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.

Practice

1. What is the primary purpose of a use case diagram in system design?

easy

A. To show user roles and their interactions with the system

B. To display database table relationships

C. To illustrate the internal code structure

D. To list all system hardware components

Solution

1. Step 1: Understand the role of use case diagrams

   Use case diagrams focus on users (actors) and what they do with the system (use cases).

2. Step 2: Compare with other diagram types

   Database diagrams show tables, code diagrams show code structure, hardware diagrams show physical parts, none are use case diagrams.

3. Final Answer:

   To show user roles and their interactions with the system -> Option A

4. Quick Check:

   Use case diagram = user roles + actions [OK]

Hint: Use case = users + actions, not code or hardware [OK]

Common Mistakes:

• Confusing use case diagrams with class or sequence diagrams
• Thinking use case diagrams show database details
• Assuming use case diagrams show internal code logic

2. Which of the following is the correct symbol for an actor in a use case diagram?

easy

A. A rectangle with the actor's name inside

B. An oval shape showing a system function

C. A stick figure representing a user

D. A diamond shape indicating a decision

Solution

1. Step 1: Identify actor symbol in use case diagrams

   Actors are shown as stick figures to represent users or external systems.

2. Step 2: Differentiate other symbols

   Ovals represent use cases (functions), rectangles can be system boundaries, diamonds are for decisions in flowcharts, not use case diagrams.

3. Final Answer:

   A stick figure representing a user -> Option C

4. Quick Check:

   Actor symbol = stick figure [OK]

Hint: Actors are stick figures, use cases are ovals [OK]

Common Mistakes:

• Using rectangles for actors instead of stick figures
• Confusing use case ovals with actor symbols
• Mixing flowchart symbols with use case diagram symbols

3. Consider a use case diagram with actors Customer and Admin, and use cases Place Order, Cancel Order, and Update Inventory. Which use case should only be connected to the Admin actor?

medium

A. Place Order

B. Cancel Order

C. Place Order and Cancel Order

D. Update Inventory

Solution

1. Step 1: Analyze actor responsibilities

   Customers place and cancel orders; Admin manages inventory updates.

2. Step 2: Match use cases to actors

   Only Admin should connect to Update Inventory as it is a system management task.

3. Final Answer:

   Update Inventory -> Option D

4. Quick Check:

   Admin-only use case = Update Inventory [OK]

Hint: Admin manages system tasks, customers do orders [OK]

Common Mistakes:

• Connecting customers to inventory updates
• Assuming customers can update system data
• Linking all use cases to all actors

4. A use case diagram shows an actor connected to a use case with a dashed arrow labeled <<extend>>. What does this indicate?

medium

A. The extended use case adds optional behavior to the base use case

B. The actor is not allowed to perform the extended use case

C. The actor must always perform the extended use case

D. The use case is a system boundary

Solution

1. Step 1: Understand <<extend>> relationship

   The <<extend>> arrow shows optional or conditional behavior added to a base use case.

2. Step 2: Interpret actor connection meaning

   The actor can perform the base use case; the extended use case happens only sometimes.

3. Final Answer:

   The extended use case adds optional behavior to the base use case -> Option A

4. Quick Check:

   <<extend>> = optional behavior [OK]

Hint: <<extend>> means optional addition, not mandatory [OK]

Common Mistakes:

• Thinking <<extend>> means mandatory action
• Confusing <<extend>> with <<include>>
• Assuming <<extend>> defines system boundaries

5. You are designing a use case diagram for an online library system. Which of the following best represents a correct use case for the Member actor that includes an Admin actor managing the system?

hard

A. Member: Add Book, Remove Book; Admin: Borrow Book, Return Book

B. Member: Borrow Book, Return Book; Admin: Add Book, Remove Book

C. Member: Borrow Book, Add Book; Admin: Remove Book, Return Book

D. Member: Remove Book, Return Book; Admin: Borrow Book, Add Book

Solution

1. Step 1: Identify typical member actions

   Members usually borrow and return books, not manage inventory.

2. Step 2: Identify admin responsibilities

   Admins add or remove books to keep the library updated.

3. Step 3: Match actions to actors correctly

   Member: Borrow Book, Return Book; Admin: Add Book, Remove Book correctly assigns borrowing and returning to Member, and adding/removing to Admin.

4. Final Answer:

   Member: Borrow Book, Return Book; Admin: Add Book, Remove Book -> Option B

5. Quick Check:

   Member = borrow/return, Admin = add/remove [OK]

Hint: Members use books; Admins manage books [OK]

Common Mistakes:

• Swapping member and admin roles
• Assigning management tasks to members
• Mixing use cases between actors