subroute.
Beginner12 min readUML & Diagramminglive prototype

Use Case Diagrams

A use case diagram is a bird's-eye picture of who uses a system and what goals they can reach with it. Stick figures (actors) on the outside, ovals (goals) on the inside, lines joining who does what — it shows the WHAT, never the how.

The idea

What it is

A use case diagram is the simplest picture in UML. It answers two questions in one glance: who uses this system? and what can they do with it? The who are the actors — drawn as stick figures. The what are the use cases — the goals a user can achieve, drawn as ovals. Lines join each actor to the goals they care about. That's the whole diagram.

It is deliberately high-level. A use case diagram shows the WHAT, never the how. It won't tell you which classes exist, what order things happen in, or how the code works inside. It's the menu, not the kitchen.

Think of a restaurant menu. The menu lists what a customer can order — order food, pay the bill, book a table. It also implies who does what: a customer orders and pays, the kitchen cooks, the card machine takes payment. You can read the menu without knowing a single recipe. A use case diagram is that menu for your software: a quick, shared list of what the system offers and who it offers it to.

The one sentence to remember

A use case diagram = actors (stick figures = who, on the outside) + use cases (ovals = their goals, inside the system box) joined by lines (who can do what). It captures the what, so anyone — even a non-coder — can read it and agree on what the system should do.

Mechanics

How it works

The four things you draw

A use case diagram has only a handful of parts, and the prototype shows all of them at once. Here's the whole vocabulary:

  • Actor — a stick figure. It's a role outside the system, not a specific person. An actor can be a human (a Customer, an Admin) or another system (a Payment Gateway). Same person playing two roles = two actors.
  • Use case — an oval. It's one goal the system lets an actor achieve, written as a verb phrase: Place Order, Track Delivery. One oval = one goal, not one button-click.
  • System boundary — the box drawn around all the ovals. Everything inside is what the system does; actors live outside it. The box label is the system's name, e.g. Online Store.
  • Association — a plain line from an actor to a use case. It just means “this actor performs this goal.” No arrowheads needed.
Online Store «include» Browse Catalog Place Order Make Payment Track Delivery Manage Products Customer Admin Payment Gateway «external system»
An actor (stick figure) is a role outside the system; an oval is a goal the system offers; the box is the system boundary labelled Online Store. The dashed orange arrow is «include» — Place Order always reuses Make Payment.

How to read it

Start at a stick figure and follow its lines into the box. Each oval you reach is a goal that actor can pursue. So Customer ── Place Order reads as “a customer can place an order.” That's it — you can read any use case diagram this way.

«include» — a goal that ALWAYS reuses another

Sometimes one use case always contains another. Place Order always needs Make Payment — you can't finish an order without paying. Instead of repeating the payment steps in every checkout, you pull them into their own use case and point at it with an `«include»` arrow (a dashed arrow from the base use case to the included one).

  • Read it as: “Place Order always includes Make Payment.”
  • It's the diagram version of “call this shared sub-routine every time.” Reuse a common step across several use cases.
  • The dashed arrow points from the bigger goal to the step it reuses.

«extend» — an OPTIONAL extra that adds on

Other times a behaviour is optional — it only happens under some condition. Apply Coupon extends Place Order: most orders don't use a coupon, but some do. That's an `«extend»` arrow (a dashed arrow pointing the other way — from the optional extra back to the base use case it adds onto).

  • Read it as: “Apply Coupon may extend Place Order” — it adds behaviour sometimes, when a condition is met.
  • Arrow direction is the giveaway: «include» points to the reused step; «extend» points back to the base case from the optional add-on.
  • Rule of thumb: `«include»` = always, mandatory. `«extend»` = sometimes, optional.

Tell include from extend

Ask: does it happen every single time? If yes, it's `«include»` (always reused). If it's a conditional “only if…” add-on, it's `«extend»`. And watch the arrowhead — include points at the part being reused; extend points back at the goal being added to.

Generalization — one actor is a kind of another

Actors can inherit too. A hollow-triangle arrow between two actors means “is a kind of.” If a Premium Customer is a special Customer, you draw Premium Customer ──▷ Customer, and the premium one automatically gets all the customer's use cases plus its own. Same idea as inheritance in a class diagram, just for roles.

Keep ovals at goal-level, not step-level

The most common beginner mistake is drawing tiny steps as use cases — Enter Email, Click Submit, Validate Password. Those are steps inside a goal, not goals. A good use case is something a user would say they came to do: Log In, Place Order, Track Delivery. If an actor wouldn't brag “I did that today,” it's probably too small to be its own oval.

Interactive prototype

See it. Build it. Break it.

A sandboxed, hands-on simulation — no setup, no install. Play with it as you read.

About this simulation

One clean diagram of an Online Store. A box (the system boundary) holds the goals as ovals — Browse Catalog, Place Order, Make Payment, Track Delivery, Manage Products — while stick figures outside (Customer, Admin, Payment Gateway) connect by plain lines to the goals they perform. A dashed «include» arrow shows Place Order always reuses Make Payment, and a dashed «extend» arrow shows the optional Apply Coupon adds onto Place Order. Click any actor, oval, or arrow — or take the guided Tour — and a single fixed note explains it in plain English. Nothing scrolls away or grows the page.

Hands-on

Try these yourself

Open the prototype above, predict what happens, then verify.

try 01

Read who does what

Open the prototype. Before clicking, trace each stick figure's lines into the box. Confirm out loud: the Customer can browse, order, pay, and track; the Admin manages products; the Payment Gateway is an external system that takes part in Make Payment. Now click Customer and read the note — an actor is a role, not a named person, and it can be another system too.

try 02

Click an oval, then the boundary

Click the Place Order oval and read why it's a goal (a verb phrase a user came to achieve), not a button or a step. Then click the system boundary box itself: everything inside is what the Online Store does; everyone outside it is an actor. That line between inside and outside is the whole point of the diagram.

try 03

Compare «include» and «extend»

Click the dashed «include» arrow from Place Order to Make Payment — note it means always reused. Then click the «extend» arrow from Apply Coupon to Place Order — note it means optional, only sometimes. Watch the arrow directions: include points at the reused step; extend points back at the base goal. Or hit Tour and let the stepper walk you through every element in order.

In practice

When to use it — and what trips people up

When to reach for a use case diagram

Reach for one early, when you're still figuring out what to build. It shines during requirements gathering and scoping: you sit with a client or product owner, list the actors, and sketch the goals each one needs. Because it's so simple, non-technical stakeholders can read it and say “yes, that's the system” or “you forgot returns.” It's the picture you put on the whiteboard to agree on the boundary of a feature before anyone writes code.

Great for agreeing scope — not for internal logic

Use it to agree what the system does and who it serves: requirements, scope, and shared understanding with non-coders. Don't use it to describe how anything works inside — the order of steps belongs in a sequence or activity diagram, and the structure belongs in a class diagram. If you find yourself drawing logic, you've picked the wrong diagram.

What it gives you

  • Dead simple — stick figures and ovals mean even non-technical stakeholders can read it and give feedback.
  • Perfect for scoping: it draws a clear line (the system boundary) around what's in and what's out.
  • Captures the full set of user goals on one page, so nothing important gets forgotten in requirements.
  • Each oval often maps to a real feature or public API method, giving you a natural to-do list to build.

Common mistakes

  • Shows the WHAT, not the how — it can't describe steps, order, data, or any internal logic.
  • Easy to misuse by drawing tiny steps (Enter Email) as use cases, which turns it into noise.
  • «include» vs «extend» and their arrow directions trip up beginners until practised.
  • Low detail by design, so it must be paired with other diagrams (and written use-case text) to actually build from.

Reference

Code & further reading

A minimal reference implementation and pointers worth bookmarking.

// A use case diagram isn't code — but each use case (oval) usually becomes
// one public method on the service the actors talk to. The diagram is the
// menu; this interface is that same menu, written for the compiler.

interface StoreService {
  // Customer's use cases:
  browseCatalog(): Product[];          // ≈ use case "Browse Catalog"
  placeOrder(cart: Cart): Order;       // ≈ use case "Place Order"
  makePayment(order: Order): Receipt;  // ≈ use case "Make Payment"  (included by placeOrder)
  trackDelivery(orderId: string): DeliveryStatus; // ≈ use case "Track Delivery"

  // Admin's use case — an admin-only goal maps to the Admin actor:
  manageProducts(change: ProductChange): void;     // ≈ use case "Manage Products"
}

References & further reading

5 sources

Knowledge check

Did it land?

Quick questions, answers revealed on submit. Sign in to save your best score.

question 01 / 05

In a use case diagram, what does a stick figure (an actor) represent?

question 02 / 05

What does an oval inside the system boundary represent?

question 03 / 05

Place Order always needs Make Payment to complete. Which relationship models this?

question 04 / 05

Apply Coupon only happens on some orders, when the customer has a code. How is this drawn?

question 05 / 05

Which question is a use case diagram NOT meant to answer?

0/5 answered