Anwendungsfalldiagramm

Einführung in die Use-Case-Modellierung

Die Unified Modeling Language (Vereinheitlichte Modellierungssprache), kurz UML, ist eine standardisierte grafische Modellierungssprache zur Spezifikation, Konstruktion und Dokumentation von Softwareteilen und anderen Systemen. Das Anwendungsfalldiagramm (im englischsprachigen Raum Use Case Diagramm) gehört zu den Verhaltensdiagrammen der UML.

Zielsetzung im Requirements Engineering

In der Analysephase (Anforderungsermittlung / Requirements Engineering) ist es das primäre Ziel des Anwendungsfalldiagramms, das geplante System aus der externen Beobachterperspektive zu beschreiben. Es modelliert das "Was" (welche Funktionen bietet das System?) und grenzt sich strikt vom "Wie" (wie werden diese Funktionen technisch umgesetzt?) ab.

Es dient als zentrales Kommunikationsmittel zwischen:

• Auftraggebern / potenziellen Anwendern (Fachseite): Diese können das Diagramm ohne Programmierkenntnisse verstehen.
• Auftragnehmern (Entwicklerteam / Systemarchitekten): Für diese bildet das Diagramm die Grundlage für die Systemarchitektur.

Daher fließen Anwendungsfalldiagramme als strukturierte Anforderungsbeschreibung in das Lastenheft (Forderungen des Auftraggebers) und später detailliert in das Pflichtenheft (Umsetzungsvorgaben des Auftragnehmers) ein.

Die drei Kernelemente

Das Diagramm besteht aus drei essenziellen Bausteinen:<ref>Heide Balzer: Lehrbuch der Objektmodellierung - Analyse und Entwurf, Spektrum Akademischer Verlag, S. 62 ff.</ref>

1. Akteure (engl. actors): Sie repräsentieren externe Entitäten, die mit dem System interagieren. Wichtig: Ein Akteur ist immer eine Rolle (z. B. "Kunde"), niemals eine konkrete Person (z. B. "Herr Müller"). Auch externe Fremdsysteme (wie ein Zahlungsanbieter) treten als Akteure auf.
2. Anwendungsfälle (engl. use cases): Sie beschreiben eine in sich abgeschlossene Aufgabe, die für den Akteur einen messbaren, fachlichen Mehrwert erzeugt.
3. Beziehungen (engl. relations): Die Interaktionspfade zwischen Akteur und Anwendungsfall oder die Abhängigkeiten von Anwendungsfällen untereinander.

Hinweis zur Abgrenzung: Der detaillierte, prozessuale Ablauf (Kontrollfluss) innerhalb eines Anwendungsfalls wird im Use-Case-Diagramm bewusst abstrahiert. Hierfür werden in der UML ergänzend Aktivitätendiagramme oder Sequenzdiagramme genutzt.

Systemkontext und Systemgrenze

Ein vollständiges Anwendungsfalldiagramm führt alle Elemente innerhalb eines umschließenden Systemrahmens (Systemgrenze / System Boundary) zusammen. Die Systemgrenze ist ein fundamentales Konzept: Sie trennt das zu entwickelnde System strikt von seiner Umwelt. Akteure befinden sich als externe Rollen immer außerhalb des Systems, während die Anwendungsfälle die Funktionalität innerhalb des Systems definieren.

Gesamtbeispiel: Der Rahmen definiert die Systemgrenze. Akteure stehen außerhalb, Use Cases innerhalb.

Notation und Erstellung

Die Erstellung eines Anwendungsfalldiagramms folgt methodisch diesen drei Schritten:

1. Akteure identifizieren: Wer oder was interagiert mit der Software? Akteure werden als „Strichmännchen“ (Menschen) oder als Rechteck mit dem Stereotyp <<system>> (externe Systeme) dargestellt. Der Name muss zwingend eine präzise Rolle beschreiben (z. B. Sachbearbeiter, Administrator). Generische Namen wie "User" sind als Modellierungsfehler zu betrachten.
2. Anwendungsfälle definieren: Welche fachlichen Ziele sollen erreicht werden? Anwendungsfälle werden als Ellipsen gezeichnet. Die Benennung erfolgt imperativ oder im Infinitiv im Format Subjekt-Prädikat-Objekt (z. B. "Rechnung stornieren", "Artikel suchen"). Die Formulierung muss prägnant und fachlich verständlich sein.
3. Beziehungen verknüpfen: Akteure und Anwendungsfälle werden durch Kommunikationspfade (Linien) verbunden, um den Interaktionsfluss sichtbar zu machen.

Beziehungsarten (Relationen)

Assoziation

Assoziationen sind die grundlegenden Kommunikationspfade zwischen Akteur und Use Case. Sie drücken aus, dass der Akteur mit dem System interagiert, um den Anwendungsfall auszuführen. Eine Assoziation ist immer binär (verbindet exakt zwei Elemente). Ein Akteur kann mit mehreren Use Cases assoziiert sein und umgekehrt.

Ungerichtete Assoziation

Wird als durchgehende Linie ohne Pfeilspitzen dargestellt. Sie zeigt an, dass eine Kommunikation stattfindet, lässt aber die Initiierungsrichtung (wer den Anstoß gibt) offen. Dies ist die häufigste und flexibelste Form in frühen Analysephasen.

Beispiel einer ungerichteten Assoziation: Die Interaktion ist bidirektional.

Gerichtete Assoziation

Verfügt über eine offene Pfeilspitze und gibt die Navigierbarkeit bzw. den Initiator an. Ein Pfeil zum Use Case bedeutet: Der Akteur stößt den Prozess aktiv an. Ein Pfeil zum Akteur bedeutet: Das System initiiert die Kommunikation zum Akteur (z. B. automatischer E-Mail-Versand an den Kunden). Können beide den Prozess anstoßen, wird auf Pfeile komplett verzichtet.

Beispiel einer gerichteten Assoziation: Die Pfeilspitze definiert den Initiator.

Multiplizitäten

Multiplizitäten (auch Kardinalitäten genannt) definieren, wie viele Instanzen eines Akteurs zeitgleich an wie vielen Instanzen eines Anwendungsfalls beteiligt sind.

Darstellung von Multiplizitäten am Beispiel eines Tischtennis-Rundlaufs

Lesebeispiel der Abbildung:

• An einem Tischtennis-Rundlauf (Use Case) nehmen zwingend mindestens 3 bis beliebig viele (*) Spielerinnen teil (Notation: 3..*). Jede einzelne Spielerin nimmt jedoch zu einem gegebenen Zeitpunkt an exakt 1 Rundlauf-Spiel teil (Notation: 1).
• Ein Spiel kann völlig ohne oder mit beliebig vielen Schiedsrichterinnen stattfinden (0..*). Eine Schiedsrichterin überwacht gleichzeitig maximal ein Spiel (0..1).

Prüfungshinweis: Multiplizitäten spielen in Use-Case-Diagrammen in der Praxis eine untergeordnete Rolle, da sie das Diagramm schnell überladen. Ihre volle konzeptionelle Bedeutung entfalten sie erst im strukturellen Klassendiagramm.

Abhängigkeiten zwischen Anwendungsfällen

Include-Beziehung (<<include>>)

Die include-Beziehung dient der Vermeidung von Redundanz. Sie lagert gemeinsames Verhalten in einen eigenen Use Case aus. Der gestrichelte Pfeil zeigt vom Basis-Use-Case zum inkludierten Use Case.

• Semantik: Wenn der Basis-Anwendungsfall ausgeführt wird, wird der inkludierte Anwendungsfall zwingend immer (zu 100%) mit ausgeführt. Der Basis-Use-Case ist ohne das Inkludat unvollständig.

Include-Beziehung: Der inkludierte Prozess wird zwingend aufgerufen.

Extend-Beziehung (<<extend>>)

Die extend-Beziehung modelliert Ausnahmebehandlungen oder optionale Erweiterungen. Der gestrichelte Pfeil zeigt (im Gegensatz zum Include!) vom erweiternden Use Case (Extension) zurück auf den Basis-Use-Case.

• Semantik: Die Erweiterung wird nur unter bestimmten Bedingungen ausgeführt. Der Basis-Use-Case ist auch ohne die Erweiterung vollständig lauffähig.

Die Integration erfolgt über sogenannte Erweiterungspunkte (Extension Points). Diese markieren im Basis-Use-Case (unterhalb eines Trennstrichs) die genaue Stelle des Eingriffs. Optional kann über ein Notizsymbol eine logische Bedingung (Condition) angefügt werden, die prüft, ob die Erweiterung überhaupt zündet.

Extend-Beziehung mit definierten Erweiterungspunkten und auslösender Bedingung (Condition).

Generalisierung (Vererbung)

Die Generalisierung entspricht dem aus der Objektorientierung bekannten Konzept der Vererbung ("Ist-ein"-Beziehung). Sie wird mit einer durchgehenden Linie und einer hohlen, geschlossenen Pfeilspitze dargestellt, die vom speziellen zum allgemeinen Element zeigt.

Generalisierungsbeziehung: Spezialisierung von Anwendungsfällen oder Akteuren.

• Generalisierung von Akteuren: Der Akteur Fahrer ist eine Spezialisierung des Akteurs Anwender. Der Fahrer erbt alle Zugriffsrechte und Use Cases des allgemeinen Anwenders (z. B. "Login"), besitzt darüber hinaus aber erweiterte, spezifische Berechtigungen (z. B. "Fahrzeug starten").
• Generalisierung von Use Cases: Ein allgemeiner Anwendungsfall wie „Zahlung durchführen“ kann durch spezialisierte Anwendungsfälle wie „Per Kreditkarte zahlen“ oder „Per PayPal zahlen“ generalisiert werden. Die speziellen Fälle erben die grundlegende Funktionalität, setzen sie aber im Detail abweichend um.