Use case diagrams in LLD - System Design Guide

Problem Statement

When system requirements are unclear or stakeholders have different views, teams struggle to agree on what the system should do. This leads to missed features, wasted effort, and confusion during development.

Solution

Use case diagrams visually show the interactions between users (actors) and the system's functions (use cases). They clarify who does what and help everyone agree on system behavior before coding starts.

Architecture

Actor 1

↓

Actor 2

This diagram shows actors (users or external systems) connected to use cases (system functions) they interact with.

Trade-offs

✓ Pros

→

Provides a clear, visual summary of system functionality from user perspective.

→

Helps align stakeholders early by showing who uses what features.

→

Easy to create and understand without technical background.

→

Supports identifying missing or overlapping requirements.

✗ Cons

→

Does not show internal system design or data flow details.

→

Can become cluttered if too many actors or use cases exist.

→

Limited in expressing complex logic or conditions.

Use when gathering requirements for new systems or features, especially with multiple user roles and when stakeholder alignment is critical.

Avoid when detailed system internals or data processing flows need to be modeled, or when the system is very simple with only one user and few functions.

Real World Examples

Amazon

Used use case diagrams to clarify interactions between customers, sellers, and payment systems during the design of their marketplace platform.

Uber

Applied use case diagrams to map rider and driver interactions with the app, ensuring all user scenarios were covered before development.

LinkedIn

Used use case diagrams to define different user roles like job seekers, recruiters, and advertisers and their respective system interactions.

Code Example

The before code mixes user types and actions in one method, making it hard to extend or understand. The after code separates actors and use cases into classes, clearly showing who does what, reflecting the use case diagram concept.

LLD

### Before: No clear structure for user interactions
class System:
    def process(self, user_type, action):
        if user_type == 'admin' and action == 'delete':
            print('Admin deletes data')
        elif user_type == 'guest' and action == 'view':
            print('Guest views data')
        else:
            print('Action not allowed')

### After: Using classes to represent actors and use cases clearly
class Actor:
    def __init__(self, name):
        self.name = name

class UseCase:
    def __init__(self, name):
        self.name = name
    def execute(self, actor):
        print(f'{actor.name} executes {self.name}')

admin = Actor('Admin')
guest = Actor('Guest')
view_data = UseCase('View Data')
delete_data = UseCase('Delete Data')

view_data.execute(guest)  # Guest executes View Data
delete_data.execute(admin)  # Admin executes Delete Data

Alternatives

User stories

User stories describe functionality in short text form focusing on user goals, while use case diagrams visually map actors and their interactions.

Use when: Choose user stories when you want detailed narrative requirements and acceptance criteria rather than a visual overview.

Activity diagrams

Activity diagrams model workflows and processes step-by-step, unlike use case diagrams which show actor-function relationships.

Use when: Choose activity diagrams when you need to model detailed process flows or decision points.

Sequence diagrams

Sequence diagrams show the order of interactions between system components over time, unlike use case diagrams which focus on who uses what.

Use when: Choose sequence diagrams when you want to detail message exchanges and timing between objects.

Summary

Use case diagrams visually map users and their interactions with system functions to clarify requirements.

They help align stakeholders early by showing who uses what features in a simple way.

They are best for capturing user goals but not for modeling internal system details or workflows.

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