UML22 — Packaging Issues with Stereotype Extension

Section: 18.3.2 (Extension)

Extension::metaclass has the type Class. When the Profiles package is merged into L2, Profiles::Class is merged into L2::Class. This means that the metaclass for an extension has to be represented as a UML Class (at L2 or, after further merging, at L3).

However, the UML abstract syntax metamodel is not actually a UML model, but a CMOF model. This means that UML metaclasses are instances of CMOF::Class, not UML::Class (at L2 or L3). This means that it is not possible to actually construct a stereotype extension that points to a metaclass representation of the correct type.

UML tools currently get around this my referencing metaclasses from a version of the UML abstract syntax metamodel that is expressed in terms of UML L3, rather than CMOF. Or they just don't worry about the type checking. But that is not technically correct, and it means that stereotypes in each tool are referencing non-normative representations of the UML metamodel, rather than standard metaclass object IDs.

The problem is resolved by shipping a normative version of the UML metamodel expressed in terms of UML, and changing the text accordingly.
A couple of decisions need making about this metamodel, which we?ve discussed extensively in email:
1. Which compliance level of UML is used to create it? We?ll use the lowest compliance level that we can, which is L1. This means we cannot use Model, so the root of the metamodel will be a uml:Package.
2. Do we apply any stereotypes such as «metamodel» or «metaclass» in the normative UML model? The answer is no and follows from (1): since we don?t use Model, we cannot use «metamodel». Also, using stereotypes in order to specify stereotypes (see 14092) might give circularity or fixed-point issues. We are justified in omitting these by the wording of PresentationOptions in 18.3.1: “A Class that is extended by a Stereotype may be extended by the optional stereotype «metaclass» …”