Unit 3: Use Case Diagrams
Learning Objectives
- Identify actors, use cases, and system boundaries in a use case diagram
- Distinguish between «include» and «extend» relationships
- Evaluate a use case diagram for appropriate abstraction and completeness
Core Input
Read through each tab before moving to the key concepts below.
A use case diagram contains three core elements:
- Actor — drawn as a stick figure. Represents any entity outside the system boundary that interacts with the system: a human user, an external system, or a hardware device. Actors are named by role, not by person (Student, not John).
- Use case — drawn as an ellipse with a name inside. Represents a goal that an actor wants to achieve using the system. Each use case is a meaningful unit of functionality from the actor's perspective. Named with a verb phrase: Book Room, Submit Assignment, Generate Report.
- System boundary — drawn as a rectangle. The use cases sit inside it; the actors sit outside. The name of the system is written at the top of the rectangle.
Four relationship types are used in use case diagrams:
- Association — a plain line between an actor and a use case. It means the actor participates in that use case.
- «include» — a dashed arrow from one use case to another, labelled «include». The base use case always triggers the included use case. Use this for shared sub-flows. Example: Book Room «include» Check Availability.
- «extend» — a dashed arrow from an extending use case to the base use case, labelled «extend». The extension occurs only under a specified condition. Example: Apply Discount «extend» Process Payment — only when a discount code is entered.
- Generalisation — a solid line with a hollow arrowhead, used between actors (a Student is a kind of User) or between use cases (a Pay by Card is a kind of Make Payment).
Use case diagrams are easy to misuse. Common mistakes and how to avoid them:
- Wrong level of abstraction — use cases should represent meaningful goals, not low-level steps. Click Submit Button is not a use case; Submit Assignment is.
- Too many «include»/«extend» relationships — these add complexity. Use them only when a sub-flow is genuinely reused across multiple use cases, or when an extension is clearly conditional and optional.
- Confusing actors with roles — an actor is a role, not a person or system name. One person can play multiple roles; one role can be played by multiple people.
- Putting processes inside the diagram — a use case diagram shows what users want to do, not how the system does it. Sequence and activity diagrams handle the how.
Key Concepts: Diagram Elements
Expand each item and think about your answer before reading the explanation.
An actor is anything outside the system boundary that interacts with the system. The three most common types are:
- Human users — roles such as Student, Lecturer, Administrator. Named by role, not by person.
- External systems — another software system that exchanges data with yours, such as a Payment Gateway or Email Service. Drawn as a stick figure with a label clarifying it is a system, or sometimes as a box.
- Time — a system can be triggered by a clock event (e.g. a nightly report). Time is an actor when no human initiates the interaction.
Crucially: actors are not part of the system. They sit outside the boundary rectangle.
A use case should be named with a clear verb + noun phrase that describes the actor's goal — not the system's internal process.
- ✓ Submit Assignment — describes what the student wants to achieve
- ✗ Process File Upload — describes what the system does internally
- ✓ View Booking History — clear actor goal
- ✗ Database Query — an implementation detail, not a goal
A useful test: could the actor walk up to a desk and ask a human to do this for them? If yes, it is probably a good use case. If it sounds like a technical process, it probably belongs in a sequence or activity diagram, not here.
The rectangle defines the scope of the system being modelled. Everything inside it is the responsibility of the system you are building. Everything outside it is an actor — something you must interface with but do not control.
The boundary is not a physical container — it is a design decision. For example, a payment process could be handled by your system or delegated to a payment gateway. Where you draw the boundary determines how much your system must implement.
The system name is written at the top of the rectangle, making it clear which system the diagram describes.
There is no fixed number, but a common guideline is 5–15 use cases per diagram for a readable level of abstraction. More than that usually means you have gone too low-level.
For large systems, it is better to draw multiple use case diagrams — one per major subsystem or actor — rather than cramming everything onto one diagram.
Remember: the purpose of the diagram is communication. If it takes more than a few minutes to read and understand, it is too complex.
Key Concepts: Relationships
The relationships between use cases are the most commonly misunderstood part of this diagram type. Work through each item carefully.
An association is drawn as a plain solid line between an actor and a use case. It simply means: this actor participates in this use case.
An association has no arrowhead by convention (or sometimes a unidirectional arrow showing who initiates). It does not imply any ordering, frequency, or conditionality — those details belong in other diagrams.
Every use case must have at least one actor associated with it. A use case with no actor is a design error — if nothing can initiate or benefit from a use case, it should not be in the system.
An «include» relationship means: whenever the base use case is performed, the included use case is always performed as part of it.
Drawn as a dashed arrow from the base use case to the included use case, labelled «include».
When to use it:
- When a sub-flow is mandatory and reused across multiple use cases
- When the included behaviour is complex enough to deserve its own description
Example:
Book Room «include» Check Availability
Reserve Equipment «include» Check Availability
Here, Check Availability is shared between two use cases — «include» models this cleanly.
Common mistake: using «include» for every sub-step. Only use it when the included behaviour is genuinely reused or meaningfully complex.
An «extend» relationship means: the extending use case adds optional behaviour to the base use case — but only under a specified condition.
Drawn as a dashed arrow from the extending use case to the base use case (note the direction is reversed from «include»), labelled «extend».
When to use it:
- When a behaviour is optional and conditional
- When the base use case is complete without the extension
Example:
Apply Discount Code «extend» Process Payment
Payment processing happens without a discount code. Applying a discount is optional and
occurs only when the user provides one.
Key distinction: «include» is about what always happens; «extend» is about what sometimes happens.
Generalisation expresses an is-a relationship — the same concept used in class diagrams. It is drawn as a solid line with a hollow triangle arrowhead pointing to the parent.
Between actors:
A Registered User and a Guest are both kinds of User.
Both can access public use cases; Registered User additionally accesses
protected ones. The child actor inherits the parent's associations.
Between use cases:
Pay by Card and Pay by Bank Transfer are both kinds of Make Payment.
Use case generalisation is less common than actor generalisation and should be used sparingly.
Watch
Video coming soon
Check Your Understanding
Select the best answer for each question.
In a use case diagram, which element represents a user or external system that interacts with the system?
The use case 'Book Room' always requires 'Check Availability' to run first. Which relationship should you use?
Activities
Individual task
Using the group system from Unit 1, draw a use case diagram. Your diagram should include:
- At least three actors
- At least five use cases inside the system boundary
- At least one «include» relationship
- At least one «extend» relationship (if applicable)
Draw the diagram on paper or using a tool of your choice (draw.io, Lucidchart, or similar). Be prepared to explain your choices.
Pair task
Exchange diagrams with a partner and review theirs against these criteria:
- Abstraction — are the use cases at the right level? Any that sound like internal processes (not actor goals)?
- Completeness — do the use cases cover the requirements from Unit 2? Are there any obvious gaps?
- Relationships — are any «include»/«extend» relationships missing or misused?
- Naming — are all use cases named with a clear verb + noun phrase?
Provide written feedback on at least two specific improvements.
Group task
As a group, produce a single shared use case diagram for your system.
- Start from the individual diagrams and identify points of agreement and disagreement.
- Resolve naming conflicts — choose the clearest use case names.
- Agree on the correct use of «include» and «extend» for any shared sub-flows.
- Ensure the diagram reflects the requirements agreed in Unit 2.
This shared diagram will be used as input for Unit 4 (Class Diagrams). Keep it accessible.
Review
- Actor — a role outside the system boundary that interacts with the system
- Use case — a goal that an actor can achieve using the system (verb + noun name)
- System boundary — the rectangle that defines scope
- Relationships — association, «include», «extend», generalisation
Each use case corresponds to one or more functional requirements. The actors correspond to stakeholders. The system boundary represents the scope defined during requirements analysis.
A use case diagram does not replace the requirements list — it visualises it, making it easier to identify gaps and communicate scope to non-technical stakeholders.
Proceed to Unit 4: Class Diagrams — Structure I when ready.