UML 2.3 RTF Avatar
  1. OMG Issue

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

  • Key: UML23-23
  • Legacy Issue Number: 13482
  • Status: closed  
  • Source: UK Ltd ( Pete Rivett)
  • Summary:

    (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

    {redefines} SuperClock::base_Class. Thus the Stereotype Clock ends up with only one composite owner property.

    It seems there are two main options, one with variants, for addressing the general problem:

    A) Prohibit a stereotype extending more than one metaclass. Or restrict to the special case above where one base_X property can redefine the other.

    I’m not sure how useful it is to have Stereotypes extending multiple metaclasses anyway since one could always declare common properties on an abstract Stereotype with specialized concrete stereotypes each extending a single metaclass. Extending multiple metaclasses also gives rise to potential problems of how to express constraints – which typically require navigation to the extended element and use of its properties: if there are multiple such navigations and different properties at the target element this becomes tortuous to say the least. However I’m sure there are such profiles out there so this will ‘break’ those (despite the fact that they are inherently ill-formed anyway according to profile semantics)

    B) Modify the ‘MOF equivalent metamodel’ and the XMI and XSD rendition of Profiles to make the base_X property 0..1 instead of 1..1. This would need to be combined with a somewhat-tortuous-to-express (especially if there are more than 2 metaclasses extended) constraint that exactly one of the base_X properties (including those inherited from other Stereotypes) must be non-empty. And this constraint could not be expressed in the XSD (not that XSDs are very good for validation anyway).

    C) A variant of B) is to make the base_X property optional only if the Stereotype extends more than one metaclass (including those inherited). This would minimize the impact for the vast majority of existing profiles. However there are complications. In particular it would require redefinition of properties from general stereotypes which extend a single metaclass. In the above extended example with SuperClock, since that extends only one metaclass then SuperClock::base_Class would be defined as 1..1 as in the current specification. However Clock, in addition to defining Clock::base_Component[0..1] would also require Clock::base_Class[0..1} {redefines}

    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)

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT