Use Case Diagram

The UML picture of who uses a system and what they use it for. It is the fastest way to agree on scope before you draw a single class.

Overview

A use case diagram answers two questions: who interacts with the system, and what do they get from it? The people and outside systems are actors. The things they can do are use cases. A rectangle around the use cases marks the boundary of the system you are designing; everything outside it is someone else's problem.

The notation is defined in clause 18 of UML 2.5.1. An actor is a stick figure with its name nearby. A use case is an ellipse with a verb-noun name such as 'Withdraw cash'. A solid line joins an actor to each use case it takes part in. Two dashed arrows, labeled «include» and «extend», relate use cases to each other.

In an interview, this diagram is a scoping tool. When the prompt is 'design an ATM', listing the actors and use cases first shows the interviewer that you find out what the system must do before you decide how it is built. It also gives you a checklist: every use case should later have a flow (a sequence or activity diagram) and the classes that carry it out.

The parts

Actor — stick figure, name above or below — outside the boundary; a role, not a person
Use case — ellipse with a verb-noun name — a complete goal for an actor, not a step
Subject (system boundary) — rectangle with the system's name at the top — use cases inside, actors outside
Association — solid line from actor to use case — the actor takes part in that use case
Include — dashed arrow with an open head, from the base to the included use case, labeled «include» — the base always runs the included behavior
Extend — dashed arrow with an open head, from the extension to the extended use case, labeled «extend» — the extension runs only under a condition, at an extension point

An ATM, drawn

The picture below is drawn as a flowchart in the same shape: actors as grey boxes outside the boundary, use cases as rounded ellipses inside it.

Include versus extend

When it runs — always, as part of the base — only when a condition holds
Arrow points — from the base to the included use case — from the extension to the base
Base works without it? — no — yes
Why you draw it — to share a step many use cases need — to keep an optional path out of the main use case
ATM example — Withdraw cash includes Authenticate — Print receipt extends Withdraw cash

A memory aid: include is 'always happens'; extend is 'sometimes happens'. The arrows point toward the use case that is being reused or interrupted.

Finding actors and use cases

Who starts an interaction with the system? — primary actors (Customer)
Whom does the system call for help? — supporting actors (Bank network, Payment gateway)
Who maintains or configures it? — operational actors (Technician, Admin)
What does each actor want to achieve? — use cases, named verb-noun
Which steps appear in several use cases? — candidates for «include»
Which paths are optional or conditional? — candidates for «extend»

Actors are classifiers, so one actor can specialize another with the usual generalization arrow: a Premium Customer is a Customer with extra use cases. Use this when a role adds goals, not when it only differs in data.

Use cases, user stories and requirements

Use case diagram — who can do what — one picture per system — scope and actors at a glance
Use case description — how one goal plays out, step by step — half a page per use case — main and alternate flows
User story — what a user wants and why — one sentence — planning a sprint
Functional requirement — what the system shall do — one line — contracts and tests

What you will be able to do

List the actors and use cases of a design prompt in the first five minutes.
Draw the boundary, associations, «include» and «extend» with the arrows pointing the right way.
Decide whether a behavior is a step, an included use case, or an extension.
Turn each use case into the flow and classes that carry it out.

Interview questions

What is the difference between include and extend, and which way do the arrows point?
How do you identify the actors of a system?
How detailed should the diagram be?
How does a use case diagram turn into the rest of the design?
When would you use a use case diagram instead of user stories?