Fallstudie: Use-Case-Diagramm für eine Food-Delivery-Plattform

Modellierung realer Anforderungen mit UML – Ein praktischer Leitfaden

1. Einleitung

In der modernen SoftwareentwicklungUse-Case-Diagramme sind ein grundlegendes Werkzeug zur Erfassung funktionaler Anforderungen aus Sicht des Benutzers. Diese Fallstudie präsentiert eine detaillierte Analyse einesrealistischen Use-Case-Diagramms für eineFood-Delivery-Plattform, unter Verwendung vonPlantUML-Syntax als Modellierungssprache. Ziel ist es, nicht nur zu zeigen, welchewelcheElemente im Diagramm verwendet werden, sondern auchwarum sie gewählt werden – wobeipraktische Modellierungsentscheidungen, Konventionen, sowiehäufige Fallstricke.

Diese Fallstudie richtet sich sowohl anAnfänger, die UML lernen als auch anPraktiker, die ihre Modellierungspraktiken verfeinern. Sie analysiert jedes Element des Diagramms, erläutert dessen Zweck und diskutiert praktische Implikationen.

2. Systemübersicht

DieFood-Delivery-Plattform ist eine digitale Marktplattform, die verbindet:

• Kunden (Einzelpersonen, die Essen bestellen),
• Restaurants (Anbieter von Mahlzeiten),
• Fahrer (Lieferpersonal),
• Externe Zahlungsgateways (Drittsysteme, die Transaktionen verarbeiten).

Die Plattform ermöglicht es Benutzern, Restaurants zu durchsuchen, Bestellungen aufzugeben, Lieferungen zu verfolgen, Zahlungen zu verwalten und Angebote anzuwenden. Das System integriert sich mit externen Diensten wie Zahlungsprozessoren und verarbeitet keine Zahlungslogik intern.

PlantUML-Code:

@startuml
skinparam monochrome true
skinparam shadowing false

left to right direction

' Alle Akteure sind außerhalb des Rechtecks definiert
actor Kunde
actor "Registrierter Kunde" als RegKunde
actor "Restaurant-Mitarbeiter" als Restaurant
actor Fahrer
actor "Zahlungsprozessor" als ZahlungsGW

rechteck "Essen-Lieferplattform" {

(Restaurants durchsuchen)
(Bestellung aufgeben)
(Bestellung verfolgen)
(Menu verwalten)
(Bestellung akzeptieren / vorbereiten)
(Bestellung liefern)
(Zahlung verarbeiten)
(Rückerstattung ausstellen)
(Pro-Motion-Code anwenden)
(Geldbörse nutzen)
(Kartenzahlung)
(Digitale Geldbörse Zahlung)

' Assoziationen – Pfeile kreuzen die Grenze
Kunde --> (Restaurants durchsuchen)
RegKunde --> (Bestellung aufgeben)
RegKunde --> (Bestellung verfolgen)

Restaurant --> (Menu verwalten)
Restaurant --> (Bestellung akzeptieren / vorbereiten)

Fahrer --> (Bestellung liefern)

ZahlungsGW --> (Zahlung verarbeiten)
ZahlungsGW --> (Rückerstattung ausstellen)

' include
(Bestellung aufgeben) ..> (Zahlung verarbeiten) : <<include>>

' extend
(Bestellung aufgeben) <.. (Pro-Motion-Code anwenden) : <<extend>>
(Zahlung verarbeiten) <.. (Geldbörse nutzen) : <<extend>>

' Generalisierung
(Zahlung verarbeiten) <|-- (Kartenzahlung)
(Zahlung verarbeiten) <|-- (Digitale Geldbörse Zahlung)
}

' Akteur-Vererbung (auch außerhalb)
Kunde <|-- RegKunde

notiz rechts von ZahlungsGW
Externer Zahlungsgateway
(Stripe, PayPal, Adyen, ...)
ende notiz

notiz unten von (Pro-Motion-Code anwenden)
Optional – nur wenn ein gültiger Code eingegeben wird
ende notiz

@enduml

✅ Wichtiger Erkenntnis: Das Diagramm konzentriert sich aufexterne Interaktionen — es zeigt, was das Systemtutfür seine Benutzer und Systeme tut, nicht wie es implementiert ist.

3. Diagrammelemente: Tiefgang mit praktischer Bedeutung

Unten finden Sie eine umfassende Aufschlüsselung jedes in dem Diagramm verwendeten UML-Elements zusammen mit einer realen Interpretation und der Modellierungsgrundlage.

4. Wichtige Modellierungsentscheidungen und Begründungen

✅ Warum Akteure außerhalb der Systemgrenze liegen

• Best Practice: Akteure stellen Rollen daraußerhalb des Systems.
• Warum es wichtig ist: Verhindert Verwirrung zwischen Systemkomponenten und externen Entitäten.
• Beispiel: Treiber ist kein Modul der Plattform – sie sind eine Drittpartei, die mit ihr interagiert.

📌 Pro-Tipp: Wenn alle Akteure innerhalb der Grenze wären, würde das bedeuten, dass das System sie enthält – was irreführend ist.

✅ Warum verwenden Kunde <|-- RegKunde anstelle von doppelten Verbindungen

• Ohne Verallgemeinerung müsstest du zeichnen:
  Plantuml
  
  
  Plantuml in VPasCode bearbeiten
  

  Plantuml Edit Plantuml in VPasCode

  Kunde --> (Restaurants durchsuchen)
  RegKunde --> (Restaurants durchsuchen)
  RegKunde --> (Bestellen)
  

  Edit Plantuml in VPasCode

  
  
  Plantuml in VPasCode bearbeiten
  
• Mit Verallgemeinerung brauchst du nur:
  Plantuml
  
  
  Plantuml in VPasCode bearbeiten
  

  Plantuml Edit Plantuml in VPasCode

  Kunde <|-- RegKunde
  Kunde --> (Restaurants durchsuchen)
  RegKunde --> (Bestellen)
  

  Edit Plantuml in VPasCode

  
  
  Plantuml in VPasCode bearbeiten
  
• Ergebnis: Übersichtlicheres, wartungsfreundlicheres Diagramm.

📌 Beste Praxis: Verwende Akteur-Verallgemeinerung, wenn ein spezialisierter Akteur alle Verhaltensweisen eines allgemeineren erbt.

✅ Warum <<include>> und <<extend>> werden korrekt verwendet

❗ Häufiger Fehler: Umkehren der Pfeilrichtung. Vergiss nie:

• einbeziehen: Basis ..> Eingeschlossen
• erweitern: Erweiterung <.. Basis

✅ Warum Zahlung verarbeiten hat Verallgemeinerungen

• Kartenzahlung und Zahlung per Digitales Brieftasche sind spezialisierte Formen von Zahlung verarbeiten.
• Dies zeigt, dass die Plattform mehrere Zahlungsmethoden, aber sie folgen alle dem gleichen Kernablauf.
• Verallgemeinerung ermöglicht geteiltes Verhalten und zukünftige Erweiterbarkeit.

📌 Anwendungsfall: Das Hinzufügen einer neuen Zahlungsmethode (z. B. Apple Pay) wäre einfach eine weitere Verallgemeinerung von Zahlung verarbeiten.

5. Interpretationen aus der Praxis & beantwortete Fragen

Dieses Diagramm ist nicht nur eine visuelle Hilfestellung – es beantwortet entscheidende geschäftliche und technische Fragen:

✅ Geschäftswert: Das Diagramm kommuniziert klar was das System tut, wer es nutzt, und welche Verhaltensweisen obligatorisch sind und welche optional sind.

6. Gebräuchliche Modellierungsrichtlinien veranschaulicht

Das Diagramm veranschaulicht mehrere Best-Practices bei der UML-Nutzungsfallmodellierung:

📌 Warnung: Viele Diagramme missbrauchen <<extend>> um „optional“ zu bedeuten, ohne die bedingte Natur von Erweiterungen zu verstehen. Dieses Diagramm vermeidet diesen Fehler.

7. Mögliche Verbesserungen und Kritik

Obwohl das Diagramm stark ist, hier sind konstruktive Vorschläge zur Verbesserung:

🔧 1. Stereotypen zur Klarheit hinzufügen

actor "Zahlungsprozessor" als PaymentGW <<system>>

• Warum: Macht deutlich, dass es sich um ein externes System handelt, kein menschlicher Rollen.
• Vorteil: Verringert die Mehrdeutigkeit, insbesondere bei großen Modellen.

🔧 2. Klären Sie Gutscheincode anwendenErweiterungsbedingung

Derzeit:

note unten von (Gutscheincode anwenden)
  Optional – nur wenn ein gültiger Code eingegeben wurde
ende note

• Besser: Verwenden Sie eine Bedingungsnotation oder Guard in der <<erweitern>> Pfeil:

(Bestellung aufgeben) <.. (Promo-Code anwenden) : <<erweitern>> [gültiger Promo-Code]rn

• Warum: Genauer als eine Notiz — verknüpft die Erweiterung direkt mit einer Bedingung.

🔧 3. Berücksichtigen Sie die Hinzufügung einer Bestellverlauf anzeigen Nutzungsfall

• Derzeit fehlend, aber wahrscheinlich wichtig für Kunden und Restaurants.
• Könnte als eine RegKunde Nutzungsfall.

🔧 4. Verwandte Nutzungsfälle gruppieren (optional)

Bei größeren Diagrammen können Nutzungsfälle in Pakete:

package "Bestellverwaltung" {rn    (Bestellung aufgeben)rn    (Bestellung verfolgen)rn    (Promo-Code anwenden)rn}rnpackage "Zahlung" {rn    (Zahlung verarbeiten)rn    (Geldbörse verwenden)rn    (Kartenzahlung)rn    (Digitale Geldbörse Zahlung)rn}rn

• Vorteil: Verbessert Skalierbarkeit und Lesbarkeit.

8. Was kommt als Nächstes?

Diese Fallstudie hat gezeigt, wie ein gut strukturiertes Nutzungsfall-Diagrammkomplexe Geschäftslogik klar und präzise erfassen kann. Um Ihr Verständnis zu vertiefen, hier vorgeschlagene nächste Schritte:

🔄 Option 1: Restaurantzentrierte Ansicht

Modellieren Sie dasselbe Domäne von der Perspektive des Restaurants:

• Fokus auf Menü verwalten, Bestellung annehmen / vorbereiten, Bestellungen anzeigen, Status aktualisieren.
• Zeigen Sie Restaurant als primärer Akteur.
• Einschließen Kunde als sekundärer Akteur (z. B. Kunde sendet Bestellung → Restaurant erhält sie).

✅ Vorteil: Zeigt unterschiedliche Systemziele und Akteurrollen auf.

🔄 Option 2: Weitere Erweiterungspunkte hinzufügen

Verbessern Sie Bestellung aufgeben mit:

• Gutschein anwenden (falls Promo-Code ungültig ist → <<erweitern>> mit Fehlermeldung)
• Sonderanweisungen anfordern (optional)
• Bestellung planen (für spätere Lieferung)

🔄 Option 3: Vergleichen enthalten gegenüber erweitern mit Beispielen

📌 Richtlinie:

• Verwenden Sie <<einbeziehen>> wenn das Verhalten eintreten muss.
• Verwenden Sie <<erweitern>> wenn das Verhalten eintreten könnte unter bestimmten Bedingungen.

🔄 Option 4: In Sequenz- oder Aktivitätsdiagramme umwandeln

Für eine tiefere Analyse:

• Sequenzdiagramm: Zeigt den Ablauf von Bestellung aufgeben → Zahlung verarbeiten → Bestellung liefern mit Nachrichten zwischen Akteuren und System.
• Aktivitätsdiagramm: Modellieren Sie die Entscheidungspunkte in Zahlung verarbeiten (z. B. Karte abgelehnt → erneut versuchen oder auf Wallet wechseln).

9. Schlussfolgerung

Diese Fallstudie zeigt, dass ein gut gestaltetes Use-Case-Diagrammist weitaus mehr als eine visuelle Skizze – es ist ein strategisches Kommunikationsinstrument das:

• klärt den Systemumfang,
• erfasst Geschäftsregeln,
• leitet die Entwicklung an,
• verhindert Missverständnisse.

Das Food-Delivery-PlattformDiagramm ist ein starkes Beispielfür:

• angemessene Verwendung der UML-Notation,
• gute Modellierungsentscheidungen,
• klare Trennung der Anliegen,
• effektive Verwendung von Notizen und Generalisierungen.

Durch die Einhaltung der hier gezeigten Prinzipien –zielorientierte Benennung, korrekte Verwendung von einbeziehen/erweitern, Aktorgeneralisierung, und strategischer Einsatz von Notizen — Sie können Use-Case-Diagramme erstellen, die sowohl genau als auch umsetzbar.

✅ Endgültige Erkenntnisse