Anwendungsfalldiagramm

Use Cases beschreiben die Ziele der Benutzer und eignen sich daher besonders gut, um für Benutzer des Systems (Akteure) relevante funktionale Anforderungen an ein System zu analysieren. Das Use Case Diagramm besteht aus wenigen und sehr anschaulichen Elementen und ist aufgrund seiner Einfachheit bestens zur Kommunikation zwischen Auftraggeber und Auftragnehmer geeignet. Beide Seiten entwickeln ein gemeinsames Bild des Systems, so können Missverständnisse über den Funktionsumfang frühzeitig vermieden werden.

Das Use Case Diagramm ist lediglich die grafische Repräsentation von Anwendungsfällen und deren Beziehungen zur Umwelt und zueinander. Wichtige Informationen stecken in den Meta-Informationen eines Use Cases oder werden durch weitere Diagramme im Detail spezifiziert.
Zu einem Use Case gehört mindestens: Name, Beschreibung (Notiz), Vor- und Nachbedingungen und ein Szenario mit den essenziellen Schritten, die notwendig sind, um den Anwendungsfall durchzuführen.

Durch das Sammeln der wichtigsten Informationen und Anforderungen an das System in Form von Use Cases, bietet sich der einzelne Use Case auch an, als Ausgangspunkt für einen Test Case herangezogen zu werden. Für jeden Use Case (Anwendungsfall) sollte es mindestens einen Test Case (Testfall) geben. Alle in einem Use Case definierten Vor- und Nachbedingungen (Pre- and Post- Conditions), die weiteren qualitativen Anforderungen (Requirements) am Anwendungsfall sowie die einzelnen Szenarien und deren Alternativen dienen zur Ableitung der einzelnen Test Cases.

Das Use Case Diagramm in der nebenstehenden Abbildung zeigt zwei Anwendungsfälle und die zugehörigen Akteure. Die zwei Anwendungsfälle von oben nach unten gelesen suggerieren zwar eine Reihenfolge, diese ist aber seitens der UML weder gegeben noch vorgesehen. Das Diagramm beschreibt nur, welche Anwendungsfälle es gibt und wer daran beteiligt ist. Die Abläufe und die Reihenfolge können im Szenario (natürlich sprachliche Beschreibung des Ablaufes eines Use Cases) oder als eigener Use Case beschrieben werden, z. B. in Aktivitätsdiagrammen, in Zustandsautomaten oder in Sequenzdiagrammen.

Akteure

In einem Anwendungsfalldiagramm werden alle Beteiligten (Stakeholder) eines Vorganges (Anwendungsfalls) mit Hilfe von Akteuren dargestellt. Der Akteur (Actor) ist definiert als eine Rolle, die sich außerhalb des Systems des zugehörigen Anwendungsfalles befindet und mit dem System, beschrieben durch seine Anwendungsfälle, interagiert. Akteure können Personen sein, die das System bedienen, oder Fremdsysteme, die auf das System zugreifen oder mit ihm interagieren. Sie haben Anforderungen an das oder ein Interesse am System und sind entsprechend an den Ergebnissen interessiert. Ebenso können Auslöser unabhängig von Akteuren auftreten, z. B, zeit- ablaufbedingte Trigger.

Ein Akteur beschreibt eine Rolle, die im konkreten Fall durch etwas Gegenständliches (z. B. die Person Maria Musterfrau) ersetzt werden kann. Der Akteur Kunde kann z. B. von jeder Person, die ein Kunde der Bank ist, ersetzt werden. Kann der Akteur nicht durch etwas Gegenständliches ersetzt werden (konkrete Person), sollte er als Abstract gekennzeichnet werden. Abstrakte Elemente werden in UML mit einem kursiven Namen geschrieben. Ein abstraktes Element kann durch keine konkrete Ausprägung in der „Wirklichkeit“ beschrieben werden, sondern dient als Abstraktion.

Die Verwendung eines Akteurs ist manchmal zu „allgemein“ und kann durch die Definition eines UML Profils verfeinert werden. Tim Weilkiens hat einen Vorschlag für ein Erweiterungsprofil im Buch „Systems Engineering mit SysML/UML“ gezeigt. Darin werden Akteure in Benutzersystem, Sensor, Aktuator, Umwelteinfluss, etc. verfeinert.

Anwendungsfall

Ein Anwendungsfall (Use Case) spezifiziert eine Funktion (Menge von Aktionen), die von einem System ausgeführt werden und zu einem Ergebnis führen, das üblicherweise von Bedeutung für einen Akteur oder Stakeholder ist. Anwendungsfälle stehen für das Verhalten eines Systems und werden in der Regel durch Verhaltensdiagramme näher beschrieben. Passende Anwendungsfälle für ein Ticketsystem sind z.B. das Kaufen, das Reservieren oder das Stornieren von Eintrittskarten.

Notation von Anwendungsfällen

Die folgende Abbildung zeigt verschiedene Notationsformen von Anwendungsfällen. Die linke Abbildung ist die Standardnotation. Es ist aber auch erlaubt, den Namen des Anwendungsfalles unterhalb der Elipse zu notieren. Das hat den Vorteil, dass die Größe der Ellipse nicht mit der Länge des Anwendungsfallnamens skalieren muss. Sowie Akteure als Rechteck mit Stereotyp Actor dargestellt werden können, ist dies auch bei Use Cases möglich. Anstelle des Stereotyps «Use Case» bietet die UML eine Darstellungsoption mit Use Case Symbol an.

Beziehungen

Die Anwendungsfälle und Akteure stehen in bestimmter Beziehung zueinander. Die Beziehungen werden mit Linien modelliert. Eine solche Verbindung von Akteur und Anwendungsfall bedeutet, dass beide miteinander kommunizieren. Ein Akteur wird mittels einer einfachen Assoziation mit Anwendungsfällen verbunden. Das bedeutet in der Regel, dass der Anwendungsfall vom Akteur ausgeführt werden kann. Durch mehr Details an der Beziehung kann ein semantisch ausdrucksstärkeres Modell erstellt werden.

Wie bei Assoziationen im Klassendiagramm ist auch hier die Angabe von Multiplizitäten möglich. Die Multiplizität auf Seite des Anwendungsfalles gibt an, wie oft dieser Anwendungsfall vom Akteur gleichzeitig ausgeführt werden darf. Wenn keine Angabe gemacht wird, ist die Multiplizität immer 0..1. Auf der Seite des Akteurs bedeutet die Multiplizität, wie viele Akteure der angegebenen Rolle am Anwendungsfall beteiligt sein müssen bzw. können. Wenn keine Angabe gemacht wird, ist die Multiplizität 1..1 oder vereinfacht geschrieben 1.

Üblicherweise verwendet man keine Navigationsangaben. Gerichtete Assoziationen sind aber erlaubt. Sie bedeuten keine Datenflussrichtung – so werden sie meist interpretiert -, sondern geben den Initiator der Kommunikation zwischen Akteur und System an. Somit wird beschrieben, welcher Teil der aktive und welcher der passive ist. Wenn ein Akteur zu einem Anwendungsfall navigiert, dann ist der Akteur der aktive Teil und stößt den Anwendungsfall an. Im umgekehrten Fall, Navigation vom Anwendungsfall zum Akteur, ist der Akteur der passive und wird vom Anwendungsfall benötigt und aufgefordert teilzunehmen.

Das Beispiel in Abb. 9 beschreibt, dass ein Kunde den Use Case Geld abheben anstößt, aber maximal 1x gleichzeitig. Um Geld abheben auszuführen, wird der Actor Bank-Server benötigt (er ist passiv). Der Bank-Server kann allerdings in beliebig vielen Geld abheben Anwendungsfällen gleichzeitig involviert sein, der Kunde hingegen nur 1x.

Im Use Case Diagramm wird durch die «include» Beziehung beschrieben, dass ein Use Case immer einen anderen Use Case aufruft. Wann genau der eingebundene Use Case auszuführen ist, kann nicht im Diagramm beschrieben werden. Dies wird im UseCase Szenario textuell beschrieben oder in einem Verhaltensdiagramm, welches den Use Case detaillierter darstellt.

Hinweis: Bei der Verwendung von Enthält-Beziehungen ist darauf zu achten, dass nur Use Cases des gleichen Abstraktionsniveaus verbunden werden. Das Inkludieren verleitet dazu, immer tiefer und detaillierter in das zu beschreibendes System einzutauchen. EinUse Case PIN eingeben, der in Authentifizieren enthalten sein soll (include), wäre zu detailliert. Hinzu kommt, dass PIN eingeben ein schlechter Use Case ist, da der Prozess (Workflow) hinter PIN eingeben zu gering ist, um einen eigenen Use Case dafür zu definieren.

Merke: Oft benötigte Sachverhalte werden als eigene Use Cases beschrieben und können durch

«include» Beziehungen beliebig oft wiederverwendet werden. Jeder Use Case, der durch eine

«include» Beziehungen eingebunden wurde, wird IMMER ausgeführt, wenn der einbindende Use Case ausgeführt wird.

Erweiterungsbeziehung

Werden Teile eines Use Cases nur unter speziellen Bedingungen ausgeführt, können diese Teile als eigene Anwendungsfälle modelliert und mittels «extend» Beziehung eingebunden werden.

Die Erweiterungsbeziehung zeigt auf den Anwendungsfall, der erweitert wird, und geht von dem Anwendungsfall aus, der das Verhalten der Erweiterung beschreibt (siehe Abb. 11).

Achtung: Intuitiv würde man «extend» anders herum interpretieren. Der Pfeil zeigt aber in Richtung des Use Cases, der erweitert wird ( A «extend» B ). Sonst müsste die Beziehung «extended by» heißen.

Der erweiterte Use Case kann optional durch einen sogenannten Erweiterungspunkt (extension point) genauer beschrieben werden (siehe Abb. 12). Ein Erweiterungspunkt beschreibt das Ereignis, unter dem die Erweiterung aktiviert wird. Ein Anwendungsfall kann beliebig viele Erweiterungspunkte definieren. Zusätzlich zum Erweiterungspunkt können auch noch Bedingungen definiert werden. Wenn keine Bedingung angegeben wird, findet die Erweiterung immer statt. Mit dem erweiternden Anwendungsfall muss nicht zwingend ein Akteur verbunden sein. Ist dies der Fall, kann er mit dem Stereotyp «secondary»bezeichnet werden.

Das Beispiel „Geld abheben“ zeigt den Use Case Bargeld abheben in Rechtecknotation. Der Use Case beinhaltet zwei Erweiterungspunkte. Beide Erweiterungspunkte beschreiben, unter welcher Bedingung die Erweiterung ausgeführt wird. Die Erweiterungsbeziehung enthält eine Einschränkung (Constraint: {Papier vorhanden}). Der Erweiterungspunkt muss eintreten und die Einschränkung muss erfüllt sein, erst dann wird der erweiternde Use Case ausgeführt.

Wie bei der «include» Beziehung wird auch bei der «extend» Beziehung im Diagramm kein Zeitpunkt angegeben, wann der erweiternde Use Case ausgeführt wird. Der Zeitpunkt kann ebenfalls im Use Case Szenario bzw. in einem Verhaltensdiagramm definiert werden.

Spezialisierung (Generalisierung)

Ein Anwendungsfall (oder auch ein Akteur) kann durch weitere Anwendungsfälle (oder Akteure) spezialisiert werden. Beispielsweise ist der Verkauf an der Abendkasse mit dem Verkauf im Internet bis auf den Vertriebsweg ähnlich. Es bietet sich an, einen generellen Anwendungsfall „Verkaufen“ zu erstellen und in der Spezialisierung dieses Anwendungsfalls die geänderten Abfertigungsschritte, die durch die verschiedenen Vertriebswege entstehen, unterzubringen.

Generalisierungsbeziehungen werden auch eingesetzt, um Funktionalitäten allgemein und abstrakt zu beschreiben. Der Use Case Authentifizierung in Abbildung Abb. 14 ist abstrakt und kann selbst nicht ausgeführt werden. Die beiden Verfeinerungen Fingerprint Authentifizierung und PIN-Code Authentifizierung sind zwei konkrete Varianten des allgemeinen Use Cases. Authentifizierung kann als „Platzhalter“ verwendet werden, um zu verdeutlichen, dass sich Kunden authentifizieren müssen und eine der beiden Varianten gewählt werden kann.

Der abstrakte Use Case Authentifizierung enthält eine allgemeine Beschreibung darüber, wie eine Authentifizierung durchgeführt wird. Die konkreten Use Cases beschreiben die Abweichung desgenerelleren Falls, wie im oberen Beispiel des Use Cases „Verkaufen“ beschrieben ist.

Merke: Die Generalisierung zeigt immer in Richtung des generelleren Elements, daher der Name

„Generalisierung“. Bei dieser Art der Verbindung spricht man auch von einer is-a Beziehung, da alles vom generelleren Element„geerbt“ wird. Der Kunde der eigenen Bank ist also auch ein Kunde.

Beschreibungen und Notizen

UML gestattet für alle Anwendungsfälle und Akteure detaillierte Beschreibungen in Form von verbalen Formulierungen anzufügen. Alternativ können Verhaltensmodelle verwendet werden, um Details in strukturierter Form anzufügen. Notizen können den Diagrammen hinzugefügt werden, die auf wesentliche Gestaltungsüberlegungen hinweisen. Notizen werden mit einem Rechteck dargestellt, deren rechte obere Ecke eingeknickt ist.

Eine gestrichelte Line stellt die Verbindung zwischen der Notiz und dem zu erklärendes Element her. Um Doppelgleisigkeiten zwischen den in den Diagrammen aufscheinenden Notizen und Angaben in den Elementen zu vermeiden, wurde auch vorgesehen, interne Inhalte zitieren zu dürfen.

Beispiel

Ein Kunde möchte mit der Bankomatkarte Geld am Automaten abheben. Der Akteur Kunde charakterisiert die Rolle des Kunden und ist die Generalisierung für die Akteur-Rolle Kunde der eigenen Bank. Der spezialisierte Akteur Kunde der eigenen Bank kann über die Rolle Kunde den Anwendungsfall Authentifizieren ausführen, der für beide Kundenarten gleichermaßen abläuft.

Dieser Anwendungsfall enthält den Anwendungsfall Konto- und Pin-Kontrolle, bei dem die Berechtigung des Kunden zur Kartennutzung überprüft wird. Wurde mehrfach eine falsche PIN eingegeben (Constraint: {3x falsch angemeldet}), wird die Karte eingezogen. Um dies zu modellieren, wird der Anwendungsfall Authentifizieren mit dem Anwendungsfall Karte einziehen erweitert. Dieser wird nur unter der Bedingung, dass der Kunde sich mehrfach nicht identifizieren konnte, abgearbeitet.