Anwendungsfalldiagramm

Einführung

Die Unified Modeling Language (Vereinheitlichte Modellierungssprache), kurz UML, ist eine standardisierte, grafische Modellierungssprache zur Spezifikation, zum Entwurf und zur Dokumentation von Software- und anderen Systemen. Innerhalb der UML gehören Anwendungsfalndiagramme (auch Use-Case-Diagramme genannt) zu den Verhaltensdiagrammen. Sie beschreiben das erwartete Verhalten eines Systems aus der Perspektive eines externen Beobachters (Benutzers) heraus, ohne technische Implementierungsdetails offenzulegen.

Zielsetzung im Software-Lebenszyklus

In der Analysephase eines Softwareprojekts dienen Anwendungsfalldiagramme dazu, die funktionalen Anforderungen des Auftraggebers strukturiert, übersichtlich und vollständig zu erfassen. Sie erfüllen dabei eine essenzielle Brückenfunktion:

• Kommunikationsmittel: Sie vermitteln barrierefrei zwischen fachlichen Laien (potenziellen Anwendern, Auftraggebern) und dem technischen Entwicklungsteam (Auftragnehmern).
• Anforderungsdokumentation: Als strukturierte und visuelle Anforderungsbeschreibung sind sie ein fundamentaler Bestandteil des Lastenhefts (was das System tun soll) und fließen direkt in das Pflichtenheft ein.

Die drei Kernelemente

Ein Anwendungsfalndiagramm lässt sich auf drei wesentliche Säulen reduzieren:<ref>Heide Balzer: Lehrbuch der Objektmodellierung - Analyse und Entwurf, Spektrum Akademischer Verlag, S. 62 ff.</ref>

1. Akteure (Actors): Wer interagiert mit dem System? (Sowohl Personen als auch externe Systeme).
2. Anwendungsfälle (Use Cases): Was kann mit dem System getan werden? Welche Ziele werden erreicht?
3. Beziehungen (Relations): Wie interagieren Akteure und Anwendungsfälle miteinander oder wie hängen Anwendungsfälle untereinander zusammen?

Hinweis zur Abgrenzung: Ein Use-Case-Diagramm zeigt nicht, in welcher zeitlichen oder logischen Reihenfolge Prozesse ablaufen. Für die Modellierung von detaillierten, prozessualen Abläufen und Kontrollflüssen wird stattdessen das Aktivitätendiagramm verwendet.

Systematische Notation und Aufbau

Die Erstellung eines normkonformen Diagramms folgt einem klaren, dreistufigen iterativen Prozess:

1. Akteure identifizieren (Actors)

Akteure stellen Rollen dar, die außerhalb des betrachteten Systems liegen, aber mit diesem interagieren.

• Darstellung: Grafisch als klassisches Strichmännchen (für menschliche Rollen) oder als Rechteck mit dem Stereotyp «system» (für externe Software/Hardware).
• Namensgebung: Akteure müssen präzise, selbsterklärende Substantive sein (z. B. Kunde, Systemadministrator, Buchhaltungssystem). Generische Bezeichnungen wie „User“, „Benutzer“ oder „Akteur“ sind strikt zu vermeiden, da sie keine differenzierte Rolle beschreiben.

2. Anwendungsfälle definieren (Use Cases)

Ein Anwendungsfall beschreibt eine Sequenz von Interaktionen, die für den Akteur ein Ergebnis von messbarem, fachlichem Wert liefert.

• Darstellung: Als horizontale Ellipse, in deren Zentrum die Beschreibung steht.
• Namensgebung: Die Formulierung erfolgt kurz, prägnant, im Infinitiv und folgt der sprachlichen Struktur: Subjekt-Objekt-Prädikat (z. B. Artikel in Warenkorb legen, Passwort zurücksetzen).

3. Beziehungen verknüpfen (Relations)

Akteure und Anwendungsfälle werden über Beziehungslinien verknüpft, um Interaktionskanäle aufzuzeigen. Das gesamte System wird optional durch einen rechteckigen Systemrahmen (System Boundary) umschlossen, welcher die Systemgrenze markiert: Akteure stehen außerhalb, Use Cases innerhalb des Rahmens.

Detaillierte Typisierung von Beziehungen

1. Assoziationen (Akteur ↔ Use Case)

Assoziationen bilden das Fundament der Kommunikation zwischen Akteur und System. Es handelt sich um eine binäre Beziehung (verbindet genau zwei Elemente).

• Ungerichtete Assoziation: Eine einfache, durchgehende Linie. Sie signalisiert einen bidirektionalen Informationsfluss. Der Akteur interagiert mit dem Use Case, lässt jedoch offen, wer die Interaktion gestartet hat.
• Gerichtete Assoziation: Eine Linie mit einer offenen Pfeilspitze. Der Pfeil zeigt auf den Initiator des Datenflusses bzw. der Aktion:
  • Pfeil zeigt zum Use Case: Der Akteur initiiert den Anwendungsfall aktiv.
  • Pfeil zeigt zum Akteur: Der Anwendungsfall stößt eine Aktion beim Akteur an (häufig bei sekundären, externen Systemen wie z. B. Benachrichtigungsdiensten).

2. Multiplizitäten

Multiplizitäten (Kardinalitäten) geben an, wie viele Instanzen eines Akteurs zeitgleich mit wie vielen Instanzen eines Anwendungsfalls interagieren können. Sie werden direkt an die Enden der Assoziationslinien geschrieben.

Praxisbeispiel: Das Tischtennis-Rundlaufspiel

Um die Logik von Multiplizitäten zu verdeutlichen, betrachten wir das Regelwerk eines Tischtennis-Rundlaufs:

• An einem Rundlauf-Spiel müssen mindestens 3 Spielerinnen teilnehmen, nach oben hin gibt es keine Grenze (3..*). Jede einzelne Spielerin nimmt jedoch zu einem Zeitpunkt an exakt 1 Rundlauf-Spiel teil (1).
• Ein Spiel kann völlig ohne oder mit unbegrenzt vielen Schiedsrichterinnen stattfinden (0..*). Eine Schiedsrichterin kann maximal an höchstens 1 Spiel gleichzeitig als Offizielle zugewiesen sein (0..1).

Hinweis für die Praxis: Da Multiplizitäten Use-Case-Diagramme schnell visuell überladen und für fachliche Auftraggeber oft sekundär sind, werden sie in dieser Diagrammart selten notiert. Ihre fundamentale Bedeutung entfalten sie im Klassendiagramm.

3. Include-Beziehungen (Abhängigkeiten)

Die «include»-Beziehung beschreibt eine zwingende Abhängigkeit (Einschluss). Wenn ein Basis-Anwendungsfall ausgeführt wird, muss der inkludierte Anwendungsfall zwingend ebenfalls ausgeführt werden. Sie dient dem Aufbrechen komplexer Use Cases und der Wiederverwendung von Funktionalitäten.

• Pfeilrichtung: Der gestrichelte Pfeil startet beim Basis-Use-Case und zeigt auf den inkludierten Use Case.
• Stereotyp: Die Beziehungslinie muss zwingend mit dem Schlüsselwort «include» gekennzeichnet werden.

4. Extend-Beziehungen (Erweiterungen)

Die «extend»-Beziehung modelliert ein optionales Verhalten. Der erweiternde Use Case wird nur unter präzise definierten Rahmenbedingungen ausgeführt.

• Pfeilrichtung: Der gestrichelte Pfeil verhält sich umgekehrt zur Include-Beziehung: Er startet beim erweiternden (optionalen) Use Case und zeigt auf den Basis-Use-Case.
• Stereotyp: Kennzeichnung erfolgt über das Schlüsselwort «extend».
• Erweiterungspunkte (Extension Points): Im Basis-Use-Case wird unter einer horizontalen Trennlinie via extension points definiert, an welcher Stelle die Erweiterung eingreift.
• Bedingung (Condition): Ein umschließendes Notizfeld (als Notizzettel dargestellt) definiert die logische Bedingung. Es wird mit einer fein gestrichelten Linie an die Extend-Beziehung geheftet.

5. Generalisierung (Vererbung / Spezialisierung)

Eine Generalisierungsbeziehung spiegelt das klassische Konzept der Vererbung (OOP) wider. Sie kann sowohl zwischen zwei Akteuren als auch zwischen zwei Anwendungsfällen existieren. Das spezialisierte Element erbt alle Eigenschaften, Attribute und Verhaltensweisen des allgemeinen Elements und konkretisiert diese.

• Darstellung: Eine durchgehende Linie mit einer großen, leeren und geschlossenen Pfeilspitze.
• Pfeilrichtung: Der Pfeil zeigt immer vom spezifischen (Unterklasse) zum allgemeinen (Oberklasse) Element.

Praxisbeispiel: Nutzerhierarchie

Ein Fahrer ist eine explizite Spezialisierung des allgemeinen Anwenders. Der Fahrer besitzt implizit jede Eigenschaft des Standard-Anwenders (wie Stammdaten: Vorname, Nachname, Username) und erbt dessen Fähigkeit, den Use Case Login durchführen aufzurufen, ohne dass dies redundant gezeichnet werden muss.

Zusammenfassende Gegenüberstellung für die Klausur / Praxis

Beziehungstyp	Notation im Diagramm	Semantik (Bedeutung)	Typischer Anwendungsfall
Assoziation	Durchgehende Linie	Kommunikationspfad	Verknüpft primäre Akteure mit Kernfunktionen.
Include	Gestrichelte Linie + Pfeil zum Ziel + «include»	Zwingende Ausführung (100% Pflicht)	Auslagerung von wiederkehrenden Funktionen wie Login oder Validierung.
Extend	Gestrichelte Linie + Pfeil zur Basis + «extend»	Optionale Ausführung (0-100% je nach Bedingung)	Modellierung von Ausnahmefällen, Fehlermeldungen oder optionalen Zusatzfunktionen.
Generalisierung	Linie + geschlossene, leere Pfeilspitze	"Ist-ein"-Beziehung (Vererbung)	Abbildung von Benutzer-Rollenstrukturen (Rechtehierarchien).