Anwendungsfalldiagramm: Unterschied zwischen den Versionen

Die '''Unified Modeling Language''' (Vereinheitlichte Modellierungssprache), kurz UML, ist eine standardisierte grafische Modellierungssprache zur Beschreibung von Anforderungen und Softwarearchitekturen. Das '''Anwendungsfalldiagramm''' (häufig auch ''Use-Case-Diagramm'' genannt) ist ein elementares Verhaltensdiagramm der UML.

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 zentrales Kommunikationsmittel, um zwischen potenziellen Anwendern, Auftraggebern und Auftragnehmern zu vermitteln. Als strukturierte Anforderungsbeschreibung können Anwendungsfalldiagramme direkt in das Lastenheft mit aufgenommen werden.

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

* '''Akteure (engl. ''actors''):''' Potentielle Benutzer oder externe Systeme, die mit der Software interagieren.

* '''Anwendungsfälle (engl. ''use cases''):''' Aufgaben, die für den Anwender ein Ergebnis von messbarem Wert erzeugen und bei deren Lösung das System hilft.

* '''Beziehungen (engl. ''relations''):''' Verbindungen zwischen Akteuren und Anwendungsfällen oder zwischen Anwendungsfällen untereinander.

''Hinweis:'' Der detaillierte, prozessuale Ablauf von Anwendungsfällen wird in der UML typischerweise nicht hier, sondern in einem intern verlinkten [[Aktivitätendiagramm]] abgebildet.

== Notation und Aufbau ==

Der systematische Aufbau eines Anwendungsfalldiagramms folgt in der Regel diesen drei Schritten:

# '''Akteure identifizieren:''' Zuerst wird geklärt, welche unterschiedlichen Akteure das zu erstellende System nutzen werden. Akteure werden grafisch als „Strichmännchen“ dargestellt. Dies können Personen (Kunden, Mitarbeiter, Administratoren) oder angrenzende Software-Systeme sein. Jeder Akteur muss einen aussagekräftigen, selbsterklärenden Namen erhalten (allgemeine Bezeichnungen wie „User“ sind zu vermeiden, da sie für jede Software gelten).

# '''Anwendungsfälle definieren:''' Im zweiten Schritt wird festgelegt, welche Aufgaben die Software erfüllen soll. Anwendungsfälle werden als Ellipsen dargestellt und enthalten eine kurze, inhaltliche Beschreibung. Die Formulierung sollte knapp, aber verständlich sein und bevorzugt im Format ''Subjekt-Prädikat-Objekt'' formuliert werden.

# '''Beziehungen herstellen:''' Erst im letzten Schritt werden Akteure und Anwendungsfälle durch Linien miteinander verbunden, um die konkrete Interaktion zu modellieren.

== Beziehungen (Relationen) ==

| '''Ungerichtete Assoziation'''

| Verbindet Akteure mit Anwendungsfällen. Sie drückt aus, dass der User die Aktion ausführen kann und mit dem System interagiert. Ein Anwendungsfall darf mit mehreren Akteuren verbunden sein und umgekehrt. Eine binäre Assoziation verbindet immer genau zwei Elemente. Dies ist die offenste Form der Darstellung.

| '''Gerichtete Assoziation'''

| Gibt die Initiierungsrichtung an. Ein Pfeil zum Anwendungsfall bedeutet, dass nur der Akteur die Aktion initiieren kann. Ein Pfeil zum Akteur besagt, dass das System die Aktion anstößt. Können beide Seiten initiieren, wird auf Pfeile komplett verzichtet.

| '''Include-Beziehung'''<br/>(dt. ''beinhalten'')

| Gibt an, dass der Basis-Anwendungsfall das Verhalten des inkludierten Anwendungsfalls zwingend mitbenutzt und immer ausführt.

| '''Extend-Beziehung'''<br/>(dt. ''erweitern'')

| Gibt an, dass ein Anwendungsfall optional ist und den Basis-Anwendungsfall nur unter bestimmten Bedingungen erweitert.

| '''Generalisierung'''<br/>(Vererbung)

| Zeigt an, dass ein spezialisierter Anwendungsfall (oder Akteur) alle Bestandteile des allgemeinen übernimmt und diese konkretisiert oder erweitert. Beispiel: Der Akteur ''Fahrer'' ist eine Spezialisierung des Akteurs ''Anwender'' und erbt dessen Attribute wie Vorname, Nachname und die Befähigung zum Login.

=== Detaillierte Betrachtung spezifischer Konzepte ===

==== Multiplizitäten ====

Multiplizitäten geben an, wie viele Instanzen eines Akteurs mit wie vielen Anwendungsfällen in Beziehung stehen. Sie werden direkt an gerichteten oder ungerichteten Assoziationen notiert.

* An einem Tischtennis-Rundlauf sind mindestens 3 Spielerinnen beteiligt. Die Untergrenze ist <code>3</code>, die Obergrenze ist <code>*</code> (beliebig viele). Notation: <code>3..*</code>

''Anmerkung:'' Da diese feingranularen Informationen für die Adressaten des Use-Case-Diagramms häufig keine Rolle spielen, werden Multiplizitäten hier eher selten notiert. Eine weitaus wichtigere Rolle spielen sie beim [[Klassendiagramm]].

==== Erweiterungspunkte (Extension Points) und Bedingungen (Conditions) ====

Bei der optionalen '''Extend-Beziehung''' bestimmt der Basis-Anwendungsfall sogenannte Erweiterungspunkte (''Extension Points'').  

* '''Extension Points:''' Sie geben den präzisen Ort innerhalb des Basis-Anwendungsfalls an, an dem Extensions hinzugefügt werden dürfen. Zur Darstellung wird innerhalb der Ellipse eine horizontale Linie gezogen. Darunter steht das Schlüsselwort <code>extension points</code>, gefolgt vom Namen des Erweiterungspunktes.

* '''Bedingung (Condition):''' Optional kann eine Bedingung hinzugefügt werden, die beschreibt, unter welchen Voraussetzungen der Extend-Use-Case ausgeführt wird. Die Bedingung wird als Notizzettel-Symbol dargestellt, das das Schlüsselwort <code>Condition</code> enthält. Darunter steht die Bedingung in geschweiften Klammern und der bezogene Erweiterungspunkt. Dieses Symbol ist über eine gestrichelte Linie mit der Extend-Anweisung verbunden.