A Use Case Diagram is a useful way to describe how users interact with a system. In this example, we’ll use a food ordering platform (like a restaurant app or online ordering site) to explain the components and relationships.

Main Components

• Actor: A person or system interacting with your application. Example: Customer, Admin, Delivery Rider.
• Use Case: A function or goal the user wants to achieve. Example: Place Order, Browse Menu.
• System Boundary: Defines what belongs to the food ordering system.

Common Use Cases

• Browse Menu
• Place Order
• Make Payment
• Track Delivery
• Register / Login

Use Case Relationships

1. «include»

Used when a use case always uses another use case. This helps reduce repetition.

Example: "Place Order" always includes "Make Payment".

Place Order ——> «include» Make Payment

2. «extend»

Used for optional or conditional behavior. The base use case is extended only under certain conditions.

Example: "Register" may extend to "Apply Promo Code" if the user enters a promo during signup.

Register ——> «extend» Apply Promo Code

3. Generalization

Used when one actor or use case is a more specific version of another.

Example: "Admin" and "Customer Support" both inherit from "Staff", sharing some system privileges.

Admin ——|> Staff
Customer Support ——|> Staff

Conclusion

Use Case Diagrams give a clear view of how users interact with your food ordering system. By modeling relationships like «include», «extend», and generalization, you can create more reusable and understandable system designs.