Issue 13482: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents (uml2-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Revision Severity: Critical 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 {required} 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) Resolution: Revised Text: Actions taken: February 11, 2009: received issue Discussion: End of Annotations:===== ubject: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Wed, 11 Feb 2009 17:43:35 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmMs1GAnsDXYSRJSLG8WnbU3CWfWw== Priority: Urgent From: "Pete Rivett" To: Cc: (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 {required} 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jBg08ErWEXHMqtWh9BJjX3CJiI3CctYMmiz77QdurJQ=; b=H+SQ+aZINfGEfftS4Kzx5X2sCeZamMx8bMFkJVUyZF9uctPRfCJ4LbeEsvM1sKl+XF yUMWqZfrfEc8hx8Nc8Uqk4xYiyhau8iJjw7uSzOSIy8hbcub9Cbrfju/ZMyZFstwXMm0 8vn/JmbDufcQY1X6nh+eydEbfNpNznMamoUqo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NMOmb7mtuxYlB0AzYQF0YxrJROvxVUbiK+3bviEbXc+3plcApIJs+6RDIJhabnwKTG M/zcEL2zyMHRHrVzBvZIZV3pBoBInRW5+xDwkCNgX++SQXe1YNom13kcQ7zl3nXMIAKN dhTTgLNFGsL0B+UDThi4PhZj6UOY9VPzlmwzU= Date: Wed, 11 Feb 2009 22:03:37 -0500 Subject: Re: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents From: Bran Selic To: Pete Rivett Cc: issues@omg.org, uml2-rtf@omg.org Pete, First of all, I'd like to explain why it is absolutely necessary to have the ability for a stereotype to extend more than one metaclass: Take, for example, a case where we need to define a <> stereotype. The most obvious base class for this is, of course, the Class meta-class. Next, consider a case where, in a given model we not only want to apply this stereotype to certain M1 instances of Class, but also to other model elements. For instance, we might want to apply the same <> stereotype to a role in a collaboration or a part in a structured class that is typed by the stereotyped Class. Unfortunately, these are instances of a kind of ConnectableElement and not instances of Class. So, unless we are allowed to have the <> stereotype to extend both Class and ConnectableElement, we need to define a new stereotype <>, that extends ConnectableElement and which is, a clone of <> since it has all the same tagged values/attributes. Such cloning is not practical, since there are cases where a given stereotype may be applied to a large number of different kinds of metamodel elements. (This is particularly useful in profiles used for specialized domain analyses, whereby a domain concept may have many different UML manifestations.) Therefore, this a very important feature that is used by a number of existing OMG-adopted profiles. I do agree, however, that there is a problem with the construct shown in figure 18.4. Note that nothing in the metamodel in figure 18.2 suggests that stereotypes should be owned by their base classes. (In fact, stereotypes and their respective extensions should be owned by the profile in which they appear.; it makes no sense for them to hang around if the profile is deleted.) Furthermore, there is something else that is fishy about figure 18.4, since I don't see any Extensions with ExtensionEnds in the diagram, which I expected. This gets into the hairy parts of meta-level crossover that I will need to think about more deeply -- but don't have time to right now. It would be interesting to see how the various vendors dealt with this issue in their implementations. Cheers...Bran On Wed, Feb 11, 2009 at 8:43 PM, Pete Rivett wrote: (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 {required} 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) Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Wed, 11 Feb 2009 19:20:02 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmMvp5wsM3mhC5aSr+QnitFcThftQAACEuw From: "Pete Rivett" To: "Bran Selic" Cc: Hi Bran, I.m still not convinced (but still open to persuasion) of the usefulness of stereotypes applied to multiple metaclasses: as I suggested in the issue you could avoid cloning property sets by attaching them to an abstract Stereotype (which does not extend any metaclass). Another disadvantage, as I also pointed out, is it becomes impractical to try and express constraints attached to such Stereotypes . since you have no predictability as to what metaclass (and properties thereon) you will be dealing with. But regardless of whether they are a good idea, we need to manage the fact that existing profiles may make use of them. It would be I think be useful to try and quantify the extent of such usage, in terms of number of profiles and number of such stereotypes in each. We need to try and evaluate the real impact of the different options. Note that figure 18.4 is a model for instances of the Stereotype so you would not expect to see ExtensionEnds etc. which are in the Profile itself not its instances: the diagram does in fact show a slot corresponding to the ExtensionEnd. And you do want instances of the Stereotype to be owned by the elements to which they are applied . so that if the element is deleted (e.g. a specific Component) then the applied stereotype instance is deleted, not floating around unattached. That is not expressed in Figure 18.2 (the wrong meta-level) but is expressed in 18.3.3 .The aggregation of an ExtensionEnd is always composite.. Regards Pete From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 11 February 2009 19:04 To: Pete Rivett Cc: issues@omg.org; uml2-rtf@omg.org Subject: Re: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, First of all, I'd like to explain why it is absolutely necessary to have the ability for a stereotype to extend more than one metaclass: Take, for example, a case where we need to define a <> stereotype. The most obvious base class for this is, of course, the Class meta-class. Next, consider a case where, in a given model we not only want to apply this stereotype to certain M1 instances of Class, but also to other model elements. For instance, we might want to apply the same <> stereotype to a role in a collaboration or a part in a structured class that is typed by the stereotyped Class. Unfortunately, these are instances of a kind of ConnectableElement and not instances of Class. So, unless we are allowed to have the <> stereotype to extend both Class and ConnectableElement, we need to define a new stereotype <>, that extends ConnectableElement and which is, a clone of <> since it has all the same tagged values/attributes. Such cloning is not practical, since there are cases where a given stereotype may be applied to a large number of different kinds of metamodel elements. (This is particularly useful in profiles used for specialized domain analyses, whereby a domain concept may have many different UML manifestations.) Therefore, this a very important feature that is used by a number of existing OMG-adopted profiles. I do agree, however, that there is a problem with the construct shown in figure 18.4. Note that nothing in the metamodel in figure 18.2 suggests that stereotypes should be owned by their base classes. (In fact, stereotypes and their respective extensions should be owned by the profile in which they appear.; it makes no sense for them to hang around if the profile is deleted.) Furthermore, there is something else that is fishy about figure 18.4, since I don't see any Extensions with ExtensionEnds in the diagram, which I expected. This gets into the hairy parts of meta-level crossover that I will need to think about more deeply -- but don't have time to right now. It would be interesting to see how the various vendors dealt with this issue in their implementations. Cheers...Bran On Wed, Feb 11, 2009 at 8:43 PM, Pete Rivett wrote: (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 {required} 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/SCkbbvakgOzsWjOuVDe+YDqANy+s5swilaWE1q0sSU=; b=bb3qK7eso2/75rD/eOeeGwiCzP+ZOAuQfe0HgvjK1NlEY3yNSZ6rRmkw2UmfWSOyZs zjgo6KLQaXTcuTDVsehbAMc2v2pCeigqlFLfCBAdXzM7kQOSDdilE2KbQB+ywl3Si3Fe mHYR+cliFx7JjAW854ORdLsYodLMf9UoVoIyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iT24xXgR1NEcqi76loJWuW0sjFGGzdvDlyI64S5cvSfGREO2aWJ4TWYaG8Ic8QksIL VFTBzqmZwnIAmadmh3nHMgFyu1o2zfmIyLKBexP06VXgRmrsOOUw//rH7fhTOlPnJCwg mbww6hHkUUjc5v4z3TnAO4ZmfVNU+jfC/uXmM= Date: Thu, 12 Feb 2009 00:12:56 -0500 Subject: Re: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents From: Bran Selic To: Pete Rivett Cc: uml2-rtf@omg.org Hello Pete, Thanks for the quick response. Further comments below: On Wed, Feb 11, 2009 at 10:20 PM, Pete Rivett wrote: Hi Bran, I'm still not convinced (but still open to persuasion) of the usefulness of stereotypes applied to multiple metaclasses: Whether or not you are open to persuasion, this is a requirement for profiles, not only because current profiles use it, but also because it is a very useful feature. It is particularly useful in case of so-called viewpoint profiles, which are profiles that are overlaid on a UML model typically for purposes of analysis. For example, you may need to do a performance analysis on a UML model. In that case, you need to identify which parts of the model represent servers and which parts represent clients. The mapping of these specialized domain concepts to corresponding UML concepts is one to many, because the UML model may have been designed without any consideration given to the analysis concepts. (Once annotated in this way, it becomes possible to translate such a model automatically into an analysis-specific model, otherwise it is not possible in the general case.) Just because something is "tortuous-to-express" as you say should not be a reason to reject a requirement. In this case, it is not a question of feasibility or core conflict, but just of some surmountable implementation difficulty -- a one time cost. This does not seem sufficient grounds to remove an important capability. as I suggested in the issue you could avoid cloning property sets by attaching them to an abstract Stereotype (which does not extend any metaclass). My apologies, but I cannot discern this part in your proposal; can you please point it out? If there is an alternative solution that fully satisfies the requirement and has advantages, I am all for it. I just don't want to lose the requirement. Note that, in general, there does not have to exist any kind of subclassing relationship between the metaclasses that may need to share a stereotype (and, I do not believe that stereotyping Element is a solution). Another disadvantage, as I also pointed out, is it becomes impractical to try and express constraints attached to such Stereotypes . since you have no predictability as to what metaclass (and properties thereon) you will be dealing with. This is the "it is difficult for implementors" argument, which I do not accept. Besides, you can always do a simple check in your OCL to determine which class you are dealing with. It doesn't look that hard to me. But regardless of whether they are a good idea, we need to manage the fact that existing profiles may make use of them. It would be I think be useful to try and quantify the extent of such usage, in terms of number of profiles and number of such stereotypes in each. We need to try and evaluate the real impact of the different options. I think quantifying this and figuring out what the results mean is a lot more complicated than doing the lesser bit of extra work to support the requirement. Note that figure 18.4 is a model for instances of the Stereotype so you would not expect to see ExtensionEnds etc. which are in the Profile itself not its instances: the diagram does in fact show a slot corresponding to the ExtensionEnd. Right. I noticed that after I sent the previous e-mail. Sorry for the red herring. And you do want instances of the Stereotype to be owned by the elements to which they are applied . so that if the element is deleted (e.g. a specific Component) then the applied stereotype instance is deleted, not floating around unattached. That is not expressed in Figure 18.2 (the wrong meta-level) but is expressed in 18.3.3 "The aggregation of an ExtensionEnd is always composite." Agreed. Cheers...Bran From: "Rouquette, Nicolas F" To: Bran Selic , Pete Rivett CC: "uml2-rtf@omg.org" Date: Thu, 12 Feb 2009 01:07:55 -0800 Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmM0OIba3cTQeLVSU+C3tKSqCOCFAADEA5g Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized I propose another alternative, option (E), which would involve the following: - Make ProfileApplication a kind of PackageMerge relationship instead of an Association. - Create a new metaclass, PackagedExtensions, which will be the owner of the instances of the stereotypes applied to elements of the package with the applied profile defining these stereotypes. There are several benefits to this approach: - Extending multiple metaclasses is OK because ownership of the stereotype applied is to the new PackagedExtensions package rather than to the extended element - It simplifies the separate serialization of a model from that of the application of a profile to that model. There are some important implications to this option: - It involves tinkering in a sensitive and difficult part of the metamodel - Following Figure 18.4, applying a profile, HomeExample, to a package, P1, requires creating a new package, P1[PackagedExtensions] that are, respectively, the source merged package and the target receiving package of the ProfileApplication relationship which became a kind of PackageMerge relation with a link to the profile being applied, HomeProfile. - Whenever a stereotype, Home, is added to an element, I, in the source merged package (P1), a tool would have to create for the user a corresponding element in the target receiving package, I so that, as a result of applying the semantics of package merge, we would obtain a new package corresponding to an M1-level equivalent of the M2 MOF equivalent shown in Figure 18.4 See the attached figure for details. I used the example of Figure 18.4 to illustrate this option. Finally, note that the MARTE and ODM profiles rely extensively on the idiom where one stereotype extends 2 or more metaclasses. SysML has non-normative extensions where some stereotypes extend 2 metaclasses (e.g., objectiveFunction in C.3.2) n Nicolas. From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Wednesday, February 11, 2009 9:13 PM To: Pete Rivett Cc: uml2-rtf@omg.org Subject: Re: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Hello Pete, Thanks for the quick response. Further comments below: On Wed, Feb 11, 2009 at 10:20 PM, Pete Rivett wrote: Hi Bran, I'm still not convinced (but still open to persuasion) of the usefulness of stereotypes applied to multiple metaclasses: Whether or not you are open to persuasion, this is a requirement for profiles, not only because current profiles use it, but also because it is a very useful feature. It is particularly useful in case of so-called viewpoint profiles, which are profiles that are overlaid on a UML model typically for purposes of analysis. For example, you may need to do a performance analysis on a UML model. In that case, you need to identify which parts of the model represent servers and which parts represent clients. The mapping of these specialized domain concepts to corresponding UML concepts is one to many, because the UML model may have been designed without any consideration given to the analysis concepts. (Once annotated in this way, it becomes possible to translate such a model automatically into an analysis-specific model, otherwise it is not possible in the general case.) Just because something is "tortuous-to-express" as you say should not be a reason to reject a requirement. In this case, it is not a question of feasibility or core conflict, but just of some surmountable implementation difficulty -- a one time cost. This does not seem sufficient grounds to remove an important capability. as I suggested in the issue you could avoid cloning property sets by attaching them to an abstract Stereotype (which does not extend any metaclass). My apologies, but I cannot discern this part in your proposal; can you please point it out? If there is an alternative solution that fully satisfies the requirement and has advantages, I am all for it. I just don't want to lose the requirement. Note that, in general, there does not have to exist any kind of subclassing relationship between the metaclasses that may need to share a stereotype (and, I do not believe that stereotyping Element is a solution). Another disadvantage, as I also pointed out, is it becomes impractical to try and express constraints attached to such Stereotypes . since you have no predictability as to what metaclass (and properties thereon) you will be dealing with. This is the "it is difficult for implementors" argument, which I do not accept. Besides, you can always do a simple check in your OCL to determine which class you are dealing with. It doesn't look that hard to me. But regardless of whether they are a good idea, we need to manage the fact that existing profiles may make use of them. It would be I think be useful to try and quantify the extent of such usage, in terms of number of profiles and number of such stereotypes in each. We need to try and evaluate the real impact of the different options. I think quantifying this and figuring out what the results mean is a lot more complicated than doing the lesser bit of extra work to support the requirement. Note that figure 18.4 is a model for instances of the Stereotype so you would not expect to see ExtensionEnds etc. which are in the Profile itself not its instances: the diagram does in fact show a slot corresponding to the ExtensionEnd. Right. I noticed that after I sent the previous e-mail. Sorry for the red herring. And you do want instances of the Stereotype to be owned by the elements to which they are applied . so that if the element is deleted (e.g. a specific Component) then the applied stereotype instance is deleted, not floating around unattached. That is not expressed in Figure 18.2 (the wrong meta-level) but is expressed in 18.3.3 "The aggregation of an ExtensionEnd is always composite." Agreed. Cheers...Bran ProfileApplication as PackageMerge.jpg HomeExample Model.jpg HomeExample Profile.jpg Reply-To: From: "Conrad Bock" To: "'Pete Rivett'" , Cc: Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Thu, 12 Feb 2009 08:56:06 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmMs1GAnsDXYSRJSLG8WnbU3CWfWwAZiWoA X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n1CDu6D1021500 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1235051772.18578@mapQIQEPNMH1b5uTuE3KeQ X-Spam-Status: No Pete, > 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). My understanding is a stereotype can have multiple base classes, but can only be applied to intances of one of those base classes at M1. Conrad Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Thu, 12 Feb 2009 07:21:30 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmMs1GAnsDXYSRJSLG8WnbU3CWfWwAZiWoAAALzgZA= From: "Pete Rivett" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n1CFLTkv017889 That I believe is the intention, Conrad. But the effective metamodel in 18.4 (and the XMI) states that ALL the base_X properties are mandatory. Applying a stereotype instance to only one base class instance will leave one or more base_X[1..1 ] properties empty. Pete -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: 12 February 2009 05:56 To: Pete Rivett; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, > 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). My understanding is a stereotype can have multiple base classes, but can only be applied to intances of one of those base classes at M1. Conrad To: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents X-KeepSent: 825658CE:A36FCA19-8525755B:0055A246; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Jim Amsden Date: Thu, 12 Feb 2009 10:48:37 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 02/12/2009 08:48:37, Serialize complete at 02/12/2009 08:48:37 Pete, I also agree that this is the intention, and is currently supported by RSM. I don't know exactly what is done about the base_X constraint in the XML - likely its ignored. When I get a chance I'll create a simple example and see what the XMI looks like. Re: figure 18.4, consider stereotype Home as extending Interface or Class. I interpret figure 18.4 as indicating an instance of stereotype Home applied to an instance of metaclass Interface must be connected by base_Interface. But another instance of stereotype Home could be applied to class Foo and would related by base_Foo. That would imply that Home has two properties base_Interface and base_Foo that would need to have multiplicity 0..1 with a constraint that for any instance of Home, one of them must be non-null. Would that work? I also agree with Bran that it is necessary for a stereotype to extend more than one metaclass. SoaML uses this: ServiceInterface can extend Class or Interface. From: "Pete Rivett" To: Cc: Date: 02/12/2009 10:28 AM Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents -------------------------------------------------------------------------------- That I believe is the intention, Conrad. But the effective metamodel in 18.4 (and the XMI) states that ALL the base_X properties are mandatory. Applying a stereotype instance to only one base class instance will leave one or more base_X[1..1 ] properties empty. Pete -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: 12 February 2009 05:56 To: Pete Rivett; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, > 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). My understanding is a stereotype can have multiple base classes, but can only be applied to intances of one of those base classes at M1. Conrad Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Thu, 12 Feb 2009 08:23:17 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmNKZ57GthzEDpWQQWBxxRMS9djUwABBpEg From: "Pete Rivett" To: "Jim Amsden" , Ø That would imply that Home has two properties base_Interface and base_Foo that would need to have multiplicity 0..1 with a constraint that for any instance of Home, one of them must be non-null. Would that work? That is my option B). Which has the impacts I identify in the issue. And it also has variants C) and D) . for example we could retain the multiplicity as 1..1 if we know that only one metaclass is extended. That minimizes the impact on existing profiles whose stereotypes don.t extend multiple metaclasses. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 12 February 2009 07:49 To: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, I also agree that this is the intention, and is currently supported by RSM. I don't know exactly what is done about the base_X constraint in the XML - likely its ignored. When I get a chance I'll create a simple example and see what the XMI looks like. Re: figure 18.4, consider stereotype Home as extending Interface or Class. I interpret figure 18.4 as indicating an instance of stereotype Home applied to an instance of metaclass Interface must be connected by base_Interface. But another instance of stereotype Home could be applied to class Foo and would related by base_Foo. That would imply that Home has two properties base_Interface and base_Foo that would need to have multiplicity 0..1 with a constraint that for any instance of Home, one of them must be non-null. Would that work? I also agree with Bran that it is necessary for a stereotype to extend more than one metaclass. SoaML uses this: ServiceInterface can extend Class or Interface. From: "Pete Rivett" To: Cc: Date: 02/12/2009 10:28 AM Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents -------------------------------------------------------------------------------- That I believe is the intention, Conrad. But the effective metamodel in 18.4 (and the XMI) states that ALL the base_X properties are mandatory. Applying a stereotype instance to only one base class instance will leave one or more base_X[1..1 ] properties empty. Pete -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: 12 February 2009 05:56 To: Pete Rivett; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, > 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). My understanding is a stereotype can have multiple base classes, but can only be applied to intances of one of those base classes at M1. Conrad Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Thu, 12 Feb 2009 08:35:50 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmMs1GAnsDXYSRJSLG8WnbU3CWfWwAZiWoAAALzgZAAAYYy0AAA7I/w From: "Pete Rivett" To: "Rouquette, Nicolas F" Cc: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n1CGZcIV015989 I don't see that explicitly (and am in too much of a rush to check). IMHO I think you are applying it to the wrong end. Instead: extension_S[1..1] corresponds to Extension::isRequired = true. extension_S[0..1] corresponds to Extension::isRequired = false. Where S is the stereotype name e.g. extension_Home. isRequired governs whether each instance of the base class must have an instance of the stereotype attached. > Extension::isRequired=true makes sense only in the case where a stereotype extends directly or indirectly only one metaclass. No - it is valid to say that each instance of Class AND each instance of Component must have stereotype Clock applied. > If a stereotype has multiple extensions, then all extensions must necessarily be non-required. That represents options B C D in the issue. But has nothing to do with isRequired. Pete -----Original Message----- From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 12 February 2009 08:16 To: Pete Rivett; conrad.bock@nist.gov Cc: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, According to 18.3.2 /isRequired means the following: base_X[1..1] corresponds to Extension::isRequired = true. base_X[0..1] corresponds to Extension::isRequired = false. Extension::isRequired=true makes sense only in the case where a stereotype extends directly or indirectly only one metaclass. If a stereotype has multiple extensions, then all extensions must necessarily be non-required. -- Nicolas. > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Thursday, February 12, 2009 7:22 AM > To: conrad.bock@nist.gov > Cc: uml2-rtf@omg.org > Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple > metaclasses are ill-formed as metamodel equivalents > > That I believe is the intention, Conrad. But the effective metamodel in > 18.4 (and the XMI) states that ALL the base_X properties are mandatory. > Applying a stereotype instance to only one base class instance will > leave one or more base_X[1..1 ] properties empty. > > Pete > > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: 12 February 2009 05:56 > To: Pete Rivett; issues@omg.org > Cc: uml2-rtf@omg.org > Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple > metaclasses are ill-formed as metamodel equivalents > > > > Pete, > > > 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). > > My understanding is a stereotype can have multiple base > classes, but can only be applied to intances of one of > those base classes at M1. > > Conrad From: "Rouquette, Nicolas F" To: Pete Rivett CC: "uml2-rtf@omg.org" , "conrad.bock@nist.gov" Date: Thu, 12 Feb 2009 09:25:07 -0800 Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmMs1GAnsDXYSRJSLG8WnbU3CWfWwAZiWoAAALzgZAAAYYy0AAA7I/wAAGEQ1A= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n1CHPAdK000699 You're correct, I was mistaken. Option (D) seems to me to be the most pragmatic resolution to this issue. The option (E) I proposed earlier addresses a closely related issue about relaxing the compositional ownership of stereotype instances (your issue) and of profile application elements. The latter matters for the purpose of serializing a package as a separate resource distinct from the resource containing the stereotype instances corresponding to the application of a profile to that package. Nicolas. > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Thursday, February 12, 2009 8:36 AM > To: Rouquette, Nicolas F > Cc: uml2-rtf@omg.org; conrad.bock@nist.gov > Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple > metaclasses are ill-formed as metamodel equivalents > > I don't see that explicitly (and am in too much of a rush to check). > IMHO I think you are applying it to the wrong end. Instead: > extension_S[1..1] corresponds to Extension::isRequired = true. > extension_S[0..1] corresponds to Extension::isRequired = false. > Where S is the stereotype name e.g. extension_Home. > > isRequired governs whether each instance of the base class must have an > instance of the stereotype attached. > > > Extension::isRequired=true makes sense only in the case where a > stereotype extends directly or indirectly only one metaclass. > > No - it is valid to say that each instance of Class AND each instance of > Component must have stereotype Clock applied. > > > If a stereotype has multiple extensions, then all extensions must > necessarily be non-required. > That represents options B C D in the issue. But has nothing to do with > isRequired. > > Pete > > -----Original Message----- > From: Rouquette, Nicolas F [mailto:nicolas.f.rouquette@jpl.nasa.gov] > Sent: 12 February 2009 08:16 > To: Pete Rivett; conrad.bock@nist.gov > Cc: uml2-rtf@omg.org > Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple > metaclasses are ill-formed as metamodel equivalents > > Pete, > > According to 18.3.2 /isRequired means the following: > > base_X[1..1] corresponds to Extension::isRequired = true. > base_X[0..1] corresponds to Extension::isRequired = false. > > Extension::isRequired=true makes sense only in the case where a > stereotype extends directly or indirectly only one metaclass. > > If a stereotype has multiple extensions, then all extensions must > necessarily be non-required. > > -- Nicolas. > > > > -----Original Message----- > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > Sent: Thursday, February 12, 2009 7:22 AM > > To: conrad.bock@nist.gov > > Cc: uml2-rtf@omg.org > > Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple > > metaclasses are ill-formed as metamodel equivalents > > > > That I believe is the intention, Conrad. But the effective metamodel > in > > 18.4 (and the XMI) states that ALL the base_X properties are > mandatory. > > Applying a stereotype instance to only one base class instance will > > leave one or more base_X[1..1 ] properties empty. > > > > Pete > > > > -----Original Message----- > > From: Conrad Bock [mailto:conrad.bock@nist.gov] > > Sent: 12 February 2009 05:56 > > To: Pete Rivett; issues@omg.org > > Cc: uml2-rtf@omg.org > > Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple > > metaclasses are ill-formed as metamodel equivalents > > > > > > > > Pete, > > > > > 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). > > > > My understanding is a stereotype can have multiple base > > classes, but can only be applied to intances of one of > > those base classes at M1. > > > > Conrad Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Thu, 12 Feb 2009 17:18:27 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents thread-index: AcmM0L7r4Wu9JzoDSqa5Ni1rTzheAAAjO7iQ From: "Cory Casanave" To: "Bran Selic" , "Pete Rivett - Adaptive" Cc: Pete, I would like to second Bran.s position that this is a valuable feature and should be fully supported . implementation considerations may impact how it is represented but not if it is represented. An RTF should not deleted valuable features in use. This feature is also used in SoaML. If fact it was somewhat of a problem when mapping from the SoaML profile to the meta model to find that limits in MOF prevented a clean mapping . so I see this as fundamentally a MOF issue. The way the profile was expressed in SoaML matched our design intent . MOF didn.t. Semantically you shouldn.t have two associations but one association that can be of either type (the union type). Either two 0..1 associations could be used with a constraint (your option a), or, you could have one 1..1 association with a type constraint. You could also use .redefines. to express these constraints. So, there is multiple ways to express it in the model. If our models were very well factored it is possible a super type would exist for all cases where we wanted a choice of the base . but this is UML. And the user can.t create new UML super types. As for ownership . we frequently want to have stereotypes applied in a model other than the owning model. For example, for specializing technology details in a PSM level model. In this case the model elements being stereotypes may not be modifiable by the model that applies the stereotypes. In this case the applied elements should cascade delete when the model with the stereotypes is updated to the current imported model . most tools do this. So, the stereotyped element should not own the stereotype. -Cory (A View from the trenches) -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Thursday, February 12, 2009 12:13 AM To: Pete Rivett - Adaptive Cc: uml2-rtf@omg.org Subject: Re: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Hello Pete, Thanks for the quick response. Further comments below: On Wed, Feb 11, 2009 at 10:20 PM, Pete Rivett wrote: Hi Bran, I'm still not convinced (but still open to persuasion) of the usefulness of stereotypes applied to multiple metaclasses: Whether or not you are open to persuasion, this is a requirement for profiles, not only because current profiles use it, but also because it is a very useful feature. It is particularly useful in case of so-called viewpoint profiles, which are profiles that are overlaid on a UML model typically for purposes of analysis. For example, you may need to do a performance analysis on a UML model. In that case, you need to identify which parts of the model represent servers and which parts represent clients. The mapping of these specialized domain concepts to corresponding UML concepts is one to many, because the UML model may have been designed without any consideration given to the analysis concepts. (Once annotated in this way, it becomes possible to translate such a model automatically into an analysis-specific model, otherwise it is not possible in the general case.) Just because something is "tortuous-to-express" as you say should not be a reason to reject a requirement. In this case, it is not a question of feasibility or core conflict, but just of some surmountable implementation difficulty -- a one time cost. This does not seem sufficient grounds to remove an important capability. as I suggested in the issue you could avoid cloning property sets by attaching them to an abstract Stereotype (which does not extend any metaclass). My apologies, but I cannot discern this part in your proposal; can you please point it out? If there is an alternative solution that fully satisfies the requirement and has advantages, I am all for it. I just don't want to lose the requirement. Note that, in general, there does not have to exist any kind of subclassing relationship between the metaclasses that may need to share a stereotype (and, I do not believe that stereotyping Element is a solution). Another disadvantage, as I also pointed out, is it becomes impractical to try and express constraints attached to such Stereotypes . since you have no predictability as to what metaclass (and properties thereon) you will be dealing with. This is the "it is difficult for implementors" argument, which I do not accept. Besides, you can always do a simple check in your OCL to determine which class you are dealing with. It doesn't look that hard to me. But regardless of whether they are a good idea, we need to manage the fact that existing profiles may make use of them. It would be I think be useful to try and quantify the extent of such usage, in terms of number of profiles and number of such stereotypes in each. We need to try and evaluate the real impact of the different options. I think quantifying this and figuring out what the results mean is a lot more complicated than doing the lesser bit of extra work to support the requirement. Note that figure 18.4 is a model for instances of the Stereotype so you would not expect to see ExtensionEnds etc. which are in the Profile itself not its instances: the diagram does in fact show a slot corresponding to the ExtensionEnd. Right. I noticed that after I sent the previous e-mail. Sorry for the red herring. And you do want instances of the Stereotype to be owned by the elements to which they are applied . so that if the element is deleted (e.g. a specific Component) then the applied stereotype instance is deleted, not floating around unattached. That is not expressed in Figure 18.2 (the wrong meta-level) but is expressed in 18.3.3 "The aggregation of an ExtensionEnd is always composite." Agreed. Cheers...Bran Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Thu, 12 Feb 2009 14:44:37 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmM0L7r4Wu9JzoDSqa5Ni1rTzheAAAjO7iQAADhQHA= From: "Pete Rivett" To: "Cory Casanave" , "Bran Selic" Cc: From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 12 February 2009 14:18 To: Bran Selic; Pete Rivett Cc: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, I would like to second Bran.s position that this is a valuable feature and should be fully supported . implementation considerations may impact how it is represented but not if it is represented. An RTF should not deleted valuable features in use. This feature is also used in SoaML. If fact it was somewhat of a problem when mapping from the SoaML profile to the meta model to find that limits in MOF prevented a clean mapping . so I see this as fundamentally a MOF issue. The way the profile was expressed in SoaML matched our design intent . MOF didn.t. Semantically you shouldn.t have two associations but one association that can be of either type (the union type). Either two 0..1 associations could be used with a constraint (your option a), or, you could have one 1..1 association with a type constraint. You could also use .redefines. to express these constraints. So, there is multiple ways to express it in the model. [PJR] I (tried to) enumerate the options and their pros, cons and impacts in the issue: for example you cannot generally use redefines without inheritance. I cannot see how .one 1..1 association with a type constraint. would work unless the association were to Element. Or is that your next point? If our models were very well factored it is possible a super type would exist for all cases where we wanted a choice of the base . but this is UML. And the user can.t create new UML super types. As for ownership . we frequently want to have stereotypes applied in a model other than the owning model. For example, for specializing technology details in a PSM level model. In this case the model elements being stereotypes may not be modifiable by the model that applies the stereotypes. In this case the applied elements should cascade delete when the model with the stereotypes is updated to the current imported model . most tools do this. So, the stereotyped element should not own the stereotype. [PJR] I was fine until your last sentence which is I think confusing Stereotype elements with stereotype instances: as you point out the instances should be deleted when the elements they are applied to are deleted. In order to achieve this, the equivalent metamodel needs to show the Stereotype compositely aggregated (aka . owned.) by the extended Metaclass. This does not imply that applying a stereotype .modifies. the element to which it is applied . though as I.ve pointed out before this notion of whether certain changes count as modifying an element is undefined: it.s not a concept that MOF says anything about. [PJR] Note, as pointed out by another issue, Figure 18.4 is employing the idiosyncratic UML specification convention of using navigability instead of the .dot notation. to indicate property ownership. Though the extension_Home property is owned by the Association/Extension, the association should be efficiently traversable in either direction (which has been the official meaning of navigability since UML 2.0 was Finalized) . since otherwise stereotype constraints will be a disaster. -Cory (A View from the trenches) -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Thursday, February 12, 2009 12:13 AM To: Pete Rivett - Adaptive Cc: uml2-rtf@omg.org Subject: Re: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Hello Pete, Thanks for the quick response. Further comments below: On Wed, Feb 11, 2009 at 10:20 PM, Pete Rivett wrote: Hi Bran, I'm still not convinced (but still open to persuasion) of the usefulness of stereotypes applied to multiple metaclasses: Whether or not you are open to persuasion, this is a requirement for profiles, not only because current profiles use it, but also because it is a very useful feature. It is particularly useful in case of so-called viewpoint profiles, which are profiles that are overlaid on a UML model typically for purposes of analysis. For example, you may need to do a performance analysis on a UML model. In that case, you need to identify which parts of the model represent servers and which parts represent clients. The mapping of these specialized domain concepts to corresponding UML concepts is one to many, because the UML model may have been designed without any consideration given to the analysis concepts. (Once annotated in this way, it becomes possible to translate such a model automatically into an analysis-specific model, otherwise it is not possible in the general case.) Just because something is "tortuous-to-express" as you say should not be a reason to reject a requirement. In this case, it is not a question of feasibility or core conflict, but just of some surmountable implementation difficulty -- a one time cost. This does not seem sufficient grounds to remove an important capability. as I suggested in the issue you could avoid cloning property sets by attaching them to an abstract Stereotype (which does not extend any metaclass). My apologies, but I cannot discern this part in your proposal; can you please point it out? If there is an alternative solution that fully satisfies the requirement and has advantages, I am all for it. I just don't want to lose the requirement. Note that, in general, there does not have to exist any kind of subclassing relationship between the metaclasses that may need to share a stereotype (and, I do not believe that stereotyping Element is a solution). Another disadvantage, as I also pointed out, is it becomes impractical to try and express constraints attached to such Stereotypes . since you have no predictability as to what metaclass (and properties thereon) you will be dealing with. This is the "it is difficult for implementors" argument, which I do not accept. Besides, you can always do a simple check in your OCL to determine which class you are dealing with. It doesn't look that hard to me. But regardless of whether they are a good idea, we need to manage the fact that existing profiles may make use of them. It would be I think be useful to try and quantify the extent of such usage, in terms of number of profiles and number of such stereotypes in each. We need to try and evaluate the real impact of the different options. I think quantifying this and figuring out what the results mean is a lot more complicated than doing the lesser bit of extra work to support the requirement. Note that figure 18.4 is a model for instances of the Stereotype so you would not expect to see ExtensionEnds etc. which are in the Profile itself not its instances: the diagram does in fact show a slot corresponding to the ExtensionEnd. Right. I noticed that after I sent the previous e-mail. Sorry for the red herring. And you do want instances of the Stereotype to be owned by the elements to which they are applied . so that if the element is deleted (e.g. a specific Component) then the applied stereotype instance is deleted, not floating around unattached. That is not expressed in Figure 18.2 (the wrong meta-level) but is expressed in 18.3.3 "The aggregation of an ExtensionEnd is always composite." Agreed. Cheers...Bran Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents X-KeepSent: 4DBE1D6D:6F47BAE9-8525755B:00812CAD; type=4; name=$KeepSent To: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Jim Amsden Date: Thu, 12 Feb 2009 18:34:14 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 02/12/2009 16:34:16 Cory, A couple of quick things: Extension is an Association, not Generalization, so redefinition is not defined for Stereotypes. It might be possible to use derived properties to simulate some kinds of redefinition, but that might not be supported by too many tools and isn't mentioned in the UML spec (that I know of). Well refactored models are a possibility, until the are used and extended by others that don't want the coupling that results from generalization. So we have the problem no matter what. "Cory Casanave" ---02/12/2009 05:21:09 PM---Pete, I would like to second Branâ..s position that this is a valuable feature and should be fully supported . implementation c From: "Cory Casanave" To: "Bran Selic" , "Pete Rivett - Adaptive" Cc: Date: 02/12/2009 05:21 PM Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents -------------------------------------------------------------------------------- Pete, I would like to second Branâ..s position that this is a valuable feature and should be fully supported . implementation considerations may impact how it is represented but not if it is represented. An RTF should not deleted valuable features in use. This feature is also used in SoaML. If fact it was somewhat of a problem when mapping from the SoaML profile to the meta model to find that limits in MOF prevented a clean mapping . so I see this as fundamentally a MOF issue. The waay the profile was expressed in SoaML matched our design intent . MOF didnâ..t. Semantically you shouldnâ..t havve two associations but one association that can be of either type (the union type). Either two 0..1 associations could be used with a constraint (your option a), or, you could have one 1..1 association with a type constraint. You could also use â..redefinesâ. to express these constraints. So, there is multiple ways to express it in the model. If our models were very well factored it is possible a super type would exist for all cases where we wanted a choice of the base . but this is UML. And the user canâ..t create new UML super types. As for ownership . we frequently want to have stereotyypes applied in a model other than the owning model. For example, for specializing technology details in a PSM level model. In this case the model elements being stereotypes may not be modifiable by the model that applies the stereotypes. In this case the applied elements should cascade delete when the model with the stereotypes is updated to the current imported model . most tools do this. SSo, the stereotyped element should not own the stereotype. -Cory (A View from the trenches) -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Thursday, February 12, 2009 12:13 AM To: Pete Rivett - Adaptive Cc: uml2-rtf@omg.org Subject: Re: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Hello Pete, Thanks for the quick response. Further comments below: On Wed, Feb 11, 2009 at 10:20 PM, Pete Rivett wrote: Hi Bran, I'm still not convinced (but still open to persuasion) of the usefulness of stereotypes applied to multiple metaclasses: Whether or not you are open to persuasion, this is a requirement for profiles, not only because current profiles use it, but also because it is a very useful feature. It is particularly useful in case of so-called viewpoint profiles, which are profiles that are overlaid on a UML model typically for purposes of analysis. For example, you may need to do a performance analysis on a UML model. In that case, you need to identify which parts of the model represent servers and which parts represent clients. The mapping of these specialized domain concepts to corresponding UML concepts is one to many, because the UML model may have been designed without any consideration given to the analysis concepts. (Once annotated in this way, it becomes possible to translate such a model automatically into an analysis-specific model, otherwise it is not possible in the general case.) Just because something is "tortuous-to-express" as you say should not be a reason to reject a requirement. In this case, it is not a question of feasibility or core conflict, but just of some surmountable implementation difficulty -- a one time cost. This does not seem sufficient grounds to remove an important capability. as I suggested in the issue you could avoid cloning property sets by attaching them to an abstract Stereotype (which does not extend any metaclass). My apologies, but I cannot discern this part in your proposal; can you please point it out? If there is an alternative solution that fully satisfies the requirement and has advantages, I am all for it. I just don't want to lose the requirement. Note that, in general, there does not have to exist any kind of subclassing relationship between the metaclasses that may need to share a stereotype (and, I do not believe that stereotyping Element is a solution). Another disadvantage, as I also pointed out, is it becomes impractical to try and express constraints attached to such Stereotypes . since you have no predictability as to whhat metaclass (and properties thereon) you will be dealing with. This is the "it is difficult for implementors" argument, which I do not accept. Besides, you can always do a simple check in your OCL to determine which class you are dealing with. It doesn't look that hard to me. But regardless of whether they are a good idea, we need to manage the fact that existing profiles may make use of them. It would be I think be useful to try and quantify the extent of such usage, in terms of number of profiles and number of such stereotypes in each. We need to try and evaluate the real impact of the different options. I think quantifying this and figuring out what the results mean is a lot more complicated than doing the lesser bit of extra work to support the requirement. Note that figure 18.4 is a model for instances of the Stereotype so you would not expect to see ExtensionEnds etc. which are in the Profile itself not its instances: the diagram does in fact show a slot corresponding to the ExtensionEnd. Right. I noticed that after I sent the previous e-mail. Sorry for the red herring. And you do want instances of the Stereotype to be owned by the elements to which they are applied . sso that if the element is deleted (e.g. a specific Component) then the applied stereotype instance is deleted, not floating around unattached. That is not expressed in Figure 18.2 (the wrong meta-level) but is expressed in 18.3.3 "The aggregation of an ExtensionEnd is always composite." Agreed. Cheers...Bran From: "DESFRAY Philippe" To: "'Pete Rivett'" , Cc: Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Fri, 13 Feb 2009 09:20:57 +0100 Organization: Softeam X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcmMs1GAnsDXYSRJSLG8WnbU3CWfWwA/qyGw X-Softeam.fr-MailScanner: Found to be clean X-Softeam.fr-MailScanner-SpamCheck: n'est pas un polluriel (inscrit sur la liste blanche), SpamAssassin (not cached, score=0.75, requis 3.5, AWL 0.64, BAYES_00 -2.60, HTML_MESSAGE 0.00, HTML_TAG_BALANCE_BODY 1.26, MSGID_MULTIPLE_AT 1.45) X-Softeam.fr-MailScanner-From: philippe.desfray@softeam.fr X-Spam-Status: No I do not remember exactly why this possibility for stereotypes to extend several metaclasses has been defined. I recall that there has been a strong push due to existing profiles, and cases where it would have been very cumbersome to individually extend several metaclasses. Probably profiles for performance and time. Does somebody have a recollection of this? I am in favor of A, since this feature very badly combines with generalization, and since by practice we do not know what to do with an instance of stereotype extending several metaclasses (when we handle a metamodel instance, we don.t have meaningful common behavior since the nature of the extended instance can be very variable). Note that this feature allows a stereotype definition to be able to extend several metaclasses. But for a given stereotype instance, only one metaclass is extended. (for example : <> can extend Class and Attribute. But a <> instance will be related either to a Class instance or (exclusive) to an Attribute instance.). Before moving to an option, we should investigate to know what are the .compelling. use cases that have resulted in this .multiple extension. feature. We should also be careful that there are namespacing issues: if I Create two stereotypes .persistent. one extending Class and the other Attribute, there is a name clash. And that will be a bit tricky for existing profiles. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.objecteering.com De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : jeudi 12 février 2009 02:44 À : issues@omg.org Cc : uml2-rtf@omg.org Objet : UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Importance : Haute (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 {required} 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) From: "DESFRAY Philippe" To: , "'Pete Rivett'" , Cc: Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Fri, 13 Feb 2009 09:32:24 +0100 Organization: Softeam X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcmMs1GAnsDXYSRJSLG8WnbU3CWfWwAZiWoAACcBjzA= X-Softeam.fr-MailScanner: Found to be clean X-Softeam.fr-MailScanner-SpamCheck: n'est pas un polluriel (inscrit sur la liste blanche), SpamAssassin (not cached, score=1.212, requis 3.5, AWL 0.16, BAYES_00 -2.60, MSGID_MULTIPLE_AT 1.45, URIBL_BLACK 1.96, URIBL_GREY 0.25, URIBL_RED 0.00) X-Softeam.fr-MailScanner-From: philippe.desfray@softeam.fr X-Spam-Status: No X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n1D8Z3d0009030 Exactly, that is what I have expressed in my previous mail (I shall read all the thread before responding!) ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.objecteering.com -----Message d'origine----- De : Conrad Bock [mailto:conrad.bock@nist.gov] Envoyé : jeudi 12 février 2009 14:56 À : 'Pete Rivett'; issues@omg.org Cc : uml2-rtf@omg.org Objet : RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, > 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). My understanding is a stereotype can have multiple base classes, but can only be applied to intances of one of those base classes at M1. Conrad From: Steve Cook To: Pete Rivett , Jim Amsden , "uml2-rtf@omg.org" Date: Fri, 13 Feb 2009 09:48:04 +0000 Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmNKZ57GthzEDpWQQWBxxRMS9djUwABBpEgACRjdZA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Pete You say in your original post that option B requires a change to the XMI serialization of all existing profiles, but many people on this thread are insisting that many existing profiles contain stereotypes that apply to multiple metaclasses. If so, presumably they are serialized in XMI somehow . Jim suggests that they are. If so, maybe the change to XMI is not as damaging as you imply? I don.t know the details, and I.d much appreciate an example of how existing XMI would be damaged by option B. The option-B constraint (exactly one applies) has always been something of an omission in UML (it used to be called XOR). -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 February 2009 16:23 To: Jim Amsden; uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Ø That would imply that Home has two properties base_Interface and base_Foo that would need to have multiplicity 0..1 with a constraint that for any instance of Home, one of them must be non-null. Would that work? That is my option B). Which has the impacts I identify in the issue. And it also has variants C) and D) . for example we could retain the multiplicity as 1..1 if we know that only one metaclass is extended. That minimizes the impact on existing profiles whose stereotypes don.t extend multiple metaclasses. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 12 February 2009 07:49 To: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, I also agree that this is the intention, and is currently supported by RSM. I don't know exactly what is done about the base_X constraint in the XML - likely its ignored. When I get a chance I'll create a simple example and see what the XMI looks like. Re: figure 18.4, consider stereotype Home as extending Interface or Class. I interpret figure 18.4 as indicating an instance of stereotype Home applied to an instance of metaclass Interface must be connected by base_Interface. But another instance of stereotype Home could be applied to class Foo and would related by base_Foo. That would imply that Home has two properties base_Interface and base_Foo that would need to have multiplicity 0..1 with a constraint that for any instance of Home, one of them must be non-null. Would that work? I also agree with Bran that it is necessary for a stereotype to extend more than one metaclass. SoaML uses this: ServiceInterface can extend Class or Interface. From: "Pete Rivett" To: Cc: Date: 02/12/2009 10:28 AM Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents -------------------------------------------------------------------------------- That I believe is the intention, Conrad. But the effective metamodel in 18.4 (and the XMI) states that ALL the base_X properties are mandatory. Applying a stereotype instance to only one base class instance will leave one or more base_X[1..1 ] properties empty. Pete -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: 12 February 2009 05:56 To: Pete Rivett; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, > 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). My understanding is a stereotype can have multiple base classes, but can only be applied to intances of one of those base classes at M1. Conrad Date: Fri, 13 Feb 2009 05:14:39 -0500 From: "Chonoles, Michael J" Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents To: uml2-rtf@omg.org Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmNKZ57GthzEDpWQQWBxxRMS9djUwABBpEgACRjdZAAASAmgA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 13 Feb 2009 10:22:41.0679 (UTC) FILETIME=[00B649F0:01C98DC5] Yes, .B. seems to be necessary to keep profiles, such as SysML, working. Michael LMCO From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, February 13, 2009 4:48 AM To: Pete Rivett; Jim Amsden; uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete You say in your original post that option B requires a change to the XMI serialization of all existing profiles, but many people on this thread are insisting that many existing profiles contain stereotypes that apply to multiple metaclasses. If so, presumably they are serialized in XMI somehow . Jim suggests that they are. If so, maybe the change to XMI is not as damaging as you imply? I don.t know the details, and I.d much appreciate an example of how existing XMI would be damaged by option B. The option-B constraint (exactly one applies) has always been something of an omission in UML (it used to be called XOR). -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 February 2009 16:23 To: Jim Amsden; uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Ø That would imply that Home has two properties base_Interface and base_Foo that would need to have multiplicity 0..1 with a constraint that for any instance of Home, one of them must be non-null. Would that work? That is my option B). Which has the impacts I identify in the issue. And it also has variants C) and D) . for example we could retain the multiplicity as 1..1 if we know that only one metaclass is extended. That minimizes the impact on existing profiles whose stereotypes don.t extend multiple metaclasses. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 12 February 2009 07:49 To: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, I also agree that this is the intention, and is currently supported by RSM. I don't know exactly what is done about the base_X constraint in the XML - likely its ignored. When I get a chance I'll create a simple example and see what the XMI looks like. Re: figure 18.4, consider stereotype Home as extending Interface or Class. I interpret figure 18.4 as indicating an instance of stereotype Home applied to an instance of metaclass Interface must be connected by base_Interface. But another instance of stereotype Home could be applied to class Foo and would related by base_Foo. That would imply that Home has two properties base_Interface and base_Foo that would need to have multiplicity 0..1 with a constraint that for any instance of Home, one of them must be non-null. Would that work? I also agree with Bran that it is necessary for a stereotype to extend more than one metaclass. SoaML uses this: ServiceInterface can extend Class or Interface. From: "Pete Rivett" To: Cc: Date: 02/12/2009 10:28 AM Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents -------------------------------------------------------------------------------- That I believe is the intention, Conrad. But the effective metamodel in 18.4 (and the XMI) states that ALL the base_X properties are mandatory. Applying a stereotype instance to only one base class instance will leave one or more base_X[1..1 ] properties empty. Pete -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: 12 February 2009 05:56 To: Pete Rivett; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, > 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). My understanding is a stereotype can have multiple base classes, but can only be applied to intances of one of those base classes at M1. Conrad Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Fri, 13 Feb 2009 10:16:49 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmM0L7r4Wu9JzoDSqa5Ni1rTzheAAAjO7iQABlf9KA= From: "Hains, Ralph" To: "Cory Casanave" , "Bran Selic" , "Pete Rivett - Adaptive" Cc: HI All, I would like to third Cory and Bran, both the fact that this is a valuable feature and that deleting it is beyond the remit of the rtf. To clarify, for myself as much as anyone else (as this thread is getting convoluted): Stereotypes can be defined as capable of applying to more than one metatype, without having to inherit them. This situation should not be changed by the rtf, it is useful and used in many profiles including those that are standards. A given stereotype application (resulting in an instance) can only be to a single instance of a metatype (aka model element). Not two (and not zero either) If this means that a multiplicity in the metamodel that is currently .1. requires changing to .0..1. plus constraint (that exactly one of the resulting set of 0..1s be used in each given situation) then so be it. If this in turn results in some hard serialization changes we should consider whether the chase is worth the candle. But what we should not do is inconvenience end users by removing an intended feature they have used and appreciate. Aside: I do not consider the argument that this feature has been abused (which it has) as well as used sensibly (also has) to be a reason to get rid of it. That way most or all of the UML would go with it! Ralph From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 12 February 2009 22:18 To: Bran Selic; Pete Rivett - Adaptive Cc: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, I would like to second Bran.s position that this is a valuable feature and should be fully supported . implementation considerations may impact how it is represented but not if it is represented. An RTF should not deleted valuable features in use. This feature is also used in SoaML. If fact it was somewhat of a problem when mapping from the SoaML profile to the meta model to find that limits in MOF prevented a clean mapping . so I see this as fundamentally a MOF issue. The way the profile was expressed in SoaML matched our design intent . MOF didn.t. Semantically you shouldn.t have two associations but one association that can be of either type (the union type). Either two 0..1 associations could be used with a constraint (your option a), or, you could have one 1..1 association with a type constraint. You could also use .redefines. to express these constraints. So, there is multiple ways to express it in the model. If our models were very well factored it is possible a super type would exist for all cases where we wanted a choice of the base . but this is UML. And the user can.t create new UML super types. As for ownership . we frequently want to have stereotypes applied in a model other than the owning model. For example, for specializing technology details in a PSM level model. In this case the model elements being stereotypes may not be modifiable by the model that applies the stereotypes. In this case the applied elements should cascade delete when the model with the stereotypes is updated to the current imported model . most tools do this. So, the stereotyped element should not own the stereotype. -Cory (A View from the trenches) -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Thursday, February 12, 2009 12:13 AM To: Pete Rivett - Adaptive Cc: uml2-rtf@omg.org Subject: Re: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Hello Pete, Thanks for the quick response. Further comments below: On Wed, Feb 11, 2009 at 10:20 PM, Pete Rivett wrote: Hi Bran, I'm still not convinced (but still open to persuasion) of the usefulness of stereotypes applied to multiple metaclasses: Whether or not you are open to persuasion, this is a requirement for profiles, not only because current profiles use it, but also because it is a very useful feature. It is particularly useful in case of so-called viewpoint profiles, which are profiles that are overlaid on a UML model typically for purposes of analysis. For example, you may need to do a performance analysis on a UML model. In that case, you need to identify which parts of the model represent servers and which parts represent clients. The mapping of these specialized domain concepts to corresponding UML concepts is one to many, because the UML model may have been designed without any consideration given to the analysis concepts. (Once annotated in this way, it becomes possible to translate such a model automatically into an analysis-specific model, otherwise it is not possible in the general case.) Just because something is "tortuous-to-express" as you say should not be a reason to reject a requirement. In this case, it is not a question of feasibility or core conflict, but just of some surmountable implementation difficulty -- a one time cost. This does not seem sufficient grounds to remove an important capability. as I suggested in the issue you could avoid cloning property sets by attaching them to an abstract Stereotype (which does not extend any metaclass). My apologies, but I cannot discern this part in your proposal; can you please point it out? If there is an alternative solution that fully satisfies the requirement and has advantages, I am all for it. I just don't want to lose the requirement. Note that, in general, there does not have to exist any kind of subclassing relationship between the metaclasses that may need to share a stereotype (and, I do not believe that stereotyping Element is a solution). Another disadvantage, as I also pointed out, is it becomes impractical to try and express constraints attached to such Stereotypes . since you have no predictability as to what metaclass (and properties thereon) you will be dealing with. This is the "it is difficult for implementors" argument, which I do not accept. Besides, you can always do a simple check in your OCL to determine which class you are dealing with. It doesn't look that hard to me. But regardless of whether they are a good idea, we need to manage the fact that existing profiles may make use of them. It would be I think be useful to try and quantify the extent of such usage, in terms of number of profiles and number of such stereotypes in each. We need to try and evaluate the real impact of the different options. I think quantifying this and figuring out what the results mean is a lot more complicated than doing the lesser bit of extra work to support the requirement. Note that figure 18.4 is a model for instances of the Stereotype so you would not expect to see ExtensionEnds etc. which are in the Profile itself not its instances: the diagram does in fact show a slot corresponding to the ExtensionEnd. Right. I noticed that after I sent the previous e-mail. Sorry for the red herring. And you do want instances of the Stereotype to be owned by the elements to which they are applied . so that if the element is deleted (e.g. a specific Component) then the applied stereotype instance is deleted, not floating around unattached. That is not expressed in Figure 18.2 (the wrong meta-level) but is expressed in 18.3.3 "The aggregation of an ExtensionEnd is always composite." Agreed. Cheers...Bran Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Fri, 13 Feb 2009 06:35:50 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmNKZ57GthzEDpWQQWBxxRMS9djUwABBpEgACRjdZAAB/umIA== From: "Pete Rivett" To: "Steve Cook" , "Jim Amsden" , The way I believe they are serialized now results in the equivalent of an ill-formed metamodel (multiple 1..1 composite owner properties) and hence invalid instance models (for any instance of such a Stereotype all but one of its mandatory 1..1 properties will be unset). The change to the XMI for option B is, as I state, in the Profiles themselves not to the models to which they are applied. And it is to reflect the fact that the base_X property becomes 0..1 rather than 1..1. One would also expect that there is something in the Profile definition to reflect the constraint, however we express it, that exactly one of the base_X properties (inherited and direct) on the Stereotype can be non-empty. When this constraint is explicitly needed depends to some extent on the option B, C, D chosen. Xor could possibly be used for the .exactly one. constraint but it.s unclear how it would be made use of for inherited base_X properties. In fact a lot about xor is unclear, including how any use of it would be represented in XMI . see PS below. In 18.3.6 the example XMI that currently reads: Would need a lowerValue and an ownedRule . which would in turn need some expression: Similarly for the XSD we.d need to change the following in the ComplexType .Home.: The element: Becomes The attribute To: Cc: Date: 02/12/2009 10:28 AM Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents -------------------------------------------------------------------------------- That I believe is the intention, Conrad. But the effective metamodel in 18.4 (and the XMI) states that ALL the base_X properties are mandatory. Applying a stereotype instance to only one base class instance will leave one or more base_X[1..1 ] properties empty. Pete -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: 12 February 2009 05:56 To: Pete Rivett; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, > 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). My understanding is a stereotype can have multiple base classes, but can only be applied to intances of one of those base classes at M1. Conrad Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Fri, 13 Feb 2009 06:49:38 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmMs1GAnsDXYSRJSLG8WnbU3CWfWwA/qyGwAA3dk2A= From: "Pete Rivett" To: "DESFRAY Philippe" , Cc: Hi Philippe, The rest of your email and its follow-up tell me that I don.t think you are really in favor of Option A which prevents a stereotype definition extending multiple metaclasses. In that case Figure 18.16 would no longer be valid. No one seems to really want this option, including myself (due to me not wanting to invalidate existing profiles), but I mentioned it in the issue for completeness. All the options restrict a stereotype instance from being applied to more than one metaclass instance. That is fundamental as your email states. Pete From: DESFRAY Philippe [mailto:philippe.desfray@softeam.fr] Sent: 13 February 2009 00:21 To: Pete Rivett; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents I do not remember exactly why this possibility for stereotypes to extend several metaclasses has been defined. I recall that there has been a strong push due to existing profiles, and cases where it would have been very cumbersome to individually extend several metaclasses. Probably profiles for performance and time. Does somebody have a recollection of this? I am in favor of A, since this feature very badly combines with generalization, and since by practice we do not know what to do with an instance of stereotype extending several metaclasses (when we handle a metamodel instance, we don.t have meaningful common behavior since the nature of the extended instance can be very variable). Note that this feature allows a stereotype definition to be able to extend several metaclasses. But for a given stereotype instance, only one metaclass is extended. (for example : <> can extend Class and Attribute. But a <> instance will be related either to a Class instance or (exclusive) to an Attribute instance.). Before moving to an option, we should investigate to know what are the .compelling. use cases that have resulted in this .multiple extension. feature. We should also be careful that there are namespacing issues: if I Create two stereotypes .persistent. one extending Class and the other Attribute, there is a name clash. And that will be a bit tricky for existing profiles. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.objecteering.com De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : jeudi 12 février 2009 02:44 À : issues@omg.org Cc : uml2-rtf@omg.org Objet : UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Importance : Haute (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 {required} 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) Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Fri, 13 Feb 2009 19:02:36 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmNKZ57GthzEDpWQQWBxxRMS9djUwABBpEgACRjdZAABIXWMA== From: "GERARD Sebastien 166342" To: "Steve Cook" , "Pete Rivett" , "Jim Amsden" , X-OriginalArrivalTime: 13 Feb 2009 18:02:36.0894 (UTC) FILETIME=[40BDEFE0:01C98E05] All, So, finishing to read carefully ( I hope so) this thread, first it is not clear to me what is the issue: is the issue related to the fact that it is useful (yes, it is, and we did it intensively in MARTE to extend several meta-classes with a same stereotype; or if the issue is on the impossibility for an instance of a stereotype to extend several M1 elements in the same time. I understand Pete focus mainly on the first issue but other seems to say there is no pb! Philippe seems to say also issue 1 is not an issue, but confirm the second case is not possible. So, who is able to clarify before making a choice for the possible propositions sent by Pete? BTW, to my experience coming from Papyrus (we use here the UML2 project of Eclipse), it is possible to extend different metaclasses with a same stereotype, but it is not possible to apply a same stereotype to different M1 elements conformed to the M2 elements extended by the stereotype definition. Moreover, I do think we need to be able to extend several meta-classes with a same stereotype. In addition, I do think that being applied several time the same instance of stereotype to several M1 element could be very interesting. Let's consider a stereotype <> (extending for example Element) with a property number: Integer [0..1]. If such feature would be possible, I would be able to apply the same instance of <> with of course the same number of version to a set of M1 element. Finally, I also like the proposition E sent by Nicalas (Nobody has reacted on it by now.), because, correct if I am wrong Nicolas, but I think it provides us a very interesting feature that is to say the ability to apply several time the same profile on a same model. This feature would be very useful as for example for analysis purpose or code generation. Let's consider for example you define a profile containing stereotype for C++, you could apply your profile differently on the same model depending on some condition. For example in one case, you want to say that some of the operations of the classes has to be considered as inline and for other case it has not be. So you would have two merged profiled merged model (coming from the same model) that target both cases. Finally finally, about xmi, if I also understand what is the current situation, tools make some specific choices (I believe not the same?) to overcome the issue. So if the proposed resolution contain some xmi changes that enable to fix the issue, it would improve model exchange! So in this case, change is good Sébastien. -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : vendredi 13 février 2009 10:48 À : Pete Rivett; Jim Amsden; uml2-rtf@omg.org Objet : RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete You say in your original post that option B requires a change to the XMI serialization of all existing profiles, but many people on this thread are insisting that many existing profiles contain stereotypes that apply to multiple metaclasses. If so, presumably they are serialized in XMI somehow . Jim suggests that they are. If so, maybe the change to XMI is not as damaging as you imply? I don.t know the details, and I.d much appreciate an example of how existing XMI would be damaged by option B. The option-B constraint (exactly one applies) has always been something of an omission in UML (it used to be called XOR). -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 12 February 2009 16:23 To: Jim Amsden; uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Ø That would imply that Home has two properties base_Interface and base_Foo that would need to have multiplicity 0..1 with a constraint that for any instance of Home, one of them must be non-null. Would that work? That is my option B). Which has the impacts I identify in the issue. And it also has variants C) and D) . for example we could retain the multiplicity as 1..1 if we know that only one metaclass is extended. That minimizes the impact on existing profiles whose stereotypes don.t extend multiple metaclasses. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 12 February 2009 07:49 To: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, I also agree that this is the intention, and is currently supported by RSM. I don't know exactly what is done about the base_X constraint in the XML - likely its ignored. When I get a chance I'll create a simple example and see what the XMI looks like. Re: figure 18.4, consider stereotype Home as extending Interface or Class. I interpret figure 18.4 as indicating an instance of stereotype Home applied to an instance of metaclass Interface must be connected by base_Interface. But another instance of stereotype Home could be applied to class Foo and would related by base_Foo. That would imply that Home has two properties base_Interface and base_Foo that would need to have multiplicity 0..1 with a constraint that for any instance of Home, one of them must be non-null. Would that work? I also agree with Bran that it is necessary for a stereotype to extend more than one metaclass. SoaML uses this: ServiceInterface can extend Class or Interface. From: "Pete Rivett" To: Cc: Date: 02/12/2009 10:28 AM Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents -------------------------------------------------------------------------------- That I believe is the intention, Conrad. But the effective metamodel in 18.4 (and the XMI) states that ALL the base_X properties are mandatory. Applying a stereotype instance to only one base class instance will leave one or more base_X[1..1 ] properties empty. Pete -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: 12 February 2009 05:56 To: Pete Rivett; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Pete, > 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). My understanding is a stereotype can have multiple base classes, but can only be applied to intances of one of those base classes at M1. Conrad Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Tue, 17 Feb 2009 11:24:18 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmMs1GAnsDXYSRJSLG8WnbU3CWfWwA/qyGwAA3dk2AAzDUoUA== From: "Pete Rivett" To: Cc: The consensus from the UML RTF call today was to go for Option B) but without any explicit constraint in the serialized Profile (it will just be in the specification text). Should we find a means to serialize {xor} then we can raise a further issue to use it for such a constraint (though it will still be complex since it would need to involve inherited base_X properties). This is not official pending a formal ballot. Pete De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : jeudi 12 février 2009 02:44 À : issues@omg.org Cc : uml2-rtf@omg.org Objet : UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Importance : Haute (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 {required} 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) Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Date: Tue, 17 Feb 2009 22:40:12 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Thread-Index: AcmMs1GAnsDXYSRJSLG8WnbU3CWfWwA/qyGwAA3dk2AAzDUoUAANi8IQ From: "Hains, Ralph" To: "Pete Rivett" , Cc: I missed the UML RTF call (sorry, I was on holiday) but I also concur with B (unofficially as yet, of course) From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 17 February 2009 19:24 To: uml2-rtf@omg.org Cc: updm-rfc-ftf@omg.org Subject: RE: UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents The consensus from the UML RTF call today was to go for Option B) but without any explicit constraint in the serialized Profile (it will just be in the specification text). Should we find a means to serialize {xor} then we can raise a further issue to use it for such a constraint (though it will still be complex since it would need to involve inherited base_X properties). This is not official pending a formal ballot. Pete De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : jeudi 12 février 2009 02:44 À : issues@omg.org Cc : uml2-rtf@omg.org Objet : UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents Importance : Haute (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 {required} 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) From: "Wendland, Marc-Florian" To: "uml25-ftf@omg.org" Subject: Draft resolution 13482 Thread-Topic: Draft resolution 13482 Thread-Index: Ac6EwW0kBuItZjorTQWBGpVXIXjgNw== Date: Fri, 19 Jul 2013 21:00:34 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [195.37.77.169] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml25-ftf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate04-dus with 17A363880009 X-cloud-security-connect: pluto.fokus.fraunhofer.de[195.37.77.164], TLS=, IP=195.37.77.164 X-cloud-security: scantime:.1544 X-Virus-Scanned: amavisd-new at omg.org Hi all, I checked in a draft resolution for ballot 8 for issue #13482, i.e., single and multiple metaclass extension by stereotypes. In included the fundamental things we discussed in the mails according to this issue. I did not include (as announce in a previous mail) any XMI-related resolution, this issue is actually asking for. Someone who has a greater expertise in XMI should tackle the XMI-related issues. Furthermore, I did not include the explanation of the different patterns Nicolas suggested. I actually do not see the necessity to make these pattern explicit in the specification. If you guys thinks it is necessary to put such patterns into the spec, please change the resolution accordingly. I will not be available (vacations) for the next two weeks. I would like to pass the draft resolution to Nicolas, since he was most involved in the discussion few weeks ago. He is also most predestined to integrate the pattern definitions, if required. Nicolas, will you take over the responsibility for resolution to #13482 from now on, please? Regards, Marc-Florian From: "Rouquette, Nicolas F (313K)" To: "Wendland, Marc-Florian" , "uml25-ftf@omg.org" Subject: Re: Draft resolution 13482 Thread-Topic: Draft resolution 13482 Thread-Index: Ac6EwW0kBuItZjorTQWBGpVXIXjgNwAB35gA Date: Fri, 19 Jul 2013 21:42:53 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Marc-Florian, Thanks for drafting this resolution. I read it and I'm OK in taking over responsibility. - Nicolas. From: , Marc-Florian Date: Friday, July 19, 2013 2:00 PM To: "uml25-ftf@omg.org" Subject: Draft resolution 13482 Hi all, I checked in a draft resolution for ballot 8 for issue #13482, i.e., single and multiple metaclass extension by stereotypes. In included the fundamental things we discussed in the mails according to this issue. I did not include (as announce in a previous mail) any XMI-related resolution, this issue is actually asking for. Someone who has a greater expertise in XMI should tackle the XMI-related issues. Furthermore, I did not include the explanation of the different patterns Nicolas suggested. I actually do not see the necessity to make these pattern explicit in the specification. If you guys thinks it is necessary to put such patterns into the spec, please change the resolution accordingly. I will not be available (vacations) for the next two weeks. I would like to pass the draft resolution to Nicolas, since he was most involved in the discussion few weeks ago. He is also most predestined to integrate the pattern definitions, if required. Nicolas, will you take over the responsibility for resolution to #13482 from now on, please? Regards, Marc-Florian