Issue 15890: New notation for attribute (uml2-rtf) Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com) Nature: Uncategorized Issue Severity: Summary: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the link notation Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Resolution: Revised Text: Actions taken: December 10, 2010: received issue Discussion: End of Annotations:===== m: "BERNARD, Yves" To: "uml2-rtf@omg.org" Date: Fri, 10 Dec 2010 13:01:16 +0100 Subject: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wA== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Rouquette, Nicolas F (316A)" To: "BERNARD, Yves" CC: "uml2-rtf@omg.org" Date: Sat, 11 Dec 2010 11:58:35 -0800 Subject: Re: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcuZbcxbIwcBvtSeTmCufcIGZzOLcg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Steve Cook To: "Rouquette, Nicolas F (316A)" , "BERNARD, Yves" CC: "uml2-rtf@omg.org" Subject: RE: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wABC9hSAACGMH8A= Date: Sun, 12 Dec 2010 11:59:35 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.105] I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: Steve Cook , "Rouquette, Nicolas F (316A)" CC: "uml2-rtf@omg.org" Date: Mon, 13 Dec 2010 08:48:08 +0100 Subject: RE: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wABC9hSAACGMH8AAKQDs4A== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Steve, Thanks, I missed this figure! It.s not clearly said in the text but it seems that the link use a thicker line. It would make senses to avoid confusion with an association. It is said that the link shall be drawn with .no adornment at the tail of the arrow.. Does it mean that the aggregation kind cannot be shown? If so , I think we should enhance this notation. Nicolas, Is it worth to open an issue? Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: dimanche 12 démbre 2010 13:00 To: Rouquette, Nicolas F (316A); BERNARD, Yves Cc: uml2-rtf@omg.org Subject: RE: New notation for attribute I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Rouquette, Nicolas F (316A)" To: "BERNARD, Yves" CC: Steve Cook , "uml2-rtf@omg.org" Date: Mon, 13 Dec 2010 08:05:33 -0800 Subject: Re: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: Acua35LmqqutqO/hQUKxKOwCkcI2cw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Yves, Steve, I agree that there is grounds for a new issue to address 2 points: - clarifying whether aggregation kind can be shown - the notation for association end property attribute should be clearly distinct from that for a property attribute that is not an association end, even for the visually impaired. - Nicolas. On Dec 12, 2010, at 11:48 PM, BERNARD, Yves wrote: Steve, Thanks, I missed this figure! It.s not clearly said in the text but it seems that the link use a thicker line. It would make senses to avoid confusion with an association. It is said that the link shall be drawn with .no adornment at the tail of the arrow.. Does it mean that the aggregation kind cannot be shown? If so , I think we should enhance this notation. Nicolas, Is it worth to open an issue? Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: dimanche 12 démbre 2010 13:00 To: Rouquette, Nicolas F (316A); BERNARD, Yves Cc: uml2-rtf@omg.org Subject: RE: New notation for attribute I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=ZFQH9VM9KergUYe1MnfLUSfnKs9tUGFLd5tEDUPwQkE=; b=a40VEk4oCmlgo0F8Uha+IVseQCD6XNrIa8ZZfHKUqj6UYFh+ySEcpC8eYPgwzCHRrH 0+WNTDfjCMVcVCbxeZREAPXrAjpS7wUrXE6fdhsD4a/jQY+zjIGEqjFEzjhG6yNGcKvv 6j5CTqzmPVrRDncVzJ2GnSNrziX9De21cKpvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=hHKPI+zGrcKYxntKZRTFUpCtAxD3rZ5WkFDhyOmSwHidzvYy3yFRHXfpyB/5xIVM5N 72MVK2wsHkKiz42Us93r6Od2xpi+SCMBBxBo03ugxTSAZD6FB1b4aPgHlIkZ6kgBJlGj CGvtdtFTkumgZ8fys7spuR0Cr2nQ27TYqR/rA= Sender: bran.selic@gmail.com From: Bran Selic Date: Mon, 13 Dec 2010 12:14:27 -0500 X-Google-Sender-Auth: gfFOtQI5X8NwxD0puJrarOhJ0oM Subject: Re: New notation for attribute To: Steve Cook Cc: "Rouquette, Nicolas F (316A)" , "BERNARD, Yves" , "uml2-rtf@omg.org" Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: New notation for attribute Date: Mon, 13 Dec 2010 12:31:51 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: Acua6YiSgI9/Yoq5TF2ah7vmipwVBQAAadiQ From: "Ed Seidewitz" To: "Bran Selic" Cc: "BERNARD, Yves" , Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: New notation for attribute Date: Mon, 13 Dec 2010 09:34:19 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: Acua35LmqqutqO/hQUKxKOwCkcI2cwACb1fw From: "Pete Rivett" To: "Rouquette, Nicolas F (316A)" , "BERNARD, Yves" Cc: "Steve Cook" , What does it mean for an .attribute. to have an aggregation. If class C has a composite property a1 of type Integer, and an instance of C has a1 = 2, then what does that mean? Does that prevent any other instance of C having the a1 = 2? Any other property having the value 2? And what happens if that instance is deleted? The value 2 is deleted? Clearly the above is absurd, but AFAIK that is the only semantics we have for composition. Therefore by Reductio ad Absurdum the concept of composition for such properties should be disallowed. And I can think of no alternative semantics of composition (or aggregation) that would be useful for them. It remains an exercise to determine the exact condition for when aggregation should be disallowed . my initial thought is where the type is a DataType. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, December 13, 2010 8:06 AM To: BERNARD, Yves Cc: Steve Cook; uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, Steve, I agree that there is grounds for a new issue to address 2 points: - clarifying whether aggregation kind can be shown - the notation for association end property attribute should be clearly distinct from that for a property attribute that is not an association end, even for the visually impaired. - Nicolas. On Dec 12, 2010, at 11:48 PM, BERNARD, Yves wrote: Steve, Thanks, I missed this figure! It.s not clearly said in the text but it seems that the link use a thicker line. It would make senses to avoid confusion with an association. It is said that the link shall be drawn with .no adornment at the tail of the arrow.. Does it mean that the aggregation kind cannot be shown? If so , I think we should enhance this notation. Nicolas, Is it worth to open an issue? Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: dimanche 12 démbre 2010 13:00 To: Rouquette, Nicolas F (316A); BERNARD, Yves Cc: uml2-rtf@omg.org Subject: RE: New notation for attribute I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=mURAuUbWW5wyLayYI0cXoqQCtj9Hxm6redmqFI9gtNk=; b=MVrCNwu5nDphc6+4Ckf1YGCvd+D0jtFKOyFVrei2PpQgQd/n8k64YizwoZz38Vwd0/ JXN1vossbYMbrhAmsTY590MQJ3zgqTkTmVJnVA79SsSShKr7cKtAXB2VQl5CeTwfpplM Au61u01QIpwUpO/2dqKG6zRQx2G5GXUsh8l7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=lK4WKvxNCJ53qvkvGwlb3Zo3SsU+UohcaT3Ul9xh+0KOMuKD2mlQn/TKj37ecvGrOV EcG8wqj3m0w1qU0YmTxQk7CMnPKBUF5TsdWzl8fRtQ8XAkZ3/ZsWi7grZa1LuAg5A+TL M2OqB3WwAP7NgwoEqqDZg2/bj9IC4zAbgG8wk= Sender: bran.selic@gmail.com From: Bran Selic Date: Mon, 13 Dec 2010 12:41:54 -0500 X-Google-Sender-Auth: 85wMszsH5wZnB_oKujRlffSMkWs Subject: Re: New notation for attribute To: Ed Seidewitz Cc: "BERNARD, Yves" , uml2-rtf@omg.org ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: New notation for attribute Date: Mon, 13 Dec 2010 12:49:50 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: Acua35LmqqutqO/hQUKxKOwCkcI2cwACb1fwAAD6GXA= From: "Ed Seidewitz" To: "Pete Rivett - Adaptive" , "Rouquette, Nicolas F (316A)" , "BERNARD, Yves" Cc: "Steve Cook" , Pete . The point you bring up is a general one that has come up before, not anything specific to attributes. An association end can also have a data type as its type and a non-association end attribute can have a class as its type. Currently any property may have shared or composite aggregation, though, as you say, it is not always clear what this means semantically. The usual response is to simply say that aggregation is ignored for properties whose types are immutable, but I agree that this is not entirely satisfactory. This also relates to the discussion around whether an immutable data value has .identity. or not. For example, does the numeral .2. always represent the same data value 2, or does each such numeral evaluate to a different data value, all of which, however, are .indistinguishable.. The later semantic would resolve the absurdities you pose (and is, in fact, how data values are modeled in the fUML execution model), but it is not particularly intuitive to most people. -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Monday, December 13, 2010 12:34 PM To: Rouquette, Nicolas F (316A); BERNARD, Yves Cc: Steve Cook; uml2-rtf@omg.org Subject: RE: New notation for attribute What does it mean for an .attribute. to have an aggregation. If class C has a composite property a1 of type Integer, and an instance of C has a1 = 2, then what does that mean? Does that prevent any other instance of C having the a1 = 2? Any other property having the value 2? And what happens if that instance is deleted? The value 2 is deleted? Clearly the above is absurd, but AFAIK that is the only semantics we have for composition. Therefore by Reductio ad Absurdum the concept of composition for such properties should be disallowed. And I can think of no alternative semantics of composition (or aggregation) that would be useful for them. It remains an exercise to determine the exact condition for when aggregation should be disallowed . my initial thought is where the type is a DataType. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, December 13, 2010 8:06 AM To: BERNARD, Yves Cc: Steve Cook; uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, Steve, I agree that there is grounds for a new issue to address 2 points: - clarifying whether aggregation kind can be shown - the notation for association end property attribute should be clearly distinct from that for a property attribute that is not an association end, even for the visually impaired. - Nicolas. On Dec 12, 2010, at 11:48 PM, BERNARD, Yves wrote: Steve, Thanks, I missed this figure! It.s not clearly said in the text but it seems that the link use a thicker line. It would make senses to avoid confusion with an association. It is said that the link shall be drawn with .no adornment at the tail of the arrow.. Does it mean that the aggregation kind cannot be shown? If so , I think we should enhance this notation. Nicolas, Is it worth to open an issue? Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: dimanche 12 démbre 2010 13:00 To: Rouquette, Nicolas F (316A); BERNARD, Yves Cc: uml2-rtf@omg.org Subject: RE: New notation for attribute I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: New notation for attribute Date: Mon, 13 Dec 2010 12:55:25 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: Acua7RUsgacyGA+hTtmrAofUTnDlrAAAUZUw From: "Ed Seidewitz" To: "Bran Selic" Cc: "BERNARD, Yves" , Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Steve Cook To: Ed Seidewitz , Bran Selic CC: "BERNARD, Yves" , "uml2-rtf@omg.org" Subject: RE: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wABC9hSAACGMH8AAPU2egAAAm5KAAABZ2gAAAHjagAAAM89w Date: Mon, 13 Dec 2010 18:08:51 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.92] I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: New notation for attribute Date: Mon, 13 Dec 2010 13:20:43 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wABC9hSAACGMH8AAPU2egAAAm5KAAABZ2gAAAHjagAAAM89wAAB62EA= From: "Ed Seidewitz" To: "Steve Cook" , "Bran Selic" Cc: "BERNARD, Yves" , Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Steve Cook To: Ed Seidewitz , Bran Selic CC: "BERNARD, Yves" , "uml2-rtf@omg.org" , "Andrew Watson (andrew@omg.org)" Subject: RE: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wABC9hSAACGMH8AAPU2egAAAm5KAAABZ2gAAAHjagAAAM89wAAB62EAAANxJoA== Date: Mon, 13 Dec 2010 18:49:06 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.92] Ed Maged has control of the documents and would have to be persuaded to redo the framemaker if you feel this is really important. Also I think we need Andrew.s advice on whether it is procedurally in order to change this diagram at this point. As for constituencies, the submitters of UML 2.5 have a choice here, and I am certain about where my vote goes. I don.t believe it is necessary to satisfy everybody. Trying to satisfy everybody is one of the reasons why UML 2 is like it is. We have voting procedures. Let.s use them. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 18:21 To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=1+kwPpFianoLkQ/WtyEqERAmwGdoeKKR77vsZaunSv8=; b=DMVGTzec2ZXXHUNg1C8AHZt3zMx32Lpuf2CVNPEaHzMjRPwDCjUGCrW3LDAUosmx55 vKA+4wQi5MhvalXM/7B08I3fB3lUwHL5VJadERASn6OZBoqootaBX1HGouS+OuXxYAr/ pi1Q9H5aLXllLNvffgact1x7ebXDMAog8nPkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=ccQmY7oTyRh6qEoYftvm2E9NDswqCfZWYE60A0wDjetGzNINs2W55SX7RlBEmNbEdf 87+6BtaRAPDAJeLO9K3cmHpxH8Gf+spOb/8defcGAVNcJDSz3frDGnF4Q1vDvFpUFJ3W scfDVTW3PIL5Q9l4YnXilLOTofWqhKwLc0lnA= Sender: bran.selic@gmail.com From: Bran Selic Date: Mon, 13 Dec 2010 14:34:13 -0500 X-Google-Sender-Auth: wN2DaZn284Z2PZobGYqhSgnobFc Subject: Re: New notation for attribute To: Steve Cook Cc: Ed Seidewitz , "BERNARD, Yves" , "uml2-rtf@omg.org" , "Andrew Watson (andrew@omg.org)" Can someone remind me why we need the navigability concept at all? The text already says, in several places, that it is a deprecated concept especially given that it is impossible to define precisely (something about "efficient" navigation at run time...). So, if we eliminated this useless concept, we could go back to using the arrow to mean what most people thought it meant anyway. My experience with many different UML users and instructors is that most of them are completely unaware of it. Even when they are, they almost invariably have to go to the manual to figure out where to put it (interpret that last phrase as you choose). Cheers...Bran On Mon, Dec 13, 2010 at 1:49 PM, Steve Cook wrote: Ed Maged has control of the documents and would have to be persuaded to redo the framemaker if you feel this is really important. Also I think we need Andrew.s advice on whether it is procedurally in order to change this diagram at this point. As for constituencies, the submitters of UML 2.5 have a choice here, and I am certain about where my vote goes. I don.t believe it is necessary to satisfy everybody. Trying to satisfy everybody is one of the reasons why UML 2 is like it is. We have voting procedures. Let.s use them. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 18:21 To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: New notation for attribute Date: Mon, 13 Dec 2010 12:09:50 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wABC9hSAACGMH8AAPU2egAAAm5KAAABZ2gAAAHjagAAAM89wAAB62EAAAGb8cA== From: "Pete Rivett" To: "Ed Seidewitz" , "Steve Cook" , "Bran Selic" Cc: "BERNARD, Yves" , I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Rouquette, Nicolas F (316A)" To: Pete Rivett CC: Ed Seidewitz , Steve Cook , Bran Selic , "BERNARD, Yves" , "uml2-rtf@omg.org" Date: Mon, 13 Dec 2010 18:39:18 -0800 Subject: Re: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcubOBxoxuc5WFFGT3ioruwz6FryeA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: "Rouquette, Nicolas F (316A)" , Pete Rivett CC: Ed Seidewitz , Steve Cook , Bran Selic , "uml2-rtf@omg.org" Date: Tue, 14 Dec 2010 08:59:36 +0100 Subject: RE: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcubOBxoxuc5WFFGT3ioruwz6FryeAAKPP5w Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability. is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability. concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like. notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "DESFRAY Philippe" To: "'BERNARD, Yves'" , "'Rouquette, Nicolas F \(316A\)'" , "'Pete Rivett'" Cc: "'Ed Seidewitz'" , "'Steve Cook'" , "'Bran Selic'" , Subject: RE: New notation for attribute Date: Tue, 14 Dec 2010 10:59:53 +0100 Organization: Softeam X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcubOBxoxuc5WFFGT3ioruwz6FryeAAKPP5wAARlL1A= X-Softeam-fr-MailScanner-ID: 4FF7563A5156.AD07F X-Softeam-fr-MailScanner: Found to be clean X-Softeam-fr-MailScanner-SpamCheck: n'est pas un polluriel (inscrit sur la liste blanche), SpamAssassin (not cached, score=2.024, requis 3.5, ALL_TRUSTED -1.80, BAYES_50 0.00, HTML_MESSAGE 0.00, HTML_TAG_BALANCE_BODY 1.26, MPART_ALT_DIFF_COUNT 1.11, MSGID_MULTIPLE_AT 1.45) X-Softeam-fr-MailScanner-From: philippe.desfray@softeam.fr X-Spam-Status: No I violently disagree with this discussion. The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability. is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability. concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like. notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: DESFRAY Philippe , "'Rouquette, Nicolas F (316A)'" , "'Pete Rivett'" CC: "'Ed Seidewitz'" , "'Steve Cook'" , "'Bran Selic'" , "uml2-rtf@omg.org" Date: Tue, 14 Dec 2010 11:33:23 +0100 Subject: RE: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcubOBxoxuc5WFFGT3ioruwz6FryeAAKPP5wAARlL1AAAPTqkA== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Philippe, It seems that our disagreement is not so violent.. Let me first underline that I.m a .UML end user., myself. I.m no more than you in favor of the .dot. notation, no more than SysML folks who do not retain it. Our point is not to drop the .arrow notation. but clarify the corresponding semantics. You say that the navigability as currently defined in the UML specification is .imprecise. and then we say the same thing. The point where we might disagree is that I understand the concept of ownership as not purely related to the physical aspect: to me, it has impact on the logical one as well. Yves From: DESFRAY Philippe [mailto:philippe.desfray@softeam.fr] Sent: mardi 14 démbre 2010 11:00 To: BERNARD, Yves; 'Rouquette, Nicolas F (316A)'; 'Pete Rivett' Cc: 'Ed Seidewitz'; 'Steve Cook'; 'Bran Selic'; uml2-rtf@omg.org Subject: RE: New notation for attribute I violently disagree with this discussion. The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. From: "BERNARD, Yves" To: DESFRAY Philippe , "'Rouquette, Nicolas F (316A)'" , "'Pete Rivett'" CC: "'Ed Seidewitz'" , "'Steve Cook'" , "'Bran Selic'" , "uml2-rtf@omg.org" Date: Tue, 14 Dec 2010 11:33:23 +0100 Subject: RE: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcubOBxoxuc5WFFGT3ioruwz6FryeAAKPP5wAARlL1AAAPTqkA== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Philippe, It seems that our disagreement is not so violent.. Let me first underline that I.m a .UML end user., myself. I.m no more than you in favor of the .dot. notation, no more than SysML folks who do not retain it. Our point is not to drop the .arrow notation. but clarify the corresponding semantics. You say that the navigability as currently defined in the UML specification is .imprecise. and then we say the same thing. The point where we might disagree is that I understand the concept of ownership as not purely related to the physical aspect: to me, it has impact on the logical one as well. Yves From: DESFRAY Philippe [mailto:philippe.desfray@softeam.fr] Sent: mardi 14 démbre 2010 11:00 To: BERNARD, Yves; 'Rouquette, Nicolas F (316A)'; 'Pete Rivett' Cc: 'Ed Seidewitz'; 'Steve Cook'; 'Bran Selic'; uml2-rtf@omg.org Subject: RE: New notation for attribute I violently disagree with this discussion. The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability. is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability. concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like. notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Rouquette, Nicolas F (316A)" To: DESFRAY Philippe CC: "BERNARD, Yves" , Pete Rivett , Ed Seidewitz , Steve Cook , Bran Selic , "uml2-rtf@omg.org" Date: Tue, 14 Dec 2010 03:06:07 -0800 Subject: Re: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcubfulVvXDlOc0jRYKXecuyRNd1JQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability. is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability. concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like. notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Steve Cook To: "Rouquette, Nicolas F (316A)" , "DESFRAY Philippe" CC: "BERNARD, Yves" , Pete Rivett , Ed Seidewitz , Bran Selic , "uml2-rtf@omg.org" Subject: RE: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wAAKPP5wALqwGoAAAlAsgAACAE6w Date: Tue, 14 Dec 2010 12:43:03 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] Today UML has several different ill-defined ways to express asymmetry of an association. 1. The .white diamond., shared aggregation. The spec admits that this has no well-defined semantics. 2. The arrowhead for navigability. The semantics are .efficient access.. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. 3. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. .Ownership. in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. .Ownership. implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an .end. property on the generated class ConnectableElement, so it must be a .navigable. property, and because navigable is .deprecated. in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability. is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability. concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like. notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: Re: New notation for attribute From: "Ed Seidewitz" Date: Tue, 14 Dec 2010 08:06:45 -0500 Thread-Topic: New notation for attribute Thread-Index: Acubj8ZgbmgT0ENkSUSCuX+3tSrnBQ== To: "Rouquette, Nicolas F (316A)" Cc: "DESFRAY Philippe" , "BERNARD, Yves" , "Pete Rivett" , "Steve Cook" , "Bran Selic" , Nicolas -- Note that your option (b) is not actually possible in UML. Currently, class ownership of an end always implies navigability. Thus if the unmarked end is owned by the opposite class it would be navigable and the association would be bidirectional. Ed Sent from my iPhone On Dec 14, 2010, at 6:06 AM, "Rouquette, Nicolas F (316A)" wrote: Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of thatt end, . tthe marked association end is owned by the classifier, and . the oppposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The âdotâ notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the directtion of that end, . the marked association end is owned by the classsifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end userâs modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé : mardi 14 décembre 2010 09:00 à : Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what ânavigabilityâ is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a ânavigabilityâ concept (assuming it is clear in their minds) might create a stereotype. Anyway, thatâs a separate issue and except if Iâm wrong, itâs already registered. Iâm going to open a separate one for the âassociation-likeâ notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 décembre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling.> What does it mean to say that itâs not possible (âefficientlyâ) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? Thatâs not to say navigability has no value for other types of model. I donât feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since itâ.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since itâs the end ownership that determines seerialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the âdot on the wrong endâ is the right way to show an attribute using âassociation-like notationâ, which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I donât think it has), I donât think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Iâve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I donât believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 âto show dot-notationâ. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I donât see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the âlink notationâ · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. To: Steve Cook Cc: Ed Seidewitz , "Rouquette, Nicolas F (316A)" , Pete Rivett , "DESFRAY Philippe" , Bran Selic , "uml2-rtf@omg.org" , "BERNARD, Yves" Subject: RE: New notation for attribute X-KeepSent: 3B21C017:2C19F86E-852577F9:0047BF70; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: Jim Amsden Date: Tue, 14 Dec 2010 06:22:09 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 12/14/2010 06:22:12, Serialize complete at 12/14/2010 06:22:12 X-Content-Scanned: Fidelis XPS MAILER I agree with both Steve and Philippe on this. The history derives from the EMOF/CMOF discussions. EMOF didn't have associations but rather had properties whose types could be either primitive (representing an attribute) or some non-primitive type (representing a navigable association). This is similar to RDF where the object in Subject Predicate Object can either be a primitive type or a reference to another object. Property::opposite was introduced to support a closed relationship loop between two classes (navigating from one to the other and back results in the original instance). EMOF made not distinguish between attribute and association notation - they are different notations depicting the same concept. Which one to use is a user preference. CMOF introduced associations to explicitly model relationships between classes as something separate from properties. Then the issue arose about which element "owns" the properties corresponding to the association ends - the associated classes (to be consistent with EMOF) or the association (to decouple the related classes) or both based on conventions for navigability, or the new concept of explicit property ownership. UML Superstructure adds AssociationClass to provide attributes on the association (even though an Association is a Class and can already have attributes - but there was no notation for this). The argument for property ownership as something separate from navigability was based on: 1. decoupling classes and supporting change management (adding a relationship without changing the related classes) 2. supporting a means of denoting property access across associations that should be "efficient" based possibly on some implementation(s) 3. supporting explicit modeling of relational tables that have to flip property ownership/navigability for normalized foreign keys I believe this is a good example of introducing unnecessary concerns into the modeling language that resulted in unneeded complexity. The logical notion of property and association should have either been simple as in EMOF, or attributes and associations should have been clearly distinguished and separate as in CMOF. We should not have done both. Navigability would then be semantically meaningful in terms of the relationship itself. Issues of XMI generation, efficient access or object/relational mapping and property ownership should have been left to mappings and implementations. I would be strongly in favor of removing the dot notation - it is little understood, infrequently used, and not needed. Jim Amsden, Senior Technical Staff Member Unleash the Labs Solution Architect for Rational EA and ADC Tools Make a new ULL Request 919-461-3689 From: Steve Cook To: "Rouquette, Nicolas F (316A)" , "DESFRAY Philippe" Cc: "BERNARD, Yves" , Pete Rivett , Ed Seidewitz , Bran Selic , "uml2-rtf@omg.org" Date: 12/14/2010 07:48 AM Subject: RE: New notation for attribute -------------------------------------------------------------------------------- Today UML has several different ill-defined ways to express asymmetry of an association. 1. The âwhite diamondâ, shared aggregation. The spec admits that this has no well-defined semantics. 2. The arrowhead for navigability. The semantics are âefficient accessâ. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. 3. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. âOwnershipâ in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. âOwnershipâ implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an âendâ property on the generated class ConnectableElement, so it must be a ânavigableâ property, and because navigable is âdeprecatedâ in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is nnavigable in the direction of that end, . the marked associationn end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The âdotâ notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navvigable in the direction of that end, . the marked association eend is owned by the classifier, and . the opposite (unmarked) asssociation end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end userâs modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé : mardi 14 décembre 2010 09:00 à : Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what ânavigabilityâ is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a ânavigabilityâ concept (assuming it is clear in their minds) might create a stereotype. Anyway, thatâs a separate issue and except if Iâm wrong, itâs already registered. Iâm going to open a separate one for the âassociation-likeâ notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 décembre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically ffor metamodeling. What does it mean to say that itâs not possible (âefficientlyâ) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? Thatâs not to say navigability has no value for other types of model. I donât feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since iitâs redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since ittâs the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the âdot on the wrong endâ is the right way to show an attribute using âassociation-like notationâ, which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I donât think it has), I donât think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Iâve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I donât believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 âto show dot-notationâ. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I aggree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I donât see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the âlink notationâ · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "DESFRAY Philippe" To: "'Rouquette, Nicolas F \(316A\)'" Cc: "'BERNARD, Yves'" , "'Pete Rivett'" , "'Ed Seidewitz'" , "'Steve Cook'" , "'Bran Selic'" , Subject: RE: New notation for attribute Date: Tue, 14 Dec 2010 14:33:58 +0100 Organization: Softeam X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcubfulVvXDlOc0jRYKXecuyRNd1JQADEi3w X-Softeam-fr-MailScanner-ID: CED7D63A5156.ADAFB X-Softeam-fr-MailScanner: Found to be clean X-Softeam-fr-MailScanner-SpamCheck: n'est pas un polluriel (inscrit sur la liste blanche), SpamAssassin (not cached, score=2.024, requis 3.5, ALL_TRUSTED -1.80, BAYES_50 0.00, HTML_MESSAGE 0.00, HTML_TAG_BALANCE_BODY 1.26, MPART_ALT_DIFF_COUNT 1.11, MSGID_MULTIPLE_AT 1.45) X-Softeam-fr-MailScanner-From: philippe.desfray@softeam.fr X-Spam-Status: No Nicolas, Your description is far better than what currently exists. Regarding the ownership rules, I have no strong opinion. I tend to think that .C. is the most convenient: association is by itself an important and autonomous notion: UML2 has promoted it to be a kind of Class. In addition, changing the ownership when some adornments are changed is a bit weird. May be the only case in the UML metamodel. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Envoyé mardi 14 démbre 2010 12:06 À: DESFRAY Philippe Cc : BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability. is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability. concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like. notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Steve Cook To: "george.ericson@emc.com" , "nicolas.f.rouquette@jpl.nasa.gov" , "philippe.desfray@softeam.fr" CC: "Yves.Bernard@airbus.com" , "pete.rivett@adaptive.com" , "ed-s@modeldriven.com" , "selic@acm.org" , "uml2-rtf@omg.org" Subject: RE: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wAAKPP5wALqwGoAAAlAsgAACAE6wAAI0pr8AAaarcA== Date: Tue, 14 Dec 2010 14:08:45 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] George You are right: in addition to what I wrote about end ownership, it would be invalid to allocate a slot to an InstanceSpecification corresponding to a property that its classifier does not own. The link notation for InstanceSpecification has no corollary to the blob notation. You can show navigability, which would imply ownership of the slot by the instance at the other end, but not showing navigability implies nothing. -- Steve From: george.ericson@emc.com [mailto:george.ericson@emc.com] Sent: 14 December 2010 13:07 To: Steve Cook; nicolas.f.rouquette@jpl.nasa.gov; philippe.desfray@softeam.fr Cc: Yves.Bernard@airbus.com; pete.rivett@adaptive.com; ed-s@modeldriven.com; selic@acm.org; uml2-rtf@omg.org Subject: Re: New notation for attribute Useful summary. I had thought, perhaps naively, that ownership told me what classifier, (or if), a slot for the property should be allocated to.. I had not known of your use. In our use with the dmtf common information model, ifDeleted semantics are expressed explictly via a qualifier. -------------------------------------------------------------------------------- From: Steve Cook To: Rouquette, Nicolas F (316A) ; DESFRAY Philippe Cc: BERNARD, Yves ; Pete Rivett ; Ed Seidewitz ; Bran Selic ; uml2-rtf@omg.org Sent: Tue Dec 14 07:43:03 2010 Subject: RE: New notation for attribute Today UML has several different ill-defined ways to express asymmetry of an association. 1. The .white diamond., shared aggregation. The spec admits that this has no well-defined semantics. 2. The arrowhead for navigability. The semantics are .efficient access.. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. 3. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. .Ownership. in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. .Ownership. implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an .end. property on the generated class ConnectableElement, so it must be a .navigable. property, and because navigable is .deprecated. in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association iis navigable in the direction of that end, . the marked aassociation end is owned by the classifier, and . the oppposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of thaat end, . the marked association end is owned by the classsifier, and . the opposite (unmarked) association end iss owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability. is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability. concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like. notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no ssense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines seriallization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran .< You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is inddeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran .> I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=v2DgrfvtYp4TNOD2tR09S24jNmuMQGj6m7AFm6wwiJk=; b=C//kxn3PMa/kHM4N9+rZDmbZ6kk6QeEIKY0rgtcTEHuw5Akqw/o5RBUxbcsnXB/r8I pq4fUgGCppQYgLQPIFcPZIjBr40D/oUr8wNAFugeE48lIb+EakkDyRc+R0VKXL8bJk4L UFNdfBsWR86pyOvV+dbaezcrOYuI5sd3ViCoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=LhD5eiqUJJZI39n50JMrTBwkd5E+FutQrvEcUWc/P62u487kL3hRUKLYk3fEC/3K/J CMICxUZYJNHWBWCYm+OML5UtTUGS1UlCdYyMrSIQGf4mVsoOkhj/TrEs+gC8CFosDNmy AdqYnvxZ6TE6ra0KZ59M6DDob0bOzowmFkF1c= Sender: bran.selic@gmail.com From: Bran Selic Date: Tue, 14 Dec 2010 10:12:45 -0500 X-Google-Sender-Auth: FrN-Q8IcLjBGyIQ-rZ8PRsEqcDI Subject: Re: New notation for attribute To: DESFRAY Philippe Cc: "BERNARD, Yves" , "Rouquette, Nicolas F (316A)" , Pete Rivett , Ed Seidewitz , Steve Cook , uml2-rtf@omg.org Hi Philippe, Since I started the "navigability is useless" movement, I feel compelled to respond: On Tue, Dec 14, 2010 at 4:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. [bvs] If we are going to get violent, we have to put an "adults only" rating in the subject The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? [bvs] I guess we agree on the inappropriateness of the dot notation. (I only wish more RTF members had thought the same when we had a vote on it back in UML 2.1.) However, I disagree with the suggestion that this was done without care for end users. The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. [bvs] But, this fragment of text is not part of the definition of navigability. It is an explanatory note on the conventions used inside the document. It was to have been removed once we updated all the diagrams. (At the time, we had no tools that supported it.) The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. [bvs] I remind you again, this is not part of the definition of navigability, it was only used to explain what was intended to be a temporary situation in how the document was written. I really think this is irrelevant to the discussion. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. [bvs] Indeed many of them. However, in my experience, the vast majority used them to represent the fact that the classifier at the opposite end of the arrow had some kind of direct reference ("knowledge of"?) to the classifier at the near end of the arrow. The "plumbing" part is how this is realized -- usually it means that the classifier included a feature typed by the referenced classifier. In fact, I claim that this is how most people interpreted it -- they don't care a hoot about navigability. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language [bvs] You say "to me". But, that is part of the problem: as currently defined, others have equal rights to interpret it differently. What does it mean to "favour" a direction? My point is that such a vague concept is probably best handled by a profile. In a way, the white diamond notation suffers from the same problem. I wish we had not included it either since I have seen no end of confusion that it causes. [bvs] But, please note that I am not arguing against the arrow notation: on the contrary. I am all for it, but I want it to have a precise meaning. That meaning is that the classifier end has a feature of the type pointed to by the arrow. The "plumbing" part, as you call it, is the detail that it is an association end that is owned by the classifier. However, although this detail is included in the spec (as it should be), users need not worry about that. [bvs] In summary, while I want to retain the navigability arrow and the logical implication behind it, I want to do it by avoiding vague and ambiguous concepts such as "efficiency". [bvs] So, perhaps we agree after all? Cheers...Bran Date: Tue, 14 Dec 2010 16:00:35 +0000 To: Steve Cook From: Andrew Watson Subject: RE: New notation for attribute Cc: Ed Seidewitz , Bran Selic , "BERNARD, Yves" , "uml2-rtf@omg.org" Steve, Sorry about the delayed reply. You wrote: > Maged has control of the documents and would have to be persuaded to redo > the framemaker if you feel this is really important. Also I think we need > Andrew's advice on whether it is procedurally in order to change this > diagram at this point. > > As for constituencies, the submitters of UML 2.5 have a choice here, and > I am certain about where my vote goes. I don't believe it is necessary to > satisfy everybody. Trying to satisfy everybody is one of the reasons why > UML 2 is like it is. We have voting procedures. Let's use them. No, I'm afraid we can't do this as an editorial change. My working definition of a editorial fix is "something my primary school teacher could find and fix. This isn't. If it needs fixing in a hurry, we have two options: 1. The UML 2.4 RTF exists until Friday 17th. If you can draft a resolution and vote on it before Friday, you can make the change. The RTF would have to issue a revised report, but if absolutely necessary that could be done after Friday, provided the vote finished before the end of Friday. The AB would also have to re-vote it, but that should be a formality. We would then put the new report in the PTC ballot. 2. If the RTF can't do this before Friday, but it is urgent, I could flag it as an urgent issue. With no UML RTF in place, the AB would vote on it. Hope this helps. Cheers, Andrew Subject: RE: New notation for attribute Date: Tue, 14 Dec 2010 09:23:49 -0800 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: AcubkfBo5Y/980R7SLSxstBfIMB/zgAGaKAw From: "Pete Rivett" To: "Jim Amsden" , "Steve Cook" Cc: "Ed Seidewitz" , "Rouquette, Nicolas F (316A)" , "DESFRAY Philippe" , "Bran Selic" , , "BERNARD, Yves" Lots of points to address here. See [PJR] below. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, December 14, 2010 5:22 AM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); Pete Rivett; DESFRAY Philippe; Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: New notation for attribute I agree with both Steve and Philippe on this. The history derives from the EMOF/CMOF discussions. EMOF didn't have associations but rather had properties whose types could be either primitive (representing an attribute) or some non-primitive type (representing a navigable association). This is similar to RDF where the object in Subject Predicate Object can either be a primitive type or a reference to another object. Property::opposite was introduced to support a closed relationship loop between two classes (navigating from one to the other and back results in the original instance). EMOF made not distinguish between attribute and association notation - they are different notations depicting the same concept. Which one to use is a user preference. [PJR] EMOF has no notation . it relies on UML. The questionn is how to interpret that UML. The major problem is that the L0 compliance level of UML that EMOF is based on has been implemented by zero vendors and is to all intents and purposes non-existent. And indeed will be removed completely at UML 2.5. Hence, without the ability for the modeler to say .run in L0 mode. or .treat this as an L0 diagram. the notation is inherently ambiguous as others have pointed out on this thread. All UML tools that I am aware of will create an Association when a user draws a line so we should build on that. CMOF introduced associations to explicitly model relationships between classes as something separate from properties. [PJR] No, CMOF did not introduce this . it.s always been part of UML and mainstream MOF froom day 1 (prior to MOF 2.0 did not have the crippled EMOF without Associations). So it.s more accurate to say that .EMOF removed Associations.. Then the issue arose about which element "owns" the properties corresponding to the association ends - the associated classes (to be consistent with EMOF) or the association (to decouple the related classes) or both based on conventions for navigability, or the new concept of explicit property ownership. UML Superstructure adds AssociationClass to provide attributes on the association (even though an Association is a Class and can already have attributes - but there was no notation for this). [PJR] Association is a Classifier not a Class and as such cannot have ownedAttributes. The argument for property ownership as something separate from navigability was based on: 1. decoupling classes and supporting change management (adding a relationship without changing the related classes) [PJR] Whether the addition of a Property is deemed to .change. the Class at either end is in none of the OMG specs which don.t address the topic at all. It.s certainly not in MOF Versioning/Facility which are the specs that comes closest to any sort of change management. This assumption of change seems based on a certain serialization paradigm . as if models are all naively storred as text files and managed in a text-based versioning/change management system. However even with the naï approach of treating XMI serialization as the storage model, the OMG specs do not dictate how models are serialized across one or more files. And, for the example at hand, there is nothing to force the ownedAttributes of a Class to be serialized in the same XMI file as the Class itself. Overall the current conflation of naming, ownership and deletion semantics is pretty broken and not useful even for metamodeling. Steve Cook gave a good example . where deletion of an Associatiion should delete all its end Properties regardless of whether .owned. by the Class or Association. All UML tools do this as a matter of common sense: but we have no way of specifying something as basic as that in the metamodel! 2. supporting a means of denoting property access across associations that should be "efficient" based possibly on some implementation(s) 3. supporting explicit modeling of relational tables that have to flip property ownership/navigability for normalized foreign keys [PJR] Well until UML 2.4, we didn.t have the notion of any sort of identifier in UML let alone keys (which is essential for relational database modeling): so this argument does not seem to hold. In any case, for metamodels . which sppecify the behavior of modeling, constraint and transformation tools, all such navigations should be .efficient. . hence my argument that navigability has no place foor use in metamodels (i.e. MOF). In other words MOF should have the constraint that all ends are navigable. I believe this is a good example of introducing unnecessary concerns into the modeling language that resulted in unneeded complexity. The logical notion of property and association should have either been simple as in EMOF, or attributes and associations should have been clearly distinguished and separate as in CMOF. We should not have done both. Navigability would then be semantically meaningful in terms of the relationship itself. [PJR] Due to the absence of L0 support, we already have what you call the CMOF approach (which is actually the original UML and MOF approach). So, as per Yves. original request we have no practical means of using the line notation for attributes. Which actually is fine by me . I personally don.t find it useful. But maybe we could introduce a keyword <> to annotate an association. [PJR] Even with the CMOF approach I still don.t see that navigability has any useful semantics . it.s onlyy ever an implementation hint . which rather belongs to markup/profile rather than as something inherent to the language. Issues of XMI generation, efficient access or object/relational mapping and property ownership should have been left to mappings and implementations. [PJR] Agreed . you seem to be supportting my argument that navigability has no semantics. I would be strongly in favor of removing the dot notation - it is little understood, infrequently used, and not needed. [PJR] I disagree: as per my earlier email (and as you yourself seem to be arguing) it.s the concept of navigability that needs to be removed for metamodeling. The dot notation in contrast does have some clear meaning but I agree it.s not of interest to most users. Maybe it would be more appropriate as a stereotype . but surely our metaamodel diagrams are neater and clearer through use of the dot notation than with lots of tags attached to ends. Especially as our tools have now gone to the hassle of supporting it. However that would be mere tinkering . we shoould consider the semantics we actually want to represent (e.g. around naming, deletion and even change management), not be driven by the notation. A final thought linked to the Binding thread . the navigability arrow seems to be a generic notatioonal device which only has a precise meaning when combined with a Binding to some sort of platform. The original UML2.0 spec (and the current section on .how to read the notation in the UML spec.) represent a specific binding to the MOF platform (i.e. a model management meaning). However the fact that this was really a binding was not recognized and, because some people wanted it interpreted differently for other platforms, it was reclaimed it as something vague and the dot notation was introduced for that MOF platform related meaning. Jim Amsden, Senior Technical Staff Member Unleash the Labs Solution Architect for Rational EA and ADC Tools Make a new ULL Request 919-461-3689 From: Steve Cook To: "Rouquette, Nicolas F (316A)" , "DESFRAY Philippe" Cc: "BERNARD, Yves" , Pete Rivett , Ed Seidewitz , Bran Selic , "uml2-rtf@omg.org" Date: 12/14/2010 07:48 AM Subject: RE: New notation for attribute -------------------------------------------------------------------------------- Today UML has several different ill-defined ways to express asymmetry of an association. 1. The .white diamond., shared aggregation. The spec admits that this has no well-defined semantics. 2. The arrowhead for navigability. The semantics are .efficient access.. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. 3. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. .Ownership. in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. .Ownership. implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an .end. property on the generated class ConnectableElement, so it must be a .navigable. property, and because navigable is .deprecated. in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direection of that end, . the marked association end is owned by the classiifier, and . tthe opposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the aassociation is navigable in the direction of that end, . the marked asssociation end is owned by the classifier, and . the opposite (unmarked)) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability. is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability. concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like. notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no ssense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is inddeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Steve Cook To: "juergen@omg.org" Subject: RE: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wABC9hSAACGMH8AAPU2egAAAm5KAAABZ2gAAAHjagAAAM89wAAB62EAAAGb8cAAmTwzAAApHnAAAAJAYEA== Date: Tue, 14 Dec 2010 17:55:08 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] Juergen, we need an emergency last-minute issue for UML 2.4: .Figure 7.31 shows the dot at the wrong end.. From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 14 December 2010 17:50 To: Steve Cook Cc: Maged Elaasar; andrew@omg.org Subject: RE: New notation for attribute No it did not come from me: I think it was Jim or Bran or Ed (see attached). However attached is an updated figure I drew from scratch. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, December 14, 2010 4:44 AM To: Pete Rivett Cc: Maged Elaasar; Andrew Watson (andrew@omg.org) Subject: RE: New notation for attribute Pete . I believe you made that figure. Is it possible to supply a correct one? From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 13 December 2010 20:10 To: Ed Seidewitz; Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: Capability to get a modular diagram thanks to the .link notation. Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: New notation for attribute Date: Tue, 14 Dec 2010 14:04:19 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: AcubkfBo5Y/980R7SLSxstBfIMB/zgAGaKAwAAJQgDA= From: "Ed Seidewitz" To: I think it is useful to recall the history of how we got to the dot notation. But my own recollection is that this history did not have anything directly to do with MOF (which I think is consistent with Pete.s comments below). In UML 1, associations always owned their ends (called .roles. back then). The UML 1 concept of association was strongly influenced by the work of Jim Rumbaugh and Mike Blaha on OO data modeling, in which they argued that associations should be modeled as a peer concept to classes, not simply as the consequence of .referential attributes. on classes. However, UML 1 still included the concept of navigability on an association because, especially for OO design modeling, many people continued to think of associations as directed .references. from one class to another. But this compromise never sat well with many OO practitioners, because it meant that you could .navigate across an association. from a source class that seemed to have no .visibility. of the opposite end of the association. So, in UML 2.0 as submitted, navigability was defined by end ownership: .When a property is owned by a class or data type via ownedAttribute, then it represents an attribute of the class or data type. When owned by an association via ownedEnd, it represents a non-navigable end of the association. (from the beginning of the Semantics section of the description of Property in Subclause 1.11 of ad/03-04-01 . emphasis in the original). There was no concept of .navigable association-owned ends.. However, those who preferred the UML 1 conception of associations now complained. The new UML 2.0 model allowed an association to own all its ends, but, in this case, they were all non-navigable. But this made it seem like you couldn.t navigate at all across the association, and those that viewed association in a more assertional or database sort of way didn.t want to have to make association ends class owned just to get navigability (which is required, for example, to do a read link action on an end). (Conrad Bock was the primary advocate on the FTF of this position, but he was by no means the only person who reviewed the submitted spec who had this position.) As a result, the UML 2.0 FTF decided to allow associations to have navigable owned ends, which provided the ability in UML 2.0 to model associations in the same way as in UML 1.0. But end ownership and navigability did not really become completely .orthogonal., because the constraint that class ownership always implies navigability was retained . which kept the OO folks happy. This change was made in UML 2.0 as finalized, in which (among other things) the two sentences quoted above were changed to .When a property is owned by a classifier other than an association via ownedAttribute, then it represents an attribute of the class or data type. When related to an association via memberEnd or one of its specializations, it represents an end of the association. (from Subclause 7.3.44 of formal/05-07-04), no longer mentioning navigability. It was then noticed in the UML 2.1 RTF that there was no way to graphically notate the difference between a navigable end that is owned by the association from one that is owned by the opposite class. So the dot notation was added in UML 2.1 as an optional way to notate this (as the resolution to Issue 8956). I believe it was Karl Frank who originally proposed this notation. And, while no one particularly liked it, no one could come up with any better notation either, so that was what was adopted. If, as some have suggested, we were to eliminate the concept of navigability, and then use the arrowhead to represent ownership, we would be essentially right back where we were when UML 2.0 started. And we would likely end up coming back full circle in the discussion that lead to the dot notation in the first place. Before we do anything, we need to be sure that we engage again the constituency that wanted navigable association-owned ends in the first place (they are still around!) and address their valid concerns. As is the case with any established product, just about every feature in UML, no matter how obscure, has some constituency! -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, December 14, 2010 12:24 PM To: Jim Amsden; Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); DESFRAY Philippe; Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: New notation for attribute Lots of points to address here. See [PJR] below. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, December 14, 2010 5:22 AM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); Pete Rivett; DESFRAY Philippe; Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: New notation for attribute I agree with both Steve and Philippe on this. The history derives from the EMOF/CMOF discussions. EMOF didn't have associations but rather had properties whose types could be either primitive (representing an attribute) or some non-primitive type (representing a navigable association). This is similar to RDF where the object in Subject Predicate Object can either be a primitive type or a reference to another object. Property::opposite was introduced to support a closed relationship loop between two classes (navigating from one to the other and back results in the original instance). EMOF made not distinguish between attribute and association notation - they are different notations depicting the same concept. Which one to use is a user preference. [PJR] EMOF has no notation . it relies on UML. The question is how to interpret that UML. The major problem is that the L0 compliance level of UML that EMOF is based on has been implemented by zero vendors and is to all intents and purposes non-existent. And indeed will be removed completely at UML 2.5. Hence, without the ability for the modeler to say .run in L0 mode. or .treat this as an L0 diagram. the notation is inherently ambiguous as others have pointed out on this thread. All UML tools that I am aware of will create an Association when a user draws a line so we should build on that. CMOF introduced associations to explicitly model relationships between classes as something separate from properties. [PJR] No, CMOF did not introduce this . it.s always been part of UML and mainstream MOF from day 1 (prior to MOF 2.0 did not have the crippled EMOF without Associations). So it.s more accurate to say that .EMOF removed Associations.. Then the issue arose about which element "owns" the properties corresponding to the association ends - the associated classes (to be consistent with EMOF) or the association (to decouple the related classes) or both based on conventions for navigability, or the new concept of explicit property ownership. UML Superstructure adds AssociationClass to provide attributes on the association (even though an Association is a Class and can already have attributes - but there was no notation for this). [PJR] Association is a Classifier not a Class and as such cannot have ownedAttributes. The argument for property ownership as something separate from navigability was based on: 1. decoupling classes and supporting change management (adding a relationship without changing the related classes) [PJR] Whether the addition of a Property is deemed to .change. the Class at either end is in none of the OMG specs which don.t address the topic at all. It.s certainly not in MOF Versioning/Facility which are the specs that comes closest to any sort of change management. This assumption of change seems based on a certain serialization paradigm . as if models are all naively stored as text files and managed in a text-based versioning/change management system. However even with the naï approach of treating XMI serialization as the storage model, the OMG specs do not dictate how models are serialized across one or more files. And, for the example at hand, there is nothing to force the ownedAttributes of a Class to be serialized in the same XMI file as the Class itself. Overall the current conflation of naming, ownership and deletion semantics is pretty broken and not useful even for metamodeling. Steve Cook gave a good example . where deletion of an Association should delete all its end Properties regardless of whether .owned. by the Class or Association. All UML tools do this as a matter of common sense: but we have no way of specifying something as basic as that in the metamodel! 2. supporting a means of denoting property access across associations that should be "efficient" based possibly on some implementation(s) 3. supporting explicit modeling of relational tables that have to flip property ownership/navigability for normalized foreign keys [PJR] Well until UML 2.4, we didn.t have the notion of any sort of identifier in UML let alone keys (which is essential for relational database modeling): so this argument does not seem to hold. In any case, for metamodels . which specify the behavior of modeling, constraint and transformation tools, all such navigations should be .efficient. . hence my argument that navigability has no place for use in metamodels (i.e. MOF). In other words MOF should have the constraint that all ends are navigable. I believe this is a good example of introducing unnecessary concerns into the modeling language that resulted in unneeded complexity. The logical notion of property and association should have either been simple as in EMOF, or attributes and associations should have been clearly distinguished and separate as in CMOF. We should not have done both. Navigability would then be semantically meaningful in terms of the relationship itself. [PJR] Due to the absence of L0 support, we already have what you call the CMOF approach (which is actually the original UML and MOF approach). So, as per Yves. original request we have no practical means of using the line notation for attributes. Which actually is fine by me . I personally don.t find it useful. But maybe we could introduce a keyword <> to annotate an association. [PJR] Even with the CMOF approach I still don.t see that navigability has any useful semantics . it.s only ever an implementation hint . which rather belongs to markup/profile rather than as something inherent to the language. Issues of XMI generation, efficient access or object/relational mapping and property ownership should have been left to mappings and implementations. [PJR] Agreed . you seem to be supporting my argument that navigability has no semantics. I would be strongly in favor of removing the dot notation - it is little understood, infrequently used, and not needed. [PJR] I disagree: as per my earlier email (and as you yourself seem to be arguing) it.s the concept of navigability that needs to be removed for metamodeling. The dot notation in contrast does have some clear meaning but I agree it.s not of interest to most users. Maybe it would be more appropriate as a stereotype . but surely our metamodel diagrams are neater and clearer through use of the dot notation than with lots of tags attached to ends. Especially as our tools have now gone to the hassle of supporting it. However that would be mere tinkering . we should consider the semantics we actually want to represent (e.g. around naming, deletion and even change management), not be driven by the notation. A final thought linked to the Binding thread . the navigability arrow seems to be a generic notational device which only has a precise meaning when combined with a Binding to some sort of platform. The original UML2.0 spec (and the current section on .how to read the notation in the UML spec.) represent a specific binding to the MOF platform (i.e. a model management meaning). However the fact that this was really a binding was not recognized and, because some people wanted it interpreted differently for other platforms, it was reclaimed it as something vague and the dot notation was introduced for that MOF platform related meaning. Jim Amsden, Senior Technical Staff Member Unleash the Labs Solution Architect for Rational EA and ADC Tools Make a new ULL Request 919-461-3689 From: Steve Cook To: "Rouquette, Nicolas F (316A)" , "DESFRAY Philippe" Cc: "BERNARD, Yves" , Pete Rivett , Ed Seidewitz , Bran Selic , "uml2-rtf@omg.org" Date: 12/14/2010 07:48 AM Subject: RE: New notation for attribute -------------------------------------------------------------------------------- Today UML has several different ill-defined ways to express asymmetry of an association. 1. The .white diamond., shared aggregation. The spec admits that this has no well-defined semantics. 2. The arrowhead for navigability. The semantics are .efficient access.. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. 3. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. .Ownership. in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. .Ownership. implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an .end. property on the generated class ConnectableElement, so it must be a .navigable. property, and because navigable is .deprecated. in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability. is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability. concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like. notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. To: "Pete Rivett" Cc: "Ed Seidewitz" , "Rouquette, Nicolas F (316A)" , "DESFRAY Philippe" , "Bran Selic" , "Steve Cook" , uml2-rtf@omg.org, "BERNARD, Yves" Subject: RE: New notation for attribute X-KeepSent: 52DAFD2D:85FB90A1-852577F9:00686349; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: Jim Amsden Date: Tue, 14 Dec 2010 12:14:34 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 12/14/2010 12:14:37, Serialize complete at 12/14/2010 12:14:37 Pete, RSA lets you drag and drop a property with non-primitive type out of a class and view it as an association. You can also put it back. So this is implemented in at least one tool. Classifier has property attributes which is derived. If I remember right, Association member ends contributes to attributes. Association could have had attributes, but AssociationClass was introduced instead. Why have Association be a class if it doesn't have attributes? There have been countless arguments about property ownership in the UML 2 metamodel itself as a result of the conventions used in early versions of the spec. Dependency was one such example. The issue was always changing the metamodel so that adding for example a dependency or generalization didn't "change" (i.e., add a property to) any of the dependent classes. The semantics of navigability are simple, well understood, and well practiced - even in the UML specification itself. It simply means that from a source object you would expect to be able to reference the target object if its navigable, and not if it isn't. This is common in programming languages and relational databases. OCL might ignore this, but that seems like an odd exception, not common practice. Navigability was how the UML spec was originally created, and I don't remember anyone ever being confused about what it meant - after all it was in UML 1.x. Property ownership is essentially redundant and is the thing that has no semantic meaning - rather specifying something about implementation structure. Are there any cases in the UML 2.4 specification where the dot notation and property ownership is different than the conventions that were used with navigation in earlier versions? If so, does anyone understand or care about the implications? But it is pointless to have these arguments again. The fact that it keeps coming up is an indication of poor understanding and adoption. This is the point that is being made, not the specific technical details of this particular issue. It is only one of many that taken together may have resulted in reduced quality, relevance, value and usability of UML. Jim Amsden, Senior Technical Staff Member Unleash the Labs Solution Architect for Rational EA and ADC Tools Make a new ULL Request 919-461-3689 From: "Pete Rivett" To: Jim Amsden/Raleigh/IBM@IBMUS, "Steve Cook" Cc: "Ed Seidewitz" , "Rouquette, Nicolas F (316A)" , "DESFRAY Philippe" , "Bran Selic" , , "BERNARD, Yves" Date: 12/14/2010 12:26 PM Subject: RE: New notation for attribute -------------------------------------------------------------------------------- Lots of points to address here. See [PJR] below. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, December 14, 2010 5:22 AM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); Pete Rivett; DESFRAY Philippe; Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: New notation for attribute I agree with both Steve and Philippe on this. The history derives from the EMOF/CMOF discussions. EMOF didn't have associations but rather had properties whose types could be either primitive (representing an attribute) or some non-primitive type (representing a navigable association). This is similar to RDF where the object in Subject Predicate Object can either be a primitive type or a reference to another object. Property::opposite was introduced to support a closed relationship loop between two classes (navigating from one to the other and back results in the original instance). EMOF made not distinguish between attribute and association notation - they are different notations depicting the same concept. Which one to use is a user preference. [PJR] EMOF has no notation . it relies on UML. The question is hhow to interpret that UML. The major problem is that the L0 compliance level of UML that EMOF is based on has been implemented by zero vendors and is to all intents and purposes non-existent. And indeed will be removed completely at UML 2.5. Hence, without the ability for the modeler to say ârun in L0 modeâ or âtreat this as an L0 diagramâ the notation is inherently ambiguous as others have pointed out on this thread. All UML tools that I am aware of will create an Association when a user draws a line so we should build on that. CMOF introduced associations to explicitly model relationships between classes as something separate from properties. [PJR] No, CMOF did not introduce this . itâs always been part of UML and mainstream MOF ffrom day 1 (prior to MOF 2.0 did not have the crippled EMOF without Associations). So itâs more accurate to say that âEMOF removed Associationsâ. Then the issue arose about which element "owns" the properties corresponding to the association ends - the associated classes (to be consistent with EMOF) or the association (to decouple the related classes) or both based on conventions for navigability, or the new concept of explicit property ownership. UML Superstructure adds AssociationClass to provide attributes on the association (even though an Association is a Class and can already have attributes - but there was no notation for this). [PJR] Association is a Classifier not a Class and as such cannot have ownedAttributes. The argument for property ownership as something separate from navigability was based on: 1. decoupling classes and supporting change management (adding a relationship without changing the related classes) [PJR] Whether the addition of a Property is deemed to âchangeâ the Class at either end is in none of the OMG specs which donât address the topic at all. Itâs certainly not in MOF Versioning/Facility which are the specs that comes closest to any sort of change management. This assumption of change seems based on a certain serialization paradigm . as if moddels are all naively stored as text files and managed in a text-based versioning/change management system. However even with the naïve approach of treating XMI serialization as the storage model, the OMG specs do not dictate how models are serialized across one or more files. And, for the example at hand, there is nothing to force the ownedAttributes of a Class to be serialized in the same XMI file as the Class itself. Overall the current conflation of naming, ownership and deletion semantics is pretty broken and not useful even for metamodeling. Steve Cook gave a good example . where deletion of an Association should delete all its end Properties regardless of whether âownedâ by the Class or Association. All UML tools do this as a matter of common sense: but we have no way of specifying something as basic as that in the metamodel! 2. supporting a means of denoting property access across associations that should be "efficient" based possibly on some implementation(s) 3. supporting explicit modeling of relational tables that have to flip property ownership/navigability for normalized foreign keys [PJR] Well until UML 2.4, we didnât have the notion of any sort of identifier in UML let alone keys (which is essential for relational database modeling): so this argument does not seem to hold. In any case, for metamodels . which specify the behavior of modeling, constraint and transformation tools, all such navigations should be âefficientâ . hence my argument that navigability has nno place for use in metamodels (i.e. MOF). In other words MOF should have the constraint that all ends are navigable. I believe this is a good example of introducing unnecessary concerns into the modeling language that resulted in unneeded complexity. The logical notion of property and association should have either been simple as in EMOF, or attributes and associations should have been clearly distinguished and separate as in CMOF. We should not have done both. Navigability would then be semantically meaningful in terms of the relationship itself. [PJR] Due to the absence of L0 support, we already have what you call the CMOF approach (which is actually the original UML and MOF approach). So, as per Yvesâ original request we have no practical means of using the line notation for attributes. Which actually is fine by me . I personally donât findd it useful. But maybe we could introduce a keyword <> to annotate an association. [PJR] Even with the CMOF approach I still donât see that navigability has any useful semantics . itâs only evver an implementation hint . which rather belongs to marrkup/profile rather than as something inherent to the language. Issues of XMI generation, efficient access or object/relational mapping and property ownership should have been left to mappings and implementations. [PJR] Agreed . you seem to be supporting myy argument that navigability has no semantics. I would be strongly in favor of removing the dot notation - it is little understood, infrequently used, and not needed. [PJR] I disagree: as per my earlier email (and as you yourself seem to be arguing) itâs the concept of navigability that needs to be removed for metamodeling. The dot notation in contrast does have some clear meaning but I agree itâs not of interest to most users. Maybe it would be more appropriate as a stereotype . but surely our metamodel diagrams are neater and clearer through use of the dot notation than with lots of tags attached to ends. Especially as our tools have now gone to the hassle of supporting it. However that would be mere tinkering . we should consider the semantiics we actually want to represent (e.g. around naming, deletion and even change management), not be driven by the notation. A final thought linked to the Binding thread . the navigability arrow seems to be a genericc notational device which only has a precise meaning when combined with a Binding to some sort of platform. The original UML2.0 spec (and the current section on âhow to read the notation in the UML specâ) represent a specific binding to the MOF platform (i.e. a model management meaning). However the fact that this was really a binding was not recognized and, because some people wanted it interpreted differently for other platforms, it was reclaimed it as something vague and the dot notation was introduced for that MOF platform related meaning. Jim Amsden, Senior Technical Staff Member Unleash the Labs Solution Architect for Rational EA and ADC Tools Make a new ULL Request 919-461-3689 From: Steve Cook To: "Rouquette, Nicolas F (316A)" , "DESFRAY Philippe" Cc: "BERNARD, Yves" , Pete Rivett , Ed Seidewitz , Bran Selic , "uml2-rtf@omg.org" Date: 12/14/2010 07:48 AM Subject: RE: New notation for attribute -------------------------------------------------------------------------------- Today UML has several different ill-defined ways to express asymmetry of an association. 1. The âwhite diamondâ, shared aggregation. The spec admits that this has no well-defined semantics. 2. The arrowhead for navigability. The semantics are âefficient accessâ. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. 3. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. âOwnershipâ in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. âOwnershipâ implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an âendâ property on the generated class ConnectableElement, so it must be a ânavigableâ property, and because navigable is âdeprecatedâ in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marrked association end is owned by the classifier, and . the opposite (unmarkedd) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The âdotâ notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . tthe association is navigable in the direction of that end, . the marked assocciation end is owned by the classifier, and . the opposite (unmarked) associaation end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end userâs modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé : mardi 14 décembre 2010 09:00 à : Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what ânavigabilityâ is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a ânavigabilityâ concept (assuming it is clear in their minds) might create a stereotype. Anyway, thatâs a separate issue and except if Iâm wrong, itâs already registered. Iâm going to open a separate one for the âassociation-likeâ notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 décembre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that itâs not possible (âefficientlyâ) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? Thatâs not to say navigability has no value for other types of model. I donât feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since itâs redundant, confusing and mmakes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange â since itâs the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve .. I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the âdot on the wrong endâ is the right way to show an attribute using âassociation-like notationâ, which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I donât think it has), I donât think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Iâve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I donât believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 âto show dot-notationâ. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it iss indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I donât see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the âlink notationâ · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: New notation for attribute Date: Tue, 14 Dec 2010 14:24:31 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wAAKPP5wALqwGoAAAlAsgAACAE6wAAI0pr8AAaarcAALZgKw From: "Ed Seidewitz" To: "Steve Cook" Cc: Steve . Actually, the defining feature of a slot does not have to actually be owned by a classifier of an instance specification, it only has to be a namespace member of a classifier. Since all ends of an association are members of the association, whatever their ownership, an instance specification representing a link of an association can always have slots for any ends of the link. On the other hand, an association end is only a member of its opposite classifier if it is owned by that classifier. Therefore, an instance specification of a non-association classifier will only have slots for association ends that are owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, December 14, 2010 9:09 AM To: george.ericson@emc.com; nicolas.f.rouquette@jpl.nasa.gov; philippe.desfray@softeam.fr Cc: Yves.Bernard@airbus.com; Pete Rivett - Adaptive; Ed Seidewitz; selic@acm.org; uml2-rtf@omg.org Subject: RE: New notation for attribute George You are right: in addition to what I wrote about end ownership, it would be invalid to allocate a slot to an InstanceSpecification corresponding to a property that its classifier does not own. The link notation for InstanceSpecification has no corollary to the blob notation. You can show navigability, which would imply ownership of the slot by the instance at the other end, but not showing navigability implies nothing. -- Steve From: george.ericson@emc.com [mailto:george.ericson@emc.com] Sent: 14 December 2010 13:07 To: Steve Cook; nicolas.f.rouquette@jpl.nasa.gov; philippe.desfray@softeam.fr Cc: Yves.Bernard@airbus.com; pete.rivett@adaptive.com; ed-s@modeldriven.com; selic@acm.org; uml2-rtf@omg.org Subject: Re: New notation for attribute Useful summary. I had thought, perhaps naively, that ownership told me what classifier, (or if), a slot for the property should be allocated to.. I had not known of your use. In our use with the dmtf common information model, ifDeleted semantics are expressed explictly via a qualifier. -------------------------------------------------------------------------------- From: Steve Cook To: Rouquette, Nicolas F (316A) ; DESFRAY Philippe Cc: BERNARD, Yves ; Pete Rivett ; Ed Seidewitz ; Bran Selic ; uml2-rtf@omg.org Sent: Tue Dec 14 07:43:03 2010 Subject: RE: New notation for attribute Today UML has several different ill-defined ways to express asymmetry of an association. 1. The .white diamond., shared aggregation. The spec admits that this has no well-defined semantics. 2. The arrowhead for navigability. The semantics are .efficient access.. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. 3. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. .Ownership. in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. .Ownership. implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an .end. property on the generated class ConnectableElement, so it must be a .navigable. property, and because navigable is .deprecated. in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability. is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability. concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like. notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: New notation for attribute Date: Tue, 14 Dec 2010 14:42:49 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: AcubwytQTdV1WokrQFaY+IyDtM8yHwAAhGyA From: "Ed Seidewitz" To: "Jim Amsden" Cc: Jim . An association that is not an association class does not have attributes. The member ends are just members, not attributes (memberEnd does not subset attribute). An association is not a class, it is a classifier. It is a classifier because it can have instances. -- Ed -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, December 14, 2010 2:15 PM To: Pete Rivett - Adaptive Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); DESFRAY Philippe; Bran Selic; Steve Cook; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: New notation for attribute Pete, RSA lets you drag and drop a property with non-primitive type out of a class and view it as an association. You can also put it back. So this is implemented in at least one tool. Classifier has property attributes which is derived. If I remember right, Association member ends contributes to attributes. Association could have had attributes, but AssociationClass was introduced instead. Why have Association be a class if it doesn't have attributes? There have been countless arguments about property ownership in the UML 2 metamodel itself as a result of the conventions used in early versions of the spec. Dependency was one such example. The issue was always changing the metamodel so that adding for example a dependency or generalization didn't "change" (i.e., add a property to) any of the dependent classes. The semantics of navigability are simple, well understood, and well practiced - even in the UML specification itself. It simply means that from a source object you would expect to be able to reference the target object if its navigable, and not if it isn't. This is common in programming languages and relational databases. OCL might ignore this, but that seems like an odd exception, not common practice. Navigability was how the UML spec was originally created, and I don't remember anyone ever being confused about what it meant - after all it was in UML 1.x. Property ownership is essentially redundant and is the thing that has no semantic meaning - rather specifying something about implementation structure. Are there any cases in the UML 2.4 specification where the dot notation and property ownership is different than the conventions that were used with navigation in earlier versions? If so, does anyone understand or care about the implications? But it is pointless to have these arguments again. The fact that it keeps coming up is an indication of poor understanding and adoption. This is the point that is being made, not the specific technical details of this particular issue. It is only one of many that taken together may have resulted in reduced quality, relevance, value and usability of UML. Jim Amsden, Senior Technical Staff Member Unleash the Labs Solution Architect for Rational EA and ADC Tools Make a new ULL Request 919-461-3689 From: "Pete Rivett" To: Jim Amsden/Raleigh/IBM@IBMUS, "Steve Cook" Cc: "Ed Seidewitz" , "Rouquette, Nicolas F (316A)" , "DESFRAY Philippe" , "Bran Selic" , , "BERNARD, Yves" Date: 12/14/2010 12:26 PM Subject: RE: New notation for attribute -------------------------------------------------------------------------------- Lots of points to address here. See [PJR] below. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, December 14, 2010 5:22 AM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); Pete Rivett; DESFRAY Philippe; Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: New notation for attribute I agree with both Steve and Philippe on this. The history derives from the EMOF/CMOF discussions. EMOF didn't have associations but rather had properties whose types could be either primitive (representing an attribute) or some non-primitive type (representing a navigable association). This is similar to RDF where the object in Subject Predicate Object can either be a primitive type or a reference to another object. Property::opposite was introduced to support a closed relationship loop between two classes (navigating from one to the other and back results in the original instance). EMOF made not distinguish between attribute and association notation - they are different notations depicting the same concept. Which one to use is a user preference. [PJR] EMOF has no notation . it relies on UML. The question is how to interpret that UML. The major problem is that the L0 compliance level of UML that EMOF is based on has been implemented by zero vendors and is to all intents and purposes non-existent. And indeed will be removed completely at UML 2.5. Hence, without the ability for the modeler to say .run in L0 mode. or .treat this as an L0 diagram. the notation is inherently ambiguous as others have pointed out on this thread. All UML tools that I am aware of will create an Association when a user draws a line so we should build on that. CMOF introduced associations to explicitly model relationships between classes as something separate from properties. [PJR] No, CMOF did not introduce this . it.s always been part of UML and mainstream MOF from day 1 (prior to MOF 2.0 did not have the crippled EMOF without Associations). So it.s more accurate to say that .EMOF removed Associations.. Then the issue arose about which element "owns" the properties corresponding to the association ends - the associated classes (to be consistent with EMOF) or the association (to decouple the related classes) or both based on conventions for navigability, or the new concept of explicit property ownership. UML Superstructure adds AssociationClass to provide attributes on the association (even though an Association is a Class and can already have attributes - but there was no notation for this). [PJR] Association is a Classifier not a Class and as such cannot have ownedAttributes. The argument for property ownership as something separate from navigability was based on: 1. decoupling classes and supporting change management (adding a relationship without changing the related classes) [PJR] Whether the addition of a Property is deemed to .change. the Class at either end is in none of the OMG specs which don.t address the topic at all. It.s certainly not in MOF Versioning/Facility which are the specs that comes closest to any sort of change management. This assumption of change seems based on a certain serialization paradigm . as if models are all naively stored as text files and managed in a text-based versioning/change management system. However even with the naï approach of treating XMI serialization as the storage model, the OMG specs do not dictate how models are serialized across one or more files. And, for the example at hand, there is nothing to force the ownedAttributes of a Class to be serialized in the same XMI file as the Class itself. Overall the current conflation of naming, ownership and deletion semantics is pretty broken and not useful even for metamodeling. Steve Cook gave a good example . where deletion of an Association should delete all its end Properties regardless of whether .owned. by the Class or Association. All UML tools do this as a matter of common sense: but we have no way of specifying something as basic as that in the metamodel! 2. supporting a means of denoting property access across associations that should be "efficient" based possibly on some implementation(s) 3. supporting explicit modeling of relational tables that have to flip property ownership/navigability for normalized foreign keys [PJR] Well until UML 2.4, we didn.t have the notion of any sort of identifier in UML let alone keys (which is essential for relational database modeling): so this argument does not seem to hold. In any case, for metamodels . which specify the behavior of modeling, constraint and transformation tools, all such navigations should be .efficient. . hence my argument that navigability has no place for use in metamodels (i.e. MOF). In other words MOF should have the constraint that all ends are navigable. I believe this is a good example of introducing unnecessary concerns into the modeling language that resulted in unneeded complexity. The logical notion of property and association should have either been simple as in EMOF, or attributes and associations should have been clearly distinguished and separate as in CMOF. We should not have done both. Navigability would then be semantically meaningful in terms of the relationship itself. [PJR] Due to the absence of L0 support, we already have what you call the CMOF approach (which is actually the original UML and MOF approach). So, as per Yves. original request we have no practical means of using the line notation for attributes. Which actually is fine by me . I personally don.t find it useful. But maybe we could introduce a keyword <> to annotate an association. [PJR] Even with the CMOF approach I still don.t see that navigability has any useful semantics . it.s only ever an implementation hint . which rather belongs to markup/profile rather than as something inherent to the language. Issues of XMI generation, efficient access or object/relational mapping and property ownership should have been left to mappings and implementations. [PJR] Agreed . you seem to be supporting my argument that navigability has no semantics. I would be strongly in favor of removing the dot notation - it is little understood, infrequently used, and not needed. [PJR] I disagree: as per my earlier email (and as you yourself seem to be arguing) it.s the concept of navigability that needs to be removed for metamodeling. The dot notation in contrast does have some clear meaning but I agree it.s not of interest to most users. Maybe it would be more appropriate as a stereotype . but surely our metamodel diagrams are neater and clearer through use of the dot notation than with lots of tags attached to ends. Especially as our tools have now gone to the hassle of supporting it. However that would be mere tinkering . we should consider the semantics we actually want to represent (e.g. around naming, deletion and even change management), not be driven by the notation. A final thought linked to the Binding thread . the navigability arrow seems to be a generic notational device which only has a precise meaning when combined with a Binding to some sort of platform. The original UML2.0 spec (and the current section on .how to read the notation in the UML spec.) represent a specific binding to the MOF platform (i.e. a model management meaning). However the fact that this was really a binding was not recognized and, because some people wanted it interpreted differently for other platforms, it was reclaimed it as something vague and the dot notation was introduced for that MOF platform related meaning. Jim Amsden, Senior Technical Staff Member Unleash the Labs Solution Architect for Rational EA and ADC Tools Make a new ULL Request 919-461-3689 From: Steve Cook To: "Rouquette, Nicolas F (316A)" , "DESFRAY Philippe" Cc: "BERNARD, Yves" , Pete Rivett , Ed Seidewitz , Bran Selic , "uml2-rtf@omg.org" Date: 12/14/2010 07:48 AM Subject: RE: New notation for attribute -------------------------------------------------------------------------------- Today UML has several different ill-defined ways to express asymmetry of an association. 1. The .white diamond., shared aggregation. The spec admits that this has no well-defined semantics. 2. The arrowhead for navigability. The semantics are .efficient access.. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. 3. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. .Ownership. in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. .Ownership. implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an .end. property on the generated class ConnectableElement, so it must be a .navigable. property, and because navigable is .deprecated. in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability. is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability. concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like. notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-IronPort-AV: E=Sophos;i="4.59,344,1288566000"; d="scan'208,217";a="22718912" From: LONJON Antoine To: "'ed-s@modeldriven.com'" , "'Steve.Cook@microsoft.com'" CC: "'uml2-rtf@omg.org'" Date: Tue, 14 Dec 2010 21:11:15 +0100 Subject: Re: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wAAKPP5wALqwGoAAAlAsgAACAE6wAAI0pr8AAaarcAALZgKwAAHIX3k= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed You said "Since all ends of an association are members of the association, ..." This "member" subsetting is very odd as "members" should be owned or inherited according to namespace definition. This just shows that association is ill defined as is trying to cover two different views of relationships as Jim said (EMOF, CMOF) The introduction of composite structure has changed the meaning of association as type of connectors. This should now be acknoledged and fixed accordingly. All the debat on ownership of properties will go away. Antoine From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, December 14, 2010 08:24 PM To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . Actually, the defining feature of a slot does not have to actually be owned by a classifier of an instance specification, it only has to be a namespace member of a classifier. Since all ends of an association are members of the association, whatever their ownership, an instance specification representing a link of an association can always have slots for any ends of the link. On the other hand, an association end is only a member of its opposite classifier if it is owned by that classifier. Therefore, an instance specification of a non-association classifier will only have slots for association ends that are owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, December 14, 2010 9:09 AM To: george.ericson@emc.com; nicolas.f.rouquette@jpl.nasa.gov; philippe.desfray@softeam.fr Cc: Yves.Bernard@airbus.com; Pete Rivett - Adaptive; Ed Seidewitz; selic@acm.org; uml2-rtf@omg.org Subject: RE: New notation for attribute George You are right: in addition to what I wrote about end ownership, it would be invalid to allocate a slot to an InstanceSpecification corresponding to a property that its classifier does not own. The link notation for InstanceSpecification has no corollary to the blob notation. You can show navigability, which would imply ownership of the slot by the instance at the other end, but not showing navigability implies nothing. -- Steve From: george.ericson@emc.com [mailto:george.ericson@emc.com] Sent: 14 December 2010 13:07 To: Steve Cook; nicolas.f.rouquette@jpl.nasa.gov; philippe.desfray@softeam.fr Cc: Yves.Bernard@airbus.com; pete.rivett@adaptive.com; ed-s@modeldriven.com; selic@acm.org; uml2-rtf@omg.org Subject: Re: New notation for attribute Useful summary. I had thought, perhaps naively, that ownership told me what classifier, (or if), a slot for the property should be allocated to.. I had not known of your use. In our use with the dmtf common information model, ifDeleted semantics are expressed explictly via a qualifier. -------------------------------------------------------------------------------- From: Steve Cook To: Rouquette, Nicolas F (316A) ; DESFRAY Philippe Cc: BERNARD, Yves ; Pete Rivett ; Ed Seidewitz ; Bran Selic ; uml2-rtf@omg.org Sent: Tue Dec 14 07:43:03 2010 Subject: RE: New notation for attribute Today UML has several different ill-defined ways to express asymmetry of an association. 1. The âwhite diamondâ, shared aggregation. The spec admits that this has no well-defined semantics. 2. The arrowhead for navigability. The semantics are âefficient accessâ. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. 3. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. âOwnershipâ in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. âOwnershipâ implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an âendâ property on the generated class ConnectableElement, so it must be a ânavigableâ property, and because navigable is âdeprecatedâ in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . thee association is navigable in the direction of that end, . the marked associatioon end is owned by the classifier, and . the opposite (unmarked) association endd is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The âdotâ notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is naavigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end userâs modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé : mardi 14 décembre 2010 09:00 à : Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what ânavigabilityâ is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a ânavigabilityâ concept (assuming it is clear in their minds) might create a stereotype. Anyway, thatâs a separate issue and except if Iâm wrong, itâs already registered. Iâm going to open a separate one for the âassociation-likeâ notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 décembre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that itâs not possible (âefficientlyâ) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? Thatâs not to say navigability has no value for other types of model. I donât feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since itâs redunddant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since itâs tthe end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the âdot on the wrong endâ is the right way to show an attribute using âassociation-like notationâ, which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I donât think it has), I donât think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Iâve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I donât believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 âto show dot-notationâ. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloadded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I donât see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the âlink notationâ · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -------------------------------------------------------------------------------- !!WARNING!! MEGA moves and joins up its Paris teams on December 17th. Our phone and email connections will be affected during this time. Should you face any trouble in contacting us, please do not hesitate to call your Account Manager on his/her mobile. Please excuse any inconvenience. This e-mail, including attachments, is confidential. It is intended solely for the addressees. If you are not a recipient, any use, copy or diffusion, even in part of this message is prohibited. Please delete it and notify the sender immediately. Since the integrity of this message cannot be guaranteed on the Internet, MEGA cannot be considered liable for its content. Subject: RE: New notation for attribute Date: Tue, 14 Dec 2010 15:17:14 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wAAKPP5wALqwGoAAAlAsgAACAE6wAAI0pr8AAaarcAALZgKwAAHIX3kAABw+YA== From: "Ed Seidewitz" To: "LONJON Antoine" Cc: Antoine . I would say that the current concept of association in UML covers OO-oriented and database-oriented views, rather than EMOF and CMOF, since I don.t think MOF really was the reason for this concept in the UML superstructure. Be that as it may, I also don.t think that the concept is .ill defined.. Poorly defined, perhaps, or defined by compromise, certainly . but then, that is true of many UML constructs today! -- Ed -------------------------------------------------------------------------------- From: LONJON Antoine [mailto:antoine.lonjon@mega.com] Sent: Tuesday, December 14, 2010 3:11 PM To: Ed Seidewitz; 'Steve.Cook@microsoft.com' Cc: 'uml2-rtf@omg.org' Subject: Re: New notation for attribute Ed You said "Since all ends of an association are members of the association, ..." This "member" subsetting is very odd as "members" should be owned or inherited according to namespace definition. This just shows that association is ill defined as is trying to cover two different views of relationships as Jim said (EMOF, CMOF) The introduction of composite structure has changed the meaning of association as type of connectors. This should now be acknoledged and fixed accordingly. All the debat on ownership of properties will go away. Antoine From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, December 14, 2010 08:24 PM To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . Actually, the defining feature of a slot does not have to actually be owned by a classifier of an instance specification, it only has to be a namespace member of a classifier. Since all ends of an association are members of the association, whatever their ownership, an instance specification representing a link of an association can always have slots for any ends of the link. On the other hand, an association end is only a member of its opposite classifier if it is owned by that classifier. Therefore, an instance specification of a non-association classifier will only have slots for association ends that are owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, December 14, 2010 9:09 AM To: george.ericson@emc.com; nicolas.f.rouquette@jpl.nasa.gov; philippe.desfray@softeam.fr Cc: Yves.Bernard@airbus.com; Pete Rivett - Adaptive; Ed Seidewitz; selic@acm.org; uml2-rtf@omg.org Subject: RE: New notation for attribute George You are right: in addition to what I wrote about end ownership, it would be invalid to allocate a slot to an InstanceSpecification corresponding to a property that its classifier does not own. The link notation for InstanceSpecification has no corollary to the blob notation. You can show navigability, which would imply ownership of the slot by the instance at the other end, but not showing navigability implies nothing. -- Steve From: george.ericson@emc.com [mailto:george.ericson@emc.com] Sent: 14 December 2010 13:07 To: Steve Cook; nicolas.f.rouquette@jpl.nasa.gov; philippe.desfray@softeam.fr Cc: Yves.Bernard@airbus.com; pete.rivett@adaptive.com; ed-s@modeldriven.com; selic@acm.org; uml2-rtf@omg.org Subject: Re: New notation for attribute Useful summary. I had thought, perhaps naively, that ownership told me what classifier, (or if), a slot for the property should be allocated to.. I had not known of your use. In our use with the dmtf common information model, ifDeleted semantics are expressed explictly via a qualifier. -------------------------------------------------------------------------------- From: Steve Cook To: Rouquette, Nicolas F (316A) ; DESFRAY Philippe Cc: BERNARD, Yves ; Pete Rivett ; Ed Seidewitz ; Bran Selic ; uml2-rtf@omg.org Sent: Tue Dec 14 07:43:03 2010 Subject: RE: New notation for attribute Today UML has several different ill-defined ways to express asymmetry of an association. The .white diamond, shared aggregation. The spec admits that this has no well-defined semantics. The arrowhead for navigability. The semantics are .efficient access. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. .Ownership in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. .Ownership implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an .end property on the generated class ConnectableElement, so it must be a .navigable property, and because navigable is .deprecated in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The .dot notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end is the right way to show an attribute using .association-like notation, which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -------------------------------------------------------------------------------- !!WARNING!! MEGA moves and joins up its Paris teams on December 17th. Our phone and email connections will be affected during this time. Should you face any trouble in contacting us, please do not hesitate to call your Account Manager on his/her mobile. Please excuse any inconvenience. This e-mail, including attachments, is confidential. It is intended solely for the addressees. If you are not a recipient, any use, copy or diffusion, even in part of this message is prohibited. Please delete it and notify the sender immediately. Since the integrity of this message cannot be guaranteed on the Internet, MEGA cannot be considered liable for its content. From: Steve Cook To: Andrew Watson CC: Ed Seidewitz , Bran Selic , "BERNARD, Yves" , "uml2-rtf@omg.org" Subject: RE: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wABC9hSAACGMH8AAPU2egAAAm5KAAABZ2gAAAHjagAAAM89wAAB62EAALarhcgAJJBSw Date: Tue, 14 Dec 2010 20:25:50 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.93] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id oBEK5T0H011112 Andrew Maged, who owns the 2.4 spec source document, is out on vacation until 10th January. Is it tractable to vote on this by Friday, then deliver the report soon after, then deliver the source docs in January? -- Steve -----Original Message----- From: Andrew Watson [mailto:andrew@omg.org] Sent: 14 December 2010 16:01 To: Steve Cook Cc: Ed Seidewitz; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve, Sorry about the delayed reply. You wrote: > Maged has control of the documents and would have to be persuaded to > redo the framemaker if you feel this is really important. Also I think > we need Andrew's advice on whether it is procedurally in order to > change this diagram at this point. > > As for constituencies, the submitters of UML 2.5 have a choice here, > and I am certain about where my vote goes. I don't believe it is > necessary to satisfy everybody. Trying to satisfy everybody is one of > the reasons why UML 2 is like it is. We have voting procedures. Let's use them. No, I'm afraid we can't do this as an editorial change. My working definition of a editorial fix is "something my primary school teacher could find and fix. This isn't. If it needs fixing in a hurry, we have two options: 1. The UML 2.4 RTF exists until Friday 17th. If you can draft a resolution and vote on it before Friday, you can make the change. The RTF would have to issue a revised report, but if absolutely necessary that could be done after Friday, provided the vote finished before the end of Friday. The AB would also have to re-vote it, but that should be a formality. We would then put the new report in the PTC ballot. 2. If the RTF can't do this before Friday, but it is urgent, I could flag it as an urgent issue. With no UML RTF in place, the AB would vote on it. Hope this helps. Cheers, Andrew Subject: RE: New notation for attribute Date: Tue, 14 Dec 2010 12:45:45 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wABC9hSAACGMH8AAPU2egAAAm5KAAABZ2gAAAHjagAAAM89wAAB62EAALarhcgAJJBSwAACbFLA= From: "Pete Rivett" To: "Steve Cook" , "Andrew Watson" Cc: "Ed Seidewitz" , "Bran Selic" , "BERNARD, Yves" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id oBEKO2Ic013898 My understanding is 'yes' to your proposal. Pete -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, December 14, 2010 12:26 PM To: Andrew Watson Cc: Ed Seidewitz; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Andrew Maged, who owns the 2.4 spec source document, is out on vacation until 10th January. Is it tractable to vote on this by Friday, then deliver the report soon after, then deliver the source docs in January? -- Steve -----Original Message----- From: Andrew Watson [mailto:andrew@omg.org] Sent: 14 December 2010 16:01 To: Steve Cook Cc: Ed Seidewitz; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve, Sorry about the delayed reply. You wrote: > Maged has control of the documents and would have to be persuaded to > redo the framemaker if you feel this is really important. Also I think > we need Andrew's advice on whether it is procedurally in order to > change this diagram at this point. > > As for constituencies, the submitters of UML 2.5 have a choice here, > and I am certain about where my vote goes. I don't believe it is > necessary to satisfy everybody. Trying to satisfy everybody is one of > the reasons why UML 2 is like it is. We have voting procedures. Let's use them. No, I'm afraid we can't do this as an editorial change. My working definition of a editorial fix is "something my primary school teacher could find and fix. This isn't. If it needs fixing in a hurry, we have two options: 1. The UML 2.4 RTF exists until Friday 17th. If you can draft a resolution and vote on it before Friday, you can make the change. The RTF would have to issue a revised report, but if absolutely necessary that could be done after Friday, provided the vote finished before the end of Friday. The AB would also have to re-vote it, but that should be a formality. We would then put the new report in the PTC ballot. 2. If the RTF can't do this before Friday, but it is urgent, I could flag it as an urgent issue. With no UML RTF in place, the AB would vote on it. Hope this helps. Cheers, Andrew Subject: RE: New notation for attribute Date: Tue, 14 Dec 2010 12:46:55 -0800 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: AcubkfBo5Y/980R7SLSxstBfIMB/zgAGaKAwAAJQgDAABbBgcA== From: "Pete Rivett" To: "Ed Seidewitz" , Great explanation Ed! I want to clarify my position: I want to do away with the use of navigability for metamodels, but not remove it as a general capability for UML modelers. In other words we should include in the MOF constraints one that says, in essence, .to be a valid metamodel all ends must be navigable.. One consequence is that we can dispense with the use of arrows in the diagrams within the UML (and other metamodel) specs. Hopefully that will keep all constituencies happy enough in the short term . and we can move on to discuss longer term what (meta)modeling primitives we should have e.g. breaking apart naming, deletion semantics and serialization and possibly even change management. I avoid use of the word .ownership. because that term has been a major part of the problem. Another option would be to introduce a Binding from UML to the MOF platform that maps navigability to end ownership. Which is sort-of what the original non-finalized UML spec tried to do. But now that we have a specific notation for ownership independent of navigation, with navigation retaining its UML 1.x meaning (as Ed described), it seems counter-productive to do so. And we have no agreement on whether concept of Binding is even a good idea. The dot notation as distinct from navigability is a fact of life and was adopted through the formal democratic process we have in place. It.s been in 3 revisions of the UML spec and is implemented in many tools. The major impediment has been its slow adoption in the diagrams of the UML spec itself, and UML.s continued use of the arrow convention for ownership has caused ongoing confusion. I wish people would accept the 2 notations exist, use them as intended, and stop this passive-aggressive moaning about it: I.m not a great fan of dot notation but there are far more interesting issues to resolve. For those who wish to take the discussion further see http://uncyclopedia.wikia.com/wiki/Angels_on_the_head_of_a_pin. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, December 14, 2010 11:04 AM To: uml2-rtf@omg.org Subject: RE: New notation for attribute I think it is useful to recall the history of how we got to the dot notation. But my own recollection is that this history did not have anything directly to do with MOF (which I think is consistent with Pete.s comments below). In UML 1, associations always owned their ends (called .roles. back then). The UML 1 concept of association was strongly influenced by the work of Jim Rumbaugh and Mike Blaha on OO data modeling, in which they argued that associations should be modeled as a peer concept to classes, not simply as the consequence of .referential attributes. on classes. However, UML 1 still included the concept of navigability on an association because, especially for OO design modeling, many people continued to think of associations as directed .references. from one class to another. But this compromise never sat well with many OO practitioners, because it meant that you could .navigate across an association. from a source class that seemed to have no .visibility. of the opposite end of the association. So, in UML 2.0 as submitted, navigability was defined by end ownership: .When a property is owned by a class or data type via ownedAttribute, then it represents an attribute of the class or data type. When owned by an association via ownedEnd, it represents a non-navigable end of the association. (from the beginning of the Semantics section of the description of Property in Subclause 1.11 of ad/03-04-01 . emphasis in the original). There was no concept of .navigable association-owned ends.. However, those who preferred the UML 1 conception of associations now complained. The new UML 2.0 model allowed an association to own all its ends, but, in this case, they were all non-navigable. But this made it seem like you couldn.t navigate at all across the association, and those that viewed association in a more assertional or database sort of way didn.t want to have to make association ends class owned just to get navigability (which is required, for example, to do a read link action on an end). (Conrad Bock was the primary advocate on the FTF of this position, but he was by no means the only person who reviewed the submitted spec who had this position.) As a result, the UML 2.0 FTF decided to allow associations to have navigable owned ends, which provided the ability in UML 2.0 to model associations in the same way as in UML 1.0. But end ownership and navigability did not really become completely .orthogonal., because the constraint that class ownership always implies navigability was retained . which kept the OO folks happy. This change was made in UML 2.0 as finalized, in which (among other things) the two sentences quoted above were changed to .When a property is owned by a classifier other than an association via ownedAttribute, then it represents an attribute of the class or data type. When related to an association via memberEnd or one of its specializations, it represents an end of the association. (from Subclause 7.3.44 of formal/05-07-04), no longer mentioning navigability. It was then noticed in the UML 2.1 RTF that there was no way to graphically notate the difference between a navigable end that is owned by the association from one that is owned by the opposite class. So the dot notation was added in UML 2.1 as an optional way to notate this (as the resolution to Issue 8956). I believe it was Karl Frank who originally proposed this notation. And, while no one particularly liked it, no one could come up with any better notation either, so that was what was adopted. If, as some have suggested, we were to eliminate the concept of navigability, and then use the arrowhead to represent ownership, we would be essentially right back where we were when UML 2.0 started. And we would likely end up coming back full circle in the discussion that lead to the dot notation in the first place. Before we do anything, we need to be sure that we engage again the constituency that wanted navigable association-owned ends in the first place (they are still around!) and address their valid concerns. As is the case with any established product, just about every feature in UML, no matter how obscure, has some constituency! -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, December 14, 2010 12:24 PM To: Jim Amsden; Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); DESFRAY Philippe; Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: New notation for attribute Lots of points to address here. See [PJR] below. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, December 14, 2010 5:22 AM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); Pete Rivett; DESFRAY Philippe; Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: New notation for attribute I agree with both Steve and Philippe on this. The history derives from the EMOF/CMOF discussions. EMOF didn't have associations but rather had properties whose types could be either primitive (representing an attribute) or some non-primitive type (representing a navigable association). This is similar to RDF where the object in Subject Predicate Object can either be a primitive type or a reference to another object. Property::opposite was introduced to support a closed relationship loop between two classes (navigating from one to the other and back results in the original instance). EMOF made not distinguish between attribute and association notation - they are different notations depicting the same concept. Which one to use is a user preference. [PJR] EMOF has no notation . it relies on UML. The question is how to interpret that UML. The major problem is that the L0 compliance level of UML that EMOF is based on has been implemented by zero vendors and is to all intents and purposes non-existent. And indeed will be removed completely at UML 2.5. Hence, without the ability for the modeler to say .run in L0 mode. or .treat this as an L0 diagram. the notation is inherently ambiguous as others have pointed out on this thread. All UML tools that I am aware of will create an Association when a user draws a line so we should build on that. CMOF introduced associations to explicitly model relationships between classes as something separate from properties. [PJR] No, CMOF did not introduce this . it.s always been part of UML and mainstream MOF from day 1 (prior to MOF 2.0 did not have the crippled EMOF without Associations). So it.s more accurate to say that .EMOF removed Associations.. Then the issue arose about which element "owns" the properties corresponding to the association ends - the associated classes (to be consistent with EMOF) or the association (to decouple the related classes) or both based on conventions for navigability, or the new concept of explicit property ownership. UML Superstructure adds AssociationClass to provide attributes on the association (even though an Association is a Class and can already have attributes - but there was no notation for this). [PJR] Association is a Classifier not a Class and as such cannot have ownedAttributes. The argument for property ownership as something separate from navigability was based on: 1. decoupling classes and supporting change management (adding a relationship without changing the related classes) [PJR] Whether the addition of a Property is deemed to .change. the Class at either end is in none of the OMG specs which don.t address the topic at all. It.s certainly not in MOF Versioning/Facility which are the specs that comes closest to any sort of change management. This assumption of change seems based on a certain serialization paradigm . as if models are all naively stored as text files and managed in a text-based versioning/change management system. However even with the naï approach of treating XMI serialization as the storage model, the OMG specs do not dictate how models are serialized across one or more files. And, for the example at hand, there is nothing to force the ownedAttributes of a Class to be serialized in the same XMI file as the Class itself. Overall the current conflation of naming, ownership and deletion semantics is pretty broken and not useful even for metamodeling. Steve Cook gave a good example . where deletion of an Association should delete all its end Properties regardless of whether .owned. by the Class or Association. All UML tools do this as a matter of common sense: but we have no way of specifying something as basic as that in the metamodel! 2. supporting a means of denoting property access across associations that should be "efficient" based possibly on some implementation(s) 3. supporting explicit modeling of relational tables that have to flip property ownership/navigability for normalized foreign keys [PJR] Well until UML 2.4, we didn.t have the notion of any sort of identifier in UML let alone keys (which is essential for relational database modeling): so this argument does not seem to hold. In any case, for metamodels . which specify the behavior of modeling, constraint and transformation tools, all such navigations should be .efficient. . hence my argument that navigability has no place for use in metamodels (i.e. MOF). In other words MOF should have the constraint that all ends are navigable. I believe this is a good example of introducing unnecessary concerns into the modeling language that resulted in unneeded complexity. The logical notion of property and association should have either been simple as in EMOF, or attributes and associations should have been clearly distinguished and separate as in CMOF. We should not have done both. Navigability would then be semantically meaningful in terms of the relationship itself. [PJR] Due to the absence of L0 support, we already have what you call the CMOF approach (which is actually the original UML and MOF approach). So, as per Yves. original request we have no practical means of using the line notation for attributes. Which actually is fine by me . I personally don.t find it useful. But maybe we could introduce a keyword <> to annotate an association. [PJR] Even with the CMOF approach I still don.t see that navigability has any useful semantics . it.s only ever an implementation hint . which rather belongs to markup/profile rather than as something inherent to the language. Issues of XMI generation, efficient access or object/relational mapping and property ownership should have been left to mappings and implementations. [PJR] Agreed . you seem to be supporting my argument that navigability has no semantics. I would be strongly in favor of removing the dot notation - it is little understood, infrequently used, and not needed. [PJR] I disagree: as per my earlier email (and as you yourself seem to be arguing) it.s the concept of navigability that needs to be removed for metamodeling. The dot notation in contrast does have some clear meaning but I agree it.s not of interest to most users. Maybe it would be more appropriate as a stereotype . but surely our metamodel diagrams are neater and clearer through use of the dot notation than with lots of tags attached to ends. Especially as our tools have now gone to the hassle of supporting it. However that would be mere tinkering . we should consider the semantics we actually want to represent (e.g. around naming, deletion and even change management), not be driven by the notation. A final thought linked to the Binding thread . the navigability arrow seems to be a generic notational device which only has a precise meaning when combined with a Binding to some sort of platform. The original UML2.0 spec (and the current section on .how to read the notation in the UML spec.) represent a specific binding to the MOF platform (i.e. a model management meaning). However the fact that this was really a binding was not recognized and, because some people wanted it interpreted differently for other platforms, it was reclaimed it as something vague and the dot notation was introduced for that MOF platform related meaning. Jim Amsden, Senior Technical Staff Member Unleash the Labs Solution Architect for Rational EA and ADC Tools Make a new ULL Request 919-461-3689 From: Steve Cook To: "Rouquette, Nicolas F (316A)" , "DESFRAY Philippe" Cc: "BERNARD, Yves" , Pete Rivett , Ed Seidewitz , Bran Selic , "uml2-rtf@omg.org" Date: 12/14/2010 07:48 AM Subject: RE: New notation for attribute -------------------------------------------------------------------------------- Today UML has several different ill-defined ways to express asymmetry of an association. 1. The .white diamond., shared aggregation. The spec admits that this has no well-defined semantics. 2. The arrowhead for navigability. The semantics are .efficient access.. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. 3. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. .Ownership. in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. .Ownership. implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an .end. property on the generated class ConnectableElement, so it must be a .navigable. property, and because navigable is .deprecated. in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability. is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability. concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like. notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: New notation for attribute Date: Tue, 14 Dec 2010 15:54:23 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: AcubkfBo5Y/980R7SLSxstBfIMB/zgAGaKAwAAJQgDAABbBgcAABRTOg From: "Ed Seidewitz" To: "Pete Rivett - Adaptive" Cc: Pete . Thanks! Like everyone else, if I had had my way from the beginning things would have turned out differently. But, as you noted, the OMG standardization process is a democratic one, and compromises will always be necessary. While the dot notation compromise isn.t necessarily beautiful, I think it is probably a better thought out compromise than a number of other ones in UML. As you also note, there are far more interesting issues still to be resolved with UML! So I think I can live with your position as clarified below. -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, December 14, 2010 3:47 PM To: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: New notation for attribute Great explanation Ed! I want to clarify my position: I want to do away with the use of navigability for metamodels, but not remove it as a general capability for UML modelers. In other words we should include in the MOF constraints one that says, in essence, .to be a valid metamodel all ends must be navigable.. One consequence is that we can dispense with the use of arrows in the diagrams within the UML (and other metamodel) specs. Hopefully that will keep all constituencies happy enough in the short term . and we can move on to discuss longer term what (meta)modeling primitives we should have e.g. breaking apart naming, deletion semantics and serialization and possibly even change management. I avoid use of the word .ownership. because that term has been a major part of the problem. Another option would be to introduce a Binding from UML to the MOF platform that maps navigability to end ownership. Which is sort-of what the original non-finalized UML spec tried to do. But now that we have a specific notation for ownership independent of navigation, with navigation retaining its UML 1.x meaning (as Ed described), it seems counter-productive to do so. And we have no agreement on whether concept of Binding is even a good idea. The dot notation as distinct from navigability is a fact of life and was adopted through the formal democratic process we have in place. It.s been in 3 revisions of the UML spec and is implemented in many tools. The major impediment has been its slow adoption in the diagrams of the UML spec itself, and UML.s continued use of the arrow convention for ownership has caused ongoing confusion. I wish people would accept the 2 notations exist, use them as intended, and stop this passive-aggressive moaning about it: I.m not a great fan of dot notation but there are far more interesting issues to resolve. For those who wish to take the discussion further see http://uncyclopedia.wikia.com/wiki/Angels_on_the_head_of_a_pin. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, December 14, 2010 11:04 AM To: uml2-rtf@omg.org Subject: RE: New notation for attribute I think it is useful to recall the history of how we got to the dot notation. But my own recollection is that this history did not have anything directly to do with MOF (which I think is consistent with Pete.s comments below). In UML 1, associations always owned their ends (called .roles. back then). The UML 1 concept of association was strongly influenced by the work of Jim Rumbaugh and Mike Blaha on OO data modeling, in which they argued that associations should be modeled as a peer concept to classes, not simply as the consequence of .referential attributes. on classes. However, UML 1 still included the concept of navigability on an association because, especially for OO design modeling, many people continued to think of associations as directed .references. from one class to another. But this compromise never sat well with many OO practitioners, because it meant that you could .navigate across an association. from a source class that seemed to have no .visibility. of the opposite end of the association. So, in UML 2.0 as submitted, navigability was defined by end ownership: .When a property is owned by a class or data type via ownedAttribute, then it represents an attribute of the class or data type. When owned by an association via ownedEnd, it represents a non-navigable end of the association. (from the beginning of the Semantics section of the description of Property in Subclause 1.11 of ad/03-04-01 . emphasis in the original). There was no concept of .navigable association-owned ends.. However, those who preferred the UML 1 conception of associations now complained. The new UML 2.0 model allowed an association to own all its ends, but, in this case, they were all non-navigable. But this made it seem like you couldn.t navigate at all across the association, and those that viewed association in a more assertional or database sort of way didn.t want to have to make association ends class owned just to get navigability (which is required, for example, to do a read link action on an end). (Conrad Bock was the primary advocate on the FTF of this position, but he was by no means the only person who reviewed the submitted spec who had this position.) As a result, the UML 2.0 FTF decided to allow associations to have navigable owned ends, which provided the ability in UML 2.0 to model associations in the same way as in UML 1.0. But end ownership and navigability did not really become completely .orthogonal., because the constraint that class ownership always implies navigability was retained . which kept the OO folks happy. This change was made in UML 2.0 as finalized, in which (among other things) the two sentences quoted above were changed to .When a property is owned by a classifier other than an association via ownedAttribute, then it represents an attribute of the class or data type. When related to an association via memberEnd or one of its specializations, it represents an end of the association. (from Subclause 7.3.44 of formal/05-07-04), no longer mentioning navigability. It was then noticed in the UML 2.1 RTF that there was no way to graphically notate the difference between a navigable end that is owned by the association from one that is owned by the opposite class. So the dot notation was added in UML 2.1 as an optional way to notate this (as the resolution to Issue 8956). I believe it was Karl Frank who originally proposed this notation. And, while no one particularly liked it, no one could come up with any better notation either, so that was what was adopted. If, as some have suggested, we were to eliminate the concept of navigability, and then use the arrowhead to represent ownership, we would be essentially right back where we were when UML 2.0 started. And we would likely end up coming back full circle in the discussion that lead to the dot notation in the first place. Before we do anything, we need to be sure that we engage again the constituency that wanted navigable association-owned ends in the first place (they are still around!) and address their valid concerns. As is the case with any established product, just about every feature in UML, no matter how obscure, has some constituency! -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, December 14, 2010 12:24 PM To: Jim Amsden; Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); DESFRAY Philippe; Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: New notation for attribute Lots of points to address here. See [PJR] below. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, December 14, 2010 5:22 AM To: Steve Cook Cc: Ed Seidewitz; Rouquette, Nicolas F (316A); Pete Rivett; DESFRAY Philippe; Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: New notation for attribute I agree with both Steve and Philippe on this. The history derives from the EMOF/CMOF discussions. EMOF didn't have associations but rather had properties whose types could be either primitive (representing an attribute) or some non-primitive type (representing a navigable association). This is similar to RDF where the object in Subject Predicate Object can either be a primitive type or a reference to another object. Property::opposite was introduced to support a closed relationship loop between two classes (navigating from one to the other and back results in the original instance). EMOF made not distinguish between attribute and association notation - they are different notations depicting the same concept. Which one to use is a user preference. [PJR] EMOF has no notation . it relies on UML. The question is how to interpret that UML. The major problem is that the L0 compliance level of UML that EMOF is based on has been implemented by zero vendors and is to all intents and purposes non-existent. And indeed will be removed completely at UML 2.5. Hence, without the ability for the modeler to say .run in L0 mode. or .treat this as an L0 diagram. the notation is inherently ambiguous as others have pointed out on this thread. All UML tools that I am aware of will create an Association when a user draws a line so we should build on that. CMOF introduced associations to explicitly model relationships between classes as something separate from properties. [PJR] No, CMOF did not introduce this . it.s always been part of UML and mainstream MOF from day 1 (prior to MOF 2.0 did not have the crippled EMOF without Associations). So it.s more accurate to say that .EMOF removed Associations.. Then the issue arose about which element "owns" the properties corresponding to the association ends - the associated classes (to be consistent with EMOF) or the association (to decouple the related classes) or both based on conventions for navigability, or the new concept of explicit property ownership. UML Superstructure adds AssociationClass to provide attributes on the association (even though an Association is a Class and can already have attributes - but there was no notation for this). [PJR] Association is a Classifier not a Class and as such cannot have ownedAttributes. The argument for property ownership as something separate from navigability was based on: 1. decoupling classes and supporting change management (adding a relationship without changing the related classes) [PJR] Whether the addition of a Property is deemed to .change. the Class at either end is in none of the OMG specs which don.t address the topic at all. It.s certainly not in MOF Versioning/Facility which are the specs that comes closest to any sort of change management. This assumption of change seems based on a certain serialization paradigm . as if models are all naively stored as text files and managed in a text-based versioning/change management system. However even with the naï approach of treating XMI serialization as the storage model, the OMG specs do not dictate how models are serialized across one or more files. And, for the example at hand, there is nothing to force the ownedAttributes of a Class to be serialized in the same XMI file as the Class itself. Overall the current conflation of naming, ownership and deletion semantics is pretty broken and not useful even for metamodeling. Steve Cook gave a good example . where deletion of an Association should delete all its end Properties regardless of whether .owned. by the Class or Association. All UML tools do this as a matter of common sense: but we have no way of specifying something as basic as that in the metamodel! 2. supporting a means of denoting property access across associations that should be "efficient" based possibly on some implementation(s) 3. supporting explicit modeling of relational tables that have to flip property ownership/navigability for normalized foreign keys [PJR] Well until UML 2.4, we didn.t have the notion of any sort of identifier in UML let alone keys (which is essential for relational database modeling): so this argument does not seem to hold. In any case, for metamodels . which specify the behavior of modeling, constraint and transformation tools, all such navigations should be .efficient. . hence my argument that navigability has no place for use in metamodels (i.e. MOF). In other words MOF should have the constraint that all ends are navigable. I believe this is a good example of introducing unnecessary concerns into the modeling language that resulted in unneeded complexity. The logical notion of property and association should have either been simple as in EMOF, or attributes and associations should have been clearly distinguished and separate as in CMOF. We should not have done both. Navigability would then be semantically meaningful in terms of the relationship itself. [PJR] Due to the absence of L0 support, we already have what you call the CMOF approach (which is actually the original UML and MOF approach). So, as per Yves. original request we have no practical means of using the line notation for attributes. Which actually is fine by me . I personally don.t find it useful. But maybe we could introduce a keyword <> to annotate an association. [PJR] Even with the CMOF approach I still don.t see that navigability has any useful semantics . it.s only ever an implementation hint . which rather belongs to markup/profile rather than as something inherent to the language. Issues of XMI generation, efficient access or object/relational mapping and property ownership should have been left to mappings and implementations. [PJR] Agreed . you seem to be supporting my argument that navigability has no semantics. I would be strongly in favor of removing the dot notation - it is little understood, infrequently used, and not needed. [PJR] I disagree: as per my earlier email (and as you yourself seem to be arguing) it.s the concept of navigability that needs to be removed for metamodeling. The dot notation in contrast does have some clear meaning but I agree it.s not of interest to most users. Maybe it would be more appropriate as a stereotype . but surely our metamodel diagrams are neater and clearer through use of the dot notation than with lots of tags attached to ends. Especially as our tools have now gone to the hassle of supporting it. However that would be mere tinkering . we should consider the semantics we actually want to represent (e.g. around naming, deletion and even change management), not be driven by the notation. A final thought linked to the Binding thread . the navigability arrow seems to be a generic notational device which only has a precise meaning when combined with a Binding to some sort of platform. The original UML2.0 spec (and the current section on .how to read the notation in the UML spec.) represent a specific binding to the MOF platform (i.e. a model management meaning). However the fact that this was really a binding was not recognized and, because some people wanted it interpreted differently for other platforms, it was reclaimed it as something vague and the dot notation was introduced for that MOF platform related meaning. Jim Amsden, Senior Technical Staff Member Unleash the Labs Solution Architect for Rational EA and ADC Tools Make a new ULL Request 919-461-3689 From: Steve Cook To: "Rouquette, Nicolas F (316A)" , "DESFRAY Philippe" Cc: "BERNARD, Yves" , Pete Rivett , Ed Seidewitz , Bran Selic , "uml2-rtf@omg.org" Date: 12/14/2010 07:48 AM Subject: RE: New notation for attribute -------------------------------------------------------------------------------- Today UML has several different ill-defined ways to express asymmetry of an association. 1. The .white diamond., shared aggregation. The spec admits that this has no well-defined semantics. 2. The arrowhead for navigability. The semantics are .efficient access.. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. 3. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. .Ownership. in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. .Ownership. implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an .end. property on the generated class ConnectableElement, so it must be a .navigable. property, and because navigable is .deprecated. in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The .dot. notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability. is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability. concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like. notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end. is the right way to show an attribute using .association-like notation., which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation.. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation. · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: New notation for attribute Date: Wed, 15 Dec 2010 16:15:01 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wAAKPP5wALqwGoAAAlAsgAACAE6wAAI0pr8AAaarcAALZgKwAAHIX3kAABw+YAAfDLeAABU/f7A= From: "Ed Seidewitz" To: "LONJON Antoine" Cc: Antoine . The metamodel is well defined, even if it is not as neat and elegant as you might like. The description of member that you quote is, indeed, inconsistent with its subsetting by memberEnd, but there are many such inconsistencies in the current text of the UML spec (and many much worse than the one you identified). We are trying to correct all such inconsistencies in the spec for UML 2.5. However, any radical change to the structure of the metamodel for associations will have to wait until UML 3. -- Ed -------------------------------------------------------------------------------- From: LONJON Antoine [mailto:antoine.lonjon@mega.com] Sent: Wednesday, December 15, 2010 6:31 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: New notation for attribute Ed, I agree that the term .ill defined. is a little too sharp. I also agree that the debate is rather on OO versus Database orientation. But looking at the consistency of the association model, one could really get puzzled. 1. The first association .association / member. subsets .memberNamespace/Member., which is a derived association with the following definition: A collection of NamedElements identifiable within the Namespace, either by being owned or by being introduced by importing or inheritance. This is a derived union. Not all association properties are owned or inherited. So we have inconsistency here, don.t we? 2. .association / member. is itself subsetted by .owning association/owned end.. This means that ownership of association property is a subset of a derived association depending on this ownership. Hum .. 3. .owning association/owned end. is then subsetted by .association/navigable owned end., and here finally the desired navigability; but what a journey! We are at the very top of the UML model. Everything should be neat and elegant: this is the root. As architects, when we see such a .hard-working. attempt, the usual approach in to question the validity of the underlying concept itself. In an old debate between Bachman and Codd about the ER model of Chen, Codd said: .We definitely want sometimes to think of a relationship-relation as an entity.. This is what the composite structure is providing. This also means being able to get new eyes on what an association really is. I think this is the path to provide an effective alignment between OO and DB and even further to OWL and others. UML has the potential to do it in a very neat and elegant manner. Antoine From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, December 14, 2010 9:17 PM To: LONJON Antoine Cc: uml2-rtf@omg.org Subject: RE: New notation for attribute Antoine . I would say that the current concept of association in UML covers OO-oriented and database-oriented views, rather than EMOF and CMOF, since I don.t think MOF really was the reason for this concept in the UML superstructure. Be that as it may, I also don.t think that the concept is .ill defined.. Poorly defined, perhaps, or defined by compromise, certainly . but then, that is true of many UML constructs today! -- Ed -------------------------------------------------------------------------------- From: LONJON Antoine [mailto:antoine.lonjon@mega.com] Sent: Tuesday, December 14, 2010 3:11 PM To: Ed Seidewitz; 'Steve.Cook@microsoft.com' Cc: 'uml2-rtf@omg.org' Subject: Re: New notation for attribute Ed You said "Since all ends of an association are members of the association, ..." This "member" subsetting is very odd as "members" should be owned or inherited according to namespace definition. This just shows that association is ill defined as is trying to cover two different views of relationships as Jim said (EMOF, CMOF) The introduction of composite structure has changed the meaning of association as type of connectors. This should now be acknoledged and fixed accordingly. All the debat on ownership of properties will go away. Antoine From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, December 14, 2010 08:24 PM To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . Actually, the defining feature of a slot does not have to actually be owned by a classifier of an instance specification, it only has to be a namespace member of a classifier. Since all ends of an association are members of the association, whatever their ownership, an instance specification representing a link of an association can always have slots for any ends of the link. On the other hand, an association end is only a member of its opposite classifier if it is owned by that classifier. Therefore, an instance specification of a non-association classifier will only have slots for association ends that are owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, December 14, 2010 9:09 AM To: george.ericson@emc.com; nicolas.f.rouquette@jpl.nasa.gov; philippe.desfray@softeam.fr Cc: Yves.Bernard@airbus.com; Pete Rivett - Adaptive; Ed Seidewitz; selic@acm.org; uml2-rtf@omg.org Subject: RE: New notation for attribute George You are right: in addition to what I wrote about end ownership, it would be invalid to allocate a slot to an InstanceSpecification corresponding to a property that its classifier does not own. The link notation for InstanceSpecification has no corollary to the blob notation. You can show navigability, which would imply ownership of the slot by the instance at the other end, but not showing navigability implies nothing. -- Steve From: george.ericson@emc.com [mailto:george.ericson@emc.com] Sent: 14 December 2010 13:07 To: Steve Cook; nicolas.f.rouquette@jpl.nasa.gov; philippe.desfray@softeam.fr Cc: Yves.Bernard@airbus.com; pete.rivett@adaptive.com; ed-s@modeldriven.com; selic@acm.org; uml2-rtf@omg.org Subject: Re: New notation for attribute Useful summary. I had thought, perhaps naively, that ownership told me what classifier, (or if), a slot for the property should be allocated to.. I had not known of your use. In our use with the dmtf common information model, ifDeleted semantics are expressed explictly via a qualifier. -------------------------------------------------------------------------------- From: Steve Cook To: Rouquette, Nicolas F (316A) ; DESFRAY Philippe Cc: BERNARD, Yves ; Pete Rivett ; Ed Seidewitz ; Bran Selic ; uml2-rtf@omg.org Sent: Tue Dec 14 07:43:03 2010 Subject: RE: New notation for attribute Today UML has several different ill-defined ways to express asymmetry of an association. The .white diamond, shared aggregation. The spec admits that this has no well-defined semantics. The arrowhead for navigability. The semantics are .efficient access. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. .Ownership in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. .Ownership implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an .end property on the generated class ConnectableElement, so it must be a .navigable property, and because navigable is .deprecated in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The .dot notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end is the right way to show an attribute using .association-like notation, which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -------------------------------------------------------------------------------- !!WARNING!! MEGA moves and joins up its Paris teams on December 17th. Our phone and email connections will be affected during this time. Should you face any trouble in contacting us, please do not hesitate to call your Account Manager on his/her mobile. Please excuse any inconvenience. This e-mail, including attachments, is confidential. It is intended solely for the addressees. If you are not a recipient, any use, copy or diffusion, even in part of this message is prohibited. Please delete it and notify the sender immediately. Since the integrity of this message cannot be guaranteed on the Internet, MEGA cannot be considered liable for its content. X-IronPort-AV: E=Sophos;i="4.59,355,1288566000"; d="scan'208,217";a="33531265" From: LONJON Antoine To: Ed Seidewitz CC: "uml2-rtf@omg.org" Date: Thu, 16 Dec 2010 16:52:38 +0100 Subject: RE: New notation for attribute Thread-Topic: New notation for attribute Thread-Index: AcuYYfLlZXV6UjC7TYW9EhfbdiT6wAAKPP5wALqwGoAAAlAsgAACAE6wAAI0pr8AAaarcAALZgKwAAHIX3kAABw+YAAfDLeAABU/f7AAJhovkA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed, Thank you for your hard work in fixing inconsistencies in the UML specification. Any specification has errors and it is hard time to find them and fix them. The UML RTF team has done an incredibly good job during the last months to improve the spec down to XMI serialization. Regarding association, however, I think that we are looking at more than inconsistency fixes, but I am sure you will find a way through. Antoine From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, December 15, 2010 10:15 PM To: LONJON Antoine Cc: uml2-rtf@omg.org Subject: RE: New notation for attribute Antoine . The metamodel is well defined, even if it is not as neat and elegant as you might like. The description of member that you quote is, indeed, inconsistent with its subsetting by memberEnd, but there are many such inconsistencies in the current text of the UML spec (and many much worse than the one you identified). We are trying to correct all such inconsistencies in the spec for UML 2.5. However, any radical change to the structure of the metamodel for associations will have to wait until UML 3. -- Ed -------------------------------------------------------------------------------- From: LONJON Antoine [mailto:antoine.lonjon@mega.com] Sent: Wednesday, December 15, 2010 6:31 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: New notation for attribute Ed, I agree that the term .ill defined. is a little too sharp. I also agree that the debate is rather on OO versus Database orientation. But looking at the consistency of the association model, one could really get puzzled. The first association .association / member. subsets .memberNamespace/Member., which is a derived association with the following definition: A collection of NamedElements identifiable within the Namespace, either by being owned or by being introduced by importing or inheritance. This is a derived union. Not all association properties are owned or inherited. So we have inconsistency here, don.t we? .association / member. is itself subsetted by .owning association/owned end.. This means that ownership of association property is a subset of a derived association depending on this ownership. Hum .. .owning association/owned end. is then subsetted by .association/navigable owned end., and here finally the desired navigability; but what a journey! We are at the very top of the UML model. Everything should be neat and elegant: this is the root. As architects, when we see such a .hard-working. attempt, the usual approach in to question the validity of the underlying concept itself. In an old debate between Bachman and Codd about the ER model of Chen, Codd said: .We definitely want sometimes to think of a relationship-relation as an entity.. This is what the composite structure is providing. This also means being able to get new eyes on what an association really is. I think this is the path to provide an effective alignment between OO and DB and even further to OWL and others. UML has the potential to do it in a very neat and elegant manner. Antoine From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, December 14, 2010 9:17 PM To: LONJON Antoine Cc: uml2-rtf@omg.org Subject: RE: New notation for attribute Antoine . I would say that the current concept of association in UML covers OO-oriented and database-oriented views, rather than EMOF and CMOF, since I don.t think MOF really was the reason for this concept in the UML superstructure. Be that as it may, I also don.t think that the concept is .ill defined.. Poorly defined, perhaps, or defined by compromise, certainly . but then, that is true of many UML constructs today! -- Ed -------------------------------------------------------------------------------- From: LONJON Antoine [mailto:antoine.lonjon@mega.com] Sent: Tuesday, December 14, 2010 3:11 PM To: Ed Seidewitz; 'Steve.Cook@microsoft.com' Cc: 'uml2-rtf@omg.org' Subject: Re: New notation for attribute Ed You said "Since all ends of an association are members of the association, ..." This "member" subsetting is very odd as "members" should be owned or inherited according to namespace definition. This just shows that association is ill defined as is trying to cover two different views of relationships as Jim said (EMOF, CMOF) The introduction of composite structure has changed the meaning of association as type of connectors. This should now be acknoledged and fixed accordingly. All the debat on ownership of properties will go away. Antoine From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Tuesday, December 14, 2010 08:24 PM To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . Actually, the defining feature of a slot does not have to actually be owned by a classifier of an instance specification, it only has to be a namespace member of a classifier. Since all ends of an association are members of the association, whatever their ownership, an instance specification representing a link of an association can always have slots for any ends of the link. On the other hand, an association end is only a member of its opposite classifier if it is owned by that classifier. Therefore, an instance specification of a non-association classifier will only have slots for association ends that are owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, December 14, 2010 9:09 AM To: george.ericson@emc.com; nicolas.f.rouquette@jpl.nasa.gov; philippe.desfray@softeam.fr Cc: Yves.Bernard@airbus.com; Pete Rivett - Adaptive; Ed Seidewitz; selic@acm.org; uml2-rtf@omg.org Subject: RE: New notation for attribute George You are right: in addition to what I wrote about end ownership, it would be invalid to allocate a slot to an InstanceSpecification corresponding to a property that its classifier does not own. The link notation for InstanceSpecification has no corollary to the blob notation. You can show navigability, which would imply ownership of the slot by the instance at the other end, but not showing navigability implies nothing. -- Steve From: george.ericson@emc.com [mailto:george.ericson@emc.com] Sent: 14 December 2010 13:07 To: Steve Cook; nicolas.f.rouquette@jpl.nasa.gov; philippe.desfray@softeam.fr Cc: Yves.Bernard@airbus.com; pete.rivett@adaptive.com; ed-s@modeldriven.com; selic@acm.org; uml2-rtf@omg.org Subject: Re: New notation for attribute Useful summary. I had thought, perhaps naively, that ownership told me what classifier, (or if), a slot for the property should be allocated to.. I had not known of your use. In our use with the dmtf common information model, ifDeleted semantics are expressed explictly via a qualifier. -------------------------------------------------------------------------------- From: Steve Cook To: Rouquette, Nicolas F (316A) ; DESFRAY Philippe Cc: BERNARD, Yves ; Pete Rivett ; Ed Seidewitz ; Bran Selic ; uml2-rtf@omg.org Sent: Tue Dec 14 07:43:03 2010 Subject: RE: New notation for attribute Today UML has several different ill-defined ways to express asymmetry of an association. The .white diamond, shared aggregation. The spec admits that this has no well-defined semantics. The arrowhead for navigability. The semantics are .efficient access. Code generators will often interpret this by creating an accessor property on a generated class. Users understand the arrowheads easily and intuitively, as Philippe points out. The ownership blob. This is actually a model organization concept, and not a semantic concept at all. Of even the tiny number of UML users that are aware of this notation, most are confused about it. .Ownership in a UML model essentially determines how elements are organized in the model explorer and in the serialized XMI. An association-owned end appears nested under the association, and a class-owned end appears nested under the class. .Ownership implies delete propagation, but a tool that left the class-owned ends of an association undeleted when the association itself is deleted would be regarded as buggy, so delete is generally propagated in more cases than simply ownership, although UML does not specify these cases. Despite the availability of these three options, the UML spec has chosen yet a fourth option to express the asymmetry of the association between ConnectableElement and ConnectorEnd (figure 9.3). We use asymmetrical isDerived flags; /end is derived from role. The reason for this is because of unstated expectations about (1) the API generated from the UML metamodel (we want an .end property on the generated class ConnectableElement, so it must be a .navigable property, and because navigable is .deprecated in sophisticated meta-modelling circles, we have to make it class-owned) and (2) the model XMI implied by the metamodel (we do not want to serialize end elements under the class in the XMI, because that would require altering a thing when you simply connect to it, and class-owned ends are serialized, so we need to make it derived, but using the intrinsic logic that applies to association ends anyway). This all goes to show how very confused we are about the distinction between logical and physical and where semantics actually are. -- Steve From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 14 December 2010 11:06 To: DESFRAY Philippe Cc: BERNARD, Yves; Pete Rivett; Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Subject: Re: New notation for attribute Philippe, Instead of: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. What do you think of the following: A binary association with only one end marked by an outward direction arrow means that: 1) the marked end carries all of the essential information about the association 2) the unmarked end carries no significant information since it is logically derived as the inverse of the essential information conveyed by the marked end With directed associations, there are only 3 combinations of ownership that make sense in practice: a) the marked end is owned by the opposite class; the unmarked end is owned by the association (i.e., only the marked end property is important and the unmarked inverse end property is not) b) the marked end is owned by the opposite class; the unmarked end is owned by the opposite class (i.e., the unmarked inverse association end property is important) c) both marked & unmarked ends are owned by the association (in practice, this means that the association represents completely independent information) -- Nicolas. On Dec 14, 2010, at 1:59 AM, DESFRAY Philippe wrote: I violently disagree with this discussion. The .dot notation is to me an unnecessary physical staff introduced as a pollution to UML. This is the thing used nowhere, understood by only a few experts, that is to ditch, and now come discussion on navigability which is a fundamental heavily used notation in UML. In addition, this notation has some clarity, which is not so frequent in UML. Could we care about UML end users sometimes? The spec says: An association with one end marked by a navigability arrow means that: . the association is navigable in the direction of that end, . the marked association end is owned by the classifier, and . the opposite (unmarked) association end is owned by the association. The two last bullets are irrelevant for me: they express a physical internal staff: boring plumbing, yes with overloading semantics with the bullet. The first bullet is not well expressed. As it has been said in this thread, it is not appropriate to express precisely navigability directions and forbid other possible navigabilities. Due to the imprecise semantics (well not an exception in the UML spec), UML users have used this notation with specific interpretations. To me navigability expresses the wish of the designers to favor one navigation direction in the association. And that hint has to be interpreted for example when you map it to a framework or language · Conceptually, it expresses that a concept is based in its definition on the other (e.g. library->book) · Logically, it expresses that the association will be mostly navigated in this direction · Physically, pointers, foreign keys and any other staff will be used to implement this hint. That is personal interpretation, but that is a frequent usage of navigability. Saying that this should be used to express the UML (or other language) metamodel is a separate matter. Beware : MOF is a kind of Framework/physical implementation. The metamodeling language is designed to map with XMI, MOF infrastructures and so on : we must not confuse these physical constraints and the end user.s modeling needs. ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS (+33) 0153968400 phd@softeam.fr www.softeam.com - www.modeliosoft.com De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé mardi 14 démbre 2010 09:00 À: Rouquette, Nicolas F (316A); Pete Rivett Cc : Ed Seidewitz; Steve Cook; Bran Selic; uml2-rtf@omg.org Objet : RE: New notation for attribute Nicolas, The point is, as underlined by Bran, nobody seems to be able to give a clear and formal definition what .navigability is when considered separately from the end ownership. So do we have to include in the standard something that has no clear semantics? Folks who really need a .navigability concept (assuming it is clear in their minds) might create a stereotype. Anyway, that.s a separate issue and except if I.m wrong, it.s already registered. I.m going to open a separate one for the .association-like notation of an attribute. I agree that the current version is confusing. Yves From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: mardi 14 démbre 2010 03:39 To: Pete Rivett Cc: Ed Seidewitz; Steve Cook; Bran Selic; BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Pete, I agree about fixing the diagram editorially, assuming there exists a suitable procedure for this. I agree about disallowing navigability for CMOF metamodels and suggest migrating this notion away from the UML metamodel to a profile that would define a stereotype extending Association with a tag corresponding to Association::nagivableOwnedEnd The point is that we can preserve the capability to model association navigability for the folks who really care about such thing but we do not have to pollute the UML metamodel with concepts that can't be rigorously defined within the UML. Of course, a more radical approach would be to delete the support for navigability altogether. - Nicolas. On Dec 13, 2010, at 12:09 PM, Pete Rivett wrote: I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure. In terms of the concepts, it seems that navigability is the thing we should lose . specifically for metamodeling. What does it mean to say that it.s not possible (.efficiently.) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information? That.s not to say navigability has no value for other types of model. I don.t feel qualified to comment. Clearly some people like it. However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) . since it.s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability. This will make no difference at all to the XMI for model interchange . since it.s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, December 13, 2010 10:21 AM To: Steve Cook; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Steve . I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the .dot on the wrong end is the right way to show an attribute using .association-like notation, which will just cause even more confusion! As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don.t think it has), I don.t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved! -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Monday, December 13, 2010 1:09 PM To: Ed Seidewitz; Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute I.ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML. The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example. I don.t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 13 December 2010 17:55 To: Bran Selic Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: RE: New notation for attribute Bran . You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 .to show dot-notation. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??). In any case, I think the intention was that this notation alternative look exactly like association notation . that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:42 PM To: Ed Seidewitz Cc: BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot -- which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) -- which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention). Ugh! Overloading notations is a bad idea. Cheers...Bran On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz wrote: Bran . I don.t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association. -- Ed -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Monday, December 13, 2010 12:14 PM To: Steve Cook Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org Subject: Re: New notation for attribute Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong? In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion -- such as the case above (regardless of whether I am right or wrong above). Cheers...Bran On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook wrote: I believe this option is already there: see figure 7.31. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 11 December 2010 11:59 To: BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: New notation for attribute Yves, This idea makes sense as part of the Diagram Definition for UML. - Nicolas. On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote: According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly: · Capability to get a modular diagram thanks to the .link notation · Capability to show the aggregation kind However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation. What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link? Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -------------------------------------------------------------------------------- !!WARNING!! MEGA moves and joins up its Paris teams on December 17th. Our phone and email connections will be affected during this time. Should you face any trouble in contacting us, please do not hesitate to call your Account Manager on his/her mobile. Please excuse any inconvenience. This e-mail, including attachments, is confidential. It is intended solely for the addressees. If you are not a recipient, any use, copy or diffusion, even in part of this message is prohibited. Please delete it and notify the sender immediately. Since the integrity of this message cannot be guaranteed on the Internet, MEGA cannot be considered liable for its content.