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

Modellierung von realen Anforderungen mit UML – Ein praktischer Leitfaden

---

1. Einleitung

In der modernen Softwareentwicklung Use-Case-Diagramme sind ein grundlegendes Werkzeug zur Erfassung funktionaler Anforderungen aus Sicht des Benutzers. Diese Fallstudie präsentiert eine detaillierte Analyse eines realistischen Use-Case-Diagramms für eine Food-Delivery-Plattform, unter Verwendung von PlantUML-Syntax als Modellierungssprache. Ziel ist es, nicht nur welche Elemente im Diagramm verwendet werden, sondern auch warum sie ausgewählt werden – unterstreicht praktische Modellierungsentscheidungen, Konventionen, und häufige Fehlerquellen.

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

---

2. Systemübersicht

Die Food-Delivery-Plattform ist eine digitale Marktplattform, die verbindet:

• Kunden (Personen, die Essen bestellen),

• Restaurants (Anbieter von Mahlzeiten),

• Fahrer (Lieferpersonal),

• Externe Zahlungsgateways (Drittanbietersysteme, die Transaktionen verarbeiten).

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

PlantUML-Code:

@startuml
skinparam monochrome true
skinparam shadowing false

von links nach rechts Richtung

‘ Alle Akteure sind außerhalb des Rechtecks definiert
aktor Kunde
aktor „Registrierter Kunde“ als RegKunde
aktor „Restaurantpersonal“ als Restaurant
aktor Fahrer
aktor „Zahlungsprozessor“ als Zahlungsgateway

Rechteck „Essen-Lieferplattform“ {

(Restaurants durchsuchen)
(Bestellung aufgeben)
(Bestellung verfolgen)
(Menu verwalten)
(Bestellung akzeptieren / vorbereiten)
(Bestellung liefern)
(Zahlung verarbeiten)
(Rückerstattung ausstellen)
(Promocode anwenden)
(Wallet verwenden)
(Kartenzahlung)
(Zahlung per Digitales Wallet)

‘ Assoziationen – Pfeile überschreiten die Grenze
Kunde –> (Restaurants durchsuchen)
Registrierter Kunde –> (Bestellung aufgeben)
Registrierter Kunde –> (Bestellung verfolgen)

Restaurant –> (Menü verwalten)
Restaurant –> (Bestellung annehmen / vorbereiten)

Fahrer –> (Bestellung ausliefern)

Zahlungsgateway –> (Zahlung verarbeiten)
Zahlungsgateway –> (Rückerstattung ausstellen)

‘ einbinden
(Bestellung aufgeben) ..> (Zahlung verarbeiten) : <<einbinden>>

‘ erweitern
(Bestellung aufgeben) <.. (Promocode anwenden) : <<erweitern>>
(Zahlung verarbeiten) <.. (Wallet verwenden) : <<erweitern>>

‘ Verallgemeinerung
(Zahlung verarbeiten) <|– (Kartenzahlung)
(Zahlung verarbeiten) <|– (Zahlung per Digitales Wallet)
}

‘ Akteur-Verallgemeinerung (auch außerhalb)
Kunde <|– Registrierter Kunde

Hinweis rechts von Zahlungsgateway
Externes Zahlungsgateway
(Stripe, PayPal, Adyen, …)
Ende Hinweis

Hinweis unten bei (Promocode anwenden)
Optional – nur wenn ein gültiger Code eingegeben wird
Ende der Notiz

@enduml

✅ Wichtiger Einblick: Das Diagramm konzentriert sich auf externe Interaktionen — es zeigt, was das System tutfü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 Modellierungslogik.

#	Element	Notation	Bedeutung & Zweck	Modellierungsentscheidung / Kommentar
1	Systemgrenze	Rechteck "Food Delivery Platform"	Definiert die Umfangdes zu modellierenden Systems. Alle Use Cases innerhalb gehören zu diesem System.	Der Name ist prägnant, aber beschreibend. In unternehmensweiten Kontexten können längere Namen (z. B. „Kundenbestellungs-Management-System“) verwendet werden.
2	Primärer menschlicher Akteur	Akteur Kunde, Akteur Fahrer	Stellt dar externe Rollendie Use Cases initiieren oder darin teilnehmen.	Namen sind einfach und intuitiv. Vermeidet unnötige Stereotypen wie<<Person>>es sei denn, es ist für große Modelle erforderlich.
3	Aktionsfigur mit Alias	Aktionsfigur "Restaurantpersonal" als Restaurant	Ermöglicht es, einen längeren, beschreibenden Akteurnamen für Klarheit bei Verbindungen zu verkürzen.	Sehr effektiv, wenn Akteurnamen Leerzeichen enthalten oder ausführlich sind. Reduziert Unordnung und verbessert die Lesbarkeit.
4	Externe Systemaktionsfigur	Aktionsfigur "Zahlungsprozessor" als PaymentGW	ModelliertDrittsystememit denen die Plattform interagiert.	Kein Stereotyp«System»wird verwendet – akzeptabel in leichtgewichtigen Diagrammen. Allerdings kann das Hinzufügen«System»die Absicht in komplexen Systemen klären.
5	Aktionsfigur-Verallgemeinerung	`Kunde <	— RegKunde`	Zeigt an, dass einregistrierter Kundeeine spezialisierte Version einesGastkunden.
6	Gewöhnliche Assoziation	Kunde --> (Restaurants durchsuchen)	Zeigt an, dass der Akteurinitiiertodernimmt teil andem Use Case.	Solide Linie = Kommunikation. Die Richtung wird von Akteur zu Use Case impliziert (Pfeilspitze nicht erforderlich).
7	«include»-Beziehung	(Bestellung aufgeben) ..> (Zahlung verarbeiten) : <<include>>	Zahlung verarbeitenistimmer erforderlichbeim Aufgeben einer Bestellung.	Pfeil zeigtvon inkludierend → inkludiert. Dies ist entscheidend:Bestellung aufgeben schließt ein Zahlung verarbeitenals obligatorischen Schritt.
8	«extend»-Beziehung	(Bestellung aufgeben) <.. (Promo-Code anwenden) : <<extend>>	Die Anwendung eines Promo-Codes istoptionalund erfolgt nur unter bestimmten Bedingungen.	Pfeil zeigtvon Erweiterung → Basis. Der Basis-Anwendungsfall (Bestellung aufgeben) kann erweitert werden bedingt.
9	Anwendungsfall-Verallgemeinerung	`(Zahlung verarbeiten) <	— (Kartenzahlung)<br>(Zahlung verarbeiten) <	— (Digitale Brieftasche-Zahlung)`
10	Hinweis	Hinweis rechts von PaymentGW Hinweis unten bei (Promo-Code anwenden)	Bietet kontextuelle Erklärung zu Implementierung oder Geschäftsregeln.	Hinweise werden unterschätzt, aber äußerst wertvoll. Sie verhindern Missverständnisse (z. B. die Klärung, dass PaymentGW extern ist).
11	Akteure außerhalb der Grenze	Alle Akteur Deklarationen precedieren das Rechteck	Betont, dass kein Akteur Teil des Systems ist — klare Trennung der Verantwortlichkeiten.	Eine von zwei Standardlayouts. Bevorzugt, wenn Akteure zahlreich oder extern sind.
12	Diagrammrichtung	von links nach rechts	Verbessert die Anordnung, wenn mehrere Akteure auf der linken Seite stehen.	Erhöht die Lesbarkeit. Besonders wirksam bei 4–8 Akteuren. Alternativ: Top-down-Layout bei weniger Akteuren.

---

4. Wichtige Modellierungsentscheidungen und Begründungen

✅ Warum Akteure außerhalb der Systemgrenze liegen

• Best Practice: Akteure repräsentieren Rollenaußerhalbdes Systems.

• Warum es wichtig ist: Verhindert Verwirrung zwischen Systemkomponenten und externen Entitäten.

• Beispiel: Fahrerist kein Modul der Plattform – sie sind eine externe Rolle, die mit ihr interagiert.

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

---

✅ Warum verwendenKunde <|-- RegKundeanstatt Links zu duplizieren

• Ohne Verallgemeinerung müsstest du zeichnen:

  Kunde --> (Restaurants durchsuchen)
  RegKunde --> (Restaurants durchsuchen)
  RegKunde --> (Bestellung aufgeben)
  

• Mit Verallgemeinerung brauchst du nur:

  Kunde <|-- RegKunde
  Kunde --> (Restaurants durchsuchen)
  RegKunde --> (Bestellung aufgeben)
  

• Ergebnis: Sauberer, wartbarer Diagramm.

📌 Beste Praxis: Verwenden Sie die Aktorgeneralisierung, wenn ein spezialisierter Aktor alle Verhaltensweisen eines allgemeineren erbt.

---

✅ Warum <<einschließen>> und <<erweitern>> werden korrekt verwendet

Beziehung	Zweck	Richtung	Beispiel
<<einschließen>>	Pflichtunterfluss	Von einschließlich → eingeschlossen	Bestellung aufgeben muss einschließen Zahlung verarbeiten
<<erweitern>>	Optionale Erweiterung	Von Erweiterung → Basis	Promo-Code anwenden erweitert Bestellung aufgebennur wenn der Code gültig ist

❗ Häufiger Fehler: Pfeilrichtung umkehren. Vergiss nie:

• enthält: Basis ..> Enthaltene

• erweitern: Erweiterung <.. Basis

---

✅ Warum Zahlung verarbeitenhat Generalisierungen

• KartenzahlungundZahlung über digitale Brieftaschesindspezialisierte FormenvonZahlung verarbeiten.

• Dies zeigt, dass die Plattform unterstütztmehrere Zahlungsmethoden, aber sie folgen alle dem gleichen Kernprozess.

• Generalisierung ermöglichtgeteiltes Verhalten und zukünftige Erweiterbarkeit.

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

---

5. Realweltdarstellungen und beantwortete Fragen

Dieses Diagramm ist nicht nur eine visuelle Hilfsmittel — es beantwortet kritische geschäftliche und technische Fragen:

Frage	Antwort aus Diagramm
Wer sind die Hauptnutzer?	Kunden, Registrierte Kunden, Restaurantangestellte, Fahrer, Zahlungsgateway
Können nicht registrierte Benutzer Bestellungen aufgeben?	❌ Nein — nur RegKunde kann Bestellung aufgeben. Kunde kann nur Restaurants durchsuchen.
Wird die Zahlung immer benötigt?	✅ Ja — Bestellung aufgeben enthält Zahlung verarbeiten. Pflichtfeld.
Können Kunden Rabattcodes anwenden?	✅ Ja — aber nur wahlweise über <<erweitern>>. Nur, wenn ein gültiger Code eingegeben wird.
Welche Zahlungsmethoden werden unterstützt?	Karte und Digitale Brieftasche (über Verallgemeinerung). Das externe System führt die eigentliche Verarbeitung durch.
Wer bearbeitet die Zahlung?	Extern PaymentGW — kein Bestandteil der Plattform.
Können Restaurants ihre Menüs verwalten?	✅ Ja — Restaurant Aktionspartner interagiert mit Menü verwalten und Bestellung annehmen / vorbereiten.

✅ Geschäftswert: Das Diagramm vermittelt eindeutig was das System tut, wer es nutzt, und welche Verhaltensweisen obligatorisch sind im Gegensatz zu wahlweise.

---

6. Gemeinsame Modellierungsrichtlinien veranschaulicht

Das Diagramm veranschaulicht mehrere Best Practices in der UML-Nutzungsfalldiagrammierung:

Richtlinie	Wie es angewendet wird
Verwenden Sie zielorientierte Nutzungsfalldenbezeichnungen	Bestellung aufgeben, Bestellung verfolgen, Promo-Code anwenden — alle beginnen mit einem Verb und beschreiben ein Benutzerziel.
Halten Sie das Diagramm lesbar	Nur 10 Nutzungsfälle werden angezeigt — ideal für die meisten Geschäftsbereiche (5–12 wird empfohlen).
Externe Systeme als Akteure	PaymentGW wird als Akteur, nicht als Nutzungsfall modelliert. Trennt korrekt die Verantwortlichkeiten.
Verwenden Sie Notizen, um Unklarheiten zu klären	Notizen erklären, dass PaymentGW extern ist und dass der Promo-Code optional ist — entscheidend, um Missverständnisse zu vermeiden.
Verwenden Sie die Akteur-Verallgemeinerung, um Unordnung zu reduzieren	`Kunde <
Verwenden Sie include und extend korrekt	Klare Unterscheidung zwischen obligatorischem und optionalem Verhalten.

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

---

7. Potenzielle Verbesserungen und Kritik

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

🔧 1. Stereotypen zur Klarheit hinzufügen

Aktivität "Zahlungsprozessor" als PaymentGW <<System>>

• Warum: Macht deutlich, dass es sich um ein externes System handelt, kein menschliche Rolle.

• Vorteil: Verringert Mehrdeutigkeit, besonders in großen Modellen.

🔧 2. Klärung Gutscheincode anwenden Erweiterungsbedingung

Derzeit:

Anmerkung unten von (Gutscheincode anwenden)
  Optional – nur wenn ein gültiger Code eingegeben wird
Ende Anmerkung

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

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

• Warum: Genauer als eine Notiz — verbindet die Erweiterung direkt mit einer Bedingung.

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

• Derzeit fehlend, aber wahrscheinlich wichtig für Kunden und Restaurants.

• Könnte als eine RegKunde Anwendungsfall.

🔧 4. Verwandte Anwendungsfälle gruppieren (optional)

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

Paket "Bestellverwaltung" {
    (Bestellung aufgeben)
    (Bestellung verfolgen)
    (Promo-Code anwenden)
}
Paket "Zahlung" {
    (Zahlung verarbeiten)
    (Wallet verwenden)
    (Kartenzahlung)
    (Digitale Wallet-Zahlung)
}

• Vorteil: Verbessert Skalierbarkeit und Lesbarkeit.

---

8. Was kommt als Nächstes?

Diese Fallstudie hat gezeigt, wie ein gut strukturierter Anwendungsfalldiagramm komplexe 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:

• Fokussieren Sie auf Menü verwalten, Bestellung annehmen / vorbereiten, Bestellungen anzeigen, Status aktualisieren.

• Zeigen Sie Restaurant als primären Akteur.

• Schließen Sie Kunde als sekundären Akteur (z. B. Kunde sendet Bestellung → Restaurant empfängt sie).

✅ Vorteil: Zeigt verschiedene Systemziele und Akteurrollen auf.

🔄 Option 2: Weitere Erweiterungspunkte hinzufügen

Verbessern Sie Bestellung aufgeben mit:

• Gutschein anwenden (wenn Promo-Code ungültig ist → <<erweitern>> mit Fehlermeldung)

• Spezielle Anweisungen anfordern (optional)

• Bestellung planen (für spätere Lieferung)

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

Anwendungsfall	<<enthalten>>	<<erweitern>>
Bestellung aufgeben → Zahlung verarbeiten	✅ Pflichtfeld	❌ Nicht optional
Bestellung aufgeben → Promo-Code anwenden	❌ Nicht verpflichtend	✅ Bedingt
Anmelden → Identität überprüfen	✅ Immer erforderlich	❌ Nicht anwendbar
Zur Kasse gehen → Rabatt anwenden	✅ Immer	✅ Nur wenn ein Rabatt vorhanden ist

📌 Richtlinie:

• Verwenden Sie <<einbeziehen>> wenn das Verhalten muss erfolgen.

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

🔄 Option 4: Konvertieren in Sequenz- oder Aktivitätsdiagramme

Für eine tiefere Analyse:

• Sequenzdiagramm: Zeigt den Ablauf von Bestellung aufgeben → Zahlung verarbeiten → Bestellung ausliefern 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. Fazit

Diese Fallstudie zeigt, dass ein gut gestaltetes Use-Case-Diagramm ist weitaus mehr als ein visuelles Skizze — es ist ein strategisches Kommunikationsinstrument das:

• klärt den Systemumfang,

• erfasst Geschäftsregeln,

• leitet die Entwicklung an,

• verhindert Missverständnisse.

Das Food Delivery Platform Diagramm ist ein starkes Beispiel von:

• angemessener Einsatz der UML-Notation,

• gute Modellierungsentscheidungen,

• klare Trennung der Anliegen,

• effektiver Einsatz von Notizen und Generalisierungen.

Durch die Einhaltung der hier gezeigten Prinzipien — zielorientierte Benennung, angemessener Einsatz von include/erweitern, Aktoren-Verallgemeinerung, und strategischer Einsatz von Notizen — Sie können Use-Case-Diagramme erstellen, die sowohl genauund umsetzbar.

---

✅ Endgültige Erkenntnisse

Prinzip	Hier angewendet?	Warum es wichtig ist
Verwenden Sie zielorientierte Use-Case-Namen	✅ Ja	Verbessert Klarheit und Benutzerfokus
Halten Sie die Diagrammgröße überschaubar	✅ Ja (10 Use Cases)	Verhindert kognitive Überlastung
Externe Systeme als Akteure	✅ Ja	Richtige Trennung der Anliegen
Verwenden Sie Notizen für Kontext	✅ Ja	Verhindert Missverständnisse
Verwenden Sie Verallgemeinerung, um Redundanz zu reduzieren	✅ Ja	Macht das Diagramm skalierbar und wartbar
Richtig <<einbeziehen>> und <<erweitern>> Richtung	✅ Ja	Stellt eine genaue Verhaltensmodellierung sicher

---