Skip to content
Software Architecture Guide

UML Generalization and Specialization

Explanation

Section titled “Explanation”

Generalization is a relationship between a general class (the superclass) and a more specific class (the subclass). Specialization is the same relationship seen from the other direction: you start from the general class and add more specific ones. See UML Class Diagram for the diagram type.

Notation. A hollow triangular arrowhead marks the relationship. It points toward the more general class.

Inheritance. A specialized class inherits the characteristics of its general class. It may also add characteristics of its own.

Abstract classes. An abstract class defines common characteristics but has no direct instances of its own.

Substitutability. Every instance of a subclass is also an instance of its superclass. This underlies substitutability. The Liskov formulation says: if S is a subtype of T, objects of type T in a program may be replaced with objects of type S without altering desirable program properties.

Generalization sets. A set groups the specializations of one general class. Two properties describe a set:

  • Complete: the set covers all permitted specializations. The UML 2.5 notation says “complete” and the metamodel says “covering”. The maintainers kept both as synonyms.
  • Disjoint: one instance can belong to only one specialization in the set.

Where it appears. One source states that generalization can be shown only on class diagrams and use case diagrams.

Example

Section titled “Example”

A shop models a general class “Payment”. Two specific classes, “CardPayment” and “BankTransfer”, each point to it with a hollow triangle. Both inherit what all payments share, such as an amount. Each adds its own details. “Payment” is abstract, so the shop never creates a plain payment. A card payment can be used wherever a payment is expected. If the set holds only these two classes and no payment is both, it is complete and disjoint.

Trade-offs

Section titled “Trade-offs”

Inheritance is an intimate relationship, and it has dangers. Superclass behavior can easily be broken, and changes to the superclass affect every subclass. Keep hierarchies shallow and use them only where substitution truly holds.

Two specific payment classes generalize to one abstract Payment class.

Diagram source 
@startuml
abstract class Payment {
  amount
}
class CardPayment {
  cardNumber
}
class BankTransfer {
  iban
}
Payment <|-- CardPayment
Payment <|-- BankTransfer
@enduml

Checks

Section titled “Checks”
  • Generalization arrows use a hollow triangle and point to the more general class.
  • Every subclass can stand in for its superclass, because each of its instances is also an instance of the superclass.
  • Abstract classes are used only for shared characteristics and have no direct instances.
  • Generalization sets state whether they are complete and whether they are disjoint.
Section titled “Related”

Sources

Section titled “Sources”