Use Case Diagram

A use case diagram provides a high-level visual representation of a system's functionality from the user's perspective. It shows what the system does (not how it does it) by identifying the actors who interact with the system and the use cases (goals) they can accomplish. Use case diagrams are typically the first UML diagrams created during requirements analysis because they establish system scope and communicate functionality to non-technical stakeholders in an intuitive visual format.

Core Elements

Actor: An entity external to the system that interacts with it to accomplish a goal. Actors are typically humans (Customer, Administrator, Manager) but can also be external systems (Payment Gateway, Email Service, Sensor Network). Actors are drawn as stick figures with their role name below.

Use Case: A specific piece of functionality the system provides—a goal an actor can accomplish. Use cases are drawn as ovals with the use case name inside (e.g., "Place Order," "Generate Report," "Reset Password"). Each use case represents a complete, meaningful interaction that delivers value to an actor.

System Boundary: A rectangle that encloses all use cases, representing the scope of the system. Actors are outside this boundary; use cases are inside. This visually distinguishes what is part of the system from what is external.

Associations: Lines connecting actors to use cases they participate in. A simple line (no arrowhead) indicates the actor interacts with that use case.

Relationships Between Use Cases

Include (<<include>>): A use case that always incorporates the behavior of another use case. The included use case is not optional—it executes every time the base use case executes. Drawn as a dashed arrow from the base use case to the included use case.

Example: "Place Order" always includes "Verify Payment"—you cannot place an order without verifying payment.

Extend (<<extend>>): A use case that optionally adds behavior to another use case under certain conditions. The extending use case only executes when specific conditions are met. Drawn as a dashed arrow from the extending use case to the base use case.

Example: "Apply Coupon" extends "Place Order"—applying a coupon is optional and only occurs when the customer has a coupon code.

Generalization: An inheritance relationship between actors or between use cases. A specialized actor inherits all use cases of its parent and may have additional ones. A child use case inherits the behavior of its parent and modifies or extends it.

Example: "Premium Customer" generalizes "Customer"—premium customers can do everything regular customers can, plus additional actions like "Access Priority Support."

Real-World Example: Library Management System

This diagram immediately communicates: Members can search, borrow, return, and reserve books. Borrowing always checks availability (include). Returning sometimes requires paying a late fee (extend). Librarians manage the catalog and members. Admins configure the system.

Writing Use Case Descriptions

Each oval in the diagram is typically accompanied by a detailed use case description:

Use Case: Borrow Book Actor: Library Member Preconditions: Member is logged in, book exists in catalog Main Success Scenario:

1. Member searches for and selects a book
2. System checks book availability (<<include>> Check Availability)
3. System verifies member has no overdue books
4. System records the loan with due date (14 days)
5. System updates book status to "On Loan"
6. System sends confirmation email to member

Alternative Flows:

• 2a. Book is not available → System shows waitlist option
• 3a. Member has overdue books → System blocks borrowing until resolved

Postconditions: Book is checked out to member, due date is set

Common Mistakes

Too many use cases: Including every system function (even trivial ones) clutters the diagram. Focus on significant user goals, not individual buttons or screens. "Manage User Profile" is a use case; "Click Save Button" is not.

Functional decomposition: Breaking use cases into sub-steps creates a hierarchy that belongs in activity diagrams, not use case diagrams. Each use case should represent a complete goal.

Overusing include/extend: These relationships should be used when they clarify the diagram, not to show every possible shared behavior. If every use case includes "Authenticate User," the relationship is obvious and can be omitted.

Actor confusion: Actors represent roles, not individuals. One person might play multiple roles (a librarian who is also a member). Different systems playing the same role are the same actor.

When to Use Use Case Diagrams

Use case diagrams excel during requirements gathering to establish system scope and stakeholder agreement on what the system will do. They communicate effectively with non-technical stakeholders because the notation is intuitive. They serve as the foundation for more detailed analysis—each use case becomes a candidate for sequence diagrams, activity diagrams, and test scenarios.