Anwendungsfalldiagramm
Einführung
Die Unified Modeling Language (Vereinheitlichte Modellierungssprache), kurz UML, ist eine standardisierte graphische Modellierungssprache zur Beschreibung von Anforderungen und Software. Das Anwendungsfalldiagramm ist Teil der UML. Es wird auch Use Case Diagramm genannt.
Ziel des Anwendungsfalldiagramms ist es, in der Analysephase die Anforderungen des Auftraggebers aus fachlicher Sicht für alle Beteiligten verständlich, übersichtlich und vollständig zu modellieren. Es dient als Kommunikationsmittel, um zwischen potentiellen Anwendern, Auftraggebern und Auftragnehmern zu vermitteln. Als strukturierte Anforderungsbeschreibung können Anwendungsfalldiagramme in das Lastenheft mit aufgenommen werden.
Das Anwendungsfalldiagramm besteht aus drei wesentlichen Elementen (Heide Balzer Lehrbuch der Objektmodellierung - Analyse und Entwurf; Spektruk Akademischer Verlag; Seite 62 ff):
In einem Anwendungsfalldiagramm (häufig auch Use-Case-Diagramm genannt) werden potentielle Benutzer des Systems identifiziert. Die Benutzer nennt man Akteure (engl. actors).
Jeder Akteur hat gewisse Erwartungen an die Software. Benutzer erwarten, dass das Programm ihnen hilft, ihre Aufgaben schneller und einfacher zu lösen. Diese Aufgaben nennt man Anwendungsfälle (engl. use case). Diese Aufgaben erzeugen für den Anwender ein Ergebnis von messbarem Wert. Der detaillierte Ablauf von Anwendungsfällen kann besser in einem UML Aktivitätendiagramm dargestellt werden.
Die Verbindung zwischen Akteur und Anwendungsfall nennt man Beziehung (oder Relation engl. relation).
Notation
Der Aufbau eines Anwendungsfalldiagramms folgt folgenden drei Regeln:
1. Als erstes sollte man klären, welche unterschiedlichen Akteure (engl. actors) 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 und selbsterklärenden Namen, da sie für jede Software gültig sind.
2. Als zweites sollte geklärt werden, welche Anwendungsfälle (engl. use case) die Software erfüllen soll. Anwendungsfälle werden in Ellipsen dargestellt. In diese Ellipsen wird die inhaltliche Beschreibung des Anwendungsfalls geschrieben. Es wird empfohlen den Anwendungsfall kurz und aussagekräftig zusammenzufassen. Trotz der Kürze muss der Anwendungsfall verständlich bleiben! Daher sollte er in einem ganzen aber möglichst knappen Satz im Sinne von Subjekt-Prädikat-Objekt formuliert werden.
3. Erst im dritten Schritt sollten die Anwendungsfälle und Akteure über Beziehungen (engl. relation) mit einander verbunden werden. 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
Ungerichtet Assoziationen werden als eine durchgehende Linie dargestellt. Es ist die offenste Form der Darstellung und lässt Spielraum für Interpretation.
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 nicht gerichtet Assoziationen modelliert.
Die Multiplizitäten sind wie folgt zu lesen:
An einem Tischtennis-Rundlauf sind mindestens 3 Spielerinnen beteiligt- Die Obergrenze ist als * bzw. beliebig 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. Jede Schiedsrichterin kann an höchstens einem Rundlaufspiel beteiligt sein.
Da diese Information jedoch häufig für die Adressaten des Use-Case-Diagramms keine Rolle spielt werden Multiplizitäten eher selten notiert. Eine wichtige Rolle spielen Sie beim UML-Klassendiagramm.
Includes
include-Beziehungen (dt. beinhalten) werden mittels (mit <<include>> gekennzeichneter) Linie und einem Pfeil zum inkludierten Anwendungsfall gekennzeichnet. Hierdurch wird abgebildet, dass der inkludierte Anwendungsfall immer ausgeführt werden muss.
Die Include-Anweisung gibt an, dass ein Use-Case alle inkludierten Use-Cases 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. Siewird durch eine gestrichelte Linie dargestellt, die durch das Schlüsselwort <<extend>> gekennzeichnet ist und vom Extension Use-Case 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 hinzufü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 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 (einfacher Pfeil). 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 Beispiel ist der Akteur Fahrer eine Spezialisierung von Anwender. Ein Fahrer hat alle Fähigkeiten und Eigenschaften eines allgemeinen Anwenders, wie z.B. Vorname, Nachname, Benutzername und dass er sich mit dem Benutzernamen und Passwort anmelden kann (login).