3. Vorlesung: UML Use Case Diagramme Einführung Grundelemente Beispiel Beschreibung von Use Cases Beziehungen zwischen Use Cases Übersicht über Konstrukte in Use Case Diagrammen Wie findet man Use Cases? Kriterien für Use Cases Hans-Jürgen Steffens Systemanalyse SS 04

UML Use Case-Diagramme Erster Schritt bei der Anforderungsanalyse: Use Case-Diagramme und -Beschreibungen Use Cases (Anwendungsfälle) beschreiben Systemfunktionalität aus Anwendersicht Beantworten die Frage „Wer macht was mit dem System?“ Hans-Jürgen Steffens Systemanalyse SS 04

Beispiel für UML Use Case Diagramm Actor Communicates- Beziehung Use Case Systemgrenze Hans-Jürgen Steffens Systemanalyse SS 04

Elemente von Use Case-Diagrammen (1) Actor (Akteur) Ist eine Rolle, die ein Benutzer des Systems spielt. Ist häufig eine Person, kann aber auch eine Organisationseinheit oder ein externes System sein. Use Case (Anwendungsfall) Beschreibt die Durchführung einer konkreten Aufgabe mit dem System aus Anwendersicht. Kann aus mehreren Einzelaktivitäten bestehen, die von einem Akteur durchgeführt werden, um ein bestimmtes Ergebnis zu erreichen. System Systemgrenzen können eingezeichnet werden Communicates-Beziehung zwischen Actor und Use Case Der Actor kommuniziert mit dem Use Case (z. B. er führt ihn durch, muss Eingaben machen o. ä.) Hans-Jürgen Steffens Systemanalyse SS 04

Notation für Use Case Diagramme System Use Case 1 Use Case 3 Actor 2 Actor 1 Use Case 2 Hans-Jürgen Steffens Systemanalyse SS 04

Beschreibung von Use Cases Die Use Case-Diagramme alleine reichen nicht aus, um die Systemfunktionalität aus Anwendersicht ausreichend zu beschreiben Daher ist zu jedem Use Case eine textuelle Beschreibung erforderlich Hans-Jürgen Steffens Systemanalyse SS 04

Muster für die Beschreibung von Use Cases Name des Use Case (z. B. Substantiv + Verb) Vorbedingung Nachbedingung im Erfolgsfall Nachbedingung im Falle eines Fehlschlags Akteure Auslösendes Ereignis Beschreibung 1 Aktion 1 2 Aktion 2, ... Erweiterungen 1a Erweiterung Funktionsumfang Aktion 1 Alternativen 1A Alternative zur Ausführung Aktion 1 1B Weitere Alternative zur Ausführung Aktion 1 Quelle: Balzert, H.: Lehrbuch der Softwaretechnik Hans-Jürgen Steffens Systemanalyse SS 04

Beispiel: Use Case Einzelkarte kaufen Name des Use Case: Einzelkarte kaufen Vorbedingung: Keine Nachbedingung (Erfolg): Fahrkarte ausgestellt Nachbedingung Fahrkarte wurde nicht ausgestellt, (Fehlschlag): Geld zurück gegeben Akteure: Fahrgast Auslösendes Ereignis: Fahrgast will Fahrkarte kaufen Beschreibung: Fahrgast wählt Fahrkartentyp Fahrgast wählt Fahrziel System ermittelt mögliche Verbindungen Fahrgast wählt gewünschte Verbindung aus System ermittelt Preis Fahrgast wirft Geld ein System gibt Wechselgeld und druckt Ticket aus Hans-Jürgen Steffens Systemanalyse SS 04

Fortsetzung: Use Case Einzelkarte kaufen Erweiterungen: 3a. Fahrgast lässt Verbindungsübersicht ausdrucken Alternativen: 1A.-5A.: Fahrgast bricht Aktion ab, System geht nach Wartezeit in Ausgangszustand zurück 6A.: Fahrgast wirft nicht genug Geld ein, System gibt nach Wartezeit Geld zurück und geht in Ausgangszustand 6B.: Automat hat nicht mehr genug Wechselgeld, es muss passend gezahlt werden. Wenn nicht passend gezahlt wird, wird das Geld zurück gegeben und der Fahrgast erhält die Möglichkeit zum erneuten Geldeinwurf. Hans-Jürgen Steffens Systemanalyse SS 04

Beispiel: Use Case Monatskarte kaufen Name des Use Case: Monatskarte kaufen Vorbedingung: Keine Nachbedingung (Erfolg): Monatskarte ausgestellt Nachbedingung Monatskarte wurde nicht ausgestellt, (Fehlschlag): Geld zurück gegeben Akteure: Fahrgast Auslösendes Ereignis: Fahrgast will Monatskarte kaufen Beschreibung: Fahrgast wählt Monatskartentyp Fahrgast wählt Fahrziel System ermittelt mögliche Verbindungen Fahrgast wählt gewünschte Verbindung aus System ermittelt Preis Fahrgast wirft Geld ein System gibt Wechselgeld und druckt Monatskarte aus Hans-Jürgen Steffens Systemanalyse SS 04

Fortsetzung: Use Case Monatskarte kaufen Erweiterungen: 3a. Fahrgast lässt Verbindungsübersicht ausdrucken Alternativen: 1A.-5A.: Fahrgast bricht Aktion ab, System geht nach Wartezeit in Ausgangszustand zurück 6A.: Fahrgast wirft nicht genug Geld ein, System gibt nach Wartezeit Geld zurück und geht in Ausgangszustand 6B.: Automat hat nicht mehr genug Wechselgeld, es muss passend gezahlt werden. Wenn nicht passend gezahlt wird, wird das Geld zurück gegeben und der Fahrgast erhält die Möglichkeit zum erneuten Geldeinwurf. Hans-Jürgen Steffens Systemanalyse SS 04

Vergleich der Use Cases Beide Use Cases haben gemeinsame Aktivitäten: Verbindungen ermitteln Geldeinwurf und Fahrkartenausgabe Hierfür können eigene Use Cases gebildet und über die include-Beziehung eingebunden werden Kriterien für Bildung eigener Use Cases: Umfassen selbst einen abgeschlossenen Ablauf Werden mehrfach benötigt (oder sie könnten in Zukunft mehrfach verwendet werden) Hans-Jürgen Steffens Systemanalyse SS 04

Include-Beziehung im Beispiel Einzelkarte kaufen «include» «include» Verbindungen Geldeinwurf und ermitteln Fahrkartenausgabe «include» «include» Monatskarte kaufen Use Case „Monatskarte kaufen“ schließt Use Case „Geldeinwurf und Fahrkartenausgabe“ mit ein Hans-Jürgen Steffens Systemanalyse SS 04

Erweiterungen von Use Cases Sonderfälle können mit Hilfe von eigenen Use Cases dargestellt werden, die über extend-Beziehungen eingebunden werden Im Beispiel: Ausdruck von Verbindungen Hans-Jürgen Steffens Systemanalyse SS 04

Extend-Beziehung im Beispiel Use Case „Verbindung ausdrucken“ erweitert Use Case „Verbindungen ermitteln“ «extend» Fahrgast wünscht Ausdruck Verbindungen ermitteln Verbindung ______________________ ausdrucken Nach „Verbindungen anzeigen“ Bedingung für Erweiterung (optional) Extension Point (optional): An welcher Stelle wird Erweiterung durchgeführt? Hans-Jürgen Steffens Systemanalyse SS 04

Generalisierung von Use Cases Use Cases, die viele Gemeinsamkeiten haben, können verallgemeinert werden Beispielsweise könnte für die Use Cases Einzelkarte kaufen und Monatskarte kaufen ein allgemeiner Use Case Fahrkarte kaufen definiert werden. In den speziellen Use Cases braucht dann nur noch beschrieben werden, wie sich diese vom allgemeinen Fall unterscheiden Hans-Jürgen Steffens Systemanalyse SS 04

Generalisierung im Beispiel Hans-Jürgen Steffens Systemanalyse SS 04

Übersicht Konstrukte im Use Case-Diagramm System Use Case Actor Use Case Use Case «include» «extend» Use Case Bedingung ________ Use Case Extension Point Hans-Jürgen Steffens Systemanalyse SS 04

Wie findet man Use Cases? (1) Akteure ermitteln Wer führt die Aufgaben heute / künftig durch? Welche Rollen gibt es? Was gehört zum System / nicht zum System? Use Cases für den Standardfall ermitteln Mittels Akteuren: Welche Aufgaben führen Sie durch? An welchen Aufgaben wirken sie mit? Mittels Ereignissen: Erstellen einer Ereignisliste Welche Aktivitäten lösen diese aus? Für jedes Ereignis Use Case ermitteln. Mittels Aufgabenbeschreibungen: Was sind die Gesamtziele des Systems? Welches sind die zehn wichtigsten Aufgaben? Was ist das Ziel jeder Aufgabe? Hans-Jürgen Steffens Systemanalyse SS 04

Wie findet man Use Cases? (2) Use Cases für Sonderfälle ermitteln Erweiterungen und Alternativen in Use Case-Beschreibungen definieren Aufbauend auf Standardfälle die Sonderfälle formulieren und mit extend einbinden Aufteilen komplexer Use Cases Komplexe Schritte als eigene Use Cases definieren und über include einbinden Komplexe Use Cases mit vielen Sonderfällen in mehrere Use Cases zerlegen und Gemeinsamkeiten mit include modellieren Gemeinsamkeiten von Use Cases ermitteln Gemeinsame Teilabläufe in eigenen Use Cases darstellen und über include einbinden Mehr Gemeinsamkeiten als Unterschiede Ggf. Generalisierung nutzen Hans-Jürgen Steffens Systemanalyse SS 04

Kriterien für Use Cases Gute Use Cases: Verständlich für Auftraggeber Extern wahrnehmbares Verhalten Fachliche Beschreibung des Arbeitsablaufs Trennung von Standard- und Sonderfällen Beschreibung max. 1 Seite pro Use Case Häufige Fehler: Zu kleine und damit zu viele Use Cases Zu frühe Betrachtung von Sonderfällen Zu detaillierte Beschreibung Verwechseln von include und extend Es wird versucht, im Use Case-Diagramm eine Ablaufreihenfolge zu modellieren Hans-Jürgen Steffens Systemanalyse SS 04

Zusammenfassung Die Beschreibung der Systemfunktionalität aus Anwendersicht in Form von Use Cases (Anwendungsfälle) stellt den ersten Schritt der Anforderungsanalyse dar. Zentrale Elemente von UML Use Case Diagrammen sind die Use Cases sowie die sie ausführenden Actors (Akteure) Use Cases werden mit ihren einzelnen Ablaufschritten textuell beschrieben Beziehungstypen zwischen Use Cases sind include (ein Use Case umfasst einen anderen), extend (ein Use Case erweitert das Verhalten eines anderen) und Generalisierung (ein Use Case ist die Verallgemeinerung mehrerer anderer) Use Cases lassen sich über Akteure, Ereignisse und Aufgabenbeschreibungen identifizieren, anschließend sind Sonderfälle, komplexe Teilschritte und Gemeinsamkeiten zu modellieren. Hans-Jürgen Steffens Systemanalyse SS 04

Übungsfragen Was ist ein Use Case? Nennen Sie Beispiele aus unterschiedlichen Anwendungsbereichen. Was ist der Zweck von UML Use Case-Diagrammen? Welche Konstrukte umfassen UML Use Case Diagramme? Wie kann man Use Cases beschreiben? Nennen und erläutern Sie die verschiedenen Arten von Beziehungen zwischen Use Cases. Wie findet man Use Cases? Woran erkennt man gute bzw. schlechte Use Case-Diagramme und –Beschreibungen? Hans-Jürgen Steffens Systemanalyse SS 04