UML-Use-Case-Diagramme als Code mit PlantUML und VPasCode

Ein UML-Use-Case-Diagramm zeigt, was ein System bietet und wer oder was damit interagiert. Bei einem Diagramm-als-Code-Workflow ist die Quelle des Diagramms reiner Text: Bearbeiten Sie den Text, rendern Sie das Diagramm und bewahren Sie die Quelle zusammen mit der Projektdokumentation auf.

PlantUML unterstützt Use-Case-Diagramme. Der VPasCode-Editor von Visual Paradigm bietet einen PlantUML-Editor und eine Vorschau sowie KI-gestützte Funktionen zur Diagrammerstellung und -bearbeitung.

1. Was ein Use-Case-Diagramm vermittelt

Use-Case-Diagramme konzentrieren sich auf den Systemumfang und die Benutzerziele, nicht die schrittweisen Abläufe eines Workflows. Ein Diagramm enthält typischerweise:

• Systemgrenze:Ein Rechteck, das das zu modellierende System benennt.

• Akteur:Eine Rolle außerhalb des Systems, die mit ihm interagiert. Akteure können Personen, Organisationen, Geräte oder externe Systeme sein.

• Use Case:Eine vom System bereitgestellte Fähigkeit oder ein Ziel, das üblicherweise als Oval dargestellt und mit einer Verbbegriff wie „Bestellung aufgeben“ benannt wird.

• Assoziation:Eine Linie, die zeigt, dass ein Akteur an einem Use Case teilnimmt.

• Use-Case-Beziehungen:Include, Extend und Verallgemeinerung.

Akteure repräsentieren Rollen, nicht spezifische Personen. Ein externer Zahlungsdienst kann ein Akteur sein, wenn er mit dem zu modellierenden System interagiert.

Use-Case-Diagramme sind nützlich, um den Systemumfang zu klären, Anforderungen mit Stakeholdern zu besprechen, externe Abhängigkeiten zu identifizieren und eine gemeinsame Übersicht für Entwicklung und Test bereitzustellen. Kombinieren Sie sie mit schriftlichen Use-Case-Beschreibungen, wenn Details wie Vorbedingungen, Hauptschritte, alternative Abläufe und Ergebnisse erforderlich sind.

2. Beziehungen auf einen Blick

• Akteur–Use-Case-Assoziation:Eine einfache Linie, die eine Interaktion anzeigt.

• <<include>>:Der einschließende Use Case verwendet immer das eingeschlossene Verhalten. Der gestrichelte Pfeil zeigt vom einschließenden Use Case zum eingeschlossenen Use Case. Zum Beispiel kann das Aufgeben einer Bestellung immer eine Zahlungsautorisierung beinhalten.

• <<extend>>:Ein erweiternder Use Case fügt unter einer Bedingung Verhalten zu einem Basis-Use Case hinzu. Der gestrichelte Pfeil zeigt vom erweiternden Anwendungsfall zum Basis-Anwendungsfall. Zum Beispiel kann das Anwenden eines Angebots das Aufgeben einer Bestellung erweitern.

• Verallgemeinerung: Ein spezialisierter Akteur oder Anwendungsfall erbt von einem allgemeineren. Die durchgezogene Linie mit einem hohlen Dreieck zeigt auf das allgemeine Element.

Eine nützliche Unterscheidung: include bedeutet erforderliches Verhalten; extend bedeutet bedingtes hinzugefügtes Verhalten.

3. PlantUML-Grundlagen

Ein PlantUML-Diagramm beginnt mit @startuml und endet mit @enduml. Deklarieren Sie Akteure mit actor, Anwendungsfälle mit usecase und Systemgrenzen mit rectangle. Aliasnamen erleichtern die Referenzierung von Elementen in Beziehungen.

@startuml
left to right direction

actor Kunde

rectangle "Online-Shop" {
  usecase "Produkte durchsuchen" as Durchsuchen
  usecase "Bestellung aufgeben" as Aufgeben
}

Kunde --> Durchsuchen
Kunde --> Aufgeben
@enduml

Richtung von links nach rechts weist PlantUML an, das Diagramm horizontal anzuordnen. PlantUML kann das genaue Layout anpassen, wenn sich das Diagramm ändert.

4. Beispiel: grundlegender Online-Shop

@startuml
left to right direction

actor Kunde
actor Administrator als Admin

rectangle "Online-Shop" {
  usecase "Produkte durchsuchen" als Durchsuchen
  usecase "Bestellung aufgeben" als Aufgeben
  usecase "Sendung verfolgen" als Verfolgen
  usecase "Katalog verwalten" als Verwalten
}

Kunde --> Durchsuchen
Kunde --> Aufgeben
Kunde --> Verfolgen
Admin --> Verwalten
@enduml

Kunden durchsuchen Produkte, geben Bestellungen auf und verfolgen Sendungen. Der Administrator verwaltet den Katalog. Das Diagramm lässt bewusst die internen Schritte der Bestellabwicklung aus.

5. Beispiel: include und extend

Angenommen, das Aufgeben einer Bestellung erfordert immer eine Zahlungsautorisierung, während das Anwenden eines Rabatts optional und bedingt ist.

@startuml
left to right direction

actor Kunde

rectangle "Online-Shop" {
  usecase "Bestellung aufgeben" als Aufgeben
  usecase "Zahlung autorisieren" als Zahlung
  usecase "Rabatt anwenden" als Rabatt
}

Kunde --> Aufgeben

Aufgeben ..> Zahlung : <<include>>
Rabatt ..> Aufgeben : <<extend>>
@enduml

Der Aufgeben ..> Zahlung Pfeil bedeutet, dass „Bestellung aufgeben“ das erforderliche Zahlungsverhalten einschließt. Der Rabatt ..> Aufgeben Pfeil bedeutet, dass „Rabatt anwenden“ „Bestellung aufgeben“ erweitert, wenn seine Bedingung erfüllt ist.

Dokumentieren Sie die Bedingung – beispielsweise „Kunde gibt einen gültigen Rabattcode ein“ – in der Use-Case-Beschreibung oder in einer Notiz.

6. Beispiel: Akteur-Generalisierung und externe Systeme

Ein spezialisierter Akteur erbt Interaktionen von einem allgemeineren Akteur. Externe Dienste können ebenfalls als Akteure fungieren, wenn sie mit dem System interagieren.

@startuml
left to right direction

actor "Benutzer" als Benutzer
actor "Registrierter Kunde" als Kunde
actor "Zahlungs-Gateway" als Gateway

Kunde --|> Benutzer

rectangle "Online-Shop" {
  usecase "Produkte durchsuchen" als Durchsuchen
  usecase "Bestellung aufgeben" als Aufgeben
  usecase "Zahlung verarbeiten" als Bezahlen
}

Benutzer --> Durchsuchen
Kunde --> Aufgeben
Aufgeben ..> Bezahlen : <<include>>
Gateway --> Bezahlen
@enduml

„Registrierter Kunde“ spezialisiert „Benutzer“ und erbt die allgemeine Benutzerinteraktion. Das Payment-Gateway liegt außerhalb der Online-Store-Grenze, nimmt jedoch am Zahlungsfall teil.

7. Beispiel: Verallgemeinerung von Anwendungsfällen

Verallgemeinerung kann spezialisierte Versionen eines breiteren Anwendungsfalls darstellen. Das hohle Dreieck zeigt auf den allgemeinen Anwendungsfall.

@startuml
left to right direction

actor Kunde

rectangle "Zahlungssystem" {
  usecase "Zahlung leisten" as Zahlung
  usecase "Mit Karte zahlen" as Karte
  usecase "Überweisen" as Überweisung
}

Kunde --> Karte
Kunde --> Überweisung

Karte --|> Zahlung
Überweisung --|> Zahlung
@enduml

Verwenden Sie dies, wenn spezialisierte Anwendungsfälle ein gemeinsames Ziel haben, aber bedeutende Unterschiede aufweisen. Wenn die Variationen lediglich bedingte Schritte sind, ist eine <<extend>>Beziehung oder eine schriftliche Beschreibung des Anwendungsfalls möglicherweise klarer.

8. Arbeiten in VPasCode

Ein praktischer Arbeitsablauf:

1. Definieren Sie den Umfang.Identifizieren Sie die Systemgrenze, die Rollen der Akteure und die Ziele, die jede Rolle erreichen möchte.

2. Erstellen Sie einen Entwurf.Schreiben Sie PlantUML direkt oder bitten Sie den KI-Assistenten, ein Anwendungsfalldiagramm zu generieren.

3. Überprüfen Sie den Code und die Vorschau.Bestätigen Sie, dass Akteure außerhalb der Systemgrenze liegen, Anwendungsfälle innerhalb liegen und Pfeile in die richtige Richtung zeigen.

4. Verfeinern Sie das Modell.Ersetzen Sie vage Namen, entfernen Sie Implementierungsdetails und fügen Sie Beziehungen nur hinzu, wenn sie echte Anforderungen widerspiegeln.

5. Fordern Sie gezielte KI-Bearbeitungen an.Zum Beispiel: „Fügen Sie einen externen Payment-Gateway-Akteur hinzu und zeigen Sie die erforderliche Zahlungsinteraktion mit einer Include-Beziehung. Lassen Sie den Rest unverändert.“

6. Validieren Sie mit den Beteiligten.Stellen Sie sicher, dass das Diagramm den tatsächlichen Umfang des Systems und die Benutzerziele widerspiegelt.

7. Speichern Sie die Quelle. Bewahren Sie die .puml Text zusammen mit der Projektdokumentation oder in der Versionsverwaltung. Exportieren Sie bei Bedarf ein Bild für Dokumente oder Präsentationen.

Beispiel-Prompt für KI-Unterstützung

Erstellen Sie ein UML-Anwendungsfalldiagramm in PlantUML für einen Online-Shop. Fügen Sie eine Systemgrenze, Akteure „Kunde” und „Administrator” sowie die Ziele „Produkte durchsuchen”, „Bestellung aufgeben

Betrachten Sie KI-generierten Code als einen ersten Entwurf. Überprüfen Sie die Akteure, Grenzen, Beziehungen und geschäftlichen Annahmen, bevor Sie ihn verwenden.

9. Häufige Fallstricke

• Interne Komponenten als Akteure modellieren:Akteure sollten externe Rollen oder Systeme sein, die mit dem Subjekt interagieren.

• Anwendungsfälle als Implementierungsaufgaben benennen:Bevorzugen Sie „Versand verfolgen” gegenüber „Tracking-API aufrufen.”

• Verwenden von <<include>> für optionales Verhalten:Include stellt das Verhalten dar, das der Basisanwendungskasus erfordert.

• Umkehren von Beziehungs-Pfeilen:Include zeigt auf den eingeschlossenen Anwendungskasus; Extend zeigt auf den Basisanwendungskasus.

• Ein Diagramm mit Details überladen:Verwenden Sie ein Diagramm auf hoher Ebene für den Geltungsbereich und anschließend separate Diagramme oder Texte für detaillierte Szenarien.

• Davon ausgehen, dass eine erfolgreiche Darstellung bedeutet, dass das Modell korrekt ist:PlantUML kann ein Diagramm rendern, das die Anforderungen dennoch falsch darstellt.

10. Überprüfungsliste

Bestätigen Sie vor dem Teilen des Diagramms Folgendes:

• Die Systemgrenze ist klar.

• Jeder Akteur ist extern und stellt eine Rolle dar.

• Die Namen der Anwendungsfälle beschreiben sinnvolle Ziele.

• Akteur-Assoziationen spiegeln tatsächliche Interaktionen wider.

• Include-Beziehungen sind erforderlich; Extend-Beziehungen sind bedingt oder anderweitig begründet.

• Verallgemeinerungspfeile zeigen auf den allgemeinen Akteur oder Anwendungskasus.

• Das Diagramm bleibt in der beabsichtigten Größe lesbar.

• KI-generierte Annahmen wurden mit Personen überprüft, die mit den Anforderungen vertraut sind.

Der Artikel ist auch in English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam and 繁體中文 verfügbar.