Use Case Diagrams — Low Level Design

Summary#

A use case diagram answers exactly one question: who interacts with this system, and to do what? It is the cheapest UML diagram to produce — five shapes, two minutes of board time — and the one most consistently skipped by candidates who then realise twenty minutes later they have been designing for the wrong actor.

Three primitives carry the entire notation:

Actor — a stick figure outside the system boundary, representing a role (not a person). “Driver,” not “Sangeeta.” “External payment service,” not “Stripe.” A single human can play multiple actors; a single actor can be played by multiple humans or another system.
Use case — an ellipse inside the system boundary, labelled with a goal-level verb phrase from the actor’s perspective. “Park vehicle,” “Retrieve vehicle,” “Pay fare.” Not “click button” (too low-level), not “use parking lot” (not a goal).
System boundary — a labelled rectangle enclosing the use cases. Anything outside it is an actor; anything inside is the responsibility of the system you are designing.

Two relationships refine the picture without adding nouns:

`<<include>>` — a use case that always invokes another. “Pay fare” `<<include>>` “Print receipt” if every payment is always followed by a receipt.
`<<extend>>` — a use case that conditionally augments another. “Pay fare” `<<extend>>` “Apply loyalty discount” — the extension fires only when an extension point is reached.

That is the entire notation a candidate needs to draw a competent use case diagram in any LLD round.

Why it matters#

The use case diagram is not for the code; it is for the conversation. Three failure modes the diagram prevents in five minutes of board time:

The first is scoping the wrong system. The interviewer says “design a parking lot,” and the candidate hears “design the parking lot business, including monthly subscriptions, valet, EV charging, and a customer mobile app.” The use case diagram forces an explicit decision about which use cases are in scope and which are not — and the interviewer can intervene before fifteen minutes of class diagram are wasted on a feature nobody asked for.

The second is missing an actor. The candidate models Driver and never considers Admin. Twenty minutes in, the interviewer asks “how does ops change the rate table?” and the candidate has nowhere for that capability to live. Drawing actors at the top of the round is a forcing function: every face you draw is a check that the system has somewhere for that face’s needs.

The third is conflating actors and components. A candidate writes “Database” as an actor. The database is inside the system — it is not an external party interacting with it. Distinguishing “this is a participant” from “this is part of the implementation” is part of the discipline use case diagrams teach.

The diagram also pays a second dividend later in the round: when the interviewer pushes a follow-up (“what if there’s a kiosk for entry instead of a gate?”), you can point at the use case diagram and ask whether the kiosk is a new actor or just a new way for the Driver actor to invoke park vehicle. The diagram localises the question.

How it works#

The notation is small enough to memorise once. A canonical mini-diagram for the parking lot:

   +-----------------------------------------------------------+
   |                       Parking Lot                         |
   |                                                           |
   |     ( park vehicle )                                      |
   |          ^                                                |
   |          |                                                |
   |          |       ( pay fare ) <<include>> ( issue receipt )
   |          |            ^                                   |
   |          |            |                                   |
   |     ( retrieve vehicle )                                  |
   |          ^                                                |
   |          |                                                |
   |          |       <<extend>>  ( apply loyalty discount )   |
   |                                                           |
   |     ( configure rates ) <-----+                           |
   |     ( audit revenue )   <-----+                           |
   +-----------------|---------------------|-------------------+
                     |                     |
                     |                     |
                  +--+--+               +--+--+
                  | O   |               | O   |
                  |/|\  |               |/|\  |
                  | / \ |               | / \ |
                  +-----+               +-----+
                  Driver                 Admin

Reading the diagram:

Two actors are named outside the boundary: Driver (primary) and Admin (secondary, mostly out of scope but acknowledged).
Three primary use cases are connected to Driver: park vehicle, retrieve vehicle, pay fare. The line is plain association — Driver participates in those use cases.
pay fare always includes issue receipt (`<<include>>`) — receipt issuance is part of every payment.
pay fare is conditionally extended by apply loyalty discount (`<<extend>>`) — the discount applies only at a defined extension point inside pay fare.
Admin’s use cases are inside the boundary but called out as out-of-scope in the verbal narration; they are drawn so the interviewer sees you noticed them.

Distinguishing include from extend#

The two relationships look similar and trip up candidates regularly. The rule:

`<<include>>` — always. The base use case unconditionally calls the included one. Arrow points from the base to the included. Read as “park vehicle includes log entry.”

`<<extend>>` — sometimes. The extending use case may fire when a condition is met. Arrow points from the extension to the base, with an extension point named on the base. Read as “apply loyalty discount may extend pay fare.”

The asymmetry of the arrow direction is the most-confused detail in UML — committing it to muscle memory saves seconds in the room.

Goal-level versus task-level use cases#

A common pathology is writing too many, too small use cases: click park button, validate plate, assign spot, print ticket. None of these are goals — they are steps inside the goal park vehicle. The test for a use case is the boss test: would your manager, on hearing “I helped a Driver <use case>,” consider the day’s work complete? “Helped a Driver park vehicle” passes; “Helped a Driver click button” does not.

The right level is usually the level the interviewer used to describe the problem. If they said “drivers park their vehicles and pay on exit,” your use cases are park vehicle and pay fare. Do not subdivide further on the diagram — those subdivisions belong on the sequence diagram.

Variants and trade-offs#

A use case diagram has fewer choices than the other UML diagrams, but a few worth naming.

How many actors to draw. Aim for 2–4 in a 45-minute LLD round. Fewer than two suggests you missed someone (the admin, the operator, an external system). More than four is usually a smell that some “actors” are actually components inside the system. If the count balloons, ask whether two roles can collapse into one actor.

How many use cases to draw. Aim for 3–6 primary use cases. Fewer suggests under-scoping; more suggests task-level rather than goal-level granularity. Out-of-scope use cases can be drawn faintly or named verbally — both are fine; do not pretend they do not exist.

Whether to include `<<include>>` / `<<extend>>` at all. Optional. A clean, plain-association diagram of actors-to-use-cases is fully sufficient in most interviews. Reach for include/extend only when there is a real shared sub-flow (an audit log every action writes to) or a real conditional extension (loyalty, surge pricing). Drawing them speculatively is decoration.

Generalization between actors. UML allows actor inheritance — a Premium Driver may inherit from Driver. Almost always overkill for a 45-minute round. If two actors share most use cases and differ in one, just draw the shared associations twice and name the difference.

When this is asked in interviews#

The use case diagram is rarely the centre of attention in the round; it is the artefact that earns or loses goodwill in the first ten minutes. Three specific things interviewers reward:

Naming the actors out loud before you draw them. “There’s a Driver who parks and retrieves. There’s an Admin who configures rates — I’ll treat the admin flows as out of scope unless you want them in. Are there any other actors I should consider?” That last question routinely surfaces an actor you would have missed: an Operator who handles lost tickets, a Payment Processor as an external system, a Floor Display as a passive consumer of state. Asking gives the interviewer permission to volunteer; not asking forfeits the chance.

Explicitly calling out the out-of-scope use cases. “Reservations, monthly passes, EV charging, valet — all out of scope unless you’d like to bring any of them in.” This is the single most points-bearing sentence in the first ten minutes. It signals that you saw the territory and chose to bound it, rather than failing to notice.

Treating external systems as actors. A payment gateway, an external KYC service, or an SMS provider is an actor — not a component you will design. Drawing it as an actor (often with the stereotype `<<system>>` on the stick figure or, more commonly, a labelled rectangle) tells the interviewer you have a sane mental model of where your system ends.

The common follow-up: “Are these actors authenticated?” Authentication is rarely a primary use case in LLD — note it as an <<include>> on each Driver use case if the interviewer pushes, and move on.

OOAD and UML — Overview — where use case diagrams fit in the four-diagram canon.
Class Diagrams — the next artefact, drawn after the use case diagram has fixed scope.
Sequence Diagrams — where each primary use case becomes a flow of object messages.
Activity Diagrams — useful when a single use case has non-trivial branching.
Approaching the OOD Interview — the meta-script that opens with this diagram.
Parking Lot — the canonical worked example, with a real use case diagram at the top of the writeup.