UML use case notation reference
A use case diagram uses a small, precise vocabulary. Every element carries a specific meaning — using the wrong notation changes how readers interpret the diagram's scope and relationships.
| Element | UML notation | Meaning |
|---|---|---|
| Actor | Stick figure | A person, organisation, or external system that interacts with the system. Actors appear outside the system boundary. |
| Use case | Oval / ellipse | A discrete goal or function the system provides to an actor. Named as a verb-noun phrase from the actor's perspective. |
| System boundary | Labelled rectangle | Defines the scope of the system. Use cases live inside; actors and external systems live outside. |
| Association | Solid line | Connects an actor to a use case they initiate or participate in. No arrowhead unless direction needs to be made explicit. |
| «include» arrow | Dashed arrow, «include» | The base use case always calls the included use case as a mandatory sub-step. Arrow points from base to included. |
| «extend» arrow | Dashed arrow, «extend» | The extending use case optionally adds behaviour to the base use case under a stated condition. Arrow points from extension to base. |
| Generalization | Solid line, hollow arrowhead | Used between actors (one actor is a specialisation of another) or between use cases (child inherits parent behaviour and may override it). |
When to use a use case diagram
Use case diagrams are most effective at specific stages of a project — and least effective when used as a substitute for implementation design.
| Situation | Why a use case diagram helps |
|---|---|
| Requirements gathering | Captures what the system must do before committing to how it does it. Forces every requirement to map to an actor goal. |
| Stakeholder communication | Readable by non-technical stakeholders. Avoids implementation vocabulary (APIs, databases, services) that obscures intent. |
| Scope definition | The system boundary makes scope visible and negotiable. Anything outside the rectangle is explicitly out of scope. |
| System boundary clarification | Shows which actors are primary (initiate use cases) and which are secondary (called by the system), and which functions cross system lines. |
| Gap analysis | Mapping existing requirements to use cases surfaces missing functionality and duplicate requirements early. |
Example: e-commerce system
The following use cases cover the core customer and admin flows for an e-commerce platform. Checkout includes Payment Processing as a mandatory sub-step; Apply Coupon extends Checkout conditionally.
| Actor | Use case | Relationships |
|---|---|---|
| Customer | Browse Products | — |
| Customer | Add to Cart | — |
| Customer | Checkout | «include» Payment Processing; «extend» Apply Coupon |
| Customer | Track Order | — |
| Guest | Browse Products | Generalizes Customer (inherits) |
| Payment Gateway | Payment Processing | Included by Checkout (secondary actor) |
| Admin | Manage Inventory | — |
| Admin | View Order Reports | — |
Example: banking system
A retail banking system with two primary actors — Customer and Teller — and one secondary actor — Core Banking System — that processes transactions.
| Actor | Use case | Relationships |
|---|---|---|
| Customer | Login | «include» Verify Identity |
| Customer | Transfer Funds | «include» Verify Balance; «include» Verify Identity |
| Customer | Pay Bill | «include» Verify Balance |
| Customer | View Statement | — |
| Teller | Transfer Funds | Generalizes Customer (inherits); additional authority |
| Teller | Open Account | — |
| Core Banking System | Verify Balance | Included by Transfer Funds, Pay Bill (secondary actor) |
Type this prompt into flow-chart.io to generate the banking use case diagram:
Banking system use case diagram. Actors: Customer, Teller (generalizes Customer), Core Banking System (secondary). Use cases: Login (includes Verify Identity), Transfer Funds (includes Verify Balance and Verify Identity), Pay Bill (includes Verify Balance), View Statement. Teller can also Open Account. Core Banking System handles Verify Balance. Show system boundary labelled "Retail Banking System". UML use case diagram.
How AI use case diagram generation works
- Actor extraction. The prompt is scanned for people, roles, and external systems. Primary actors (who initiate goals) are placed to the left of the system boundary; secondary actors (called by the system) are placed to the right.
- Use case identification. Each distinct goal or function is extracted and placed as a named oval inside the system boundary. The AI filters out implementation details and keeps use cases at the correct level of abstraction.
- Relationship detection. Mandatory sub-steps are modelled as «include» relationships; conditional behaviours as «extend»; actor hierarchies as generalization. Associations link each actor to the use cases they participate in.
- Layout pass. Actors are distributed around the system boundary. Use cases are arranged to minimise line crossings, with shared included use cases centred.
Every element is a typed scene graph object — not a flat image. You can rename any use case, reposition actors, add relationships, or extend the diagram after generation.
Use case diagram best practices
- Name use cases as verb-noun phrases from the actor's perspective — "Pay Bill", not "Bill Payment Processing Module".
- Keep the system boundary tight. Every use case inside must be delivered by this system, not an external service or future release.
- Limit actors to those who directly initiate or receive value from use cases. Observers and indirect stakeholders are not actors.
- Use «include» for behaviour that always executes as part of another use case. Use «extend» only for genuinely conditional or optional behaviour — not to decompose a use case into steps.
- One use case per meaningful actor goal. Do not model implementation steps (validate input, write to database) as separate use cases.
- Apply generalization between actors when one actor is a specialisation of another and inherits their full set of use cases.
- Validate the diagram against requirements: every functional requirement should map to at least one use case. A requirement with no use case is missing or out of scope.
Frequently asked questions
- What is a use case diagram?
- A use case diagram is a UML behavioural diagram that shows the functional requirements of a system from the perspective of its users. It captures who interacts with the system (actors), what goals they pursue (use cases), and how those goals relate to each other (include, extend, generalization). Use case diagrams do not show implementation detail — they answer "what must the system do" rather than "how does it do it", making them the primary tool for capturing and communicating requirements with stakeholders.
- What is the difference between an actor and a system boundary?
- An actor is a person, organisation, or external system that interacts with the system being modelled. Actors appear outside the system boundary and initiate or receive use cases. The system boundary is a rectangle that encloses all the use cases the system delivers — everything inside the boundary is the system's responsibility; everything outside is external. Keeping the boundary explicit prevents scope creep: if a proposed use case sits outside the boundary, it belongs to a different system or a future phase.
- What is the difference between include and extend in a use case diagram?
- «include» models mandatory, reusable sub-behaviour. When use case A includes use case B, B always executes as part of A — for example, Checkout always includes Payment Processing. «extend» models optional or conditional behaviour. When use case B extends use case A, B executes only when a specific condition is met — for example, Apply Coupon extends Checkout only when the customer enters a coupon code. A practical rule: if the sub-behaviour always happens, use «include»; if it only sometimes happens, use «extend».
- When should I use a use case diagram instead of a user story?
- Use case diagrams and user stories serve different audiences and granularities. A use case diagram gives a system-level overview — it shows all actors, all top-level goals, and the relationships between them on a single page. It is most useful for scope definition, stakeholder review, and identifying missing requirements. User stories are atomic units of work written for a development team. Use the diagram early to establish scope and discover actors; write user stories to break individual use cases into sprint-sized deliverables.
- How do I identify use cases for my system?
- Start with actors. List every person or external system that interacts with the system, then ask "What does this actor want to accomplish?" Each distinct goal is a candidate use case. Filter by granularity: a use case should represent a complete, meaningful interaction from the actor's perspective — not a single button click and not an entire business process. Cross-check against requirements: every functional requirement should map to at least one use case. Describe your actors and goals to flow-chart.io in plain language and it will generate the diagram with actors, ovals, and relationships placed correctly.
- What is the difference between a use case diagram and a sequence diagram?
- A use case diagram answers "what" — it shows actors and the goals they achieve, giving a high-level map of system functionality with no time ordering. A sequence diagram answers "how" — it shows the step-by-step message exchange between participants (lifelines) to fulfil one specific use case, with time running top to bottom. The two diagrams are complementary: start with a use case diagram to establish scope, then create sequence diagrams for the use cases that need detailed interaction design.
- What are the best practices for drawing use case diagrams?
- Seven practices that produce clear, useful use case diagrams: (1) Name use cases as verb-noun phrases from the actor's perspective. (2) Keep the system boundary tight. (3) Limit actors to those who directly initiate or receive value from a use case. (4) Use «include» for behaviour that always executes and «extend» only for genuinely conditional behaviour. (5) One use case per meaningful actor goal — do not model implementation steps as separate use cases. (6) Show generalization when one actor is a specialisation of another. (7) Validate by mapping every functional requirement to at least one use case.