How to use class generalization

Generalization lets one type in a metamodel inherit from another. The type that inherits is the subclass; the type it inherits from is its superclass. Use it to define something once, such as an Address on every kind of Building, instead of repeating it on House, Factory and Office.

It works for element types and for relationship types.

What a subclass inherits

Inherited	What it means
Property types	An element shows its type’s properties and those of every superclass, all the way up. If two have the same name, the type’s own is used. Inherited properties can be edited, appear in catalogs and boards, and show on diagrams like any other.
A place in relationship constraints	A constraint that names a type also covers its subclasses. If Ownership is allowed from Owner to Building, it can be drawn from a Company to a Factory.

Not inherited: appearance (shape, colours, icon), subordination, and the Abstract and Hidden from palette settings. Each type has its own.

A relationship type inherits property types only. Its constraints, appearance and verbs are its own: a subtype is not limited by its supertype’s constraints.

Find a type’s inheritance

Select the type in the Explorer and open Inheritance in the Properties panel. It lists the type’s Superclasses and its Subclasses. Click a name to go to that type.

The heading tells you what is inside before you open it: Inheritance · 1 superclass, 4 subclasses. A plain Inheritance means the type has neither.

Only direct superclasses and subclasses are listed. To see the whole chain, follow the links.

Add a superclass

1. Select the type that should inherit (for example, House)
2. Open Inheritance and click + Add under Superclasses
3. Type to filter the list, then click the superclass (for example, Building)

The change applies at once. House now has Building’s property types, and every relationship rule that names Building now allows a House.

The list offers only the types that make sense:

• The same kind: element types for an element type, relationship types for a relationship type
• In the same metamodel
• Not already inherited, and not one of the type’s own subclasses, which would make a loop
• Not retired

If the type already has a property with the same name as one it would inherit, the row says so in amber. The type’s own property is used, and the inherited one is hidden.

Add a subclass

Working from the top down is the same change seen from the other side.

1. Select the superclass (for example, Building)
2. Open Inheritance and click + Add under Subclasses
3. Click the type that should inherit from it

The other type keeps any superclasses it already has.

Remove a superclass

Click the ✕ beside a name in either list.

• If nothing depends on it, it is removed at once.
• If something does, a dialog says what, with counts, and asks before anything changes.

Values. Elements may hold values for properties they will no longer have. Choose what happens to them:

• Move the values into notes: each element keeps the value as a line in its notes, such as Share (from Interest): 50
• Discard the values: they cannot be brought back

Click Export a backup first to save the whole project to a file before going on. It is offered, not required.

Relationships. Relationships that were allowed only through the removed superclass are kept, and are flagged as no longer valid. See How to use the integrity checker.

Boards. A board whose columns come from a property the type would lose blocks the removal. Change or delete the board first.

Only elements whose type really loses a property are touched. If House is both a Building and a Property, removing Building leaves whatever House still inherits from Property.

Create an abstract superclass

An abstract type exists only to be inherited from. Nothing is created as one.

1. Select the superclass
2. Open Advanced and tick Abstract

Then:

• It is not offered for creating anything. It leaves the Palette, the lists of element types, and the relationship types offered when you connect two elements. You do not need to tick Hidden from palette as well: it shows ticked and dimmed while Abstract is on, and returns to what it was when you untick Abstract.
• Its name is in italics in the Explorer and in the Inheritance lists, as UML writes an abstract class.
• It can still be named in a relationship constraint. That is how most rules are written: allow Ownership from Owner to Building, and every kind of Owner and Building is covered.
• Its section heading says so: Advanced · abstract.

If you make a type abstract when elements of it already exist, they are kept. They show dimmed in the Explorer, with a note in their Properties, because an element should be one of the type’s subtypes. Untick Abstract, or delete those elements and create them again as a subtype.

Several superclasses

A type can have more than one superclass. It inherits the property types of all of them, and takes part in every relationship rule that names any of them.

Relationship types

Everything above applies. A common use is an abstract relationship type that holds shared properties:

1. Create a relationship type, such as Interest, and give it property types (Start Date, Share)
2. In Advanced, tick Abstract
3. On each specific relationship type (Ownership, Lease), add Interest as a superclass
4. Give each its own property types, and its own Constraints

Every Ownership and Lease then has a Start Date and a Share. Remember that constraints are not inherited: a relationship type with an empty Constraints section can connect anything, whatever its superclass allows. The Constraints section says so when the type has a superclass.

Tips

• Use an abstract base type for properties that several types share (Description, Status, Owner)
• Keep hierarchies shallow: one or two levels is usually enough
• Write relationship constraints against the most general type that is true. It covers the subtypes you have now and the ones you add later
• A type’s Property Types heading counts inherited ones separately: Property Types · 1 + 2 inherited