Worum es hier geht
In den anderen Aufgaben übst du UML „pur". Hier wendest du es auf das Modul an: Bevor in LS3 die Nordfracht-Datenaustausch-Anwendung programmiert wird, wird sie modelliert. Das Klassendiagramm liefert den Bauplan der Software, das Aktivitätsdiagramm den Ablauf der Datenverarbeitung von der Quelle bis zur Bereitstellung.
Ausgangssituation
Die Nordfracht Logistik GmbH erhält Auftragsdaten ihrer Partner als CSV-Dateien. Diese sollen eingelesen, geprüft, in die interne Datenbank übernommen und anderen Systemen anschließend als JSON über eine REST-Schnittstelle bereitgestellt werden. Ein Auftrag gehört zu genau einem Kunden und besteht aus mindestens einer Position.
Klassendiagramm – Bauplan der Anwendung
Anforderungen
- Modellieren Sie die Fachklassen Kunde, Auftrag und Position mit je drei sinnvollen Attributen samt Datentyp und Sichtbarkeit.
- Bilden Sie die Beziehungen ab: ein Kunde kann mehrere Aufträge erteilen; ein Auftrag besteht aus seinen Positionen (Komposition). Vergeben Sie korrekte Multiplizitäten.
- Ergänzen Sie eine Persistenzklasse AuftragRepository (Zugriff auf die Datenbank) und eine Transferklasse AuftragDto (Serialisierung für REST/JSON). Kennzeichnen Sie deren Rolle mit einem Stereotyp.
- Zeichnen Sie die Abhängigkeiten von Repository und DTO zur Klasse Auftrag als gestrichelte Beziehung.
✅ Musterlösung
Wichtige Punkte (UML 2.5.1)
- Komposition (gefüllte Raute) zwischen Auftrag und Position: ohne Auftrag existiert die Position nicht – Lebensdauer gekoppelt. Die Raute steht am „Ganzen" (Auftrag).
- Multiplizität 1..* erzwingt mindestens eine Position; 0..* erlaubt Kunden ohne Auftrag.
- «DTO» trennt das interne Domänenmodell von der Schnittstellen-Darstellung – Kern von LF8: nicht die DB-Entität wird serialisiert, sondern ein angepasstes Objekt.
- Repository und DTO hängen über eine gestrichelte Abhängigkeit an Auftrag, nicht über eine Assoziation – sie „kennen" Auftrag, halten ihn aber nicht dauerhaft.
🎯 IHK-Bezug (AP2)
Im AP2 wird das Klassendiagramm fast immer aus einem Text abgeleitet. Achte besonders auf die Unterscheidung Assoziation / Aggregation / Komposition und auf korrekte Multiplizitäten – dort werden die meisten Punkte verschenkt.
Aktivitätsdiagramm – Ablauf der Datenverarbeitung
Anforderungen
- Modellieren Sie den Ablauf von der CSV-Quelle bis zur REST-Bereitstellung mit Startknoten, Aktionen und Endknoten.
- Bauen Sie zwei Entscheidungsknoten ein: ist das Dateiformat gültig? sind die Datensätze gültig? – jeweils mit beschrifteten Bedingungen ([ja]/[nein]).
- Ungültige Datensätze werden protokolliert, der gültige Rest läuft weiter (Merge-Knoten). Ein ungültiges Dateiformat bricht den Vorgang ab.
- Schließen Sie mit den Schritten Transformation → Speichern (EF6) → Bereitstellen als JSON.
✅ Musterlösung
Wichtige Punkte (UML 2.5.1)
- Entscheidungsknoten (Raute, ein Eingang, mehrere Ausgänge) immer mit Bedingung in eckigen Klammern. Bedingungen müssen sich gegenseitig ausschließen.
- Merge-Knoten (Raute, mehrere Eingänge, ein Ausgang) führt die Pfade wieder zusammen – wird gern mit der Entscheidung verwechselt, ist aber das Gegenstück.
- Zwei Endknoten sind hier korrekt: Abbruch bei ungültigem Format vs. regulärer Abschluss. Ein Aktivitäts-Endknoten beendet den gesamten Ablauf.
- Der Ablauf bildet die drei LF8-Phasen ab: Quelle (einlesen) → Aufbereitung (validieren, transformieren) → Bereitstellung (speichern, REST).
Brücke zum Modul
Diese beiden Diagramme sind nicht nur Prüfungsübung – sie sind der Entwurf für die Anwendung, die in Woche 4 tatsächlich programmiert wird. Wer den Ablauf hier sauber modelliert, hat die Architektur für den Code schon stehen.