Use Case Diagram

A UML Use Case Diagram is a behavioral diagram that models the functional requirements of a system. It defines the interactions between external users (Actors) and the services or actions the system provides (Use Cases). In Low-Level Design, use case diagrams define the functional scope of a system, mapping actors to specific application service interfaces.

1. Learning Objectives

• Identify actors, use cases, and system boundaries in a functional design.
• Understand the structural differences between «include» and «extend» relationships.
• Differentiate primary actors from secondary actors (external supporting systems).
• Translate use case diagrams directly into clean-architecture command pattern objects.
• Implement transaction flow controls representing ATM system use cases in Java, Python, and C++.

2. Problem Statement

When kick-starting a new system design, developers often jump directly to writing database tables or classes. Without a high-level model defining what actions the system supports and who executes them, projects suffer from:

• Scope Creep: Adding features that the client did not request because system boundaries were never established.
• Missing Edge Cases: Forgetting that a user withdrawal requires pin validation or that printing a receipt is optional, leading to last-minute code additions.
• Violating Security Roles: Forcing standard users to implement administrative or support functions due to polluted API interfaces.

3. Real-world Analogy

4. Theory (Actors, Use Cases, and Relationships)

A Use Case Diagram consists of four core elements:

• Actors: Represent external entities that interact with the system. They can be humans (e.g. Customer) or external hardware/software systems (e.g. Credit Card Processor). - *Primary Actor*: Initiates the interaction to achieve a goal (drawn on the left). - *Secondary / Supporting Actor*: Provides services to the system (drawn on the right).
• Use Cases: Represent specific actions or functions (drawn as ovals/pills).
• System Boundary: Represents the limits of the system (drawn as a box surrounding the use cases, with the actors outside).

Relationship Types

• Association: A simple line linking an Actor to a Use Case, indicating the actor can trigger the function.
• Include («include»): A directed relationship from a base use case to a target use case. It represents mandatory behavior: the target usecase *must* execute for the base usecase to complete (e.g., Withdraw Cash *includes* Validate PIN).
• Extend («extend»): A directed relationship from an extension use case to a base use case. It represents optional behavior: the extension use case executes only under specific conditions (e.g., Print Receipt *extends* Withdraw Cash, only if requested).

5. Visual Diagrams (ATM System Use Case)

Below is a Use Case Diagram for an ATM System. Note that Card PIN Validation is included in cash transactions, and Printing a Receipt is an optional extension:

6. Syntax Explanation

In clean LLD architectures, use cases map directly to the Use Case Layer or Command Pattern class structures:

• Include («include»): Inside the primary use case runner class, call the included service method directly as a mandatory step. If the validation fails, the entire transaction is aborted.
• Extend («extend»): Check an optional boolean flag (e.g. wantsReceipt) inside the class constructor or execution method. Execute the extension method only if the condition evaluates to true.

7. Step-by-Step Creation

1. Identify System Boundary: Draw a large box representing the system scope (e.g. ATM console, checkout portal).
2. Identify Actors: Draw actors outside the box. Place primary actors (initiating requests) on the left, and secondary actors (external databases, printer components) on the right.
3. Determine Use Cases: List primary goals as verb-noun phrases inside the boundary box (e.g., Check Balance, Withdraw Cash).
4. Link Associations: Draw simple solid lines connecting actors to the use cases they trigger.
5. Refactor with Include/Extend: - Extract common, mandatory validation checks into a separate use case and draw an «include» arrow *pointing to* the helper use case. - Extract optional, conditional actions and draw an «extend» arrow *pointing back to* the base use case.

8. Complete Code (Mini Project)

9. Code Walkthrough

Let's review the code structure mapping:

• WithdrawUseCase represents the main functional requirement (Use Case). It wraps the logic for withdrawing cash from an account.
• PinValidationService represents an Included Use Case. Because withdrawals always require authentication, validatePIN() is called unconditionally inside execute(). If it fails, the flow terminates.
• ReceiptPrinter represents an Extended Use Case. Printing a receipt is optional. WithdrawUseCase accepts a boolean parameter wantsReceipt, representing the extension condition. The printing logic is executed only if this flag is true.
• The BankDatabase object represents the Supporting Actor (external bank system), providing state tracking.

10. Execution Flow

1. Assembly: The client initializes database, validation, and printer helper structures.
2. Instantiating Use Case: The client instantiates WithdrawUseCase, specifying transaction parameters and configuration flags.
3. Verification (Include): Inside execute(), the use case calls validator.validatePIN().
4. Transaction Execution: If validation passes, the system validates the balance against the database and deducts the amount.
5. Optional Output (Extend): The use case evaluates wantsReceipt. If true, it calls printer.printReceipt(), generating physical receipt records.

11. Internal Working (Control Flow Execution)

At the execution stack frame level, use case dependencies are handled via standard subroutine calls:

• Stack Allocations: Invoking execute() pushes a new frame onto the execution stack.
• Includes Branching: When the execution line reaches the validation call, a new stack frame for validator.validatePIN() is pushed. The execution pauses until the validation returns a value.
• Extends Branching: When the execution reaches the receipt print check, the runtime checks the status register flag. If set, a stack frame for printer.printReceipt() is allocated. Otherwise, execution bypasses the print routine entirely.

12. Complexity Analysis

• Time Complexity: $O(1)$ constant time for validation checks and transaction logic.
• Space Complexity: $O(1)$ stack allocation overhead. Splitting use cases into separate classes avoids bloated controllers without adding memory overhead.

13. Best Practices

• Stick to user-facing goals: Describe *what* the system does from the user's perspective, not *how* it is done internally (e.g. use "Validate Login" instead of "Query User Table").
• Model the System Boundary clearly: Ensure all use cases reside inside the boundary box, while actors remain outside.
• Avoid deep inheritance chains for actors: Generalize actors only when their permission profiles overlap significantly (e.g. Patron and Librarian both inherit from User).

14. Common Mistakes

• Incorrect Arrow Direction: Drawing include/extend arrows backward. Remember: the base use case points *to* the included use case, but the extension use case points *to* the base use case.
• Using Include for sequence flows: Using «include» to represent sequential steps (e.g., Step 1: Insert Card, Step 2: Validate PIN). Use case diagrams model capabilities, not time sequences.
• Adding too many details: Bloating the diagram with low-level details. A use case diagram should remain simple enough for business stakeholders to review.

15. Interview Questions

16. Practice Exercises

• Easy: Draw a Use Case Diagram for a simple DigitalLibrary where a User can search for books and download PDFs, while an Admin can upload new catalogs.
• Medium: Draw a Use Case Diagram for an OnlineStore checkout. Include PIN/OTP verification and optional order tracking notification extensions.
• Hard: Design a Use Case Diagram for a RideHailingSystem (like Uber). Model interactions for both Passenger and Driver actors, including payment verification, GPS tracking inclusions, and driver tipping extensions.

17. Challenge Problem

Design the Use Case Diagram for a Food Delivery Platform (like DoorDash). The system must support three actor classes: the Customer, the Restaurant Manager, and the Delivery Rider. Include use cases for ordering food, notifying restaurants, tracking deliveries, and leaving reviews. Incorporate at least three «include» and three «extend» relationships. Write the core execution logic in Java, Python, or C++ representing the order checkout process with included credit card validation.

18. Summary

• Use Case Diagrams define the functional requirements and scope of a system.
• Actors are external entities (primary or secondary), while Use Cases are system capabilities.
• The «include» relationship indicates mandatory validation or sub-flow execution.
• The «extend» relationship indicates conditional, optional execution.

19. Cheat Sheet

20. Quiz

21. Next Lesson Preview

In the next lesson, we will cover the Sequence Diagram. We will learn how to capture dynamic behavior and trace method calls chronologically across object lifelines!