Aufgabe 23 - Vokabeltrainer (Mini-Projekt)

Aufgabe 23 - Vokabeltrainer (Mini-Projekt)

Worum geht es?

Das Jahr in einer Anwendung: ein Vokabeltrainer mit GUI, JSON-Datenhaltung, Klassenmodell, Exception-Handling, Tests und Git-Workflow. Die Übung ist die Generalprobe für das Abschlussprojekt; sie prüft weniger einzelne Techniken als deren Zusammenspiel. Der Funktionsumfang ist bewusst klein gehalten: Ein schlanker, sauber gebauter Trainer ist das Ziel, kein Funktionsfeuerwerk.

Was Sie dafür brauchen

• Alle Kapitel des Schuljahres, insbesondere GUI mit Python, Dateien und Datenformate, Exceptions, Testen mit pytest und Versionsverwaltung mit Git.
• Die Aufgaben 20 und 21 als handwerkliche Vorlagen; ein Repository am Schul-GitLab.

Welche Kompetenzen Sie erwerben und zeigen

• Sie planen eine kleine Anwendung mit Modell (Klassen- und Zustandsdiagramm), bevor Sie bauen.
• Sie integrieren Datenhaltung, Fachlogik, Fehlerbehandlung, Tests und Oberfläche zu einem lauffähigen Ganzen.
• Sie liefern nachvollziehbar: dokumentiertes Datenformat, README, Git-Historie mit Branches.

Pädagogische Einordnung

• Reproduktion: eingeübte Bausteine (JSON-Laden, Klassen, GUI-Gerüst) wiederverwenden (Teile A und B).
• Reorganisation und Transfer: die Bausteine zu einer neuen Anwendung kombinieren und an neue Anforderungen anpassen (Teile B und C).
• Reflexion, Problemlösung und Urteilsbildung: einen eigenen Auswahlalgorithmus entwerfen und begründen, das Gesamtsystem präsentieren und verteidigen (Teile C und D).

Arbeitsaufträge

Kern der Übung (Teile A bis C) ist auf etwa zwei Stunden konzentrierter Arbeit ausgelegt; Teil D ist der Expertenteil für den Feinschliff. Halten Sie den Umfang klein und die Struktur sauber; bewertet wird das Zusammenspiel, nicht die Featureliste.

Teil A - Modell und Datenformat (vor der ersten Codezeile)

1. Zeichnen Sie ein Klassendiagramm mit mindestens Vocable (Fremdwort, Übersetzung, Zähler richtig/falsch), VocableSet (Name, Liste von Vokabeln) und Trainer (Abfragelogik).
2. Zeichnen Sie ein Zustandsdiagramm des Trainingsablaufs (mindestens: Frage angezeigt, Antwort ausgewertet, Runde beendet).
3. Definieren Sie Ihr JSON-Format für ein Vokabelset und dokumentieren Sie es mit einem kommentierten Beispiel von drei Vokabeln. Dieses Format ist der Vertrag Ihrer Anwendung.

Teil B - Fachlogik mit Tests

1. Implementieren Sie die drei Klassen GUI-frei in eigenen Modulen. Laden und Speichern der Sets läuft über JSON mit vollständiger Fehlerbehandlung: fehlende Datei, kaputtes JSON und fehlende Pflichtfelder führen zu einer eigenen Exception mit verständlicher Meldung.
2. Der Trainer liefert die nächste abzufragende Vokabel und verbucht Antworten (check_answer(text) aktualisiert die Zähler und liefert richtig/falsch).
3. Mindestens sechs pytest-Tests für Logik und Laden (inklusive eines Fehlerfalls mit pytest.raises). Alle grün, bevor die GUI entsteht.

Teil C - Die Anwendung

1. Trainingsmodus als Tkinter-Oberfläche: Set wählen, Vokabel wird angezeigt, Antwort eingeben, sofortige Rückmeldung, laufende Statistik (richtig/falsch, Quote); der Fortschritt wird beim Beenden gespeichert.
2. Gewichtete Auswahl: Vokabeln mit schlechter Quote kommen häufiger dran. Eine einfache, selbst entworfene Formel genügt; dokumentieren Sie sie im README und begründen Sie die Wahl in zwei Sätzen.
3. Robustheit: Kein Eingabe- oder Dateifehler bringt den Trainer zum Absturz; Meldungen laufen über messagebox.
4. Git-Workflow von Beginn an: Feature-Branches, sprechende Commits, mindestens ein gemergter Branch.

Teil D - Expertenteil: Verwaltung, Varianten, Präsentation

1. Verwaltungsmodus: Vokabeln hinzufügen, bearbeiten, löschen; neues Set anlegen. Eigenes Fenster (Toplevel) oder eigener Bereich, ebenfalls strikt über die Fachlogik.
2. Fragevarianten über einen Vertrag: abstrakte Klasse Question mit Subklassen TextInputQuestion und MultipleChoiceQuestion (drei Ablenker aus dem Set). Ein Vertragstest stellt sicher, dass jede Variante auswertbar ist.
3. README vervollständigen: Screenshot, Startanleitung, Formatdokumentation, bekannte Grenzen.
4. Fünfminütige Demo vor der Gruppe: eine Trainingsrunde, ein absichtlich provozierter Fehlerfall, ein Blick in Tests und Git-Historie. Bereiten Sie eine Antwort auf die Frage vor: “Welche Entwurfsentscheidung würden Sie heute anders treffen, und warum?”

Wissenscheck

1. Warum steht das Modell (Diagramme, Datenformat) vor der ersten Codezeile? Nennen Sie zwei konkrete Fehler, die es verhindert.
2. Ihr JSON-Format ist “der Vertrag Ihrer Anwendung”. Wer sind die Vertragsparteien, und was passiert bei Vertragsbruch?
3. Warum muss die Gewichtungsformel in der Fachlogik liegen und nicht im GUI-Code?
4. Wozu dient der Vertragstest bei den Fragevarianten, wenn beide Varianten ohnehin von Ihnen stammen?
5. Woran erkennt eine Betrachterin an Ihrer Git-Historie, wie dieses Projekt entstanden ist?

Abgabe

Repository-Link mit vollständigem README; die Historie zeigt Branches und Merges. Diagramme aus Teil A liegen im Repository. Die Demo findet im Unterricht statt.

Beurteilungshinweise

Bewertet werden: Funktionalität (40 %), Codequalität und Schichtentrennung (25 %), Tests (15 %), Git-Workflow (10 %), Modell und README (10 %).