8. UML I – Use-Case-Diagramm

Nach diesem Kapitel kannst du:

• die drei Diagrammtypen Use-Case-, Klassen- und Sequenzdiagramm mit ihrer Leitfrage nennen und einer Phase des Entwicklungsprozesses zuordnen.
• begründen, wann sich UML lohnt, und zwischen Skizze und Bauplan unterscheiden.
• include und extend unterscheiden und deine Wahl begründen.
• zu einer Beschreibung ein Use-Case-Diagramm zeichnen und den wichtigsten Anwendungsfall mit Vorbedingung, Standardablauf, Alternativablauf und Nachbedingung beschreiben.

Stell dir vor, du planst mit der Navi-App eine Reise in eine fremde Stadt. Die App kennt drei Karten derselben Stadt: eine Übersicht, wer wohin will (Altstadt, Bahnhof), den Stadtplan mit Straßen, Stationen und Linien und die Routenanweisung, die sagt, was in welcher Reihenfolge passiert. Keine der Karten ersetzt die anderen, aber alle drei müssen zusammenpassen: Fährt laut Routenanweisung eine Linie, die im Stadtplan keine Haltestelle hat, stimmt irgendwo etwas nicht.

Bei der UML (Unified Modeling Language) ist es genauso. Das Use-Case-Diagramm ist die Karte der Ziele, das Klassendiagramm der Stadtplan, das Sequenzdiagramm die Routenanweisung. Dabei hinkt der Vergleich an einer Stelle: Die Stadt gibt es schon, dein System noch nicht. Du zeichnest die Karten vor dem Bauen, und die Widersprüche zwischen ihnen findest du, bevor sie als Fehler im Code stehen.

Du programmierst seit vier Jahren und hast wahrscheinlich schon erlebt, was passiert, wenn mehrere Personen an einem System arbeiten, das nur in einem Kopf existiert: Jede Person baut ihr eigenes Bild davon, und die Bilder stimmen nicht überein. Das fällt erst bei der Integration auf. UML bringt dieses Bild aus dem Kopf auf eine Fläche, die alle lesen, vergleichen und kritisieren können.

Dieses und die beiden folgenden Kapitel behandeln bewusst nur drei der vierzehn UML-Diagrammtypen. Nicht, weil die anderen unwichtig wären, sondern weil diese drei drei verschiedene Fragen beantworten und einander gegenseitig prüfen. Wer die Diagramme nur einzeln zeichnen kann, hat Notation gelernt. Wer sie gegeneinander prüfen kann, hat modelliert.

Begriffe vorab

• Akteur (actor): eine Rolle außerhalb des Systems, die mit ihm interagiert.
• Anwendungsfall (use case): ein Ziel, das ein Akteur mit dem System erreicht.
• Klasse (class) mit Attributen und Operationen: ein Baustein des Systems mit seinen Daten und Fähigkeiten.
• Multiplizität (multiplicity): die Zahl an einem Linienende, die sagt, wie viele Objekte beteiligt sind.
• Lebenslinie (lifeline): ein Beteiligter über die Zeit im Sequenzdiagramm.
• Nachricht (message): ein Pfeil zwischen zwei Lebenslinien, im Code ein Methodenaufruf.

UML lohnt sich dort, wo ein Kopf nicht mehr reicht

Die ehrliche Antwort auf die Frage, ob man nicht gleich programmieren kann, lautet: Für ein Programm, das eine Person an einem Nachmittag schreibt, braucht man UML nicht. Es lohnt sich dort, wo mindestens eine der folgenden Situationen vorliegt.

• Mehrere Personen müssen sich auf Schnittstellen einigen, bevor sie parallel arbeiten können.
• Der Auftraggeber (oder die Betreuungsperson der Diplomarbeit) soll beurteilen, ob das Richtige gebaut wird, kann aber keinen Code lesen.
• Eine Entscheidung ist teuer zu ändern, etwa die Aufteilung in Klassen oder der Ablauf über mehrere Systeme hinweg. Auf dem Papier kostet das Umbauen Minuten, im Code Tage.
• Das System muss später erklärt werden - in der Diplomarbeit, bei der Übergabe, nach einem halben Jahr, wenn du den Code selbst nicht mehr verstehst.

Martin Fowler unterscheidet drei Arten, UML zu verwenden, und die Unterscheidung klärt viele Missverständnisse:

Verwendung	Zweck	Anspruch an Vollständigkeit
Skizze	eine Idee besprechen, einen Entwurf im Team abstimmen	bewusst unvollständig, Whiteboard oder Papier genügt
Bauplan	Implementierung vorbereiten oder dokumentieren	vollständig genug, dass andere danach implementieren können
Programmiersprache	aus dem Modell automatisch Code erzeugen	vollständig und formal, braucht Spezialwerkzeuge

flowchart LR
  accTitle: Drei Arten, UML zu verwenden, mit steigender Vollständigkeit
  A["Skizze: Idee im Team besprechen"] -->|mehr Detail| B["Bauplan: andere können danach implementieren"]
  B -->|noch mehr Detail| C["Programmiersprache: Code wird erzeugt"]

In diesem Kapitel und in der Diplomarbeit meinen wir Skizze und Bauplan. Der Anspruch “aus dem Diagramm entsteht automatisch das Programm” ist in der Praxis selten und nicht Ziel dieses Kapitels.

Wo begegnet dir das? Wenn du in einem GitLab- oder GitHub-Projekt eine README mit einem Diagramm siehst, ist das fast immer eine Skizze oder ein Bauplan für genau diesen Zweck: Neue Teammitglieder sollen verstehen, wie das System aufgebaut ist, ohne zuerst den ganzen Code zu lesen. In deinem Jahresprojekt und in der Diplomarbeit ist das nicht anders.

Kurz nachgedacht

Drei Vorhaben: (a) ein Skript, das du allein an einem Nachmittag schreibst, (b) ein Jahresprojekt mit vier Personen und einem Auftraggeber, (c) die Übergabe eines Systems an ein neues Team. Bei welchen lohnt sich UML, und als Skizze oder als Bauplan?

Auflösung

(a) Nein, dafür genügt der Code selbst. (b) Ja, als Skizze für Absprachen und teilweise als Bauplan, weil mehrere Personen parallel arbeiten und der Auftraggeber kein Code liest. (c) Ja, als Bauplan: Hier ist die Dokumentation das Ergebnis, und die Diagramme sind dafür gedacht, dass andere sie ohne dich verstehen.

Weiterlesen

• Martin Fowler, UML Mode - kurze Gegenüberstellung von Skizze, Bauplan und Programmiersprache mit der Empfehlung, UML überwiegend als Skizze zu nutzen.

Drei Fragen, drei Diagramme

Jedes der drei Diagramme beantwortet genau eine Frage und gehört zu einer bestimmten Stelle im Entwicklungsprozess. Dieselbe Zuordnung kennst du bereits aus dem V-Modell in Kapitel 01.

Diagramm	Frage	Sicht	Typische Phase	Gegenstück im V-Modell
Use-Case-Diagramm	Wer macht mit dem System was?	von außen, aus Sicht der Nutzenden	Anforderungen	Abnahmetest
Klassendiagramm	Aus welchen Bausteinen besteht das System und wie hängen sie zusammen?	von innen, statische Struktur	Entwurf	Modul- und Integrationstest
Sequenzdiagramm	Was passiert in welcher Reihenfolge, wenn ein Anwendungsfall abläuft?	von innen, zeitlicher Ablauf	Entwurf	Integrationstest

flowchart LR
  accTitle: Welches Diagramm zu welcher Phase gehört
  A["Anforderungen"] --> B["Use-Case-Diagramm: Wer will was?"]
  C["Entwurf"] --> D["Klassendiagramm: Welche Bausteine?"]
  C --> E["Sequenzdiagramm: Was passiert wann?"]

Als durchgängiges Beispiel verwenden wir eine Bibliotheksverwaltung (LibraryApp): Mitglieder suchen und leihen Bücher, Bibliothekarinnen und Bibliothekare verwalten den Bestand. Am Ende von Kapitel 10 modellierst du selbst ein anderes System.

Englische Bezeichner in den Diagrammen

Klassen-, Attribut- und Methodennamen stehen in den Diagrammen auf Englisch (Book, Member, borrow()), weil sie später im Code so heißen sollen. Wer im Diagramm Buch und im Code Book schreibt, führt zwei Namen für dieselbe Sache und verliert genau die Nachvollziehbarkeit, für die man das Diagramm zeichnet. Beschriftungen für Menschen (Namen der Anwendungsfälle, Erläuterungen) dürfen deutsch sein.

Wo begegnet dir das? Fast jede Dokumentation einer größeren Software verwendet genau diese Aufteilung: eine Übersicht der Rollen und Ziele, eine Strukturansicht und Abläufe für die kritischen Funktionen. Das ist dieselbe Dreiteilung wie bei den Karten in der Navi-App.

Schritt 1: Use-Case-Diagramm - wer macht was?

Das Use-Case-Diagramm hält fest, wer das System benutzt und welche Ziele diese Personen damit erreichen wollen. Es sagt nichts darüber, wie das System intern funktioniert, und das ist Absicht: Es ist das Diagramm, das auch der Auftraggeber noch versteht.

Die Bausteine des Use-Case-Diagramms

Element	Notation	Bedeutung
Akteur	Strichmännchen (oder Kasten mit actor)	eine Rolle außerhalb des Systems, die mit ihm interagiert - auch ein Fremdsystem (Zahlungsdienst, Zeitgeber)
Anwendungsfall (use case)	Oval mit Beschriftung	ein Ziel, das ein Akteur mit dem System erreicht und das für ihn einen Wert hat
Systemgrenze	Rechteck um die Anwendungsfälle	trennt, was zum System gehört und was nicht
Assoziation	Linie Akteur - Anwendungsfall	der Akteur ist an diesem Anwendungsfall beteiligt
include	gestrichelter Pfeil mit include	der Anwendungsfall enthält immer einen anderen als Teilschritt
extend	gestrichelter Pfeil mit extend	ein Anwendungsfall wird nur unter einer Bedingung erweitert
Generalisierung	Pfeil mit unausgefülltem Dreieck	Spezialisierung von Akteuren oder Anwendungsfällen

Das Beispiel: Use Cases der LibraryApp

usecase-beta
  actor Member
  actor Librarian
  actor PaymentService

  systemBoundary LibraryApp
    Search(Search books)
    Borrow(Borrow book)
    Login(Log in)
    Pay(Pay late fee)
    Manage(Manage catalogue)
  end

  Member --> Search
  Member --> Borrow
  Librarian --> Manage
  Librarian --> Borrow
  PaymentService --> Pay
  Borrow --include--> Login
  Manage --include--> Login
  Pay --extend--> Borrow

Mermaid-Version

Use-Case-Diagramme (usecase-beta) gibt es in Mermaid erst ab Version 12; die Syntax ist noch als Beta gekennzeichnet und kann sich ändern. Wenn deine Mermaid-Version das Diagramm nicht darstellt, zeigt sie nur eine Fehlermeldung. Dann hilft ein Update oder ein Werkzeug mit stabiler Notation wie draw.io oder PlantUML. Beachte auch bei der Syntax: Anwendungsfälle werden ohne Schlüsselwort als Id(Titel) im Block systemBoundary angelegt, Beziehungen stehen außerhalb des Blocks, und include bzw. extend schreibst du als beschrifteten Pfeil (A --include--> B). Mermaid zeichnet diese Pfeile durchgezogen, in UML wären sie gestrichelt. Bei extend zeigt der Pfeil, wie in UML üblich, von der Erweiterung zum erweiterten Anwendungsfall.

Wo begegnet dir das? Jeder Webshop hat mindestens zwei Rollen mit ganz verschiedenen Zielen: Kundinnen und Kunden suchen und bestellen, Mitarbeitende pflegen Sortiment und Lieferungen. Dasselbe Prinzip steckt hinter dem Rechtemodell vieler Apps: Wer welche Rolle hat, entscheidet, welche Anwendungsfälle sichtbar sind.

Weiterlesen

• Mermaid: Use Case Diagram - Syntax für Akteure, Systemgrenzen, include, extend und Generalisierung.

Genauer erklärt: was ein guter Anwendungsfall ist

Die meisten schwachen Use-Case-Diagramme scheitern an der Frage, was überhaupt ein Anwendungsfall ist. Eine brauchbare Prüffrage lautet: Hat der Akteur danach etwas erreicht, wofür er das System überhaupt geöffnet hat?

• “Buch ausleihen” ist ein Anwendungsfall: Danach hält das Mitglied das Buch in der Hand.
• “Passwort eingeben” ist keiner: Danach hat niemand etwas erreicht, es ist ein Bedienschritt.
• “In Datenbank speichern” ist keiner: Es ist eine technische Funktion, die kein Akteur als Ziel hat.

Als Faustregel steht der Name im Format Verb + Objekt aus Sicht der Akteurin (“Buch ausleihen”, nicht “Ausleihmodul”). Zwei weitere Regeln verhindern die häufigsten Fehler.

• Akteure sind Rollen, keine Personen. Dieselbe Person kann in einer Bibliothek Member und Librarian sein; im Diagramm sind das zwei Akteure. Zeichne nicht “Frau Meier” als Akteur, sondern ihre Rolle.
• Das Diagramm ist ein Inhaltsverzeichnis, kein Inhalt. Der eigentliche Wert steckt in der Beschreibung jedes Anwendungsfalls (siehe unten). Ein Diagramm mit 25 Ovalen ohne Beschreibungen sagt weniger als vier Ovale mit sauberem Ablauf.

include oder extend?

Die beiden Beziehungen werden in jeder Prüfung verwechselt, weil beide nach “gehört irgendwie dazu” aussehen. Der Unterschied ist die Frage, ob der Teilschritt immer passiert.

	include	extend
Ist der Teilschritt optional?	nein, er passiert immer	ja, nur wenn eine Bedingung zutrifft
Wer kennt wen?	der Basisfall kennt den enthaltenen Fall	die Erweiterung kennt den Basisfall, nicht umgekehrt
Pfeilrichtung	vom Basisfall zum enthaltenen Fall	von der Erweiterung zum Basisfall
Typischer Zweck	gemeinsamen Teil herausziehen (Log in)	seltenen Sonderfall abspalten (Pay late fee)
Beispiel	Borrow book enthält Log in	Borrow book wird bei überfälligem Buch um Pay late fee erweitert

Konkret heißt das: Wenn du das Ausleihen ohne Anmeldung nicht durchführen kannst, ist die Anmeldung ein include. Wenn die Gebühr nur anfällt, weil ein Buch überfällig war, ist sie ein extend - der Basisfall funktioniert auch ohne sie. Und wenn du unsicher bist: Meist genügt gar keine der beiden Beziehungen. Beide Konstrukte zerlegen Anwendungsfälle in Teile, und wer damit anfängt, zeichnet schnell ein Funktionsdiagramm statt eines Anforderungsdiagramms.

Kurz nachgedacht

In einem Webshop gibt es den Anwendungsfall Bestellung abschließen. Dazu gehören Warenkorb prüfen und Gutschein einlösen. Welcher der beiden Teilschritte ist ein include, welcher ein extend?

Auflösung

Warenkorb prüfen ist ein include: Ohne diese Prüfung lässt sich keine Bestellung abschließen, der Schritt passiert immer. Gutschein einlösen ist ein extend: Er passiert nur, wenn die Kundin einen Gutschein hat, und die Bestellung funktioniert auch ohne ihn.

Die Beschreibung macht den Anwendungsfall

Jeder wichtige Anwendungsfall bekommt eine kurze, einheitliche Beschreibung. Das ist in der Praxis ein einfaches Formular:

Feld	Beispiel: Borrow book
Akteure	Member (primär), Librarian (kann stellvertretend ausleihen)
Vorbedingung	Das Mitglied ist angemeldet und hat kein gesperrtes Konto.
Standardablauf	1. Das Mitglied wählt ein Buch aus. 2. Das System prüft, ob das Buch verfügbar ist. 3. Das System legt eine Ausleihe an. 4. Das System bestätigt die Ausleihe mit Rückgabedatum.
Alternativabläufe	2a. Das Buch ist verliehen: Das System bietet eine Vormerkung an. 2b. Das Konto hat offene Gebühren: Das System verweist auf Pay late fee.
Nachbedingung	Das Buch ist als verliehen markiert, die Ausleihe ist gespeichert.

Merksatz

Die Beschreibung macht den Anwendungsfall, das Oval ist nur das Inhaltsverzeichnis.

Diese Tabelle ist der wertvollste Teil des gesamten Use-Case-Modells: Aus dem Standardablauf entsteht später das Sequenzdiagramm, aus den Nomen die Klassen, aus den Alternativabläufen die Testfälle. Und aus Vor- und Nachbedingungen lässt sich der Abnahmetest direkt ableiten - die Anforderung ist damit “testbar” im Sinn des V-Modells aus Kapitel 01.

Weiterlesen

• uml-diagrams.org: Use Case Diagrams - ausführliche Referenz mit allen Beziehungsarten und Beispielen aus verschiedenen Domänen.

Zusatzmaterialien

• UML Mode (Martin Fowler) - ein kurzer Text, der klärt, wann Diagramme Zeit sparen und wann sie nur Zeit kosten.
• PlantUML - textbasiertes Werkzeug mit vollständiger UML-Notation, einschließlich echter Use-Case-Diagramme.

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

• Nennen: die drei Diagrammtypen mit der Frage nennen, die jeder beantwortet, und sie einer Phase des Entwicklungsprozesses zuordnen.
• Beurteilen: begründen, ob sich UML für ein Vorhaben lohnt und ob es als Skizze oder als Bauplan eingesetzt wird.
• Erklären: den Unterschied zwischen include und extend erklären.
• Anwenden: zu einer Beschreibung ein Use-Case-Diagramm zeichnen und einen Anwendungsfall mit Vorbedingung, Standardablauf, Alternativablauf und Nachbedingung beschreiben.

Passende Übungen

• Aufgabe 04 - Jahresprojekt Sprint 1 - Use Cases: Kata: ein fehlerhaftes Use-Case-Diagramm (Probenraum-Buchung) beurteilen und korrigieren, dazu das Planning von Sprint 1 (Wesentlich_überwiegend); Use-Case-Diagramm des Jahresprojekts, Beschreibung des wichtigsten Anwendungsfalls und Abgleich mit dem Backlog (Wesentlich_vollständig). PlusPlus: Akzeptanzkriterien aus den Alternativabläufen; MandalorianPlus: Abnahmetest aus Vor- und Nachbedingung, Skizze oder Bauplan.

Ab dieser Woche ist das Jahresprojekt die Praxis: Jede Aufgabe beginnt mit einer kurzen Kata zum Kapitel und setzt die Theorie dann im eigenen Projekt um.

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules