• wird auch Anwendungsfalldiagramm genannt
  • zeigt funktionale Anforderung an das Gesamtsystem (Nutzerinteraktionen)
  • Darstellung der Akteure eines Systems
  • zeigt Aktionen von System und Nutzer (Mensch/anderes System)
  • stellt Erfolge und Misserfolge dar
  • Aufgaben: Visualisierung, Spezifizierung und Dokumentation
  • Basis für die Verständigung von Entwicklern, Endanwendern und Fachleuten für den Anwendungsbereich
  • Für die Requirements, für die Überprüfung der Architektur, und für den Test genutzt
  • Werden von allen Stakeholdern definiert
  • Zeigt keine Implementierung
  • Use Cases sind keine vollständige Anforderungsanalyse, nur ein Bestandteil davon.

1. Anwendungsfälle analysieren

  • Beginn mit Sunny-Day-Szenario
  • Was will der Aktor (aus Vogelperspektive gesehen)?
    • Verschiedene Use Cases bei versch. Aktoren
  • Wer/Wo/Wann/Was Fragen stellen
  • Welche Infos werden ausgetauscht?
  • Welche Unregelmäßigkeiten können auftreten?
  • keine internen Abläufe aufführen, nur aus Sicht des Kunden

2. Textkarten erstellen

Alle Anwendungsfälle werden in Tabellenform aufgeschrieben:

Use Case

ein Vorgang im System

Use Cases

verbundene Anwendungsfälle

(Bezeichnung mit Subjekt + Verb; konkret formulieren)

System

enthält gesamte Software

Systemname in Kasten darstellen

Akteur

    • Systeme/Personen, welche mit System interagieren
    • Löst Use Case aus

Primary Actor

Auslöser von Case (Kunde etc.)

Further Actors

spätere Akteure (Kundenbearbeiter etc.)

Trigger

    • erste Aktion
    • startet durch Nutzer, Zeit oder Fehler

Success Guarantees

Ziel der Aktion (laut Titel)

4. Diagramm erstellen

Ziel: Die versch. Anwendungsfälle in einem oder mehreren Diagrammen übersichtlich modellieren.

Diagrammelemente

System

UML-System-300x300 Use Case Diagramm erstellen - Schritt für SchrittDer Systemkontext wird durch Systemgrenzen in Form von Rechtecken gekennzeichnet. Mehrere Subsysteme sind in einem Diagramm darstellbar. Oben wird im Rechteck der Name des Systems eingetragen.

Actor

Actor Use Case Diagramm erstellen - Schritt für SchrittKann eine Person oder ein anderes System sein, welches interagiert. Darstellung als Strichmännchen mit Namen darunter. Steht überlicherweise außerhalb des Systems.

Use Case

UML-Use-Case Use Case Diagramm erstellen - Schritt für SchrittNamen der einzelnen Anwendungsfälle, die einem oder mehreren Actors zugeordnet werden. Darstellung in Ellypsen, mit Kanten verbunden.

Kanten

UML-Kante-300x155 Use Case Diagramm erstellen - Schritt für Schritt

Verbinden einen oder mehrere Actors mit Use-Cases. Erster Pfeil zeigt zu Hauptaktion (ohne Pfeil), restliches kann dann „included“ werden (wenn aufeinander aufbauend, Pfeilrichtung beachten).

Beziehungen

include-Beziehung

UML-include Use Case Diagramm erstellen - Schritt für Schritt

  • Importiert vorgesehenen Use Case in einen anderen (wird normalerweise genutzt)
  • Nutzung bei selbem Verhalten von mehreren Use Cases
  • Notation mit gestrichteltem Pfeil und Bezeichnung <<include>>
extend-BeziehungUML-extend Use Case Diagramm erstellen - Schritt für Schritt
  • Erweiterung von Use Case um einen weiteren (unabhängig)
  • enthält z. B. return-Point (kann auch Abbruch sein)
  • Notation mit gestrichteltem Pfeil und Bezeichnung <<extend>>
GeneralisierungUML-generalisierung Use Case Diagramm erstellen - Schritt für Schritt
  • Zeigt von Spezialisierung auf allgemeinen Anwendungsfall/Actor
  • Darstellung mit Pfeil

Aufbau von Abzweigungen

  1. Trigger (Bedingung für Aufruf von Course)
  2. Alternative Course (Ablaufschritte)
    1. sog. Action-Steps (Aktionen von System/Nutzer)
  3. Rückkehr/Abbruch/Ausgabe

Beispiel

OOST-UseCase-Übung-Post-Page-1-800x481 Use Case Diagramm erstellen - Schritt für Schritt

Begriffe erklärt

Succcess Guarantees/Use Case-Business-Result/Main Success Scenario

Alle Bedingungen, die im Erfolgsfall erfüllt sein müssen

Minimal Guarantees

Bedingungen die immer erfüllt sein müssen (z. B. Pflichtfelder oder Abbruch, Meldung anzeigen, Karte ausgeben, Protokollierung…)

Alternative Course

Abzweigung (z.B. bei Fehlern)
Werden als vollständige Use Cases beschrieben.

Praxistipps

  • Erst Textkarten erstellen
  • Beginn mit dem Sunny Day Scenario
  • aktive Formulierungen (Subjekt, Prädikat, Objekt) nutzen
  • exakte, kurze Formulierung (kein sollte/müsste)
  • von außen gucken
  • kein Userinferface beschreiben, nur die Ziele fokussieren
  • lieber wenig Schritte, notfalls zusammenfassen (max. 9 Schritte, danach Auslagern/Zusammenfassen)

Dein Kommentar