Anwendungsfalldiagramm-Beispiele
Zwei Anwendungsfalldiagramme von Systemen, die jeder kennt, und eines bewusst falsch gezeichnet - denn der Fehler, an dem die meisten dieser Diagramme scheitern, ist leichter zu erkennen als zu definieren.
8 Min. LesezeitUML 2.5.112 von 35
01Example 1: a library system
The library is the standard first example for a reason: everybody already knows the domain, so the only thing left to look at is the notation. Two actors, five use cases, and a boundary that says which of them the software is responsible for.
Notice what the ellipses are. Borrow book is a goal - a member wants to leave with a book - and it stays a goal whether the counter is a person, a self-service kiosk or an app. That independence from mechanism is the test for a use case: if replacing the interface would change the label, the label is a step.
Two relationships are doing real work. Check membership is included by Borrow book, meaning it always happens as part of it and the arrow points from the borrower to the included behaviour. It has no actor of its own, and that is correct - nobody arrives at the library wanting their membership checked. Pay overdue fine extends Return book: it happens only sometimes, and the arrow points the other way, from the optional behaviour into the base.
02Example 2: an online store, with an external system
The second example adds the piece most first diagrams leave out: a system you depend on and do not control.
The Payment gateway is a secondary actor. It initiates nothing - the customer starts everything on this diagram - but the system calls out to it, so it belongs outside the boundary with a line into the use case that needs it. Drawing it is how a use case diagram earns its keep in a scoping conversation: the boundary now shows exactly which behaviour you are on the hook for and which you are buying.
Apply discount code extends Place order because most orders do not have one. If nearly every order did, it would be an include instead. The question is not whether the behaviour is important, it is whether it always happens.
Four ellipses is a reasonable size. A real store has hundreds of behaviours, and the diagram does not grow to match - you draw one per conversation, scoped to the question being asked, which is the discipline scoping a model is about.
03Example 3: the same notation used badly
Most bad use case diagrams are bad in exactly one way, and it is worth seeing once.
Four ellipses, one actor, a boundary, no notation errors at all - and the diagram is worthless. Every label is a step in a user interface rather than a goal a person has. Nobody wants to enter a username; they want to log in, and even that is usually only in service of something else.
The whole diagram collapses to a single use case, and the four steps belong in its text description or, if the branching genuinely matters, in an activity diagram. That is the standard repair: sequence goes to activity, goals stay here.
04Adapting these to your system
The two good diagrams above are the same diagram with different nouns, which is the useful thing about the notation - once the shape is in your hand, the next one takes ten minutes.
Reach for it when
- Goals a user would name, phrased as verb plus object: place order, borrow book.
- A boundary drawn around exactly one system, with actors outside it.
- Secondary actors for every external service the system calls, so dependencies are visible.
- Include for behaviour that always happens; extend for behaviour that sometimes does.
Reach for something else when
- Interface steps - click, enter, select, submit. They are not goals.
- CRUD sprayed across the diagram: create, read, update and delete a thing is one use case, not four.
- Plain lines between two ellipses. Only include, extend and generalization are legal there.
- More than about a dozen ellipses. Split by actor or by subsystem instead.
05What to remember
In one line each
- 01A use case is a goal that survives an interface redesign. If the label would change, it is a step.
- 02Include points from the base to the always-included behaviour; extend points from the optional behaviour back to the base.
- 03Included use cases have no actor of their own, and that is correct.
- 04Secondary actors are what makes the diagram useful in a scoping conversation.
- 05Three to a dozen ellipses. Past that, the diagram has become a list of screens.
06Häufige Fragen
Was ist ein gutes Beispiel für ein Anwendungsfalldiagramm?
Ein Bibliothekssystem: Ein Mitglied durchsucht den Katalog, leiht und gibt Bücher zurück; ein Bibliothekar bedient die Thekenseite derselben zwei; das Ausleihen schließt eine Mitgliedsprüfung ein; und das Zahlen einer Mahngebühr erweitert die Rückgabe. Zwei Akteure, fünf Ellipsen, eine Grenze - fertig.
Ist Anmelden ein Anwendungsfall?
Für sich genommen meist nicht. Niemand öffnet eine Anwendung, um sich anzumelden - man meldet sich an, um etwas anderes zu tun, und dieses andere ist das Ziel. Zeichnen Sie es als eingeschlossenen Anwendungsfall, wenn mehrere Ziele es wirklich brauchen, sonst lassen Sie es weg.
Wie viele Anwendungsfälle gehören in ein Diagramm?
Etwa drei bis ein Dutzend. Unter drei hätte ein Satz gereicht; über einem Dutzend sind die Ellipsen Schritte statt Ziele, oder die Systemgrenze wurde um zwei Systeme gezogen.
Dürfen zwei Anwendungsfälle durch eine einfache Assoziation verbunden werden?
Nein. Assoziationen verlaufen nur zwischen Akteur und Anwendungsfall. Zwischen zwei Anwendungsfällen sind include, extend und Generalisierung zulässig; eine schlichte Linie zwischen zwei Ellipsen ist das Zeichen, dass jemand eine Schrittfolge statt einer Zielmenge zeichnet.
Was ist ein Sekundärakteur in einem Anwendungsfalldiagramm?
Eine externe Partei, die das System aufruft, statt selbst etwas anzustoßen: ein Zahlungsdienstleister, ein Identitätsanbieter, ein Mailversand. Sie steht als Akteur auf der anderen Seite der Grenze und zeigt, wovon Sie abhängen, ohne es zu kontrollieren.
Passend dazu