The use case diagram
Lesson 2 of 6
2The use case diagram
The simplest diagram in UML and the most misused. Its question is one: who wants something from the system, and what is it?, and whoever draws buttons and screens in it is drawing something else entirely.
What the picture shows: The actor stands outside the system boundary, and each oval is a goal it wants: borrow, return, search.
Map of this part
The concepts in order, click any one to jump to it:
Two ways into the same idea
A use case diagram is like the list of services on a government office door: who comes (a citizen, a clerk) and what they want done (renew an ID, pay a fee). It does not explain how the service works inside, only who asks for what. That is why a project owner who cannot code understands it.
An actor is a role outside the system (a person or another system), a use case is a goal of value to that actor, and the system boundary is a box. include and extend are used sparingly, and the classic mistake is turning cases into screen steps or functions instead of goals.
Required fundamentals
Part one
The library's four rules written in front of you, with the nouns and verbs underlined.
The idea of an actor
An actor is not necessarily a person: it may be another system or a clock. Its only requirement is being outside your system's boundary and wanting something from it.
The idea of a boundary
What is inside your system and what is outside. Without that line the whole diagram is meaningless.
Core concepts
Who wants something from the system, and what is it? Not how it is achieved, not in what order, not on which screen. Only “who” and “what”.
A role, not a person. “Member” is an actor; “Ahmed” is not. And a librarian who borrows a book for himself is playing the Member role at that moment, which is why we draw roles, not names.
A complete goal ending in value for the actor, named verb + object: “Borrow a copy” yes; “The borrow button” no; “Check the database” no, because it is an internal step nobody wants for its own sake.
The rectangle around the use cases. Actors are always outside it. And the single biggest fix for a bad diagram is drawing that rectangle first and asking: is this thing our responsibility or someone else's?
«include»: a step that always happens inside the use case, factored out because it is shared, checking eligibility inside borrowing. «extend»: optional behaviour added in a special case, reserving when no copy is available. The difference between them: “always” versus “sometimes”.
This diagram describes no order, no exceptions and no data. Whoever crams detail into it gets a diagram that is neither readable nor answerable, and usually they wanted an activity diagram.
How it works
Diagram 1, Our library: two circles are actors, the rectangles are use cases, the dashed lines are include and extend
Diagram 2, A two-question test that rules out most of what is wrongly drawn here
| Candidate | A use case? | Why |
|---|---|---|
| Borrow a copy | ✅ Yes | An external actor, and complete value for them |
| Search the catalogue | ✅ Yes | Both member and librarian want it |
| Log in | ⚠️ Usually not | Not a goal in itself; draw it as «include» if it recurs |
| Check eligibility | ➖ A step | Nobody wants it for its own sake, «include» inside borrowing |
| Click the “Borrow” button | ❌ No | An interface detail, not a goal |
| Save the row to the table | ❌ No | An internal step with no actor |
| Send an overdue notice | ✅ Yes | Its actor is a clock, an actor need not be human |
The exercise: from four rules to a diagram and a narrative
Back to the library's four rules, extracting the diagram in five steps. Notice that each step rejects as much as it accepts:
| «include» | «extend» | |
|---|---|---|
| When does it happen? | Always | Sometimes, on a condition |
| Who knows whom? | The base case knows the included one | The extending one knows the base |
| Our example | Check eligibility | Reserve an unavailable copy |
| In code | A call in the main path | A conditional branch |
| If you delete it? | The base case becomes incomplete | The base case stays sound |
The use case narrative: what the drawing does not show
The diagram says “Borrow a copy” and does not say how. What is missing is written beside it in prose, and this is the part a programmer actually reads:
Use case: Borrow a copy Actor: Member Precondition: The member is registered and the copy is held by the library Main path: 1. The member requests a specific copy 2. The system checks eligibility «include» 3. The system records the loan and sets a due date 4. The system tells the member the due date Alternative paths: 2a. The member is overdue -> refuse, explain why 2b. The member holds 5 copies -> refuse, state the limit 1a. The copy is already on loan -> offer a reservation «extend» Postcondition: The copy is unavailable and the member's loan count is one higher
Myth vs. reality
| The myth | The reality |
|---|---|
| “An actor is always a human.” | The clock that sends the overdue notice is an actor, and an external payment system is an actor. The requirement: outside the boundary and wanting something. |
| “Log in is a primary use case.” | It is not a goal in itself: nobody opens the system in order to log in. Draw it as «include» if you need it. |
| “Every screen is a use case.” | One screen may serve three use cases, and one use case may span five screens. They are unrelated. |
| “«include» and «extend» are much the same.” | One is “always” and the other “sometimes”, and each becomes different code: a call in the path versus a conditional branch. |
| “The diagram is enough, we do not need a narrative.” | The diagram says “what”; the narrative gives the alternative paths and the conditions. A programmer builds from the second. |
| “A bigger diagram means deeper analysis.” | A diagram with thirty use cases is unreadable. Depth lives in the narrative, not in the number of ovals. |
Try it yourself
“Check eligibility” happens on every borrow without exception. How do you connect it?
“Always” means «include». Drawn as «extend» it becomes a conditional branch in code, so a copy could be borrowed without any check, a functional bug, not a cosmetic one. The first option is wrong because a member does not want “having their eligibility checked” as a goal.
Which name works as a use case?
Verb + object from the actor's point of view, ending in clear value. The first is an administrative function covering several goals, the second a screen, the fourth a technical component, none of them a goal an actor wants.
Quick review flashcards
Check your understanding
1. In one sentence: why is “click the Borrow button” not a use case?
Because the actor does not want to press a button, they want a copy in their hands. The button is a replaceable means: if borrowing became a QR scan or a voice command, the use case “Borrow a copy” would stay exactly as correct.
2. Explain in detail how «include» and «extend» become different code.
«include» means the step is part of the use case's definition, so it becomes an unconditional call in the main path: every borrow calls the check, and if the check fails the borrow fails. «extend» means behaviour added on a condition, so it becomes a branch: if the copy is unavailable a reservation is offered, and otherwise none of that code runs. The practical difference is that confusing them yields a system that borrows without checking, or reserves for no reason.
3. (Spot the bug) A diagram has an actor “Database” with an arrow to “Save the loan”. What is wrong?
The database is inside the system boundary, so it is not an actor, an actor must be outside the boundary and want something, and a database wants nothing. And “Save the loan” is an internal step that is nobody's goal. The correct version: the actor is Member, the use case is “Borrow a copy”, and saving is an implementation detail that appears in a sequence diagram.
4. The client wants to add “online payment of fines”. How does that appear in the diagram?
A new non-human actor: the payment gateway, outside the boundary. And a use case “Pay a fine” for the member, including “Check the fine amount”. Note the gateway is a secondary actor: the system calls it rather than it initiating the use case, and a secondary actor is drawn on the far side of the use case.
5. (Decision) Your manager asks for one use case diagram covering a system with 40 functions. Your answer?
That a single diagram will be unreadable, and that the number itself is a signal that “the system” is really several systems. The alternative: split by actor or by domain (lending, cataloguing, memberships, reporting) and draw one diagram per domain, with narratives for its three most important use cases. The success measure for this diagram is that it reads in a minute, so if it needs a spoken explanation, it has failed at its job.
Resources for this part
Sorted by kind: start with the official docs when you want the precise reference, or with an article or video when you want the explanation first.
Resources for this lesson
Grouped by type. Start with the official docs for precision, or an article or video for the explanation.
Done with this lesson?
Sign in to save your progress.