UML Use Case Diagrams: A Complete Guide
A use case diagram maps who uses a system and what they use it to do. This guide covers actors, use cases, boundaries, and the include and extend relationships that trip people up.
Use case diagrams sit at the boundary between requirements and design. Before you decide how a system works internally, you decide what it does and for whom, and a use case diagram captures exactly that at a glance: the actors on the outside, the goals they want to accomplish, and the line that separates the system from the world around it. Because they are simple and non-technical, they are one of the few UML diagrams you can put in front of a business stakeholder and expect a productive conversation.
The simplicity is also a trap, because the two relationship types, include and extend, are among the most misused notation in all of UML. This guide keeps the basics tight and spends real time getting those relationships right. You can sketch use case diagrams at /diagrams, and the broader UML reference at /diagram-tools/uml-diagram covers how they fit with the rest of the language.
The three core elements
A use case diagram has three ingredients. Actors are the roles that interact with the system, drawn as stick figures and placed outside the system boundary. An actor is a role, not a person: the same human might be both a Customer and an Administrator, and those are two actors. Actors can also be external systems, like a payment gateway or a scheduled job.
Use cases are the goals actors accomplish, drawn as ovals inside the boundary and named as verb phrases: "Place Order", "Reset Password", "Generate Report". The system boundary is a rectangle enclosing the use cases, with the system's name at the top, that visually separates what the system does from who is asking. Lines called associations connect actors to the use cases they participate in. That is the entire core vocabulary.
Include versus extend
The two relationships between use cases are where most diagrams go wrong. An include relationship, drawn as a dashed arrow labeled include pointing from a base use case to the included one, means the base use case always performs the included behavior as part of itself. "Place Order" includes "Validate Payment" because you cannot place an order without validating payment. Include is for common behavior factored out of several use cases, like a shared subroutine.
An extend relationship, drawn as a dashed arrow labeled extend pointing from the extending use case to the base, means the extending behavior happens only sometimes, under a condition, and the base use case is complete without it. "Place Order" might be extended by "Apply Discount Code" because most orders proceed without one. The direction confuses people: include points from base to part, but extend points from the optional part back to the base. When in doubt, ask whether the behavior always happens (include) or only conditionally (extend), and remember that the base must make sense on its own for extend to be correct.
A worked example
Picture an online bookstore. The actors are Customer, Administrator, and an external Payment Gateway. The Customer is associated with use cases "Browse Catalog", "Place Order", and "Track Shipment". "Place Order" includes "Validate Payment", which associates with the Payment Gateway actor, and is extended by "Apply Gift Card" under the condition that the customer has one. The Administrator is associated with "Manage Inventory" and "View Sales Report".
Read as a whole, this diagram tells a product manager the entire scope of what the system offers, who each capability serves, and which behaviors are optional, without a line of code or a single screen. That is the point of the diagram: it is a scope agreement, not a design. If you want a first draft from a written description of your system, the AI generator at /diagram-tools/ai-diagram-generator can lay out the actors and use cases for you to refine.
Common pitfalls
The most common mistake is turning a use case diagram into a flowchart. Use cases are goals, not steps. "Enter Username", "Click Login", "Validate" are steps in a single use case ("Log In"), not three separate use cases. If your ovals read like a sequence of actions, you have drawn the wrong diagram; the steps belong in the use case's text description or in an activity diagram.
- Do not model internal system functions as use cases; use cases are user-facing goals, not implementation details.
- Do not overuse include and extend; if a diagram is more arrows than ovals, it has lost the plot.
- Do not confuse actors with the department or team; an actor is a role interacting with the system.
- Do not draw a use case with no actor; every use case should serve someone or something.
- Do not sequence use cases with arrows implying order; the diagram is not a workflow.
- Do keep names as short verb phrases from the actor's point of view.