UML: Use Case Diagrams & Scenarios

Generalization of Actors & Use Cases

18 min Lesson 5 of 10

Generalization of Actors & Use Cases

In real systems, actors are rarely monolithic. A Registered Member of a library can do everything a Guest can do — plus more. A Senior Doctor can perform all tasks a Doctor can, and also authorize referrals. This specialization relationship is captured in UML with the generalization arrow — a solid line with a hollow triangular arrowhead pointing from the specialized (child) element toward the general (parent) element.

Generalization applies to both actors and use cases, and it is one of the most expressive tools in a use-case model. Used correctly, it eliminates duplication, clarifies role hierarchies, and exposes exactly what behavior is added or overridden at the specialized level.

Actor Generalization

When one actor inherits all the use cases of another actor and participates in additional use cases of its own, we draw a generalization from the child actor to the parent actor. The child is the more specific role; the parent is the more abstract one.

In a clinic booking system, consider three roles:

User — any person who interacts with the public portal: can Browse Available Slots and View Doctor Profiles.
Patient — a registered user: inherits Browse and View, and also Book Appointment, Cancel Appointment, and View Medical History.
Premium Patient — a paying subscriber: inherits everything a Patient can do, plus Request Priority Appointment and Download Reports.

This three-level hierarchy is drawn as two generalization arrows: Patient → User and Premium Patient → Patient. The resulting diagram is far cleaner than duplicating all inherited associations on every actor.

Actor generalization hierarchy: Premium Patient inherits from Patient, which inherits from User — each level adds new use cases.

Reading the arrow: The generalization arrow points from child to parent (from the specialized actor toward the general one). This follows the same convention as class generalization in class diagrams: the triangle arrowhead always points to the more general element.

Use Case Generalization

Use cases themselves can also be generalized. A parent use case defines the overall goal and the general flow; a child use case inherits that behavior and overrides or extends specific steps without redefining the entire flow. This is different from «include» and «extend», which are about reuse and conditional addition — generalization is about specialization of behavior.

In an online store, the use case Process Payment defines the abstract goal of collecting money from a customer. Two concrete child use cases specialize it:

Pay by Credit Card — inherits the generic payment flow, overrides the step where payment details are collected to require a card number, expiry, and CVV.
Pay by Digital Wallet — inherits the same parent, overrides the detail-collection step to redirect to a wallet provider (PayPal, Apple Pay, etc.).

Child use cases can be instantiated directly by actors, while the parent use case may be abstract (meaning no actor directly triggers it — it only exists to factor out shared behavior).

Use case generalization: Pay by Credit Card and Pay by Digital Wallet specialize the abstract Process Payment use case.

Key Differences: Generalization vs «include» vs «extend»

New analysts frequently confuse generalization with the other two use-case relationships. The table below clarifies the distinction:

Relationship      | Meaning                                  | When to use
------------------|------------------------------------------|---------------------------------
Generalization    | Child inherits & may override parent  | Role hierarchy; behavioral specialization
«include»        | Base UC always calls the included UC     | Mandatory shared sub-behavior
«extend»         | Extension UC optionally inserts behavior | Optional, conditional additions

Guideline: Reach for generalization when you can complete the sentence: "A [Child Actor/UC] IS A [Parent Actor/UC], but with additional or different behavior." If you would say "A always triggers B" use «include»; if you would say "B sometimes adds behavior to A" use «extend».

Actor Generalization in a Library System

Consider a library management system with the following actor hierarchy:

Library Member — can Search Catalog, Borrow Item, Return Item, and Pay Fine.
Staff Member — inherits everything a Library Member can do, plus Process Loan, Register New Member, and Generate Reports.
Head Librarian — inherits from Staff Member, plus Configure System Settings and Approve Budget.

Here the generalization chain is Staff Member → Library Member and Head Librarian → Staff Member. Drawing these two arrows instead of replicating every inherited association makes the diagram both compact and semantically precise.

Avoid deep hierarchies in diagrams. Three levels (like the library example) is the practical maximum for a use-case diagram. If a role hierarchy runs four or more levels deep, reconsider whether the deeper levels truly need to appear on the use-case diagram — a separate role/permission matrix may communicate that information more clearly.

Abstract vs Concrete in Use Case Generalization

A parent use case is called abstract when no actor initiates it directly — its only purpose is to define shared structure that child use cases inherit and specialize. Abstract use cases are conventionally shown with a dashed ellipse border or with the name written in italics.

A concrete child use case can be directly initiated by an actor. It inherits all steps of the parent and must fulfill the same postconditions, but it may override specific steps and add its own preconditions.

In textual scenarios: When you write the use case scenario document for a child use case, start with "Extends: [Parent UC Name]" in the header, then list only the overridden or additional steps. This keeps the written documentation as clean as the diagram.

Summary

Generalization = IS-A relationship; the child inherits all associations and behavior of the parent.
Arrow direction: from child (specialized) to parent (general), with a hollow triangle arrowhead at the parent end.
Applies to both actors (role inheritance) and use cases (behavioral specialization).
An abstract parent use case has no direct actor associations — only its concrete children are directly triggered.
Prefer generalization over duplicating associations whenever a true IS-A relationship exists between actors or use cases.