Compare commits
8
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 libretech
|
64f4729f45 | ||
 libretechandClaude Opus 4.5
|
c35541961e | ||
|
libretechandClaude Opus 4.5
|
d8f68183f3 | ||
|
libretechandClaude Opus 4.5
|
705c5e3457 | ||
|
libretechandClaude Opus 4.5
|
9b0b6bc9d6 | ||
|
libretechandClaude Opus 4.5
|
62cd97c51a | ||
|
libretechandClaude Opus 4.5
|
9f2c78d536 | ||
|
libretechandClaude Opus 4.5
|
fb0db03db9 |
@@ -1,7 +1,7 @@
|
||||
# HdM Slides - Unified Makefile
|
||||
# Supports multiple courses: 223015b (Dateiformate) and 223015c (Internettechnik)
|
||||
|
||||
.PHONY: help dev dev-b dev-c build build-b build-c pdf html klausur clean install deploy qr optimize-images klausurfragen build-klausurfragen deploy-klausurfragen
|
||||
.PHONY: help dev dev-b dev-c build build-b build-c pdf html klausur clean install deploy qr optimize-images
|
||||
|
||||
# Course configuration
|
||||
COURSES = 223015b 223015c
|
||||
@@ -9,11 +9,11 @@ SLIDES_DIR = slides
|
||||
|
||||
# Course-specific settings
|
||||
223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
|
||||
223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien
|
||||
223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien klausurfragen
|
||||
223015b_DEPLOY_PATH = /home/tengo/html/hdm/223015b
|
||||
|
||||
223015c_NAME = Internettechnologien
|
||||
223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien
|
||||
223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien klausurfragen
|
||||
223015c_DEPLOY_PATH = /home/tengo/html/hdm/223015c
|
||||
|
||||
DEPLOY_HOST = tengo@tuttle.uberspace.de
|
||||
@@ -85,18 +85,7 @@ build-b: build/.exists
|
||||
build-c: build/.exists
|
||||
$(call build_course,223015c)
|
||||
|
||||
build-klausurfragen: build/.exists
|
||||
@echo "Building klausurfragen..."
|
||||
@mkdir -p build
|
||||
@if [ -f "$(SLIDES_DIR)/klausurfragen.md" ]; then \
|
||||
echo " Building klausurfragen.md..."; \
|
||||
npx @marp-team/marp-cli "$(SLIDES_DIR)/klausurfragen.md" -o build/klausurfragen.html; \
|
||||
npx @marp-team/marp-cli "$(SLIDES_DIR)/klausurfragen.md" --pdf --allow-local-files -o build/klausurfragen.pdf; \
|
||||
else \
|
||||
echo " Skipping: $(SLIDES_DIR)/klausurfragen.md not found"; \
|
||||
fi
|
||||
|
||||
build: build-b build-c build-klausurfragen
|
||||
build: build-b build-c
|
||||
@echo "All courses built!"
|
||||
|
||||
# HTML only builds
|
||||
@@ -210,20 +199,13 @@ deploy-b: build-b
|
||||
deploy-c: build-c
|
||||
$(call deploy_course,223015c)
|
||||
|
||||
# Deploy klausurfragen (root-level page)
|
||||
deploy-klausurfragen: build-klausurfragen
|
||||
@echo "Deploying klausurfragen..."
|
||||
@scp build/klausurfragen.html $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
|
||||
@scp build/klausurfragen.pdf $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
|
||||
@echo "klausurfragen deployed!"
|
||||
|
||||
deploy-index: build-index
|
||||
@echo "Deploying root index..."
|
||||
scp build/index.html $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/
|
||||
scp build/qr-root.svg $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
|
||||
@echo "Root index deployed!"
|
||||
|
||||
deploy: build-index deploy-b deploy-c deploy-klausurfragen deploy-index
|
||||
deploy: build-index deploy-b deploy-c deploy-index
|
||||
@echo "All courses deployed!"
|
||||
|
||||
# Clean
|
||||
|
||||
@@ -0,0 +1,469 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<quiz>
|
||||
|
||||
<!-- ============================================================
|
||||
223015c – Grundlagen IT- und Internettechnik
|
||||
40 Punkte / 40 Minuten
|
||||
Michael Czechowski – HdM Stuttgart – WS 2025/26
|
||||
============================================================ -->
|
||||
|
||||
<!-- ─── 3 pt – Von-Neumann: 5 Komponenten ─── -->
|
||||
<question type="matching">
|
||||
<n><text>Q1 – Von-Neumann: Komponenten zuordnen</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ordne jeder Komponente der Von-Neumann-Architektur ihre
|
||||
Funktion zu.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<answer fraction="100"><text>Rechenwerk (ALU)</text><match>Führt arithmetische und logische Operationen durch.</match></answer>
|
||||
<answer fraction="100"><text>Steuerwerk</text><match>Holt, dekodiert und steuert die Ausführung von Befehlen.</match></answer>
|
||||
<answer fraction="100"><text>Speicherwerk</text><match>Enthält sowohl Programme als auch Daten (Stored Program Concept).</match></answer>
|
||||
<answer fraction="100"><text>Ein-/Ausgabe</text><match>Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.</match></answer>
|
||||
<answer fraction="100"><text>Bus-System</text><match>Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.</match></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – Von-Neumann vs Harvard: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q2 – Von-Neumann vs. Harvard</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Arduino-Mikrocontroller nutzt die <strong>Harvard-Architektur</strong>.
|
||||
Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.</p>
|
||||
<p><strong>Warum ist die Harvard-Architektur für Echtzeit-Anwendungen
|
||||
auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn
|
||||
das Smartphone diese Architektur verwenden würde?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Speed vs. Flexibilität.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was getrennte Speicher für Code und Daten bedeuten.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Harvard nutzt <strong>separate Speicher</strong> für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – Stored Program Concept Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q3 – Stored Program Concept</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem
|
||||
ENIAC Programme durch <strong>Umstecken von Kabeln</strong> eingegeben
|
||||
werden.</p>
|
||||
<p><strong>Was konkret ermöglicht das Stored Program Concept, was
|
||||
vorher nicht möglich war? Nenne zwei Beispiele.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Programme als Daten im Speicher = Flexibilität.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – der Kern liegt darin, dass Programme im Speicher als Daten residieren.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Programme werden als <strong>Daten im Speicher</strong> abgelegt → z. B. Apps können installiert/gelöscht werden und <strong>Multitasking</strong> (mehrere Programme gleichzeitig) wird möglich.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – HTML Metadaten: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q4 – HTML: <head> vs. <body></text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Student erstellt eine Webseite und platziert <em>alles</em>
|
||||
im <code><body></code> – auch den <code><title></code>
|
||||
und die <code><meta name="description"></code>.</p>
|
||||
<p><strong>Welche zwei konkreten Konsequenzen hat das?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>title und meta description gehören in <head>. Im <body>: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Metadaten im Body werden nicht als solche interpretiert.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – <head> und <body> haben spezifische Funktionen.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[(1) Der Browser-Tab zeigt <strong>keinen Titel</strong> an. (2) Suchmaschinen haben <strong>keine Beschreibung</strong> für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Kein Problem – Browser ignorieren die Unterscheidung zwischen <code><head></code> und <code><body></code>.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Nur das Fehlen von <code><meta charset></code> ist ein Problem – title und description funktionieren überall.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – Accessibility Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q5 – Barrierefreiheit: Curb-Cut-Effekt</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Der <strong>Curb-Cut-Effekt</strong> beschreibt, wie eine
|
||||
barrierefreie Lösung – ursprünglich für Menschen mit Behinderung –
|
||||
letztendlich <em>allen</em> zugute kommt.</p>
|
||||
<p><strong>Nenne ein konkretes Web-Beispiel, das diesen Effekt
|
||||
demonstriert, und erkläre, wer davon profitiert.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Barrierefreiheit hilft allen.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, welche barrierefreien Maßnahmen auch Menschen ohne Behinderung nutzen.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Untertitel:</strong> Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Dark Mode:</strong> Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – EAA / WCAG ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q6 – European Accessibility Act</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Der <strong>European Accessibility Act (EAA)</strong> ist seit
|
||||
Juni 2025 in Kraft.</p>
|
||||
<p><strong>Was bedeutet das konkret für ein deutsches
|
||||
E-Commerce-Unternehmen, das eine Webseite betreibt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – rechtliche Pflicht zur Barrierefreiheit.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – der EAA erstellt eine rechtliche Verpflichtung für bestimmte Sektoren.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Die Webseite <strong>muss barrierefreiheitstechnisch</strong> WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – TCP/IP Schichten: Protokoll → Schicht ─── -->
|
||||
<question type="matching">
|
||||
<n><text>Q7 – TCP/IP: Protokoll → Schicht</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<answer fraction="100"><text>HTTP</text><match>Anwendung</match></answer>
|
||||
<answer fraction="100"><text>TCP</text><match>Transport</match></answer>
|
||||
<answer fraction="100"><text>IP</text><match>Internet</match></answer>
|
||||
<answer fraction="100"><text>Ethernet</text><match>Netzzugang</match></answer>
|
||||
<answer fraction="100"><text>DNS</text><match>Anwendung</match></answer>
|
||||
<answer fraction="100"><text>UDP</text><match>Transport</match></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – Encapsulation: D-S-P-F ─── -->
|
||||
<question type="matching">
|
||||
<n><text>Q8 – Encapsulation: Dateneinheit → Schicht</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Bei der Übertragung wird eine Nachricht von Schicht zu Schicht
|
||||
verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige
|
||||
Schicht zu.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<answer fraction="100"><text>Daten</text><match>Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).</match></answer>
|
||||
<answer fraction="100"><text>Segment</text><match>Transportschicht – Daten + Ports und Sequenznummern.</match></answer>
|
||||
<answer fraction="100"><text>Paket</text><match>Internetschicht – Segment + IP-Adressen (Quelle und Ziel).</match></answer>
|
||||
<answer fraction="100"><text>Frame</text><match>Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.</match></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – IP vs MAC vs Port Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q9 – IP vs. MAC vs. Port: Transfer-Szenario</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in
|
||||
einem anderen Land. Das Paket durchläuft mehrere Router.</p>
|
||||
<p><strong>Welche der folgenden Aussagen über die Adressen auf dem
|
||||
Weg ist korrekt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – nur MAC ändert sich unterwegs.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, welche Adresse bei jedem Hop neu gesetzt wird.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Die <strong>IP-Adresse</strong> des Servers bleibt konstant, der <strong>Port</strong> (443) ändert sich nicht – die <strong>MAC-Adresse</strong> wird an jedem Router neu gesetzt (lokal, ein Hop).]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – 3-Way Handshake: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q10 – TCP 3-Way-Handshake: Was passiert wäre?</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Der Client sendet ein <strong>SYN</strong> zum Server.
|
||||
Das SYN-Paket geht verloren – es erreicht den Server nie.</p>
|
||||
<p><strong>Was passiert als nächstes, und warum wird keine
|
||||
Verbindung aufgebaut?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – ohne SYN beim Server: kein SYN-ACK, kein Handshake.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was der Server ohne SYN tun kann.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Der Server kennt die Anfrage nicht → sendet <strong>kein SYN-ACK</strong> → der Client erhält keine Antwort → <strong>keine Verbindung</strong>. Der Client wird das SYN nach einem Timeout erneut senden.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – TCP vs UDP Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q11 – TCP vs. UDP: Videostreaming</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Videostreaming-Dienst sendet Daten an deinen Browser.
|
||||
Ein einzelnes Paket geht verloren.</p>
|
||||
<p><strong>Warum wählt der Dienst <strong>UDP</strong> statt TCP,
|
||||
obwohl ein Paket verloren geht?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – bei Echtzeit ist Verzögerung ärger als Verlust.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was TCP bei einem verlorenen Paket tun würde.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Bei <strong>Echtzeit</strong> ist Verzögerung schlimmer als Verlust. TCP würde das Paket <strong>erneut anfordern</strong> → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – HTTP Methoden: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q12 – HTTP-Methoden: Szenario</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Nutzer aktualisiert sein Profilbild auf einer Webseite.
|
||||
Das Foto wird zum Server gesendet und das <strong>alte Bild
|
||||
ersetzt</strong>.</p>
|
||||
<p><strong>Welche HTTP-Methode wird für diese Operation verwendet,
|
||||
und warum nicht GET?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – PUT für das Ersetzen einer Ressource.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was „ersetzen" in HTTP bedeutet.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>PUT</strong> – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet <em>keine</em> Daten zum Server.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>GET</strong> – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>POST</strong> – POST ist immer für das Ersetzen von Daten zuständig.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>DELETE</strong> – DELETE sendet das neue Foto und löscht gleichzeitig das alte.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – HTTP Status-Codes Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q13 – HTTP Status-Codes: Fehlerdiagnose</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Du rufst eine Webseite auf und der Browser zeigt folgende
|
||||
Fehlermeldung an:</p>
|
||||
<pre>HTTP/1.1 503 Service Unavailable</pre>
|
||||
<p><strong>Was bedeutet dieser Code, und wer ist für die Behebung
|
||||
zuständig – du oder der Betreiber der Webseite?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – 5xx = Server-Problem, nicht dein Fehler.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was die Ziffer „5" im Code bedeutet.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Server-Fehler:</strong> Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim <strong>Betreiber</strong> – du kannst nur später erneut versuchen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – DNS Ablauf Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q14 – DNS: Rolle im Ablauf</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Du gibst <code>https://hdm-stuttgart.de</code> in die
|
||||
Adresszeile ein.</p>
|
||||
<p><strong>Was passiert <em>vor</em> dem TCP-Handshake, und warum
|
||||
ist dieser Schritt zwingend nötig?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – DNS vor TCP, Name → IP.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was TCP als Zieladresse braucht.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>DNS-Auflösung:</strong> Der Name <code>hdm-stuttgart.de</code> wird in eine <strong>IP-Adresse</strong> umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – CSS Spezifität Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q15 – CSS Spezifität: Welche Regel gewinnt?</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Gegeben folgender CSS-Code:</p>
|
||||
<pre>
|
||||
p { color: blue; } /* (A) */
|
||||
.highlight { color: green; } /* (B) */
|
||||
#main { color: red; } /* (C) */
|
||||
</pre>
|
||||
<p>Ein Element <code><p class="highlight" id="main">Text</p></code>
|
||||
wird angezeigt.<br>
|
||||
<strong>Welche Farbe zeigt der Text an, und warum?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – ID gewinnt durch höchste Spezifität.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege die Spezifitätswerte: ID > Klasse > Element.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Rot</strong> – die ID-Regel <code>#main</code> hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die Element-Regel steht zuerst im Code und hat daher Vorrang.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Grün</strong> – Klassen-Selektoren haben immer Vorrang vor IDs.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Rot</strong> – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – Responsive Design Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q16 – Responsive Design: Mobile First</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Developer schreibt folgendes CSS:</p>
|
||||
<pre>
|
||||
.container { background: white; }
|
||||
|
||||
@media (min-width: 768px) {
|
||||
.container { background: blue; }
|
||||
}
|
||||
|
||||
@media (min-width: 1024px) {
|
||||
.container { background: green; }
|
||||
}
|
||||
</pre>
|
||||
<p><strong>Welche Farbe hat <code>.container</code> bei einem
|
||||
Bildschirm von 900 px Breite, und warum?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 < 1024). Ergebnis: blau.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – 768px greift, 1024px nicht.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, welche min-width-Bedingungen bei 900px erfüllt sind.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Blau</strong> – bei 900 px greift <code>min-width: 768px</code> (900 ≥ 768), aber <code>min-width: 1024px</code> greift nicht (900 < 1024).]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Grün</strong> – die letzte Media-Query überschreibt immer alle vorherigen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 1 pt – Zusammen: Der Ablauf eines Klicks ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Du gibst eine URL ein. <strong>Welche Reihenfolge der Schritte
|
||||
ist korrekt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).</text></generalfeedback>
|
||||
<defaultgrade>1</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – DNS → TCP → HTTP Request → HTTP Response.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – an erster Stelle steht immer die DNS-Auflösung.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 1 pt – Bonusfrage: Spezifität Edge Case ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q18 – CSS: 100 Element-Selektoren vs. 1 Klasse</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Es gibt zwei CSS-Regeln für ein <code><p></code>-Element:</p>
|
||||
<pre>
|
||||
p p p p p p p p p p { color: blue; } /* 100× Element-Selektor */
|
||||
.highlight { color: red; } /* 1× Klasse */
|
||||
</pre>
|
||||
<p>Das Element hat die Klasse <code>highlight</code>.
|
||||
<strong>Welche Farbe gewinnt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.</text></generalfeedback>
|
||||
<defaultgrade>1</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – eine Klasse gewinnt immer gegen beliebig viele Elemente.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – Spezifität funktioniert nicht durch Addition innerhalb einer Stelle.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Rot</strong> – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Unentschieden – die Regeln haben exakt gleiche Spezifität.]]></text></answer>
|
||||
</question>
|
||||
|
||||
</quiz>
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,439 @@
|
||||
Here is the quiz converted into a clean, readable Markdown format. I have preserved the structure, code snippets, and feedback for each question.
|
||||
|
||||
---
|
||||
|
||||
# 223015c – Grundlagen IT- und Internettechnik
|
||||
|
||||
**WS 2025/26 – Michael Czechowski – HdM Stuttgart**
|
||||
**40 Punkte / 40 Minuten**
|
||||
|
||||
---
|
||||
|
||||
### Q1 – Von-Neumann: Komponenten zuordnen (3 pt)
|
||||
|
||||
**Ordne jeder Komponente der Von-Neumann-Architektur ihre Funktion zu.**
|
||||
|
||||
* **Rechenwerk (ALU):** Führt arithmetische und logische Operationen durch.
|
||||
* **Steuerwerk:** Holt, dekodiert und steuert die Ausführung von Befehlen.
|
||||
* **Speicherwerk:** Enthält sowohl Programme als auch Daten (Stored Program Concept).
|
||||
* **Ein-/Ausgabe:** Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.
|
||||
* **Bus-System:** Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.
|
||||
|
||||
> **Feedback:** Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).
|
||||
|
||||
---
|
||||
|
||||
### Q2 – Von-Neumann vs. Harvard (2 pt)
|
||||
|
||||
**Ein Arduino-Mikrocontroller nutzt die Harvard-Architektur. Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.**
|
||||
|
||||
**Warum ist die Harvard-Architektur für Echtzeit-Anwendungen auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn das Smartphone diese Architektur verwenden würde?**
|
||||
|
||||
* [ ] Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.
|
||||
* [x] **Harvard nutzt separate Speicher für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.** ✅
|
||||
* [ ] Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.
|
||||
* [ ] Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.
|
||||
|
||||
> **Feedback:** Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.
|
||||
|
||||
---
|
||||
|
||||
### Q3 – Stored Program Concept (2 pt)
|
||||
|
||||
**Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem ENIAC Programme durch Umstecken von Kabeln eingegeben werden.**
|
||||
|
||||
**Was konkret ermöglicht das Stored Program Concept, was vorher nicht möglich war? Nenne zwei Beispiele.**
|
||||
|
||||
* [ ] Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.
|
||||
* [ ] Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.
|
||||
* [x] **Programme werden als Daten im Speicher abgelegt → z. B. Apps können installiert/gelöscht werden und Multitasking (mehrere Programme gleichzeitig) wird möglich.** ✅
|
||||
* [ ] Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.
|
||||
|
||||
> **Feedback:** Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.
|
||||
|
||||
---
|
||||
|
||||
### Q4 – HTML: `<head>` vs. `<body>` (2 pt)
|
||||
|
||||
**Ein Student erstellt eine Webseite und platziert *alles* im `<body>` – auch den `<title>` und die `<meta name="description">`.**
|
||||
|
||||
**Welche zwei konkreten Konsequenzen hat das?**
|
||||
|
||||
* [ ] Kein Problem – Browser ignorieren die Unterscheidung zwischen `<head>` und `<body>`.
|
||||
* [x] **(1) Der Browser-Tab zeigt keinen Titel an. (2) Suchmaschinen haben keine Beschreibung für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen.** ✅
|
||||
* [ ] (1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.
|
||||
* [ ] Nur das Fehlen von `<meta charset>` ist ein Problem – title und description funktionieren überall.
|
||||
|
||||
> **Feedback:** title und meta description gehören in `<head>`. Im `<body>`: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.
|
||||
|
||||
---
|
||||
|
||||
### Q5 – Barrierefreiheit: Curb-Cut-Effekt (3 pt)
|
||||
|
||||
**Der Curb-Cut-Effekt beschreibt, wie eine barrierefreie Lösung – ursprünglich für Menschen mit Behinderung – letztendlich *allen* zugute kommt.**
|
||||
|
||||
**Nenne ein konkretes Web-Beispiel, das diesen Effekt demonstriert, und erkläre, wer davon profitiert.**
|
||||
|
||||
* [ ] Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.
|
||||
* [ ] Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.
|
||||
* [x] **Untertitel: Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.** ✅
|
||||
* [ ] **Dark Mode:** Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.
|
||||
|
||||
> **Feedback:** Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.
|
||||
|
||||
---
|
||||
|
||||
### Q6 – European Accessibility Act (2 pt)
|
||||
|
||||
**Der European Accessibility Act (EAA) ist seit Juni 2025 in Kraft.**
|
||||
|
||||
**Was bedeutet das konkret für ein deutsches E-Commerce-Unternehmen, das eine Webseite betreibt?**
|
||||
|
||||
* [ ] Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.
|
||||
* [ ] Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.
|
||||
* [x] **Die Webseite muss barrierefreiheitstechnisch WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.** ✅
|
||||
* [ ] Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.
|
||||
|
||||
> **Feedback:** EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.
|
||||
|
||||
---
|
||||
|
||||
### Q7 – TCP/IP: Protokoll → Schicht (3 pt)
|
||||
|
||||
**Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.**
|
||||
|
||||
* **HTTP:** Anwendung
|
||||
* **DNS:** Anwendung
|
||||
* **TCP:** Transport
|
||||
* **UDP:** Transport
|
||||
* **IP:** Internet
|
||||
* **Ethernet:** Netzzugang
|
||||
|
||||
> **Feedback:** Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.
|
||||
|
||||
---
|
||||
|
||||
### Q8 – Encapsulation: Dateneinheit → Schicht (3 pt)
|
||||
|
||||
**Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige Schicht zu.**
|
||||
|
||||
* **Daten:** Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).
|
||||
* **Segment:** Transportschicht – Daten + Ports und Sequenznummern.
|
||||
* **Paket:** Internetschicht – Segment + IP-Adressen (Quelle und Ziel).
|
||||
* **Frame:** Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.
|
||||
|
||||
> **Feedback:** Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.
|
||||
|
||||
---
|
||||
|
||||
### Q9 – IP vs. MAC vs. Port: Transfer-Szenario (3 pt)
|
||||
|
||||
**Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in einem anderen Land. Das Paket durchläuft mehrere Router.**
|
||||
|
||||
**Welche der folgenden Aussagen über die Adressen auf dem Weg ist korrekt?**
|
||||
|
||||
* [ ] Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.
|
||||
* [x] **Die IP-Adresse des Servers bleibt konstant, der Port (443) ändert sich nicht – die MAC-Adresse wird an jedem Router neu gesetzt (lokal, ein Hop).** ✅
|
||||
* [ ] Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.
|
||||
* [ ] IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.
|
||||
|
||||
> **Feedback:** IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.
|
||||
|
||||
---
|
||||
|
||||
### Q10 – TCP 3-Way-Handshake: Was passiert wäre? (3 pt)
|
||||
|
||||
**Der Client sendet ein SYN zum Server. Das SYN-Paket geht verloren – es erreicht den Server nie.**
|
||||
|
||||
**Was passiert als nächstes, und warum wird keine Verbindung aufgebaut?**
|
||||
|
||||
* [ ] Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.
|
||||
* [x] **Der Server kennt die Anfrage nicht → sendet kein SYN-ACK → der Client erhält keine Antwort → keine Verbindung. Der Client wird das SYN nach einem Timeout erneut senden.** ✅
|
||||
* [ ] Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.
|
||||
* [ ] Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.
|
||||
|
||||
> **Feedback:** Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).
|
||||
|
||||
---
|
||||
|
||||
### Q11 – TCP vs. UDP: Videostreaming (2 pt)
|
||||
|
||||
**Ein Videostreaming-Dienst sendet Daten an deinen Browser. Ein einzelnes Paket geht verloren.**
|
||||
|
||||
**Warum wählt der Dienst UDP statt TCP, obwohl ein Paket verloren geht?**
|
||||
|
||||
* [ ] UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.
|
||||
* [x] **Bei Echtzeit ist Verzögerung schlimmer als Verlust. TCP würde das Paket erneut anfordern → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.** ✅
|
||||
* [ ] TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.
|
||||
* [ ] UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.
|
||||
|
||||
> **Feedback:** Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.
|
||||
|
||||
---
|
||||
|
||||
### Q12 – HTTP-Methoden: Szenario (2 pt)
|
||||
|
||||
**Ein Nutzer aktualisiert sein Profilbild auf einer Webseite. Das Foto wird zum Server gesendet und das *alte Bild ersetzt*.**
|
||||
|
||||
**Welche HTTP-Methode wird für diese Operation verwendet, und warum nicht GET?**
|
||||
|
||||
* [ ] **GET** – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.
|
||||
* [x] **PUT – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet *keine* Daten zum Server.** ✅
|
||||
* [ ] **POST** – POST ist immer für das Ersetzen von Daten zuständig.
|
||||
* [ ] **DELETE** – DELETE sendet das neue Foto und löscht gleichzeitig das alte.
|
||||
|
||||
> **Feedback:** PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.
|
||||
|
||||
---
|
||||
|
||||
### Q13 – HTTP Status-Codes: Fehlerdiagnose (2 pt)
|
||||
|
||||
**Du rufst eine Webseite auf und der Browser zeigt folgende Fehlermeldung an:**
|
||||
`HTTP/1.1 503 Service Unavailable`
|
||||
|
||||
**Was bedeutet dieser Code, und wer ist für die Behebung zuständig – du oder der Betreiber der Webseite?**
|
||||
|
||||
* [ ] Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.
|
||||
* [ ] Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.
|
||||
* [x] **Server-Fehler: Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Betreiber – du kannst nur später erneut versuchen.** ✅
|
||||
* [ ] Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.
|
||||
|
||||
> **Feedback:** 503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.
|
||||
|
||||
---
|
||||
|
||||
### Q14 – DNS: Rolle im Ablauf (2 pt)
|
||||
|
||||
**Du gibst `https://hdm-stuttgart.de` in die Adresszeile ein.**
|
||||
|
||||
**Was passiert *vor* dem TCP-Handshake, und warum ist dieser Schritt zwingend nötig?**
|
||||
|
||||
* [ ] Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.
|
||||
* [x] **DNS-Auflösung: Der Name `hdm-stuttgart.de` wird in eine IP-Adresse umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.** ✅
|
||||
* [ ] DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.
|
||||
* [ ] DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.
|
||||
|
||||
> **Feedback:** DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.
|
||||
|
||||
---
|
||||
|
||||
### Q15 – CSS Spezifität: Welche Regel gewinnt? (2 pt)
|
||||
|
||||
**Gegeben folgender CSS-Code:**
|
||||
|
||||
```css
|
||||
p { color: blue; } /* (A) */
|
||||
.highlight { color: green; } /* (B) */
|
||||
#main { color: red; } /* (C) */
|
||||
|
||||
```
|
||||
|
||||
**Ein Element `<p class="highlight" id="main">Text</p>` wird angezeigt.**
|
||||
**Welche Farbe zeigt der Text an, und warum?**
|
||||
|
||||
* [ ] **Blau** – die Element-Regel steht zuerst im Code und hat daher Vorrang.
|
||||
* [ ] **Grün** – Klassen-Selektoren haben immer Vorrang vor IDs.
|
||||
* [x] **Rot – die ID-Regel `#main` hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).** ✅
|
||||
* [ ] **Rot** – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.
|
||||
|
||||
> **Feedback:** Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.
|
||||
|
||||
---
|
||||
|
||||
### Q16 – Responsive Design: Mobile First (2 pt)
|
||||
|
||||
**Ein Developer schreibt folgendes CSS:**
|
||||
|
||||
```css
|
||||
.container { background: white; }
|
||||
|
||||
@media (min-width: 768px) {
|
||||
.container { background: blue; }
|
||||
}
|
||||
|
||||
@media (min-width: 1024px) {
|
||||
.container { background: green; }
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
**Welche Farbe hat `.container` bei einem Bildschirm von 900 px Breite, und warum?**
|
||||
|
||||
* [ ] **Weiß** – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.
|
||||
* [ ] **Grün** – die letzte Media-Query überschreibt immer alle vorherigen.
|
||||
* [x] **Blau – bei 900 px greift `min-width: 768px` (900 ≥ 768), aber `min-width: 1024px` greift nicht (900 < 1024).** ✅
|
||||
* [ ] **Weiß** – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.
|
||||
|
||||
> **Feedback:** Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 < 1024). Ergebnis: blau.
|
||||
|
||||
---
|
||||
|
||||
### Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs (1 pt)
|
||||
|
||||
**Du gibst eine URL ein. Welche Reihenfolge der Schritte ist korrekt?**
|
||||
|
||||
* [ ] (1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK
|
||||
* [x] **(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK** ✅
|
||||
* [ ] (1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK
|
||||
* [ ] (1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK
|
||||
|
||||
> **Feedback:** Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).
|
||||
|
||||
---
|
||||
|
||||
### Q18 – Bonusfrage: Spezifität Edge Case (1 pt)
|
||||
|
||||
**Es gibt zwei CSS-Regeln für ein `<p>`-Element:**
|
||||
|
||||
```css
|
||||
p p p p p p p p p p { color: blue; } /* 100× Element-Selektor */
|
||||
.highlight { color: red; } /* 1× Klasse */
|
||||
|
||||
```
|
||||
|
||||
**Das Element hat die Klasse `highlight`. Welche Farbe gewinnt?**
|
||||
|
||||
* [ ] **Blau** – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.
|
||||
* [x] **Rot – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.** ✅
|
||||
* [ ] **Blau** – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.
|
||||
* [ ] Unentschieden – die Regeln haben exakt gleiche Spezifität.
|
||||
|
||||
> **Feedback:** Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.
|
||||
|
||||
---
|
||||
|
||||
### Q19 – Von-Neumann: Der Flaschenhals (Engpass)
|
||||
|
||||
**Die Von-Neumann-Architektur hat einen bekannten Nachteil, den sogenannten „Von-Neumann-Flaschenhals“. Was ist damit gemeint?**
|
||||
|
||||
* [ ] Das Steuerwerk kann Befehle schneller verarbeiten, als das Rechenwerk sie berechnen kann.
|
||||
* [x] **Die CPU ist schneller als der Datentransfer über den gemeinsamen Bus. Da Daten und Befehle denselben Bus nutzen, müssen sie nacheinander geladen werden.** ✅
|
||||
* [ ] Der Speicher verliert seine Daten, wenn der Strom abgeschaltet wird, was den Startvorgang verlangsamt.
|
||||
* [ ] Die Ein-/Ausgabegeräte blockieren den Prozessor dauerhaft, da sie keinen eigenen Speicher haben.
|
||||
|
||||
> **Feedback:** Der Flaschenhals entsteht, weil Befehle und Daten sich den gleichen Weg (Bus) teilen müssen und der Speicherzugriff langsamer ist als die CPU-Geschwindigkeit.
|
||||
|
||||
---
|
||||
|
||||
### Q20 – HTML: Encoding (Charset)
|
||||
|
||||
**In Q4 ging es um Metadaten. Ein weiteres wichtiges Tag im `<head>` ist `<meta charset="UTF-8">`. Was ist die konkrete Konsequenz, wenn dieses Tag fehlt oder falsch ist?**
|
||||
|
||||
* [ ] Die Webseite lädt gar nicht, da der Browser den Binärcode nicht interpretieren kann.
|
||||
* [x] **Sonderzeichen (Umlaute, Emojis) werden als kryptische Symbole („Hieroglyphen“) dargestellt, da der Browser die falsche Zeichenkodierung rät.** ✅
|
||||
* [ ] Die Seite wird langsamer, da der Browser erst alle Sprachen der Welt durchprobieren muss.
|
||||
* [ ] Das CSS wird nicht geladen, da CSS zwingend UTF-8 voraussetzt.
|
||||
|
||||
> **Feedback:** Ohne definierte `charset` (Zeichensatz) nutzt der Browser oft einen Standard (z. B. Latin-1), was bei UTF-8-gespeicherten Dateien zu Darstellungsfehlern bei ä, ö, ü oder Emojis führt.
|
||||
|
||||
---
|
||||
|
||||
### Q21 – Barrierefreiheit: POUR-Prinzip
|
||||
|
||||
**Die WCAG basieren auf vier Prinzipien (POUR). Eines davon ist „Bedienbarkeit“ (Operable). Welches Szenario beschreibt eine Verletzung dieses Prinzips?**
|
||||
|
||||
* [ ] Der Textkontrast ist zu gering (grau auf hellgrau), sodass man ihn kaum lesen kann.
|
||||
* [x] **Eine Navigation funktioniert nur per Maus (Hover), ist aber per Tastatur (Tab-Taste) nicht erreichbar.** ✅
|
||||
* [ ] Der Inhalt ist in sehr komplizierter Fachsprache geschrieben, die ein Laie nicht versteht.
|
||||
* [ ] Die Webseite stürzt in alten Browsern ab.
|
||||
|
||||
> **Feedback:** „Bedienbar“ bedeutet, dass die Schnittstelle (Buttons, Links) von jedem genutzt werden kann – also auch ohne Maus (nur Tastatur). Kontrast gehört zu „Wahrnehmbar“ (Perceivable).
|
||||
|
||||
---
|
||||
|
||||
### Q22 – Encapsulation: Die Empfänger-Seite (Decapsulation)
|
||||
|
||||
**In Q8 haben wir Daten verpackt. Wenn der Server das Signal empfängt, passiert das Gegenteil (Decapsulation). In welcher Reihenfolge werden die Header *entfernt*?**
|
||||
|
||||
* [ ] Anwendung (HTTP) → Transport (TCP) → Internet (IP) → Netzzugang (Ethernet)
|
||||
* [ ] Es werden alle Header gleichzeitig entfernt, sobald die Daten im RAM liegen.
|
||||
* [x] **Netzzugang (Ethernet-Header weg) → Internet (IP-Header weg) → Transport (TCP-Header weg) → Daten.** ✅
|
||||
* [ ] Internet (IP) → Netzzugang (Ethernet) → Transport (TCP) → Anwendung (HTTP)
|
||||
|
||||
> **Feedback:** Das Auspacken erfolgt in umgekehrter Reihenfolge wie das Einpacken (Zwiebel-Prinzip). Erst wird der Umschlag (Ethernet) geöffnet, dann das Paket (IP), dann das Segment (TCP).
|
||||
|
||||
---
|
||||
|
||||
### Q23 – Ports: Wozu genau?
|
||||
|
||||
**Wir wissen aus Q9, dass IP-Adressen Computer identifizieren. Wozu genau dient dann die Port-Nummer (z. B. 80 oder 443) auf dem Zielrechner?**
|
||||
|
||||
* [ ] Sie bestimmt die Geschwindigkeit der Verbindung.
|
||||
* [ ] Sie dient zur Verschlüsselung der Daten.
|
||||
* [x] **Sie adressiert den konkreten Dienst bzw. die Anwendung auf dem Computer (z. B. Webserver vs. Mailserver).** ✅
|
||||
* [ ] Sie zeigt an, ob der Computer per WLAN oder Kabel verbunden ist.
|
||||
|
||||
> **Feedback:** Die IP ist wie die Hausnummer (welches Gebäude?), der Port ist wie die Türnummer oder der Name an der Klingel (wer im Haus soll das Paket bekommen? Webserver? Mailserver?).
|
||||
|
||||
---
|
||||
|
||||
### Q24 – TCP: Sequenznummern
|
||||
|
||||
**TCP ist zuverlässig. Ein Mechanismus dafür sind „Sequenznummern“ im Header. Welches Problem lösen diese konkret?**
|
||||
|
||||
* [ ] Sie verhindern, dass Hacker die Verbindung abhören können.
|
||||
* [x] **Pakete können im Internet unterschiedliche Routen nehmen und in falscher Reihenfolge ankommen. Sequenznummern erlauben das korrekte Sortieren beim Empfänger.** ✅
|
||||
* [ ] Sie zählen, wie viele Benutzer gerade gleichzeitig auf dem Server sind.
|
||||
* [ ] Sie bestimmen die maximale Größe einer Datei.
|
||||
|
||||
> **Feedback:** Da IP-Pakete überholen können, kommen Teil 2 und Teil 3 vielleicht vor Teil 1 an. TCP sortiert sie anhand der Nummern wieder richtig. UDP macht das nicht.
|
||||
|
||||
---
|
||||
|
||||
### Q25 – HTTP Methoden: Sicherheit
|
||||
|
||||
**Warum sollte man niemals die GET-Methode verwenden, um sensible Daten (z. B. ein Passwort) an den Server zu senden?**
|
||||
|
||||
* [ ] GET ist langsamer als POST und Passwörter müssen schnell übertragen werden.
|
||||
* [x] **Bei GET stehen die Daten sichtbar in der URL (Browser-Verlauf, Server-Logs, Proxy-Server). Bei POST stehen sie im Body.** ✅
|
||||
* [ ] GET erlaubt nur Zahlen, keine Buchstaben.
|
||||
* [ ] GET-Anfragen werden vom Server nicht verschlüsselt, POST-Anfragen immer.
|
||||
|
||||
> **Feedback:** Parameter bei GET hängen an der URL (`?pw=123`). Das ist in der History und in Logs sichtbar. HTTPS verschlüsselt zwar beides auf der Leitung, aber die URL ist an zu vielen Stellen sichtbar.
|
||||
|
||||
---
|
||||
|
||||
### Q26 – HTTP Status: 404 Not Found
|
||||
|
||||
**Du erhältst einen 404-Fehler. In Q13 (503) lag der Fehler beim Server. Wer hat beim 404-Fehler „Schuld“ bzw. wo liegt die Ursache meistens?**
|
||||
|
||||
* [ ] Der Server ist abgestürzt.
|
||||
* [ ] Das Internet ist ausgefallen.
|
||||
* [x] **Der Client (Nutzer). Es wurde eine URL angefordert, die es nicht gibt (Tippfehler oder veralteter Link).** ✅
|
||||
* [ ] Der DNS-Server konnte den Namen nicht auflösen.
|
||||
|
||||
> **Feedback:** 4xx-Codes sind Client-Errors. Der Server funktioniert super, er sagt dir nur: „Das, was du (Client) suchst, habe ich nicht.“
|
||||
|
||||
---
|
||||
|
||||
### Q27 – CSS: `!important` vs. ID
|
||||
|
||||
**In Q15 hat die ID gewonnen. Nun ändern wir den Code:**
|
||||
|
||||
```css
|
||||
#main { color: red; }
|
||||
p { color: blue !important; }
|
||||
|
||||
```
|
||||
|
||||
**Welche Farbe hat das `<p id="main">` Element nun?**
|
||||
|
||||
* [ ] **Rot** – ID ist immer noch spezifischer als ein Element-Selektor.
|
||||
* [ ] **Lila** – Die Farben mischen sich.
|
||||
* [x] **Blau** – `!important` durchbricht die normale Spezifitäts-Kaskade und gewinnt sogar gegen IDs (außer die ID hat auch !important). ✅
|
||||
* [ ] **Rot** – `!important` wird von modernen Browsern ignoriert.
|
||||
|
||||
> **Feedback:** `!important` ist die „Atombombe“ im CSS. Es überschreibt normale Spezifitätsregeln (ID, Klasse, Element). Es sollte daher sehr sparsam eingesetzt werden.
|
||||
|
||||
---
|
||||
|
||||
### Q28 – Responsive Design: Desktop First
|
||||
|
||||
**In Q16 nutzten wir `min-width` (Mobile First). Wie würde die Media Query aussehen, wenn wir „Desktop First“ arbeiten würden (also Standard ist Desktop, Anpassung für kleine Screens)?**
|
||||
|
||||
* [ ] `@media (device-width: small) { ... }`
|
||||
* [ ] `@media (min-width: ...)` – das bleibt gleich, nur die Reihenfolge ändert sich.
|
||||
* [x] **`@media (max-width: ...)` – Wir definieren Stile für Bildschirme, die *kleiner* als eine bestimmte Breite sind.** ✅
|
||||
* [ ] `@media (mobile: true) { ... }`
|
||||
|
||||
> **Feedback:** Desktop First bedeutet: Das Basis-CSS ist für große Schirme. Mit `max-width` (maximale Breite) definieren wir Ausnahmen für Geräte, die schmaler sind (Tablets, Handys).
|
||||
@@ -41,6 +41,7 @@ TOPIC_MAP["vertiefung-offene-fragen"]="Vertiefung & Offene Fragen"
|
||||
TOPIC_MAP["geschichte-grundlagen-html"]="Geschichte, Grundlagen & HTML"
|
||||
TOPIC_MAP["netzwerke-protokolle-css"]="Netzwerke, Protokolle & CSS"
|
||||
TOPIC_MAP["interaktivitaet-javascript"]="Interaktivität & JavaScript"
|
||||
TOPIC_MAP["klausurfragen"]="Klausurfragen"
|
||||
|
||||
# Configure which topics should appear disabled per course
|
||||
# Two modes: fully disabled (non-clickable card) and buttons-disabled (link remains clickable, buttons are disabled)
|
||||
|
||||
Executable
+187
@@ -0,0 +1,187 @@
|
||||
#!/usr/bin/env bash
|
||||
# Generate root index.html for /hdm/
|
||||
# Lists all courses (klausurfragen are now per-course)
|
||||
|
||||
BUILD_DIR="build"
|
||||
|
||||
cat > "$BUILD_DIR/index.html" << 'HEADER'
|
||||
<!DOCTYPE html>
|
||||
<html lang="de">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>HdM Vorlesungen</title>
|
||||
<style>
|
||||
* { box-sizing: border-box; margin: 0; padding: 0; }
|
||||
body {
|
||||
font-family: -apple-system, BlinkMacSystemFont, "SF Pro Display", "Segoe UI", Roboto, sans-serif;
|
||||
max-width: 720px;
|
||||
margin: 0 auto;
|
||||
padding: 3rem 1.5rem;
|
||||
background: #fafafa;
|
||||
color: #1d1d1f;
|
||||
line-height: 1.5;
|
||||
}
|
||||
h1 {
|
||||
font-size: 2rem;
|
||||
font-weight: 600;
|
||||
letter-spacing: -0.02em;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
.subtitle { color: #86868b; font-size: 1rem; }
|
||||
.courses {
|
||||
margin-top: 2rem;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 0.75rem;
|
||||
}
|
||||
.course-card {
|
||||
position: relative;
|
||||
background: #fff;
|
||||
border-radius: 12px;
|
||||
box-shadow: 0 1px 3px rgba(0,0,0,0.08);
|
||||
transition: all 0.2s ease;
|
||||
display: grid;
|
||||
grid-template-columns: 1fr auto auto;
|
||||
align-items: center;
|
||||
gap: 1rem;
|
||||
}
|
||||
.course-card:hover {
|
||||
transform: translateY(-2px);
|
||||
box-shadow: 0 4px 12px rgba(0,0,0,0.12);
|
||||
}
|
||||
.course-link {
|
||||
display: block;
|
||||
padding: 1.25rem 1.5rem;
|
||||
text-decoration: none;
|
||||
color: inherit;
|
||||
grid-column: 1;
|
||||
}
|
||||
.course-link::after {
|
||||
content: '';
|
||||
position: absolute;
|
||||
inset: 0;
|
||||
border-radius: 12px;
|
||||
}
|
||||
.course-label {
|
||||
font-size: 0.7rem;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.05em;
|
||||
}
|
||||
.course-b .course-label { color: #1e5f8a; }
|
||||
.course-c .course-label { color: #d63384; }
|
||||
.course-title {
|
||||
font-size: 1.15rem;
|
||||
font-weight: 500;
|
||||
color: #1d1d1f;
|
||||
margin: 0.25rem 0;
|
||||
}
|
||||
.course-info { font-size: 0.85rem; color: #86868b; }
|
||||
.btn {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
padding: 0.5rem 1rem;
|
||||
border-radius: 8px;
|
||||
text-decoration: none;
|
||||
font-size: 0.8rem;
|
||||
font-weight: 500;
|
||||
transition: all 0.2s;
|
||||
white-space: nowrap;
|
||||
position: relative;
|
||||
z-index: 1;
|
||||
margin-right: 0.5rem;
|
||||
}
|
||||
.btn-slides {
|
||||
background: #6c757d;
|
||||
color: #fff;
|
||||
}
|
||||
.btn-slides:hover { filter: brightness(1.1); }
|
||||
.btn-pdf {
|
||||
background: #f5f5f7;
|
||||
color: #1d1d1f;
|
||||
}
|
||||
.btn-pdf:hover { background: #e8e8ed; }
|
||||
.section-title {
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: #86868b;
|
||||
margin-top: 2.5rem;
|
||||
margin-bottom: 0.75rem;
|
||||
}
|
||||
.references {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 0.75rem;
|
||||
}
|
||||
footer {
|
||||
margin-top: 2.5rem;
|
||||
padding-top: 1.5rem;
|
||||
border-top: 1px solid #e5e5e7;
|
||||
color: #86868b;
|
||||
font-size: 0.85rem;
|
||||
}
|
||||
footer a { color: #1d1d1f; text-decoration: none; }
|
||||
footer a:hover { text-decoration: underline; }
|
||||
.qr-section {
|
||||
margin-top: 2.5rem;
|
||||
padding: 1.5rem;
|
||||
background: #fff;
|
||||
border-radius: 12px;
|
||||
box-shadow: 0 1px 3px rgba(0,0,0,0.08);
|
||||
text-align: center;
|
||||
}
|
||||
.qr-code { width: 100%; height: auto; }
|
||||
.qr-url { margin-top: 0.75rem; font-size: 0.85rem; color: #86868b; }
|
||||
@media (max-width: 600px) {
|
||||
.course-card { grid-template-columns: 1fr; }
|
||||
.course-link { padding-bottom: 0.75rem; }
|
||||
.btn { margin: 0 1rem 1rem 1.5rem; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<h1>HdM Vorlesungen</h1>
|
||||
<p class="subtitle">Wintersemester 2025/26 · Michael Czechowski</p>
|
||||
<div class="courses">
|
||||
<div class="course-card course-b">
|
||||
<a href="223015b/" class="course-link">
|
||||
<span class="course-label">223015b</span>
|
||||
<div class="course-title">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div>
|
||||
<span class="course-info">6 Kapitel · Modul "Technik 1"</span>
|
||||
</a>
|
||||
</div>
|
||||
<div class="course-card course-c">
|
||||
<a href="223015c/" class="course-link">
|
||||
<span class="course-label">223015c</span>
|
||||
<div class="course-title">Grundlagen IT- und Internettechnik</div>
|
||||
<span class="course-info">3 Kapitel · Modul "Technik 1"</span>
|
||||
</a>
|
||||
</div>
|
||||
HEADER
|
||||
|
||||
cat >> "$BUILD_DIR/index.html" << 'FOOTER'
|
||||
</div>
|
||||
<h2 class="section-title">Referenzen</h2>
|
||||
<div class="references">
|
||||
<div class="course-card">
|
||||
<a href="https://codecrispi.es/" class="course-link">
|
||||
<span class="course-label">Plattform</span>
|
||||
<div class="course-title">Code Crispies</div>
|
||||
<span class="course-info">Selbstlernplattform</span>
|
||||
</a>
|
||||
</div>
|
||||
</div>
|
||||
<div class="qr-section">
|
||||
<img src="qr-root.svg" alt="QR Code" class="qr-code">
|
||||
<p class="qr-url">https://librete.ch/hdm/</p>
|
||||
</div>
|
||||
<footer>
|
||||
<a href="mailto:mail@librete.ch">Kontakt</a>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
FOOTER
|
||||
|
||||
echo "Generated $BUILD_DIR/index.html"
|
||||
File diff suppressed because it is too large
Load Diff
+1362
-1022
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,924 @@
|
||||
---
|
||||
marp: true
|
||||
theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Klausurfragen – 223015b"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
title: "Klausurfragen – Dateiformate, Schnittstellen, Speichermedien"
|
||||
---
|
||||
<style>
|
||||
:root {
|
||||
--color-foreground: #1a1a2e;
|
||||
--color-highlight: #1e5f8a;
|
||||
--color-dimmed: #4a4a6a;
|
||||
}
|
||||
section.invert { --color-foreground: #fff; }
|
||||
section { font-size: 1.325rem; }
|
||||
h1 { color: #1e5f8a; }
|
||||
section.invert h1 { color: #fff; }
|
||||
h2 { color: #1f2937; }
|
||||
pre { background: #0f0f23; border-radius: 8px; }
|
||||
pre code { background: transparent; color: inherit; }
|
||||
a { color: var(--color-highlight); }
|
||||
section.disable { opacity: 0.3; }
|
||||
</style>
|
||||
|
||||
# Klausurfragen – 223015b
|
||||
**Dateiformate, Schnittstellen, Speichermedien · HdM Stuttgart · M. Czechowski**
|
||||
|
||||
<small>Stand: 02.02.2026</small>
|
||||
|
||||
---
|
||||
|
||||
> **Legende – Moodle XML-Typen:**
|
||||
> `[MC]` = `multichoice` (einzelne Auswahl)
|
||||
> `[MM]` = `multichoice` + `<single>false</single>` (Mehrfachauswahl)
|
||||
> `[MATCH]` = `matching` (Zuordnung)
|
||||
> `[ORDER]` = `ordering` (Reihenfolge)
|
||||
> `[ESSAY]` = `essay` (Freitext, manuell bewertet)
|
||||
> `[SHORTANS]` = `shortanswer` (Stichwort/Satz, automatisch geprüft)
|
||||
> `[NUMERIC]` = `numerical` (Zahlenwert ± Toleranz)
|
||||
> `[CLOZE]` = `cloze` (Lückentext, gemischt)
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK J – Dateiformate: Grundbegriffe
|
||||
|
||||
---
|
||||
|
||||
### J1 – Was bedeutet „komprimieren"?
|
||||
**Thema:** Grundbegriffe – Kompression
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was bedeutet es, eine Datei zu komprimieren?
|
||||
|
||||
- [ ] Die Datei wird auf einem anderen Speichermedium gesichert.
|
||||
- [x] **Die Dateigröße wird durch Entfernung oder Vereinfachung von Daten reduziert.** ✅
|
||||
- [ ] Die Datei wird verschlüsselt, damit sie kleiner aussieht.
|
||||
- [ ] Die Datei wird in ein anderen Format umgewandelt, ohne dass sich die Größe ändert.
|
||||
|
||||
> **Feedback:** Kompression = Dateigröße reduzieren. Zwei Familien: verlustfrei (alle Daten bleiben erhalten, z. B. ZIP, PNG) und verlustbehaftet (Daten werden dauerhaft weggeworfen, z. B. JPEG, MP3).
|
||||
|
||||
---
|
||||
|
||||
### J2 – Verlustfrei vs. verlustbehaftet
|
||||
**Thema:** Grundbegriffe – Kompressionsprimitiven
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Format zu, ob es verlustfrei oder verlustbehaftet komprimiert.
|
||||
|
||||
| Format | Kompressions-Typ |
|
||||
|---|---|
|
||||
| JPEG | Verlustbehaftet |
|
||||
| PNG | Verlustfrei |
|
||||
| MP3 | Verlustbehaftet |
|
||||
| ZIP | Verlustfrei |
|
||||
| FLAC | Verlustfrei |
|
||||
| WebP (lossy) | Verlustbehaftet |
|
||||
|
||||
> **Feedback:** Verlustfrei = Originaldaten perfekt rekonstruierbar (ZIP, PNG, FLAC). Verlustbehaftet = Daten dauerhaft weggeworfen, nicht mehr zurückholbar (JPEG, MP3).
|
||||
|
||||
---
|
||||
|
||||
### J3 – Verlustfrei vs. verlustbehaftet: Erkläre
|
||||
**Thema:** Grundbegriffe – Konzept
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre den Unterschied zwischen verlustfreier und verlustbehafteter Kompression. Nenne je ein konkretes Beispiel und erkläre, warum man in unterschiedlichen Situationen unterschiedliche Kompressionstypen wählt.
|
||||
|
||||
> **Musterlösung:** Verlustfrei: Alle Originaldaten bleiben erhalten – die Datei kann perfekt rekonstruiert werden (z. B. ZIP, PNG). Verlustbehaftet: Daten werden dauerhaft weggeworfen – die Datei kann nicht mehr perfekt hergestellt werden (z. B. JPEG, MP3). Wahl: Fotos fürs Web → JPEG (verlustbehaftet), weil der Unterschied kaum sichtbar ist und die Datei deutlich kleiner wird. Archivierung oder Grafiken → PNG (verlustfrei), weil Qualitätsverlust inakzeptabel wäre.
|
||||
|
||||
---
|
||||
|
||||
### J4 – Was bedeutet „skalieren"?
|
||||
**Thema:** Grundbegriffe – Skalierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was passiert, wenn ein Rasterbild vergrößert wird?
|
||||
|
||||
- [ ] Neue Pixel werden aus dem Dateiformat automatisch geladen.
|
||||
- [x] **Fehlende Pixel müssen durch Interpolation „erfunden" werden – es entsteht keine neue Information.** ✅
|
||||
- [ ] Das Bild wird verlustfrei größer, weil Pixel automatisch duplifiziert werden.
|
||||
- [ ] Die Dateigröße bleibt gleich, nur der Zoom im Betrachter ändert sich.
|
||||
|
||||
> **Feedback:** Ein Rasterbild hat eine native Auflösung. Alles darüber hinaus = Schätzung (Interpolation). Deshalb werden vergrößerte Rasterbilder unscharf – es gibt einfach keine Daten für die fehlenden Pixel.
|
||||
|
||||
---
|
||||
|
||||
### J5 – Was bedeutet „konvertieren"?
|
||||
**Thema:** Grundbegriffe – Konvertierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was bedeutet es, eine Datei zu konvertieren?
|
||||
|
||||
- [ ] Die Datei wird komprimiert und umbenannt.
|
||||
- [x] **Die Daten werden von einem Format in ein anderes umgewandelt (z. B. JPEG → PNG, MP4 → WebM).** ✅
|
||||
- [ ] Die Datei wird verschlüsselt und in ein neues Format gepackt.
|
||||
- [ ] Die Dateiendung wird umbenannt, ohne dass sich der Inhalt ändert.
|
||||
|
||||
> **Feedback:** Konvertierung = Format-Umwandlung. Der Inhalt bleibt inhaltlich gleich, aber die Art der Speicherung (Kompression, Struktur) ändert sich. Wichtig: Eine Dateiendung umzubenennen ist KEINE Konvertierung.
|
||||
|
||||
---
|
||||
|
||||
### J6 – Was bedeutet „codieren" und „decodieren"?
|
||||
**Thema:** Grundbegriffe – Codec-Konzept
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, was „codieren" und „decodieren" bedeuten. Erkläre anschließend, warum der Begriff „Codec" aus beiden Wörtern zusammengesetzt ist, und nenne ein konkretes Beispiel.
|
||||
|
||||
> **Musterlösung:** Codieren = Daten in ein bestimmtes Format umwandeln (z. B. Rohvideodaten → H.264-komprimiertes Video). Decodieren = das Gegenteil: komprimierte Daten wieder in abspielbare Form zurückwandeln (z. B. H.264 → Pixeldaten für den Bildschirm). Codec = Co(der) + Dec(oder) – ein Algorithmus, der beides kann. Beispiel: H.264 ist ein Video-Codec: Der Encoder erzeugt die komprimierte Datei, der Decoder im Player spielt sie wieder ab.
|
||||
|
||||
---
|
||||
|
||||
### J7 – Codec vs. Container
|
||||
**Thema:** Grundbegriffe – Codec/Container-Unterschied
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der Unterschied zwischen einem Container und einem Codec bei Videodateien?
|
||||
|
||||
- [ ] Container und Codec sind synonyme Begriffe für das gleiche Konzept.
|
||||
- [x] **Der Container (z. B. MP4) ist die „Verpackung", die verschiedene Streams zusammenpackt. Der Codec (z. B. H.264) bestimmt, wie der Video-Stream komprimiert wird.** ✅
|
||||
- [ ] Der Codec ist die Dateiendung, der Container der Kompressionsalgorithmus.
|
||||
- [ ] Ein Container enthält immer genau einen Codec – es kann keine Kombination geben.
|
||||
|
||||
> **Feedback:** Container ≠ Codec. Ein MP4-Container kann H.264, H.265 oder AV1 enthalten. Gleiche Endung `.mp4`, unterschiedlicher Inhalt. Der Container packt zusammen (Video, Audio, Untertitel, Metadaten), der Codec komprimiert.
|
||||
|
||||
---
|
||||
|
||||
### J8 – Codec vs. Container: Zuordnung
|
||||
**Thema:** Grundbegriffe – Codec/Container-Zuordnung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne zu: Container oder Codec?
|
||||
|
||||
| Name | Typ |
|
||||
|---|---|
|
||||
| MP4 | Container |
|
||||
| H.264 | Codec |
|
||||
| WebM | Container |
|
||||
| AV1 | Codec |
|
||||
> **Feedback:** Container = Dateiformat, das Streams zusammenpackt (MP4, MKV, WebM). Codec = Kompressionsalgorithmus für einen bestimmten Stream (H.264, AV1, AAC).
|
||||
|
||||
---
|
||||
|
||||
### J9 – Redundanz vs. Irrelevanz
|
||||
**Thema:** Grundbegriffe – Kompressionsprinzipien
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Verlustfreie und verlustbehaftete Kompression arbeiten nach unterschiedlichen Prinzipien. Ordne zu.
|
||||
|
||||
| Prinzip | Kompressionstyp |
|
||||
|---|---|
|
||||
| Redundanz entfernen (wiederholende Muster kompakter darstellen) | Verlustfrei |
|
||||
| Irrelevanz entfernen (für Menschen nicht wahrnehmbar) | Verlustbehaftet |
|
||||
|
||||
> **Feedback:** Der Kernunterschied: Verlustfrei arbeitet mit Redundanz – Wiederholungen werden kompakter gespeichert, aber nichts geht verloren. Verlustbehaftet arbeitet mit Irrelevanz – Daten werden weggeworfen, die Menschen sowieso nicht wahrnehmen können (Psychovisuell bei Bildern, Psychoakustisch bei Audio).
|
||||
|
||||
---
|
||||
|
||||
### J10 – Dateneinheiten: Größenordnungen
|
||||
**Thema:** Grundbegriffe – Speichereinheiten
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die Dateneinheiten von kleinster zu größter:
|
||||
|
||||
1. Byte
|
||||
2. Kilobyte (KB)
|
||||
3. Megabyte (MB)
|
||||
4. Gigabyte (GB)
|
||||
5. Terabyte (TB)
|
||||
6. Petabyte (PB)
|
||||
|
||||
> **Feedback:** Jede Stufe = Faktor 1.000 (SI-Präfixe). Merkhilfe: „Komm Mit Großem Tee, Peter". Ein einzelnes Foto (12 MP, unkomprimiert) ≈ 36 MB. Ein FullHD-Kinofilm ≈ 1 GB. Ein 4K-Film pro Minute unkomprimiert ≈ 44 GB.
|
||||
|
||||
---
|
||||
|
||||
### J11 – Bit und Byte: Umrechnung
|
||||
**Thema:** Grundbegriffe – Bit/Byte-Verhältnis
|
||||
**Punkte:** 1
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Ein Bit ist die kleinste Informationseinheit. Ein Byte besteht aus wie vielen Bit?
|
||||
|
||||
**Lösung:** **8** (±0)
|
||||
|
||||
> **Feedback:** 1 Byte = 8 Bit. Ein Byte kann einen Wert von 0 bis 255 darstellen (2⁸ − 1). Die Unterscheidung Bit/Byte ist fundamental – Bit wird mit kleinem „b" abgekürzt (b), Byte mit großem „B" (B). Deshalb: 1 Mbit/s ≠ 1 MB/s.
|
||||
|
||||
---
|
||||
|
||||
### J12 – 7-Bit ASCII: Wie viele Zeichen?
|
||||
**Thema:** Grundbegriffe – ASCII-Zeichenkodierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Der ASCII-Standard verwendet 7 Bit pro Zeichen. Wie viele verschiedene Zeichen können damit dargestellt werden?
|
||||
|
||||
**Lösung:** **128** (±0)
|
||||
|
||||
> **Feedback:** Bei n Bit gibt es 2ⁿ mögliche Werte. 7 Bit → 2⁷ = 128 Zeichen. Diese umfassen: Ziffern (0–9), Buchstaben (A–Z, a–z), Sonderzeichen und Steuerzeichen. Achtung: Umlaute (ä, ö, ü) sind nicht im ASCII-Sortiment – dafür braucht man z. B. UTF-8.
|
||||
|
||||
---
|
||||
|
||||
### J13 – Hexadezimalzahlen: Zwei 4-Bit-Werte
|
||||
**Thema:** Grundbegriffe – Hexadezimal
|
||||
**Punkte:** 2
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Zwei Hexadezimalzahlen werden jeweils durch 4 Bit dargestellt. Wie viele verschiedene Werte kann eine einzelne Hexadezimalziffer annehmen?
|
||||
|
||||
**Lösung:** **16** (±0)
|
||||
|
||||
> **Feedback:** 4 Bit → 2⁴ = 16 Werte (0–15). Diese werden in Hexadezimal als 0–9 und A–F dargestellt. Zwei Hex-Ziffern zusammen = 8 Bit = 1 Byte → ein Byte lässt sich immer als genau zwei Hex-Ziffern schreiben (z. B. Byte 255 = FF, Byte 10 = 0A).
|
||||
|
||||
---
|
||||
|
||||
### J14 – Ein Pixel, drei Kanäle, 8 Bit
|
||||
**Thema:** Grundbegriffe – Speicherbedarf eines Pixels
|
||||
**Punkte:** 1
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Ein einzelner Pixel wird durch drei Farbkanäle (R, G, B) mit jeweils 8 Bit Farbtiefe gespeichert. Wie viele Byte Informationen enthalten ein solcher Pixel?
|
||||
|
||||
**Lösung:** **3** (±0)
|
||||
|
||||
> **Feedback:** 3 Kanäle × 8 Bit = 24 Bit = 3 Byte pro Pixel. Das entspricht einer 24-Bit-Farbtiefe (True Color). Diese 3 Byte pro Pixel bilden die Basis für jede Speicherberechnung von Rasterbildern: Breite × Höhe × 3 Bytes = Gesamtgröße unkomprimiert.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK K – Bildformate & Raster vs. Vektor
|
||||
|
||||
---
|
||||
|
||||
### K1 – Was ist ein Pixel?
|
||||
**Thema:** Digitale Bilder – Grundbegriffe
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist ein Pixel in einem digitalen Bild?
|
||||
|
||||
- [ ] Ein winziges physisches Kameraobjektiv.
|
||||
- [x] **Ein einzelner Farbpunkt in einem Rasterbild – der kleinste Baustein.** ✅
|
||||
- [ ] Eine Einheit zur Messung der Dateigröße.
|
||||
- [ ] Ein Synonym für eine Farbe im RGB-Farbraum.
|
||||
|
||||
> **Feedback:** Pixel = Picture Element. Ein digitales Rasterbild ist ein 2D-Array aus Pixeln, jeder mit einem Farbwert (z. B. RGB).
|
||||
|
||||
---
|
||||
|
||||
### K2 – Speicherbedarf berechnen
|
||||
**Thema:** Rastergrafiken – Berechnung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[NUMERIC]`
|
||||
|
||||
Ein Bild ist 1920 × 1080 Pixel groß und nutzt 24-Bit-Farbtiefe (True Color). Wie groß ist das Bild unkomprimiert in Megabyte? (Runde auf eine Dezimalstelle)
|
||||
|
||||
**Formel:** Breite × Höhe × (Farbtiefe / 8) = Bytes
|
||||
|
||||
**Lösung:** 1920 × 1080 × 3 = 6.220.800 Bytes ≈ **6,2 MB** (±0,1)
|
||||
|
||||
> **Feedback:** 24 Bit = 3 Bytes pro Pixel (8 Bit pro Kanal: R, G, B). 1920 × 1080 = 2.073.600 Pixel × 3 Bytes = 6.220.800 Bytes. Durch 1.000.000 ≈ 6,2 MB.
|
||||
|
||||
---
|
||||
|
||||
### K3 – Farbtiefe: Bedeutung
|
||||
**Thema:** Rastergrafiken – Farbtiefe
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Farbtiefe ihre Bedeutung zu.
|
||||
|
||||
| Farbtiefe | Bedeutung |
|
||||
|---|---|
|
||||
| 1 Bit | 2 Farben (Schwarz/Weiß) |
|
||||
| 8 Bit | 256 Farben (Graustufen, GIF) |
|
||||
| 24 Bit | 16,7 Millionen Farben (True Color, Standard) |
|
||||
| 32 Bit | 16,7 Millionen Farben + Alpha (Transparenz) |
|
||||
|
||||
> **Feedback:** Bei n Bit gibt es 2ⁿ mögliche Werte. 24 Bit = 8 Bit pro Kanal (R, G, B). 32 Bit = 24 Bit Farbe + 8 Bit Alpha-Kanal für Transparenz.
|
||||
|
||||
---
|
||||
|
||||
### K4 – Was ist Alpha-Transparenz?
|
||||
**Thema:** Rastergrafiken – Transparenz
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was bedeutet ein 32-Bit-Bild gegenüber einem 24-Bit-Bild?
|
||||
|
||||
- [ ] Es hat doppelt so viele Pixel.
|
||||
- [x] **Es hat einen zusätzlichen Alpha-Kanal (8 Bit), der die Transparenz jedes Pixels speichert.** ✅
|
||||
- [ ] Es nutzt eine höhere Auflösung.
|
||||
- [ ] Es kann mehr Dateiformate speichern.
|
||||
|
||||
> **Feedback:** 32 Bit = 24 Bit (RGB) + 8 Bit Alpha. Der Alpha-Kanal bestimmt, wie durchsichtig jeder Pixel ist (0 = vollständig transparent, 255 = vollständig undurchsichtig). Wichtig für PNGs mit Hintergrund-Transparenz.
|
||||
|
||||
---
|
||||
|
||||
### K5 – Raster vs. Vektor: Kern-Unterschied
|
||||
**Thema:** Raster vs. Vektor – Konzept
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der fundamentale Unterschied zwischen Raster- und Vektorgrafiken?
|
||||
|
||||
- [ ] Vektorgrafiken sind immer farbiger als Rastergrafiken.
|
||||
- [x] **Rastergrafiken speichern einzelne Pixel; Vektorgrafiken speichern geometrische Beschreibungen (Pfade, Formen), die beliebig skaliert werden können.** ✅
|
||||
- [ ] Rastergrafiken können keine Farben darstellen, Vektorgrafiken schon.
|
||||
- [ ] Der Unterschied liegt nur in der Dateiendung, nicht im Inhalt.
|
||||
|
||||
> **Feedback:** Raster = „Malen nach Zahlen" (jeder Pixel einzeln). Vektor = „Bauanleitung" (Formen beschreiben). Diese Unterschied bestimmt alles: Skalierung, Dateigröße, Einsatzbereich.
|
||||
|
||||
---
|
||||
|
||||
### K6 – Raster vs. Vektor: Vergleich
|
||||
**Thema:** Raster vs. Vektor – Eigenschaften zuordnen
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Eigenschaft zu: Raster oder Vektor?
|
||||
|
||||
| Eigenschaft | Typ |
|
||||
|---|---|
|
||||
| Skalierung ohne Qualitätsverlust | Vektor |
|
||||
| Ideal für Fotos | Raster |
|
||||
| Dateigröße abhängig von der Auflösung | Raster |
|
||||
| Ideal für Logos und Icons | Vektor |
|
||||
| Speicherung als 2D-Array von Pixeln | Raster |
|
||||
| Dateigröße abhängig von der Komplexität | Vektor |
|
||||
|
||||
> **Feedback:** Raster = Pixel-basiert, auflösungsabhängig, ideal für Fotos. Vektor = Beschreibungs-basiert, beliebig skalierbar, ideal für Grafiken/Logos.
|
||||
|
||||
---
|
||||
|
||||
### K7 – Skalierung: Warum werden Rasterbilder unscharf?
|
||||
**Thema:** Rastergrafiken – Skalierung Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, warum ein Rasterbild beim Vergrößern unscharf wird, während ein Vektorbild bei beliebiger Größe scharf bleibt. Nenne einen konkreten Anwendungsfall, in dem diese Eigenschaft ausschlaggebend ist.
|
||||
|
||||
> **Musterlösung:** Ein Rasterbild hat eine feste Auflösung (eine bestimmte Anzahl von Pixeln). Beim Vergrößern müssen neue Pixel „erfunden" werden (Interpolation) – es gibt keine echten Daten für die fehlenden Stellen → Unschärfe. Ein Vektorbild speichert nur Beschreibungen (Pfade, Formen). Beim Vergrößern werden einfach die Koordinaten skaliert – keine Information geht verloren → immer scharf. Anwendungsfall: Ein Logo auf einer Visitenkarte UND auf einem Plakat → SVG nutzen, damit es bei beliebiger Größe scharf bleibt.
|
||||
|
||||
---
|
||||
|
||||
### K8 – Vektor → Raster: Wie heißt das?
|
||||
**Thema:** Raster vs. Vektor – Konvertierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie heißt der Prozess, bei dem eine Vektorgrafik in eine Rastergrafik umgewandelt wird?
|
||||
|
||||
- [ ] Vektorisierung
|
||||
- [x] **Rasterisierung** ✅
|
||||
- [ ] Pixelierung
|
||||
- [ ] Komprimierung
|
||||
|
||||
> **Feedback:** Rasterisierung = Vektor → Raster (trivial, immer möglich). Der umgekehrte Prozess (Raster → Vektor) heißt „Tracing" und funktioniert oft nur unbefriedigend.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### K9 – Interpolation: Welches Verfahren wofür?
|
||||
**Thema:** Rastergrafiken – Interpolationsverfahren
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Interpolationsverfahren seine Eigenschaft zu.
|
||||
|
||||
| Verfahren | Eigenschaft |
|
||||
|---|---|
|
||||
| Nearest Neighbor | Schnell, pixelig – gut für Pixel-Art |
|
||||
| Bilinear | Glättet, Standard-Verfahren |
|
||||
| Bicubic | Hohe Qualität, rechenintensiver |
|
||||
| Lanczos | Beste Qualität, mathematisch komplex |
|
||||
|
||||
> **Feedback:** Bei der Wahl: Pixel-Art → Nearest Neighbor (soll pixelig bleiben). Normale Bilder → Bilinear oder Bicubic. Maximale Qualität bei Fotos → Lanczos.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK L – JPEG: Innenleben
|
||||
|
||||
---
|
||||
|
||||
### L1 – JPEG: Verlustfrei oder verlustbehaftet?
|
||||
**Thema:** JPEG – Grundeigenschaft
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
JPEG ist ein …
|
||||
|
||||
- [x] **…verlustbehaftetes Bildformat. Beim Speichern werden Daten dauerhaft weggeworfen.** ✅
|
||||
- [ ] …verlustfreies Bildformat wie PNG.
|
||||
- [ ] …Videoformat für Streaming.
|
||||
- [ ] …Vektorgrafik-Format.
|
||||
|
||||
> **Feedback:** JPEG = Joint Photographic Experts Group. Verlustbehaftet: Beim Speichern werden Daten dauerhaft weggeworfen – eine gespeicherte JPEG kann nicht perfekt zum Original zurückgeführt werden. Quality 100 ≠ verlustfrei, nur „wenig wegwerfen".
|
||||
|
||||
---
|
||||
|
||||
### L2 – Psychovisuelle Kompression: Das Auge austricksen
|
||||
**Thema:** JPEG – Wahrnehmungsprinzip
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie nutzt JPEG die Schwächen des menschlichen Auges aus?
|
||||
|
||||
- [ ] Das Auge kann keine Farben wahrnehmen – daher werden Farben komplett entfernt.
|
||||
- [x] **Das Auge sieht Helligkeit besser als Farbe. JPEG behält die Helligkeit (Y) nahezu vollständig, reduziert aber die Farbauflösung (Cb, Cr) – der Verlust wird kaum wahrgenommen.** ✅
|
||||
- [ ] Das Auge kann keine Details sehen – daher werden alle Details entfernt.
|
||||
- [ ] JPEG nutzt keine Wahrnehmungsforschung, komprimiert rein mathematisch.
|
||||
|
||||
> **Feedback:** Psychovisuelle Kompression = Schwächen des Auges ausnutzen. Kern: Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge → Helligkeit sichern, Farbe reduzieren. Der Verlust ist für Menschen kaum sichtbar.
|
||||
|
||||
---
|
||||
|
||||
### L3 – Farbraumkonversion: RGB → YCbCr
|
||||
**Thema:** JPEG Schritt 1 – Farbraum
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Warum wird bei JPEG von RGB in YCbCr konvertiert?
|
||||
|
||||
- [ ] YCbCr nutzt weniger Speicher pro Pixel als RGB.
|
||||
- [x] **In YCbCr sind Helligkeit (Y) und Farbe (Cb, Cr) getrennt – die Farbauflösung kann unabhängig von der Helligkeit reduziert werden.** ✅
|
||||
- [ ] RGB kann keine Transparenz darstellen, YCbCr schon.
|
||||
- [ ] Die Konvertierung ist ein verlustfreier Schritt, der die Dateigröße halbiert.
|
||||
|
||||
> **Feedback:** Y = Helligkeit (Luminanz), Cb/Cr = Farbdifferenzen (Chrominanz). Diese Trennung ermöglicht Chroma Subsampling: Helligkeit voll behalten, Farbe reduzieren – ohne sichtbaren Verlust.
|
||||
|
||||
---
|
||||
|
||||
### L4 – Chroma Subsampling: Was ist 4:2:0?
|
||||
**Thema:** JPEG Schritt 2 – Subsampling
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was bedeutet das Subsampling-Schema 4:2:0?
|
||||
|
||||
- [ ] 4 Pixel teilen sich eine Helligkeit, aber jeder hat eigene Farbe.
|
||||
- [x] **4 Pixel teilen sich einen Farbwert (Chrominanz), aber jeder hat eine eigene Helligkeit (Luminanz). Die Farbauflösung wird auf 25% reduziert.** ✅
|
||||
- [ ] 4:2:0 bedeutet, dass keine Farbe gespeichert wird – nur Graustufen.
|
||||
- [ ] Die Notation beschreibt die Blockgröße, nicht die Farbauflösung.
|
||||
|
||||
> **Feedback:** 4:2:0 = JPEG-Standard. Von 4 Pixeln wird nur 1 Farbwert gespeichert (2×2-Block teilt Farbe), aber jeder Pixel behält seine eigene Helligkeit. Ergebnis: 50% Datenreduktion, kaum sichtbar.
|
||||
|
||||
---
|
||||
|
||||
### L5 – JPEG-Schritte: Richtige Reihenfolge
|
||||
**Thema:** JPEG – Kompressionsablauf
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die Schritte der JPEG-Kompression in der richtigen Reihenfolge:
|
||||
|
||||
1. Farbraumkonversion (RGB → YCbCr)
|
||||
2. Chroma Subsampling
|
||||
3. Block-Aufteilung (8×8)
|
||||
4. DCT (Frequenzanalyse)
|
||||
5. Quantisierung (hier passiert der Verlust!)
|
||||
6. Huffman-Coding (verlustfrei)
|
||||
|
||||
> **Feedback:** Der einzige verlustbehaftete Schritt ist die Quantisierung (Schritt 5). Alles davor bereitet die Daten vor, alles danach komprimiert die Ergebnisse verlustfrei weiter.
|
||||
|
||||
---
|
||||
|
||||
### L6 – Welcher Schritt ist verlustbehaftet?
|
||||
**Thema:** JPEG – Verlust lokalisieren
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Bei welchem Schritt der JPEG-Kompression werden Daten dauerhaft weggeworfen?
|
||||
|
||||
- [ ] Farbraumkonversion (RGB → YCbCr)
|
||||
- [ ] DCT (Discrete Cosine Transform)
|
||||
- [x] **Quantisierung – hier werden unwichtige Frequenzkoeffizienten auf Null gesetzt oder vergröbert.** ✅
|
||||
- [ ] Huffman-Coding
|
||||
|
||||
> **Feedback:** DCT selbst ist verlustfrei und reversibel – es sortiert nur die Daten nach Wichtigkeit. Die Quantisierung ist der einzige verlustbehaftete Schritt: Sie wirft hohe Frequenzen (feine Details) weg. Huffman-Coding danach ist wieder verlustfrei.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L7 – DCT: Was macht sie?
|
||||
**Thema:** JPEG – DCT-Prinzip
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was leitet die DCT (Discrete Cosine Transform) bei JPEG?
|
||||
|
||||
- [ ] Sie komprimiert die Daten verlustbehaftet.
|
||||
- [x] **Sie wandelt 64 Pixelwerte eines 8×8-Blocks in 64 Frequenzkoeffizienten um – sortiert die Information nach Wichtigkeit (niedrige Frequenz = wichtig, hohe Frequenz = Details).** ✅
|
||||
- [ ] Sie verschlüsselt die Daten für sichere Übertragung.
|
||||
- [ ] Sie reduziert die Farbauflösung des Bildes.
|
||||
|
||||
> **Feedback:** DCT = Herzstück von JPEG, aber selbst verlustfrei. Sie sortiert: Der DC-Koeffizient (0,0) = Durchschnittshelligkeit eines Blocks. Die AC-Koeffizienten = Helligkeitsänderungen. 90% der Information steckt in den ersten 10–15 Koeffizienten.
|
||||
|
||||
---
|
||||
|
||||
### L8 – Huffman-Coding: Prinzip
|
||||
**Thema:** JPEG – Huffman
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie funktioniert Huffman-Coding?
|
||||
|
||||
- [ ] Alle Zeichen bekommen gleich lange Codes – einfach und effizient.
|
||||
- [x] **Häufige Werte bekommen kurze Codes, selten vorkommende lange Codes – variable Bitlänge statt fester 8 Bit.** ✅
|
||||
- [ ] Huffman-Coding verschlüsselt die Daten zusätzlich.
|
||||
- [ ] Es funktioniert nur für Texte, nicht für Bilddaten.
|
||||
|
||||
> **Feedback:** Huffman = verlustfrei, optimal für bekannte Häufigkeiten. Präfix-frei: Kein Code ist Anfang eines anderen → eindeutig decodierbar. Auch in ZIP, PNG, MP3 verwendet.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### L9 – JPEG-Artefakte: Benennen
|
||||
**Thema:** JPEG – Artefakte identifizieren
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem JPEG-Artefakt seine Beschreibung zu.
|
||||
|
||||
| Artefakt | Beschreibung |
|
||||
|---|---|
|
||||
| Blocking | 8×8-Blöcke werden sichtbar als Rechteckmuster |
|
||||
| Ringing | „Geister" oder Halos an scharfen Kanten |
|
||||
| Posterization | Farbverläufe werden stufig statt fließend |
|
||||
|
||||
> **Feedback:** Alle drei sind Folgen der Quantisierung. Blocking: Weil jeder 8×8-Block unabhängig komprimiert wird. Ringing: DCT hat Probleme mit harten Kanten (Gibbs-Phänomen). Posterization: Zu wenige Bits für feine Farbabstufungen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK M – Bildformate: PNG, GIF, WebP, SVG
|
||||
|
||||
---
|
||||
|
||||
### M1 – PNG: Verlustfrei oder verlustbehaftet?
|
||||
**Thema:** PNG – Grundeigenschaft
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie komprimiert PNG?
|
||||
|
||||
- [ ] Verlustbehaftet – wie JPEG, aber mit besserer Qualität.
|
||||
- [x] **Verlustfrei – die Originaldaten können perfekt rekonstruiert werden.** ✅
|
||||
- [ ] Gar nicht – PNG speichert Daten unkomprimiert.
|
||||
- [ ] PNG nutzt eine Kombination aus verlustfrei und verlustbehaftet.
|
||||
|
||||
> **Feedback:** PNG nutzt DEFLATE-Kompression (wie ZIP) – verlustfrei. Deshalb ist PNG ideal für Grafiken, Screenshots und Bilder mit Transparenz, aber größer als JPEG für Fotos.
|
||||
|
||||
---
|
||||
|
||||
### M2 – PNG vs. JPEG: Wann was?
|
||||
**Thema:** Bildformate – Formatwahl
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie, wann Sie PNG und wann JPEG wählen würden. Nenne je zwei konkrete Anwendungsfälle und begründen Sie Ihre Wahl.
|
||||
|
||||
> **Musterlösung:** PNG: (1) Screenshots – Texte und Linien bleiben scharf, keine Artefakte. (2) Logos mit Transparenz – PNG unterstützt Alpha-Transparenz, JPEG nicht. JPEG: (1) Fotos fürs Web – deutlich kleiner bei kaum sichtbarem Qualitätsverlust. (2) Social Media – Plattformen re-komprimieren sowieso, PNG würde nur unnötig groß sein.
|
||||
|
||||
---
|
||||
|
||||
### M3 – GIF: Wie viele Farben?
|
||||
**Thema:** GIF – Eigenschaften
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie viele Farben kann ein GIF-Bild gleichzeitig anzeigen?
|
||||
|
||||
- [ ] 16 Farben
|
||||
- [ ] 16,7 Millionen Farben
|
||||
- [x] **256 Farben (8-Bit-Palette)** ✅
|
||||
- [ ] Unbegrenzt – GIF unterstützt alle Farben.
|
||||
|
||||
> **Feedback:** GIF = 8-Bit-Palette = 256 Farben maximal. Deshalb sehen GIF-Bilder bei Fotos oft banding/posterisiert aus. GIF überlebt heute wegen Animationen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### M4 – WebP vs. JPEG: Vorteil?
|
||||
**Thema:** Bildformate – WebP
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der hauptsächliche Vorteil von WebP gegenüber JPEG?
|
||||
|
||||
- [ ] WebP unterstützt Videos, JPEG nicht.
|
||||
- [x] **WebP erzeugt bei gleicher Qualität 25–35% kleinere Dateien als JPEG.** ✅
|
||||
- [ ] WebP ist verlustfrei, JPEG nicht.
|
||||
- [ ] WebP kann keine Fotos speichern, nur Grafiken.
|
||||
|
||||
> **Feedback:** WebP (Google, 2010) kann sowohl lossy als auch lossless komprimieren, unterstützt Transparenz und Animationen. Bei gleicher visueller Qualität sind WebP-Dateien deutlich kleiner als JPEG.
|
||||
|
||||
---
|
||||
|
||||
### M5 – SVG: Was ist es?
|
||||
**Thema:** SVG – Grundbegriff
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist SVG?
|
||||
|
||||
- [ ] Ein verlustbehaftetes Rasterbild-Format wie JPEG.
|
||||
- [x] **Ein Vektorgrafik-Format, das Bilder als geometrische Beschreibungen (XML) speichert – beliebig skalierbar ohne Qualitätsverlust.** ✅
|
||||
- [ ] Ein Video-Container wie MP4.
|
||||
- [ ] Ein komprimiertes Archivformat wie ZIP.
|
||||
|
||||
> **Feedback:** SVG = Scalable Vector Graphics. Web-Standard für Vektorgrafiken. Beschreibt WAS gezeichnet werden soll (`<circle>`, `<rect>`, `<path>`), nicht wie jeder Pixel aussieht. Ideal für Logos, Icons, Illustrationen.
|
||||
|
||||
---
|
||||
|
||||
### M6 – Formatwahl: Szenario zuordnen
|
||||
**Thema:** Bildformate – Formatwahl Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Szenario das optimale Bildformat zu.
|
||||
|
||||
| Szenario | Format |
|
||||
|---|---|
|
||||
| Ein Foto für eine Webseite (klein, OK-Qualität) | JPEG |
|
||||
| Ein Screenshot einer Benutzeroberfläche | PNG |
|
||||
| Ein Logo, das auf allen Bildschirmgrößen scharf sein muss | SVG |
|
||||
| Ein animiertes Reaktionsbild für einen Chat | GIF |
|
||||
|
||||
> **Feedback:** JPEG = Fotos (klein, lossy OK). PNG = Screenshots, Grafiken mit Transparenz (verlustfrei). SVG = Logos, Icons (skalierbar). GIF = Animationen (256 Farben, aber Animations-Support).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK N – Video-Kompression
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N1 – Spatial vs. Temporal Compression
|
||||
**Thema:** Video – Kompressionsprinzipien
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Prinzip seine Beschreibung zu.
|
||||
|
||||
| Prinzip | Beschreibung |
|
||||
|---|---|
|
||||
| Spatial Compression (Intra-Frame) | Komprimiert jedes einzelne Bild für sich (wie JPEG) |
|
||||
| Temporal Compression (Inter-Frame) | Speichert nur die Änderungen zwischen aufeinanderfolgenden Bildern |
|
||||
| Motion Compensation | Beschreibt Bewegung durch Vektoren statt Pixel zu kopieren |
|
||||
|
||||
> **Feedback:** Spatial = räumlich (innerhalb eines Frames). Temporal = zeitlich (zwischen Frames). Motion Compensation = Bewegungsvektoren. 90% eines Frames ist oft identisch mit dem vorherigen – deshalb ist Temporal-Kompression so wirksam.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N2 – I-Frame, P-Frame, B-Frame: Was ist was?
|
||||
**Thema:** Video – Frame-Typen
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Frame-Typ seine Beschreibung zu.
|
||||
|
||||
| Frame-Typ | Beschreibung |
|
||||
|---|---|
|
||||
| I-Frame (Keyframe) | Vollständiges Bild, unabhängig dekodierbar – keine Referenz auf andere Frames |
|
||||
| P-Frame | Nur Änderungen gegenüber vorherigen Frames speichern (~30% der Größe eines I-Frames) |
|
||||
| B-Frame | Änderungen gegenüber vorherigen UND zukünftigen Frames (~15% der Größe eines I-Frames) |
|
||||
|
||||
> **Feedback:** I = Intra (innerhalb). P = Predicted (aus Vergangenheit). B = Bi-directional (Vergangenheit + Zukunft). B-Frames sind am kleinsten, aber brauchen mehr Rechenleistung zum Decodieren.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N3 – Was passiert, wenn ein I-Frame beschädigt ist?
|
||||
**Thema:** Video – I-Frame Bedeutung Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, warum ein I-Frame bei der Videokompression so wichtig ist. Was passiert, wenn ein einzelner I-Frame in einem Videostream beschädigt wird?
|
||||
|
||||
> **Musterlösung:** Ein I-Frame ist ein vollständiges, unabhängig dekodierbare Bild. Alle nachfolgenden P- und B-Frames referenzieren auf vorherige Frames – letztlich auf das letzte I-Frame. Wenn ein I-Frame beschädigt wird, können alle abhängigen P- und B-Frames bis zum nächsten intakten I-Frame nicht mehr korrekt rekonstruiert werden → Videofehler sichtbar bis zum nächsten Keyframe. Deshalb werden typischerweise alle 1–2 Sekunden neue I-Frames eingefügt.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N4 – Motion Compensation: Prinzip
|
||||
**Thema:** Video – Motion Compensation
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was beschreibt ein Motion Vector bei der Videokompression?
|
||||
|
||||
- [ ] Die Helligkeit eines einzelnen Pixels.
|
||||
- [x] **Die Verschiebung eines Bildblocks zwischen zwei Frames (z. B. „verschiebe um +20 Pixel nach rechts").** ✅
|
||||
- [ ] Die Kompressionsrate des gesamten Videos.
|
||||
- [ ] Die Anzahl der Farben in einem Frame.
|
||||
|
||||
> **Feedback:** Motion Compensation speichert Bewegung als Vektoren statt Pixel zu kopieren. Wenn sich ein 16×16-Block von (100,200) auf (120,200) bewegt, wird nur „+20, 0" gespeichert – deutlich kleiner als den Block zweimal zu speichern.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### N5 – Video-Codecs: Zeitstrahl
|
||||
**Thema:** Video – Codecs-Übersicht
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die Video-Codecs nach Veröffentlichungsjahr (alt → neu):
|
||||
|
||||
1. H.264 / AVC (2003)
|
||||
2. H.265 / HEVC (2013)
|
||||
3. VP9 (2013)
|
||||
4. AV1 (2018)
|
||||
|
||||
> **Feedback:** H.264 revolutionierte Streaming. H.265 und VP9 kamen gleichzeitig – H.265 technisch besser, aber Patent-Chaos. AV1 vereint die Industrie: patent-frei, 30% besser als H.265.
|
||||
|
||||
---
|
||||
|
||||
### N6 – AV1: Warum die Zukunft?
|
||||
**Thema:** Video – AV1 Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, warum AV1 als „die Zukunft" der Videokompression gilt. Nenne mindestens zwei konkrete Eigenschaften und erkläre, warum H.265 trotz besserer technischer Kompression nicht die gleiche Dominanz erreicht hat.
|
||||
|
||||
> **Musterlösung:** AV1 (2018) ist royalty-free und open source – die Alliance for Open Media vereint Google, Netflix, Amazon, Apple, Mozilla. Es liefert 30% bessere Kompression als H.265 und unterstützt 8K, HDR, hohe Frame-Rates. H.265 scheitert vor allem am Patent-Chaos: Drei konkurrierende Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) erzeugen rechtliche Unsicherheit und unklare Kosten → viele Unternehmen bleiben bei H.264 oder wechseln direkt zu AV1.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK O – Speichermedien & Schnittstellen
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O1 – KB vs. KiB: Was ist der Unterschied?
|
||||
**Thema:** Speicher – Einheiten
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Eine Festplatte wird als „1 TB" vermarktet, aber Windows zeigt nur ~931 GB an. Warum?
|
||||
|
||||
- [ ] Windows zeigt falsche Werte an – das ist ein Bug.
|
||||
- [x] **Hersteller nutzen dezimale Einheiten (1 TB = 1.000 GB), Windows nutzt binäre Einheiten (1 TiB = 1.024 GiB). Bei TB-Größen entsteht eine ~7% Diskrepanz.** ✅
|
||||
- [ ] Die Festplatte verliert beim Formatieren fast 10% ihrer Kapazität.
|
||||
- [ ] Windows reserviert automatisch 10% als Sicherheitspuffer.
|
||||
|
||||
> **Feedback:** SI (Dezimal): 1 KB = 1.000 Bytes, 1 MB = 1.000 KB. IEC (Binär): 1 KiB = 1.024 Bytes, 1 MiB = 1.024 KiB. Bei 1 TB: 1.000⁴ vs. 1.024⁴ Bytes → ~7% Unterschied. Windows zeigt binäre Werte an, aber mit SI-Bezeichnung (GB statt GiB) → Verwirrung.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O2 – HDD vs. SSD: Kern-Unterschied
|
||||
**Thema:** Speichermedien – HDD vs. SSD
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der fundamentale technische Unterschied zwischen HDD und SSD?
|
||||
|
||||
- [ ] HDDs sind elektronisch, SSDs mechanisch.
|
||||
- [x] **HDDs speichern Daten magnetisch auf sich drehenden Plattern (mechanisch). SSDs nutzen Flash-Speicher (elektronisch, keine beweglichen Teile).** ✅
|
||||
- [ ] Beide Technologien funktionieren identisch, der Unterschied liegt nur im Gehäuse.
|
||||
- [ ] HDDs nutzen Flash-Speicher, SSDs magnetische Platten.
|
||||
|
||||
> **Feedback:** HDD = Hard Disk Drive = mechanisch (Platter, Spindel, Schreib-Lese-Kopf). SSD = Solid State Drive = elektronisch (Flash-Speicher). Diese Unterschied bestimmt alles: Geschwindigkeit, Latenz, Geräusche, Haltbarkeit.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O3 – HDD vs. SSD: Eigenschaften zuordnen
|
||||
**Thema:** Speichermedien – Vergleich
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Eigenschaft zu: HDD oder SSD?
|
||||
|
||||
| Eigenschaft | Typ |
|
||||
|---|---|
|
||||
| Sequentielle Lesgeschwindigkeit ~150 MB/s | HDD |
|
||||
| Sequentielle Lesgeschwindigkeit ~3.500 MB/s | SSD (NVMe) |
|
||||
| Latenz ~10 ms | HDD |
|
||||
| Latenz ~0,02 ms | SSD |
|
||||
| Günstig pro TB (~15€/TB) | HDD |
|
||||
| Ideal für Betriebssystem | SSD |
|
||||
|
||||
> **Feedback:** Der dramatische Unterschied liegt bei Random Access: SSD ~500× schneller. Deshalb: Betriebssystem auf SSD, Archiv auf HDD. Viele nutzen beides: Kleine SSD für System + große HDD für Daten.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O4 – USB-C: Stecker oder Protokoll?
|
||||
**Thema:** Schnittstellen – USB-C
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Ein USB-C-Kabel kann langsam sein, obwohl es wie ein „modernes" Kabel aussieht. Warum?
|
||||
|
||||
- [ ] USB-C-Kabel sind immer gleich schnell – die Geschwindigkeit liegt am Gerät.
|
||||
- [x] **USB-C ist nur ein Steckertyp, kein Protokoll. Ein USB-C-Kabel kann USB 2.0 (480 Mbit/s) bis USB4 (40 Gbit/s) sein – am Stecker nicht erkennbar.** ✅
|
||||
- [ ] USB-C-Kabel werden nach einem Jahr automatisch langsamer.
|
||||
- [ ] Die Geschwindigkeit hängt nur vom Betriebssystem ab.
|
||||
|
||||
> **Feedback:** USB-C = Steckerform. Das Protokoll dahinter kann USB 2.0, 3.2 oder USB4 sein. Ein billiges USB-C-Kabel ist oft nur USB 2.0 mit neuem Stecker. Kabel-Spezifikation prüfen!
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O5 – Dateisysteme: Zuordnung
|
||||
**Thema:** Dateisysteme – Überblick
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Dateisystem seine ideale Anwendung zu.
|
||||
|
||||
| Dateisystem | Ideal für |
|
||||
|---|---|
|
||||
| FAT32 | USB-Sticks, SD-Karten (maximale Kompatibilität) |
|
||||
| NTFS | Windows-Systeme (Journaling, Rechte) |
|
||||
| APFS | macOS, iOS (Snapshots, CoW) |
|
||||
| ext4 | Linux-Systeme (Journaling, stabil) |
|
||||
| exFAT | Große Dateien auf portablen Medien |
|
||||
|
||||
> **Feedback:** FAT32 = kleinster gemeinsamer Nenner, aber max. 4 GB pro Datei. exFAT = FAT32 ohne Größenlimits. NTFS/APFS/ext4 = moderne Systeme mit Journaling. Journaling = bei Absturz werden Änderungen nicht verloren.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O6 – FAT32: Warum nicht für große Dateien?
|
||||
**Thema:** Dateisysteme – FAT32 Limitation
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie versuchen, eine 5-GB-Videodatei auf einen FAT32-formatierten USB-Stick zu kopieren. Was passiert?
|
||||
|
||||
- [ ] Die Datei wird automatisch aufgeteilt in kleinere Teile.
|
||||
- [x] **Der Vorgang fehlschlägt – FAT32 unterstützt keine einzelnen Dateien größer als 4 GB.** ✅
|
||||
- [ ] Die Datei wird automatisch komprimiert, bis sie unter 4 GB ist.
|
||||
- [ ] FAT32 hat keine Dateigrößenbeschränkung.
|
||||
|
||||
> **Feedback:** FAT32-Limit: max. 4 GB pro Datei. Ein 4K-Video oder ISO-Image passt oft nicht. Lösung: USB-Stick mit exFAT oder NTFS formatieren.
|
||||
|
||||
---
|
||||
|
||||
### O7 – Die 3-2-1-Regel
|
||||
**Thema:** Backup – Prinzip
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre die 3-2-1-Regel für Backups. Begründe, warum jede der drei Ziffern wichtig ist.
|
||||
|
||||
> **Musterlösung:** 3 Kopien: Original + 2 Backups. Warum? Das Original kann kaputt gehen, das erste Backup auch – das zweite ist der Sicherheitspuffer. 2 verschiedene Medientypen (z. B. SSD + HDD, oder lokal + Cloud). Warum? Gleiche Medien haben gleiche Schwachstellen (z. B. Batch-Fehler bei HDDs derselben Charge). 1 Kopie an einem anderen Ort (Cloud, anderes Gebäude). Warum? Brand oder Wasserschaden zerstört alles vor Ort; Ransomware verschlüsselt alle angeschlossenen Laufwerke gleichzeitig.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### O8 – Backup-Arten: Unterschiede
|
||||
**Thema:** Backup – Typen
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Backup-Typ seine Beschreibung zu.
|
||||
|
||||
| Backup-Typ | Beschreibung |
|
||||
|---|---|
|
||||
| Full (Vollständig) | Kompletter Datenbestand jedes Mal – einfach, aber langsam und platzhungrig |
|
||||
| Inkrementell | Nur Änderungen seit dem letzten Backup (egal welcher Art) – schnell, aber Wiederherstellung komplex |
|
||||
| Differenziell | Änderungen seit dem letzten Voll-Backup – Mittelweg zwischen beiden |
|
||||
|
||||
> **Feedback:** Typisches Schema: Sonntag Full, Mo–Sa Inkrementell oder Differenziell. Inkrementell = schnellstes Backup, langsamste Wiederherstellung (Kette aufbauen). Full = langsamstes Backup, schnellste Wiederherstellung.
|
||||
@@ -68,6 +68,33 @@ section.aufgabe {
|
||||
section.aufgabe footer {
|
||||
display: none;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: linear-gradient(180deg, #fff8fa 0%, #fef0f4 100%) !important;
|
||||
border-left: 6px solid #a02060;
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.6rem;
|
||||
color: #a02060;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
section.erklaerung h2 {
|
||||
font-size: 1.3rem;
|
||||
color: #1f2937;
|
||||
margin-top: 0;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.5;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.95rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
@@ -652,6 +679,26 @@ PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Die 5 Komponenten: Erklaerung
|
||||
|
||||
**Definition:** Die Von-Neumann-Architektur beschreibt den grundlegenden Aufbau moderner Computer in fuenf Funktionseinheiten.
|
||||
|
||||
| Komponente | Aufgabe | Beispiel |
|
||||
|------------|---------|----------|
|
||||
| **Rechenwerk (ALU)** | Arithmetische & logische Operationen | +, -, ×, ÷, Vergleiche |
|
||||
| **Steuerwerk** | Holt, dekodiert und steuert Befehle | Fetch-Decode-Execute-Zyklus |
|
||||
| **Speicherwerk** | Speichert Programme UND Daten | RAM, ROM |
|
||||
| **Ein-/Ausgabe** | Kommunikation mit Aussenwelt | Tastatur, Monitor, USB |
|
||||
| **Bus-System** | Verbindet alle Komponenten | Adress-, Daten-, Steuerbus |
|
||||
|
||||
**Merkhilfe:** "**R**echnen, **S**teuern, **S**peichern, **E**in/**A**us, **B**us" (RSSEAB)
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -689,6 +736,27 @@ PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beis
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Von-Neumann-Architektur: Erklaerung
|
||||
|
||||
**Definition:** Das revolutionaere Prinzip, dass Programme und Daten im selben Speicher liegen und Programme somit wie Daten behandelt werden koennen.
|
||||
|
||||
**Kernpunkte:**
|
||||
- **Stored Program Concept:** Programme sind austauschbare Daten
|
||||
- **Universalrechner:** Gleiche Hardware fuer beliebige Aufgaben
|
||||
- **Software-Flexibilitaet:** Programme koennen geladen, geaendert und geloescht werden
|
||||
|
||||
**Vorher (ENIAC):** Programmierung durch Umstecken von Kabeln → Tage fuer jedes neue Programm
|
||||
|
||||
**Nachher:** Software als austauschbare Datei → Betriebssysteme, Apps, Updates moeglich
|
||||
|
||||
**Harvard-Architektur (Alternative):** Getrennter Speicher fuer Code und Daten → schneller, aber weniger flexibel (Arduino, DSPs)
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Vom Militär zum Netz
|
||||
@@ -1117,6 +1185,30 @@ PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTML Metadaten: Erklaerung
|
||||
|
||||
**Definition:** Der `<head>`-Bereich enthaelt Informationen ueber das Dokument, die nicht direkt im Browser angezeigt werden.
|
||||
|
||||
| Meta-Tag | Zweck | Beispiel |
|
||||
|----------|-------|----------|
|
||||
| `<title>` | Browser-Tab, Lesezeichen, SEO | "Meine Website" |
|
||||
| `<meta charset>` | Zeichenkodierung | UTF-8 fuer Umlaute |
|
||||
| `<meta description>` | Suchmaschinen-Snippet | Max. 160 Zeichen |
|
||||
| `<meta viewport>` | Mobile Darstellung | width=device-width |
|
||||
| `<meta og:image>` | Social Media Vorschau | Bild beim Teilen |
|
||||
|
||||
**Wichtige Unterscheidung:**
|
||||
- `<head>`: Metadaten (fuer Browser, Suchmaschinen, Social Media)
|
||||
- `<body>`: Sichtbarer Inhalt (fuer Menschen)
|
||||
|
||||
**Merkhilfe:** "Head = Gehirn (unsichtbar), Body = Koerper (sichtbar)"
|
||||
|
||||
---
|
||||
|
||||
# HTML-Tags und Attribute
|
||||
|
||||
```html
|
||||
@@ -1340,6 +1432,29 @@ PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Web-Nutzung: Erklaerung
|
||||
|
||||
**Definition:** Menschen nutzen das Web auf sehr unterschiedliche Weisen - nicht nur mit Maus und Bildschirm.
|
||||
|
||||
**Eingabemethoden:**
|
||||
- **Maus/Trackpad:** Klicken, Scrollen, Hover
|
||||
- **Tastatur:** Tab-Navigation, Shortcuts, Pfeiltasten
|
||||
- **Screenreader:** Vorlesen von Inhalten (NVDA, VoiceOver, JAWS)
|
||||
- **Sprache/Augen:** Sprachbefehle, Eye-Tracking, Switch-Geraete
|
||||
|
||||
**Arten von Einschraenkungen:**
|
||||
- **Permanent:** Blindheit, Taubheit, motorische Einschraenkungen
|
||||
- **Temporaer:** Gebrochener Arm, Augen-OP
|
||||
- **Situativ:** Sonnenlicht, laute Umgebung, Baby auf Arm
|
||||
|
||||
**Merkhilfe:** "a11y" = a + 11 Buchstaben + y = "accessibility"
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -1379,6 +1494,28 @@ PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Barrierefreiheit: Erklaerung
|
||||
|
||||
**Definition:** Barrierefreiheit (Accessibility) bedeutet, dass digitale Inhalte fuer alle Menschen zugaenglich sind - unabhaengig von koerperlichen oder technischen Einschraenkungen.
|
||||
|
||||
**Rechtlicher Rahmen:**
|
||||
- **European Accessibility Act (EAA):** Seit Juni 2025 EU-weit verpflichtend
|
||||
- **BITV 2.0:** Deutsche Verordnung fuer oeffentliche Stellen
|
||||
- **Strafen:** Bis zu 100.000 EUR Bussgeld moeglich
|
||||
|
||||
**Curb-Cut-Effekt:** Massnahmen fuer Menschen mit Behinderung helfen allen:
|
||||
- Untertitel → laute Umgebung, Sprachlernen
|
||||
- Kontrast → Sonnenlicht, aeltere Menschen
|
||||
- Tastatur-Navigation → Power-User, RSI-Betroffene
|
||||
|
||||
**Business Case:** ~15% Menschen mit Behinderung + ~20% Aeltere = 35% potenzielle Zielgruppe
|
||||
|
||||
---
|
||||
|
||||
# WCAG: Der Standard
|
||||
|
||||
**W**eb **C**ontent **A**ccessibility **G**uidelines
|
||||
@@ -1532,6 +1669,32 @@ Echte NutzerInnen einbeziehen = Gold-Standard
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Barrieren vermeiden: Erklaerung
|
||||
|
||||
**Definition:** Praktische Massnahmen zur Pruefung und Sicherstellung der Barrierefreiheit von Webseiten.
|
||||
|
||||
**Tastatur-Test (selbst durchfuehren):**
|
||||
1. Tab druecken → Springt der Fokus logisch durch die Seite?
|
||||
2. Ist der fokussierte Bereich immer sichtbar markiert?
|
||||
3. Kann man alle Funktionen ohne Maus bedienen?
|
||||
|
||||
**Screenreader-Test:**
|
||||
- **Mac:** VoiceOver aktivieren mit `Cmd + F5`
|
||||
- **Windows:** NVDA installieren (kostenlos)
|
||||
- **Frage:** Ergibt die vorgelesene Seite Sinn?
|
||||
|
||||
**Automatische Tools (finden ~30% der Probleme):**
|
||||
- axe DevTools, WAVE (Browser-Extensions)
|
||||
- Lighthouse (in Chrome DevTools unter F12)
|
||||
|
||||
**Merkhilfe WCAG-Prinzipien:** "**P**erceivable, **O**perable, **U**nderstandable, **R**obust" (POUR)
|
||||
|
||||
---
|
||||
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
|
||||
@@ -71,6 +71,33 @@ section.aufgabe footer {
|
||||
section.glossar {
|
||||
font-size: 1.4rem;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: linear-gradient(180deg, #fff8fa 0%, #fef0f4 100%) !important;
|
||||
border-left: 6px solid #a02060;
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.6rem;
|
||||
color: #a02060;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
section.erklaerung h2 {
|
||||
font-size: 1.3rem;
|
||||
color: #1f2937;
|
||||
margin-top: 0;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.5;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.95rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
@@ -402,6 +429,29 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# TCP/IP-Modell: Erklaerung
|
||||
|
||||
**Definition:** Das TCP/IP-Modell beschreibt die Kommunikation im Internet in vier hierarchischen Schichten.
|
||||
|
||||
| Schicht | Frage | Protokolle | Dateneinheit |
|
||||
|---------|-------|------------|--------------|
|
||||
| 4 Anwendung | Was will ich? | HTTP, DNS, SMTP | Daten |
|
||||
| 3 Transport | Kommt es an? | TCP, UDP | Segment |
|
||||
| 2 Internet | Welcher Rechner? | IP | Paket |
|
||||
| 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN | Frame |
|
||||
|
||||
**Kernprinzip:** Jede Schicht hat eine Aufgabe und kennt nur ihre Nachbarschichten.
|
||||
|
||||
**Encapsulation:** Jede Schicht verpackt die Daten der darueberliegenden Schicht mit eigenem Header.
|
||||
|
||||
**Merkhilfe Schichten:** "**A**lle **T**rinken **I**mmer **N**och" (Anwendung-Transport-Internet-Netzzugang)
|
||||
|
||||
---
|
||||
|
||||
# Schichten verpacken Daten
|
||||
|
||||
```
|
||||
@@ -461,6 +511,30 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Dateneinheiten: Erklaerung
|
||||
|
||||
**Definition:** Jede Schicht im TCP/IP-Modell hat eine eigene Bezeichnung fuer die Daten, die sie verarbeitet.
|
||||
|
||||
| Schicht | Dateneinheit | Was kommt hinzu? |
|
||||
|---------|--------------|------------------|
|
||||
| Anwendung | **Daten** (Message) | Anwendungsspezifische Infos |
|
||||
| Transport | **Segment** | Ports, Sequenznummern |
|
||||
| Internet | **Paket** | IP-Adressen (Quelle, Ziel) |
|
||||
| Netzzugang | **Frame** | MAC-Adressen, Pruefsumme |
|
||||
|
||||
**Encapsulation-Prozess:**
|
||||
```
|
||||
Daten → [TCP-Header + Daten] → [IP-Header + Segment] → [Eth-Header + Paket + Eth-Trailer]
|
||||
```
|
||||
|
||||
**Merkhilfe:** "**D**er **S**ache **P**raktischer **F**olgen" (Daten-Segment-Paket-Frame, von oben nach unten)
|
||||
|
||||
---
|
||||
|
||||
# Warum ist das clever?
|
||||
|
||||
**Ohne Schichten:**
|
||||
@@ -640,6 +714,29 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# IP vs. MAC vs. Port: Erklaerung
|
||||
|
||||
**Definition:** Drei verschiedene Adresstypen fuer drei verschiedene Fragen im Netzwerk.
|
||||
|
||||
| Adresstyp | Frage | Reichweite | Aendert sich? |
|
||||
|-----------|-------|------------|---------------|
|
||||
| **IP-Adresse** | Welcher Rechner im Internet? | Global | Nein (Ziel bleibt) |
|
||||
| **MAC-Adresse** | Welches Geraet nebenan? | Lokal (1 Hop) | Ja, bei jedem Hop |
|
||||
| **Port** | Welches Programm? | Auf einem Rechner | Nein |
|
||||
|
||||
**Analogie Briefpost:**
|
||||
- **IP** = Empfaengeradresse auf dem Brief (bleibt gleich)
|
||||
- **MAC** = "Naechstes Postamt" (aendert sich bei jeder Station)
|
||||
- **Port** = Wohnungsnummer im Mehrfamilienhaus
|
||||
|
||||
**Merkhilfe:** "**I**P = **I**nternet-weit, **M**AC = **M**omentaner Nachbar, **P**ort = **P**rogramm"
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Die Reise eines Klicks
|
||||
@@ -922,6 +1019,31 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# 3-Way-Handshake: Erklaerung
|
||||
|
||||
**Definition:** Der TCP-Verbindungsaufbau in drei Schritten, bei dem Client und Server ihre Sequenznummern austauschen.
|
||||
|
||||
**Die drei Schritte:**
|
||||
1. **SYN** (Client → Server): "Ich will reden, starte bei Seq=1000"
|
||||
2. **SYN-ACK** (Server → Client): "OK, ich starte bei Seq=5000, erwarte 1001"
|
||||
3. **ACK** (Client → Server): "Verstanden, erwarte 5001 - los geht's!"
|
||||
|
||||
**Warum so kompliziert?**
|
||||
- Beide Seiten muessen **bereit** sein
|
||||
- Sequenznummern werden **synchronisiert** (daher SYN)
|
||||
- Verlorene Pakete koennen spaeter **erkannt und nachgefordert** werden
|
||||
|
||||
**Analogie Telefonat:**
|
||||
- Klingeln → Abheben → "Hallo?" → Gespraech beginnt
|
||||
|
||||
**Merkhilfe:** "**S**ag mir → **S**icher, **A**ntworte → **A**lles klar" (SYN → SYN-ACK → ACK)
|
||||
|
||||
---
|
||||
|
||||
# Nach dem Handshake
|
||||
|
||||
**Status:** Die TCP-Verbindung steht.
|
||||
@@ -1429,6 +1551,31 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# TCP vs. UDP: Erklaerung
|
||||
|
||||
**Definition:** Die zwei Transport-Protokolle mit unterschiedlichen Garantien und Anwendungsfaellen.
|
||||
|
||||
| Eigenschaft | TCP | UDP |
|
||||
|-------------|-----|-----|
|
||||
| Verbindungsaufbau | Ja (3-Way-Handshake) | Nein |
|
||||
| Reihenfolge | Garantiert | Nicht garantiert |
|
||||
| Verlorene Pakete | Werden nachgefordert | Gehen verloren |
|
||||
| Geschwindigkeit | Langsamer (Overhead) | Schneller |
|
||||
|
||||
**Wann TCP?** Wenn **alles ankommen** muss:
|
||||
- Web (HTTP/HTTPS), E-Mail, Datei-Downloads
|
||||
|
||||
**Wann UDP?** Wenn **Geschwindigkeit** wichtiger ist als Vollstaendigkeit:
|
||||
- Video-Calls, Gaming, DNS, Streaming
|
||||
|
||||
**Merkhilfe:** "**T**CP = **T**otal **C**omplete **P**ackages" vs. "**U**DP = **U**nsicher, **D**afuer **P**rompt"
|
||||
|
||||
---
|
||||
|
||||
# Warum UDP bei Video-Calls?
|
||||
|
||||
**Szenario:** Ein Paket geht verloren.
|
||||
@@ -1508,6 +1655,30 @@ Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTTP-Methoden: Erklaerung
|
||||
|
||||
**Definition:** HTTP-Methoden beschreiben die gewuenschte Aktion auf einer Ressource.
|
||||
|
||||
| Methode | Bedeutung | Typischer Einsatz |
|
||||
|---------|-----------|-------------------|
|
||||
| **GET** | Daten abrufen | Webseite laden, Bild anzeigen |
|
||||
| **POST** | Daten senden | Formular absenden, Login |
|
||||
| **PUT** | Daten ersetzen | Profil komplett aktualisieren |
|
||||
| **PATCH** | Daten teilweise aendern | Einzelnes Feld aendern |
|
||||
| **DELETE** | Daten loeschen | Account loeschen |
|
||||
|
||||
**Idempotenz:** GET, PUT, DELETE koennen mehrfach ausgefuehrt werden mit gleichem Ergebnis. POST nicht (mehrfach absenden = mehrere Bestellungen).
|
||||
|
||||
**REST-APIs:** Nutzen diese Methoden systematisch fuer CRUD-Operationen (Create, Read, Update, Delete).
|
||||
|
||||
**Merkhilfe:** "**G**ib mir, **P**oste das, **P**latziere neu, **D**elete" (GET, POST, PUT, DELETE)
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -1543,6 +1714,31 @@ Status-Codes sagen euch, was passiert ist.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTTP Status-Codes: Erklaerung
|
||||
|
||||
**Definition:** Dreistellige Codes, die der Server zurueckgibt, um das Ergebnis einer Anfrage zu beschreiben.
|
||||
|
||||
| Bereich | Bedeutung | Wichtige Codes |
|
||||
|---------|-----------|----------------|
|
||||
| **2xx** | Erfolg | 200 OK, 201 Created, 204 No Content |
|
||||
| **3xx** | Umleitung | 301 Moved Permanently, 304 Not Modified |
|
||||
| **4xx** | Client-Fehler | 400 Bad Request, 403 Forbidden, 404 Not Found |
|
||||
| **5xx** | Server-Fehler | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
|
||||
|
||||
**Haeufigste Codes im Alltag:**
|
||||
- **200:** Alles OK, hier sind die Daten
|
||||
- **404:** Seite nicht gefunden (falsche URL)
|
||||
- **403:** Zugriff verweigert (keine Berechtigung)
|
||||
- **500:** Server hat einen Fehler (nicht eure Schuld)
|
||||
|
||||
**Merkhilfe:** "**2**=alles **g**ut, **3**=woanders, **4**=du Fehler, **5**=Server Fehler"
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -1579,6 +1775,34 @@ Wie Encapsulation funktioniert.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Netzwerke Zusammenfassung: Erklaerung
|
||||
|
||||
**Der Ablauf eines Webseitenaufrufs:**
|
||||
1. **DNS** (UDP:53): Domain → IP-Adresse aufloesen
|
||||
2. **TCP-Handshake:** SYN → SYN-ACK → ACK (Verbindung aufbauen)
|
||||
3. **HTTP-Request:** GET /index.html (Seite anfordern)
|
||||
4. **HTTP-Response:** 200 OK + HTML (Seite erhalten)
|
||||
|
||||
**Die 4 Schichten (TCP/IP):**
|
||||
|
||||
| Schicht | Protokolle | Dateneinheit |
|
||||
|---------|------------|--------------|
|
||||
| Anwendung | HTTP, DNS | Daten |
|
||||
| Transport | TCP, UDP | Segment |
|
||||
| Internet | IP | Paket |
|
||||
| Netzzugang | Ethernet | Frame |
|
||||
|
||||
**Merkhilfen:**
|
||||
- Schichten: "**A**lle **T**rinken **I**mmer **N**och"
|
||||
- Dateneinheiten: "**D**er **S**ache **P**raktischer **F**olgen"
|
||||
- IP bleibt gleich, MAC aendert sich bei jedem Hop
|
||||
|
||||
---
|
||||
|
||||
# Werkzeuge zum Selbst-Erkunden
|
||||
|
||||
**Im Browser (F12 → Network-Tab):**
|
||||
@@ -1870,6 +2094,33 @@ Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# CSS Spezifitaet: Erklaerung
|
||||
|
||||
**Definition:** Spezifitaet bestimmt, welche CSS-Regel gewinnt, wenn mehrere Regeln auf dasselbe Element zutreffen.
|
||||
|
||||
**Spezifitaet als 4-stellige Zahl (a,b,c,d):**
|
||||
|
||||
| Kategorie | Gewicht | Beispiel |
|
||||
|-----------|---------|----------|
|
||||
| **a:** Inline-Style | 1,0,0,0 | `style="..."` |
|
||||
| **b:** ID | 0,1,0,0 | `#header` |
|
||||
| **c:** Klasse, Attribut, Pseudo-Klasse | 0,0,1,0 | `.wichtig`, `:hover` |
|
||||
| **d:** Element, Pseudo-Element | 0,0,0,1 | `p`, `::before` |
|
||||
|
||||
**Vergleich:** Von links nach rechts, hoehere Zahl gewinnt.
|
||||
- 0,1,0,0 > 0,0,99,99 (eine ID schlaegt beliebig viele Klassen)
|
||||
|
||||
**Praktische Tipps:**
|
||||
- Vermeide IDs in CSS (zu spezifisch)
|
||||
- Vermeide `!important` (bricht das System)
|
||||
- Nutze Klassen fuer wiederverwendbare Styles
|
||||
|
||||
---
|
||||
|
||||
# Box-Modell
|
||||
|
||||
```
|
||||
@@ -2117,6 +2368,39 @@ Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Responsive Design: Erklaerung
|
||||
|
||||
**Definition:** Webseiten passen sich automatisch an verschiedene Bildschirmgroessen an (Desktop, Tablet, Smartphone).
|
||||
|
||||
**Mobile First Ansatz:**
|
||||
1. Basis-CSS fuer kleine Bildschirme schreiben
|
||||
2. Mit `@media (min-width: ...)` fuer groessere Bildschirme erweitern
|
||||
|
||||
```css
|
||||
/* Basis (Mobile) */
|
||||
.container { padding: 1rem; }
|
||||
|
||||
/* Ab 768px (Tablet) */
|
||||
@media (min-width: 768px) { .container { padding: 2rem; } }
|
||||
|
||||
/* Ab 1024px (Desktop) */
|
||||
@media (min-width: 1024px) { .container { max-width: 1200px; } }
|
||||
```
|
||||
|
||||
**Typische Breakpoints:**
|
||||
- **576px:** Kleine Smartphones
|
||||
- **768px:** Tablets
|
||||
- **1024px:** Desktop
|
||||
- **1200px:** Grosse Bildschirme
|
||||
|
||||
**Merkhilfe:** "Mobile First" = Basis klein, dann groesser werden
|
||||
|
||||
---
|
||||
|
||||
# Zusammenfassung CSS
|
||||
|
||||
**Selektoren:**
|
||||
|
||||
@@ -0,0 +1,938 @@
|
||||
---
|
||||
marp: true
|
||||
theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Klausurfragen – 223015c"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
title: "Klausurfragen – Grundlagen IT- und Internettechnik"
|
||||
---
|
||||
<style>
|
||||
:root {
|
||||
--color-foreground: #1a1a2e;
|
||||
--color-highlight: #d63384;
|
||||
--color-dimmed: #4a4a6a;
|
||||
}
|
||||
section.invert { --color-foreground: #fff; }
|
||||
section { font-size: 1.325rem; }
|
||||
h1 { color: #a02060; }
|
||||
section.invert h1 { color: #fff; }
|
||||
h2 { color: #1f2937; }
|
||||
pre { background: #0f0f23; border-radius: 8px; }
|
||||
pre code { background: transparent; color: inherit; }
|
||||
a { color: var(--color-highlight); }
|
||||
section.disable { opacity: 0.3; }
|
||||
</style>
|
||||
|
||||
# Klausurfragen – 223015c
|
||||
**Grundlagen IT- und Internettechnik · HdM Stuttgart · M. Czechowski**
|
||||
|
||||
<small>Stand: 02.02.2026</small>
|
||||
|
||||
---
|
||||
|
||||
> **Legende – Moodle XML-Typen:**
|
||||
> `[MC]` = `multichoice` (einzelne Auswahl)
|
||||
> `[MM]` = `multichoice` + `<single>false</single>` (Mehrfachauswahl)
|
||||
> `[MATCH]` = `matching` (Zuordnung)
|
||||
> `[ORDER]` = `ordering` (Reihenfolge)
|
||||
> `[ESSAY]` = `essay` (Freitext, manuell bewertet)
|
||||
> `[SHORTANS]` = `shortanswer` (Stichwort/Satz, automatisch geprüft)
|
||||
> `[NUMERIC]` = `numerical` (Zahlenwert ± Toleranz)
|
||||
> `[CLOZE]` = `cloze` (Lückentext, gemischt)
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK A – Von-Neumann-Architektur
|
||||
|
||||
---
|
||||
|
||||
### A1 – Komponenten zuordnen
|
||||
**Thema:** Von-Neumann Grundstruktur
|
||||
**Punkte:** 3
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Komponente der Von-Neumann-Architektur ihre Funktion zu.
|
||||
|
||||
| Komponente | Funktion |
|
||||
|---|---|
|
||||
| Rechenwerk (ALU) | Führt arithmetische und logische Operationen durch |
|
||||
| Steuerwerk | Holt, dekodiert und steuert die Ausführung von Befehlen |
|
||||
| Speicherwerk | Enthält sowohl Programme als auch Daten |
|
||||
| Ein-/Ausgabe | Schnittstelle zu externen Geräten (Tastatur, Bildschirm, Netzwerk) |
|
||||
| Bus-System | Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus |
|
||||
|
||||
> **Feedback:** Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### A2 – Welche Komponente ist das?
|
||||
**Thema:** Von-Neumann – einzelne Komponente identifizieren
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Ein Programm besteht aus einer Folge von Befehlen. Eine Komponente der Von-Neumann-Architektur ist für das Abrufen, Dekodieren und Ausführen dieser Befehle zuständig. Welche?
|
||||
|
||||
- [ ] Rechenwerk (ALU)
|
||||
- [x] **Steuerwerk** ✅
|
||||
- [ ] Speicherwerk
|
||||
- [ ] Ein-/Ausgabe
|
||||
|
||||
> **Feedback:** Das Steuerwerk (Control Unit) orchestriert den Fetch-Decode-Execute-Zyklus – es ist der „Dirigent" der CPU.
|
||||
|
||||
---
|
||||
|
||||
### A3 – Von-Neumann: Was wird ermöglicht?
|
||||
**Thema:** Von-Neumann – Bedeutung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MM]` (Mehrfachauswahl)
|
||||
|
||||
Welche der folgenden Aussagen werden durch die Von-Neumann-Architektur ermöglicht? (Mehrere Antworten möglich)
|
||||
|
||||
- [x] **Betriebssysteme können verschiedene Programme aus dem Speicher laden.** ✅
|
||||
- [x] **Apps können ohne Hardwareänderung installiert werden.** ✅
|
||||
- [ ] Der Computer kann nur ein einziges Programm gleichzeitig ausführen.
|
||||
- [x] **Multitasking wird möglich.** ✅
|
||||
- [ ] Die Hardware muss für jedes neue Programm physisch umgebaut werden.
|
||||
- [x] **Software kann aktualisiert werden, ohne die Hardware zu ändern.** ✅
|
||||
|
||||
> **Feedback:** Kern der Von-Neumann-Architektur: Programme und Daten teilen denselben Speicher → Programme sind austauschbare Daten. Ohne das: kein Betriebssystem, keine Apps, kein Multitasking, keine Updates.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK B – Netzwerk-Grundlagen (TCP/IP)
|
||||
|
||||
---
|
||||
|
||||
### B1 – Protokoll → TCP/IP-Schicht zuordnen
|
||||
**Thema:** TCP/IP-Schichtmodell – Zuordnung
|
||||
**Punkte:** 3
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.
|
||||
|
||||
| Protokoll | Schicht |
|
||||
|----------|---|
|
||||
| HTTP | Anwendung |
|
||||
| DNS | Anwendung |
|
||||
| TCP | Transport |
|
||||
| UDP | Transport |
|
||||
| IP | Internet |
|
||||
| Ethernet | Netzzugang |
|
||||
| WLAN | Netzzugang |
|
||||
|
||||
> **Feedback:** Anwendung: HTTP, DNS, SMTP, FTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.
|
||||
|
||||
---
|
||||
|
||||
### B2 – Welche Schicht ist das? (einzeln)
|
||||
**Thema:** TCP/IP – einzelne Schicht identifizieren
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Das Protokoll IP arbeitet auf welcher TCP/IP-Schicht?
|
||||
|
||||
- [ ] Anwendung
|
||||
- [ ] Transport
|
||||
- [x] **Internet** ✅
|
||||
- [ ] Netzzugang
|
||||
|
||||
> **Feedback:** IP (Internet Protocol) arbeitet auf der Internet-Schicht – dort werden Pakete adressiert und geroutet.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### B3 – Schicht-Funktion beschreiben
|
||||
**Thema:** TCP/IP – Funktionen der Schichten
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Beschreibe in einem Satz pro Schicht die Hauptfunktion jeder der vier TCP/IP-Schichten (Anwendung, Transport, Internet, Netzzugang).
|
||||
|
||||
> **Musterlösung:** Anwendung: Stellt Protokolle für spezifische Dienste bereit (HTTP für Web, SMTP für Mail). Transport: Sorgt für zuverlässige (TCP) oder schnelle (UDP) Übertragung zwischen zwei Endpunkten. Internet: Adressiert und routet Pakete über Netzwerkgrenzen hinweg mittels IP. Netzzugang: Übertragen von Frames auf einem physischen Übertragungsweg (Ethernet, WLAN).
|
||||
|
||||
---
|
||||
|
||||
### B4 – Was ist eine MAC-Adresse?
|
||||
**Thema:** MAC-Adresse – Konzept
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was identifiziert eine MAC-Adresse?
|
||||
|
||||
- [ ] Den konkreten Dienst (z. B. Webserver) auf einem Computer.
|
||||
- [ ] Den Computer im globalen Internet über Netzwerkgrenzen hinweg.
|
||||
- [x] **Die Netzwerkkarte eines Geräts auf einem lokalen Netzwerksegment.** ✅
|
||||
- [ ] Die Routen, die ein Paket durch das Internet nimmt.
|
||||
|
||||
> **Feedback:** MAC = Media Access Control. Sie ist eine 48-Bit-Adresse, die einer Netzwerkkarte ab Werk zugewiesen wird – lokal, ein Hop.
|
||||
|
||||
---
|
||||
|
||||
### B5 – Was ist eine IP-Adresse?
|
||||
**Thema:** IP-Adresse – Konzept
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was identifiziert eine IP-Adresse?
|
||||
|
||||
- [ ] Die Netzwerkkarte eines Geräts auf einem lokalen Segment.
|
||||
- [x] **Ein Gerät (Host) im globalen Internet – sie ermöglicht das Routing über Netzwerkgrenzen.** ✅
|
||||
- [ ] Den Dienst, der auf einem bestimmten Port läuft.
|
||||
- [ ] Die physische Leitung zwischen zwei Computern.
|
||||
|
||||
> **Feedback:** IP = Internet Protocol. Die IP-Adresse ist der globale „Hausnummer" eines Geräts – routing-tauglich, im Gegensatz zur lokalen MAC-Adresse.
|
||||
|
||||
---
|
||||
|
||||
### B6 – Was ist eine Port-Nummer?
|
||||
**Thema:** Port – Konzept
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wozu dient eine Port-Nummer auf dem Zielrechner?
|
||||
|
||||
- [ ] Sie bestimmt die Geschwindigkeit der Verbindung.
|
||||
- [ ] Sie identifiziert das Gerät im Netzwerk.
|
||||
- [x] **Sie adressiert den konkreten Dienst bzw. die Anwendung auf dem Computer (z. B. Webserver auf 80, HTTPS auf 443).** ✅
|
||||
- [ ] Sie zeigt an, ob das Gerät per WLAN oder Kabel verbunden ist.
|
||||
|
||||
> **Feedback:** IP = „Welches Gebäude?", Port = „Welche Tür im Gebäude?" (welcher Dienst soll die Anfrage empfangen).
|
||||
|
||||
---
|
||||
|
||||
### B7 – IP, MAC, Port: Zuordnung
|
||||
**Thema:** Adressierung – Unterschiede auf einen Blick
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder Adresse ihre Beschreibung zu.
|
||||
|
||||
| Adresse | Beschreibung |
|
||||
|---|---|
|
||||
| IP-Adresse | Globale Adresse eines Geräts – ermöglicht Routing über Netzwerkgrenzen |
|
||||
| MAC-Adresse | Lokale Adresse einer Netzwerkkarte – nur innerhalb eines Segments gültig |
|
||||
| Port-Nummer | Adressiert einen bestimmten Dienst auf einem Computer |
|
||||
|
||||
> **Feedback:** Drei Ebenen der Adressierung: Gerät global (IP), Gerät lokal (MAC), Dienst auf dem Gerät (Port).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### B8 – MAC ändert sich, IP nicht: Warum?
|
||||
**Thema:** IP vs. MAC beim Routing – Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Ein Paket reist von Ihrem Laptop zu einem Webserver über mehrere Router. Erkläre in 2–3 Sätzen, warum die MAC-Adresse an jedem Router neu gesetzt wird, während die IP-Adresse des Ziel-Servers konstant bleibt.
|
||||
|
||||
> **Musterlösung:** Die IP-Adresse des Ziel-Servers bleibt konstant, weil sie das globale Routingziel identifiziert – jeder Router nutzt sie, um das nächste Hop zu bestimmen. Die MAC-Adresse hingegen gilt nur für ein einzelnes Netzwerksegment (einen „Hop"). An jedem Router wird ein neuer Frame erstellt mit der MAC des nächsten Hops als Ziel – die alte MAC wird verworfen.
|
||||
|
||||
---
|
||||
|
||||
### B9 – Encapsulation: Dateneinheit → Schicht
|
||||
**Thema:** Encapsulation – Zuordnung
|
||||
**Punkte:** 3
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt. Ordne jeder Dateneinheit die zugehörige Schicht und was hinzugefügt wird.
|
||||
|
||||
| Dateneinheit | Schicht + Was wird ergänzt |
|
||||
|---|---|
|
||||
| Daten | Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite) |
|
||||
| Segment | Transportschicht – Daten + Ports und Sequenznummern |
|
||||
| Paket | Internetschicht – Segment + IP-Adressen (Quelle und Ziel) |
|
||||
| Frame | Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme |
|
||||
|
||||
> **Feedback:** D-S-P-F: Daten → Segment → Paket → Frame. Jede Schicht fügt einen Header (und beim Frame auch einen Trailer) hinzu.
|
||||
|
||||
---
|
||||
|
||||
### B10 – Encapsulation: Reihenfolge sortieren
|
||||
**Thema:** Encapsulation – Reihenfolge
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die Dateneinheiten in der Reihenfolge, wie sie beim Senden entstehen (von innen nach außen):
|
||||
|
||||
1. Daten
|
||||
2. Segment
|
||||
3. Paket
|
||||
4. Frame
|
||||
|
||||
> **Feedback:** Zwiebelprinzip: Die Anwendung erzeugt Daten → Transport verpackt zu einem Segment → Internet zu einem Paket → Netzzugang zum Frame.
|
||||
|
||||
---
|
||||
|
||||
### B11 – Decapsulation: Umgekehrte Reihenfolge
|
||||
**Thema:** Decapsulation – Empfänger-Seite
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wenn der Server das Signal empfängt, passiert Decapsulation. In welcher Reihenfolge werden die Header entfernt?
|
||||
|
||||
- [ ] Anwendung → Transport → Internet → Netzzugang
|
||||
- [ ] Alle Header werden gleichzeitig entfernt, sobald die Daten im RAM liegen.
|
||||
- [x] **Netzzugang (Ethernet-Header weg) → Internet (IP-Header weg) → Transport (TCP-Header weg) → Daten.** ✅
|
||||
- [ ] Internet → Netzzugang → Transport → Anwendung
|
||||
|
||||
> **Feedback:** Das Auspacken erfolgt in umgekehrter Reihenfolge wie das Einpacken – der äußerste Header (Frame) wird zuerst entfernt.
|
||||
|
||||
---
|
||||
|
||||
### B12 – Encapsulation: Lückentext
|
||||
**Thema:** Encapsulation – Terminologie
|
||||
**Punkte:** 2
|
||||
**Typ:** `[CLOZE]`
|
||||
|
||||
Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt. Die Transportschicht erzeugt ein [[1:Segment]], die Internetschicht ein [[2:Paket]], und die Netzzugangsschicht einen [[3:Frame]]. Am Empfänger wird dieses in [[4:umgekehrter Reihenfolge]] wieder abgepackt (Decapsulation).
|
||||
|
||||
> **Feedback:** D-S-P-F vorwärts beim Senden, F-P-S-D beim Empfangen. Jeder Name beschreibt die Dateneinheit mit allen bis zu dieser Schicht hinzugefügten Headern.
|
||||
|
||||
---
|
||||
|
||||
### B13 – TCP vs. UDP: Videostreaming
|
||||
**Thema:** TCP vs. UDP – Echtzeit-Szenario
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Ein Videostreaming-Dienst sendet Daten an Ihren Browser. Ein einzelnes Paket geht verloren. Warum wählt der Dienst UDP statt TCP?
|
||||
|
||||
- [ ] UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.
|
||||
- [x] **Bei Echtzeit ist Verzögerung schlimmer als Verlust. TCP würde das Paket erneut anfordern → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.** ✅
|
||||
- [ ] TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.
|
||||
- [ ] UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.
|
||||
|
||||
> **Feedback:** Der Kern: Bei Echtzeit zählt Latenz, nicht Vollständigkeit. Ein fehlendes Frame ist besser als ein eingefrorenes Video.
|
||||
|
||||
---
|
||||
|
||||
### B14 – TCP vs. UDP: Unterschiede beschreiben
|
||||
**Thema:** TCP vs. UDP – Konzept-Vergleich
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Nenne zwei wesentliche Unterschiede zwischen TCP und UDP und gib für jeden einen konkreten Anwendungsfall an, in dem genau dieses Eigenschaftspaar ausschlaggebend ist.
|
||||
|
||||
> **Musterlösung:** (1) TCP ist verbindungsorientiert und zuverlässig (Handshake, Sequenznummern, ACK) → ideal für Dateiübertragung, wo jedes Byte zählt. (2) UDP ist verbindungslos und schneller, aber ohne Garantie für Lieferung oder Reihenfolge → ideal für Echtzeit-Anwendungen wie Videostreaming oder Online-Gaming, wo Latenz wichtiger als Vollständigkeit ist.
|
||||
|
||||
---
|
||||
|
||||
### B15 – TCP vs. UDP: Richtig oder Falsch?
|
||||
**Thema:** TCP vs. UDP – Aussagen prüfen
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
„UDP garantiert, dass alle Pakete in der richtigen Reihenfolge ankommen."
|
||||
|
||||
Diese Aussage ist …
|
||||
|
||||
- [ ] …korrekt – UDP nutzt Sequenznummern wie TCP.
|
||||
- [x] **…falsch – UDP bietet keine Garantie für Reihenfolge noch für Lieferung.** ✅
|
||||
- [ ] …korrekt – UDP ist sogar zuverlässiger als TCP.
|
||||
- [ ] …falsch – UDP existiert gar nicht mehr in modernen Netzwerken.
|
||||
|
||||
> **Feedback:** UDP = „fire and forget". Keine Verbindung, keine Sequenznummern, keine Bestätigung. Genau deshalb ist es schneller.
|
||||
|
||||
---
|
||||
|
||||
### B16 – TCP 3-Way-Handshake: SYN geht verloren
|
||||
**Thema:** TCP-Verbindungsaufbau – Störfall
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Der Client sendet ein SYN zum Server. Das SYN-Paket geht verloren – es erreicht den Server nie. Was passiert als nächstes?
|
||||
|
||||
- [ ] Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist.
|
||||
- [x] **Der Server kennt die Anfrage nicht → sendet kein SYN-ACK → der Client erhält keine Antwort → keine Verbindung. Der Client sendet das SYN nach einem Timeout erneut.** ✅
|
||||
- [ ] Der Client sendet direkt ein ACK als Fallback – Verbindung mit zwei Paketen.
|
||||
- [ ] Das verloren gegangene SYN wird vom Netzwerk automatisch rekonstruiert.
|
||||
|
||||
> **Feedback:** Ohne SYN beim Server: kein SYN-ACK, kein Handshake, keine Verbindung. TCP retransmittiert nach Timeout.
|
||||
|
||||
---
|
||||
|
||||
### B17 – TCP 3-Way-Handshake: Ablauf beschreiben
|
||||
**Thema:** TCP-Verbindungsaufbau – Konzept
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Beschreibe die drei Schritte des TCP 3-Way-Handshakes. Erkläre, warum alle drei Schritte nötig sind, bevor Daten gesendet werden.
|
||||
|
||||
> **Musterlösung:** (1) Client → Server: SYN („Ich will eine Verbindung aufbauen"). (2) Server → Client: SYN-ACK (「Ich bestätige das und will auch eine Verbindung"). (3) Client → Server: ACK ("Bestätigt"). Alle drei Schritte sind nötig, damit beide Seiten wissen, dass die andere die Verbindung akzeptiert hat – erst dann kann zuverlässiger Datenaustausch beginnen.
|
||||
|
||||
---
|
||||
|
||||
### B18 – TCP Sequenznummern: Wozu?
|
||||
**Thema:** TCP – Sequenznummern
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Welches Problem lösen Sequenznummern im TCP-Header konkret?
|
||||
|
||||
- [ ] Sie verhindern, dass Hacker die Verbindung abhören können.
|
||||
- [x] **Pakete können in falscher Reihenfolge ankommen. Sequenznummern erlauben das korrekte Sortieren beim Empfänger.** ✅
|
||||
- [ ] Sie zählen, wie viele Benutzende gleichzeitig auf dem Server sind.
|
||||
- [ ] Sie bestimmen die maximale Größe einer Datei.
|
||||
|
||||
> **Feedback:** IP-Pakete können unterschiedliche Routen nehmen → Part 3 kommt vor Part 1. TCP sortiert sie anhand der Sequenznummern wieder.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK C – HTTP
|
||||
|
||||
---
|
||||
|
||||
### C1 – HTTP-Methoden: Zuordnung
|
||||
**Thema:** HTTP-Methoden – Was macht was
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder HTTP-Methode ihre Hauptfunktion zu.
|
||||
|
||||
| Methode | Hauptfunktion |
|
||||
|---|---|
|
||||
| GET | Ruft eine Ressource ab (nur lesen) |
|
||||
| POST | Erstellt eine neue Ressource auf dem Server |
|
||||
| PUT | Ersetzt eine existierende Ressource vollständig |
|
||||
| DELETE | Löscht eine Ressource auf dem Server |
|
||||
|
||||
> **Feedback:** CRUD-Mapping: GET=Read, POST=Create, PUT=Update, DELETE=Delete.
|
||||
|
||||
---
|
||||
|
||||
### C2 – POST vs. PUT: Unterschied
|
||||
**Thema:** HTTP-Methoden – POST vs. PUT
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Eine Person erstellt einen neuen Blog-Eintrag auf einer Webseite. Welche HTTP-Methode wird verwendet?
|
||||
|
||||
- [x] **POST – eine neue Ressource wird erstellt.** ✅
|
||||
- [ ] PUT – PUT wird immer verwendet, wenn Daten gesendet werden.
|
||||
- [ ] GET – GET kann auch Daten senden mit URL-Parametern.
|
||||
- [ ] DELETE – DELETE erstellt und löscht gleichzeitig.
|
||||
|
||||
> **Feedback:** POST = „Erstelle etwas Neues". PUT = „Ersetze etwas Bestehendes". Neuer Blog-Eintrag → POST.
|
||||
|
||||
---
|
||||
|
||||
### C3 – PUT: Profilbild ersetzen
|
||||
**Thema:** HTTP-Methoden – PUT im Szenario
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Eine Person aktualisiert ihr Profilbild – das alte Bild wird durch ein neues ersetzt. Welche HTTP-Methode?
|
||||
|
||||
- [ ] GET – GET kann auch Daten senden.
|
||||
- [x] **PUT – ersetzt eine existierende Ressource.** ✅
|
||||
- [ ] POST – POST ist immer für das Ersetzen zuständig.
|
||||
- [ ] DELETE – DELETE sendet das neue Foto und löscht das alte.
|
||||
|
||||
> **Feedback:** „Ersetzen einer existierenden Ressource" = PUT. POST wäre, wenn ein völlig neues Bild erstellt würde, ohne dass ein vorhandenes überschrieben wird.
|
||||
|
||||
---
|
||||
|
||||
### C4 – DELETE: Wann nutzen?
|
||||
**Thema:** HTTP-Methoden – DELETE im Szenario
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Eine Person löscht einen von ihr erstellten Kommentar auf einer Webseite. Welche HTTP-Methode wird der Browser im Hintergrund verwenden?
|
||||
|
||||
- [ ] GET – GET kann auch Löschvorgänge auslösen.
|
||||
- [ ] POST – POST ist die Standardmethode für alle Änderungen.
|
||||
- [ ] PUT – PUT löscht und ersetzt gleichzeitig.
|
||||
- [x] **DELETE – der Kommentar wird vom Server entfernt.** ✅
|
||||
|
||||
> **Feedback:** DELETE = „Entferne diese Ressource vom Server." Konkret: der Kommentar wird anhand seiner URL/ID identifiziert und gelöscht.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### C5 – GET: Warum nicht für Passwörter?
|
||||
**Thema:** HTTP-Methoden – GET Sicherheit
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Warum sollte man niemals GET verwenden, um sensible Daten (z. B. ein Passwort) an den Server zu senden?
|
||||
|
||||
- [ ] GET ist langsamer als POST – Passwörter müssen schnell übertragen werden.
|
||||
- [x] **Bei GET stehen die Daten sichtbar in der URL (Browser-Verlauf, Server-Logs, Proxy-Server). Bei POST sind sie im Body versteckt.** ✅
|
||||
- [ ] GET erlaubt nur Zahlen, keine Buchstaben.
|
||||
- [ ] GET wird vom Server nie verschlüsselt, POST immer.
|
||||
|
||||
> **Feedback:** GET-Parameter hängen an der URL (`?pw=123`). Diese ist in History, Logs, Proxies sichtbar. HTTPS verschlüsselt zwar beides auf der Leitung, aber die URL selbst wird an zu vielen Stellen gespeichert.
|
||||
|
||||
---
|
||||
|
||||
### C6 – Status-Codes: Kategorisierung
|
||||
**Thema:** HTTP Status-Codes – Bedeutung der ersten Ziffer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jeder ersten Ziffer eines HTTP-Status-Codes ihre Bedeutung zu.
|
||||
|
||||
| Erste Ziffer | Bedeutung |
|
||||
|---|---|
|
||||
| 2xx | Erfolg – die Anfrage wurde erfolgreich verarbeitet |
|
||||
| 3xx | Weiterleitung – die Ressource wurde verschoben |
|
||||
| 4xx | Client-Fehler – die Anfrage der Anfragenden war fehlerhaft |
|
||||
| 5xx | Server-Fehler – der Server hat ein Problem |
|
||||
|
||||
> **Feedback:** Die erste Ziffer = Kategorie. 200 OK, 301 Moved, 404 Not Found, 503 Service Unavailable – die Kategorie sagt Ihnen sofort, wo das Problem liegt.
|
||||
|
||||
---
|
||||
|
||||
### C7 – 503: Server-Fehler erkläre
|
||||
**Thema:** HTTP Status-Codes – 5xx Transfer
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie rufen eine Webseite auf und erhalten `HTTP/2 503 Service Unavailable`. Was bedeutet das?
|
||||
|
||||
- [ ] Sie haben die falsche URL eingegeben.
|
||||
- [ ] Der Server hat die Anfrage erfolgreich umgeleitet.
|
||||
- [x] **Der Server ist überlastet oder temporär nicht verfügbar – Verantwortung liegt beim Betreiber.** ✅
|
||||
- [ ] Der Server hat die Seite dauerhaft verschoben.
|
||||
|
||||
> **Feedback:** 5xx = Server-Problem. Sie als Client können nur später erneut versuchen. Der Betreiber muss das lösen.
|
||||
|
||||
---
|
||||
|
||||
### C8 – 404: Wer hat „Schuld"?
|
||||
**Thema:** HTTP Status-Codes – 4xx Transfer
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie erhalten einen 404-Fehler. Wer ist für die Ursache verantwortlich?
|
||||
|
||||
- [ ] Der Server ist abgestürzt.
|
||||
- [ ] Das Internet ist ausgefallen.
|
||||
- [x] **Der Client (Anfragende) – eine URL wurde angefordert, die nicht existiert (Tippfehler oder veralteter Link).** ✅
|
||||
- [ ] Der DNS-Server konnte den Namen nicht auflösen.
|
||||
|
||||
> **Feedback:** 4xx = Client-Fehler. Der Server funktioniert perfekt, er sagt nur: „Das, was Sie anfragen, habe ich nicht."
|
||||
|
||||
---
|
||||
|
||||
### C9 – Status-Codes: Szenarios zuordnen
|
||||
**Thema:** HTTP Status-Codes – Transfer Zuordnung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Szenario den passenden HTTP-Status-Code zu.
|
||||
|
||||
| Szenario | Status-Code |
|
||||
|---|---|
|
||||
| Sie rufen eine Seite auf, die seit letztem Jahr auf eine neue URL umgeleitet wurde | 301 Moved Permanently |
|
||||
| Eine Webseite lädt erfolgreich | 200 OK |
|
||||
| Sie geben eine URL ein, die nicht existiert | 404 Not Found |
|
||||
| Der Webserver ist überlastet | 503 Service Unavailable |
|
||||
|
||||
> **Feedback:** 200 = Alles gut. 301 = dauerhaft verschoben. 404 = nicht gefunden (Ihr Fehler). 503 = Server-Problem (Betreiber).
|
||||
|
||||
---
|
||||
|
||||
### C10 – Status-Codes: Freitext
|
||||
**Thema:** HTTP Status-Codes – Konzept zusammenfassen
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, warum HTTP-Status-Codes aus einer dreistelligen Zahl bestehen und was die erste Ziffer konkret bedeutet. Nenne je einen Beispiel-Code für 2xx, 4xx und 5xx.
|
||||
|
||||
> **Musterlösung:** Die erste Ziffer kategorisiert die Antwort: 2xx = Erfolg, 3xx = Weiterleitung, 4xx = Client-Fehler, 5xx = Server-Fehler. Die restlichen zwei Ziffern spezifizieren den genauen Fall. Beispiele: 200 OK (Erfolg), 404 Not Found (Client-Fehler), 500 Internal Server Error (Server-Fehler). Diese Struktur ermöglicht es, allein aus dem Code zu verstehen, ob und wo ein Problem liegt – ohne die Antwort ganz lesen zu müssen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK D – DNS
|
||||
|
||||
---
|
||||
|
||||
### D1 – DNS: Was macht es?
|
||||
**Thema:** DNS – Grundfunktion
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist die Hauptfunktion eines DNS-Servers?
|
||||
|
||||
- [ ] Er verschlüsselt die Verbindung zwischen Client und Server.
|
||||
- [x] **Er übersetzt einen Domain-Namen (z. B. `hdm-stuttgart.de`) in eine IP-Adresse.** ✅
|
||||
- [ ] Er routet Pakete durch das Internet.
|
||||
- [ ] Er weist jedem Computer eine MAC-Adresse zu.
|
||||
|
||||
> **Feedback:** DNS = Domain Name System = „Telefonbuch des Internets". Name → IP. Ohne DNS müsste man überall IP-Adressen eintippen.
|
||||
|
||||
---
|
||||
|
||||
### D2 – DNS: Zeitlicher Ablauf
|
||||
**Thema:** DNS – Rolle im Gesamtablauf
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie geben `https://hdm-stuttgart.de` in die Adresszeile ein. Was passiert vor dem TCP-Handshake?
|
||||
|
||||
- [ ] Der Browser sendet direkt den Namen an den Server – DNS wird erst danach benötigt.
|
||||
- [x] **DNS-Auflösung: Der Name wird in eine IP-Adresse umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen.** ✅
|
||||
- [ ] DNS passiert nach dem TCP-Handshake.
|
||||
- [ ] DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.
|
||||
|
||||
> **Feedback:** DNS vor TCP. Kein Name-to-IP? Kein Handshake möglich. TCP arbeitet auf IP-Adressen, nicht auf Domain-Namen.
|
||||
|
||||
---
|
||||
|
||||
### D3 – DNS: Warum zwingend nötig?
|
||||
**Thema:** DNS – Transfer/Begründung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre in 2–3 Sätzen, warum der DNS-Schritt zwingend vor dem TCP-Handshake stehen muss. Was würde passieren, wenn der Browser den Domain-Namen direkt an den Netzwerk-Stack übergeben würde?
|
||||
|
||||
> **Musterlösung:** TCP arbeitet nur mit IP-Adressen – ein Domain-Name wie `hdm-stuttgart.de` ist für TCP-/IP-Stack sinnlos. Ohne vorherige DNS-Auflösung würde der Browser nicht wissen, an welche IP er das SYN senden soll. Der DNS-Schritt konvertiert den human-readable-Namen in eine maschinenlesbare IP, erst danach kann der Verbindungsaufbau beginnen.
|
||||
|
||||
---
|
||||
|
||||
### D4 – DNS: Lückentext
|
||||
**Thema:** DNS – Terminologie
|
||||
**Punkte:** 1
|
||||
**Typ:** `[CLOZE]`
|
||||
|
||||
Der DNS-Server übersetzt einen [[1:Domain-Namen]] in eine [[2:IP-Adresse]]. Dieser Schritt fällt [[3:vor]] dem TCP-Handshake statt, weil TCP nur zu [[4:IP-Adressen]] Verbindungen aufbauen kann.
|
||||
|
||||
> **Feedback:** Die vier Lücken beschreiben den DNS-Ablauf vollständig: Was wird übersetzt, in was, wann, und warum.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK E – Der Gesamtablauf (Zusammen)
|
||||
|
||||
---
|
||||
|
||||
### E1 – Reihenfolge eines HTTPS-Aufrufs
|
||||
**Thema:** Gesamtablauf – Sortierung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ORDER]`
|
||||
|
||||
Sortiere die Schritte eines HTTPS-Aufrufs in der richtigen Reihenfolge:
|
||||
|
||||
1. DNS-Auflösung (Name → IP)
|
||||
2. TCP 3-Way-Handshake (Verbindung aufbauen)
|
||||
3. TLS-Handshake (Verschlüsselung vereinbaren)
|
||||
4. HTTP GET (Anfrage senden)
|
||||
5. HTTP 200 OK + HTML (Antwort empfangen)
|
||||
|
||||
> **Feedback:** DNS → TCP → TLS → HTTP Request → HTTP Response. Jeder Schritt ist eine Voraussetzung für den nächsten.
|
||||
|
||||
---
|
||||
|
||||
### E2 – Reihenfolge: Welche Folge ist korrekt?
|
||||
**Thema:** Gesamtablauf – Multiple Choice
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie geben eine URL ein. Welche Reihenfolge ist korrekt?
|
||||
|
||||
- [ ] (1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK
|
||||
- [x] **(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK** ✅
|
||||
- [ ] (1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK
|
||||
- [ ] (1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK
|
||||
|
||||
> **Feedback:** DNS immer zuerst. Dann TCP (Verbindung). Dann HTTP (Anfrage/Antwort).
|
||||
|
||||
---
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK F – HTML-Grundlagen
|
||||
|
||||
---
|
||||
|
||||
### F1 – `<head>` vs. `<body>`: Was passiert bei Fehler?
|
||||
**Thema:** HTML-Struktur – head/body
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Eine studierende Person platziert den `<title>` und `<meta name="description">` im `<body>` statt im `<head>`. Welche zwei Konsequenzen hat das?
|
||||
|
||||
- [ ] Kein Problem – Browser ignorieren die Unterscheidung.
|
||||
- [x] **(1) Der Browser-Tab zeigt keinen Titel an. (2) Suchmaschinen haben keine Beschreibung für das Snippet → schlechte SEO, Screen-Reader können die Seite nicht richtig vorlesen.** ✅
|
||||
- [ ] (1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.
|
||||
- [ ] Nur das Fehlen von `<meta charset>` ist ein Problem.
|
||||
|
||||
> **Feedback:** `<head>` = Metadaten (unsichtbar für die Benutzenden, sichtbar für Browser/Maschinen). `<body>` = sichtbarer Inhalt. Title und description im Body werden nicht als Metadaten interpretiert.
|
||||
|
||||
---
|
||||
|
||||
### F2 – `<head>`: Was gehört wohin?
|
||||
**Thema:** HTML-Struktur – Zuordnung
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Element zu, ob es in `<head>` oder `<body>` gehört.
|
||||
|
||||
| Element | Wohin? |
|
||||
|---|---|
|
||||
| `<title>` | `<head>` |
|
||||
| `<meta charset="UTF-8">` | `<head>` |
|
||||
| `<meta name="description">` | `<head>` |
|
||||
| `<h1>Willkommen</h1>` | `<body>` |
|
||||
| `<p>Text hier</p>` | `<body>` |
|
||||
| `<link rel="stylesheet">` | `<head>` |
|
||||
|
||||
> **Feedback:** `<head>` = alles, was die Benutzenden nicht direkt sehen (Metadaten, Styles, Titel). `<body>` = alles, was im Browser-Fenster angezeigt wird.
|
||||
|
||||
---
|
||||
|
||||
### F3 – Charset: Was passiert ohne `<meta charset>`?
|
||||
**Thema:** HTML – Zeichenkodierung
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist die konkrete Konsequenz, wenn `<meta charset="UTF-8">` fehlt oder falsch gesetzt ist?
|
||||
|
||||
- [ ] Die Webseite lädt gar nicht.
|
||||
- [x] **Sonderzeichen (Umlaute, Emojis) werden als kryptische Symbole dargestellt, weil der Browser die falsche Zeichenkodierung rät.** ✅
|
||||
- [ ] Die Seite wird langsamer, da der Browser alle Sprachen durchprobieren muss.
|
||||
- [ ] Das CSS wird nicht geladen.
|
||||
|
||||
> **Feedback:** Ohne charset nutzt der Browser oft einen Standard wie Latin-1. Bei UTF-8-gespeicherten Dateien → Umlaute und Emojis werden falsch dargestellt (Mojibake).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK G – CSS
|
||||
|
||||
---
|
||||
|
||||
### G1 – Spezifität: ID vs. Klasse vs. Element
|
||||
**Thema:** CSS Spezifität – Grundregel
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Gegeben:
|
||||
```
|
||||
p { color: blue; }
|
||||
.highlight { color: green; }
|
||||
#main { color: red; }
|
||||
```
|
||||
Ein Element `<p class="highlight" id="main">` wird angezeigt. Welche Farbe?
|
||||
|
||||
- [ ] Blau – die Element-Regel steht zuerst im Code.
|
||||
- [ ] Grün – Klassen haben immer Vorrang vor IDs.
|
||||
- [x] **Rot – die ID `#main` hat die höchste Spezifität (0,1,0,0).** ✅
|
||||
- [ ] Rot – die letzte Regel im Code gewinnt immer.
|
||||
|
||||
> **Feedback:** Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Reihenfolge im Code ist nur relevant bei gleicher Spezifität.
|
||||
|
||||
---
|
||||
|
||||
|
||||
### G2 – Responsive Design: Mobile First – Welche Farbe?
|
||||
**Thema:** CSS Media Queries – Mobile First
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
```css
|
||||
.container { background: white; }
|
||||
@media (min-width: 768px) { .container { background: blue; } }
|
||||
@media (min-width: 1024px) { .container { background: green; } }
|
||||
```
|
||||
Welche Farbe bei 900 px Breite?
|
||||
|
||||
- [ ] Weiß – Media-Queries gelten nur ab 1024 px.
|
||||
- [ ] Grün – die letzte Media-Query überschreibt immer.
|
||||
- [x] **Blau – bei 900 px greift `min-width: 768px` (900 ≥ 768), aber `min-width: 1024px` nicht (900 < 1024).** ✅
|
||||
- [ ] Weiß – keine Media-Query greift zwischen den Breakpoints.
|
||||
|
||||
> **Feedback:** Mobile First: Basis = white. Bei 900px: 768px-Query greift ✓, 1024px-Query greift ✗ → blau.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### G3 – Desktop First: `max-width` erkläre
|
||||
**Thema:** CSS Media Queries – Desktop First
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Wie würde eine Media Query für „Desktop First" aussehen (Standard ist Desktop, Anpassung für kleine Screens)?
|
||||
|
||||
- [ ] `@media (device-width: small) { ... }`
|
||||
- [ ] `@media (min-width: ...)` – bleibt gleich, nur die Reihenfolge ändert sich.
|
||||
- [x] **`@media (max-width: ...)` – Stile für Bildschirme, die kleiner als eine bestimmte Breite sind.** ✅
|
||||
- [ ] `@media (mobile: true) { ... }`
|
||||
|
||||
> **Feedback:** Desktop First: Basis-CSS für große Schirme. `max-width` = „Wenn der Bildschirm schmäler ist als X, dann…" – Ausnahmen für Tablets/Handys.
|
||||
|
||||
---
|
||||
|
||||
### G4 – Mobile First vs. Desktop First: Vergleich
|
||||
**Thema:** CSS Media Queries – Konzept-Vergleich
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre den Unterschied zwischen „Mobile First" und „Desktop First" beim Responsive Design. Welche Media-Query-Eigenschaft nutzt jeder Ansatz, und warum?
|
||||
|
||||
> **Musterlösung:** Mobile First: Das Basis-CSS ist für kleine Bildschirme (Handy). Mit `min-width` werden schrittweise Anpassungen für größere Bildschirme hinzugefügt („ab dieser Breite"). Desktop First: Das Basis-CSS ist für große Bildschirme. Mit `max-width` werden Ausnahmen für kleinere Geräte definiert (「bis zu dieser Breite"). Mobile First wird bevorzugt, weil die Mehrheit der Benutzenden mobil zugrifft und forced-mobile-first die Grundlage für progressive Enhancement bietet.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
## BLOCK H – Barrierefreiheit
|
||||
|
||||
---
|
||||
|
||||
### H1 – Wie nutzen Menschen das Web?
|
||||
**Thema:** Barrierefreiheit – Eingabegeräte
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MATCH]`
|
||||
|
||||
Ordne jedem Eingabegerät seine Nutzungsweise zu.
|
||||
|
||||
| Eingabe | Nutzungsweise |
|
||||
|---|---|
|
||||
| Maus | Klicken, Scrollen |
|
||||
| Tastatur | Tab-Navigation, Enter, Pfeiltasten |
|
||||
| Screenreader | Vorlesen von Inhalten |
|
||||
| Sprachsteuerung | „Klicke auf Anmelden" |
|
||||
| Augensteuerung | Eye-Tracking |
|
||||
| Switch-Geräte | Ein-/Aus-Schalter |
|
||||
|
||||
> **Feedback:** Nicht alle nutzen Maus + Bildschirm. ~15% der Weltbevölkerung haben eine Behinderung (WHO). Assistive Technologien wie Screenreader (NVDA, VoiceOver, JAWS) oder Switch-Geräte ermöglichen Web-Zugang für Menschen mit verschiedenen Einschränkungen.
|
||||
|
||||
---
|
||||
|
||||
### H2 – Einschränkungen: Temporär vs. situativ
|
||||
**Thema:** Barrierefreiheit – Einschränkungstypen
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Eine Person kann aktuell nur mit einer Hand ihr Handy bedienen, weil sie das Baby auf dem Arm trägt. Wie klassifiziert man diese Einschränkung?
|
||||
|
||||
- [ ] Permanent – das ist eine bleibende körperliche Behinderung.
|
||||
- [ ] Temporär – die Person ist verletzt und braucht Zeit zum Heilen.
|
||||
- [x] **Situativ – die Einschränkung entsteht durch die aktuelle Umgebung/Situation, nicht durch eine Behinderung.** ✅
|
||||
- [ ] Diese Art von Einschränkung existiert nicht – Barrierefreiheit betrifft nur Menschen mit Behinderung.
|
||||
|
||||
> **Feedback:** Drei Typen: Permanent (z. B. Blindheit), Temporär (z. B. gebrochener Arm, Augen-OP), Situativ (z. B. helle Sonne, laute Umgebung, Baby auf dem Arm). Barrierefreie Gestaltung hilft bei allen drei.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### H3 – Curb-Cut-Effekt: Beispiel identifizieren
|
||||
**Thema:** Barrierefreiheit – Curb-Cut-Effekt
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Welches Beispiel demonstriert den Curb-Cut-Effekt?
|
||||
|
||||
- [ ] Barrierefreie Webseiten laden langsamer.
|
||||
- [x] **Untertitel: gedacht für Gehörlose, helfen aber auch in lauter Umgebung oder beim Sprachlernen.** ✅
|
||||
- [ ] Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.
|
||||
- [ ] Alt-Texte verlängern die Ladezeit einer Webseite.
|
||||
|
||||
> **Feedback:** Curb-Cut-Effekt = eine barrierefreie Lösung nutzt am Ende allen. Untertitel für Gehörlose → helfen auch in lauter Umgebung. Kontrastreiche Farben für Sehbehinderung → besser im Sonnenlicht, für ältere Menschen.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### H4 – Curb-Cut-Effekt: Erklärung
|
||||
**Thema:** Barrierefreiheit – Curb-Cut-Effekt Transfer
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre das Konzept des Curb-Cut-Effekts. Nenne zwei konkrete Web-Beispiele und erkläre jeweils, wer die ursprüngliche Zielgruppe war und wer sonst davon profitiert.
|
||||
|
||||
> **Musterlösung:** Der Curb-Cut-Effekt beschreibt, wie eine Maßnahme für Menschen mit Behinderung am Ende allen zugute kommt – wie die Bordsteinabsenkung, die für Rollstuhlfahrer gedacht war, aber auch Kinderwagen, Rollkoffer und Fahrrädern helfen. Web-Beispiele: (1) Untertitel – primär für Gehörlose, helfen auch in lauter Umgebung oder beim Sprachlernen. (2) Alt-Texte – primär für Screen-Reader-Benutzende, helfen auch Suchmaschinen (SEO).
|
||||
|
||||
---
|
||||
|
||||
### H5 – EAA: Was ist das?
|
||||
**Thema:** Barrierefreiheit – Rechtlicher Rahmen
|
||||
**Punkte:** 1
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Was ist der European Accessibility Act (EAA)?
|
||||
|
||||
- [ ] Ein freiwilliges EU-Programm zur Förderung barrierefreier Websites.
|
||||
- [x] **Eine EU-Richtlinie, die seit Juni 2025 in Kraft ist und Barrierefreiheit in bestimmten digitalen Bereichen verpflichtend macht.** ✅
|
||||
- [ ] Ein deutsches Gesetz, das nur öffentliche Behörden betrifft.
|
||||
- [ ] Ein technisches Standard wie HTML oder CSS.
|
||||
|
||||
> **Feedback:** EAA = European Accessibility Act. Seit 28. Juni 2025 in Kraft. Betrifft E-Commerce, Banking, Telekommunikation, Transport, E-Books. In Deutschland umgesetzt durch das BFSG (Barrierefreiheitsstärkungsgesetz). Verstoß: bis 100.000€ Bußgeld möglich.
|
||||
|
||||
---
|
||||
|
||||
### H6 – Barrierefreiheit: Warum auch für „normale" Benutzende?
|
||||
**Thema:** Barrierefreiheit – Business Case
|
||||
**Punkte:** 2
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erkläre, warum barrierefreie Gestaltung nicht nur für Menschen mit Behinderung wichtig ist, sondern auch einen praktischen Nutzen für alle Benutzenden hat. Nenne mindestens zwei konkrete Beispiele.
|
||||
|
||||
> **Musterlösung:** Barrierefreiheit verbessert die UX für alle: (1) SEO – Alt-Texte und semantisches HTML helfen Suchmaschinen, die Seite besser zu verstehen → besseres Ranking. (2) Mobile – viele barrierefreie Prinzipien (z. B. große Tippflächen, guter Kontrast) sind auch für Mobilgeräte im Sonnenlicht wichtig. (3) Ältere Menschen – Sehschwäche, motorische Einschränkungen betreffen einen großen Anteil der Bevölkerung. Der Markt: ~15% Menschen mit Behinderung + ~20% ältere Menschen.
|
||||
|
||||
---
|
||||
|
||||
### H7 – Tastatur-Test: Was prüfen?
|
||||
**Thema:** Barrierefreiheit – Praktischer Test
|
||||
**Punkte:** 2
|
||||
**Typ:** `[MC]`
|
||||
|
||||
Sie möchten eine Webseite auf Barrierefreiheit testen, ohne assistive Technologie zu installieren. Was machen Sie?
|
||||
|
||||
- [ ] Sie scrollen durch die Seite und schauen, ob sie schön aussieht.
|
||||
- [x] **Sie navigieren nur mit Tab + Enter durch die Seite und prüfen: Erreichen Sie alle Funktionen? Ist der Fokus immer sichtbar? Ist die Tab-Reihenfolge logisch?** ✅
|
||||
- [ ] Sie installieren einen Screenreader und lassen die Seite vorlesen.
|
||||
- [ ] Sie öffnen den Quellcode und zählen die barrierefreien Tags.
|
||||
|
||||
> **Feedback:** Der Tastatur-Test ist der schnellste barrierefreie Selbsttest: Nur Tab + Enter benutzen. Wenn man so eine Funktion nicht erreicht kann, ist sie für Tastatur-Benutzende (und damit auch für Screenreader-Benutzende) nicht zugänglich. Tools wie axe DevTools oder Lighthouse automatisieren ~30% der Checks.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead disable -->
|
||||
|
||||
## BLOCK I – Zusammenfassung-Fragen (Übergreifend)
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### I1 – Gesamtablauf: Wahl der richtigen Methode
|
||||
**Thema:** HTTP + TCP + DNS zusammen
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Eine Person klickt auf einen „Neuen Eintrag erstellen"-Button einer Webanwendung. Beschreibe vom Klick bis zur Antwort des Servers, welche Protokolle beteiligt sind und welche HTTP-Methode verwendet wird.
|
||||
|
||||
> **Musterlösung:** (1) Der Browser sendet eine HTTP-Anfrage. Da es sich um eine neue Ressource handelt, nutzt er POST. (2) Vorher: DNS löst den Domain-Namen auf. (3) TCP-Handshake stellt die Verbindung her. (4) POST-Anfrage wird gesendet (Daten im Body). (5) Server verarbeitet, erstellt den Eintrag, antwortet mit 201 Created.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: disable -->
|
||||
|
||||
### I2 – Gesamtablauf: Störfall analysieren
|
||||
**Thema:** Netzwerk + HTTP – Transfer/Problemlösung
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Sie rufen eine Webseite auf und erhalten eine Fehlermeldung. Beschreibe drei verschiedene Szenarien, die zu einer Fehlermeldung führen könnten, und erkläre, in welcher „Schicht" des Ablaufs (DNS, TCP, HTTP) das Problem liegt und wie Sie es erkennen.
|
||||
|
||||
> **Musterlösung:** (1) DNS-Fehler: „Der Server wurde nicht gefunden" → DNS konnte den Namen nicht auflösen (z. B. Tippfehler in der URL oder DNS-Server nicht erreichbar). (2) TCP-Fehler: „Die Verbindung wurde verweigert" → Server existiert (IP bekannt), akzeptiert aber keine Verbindung (nicht gestartet, Port blockiert). (3) HTTP-Fehler: 404 → TCP-Verbindung erfolgreich, aber die angeforderte Ressource existiert nicht auf dem Server.
|
||||
Reference in New Issue
Block a user