Use Case Diagram Example: Actors, Use Cases, Include and Extend

A use case diagram answers one question on one page: who uses this system, and what do they use it for? Product managers use it to agree on scope, engineers to see every entry point into a system, and testers to check that every goal has a path. It is also one of the most frequently misdrawn UML diagrams: people turn it into a flowchart, draw every button as a use case, or use include and extend backwards.

This post explains the notation as the UML 2.5.1 specification defines it, settles include versus extend with a simple test, walks through a worked example for a food ordering app, shows the text that should sit behind each oval, and lists the mistakes that make use case diagrams useless.

The notation

The arrow directions come straight from the UML 2.5.1 specification, published by the OMG in December 2017: include points from the base use case to the included one; extend points from the extending use case to the one it extends. The spec also allows extension points, named places in the base use case where an extension may plug in, listed inside the oval.

Include versus extend: one test

Ask whether the base use case is complete without the other one.

• Not complete without it: include. Placing an order always takes payment. "Place order" includes "Pay for order". The arrow points at what is included, and the base cannot run without it.
• Complete without it: extend. Applying a promo code is optional; an order is perfectly valid without one. "Apply promo code" extends "Place order", at an extension point such as "before payment", when the customer has a code. The arrow points at the base, which does not even know the extension exists.

Two more rules prevent most misuse:

• Use include to share behavior that several use cases need, such as authentication or payment. Do not use it to break one use case into steps; that is a flowchart.
• Use extend sparingly. If you have more extends than base use cases, you are documenting UI options, not goals.

Actors are roles

An actor is a role, not a person or a job title. One person can be a customer in the morning and a restaurant manager in the afternoon. Actors can also be systems: a payment provider that the app calls to authorize a card is a supporting actor. Some teams model scheduled jobs with a "Time" actor, a common convention for use cases that nobody starts by hand.

By convention, primary actors, who start use cases to reach their goals, stand on the left, and supporting actors, which the system calls on, stand on the right.

Naming use cases at the right level

Name use cases as verb plus object, from the actor's point of view: "Place order", not "Order", "Order screen" or "Submit button". Each one should be a goal the actor can complete in one sitting and would be glad to have achieved, what Alistair Cockburn calls the sea level of user goals. Higher levels ("Run the restaurant") are too broad for one oval; lower levels ("Enter card number") are steps inside a use case.

A worked example: food ordering

The diagram below shows a food ordering app with four actors:

• Customer browses the menu, places orders and tracks deliveries.
• Restaurant staff accept orders.
• Courier delivers orders.
• Payment provider, an external system, supports payment.

And seven use cases inside the boundary:

1. Browse menu
2. Place order, which includes Pay for order
3. Pay for order, which the payment provider supports
4. Apply promo code, which extends Place order before payment
5. Track delivery
6. Accept order
7. Deliver order

Notice what is not in the diagram: no order of steps, no screens, no "Log in" oval for every actor. Authentication is a precondition, not a goal; it belongs in the descriptions or as a single included use case if it carries real behavior.

The description behind each oval

The diagram is an index. The value lives in a short description per use case, for example:

Use case: Place order
Primary actor: Customer
Precondition: The customer is signed in and the basket is not empty.

Main success scenario:
  1. Customer reviews the basket and delivery address.
  2. System shows the total, including fees and estimated delivery time.
  3. Customer confirms the order.
  4. System takes payment (includes: Pay for order).
  5. System sends the order to the restaurant and confirms it to the customer.

Extensions:
  2a. Customer has a promo code: Apply promo code, then continue at step 2.
  4a. Payment is declined: System asks for another payment method.
  5a. Restaurant does not accept within 5 minutes: System cancels and refunds.

Postcondition: The order is paid and visible to the restaurant.

Extensions in the description, the numbered "what if" branches, are where requirements and test cases come from. They are far more detailed than the extend relationships on the diagram, which should show only the optional goals worth a picture.

Common mistakes

• A flowchart in disguise. Arrows between use cases that mean "then" turn the diagram into a process model. Use a BPMN diagram or an activity diagram for order of work.
• One use case per CRUD operation. "Create menu item", "Update menu item" and "Delete menu item" are usually one goal: "Manage menu".
• Screens and buttons as use cases. "Click checkout" is a step, not a goal.
• Include for decomposition. If every use case includes three others, the diagram describes the code structure, not user goals.
• Internal components as actors. The database is not an actor; it is inside the system. External systems you call are.
• No boundary. Without the subject rectangle, readers cannot tell what you are building and what you depend on.

Use case diagrams, user stories and sequence diagrams

They work together: the use case diagram maps the territory, stories slice it into deliverable pieces, and a sequence diagram shows how one scenario actually runs.

The use case diagram

How to read it:

• The rectangle is the system boundary: everything inside is the food ordering app.
• Actors on the left start use cases: the customer has three goals, restaurant staff and couriers one each.
• The payment provider on the right is a supporting system the app calls during payment.
• The «include» arrow from Place order to Pay for order means payment always happens. The «extend» arrow from Apply promo code to Place order means the promo code is optional.
• The Markdown block is a notation key for readers new to UML.

Drawing use case diagrams people actually read

• Keep it under about 15 use cases per diagram. If a system has more, split by actor or by subsystem.
• Put primary actors left and supporting actors right, so the reading direction matches who starts what.
• Label include and extend explicitly, with the guillemets, and keep the arrows dashed.
• Leave the details to the descriptions. The diagram should fit on a slide; the text can be as long as it needs.

Use case diagrams pair well with the other UML views: the UML class diagram example for the domain model and the state diagram example for the lifecycle of an order.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. Add a Core Frame named Food ordering app as the system boundary.
3. Add seven Use Case nodes from the UML pack inside the frame, named as above.
4. Add four Actor nodes from the UML pack: Customer, Restaurant staff and Courier on the left, Payment provider on the right.
5. Connect actors to their use cases with plain lines. Add dashed edges labeled «include» from Place order to Pay for order and «extend» from Apply promo code to Place order.
6. Add a Markdown block from the Core pack with a short notation key.

The example uses 13 diagram nodes, within the Free plan.

FAQ

What is the difference between include and extend in a use case diagram? Include means the base use case always performs the included behavior, and the arrow points to the included use case. Extend means optional behavior added under a condition, and the arrow points from the extension to the base use case.

Can an actor be a system? Yes. Any external role that interacts with the system can be an actor, including other software such as a payment provider. Components inside your system are not actors.

Should arrows connect actors to use cases? UML uses plain association lines between actors and use cases. Some teams add arrowheads to show who initiates, but the standard notation does not require them.

How many use cases should a diagram have? As a guideline, no more than about 15. Larger systems read better as several diagrams, split by actor or subsystem.

Do use case diagrams show the order of steps? No. They show goals, not sequences. The order of steps belongs in use case descriptions, activity diagrams or sequence diagrams.

Start free — one seat, no credit card.