Issue 6244: Metamodel for applying a stereotype (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: What part of the metamodel is for applying a stereotype to a single element in a user model? I can only find the appliedProfile association for applying profiles to packages. Figure 458 shows a repository model for it, but doesn't give the name of the relation between a class and the Clock stereotype. Resolution: This issue is resolved by the solution to issue 6347. Revised Text: Actions taken: September 8, 2003: received issue March 8, 2005: closed issue Discussion: End of Annotations:===== Reply-To: From: "Conrad Bock" To: Subject: Two more Date: Mon, 8 Sep 2003 22:14:42 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Hi Juergen, Here are two more UML 2 Super issues. I hope the deadline is midnight ET. :) Thanks, Conrad Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Clarification Subject: Metamodel for applying a stereotype What part of the metamodel is for applying a stereotype to a single element in a user model? I can only find the appliedProfile association for applying profiles to packages. Figure 458 shows a repository model for it, but doesn't give the name of the relation between a class and Reply-To: From: "DESFRAY Philippe" To: "'Pete Rivett'" , , Subject: RE: [profile] - Proposed issue resolution for profile issues assigned to me Date: Wed, 21 Jan 2004 16:32:09 +0100 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MS-TNEF-Correlator: 0000000000C3B727BFC1BC11A4646E0283BD88A884A99E00 Pete, Thanks for the thorough revision. 1 revise the requirements : OK For the remaining part, brainstorm is needed. 2 >>> The replacement text still does not address issue 6244 about the naming of the association between instances of S and C: though in theory the notation would allow a name to be specified, in all the examples of stereotype definitions in the spec and in real UML2 Profiles (in other specs) this association has never been named: so how is a tool to navigate to the applied stereotype instances? OK, I will iterate on this issue. The spec does provide part of the solution in "Extension:semantics" : --- In order to be able to navigate to the extended metaclass when writing constraints, the end must have a name. If no name is given, the default name is baseClass. ---- A reverse navigation is also of interest and can be adressed similarily. 3 >>>> one thing I've already suggested is a definition of the abstract semantics' of the various profile related operations: such as applying and removing a profile from a model and a model element: this would, using an instance model, specify the post condition in a similar style to that used in the MOF spec (chapter 15 of ptc/03-10-04). You mean something like the example below? --- Object::delete() modeled as ObjectInstance::delete() -- Delete all composite objects and all slots post: (self.allProperties->select(p| isComposite(p), delete(self.get(p))) and self.allSlottableProperties->forAll(p| destroyed(self.propertySlot(p))) and extent().removeObject(self) not(extent().objects() includes self) and destroyed(self) --- I can imagine : Package::apply (Profile p) Package::retract (Profile p) Class::extend (Stereotype s) Class::retract (Stereotype s) Class::hasExtension (Stereotype s) >>> we should also define, in MOF terms, the semantics of defining stereotypes so that the mapping/equivalence is clear. This will also facilitate the expression of profiles in XMI (which is driven by MOF definitions). I would relate that to the issue regarding XMI example, which I had deliberately left out of this thread. There, cooperation is needed. All this could be gathered in the same chapter. (Issue 6242: Confusion regarding XMI for use of stereotypes (uml2-superstructure-ftf)) >>> To help review the changes it would be useful to see a revision of the complete chapter. While I agree with this concern, I think that it is not practical to apply. It does concern every spec : we see changes for parts Y, X Z, but may find difficult to see the consolidation of that. And we need to make progress and reach convergence step by step. In conclusion, I will iterate on the proposal : step 1 : without issue 6244 Step 2 issue 6344 Step 3 issue 6242 with the XMI concern (MOF/XMI expert cooperation needed there) best regards -- Philippe -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoye : mercredi 21 janvier 2004 13:36 A : philippe.desfray@softeam.fr; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Objet : RE: [profile] - Proposed issue resolution for profile issues assigned to me Since Profiles are part of both Infra and Super, this should not start with 'Important note to readers of the Superstructure' Requirement 1: should not refer to 'The standard UML metamodel' as the reference metamodel implying that there's only one: given that there will be different compliance levels each with their own set of UML metamodel packages. Requirement 2: I would delete "(or idl)". Requirement 2: Implies that an export is done in the knowledge of the eventual target tool: is that the intention? How would this knowledge be made available? How does this fit with requirement [13]? Requirement 3: Should say 'reference' rather than 'define' Requirement 5: By 'profile selections' does this mean 'profile applications' - those profiles that are currently applied to a (M1) Model/Package? Requirement 6: Presumably this kind of dependency requires some way of distinguishing it from other dependencies Requirement 10: I don't think this is well-defined at all: since 'metacase functionality' is not defined or generally understood. The replacement text still does not address issue 6244 about the naming of the association between instances of S and C: though in theory the notation would allow a name to be specified, in all the examples of stereotype definitions in the spec and in real UML2 Profiles (in other specs) this association has never been named: so how is a tool to navigate to the applied stereotype instances? To help review the changes it would be useful to see a revision of the complete chapter. While I agree with the requirements what we need to ensure is that the spec itself reflects all these aspects: it seems that there is quite a bit more to add the spec to achieve this: one thing I've already suggested is a definition of the abstract semantics' of the various profile related operations: such as applying and removing a profile from a model and a model element: this would, using an instance model, specify the post condition in a similar style to that used in the MOF spec (chapter 15 of ptc/03-10-04). And we should also define, in MOF terms, the semantics of defining stereotypes so that the mapping/equivalence is clear. This will also facilitate the expression of profiles in XMI (which is driven by MOF definitions). Also I think further examples are needed - especially some of the cases of transmitting profiles with their model and the profile definition itself. Regards Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: DESFRAY Philippe [mailto:philippe.desfray@softeam.fr] Sent: Tuesday, January 20, 2004 10:59 AM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: [profile] - Proposed issue resolution for profile issues assigned to me Dear all, As I said previously, many issues are related to the same subject. On this thread, I am focusing on this (+ one simple reject issue). Discussion is likely to happen on this specific subject, so we are not at all in a proposal for a ballot X. Issue 6242 is also very related to the same subject. But it asks for XMI, which will be worked on later. Best regards -- Philippe winmail1.dat Reply-To: From: "DESFRAY Philippe" To: "'Pete Rivett'" , , Subject: RE: [profile] - Proposed issue resolution for profile issues assigned to me Date: Mon, 26 Jan 2004 18:47:53 +0100 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MS-TNEF-Correlator: 0000000000C3B727BFC1BC11A4646E0283BD88A884E09E00 In response to pete's comments, here is an iteration of the proposed issue resolution. >>>> In conclusion, I will iterate on the proposal : step 1 : without issue 6244 Step 2 issue 6344 Step 3 issue 6242 with the XMI concern (MOF/XMI expert cooperation needed there) <<<< This is step1 -- Philippe -----Message d'origine----- De : DESFRAY Philippe [mailto:philippe.desfray@softeam.fr] Envoyé : mercredi 21 janvier 2004 16:32 À : 'Pete Rivett'; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Objet : RE: [profile] - Proposed issue resolution for profile issues assigned to me Pete, Thanks for the thorough revision. 1 revise the requirements : OK For the remaining part, brainstorm is needed. 2 >>> The replacement text still does not address issue 6244 about the naming of the association between instances of S and C: though in theory the notation would allow a name to be specified, in all the examples of stereotype definitions in the spec and in real UML2 Profiles (in other specs) this association has never been named: so how is a tool to navigate to the applied stereotype instances? OK, I will iterate on this issue. The spec does provide part of the solution in "Extension:semantics" : --- In order to be able to navigate to the extended metaclass when writing constraints, the end must have a name. If no name is given, the default name is baseClass. ---- A reverse navigation is also of interest and can be adressed similarily. 3 >>>> one thing I've already suggested is a definition of the abstract semantics' of the various profile related operations: such as applying and removing a profile from a model and a model element: this would, using an instance model, specify the post condition in a similar style to that used in the MOF spec (chapter 15 of ptc/03-10-04). You mean something like the example below? --- Object::delete() modeled as ObjectInstance::delete() -- Delete all composite objects and all slots post: (self.allProperties->select(p| isComposite(p), delete(self.get(p))) and self.allSlottableProperties->forAll(p| destroyed(self.propertySlot(p))) and extent().removeObject(self) not(extent().objects() includes self) and destroyed(self) --- I can imagine : Package::apply (Profile p) Package::retract (Profile p) Class::extend (Stereotype s) Class::retract (Stereotype s) Class::hasExtension (Stereotype s) >>> we should also define, in MOF terms, the semantics of defining stereotypes so that the mapping/equivalence is clear. This will also facilitate the expression of profiles in XMI (which is driven by MOF definitions). I would relate that to the issue regarding XMI example, which I had deliberately left out of this thread. There, cooperation is needed. All this could be gathered in the same chapter. (Issue 6242: Confusion regarding XMI for use of stereotypes (uml2-superstructure-ftf)) >>> To help review the changes it would be useful to see a revision of the complete chapter. While I agree with this concern, I think that it is not practical to apply. It does concern every spec : we see changes for parts Y, X Z, but may find difficult to see the consolidation of that. And we need to make progress and reach convergence step by step. In conclusion, I will iterate on the proposal : step 1 : without issue 6244 Step 2 issue 6344 Step 3 issue 6242 with the XMI concern (MOF/XMI expert cooperation needed there) best regards -- Philippe -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mercredi 21 janvier 2004 13:36 À : philippe.desfray@softeam.fr; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Objet : RE: [profile] - Proposed issue resolution for profile issues assigned to me Since Profiles are part of both Infra and Super, this should not start with 'Important note to readers of the Superstructure' Requirement 1: should not refer to 'The standard UML metamodel' as the reference metamodel implying that there's only one: given that there will be different compliance levels each with their own set of UML metamodel packages. Requirement 2: I would delete "(or idl)". Requirement 2: Implies that an export is done in the knowledge of the eventual target tool: is that the intention? How would this knowledge be made available? How does this fit with requirement [13]? Requirement 3: Should say 'reference' rather than 'define' Requirement 5: By 'profile selections' does this mean 'profile applications' - those profiles that are currently applied to a (M1) Model/Package? Requirement 6: Presumably this kind of dependency requires some way of distinguishing it from other dependencies Requirement 10: I don't think this is well-defined at all: since 'metacase functionality' is not defined or generally understood. The replacement text still does not address issue 6244 about the naming of the association between instances of S and C: though in theory the notation would allow a name to be specified, in all the examples of stereotype definitions in the spec and in real UML2 Profiles (in other specs) this association has never been named: so how is a tool to navigate to the applied stereotype instances? To help review the changes it would be useful to see a revision of the complete chapter. While I agree with the requirements what we need to ensure is that the spec itself reflects all these aspects: it seems that there is quite a bit more to add the spec to achieve this: one thing I've already suggested is a definition of the abstract semantics' of the various profile related operations: such as applying and removing a profile from a model and a model element: this would, using an instance model, specify the post condition in a similar style to that used in the MOF spec (chapter 15 of ptc/03-10-04). And we should also define, in MOF terms, the semantics of defining stereotypes so that the mapping/equivalence is clear. This will also facilitate the expression of profiles in XMI (which is driven by MOF definitions). Also I think further examples are needed - especially some of the cases of transmitting profiles with their model and the profile definition itself. Regards Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: DESFRAY Philippe [mailto:philippe.desfray@softeam.fr] Sent: Tuesday, January 20, 2004 10:59 AM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: [profile] - Proposed issue resolution for profile issues assigned to me Dear all, As I said previously, many issues are related to the same subject. On this thread, I am focusing on this (+ one simple reject issue). Discussion is likely to happen on this specific subject, so we are not at all in a proposal for a ballot X. Issue 6242 is also very related to the same subject. But it asks for XMI, which will be worked on later. Best regards -- Philippe the Clock stereotype.