Issue 6183: UML 2 Super/Metamodel::Kernel::DataTypes/missing renames (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: Kernel/DataTypes has association enumeration:Enumeration <--> literal:EnumerationLiteral with no renames redefinition while its ownedLiteral:EnumerationLiteral every where else. Resolution: see above Revised Text: Actions taken: September 7, 2003: received issue March 8, 2005: closed issue Discussion: The syntax diagram that shows the association and rolenames that are the subject of this issue is Figure 40 on page 94 as printed, which is page 108 in the electronic pdf. The text definition of the association roles is on page 96 as printed, page 110 in the electronic pdf. Here is the text of the definition Associations • ownedLiteral: EnumerationLiteral[*]The ordered set of literals for this Enumeration. Subsets Element::ownedMember. Indeed the rolename of the EnumerationLiteral is given in the diagram as “literal”, it is not documented as a renaming of “ownedLiteral”, yet elsewhere in the model and the text of the spec, the rolename is “ownedLiteral”. Note that it subsets “ownedMember”. The point is that there is evidence of a naming convention such that there should be a prefix “owned”. There are two ways of fixing this, either we change the name “literal” as it appears in this diagram 40, to read “ownedLiteral”, or we change the name “ownedLiteral” as it appears elsewhere to agree with what is in Diagram 40. There is a convention evident in other names, such as “ownedOperation” which make it clear that changing the name “literal” to read “ownedLiteral” is the better choice, since it maintains a consistency in the structure of such rolenames. The resolution is to change the rolename of EnumerationLiteral, with respect to the referenced association, in the abstract syntax model. We shall fix the name in the model so the it reads “ownedLiteral” on the diagram, so it matches the text and follows the implied naming convention. End of Annotations:===== To: issues@omg.org Subject: UML 2 Super/Metamodel::Kernel::DataTypes/missing renames X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Sun, 7 Sep 2003 08:46:22 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/07/2003 08:46:23, Serialize complete at 09/07/2003 08:46:23 Kernel/DataTypes has association enumeration:Enumeration <--> literal:EnumerationLiteral with no renames redefinition while its ownedLiteral:EnumerationLiteral every where else. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 Subject: TwoMoreProposedClassesIssues for 15 Date: Wed, 26 May 2004 18:31:34 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: TwoMoreProposedClassesIssues for 15 Thread-Index: AcRDWF7YdarZyYxfS6KbzeuZXg8bJQAGEVaA From: "Karl Frank" To: X-OriginalArrivalTime: 26 May 2004 22:31:35.0882 (UTC) FILETIME=[342B12A0:01C44371] Please see attached. 6173 will (I predict) immediately make each person want to create his own new better example. Let's not go there. I have tried that, and it turns out no-one then agrees on what a good example is. The FAS spec says the direction "doesn't matter" so lets not waste time on what the "right" direction is. 6183 is, I hope, not a problem. ClassesIssues6173_6183.doc OMG Issue No: 6183 Title: UML 2 Super/Metamodel::Kernel::DataTypes/missing renames Source: Bran Selic, IBM (bselic@ca.ibm.com) Summary: Kernel/DataTypes has association enumeration:Enumeration <--> literal:EnumerationLiteral with no renames redefinition while it is ownedLiteral:EnumerationLiteral every where else. Discussion: The syntax diagram that shows the association and rolenames that are the subject of this issue is Figure 40 on page 94 as printed, which is page 108 in the electronic pdf. The text definition of the association roles is on page 96 as printed, page 110 in the electronic pdf. Here is the text of the definition Associations . ownedLiteral: EnumerationLiteral[*]The ordered set of literals for this Enumeration. Subsets Element::ownedMember. Indeed the rolename of the EnumerationLiteral is given in the diagram as .literal., it is not documented as a renaming of .ownedLiteral., yet elsewhere in the model and the text of the spec, the rolename is .ownedLiteral.. Note that it subsets .owenedMember.. The point is that there is a naming convention such that there should be a prefix .owned.. There are two ways of fixing this, either we change the name .literal. as it appears in this diagram 40, to read .ownedLiteral., or we change the name .ownedLiteral. as it appears elsewhere to agree with what is in Diagram 40. There is a convention evident in other names, such as .ownedOperation. which make it clear that changing the name .literal. to read .ownedLiteral. is the better choice, since it maintains a consistency in the structure of such rolenames. The resolution is to change the rolename of EnumerationLiteral, with respect to the referenced association, in the abstract syntax model. We shall fix the name in the model so the it reads .ownedLiteral. on the diagram, so it matches the text and follows the implied naming convention Disposition: Resolved Subject: two Classes resolutions for ballot 16 Date: Sun, 30 May 2004 21:32:39 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: two Classes resolutions for ballot 16 Thread-Index: AcRGjDXBC7ofg3fYQWKZKGkUKd+pVgAIa2gQ From: "Karl Frank" To: X-OriginalArrivalTime: 31 May 2004 01:32:40.0753 (UTC) FILETIME=[29C9D210:01C446AF] Here are two Classes issues that did not make it into Ballot 15. Bran thought there was some potential for disagreement about these, so do take a look at them. They are not difficult to understand, so no great mental effort is required in this. - Karl ClassesIssues6173_6183.doc OMG Issue No: 6183 Title: UML 2 Super/Metamodel::Kernel::DataTypes/missing renames Source: Bran Selic, IBM (bselic@ca.ibm.com) Summary: Kernel/DataTypes has association enumeration:Enumeration <--> literal:EnumerationLiteral with no renames redefinition while it is ownedLiteral:EnumerationLiteral every where else. Discussion: The syntax diagram that shows the association and rolenames that are the subject of this issue is Figure 40 on page 94 as printed, which is page 108 in the electronic pdf. The text definition of the association roles is on page 96 as printed, page 110 in the electronic pdf. Here is the text of the definition Associations . ownedLiteral: EnumerationLiteral[*]The ordered set of literals for this Enumeration. Subsets Element::ownedMember. Indeed the rolename of the EnumerationLiteral is given in the diagram as .literal., it is not documented as a renaming of .ownedLiteral., yet elsewhere in the model and the text of the spec, the rolename is .ownedLiteral.. Note that it subsets .ownedMember.. The point is that there is evidence of a naming convention such that there should be a prefix .owned.. There are two ways of fixing this, either we change the name .literal. as it appears in this diagram 40, to read .ownedLiteral., or we change the name .ownedLiteral. as it appears elsewhere to agree with what is in Diagram 40. There is a convention evident in other names, such as .ownedOperation. which make it clear that changing the name .literal. to read .ownedLiteral. is the better choice, since it maintains a consistency in the structure of such rolenames. The resolution is to change the rolename of EnumerationLiteral, with respect to the referenced association, in the abstract syntax model. We shall fix the name in the model so the it reads .ownedLiteral. on the diagram, so it matches the text and follows the implied naming convention Disposition: Resolved e-mail: bselic@ca.ibm.com