UML Anwendungsfalldiagramm

Der Zweck: Was soll das System können und wer nutzt es?

Stell dir vor, du planst eine neue Software, zum Beispiel eine App für einen Lieferservice. Bevor du auch nur eine Zeile Code schreibst, musst du verstehen, was die App können soll und wer sie benutzen wird. Genau hier kommen UML-Anwendungsfalldiagramme (Use Case Diagrams) ins Spiel. Sie sind wie eine Landkarte der Funktionen deines Systems aus der Sicht zukünftiger Nutzender. Sie helfen, die grundlegenden Anforderungen an ein System einfach und visuell darzustellen und dienen als gemeinsame Sprache für alle Projektbeteiligten – von den Entwickelnden über das Management bis hin zu den Personen, die das System später nutzen.

Die wichtigsten Bausteine im Überblick

Ein Anwendungsfalldiagramm ist erfreulich übersichtlich und nutzt nur wenige, klar definierte Symbole:

• Akteure (Actors): Das sind die "Wer"-Komponenten. Ein Akteur ist eine Rolle, die eine Person (z. B. "Bestellende Person", "Admin"), ein anderes System (z. B. "Externes Zahlungssystem") oder sogar ein Gerät (z. B. "Sensor") einnehmen kann, das mit deinem System interagiert. Akteure werden meist als Strichmännchen dargestellt und befinden sich außerhalb des eigentlichen Systems.
• Anwendungsfälle (Use Cases): Das sind die "Was"-Komponenten. Ein Anwendungsfall beschreibt eine spezifische Interaktion oder Funktion, die ein Akteur mit dem System ausführt, um ein bestimmtes Ziel zu erreichen. Sie werden als Ovale dargestellt. Für einen Lieferservice wären das z. B. "Essen bestellen", "Bestellung verfolgen" oder "Restaurant bewerten".
• Systemgrenze (System Boundary): Ein Rechteck, das symbolisch dein System (z. B. die Lieferservice-App) umschließt. Die Anwendungsfälle liegen innerhalb dieser Grenze, die Akteure außerhalb.
• Assoziationen (Associations): Das sind einfache Linien, die einen Akteur mit einem Anwendungsfall verbinden. Sie zeigen an, dass der Akteur diesen Anwendungsfall nutzt oder daran beteiligt ist.

Beispiel Lieferservice-App:
Der Akteur "Bestellende Person" ist durch Linien mit den Anwendungsfällen "Essen bestellen" und "Bestellung verfolgen" verbunden. Der Akteur "Restaurant" ist mit "Bestellung bearbeiten" verbunden.

Kommunikation und gemeinsames Verständnis

Anwendungsfalldiagramme sind Gold wert für die Kommunikation. Anstatt lange Textdokumente zu wälzen, bietet das Diagramm einen schnellen, visuellen Überblick über die Kernfunktionalitäten.

• Klarheit: Sie zeigen auf einen Blick, wer was mit dem System machen kann.
• Diskussionsgrundlage: Das Team und die Stakeholder (z. B. auftraggebende Personen oder Abteilungen) können anhand des Diagramms diskutieren, ob alle wichtigen Funktionen bedacht wurden oder ob es Missverständnisse gibt.
• Früherkennung von Problemen: Unklare Anforderungen oder fehlende Funktionen fallen oft schneller auf, wenn sie visualisiert werden.

Die <<include>>-Beziehung: Wenn eins das andere immer braucht

Manchmal ist ein Anwendungsfall so grundlegend, dass er von mehreren anderen Anwendungsfällen immer benötigt wird. Hier kommt die <<include>>-Beziehung ins Spiel.

• Bedeutung: Ein Anwendungsfall (der Basis-Anwendungsfall) beinhaltet die Funktionalität eines anderen Anwendungsfalls (des inkludierten Anwendungsfalls). Der Basis-Anwendungsfall ist ohne den inkludierten nicht vollständig.
• Darstellung: Eine gestrichelte Linie mit einem offenen Pfeil, der vom Basis-Anwendungsfall zum inkludierten Anwendungsfall zeigt, beschriftet mit dem Stereotyp <<include>>.
• Beispiel Lieferservice-App: Sowohl "Essen bestellen" als auch "Profil bearbeiten" könnten den Anwendungsfall "Nutzende Person authentifizieren" inkludieren. Jedes Mal, wenn eine Bestellung aufgegeben oder das Profil geändert wird, muss sich die nutzende Person zuerst authentifizieren.

Die <<extend>>-Beziehung: Optionale Erweiterungen

Die <<extend>>-Beziehung wird verwendet, wenn ein Anwendungsfall die Funktionalität eines anderen Anwendungsfalls unter bestimmten Bedingungen optional erweitern kann.

• Bedeutung: Ein Anwendungsfall (der erweiternde Anwendungsfall) fügt einem anderen Anwendungsfall (dem erweiterten oder Basis-Anwendungsfall) zusätzliches Verhalten hinzu. Dieses zusätzliche Verhalten ist nicht zwingend notwendig für den Abschluss des Basis-Anwendungsfalls.
• Darstellung: Eine gestrichelte Linie mit einem offenen Pfeil, der vom erweiternden Anwendungsfall zum Basis-Anwendungsfall zeigt, beschriftet mit dem Stereotyp <<extend>>. Oft wird auch eine Bedingung für die Erweiterung angegeben.
• Beispiel Lieferservice-App: Der Anwendungsfall "Essen bestellen" könnte durch den Anwendungsfall "Gutscheincode eingeben" erweitert werden. Die Eingabe eines Gutscheincodes ist optional und erweitert den Bestellvorgang nur, wenn die bestellende Person einen Gutschein hat und nutzen möchte.

Generalisierung: Vom Allgemeinen zum Speziellen

Die Generalisierung ist ähnlich dem Konzept der Vererbung in der objektorientierten Programmierung. Sie zeigt, dass ein Anwendungsfall (das "Kind" oder der spezialisierte Anwendungsfall) eine spezielle Art eines allgemeineren Anwendungsfalls (das "Elternteil" oder der generelle Anwendungsfall) ist.

• Bedeutung: Der spezialisierte Anwendungsfall erbt die Eigenschaften und das Verhalten des generellen Anwendungsfalls, kann aber eigene spezifische Schritte oder Merkmale hinzufügen.
• Darstellung: Eine durchgezogene Linie mit einer geschlossenen, nicht ausgefüllten Pfeilspitze (ein Dreieck), die vom spezialisierten Anwendungsfall zum generellen Anwendungsfall zeigt.
• Beispiel Lieferservice-App: Der generelle Anwendungsfall könnte "Zahlung durchführen" sein. Spezialisierte Anwendungsfälle davon wären "Mit Kreditkarte zahlen", "Mit PayPal zahlen" oder "Barzahlung bei Lieferung". Alle sind Arten der "Zahlung durchführen", haben aber jeweils spezifische Abläufe.