Loading learning content...
Read aloud is unavailable in this browser.
Every software system exists to serve users. Yet the journey from understanding what users need to building software that meets those needs is fraught with miscommunication, ambiguity, and missed expectations. Use case diagrams represent one of the most powerful tools in a system designer's arsenal for bridging this gap—providing a visual language that both technical and non-technical stakeholders can understand.
At their core, use case diagrams answer a deceptively simple question: Who interacts with our system, and what can they do? This seemingly straightforward question, when answered rigorously, reveals the functional scope of any software system and establishes a shared understanding between everyone involved in building it.
By the end of this page, you will understand the fundamental concepts of actors and use cases—the two primary building blocks of use case diagrams. You'll learn how to identify actors from different perspectives, define meaningful use cases that capture user goals, and understand why these diagrams remain essential in modern software development despite being a decades-old technique.
A use case diagram is a behavioral UML diagram that captures the functional requirements of a system from the user's perspective. Unlike class diagrams (which show structure) or sequence diagrams (which show interactions over time), use case diagrams operate at the highest level of abstraction—depicting what a system does without specifying how it accomplishes those functions.
Historical Context:
Use case diagrams emerged from the pioneering work of Ivar Jacobson in the late 1980s while he was at Ericsson developing object-oriented software engineering methods. Jacobson observed that capturing requirements from the user's perspective—rather than from a technical or data-centric viewpoint—produced systems that better aligned with actual user needs. His approach was later incorporated into the Unified Modeling Language (UML) and became a standard technique in software engineering.
The Core Philosophy:
Use case diagrams embody a fundamental principle: requirements should be expressed in terms of user goals, not system internals. This perspective shift is profound. Instead of asking 'What data should the database store?' or 'What modules should we build?', use case modeling asks 'What does the user want to accomplish?' This user-centric approach ensures that technical decisions are always traceable to actual user value.
Use case diagrams force you to think from the outside-in rather than the inside-out. This seemingly simple shift in perspective is why they remain valuable even in agile environments—they keep the team focused on delivering user value rather than building features for features' sake.
Key Characteristics of Use Case Diagrams:
Use case diagrams possess several defining characteristics that distinguish them from other modeling techniques:
An actor is any entity that interacts with the system from outside its boundaries. Actors represent the different roles that users, other systems, or external forces play in relation to your system. Understanding actors is crucial because they define the context in which your system operates and the expectations it must satisfy.
The Critical Distinction: Actors Are Roles, Not Individuals
A common misconception is that actors represent specific people. They do not. Actors represent roles. A single person might play multiple actor roles, and a single actor role might be played by many different people. This abstraction is intentional—it focuses on the relationship between the role and the system, not on individual identity.
| Actor Type | Description | Examples | Representation |
|---|---|---|---|
| Primary Actor | The main initiator who triggers usage; the 'hero' of the use case whose goal is being served | Customer, Administrator, Employee | Stick figure on the left side of the diagram |
| Secondary Actor | Provides services to the system; the system depends on them to fulfill a use case | Payment Gateway, Email Service, Authentication Provider | Stick figure on the right side |
| Human Actor | A person who interacts with the system | End User, Support Agent, Manager | Stick figure (standard UML notation) |
| System Actor | An external system or hardware that interacts with your system | Database, Third-party API, IoT Device | Stick figure with «system» stereotype or box notation |
| Time Actor | Represents scheduled or time-triggered events | Cron Job, Scheduled Report, System Timer | Often shown as an actor with «timer» stereotype |
The Art of Actor Identification:
Identifying actors is not merely listing job titles or system names. It requires deep analysis of who has stakes in the system and how those stakes manifest as interactions. Consider these guiding questions:
For Human Actors:
For System Actors:
Don't confuse actors with system components. The database is inside your system boundary—it's not an actor. If you find yourself listing internal components as actors, you're breaking the 'external entity' rule. Also avoid overly generic actors like 'User'—if different users have different goals, they should be different actors.
Actor Generalization:
Actors can have inheritance relationships, just like classes. When one actor inherits from another, they inherit all use cases associated with the parent actor while potentially having additional ones. This is particularly useful for modeling permission hierarchies.
Example: In an e-commerce system:
This generalization reduces duplication and makes role hierarchies explicit in your diagrams.
A use case represents a complete, discrete interaction between an actor and the system that delivers value to the actor. The key word is 'complete'—a use case should represent a meaningful goal achievement, not an arbitrary step in a larger process.
The Essence of a Good Use Case:
Alistair Cockburn, a leading expert on use case modeling, introduced the concept of 'goal levels' to help identify appropriate use case granularity. A well-formed use case should represent a user goal—something an actor wants to accomplish in a single sitting that leaves them satisfied.
The 'Boss Test': Imagine an employee telling their boss, 'I just finished [action].' If the boss would say 'Good work, what's next?' it's probably a good use case. If the boss would say 'So what? Keep going,' it's probably too low-level.
The 'Complete Transaction Test': A use case should complete a transaction from the actor's perspective. 'Place Order' is complete—when done, the customer has committed to a purchase. 'Enter Shipping Address' is incomplete—it's just a step toward placing an order.
Use Case Naming Conventions:
Use cases should be named with verb-object phrases written in active voice. The verb should express what the actor accomplishes, and the object should be the thing they're acting upon. This naming convention makes use cases immediately understandable:
The Goal-Level Hierarchy:
Use cases operate at different levels of abstraction. Understanding these levels helps you model at the right granularity:
| Level | Description | Example | Typical Use |
|---|---|---|---|
| Summary/Cloud | Very high-level, multiple user goals | 'Manage Customer Relationship' | Business capability overview |
| User Goal/Sea Level | Standard use case, one sitting | 'Place Order' | Primary use case level |
| Subfunction/Fish | Below water, supporting function | 'Authenticate User' | Included/shared functionality |
Most use cases in your diagrams should be at the 'sea level'—user goal level. Summary-level use cases are useful for high-level overviews, and subfunction-level use cases typically exist to be «included» by multiple user-goal level use cases.
Use Case Documentation Beyond the Diagram:
While the diagram itself shows use case names and their relationships to actors, each use case should be accompanied by narrative documentation called a use case specification or use case description. This specification captures:
The diagram provides the overview; the specifications provide the details.
Use case diagrams employ a minimal visual vocabulary intentionally. The simplicity is a feature—it keeps diagrams accessible to non-technical stakeholders while still conveying essential information about system scope and actor interactions.
The Core Visual Elements:
| Element | Symbol | Purpose | Placement Guidelines |
|---|---|---|---|
| Actor | Stick figure | Represents external entity that interacts with the system | Left side for primary actors, right side for secondary actors |
| Use Case | Oval/ellipse | Represents a complete user goal or system function | Inside the system boundary, labeled with verb-object phrase |
| System Boundary | Rectangle | Defines the scope of the system being modeled | Encloses all use cases; actors remain outside |
| Association | Solid line | Shows that an actor participates in a use case | Connects actor to use case; no arrowhead needed for basic association |
| System Name | Label | Identifies the system or subsystem being modeled | Top of the boundary rectangle |
Association Lines:
The solid line connecting an actor to a use case represents participation. It's called an association and indicates that the actor participates in that use case. Some modeling conventions include:
In practice, keeping associations as simple solid lines without arrowheads is most common because the directionality is usually clear from context.
Reading a Use Case Diagram:
When reading a use case diagram, follow this pattern:
This systematic reading reveals the functional scope and the actor-to-functionality mapping.
Place primary actors (who initiate interactions) on the left side of your diagram and secondary actors (who provide services) on the right. This left-to-right flow mirrors how we read and creates intuitive visual hierarchy. Keep the diagram uncluttered—if it's getting crowded, consider splitting into subsystem diagrams.
Let's walk through a comprehensive example that demonstrates actor and use case identification in practice. Consider designing a use case model for an e-commerce platform.
Step 1: Stakeholder Analysis
Before drawing anything, we identify everyone who has a stake in the system:
Step 2: Actor Identification
From our stakeholder analysis, we derive actors:
| Actor | Role Type | Primary Goals |
|---|---|---|
| Guest | Human, Primary | Browse catalog, search products |
| Registered Customer | Human, Primary | All guest functions + purchase, track orders, manage profile |
| Seller | Human, Primary | Manage listings, fulfill orders, view analytics |
| Administrator | Human, Primary | Manage users, configure policies, view reports |
| Support Agent | Human, Primary | Resolve tickets, process refunds, assist customers |
| Payment Gateway | System, Secondary | Process payments, handle refunds |
| Shipping Provider | System, Secondary | Calculate rates, track shipments |
| Inventory System | System, Secondary | Track stock levels, receive updates |
Step 3: Use Case Identification
For each actor, we identify their goals and translate them into use cases:
Customer-Centric Use Cases:
Seller-Centric Use Cases:
Administrator-Centric Use Cases:
Notice how each use case passes the 'boss test.' A customer can say 'I just placed an order' and feel satisfied. A seller can say 'I created a product listing' and have accomplished a complete goal. Some use cases like 'Process Payment' might be candidates for «include» relationships—they support other use cases rather than being directly valuable to actors.
Step 4: Actor-Use Case Association
Now we connect actors to their use cases. Note that:
Key Insights from This Analysis:
This systematic approach ensures comprehensive coverage while maintaining appropriate abstraction.
Even experienced practitioners make mistakes when creating use case diagrams. Understanding these pitfalls helps you avoid them and create more effective models.
Use case diagrams can become an end in themselves. Remember: the goal is shared understanding and clear requirements, not a perfect UML diagram. If spending more time on the diagram than discussing requirements with stakeholders, the model is failing its purpose.
Use case diagrams are not always the right tool. Understanding their strengths and limitations helps you apply them effectively.
Use Case Diagrams Excel When:
Use Case Diagrams Are Less Suitable When:
| Context | Value of Use Cases | Recommended Approach |
|---|---|---|
| Agile/Scrum Projects | Medium — Can seed product backlog and define epics | Use lightweight use case lists rather than formal diagrams; elaborate in user stories |
| Waterfall Projects | High — Formal requirements documentation | Full use case specification with detailed documentation |
| API Design | High — Defines capabilities for API consumers | Map use cases to API endpoints; actors become API consumers |
| Microservices | High — Helps define service boundaries | Use case diagrams per service; actors may be other services |
| System Integration | High — Identifies integration points | Focus on system actors and data exchange use cases |
| Startup/MVP | Medium — Helps scope minimum viable features | Keep minimal; focus on primary actor, primary use cases only |
The Agile Adaptation:
In agile environments, use case diagrams are often adapted rather than abandoned. A common approach:
The formality of traditional use case modeling is reduced, but the core concept—understanding user goals before building—remains valuable.
We've established the foundation of use case modeling. Let's consolidate the essential concepts:
What's Next:
Now that we understand actors and use cases—the fundamental building blocks—we need to understand how to define what's inside versus outside our system. The next page explores system boundaries: how to scope your system, what belongs inside the boundary, and how boundary decisions affect your entire design.
You now understand actors and use cases—the two primary elements of use case diagrams. You can identify different types of actors, define meaningful use cases at appropriate granularity, and understand the notation used to represent them. Next, we'll explore how system boundaries define the scope of your modeling efforts.