Anwendungsfalldiagramm

Einführung

Die Unified Modeling Language (Vereinheitlichte Modellierungssprache), kurz UML, ist eine standardisierte grafische Modellierungssprache zur Beschreibung, Spezifikation und Dokumentation von Anforderungen und Softwarearchitekturen. Das Anwendungsfalldiagramm (engl. Use Case Diagramm) ist ein elementares Verhaltensdiagramm der UML.

Ziel des Anwendungsfalldiagramms ist es, in der Analysephase (Requirements Engineering) die funktionalen Anforderungen des Auftraggebers aus fachlicher Sicht für alle Beteiligten verständlich, übersichtlich und vollständig zu modellieren. Es dient als zentrales Kommunikationsmittel, um barrierefrei zwischen potenziellen Anwendern, Auftraggebern (Fachseite) und Auftragnehmern (Entwicklungsteam) zu vermitteln. Als strukturierte funktionale Anforderungsbeschreibung sind Anwendungsfalldiagramme ein fester Bestandteil des Lastenhefts und bilden die primäre Grundlage für das Pflichtenheft.

Das Anwendungsfalldiagramm besteht aus drei wesentlichen Elementen:

1. Akteure (engl. actors): Sie identifizieren die externen Benutzer oder Systeme, die mit dem System interagieren. Jeder Akteur repräsentiert eine Rolle und keine konkrete Person.
2. Anwendungsfälle (engl. use cases): Sie beschreiben die vom System angebotenen Funktionalitäten und Aufgaben, die für den Akteur ein Ergebnis von messbarem, fachlichem Wert erzeugen.
3. Beziehungen (engl. relations): Sie definieren die Kommunikationspfade zwischen Akteuren und Anwendungsfällen sowie die strukturellen Abhängigkeiten der Anwendungsfälle untereinander.

Hinweis zur Abgrenzung: Ein Anwendungsfalldiagramm bildet keine zeitlichen, logischen oder prozessualen Abläufe ab. Für die Modellierung von Kontrollflüssen und sequentiellen Prozessen sind stattdessen UML-Aktivitätendiagramme oder Sequenzdiagramme zu verwenden.

Gesamtbeispiel (Systemkontext)

Ein vollständiges Anwendungsfalldiagramm führt alle Funktionseinheiten innerhalb eines umschließenden Systemrahmens (Systemgrenze / System Boundary) zusammen. Der Rahmen grenzt das zu entwickelnde System strikt von seiner Umwelt ab: Akteure stehen als externe Entitäten immer außerhalb des Systems, während die Anwendungsfälle die interne Funktionalität definieren.

Gesamtbeispiel eines Use-Case-Diagramms mit Systemgrenze, Akteuren und verknüpften Beziehungen

Notation

Der methodische Aufbau eines standardkonformen Anwendungsfalldiagramms folgt drei sequentiellen Schritten:

1. Akteure identifizieren: Es wird festgelegt, welche unterschiedlichen Rollen das System nutzen werden. Menschliche Rollen werden grafisch als Strichmännchen dargestellt, externe Software- oder Hardwaresysteme als Rechtecke mit dem Stereotyp «system». Jeder Akteur muss einen eindeutigen, selbsterklärenden Namen im Singular erhalten (z. B. Kunde, Administrator). Allgemeine Bezeichnungen wie „User“ oder „Akteur“ sind zu vermeiden, da sie für fast jedes Softwaresystem gültig sind und keine spezifische Rolle beschreiben.
2. Anwendungsfälle definieren: Es wird geklärt, welche fachlichen Ziele das System erfüllen muss. Anwendungsfälle werden als horizontale Ellipsen dargestellt, die eine kurze Inhaltsbeschreibung enthalten. Die Formulierung muss kurz, aussagekräftig und im Infinitiv bzw. im Format Subjekt-Prädikat-Objekt erfolgen (z. B. Artikel suchen, Passwort zurücksetzen).
3. Beziehungen verknüpfen: Erst im letzten Schritt werden die Akteure und Anwendungsfälle über strukturierte Beziehungslinien miteinander verbunden, um die Interaktionskanäle visuell zu definieren.

Beziehungen

Assoziation

Assoziationen bilden die grundlegenden Kommunikationspfade zwischen Akteuren und Use Cases. Eine Assoziation signalisiert, dass der verknüpfte Akteur die Aktion des Use Cases ausführen oder mit diesem interagieren kann. Es handelt sich um eine binäre Beziehung, die exakt zwei Elemente miteinander verbindet. Ein einzelner Use Case darf mit mehreren Akteuren und ein einzelner Akteur mit mehreren Use Cases verbunden sein.

Ungerichtete Assoziation

Ungerichtete Assoziationen werden als einfache, durchgehende Linie dargestellt. Sie stellt die offenste Form der Interaktion dar und signalisiert einen bidirektionalen Informationsfluss, lässt jedoch die Richtung der Initiierung (wer die Aktion startet) offen.

Ungerichtete Assoziation als einfache Verbindungslinie

Gerichtete Assoziation

Eine gerichtete Assoziation verwendet eine offene Pfeilspitze, um die Navigierbarkeit und den Initiator des Prozesses eindeutig festzulegen.

• Ein Pfeil, der auf den Use Case gerichtet ist, besagt, dass der Akteur den Anwendungsfall aktiv initiiert.
• Ein Pfeil, der auf den Akteur zeigt, besagt, dass der Use Case (bzw. das System) die Interaktion zum Akteur hin anstößt (häufig bei sekundären Systemen oder Benachrichtigungsdiensten).
• Können beide Seiten die Aktion unabhängig voneinander initiieren, werden die Pfeile weggelassen.

Gerichtete Assoziation mit Pfeil zur Kennzeichnung des Initiators

Multiplizitäten

Multiplizitäten (Kardinalitäten) geben an, wie viele Instanzen eines Akteurs mit wie vielen Instanzen eines Anwendungsfalls in einer konkreten Systeminteraktion in Beziehung stehen können. Sie werden direkt an den Enden der Assoziationslinien notiert.

Modellierung von Multiplizitäten am Beispiel eines Tischtennis-Rundlaufs

Die Multiplizitäten des Beispiels sind gemeldet nach UML-Standard wie folgt zu interpretieren:

• An einem Tischtennis-Rundlauf (Use Case) sind mindestens 3 Spielerinnen beteiligt. Die Untergrenze ist 3, die Obergrenze ist als * (beliebig viele) definiert (Notation: 3..*). Jede Spielerin kann jedoch zeitgleich an exakt einem Rundlauf-Spiel teilnehmen (Notation: 1).
• An einem Rundlaufspiel können keine oder beliebig viele Schiedsrichterinnen beteiligt sein (Notation: 0..*). Jede Schiedsrichterin kann wiederum an höchstens einem Rundlaufspiel aktiv beteiligt sein (Notation: 0..1).

Hinweis für die Praxis: Da diese Detailinformationen die Adressaten eines Use-Case-Diagramms häufig überfordern, werden Multiplizitäten hier selten notiert. Ihre zentrale und fundamentale Bedeutung entfalten sie im strukturellen Klassendiagramm.

Includes (Inklusion)

Eine Include-Beziehung (dt. beinhalten oder einschließen) beschreibt eine zwingende Abhängigkeit zur Vermeidung von funktionaler Redundanz (Wiederverwendung von Use Cases).

Die Beziehung wird durch eine gestrichelte Linie mit einer offenen Pfeilspitze dargestellt, die mit dem Stereotyp «include» gekennzeichnet ist. Der Pfeil startet immer beim Basis-Use-Case und zeigt in Richtung des zu inkludierenden Use Cases.

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

Zwingende Include-Beziehung zur Auslagerung gemeinsamer Funktionalitäten

Extend (Erweiterung)

Eine Extend-Beziehung (dt. erweitern) beschreibt ein optionales Verhalten, das den Basis-Use-Case nur unter ganz bestimmten Bedingungen ergänzt.

Die Beziehung wird durch eine gestrichelte Linie mit einer offenen Pfeilspitze dargestellt, die mit dem Stereotyp «extend» gekennzeichnet ist. Die Pfeilrichtung verhält sich umgekehrt zum Include: Der Pfeil startet beim Extension-Use-Case (Erweiterung) und zeigt in Richtung des Basis-Use-Cases.

Der Basis-Use-Case deklariert sogenannte Erweiterungspunkte (Extension Points), die den präzisen Ort innerhalb des Ablaufs definieren, an dem die Erweiterung eingreifen darf. Grafisch wird hierzu in der Ellipse des Basis-Use-Cases eine horizontale Trennlinie eingezogen, unter der das Schlüsselwort extension points: gefolgt von den Namen der Punkte steht.

Optional wird an die Extend-Linie über eine fein gestrichelte Linie ein UML-Notizsymbol angeheftet. Dieses enthält das Schlüsselwort Condition: gefolgt von der logischen Bedingung in geschweiften Klammern {...} sowie den Verweis auf den zugehörigen Erweiterungspunkt.

• Semantik: Der Basis-Use-Case ist auch ohne die Erweiterung vollkommen autark lauffähig. Der Extension-Use-Case wird nur dann ausgeführt, wenn die definierte Bedingung am Erweiterungspunkt wahr (true) ist.

Optionale Extend-Beziehung mit expliziten Extension Points und Notizfeld für die Bedingung (Condition)

Generalisierung (Vererbung)

Zwischen Akteuren untereinander sowie zwischen Anwendungsfällen untereinander kann eine Generalisierungsbeziehung existieren. Sie modelliert eine klassische "Ist-ein"-Beziehung, analog zur Vererbung in der objektorientierten Programmierung.

Die Generalisierung wird grafisch durch eine durchgehende Linie mit einer geschlossenen, hohlen Dreieckspfeilspitze dargestellt. Der Pfeil zeigt immer vom spezialisierten Element (Unterklasse) zum allgemeinen Element (Oberklasse).

Strukturelle Generalisierung zwischen Akteuren oder Funktionseinheiten

• Generalisierung von Akteuren: Im Beispiel ist der Akteur Fahrer eine Spezialisierung von Anwender. Der Fahrer erbt bedingungslos alle Fähigkeiten, Use Cases und Attribute des allgemeinen Anwenders (z. B. Stammdaten und die Interaktion mit dem Use Case Login durchführen), konkretisiert oder erweitert diese Rolle jedoch um spezifische Eigenschaften.
• Generalisierung von Anwendungsfällen: Ein abstrakter Anwendungsfall wie „Medium brennen“ kann durch spezialisierte Anwendungsfälle wie „CD brennen“ oder „DVD brennen“ geerbt und ausdifferenziert werden.