Anwendungsfalldiagramm

Einführung

Die Unified Modeling Language (Vereinheitlichte Modellierungssprache), kurz UML, ist eine standardisierte grafische Modellierungssprache zur Beschreibung von Anforderungen und Softwarearchitekturen. Das Anwendungsfalldiagramm ist Teil der UML und wird im englischsprachigen Raum auch als Use Case Diagramm bezeichnet.

Ziel des Anwendungsfalldiagramms ist es, in der Analysephase 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 zwischen potenziellen Anwendern, Auftraggebern (Fachseite) und Auftragnehmern (Entwicklerteam) zu vermitteln. Als strukturierte Anforderungsbeschreibung können Anwendungsfalldiagramme direkt in das Lastenheft mit aufgenommen werden.

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

1. Akteure (engl. actors): In einem Anwendungsfalldiagramm werden potenzielle Benutzer des Systems identifiziert. Diese Benutzer nennt man Akteure. Jeder Akteur hat gewisse Erwartungen an die Software. Benutzer erwarten, dass das Programm ihnen hilft, ihre Aufgaben schneller und einfacher zu lösen.
2. Anwendungsfälle (engl. use cases): Diese Aufgaben der Benutzer nennt man Anwendungsfälle. Sie erzeugen für den Anwender ein Ergebnis von messbarem Wert.
3. Beziehungen (engl. relations): Die Verbindung zwischen Akteur und Anwendungsfall (oder zwischen Anwendungsfällen untereinander) nennt man Beziehung oder Relation.

Hinweis zur Abgrenzung: Der detaillierte, prozessuale Ablauf von Anwendungsfällen wird nicht hier, sondern vorzugsweise in einem UML-Aktivitätendiagramm dargestellt.

Notation

Der Aufbau eines Anwendungsfalldiagramms folgt methodisch folgenden drei Regeln:

1. Akteure identifizieren: Als erstes sollte man klären, welche unterschiedlichen Akteure die zu erstellende Software benutzen werden. Akteure werden als „Strichmännchen“ dargestellt. Alle notwendigen Benutzer der Software sind darzustellen. Dies sind in der Regel Personen wie Kunden, Mitarbeiter oder Administratoren. Es können aber auch andere Software-Systeme sein, die eine Anwendung benutzen werden. Jeder Akteur sollte einen aussagekräftigen und selbsterklärenden Namen haben. „User“ bzw. „Akteur“ sind keine aussagekräftigen Namen, da sie für jede Software gültig sind.
2. Anwendungsfälle definieren: Als zweites sollte geklärt werden, welche Anwendungsfälle die Software erfüllen soll. Anwendungsfälle werden in Ellipsen dargestellt. In diese Ellipsen wird die inhaltliche Beschreibung geschrieben. Es wird empfohlen, den Anwendungsfall kurz und aussagekräftig zusammenzufassen. Trotz der Kürze muss er verständlich bleiben! Daher sollte er in einem ganzen, aber möglichst knappen Satz im Sinne von Subjekt-Prädikat-Objekt (bzw. im Infinitiv) formuliert werden.
3. Beziehungen verknüpfen: Erst im dritten Schritt werden die Anwendungsfälle und Akteure über Beziehungen miteinander verbunden. Beziehungen zwischen Akteuren und Anwendungsfällen müssen durch Linien gekennzeichnet werden.

Beziehungen

Assoziation

Assoziationen verbinden Akteure mit Use Cases. Eine Assoziation bedeutet, dass der User die Aktion ausführen kann und somit mit dem System interagiert, das den Use Case enthält. Dabei darf ein einzelner Use Case mit mehreren Akteuren und ein einzelner Akteur mit mehreren Use Cases verbunden sein. Eine einzelne Assoziation muss immer genau zwei Elemente miteinander verbinden (binäre Assoziation).

Ungerichtete Assoziation

Ungerichtete Assoziationen werden als eine durchgehende Linie dargestellt. Es ist die offenste Form der Darstellung und lässt Spielraum für Interpretation bezüglich des genauen Datenflusses.

Gerichtete Assoziation

Pfeile an der Assoziation geben an, wer die Aktion initiieren kann. Hier spricht man von einer gerichteten Assoziation. Ein Pfeil, der auf den Use Case gerichtet ist, besagt, dass nur der Akteur die Aktion initiieren kann, während ein Pfeil, der auf den Akteur zeigt, besagt, dass nur der Use Case die Aktion initiieren kann. Können beide Seiten die Aktion initiieren, werden die Pfeile weggelassen, anstatt zwei Pfeile zu setzen.

Multiplizitäten

Multiplizitäten geben an, wie viele Akteure mit wie vielen Anwendungsfällen in Beziehung stehen. Sie werden an gerichtete oder ungerichtete Assoziationen modelliert.

Die Multiplizitäten sind im obigen Beispiel wie folgt zu lesen:

• An einem Tischtennis-Rundlauf sind mindestens 3 Spielerinnen beteiligt. Die Obergrenze ist als * bzw. beliebig definiert und die Untergrenze ist 3. Jede Spielerin jedoch kann an exakt einem Rundlauf-Spiel teilnehmen. Hier sind die Ober- und Untergrenze 1.
• An einem Rundlaufspiel können keine oder beliebig viele Schiedsrichterinnen beteiligt sein (0..*). Jede Schiedsrichterin kann an höchstens einem Rundlaufspiel beteiligt sein (0..1).

Da diese Information jedoch häufig für die Adressaten des Use Case Diagramms keine Rolle spielt, werden Multiplizitäten im Anwendungsfalldiagramm eher selten notiert. Eine elementare Rolle spielen sie hingegen beim Klassendiagramm.

Includes

include-Beziehungen (dt. beinhalten) werden mittels einer mit <<include>> gekennzeichneten gestrichelten Linie und einem Pfeil zum inkludierten Anwendungsfall gekennzeichnet. Hierdurch wird abgebildet, dass der inkludierte Anwendungsfall immer zwingend ausgeführt werden muss.

Die Include-Anweisung gibt an, dass ein Use Case alle inkludierten Use Cases zwingend mitbenutzt. Die Include-Beziehung wird durch eine gestrichelte Linie dargestellt, die durch das Schlüsselwort <<include>> gekennzeichnet ist und vom Basis Use Case einen Pfeil in Richtung des zu inkludierenden Use Cases hat.

Extend

Die extend-Beziehung gibt an, dass ein Use Case optional ist und nur unter bestimmten Bedingungen ausgeführt wird. Sie wird durch eine gestrichelte Linie dargestellt, die durch das Schlüsselwort <<extend>> gekennzeichnet ist und vom Extension Use Case (Erweiterung) einen Pfeil in Richtung des Basis Use Cases hat.

Der Basis Use Case bestimmt sogenannte Erweiterungspunkte (Extension Points), die den präzisen Ort innerhalb des Use Cases angeben, an dem Extensions hinzugefügt werden dürfen. Erweiterungspunkte werden dargestellt, indem dem Use Case eine horizontale Linie hinzugefügt wird, unter der das Schlüsselwort extension points steht, gefolgt von den Namen der Erweiterungspunkte.

Optional kann an eine Extend-Anweisung eine Bedingung (Condition) hinzugefügt werden, die beschreibt, unter welchen Voraussetzungen bezogen auf den Erweiterungspunkt der Extend Use Case ausgeführt wird. Die Bedingung wird in der UML als Notizzettel dargestellt, der das Schlüsselwort Condition enthält, gefolgt von der Bedingung in geschweiften Klammern und darunter der Erweiterungspunkt, auf den sich die Bedingung bezieht. Die Bedingung ist mit einer gestrichelten Linie mit der Linie der Extend-Anweisung verbunden.

Generalisierung

Zwischen zwei Anwendungsfällen und Akteuren kann eine Generalisierungsbeziehung existieren (Vererbungspfeil). Ausgedrückt wird damit, dass der spezialisierte Anwendungsfall oder Akteur alle Bestandteile des allgemeinen Anwendungsfalls oder Akteurs beinhaltet. Der spezialisierte Anwendungsfall oder Akteur konkretisiert oder erweitert den allgemeinen Anwendungsfall.

Im obigen Beispiel ist der Akteur Fahrer eine Spezialisierung von Anwender. Ein Fahrer besitzt alle Fähigkeiten, Use Cases und Eigenschaften eines allgemeinen Anwenders, wie z.B. Vorname, Nachname, Benutzername und dass er sich mit dem Benutzernamen und Passwort anmelden kann (login), fügt jedoch spezifische Eigenschaften oder Rollen hinzu.