Issue 7105: In normative XMI file for the metamodel, no Associations have a name. (uml2-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: In the normative XMI file for the metamodel, no Associations have a name. The name is needed for generating APIs and (in some cases) XMI elements; and their absence actually makes UML2 an invalid MOF2 metamodel: MOF2 Core has the following constraint for CMOF: [6] Names are required for all classifiers and features (though there is nothing to prevent these names being automatically generated by a tool). (Association is a classifier) We could get by with not having a name in the MDL and auto-generating a name into the XMI. This is in fact what the Unisys XMI plug-in did when no Association name was provided - and this was hence reflected in the normative XMI for UML 1.x (the names were of the form A_<end1>_<end2>). Resolution: Revised Text: Actions taken: March 8, 2004: received issue February 18, 2005: moved from infrastructure August 23, 2006: closed issue Discussion: This is a duplicate of issue 6492, which was resolved in earlier ballots. Disposition: See issue 6492 for disposition End of Annotations:===== ubject: Issue on UML2.0 Infrastructure and Superstructure Date: Mon, 8 Mar 2004 08:26:38 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue on UML2.0 Infrastructure and Superstructure Thread-Index: AcQFEDj2iYPXKfuwQDmz0Df8TTzFaw== From: "Pete Rivett" To: Cc: "Branislav Selic" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i28DJYre029685 (Could be catalogued with 2 issue numbers) In the normative XMI file for the metamodel, no Associations have a name. The name is needed for generating APIs and (in some cases) XMI elements; and their absence actually makes UML2 an invalid MOF2 metamodel: MOF2 Core has the following constraint for CMOF: [6] Names are required for all classifiers and features (though there is nothing to prevent these names being automatically generated by a tool). (Association is a classifier) We could get by with not having a name in the MDL and auto-generating a name into the XMI. This is in fact what the Unisys XMI plug-in did when no Association name was provided - and this was hence reflected in the normative XMI for UML 1.x (the names were of the form A__). 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 To: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Cc: ocl2-ftf@omg.org Subject: Consolidated Classes chapter X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 8 Mar 2004 11:57:30 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/08/2004 11:59:07 I have now made the changes to the Classes chapter of the UML 2 Superstructure spec that align its structure with the organization of the rest of the document. This represents part of the proposed resolution to issue 6177 and in line with the direction that was suggested in the recent straw poll on compliance/package merge set of issues (specifically, it deals with sub-issue number 2). Specifically, here is how the chapter was changed: All the diagrams were put up front -- grouped by sub-package. All class definitions were gathered together in a single section and put in alphabetical order Text that explained the old non-standard diagram-based organization of the document was removed Every class description was given an additional sub-section: Parents. This contains a set of hyperlinks to all the direct superclasses of the class. This was suggested as part of the resolution in Anaheim and, if people agree, I will do the same for all the classes in the document. None of the actual text describing individual classes was changed (however, this will not hold for equivalent changes to the Infrastructure). Note that this does not yet include the fixes that have to do with package merge itself. Also, the changes to the Infrastructure document have yet to be done. Still, this is the largest single change in the Superstructure (in terms of impact on the text) required to implement the proposed resolutions to the compliance/merge set of problems. The rest of the changes are smaller and more scattered. If we adopt this in ballot 10, as I am hoping, then we will bypass having to merge these changes in with other changes that might be error prone. So, please have alook at it and express your opinionsand suggestions before Wednesday, March 17. This whole effort required only one person-day of effort, which is actually less than was estimated (although the Infrastrcutre part of this still needs to be done). Cheers, Bran 1_Classes.pdf Subject: RE: Consolidated Classes chapter Date: Mon, 8 Mar 2004 13:39:02 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consolidated Classes chapter Thread-Index: AcQFNtvvxogpXAy2S2+9kSOq5jiP4gABPNZ2 From: "Karl Frank" To: Birger Møller-Pedersen , "Branislav Selic" Cc: , , X-OriginalArrivalTime: 08 Mar 2004 18:39:03.0572 (UTC) FILETIME=[A14F4540:01C4053C] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i28Ibvre026661 A voice of strong support for Birger's point. "parent" is used widely to mean any entity on which another is dependent, in other words the term is broad in meaning, and although a superclass is a parent, a parent is not always a superclass. The word "Specializes" followed by the name(s) of the direct generalization(s) leaves less slop in the fit. - Karl Frank -----Original Message----- From: Birger Møller-Pedersen [mailto:birger@ifi.uio.no] Sent: Mon 3/8/2004 12:56 PM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Re: Consolidated Classes chapter A small thing: the spec is not all consistent wrt to the use of parent/child versus general/specific. From what I remember, general/specific is dominant, and these are also the terms used in the metamodel (role names). From a word class point of view, general/specific seems right. Parents most often come in pairs, and both parent and child are words used to denote what we would model by objects. /birger Branislav Selic wrote: I have now made the changes to the Classes chapter of the UML 2 Superstructure spec that align its structure with the organization of the rest of the document. This represents part of the proposed resolution to issue 6177 and in line with the direction that was suggested in the recent straw poll on compliance/package merge set of issues (specifically, it deals with sub-issue number 2). Specifically, here is how the chapter was changed: * All the diagrams were put up front -- grouped by sub-package. * All class definitions were gathered together in a single section and put in alphabetical order * Text that explained the old non-standard diagram-based organization of the document was removed * Every class description was given an additional sub-section: Parents. This contains a set of hyperlinks to all the direct superclasses of the class. This was suggested as part of the resolution in Anaheim and, if people agree, I will do the same for all the classes in the document. None of the actual text describing individual classes was changed (however, this will not hold for equivalent changes to the Infrastructure). Note that this does not yet include the fixes that have to do with package merge itself. Also, the changes to the Infrastructure document have yet to be done. Still, this is the largest single change in the Superstructure (in terms of impact on the text) required to implement the proposed resolutions to the compliance/merge set of problems. The rest of the changes are smaller and more scattered. If we adopt this in ballot 10, as I am hoping, then we will bypass having to merge these changes in with other changes that might be error prone. So, please have alook at it and express your opinionsand suggestions before Wednesday, March 17. This whole effort required only one person-day of effort, which is actually less than was estimated (although the Infrastrcutre part of this still needs to be done). Cheers, Bran -- Birger Møller-Pedersen Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 24 37 (office) Tel: +47 918 27 27 9 (mobile) http://folk.uio.no/birger To: "Karl Frank" Cc: Birger Møller-Pedersen , mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Consolidated Classes chapter X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 8 Mar 2004 13:50:21 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/08/2004 13:50:34, Serialize complete at 03/08/2004 13:50:34 The reason I chose "parents" is because it is obvious that this refers only to the immediate ancestors of a class. Any other term is cumbersome and possibly ambiguous. For example, "specializes" (or "specialises") is ambiguous because a class specializes all of its ancestors not just its parent classes. Or, I could say "immediate superclasses" but the term "immediate" is not a common technical term from what I know and could be confusing to some. It seems to me that "parent", with all of its shortcomings, comes closest and is least likely to be misunderstood. Anyways, I'm not hung up on the name, I'll go along with whatever the consensus is -- assuming there is one. Bran "Karl Frank" 03/08/2004 01:39 PM To Birger Møller-Pedersen , Branislav Selic/Ottawa/IBM@IBMCA cc , , Subject RE: Consolidated Classes chapter A voice of strong support for Birger's point. "parent" is used widely to mean any entity on which another is dependent, in other words the term is broad in meaning, and although a superclass is a parent, a parent is not always a superclass. The word "Specializes" followed by the name(s) of the direct generalization(s) leaves less slop in the fit. - Karl Frank -----Original Message----- From: Birger Møller-Pedersen [mailto:birger@ifi.uio.no] Sent: Mon 3/8/2004 12:56 PM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Re: Consolidated Classes chapter A small thing: the spec is not all consistent wrt to the use of parent/child versus general/specific. From what I remember, general/specific is dominant, and these are also the terms used in the metamodel (role names). From a word class point of view, general/specific seems right. Parents most often come in pairs, and both parent and child are words used to denote what we would model by objects. /birger Branislav Selic wrote: I have now made the changes to the Classes chapter of the UML 2 Superstructure spec that align its structure with the organization of the rest of the document. This represents part of the proposed resolution to issue 6177 and in line with the direction that was suggested in the recent straw poll on compliance/package merge set of issues (specifically, it deals with sub-issue number 2). Specifically, here is how the chapter was changed: * All the diagrams were put up front -- grouped by sub-package. * All class definitions were gathered together in a single section and put in alphabetical order * Text that explained the old non-standard diagram-based organization of the document was removed * Every class description was given an additional sub-section: Parents. This contains a set of hyperlinks to all the direct superclasses of the class. This was suggested as part of the resolution in Anaheim and, if people agree, I will do the same for all the classes in the document. None of the actual text describing individual classes was changed (however, this will not hold for equivalent changes to the Infrastructure). Note that this does not yet include the fixes that have to do with package merge itself. Also, the changes to the Infrastructure document have yet to be done. Still, this is the largest single change in the Superstructure (in terms of impact on the text) required to implement the proposed resolutions to the compliance/merge set of problems. The rest of the changes are smaller and more scattered. If we adopt this in ballot 10, as I am hoping, then we will bypass having to merge these changes in with other changes that might be error prone. So, please have alook at it and express your opinionsand suggestions before Wednesday, March 17. This whole effort required only one person-day of effort, which is actually less than was estimated (although the Infrastrcutre part of this still needs to be done). Cheers, Bran -- Birger Møller-Pedersen Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 24 37 (office) Tel: +47 918 27 27 9 (mobile) http://folk.uio.no/birger User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 08 Mar 2004 14:04:05 -0500 Subject: Re: Consolidated Classes chapter From: James Odell To: CC: , .Parent. carries about thirty years of IT baggage. IMO, Birger and Karl have summed up all the usages of the word quite well. It has just come to .to mean any entity on which another is dependent.. -Jim On 3/8/04 1:50 PM, "Branislav Selic" indited: The reason I chose "parents" is because it is obvious that this refers only to the immediate ancestors of a class. Any other term is cumbersome and possibly ambiguous. For example, "specializes" (or "specialises") is ambiguous because a class specializes all of its ancestors not just its parent classes. Or, I could say "immediate superclasses" but the term "immediate" is not a common technical term from what I know and could be confusing to some. It seems to me that "parent", with all of its shortcomings, comes closest and is least likely to be misunderstood. Anyways, I'm not hung up on the name, I'll go along with whatever the consensus is -- assuming there is one. Bran "Karl Frank" 03/08/2004 01:39 PM To Birger Møller-Pedersen , Branislav Selic/Ottawa/IBM@IBMCA cc , , Subject RE: Consolidated Classes chapter A voice of strong support for Birger's point. "parent" is used widely to mean any entity on which another is dependent, in other words the term is broad in meaning, and although a superclass is a parent, a parent is not always a superclass. The word "Specializes" followed by the name(s) of the direct generalization(s) leaves less slop in the fit. - Karl Frank http://www.adaptive.com