UML Use Case Diagrams

---

Dark Mode

Show Highlights

Audio Clips

UML Use Case Diagrams

Learning Objectives

By the end of this chapter, you will be able to:

1. Identify the core elements of a use case diagram: actors, use cases, system boundaries, and associations.
2. Differentiate between include, extend, and generalization relationships between use cases.
3. Translate a written description of system requirements into a use case diagram.
4. Evaluate when use case diagrams are appropriate versus other UML diagram types.

---

1. Introduction: Requirements from the User’s Perspective

Before diving into the internal design of a system (class diagrams, sequence diagrams), we need to answer a fundamental question: What should the system do? Use case diagrams capture the requirements of a system from the user’s perspective. They show the functionality a system must provide and which types of users interact with each piece of functionality.

A use case refers to a particular piece of functionality that the system must provide to a user—similar to a user story. Use cases are at a higher level of abstraction than other UML elements. While class diagrams model the code structure and sequence diagrams model object interactions, use case diagrams model the system’s goals from the outside looking in.

Concept Check (Generation): Before reading further, try to list 4-5 things a user might want to do with an online bookstore. What types of users might there be? Write your answers down, then compare them to the examples below.

---

2. Core Elements

2.1 Actors

An actor represents a role that a user takes when interacting with the system. Actors are drawn as stick figures with their role name below.

Key points about actors:

• An actor is a role, not a specific person. One person can play multiple roles (e.g., a university professor might be both an “Instructor” and a “Student” in a course system).
• A single user may be represented by multiple actors if they interact with different parts of the system in different capacities.
• Actors are always external to the system—they interact with it but are not part of it.

2.2 Use Cases

A use case represents a specific goal or piece of functionality the system provides. Use cases are drawn as ovals (ellipses) containing the use case name.

• Use case names should describe a goal using a verb phrase (e.g., “Place Order”, not “Order” or “OrderSystem”).
• There will be one or more use cases per kind of actor. It is common for any reasonable system to have many use cases.

2.3 System Boundary

The system boundary is a rectangle drawn around the use cases, representing the scope of the system. The system name appears at the top of the rectangle. Actors are placed outside the boundary, and use cases are placed inside.

2.4 Associations

An association is a line drawn from an actor to a use case, indicating that the actor participates in that use case.

Putting the Basics Together

Here is a use case diagram for an automatic train system (an unmanned people-mover like those found in airports):

Reading this diagram: A Passenger can Ride the train, and a Technician can Repair the train. Both are roles (actors) external to the system.

---

3. Use Case Descriptions

A use case diagram shows what functionality exists, but not how it works. To capture the details, each use case should have a written use case description that includes:

• Name: A concise verb phrase (e.g., “Normal Train Ride”).
• Actors: Which actors participate (e.g., Passenger).
• Entry Condition: What must be true before this use case begins (e.g., Passenger is at station).
• Exit Condition: What is true when the use case ends (e.g., Passenger has left the station).
• Event Flow: A numbered list of steps describing the interaction.

Example: Normal Train Ride

Field	Value
Name	Normal Train Ride
Actors	Passenger
Entry Condition	Passenger is at station
Exit Condition	Passenger has left the station

Event Flow:

1. Passenger arrives and presses the request button.
2. Train arrives and stops at the platform.
3. Doors open.
4. Passenger steps into the train.
5. Doors close.
6. Passenger presses the request button for their final stop.
7. Doors open at the final stop.
8. Passenger exits the train.

Concept Check (Self-Explanation): Look at the event flow above. What would a non-functional requirement for this system look like? (Hint: Think about timing, safety, or capacity.) Non-functional requirements are not captured in use case diagrams—they are typically captured as Quality Attribute Scenarios.

---

4. Relationships Between Use Cases

Use cases rarely exist in isolation. UML defines three types of relationships between use cases: inclusion, extension, and generalization. Each is drawn as a dashed or solid arrow between use cases.

Notation Rule: For include and extend arrows, the arrows are dashed and point in the reading direction of the verb. The relationship label is written in double angle brackets (guillemets) and uses the base form of the verb (e.g., <<include>>, not <<includes>>).

4.1 Inclusion (<<include>>)

A use case can include the behavior of another use case. This means the included behavior always occurs as part of the including use case. Think of it as mandatory sub-behavior that has been factored out because multiple use cases share it.

Reading this diagram: Whenever a customer Purchases an Item, they always Login. Whenever they Track Packages, they also always Login. The Login behavior is shared, so it is factored out into its own use case and included by both.

Key insight: The arrow points from the including use case to the included use case (from “Purchase Item” to “Login”).

4.2 Extension (<<extend>>)

A use case extension encapsulates a distinct flow of events that is not part of the normal or basic flow but may optionally extend an existing use case. Think of it as an optional, exceptional, or conditional behavior.

Reading this diagram: When a customer purchases an item, debug info can (optionally) be logged in some cases. The extension is not part of the normal flow.

Key insight: The arrow points from the extending use case to the base use case (from “Log Debug Info” to “Purchase Item”). This is the opposite direction from <<include>>.

4.3 Generalization

Just like class generalization, a specialized use case can replace or enhance the behavior of a generalized use case. Generalization uses a solid line with a hollow triangle arrowhead pointing to the generalized (parent) use case.

Reading this diagram: “Synchronize Wirelessly” and “Synchronize Serially” are both specialized versions of “Synchronize Data.” Either can be used wherever the general “Synchronize Data” use case is expected.

Concept Check (Retrieval Practice): Without looking at the diagrams above, answer: Which direction does the <<include>> arrow point? Which direction does the <<extend>> arrow point? What arrowhead style does generalization use?

Reveal Answer

<<include>> points from the including use case to the included use case. <<extend>> points from the extending use case to the base use case. Generalization uses a solid line with a hollow triangle.

---

5. Include vs. Extend: A Comparison

Students often confuse <<include>> and <<extend>>. Here is a direct comparison:

Feature	<<include>>	<<extend>>
When it happens	Always — the included behavior is mandatory	Sometimes — the extending behavior is optional/conditional
Arrow direction	From including use case to included use case	From extending use case to base use case
Analogy	Like a function call that always executes	Like an optional plugin or hook
Example	“Purchase Item” always includes “Login”	“Purchase Item” may be extended by “Apply Coupon”

---

6. Putting It All Together: Library System

Let’s read a complete use case diagram that combines all the elements we have learned.

System Walkthrough

1. Actors: There is one actor, Customer, who interacts with the library system.
2. Use Cases: The system provides three pieces of functionality: Loan Book, Borrow Book, and Check Identity.
3. Associations: The Customer can Loan a Book or Borrow a Book.
4. Inclusion: Both Loan Book and Borrow Book always include checking the customer’s identity. This shared behavior is factored out rather than duplicated.

Think-Pair-Share: In English, describe what this use case diagram says. What would happen if we added an <<extend>> relationship from a new use case “Charge Late Fee” to “Loan Book”?

---

7. Active Recall Challenge

Grab a blank piece of paper. Without looking at this chapter, try to draw the use case diagram for the following scenario:

1. A Student can Enroll in Course and View Grades.
2. A Professor can Create Course and Submit Grades.
3. Both Enroll in Course and Create Course always include Authenticate (login).
4. View Grades can optionally be extended by Export Transcript.

After drawing, review your diagram against the rules in sections 2-4. Check: Are your arrows pointing in the correct direction? Did you use dashed lines for include/extend?

---

8. Interactive Practice

Test your knowledge with these retrieval practice exercises.

Knowledge Quiz

UML Use Case Diagram Practice

Test your ability to read and interpret UML Use Case Diagrams.

In a use case diagram, what does an actor represent?

Correct Answer:

Explanation

An actor represents a role, not a specific person. One person can play multiple roles (e.g., a professor who is also a student), and multiple people can share the same role.

Look at this diagram. What does the <<include>> relationship mean here?

Correct Answer:

Explanation

The <<include>> relationship means the included behavior always occurs. Whenever a customer purchases an item, they always go through the login process. This is mandatory, not optional.

What is the key difference between <<include>> and <<extend>>?

Correct Answer:

Explanation

<<include>> models mandatory shared behavior (always happens). <<extend>> models optional or conditional behavior (sometimes happens). Both use dashed arrows, but they point in opposite directions.

In this diagram, which direction does the <<extend>> arrow point?

Correct Answer:

Explanation

The <<extend>> arrow points from the extending use case to the base use case — from ‘Apply Coupon’ to ‘Place Order.’ This indicates that ‘Apply Coupon’ is optional behavior that may extend the ‘Place Order’ flow.

What does the rectangle (system boundary) represent in a use case diagram?

Correct Answer:

Explanation

The system boundary rectangle defines the scope of the system. Use cases (the functionality the system provides) are placed inside, while actors (external users/roles) are placed outside. The system name appears at the top.

Which of the following are valid elements in a UML Use Case Diagram? (Select all that apply.)

Correct Answers:

Explanation

Use case diagrams contain actors (stick figures), use cases (ovals), system boundaries (rectangles), and associations (lines). Classes belong in class diagrams, and lifelines belong in sequence diagrams.

How is generalization between use cases shown?

Correct Answer:

Explanation

Use case generalization uses the same notation as class generalization: a solid line with a hollow triangle pointing to the general (parent) use case. A specialized use case can replace or enhance the parent’s behavior.

A university system requires that both ‘Enroll in Course’ and ‘Drop Course’ always verify the student’s identity first. How should ‘Verify Identity’ be related to these use cases?

Correct Answer:

Explanation

Since identity verification always happens (mandatory), this is an <<include>> relationship. Both ‘Enroll in Course’ and ‘Drop Course’ include ‘Verify Identity.’ The include arrows point from the including use cases toward Verify Identity.

Workout Complete!

Your Score: 0/8

Retrieval Flashcards

UML Use Case Diagram Flashcards

Quick review of UML Use Case Diagram notation and relationships.

What does an actor represent in a use case diagram, and how is it drawn?

A role that a user takes when interacting with the system, drawn as a stick figure.

An actor is a role, not a specific person. One person can play multiple roles. Actors are always external to the system boundary.

What is the difference between <<include>> and <<extend>>?

<<include>> = always happens (mandatory). <<extend>> = sometimes happens (optional).

Include factors out shared behavior that must always occur. Extend adds optional behavior that only occurs under certain conditions. Both use dashed arrows, but the arrow directions differ: include points toward the included use case; extend points toward the base use case.

Which direction does the <<include>> arrow point?

From the including (base) use case to the included (shared) use case.

For example, if “Purchase Item” always includes “Login,” the arrow goes from “Purchase Item” to “Login.” Think of it like a function call: the caller points to the callee.

Which direction does the <<extend>> arrow point?

From the extending (optional) use case to the base use case.

For example, if “Log Debug Info” optionally extends “Purchase Item,” the arrow goes from “Log Debug Info” to “Purchase Item.” This is the opposite direction from include.

What does the system boundary (rectangle) represent in a use case diagram?

The scope of the system — use cases go inside, actors go outside.

The rectangle is labeled with the system name at the top. Everything inside the boundary is functionality the system provides. Everything outside (actors) interacts with the system but is not part of it.

How is generalization between use cases drawn?

A solid line with a hollow triangle arrowhead pointing to the general (parent) use case.

This is the same notation as class generalization (inheritance). A specialized use case can replace or enhance the behavior of the general use case.

Workout Complete!

Your Score: 0/6

Come back later to improve your recall!

Pedagogical Tip: If you find these challenging, it’s a good sign! Effortful retrieval is exactly what builds durable mental models. Try coming back to these tomorrow to benefit from spacing and interleaving.