Anwendungsfalldiagramm: Unterschied zwischen den Versionen

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 [[Lastenheft]]s und bilden die primäre Grundlage für das [[Pflichtenheft]].

Das Anwendungsfalldiagramm besteht aus drei wesentlichen Elementen:

# '''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.

# '''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.

# '''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.

[[Datei:AnwendungsfallSys.png|mini|Gesamtbeispiel eines Use-Case-Diagramms mit Systemgrenze, Akteuren und verknüpften Beziehungen]]

== Notation ==

Der methodische Aufbau eines standardkonformen Anwendungsfalldiagramms folgt drei sequentiellen Schritten:

# '''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 <code>«system»</code>. 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.

# '''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'').

# '''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 ===

==== 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.

[[Datei:AnwendungsfallEinweihungsfeier.png|mini|Ungerichtete Assoziation als einfache Verbindungslinie]]

==== Gerichtete Assoziation ====

* 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.

[[Datei:AnwendungsfallHotelreservierung.png|mini|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.

[[Datei:AnwendungsfallTischtennis.png|mini|Modellierung von Multiplizitäten am Beispiel eines Tischtennis-Rundlaufs]]

* An einem Tischtennis-Rundlauf (Use Case) sind mindestens 3 Spielerinnen beteiligt. Die Untergrenze ist <code>3</code>, die Obergrenze ist als <code>*</code> (beliebig viele) definiert (Notation: <code>3..*</code>). Jede Spielerin kann jedoch zeitgleich an exakt einem Rundlauf-Spiel teilnehmen (Notation: <code>1</code>).

* An einem Rundlaufspiel können keine oder beliebig viele Schiedsrichterinnen beteiligt sein (Notation: <code>0..*</code>). Jede Schiedsrichterin kann wiederum an höchstens einem Rundlaufspiel aktiv beteiligt sein (Notation: <code>0..1</code>).

''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 <code>«include»</code> 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.

[[Datei:AnwendungsfallHotelreservierungKomplex.png|mini|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 <code>«extend»</code> 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 <code>extension points:</code> 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 <code>Condition:</code> gefolgt von der logischen Bedingung in geschweiften Klammern <code>{...}</code> 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.

[[Datei:AnwendungsfalldiagrammHotelreservierungKomplexErkl.png|mini|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)'''.

[[Datei:AnwendungsfallCD.png|mini|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.