Issue 6243: Association not affecting ends (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Critical Summary: Restore UML 1.x capability of modeling associations without modifying the end types. This is needed for database modeling, for profiles to be used with fixed-schema repositories, and is the differentiator of UML over OWL, etc. Resolution: see above Revised Text: Actions taken: September 8, 2003: received issue March 8, 2005: closed issue Discussion: Summary The intent of this resolution is to harmonize the relational (UML 1.x) and object-oriented (UML 2) viewpoints in modeling associations, properties, and navigability. It recommends separating ownership and navigation, while preserving the other beneficial aspects of the UML 2 model, in particular, the unification of properties and association ends. The changes provide more flexiblity than both UML 1.x and 2.0 in modeling commonly needed combinations of navigability and ownership. Comparing UML 1.x and UML 2: UML 1.x supported the specification of associations without modifying the classes being associated. Association ends were always owned by the association, regardless of the navigability of the association. The model was most appropriate for relational applications such as databases, hash tables, SmallTalk dictionaries, and predicate logic, and was useful when the classes being associated should not be modified for some reason, such as using a read-only model, or derived associations. It was less appropriate for object-oriented applications, which expected that specifying navigation of an association would modify the source class of the navigation by defining an attribute on it to support runtime traversal from instances of the class. The UML 1.x model also separated attributes and associations, even though these are usually different views of the same underlyi ng semantic. UML 2 requires modification of the classes being associated in common cases. In particular, it requires that an association end (modeled as a property) be owned by the end classes when it is the source of navigation. The model is most appropriate for object-oriented or record-based applications, and supports supports class diagrams and composite structure diagrams as views on a single underlying model. It is less appropriate for relational applications and derived associations, which expect that the navigation of an association does not necessarily modify the source class of the navigation. Example: Suppose we model an association of teachers to courses like this: In UML 2 this means: For the relational modeler, the above will normally imply a column in the Teacher table, even when this is not desired. Instead, the modeler might want an intersection/correlation table, which in effect puts the columns on the association. UML 2 offers this solution to have the association own properties for teacher and course: However, this prevents navigation from both teachers and courses, or at least does not require it in the generated implementation. The modeler probably wants the compiler to generate an API or other means for querying a course for its teacher. The model must be refined to: This again has the undesired effect of an attribute on Teacher, because the current specification does not indicate that derived associations should not affect the end classes. In addition, it is a detailed model more appropriate for the late design stage, rather than early as in the first example figure. And a late stage Teacher Course 0..* 1 +teacher +course Teacher course : Course [0..*] Course 1 0..* +teacher +course Teacher Course 1 0..* +teacher +course Teacher course : Course [0..*] TeacherCourseAssociation teacher : Teacher [1] course : Course [1] 0..* 1 +teacherCourse +teacher Course 1 0..* +teacher +course / 1 1 +teacherCourse model might migrate the column across to the other end, to prevent repeated groups and normalize the database: These examples shows that navigability in relational modeling is a requirement for query services, rather than property ownership. The model should indicate it is possible at runtime to get courses given a teacher, rather than indicate Teacher has a course property. Proposed changes to Infrastructure: In Figure 73: Add association between Property and Association that identifies the owned ends that are navigable, called navigableOwnEnd, specialized from ownedEnd: In Infrastructure, Association class, section 11.3.1: In Description section: Replace second paragraph with: “An end property of an association that is owned by an end class or that is a navigable owned end of the association Teacher Course teacher : Teacher [1] 1 0..* +teacher +course Property isReadOnly : Boolean = false isDerivedUnion : Boolean = false Association isDerived : Boolean = false 0..1 * +owningAssociation {subsets association, subsets namespace, subsets featuringClassifier} +ownedEnd {ordered, subsets memberEnd, subsets feature, subsets ownedMember} 2..* +association 0..1 +memberEnd {ordered, subsets member} +navigableOwnedEnd {subsets ownedEnd} indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the opposite ends.” In Associations section: ownedEnd entry, delete "non-navigable". Add navigableOwnedEnd attribute: navigableOwnedEnd : Property [*] The navigable ends that are owned by the association itself. Subsets Association.ownedEnd. In Constraints section add new constraint: Association ends of associations with more than two ends must be owned by the association. if memberEnd->size() > 2 then ownedEnd->includesAll(memberEnd) In Semantics section: Delete the sentence “The semantics of navigable association ends are the same as for attributes.” In Notation section: Replace paragraph above Figure 77 with: "Figure 77 shows that the attribute notation can be used for an association end owned by a class, because an association end owned by a class is also an attribute. This notation may be used in conjunction with the line -arrow notation to make it perfectly clear that the attribute is also an association end." Change caption of Figure 77 to "Example of attribute notation for navigable end owned by an end class." In Infrastructure, in Property class, section 11.3.5: Replace second two paragraphs with: “A property related to a class by ownedAttribute represents an attribute, and might also represent an association end. It relates an instance of the class to a value or set of values of the type of the attribute.“A property related to an association by memberEnd or its specializations represents an end of the association. The type of the property is the type of the end of the association.” In Constraints section: Replace rule 5 with: [5] A navigable property can only be redefined or subsetted by a navigable property. (subsettedProperty->exists(sp | sp.isNavigable() implies isNavigable()) and (redefinedProperty->exists(rp | rp.isNavigable implies isNavigable()) Replace rule 7 with: [7] Only a navigable property can be marked as readOnly. isReadOnly implies isNavigable() In Additional Operations section add new operation: The query isNavigable indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean IsNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd - >includes(self) In Semantics section: First paragraph, replace second sentence with: “When related to an association via memberEnd or one of its specializations, it represents an end of the association.” Ninth paragraph, after "If a navigable property", delete "(attribute)". Proposed changes to MOF 2 Core: Section 15.2 (MOF Instances Model), under Link Slot, p 59, remove "(it is owned by a Class)". Section 16.1 (Migration from MOF 1.4): under Association End, in the right column, remove the second sentence "If the property is owned by the association, it is not navigable (no reference is referencing it)." Proposed changes to Superstructure: In Figure 30: Add association between Property and Association that identifies the owned ends that are navigable, called navigableOwnEnd, specialized from ownedEnd: In Association class, section 7.11.2: In Description section: Replace second paragraph with: “An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the opposite ends.” In Associations section: ownedEnd entry, delete "non-navigable". Add navigableOwnedEnd attribute: navigableOwnedEnd : Property [*] The navigable ends that are owned by the association itself. Subsets Association.ownedEnd. Property isDerived : Boolean = false isReadOnly : Boolean = false isDerivedUnion : Boolean = false / default : String aggregation : AggregationKind = none / isComposite : Boolean Association isDerived : Boolean = false 0..1 * +owningAssociation {subsets association, subsets namespace, subsets featuringClassifier} +ownedEnd {ordered, subsets memberEnd, subsets feature, subsets ownedMember} 0..1 2..* +association +memberEnd {ordered, subsets member} +navigableOwnedEnd {subsets ownedEnd} In Constraints section add new constraint: Association ends of associations with more than two ends must be owned by the association. if memberEnd->size() > 2 then ownedEnd->includesAll(memberEnd) In Semantics section: Delete the sentence “The semantics of navigable association ends are the same as for attributes. In Examples section: Replace paragraph above Figure 34 with: "Figure 34 shows that the attribute notation can be used for an association end owned by a class, because an association end owned by a class is also an attribute. This notation may be used in conjunction with the line -arrow notation to make it perfectly clear that the attribute is also an association end." Change caption of Figure 34 to "Example of attribute notation for navigable end owned by an end class." In Property class, section 7.11.4: Replace second two paragraphs with: “A property related to a class by ownedAttribute represents an attribute, and might also represent an association end. It relates an instance of the class to a value or set of values of the type of the attribute.” “A property related to an association by memberEnd or its specializations represents an end of the association. The type of the property is the type of the end of the association.” In Constraints section: Replace rule 4 with: [4] A navigable property can only be redefined or subsetted by a navigable property. (subsettedProperty->exists(sp | sp.isNavigable() implies isNavigable()) and (redefinedProperty->exists(rp | rp.isNavigable implies isNavigable()) Replace rule 6 with: [6] Only a navigable property can be marked as readOnly. isReadOnly implies isNavigable() Add Additional Operations section after Constraints containing: [1] The query isNavigable indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean IsNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd - >includes(self) In Semantics section: First paragraph, replace second sentence with: “When related to an association via memberEnd or one of its specializations, it represents an end of the association.” Ninth paragraph, after "If a navigable property", delete "(attribute)". In ReadLinkAction class, Constraints, in OCL of constraint [4], replace “isNavigable = #true” with “isNavigable()”. End of Annotations:===== eply-To: From: "Conrad Bock" To: Subject: Two more Date: Mon, 8 Sep 2003 22:14:42 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Hi Juergen, Here are two more UML 2 Super issues. I hope the deadline is midnight ET. :) Thanks, Conrad ******************************************************************** Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Critical Subject: Association not affecting ends Restore UML 1.x capability of modeling associations without modifying the end types. This is needed for database modeling, for profiles to be used with fixed-schema repositories, and is the differentiator of UML over OWL, etc. Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 07 Mar 2004 10:47:23 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: FW: Issues 6243, 6462 Conrad, I'm afraid i am a little slow on this. I wrote: > If it is an association class, then aren't the properties (which declare references to object linked by instances of that association class) owned attributes of that association class? You replied: No, the ends of an association are not ownedAttributes of the association, even though they use the Property metaclass. At most they are features. See ownedEnd and memberEnd in Figure 30. The proposal doesn't change this aspect of the model. Let me repeat this, to see if i understand. 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? Is that explained in 17.6.1? Is that a change from UML 1? (I can't make much sense out of 2.5.4.2 of Formal/03/03/01) 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. 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? 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? [If that last sentence is hard to swallow, i'll suppose the references are held in slots of a:A, then the question is: Or is it the case that the slots of the object, a, that hold the references to the objects, b and c, are not slots that correspond to properties owned by the class, A?] Or is it simply the case that the properties in question are attributes of A, but not owned attributes of A? Sorry to be so slow. Conrad Bock wrote: Hi Joaquin, Joaquin wrote: > Conrad wrote: > > - isNavigable can be either true or false for Properties owned by associations that are also used as ends (note: these are not ownedAttributes of the association, if it is a class). > > I don't understand the note. I may be misreading the referent of 'it.' If 'it' refers to the association, then it is an association class, right? Yes (updated the sketch below). > If it is an association class, then aren't the properties (which declare references to object linked by instances of that association class) owned attributes of that association class? No, the ends of an association are not ownedAttributes of the association, even though they use the Property metaclass. At most they are features. See ownedEnd and memberEnd in Figure 30. The proposal doesn't change this aspect of the model. Added a bullet for removing the existing text on navigation by ownership. Conrad - Add isNavigable (underived) on Property, default true. - Properties used as association ends can be owned by the end classes or the association. - isNavigable = true for Properties that are ownedAttributes of classes, whether or not they are used as association ends. - isNavigable can be either true or false for Properties owned by associations that are also used as ends (note: these are not ownedAttributes of the association, if the association is a class). - Delete existing text that determines navigability by ownership of the end property. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 07 Mar 2004 20:33:50 -0800 To: UML Superstructure FTF , MOF UML Infrastructure FTF From: Joaquin Miller Subject: ,cl, Issue 6243 If anything needs to be changed, it should be the term "navigable". But, it is probably too late to change it now. I do not feel it is too late to change this. Obviously we will have to be explicit that this concept can, for backward compatibility, also be called 'navigable.' But we can better explain the concept and give it a better name. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Subject: RE: ,cl, Issue 6243 Date: Mon, 8 Mar 2004 00:14:13 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issue 6243 Thread-Index: AcQEx4UTbBE2iA9qQyixyUQfZdIYzgAASxGQ From: "Pete Rivett" To: "Joaquin Miller" , "UML Superstructure FTF" , "MOF UML Infrastructure FTF" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i28574re026005 FWIW unlike UML 1.x, at UML 2.0 'navigable' does not appear in the metamodel itself so such a change would not have an impact on the normative spec. Though the term is used in quite a few places, changing it would improve clarity. For example, constraint [7] for Property (11.3.5 of Infra) is: [7] Only a navigable property can be marked as readOnly. isReadOnly implies class->notEmpty() .. which does not really make a lot of sense unless you understand the very particular meaning of 'navigable' we have adopted. And there is not a place where this meaning is definitively explained: it pervades a number of other definitions. 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 ________________________________ From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] Sent: Monday, March 08, 2004 4:34 AM To: UML Superstructure FTF; MOF UML Infrastructure FTF Subject: ,cl, Issue 6243 If anything needs to be changed, it should be the term "navigable". But, it is probably too late to change it now. I do not feel it is too late to change this. Obviously we will have to be explicit that this concept can, for backward compatibility, also be called 'navigable.' But we can better explain the concept and give it a better name. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 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). c: 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 navigable ends. 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 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 19:03:24 -0800 To: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: ,cl, Issue 6243 What is the meaning of 'to navigate' and what is the correct diction? It's *always* possible to navigate via the Association. Navigation happens at runtime and may not use MOF at all I copy these two fragments to point out that there is no agreement on the meaning of 'to navigate' and the related 'navigation' and 'navigable.' Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 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 19:08:55 -0800 To: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: , cl, Issues 6242 and 6243 How many questions? Guus wrote: The definition of navigability is broken in that it no longer allows UML 1.x models where associations owned their ends, and where "isNavigable" can be set for those associations. So, i was wrong when i wrote "this is t h e issue." .......................... These questions each are two questions, where is 'Is it the case that' and then 'Should it be the case that.' there are slots for ends on links of plain associations? there are slots for ends on link objects of association classes? an end of an association class, if not an attribute of the associated class, is an attribute of that association class? if an association owns an end, isNavigable can be set for that end. 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. Conrad Reply-To: From: "Conrad Bock" To: , , Subject: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Sun, 21 Mar 2004 14:32:33 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Hi all, Here's a proposed resolution to Issue 6243: Association not affecting ends. It follows the sketch previously posted, except for: - Making isNavigable = true for properties related by ownedAttributes to class. That would have hosed Pete's resolution to the recent discussion about ends as attributes. - Clarifying the definition navigation, which is the topic of Infra Issue 6460: UML 2 Issue: definition of navigability. If it looks OK, I can propose the same changes to infra. Looks like the text is not exactly the same. Conrad P.S. This is not related to the recent discussion about associations ends being attributes. That issue hasn't been filed yet, as far as I know. issueresolution-6243.doc OMG Issue No: 6243 Title: Association not affecting ends Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Restore UML 1.x capability of modeling associations without modifying the end types. This is needed for database modeling, for profiles to be used with fixed-schema repositories, and is the differentiator of UML over OWL, etc. Discussion: Separate association end ownership from navigation by introducing an isNavigable attribute on properties, as indicated below. In Figure 30: Add attribute to Property: isNavigable : Boolean = true In Association class: In Description section: Delete second paragraph. In Associations section: ownedEnd entry, delete "non-navigable". In Semantics section: Delete the sentence above "Note". In Notation section: Replace paragraph above Figure 34 with: "Figure 34 shows that the attribute notation can be used for a navigable end owned by an end class, because a navigable end owned by an end class is also an attribute. Normally in this case the notation would be used in conjunction with the line-arrow notation to make it perfectly clear that the attribute is also an association end." Change caption of Figure 34 to "Example of attribute notation for navigable end owned by an end class." In Property class: Replace second two paragraphs with: .A property is related to a class by ownedAttribute represents an attribute, and might also represent an association end. It relates an instance of the class to a value or set of values of the type of the attribute.. .A property related to an association by memberEnd or ownedEnd represents an end of the association. The type of the property is the type of the end of the association.. In Constraints section: Replace rule 4 with: [4] A navigable property can only be redefined or subsetted by a navigable property. (subsettedProperty->exists(sp | sp.isNavigable implies isNavigable) and (redefinedProperty->exists(rp | rp.isNavigable->implies isNavigable) Replace rule 6 with: [6] Only a navigable property can be marked as readOnly. isReadOnly implies isNavigable In Semantics section: First paragraph, replace second sentence with: .When related to an association via ownedEnd or memberEnd, it represents an end of the association.. Ninth paragraph, after "If a navigable property", delete "(attribute)". Disposition: Resolved Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Mon, 22 Mar 2004 01:14:29 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: , cl, Issues 6242 (Association not affecting ends), proposed resolution Thread-Index: AcQPfFit2e0dkoy7SLSqtzZFCso/6QAV6KQw From: "Pete Rivett" To: , , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i2M66Are001748 I'm not sure a resolution is needed for the issue as worded - which is for 'modeling associations without modifying the end types'. This is possible in the existing spec. The resolution actually addresses a different issue: that of 'modeling property navigability independently of property ownership'. I don't think this can really be resolved until we have an agreed definition of navigability - since currently the spec *equates* navigability with property ownership (that is the only semantic associated with navigability). This is different from UML 1.x admittedly, but the words in UML 1.x are also different from Conrad's desired definition which is more to do with *efficiency* of navigation than *possibility* of navigation. So it seems we should address issue 6460 first. Which has yet another proposal in the issue more biased towards the OO ability to send messages (which I assume will not satisfy the information modeling users that Conrad is championing). More specifically I don't think we can adopt Conrad's resolution which is to add 'isNavigable' to Property when it has no proposed description or semantics as to what it means! Also I think the resolution deletes too much without replacing it - e.g. 2nd paragraph of description of Associations. In its stead there should be a similar description about the interaction (or not) of ownership and navigability. And there should also probably be some new constraints e.g. if a property is owned by a class then I assume it must be navigable. 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: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, March 21, 2004 7:33 PM > To: mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; > uml2-superstructure-ftf@omg.org > Subject: , cl, Issues 6242 (Association not affecting ends), > proposed resolution > > > Hi all, > > Here's a proposed resolution to Issue 6243: Association not affecting > ends. It follows the sketch previously posted, except for: > > - Making isNavigable = true for properties related by > ownedAttributes > to class. That would have hosed Pete's resolution to the recent > discussion about ends as attributes. > > - Clarifying the definition navigation, which is the topic of Infra > Issue 6460: UML 2 Issue: definition of navigability. > > If it looks OK, I can propose the same changes to infra. > Looks like the > text is not exactly the same. > > Conrad > > P.S. This is not related to the recent discussion about associations > ends being attributes. That issue hasn't been filed yet, as far as I > know. > To: "Pete Rivett" Cc: conrad.bock@nist.gov, mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 22 Mar 2004 12:07:24 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/22/2004 12:07:29, Serialize complete at 03/22/2004 12:07:29 I tend to agree with Pete's line of thinking, particularly the point that the issue being debated is about efficiency rather than about a fundamental capability. Furthermore, it seems to me that a vendor could very easily make this efficient in their implementation without requiring any changes to the metamodel (e.g., by adding the necessary navigability information to data or by dynamically constructing a navigation table). Bran "Pete Rivett" 03/22/2004 01:14 AM To , , , cc Subject RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution I'm not sure a resolution is needed for the issue as worded - which is for 'modeling associations without modifying the end types'. This is possible in the existing spec. The resolution actually addresses a different issue: that of 'modeling property navigability independently of property ownership'. I don't think this can really be resolved until we have an agreed definition of navigability - since currently the spec *equates* navigability with property ownership (that is the only semantic associated with navigability). This is different from UML 1.x admittedly, but the words in UML 1.x are also different from Conrad's desired definition which is more to do with *efficiency* of navigation than *possibility* of navigation. So it seems we should address issue 6460 first. Which has yet another proposal in the issue more biased towards the OO ability to send messages (which I assume will not satisfy the information modeling users that Conrad is championing). More specifically I don't think we can adopt Conrad's resolution which is to add 'isNavigable' to Property when it has no proposed description or semantics as to what it means! Also I think the resolution deletes too much without replacing it - e.g. 2nd paragraph of description of Associations. In its stead there should be a similar description about the interaction (or not) of ownership and navigability. And there should also probably be some new constraints e.g. if a property is owned by a class then I assume it must be navigable. 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: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, March 21, 2004 7:33 PM > To: mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; > uml2-superstructure-ftf@omg.org > Subject: , cl, Issues 6242 (Association not affecting ends), > proposed resolution > > > Hi all, > > Here's a proposed resolution to Issue 6243: Association not affecting > ends. It follows the sketch previously posted, except for: > > - Making isNavigable = true for properties related by > ownedAttributes > to class. That would have hosed Pete's resolution to the recent > discussion about ends as attributes. > > - Clarifying the definition navigation, which is the topic of Infra > Issue 6460: UML 2 Issue: definition of navigability. > > If it looks OK, I can propose the same changes to infra. > Looks like the > text is not exactly the same. > > Conrad > > P.S. This is not related to the recent discussion about associations > ends being attributes. That issue hasn't been filed yet, as far as I > know. > Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Mon, 22 Mar 2004 12:25:10 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: , cl, Issues 6242 (Association not affecting ends), proposed resolution Thread-Index: AcQQMJGu5qI3ZxOGRdmDJrKLJA1nMwAAHHMk From: "Karl Frank" To: "Branislav Selic" , "Pete Rivett" Cc: , , , X-OriginalArrivalTime: 22 Mar 2004 17:25:12.0117 (UTC) FILETIME=[A1BD6650:01C41032] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i2MHNEre007870 6460 is the nub. The 6242 issue as worded is no longer the important problem here, the problem that has emerged is (as Pete says), the lack of an agreed reading of the UML 2 specification with respect to navigability, in relationship to attributes, owned properties, and non-Class-classifiers, meaning the specializations of Classifier other than Class (including Association Class and Association). This is a fundamental problem, a priority because it impacts the essential part of the metamodel. - Karl -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Mon 3/22/2004 12:07 PM To: Pete Rivett Cc: conrad.bock@nist.gov; mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution I tend to agree with Pete's line of thinking, particularly the point that the issue being debated is about efficiency rather than about a fundamental capability. Furthermore, it seems to me that a vendor could very easily make this efficient in their implementation without requiring any changes to the metamodel (e.g., by adding the necessary navigability information to data or by dynamically constructing a navigation table). Bran "Pete Rivett" 03/22/2004 01:14 AM To , , , cc Subject RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution I'm not sure a resolution is needed for the issue as worded - which is for 'modeling associations without modifying the end types'. This is possible in the existing spec. The resolution actually addresses a different issue: that of 'modeling property navigability independently of property ownership'. I don't think this can really be resolved until we have an agreed definition of navigability - since currently the spec *equates* navigability with property ownership (that is the only semantic associated with navigability). This is different from UML 1.x admittedly, but the words in UML 1.x are also different from Conrad's desired definition which is more to do with *efficiency* of navigation than *possibility* of navigation. So it seems we should address issue 6460 first. Which has yet another proposal in the issue more biased towards the OO ability to send messages (which I assume will not satisfy the information modeling users that Conrad is championing). More specifically I don't think we can adopt Conrad's resolution which is to add 'isNavigable' to Property when it has no proposed description or semantics as to what it means! Also I think the resolution deletes too much without replacing it - e.g. 2nd paragraph of description of Associations. In its stead there should be a similar description about the interaction (or not) of ownership and navigability. And there should also probably be some new constraints e.g. if a property is owned by a class then I assume it must be navigable. 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: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, March 21, 2004 7:33 PM > To: mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; > uml2-superstructure-ftf@omg.org > Subject: , cl, Issues 6242 (Association not affecting ends), > proposed resolution > > > Hi all, > > Here's a proposed resolution to Issue 6243: Association not affecting > ends. It follows the sketch previously posted, except for: > > - Making isNavigable = true for properties related by > ownedAttributes > to class. That would have hosed Pete's resolution to the recent > discussion about ends as attributes. > > - Clarifying the definition navigation, which is the topic of Infra > Issue 6460: UML 2 Issue: definition of navigability. > > If it looks OK, I can propose the same changes to infra. > Looks like the > text is not exactly the same. > > Conrad > > P.S. This is not related to the recent discussion about associations > ends being attributes. That issue hasn't been filed yet, as far as I > know. > Date: Mon, 22 Mar 2004 17:53:28 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Branislav Selic CC: Pete Rivett , conrad.bock@nist.gov, mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: , cl, Issues 6242 (Association not affecting ends), proposed resolution Bran, > seems to me that a vendor could very easily make this efficient in their implementation without requiring any changes to the metamodel (e.g., by adding the necessary navigability information to data or by dynamically constructing a navigation table). If the feeling is that navigability should be interpreted as in UML 1.x (navigability = ability to traverse), then we can stay with that interpretation in UML 2.0. But we do need a change in the meta model to indicate that associations that own their ends can be marked as navigable. Currently, it simply can't be 'stored'. I agree that we don't need to change the meta model to capture any efficiency factors. Thanks, guus Branislav Selic wrote: I tend to agree with Pete's line of thinking, particularly the point that the issue being debated is about efficiency rather than about a fundamental capability. Furthermore, it seems to me that a vendor could very easily make this efficient in their implementation without requiring any changes to the metamodel (e.g., by adding the necessary navigability information to data or by dynamically constructing a navigation table). Bran "Pete Rivett" 03/22/2004 01:14 AM To , , , cc Subject RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution I'm not sure a resolution is needed for the issue as worded - which is for 'modeling associations without modifying the end types'. This is possible in the existing spec. The resolution actually addresses a different issue: that of 'modeling property navigability independently of property ownership'. I don't think this can really be resolved until we have an agreed definition of navigability - since currently the spec *equates* navigability with property ownership (that is the only semantic associated with navigability). This is different from UML 1.x admittedly, but the words in UML 1.x are also different from Conrad's desired definition which is more to do with *efficiency* of navigation than *possibility* of navigation. So it seems we should address issue 6460 first. Which has yet another proposal in the issue more biased towards the OO ability to send messages (which I assume will not satisfy the information modeling users that Conrad is championing). More specifically I don't think we can adopt Conrad's resolution which is to add 'isNavigable' to Property when it has no proposed description or semantics as to what it means! Also I think the resolution deletes too much without replacing it - e.g. 2nd paragraph of description of Associations. In its stead there should be a similar description about the interaction (or not) of ownership and navigability. And there should also probably be some new constraints e.g. if a property is owned by a class then I assume it must be navigable. 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: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, March 21, 2004 7:33 PM > To: mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; > uml2-superstructure-ftf@omg.org > Subject: , cl, Issues 6242 (Association not affecting ends), > proposed resolution > > > Hi all, > > Here's a proposed resolution to Issue 6243: Association not affecting > ends. It follows the sketch previously posted, except for: > > - Making isNavigable = true for properties related by > ownedAttributes > to class. That would have hosed Pete's resolution to the recent > discussion about ends as attributes. > > - Clarifying the definition navigation, which is the topic of Infra > Issue 6460: UML 2 Issue: definition of navigability. > > If it looks OK, I can propose the same changes to infra. > Looks like the > text is not exactly the same. > > Conrad > > P.S. This is not related to the recent discussion about associations > ends being attributes. That issue hasn't been filed yet, as far as I > know. > -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Mar 2004 19:27:03 -0800 To: , , From: Joaquin Miller Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution I hope i am wrong, but i get the impression that we may still be using two distinct meanings of 'to navigate' in these discussions. Some folks may have in mind getting around the model, and some getting around the program. If you all will, i'd like 1) those who have in mind the program, at run time, to remain silent, and 2) anyone who has in mind getting around the model, to speak up. (In answer to those in 1) who may wish to respond: Yes, i know.) I hope to receive no responses. That will show i am wrong, and everyone has in mind only navigability (whatever that means) in the program, that is, at run time. PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 To: Joaquin Miller Cc: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 23 Mar 2004 02:35:32 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/23/2004 02:35:36, Serialize complete at 03/23/2004 02:35:36 Alas, Joaquin, in our scattered and overworked community, silence does not always imply agreement. I'm not sure that you can draw any certain conclusions from your poll. Bran Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Thu, 25 Mar 2004 08:03:30 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Pete, > I'm not sure a resolution is needed for the issue as worded - which is > for 'modeling associations without modifying the end types'. This is > possible in the existing spec. They're related. Yes, you can model associations without affecting the ends, but only if the association is not navigable from either end. By "modeling associations" I meant "modeling associations with restriction". > The resolution actually addresses a different issue: that of 'modeling > property navigability independently of property ownership'. This is a "derived requirement" as it were. Navigation is the spt where we can't currently define associations without affecting the ends (without restriction). > I don't think this can really be resolved until we have an agreed > definition of navigability - since currently the spec *equates* > navigability with property ownership (that is the only semantic > associated with navigability). > More specifically I don't think we can adopt Conrad's resolution which > is to add 'isNavigable' to Property when it has no proposed description > or semantics as to what it means! No, it says that the association is navigable from an object *if* the object owns the opposite end. This assumes navigability is already understood, and tells the modeler how they need to instantiate the metamodel to get that. I would like to deal with these separately: - a more precise definition of navigability - navigation independent of ownership. My proposal does not introduce a new definition of navigation or change the one that's (not) there. It simply restores a UML 1.x capability that was accidentally taken away. > This is different from UML 1.x admittedly, but the words in UML 1.x > are also different from Conrad's desired definition which is more to > do with *efficiency* of navigation than *possibility* of navigation. This isn't just my understanding. I would say most users when they see the navigation arrow, assume that they can query efficiently in that direction. I'm actually rather surprised that anyone didn't see it this way. > Also I think the resolution deletes too much without replacing it - e.g. > 2nd paragraph of description of Associations. In its stead there should > be a similar description about the interaction (or not) of ownership and > navigability. And there should also probably be some new constraints > e.g. if a property is owned by a class then I assume it must be > navigable. We can replace the paragraph with one that says isNavigable = true means the association is navigable from the opposite end. Conrad Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Thu, 25 Mar 2004 08:03:47 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Bran, > I tend to agree with Pete's line of thinking, particularly the > point that the issue being debated is about efficiency rather > than about a fundamental capability. It's not about runtime efficiency, this is where 6243 and the definition navigation are getting confused. In some application the classes being associated *should not change* in the user's model when they are associated. This is true in database and logic-based modeling, and was supported in UML 1.x The issue of navigation only comes up as a derived requirement of not affecting the end classes when defining an association. And even then, it only affects the way navigatio is represented in the metamodel, not the definition of navigation itself. Conrad Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Thu, 25 Mar 2004 08:04:12 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Associators, There are a number of issues going around under the topic "navigation" that are independent, but are close enough together that they are geting confused. I've listed them below. General points: None of them requires the resolution of the other two. All of them are not possible under the current metamodel, as explained in the second section below. #1 is a modeling issue, #2 and #3 are runtime issues. Conrad The issues: 1) Super 6243: Association not affecting ends This asks that defining an association (of whatever kind and navigability) does not affect the classes. 2) Infra 6460: UML 2 Issue: definition of navigability Asks for a definition of navigability 3) Unfiled: accessing association ends from association class via attribues. Asks to access the ends of an instance of an association via its attributes. Why the metamodel doesn't resolve them: 1) Super 6243: Association not affecting ends An association that is navigable from either end requires the source end class of the navigation to own the property. See the top section of Property, 7.11.4, and the fact that the metamodel has no explicit mention of navigation. Infra 6460: UML 2 Issue: definition of navigability The term "navigation" is used without definition in the spec, as far as I can tell. Unfiled: accessing association ends from association class via attribues. If InstanceSpecification is our guide (which may be incorrect), only features of classifiers that are structural and owned by the classifier may have slots. See the metamodel for InstanceSpecification and Constraint 2 of InstanceSpecification. Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), yet another updated proposed resolution Date: Thu, 25 Mar 2004 08:05:55 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Pete, et al, > Also I think the resolution deletes too much without replacing it - e.g. > 2nd paragraph of description of Associations. See updated proposal attached. > In its stead there should be a similar description about the > interaction (or not) of ownership and navigability. And there should > also probably be some new constraints e.g. if a property is owned by > a class then I assume it must be navigable. This was in the original sketch, but it would conflict with associations that own nonnavigable ends. Presumably users and tool vendors can figure out that a non-navigable attribute (an ordinary property, not an association end), aren't very useful. Conrad P.S. Also added the constraint on properties we talked about yesterday, see end of page 2. issueresolution-62431.doc OMG Issue No: 6243 Title: Association not affecting ends Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Restore UML 1.x capability of modeling associations without modifying the end types. This is needed for database modeling, for profiles to be used with fixed-schema repositories, and is the differentiator of UML over OWL, etc. Discussion: Separate association end ownership from navigation by introducing an isNavigable attribute on properties, as indicated below. In Figure 30: Add attribute to Property: isNavigable : Boolean = true In Association class, section 7.11.2: In Description section: Replace second paragraph with: .An end property of an association with isNavigable = true indicates that the association is navigable from the opposite ends, otherwise the association is not navigable form the opposite ends.. In Associations section: ownedEnd entry, delete "non-navigable". In Semantics section: Delete the sentence above "Note". In Notation section: Replace paragraph above Figure 34 with: "Figure 34 shows that the attribute notation can be used for a navigable end owned by an end class, because a navigable end owned by an end class is also an attribute. Normally in this case the notation would be used in conjunction with the line-arrow notation to make it perfectly clear that the attribute is also an association end." Change caption of Figure 34 to "Example of attribute notation for navigable end owned by an end class." In Property class, section 7.11.4: Replace second two paragraphs with: .A property is related to a class by ownedAttribute represents an attribute, and might also represent an association end. It relates an instance of the class to a value or set of values of the type of the attribute.. .A property related to an association by memberEnd or ownedEnd represents an end of the association. The type of the property is the type of the end of the association.. In Constraints section: Replace rule 4 with: [4] A navigable property can only be redefined or subsetted by a navigable property. (subsettedProperty->exists(sp | sp.isNavigable implies isNavigable) and (redefinedProperty->exists(rp | rp.isNavigable->implies isNavigable) Replace rule 6 with: [6] Only a navigable property can be marked as readOnly. isReadOnly implies isNavigable Add new rule at end: A property that is an ownedAttribute of a class and that is not an ownedEnd of an association must be navigable. if owningAssociation->isEmpty() and class->notEmpty() then isNavigable = true In Semantics section: First paragraph, replace second sentence with: .When related to an association via ownedEnd or memberEnd, it represents an end of the association.. Ninth paragraph, after "If a navigable property", delete "(attribute)". Disposition: Resolved From: Edwin Seidewitz To: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Thu, 25 Mar 2004 16:06:14 -0500 X-Mailer: Internet Mail Service (5.5.2655.55) OK, I kind of hate to add yet another voice to this thread, but I thought I would throw a comment in, because I remember having an extended discussion with Jim R. on exactly the topic of navigability during the UML 1.2 RTF. While I cannot claim for sure that my recollection of this discussion is exactly correct, or that my current position is exactly what I had then (though I definitely remember having the discussion!), I believe the current UML 2.0 metamodel reflects the result of that discussion. Basically, the result of that discussion was the following concept of "navigability". Suppose a binary association R is navigable from class A to class B. Then, knowing _only_ about properties of class A and given _only_ and instance a of A, it is possible to determine the instance b of B associated with a. On the other hand, given _both_ and instance r of R _and_ and instance a of A, it should _always_ be possible to determine the instance b of B associated with a by r. This conception of "navigability" never really made it into UML 1.x, but is definitely consistent with the UML 2.0 metamodel approach of making the navigable end of R a property of A. Indeed, it _has_ to be a property of A, since you need to be able to do the navigation knowing _only_ about A to start with. In this sense, the navigable end becomes the "moral equivalent" of an attribute of A (whether it really is in the metamodel or not) -- which is how a lot of people (especially OO people) already look at it. On the other hand, people with a relational background tend to start assuming knowledge of the association R, and then want to make queries based on a value at one or the other end. (Or, for an n-ary association, make queries based on values at m ends to get values at the other n-m ends.) This leads to comments like "you can always navigate in either direction". But, with the above conception of "navigation", such queries are _not_ considered navigations. If the metamodel changed along the lines proposed by Conrad, then, for those association ends owned by a class, you still have "navigability" in a sense similar to that conceived above. However, you would _also_ be able to say an association is navigable when the end is _not_ owned by the class. In this case, I have not yet quite seen a clear conception of what "navigability" means, since such a traversal would then seem to require a relational-type query -- which would always be possible. To turn the question around: What does it mean, in Conrad's scheme, if an association end is _not_ marked as navigable? Since a traversal across the association is always conceptually possible given an association instance, and since navigability as I conceived it above is only possible if navigability implies ownership, then the only thing I can think of is that, in Conrad's scheme, non-navigability means "you can, indeed, do the traversal, but you don't have to implement it efficiently". But I thought Conrad disclaimed "navigability = efficiency" somewhere along the line of the discussion. So, I would ask Conrad explicitly: How would you define "navigability" as a distinction within a relational-type query of an association other than efficiency? Or how would you define "navigability" to allow OO-type navigation from one class to another, without requiring any property to be inserted into the first class? Conrad has probably already tried to explain this a few times in his various messages, but I still can't quite get it. -- Ed From: "Thomas Weigert" To: "Edwin Seidewitz" , , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Thu, 25 Mar 2004 17:33:47 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal I think the problem with this discussion is a confusion between meta levels. When we talk about navigability, we are talking about traversing the repository. What users think about when they see the arrow, they think in terms of the user model, not the repository. In particular, most users interpret the arrow to mean that there is a pointer to the other object, or an embedding, depending on what the association is. From a user's point of view, the repository is completely irrelevant. So while this interpretation, that you can always traverse to the other hand, whether navigable or not, makes sense for the repository, it certainly does not hold for the user models. Not that this comment helps much here, as this topic is still muddled.... Th. > -----Original Message----- > From: Edwin Seidewitz [mailto:eseidewitz@intelidata.com] > Sent: Thursday, March 25, 2004 3:06 PM > To: mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; > uml2-superstructure-ftf@omg.org > Subject: RE: , cl, Issues 6242 (Association not affecting ends), > proposed resolution > > > OK, I kind of hate to add yet another voice to this thread, but I > thought I > would throw a comment in, because I remember having an extended discussion > with Jim R. on exactly the topic of navigability during the UML 1.2 RTF. > While I cannot claim for sure that my recollection of this discussion is > exactly correct, or that my current position is exactly what I had then > (though I definitely remember having the discussion!), I believe > the current > UML 2.0 metamodel reflects the result of that discussion. > > Basically, the result of that discussion was the following concept of > "navigability". Suppose a binary association R is navigable from > class A to > class B. Then, knowing _only_ about properties of class A and given _only_ > and instance a of A, it is possible to determine the instance b of B > associated with a. On the other hand, given _both_ and instance r > of R _and_ > and instance a of A, it should _always_ be possible to determine the > instance b of B associated with a by r. > > This conception of "navigability" never really made it into UML > 1.x, but is > definitely consistent with the UML 2.0 metamodel approach of making the > navigable end of R a property of A. Indeed, it _has_ to be a > property of A, > since you need to be able to do the navigation knowing _only_ about A to > start with. In this sense, the navigable end becomes the "moral > equivalent" > of an attribute of A (whether it really is in the metamodel or > not) -- which > is how a lot of people (especially OO people) already look at it. > > On the other hand, people with a relational background tend to start > assuming knowledge of the association R, and then want to make > queries based > on a value at one or the other end. (Or, for an n-ary association, make > queries based on values at m ends to get values at the other n-m > ends.) This > leads to comments like "you can always navigate in either direction". But, > with the above conception of "navigation", such queries are _not_ > considered > navigations. > > If the metamodel changed along the lines proposed by Conrad, > then, for those > association ends owned by a class, you still have "navigability" > in a sense > similar to that conceived above. However, you would _also_ be > able to say an > association is navigable when the end is _not_ owned by the class. In this > case, I have not yet quite seen a clear conception of what "navigability" > means, since such a traversal would then seem to require a relational-type > query -- which would always be possible. > > To turn the question around: What does it mean, in Conrad's scheme, if an > association end is _not_ marked as navigable? Since a traversal across the > association is always conceptually possible given an association instance, > and since navigability as I conceived it above is only possible if > navigability implies ownership, then the only thing I can think > of is that, > in Conrad's scheme, non-navigability means "you can, indeed, do the > traversal, but you don't have to implement it efficiently". > > But I thought Conrad disclaimed "navigability = efficiency" > somewhere along > the line of the discussion. > > So, I would ask Conrad explicitly: How would you define > "navigability" as a > distinction within a relational-type query of an association other than > efficiency? Or how would you define "navigability" to allow OO-type > navigation from one class to another, without requiring any property to be > inserted into the first class? > > Conrad has probably already tried to explain this a few times in > his various > messages, but I still can't quite get it. > > -- Ed > From: Edwin Seidewitz To: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Thu, 25 Mar 2004 18:46:46 -0500 X-Mailer: Internet Mail Service (5.5.2655.55) Well, my comment was meant to refer to user models. The concept of "navigability", as I defined it, is, in essence, the "association as pointer" interpretation. To have a pointer in one object to another object, the pointer has to be a property of the class of the first object -- as defined in the user model. People with an OOP background are particularly comfortable with this. But not all users actually think this way. And UML 1.x associations were specifically NOT this way -- instead, they came from the object-relational association modeling school (a la Blaha and Rumbaugh). In UML 1.x, defining an association NEVER added a property to any of the associated classes. That was why you had to have a special flag on and association end for "navigability" and then have rules that made the navigable end act like a "pseudo-attribute" of the class you wanted to navigate from. If, of course, your concept of UML 1.x "navigability" was from the OO-pointer perspective. But, I think, Conrad is indicative of a lot of a lot of people who came at UML 1.x associations from a different, data-modeling perspective. And, to them, the UML 2.0 change just does seem right. -- Ed > -----Original Message----- > From: Thomas Weigert [mailto:thomas.weigert@motorola.com] > Sent: Thursday, March 25, 2004 6:34 PM > To: Edwin Seidewitz; mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; > uml2-superstructure-ftf@omg.org > Subject: RE: , cl, Issues 6242 (Association not affecting ends), > proposed resolution > > > I think the problem with this discussion is a confusion > between meta levels. > When we talk about navigability, we are talking about traversing the > repository. What users think about when they see the arrow, > they think in > terms of the user model, not the repository. In particular, most users > interpret the arrow to mean that there is a pointer to the > other object, or > an embedding, depending on what the association is. From a > user's point of > view, the repository is completely irrelevant. So while this > interpretation, > that you can always traverse to the other hand, whether > navigable or not, > makes sense for the repository, it certainly does not hold > for the user > models. > > Not that this comment helps much here, as this topic is still > muddled.... > > Th. > > > -----Original Message----- > > From: Edwin Seidewitz [mailto:eseidewitz@intelidata.com] > > Sent: Thursday, March 25, 2004 3:06 PM > > To: mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; > > uml2-superstructure-ftf@omg.org > > Subject: RE: , cl, Issues 6242 (Association not affecting ends), > > proposed resolution > > > > > > OK, I kind of hate to add yet another voice to this thread, but I > > thought I > > would throw a comment in, because I remember having an > extended discussion > > with Jim R. on exactly the topic of navigability during the > UML 1.2 RTF. > > While I cannot claim for sure that my recollection of this > discussion is > > exactly correct, or that my current position is exactly > what I had then > > (though I definitely remember having the discussion!), I believe > > the current > > UML 2.0 metamodel reflects the result of that discussion. > > > > Basically, the result of that discussion was the following > concept of > > "navigability". Suppose a binary association R is navigable from > > class A to > > class B. Then, knowing _only_ about properties of class A > and given _only_ > > and instance a of A, it is possible to determine the instance b of B > > associated with a. On the other hand, given _both_ and instance r > > of R _and_ > > and instance a of A, it should _always_ be possible to determine the > > instance b of B associated with a by r. > > > > This conception of "navigability" never really made it into UML > > 1.x, but is > > definitely consistent with the UML 2.0 metamodel approach > of making the > > navigable end of R a property of A. Indeed, it _has_ to be a > > property of A, > > since you need to be able to do the navigation knowing > _only_ about A to > > start with. In this sense, the navigable end becomes the "moral > > equivalent" > > of an attribute of A (whether it really is in the metamodel or > > not) -- which > > is how a lot of people (especially OO people) already look at it. > > > > On the other hand, people with a relational background tend to start > > assuming knowledge of the association R, and then want to make > > queries based > > on a value at one or the other end. (Or, for an n-ary > association, make > > queries based on values at m ends to get values at the other n-m > > ends.) This > > leads to comments like "you can always navigate in either > direction". But, > > with the above conception of "navigation", such queries are _not_ > > considered > > navigations. > > > > If the metamodel changed along the lines proposed by Conrad, > > then, for those > > association ends owned by a class, you still have "navigability" > > in a sense > > similar to that conceived above. However, you would _also_ be > > able to say an > > association is navigable when the end is _not_ owned by the > class. In this > > case, I have not yet quite seen a clear conception of what > "navigability" > > means, since such a traversal would then seem to require a > relational-type > > query -- which would always be possible. > > > > To turn the question around: What does it mean, in Conrad's > scheme, if an > > association end is _not_ marked as navigable? Since a > traversal across the > > association is always conceptually possible given an > association instance, > > and since navigability as I conceived it above is only possible if > > navigability implies ownership, then the only thing I can think > > of is that, > > in Conrad's scheme, non-navigability means "you can, indeed, do the > > traversal, but you don't have to implement it efficiently". > > > > But I thought Conrad disclaimed "navigability = efficiency" > > somewhere along > > the line of the discussion. > > > > So, I would ask Conrad explicitly: How would you define > > "navigability" as a > > distinction within a relational-type query of an > association other than > > efficiency? Or how would you define "navigability" to allow OO-type > > navigation from one class to another, without requiring any > property to be > > inserted into the first class? > > > > Conrad has probably already tried to explain this a few times in > > his various > > messages, but I still can't quite get it. > > > > -- Ed > > > > Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Fri, 26 Mar 2004 16:39:23 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Hi Jim, > > They're related. Yes, you can model associations without affecting the > > ends, but only if the association is not navigable from either end. By > > "modeling associations" I meant "modeling associations with > > restriction". > > If you want to model an association between two classes, but not > effect either class, then by definition, neither of these > classes can know anything about the association its ends, or its > meaning. So some other element has to be responsible for this. > One possibility would be to introduce another mediator class > that does know the semantics of the association, and have two > one-way associations pointing at the participating classes. > Another would be to have an association (a Classifier or by > using an AssociationClass) that owns both its ends. As we discussed in telecon, the above is an implementation possible for the specification of navigation between the classes. This is how UML 1.x worked. > > > This is different from UML 1.x admittedly, but the words in UML 1.x > > > are also different from Conrad's desired definition which is more to > > > do with *efficiency* of navigation than *possibility* of navigation. > > > > This isn't just my understanding. I would say most users when they see > > the navigation arrow, assume that they can query efficiently in that > > direction. I'm actually rather surprised that anyone didn't > > see it this way. > When I see a navigation arrow, I just think the property at the > end is visible and accessible in from the class, that I can > refer to this property, i.e., "navigate to it" in an activity or > OCL expression. This is more about the wording. UML happens to use the terms navigation and visibility for different things. > How that's implemented in a runtime is completely separate concern. I > would expect the runtime to support the semantics, and that different > implementations would have different qualities of service that may or > may not be acceptable in any given circumstance. Right, and the semantics would be traversal to the target object given the source. This is separate from ownership. Conrad Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Fri, 26 Mar 2004 16:54:06 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Ed, > OK, I kind of hate to add yet another voice to this thread, but I > thought I would throw a comment in, because I remember having an > extended discussion with Jim R. on exactly the topic of navigability > during the UML 1.2 RTF. While I cannot claim for sure that my > recollection of this discussion is exactly correct, or that my > current position is exactly what I had then (though I definitely > remember having the discussion!), I believe the current UML 2.0 > metamodel reflects the result of that discussion. We should let Jim R speak for himself. I heard something quite different from him during the RTF than you describe below. > Basically, the result of that discussion was the following concept of > "navigability". Suppose a binary association R is navigable from > class A to class B. Then, knowing _only_ about properties of class A > and given _only_ and instance a of A, it is possible to determine the > instance b of B associated with a. On the other hand, given _both_ > and instance r of R _and_ and instance a of A, it should _always_ be > possible to determine the instance b of B associated with a by r. This doesn't apply to database applications that use intersection tables, as you explain in your message. We need to support the relational viewpoint. One of the purpose of 2.0 was to support a wider range of languages, and databases, as in CWM for example, was an important motivator. > If the metamodel changed along the lines proposed by Conrad, then, > for those association ends owned by a class, you still have > "navigability" in a sense similar to that conceived above. However, > you would _also_ be able to say an association is navigable when the > end is _not_ owned by the class. In this case, I have not yet quite > seen a clear conception of what "navigability" means, since such a > traversal would then seem to require a relational-type query -- which > would always be possible. Relational queries are only possible of the implementation supports it. In any case, navigation doesn't say that the implementation is relational or not, just which traversals will be supported in the generated system. > To turn the question around: What does it mean, in Conrad's scheme, > if an association end is _not_ marked as navigable? Since a traversal > across the association is always conceptually possible given an > association instance, and since navigability as I conceived it above > is only possible if navigability implies ownership, then the only > thing I can think of is that, in Conrad's scheme, non-navigability > means "you can, indeed, do the traversal, but you don't have to > implement it efficiently". > So, I would ask Conrad explicitly: How would you define > "navigability" as a distinction within a relational-type query of an > association other than efficiency? My personal viewpoint is that navigation = efficienit access, but others didn't care for introducing the notion of efficiency in UML (even though it is there implicitly everywhere), preferring the term "traversal". In any case, the definition of navigation is not the issue, it's separating the notion of navigation from ownership. > Or how would you define "navigability" to allow OO-type navigation > from one class to another, without requiring any property to be > inserted into the first class? The OO viewpoint is supported also. Once ownership and navigation are separate, you can do OO or relational. Conrad Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Fri, 26 Mar 2004 17:03:54 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Hi Thomas, > I think the problem with this discussion is a confusion between meta > levels. When we talk about navigability, we are talking about > traversing the repository. What users think about when they see the > arrow, they think in terms of the user model, not the repository. In > particular, most users interpret the arrow to mean that there is a > pointer to the other object, or an embedding, depending on what the > association is. From a user's point of view, the repository is > completely irrelevant. So while this interpretation, that you can > always traverse to the other hand, whether navigable or not, makes > sense for the repository, it certainly does not hold for the user > models. This came up at the telecon, and you're right there is level confusion. Navigation in the user model refers to a runtime capability. For example: owner Pet ----------> Person Means that is is possible to traverse from a runtime instance of Pet to a runtime instance of Person. Because navigation is a runtime concept, and the ownership of properties by classes is a repository concept, they can be addressed separately. We can define navigation with whatever runtime semantics we want and still separate navigation from classes owning properties (Issue 6243: Association not affecting ends). Conrad Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Fri, 26 Mar 2004 17:07:11 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Ed, > If, of course, your concept of UML 1.x "navigability" was from the > OO-pointer perspective. But, I think, Conrad is indicative of a lot > of a lot of people who came at UML 1.x associations from a different, > data-modeling perspective. And, to them, the UML 2.0 change just does > seem right. And the great thing about the UML 2 model it can unify the OO and relational viewpoints, with the propsed change. In fact, the U2P agreed on it, but the workgroup lead failed to implement. Conrad To: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Mon, 29 Mar 2004 11:51:48 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 03/29/2004 11:51:49 OK, since my name has come up I thought I should give a full analysis of the issue. There are several basic concepts that have all gotten mixed together under the name 'navigability'. Also in UML2 the concept of semantics has gotten mixed up (inappropriately) with the question of how to actually program a metamodel repository, so that implementation choices seem to have seeped into the metamodel contents. In the attachment I list the various meanings of navigability that I can think of and where they fit into the picture. - Jim Rumbaugh Edwin Seidewitz 03/25/2004 01:06 PM To mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org cc Subject RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution OK, I kind of hate to add yet another voice to this thread, but I thought I would throw a comment in, because I remember having an extended discussion with Jim R. on exactly the topic of navigability during the UML 1.2 RTF. While I cannot claim for sure that my recollection of this discussion is exactly correct, or that my current position is exactly what I had then (though I definitely remember having the discussion!), I believe the current UML 2.0 metamodel reflects the result of that discussion. Basically, the result of that discussion was the following concept of "navigability". Suppose a binary association R is navigable from class A to class B. Then, knowing _only_ about properties of class A and given _only_ an instance a of A, it is possible to determine the instance b of B associated with a. On the other hand, given _both_ an instance r of R _and_ and instance a of A, it should _always_ be possible to determine the instance b of B associated with a by r. [jr: This is not my doing. What does it mean to "know" "only" a single instance? The association R is there. If we pretend that it is not there, then what does it mean to navigate? This line of thinking makes too many (dubious) assumptions about the implementation of the program.] This conception of "navigability" never really made it into UML 1.x, but is definitely consistent with the UML 2.0 metamodel approach of making the navigable end of R a property of A. Indeed, it _has_ to be a property of A, since you need to be able to do the navigation knowing _only_ about A to start with. In this sense, the navigable end becomes the "moral equivalent" of an attribute of A (whether it really is in the metamodel or not) -- which is how a lot of people (especially OO people) already look at it. [jr: Again, this is mixing up programming language implementation issues and modeling issues. That's not a good way to define a modeling property. If anything, you derive constraints on the implementation from the modeling properties, not the other way around.] On the other hand, people with a relational background tend to start assuming knowledge of the association R, and then want to make queries based on a value at one or the other end. (Or, for an n-ary association, make queries based on values at m ends to get values at the other n-m ends.) This leads to comments like "you can always navigate in either direction". But, with the above conception of "navigation", such queries are _not_ considered navigations. [jr: You can do all kinds of things at run time. We need to define the modeling properties in a more abstract way.] If the metamodel changed along the lines proposed by Conrad, then, for those association ends owned by a class, you still have "navigability" in a sense similar to that conceived above. However, you would _also_ be able to say an association is navigable when the end is _not_ owned by the class. In this case, I have not yet quite seen a clear conception of what "navigability" means, since such a traversal would then seem to require a relational-type query -- which would always be possible. [jr: The definition of run-time accessibily you gave above and the question of who owns the model element in the metamodel are completely unrelated. The program implementation does not have to match the metamodel implementation.] To turn the question around: What does it mean, in Conrad's scheme, if an association end is _not_ marked as navigable? Since a traversal across the association is always conceptually possible given an association instance, and since navigability as I conceived it above is only possible if navigability implies ownership, then the only thing I can think of is that, in Conrad's scheme, non-navigability means "you can, indeed, do the traversal, but you don't have to implement it efficiently". But I thought Conrad disclaimed "navigability = efficiency" somewhere along the line of the discussion. So, I would ask Conrad explicitly: How would you define "navigability" as a distinction within a relational-type query of an association other than efficiency? Or how would you define "navigability" to allow OO-type navigation from one class to another, without requiring any property to be inserted into the first class? Conrad has probably already tried to explain this a few times in his various messages, but I still can't quite get it. -- Ed "Conrad Bock" 03/26/2004 01:54 PM Please respond to conrad.bock To , , cc Subject RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Ed, > OK, I kind of hate to add yet another voice to this thread, but I > thought I would throw a comment in, because I remember having an > extended discussion with Jim R. on exactly the topic of navigability > during the UML 1.2 RTF. While I cannot claim for sure that my > recollection of this discussion is exactly correct, or that my > current position is exactly what I had then (though I definitely > remember having the discussion!), I believe the current UML 2.0 > metamodel reflects the result of that discussion. We should let Jim R speak for himself. I heard something quite different from him during the RTF than you describe below. Conrad Different Meanings of the Concept of Navigability1.doc To: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Tue, 30 Mar 2004 10:19:29 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 03/30/2004 10:19:30 [I seem to be having problems with the mailing list server so apologies if this comes more than once] OK, since my name has come up I thought I should give an analysis of the issue. There are several basic concepts that have all gotten mixed together under the name 'navigability'. Also in UML2 the concept of semantics has gotten mixed up (inappropriately) with the question of how to actually program a metamodel repository, so that implementation choices seem to have seeped into the metamodel contents. In the attachment I list the various meanings of navigability that I can think of and where they fit into the picture. - Jim Rumbaugh Edwin Seidewitz 03/25/2004 01:06 PM To mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org cc Subject RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution OK, I kind of hate to add yet another voice to this thread, but I thought I would throw a comment in, because I remember having an extended discussion with Jim R. on exactly the topic of navigability during the UML 1.2 RTF. While I cannot claim for sure that my recollection of this discussion is exactly correct, or that my current position is exactly what I had then (though I definitely remember having the discussion!), I believe the current UML 2.0 metamodel reflects the result of that discussion. Basically, the result of that discussion was the following concept of "navigability". Suppose a binary association R is navigable from class A to class B. Then, knowing _only_ about properties of class A and given _only_ an instance a of A, it is possible to determine the instance b of B associated with a. On the other hand, given _both_ an instance r of R _and_ and instance a of A, it should _always_ be possible to determine the instance b of B associated with a by r. [jr: This is not my doing. What does it mean to "know" "only" a single instance? The association R is there. If we pretend that it is not there, then what does it mean to navigate? This line of thinking makes too many (dubious) assumptions about the implementation of the program.] This conception of "navigability" never really made it into UML 1.x, but is definitely consistent with the UML 2.0 metamodel approach of making the navigable end of R a property of A. Indeed, it _has_ to be a property of A, since you need to be able to do the navigation knowing _only_ about A to start with. In this sense, the navigable end becomes the "moral equivalent" of an attribute of A (whether it really is in the metamodel or not) -- which is how a lot of people (especially OO people) already look at it. [jr: Again, this is mixing up programming language implementation issues and modeling issues. That's not a good way to define a modeling property. If anything, you derive constraints on the implementation from the modeling properties, not the other way around.] On the other hand, people with a relational background tend to start assuming knowledge of the association R, and then want to make queries based on a value at one or the other end. (Or, for an n-ary association, make queries based on values at m ends to get values at the other n-m ends.) This leads to comments like "you can always navigate in either direction". But, with the above conception of "navigation", such queries are _not_ considered navigations. [jr: You can do all kinds of things at run time. We need to define the modeling properties in a more abstract way.] If the metamodel changed along the lines proposed by Conrad, then, for those association ends owned by a class, you still have "navigability" in a sense similar to that conceived above. However, you would _also_ be able to say an association is navigable when the end is _not_ owned by the class. In this case, I have not yet quite seen a clear conception of what "navigability" means, since such a traversal would then seem to require a relational-type query -- which would always be possible. [jr: The definition of run-time accessibily you gave above and the question of who owns the model element in the metamodel are completely unrelated. The program implementation does not have to match the metamodel implementation.] To turn the question around: What does it mean, in Conrad's scheme, if an association end is _not_ marked as navigable? Since a traversal across the association is always conceptually possible given an association instance, and since navigability as I conceived it above is only possible if navigability implies ownership, then the only thing I can think of is that, in Conrad's scheme, non-navigability means "you can, indeed, do the traversal, but you don't have to implement it efficiently". But I thought Conrad disclaimed "navigability = efficiency" somewhere along the line of the discussion. So, I would ask Conrad explicitly: How would you define "navigability" as a distinction within a relational-type query of an association other than efficiency? Or how would you define "navigability" to allow OO-type navigation from one class to another, without requiring any property to be inserted into the first class? Conrad has probably already tried to explain this a few times in his various messages, but I still can't quite get it. -- Ed "Conrad Bock" 03/26/2004 01:54 PM Please respond to conrad.bock To , , cc Subject RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Ed, > OK, I kind of hate to add yet another voice to this thread, but I > thought I would throw a comment in, because I remember having an > extended discussion with Jim R. on exactly the topic of navigability > during the UML 1.2 RTF. While I cannot claim for sure that my > recollection of this discussion is exactly correct, or that my > current position is exactly what I had then (though I definitely > remember having the discussion!), I believe the current UML 2.0 > metamodel reflects the result of that discussion. We should let Jim R speak for himself. I heard something quite different from him during the RTF than you describe below. Conrad Different Meanings of the Concept of Navigability.doc Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Mar 2004 11:17:29 -0800 To: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Thanks, Jim, for the sterling analysis. Regarding one thing you wrote: .............................................................................. Rumbaugh wrote: "There was a question whether it was an attribute of the association, but 'attribute' is not a type, it is a rolename of Class, so that formulation of the question and Conrad's answer appears misleading even if technically correct." If the formulation of the question appears misleading, we need to get that off the table. Of course, 'attribute' is a rolename of Class. (This is in keeping with the UML 2 style that admits that some central (traditional, customary, old-fashioned, UML 1, ...) concepts may appear in the specification of UML 2 as roles, and not at classes.) Many users, in many common uses of UML, will expect two things: 1. If an item is an attribute of a class in a model, it will appear in conforming program code as a {member, field, attribute, ...}, in database schemata as a column (field, domain, ...}, and so on... (By 'will' i refer to the user's expectations. I mean users will use the specification of an attribute in a class to call for a field {whatever that is called} in an implementation.) 2. If an item is not an attribute of a class in a model, it will n o t appear in conforming program code as a {member, field, attribute, ...}, in database schemata as a column (field, domain, ...}, and so on... So, it is a side issue that the UML 2 specification says, as it does, "When a property is owned by a class it represents an attribute" and also says, as Conrad correctly points out, that it ain't necessarily so. The question is: If an association end is marked 'not navigable' from the associated class, and it is an end of an association class, is it an attribute of that association class? Which is a short, and so possibly apparently misleading way to ask: If an association end is marked 'not navigable' from the associated class, and it is an end of an association class, is it an attribute of that association class, that is, to be precise, may users expect that the other associated class is in the role, attribute, of that association class, so that may expect that (in many cases of the use of a UML 2 specification) a field will be found in a conforming implementation, just as would be found if that same end were marked 'navigable' from the associated class? (Of course, in the marked-navigable case, the field will be found on the associated class, instead of on the association class.) I feel strongly that we will be wrong if we answer: "UML 2 requires that specification of an attribute in a UML model can not be the technique used to specify that there will be a field {whatever it is called} in an implementation conforming to that model. The user must use some other UML 2 capability to specify that." I did not get any answer to my question: What is the practical advantage of insisting that the ends in question are not attributes of the association class? I take it there is no practical advantage. So i will submit an issue to correct the contradiction in the UML 2 spec in favor of the text: When a property is owned by a class it represents an attribute. Cordially, Joaquin To: Joaquin Miller Cc: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Tue, 30 Mar 2004 12:32:45 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 03/30/2004 13:32:46, Serialize complete at 03/30/2004 13:32:47, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 03/30/2004 13:32:47 Joaquin, See in my embedded comments (>>) a pessimistic view on the whole issue of UML semantics. - Jim Rumbaugh Joaquin Miller 03/30/2004 11:17 AM Please respond to Joaquin Miller To mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org cc Subject RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Thanks, Jim, for the sterling analysis. Regarding one thing you wrote: .............................................................................. Rumbaugh wrote: "There was a question whether it was an attribute of the association, but 'attribute' is not a type, it is a rolename of Class, so that formulation of the question and Conrad's answer appears misleading even if technically correct." If the formulation of the question appears misleading, we need to get that off the table. Of course, 'attribute' is a rolename of Class. (This is in keeping with the UML 2 style that admits that some central (traditional, customary, old-fashioned, UML 1, ...) concepts may appear in the specification of UML 2 as roles, and not at classes.) Many users, in many common uses of UML, will expect two things: 1. If an item is an attribute of a class in a model, it will appear in conforming program code as a {member, field, attribute, ...}, in database schemata as a column (field, domain, ...}, and so on... (By 'will' i refer to the user's expectations. I mean users will use the specification of an attribute in a class to call for a field {whatever that is called} in an implementation.) >> And this is the crux of the matter. Different people have different expectations, and the most serious flaw of UML (and particularly the failed attempt to increase precision in UML2) is the failure to clearly state the assumptions and expectations that underlie the UML metamodel. The problem is that most of the authors of UML had a lot of assumptions (different from person to person) without realizing it. >> So in UML2 people chose (unwisely, in my opinion) to try to eliminate the difference between attribute and association end by unifying them in the metamodel. Then they furthermore unified the concept of navigability, thereby mushing everything together. The argument is that, as a matter of deep semantics, association ends and attributes are the same. Well, yes they are. But that argument overlooked the fact that users choose to use the surface syntax to make distinctions useful to them, such as the expectations you cite. Now it is not the job of UML to enforce these expectations, and it does not do so. But by squashing together attribute and association end, UML2 removed the ability of users to make this distinction. All the fuss about whether something is an attribute is (in my belief) based on the hidden expectation that attributes and association ends behave differently, if not in fundamental semantics at least in connotations. But this is precisely the syntactic distinction that has been lost by the excessive unification between attribute/association and then between navigability/attributes. >> So your statement of expectations may be correct, but the changes in UML2 undermine it and you can't rely on the expectations any more. 2. If an item is not an attribute of a class in a model, it will n o t appear in conforming program code as a {member, field, attribute, ...}, in database schemata as a column (field, domain, ...}, and so on... So, it is a side issue that the UML 2 specification says, as it does, "When a property is owned by a class it represents an attribute" and also says, as Conrad correctly points out, that it ain't necessarily so. >> And the reality is, it doesn't matter any more, because that was the implication of the unification described above. The problem is that people keep trying to say what something "means", with the definition based on a lot of unstated (and no longer true) assumptions and expectations. The question is: If an association end is marked 'not navigable' from the associated class, and it is an end of an association class, is it an attribute of that association class? >> My reading of the spec was that, if an association end is not navigable on its associated class, then it is an attribute of the association--and it did not have to be an association class. It appears some people read it differently. If that is the case, there is no point to consult the author of the chapter. If several people well versed in UML can read it and get different answers, the spec is plain ambiguous. Which it is, if you look at this case and MOST of the others in UML. The problem is that UML rarely gives usage notes to explain which of the legal instance models compatible with the metamodel is the one that is to be used in a given modeling situation. Which is a short, and so possibly apparently misleading way to ask: If an association end is marked 'not navigable' from the associated class, and it is an end of an association class, is it an attribute of that association class, that is, to be precise, may users expect that the other associated class is in the role, attribute, of that association class, so that may expect that (in many cases of the use of a UML 2 specification) a field will be found in a conforming implementation, just as would be found if that same end were marked 'navigable' from the associated class? (Of course, in the marked-navigable case, the field will be found on the associated class, instead of on the association class.) >> If the goal of attributes is to supply connotations that aren't exactly part of the semantics but are expectations the user can use in implementation (see previous comments), then the current situation in UML2 is overconstrained: Separate being an attribute from navigability from where it is stored in the model repository from how it will be implemented in Java. The real thing that is overloaded is people's expectations about what "attribute" (and "navigablity", and "ownership", and "namespace", etc. ad infinitum) implies. I feel strongly that we will be wrong if we answer: "UML 2 requires that specification of an attribute in a UML model can not be the technique used to specify that there will be a field {whatever it is called} in an implementation conforming to that model. The user must use some other UML 2 capability to specify that." >> You may feel strongly, but now you are bringing your own expectations to bear and saying that everybody has to accept them. That's the problem with most UML debates. Usage and process issues get transmuted into ontological battles. I did not get any answer to my question: What is the practical advantage of insisting that the ends in question are not attributes of the association class? I take it there is no practical advantage. So i will submit an issue to correct the contradiction in the UML 2 spec in favor of the text: When a property is owned by a class it represents an attribute. >> As I thing I have made clear, I believe the real problem is much deeper and more intractable: People thought they were defining "semantics" in UML, but in many cases they were really embedding hidden assumptions and expectations about how UML constructs will be used, rather than what they mean. When put through the mill of overzealous "unification" of concepts and subjected to excessive overgeneralization, we end up with a set of concepts that is not coherent and that contains a lot of implicit clashes. Furthermore, I think the semantics zealots have underestimated the value of using UML syntax to make useful distinctions that may have the same foundational semantics but that may have different connotations to users and code generators. -- Jim Rumbaugh Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Mar 2004 15:17:06 -0800 To: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Thanks very much Jim. Well said, and, i feel correct: All of it. I just want to squirm a little right here: Jim Rumbaugh wrote: Joaquin wrote: I feel strongly that we will be wrong if we answer: "UML 2 requires that specification of an attribute in a UML model can not be the technique used to specify that there will be a field {whatever it is called} in an implementation conforming to that model. The user must use some other UML 2 capability to specify that." >> You may feel strongly, but now you are bringing your own expectations to bear and saying that everybody has to accept them. That's the problem with most UML debates. Usage and process issues get transmuted into ontological battles. I did not intend to get into any ontological battles here, and hope i don't get so transmuted. I only ask that UML 2 not restrict the user in this particular way. My position, in short: There is no practical advantage to requiring that the ends in dispute are not attributes of the association class. ....... (Jim, I could go further, as you do, but I will rather stop here, since no reason has been given for this particular restriction. (I hope no one feels as Falstaff did: " Give you a reason on compulsion? If reasons were as plentiful as blackberries, I would give no man a reason upon compulsion, I." )) Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Mar 2004 15:17:06 -0800 To: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Thanks very much Jim. Well said, and, i feel correct: All of it. I just want to squirm a little right here: Jim Rumbaugh wrote: Joaquin wrote: I feel strongly that we will be wrong if we answer: "UML 2 requires that specification of an attribute in a UML model can not be the technique used to specify that there will be a field {whatever it is called} in an implementation conforming to that model. The user must use some other UML 2 capability to specify that." >> You may feel strongly, but now you are bringing your own expectations to bear and saying that everybody has to accept them. That's the problem with most UML debates. Usage and process issues get transmuted into ontological battles. I did not intend to get into any ontological battles here, and hope i don't get so transmuted. I only ask that UML 2 not restrict the user in this particular way. My position, in short: There is no practical advantage to requiring that the ends in dispute are not attributes of the association class. ....... (Jim, I could go further, as you do, but I will rather stop here, since no reason has been given for this particular restriction. (I hope no one feels as Falstaff did: " Give you a reason on compulsion? If reasons were as plentiful as blackberries, I would give no man a reason upon compulsion, I." )) Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Fri, 2 Apr 2004 22:02:30 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: , cl, Issues 6242 (Association not affecting ends), proposed resolution Thread-Index: AcQYLLy7Zl1LZ4YzR/m7FqBoMH/qMgA+nTRw From: "Karl Frank" To: "James E Rumbaugh" , , , , X-OriginalArrivalTime: 03 Apr 2004 03:02:31.0945 (UTC) FILETIME=[1B3AEF90:01C41928] OCLcompatibility is an issue that Jim has overlooked in his otherwise very helpful review of the alternatives. The first navigability concept in Jim's analysis is what OCL uses, and it uses it in very significant ways. So I believe this must be handled as a joint issue. The semantic of the dot expressions in OCL are tied to the notion of the dots representing associations and the result of evaluating such an expression is (as I understand it, and I am no expert in this, hence my copying of Anders) is based on collecting the instances found according to the multiplicity of the association one is navigating. - Karl Frank (Jim's first sense of navigability is quoted next as a reminder) 1. (accessibility) You can get from one object to another using the association. Although this is quoted a lot, it is too vague to be tenable. You can always take an association and an extent, invert the association, and come up with the inverse association. Permissions are a better mechanism if we are concerned about that sort of thing. -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Monday, March 29, 2004 1:52 PM To: mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution OK, since my name has come up I thought I should give a full analysis of the issue. There are several basic concepts that have all gotten mixed together under the name 'navigability'. Also in UML2 the concept of semantics has gotten mixed up (inappropriately) with the question of how to actually program a metamodel repository, so that implementation choices seem to have seeped into the metamodel contents. In the attachment I list the various meanings of navigability that I can think of and where they fit into the picture. - Jim Rumbaugh Edwin Seidewitz 03/25/2004 01:06 PM To mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org cc Subject RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution OK, I kind of hate to add yet another voice to this thread, but I thought I would throw a comment in, because I remember having an extended discussion with Jim R. on exactly the topic of navigability during the UML 1.2 RTF. While I cannot claim for sure that my recollection of this discussion is exactly correct, or that my current position is exactly what I had then (though I definitely remember having the discussion!), I believe the current UML 2.0 metamodel reflects the result of that discussion. Basically, the result of that discussion was the following concept of "navigability". Suppose a binary association R is navigable from class A to class B. Then, knowing _only_ about properties of class A and given _only_ an instance a of A, it is possible to determine the instance b of B associated with a. On the other hand, given _both_ an instance r of R _and_ and instance a of A, it should _always_ be possible to determine the instance b of B associated with a by r. [jr: This is not my doing. What does it mean to "know" "only" a single instance? The association R is there. If we pretend that it is not there, then what does it mean to navigate? This line of thinking makes too many (dubious) assumptions about the implementation of the program.] This conception of "navigability" never really made it into UML 1.x, but is definitely consistent with the UML 2.0 metamodel approach of making the navigable end of R a property of A. Indeed, it _has_ to be a property of A, since you need to be able to do the navigation knowing _only_ about A to start with. In this sense, the navigable end becomes the "moral equivalent" of an attribute of A (whether it really is in the metamodel or not) -- which is how a lot of people (especially OO people) already look at it. [jr: Again, this is mixing up programming language implementation issues and modeling issues. That's not a good way to define a modeling property. If anything, you derive constraints on the implementation from the modeling properties, not the other way around.] On the other hand, people with a relational background tend to start assuming knowledge of the association R, and then want to make queries based on a value at one or the other end. (Or, for an n-ary association, make queries based on values at m ends to get values at the other n-m ends.) This leads to comments like "you can always navigate in either direction". But, with the above conception of "navigation", such queries are _not_ considered navigations. [jr: You can do all kinds of things at run time. We need to define the modeling properties in a more abstract way.] If the metamodel changed along the lines proposed by Conrad, then, for those association ends owned by a class, you still have "navigability" in a sense similar to that conceived above. However, you would _also_ be able to say an association is navigable when the end is _not_ owned by the class. In this case, I have not yet quite seen a clear conception of what "navigability" means, since such a traversal would then seem to require a relational-type query -- which would always be possible. [jr: The definition of run-time accessibily you gave above and the question of who owns the model element in the metamodel are completely unrelated. The program implementation does not have to match the metamodel implementation.] To turn the question around: What does it mean, in Conrad's scheme, if an association end is _not_ marked as navigable? Since a traversal across the association is always conceptually possible given an association instance, and since navigability as I conceived it above is only possible if navigability implies ownership, then the only thing I can think of is that, in Conrad's scheme, non-navigability means "you can, indeed, do the traversal, but you don't have to implement it efficiently". But I thought Conrad disclaimed "navigability = efficiency" somewhere along the line of the discussion. So, I would ask Conrad explicitly: How would you define "navigability" as a distinction within a relational-type query of an association other than efficiency? Or how would you define "navigability" to allow OO-type navigation from one class to another, without requiring any property to be inserted into the first class? Conrad has probably already tried to explain this a few times in his various messages, but I still can't quite get it. -- Ed "Conrad Bock" 03/26/2004 01:54 PM Please respond to conrad.bock To , , cc Subject RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Ed, > OK, I kind of hate to add yet another voice to this thread, but I > thought I would throw a comment in, because I remember having an > extended discussion with Jim R. on exactly the topic of navigability > during the UML 1.2 RTF. While I cannot claim for sure that my > recollection of this discussion is exactly correct, or that my > current position is exactly what I had then (though I definitely > remember having the discussion!), I believe the current UML 2.0 > metamodel reflects the result of that discussion. We should let Jim R speak for himself. I heard something quite different from him during the RTF than you describe below. Conrad Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Mon, 5 Apr 2004 12:12:58 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: , cl, Issues 6242 (Association not affecting ends), proposed resolution Thread-index: AcQYLLy7Zl1LZ4YzR/m7FqBoMH/qMgA+nTRwAHKE6BA= From: "Anders Ivner" To: "Karl Frank" , , , , X-OriginalArrivalTime: 05 Apr 2004 10:13:01.0447 (UTC) FILETIME=[93A3A970:01C41AF6] Karl, all, Actually, OCL 2 cares very little about navigability. It is perfectly legal to follow an association that is not navigable. The only difference is that allowing this is an optional compliance point for ocl-evaluators. So any of the suggested definitions would work from an OCL pespective. /Anders Ivner I would suggest yet another definition of navigability, if I may: Navigability implies dependency. If we have A --> B then - in addition to there being an association between A and B - A depends on B, but B does not depend on A. -----Original Message----- From: Karl Frank Sent: den 3 april 2004 05:18 To: Anders Ivner Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Anders, hi. I sent this out separately to the UML 2 FTF list, but misspelled your name and you did not get it. so this is a repeat for you alone: ------------------- OCLcompatibility is an issue that Jim Rumbaugh has overlooked in his otherwise very helpful review of the alternatives. The first navigability concept in Jim's analysis is what OCL uses, and it uses it in very significant ways. So I believe this must be handled as a joint issue. The semantic of the dot expressions in OCL are tied to the notion of the dots representing associations and the result of evaluating such an expression is (as I understand it, and I am no expert in this, hence my copying of Anders) is based on collecting the instances found according to the multiplicity of the association one is navigating. - Karl Frank (Jim's first sense of navigability is quoted next as a reminder) 1. (accessibility) You can get from one object to another using the association. Although this is quoted a lot, it is too vague to be tenable. You can always take an association and an extent, invert the association, and come up with the inverse association. Permissions are a better mechanism if we are concerned about that sort of thing. -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Monday, March 29, 2004 1:52 PM To: mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution OK, since my name has come up I thought I should give a full analysis of the issue. There are several basic concepts that have all gotten mixed together under the name 'navigability'. Also in UML2 the concept of semantics has gotten mixed up (inappropriately) with the question of how to actually program a metamodel repository, so that implementation choices seem to have seeped into the metamodel contents. In the attachment I list the various meanings of navigability that I can think of and where they fit into the picture. - Jim Rumbaugh Edwin Seidewitz 03/25/2004 01:06 PM To mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org cc Subject RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution OK, I kind of hate to add yet another voice to this thread, but I thought I would throw a comment in, because I remember having an extended discussion with Jim R. on exactly the topic of navigability during the UML 1.2 RTF. While I cannot claim for sure that my recollection of this discussion is exactly correct, or that my current position is exactly what I had then (though I definitely remember having the discussion!), I believe the current UML 2.0 metamodel reflects the result of that discussion. Basically, the result of that discussion was the following concept of "navigability". Suppose a binary association R is navigable from class A to class B. Then, knowing _only_ about properties of class A and given _only_ an instance a of A, it is possible to determine the instance b of B associated with a. On the other hand, given _both_ an instance r of R _and_ and instance a of A, it should _always_ be possible to determine the instance b of B associated with a by r. [jr: This is not my doing. What does it mean to "know" "only" a single instance? The association R is there. If we pretend that it is not there, then what does it mean to navigate? This line of thinking makes too many (dubious) assumptions about the implementation of the program.] This conception of "navigability" never really made it into UML 1.x, but is definitely consistent with the UML 2.0 metamodel approach of making the navigable end of R a property of A. Indeed, it _has_ to be a property of A, since you need to be able to do the navigation knowing _only_ about A to start with. In this sense, the navigable end becomes the "moral equivalent" of an attribute of A (whether it really is in the metamodel or not) -- which is how a lot of people (especially OO people) already look at it. [jr: Again, this is mixing up programming language implementation issues and modeling issues. That's not a good way to define a modeling property. If anything, you derive constraints on the implementation from the modeling properties, not the other way around.] On the other hand, people with a relational background tend to start assuming knowledge of the association R, and then want to make queries based on a value at one or the other end. (Or, for an n-ary association, make queries based on values at m ends to get values at the other n-m ends.) This leads to comments like "you can always navigate in either direction". But, with the above conception of "navigation", such queries are _not_ considered navigations. [jr: You can do all kinds of things at run time. We need to define the modeling properties in a more abstract way.] If the metamodel changed along the lines proposed by Conrad, then, for those association ends owned by a class, you still have "navigability" in a sense similar to that conceived above. However, you would _also_ be able to say an association is navigable when the end is _not_ owned by the class. In this case, I have not yet quite seen a clear conception of what "navigability" means, since such a traversal would then seem to require a relational-type query -- which would always be possible. [jr: The definition of run-time accessibily you gave above and the question of who owns the model element in the metamodel are completely unrelated. The program implementation does not have to match the metamodel implementation.] To turn the question around: What does it mean, in Conrad's scheme, if an association end is _not_ marked as navigable? Since a traversal across the association is always conceptually possible given an association instance, and since navigability as I conceived it above is only possible if navigability implies ownership, then the only thing I can think of is that, in Conrad's scheme, non-navigability means "you can, indeed, do the traversal, but you don't have to implement it efficiently". But I thought Conrad disclaimed "navigability = efficiency" somewhere along the line of the discussion. So, I would ask Conrad explicitly: How would you define "navigability" as a distinction within a relational-type query of an association other than efficiency? Or how would you define "navigability" to allow OO-type navigation from one class to another, without requiring any property to be inserted into the first class? Conrad has probably already tried to explain this a few times in his various messages, but I still can't quite get it. -- Ed "Conrad Bock" 03/26/2004 01:54 PM Please respond to conrad.bock To , , cc Subject RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Ed, > OK, I kind of hate to add yet another voice to this thread, but I > thought I would throw a comment in, because I remember having an > extended discussion with Jim R. on exactly the topic of navigability > during the UML 1.2 RTF. While I cannot claim for sure that my > recollection of this discussion is exactly correct, or that my > current position is exactly what I had then (though I definitely > remember having the discussion!), I believe the current UML 2.0 > metamodel reflects the result of that discussion. We should let Jim R speak for himself. I heard something quite different from him during the RTF than you describe below. Conrad To: "Anders Ivner" Cc: "Karl Frank" , mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, rumbaugh@us.ibm.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 5 Apr 2004 08:52:58 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/05/2004 08:53:01, Serialize complete at 04/05/2004 08:53:01 Hi Anders, You wrote: > Actually, OCL 2 cares very little about navigability. It is > perfectly legal to follow an association that is not navigable. The > only difference is that allowing this is an optional compliance > point for ocl-evaluators. This is something new then in OCL 2. I distinctly recall that in OCL 1.x, navigability was something that OCL respected. I actually objected to this, but got beaten down. Was this something that was explicitly discussed and decided in the OCL submission team, or is this your interpretation? > I would suggest yet another definition of navigability, if I may: > Navigability implies dependency. If we have A --> B then - in > addition to there being an association between A and B - A depends > on B, but B does not depend on A. I hate to say it, but what are the semantics of the "dependency" you mention? Thanks...Bran Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Mon, 5 Apr 2004 15:51:18 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: , cl, Issues 6242 (Association not affecting ends), proposed resolution Thread-index: AcQbDPb5dlmf7PugRHKjlb4P69myHQAA4LgQ From: "Anders Ivner" To: "Branislav Selic" Cc: "Karl Frank" , , , , X-OriginalArrivalTime: 05 Apr 2004 13:51:21.0310 (UTC) FILETIME=[13C41FE0:01C41B15] Hi Bran, Yes, there was a conscious decision in the submission team to allow this. Not that there are any permanent records of that telecon to prove it. But the section about compliance points explicitly mentions this as an optional compliance point. Otherwise, OCL 2 just allows it by not explicitly excluding the possibility. >I hate to say it, but what are the semantics of the "dependency" you mention? Oh... that's what I get for not keeping myself updated on the specs. Do you mean that there is no definition of "dependency" in uml 2? What I was getting at is probably something along the lines of: if A --> B then the definition of A is not complete/useful/meaningful without the definition of B, whereas the definition of B is meaningful without the defintion of A. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 5 april 2004 14:53 To: Anders Ivner Cc: Karl Frank; mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; rumbaugh@us.ibm.org; uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Hi Anders, You wrote: > Actually, OCL 2 cares very little about navigability. It is > perfectly legal to follow an association that is not navigable. The > only difference is that allowing this is an optional compliance > point for ocl-evaluators. This is something new then in OCL 2. I distinctly recall that in OCL 1.x, navigability was something that OCL respected. I actually objected to this, but got beaten down. Was this something that was explicitly discussed and decided in the OCL submission team, or is this your interpretation? > I would suggest yet another definition of navigability, if I may: > Navigability implies dependency. If we have A --> B then - in > addition to there being an association between A and B - A depends > on B, but B does not depend on A. I hate to say it, but what are the semantics of the "dependency" you mention? Thanks...Bran Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Thu, 25 Mar 2004 08:03:30 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Pete, > I'm not sure a resolution is needed for the issue as worded - which is > for 'modeling associations without modifying the end types'. This is > possible in the existing spec. They're related. Yes, you can model associations without affecting the ends, but only if the association is not navigable from either end. By "modeling associations" I meant "modeling associations with restriction". > The resolution actually addresses a different issue: that of 'modeling > property navigability independently of property ownership'. This is a "derived requirement" as it were. Navigation is the spt where we can't currently define associations without affecting the ends (without restriction). > I don't think this can really be resolved until we have an agreed > definition of navigability - since currently the spec *equates* > navigability with property ownership (that is the only semantic > associated with navigability). > More specifically I don't think we can adopt Conrad's resolution which > is to add 'isNavigable' to Property when it has no proposed description > or semantics as to what it means! No, it says that the association is navigable from an object *if* the object owns the opposite end. This assumes navigability is already understood, and tells the modeler how they need to instantiate the metamodel to get that. I would like to deal with these separately: - a more precise definition of navigability - navigation independent of ownership. My proposal does not introduce a new definition of navigation or change the one that's (not) there. It simply restores a UML 1.x capability that was accidentally taken away. > This is different from UML 1.x admittedly, but the words in UML 1.x > are also different from Conrad's desired definition which is more to > do with *efficiency* of navigation than *possibility* of navigation. This isn't just my understanding. I would say most users when they see the navigation arrow, assume that they can query efficiently in that direction. I'm actually rather surprised that anyone didn't see it this way. > Also I think the resolution deletes too much without replacing it - e.g. > 2nd paragraph of description of Associations. In its stead there should > be a similar description about the interaction (or not) of ownership and > navigability. And there should also probably be some new constraints > e.g. if a property is owned by a class then I assume it must be > navigable. We can replace the paragraph with one that says isNavigable = true means the association is navigable from the opposite end. Conrad Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Thu, 25 Mar 2004 08:03:47 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Bran, > I tend to agree with Pete's line of thinking, particularly the > point that the issue being debated is about efficiency rather > than about a fundamental capability. It's not about runtime efficiency, this is where 6243 and the definition navigation are getting confused. In some application the classes being associated *should not change* in the user's model when they are associated. This is true in database and logic-based modeling, and was supported in UML 1.x The issue of navigation only comes up as a derived requirement of not affecting the end classes when defining an association. And even then, it only affects the way navigatio is represented in the metamodel, not the definition of navigation itself. Conrad Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution Date: Thu, 25 Mar 2004 08:04:12 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Associators, There are a number of issues going around under the topic "navigation" that are independent, but are close enough together that they are geting confused. I've listed them below. General points: None of them requires the resolution of the other two. All of them are not possible under the current metamodel, as explained in the second section below. #1 is a modeling issue, #2 and #3 are runtime issues. Conrad The issues: 1) Super 6243: Association not affecting ends This asks that defining an association (of whatever kind and navigability) does not affect the classes. 2) Infra 6460: UML 2 Issue: definition of navigability Asks for a definition of navigability 3) Unfiled: accessing association ends from association class via attribues. Asks to access the ends of an instance of an association via its attributes. Why the metamodel doesn't resolve them: 1) Super 6243: Association not affecting ends An association that is navigable from either end requires the source end class of the navigation to own the property. See the top section of Property, 7.11.4, and the fact that the metamodel has no explicit mention of navigation. Infra 6460: UML 2 Issue: definition of navigability The term "navigation" is used without definition in the spec, as far as I can tell. Unfiled: accessing association ends from association class via attribues. If InstanceSpecification is our guide (which may be incorrect), only features of classifiers that are structural and owned by the classifier may have slots. See the metamodel for InstanceSpecification and Constraint 2 of InstanceSpecification. Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), yet another updated proposed resolution Date: Thu, 25 Mar 2004 08:05:55 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Pete, et al, > Also I think the resolution deletes too much without replacing it - e.g. > 2nd paragraph of description of Associations. See updated proposal attached. > In its stead there should be a similar description about the > interaction (or not) of ownership and navigability. And there should > also probably be some new constraints e.g. if a property is owned by > a class then I assume it must be navigable. This was in the original sketch, but it would conflict with associations that own nonnavigable ends. Presumably users and tool vendors can figure out that a non-navigable attribute (an ordinary property, not an association end), aren't very useful. Conrad P.S. Also added the constraint on properties we talked about yesterday, see end of page 2. issueresolution-62431.doc OMG Issue No: 6243 Title: Association not affecting ends Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Restore UML 1.x capability of modeling associations without modifying the end types. This is needed for database modeling, for profiles to be used with fixed-schema repositories, and is the differentiator of UML over OWL, etc. Discussion: Separate association end ownership from navigation by introducing an isNavigable attribute on properties, as indicated below. In Figure 30: Add attribute to Property: isNavigable : Boolean = true In Association class, section 7.11.2: In Description section: Replace second paragraph with: .An end property of an association with isNavigable = true indicates that the association is navigable from the opposite ends, otherwise the association is not navigable form the opposite ends.. In Associations section: ownedEnd entry, delete "non-navigable". In Semantics section: Delete the sentence above "Note". In Notation section: Replace paragraph above Figure 34 with: "Figure 34 shows that the attribute notation can be used for a navigable end owned by an end class, because a navigable end owned by an end class is also an attribute. Normally in this case the notation would be used in conjunction with the line-arrow notation to make it perfectly clear that the attribute is also an association end." Change caption of Figure 34 to "Example of attribute notation for navigable end owned by an end class." In Property class, section 7.11.4: Replace second two paragraphs with: .A property is related to a class by ownedAttribute represents an attribute, and might also represent an association end. It relates an instance of the class to a value or set of values of the type of the attribute.. .A property related to an association by memberEnd or ownedEnd represents an end of the association. The type of the property is the type of the end of the association.. In Constraints section: Replace rule 4 with: [4] A navigable property can only be redefined or subsetted by a navigable property. (subsettedProperty->exists(sp | sp.isNavigable implies isNavigable) and (redefinedProperty->exists(rp | rp.isNavigable->implies isNavigable) Replace rule 6 with: [6] Only a navigable property can be marked as readOnly. isReadOnly implies isNavigable Add new rule at end: A property that is an ownedAttribute of a class and that is not an ownedEnd of an association must be navigable. if owningAssociation->isEmpty() and class->notEmpty() then isNavigable = true In Semantics section: First paragraph, replace second sentence with: .When related to an association via ownedEnd or memberEnd, it represents an end of the association.. Ninth paragraph, after "If a navigable property", delete "(attribute)". Disposition: Resolved To: Cc: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6242 (Association not affecting ends), proposed resolution X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Jim Amsden Date: Thu, 25 Mar 2004 13:33:34 -0500 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 03/25/2004 11:33:37, Serialize complete at 03/25/2004 11:33:37 > They're related. Yes, you can model associations without affecting the > ends, but only if the association is not navigable from either end. By > "modeling associations" I meant "modeling associations with > restriction". If you want to model an association between two classes, but not effect either class, then by definition, neither of these classes can know anything about the association its ends, or its meaning. So some other element has to be responsible for this. One possibility would be to introduce another mediator class that does know the semantics of the association, and have two one-way associations pointing at the participating classes. Another would be to have an association (a Classifier or by using an AssociationClass) that owns both its ends. > > This is different from UML 1.x admittedly, but the words in UML 1.x > > are also different from Conrad's desired definition which is more to > > do with *efficiency* of navigation than *possibility* of navigation. > > This isn't just my understanding. I would say most users when they see > the navigation arrow, assume that they can query efficiently in that > direction. I'm actually rather surprised that anyone didn't see it this > way. > When I see a navigation arrow, I just think the property at the end is visible and accessible in from the class, that I can refer to this property, i.e., "navigate to it" in an activity or OCL expression. How that's implemented in a runtime is completely separate concern. I would expect the runtime to support the semantics, and that different implementations would have different qualities of service that may or may not be acceptable in any given circumstance. Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), 6460, proposed resolutions Date: Wed, 14 Apr 2004 14:12:44 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MailScanner: , Found to be clean, Found to be clean X-NIST-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 6,autolearn=not spam, BAYES_00 -4.90), X-MailScanner-Information: Please contact your ISP for more information X-MailScanner-From: pete.rivett@adaptive.com X-MIME-Autoconverted: from quoted-printable to 8bit by meles1.mel.nist.gov id i2M6AHPQ000794 Hi all, Here are proposed resolutions to super 6243 (associations not affecting ends) and infra 6460 (definition of navigability). It was agreed in telecon to address these together. Conrad issueresolution-62432.doc issueresolution-6460.doc OMG Issue No: 6243 Title: Association not affecting ends Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Restore UML 1.x capability of modeling associations without modifying the end types. This is needed for database modeling, for profiles to be used with fixed-schema repositories, and is the differentiator of UML over OWL, etc. Discussion: Separate association end ownership from navigation by introducing an isNavigable attribute on properties, as indicated below. In Figure 30: Add attribute to Property: isNavigable : Boolean = true In Association class, section 7.11.2: In Description section: Replace second paragraph with: .An end property of an association with isNavigable = true indicates that the association is navigable from the opposite ends, otherwise the association is not navigable form the opposite ends.. In Associations section: ownedEnd entry, delete "non-navigable". In Semantics section: Delete the sentence above "Note". In Notation section: Replace paragraph above Figure 34 with: "Figure 34 shows that the attribute notation can be used for a navigable end owned by an end class, because a navigable end owned by an end class is also an attribute. Normally in this case the notation would be used in conjunction with the line-arrow notation to make it perfectly clear that the attribute is also an association end." Change caption of Figure 34 to "Example of attribute notation for navigable end owned by an end class." In Property class, section 7.11.4: Replace second two paragraphs with: .A property is related to a class by ownedAttribute represents an attribute, and might also represent an association end. It relates an instance of the class to a value or set of values of the type of the attribute.. .A property related to an association by memberEnd or ownedEnd represents an end of the association. The type of the property is the type of the end of the association.. In Constraints section: Replace rule 4 with: [4] A navigable property can only be redefined or subsetted by a navigable property. (subsettedProperty->exists(sp | sp.isNavigable implies isNavigable) and (redefinedProperty->exists(rp | rp.isNavigable->implies isNavigable) Replace rule 6 with: [6] Only a navigable property can be marked as readOnly. isReadOnly implies isNavigable Add new rule at end: A property that is an ownedAttribute of a class and that is not an ownedEnd of an association must be navigable. if owningAssociation->isEmpty() and class->notEmpty() then isNavigable = true In Semantics section: First paragraph, replace second sentence with: .When related to an association via ownedEnd or memberEnd, it represents an end of the association.. Ninth paragraph, after "If a navigable property", delete "(attribute)". Disposition: Resolved Reply-To: From: "Conrad Bock" To: , , Subject: RE: [mu2i-ftf][mof2xmi-ftf] Apr 22 Joint Telecon moved & Reminder to vote on XMI ballot 3 Date: Thu, 22 Apr 2004 10:28:05 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi all, Here are the documents for some of the discussion today: Super Issue 6243 (Association not affecting ends) Infra Issue 6460 (definition of navigability) Conrad issueresolution-62433.doc issueresolution-64601.doc OMG Issue No: 6243 Title: Association not affecting ends Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Restore UML 1.x capability of modeling associations without modifying the end types. This is needed for database modeling, for profiles to be used with fixed-schema repositories, and is the differentiator of UML over OWL, etc. Discussion: Separate association end ownership from navigation by introducing an isNavigable attribute on properties, as indicated below. In Figure 30: Add attribute to Property: isNavigable : Boolean = true In Association class, section 7.11.2: In Description section: Replace second paragraph with: .An end property of an association with isNavigable = true indicates that the association is navigable from the opposite ends, otherwise the association is not navigable form the opposite ends.. In Associations section: ownedEnd entry, delete "non-navigable". In Semantics section: Delete the sentence above "Note". In Notation section: Replace paragraph above Figure 34 with: "Figure 34 shows that the attribute notation can be used for a navigable end owned by an end class, because a navigable end owned by an end class is also an attribute. Normally in this case the notation would be used in conjunction with the line-arrow notation to make it perfectly clear that the attribute is also an association end." Change caption of Figure 34 to "Example of attribute notation for navigable end owned by an end class." In Property class, section 7.11.4: Replace second two paragraphs with: .A property is related to a class by ownedAttribute represents an attribute, and might also represent an association end. It relates an instance of the class to a value or set of values of the type of the attribute.. .A property related to an association by memberEnd or ownedEnd represents an end of the association. The type of the property is the type of the end of the association.. In Constraints section: Replace rule 4 with: [4] A navigable property can only be redefined or subsetted by a navigable property. (subsettedProperty->exists(sp | sp.isNavigable implies isNavigable) and (redefinedProperty->exists(rp | rp.isNavigable->implies isNavigable) Replace rule 6 with: [6] Only a navigable property can be marked as readOnly. isReadOnly implies isNavigable Add new rule at end: A property that is an ownedAttribute of a class and that is not an ownedEnd of an association must be navigable. if owningAssociation->isEmpty() and class->notEmpty() then isNavigable = true In Semantics section: First paragraph, replace second sentence with: .When related to an association via ownedEnd or memberEnd, it represents an end of the association.. Ninth paragraph, after "If a navigable property", delete "(attribute)". Disposition: Resolved To: Cc: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6243 (Association not affecting ends), 6460 (defintion of navigation), proposed resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sun, 25 Apr 2004 21:05:41 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/25/2004 21:05:43, Serialize complete at 04/25/2004 21:05:43 Thanks, Conrad. I will try to send out an agenda tomorrow. We will have a speaker phone available and the telecon number will be the one we use normally for the Wednesday telecon. Regards, Bran "Conrad Bock" 04/25/2004 09:18 AM Please respond to conrad.bock To , , cc Subject RE: , cl, Issues 6243 (Association not affecting ends), 6460 (defintion of navigation), proposed resolutions Hi all, Here are the materials (".zap" file) for the infra/super FTF discussion on 6243 (Association not affecting ends), 6460 (defintion of navigation). Bran, let me know when/where to call in, thanks, Conrad[attachment "issue-6243-6460.zap" deleted by Branislav Selic/Ottawa/IBM] Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6243 (Association not affecting ends), 6460 (defintion of navigation), proposed resolutions Date: Wed, 5 May 2004 09:35:34 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Navigators, Here's an update to the proposal for 6243, reflecting Ed's point in St Louis that n-aries cannot have ends that are ownedAttribute's of the associated classes, because n-ary navigation requires multiple objects to navigate from. The proposal for 6460 is unchanged, but included for reference. Conrad issueresolution-62434.doc issueresolution-64602.doc OMG Issue No: 6243 Title: Association not affecting ends Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Restore UML 1.x capability of modeling associations without modifying the end types. This is needed for database modeling, for profiles to be used with fixed-schema repositories, and is the differentiator of UML over OWL, etc. Discussion: Separate association end ownership from navigation by introducing an isNavigable attribute on properties, as indicated below. In Figure 30: Add attribute to Property: isNavigable : Boolean = true In Association class, section 7.11.2: In Description section: Replace second paragraph with: .An end property of an association with isNavigable = true indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the opposite ends.. In Associations section: ownedEnd entry, delete "non-navigable". In Semantics section: Delete the sentence above "Note". In Notation section: Replace paragraph above Figure 34 with: "Figure 34 shows that the attribute notation can be used for a navigable end owned by an end class, because a navigable end owned by an end class is also an attribute. The notation should be used in conjunction with the line-arrow notation to make it perfectly clear that the attribute is also an association end." Change caption of Figure 34 to "Example of attribute notation for navigable end owned by an end class." In Property class, section 7.11.4: Replace second two paragraphs with: .A property is related to a class by ownedAttribute represents an attribute, and might also represent an association end. It relates an instance of the class to a value or set of values of the type of the attribute.. .A property related to an association by memberEnd or ownedEnd represents an end of the association. The type of the property is the type of the end of the association.. In Constraints section: Replace rule 4 with: [4] A navigable property can only be redefined or subsetted by a navigable property. (subsettedProperty->exists(sp | sp.isNavigable implies isNavigable) and (redefinedProperty->exists(rp | rp.isNavigable->implies isNavigable) Replace rule 6 with: [6] Only a navigable property can be marked as readOnly. isReadOnly implies isNavigable Add two new rules at end: A property that is an ownedAttribute of a class must be navigable. if class->notEmpty() then isNavigable = true A property that is an association end of an association with more than two ends cannot be an ownedAttribute of the end classes. if association->notEmpty() and association.memberEnd->size() > 2 and class->notEmpty() then not association.memberEnd.type ->includes(class) In Semantics section: First paragraph, replace second sentence with: v.When related to an association via ownedEnd or memberEnd, it represents an end of the association.. Ninth paragraph, after "If a navigable property", delete "(attribute)". Disposition: Resolved To: Cc: mof2xmi-ftf@omg.org, mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: , cl, Issues 6243 (Association not affecting ends), 6460 (defintion of navigation), proposed resolutions X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Wed, 5 May 2004 10:04:37 -0400 X-MIMETrack: Serialize by Router on D25ML06/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/05/2004 10:04:40, Serialize complete at 05/05/2004 10:04:40 Conrad, Since it is possible for association ends to be owned by classifiers other than classes (in fact, they can currently be owned by artifacts, data types, interfaces, signals, and structured classifiers), I'm not sure that it is sufficient to express the new constraints (nor any similar constraints, for that matter) in terms of a property's class. As for the second new constraint, I'm not convinced that it is correct. Shouldn't it be something like this: if association->notEmpty() and association.memberEnd->size() > 2 then owningAssociation->notEmpty() Thanks, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Conrad Bock" 05/05/2004 09:35 AM Please respond to conrad.bock To , , cc Subject RE: , cl, Issues 6243 (Association not affecting ends), 6460 (defintion of navigation), proposed resolutions Navigators, Here's an update to the proposal for 6243, reflecting Ed's point in St Louis that n-aries cannot have ends that are ownedAttribute's of the associated classes, because n-ary navigation requires multiple objects to navigate from. The proposal for 6460 is unchanged, but included for reference. Conrad[attachment "issueresolution-6243.doc" deleted by Kenneth Hussey/Ottawa/IBM] [attachment "issueresolution-6460.doc" deleted by Kenneth Hussey/Ottawa/IBM] Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6243 (Association not affecting ends), 6460 (defintion of navigation), proposed resolutions Date: Wed, 5 May 2004 11:50:47 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Ken, > if association->notEmpty() > and association.memberEnd->size() > 2 > then owningAssociation->notEmpty() Much better, thanks, update attached. Conrad issueresolution-62435.doc issueresolution-64603.doc To: uml2-superstructure-ftf@omg.org Subject: Fw: Modeling Navigability X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 5 May 2004 12:06:13 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/05/2004 12:06:15, Serialize complete at 05/05/2004 12:06:15 Bran ----- Forwarded by Branislav Selic/Ottawa/IBM on 05/05/2004 12:05 PM ----- Jim Amsden/Raleigh/IBM@IBMUS 04/27/2004 09:59 PM To Stephen Brodsky/Santa Teresa/IBM cc Branislav Selic/Ottawa/IBM@IBMCA Subject RE: Modeling NavigabilityLink Steve, Here's my take, but I might not have it right either. Say you had existing classes Student and Course. Now you want to introduce an association between them where students take courses. The simpliest, EMOF way to do this is to introduce a property as: or the equivalent: In Basic, Student gets a new Property called courses. In Constructs, an Association is created which has :Student and courses:Course[0..*] as its member ends, and :Student as its ownedEnd. courses is still a property of Student. Now if the association is navigable in both directions, then in Basic the property opposites would ensure the (effectively) two one-way associations form a dependent loop resulting in property->opposite->opposite resulting in the same instance. This can't be modeled in Constructs without introducing an Association with no ownedEnds. What Conrad wants is a way to introduce this association in such a way that Student isn't changed, it doesn't get a new property. This can be modeled three ways in UML2 now: An association that isn't navigable from either end: This introduces a relation defining a tuple (:Student, courses:Course[0..*]) where the Association owns both ends. However, given an instance of a student, there's no way to "navigate to" or otherwise access the courses related through the tuple. Conrad wants to use the navigation arrows to serve an indicator to implementations that an efficient implementation must be provided to find courses related to a student through the relation, and at runtime, the courses are accessible from an instance of a Student. Example implementations would be a Dictionary, Hashtable, or relational query. This is why I think this is out of scope for UML2. Given a mathematical relation, all you know is the members of a tuple. Given a member of some tuple, other than a search, there's no formal way to determine the related members of the same tuple unless the relation is quite constrained (a 1-1 or maybe even onto function depending on the directions you want to navigate). But it is common in the relational world to treat associations this way, so that's why Conrad wants it. Another way would be to use an AssociationClass: Registration is now responsible for managing the semantics of the instances related through the tuple. Another possibility is to introduce a mediator: In both cases, there's another class that manages the association semantics and can provide the navigability without effecting the associated classes. But such correlation objects aren't always used in relational databases unless the multiplicities require it. So as far as I can see, Conrad doesn't want and to mean exactly the same thing. The second example introduces an Association that owns both ends, but marks the courses end with isNavigable=ture so runtime semantics or translations know they have to be able to implement this somehow. However, in either case, an action or OCL expression can navigate from an instance of a Student to its courses at runtime. But this is confusing references and relations, and there's no way to model a backpointer like Property::opposite which Conrad also wants. So I think his solution introduces "fuzzy" semantics in order to support what appears as an implementation strategy. Stephen Brodsky/Santa Teresa/IBM 04/27/2004 09:14 PM To cc "Branislav Selic" , Jim Amsden/Raleigh/IBM@IBMUS Subject RE: Modeling NavigabilityLink Conrad, Can you help me understand the motivation for 6243 better? I have been on the calls and at the meetings and have seen the presentation, but I still don't understand the issue regarding "without effecting" is. I think you are trying to do something like model RDF assertions/statements? Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Conrad Bock" 04/27/2004 05:46 PM Please respond to conrad.bock To: Jim Amsden/Raleigh/IBM@IBMUS, "Branislav Selic" cc: Stephen Brodsky/Santa Teresa/IBM@IBMUS Subject: RE: Modeling Navigability Jim, Thanks for writing this up. As you said, it needs iteration before sending around. Will work on it later this week, which may mean the weekend. :) Conrad -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, April 27, 2004 5:42 PM To: Branislav Selic Cc: Conrad Bock; Stephen Brodsky Subject: Modeling Navigability Bran, Conrad and I had a long conversation about the association navigability issue and I volunteered to summarize. I'll try to spell out the issues we discussed, including a couple of new ones we discovered, and then explore the approaches we discussed for resolving them and their pros and cons. Issues Issue 6243: Need to be able to have navigable associations without effecting the classifiers at the ends. My understanding of this issue is that we do have a way of modeling OO references (using Property and opposite) in UML2, and relations using Associations. But what Conrad wants is a way of indicating that for a relation, he would like to indicate in the model that tools should provide a way of "navigating" from one element in a tuple to another in the relation. This is not really a fundamental modeling semantic as it is a way of telling translators to generate some efficient implementation for locating members of a tuple from other members. Association navigability is one such way, and the way Conrad proposes, but there may be other ways that we explore below. Issue 6462: No formal definition of navigability. (new issue) There is no Action for reading or writing the member ends of an Association. ReadLinkAction doesn't work, because it is not allowed on non-navigable ends, and is therefore redundant because in the current metamodel, these properties can be accessed with a ReadStructuralFeatureAction. ReadLinkObjectEndAction doesn't work because it only applies to AssociationClasses, not Associations. So there is no action that reads association owned ends. (new issue) The property support in Basic is not allowed in Constructs. Basic has Property::opposite which models simple OO references with back pointers indicating a constraint on the instances. Basic uses the same notation as associations in Constructs. In particular it uses the arrow to indicate when the opposite should have a value. However, Property::opposite is derived in Constructs and Kernel so it is no longer possible to model simple OO references without introducing an instance of an Association. Possible Solutions We discussed four possible solutions, which of the issues they addressed, and their pros and cons. 1. Do Nothing Don't change anything in the metamodel. Model object references using properties, and relations using associations, association classes, or a mediator class that knows the participating classes and the meaning of the association. Define navigability in terms of property ownership. + doesn't require any changes to the metamodel + already supports the semantics of references and relations + Navigability arrow in the notation has the same meaning in Basic and Constructs. - Only addresses issue 2 - would require some additional profile to indicate accessing objects in a relation tuple from other objects in the tuple. - there's no action for accessing owned ends of the association +- (not really a pro or con) Requires x's in the notation to indicate both ends are not navigable and the association owns both ends 2. Add an Action for accessing Association::memberEnd Either create a new action, or change ReadLinkAction and WriteLinkAction to allow access to association member ends. + Only changes a constraint in the metamodel + addresses issues 2 and 3 - doesn't address issue 1 or 4 - could introduce confusion that it is possible to access the ends of an association even if the association isn't navigable. But if issue 2 is resolved by defining navigability in terms of participating classes (so it has the same meaning in Basic and Constructs), then this isn't a problem - doesn't address the relationship between association member or owned ends, and association (as a classifier) attributes. 3. Adopt Conrad's proposal Introduce Property::isNavigable to indicate a property is navigable, even if it is an ownedAttribute of a class instead of an ownedMember of an Association. + Addresses issues 1 and 2 - introduces a property whose value is fixed by a constraint in instances where the property is owned by the participating class, and where the type of the property is not a class (i.e., doesn't have identity such as primitive types of data types acting as value objects). - Isn't consistent with Basic's modeling of navigability - confuses the semantics of reference and membership in a relation. A mathematical relation says nothing about how to access one member of a tuple from another. In fact, in many instances this would be non-deterministic unless the relation were a function. And then the navigability would depend on whether the function was 1-1 or not, etc. - requires ReadLinkAction to access the property instead of just ReadStructuralFeature - doesn't address issues 3 and 4 - could be considered a transformation concern outside the scope of UML2 semantics. However common practice does use UML associations to model relational database relations and navigability has a well understood meaning in the relational context, separate from ownership. 4. Introduce metaclass AssociationEnd Reintroduce metaclass AssociationEnd as a subclass of Property. Change Association ownedEnd to be to an AssociationEnd. Add property AssociationEnd::isNavigable. Make Property::opposite non-derived. Keep the semantics of object reference (property and opposite) separate from the semantics of relations. Make Association::memberEnd and ownedEnd subsets of derived union Classifier::attribute. Eliminate ReadLinkAction and just use ReadStructuralFeature This introduces additional metamodel elements to capture the specific information Conrad wants - indicating how to navigate from one member of a tuple to another in the same tuple, but doesn't confuse references and relations. + Resolves all 4 problems + doesn't commingle reference and relation semantics + doesn't require ReadLinkAction - Introduces a new metaclass and may be difficult to get through FTF This is just a start to capture what we discussed. Resolution 4 looks promising but needs further investigation to see if it really works and doesn't introduce other problems. I didn't want to way to do this before getting something out, so consider it very tentative at this point. Can we iterate on this a bit to reach some common agreement before sending the proposal to the mailing list? Fw Modeling Navigability.gif Fw Modeling Navigability1.gif Fw Modeling Navigability2.gif Fw Modeling Navigability3.gif Fw Modeling Navigability4.gif Fw Modeling Navigability5.gif Fw Modeling Navigability6.gif Fw Modeling Navigability7.gif To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: Re: Fw: Modeling Navigability X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Wed, 5 May 2004 11:08:57 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 05/05/2004 12:08:58, Serialize complete at 05/05/2004 12:08:58 I think that both Conrad and Jim A. can be accommodated. Conrad is not asking for something .fuzzy.. He is asking for a modeling flag that imposes a constraint on the implementation (an efficient implementation of traversal from one object to a set of related objects) without forcing a particular implementation. This seems like exactly the sort of thing that models are intended for, so it is not out of scope or inappropriate. It is a design-stage property, but we already have plenty of those (such as visibility). The fact that some people are asking for it means that they think it is useful. I think we should add the proposed efficient-traversal flag. Perhaps it should have a new notation, however, leaving the arrow to mean ownership of a property by a class in the model repository as in the current UML2 spec. One important thing is that none of the definitions of navigability are about semantics (where semantics is about the meaning of the model). All of Jim A.s examples mean the same thing, for example. Navigability is about the implementation of information (model-time or run-time, as the case may be), which is an important consideration but different from logical meanings. I think the current UML2 metamodel addresses the need for .model knowledge.. In the current UML2 metamodel, ownership of a property (including an association end) by a class indicates that the class is affected by adding the association and lack of ownership indicates that it is not affected by adding the association. You can have 1-way ownership (with or without an association), 2-way ownership (with an association), and 0-way ownership (with an association). Let.s call this model-navigability. It is important because people want to build packages that do not change when additional packages are added. They want to use the original packages without fear that they will suddenly change without warning. Conrad.s proposal adds a flag to indicate that the eventual run-time implementation must provide an efficient way to get from an object of one class (such as Student) to its related objects (such as Courses). It does not say anything about the structure of the model in the model repository.you could require efficient traversal from Student to Course even if the classes in the model repository don.t know about each other, as in the stand-alone association. This is a modeling issue because you can.t design algorithms, and therefore methods, without worrying about computational complexity (actually you can, as evidenced by a lot of lousy software, if you don.t mind building bad applications). Not that, just because Student-in-the-model doesn.t know about Course-in-the-model does not mean that Student-the-Java-class doesn.t know about Course-the-Java-class. Code generation can examine the entire model; it doesn.t have to operate on a package-by-package separate compilation basis. But the run-time-navigability flag does not mean that Student-the-Java-class must have a method to find Courses. You might choose to implement the Student-Course relationship as a stand-alone look-up table that you call with a Student object as input.who said that all navigation has to be done using methods on the affected classes? Those are detailed design decisions for the implementer. Requiring efficient traversal is a basic algorithmic consideration of a much higher level and very appropriate for capturing in a design model. I don.t see why making this kind of constraint on the run-time implementation (especially in such a generic way that admits various possible implementations) is .out of scope. for UML. UML is intended to allow developers to model things that are important, and the need to efficiently traverse from object to object is an important thing. It is a design thing, not a logical semantics thing, but UML models both logical and design attributes. Possibly .navigability. is not the right term for run-time efficiency. Maybe it should be called .efficiency.. We will need a new symbol for it. Or maybe the arrow should be reserved for the case when you have both .ownership. and .efficiency. (it is probably true that usually you get both or neither). As a final note, I think that OCL expressions should not incorporate either view of navigability. That is, you should be able to write an expression .student.courses. even if the model contains a stand-alone association. The expression is perfectly well defined. It cannot be evaluated using only the Student class, but in the context of a model containing both the Student class and the association (possibly in different packages), its meaning is perfectly clear and can be evaluated without ambiguity. OCL should focus on the logical semantics, not the packaging of the model in the model repository or the run-time implementation. It is also not the case that the model representation should say anything about the generated Java classes. That is an MDA issue using a particular code generator, not a UML issue. Any one of Jim A.s examples could generate a Java class Student that contains a pointer to a set of Courses or that implements the association as a separate look-up table. It is important not to treat UML as a visual programming language for Java, although a particular code generator could do that if it wants, but let.s not make assumptions about all code generators. - Jim Rumbaugh Branislav Selic 05/05/2004 09:06 AM To uml2-superstructure-ftf@omg.org cc Subject Fw: Modeling Navigability Bran ----- Forwarded by Branislav Selic/Ottawa/IBM on 05/05/2004 12:05 PM ----- Jim Amsden/Raleigh/IBM@IBMUS 04/27/2004 09:59 PM To Stephen Brodsky/Santa Teresa/IBM cc Branislav Selic/Ottawa/IBM@IBMCA Subject RE: Modeling NavigabilityLink Steve, Here's my take, but I might not have it right either. Say you had existing classes Student and Course. Now you want to introduce an association between them where students take courses. The simpliest, EMOF way to do this is to introduce a property as: or the equivalent: In Basic, Student gets a new Property called courses. In Constructs, an Association is created which has :Student and courses:Course[0..*] as its member ends, and :Student as its ownedEnd. courses is still a property of Student. Now if the association is navigable in both directions, then in Basic the property opposites would ensure the (effectively) two one-way associations form a dependent loop resulting in property->opposite->opposite resulting in the same instance. This can't be modeled in Constructs without introducing an Association with no ownedEnds. What Conrad wants is a way to introduce this association in such a way that Student isn't changed, it doesn't get a new property. This can be modeled three ways in UML2 now: An association that isn't navigable from either end: This introduces a relation defining a tuple (:Student, courses:Course[0..*]) where the Association owns both ends. However, given an instance of a student, there's no way to "navigate to" or otherwise access the courses related through the tuple. Conrad wants to use the navigation arrows to serve an indicator to implementations that an efficient implementation must be provided to find courses related to a student through the relation, and at runtime, the courses are accessible from an instance of a Student. Example implementations would be a Dictionary, Hashtable, or relational query. This is why I think this is out of scope for UML2. Given a mathematical relation, all you know is the members of a tuple. Given a member of some tuple, other than a search, there's no formal way to determine the related members of the same tuple unless the relation is quite constrained (a 1-1 or maybe even onto function depending on the directions you want to navigate). But it is common in the relational world to treat associations this way, so that's why Conrad wants it. Another way would be to use an AssociationClass: Registration is now responsible for managing the semantics of the instances related through the tuple. Another possibility is to introduce a mediator: In both cases, there's another class that manages the association semantics and can provide the navigability without effecting the associated classes. But such correlation objects aren't always used in relational databases unless the multiplicities require it. So as far as I can see, Conrad doesn't want and to mean exactly the same thing. The second example introduces an Association that owns both ends, but marks the courses end with isNavigable=ture so runtime semantics or translations know they have to be able to implement this somehow. However, in either case, an action or OCL expression can navigate from an instance of a Student to its courses at runtime. But this is confusing references and relations, and there's no way to model a backpointer like Property::opposite which Conrad also wants. So I think his solution introduces "fuzzy" semantics in order to support what appears as an implementation strategy. Stephen Brodsky/Santa Teresa/IBM 04/27/2004 09:14 PM To cc "Branislav Selic" , Jim Amsden/Raleigh/IBM@IBMUS Subject RE: Modeling NavigabilityLink Conrad, Can you help me understand the motivation for 6243 better? I have been on the calls and at the meetings and have seen the presentation, but I still don't understand the issue regarding "without effecting" is. I think you are trying to do something like model RDF assertions/statements? Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Conrad Bock" 04/27/2004 05:46 PM Please respond to conrad.bock To: Jim Amsden/Raleigh/IBM@IBMUS, "Branislav Selic" cc: Stephen Brodsky/Santa Teresa/IBM@IBMUS Subject: RE: Modeling Navigability Jim, Thanks for writing this up. As you said, it needs iteration before sending around. Will work on it later this week, which may mean the weekend. :) Conrad -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, April 27, 2004 5:42 PM To: Branislav Selic Cc: Conrad Bock; Stephen Brodsky Subject: Modeling Navigability Bran, Conrad and I had a long conversation about the association navigability issue and I volunteered to summarize. I'll try to spell out the issues we discussed, including a couple of new ones we discovered, and then explore the approaches we discussed for resolving them and their pros and cons. Issues Issue 6243: Need to be able to have navigable associations without effecting the classifiers at the ends. My understanding of this issue is that we do have a way of modeling OO references (using Property and opposite) in UML2, and relations using Associations. But what Conrad wants is a way of indicating that for a relation, he would like to indicate in the model that tools should provide a way of "navigating" from one element in a tuple to another in the relation. This is not really a fundamental modeling semantic as it is a way of telling translators to generate some efficient implementation for locating members of a tuple from other members. Association navigability is one such way, and the way Conrad proposes, but there may be other ways that we explore below. Issue 6462: No formal definition of navigability. (new issue) There is no Action for reading or writing the member ends of an Association. ReadLinkAction doesn't work, because it is not allowed on non-navigable ends, and is therefore redundant because in the current metamodel, these properties can be accessed with a ReadStructuralFeatureAction. ReadLinkObjectEndAction doesn't work because it only applies to AssociationClasses, not Associations. So there is no action that reads association owned ends. (new issue) The property support in Basic is not allowed in Constructs. Basic has Property::opposite which models simple OO references with back pointers indicating a constraint on the instances. Basic uses the same notation as associations in Constructs. In particular it uses the arrow to indicate when the opposite should have a value. However, Property::opposite is derived in Constructs and Kernel so it is no longer possible to model simple OO references without introducing an instance of an Association. Possible Solutions We discussed four possible solutions, which of the issues they addressed, and their pros and cons. 1. Do Nothing Don't change anything in the metamodel. Model object references using properties, and relations using associations, association classes, or a mediator class that knows the participating classes and the meaning of the association. Define navigability in terms of property ownership. + doesn't require any changes to the metamodel + already supports the semantics of references and relations + Navigability arrow in the notation has the same meaning in Basic and Constructs. - Only addresses issue 2 - would require some additional profile to indicate accessing objects in a relation tuple from other objects in the tuple. - there's no action for accessing owned ends of the association +- (not really a pro or con) Requires x's in the notation to indicate both ends are not navigable and the association owns both ends 2. Add an Action for accessing Association::memberEnd Either create a new action, or change ReadLinkAction and WriteLinkAction to allow access to association member ends. + Only changes a constraint in the metamodel + addresses issues 2 and 3 - doesn't address issue 1 or 4 - could introduce confusion that it is possible to access the ends of an association even if the association isn't navigable. But if issue 2 is resolved by defining navigability in terms of participating classes (so it has the same meaning in Basic and Constructs), then this isn't a problem - doesn't address the relationship between association member or owned ends, and association (as a classifier) attributes. 3. Adopt Conrad's proposal Introduce Property::isNavigable to indicate a property is navigable, even if it is an ownedAttribute of a class instead of an ownedMember of an Association. + Addresses issues 1 and 2 - introduces a property whose value is fixed by a constraint in instances where the property is owned by the participating class, and where the type of the property is not a class (i.e., doesn't have identity such as primitive types of data types acting as value objects). - Isn't consistent with Basic's modeling of navigability - confuses the semantics of reference and membership in a relation. A mathematical relation says nothing about how to access one member of a tuple from another. In fact, in many instances this would be non-deterministic unless the relation were a function. And then the navigability would depend on whether the function was 1-1 or not, etc. - requires ReadLinkAction to access the property instead of just ReadStructuralFeature - doesn't address issues 3 and 4 - could be considered a transformation concern outside the scope of UML2 semantics. However common practice does use UML associations to model relational database relations and navigability has a well understood meaning in the relational context, separate from ownership. 4. Introduce metaclass AssociationEnd Reintroduce metaclass AssociationEnd as a subclass of Property. Change Association ownedEnd to be to an AssociationEnd. Add property AssociationEnd::isNavigable. Make Property::opposite non-derived. Keep the semantics of object reference (property and opposite) separate from the semantics of relations. Make Association::memberEnd and ownedEnd subsets of derived union Classifier::attribute. Eliminate ReadLinkAction and just use ReadStructuralFeature This introduces additional metamodel elements to capture the specific information Conrad wants - indicating how to navigate from one member of a tuple to another in the same tuple, but doesn't confuse references and relations. + Resolves all 4 problems + doesn't commingle reference and relation semantics + doesn't require ReadLinkAction - Introduces a new metaclass and may be difficult to get through FTF This is just a start to capture what we discussed. Resolution 4 looks promising but needs further investigation to see if it really works and doesn't introduce other problems. I didn't want to way to do this before getting something out, so consider it very tentative at this point. Can we iterate on this a bit to reach some common agreement before sending the proposal to the mailing list? Re Fw Modeling Navigability.gif Re Fw Modeling Navigability1.gif Re Fw Modeling Navigability2.gif Re Fw Modeling Navigability3.gif Re Fw Modeling Navigability4.gif Re Fw Modeling Navigability5.gif Re Fw Modeling Navigability6.gif Re Fw Modeling Navigability7.gif Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), 6460 (definition of navigation), proposed resolutions Date: Tue, 25 May 2004 09:39:25 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIME-Autoconverted: from quoted-printable to 8bit by meles1.mel.nist.gov id i2M6AHPQ000794 X-MailScanner: , Found to be clean, Found to be clean X-NIST-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 6,autolearn=not spam, BAYES_00 -4.90), X-MailScanner-Information: Please contact your ISP for more information X-MailScanner-From: pete.rivett@adaptive.com X-MS-Has-Attach: X-MS-TNEF-Correlator: Hi all, After discussion with interested folks, here are the proposals for: Super 6243 (Association not affecting ends) Infra 6460 (definition of navigation) The first only affects superstructure, though infrastructure should consider making the same change. The second is a change to shared text in infra and super. Bran, 6243 and 6460 are for super ballot 16. Pete, what is the appropriate time to ballot 6460 in infra? Conrad issueresolution-6243.doc issueresolution-6460.doc OMG Issue No: 6243 Title: Association not affecting ends Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Restore UML 1.x capability of modeling associations without modifying the end types. This is needed for database modeling, for profiles to be used with fixed-schema repositories, and is the differentiator of UML over OWL, etc. Discussion: Summary The intent of this resolution is to harmonize the relational (UML 1.x) and object-oriented (UML 2) viewpoints in modeling associations, properties, and navigability. It recommends separating ownership and navigation, while preserving the other beneficial aspects of the UML 2 model, in particular, the unification of properties and association ends. The changes provide more flexiblity than both UML 1.x and 2.0 in modeling commonly needed combinations of navigability and ownership. Comparing UML 1.x and UML 2: UML 1.x supported the specification of associations without modifying the classes being associated. Association ends were always owned by the association, regardless of the navigability of the association. The model was most appropriate for relational applications such as databases, hash tables, SmallTalk dictionaries, and predicate logic, and was useful when the classes being associated should not be modified for some reason, such as using a read-only model, or derived associations. It was less appropriate for object-oriented applications, which expected that the navigation of an association would modify the source class of the navigation by defining an attribute on it to support runtime traversal from instances of the class. The UML 1.x model also separted attributes and associations, even though these are usually different views of the same underlying semantic. UML 2 requires modification of the classes being associated in common cases. In particular, it requires that an association end (modeled as a property) be owned by the end classes when it is the source of navigation. The model is most appropriate for object-oriented or record-based applications, and supports supports class diagrams and composite structure diagrams as views on a single underlying model. It is less appropriate for relational applications and derived associations, which expect that the navigation of an association does not necessarily modify the source class of the navigation. Example: In UML 2, suppose we model an association of teachers to courses like this: In UML 2 this means: For the relational modeler, the above will normally imply a column in the Teacher table, even when this is not desired. Instead, the modeler might want an intersection/correlation table, which in effect puts the columns on the association. UML 2 offers this solution to have the association own properties for teacher and course: However, this prevents navigation from both teachers and courses, or at least does not require it in the generated implementation. The modeler probably wants the compiler to generate an API or other means for querying a course for its teacher. The model must be refined to: This again has the undesired effect of an attribute on Teacher, because the current specification does not indicate that derived associations should not affect the end classes. In addition, it is a detailed model more appropriate for the late design stage, rather than early as in the first example figure. And a late stage model might migrate the column across to the other end, to prevent repeated groups and normalize the database: These examples shows that navigability in relational modeling is a requirement for query services, rather than property ownership. The model should indicate it is possible at runtime to get courses given a teacher, rather than indicate Teacher has a course property. Proposed changes: In Figure 30: Add association between Property and Association that identifies the owned ends that are navigable called navigableEnd specialized from ownedEnd: In Association class, section 7.11.2: In Description section: Replace second paragraph with: .An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the opposite ends.. In Associations section: ownedEnd entry, delete "non-navigable". Add navigableOwnedEnd attribute: navigableOwnedEnd : Property [*] The navigable ends that are owned by the association itself. Subsets Association.ownedEnd. In Constraints section add new constraint: Association ends of associations with more than two ends must be owned by the association. if memberEnd->size() > 2 then ownedEnd->includesAll(memberEnd) In Semantics section: Delete the sentence above "Note". In Notation section: Replace paragraph above Figure 34 with: "Figure 34 shows that the attribute notation can be used for an association end owned by a class, because an association end owned by a class is also an attribute. This notation may be used in conjunction with the line-arrow notation to make it perfectly clear that the attribute is also an association end." Change caption of Figure 34 to "Example of attribute notation for navigable end owned by an end class." In Property class, section 7.11.4: Replace second two paragraphs with: .A property related to a class by ownedAttribute represents an attribute, and might also represent an association end. It relates an instance of the class to a value or set of values of the type of the attribute.. .A property related to an association by memberEnd or its specializations represents an end of the association. The type of the property is the type of the end of the association.. In Constraints section: Replace rule 4 with: [4] A navigable property can only be redefined or subsetted by a navigable property. (subsettedProperty->exists(sp | sp.isNavigable() implies isNavigable()) and (redefinedProperty->exists(rp | rp.isNavigable implies isNavigable()) Replace rule 6 with: [6] Only a navigable property can be marked as readOnly. isReadOnly implies isNavigable() Add Additional Operations section after Constraints containing: [1] The query isNavigable indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean IsNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) In Semantics section: First paragraph, replace second sentence with: .When related to an association via memberEnd or one of its specializations, it represents an end of the association.. Ninth paragraph, after "If a navigable property", delete "(attribute)". Disposition: Resolved From: Edwin Seidewitz To: "'conrad.bock@nist.gov'" , "'mof2xmi-ftf@omg.org'" , "'mu2i-ftf@omg.org'" , "'uml2-superstructure-ftf@omg.org'" Subject: RE: , cl, Issues 6242 (Association not affecting ends), 6460 (de finition of navigation), proposed resolutions Date: Tue, 25 May 2004 11:38:40 -0400 X-Mailer: Internet Mail Service (5.5.2655.55) Conrad -- For what it's worth, I like your proposed resolutions. I would note, though, that the resolution to Issue 6242 should include changing constraint 4 of ReadLinkAction (Section 11.3.28) to replace "isNavigable = #true" with "isNavigable()". A search of the document seems to indicate that this is the only current reference to "isNavigable". -- Ed > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Tuesday, May 25, 2004 9:39 AM > To: mof2xmi-ftf@omg.org; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org > Subject: RE: , cl, Issues 6242 (Association not affecting ends), 6460 > (definition of navigation), proposed resolutions > > > Hi all, > > After discussion with interested folks, here are the proposals for: > > Super 6243 (Association not affecting ends) > > Infra 6460 (definition of navigation) > > The first only affects superstructure, though infrastructure should > consider making the same change. The second is a change to shared text > in infra and super. > > Bran, 6243 and 6460 are for super ballot 16. > > Pete, what is the appropriate time to ballot 6460 in infra? > > Conrad OMG Issue No: 6243 Title: Association not affecting ends Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Restore UML 1.x capability of modeling associations without modifying the end types. This is needed for database modeling, for profiles to be used with fixed-schema repositories, and is the differentiator of UML over OWL, etc. Discussion: Summary The intent of this resolution is to harmonize the relational (UML 1.x) and object-oriented (UML 2) viewpoints in modeling associations, properties, and navigability. It recommends separating ownership and navigation, while preserving the other beneficial aspects of the UML 2 model, in particular, the unification of properties and association ends. The changes provide more flexiblity than both UML 1.x and 2.0 in modeling commonly needed combinations of navigability and ownership. Comparing UML 1.x and UML 2: UML 1.x supported the specification of associations without modifying the classes being associated. Association ends were always owned by the association, regardless of the navigability of the association. The model was most appropriate for relational applications such as databases, hash tables, SmallTalk dictionaries, and predicate logic, and was useful when the classes being associated should not be modified for some reason, such as using a read-only model, or derived associations. It was less appropriate for object-oriented applications, which expected that the navigation of an association would modify the source class of the navigation by defining an attribute on it to support runtime traversal from instances of the class. The UML 1.x model also separted attributes and associations, even though these are usually different views of the same underlying semantic. UML 2 requires modification of the classes being associated in common cases. In particular, it requires that an association end (modeled as a property) be owned by the end classes when it is the source of navigation. The model is most appropriate for object-oriented or record-based applications, and supports supports class diagrams and composite structure diagrams as views on a single underlying model. It is less appropriate for relational applications and derived associations, which expect that the navigation of an association does not necessarily modify the source class of the navigation. Example: In UML 2, suppose we model an association of teachers to courses like this: In UML 2 this means: For the relational modeler, the above will normally imply a column in the Teacher table, even when this is not desired. Instead, the modeler might want an intersection/correlation table, which in effect puts the columns on the association. UML 2 offers this solution to have the association own properties for teacher and course: However, this prevents navigation from both teachers and courses, or at least does not require it in the generated implementation. The modeler probably wants the compiler to generate an API or other means for querying a course for its teacher. The model must be refined to: This again has the undesired effect of an attribute on Teacher, because the current specification does not indicate that derived associations should not affect the end classes. In addition, it is a detailed model more appropriate for the late design stage, rather than early as in the first example figure. And a late stage model might migrate the column across to the other end, to prevent repeated groups and normalize the database: These examples shows that navigability in relational modeling is a requirement for query services, rather than property ownership. The model should indicate it is possible at runtime to get courses given a teacher, rather than indicate Teacher has a course property. Proposed changes: In Figure 30: Add association between Property and Association that identifies the owned ends that are navigable called navigableEnd specialized from ownedEnd: In Association class, section 7.11.2: In Description section: Replace second paragraph with: .An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the opposite ends.. In Associations section: ownedEnd entry, delete "non-navigable". Add navigableOwnedEnd attribute: navigableOwnedEnd : Property [*] The navigable ends that are owned by the association itself. Subsets Association.ownedEnd. In Constraints section add new constraint: Association ends of associations with more than two ends must be owned by the association. if memberEnd->size() > 2 then ownedEnd->includesAll(memberEnd) In Semantics section: Delete the sentence above "Note". In Notation section: Replace paragraph above Figure 34 with: "Figure 34 shows that the attribute notation can be used for an association end owned by a class, because an association end owned by a class is also an attribute. This notation may be used in conjunction with the line-arrow notation to make it perfectly clear that the attribute is also an association end." Change caption of Figure 34 to "Example of attribute notation for navigable end owned by an end class." In Property class, section 7.11.4: Replace second two paragraphs with: .A property related to a class by ownedAttribute represents an attribute, and might also represent an association end. It relates an instance of the class to a value or set of values of the type of the attribute.. .A property related to an association by memberEnd or its specializations represents an end of the association. The type of the property is the type of the end of the association.. In Constraints section: Replace rule 4 with: [4] A navigable property can only be redefined or subsetted by a navigable property. (subsettedProperty->exists(sp | sp.isNavigable() implies isNavigable()) and (redefinedProperty->exists(rp | rp.isNavigable implies isNavigable()) Replace rule 6 with: [6] Only a navigable property can be marked as readOnly. isReadOnly implies isNavigable() Add Additional Operations section after Constraints containing: [1] The query isNavigable indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean IsNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) In Semantics section: First paragraph, replace second sentence with: .When related to an association via memberEnd or one of its specializations, it represents an end of the association.. Ninth paragraph, after "If a navigable property", delete "(attribute)". In ReadLinkAction class, Constraints, in OCL of constraint [4], replace .isNavigable = #true. with .isNavigable().. Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6243 (Association not affecting ends), 6460 (defintion of navigation), proposed resolutions Date: Thu, 27 May 2004 14:07:15 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Navigators, Per the joint telecon today, here are the updates to: - 6243 (Association not affecting ends) This is in two versions, one for infra and one for super. The infra proposal includes some minor textual changes to MOF 2 Core. - 6460 (definition of navigation) This is in one version for super and infra. It does not affect MOF 2 Core. Change bars are from the last revision of the proposal. The changes are proposed for infra, super, and MOF 2 Core. Infra will go to ballot next week, and super in ballot 16. Let me know if there are any other comments. Thanks, Conrad issueresolution-6243-super.doc issueresolution-6243-infra.doc Disposition: Resolved Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 May 2004 13:51:55 -0700 To: UML Superstructure FTF , MOF UML Infrastructure FTF From: Joaquin Miller Subject: RE: , cl, Issues 6243 (Association not affecting ends), 6460 (defintion of navigation), proposed resolutions Good work, Conrad and all. 6460: Traversal of an n-ary association towards a navigable end requires that first the objects first be provided for at the remaining n-1 ends be identified. The result of traversal is a collection of objects for the navigable end derived from links in which the other n-1 objects participate. For binary associations n=2, in which case traversal proceeds from one object at the other end to a collection of objects at the navigable end. The objects need not be provided; they must be identified. 6243 (just editing): 1) It was less appropriate for object-oriented applications, which expected that specification of the navigationbility of an association would modify the source class of the navigation by defining an attribute on it to support runtime traversal from instances of the class. 2) The UML 1.x model also separated attributes and associations, even though these are usually different views of the same underlying semantic. That can't be right. Should it be this? The UML 1.x model also separated attributes and association ends, even though these are usually different views of the same underlying semantic. 3) As a separate question: could you go with this? The UML 1.x model also separated attributes and associations, even though these are usually different views of the same underlying semantic. This text is only a discussion, so i don't want to push this suggestion. But attributes and associations do not (necessarily) have the same meaning. 4) It is less appropriate for relational applications and derived associations, which expect that the navigation of an association does not necessarily modify the source class of the navigabilitytion. 5) However, this prevents navigation from both teachers and courses, or at least does not require it in the generated implementation. How about: However, this declares that the association is not navigable from teachers nor from courses, or at least does not require support for navigability in the generated implementation. Or even better: However, this declares that the association is not navigable from teachers nor from courses. To: Edwin Seidewitz Cc: "'conrad.bock@nist.gov'" , "'mof2xmi-ftf@omg.org'" , "'mu2i-ftf@omg.org'" , "'uml2-superstructure-ftf@omg.org'" Subject: RE: , cl, Issues 6242 (Association not affecting ends), 6460 (de finition of navigation), proposed resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 27 May 2004 18:33:01 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 05/27/2004 18:33:06, Serialize complete at 05/27/2004 18:33:06 On a separate topic related to OCL style, and prompted by Ed's comment: > I would note, though, that the resolution to Issue 6242 should include > changing constraint 4 of ReadLinkAction (Section 11.3.28) to replace > "isNavigable = #true" with "isNavigable()". A search of the document seems > to indicate that this is the only current reference to "isNavigable" I learned early in my computing practice that checks of Booleans of the form: (isNavigable = #true) //where isNavigable is a Boolean are redundant, because it is sufficient to say: isNavigable to get the same effect. I am surprised how many experts still make this elementary mistake. There are numerous instances of it in the OCL in the spec. Ed, of course, got it right. Bran OMG Issue No: 6243 Title: Association not affecting ends Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Restore UML 1.x capability of modeling associations without modifying the end types. This is needed for database modeling, for profiles to be used with fixed-schema repositories, and is the differentiator of UML over OWL, etc. Discussion: Summary The intent of this resolution is to harmonize the relational (UML 1.x) and object-oriented (UML 2) viewpoints in modeling associations, properties, and navigability. It recommends separating ownership and navigation, while preserving the other beneficial aspects of the UML 2 model, in particular, the unification of properties and association ends. The changes provide more flexiblity than both UML 1.x and 2.0 in modeling commonly needed combinations of navigability and ownership. Comparing UML 1.x and UML 2: UML 1.x supported the specification of associations without modifying the classes being associated. Association ends were always owned by the association, regardless of the navigability of the association. The model was most appropriate for relational applications such as databases, hash tables, SmallTalk dictionaries, and predicate logic, and was useful when the classes being associated should not be modified for some reason, such as using a read-only model, or derived associations. It was less appropriate for object-oriented applications, which expected that specifying navigation of an association would modify the source class of the navigation by defining an attribute on it to support runtime traversal from instances of the class. The UML 1.x model also separated attributes and associations, even though these are usually different views of the same underlying semantic. UML 2 requires modification of the classes being associated in common cases. In particular, it requires that an association end (modeled as a property) be owned by the end classes when it is the source of navigation. The model is most appropriate for object-oriented or record-based applications, and supports supports class diagrams and composite structure diagrams as views on a single underlying model. It is less appropriate for relational applications and derived associations, which expect that the navigation of an association does not necessarily modify the source class of the navigation. Example: Suppose we model an association of teachers to courses like this: In UML 2 this means: For the relational modeler, the above will normally imply a column in the Teacher table, even when this is not desired. Instead, the modeler might want an intersection/correlation table, which in effect puts the columns on the association. UML 2 offers this solution to have the association own properties for teacher and course: However, this prevents navigation from both teachers and courses, or at least does not require it in the generated implementation. The modeler probably wants the compiler to generate an API or other means for querying a course for its teacher. The model must be refined to: This again has the undesired effect of an attribute on Teacher, because the current specification does not indicate that derived associations should not affect the end classes. In addition, it is a detailed model more appropriate for the late design stage, rather than early as in the first example figure. And a late stage model might migrate the column across to the other end, to prevent repeated groups and normalize the database: These examples shows that navigability in relational modeling is a requirement for query services, rather than property ownership. The model should indicate it is possible at runtime to get courses given a teacher, rather than indicate Teacher has a course property. Proposed changes: In Figure 73: Add association between Property and Association that identifies the owned ends that are navigable, called navigableOwnEnd, specialized from ownedEnd: In Infrastructure, Association class, section 11.3.1: In Description section: Replace second paragraph with: .An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the opposite ends.. In Associations section: ownedEnd entry, delete "non-navigable". Add navigableOwnedEnd attribute: navigableOwnedEIn Semantics section: First paragraph, replace second sentence with: .When related to an association via memberEnd or one of its specializations, it represents an end of the association.. Ninth paragraph, after "If a navigable property", delete "(attribute)". In MOF 2 Core: Section 15.2 (MOF Instances Model), under Link Slot, p 59, remove "(it is owned by a Class)". Section 16.1 (Migration from MOF 1.4): under Association End, in the right column, remove the second sentence "If the property is owned by the association, it is not navigable (no reference is referencing it)." Disposition: Resolved OMG Issue No: 6243 Title: Association not affecting ends Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Restore UML 1.x capability of modeling associations without modifying the end types. This is needed for database modeling, for profiles to be used with fixed-schema repositories, and is the differentiator of UML over OWL, etc. Discussion: Summary The intent of this resolution is to harmonize the relational (UML 1.x) and object-oriented (UML 2) viewpoints in modeling associations, properties, and navigability. It recommends separating ownership and navigation, while preserving the other beneficial aspects of the UML 2 model, in particular, the unification of properties and association ends. The changes provide more flexiblity than both UML 1.x and 2.0 in modeling commonly needed combinations of navigability and ownership. Comparing UML 1.x and UML 2: UML 1.x supported the specification of associations without modifying the classes being associated. Association ends were always owned by the association, regardless of the navigability of the association. The model was most appropriate for relational applications such as databases, hash tables, SmallTalk dictionaries, and predicate logic, and was useful when the classes being associated should not be modified for some reason, such as using a read-only model, or derived associations. It was less appropriate for object-oriented applications, which expected that the specifying navigation of an association would modify the source class of the navigation by defining an attribute on it to support runtime traversal from instances of the class. The UML 1.x model also separated attributes and associations, even though these are usually different views of the same underlying semantic. UML 2 requires modification of the classes being associated in common cases. In particular, it requires that an association end (modeled as a property) be owned by the end classes when it is the source of navigation. The model is most appropriate for object-oriented or record-based applications, and supports supports class diagrams and composite structure diagrams as views on a single underlying model. It is less appropriate for relational applications and derived associations, which expect that the navigation of an association does not necessarily modify the source class of the navigation. Example: Suppose we model an association of teachers to courses like this: In UML 2 this means: For the relational modeler, the above will normally imply a column in the Teacher table, even when this is not desired. Instead, the modeler might want an intersection/correlation table, which in effect puts the columns on the association. UML 2 offers this solution to have the association own properties for teacher and course: However, this prevents navigation from both teachers and courses, or at least does not require it in the generated implementation. The modeler probably wants the compiler to generate an API or other means for querying a course for its teacher. The model must be refined to: This again has the undesired effect of an attribute on Teacher, because the current specification does not indicate that derived associations should not affect the end classes. In addition, it is a detailed model more appropriate for the late design stage, rather than early as in the first example figure. And a late stage model might migrate the column across to the other end, to prevent repeated groups and normalize the database: These examples shows that navigability in relational modeling is a requirement for query services, rather than property ownership. The model should indicate it is possible at runtime to get courses given a teacher, rather than indicate Teacher has a course property. Proposed changes: In Figure 30: Add association between Property and Association that identifies the owned ends that are navigable, called navigableOwnEnd, specialized from ownedEnd: In Association class, section 7.11.2: In Description section: Replace second paragraph with: .An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the opposite ends.. In Associations section: ownedEnd entry, delete "non-navigable". Add navigableOwnedEnd attribute: navigableOwnedEnd : Property [*] The navigable ends that are owned by the association itself. Subsets Association.ownedEnd. In Constraints section add new constraint: Association ends of associations with more than two ends must be owned by the association. if memberEnd->size() > 2 then ownedEnd->includesAll(memberEnd) In Semantics section: Delete the sentence .The semantics of navigable association ends are the same as for attributes. In Examples section: Replace paragraph above Figure 34 with: "Figure 34 shows that the attribute notation can be used for an association end owned by a class, because an association end owned by a class is also an attribute. This notation may be used in conjunction with the line-arrow notation to make it perfectly clear that the attribute is also an association end." Change caption of Figure 34 to "Example of attribute notation for navigable end owned by an end class." In Property class, section 7.11.4: Replace second two paragraphs with: .A property related to a class by ownedAttribute represents an attribute, and might also represent an association end. It relates an instance of the class to a value or set of values of the type of the attribute.. .A property related to an association by memberEnd or its specializations represents an end of the association. The type of the property is the type of the end of the association.. In Constraints section: Replace rule 4 with: [4] A navigable property can only be redefined or subsetted by a navigable property. (subsettedProperty->exists(sp | sp.isNavigable() implies isNavigable()) and (redefinedProperty->exists(rp | rp.isNavigable implies isNavigable()) Replace rule 6 with: [6] Only a navigable property can be marked as readOnly. isReadOnly implies isNavigable() Add Additional Operations section after Constraints containing: [1] The query isNavigable indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean IsNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) In Semantics section: First paragraph, replace second sentence with: .When related to an association via memberEnd or one of its specializations, it represents an end of the association.. Ninth paragraph, after "If a navigable property", delete "(attribute)". In ReadLinkAction class, Constraints, in OCL of constraint [4], replace .isNavigable = #true. with .isNavigable().. Disposition: Resolved