Björn Klippstein

Use-Case-Diagramm

Klippstein IT Service

Aus 4webmaster.de

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Das Use-Case-Diagramm zeigt das externe Verhalten des Systems aus der Sicht des Users. Dazu werden Akteure, Use-Cases und ihre Beziehungen untereinander dargestellt. Das Diagramm eignet sich gut für einen Überblick über das Systemverhalten auf der gröbsten Detailstufe und für das Verständnis der Anforderungen.

Akteure

  • Akteure sind die handelnden Subjekte in einem Use-Case-Diagramm. Sie interagieren mit dem System (z.B. indem sie Daten austauschen) und rufen ein bestimmtes Verhalten des Systems ab.
  • Akteure können menschlich oder maschinell sein. Beispiele für maschinelle Akteure sind externe Systeme, Subsysteme, Komponenten, Klassen oder ein Zeitgeber.
  • Akteure stehen dabei immer außerhalb des Systems, welches ein bestimmtes Verhalten anbietet.
  • Ein Akteur ist keine konkrete Instanz, sondern wie eine Klasse eine allgemeine Schablone für ein handelndes Subjekt, das eine bestimmte Rolle einnimmt.


Benennung des Akteurs

Akteure mit unterschiedlichem Status, unterschiedlicher Rolle oder unterschiedlichen Bedürfnissen können über den Namen unterschieden werden und über Generalisierungs-Relationen klassifiziert werden.

Status Akteure haben einen bestimmten Zustand oder Status, z.B. lassen sich User in neue User, Erstkunden und Stammkunden differenzieren. User mit unterschiedlichem Status haben oft verschiedene Berechtigungen oder Fähigkeiten.
Rolle Akteure nehmen meist eine bestimmte Rolle wahr. So lassen sich User z.B. in Anbieter, Nachfrager, Käufer, Beobachter etc. differenzieren.
Bedürfnisse  Menschliche Akteure haben Interessen und Bedürfnisse. Beispielsweise lassen sich User in Individualtourist, Pauschaltourist, Wochenendtourist etc. differenzieren.



Use-Cases

Ein Use-Case ("Anwendungsfall") ist ein Arbeitsgang, mit dem der User (oder ein maschineller Akteur) ein bestimmtes, einzelnes Ziel erreichen kann. Damit kapselt ein Use-Case ein bestimmtes, nach außen wahrnehmbares und vollständiges Verhalten, inklusive Fehlerbehandlung und Sonderverhalten bei Spezialfällen.

Jede Einheit, die Verhalten realisieren und nach außen anbieten kann, kann auch Use-Cases haben: Systeme, Subsysteme und Komponenten, aber auch Klassen und Schnittstellen . In UML werden solche Einheiten als Classifier bezeichnet.

Zusammenhängende Use-Cases können in einem Use-Case-Diagramm dargestellt werden. Das Innere der Use-Cases bleibt dort verborgen: Im Use-Case-Diagramm ist es irrelevant bzw. störend zu wissen, wie ein bestimmtes Verhalten erzielt wird. Es interessiert nur: WAS für ein Verhalten zeigt das System nach außen.

Ein Use-Case ist wie eine Klasse eine allgemeine Schablone für Verhalten. Die Reihenfolge der einzelnen Aktionen ist dabei nicht exakt festgelegt. Erst wenn der Use-Case von einer Akteur-Instanz instanziiert wird, wird der Handlungsablauf zu einem konkreten Szenario. Ein Szenario ist eine Instanz eines Use-Case.


Use-Case-Spezifikation

Die Beschreibung des Use-Case sollte das System als Black Box betrachten. Es wird nur das nach außen sichtbare Verhalten dargestellt. Alle internen Abläufe werden weggelassen. Denn die inneren Strukturen können sich ändern, die Beschreibung der Use-Cases soll unabhängig davon sein.

Element Beispiel Beschreibung
Identifier Change MainAddress eindeutiger Identifier für den Use-Case. Die Namen sollten sprechend sein (Change MainAddress statt CMA o.ä.). Sinnvoll ist auch eine einheitliche Systematik bei den Namen, z.B. nach dem Schema Verb-Substantiv oder auch Subjekt-Prädikat-Objekt. Zusätzlich kann ein Nummerierungssystem ähnliche Use-Cases unterscheiden.
Akteure
  • User
  • Datenbank
Welche Akteure nehmen an diesem Use-Case teil?
Vorbedingungen &
Auslöser
  1. User ist eingeloggt
  2. User sieht seine MainAddress, bezeichnet als aktuelle E-Mail-Adresse
  3. User klickt Link
Welche Bedingungen müssen vor dem Ablauf des Use-Case erfüllt sein? Wie wird der Use-Case ausgelöst? Welcher Akteur initiiert ihn und instanziiert den Use-Case damit?
Handlungsablauf * neue Adresse eingeben (einmalig) Welche Aktionen werden ausgeführt? Grobe Skizze des Hauptpfades aus Usersicht, entscheidend ist die Interaktion zwischen Akteur und System. Interne Abläufe, die der Akteur nicht sehen kann, werden weggelassen.
Fehlerbehandlung
  • ungültige Eingabe
       >> Wiederholung anbieten
Was sind die wichtigsten Fehler, die auftreten können, und wie wird damit umgegangen?
Sonderfälle & Alternativen
  • neue Adresse existiert bereits
       >> Join Accounts anbieten
  • nicht erreichbare Domain
       >> Wiederholung anbieten
  • bekannter Tippfehler in Domain 
       >> Wiederholung anbieten
  • neue Adresse gesperrt
       >> alte Adresse auch sperren
Gibt es Sonderfälle, die berücksichtigt werden müssen? Alternative Handlungsabläufe?

Interne Abläufe, die der Akteur nicht erfahren kann, werden wieder weggelassen. Der letzte Punkt des Beispiels ("alte Adresse auch sperren") widerspricht dieser Regel übrigens nicht, denn ganz unabhängig davon ob dem User die Sperrung direkt mitgeteilt wird oder nicht, hat sie doch zur Folge, dass der User sich in Zukunft nicht mehr einloggen kann.
Ergebnis
  1. Ok-Meldung
  2. Login ist zukünftig mit neuer Adresse möglich
  3. alle Mails gehen in Zukunft an die neue Adresse
  4. bei Problemen ist die alte Adresse weiterhin nutzbar
Welches Ergebnis hat der Use-Case aus Sicht des Aktors? D.h.
  1. woran erkennt der Akteur, dass er sein Ziel erreicht hat?
  2. Und vor allem, was hat der Use-Case für den Actor geändert?
Nachbedingungen
  • User ist unter neuer Adresse eingeloggt
Wie sind die Zustände nach dem Ablauf des Use-Case?


Beziehungen im Use-Case-Diagramm

Beziehung zeigt Beschreibung
Akteur Allgemein ◁───▷ Akteur Speziell Vererbung Akteure können untereinander durch Generalisierungs-Assoziationen verbunden werden. Dadurch lässt sich Vererbung realisieren. Beispielsweise kann der Stammkunde die gleichen Dienstleistungen abrufen wie der allgemeine Kunde. In UML weist der Pfeil vom Speziellen ───▷ Allgemeinen, stellt also die Abhängigkeit dar (das Spezielle ist vom Allgemeinen abhängig, nicht umgekehrt).
Akteur ──── Use-Case Interaktion Akteure interagieren mit den einzelnen Use-Cases, indem sie dessen Ausführung initiieren oder Daten liefern. Die Interaktion zwischen Use-Case und Akteur wird als (zweistellige) Assoziation zwischen Akteur und Use-Case dargestellt. Genau wie bei Assoziationen zwischen Klassen kann man die Relation mit Kardinalitäten, Rollen und Assoziationsnamen spezifizieren. Die Richtung des Informationsflusses lässt sich darstellen, indem man gerichtete Assoziationen (also Pfeile) verwendet. Die Information fließt dann in Pfeilrichtung.
Akteur ───▷ System Informationsfluss Die Assoziationen zwischen Akteur und Use-Case können auch "unschärfer" dargestellt werden, indem das Verhalten des Systems als Ganzes betrachtet wird und auf eine Zuordnung zu einzelnen Use-Cases verzichtet wird. Insbesondere kann auf diese Weise sehr übersichtlich dargestellt werden, welche Informationen in ein System hineinfließen und welche hinausgelangen, und welche Aktoren diese Informationen mit dem System austauschen. Ein solches Diagramm heißt Kontextdiagramm.
Use-Case Hülle1 ----▷ Use-Case Recyc
«include»

Use-Case Hülle2 ----▷ Use-Case Recyc
«include»

Import Um Redundanz zu vermeiden, können Use-Cases einander inkludieren. Wenn ein Use-Case einen anderen Use-Case importiert, wird das in UML durch eine Abhängigkeits-Relation dargestellt, also ein Pfeil mit unterbrochener Linie. In UML weist der Pfeil nicht in Richtung der Inklusion, sondern stets vom Abhängigen ----▷ Unabhängigen. A ----▷ B bedeutet also: A enthält B (also ist A von B abhängig, denn jeder Ablauf von A beinhaltet auch einen Ablauf von B). Die Inklusion gibt keine zeitliche Reihenfolge vor und ist zwingend.
Use-Case Main ◁---- Use-Case Sonder
«extend»
Erweiterung Anders als die «include»-Beziehung ist die «extend»-Beziehung optional. Sie dient der Auslagerung von Sonderverhalten in Spezialfällen: Der Use-Case Main zeigt für sich schon ein vollständiges Verhalten, kann aber bei Bedarf um das Verhalten von Use-Case Sonder erweitert werden. Der Pfeil zeigt jetzt in die andere Richtung, d.h. von der Erweiterung zum Ganzen. Das spiegelt wieder die Abhängigkeitsrichtung wieder (das Ganze ist unabhängig, die Erweiterung aber braucht das Ganze).
Use-Case Allgemein ◁─── Use-Case Speziell Vererbung Auch Use-Cases können untereinander durch Generalisierungs-Assoziationen verbunden werden, um Vererbung zu realisieren. Der spezielle Use-Case kopiert und überschreibt dabei das Verhalten des allgemeinen Use-Case.