PlantUML Use Case Diagrams: Actors, Use Cases, and Boundaries

A use case diagram is the most approachable UML diagram, which is exactly why it is useful for talking to non-technical stakeholders. It captures the actors who interact with a system and the use cases - the things they can do - without any implementation detail. Product managers, analysts, and clients can read one at a glance, so it is a favourite for scoping requirements early, before anyone commits to how the features will be built.

PlantUML expresses use case diagrams in a handful of lines, which means you can sketch scope in a meeting and version it alongside your requirements. This tutorial covers declaring actors and use cases, connecting them, and using the include and extend relationships and a system boundary to add structure. Because PlantUML is a text format, you can reference any diagram here and rebuild it as an editable version in Atlas Diagram Studio at /diagrams, or begin from the UML diagram tool at /diagram-tools/uml-diagram. The complete overview lives at /guides/plantuml-complete-guide.

Actors and use cases

Between @startuml and @enduml, declare an actor with actor Customer, which draws the familiar stick figure, and a use case either with the usecase keyword or by wrapping text in parentheses, so (Place Order) creates an oval labelled Place Order. For names with spaces you can quote and alias, writing actor "Registered User" as User or usecase "Reset Password" as UC1, then referring to the short alias in the connections. Aliases keep the relationship lines readable when your labels are long.

Connect an actor to a use case with a plain association line: Customer -- (Place Order) means the customer can place an order. This actor-to-use-case association is the heart of the diagram, and most of a simple use case diagram is just a set of these lines. You can point the association with an arrow if you want to emphasise who initiates, but a plain undirected line is the conventional and cleanest choice for showing that an actor participates in a use case.

Include, extend, and generalisation

Use case diagrams support three special relationships that add real modelling power beyond simple associations. An include relationship, drawn as a dashed arrow with an include label, means one use case always incorporates another: (Place Order) ..> (Validate Payment) : include shows that placing an order always runs payment validation. Use include to factor out a step shared by several use cases, so you describe it once and point to it from each.

An extend relationship, (Place Order) <.. (Apply Discount) : extend, means the extending use case adds optional behaviour under some condition - a discount that only sometimes applies. Generalisation, using the same hollow-triangle notation as class diagrams, lets one actor or use case specialise another: a Premium Customer actor can inherit from a Customer actor with Premium --|> Customer. Together, include for the mandatory shared steps, extend for the optional variations, and generalisation for specialisation let a use case diagram express nuance without losing its at-a-glance readability.

System boundaries and layout

A rectangle keyword or a titled boundary groups the use cases that belong to your system, visually separating what the system does from the external actors who use it. The conventions below keep a use case diagram tidy and honest about scope.

• Wrap the internal use cases in rectangle "Order System" with a brace-delimited body to draw the system boundary.
• Keep actors outside the boundary and use cases inside it, which is the standard reading of the diagram.
• Use aliases for long names so the connection lines stay short and legible.
• Prefer plain associations for actor-to-use-case links and reserve dashed arrows for include and extend.
• Label every include and extend arrow explicitly so readers do not have to infer the relationship type.
• Keep the diagram to the use cases that define scope; resist adding implementation steps that belong in an activity diagram.

Using use case diagrams well

The value of a use case diagram is scoping and communication, not detail. Its job is to answer "who can do what" so that everyone agrees on the boundary of the system before design begins. Resist the temptation to cram in the how - the branching logic and step order belong in an activity diagram, covered in /guides/plantuml-activity-diagram-tutorial, or a flowchart. A use case diagram that stays at the level of actors and capabilities remains readable by the non-technical stakeholders who benefit from it most.

Because the diagram is small and stable, it is an ideal candidate to keep as living documentation of scope. Version the PlantUML text with your requirements, and when you want a client-ready version - styled, annotated, and collaboratively editable - rebuild it in Atlas Diagram Studio at /diagrams. You can also generate a first draft from a plain-English description of the system's users and features with the AI diagram generator at /diagram-tools/ai-diagram-generator, then refine it. For the deeper modelling that follows scoping, the class and sequence tutorials at /guides/plantuml-class-diagram-tutorial and /guides/plantuml-sequence-diagram-tutorial pick up where the use case diagram leaves off.