Uml Use Case Diagram Relationships Cheat Sheet: Includes, Extends & Generalization Explained

If you've ever stared at a use case diagram and wondered why there are different arrow styles pointing between use cases and actors, you're not alone. Use case diagram relationships are one of the most misunderstood parts of UML. A quick cheat sheet that breaks down each relationship type association, include, extend, generalization, dependency, and realization saves you hours of confusion and helps you draw diagrams that actually communicate what your system does.

What Exactly Are Use Case Diagram Relationships?

In UML, a use case diagram shows how users (called actors) interact with a system. Relationships are the lines and arrows connecting actors to use cases, or use cases to other use cases. Each type of line means something different. Getting these wrong doesn't just make your diagram messy it can misrepresent how your system works.

There are six commonly recognized relationship types in use case diagrams:

Association connects an actor to a use case
Include one use case always requires another
Extend one use case optionally adds behavior to another
Generalization a child inherits from a parent actor or use case
Dependency a general "uses" relationship (less common in practice)
Realization a use case realizes a specific behavior or interface

Each one has a distinct notation, purpose, and set of rules. Let's walk through them all.

How Do Association Relationships Work?

An association is the simplest relationship. It's a solid line connecting an actor to a use case. It means the actor participates in or initiates that use case.

Notation: Solid line, no arrows (or with arrows showing direction of communication)
When to use it: Every time an actor interacts with a use case

For example, a "Customer" actor connected to a "Place Order" use case means the customer can place an order. That's it. No special behavior, no conditions.

What Does the Include Relationship Mean?

The include relationship says that one use case always incorporates the behavior of another use case. The base use case cannot complete without the included use case running.

Notation: Dashed arrow with an open arrowhead, pointing from the base use case to the included use case, labeled <<include>>
When to use it: When multiple use cases share a common mandatory step

Example: "Place Order" always includes "Authenticate User." You can't place an order without logging in first. The arrow goes from "Place Order" → "Authenticate User."

What Does the Extend Relationship Mean?

The extend relationship is the opposite direction of include. It says one use case optionally adds behavior to another, under certain conditions.

Notation: Dashed arrow with an open arrowhead, pointing from the extending use case to the base use case, labeled <<extend>>
When to use it: When behavior is optional or conditional

Example: "Apply Discount" extends "Place Order." A discount is only applied if the customer has a promo code. The arrow goes from "Apply Discount" → "Place Order."

Include vs. Extend How Do You Tell the Difference?

This is where most people get tripped up. Here's a simple way to remember it:

Include: "I can't do A without doing B." The included use case is mandatory.
Extend: "A works on its own, but B might add to it." The extension is optional.

Another clue is the arrow direction. Include arrows point from the base to the shared use case. Extend arrows point from the optional use case back to the base. This is one of the most common mistakes in UML modeling, so double-check your arrows every time.

How Does Generalization Work in Use Case Diagrams?

Generalization (also called inheritance) applies to both actors and use cases. It means a child element inherits the behavior and attributes of a parent.

Notation: Solid line with a hollow triangle arrowhead, pointing from the child to the parent
For actors: "Admin" generalizes from "User." Admin inherits all interactions that a User has, plus extra ones.
For use cases: "Pay by Credit Card" and "Pay by PayPal" both generalize from "Make Payment."

If you're also working with class diagrams, you'll notice generalization uses the same notation. Our UML class diagram syntax guide covers inheritance in more detail.

When Should You Use Dependency and Realization?

These two show up less frequently in basic use case diagrams, but they matter in more detailed models.

Dependency is a general relationship where one element depends on another. In use case diagrams, it's rare because include and extend are more specific forms of dependency. You might see it when modeling relationships with external systems or libraries.

Realization connects an implementation-level element to a use case that specifies what behavior should exist. Think of it as: this use case defines what needs to happen, and the connected element is how it happens.

Dependency notation: Dashed arrow, no stereotype label
Realization notation: Dashed line with a hollow triangle arrowhead

Quick Cheat Sheet: All 6 Relationships at a Glance

Relationship	Line Style	Arrowhead	Label	Meaning
Association	Solid	None or plain	None	Actor interacts with use case
Include	Dashed	Open (→)	<<include>>	Mandatory shared behavior
Extend	Dashed	Open (→)	<<extend>>	Optional/conditional behavior
Generalization	Solid	Hollow triangle (▷)	None	Inheritance (parent-child)
Dependency	Dashed	Open (→)	None or custom	One element depends on another
Realization	Dashed	Hollow triangle (▷)	None	Specification-implementation link

What Are the Most Common Mistakes with Use Case Relationships?

After reviewing hundreds of student and professional diagrams, these errors come up again and again:

Swapping include and extend arrows. The most frequent mistake. Remember: include goes from base → shared. Extend goes from optional → base.
Using include when behavior is optional. If the step doesn't always happen, use extend instead.
Overusing generalization. Not every "sub-type" needs its own use case. If the steps are nearly identical, one use case with a note might be clearer.
Drawing association lines between use cases. Association connects actors to use cases, not use cases to each other. Use include or extend for use case relationships.
Missing the stereotype labels. Without <<include>> or <<extend>> labels, a dashed arrow is ambiguous.

Practical Tips for Drawing Better Use Case Diagrams

Start with actors and goals. List who uses the system and what they want to do. Relationships come second.
Use include for shared authentication or validation steps. If three use cases all require login, extract it as an included use case.
Use extend for optional features. Gift wrapping, promo codes, express shipping these are classic extend scenarios.
Keep it readable. If your diagram has more than 15–20 use cases, split it into sub-systems.
Use a tool that supports UML stereotypes. Tools like PlantUML make it easy to render correct arrow styles. If you're working in text-based diagramming, check out our PlantUML code examples for syntax patterns that also apply to use case diagrams.
Label every dashed arrow. Ambiguity is the enemy of a good diagram.

Where Can You Learn More About UML Diagram Syntax?

Use case diagrams are just one part of the UML ecosystem. If you need a broader refresher on UML diagram types and their notation, the official UML specification from the Object Management Group (OMG) is the authoritative source. For practical, code-level syntax, our full use case diagram relationships cheat sheet and related UML guides cover the hands-on details you need.

Your Next Step: A Practical Checklist

☐ Identify all actors and list their goals
☐ Map each goal to a primary use case
☐ Find shared mandatory steps → use include
☐ Find optional or conditional steps → use extend
☐ Check for actor or use case hierarchies → use generalization
☐ Label every dashed arrow with the correct stereotype
☐ Review arrow directions include and extend point in opposite directions
☐ Keep diagrams under 20 use cases per view; split if needed

Print this checklist out or bookmark this page. The next time you model a system, walk through each step before you start drawing lines. It'll save you rework and make your diagrams easier for others to read.