Hans-Jürgen Steffens Systemanalyse SS 041 3. Vorlesung: UML Use Case Diagramme Einführung...

Hans-Jürgen Steffens Systemanalyse SS 04 1

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


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?“


Beispiel für UML Use Case Diagramm

Fahrkartenautomat

Fahrgast

Einzelkarte kaufen

Monatskarte kaufen

Formulare auffüllen

Einnahmen abrechnenAutomaten-Betreuer

Actor

Use Case

Systemgrenze

Communicates-Beziehung


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. ä.)


Notation für Use Case Diagramme

Use Case 1

Use Case 2

Use Case 3

System

Actor 1

Actor 2


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


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


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:

1. Fahrgast wählt Fahrkartentyp2. Fahrgast wählt Fahrziel3. System ermittelt mögliche Verbindungen4. Fahrgast wählt gewünschte Verbindung aus5. System ermittelt Preis6. Fahrgast wirft Geld ein7. System gibt Wechselgeld und druckt Ticket aus


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.


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:

1. Fahrgast wählt Monatskartentyp2. Fahrgast wählt Fahrziel3. System ermittelt mögliche Verbindungen4. Fahrgast wählt gewünschte Verbindung aus5. System ermittelt Preis6. Fahrgast wirft Geld ein7. System gibt Wechselgeld und druckt Monatskarte aus


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.


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)


Einzelkarte kaufen

Monatskarte kaufen

Verbindungenermitteln

Geldeinwurf undFahrkartenausgabe

«include»

«include» «include»

«include»

Include-Beziehung im Beispiel

Use Case „Monatskarte kaufen“schließt Use Case „Geldeinwurf undFahrkartenausgabe“ mit ein


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


Verbindungenermitteln

______________________Nach „Verbindungen

anzeigen“

Verbindungausdrucken

«extend»

Extend-Beziehung im Beispiel

Fahrgast wünschtAusdruck

Use Case„Verbindung ausdrucken“erweitert Use Case„Verbindungen ermitteln“

Bedingung fürErweiterung(optional)Extension Point

(optional): Anwelcher Stelle wirdErweiterung durchgeführt?


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


Generalisierung im Beispiel

Einzelkarte kaufen Monatskarte kaufen

Fahrkarte kaufen


Übersicht Konstrukte im Use Case-Diagramm

System

Actor

Use Case

Use Case Use Case

Use Case________

Extension Point

«include»

Use Case

«extend»Bedingung


Wie findet man Use Cases? (1)

1. Akteure ermitteln Wer führt die Aufgaben heute / künftig durch? Welche Rollen gibt es? Was gehört zum System / nicht zum System?

2. Use Cases für den Standardfall ermitteln

a) Mittels Akteuren:– Welche Aufgaben führen Sie durch? – An welchen Aufgaben wirken sie mit?

b) Mittels Ereignissen:– Erstellen einer Ereignisliste– Welche Aktivitäten lösen diese aus?

Für jedes Ereignis Use Case ermitteln.

c) Mittels Aufgabenbeschreibungen:– Was sind die Gesamtziele des Systems?– Welches sind die zehn wichtigsten Aufgaben?– Was ist das Ziel jeder Aufgabe?


Wie findet man Use Cases? (2)

3. 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

4. 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

5. Gemeinsamkeiten von Use Cases ermitteln

• Gemeinsame Teilabläufe in eigenen Use Cases darstellen und über include einbinden

• Mehr Gemeinsamkeiten als Unterschiede Ggf. Generalisierung nutzen


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


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.


Ü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 041 3. Vorlesung: UML Use Case Diagramme Einführung...

Documents

Transcript of Hans-Jürgen Steffens Systemanalyse SS 041 3. Vorlesung: UML Use Case Diagramme Einführung...