UML Generalization Sets and Power Types Explained

Business objects often belong to several categories at once. An employee, for example, can be full-time and hold more than one organizational role. UML Generalization Sets help us express how these categories fit together, while power types let us describe the categories themselves. This article explains both concepts through a practical employee model, with examples of complete, incomplete, disjoint, and overlapping sets.

Key Takeaways

• A UML Generalization Set groups generalization relationships that share the same general classifier. Multiple sets can describe different ways of classifying the same instances.
• Complete and incomplete concern coverage. Disjoint and overlapping concern whether the specific classifiers can share instances.
• One employee can be full-time, a manager, and a technical specialist simultaneously, without creating a separate class for that combination.
• An incomplete set does not require its general classifier to be concrete. A complete set does not require it to be abstract.
• A power type is optional. Its instances correspond one-to-one to the specific classifiers in its associated Generalization Set.
• Use power types when the categories themselves need information, such as business codes and descriptions.

Introduction

Anna works full-time, manages an engineering team, and provides specialist technical expertise. These descriptions refer to one employee. A useful model should preserve that single identity while showing how the classifications fit together.

UML Generalization Sets let us organize specializations into dimensions such as working hours and organizational role. Power types let us describe the categories in those dimensions as objects with their own information.

We will build an employee example, read its constraints, and then add power types. The goal is to make the business rules explicit enough for analysts, architects, and stakeholders to discuss the same model confidently.

1 What is a UML Generalization Set?

A generalization relates a more specific classifier to a more general classifier. For example, FullTimeEmployee specializes Employee. Every FullTimeEmployee instance is also an Employee instance.

A Generalization Set groups selected generalization relationships with a common general classifier. In a class diagram, this lets us say which subclasses belong to one classification dimension and what constraints apply to that group.

The distinction matters: four subclasses beneath Employee do not, by themselves, explain which categories are alternatives, which can coexist, or whether the categories cover every employee.

For our model, we will create two named sets:

Both sets share Employee as their general classifier. The sets group the generalizations; they do not create separate employee records.

2 Define the business scope first

Consider an internal employee directory for one company. Each employee has one current employment arrangement. Within this model, every employee is classified as either full-time or part-time according to the company's working-hours standard.

The directory also records selected responsibilities. Some employees manage teams, some provide specialist expertise, and some do both. Other employees, such as administrative assistants, do neither of these two things.

These are the assumptions for our example, not a universal employment taxonomy. Contractors, concurrent contracts, and employment history are outside its scope.

Employee holds shared information such as employeeId and weeklyHours. PartTimeEmployee adds a working-time fraction; Manager adds a management scope; TechnicalSpecialist adds expertise and qualifications.

3 Complete, incomplete, disjoint, and overlapping

Two questions determine the constraints for each set:

1. Must every instance of the general classifier belong to at least one specific classifier in this set?
2. Can the same instance belong to more than one specific classifier in this set?

The first concerns coverage; the second concerns overlap. In the UML metamodel, the corresponding properties are isCovering and isDisjoint. In diagrams, we use labels such as {complete, disjoint}.

Working hours are complete and disjoint

We label workingHours with {complete, disjoint}. Under our stated scope, every employee is full-time or part-time, and no employee is both at the same time.

Completeness supplies the requirement to belong to at least one category. The disjoint constraint prevents an employee from belonging to both categories. Together, they give us exactly one working-hours classification per employee.

Organizational roles are incomplete and overlapping

We label organizationalRole with {incomplete, overlapping}. Manager and TechnicalSpecialist are selected roles, not a complete catalogue of jobs.

Anna belongs to both classifiers. Carla, an administrative assistant, belongs to neither. Carla still has a working-hours classification because the other set is complete.

Overlapping does not mean that every employee must have both roles. Likewise, incomplete does not mean that the model is unfinished or that an employee's data is missing.

Figure 1. Two Generalization Sets organize specializations of Employee.

How to read the notation

The hollow triangular arrowheads point toward Employee, the general classifier. Each pair of subclass lines joins a separate shared arrowhead and carries its own set name and constraints.

Read the workingHours branch independently of organizationalRole. The disjoint constraint on the left does not prevent a FullTimeEmployee from also being a Manager on the right.

A UML diagram can also identify a set by repeating its name beside separate generalization arrows, or by using a dashed line across the relevant arrows. Explicit labels make the intended grouping clear. An unlabeled shared arrowhead alone is not enough to establish which Generalization Sets exist in the model. [1]

4 Test the model with employees

Anna is one object with several classifications. The model does not require three different Anna records or a FullTimeTechnicalManager subclass.

These examples also expose incorrect interpretations. Rejecting Anna because Manager and TechnicalSpecialist overlap would contradict the organizationalRole set. Rejecting Carla because she has neither role would incorrectly treat that set as complete.

Conversely, accepting an employee who is neither full-time nor part-time would violate the workingHours set. The role classifications cannot compensate for missing membership in a different, complete set.

5 Does Employee have to be abstract?

No. Abstractness is a property of a classifier. Completeness is a property of a particular Generalization Set.

An abstract classifier has no direct instances: each instance must also belong to some specialization. A complete Generalization Set imposes a more specific coverage requirement involving the specializations in that set. [1]

Our Employee class is concrete. Nevertheless, its complete workingHours set requires every employee instance to belong to FullTimeEmployee or PartTimeEmployee. Making Employee concrete does not override that constraint.

The reverse distinction is useful too. An abstract Employee could have an incomplete organizationalRole set because employees outside Manager and TechnicalSpecialist could still belong to other specializations, such as FullTimeEmployee. Incomplete does not automatically mean that direct instances of the general class must be allowed.

6 Add power types when categories need information

So far, the model describes employees and their specializations. Now suppose the company also maintains codes and definitions for the categories themselves.

For example, the category represented by Manager might have the business code MGR and a description of the responsibilities that qualify an employee for that role. Those values describe the category, rather than Anna's individual management scope.

A UML power type is a classifier associated with a Generalization Set. Its instances correspond one-to-one to the specific classifiers represented by the generalizations in that set. The power type is optional; the set remains useful without it.

We add WorkingHoursType and OrganizationalRoleType, each with code and description attributes.

Here, manager is an instance of OrganizationalRoleType; Manager is a classifier whose instances are employees. Anna is an instance of Manager. These names refer to different model elements with different responsibilities.

Read the colon notation

The label :WorkingHoursType beside workingHours identifies its power type. Similarly, :OrganizationalRoleType identifies the power type of organizationalRole.

The colon label does not make the power type another superclass of Employee. The employee subclasses still specialize Employee. The additional classifiers describe the categories associated with those subclasses.

Figure 2. Power types add category information. The colon-prefixed labels designate them as power types; the horizontal associations express employee-to-category links.

Read the employee associations

In this model, an employee links to exactly one WorkingHoursType instance. A working-hours category can be linked to zero or more employees.

The OrganizationalRoleType association allows an employee to link to zero, one, or two of the selected role-type instances. Zero supports Carla; two supports Anna. The upper bound of two belongs to this example, which models only Manager and TechnicalSpecialist. It is not a general UML rule for overlapping sets.

The association links must agree with classification. Anna links to fullTime, manager, and technicalSpecialist. Ben links to partTime and technicalSpecialist.

Adding ordinary associations alone would not establish power type semantics. The power type designations identify the correspondence, and our model additionally requires the links to reflect it. UML does not prescribe how an implementation maintains that consistency. [1]

Why this is more than a category list

A catalogue of role names can exist without any relationship to employee subclasses. A power type makes that relationship explicit.

If we extend this organizationalRole set with another specialization, we also need its corresponding OrganizationalRoleType instance. Adding an unrelated catalogue entry while leaving the set unchanged would not preserve the stated one-to-one correspondence.

This is useful when both sides matter: employee subclasses carry relevant structure, while the categories need shared descriptions, business codes, or other information.

7 Common mistakes and modeling choices

Applying constraints across the entire hierarchy

The disjoint constraint belongs to workingHours. It does not make FullTimeEmployee disjoint from Manager. Read each set's membership and constraints before drawing conclusions about combinations.

Treating incomplete as unknown

Carla's classification can be fully known even though she falls outside the selected organizational roles. Missing information about whether an employee is a manager is a different problem and needs its own treatment.

Confusing a category with an employee

The manager instance of OrganizationalRoleType represents a category. It is not Anna or Daniel. Category descriptions belong on the power type side; employee-specific responsibilities belong on the employee side.

Assuming categories need subclasses in every system

For a simple staff list, a working-hours attribute and a collection of role values may be sufficient. Generalization becomes more useful when the specializations also have meaningful properties, relationships, constraints, or behavior.

A system that records repeated role assignments, dates, departments, and approval history may be better served by explicit RoleAssignment objects. Our model describes current classification; it does not define the process of promotion or role reassignment.

Assuming a class diagram determines the implementation

Multiple classification of one instance is not the same as declaring a new class with several superclasses. Anna can have several classifications without introducing a named subclass for every combination.

A programming language or persistence framework may represent this model through composition, role objects, or another implementation strategy. Select that strategy deliberately rather than assuming the diagram translates directly into code.

8 Why this matters

The employee example turns vague category labels into reviewable business rules. HR can check whether the working-hours categories cover the intended population. Managers can check whether responsibilities overlap. Developers can identify where category definitions and employee-specific information belong.

Before adding a Generalization Set, ask what classification question it answers, which generalizations it contains, whether it covers every relevant instance, and whether those instances can share classifications. Then test the result with ordinary cases and exceptions.

The best test is a concrete employee such as Anna or Carla: can everyone reading the diagram explain why her combination is valid?

9 UML 2 Advanced certification connection

Generalization Sets are included in the UML 2 Advanced certification scope. The topic rewards careful interpretation: changing complete to incomplete or disjoint to overlapping changes what a model says about its instances. Consult the official OMG certification resources for the applicable scope. [2]

For further practice, my UML 2 Advanced practice questions include 127 original interactive questions across Advanced topics, including Generalization Sets. They are designed to help identify knowledge gaps alongside study materials and the official scope.

Frequently Asked Questions

Can two Generalization Sets share the same general classifier?

Yes. In our example, workingHours and organizationalRole both use Employee. Each set groups a different selection of generalizations and states its own constraints.

Does complete mean exactly one subclass?

Not by itself. Complete requires membership in at least one specific classifier in the set. Adding disjoint rules out membership in more than one. Our workingHours set combines both constraints.

Can an employee be a manager and work part-time?

Yes. Manager belongs to organizationalRole, while PartTimeEmployee belongs to workingHours. Nothing in our model forbids that combination; Daniel illustrates it.

Can an incomplete set be used with an abstract class?

Yes. An instance can fall outside the specific classifiers in that set while belonging to another specialization of the abstract class. Coverage is evaluated for the particular set, not for every specialization in the model.

Can I swap the order of the completeness and disjointness constraints?

Yes. {complete, disjoint} and {disjoint, complete} have the same meaning. For workingHours, either order requires exactly one classification per employee. complete requires at least one, and disjoint allows at most one.

What happens if I omit the constraints?

For an existing Generalization Set, each omitted constraint takes its own default. Coverage defaults to incomplete, and disjointness defaults to overlapping. With two specific classifiers, the results are as follows.

In our organizationalRole example, writing only {overlapping} preserves the intended rule. Anna can be both a Manager and a TechnicalSpecialist. Daniel can be a Manager only. Carla can belong to neither because coverage defaults to incomplete.

For workingHours, both labels matter. Writing only {disjoint} would allow an employee to be neither full-time nor part-time. Writing only {complete} would allow an employee to be both. The company’s rule requires {complete, disjoint}.

For explanatory diagrams, show both the set name and its constraints. [1]

Is a power type required for every Generalization Set?

No. Use a power type when the category objects and their correspondence to specific classifiers add useful meaning. A set can express coverage and overlap without one.

Is OrganizationalRoleType an enumeration?

In this example, it is a class with instances that have codes and descriptions. The important power type property is the correspondence between those instances and the specific classifiers in organizationalRole. A list of enumeration literals alone does not establish that correspondence.

Related Reading and References

• The 5 Most Useful UML Diagrams for Software Engineers
• Which UML Diagrams Are Covered in OMG UML Exams
• [1] OMG Unified Modeling Language 2.5.1: section 9.2.3.2 on generalization and abstract classifiers; sections 9.7.3 and 9.7.4 on generalization-set semantics, power types, and notation.
• [2] OMG UML Certification: official certification and exam-scope resources.

About eduMAX

eduMAX provides training and practice materials for modeling with UML, BPMN, and SysML. As an OMG Accredited Training Provider for UML 2 and BPM 2, eduMAX helps practitioners develop their modeling skills and prepare for certification. Explore more practical explanations on the eduMAX blog.

Why Trust This Article

I am Filip Stachecki, a consultant, trainer, and founder of eduMAX. Since 2013, I have contributed to OMG certification programs, including exam scopes and official questions for UML 2 (OCUP 2) and BPM 2 (OCEB 2). I hold Advanced certifications in both UML 2 and BPM 2.