Issue 9404: inability to uniquely reference association ends (ocl2-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: Section 7.5.3 of ptc/05-06-06 starts with the following: "Starting from a specific object, we can navigate an association on the class diagram to refer to other objects and their properties. To do so, we navigate the association by using the opposite association-end:" However, unlike in UML 1.x, in UML2 this may well be ambiguous (since names of ends owned by Associations only have to be unique within the Association and not within the context of the Class). OCL should therefore explicitly allow qualification using the name of the Association itself as well as the end name (it is not clear whether this is currently allowed as part of the syntax for 'associationendname' so there should be an example to show this. This would make it consistent with the metamodel which allows reference to specific Properties. For example we could have associations A1 and A2 both linking classes C1 and C2 and each with ends c1 and c2 owned by the respective associations. OCL does not then address the fact that aC1.c2 is ambiguous - unlike the case with unnamed ends it does not even say that it may be ambiguous and is hence disallowed. However rather than disallowing the navigation OCL should have a syntax to allow qualification by the association name For example aC1.A1::c2 The same could be used for missing association end names: If A1 had unnamed ends then one could use aC1.A1::C2 Resolution: Revised Text: (1) In section 7.5.3 add the following text after Missing Association End Names section: Qualifying association ends with association names In cases the association that is being navigated has a non empty name, it is possible to qualify the accessed role name with the name of the association. This notation can be used to solve ambiguities as in the example below: A1 and A2 are two associations both linking classes C1 and C2 and each with ends c1 and c2. If aC1 is a C1 access, aC1.c2 will not be valid since it is ambiguous, whereas aC1.A1::c2 or aC1.A2::c2 will be valid. Actions taken: February 28, 2006: received issue October 16, 2009: closed issue Discussion: The proposed qualification by the association name solves the issue in a consistent way. Notice however that in the case of missing association end names, OCL already have a convention which is to use the class name with the first letter lowerized. End of Annotations:===== ubject: RE: Issues on OCL2 - correction to ussue just raised Date: Tue, 28 Feb 2006 19:34:51 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues on OCL2 - correction to ussue just raised Thread-Index: AcY83q/dW5WrPGSHQpeTk4pcJZEGWgAAQV2g From: "Pete Rivett" To: I missed something in the first issue I raised below - please enter Issue A) as follows. Issue B) is unchanged: A) inability to uniquely reference association ends Section 7.5.3 of ptc/05-06-06 starts with the following: "Starting from a specific object, we can navigate an association on the class diagram to refer to other objects and their properties. To do so, we navigate the association by using the opposite association-end:" However, unlike in UML 1.x, in UML2 this may well be ambiguous (since names of ends owned by Associations only have to be unique within the Association and not within the context of the Class). OCL should therefore explicitly allow qualification using the name of the Association itself as well as the end name (it is not clear whether this is currently allowed as part of the syntax for 'associationendname' so there should be an example to show this. This would make it consistent with the metamodel which allows reference to specific Properties. For example we could have associations A1 and A2 both linking classes C1 and C2 and each with ends c1 and c2 owned by the respective associations. OCL does not then address the fact that aC1.c2 is ambiguous - unlike the case with unnamed ends it does not even say that it may be ambiguous and is hence disallowed. However rather than disallowing the navigation OCL should have a syntax to allow qualification by the association name For example aC1.A1::c2 The same could be used for missing association end names: If A1 had unnamed ends then one could use aC1.A1::C2 -------------------------------------------------------------------------------- From: Pete Rivett Sent: Wednesday, March 01, 2006 3:18 AM To: issues@omg.org Subject: Issues on OCL2 A) inability to uniquely reference association ends Section 7.5.3 of ptc/05-06-06 starts with the following: Starting from a specific object, we can navigate an association on the class diagram to refer to other objects and their properties. To do so, we navigate the association by using the opposite association-end: However, unlike in UML 1.x, in UML2 this may well be ambiguous (since names of ends owned by Associations only have to be unique within the Association and not within the context of the Class). OCL should therefore have a syntax to allow qualification using the name of the Association itself as well as the end name. This would make it consistent with the metamodel which allows reference to specific Properties. For example we could have associations A1 and A2 both linking classes C1 and C2 and each with ends c1 and c2 owned by the respective associations. OCL does not then address the fact that aC1.c2 is ambiguous - unlike the case with unnamed ends it does not even say that it may be ambiguous and is hence disallowed. However rather than disallowing the navigation OCL should have a syntax to allow qualification by the association name For example aC1.[A1.c2] The same could be used for missing association end names: If A1 had unnamed ends then one could use aC1.[A1.C2] B) Wrong subtyping of PropertyCallExp and NavigationCallExp In section 8.3.2 of ptc/05-06-06 PropertyCall is shown as a subclass of NavigationCallExp -this seems the wrong way round: NavigationCallExp seems to be a specialization for when the Property is an AssociationEnd. To illustrate this, the description of NavigationCallExp starts with the following, which would not apply if the Property in question were an ownedAttribute of a class: "A NavigationCallExp is a reference to an AssociationEnd or an AssociationClass defined in a UML model." Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Hello House, 135 Somerford Road, Christchurch, BH23 3PY, UK Tel: +44 (0)1202 491243 Fax: +44 (0)1202 491241 http://www.adaptive.com