Having gotten a feel for what UML is and the different types of diagrams it includes, let’s move on to the practical side. And from a business analyst’s perspective, the first thing that usually comes to mind is the Use Case Diagram.
Legend for this article:
Legend for this article:
- Blue — things not dictated by UML, but borrowed as helpful practices from other theories or hands-on experience (for example, from classic use case theory).
- Italic — examples.
When used as intended, a Use Case Diagram describes what can be done with the system, framed in terms of actors and the use cases (i.e., interactions) they perform.
When to Use It:
Nothing out of this world — its applicability stems straight from its description: use it when you, as an analyst, need to visually communicate scope in terms of use cases (valuable actions a user can take with the system):
Even if use case modeling itself doesn’t feel like your thing, looking at the system from the user’s perspective is always valuable. User stories alone don’t quite cut it — not every story answers the question “What meaningful thing can I do with the system?” Often they’re smaller in scale, sometimes describing edge cases or one-off paths within a broader use case.
Nothing out of this world — its applicability stems straight from its description: use it when you, as an analyst, need to visually communicate scope in terms of use cases (valuable actions a user can take with the system):
- To align on scope with the client or end users
- To convey scope to the development team
- To organize and make sense of scope for yourself or fellow analysts
Even if use case modeling itself doesn’t feel like your thing, looking at the system from the user’s perspective is always valuable. User stories alone don’t quite cut it — not every story answers the question “What meaningful thing can I do with the system?” Often they’re smaller in scale, sometimes describing edge cases or one-off paths within a broader use case.
Elements:
Actor — these are the participants in your use cases. Represented by stick figures. An actor is a person, organization, role, or even non-human entity (like software or hardware) that interacts with the system and derives value from the use case. In most cases, this means they perform the use case. Technically speaking, UML allows for use cases to be triggered by something other than an actor, but the actor still benefits from the outcome — and that’s what matters.
Actor — these are the participants in your use cases. Represented by stick figures. An actor is a person, organization, role, or even non-human entity (like software or hardware) that interacts with the system and derives value from the use case. In most cases, this means they perform the use case. Technically speaking, UML allows for use cases to be triggered by something other than an actor, but the actor still benefits from the outcome — and that’s what matters.
- Actors should be external to the system you're modeling. Here’s a structure to remember: there’s a target system — the thing we’re describing. There are use cases — things that can be done with that system. And there are actors who do those things. Logically, they must exist outside the system. That said — if you really want to, you can show internal use cases performed by the system itself (technically, this breaks UML orthodoxy). For example, the system wakes up every morning and triggers a data import from a third-party service. Purists will scoff, but you’re doing your job.
- You can divide actors into primary and secondary. Primary actors are the ones we just described — those who initiate and benefit from the use case. Secondary actors are involved in the execution somehow, but don’t initiate it or get primary value from it. This is a helpful distinction. Visually, you can’t tell them apart just by the actor icons, but you can show the difference using directional associations, which we’ll talk about in a moment.
Use Case — a valuable operation a primary actor can perform with the system. Represented as an oval. A proper use case should be:
- Valuable — You come in, do something, and leave with a result. That means something like “Log in” doesn’t count as a full use case. We’ll talk about exceptions later.
- Atomic — One-time, meaningful operations like “Create user”, not vague abstractions like “User Management”.
- Verb-based — Ideally phrased as an action (with an object if needed). E.g., Create user, not just User.
Relationships:
Association — a link between an actor and a use case they perform or participate in. Just a line — can be directional (open arrow) or not.
Usage:
Association — a link between an actor and a use case they perform or participate in. Just a line — can be directional (open arrow) or not.
Usage:
- If a use case has no secondary actors, use a non-directional association.
- If there are secondary actors: direction goes from primary actor to the use case and from the use case to secondary actor. Arrow direction does not represent data flow or command flow — it’s purely a semantic marker of whether the actor is primary or secondary.
At this point, many people stop. They build a “daisy” diagram: actors, use cases, and lines between them — and call it a day. But honestly, what’s the point? How is that more informative than just listing the use cases next to each actor in text form? So, let’s not stop here. Let’s go deeper and explore what other meaningful relationships we can show in a Use Case Diagram.
Include. This relationship shows that one use case fully and necessarily includes another. Represented by a dashed arrow with the <<include>> stereotype. Direction goes from the main use case to the one it includes.
Usage:
In scenarios 2 and 3, include helps avoid repeating steps — especially useful if you're writing a specification alongside the diagram.
Usage:
- To highlight that process A always contains subprocess B.
- If use case B can sometimes be a standalone operation and other times is part of use case A.
- If use case B is reused across multiple other use cases.
In scenarios 2 and 3, include helps avoid repeating steps — especially useful if you're writing a specification alongside the diagram.
Extend. This relationship shows that one use case optionally extends another — meaning it adds optional behavior. Also a dashed arrow with the <<extend>> stereotype. The direction is often counterintuitive — the arrow goes from the extending use case to the base use case.
Usage:
Again, extend helps avoid duplication in specs and diagrams.
Usage:
- To show that under certain conditions or by actor choice, process A might include process B.
- If the extending use case B can sometimes be performed on its own, and other times adds behavior to A.
- If B extends multiple other use cases.
Again, extend helps avoid duplication in specs and diagrams.
Useful to know:
- The association from the primary actor to included and extending use cases may be visually omitted so as not to clutter the diagrams.
- From the applications described above for both types of relationships, it follows that the included and extending use cases may not be independently useful (i.e., they can simply be steps or subprocesses that you decided to highlight).
Let’s cook up a simple IT example.
Suppose we have a video hosting system — a somewhat battered and occasionally inconvenient analogue of YouTube. Here’s what it has:
Here’s how this can be reflected in a diagram:
Suppose we have a video hosting system — a somewhat battered and occasionally inconvenient analogue of YouTube. Here’s what it has:
- Registration and login/logout
- Watching videos (via the feed on the homepage) and uploading videos
- Commenting and moderating comments
- Adding videos to a “Watch Later” playlist
Here’s how this can be reflected in a diagram:
What guided our decisions in some cases:
- You can watch a video only during the process of browsing the feed on the homepage (i.e., from the feed itself).
- While watching a video, you can add it to “Watch Later” or leave a comment.
- “Log into the system” is highlighted as a separate use case (even though it is not an independently valuable use case), deliberately (understanding that this breaks the “classics’” rules) in order to a) avoid duplicating login steps in every use case in the future, b) ensure completeness of the scope (so that important functional parts aren’t hidden from readers).
- “Log out” is made a use case for the same reason (b).
- “Set access rights” is highlighted as an included use case to explicitly inform readers that it will be a mandatory part of video creation.
What’s described above is enough to draw decent diagrams without fuss. For those who want to know/handle more, here are some more advanced practices:
Subject (sometimes called Boundary). This is an element that groups use cases by some criterion (in UML, the applicability of this element is somewhat narrower, but for an analyst, it makes sense to generalize it to “any criterion”). It’s shown as a rectangle.
Usage:
Follows from the description: use it if you want to group use cases by functional module, logical area, or any other way.
Usage:
Follows from the description: use it if you want to group use cases by functional module, logical area, or any other way.
Generalization (sometimes called Inheritance). This is a relationship between actors or between use cases, showing what object-oriented approach calls inheritance. It is represented by a solid line with a hollow triangle at the end (this relationship is also actively used in other UML diagrams), going from the child to the parent.
Generalization indicates that the child element B (actor or use case) is a further specification of the parent element (actor or use case), i.e., the child clarifies and adds details to the parent. In other words, the descendant is the same as the parent, but with additional details/specifics.
Generalization indicates that the child element B (actor or use case) is a further specification of the parent element (actor or use case), i.e., the child clarifies and adds details to the parent. In other words, the descendant is the same as the parent, but with additional details/specifics.
Examples of generalization chains from parent to child:
To check if you’re using this relationship correctly in terms of meaning, formulate it like this: Child B is parent A with an additional specification (clarification) X.
What’s useful about this: the child inherits all properties of the parent (e.g., the common use cases they perform) but can add new, unique ones (e.g., some unique use cases).
Usage:
Let’s extend our IT example by adding a) different user types as described in point 1 above, and b) variations of video creation to demonstrate point 2.
- Vehicle → Car → Passenger Car → Sedan
- Hardware Device → Computing Device → Laptop → Gaming Laptop
To check if you’re using this relationship correctly in terms of meaning, formulate it like this: Child B is parent A with an additional specification (clarification) X.
What’s useful about this: the child inherits all properties of the parent (e.g., the common use cases they perform) but can add new, unique ones (e.g., some unique use cases).
Usage:
- For actors: most often used to show the structure of roles or access rights. See the example below. With well-organized chains, this can reduce the duplication of many associations (common use cases for descendants are associated with a highlighted parent).
- For use cases: used less often, but you can show that a use case is a concrete instance of a more abstract one. For example, use cases “Have Lunch” and “Have Dinner” can be generalized into a more abstract use case “Eat a Meal”. In terms of visualization, this is purely to show readers what they have in common. For further specification, this can be used to avoid duplicating sections of use cases by moving common parts to the parent — if use cases share something, some parameters will likely be common too: preconditions, postconditions, scenario steps or even entire scenarios, triggers, or other parameters.
Let’s extend our IT example by adding a) different user types as described in point 1 above, and b) variations of video creation to demonstrate point 2.
What point (a) gave us: We introduced the Unknown user, which emphasizes that Registration and Login are for unauthenticated anonymous users; Watching videos is available to everyone; but to add a video to a playlist, comment, create/delete one’s own video, or log out — the user must be known to the system. Moderator is a subtype of an authenticated user with slightly elevated rights (but importantly, with the ability to do everything the regular user can — which the previous diagram version did not reflect).
What point (b) gave us: We added two subtypes of video creation — manual upload and import from YouTube (involving YouTube, obviously).
Business and system use cases — highlighting such categories may not be hugely useful but can be helpful for awareness and understanding/reading the diagram. Everything described above can be called system use cases since we talked about an IT system. You can also build diagrams describing business/organizational use cases — how one interacts with the organization. Referring back to the earlier exception to the rules — that an actor need not be external to the modeled subject — you can also show who does what useful operations inside the organization.
Strictly speaking, this is not part of the UML standard but seems likely to become so, as it gains popularity. For modeling this, simply add slashes to actors and use cases.
What point (b) gave us: We added two subtypes of video creation — manual upload and import from YouTube (involving YouTube, obviously).
Business and system use cases — highlighting such categories may not be hugely useful but can be helpful for awareness and understanding/reading the diagram. Everything described above can be called system use cases since we talked about an IT system. You can also build diagrams describing business/organizational use cases — how one interacts with the organization. Referring back to the earlier exception to the rules — that an actor need not be external to the modeled subject — you can also show who does what useful operations inside the organization.
Strictly speaking, this is not part of the UML standard but seems likely to become so, as it gains popularity. For modeling this, simply add slashes to actors and use cases.
Abstract Use Cases. Like in the previous case, this is mostly useful for correctly interpreting diagrams. All use case examples above were non-abstract (or “concrete,” if you prefer). Abstract use cases (and this applies to most UML elements across diagrams) are shown in italics. This means the abstract element is not “real” and exists only for some auxiliary purpose. For use cases, this means an abstract use case cannot be performed by any actor. The natural question arises: why have it at all? Typical usage of abstract use cases is in combination with generalization among use cases.
Another use of abstract use cases and generalization (technically similar to the previous but with slightly different meaning) is grouping use cases into higher-level containers, e.g.:
Another use of abstract use cases and generalization (technically similar to the previous but with slightly different meaning) is grouping use cases into higher-level containers, e.g.:
Note. Not exactly advanced level, but it’s useful to know that any explanations you add are best indicated according to UML rules:
Common Mistakes:
Let’s make them all on a single diagram right away (though you can actually try to spot each one and think it through before the spoilers hit):
Let’s make them all on a single diagram right away (though you can actually try to spot each one and think it through before the spoilers hit):
- “Useless” use cases, meaning those that represent nothing more than steps of a more meaningful operation, mistakenly shown as full use cases.
I recommend interpreting use cases in line with the earlier note: the actor comes into the system → performs a use case → leaves the system happy, having accomplished something useful. If this paradigm doesn’t fit your use case, consider whether it’s really a use case or just a step within another. Sure, every rule has exceptions — but it's only a working exception when you're knowingly breaking the rules for a justifiable reason (not by accident).
- Misusing direction in associations, interpreting it as “who contacts whom” or “where data flows” instead of showing primary/secondary actor relationships.
Here’s how to properly use association directions when you have multiple types of actors: from a primary actor → to the use case; from the use case → to the secondary actor.
- Using extend to show temporal sequence rather than optional behavior that may happen during the base use case.
On the diagram above, Logout cannot extend Login. If you do that, you’re effectively saying: "As an analyst, I suggest that every time a user logs in, the system should logically offer them the option to log out during the login process." That’s clearly not the case. From the moment the login page opens to the post-condition "Actor is authenticated and on the homepage", the system won’t be offering a logout option — that's a completely separate operation. What’s actually being illustrated is that login is a precondition for being able to log out. Preconditions aren’t shown on the diagram — they go into the use case description (but if you must show it, add a new connector with a stereotype, e.g., <<precede>>).
- Incorrect direction of generalization: from parent to child.
Generalization must be drawn from the child to the parent, and should be understood/read as: “generalizes to” or “abstracts to.” (Pro tip: it’s always easier to grasp or describe relationships when you align with their direction of reading.)
- Incorrect understanding of what generalization actually means.
So what’s wrong with this example? The logic seems sound: a user with the CommonUser role can do more than an unauthenticated user, and an Admin can do even more than a CommonUser. But let’s revisit the key question for validating generalization: “Is child B essentially parent A with additional specificity X?” So: is a CommonUser just an unauthenticated user with extra details? Is an Admin just a CommonUser with extras? On closer inspection, not really. A user with any role is already authenticated. And assuming roles are mutually exclusive (i.e. a user can only have one of them), an Admin is not a type of CommonUser.
The correct approach would be to introduce more actors to build a proper generalization chain: a User (as an abstraction for both authenticated and unauthenticated actors); an Authenticated User (as an abstraction for users with roles like CommonUser and Admin.
