Issue 6462: UML 2 Issue: AssociationEnd (uml2-rtf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: PROBLEM STATEMENT In UML 1 the navigability of an association end was specified by the meta-attribute AssociationEnd.isNavigable. In UML 2 apparently this meta-attribute dissapears, and AssociationEnd is substituted by Property. We know whether an association end is navigable by the following rule: if the property is owned by a class, it represents a navigable end; if the property is owned by an association, it represents a non-navigable end (see Superstructure, p. 89). However, references to old metaclass AssociationEnd and old meta-attribute isNavigable still appear in the Spec in several places and OCL expressions (AssociationEnd appears in: Infrastructure, p. 33; Superstructure, pp. 119, 245; isNavigable appears in: Superstructure, p. 245). PROPOSED SOLUTION Add derived meta-attribute /isNavigable to metaclass Property. Eliminate references to AssociationEnd. Resolution: Discussion This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification. Disposition: Closed - No Change Revised Text: In the UML 2.2 Superstructure specification (ptc/08-05-05): In Subclause 7.3.4 (AssociationClass), Constraint [1] text, change "AssociationEnds" to association ends. In Subclause 11.3.33 (ReadLinkAction), in the OCL for Constraints [2] to [5], change "AssociationEnd" to "Property". In the UML 2.2 Infrastructure specification (ptc/08-05-04), Subclause 8.1, the last sentence of the last paragraph, change "AssociationEnd" to "Property". Actions taken: November 7, 2003: received issue February 18, 2005: moved from infrastructure February 20, 2015: closed issue Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== ubject: Fw: UML 2 Issue: AssociationEnd X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 7 Nov 2003 08:30:49 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 11/07/2003 08:30:54, Serialize complete at 11/07/2003 08:30:54 Issue raised by Gonzalo Genova. 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 ----- Forwarded by Branislav Selic/Ottawa/IBM on 11/07/2003 07:47 AM ----- Gonzalo Genova 11/06/2003 01:33 PM To: "'issues@omg.org'" , Branislav Selic/Ottawa/IBM@IBMCA cc: "Juan Llorens (inf)" , "J.Miguel Fuentes Torres" Subject: UML 2 Issue: AssociationEnd This issue refers to UML 2.0 Infrastructure Specification (ptc/03-09-15) and UML 2.0 Superstructure Specification (ptc/03-08-02). PROBLEM STATEMENT In UML 1 the navigability of an association end was specified by the meta-attribute AssociationEnd.isNavigable. In UML 2 apparently this meta-attribute dissapears, and AssociationEnd is substituted by Property. We know whether an association end is navigable by the following rule: if the property is owned by a class, it represents a navigable end; if the property is owned by an association, it represents a non-navigable end (see Superstructure, p. 89). However, references to old metaclass AssociationEnd and old meta-attribute isNavigable still appear in the Spec in several places and OCL expressions (AssociationEnd appears in: Infrastructure, p. 33; Superstructure, pp. 119, 245; isNavigable appears in: Superstructure, p. 245). PROPOSED SOLUTION Add derived meta-attribute /isNavigable to metaclass Property. Eliminate references to AssociationEnd. Date: Thu, 11 Mar 2004 07:33:25 -0500 From: Conrad Bock To: uml2-superstructure-ftf@omg.org Subject: RE: Issues 6243, 6462 User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 208.57.87.154 X-NIST-MailScanner-Information: Please contact the ISP for more information X-NIST-MailScanner: Found to be clean X-MailScanner-From: conrad.bock@nist.gov Joaquin, > If i create an association class, A, connecting two other classes, B > and C, then in a link of that association class, there are references > to an object of class B (b:B) and an object of class C (c:C), these > references are held in an object of class A (a:A), but the references > are not attributes (if you like, slots) of that object. > > Is that right? Right, see Figure 30. The association ends (represented as properties) are linked to the association via memberEnd and ownedEnd. Neither of them subsets ownedAttribute. > Is that a change from UML 1? (I can't make much sense out of 2.5.4.2 of > Formal/03/03/01) Yes, in UML 1.x the association ends were always owned by the association, and that was separate from navigability. UML 2 conflates these. > If that is right does it mean that the references are not held in > slots of that object, a:A? Or does it mean that they are held in > slots, but those slots of a:A do not correspond to attributes of the > class, A. Good question, I hadn't thought about the effect on the instance model. > 17.6.1 refers the user to page 89. There we read "When a property is > owned by a class it represents an attribute." Does that need to be > rewritten? Guess it does. > Or is it the case that the properties of an association class that > specify the capability to hold the references are not properties > owned by that class? They can be owned by the association class, but not necessarily (that's memberEnd in Figure 30). To: Conrad Bock Cc: uml2-superstructure-ftf@omg.org Subject: RE: Issues 6243, 6462 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 11 Mar 2004 09:54:21 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/11/2004 09:54:38, Serialize complete at 03/11/2004 09:54:38 I am not sure that it matters what this thing is called as long as we agree that there are slots corresponding to link ends. Depending on the association, these slots will belong either to the link or to the object tht is linked. If we agree on that, the rest is a mere naming issue. Bran Conrad Bock 03/11/2004 07:33 AM To uml2-superstructure-ftf@omg.org cc Subject RE: Issues 6243, 6462 Joaquin, > If i create an association class, A, connecting two other classes, B > and C, then in a link of that association class, there are references > to an object of class B (b:B) and an object of class C (c:C), these > references are held in an object of class A (a:A), but the references > are not attributes (if you like, slots) of that object. > > Is that right? Right, see Figure 30. The association ends (represented as properties) are linked to the association via memberEnd and ownedEnd. Neither of them subsets ownedAttribute. > Is that a change from UML 1? (I can't make much sense out of 2.5.4.2 of > Formal/03/03/01) Yes, in UML 1.x the association ends were always owned by the association, and that was separate from navigability. UML 2 conflates these. > If that is right does it mean that the references are not held in > slots of that object, a:A? Or does it mean that they are held in > slots, but those slots of a:A do not correspond to attributes of the > class, A. Good question, I hadn't thought about the effect on the instance model. > 17.6.1 refers the user to page 89. There we read "When a property is > owned by a class it represents an attribute." Does that need to be > rewritten? Guess it does. > Or is it the case that the properties of an association class that > specify the capability to hold the references are not properties > owned by that class? They can be owned by the association class, but not necessarily (that's memberEnd in Figure 30). Conrad Date: Thu, 11 Mar 2004 13:10:34 -0500 From: Conrad Bock To: uml2-superstructure-ftf@omg.org, mof2xmi-ftf@omg.org, mu2i-ftf@omg.org Subject: RE: Issues 6243, 6462 User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 209.216.225.38 X-NIST-MailScanner-Information: Please contact the ISP for more information X-NIST-MailScanner: Found to be clean X-MailScanner-From: conrad.bock@nist.gov Bran, > I don't think vendors are so dumb not to think of the obvious > solution. I'd be glad to be missing something, I just don't understand. Here's the problem: Navigation from an object = object owns an association end, ie, changes the class. We don't want to change the class. What's the obvious vendor solution? How does renaming navigation in UML solve it? > I am not sure that it matters what this thing is called as long as we > agree that there are slots corresponding to link ends. > Depending on the association, these slots will belong either to the > link or to the object that is linked. There aren't any slots on associations for the ends. Slots require a structural feature (Figure 18), and the ends are features of associations at best. > If we agree on that, the rest is a mere naming issue. Even if we fix the above, the text I cited dictates that the vendor can only navigate from objects that own the ends. Conrad 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 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 18:49:22 -0800 To: uml2-superstructure-ftf@omg.org, mof2xmi-ftf@omg.org, mu2i-ftf@omg.org From: Joaquin Miller Subject: ,cl, Issues 6243, 6462 Conrad wrote: There aren't any slots on associations for the ends. Slots require a structural feature (Figure 18), and the ends are features of associations at best. This is the issue (as i understand it). Let's assume for the moment that Conrad is correct about the implications of the metamodel. Then there is text that is wrong, for example: "When a property is owned by a class it represents an attribute." [7.11.4] And, i feel strongly, we ought to change the metamodel to let objects that are instantiated from an AssociationClass have slots for the ends. Now, let's assume for the moment that Conrad is n o t correct about the implications of the metamodel. Then i am happy, the text quoted above is correct, and at least objects that are instantiated from an AssociationClass have slots for the ends. In either case, we ought to discuss just what the ends of a link are, when they are not slots. PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Subject: RE: ,cl, Issues 6243, 6462 Date: Thu, 11 Mar 2004 23:04:32 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issues 6243, 6462 Thread-Index: AcQH4GQYMqQOnRaUSamXRpHIzHbXKQAAv0Rg From: "Pete Rivett" To: "Joaquin Miller" , , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i2C3urre003323 See section 15 of the MOF spec ptc/03-10-04 for an instance model for the semantics of core classes, including pre- and post-conditions for the operations. This introduces the notion of a 'LinkSlot' for Association. Though these are CMOF (as opposed to UML) semantics, they are not that MOF-specific, and at least provide a starting point and a vocabulary. It does not include AssociationClasses explicitly though (which are not in MOF). With respect to the AssociationClasses argument between Joaquin and Conrad my opinion FWIW is that an AssociationClass will have as attributes only those ends which are not 'navigable' from the respective end Class. So if we have AssociationClass AB which is navigable from A to B but not vice versa then we'll have Property 'b' which is owned by A and hence an attribute of A (and also a member of AB), and we'll have Property 'a' which is owned by AB and hence is an attribute of AB (and which is *not* a member of B). 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: Joaquin Miller [mailto:joaquin.no.spam@acm.org] > Sent: Friday, March 12, 2004 2:49 AM > To: uml2-superstructure-ftf@omg.org; mof2xmi-ftf@omg.org; > mu2i-ftf@omg.org > Subject: ,cl, Issues 6243, 6462 > > Conrad wrote: > > >There aren't any slots on associations for the ends. Slots require a > >structural feature (Figure 18), and the ends are features of > >associations at best. > > This is the issue (as i understand it). > > Let's assume for the moment that Conrad is correct about the > implications > of the metamodel. > Then there is text that is wrong, for example: "When a > property is > owned by a class it represents an attribute." [7.11.4] > And, i feel strongly, we ought to change the metamodel to > let objects > that are instantiated from an AssociationClass have slots for > the ends. > > > Now, let's assume for the moment that Conrad is n o t > correct about the > implications of the metamodel. > Then i am happy, the text quoted above is correct, and at least > objects that are instantiated from an AssociationClass have > slots for the ends. > > > In either case, we ought to discuss just what the ends of a > link are, when > they are not slots. > > > > > > > > > PGP Fingerprint: > CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 > > > Reply-To: From: "Conrad Bock" To: , , Subject: RE: ,cl, Issues 6243, 6462 Date: Thu, 11 Mar 2004 23:25:45 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Joaquin, > >There aren't any slots on associations for the ends. Slots require a > >structural feature (Figure 18), and the ends are features of > >associations at best. > > This is the issue (as i understand it). It's related but different. Sorry to keep pasting this text from infra/super, but it seems clear to me: 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. It says that navigating from a class requires that the class must change. That's the issue.