Issue 15259: Meaning of BodyCondition and its alignment with OCL (uml2-rtf) Source: International Business Machines (Dr. Maged Elaasar, melaasar(at)ca.ibm.com) Nature: Uncategorized Issue Severity: Summary: The UML superstructure allows an Operation to have: bodyCondition: Constraint[0..1] : An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule Since bodyCondition is of type Constraint, its expression must be boolean according to clause 7.3.10 (Constraint): [1] The value specification for a constraint must evaluate to a Boolean value. Now, the OCL spec states in 7.3.6 that an operation body expression has the form: context Typename::operationName(param1 : Type1, ... ): ReturnType body: -- some expression and gives an example: context Person::getCurrentSpouse() : Person pre: self.isMarried = true body: self.mariages->select( m | m.ended = false ).spouse Notice that in this example, the expression is NOT boolean, therefore if "self.mariages->select( m | m.ended = false ).spouse" was used as an expression in the bodyCondition, it would not be valid. Am I missing something? in RSA, we got around this by requiring the expression to be of the format: context Typename::operationName(param1 : Type1, ... ): ReturnType body: result = some expression Is the keyword "result" legal in the expression of bodyCondition? Resolution: Revised Text: Actions taken: May 19, 2010: received issue Discussion: End of Annotations:===== ubject: Operation body condition To: uml2-rtf@omg.org Cc: ocl2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Tue, 18 May 2010 17:59:56 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 05/18/2010 18:00:01 The UML superstructure allows an Operation to have: bodyCondition: Constraint[0..1] : An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule Since bodyCondition is of type Constraint, its expression must be boolean according to clause 7.3.10 (Constraint): [1] The value specification for a constraint must evaluate to a Boolean value. Now, the OCL spec states in 7.3.6 that an operation body expression has the form: context Typename::operationName(param1 : Type1, ... ): ReturnType body: -- some expression and gives an example: context Person::getCurrentSpouse() : Person pre: self.isMarried = true body: self.mariages->select( m | m.ended = false ).spouse Notice that in this example, the expression is NOT boolean, therefore if "self.mariages->select( m | m.ended = false ).spouse" was used as an expression in the bodyCondition, it would not be valid. Am I missing something? in RSA, we got around this by requiring the expression to be of the format: context Typename::operationName(param1 : Type1, ... ): ReturnType body: result = some expression Is the keyword "result" legal in the expression of bodyCondition? -- Maged From: "Wartik, Steven P \"Steve\"" To: "'Maged Elaasar'" , "uml2-rtf@omg.org" CC: "ocl2-rtf@omg.org" Date: Tue, 18 May 2010 18:27:58 -0400 Subject: RE: Operation body condition Thread-Topic: Operation body condition Thread-Index: Acr21dgqsWV2J9cyRUeUJCp4SgGJYwAAsJlw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US I don.t think it.s the case that an OCL body maps to bodyCondition. I haven.t found that in the OCL specifications. Please correct me if I.m wrong. Indeed, I.ve never been sure how a body is supposed to be represented in the superstructure. Can anyone shed some light? From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, May 18, 2010 6:00 PM To: uml2-rtf@omg.org Cc: ocl2-rtf@omg.org Subject: Operation body condition The UML superstructure allows an Operation to have: bodyCondition: Constraint[0..1] : An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule Since bodyCondition is of type Constraint, its expression must be boolean according to clause 7.3.10 (Constraint): [1] The value specification for a constraint must evaluate to a Boolean value. Now, the OCL spec states in 7.3.6 that an operation body expression has the form: context Typename::operationName(param1 : Type1, ... ): ReturnType body: -- some expression and gives an example: context Person::getCurrentSpouse() : Person pre: self.isMarried = true body: self.mariages->select( m | m.ended = false ).spouse Notice that in this example, the expression is NOT boolean, therefore if "self.mariages->select( m | m.ended = false ).spouse" was used as an expression in the bodyCondition, it would not be valid. Am I missing something? in RSA, we got around this by requiring the expression to be of the format: context Typename::operationName(param1 : Type1, ... ): ReturnType body: result = some expression Is the keyword "result" legal in the expression of bodyCondition? -- Maged X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYFAOYn80tUXeb0/2dsb2JhbACBPptoaHG9VIUQBA Date: Wed, 19 May 2010 07:55:47 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: "Wartik, Steven P \"Steve\"" CC: "'Maged Elaasar'" , "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" Subject: Re: Operation body condition Hi There is certainly a discrepancy, which could be worked around as you suggest by the omitted OCL mapping specifying result = ... however it is then unclear what the difference between a bodyCondition and a postCondition is. The incomplete OCL Section 12 awaits 'UML alignment' so the body to bodyCondition mapping is unclear. The status of 'result' is vague. OCL 12.7.2 indicates that it is visible in a postcondition but the specification of an environment in which it is visible is missing. The OCL specification only seems to use 'body' in the 7.3.6 example demonstrating UML equivalence, so 'body' does not appear very useful. The usage of "post: result = ..." is widespread. I think it is for UML to decide that bodyCondition has no usefully distinct semantics from postCondition, deprecate it as unnecessary bloat, and for OCL to align with that deprecation, suggesting that tools may provide backward compatibility by specifying a "result=" postcondition. Or UML might decide that bodyCondition/postCondition distinguishes mandatory/optional for code synthesis and either relax the bodyCondition type, or require the expression to be of "result=..." form. [7.3.10 [1] also specifies that the Boolean expression cannot be expressed on OCL. It can. The OCL specification in 8.3.7 BooleanLiteralExp currently uses "self.type.name = 'Boolean'", although since a TypeExp is really just a TypeLiteralExp as used in ...oclAsType(Boolean), I see no reason why "self.type = Boolean" is not valid too.] [The 7.3.10 [2] "cannot be expressed in OCL" could perhaps be resolved via allInstances@pre() = allInstances()] [The getCurrentSpouse example has at least four declaration errors and one other realisability problem when compared to Figure 7.1; fixed by Issue 12456.] Regards Ed Willink On 18/05/2010 23:27, Wartik, Steven P "Steve" wrote: I don.t think it.s the case that an OCL body maps to bodyCondition. I haven.t found that in the OCL specifications. Please correct me if I.m wrong. Indeed, I.ve never been sure how a body is supposed to be represented in the superstructure. Can anyone shed some light? From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, May 18, 2010 6:00 PM To: uml2-rtf@omg.org Cc: ocl2-rtf@omg.org Subject: Operation body condition The UML superstructure allows an Operation to have: bodyCondition: Constraint[0..1] : An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule Since bodyCondition is of type Constraint, its expression must be boolean according to clause 7.3.10 (Constraint): [1] The value specification for a constraint must evaluate to a Boolean value. Now, the OCL spec states in 7.3.6 that an operation body expression has the form: context Typename::operationName(param1 : Type1, ... ): ReturnType body: -- some expression and gives an example: context Person::getCurrentSpouse() : Person pre: self.isMarried = true body: self.mariages->select( m | m.ended = false ).spouse Notice that in this example, the expression is NOT boolean, therefore if "self.mariages->select( m | m.ended = false ).spouse" was used as an expression in the bodyCondition, it would not be valid. Am I missing something? in RSA, we got around this by requiring the expression to be of the format: context Typename::operationName(param1 : Type1, ... ): ReturnType body: result = some expression Is the keyword "result" legal in the expression of bodyCondition? -- Maged No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.819 / Virus Database: 271.1.1/2880 - Release Date: 05/17/10 19:26:00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=5KNwPcmJKvwb3MI44IuPm91MIIGoMGGCwqk9FAarX+g=; b=OgPQD0bhiSpzOoB+HvulzXqLZRvJZBCqdB907ZHBktz2SCeoGRwzA0RXzPpCTe36qQ oFRebKRJh7fbkmta1XjUu3Vts070Y3tjsLrOAc39df3wn8+toX72K5fWSq/WGhNCs6dD MSwo6IaqrDe8zi8hxvcmeW8ddn30mq4ThlCHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=diMUX50DMMyl+LW91xTAKNvLPh9XYaWDo4n4RgT/G8POaTQP42f/tKtMOVmW+NIIVf vfZIkmqmzu9WXWc6v2daoaRxSdiRQAqB4Nkzi78qvP3pY1bJO4ZnJjcmsWeH+GiPQfCV l/cPMMSvdTVhWfaSM1kIPKXZcYxSNSlG3MU+U= Sender: bran.selic@gmail.com From: Bran Selic Date: Wed, 19 May 2010 09:50:54 +0200 X-Google-Sender-Auth: AWznsdKHYdu3JDRM-DcRnSIXHLs Subject: Re: Operation body condition To: "Wartik, Steven P Steve" Cc: Maged Elaasar , "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" Correct, bodyCondition is a UML concept and not an OCL concept. Body condition was intended as a kind of overrideable post-condition (because regular post conditions cannot be redefined). I can't recall who introduced it and why, but it looks like someone had a use case where the regular post-condition constraints were too restrictive. Bran On Wed, May 19, 2010 at 12:27 AM, Wartik, Steven P "Steve" wrote: I don.t think it.s the case that an OCL body maps to bodyCondition. I haven.t found that in the OCL specifications. Please correct me if I.m wrong. Indeed, I.ve never been sure how a body is supposed to be represented in the superstructure. Can anyone shed some light? From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, May 18, 2010 6:00 PM To: uml2-rtf@omg.org Cc: ocl2-rtf@omg.org Subject: Operation body condition The UML superstructure allows an Operation to have: bodyCondition: Constraint[0..1] : An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule Since bodyCondition is of type Constraint, its expression must be boolean according to clause 7.3.10 (Constraint): [1] The value specification for a constraint must evaluate to a Boolean value. Now, the OCL spec states in 7.3.6 that an operation body expression has the form: context Typename::operationName(param1 : Type1, ... ): ReturnType body: -- some expression and gives an example: context Person::getCurrentSpouse() : Person pre: self.isMarried = true body: self.mariages->select( m | m.ended = false ).spouse Notice that in this example, the expression is NOT boolean, therefore if "self.mariages->select( m | m.ended = false ).spouse" was used as an expression in the bodyCondition, it would not be valid. Am I missing something? in RSA, we got around this by requiring the expression to be of the format: context Typename::operationName(param1 : Type1, ... ): ReturnType body: result = some expression Is the keyword "result" legal in the expression of bodyCondition? -- Maged From: Steve Cook To: "juergen@omg.org" CC: "'Maged Elaasar'" , "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" , Ed Willink , "Wartik, Steven P \"Steve\"" , "issues@omg.org" Subject: RE: Operation body condition Thread-Topic: Operation body condition Thread-Index: AQHK9tX82GsAmUwXv062xq0pvk+uvZJXtEwAgACN4oCAAHwhIA== Date: Wed, 19 May 2010 13:21:42 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Juergen Please raise an issue against UML 2 to sort out the meaning of BodyCondition and its alignment with OCL, with the emails below as summary of the issue. Cheers -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 19 May 2010 07:56 To: Wartik, Steven P "Steve" Cc: 'Maged Elaasar'; uml2-rtf@omg.org; ocl2-rtf@omg.org Subject: Re: Operation body condition Hi There is certainly a discrepancy, which could be worked around as you suggest by the omitted OCL mapping specifying result = ... however it is then unclear what the difference between a bodyCondition and a postCondition is. The incomplete OCL Section 12 awaits 'UML alignment' so the body to bodyCondition mapping is unclear. The status of 'result' is vague. OCL 12.7.2 indicates that it is visible in a postcondition but the specification of an environment in which it is visible is missing. The OCL specification only seems to use 'body' in the 7.3.6 example demonstrating UML equivalence, so 'body' does not appear very useful. The usage of "post: result = ..." is widespread. I think it is for UML to decide that bodyCondition has no usefully distinct semantics from postCondition, deprecate it as unnecessary bloat, and for OCL to align with that deprecation, suggesting that tools may provide backward compatibility by specifying a "result=" postcondition. Or UML might decide that bodyCondition/postCondition distinguishes mandatory/optional for code synthesis and either relax the bodyCondition type, or require the expression to be of "result=..." form. [7.3.10 [1] also specifies that the Boolean expression cannot be expressed on OCL. It can. The OCL specification in 8.3.7 BooleanLiteralExp currently uses "self.type.name = 'Boolean'", although since a TypeExp is really just a TypeLiteralExp as used in ...oclAsType(Boolean), I see no reason why "self.type = Boolean" is not valid too.] [The 7.3.10 [2] "cannot be expressed in OCL" could perhaps be resolved via allInstances@pre() = allInstances()] [The getCurrentSpouse example has at least four declaration errors and one other realisability problem when compared to Figure 7.1; fixed by Issue 12456.] Regards Ed Willink On 18/05/2010 23:27, Wartik, Steven P "Steve" wrote: I don.t think it.s the case that an OCL body maps to bodyCondition. I haven.t found that in the OCL specifications. Please correct me if I.m wrong. Indeed, I.ve never been sure how a body is supposed to be represented in the superstructure. Can anyone shed some light? From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, May 18, 2010 6:00 PM To: uml2-rtf@omg.org Cc: ocl2-rtf@omg.org Subject: Operation body condition The UML superstructure allows an Operation to have: bodyCondition: Constraint[0..1] : An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule Since bodyCondition is of type Constraint, its expression must be boolean according to clause 7.3.10 (Constraint): [1] The value specification for a constraint must evaluate to a Boolean value. Now, the OCL spec states in 7.3.6 that an operation body expression has the form: context Typename::operationName(param1 : Type1, ... ): ReturnType body: -- some expression and gives an example: context Person::getCurrentSpouse() : Person pre: self.isMarried = true body: self.mariages->select( m | m.ended = false ).spouse Notice that in this example, the expression is NOT boolean, therefore if "self.mariages->select( m | m.ended = false ).spouse" was used as an expression in the bodyCondition, it would not be valid. Am I missing something? in RSA, we got around this by requiring the expression to be of the format: context Typename::operationName(param1 : Type1, ... ): ReturnType body: result = some expression Is the keyword "result" legal in the expression of bodyCondition? -- Maged No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.819 / Virus Database: 271.1.1/2880 - Release Date: 05/17/10 19:26:00