10. UML III – Von User Stories zu Diagrammen

Nach diesem Kapitel kannst du:

• User Stories und Diagramme ineinander überführen und einen Anwendungsfall in Stories schneiden.
• Use-Case-, Klassen- und Sequenzdiagramm gegeneinander auf Widersprüche prüfen.
• begründen, wann sich ein Diagramm lohnt, und passende Ergänzungen (Zustands-, Aktivitätsdiagramm) vorschlagen.

In den Kapiteln 08 und 09 hast du die drei Karten der Navi-App einzeln gezeichnet: Ziele, Stadtplan und Routenanweisung. In diesem Kapitel verbindest du sie mit den User Stories aus Kapitel 04 und prüfst, ob alle drei Karten zusammenpassen.

Von User Stories zu Diagrammen - und zurück

In Kapitel 04 hast du Anforderungen als User Stories formuliert. In Kapitel 08 begann die Modellierung mit Anwendungsfällen. Das ist kein Widerspruch, sondern dieselbe Information in unterschiedlicher Körnung und mit unterschiedlichem Zweck.

	User Story	Anwendungsfall (Use Case)
Zweck	Platzhalter für ein Gespräch; plant und priorisiert Arbeit	beschreibt eine Interaktion vollständig; klärt Verhalten
Umfang	klein genug für einen Sprint	ein Ziel, oft größer als eine Story
Detailgrad	ein Satz plus Akzeptanzkriterien	Vorbedingung, Standardablauf, Alternativabläufe, Nachbedingung
Lebensdauer	wird im Sprint abgearbeitet und geschlossen	bleibt als Dokumentation bestehen
Wo sie lebt	Backlog, Issue-Tracker	Anforderungsdokument, Diplomarbeit

Die Story beantwortet “Was soll als Nächstes gebaut werden?”, der Anwendungsfall beantwortet “Wie verhält sich das System dabei genau?”. In agilen Projekten schreibt man deshalb nicht zwingend beides für alles: Stories sind der Normalfall, Anwendungsfälle und Diagramme kommen dazu, wo ein Ablauf komplex genug ist, dass ein Satz nicht genügt.

Von der Story zum Diagramm

Jeder Teil der Story-Schablone landet an einer bestimmten Stelle des Modells. Dazu eine Story zum durchgängigen Beispiel:

Als Mitglied
möchte ich ein verfügbares Buch ausleihen,
damit ich es mit nach Hause nehmen kann.

Akzeptanzkriterien:
- Ein verfügbares Buch kann ausgeliehen werden; das Rückgabedatum wird angezeigt.
- Ein bereits verliehenes Buch kann nicht ausgeliehen werden; eine Vormerkung wird angeboten.
- Ein Mitglied mit offenen Gebühren kann nicht ausleihen.

Teil der Story	wird zu	im Beispiel
Als Rolle	Akteur im Use-Case-Diagramm	Member
Möchte ich Funktion	Anwendungsfall (Verb und Objekt)	Borrow book
Damit Nutzen	Nachbedingung und Prüfmaßstab: Wurde das Ziel erreicht?	Das Buch ist verliehen und gespeichert
Nomen in Story und Kriterien	Klassen und Attribute	Member, Book, Loan, Rückgabedatum
Verben in den Kriterien	Operationen und Nachrichten	verfügbar prüfen, ausleihen, vormerken
Akzeptanzkriterium, Normalfall	Standardablauf und damit das Sequenzdiagramm	erstes Kriterium
Akzeptanzkriterium, Ausnahme	Alternativablauf, alt-Fragment, Testfall	zweites und drittes Kriterium

Konkret heißt das: Das Sequenzdiagramm aus Schritt 3 (Kapitel 09) ist die grafische Fassung der ersten beiden Akzeptanzkriterien, und das dritte Kriterium ist ein Alternativablauf, der dort noch fehlt - ein Hinweis, dass entweder das Diagramm unvollständig ist oder die Story zu viel auf einmal verlangt.

Mehrere Stories gehören oft zu einem Anwendungsfall und zu einem Oval im Diagramm. “Als Mitglied möchte ich ein Buch ausleihen” und “Als Mitglied möchte ich ein verliehenes Buch vormerken” sind zwei Stories, die gemeinsam das Ziel Borrow book mit seinem Alternativablauf ergeben. Ein umfangreicher Anwendungsfall entspricht damit eher einem Epic, das sich in mehrere Stories zerlegen lässt.

flowchart LR
  accTitle: Ein Anwendungsfall wird in mehrere Stories geschnitten
  UC["Use Case: Borrow book"] --> S1["Story 1: Buch ausleihen (Standardablauf)"]
  UC --> S2["Story 2: Verliehenes Buch vormerken (Alternativablauf)"]
  UC --> S3["Story 3: Ausleihe bei offener Gebühr sperren (Alternativablauf)"]

Vom Diagramm zur Story

Auch die umgekehrte Richtung kommt vor, und sie ist in agilen Projekten sogar der häufigere Weg, wenn ein größeres Vorhaben erst einmal verstanden werden muss.

• Use Case in Stories schneiden. Ein Anwendungsfall ist meist zu groß für einen Sprint. Der Standardablauf wird die erste Story (dünner, aber durchgängiger Durchstich), jeder Alternativablauf eine weitere. Im Beispiel: Story 1 Buch ausleihen, Story 2 Verliehenes Buch vormerken, Story 3 Ausleihe bei offener Gebühr sperren. Der Wert wächst Sprint für Sprint, und nach Story 1 ist bereits etwas Lauffähiges vorhanden.
• Diagramm deckt fehlende Stories auf. Ein Zustandsdiagramm für Loan zeigt den Zustand überfällig - und niemand hat eine Story dafür geschrieben, was dann passiert. Eine Klasse im Klassendiagramm, die in keinem Ablauf vorkommt, ist ein Hinweis auf eine vergessene Anforderung. Das Diagramm liefert also Fragen an den Product Owner, und aus den Antworten werden neue Stories.
• Diagramm wird zu Tasks, nicht zu Stories. Ein Klassendiagramm ist technisch: “Klasse LoanService anlegen” oder “Tabelle loan erstellen” hat für keine Nutzerin einen sichtbaren Wert und ist deshalb keine Story, sondern ein Task an einer Story (siehe INVEST in Kapitel 04, Kriterium Valuable). Wer aus dem Klassendiagramm Stories macht, landet bei “Als Nutzer möchte ich eine Datenbank”.
• Bestehende Software verstehen. Bei Altsystemen ohne Dokumentation geht man manchmal rückwärts: aus dem Code ein Klassendiagramm, aus dem Ablauf ein Sequenzdiagramm, daraus die tatsächlich unterstützten Anwendungsfälle und schließlich Stories für Änderungen. Das Ergebnis ist eine Schätzung, kein Beweis, denn der Code zeigt, was passiert, nicht was gewollt war.

Wo begegnet dir das? Auf dem Board deines Jahresprojekts in GitLab sind die Issues die Stories. Das Diagramm in der Dokumentation zeigt, wie viele von ihnen zu einem größeren Ziel gehören, und es macht sichtbar, was im Backlog noch fehlt.

Wie viel Modellierung verträgt ein agiles Projekt?

Die Befürchtung, UML und Scrum passten nicht zusammen, beruht meist auf einem Missverständnis: Nicht die Diagramme sind das Problem, sondern ihr Zeitpunkt. Ein vollständiges Modell für alle Anforderungen vor dem ersten Sprint ist der Wasserfall in neuer Verpackung. Bewährt hat sich stattdessen Modellierung just in time.

• Zu den Stories, die im nächsten Sprint anstehen, entsteht eine Skizze am Whiteboard (Fowler: Skizze statt Bauplan, siehe Kapitel 08), und sie wird fotografiert oder abgezeichnet.
• Diagramme, die über den Sprint hinaus nützlich bleiben - Klassenstruktur, zentrale Abläufe -, kommen in die Dokumentation und werden mit dem Code gepflegt.
• Die Skizze wird nicht gepflegt, wenn sie ihren Zweck erfüllt hat. Sie war ein Werkzeug des Gesprächs, nicht ein Ergebnis.

Und die Definition of Done?

Ob zu einer Story ein Diagramm gehört, legt das Team vorab fest, am besten in der Definition of Done: “Bei Änderungen an Klassenstruktur oder zentralen Abläufen ist das Diagramm in der Dokumentation aktualisiert.” Ohne diese Vereinbarung veralten Diagramme ausnahmslos.

Wie die drei Diagramme zusammenhängen

Der Arbeitsablauf ist keine Einbahnstraße, aber er hat eine sinnvolle Reihenfolge:

flowchart LR
  S[User Story mit Akzeptanzkriterien] -->|Rolle und Ziel| A[Use Case mit Beschreibung]
  A -->|zu große Fälle werden in Stories geschnitten| S
  A -->|Nomen werden zu Klassen| B[Klassendiagramm]
  A -->|Standardablauf wird zu Nachrichten| C[Sequenzdiagramm]
  C -->|Nachrichten werden zu Methoden| B
  B -->|Methoden müssen existieren| C
  A -->|Alternativabläufe werden zu Tests| D[Testfälle]

Die Pfeile sind Prüfbeziehungen: Jedes Diagramm liefert dem nächsten Rohmaterial und kontrolliert es zugleich. Wie bei den drei Karten der Navi-App: Erst wenn Ziele, Stadtplan und Route zusammenpassen, kannst du dich auf die Reise verlassen.

Von	Nach	Was geprüft wird
Use Case	Klassendiagramm	Kommt jedes fachliche Nomen aus den Beschreibungen als Klasse oder Attribut vor?
Use Case	Sequenzdiagramm	Gibt es zu jedem wichtigen Standardablauf ein Sequenzdiagramm?
Sequenzdiagramm	Klassendiagramm	Existiert jede Nachricht als Operation in der Klasse des Empfängers?
Klassendiagramm	Sequenzdiagramm	Wird jede Operation in mindestens einem Ablauf wirklich gebraucht? Eine nie gerufene Methode ist entweder überflüssig oder ein vergessener Anwendungsfall.

1. Anwendungsfälle sammeln. Aus den Stories des Backlogs (oder direkt mit dem Auftraggeber) Akteure und ihre Ziele festhalten, die wichtigsten Anwendungsfälle mit Standard- und Alternativabläufen beschreiben.
2. Klassen ableiten. Aus den Nomen der Beschreibungen Kandidaten sammeln, überflüssige streichen (technische Details, Synonyme), Beziehungen und Multiplizitäten festlegen.
3. Ablauf zeichnen. Für jeden wichtigen Anwendungsfall den Standardablauf als Sequenzdiagramm zeichnen.
4. Gegenprüfen. Jede Nachricht im Klassendiagramm suchen, fehlende Operationen und Klassen ergänzen.
5. Wiederholen. Beim Zeichnen von Schritt 3 fällt fast immer etwas an Schritt 1 oder 2 auf - das ist das Ziel, kein Rückschritt.

Merksatz

Die drei Diagramme sind nicht drei Dokumente, sondern drei Blickwinkel, die einander prüfen.

Reicht das für die Praxis?

Für Anforderungen, Struktur und Ablauf eines typischen Schulprojekts: ja, als Grundgerüst. Drei Ergänzungen kommen in Diplomarbeiten aber oft dazu, und du solltest zumindest wissen, wofür sie da sind.

Diagramm	Wann ergänzen	Beispiel
Zustandsdiagramm	Ein Objekt hat einen Lebenszyklus mit klaren Zuständen und Übergängen	Loan: angefragt, aktiv, überfällig, zurückgegeben
Aktivitätsdiagramm	Ein Arbeitsablauf mit Verzweigungen und Parallelität, oft über mehrere Akteure	Bestellprozess von der Bestellung bis zum Versand
Komponenten- und Verteilungsdiagramm	Die technische Architektur soll gezeigt werden: Dienste, Datenbank, Schnittstellen	Frontend, API, Datenbank, externer Zahlungsdienst

So sieht das Zustandsdiagramm für die Ausleihe aus. Es zeigt auf einen Blick, welche Zustände eine Loan kennt und was sie weiterschaltet.

stateDiagram-v2
  accTitle: Lebenszyklus einer Ausleihe
  [*] --> Active : Buch ausgeliehen
  Active --> Overdue : Rückgabedatum überschritten
  Overdue --> Returned : Buch zurückgegeben, Gebühr bezahlt
  Active --> Returned : Buch zurückgegeben
  Returned --> [*]

Das Entity-Relationship-Diagramm für die Datenbank gehört nicht zur UML, sieht dem Klassendiagramm aber ähnlich. Es modelliert Tabellen und Schlüssel, nicht Klassen und Operationen; im Datenbankunterricht lernst du es genauer kennen.

Wo begegnet dir das? Der Bestellstatus in einem Webshop (bestellt, bezahlt, versandt, geliefert) ist ein Zustandsdiagramm, das du aus dem Alltag kennst. Wer Software für einen solchen Ablauf baut, braucht genau dieses Modell.

Wichtiger als die Anzahl der Diagrammtypen ist deshalb die Haltung: Modelliert wird, was eine Entscheidung klärt oder eine Frage beantwortet. Ein Diagramm, das niemand liest und das nach der Abgabe nie wieder geöffnet wird, war Aufwand ohne Nutzen.

Die häufigsten Fehler

“Das Klassendiagramm ist die Datenbank.” Klassen modellieren Verhalten und Struktur im Programm, Tabellen modellieren Daten auf der Platte. Beides kann ähnlich aussehen und ist trotzdem nicht dasselbe.

Doppelte Information. Eine Beziehung wird als Linie gezeichnet und zusätzlich als Attribut (loans : Loan[]) in die Klasse geschrieben. Entweder Linie oder Attribut, nie beides - sonst widersprechen sich die beiden Darstellungen bei der nächsten Änderung.

Anwendungsfälle als Funktionsliste. “Datenbank speichern”, “Eingabe prüfen”, “Fenster öffnen” sind Implementierungsdetails. Ein Anwendungsfall ist ein Ziel einer Akteurin, nicht eine Methode.

Das Diagramm als Selbstzweck. Wer UML zeichnet, nur weil es verlangt wird, und danach anders programmiert, hat ein Dokument erzeugt, das beim ersten Commit veraltet ist. Ein Diagramm gehört mit dem Code zusammen gepflegt oder bewusst als “Entwurfsstand vom …” gekennzeichnet.

Mini-Projekt: ein Quiz-System modellieren

Wende die drei Diagramme auf ein neues System an. Das Mini-Projekt ist eine Übungsfassung zum Selberprobieren an einem fremden System; im eigenen Jahresprojekt machst du dasselbe in Aufgabe 04 bis 06. Hier steht der Kern des ganzen Mini-Projekts. Die Aufgabe ist bewusst offen; zeichne auf Papier, im Whiteboard-Tool deiner Wahl oder mit draw.io.

Ausgangslage: Eine Quiz-Anwendung für den Unterricht. Lehrpersonen legen Quizze mit Fragen an, Schülerinnen und Schüler spielen ein Quiz und sehen danach ihre Punkte. Ein Quiz besteht aus mehreren Fragen, jede Frage hat mehrere Antwortmöglichkeiten, von denen mindestens eine richtig ist.

1. Use-Case-Diagramm: Bestimme die Akteure und mindestens fünf Anwendungsfälle. Verwende mindestens ein include oder extend und begründe in einem Satz, warum es diese Beziehung und nicht die andere ist.
2. Beschreibung: Schreibe für den wichtigsten Anwendungsfall die Beschreibung mit Vorbedingung, Standardablauf, mindestens einem Alternativablauf und Nachbedingung.
3. Klassendiagramm: Leite aus deiner Beschreibung mindestens vier Klassen ab. Gib Sichtbarkeit, Multiplizitäten und mindestens eine Komposition an und begründe, warum es eine Komposition und keine Assoziation ist.
4. Sequenzdiagramm: Zeichne den Standardablauf aus Schritt 2 mit mindestens einem alt-Fragment.
5. Gegenprobe: Prüfe, ob jede Nachricht deines Sequenzdiagramms als Operation im Klassendiagramm steht. Notiere, was du dabei ergänzen musstest.

Eine einzige “richtige” Lösung gibt es hier nicht: Ob deine Klassen “richtig” sind, entscheidet die Frage, ob der Ablauf damit ohne Widerspruch erklärbar ist, und nicht der Vergleich mit einer fremden Lösung.

Tipp: von Mermaid nach draw.io

Du musst dich nicht zwischen Text und Zeichnen entscheiden. draw.io kann Mermaid-Code einlesen: Über Anordnen > Einfügen > Mermaid (englisch Arrange > Insert > Mermaid) fügst du den Quelltext eines Diagramms ein, und draw.io erzeugt daraus je nach Auswahl entweder bearbeitbare draw.io-Formen (Diagram) oder ein festes SVG-Bild (Image). So schreibst du das Grundgerüst schnell als Text, zum Beispiel das Klassendiagramm aus Kapitel 09, und arbeitest es anschließend grafisch nach, etwa für eine Abgabe oder Präsentation.

Zwei Einschränkungen solltest du kennen. Erstens läuft der Weg nur in eine Richtung: Aus draw.io wird kein Mermaid-Code zurückgeschrieben. Was du in draw.io nachbearbeitest, geht beim erneuten Einfügen der Mermaid-Quelle verloren, entscheide dich also vorab, welche der beiden Fassungen die maßgebliche ist. Zweitens muss die in draw.io eingebaute Mermaid-Version den jeweiligen Diagrammtyp kennen; das neue usecase-beta-Diagramm aus Schritt 1 (Kapitel 08) funktioniert dort unter Umständen noch nicht. Ob es klappt, zeigt ein kurzer Versuch. Die Menüführung findest du in der draw.io-Dokumentation: Insert and edit a Mermaid diagram.

Zusatzmaterialien

• uml-diagrams.org - gut gegliederte Referenz zu allen UML-Diagrammtypen mit Beispielen; hilfreich, wenn du über die drei Diagramme der Kapitel 08 bis 10 hinausgehen willst.
• draw.io: Insert and edit a Mermaid diagram - zeigt, wie ein Mermaid-Text in bearbeitbare draw.io-Formen umgewandelt wird, wenn du ein Diagramm grafisch nachbearbeiten willst.

Zum Anhören

Du kannst dir diesen Text mit der Vorlesefunktion deines Browsers oder Betriebssystems kostenlos anhören, etwa mit “Laut vorlesen” in Microsoft Edge. Das eignet sich gut zum Wiederholen vor der Schularbeit.

Lernergebnisse: Was du nach diesem Kapitel können solltest

• Anwenden: User Stories in Anwendungsfälle und Diagramme überführen und einen Anwendungsfall in Stories schneiden.
• Analysieren: Use-Case-, Klassen- und Sequenzdiagramm gegeneinander auf Widersprüche prüfen.
• Beurteilen: begründen, ob ein Diagramm eine Entscheidung klärt oder nur Aufwand erzeugt, und passende Ergänzungen (Zustands-, Aktivitätsdiagramm) vorschlagen.

Passende Übungen

• Aufgabe 06 - Jahresprojekt Sprint 1 - Review, Stories und Modell: Kata: eine Story den Modellelementen zuordnen, dazu Review und Retrospektive von Sprint 1 (Wesentlich_überwiegend); Release und einen Anwendungsfall in Stories schneiden (Wesentlich_vollständig). PlusPlus: die vier Prüfbeziehungen an den eigenen Diagrammen, Zustandsdiagramm und Story oder Task; MandalorianPlus: Modellierung just in time und eine Zeile für die Definition of Done.

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules