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 Payment2. «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 Code3. 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 ——|> StaffConclusion
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.
