Free diagram maker
Use case diagram tool
A use case diagram shows who uses a system and what they use it for. Stick figures are actors, ovals are use cases, and the box around them marks what is inside the system and what is not.
Free, no account, and nothing you draw is uploaded.
Published . By the DiagramDesk team.
It is deliberately shallow. The value is in the boundary and the list of actors, which is often where a scoping disagreement turns out to have been hiding.
A worked example: a library system
Draw the system as a rectangle labelled Library system. Outside it, two actors: Member and Librarian. Inside it, ovals for what each wants to get done: Search the catalogue, Borrow a book and Return a book for the member; Add a book and Manage members for the librarian.
Borrow a book includes Check membership, which is shown as a dashed arrow labelled include because it always happens. Pay a late fee extends Return a book, with a dashed arrow labelled extend, because it only happens sometimes. That distinction, always against sometimes, is the one people most often get backwards.
Drawing the use cases
- Draw the system boundary first and name it. Everything inside is what you are building.
- Put the actors outside, on the left for people who initiate, on the right for systems that respond.
- Add one oval per use case, named as a goal: Book a seat, not Click book button.
- Connect each actor to the use cases they take part in with plain lines, no arrowheads.
- Use a dashed arrow labelled «include» for behaviour a use case always pulls in.
- Stop there. Detail belongs in the written use case, not on this diagram.
What a use case diagram shows
- Scoping a system at the start, before requirements are written
- Showing non-technical stakeholders what a system will and will not do
- Finding actors nobody had counted, such as a payment provider or a scheduled job
- Coursework on requirements and UML
Rules that keep it correct
- Actors are roles, not people
- One person may be both a Customer and an Administrator. Those are two actors.
- Use cases are goals
- If it does not deliver something of value on its own, it is a step, not a use case.
- Actor lines have no arrowheads
- The plain line means participation. An arrow would imply direction, which is not what this diagram says.
- «include» and «extend» are easy to overuse
- Use «include» for behaviour that always happens and «extend» for behaviour that sometimes does. Most diagrams need neither.
Ready to draw yours?
The example above opens in the editor, so you can edit rather than start cold.
Use case diagram questions
Should systems be actors?
Yes, if they sit outside your boundary and interact with it. A payment provider or an overnight batch job is an actor.
How many use cases should there be?
Usually fewer than twenty. If you have fifty, you are listing features rather than goals.
Does it replace written requirements?
No. It is the index. Each oval should have a written use case behind it describing the steps.
Can an actor connect to another actor?
Only with a generalisation arrow, to show one role is a kind of another. Otherwise no.