Issue 15001: Incomplete resolution to 10826 (uml2-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: Issue 10826 was asking for two things: what is an applied stereotype, as opposed to the definition of the stereotype that was applied what are tag/value pairs, as opposed to the definition of the stereotype properties that led to the tag/value pairs The resolution for 10826 added the following paragraph: An instance “S” of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather than generalization/specialization. Relating it to a metaclass “C” from the reference metamodel (typically UML) using an “Extension” (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of “S” (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of “S” are related to “C” model elements (instances of “C”) by links (occurrences of the association/extension from “S’ to “C”). Up to the last sentence, the paragraph refers to ‘an instance “S” of Stereotype’ -- i.e., the definition of “S”, a stereotype, in a profile — as illustrated in figure 18.13. The last sentence is relevant to question (1) of 10826; however, the resolution doesn’t actually answer the question — i.e., it doesn’t explain what ‘an instance of “S”’ actually is. >From Figure 18.18, the notation suggests that ‘an instance of “S”’ is some kind of instance specification but the resolution doesn’t actually say so and doesn’t address question (2) of 10826 either. I propose then to file a new issue about this and include Ed’s suggestion below as well as clarifying that in Figure 18.18, ‘an instance of “S”’ is actually an instance specification whose classifier happens to be ‘an instance “S” of Stereotype’, i.e., the definition of “S”, a kind of Class since Stereotype extends Class. Resolution: Revised Text: Actions taken: December 17, 2009: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (316A)" To: Steve Cook , Jim Amsden , "uml2-rtf@omg.org" Date: Thu, 17 Dec 2009 07:32:44 -0800 Subject: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Topic: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Index: AQHKfbWJtDoDYPXOrkurwJya5w/oQpFngCZQgAChDzqAAONOUIAAXGzK Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Steve, Issue 10826 was asking for two things: what is an applied stereotype, as opposed to the definition of the stereotype that was applied what are tag/value pairs, as opposed to the definition of the stereotype properties that led to the tag/value pairs The resolution for 10826 added the following paragraph: An instance .S. of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather than generalization/specialization. Relating it to a metaclass .C. from the reference metamodel (typically UML) using an .Extension. (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of .S. (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of .S. are related to .C. model elements (instances of .C.) by links (occurrences of the association/extension from .S. to .C.). Up to the last sentence, the paragraph refers to .an instance .S. of Stereotype. -- i.e., the definition of .S., a stereotype, in a profile . as illustrated in figure 18.13. The last sentence is relevant to question (1) of 10826; however, the resolution doesn.t actually answer the question . i.e., it doesn.t explain what .an instance of .S.. actually is. >From Figure 18.18, the notation suggests that .an instance of .S.. is some kind of instance specification but the resolution doesn.t actually say so and doesn.t address question (2) of 10826 either. I propose then to file a new issue about this and include Ed.s suggestion below as well as clarifying that in Figure 18.18, .an instance of .S.. is actually an instance specification whose classifier happens to be .an instance .S. of Stereotype., i.e., the definition of .S., a kind of Class since Stereotype extends Class. - Nicolas. On 12/17/09 2:11 AM, "Steve Cook" wrote: Nic 10826 was resolved in Ballot 6 of 2.3. Please check. Regarding circular generalization: isn.t this a MOF thing? Shouldn.t this actually go into SMOF, whose purpose is better alignment between MOF and semantic web constructs? Thanks -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 16 December 2009 20:28 To: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Guiding principles for choosing UML 2.4 Issues What about the leftovers of the UML 2.3 RTF? Two leftovers are particularly important for other OMG specifications that depend on the UML spec: SysML and related efforts including the SysML/QUDV and SysML/Modelica integration. The two leftovers are: applied stereotypes (we had a discussion in issue 13291 but there is an issue filed, 10826 about this that isn.t in the UML 2.4 spreadsheet) navigation up/down classifier hierarchies About (1) -- Applied stereotypes. I didn.t find 10826 in the UML 2.4 spreadsheet: http://www.omg.org/issues/uml2-rtf.html#Issue10826 This issue is about the lack of a normative abstract syntax for accessing the stereotypes that are applied to an element: Issue 13291 was eventually withdrawn; however, before the discussion digressed to other topics, Ed provided a concise suggestion summarizing a discussion between Dave H., Ed S., Jim A. and myself (01/20/2009): Moreover, it seems to me that the whole point of pointing stereotypes specifically to UML metaclasses in UML 2 was so that such stereotypes were based of the standard UML metamodel. For this to have any real force in terms of repository representation and interchange, then the metaclasses referenced should be those with normative IDs in the normative CMOF representation of the metamodel. Such standard IDs are lost if each tool is, instead, pointing to its own (non-normative) representation of the metamodel as a UML L3 model. If stereotypes are not going to point to the normative CMOF metaclasses, then one might as well simplify the stereotype abstract syntax to just reference the extended the metaclasses by name, as was done in UML 1. -- Ed I propose to develop a resolution for 10826 and include Ed.s suggestion above, i.e., reference the extended metaclass by its normative URI. About (2) -- Navigation up/down classifier hierarchies. The UML 2.3 RTF report includes the following in the resolution text of 9374: This resolution includes an OCL constraint which depends on the OCL 2.1 revision: context AssociationClass self.A_general_classifier::classifier ->forAll(oclIsKindOf(AssociationClass)) The meaning of this constraint is as follows: self.A_general_classifier::classifier This expression navigates the association A_general_classifier in the inverse direction of the navigability of the property /Classifier::general : Classifier[*]. That is, it provides the set of classifiers that specialize .self.. This OCL constraint was editorially removed on the basis that UML 2.3 was aligned to OCL 2.0, not 2.1. Since then, OCL 2.1 is available; the constraint could be reinstated in principle. However, Maged had suggested instead renaming the association: A_general_classifier on Classifier to A_general_specific. Classifer would have, symmetrically, two derived properties for accessing its general and specific classifiers. Besides the two leftovers above, there is a third issue: (3) - Relaxing generalization relationships to allow circularities In OWL/OWL2, generalization relationships among classes can be circular . the semantics here are that all classes in the strongly connected graph of generalization relationships are semantically equivalent. All CMOF-based metamodels can.t have circular generalization relationships. In UML infrastructure, Core::Constructs::Classifier includes a constraint that the generalization relationships that a classifier is involved in must be acyclic. I propose to remove this constraint and replace it with a query: context Classifier::hasCircularGeneralization() : Boolean body: = self.general->includes(self) It is out of scope of the UML to say whether generalizations should be acyclic but it is something that could be enforced as an invariant specified in a profile (e.g., for OO languages with a strict type hierarchy). - Nicolas. On 12/16/09 2:55 AM, "Steve Cook" wrote: Jim I think this is useful for helping to establish the scope for 2.4. In my mind, in 2.4 we should avoid dealing with issues that can be dealt with better during simplification (your category 3) and issues that can be dealt with more easily after simplification (such as refactoring). I don.t think there is any need to avoid fixing OCL in 2.4 in cases where we find it to be in error. Thanks -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 15 December 2009 18:34 To: uml2-rtf@omg.org Subject: Guiding principles for choosing UML 2.4 Issues We increased the time window for the UML 2.4 RTF, but its still short. As you know, IBM's desire was to limit the number of additional releases on the 2.x stream as these are expensive, have limited value for our customers, and could delay efforts to significantly cleanup, simplify, and provide better extensibility and integration mechanisms for UML. In order to limit releases on the 2.x stream, we have to address issues that would motivate them. Ideally the 2.4 RTF would address these issues providing a usable, stable platform for UML modeling and model interchange. Then the UML 2.5 specification simplification submission could provide a better description of that that modeling language is. Taken together, these two releases could provide a longer-lived modeling platform that could give us the time we need to develop the next generation of UML that would hopefully address the issues and opportunities we identified in the UML Futures RFI responses. Maybe we can't achieve this with UML 2.4 and 2.5, and may need to do 2.6 and beyond to address specific needs. But it may be useful to try. The UML 2.4 (or possibly any) RTF is too short to address all the issues, so we may need some guiding principles to help decide which issues are critical to achieving a stable UML 2.5 platform, and therefore which ones will be included in 2.4. Here's a possible starter set for discussion: Include any issue that prevents creation of the merged metamodel or XMI interchange Include any show-stopper issues that are preventing the successful use of UML for common use cases, including some of the key issues raised by the RFI responses Avoid simple editorial changes and clarifications that could be handled by the UML 2.5 specification cleanup submission Avoid cleanup, refactoring, removal of unintended inheritance, OCL cleanup or addition of missing constraints, etc. that although useful, are not critical inhibitors for UML implementation or use, and may be easier to handle more effectively in a less constrained release. Do you think this is useful, a good starting point? Any other suggestions? Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Steve Cook To: "Rouquette, Nicolas F (316A)" , "Jim Amsden" , "uml2-rtf@omg.org" Subject: RE: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Topic: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Index: AQHKfy5DXRV1+v3xcUO9hitzsNQVAZFvu4rA Date: Mon, 21 Dec 2009 16:51:00 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Nicolas You wrote: >I propose then to file a new issue about this and include Ed.s suggestion below as well as clarifying that in Figure 18.18, .an instance of .S.. is actually an instance specification whose classifier happens to be .an instance .S. of Stereotype., i.e., the definition of .S., a kind of Class since Stereotype extends Class. Sounds good to me! I do remember however that when I suggested some time ago that stereotype instances are in fact instances of InstanceSpecification, I got quite a lot pushback. I don.t know what else they might be, though. It does mean that we.ll have two ways of serializing InstanceSpecifications though: the .normal. way and the stereotype way. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 17 December 2009 15:33 To: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Steve, Issue 10826 was asking for two things: what is an applied stereotype, as opposed to the definition of the stereotype that was applied what are tag/value pairs, as opposed to the definition of the stereotype properties that led to the tag/value pairs The resolution for 10826 added the following paragraph: An instance .S. of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather than generalization/specialization. Relating it to a metaclass .C. from the reference metamodel (typically UML) using an .Extension. (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of .S. (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of .S. are related to .C. model elements (instances of .C.) by links (occurrences of the association/extension from .S. to .C.). Up to the last sentence, the paragraph refers to .an instance .S. of Stereotype. -- i.e., the definition of .S., a stereotype, in a profile . as illustrated in figure 18.13. The last sentence is relevant to question (1) of 10826; however, the resolution doesn.t actually answer the question . i.e., it doesn.t explain what .an instance of .S.. actually is. From Figure 18.18, the notation suggests that .an instance of .S.. is some kind of instance specification but the resolution doesn.t actually say so and doesn.t address question (2) of 10826 either. I propose then to file a new issue about this and include Ed.s suggestion below as well as clarifying that in Figure 18.18, .an instance of .S.. is actually an instance specification whose classifier happens to be .an instance .S. of Stereotype., i.e., the definition of .S., a kind of Class since Stereotype extends Class. - Nicolas. On 12/17/09 2:11 AM, "Steve Cook" wrote: Nic 10826 was resolved in Ballot 6 of 2.3. Please check. Regarding circular generalization: isn.t this a MOF thing? Shouldn.t this actually go into SMOF, whose purpose is better alignment between MOF and semantic web constructs? Thanks -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 16 December 2009 20:28 To: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Guiding principles for choosing UML 2.4 Issues What about the leftovers of the UML 2.3 RTF? Two leftovers are particularly important for other OMG specifications that depend on the UML spec: SysML and related efforts including the SysML/QUDV and SysML/Modelica integration. The two leftovers are: applied stereotypes (we had a discussion in issue 13291 but there is an issue filed, 10826 about this that isn.t in the UML 2.4 spreadsheet) navigation up/down classifier hierarchies About (1) -- Applied stereotypes. I didn.t find 10826 in the UML 2.4 spreadsheet: http://www.omg.org/issues/uml2-rtf.html#Issue10826 This issue is about the lack of a normative abstract syntax for accessing the stereotypes that are applied to an element: Issue 13291 was eventually withdrawn; however, before the discussion digressed to other topics, Ed provided a concise suggestion summarizing a discussion between Dave H., Ed S., Jim A. and myself (01/20/2009): Moreover, it seems to me that the whole point of pointing stereotypes specifically to UML metaclasses in UML 2 was so that such stereotypes were based of the standard UML metamodel. For this to have any real force in terms of repository representation and interchange, then the metaclasses referenced should be those with normative IDs in the normative CMOF representation of the metamodel. Such standard IDs are lost if each tool is, instead, pointing to its own (non-normative) representation of the metamodel as a UML L3 model. If stereotypes are not going to point to the normative CMOF metaclasses, then one might as well simplify the stereotype abstract syntax to just reference the extended the metaclasses by name, as was done in UML 1. -- Ed I propose to develop a resolution for 10826 and include Ed.s suggestion above, i.e., reference the extended metaclass by its normative URI. About (2) -- Navigation up/down classifier hierarchies. The UML 2.3 RTF report includes the following in the resolution text of 9374: This resolution includes an OCL constraint which depends on the OCL 2.1 revision: context AssociationClass self.A_general_classifier::classifier ->forAll(oclIsKindOf(AssociationClass)) The meaning of this constraint is as follows: self.A_general_classifier::classifier This expression navigates the association A_general_classifier in the inverse direction of the navigability of the property /Classifier::general : Classifier[*]. That is, it provides the set of classifiers that specialize .self.. This OCL constraint was editorially removed on the basis that UML 2.3 was aligned to OCL 2.0, not 2.1. Since then, OCL 2.1 is available; the constraint could be reinstated in principle. However, Maged had suggested instead renaming the association: A_general_classifier on Classifier to A_general_specific. Classifer would have, symmetrically, two derived properties for accessing its general and specific classifiers. Besides the two leftovers above, there is a third issue: (3) - Relaxing generalization relationships to allow circularities In OWL/OWL2, generalization relationships among classes can be circular . the semantics here are that all classes in the strongly connected graph of generalization relationships are semantically equivalent. All CMOF-based metamodels can.t have circular generalization relationships. In UML infrastructure, Core::Constructs::Classifier includes a constraint that the generalization relationships that a classifier is involved in must be acyclic. I propose to remove this constraint and replace it with a query: context Classifier::hasCircularGeneralization() : Boolean body: = self.general->includes(self) It is out of scope of the UML to say whether generalizations should be acyclic but it is something that could be enforced as an invariant specified in a profile (e.g., for OO languages with a strict type hierarchy). - Nicolas. On 12/16/09 2:55 AM, "Steve Cook" wrote: Jim I think this is useful for helping to establish the scope for 2.4. In my mind, in 2.4 we should avoid dealing with issues that can be dealt with better during simplification (your category 3) and issues that can be dealt with more easily after simplification (such as refactoring). I don.t think there is any need to avoid fixing OCL in 2.4 in cases where we find it to be in error. Thanks -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 15 December 2009 18:34 To: uml2-rtf@omg.org Subject: Guiding principles for choosing UML 2.4 Issues We increased the time window for the UML 2.4 RTF, but its still short. As you know, IBM's desire was to limit the number of additional releases on the 2.x stream as these are expensive, have limited value for our customers, and could delay efforts to significantly cleanup, simplify, and provide better extensibility and integration mechanisms for UML. In order to limit releases on the 2.x stream, we have to address issues that would motivate them. Ideally the 2.4 RTF would address these issues providing a usable, stable platform for UML modeling and model interchange. Then the UML 2.5 specification simplification submission could provide a better description of that that modeling language is. Taken together, these two releases could provide a longer-lived modeling platform that could give us the time we need to develop the next generation of UML that would hopefully address the issues and opportunities we identified in the UML Futures RFI responses. Maybe we can't achieve this with UML 2.4 and 2.5, and may need to do 2.6 and beyond to address specific needs. But it may be useful to try. The UML 2.4 (or possibly any) RTF is too short to address all the issues, so we may need some guiding principles to help decide which issues are critical to achieving a stable UML 2.5 platform, and therefore which ones will be included in 2.4. Here's a possible starter set for discussion: Include any issue that prevents creation of the merged metamodel or XMI interchange Include any show-stopper issues that are preventing the successful use of UML for common use cases, including some of the key issues raised by the RFI responses Avoid simple editorial changes and clarifications that could be handled by the UML 2.5 specification cleanup submission Avoid cleanup, refactoring, removal of unintended inheritance, OCL cleanup or addition of missing constraints, etc. that although useful, are not critical inhibitors for UML implementation or use, and may be easier to handle more effectively in a less constrained release. Do you think this is useful, a good starting point? Any other suggestions? Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Rouquette, Nicolas F (316A)" To: Steve Cook , Jim Amsden , "uml2-rtf@omg.org" Date: Mon, 21 Dec 2009 09:58:27 -0800 Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Topic: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Index: AQHKfy5DXRV1+v3xcUO9hitzsNQVAZFvu4rAgAAUfnk= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Steve, I had a very productive exchange with Pete about this resolution; I think I understand his objections and that there is a reasonable compromise that I can draft into a resolution for Jan. 4. Then, we can take it from there. I haven.t looked into the implications on serialization yet. We discussed in 2.3 the possibility of serializing applied profiles separately from the models/packages they are applied to. However, we kept the .profileApplication. end of association between Package & ProfileApplication (figure 18.2) as navigable. Now that OCL 2.1 clearly states that one can traversing association ends regardless of their navigability, it would be easy to make .profileApplication. non-navigable and add an operation to retrieve the information via OCL. This would incur a small API change but it would mean that we might be able to serialize applied profiles as separate resources. Of course, there are details to consider... - Nicolas. On 12/21/09 8:51 AM, "Steve Cook" wrote: Nicolas You wrote: >I propose then to file a new issue about this and include Ed.s suggestion below as well as clarifying that in Figure 18.18, .an instance of .S.. is actually an instance specification whose classifier happens to be .an instance .S. of Stereotype., i.e., the definition of .S., a kind of Class since Stereotype extends Class. Sounds good to me! I do remember however that when I suggested some time ago that stereotype instances are in fact instances of InstanceSpecification, I got quite a lot pushback. I don.t know what else they might be, though. It does mean that we.ll have two ways of serializing InstanceSpecifications though: the .normal. way and the stereotype way. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 17 December 2009 15:33 To: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Steve, Issue 10826 was asking for two things: what is an applied stereotype, as opposed to the definition of the stereotype that was applied what are tag/value pairs, as opposed to the definition of the stereotype properties that led to the tag/value pairs The resolution for 10826 added the following paragraph: An instance .S. of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather than generalization/specialization. Relating it to a metaclass .C. from the reference metamodel (typically UML) using an .Extension. (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of .S. (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of .S. are related to .C. model elements (instances of .C.) by links (occurrences of the association/extension from .S. to .C.). Up to the last sentence, the paragraph refers to .an instance .S. of Stereotype. -- i.e., the definition of .S., a stereotype, in a profile . as illustrated in figure 18.13. The last sentence is relevant to question (1) of 10826; however, the resolution doesn.t actually answer the question . i.e., it doesn.t explain what .an instance of .S.. actually is. >From Figure 18.18, the notation suggests that .an instance of .S.. is some kind of instance specification but the resolution doesn.t actually say so and doesn.t address question (2) of 10826 either. I propose then to file a new issue about this and include Ed.s suggestion below as well as clarifying that in Figure 18.18, .an instance of .S.. is actually an instance specification whose classifier happens to be .an instance .S. of Stereotype., i.e., the definition of .S., a kind of Class since Stereotype extends Class. - Nicolas. On 12/17/09 2:11 AM, "Steve Cook" wrote: Nic 10826 was resolved in Ballot 6 of 2.3. Please check. Regarding circular generalization: isn.t this a MOF thing? Shouldn.t this actually go into SMOF, whose purpose is better alignment between MOF and semantic web constructs? Thanks -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 16 December 2009 20:28 To: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Guiding principles for choosing UML 2.4 Issues What about the leftovers of the UML 2.3 RTF? Two leftovers are particularly important for other OMG specifications that depend on the UML spec: SysML and related efforts including the SysML/QUDV and SysML/Modelica integration. The two leftovers are: applied stereotypes (we had a discussion in issue 13291 but there is an issue filed, 10826 about this that isn.t in the UML 2.4 spreadsheet) navigation up/down classifier hierarchies About (1) -- Applied stereotypes. I didn.t find 10826 in the UML 2.4 spreadsheet: http://www.omg.org/issues/uml2-rtf.html#Issue10826 This issue is about the lack of a normative abstract syntax for accessing the stereotypes that are applied to an element: Issue 13291 was eventually withdrawn; however, before the discussion digressed to other topics, Ed provided a concise suggestion summarizing a discussion between Dave H., Ed S., Jim A. and myself (01/20/2009): Moreover, it seems to me that the whole point of pointing stereotypes specifically to UML metaclasses in UML 2 was so that such stereotypes were based of the standard UML metamodel. For this to have any real force in terms of repository representation and interchange, then the metaclasses referenced should be those with normative IDs in the normative CMOF representation of the metamodel. Such standard IDs are lost if each tool is, instead, pointing to its own (non-normative) representation of the metamodel as a UML L3 model. If stereotypes are not going to point to the normative CMOF metaclasses, then one might as well simplify the stereotype abstract syntax to just reference the extended the metaclasses by name, as was done in UML 1. -- Ed I propose to develop a resolution for 10826 and include Ed.s suggestion above, i.e., reference the extended metaclass by its normative URI. About (2) -- Navigation up/down classifier hierarchies. The UML 2.3 RTF report includes the following in the resolution text of 9374: This resolution includes an OCL constraint which depends on the OCL 2.1 revision: context AssociationClass self.A_general_classifier::classifier ->forAll(oclIsKindOf(AssociationClass)) The meaning of this constraint is as follows: self.A_general_classifier::classifier This expression navigates the association A_general_classifier in the inverse direction of the navigability of the property /Classifier::general : Classifier[*]. That is, it provides the set of classifiers that specialize .self.. This OCL constraint was editorially removed on the basis that UML 2.3 was aligned to OCL 2.0, not 2.1. Since then, OCL 2.1 is available; the constraint could be reinstated in principle. However, Maged had suggested instead renaming the association: A_general_classifier on Classifier to A_general_specific. Classifer would have, symmetrically, two derived properties for accessing its general and specific classifiers. Besides the two leftovers above, there is a third issue: (3) - Relaxing generalization relationships to allow circularities In OWL/OWL2, generalization relationships among classes can be circular . the semantics here are that all classes in the strongly connected graph of generalization relationships are semantically equivalent. All CMOF-based metamodels can.t have circular generalization relationships. In UML infrastructure, Core::Constructs::Classifier includes a constraint that the generalization relationships that a classifier is involved in must be acyclic. I propose to remove this constraint and replace it with a query: context Classifier::hasCircularGeneralization() : Boolean body: = self.general->includes(self) It is out of scope of the UML to say whether generalizations should be acyclic but it is something that could be enforced as an invariant specified in a profile (e.g., for OO languages with a strict type hierarchy). - Nicolas. On 12/16/09 2:55 AM, "Steve Cook" wrote: Jim I think this is useful for helping to establish the scope for 2.4. In my mind, in 2.4 we should avoid dealing with issues that can be dealt with better during simplification (your category 3) and issues that can be dealt with more easily after simplification (such as refactoring). I don.t think there is any need to avoid fixing OCL in 2.4 in cases where we find it to be in error. Thanks -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 15 December 2009 18:34 To: uml2-rtf@omg.org Subject: Guiding principles for choosing UML 2.4 Issues We increased the time window for the UML 2.4 RTF, but its still short. As you know, IBM's desire was to limit the number of additional releases on the 2.x stream as these are expensive, have limited value for our customers, and could delay efforts to significantly cleanup, simplify, and provide better extensibility and integration mechanisms for UML. In order to limit releases on the 2.x stream, we have to address issues that would motivate them. Ideally the 2.4 RTF would address these issues providing a usable, stable platform for UML modeling and model interchange. Then the UML 2.5 specification simplification submission could provide a better description of that that modeling language is. Taken together, these two releases could provide a longer-lived modeling platform that could give us the time we need to develop the next generation of UML that would hopefully address the issues and opportunities we identified in the UML Futures RFI responses. Maybe we can't achieve this with UML 2.4 and 2.5, and may need to do 2.6 and beyond to address specific needs. But it may be useful to try. The UML 2.4 (or possibly any) RTF is too short to address all the issues, so we may need some guiding principles to help decide which issues are critical to achieving a stable UML 2.5 platform, and therefore which ones will be included in 2.4. Here's a possible starter set for discussion: Include any issue that prevents creation of the merged metamodel or XMI interchange Include any show-stopper issues that are preventing the successful use of UML for common use cases, including some of the key issues raised by the RFI responses Avoid simple editorial changes and clarifications that could be handled by the UML 2.5 specification cleanup submission Avoid cleanup, refactoring, removal of unintended inheritance, OCL cleanup or addition of missing constraints, etc. that although useful, are not critical inhibitors for UML implementation or use, and may be easier to handle more effectively in a less constrained release. Do you think this is useful, a good starting point? Any other suggestions? Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 Date: Thu, 24 Dec 2009 11:59:01 +0000 From: Dave Hawkins User-Agent: Thunderbird 2.0.0.6 (X11/20070728) To: "Rouquette, Nicolas F (316A)" CC: Steve Cook , Jim Amsden , "uml2-rtf@omg.org" Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4B3357C5.001E:SCFMA4539814,ss=1,fgs=0 I thought Ed submitted http://www.omg.org/issues/uml2-rtf.html#Issue13306 to cover that discussion? The essence of the problem is that the current structure of the metamodel means that you cannot create a valid extension that points to a metaclass. It doesn't matter what id you chose, the typing is wrong because UML::Class != CMOF::Class. I've been working on an alternative metamodel for our tool that resolves this issue and allows normal XMI serialization to work. Where profile applications (and stereotype instances for that matter) are stored is separate to that but equally worthy of discussion. However is this really a 2.4 issue? Aren't the changes likely to be fairly significant? Cheers, Dave Rouquette, Nicolas F (316A) wrote: Steve, I had a very productive exchange with Pete about this resolution; I think I understand his objections and that there is a reasonable compromise that I can draft into a resolution for Jan. 4. Then, we can take it from there. I haven.t looked into the implications on serialization yet. We discussed in 2.3 the possibility of serializing applied profiles separately from the models/packages they are applied to. However, we kept the .profileApplication. end of association between Package & ProfileApplication (figure 18.2) as navigable. Now that OCL 2.1 clearly states that one can traversing association ends regardless of their navigability, it would be easy to make .profileApplication. non-navigable and add an operation to retrieve the information via OCL. This would incur a small API change but it would mean that we might be able to serialize applied profiles as separate resources. Of course, there are details to consider... - Nicolas. On 12/21/09 8:51 AM, "Steve Cook" wrote: Nicolas You wrote: >I propose then to file a new issue about this and include Ed.s suggestion below as well as clarifying that in Figure 18.18, .an instance of .S.. is actually an instance specification whose classifier happens to be .an instance .S. of Stereotype., i.e., the definition of .S., a kind of Class since Stereotype extends Class. Sounds good to me! I do remember however that when I suggested some time ago that stereotype instances are in fact instances of InstanceSpecification, I got quite a lot pushback. I don.t know what else they might be, though. It does mean that we.ll have two ways of serializing InstanceSpecifications though: the .normal. way and the stereotype way. -- Steve *From:* Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] *Sent:* 17 December 2009 15:33 *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org *Subject:* Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Steve, Issue 10826 was asking for two things: 1. what is an applied stereotype, as opposed to the definition of the stereotype that was applied 2. what are tag/value pairs, as opposed to the definition of the stereotype properties that led to the tag/value pairs The resolution for 10826 added the following paragraph: An instance .S. of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather than generalization/specialization. Relating it to a metaclass .C. from the reference metamodel (typically UML) using an .Extension. (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of .S. (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of .S. are related to .C. model elements (instances of .C.) by links (occurrences of the association/extension from .S. to .C.). Up to the last sentence, the paragraph refers to .an instance .S. of Stereotype. -- i.e., the definition of .S., a stereotype, in a profile . as illustrated in figure 18.13. The last sentence is relevant to question (1) of 10826; however, the resolution doesn.t actually answer the question . i.e., it doesn.t explain what .an instance of .S.. actually is. From Figure 18.18, the notation suggests that .an instance of .S.. is some kind of instance specification but the resolution doesn.t actually say so and doesn.t address question (2) of 10826 either. I propose then to file a new issue about this and include Ed.s suggestion below as well as clarifying that in Figure 18.18, .an instance of .S.. is actually an instance specification whose classifier happens to be .an instance .S. of Stereotype., i.e., the definition of .S., a kind of Class since Stereotype extends Class. - Nicolas. On 12/17/09 2:11 AM, "Steve Cook" wrote: Nic 10826 was resolved in Ballot 6 of 2.3. Please check. Regarding circular generalization: isn.t this a MOF thing? Shouldn.t this actually go into SMOF, whose purpose is better alignment between MOF and semantic web constructs? Thanks -- Steve *From:* Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] *Sent:* 16 December 2009 20:28 *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org *Subject:* Re: Guiding principles for choosing UML 2.4 Issues What about the leftovers of the UML 2.3 RTF? Two leftovers are particularly important for other OMG specifications that depend on the UML spec: SysML and related efforts including the SysML/QUDV and SysML/Modelica integration. The two leftovers are: 1. applied stereotypes (we had a discussion in issue 13291 but there is an issue filed, 10826 about this that isn.t in the UML 2.4 spreadsheet) 2. navigation up/down classifier hierarchies About (1) -- Applied stereotypes. I didn.t find 10826 in the UML 2.4 spreadsheet: http://www.omg.org/issues/uml2-rtf.html#Issue10826 This issue is about the lack of a normative abstract syntax for accessing the stereotypes that are applied to an element: Issue 13291 was eventually withdrawn; however, before the discussion digressed to other topics, Ed provided a concise suggestion summarizing a discussion between Dave H., Ed S., Jim A. and myself (01/20/2009): Moreover, it seems to me that the whole point of pointing stereotypes specifically to UML metaclasses in UML 2 was so that such stereotypes were based of the standard UML metamodel. For this to have any real force in terms of repository representation and interchange, then the metaclasses referenced should be those with normative IDs in the normative CMOF representation of the metamodel. Such standard IDs are lost if each tool is, instead, pointing to its own (non-normative) representation of the metamodel as a UML L3 model. If stereotypes are not going to point to the normative CMOF metaclasses, then one might as well simplify the stereotype abstract syntax to just reference the extended the metaclasses by name, as was done in UML 1. -- Ed I propose to develop a resolution for 10826 and include Ed.s suggestion above, i.e., reference the extended metaclass by its normative URI. About (2) -- Navigation up/down classifier hierarchies. The UML 2.3 RTF report includes the following in the resolution text of 9374: This resolution includes an OCL constraint which depends on the OCL 2.1 revision: context AssociationClass self.A_general_classifier::classifier ->forAll(oclIsKindOf(AssociationClass)) The meaning of this constraint is as follows: self.A_general_classifier::classifier This expression navigates the association A_general_classifier in the inverse direction of the navigability of the property /Classifier::general : Classifier[*]. That is, it provides the set of classifiers that specialize .self.. This OCL constraint was editorially removed on the basis that UML 2.3 was aligned to OCL 2.0, not 2.1. Since then, OCL 2.1 is available; the constraint could be reinstated in principle. However, Maged had suggested instead renaming the association: A_general_classifier on Classifier to A_general_specific. Classifer would have, symmetrically, two derived properties for accessing its general and specific classifiers. Besides the two leftovers above, there is a third issue: (3) - Relaxing generalization relationships to allow circularities In OWL/OWL2, generalization relationships among classes can be circular . the semantics here are that all classes in the strongly connected graph of generalization relationships are semantically equivalent. All CMOF-based metamodels can.t have circular generalization relationships. In UML infrastructure, Core::Constructs::Classifier includes a constraint that the generalization relationships that a classifier is involved in must be acyclic. I propose to remove this constraint and replace it with a query: context Classifier::hasCircularGeneralization() : Boolean body: = self.general->includes(self) It is out of scope of the UML to say whether generalizations should be acyclic but it is something that could be enforced as an invariant specified in a profile (e.g., for OO languages with a strict type hierarchy). - Nicolas. On 12/16/09 2:55 AM, "Steve Cook" wrote: Jim I think this is useful for helping to establish the scope for 2.4. In my mind, in 2.4 we should avoid dealing with issues that can be dealt with better during simplification (your category 3) and issues that can be dealt with more easily after simplification (such as refactoring). I don.t think there is any need to avoid fixing OCL in 2.4 in cases where we find it to be in error. Thanks -- Steve *From:* Jim Amsden [mailto:jamsden@us.ibm.com] *Sent:* 15 December 2009 18:34 *To:* uml2-rtf@omg.org *Subject:* Guiding principles for choosing UML 2.4 Issues We increased the time window for the UML 2.4 RTF, but its still short. As you know, IBM's desire was to limit the number of additional releases on the 2.x stream as these are expensive, have limited value for our customers, and could delay efforts to significantly cleanup, simplify, and provide better extensibility and integration mechanisms for UML. In order to limit releases on the 2.x stream, we have to address issues that would motivate them. Ideally the 2.4 RTF would address these issues providing a usable, stable platform for UML modeling and model interchange. Then the UML 2.5 specification simplification submission could provide a better description of that that modeling language is. Taken together, these two releases could provide a longer-lived modeling platform that could give us the time we need to develop the next generation of UML that would hopefully address the issues and opportunities we identified in the UML Futures RFI responses. Maybe we can't achieve this with UML 2.4 and 2.5, and may need to do 2.6 and beyond to address specific needs. But it may be useful to try. The UML 2.4 (or possibly any) RTF is too short to address all the issues, so we may need some guiding principles to help decide which issues are critical to achieving a stable UML 2.5 platform, and therefore which ones will be included in 2.4. Here's a possible starter set for discussion: 1. Include any issue that prevents creation of the merged metamodel or XMI interchange 2. Include any show-stopper issues that are preventing the successful use of UML for common use cases, including some of the key issues raised by the RFI responses 3. Avoid simple editorial changes and clarifications that could be handled by the UML 2.5 specification cleanup submission 4. Avoid cleanup, refactoring, removal of unintended inheritance, OCL cleanup or addition of missing constraints, etc. that although useful, are not critical inhibitors for UML implementation or use, and may be easier to handle more effectively in a less constrained release. Do you think this is useful, a good starting point? Any other suggestions? Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: "Rouquette, Nicolas F (316A)" To: Dave Hawkins CC: Steve Cook , Jim Amsden , "uml2-rtf@omg.org" Date: Thu, 24 Dec 2009 10:02:49 -0800 Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Topic: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Index: AcqEkKT7ddJ3FEmrSKm/Bg72EDX0DwAMqit+ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Dave, 13306 is perhaps wishful thinking on my part; however, if you have developed a solution for it; would you consider using it to propose a resolution? The problem I.m after is finishing 10826; in particular, explicitly stating what kind of thing a stereotype instance actually is . i.e., a kind of instance specification whose classifier is the stereotype and that has a link to the stereotyped element where this link is in fact an instance of the Extension association. We have users who are experiencing problems with profiles; these problems are related to several factors: we can apply a profile only once to a package currently, the instances of stereotypes applied to elements are serialized in the same resource as the stereotyped elements According to the spec, (1) and (2) imply that the ability to modify an element also includes the ability to add/modify/delete any stereotype applicable to that element; and each stereotype can be applied only once. We are effectively unable to use configuration management techniques on model resources to address this problem; we have to use some kind of indirection scheme in the model itself. If a tool vendor has a proprietary solution to this, it is most likely non-interoperable with other tools. If we use a custom solution, we then have to build custom tool extensions to deal with this and train users how to use our own customizations. Here is a simple example of what we should be able to do. Consider a SysML model, M, with 3 elements: X,Y,Z Consider two users, Jack and Susie, who need to come up with proposals for allocating elements of M. Jack wants to allocate X to Y. Susie wants to allocate X to Z. We should allow Jack to create a resource, M-Jack, that imports M where M-Jack contains the application of the <> and <> stereotypes to X and Y. Ditto for Susie. To make this easier for tools to support, we can make ProfileApplication both a DirectedRelationship and a PackageableElement. Having made the notion of an applied stereotype explicit in the abstract syntax, we can certainly add the following constraint: A stereotype instance IS for a stereotype S defined in a profile PF and applied to an element E contained in a package P must be contained in the same package that also contains the profile application of PF to P. With this constraint, a tool could, for example, prompt the user for which package to put a stereotype instance if in fact there are multiple profile applications in distinct packages. This would allow, for example, Jack and Susie to manage their allocations in their own packages without clobbering each other independently of whether Jack.s and Susie.s packages are serialized separately. As far as whether it is reasonable to do this in 2.4; I.ll draft a resolution for finishing 10826 and we.ll take it from there. Since you seem to be ahead of me w.r.t. 13306, I.ll let you decide whether you want to propose a resolution or not. - Nicolas. On 12/24/09 3:59 AM, "Dave Hawkins" wrote: I thought Ed submitted http://www.omg.org/issues/uml2-rtf.html#Issue13306 to cover that discussion? The essence of the problem is that the current structure of the metamodel means that you cannot create a valid extension that points to a metaclass. It doesn't matter what id you chose, the typing is wrong because UML::Class != CMOF::Class. I've been working on an alternative metamodel for our tool that resolves this issue and allows normal XMI serialization to work. Where profile applications (and stereotype instances for that matter) are stored is separate to that but equally worthy of discussion. However is this really a 2.4 issue? Aren't the changes likely to be fairly significant? Cheers, Dave Rouquette, Nicolas F (316A) wrote: > Steve, > > I had a very productive exchange with Pete about this resolution; I > think I understand his objections and that there is a reasonable > compromise that I can draft into a resolution for Jan. 4. > Then, we can take it from there. > > I haven.t looked into the implications on serialization yet. We > discussed in 2.3 the possibility of serializing applied profiles > separately from the models/packages they are applied to. > However, we kept the .profileApplication. end of association between > Package & ProfileApplication (figure 18.2) as navigable. > > Now that OCL 2.1 clearly states that one can traversing association ends > regardless of their navigability, it would be easy to make > .profileApplication. non-navigable and add an operation to retrieve the > information via OCL. This would incur a small API change but it would > mean that we might be able to serialize applied profiles as separate > resources. Of course, there are details to consider... > > - Nicolas. > > > > On 12/21/09 8:51 AM, "Steve Cook" wrote: > > Nicolas > > You wrote: > >I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > Sounds good to me! I do remember however that when I suggested > some time ago that stereotype instances are in fact instances of > InstanceSpecification, I got quite a lot pushback. I don.t know > what else they might be, though. > > It does mean that we.ll have two ways of serializing > InstanceSpecifications though: the .normal. way and the stereotype way. > > -- Steve > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 17 December 2009 15:33 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Incomplete resolution to 10826 -- Re: Guiding principles > for choosing UML 2.4 Issues > > Steve, > > Issue 10826 was asking for two things: > > 1. what is an applied stereotype, as opposed to the definition of > the stereotype that was applied > 2. what are tag/value pairs, as opposed to the definition of the > stereotype properties that led to the tag/value pairs > > > The resolution for 10826 added the following paragraph: > An instance .S. of Stereotype is a kind of metaclass that extends > other metaclasses through association (Extension) rather > than generalization/specialization. Relating it to a metaclass .C. > from the reference metamodel (typically UML) using an > .Extension. (which is a specific kind of association), signifies > that model elements of type C can be extended by an > instance of .S. (see example in Figure 18.13). At the model level > (such as in Figure 18.18) instances of .S. are related to > .C. model elements (instances of .C.) by links (occurrences of the > association/extension from .S. to .C.). > > > > Up to the last sentence, the paragraph refers to .an instance .S. of > Stereotype. -- i.e., the definition of .S., a stereotype, in a > profile . as illustrated in figure 18.13. > > The last sentence is relevant to question (1) of 10826; however, the > resolution doesn.t actually answer the question . i.e., it doesn.t > explain what .an instance of .S.. actually is. From Figure 18.18, > the notation suggests that .an instance of .S.. is some kind of > instance specification but the resolution doesn.t actually say so > and doesn.t address question (2) of 10826 either. > > I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > - Nicolas. > > > On 12/17/09 2:11 AM, "Steve Cook" wrote: > Nic > > 10826 was resolved in Ballot 6 of 2.3. Please check. > > Regarding circular generalization: isn.t this a MOF thing? Shouldn.t > this actually go into SMOF, whose purpose is better alignment > between MOF and semantic web constructs? > > Thanks > -- Steve > > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 16 December 2009 20:28 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Re: Guiding principles for choosing UML 2.4 Issues > > What about the leftovers of the UML 2.3 RTF? > > Two leftovers are particularly important for other OMG > specifications that depend on the UML spec: SysML and related > efforts including the SysML/QUDV and SysML/Modelica integration. > The two leftovers are: > > 1. applied stereotypes (we had a discussion in issue 13291 but > there is an issue filed, 10826 about this that isn.t in the > UML 2.4 spreadsheet) > 2. navigation up/down classifier hierarchies > > > About (1) -- Applied stereotypes. > > I didn.t find 10826 in the UML 2.4 spreadsheet: > http://www.omg.org/issues/uml2-rtf.html#Issue10826 > This issue is about the lack of a normative abstract syntax for > accessing the stereotypes that are applied to an element: > > Issue 13291 was eventually withdrawn; however, before the discussion > digressed to other topics, Ed provided a concise suggestion > summarizing a discussion between Dave H., Ed S., Jim A. and myself > (01/20/2009): > Moreover, it seems to me that the whole point of pointing stereotypes > specifically to UML metaclasses in UML 2 was so that such stereotypes > were based of the standard UML metamodel. For this to have any real > force in terms of repository representation and interchange, then the > metaclasses referenced should be those with normative IDs in the > normative CMOF representation of the metamodel. Such standard IDs are > lost if each tool is, instead, pointing to its own (non-normative) > representation of the metamodel as a UML L3 model. > > If stereotypes are not going to point to the normative CMOF metaclasses, > then one might as well simplify the stereotype abstract syntax to just > reference the extended the metaclasses by name, as was done in UML 1. > > -- Ed > > I propose to develop a resolution for 10826 and include Ed.s > suggestion above, i.e., reference the extended metaclass by its > normative URI. > > About (2) -- Navigation up/down classifier hierarchies. > > The UML 2.3 RTF report includes the following in the resolution text > of 9374: > This resolution includes an OCL constraint which depends on the OCL > 2.1 revision: > context AssociationClass > self.A_general_classifier::classifier > ->forAll(oclIsKindOf(AssociationClass)) > The meaning of this constraint is as follows: > self.A_general_classifier::classifier > This expression navigates the association A_general_classifier in > the inverse direction of the navigability of the property > /Classifier::general : Classifier[*]. > That is, it provides the set of classifiers that specialize .self.. > > This OCL constraint was editorially removed on the basis that UML > 2.3 was aligned to OCL 2.0, not 2.1. > Since then, OCL 2.1 is available; the constraint could be reinstated > in principle. > However, Maged had suggested instead renaming the association: > A_general_classifier on Classifier to A_general_specific. > Classifer would have, symmetrically, two derived properties for > accessing its general and specific classifiers. > > Besides the two leftovers above, there is a third issue: > > (3) - Relaxing generalization relationships to allow circularities > > In OWL/OWL2, generalization relationships among classes can be > circular . > the semantics here are that all classes in the strongly connected > graph of > generalization relationships are semantically equivalent. > > All CMOF-based metamodels can.t have circular generalization > relationships. > In UML infrastructure, Core::Constructs::Classifier includes a > constraint that > the generalization relationships that a classifier is involved in > must be acyclic. > > I propose to remove this constraint and replace it with a query: > > context Classifier::hasCircularGeneralization() : Boolean > body: = self.general->includes(self) > > It is out of scope of the UML to say whether generalizations should be > acyclic but it is something that could be enforced as an invariant > specified > in a profile (e.g., for OO languages with a strict type hierarchy). > > - Nicolas. > > > On 12/16/09 2:55 AM, "Steve Cook" wrote: > Jim > > I think this is useful for helping to establish the scope for 2.4. > In my mind, in 2.4 we should avoid dealing with issues that can be > dealt with better during simplification (your category 3) and issues > that can be dealt with more easily after simplification (such as > refactoring). > > I don.t think there is any need to avoid fixing OCL in 2.4 in cases > where we find it to be in error. > > Thanks > -- Steve > > *From:* Jim Amsden [mailto:jamsden@us.ibm.com] > *Sent:* 15 December 2009 18:34 > *To:* uml2-rtf@omg.org > *Subject:* Guiding principles for choosing UML 2.4 Issues > > We increased the time window for the UML 2.4 RTF, but its still > short. As you know, IBM's desire was to limit the number of > additional releases on the 2.x stream as these are expensive, have > limited value for our customers, and could delay efforts to > significantly cleanup, simplify, and provide better extensibility > and integration mechanisms for UML. In order to limit releases on > the 2.x stream, we have to address issues that would motivate them. > Ideally the 2.4 RTF would address these issues providing a usable, > stable platform for UML modeling and model interchange. Then the UML > 2.5 specification simplification submission could provide a better > description of that that modeling language is. Taken together, these > two releases could provide a longer-lived modeling platform that > could give us the time we need to develop the next generation of UML > that would hopefully address the issues and opportunities we > identified in the UML Futures RFI responses. > > Maybe we can't achieve this with UML 2.4 and 2.5, and may need to do > 2.6 and beyond to address specific needs. But it may be useful to try. > > The UML 2.4 (or possibly any) RTF is too short to address all the > issues, so we may need some guiding principles to help decide which > issues are critical to achieving a stable UML 2.5 platform, and > therefore which ones will be included in 2.4. Here's a possible > starter set for discussion: > > 1. Include any issue that prevents creation of the merged > metamodel or XMI interchange > 2. Include any show-stopper issues that are preventing the > successful use of UML for common use cases, including some of > the key issues raised by the RFI responses > 3. Avoid simple editorial changes and clarifications that could > be handled by the UML 2.5 specification cleanup submission > 4. Avoid cleanup, refactoring, removal of unintended inheritance, > OCL cleanup or addition of missing constraints, etc. that > although useful, are not critical inhibitors for UML > implementation or use, and may be easier to handle more > effectively in a less constrained release. > > > Do you think this is useful, a good starting point? Any other > suggestions? > > > Jim Amsden, Senior Technical Staff Member > Rational Enterprise Architecture Management > 919-461-3689 > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. Subject: RE: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Date: Thu, 24 Dec 2009 11:01:38 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Index: AcqEkKT7ddJ3FEmrSKm/Bg72EDX0DwAMqit+AACDsAA= From: "Pete Rivett" To: "Rouquette, Nicolas F (316A)" , "Dave Hawkins" Cc: "Steve Cook" , "Jim Amsden" , Some interesting points here . and a number of assumptions which I don.t think are supported by the spec (neither UML nor MOF nor XMI). I think the specs between them (if not eh tools) are already capable of what Nicolas wants: the only thing possibly lacking is the ability to associate Stereotype Instances (which BTW are emphatically not UML InstanceSpecifications) with ProfileApplications. See below. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 24 December 2009 10:03 To: Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Dave, 13306 is perhaps wishful thinking on my part; however, if you have developed a solution for it; would you consider using it to propose a resolution? The problem I.m after is finishing 10826; in particular, explicitly stating what kind of thing a stereotype instance actually is . i.e., a kind of instance specification whose classifier is the stereotype and that has a link to the stereotyped element where this link is in fact an instance of the Extension association. [PJR] As per our private email thread I don.t agree with this: a stereotype instance is a instance of the pseudo-metaclass defined by the Stereotype definition. We have users who are experiencing problems with profiles; these problems are related to several factors: we can apply a profile only once to a package [PJR] in theory there is nothing to require this . though each ProfileApplication is for one Profile, a Package could have many ProfileApplications each for the same Profile. currently, the instances of stereotypes applied to elements are serialized in the same resource as the stereotyped elements [PJR] this is by no means required by the specs: indeed an original design goal was to allow different stereotype instances to be associated with the same model to create different marked-up models for different purposes and without .disrupting. that model (e.g. one for a database realization another for a Java realization). BTW in OMG language we should refer to .extent. or .store.(as defined by MOF) not .resource.. According to the spec, (1) and (2)[PJR] not IMHO valid factors . see above imply that the ability to modify an element also includes the ability to add/modify/delete any stereotype applicable to that element; and each stereotype can be applied only once. [PJR] I.m not aware that the specs say anything whatsoever about .ability to modify elements., except that a Property may be flagged as ReadOnly. And AFAIK in the UML metamodel itself there are no such Properties except those which are derived. Furthermore there is no property owned by the stereotyped element to represent the link to the stereotype instance so changing stereotypes does not require changing any property owned by that element. We are effectively unable to use configuration management techniques on model resources to address this problem; we have to use some kind of indirection scheme in the model itself. If a tool vendor has a proprietary solution to this, it is most likely non-interoperable with other tools. If we use a custom solution, we then have to build custom tool extensions to deal with this and train users how to use our own customizations. [PJR] You should pressure the vendor to remove restrictions not required by the spec. I don.t see why this should be proprietary. In order to help interoperability any conventions could be agreed and tested through the MIWG. Here is a simple example of what we should be able to do. Consider a SysML model, M, with 3 elements: X,Y,Z Consider two users, Jack and Susie, who need to come up with proposals for allocating elements of M. Jack wants to allocate X to Y. Susie wants to allocate X to Z. We should allow Jack to create a resource, M-Jack, that imports M [PJR] I don.t see why .import. is strictly needed where M-Jack contains the application of the <> and <> stereotypes to X and Y. Ditto for Susie. To make this easier for tools to support, we can make ProfileApplication both a DirectedRelationship and a PackageableElement. [PJR] Hmm it is already (at UML 2.3) a DirectedRelationship and owned by Package (though not specifically a PackageableElement though I.m not sure what benefit this would add). Having made the notion of an applied stereotype explicit in the abstract syntax, we can certainly add the following constraint: A stereotype instance IS for a stereotype S defined in a profile PF and applied to an element E contained in a package P must be contained in the same package that also contains the profile application of PF to P. [PJR] No. Stereotype instances are currently clearly defined as owned by the element to which they are applied not any Package. However you raise an interesting issue as to how the different stereotype instances owned by an element (potentially in different extents) can be distinguished or related to a ProfileApplication. Though it would be possible to use MOF capabilities to discover the extent of the different instances and the profile application it would be desirable if UML were more .self contained. in this regard. That would also provide a means for them to be constrained in the manner you suggest . though we should also debate the benefits of such a constraint. With this constraint, a tool could, for example, prompt the user for which package to put a stereotype instance if in fact there are multiple profile applications in distinct packages. This would allow, for example, Jack and Susie to manage their allocations in their own packages without clobbering each other independently of whether Jack.s and Susie.s packages are serialized separately. [PJR] another approach is for UML tools to work with Workspaces as defined by MOF Facility (and extended by MOF Versioning). So Jack and Susie would have different workspaces each including the shared model and the profile but with their own packages for stereotype instances. Actually MOF Workspaces are designed to be transparent to modeling tools and could be supported by the .environment. e.g. Eclipse As far as whether it is reasonable to do this in 2.4; I.ll draft a resolution for finishing 10826 and we.ll take it from there. Since you seem to be ahead of me w.r.t. 13306, I.ll let you decide whether you want to propose a resolution or not. [PJR] See also one further comment below. - Nicolas. On 12/24/09 3:59 AM, "Dave Hawkins" wrote: I thought Ed submitted http://www.omg.org/issues/uml2-rtf.html#Issue13306 to cover that discussion? The essence of the problem is that the current structure of the metamodel means that you cannot create a valid extension that points to a metaclass. It doesn't matter what id you chose, the typing is wrong because UML::Class != CMOF::Class. [PJR] Agreed. IMHO the problem is in Fig 18.2 which shows a single Class: it should continue to show Stereotype inheriting from UML::Class but ExtensionEnd should be linked to CMOF::Class. We now have defined URLs for referencing other metamodels, and a reliable UML XMI file, so I don.t see that references to elements in the UML metamodel itself (the CMOF file) should be a problem. That is after all what many tools are already using when serializing models to reference the standard PrimitiveTypes such as Integer. I've been working on an alternative metamodel for our tool that resolves this issue and allows normal XMI serialization to work. Where profile applications (and stereotype instances for that matter) are stored is separate to that but equally worthy of discussion. However is this really a 2.4 issue? Aren't the changes likely to be fairly significant? Cheers, Dave Rouquette, Nicolas F (316A) wrote: > Steve, > > I had a very productive exchange with Pete about this resolution; I > think I understand his objections and that there is a reasonable > compromise that I can draft into a resolution for Jan. 4. > Then, we can take it from there. > > I haven.t looked into the implications on serialization yet. We > discussed in 2.3 the possibility of serializing applied profiles > separately from the models/packages they are applied to. > However, we kept the .profileApplication. end of association between > Package & ProfileApplication (figure 18.2) as navigable. > > Now that OCL 2.1 clearly states that one can traversing association ends > regardless of their navigability, it would be easy to make > .profileApplication. non-navigable and add an operation to retrieve the > information via OCL. This would incur a small API change but it would > mean that we might be able to serialize applied profiles as separate > resources. Of course, there are details to consider... > > - Nicolas. > > > > On 12/21/09 8:51 AM, "Steve Cook" wrote: > > Nicolas > > You wrote: > >I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > Sounds good to me! I do remember however that when I suggested > some time ago that stereotype instances are in fact instances of > InstanceSpecification, I got quite a lot pushback. I don.t know > what else they might be, though. > > It does mean that we.ll have two ways of serializing > InstanceSpecifications though: the .normal. way and the stereotype way. > > -- Steve > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 17 December 2009 15:33 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Incomplete resolution to 10826 -- Re: Guiding principles > for choosing UML 2.4 Issues > > Steve, > > Issue 10826 was asking for two things: > > 1. what is an applied stereotype, as opposed to the definition of > the stereotype that was applied > 2. what are tag/value pairs, as opposed to the definition of the > stereotype properties that led to the tag/value pairs > > > The resolution for 10826 added the following paragraph: > An instance .S. of Stereotype is a kind of metaclass that extends > other metaclasses through association (Extension) rather > than generalization/specialization. Relating it to a metaclass .C. > from the reference metamodel (typically UML) using an > .Extension. (which is a specific kind of association), signifies > that model elements of type C can be extended by an > instance of .S. (see example in Figure 18.13). At the model level > (such as in Figure 18.18) instances of .S. are related to > .C. model elements (instances of .C.) by links (occurrences of the > association/extension from .S. to .C.). > > > > Up to the last sentence, the paragraph refers to .an instance .S. of > Stereotype. -- i.e., the definition of .S., a stereotype, in a > profile . as illustrated in figure 18.13. > > The last sentence is relevant to question (1) of 10826; however, the > resolution doesn.t actually answer the question . i.e., it doesn.t > explain what .an instance of .S.. actually is. From Figure 18.18, > the notation suggests that .an instance of .S.. is some kind of > instance specification but the resolution doesn.t actually say so > and doesn.t address question (2) of 10826 either. > > I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > - Nicolas. > > > On 12/17/09 2:11 AM, "Steve Cook" wrote: > Nic > > 10826 was resolved in Ballot 6 of 2.3. Please check. > > Regarding circular generalization: isn.t this a MOF thing? Shouldn.t > this actually go into SMOF, whose purpose is better alignment > between MOF and semantic web constructs? > > Thanks > -- Steve > > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 16 December 2009 20:28 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Re: Guiding principles for choosing UML 2.4 Issues > > What about the leftovers of the UML 2.3 RTF? > > Two leftovers are particularly important for other OMG > specifications that depend on the UML spec: SysML and related > efforts including the SysML/QUDV and SysML/Modelica integration. > The two leftovers are: > > 1. applied stereotypes (we had a discussion in issue 13291 but > there is an issue filed, 10826 about this that isn.t in the > UML 2.4 spreadsheet) > 2. navigation up/down classifier hierarchies > > > About (1) -- Applied stereotypes. > > I didn.t find 10826 in the UML 2.4 spreadsheet: > http://www.omg.org/issues/uml2-rtf.html#Issue10826 > This issue is about the lack of a normative abstract syntax for > accessing the stereotypes that are applied to an element: > > Issue 13291 was eventually withdrawn; however, before the discussion > digressed to other topics, Ed provided a concise suggestion > summarizing a discussion between Dave H., Ed S., Jim A. and myself > (01/20/2009): > Moreover, it seems to me that the whole point of pointing stereotypes > specifically to UML metaclasses in UML 2 was so that such stereotypes > were based of the standard UML metamodel. For this to have any real > force in terms of repository representation and interchange, then the > metaclasses referenced should be those with normative IDs in the > normative CMOF representation of the metamodel. Such standard IDs are > lost if each tool is, instead, pointing to its own (non-normative) > representation of the metamodel as a UML L3 model. > > If stereotypes are not going to point to the normative CMOF metaclasses, > then one might as well simplify the stereotype abstract syntax to just > reference the extended the metaclasses by name, as was done in UML 1. > > -- Ed > > I propose to develop a resolution for 10826 and include Ed.s > suggestion above, i.e., reference the extended metaclass by its > normative URI. > > About (2) -- Navigation up/down classifier hierarchies. > > The UML 2.3 RTF report includes the following in the resolution text > of 9374: > This resolution includes an OCL constraint which depends on the OCL > 2.1 revision: > context AssociationClass > self.A_general_classifier::classifier > ->forAll(oclIsKindOf(AssociationClass)) > The meaning of this constraint is as follows: > self.A_general_classifier::classifier > This expression navigates the association A_general_classifier in > the inverse direction of the navigability of the property > /Classifier::general : Classifier[*]. > That is, it provides the set of classifiers that specialize .self.. > > This OCL constraint was editorially removed on the basis that UML > 2.3 was aligned to OCL 2.0, not 2.1. > Since then, OCL 2.1 is available; the constraint could be reinstated > in principle. > However, Maged had suggested instead renaming the association: > A_general_classifier on Classifier to A_general_specific. > Classifer would have, symmetrically, two derived properties for > accessing its general and specific classifiers. > > Besides the two leftovers above, there is a third issue: > > (3) - Relaxing generalization relationships to allow circularities > > In OWL/OWL2, generalization relationships among classes can be > circular . > the semantics here are that all classes in the strongly connected > graph of > generalization relationships are semantically equivalent. > > All CMOF-based metamodels can.t have circular generalization > relationships. > In UML infrastructure, Core::Constructs::Classifier includes a > constraint that > the generalization relationships that a classifier is involved in > must be acyclic. > > I propose to remove this constraint and replace it with a query: > > context Classifier::hasCircularGeneralization() : Boolean > body: = self.general->includes(self) > > It is out of scope of the UML to say whether generalizations should be > acyclic but it is something that could be enforced as an invariant > specified > in a profile (e.g., for OO languages with a strict type hierarchy). > > - Nicolas. > > > On 12/16/09 2:55 AM, "Steve Cook" wrote: > Jim > > I think this is useful for helping to establish the scope for 2.4. > In my mind, in 2.4 we should avoid dealing with issues that can be > dealt with better during simplification (your category 3) and issues > that can be dealt with more easily after simplification (such as > refactoring). > > I don.t think there is any need to avoid fixing OCL in 2.4 in cases > where we find it to be in error. > > Thanks > -- Steve > > *From:* Jim Amsden [mailto:jamsden@us.ibm.com] > *Sent:* 15 December 2009 18:34 > *To:* uml2-rtf@omg.org > *Subject:* Guiding principles for choosing UML 2.4 Issues > > We increased the time window for the UML 2.4 RTF, but its still > short. As you know, IBM's desire was to limit the number of > additional releases on the 2.x stream as these are expensive, have > limited value for our customers, and could delay efforts to > significantly cleanup, simplify, and provide better extensibility > and integration mechanisms for UML. In order to limit releases on > the 2.x stream, we have to address issues that would motivate them. > Ideally the 2.4 RTF would address these issues providing a usable, > stable platform for UML modeling and model interchange. Then the UML > 2.5 specification simplification submission could provide a better > description of that that modeling language is. Taken together, these > two releases could provide a longer-lived modeling platform that > could give us the time we need to develop the next generation of UML > that would hopefully address the issues and opportunities we > identified in the UML Futures RFI responses. > > Maybe we can't achieve this with UML 2.4 and 2.5, and may need to do > 2.6 and beyond to address specific needs. But it may be useful to try. > > The UML 2.4 (or possibly any) RTF is too short to address all the > issues, so we may need some guiding principles to help decide which > issues are critical to achieving a stable UML 2.5 platform, and > therefore which ones will be included in 2.4. Here's a possible > starter set for discussion: > > 1. Include any issue that prevents creation of the merged > metamodel or XMI interchange > 2. Include any show-stopper issues that are preventing the > successful use of UML for common use cases, including some of > the key issues raised by the RFI responses > 3. Avoid simple editorial changes and clarifications that could > be handled by the UML 2.5 specification cleanup submission > 4. Avoid cleanup, refactoring, removal of unintended inheritance, > OCL cleanup or addition of missing constraints, etc. that > although useful, are not critical inhibitors for UML > implementation or use, and may be easier to handle more > effectively in a less constrained release. > > > Do you think this is useful, a good starting point? Any other > suggestions? > > > Jim Amsden, Senior Technical Staff Member > Rational Enterprise Architecture Management > 919-461-3689 > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: "Rouquette, Nicolas F (316A)" To: Pete Adaptive , Dave Hawkins CC: Steve Cook , Jim Amsden , "uml2-rtf@omg.org" Date: Thu, 24 Dec 2009 18:04:42 -0800 Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Topic: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Index: AcqEkKT7ddJ3FEmrSKm/Bg72EDX0DwAMqit+AACDsAAAEFCwWQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Comments below. On 12/24/09 11:01 AM, "Pete Adaptive" wrote: Some interesting points here . and a number of assumptions which I don.t think are supported by the spec (neither UML nor MOF nor XMI). I think the specs between them (if not eh tools) are already capable of what Nicolas wants: [NFR] Really? Without a first-class abstract syntax concept in the spec for a stereotype instance created as a result of applying a stereotype to an element, I don.t see how a hypothetical tool could explain in terms of the spec how one could do the following: A) apply the same stereotype to the same element multiple times B) manage elements in one resource and stereotypes applied to these elements in a separate resource Of course, a tool could extend the specification and do (A) and (B) in a tool-specific manner. I don.t know if there are any such tools either. the only thing possibly lacking is the ability to associate Stereotype Instances (which BTW are emphatically not UML InstanceSpecifications) with ProfileApplications. Moreover, this association depends on having a first-class concept for a stereotype instance. See below. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 24 December 2009 10:03 To: Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Dave, 13306 is perhaps wishful thinking on my part; however, if you have developed a solution for it; would you consider using it to propose a resolution? The problem I.m after is finishing 10826; in particular, explicitly stating what kind of thing a stereotype instance actually is . i.e., a kind of instance specification whose classifier is the stereotype and that has a link to the stereotyped element where this link is in fact an instance of the Extension association. [PJR] As per our private email thread I don.t agree with this: a stereotype instance is a instance of the pseudo-metaclass defined by the Stereotype definition. [NFR] You are referring to the semantics of a stereotype instance . I agree with you! I.m focusing on how to specify the abstract syntax of a stereotype instance in compliance with requirement #9 of clause 18.1.2: 9. The vast majority of UML case tools should be able to implement Profiles. The design of UML profiles should therefore not constrain these tools to have an internal implementation based on a meta-metamodel/metamodel architecture. At the level of the abstract syntax definition of a stereotype instance, it is clear that we can.t refer to the pseudo-metaclass defined by the stereotype definition. In compliance with the above requirement, this pseudo-metaclass can only exist in the realm of the semantics of stereotypes; not their abstract syntax representation. We have users who are experiencing problems with profiles; these problems are related to several factors: we can apply a profile only once to a package [PJR] in theory there is nothing to require this . though each ProfileApplication is for one Profile, a Package could have many ProfileApplications each for the same Profile. [NFR] In practice, this theoretical flexibility is useless without support at the abstract syntax level to associate a stereotype instance to a specific profile application. currently, the instances of stereotypes applied to elements are serialized in the same resource as the stereotyped elements [PJR] this is by no means required by the specs: [NFR] Clearly the spec can.t require this since it doesn.t specify an abstract syntax for stereotype instances! indeed an original design goal was to allow different stereotype instances to be associated with the same model to create different marked-up models for different purposes and without .disrupting. that model (e.g. one for a database realization another for a Java realization). BTW in OMG language we should refer to .extent. or .store.(as defined by MOF) not .resource.. [NFR] Note that this design goal is beyond the requirements stated in clause 18.1.2. It would be easy to consider a requirement that one must be able to apply a profile to a package in a read-only extent. However, there are two problems: the concept of extent is MOF-specific (10.1, 13.6) and this requirement would violate requirement #9 above MOF doesn.t say anything about what a read-only extent is. Within the limitations of the existing requirements, the best we can do is make a ProfileApplication a kind of PackageableElement. Then, we can state the original design goal in terms of ownership/containment within a package in lieu of MOF extent. According to the spec, (1) and (2)[PJR] not IMHO valid factors . see above imply that the ability to modify an element also includes the ability to add/modify/delete any stereotype applicable to that element; and each stereotype can be applied only once. [PJR] I.m not aware that the specs say anything whatsoever about .ability to modify elements., except that a Property may be flagged as ReadOnly. And AFAIK in the UML metamodel itself there are no such Properties except those which are derived. Furthermore there is no property owned by the stereotyped element to represent the link to the stereotype instance so changing stereotypes does not require changing any property owned by that element. [NFR] Without a first-class abstract syntax concept for a stereotype instance, I don.t know how to explain the problem in terms defined in the spec. We are effectively unable to use configuration management techniques on model resources to address this problem; we have to use some kind of indirection scheme in the model itself. If a tool vendor has a proprietary solution to this, it is most likely non-interoperable with other tools. If we use a custom solution, we then have to build custom tool extensions to deal with this and train users how to use our own customizations. [PJR] You should pressure the vendor to remove restrictions not required by the spec. I don.t see why this should be proprietary. In order to help interoperability any conventions could be agreed and tested through the MIWG. [NFR] The restriction is a practical consequence of how a tool implements the spec. I don.t see how your suggestion helps in the short term. It is very difficult to put pressure on tool vendors to do something differently when the spec talks about the concept of a stereotype instance without defining what it is. Here is a simple example of what we should be able to do. Consider a SysML model, M, with 3 elements: X,Y,Z Consider two users, Jack and Susie, who need to come up with proposals for allocating elements of M. Jack wants to allocate X to Y. Susie wants to allocate X to Z. We should allow Jack to create a resource, M-Jack, that imports M [PJR] I don.t see why .import. is strictly needed where M-Jack contains the application of the <> and <> stereotypes to X and Y. Ditto for Susie. To make this easier for tools to support, we can make ProfileApplication both a DirectedRelationship and a PackageableElement. [PJR] Hmm it is already (at UML 2.3) a DirectedRelationship and owned by Package (though not specifically a PackageableElement though I.m not sure what benefit this would add). [NFR] In UML 2.3, we have: ProfileApplication => DirectedRelationship => Relationship => Element. If a tool implements a ProfileApplication as a non-packageable element, then we cannot access instances of ProfileApplication except via the associations to Package and Profile. But then, two instances of ProfileApplication that have the same profile/package would be indistinguishable from one another. This means that for all practical purposes, we are effectively restricted to being able to apply a given profile to a given package only once. If we make a ProfileApplication a kind of PackageableElement, then we get the ability to distinguish two different instances of ProfileApplication independently of which package and profile are involved. Again, this is of limited value unless we also have a first-class concept for a StereotypeInstance. When you put the two together, then you get something useful at the specification level in a tool-neutral way. Below is a sketch of what this combination would allow us to do in the context of the above example with a model M::{X,Y,Z} where Jack could put the information about his application of the SysML profile to M in a separate package, M-Jack, where, .X is allocated to Y. would entail 4 elements in M-Jack: X_allocated : StereotypeInstance { stereotype=SysML::Allocated, extendedMetaclassInstance=M::X } Y_allocated : StereotypeInstance { stereotype=SysML::Allocated, extendedMetaclassInstance=M::Y } allocateXtoY : UML4SysML::Abstraction { client=M-Jack::X_allocated, supplier=M-Jack::Y_allocated } _ : StereotypeInstance { stereotype=SysML::Allocate, extendedMetaclassInstance=M-Jack::allocateXtoY } We need either element or package import relationships for the elements in M-Jack to reference M::X and M::Y. Having made the notion of an applied stereotype explicit in the abstract syntax, we can certainly add the following constraint: A stereotype instance IS for a stereotype S defined in a profile PF and applied to an element E contained in a package P must be contained in the same package that also contains the profile application of PF to P. [PJR] No. Stereotype instances are currently clearly defined as owned by the element to which they are applied not any Package. [NFR] Where is this clearly defined in the spec? The UML 2.3 spec clearly talks about the notion of a .stereotype instance. and of an .instance of a stereotype.. 18.3.3 (Extension): An ExtensionEnd is a navigable ownedEnd, owned by an Extension. This allows a stereotype instance to be attached to an instance of the extended classifier without adding a property to the classifier. 18.3.3 (Stereotype): An instance .S. of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather than generalization/specialization. Relating it to a metaclass .C. from the reference metamodel (typically UML) using an .Extension. (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of .S. (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of .S. are related to .C. model elements (instances of .C.) by links (occurrences of the association/extension from .S. to .C.). Even the example in the spec about the MOF equivalent construction talks about the notion of an instance of a stereotype and linking that instance to the element to which the stereotype is applied. Figure 18.18 shows an example instance model for when the stereotype Clock is applied to a class called StopWatch. The extension between the stereotype and the metaclass results in a link between the instance of stereotype Clock and the (user-defined) class StopWatch. However you raise an interesting issue as to how the different stereotype instances owned by an element (potentially in different extents) can be distinguished or related to a ProfileApplication. Though it would be possible to use MOF capabilities to discover the extent of the different instances and the profile application it would be desirable if UML were more .self contained. in this regard. That would also provide a means for them to be constrained in the manner you suggest . though we should also debate the benefits of such a constraint. [NFR] Let.s come back to this when we have a resolution to discuss. With this constraint, a tool could, for example, prompt the user for which package to put a stereotype instance if in fact there are multiple profile applications in distinct packages. This would allow, for example, Jack and Susie to manage their allocations in their own packages without clobbering each other independently of whether Jack.s and Susie.s packages are serialized separately. [PJR] another approach is for UML tools to work with Workspaces as defined by MOF Facility (and extended by MOF Versioning). So Jack and Susie would have different workspaces each including the shared model and the profile but with their own packages for stereotype instances. Actually MOF Workspaces are designed to be transparent to modeling tools and could be supported by the .environment. e.g. Eclipse [NFR] Due to requirement #9 in clause 18.1.2, this approach could be an informative appendix in the UML or MOF Facility spec. We need a normative solution in the spec, one that existing UML tools should be able to implement easily for their users. As far as whether it is reasonable to do this in 2.4; I.ll draft a resolution for finishing 10826 and we.ll take it from there. Since you seem to be ahead of me w.r.t. 13306, I.ll let you decide whether you want to propose a resolution or not. [PJR] See also one further comment below. - Nicolas. On 12/24/09 3:59 AM, "Dave Hawkins" wrote: I thought Ed submitted http://www.omg.org/issues/uml2-rtf.html#Issue13306 to cover that discussion? The essence of the problem is that the current structure of the metamodel means that you cannot create a valid extension that points to a metaclass. It doesn't matter what id you chose, the typing is wrong because UML::Class != CMOF::Class. [PJR] Agreed. IMHO the problem is in Fig 18.2 which shows a single Class: it should continue to show Stereotype inheriting from UML::Class but ExtensionEnd should be linked to CMOF::Class. [NFR] If you mean that the .metaclass. end of the A_extension_metaclass should be typed by CMOF::Class, then I agree with your comment below. We now have defined URLs for referencing other metamodels, and a reliable UML XMI file, so I don.t see that references to elements in the UML metamodel itself (the CMOF file) should be a problem. That is after all what many tools are already using when serializing models to reference the standard PrimitiveTypes such as Integer. - Nicolas. I've been working on an alternative metamodel for our tool that resolves this issue and allows normal XMI serialization to work. Where profile applications (and stereotype instances for that matter) are stored is separate to that but equally worthy of discussion. However is this really a 2.4 issue? Aren't the changes likely to be fairly significant? Cheers, Dave Rouquette, Nicolas F (316A) wrote: > Steve, > > I had a very productive exchange with Pete about this resolution; I > think I understand his objections and that there is a reasonable > compromise that I can draft into a resolution for Jan. 4. > Then, we can take it from there. > > I haven.t looked into the implications on serialization yet. We > discussed in 2.3 the possibility of serializing applied profiles > separately from the models/packages they are applied to. > However, we kept the .profileApplication. end of association between > Package & ProfileApplication (figure 18.2) as navigable. > > Now that OCL 2.1 clearly states that one can traversing association ends > regardless of their navigability, it would be easy to make > .profileApplication. non-navigable and add an operation to retrieve the > information via OCL. This would incur a small API change but it would > mean that we might be able to serialize applied profiles as separate > resources. Of course, there are details to consider... > > - Nicolas. > > > > On 12/21/09 8:51 AM, "Steve Cook" wrote: > > Nicolas > > You wrote: > >I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > Sounds good to me! I do remember however that when I suggested > some time ago that stereotype instances are in fact instances of > InstanceSpecification, I got quite a lot pushback. I don.t know > what else they might be, though. > > It does mean that we.ll have two ways of serializing > InstanceSpecifications though: the .normal. way and the stereotype way. > > -- Steve > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 17 December 2009 15:33 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Incomplete resolution to 10826 -- Re: Guiding principles > for choosing UML 2.4 Issues > > Steve, > > Issue 10826 was asking for two things: > > 1. what is an applied stereotype, as opposed to the definition of > the stereotype that was applied > 2. what are tag/value pairs, as opposed to the definition of the > stereotype properties that led to the tag/value pairs > > > The resolution for 10826 added the following paragraph: > An instance .S. of Stereotype is a kind of metaclass that extends > other metaclasses through association (Extension) rather > than generalization/specialization. Relating it to a metaclass .C. > from the reference metamodel (typically UML) using an > .Extension. (which is a specific kind of association), signifies > that model elements of type C can be extended by an > instance of .S. (see example in Figure 18.13). At the model level > (such as in Figure 18.18) instances of .S. are related to > .C. model elements (instances of .C.) by links (occurrences of the > association/extension from .S. to .C.). > > > > Up to the last sentence, the paragraph refers to .an instance .S. of > Stereotype. -- i.e., the definition of .S., a stereotype, in a > profile . as illustrated in figure 18.13. > > The last sentence is relevant to question (1) of 10826; however, the > resolution doesn.t actually answer the question . i.e., it doesn.t > explain what .an instance of .S.. actually is. From Figure 18.18, > the notation suggests that .an instance of .S.. is some kind of > instance specification but the resolution doesn.t actually say so > and doesn.t address question (2) of 10826 either. > > I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > - Nicolas. > > > On 12/17/09 2:11 AM, "Steve Cook" wrote: > Nic > > 10826 was resolved in Ballot 6 of 2.3. Please check. > > Regarding circular generalization: isn.t this a MOF thing? Shouldn.t > this actually go into SMOF, whose purpose is better alignment > between MOF and semantic web constructs? > > Thanks > -- Steve > > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 16 December 2009 20:28 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Re: Guiding principles for choosing UML 2.4 Issues > > What about the leftovers of the UML 2.3 RTF? > > Two leftovers are particularly important for other OMG > specifications that depend on the UML spec: SysML and related > efforts including the SysML/QUDV and SysML/Modelica integration. > The two leftovers are: > > 1. applied stereotypes (we had a discussion in issue 13291 but > there is an issue filed, 10826 about this that isn.t in the > UML 2.4 spreadsheet) > 2. navigation up/down classifier hierarchies > > > About (1) -- Applied stereotypes. > > I didn.t find 10826 in the UML 2.4 spreadsheet: > http://www.omg.org/issues/uml2-rtf.html#Issue10826 > This issue is about the lack of a normative abstract syntax for > accessing the stereotypes that are applied to an element: > > Issue 13291 was eventually withdrawn; however, before the discussion > digressed to other topics, Ed provided a concise suggestion > summarizing a discussion between Dave H., Ed S., Jim A. and myself > (01/20/2009): > Moreover, it seems to me that the whole point of pointing stereotypes > specifically to UML metaclasses in UML 2 was so that such stereotypes > were based of the standard UML metamodel. For this to have any real > force in terms of repository representation and interchange, then the > metaclasses referenced should be those with normative IDs in the > normative CMOF representation of the metamodel. Such standard IDs are > lost if each tool is, instead, pointing to its own (non-normative) > representation of the metamodel as a UML L3 model. > > If stereotypes are not going to point to the normative CMOF metaclasses, > then one might as well simplify the stereotype abstract syntax to just > reference the extended the metaclasses by name, as was done in UML 1. > > -- Ed > > I propose to develop a resolution for 10826 and include Ed.s > suggestion above, i.e., reference the extended metaclass by its > normative URI. > > About (2) -- Navigation up/down classifier hierarchies. > > The UML 2.3 RTF report includes the following in the resolution text > of 9374: > This resolution includes an OCL constraint which depends on the OCL > 2.1 revision: > context AssociationClass > self.A_general_classifier::classifier > ->forAll(oclIsKindOf(AssociationClass)) > The meaning of this constraint is as follows: > self.A_general_classifier::classifier > This expression navigates the association A_general_classifier in > the inverse direction of the navigability of the property > /Classifier::general : Classifier[*]. > That is, it provides the set of classifiers that specialize .self.. > > This OCL constraint was editorially removed on the basis that UML > 2.3 was aligned to OCL 2.0, not 2.1. > Since then, OCL 2.1 is available; the constraint could be reinstated > in principle. > However, Maged had suggested instead renaming the association: > A_general_classifier on Classifier to A_general_specific. > Classifer would have, symmetrically, two derived properties for > accessing its general and specific classifiers. > > Besides the two leftovers above, there is a third issue: > > (3) - Relaxing generalization relationships to allow circularities > > In OWL/OWL2, generalization relationships among classes can be > circular . > the semantics here are that all classes in the strongly connected > graph of > generalization relationships are semantically equivalent. > > All CMOF-based metamodels can.t have circular generalization > relationships. > In UML infrastructure, Core::Constructs::Classifier includes a > constraint that > the generalization relationships that a classifier is involved in > must be acyclic. > > I propose to remove this constraint and replace it with a query: > > context Classifier::hasCircularGeneralization() : Boolean > body: = self.general->includes(self) > > It is out of scope of the UML to say whether generalizations should be > acyclic but it is something that could be enforced as an invariant > specified > in a profile (e.g., for OO languages with a strict type hierarchy). > > - Nicolas. > > > On 12/16/09 2:55 AM, "Steve Cook" wrote: > Jim > > I think this is useful for helping to establish the scope for 2.4. > In my mind, in 2.4 we should avoid dealing with issues that can be > dealt with better during simplification (your category 3) and issues > that can be dealt with more easily after simplification (such as > refactoring). > > I don.t think there is any need to avoid fixing OCL in 2.4 in cases > where we find it to be in error. > > Thanks > -- Steve > > *From:* Jim Amsden [mailto:jamsden@us.ibm.com] > *Sent:* 15 December 2009 18:34 > *To:* uml2-rtf@omg.org > *Subject:* Guiding principles for choosing UML 2.4 Issues > > We increased the time window for the UML 2.4 RTF, but its still > short. As you know, IBM's desire was to limit the number of > additional releases on the 2.x stream as these are expensive, have > limited value for our customers, and could delay efforts to > significantly cleanup, simplify, and provide better extensibility > and integration mechanisms for UML. In order to limit releases on > the 2.x stream, we have to address issues that would motivate them. > Ideally the 2.4 RTF would address these issues providing a usable, > stable platform for UML modeling and model interchange. Then the UML > 2.5 specification simplification submission could provide a better > description of that that modeling language is. Taken together, these > two releases could provide a longer-lived modeling platform that > could give us the time we need to develop the next generation of UML > that would hopefully address the issues and opportunities we > identified in the UML Futures RFI responses. > > Maybe we can't achieve this with UML 2.4 and 2.5, and may need to do > 2.6 and beyond to address specific needs. But it may be useful to try. > > The UML 2.4 (or possibly any) RTF is too short to address all the > issues, so we may need some guiding principles to help decide which > issues are critical to achieving a stable UML 2.5 platform, and > therefore which ones will be included in 2.4. Here's a possible > starter set for discussion: > > 1. Include any issue that prevents creation of the merged > metamodel or XMI interchange > 2. Include any show-stopper issues that are preventing the > successful use of UML for common use cases, including some of > the key issues raised by the RFI responses > 3. Avoid simple editorial changes and clarifications that could > be handled by the UML 2.5 specification cleanup submission > 4. Avoid cleanup, refactoring, removal of unintended inheritance, > OCL cleanup or addition of missing constraints, etc. that > although useful, are not critical inhibitors for UML > implementation or use, and may be easier to handle more > effectively in a less constrained release. > > > Do you think this is useful, a good starting point? Any other > suggestions? > > > Jim Amsden, Senior Technical Staff Member > Rational Enterprise Architecture Management > 919-461-3689 > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. Subject: RE: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Date: Mon, 4 Jan 2010 08:00:48 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Index: AcqEkKT7ddJ3FEmrSKm/Bg72EDX0DwAMqit+AACDsAAAEFCwWQABvXlw From: "Pete Rivett" To: "Rouquette, Nicolas F (316A)" , "Dave Hawkins" Cc: "Steve Cook" , "Jim Amsden" , Hi Nicolas, I.ll be briefer this time: · I think you.re taking requirement #9 too seriously . it might have been a goal when we started UML 2 Profiles but what we have now is the specification which may or may not meet that goal . just as we no longer expect the spec to meet the requirements in the original RFP. · Nonetheless it is possible to implement Profiles without full MOF support (e.g. Reflection, Identity). However implementations should be able to provide .MOF equivalent. behavior as explicitly specified in Chapter 18: for example for the serialization as XMI. The emphasis here is .equivalent.: tools may use whatever internal mechanism they like and that fits their architecture. To require a specific implementation or abstract syntax as you suggest would destroy this flexibility. IMHO we already have the right level for what we need and no more, although I would like to see the .MOF equivalent. behavior specified more generally and not just through examples. · UML is a MOF metamodel and MOF concepts are already all over the UML spec (it.s how each metaclass is defined). Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 24 December 2009 18:05 To: Pete Rivett; Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Comments below. On 12/24/09 11:01 AM, "Pete Adaptive" wrote: Some interesting points here . and a number of assumptions which I don.t think are supported by the spec (neither UML nor MOF nor XMI). I think the specs between them (if not eh tools) are already capable of what Nicolas wants: [NFR] Really? Without a first-class abstract syntax concept in the spec for a stereotype instance created as a result of applying a stereotype to an element, I don.t see how a hypothetical tool could explain in terms of the spec how one could do the following: A) apply the same stereotype to the same element multiple times B) manage elements in one resource and stereotypes applied to these elements in a separate resource Of course, a tool could extend the specification and do (A) and (B) in a tool-specific manner. I don.t know if there are any such tools either. the only thing possibly lacking is the ability to associate Stereotype Instances (which BTW are emphatically not UML InstanceSpecifications) with ProfileApplications. Moreover, this association depends on having a first-class concept for a stereotype instance. See below. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 24 December 2009 10:03 To: Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Dave, 13306 is perhaps wishful thinking on my part; however, if you have developed a solution for it; would you consider using it to propose a resolution? The problem I.m after is finishing 10826; in particular, explicitly stating what kind of thing a stereotype instance actually is . i.e., a kind of instance specification whose classifier is the stereotype and that has a link to the stereotyped element where this link is in fact an instance of the Extension association. [PJR] As per our private email thread I don.t agree with this: a stereotype instance is a instance of the pseudo-metaclass defined by the Stereotype definition. [NFR] You are referring to the semantics of a stereotype instance . I agree with you! I.m focusing on how to specify the abstract syntax of a stereotype instance in compliance with requirement #9 of clause 18.1.2: 9. The vast majority of UML case tools should be able to implement Profiles. The design of UML profiles should therefore not constrain these tools to have an internal implementation based on a meta-metamodel/metamodel architecture. At the level of the abstract syntax definition of a stereotype instance, it is clear that we can.t refer to the pseudo-metaclass defined by the stereotype definition. In compliance with the above requirement, this pseudo-metaclass can only exist in the realm of the semantics of stereotypes; not their abstract syntax representation. We have users who are experiencing problems with profiles; these problems are related to several factors: we can apply a profile only once to a package [PJR] in theory there is nothing to require this . though each ProfileApplication is for one Profile, a Package could have many ProfileApplications each for the same Profile. [NFR] In practice, this theoretical flexibility is useless without support at the abstract syntax level to associate a stereotype instance to a specific profile application. currently, the instances of stereotypes applied to elements are serialized in the same resource as the stereotyped elements [PJR] this is by no means required by the specs: [NFR] Clearly the spec can.t require this since it doesn.t specify an abstract syntax for stereotype instances! indeed an original design goal was to allow different stereotype instances to be associated with the same model to create different marked-up models for different purposes and without .disrupting. that model (e.g. one for a database realization another for a Java realization). BTW in OMG language we should refer to .extent. or .store.(as defined by MOF) not .resource.. [NFR] Note that this design goal is beyond the requirements stated in clause 18.1.2. It would be easy to consider a requirement that one must be able to apply a profile to a package in a read-only extent. However, there are two problems: the concept of extent is MOF-specific (10.1, 13.6) and this requirement would violate requirement #9 above MOF doesn.t say anything about what a read-only extent is. Within the limitations of the existing requirements, the best we can do is make a ProfileApplication a kind of PackageableElement. Then, we can state the original design goal in terms of ownership/containment within a package in lieu of MOF extent. According to the spec, (1) and (2)[PJR] not IMHO valid factors . see above imply that the ability to modify an element also includes the ability to add/modify/delete any stereotype applicable to that element; and each stereotype can be applied only once. [PJR] I.m not aware that the specs say anything whatsoever about .ability to modify elements., except that a Property may be flagged as ReadOnly. And AFAIK in the UML metamodel itself there are no such Properties except those which are derived. Furthermore there is no property owned by the stereotyped element to represent the link to the stereotype instance so changing stereotypes does not require changing any property owned by that element. [NFR] Without a first-class abstract syntax concept for a stereotype instance, I don.t know how to explain the problem in terms defined in the spec. We are effectively unable to use configuration management techniques on model resources to address this problem; we have to use some kind of indirection scheme in the model itself. If a tool vendor has a proprietary solution to this, it is most likely non-interoperable with other tools. If we use a custom solution, we then have to build custom tool extensions to deal with this and train users how to use our own customizations. [PJR] You should pressure the vendor to remove restrictions not required by the spec. I don.t see why this should be proprietary. In order to help interoperability any conventions could be agreed and tested through the MIWG. [NFR] The restriction is a practical consequence of how a tool implements the spec. I don.t see how your suggestion helps in the short term. It is very difficult to put pressure on tool vendors to do something differently when the spec talks about the concept of a stereotype instance without defining what it is. Here is a simple example of what we should be able to do. Consider a SysML model, M, with 3 elements: X,Y,Z Consider two users, Jack and Susie, who need to come up with proposals for allocating elements of M. Jack wants to allocate X to Y. Susie wants to allocate X to Z. We should allow Jack to create a resource, M-Jack, that imports M [PJR] I don.t see why .import. is strictly needed where M-Jack contains the application of the <> and <> stereotypes to X and Y. Ditto for Susie. To make this easier for tools to support, we can make ProfileApplication both a DirectedRelationship and a PackageableElement. [PJR] Hmm it is already (at UML 2.3) a DirectedRelationship and owned by Package (though not specifically a PackageableElement though I.m not sure what benefit this would add). [NFR] In UML 2.3, we have: ProfileApplication => DirectedRelationship => Relationship => Element. If a tool implements a ProfileApplication as a non-packageable element, then we cannot access instances of ProfileApplication except via the associations to Package and Profile. But then, two instances of ProfileApplication that have the same profile/package would be indistinguishable from one another. This means that for all practical purposes, we are effectively restricted to being able to apply a given profile to a given package only once. If we make a ProfileApplication a kind of PackageableElement, then we get the ability to distinguish two different instances of ProfileApplication independently of which package and profile are involved. Again, this is of limited value unless we also have a first-class concept for a StereotypeInstance. When you put the two together, then you get something useful at the specification level in a tool-neutral way. Below is a sketch of what this combination would allow us to do in the context of the above example with a model M::{X,Y,Z} where Jack could put the information about his application of the SysML profile to M in a separate package, M-Jack, where, .X is allocated to Y. would entail 4 elements in M-Jack: X_allocated : StereotypeInstance { stereotype=SysML::Allocated, extendedMetaclassInstance=M::X } Y_allocated : StereotypeInstance { stereotype=SysML::Allocated, extendedMetaclassInstance=M::Y } allocateXtoY : UML4SysML::Abstraction { client=M-Jack::X_allocated, supplier=M-Jack::Y_allocated } _ : StereotypeInstance { stereotype=SysML::Allocate, extendedMetaclassInstance=M-Jack::allocateXtoY } We need either element or package import relationships for the elements in M-Jack to reference M::X and M::Y. Having made the notion of an applied stereotype explicit in the abstract syntax, we can certainly add the following constraint: A stereotype instance IS for a stereotype S defined in a profile PF and applied to an element E contained in a package P must be contained in the same package that also contains the profile application of PF to P. [PJR] No. Stereotype instances are currently clearly defined as owned by the element to which they are applied not any Package. [NFR] Where is this clearly defined in the spec? The UML 2.3 spec clearly talks about the notion of a .stereotype instance. and of an .instance of a stereotype.. 18.3.3 (Extension): An ExtensionEnd is a navigable ownedEnd, owned by an Extension. This allows a stereotype instance to be attached to an instance of the extended classifier without adding a property to the classifier. 18.3.3 (Stereotype): An instance .S. of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather than generalization/specialization. Relating it to a metaclass .C. from the reference metamodel (typically UML) using an .Extension. (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of .S. (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of .S. are related to .C. model elements (instances of .C.) by links (occurrences of the association/extension from .S. to .C.). Even the example in the spec about the MOF equivalent construction talks about the notion of an instance of a stereotype and linking that instance to the element to which the stereotype is applied. Figure 18.18 shows an example instance model for when the stereotype Clock is applied to a class called StopWatch. The extension between the stereotype and the metaclass results in a link between the instance of stereotype Clock and the (user-defined) class StopWatch. However you raise an interesting issue as to how the different stereotype instances owned by an element (potentially in different extents) can be distinguished or related to a ProfileApplication. Though it would be possible to use MOF capabilities to discover the extent of the different instances and the profile application it would be desirable if UML were more .self contained. in this regard. That would also provide a means for them to be constrained in the manner you suggest . though we should also debate the benefits of such a constraint. [NFR] Let.s come back to this when we have a resolution to discuss. With this constraint, a tool could, for example, prompt the user for which package to put a stereotype instance if in fact there are multiple profile applications in distinct packages. This would allow, for example, Jack and Susie to manage their allocations in their own packages without clobbering each other independently of whether Jack.s and Susie.s packages are serialized separately. [PJR] another approach is for UML tools to work with Workspaces as defined by MOF Facility (and extended by MOF Versioning). So Jack and Susie would have different workspaces each including the shared model and the profile but with their own packages for stereotype instances. Actually MOF Workspaces are designed to be transparent to modeling tools and could be supported by the .environment. e.g. Eclipse [NFR] Due to requirement #9 in clause 18.1.2, this approach could be an informative appendix in the UML or MOF Facility spec. We need a normative solution in the spec, one that existing UML tools should be able to implement easily for their users. As far as whether it is reasonable to do this in 2.4; I.ll draft a resolution for finishing 10826 and we.ll take it from there. Since you seem to be ahead of me w.r.t. 13306, I.ll let you decide whether you want to propose a resolution or not. [PJR] See also one further comment below. - Nicolas. On 12/24/09 3:59 AM, "Dave Hawkins" wrote: I thought Ed submitted http://www.omg.org/issues/uml2-rtf.html#Issue13306 to cover that discussion? The essence of the problem is that the current structure of the metamodel means that you cannot create a valid extension that points to a metaclass. It doesn't matter what id you chose, the typing is wrong because UML::Class != CMOF::Class. [PJR] Agreed. IMHO the problem is in Fig 18.2 which shows a single Class: it should continue to show Stereotype inheriting from UML::Class but ExtensionEnd should be linked to CMOF::Class. [NFR] If you mean that the .metaclass. end of the A_extension_metaclass should be typed by CMOF::Class, then I agree with your comment below. We now have defined URLs for referencing other metamodels, and a reliable UML XMI file, so I don.t see that references to elements in the UML metamodel itself (the CMOF file) should be a problem. That is after all what many tools are already using when serializing models to reference the standard PrimitiveTypes such as Integer. - Nicolas. I've been working on an alternative metamodel for our tool that resolves this issue and allows normal XMI serialization to work. Where profile applications (and stereotype instances for that matter) are stored is separate to that but equally worthy of discussion. However is this really a 2.4 issue? Aren't the changes likely to be fairly significant? Cheers, Dave Rouquette, Nicolas F (316A) wrote: > Steve, > > I had a very productive exchange with Pete about this resolution; I > think I understand his objections and that there is a reasonable > compromise that I can draft into a resolution for Jan. 4. > Then, we can take it from there. > > I haven.t looked into the implications on serialization yet. We > discussed in 2.3 the possibility of serializing applied profiles > separately from the models/packages they are applied to. > However, we kept the .profileApplication. end of association between > Package & ProfileApplication (figure 18.2) as navigable. > > Now that OCL 2.1 clearly states that one can traversing association ends > regardless of their navigability, it would be easy to make > .profileApplication. non-navigable and add an operation to retrieve the > information via OCL. This would incur a small API change but it would > mean that we might be able to serialize applied profiles as separate > resources. Of course, there are details to consider... > > - Nicolas. > > > > On 12/21/09 8:51 AM, "Steve Cook" wrote: > > Nicolas > > You wrote: > >I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > Sounds good to me! I do remember however that when I suggested > some time ago that stereotype instances are in fact instances of > InstanceSpecification, I got quite a lot pushback. I don.t know > what else they might be, though. > > It does mean that we.ll have two ways of serializing > InstanceSpecifications though: the .normal. way and the stereotype way. > > -- Steve > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 17 December 2009 15:33 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Incomplete resolution to 10826 -- Re: Guiding principles > for choosing UML 2.4 Issues > > Steve, > > Issue 10826 was asking for two things: > > 1. what is an applied stereotype, as opposed to the definition of > the stereotype that was applied > 2. what are tag/value pairs, as opposed to the definition of the > stereotype properties that led to the tag/value pairs > > > The resolution for 10826 added the following paragraph: > An instance .S. of Stereotype is a kind of metaclass that extends > other metaclasses through association (Extension) rather > than generalization/specialization. Relating it to a metaclass .C. > from the reference metamodel (typically UML) using an > .Extension. (which is a specific kind of association), signifies > that model elements of type C can be extended by an > instance of .S. (see example in Figure 18.13). At the model level > (such as in Figure 18.18) instances of .S. are related to > .C. model elements (instances of .C.) by links (occurrences of the > association/extension from .S. to .C.). > > > > Up to the last sentence, the paragraph refers to .an instance .S. of > Stereotype. -- i.e., the definition of .S., a stereotype, in a > profile . as illustrated in figure 18.13. > > The last sentence is relevant to question (1) of 10826; however, the > resolution doesn.t actually answer the question . i.e., it doesn.t > explain what .an instance of .S.. actually is. From Figure 18.18, > the notation suggests that .an instance of .S.. is some kind of > instance specification but the resolution doesn.t actually say so > and doesn.t address question (2) of 10826 either. > > I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > - Nicolas. > > > On 12/17/09 2:11 AM, "Steve Cook" wrote: > Nic > > 10826 was resolved in Ballot 6 of 2.3. Please check. > > Regarding circular generalization: isn.t this a MOF thing? Shouldn.t > this actually go into SMOF, whose purpose is better alignment > between MOF and semantic web constructs? > > Thanks > -- Steve > > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 16 December 2009 20:28 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Re: Guiding principles for choosing UML 2.4 Issues > > What about the leftovers of the UML 2.3 RTF? > > Two leftovers are particularly important for other OMG > specifications that depend on the UML spec: SysML and related > efforts including the SysML/QUDV and SysML/Modelica integration. > The two leftovers are: > > 1. applied stereotypes (we had a discussion in issue 13291 but > there is an issue filed, 10826 about this that isn.t in the > UML 2.4 spreadsheet) > 2. navigation up/down classifier hierarchies > > > About (1) -- Applied stereotypes. > > I didn.t find 10826 in the UML 2.4 spreadsheet: > http://www.omg.org/issues/uml2-rtf.html#Issue10826 > This issue is about the lack of a normative abstract syntax for > accessing the stereotypes that are applied to an element: > > Issue 13291 was eventually withdrawn; however, before the discussion > digressed to other topics, Ed provided a concise suggestion > summarizing a discussion between Dave H., Ed S., Jim A. and myself > (01/20/2009): > Moreover, it seems to me that the whole point of pointing stereotypes > specifically to UML metaclasses in UML 2 was so that such stereotypes > were based of the standard UML metamodel. For this to have any real > force in terms of repository representation and interchange, then the > metaclasses referenced should be those with normative IDs in the > normative CMOF representation of the metamodel. Such standard IDs are > lost if each tool is, instead, pointing to its own (non-normative) > representation of the metamodel as a UML L3 model. > > If stereotypes are not going to point to the normative CMOF metaclasses, > then one might as well simplify the stereotype abstract syntax to just > reference the extended the metaclasses by name, as was done in UML 1. > > -- Ed > > I propose to develop a resolution for 10826 and include Ed.s > suggestion above, i.e., reference the extended metaclass by its > normative URI. > > About (2) -- Navigation up/down classifier hierarchies. > > The UML 2.3 RTF report includes the following in the resolution text > of 9374: > This resolution includes an OCL constraint which depends on the OCL > 2.1 revision: > context AssociationClass > self.A_general_classifier::classifier > ->forAll(oclIsKindOf(AssociationClass)) > The meaning of this constraint is as follows: > self.A_general_classifier::classifier > This expression navigates the association A_general_classifier in > the inverse direction of the navigability of the property > /Classifier::general : Classifier[*]. > That is, it provides the set of classifiers that specialize .self.. > > This OCL constraint was editorially removed on the basis that UML > 2.3 was aligned to OCL 2.0, not 2.1. > Since then, OCL 2.1 is available; the constraint could be reinstated > in principle. > However, Maged had suggested instead renaming the association: > A_general_classifier on Classifier to A_general_specific. > Classifer would have, symmetrically, two derived properties for > accessing its general and specific classifiers. > > Besides the two leftovers above, there is a third issue: > > (3) - Relaxing generalization relationships to allow circularities > > In OWL/OWL2, generalization relationships among classes can be > circular . > the semantics here are that all classes in the strongly connected > graph of > generalization relationships are semantically equivalent. > > All CMOF-based metamodels can.t have circular generalization > relationships. > In UML infrastructure, Core::Constructs::Classifier includes a > constraint that > the generalization relationships that a classifier is involved in > must be acyclic. > > I propose to remove this constraint and replace it with a query: > > context Classifier::hasCircularGeneralization() : Boolean > body: = self.general->includes(self) > > It is out of scope of the UML to say whether generalizations should be > acyclic but it is something that could be enforced as an invariant > specified > in a profile (e.g., for OO languages with a strict type hierarchy). > > - Nicolas. > > > On 12/16/09 2:55 AM, "Steve Cook" wrote: > Jim > > I think this is useful for helping to establish the scope for 2.4. > In my mind, in 2.4 we should avoid dealing with issues that can be > dealt with better during simplification (your category 3) and issues > that can be dealt with more easily after simplification (such as > refactoring). > > I don.t think there is any need to avoid fixing OCL in 2.4 in cases > where we find it to be in error. > > Thanks > -- Steve > > *From:* Jim Amsden [mailto:jamsden@us.ibm.com] > *Sent:* 15 December 2009 18:34 > *To:* uml2-rtf@omg.org > *Subject:* Guiding principles for choosing UML 2.4 Issues > > We increased the time window for the UML 2.4 RTF, but its still > short. As you know, IBM's desire was to limit the number of > additional releases on the 2.x stream as these are expensive, have > limited value for our customers, and could delay efforts to > significantly cleanup, simplify, and provide better extensibility > and integration mechanisms for UML. In order to limit releases on > the 2.x stream, we have to address issues that would motivate them. > Ideally the 2.4 RTF would address these issues providing a usable, > stable platform for UML modeling and model interchange. Then the UML > 2.5 specification simplification submission could provide a better > description of that that modeling language is. Taken together, these > two releases could provide a longer-lived modeling platform that > could give us the time we need to develop the next generation of UML > that would hopefully address the issues and opportunities we > identified in the UML Futures RFI responses. > > Maybe we can't achieve this with UML 2.4 and 2.5, and may need to do > 2.6 and beyond to address specific needs. But it may be useful to try. > > The UML 2.4 (or possibly any) RTF is too short to address all the > issues, so we may need some guiding principles to help decide which > issues are critical to achieving a stable UML 2.5 platform, and > therefore which ones will be included in 2.4. Here's a possible > starter set for discussion: > > 1. Include any issue that prevents creation of the merged > metamodel or XMI interchange > 2. Include any show-stopper issues that are preventing the > successful use of UML for common use cases, including some of > the key issues raised by the RFI responses > 3. Avoid simple editorial changes and clarifications that could > be handled by the UML 2.5 specification cleanup submission > 4. Avoid cleanup, refactoring, removal of unintended inheritance, > OCL cleanup or addition of missing constraints, etc. that > although useful, are not critical inhibitors for UML > implementation or use, and may be easier to handle more > effectively in a less constrained release. > > > Do you think this is useful, a good starting point? Any other > suggestions? > > > Jim Amsden, Senior Technical Staff Member > Rational Enterprise Architecture Management > 919-461-3689 > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: "Rouquette, Nicolas F (316A)" To: Pete Adaptive , Dave Hawkins CC: Steve Cook , Jim Amsden , "uml2-rtf@omg.org" Date: Mon, 4 Jan 2010 11:00:11 -0800 Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Topic: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Index: AcqEkKT7ddJ3FEmrSKm/Bg72EDX0DwAMqit+AACDsAAAEFCwWQABvXlwAhijsH4= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Pete, I.ll be equally brief. The limitations are inherent in the MOF-equivalent construction and in its limitations. 1) the MOF-equivalent construction inherently prevents the application of a stereotype more than once to a given element Fig 18.4 shows .extension_Home. with 0..1 multiplicity, not 0..* We can apply <> to ClientPackage::Client in Fig. 18.9 only once, not twice. 2) the MOF-equivalent construction does not provide a mechanism to retrieve the information about the stereotypes actually applied to a given element. For the MOF-equivalent XMI of Fig 18.9, how can one tell which stereotypes are applied to ClientPackage::Client? Unless a tool has MOF reflection, the best we can do is check for a known stereotype if we have OCL 2.1 support: context Interface::isHomeStereotypeApplied() : boolean = self.extension_Home->notEmpty() 3) Unless a tool has MOF reflection, there is no way to retrieve tag/value pairs for a given application of a stereotype to an element. E.g., how can you retrieve the value of the .magic. tag on ClientPackage::Client . i.e., .1234.? Unless I.m incorrect on these three questions, there is a serious limitation in the current specification of UML profiles that has a significant impact on the development of portable profiles with OCL constraints where such constraints may need to check for whether a stereotype is applied to an element and if so retrieve tag/value pair information about it. - Nicolas. On 1/4/10 8:00 AM, "Pete Adaptive" wrote: Hi Nicolas, I.ll be briefer this time: · I think you.re taking requirement #9 too seriously . it might have been a goal when we started UML 2 Profiles but what we have now is the specification which may or may not meet that goal . just as we no longer expect the spec to meet the requirements in the original RFP. · Nonetheless it is possible to implement Profiles without full MOF support (e.g. Reflection, Identity). However implementations should be able to provide .MOF equivalent. behavior as explicitly specified in Chapter 18: for example for the serialization as XMI. The emphasis here is .equivalent.: tools may use whatever internal mechanism they like and that fits their architecture. To require a specific implementation or abstract syntax as you suggest would destroy this flexibility. IMHO we already have the right level for what we need and no more, although I would like to see the .MOF equivalent. behavior specified more generally and not just through examples. · UML is a MOF metamodel and MOF concepts are already all over the UML spec (it.s how each metaclass is defined). Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 24 December 2009 18:05 To: Pete Rivett; Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Comments below. On 12/24/09 11:01 AM, "Pete Adaptive" wrote: Some interesting points here . and a number of assumptions which I don.t think are supported by the spec (neither UML nor MOF nor XMI). I think the specs between them (if not eh tools) are already capable of what Nicolas wants: [NFR] Really? Without a first-class abstract syntax concept in the spec for a stereotype instance created as a result of applying a stereotype to an element, I don.t see how a hypothetical tool could explain in terms of the spec how one could do the following: A) apply the same stereotype to the same element multiple times B) manage elements in one resource and stereotypes applied to these elements in a separate resource Of course, a tool could extend the specification and do (A) and (B) in a tool-specific manner. I don.t know if there are any such tools either. the only thing possibly lacking is the ability to associate Stereotype Instances (which BTW are emphatically not UML InstanceSpecifications) with ProfileApplications. Moreover, this association depends on having a first-class concept for a stereotype instance. See below. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 24 December 2009 10:03 To: Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Dave, 13306 is perhaps wishful thinking on my part; however, if you have developed a solution for it; would you consider using it to propose a resolution? The problem I.m after is finishing 10826; in particular, explicitly stating what kind of thing a stereotype instance actually is . i.e., a kind of instance specification whose classifier is the stereotype and that has a link to the stereotyped element where this link is in fact an instance of the Extension association. [PJR] As per our private email thread I don.t agree with this: a stereotype instance is a instance of the pseudo-metaclass defined by the Stereotype definition. [NFR] You are referring to the semantics of a stereotype instance . I agree with you! I.m focusing on how to specify the abstract syntax of a stereotype instance in compliance with requirement #9 of clause 18.1.2: 9. The vast majority of UML case tools should be able to implement Profiles. The design of UML profiles should therefore not constrain these tools to have an internal implementation based on a meta-metamodel/metamodel architecture. At the level of the abstract syntax definition of a stereotype instance, it is clear that we can.t refer to the pseudo-metaclass defined by the stereotype definition. In compliance with the above requirement, this pseudo-metaclass can only exist in the realm of the semantics of stereotypes; not their abstract syntax representation. We have users who are experiencing problems with profiles; these problems are related to several factors: we can apply a profile only once to a package [PJR] in theory there is nothing to require this . though each ProfileApplication is for one Profile, a Package could have many ProfileApplications each for the same Profile. [NFR] In practice, this theoretical flexibility is useless without support at the abstract syntax level to associate a stereotype instance to a specific profile application. currently, the instances of stereotypes applied to elements are serialized in the same resource as the stereotyped elements [PJR] this is by no means required by the specs: [NFR] Clearly the spec can.t require this since it doesn.t specify an abstract syntax for stereotype instances! indeed an original design goal was to allow different stereotype instances to be associated with the same model to create different marked-up models for different purposes and without .disrupting. that model (e.g. one for a database realization another for a Java realization). BTW in OMG language we should refer to .extent. or .store.(as defined by MOF) not .resource.. [NFR] Note that this design goal is beyond the requirements stated in clause 18.1.2. It would be easy to consider a requirement that one must be able to apply a profile to a package in a read-only extent. However, there are two problems: the concept of extent is MOF-specific (10.1, 13.6) and this requirement would violate requirement #9 above MOF doesn.t say anything about what a read-only extent is. Within the limitations of the existing requirements, the best we can do is make a ProfileApplication a kind of PackageableElement. Then, we can state the original design goal in terms of ownership/containment within a package in lieu of MOF extent. According to the spec, (1) and (2)[PJR] not IMHO valid factors . see above imply that the ability to modify an element also includes the ability to add/modify/delete any stereotype applicable to that element; and each stereotype can be applied only once. [PJR] I.m not aware that the specs say anything whatsoever about .ability to modify elements., except that a Property may be flagged as ReadOnly. And AFAIK in the UML metamodel itself there are no such Properties except those which are derived. Furthermore there is no property owned by the stereotyped element to represent the link to the stereotype instance so changing stereotypes does not require changing any property owned by that element. [NFR] Without a first-class abstract syntax concept for a stereotype instance, I don.t know how to explain the problem in terms defined in the spec. We are effectively unable to use configuration management techniques on model resources to address this problem; we have to use some kind of indirection scheme in the model itself. If a tool vendor has a proprietary solution to this, it is most likely non-interoperable with other tools. If we use a custom solution, we then have to build custom tool extensions to deal with this and train users how to use our own customizations. [PJR] You should pressure the vendor to remove restrictions not required by the spec. I don.t see why this should be proprietary. In order to help interoperability any conventions could be agreed and tested through the MIWG. [NFR] The restriction is a practical consequence of how a tool implements the spec. I don.t see how your suggestion helps in the short term. It is very difficult to put pressure on tool vendors to do something differently when the spec talks about the concept of a stereotype instance without defining what it is. Here is a simple example of what we should be able to do. Consider a SysML model, M, with 3 elements: X,Y,Z Consider two users, Jack and Susie, who need to come up with proposals for allocating elements of M. Jack wants to allocate X to Y. Susie wants to allocate X to Z. We should allow Jack to create a resource, M-Jack, that imports M [PJR] I don.t see why .import. is strictly needed where M-Jack contains the application of the <> and <> stereotypes to X and Y. Ditto for Susie. To make this easier for tools to support, we can make ProfileApplication both a DirectedRelationship and a PackageableElement. [PJR] Hmm it is already (at UML 2.3) a DirectedRelationship and owned by Package (though not specifically a PackageableElement though I.m not sure what benefit this would add). [NFR] In UML 2.3, we have: ProfileApplication => DirectedRelationship => Relationship => Element. If a tool implements a ProfileApplication as a non-packageable element, then we cannot access instances of ProfileApplication except via the associations to Package and Profile. But then, two instances of ProfileApplication that have the same profile/package would be indistinguishable from one another. This means that for all practical purposes, we are effectively restricted to being able to apply a given profile to a given package only once. If we make a ProfileApplication a kind of PackageableElement, then we get the ability to distinguish two different instances of ProfileApplication independently of which package and profile are involved. Again, this is of limited value unless we also have a first-class concept for a StereotypeInstance. When you put the two together, then you get something useful at the specification level in a tool-neutral way. Below is a sketch of what this combination would allow us to do in the context of the above example with a model M::{X,Y,Z} where Jack could put the information about his application of the SysML profile to M in a separate package, M-Jack, where, .X is allocated to Y. would entail 4 elements in M-Jack: X_allocated : StereotypeInstance { stereotype=SysML::Allocated, extendedMetaclassInstance=M::X } Y_allocated : StereotypeInstance { stereotype=SysML::Allocated, extendedMetaclassInstance=M::Y } allocateXtoY : UML4SysML::Abstraction { client=M-Jack::X_allocated, supplier=M-Jack::Y_allocated } _ : StereotypeInstance { stereotype=SysML::Allocate, extendedMetaclassInstance=M-Jack::allocateXtoY } We need either element or package import relationships for the elements in M-Jack to reference M::X and M::Y. Having made the notion of an applied stereotype explicit in the abstract syntax, we can certainly add the following constraint: A stereotype instance IS for a stereotype S defined in a profile PF and applied to an element E contained in a package P must be contained in the same package that also contains the profile application of PF to P. [PJR] No. Stereotype instances are currently clearly defined as owned by the element to which they are applied not any Package. [NFR] Where is this clearly defined in the spec? The UML 2.3 spec clearly talks about the notion of a .stereotype instance. and of an .instance of a stereotype.. 18.3.3 (Extension): An ExtensionEnd is a navigable ownedEnd, owned by an Extension. This allows a stereotype instance to be attached to an instance of the extended classifier without adding a property to the classifier. 18.3.3 (Stereotype): An instance .S. of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather than generalization/specialization. Relating it to a metaclass .C. from the reference metamodel (typically UML) using an .Extension. (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of .S. (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of .S. are related to .C. model elements (instances of .C.) by links (occurrences of the association/extension from .S. to .C.). Even the example in the spec about the MOF equivalent construction talks about the notion of an instance of a stereotype and linking that instance to the element to which the stereotype is applied. Figure 18.18 shows an example instance model for when the stereotype Clock is applied to a class called StopWatch. The extension between the stereotype and the metaclass results in a link between the instance of stereotype Clock and the (user-defined) class StopWatch. However you raise an interesting issue as to how the different stereotype instances owned by an element (potentially in different extents) can be distinguished or related to a ProfileApplication. Though it would be possible to use MOF capabilities to discover the extent of the different instances and the profile application it would be desirable if UML were more .self contained. in this regard. That would also provide a means for them to be constrained in the manner you suggest . though we should also debate the benefits of such a constraint. [NFR] Let.s come back to this when we have a resolution to discuss. With this constraint, a tool could, for example, prompt the user for which package to put a stereotype instance if in fact there are multiple profile applications in distinct packages. This would allow, for example, Jack and Susie to manage their allocations in their own packages without clobbering each other independently of whether Jack.s and Susie.s packages are serialized separately. [PJR] another approach is for UML tools to work with Workspaces as defined by MOF Facility (and extended by MOF Versioning). So Jack and Susie would have different workspaces each including the shared model and the profile but with their own packages for stereotype instances. Actually MOF Workspaces are designed to be transparent to modeling tools and could be supported by the .environment. e.g. Eclipse [NFR] Due to requirement #9 in clause 18.1.2, this approach could be an informative appendix in the UML or MOF Facility spec. We need a normative solution in the spec, one that existing UML tools should be able to implement easily for their users. As far as whether it is reasonable to do this in 2.4; I.ll draft a resolution for finishing 10826 and we.ll take it from there. Since you seem to be ahead of me w.r.t. 13306, I.ll let you decide whether you want to propose a resolution or not. [PJR] See also one further comment below. - Nicolas. On 12/24/09 3:59 AM, "Dave Hawkins" wrote: I thought Ed submitted http://www.omg.org/issues/uml2-rtf.html#Issue13306 to cover that discussion? The essence of the problem is that the current structure of the metamodel means that you cannot create a valid extension that points to a metaclass. It doesn't matter what id you chose, the typing is wrong because UML::Class != CMOF::Class. [PJR] Agreed. IMHO the problem is in Fig 18.2 which shows a single Class: it should continue to show Stereotype inheriting from UML::Class but ExtensionEnd should be linked to CMOF::Class. [NFR] If you mean that the .metaclass. end of the A_extension_metaclass should be typed by CMOF::Class, then I agree with your comment below. We now have defined URLs for referencing other metamodels, and a reliable UML XMI file, so I don.t see that references to elements in the UML metamodel itself (the CMOF file) should be a problem. That is after all what many tools are already using when serializing models to reference the standard PrimitiveTypes such as Integer. - Nicolas. I've been working on an alternative metamodel for our tool that resolves this issue and allows normal XMI serialization to work. Where profile applications (and stereotype instances for that matter) are stored is separate to that but equally worthy of discussion. However is this really a 2.4 issue? Aren't the changes likely to be fairly significant? Cheers, Dave Rouquette, Nicolas F (316A) wrote: > Steve, > > I had a very productive exchange with Pete about this resolution; I > think I understand his objections and that there is a reasonable > compromise that I can draft into a resolution for Jan. 4. > Then, we can take it from there. > > I haven.t looked into the implications on serialization yet. We > discussed in 2.3 the possibility of serializing applied profiles > separately from the models/packages they are applied to. > However, we kept the .profileApplication. end of association between > Package & ProfileApplication (figure 18.2) as navigable. > > Now that OCL 2.1 clearly states that one can traversing association ends > regardless of their navigability, it would be easy to make > .profileApplication. non-navigable and add an operation to retrieve the > information via OCL. This would incur a small API change but it would > mean that we might be able to serialize applied profiles as separate > resources. Of course, there are details to consider... > > - Nicolas. > > > > On 12/21/09 8:51 AM, "Steve Cook" wrote: > > Nicolas > > You wrote: > >I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > Sounds good to me! I do remember however that when I suggested > some time ago that stereotype instances are in fact instances of > InstanceSpecification, I got quite a lot pushback. I don.t know > what else they might be, though. > > It does mean that we.ll have two ways of serializing > InstanceSpecifications though: the .normal. way and the stereotype way. > > -- Steve > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 17 December 2009 15:33 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Incomplete resolution to 10826 -- Re: Guiding principles > for choosing UML 2.4 Issues > > Steve, > > Issue 10826 was asking for two things: > > 1. what is an applied stereotype, as opposed to the definition of > the stereotype that was applied > 2. what are tag/value pairs, as opposed to the definition of the > stereotype properties that led to the tag/value pairs > > > The resolution for 10826 added the following paragraph: > An instance .S. of Stereotype is a kind of metaclass that extends > other metaclasses through association (Extension) rather > than generalization/specialization. Relating it to a metaclass .C. > from the reference metamodel (typically UML) using an > .Extension. (which is a specific kind of association), signifies > that model elements of type C can be extended by an > instance of .S. (see example in Figure 18.13). At the model level > (such as in Figure 18.18) instances of .S. are related to > .C. model elements (instances of .C.) by links (occurrences of the > association/extension from .S. to .C.). > > > > Up to the last sentence, the paragraph refers to .an instance .S. of > Stereotype. -- i.e., the definition of .S., a stereotype, in a > profile . as illustrated in figure 18.13. > > The last sentence is relevant to question (1) of 10826; however, the > resolution doesn.t actually answer the question . i.e., it doesn.t > explain what .an instance of .S.. actually is. From Figure 18.18, > the notation suggests that .an instance of .S.. is some kind of > instance specification but the resolution doesn.t actually say so > and doesn.t address question (2) of 10826 either. > > I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > - Nicolas. > > > On 12/17/09 2:11 AM, "Steve Cook" wrote: > Nic > > 10826 was resolved in Ballot 6 of 2.3. Please check. > > Regarding circular generalization: isn.t this a MOF thing? Shouldn.t > this actually go into SMOF, whose purpose is better alignment > between MOF and semantic web constructs? > > Thanks > -- Steve > > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 16 December 2009 20:28 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Re: Guiding principles for choosing UML 2.4 Issues > > What about the leftovers of the UML 2.3 RTF? > > Two leftovers are particularly important for other OMG > specifications that depend on the UML spec: SysML and related > efforts including the SysML/QUDV and SysML/Modelica integration. > The two leftovers are: > > 1. applied stereotypes (we had a discussion in issue 13291 but > there is an issue filed, 10826 about this that isn.t in the > UML 2.4 spreadsheet) > 2. navigation up/down classifier hierarchies > > > About (1) -- Applied stereotypes. > > I didn.t find 10826 in the UML 2.4 spreadsheet: > http://www.omg.org/issues/uml2-rtf.html#Issue10826 > This issue is about the lack of a normative abstract syntax for > accessing the stereotypes that are applied to an element: > > Issue 13291 was eventually withdrawn; however, before the discussion > digressed to other topics, Ed provided a concise suggestion > summarizing a discussion between Dave H., Ed S., Jim A. and myself > (01/20/2009): > Moreover, it seems to me that the whole point of pointing stereotypes > specifically to UML metaclasses in UML 2 was so that such stereotypes > were based of the standard UML metamodel. For this to have any real > force in terms of repository representation and interchange, then the > metaclasses referenced should be those with normative IDs in the > normative CMOF representation of the metamodel. Such standard IDs are > lost if each tool is, instead, pointing to its own (non-normative) > representation of the metamodel as a UML L3 model. > > If stereotypes are not going to point to the normative CMOF metaclasses, > then one might as well simplify the stereotype abstract syntax to just > reference the extended the metaclasses by name, as was done in UML 1. > > -- Ed > > I propose to develop a resolution for 10826 and include Ed.s > suggestion above, i.e., reference the extended metaclass by its > normative URI. > > About (2) -- Navigation up/down classifier hierarchies. > > The UML 2.3 RTF report includes the following in the resolution text > of 9374: > This resolution includes an OCL constraint which depends on the OCL > 2.1 revision: > context AssociationClass > self.A_general_classifier::classifier > ->forAll(oclIsKindOf(AssociationClass)) > The meaning of this constraint is as follows: > self.A_general_classifier::classifier > This expression navigates the association A_general_classifier in > the inverse direction of the navigability of the property > /Classifier::general : Classifier[*]. > That is, it provides the set of classifiers that specialize .self.. > > This OCL constraint was editorially removed on the basis that UML > 2.3 was aligned to OCL 2.0, not 2.1. > Since then, OCL 2.1 is available; the constraint could be reinstated > in principle. > However, Maged had suggested instead renaming the association: > A_general_classifier on Classifier to A_general_specific. > Classifer would have, symmetrically, two derived properties for > accessing its general and specific classifiers. > > Besides the two leftovers above, there is a third issue: > > (3) - Relaxing generalization relationships to allow circularities > > In OWL/OWL2, generalization relationships among classes can be > circular . > the semantics here are that all classes in the strongly connected > graph of > generalization relationships are semantically equivalent. > > All CMOF-based metamodels can.t have circular generalization > relationships. > In UML infrastructure, Core::Constructs::Classifier includes a > constraint that > the generalization relationships that a classifier is involved in > must be acyclic. > > I propose to remove this constraint and replace it with a query: > > context Classifier::hasCircularGeneralization() : Boolean > body: = self.general->includes(self) > > It is out of scope of the UML to say whether generalizations should be > acyclic but it is something that could be enforced as an invariant > specified > in a profile (e.g., for OO languages with a strict type hierarchy). > > - Nicolas. > > > On 12/16/09 2:55 AM, "Steve Cook" wrote: > Jim > > I think this is useful for helping to establish the scope for 2.4. > In my mind, in 2.4 we should avoid dealing with issues that can be > dealt with better during simplification (your category 3) and issues > that can be dealt with more easily after simplification (such as > refactoring). > > I don.t think there is any need to avoid fixing OCL in 2.4 in cases > where we find it to be in error. > > Thanks > -- Steve > > *From:* Jim Amsden [mailto:jamsden@us.ibm.com] > *Sent:* 15 December 2009 18:34 > *To:* uml2-rtf@omg.org > *Subject:* Guiding principles for choosing UML 2.4 Issues > > We increased the time window for the UML 2.4 RTF, but its still > short. As you know, IBM's desire was to limit the number of > additional releases on the 2.x stream as these are expensive, have > limited value for our customers, and could delay efforts to > significantly cleanup, simplify, and provide better extensibility > and integration mechanisms for UML. In order to limit releases on > the 2.x stream, we have to address issues that would motivate them. > Ideally the 2.4 RTF would address these issues providing a usable, > stable platform for UML modeling and model interchange. Then the UML > 2.5 specification simplification submission could provide a better > description of that that modeling language is. Taken together, these > two releases could provide a longer-lived modeling platform that > could give us the time we need to develop the next generation of UML > that would hopefully address the issues and opportunities we > identified in the UML Futures RFI responses. > > Maybe we can't achieve this with UML 2.4 and 2.5, and may need to do > 2.6 and beyond to address specific needs. But it may be useful to try. > > The UML 2.4 (or possibly any) RTF is too short to address all the > issues, so we may need some guiding principles to help decide which > issues are critical to achieving a stable UML 2.5 platform, and > therefore which ones will be included in 2.4. Here's a possible > starter set for discussion: > > 1. Include any issue that prevents creation of the merged > metamodel or XMI interchange > 2. Include any show-stopper issues that are preventing the > successful use of UML for common use cases, including some of > the key issues raised by the RFI responses > 3. Avoid simple editorial changes and clarifications that could > be handled by the UML 2.5 specification cleanup submission > 4. Avoid cleanup, refactoring, removal of unintended inheritance, > OCL cleanup or addition of missing constraints, etc. that > although useful, are not critical inhibitors for UML > implementation or use, and may be easier to handle more > effectively in a less constrained release. > > > Do you think this is useful, a good starting point? Any other > suggestions? > > > Jim Amsden, Senior Technical Staff Member > Rational Enterprise Architecture Management > 919-461-3689 > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=hhOMpiKaMWBboZLFu/pCCeiWNTzWpHvhJGidAh+kMNk=; b=fi8Oc3lRsNEmVNfjwC2iPKi4WpUlZjFOt0KjKFqO+wU52o9u3akm6O5bL6mMyjMHhJ 52N96H16DA0qMFB0imxWI6zKpjzOMViZL5rt+UG2B4llxvNE4AGMZ6ZKhfGH5lguwH9v QbkiGh1qbRE0V3UjNSZR33aqoK5e2oDJh7HkU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=GsyRbAeF1xa02q+untfkSTAaCTmz1xXzmz4kki+jCAMXKtjt8tgVPEk39L6tSPZ9RS hBt/Xjsntis1OIr12N55LwiB/lPfptt//in1flcAkBcnQeS4dzJBHVV/vSZybzEqqGgp iDZ+6t0JBqXOz6Adl0XdHa6bXrTeYs2YocnMs= Sender: bran.selic@gmail.com From: Bran Selic Date: Mon, 4 Jan 2010 15:47:50 -0500 X-Google-Sender-Auth: c500383c5a079ec8 Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues To: "Rouquette, Nicolas F (316A)" Cc: Pete Adaptive , Dave Hawkins , Steve Cook , Jim Amsden , "uml2-rtf@omg.org" Nicolas, Some feedback below: On Mon, Jan 4, 2010 at 2:00 PM, Rouquette, Nicolas F (316A) wrote: Pete, I.ll be equally brief. The limitations are inherent in the MOF-equivalent construction and in its limitations. 1) the MOF-equivalent construction inherently prevents the application of a stereotype more than once to a given element Fig 18.4 shows .extension_Home. with 0..1 multiplicity, not 0..* We can apply <> to ClientPackage::Client in Fig. 18.9 only once, not twice. Good point. I can assure you, though, that this was never the inent, but merely an oversight that is simply resolved by changing the upper multiplicity bound from 1 to *. However, I think that Pete is right in saying that this whole thing should be described generally rather than through examples. So, there is some fixing that needs to be done here. 2) the MOF-equivalent construction does not provide a mechanism to retrieve the information about the stereotypes actually applied to a given element. First of all, the reason for the base class not knowing about its stereotypes had to do with the desire to leave the underlying model unaffected when a profile is applied/unapplied. The assumption was that having such knowledge in the base class would somehow "corrupt" it. I am no longer sure this is a valid argument. However, hiding in here is a deeper issue about different use cases for profiles that should, perhaps, be accounted for in any changes that we consider to this whole area. In one case, profiles are used as a kind of recasting capability, that is, to present a "standard" UML model as a different kind of model based possibly on a different paradigm (e.g., a model suitable for schedulability analysis). Since the recasting of the original model is for a particular usually temporary purpose/viewpoint, the notion of applying and unapplying such a profile to the original model makes eminent sense. In the second case, the profile mechanism is used to adapt UML itself (rather than a particular model) to provide a domain-specific language. In those cases, applying and unapplying profiles is meaningless (at least in most cases) and unnecessary. I suspect that when we take these two rather different profile use cases into account, we will have different sets of requirements for profiles and stereotypes and maybe even two different mechanisms. Cheers...Bran Subject: RE: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Date: Mon, 4 Jan 2010 14:34:38 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Index: AcqEkKT7ddJ3FEmrSKm/Bg72EDX0DwAMqit+AACDsAAAEFCwWQABvXlwAhijsH4ABuEhEA== From: "Pete Rivett" To: "Rouquette, Nicolas F (316A)" , "Dave Hawkins" Cc: "Steve Cook" , "Jim Amsden" , Hi Nicolas, Bran already addressed your point 1. Points 2 and 3 both relate to navigating from an element to applied stereotypes. In addition to the OCL syntax you included, one could use the admittedly clumsy (but valid OCL 2.0) construct. context Interface::isHomeStereotypeApplied() : boolean = Home.allInstances()->exists(h | h.base_Interface = self) And having obtained h above you could access its properties in the normal way. Furthermore, one is not required to use MOF Reflection . it would also be possible to use the specific MOF interfaces generated from Associations. That said, we only have such a language binding formally specified for MOF 2.0 to IDL. The Java language binding work was started but not completed. Regards Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 04 January 2010 11:00 To: Pete Rivett; Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Pete, I.ll be equally brief. The limitations are inherent in the MOF-equivalent construction and in its limitations. 1) the MOF-equivalent construction inherently prevents the application of a stereotype more than once to a given element Fig 18.4 shows .extension_Home. with 0..1 multiplicity, not 0..* We can apply <> to ClientPackage::Client in Fig. 18.9 only once, not twice. 2) the MOF-equivalent construction does not provide a mechanism to retrieve the information about the stereotypes actually applied to a given element. For the MOF-equivalent XMI of Fig 18.9, how can one tell which stereotypes are applied to ClientPackage::Client? Unless a tool has MOF reflection, the best we can do is check for a known stereotype if we have OCL 2.1 support: context Interface::isHomeStereotypeApplied() : boolean = self.extension_Home->notEmpty() 3) Unless a tool has MOF reflection, there is no way to retrieve tag/value pairs for a given application of a stereotype to an element. E.g., how can you retrieve the value of the .magic. tag on ClientPackage::Client . i.e., .1234.? Unless I.m incorrect on these three questions, there is a serious limitation in the current specification of UML profiles that has a significant impact on the development of portable profiles with OCL constraints where such constraints may need to check for whether a stereotype is applied to an element and if so retrieve tag/value pair information about it. - Nicolas. On 1/4/10 8:00 AM, "Pete Adaptive" wrote: Hi Nicolas, I.ll be briefer this time: · I think you.re taking requirement #9 too seriously . it might have been a goal when we started UML 2 Profiles but what we have now is the specification which may or may not meet that goal . just as we no longer expect the spec to meet the requirements in the original RFP. · Nonetheless it is possible to implement Profiles without full MOF support (e.g. Reflection, Identity). However implementations should be able to provide .MOF equivalent. behavior as explicitly specified in Chapter 18: for example for the serialization as XMI. The emphasis here is .equivalent.: tools may use whatever internal mechanism they like and that fits their architecture. To require a specific implementation or abstract syntax as you suggest would destroy this flexibility. IMHO we already have the right level for what we need and no more, although I would like to see the .MOF equivalent. behavior specified more generally and not just through examples. · UML is a MOF metamodel and MOF concepts are already all over the UML spec (it.s how each metaclass is defined). Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 24 December 2009 18:05 To: Pete Rivett; Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Comments below. On 12/24/09 11:01 AM, "Pete Adaptive" wrote: Some interesting points here . and a number of assumptions which I don.t think are supported by the spec (neither UML nor MOF nor XMI). I think the specs between them (if not eh tools) are already capable of what Nicolas wants: [NFR] Really? Without a first-class abstract syntax concept in the spec for a stereotype instance created as a result of applying a stereotype to an element, I don.t see how a hypothetical tool could explain in terms of the spec how one could do the following: A) apply the same stereotype to the same element multiple times B) manage elements in one resource and stereotypes applied to these elements in a separate resource Of course, a tool could extend the specification and do (A) and (B) in a tool-specific manner. I don.t know if there are any such tools either. the only thing possibly lacking is the ability to associate Stereotype Instances (which BTW are emphatically not UML InstanceSpecifications) with ProfileApplications. Moreover, this association depends on having a first-class concept for a stereotype instance. See below. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 24 December 2009 10:03 To: Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Dave, 13306 is perhaps wishful thinking on my part; however, if you have developed a solution for it; would you consider using it to propose a resolution? The problem I.m after is finishing 10826; in particular, explicitly stating what kind of thing a stereotype instance actually is . i.e., a kind of instance specification whose classifier is the stereotype and that has a link to the stereotyped element where this link is in fact an instance of the Extension association. [PJR] As per our private email thread I don.t agree with this: a stereotype instance is a instance of the pseudo-metaclass defined by the Stereotype definition. [NFR] You are referring to the semantics of a stereotype instance . I agree with you! I.m focusing on how to specify the abstract syntax of a stereotype instance in compliance with requirement #9 of clause 18.1.2: 9. The vast majority of UML case tools should be able to implement Profiles. The design of UML profiles should therefore not constrain these tools to have an internal implementation based on a meta-metamodel/metamodel architecture. At the level of the abstract syntax definition of a stereotype instance, it is clear that we can.t refer to the pseudo-metaclass defined by the stereotype definition. In compliance with the above requirement, this pseudo-metaclass can only exist in the realm of the semantics of stereotypes; not their abstract syntax representation. We have users who are experiencing problems with profiles; these problems are related to several factors: we can apply a profile only once to a package [PJR] in theory there is nothing to require this . though each ProfileApplication is for one Profile, a Package could have many ProfileApplications each for the same Profile. [NFR] In practice, this theoretical flexibility is useless without support at the abstract syntax level to associate a stereotype instance to a specific profile application. currently, the instances of stereotypes applied to elements are serialized in the same resource as the stereotyped elements [PJR] this is by no means required by the specs: [NFR] Clearly the spec can.t require this since it doesn.t specify an abstract syntax for stereotype instances! indeed an original design goal was to allow different stereotype instances to be associated with the same model to create different marked-up models for different purposes and without .disrupting. that model (e.g. one for a database realization another for a Java realization). BTW in OMG language we should refer to .extent. or .store.(as defined by MOF) not .resource.. [NFR] Note that this design goal is beyond the requirements stated in clause 18.1.2. It would be easy to consider a requirement that one must be able to apply a profile to a package in a read-only extent. However, there are two problems: the concept of extent is MOF-specific (10.1, 13.6) and this requirement would violate requirement #9 above MOF doesn.t say anything about what a read-only extent is. Within the limitations of the existing requirements, the best we can do is make a ProfileApplication a kind of PackageableElement. Then, we can state the original design goal in terms of ownership/containment within a package in lieu of MOF extent. According to the spec, (1) and (2)[PJR] not IMHO valid factors . see above imply that the ability to modify an element also includes the ability to add/modify/delete any stereotype applicable to that element; and each stereotype can be applied only once. [PJR] I.m not aware that the specs say anything whatsoever about .ability to modify elements., except that a Property may be flagged as ReadOnly. And AFAIK in the UML metamodel itself there are no such Properties except those which are derived. Furthermore there is no property owned by the stereotyped element to represent the link to the stereotype instance so changing stereotypes does not require changing any property owned by that element. [NFR] Without a first-class abstract syntax concept for a stereotype instance, I don.t know how to explain the problem in terms defined in the spec. We are effectively unable to use configuration management techniques on model resources to address this problem; we have to use some kind of indirection scheme in the model itself. If a tool vendor has a proprietary solution to this, it is most likely non-interoperable with other tools. If we use a custom solution, we then have to build custom tool extensions to deal with this and train users how to use our own customizations. [PJR] You should pressure the vendor to remove restrictions not required by the spec. I don.t see why this should be proprietary. In order to help interoperability any conventions could be agreed and tested through the MIWG. [NFR] The restriction is a practical consequence of how a tool implements the spec. I don.t see how your suggestion helps in the short term. It is very difficult to put pressure on tool vendors to do something differently when the spec talks about the concept of a stereotype instance without defining what it is. Here is a simple example of what we should be able to do. Consider a SysML model, M, with 3 elements: X,Y,Z Consider two users, Jack and Susie, who need to come up with proposals for allocating elements of M. Jack wants to allocate X to Y. Susie wants to allocate X to Z. We should allow Jack to create a resource, M-Jack, that imports M [PJR] I don.t see why .import. is strictly needed where M-Jack contains the application of the <> and <> stereotypes to X and Y. Ditto for Susie. To make this easier for tools to support, we can make ProfileApplication both a DirectedRelationship and a PackageableElement. [PJR] Hmm it is already (at UML 2.3) a DirectedRelationship and owned by Package (though not specifically a PackageableElement though I.m not sure what benefit this would add). [NFR] In UML 2.3, we have: ProfileApplication => DirectedRelationship => Relationship => Element. If a tool implements a ProfileApplication as a non-packageable element, then we cannot access instances of ProfileApplication except via the associations to Package and Profile. But then, two instances of ProfileApplication that have the same profile/package would be indistinguishable from one another. This means that for all practical purposes, we are effectively restricted to being able to apply a given profile to a given package only once. If we make a ProfileApplication a kind of PackageableElement, then we get the ability to distinguish two different instances of ProfileApplication independently of which package and profile are involved. Again, this is of limited value unless we also have a first-class concept for a StereotypeInstance. When you put the two together, then you get something useful at the specification level in a tool-neutral way. Below is a sketch of what this combination would allow us to do in the context of the above example with a model M::{X,Y,Z} where Jack could put the information about his application of the SysML profile to M in a separate package, M-Jack, where, .X is allocated to Y. would entail 4 elements in M-Jack: X_allocated : StereotypeInstance { stereotype=SysML::Allocated, extendedMetaclassInstance=M::X } Y_allocated : StereotypeInstance { stereotype=SysML::Allocated, extendedMetaclassInstance=M::Y } allocateXtoY : UML4SysML::Abstraction { client=M-Jack::X_allocated, supplier=M-Jack::Y_allocated } _ : StereotypeInstance { stereotype=SysML::Allocate, extendedMetaclassInstance=M-Jack::allocateXtoY } We need either element or package import relationships for the elements in M-Jack to reference M::X and M::Y. Having made the notion of an applied stereotype explicit in the abstract syntax, we can certainly add the following constraint: A stereotype instance IS for a stereotype S defined in a profile PF and applied to an element E contained in a package P must be contained in the same package that also contains the profile application of PF to P. [PJR] No. Stereotype instances are currently clearly defined as owned by the element to which they are applied not any Package. [NFR] Where is this clearly defined in the spec? The UML 2.3 spec clearly talks about the notion of a .stereotype instance. and of an .instance of a stereotype.. 18.3.3 (Extension): An ExtensionEnd is a navigable ownedEnd, owned by an Extension. This allows a stereotype instance to be attached to an instance of the extended classifier without adding a property to the classifier. 18.3.3 (Stereotype): An instance .S. of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather than generalization/specialization. Relating it to a metaclass .C. from the reference metamodel (typically UML) using an .Extension. (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of .S. (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of .S. are related to .C. model elements (instances of .C.) by links (occurrences of the association/extension from .S. to .C.). Even the example in the spec about the MOF equivalent construction talks about the notion of an instance of a stereotype and linking that instance to the element to which the stereotype is applied. Figure 18.18 shows an example instance model for when the stereotype Clock is applied to a class called StopWatch. The extension between the stereotype and the metaclass results in a link between the instance of stereotype Clock and the (user-defined) class StopWatch. However you raise an interesting issue as to how the different stereotype instances owned by an element (potentially in different extents) can be distinguished or related to a ProfileApplication. Though it would be possible to use MOF capabilities to discover the extent of the different instances and the profile application it would be desirable if UML were more .self contained. in this regard. That would also provide a means for them to be constrained in the manner you suggest . though we should also debate the benefits of such a constraint. [NFR] Let.s come back to this when we have a resolution to discuss. With this constraint, a tool could, for example, prompt the user for which package to put a stereotype instance if in fact there are multiple profile applications in distinct packages. This would allow, for example, Jack and Susie to manage their allocations in their own packages without clobbering each other independently of whether Jack.s and Susie.s packages are serialized separately. [PJR] another approach is for UML tools to work with Workspaces as defined by MOF Facility (and extended by MOF Versioning). So Jack and Susie would have different workspaces each including the shared model and the profile but with their own packages for stereotype instances. Actually MOF Workspaces are designed to be transparent to modeling tools and could be supported by the .environment. e.g. Eclipse [NFR] Due to requirement #9 in clause 18.1.2, this approach could be an informative appendix in the UML or MOF Facility spec. We need a normative solution in the spec, one that existing UML tools should be able to implement easily for their users. As far as whether it is reasonable to do this in 2.4; I.ll draft a resolution for finishing 10826 and we.ll take it from there. Since you seem to be ahead of me w.r.t. 13306, I.ll let you decide whether you want to propose a resolution or not. [PJR] See also one further comment below. - Nicolas. On 12/24/09 3:59 AM, "Dave Hawkins" wrote: I thought Ed submitted http://www.omg.org/issues/uml2-rtf.html#Issue13306 to cover that discussion? The essence of the problem is that the current structure of the metamodel means that you cannot create a valid extension that points to a metaclass. It doesn't matter what id you chose, the typing is wrong because UML::Class != CMOF::Class. [PJR] Agreed. IMHO the problem is in Fig 18.2 which shows a single Class: it should continue to show Stereotype inheriting from UML::Class but ExtensionEnd should be linked to CMOF::Class. [NFR] If you mean that the .metaclass. end of the A_extension_metaclass should be typed by CMOF::Class, then I agree with your comment below. We now have defined URLs for referencing other metamodels, and a reliable UML XMI file, so I don.t see that references to elements in the UML metamodel itself (the CMOF file) should be a problem. That is after all what many tools are already using when serializing models to reference the standard PrimitiveTypes such as Integer. - Nicolas. I've been working on an alternative metamodel for our tool that resolves this issue and allows normal XMI serialization to work. Where profile applications (and stereotype instances for that matter) are stored is separate to that but equally worthy of discussion. However is this really a 2.4 issue? Aren't the changes likely to be fairly significant? Cheers, Dave Rouquette, Nicolas F (316A) wrote: > Steve, > > I had a very productive exchange with Pete about this resolution; I > think I understand his objections and that there is a reasonable > compromise that I can draft into a resolution for Jan. 4. > Then, we can take it from there. > > I haven.t looked into the implications on serialization yet. We > discussed in 2.3 the possibility of serializing applied profiles > separately from the models/packages they are applied to. > However, we kept the .profileApplication. end of association between > Package & ProfileApplication (figure 18.2) as navigable. > > Now that OCL 2.1 clearly states that one can traversing association ends > regardless of their navigability, it would be easy to make > .profileApplication. non-navigable and add an operation to retrieve the > information via OCL. This would incur a small API change but it would > mean that we might be able to serialize applied profiles as separate > resources. Of course, there are details to consider... > > - Nicolas. > > > > On 12/21/09 8:51 AM, "Steve Cook" wrote: > > Nicolas > > You wrote: > >I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > Sounds good to me! I do remember however that when I suggested > some time ago that stereotype instances are in fact instances of > InstanceSpecification, I got quite a lot pushback. I don.t know > what else they might be, though. > > It does mean that we.ll have two ways of serializing > InstanceSpecifications though: the .normal. way and the stereotype way. > > -- Steve > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 17 December 2009 15:33 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Incomplete resolution to 10826 -- Re: Guiding principles > for choosing UML 2.4 Issues > > Steve, > > Issue 10826 was asking for two things: > > 1. what is an applied stereotype, as opposed to the definition of > the stereotype that was applied > 2. what are tag/value pairs, as opposed to the definition of the > stereotype properties that led to the tag/value pairs > > > The resolution for 10826 added the following paragraph: > An instance .S. of Stereotype is a kind of metaclass that extends > other metaclasses through association (Extension) rather > than generalization/specialization. Relating it to a metaclass .C. > from the reference metamodel (typically UML) using an > .Extension. (which is a specific kind of association), signifies > that model elements of type C can be extended by an > instance of .S. (see example in Figure 18.13). At the model level > (such as in Figure 18.18) instances of .S. are related to > .C. model elements (instances of .C.) by links (occurrences of the > association/extension from .S. to .C.). > > > > Up to the last sentence, the paragraph refers to .an instance .S. of > Stereotype. -- i.e., the definition of .S., a stereotype, in a > profile . as illustrated in figure 18.13. > > The last sentence is relevant to question (1) of 10826; however, the > resolution doesn.t actually answer the question . i.e., it doesn.t > explain what .an instance of .S.. actually is. From Figure 18.18, > the notation suggests that .an instance of .S.. is some kind of > instance specification but the resolution doesn.t actually say so > and doesn.t address question (2) of 10826 either. > > I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > - Nicolas. > > > On 12/17/09 2:11 AM, "Steve Cook" wrote: > Nic > > 10826 was resolved in Ballot 6 of 2.3. Please check. > > Regarding circular generalization: isn.t this a MOF thing? Shouldn.t > this actually go into SMOF, whose purpose is better alignment > between MOF and semantic web constructs? > > Thanks > -- Steve > > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 16 December 2009 20:28 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Re: Guiding principles for choosing UML 2.4 Issues > > What about the leftovers of the UML 2.3 RTF? > > Two leftovers are particularly important for other OMG > specifications that depend on the UML spec: SysML and related > efforts including the SysML/QUDV and SysML/Modelica integration. > The two leftovers are: > > 1. applied stereotypes (we had a discussion in issue 13291 but > there is an issue filed, 10826 about this that isn.t in the > UML 2.4 spreadsheet) > 2. navigation up/down classifier hierarchies > > > About (1) -- Applied stereotypes. > > I didn.t find 10826 in the UML 2.4 spreadsheet: > http://www.omg.org/issues/uml2-rtf.html#Issue10826 > This issue is about the lack of a normative abstract syntax for > accessing the stereotypes that are applied to an element: > > Issue 13291 was eventually withdrawn; however, before the discussion > digressed to other topics, Ed provided a concise suggestion > summarizing a discussion between Dave H., Ed S., Jim A. and myself > (01/20/2009): > Moreover, it seems to me that the whole point of pointing stereotypes > specifically to UML metaclasses in UML 2 was so that such stereotypes > were based of the standard UML metamodel. For this to have any real > force in terms of repository representation and interchange, then the > metaclasses referenced should be those with normative IDs in the > normative CMOF representation of the metamodel. Such standard IDs are > lost if each tool is, instead, pointing to its own (non-normative) > representation of the metamodel as a UML L3 model. > > If stereotypes are not going to point to the normative CMOF metaclasses, > then one might as well simplify the stereotype abstract syntax to just > reference the extended the metaclasses by name, as was done in UML 1. > > -- Ed > > I propose to develop a resolution for 10826 and include Ed.s > suggestion above, i.e., reference the extended metaclass by its > normative URI. > > About (2) -- Navigation up/down classifier hierarchies. > > The UML 2.3 RTF report includes the following in the resolution text > of 9374: > This resolution includes an OCL constraint which depends on the OCL > 2.1 revision: > context AssociationClass > self.A_general_classifier::classifier > ->forAll(oclIsKindOf(AssociationClass)) > The meaning of this constraint is as follows: > self.A_general_classifier::classifier > This expression navigates the association A_general_classifier in > the inverse direction of the navigability of the property > /Classifier::general : Classifier[*]. > That is, it provides the set of classifiers that specialize .self.. > > This OCL constraint was editorially removed on the basis that UML > 2.3 was aligned to OCL 2.0, not 2.1. > Since then, OCL 2.1 is available; the constraint could be reinstated > in principle. > However, Maged had suggested instead renaming the association: > A_general_classifier on Classifier to A_general_specific. > Classifer would have, symmetrically, two derived properties for > accessing its general and specific classifiers. > > Besides the two leftovers above, there is a third issue: > > (3) - Relaxing generalization relationships to allow circularities > > In OWL/OWL2, generalization relationships among classes can be > circular . > the semantics here are that all classes in the strongly connected > graph of > generalization relationships are semantically equivalent. > > All CMOF-based metamodels can.t have circular generalization > relationships. > In UML infrastructure, Core::Constructs::Classifier includes a > constraint that > the generalization relationships that a classifier is involved in > must be acyclic. > > I propose to remove this constraint and replace it with a query: > > context Classifier::hasCircularGeneralization() : Boolean > body: = self.general->includes(self) > > It is out of scope of the UML to say whether generalizations should be > acyclic but it is something that could be enforced as an invariant > specified > in a profile (e.g., for OO languages with a strict type hierarchy). > > - Nicolas. > > > On 12/16/09 2:55 AM, "Steve Cook" wrote: > Jim > > I think this is useful for helping to establish the scope for 2.4. > In my mind, in 2.4 we should avoid dealing with issues that can be > dealt with better during simplification (your category 3) and issues > that can be dealt with more easily after simplification (such as > refactoring). > > I don.t think there is any need to avoid fixing OCL in 2.4 in cases > where we find it to be in error. > > Thanks > -- Steve > > *From:* Jim Amsden [mailto:jamsden@us.ibm.com] > *Sent:* 15 December 2009 18:34 > *To:* uml2-rtf@omg.org > *Subject:* Guiding principles for choosing UML 2.4 Issues > > We increased the time window for the UML 2.4 RTF, but its still > short. As you know, IBM's desire was to limit the number of > additional releases on the 2.x stream as these are expensive, have > limited value for our customers, and could delay efforts to > significantly cleanup, simplify, and provide better extensibility > and integration mechanisms for UML. In order to limit releases on > the 2.x stream, we have to address issues that would motivate them. > Ideally the 2.4 RTF would address these issues providing a usable, > stable platform for UML modeling and model interchange. Then the UML > 2.5 specification simplification submission could provide a better > description of that that modeling language is. Taken together, these > two releases could provide a longer-lived modeling platform that > could give us the time we need to develop the next generation of UML > that would hopefully address the issues and opportunities we > identified in the UML Futures RFI responses. > > Maybe we can't achieve this with UML 2.4 and 2.5, and may need to do > 2.6 and beyond to address specific needs. But it may be useful to try. > > The UML 2.4 (or possibly any) RTF is too short to address all the > issues, so we may need some guiding principles to help decide which > issues are critical to achieving a stable UML 2.5 platform, and > therefore which ones will be included in 2.4. Here's a possible > starter set for discussion: > > 1. Include any issue that prevents creation of the merged > metamodel or XMI interchange > 2. Include any show-stopper issues that are preventing the > successful use of UML for common use cases, including some of > the key issues raised by the RFI responses > 3. Avoid simple editorial changes and clarifications that could > be handled by the UML 2.5 specification cleanup submission > 4. Avoid cleanup, refactoring, removal of unintended inheritance, > OCL cleanup or addition of missing constraints, etc. that > although useful, are not critical inhibitors for UML > implementation or use, and may be easier to handle more > effectively in a less constrained release. > > > Do you think this is useful, a good starting point? Any other > suggestions? > > > Jim Amsden, Senior Technical Staff Member > Rational Enterprise Architecture Management > 919-461-3689 > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: "Rouquette, Nicolas F (316A)" To: Pete Adaptive , Dave Hawkins CC: Steve Cook , Jim Amsden , "uml2-rtf@omg.org" Date: Mon, 4 Jan 2010 15:32:31 -0800 Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Topic: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Index: AcqEkKT7ddJ3FEmrSKm/Bg72EDX0DwAMqit+AACDsAAAEFCwWQABvXlwAhijsH4ABuEhEAACoblG Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Pete, For #1, we seem to have a consensus about the scope of a resolution for fixing loose ends in Extension (18.3.2): - changing the multiplicity from 1 to * - fixing the name of the role of the extension stereotype, incorrectly stated as: .extension$_.stereotypeName - explicitly stating that the MOF-equivalent construction is normative For #2/#3, the OCL queries are in fact incorrect; someone twisted could have two profiles, P1 and P2 with two stereotypes: P1::Home and P2::Home, both extending Interface. In such case, it would be ambiguous which of P1::Home or P2::Home would be applied to ClientPackage::Client. The MOF-to-IDL mapping spec covers EMOF and CMOF but not Profiles. How would you generate MOF interfaces since a profile is neither a pure metamodel nor a pure model? - Nicolas. On 1/4/10 2:34 PM, "Pete Adaptive" wrote: Hi Nicolas, Bran already addressed your point 1. Points 2 and 3 both relate to navigating from an element to applied stereotypes. In addition to the OCL syntax you included, one could use the admittedly clumsy (but valid OCL 2.0) construct. context Interface::isHomeStereotypeApplied() : boolean = Home.allInstances()->exists(h | h.base_Interface = self) And having obtained h above you could access its properties in the normal way. Furthermore, one is not required to use MOF Reflection . it would also be possible to use the specific MOF interfaces generated from Associations. That said, we only have such a language binding formally specified for MOF 2.0 to IDL. The Java language binding work was started but not completed. Regards Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 04 January 2010 11:00 To: Pete Rivett; Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Pete, I.ll be equally brief. The limitations are inherent in the MOF-equivalent construction and in its limitations. 1) the MOF-equivalent construction inherently prevents the application of a stereotype more than once to a given element Fig 18.4 shows .extension_Home. with 0..1 multiplicity, not 0..* We can apply <> to ClientPackage::Client in Fig. 18.9 only once, not twice. 2) the MOF-equivalent construction does not provide a mechanism to retrieve the information about the stereotypes actually applied to a given element. For the MOF-equivalent XMI of Fig 18.9, how can one tell which stereotypes are applied to ClientPackage::Client? Unless a tool has MOF reflection, the best we can do is check for a known stereotype if we have OCL 2.1 support: context Interface::isHomeStereotypeApplied() : boolean = self.extension_Home->notEmpty() 3) Unless a tool has MOF reflection, there is no way to retrieve tag/value pairs for a given application of a stereotype to an element. E.g., how can you retrieve the value of the .magic. tag on ClientPackage::Client . i.e., .1234.? Unless I.m incorrect on these three questions, there is a serious limitation in the current specification of UML profiles that has a significant impact on the development of portable profiles with OCL constraints where such constraints may need to check for whether a stereotype is applied to an element and if so retrieve tag/value pair information about it. - Nicolas. On 1/4/10 8:00 AM, "Pete Adaptive" wrote: Hi Nicolas, I.ll be briefer this time: · I think you.re taking requirement #9 too seriously . it might have been a goal when we started UML 2 Profiles but what we have now is the specification which may or may not meet that goal . just as we no longer expect the spec to meet the requirements in the original RFP. · Nonetheless it is possible to implement Profiles without full MOF support (e.g. Reflection, Identity). However implementations should be able to provide .MOF equivalent. behavior as explicitly specified in Chapter 18: for example for the serialization as XMI. The emphasis here is .equivalent.: tools may use whatever internal mechanism they like and that fits their architecture. To require a specific implementation or abstract syntax as you suggest would destroy this flexibility. IMHO we already have the right level for what we need and no more, although I would like to see the .MOF equivalent. behavior specified more generally and not just through examples. · UML is a MOF metamodel and MOF concepts are already all over the UML spec (it.s how each metaclass is defined). Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 24 December 2009 18:05 To: Pete Rivett; Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Comments below. On 12/24/09 11:01 AM, "Pete Adaptive" wrote: Some interesting points here . and a number of assumptions which I don.t think are supported by the spec (neither UML nor MOF nor XMI). I think the specs between them (if not eh tools) are already capable of what Nicolas wants: [NFR] Really? Without a first-class abstract syntax concept in the spec for a stereotype instance created as a result of applying a stereotype to an element, I don.t see how a hypothetical tool could explain in terms of the spec how one could do the following: A) apply the same stereotype to the same element multiple times B) manage elements in one resource and stereotypes applied to these elements in a separate resource Of course, a tool could extend the specification and do (A) and (B) in a tool-specific manner. I don.t know if there are any such tools either. the only thing possibly lacking is the ability to associate Stereotype Instances (which BTW are emphatically not UML InstanceSpecifications) with ProfileApplications. Moreover, this association depends on having a first-class concept for a stereotype instance. See below. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 24 December 2009 10:03 To: Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Dave, 13306 is perhaps wishful thinking on my part; however, if you have developed a solution for it; would you consider using it to propose a resolution? The problem I.m after is finishing 10826; in particular, explicitly stating what kind of thing a stereotype instance actually is . i.e., a kind of instance specification whose classifier is the stereotype and that has a link to the stereotyped element where this link is in fact an instance of the Extension association. [PJR] As per our private email thread I don.t agree with this: a stereotype instance is a instance of the pseudo-metaclass defined by the Stereotype definition. [NFR] You are referring to the semantics of a stereotype instance . I agree with you! I.m focusing on how to specify the abstract syntax of a stereotype instance in compliance with requirement #9 of clause 18.1.2: 9. The vast majority of UML case tools should be able to implement Profiles. The design of UML profiles should therefore not constrain these tools to have an internal implementation based on a meta-metamodel/metamodel architecture. At the level of the abstract syntax definition of a stereotype instance, it is clear that we can.t refer to the pseudo-metaclass defined by the stereotype definition. In compliance with the above requirement, this pseudo-metaclass can only exist in the realm of the semantics of stereotypes; not their abstract syntax representation. We have users who are experiencing problems with profiles; these problems are related to several factors: we can apply a profile only once to a package [PJR] in theory there is nothing to require this . though each ProfileApplication is for one Profile, a Package could have many ProfileApplications each for the same Profile. [NFR] In practice, this theoretical flexibility is useless without support at the abstract syntax level to associate a stereotype instance to a specific profile application. currently, the instances of stereotypes applied to elements are serialized in the same resource as the stereotyped elements [PJR] this is by no means required by the specs: [NFR] Clearly the spec can.t require this since it doesn.t specify an abstract syntax for stereotype instances! indeed an original design goal was to allow different stereotype instances to be associated with the same model to create different marked-up models for different purposes and without .disrupting. that model (e.g. one for a database realization another for a Java realization). BTW in OMG language we should refer to .extent. or .store.(as defined by MOF) not .resource.. [NFR] Note that this design goal is beyond the requirements stated in clause 18.1.2. It would be easy to consider a requirement that one must be able to apply a profile to a package in a read-only extent. However, there are two problems: the concept of extent is MOF-specific (10.1, 13.6) and this requirement would violate requirement #9 above MOF doesn.t say anything about what a read-only extent is. Within the limitations of the existing requirements, the best we can do is make a ProfileApplication a kind of PackageableElement. Then, we can state the original design goal in terms of ownership/containment within a package in lieu of MOF extent. According to the spec, (1) and (2)[PJR] not IMHO valid factors . see above imply that the ability to modify an element also includes the ability to add/modify/delete any stereotype applicable to that element; and each stereotype can be applied only once. [PJR] I.m not aware that the specs say anything whatsoever about .ability to modify elements., except that a Property may be flagged as ReadOnly. And AFAIK in the UML metamodel itself there are no such Properties except those which are derived. Furthermore there is no property owned by the stereotyped element to represent the link to the stereotype instance so changing stereotypes does not require changing any property owned by that element. [NFR] Without a first-class abstract syntax concept for a stereotype instance, I don.t know how to explain the problem in terms defined in the spec. We are effectively unable to use configuration management techniques on model resources to address this problem; we have to use some kind of indirection scheme in the model itself. If a tool vendor has a proprietary solution to this, it is most likely non-interoperable with other tools. If we use a custom solution, we then have to build custom tool extensions to deal with this and train users how to use our own customizations. [PJR] You should pressure the vendor to remove restrictions not required by the spec. I don.t see why this should be proprietary. In order to help interoperability any conventions could be agreed and tested through the MIWG. [NFR] The restriction is a practical consequence of how a tool implements the spec. I don.t see how your suggestion helps in the short term. It is very difficult to put pressure on tool vendors to do something differently when the spec talks about the concept of a stereotype instance without defining what it is. Here is a simple example of what we should be able to do. Consider a SysML model, M, with 3 elements: X,Y,Z Consider two users, Jack and Susie, who need to come up with proposals for allocating elements of M. Jack wants to allocate X to Y. Susie wants to allocate X to Z. We should allow Jack to create a resource, M-Jack, that imports M [PJR] I don.t see why .import. is strictly needed where M-Jack contains the application of the <> and <> stereotypes to X and Y. Ditto for Susie. To make this easier for tools to support, we can make ProfileApplication both a DirectedRelationship and a PackageableElement. [PJR] Hmm it is already (at UML 2.3) a DirectedRelationship and owned by Package (though not specifically a PackageableElement though I.m not sure what benefit this would add). [NFR] In UML 2.3, we have: ProfileApplication => DirectedRelationship => Relationship => Element. If a tool implements a ProfileApplication as a non-packageable element, then we cannot access instances of ProfileApplication except via the associations to Package and Profile. But then, two instances of ProfileApplication that have the same profile/package would be indistinguishable from one another. This means that for all practical purposes, we are effectively restricted to being able to apply a given profile to a given package only once. If we make a ProfileApplication a kind of PackageableElement, then we get the ability to distinguish two different instances of ProfileApplication independently of which package and profile are involved. Again, this is of limited value unless we also have a first-class concept for a StereotypeInstance. When you put the two together, then you get something useful at the specification level in a tool-neutral way. Below is a sketch of what this combination would allow us to do in the context of the above example with a model M::{X,Y,Z} where Jack could put the information about his application of the SysML profile to M in a separate package, M-Jack, where, .X is allocated to Y. would entail 4 elements in M-Jack: X_allocated : StereotypeInstance { stereotype=SysML::Allocated, extendedMetaclassInstance=M::X } Y_allocated : StereotypeInstance { stereotype=SysML::Allocated, extendedMetaclassInstance=M::Y } allocateXtoY : UML4SysML::Abstraction { client=M-Jack::X_allocated, supplier=M-Jack::Y_allocated } _ : StereotypeInstance { stereotype=SysML::Allocate, extendedMetaclassInstance=M-Jack::allocateXtoY } We need either element or package import relationships for the elements in M-Jack to reference M::X and M::Y. Having made the notion of an applied stereotype explicit in the abstract syntax, we can certainly add the following constraint: A stereotype instance IS for a stereotype S defined in a profile PF and applied to an element E contained in a package P must be contained in the same package that also contains the profile application of PF to P. [PJR] No. Stereotype instances are currently clearly defined as owned by the element to which they are applied not any Package. [NFR] Where is this clearly defined in the spec? The UML 2.3 spec clearly talks about the notion of a .stereotype instance. and of an .instance of a stereotype.. 18.3.3 (Extension): An ExtensionEnd is a navigable ownedEnd, owned by an Extension. This allows a stereotype instance to be attached to an instance of the extended classifier without adding a property to the classifier. 18.3.3 (Stereotype): An instance .S. of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather than generalization/specialization. Relating it to a metaclass .C. from the reference metamodel (typically UML) using an .Extension. (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of .S. (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of .S. are related to .C. model elements (instances of .C.) by links (occurrences of the association/extension from .S. to .C.). Even the example in the spec about the MOF equivalent construction talks about the notion of an instance of a stereotype and linking that instance to the element to which the stereotype is applied. Figure 18.18 shows an example instance model for when the stereotype Clock is applied to a class called StopWatch. The extension between the stereotype and the metaclass results in a link between the instance of stereotype Clock and the (user-defined) class StopWatch. However you raise an interesting issue as to how the different stereotype instances owned by an element (potentially in different extents) can be distinguished or related to a ProfileApplication. Though it would be possible to use MOF capabilities to discover the extent of the different instances and the profile application it would be desirable if UML were more .self contained. in this regard. That would also provide a means for them to be constrained in the manner you suggest . though we should also debate the benefits of such a constraint. [NFR] Let.s come back to this when we have a resolution to discuss. With this constraint, a tool could, for example, prompt the user for which package to put a stereotype instance if in fact there are multiple profile applications in distinct packages. This would allow, for example, Jack and Susie to manage their allocations in their own packages without clobbering each other independently of whether Jack.s and Susie.s packages are serialized separately. [PJR] another approach is for UML tools to work with Workspaces as defined by MOF Facility (and extended by MOF Versioning). So Jack and Susie would have different workspaces each including the shared model and the profile but with their own packages for stereotype instances. Actually MOF Workspaces are designed to be transparent to modeling tools and could be supported by the .environment. e.g. Eclipse [NFR] Due to requirement #9 in clause 18.1.2, this approach could be an informative appendix in the UML or MOF Facility spec. We need a normative solution in the spec, one that existing UML tools should be able to implement easily for their users. As far as whether it is reasonable to do this in 2.4; I.ll draft a resolution for finishing 10826 and we.ll take it from there. Since you seem to be ahead of me w.r.t. 13306, I.ll let you decide whether you want to propose a resolution or not. [PJR] See also one further comment below. - Nicolas. On 12/24/09 3:59 AM, "Dave Hawkins" wrote: I thought Ed submitted http://www.omg.org/issues/uml2-rtf.html#Issue13306 to cover that discussion? The essence of the problem is that the current structure of the metamodel means that you cannot create a valid extension that points to a metaclass. It doesn't matter what id you chose, the typing is wrong because UML::Class != CMOF::Class. [PJR] Agreed. IMHO the problem is in Fig 18.2 which shows a single Class: it should continue to show Stereotype inheriting from UML::Class but ExtensionEnd should be linked to CMOF::Class. [NFR] If you mean that the .metaclass. end of the A_extension_metaclass should be typed by CMOF::Class, then I agree with your comment below. We now have defined URLs for referencing other metamodels, and a reliable UML XMI file, so I don.t see that references to elements in the UML metamodel itself (the CMOF file) should be a problem. That is after all what many tools are already using when serializing models to reference the standard PrimitiveTypes such as Integer. - Nicolas. I've been working on an alternative metamodel for our tool that resolves this issue and allows normal XMI serialization to work. Where profile applications (and stereotype instances for that matter) are stored is separate to that but equally worthy of discussion. However is this really a 2.4 issue? Aren't the changes likely to be fairly significant? Cheers, Dave Rouquette, Nicolas F (316A) wrote: > Steve, > > I had a very productive exchange with Pete about this resolution; I > think I understand his objections and that there is a reasonable > compromise that I can draft into a resolution for Jan. 4. > Then, we can take it from there. > > I haven.t looked into the implications on serialization yet. We > discussed in 2.3 the possibility of serializing applied profiles > separately from the models/packages they are applied to. > However, we kept the .profileApplication. end of association between > Package & ProfileApplication (figure 18.2) as navigable. > > Now that OCL 2.1 clearly states that one can traversing association ends > regardless of their navigability, it would be easy to make > .profileApplication. non-navigable and add an operation to retrieve the > information via OCL. This would incur a small API change but it would > mean that we might be able to serialize applied profiles as separate > resources. Of course, there are details to consider... > > - Nicolas. > > > > On 12/21/09 8:51 AM, "Steve Cook" wrote: > > Nicolas > > You wrote: > >I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > Sounds good to me! I do remember however that when I suggested > some time ago that stereotype instances are in fact instances of > InstanceSpecification, I got quite a lot pushback. I don.t know > what else they might be, though. > > It does mean that we.ll have two ways of serializing > InstanceSpecifications though: the .normal. way and the stereotype way. > > -- Steve > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 17 December 2009 15:33 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Incomplete resolution to 10826 -- Re: Guiding principles > for choosing UML 2.4 Issues > > Steve, > > Issue 10826 was asking for two things: > > 1. what is an applied stereotype, as opposed to the definition of > the stereotype that was applied > 2. what are tag/value pairs, as opposed to the definition of the > stereotype properties that led to the tag/value pairs > > > The resolution for 10826 added the following paragraph: > An instance .S. of Stereotype is a kind of metaclass that extends > other metaclasses through association (Extension) rather > than generalization/specialization. Relating it to a metaclass .C. > from the reference metamodel (typically UML) using an > .Extension. (which is a specific kind of association), signifies > that model elements of type C can be extended by an > instance of .S. (see example in Figure 18.13). At the model level > (such as in Figure 18.18) instances of .S. are related to > .C. model elements (instances of .C.) by links (occurrences of the > association/extension from .S. to .C.). > > > > Up to the last sentence, the paragraph refers to .an instance .S. of > Stereotype. -- i.e., the definition of .S., a stereotype, in a > profile . as illustrated in figure 18.13. > > The last sentence is relevant to question (1) of 10826; however, the > resolution doesn.t actually answer the question . i.e., it doesn.t > explain what .an instance of .S.. actually is. From Figure 18.18, > the notation suggests that .an instance of .S.. is some kind of > instance specification but the resolution doesn.t actually say so > and doesn.t address question (2) of 10826 either. > > I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > - Nicolas. > > > On 12/17/09 2:11 AM, "Steve Cook" wrote: > Nic > > 10826 was resolved in Ballot 6 of 2.3. Please check. > > Regarding circular generalization: isn.t this a MOF thing? Shouldn.t > this actually go into SMOF, whose purpose is better alignment > between MOF and semantic web constructs? > > Thanks > -- Steve > > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 16 December 2009 20:28 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Re: Guiding principles for choosing UML 2.4 Issues > > What about the leftovers of the UML 2.3 RTF? > > Two leftovers are particularly important for other OMG > specifications that depend on the UML spec: SysML and related > efforts including the SysML/QUDV and SysML/Modelica integration. > The two leftovers are: > > 1. applied stereotypes (we had a discussion in issue 13291 but > there is an issue filed, 10826 about this that isn.t in the > UML 2.4 spreadsheet) > 2. navigation up/down classifier hierarchies > > > About (1) -- Applied stereotypes. > > I didn.t find 10826 in the UML 2.4 spreadsheet: > http://www.omg.org/issues/uml2-rtf.html#Issue10826 > This issue is about the lack of a normative abstract syntax for > accessing the stereotypes that are applied to an element: > > Issue 13291 was eventually withdrawn; however, before the discussion > digressed to other topics, Ed provided a concise suggestion > summarizing a discussion between Dave H., Ed S., Jim A. and myself > (01/20/2009): > Moreover, it seems to me that the whole point of pointing stereotypes > specifically to UML metaclasses in UML 2 was so that such stereotypes > were based of the standard UML metamodel. For this to have any real > force in terms of repository representation and interchange, then the > metaclasses referenced should be those with normative IDs in the > normative CMOF representation of the metamodel. Such standard IDs are > lost if each tool is, instead, pointing to its own (non-normative) > representation of the metamodel as a UML L3 model. > > If stereotypes are not going to point to the normative CMOF metaclasses, > then one might as well simplify the stereotype abstract syntax to just > reference the extended the metaclasses by name, as was done in UML 1. > > -- Ed > > I propose to develop a resolution for 10826 and include Ed.s > suggestion above, i.e., reference the extended metaclass by its > normative URI. > > About (2) -- Navigation up/down classifier hierarchies. > > The UML 2.3 RTF report includes the following in the resolution text > of 9374: > This resolution includes an OCL constraint which depends on the OCL > 2.1 revision: > context AssociationClass > self.A_general_classifier::classifier > ->forAll(oclIsKindOf(AssociationClass)) > The meaning of this constraint is as follows: > self.A_general_classifier::classifier > This expression navigates the association A_general_classifier in > the inverse direction of the navigability of the property > /Classifier::general : Classifier[*]. > That is, it provides the set of classifiers that specialize .self.. > > This OCL constraint was editorially removed on the basis that UML > 2.3 was aligned to OCL 2.0, not 2.1. > Since then, OCL 2.1 is available; the constraint could be reinstated > in principle. > However, Maged had suggested instead renaming the association: > A_general_classifier on Classifier to A_general_specific. > Classifer would have, symmetrically, two derived properties for > accessing its general and specific classifiers. > > Besides the two leftovers above, there is a third issue: > > (3) - Relaxing generalization relationships to allow circularities > > In OWL/OWL2, generalization relationships among classes can be > circular . > the semantics here are that all classes in the strongly connected > graph of > generalization relationships are semantically equivalent. > > All CMOF-based metamodels can.t have circular generalization > relationships. > In UML infrastructure, Core::Constructs::Classifier includes a > constraint that > the generalization relationships that a classifier is involved in > must be acyclic. > > I propose to remove this constraint and replace it with a query: > > context Classifier::hasCircularGeneralization() : Boolean > body: = self.general->includes(self) > > It is out of scope of the UML to say whether generalizations should be > acyclic but it is something that could be enforced as an invariant > specified > in a profile (e.g., for OO languages with a strict type hierarchy). > > - Nicolas. > > > On 12/16/09 2:55 AM, "Steve Cook" wrote: > Jim > > I think this is useful for helping to establish the scope for 2.4. > In my mind, in 2.4 we should avoid dealing with issues that can be > dealt with better during simplification (your category 3) and issues > that can be dealt with more easily after simplification (such as > refactoring). > > I don.t think there is any need to avoid fixing OCL in 2.4 in cases > where we find it to be in error. > > Thanks > -- Steve > > *From:* Jim Amsden [mailto:jamsden@us.ibm.com] > *Sent:* 15 December 2009 18:34 > *To:* uml2-rtf@omg.org > *Subject:* Guiding principles for choosing UML 2.4 Issues > > We increased the time window for the UML 2.4 RTF, but its still > short. As you know, IBM's desire was to limit the number of > additional releases on the 2.x stream as these are expensive, have > limited value for our customers, and could delay efforts to > significantly cleanup, simplify, and provide better extensibility > and integration mechanisms for UML. In order to limit releases on > the 2.x stream, we have to address issues that would motivate them. > Ideally the 2.4 RTF would address these issues providing a usable, > stable platform for UML modeling and model interchange. Then the UML > 2.5 specification simplification submission could provide a better > description of that that modeling language is. Taken together, these > two releases could provide a longer-lived modeling platform that > could give us the time we need to develop the next generation of UML > that would hopefully address the issues and opportunities we > identified in the UML Futures RFI responses. > > Maybe we can't achieve this with UML 2.4 and 2.5, and may need to do > 2.6 and beyond to address specific needs. But it may be useful to try. > > The UML 2.4 (or possibly any) RTF is too short to address all the > issues, so we may need some guiding principles to help decide which > issues are critical to achieving a stable UML 2.5 platform, and > therefore which ones will be included in 2.4. Here's a possible > starter set for discussion: > > 1. Include any issue that prevents creation of the merged > metamodel or XMI interchange > 2. Include any show-stopper issues that are preventing the > successful use of UML for common use cases, including some of > the key issues raised by the RFI responses > 3. Avoid simple editorial changes and clarifications that could > be handled by the UML 2.5 specification cleanup submission > 4. Avoid cleanup, refactoring, removal of unintended inheritance, > OCL cleanup or addition of missing constraints, etc. that > although useful, are not critical inhibitors for UML > implementation or use, and may be easier to handle more > effectively in a less constrained release. > > > Do you think this is useful, a good starting point? Any other > suggestions? > > > Jim Amsden, Senior Technical Staff Member > Rational Enterprise Architecture Management > 919-461-3689 > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: Salman Qadri To: "Rouquette, Nicolas F (316A)" , Pete Adaptive , Dave Hawkins CC: Steve Cook , Jim Amsden , "uml2-rtf@omg.org" Date: Tue, 5 Jan 2010 10:28:02 -0500 Subject: RE: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Topic: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Thread-Index: AcqEkKT7ddJ3FEmrSKm/Bg72EDX0DwAMqit+AACDsAAAEFCwWQABvXlwAhijsH4AKttUwA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US +1 From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, January 04, 2010 2:00 PM To: Pete Adaptive; Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Pete, I.ll be equally brief. The limitations are inherent in the MOF-equivalent construction and in its limitations. 1) the MOF-equivalent construction inherently prevents the application of a stereotype more than once to a given element Fig 18.4 shows .extension_Home. with 0..1 multiplicity, not 0..* We can apply <> to ClientPackage::Client in Fig. 18.9 only once, not twice. 2) the MOF-equivalent construction does not provide a mechanism to retrieve the information about the stereotypes actually applied to a given element. For the MOF-equivalent XMI of Fig 18.9, how can one tell which stereotypes are applied to ClientPackage::Client? Unless a tool has MOF reflection, the best we can do is check for a known stereotype if we have OCL 2.1 support: context Interface::isHomeStereotypeApplied() : boolean = self.extension_Home->notEmpty() 3) Unless a tool has MOF reflection, there is no way to retrieve tag/value pairs for a given application of a stereotype to an element. E.g., how can you retrieve the value of the .magic. tag on ClientPackage::Client . i.e., .1234.? Unless I.m incorrect on these three questions, there is a serious limitation in the current specification of UML profiles that has a significant impact on the development of portable profiles with OCL constraints where such constraints may need to check for whether a stereotype is applied to an element and if so retrieve tag/value pair information about it. - Nicolas. On 1/4/10 8:00 AM, "Pete Adaptive" wrote: Hi Nicolas, I.ll be briefer this time: · I think you.re taking requirement #9 too seriously . it might have been a goal when we started UML 2 Profiles but what we have now is the specification which may or may not meet that goal . just as we no longer expect the spec to meet the requirements in the original RFP. · Nonetheless it is possible to implement Profiles without full MOF support (e.g. Reflection, Identity). However implementations should be able to provide .MOF equivalent. behavior as explicitly specified in Chapter 18: for example for the serialization as XMI. The emphasis here is .equivalent.: tools may use whatever internal mechanism they like and that fits their architecture. To require a specific implementation or abstract syntax as you suggest would destroy this flexibility. IMHO we already have the right level for what we need and no more, although I would like to see the .MOF equivalent. behavior specified more generally and not just through examples. · UML is a MOF metamodel and MOF concepts are already all over the UML spec (it.s how each metaclass is defined). Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 24 December 2009 18:05 To: Pete Rivett; Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Comments below. On 12/24/09 11:01 AM, "Pete Adaptive" wrote: Some interesting points here . and a number of assumptions which I don.t think are supported by the spec (neither UML nor MOF nor XMI). I think the specs between them (if not eh tools) are already capable of what Nicolas wants: [NFR] Really? Without a first-class abstract syntax concept in the spec for a stereotype instance created as a result of applying a stereotype to an element, I don.t see how a hypothetical tool could explain in terms of the spec how one could do the following: A) apply the same stereotype to the same element multiple times B) manage elements in one resource and stereotypes applied to these elements in a separate resource Of course, a tool could extend the specification and do (A) and (B) in a tool-specific manner. I don.t know if there are any such tools either. the only thing possibly lacking is the ability to associate Stereotype Instances (which BTW are emphatically not UML InstanceSpecifications) with ProfileApplications. Moreover, this association depends on having a first-class concept for a stereotype instance. See below. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 24 December 2009 10:03 To: Dave Hawkins Cc: Steve Cook; Jim Amsden; uml2-rtf@omg.org Subject: Re: Incomplete resolution to 10826 -- Re: Guiding principles for choosing UML 2.4 Issues Dave, 13306 is perhaps wishful thinking on my part; however, if you have developed a solution for it; would you consider using it to propose a resolution? The problem I.m after is finishing 10826; in particular, explicitly stating what kind of thing a stereotype instance actually is . i.e., a kind of instance specification whose classifier is the stereotype and that has a link to the stereotyped element where this link is in fact an instance of the Extension association. [PJR] As per our private email thread I don.t agree with this: a stereotype instance is a instance of the pseudo-metaclass defined by the Stereotype definition. [NFR] You are referring to the semantics of a stereotype instance . I agree with you! I.m focusing on how to specify the abstract syntax of a stereotype instance in compliance with requirement #9 of clause 18.1.2: 9. The vast majority of UML case tools should be able to implement Profiles. The design of UML profiles should therefore not constrain these tools to have an internal implementation based on a meta-metamodel/metamodel architecture. At the level of the abstract syntax definition of a stereotype instance, it is clear that we can.t refer to the pseudo-metaclass defined by the stereotype definition. In compliance with the above requirement, this pseudo-metaclass can only exist in the realm of the semantics of stereotypes; not their abstract syntax representation. We have users who are experiencing problems with profiles; these problems are related to several factors: we can apply a profile only once to a package [PJR] in theory there is nothing to require this . though each ProfileApplication is for one Profile, a Package could have many ProfileApplications each for the same Profile. [NFR] In practice, this theoretical flexibility is useless without support at the abstract syntax level to associate a stereotype instance to a specific profile application. currently, the instances of stereotypes applied to elements are serialized in the same resource as the stereotyped elements [PJR] this is by no means required by the specs: [NFR] Clearly the spec can.t require this since it doesn.t specify an abstract syntax for stereotype instances! indeed an original design goal was to allow different stereotype instances to be associated with the same model to create different marked-up models for different purposes and without .disrupting. that model (e.g. one for a database realization another for a Java realization). BTW in OMG language we should refer to .extent. or .store.(as defined by MOF) not .resource.. [NFR] Note that this design goal is beyond the requirements stated in clause 18.1.2. It would be easy to consider a requirement that one must be able to apply a profile to a package in a read-only extent. However, there are two problems: the concept of extent is MOF-specific (10.1, 13.6) and this requirement would violate requirement #9 above MOF doesn.t say anything about what a read-only extent is. Within the limitations of the existing requirements, the best we can do is make a ProfileApplication a kind of PackageableElement. Then, we can state the original design goal in terms of ownership/containment within a package in lieu of MOF extent. According to the spec, (1) and (2)[PJR] not IMHO valid factors . see above imply that the ability to modify an element also includes the ability to add/modify/delete any stereotype applicable to that element; and each stereotype can be applied only once. [PJR] I.m not aware that the specs say anything whatsoever about .ability to modify elements., except that a Property may be flagged as ReadOnly. And AFAIK in the UML metamodel itself there are no such Properties except those which are derived. Furthermore there is no property owned by the stereotyped element to represent the link to the stereotype instance so changing stereotypes does not require changing any property owned by that element. [NFR] Without a first-class abstract syntax concept for a stereotype instance, I don.t know how to explain the problem in terms defined in the spec. We are effectively unable to use configuration management techniques on model resources to address this problem; we have to use some kind of indirection scheme in the model itself. If a tool vendor has a proprietary solution to this, it is most likely non-interoperable with other tools. If we use a custom solution, we then have to build custom tool extensions to deal with this and train users how to use our own customizations. [PJR] You should pressure the vendor to remove restrictions not required by the spec. I don.t see why this should be proprietary. In order to help interoperability any conventions could be agreed and tested through the MIWG. [NFR] The restriction is a practical consequence of how a tool implements the spec. I don.t see how your suggestion helps in the short term. It is very difficult to put pressure on tool vendors to do something differently when the spec talks about the concept of a stereotype instance without defining what it is. Here is a simple example of what we should be able to do. Consider a SysML model, M, with 3 elements: X,Y,Z Consider two users, Jack and Susie, who need to come up with proposals for allocating elements of M. Jack wants to allocate X to Y. Susie wants to allocate X to Z. We should allow Jack to create a resource, M-Jack, that imports M [PJR] I don.t see why .import. is strictly needed where M-Jack contains the application of the <> and <> stereotypes to X and Y. Ditto for Susie. To make this easier for tools to support, we can make ProfileApplication both a DirectedRelationship and a PackageableElement. [PJR] Hmm it is already (at UML 2.3) a DirectedRelationship and owned by Package (though not specifically a PackageableElement though I.m not sure what benefit this would add). [NFR] In UML 2.3, we have: ProfileApplication => DirectedRelationship => Relationship => Element. If a tool implements a ProfileApplication as a non-packageable element, then we cannot access instances of ProfileApplication except via the associations to Package and Profile. But then, two instances of ProfileApplication that have the same profile/package would be indistinguishable from one another. This means that for all practical purposes, we are effectively restricted to being able to apply a given profile to a given package only once. If we make a ProfileApplication a kind of PackageableElement, then we get the ability to distinguish two different instances of ProfileApplication independently of which package and profile are involved. Again, this is of limited value unless we also have a first-class concept for a StereotypeInstance. When you put the two together, then you get something useful at the specification level in a tool-neutral way. Below is a sketch of what this combination would allow us to do in the context of the above example with a model M::{X,Y,Z} where Jack could put the information about his application of the SysML profile to M in a separate package, M-Jack, where, .X is allocated to Y. would entail 4 elements in M-Jack: X_allocated : StereotypeInstance { stereotype=SysML::Allocated, extendedMetaclassInstance=M::X } Y_allocated : StereotypeInstance { stereotype=SysML::Allocated, extendedMetaclassInstance=M::Y } allocateXtoY : UML4SysML::Abstraction { client=M-Jack::X_allocated, supplier=M-Jack::Y_allocated } _ : StereotypeInstance { stereotype=SysML::Allocate, extendedMetaclassInstance=M-Jack::allocateXtoY } We need either element or package import relationships for the elements in M-Jack to reference M::X and M::Y. Having made the notion of an applied stereotype explicit in the abstract syntax, we can certainly add the following constraint: A stereotype instance IS for a stereotype S defined in a profile PF and applied to an element E contained in a package P must be contained in the same package that also contains the profile application of PF to P. [PJR] No. Stereotype instances are currently clearly defined as owned by the element to which they are applied not any Package. [NFR] Where is this clearly defined in the spec? The UML 2.3 spec clearly talks about the notion of a .stereotype instance. and of an .instance of a stereotype.. 18.3.3 (Extension): An ExtensionEnd is a navigable ownedEnd, owned by an Extension. This allows a stereotype instance to be attached to an instance of the extended classifier without adding a property to the classifier. 18.3.3 (Stereotype): An instance .S. of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather than generalization/specialization. Relating it to a metaclass .C. from the reference metamodel (typically UML) using an .Extension. (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of .S. (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of .S. are related to .C. model elements (instances of .C.) by links (occurrences of the association/extension from .S. to .C.). Even the example in the spec about the MOF equivalent construction talks about the notion of an instance of a stereotype and linking that instance to the element to which the stereotype is applied. Figure 18.18 shows an example instance model for when the stereotype Clock is applied to a class called StopWatch. The extension between the stereotype and the metaclass results in a link between the instance of stereotype Clock and the (user-defined) class StopWatch. However you raise an interesting issue as to how the different stereotype instances owned by an element (potentially in different extents) can be distinguished or related to a ProfileApplication. Though it would be possible to use MOF capabilities to discover the extent of the different instances and the profile application it would be desirable if UML were more .self contained. in this regard. That would also provide a means for them to be constrained in the manner you suggest . though we should also debate the benefits of such a constraint. [NFR] Let.s come back to this when we have a resolution to discuss. With this constraint, a tool could, for example, prompt the user for which package to put a stereotype instance if in fact there are multiple profile applications in distinct packages. This would allow, for example, Jack and Susie to manage their allocations in their own packages without clobbering each other independently of whether Jack.s and Susie.s packages are serialized separately. [PJR] another approach is for UML tools to work with Workspaces as defined by MOF Facility (and extended by MOF Versioning). So Jack and Susie would have different workspaces each including the shared model and the profile but with their own packages for stereotype instances. Actually MOF Workspaces are designed to be transparent to modeling tools and could be supported by the .environment. e.g. Eclipse [NFR] Due to requirement #9 in clause 18.1.2, this approach could be an informative appendix in the UML or MOF Facility spec. We need a normative solution in the spec, one that existing UML tools should be able to implement easily for their users. As far as whether it is reasonable to do this in 2.4; I.ll draft a resolution for finishing 10826 and we.ll take it from there. Since you seem to be ahead of me w.r.t. 13306, I.ll let you decide whether you want to propose a resolution or not. [PJR] See also one further comment below. - Nicolas. On 12/24/09 3:59 AM, "Dave Hawkins" wrote: I thought Ed submitted http://www.omg.org/issues/uml2-rtf.html#Issue13306 to cover that discussion? The essence of the problem is that the current structure of the metamodel means that you cannot create a valid extension that points to a metaclass. It doesn't matter what id you chose, the typing is wrong because UML::Class != CMOF::Class. [PJR] Agreed. IMHO the problem is in Fig 18.2 which shows a single Class: it should continue to show Stereotype inheriting from UML::Class but ExtensionEnd should be linked to CMOF::Class. [NFR] If you mean that the .metaclass. end of the A_extension_metaclass should be typed by CMOF::Class, then I agree with your comment below. We now have defined URLs for referencing other metamodels, and a reliable UML XMI file, so I don.t see that references to elements in the UML metamodel itself (the CMOF file) should be a problem. That is after all what many tools are already using when serializing models to reference the standard PrimitiveTypes such as Integer. - Nicolas. I've been working on an alternative metamodel for our tool that resolves this issue and allows normal XMI serialization to work. Where profile applications (and stereotype instances for that matter) are stored is separate to that but equally worthy of discussion. However is this really a 2.4 issue? Aren't the changes likely to be fairly significant? Cheers, Dave Rouquette, Nicolas F (316A) wrote: > Steve, > > I had a very productive exchange with Pete about this resolution; I > think I understand his objections and that there is a reasonable > compromise that I can draft into a resolution for Jan. 4. > Then, we can take it from there. > > I haven.t looked into the implications on serialization yet. We > discussed in 2.3 the possibility of serializing applied profiles > separately from the models/packages they are applied to. > However, we kept the .profileApplication. end of association between > Package & ProfileApplication (figure 18.2) as navigable. > > Now that OCL 2.1 clearly states that one can traversing association ends > regardless of their navigability, it would be easy to make > .profileApplication. non-navigable and add an operation to retrieve the > information via OCL. This would incur a small API change but it would > mean that we might be able to serialize applied profiles as separate > resources. Of course, there are details to consider... > > - Nicolas. > > > > On 12/21/09 8:51 AM, "Steve Cook" wrote: > > Nicolas > > You wrote: > >I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > Sounds good to me! I do remember however that when I suggested > some time ago that stereotype instances are in fact instances of > InstanceSpecification, I got quite a lot pushback. I don.t know > what else they might be, though. > > It does mean that we.ll have two ways of serializing > InstanceSpecifications though: the .normal. way and the stereotype way. > > -- Steve > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 17 December 2009 15:33 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Incomplete resolution to 10826 -- Re: Guiding principles > for choosing UML 2.4 Issues > > Steve, > > Issue 10826 was asking for two things: > > 1. what is an applied stereotype, as opposed to the definition of > the stereotype that was applied > 2. what are tag/value pairs, as opposed to the definition of the > stereotype properties that led to the tag/value pairs > > > The resolution for 10826 added the following paragraph: > An instance .S. of Stereotype is a kind of metaclass that extends > other metaclasses through association (Extension) rather > than generalization/specialization. Relating it to a metaclass .C. > from the reference metamodel (typically UML) using an > .Extension. (which is a specific kind of association), signifies > that model elements of type C can be extended by an > instance of .S. (see example in Figure 18.13). At the model level > (such as in Figure 18.18) instances of .S. are related to > .C. model elements (instances of .C.) by links (occurrences of the > association/extension from .S. to .C.). > > > > Up to the last sentence, the paragraph refers to .an instance .S. of > Stereotype. -- i.e., the definition of .S., a stereotype, in a > profile . as illustrated in figure 18.13. > > The last sentence is relevant to question (1) of 10826; however, the > resolution doesn.t actually answer the question . i.e., it doesn.t > explain what .an instance of .S.. actually is. >From Figure 18.18, > the notation suggests that .an instance of .S.. is some kind of > instance specification but the resolution doesn.t actually say so > and doesn.t address question (2) of 10826 either. > > I propose then to file a new issue about this and include Ed.s > suggestion below as well as clarifying that in Figure 18.18, .an > instance of .S.. is actually an instance specification whose > classifier happens to be .an instance .S. of Stereotype., i.e., the > definition of .S., a kind of Class since Stereotype extends Class. > > - Nicolas. > > > On 12/17/09 2:11 AM, "Steve Cook" wrote: > Nic > > 10826 was resolved in Ballot 6 of 2.3. Please check. > > Regarding circular generalization: isn.t this a MOF thing? Shouldn.t > this actually go into SMOF, whose purpose is better alignment > between MOF and semantic web constructs? > > Thanks > -- Steve > > > > *From:* Rouquette, Nicolas F (316A) > [mailto:nicolas.f.rouquette@jpl.nasa.gov] > *Sent:* 16 December 2009 20:28 > *To:* Steve Cook; Jim Amsden; uml2-rtf@omg.org > *Subject:* Re: Guiding principles for choosing UML 2.4 Issues > > What about the leftovers of the UML 2.3 RTF? > > Two leftovers are particularly important for other OMG > specifications that depend on the UML spec: SysML and related > efforts including the SysML/QUDV and SysML/Modelica integration. > The two leftovers are: > > 1. applied stereotypes (we had a discussion in issue 13291 but > there is an issue filed, 10826 about this that isn.t in the > UML 2.4 spreadsheet) > 2. navigation up/down classifier hierarchies > > > About (1) -- Applied stereotypes. > > I didn.t find 10826 in the UML 2.4 spreadsheet: > http://www.omg.org/issues/uml2-rtf.html#Issue10826 > This issue is about the lack of a normative abstract syntax for > accessing the stereotypes that are applied to an element: > > Issue 13291 was eventually withdrawn; however, before the discussion > digressed to other topics, Ed provided a concise suggestion > summarizing a discussion between Dave H., Ed S., Jim A. and myself > (01/20/2009): > Moreover, it seems to me that the whole point of pointing stereotypes > specifically to UML metaclasses in UML 2 was so that such stereotypes > were based of the standard UML metamodel. For this to have any real > force in terms of repository representation and interchange, then the > metaclasses referenced should be those with normative IDs in the > normative CMOF representation of the metamodel. Such standard IDs are > lost if each tool is, instead, pointing to its own (non-normative) > representation of the metamodel as a UML L3 model. > > If stereotypes are not going to point to the normative CMOF metaclasses, > then one might as well simplify the stereotype abstract syntax to just > reference the extended the metaclasses by name, as was done in UML 1. > > -- Ed > > I propose to develop a resolution for 10826 and include Ed.s > suggestion above, i.e., reference the extended metaclass by its > normative URI. > > About (2) -- Navigation up/down classifier hierarchies. > > The UML 2.3 RTF report includes the following in the resolution text > of 9374: > This resolution includes an OCL constraint which depends on the OCL > 2.1 revision: > context AssociationClass > self.A_general_classifier::classifier > ->forAll(oclIsKindOf(AssociationClass)) > The meaning of this constraint is as follows: > self.A_general_classifier::classifier > This expression navigates the association A_general_classifier in > the inverse direction of the navigability of the property > /Classifier::general : Classifier[*]. > That is, it provides the set of classifiers that specialize .self.. > > This OCL constraint was editorially removed on the basis that UML > 2.3 was aligned to OCL 2.0, not 2.1. > Since then, OCL 2.1 is available; the constraint could be reinstated > in principle. > However, Maged had suggested instead renaming the association: > A_general_classifier on Classifier to A_general_specific. > Classifer would have, symmetrically, two derived properties for > accessing its general and specific classifiers. > > Besides the two leftovers above, there is a third issue: > > (3) - Relaxing generalization relationships to allow circularities > > In OWL/OWL2, generalization relationships among classes can be > circular . > the semantics here are that all classes in the strongly connected > graph of > generalization relationships are semantically equivalent. > > All CMOF-based metamodels can.t have circular generalization > relationships. > In UML infrastructure, Core::Constructs::Classifier includes a > constraint that > the generalization relationships that a classifier is involved in > must be acyclic. > > I propose to remove this constraint and replace it with a query: > > context Classifier::hasCircularGeneralization() : Boolean > body: = self.general->includes(self) > > It is out of scope of the UML to say whether generalizations should be > acyclic but it is something that could be enforced as an invariant > specified > in a profile (e.g., for OO languages with a strict type hierarchy). > > - Nicolas. > > > On 12/16/09 2:55 AM, "Steve Cook" wrote: > Jim > > I think this is useful for helping to establish the scope for 2.4. > In my mind, in 2.4 we should avoid dealing with issues that can be > dealt with better during simplification (your category 3) and issues > that can be dealt with more easily after simplification (such as > refactoring). > > I don.t think there is any need to avoid fixing OCL in 2.4 in cases > where we find it to be in error. > > Thanks > -- Steve > > *From:* Jim Amsden [mailto:jamsden@us.ibm.com] > *Sent:* 15 December 2009 18:34 > *To:* uml2-rtf@omg.org > *Subject:* Guiding principles for choosing UML 2.4 Issues > > We increased the time window for the UML 2.4 RTF, but its still > short. As you know, IBM's desire was to limit the number of > additional releases on the 2.x stream as these are expensive, have > limited value for our customers, and could delay efforts to > significantly cleanup, simplify, and provide better extensibility > and integration mechanisms for UML. In order to limit releases on > the 2.x stream, we have to address issues that would motivate them. > Ideally the 2.4 RTF would address these issues providing a usable, > stable platform for UML modeling and model interchange. Then the UML > 2.5 specification simplification submission could provide a better > description of that that modeling language is. Taken together, these > two releases could provide a longer-lived modeling platform that > could give us the time we need to develop the next generation of UML > that would hopefully address the issues and opportunities we > identified in the UML Futures RFI responses. > > Maybe we can't achieve this with UML 2.4 and 2.5, and may need to do > 2.6 and beyond to address specific needs. But it may be useful to try. > > The UML 2.4 (or possibly any) RTF is too short to address all the > issues, so we may need some guiding principles to help decide which > issues are critical to achieving a stable UML 2.5 platform, and > therefore which ones will be included in 2.4. Here's a possible > starter set for discussion: > > 1. Include any issue that prevents creation of the merged > metamodel or XMI interchange > 2. Include any show-stopper issues that are preventing the > successful use of UML for common use cases, including some of > the key issues raised by the RFI responses > 3. Avoid simple editorial changes and clarifications that could > be handled by the UML 2.5 specification cleanup submission > 4. Avoid cleanup, refactoring, removal of unintended inheritance, > OCL cleanup or addition of missing constraints, etc. that > although useful, are not critical inhibitors for UML > implementation or use, and may be easier to handle more > effectively in a less constrained release. > > > Do you think this is useful, a good starting point? Any other > suggestions? > > > Jim Amsden, Senior Technical Staff Member > Rational Enterprise Architecture Management > 919-461-3689 > -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.