Aufgabe 05 - Jahresprojekt Sprint 1 - Klassen und Abläufe

Lernziele

• Du zeichnest ein Klassendiagramm mit Sichtbarkeit, Beziehungen und Multiplizitäten und liest es laut.
• Du unterscheidest Komposition, Aggregation und Assoziation und erkennst eine Beziehung, die selbst eine Klasse sein muss.
• Du übersetzt Multiplizitäten in Datenstrukturen im Code.
• Du zeichnest für den wichtigsten Ablauf deines Jahresprojekts ein Sequenzdiagramm mit alt-Fragment und prüfst es gegen Klassendiagramm und Code.

Ausgangslage

Zweite Woche von Sprint 1. Im Use-Case-Diagramm aus Aufgabe 04 steht, wer was erreichen will. Jetzt kommen die zweite und dritte Karte der Navi-App aus Kapitel 09: der Stadtplan (Klassendiagramm: welche Dinge gibt es, wie hängen sie zusammen) und die Routenanweisung (Sequenzdiagramm: wer ruft wen in welcher Reihenfolge). In eurem Repository entsteht gerade der erste Code. Genau jetzt lohnt sich der Blick, ob Modell und Code dasselbe meinen, denn Multiplizitäten sind Programmcode.

Die Kata: Schulradio-Sendeplan. Das Schulradio plant seine Sendungen:

• Eine Sendung hat einen Titel, einen Sendetermin und besteht aus einem oder mehreren Beiträgen in fester Reihenfolge. Wird eine Sendung gelöscht, verschwinden ihre Beiträge mit.
• Ein Beitrag hat eine Dauer in Sekunden und kann ein Musikstück aus dem Archiv verwenden, muss aber nicht. Ein Musikstück bleibt im Archiv, auch wenn keine Sendung es mehr verwendet.
• Moderatorinnen und Moderatoren moderieren Sendungen, eine Sendung hat mindestens eine Person am Mikrofon. Für jede Moderation wird festgehalten, ob die Person Haupt- oder Co-Moderation macht.
• Eine Sendung kann ihre Gesamtdauer berechnen.

Dafür brauchst du:

• Kapitel 09 UML II – Klassen- und Sequenzdiagramm (Sichtbarkeit, Beziehungsarten, Multiplizitäten, Komposition und Aggregation, vom Diagramm zum Code, Sequenzdiagramm mit Fragmenten, Nachrichten sind Methodenaufrufe).
• Dein Use-Case-Diagramm und die Beschreibung aus Aufgabe 04.
• Mermaid (classDiagram, sequenceDiagram), draw.io oder eine gut lesbare Handskizze.

Allgemein

Projektordner anlegen siehe https://qiz.at/projektordner

• Lies vorher kurz https://qiz.at/assignmentsabgabe durch.
• Nur vollständige Abgaben (siehe https://qiz.at/rules) können positiv bewertet werden.
• Abgabe- und Testdetails siehe https://qiz.at/assignmentsabgabe
• Abgegeben wird dein Projektordner mit einer README.md: darin die Kata und die Links auf die Issues, Merge Requests und Dateien dieser Woche im Jahresprojekt-Repository. Diagramme liegen im Repository des Teams unter docs/uml/.
• Wer was beigetragen hat, zeigen Board, Merge Requests und /spend-Einträge (Kapitel 07).

Wesentlich_überwiegend

Aufgabe

• Kata: Zeichne das Klassendiagramm des Sendeplans mit mindestens vier Klassen, Sichtbarkeit bei jedem Attribut und jeder Operation und Multiplizitäten an jeder Linie. Lies jede Linie laut als Satz vor und korrigiere sie, wenn der Satz fachlich falsch klingt.
• Begründe die Komposition und die Beziehung zwischen Beitrag und Musikstück mit der Frage, was mit dem Teil geschieht, wenn das Ganze verschwindet. Entscheide, ob die Beziehung zwischen Sendung und Moderator:in eine eigene Klasse braucht, und begründe es in einem Satz.
• Übersetze drei Linien in eine Tabelle mit den Spalten Linie, Multiplizität und Datenstruktur im Code (Pflichtfeld im Konstruktor, optionales Feld oder Array).

Tipp: Trage jede Beziehung nur als Linie ein, nicht zusätzlich als Attribut. Eine Beziehung, die eigene Eigenschaften trägt, ist wie eine Zwischentabelle in der Datenbank. Getter und Setter gehören nicht ins Diagramm.

Bewertungskriterien

Vollständig, wenn:

• das Diagramm mindestens vier Klassen, Sichtbarkeit bei jedem Element und laut lesbare, fachlich richtige Multiplizitäten an jeder Linie hat und keine Beziehung doppelt als Linie und Attribut enthält,
• Komposition und Aggregation bzw. Assoziation mit dem Lebenszyklus des Teils begründet sind und die Moderation als eigene Klasse erkannt ist,
• die Tabelle drei Multiplizitäten der passenden Datenstruktur zuordnet.

Abgabe

Wie unter Allgemein.

Wesentlich_vollständig

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

• Zeichnet das Klassendiagramm der Kern-Entitäten eures Jahresprojekts (mindestens vier Klassen, Multiplizitäten, Sichtbarkeit) in docs/uml/classes.md. Vergleicht es mit den Typen und Klassen, die in Sprint 1 schon im Code existieren, und notiert jede Abweichung (Klasse fehlt im Code, Feld heißt anders, Multiplizität passt nicht zum Typ).
• Zeichnet für den Standardablauf des wichtigsten Anwendungsfalls aus Aufgabe 04 das Sequenzdiagramm in docs/uml/sequence-<ablauf>.md, quer durch eure Schichten (Oberfläche, Fachlogik, Datenzugriff), mit höchstens fünf Lebenslinien, Antworten und mindestens einem alt-Fragment aus einem Alternativablauf.
• Führt die Gegenprobe durch: Sucht jede Nachricht als Operation beim Empfänger, im Klassendiagramm und im Code (Datei und Funktion oder „noch nicht gebaut“). Ergänzt das Klassendiagramm und legt für jede Operation, die im Code fehlt und in Sprint 1 gebraucht wird, einen Task an der passenden Story an.
• Bringt beide Diagramme über einen Merge Request mit Review nach dev.

Tipp: Eine Gegenprobe ohne Befund ist bei einem ersten Entwurf selten, schau genau hin. Das Sequenzdiagramm zeigt die Kommunikation, nicht die Berechnung; mehr als zwei bis drei alt-Zweige oder fünf Lebenslinien sind ein Zeichen, dass du zerlegen solltest.

Bewertungskriterien

Vollständig, wenn:

• das Klassendiagramm zum eigenen Projekt gehört, die Mindestzahlen erfüllt und die Abweichungen zum Code dokumentiert sind,
• das Sequenzdiagramm den Standardablauf durch die Schichten zeigt, höchstens fünf Lebenslinien, Antworten und ein alt-Fragment hat,
• die Gegenprobe jede Nachricht einer Operation in Diagramm und Code zuordnet und die nötigen Ergänzungen bzw. Tasks angelegt sind,
• beide Diagramme über einen Merge Request mit Review gemergt sind.

Abgabe

Wie unter Allgemein.

PlusPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

• Setze die Multiplizitäten eures Klassendiagramms im Code um, in einem eigenen Merge Request: Pflichtbeziehungen als Pflichtfelder (Konstruktor bzw. nicht optionaler Typ), 0..1 als optionales Feld, * als Array, eine fachliche Mindest- oder Höchstzahl als geprüfte Regel mit einem Test.
• Halte im README.md fest, welche Abweichung aus der Gegenprobe ihr damit behoben habt und welche bewusst bleibt.

Tipp: Was bedeutet 1..* für den Moment, in dem das Objekt erzeugt wird? Ein Test für die Regel reicht, wenn er den Fall knapp unter und genau an der Grenze prüft.

Bewertungskriterien

Vollständig, wenn:

• jede Linie des Klassendiagramms im Code wiederzufinden ist und die gewählte Datenstruktur zur Multiplizität passt,
• mindestens eine Mindest- oder Höchstzahl geprüft und getestet ist,
• behobene und bewusst verbleibende Abweichungen benannt sind.

Abgabe

Wie unter Allgemein.

MandalorianPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

• Prüfe jede Vererbung in Modell und Code eures Projekts mit dem Ist-ein-Test. Gibt es keine, suche die Stelle, an der Vererbung am verführerischsten wäre (zum Beispiel verschiedene Arten eines Medienobjekts), und beurteile in drei bis vier Sätzen, ob Vererbung, Komposition oder ein gemeinsames Interface die tragfähigere Wahl ist.
• Wähle einen zweiten, schwierigeren Ablauf eures Projekts (den, bei dem ihr am wenigsten sicher seid, wer wen aufruft) und zeichne sein Sequenzdiagramm. Wird es zu groß, zerlege es in zwei Diagramme und begründe den Schnitt.

Tipp: Vererbung ist der teuerste Pfeil im Klassendiagramm. Eine Klasse, die eine geerbte Methode nicht sinnvoll erfüllen kann, besteht den Test nicht, auch wenn der Satz „ist ein“ gut klingt.

Bewertungskriterien

Vollständig, wenn:

• die Beurteilung eine konkrete Stelle des eigenen Projekts nennt und die Wahl mit dem Ist-ein-Test begründet,
• das zweite Sequenzdiagramm die Grenzen aus Kapitel 09 einhält oder begründet zerlegt ist.

Abgabe

Wie unter Allgemein.

Zeit dafür

Durchschnittlich bis Wesentlich_vollständig: ca. 70 min (5 min Board-Check, 20 min Kata, 45 min Diagramme und Gegenprobe im Projekt)

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules