Meistern des use-case-getriebenen Ansatzes: Ein umfassender Leitfaden für Anforderungen und Entwurf

Einführung

In der Softwareentwicklung ist die Überbrückung der Lücke zwischen den Bedürfnissen der Beteiligten und der technischen Umsetzung oft die herausforderndste Phase der Entwicklung. Der use-case-getriebenen Ansatz bietet eine strukturierte, iterative Methodik zur Lösung dieses Problems. Durch den Fokus auf wie Benutzer mit dem System interagierenum spezifische Ziele zu erreichen, stellt dieser Ansatz sicher, dass Anforderungen klar, testbar und direkt auf Entwurfsmaterialien zurückverfolgbar sind.

Dieser Leitfaden bietet einen vollständigen Überblick über den use-case-getriebenen Ansatz, der von hochleveligen Anforderungen bis zum detaillierten Entwurf führt. Wir verwenden ein durchgängiges Beispiel – ein Online-Bestellverwaltungssystem – um jeden Schritt zu veranschaulichen und dabei durchgängige Konsistenz und Klarheit im gesamten Prozess zu gewährleisten.

---

Überblick über die Methodik

Der use-case-getriebene Ansatz folgt einer natürlichen Top-Down-Progression. Jede Stufe verfeinert die vorherige, fügt Präzision hinzu und reduziert Mehrdeutigkeiten.

Warum diese Reihenfolge wichtig ist?

1. Use-Case-Diagramm: Liefert eine vollständige Inventarisierung von Fähigkeiten und Umfang. Es ist schnell erfassbar und ideal für die Einigung der Beteiligten auf was das System tut.
2. Use-Case-Beschreibung: Beseitigt Mehrdeutigkeiten, indem Vorbedingungen, Nachbedingungen, Akteure und Prioritäten festgelegt werden. Es „friert” den Verhaltensvertrag ein.”
3. Ereignisablauf: Wandelt den Vertrag in konkrete, testbare Schritte um. Dies dient als Rohmaterial sowohl für Testfälle als auch für den technischen Entwurf.
4. Aktivität/Sequenzdiagramm: Dient als Brücke zum Code. Es identifiziert beteiligte Objekte, ihre Verantwortlichkeiten, Nachrichtenaustausche und exakte Verzweigungsregeln.

---

Schritt 1: Use-Case-Diagramm (Anforderungen)

Das Use-Case-Diagramm erfasst wer mit dem System interagiert (Akteure) und was sie tun können (Use Cases) sowie die Beziehungen zwischen ihnen.

Schlüsselkonzepte

• Primärer Akteur: Löst den Use Case aus (links platziert).
• Sekundärer Akteur: Unterstützt das System oder erhält Benachrichtigungen (rechts platziert).
• Systemgrenze: Das Rechteck, das den Umfang des Systems definiert.
• <<include>>: Stellt obligatorisches gemeinsames Verhalten dar. Wenn Use Case A Use Case B einschließt, muss B erfolgen stattfinden, damit A abgeschlossen werden kann.
• <<extend>>: Stellt optionales Verhalten dar. Use Case B erweitert Use Case A nur unter bestimmten Bedingungen.

Beispiel: Online-Bestellverwaltungssystem

@startuml
skinparam linetype ortho
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam vpDiagramType UseCaseDiagram
skinparam actor {
  BackgroundColor #E8F5E9
}
skinparam usecase {
  BackgroundColor #BBDEFB
  BorderColor #1976D2
  ArrowColor #1976D2
}

left to right direction
actor "Kunden(Primär)" as cust
actor "Lagern(Sekundär)" as wh

rectangle "Bestellverwaltungssystem" {
  usecase "Bestellung aufgeben" as UC1
  usecase "Bestellung stornieren" as UC2
  usecase "Bestellung verfolgen" as UC3
  usecase "Anmelden" as UC4
  usecase "Rechnung drucken" as UC5
}

cust -[#black]- UC1
cust -[#black]- UC2
cust -[#black]- UC3
UC1 -[#crimson]- wh
UC2 -[#crimson]- wh
UC1 ...> UC4 : <<include>>
UC2 ...> UC4 : <<include>>
UC3 ...> UC4 : <<include>>
UC1 <... UC5 : <<extend>>
@enduml

Analyse des Diagramms:

• Das Kunde leitet das Aufgeben, Stornieren und Verfolgen von Bestellungen ein.
• Das Lager ist am Aufgeben und Stornieren von Bestellungen beteiligt (wahrscheinlich für Lagerbestandsaktualisierungen).
• Anmeldung ist in Aufgeben, Stornieren und Verfolgen von Bestellungen enthalten, was bedeutet, dass eine Authentifizierung für diese Aktionen obligatorisch ist.
• Rechnung ausdrucken erweitert Aufgeben einer Bestellung, was bedeutet, dass es ein optionaler Schritt ist, der nach dem Aufgeben einer Bestellung erfolgen kann.

---

Stufe 2: Beschreibung des Anwendungsfalls (Spezifikation)

Ein Diagramm benennt die Anwendungsfälle, enthält jedoch keine Details. Die Tabelle zur Beschreibung des Anwendungsfallslegt den genauen Vertrag für jeden Anwendungsfall fest.

Beispiel: UC-01 Bestellung aufgeben

Feld	Wert
Anwendungsfall-ID	UC-01
Name	Bestellung aufgeben
Hauptakteur	Kunde
Nebenakteur	Lager
Vorbedingungen	Kunde ist angemeldet; Warenkorb enthält mindestens einen Artikel; Artikel sind vorrätig
Nachbedingungen (Erfolg)	Bestellung wird mit Status bestätigt; Zahlung wird eingezogen; Sendungsverfolgungsnummer wird ausgestellt
Nachbedingungen (Fehler)	Keine Bestellung erstellt; Warenkorb unverändert; Benutzer über den Grund informiert
Hauptablauf	→ Siehe Stufe 3
Alternative / Ausnahmeflüsse	Unzureichender Lagerbestand; Zahlung abgelehnt
Priorität	Hoch

Zweck: Diese Stufe definiert, was wahr sein muss vor der Anwendungsfall ausgeführt wird (Voraussetzungen) und was gelten muss nach (Nachbedingungen), wodurch klare Kriterien für Erfolg/Fehler festgelegt werden.

---

Stufe 3: Ereignisablauf (Szenarien)

Dies ist das verhaltensbezogene Herzstück des Ansatzes. Der Anwendungsfall „Bestellung aufgeben“ erweitert sich zu einem Szenarioskript—eine nummerierte Abfolge von Schritten, die vor der Erstellung detaillierter Design-Diagramme verfasst wird.

Hauptszenario für Erfolg (Grundablauf)

1. Der Kunde meldet sich an.
2. Der Kunde übermittelt den Warenkorb mit den ausgewählten Artikeln.
3. Das System validiert den Warenkorbinhalt und die Lagerverfügbarkeit.
4. Das System belastet den Gesamtbetrag über das Zahlungsportal.
5. Das System speichert die Bestellung mit dem Status bestätigt.
6. Das System gibt eine Bestellbestätigung mit einer Bestell-ID zurück.
7. Das System benachrichtigt das Lager, um zu kommissionieren, zu verpacken und zu versenden.

Alternative Szenarien

• 3a. Unzureichender Lagerbestand: Das System meldet die nicht verfügbaren Artikel und kehrt zum Warenkorb zurück.
• 4a. Zahlung abgelehnt: Das System informiert den Kunden und erstellt keine Bestellung.

Wichtige Konvention: Jedes Szenario wird direkt einem Schritt in der Beschreibung zugeordnet. Diese Abläufe bilden die Grundlage für die Aktivitäts- und Sequenzdiagramme in der nächsten Phase.

---

Phase 4: Detaillierte Gestaltung (Sequenz- und Aktivitätsdiagramme)

In dieser Phase wählen Sie die Notation basierend auf dem Aspekt des Systems, den Sie betonen möchten.

• Sequenzdiagramm:BetontLebenslinien, Nachrichtenreihenfolge und Verantwortlichkeiten zwischen Objekten. Ideal zur Entdeckung von Klassen und Methoden.
• Aktivitätsdiagramm:BetontSteuerungsfluss und Entscheidungen durch Bahnen/Parteien. Ideal zur Dokumentation von Prozessen und Rollenverantwortlichkeiten.

4A.Sequenzdiagramm (Interaktionsperspektive)

@startuml
title Sequenzdiagramm Bestellung aufgeben
skinparam linetype ortho
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam sequenceParticipant underline
skinparam vpDiagramType InteractionDiagram
skinparam {
  FontSize 14
  ArrowColor #4A4A4A
  ArrowFontColor #4A4A4A
  BackgroundColor #FFFFFF
  BorderColor #DEDEDE
  FontColor #333333
  Participant {
    BorderColor #0077B6
    BackgroundColor #F0F8FF
    FontColor #005691
  }
  Actor {
    BorderColor #6A057F
    BackgroundColor #F5EEF8
    FontColor #510363
  }
  Sequence {
    ArrowThickness 2
    LifeLineBorderColor #444444
    LifeLineBackgroundColor #F7F7F7
    BoxBorderColor #AAAAAA
    BoxBackgroundColor #FFFFFF
    BoxFontColor #333333
  }
}

actor "Kunde" as USR
participant "Bestelldienst" as OS
participant "Zahlungs-Gateway" as PG
database "Bestell-Datenbank" as DB

activate USR
USR -> OS : submitOrder(items)
activate OS
alt Validierung & Zahlung
  OS -> OS : validateCart(items)
  OS -> PG : charge(total)
  activate PG
  PG --> OS : paymentOk
  deactivate PG
  OS -> DB : saveOrder(status=confirmed)
  activate DB
  DB --> OS : orderId
  deactivate DB
  OS --> USR : orderConfirmation(orderId)
else Unzureichender Lagerbestand
  OS -> DB : checkStock(items)
  activate DB
  DB --> OS : stockUnavailable
  deactivate DB
  OS --> USR : error("Nicht auf Lager")
else Zahlung fehlgeschlagen
  PG --> OS : paymentFailed
  OS --> USR : error("Zahlung abgelehnt")
end
deactivate OS
@enduml

Wichtige Konzepte:

• Synchronaufrufe: Feste Pfeile (->).
• Antworten: Gestrichelte Pfeile (-->).
• Aktivierungsleisten: Zeigen Sie die Lebensdauer der Verarbeitung eines Objekts an.
• alt Kombiniertes Fragment: Umschließt die drei Szenarien (Erfolg, unzureichender Lagerbestand, Zahlungsfehler) und spiegelt direkt den Ereignisfluss aus Stufe 3 wider.

4B. Aktivitätsdiagramm (Prozessperspektive)

@startuml
<style>
  element { MaximumWidth 150 }
  start   { Backgroundcolor #00695C }
  stop    { Backgroundcolor #C2185B }
  activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
  diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
  arrow   { LineColor #424242; Fontcolor #000000 }
  swimlane{ Fontcolor #000000; FontSize 14 }
</style>
title Aktivitätsdiagramm für Bestellung aufgeben

|#F0F8FF|Kunde|
start
:Anmelden;
:Katalog durchsuchen;
:Artikel in den Warenkorb legen;

if (Bereit zur Kasse?) then (ja)
  :Zur Kasse gehen;
else (nein)
  :Zurück zum Stöbern;
  stop
endif

|#E8F5E9|System|
:Warenkorb validieren;
:Zahlung verarbeiten;

if (Zahlung genehmigt?) then (ja)
  :Bestellung erstellen (status=bestätigt);
else (nein)
  :Zahlungsfehler melden;
endif

|#F5EEF8|Lager|
if (Zahlung genehmigt?) then (ja)
  :Artikel kommissionieren und verpacken;
  :Bestellung versenden;
  :Sendungsverfolgungsnummer senden;
  stop
else (nein)
  stop
endif
@enduml

Wichtige Konzepte:

• Schwimmbahnen: Weisen Sie jede Aktion der verantwortlichen Partei zu (Kunde, System, Lager).
• Entscheidungsknoten: if/dann/sonst/endif Strukturen kodieren Verzweigungsszenarien.
• Start-/Stop-Markierungen: Begrenzen Sie den Beginn und das Ende des Prozesses.

---

Wichtige PlantUML-Erkenntnisse

Um diesen Ansatz mit PlantUML effektiv zu modellieren, beachten Sie die folgenden Syntax-Grundlagen:

1. Anwendungsfalldiagramme:
   • Verwenden Sie usecase für Funktionen.
   • Verwenden Sie ...> für <<include>> Beziehungen.
   • Verwenden Sie <... für <<extend>> Beziehungen.
   • Verwenden Sie rectangle "Systemname" {} um die Systemgrenze zu definieren.
2. Sequenzdiagramme:
   • Definieren Sie Teilnehmer mit actor, participant, oder database.
   • Verwenden Sie -> für synchrone Aufrufe und --> für Antworten.
   • Verwenden Sie activate und deactivate um Lebensdauern von Objekten anzuzeigen.
   • Verwenden Sie alt, sonst, und ende für kombinierte Fragmente, die alternative Abläufe darstellen.
3. Aktivitätsdiagramme:
   • Verwenden Sie |#color|Spaltenname| zum Definieren von Schwimmbahnen.
   • Verwenden Sie :aktion; für Aktivitäten.
   • Verwenden Sie if/sonst/endif für Entscheidungsknoten.
   • Verwenden Sie start und stopp zum Markieren von Prozessgrenzen.

---

Fazit

Der use-case-getriebene Ansatz ist mehr als nur eine Dokumentationsmethode; es ist ein Rahmenwerk für schrittweise Verfeinerung. Indem man mit dem großen Überblick (Use-Case-Diagramm) und in spezifisches Verhalten (Ereignisablauf) sowie technische Interaktionen (Sequenz/Aktivitätsdiagramme) können Teams sicherstellen, dass jede Codezeile auf einen verifizierten Benutzerbedarf zurückgeführt werden kann.

Diese Methode reduziert das Risiko von Missverständnissen zwischen Stakeholdern und Entwicklern, erleichtert das Testen durch klare Szenarien und führt zu einem robusten, benutzerzentrierten Systemdesign. Ob Sie eine einfache E-Commerce-Plattform oder ein komplexes Unternehmenssystem entwickeln, die Einhaltung dieser strukturierten Vorgehensweise führt zu klareren Anforderungen und Software höherer Qualität.