Issue 6201: UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite" (uml2-rtf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: Is OCL for InfrastructureLibrary::Core::Constructs::Property::opposite() incorrect? Should it be: opposite = if owningAssociation->empty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)->any() in if otherEnd.owningAssociation->empty() then otherEnd else Set{} endif else Set {} endif Resolution: See issue 8451 for disposition Revised Text: Actions taken: September 7, 2003: received issue February 18, 2005: moved from infrastructure August 23, 2006: closed issue Discussion: End of Annotations:===== To: issues@omg.org Subject: UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Sun, 7 Sep 2003 09:17:03 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/07/2003 09:17:04, Serialize complete at 09/07/2003 09:17:04 Is OCL for InfrastructureLibrary::Core::Constructs::Property::opposite() incorrect? Should it be: opposite = if owningAssociation->empty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)->any() in if otherEnd.owningAssociation->empty() then otherEnd else Set{} endif else Set {} endif Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 Subject: RE: Ballot 7 Date: Mon, 8 Aug 2005 08:54:55 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 7 Thread-Index: AcWa5nF2SJMJR4FXSXuTCngW5XvGqgBH4mzQ From: "Pete Rivett" To: "Branislav Selic" , X-Virus-Scanned: by amavisd-new at sentraliant.com Adaptive votes YES to all the issues except 6187, 6197, 6201, 6254 to which it votes NO and 6699, to which it ABSTAINS (sorry I was traveling when the draft went round). It seems premature to close 6187 and 6197. They should either be closed when the 'pending' Abstractions happens (there is still the need to do the merge even after that) or by cloning the constraints (which I think is what Jim has suggested). 6201 has the following problems: - the property being constrained is not multivalued so it seems inappropriate to return "Set{}" - the value should be set to null. While scalar values can be treated as sets, the converse does not apply. - in "let otherEnd = (association.memberEnd - self)->any() ", the usage of any() seems incorrect since it requires a boolean condition as a 'parameter' e.g. "any(true)" Note: a separate issue is neded to replace the use of 'navigable' in the English description of 'opposite'. The English description of the constraint requires the ends to be 'owned by a class' which is not captured in the OCL - though I'm not sure if this is the real intention (e.g. would 'opposite' apply to associations between Actor and UseCase.) 6254 does raise a valid specic problem for this specific redefinition; the isConsistentWith() operation which is required for a valid redefinition requires that the lowerbound of the redefined element is >= that of the redefinition. In this particular case that does not apply since the redefining element has lowerbound of 1 and the original has lowerbound of 0. The answer is to make the multiplicity of Extension.ownedEnd [0..1] and add a constraint that Extension.ownedEnd->notEmpty(). BTW when fixing this we should also take the opportunity to make this {redefines} explicit. 6699 does not have a justification for making Constraint::namespace navigable, when most other 'owner' properties are not navigable, so I don't see a reason for changing this but not the others (which I would not be averse to). 8720, 8769 should also have an equivalent change made to Infra as an editorial action. Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 05, 2005 10:19 PM To: uml2-rtf@omg.org Subject: Ballot 7 Attached is the official ballot 7. Voting starts at 6 pm EDT today (Friday, Aug. 5) and ends in 2 weeks at 6 pm EDT on Friday, August 19. Regards, Bran To: "Pete Rivett" Cc: uml2-rtf@omg.org Subject: RE: Ballot 7 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 9 Aug 2005 15:54:22 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/09/2005 15:54:26, Serialize complete at 08/09/2005 15:54:26 Pete raised the following concerns about the resolution to issue 6201 in ballot 7: > 6201 has the following problems: > - the property being constrained is not multivalued so it seems > inappropriate to return "Set{}" - the value should be set to null. > While scalar values can be treated as sets, the converse does not apply. > - in "let otherEnd = (association.memberEnd - self)->any() ", the > usage of any() seems incorrect since it requires a boolean condition > as a 'parameter' e.g. "any(true)" > Note: a separate issue is neded to replace the use of 'navigable' in > the English description of 'opposite'. > The English description of the constraint requires the ends to be > 'owned by a class' which is not captured in the OCL - though I'm not > sure if this is the real intention (e.g. would 'opposite' apply to > associations between Actor and UseCase.) This is related to the problem I already mentioned: 8451 which was resolved in ballot 2. Therefore, resolutions 8451 and 6502 are withdrawn from ballot 7. I will reissue the ballot. Bran e-mail: bselic@ca.ibm.com