Use-Case-Diagramm-Beispiel: Akteure, Anwendungsfälle, Include und Extend

Ein Use-Case-Diagramm beantwortet eine Frage auf einer Seite: Wer nutzt dieses System, und wofür? Produktmanager nutzen es, um sich auf den Umfang zu einigen, Engineers, um jeden Einstiegspunkt in ein System zu sehen, und Tester, um zu prüfen, dass jedes Ziel einen Weg hat. Es ist auch eines der am häufigsten falsch gezeichneten UML-Diagramme: Man macht daraus ein Flussdiagramm, zeichnet jeden Button als Anwendungsfall oder verwendet Include und Extend verkehrt herum.

Dieser Beitrag erklärt die Notation so, wie die UML-2.5.1-Spezifikation sie definiert, klärt Include vs. Extend mit einem einfachen Test, arbeitet ein Beispiel für eine Essensbestell-App durch, zeigt den Text, der hinter jedem Oval stehen sollte, und listet die Fehler auf, die Use-Case-Diagramme nutzlos machen.

Die Notation

Die Pfeilrichtungen stammen direkt aus der UML-2.5.1-Spezifikation, die die OMG im Dezember 2017 veröffentlicht hat: Include zeigt vom Basis-Anwendungsfall auf den inkludierten, Extend zeigt vom erweiternden Anwendungsfall auf den, den er erweitert. Die Spezifikation erlaubt außerdem Erweiterungspunkte, benannte Stellen im Basis-Anwendungsfall, an denen eine Erweiterung andocken kann, aufgelistet im Oval.

Include vs. Extend: ein Test

Frag dich, ob der Basis-Anwendungsfall ohne den anderen vollständig ist.

• Ohne ihn nicht vollständig: Include. Eine Bestellung erfordert immer eine Zahlung. „Place order“ inkludiert „Pay for order“. Der Pfeil zeigt auf das Inkludierte, und die Basis kann ohne es nicht ablaufen.
• Ohne ihn vollständig: Extend. Einen Promo-Code einzulösen ist optional; eine Bestellung ist auch ohne Code völlig gültig. „Apply promo code“ erweitert „Place order“ an einem Erweiterungspunkt wie „vor der Zahlung“, wenn der Kunde einen Code hat. Der Pfeil zeigt auf die Basis, die nicht einmal weiß, dass die Erweiterung existiert.

Zwei weitere Regeln verhindern den meisten Missbrauch:

• Nutze Include, um Verhalten zu teilen, das mehrere Anwendungsfälle brauchen, etwa Authentifizierung oder Zahlung. Nutze es nicht, um einen Anwendungsfall in Schritte zu zerlegen; das ist ein Flussdiagramm.
• Nutze Extend sparsam. Wenn du mehr Extends als Basis-Anwendungsfälle hast, dokumentierst du UI-Optionen, keine Ziele.

Akteure sind Rollen

Ein Akteur ist eine Rolle, keine Person und keine Stellenbezeichnung. Dieselbe Person kann morgens Kunde und nachmittags Restaurantleiter sein. Akteure können auch Systeme sein: Ein Zahlungsanbieter, den die App aufruft, um eine Karte zu autorisieren, ist ein unterstützender Akteur. Manche Teams modellieren geplante Jobs mit einem Akteur „Time“, eine verbreitete Konvention für Anwendungsfälle, die niemand von Hand startet.

Per Konvention stehen primäre Akteure, die Anwendungsfälle starten, um ihre Ziele zu erreichen, links, und unterstützende Akteure, auf die das System zurückgreift, rechts.

Anwendungsfälle auf der richtigen Ebene benennen

Benenne Anwendungsfälle mit Verb und Objekt aus Sicht des Akteurs: „Bestellung aufgeben“, nicht „Bestellung“, „Bestellmaske“ oder „Absenden-Button“. Jeder sollte ein Ziel sein, das der Akteur in einer Sitzung erreichen kann und über das er froh wäre, es erreicht zu haben, was Alistair Cockburn die Meeresspiegel-Ebene der Benutzerziele nennt. Höhere Ebenen („Das Restaurant betreiben“) sind zu breit für ein Oval; tiefere Ebenen („Kartennummer eingeben“) sind Schritte innerhalb eines Anwendungsfalls.

Ein durchgearbeitetes Beispiel: Essensbestellung

Das Diagramm unten zeigt eine Essensbestell-App mit vier Akteuren:

• Customer durchsucht die Speisekarte, gibt Bestellungen auf und verfolgt Lieferungen.
• Restaurant staff nimmt Bestellungen an.
• Courier liefert Bestellungen aus.
• Payment provider, ein externes System, unterstützt die Zahlung.

Und sieben Anwendungsfälle innerhalb der Grenze:

1. Browse menu
2. Place order, inkludiert Pay for order
3. Pay for order, unterstützt vom Zahlungsanbieter
4. Apply promo code, erweitert Place order vor der Zahlung
5. Track delivery
6. Accept order
7. Deliver order

Beachte, was nicht im Diagramm steht: keine Reihenfolge von Schritten, keine Bildschirme, kein Oval „Log in“ für jeden Akteur. Authentifizierung ist eine Vorbedingung, kein Ziel; sie gehört in die Beschreibungen oder, wenn sie echtes Verhalten trägt, in einen einzigen inkludierten Anwendungsfall.

Die Beschreibung hinter jedem Oval

Das Diagramm ist ein Index. Der Wert steckt in einer kurzen Beschreibung pro Anwendungsfall, zum Beispiel:

Use case: Place order
Primary actor: Customer
Precondition: The customer is signed in and the basket is not empty.

Main success scenario:
  1. Customer reviews the basket and delivery address.
  2. System shows the total, including fees and estimated delivery time.
  3. Customer confirms the order.
  4. System takes payment (includes: Pay for order).
  5. System sends the order to the restaurant and confirms it to the customer.

Extensions:
  2a. Customer has a promo code: Apply promo code, then continue at step 2.
  4a. Payment is declined: System asks for another payment method.
  5a. Restaurant does not accept within 5 minutes: System cancels and refunds.

Postcondition: The order is paid and visible to the restaurant.

Die Erweiterungen in der Beschreibung, die nummerierten „Was wäre, wenn“-Zweige, sind die Quelle für Anforderungen und Testfälle. Sie sind viel detaillierter als die Extend-Beziehungen im Diagramm, das nur die optionalen Ziele zeigen sollte, die ein Bild wert sind.

Typische Fehler

• Ein verkapptes Flussdiagramm. Pfeile zwischen Anwendungsfällen, die „danach“ bedeuten, machen aus dem Diagramm ein Prozessmodell. Nimm für die Reihenfolge von Arbeit ein BPMN-Diagramm oder ein Aktivitätsdiagramm.
• Ein Anwendungsfall pro CRUD-Operation. „Menüpunkt anlegen“, „Menüpunkt ändern“ und „Menüpunkt löschen“ sind meist ein Ziel: „Speisekarte verwalten“.
• Bildschirme und Buttons als Anwendungsfälle. „Auf Kasse klicken“ ist ein Schritt, kein Ziel.
• Include zur Zerlegung. Wenn jeder Anwendungsfall drei andere inkludiert, beschreibt das Diagramm die Codestruktur, nicht Benutzerziele.
• Interne Komponenten als Akteure. Die Datenbank ist kein Akteur; sie liegt im System. Externe Systeme, die du aufrufst, schon.
• Keine Grenze. Ohne das Subjekt-Rechteck können Leser nicht erkennen, was du baust und wovon du abhängst.

Use-Case-Diagramme, User Stories und Sequenzdiagramme

Sie arbeiten zusammen: Das Use-Case-Diagramm kartiert das Gelände, Stories schneiden es in lieferbare Stücke, und ein Sequenzdiagramm zeigt, wie ein Szenario tatsächlich abläuft.

Das Use-Case-Diagramm

So liest du es:

• Das Rechteck ist die Systemgrenze: Alles darin ist die Essensbestell-App.
• Akteure links starten Anwendungsfälle: Der Kunde hat drei Ziele, Restaurantpersonal und Kuriere je eines.
• Der Zahlungsanbieter rechts ist ein unterstützendes System, das die App während der Zahlung aufruft.
• Der «include»-Pfeil von Place order zu Pay for order bedeutet, dass die Zahlung immer stattfindet. Der «extend»-Pfeil von Apply promo code zu Place order bedeutet, dass der Promo-Code optional ist.
• Der Markdown-Block ist ein Notationsschlüssel für Leser, die neu in UML sind.

Use-Case-Diagramme zeichnen, die wirklich gelesen werden

• Bleib bei höchstens etwa 15 Anwendungsfällen pro Diagramm. Hat ein System mehr, teile nach Akteur oder Subsystem.
• Setz primäre Akteure links und unterstützende rechts, damit die Leserichtung dazu passt, wer was startet.
• Beschrifte Include und Extend ausdrücklich, mit den Guillemets, und halte die Pfeile gestrichelt.
• Überlass die Details den Beschreibungen. Das Diagramm sollte auf eine Folie passen; der Text darf so lang sein, wie er sein muss.

Use-Case-Diagramme passen gut zu den anderen UML-Sichten: dem UML-Klassendiagramm-Beispiel für das Domänenmodell und dem Zustandsdiagramm-Beispiel für den Lebenszyklus einer Bestellung.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge einen Rahmen aus dem Basis-Pack namens Food ordering app als Systemgrenze hinzu.
3. Füge im Rahmen sieben Anwendungsfall-Nodes aus dem UML-Pack hinzu, benannt wie oben.
4. Füge vier Akteur-Nodes aus dem UML-Pack hinzu: Customer, Restaurant staff und Courier links, Payment provider rechts.
5. Verbinde Akteure mit ihren Anwendungsfällen über einfache Linien. Füge gestrichelte Kanten mit «include» von Place order zu Pay for order und mit «extend» von Apply promo code zu Place order hinzu.
6. Füge einen Markdown-Block aus dem Basis-Pack mit einem kurzen Notationsschlüssel hinzu.

Das Beispiel nutzt 13 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist der Unterschied zwischen Include und Extend in einem Use-Case-Diagramm? Include bedeutet, dass der Basis-Anwendungsfall das inkludierte Verhalten immer ausführt, und der Pfeil zeigt auf den inkludierten Anwendungsfall. Extend bedeutet optionales Verhalten, das unter einer Bedingung hinzukommt, und der Pfeil zeigt von der Erweiterung auf den Basis-Anwendungsfall.

Kann ein Akteur ein System sein? Ja. Jede externe Rolle, die mit dem System interagiert, kann ein Akteur sein, auch andere Software wie ein Zahlungsanbieter. Komponenten innerhalb deines Systems sind keine Akteure.

Sollten Pfeile Akteure mit Anwendungsfällen verbinden? UML verwendet einfache Assoziationslinien zwischen Akteuren und Anwendungsfällen. Manche Teams ergänzen Pfeilspitzen, um zu zeigen, wer startet, aber die Standardnotation verlangt das nicht.

Wie viele Anwendungsfälle sollte ein Diagramm haben? Als Richtwert höchstens etwa 15. Größere Systeme lesen sich besser als mehrere Diagramme, aufgeteilt nach Akteur oder Subsystem.

Zeigen Use-Case-Diagramme die Reihenfolge von Schritten? Nein. Sie zeigen Ziele, keine Abläufe. Die Reihenfolge von Schritten gehört in Use-Case-Beschreibungen, Aktivitätsdiagramme oder Sequenzdiagramme.

Kostenlos starten — ein Seat, keine Kreditkarte.