Use case diagrams in LLD - Deep Dive

Overview - Use case diagrams

What is it?

Use case diagrams are simple pictures that show how people or other systems interact with a software system. They focus on what the system does from the user's point of view, not how it does it. Each use case represents a goal or task that a user wants to achieve with the system. Actors are the users or external systems that interact with these use cases.

Why it matters

Use case diagrams help teams understand the system's requirements clearly by showing who uses the system and what they want to do. Without them, developers might build features that don't meet user needs or miss important interactions. They also make communication easier between technical and non-technical people, reducing confusion and costly mistakes.

Where it fits

Before learning use case diagrams, you should understand basic software requirements and what a system is supposed to do. After mastering use case diagrams, you can learn more detailed design tools like sequence diagrams or class diagrams that show how the system works internally.

Mental Model

Core Idea

Use case diagrams map out who uses a system and what goals they want to achieve with it, focusing on user needs rather than technical details.

Think of it like...

It's like a restaurant menu showing what dishes customers can order and who can order them, without explaining how the kitchen prepares each dish.

╔══════════════════════╗
║      System          ║
║  ┌───────────────┐   ║
║  │ Use Case 1    │◄──┤ Actor 1 (User)
║  ├───────────────┤   ║
║  │ Use Case 2    │◄──┤ Actor 2 (External System)
║  └───────────────┘   ║
╚══════════════════════╝

Build-Up - 7 Steps

1

Foundation

Understanding Actors and Use Cases

Concept: Learn what actors and use cases represent in a system.

Actors are people or systems that interact with the software. Use cases are the tasks or goals these actors want to accomplish using the system. For example, in an online store, a customer (actor) wants to place an order (use case).

Result

You can identify who uses the system and what they want to do with it.

Understanding actors and use cases is the foundation for capturing user needs clearly and simply.

2

Foundation

Basic Diagram Components and Symbols

Concept: Learn the standard symbols used in use case diagrams.

Actors are shown as stick figures or named boxes outside the system boundary. Use cases are ovals inside the system boundary box. Lines connect actors to the use cases they interact with. The system boundary is a rectangle that groups all use cases.

Result

You can draw a simple use case diagram that visually represents user interactions.

Knowing the symbols helps you read and create diagrams that everyone can understand.

3

Intermediate

Relationships Between Use Cases

🤔Before reading on: do you think use cases can work independently or must always be connected? Commit to your answer.

Concept: Learn how use cases can relate to each other using include and extend relationships.

Include means one use case always uses another as part of its process (like a shared step). Extend means one use case adds optional behavior to another under certain conditions. For example, 'Place Order' might include 'Validate Payment', and 'Apply Discount' might extend 'Place Order'.

Result

You can model complex behaviors by showing how use cases depend on or add to each other.

Understanding these relationships helps break down complex tasks into reusable parts and optional features.

4

Intermediate

System Boundary and Scope Definition

🤔Before reading on: do you think the system boundary includes actors or only use cases? Commit to your answer.

Concept: Learn how to define what is inside and outside the system in the diagram.

The system boundary is a box that contains all use cases but excludes actors. It shows what the system does and what is external. Defining this boundary helps clarify what the system is responsible for and what is handled by users or other systems.

Result

You can clearly separate system functions from external interactions.

Defining scope prevents confusion about responsibilities and helps focus design efforts.

5

Intermediate

Multiple Actors and Their Interactions

🤔Before reading on: can one use case have multiple actors? Commit to your answer.

Concept: Learn how to represent different users or systems interacting with the same or different use cases.

A use case can be connected to multiple actors if they share the same goal. For example, both 'Customer' and 'Admin' actors might interact with 'Login'. This shows shared or distinct roles in the system.

Result

You can model real-world scenarios where different users perform similar or different tasks.

Recognizing multiple actors per use case helps capture diverse user needs and permissions.

6

Advanced

Use Case Diagram for Large Systems

🤔Before reading on: do you think one diagram can show all use cases for a big system? Commit to your answer.

Concept: Learn how to organize use case diagrams for complex systems using packages or multiple diagrams.

Large systems have many use cases and actors, making one diagram cluttered. You can group related use cases into packages or create separate diagrams for different subsystems or user groups. This keeps diagrams clear and manageable.

Result

You can create scalable diagrams that remain understandable as systems grow.

Knowing how to organize diagrams prevents information overload and supports team collaboration.

7

Expert

Common Pitfalls and Best Practices in Use Case Diagrams

🤔Before reading on: do you think every system function should be a use case? Commit to your answer.

Concept: Learn what to avoid and how to make use case diagrams effective in real projects.

Not every technical detail or internal process should be a use case; focus on user goals. Avoid overly complex diagrams by limiting use cases to meaningful tasks. Use clear names and consistent symbols. Review diagrams with stakeholders to ensure accuracy and usefulness.

Result

You produce diagrams that truly guide development and communication without confusion.

Understanding what to include or exclude ensures diagrams serve their purpose and avoid wasted effort.

Under the Hood

Use case diagrams work by abstracting system functionality into user goals and interactions. Internally, they do not show code or data flow but provide a high-level map of system requirements. Tools parse these diagrams to generate documentation or link to detailed designs, but the diagrams themselves are conceptual models.

Why designed this way?

They were created to bridge the gap between users and developers by focusing on what users want to achieve, not how the system works internally. This separation helps avoid technical jargon and keeps discussions user-centered. Alternatives like flowcharts or class diagrams focus on processes or structure, which can confuse non-technical stakeholders.

┌─────────────────────────────┐
│        Use Case Diagram      │
│                             │
│  ┌───────────────┐          │
│  │   Actor 1     │          │
│  └──────┬────────┘          │
│         │                   │
│  ┌──────▼────────┐          │
│  │  Use Case A   │◄─────────┤
│  └───────────────┘          │
│         ▲                   │
│  ┌──────┴────────┐          │
│  │  Use Case B   │          │
│  └───────────────┘          │
│                             │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do use case diagrams show how the system works internally? Commit yes or no.

Common Belief: Use case diagrams show detailed internal system processes and data flow.

Reality: They only show what the system does from the user's perspective, not internal workings.

Why it matters: Confusing use case diagrams with detailed designs can lead to wasted effort and misunderstandings between teams.

Quick: Can one actor represent multiple users with different roles? Commit yes or no.

Common Belief: Each actor must represent only one specific user or role.

Reality: Actors can represent a group of users sharing the same goals or an external system, not just individuals.

Why it matters: Limiting actors too narrowly can make diagrams unnecessarily complex and miss shared behaviors.

Quick: Should every small function or button be a use case? Commit yes or no.

Common Belief: Every system function, no matter how small, should be a use case.

Reality: Use cases represent meaningful user goals, not every tiny function or interface element.

Why it matters: Including too many trivial use cases clutters diagrams and distracts from important user needs.

Quick: Does the system boundary include actors? Commit yes or no.

Common Belief: Actors are inside the system boundary because they interact with the system.

Reality: Actors are always outside the system boundary to show they are external to the system.

Why it matters: Misplacing actors inside the boundary confuses system responsibilities and scope.

Expert Zone

1

Actors can be human users, external hardware, or other software systems, and recognizing this broadens diagram usefulness.

2

Include and extend relationships are not just technical links but represent different types of user goal dependencies and optional behaviors.

3

The naming of use cases should focus on user goals phrased as actions or tasks, not system functions or technical terms.

When NOT to use

Use case diagrams are not suitable for modeling internal system logic, data structures, or performance details. For those, use sequence diagrams, class diagrams, or architecture diagrams instead.

Production Patterns

In real projects, use case diagrams are often created early to gather requirements and reviewed regularly with stakeholders. They are combined with user stories and acceptance criteria in agile workflows. Large systems use layered diagrams to manage complexity.

Connections

User Stories

Use case diagrams build on user stories by visually grouping and relating user goals.

Knowing use case diagrams helps organize and visualize user stories, improving requirement clarity.

Sequence Diagrams

Sequence diagrams detail the interactions inside a use case over time.

Understanding use case diagrams provides the context needed to create meaningful sequence diagrams.

Theatre Scripts

Both use case diagrams and theatre scripts describe roles (actors) and actions (scenes) to tell a story.

Recognizing this connection shows how system design is like storytelling, focusing on roles and goals.

Common Pitfalls

#1 Including too many technical details as use cases.

Wrong approach:

Use Case: 'Encrypt Data' connected to Actor: 'User'

Correct approach:

Use Case: 'Securely Submit Order' connected to Actor: 'User'

Root cause:

Confusing system internal functions with user goals leads to cluttered and confusing diagrams.

#2 Placing actors inside the system boundary.

Wrong approach:

System boundary box contains actors and use cases together.

Correct approach:

Actors are placed outside the system boundary box, connected by lines to use cases inside.

Root cause:

Misunderstanding that actors represent external entities causes scope confusion.

#3 Drawing one huge diagram for a complex system.

Wrong approach:

All use cases and actors crammed into a single diagram.

Correct approach:

Divide use cases into packages or multiple diagrams by subsystem or user group.

Root cause:

Not managing complexity leads to unreadable diagrams that fail to communicate effectively.

Key Takeaways

Use case diagrams focus on who uses the system and what they want to achieve, not how the system works internally.

Actors represent external users or systems, and use cases represent meaningful user goals or tasks.

Clear system boundaries separate what the system does from what is outside, helping define scope.

Relationships like include and extend help model complex behaviors by showing dependencies and optional features.

Effective use case diagrams are simple, focused on user needs, and organized to handle system complexity.