UML23 — UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents

(This is quite a nasty and significant issue that arose from discussions of issues raised on the UPDM profile. It may well be declared as Urgent.)

(start of issue)

The Profiles chapter claims in a few places (with an example in Figure 18.16) that it’s possible to have a single Stereotype extend many metaclasses. However this is contradicted by the description of Stereotype semantics defined by means of a MOF metamodel equivalent (in Figure 18.4) which shows a ‘base_Interface’ 1..1 composite ownership property on the Home Stereotype. Which makes intuitive sense since you cannot have a free-floating stereotype instance (unattached to any element). However in the case of a Stereotype extending 2 metaclasses this would result in it having 2 mandatory composite owners (e.g. for the example in Figure 18.16 base_Class and base_Component) – which is not permitted (you could never have a valid model since an instance can only ever have one composite owner) and would not make sense (it would require each instance of the Stereotype to be attached to 2 distinct model elements – each property is mandatory).

This 1..1 property is also reflected in the XMI serialization of a Profile (in 18.3.6) that makes the multiplicity of the base_Interface property 1..1 (by default). And in the Profile XSD where the xsd:element and xsd:attribute are again 1..1 (by default).

Note that this issue also arises when a Stereotype inherits from another Stereotype and they both extend different metaclasses. This situation could however be addressed in the restricted case that one metaclass is a specialization of the other and by declaring that one property redefined the other. For example assume we modify Figure 18.16 to have an additional Stereotype SuperClock which generalizes Clock and extends Class (instead of Clock directly extending Class). We could then define that Clock::base_Component

SuperClock::base_Class. This however only works because Component specializes Class. In the general case (for example if SuperClock extended Package) then redefinition would not be possible and SuperClock::base_package would have to be changed to be optional. This violates the general design principle that extending something should not change it.

D) Due to the complications with C), a further variant of B) is to make explicit the multiplicity of the base_X property, in the same way that it can be made explicit for

stereotypes. So SuperClock::basePackage may be explicitly declared to be 0..1. If defaulted to 1..1 then that prohibits it from being specialized – except by a stereotype which extends a subclass of Package and {redefines) SuperClock::basePackage with a [0..1] property. So that makes the use of [1..1] for base_X the equivalent of declaring in Java that the Stereotype is ‘final’ and cannot be extended.

To summarize the impact of these options on existing profiles:

A) Requires a change only for Stereotypes that extend more than one metaclass (directly or indirectly) and probably requires new Stereotypes to be created to cover the multiple metaclasses. In those cases it will have an impact on models applying those Steretypes (to migrate to the new Stereotype) but this is a transformation that can be easily automated.

B) Requires a change to the XMI serialization of all Stereotypes in all existing Profiles (though not models applying those profiles) and their XSD files

C) Requires a change only for Stereotypes that extend more than one metaclass (directly or indirectly) and requires a change to the XMI serialization of their profiles and XSD but for those stereotypes only and possibly their general stereotypes (which could be in another Profile: I think though the only case I’m aware of that does this is UPDM itself which has not yet been Finalized).

D) Has the same impact on existing profiles as C), but has the benefit of simpler and more predictable generation rules.

Option A) has the advantage of retaining the current simple 1..1 structural constraint which is amenable to MOF and XSD validation without the need for OCL support. The other options make it harder to validate that an instance of a stereotype is applied to exactly one instance of a UML metaclass.

(end of issue)

The FTF agreed that this is an issue that needs to be resolved. The solution is to provide another example in
the specification besides the single metaclass example given in Figure 12.15 for multiple metaclass extension
and its MOF equivalent class. Furthermore, informal constraints need to be added to the Stereotype’s
classifier description, stating that: The upper bound of a base property is always 1
• The multiplicity of the base property in single metaclass extension is always 1..1
• The multiplicity of all base properties in multiple metaclass extension is always 0..1, whereas only
one base property is allowed to contain a value at any point during runtime