Anwendungsfalldiagramm
Use Case Diagramme geben auf hohem Abstraktionsniveau einen sehr guten Überblick über das Gesamtsystem. Sie beschreiben die Funktionalität – die zu erbringenden Dienste und Leistungen – aus Anwendersicht. Jede Beziehung von einem Akteur (Benutzer bzw. externen Systems) zu einem Use Case führt in weiterer Folge meist zur Definition von Interaktionspunkten (Interfaces) im weiterführenden Detaildesign. Zu beachten ist, dass Anwendungsfalldiagramme selbst kein Verhalten und keine Abläufe beschreiben, sondern nur die Zusammenhänge zwischen einer Menge von Anwendungsfällen und den daran beteiligten Akteuren. Diese können zur Anforderungsanalyse und -Verwaltung verwendet werden. Ebenso wird keine Reihenfolge des Auftretens der beschriebenen Leistungen/Dienste dargestellt.
Ein wesentlicher Vorteil des Use Case Diagramms liegt in der Strukturierung der funktionalen Anforderungen – was wird das System leisten können? Alle weiteren Beschreibungen können hierarchisch gegliedert, als Sub Use Cases oder durch andere Modelle, „dahinter“ aufgebaut werden. Projektabsicherung durch rasche Festschreibung des Aufgabenumfangs und eine darauf basierende Aufwandsabschätzung sind weitere Vorteile. Use Cases bieten somit einen Gesamtüberblick über die Funktionen des zu erstellenden Systems.
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.
Abb. 5: Anwendung
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.
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.
Abb. 6: Notation von Akteuren
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.
Abb. 7: Notation von Anwendungsfällen
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.
System (System Boundary)
Das System ist kein direktes, logisches Modellelement der UML. Mit System ist der Kontext des Anwendungsfalles gemeint, in dem die vom Anwendungsfall spezifizierten Aktionen ausgeführt werden. Das System kann dabei z.B. eine Klasse oder eine Komponente sein, welche die gesamte Anwendung repräsentiert. Das System wird durch einen oder mehrere Systemrahmen (Boundary) repräsentiert, die Use Cases – die Leistungen und Dienste -, die das System erbringen soll, werden in den Systemrahmen gezeichnet.
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.
Abb. 8: System
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.
Abb. 9: Multiplizität und aktive/passive Akteure
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.
Use Cases, die nicht direkt von einem Akteur aufgerufen werden können, werden oft mit dem Stereotyp «secondary» versehen. Das gehört nicht zum UML-Standard, es ist aber üblich Anwendungsfälle als „sekundär“ zu bezeichnen, wenn sie nicht direkt von einem Akteur ausgeführt werden können, sondern nur im Kontext eines „primären“ Anwendungsfall Sinn ergeben oder lediglich in dessen Kontext ausführbar sein sollen. Primäre Use Cases werden nicht mit einem zusätzlichen Stereotyp gekennzeichnet.
Abb. 10: Beispiel «include» Beziehung
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.
Abb. 11: Beispiel «extend» Beziehung
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.
Falls ein Use Case von mehreren Use Cases erweitert wird, kann durch Angabe eines Zusatzbuchstabens eine Beziehung zwischen Erweiterungspunkt und «extend» Beziehung erstellt werden (siehe Abb. 12, Zusatz (a) und (b)).
Hinweis: Bei der Verwendung von Erweiterungsbeziehungen ist darauf zu achten, dass nur Use Cases gleichen Abstraktionsniveaus beschrieben werden. Das Erweitern verleitet dazu, immer tiefer und detaillierter in das zu beschreibendes System einzutauchen.
Merke: Das Verhalten von Use Cases kann durch «extend» Beziehungen erweitert werden. Ist ein Erweiterungspunkt definiert (Extension point) wird bei dessen Eintreten eine eventuell vorhandene Bedingung (Constraint) überprüft und anschließend dererweiternde Use Case ausgeführt.
Abb. 12: Beispiel «extend» Beziehung mit Extension Points & Condition
Abb. 13: Generalisierung Use Cases
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.
Ein Akteur beschreibt eine Rolle, diese kann beliebig abstrakt definiert sein. Ein Kunde einer Bank kann z. B. den Use Case Geld abheben durchführen. Falls die Bank, von der Geld abgehoben wird, die Hausbank des Kunden ist, soll er auch Geld einzahlen dürfen.
Dies kann durch einen weiteren Akteur (Kunde der eigenen Bank) beschrieben werden. Da der Kunde der eigenen Bank auch ein Kunde ist, darf er natürlich alles, was ein Kunde darf, somit auch Geld abheben.
Dies kann durch eine Generalisierung zwischen den Akteuren Kunde und Kunde der eigenen Bank geschehen (Kunde der eigenen Bank zeigt zum generelleren Akteur Kunde). Der Kunde der eigenen Bank ist somit auch ein Kunde (Generalisierung wir auch als is-a Beziehung bezeichnet), daher erbt der Kunde der eigenen Bank auch die Beziehung zum Use Case Geld abheben vom Kunden. Der Akteur Kunde hingegen darf den Use Case Geld einzahlen nicht ausführen.
Abb. 14: Generalisierung von Akteuren
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.
Abb. 15: Notizen
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.
| Name/Symbol | Verwendung |
|---|---|
 | Ein Anwendungsfall wird mit einer Ellipse dargestellt, die den Namen des Anwendungsfalls enthält. Der Name des Use Case wird gewöhnlich durch ein Hauptwort und ein Zeitwort gebildet, wodurch das manipulierte Objekt und die durchgeführte Tätigkeit kurz und präzise beschrieben werden. |
 | Ein Anwendungsfall wird durch einen Akteur ausgelöst. Die Darstellung entspricht einem Strichmännchen. Man kann einen Akteur auch in einem Rechteck darstellen und das Stereotyp «Actor» über dem Namen des Akteurs angeben. |
 | Ein Akteur steht in einer Beziehung zum Anwendungsfall, wenn dieser ihn auslöst. Diese Beziehung wird mit einer Verbindungslinie zwischen dem Anwendungsfall und dem Akteur dargestellt. |
 | Wird ein Anwendungsfall durch einen Zweiten unter einer bestimmten Bedingung erweitert, wird diese Beziehung durch die Verbindung der Anwendungsfälle mit einem Pfeil gekennzeichnet, der mit dem Stereotyp «extend» beschriftet wird. Die Pfeilspitze zeigt auf den Anwendungsfall, der erweitert wird. |
 | Ist ein Anwendungsfall in einem Zweiten enthalten, d. h. ist er fester Bestandteil von diesem, werden beide Anwendungsfälle mit einem Pfeil verbunden, der das Stereotyp «include» als Beschriftung erhält. Die Pfeilspitze zeigt auf den enthaltenen Anwendungsfall. |
 | Diese Beziehung kann zwischen Akteuren und zwischen Anwendungsfällen modelliert werden und bedeutet, dass ein Anwendungsfall oder ein Akteur spezialisiert wird. Die Pfeilspitze zeigt auf den Akteur oder Anwendungsfall, der spezialisiert wird. |
 | Notizen sind Diagrammelemente, die an anderen Modellierungselementen angebracht werden. Sie enthalten Informationen zum Verständnis des Modells und werden durch eine unterbrochene Verbindungslinie mit dem Element verbunden. |
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.
Der Akteur Kunde der eigenen Bank kommuniziert direkt (nicht über die Rolle Kunde) mit dem Anwendungsfall Geld einzahlen. Der Kunde hingegen hat keine Beziehung zu dem Use Case Geld einzahlen und darf dies somit auch nicht tun.
Abb. 16: Beispiel Use Case Diagramm
