Issue 8952: UML 2 - Invalid subsetting of composition ends (uml2-rtf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Critical Summary: In figure 3, the association end Element::owner is shown as navigable and as a union of all its subsets. According to the following convention defined in section 6.5.2, this end is owned by the class and not the composition association: " • An association with neither end marked by navigability arrows means that: • the association is navigable in both directions • each association end is owned by the classifier at the opposite end (i.e., neither end is owned by the association)" Throughout the spec, there are many places where this association end is specialized into a non-navigable association end (e.g., figures 4, 5, ...). But, according to the following additional rule in 6.5.2: " • An association with one end marked by a navigability arrow means that: • the association is navigable in the direction of that end, • the marked association end is owned by the classifier, and • the opposite (unmarked) association end is owned by the association" this means that such non-navigable association ends are owned by the association and not by the class. Consequently, such ends cannot be valid specializations of Element::owner (as stated in the spec) since they are owned by a classifier (the association) that is not related by generalization to the classifier (i.e., metaclass) that owns the original attribute. Recommendation: (1) Define Element::owner such that it is owned by the composition association and not by the Element class. This will make all the currently invalid subsettings of this type valid. (2) Do this for all other cases of invalid subsets of this type in the spec, if they exist. (3) Make it explicit in the spec that these are exceptions to the convention described in 6.5.2 Resolution: Revised Text: Actions taken: August 8, 2005: received issue Discussion: End of Annotations:===== c: Jishnu Mukerji , jamsden@us.ibm.com, Pete.Rivett@adaptive.com, Doug.Tolbert@unisys.com Subject: UML 2 - Invalid subsetting of composition ends X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 8 Aug 2005 12:44:21 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/08/2005 12:44:22, Serialize complete at 08/08/2005 12:44:22 (Juergen: this is a high-priority issue that must be registered ASAP -- thanks.) In figure 3, the association end Element::owner is shown as navigable and as a union of all its subsets. According to the following convention defined in section 6.5.2, this end is owned by the class and not the composition association: " . An association with neither end marked by navigability arrows means that: . the association is navigable in both directions . each association end is owned by the classifier at the opposite end (i.e., neither end is owned by the association)" Throughout the spec, there are many places where this association end is specialized into a non-navigable association end (e.g., figures 4, 5, ...). But, according to the following additional rule in 6.5.2: " . An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association" this means that such non-navigable association ends are owned by the association and not by the class. Consequently, such ends cannot be valid specializations of Element::owner (as stated in the spec) since they are owned by a classifier (the association) that is not related by generalization to the classifier (i.e., metaclass) that owns the original attribute. Recommendation: (1) Define Element::owner such that it is owned by the composition association and not by the Element class. This will make all the currently invalid subsettings of this type valid. (2) Do this for all other cases of invalid subsets of this type in the spec, if they exist. (3) Make it explicit in the spec that these are exceptions to the convention described in 6.5.2 Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com