Case Study: Use Case Diagram for a Food Delivery Platform - Go 2 Posts

Modeling Real-World Requirements with UML – A Practical Guide

1. Introduction

In modern software development, use case diagrams are a foundational tool for capturing functional requirements from a user’s perspective. This case study presents a detailed analysis of a realistic use case diagram for a Food Delivery Platform, using PlantUML syntax as the modeling language. The goal is to demonstrate not only what elements are used in the diagram, but also why they are chosen — highlighting practical modeling decisions, conventions, and common pitfalls.

This case study serves both beginners learning UML and practitioners refining their modeling practices. It breaks down every element of the diagram, explains its purpose, and discusses real-world implications.

2. System Overview

The Food Delivery Platform is a digital marketplace connecting:

Customers (individuals ordering food),
Restaurants (providers of meals),
Drivers (delivery personnel),
External Payment Gateways (third-party systems handling transactions).

The platform enables users to browse restaurants, place orders, track deliveries, manage payments, and apply promotions. The system integrates with external services like payment processors and does not handle payment logic internally.

PlantUML Code:

@startuml
skinparam monochrome true
skinparam shadowing false

left to right direction

‘ All actors are defined outside the rectangle
actor Customer
actor “Registered Customer” as RegCustomer
actor “Restaurant Staff” as Restaurant
actor Driver
actor “Payment Processor” as PaymentGW

rectangle “Food Delivery Platform” {

(Browse Restaurants)
(Place Order)
(Track Order)
(Manage Menu)
(Accept / Prepare Order)
(Deliver Order)
(Process Payment)
(Issue Refund)
(Apply Promo Code)
(Use Wallet)
(Card Payment)
(Digital Wallet Payment)

‘ Associations – arrows cross the boundary
Customer –> (Browse Restaurants)
RegCustomer –> (Place Order)
RegCustomer –> (Track Order)

Restaurant –> (Manage Menu)
Restaurant –> (Accept / Prepare Order)

Driver –> (Deliver Order)

PaymentGW –> (Process Payment)
PaymentGW –> (Issue Refund)

‘ include
(Place Order) ..> (Process Payment) : <<include>>

‘ extend
(Place Order) <.. (Apply Promo Code) : <<extend>>
(Process Payment) <.. (Use Wallet) : <<extend>>

‘ generalization
(Process Payment) <|– (Card Payment)
(Process Payment) <|– (Digital Wallet Payment)
}

‘ Actor generalization (also outside)
Customer <|– RegCustomer

note right of PaymentGW
External payment gateway
(Stripe, PayPal, Adyen, …)
end note

note bottom of (Apply Promo Code)
Optional – only when a valid code is entered
end note

@enduml

✅ Key Insight: The diagram focuses on external interactions — it shows what the system does for its users and systems, not how it’s implemented.

3. Diagram Elements: Deep Dive with Practical Meaning

Below is a comprehensive breakdown of each UML element used in the diagram, along with real-world interpretation and modeling rationale.

#	Element	Notation	Meaning & Purpose	Modeling Decision / Comment
1	System Boundary	`rectangle "Food Delivery Platform"`	Defines the scope of the system being modeled. All use cases inside are part of this system.	The name is concise yet descriptive. In enterprise contexts, longer names (e.g., “Customer Order Management System”) may be used.
2	Primary Human Actor	`actor Customer`, `actor Driver`	Represents external roles that initiate or participate in use cases.	Names are simple and intuitive. Avoids unnecessary stereotypes like `<<person>>` unless required for large models.
3	Actor with Alias	`actor "Restaurant Staff" as Restaurant`	Allows a longer, descriptive actor name to be shortened for clarity in connections.	Highly effective when actor names contain spaces or are verbose. Reduces clutter and improves readability.
4	External System Actor	`actor "Payment Processor" as PaymentGW`	Models third-party systems the platform interacts with.	No stereotype `«system»` is used — acceptable in lightweight diagrams. However, adding `«system»` can clarify intent in complex systems.
5	Actor Generalization	`Customer <	— RegCustomer`	Indicates that a registered customer is a specialized version of a guest customer.
6	Ordinary Association	`Customer --> (Browse Restaurants)`	Shows that the actor initiates or participates in the use case.	Solid line = communication. Direction is implied from actor to use case (no arrowhead needed).
7	«include» Relationship	`(Place Order) ..> (Process Payment) : <<include>>`	`Process Payment` is always required when placing an order.	Arrow points from including → included. This is critical: `Place Order` includes `Process Payment` as a mandatory step.
8	«extend» Relationship	`(Place Order) <.. (Apply Promo Code) : <<extend>>`	Applying a promo code is optional and only happens under certain conditions.	Arrow points from extension → base. The base use case (`Place Order`) can be extended conditionally.
9	Use Case Generalization	`(Process Payment) <	— (Card Payment)`<br>`(Process Payment) <	— (Digital Wallet Payment)`
10	Note	`note right of PaymentGW` `note bottom of (Apply Promo Code)`	Provides contextual explanation about implementation or business rules.	Notes are underused but extremely valuable. They prevent misinterpretation (e.g., clarifying that PaymentGW is external).
11	Actors Outside Boundary	All `actor` declarations precede the rectangle	Emphasizes that no actor is part of the system — clear separation of concerns.	One of two standard layouts. Preferred when actors are numerous or external.
12	Diagram Direction	`left to right direction`	Improves layout when multiple actors are on the left.	Enhances readability. Especially effective with 4–8 actors. Alternative: top-down layout for fewer actors.

4. Key Modeling Decisions & Rationale

✅ Why actors are outside the system boundary

Best practice: Actors represent roles outside the system.
Why it matters: Prevents confusion between system components and external entities.
Example: Driver is not a module of the platform — they are a third-party role interacting with it.

📌 Pro Tip: If all actors were inside the boundary, it would imply the system includes them — which is misleading.

✅ Why use `Customer <|-- RegCustomer` instead of duplicating links

Without generalization, you’d have to draw:

Customer --> (Browse Restaurants)
RegCustomer --> (Browse Restaurants)
RegCustomer --> (Place Order)

With generalization, you only need:

Customer <|-- RegCustomer
Customer --> (Browse Restaurants)
RegCustomer --> (Place Order)

Result: Cleaner, more maintainable diagram.

📌 Best Practice: Use actor generalization whenever a specialized actor inherits all behaviors of a more general one.

✅ Why `<<include>>` and `<<extend>>` are used correctly

Relationship	Purpose	Direction	Example
`<<include>>`	Mandatory sub-flow	From including → included	`Place Order` must include `Process Payment`
`<<extend>>`	Optional extension	From extension → base	`Apply Promo Code` extends `Place Order` only if code is valid

❗ Common Mistake: Reversing the arrow direction. Always remember:

include: Base ..> Included

extend: Extension <.. Base

✅ Why `Process Payment` has generalizations

Card Payment and Digital Wallet Payment are specialized forms of Process Payment.
This shows that the platform supports multiple payment methods, but they all follow the same core flow.
Generalization allows for shared behavior and future extensibility.

📌 Use Case: Adding a new payment method (e.g., Apple Pay) would just be another generalization of Process Payment.

5. Real-World Interpretations & Questions Answered

This diagram is not just a visual aid — it answers critical business and technical questions:

Question	Answer from Diagram
Who are the main users?	Customers, Registered Customers, Restaurant Staff, Drivers, Payment Gateway
Can unregistered users place orders?	❌ No — only `RegCustomer` can `Place Order`. `Customer` can only `Browse Restaurants`.
Is payment always required?	✅ Yes — `Place Order` includes `Process Payment`. Mandatory.
Can customers apply promo codes?	✅ Yes — but only optionally via `<<extend>>`. Only if a valid code is entered.
What payment methods are supported?	Card and Digital Wallet (via generalization). External system handles actual processing.
Who handles payment?	External `PaymentGW` — not part of the platform.
Can restaurants manage their menus?	✅ Yes — `Restaurant` actor interacts with `Manage Menu` and `Accept / Prepare Order`.

✅ Business Value: The diagram clearly communicates what the system does, who uses it, and what behaviors are mandatory vs. optional.

6. Common Modeling Guidelines Demonstrated

The diagram exemplifies several best practices in UML use case modeling:

Guideline	How It’s Applied
Use goal-oriented use case names	`Place Order`, `Track Order`, `Apply Promo Code` — all start with a verb and describe a user goal.
Keep the diagram readable	Only 10 use cases are shown — ideal for most business domains (5–12 is recommended).
External systems as actors	`PaymentGW` is modeled as an actor, not a use case. Correctly separates concerns.
Use notes to clarify ambiguity	Notes explain that `PaymentGW` is external and that promo code is optional — critical for avoiding misinterpretation.
Use actor generalization to reduce clutter	`Customer <
Use `include` and `extend` correctly	Clear distinction between mandatory and optional behavior.

📌 Warning: Many diagrams misuse <<extend>> to mean “optional” without understanding the conditional nature of extensions. This diagram avoids that error.

7. Potential Improvements & Critique

While the diagram is strong, here are constructive suggestions for refinement:

🔧 1. Add Stereotypes for Clarity

actor "Payment Processor" as PaymentGW <<system>>

Why: Makes it explicit that this is an external system, not a human role.
Benefit: Reduces ambiguity, especially in large models.

🔧 2. Clarify `Apply Promo Code` Extension Condition

Currently:

note bottom of (Apply Promo Code)
  Optional – only when a valid code is entered
end note

Better: Use a condition notation or guard in the <<extend>> arrow:

(Place Order) <.. (Apply Promo Code) : <<extend>> [valid promo code]

Why: More precise than a note — directly ties the extension to a condition.

🔧 3. Consider Adding a `View Order History` Use Case

Currently missing, but likely important for both customers and restaurants.
Could be added as a RegCustomer use case.

🔧 4. Group Related Use Cases (Optional)

For larger diagrams, group use cases into packages:

package "Order Management" {
    (Place Order)
    (Track Order)
    (Apply Promo Code)
}
package "Payment" {
    (Process Payment)
    (Use Wallet)
    (Card Payment)
    (Digital Wallet Payment)
}

Benefit: Improves scalability and readability.

8. What’s Next?

This case study has shown how a well-structured use case diagram can capture complex business logic clearly and concisely. To deepen your understanding, here are suggested next steps:

🔄 Option 1: Restaurant-Centric View

Model the same domain from the restaurant’s perspective:

Focus on Manage Menu, Accept / Prepare Order, View Orders, Update Status.
Show Restaurant as primary actor.
Include Customer as a secondary actor (e.g., Customer sends order → Restaurant receives it).

✅ Benefit: Reveals different system goals and actor roles.

🔄 Option 2: Add More Extension Points

Enhance Place Order with:

Apply Coupon (if promo code is invalid → <<extend>> with error message)
Request Special Instructions (optional)
Schedule Order (for future delivery)

🔄 Option 3: Compare `include` vs `extend` with Examples

Use Case	`<<include>>`	`<<extend>>`
`Place Order` → `Process Payment`	✅ Mandatory	❌ Not optional
`Place Order` → `Apply Promo Code`	❌ Not mandatory	✅ Conditional
`Login` → `Verify Identity`	✅ Always needed	❌ Not applicable
`Check Out` → `Apply Discount`	✅ Always	✅ Only if discount exists

📌 Rule of Thumb:

Use <<include>> when the behavior must happen.

Use <<extend>> when the behavior might happen under certain conditions.

🔄 Option 4: Convert to Sequence or Activity Diagrams

For deeper analysis:

Sequence Diagram: Show the flow of Place Order → Process Payment → Deliver Order with messages between actors and system.
Activity Diagram: Model the decision points in Process Payment (e.g., card declined → retry or switch to wallet).

9. Conclusion

This case study demonstrates that a well-crafted use case diagram is far more than a visual sketch — it’s a strategic communication tool that:

Clarifies system scope,
Captures business rules,
Guides development,
Prevents misunderstandings.

The Food Delivery Platform diagram is a strong example of:

Proper use of UML notation,
Sound modeling decisions,
Clear separation of concerns,
Effective use of notes and generalizations.

By following the principles shown here — goal-oriented naming, correct use of include/extend, actor generalization, and strategic use of notes — you can create use case diagrams that are both accurate and actionable.

✅ Final Takeaways

Principle	Applied Here?	Why It Matters
Use goal-oriented use case names	✅ Yes	Improves clarity and user focus
Keep diagram size manageable	✅ Yes (10 use cases)	Prevents cognitive overload
External systems as actors	✅ Yes	Correct separation of concerns
Use notes for context	✅ Yes	Prevents misinterpretation
Use generalization to reduce redundancy	✅ Yes	Makes diagram scalable and maintainable
Correct `<<include>>` and `<<extend>>` direction	✅ Yes	Ensures accurate behavior modeling