Layrs

Use Case Diagrams in UML: Guide & Examples

Updated 2026-03-11

TL;DR

Use Case Diagrams visualize what a system does from the user’s perspective, showing actors (users or external systems) and their interactions with the system’s functionality. They’re essential for requirements gathering and communicating system behavior to stakeholders without diving into implementation details.

Prerequisites: Basic understanding of software requirements, familiarity with the concept of users interacting with systems, and general knowledge of what UML diagrams are used for in software design.

After this topic: Create use case diagrams that accurately represent system functionality from a user perspective, identify actors and their relationships to use cases, and communicate system requirements effectively to both technical and non-technical stakeholders.

Core Concept

What is a Use Case Diagram?

A Use Case Diagram is a behavioral UML diagram that shows what a system does (its functionality) from an external perspective. Unlike class diagrams that show structure, use case diagrams focus on user goals and system responsibilities.

Think of it as a high-level map of who uses your system and what they can do with it.

Core Components

Actors

Actors are entities that interact with the system from the outside. They can be:

  • Primary actors: Initiate interactions to achieve goals (e.g., Customer, Admin)
  • Secondary actors: Provide services to the system (e.g., Payment Gateway, Email Service)

Actors are NOT part of the system — they’re external users or systems.

Use Cases

Use Cases represent specific functionalities or services the system provides. Each use case describes one goal an actor wants to achieve. Examples: “Place Order”, “Generate Report”, “Reset Password”.

Use cases should be named with verb phrases that describe what gets accomplished.

Relationships

Association: A solid line connecting an actor to a use case they participate in.

Include: One use case always requires another use case (shown with dashed arrow and <<include>>). Example: “Place Order” includes “Validate Payment”.

Extend: One use case optionally adds behavior to another (shown with dashed arrow and <<extend>>). Example: “Apply Discount Code” extends “Place Order”.

Generalization: Shows inheritance between actors or between use cases (solid line with hollow arrow).

Why Use Case Diagrams Matter

They bridge the gap between business requirements and technical design. Stakeholders understand what the system will do without needing to know how it works. For developers, they provide a clear scope of functionality to implement.

Visual Guide

Basic Use Case Diagram Structure

graph LR
    Actor1((Customer))
    Actor2((Admin))
    
    subgraph System Boundary
        UC1[Place Order]
        UC2[View Products]
        UC3[Manage Inventory]
        UC4[Process Payment]
    end
    
    Actor1 --> UC1
    Actor1 --> UC2
    Actor2 --> UC3
    UC1 -.->|<<include>>| UC4

Actors (stick figures) interact with use cases (ovals) within the system boundary. The dashed arrow shows an include relationship where Place Order must include Process Payment.

Use Case Relationships

graph TB
    Actor((User))
    
    subgraph E-commerce System
        UC1[Checkout]
        UC2[Validate Payment]
        UC3[Apply Coupon]
        UC4[Send Confirmation Email]
    end
    
    Actor --> UC1
    UC1 -.->|<<include>>| UC2
    UC3 -.->|<<extend>>| UC1
    UC1 -.->|<<include>>| UC4
    
    style UC2 fill:#e1f5ff
    style UC3 fill:#fff4e1
    style UC4 fill:#e1f5ff

Include relationships (blue) are mandatory steps, while extend relationships (yellow) are optional enhancements. Checkout always includes payment validation and email confirmation, but applying a coupon is optional.

Actor Generalization

graph TB
    GenericUser((User))
    RegUser((Registered User))
    Guest((Guest User))
    Admin((Administrator))
    
    subgraph System
        UC1[Browse Products]
        UC2[Place Order]
        UC3[View Order History]
        UC4[Manage Users]
    end
    
    RegUser -.->|inherits| GenericUser
    Guest -.->|inherits| GenericUser
    Admin -.->|inherits| RegUser
    
    GenericUser --> UC1
    RegUser --> UC2
    RegUser --> UC3
    Admin --> UC4

Actor generalization shows that Registered User and Guest User are specialized types of User. Admin inherits all capabilities of Registered User plus additional administrative functions.

Examples

Example 1: Online Banking System

Let’s design a use case diagram for a simple online banking system. We’ll identify actors and their interactions.

Actors:

  • Customer (primary)
  • Bank System (secondary - external validation)
  • Admin (primary)

Use Cases:

  • View Account Balance
  • Transfer Funds
  • Validate Transaction (included in Transfer Funds)
  • Pay Bills
  • Generate Statement
  • Manage Customer Accounts (admin only)
# This is a textual representation - in practice, you'd use UML tools
# But understanding the structure helps when implementing the system

class UseCaseDiagram:
    """
    Represents the structure of a Use Case Diagram for documentation.
    This is NOT executable code but a design artifact.
    """
    def __init__(self, system_name):
        self.system_name = system_name
        self.actors = []
        self.use_cases = []
        self.relationships = []
    
    def add_actor(self, name, actor_type="primary"):
        self.actors.append({"name": name, "type": actor_type})
    
    def add_use_case(self, name, description):
        self.use_cases.append({"name": name, "description": description})
    
    def add_association(self, actor, use_case):
        self.relationships.append({
            "type": "association",
            "from": actor,
            "to": use_case
        })
    
    def add_include(self, base_use_case, included_use_case):
        self.relationships.append({
            "type": "include",
            "from": base_use_case,
            "to": included_use_case
        })
    
    def display(self):
        print(f"\n=== {self.system_name} ===")
        print("\nActors:")
        for actor in self.actors:
            print(f"  - {actor['name']} ({actor['type']})")
        
        print("\nUse Cases:")
        for uc in self.use_cases:
            print(f"  - {uc['name']}: {uc['description']}")
        
        print("\nRelationships:")
        for rel in self.relationships:
            print(f"  - {rel['from']} --{rel['type']}--> {rel['to']}")

# Create the banking system use case diagram
banking_diagram = UseCaseDiagram("Online Banking System")

# Add actors
banking_diagram.add_actor("Customer", "primary")
banking_diagram.add_actor("Admin", "primary")
banking_diagram.add_actor("Bank System", "secondary")

# Add use cases
banking_diagram.add_use_case("View Account Balance", "Customer checks current balance")
banking_diagram.add_use_case("Transfer Funds", "Customer transfers money between accounts")
banking_diagram.add_use_case("Validate Transaction", "System validates transaction is legitimate")
banking_diagram.add_use_case("Pay Bills", "Customer pays utility bills")
banking_diagram.add_use_case("Manage Customer Accounts", "Admin creates/modifies accounts")

# Add relationships
banking_diagram.add_association("Customer", "View Account Balance")
banking_diagram.add_association("Customer", "Transfer Funds")
banking_diagram.add_association("Customer", "Pay Bills")
banking_diagram.add_association("Admin", "Manage Customer Accounts")

# Include relationship - Transfer Funds MUST include Validate Transaction
banking_diagram.add_include("Transfer Funds", "Validate Transaction")
banking_diagram.add_include("Pay Bills", "Validate Transaction")

# Display the diagram structure
banking_diagram.display()

Expected Output:

=== Online Banking System ===

Actors:
  - Customer (primary)
  - Admin (primary)
  - Bank System (secondary)

Use Cases:
  - View Account Balance: Customer checks current balance
  - Transfer Funds: Customer transfers money between accounts
  - Validate Transaction: System validates transaction is legitimate
  - Pay Bills: Customer pays utility bills
  - Manage Customer Accounts: Admin creates/modifies accounts

Relationships:
  - Customer --association--> View Account Balance
  - Customer --association--> Transfer Funds
  - Customer --association--> Pay Bills
  - Admin --association--> Manage Customer Accounts
  - Transfer Funds --include--> Validate Transaction
  - Pay Bills --include--> Validate Transaction

Try it yourself: Add an “extend” relationship for “Apply for Overdraft Protection” that extends “Transfer Funds” (optional feature when balance is low).

Example 2: E-Learning Platform

Now let’s model a more complex system with actor generalization and extend relationships.

class Actor:
    """Represents an actor in the use case diagram."""
    def __init__(self, name, parent=None):
        self.name = name
        self.parent = parent  # For generalization
        self.use_cases = []
    
    def can_perform(self, use_case):
        self.use_cases.append(use_case)
    
    def get_all_use_cases(self):
        """Get use cases including inherited ones."""
        cases = self.use_cases.copy()
        if self.parent:
            cases.extend(self.parent.get_all_use_cases())
        return cases
    
    def __repr__(self):
        parent_info = f" (extends {self.parent.name})" if self.parent else ""
        return f"Actor: {self.name}{parent_info}"

class UseCase:
    """Represents a use case with relationships."""
    def __init__(self, name, description):
        self.name = name
        self.description = description
        self.includes = []  # Use cases that must be included
        self.extended_by = []  # Use cases that optionally extend this one
    
    def include(self, use_case):
        self.includes.append(use_case)
    
    def extend_with(self, use_case):
        self.extended_by.append(use_case)
    
    def __repr__(self):
        return f"UseCase: {self.name}"

# Create actor hierarchy
user = Actor("User")
student = Actor("Student", parent=user)
instructor = Actor("Instructor", parent=user)
admin = Actor("Admin", parent=user)

# Create use cases
browse_courses = UseCase("Browse Courses", "View available courses")
enroll_course = UseCase("Enroll in Course", "Register for a course")
process_payment = UseCase("Process Payment", "Handle course payment")
apply_scholarship = UseCase("Apply Scholarship", "Use scholarship code")
watch_lecture = UseCase("Watch Lecture", "View course video content")
submit_assignment = UseCase("Submit Assignment", "Upload assignment files")
grade_assignment = UseCase("Grade Assignment", "Review and score submissions")
create_course = UseCase("Create Course", "Design new course content")
manage_users = UseCase("Manage Users", "Add/remove/modify user accounts")

# Define relationships
enroll_course.include(process_payment)  # Must process payment to enroll
apply_scholarship.extend_with(enroll_course)  # Optionally apply scholarship during enrollment

# Assign use cases to actors
user.can_perform(browse_courses)
student.can_perform(enroll_course)
student.can_perform(watch_lecture)
student.can_perform(submit_assignment)
instructor.can_perform(create_course)
instructor.can_perform(grade_assignment)
admin.can_perform(manage_users)

# Display actor capabilities
print("=== E-Learning Platform Use Case Model ===")
print()
for actor in [user, student, instructor, admin]:
    print(actor)
    all_cases = actor.get_all_use_cases()
    if all_cases:
        print("  Can perform:")
        for uc in all_cases:
            print(f"    - {uc.name}")
            if uc.includes:
                for inc in uc.includes:
                    print(f"      <<includes>> {inc.name}")
            if uc.extended_by:
                for ext in uc.extended_by:
                    print(f"      <<extended by>> {ext.name}")
    print()

Expected Output:

=== E-Learning Platform Use Case Model ===

Actor: User
  Can perform:
    - Browse Courses

Actor: Student (extends User)
  Can perform:
    - Enroll in Course
      <<includes>> Process Payment
    - Watch Lecture
    - Submit Assignment
    - Browse Courses

Actor: Instructor (extends User)
  Can perform:
    - Create Course
    - Grade Assignment
    - Browse Courses

Actor: Admin (extends User)
  Can perform:
    - Manage Users
    - Browse Courses

Key Observations:

  • Student inherits “Browse Courses” from User
  • “Enroll in Course” includes “Process Payment” (mandatory)
  • “Apply Scholarship” extends “Enroll in Course” (optional)
  • Each specialized actor (Student, Instructor, Admin) has unique capabilities plus inherited ones

Try it yourself: Add a “Guest” actor that can only browse courses but cannot enroll. Then add a “Premium Student” that extends Student and can “Download Lectures for Offline Viewing”.

Java/C++ Notes

In Java, you might use interfaces to represent actors and use cases:

public interface Actor {
    String getName();
    List<UseCase> getUseCases();
}

public interface UseCase {
    String getName();
    String getDescription();
    List<UseCase> getIncludedUseCases();
}

In C++, you’d use abstract classes with virtual methods for the same purpose. The key is that use case diagrams are design artifacts — the code represents the structure for documentation and validation, not runtime behavior.

Common Mistakes

1. Confusing Actors with System Components

Mistake: Listing “Database”, “Authentication Module”, or “Payment Processor” as actors.

Why it’s wrong: Actors are external to the system. Internal components are part of the implementation, not actors. The Payment Gateway (external service) could be an actor, but your internal payment processing code is not.

Fix: Only include entities that interact with your system from the outside. Ask: “Does this exist independently of my system?“

2. Making Use Cases Too Granular

Mistake: Creating use cases like “Click Submit Button”, “Validate Email Format”, “Display Error Message”.

Why it’s wrong: Use cases represent complete user goals, not individual steps or UI actions. These are implementation details.

Fix: Use cases should answer “What does the user want to accomplish?” Examples: “Register Account”, “Submit Order”, “Generate Report”. Each should provide value to the actor.

3. Overusing Include and Extend

Mistake: Drawing include/extend arrows everywhere, creating a tangled web of dependencies.

Why it’s wrong: These relationships should be used sparingly. Include is for mandatory shared behavior. Extend is for optional variations. Most use cases should stand alone.

Fix: Use include only when a use case fragment appears in multiple places AND must always happen. Use extend only for true optional enhancements. If you’re unsure, don’t add the relationship.

4. Mixing Functional and Non-Functional Requirements

Mistake: Creating use cases like “System Responds in 2 Seconds”, “Handle 1000 Concurrent Users”.

Why it’s wrong: Use case diagrams show functional requirements (what the system does), not non-functional requirements (how well it does it). Performance, security, and scalability are documented elsewhere.

Fix: Focus on user-visible functionality. Document performance requirements in supplementary specifications or quality attribute scenarios.

5. Forgetting the System Boundary

Mistake: Not clearly defining what’s inside vs. outside the system, leading to confusion about scope.

Why it’s wrong: Without a clear boundary, stakeholders don’t know what you’re building vs. what’s external. This causes scope creep and misaligned expectations.

Fix: Always draw a system boundary (rectangle or box) around your use cases. Everything inside is what you’re building. Actors and external systems stay outside. This makes scope crystal clear.

Interview Tips

Be Ready to Draw on a Whiteboard

Interviewers often ask: “Design a use case diagram for [system X].” Practice drawing quickly and clearly. Start with the system boundary, add 2-3 key actors, then 4-6 main use cases. Don’t overcomplicate — simple and clear beats comprehensive and messy.

Explain Your Actor Choices

When you identify an actor, briefly justify it: “The Customer is a primary actor because they initiate orders to achieve their shopping goals.” This shows you understand the difference between primary/secondary actors and why actor identification matters.

Use Include/Extend Correctly

If asked about relationships, be precise:

  • Include: “Login includes Validate Credentials because every login must validate credentials.”
  • Extend: “Apply Discount extends Checkout because discounts are optional — not every checkout uses one.”

Misusing these relationships is a red flag that you don’t understand use case modeling.

Connect to Requirements Gathering

Mention that use case diagrams help with:

  • Stakeholder communication: Non-technical people understand what the system will do
  • Scope definition: Clear boundary prevents feature creep
  • Test case generation: Each use case becomes a set of test scenarios

This shows you understand the practical value, not just the notation.

Know When NOT to Use Them

If asked about limitations, mention:

  • They don’t show sequence or timing (use sequence diagrams)
  • They don’t show data flow (use activity diagrams)
  • They don’t show internal structure (use class diagrams)

Knowing the right tool for each job demonstrates maturity.

Practice Common Domains

Be ready to quickly sketch use case diagrams for:

  • E-commerce system (Customer, Admin, Payment Gateway)
  • Library management (Librarian, Member, Book Supplier)
  • ATM system (Customer, Bank, Maintenance Technician)
  • Social media platform (User, Moderator, Advertiser)

Having mental templates for common domains lets you respond quickly and confidently.

Key Takeaways

  • Use Case Diagrams show what a system does from the user’s perspective, focusing on external interactions rather than internal implementation details.
  • Actors are external entities (users or systems) that interact with your system; they are NOT part of the system itself.
  • Use cases represent complete user goals that provide value, not individual steps or UI actions — think “Place Order” not “Click Button”.
  • Include relationships are mandatory (base use case always needs the included one), while extend relationships are optional (enhancement that may or may not happen).
  • Use case diagrams bridge business and technical teams, making them essential for requirements gathering, scope definition, and stakeholder communication in both design and interviews.