für eine eigene Anwendung einen FIFO- und einen LIFO-Prozess begründen,
eine Fachklasse und ihre Beziehungen in einem kleinen Modell darstellen,
Queue und Stack in einer lauffähigen Konsolenanwendung verbinden,
Reihenfolgen und Randfälle mit selbst geplanten Tests überprüfen,
deinen Beitrag erklären und eine kleine Änderung selbstständig umsetzen.
Leitfrage: Welche kleine Welt kannst du bauen, in der Warten und Zurücknehmen eine sinnvolle Rolle spielen?
Voraussetzungen und Lernweg
Du kennst Queue programmieren und Stack verstehen. Die drei Grundlagenchecks sind deine Standortbestimmung. Eine noch offene Stelle übst du gezielt, bevor du sie im Projekt benötigst.
Vier Unterrichtsstunden als Orientierung: Idee und Modell → FIFO-Kern → LIFO-Funktion und Tests → Präsentation und eigener Nachweis. Arbeite allein oder zu zweit. In einem Team wechselt ihr spätestens nach 15 Minuten zwischen Programmieren und Prüfen. Jede Person muss beide Datenstrukturen erklären können.
Mermaid-Diagramm
Mermaid-Diagramm wird geladen…
Verbindlich sind die Kompetenzen, frei sind Thema und Gestaltung. Eine Konsole reicht. Eine Grafik ist eine spätere Erweiterung, wenn der Kern funktioniert. Das Projekt ersetzt zusätzliche Shop- und Wiederholungsaufgaben; du musst diese nicht vorher alle lösen.
Phase 1: Eine eigene Idee entwickeln
Abruf 1 – jede Person allein, 4 Minuten ohne Hilfen oder KI
Welche Ausgabe entsteht, wenn A,B,C in eine Queue beziehungsweise einen Stack eingefügt und vollständig entnommen werden?
Wie entnimmst du sicher ein Stack-Element, das du anschließend brauchst?
Warum ist ein gespeichertes Objekt nicht automatisch kopiert, wenn du eine zweite Referenz darauf ablegst?
Textabgabe
Erst entwerfen – ohne Vorlage und KI
Erfinde in 5 Minuten einen Ablauf, bei dem etwas wartet und ein letzter Schritt zurückgenommen werden kann. Zeichne drei Zustände: davor, nach einer Aktion, nach dem Zurücknehmen. Notiere eine Regel, die verhindern soll, dass etwas verloren geht.
Projektauftrag: Mein Modell (Pflicht, AFB II–III)
Entscheide dich für einen Kontext. Beschreibe zwei Nutzungsfälle, zeichne ein kleines Klassendiagramm und formuliere die Bedeutung deiner Methoden. Eine Fachklasse braucht mindestens zwei sinnvolle Attribute. Begründe beide Datenstrukturen und benenne eine Grenze deiner Simulation.
Erwartungs-Check: Welche konkrete Folge mit drei Aufträgen und zwei rücknehmbaren Schritten wird dein Programm später zeigen?
Textabgabe
Phase 2: Einen kleinen Kern bauen
Abruf 2 – vor dem Programmieren allein
Welche Methode verändert deine Queue, welche liest nur? Warum brauchst du vor einem neuen Auftrag eine Regel für den bisherigen Stack-Inhalt? Nenne aus deinem Modell ein Attribut und eine Beziehung zwischen zwei Klassen.
Textabgabe
Beispiel zum Erklären: Eine Zutat wirklich zurücknehmen
Ohne KI: Sage die drei Ausgaben voraus und erkläre die Zustandsänderung. Das Beispiel zeigt nur einen LIFO-Baustein; dein Thema und die Verbindung zur Queue entwirfst du selbst.
IDE lädt…
Mini-Check 1: Würde System.out.println(ingredients.top()) allein die Minze entfernen?
Abnehmende Hilfe
Completion – bei Bedarf: Ergänze für einen beliebigen Stack<String> history den Ablauf if (!history.____()) { String last = history.____(); history.____(); }. Erkläre anschließend jeden Schritt.
Eigenständig: Übertrage das Prinzip in deine Anwendung. Entscheide selbst über Klassen, Methoden und Meldungen. Implementiere zuerst Eingang und Bearbeitung eines Auftrags; füge danach die Rücknahme hinzu.
Meine Anwendung (Pflicht, AFB II–III)
Nutze den Editor für eigene Klassen. Ersetze das Startprogramm durch deine Demonstration. Jede Person reicht den gemeinsamen Stand unter dem eigenen Zugang ein und erklärt unten den eigenen Beitrag.
IDE lädt…
Phase 3: Testen und gegenseitig prüfen
Abruf 3 – jede Person allein
Eine Suche liefert die richtige Bestellung, hat aber frühere Bestellungen gelöscht. Ist sie korrekt? Was muss ein Test zusätzlich zum Rückgabewert prüfen? Erkläre danach, was bei Undo auf deinem leeren Zustand geschehen soll.
Textabgabe
Mini-Check 2: Alle Tests geben nur „kein Fehler“ aus. Belegen sie FIFO und LIFO?
Fünf Tests mit Soll und Ist (Pflicht, AFB II)
Schreibe für jeden Test zuerst die erwartete Ausgabe beziehungsweise den Zustand auf. Führe ihn dann aus und halte die tatsächliche Ausgabe fest.
Fall
Was du nachweisen sollst
Leere Verwaltung
Bearbeiten und Undo sind sicher.
Ein Auftrag
Eingang, Bearbeitung und Abschluss funktionieren.
Drei unterscheidbare Aufträge
FIFO ist an der vollständigen Reihenfolge erkennbar.
Zwei Schritte, dreimal Undo
LIFO und der leere Randfall sind erkennbar.
Eigener Grenzfall
Beispielsweise Auftragswechsel: kein fremder Verlauf bleibt übrig.
Textabgabe
Partnerprüfung (8 Minuten): Person A erklärt 2 Minuten eine Methode. Person B wählt 2 Minuten lang einen bisher ungetesteten Randfall. Danach Rollenwechsel. Allein: Erkläre dieselbe Methode schriftlich, wähle einen neuen Randfall und vergleiche Soll/Ist.
Selbstdiagnose: Kannst du FIFO, LIFO, die Modellentscheidung und einen Randfall jeweils ohne Hilfe erklären? Bewerte deine Sicherheit von 1–5 und nenne eine Stelle, die du noch prüfen musst. Fehlgeschlagene Tests sind ein Arbeitsauftrag, kein Grund, das ganze Projekt neu zu beginnen.
Phase 4: Vorführen und individuell nachweisen
Zeige in 2 Minuten deine Idee, eine typische Folge und eine Rücknahme. Ein anderes Team nennt eine Stärke und eine offene Frage. Allein in der Lernzeit: Halte dieselbe Demonstration als Ablaufprotokoll fest.
Kompetenzcheck am eigenen Code – jede Person, ohne KI
Die Lehrkraft oder dein Gegenüber wählt eine neue Eingabe. Sage den Zustand voraus und erkläre den Ablauf. Setze anschließend allein eine kleine Änderung um, zum Beispiel eine zusätzliche Leerfallmeldung oder eine neue erlaubte Aktion. Die Änderung muss zu deinem Modell passen.
Textabgabe
Rückmeldung: Das Modell passt zu den Regeln; FIFO und LIFO funktionieren; die fünf Tests sind aussagekräftig; die individuelle Erklärung stimmt mit dem Code überein. Je Bereich gibt es 0 Punkte (noch nicht belegt), 1 (teilweise/mit Hilfe) oder 2 (vollständig). Die Lehrkraft hält den individuellen Nachweis getrennt vom Teamergebnis fest. Es geht um eine kleine verständliche Lösung, nicht um möglichst viele Funktionen.
Wenn etwas noch fehlt: Wähle genau einen fehlerhaften Fall, zeichne davor/nachher, nutze die passende Hilfe aus Phase 2 und teste erneut. Erkläre anschließend eine neue Eingabe ohne Hilfe und ergänze deinen Nachweis. Wer fertig ist, entwickelt ein eigenes Zusatzfeature und einen dazugehörigen Test.
Eine Woche später: kurzer Wiederholungscheck
Ohne Projektcode, Unterlagen oder KI: Eine Roboterstation nimmt Aufträge A,B,C an. A wird begonnen und erhält die Schritte „vor“, „links“, „vor“. Ein Schritt wird zurückgenommen. Welche Aufträge warten, welcher Schritt liegt oben, und warum gehören zwei Datenstrukturen zu diesem Modell? Was geschieht bei einer weiteren Rücknahme nach vollständigem Leeren?
Textabgabe
Rückblick und nächste Frage
Du hast selbst entschieden, welche Objekte, Regeln und Zugriffe zu deiner Mini-Welt passen. Queue und Stack organisieren unterschiedliche Reihenfolgen. Mentale Checkliste: Welche Reihenfolge brauche ich? Was verändert die Operation? Was passiert beim leeren Zustand? Welcher Test belegt meine Behauptung?
Notiere zum Abschluss: Was hast du selbst entschieden, welche Hilfe war nützlich und welche Änderung würdest du als Nächstes ausprobieren? Danach kannst du Stack-Algorithmen vertiefen oder zum Folgekurs List und Algorithmen übergehen.
