UML Anwendungsfalldiagramm (Use Case Diagram)
https://bildung.social/@oerinformatik/112084338768562808
https://oer-informatik.de/uml-usecase
tl/dr; (ca. 7 min Lesezeit): Mit UML-Anwendungsfall-Diagrammen können Übersichten erstellt werden, welchen Nutzen ein System den Benutzer*innen zur Verfügung stellt. Das einfache Diagramm bietet wenig Notationsmittel, mithilfe derer Beziehungen dargestellt werden: zwischen Nutzergruppen, zwischen Anwendungsfällen und von Nutzern zu Anwendungsfällen. Dieser Artikel stellt diese UML-Notationen vor. (Zuletzt geändert am 12.02.2025)
Für ein weitreichenderes Bild zu Anwendungsfällen gibt es Hintergrundartikel zu Anwendungsfällen und deren tabellarische Erfassung, Grundlagen zum UML-Anwendungsfall-Diagramm (Use Case) / Tutorial zur Erstellung von UML-Anwendungsfalldiagrammen mit PlantUML / Übungsaufgaben zu UML-Use-Case-Diagrammen.
Auch zu den anderen UML-Diagrammen gibt es hier Erklärungen zu den wesentlichen Notationen: Klassendiagramm / Sequenzdiagramm / Aktivitätsdiagramm / Zustandsdiagramm (State) / Anwendungsfall-Diagramm (Use Case)
Wozu werden Anwendungsfalldiagramme eingesetzt?
Ein Anwendungsfalldiagramm beschreibt wie ein (Software)-System mit Anwender*innen interagiert. Es beschreibt, welche Anwendungsfälle ein System anbietet. Der konkrete Inhalt eines Anwendungsfalls wie die dahinterstehenden Geschäftsprozesse, Aktivitäten, Abläufe und Szenarien werden beispielsweise wie hier dargestellt (link) tabellarisch erfasst.
Anwendungsfalldiagramme helfen v.a. dabei, die Vollständigkeit und Korrektheit des Systemverständnisses der Projektbeteiligten (Kund*innen, Fachdomäne, Entwickler*innen) abzugleichen.
Akteur*innen und Anwendungsfälle
Akteur*innen sind Menschen oder andere Systeme, die Anwendungsfälle des Systems nutzen. Sie können auch Rollen (Kunde) oder Typen zusammenfassen. Sie werden in der Regel als Strichmensch (stick man ) notiert.
Mit einem Anwendungsfall (Use Case) erzeugt das modellierte System erkennbaren Nutzen für die zugeordneten Akteur*innen. Ein Anwendungsfall (im Beispiel oben: “Ware bestellen”) fasst Aktionen zusammen, die (funktionale) Anforderungen erfüllen. Anwendungsfälle werden in der Regel als Ellipse notiert.
Assoziationen verbinden Anwendungsfälle mit den auslösenden oder benötigten Akteur*innen. Sie werden mit durchgezogenen Linien notiert.
Systemgrenzen und Systemname
Die Systemgrenze legt fest, welche Anwendungsfälle im modellierten System enthalten sind. Das abgegrenzte System trägt einen Namen und spannt einen Namensraum auf.
Alle Akteur*innen stehen außerhalb der Systemgrenzen - andernfalls wären sie als Teil des Systems nicht gesondert zu modellieren.
Systemgrenzen müssen nicht zwingend angegeben werden, dienen aber dem Verständnis und der Abgrenzung von Akteur*innen, Anwendungsfällen und externen Systemen.
Vererbung zur Modellierung von Rollen der Akteur*innen
Mithilfe von Vererbungsbeziehungen können Akteur*innen spezialisiert werden: Im Beispiel unten ist die Prokuristin eine spezielle Mitarbeiterin, der zusätzlich zu allen Anwendungsfällen einer Mitarbeiterin auch noch über eigene Anwendungsfälle verfügt. Vererbung wird - wie in der UML üblich - mit einer geschlossenen Pfeilspitze symbolisiert:
Vererbungsbeziehungen werden auch genutzt, um ODER-Beziehungen zu modellieren: Eine Geschäftsführerin oder eine Prokuristin darf Verträge unterschreiben. Solche Zusammenhänge lassen sich nur über eine generalisierte Akteurin (hier: Befugte) realisieren.
Akteur*innen, die zwar als Generalisierung anderer Rollen modelliert werden, die aber konkret (als Instanz im OOP-Sinne) nie existieren, können als abstrakte Akteur*innen modelliert werden. Ihr Name wird kursiv geschrieben und/oder mit dem Constraint {abstract} gekennzeichnet:
Hier wurde eine Akteurin oberhalb und eine unterhalb positioniert, die Vererbungshierarchie wird durch die Pfeilrichtung vorgegeben.
Anwendungsfälle, die weitere Anwendungsfälle immer beinhalten
Sofern zur Erfüllung eines Anwendungsfalls in jedem Fall auf die Funktionalität eines zweiten Anwendungsfalls zurückgegriffen werden muss, kann dieser über eine include -Beziehung verknüpft werden. Wichtig ist, dass der eingebundene Anwendungsfall auch isoliert einen abgeschlossenen Nutzen generiert (also nicht fester Bestandteil des anderen Anwendungsfalls ist). Diese “beinhaltet”-Beziehung wird durch eine gestrichelte Linie mit Pfeilspitze dargestellt, die in Richtung des einbezogenen Anwendungsfalls zeigt und die mit dem Stereotyp «include» versehen wird. Der Pfeil kann als “beinhaltet” in Pfeilrichtung gelesen werden.
Die Gefahr ist groß über include -Beziehungen Programmabläufe und Unterfunktionsaufrufe zu modellieren. Daher ist es wichtig, immer genau zu prüfen: Stellt der inkludierte Anwendungsfall wirklich einen eigenständig auslösbaren Anwendungsfall dar?
Anwendungsfälle, die unter Umständen durch weitere Anwendungsfälle erweitert werden
Sofern ein Anwendungsfall nur unter bestimmten Umständen um die Funktionalitäten eines zweiten Anwendungsfalls erweitert wird, werden beide über eine extend -Beziehung verknüpft. Zu jeder extend -Beziehung sollte angegeben werden, unter welcher Bedingung (condition) welcher Anwendungsfall erweitert wird. Ein gestrichelter Pfeil zeigt vom erweiternden auf den zu erweiternden Anwendungsfall und ist mit dem Stereotyp «extend» versehen. An dieser Linie sollte eine Notiz mit condition und extension point notiert werden. Der extension point wird auch am Ursprungs-Anwendungsfall notiert. Der Pfeil kann als “erweitert” in Pfeilrichtung gelesen werden.
Vererbung von Anwendungsfällen
Analog zu Akteur*innen können auch Anwendungsfälle spezialisiert werden. Beispielsweise kann ein generalisierter Anwendungsfall “Artikel kaufen” bestehen aus dem Szenario:
1. Artikel in Warenkorb legen
2. Warenkorb bestellen
3. Kauf abwickelnDie spezialisierten Anwendungsfälle ändern Details in den Szenarien, z.B. bei “Buch per Versand kaufen”:
1. Artikel in Warenkorb legen
2. Warenkorb bestellen
3a) Versandadresse abfragen
3b) Bezahldetails abfragenoder bei “eBook kaufen”:
1. Artikel in Warenkorb legen
2. Warenkorb bestellen
3. Kaufabwicklung des Bezahldienstleisters starten
4. Downloadlink bereitstellen
Auch Anwendungsfälle kennen das Konzept der Abstraktion: Im Beispiel kann “Artikel kaufen” selbst nicht ausgeführt werden, sondern modelliert nur ein Gerüst, das in konkreten Anwendungsfällen noch ausformulieren müssen.
Die Notation entspricht der für Vererbung (geschlossene Pfeilspitze) und Abstraktion (kursive Schrift, constraint {abstract}) bekannten Darstellung.
Wie viele Akteur*innen stehen mit wie vielen UseCases in Beziehung?
Um festlegen zu können, wie viele Akteur*innen für Anwendungsfälle nötig sind und an wie vielen Anwendungsfällen Akteur*innen beteiligt sind, werden Multiplizitäten an den Assoziationen angegeben, wie im UML-Klassendiagramm üblich und am Beispiel zu sehen:
An einem Tischtennis-Rundlauf sind mindestens 3 Spieler*innen beteiligt, jede/r Spieler*in jedoch an exakt einem Rundlauf-Spiel. An einem Rundlaufspiel können keine oder beliebig viele Schiedsrichter*innen beteiligt sein. Jede/r Schiedsrichter*in kann an höchstens einem Rundlaufspiel beteiligt sein.
Da diese Information jedoch häufig für die Adressaten des Use-Case-Diagramms keine Rolle spielt, werden Multiplizitäten eher selten notiert.
Gerichtete Assoziationen (initiierende und sekundäre Akteurinnen)
In seltenen Fällen wird mithilfe von gerichteten Kanten dargestellt, welche Akteur*innen den Anwendungsfall aktiv triggern (primäre/initiierende Akteur*innen) und wer nur passiv vom Anwendungsfall benötigt wird (sekundäre Akteur*innen).
Weitere Literatur zu UML-Anwendungsfall-Diagrammen
als Primärquelle: die UML Spezifikation der Object Management Group Definition des Standards, jedoch nicht für Endnutzer aufbereitet): https://www.omg.org/spec/UML
für den Einstieg: Martina Siedl, Marion Brandsteidl, Christian Huemer, Gerti Kappel: UML@Classroom, dpunkt Verlag, Heidelberg 2012 Gut zu lesende Einführung in die wichtigsten UML-Diagramme, Empfehlung für den Einstieg.
für Lesefaule: Die Vorlesungsreihe der Technischen Uni Wien (zu UML@Classroom) kann hier angeschaut werden (Videos, Folien): http://www.uml.ac.at/de/lernen
als Nachschlagewerk: Christoph Kecher, Alexander Salvanos: UML 2.5 – Das umfassende Handbuch, Rheinwerk Bonn 2015, ISBN 978-3-8362-2977-7 Sehr umfangreiches Nachschlagewerk zu allen UML-Diagrammen
als Cheatsheet: die Notationsübersicht von oose.de: https://www.oose.de/wp-content/uploads/2012/05/UML-Notations%C3%BCbersicht-2.5.pdf
UML und Software Engineering: Chris Rupp, Stefan Queins & die SOPHISTen: UML2 glasklar, Hanser Verlag, München 2012; ISBN 978-3-446-43057-0 Schwerpunkt: Einbindung von UML-Diagrammen in den Softwareentwicklungszyklus
Zur Zertifizierungs-Vorbereitung: M. Chonoles: OCUP 2 Certification Guide, Morgan Kaufmann Verlag, Cambridge 2018, ISBN 978-0-12-809640-6 Informationen zur Zertifizierung nach OMG Certified UML Professional 2™ (OCUP 2™): Foundation Level
Software zur Erzeugung von UML-Anwendungsfall-Diagrammen
PlantUML: Deklaratives UML-Tool, das in vielen Entwicklungsumgebungen integriert ist. Auch als WebEditor verfügbar. Die obigen Diagramme wurden damit erzeugt - Eine detaillierte Anleitung für plantUml mit den Quelltexten findet sich hier
WhiteStarUML (Relativ umfangreiches Tool, viele UML-Diagramme, mit Code-Generierung für Java, C, C# und Vorlagen für Entwurfsmuster)
Draw.io: Online-Tool für Flowcharts usw. - aber eben auch UML
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “UML Anwendungsfalldiagramm (Use Case Diagram)” von Hannes Stein, Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/uml-usecase veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/uml/umlanwendungsfall. Stand: 12.02.2025.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
