Übung »Aktivitätsdiagramm zu einem Use Case«

In dieser Übung wird ein Aktivitätsdiagramm erstellt, um Haupt-, Alternativ- und Ausnahmeszenario eines Use Cases in einem Diagramm zusammenzubringen.

Dauer

Ca. 180 min

Video(s) hierzu

Inhalt

• Worum geht es?
• Ihre Aufgabe
  • Use Case Header
  • Hauptszenario
  • Alternativszenario
  • Ausnahmeszenario
• Lösung
  • Aktivitätsdiagramm ohne Swimlanes, das Haupt-, Alternativ- und Ausnahmeszenario zusammenbringt
  • Aktivitätsdiagramm mit Swimlanes - Nutzersicht
  • Aktivitätsdiagramm mit Swimlanes - Systemsicht

Worum geht es?

Wir gehen auf unser altes Beispiel eines Konzertportals zurück. Es geht um den Use Case Konzertkarten kaufen.

In dem Webportal zur Online-Bestellung von Konzertkarten können Nutzer nach Konzerten suchen. Durch Anklicken eines Konzerts kann ein Nutzer Konzerttickets kaufen. Nach Eingabe seiner Zahlungsdaten an die externen Kreditinstitute weiter. Diese veranlassen die Auszahlung. Das System druckt dann die Tickets, kuvertiert sie, und verschickt sie an die vom Nutzer angegebene Adresse.

Ihre Aufgabe

1. Erstellen Sie ein Aktivitätsdiagramm, das alle drei Szenarien zusammenbringt.
2. Swimlanes bringen Struktur in ein Aktivitätsdiagramm. Schauen Sie noch einmal in das Video zu Swimlanes. Dort werden zwei grundsätzlich sinnvolle Sichten vorgestellt: Nutzersicht und Systemsicht.
   • Welche Swimlanes hätte ein Aktivitätsdiagramm in der Nutzersicht?
   • Welche Swimlanes könnten es in der Systemsicht sein?
3. Entscheiden Sie sich für eine Swimlane-Option und stellen Sie Ihr Aktivitätsdiagramm in Swimlanes dar.

Use Case Header

Feld	Inhalt
Name	Konzertkarten kaufen
Auslösender Aktor	Kunde
Weitere Aktoren	Sachbearbeiter, Kreditinstitut
Auslöser	Kunde möchte Konzert besuchen
Vorbedingung	Kunde ist als registrierter Kunde eingeloggt
Nachbedingung	Konzertkarten beim Kunden angekommen

Hauptszenario

Benutzer	System	Externes System
1) Kunde wählt Konzert aus
2) Kunde gibt Anzahl gewünschter Karten ein
	3) System prüft, ob die gewünschte Zahl Karten noch verfügbar ist; dies ist der Fall
	4) System meldet, dass Karten verfügbar sind, und stellt einen “Kaufen”-Button dar
5) Kunde klickt “Kaufen”-Button
	6) System lädt die hinterlegten Zahlungsdaten des Kunden
	7) System schickt Zahlungsdaten an externes Kreditinstitut
		8) Kreditinstitut veranlasst Auszahlung
	9) System meldet, dass der Kauf erfolgreich war
	10) System stellt einen Link zu einem “Print@Home”-PDF für die Karten dar
11) Kunde lädt das PDF herunter

Alternativszenario

Benutzer	System	Externes System
	3a) Es sind weniger Karten verfügbar, als der Kunde wünscht
	4a) Das System reduziert die Anzahl der Karten, und bietet für diese Zahl den “Kaufen”-Button an
	3b1) Kunde wünscht außergewöhnlich große Menge Karten; System druckt die Nachricht “Ein Sachbearbeiter wird sich bei Ihnen melden” und bricht den Vorgang erst einmal ab
3b2) Sachbearbeiter sieht in seinem Admin-UI die Meldung, dass er den Kunden anrufen soll, um den Fall zu klären
3b3) Sachbearbeiter telefoniert mit dem Kunden und klärt den Vorgang
3b4) Sachbearbeiter gibt im Admin-UI ein, dass der Kauf seine Richtigkeit hat
3b5) Kunde loggt sich erneut im System ein
	(weiter mit (4) aus dem Hauptszenario)

Ausnahmeszenario

Benutzer	System	Externes System
		8c) Kreditinstitut verweigert Auszahlung, weil Konto nicht genug Deckung hat
	9c) System meldet, dass der Kauf fehlgeschlagen ist
	Neue Nachbedingung: Karten nicht gekauft

Lösung

Aktivitätsdiagramm ohne Swimlanes, das Haupt-, Alternativ- und Ausnahmeszenario zusammenbringt

Aktivitätsdiagramm mit Swimlanes - Nutzersicht

In den Szenarien tauchen nur zwei Nutzer auf, deren jeweilige Aktivitäten dann auch die Swimlanes darstellen:

• Kunde
• Sachbearbeiter

Die Aktivitäten, die dem System oder externen Systemen zugeordnet werden (mittlere und rechte Spalte der Szenarien) sortiert man dann auch in die beiden Nutzerspalten ein - da, wo sie jeweils besser hinpassen. Wenn sie mehr mit dem Kunden zu tun haben, dann links - wenn mehr mit dem Sachbearbeiter, dann rechts.

Aktivitätsdiagramm mit Swimlanes - Systemsicht

Bei der Systemsicht braucht man mehr etwas mehr “Phantasie” und kann nicht mehr nur exakt nach dem Text gehen, weil in diesem noch keine expliziten Systembestandteile/Module erwähnt werden. Mit ein bisschen “gesundem Menschenverstand”, wie ein solches System aufgebaut sein müsste, haben wir uns in der Beispiel-Lösung für folgende Unterteilung entschieden:

• Kunden-UI (das Webportal, das nach außen sichtbar ist und mit dem die Kunden interagieren)
• Backend-System (wenn wir eine klassische Client-Server-Architektur annehmen)
• Admin-UI (ein internes UI, das nur Mitarbeiter/Sachbearbeiter nutzen)
• externes Kreditinstitut (bzw. dessen IT-Systeme, die wir nicht im Einzelnen kennen)

Dann ergibt sich das nachfolgende Bild.