Use case diagram examples
Two use case diagrams of systems everybody already understands, plus one drawn deliberately wrong - because the mistake that ruins most use case diagrams is far easier to recognise than to define.
8 min readUML 2.5.112 of 35
01Example 1: a library system
The library is the standard first example for a reason: everybody already knows the domain, so the only thing left to look at is the notation. Two actors, five use cases, and a boundary that says which of them the software is responsible for.
Notice what the ellipses are. Borrow book is a goal - a member wants to leave with a book - and it stays a goal whether the counter is a person, a self-service kiosk or an app. That independence from mechanism is the test for a use case: if replacing the interface would change the label, the label is a step.
Two relationships are doing real work. Check membership is included by Borrow book, meaning it always happens as part of it and the arrow points from the borrower to the included behaviour. It has no actor of its own, and that is correct - nobody arrives at the library wanting their membership checked. Pay overdue fine extends Return book: it happens only sometimes, and the arrow points the other way, from the optional behaviour into the base.
02Example 2: an online store, with an external system
The second example adds the piece most first diagrams leave out: a system you depend on and do not control.
The Payment gateway is a secondary actor. It initiates nothing - the customer starts everything on this diagram - but the system calls out to it, so it belongs outside the boundary with a line into the use case that needs it. Drawing it is how a use case diagram earns its keep in a scoping conversation: the boundary now shows exactly which behaviour you are on the hook for and which you are buying.
Apply discount code extends Place order because most orders do not have one. If nearly every order did, it would be an include instead. The question is not whether the behaviour is important, it is whether it always happens.
Four ellipses is a reasonable size. A real store has hundreds of behaviours, and the diagram does not grow to match - you draw one per conversation, scoped to the question being asked, which is the discipline scoping a model is about.
03Example 3: the same notation used badly
Most bad use case diagrams are bad in exactly one way, and it is worth seeing once.
Four ellipses, one actor, a boundary, no notation errors at all - and the diagram is worthless. Every label is a step in a user interface rather than a goal a person has. Nobody wants to enter a username; they want to log in, and even that is usually only in service of something else.
The whole diagram collapses to a single use case, and the four steps belong in its text description or, if the branching genuinely matters, in an activity diagram. That is the standard repair: sequence goes to activity, goals stay here.
04Adapting these to your system
The two good diagrams above are the same diagram with different nouns, which is the useful thing about the notation - once the shape is in your hand, the next one takes ten minutes.
Reach for it when
- Goals a user would name, phrased as verb plus object: place order, borrow book.
- A boundary drawn around exactly one system, with actors outside it.
- Secondary actors for every external service the system calls, so dependencies are visible.
- Include for behaviour that always happens; extend for behaviour that sometimes does.
Reach for something else when
- Interface steps - click, enter, select, submit. They are not goals.
- CRUD sprayed across the diagram: create, read, update and delete a thing is one use case, not four.
- Plain lines between two ellipses. Only include, extend and generalization are legal there.
- More than about a dozen ellipses. Split by actor or by subsystem instead.
05What to remember
In one line each
- 01A use case is a goal that survives an interface redesign. If the label would change, it is a step.
- 02Include points from the base to the always-included behaviour; extend points from the optional behaviour back to the base.
- 03Included use cases have no actor of their own, and that is correct.
- 04Secondary actors are what makes the diagram useful in a scoping conversation.
- 05Three to a dozen ellipses. Past that, the diagram has become a list of screens.
06Common questions
What is a good example of a use case diagram?
A library system: a Member searches the catalogue, borrows and returns books; a Librarian handles the counter side of the same two; borrowing includes a membership check; and paying an overdue fine extends returning. Two actors, five ellipses, one boundary is a complete diagram.
Is log in a use case?
Usually not on its own. Nobody opens an application in order to log in - they log in to do something else, so the goal is the something else. Draw it as an included use case where several goals genuinely require it, or leave it off entirely when it adds nothing to the scope conversation.
How many use cases should one diagram have?
Somewhere between three and about a dozen. Fewer than three and a sentence would have done; more than a dozen and the ellipses are steps rather than goals, or the system boundary has been drawn around two systems.
Can two use cases be connected by a plain association?
No. Associations run between an actor and a use case only. Between two use cases the legal relationships are include, extend and generalization, and a plain line between two ellipses is the sign that somebody is drawing a sequence of steps rather than a set of goals.
What is a secondary actor in a use case diagram?
An external party the system calls out to rather than one that initiates anything: a payment gateway, an identity provider, a mail service. It is drawn as an actor on the opposite side of the boundary, and it is the part of the diagram that shows what you depend on but do not control.
Related reading