Eine Gebrauchsfallbeschreibung erläutert, wie ein Akteur durch Interaktion mit einem System ein Ziel erreicht. Sie ergänzt ein Gebrauchsfalldiagramm:

• Gebrauchsfalldiagramm:Zeigt Akteure, Systemumfang und Beziehungen.

• Gebrauchsfallbeschreibung:Erklärt das detaillierte Verhalten, Bedingungen, Regeln und Ergebnisse.

Ein Diagramm liefert die Karte; die Beschreibung liefert die Route.

1. Was ist ein Gebrauchsfall?

Ein Gebrauchsfall stellt ein wertvolles Ziel dar, das ein externer Akteur durch ein System erreicht.

Beispiele:

• Kunde gibt eine Bestellung auf

• Mitarbeiter reicht eine Kostenabrechnung ein

• Patient vereinbart einen Termin

• Administrator erstellt ein Benutzerkonto

• Kunde setzt ein Passwort zurück

Ein guter Gebrauchsfall ist:

• Zielorientiert

• Wertvoll für einen Akteur

• Aus der Sicht des Benutzers beschrieben

• Unabhängig von spezifischen Bildschirmlayouts

• Fokussiert auf beobachtbares Systemverhalten

Schlechte und verbesserte Gebrauchsfallnamen

Verwenden Sie eine kurze Verb-Nomen-Phrase wie “Rechnung einreichen, Versand verfolgen, oder Kreditantrag genehmigen.

2. Schlüsselkonzepte

2.1 Akteure

Ein Akteur ist eine externe Rolle, die mit dem System interagiert.

Ein Akteur kann sein:

• Eine Person

• Eine Organisation

• Ein anderes Softwaresystem

• Ein Hardwaregerät

• Ein geplanter oder zeitbasierter Auslöser

Beispiele:

• Kunde

• Support-Mitarbeiter

• Lagerist

• Zahlungs-Gateway

• E-Mail-Dienst

• Administrator

Ein Akteur ist ein Rolle, nicht unbedingt eine bestimmte Person. Zum Beispiel ist „Kunde“ in der Regel besser als „Jane Smith“.

Hauptakteure und unterstützende Akteure

Der Hauptakteurleitet den Anwendungsfall ein, um ein Ziel zu erreichen.

Der unterstützende Akteurunterstützt das System während der Ausführung.

Beispiel:

• Hauptakteur: Kunde

• Unterstützender Akteur: Zahlungs-Gateway

• Anwendungsfall: Bestellung aufgeben

Der Kunde löst die Bestellung aus, während das Zahlungs-Gateway die Zahlung autorisiert.

2.2 Systemgrenze

Die Systemgrenze definiert, was sich innerhalb des zu modellierenden Systems befindet.

Für einen Online-Shop könnte die Grenze Folgendes enthalten:

• Produkte durchsuchen

• Produkt zum Warenkorb hinzufügen

• Bestellung aufgeben

• Zahlung leisten

• Bestellung verfolgen

Folgendes liegt außerhalb der Grenze:

• Kunde

• Zahlungs-Gateway

• Lieferunternehmen

• E-Mail-Anbieter

Die Abgrenzung verhindert Verwirrung hinsichtlich der Systemverantwortung.

2.3 Anwendungsfall

Ein Anwendungsfall sollte eine vollständige Interaktion beschreiben, die ein sinnvolles Ergebnis liefert.

Zum Beispiel:

Bestellung aufgeben:Ein Kunde wählt Produkte aus, liefert Lieferinformationen, bezahlt die Bestellung und erhält eine Bestellbestätigung.

„Kreditkartennummer validieren“ könnte eine Systemfunktion sein, ist aber normalerweise zu klein, um ein eigenständiges Benutzerziel zu sein. Es kann stattdessen Teil von Bestellung aufgeben oder Zahlung leisten.

2.4 Vorbedingungen

Eine Vorbedingung legt fest, was bereits wahr sein muss, bevor der Anwendungsfall beginnt.

Beispiele:

• Der Kunde verfügt über ein aktives Konto.

• Das Produkt ist zum Verkauf verfügbar.

• Der Mitarbeiter ist authentifiziert.

• Der Terminzeitraum existiert.

• Der Warenkorb enthält mindestens einen Artikel.

Eine Vorbedingung ist keine vom Anwendungsfall durchgeführte Aktion.

Schlechte Vorbedingung:

Der Kunde meldet sich an.

Bessere Vorbedingung:

Der Kunde ist authentifiziert.

2.5 Nachbedingungen

Eine Nachbedingung legt fest, was nach Abschluss des Anwendungsfalls wahr ist.

Beispiele:

• Die Bestellung wird aufgezeichnet.

• Die Zahlung ist autorisiert.

• Eine Bestätigungs-E-Mail wird gesendet.

• Der Kostenantrag hat den Status „eingereicht“.

• Das Benutzerkonto ist als aktiv markiert.

Nachbedingungen sollten Ergebnisse beschreiben, keine Implementierungsdetails.

Schlechte Nachbedingung:

Die Bestellungen-Tabelle wird aktualisiert.

Bessere Nachbedingung:

Die Bestellung wird gespeichert und ist zur Erfüllung verfügbar.

2.6 Haupterfolgs-Szenario

Das Haupterfolgs-Szenario, auch genannt der Grundablauf oder Glückspfad, beschreibt die normale erfolgreiche Interaktion.

Jeder Schritt sollte beschreiben:

1. Eine Interaktion zwischen Akteur und System

2. Eine Systemantwort

3. Eine sinnvolle Geschäftsaktion

Beispiel:

1. Der Kunde wählt Produkte aus.

2. Das System zeigt den aktuellen Warenkorb an.

3. Der Kunde gibt Lieferinformationen ein.

4. Das System validiert die Lieferinformationen.

5. Der Kunde übermittelt die Bestellung.

6. Das System fordert eine Zahlungsautorisation an.

7. Das Payment-Gateway autorisiert die Zahlung.

8. Das System protokolliert die Bestellung.

9. Das System zeigt die Bestellbestätigung an.

Vermeiden Sie interfacespezifische Details, es sei denn, sie sind für die Anforderung wesentlich.

Schlechter Schritt:

Der Kunde klickt auf den blauen Button in der unteren rechten Ecke.

Besserer Schritt:

Der Kunde übermittelt die Bestellung.

2.7 Alternative Abläufe

Ein alternativer Ablauf beschreibt eine gültige Variante des Hauptablaufs.

Beispiele:

• Der Kunde wählt die Abholung im Geschäft statt Lieferung.

• Der Kunde bezahlt mit einer gespeicherten Zahlungsmethode.

• Der Administrator genehmigt einen Antrag unter Auflagen.

• Der Benutzer authentifiziert sich mit einem Einmalcode.

Alternative Abläufe können wieder in den Hauptablauf eintreten.

Beispiel:

A1. Der Kunde verwendet eine gespeicherte Zahlungsmethode
In Schritt 6 wählt der Kunde eine gespeicherte Zahlungsmethode aus. Das System fordert eine Autorisierung mit dieser Methode an und fährt dann in Schritt 7 fort.

2.8 Ausnahmefälle

Ein Ausnahmefall beschreibt einen nicht erfolgreichen oder abnormalen Zustand.

Beispiele:

• Die Zahlung wird abgelehnt.

• Das Produkt ist nicht vorrätig.

• Die Authentifizierung schlägt fehl.

• Der externe Dienst ist nicht verfügbar.

• Die erforderlichen Daten sind ungültig.

Ein Ausnahmefall sollte erklären:

• Wo das Problem auftritt

• Was das System tut

• Was der Akteur sieht

• Ob der Anwendungsfall endet oder fortgesetzt wird

Beispiel:

E1. Die Zahlung wurde abgelehnt
In Schritt 7 lehnt das Payment-Gateway die Transaktion ab. Das System zeigt den Grund an, markiert die Bestellung als unbezahlt und ermöglicht es dem Kunden, eine andere Zahlungsmethode auszuwählen.

2.9 Include- und Extend-Beziehungen

include

Verwenden Sie include , wenn ein Use-Case immer ein anderes wiederverwendbares Verhalten aufruft.

Beispiel:

• Bestellung aufgeben includes Gesamtbetrag berechnen

• Bestellung aufgeben includes Kunden authentifizieren

• Bargeld abheben includes PIN überprüfen

Das eingebundene Verhalten ist erforderlich.

Bestellung aufgeben <<include>> Gesamtbetrag berechnen

extend

Verwenden Sie extend , wenn ein optionales oder bedingtes Verhalten einen Basis-Use-Case ergänzt.

Beispiel:

• Bestellung aufgeben kann durch Rabattcode anwenden erweitert werden

• Kasse kann durch Geschenknotiz hinzufügen erweitert werden

Das erweiternde Verhalten wird nicht immer ausgeführt.

Rabattcode anwenden <<extend>> Bestellung aufgeben

Eine nützliche Regel:

• Include: „Dies geschieht immer als Teil des Use-Case.“

• Extend: „Dies kann unter bestimmten Bedingungen eintreten.“

Verwenden Sie nicht include und erweitern einfach, um jeden Ablauf in kleine Teile zu zerlegen. Übermäßige Zerlegung macht das Modell schwer verständlich.

2.10 Verallgemeinerung

Verallgemeinerung stellt die Vererbung zwischen Akteuren oder Anwendungsfällen dar.

Beispiel:

• Mitarbeiter ist ein allgemeiner Akteur.

• Manager ist ein spezialisierter Akteur, der das Verhalten des Mitarbeiters erbt.

Manager --|> Mitarbeiter

Verwenden Sie Verallgemeinerung, wenn das spezialisierte Element tatsächlich eine Art des verallgemeinerten Elements ist, nicht nur, weil zwei Elemente einige Schritte gemeinsam haben.

3. Standardvorlage für die Beschreibung von Anwendungsfällen

Die folgende Vorlage eignet sich gut für Anforderungsdokumente, Projektspezifikationen und Analysemodelle.

Anwendungsfall-ID:
Name des Anwendungsfalls:
Ziel:
Umfang:
Ebene:
Hauptakteur:
Unterstützende Akteure:
Interessengruppen und Interessen:

Auslöser:

Voraussetzungen:

Minimale Garantien:

Erfolgsgarantien:

Hauptszenario für den Erfolg:
1.
2.
3.

Alternative Abläufe:
A1.
A2.

Ausnahmeabläufe:
E1.
E2.

Spezielle Anforderungen:
- Leistung
- Sicherheit
- Benutzerfreundlichkeit
- Verfügbarkeit
- Konformität

Geschäftsregeln:

Datenanforderungen:

Häufigkeit und Umfang:

Annahmen:

Offene Fragen:

Verwandte Anwendungsfälle:

Erklärung der Felder

4. Beispiel: Bestellung aufgeben

UC-001 — Bestellung aufgeben

Ziel:
Ermöglicht einem Kunden, ein oder mehrere Produkte zu kaufen.

Umfang:
Online-Shop

Ebene:
Benutzerziel

Hauptakteur:
Kunde

Unterstützende Akteure:

• Zahlungs-Gateway

• Lagerservice

• E-Mail-Service

• Lieferdienst

Interessengruppen und Interessen:

• Kunde:Möchte Produkte erfolgreich kaufen und eine Bestätigung erhalten.

• Geschäft:Möchte eine gültige Bestellung erfassen und die Zahlung einziehen.

• Lager:Benötigt genaue Informationen zur Auftragsabwicklung.

• Zahlungs-Gateway:Benötigt eine gültige Zahlungsanforderung.

• Lieferdienst:Benötigt eine vollständige Lieferadresse.

Auslöser:
Der Kunde reicht den Warenkorb zur Kasse ein.

Voraussetzungen:

• Der Kunde hat mindestens einen Artikel im Warenkorb.

• Produkte sind bestellbar verfügbar.

• Der Kunde gibt eine gültige Lieferadresse an.

• Das System kann mit dem Zahlungsdienst kommunizieren.

Minimale Garantien:

• Keine unbezahlte Bestellung wird als bestätigt behandelt.

• Der Kunde wird informiert, falls die Bestellung nicht abgeschlossen werden kann.

• Reservierter Lagerbestand wird freigegeben, falls die Zahlung fehlschlägt.

Erfolgsgarantien:

• Die Zahlung ist autorisiert.

• Die Bestellung wird erfasst.

• Der Lagerbestand wird reserviert.

• Der Kunde erhält eine Bestätigung.

• Informationen zur Auftragsabwicklung werden dem Lager bereitgestellt.

Hauptszenario für den Erfolg

1. Der Kunde prüft den Warenkorb.

2. Das System zeigt die Produkte, Mengen, Preise, Steuern, Versandkosten und den Gesamtbetrag an.

3. Der Kunde gibt Lieferinformationen an.

4. Das System validiert die Lieferinformationen.

5. Der Kunde wählt eine Zahlungsmethode aus.

6. Der Kunde übermittelt die Bestellung.

7. Das System prüft die Produktverfügbarkeit.

8. Das System fordert eine Zahlungsautorisation vom Payment-Gateway an.

9. Das Payment-Gateway autorisiert die Zahlung.

10. Das System erstellt die Bestellung.

11. Das System reserviert die bestellten Produkte.

12. Das System sendet eine Bestellbestätigung an den Kunden.

13. Das System zeigt die Bestellnummer und das voraussichtliche Lieferdatum an.

Alternative Abläufe

A1. Der Kunde verwendet eine gespeicherte Adresse

In Schritt 3 wählt der Kunde eine zuvor gespeicherte Adresse aus. Das System zeigt die Adresse an und fährt in Schritt 4 fort.

A2. Der Kunde verwendet eine gespeicherte Zahlungsmethode

In Schritt 5 wählt der Kunde eine gespeicherte Zahlungsmethode aus. Das System verwendet diese Methode und fährt in Schritt 6 fort.

A3. Der Kunde wählt die Abholung im Geschäft

In Schritt 3 wählt der Kunde die Abholung im Geschäft statt der Lieferung. Das System zeigt verfügbare Geschäfte und Abholtermine an und fährt dann in Schritt 5 fort.

Ausnahmefälle

E1. Produkt nicht verfügbar

In Schritt 7 stellt das System fest, dass ein Produkt nicht verfügbar ist. Das System identifiziert das nicht verfügbare Produkt, aktualisiert den Warenkorb und bittet den Kunden, die Bestellung zu überprüfen.

E2. Zahlung wird abgelehnt

In Schritt 9 lehnt das Payment-Gateway die Zahlung ab. Das System bestätigt die Bestellung nicht, hebt die Lagerreservierungen auf, zeigt die Fehlermeldung an und ermöglicht dem Kunden, eine andere Zahlungsmethode auszuwählen.

E3. Payment-Gateway ist nicht verfügbar

In Schritt 8 antwortet das Payment-Gateway nicht innerhalb des konfigurierten Zeitlimits. Das System markiert den Zahlungsvorgang als ausstehend, informiert den Kunden und verhindert die doppelte Einreichung der Bestellung.

Geschäftsregeln

• Eine Bestellung muss mindestens ein Produkt enthalten.

• Die Produktmenge muss größer als null sein.

• Ein Produkt kann nicht bestellt werden, wenn der verfügbare Lagerbestand unzureichend ist.

• Die Zahlung muss autorisiert werden, bevor die Bestellung bestätigt wird.

• Preise und Steuern werden unter Verwendung der aktuellen Preisregeln berechnet.

• Ein Kunde kann eine Bestellung nur vor Beginn der Erfüllung stornieren.

Spezielle Anforderungen

• Die Bestellzusammenfassung sollte unter normaler Last innerhalb von zwei Sekunden angezeigt werden.

• Zahlungsinformationen dürfen nicht im Klartext gespeichert werden.

• Doppelte Einreichungen dürfen keine doppelten Bestellungen erzeugen.

• Das System muss eine Prüfpflicht für Änderungen des Zahlungs- und Bestellstatus protokollieren.

5. Verwendungszweck-Ebenen

Beschreibungen von Verwendungszwecken können auf verschiedenen Detaillierungsstufen verfasst werden.

Verwendungszweck auf Zusammenfassungsebene

Ein Verwendungszweck auf Zusammenfassungsebene beschreibt einen breiten Geschäftsprozess.

Beispiel:

Kundenbestellung erfüllen

Dies kann Folgendes umfassen:

• Bestellung entgegennehmen

• Produkte kommissionieren

• Bestellung verpacken

• Bestellung versenden

Verwendungszweck auf Benutzerziel-Ebene

Dies ist in der Regel die nützlichste Ebene für die Anforderungsanalyse.

Beispiel:

Bestellung aufgeben

Es beschreibt ein Ziel, das ein primärer Akteur in einem Durchgang erreichen kann.

Use-Case auf Subfunktionsniveau

Dies beschreibt ein kleineres, wiederverwendbares Systemverhalten.

Beispiele:

• Bestellsumme berechnen

• Zahlung validieren

• Rechnung erstellen

Use-Cases auf Subfunktionsniveau sind nützlich, wenn Verhalten wiederverwendet wird oder technisch komplex ist, sollten jedoch keine Benutzerziel-Use-Cases ersetzen.

6. Schreiben hochwertiger Use-Case-Beschreibungen

Verwenden Sie akteurszentrierte Sprache

Schreiben Sie aus der Perspektive des Akteurs:

Der Kunde reicht eine Bestellung ein.

Vermeiden Sie umsetzungszentrierte Formulierungen:

OrderController ruft den Bestelldienst auf.

Letzteres gehört in die Design-Dokumentation, nicht in einen geschäftlichen Use-Case.

Halten Sie jeden Schritt atomar

Vermeiden Sie die Kombination zu vieler Aktionen:

Der Kunde gibt Details ein, wählt eine Zahlungsmethode aus, bestätigt die Bestellung und erhält eine E-Mail.

Verbessern Sie es, indem Sie die Interaktion trennen:

1. Der Kunde gibt Lieferinformationen ein.

2. Das System validiert die Informationen.

3. Der Kunde wählt eine Zahlungsmethode aus.

4. Der Kunde bestätigt die Bestellung.

5. Das System sendet eine Bestätigung.

Beschreiben Sie beobachtbares Verhalten

Ein Leser sollte feststellen können, ob die Anforderung implementiert wurde.

Schwach:

Das System verarbeitet die Anfrage.

Stärker:

Das System validiert die Anfrage, erfasst den Anspruch, weist ihm eine Anspruchsnummer zu und zeigt den Einreichungsstatus an.

Vermeiden Sie vorzeitiges UI-Design

Verwenden Sie:

Der Kunde liefert Lieferinformationen.

Statt:

Der Kunde gibt die Adresse in das Textfeld ein und klickt auf den grünen Weiter-Button.

Die zweite Version schränkt die Schnittstelle unnötig ein.

Halten Sie den Hauptablauf erfolgreich

Füllen Sie den Grundablauf nicht mit allen möglichen Fehlern. Platzieren Sie Fehler in Ausnahmeflows.

Identifizieren Sie Geschäftsregeln separat

Geschäftsregeln gelten häufig für mehrere Anwendungsfälle. Ihre separate Behandlung verhindert wiederholten, inkonsistenten Text.

Machen Sie das Fehlverhalten explizit

Geben Sie für jeden wichtigen Fehler Folgendes an:

• Ob Daten gespeichert werden

• Ob eine Transaktion rückgängig gemacht wird

• Ob der Akteur einen erneuten Versuch unternehmen kann

• Ob ein Administrator benachrichtigt wird

• Ob der Anwendungsfall endet oder fortgesetzt wird

7. Von Anforderungen zu Anwendungsfällen

Ein praktischer Arbeitsablauf ist:

1. Identifizieren Sie das zu modellierende System.

2. Listen Sie externe Akteure auf.

3. Fragen Sie, was jeder Akteur erreichen möchte.

4. Konvertieren Sie jedes Ziel in einen Anwendungsnamen.

5. Definieren Sie die Systemgrenze.

6. Schreiben Sie das Hauptszenario für den Erfolg.

7. Fügen Sie alternative und Ausnahmeflows hinzu.

8. Fügen Sie Geschäftsregeln und spezielle Anforderungen hinzu.

9. Zeichnen Sie das Anwendungsfalldiagramm.

10. Überprüfen Sie das Modell mit den Beteiligten.

11. Verknüpfen Sie Anwendungsfälle mit Anforderungen, Tests und Entwurfsdokumenten.

Akteur-Ziel-Analyse

Eine nützliche Frage ist:

Welches geschäftliche Ergebnis benötigt dieser Akteur vom System?

8. Notation für Anwendungsfalldiagramme

Die häufigsten Elemente sind:

• Akteur:Externe Rolle

• Anwendungsfall:Systemfähigkeit oder Akteursziel

• Systemgrenze:Umfang des Systems

• Assoziation:Aktor nimmt an einem Anwendungsfall teil

• Einschließen:Erforderliches wiederverwendbares Verhalten

• Erweitern:Optionales oder bedingtes Verhalten

• Verallgemeinerung:Spezialisierter Akteur oder Anwendungsfall

Ein Anwendungsfall-Diagramm sollte nicht versuchen zu zeigen:

• Jeden Workflow-Schritt

• Datenbanktabellen

• Klassenattribute

• Detaillierte Geschäftsregeln

• Bildschirmlayouts

• Interne Algorithmen

Diese gehören in Aktivitätsdiagramme, Klassendiagramme, Sequenzdiagramme oder schriftliche Anforderungen.

9. Beispiel für ein PlantUML-Diagramm

Das folgende Beispiel modelliert den Bestellung aufgeben Anwendungsfall und zugehöriges Verhalten.

@startuml
left to right direction

skinparam packageStyle rectangle
skinparam shadowing false
skinparam usecase {
    BackgroundColor #F8FBFF
    BorderColor #2F5597
    ArrowColor #555555
}

actor Kunde
actor "Zahlungs-Gateway" as Payment
actor "Lagerservice" as Inventory
actor "E-Mail-Service" as Email
actor "Lieferdienst" as Delivery

rectangle "Online-Shop" {
    usecase "Produkte durchsuchen" as Browse
    usecase "Warenkorb verwalten" as Cart
    usecase "Bestellung aufgeben" as PlaceOrder
    usecase "Bestellsumme berechnen" as CalculateTotal
    usecase "Produktverfügbarkeit prüfen" as CheckStock
    usecase "Zahlung autorisieren" as AuthorizePayment
    usecase "Lagerbestand reservieren" as ReserveInventory
    usecase "Bestellbestätigung senden" as SendConfirmation
    usecase "Bestellung verfolgen" as TrackOrder
    usecase "Rabattcode anwenden" as ApplyDiscount
}

Kunde --> Browse
Kunde --> Cart
Kunde --> PlaceOrder
Kunde --> TrackOrder

Payment --> AuthorizePayment
Inventory --> CheckStock
Inventory --> ReserveInventory
Email --> SendConfirmation
Delivery --> TrackOrder

PlaceOrder ..> CalculateTotal : <<include>>
PlaceOrder ..> CheckStock : <<include>>
PlaceOrder ..> AuthorizePayment : <<include>>
PlaceOrder ..> ReserveInventory : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

ApplyDiscount ..> PlaceOrder : <<extend>>

@enduml

Interpretation

• Der Kunde initiiert Bestellung aufgeben.

• Bestellung aufgeben umfasst immer Berechnung, Lagerbestandsprüfung, Zahlungsautorisation, Reservierung des Lagerbestands und Bestätigung.

• Rabattcode anwenden ist optional, daher erweitert es Bestellung aufgeben.

• Externe Dienste sind an spezifischen Systemverhalten beteiligt.

• Die Systemgrenze ist das Online-Shop Rechteck.

Die genaue Platzierung der Elemente wird vom Rendering-Engine gesteuert. Die wichtigen Modellierungsentscheidungen sind die Akteure, Anwendungsfälle, Grenzen und Beziehungen.

10. Erstellen des Diagramms in Visual Paradigm VPasCode

VPasCode ist eine browserbasierte Text-zu-Diagramm-Plattform, die PlantUML, Mermaid, Graphviz und andere Diagrammformate unterstützt. Es bietet Quellcode-Bearbeitung und Live-Rendering, sodass sich das Diagramm aktualisiert, wenn sich der Code ändert.

Grundlegender Arbeitsablauf

1. Öffnen Sie den VPasCode-Editor.

2. Erstellen Sie ein neues PlantUML-Diagramm.

3. Fügen Sie die PlantUML-Quelle ein.

4. Stellen Sie sicher, dass der Editor die PlantUML-Syntax erkennt.

5. Überprüfen Sie die Live-Vorschau.

6. Bearbeiten Sie Akteure, Anwendungsfälle, Beziehungen und das Styling im Quellfenster.

7. Exportieren oder kopieren Sie das gerenderte Diagramm.

8. Fügen Sie das Diagramm zur Projektdokumentation hinzu.

VPasCode unterstützt PlantUML-Anwendungsfalldiagramme und bietet Echtzeit-Rendering im Browser. Es bietet auch Beispiele und Styling-Optionen für PlantUML-Diagramme.

Beispiel-Prompt für KI-gestützte Generierung

Wenn Sie eine KI-Funktion zur Diagrammgenerierung verwenden, ist ein nützlicher Prompt:

Erstellen Sie ein PlantUML-Anwendungsfalldiagramm für einen Online-Shop.

Hauptakteur:
- Kunde

Unterstützende Akteure:
- Payment Gateway
- Inventory Service
- Email Service
- Delivery Service

Hauptanwendungsfälle:
- Produkte durchsuchen
- Warenkorb verwalten
- Bestellung aufgeben
- Bestellung verfolgen

Bestellung aufgeben muss Folgendes umfassen:
- Bestellsumme berechnen
- Produktverfügbarkeit prüfen
- Zahlung autorisieren
- Lagerbestand reservieren
- Bestellbestätigung senden

Rabattcode anwenden sollte Bestellung aufgeben erweitern.

Verwenden Sie eine Systemgrenze mit dem Namen Online-Shop.

Betrachten Sie den generierten Code als Ausgangspunkt. Überprüfen Sie, ob:

• Akteure sind tatsächlich extern

• Anwendungsfälle stellen Benutzerziele dar

• inkludieren und erweiternwerden korrekt verwendet

• Die Systemgrenze ist korrekt

• Beziehungen spiegeln echtes Geschäftsverhalten wider

VPasCode unterstützt zudem den Wechsel zwischen der textbasierten Diagrammbearbeitung und den grafischen Modellierungswerkzeugen von Visual Paradigm, was nützlich sein kann, wenn Teams eine quellenbasierte Bearbeitung für Versionierung und eine visuelle Bearbeitung zur Verfeinerung des Layouts wünschen.

11. Pflege von PlantUML-Anwendungsfalldiagrammen

Verwenden Sie aussagekräftige Aliasnamen

Aliasnamen erleichtern die Pflege von Beziehungen:

usecase "Bestellung aufgeben" als PlaceOrder
Kunde --> PlaceOrder

Kommentare hinzufügen

' Kernkundentransaktion
usecase "Bestellung aufgeben" als PlaceOrder

Kommentare helfen anderen Teammitgliedern, die Quelle zu verstehen und das Diagramm zu pflegen.

Halten Sie das Diagramm fokussiert

Wenn ein Diagramm zu viele Anwendungsfälle enthält:

• Erstellen Sie ein Kontextdiagramm

• Erstellen Sie separate Diagramme nach Geschäftsbereich

• Verwenden Sie Paketgruppierungen

• Verknüpfen Sie zusammenhängende Diagramme über die Dokumentation

• Vermeiden Sie es, jede Teilfunktion auf der höchsten Ebene darzustellen

Verwenden Sie eine konsistente Benennung

Wählen Sie eine Konvention und wenden Sie sie konsistent an:

• Bestellung aufgeben

• Bestellung stornieren

• Bestellung verfolgen

Vermeiden Sie das Mischen von Stilen wie:

• Bestellung aufgeben

• OrderCancellation

• tracking_function

Quelle mit dem Projekt speichern

Eine typische Repository-Struktur könnte wie folgt aussehen:

docs/
  use-cases/
    UC-001-place-order.md
    UC-002-track-order.md
  diagrams/
    online-store-use-cases.puml

Das Behalten der .pumlQuelle unter Versionskontrolle macht Änderungen überprüfbar und reproduzierbar.

12. Rückverfolgbarkeit

Ein ausgereifter Anforderungsprozess verbindet Anwendungsfälle mit anderen Projektartefakten.

Nachverfolgbarkeit hilft bei der Beantwortung folgender Fragen:

• Welche Anforderungen sind abgedeckt?

• Welche Anwendungsfälle wurden nicht getestet?

• Welche Designkomponenten unterstützen ein Geschäftsziel?

• Was ist betroffen, wenn sich eine Anforderung ändert?

13. Häufige Fehler

Interne Komponenten als Akteure modellieren

Eine Datenbank oder ein interner Dienst ist in der Regel kein Akteur, wenn er sich innerhalb der Systemgrenze befindet.

Ein Akteur muss außerhalb des zu modellierenden Systems liegen.

Bildschirme als Anwendungsfälle behandeln

Ein Bildschirm ist ein Benutzeroberflächenelement, nicht unbedingt ein Benutzerziel.

Verwenden Sie:

Reisekostenabrechnung einreichen

Anstatt:

Bildschirm für Reisekostenabrechnung

Verwenden von includefür jeden gemeinsamen Schritt

Gemeinsame Formulierung allein rechtfertigt keinen included use case. Verwenden Sie includewenn das Verhalten verpflichtend und eigenständig sinnvoll ist.

Verwenden von extendfür normale Schritte

Wenn ein Verhalten immer auftritt, sollte es nicht als Erweiterung modelliert werden.

Schreiben von Implementierungsdetails

Vermeiden Sie Verweise auf:

• Controller

• Datenbanktabellen

• API-Endpunkte

• Klassen

• Interne Methoden

es sei denn, das Dokument ist speziell ein technisches Design.

Auslassen des Fehlverhaltens

Ein Anwendungsfall ist unvollständig, wenn er nur den Erfolg erklärt. Zahlungsablehnungen, ungültige Daten, Zeitüberschreitungen, Autorisierungsfehler und nicht verfügbare Ressourcen sollten behandelt werden.

Anwendungsfall zu breit gefasst

„Das gesamte Geschäft verwalten“ ist nicht umsetzbar. Breitere Ziele sollten in Anwendungsfall-Ebenen auf Benutzerziele heruntergebrochen werden.

Anwendungsfall zu klein gefasst

„Feld validieren“ und „Nachricht anzeigen“ sind in der Regel System-Schritte, keine unabhängigen Akteursziele.

14. Überprüfungsliste

Überprüfen Sie vor der Genehmigung einer Anwendungsfallbeschreibung:

Umfang und Akteure

• Ist die Systemgrenze klar definiert?

• Sind alle externen Akteure identifiziert?

• Handeln die Akteure als Rollen und nicht als individuelle Namen?

• Werden unterstützende Systeme nur modelliert, wenn sie extern sind?

Zielqualität

• Bietet der Anwendungsfall einen Mehrwert für den primären Akteur?

• Ist der Name eine klare Verb-Nomen-Phrase?

• Liegt der Anwendungsfall auf einem angemessenen Niveau?

Ablaufqualität

• Beschreibt das Hauptszenario ein erfolgreiches Ergebnis?

• Ist jeder Schritt atomar und beobachtbar?

• Sind alternative Pfade dokumentiert?

• Sind Ausnahmepfade dokumentiert?

• Ist das Wiederherstellungsverhalten klar?

Bedingungen und Ergebnisse

• Sind Vorbedingungen überprüfbar?

• Sind Erfolgsgarantien explizit?

• Sind Minimalgarantien definiert?

• Sind Geschäftsregeln von prozeduralen Schritten getrennt?

Diagrammqualität

• Liegen alle Use Cases innerhalb der korrekten Grenze?

• Sind Assoziationen zwischen Akteuren sinnvoll?

• Sind includeBeziehungen verpflichtend?

• Sind extendBeziehungen optional oder bedingt?

• Ist das Diagramm ohne übermäßige Details lesbar?

Anforderungsqualität

• Kann jeder wichtige Schritt getestet werden?

• Sind nichtfunktionale Anforderungen enthalten?

• Sind ungelöste Fragen dokumentiert?

• Ist der Use Case mit Anforderungen und Testfällen verknüpft?

15. Empfohlene Struktur der Liefergegenstände

Verwenden Sie für ein vollständiges Projektpaket die folgende Struktur:

1. Systemkontext
2. Akteure-Katalog
3. Use-Case-Diagramm
4. Use-Case-Katalog
5. Detaillierte Use-Case-Beschreibungen
6. Geschäftsregeln
7. Nichtfunktionale Anforderungen
8. Rückverfolgbarkeitsmatrix
9. Offene Fragen und Annahmen
10. PlantUML-Quelldateien

Eine starke Use-Case-Beschreibung ist präzise genug für Analysten, für Stakeholder verständlich und von einem Qualitätssicherungsteam testbar. Der beste Workflow besteht darin, die schriftliche Beschreibung zu verwenden, um das Verhalten festzulegen, das Use-Case-Diagramm, um Umfang und Beziehungen zu kommunizieren, und PlantUML in VPasCode, um das visuelle Modell einfach bearbeitbar und wartbar zu halten.

Referenz

Der Artikel ist auch in English, Español, فارسی, Français, English and Bahasa Indonesia verfügbar.