Issue 15237: issue10087 and association-like notation (uml2-rtf) Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com) Nature: Uncategorized Issue Severity: Summary: No problem with the issue itself or the proposed resolution. I’m just wondering about the principle of the “association-like notation”. My concerns: The specification says that “An attribute may also be shown using association notation”. Nevertheless, defining an attribute or using an association as described in figure 7.31 is not the same thing. The definition of one attribute generates only one property while the definition of a binary association generates two properties plus a classifier for the association itself. If it’s only a matter of notation, how to distinguish in a diagram between: a) an attribute with an association-like notation and b) a “true” association? Yves Resolution: Revised Text: Actions taken: March 23, 2010: received issue Discussion: End of Annotations:===== m: Steve Cook To: "juergen@omg.org" Subject: FW: About #100087 and association-like notation Thread-Topic: About #100087 and association-like notation Thread-Index: AcrE/4Yd5lzAkldGSAmXBbasMLHO4gAtQR3wAUHX4aA= Date: Tue, 23 Mar 2010 19:07:12 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Juergen Can you log the issue below please? Thanks -- Steve From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 17 March 2010 09:32 To: BERNARD, Yves; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: About #100087 and association-like notation Yves Copying to issues@omg.org . this is a new issue. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 16 March 2010 11:55 To: uml2-rtf@omg.org Subject: About #100087 and association-like notation No problem with the issue itself or the proposed resolution. I.m just wondering about the principle of the .association-like notation.. My concerns: The specification says that .An attribute may also be shown using association notation.. Nevertheless, defining an attribute or using an association as described in figure 7.31 is not the same thing. The definition of one attribute generates only one property while the definition of a binary association generates two properties plus a classifier for the association itself. If it.s only a matter of notation, how to distinguish in a diagram between: a) an attribute with an association-like notation and b) a .true. association? 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: About #100087 and association-like notation Date: Tue, 16 Mar 2010 12:55:08 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: About #100087 and association-like notation Thread-Index: AcrE/4Yd5lzAkldGSAmXBbasMLHO4g== From: "BERNARD, Yves" To: X-OriginalArrivalTime: 16 Mar 2010 11:55:08.0426 (UTC) FILETIME=[8669B6A0:01CAC4FF] No problem with the issue itself or the proposed resolution. I.m just wondering about the principle of the .association-like notation.. My concerns: The specification says that .An attribute may also be shown using association notation.. Nevertheless, defining an attribute or using an association as described in figure 7.31 is not the same thing. The definition of one attribute generates only one property while the definition of a binary association generates two properties plus a classifier for the association itself. If it.s only a matter of notation, how to distinguish in a diagram between: a) an attribute with an association-like notation and b) a .true. association? 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: FW: About #100087 and association-like notation Date: Fri, 26 Mar 2010 16:12:37 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: About #100087 and association-like notation Thread-Index: AcrE/4Yd5lzAkldGSAmXBbasMLHO4gAtQR3wAeDa6+A= From: "Pete Rivett" To: "Juergen Boldt" , "Steve Cook" I cannot trace this issue under UML . was it ever filed by you, Juergen? For completeness it should be added that it applies to section 7.3.8 Classifier . which seems a bit surprising (why not under Property?). Maybe at UML 2.5 we.ll rationalize where we place notation descriptions. A potential answer to the question is that if the Property::type is a kind of DataType then there is no Association (or opposite Property) otherwise there is. In addition to the point raised, the illustrated notation uses a navigability arrow which I think should be replaced by the .dot. notation. I think this is an important issue to address in UML 2.4. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Wednesday, March 17, 2010 2:32 AM To: BERNARD, Yves; issues@omg.org Cc: uml2-rtf@omg.org Subject: RE: About #100087 and association-like notation Yves Copying to issues@omg.org . this is a new issue. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 16 March 2010 11:55 To: uml2-rtf@omg.org Subject: About #100087 and association-like notation No problem with the issue itself or the proposed resolution. I.m just wondering about the principle of the .association-like notation.. My concerns: The specification says that .An attribute may also be shown using association notation.. Nevertheless, defining an attribute or using an association as described in figure 7.31 is not the same thing. The definition of one attribute generates only one property while the definition of a binary association generates two properties plus a classifier for the association itself. If it.s only a matter of notation, how to distinguish in a diagram between: a) an attribute with an association-like notation and b) a .true. association? 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: "uml25-ftf@omg.org" Date: Thu, 14 Feb 2013 10:59:58 +0100 Subject: [UML 2.5 FTF] ballot2 review: #15237 Thread-Topic: [UML 2.5 FTF] ballot2 review: #15237 Thread-Index: Ac4KmgvvqK9ENWxzQ0alhKrAj6GpdQ== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org I disagree with the proposed resolution. The point raised is that a differentiating notation is required to distinguish between part resulting from an association and those which are defined as ownedAttribute. Diagrams. main interest is to communicate and to validate our models; such ambiguities in the notation shall be avoided. 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: "BERNARD, Yves" , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] ballot2 review: #15237 Thread-Topic: [UML 2.5 FTF] ballot2 review: #15237 Thread-Index: Ac4KmgvvqK9ENWxzQ0alhKrAj6GpdQACLWtw Date: Thu, 14 Feb 2013 11:10:43 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.104] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(199002)(189002)(365934001)(76482001)(51856001)(33656001)(59766001)(56816002)(80022001)(46102001)(53806001)(63696002)(20776003)(56776001)(47736001)(54316002)(49866001)(55846006)(65816001)(77982001)(4396001)(50986001)(15202345001)(31966008)(54356001)(79102001)(44976002)(16236675001)(16406001)(74502001)(5343655001)(512954001)(47446002)(47976001)(5343635001)(74662001);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB034;H:TK5EX14HUBC104.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0757EEBDCA X-Virus-Scanned: amavisd-new at omg.org Yves It.s just a fact that there are areas of UML where the notation is ambiguous, and this is one of them. I don.t believe that it is within the scope of UML 2.5 either to remove or add notation, unless it is essential to clarify the specification. This ambiguous notation was put into UML for a reason - to enable UML diagrams to be able to depict EMOF or ECore models, as well as reverse engineered programs in OO languages. I would like to let this resolution continue in the ballot to a vote, and I encourage others to review it before voting on it. Thanks -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 14 February 2013 10:00 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot2 review: #15237 I disagree with the proposed resolution. The point raised is that a differentiating notation is required to distinguish between part resulting from an association and those which are defined as ownedAttribute. Diagrams. main interest is to communicate and to validate our models; such ambiguities in the notation shall be avoided. 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: "BERNARD, Yves" , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] ballot2 review: #15237 Thread-Topic: [UML 2.5 FTF] ballot2 review: #15237 Thread-Index: Ac4KmgvvqK9ENWxzQ0alhKrAj6GpdQACLWtwAAB/0QAAADmvMA== Date: Thu, 14 Feb 2013 11:23:34 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.104] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(164054002)(365934001)(199002)(189002)(47446002)(46102001)(56776001)(65816001)(16236675001)(74662001)(54356001)(33656001)(74502001)(80022001)(79102001)(53806001)(31966008)(77982001)(59766001)(76482001)(51856001)(50986001)(47976001)(55846006)(54316002)(5343655001)(49866001)(5343635001)(63696002)(47736001)(512934001)(16406001)(56816002)(4396001)(20776003)(44976002);DIR:OUT;SFP:;SCL:1;SRVR:BY2FFO11HUB035;H:TK5EX14HUBC106.redmond.corp.microsoft.com;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0757EEBDCA X-Virus-Scanned: amavisd-new at omg.org Let.s discuss on Tuesday.s call. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 14 February 2013 11:19 To: Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #15237 Steeve, On the other hand, if you consider it is out of the 2.5/FTF scope it should be deferred, shouldn.t it? Thanks, Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 14 fĂ©ier 2013 12:11 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #15237 Yves It.s just a fact that there are areas of UML where the notation is ambiguous, and this is one of them. I don.t believe that it is within the scope of UML 2.5 either to remove or add notation, unless it is essential to clarify the specification. This ambiguous notation was put into UML for a reason - to enable UML diagrams to be able to depict EMOF or ECore models, as well as reverse engineered programs in OO languages. I would like to let this resolution continue in the ballot to a vote, and I encourage others to review it before voting on it. Thanks -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 14 February 2013 10:00 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot2 review: #15237 I disagree with the proposed resolution. The point raised is that a differentiating notation is required to distinguish between part resulting from an association and those which are defined as ownedAttribute. Diagrams. main interest is to communicate and to validate our models; such ambiguities in the notation shall be avoided. 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. 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 CC: "uml25-ftf@omg.org" Date: Thu, 14 Feb 2013 12:31:15 +0100 Subject: RE: [UML 2.5 FTF] ballot2 review: #15237 Thread-Topic: [UML 2.5 FTF] ballot2 review: #15237 Thread-Index: Ac4KmgvvqK9ENWxzQ0alhKrAj6GpdQACLWtwAAB/0QAAADmvMAAAJWcg Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Steeve, Sorry, but I won.t be able to attend the next meeting. More, the vote will start on Monday, except if you allow additional time for the review as requested by Conrad and me (at least). Thanks, Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 14 fĂ©ier 2013 12:24 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #15237 Let.s discuss on Tuesday.s call. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 14 February 2013 11:19 To: Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #15237 Steeve, On the other hand, if you consider it is out of the 2.5/FTF scope it should be deferred, shouldn.t it? Thanks, Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 14 fĂ©ier 2013 12:11 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #15237 Yves It.s just a fact that there are areas of UML where the notation is ambiguous, and this is one of them. I don.t believe that it is within the scope of UML 2.5 either to remove or add notation, unless it is essential to clarify the specification. This ambiguous notation was put into UML for a reason - to enable UML diagrams to be able to depict EMOF or ECore models, as well as reverse engineered programs in OO languages. I would like to let this resolution continue in the ballot to a vote, and I encourage others to review it before voting on it. Thanks -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 14 February 2013 10:00 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot2 review: #15237 I disagree with the proposed resolution. The point raised is that a differentiating notation is required to distinguish between part resulting from an association and those which are defined as ownedAttribute. Diagrams. main interest is to communicate and to validate our models; such ambiguities in the notation shall be avoided. 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. 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. 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 , "uml25-ftf@omg.org" Date: Thu, 14 Feb 2013 12:19:09 +0100 Subject: RE: [UML 2.5 FTF] ballot2 review: #15237 Thread-Topic: [UML 2.5 FTF] ballot2 review: #15237 Thread-Index: Ac4KmgvvqK9ENWxzQ0alhKrAj6GpdQACLWtwAAB/0QA= Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Steeve, On the other hand, if you consider it is out of the 2.5/FTF scope it should be deferred, shouldn.t it? Thanks, Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 14 fĂ©ier 2013 12:11 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #15237 Yves It.s just a fact that there are areas of UML where the notation is ambiguous, and this is one of them. I don.t believe that it is within the scope of UML 2.5 either to remove or add notation, unless it is essential to clarify the specification. This ambiguous notation was put into UML for a reason - to enable UML diagrams to be able to depict EMOF or ECore models, as well as reverse engineered programs in OO languages. I would like to let this resolution continue in the ballot to a vote, and I encourage others to review it before voting on it. Thanks -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 14 February 2013 10:00 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot2 review: #15237 I disagree with the proposed resolution. The point raised is that a differentiating notation is required to distinguish between part resulting from an association and those which are defined as ownedAttribute. Diagrams. main interest is to communicate and to validate our models; such ambiguities in the notation shall be avoided. 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. 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: [UML 2.5 FTF] ballot2 review: #15237 Date: Thu, 14 Feb 2013 08:28:30 -0800 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [UML 2.5 FTF] ballot2 review: #15237 Thread-Index: Ac4KmgvvqK9ENWxzQ0alhKrAj6GpdQACLWtwAAB/0QAAADmvMAAIeQ9A From: "Pete Rivett" To: "Steve Cook" , "BERNARD, Yves" , X-Virus-Scanned: amavisd-new at omg.org (I.ll be on customer site again Tuesday so won.t be able to make the call.) I agree with Yves . it.s surely not good that the notation is ambiguous. Normally ambiguity is caused by having elided notation . however AFAIK this case is unique in that there is no notation that could be added to remove the ambiguity. If a particular platform wants to ignore Associations (e.g. when generating code) that.s what they should do (and when they should do it): it should not result in associations being omitted from the original model. For other platforms such as databases, Associations may be converted into foreign keys, or if many-to-many, a separate link table with foreign keys. In fact creating a separate class in the middle would be a better way to implement Associations in EMF/Java. But that should be left as an implementation/generation decision which should not pollute the model . is that not what platform independence is meant to be about? And if people really do want a platform specific model they should use tags/stereotypes to indicate the choices (e.g. a stereotype <> on an association line). From a practical tooling point of view, using MagicDraw when I use the capability to drag an attribute out of a class compartment it does use the association notation (below) but it then converts it to an actual Association in the model! In Enterprise Architect I could not even work out (though I.m no expert) how to use the association notation for attributes . if I tried to .quick link. from a Class to a Primitive (or a DataType) I only got options of Dependency, Information Flow and Trace. I know this is not an argument for the spec, but if leading tools do not allow for use of association notation without an Association then it.s worth taking note. In summary if the current proposed resolution goes into the ballot I will vote NO. I would be OK with saying one of: - The line notation always represents an Association - The line notation represents an Association iff both ends are kinds of Class, and not an Association otherwise (i.e. a datatype/primitive/enumeration is involved). This could be represented as an OCL constraint (i.e. Property::association must be empty if the type of either end is not oclKindOf(Class)) I actually prefer the second of these . since to me Associations only make semantic sense where there are objects with identity. This also reflects the Enterprise Architect behavior where it does not allow creation of Associations with datatypes. Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, February 14, 2013 3:24 AM To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #15237 Let.s discuss on Tuesday.s call. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 14 February 2013 11:19 To: Steve Cook; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #15237 Steeve, On the other hand, if you consider it is out of the 2.5/FTF scope it should be deferred, shouldn.t it? Thanks, Yves From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: jeudi 14 fĂ©ier 2013 12:11 To: BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] ballot2 review: #15237 Yves It.s just a fact that there are areas of UML where the notation is ambiguous, and this is one of them. I don.t believe that it is within the scope of UML 2.5 either to remove or add notation, unless it is essential to clarify the specification. This ambiguous notation was put into UML for a reason - to enable UML diagrams to be able to depict EMOF or ECore models, as well as reverse engineered programs in OO languages. I would like to let this resolution continue in the ballot to a vote, and I encourage others to review it before voting on it. Thanks -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 14 February 2013 10:00 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot2 review: #15237 I disagree with the proposed resolution. The point raised is that a differentiating notation is required to distinguish between part resulting from an association and those which are defined as ownedAttribute. Diagrams. main interest is to communicate and to validate our models; such ambiguities in the notation shall be avoided. 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. 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. Date: Tue, 19 Feb 2013 14:50:14 +0000 From: Dave Hawkins User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: Pete Rivett CC: Steve Cook , "BERNARD, Yves" , uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] ballot2 review: #15237 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh0YtZgdGM0o X-Brightmail-Tracker: AAAAAA== I agree with Yves and Pete here. The notation shouldn't be unnecessarily ambiguous. In JDeveloper we don't have support for showing UML owned attributes as associations. Dave On 14/02/13 16:28, Pete Rivett wrote: (I.ll be on customer site again Tuesday so won.t be able to make the call.) I agree with Yves ­ it.s surely not good that the notation is ambiguous. Normally ambiguity is caused by having elided notation ­ however AFAIK this case is unique in that there is no notation that could be added to remove the ambiguity. If a particular platform wants to ignore Associations (e.g. when generating code) that.s what they should do (and when they should do it): it should not result in associations being omitted from the original model. For other platforms such as databases, Associations may be converted into foreign keys, or if many-to-many, a separate link table with foreign keys. In fact creating a separate class in the middle would be a better way to implement Associations in EMF/Java. But that should be left as an implementation/generation decision which should not pollute the model ­ is that not what platform independence is meant to be about? And if people really do want a platform specific model they should use tags/stereotypes to indicate the choices (e.g. a stereotype <> on an association line). From a practical tooling point of view, using MagicDraw when I use the capability to drag an attribute out of a class compartment it does use the association notation (below) but it then converts it to an actual Association in the model! In Enterprise Architect I could not even work out (though I.m no expert) how to use the association notation for attributes ­ if I tried to .quick link. from a Class to a Primitive (or a DataType) I only got options of Dependency, Information Flow and Trace. I know this is not an argument for the spec, but if leading tools do not allow for use of association notation without an Association then it.s worth taking note. In summary if the current proposed resolution goes into the ballot I will vote NO. I would be OK with saying one of: -The line notation always represents an Association -The line notation represents an Association iff both ends are kinds of Class, and not an Association otherwise (i.e. a datatype/primitive/enumeration is involved). This could be represented as an OCL constraint (i.e. Property::association must be empty if the type of either end is not oclKindOf(Class)) I actually prefer the second of these ­ since to me Associations only make semantic sense where there are objects with identity. This also reflects the Enterprise Architect behavior where it does not allow creation of Associations with datatypes. Pete *From:*Steve Cook [mailto:Steve.Cook@microsoft.com] *Sent:* Thursday, February 14, 2013 3:24 AM *To:* BERNARD, Yves; uml25-ftf@omg.org *Subject:* RE: [UML 2.5 FTF] ballot2 review: #15237 Let.s discuss on Tuesday.s call. -- Steve *From:*BERNARD, Yves [mailto:Yves.Bernard@airbus.com] *Sent:* 14 February 2013 11:19 *To:* Steve Cook; uml25-ftf@omg.org *Subject:* RE: [UML 2.5 FTF] ballot2 review: #15237 Steeve, On the other hand, if you consider it is out of the 2.5/FTF scope it should be deferred, shouldn.t it? Thanks, Yves *From:*Steve Cook [mailto:Steve.Cook@microsoft.com] *Sent:* jeudi 14 fĂ©ier 2013 12:11 *To:* BERNARD, Yves; uml25-ftf@omg.org *Subject:* RE: [UML 2.5 FTF] ballot2 review: #15237 Yves It.s just a fact that there are areas of UML where the notation is ambiguous, and this is one of them. I don.t believe that it is within the scope of UML 2.5 either to remove or add notation, unless it is essential to clarify the specification. This ambiguous notation was put into UML for a reason - to enable UML diagrams to be able to depict EMOF or ECore models, as well as reverse engineered programs in OO languages. I would like to let this resolution continue in the ballot to a vote, and I encourage others to review it before voting on it. Thanks -- Steve *From:*BERNARD, Yves [mailto:Yves.Bernard@airbus.com] *Sent:* 14 February 2013 10:00 *To:* uml25-ftf@omg.org *Subject:* [UML 2.5 FTF] ballot2 review: #15237 I disagree with the proposed resolution. The point raised is that a differentiating notation is required to distinguish between part resulting from an association and those which are defined as ownedAttribute. Diagrams. main interest is to communicate and to validate our models; such ambiguities in the notation shall be avoided. 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. 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. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.