While Sequence, Activity, and State diagrams dive deep into how a system executes its internal logic, the Use Case Diagram steps back to look at the big picture. It serves as the high-level functional map of your system, defining who uses the application and what they can do with it.

In Low-Level Design (LLD) interviews and project specifications, the Use Case Diagram acts as a contract that defines the functional scope of your software before you write any code or design tight class hierarchies.

Key ideas:

  • A Use Case Diagram visualizes the interactions between a system and its external entities (users or systems).

  • It defines the explicit functional scope of the application, keeping out-of-scope requirements away.

  • It bridges the gap between high-level business goals and concrete, low-level technical architecture.

Core Components of a Use Case Diagram

A Use Case Diagram uses four fundamental visual building blocks to organize system requirements:

  • Actor: Represented by a standard stick figure, an actor represents any external entity that interacts with your system. It can be a human user (e.g., Customer, Admin) or an external hardware device/software system (e.g., PaymentGateway, SmsService).

  • Use Case: Represented by a horizontal oval, a use case represents a distinct, high-level business goal or action that an actor can perform within the system (e.g., ViewCatalog, ProcessPayment).

  • System Boundary: Represented by a large rectangle enclosing the use cases, this box defines the scope of the software application you are designing. Actors sit outside the boundary box; use cases sit inside it.

  • Association Line: A simple solid line connecting an actor to a use case, showing that the actor participates in or initiates that specific functional task.

Use Case Relationships: Include and Extend

Not all use cases stand alone. Often, different workflows share duplicate tasks or branch off into optional behaviors. UML manages these scenarios using two specific types of directed relationships between use cases:

One: <<include>> Relationship

An include relationship indicates that a base use case strictly requires the behavior of another use case to complete its task. It represents a mandatory sub-task.

  • Direction: The dashed arrow points away from the base use case toward the included sub-task use case.

  • Example: CheckoutOrder includes ValidateStock. You cannot physically check out without running the inventory check first.

Two: <<extend>> Relationship

An extended relationship indicates that a base use case can conditionally or optionally branch off into a specialized behavior under specific circumstances. It represents an optional sub-task.

  • Direction: The dashed arrow points backward from the extending use case toward the base use case.

  • Example: ProcessPayment is the base task. If a payment transaction fails, the system can optionally branch into DisplayPaymentError. The error screen extends the base payment workflow.

Step-by-Step Walkthrough: An E-Commerce Use Case Model

To see how these concepts fit together, let us map out the functional scope for an E-Commerce portal:

"A Customer can browse items, search for products, and check out an order. Checking out an order mandates a payment process. If the user possesses a digital coupon, they can optionally apply a discount during checkout. An Inventory Admin can log into the same system boundary to update warehouse stock listings."

Mapping Use Cases to Low-Level C++ Code

When moving from a Use Case Diagram to concrete code, a common mistake is grouping all use cases into a single massive manager class. To make your system extensible and maintainable, map each use case (or group of closely related use cases) to a dedicated Controller, Service, or Command Object.

Here is how the e-commerce use case boundaries translate directly into highly modular, decoupled C++ design:


System Execution Demonstration


Architectural Mapping: Diagram to Code

When translating a Use Case Diagram into low-level components, follow these structural guidelines:

  • Actors to Client Calls: Actors match the external triggers or clients that invoke methods on your API gateway or main controller layer.

  • Use Case Ovals to Service Methods: Each use case oval inside your system boundary maps to a public execution method (executeCheckout()) within your application services.

  • Include Links to Mandatory Dependencies: If a use case includes another task, the target service must be injected as a structural dependency or member variable to be executed within the main workflow sequence.

  • Extend Links to Conditional Blocks: An extend relationship translates to a conditional wrapper (if statement or strategy pattern) That triggers only when explicit criteria are met.

Common Pitfalls in Use Case Diagrams

  • Writing Flowcharts Inside Ovals: A use case represents a complete business goal, not an individual step in an algorithm. Do not name use cases like EnterPassword, ClickSubmitButton, or VerifyDatabaseField. Instead, encapsulate all of those steps inside a single, comprehensive use case named. LoginUser.

  • Inverting Include and Extend Arrowheads: Remember the arrow directions: <<include>> Points forward from the base task to the required dependency. <<extend>> Points backward from the optional custom task back to the base anchor workflow. Inverting these arrows flips the structural logic of your system.

  • Forgetting the System Boundary Box: If you scatter use case ovals around actors without drawing a clear system boundary box, your model loses its primary utility—defining what your code is responsible for doing versus what external platforms handle.

Summary

  • Use case diagrams act as a high-level system contract, defining actors, boundaries, and system goals.

  • <<include>> The relationships model mandates sub-tasks that must be executed for a base use case to succeed.

  • <<extend>> Relationships represent optional or exceptional pathways that run under explicit conditions.

  • Mapping use cases to dedicated command objects or service controllers prevents cluttered, bloated code structures.