Complete guide to UML Use Case Diagrams: learn how to model system functionality from the user's perspective. Master actors, use cases, relationships, and how to capture requirements effectively.
Table of Contents
1. What are Use Case Diagrams?
Use case diagrams model the functionality of a system from the user's perspective. They show actors (users or external systems), use cases (functionality), and the relationships between them.
Use case diagrams are typically created during the requirements analysis phase to:
- Capture functional requirements
- Define system scope and boundaries
- Communicate with stakeholders
- Identify actors and their goals
- Document system functionality at a high level
Unlike other UML diagrams that focus on how the system works internally, use case diagrams focus on what the system does from the user's viewpoint.
2. Actors
2.1 What are Actors?
An actor represents a role played by a user or external system that interacts with the system being modeled. Actors are outside the system boundary and represent anyone or anything that needs to exchange information with the system.
2.2 Actor Notation
Actors are represented as stick figures or as rectangles with the <
2.3 Types of Actors
- Primary Actors: Users who directly use the system to achieve their goals (e.g., Customer, Administrator)
- Secondary Actors: External systems or services that the system uses (e.g., Payment Gateway, Email Service)
- Supporting Actors: Actors that help the system but are not the main focus (e.g., System Administrator)
2.4 Identifying Actors
To identify actors, ask:
- Who uses the system?
- Who installs, maintains, or administers the system?
- What external systems interact with the system?
- Who gets information from the system?
- Who provides information to the system?
2.5 Actor Naming
Actors should be named:
- As roles, not individuals (Customer, not John Smith)
- As nouns (Administrator, Payment System)
- Clearly and consistently
- From the system's perspective
3. Use Cases
3.1 What are Use Cases?
A use case represents a specific functionality or service that the system provides to actors. It describes what the system does, not how it does it. A use case should represent a complete, meaningful task from the actor's perspective.
3.2 Use Case Notation
Use cases are represented as ovals or ellipses:
3.3 Use Case Characteristics
A good use case:
- Represents a complete, meaningful task
- Has a clear goal from the actor's perspective
- Produces a result of value to the actor
- Is described at an appropriate level of detail
- Is independent and can be executed independently
3.4 Use Case Naming
Use cases should be named:
- As verb phrases (Place Order, Cancel Reservation)
- In active voice (not "Order is Placed")
- From the actor's perspective
- Clearly and concisely
3.5 Use Case Levels
- Summary Level: High-level use cases covering multiple user goals (Manage Orders)
- User Goal Level: Specific tasks that provide value (Place Order, Cancel Order)
- Sub-function Level: Steps within user goals (Validate Credit Card, Calculate Total)
4. Relationships
4.1 Association
An association connects an actor to a use case, showing that the actor participates in the use case. Shown as a solid line.
4.2 Include Relationship
An include relationship means that a use case always includes the behavior of another use case. The included use case is mandatory. Shown with a dashed arrow labeled <
Example: "Place Order" always includes "Validate Payment"
4.3 Extend Relationship
An extend relationship means that a use case may (optionally) extend the behavior of another use case under certain conditions. Shown with a dashed arrow labeled <
Example: "Place Order" may be extended by "Apply Discount" if a discount code is provided
4.4 Generalization
Generalization shows that one use case is a specialized version of another, or one actor is a specialized type of another. Shown with a hollow triangle arrow.
4.5 Include vs Extend
| Aspect | Include | Extend |
|---|---|---|
| When | Always | Conditionally |
| Direction | Base includes included | Extension extends base |
| Purpose | Reuse common behavior | Add optional behavior |
5. System Boundary
5.1 What is a System Boundary?
The system boundary (also called system box) is a rectangle that represents the scope of the system being modeled. Everything inside the rectangle is part of the system; everything outside is external.
5.2 System Boundary Notation
5.3 Using System Boundaries
System boundaries help:
- Define system scope clearly
- Distinguish between system and external entities
- Organize use cases by subsystem
- Show system decomposition
5.4 Multiple System Boundaries
You can show subsystems within a larger system:
6. Best Practices
6.1 Keep Use Cases Focused
- Each use case should represent a single, complete task
- Avoid combining multiple unrelated tasks
- Keep use cases at an appropriate level of abstraction
- Focus on user goals, not system functions
6.2 Use Appropriate Detail Level
- Start with high-level use cases
- Refine into more detailed use cases as needed
- Don't include implementation details
- Focus on what, not how
6.3 Organize Use Cases
- Group related use cases together
- Use packages or subsystems for large systems
- Maintain consistent naming conventions
- Keep diagrams readable and uncluttered
6.4 Validate with Stakeholders
- Review use cases with end users
- Ensure all actors are identified
- Verify use cases cover all requirements
- Confirm use cases are understandable to non-technical stakeholders
6.5 Avoid Common Mistakes
- Don't include system functions as use cases (e.g., "Save to Database")
- Don't create use cases for every possible action
- Don't mix different abstraction levels
- Don't show data flow or system internals
0 Comments