UML (Unified Modeling Language) is a powerful tool for modeling complex systems, and one of its most useful concepts is UML generalization and specialization. These ideas help organize and simplify relationships by showing how broader classes can share common traits with more specific ones. In this article, I’ll explain how UML generalization and specialization work in practice, using clear examples and a real business case to make these concepts easy to understand and apply.
What Are UML Generalization and Specialization?
Generalization connects a more specific class with a more general class.
For example, Company and Person can both represent different kinds of Client. Therefore, I can model Client as the general class and Company and Person as specialized classes.
The hollow triangular arrow points toward the more general class.
A specialized class inherits the characteristics of its generalized class and can add characteristics of its own.
I can view the same relationship from two directions:
- Company generalizes to Client.
- Company specializes Client.
The underlying UML relationship remains the same.
Abstract General Classes
Sometimes I use a general class only to organize common characteristics. I do not want direct objects of that class.
In the example, Client appears in italics. This indicates an abstract class.
Therefore, I can create Company or Person objects, but I do not create a direct Client object.
An abstract class defines common characteristics without representing direct instances of its own.
Generalization Sets
A general class can have several different ways of being specialized. Therefore, UML lets me organize related generalizations into generalization sets.
I can then add constraints that define how the specialized classes relate.
Complete and Incomplete
A complete generalization set covers every permitted specialization within that set.
An incomplete generalization set leaves room for additional specializations.
For example, the Contact Type set contains Person and Company and is marked as complete. Therefore, every Contact must belong to one of these types.
In contrast, Contact Kind is incomplete. Bank, Interested Party, Client, and Supplier do not necessarily represent every possible kind of Contact.
Disjoint and Overlapping
Disjoint means that one instance can belong to only one specialization within the set.
Overlapping means that one instance may belong to several specializations.
For example, Contact Type is disjoint. Therefore, a Contact is modeled either as Person or Company within this set.
Contact Kind is overlapping. Therefore, the same Contact may, for example, be both Client and Supplier.
Complete or incomplete tells me whether the set covers all alternatives, while disjoint or overlapping tells me whether one instance may belong to several alternatives.
How I Identify Generalizations
I often find generalizations through language.
Statements such as these provide useful clues:
- Company is a kind of Client.
- Person is a kind of Client.
- Client is a type of Contact.
- Supplier is a type of Contact.
I also look for several classes that share the same characteristics. If I repeatedly model the same information, a more general class may be missing.
However, I do not create a generalization only to remove duplication. The broader concept must also make sense in the domain.
I use generalization when the specialized classes genuinely represent different forms of the same broader concept.
Conclusion
UML generalization and specialization help me structure related classes at different levels of abstraction.
I place shared characteristics in a general class and represent more specific concepts as specializations. In addition, abstract classes let me define general concepts without direct instances.
Generalization sets add further precision. Complete and incomplete describe coverage, while disjoint and overlapping describe whether specializations can occur together.
A good UML generalization expresses a real “is a kind of” relationship between the specialized and generalized concepts.
What’s Next?!
If I want to make my UML class models more useful, the next step is to define attributes with more care. That is why I continue with Heuristics for Determining Attributes. In that article, I show how I identify meaningful attributes in a structured way instead of adding details at random. As a result, I can describe classes more clearly, improve model quality, and create diagrams that support requirements analysis much better.
Understand Requirements Through Models
If I want to make requirements easier to understand, I need more than text alone. I need models that show how ideas, processes, and structures connect. In the main article on Requirements Modeling, I explore core Modeling Concepts, Process Modeling with BPMN, and the structural perspective of UML. Together, these topics help me visualize workflows, clarify relationships, and analyze systems more effectively. Click through to see how Requirements Modeling helps me turn complex requirements into clear, structured, and practical insight.
This article covers concepts that are also included in the CPRE certification syllabus.