Issue 13908: there are numerous places where associations between UML elements have only one, navigable role (uml2-rtf) Source: PTC (Mr. Phillip Astle, nobody) Nature: Enhancement Severity: Significant Summary: In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin. Resolution: Revised Text: Actions taken: April 29, 2009: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 29 Apr 2009 12:56:26 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML) Superstructure Section: General FormalNumber: formal/2007-11-02 Version: V2.1.2 RevisionDate: 2007-11-02 Page: All Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=D0gjHMkAixDG5bg9vbIsxTx/SY0QfvkRb4j6Pmapq/U=; b=VDGyn0epi9mTTcSkI564zXYYTQ6xUUVOC78JtS2YtrqTjDL1HsQWFSTC+SbBlwpIo8 2ZsHtBfqk8L+H0dlrQEkb3oUoHOIO8kYT4YZ5Re6CR/BitXeXZUWyVj2Jy5JeCCkXY0k 7DnOjqFftSH1AasWC5gdYg+89s6Q9cbjiyqXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=p9G9d1nocEW47kAvSNL9FVJwUOUtSHvMyYgitQhHRkBwJETLvJ/o4XcZdi3b46+Hi3 sPPf5M+Kxs8bT2Nw0GHElFAPTeEm4gGuyYH3PH/1KgnPdLnsYo52hcMvlA8crDrueCjY IPU8j57d+KknBvZqPUykHiE6N42NycGkiHTQU= Date: Wed, 29 Apr 2009 21:05:01 -0400 Subject: Re: issue 13908 -- UML 2 RTF issue From: Bran Selic To: Juergen Boldt Cc: uml2-rtf@omg.org This issue needs more clarification. I cannot see how navigability, which is a run-time constraint, can have any impact on the definition of derivation formulas, in profiles or otherwise. Keep in mind that OCL ignores navigability and, as Conrad pointed out, association ends without names get default names (I believe that this is defined in the OCL spec). This means that one can freely write OCL constraints that involve unnamed non-navigable ends. If any other language is used for the constraint, the same conventions can be defined for that language. Making all association ends navigable in the metamodel would have immense consequences on existing implementations that conform to the standard (I am not sure what the submitter means when he says that all vendors implement bi-directional relationships--several vendors actually include the standard metamodel directly insider their tools). Remember that navigability in the UML spec is used to specify link end ownership. As currently stated, this issue should clearly be rejected. Cheers...Bran On Wed, Apr 29, 2009 at 1:31 PM, Juergen Boldt wrote: From: webmaster@omg.org Date: 29 Apr 2009 12:56:26 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML) Superstructure Section: General FormalNumber: formal/2007-11-02 Version: V2.1.2 RevisionDate: 2007-11-02 Page: All Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: Steve Cook To: Bran Selic CC: "uml2-rtf@omg.org" Date: Thu, 30 Apr 2009 10:37:47 +0100 Subject: RE: issue 13908 -- UML 2 RTF issue Thread-Topic: issue 13908 -- UML 2 RTF issue Thread-Index: AcnJMPcZqNZ1NLIPThyb6MlB/jRbKAARRQ7Q Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Bran I do agree with you that making all ends navigable would have a big impact. However as Ed recently pointed out to me in a discussion about issue 10536, by the conventions used in the UML abstract syntax metamodel, only navigable ends are actually referenced by name in OCL constraints. Although in the OCL spec it is possible (it is actually a compliance point) to refer to non-navigable ends, the UML spec does not do it. This simplifies the interpretation of the spec and the implementation of OCL. Hence the resolution to 10536, which is essentially a workaround for the fact that we want non-navigable ends and we also want to constrain them. -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 30 April 2009 02:05 To: Juergen Boldt Cc: uml2-rtf@omg.org Subject: Re: issue 13908 -- UML 2 RTF issue This issue needs more clarification. I cannot see how navigability, which is a run-time constraint, can have any impact on the definition of derivation formulas, in profiles or otherwise. Keep in mind that OCL ignores navigability and, as Conrad pointed out, association ends without names get default names (I believe that this is defined in the OCL spec). This means that one can freely write OCL constraints that involve unnamed non-navigable ends. If any other language is used for the constraint, the same conventions can be defined for that language. Making all association ends navigable in the metamodel would have immense consequences on existing implementations that conform to the standard (I am not sure what the submitter means when he says that all vendors implement bi-directional relationships--several vendors actually include the standard metamodel directly insider their tools). Remember that navigability in the UML spec is used to specify link end ownership. As currently stated, this issue should clearly be rejected. Cheers...Bran On Wed, Apr 29, 2009 at 1:31 PM, Juergen Boldt wrote: From: webmaster@omg.org Date: 29 Apr 2009 12:56:26 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML) Superstructure Section: General FormalNumber: formal/2007-11-02 Version: V2.1.2 RevisionDate: 2007-11-02 Page: All Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Error! Filename not specified. Date: Thu, 30 Apr 2009 19:10:20 +0100 From: Dave Hawkins User-Agent: Thunderbird 2.0.0.6 (X11/20070728) To: Steve Cook CC: Bran Selic , "uml2-rtf@omg.org" Subject: Re: issue 13908 -- UML 2 RTF issue X-Source-IP: acsmt703.oracle.com [141.146.40.81] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A09020B.49F9E9C8.02BF:SCFMA4539814,ss=1,fgs=0 It sounds like the problem is not whether associations are bidirectional, but the ambiguity that exists for unidirectional associations. OCL section 7.5.3 says that if the rolename is ambiguous it cannot be navigated. This is quite common for UML unidirectional associations. For example, consider InformationFlow, as mentioned in the issue, and Classifier. There are three non-navigable ends for Classifier named "informationFlow". The relevant associations are: A_conveyed_informationFlow-informationFlow A_informationSource_informationFlow-informationFlow A_informationTarget_informationFlow-informationFlow While these could all be navigated in the same manner as the resolution to 10536 by using an allInstances() expression (which, incidentally, is also an OCL compliance point), it's a little cumbersome. Is there an easier syntax that could be proposed for OCL? Cheers, Dave Steve Cook wrote: Bran I do agree with you that making all ends navigable would have a big impact. However as Ed recently pointed out to me in a discussion about issue 10536, by the conventions used in the UML abstract syntax metamodel, only navigable ends are actually referenced by name in OCL constraints. Although in the OCL spec it is possible (it is actually a compliance point) to refer to non-navigable ends, the UML spec does not do it. This simplifies the interpretation of the spec and the implementation of OCL. Hence the resolution to 10536, which is essentially a workaround for the fact that we want non-navigable ends and we also want to constrain them. -- Steve *From:* Bran Selic [mailto:bran.selic@gmail.com] *Sent:* 30 April 2009 02:05 *To:* Juergen Boldt *Cc:* uml2-rtf@omg.org *Subject:* Re: issue 13908 -- UML 2 RTF issue This issue needs more clarification. I cannot see how navigability, which is a run-time constraint, can have any impact on the definition of derivation formulas, in profiles or otherwise. Keep in mind that OCL ignores navigability and, as Conrad pointed out, association ends without names get default names (I believe that this is defined in the OCL spec). This means that one can freely write OCL constraints that involve unnamed non-navigable ends. If any other language is used for the constraint, the same conventions can be defined for that language. Making all association ends navigable in the metamodel would have immense consequences on existing implementations that conform to the standard (I am not sure what the submitter means when he says that all vendors implement bi-directional relationships--several vendors actually include the standard metamodel directly insider their tools). Remember that navigability in the UML spec is used to specify link end ownership. As currently stated, this issue should clearly be rejected. Cheers...Bran On Wed, Apr 29, 2009 at 1:31 PM, Juergen Boldt > wrote: From: webmaster@omg.org Date: 29 Apr 2009 12:56:26 -0400 To: > Subject: Issue/Bug Report ------------------------------------------------------------------------ * *Name: *Phillip Astle * *Company: *Artisan Software Tools * *mailFrom: *phillip.astle@artisansoftwaretools.com * *Notification: *No * *Specification: *OMG Unified Modeling Language (OMG UML) Superstructure * *Section: *General * *FormalNumber: *formal/2007-11-02 * *Version: *V2.1.2 * *RevisionDate: *2007-11-02 * *Page: *All * *Nature: *Enhancement * *Severity: *Significant * *HTTP User Agent: *Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin. * Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org **Error! Filename not specified.* -- 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. Subject: RE: issue 13908 -- UML 2 RTF issue Date: Thu, 30 Apr 2009 11:55:24 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 13908 -- UML 2 RTF issue Thread-Index: AcnJMPcZqNZ1NLIPThyb6MlB/jRbKAARRQ7QABL6+PA= From: "Pete Rivett" To: "Steve Cook" , "Bran Selic" Cc: In the normative definition of the UML metamodel (the XMI), all ends (and indeed all Associations) are explicitly named: this is in fact a requirement for any CMOF metamodel. The fact that they are not shown on diagrams is utterly irrelevant. I.m not aware of any convention that .only navigable ends are referenced by name in OCL constraints.: all I could find is that .Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints. which I read to mean the opposite . that specific ends are left unnamed (on diagrams) because they do not need to be referenced in constraints. If a name is needed in constraints then surely it can be shown on diagrams . note that this has no effect on the name (which is in the metamodel anyway), navigability or end ownership . Pete PS In any such discussion of .navigable. we should be careful to distinguish: a) Ends which have isNavigable=false b) Ends which use the convention peculiar to the UML spec which depicts end ownership using a navigability arrow (as opposed to the official .dot. notation): I.d hope that a subsequent revision of the spec will move to the official notation Case a) - relates to whether the navigation is .efficient.. Case b) relates to whether there is a property on the end Class. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 30 April 2009 02:38 To: Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Bran I do agree with you that making all ends navigable would have a big impact. However as Ed recently pointed out to me in a discussion about issue 10536, by the conventions used in the UML abstract syntax metamodel, only navigable ends are actually referenced by name in OCL constraints. Although in the OCL spec it is possible (it is actually a compliance point) to refer to non-navigable ends, the UML spec does not do it. This simplifies the interpretation of the spec and the implementation of OCL. Hence the resolution to 10536, which is essentially a workaround for the fact that we want non-navigable ends and we also want to constrain them. -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 30 April 2009 02:05 To: Juergen Boldt Cc: uml2-rtf@omg.org Subject: Re: issue 13908 -- UML 2 RTF issue This issue needs more clarification. I cannot see how navigability, which is a run-time constraint, can have any impact on the definition of derivation formulas, in profiles or otherwise. Keep in mind that OCL ignores navigability and, as Conrad pointed out, association ends without names get default names (I believe that this is defined in the OCL spec). This means that one can freely write OCL constraints that involve unnamed non-navigable ends. If any other language is used for the constraint, the same conventions can be defined for that language. Making all association ends navigable in the metamodel would have immense consequences on existing implementations that conform to the standard (I am not sure what the submitter means when he says that all vendors implement bi-directional relationships--several vendors actually include the standard metamodel directly insider their tools). Remember that navigability in the UML spec is used to specify link end ownership. As currently stated, this issue should clearly be rejected. Cheers...Bran On Wed, Apr 29, 2009 at 1:31 PM, Juergen Boldt wrote: From: webmaster@omg.org Date: 29 Apr 2009 12:56:26 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML) Superstructure Section: General FormalNumber: formal/2007-11-02 Version: V2.1.2 RevisionDate: 2007-11-02 Page: All Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Error! Filename not specified. Subject: RE: issue 13908 -- UML 2 RTF issue Date: Thu, 30 Apr 2009 12:24:05 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 13908 -- UML 2 RTF issue Thread-Index: AcnJv1u+lRUj5WWAS9KxHR8B/WQSiAACT2Sg From: "Pete Rivett" To: "Dave Hawkins" , "Steve Cook" Cc: "Bran Selic" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n3UJTJhD019936 As per my earlier email, all ends have a name and, if owned by an Association, can be uniquely identified through qualification with the association name (as you listed). So the syntax might involve long names but is not cumbersome as in allInstances() - which in general I don't like since one cannot predict the runtime context (the set of extents which will be examined) when writing the constraint. Pete -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: 30 April 2009 11:10 To: Steve Cook Cc: Bran Selic; uml2-rtf@omg.org Subject: Re: issue 13908 -- UML 2 RTF issue It sounds like the problem is not whether associations are bidirectional, but the ambiguity that exists for unidirectional associations. OCL section 7.5.3 says that if the rolename is ambiguous it cannot be navigated. This is quite common for UML unidirectional associations. For example, consider InformationFlow, as mentioned in the issue, and Classifier. There are three non-navigable ends for Classifier named "informationFlow". The relevant associations are: A_conveyed_informationFlow-informationFlow A_informationSource_informationFlow-informationFlow A_informationTarget_informationFlow-informationFlow While these could all be navigated in the same manner as the resolution to 10536 by using an allInstances() expression (which, incidentally, is also an OCL compliance point), it's a little cumbersome. Is there an easier syntax that could be proposed for OCL? Cheers, Dave Steve Cook wrote: > Bran > > > > I do agree with you that making all ends navigable would have a big impact. > > > > However as Ed recently pointed out to me in a discussion about issue > 10536, by the conventions used in the UML abstract syntax metamodel, > only navigable ends are actually referenced by name in OCL > constraints. Although in the OCL spec it is possible (it is actually > a compliance point) to refer to non-navigable ends, the UML spec does > not do it. This simplifies the interpretation of the spec and the > implementation of OCL. Hence the resolution to 10536, which is > essentially a workaround for the fact that we want non-navigable ends > and we also want to constrain them. > > > > -- Steve > > > > > > *From:* Bran Selic [mailto:bran.selic@gmail.com] > *Sent:* 30 April 2009 02:05 > *To:* Juergen Boldt > *Cc:* uml2-rtf@omg.org > *Subject:* Re: issue 13908 -- UML 2 RTF issue > > > > This issue needs more clarification. I cannot see how navigability, > which is a run-time constraint, can have any impact on the definition of > derivation formulas, in profiles or otherwise. Keep in mind that OCL > ignores navigability and, as Conrad pointed out, association ends > without names get default names (I believe that this is defined in the > OCL spec). This means that one can freely write OCL constraints that > involve unnamed non-navigable ends. If any other language is used for > the constraint, the same conventions can be defined for that language. > > Making all association ends navigable in the metamodel would have > immense consequences on existing implementations that conform to the > standard (I am not sure what the submitter means when he says that all > vendors implement bi-directional relationships--several vendors actually > include the standard metamodel directly insider their tools). Remember > that navigability in the UML spec is used to specify link end ownership. > > As currently stated, this issue should clearly be rejected. > > Cheers...Bran > > On Wed, Apr 29, 2009 at 1:31 PM, Juergen Boldt > wrote: > > > > From: webmaster@omg.org > Date: 29 Apr 2009 12:56:26 -0400 > To: > > Subject: Issue/Bug Report > > ------------------------------------------------------------------------ > > * *Name: *Phillip Astle > * *Company: *Artisan Software Tools > * *mailFrom: *phillip.astle@artisansoftwaretools.com > > * *Notification: *No > * *Specification: *OMG Unified Modeling Language (OMG UML) > Superstructure > * *Section: *General > * *FormalNumber: *formal/2007-11-02 > * *Version: *V2.1.2 > * *RevisionDate: *2007-11-02 > * *Page: *All > * *Nature: *Enhancement > * *Severity: *Significant > * *HTTP User Agent: *Mozilla/4.0 (compatible; MSIE 7.0; Windows NT > 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; > MS-RTC LM 8) > > > > > Description > > > > In the specification there are numerous places where associations > between UML elements have only one, navigable role. This seriously > restricts the ability of derived properties that are added as part of a > profile. Though most tool vendors implement bi-directional relationships > for everything anyway, this doesn't help at all when you're trying to > define the implementation of the derived property (i.e. tag), as part of > a property. It is my belief that all associations in UML should be > bi-directional to support a method of non-ambiguous definition. A couple > of obvious examples are: 1. Navigating from a realizing relationship to > a realized InformationFlow. 2. Navigating from an ActivityEdge to an > Action via a Pin. > > > > * > > Juergen Boldt > Director, Member Services > Object Management Group > 140 Kendrick St > Building A Suite 300 > Needham, MA 02494 > USA > > tel: +1 781 444 0404 x 132 > fax: +1 781 444 0320 > email: juergen@omg.org > www.omg.org > > **Error! Filename not specified.* > > > > > > -- 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. From: Steve Cook To: Pete Rivett , Bran Selic CC: "uml2-rtf@omg.org" Date: Fri, 1 May 2009 10:17:27 +0100 Subject: RE: issue 13908 -- UML 2 RTF issue Thread-Topic: issue 13908 -- UML 2 RTF issue Thread-Index: AcnJMPcZqNZ1NLIPThyb6MlB/jRbKAARRQ7QABL6+PAAHtOGwA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Pete If what you say is correct then the resolution to 10536 is absurd. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 30 April 2009 19:55 To: Steve Cook; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue In the normative definition of the UML metamodel (the XMI), all ends (and indeed all Associations) are explicitly named: this is in fact a requirement for any CMOF metamodel. The fact that they are not shown on diagrams is utterly irrelevant. I.m not aware of any convention that .only navigable ends are referenced by name in OCL constraints.: all I could find is that .Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints. which I read to mean the opposite . that specific ends are left unnamed (on diagrams) because they do not need to be referenced in constraints. If a name is needed in constraints then surely it can be shown on diagrams . note that this has no effect on the name (which is in the metamodel anyway), navigability or end ownership . Pete PS In any such discussion of .navigable. we should be careful to distinguish: a) Ends which have isNavigable=false b) Ends which use the convention peculiar to the UML spec which depicts end ownership using a navigability arrow (as opposed to the official .dot. notation): I.d hope that a subsequent revision of the spec will move to the official notation Case a) - relates to whether the navigation is .efficient.. Case b) relates to whether there is a property on the end Class. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 30 April 2009 02:38 To: Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Bran I do agree with you that making all ends navigable would have a big impact. However as Ed recently pointed out to me in a discussion about issue 10536, by the conventions used in the UML abstract syntax metamodel, only navigable ends are actually referenced by name in OCL constraints. Although in the OCL spec it is possible (it is actually a compliance point) to refer to non-navigable ends, the UML spec does not do it. This simplifies the interpretation of the spec and the implementation of OCL. Hence the resolution to 10536, which is essentially a workaround for the fact that we want non-navigable ends and we also want to constrain them. -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 30 April 2009 02:05 To: Juergen Boldt Cc: uml2-rtf@omg.org Subject: Re: issue 13908 -- UML 2 RTF issue This issue needs more clarification. I cannot see how navigability, which is a run-time constraint, can have any impact on the definition of derivation formulas, in profiles or otherwise. Keep in mind that OCL ignores navigability and, as Conrad pointed out, association ends without names get default names (I believe that this is defined in the OCL spec). This means that one can freely write OCL constraints that involve unnamed non-navigable ends. If any other language is used for the constraint, the same conventions can be defined for that language. Making all association ends navigable in the metamodel would have immense consequences on existing implementations that conform to the standard (I am not sure what the submitter means when he says that all vendors implement bi-directional relationships--several vendors actually include the standard metamodel directly insider their tools). Remember that navigability in the UML spec is used to specify link end ownership. As currently stated, this issue should clearly be rejected. Cheers...Bran On Wed, Apr 29, 2009 at 1:31 PM, Juergen Boldt wrote: From: webmaster@omg.org Date: 29 Apr 2009 12:56:26 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML) Superstructure Section: General FormalNumber: formal/2007-11-02 Version: V2.1.2 RevisionDate: 2007-11-02 Page: All Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Error! Filename not specified. Subject: RE: issue 13908 -- UML 2 RTF issue Date: Fri, 1 May 2009 10:00:00 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 13908 -- UML 2 RTF issue Thread-Index: AcnJMPcZqNZ1NLIPThyb6MlB/jRbKAARRQ7QABL6+PAAHtOGwAAJAWwg From: "Ed Seidewitz" To: "Steve Cook" , "Pete Rivett - Adaptive" , "Bran Selic" Cc: Pete . I don.t take the sentence you quoted to be the opposite of what Steve said I said, but rather (almost) the converse. In fact, if the sentence did not include the phrase .in general., then the later part of the sentence implies .There is no need to refer to non-navigable association ends explicitly either in text or in formal constraints., which is pretty much equivalent to .Only navigable association ends are explicitly referenced by name.. The phrase .in general., of course, leaves open the possibility that sometimes a non-navigable association end is named and referenced. Personally, I don.t know of any case in the UML spec in which a non-navigable end is referenced by name in OCL. I know that only navigable association ends were named and used in the adopted UML 2.0 spec, but it is possible that some OCL somewhere has been added to the spec that references a non-navigable end. Note also that my original comment to Steve was not meant to imply whether the convention of not referencing non-navigable ends is a good one or not, just that this is what has been pretty much consistently done in the past. It has been noted that .navigation across non-navigable associations. (sic) is an optional compliance point for OCL. Of course, the alternative of using allIInstances() is also optional. In any case, the real point of issue 10536 was to make one end of a bidirectional association derived. This was because the desire was the association remain bidirectional, with both ends owned by the end types, but that it not be necessary to physically store the value of one end of the association if it could be derived. Whether or not this made sense, and, if so, whether it was the right solution, was the real point of discussion on this issue, not the OCL. In the end, so long as the OCL reasonably specifies what we want, it is OK (even if one could argue at this point it could have been expressed better). -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 01, 2009 5:17 AM To: Pete Rivett - Adaptive; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Pete If what you say is correct then the resolution to 10536 is absurd. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 30 April 2009 19:55 To: Steve Cook; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue In the normative definition of the UML metamodel (the XMI), all ends (and indeed all Associations) are explicitly named: this is in fact a requirement for any CMOF metamodel. The fact that they are not shown on diagrams is utterly irrelevant. I.m not aware of any convention that .only navigable ends are referenced by name in OCL constraints.: all I could find is that .Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints. which I read to mean the opposite . that specific ends are left unnamed (on diagrams) because they do not need to be referenced in constraints. If a name is needed in constraints then surely it can be shown on diagrams . note that this has no effect on the name (which is in the metamodel anyway), navigability or end ownership . Pete PS In any such discussion of .navigable. we should be careful to distinguish: a) Ends which have isNavigable=false b) Ends which use the convention peculiar to the UML spec which depicts end ownership using a navigability arrow (as opposed to the official .dot. notation): I.d hope that a subsequent revision of the spec will move to the official notation Case a) - relates to whether the navigation is .efficient.. Case b) relates to whether there is a property on the end Class. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 30 April 2009 02:38 To: Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Bran I do agree with you that making all ends navigable would have a big impact. However as Ed recently pointed out to me in a discussion about issue 10536, by the conventions used in the UML abstract syntax metamodel, only navigable ends are actually referenced by name in OCL constraints. Although in the OCL spec it is possible (it is actually a compliance point) to refer to non-navigable ends, the UML spec does not do it. This simplifies the interpretation of the spec and the implementation of OCL. Hence the resolution to 10536, which is essentially a workaround for the fact that we want non-navigable ends and we also want to constrain them. -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 30 April 2009 02:05 To: Juergen Boldt Cc: uml2-rtf@omg.org Subject: Re: issue 13908 -- UML 2 RTF issue This issue needs more clarification. I cannot see how navigability, which is a run-time constraint, can have any impact on the definition of derivation formulas, in profiles or otherwise. Keep in mind that OCL ignores navigability and, as Conrad pointed out, association ends without names get default names (I believe that this is defined in the OCL spec). This means that one can freely write OCL constraints that involve unnamed non-navigable ends. If any other language is used for the constraint, the same conventions can be defined for that language. Making all association ends navigable in the metamodel would have immense consequences on existing implementations that conform to the standard (I am not sure what the submitter means when he says that all vendors implement bi-directional relationships--several vendors actually include the standard metamodel directly insider their tools). Remember that navigability in the UML spec is used to specify link end ownership. As currently stated, this issue should clearly be rejected. Cheers...Bran On Wed, Apr 29, 2009 at 1:31 PM, Juergen Boldt wrote: From: webmaster@omg.org Date: 29 Apr 2009 12:56:26 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML) Superstructure Section: General FormalNumber: formal/2007-11-02 Version: V2.1.2 RevisionDate: 2007-11-02 Page: All Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Error! Filename not specified. From: Steve Cook To: Ed Seidewitz , Pete Rivett - Adaptive , Bran Selic CC: "uml2-rtf@omg.org" Date: Fri, 1 May 2009 15:22:32 +0100 Subject: RE: issue 13908 -- UML 2 RTF issue Thread-Topic: issue 13908 -- UML 2 RTF issue Thread-Index: AcnJMPcZqNZ1NLIPThyb6MlB/jRbKAARRQ7QABL6+PAAHtOGwAAJAWwgAAGMsTA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US >real point of issue 10536 was to make one end of a bidirectional association derived Which is *exactly* what .non-navigable. should actually mean. To implement .one end derived. as navigable plus some OCL that derives the value from the other end is a travesty IMHO. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 May 2009 15:00 To: Steve Cook; Pete Rivett - Adaptive; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Pete . I don.t take the sentence you quoted to be the opposite of what Steve said I said, but rather (almost) the converse. In fact, if the sentence did not include the phrase .in general., then the later part of the sentence implies .There is no need to refer to non-navigable association ends explicitly either in text or in formal constraints., which is pretty much equivalent to .Only navigable association ends are explicitly referenced by name.. The phrase .in general., of course, leaves open the possibility that sometimes a non-navigable association end is named and referenced. Personally, I don.t know of any case in the UML spec in which a non-navigable end is referenced by name in OCL. I know that only navigable association ends were named and used in the adopted UML 2.0 spec, but it is possible that some OCL somewhere has been added to the spec that references a non-navigable end. Note also that my original comment to Steve was not meant to imply whether the convention of not referencing non-navigable ends is a good one or not, just that this is what has been pretty much consistently done in the past. It has been noted that .navigation across non-navigable associations. (sic) is an optional compliance point for OCL. Of course, the alternative of using allIInstances() is also optional. In any case, the real point of issue 10536 was to make one end of a bidirectional association derived. This was because the desire was the association remain bidirectional, with both ends owned by the end types, but that it not be necessary to physically store the value of one end of the association if it could be derived. Whether or not this made sense, and, if so, whether it was the right solution, was the real point of discussion on this issue, not the OCL. In the end, so long as the OCL reasonably specifies what we want, it is OK (even if one could argue at this point it could have been expressed better). -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 01, 2009 5:17 AM To: Pete Rivett - Adaptive; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Pete If what you say is correct then the resolution to 10536 is absurd. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 30 April 2009 19:55 To: Steve Cook; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue In the normative definition of the UML metamodel (the XMI), all ends (and indeed all Associations) are explicitly named: this is in fact a requirement for any CMOF metamodel. The fact that they are not shown on diagrams is utterly irrelevant. I.m not aware of any convention that .only navigable ends are referenced by name in OCL constraints.: all I could find is that .Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints. which I read to mean the opposite . that specific ends are left unnamed (on diagrams) because they do not need to be referenced in constraints. If a name is needed in constraints then surely it can be shown on diagrams . note that this has no effect on the name (which is in the metamodel anyway), navigability or end ownership . Pete PS In any such discussion of .navigable. we should be careful to distinguish: a) Ends which have isNavigable=false b) Ends which use the convention peculiar to the UML spec which depicts end ownership using a navigability arrow (as opposed to the official .dot. notation): I.d hope that a subsequent revision of the spec will move to the official notation Case a) - relates to whether the navigation is .efficient.. Case b) relates to whether there is a property on the end Class. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 30 April 2009 02:38 To: Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Bran I do agree with you that making all ends navigable would have a big impact. However as Ed recently pointed out to me in a discussion about issue 10536, by the conventions used in the UML abstract syntax metamodel, only navigable ends are actually referenced by name in OCL constraints. Although in the OCL spec it is possible (it is actually a compliance point) to refer to non-navigable ends, the UML spec does not do it. This simplifies the interpretation of the spec and the implementation of OCL. Hence the resolution to 10536, which is essentially a workaround for the fact that we want non-navigable ends and we also want to constrain them. -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 30 April 2009 02:05 To: Juergen Boldt Cc: uml2-rtf@omg.org Subject: Re: issue 13908 -- UML 2 RTF issue This issue needs more clarification. I cannot see how navigability, which is a run-time constraint, can have any impact on the definition of derivation formulas, in profiles or otherwise. Keep in mind that OCL ignores navigability and, as Conrad pointed out, association ends without names get default names (I believe that this is defined in the OCL spec). This means that one can freely write OCL constraints that involve unnamed non-navigable ends. If any other language is used for the constraint, the same conventions can be defined for that language. Making all association ends navigable in the metamodel would have immense consequences on existing implementations that conform to the standard (I am not sure what the submitter means when he says that all vendors implement bi-directional relationships--several vendors actually include the standard metamodel directly insider their tools). Remember that navigability in the UML spec is used to specify link end ownership. As currently stated, this issue should clearly be rejected. Cheers...Bran On Wed, Apr 29, 2009 at 1:31 PM, Juergen Boldt wrote: From: webmaster@omg.org Date: 29 Apr 2009 12:56:26 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML) Superstructure Section: General FormalNumber: formal/2007-11-02 Version: V2.1.2 RevisionDate: 2007-11-02 Page: All Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Error! Filename not specified. Subject: RE: issue 13908 -- UML 2 RTF issue Date: Fri, 1 May 2009 10:44:43 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 13908 -- UML 2 RTF issue Thread-Index: AcnJMPcZqNZ1NLIPThyb6MlB/jRbKAARRQ7QABL6+PAAHtOGwAAJAWwgAAGMsTAAAM8EgA== From: "Ed Seidewitz" To: "Steve Cook" Cc: Well, whether it is a .travesty. or not obviously is a matter of opinion. Certainly the semantic effect is equivalent. If I remember correctly, my own preference for 10636 was to just leave the association as bidirectional and say that the concern in the issue about this was not really relevant for the abstract syntax. The only argument for the derived end that somewhat made sense to me was that, with a derived end, the value didn.t need to be stored in the XMI, but that an implementation that internally closely followed the abstract syntax model could structurally include the derived end, with a value derived per the OCL. In any case, the issue resolution passed, and I, personally, don.t think it is enough of a travesty to be worth reconsidering. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 01, 2009 10:23 AM To: Ed Seidewitz; Pete Rivett - Adaptive; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue >real point of issue 10536 was to make one end of a bidirectional association derived Which is *exactly* what .non-navigable. should actually mean. To implement .one end derived. as navigable plus some OCL that derives the value from the other end is a travesty IMHO. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 May 2009 15:00 To: Steve Cook; Pete Rivett - Adaptive; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Pete . I don.t take the sentence you quoted to be the opposite of what Steve said I said, but rather (almost) the converse. In fact, if the sentence did not include the phrase .in general., then the later part of the sentence implies .There is no need to refer to non-navigable association ends explicitly either in text or in formal constraints., which is pretty much equivalent to .Only navigable association ends are explicitly referenced by name.. The phrase .in general., of course, leaves open the possibility that sometimes a non-navigable association end is named and referenced. Personally, I don.t know of any case in the UML spec in which a non-navigable end is referenced by name in OCL. I know that only navigable association ends were named and used in the adopted UML 2.0 spec, but it is possible that some OCL somewhere has been added to the spec that references a non-navigable end. Note also that my original comment to Steve was not meant to imply whether the convention of not referencing non-navigable ends is a good one or not, just that this is what has been pretty much consistently done in the past. It has been noted that .navigation across non-navigable associations. (sic) is an optional compliance point for OCL. Of course, the alternative of using allIInstances() is also optional. In any case, the real point of issue 10536 was to make one end of a bidirectional association derived. This was because the desire was the association remain bidirectional, with both ends owned by the end types, but that it not be necessary to physically store the value of one end of the association if it could be derived. Whether or not this made sense, and, if so, whether it was the right solution, was the real point of discussion on this issue, not the OCL. In the end, so long as the OCL reasonably specifies what we want, it is OK (even if one could argue at this point it could have been expressed better). -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 01, 2009 5:17 AM To: Pete Rivett - Adaptive; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Pete If what you say is correct then the resolution to 10536 is absurd. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 30 April 2009 19:55 To: Steve Cook; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue In the normative definition of the UML metamodel (the XMI), all ends (and indeed all Associations) are explicitly named: this is in fact a requirement for any CMOF metamodel. The fact that they are not shown on diagrams is utterly irrelevant. I.m not aware of any convention that .only navigable ends are referenced by name in OCL constraints.: all I could find is that .Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints. which I read to mean the opposite . that specific ends are left unnamed (on diagrams) because they do not need to be referenced in constraints. If a name is needed in constraints then surely it can be shown on diagrams . note that this has no effect on the name (which is in the metamodel anyway), navigability or end ownership . Pete PS In any such discussion of .navigable. we should be careful to distinguish: a) Ends which have isNavigable=false b) Ends which use the convention peculiar to the UML spec which depicts end ownership using a navigability arrow (as opposed to the official .dot. notation): I.d hope that a subsequent revision of the spec will move to the official notation Case a) - relates to whether the navigation is .efficient.. Case b) relates to whether there is a property on the end Class. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 30 April 2009 02:38 To: Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Bran I do agree with you that making all ends navigable would have a big impact. However as Ed recently pointed out to me in a discussion about issue 10536, by the conventions used in the UML abstract syntax metamodel, only navigable ends are actually referenced by name in OCL constraints. Although in the OCL spec it is possible (it is actually a compliance point) to refer to non-navigable ends, the UML spec does not do it. This simplifies the interpretation of the spec and the implementation of OCL. Hence the resolution to 10536, which is essentially a workaround for the fact that we want non-navigable ends and we also want to constrain them. -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 30 April 2009 02:05 To: Juergen Boldt Cc: uml2-rtf@omg.org Subject: Re: issue 13908 -- UML 2 RTF issue This issue needs more clarification. I cannot see how navigability, which is a run-time constraint, can have any impact on the definition of derivation formulas, in profiles or otherwise. Keep in mind that OCL ignores navigability and, as Conrad pointed out, association ends without names get default names (I believe that this is defined in the OCL spec). This means that one can freely write OCL constraints that involve unnamed non-navigable ends. If any other language is used for the constraint, the same conventions can be defined for that language. Making all association ends navigable in the metamodel would have immense consequences on existing implementations that conform to the standard (I am not sure what the submitter means when he says that all vendors implement bi-directional relationships--several vendors actually include the standard metamodel directly insider their tools). Remember that navigability in the UML spec is used to specify link end ownership. As currently stated, this issue should clearly be rejected. Cheers...Bran On Wed, Apr 29, 2009 at 1:31 PM, Juergen Boldt wrote: From: webmaster@omg.org Date: 29 Apr 2009 12:56:26 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML) Superstructure Section: General FormalNumber: formal/2007-11-02 Version: V2.1.2 RevisionDate: 2007-11-02 Page: All Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Error! Filename not specified. From: Steve Cook To: Ed Seidewitz CC: "uml2-rtf@omg.org" Date: Fri, 1 May 2009 16:34:17 +0100 Subject: RE: issue 13908 -- UML 2 RTF issue Thread-Topic: issue 13908 -- UML 2 RTF issue Thread-Index: AcnJMPcZqNZ1NLIPThyb6MlB/jRbKAARRQ7QABL6+PAAHtOGwAAJAWwgAAGMsTAAAM8EgAABvLgg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US >I, personally, don.t think it is enough of a travesty to be worth reconsidering Me neither. It is one of many travesties. It is good strong grist for the strategic mill, though. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 May 2009 15:45 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Well, whether it is a .travesty. or not obviously is a matter of opinion. Certainly the semantic effect is equivalent. If I remember correctly, my own preference for 10636 was to just leave the association as bidirectional and say that the concern in the issue about this was not really relevant for the abstract syntax. The only argument for the derived end that somewhat made sense to me was that, with a derived end, the value didn.t need to be stored in the XMI, but that an implementation that internally closely followed the abstract syntax model could structurally include the derived end, with a value derived per the OCL. In any case, the issue resolution passed, and I, personally, don.t think it is enough of a travesty to be worth reconsidering. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 01, 2009 10:23 AM To: Ed Seidewitz; Pete Rivett - Adaptive; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue >real point of issue 10536 was to make one end of a bidirectional association derived Which is *exactly* what .non-navigable. should actually mean. To implement .one end derived. as navigable plus some OCL that derives the value from the other end is a travesty IMHO. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 May 2009 15:00 To: Steve Cook; Pete Rivett - Adaptive; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Pete . I don.t take the sentence you quoted to be the opposite of what Steve said I said, but rather (almost) the converse. In fact, if the sentence did not include the phrase .in general., then the later part of the sentence implies .There is no need to refer to non-navigable association ends explicitly either in text or in formal constraints., which is pretty much equivalent to .Only navigable association ends are explicitly referenced by name.. The phrase .in general., of course, leaves open the possibility that sometimes a non-navigable association end is named and referenced. Personally, I don.t know of any case in the UML spec in which a non-navigable end is referenced by name in OCL. I know that only navigable association ends were named and used in the adopted UML 2.0 spec, but it is possible that some OCL somewhere has been added to the spec that references a non-navigable end. Note also that my original comment to Steve was not meant to imply whether the convention of not referencing non-navigable ends is a good one or not, just that this is what has been pretty much consistently done in the past. It has been noted that .navigation across non-navigable associations. (sic) is an optional compliance point for OCL. Of course, the alternative of using allIInstances() is also optional. In any case, the real point of issue 10536 was to make one end of a bidirectional association derived. This was because the desire was the association remain bidirectional, with both ends owned by the end types, but that it not be necessary to physically store the value of one end of the association if it could be derived. Whether or not this made sense, and, if so, whether it was the right solution, was the real point of discussion on this issue, not the OCL. In the end, so long as the OCL reasonably specifies what we want, it is OK (even if one could argue at this point it could have been expressed better). -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, May 01, 2009 5:17 AM To: Pete Rivett - Adaptive; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Pete If what you say is correct then the resolution to 10536 is absurd. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 30 April 2009 19:55 To: Steve Cook; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue In the normative definition of the UML metamodel (the XMI), all ends (and indeed all Associations) are explicitly named: this is in fact a requirement for any CMOF metamodel. The fact that they are not shown on diagrams is utterly irrelevant. I.m not aware of any convention that .only navigable ends are referenced by name in OCL constraints.: all I could find is that .Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints. which I read to mean the opposite . that specific ends are left unnamed (on diagrams) because they do not need to be referenced in constraints. If a name is needed in constraints then surely it can be shown on diagrams . note that this has no effect on the name (which is in the metamodel anyway), navigability or end ownership . Pete PS In any such discussion of .navigable. we should be careful to distinguish: a) Ends which have isNavigable=false b) Ends which use the convention peculiar to the UML spec which depicts end ownership using a navigability arrow (as opposed to the official .dot. notation): I.d hope that a subsequent revision of the spec will move to the official notation Case a) - relates to whether the navigation is .efficient.. Case b) relates to whether there is a property on the end Class. From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 30 April 2009 02:38 To: Bran Selic Cc: uml2-rtf@omg.org Subject: RE: issue 13908 -- UML 2 RTF issue Bran I do agree with you that making all ends navigable would have a big impact. However as Ed recently pointed out to me in a discussion about issue 10536, by the conventions used in the UML abstract syntax metamodel, only navigable ends are actually referenced by name in OCL constraints. Although in the OCL spec it is possible (it is actually a compliance point) to refer to non-navigable ends, the UML spec does not do it. This simplifies the interpretation of the spec and the implementation of OCL. Hence the resolution to 10536, which is essentially a workaround for the fact that we want non-navigable ends and we also want to constrain them. -- Steve From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 30 April 2009 02:05 To: Juergen Boldt Cc: uml2-rtf@omg.org Subject: Re: issue 13908 -- UML 2 RTF issue This issue needs more clarification. I cannot see how navigability, which is a run-time constraint, can have any impact on the definition of derivation formulas, in profiles or otherwise. Keep in mind that OCL ignores navigability and, as Conrad pointed out, association ends without names get default names (I believe that this is defined in the OCL spec). This means that one can freely write OCL constraints that involve unnamed non-navigable ends. If any other language is used for the constraint, the same conventions can be defined for that language. Making all association ends navigable in the metamodel would have immense consequences on existing implementations that conform to the standard (I am not sure what the submitter means when he says that all vendors implement bi-directional relationships--several vendors actually include the standard metamodel directly insider their tools). Remember that navigability in the UML spec is used to specify link end ownership. As currently stated, this issue should clearly be rejected. Cheers...Bran On Wed, Apr 29, 2009 at 1:31 PM, Juergen Boldt wrote: From: webmaster@omg.org Date: 29 Apr 2009 12:56:26 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Phillip Astle Company: Artisan Software Tools mailFrom: phillip.astle@artisansoftwaretools.com Notification: No Specification: OMG Unified Modeling Language (OMG UML) Superstructure Section: General FormalNumber: formal/2007-11-02 Version: V2.1.2 RevisionDate: 2007-11-02 Page: All Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MS-RTC LM 8) Description In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Error! Filename not specified.