Issue 16412: property.opposite (uml2-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: It seems there is an issue with derived Property.opposite. Spec says: / opposite : Property [0..1] In the case where the property is one navigable end of a binary association with both ends navigable, this gives the other end. By description, it should keep reference to opposite navigable end, but OCL works only when navigable end is owned by class. It does not work when navigable end is owned by association: Constraint #1: [1] If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end. opposite = if owningAssociation->isEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)->any() in if otherEnd.owningAssociation->isEmpty() then otherEnd else Set{} endif else Set {} endif Any comments? Which one is correct? Property description or constraint text? Resolution: Revised Text: Actions taken: August 1, 2011: received issue Discussion: End of Annotations:===== m: Nerijus Jankevicius Subject: property.opposite Date: Mon, 1 Aug 2011 16:05:59 +0300 Cc: issues@omg.org To: uml2-rtf@omg.org, uml-spec-simplification@omg.org X-Mailer: Apple Mail (2.1084) It seems there is an issue with derived Property.opposite. Spec says: / opposite : Property [0..1] In the case where the property is one navigable end of a binary association with both ends navigable, this gives the other end. By description, it should keep reference to opposite navigable end, but OCL works only when navigable end is owned by class. It does not work when navigable end is owned by association: Constraint #1: [1] If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end. opposite = if owningAssociation->isEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)->any() in if otherEnd.owningAssociation->isEmpty() then otherEnd else Set{} endif else Set {} endif Any comments? Which one is correct? Property description or constraint text? Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! From: Ed Seidewitz To: Nerijus Jankevicius CC: "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" Date: Mon, 1 Aug 2011 10:35:11 -0400 Subject: RE: property.opposite Thread-Topic: property.opposite Thread-Index: AcxQS//z8EF8ikuBTgO3XKSF/CW4pQACeQaw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-21314-c X-SpamInfo: helo-dns, Nerijus . I believe this discrepancy is left over from the days when end ownership determined navigability. In the original UML 2.0, the description of opposite actually matched the OCL. When navigability was separated from end ownership, the constraint OCL and description remained valid, but the attribute description was not updated. As to which definition for opposite is really .correct., I found two actually uses of opposite in the UML 2.4 spec, in constraint [2] of StructuralFeatureAction and constraint [1] of Actor. Both these uses seem to assume that opposite is based on navigability, not ownership (indeed, the StructurealFeatureAction constraint the property whose opposite is being obtained is specifically required not to be class owned). So, I think the description of the attribute is correct, and the constraint and OCL is what is actually wrong. Given that this is an inconsistency, I believe we can fix it in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Monday, August 01, 2011 9:06 AM To: uml2-rtf@omg.org; uml-spec-simplification@omg.org Cc: issues@omg.org Subject: property.opposite It seems there is an issue with derived Property.opposite. Spec says: / opposite : Property [0..1] In the case where the property is one navigable end of a binary association with both ends navigable, this gives the other end. By description, it should keep reference to opposite navigable end, but OCL works only when navigable end is owned by class. It does not work when navigable end is owned by association: Constraint #1: [1] If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end. opposite = if owningAssociation->isEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)->any() in if otherEnd.owningAssociation->isEmpty() then otherEnd else Set{} endif else Set {} endif Any comments? Which one is correct? Property description or constraint text? Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! Subject: RE: RE: property.opposite Date: Mon, 1 Aug 2011 09:33:26 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: property.opposite Thread-Index: AcxQaLxlXesIAzJyTWKqmfaWSJp2sw== From: "Pete Rivett" To: "Ed Seidewitz" , "Nerijus Jankevicius" Cc: , I disagree that navigability should have anything to do with the definition or use of .opposite. . the .new. (actually not so new . it dates back to the UML 2.0 FTF) definition of navigability is a mere hint of expectation of efficiency. I also think the OCL is incorrect . for a binary association the 2 ends should be the opposite of each other regardless of their ownership. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, August 01, 2011 7:35 AM To: Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Nerijus . I believe this discrepancy is left over from the days when end ownership determined navigability. In the original UML 2.0, the description of opposite actually matched the OCL. When navigability was separated from end ownership, the constraint OCL and description remained valid, but the attribute description was not updated. As to which definition for opposite is really .correct., I found two actually uses of opposite in the UML 2.4 spec, in constraint [2] of StructuralFeatureAction and constraint [1] of Actor. Both these uses seem to assume that opposite is based on navigability, not ownership (indeed, the StructurealFeatureAction constraint the property whose opposite is being obtained is specifically required not to be class owned). So, I think the description of the attribute is correct, and the constraint and OCL is what is actually wrong. Given that this is an inconsistency, I believe we can fix it in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Monday, August 01, 2011 9:06 AM To: uml2-rtf@omg.org; uml-spec-simplification@omg.org Cc: issues@omg.org Subject: property.opposite It seems there is an issue with derived Property.opposite. Spec says: / opposite : Property [0..1] In the case where the property is one navigable end of a binary association with both ends navigable, this gives the other end. By description, it should keep reference to opposite navigable end, but OCL works only when navigable end is owned by class. It does not work when navigable end is owned by association: Constraint #1: [1] If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end. opposite = if owningAssociation->isEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)->any() in if otherEnd.owningAssociation->isEmpty() then otherEnd else Set{} endif else Set {} endif Any comments? Which one is correct? Property description or constraint text? Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! From: Steve Cook To: Pete Rivett , Ed Seidewitz , Nerijus Jankevicius CC: "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" Subject: RE: RE: property.opposite Thread-Topic: RE: property.opposite Thread-Index: AcxQaLxlXesIAzJyTWKqmfaWSJp2swAAkktg Date: Mon, 1 Aug 2011 16:51:43 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.100] >for a binary association the 2 ends should be the opposite of each other regardless of their ownership I agree. From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 01 August 2011 17:33 To: Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: RE: property.opposite I disagree that navigability should have anything to do with the definition or use of .opposite. . the .new. (actually not so new . it dates back to the UML 2.0 FTF) definition of navigability is a mere hint of expectation of efficiency. I also think the OCL is incorrect . for a binary association the 2 ends should be the opposite of each other regardless of their ownership. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, August 01, 2011 7:35 AM To: Nerijus Jankevicius Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Nerijus . I believe this discrepancy is left over from the days when end ownership determined navigability. In the original UML 2.0, the description of opposite actually matched the OCL. When navigability was separated from end ownership, the constraint OCL and description remained valid, but the attribute description was not updated. As to which definition for opposite is really .correct., I found two actually uses of opposite in the UML 2.4 spec, in constraint [2] of StructuralFeatureAction and constraint [1] of Actor. Both these uses seem to assume that opposite is based on navigability, not ownership (indeed, the StructurealFeatureAction constraint the property whose opposite is being obtained is specifically required not to be class owned). So, I think the description of the attribute is correct, and the constraint and OCL is what is actually wrong. Given that this is an inconsistency, I believe we can fix it in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Monday, August 01, 2011 9:06 AM To: uml2-rtf@omg.org; uml-spec-simplification@omg.org Cc: issues@omg.org Subject: property.opposite It seems there is an issue with derived Property.opposite. Spec says: / opposite : Property [0..1] In the case where the property is one navigable end of a binary association with both ends navigable, this gives the other end. By description, it should keep reference to opposite navigable end, but OCL works only when navigable end is owned by class. It does not work when navigable end is owned by association: Constraint #1: [1] If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end. opposite = if owningAssociation->isEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)->any() in if otherEnd.owningAssociation->isEmpty() then otherEnd else Set{} endif else Set {} endif Any comments? Which one is correct? Property description or constraint text? Thanks, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - UML made simple! USER-AGENT: Thunderbird 2.0.0.21 (X11/20090302) Date: Mon, 1 Aug 2011 09:55:38 -0700 (PDT) From: Dave Hawkins To: Pete Rivett Cc: Ed Seidewitz , Nerijus Jankevicius , uml2-rtf@omg.org, uml-spec-simplification@omg.org Subject: Re: property.opposite X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E36DAAA.00C6:SCFMA922111,ss=1,re=-4.000,fgs=0 I agree with Pete that the opposite of a binary end should always be the other end. Dave On 01/08/11 17:33, Pete Rivett wrote: > I disagree that navigability should have anything to do with the > definition or use of .opposite. ­ the .new. (actually not so new ­ it > dates back to the UML 2.0 FTF) definition of navigability is a mere hint > of expectation of efficiency. > > > > I also think the OCL is incorrect ­ for a binary association the 2 ends > should be the opposite of each other regardless of their ownership. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com] > *Sent:* Monday, August 01, 2011 7:35 AM > *To:* Nerijus Jankevicius > *Cc:* uml2-rtf@omg.org; uml-spec-simplification@omg.org > *Subject:* RE: property.opposite > > > > Nerijus ­ > > > > I believe this discrepancy is left over from the days when end ownership > determined navigability. In the original UML 2.0, the description of > opposite actually matched the OCL. When navigability was separated from > end ownership, the constraint OCL and description remained valid, but > the attribute description was not updated. > > > > As to which definition for opposite is really .correct., I found two > actually uses of opposite in the UML 2.4 spec, in constraint [2] of > StructuralFeatureAction and constraint [1] of Actor. Both these uses > seem to assume that opposite is based on navigability, not ownership > (indeed, the StructurealFeatureAction constraint the property whose > opposite is being obtained is specifically required /not/ to be class > owned). > > > > So, I think the description of the attribute is correct, and the > constraint and OCL is what is actually wrong. Given that this is an > inconsistency, I believe we can fix it in UML 2.5. > > > > -- Ed > > > > ------------------------------------------------------------------------ > > *From:* Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > *Sent:* Monday, August 01, 2011 9:06 AM > *To:* uml2-rtf@omg.org ; > uml-spec-simplification@omg.org > *Cc:* issues@omg.org > *Subject:* property.opposite > > > > It seems there is an issue with derived Property.opposite. > > > > Spec says: > > > > / opposite : Property [0..1] In the case where the property is one > *navigable end of a binary association with both ends navigable*, this > gives the other end. > > > > By description, it should keep reference to opposite navigable end, but > OCL works only when navigable end is owned by class. > > It does not work when navigable end is owned by association: > > > > Constraint #1: > > [1] If this *property is owned by a class* associated with a binary > association, and the *other end of the association is also owned by a > class*, then opposite gives the other end. > > opposite = *if *owningAssociation->isEmpty() *and > *association.memberEnd->size() = 2 *then let *otherEnd = > (association.memberEnd - self)->any() *in if > *otherEnd.owningAssociation->isEmpty() *then *otherEnd *else *Set{} > *endif else *Set {} *endif * > > > > > > Any comments? > > Which one is correct? Property description or constraint text? > > > > Thanks, > > > > > > * --* > > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Europe > Savanoriu pr. 363, LT 49425 Kaunas, Lithuania > P.O. box 2166, LT- 3000, Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > -- > MagicDraw - UML made simple! > > > -- 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. Or OrFrom: Ed Seidewitz To: "uml-spec-simplification@omg.org" CC: "uml2-rtf@omg.org" Date: Mon, 1 Aug 2011 13:57:45 -0400 Subject: RE: property.opposite Thread-Topic: property.opposite Thread-Index: AcxQa+7gbo20a+7TQKWfzat4Gor8RQAByAfQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-10447-c X-SpamInfo: helo-dns, X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p71HuPvn025472 Well, for the purposes of UML 2.5, we have to be careful again here about "should" statements. That is why I looked at the actual uses of "opposite" within the metamodel. The question, then, is whether navigability meant to be enforced in either of these cases. And, on a second look, I would agree that enforcement of navigability is not intended in either case, the only requirement being that the association in question is a binary association. Since neither of these cases require class ownership of the ends (and, in fact, the constraint for StructuralFeatureAction specifically allows at least one of the ends to be association owned), I would agree that we need to change _both_ the definition of the opposite property _and_ the definition of the constraint. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, August 01, 2011 12:56 PM To: Pete Rivett Cc: Ed Seidewitz; Nerijus Jankevicius; uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: Re: property.opposite I agree with Pete that the opposite of a binary end should always be the other end. Dave On 01/08/11 17:33, Pete Rivett wrote: > I disagree that navigability should have anything to do with the > definition or use of 'opposite' - the 'new' (actually not so new - it > dates back to the UML 2.0 FTF) definition of navigability is a mere hint > of expectation of efficiency. > > > > I also think the OCL is incorrect - for a binary association the 2 ends > should be the opposite of each other regardless of their ownership. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com] > *Sent:* Monday, August 01, 2011 7:35 AM > *To:* Nerijus Jankevicius > *Cc:* uml2-rtf@omg.org; uml-spec-simplification@omg.org > *Subject:* RE: property.opposite > > > > Nerijus - > > > > I believe this discrepancy is left over from the days when end ownership > determined navigability. In the original UML 2.0, the description of > opposite actually matched the OCL. When navigability was separated from > end ownership, the constraint OCL and description remained valid, but > the attribute description was not updated. > > > > As to which definition for opposite is really "correct", I found two > actually uses of opposite in the UML 2.4 spec, in constraint [2] of > StructuralFeatureAction and constraint [1] of Actor. Both these uses > seem to assume that opposite is based on navigability, not ownership > (indeed, the StructurealFeatureAction constraint the property whose > opposite is being obtained is specifically required /not/ to be class > owned). > > > > So, I think the description of the attribute is correct, and the > constraint and OCL is what is actually wrong. Given that this is an > inconsistency, I believe we can fix it in UML 2.5. > > > > -- Ed > > > > ------------------------------------------------------------------------ > > *From:* Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > *Sent:* Monday, August 01, 2011 9:06 AM > *To:* uml2-rtf@omg.org ; > uml-spec-simplification@omg.org > *Cc:* issues@omg.org > *Subject:* property.opposite > > > > It seems there is an issue with derived Property.opposite. > > > > Spec says: > > > > / opposite : Property [0..1] In the case where the property is one > *navigable end of a binary association with both ends navigable*, this > gives the other end. > > > > By description, it should keep reference to opposite navigable end, but > OCL works only when navigable end is owned by class. > > It does not work when navigable end is owned by association: > > > > Constraint #1: > > [1] If this *property is owned by a class* associated with a binary > association, and the *other end of the association is also owned by a > class*, then opposite gives the other end. > > opposite = *if *owningAssociation->isEmpty() *and > *association.memberEnd->size() = 2 *then let *otherEnd = > (association.memberEnd - self)->any() *in if > *otherEnd.owningAssociation->isEmpty() *then *otherEnd *else *Set{} > *endif else *Set {} *endif * > > > > > > Any comments? > > Which one is correct? Property description or constraint text? > > > > Thanks, > > > > > > * --* > > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Europe > Savanoriu pr. 363, LT 49425 Kaunas, Lithuania > P.O. box 2166, LT- 3000, Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > -- > MagicDraw - UML made simple! > > > -- 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. :wq :wq :wq From: Steve Cook To: Ed Seidewitz , "uml-spec-simplification@omg.org" CC: "uml2-rtf@omg.org" Subject: RE: property.opposite Thread-Topic: property.opposite Thread-Index: AQHMUGyhuX2BNIgzskWkFP51nALy9ZUIN2uAgAYk7VA= Date: Fri, 5 Aug 2011 14:53:35 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.100] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p75Eqau5011299 I'm changing this in 2.5. The new derivation for opposite is this: result = if (not association->isEmpty()) and association.memberEnd->size() = 2 then association.memberEnd->any(e | e <> self) else null endif -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 August 2011 18:58 To: uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite Well, for the purposes of UML 2.5, we have to be careful again here about "should" statements. That is why I looked at the actual uses of "opposite" within the metamodel. The question, then, is whether navigability meant to be enforced in either of these cases. And, on a second look, I would agree that enforcement of navigability is not intended in either case, the only requirement being that the association in question is a binary association. Since neither of these cases require class ownership of the ends (and, in fact, the constraint for StructuralFeatureAction specifically allows at least one of the ends to be association owned), I would agree that we need to change _both_ the definition of the opposite property _and_ the definition of the constraint. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, August 01, 2011 12:56 PM To: Pete Rivett Cc: Ed Seidewitz; Nerijus Jankevicius; uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: Re: property.opposite I agree with Pete that the opposite of a binary end should always be the other end. Dave On 01/08/11 17:33, Pete Rivett wrote: > I disagree that navigability should have anything to do with the > definition or use of 'opposite' - the 'new' (actually not so new - it > dates back to the UML 2.0 FTF) definition of navigability is a mere > hint of expectation of efficiency. > > > > I also think the OCL is incorrect - for a binary association the 2 > ends should be the opposite of each other regardless of their ownership. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com] > *Sent:* Monday, August 01, 2011 7:35 AM > *To:* Nerijus Jankevicius > *Cc:* uml2-rtf@omg.org; uml-spec-simplification@omg.org > *Subject:* RE: property.opposite > > > > Nerijus - > > > > I believe this discrepancy is left over from the days when end > ownership determined navigability. In the original UML 2.0, the > description of opposite actually matched the OCL. When navigability > was separated from end ownership, the constraint OCL and description > remained valid, but the attribute description was not updated. > > > > As to which definition for opposite is really "correct", I found two > actually uses of opposite in the UML 2.4 spec, in constraint [2] of > StructuralFeatureAction and constraint [1] of Actor. Both these uses > seem to assume that opposite is based on navigability, not ownership > (indeed, the StructurealFeatureAction constraint the property whose > opposite is being obtained is specifically required /not/ to be class > owned). > > > > So, I think the description of the attribute is correct, and the > constraint and OCL is what is actually wrong. Given that this is an > inconsistency, I believe we can fix it in UML 2.5. > > > > -- Ed > > > > ---------------------------------------------------------------------- > -- > > *From:* Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > *Sent:* Monday, August 01, 2011 9:06 AM > *To:* uml2-rtf@omg.org ; > uml-spec-simplification@omg.org > > *Cc:* issues@omg.org > *Subject:* property.opposite > > > > It seems there is an issue with derived Property.opposite. > > > > Spec says: > > > > / opposite : Property [0..1] In the case where the property is one > *navigable end of a binary association with both ends navigable*, this > gives the other end. > > > > By description, it should keep reference to opposite navigable end, > but OCL works only when navigable end is owned by class. > > It does not work when navigable end is owned by association: > > > > Constraint #1: > > [1] If this *property is owned by a class* associated with a binary > association, and the *other end of the association is also owned by a > class*, then opposite gives the other end. > > opposite = *if *owningAssociation->isEmpty() *and > *association.memberEnd->size() = 2 *then let *otherEnd = > (association.memberEnd - self)->any() *in if > *otherEnd.owningAssociation->isEmpty() *then *otherEnd *else *Set{} > *endif else *Set {} *endif * > > > > > > Any comments? > > Which one is correct? Property description or constraint text? > > > > Thanks, > > > > > > * --* > > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Europe > Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, > Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > -- > MagicDraw - UML made simple! > > > -- 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. Os OsFrom: Ed Seidewitz To: Steve Cook CC: "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" Date: Fri, 5 Aug 2011 11:09:55 -0400 Subject: RE: property.opposite Thread-Topic: property.opposite Thread-Index: AQHMUGyhuX2BNIgzskWkFP51nALy9ZUIN2uAgAYk7VCAAAWfEA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|-0.988675|0.876559|0|white|ugly|4917|28|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0.876559 p=-0.988675 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-13081-c X-SpamInfo: helo-dns, X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p75F8MeM012961 Steve -- This looks about right. I few points of detail on the OCL (Nicolas can confirm if I have these points right!): - I don't think you can use "null" in OCL. It should be "Set{}". - Instead of "not association->isEmpty()", you can more simply write "association->notEmpty()". - I don't think it is required, but I think it is clearer to write "self.assocation" instead of just "association". -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 10:54 AM To: Ed Seidewitz; uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite I'm changing this in 2.5. The new derivation for opposite is this: result = if (not association->isEmpty()) and association.memberEnd->size() = 2 then association.memberEnd->any(e | e <> self) else null endif -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 August 2011 18:58 To: uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite Well, for the purposes of UML 2.5, we have to be careful again here about "should" statements. That is why I looked at the actual uses of "opposite" within the metamodel. The question, then, is whether navigability meant to be enforced in either of these cases. And, on a second look, I would agree that enforcement of navigability is not intended in either case, the only requirement being that the association in question is a binary association. Since neither of these cases require class ownership of the ends (and, in fact, the constraint for StructuralFeatureAction specifically allows at least one of the ends to be association owned), I would agree that we need to change _both_ the definition of the opposite property _and_ the definition of the constraint. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, August 01, 2011 12:56 PM To: Pete Rivett Cc: Ed Seidewitz; Nerijus Jankevicius; uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: Re: property.opposite I agree with Pete that the opposite of a binary end should always be the other end. Dave On 01/08/11 17:33, Pete Rivett wrote: > I disagree that navigability should have anything to do with the > definition or use of 'opposite' - the 'new' (actually not so new - it > dates back to the UML 2.0 FTF) definition of navigability is a mere > hint of expectation of efficiency. > > > > I also think the OCL is incorrect - for a binary association the 2 > ends should be the opposite of each other regardless of their ownership. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com] > *Sent:* Monday, August 01, 2011 7:35 AM > *To:* Nerijus Jankevicius > *Cc:* uml2-rtf@omg.org; uml-spec-simplification@omg.org > *Subject:* RE: property.opposite > > > > Nerijus - > > > > I believe this discrepancy is left over from the days when end > ownership determined navigability. In the original UML 2.0, the > description of opposite actually matched the OCL. When navigability > was separated from end ownership, the constraint OCL and description > remained valid, but the attribute description was not updated. > > > > As to which definition for opposite is really "correct", I found two > actually uses of opposite in the UML 2.4 spec, in constraint [2] of > StructuralFeatureAction and constraint [1] of Actor. Both these uses > seem to assume that opposite is based on navigability, not ownership > (indeed, the StructurealFeatureAction constraint the property whose > opposite is being obtained is specifically required /not/ to be class > owned). > > > > So, I think the description of the attribute is correct, and the > constraint and OCL is what is actually wrong. Given that this is an > inconsistency, I believe we can fix it in UML 2.5. > > > > -- Ed > > > > ---------------------------------------------------------------------- > -- > > *From:* Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > *Sent:* Monday, August 01, 2011 9:06 AM > *To:* uml2-rtf@omg.org ; > uml-spec-simplification@omg.org > > *Cc:* issues@omg.org > *Subject:* property.opposite > > > > It seems there is an issue with derived Property.opposite. > > > > Spec says: > > > > / opposite : Property [0..1] In the case where the property is one > *navigable end of a binary association with both ends navigable*, this > gives the other end. > > > > By description, it should keep reference to opposite navigable end, > but OCL works only when navigable end is owned by class. > > It does not work when navigable end is owned by association: > > > > Constraint #1: > > [1] If this *property is owned by a class* associated with a binary > association, and the *other end of the association is also owned by a > class*, then opposite gives the other end. > > opposite = *if *owningAssociation->isEmpty() *and > *association.memberEnd->size() = 2 *then let *otherEnd = > (association.memberEnd - self)->any() *in if > *otherEnd.owningAssociation->isEmpty() *then *otherEnd *else *Set{} > *endif else *Set {} *endif * > > > > > > Any comments? > > Which one is correct? Property description or constraint text? > > > > Thanks, > > > > > > * --* > > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Europe > Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, > Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > -- > MagicDraw - UML made simple! > > > -- 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: Ed Seidewitz CC: "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" Subject: RE: property.opposite Thread-Topic: property.opposite Thread-Index: AQHMUGyhuX2BNIgzskWkFP51nALy9ZUIN2uAgAYk7VCAAAWfEIAAAMFQ Date: Fri, 5 Aug 2011 15:11:28 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.100] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p75FA71I013131 Null is required to make the constraint typecheck in RSA. If you use Set{} it complains that there is no common supertype of Set(OclVoid) and Property. I'll change the other things. -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 05 August 2011 16:10 To: Steve Cook Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Steve -- This looks about right. I few points of detail on the OCL (Nicolas can confirm if I have these points right!): - I don't think you can use "null" in OCL. It should be "Set{}". - Instead of "not association->isEmpty()", you can more simply write "association->notEmpty()". - I don't think it is required, but I think it is clearer to write "self.assocation" instead of just "association". -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 10:54 AM To: Ed Seidewitz; uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite I'm changing this in 2.5. The new derivation for opposite is this: result = if (not association->isEmpty()) and association.memberEnd->size() = 2 then association.memberEnd->any(e | e <> self) else null endif -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 August 2011 18:58 To: uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite Well, for the purposes of UML 2.5, we have to be careful again here about "should" statements. That is why I looked at the actual uses of "opposite" within the metamodel. The question, then, is whether navigability meant to be enforced in either of these cases. And, on a second look, I would agree that enforcement of navigability is not intended in either case, the only requirement being that the association in question is a binary association. Since neither of these cases require class ownership of the ends (and, in fact, the constraint for StructuralFeatureAction specifically allows at least one of the ends to be association owned), I would agree that we need to change _both_ the definition of the opposite property _and_ the definition of the constraint. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, August 01, 2011 12:56 PM To: Pete Rivett Cc: Ed Seidewitz; Nerijus Jankevicius; uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: Re: property.opposite I agree with Pete that the opposite of a binary end should always be the other end. Dave On 01/08/11 17:33, Pete Rivett wrote: > I disagree that navigability should have anything to do with the > definition or use of 'opposite' - the 'new' (actually not so new - it > dates back to the UML 2.0 FTF) definition of navigability is a mere > hint of expectation of efficiency. > > > > I also think the OCL is incorrect - for a binary association the 2 > ends should be the opposite of each other regardless of their ownership. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com] > *Sent:* Monday, August 01, 2011 7:35 AM > *To:* Nerijus Jankevicius > *Cc:* uml2-rtf@omg.org; uml-spec-simplification@omg.org > *Subject:* RE: property.opposite > > > > Nerijus - > > > > I believe this discrepancy is left over from the days when end > ownership determined navigability. In the original UML 2.0, the > description of opposite actually matched the OCL. When navigability > was separated from end ownership, the constraint OCL and description > remained valid, but the attribute description was not updated. > > > > As to which definition for opposite is really "correct", I found two > actually uses of opposite in the UML 2.4 spec, in constraint [2] of > StructuralFeatureAction and constraint [1] of Actor. Both these uses > seem to assume that opposite is based on navigability, not ownership > (indeed, the StructurealFeatureAction constraint the property whose > opposite is being obtained is specifically required /not/ to be class > owned). > > > > So, I think the description of the attribute is correct, and the > constraint and OCL is what is actually wrong. Given that this is an > inconsistency, I believe we can fix it in UML 2.5. > > > > -- Ed > > > > ---------------------------------------------------------------------- > -- > > *From:* Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > *Sent:* Monday, August 01, 2011 9:06 AM > *To:* uml2-rtf@omg.org ; > uml-spec-simplification@omg.org > > *Cc:* issues@omg.org > *Subject:* property.opposite > > > > It seems there is an issue with derived Property.opposite. > > > > Spec says: > > > > / opposite : Property [0..1] In the case where the property is one > *navigable end of a binary association with both ends navigable*, this > gives the other end. > > > > By description, it should keep reference to opposite navigable end, > but OCL works only when navigable end is owned by class. > > It does not work when navigable end is owned by association: > > > > Constraint #1: > > [1] If this *property is owned by a class* associated with a binary > association, and the *other end of the association is also owned by a > class*, then opposite gives the other end. > > opposite = *if *owningAssociation->isEmpty() *and > *association.memberEnd->size() = 2 *then let *otherEnd = > (association.memberEnd - self)->any() *in if > *otherEnd.owningAssociation->isEmpty() *then *otherEnd *else *Set{} > *endif else *Set {} *endif * > > > > > > Any comments? > > Which one is correct? Property description or constraint text? > > > > Thanks, > > > > > > * --* > > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Europe > Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, > Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > -- > MagicDraw - UML made simple! > > > -- 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. Os Os OsFrom: Steve Cook To: Ed Seidewitz CC: "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" Subject: RE: property.opposite Thread-Topic: property.opposite Thread-Index: AQHMUGyhuX2BNIgzskWkFP51nALy9ZUIN2uAgAYk7VCAAAWfEIAAAMFQgAABdoA= Date: Fri, 5 Aug 2011 15:18:11 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.100] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p75FGlga013607 >From the OCL 2.2 spec: ... OclVoid has exactly one instance called null. ... However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). So I think null is ok. -----Original Message----- From: Steve Cook Sent: 05 August 2011 16:11 To: 'Ed Seidewitz' Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Null is required to make the constraint typecheck in RSA. If you use Set{} it complains that there is no common supertype of Set(OclVoid) and Property. I'll change the other things. -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 05 August 2011 16:10 To: Steve Cook Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Steve -- This looks about right. I few points of detail on the OCL (Nicolas can confirm if I have these points right!): - I don't think you can use "null" in OCL. It should be "Set{}". - Instead of "not association->isEmpty()", you can more simply write "association->notEmpty()". - I don't think it is required, but I think it is clearer to write "self.assocation" instead of just "association". -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 10:54 AM To: Ed Seidewitz; uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite I'm changing this in 2.5. The new derivation for opposite is this: result = if (not association->isEmpty()) and association.memberEnd->size() = 2 then association.memberEnd->any(e | e <> self) else null endif -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 August 2011 18:58 To: uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite Well, for the purposes of UML 2.5, we have to be careful again here about "should" statements. That is why I looked at the actual uses of "opposite" within the metamodel. The question, then, is whether navigability meant to be enforced in either of these cases. And, on a second look, I would agree that enforcement of navigability is not intended in either case, the only requirement being that the association in question is a binary association. Since neither of these cases require class ownership of the ends (and, in fact, the constraint for StructuralFeatureAction specifically allows at least one of the ends to be association owned), I would agree that we need to change _both_ the definition of the opposite property _and_ the definition of the constraint. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, August 01, 2011 12:56 PM To: Pete Rivett Cc: Ed Seidewitz; Nerijus Jankevicius; uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: Re: property.opposite I agree with Pete that the opposite of a binary end should always be the other end. Dave On 01/08/11 17:33, Pete Rivett wrote: > I disagree that navigability should have anything to do with the > definition or use of 'opposite' - the 'new' (actually not so new - it > dates back to the UML 2.0 FTF) definition of navigability is a mere > hint of expectation of efficiency. > > > > I also think the OCL is incorrect - for a binary association the 2 > ends should be the opposite of each other regardless of their ownership. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com] > *Sent:* Monday, August 01, 2011 7:35 AM > *To:* Nerijus Jankevicius > *Cc:* uml2-rtf@omg.org; uml-spec-simplification@omg.org > *Subject:* RE: property.opposite > > > > Nerijus - > > > > I believe this discrepancy is left over from the days when end > ownership determined navigability. In the original UML 2.0, the > description of opposite actually matched the OCL. When navigability > was separated from end ownership, the constraint OCL and description > remained valid, but the attribute description was not updated. > > > > As to which definition for opposite is really "correct", I found two > actually uses of opposite in the UML 2.4 spec, in constraint [2] of > StructuralFeatureAction and constraint [1] of Actor. Both these uses > seem to assume that opposite is based on navigability, not ownership > (indeed, the StructurealFeatureAction constraint the property whose > opposite is being obtained is specifically required /not/ to be class > owned). > > > > So, I think the description of the attribute is correct, and the > constraint and OCL is what is actually wrong. Given that this is an > inconsistency, I believe we can fix it in UML 2.5. > > > > -- Ed > > > > ---------------------------------------------------------------------- > -- > > *From:* Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > *Sent:* Monday, August 01, 2011 9:06 AM > *To:* uml2-rtf@omg.org ; > uml-spec-simplification@omg.org > > *Cc:* issues@omg.org > *Subject:* property.opposite > > > > It seems there is an issue with derived Property.opposite. > > > > Spec says: > > > > / opposite : Property [0..1] In the case where the property is one > *navigable end of a binary association with both ends navigable*, this > gives the other end. > > > > By description, it should keep reference to opposite navigable end, > but OCL works only when navigable end is owned by class. > > It does not work when navigable end is owned by association: > > > > Constraint #1: > > [1] If this *property is owned by a class* associated with a binary > association, and the *other end of the association is also owned by a > class*, then opposite gives the other end. > > opposite = *if *owningAssociation->isEmpty() *and > *association.memberEnd->size() = 2 *then let *otherEnd = > (association.memberEnd - self)->any() *in if > *otherEnd.owningAssociation->isEmpty() *then *otherEnd *else *Set{} > *endif else *Set {} *endif * > > > > > > Any comments? > > Which one is correct? Property description or constraint text? > > > > Thanks, > > > > > > * --* > > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Europe > Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, > Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > -- > MagicDraw - UML made simple! > > > -- 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. Os OsFrom: Ed Seidewitz To: Steve Cook CC: "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" Date: Fri, 5 Aug 2011 11:48:26 -0400 Subject: RE: property.opposite Thread-Topic: property.opposite Thread-Index: AQHMUGyhuX2BNIgzskWkFP51nALy9ZUIN2uAgAYk7VCAAAWfEIAAAMFQgAABdoCAAAihQA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-15592-c X-SpamInfo: helo-dns, X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p75FkriG016004 OK. The text on implicit conversion is a change from OCL 2.0 (not sure if it came in with 2.1 or 2.2). But I like it better than having to say Set{}! (However, I think RSA is wrong in not allowing Set{} for an optional value.) -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 11:18 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite >From the OCL 2.2 spec: ... OclVoid has exactly one instance called null. ... However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). So I think null is ok. -----Original Message----- From: Steve Cook Sent: 05 August 2011 16:11 To: 'Ed Seidewitz' Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Null is required to make the constraint typecheck in RSA. If you use Set{} it complains that there is no common supertype of Set(OclVoid) and Property. I'll change the other things. -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 05 August 2011 16:10 To: Steve Cook Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Steve -- This looks about right. I few points of detail on the OCL (Nicolas can confirm if I have these points right!): - I don't think you can use "null" in OCL. It should be "Set{}". - Instead of "not association->isEmpty()", you can more simply write "association->notEmpty()". - I don't think it is required, but I think it is clearer to write "self.assocation" instead of just "association". -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 10:54 AM To: Ed Seidewitz; uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite I'm changing this in 2.5. The new derivation for opposite is this: result = if (not association->isEmpty()) and association.memberEnd->size() = 2 then association.memberEnd->any(e | e <> self) else null endif -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 August 2011 18:58 To: uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite Well, for the purposes of UML 2.5, we have to be careful again here about "should" statements. That is why I looked at the actual uses of "opposite" within the metamodel. The question, then, is whether navigability meant to be enforced in either of these cases. And, on a second look, I would agree that enforcement of navigability is not intended in either case, the only requirement being that the association in question is a binary association. Since neither of these cases require class ownership of the ends (and, in fact, the constraint for StructuralFeatureAction specifically allows at least one of the ends to be association owned), I would agree that we need to change _both_ the definition of the opposite property _and_ the definition of the constraint. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, August 01, 2011 12:56 PM To: Pete Rivett Cc: Ed Seidewitz; Nerijus Jankevicius; uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: Re: property.opposite I agree with Pete that the opposite of a binary end should always be the other end. Dave On 01/08/11 17:33, Pete Rivett wrote: > I disagree that navigability should have anything to do with the > definition or use of 'opposite' - the 'new' (actually not so new - it > dates back to the UML 2.0 FTF) definition of navigability is a mere > hint of expectation of efficiency. > > > > I also think the OCL is incorrect - for a binary association the 2 > ends should be the opposite of each other regardless of their ownership. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com] > *Sent:* Monday, August 01, 2011 7:35 AM > *To:* Nerijus Jankevicius > *Cc:* uml2-rtf@omg.org; uml-spec-simplification@omg.org > *Subject:* RE: property.opposite > > > > Nerijus - > > > > I believe this discrepancy is left over from the days when end > ownership determined navigability. In the original UML 2.0, the > description of opposite actually matched the OCL. When navigability > was separated from end ownership, the constraint OCL and description > remained valid, but the attribute description was not updated. > > > > As to which definition for opposite is really "correct", I found two > actually uses of opposite in the UML 2.4 spec, in constraint [2] of > StructuralFeatureAction and constraint [1] of Actor. Both these uses > seem to assume that opposite is based on navigability, not ownership > (indeed, the StructurealFeatureAction constraint the property whose > opposite is being obtained is specifically required /not/ to be class > owned). > > > > So, I think the description of the attribute is correct, and the > constraint and OCL is what is actually wrong. Given that this is an > inconsistency, I believe we can fix it in UML 2.5. > > > > -- Ed > > > > ---------------------------------------------------------------------- > -- > > *From:* Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > *Sent:* Monday, August 01, 2011 9:06 AM > *To:* uml2-rtf@omg.org ; > uml-spec-simplification@omg.org > > *Cc:* issues@omg.org > *Subject:* property.opposite > > > > It seems there is an issue with derived Property.opposite. > > > > Spec says: > > > > / opposite : Property [0..1] In the case where the property is one > *navigable end of a binary association with both ends navigable*, this > gives the other end. > > > > By description, it should keep reference to opposite navigable end, > but OCL works only when navigable end is owned by class. > > It does not work when navigable end is owned by association: > > > > Constraint #1: > > [1] If this *property is owned by a class* associated with a binary > association, and the *other end of the association is also owned by a > class*, then opposite gives the other end. > > opposite = *if *owningAssociation->isEmpty() *and > *association.memberEnd->size() = 2 *then let *otherEnd = > (association.memberEnd - self)->any() *in if > *otherEnd.owningAssociation->isEmpty() *then *otherEnd *else *Set{} > *endif else *Set {} *endif * > > > > > > Any comments? > > Which one is correct? Property description or constraint text? > > > > Thanks, > > > > > > * --* > > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Europe > Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, > Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > -- > MagicDraw - UML made simple! > > > -- 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. Os Os OsSubject: RE: property.opposite To: Ed Seidewitz Cc: Steve Cook , "uml-spec-simplification@omg.org" , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 5 Aug 2011 12:14:20 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.5.1FP5|September 29, 2010) at 08/05/2011 12:14:23 I think RSA is right. OCL can typcast an object into a set implicitly but not the other way around. Ed Seidewitz Ed Seidewitz 08/05/2011 11:48 AM To Steve Cook cc "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" Subject RE: property.opposite OK. The text on implicit conversion is a change from OCL 2.0 (not sure if it came in with 2.1 or 2.2). But I like it better than having to say Set{}! (However, I think RSA is wrong in not allowing Set{} for an optional value.) -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 11:18 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite >From the OCL 2.2 spec: ... OclVoid has exactly one instance called null. ... However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). So I think null is ok. -----Original Message----- From: Steve Cook Sent: 05 August 2011 16:11 To: 'Ed Seidewitz' Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Null is required to make the constraint typecheck in RSA. If you use Set{} it complains that there is no common supertype of Set(OclVoid) and Property. I'll change the other things. -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 05 August 2011 16:10 To: Steve Cook Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Steve -- This looks about right. I few points of detail on the OCL (Nicolas can confirm if I have these points right!): - I don't think you can use "null" in OCL. It should be "Set{}". - Instead of "not association->isEmpty()", you can more simply write "association->notEmpty()". - I don't think it is required, but I think it is clearer to write "self.assocation" instead of just "association". -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 10:54 AM To: Ed Seidewitz; uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite I'm changing this in 2.5. The new derivation for opposite is this: result = if (not association->isEmpty()) and association.memberEnd->size() = 2 then association.memberEnd->any(e | e <> self) else null endif -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 August 2011 18:58 To: uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite Well, for the purposes of UML 2.5, we have to be careful again here about "should" statements. That is why I looked at the actual uses of "opposite" within the metamodel. The question, then, is whether navigability meant to be enforced in either of these cases. And, on a second look, I would agree that enforcement of navigability is not intended in either case, the only requirement being that the association in question is a binary association. Since neither of these cases require class ownership of the ends (and, in fact, the constraint for StructuralFeatureAction specifically allows at least one of the ends to be association owned), I would agree that we need to change _both_ the definition of the opposite property _and_ the definition of the constraint. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, August 01, 2011 12:56 PM To: Pete Rivett Cc: Ed Seidewitz; Nerijus Jankevicius; uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: Re: property.opposite I agree with Pete that the opposite of a binary end should always be the other end. Dave On 01/08/11 17:33, Pete Rivett wrote: > I disagree that navigability should have anything to do with the > definition or use of 'opposite' - the 'new' (actually not so new - it > dates back to the UML 2.0 FTF) definition of navigability is a mere > hint of expectation of efficiency. > > > > I also think the OCL is incorrect - for a binary association the 2 > ends should be the opposite of each other regardless of their ownership. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com] > *Sent:* Monday, August 01, 2011 7:35 AM > *To:* Nerijus Jankevicius > *Cc:* uml2-rtf@omg.org; uml-spec-simplification@omg.org > *Subject:* RE: property.opposite > > > > Nerijus - > > > > I believe this discrepancy is left over from the days when end > ownership determined navigability. In the original UML 2.0, the > description of opposite actually matched the OCL. When navigability > was separated from end ownership, the constraint OCL and description > remained valid, but the attribute description was not updated. > > > > As to which definition for opposite is really "correct", I found two > actually uses of opposite in the UML 2.4 spec, in constraint [2] of > StructuralFeatureAction and constraint [1] of Actor. Both these uses > seem to assume that opposite is based on navigability, not ownership > (indeed, the StructurealFeatureAction constraint the property whose > opposite is being obtained is specifically required /not/ to be class > owned). > > > > So, I think the description of the attribute is correct, and the > constraint and OCL is what is actually wrong. Given that this is an > inconsistency, I believe we can fix it in UML 2.5. > > > > -- Ed > > > > ---------------------------------------------------------------------- > -- > > *From:* Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > *Sent:* Monday, August 01, 2011 9:06 AM > *To:* uml2-rtf@omg.org ; > uml-spec-simplification@omg.org > > *Cc:* issues@omg.org > *Subject:* property.opposite > > > > It seems there is an issue with derived Property.opposite. > > > > Spec says: > > > > / opposite : Property [0..1] In the case where the property is one > *navigable end of a binary association with both ends navigable*, this > gives the other end. > > > > By description, it should keep reference to opposite navigable end, > but OCL works only when navigable end is owned by class. > > It does not work when navigable end is owned by association: > > > > Constraint #1: > > [1] If this *property is owned by a class* associated with a binary > association, and the *other end of the association is also owned by a > class*, then opposite gives the other end. > > opposite = *if *owningAssociation->isEmpty() *and > *association.memberEnd->size() = 2 *then let *otherEnd = > (association.memberEnd - self)->any() *in if > *otherEnd.owningAssociation->isEmpty() *then *otherEnd *else *Set{} > *endif else *Set {} *endif * > > > > > > Any comments? > > Which one is correct? Property description or constraint text? > > > > Thanks, > > > > > > * --* > > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Europe > Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, > Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > -- > MagicDraw - UML made simple! > > > -- 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. pic32361.gif Os Os OsFrom: Ed Seidewitz To: Maged Elaasar CC: Steve Cook , "uml-spec-simplification@omg.org" , "uml2-rtf@omg.org" Date: Fri, 5 Aug 2011 12:29:12 -0400 Subject: RE: property.opposite Thread-Topic: property.opposite Thread-Index: AcxTisPUSVhNfQ4dRFyEIE81GpCwIgAADDAw Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|-0.995333|0.838802|0|white|ugly|3420|8|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0.838802 p=-0.995333 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-SpamInfo: helo-dns, Maged . The result of the opposite operation should be an optional Property (multiplicity 0..1). An optional value is represented in OCL as a set of either zero or one value, with type Set(Property). Therefore a return value of Set{} should work for the case of returning .no Property. (the empty set). At least, that is the way it used to be. Perhaps the return type is now just Property, and OCL typing would then allow null to be returned, but, perhaps, would not allow Set{}. I say .perhaps. above, because in Subclause 7.5.3 of the OCL 2.2 spec it says .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object.. However, because this under the heading .Navigation over Associations with Multiplicity Zero or One., it is not entirely clear how generally it implies. But I have generally taken it to mean that, generally, a single value should always be allowed to be treated as a set of one value, and that one can always use the empty set in the case when a value is optional. (This would be consistent with UML semantics on multiplicity . which OCL tries, not entirely successfully, to shoehorn its collection typing into.) It was in this sense that I considered RSA to be wrong. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, August 05, 2011 12:14 PM To: Ed Seidewitz Cc: Steve Cook; uml-spec-simplification@omg.org; uml2-rtf@omg.org Subject: RE: property.opposite I think RSA is right. OCL can typcast an object into a set implicitly but not the other way around. Ed Seidewitz Ed Seidewitz 08/05/2011 11:48 AM To Steve Cook cc "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" Subject RE: property.opposite OK. The text on implicit conversion is a change from OCL 2.0 (not sure if it came in with 2.1 or 2.2). But I like it better than having to say Set{}! (However, I think RSA is wrong in not allowing Set{} for an optional value.) -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 11:18 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite From the OCL 2.2 spec: ... OclVoid has exactly one instance called null. ... However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). So I think null is ok. -----Original Message----- From: Steve Cook Sent: 05 August 2011 16:11 To: 'Ed Seidewitz' Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Null is required to make the constraint typecheck in RSA. If you use Set{} it complains that there is no common supertype of Set(OclVoid) and Property. I'll change the other things. -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 05 August 2011 16:10 To: Steve Cook Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Steve -- This looks about right. I few points of detail on the OCL (Nicolas can confirm if I have these points right!): - I don't think you can use "null" in OCL. It should be "Set{}". - Instead of "not association->isEmpty()", you can more simply write "association->notEmpty()". - I don't think it is required, but I think it is clearer to write "self.assocation" instead of just "association". -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 10:54 AM To: Ed Seidewitz; uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite I'm changing this in 2.5. The new derivation for opposite is this: result = if (not association->isEmpty()) and association.memberEnd->size() = 2 then association.memberEnd->any(e | e <> self) else null endif -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 August 2011 18:58 To: uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite Well, for the purposes of UML 2.5, we have to be careful again here about "should" statements. That is why I looked at the actual uses of "opposite" within the metamodel. The question, then, is whether navigability meant to be enforced in either of these cases. And, on a second look, I would agree that enforcement of navigability is not intended in either case, the only requirement being that the association in question is a binary association. Since neither of these cases require class ownership of the ends (and, in fact, the constraint for StructuralFeatureAction specifically allows at least one of the ends to be association owned), I would agree that we need to change _both_ the definition of the opposite property _and_ the definition of the constraint. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, August 01, 2011 12:56 PM To: Pete Rivett Cc: Ed Seidewitz; Nerijus Jankevicius; uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: Re: property.opposite I agree with Pete that the opposite of a binary end should always be the other end. Dave On 01/08/11 17:33, Pete Rivett wrote: > I disagree that navigability should have anything to do with the > definition or use of 'opposite' - the 'new' (actually not so new - it > dates back to the UML 2.0 FTF) definition of navigability is a mere > hint of expectation of efficiency. > > > > I also think the OCL is incorrect - for a binary association the 2 > ends should be the opposite of each other regardless of their ownership. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com] > *Sent:* Monday, August 01, 2011 7:35 AM > *To:* Nerijus Jankevicius > *Cc:* uml2-rtf@omg.org; uml-spec-simplification@omg.org > *Subject:* RE: property.opposite > > > > Nerijus - > > > > I believe this discrepancy is left over from the days when end > ownership determined navigability. In the original UML 2.0, the > description of opposite actually matched the OCL. When navigability > was separated from end ownership, the constraint OCL and description > remained valid, but the attribute description was not updated. > > > > As to which definition for opposite is really "correct", I found two > actually uses of opposite in the UML 2.4 spec, in constraint [2] of > StructuralFeatureAction and constraint [1] of Actor. Both these uses > seem to assume that opposite is based on navigability, not ownership > (indeed, the StructurealFeatureAction constraint the property whose > opposite is being obtained is specifically required /not/ to be class > owned). > > > > So, I think the description of the attribute is correct, and the > constraint and OCL is what is actually wrong. Given that this is an > inconsistency, I believe we can fix it in UML 2.5. > > > > -- Ed > > > > ---------------------------------------------------------------------- > -- > > *From:* Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > *Sent:* Monday, August 01, 2011 9:06 AM > *To:* uml2-rtf@omg.org ; > uml-spec-simplification@omg.org > > *Cc:* issues@omg.org > *Subject:* property.opposite > > > > It seems there is an issue with derived Property.opposite. > > > > Spec says: > > > > / opposite : Property [0..1] In the case where the property is one > *navigable end of a binary association with both ends navigable*, this > gives the other end. > > > > By description, it should keep reference to opposite navigable end, > but OCL works only when navigable end is owned by class. > > It does not work when navigable end is owned by association: > > > > Constraint #1: > > [1] If this *property is owned by a class* associated with a binary > association, and the *other end of the association is also owned by a > class*, then opposite gives the other end. > > opposite = *if *owningAssociation->isEmpty() *and > *association.memberEnd->size() = 2 *then let *otherEnd = > (association.memberEnd - self)->any() *in if > *otherEnd.owningAssociation->isEmpty() *then *otherEnd *else *Set{} > *endif else *Set {} *endif * > > > > > > Any comments? > > Which one is correct? Property description or constraint text? > > > > Thanks, > > > > > > * --* > > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Europe > Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, > Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > -- > MagicDraw - UML made simple! > > > -- 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. Os Os OsSubject: RE: property.opposite To: Ed Seidewitz Cc: Steve Cook , "uml-spec-simplification@omg.org" , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 5 Aug 2011 12:45:00 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.5.1FP5|September 29, 2010) at 08/05/2011 12:45:03 Ed, I am not sure I agree the optional value should be represented as a Set (of either zero or one) vs. an Object directly in OCL. In the former case, how would the OCL parser enforce that constraint (zero or one) on sets? parsers would only see that you are assigning a set to a set, it does not know about the contents of the set unless you make it look for Set{} literally, which I do not think you are implying (since an empty set can also be produced with an expression). On the other case, an object is unambiguous for parsers since you can always assign "null" or an expression that evalutates to an object as a value. Maged Ed Seidewitz Ed Seidewitz 08/05/2011 12:29 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Steve Cook , "uml-spec-simplification@omg.org" , "uml2-rtf@omg.org" Subject RE: property.opposite Maged . The result of the opposite operation should be an optional Property (multiplicity 0..1). An optional value is represented in OCL as a set of either zero or one value, with type Set(Property). Therefore a return value of Set{} should work for the case of returning .no Property. (the empty set). At least, that is the way it used to be. Perhaps the return type is now just Property, and OCL typing would then allow null to be returned, but, perhaps, would not allow Set{}. I say .perhaps. above, because in Subclause 7.5.3 of the OCL 2.2 spec it says .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object.. However, because this under the heading .Navigation over Associations with Multiplicity Zero or One., it is not entirely clear how generally it implies. But I have generally taken it to mean that, generally, a single value should always be allowed to be treated as a set of one value, and that one can always use the empty set in the case when a value is optional. (This would be consistent with UML semantics on multiplicity . which OCL tries, not entirely successfully, to shoehorn its collection typing into.) It was in this sense that I considered RSA to be wrong. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, August 05, 2011 12:14 PM To: Ed Seidewitz Cc: Steve Cook; uml-spec-simplification@omg.org; uml2-rtf@omg.org Subject: RE: property.opposite I think RSA is right. OCL can typcast an object into a set implicitly but not the other way around. Ed Seidewitz Ed Seidewitz 08/05/2011 11:48 AM To Steve Cook cc "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" Subject RE: property.opposite OK. The text on implicit conversion is a change from OCL 2.0 (not sure if it came in with 2.1 or 2.2). But I like it better than having to say Set{}! (However, I think RSA is wrong in not allowing Set{} for an optional value.) -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 11:18 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite >From the OCL 2.2 spec: ... OclVoid has exactly one instance called null. ... However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). So I think null is ok. -----Original Message----- From: Steve Cook Sent: 05 August 2011 16:11 To: 'Ed Seidewitz' Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Null is required to make the constraint typecheck in RSA. If you use Set{} it complains that there is no common supertype of Set(OclVoid) and Property. I'll change the other things. -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 05 August 2011 16:10 To: Steve Cook Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Steve -- This looks about right. I few points of detail on the OCL (Nicolas can confirm if I have these points right!): - I don't think you can use "null" in OCL. It should be "Set{}". - Instead of "not association->isEmpty()", you can more simply write "association->notEmpty()". - I don't think it is required, but I think it is clearer to write "self.assocation" instead of just "association". -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 10:54 AM To: Ed Seidewitz; uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite I'm changing this in 2.5. The new derivation for opposite is this: result = if (not association->isEmpty()) and association.memberEnd->size() = 2 then association.memberEnd->any(e | e <> self) else null endif -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 August 2011 18:58 To: uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite Well, for the purposes of UML 2.5, we have to be careful again here about "should" statements. That is why I looked at the actual uses of "opposite" within the metamodel. The question, then, is whether navigability meant to be enforced in either of these cases. And, on a second look, I would agree that enforcement of navigability is not intended in either case, the only requirement being that the association in question is a binary association. Since neither of these cases require class ownership of the ends (and, in fact, the constraint for StructuralFeatureAction specifically allows at least one of the ends to be association owned), I would agree that we need to change _both_ the definition of the opposite property _and_ the definition of the constraint. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, August 01, 2011 12:56 PM To: Pete Rivett Cc: Ed Seidewitz; Nerijus Jankevicius; uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: Re: property.opposite I agree with Pete that the opposite of a binary end should always be the other end. Dave On 01/08/11 17:33, Pete Rivett wrote: > I disagree that navigability should have anything to do with the > definition or use of 'opposite' - the 'new' (actually not so new - it > dates back to the UML 2.0 FTF) definition of navigability is a mere > hint of expectation of efficiency. > > > > I also think the OCL is incorrect - for a binary association the 2 > ends should be the opposite of each other regardless of their ownership. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com] > *Sent:* Monday, August 01, 2011 7:35 AM > *To:* Nerijus Jankevicius > *Cc:* uml2-rtf@omg.org; uml-spec-simplification@omg.org > *Subject:* RE: property.opposite > > > > Nerijus - > > > > I believe this discrepancy is left over from the days when end > ownership determined navigability. In the original UML 2.0, the > description of opposite actually matched the OCL. When navigability > was separated from end ownership, the constraint OCL and description > remained valid, but the attribute description was not updated. > > > > As to which definition for opposite is really "correct", I found two > actually uses of opposite in the UML 2.4 spec, in constraint [2] of > StructuralFeatureAction and constraint [1] of Actor. Both these uses > seem to assume that opposite is based on navigability, not ownership > (indeed, the StructurealFeatureAction constraint the property whose > opposite is being obtained is specifically required /not/ to be class > owned). > > > > So, I think the description of the attribute is correct, and the > constraint and OCL is what is actually wrong. Given that this is an > inconsistency, I believe we can fix it in UML 2.5. > > > > -- Ed > > > > ---------------------------------------------------------------------- > -- > > *From:* Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > *Sent:* Monday, August 01, 2011 9:06 AM > *To:* uml2-rtf@omg.org ; > uml-spec-simplification@omg.org > > *Cc:* issues@omg.org > *Subject:* property.opposite > > > > It seems there is an issue with derived Property.opposite. > > > > Spec says: > > > > / opposite : Property [0..1] In the case where the property is one > *navigable end of a binary association with both ends navigable*, this > gives the other end. > > > > By description, it should keep reference to opposite navigable end, > but OCL works only when navigable end is owned by class. > > It does not work when navigable end is owned by association: > > > > Constraint #1: > > [1] If this *property is owned by a class* associated with a binary > association, and the *other end of the association is also owned by a > class*, then opposite gives the other end. > > opposite = *if *owningAssociation->isEmpty() *and > *association.memberEnd->size() = 2 *then let *otherEnd = > (association.memberEnd - self)->any() *in if > *otherEnd.owningAssociation->isEmpty() *then *otherEnd *else *Set{} > *endif else *Set {} *endif * > > > > > > Any comments? > > Which one is correct? Property description or constraint text? > > > > Thanks, > > > > > > * --* > > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Europe > Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, > Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > -- > MagicDraw - UML made simple! > > > -- 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. pic06105.gif Os Os OsFrom: Ed Seidewitz To: Maged Elaasar CC: Steve Cook , "uml-spec-simplification@omg.org" , "uml2-rtf@omg.org" Date: Fri, 5 Aug 2011 12:58:21 -0400 Subject: RE: property.opposite Thread-Topic: property.opposite Thread-Index: AcxTjwoF1IqgQj+IQWizRt9C2wfjOgAAGGOQ Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-SpamInfo: helo-dns, Maged . An OCL parser cannot enforce the constraint statically, because OCL unfortunately does not track the multiplicity of intermediate expressions. However, it can be checked dynamically, just as general multiplicity constraints have to be. (E.g., you can.t in general check statically in OCL that the assignment of a set to a property with multiplicity 1..5 has at least one and no more than 5 values.) The point isn.t what a parser can check, though. The point is what is what the spec says and what is reasonable for a notation that is supposed to be usable as a UML constraint language. In UML semantics, it is perfectly reasonable to assign the empty set to an optional property. In fact, you have to be able to do this, since a null literal in UML does not represent any special .null. value, but .the absence of a value. . i.e., the empty set. The difficulty is that OCL is trying to have it both ways: To treat .null. as a value but to still allow it to be used like a UML null literal. This leads to complications that are still not entirely clearly handled in the OCL spec (though 2.2 is better than 2.0). -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, August 05, 2011 12:45 PM To: Ed Seidewitz Cc: Steve Cook; uml-spec-simplification@omg.org; uml2-rtf@omg.org Subject: RE: property.opposite Ed, I am not sure I agree the optional value should be represented as a Set (of either zero or one) vs. an Object directly in OCL. In the former case, how would the OCL parser enforce that constraint (zero or one) on sets? parsers would only see that you are assigning a set to a set, it does not know about the contents of the set unless you make it look for Set{} literally, which I do not think you are implying (since an empty set can also be produced with an expression). On the other case, an object is unambiguous for parsers since you can always assign "null" or an expression that evalutates to an object as a value. Maged Ed Seidewitz Ed Seidewitz 08/05/2011 12:29 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Steve Cook , "uml-spec-simplification@omg.org" , "uml2-rtf@omg.org" Subject RE: property.opposite Maged . The result of the opposite operation should be an optional Property (multiplicity 0..1). An optional value is represented in OCL as a set of either zero or one value, with type Set(Property). Therefore a return value of Set{} should work for the case of returning .no Property. (the empty set). At least, that is the way it used to be. Perhaps the return type is now just Property, and OCL typing would then allow null to be returned, but, perhaps, would not allow Set{}. I say .perhaps. above, because in Subclause 7.5.3 of the OCL 2.2 spec it says .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object.. However, because this under the heading .Navigation over Associations with Multiplicity Zero or One., it is not entirely clear how generally it implies. But I have generally taken it to mean that, generally, a single value should always be allowed to be treated as a set of one value, and that one can always use the empty set in the case when a value is optional. (This would be consistent with UML semantics on multiplicity . which OCL tries, not entirely successfully, to shoehorn its collection typing into.) It was in this sense that I considered RSA to be wrong. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, August 05, 2011 12:14 PM To: Ed Seidewitz Cc: Steve Cook; uml-spec-simplification@omg.org; uml2-rtf@omg.org Subject: RE: property.opposite I think RSA is right. OCL can typcast an object into a set implicitly but not the other way around. Ed Seidewitz Ed Seidewitz 08/05/2011 11:48 AM To Steve Cook cc "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" Subject RE: property.opposite OK. The text on implicit conversion is a change from OCL 2.0 (not sure if it came in with 2.1 or 2.2). But I like it better than having to say Set{}! (However, I think RSA is wrong in not allowing Set{} for an optional value.) -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 11:18 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite >From the OCL 2.2 spec: ... OclVoid has exactly one instance called null. ... However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). So I think null is ok. -----Original Message----- From: Steve Cook Sent: 05 August 2011 16:11 To: 'Ed Seidewitz' Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Null is required to make the constraint typecheck in RSA. If you use Set{} it complains that there is no common supertype of Set(OclVoid) and Property. I'll change the other things. -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 05 August 2011 16:10 To: Steve Cook Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Steve -- This looks about right. I few points of detail on the OCL (Nicolas can confirm if I have these points right!): - I don't think you can use "null" in OCL. It should be "Set{}". - Instead of "not association->isEmpty()", you can more simply write "association->notEmpty()". - I don't think it is required, but I think it is clearer to write "self.assocation" instead of just "association". -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 10:54 AM To: Ed Seidewitz; uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite I'm changing this in 2.5. The new derivation for opposite is this: result = if (not association->isEmpty()) and association.memberEnd->size() = 2 then association.memberEnd->any(e | e <> self) else null endif -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 August 2011 18:58 To: uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite Well, for the purposes of UML 2.5, we have to be careful again here about "should" statements. That is why I looked at the actual uses of "opposite" within the metamodel. The question, then, is whether navigability meant to be enforced in either of these cases. And, on a second look, I would agree that enforcement of navigability is not intended in either case, the only requirement being that the association in question is a binary association. Since neither of these cases require class ownership of the ends (and, in fact, the constraint for StructuralFeatureAction specifically allows at least one of the ends to be association owned), I would agree that we need to change _both_ the definition of the opposite property _and_ the definition of the constraint. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, August 01, 2011 12:56 PM To: Pete Rivett Cc: Ed Seidewitz; Nerijus Jankevicius; uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: Re: property.opposite I agree with Pete that the opposite of a binary end should always be the other end. Dave On 01/08/11 17:33, Pete Rivett wrote: > I disagree that navigability should have anything to do with the > definition or use of 'opposite' - the 'new' (actually not so new - it > dates back to the UML 2.0 FTF) definition of navigability is a mere > hint of expectation of efficiency. > > > > I also think the OCL is incorrect - for a binary association the 2 > ends should be the opposite of each other regardless of their ownership. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com] > *Sent:* Monday, August 01, 2011 7:35 AM > *To:* Nerijus Jankevicius > *Cc:* uml2-rtf@omg.org; uml-spec-simplification@omg.org > *Subject:* RE: property.opposite > > > > Nerijus - > > > > I believe this discrepancy is left over from the days when end > ownership determined navigability. In the original UML 2.0, the > description of opposite actually matched the OCL. When navigability > was separated from end ownership, the constraint OCL and description > remained valid, but the attribute description was not updated. > > > > As to which definition for opposite is really "correct", I found two > actually uses of opposite in the UML 2.4 spec, in constraint [2] of > StructuralFeatureAction and constraint [1] of Actor. Both these uses > seem to assume that opposite is based on navigability, not ownership > (indeed, the StructurealFeatureAction constraint the property whose > opposite is being obtained is specifically required /not/ to be class > owned). > > > > So, I think the description of the attribute is correct, and the > constraint and OCL is what is actually wrong. Given that this is an > inconsistency, I believe we can fix it in UML 2.5. > > > > -- Ed > > > > ---------------------------------------------------------------------- > -- > > *From:* Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > *Sent:* Monday, August 01, 2011 9:06 AM > *To:* uml2-rtf@omg.org ; > uml-spec-simplification@omg.org > > *Cc:* issues@omg.org > *Subject:* property.opposite > > > > It seems there is an issue with derived Property.opposite. > > > > Spec says: > > > > / opposite : Property [0..1] In the case where the property is one > *navigable end of a binary association with both ends navigable*, this > gives the other end. > > > > By description, it should keep reference to opposite navigable end, > but OCL works only when navigable end is owned by class. > > It does not work when navigable end is owned by association: > > > > Constraint #1: > > [1] If this *property is owned by a class* associated with a binary > association, and the *other end of the association is also owned by a > class*, then opposite gives the other end. > > opposite = *if *owningAssociation->isEmpty() *and > *association.memberEnd->size() = 2 *then let *otherEnd = > (association.memberEnd - self)->any() *in if > *otherEnd.owningAssociation->isEmpty() *then *otherEnd *else *Set{} > *endif else *Set {} *endif * > > > > > > Any comments? > > Which one is correct? Property description or constraint text? > > > > Thanks, > > > > > > * --* > > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Europe > Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, > Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > -- > MagicDraw - UML made simple! > > > -- 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. Os Os OsSubject: RE: property.opposite To: Ed Seidewitz Cc: Steve Cook , "uml-spec-simplification@omg.org" , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 5 Aug 2011 14:51:45 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.5.1FP5|September 29, 2010) at 08/05/2011 14:51:48 Ed, if we map [0..1] to a collection, (with zero or one value), why would not we also map [1] to a collection (with one value)? My point is that we are looking for the "closest" mapping to OCL, and in my mind mapping [0..1] to a Type vs. collection has more benefits for statuc type checking. Maged Ed Seidewitz Ed Seidewitz 08/05/2011 12:58 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Steve Cook , "uml-spec-simplification@omg.org" , "uml2-rtf@omg.org" Subject RE: property.opposite Maged . An OCL parser cannot enforce the constraint statically, because OCL unfortunately does not track the multiplicity of intermediate expressions. However, it can be checked dynamically, just as general multiplicity constraints have to be. (E.g., you can.t in general check statically in OCL that the assignment of a set to a property with multiplicity 1..5 has at least one and no more than 5 values.) The point isn.t what a parser can check, though. The point is what is what the spec says and what is reasonable for a notation that is supposed to be usable as a UML constraint language. In UML semantics, it is perfectly reasonable to assign the empty set to an optional property. In fact, you have to be able to do this, since a null literal in UML does not represent any special .null. value, but .the absence of a value. . i.e., the empty set. The difficulty is that OCL is trying to have it both ways: To treat .null. as a value but to still allow it to be used like a UML null literal. This leads to complications that are still not entirely clearly handled in the OCL spec (though 2.2 is better than 2.0). -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, August 05, 2011 12:45 PM To: Ed Seidewitz Cc: Steve Cook; uml-spec-simplification@omg.org; uml2-rtf@omg.org Subject: RE: property.opposite Ed, I am not sure I agree the optional value should be represented as a Set (of either zero or one) vs. an Object directly in OCL. In the former case, how would the OCL parser enforce that constraint (zero or one) on sets? parsers would only see that you are assigning a set to a set, it does not know about the contents of the set unless you make it look for Set{} literally, which I do not think you are implying (since an empty set can also be produced with an expression). On the other case, an object is unambiguous for parsers since you can always assign "null" or an expression that evalutates to an object as a value. Maged Ed Seidewitz Ed Seidewitz 08/05/2011 12:29 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Steve Cook , "uml-spec-simplification@omg.org" , "uml2-rtf@omg.org" Subject RE: property.opposite Maged . The result of the opposite operation should be an optional Property (multiplicity 0..1). An optional value is represented in OCL as a set of either zero or one value, with type Set(Property). Therefore a return value of Set{} should work for the case of returning .no Property. (the empty set). At least, that is the way it used to be. Perhaps the return type is now just Property, and OCL typing would then allow null to be returned, but, perhaps, would not allow Set{}. I say .perhaps. above, because in Subclause 7.5.3 of the OCL 2.2 spec it says .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object.. However, because this under the heading .Navigation over Associations with Multiplicity Zero or One., it is not entirely clear how generally it implies. But I have generally taken it to mean that, generally, a single value should always be allowed to be treated as a set of one value, and that one can always use the empty set in the case when a value is optional. (This would be consistent with UML semantics on multiplicity . which OCL tries, not entirely successfully, to shoehorn its collection typing into.) It was in this sense that I considered RSA to be wrong. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, August 05, 2011 12:14 PM To: Ed Seidewitz Cc: Steve Cook; uml-spec-simplification@omg.org; uml2-rtf@omg.org Subject: RE: property.opposite I think RSA is right. OCL can typcast an object into a set implicitly but not the other way around. Ed Seidewitz Ed Seidewitz 08/05/2011 11:48 AM To Steve Cook cc "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" Subject RE: property.opposite OK. The text on implicit conversion is a change from OCL 2.0 (not sure if it came in with 2.1 or 2.2). But I like it better than having to say Set{}! (However, I think RSA is wrong in not allowing Set{} for an optional value.) -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 11:18 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite >From the OCL 2.2 spec: ... OclVoid has exactly one instance called null. ... However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). So I think null is ok. -----Original Message----- From: Steve Cook Sent: 05 August 2011 16:11 To: 'Ed Seidewitz' Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Null is required to make the constraint typecheck in RSA. If you use Set{} it complains that there is no common supertype of Set(OclVoid) and Property. I'll change the other things. -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 05 August 2011 16:10 To: Steve Cook Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Steve -- This looks about right. I few points of detail on the OCL (Nicolas can confirm if I have these points right!): - I don't think you can use "null" in OCL. It should be "Set{}". - Instead of "not association->isEmpty()", you can more simply write "association->notEmpty()". - I don't think it is required, but I think it is clearer to write "self.assocation" instead of just "association". -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 10:54 AM To: Ed Seidewitz; uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite I'm changing this in 2.5. The new derivation for opposite is this: result = if (not association->isEmpty()) and association.memberEnd->size() = 2 then association.memberEnd->any(e | e <> self) else null endif -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 August 2011 18:58 To: uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite Well, for the purposes of UML 2.5, we have to be careful again here about "should" statements. That is why I looked at the actual uses of "opposite" within the metamodel. The question, then, is whether navigability meant to be enforced in either of these cases. And, on a second look, I would agree that enforcement of navigability is not intended in either case, the only requirement being that the association in question is a binary association. Since neither of these cases require class ownership of the ends (and, in fact, the constraint for StructuralFeatureAction specifically allows at least one of the ends to be association owned), I would agree that we need to change _both_ the definition of the opposite property _and_ the definition of the constraint. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, August 01, 2011 12:56 PM To: Pete Rivett Cc: Ed Seidewitz; Nerijus Jankevicius; uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: Re: property.opposite I agree with Pete that the opposite of a binary end should always be the other end. Dave On 01/08/11 17:33, Pete Rivett wrote: > I disagree that navigability should have anything to do with the > definition or use of 'opposite' - the 'new' (actually not so new - it > dates back to the UML 2.0 FTF) definition of navigability is a mere > hint of expectation of efficiency. > > > > I also think the OCL is incorrect - for a binary association the 2 > ends should be the opposite of each other regardless of their ownership. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com] > *Sent:* Monday, August 01, 2011 7:35 AM > *To:* Nerijus Jankevicius > *Cc:* uml2-rtf@omg.org; uml-spec-simplification@omg.org > *Subject:* RE: property.opposite > > > > Nerijus - > > > > I believe this discrepancy is left over from the days when end > ownership determined navigability. In the original UML 2.0, the > description of opposite actually matched the OCL. When navigability > was separated from end ownership, the constraint OCL and description > remained valid, but the attribute description was not updated. > > > > As to which definition for opposite is really "correct", I found two > actually uses of opposite in the UML 2.4 spec, in constraint [2] of > StructuralFeatureAction and constraint [1] of Actor. Both these uses > seem to assume that opposite is based on navigability, not ownership > (indeed, the StructurealFeatureAction constraint the property whose > opposite is being obtained is specifically required /not/ to be class > owned). > > > > So, I think the description of the attribute is correct, and the > constraint and OCL is what is actually wrong. Given that this is an > inconsistency, I believe we can fix it in UML 2.5. > > > > -- Ed > > > > ---------------------------------------------------------------------- > -- > > *From:* Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > *Sent:* Monday, August 01, 2011 9:06 AM > *To:* uml2-rtf@omg.org ; > uml-spec-simplification@omg.org > > *Cc:* issues@omg.org > *Subject:* property.opposite > > > > It seems there is an issue with derived Property.opposite. > > > > Spec says: > > > > / opposite : Property [0..1] In the case where the property is one > *navigable end of a binary association with both ends navigable*, this > gives the other end. > > > > By description, it should keep reference to opposite navigable end, > but OCL works only when navigable end is owned by class. > > It does not work when navigable end is owned by association: > > > > Constraint #1: > > [1] If this *property is owned by a class* associated with a binary > association, and the *other end of the association is also owned by a > class*, then opposite gives the other end. > > opposite = *if *owningAssociation->isEmpty() *and > *association.memberEnd->size() = 2 *then let *otherEnd = > (association.memberEnd - self)->any() *in if > *otherEnd.owningAssociation->isEmpty() *then *otherEnd *else *Set{} > *endif else *Set {} *endif * > > > > > > Any comments? > > Which one is correct? Property description or constraint text? > > > > Thanks, > > > > > > * --* > > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Europe > Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, > Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > -- > MagicDraw - UML made simple! > > > -- 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. pic02139.gif Os OsFrom: Ed Seidewitz To: Maged Elaasar CC: Steve Cook , "uml-spec-simplification@omg.org" , "uml2-rtf@omg.org" Date: Fri, 5 Aug 2011 15:09:36 -0400 Subject: RE: property.opposite Thread-Topic: property.opposite Thread-Index: AcxToWv51vzlqtpdSX23udDkOzGVvQAAHqVA Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-SpamInfo: helo-dns, Maged . This is a matter of interpreting the spec, not deciding what is or isn.t the .closest mapping.. Here again is the part of the OCL spec I quoted previously: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object.. So, self.manager has a type of Person (not a collection), but .such a single object can be used as a Set as well.. So, you can map Person[0..1] to just Person in OCL, but you can then treat that as a set type, with .empty. being Set{}. It is now clear in OCL 2.2 that you can also use .null. in this case, because it can be converted to Set{} (well, really Bag{}, but for a set of zero or one element, that doesn.t matter). I don.t really see the point of this kind of null conversion unless it is to accommodate the UML .empty set. semantics for optional values. And, again, the underlying issue is that UML does not have .built in. collection classes, so all multiplicity elements are fundamentally multivalued. Having a multiplicity upper bound of 1 is just a degenerate case in which the number of values allowed happens to be limited to 1. A lot of effort (and confusion) then has to be expended to map the OCL collection types into this. (It doesn.t have to be this way, either. For example, since Alf semantics are based directly on UML semantics, the Alf semantics of values directly accommodate UML multiplicity. Collection classes are then added on top of that in a normal UML model library, which can actually be implemented in terms of the underlying multiplicity semantics.) -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, August 05, 2011 2:52 PM To: Ed Seidewitz Cc: Steve Cook; uml-spec-simplification@omg.org; uml2-rtf@omg.org Subject: RE: property.opposite Ed, if we map [0..1] to a collection, (with zero or one value), why would not we also map [1] to a collection (with one value)? My point is that we are looking for the "closest" mapping to OCL, and in my mind mapping [0..1] to a Type vs. collection has more benefits for statuc type checking. Maged Ed Seidewitz Ed Seidewitz 08/05/2011 12:58 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Steve Cook , "uml-spec-simplification@omg.org" , "uml2-rtf@omg.org" Subject RE: property.opposite Maged . An OCL parser cannot enforce the constraint statically, because OCL unfortunately does not track the multiplicity of intermediate expressions. However, it can be checked dynamically, just as general multiplicity constraints have to be. (E.g., you can.t in general check statically in OCL that the assignment of a set to a property with multiplicity 1..5 has at least one and no more than 5 values.) The point isn.t what a parser can check, though. The point is what is what the spec says and what is reasonable for a notation that is supposed to be usable as a UML constraint language. In UML semantics, it is perfectly reasonable to assign the empty set to an optional property. In fact, you have to be able to do this, since a null literal in UML does not represent any special .null. value, but .the absence of a value. . i.e., the empty set. The difficulty is that OCL is trying to have it both ways: To treat .null. as a value but to still allow it to be used like a UML null literal. This leads to complications that are still not entirely clearly handled in the OCL spec (though 2.2 is better than 2.0). -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, August 05, 2011 12:45 PM To: Ed Seidewitz Cc: Steve Cook; uml-spec-simplification@omg.org; uml2-rtf@omg.org Subject: RE: property.opposite Ed, I am not sure I agree the optional value should be represented as a Set (of either zero or one) vs. an Object directly in OCL. In the former case, how would the OCL parser enforce that constraint (zero or one) on sets? parsers would only see that you are assigning a set to a set, it does not know about the contents of the set unless you make it look for Set{} literally, which I do not think you are implying (since an empty set can also be produced with an expression). On the other case, an object is unambiguous for parsers since you can always assign "null" or an expression that evalutates to an object as a value. Maged Ed Seidewitz Ed Seidewitz 08/05/2011 12:29 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Steve Cook , "uml-spec-simplification@omg.org" , "uml2-rtf@omg.org" Subject RE: property.opposite Maged . The result of the opposite operation should be an optional Property (multiplicity 0..1). An optional value is represented in OCL as a set of either zero or one value, with type Set(Property). Therefore a return value of Set{} should work for the case of returning .no Property. (the empty set). At least, that is the way it used to be. Perhaps the return type is now just Property, and OCL typing would then allow null to be returned, but, perhaps, would not allow Set{}. I say .perhaps. above, because in Subclause 7.5.3 of the OCL 2.2 spec it says .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object.. However, because this under the heading .Navigation over Associations with Multiplicity Zero or One., it is not entirely clear how generally it implies. But I have generally taken it to mean that, generally, a single value should always be allowed to be treated as a set of one value, and that one can always use the empty set in the case when a value is optional. (This would be consistent with UML semantics on multiplicity . which OCL tries, not entirely successfully, to shoehorn its collection typing into.) It was in this sense that I considered RSA to be wrong. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, August 05, 2011 12:14 PM To: Ed Seidewitz Cc: Steve Cook; uml-spec-simplification@omg.org; uml2-rtf@omg.org Subject: RE: property.opposite I think RSA is right. OCL can typcast an object into a set implicitly but not the other way around. Ed Seidewitz Ed Seidewitz 08/05/2011 11:48 AM To Steve Cook cc "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" Subject RE: property.opposite OK. The text on implicit conversion is a change from OCL 2.0 (not sure if it came in with 2.1 or 2.2). But I like it better than having to say Set{}! (However, I think RSA is wrong in not allowing Set{} for an optional value.) -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 11:18 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite >From the OCL 2.2 spec: ... OclVoid has exactly one instance called null. ... However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). So I think null is ok. -----Original Message----- From: Steve Cook Sent: 05 August 2011 16:11 To: 'Ed Seidewitz' Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Null is required to make the constraint typecheck in RSA. If you use Set{} it complains that there is no common supertype of Set(OclVoid) and Property. I'll change the other things. -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 05 August 2011 16:10 To: Steve Cook Cc: uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: RE: property.opposite Steve -- This looks about right. I few points of detail on the OCL (Nicolas can confirm if I have these points right!): - I don't think you can use "null" in OCL. It should be "Set{}". - Instead of "not association->isEmpty()", you can more simply write "association->notEmpty()". - I don't think it is required, but I think it is clearer to write "self.assocation" instead of just "association". -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Friday, August 05, 2011 10:54 AM To: Ed Seidewitz; uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite I'm changing this in 2.5. The new derivation for opposite is this: result = if (not association->isEmpty()) and association.memberEnd->size() = 2 then association.memberEnd->any(e | e <> self) else null endif -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 01 August 2011 18:58 To: uml-spec-simplification@omg.org Cc: uml2-rtf@omg.org Subject: RE: property.opposite Well, for the purposes of UML 2.5, we have to be careful again here about "should" statements. That is why I looked at the actual uses of "opposite" within the metamodel. The question, then, is whether navigability meant to be enforced in either of these cases. And, on a second look, I would agree that enforcement of navigability is not intended in either case, the only requirement being that the association in question is a binary association. Since neither of these cases require class ownership of the ends (and, in fact, the constraint for StructuralFeatureAction specifically allows at least one of the ends to be association owned), I would agree that we need to change _both_ the definition of the opposite property _and_ the definition of the constraint. -- Ed -----Original Message----- From: Dave Hawkins [mailto:dave.hawkins@oracle.com] Sent: Monday, August 01, 2011 12:56 PM To: Pete Rivett Cc: Ed Seidewitz; Nerijus Jankevicius; uml2-rtf@omg.org; uml-spec-simplification@omg.org Subject: Re: property.opposite I agree with Pete that the opposite of a binary end should always be the other end. Dave On 01/08/11 17:33, Pete Rivett wrote: > I disagree that navigability should have anything to do with the > definition or use of 'opposite' - the 'new' (actually not so new - it > dates back to the UML 2.0 FTF) definition of navigability is a mere > hint of expectation of efficiency. > > > > I also think the OCL is incorrect - for a binary association the 2 > ends should be the opposite of each other regardless of their ownership. > > > > Pete > > > > *From:* Ed Seidewitz [mailto:ed-s@modeldriven.com] > *Sent:* Monday, August 01, 2011 7:35 AM > *To:* Nerijus Jankevicius > *Cc:* uml2-rtf@omg.org; uml-spec-simplification@omg.org > *Subject:* RE: property.opposite > > > > Nerijus - > > > > I believe this discrepancy is left over from the days when end > ownership determined navigability. In the original UML 2.0, the > description of opposite actually matched the OCL. When navigability > was separated from end ownership, the constraint OCL and description > remained valid, but the attribute description was not updated. > > > > As to which definition for opposite is really "correct", I found two > actually uses of opposite in the UML 2.4 spec, in constraint [2] of > StructuralFeatureAction and constraint [1] of Actor. Both these uses > seem to assume that opposite is based on navigability, not ownership > (indeed, the StructurealFeatureAction constraint the property whose > opposite is being obtained is specifically required /not/ to be class > owned). > > > > So, I think the description of the attribute is correct, and the > constraint and OCL is what is actually wrong. Given that this is an > inconsistency, I believe we can fix it in UML 2.5. > > > > -- Ed > > > > ---------------------------------------------------------------------- > -- > > *From:* Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > *Sent:* Monday, August 01, 2011 9:06 AM > *To:* uml2-rtf@omg.org ; > uml-spec-simplification@omg.org > > *Cc:* issues@omg.org > *Subject:* property.opposite > > > > It seems there is an issue with derived Property.opposite. > > > > Spec says: > > > > / opposite : Property [0..1] In the case where the property is one > *navigable end of a binary association with both ends navigable*, this > gives the other end. > > > > By description, it should keep reference to opposite navigable end, > but OCL works only when navigable end is owned by class. > > It does not work when navigable end is owned by association: > > > > Constraint #1: > > [1] If this *property is owned by a class* associated with a binary > association, and the *other end of the association is also owned by a > class*, then opposite gives the other end. > > opposite = *if *owningAssociation->isEmpty() *and > *association.memberEnd->size() = 2 *then let *otherEnd = > (association.memberEnd - self)->any() *in if > *otherEnd.owningAssociation->isEmpty() *then *otherEnd *else *Set{} > *endif else *Set {} *endif * > > > > > > Any comments? > > Which one is correct? Property description or constraint text? > > > > Thanks, > > > > > > * --* > > Nerijus Jankevicius > SysML Product Manager > OMG-Certified UML Professional > No Magic Europe > Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, > Kaunas > Phone: +370-37-324032 Fax: +370-37-320670 > e-mail: nerijus@magicdraw.com > WWW: http://www.magicdraw.com > -- > MagicDraw - UML made simple! > > > -- 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. Os :wq :wq :wq Os Os