Issue 18245: Clarification re MOF Equivalent Semantics about defining/applying a stereotype to a slot of ininstance of a stereotype (uml25-ftf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Clarification Severity: Summary: The UML 2.5 beta document explains the mapping of Profiles, Stereotypes, and Extensions in terms of the CMOF-equivelent semantics as follows: - A Profile maps to a CMOF Package Š - A Stereotype maps to a CMOF class with the same name and properties Š - An instance of a Stereotype (created when the Stereotype is applied to an Element) maps to an instance of the CMOF class representing the Stereotype. It is associated with the Element to which it applies using a Link which is an instance of the Association to which the Extension is mapped. According to the above, this means that 1) when defining the stereotype Clock (Fig 12.22), the property Clock::OSVersion maps to a property of the CMOF class named Clock 2) when applying the stereotype Clock (Fig 12.26 and 12.27) to an element (StopWatch on Fig 12.22), the underlying semantics has an instance of the CMOF class Clock with a slot corresponding to the property Clock::OSVersion (Fig 12.27) It should be possible to define a stereotype extending UML::Slot and apply such stereotype to a slot corresponding to a property of an instance of a stereotype, e.g., the slot OSVersion="3.32" of Fig 12.27. This is a subtle point about the current profile mechanism that should be made clear in the spec. I suggest adding an explanation about this in the "MOF Equivalent Semantics" sub-section of section 12.3.3 Profile Semantics. Resolution: Revised Text: Actions taken: November 3, 2012: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "uml25-ftf@omg.org" Subject: Profile issue: Clarification needed about MOF Equivalent Semantics about defining and applying a stereotype to a slot of an in instance of a stereotype Thread-Topic: Profile issue: Clarification needed about MOF Equivalent Semantics about defining and applying a stereotype to a slot of an in instance of a stereotype Thread-Index: AQHNug/m8S44J6pby0ixUU8apPfWxA== Date: Sat, 3 Nov 2012 22:09:32 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id qA3M9sDL026597 The UML 2.5 beta document explains the mapping of Profiles, Stereotypes, and Extensions in terms of the CMOF-equivelent semantics as follows: - A Profile maps to a CMOF Package . - A Stereotype maps to a CMOF class with the same name and properties . - An instance of a Stereotype (created when the Stereotype is applied to an Element) maps to an instance of the CMOF class representing the Stereotype. It is associated with the Element to which it applies using a Link which is an instance of the Association to which the Extension is mapped. According to the above, this means that 1) when defining the stereotype Clock (Fig 12.22), the property Clock::OSVersion maps to a property of the CMOF class named Clock 2) when applying the stereotype Clock (Fig 12.26 and 12.27) to an element (StopWatch on Fig 12.22), the underlying semantics has an instance of the CMOF class Clock with a slot corresponding to the property Clock::OSVersion (Fig 12.27) It should be possible to define a stereotype extending UML::Slot and apply such stereotype to a slot corresponding to a property of an instance of a stereotype, e.g., the slot OSVersion="3.32" of Fig 12.27. This is a subtle point about the current profile mechanism that should be made clear in the spec. I suggest adding an explanation about this in the "MOF Equivalent Semantics" sub-section of section 12.3.3 Profile Semantics. - Nicolas.