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.