Issue 6242: Confusion regarding XMI for use of stereotypes (uml2-superstructure-ftf) Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk) Nature: Uncategorized Issue Severity: Summary: I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Resolution: see above Revised Text: Actions taken: September 12, 2003: received issue March 8, 2005: closed issue Discussion: It is indeed an important preoccupation that there is no illustration of how to interchange profiles in XMI. This is not explained in the Profile spec, nor in the MOF spec, nor in the XMI spec. “instance model seems to mix meta- levels” is a common misunderstanding of the Profile spec that has been solved through the previous issue resolutions. In particular, the Profile/MOF correspondence has been specified and illustrated. This allows us to apply the MOF/XMI mechanism. We therefore propose to provide an example that illustrates the XMI interchange of profiles. The specification should be amended as follows: ?? In Profiles:Profile:semantics, at the end of this paragraph, add Using XMI to exchange Profiles As shown Figure 447 (Extension : Semantics), there is a direct correspondence between a profile definition and a MOF metamodel. XMI can therefore be directly applied to exchange Profiles. We will take the example Figure 449 (Extension : Notation) of a profile that we will call “HomeExample” to illustrate how a profile can be exchanged. We will see that a profile can be exchanged as a model, as a XMI schema definition, and that models extended by the profile can also interchange their definition and extension. Figure 449 shows a “Home” stereotype extending the “Interface” UML2 metaclass. Figure 447 illustrates the MOF correspondence for that example, basically by introducing an association from the “Home” MOF class to the “Interface” MOF class. For illustration purpose, we add a property (tagged value definition in UML1.4) called “magic:String” to the “Home” stereotype. The first serialization below shows how the model Figure 449 (instance of the profile and UML2 metamodel) can be exchanged. <?xml version="1.0" encoding="UTF-8"?> <XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:mof="http://schema.omg.org/spec/MOF/2.0" xmlns:uml="http://schema.omg.org/spec/UML/2.0"> <uml:Profile xmi:id="id1" name="HomeExample"> <ownedStereotype xsi:type="uml:Stereotype" xmi:id="id2" name="Home"> <ownedAttribute xmi:id="id3" name="base_Interface" association="id5" type=”id9”/> <ownedAttribute xmi:id="id4" name="magic" type=”id10”/> </ownedStereotype> <ownedMember xsi:type="uml:Extension" xmi:id="id5" memberEnd="id3 id6"> <ownedEnd xsi:type="uml:ExtensionEnd" name="extensionHome" xmi:id="id6" type="id2" association="id5" isComposite="true" lower="0"/> </ownedMember> <!--There should be metaclass reference between the profile and the extended metaclass --> <metaclassReference xmi:id="id8"> <uml:elementImport xsi:type="uml:ElementImport" importedElement=”id9”/> </metaclassReference> </uml:Profile> <mof:Class xmi:id=”id9” href="http://schema.omg.org/spec/UML/2.0/uml.xml#Interface"/> <mof:PrimitiveType xmi:id=”id10” href="http://schema.omg.org/spec/UML/2.0/uml.xml#String"/> <mof:Tag name="org.omg.xmi.nsURI" value="http://www.mycompany.com/schemas/HomeExample.xmi" element="id1"/> <mof:Tag name="org.omg.xmi.nsPrefix" value="HomeExample" element="id1"/> <mof:Tag name="org.omg.xmi.xmiName" value="base_Interface" element="id3"/> </XMI> We will now obtain a XMI definition from the « HomeExample » profile. That XMI description will itself define in XML how the models extended by the HomeExample will be exchanged in XMI. We can see here that a XMI schema separated from the standard UML2 schema can be obtained. This XMI definition is stored in a file called “HomeExample.xmi”. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace = "http://www.mycompany.com/schemas/HomeExample.xmi" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:uml="http://www.omg.org/spec/UML/2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:import namespace="http://schema.omg.org/spec/XMI/2.1" schemaLocation="XMI.xsd"/> <xsd:import namespace="http://schema.omg.org/spec/UML/2.0" schemaLocation="UML20.xsd"/> <xsd:complexType name="Home"> <xsd:choice minOccurs="0" maxOccurs ="unbounded"> <xsd:element name="base_Interface" type="xmi:Any"/> <xsd:element name="magic" type="xsd:string"/> <xsd:element ref="xmi:Extension"/> </xsd:choice> <xsd:attribute ref="xmi:id"/> <xsd:attributeGroup ref="xmi:ObjectAttribs"/> <xsd:attribute name="base_Interface" type="uml:Interface" <xsd:attribute name="magic" type="xsd:string" use="optional"/> use="optional"/> </xsd:complexType> <xsd:element name="Home" type="Home"/> </xsd:schema> Let us provide an example of an Interface extended by the Home stereotype. Figure 452 – Using the “HomeExample” profile to extend a model Now the XMI code below shows how this model extended by the profile is serialized. A tool importing that XMI file can filter out the elements related to the “HomeExample” schema, if the tool does not have this schema (profile) definition. <?xml version="1.0" encoding="UTF-8"?> <XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:uml="http://schema.omg.org/spec/UML/2.0 " xmlns:HomeExample="http://www.mycompany.com/schemas/HomeExample.xmi"> <uml:Package xmi:id="id1" name="ClientPackage"> <ownedMember xsi:type="uml:Interface" xmi:id="id2" name="Client"/> <packageImport xsi:type="uml:ProfileApplication" xmi:id="id3"> <importedProfile href="HomeExample.xmi#id1"/> </packageImport> </uml:Package> <!-- Stereotypes --> <HomeExample:Home base_Interface="id2" magic="1234"/> </XMI> Disposition: Resolved <<Home>> Client ClientPackage End of Annotations:===== m: "Moore, Alan" To: "UML2 Superstructure FTF (E-mail)" Subject: Confusion regarding XMI for use of stereotypes Date: Fri, 12 Sep 2003 13:43:21 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Thanks in Advance, Alan. To: "Moore, Alan" Cc: "UML2 Superstructure FTF (E-mail)" Subject: Re: Confusion regarding XMI for use of stereotypes X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Fri, 12 Sep 2003 10:12:56 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/12/2003 10:13:05 Alan, This has been raised as an issue already, although not in the context of the specific figure (so, I leave it up to you whether you want to raise a new issue or not). Regarding a possible solution, I am attaching a document that proposes one but it has problems -- notably that it does not scale up very well (this is fairly obvious from the diagrams, actually). Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Moore, Alan" 09/12/2003 08:43 AM To: "UML2 Superstructure FTF (E-mail)" cc: Subject: Confusion regarding XMI for use of stereotypes I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Thanks in Advance, Alan. Applying a Stereotype to an Element.doc From: "Moore, Alan" To: "'Branislav Selic'" Cc: "UML2 Superstructure FTF (E-mail)" Subject: RE: Confusion regarding XMI for use of stereotypes Date: Fri, 12 Sep 2003 16:38:37 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) This was the solution I came up with - it is pretty ugly and I didn't think it worked - I couldn't see how you attach the instance of the stereotype to the instance of the metaclass (in this case Comment). I see you have related the instance of the stereotype to the instance of Comment via an instance of Slot, using the value association end, but I can't see how you can do this with the current metamodel Slots only reference ValueSpecifications via the value association end - - can you enlighten me? Alan. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 12 September 2003 15:13 To: Moore, Alan Cc: UML2 Superstructure FTF (E-mail) Subject: Re: Confusion regarding XMI for use of stereotypes Alan, This has been raised as an issue already, although not in the context of the specific figure (so, I leave it up to you whether you want to raise a new issue or not). Regarding a possible solution, I am attaching a document that proposes one but it has problems -- notably that it does not scale up very well (this is fairly obvious from the diagrams, actually). Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Moore, Alan" 09/12/2003 08:43 AM To: "UML2 Superstructure FTF (E-mail)" cc: Subject: Confusion regarding XMI for use of stereotypes I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Thanks in Advance, Alan. To: "Moore, Alan" Cc: "UML2 Superstructure FTF (E-mail)" Subject: RE: Confusion regarding XMI for use of stereotypes X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Fri, 12 Sep 2003 15:20:02 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/12/2003 15:20:05, Serialize complete at 09/12/2003 15:20:05 That's a good question -- we probably have to define a standard way of doing this. I was assuming that an objectId (repository id) would be the way, but have to admit that I'm fuzzy on this detail. Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Moore, Alan" 09/12/2003 11:38 AM To: Branislav Selic/Ottawa/IBM@IBMCA cc: "UML2 Superstructure FTF (E-mail)" Subject: RE: Confusion regarding XMI for use of stereotypes This was the solution I came up with - it is pretty ugly and I didn't think it worked - I couldn't see how you attach the instance of the stereotype to the instance of the metaclass (in this case Comment). I see you have related the instance of the stereotype to the instance of Comment via an instance of Slot, using the value association end, but I can't see how you can do this with the current metamodel Slots only reference ValueSpecifications via the value association end - - can you enlighten me? Alan. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 12 September 2003 15:13 To: Moore, Alan Cc: UML2 Superstructure FTF (E-mail) Subject: Re: Confusion regarding XMI for use of stereotypes Alan, This has been raised as an issue already, although not in the context of the specific figure (so, I leave it up to you whether you want to raise a new issue or not). Regarding a possible solution, I am attaching a document that proposes one but it has problems -- notably that it does not scale up very well (this is fairly obvious from the diagrams, actually). Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Moore, Alan" 09/12/2003 08:43 AM To: "UML2 Superstructure FTF (E-mail)" cc: Subject: Confusion regarding XMI for use of stereotypes I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Thanks in Advance, Alan. Reply-To: From: "DESFRAY Philippe" To: "'Branislav Selic'" , "'Moore, Alan'" Cc: "'UML2 Superstructure FTF \(E-mail\)'" Subject: RE: Confusion regarding XMI for use of stereotypes Date: Mon, 15 Sep 2003 15:34:29 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal Alan, Stereotypes are defined at the same level than the meta-meta model (MOF or M3, ... for short). The notions "Stereotype", "Extension" "Profile" are at the same level than the "meta meta Class" or the "metameta "Association". So Figure 446 (profile metamodel) is a M3 metamodel, one level above the UML metamodel. Figure 456 is at the UML metamodel level : we have "Class" and "Component", which are instances of the (meta meta) "Class" we have "Clock" which is an instance of "Stereotype". "Clock" is related to "Class" and "Component" through "extension occurences". This is entirely similar to a picture where you have "State" related through an association (or you can say "association occurence") to "Transition". (Extension is a kind of association ... at the M3 metalevel). Then, at the M1 level, which is the usual UML modeling level, you can connect through a "link" (the instanciation scheme of an association, or similarly of an extension) an instance of "Class" (StopWatch) to an instance of "Clock" (anonymous). This is picture 457, 458 where to notations are presented, and the instance model is schown. I do not see any issue here, though I recognize that the 3 levels of modeling do not help understanding. Best regards -- Philippe DESFRAY VP for R& D phd@softeam.fr SOFTEAM - Objecteering Software --------Think Object 144 avenue des Champs Elysées - 75008 PARIS - Tel (33 1) 53968400 - Fax (33 1) 53968401 -- -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : vendredi 12 septembre 2003 16:13 À : Moore, Alan Cc : UML2 Superstructure FTF (E-mail) Objet : Re: Confusion regarding XMI for use of stereotypes Alan, This has been raised as an issue already, although not in the context of the specific figure (so, I leave it up to you whether you want to raise a new issue or not). Regarding a possible solution, I am attaching a document that proposes one but it has problems -- notably that it does not scale up very well (this is fairly obvious from the diagrams, actually). Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Moore, Alan" 09/12/2003 08:43 AM To: "UML2 Superstructure FTF (E-mail)" cc: Subject: Confusion regarding XMI for use of stereotypes I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Thanks in Advance, Alan. To: Cc: "'Moore, Alan'" , "'UML2 Superstructure FTF \(E-mail\)'" Subject: RE: Confusion regarding XMI for use of stereotypes X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Mon, 15 Sep 2003 14:58:10 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/15/2003 14:58:11, Serialize complete at 09/15/2003 14:58:11 Philippe, It seems to me that you are assuming a specific type of model repository: one that dynamiclly adjusts its metamodel as new stereotypes are defined. While this is one way to implement model repositories, it is not the only way and may not be favoured by all tool vendors (e.g. due to performance and scalability concerns). Thus, using the example in figure 458 of the spec, you are assuming that a model repository will create an instance of "Clock", which is a stereotype that was encountered dynamically when some M1 model was loaded into the repository. If you recall, one of the constraints that were imposed on profiles in 1.x was to avoid assumptions that a UML tool necessarily had to be a metamodeling tool. This is why it was desireable to have an alternative way of representing stereotypes using techniques such as the one based on instance specs that I outlined in my previous note. However, as Alan pointed out, this has problems and may require a "kludge". Do you have any opinions or ideas on how we can avoid this? If so, we should think about including some reference to this in the spec itself. Thanks, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "DESFRAY Philippe" 09/15/2003 09:34 AM Please respond to philippe.desfray To: Branislav Selic/Ottawa/IBM@IBMCA, "'Moore, Alan'" cc: "'UML2 Superstructure FTF \(E-mail\)'" Subject: RE: Confusion regarding XMI for use of stereotypes Alan, Stereotypes are defined at the same level than the meta-meta model (MOF or M3, ... for short). The notions "Stereotype", "Extension" "Profile" are at the same level than the "meta meta Class" or the "metameta "Association". So Figure 446 (profile metamodel) is a M3 metamodel, one level above the UML metamodel. Figure 456 is at the UML metamodel level : we have "Class" and "Component", which are instances of the (meta meta) "Class" we have "Clock" which is an instance of "Stereotype". "Clock" is related to "Class" and "Component" through "extension occurences". This is entirely similar to a picture where you have "State" related through an association (or you can say "association occurence") to "Transition". (Extension is a kind of association ... at the M3 metalevel). Then, at the M1 level, which is the usual UML modeling level, you can connect through a "link" (the instanciation scheme of an association, or similarly of an extension) an instance of "Class" (StopWatch) to an instance of "Clock" (anonymous). This is picture 457, 458 where to notations are presented, and the instance model is schown. I do not see any issue here, though I recognize that the 3 levels of modeling do not help understanding. Best regards -- Philippe DESFRAY VP for R& D phd@softeam.fr SOFTEAM - Objecteering Software --------Think Object 144 avenue des Champs Elysées - 75008 PARIS - Tel (33 1) 53968400 - Fax (33 1) 53968401 -- -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : vendredi 12 septembre 2003 16:13 À : Moore, Alan Cc : UML2 Superstructure FTF (E-mail) Objet : Re: Confusion regarding XMI for use of stereotypes Alan, This has been raised as an issue already, although not in the context of the specific figure (so, I leave it up to you whether you want to raise a new issue or not). Regarding a possible solution, I am attaching a document that proposes one but it has problems -- notably that it does not scale up very well (this is fairly obvious from the diagrams, actually). Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Moore, Alan" 09/12/2003 08:43 AM To: "UML2 Superstructure FTF (E-mail)" cc: Subject: Confusion regarding XMI for use of stereotypes I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Thanks in Advance, Alan. Reply-To: From: "DESFRAY Philippe" To: "'Branislav Selic'" Cc: "'Moore, Alan'" , "'UML2 Superstructure FTF \(E-mail\)'" Subject: RE: Confusion regarding XMI for use of stereotypes Date: Tue, 16 Sep 2003 09:53:52 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal Bran, Well, I am not assuming. The way the specification is done, is that Stereotype is a kind of (meta)class, and "Extend" is a kind of (meta)association. The basic mechanisms of profiles are just the same as the usual principles of metaclass and meta-association. The flexibility of the profile mechanism is just that in order to add, combine or withdraw extensions to an existing UML element, it is only a matter of adding or withdrawing links between that element and extension instances (i.e. Stereotype instances). This gives the "semantics", and a specific attention has been given to provide instance models for that. (remeber the debate we had that instance semantics should be given overall in the spec). In addition, it has been checked that "usual XMI" would support this without any change. This is "MOF compatible" in that sense that "Extension" is just a kind of "pattern". This does not enforce or preclude any specific implementation of that mechanism, in particular if there are performance issues. Introducing implmentation hints, or "kludges" is a slippery path in which I am a bit reluctant to go. This is I think a global statement of the UML standard : the semantics is given, interchange format is provided, but the implementation is up to tool vendors. Expressing the contrary would be a surprising "juriprudence" case. May be a "discussion" enlighting this can be introduced as an addendum to the spec : The 3 metalevel semantics, and the fact that the instance model specifies the "semantics". -- Philippe DESFRAY VP for R& D phd@softeam.fr SOFTEAM - Objecteering Software --------Think Object 144 avenue des Champs Elysées - 75008 PARIS - Tel (33 1) 53968400 - Fax (33 1) 53968401 -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : lundi 15 septembre 2003 20:58 À : philippe.desfray@softeam.fr Cc : 'Moore, Alan'; 'UML2 Superstructure FTF (E-mail)' Objet : RE: Confusion regarding XMI for use of stereotypes Philippe, It seems to me that you are assuming a specific type of model repository: one that dynamiclly adjusts its metamodel as new stereotypes are defined. While this is one way to implement model repositories, it is not the only way and may not be favoured by all tool vendors (e.g. due to performance and scalability concerns). Thus, using the example in figure 458 of the spec, you are assuming that a model repository will create an instance of "Clock", which is a stereotype that was encountered dynamically when some M1 model was loaded into the repository. If you recall, one of the constraints that were imposed on profiles in 1.x was to avoid assumptions that a UML tool necessarily had to be a metamodeling tool. This is why it was desireable to have an alternative way of representing stereotypes using techniques such as the one based on instance specs that I outlined in my previous note. However, as Alan pointed out, this has problems and may require a "kludge". Do you have any opinions or ideas on how we can avoid this? If so, we should think about including some reference to this in the spec itself. Thanks, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "DESFRAY Philippe" 09/15/2003 09:34 AM Please respond to philippe.desfray To: Branislav Selic/Ottawa/IBM@IBMCA, "'Moore, Alan'" cc: "'UML2 Superstructure FTF \(E-mail\)'" Subject: RE: Confusion regarding XMI for use of stereotypes Alan, Stereotypes are defined at the same level than the meta-meta model (MOF or M3, ... for short). The notions "Stereotype", "Extension" "Profile" are at the same level than the "meta meta Class" or the "metameta "Association". So Figure 446 (profile metamodel) is a M3 metamodel, one level above the UML metamodel. Figure 456 is at the UML metamodel level : we have "Class" and "Component", which are instances of the (meta meta) "Class" we have "Clock" which is an instance of "Stereotype". "Clock" is related to "Class" and "Component" through "extension occurences". This is entirely similar to a picture where you have "State" related through an association (or you can say "association occurence") to "Transition". (Extension is a kind of association ... at the M3 metalevel). Then, at the M1 level, which is the usual UML modeling level, you can connect through a "link" (the instanciation scheme of an association, or similarly of an extension) an instance of "Class" (StopWatch) to an instance of "Clock" (anonymous). This is picture 457, 458 where to notations are presented, and the instance model is schown. I do not see any issue here, though I recognize that the 3 levels of modeling do not help understanding. Best regards -- Philippe DESFRAY VP for R& D phd@softeam.fr SOFTEAM - Objecteering Software --------Think Object 144 avenue des Champs Elysées - 75008 PARIS - Tel (33 1) 53968400 - Fax (33 1) 53968401 -- -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : vendredi 12 septembre 2003 16:13 À : Moore, Alan Cc : UML2 Superstructure FTF (E-mail) Objet : Re: Confusion regarding XMI for use of stereotypes Alan, This has been raised as an issue already, although not in the context of the specific figure (so, I leave it up to you whether you want to raise a new issue or not). Regarding a possible solution, I am attaching a document that proposes one but it has problems -- notably that it does not scale up very well (this is fairly obvious from the diagrams, actually). Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Moore, Alan" 09/12/2003 08:43 AM To: "UML2 Superstructure FTF (E-mail)" cc: Subject: Confusion regarding XMI for use of stereotypes I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Thanks in Advance, Alan. From: "Moore, Alan" To: "'philippe.desfray@softeam.fr'" , "'Branislav Selic'" Cc: "'UML2 Superstructure FTF (E-mail)'" Subject: RE: Confusion regarding XMI for use of stereotypes Date: Tue, 16 Sep 2003 10:26:29 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) It's clear (ish) from chapter 18 that Phillippe is correct - note that Stereotype is subclassed from Constructs::Class, not Kernel::Class - I assume that Constructs is a package in MOF, although this should be stated - I completely missed this and was under the impression that Stereotype was part of the UML metamodel. So, that said, this approach does seem to be very different from profiles in UML 1.x, which were an M2 construct. I, like Bran, thought that the idea behind stereotypes was that tools could have a fixed schema and yet still allow user extensibility - it seems that UML 2.0 stereotypes do not support that idea and require a tool to have a dynamic schema. Apart from the vague notion of backwards compatibility there's nothing said about profile support in the RfP so there's no obvious objective requirement to go on, but I'd be interested in what the expectations of the modeling community were. Thoughts? -----Original Message----- From: DESFRAY Philippe [mailto:philippe.desfray@softeam.fr] Sent: 16 September 2003 08:54 To: 'Branislav Selic' Cc: 'Moore, Alan'; 'UML2 Superstructure FTF (E-mail)' Subject: RE: Confusion regarding XMI for use of stereotypes Bran, Well, I am not assuming. The way the specification is done, is that Stereotype is a kind of (meta)class, and "Extend" is a kind of (meta)association. The basic mechanisms of profiles are just the same as the usual principles of metaclass and meta-association. The flexibility of the profile mechanism is just that in order to add, combine or withdraw extensions to an existing UML element, it is only a matter of adding or withdrawing links between that element and extension instances (i.e. Stereotype instances). This gives the "semantics", and a specific attention has been given to provide instance models for that. (remeber the debate we had that instance semantics should be given overall in the spec). In addition, it has been checked that "usual XMI" would support this without any change. This is "MOF compatible" in that sense that "Extension" is just a kind of "pattern". This does not enforce or preclude any specific implementation of that mechanism, in particular if there are performance issues. Introducing implmentation hints, or "kludges" is a slippery path in which I am a bit reluctant to go. This is I think a global statement of the UML standard : the semantics is given, interchange format is provided, but the implementation is up to tool vendors. Expressing the contrary would be a surprising "juriprudence" case. May be a "discussion" enlighting this can be introduced as an addendum to the spec : The 3 metalevel semantics, and the fact that the instance model specifies the "semantics". -- Philippe DESFRAY VP for R& D phd@softeam.fr SOFTEAM - Objecteering Software --------Think Object 144 avenue des Champs Elysées - 75008 PARIS - Tel (33 1) 53968400 - Fax (33 1) 53968401 -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : lundi 15 septembre 2003 20:58 À : philippe.desfray@softeam.fr Cc : 'Moore, Alan'; 'UML2 Superstructure FTF (E-mail)' Objet : RE: Confusion regarding XMI for use of stereotypes Philippe, It seems to me that you are assuming a specific type of model repository: one that dynamiclly adjusts its metamodel as new stereotypes are defined. While this is one way to implement model repositories, it is not the only way and may not be favoured by all tool vendors (e.g. due to performance and scalability concerns). Thus, using the example in figure 458 of the spec, you are assuming that a model repository will create an instance of "Clock", which is a stereotype that was encountered dynamically when some M1 model was loaded into the repository. If you recall, one of the constraints that were imposed on profiles in 1.x was to avoid assumptions that a UML tool necessarily had to be a metamodeling tool. This is why it was desireable to have an alternative way of representing stereotypes using techniques such as the one based on instance specs that I outlined in my previous note. However, as Alan pointed out, this has problems and may require a "kludge". Do you have any opinions or ideas on how we can avoid this? If so, we should think about including some reference to this in the spec itself. Thanks, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "DESFRAY Philippe" 09/15/2003 09:34 AM Please respond to philippe.desfray To: Branislav Selic/Ottawa/IBM@IBMCA, "'Moore, Alan'" cc: "'UML2 Superstructure FTF \(E-mail\)'" Subject: RE: Confusion regarding XMI for use of stereotypes Alan, Stereotypes are defined at the same level than the meta-meta model (MOF or M3, ... for short). The notions "Stereotype", "Extension" "Profile" are at the same level than the "meta meta Class" or the "metameta "Association". So Figure 446 (profile metamodel) is a M3 metamodel, one level above the UML metamodel. Figure 456 is at the UML metamodel level : we have "Class" and "Component", which are instances of the (meta meta) "Class" we have "Clock" which is an instance of "Stereotype". "Clock" is related to "Class" and "Component" through "extension occurences". This is entirely similar to a picture where you have "State" related through an association (or you can say "association occurence") to "Transition". (Extension is a kind of association ... at the M3 metalevel). Then, at the M1 level, which is the usual UML modeling level, you can connect through a "link" (the instanciation scheme of an association, or similarly of an extension) an instance of "Class" (StopWatch) to an instance of "Clock" (anonymous). This is picture 457, 458 where to notations are presented, and the instance model is schown. I do not see any issue here, though I recognize that the 3 levels of modeling do not help understanding. Best regards -- Philippe DESFRAY VP for R& D phd@softeam.fr SOFTEAM - Objecteering Software --------Think Object 144 avenue des Champs Elysées - 75008 PARIS - Tel (33 1) 53968400 - Fax (33 1) 53968401 -- -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : vendredi 12 septembre 2003 16:13 À : Moore, Alan Cc : UML2 Superstructure FTF (E-mail) Objet : Re: Confusion regarding XMI for use of stereotypes Alan, This has been raised as an issue already, although not in the context of the specific figure (so, I leave it up to you whether you want to raise a new issue or not). Regarding a possible solution, I am attaching a document that proposes one but it has problems -- notably that it does not scale up very well (this is fairly obvious from the diagrams, actually). Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Moore, Alan" 09/12/2003 08:43 AM To: "UML2 Superstructure FTF (E-mail)" cc: Subject: Confusion regarding XMI for use of stereotypes I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Thanks in Advance, Alan. Reply-To: From: "DESFRAY Philippe" To: "'Moore, Alan'" , "'Branislav Selic'" Cc: "'UML2 Superstructure FTF \(E-mail\)'" Subject: RE: Confusion regarding XMI for use of stereotypes Date: Wed, 17 Sep 2003 10:32:30 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal During the good old days of the U2P core team, there were passionated debates inside the infrastructure, between MOF originated people, and UML/Profile people : it lasted at least two years. I wrote a requirement document explaining the specific requirements for profiles, as opposed to a MOF based approach. Unfortunately, I cannot find it again (probably some defects in my personal configuration management ;-). It was on our U2P web server. Can someone help me to recover it? I think the answer to Alan's question is there. -- Philippe DESFRAY VP for R& D phd@softeam.fr SOFTEAM - Objecteering Software --------Think Object 144 avenue des Champs Elysées - 75008 PARIS - Tel (33 1) 53968400 - Fax (33 1) 53968401 -----Message d'origine----- De : Moore, Alan [mailto:AlanM@artisansw.com] Envoyé : mardi 16 septembre 2003 11:26 À : 'philippe.desfray@softeam.fr'; 'Branislav Selic' Cc : 'UML2 Superstructure FTF (E-mail)' Objet : RE: Confusion regarding XMI for use of stereotypes It's clear (ish) from chapter 18 that Phillippe is correct - note that Stereotype is subclassed from Constructs::Class, not Kernel::Class - I assume that Constructs is a package in MOF, although this should be stated - I completely missed this and was under the impression that Stereotype was part of the UML metamodel. So, that said, this approach does seem to be very different from profiles in UML 1.x, which were an M2 construct. I, like Bran, thought that the idea behind stereotypes was that tools could have a fixed schema and yet still allow user extensibility - it seems that UML 2.0 stereotypes do not support that idea and require a tool to have a dynamic schema. Apart from the vague notion of backwards compatibility there's nothing said about profile support in the RfP so there's no obvious objective requirement to go on, but I'd be interested in what the expectations of the modeling community were. Thoughts? -----Original Message----- From: DESFRAY Philippe [mailto:philippe.desfray@softeam.fr] Sent: 16 September 2003 08:54 To: 'Branislav Selic' Cc: 'Moore, Alan'; 'UML2 Superstructure FTF (E-mail)' Subject: RE: Confusion regarding XMI for use of stereotypes Bran, Well, I am not assuming. The way the specification is done, is that Stereotype is a kind of (meta)class, and "Extend" is a kind of (meta)association. The basic mechanisms of profiles are just the same as the usual principles of metaclass and meta-association. The flexibility of the profile mechanism is just that in order to add, combine or withdraw extensions to an existing UML element, it is only a matter of adding or withdrawing links between that element and extension instances (i.e. Stereotype instances). This gives the "semantics", and a specific attention has been given to provide instance models for that. (remeber the debate we had that instance semantics should be given overall in the spec). In addition, it has been checked that "usual XMI" would support this without any change. This is "MOF compatible" in that sense that "Extension" is just a kind of "pattern". This does not enforce or preclude any specific implementation of that mechanism, in particular if there are performance issues. Introducing implmentation hints, or "kludges" is a slippery path in which I am a bit reluctant to go. This is I think a global statement of the UML standard : the semantics is given, interchange format is provided, but the implementation is up to tool vendors. Expressing the contrary would be a surprising "juriprudence" case. May be a "discussion" enlighting this can be introduced as an addendum to the spec : The 3 metalevel semantics, and the fact that the instance model specifies the "semantics". -- Philippe DESFRAY VP for R& D phd@softeam.fr SOFTEAM - Objecteering Software --------Think Object 144 avenue des Champs Elysées - 75008 PARIS - Tel (33 1) 53968400 - Fax (33 1) 53968401 -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : lundi 15 septembre 2003 20:58 À : philippe.desfray@softeam.fr Cc : 'Moore, Alan'; 'UML2 Superstructure FTF (E-mail)' Objet : RE: Confusion regarding XMI for use of stereotypes Philippe, It seems to me that you are assuming a specific type of model repository: one that dynamiclly adjusts its metamodel as new stereotypes are defined. While this is one way to implement model repositories, it is not the only way and may not be favoured by all tool vendors (e.g. due to performance and scalability concerns). Thus, using the example in figure 458 of the spec, you are assuming that a model repository will create an instance of "Clock", which is a stereotype that was encountered dynamically when some M1 model was loaded into the repository. If you recall, one of the constraints that were imposed on profiles in 1.x was to avoid assumptions that a UML tool necessarily had to be a metamodeling tool. This is why it was desireable to have an alternative way of representing stereotypes using techniques such as the one based on instance specs that I outlined in my previous note. However, as Alan pointed out, this has problems and may require a "kludge". Do you have any opinions or ideas on how we can avoid this? If so, we should think about including some reference to this in the spec itself. Thanks, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "DESFRAY Philippe" 09/15/2003 09:34 AM Please respond to philippe.desfray To: Branislav Selic/Ottawa/IBM@IBMCA, "'Moore, Alan'" cc: "'UML2 Superstructure FTF \(E-mail\)'" Subject: RE: Confusion regarding XMI for use of stereotypes Alan, Stereotypes are defined at the same level than the meta-meta model (MOF or M3, ... for short). The notions "Stereotype", "Extension" "Profile" are at the same level than the "meta meta Class" or the "metameta "Association". So Figure 446 (profile metamodel) is a M3 metamodel, one level above the UML metamodel. Figure 456 is at the UML metamodel level : we have "Class" and "Component", which are instances of the (meta meta) "Class" we have "Clock" which is an instance of "Stereotype". "Clock" is related to "Class" and "Component" through "extension occurences". This is entirely similar to a picture where you have "State" related through an association (or you can say "association occurence") to "Transition". (Extension is a kind of association ... at the M3 metalevel). Then, at the M1 level, which is the usual UML modeling level, you can connect through a "link" (the instanciation scheme of an association, or similarly of an extension) an instance of "Class" (StopWatch) to an instance of "Clock" (anonymous). This is picture 457, 458 where to notations are presented, and the instance model is schown. I do not see any issue here, though I recognize that the 3 levels of modeling do not help understanding. Best regards -- Philippe DESFRAY VP for R& D phd@softeam.fr SOFTEAM - Objecteering Software --------Think Object 144 avenue des Champs Elysées - 75008 PARIS - Tel (33 1) 53968400 - Fax (33 1) 53968401 -- -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : vendredi 12 septembre 2003 16:13 À : Moore, Alan Cc : UML2 Superstructure FTF (E-mail) Objet : Re: Confusion regarding XMI for use of stereotypes Alan, This has been raised as an issue already, although not in the context of the specific figure (so, I leave it up to you whether you want to raise a new issue or not). Regarding a possible solution, I am attaching a document that proposes one but it has problems -- notably that it does not scale up very well (this is fairly obvious from the diagrams, actually). Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Moore, Alan" 09/12/2003 08:43 AM To: "UML2 Superstructure FTF (E-mail)" cc: Subject: Confusion regarding XMI for use of stereotypes I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Thanks in Advance, Alan. From: "Moore, Alan" To: "'philippe.desfray@softeam.fr'" , "'Branislav Selic'" Cc: "'UML2 Superstructure FTF (E-mail)'" Subject: RE: Confusion regarding XMI for use of stereotypes Date: Wed, 17 Sep 2003 15:31:05 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) It seems to me that there still is a minor problem with the metamodel. >From my reading of the spec, only packages that specialise Constructs::Package can have a Profile Application. Whereas I think that the packages to which we need to apply profiles are those packages that specialise Kernel::Package. Even if I'm right, it is probably minor, but the people that write abstract syntax checkers should bear this in mind. Alan. -----Original Message----- From: DESFRAY Philippe [mailto:philippe.desfray@softeam.fr] Sent: 17 September 2003 09:33 To: 'Moore, Alan'; 'Branislav Selic' Cc: 'UML2 Superstructure FTF (E-mail)' Subject: RE: Confusion regarding XMI for use of stereotypes During the good old days of the U2P core team, there were passionated debates inside the infrastructure, between MOF originated people, and UML/Profile people : it lasted at least two years. I wrote a requirement document explaining the specific requirements for profiles, as opposed to a MOF based approach. Unfortunately, I cannot find it again (probably some defects in my personal configuration management ;-). It was on our U2P web server. Can someone help me to recover it? I think the answer to Alan's question is there. -- Philippe DESFRAY VP for R& D phd@softeam.fr SOFTEAM - Objecteering Software --------Think Object 144 avenue des Champs Elysées - 75008 PARIS - Tel (33 1) 53968400 - Fax (33 1) 53968401 -----Message d'origine----- De : Moore, Alan [mailto:AlanM@artisansw.com] Envoyé : mardi 16 septembre 2003 11:26 À : 'philippe.desfray@softeam.fr'; 'Branislav Selic' Cc : 'UML2 Superstructure FTF (E-mail)' Objet : RE: Confusion regarding XMI for use of stereotypes It's clear (ish) from chapter 18 that Phillippe is correct - note that Stereotype is subclassed from Constructs::Class, not Kernel::Class - I assume that Constructs is a package in MOF, although this should be stated - I completely missed this and was under the impression that Stereotype was part of the UML metamodel. So, that said, this approach does seem to be very different from profiles in UML 1.x, which were an M2 construct. I, like Bran, thought that the idea behind stereotypes was that tools could have a fixed schema and yet still allow user extensibility - it seems that UML 2.0 stereotypes do not support that idea and require a tool to have a dynamic schema. Apart from the vague notion of backwards compatibility there's nothing said about profile support in the RfP so there's no obvious objective requirement to go on, but I'd be interested in what the expectations of the modeling community were. Thoughts? -----Original Message----- From: DESFRAY Philippe [mailto:philippe.desfray@softeam.fr] Sent: 16 September 2003 08:54 To: 'Branislav Selic' Cc: 'Moore, Alan'; 'UML2 Superstructure FTF (E-mail)' Subject: RE: Confusion regarding XMI for use of stereotypes Bran, Well, I am not assuming. The way the specification is done, is that Stereotype is a kind of (meta)class, and "Extend" is a kind of (meta)association. The basic mechanisms of profiles are just the same as the usual principles of metaclass and meta-association. The flexibility of the profile mechanism is just that in order to add, combine or withdraw extensions to an existing UML element, it is only a matter of adding or withdrawing links between that element and extension instances (i.e. Stereotype instances). This gives the "semantics", and a specific attention has been given to provide instance models for that. (remeber the debate we had that instance semantics should be given overall in the spec). In addition, it has been checked that "usual XMI" would support this without any change. This is "MOF compatible" in that sense that "Extension" is just a kind of "pattern". This does not enforce or preclude any specific implementation of that mechanism, in particular if there are performance issues. Introducing implmentation hints, or "kludges" is a slippery path in which I am a bit reluctant to go. This is I think a global statement of the UML standard : the semantics is given, interchange format is provided, but the implementation is up to tool vendors. Expressing the contrary would be a surprising "juriprudence" case. May be a "discussion" enlighting this can be introduced as an addendum to the spec : The 3 metalevel semantics, and the fact that the instance model specifies the "semantics". -- Philippe DESFRAY VP for R& D phd@softeam.fr SOFTEAM - Objecteering Software --------Think Object 144 avenue des Champs Elysées - 75008 PARIS - Tel (33 1) 53968400 - Fax (33 1) 53968401 -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : lundi 15 septembre 2003 20:58 À : philippe.desfray@softeam.fr Cc : 'Moore, Alan'; 'UML2 Superstructure FTF (E-mail)' Objet : RE: Confusion regarding XMI for use of stereotypes Philippe, It seems to me that you are assuming a specific type of model repository: one that dynamiclly adjusts its metamodel as new stereotypes are defined. While this is one way to implement model repositories, it is not the only way and may not be favoured by all tool vendors (e.g. due to performance and scalability concerns). Thus, using the example in figure 458 of the spec, you are assuming that a model repository will create an instance of "Clock", which is a stereotype that was encountered dynamically when some M1 model was loaded into the repository. If you recall, one of the constraints that were imposed on profiles in 1.x was to avoid assumptions that a UML tool necessarily had to be a metamodeling tool. This is why it was desireable to have an alternative way of representing stereotypes using techniques such as the one based on instance specs that I outlined in my previous note. However, as Alan pointed out, this has problems and may require a "kludge". Do you have any opinions or ideas on how we can avoid this? If so, we should think about including some reference to this in the spec itself. Thanks, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "DESFRAY Philippe" 09/15/2003 09:34 AM Please respond to philippe.desfray To: Branislav Selic/Ottawa/IBM@IBMCA, "'Moore, Alan'" cc: "'UML2 Superstructure FTF \(E-mail\)'" Subject: RE: Confusion regarding XMI for use of stereotypes Alan, Stereotypes are defined at the same level than the meta-meta model (MOF or M3, ... for short). The notions "Stereotype", "Extension" "Profile" are at the same level than the "meta meta Class" or the "metameta "Association". So Figure 446 (profile metamodel) is a M3 metamodel, one level above the UML metamodel. Figure 456 is at the UML metamodel level : we have "Class" and "Component", which are instances of the (meta meta) "Class" we have "Clock" which is an instance of "Stereotype". "Clock" is related to "Class" and "Component" through "extension occurences". This is entirely similar to a picture where you have "State" related through an association (or you can say "association occurence") to "Transition". (Extension is a kind of association ... at the M3 metalevel). Then, at the M1 level, which is the usual UML modeling level, you can connect through a "link" (the instanciation scheme of an association, or similarly of an extension) an instance of "Class" (StopWatch) to an instance of "Clock" (anonymous). This is picture 457, 458 where to notations are presented, and the instance model is schown. I do not see any issue here, though I recognize that the 3 levels of modeling do not help understanding. Best regards -- Philippe DESFRAY VP for R& D phd@softeam.fr SOFTEAM - Objecteering Software --------Think Object 144 avenue des Champs Elysées - 75008 PARIS - Tel (33 1) 53968400 - Fax (33 1) 53968401 -- -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : vendredi 12 septembre 2003 16:13 À : Moore, Alan Cc : UML2 Superstructure FTF (E-mail) Objet : Re: Confusion regarding XMI for use of stereotypes Alan, This has been raised as an issue already, although not in the context of the specific figure (so, I leave it up to you whether you want to raise a new issue or not). Regarding a possible solution, I am attaching a document that proposes one but it has problems -- notably that it does not scale up very well (this is fairly obvious from the diagrams, actually). Cheers, Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Moore, Alan" 09/12/2003 08:43 AM To: "UML2 Superstructure FTF (E-mail)" cc: Subject: Confusion regarding XMI for use of stereotypes I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Thanks in Advance, Alan. Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 11 Mar 2004 19:08:55 -0800 To: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: , cl, Issues 6242 and 6243 How many questions? Guus wrote: The definition of navigability is broken in that it no longer allows UML 1.x models where associations owned their ends, and where "isNavigable" can be set for those associations. So, i was wrong when i wrote "this is t h e issue." .......................... These questions each are two questions, where is 'Is it the case that' and then 'Should it be the case that.' there are slots for ends on links of plain associations? there are slots for ends on link objects of association classes? an end of an association class, if not an attribute of the associated class, is an attribute of that association class? if an association owns an end, isNavigable can be set for that end. PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Date: Fri, 19 Mar 2004 15:19:21 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Joaquin Miller CC: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: , cl, Issues 6242 and 6243 How many questions? Joaquin, > there are slots for ends on links of plain associations? True in UML 2.0 FAS spec > an end of an association class, if not an attribute of the associated class, is an attribute of that association class? True in UML 2.0 FAS spec > if an association owns an end, isNavigable can be set for that end. Not true in UMl 2.0 FAS spec (it used to be true in UMl 1.x). This is the core of the issue. As Conrad quotes from the FAS, the current spec has a narrow interpretation of navigability in that its definition is "Navigability = a class owning an association end" : > When a property is owned by an association it represents a non-navigable end of the association. In this case the property does not appear in the namespace of any of the associated classifiers. When a property at an end of an association is owned by one of the associated classifiers it represents a navigable end of the association. In this case the property is also an attribute of the associated classifier. Only binary associations may have navigable ends There is not a big issue here (as Bran has indicated in this thread), just a re-alignment to allow users to add an arrowhead to an association, when that association owns its ends. Now that we understand the issue, perhaps those who would like to see it resolved can make one or more concrete proposals. I am happy to contribute to that. Thanks, Guus Joaquin Miller wrote: Guus wrote: The definition of navigability is broken in that it no longer allows UML 1.x models where associations owned their ends, and where "isNavigable" can be set for those associations. So, i was wrong when i wrote "this is t h e issue." .......................... These questions each are two questions, where is 'Is it the case that' and then 'Should it be the case that.' there are slots for ends on links of plain associations? there are slots for ends on link objects of association classes? an end of an association class, if not an attribute of the associated class, is an attribute of that association class? if an association owns an end, isNavigable can be set for that end. PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 and 6243 How many questions? Date: Fri, 19 Mar 2004 10:59:56 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Guus, et al, > > there are slots for ends on links of plain associations? > True in UML 2.0 FAS spec > > an end of an association class, if not an attribute of the > associated class, is an attribute of that association class? > True in UML 2.0 FAS spec If plain = not an association class, then the link can't have slots, because its not an object. In any case, as Figure 30 shows, the properties (ends) that are owned by an association are not attributes of the association, just features. The instance model (InstanceSpecification) only supports slots for structural features. > > if an association owns an end, isNavigable can be set for that end. > Not true in UMl 2.0 FAS spec (it used to be true in UMl 1.x). > This is the core of the issue. Agreed, there is no isNavigable in the FAS. It is conflated with ownership, which I would say is the core issue. > As Conrad quotes from the FAS, the current spec has a narrow > interpretation of navigability in that its definition is > "Navigability = a class owning an association end" : > > > When a property is owned by an association it represents a > non-navigable end of the association. In this case the property does > not appear in the namespace of any of the associated > classifiers. When a property at an end of an association is owned by > one of the associated classifiers it represents a navigable end of > the association. In this case the property is also an attribute of > the associated classifier. Only binary associations may have > navigable ends > There is not a big issue here (as Bran has indicated in this > thread), just a re-alignment to allow users to add an arrowhead > to an association, when that association owns its ends. Not sure if its big or small, but it's more than notation. The isNavigable attribute needs to be reintroduced, because otherwise the association that owns both ends can't model one-way navigation. The arrows can follow the settings for isNavigable. > Now that we understand the issue, perhaps those who would like > to see it resolved can make one or more concrete proposals. I am > happy to contribute to that. Likewise. My sketch is below. If we agree on the general description of changes, a detailed proposal can follow. Conrad - Add isNavigable (underived) on Property, default true. Clarify that navigation = efficient access, and that lack of it just means there is no requirement for efficient access. Vendors can still provide efficient access in any direction they what (where-used, etc). - Properties used as association ends can be owned by the end classes or the association. - isNavigable = true for Properties that are ownedAttributes of classes, whether or not they are used as association ends. - isNavigable can be either true or false for Properties owned by associations that are also used as ends (note: these are not ownedAttributes of the association, if the association is a class). - Delete existing text that determines navigability by ownership of the end property. Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 19 Mar 2004 08:23:26 -0800 To: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: ,cl, Issues 6242 and 6243 How many answers? Thanks, Guus. So, unless i am mistaken, there is a difference of opinion on this among the FTF members. To the question: > An end of an association class, if not an attribute of the associated class, is an attribute of that association class? Some answer T some F. I'll look at these two issues again and see if there is room for a separate issue on this specific topic. In any event, we owe it to our users to make the answer clear, whichever way it goes. Guus Ramackers wrote: Joaquin, > there are slots for ends on links of plain associations? True in UML 2.0 FAS spec > an end of an association class, if not an attribute of the associated class, is an attribute of that association class? True in UML 2.0 FAS spec > if an association owns an end, isNavigable can be set for that end. Not true in UMl 2.0 FAS spec (it used to be true in UMl 1.x). This is the core of the issue. As Conrad quotes from the FAS, the current spec has a narrow interpretation of navigability in that its definition is "Navigability = a class owning an association end" : > When a property is owned by an association it represents a non-navigable end of the association. In this case the property does not appear in the namespace of any of the associated classifiers. When a property at an end of an association is owned by one of the associated classifiers it represents a navigable end of the association. In this case the property is also an attribute of the associated classifier. Only binary associations may have navigable ends There is not a big issue here (as Bran has indicated in this thread), just a re-alignment to allow users to add an arrowhead to an association, when that association owns its ends. Now that we understand the issue, perhaps those who would like to see it resolved can make one or more concrete proposals. I am happy to contribute to that. Thanks, Guus Joaquin Miller wrote: Guus wrote: The definition of navigability is broken in that it no longer allows UML 1.x models where associations owned their ends, and where "isNavigable" can be set for those associations. So, i was wrong when i wrote "this is t h e issue." .......................... These questions each are two questions, where is 'Is it the case that' and then 'Should it be the case that.' there are slots for ends on links of plain associations? there are slots for ends on link objects of association classes? an end of an association class, if not an attribute of the associated class, is an attribute of that association class? if an association owns an end, isNavigable can be set for that end. PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Date: Fri, 19 Mar 2004 16:40:35 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: conrad.bock@nist.gov CC: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: , cl, Issues 6242 and 6243 How many questions? Conrad, This sounds good. Some suggestions for sharpening the proposal: - Add isNavigable (underived) on Property, default true. Clarify that navigation = efficient access, and that lack of it just means there is no requirement for efficient access. Vendors can still provide efficient access in any direction they what (where-used, etc). - Properties used as association ends can be owned by the end classes or the association. This is already covered in the spec - can be removed from this list perhaps. - isNavigable = true for Properties that are ownedAttributes of classes, whether or not they are used as association ends. Should supply OCL for the rule - isNavigable can be either true or false for Properties owned by associations that are also used as ends (note: these are not ownedAttributes of the association, if the association is a class). Logically, this doesn't add anything ("can be true or false") - what is the essence of what you are trying to say here? Otherwise it can be dropped from the list. - Delete existing text that determines navigability by ownership of the end property. Perhaps "Update the existing text in section 7.11.2 re. navigability" Guus Conrad Bock wrote: Guus, et al, > > there are slots for ends on links of plain associations? > True in UML 2.0 FAS spec > > an end of an association class, if not an attribute of the > associated class, is an attribute of that association class? > True in UML 2.0 FAS spec If plain = not an association class, then the link can't have slots, because its not an object. In any case, as Figure 30 shows, the properties (ends) that are owned by an association are not attributes of the association, just features. The instance model (InstanceSpecification) only supports slots for structural features. > > if an association owns an end, isNavigable can be set for that end. > Not true in UMl 2.0 FAS spec (it used to be true in UMl 1.x). > This is the core of the issue. Agreed, there is no isNavigable in the FAS. It is conflated with ownership, which I would say is the core issue. > As Conrad quotes from the FAS, the current spec has a narrow > interpretation of navigability in that its definition is > "Navigability = a class owning an association end" : > > > When a property is owned by an association it represents a > non-navigable end of the association. In this case the property does > not appear in the namespace of any of the associated > classifiers. When a property at an end of an association is owned by > one of the associated classifiers it represents a navigable end of > the association. In this case the property is also an attribute of > the associated classifier. Only binary associations may have > navigable ends > There is not a big issue here (as Bran has indicated in this > thread), just a re-alignment to allow users to add an arrowhead > to an association, when that association owns its ends. Not sure if its big or small, but it's more than notation. The isNavigable attribute needs to be reintroduced, because otherwise the association that owns both ends can't model one-way navigation. The arrows can follow the settings for isNavigable. > Now that we understand the issue, perhaps those who would like > to see it resolved can make one or more concrete proposals. I am > happy to contribute to that. Likewise. My sketch is below. If we agree on the general description of changes, a detailed proposal can follow. Conrad - Add isNavigable (underived) on Property, default true. Clarify that navigation = efficient access, and that lack of it just means there is no requirement for efficient access. Vendors can still provide efficient access in any direction they what (where-used, etc). - Properties used as association ends can be owned by the end classes or the association. - isNavigable = true for Properties that are ownedAttributes of classes, whether or not they are used as association ends. - isNavigable can be either true or false for Properties owned by associations that are also used as ends (note: these are not ownedAttributes of the association, if the association is a class). - Delete existing text that determines navigability by ownership of the end property. -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Reply-To: From: "Conrad Bock" To: , , Subject: RE: ,cl, Issues 6242 and 6243 How many answers? Date: Fri, 19 Mar 2004 12:27:09 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal > To the question: > > An end of an association class, if not an attribute of the > associated class, is an attribute of that association class? > > Some answer T some F. The metamodel in Figure 30 is unambiguous, it says F. Ends are features at best. Not all features are attributes, and the actions for reading attributes require structural features (there are other actions for reading the ends of association objects, thank goodness). So unless there's some other part of the spec that modifies Figure 30, that's the answer. You should file an issue if you think it shouldn't be that way. Conirad Date: Fri, 19 Mar 2004 17:33:28 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Joaquin Miller CC: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Issues 6242 and 6243 How many answers? Joaquin, Yes, I think it would be very helpful to separate the different issues. - definition of navigability - exact role of association ends in the context of an association class On the latter issue the spec says very little (section 7.16.1) which explains why there are different interpretations. To clarify why I thought the answer to this question was True: Basically it says "an association class is an association and a class" (multiple supertypes). - as an association its ends may be owned by the participating classifiers, or it may be owned by the association itself. - if the properties are owned by the association itself, and that association is an association class, then effectively it is the AssociationClass that owns the association end properties. These properties cannot be distinguished from any other properties that the AssociationClass owns as a class. Ergo: > > An end of an association class, if not an attribute of the associated class, is an attribute of that association class? Is true. Because of the subtyping relationship we could have also said: > > An end of an association class, if not an attribute of the associated class, is an attribute of that association? But as above - this is a separate issue to navigability. Guus Joaquin Miller wrote: Thanks, Guus. So, unless i am mistaken, there is a difference of opinion on this among the FTF members. To the question: > An end of an association class, if not an attribute of the associated class, is an attribute of that association class? Some answer T some F. I'll look at these two issues again and see if there is room for a separate issue on this specific topic. In any event, we owe it to our users to make the answer clear, whichever way it goes. Guus Ramackers wrote: Joaquin, > there are slots for ends on links of plain associations? True in UML 2.0 FAS spec > an end of an association class, if not an attribute of the associated class, is an attribute of that association class? True in UML 2.0 FAS spec > if an association owns an end, isNavigable can be set for that end. Not true in UMl 2.0 FAS spec (it used to be true in UMl 1.x). This is the core of the issue. As Conrad quotes from the FAS, the current spec has a narrow interpretation of navigability in that its definition is "Navigability = a class owning an association end" : > When a property is owned by an association it represents a non-navigable end of the association. In this case the property does not appear in the namespace of any of the associated classifiers. When a property at an end of an association is owned by one of the associated classifiers it represents a navigable end of the association. In this case the property is also an attribute of the associated classifier. Only binary associations may have navigable ends There is not a big issue here (as Bran has indicated in this thread), just a re-alignment to allow users to add an arrowhead to an association, when that association owns its ends. Now that we understand the issue, perhaps those who would like to see it resolved can make one or more concrete proposals. I am happy to contribute to that. Thanks, Guus Joaquin Miller wrote: Guus wrote: The definition of navigability is broken in that it no longer allows UML 1.x models where associations owned their ends, and where "isNavigable" can be set for those associations. So, i was wrong when i wrote "this is t h e issue." .......................... These questions each are two questions, where is 'Is it the case that' and then 'Should it be the case that.' there are slots for ends on links of plain associations? there are slots for ends on link objects of association classes? an end of an association class, if not an attribute of the associated class, is an attribute of that association class? if an association owns an end, isNavigable can be set for that end. PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Date: Fri, 19 Mar 2004 17:52:32 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: conrad.bock@nist.gov CC: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Issues 6242 and 6243 How many answers? Conrad, I agree - contrary to my earlier mail... > Not all features are attributes Or narrowed to this problem area : Not all properties are attributes. >> An end of an association class, if not an attribute of the associated class, is an attribute of that association class? It is only correct if stated as : >> An end of an association class, if not a property of the associated class, is a property of that association class? Thanks, Guus > To the question: > > An end of an association class, if not an attribute of the > associated class, is an attribute of that association class? > > Some answer T some F. The metamodel in Figure 30 is unambiguous, it says F. Ends are features at best. Not all features are attributes, and the actions for reading attributes require structural features (there are other actions for reading the ends of association objects, thank goodness). So unless there's some other part of the spec that modifies Figure 30, that's the answer. You should file an issue if you think it shouldn't be that way. Conirad -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 19 Mar 2004 10:46:44 -0800 To: , , From: Joaquin Miller Subject: RE: ,cl, Issues 6242 and 6243 How many answers? Conrad, this particular problem does not have anything to do with what i think should or should not be. > To the question: An end of an association class, if not an attribute of the associated class, is an attribute of that association class? Some answer T some F. The metamodel in Figure 30 is unambiguous, it says F. I'm sure you are right, as usual. And the text in 7.11.4 is unambiguous, it says T. Guus has sent a detailed explanation of his answer to the list. The text reads: "When a property is owned by a class it represents an attribute." ======================== As to how i feel: It will be a service to programmers if the ends we are discussing are attributes of the association class. Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 19 Mar 2004 10:48:42 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: Re: ,cl, Issues 6242 and 6243 How many answers? ... narrowed to this problem area : Not all properties are attributes. >> An end of an association class, if not an attribute of the associated class, is an attribute of that association class? It is only correct if stated as : >> An end of an association class, if not a property of the associated class, is a property of that association class? That is a good question. The answer may be clear and not disputed. But not mine. My question is: >> An end of an association class, if not an attribute of the associated class, is an attribute of that association class? PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Subject: RE: ,cl, Issues 6242 and 6243 How many answers? Date: Fri, 19 Mar 2004 17:17:54 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issues 6242 and 6243 How many answers? Thread-Index: AcQN2buIzOVxrnCRRraMkuJoj8DseQAJLnUw From: "Pete Rivett" To: "Guus Ramackers" , "Joaquin Miller" Cc: , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i2JM9Vre018384 Guus' analysis makes sense to me. I don't agree Conrad's assertion that Figure 30 makes things obvious: in particular since it does not include AssociationClass at all! What we don't have is a diagram including AssociationClass that shows the meta-association subsetting specific to that class at the same level of detail as Figure 30. IMHO I don't think we'll get a definitive answer from the current spec. Perhaps we should focus discussion on what we think the answer *should* be and then ensure that's made very apparent in the spec. FWIW I think the answer should be True for the reasons put forward by Guus. 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: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Friday, March 19, 2004 5:33 PM To: Joaquin Miller Cc: mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Issues 6242 and 6243 How many answers? Joaquin, Yes, I think it would be very helpful to separate the different issues. - definition of navigability - exact role of association ends in the context of an association class On the latter issue the spec says very little (section 7.16.1) which explains why there are different interpretations. To clarify why I thought the answer to this question was True: Basically it says "an association class is an association and a class" (multiple supertypes). - as an association its ends may be owned by the participating classifiers, or it may be owned by the association itself. - if the properties are owned by the association itself, and that association is an association class, then effectively it is the AssociationClass that owns the association end properties. These properties cannot be distinguished from any other properties that the AssociationClass owns as a class. Ergo: > > An end of an association class, if not an attribute of the associated class, is an attribute of that association class? Is true. Because of the subtyping relationship we could have also said: > > An end of an association class, if not an attribute of the associated class, is an attribute of that association? But as above - this is a separate issue to navigability. Guus Joaquin Miller wrote: Thanks, Guus. So, unless i am mistaken, there is a difference of opinion on this among the FTF members. To the question: > An end of an association class, if not an attribute of the associated class, is an attribute of that association class? Some answer T some F. I'll look at these two issues again and see if there is room for a separate issue on this specific topic. In any event, we owe it to our users to make the answer clear, whichever way it goes. Guus Ramackers wrote: Joaquin, > there are slots for ends on links of plain associations? True in UML 2.0 FAS spec > an end of an association class, if not an attribute of the associated class, is an attribute of that association class? True in UML 2.0 FAS spec > if an association owns an end, isNavigable can be set for that end. Not true in UMl 2.0 FAS spec (it used to be true in UMl 1.x). This is the core of the issue. As Conrad quotes from the FAS, the current spec has a narrow interpretation of navigability in that its definition is "Navigability = a class owning an association end" : > When a property is owned by an association it represents a non-navigable end of the association. In this case the property does not appear in the namespace of any of the associated classifiers. When a property at an end of an association is owned by one of the associated classifiers it represents a navigable end of the association. In this case the property is also an attribute of the associated classifier. Only binary associations may have navigable ends There is not a big issue here (as Bran has indicated in this thread), just a re-alignment to allow users to add an arrowhead to an association, when that association owns its ends. Now that we understand the issue, perhaps those who would like to see it resolved can make one or more concrete proposals. I am happy to contribute to that. Thanks, Guus Joaquin Miller wrote: Guus wrote: The definition of navigability is broken in that it no longer allows UML 1.x models where associations owned their ends, and where "isNavigable" can be set for those associations. So, i was wrong when i wrote "this is t h e issue." .......................... These questions each are two questions, where is 'Is it the case that' and then 'Should it be the case that.' there are slots for ends on links of plain associations? there are slots for ends on link objects of association classes? an end of an association class, if not an attribute of the associated class, is an attribute of that association class? if an association owns an end, isNavigable can be set for that end. PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 To: Cc: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 and 6243 How many questions? X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sat, 20 Mar 2004 17:21:59 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/20/2004 17:22:03, Serialize complete at 03/20/2004 17:22:03 Conrad, The Classes Diagram shows that an association end is a Property (not a Feature as you said) -- which is a kind of StructuralFeature. This means that you can indeed have slots for link ends owned by a link. A link such as that CAN be specified by an InstanceSpecification, since an instance specification is typed by a Classifier -- and Association is a kind of Classifier. Bran To: Cc: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 and 6243 How many questions? X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sat, 20 Mar 2004 17:21:59 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/20/2004 17:22:03, Serialize complete at 03/20/2004 17:22:03 Conrad, The Classes Diagram shows that an association end is a Property (not a Feature as you said) -- which is a kind of StructuralFeature. This means that you can indeed have slots for link ends owned by a link. A link such as that CAN be specified by an InstanceSpecification, since an instance specification is typed by a Classifier -- and Association is a kind of Classifier. Bran Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 20 Mar 2004 16:03:11 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: ,cl, Issues 6242 and 6243 [Picture below for fixed space font] Forgetting what the FAS says, but just thinking about what is in this message, please answer my question: A [X]--------------[Y] p : q : [A] A is an association. X and Y are classes. p and q are names of association ends. A turns out to be an association class A is not navigable from X to Y (whatever 'navigable' might mean). So, the association end, q, of the association, A which end is about the role of Y in A is a feature or property of A. OK so far? ........ Now: (Supposing this were allowed) A is navigable from A to Y (whatever 'navigable' might mean). My question: What is the practical advantage of requiring that the association end, q, is n o t an attribute of the class, A? Thanks, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 and 6243 How many questions? Date: Sun, 21 Mar 2004 14:29:23 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Bran, > The Classes Diagram shows that an association end is a Property > (not a Feature as you said) -- which is a kind of > StructuralFeature. This means that you can indeed have slots for > link ends owned by a link. Look at the associations between Property and Association. The one called "ownedEnd" only subsets feature, not ownedAttribute. Ie, the ends are not attributes. That's intentional, I assume, because not all associations are association classes. "Normal" association can't have attributes. Conrad Reply-To: From: "Conrad Bock" To: , , Subject: ,cl, Ends for association classes = attributes? (was Issues 6242 and 6243 How many answers?) Date: Sun, 21 Mar 2004 14:43:25 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Pete, > I don't agree Conrad's assertion that Figure 30 makes things obvious: in > particular since it does not include AssociationClass at all! Right, but the abscence of: > What we don't have is a diagram including AssociationClass that shows > the meta-association subsetting specific to that class at the same level > of detail as Figure 30. Figure 30 is the only model that applies. I think the above is a good resolution (if someone chooses to file an issue!). > Perhaps we should focus discussion on what we think the answer *should* > be and then ensure that's made very apparent in the spec. Sure, we need to know what we want, but we also need to know whether the spec gives us what we want or not. Conrad Reply-To: From: "Conrad Bock" To: , , Subject: RE: ,cl, Ends for association classes = attributes? (was Issues 6242 and 6243 How many answers?) Date: Sun, 21 Mar 2004 15:02:25 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal P.S. Bran, you're right about slots on InstanceSpecification for ends that are owned by associations through ownedEnd (which may be the ones you were referring to), the only constraint is: [1] The defining feature of each slot is a structural feature (directly or inherited) of a classifier of the instance specification. slot->forAll(s | classifier->exists(c | c.allFeatures()->includes(s.definingFeature)) The OCL clarifies the text: slots on InstanceSpecification work for association ends as long as they are features, even if they are not attributes (ownedAttribute). Conrad To: Cc: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 and 6243 How many questions? X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sun, 21 Mar 2004 17:13:58 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/21/2004 17:14:02, Serialize complete at 03/21/2004 17:14:02 But, I thought your complaint was that association ends did not have corresponding slots in InstanceSpecifications -- which seems to me to be an incorrect conclusion. The fact that they association ends are not called "attributes" seems immaterial in this case -- they still have corresponding slots. According to the metamodel, a slot needs a corresponding structural feature. Fortunately, association ends are properties, and therefore, they are structural features, which means that they can have corresponding slots (in the link or in the object, depending on whether they are owned by the object or the link). So, your argument that they are "merely features", although correct, does not imply any problems with slots. Or am I missing something? Cheers, Bran "Conrad Bock" 03/21/2004 02:29 PM Please respond to conrad.bock To , , cc Subject RE: , cl, Issues 6242 and 6243 How many questions? Bran, > The Classes Diagram shows that an association end is a Property > (not a Feature as you said) -- which is a kind of > StructuralFeature. This means that you can indeed have slots for > link ends owned by a link. Look at the associations between Property and Association. The one called "ownedEnd" only subsets feature, not ownedAttribute. Ie, the ends are not attributes. That's intentional, I assume, because not all associations are association classes. "Normal" association can't have attributes. Conrad To: Cc: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 and 6243 How many questions? X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sun, 21 Mar 2004 17:13:58 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/21/2004 17:14:02, Serialize complete at 03/21/2004 17:14:02 But, I thought your complaint was that association ends did not have corresponding slots in InstanceSpecifications -- which seems to me to be an incorrect conclusion. The fact that they association ends are not called "attributes" seems immaterial in this case -- they still have corresponding slots. According to the metamodel, a slot needs a corresponding structural feature. Fortunately, association ends are properties, and therefore, they are structural features, which means that they can have corresponding slots (in the link or in the object, depending on whether they are owned by the object or the link). So, your argument that they are "merely features", although correct, does not imply any problems with slots. Or am I missing something? Cheers, Bran "Conrad Bock" 03/21/2004 02:29 PM Please respond to conrad.bock To , , cc Subject RE: , cl, Issues 6242 and 6243 How many questions? Bran, > The Classes Diagram shows that an association end is a Property > (not a Feature as you said) -- which is a kind of > StructuralFeature. This means that you can indeed have slots for > link ends owned by a link. Look at the associations between Property and Association. The one called "ownedEnd" only subsets feature, not ownedAttribute. Ie, the ends are not attributes. That's intentional, I assume, because not all associations are association classes. "Normal" association can't have attributes. Conrad Subject: RE: Navigability [was:, cl, Issues 6242 ] Date: Mon, 22 Mar 2004 20:26:45 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Navigability [was:, cl, Issues 6242 ] Thread-Index: AcQQNxffsIXS1wlRSoiNWe2egMdtegALR0Xg From: "Pete Rivett" To: "Guus Ramackers" Cc: , , , See below. 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: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Monday, March 22, 2004 5:49 PM To: Pete Rivett Cc: conrad.bock@nist.gov; mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: Navigability [was:, cl, Issues 6242 ] Pete, UML 1.x: isNavigable When placed on a target end, specifies whether traversal from a source instance to its associated target instances is possible. Specification of each direction across the Association is independent. A value of true means that the association can be navigated by the source class and the target rolename can be used in navigation expressions. UML 2.0 When a property is owned by an association it represents a non-navigable end of the association. In this case the property does not appear in the namespace of any of the associated classifiers. When a property at an end of an association is owned by one of the associated classifiers it represents a navigable end of the association. In this case the property is also an attribute of the associated classifier. Only binary associations may have navigable ends. As discussed in this mail thread, the UML 2.0 definition precludes associations that own their ends to be navigable (viz. have an arrowhead in the notation), but like UMl 1.x it implies that navigable = ability to traverse an association (since the object "holds a reference property"). Two options have been suggested: Extend the 2.0 definition to also cover navigability for associations that own their ends, and 1. Keep the basic definition 'narrow' (as in 1.x, 2.0), viz. navigability is ability to traverse, OR 2. Make the definition a bit weaker (as Conrad proposes), viz. navigability is ability for efficient traversal (but doesn't forbid traversal "the other way") The first option is least invasive, it just reinstates UML 1.x capability (to apply to associations that own their ends). [Pete Rivett] Let's be very concrete here to help understanding - and look at the implication on APIs. In particular let's take MOF APIs as a specific example since that's the one of the few formal standards we have for generating APIs from UML. Lets say we have a navigable association end that is not owned by a class. How would we expect that navigability to be expressed via generated MOF operation(s)? We would not have a property on the class (since that is reserved for properties owned by the class) and we have the ability to use the MOF Association interface in any case. The (apparent - to me anyway) difficulty of answering by generating any new operations leans me to say that option 2 makes more sense. Though I'm not convinced of either: I still think I'm missing the real requirement/use case here - I do a lot of information modeling, have engaged with several data modeling customers, and have done a lot with CWM - and I cannot recall any information model expressing any notion of 'efficient' navigation. Perhaps there's a community I have just not come across using hybrid UML-based Information Models. Again (I did ask for examples before), I'd genuinely like to find out more. What other efficiency hints should we have for information modeling - the ability to specify indexed properties? The second option does the same, but takes some practical feedback over the years into account to loosen the definition somewhat. This does not preclude a narrower interpretation (in profiles, in modeling processes) of navigability as traversal, but it recognizes that e.g. repository implementations may offer "reverse traversal APIs". If we can agree on which which of these two options, the issue of which text should be modified can be tackled next. If we can't agree, the default should probably be to stick with the interpretation of UML 1.x and UMl 2.0 that navigability = ability to traverse, and reinstate that to apply to associations that own their ends. [Pete Rivett] More specifically both UMLs say that not only navigability=ability to traverse but that also navigability=presence of property as part of the 'source' class. We're also here ignoring the aspect Bran raises in his issue 6460, which is navigability related to 'ability to send messages to'. Thanks, Guus Pete Rivett wrote: I'm not sure a resolution is needed for the issue as worded - which is for 'modeling associations without modifying the end types'. This is possible in the existing spec. The resolution actually addresses a different issue: that of 'modeling property navigability independently of property ownership'. I don't think this can really be resolved until we have an agreed definition of navigability - since currently the spec *equates* navigability with property ownership (that is the only semantic associated with navigability). This is different from UML 1.x admittedly, but the words in UML 1.x are also different from Conrad's desired definition which is more to do with *efficiency* of navigation than *possibility* of navigation. So it seems we should address issue 6460 first. Which has yet another proposal in the issue more biased towards the OO ability to send messages (which I assume will not satisfy the information modeling users that Conrad is championing). More specifically I don't think we can adopt Conrad's resolution which is to add 'isNavigable' to Property when it has no proposed description or semantics as to what it means! Also I think the resolution deletes too much without replacing it - e.g. 2nd paragraph of description of Associations. In its stead there should be a similar description about the interaction (or not) of ownership and navigability. And there should also probably be some new constraints e.g. if a property is owned by a class then I assume it must be navigable. 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 -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Sunday, March 21, 2004 7:33 PM To: mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: , cl, Issues 6242 (Association not affecting ends), proposed resolution Hi all, Here's a proposed resolution to Issue 6243: Association not affecting ends. It follows the sketch previously posted, except for: - Making isNavigable = true for properties related by ownedAttributes to class. That would have hosed Pete's resolution to the recent discussion about ends as attributes. - Clarifying the definition navigation, which is the topic of Infra Issue 6460: UML 2 Issue: definition of navigability. If it looks OK, I can propose the same changes to infra. Looks like the text is not exactly the same. Conrad P.S. This is not related to the recent discussion about associations ends being attributes. That issue hasn't been filed yet, as far as I vknow. -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Reply-To: From: "Conrad Bock" To: , , Subject: RE: ,cl, Ends for association classes = attributes? (was Issues 6242 and 6243 Date: Thu, 25 Mar 2004 08:02:58 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Bran, > According to the metamodel, a slot needs a corresponding structural > feature. Fortunately, association ends are properties, and > therefore, they are structural features, which means that they can > have corresponding slots (in the link or in the object, depending on > whether they are owned by the object or the link). The fact that > they association ends are not called "attributes" seems immaterial in > this case -- they still have corresponding slots. Only if the association is related to end via ownedMember (Figure 30), because it subsets features, and constraint 2 of InstanceSpecification allows that. Otherwise, the association is related by memberEnd (Figure 30), which only subsets member. Then constraint 2 of InstanceSpecification is not satisfied. > But, I thought your complaint was that association ends did not > have corresponding slots in InstanceSpecifications -- which > seems to me to be an incorrect conclusion. Actually, I've forgotton what we were debating! Conrad To: Cc: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), 6460, proposed resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 19 Apr 2004 10:08:02 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/19/2004 10:08:09, Serialize complete at 04/19/2004 10:08:09 Hi Conrad, Just to make sure I understand, I will try to explain what I think is the rationale behind your proposal -- perhaps you can tell me if I got it right (or, where I have it wrong): In UML 1.x, a navigable link end meant that it was possible to communicate with the object at the other end (actually, I'm not sure there was agreement on that, but let's not get into that) In UML 1.x a navigable link end did not require an attribute to be provided in the object at the other end For reasons of backward compatibility, you would like to separate the concept of owning a link end from the ability to communicate with the other end. It seems that in 1.x, we dealt with navigability at a more abstract level, without delving into the mechanism by which communication across links is achieved. In 2.0, we changed that. Now here is my problem: as far as I know, the only reason why an object would need to have an attribute for a link end is so that it can communicate with the other end. (Is there any other reason that I am missing?) If I'm right, then the two concepts are really not separable. So, it seems to me that what you are looking for is a selectable level of abstraction for modeling navigability, which, as you define it, is the ability to communicate across a link. Is this something that you would want to control at the level of individual associations or is it something that is chosen at the level of a model? I'd appreciate if you could help me here by commenting on the above. Thanks, Bran "Conrad Bock" 04/14/2004 02:12 PM Please respond to conrad.bock To , , cc Subject RE: , cl, Issues 6242 (Association not affecting ends), 6460, proposed resolutions Hi all, Here are proposed resolutions to super 6243 (associations not affecting ends) and infra 6460 (definition of navigability). It was agreed in telecon to address these together. Conrad[attachment "issueresolution-6243.doc" deleted by Branislav Selic/Ottawa/IBM] [attachment "issueresolution-6460.doc" deleted by Branislav Selic/Ottawa/IBM] Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), 6460, proposed resolutions Date: Thu, 22 Apr 2004 10:41:33 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, > Just to make sure I understand, I will try to explain what I think is > the rationale behind your proposal -- perhaps you can tell me if I > got it right (or, where I have it wrong): > > In UML 1.x, a navigable link end meant that it was possible to > communicate with the object at the other end (actually, I'm not sure > there was agreement on that, but let's not get into that) In UML 1.x > a navigable link end did not require an attribute to be provided in > the object at the other end For reasons of backward compatibility, > you would like to separate the concept of owning a link end from the > ability to communicate with the other end. > It seems that in 1.x, we dealt with navigability at a more > abstract level, without delving into the mechanism by which > communication across links is achieved. In 2.0, we changed that. Yes, except that I wouldn't restrict navigation to communication. Any process (whether in the source object or not) with a handle on an object may want to traverse an association to another object. It can do this other ways besides looking up attributes on the source object (database intersection tables are an example). > Now here is my problem: as far as I know, the only reason why an > object would need to have an attribute for a link end is so that it > can communicate with the other end. (Is there any other reason that I > am missing?) If I'm right, then the two concepts are really not > separable. > So, it seems to me that what you are looking for is a selectable > level of abstraction for modeling navigability, which, as you define > it, is the ability to communicate across a link. Is this something > that you would want to control at the level of individual > associations or is it something that is chosen at the level of a > model? See first comment. When navigation is not limited to communciation, we need the UML 1.x functionality. The proposal I sent out lets the modeler take a object or relational viewpoint as they find necessary. Reply-To: From: "Desfray" To: "'Branislav Selic'" , Cc: Subject: [Profiles] Proposed resolution for ballot 17 Date: Wed, 16 Jun 2004 19:05:28 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Dear all, You will find enclosed the last remaining issue for profiles and the proposed resolution for it. Best regards [Desfray] ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com Objet : RE: Proposed resolutions for ballot 15 Attached, please find resolution proposals for Profile and Information Flow issues. Bran, 7276 and 7234 are included, in case you work in parallel on these. Cheers ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : dimanche 23 mai 2004 23:27 À : uml2-superstructure-ftf@omg.org Cc : mu2i-ftf@omg.org; ocl2-ftf@omg.org Objet : Proposed resolutions for ballot 15 Attached, please find 23 proposed resolutions for Ballot 15. Most of them are simple typos, but not all. Please have a lookg through them and tell me if you have any objections. I hope to have another 4 by tomorrow. The issues addressed are: 6959 7232 7233 7235 7237 7238 7239 7244 7295 7292 7300 7324 7325 7327 7329 7345 7346 7347 7349 7350 7360 7361 Cheers, Bran Issue 6242 resolution.doc OMG Issue N° 6242: Title: Confusion regarding XMI for use of stereotypes (uml2-superstructure-ftf) Source: ARTISAN Software Tools (Mr. Alan Moore, alan.moore@artisansw.com) Summary: I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Discussion It is indeed an important preoccupation that there is no illustration of how to interchange profiles in XMI. This is not explained in the Profile spec, nor in the MOF spec, nor in the XMI spec. .instance model seems to mix meta-levels. is a common misunderstanding of the Profile spec that has been solved through the previous issue resolutions. In particular, the Profile/MOF correspondence has been specified and illustrated. This allows us to apply the MOF/XMI mechanism. We therefore propose to provide an example that illustrates the XMI interchange of profiles. The specification should be amended as follows: In Profiles:Profile:semantics, at the end of this paragraph, add Using XMI to exchange Profiles As shown Figure 447 (Extension : Semantics), there is a direct correspondence between a profile definition and a MOF metamodel. XMI can therefore be directly applied to exchange Profiles. We will take the example Figure 449 (Extension : Notation) of a profile that we will call .HomeExample. to illustrate how a profile can be exchanged. We will see that a profile can be exchanged as a model, as a XMI schema definition, and that models extended by the profile can also interchange their definition and extension. Figure 449 shows a .Home. stereotype extending the .Interface. UML2 metaclass. Figure 447 illustrates the MOF correspondence for that example, basically by introducing an association from the .Home. MOF class to the .Interface. MOF class. The first serialization above shows how the model Figure 449 (instance of the profile and UML2 metamodel) can be exchanged. The XML schema above shows now the schema definition that can be obtained from the « HomeExample » profile. That schema definition will itself define in XML how the models extended by the HomeExample will be exchanged in XMI. We can see here that a XMI schema separated from the standard UML2 schema can be obtained. Let us provide an example of an Interface extended by the Home stereotype. Figure 452 . Using the .HomeExample. profile to extend a model Now the XMI code below shows how this model extended by the profile is serialized. A tool importing that XMI file can filter out the elements related to the .HomeExample. schema, if the tool does not have this schema (profile) definition. Disposition: Resolved Subject: RE: First draft of Ballot 18 (full) Date: Thu, 8 Jul 2004 07:25:06 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: First draft of Ballot 18 (full) Thread-Index: AcRkaDzVJAwcEo2yQJyo76a7goIVVQAbuYHw From: "Pete Rivett" To: "Branislav Selic" , , Issue 6156 partially applies to Infra, so as for 7056, should have an Infrastructure resolution section: although Infra does not have the equivalent of Figure 22, it does require the '/' added to the description of attribute and currently does not include anything at all about classifier notation (the Notation section is all about attributes) so should include not only the new para but the current first two paragraphs from Super.. Issue 7227: I have major problem with the following from the resolution "Deployment is a subclass of Dependency as that is the notation that it uses. This is based on the UML 1.x notation, and as such is best kept consistent. ": surely consistency with (UML 1.4) notation should not be the basis of the metamodel! Moreover the resolution is incorrect to use as justification "all dashed lines are Dependencies" - one exception that comes to mind is Imports. And precise consistency of mapping notation to metamodel is not something seen as vital in the past (there are several shapes which are not unambiguous, not to mention the overuse of text in guillemets and the famous inability to interpret an association with no navigability arrows). As author of the issue I made the point that Deployment is a relationship between Node and Artifact where neither is Dependent in any sense on the other. The fact that, as the resolution discusses, a Node may 'know about' what's deployed on it is irrelevant with respect to Dependency. More seriously, the point of the metamodel is not some generally handy way to interchange the models, but to provide some semantics/meaning: software may actually want to apply some processing to Dependencies (e.g. for impact analysis) for which this Deployment information is just not relevant. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, July 07, 2004 10:11 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: First draft of Ballot 18 (full) Attached, please find a draft of the issues resolutions proposed for Ballot 18. Bran OMG Issue N° 6242: Title: Confusion regarding XMI for use of stereotypes (uml2-superstructure-ftf) Source: ARTISAN Software Tools (Mr. Alan Moore, alan.moore@artisansw.com) Summary: I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Discussion It is indeed an important preoccupation that there is no illustration of how to interchange profiles in XMI. This is not explained in the Profile spec, nor in the MOF spec, nor in the XMI spec. .instance model seems to mix meta-levels. is a common misunderstanding of the Profile spec that has been solved through the previous issue resolutions. In particular, the Profile/MOF correspondence has been specified and illustrated. This allows us to apply the MOF/XMI mechanism. We therefore propose to provide an example that illustrates the XMI interchange of profiles. The specification should be amended as follows: In Profiles:Profile:semantics, at the end of this paragraph, add Using XMI to exchange Profiles As shown Figure 447 (Extension : Semantics), there is a direct correspondence between a profile definition and a MOF metamodel. XMI can therefore be directly applied to exchange Profiles. We will take the example Figure 449 (Extension : Notation) of a profile that we will call .HomeExample. to illustrate how a profile can be exchanged. We will see that a profile can be exchanged as a model, as a XMI schema definition, and that models extended by the profile can also interchange their definition and extension. Figure 449 shows a .Home. stereotype extending the .Interface. UML2 metaclass. Figure 447 illustrates the MOF correspondence for that example, basically by introducing an association from the .Home. MOF class to the .Interface. MOF class. For illustration purpose, we add a tagged value definition (attribute) called .magic:string. to the .Home. stereotype. The first serialization above shows how the model Figure 449 (instance of the profile and UML2 metamodel) can be exchanged. The XML schema above shows now the schema definition that can be obtained from the « HomeExample » profile. That schema definition will itself define in XML how the models extended by the HomeExample will be exchanged in XMI. We can see here that a XMI schema separated from the standard UML2 schema can be obtained. Let us provide an example of an Interface extended by the Home stereotype. Figure 452 . Using the .HomeExample. profile to extend a model Now the XMI code below shows how this model extended by the profile is serialized. A tool importing that XMI file can filter out the elements related to the .HomeExample. schema, if the tool does not have this schema (profile) definition. Disposition: Resolved To: Cc: "'Branislav Selic'" , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org, xavier.blanc@softeam.fr Subject: RE: [Profiles] Proposed resolution for ballot 17 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Tue, 13 Jul 2004 01:03:43 -0400 X-MIMETrack: Serialize by Router on D25ML06/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 07/13/2004 01:03:33, Serialize complete at 07/13/2004 01:03:33 Philippe, Thanks for the amendments. I have a couple of further comments: - The 'baseInterface' property should be renamed to 'base$Interface' to conform to the extension end naming convention. - I believe the type of the extension end must be an instance of Stereotype, not the Stereotype metaclass itself. I would have expected something like this: Note that a lower value is included (with an implicit value of 0) to ensure that the extension is not considered "required". - I'm not sure the metaclass reference is correct. I would have expected something like: I'm not sure what to include for the href here (nor in the type references of the stereotype attributes)... this is part of the "mixing of metalevels" problem/confusion. - In order to apply the Home stereotype to your Client interface, the profile must first be applied to the containing package. I would have expected to see something like this: Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Desfray" 07/09/2004 08:58 AM Please respond to Philippe.Desfray To Kenneth Hussey/Ottawa/IBM@IBMCA, Branislav Selic/Ottawa/IBM@IBMCA, , cc Subject RE: [Profiles] Proposed resolution for ballot 17 Dear all, This revised proposal targets now ballot 19. It contains amendments in response to Kenneth's feedbacks. In case of further observations, please include Xavier Blanc in your response. Xavier, who attends frequently OMG meetings represents also SOFTEAM there, and is (much much more than me) aware in XMI. ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Kenneth Hussey [mailto:khussey@ca.ibm.com] Envoyé : mardi 22 juin 2004 22:50 À : Philippe.Desfray@softeam.fr Cc : 'Branislav Selic'; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : Re: [Profiles] Proposed resolution for ballot 17 Philippe, I have several concerns with your proposal... I would have expected the namespace URI for UML 2.0 to be something like 'http://www.omg.org/2004/UML' I would have expected the namespace prefix for UML 2.0 to be 'uml' There should be a metaclass reference between the profile and the extended metaclass (i.e. Interface) The name of the extension end should be 'extension$Home' (as per the extension end naming convention) The aggregation of the extension end should be composite Your example should probably show how to deal with stereotypes that introduce new properties (and their values) Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Desfray" 06/16/2004 01:05 PM Please respond to Philippe.Desfray To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject [Profiles] Proposed resolution for ballot 17 Dear all, You will find enclosed the last remaining issue for profiles and the proposed resolution for it. Best regards [Desfray] ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com Objet : RE: Proposed resolutions for ballot 15 Attached, please find resolution proposals for Profile and Information Flow issues. Bran, 7276 and 7234 are included, in case you work in parallel on these. Cheers ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : dimanche 23 mai 2004 23:27 À : uml2-superstructure-ftf@omg.org Cc : mu2i-ftf@omg.org; ocl2-ftf@omg.org Objet : Proposed resolutions for ballot 15 Attached, please find 23 proposed resolutions for Ballot 15. Most of them are simple typos, but not all. Please have a lookg through them and tell me if you have any objections. I hope to have another 4 by tomorrow. The issues addressed are: 6959 7232 7233 7235 7237 7238 7239 7244 7295 7292 7300 7324 7325 7327 7329 7345 7346 7347 7349 7350 7360 7361 Cheers, Bran [attachment "Issue 6242 resolution.doc" deleted by Kenneth Hussey/Ottawa/IBM] [attachment "Issue 6242 resolutionv2.doc" deleted by Kenneth Hussey/Ottawa/IBM] Reply-To: From: "Desfray" To: "'Kenneth Hussey'" , "'Branislav Selic'" , , Cc: Subject: RE: [Profiles] Proposed resolution for ballot (20?) Date: Mon, 19 Jul 2004 17:44:30 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Dear all, Here is a new attempt to solve the XMI/Profile issue. We should converge, after two review feedbacks be Kenneth. In case of any other feedback, please do CC Xavier Blanc. best regards ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Desfray [mailto:Philippe.Desfray@softeam.fr] Envoyé : vendredi 9 juillet 2004 14:58 À : 'Kenneth Hussey'; 'Branislav Selic'; 'mu2i-ftf@omg.org'; 'uml2-superstructure-ftf@omg.org' Cc : 'xavier.blanc@softeam.fr' Objet : RE: [Profiles] Proposed resolution for ballot 17 Dear all, This revised proposal targets now ballot 19. It contains amendments in response to Kenneth's feedbacks. In case of further observations, please include Xavier Blanc in your response. Xavier, who attends frequently OMG meetings represents also SOFTEAM there, and is (much much more than me) aware in XMI. ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Kenneth Hussey [mailto:khussey@ca.ibm.com] Envoyé : mardi 22 juin 2004 22:50 À : Philippe.Desfray@softeam.fr Cc : 'Branislav Selic'; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : Re: [Profiles] Proposed resolution for ballot 17 Philippe, I have several concerns with your proposal... I would have expected the namespace URI for UML 2.0 to be something like 'http://www.omg.org/2004/UML' I would have expected the namespace prefix for UML 2.0 to be 'uml' There should be a metaclass reference between the profile and the extended metaclass (i.e. Interface) The name of the extension end should be 'extension$Home' (as per the extension end naming convention) The aggregation of the extension end should be composite Your example should probably show how to deal with stereotypes that introduce new properties (and their values) Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Desfray" 06/16/2004 01:05 PM Please respond to Philippe.Desfray To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject [Profiles] Proposed resolution for ballot 17 Dear all, You will find enclosed the last remaining issue for profiles and the proposed resolution for it. Best regards [Desfray] ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com Objet : RE: Proposed resolutions for ballot 15 Attached, please find resolution proposals for Profile and Information Flow issues. Bran, 7276 and 7234 are included, in case you work in parallel on these. Cheers ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : dimanche 23 mai 2004 23:27 À : uml2-superstructure-ftf@omg.org Cc : mu2i-ftf@omg.org; ocl2-ftf@omg.org Objet : Proposed resolutions for ballot 15 Attached, please find 23 proposed resolutions for Ballot 15. Most of them are simple typos, but not all. Please have a lookg through them and tell me if you have any objections. I hope to have another 4 by tomorrow. The issues addressed are: 6959 7232 7233 7235 7237 7238 7239 7244 7295 7292 7300 7324 7325 7327 7329 7345 7346 7347 7349 7350 7360 7361 Cheers, Bran [attachment "Issue 6242 resolution.doc" deleted by Kenneth Hussey/Ottawa/IBM] Issue 6242 resolutionv3.doc OMG Issue N° 6242: Title: Confusion regarding XMI for use of stereotypes (uml2-superstructure-ftf) Source: ARTISAN Software Tools (Mr. Alan Moore, alan.moore@artisansw.com) Summary: I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Discussion It is indeed an important preoccupation that there is no illustration of how to interchange profiles in XMI. This is not explained in the Profile spec, nor in the MOF spec, nor in the XMI spec. .instance model seems to mix meta-levels. is a common misunderstanding of the Profile spec that has been solved through the previous issue resolutions. In particular, the Profile/MOF correspondence has been specified and illustrated. This allows us to apply the MOF/XMI mechanism. We therefore propose to provide an example that illustrates the XMI interchange of profiles. The specification should be amended as follows: In Profiles:Profile:semantics, at the end of this paragraph, add Using XMI to exchange Profiles As shown Figure 447 (Extension : Semantics), there is a direct correspondence between a profile definition and a MOF metamodel. XMI can therefore be directly applied to exchange Profiles. We will take the example Figure 449 (Extension : Notation) of a profile that we will call .HomeExample. to illustrate how a profile can be exchanged. We will see that a profile can be exchanged as a model, as a XMI schema definition, and that models extended by the profile can also interchange their definition and extension. Figure 449 shows a .Home. stereotype extending the .Interface. UML2 metaclass. Figure 447 illustrates the MOF correspondence for that example, basically by introducing an association from the .Home. MOF class to the .Interface. MOF class. For illustration purpose, we add a tagged value definition (attribute) called .magic:string. to the .Home. stereotype. The first serialization above shows how the model Figure 449 (instance of the profile and UML2 metamodel) can be exchanged. The XML schema above shows now the schema definition that can be obtained from the « HomeExample » profile. That schema definition will itself define in XML how the models extended by the HomeExample will be exchanged in XMI. We can see here that a XMI schema separated from the standard UML2 schema can be obtained. Let us provide an example of an Interface extended by the Home stereotype. Figure 452 . Using the .HomeExample. profile to extend a model Now the XMI code below shows how this model extended by the profile is serialized. A tool importing that XMI file can filter out the elements related to the .HomeExample. schema, if the tool does not have this schema (profile) definition. Disposition: Resolved To: Branislav Selic Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: Draft of ballot 20 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Fri, 23 Jul 2004 11:03:53 -0400 X-MIMETrack: Serialize by Router on D25ML06/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 07/23/2004 11:02:00, Serialize complete at 07/23/2004 11:02:00 Bran, I noticed that some of my concerns are still not addressed in the proposed resolution to issue 6242, in particular with respect to the structure of the metaclass reference. I don't claim to be an XMI expert, though, so maybe it's OK... In any case, the resolution should probably explain what is meant by 'href="..."', since readers of the specification will no doubt wonder. Note also that the stereotype application (at the end) is missing an XMI ID. Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 Branislav Selic/Ottawa/IBM@IBMCA 07/22/2004 03:44 PM To uml2-superstructure-ftf@omg.org cc mu2i-ftf@omg.org Subject Draft of ballot 20 Here is the current draft of ballot 20. Eran, I changed your resolution to reflect the new BNF format that we are hoping to adopt as part of issue 7135. There are 25 resoutions in this ballot at present. I expect that karl will likely have at least one more resolution. Please review and tell me if you have any objections to any of the resolutions -- before noon tomorrow, if possible. Cheers, Bran [attachment "Ballot20.draft.040722.doc" deleted by Kenneth Hussey/Ottawa/IBM] Reply-To: From: "Desfray" To: "'Desfray'" , "'Kenneth Hussey'" , "'Branislav Selic'" , , Cc: Subject: RE: [Profiles] Proposed resolution for ballot (20?) Date: Mon, 26 Jul 2004 11:57:31 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-Virus-Scanned: by amavisd-new at softeam.com Dear all, Here is a new version of the resolution to the Issue 6242. It takes into account the latest feedbacks of Ken.This is, I hope, a proposal to be included in Ballot 21. In case of feedbacks, please include Xavier Blanc in CC. Best regards ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Desfray [mailto:Philippe.Desfray@softeam.fr] Envoyé : lundi 19 juillet 2004 17:45 À : 'Kenneth Hussey'; 'Branislav Selic'; 'mu2i-ftf@omg.org'; 'uml2-superstructure-ftf@omg.org' Cc : 'xavier.blanc@softeam.fr' Objet : RE: [Profiles] Proposed resolution for ballot (20?) Dear all, Here is a new attempt to solve the XMI/Profile issue. We should converge, after two review feedbacks be Kenneth. In case of any other feedback, please do CC Xavier Blanc. best regards ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Desfray [mailto:Philippe.Desfray@softeam.fr] Envoyé : vendredi 9 juillet 2004 14:58 À : 'Kenneth Hussey'; 'Branislav Selic'; 'mu2i-ftf@omg.org'; 'uml2-superstructure-ftf@omg.org' Cc : 'xavier.blanc@softeam.fr' Objet : RE: [Profiles] Proposed resolution for ballot 17 Dear all, This revised proposal targets now ballot 19. It contains amendments in response to Kenneth's feedbacks. In case of further observations, please include Xavier Blanc in your response. Xavier, who attends frequently OMG meetings represents also SOFTEAM there, and is (much much more than me) aware in XMI. ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Kenneth Hussey [mailto:khussey@ca.ibm.com] Envoyé : mardi 22 juin 2004 22:50 À : Philippe.Desfray@softeam.fr Cc : 'Branislav Selic'; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : Re: [Profiles] Proposed resolution for ballot 17 Philippe, I have several concerns with your proposal... I would have expected the namespace URI for UML 2.0 to be something like 'http://www.omg.org/2004/UML' I would have expected the namespace prefix for UML 2.0 to be 'uml' There should be a metaclass reference between the profile and the extended metaclass (i.e. Interface) The name of the extension end should be 'extension$Home' (as per the extension end naming convention) The aggregation of the extension end should be composite Your example should probably show how to deal with stereotypes that introduce new properties (and their values) Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Desfray" 06/16/2004 01:05 PM Please respond to Philippe.Desfray To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject [Profiles] Proposed resolution for ballot 17 Dear all, You will find enclosed the last remaining issue for profiles and the proposed resolution for it. Best regards [Desfray] ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com Objet : RE: Proposed resolutions for ballot 15 Attached, please find resolution proposals for Profile and Information Flow issues. Bran, 7276 and 7234 are included, in case you work in parallel on these. Cheers ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : dimanche 23 mai 2004 23:27 À : uml2-superstructure-ftf@omg.org Cc : mu2i-ftf@omg.org; ocl2-ftf@omg.org Objet : Proposed resolutions for ballot 15 Attached, please find 23 proposed resolutions for Ballot 15. Most of them are simple typos, but not all. Please have a lookg through them and tell me if you have any objections. I hope to have another 4 by tomorrow. The issues addressed are: 6959 7232 7233 7235 7237 7238 7239 7244 7295 7292 7300 7324 7325 7327 7329 7345 7346 7347 7349 7350 7360 7361 Cheers, Bran [attachment "Issue 6242 resolution.doc" deleted by Kenneth Hussey/Ottawa/IBM] Issue 6242 resolutionv5.doc OMG Issue N° 6242: Title: Confusion regarding XMI for use of stereotypes (uml2-superstructure-ftf) Source: ARTISAN Software Tools (Mr. Alan Moore, alan.moore@artisansw.com) Summary: I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Discussion It is indeed an important preoccupation that there is no illustration of how to interchange profiles in XMI. This is not explained in the Profile spec, nor in the MOF spec, nor in the XMI spec. .instance model seems to mix meta-levels. is a common misunderstanding of the Profile spec that has been solved through the previous issue resolutions. In particular, the Profile/MOF correspondence has been specified and illustrated. This allows us to apply the MOF/XMI mechanism. We therefore propose to provide an example that illustrates the XMI interchange of profiles. The specification should be amended as follows: In Profiles:Profile:semantics, at the end of this paragraph, add Using XMI to exchange Profiles As shown Figure 447 (Extension : Semantics), there is a direct correspondence between a profile definition and a MOF metamodel. XMI can therefore be directly applied to exchange Profiles. We will take the example Figure 449 (Extension : Notation) of a profile that we will call .HomeExample. to illustrate how a profile can be exchanged. We will see that a profile can be exchanged as a model, as a XMI schema definition, and that models extended by the profile can also interchange their definition and extension. Figure 449 shows a .Home. stereotype extending the .Interface. UML2 metaclass. Figure 447 illustrates the MOF correspondence for that example, basically by introducing an association from the .Home. MOF class to the .Interface. MOF class. For illustration purpose, we add a tagged value definition (attribute) called .magic:string. to the .Home. stereotype. The first serialization above shows how the model Figure 449 (instance of the profile and UML2 metamodel) can be exchanged. The XML schema above shows now the schema definition that can be obtained from the « HomeExample » profile. That schema definition will itself define in XML how the models extended by the HomeExample will be exchanged in XMI. We can see here that a XMI schema separated from the standard UML2 schema can be obtained. Let us provide an example of an Interface extended by the Home stereotype. Figure 452 . Using the .HomeExample. profile to extend a model Now the XMI code below shows how this model extended by the profile is serialized. A tool importing that XMI file can filter out the elements related to the .HomeExample. schema, if the tool does not have this schema (profile) definition. Disposition: Resolved Subject: RE: [Profiles] Proposed resolution for ballot (20?) - extensive comments Date: Thu, 29 Jul 2004 14:43:30 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Profiles] Proposed resolution for ballot (20?) - extensive comments Thread-Index: AcR1lY5I4cwXV1baTaaJwZAkwfAK+wAAPihw From: "Pete Rivett" To: "Kenneth Hussey" Cc: , , X-Virus-Scanned: by amavisd-new at sentraliant.com Hi Kenn, See below: well picked up, though I remain to be convinced about xmi:type. Attached is corrected document. While I remember, something we need to do before wrapping up the specs is to formally define the set of MOF tags (whose names are defined in the XMI spec) to be used for generating the UML XML Schema itself. Including for example the nsURI and the nsPrefix. And indeed the set of tags for MOF - which determine how the UML metamodel itself is serialized as XMI (or the XMI for any metamodel come to that). Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Kenneth Hussey [mailto:khussey@ca.ibm.com] Sent: Thursday, July 29, 2004 6:48 PM To: Pete Rivett Cc: mu2i-ftf@omg.org; Philippe.Desfray@softeam.fr; uml2-superstructure-ftf@omg.org Subject: RE: [Profiles] Proposed resolution for ballot (20?) - extensive comments Pete, A couple of questions/concerns: - It's still not clear to me why we are using xsi:type instead of xmi:type - I believe the XMI specification is full of examples that show the use of xmi:type in describing UML elements... [Pete Rivett] xsi:type is still valid and actually required (instead of xmi:type) if XML Schema inheritance is being used and is used in the official published XMI adaopted for the Superstructure. In terms of stylistic choice my preference would be xsi since a) I don't like reinventing the wheel - if XML generally has a mechanism then why not use it - other XML processors may then be able to do something with the document and b) it provides forward compoatibility with XMI 2.0 which I do not think has xmi:type c) it means only one way of doing things - I can use xsi: all the time without worrying whether I've got schema inheritance on or not. And in some cases I might not know if my Schema is to be included in others I do not know about yet. Do you have arguments in favor of xmi? - Shouldn't the memberEnd attribute of the Extension element reference both ends, i.e. memberEnd="id3 id6"? [Pete Rivett] True - since it's a subset not a redefine or derivation. Corrected. - ownedmember in the last example should be ownedMember. [Pete Rivett] Corrected Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Pete Rivett" 07/29/2004 01:32 PM To , , cc Subject RE: [Profiles] Proposed resolution for ballot (20?) - extensive comments There are few more minor errors. I just saw Philippe's email so have also updated the doc with change bars (attached). Here are some highlights (I started writing comments before realizing I should update the doc!) but there are several more minor changes. 1. As per my 2nd Correction, the references should not be qualified by class name, specifically: - uml:Profile.ownedStereotype: use ownedStereotype (start and end tags) - uml:Package.ownedMember (use ownedMember) In other places the namespace prefix is not necessary but not wrong e.g. - uml:metaclassReference 2. the base_Interface attribute has where id9 does not exist. This should reference the Interface class. It could do this directly via href but it is better style to have a proxy element with the href since there is another href to the same class. I did the same with String. 3. The href=http://schema.omg.org/spec/UML/2.0#Interface (and the reference to String) should refer to the full filename i.e. href="http://schema.omg.org/spec/UML/2.0/uml.xml#Interface"/> 4. Something I had not spotted before - the composition should be specified as isComposite="true" not aggregation="composition" since Profiles extends Constructs and Property.aggregation is only added in Kernel. 5. In the Schema the minoccurs should be 1. 6. I did not previously check the Schema closely enough - there are various XMI-mandated red tape elements. And less type checking e.g. the type for base_Interface has to be xmi:Any. And XML attributes need to be declared (otherwise it would not validate the example at the end!) PS have a great vaaction Philippe! Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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 [mailto:Philippe.Desfray@softeam.fr] Sent: Thursday, July 29, 2004 2:29 PM To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: TR: [Profiles] Proposed resolution for ballot (20?) - extensive comments For these of you who could not read the previous attachment (Bran and Ken could'nt), here is a zipped version, MIME format for the mail. It has worked for Bran. Hope this passes through the list (zip) and everybody can read it. regards ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Desfray [mailto:Philippe.Desfray@softeam.fr] Envoyé : jeudi 29 juillet 2004 10:41 À : 'Branislav Selic'; 'Kenneth Hussey' Objet : RE: [Profiles] Proposed resolution for ballot (20?) - extensive comments First attempt : the file is zipped, and the message in MIME format. I will send it again using UUENCODE Hope one of them will work ... ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 28 juillet 2004 20:14 À : Philippe.Desfray@softeam.fr Objet : RE: [Profiles] Proposed resolution for ballot (20?) - extensive comments Philippe, Can you please use that trick that attaches the file in a format such that I can read it. At the moment it is an unreadable winmail.dat file. Sorry, Bran [attachment "Issue 6242 resolutionv7.2.doc" deleted by Kenneth Hussey/Ottawa/IBM] Issue 6242 resolutionv7.3.doc OMG Issue N° 6242: Title: Confusion regarding XMI for use of stereotypes (uml2-superstructure-ftf) Source: ARTISAN Software Tools (Mr. Alan Moore, alan.moore@artisansw.com) Summary: I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Discussion It is indeed an important preoccupation that there is no illustration of how to interchange profiles in XMI. This is not explained in the Profile spec, nor in the MOF spec, nor in the XMI spec. .instance model seems to mix meta-levels. is a common misunderstanding of the Profile spec that has been solved through the previous issue resolutions. In particular, the Profile/MOF correspondence has been specified and illustrated. This allows us to apply the MOF/XMI mechanism. We therefore propose to provide an example that illustrates the XMI interchange of profiles. The specification should be amended as follows: In Profiles:Profile:semantics, at the end of this paragraph, add Using XMI to exchange Profiles As shown Figure 447 (Extension : Semantics), there is a direct correspondence between a profile definition and a MOF metamodel. XMI can therefore be directly applied to exchange Profiles. We will take the example Figure 449 (Extension : Notation) of a profile that we will call .HomeExample. to illustrate how a profile can be exchanged. We will see that a profile can be exchanged as a model, as a XMI schema definition, and that models extended by the profile can also interchange their definition and extension. Figure 449 shows a .Home. stereotype extending the .Interface. UML2 metaclass. Figure 447 illustrates the MOF correspondence for that example, basically by introducing an association from the .Home. MOF class to the .Interface. MOF class. For illustration purpose, we add a property (tagged value definition in UML1.4) called .magic:String. to the .Home. stereotype. The first serialization below shows how the model Figure 449 (instance of the profile and UML2 metamodel) can be exchanged. We will now obtain a XMI definition from the « HomeExample » profile. That XMI description will itself define in XML how the models extended by the HomeExample will be exchanged in XMI. We can see here that a XMI schema separated from the standard UML2 schema can be obtained. This XMI definition is stored in a file called .HomeExample.xmi.. use="optional"/> Let us provide an example of an Interface extended by the Home stereotype. Figure 452 . Using the .HomeExample. profile to extend a model Now the XMI code below shows how this model extended by the profile is serialized. A tool importing that XMI file can filter out the elements related to the .HomeExample. schema, if the tool does not have this schema (profile) definition. Disposition: Resolved Subject: RE: [Profiles] Proposed resolution for ballot (20?) - extensive comments Date: Thu, 29 Jul 2004 13:32:01 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Profiles] Proposed resolution for ballot (20?) - extensive comments Thread-Index: AcR1R8HKvhwNMdXGRWe0vn4TD+e7qQAJ/5egAAI1+1A= From: "Pete Rivett" To: , , X-Virus-Scanned: by amavisd-new at sentraliant.com There are few more minor errors. I just saw Philippe's email so have also updated the doc with change bars (attached). Here are some highlights (I started writing comments before realizing I should update the doc!) but there are several more minor changes. 1. As per my 2nd Correction, the references should not be qualified by class name, specifically: - uml:Profile.ownedStereotype: use ownedStereotype (start and end tags) - uml:Package.ownedMember (use ownedMember) In other places the namespace prefix is not necessary but not wrong e.g. - uml:metaclassReference 2. the base_Interface attribute has where id9 does not exist. This should reference the Interface class. It could do this directly via href but it is better style to have a proxy element with the href since there is another href to the same class. I did the same with String. 3. The href=http://schema.omg.org/spec/UML/2.0#Interface (and the reference to String) should refer to the full filename i.e. href="http://schema.omg.org/spec/UML/2.0/uml.xml#Interface"/> 4. Something I had not spotted before - the composition should be specified as isComposite="true" not aggregation="composition" since Profiles extends Constructs and Property.aggregation is only added in Kernel. 5. In the Schema the minoccurs should be 1. 6. I did not previously check the Schema closely enough - there are various XMI-mandated red tape elements. And less type checking e.g. the type for base_Interface has to be xmi:Any. And XML attributes need to be declared (otherwise it would not validate the example at the end!) PS have a great vaaction Philippe! Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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 [mailto:Philippe.Desfray@softeam.fr] Sent: Thursday, July 29, 2004 2:29 PM To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: TR: [Profiles] Proposed resolution for ballot (20?) - extensive comments For these of you who could not read the previous attachment (Bran and Ken could'nt), here is a zipped version, MIME format for the mail. It has worked for Bran. Hope this passes through the list (zip) and everybody can read it. regards ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Desfray [mailto:Philippe.Desfray@softeam.fr] Envoyé : jeudi 29 juillet 2004 10:41 À : 'Branislav Selic'; 'Kenneth Hussey' Objet : RE: [Profiles] Proposed resolution for ballot (20?) - extensive comments First attempt : the file is zipped, and the message in MIME format. I will send it again using UUENCODE Hope one of them will work ... ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 28 juillet 2004 20:14 À : Philippe.Desfray@softeam.fr Objet : RE: [Profiles] Proposed resolution for ballot (20?) - extensive comments Philippe, Can you please use that trick that attaches the file in a format such that I can read it. At the moment it is an unreadable winmail.dat file. Sorry, Bran Issue 6242 resolutionv7.2.doc OMG Issue N° 6242: Title: Confusion regarding XMI for use of stereotypes (uml2-superstructure-ftf) Source: ARTISAN Software Tools (Mr. Alan Moore, alan.moore@artisansw.com) Summary: I've been looking at Figure 458 and can't quite get it, but don't know if it's an issue -the problem I have is that the instance model seems to mix meta-levels; we have an instance of the UML (meta) class, Class and an instance of the user stereotype(class) Clock - yet on the diagram this jump in metalevels is not mentioned. I can't see how this can be the true Instance model. Could someone provide me with the XMI fragment that this figure is intended to produce - I think that this would give me more of a clue about what's going on. Discussion It is indeed an important preoccupation that there is no illustration of how to interchange profiles in XMI. This is not explained in the Profile spec, nor in the MOF spec, nor in the XMI spec. .instance model seems to mix meta-levels. is a common misunderstanding of the Profile spec that has been solved through the previous issue resolutions. In particular, the Profile/MOF correspondence has been specified and illustrated. This allows us to apply the MOF/XMI mechanism. We therefore propose to provide an example that illustrates the XMI interchange of profiles. The specification should be amended as follows: In Profiles:Profile:semantics, at the end of this paragraph, add Using XMI to exchange Profiles As shown Figure 447 (Extension : Semantics), there is a direct correspondence between a profile definition and a MOF metamodel. XMI can therefore be directly applied to exchange Profiles. We will take the example Figure 449 (Extension : Notation) of a profile that we will call .HomeExample. to illustrate how a profile can be exchanged. We will see that a profile can be exchanged as a model, as a XMI schema definition, and that models extended by the profile can also interchange their definition and extension. Figure 449 shows a .Home. stereotype extending the .Interface. UML2 metaclass. Figure 447 illustrates the MOF correspondence for that example, basically by introducing an association from the .Home. MOF class to the .Interface. MOF class. For illustration purpose, we add a property (tagged value definition in UML1.4) called .magic:String. to the .Home. stereotype. The first serialization below shows how the model Figure 449 (instance of the profile and UML2 metamodel) can be exchanged. < type=.id10./> href="http://schema.omg.org/spec/UML/2.0#String"/> We will now obtain a XMI definition from the « HomeExample » profile. That XMI description will itself define in XML how the models extended by the HomeExample will be exchanged in XMI. We can see here that a XMI schema separated from the standard UML2 schema can be obtained. This XMI definition is stored in a file called .HomeExample.xmi.. use="optional"/> Let us provide an example of an Interface extended by the Home stereotype. Figure 452 . Using the .HomeExample. profile to extend a model Now the XMI code below shows how this model extended by the profile is serialized. A tool importing that XMI file can filter out the elements related to the .HomeExample. schema, if the tool does not have this schema (profile) definition. Disposition: Resolved To: "Pete Rivett" Cc: mu2i-ftf@omg.org, Philippe.Desfray@softeam.fr, uml2-superstructure-ftf@omg.org Subject: RE: [Profiles] Proposed resolution for ballot (20?) - extensive comments X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Thu, 29 Jul 2004 13:48:22 -0400 X-MIMETrack: Serialize by Router on D25ML06/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 07/29/2004 13:48:24, Serialize complete at 07/29/2004 13:48:24 Pete, A couple of questions/concerns: - It's still not clear to me why we are using xsi:type instead of xmi:type - I believe the XMI specification is full of examples that show the use of xmi:type in describing UML elements... - Shouldn't the memberEnd attribute of the Extension element reference both ends, i.e. memberEnd="id3 id6"? - ownedmember in the last example should be ownedMember. Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Pete Rivett" 07/29/2004 01:32 PM To , , cc Subject RE: [Profiles] Proposed resolution for ballot (20?) - extensive comments There are few more minor errors. I just saw Philippe's email so have also updated the doc with change bars (attached). Here are some highlights (I started writing comments before realizing I should update the doc!) but there are several more minor changes. 1. As per my 2nd Correction, the references should not be qualified by class name, specifically: - uml:Profile.ownedStereotype: use ownedStereotype (start and end tags) - uml:Package.ownedMember (use ownedMember) In other places the namespace prefix is not necessary but not wrong e.g. - uml:metaclassReference 2. the base_Interface attribute has where id9 does not exist. This should reference the Interface class. It could do this directly via href but it is better style to have a proxy element with the href since there is another href to the same class. I did the same with String. 3. The href=http://schema.omg.org/spec/UML/2.0#Interface (and the reference to String) should refer to the full filename i.e. href="http://schema.omg.org/spec/UML/2.0/uml.xml#Interface"/> 4. Something I had not spotted before - the composition should be specified as isComposite="true" not aggregation="composition" since Profiles extends Constructs and Property.aggregation is only added in Kernel. 5. In the Schema the minoccurs should be 1. 6. I did not previously check the Schema closely enough - there are various XMI-mandated red tape elements. And less type checking e.g. the type for base_Interface has to be xmi:Any. And XML attributes need to be declared (otherwise it would not validate the example at the end!) PS have a great vaaction Philippe! Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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 [mailto:Philippe.Desfray@softeam.fr] Sent: Thursday, July 29, 2004 2:29 PM To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: TR: [Profiles] Proposed resolution for ballot (20?) - extensive comments For these of you who could not read the previous attachment (Bran and Ken could'nt), here is a zipped version, MIME format for the mail. It has worked for Bran. Hope this passes through the list (zip) and everybody can read it. regards ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Desfray [mailto:Philippe.Desfray@softeam.fr] Envoyé : jeudi 29 juillet 2004 10:41 À : 'Branislav Selic'; 'Kenneth Hussey' Objet : RE: [Profiles] Proposed resolution for ballot (20?) - extensive comments First attempt : the file is zipped, and the message in MIME format. I will send it again using UUENCODE Hope one of them will work ... ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 28 juillet 2004 20:14 À : Philippe.Desfray@softeam.fr Objet : RE: [Profiles] Proposed resolution for ballot (20?) - extensive comments Philippe, Can you please use that trick that attaches the file in a format such that I can read it. At the moment it is an unreadable winmail.dat file. Sorry, Bran [attachment "Issue 6242 resolutionv7.2.doc" deleted by Kenneth Hussey/Ottawa/IBM] Conrad