Use-Case-Diagramme (zu deutsch: Anwendungsfalldiagramme) beantworten in UML folgende Fragen:

  • An wen richtet sich das Programm?
  • Was soll das Programm können?
  • Warum wird das Programm benötigt?

Der Fokus liegt hierbei auf dem Benutzer und den Zielen, die dieser bei der Benutzung des Programms erreichen kann. Use-Case-Diagramme können als eine Art Inhaltsverzeichnis gesehen werden für die Anforderungen, die an ein Programm gestellt werden. Sie werden in der Regel in der frühen Planungsphase eine Projektes angelegt und im Verlauf der Entwicklung fortgeführt.

Use-Case-Diagramme stellen so genannte Akteure (Actors) und Anwendungsfälle (Use-Cases) bereit. Diese sind über Assoziationen miteinander verknüpft.

Akteure (Actors)

Akteure beantworten die Frage wer oder was mit Systemen interagiert. Dabei stehen sie stets außerhalb des Systems. Sie dienen dazu Use-Cases einzuleiten.

In UML werden Akteure als Strichfiguren dargestellt, die mit dem Namen des jeweiligen Akteurs versehen sind:

UML Akteur

Alternativ kann ein Akteur auch als Klasse dargestellt werden mit dem Schlüsselwort <<actor>>:

UML Akteur als Klasse

In der Regel werden menschliche Akteure als Strichfigur und nicht-menschliche Akteure als Klassen dargestellt.

Akteure stellen keine spezifische Person dar, sondern eine Rolle, in der diese Person agieren kann. Daher ist es möglich, dass eine einzelne Person mehrere Akteure darstellen kann. Es sollte vermieden werden einen Akteur nach einer einzelnen Person zu benennen.

Die Benennung eines Akteurs sollte im Singular erfolgen. Beispiele sind: Kunde, Berater, Schuldner, Professor, Angestellter, Gast, Student, etc.

Use-Cases (Anwendungsfälle) und Systeme

Use-Cases beschreiben bestimmte Szenarien, auf die ein User bei der Benutzung eines Programms trifft. Sie definieren die Interaktionen zwischen dem Akteur und dem System und werden ermittelt aus den gewünschten Anforderungen, die ein User an das Programm stellt.

Use-Cases werden als Ellipsen dargestellt, die den Namen des Use-Cases enthalten. Laut des UML Standards ist es aber auch zulässig den Namen unter die Ellipse zu setzen, beispielsweise um flexibler für spätere Anpassungen zu sein. Der Name eines Use-Cases sollte immer mindestens ein Nomen und ein Verb enthalten und aus der Sicht des Akteurs formuliert werden.

Ein System beschreibt die Software, die entwickelt werden soll, und enthält die Use-Cases. Systeme werden als rechteckige Box dargestellt mit der Bezeichnung des Systems. Das folgende Diagramm stellt das System “Hotelreservierung” dar, das die beiden Use-Cases “Zimmer Reservieren” und “Reservierung Stornieren” enthält.

UML Use Cases und System

Assoziationen

Assoziationen verbinden Akteure mit Use-Cases. Eine Assoziation bedeutet, dass der User die Aktion ausführen kann und somit mit dem System interagiert, das den Use-Case enthält. Dabei darf ein einzelner Use-Case mit mehreren Akteuren und ein einzelner Akteur mit mehreren Use-Cases verbunden sein. Eine einzelne Assoziation muss immer genau zwei Elemente miteinander verbinden (binäre Assoziation). Assoziationen werden als eine durchgehende Linie dargestellt.

Pfeile an der Assoziation geben an wer die Aktion initiieren kann. Ein Pfeil, der auf den Use-Case zeigt, besagt, dass nur der Akteur die Aktion initiieren kann, während ein Pfeil, der auf den Akteur zeigt, besagt, dass nur der Use-Case die Aktion initiieren kann. Können beide Seiten die Aktion initiieren, werden die Pfeile weggelassen, anstatt zwei Pfeile zu setzen.

Das folgende Diagramm stellt den Akteur “Gast” dar, der bei der Hotelreservierung die Aktionen “Zimmer Reservieren” und “Zimmerverfügbarkeit Prüfen” initiieren kann. Die Aktion “Reservierung Stornieren” kann sowohl vom Gast, als auch vom Hotel initiiert werden:

UML Hotelreservierung

Include

Neben den herkömmlichen Assoziationen, die immer einen Akteur und einen Use-Case miteinander verbinden, gibt es außerdem spezielle Assoziationen, die Abhängigkeiten (Dependencies) genannt werden, und jeweils mehrere Use-Cases miteinander verbinden.

Die Include-Anweisung gibt an, dass ein Use-Case sämtliche Schritte eines inkludierten Use-Cases mitbenutzt. Auf diese Weise können Redundanzen vermieden werden. Dies hat den Vorteil, dass bei einer Änderung des Verwiesenen Use-Cases (Inclusion Use Case) nur dieser geändert werden muss, anstatt an mehreren Stellen im Diagramm.

Die Include-Anweisung wird durch eine gestrichelte Linie dargestellt, die durch das Schlüsselwort <<include>> gekennzeichnet ist und vom Basis Use-Case einen Pfeil in Richtung des zu inkludierenden Use-Cases hat.

Im folgenden Diagramm hat sich im Vergleich zum Vorherigen geändert, dass sowohl bei der Reservierung, als auch bei der Stornierung der Reservierung die Bankverbindung bei der Bank geprüft wird:

UML Hotelreservierung

Extend

Neben der Include-Anweisung, die inkludierte Use-Cases zwingend ausführt, gibt es auch die Extend-Anweisung. Diese gibt an, dass ein Use-Case optional ist und nur unter bestimmten Bedingungen ausgeführt wird.

Die Extend-Anweisung wird durch eine gestrichelte Linie dargestellt, die durch das Schlüsselwort <<extend>> gekennzeichnet ist und vom Extension Use-Case einen Pfeil in Richtung des Basis Use-Cases hat.

Der Basis Use-Case bestimmt sogenannte Erweiterungspunkte (Extension Points), die den präzisen Ort innerhalb des Use-Cases angeben, an dem Extensions hinzufügt werden dürfen. Erweiterungspunkte werden dargestellt, indem dem Use-Case eine horizontale Linie hinzugefügt wird, unter der das Schlüsselwort extension points steht, gefolgt von den Namen der Erweiterungspunkte.

Optional kann an eine Extend-Anweisung eine Bedingung (Condition) hinzugefügt werden, die beschreibt unter welchen Voraussetzungen bezogen auf den Erweiterungspunkt der Extend Use-Case ausgeführt wird. Die Bedingung wird in UML als Notizzettel dargestellt, der das Schlüsselwort Condition enthält, gefolgt von der Bedingung in geschweiften Klammern und darunter der Erweiterungspunkt, auf den sich die Bedingung bezieht. Die Bedingung ist mit einer gestrichelten Linie mit der Linie der Extend-Anweisung verbunden.

Das folgende Diagramm wurde im Vergleich zum Vorherigen insofern abgeändert, als der Use-Case “Bankverbindung Prüfen” nur dann ausgeführt wird, wenn der Gast “Bankzahlung” als Zahlungsmethode gewählt hat:

UML Hotelreservierung