UML use case diagrams
The diagram for scope, not design. Who uses the system, what they use it for, and where the boundary of the thing you are building actually sits - drawn before a single class exists.
8 min readUML 2.5.14 of 15
01What it shows, and what it deliberately does not
A use case diagram is a map of scope. It names the people and systems that interact with what you are building, the goals they come to it with, and the line between inside and outside. That is all it does, and its restraint is the point.
It says nothing about order. Nothing about screens, fields, or algorithms. Nothing about how anything works. Every one of those is a different diagram, and the temptation to smuggle them onto this one is what produces the sprawling, useless use case diagrams that gave the notation a bad reputation.
02The four marks
| Element | Notation | What it means |
|---|---|---|
| Actor | stick figure | A role outside the system - a person, another system, or a clock. A role, not a named individual: Merchant, never Anna. |
| Use case | ellipse | A goal the system delivers, named verb-first. |
| System boundary | rectangle | The subject. Use cases go inside it, actors always outside. Its name is the thing you are building. |
| Association | This actor participates in this use case. No arrowhead needed. | |
| Include | Dashed arrow from the base to the included case. The included behaviour always runs. | |
| Extend | Dashed arrow from the extension to the base. The behaviour runs only sometimes. | |
| Generalization | Hollow triangle at the general one. Works between actors and between use cases. |
03Include and extend, without the confusion
These two are the reason use case diagrams get drawn wrong. Both are dashed arrows with a keyword, and they point in opposite directions.
«include» points from the base to the thing it always does. Read it as "calls". In the diagram above, Submit payment includes Authorize payment: you cannot submit without authorizing. It exists to factor out behaviour shared by several use cases - which is exactly why Refund payment includes it too.
«extend» points from the optional extra back to the base. Read it as "may interrupt". Log audit trail extends Refund payment: refunds work without it, and it happens under some condition. The base use case does not know its extensions exist.
04When to draw one
Reach for it when
- Agreeing scope at the start of a project, with people who do not read code
- Working out which external systems you actually depend on
- Producing a checklist that a test plan or a backlog can be derived from
- Showing that a requirement belongs to somebody else's system, not yours
Reach for something else when
- You want to show a sequence of steps - that is an activity or sequence diagram
- The system has one actor and four use cases; a bulleted list is clearer
- You are tempted to decompose use cases into sub-use-cases three levels deep
- The audience is engineers who need the design, not the scope
A useful use case diagram fits on one page and has somewhere between three and ten ellipses. It is a table of contents, not the book. The detail belongs in use case descriptions - the numbered main flow and its alternatives - or, if the flow is branchy enough to be worth drawing, in an activity diagram per use case.
05Common mistakes
- Functional decomposition. Twenty ellipses named after buttons. Use cases are goals; if it is not something an actor wants, it does not belong.
- Actors named after people or job titles in your org chart. Model the role. One person can be several actors, and one actor can be a batch job.
«include»and«extend»arrows reversed. They point opposite ways. Apply the removal test above.- Actors inside the boundary. The boundary is what you are building. An actor is by definition outside it.
- Sequencing implied by vertical position. A use case diagram has no time axis. Nothing about the layout says what happens first.
In one line each
- 01Use case diagrams answer who and what for - never how or in what order.
- 02A use case is a goal that delivers value to an actor, named verb-first.
- 03Actors are roles and always sit outside the boundary rectangle.
- 04«include» points from the base to behaviour that always runs.
- 05«extend» points from the optional extra back to the base.
- 06Three to ten use cases on one page; the detail lives in descriptions, not on the canvas.
Related reading