Issue 15259: Meaning of BodyCondition and its alignment with OCL (uml2-rtf) Source: (Dr. Maged Elaasar, melaasar(at)gmail.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 From: Steve Cook To: Ed Seidewitz , "uml25-ftf@omg.org" Subject: Issue 15259 Thread-Topic: Issue 15259 Thread-Index: Ac535Gz1TYOQ7Ov8QRK2S1i/nAtusQ== Date: Wed, 3 Jul 2013 12:05:00 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(189002)(199002)(5403001)(377454003)(377424004)(479174003)(24454002)(63696002)(71186001)(31966008)(81542001)(16236675002)(33656001)(74876001)(512954002)(15202345003)(74366001)(19300405004)(76786001)(77096001)(44976004)(76176001)(74706001)(16601075003)(76796001)(74502001)(16406001)(76482001)(56816003)(79102001)(54356001)(6806003)(15974865002)(53806001)(4396001)(59766001)(51856001)(20776003)(47976001)(47446002)(65816001)(56776001)(77982001)(47736001)(55846006)(83072001)(49866001)(50986001)(74662001)(69226001)(46102001)(80022001)(54316002)(81342001)(579003)(559001);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB003;H:TK5EX14HUBC101.redmond.corp.microsoft.com;CLIP:131.107.125.37;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0896BFCE6C X-Virus-Scanned: amavisd-new at omg.org I am revisiting issue 15259, which concerns body conditions (see the email trail below). I did some experiments with adding result= to the beginning of body conditions. Unfortunately when I do this for some of them . in fact those whose operation.s return type is Boolean . I get an error. For example, Classifier::conformsTo() : Boolean, when the body condition is defined as result = (self = other or allParents()->includes(other)) Gives the somewhat surprising error: Parsing Error: Body condition must have the for .result = . on operation .conformsTo.. Given this, rather than changing all of the bodyConditions so that all the Boolean ones give a parsing error, I feel inclined to explain in the front matter that all of the body conditions are typed with the result of the operation, and are thus strictly-speaking invalid. Any better suggestions welcomed! -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 08 November 2012 17:09 To: uml25-ftf@omg.org Subject: RE: Report on today's call I think a simple solution here is the best solution, .brute force. or otherwise. Any solution that needs to be .very clearly explained in the UML spec. is likely, in my opinion, to never be explained quite clearly enough to avoid confusion in the future. I still think we should proceed pretty much as Steve originally proposed: · Add .result=. to the beginning of all the OCL expressions for bodyConditions in RSA. The problem, I guess, is that .result. is a reserved word in OCL, so to refer to the operation return parameter would require some notation like ._.result.., which is awkward. However, since the reserved work .result. means the operation result, I think we can still use it in an OCL expression, even though this expression is used for a UML bodyCondition, not a UML preCondition or postCondition. · Allow this to be generated as .body: result=.. in the specification document text. · Explain in 6.4 that that .body:. simply introduces a UML bodyCondition for the operation and that it is not OCL syntax. There is no requirement that we use OCL syntax here, since operations and their bodyConditions are represented in the metamodel as UML, not OCL. Only the expression itself needs to conform to OCL syntax. I would suggest that any further issues of UML and OCL alignment should then be taken up in revisions of the OCL spec, not as part of the UML 2.5 FTF. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Thursday, November 08, 2012 6:37 AM To: uml25-ftf@omg.org Subject: Re: Report on today's call Hi Steve, Yes, although 'valid' is not a word that can always be used with precision in regards to the OCL specification. Since the OCL specification is still looking forwards to aligning with UML 2.0, the OCL specification can be clarified. My earlier long response was explaining how both "body result: result = value" and "body: result = value" and "body: value" could become equivalent and valid in 'OCL 2.5'. The full explanation of the UML bodyCondition / OCL bodyExpression mapping belongs in the OCL specification. My one sentence adjustment to 6.4.1 is just a summary. Editorially, the UML specification could easily state that "body:" was just an exposition aid rather than a Complete OCL declaration. But this is an irrelevance to the fundamental issue is that the UML.xmi must contain a Boolean-valued bodyCondition. Regards Ed Willink On 08/11/2012 11:11, Steve Cook wrote: Ed W As I understand it, you are pointing out that the .brute force. solution would result in fragments in the UML spec such as this: realValue() : Real body: result = value Which is not valid OCL because the .body:. syntax is defined by OCL to be a bodyExpression, which has to be typed (in this case) as Real. You are therefore proposing instead that the XMI generation prepends the .result = ., in order to convert body expressions to body conditions in the XMI generation process. Something of the kind is necessary because OCL does not define any syntax for bodyConditions, in the sense used by UML. This process would need to be very clearly explained in the UML spec. Have I understood? -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 08 November 2012 10:50 To: uml25-ftf@omg.org Subject: Re: Report on today's call Hi Ed I'm trying to future-proof the UML 2.5 specification against the 'OCL 2.5' specification with a solution for the problem that "body: result = ..." is not currently 'standard' OCL. Perhaps my sleight of hand and the limited impact on the proposed UML 2.5 text caused you to miss the significance. The solution must accommodate the immovable obstacles: - the behavior of an Operation is specified by a bodyCondition that is a Constraint - all Constraints are Boolean-valued the corollary that - the bodyCondition text in UML.xmi must be Boolean-valued OCL; i.e. "result = ..." and the pragmatics of using IBM RSA - the bodyCondition text is propagated unchanged from the RSA constraint editor field Simple Brute Force Solution Prefix all UML 2.5 Beta 1 bodyCondition texts by "result = " - the additional "result = " then appears in every exposition of a bodyCondition in the UML text. Modify the overview paragraph in 6.4.1 page 8 from: Operations: each specified by its signature, a textual description of the logic of the operation, and a specification of the logic of the operation in OCL. Note that in some cases the OCL is absent. to Operations: each specified by its signature, a textual description of the logic of the operation, and a bodyCondition to specify the logic of the operation in OCL. The mapping from the result-valued OCL bodyExpression to the Boolean-valued UML bodyCondition is expressed explicitly by a comparison of the result parameter with the bodyExpression . Note that in some cases the OCL is absent. Smarter Solution Arrange for the XMI producer to add the "result = " prefix to all the bodyConditions. - the UML text is unchanged, the RSA source is unchanged. Modify the overview paragraph in 6.4.1 page 8 from: Operations: each specified by its signature, a textual description of the logic of the operation, and a specification of the logic of the operation in OCL. Note that in some cases the OCL is absent. to Operations: each specified by its signature, a textual description of the logic of the operation, and a result-valued bodyExpression to specify the logic of the operation in OCL. The Boolean-valued UML bodyCondition may be determined from the OCL bodyExpression by wrapping the bodyExpression in a comparison with the result parameter. Note that in some cases the OCL is absent. ================================ Either way, the OCL specification and OCL tooling must evolve to eliminate the use of non-Boolean-valued bodyConditions. Regards Ed Willink On 07/11/2012 18:34, Ed Seidewitz wrote: Ed . Sorry, but I am losing track of the relevance of your comments to the issue at hand. Multi-returns are not at issue. OCL semantics is not at issue. We are talking about a UML construction (bodyConstraint) with the UML syntax of a Constraint whose specification is a UML ValueSpecification. The only reason OCL is involved is that the ValueSpecification happens to be a UML OpaqueExpression whose body is written in OCL. And this body is just an OCL Boolean expression, not a condition declaration or any other OCL construct. The name of the return parameters of the operation in question is .result., so an expression of the form .result=.. is just an OCL expression that says this return parameter must equal whatever the expression on the right-hand side of the .=. evaluates to. There is no special syntax here. Done deal, it seems to me. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Wednesday, November 07, 2012 3:11 AM To: Ed Seidewitz Cc: uml25-ftf@omg.org Subject: Re: Report on today's call Hi I was concentrating too much on the 'Constraint'. Yes the overriding semantics justifies the separate naming, and anything that is a Constraint is Boolean-valued. For multi-returns, the [0..1] multiplicity on body-condition is unhelpful; each return may benefit from a distinct body-condition rather to avoid an AND of multiple sub-bodyConditions. ?? A separate issue, but see solution below. ----- What does the OCL specification actually say normatively? In OCL 12.10 "The placement of an operation body expression is dependent upon the [forthcoming] UML 2.0 metamodel.". Nothing. The diagram showing the relationship of an OCL result-typed body-expression and a UML body-condition is missing, so any relationship is a proprietary attempt to make sense of the omission. There is no contradiction if UML uses a concrete syntax exposition such as "result = xyzzy" However in OCL 12.12.9, the Complete OCL syntax is "prePostOrBodyDeclCS[1] ::= .body. (simpleNameCS)? .:. OclExpressionCS prePostOrBodyDeclCS[2]?" so in Complete OCL, "body: xyzzy" is the normative way to specify a body-expression. The UML 2.5 exposition omits the redundant "context ..." declarations, so it is not necessary that the UML exposition is a syntactically valid Complete OCL prePostOrBodyDeclCS. An editorial statement that "body: result = xyzzy" is a body-condition comprising a "body:" introducer followed by the OCL for the bodyCondition eliminates the possible contradiction. What is the OCL custom and practice? Warmer and Kleppe, in OCL Getting your models ready for MDA, clearly use the "body: body-expression" syntax, so there is independent agreement with Eclipse OCL usage. ----- A possible OCL solution: The Complete OCL syntax for a body expression has an optional name. I assume that is just there for syntactic symmetry; I have never seen it used. It can be exploited to solve the multiple outputs and bridge the body-expression to body-condition gap. 1) Let Complete OCL semantics define "body X: ..." as the typeof-X-valued body-expression for the return/out/inout parameter named X. "body: ..." is a shortform for "body result: ..." The UML body-condition is then formed from the OCL body-expressions as a conjunction of comparisons. "(result = res) and (A = a) and (B = b)" is therefore the UIML-body-condition encoding of the the OCL body-expressions for an operation with a result, an out parameter A and an inout parameter B body: res body A: a body B: b This would just require an editorial clarification in the UML specification that the exposition of the body-expression as "body: res" is a shortform for the body-condition "result = res". But it would not support maintenance of the UML 2.5 meta-model with today's tools; the UML 2.5 OCL would be missing all the "result=" terms from the body-expression to body-condition encoding. Therefore: ---- 2) Let Complete OCL semantics further define "body X: ...", where "..." does not use "X", as a shortform for "body X: X=(...)". This then allows the UML 2.5 meta-model to be maintained by existing tools provided the "result=" is added manually to every body-condition (Use a text editor on the XML). The OCL in the UML 2.5 meta-model should be parseable by today's tooling but will only be executable by tooling that understands the body-expression/body-condition encoding. The OCL exposition in the UML 2.5 specification need not change, provided the auto-generator strips the redundant "result=" while formatting the OCL from the UML metamodel. The UML 2.5 specification could impose a constraint on the body-condition as a conjunction of output-name comparisons, but this is a useful simplification for OCL tooling rather than a necessary characteristic of the specification. Regards Ed Willink On 06/11/2012 21:43, Ed Seidewitz wrote: Ed . An Operation::bodyCondition is a Constraint. The .boolean_value. constraint on Constraint says .The ValueSpecification for a Constraint must evaluate to a Boolean value.. For the Constraints in question, the ValueSpecification is an OpaqueExpression whose body is an OCL expression, which must therefore evaluate to a Boolean value. The difference between a preCondition and a bodyCondition is given in 9.6.3: .The bodyCondition for an Operation constrains the return result. The bodyCondition differs from postconditions in that the bodyCondition may be overridden when an Operation is redefined, whereas postconditions may only be added during redefinition.. This ability to override is actually important in the way operations are used in the UML abstract syntax metamodel. Perhaps it would have been better to have defined a bodyExpression rather than a Boolean bodyCondition. But don.t think that is not something that is going to change at this point. There is no clash with OCL semantics, since bodyCondition is a UML syntactic construct, not something usable just with OCL. As Steve has said, the real issue is really that OCL attempted some tighter integration with UML, but didn.t specify it entirely properly (even though it has gotten a bit better in later versions). In any case, the update that Steve is proposing seems to be a perfectly acceptable way to make all the bodyConditions into correct Boolean expressions meaning exactly what we want. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Tuesday, November 06, 2012 3:46 PM To: uml25-ftf@omg.org Subject: Re: Report on today's call Hi Steve It's not clear to me that 12-10-24 requires the Body Condition to have a Boolean value. I see: "An optional Constraint on the result values of an invocation of this Operation." and "The bodyCondition for an Operation constrains the return result." [As a formal "Constraint" the value should be Boolean, but as an informal "constraint" it only provides a mechanism to validate a characteristic.] If you want a Boolean condition then bodyCondition is redundant. You might as well just use a post-condition for which 'result = ...' would be correct. It would appear that the OCL 2.0 authors recognised the confusing 'Body Condition' wording and so chose to use 'Body Expression'. For UML 2.5, I see the following choices a) reword BodyCondition to specify Boolean-valued => requires insertion of 'result =' in all body constraints => requires an explanation as to why bodycondition is indistiguishable from a postcondition => obscures the computable body with an idiomatic redundant comparison => introduces a head-on clash with OCL semantics => requires 'result' to be visible in more than post conditions. b) clarify BodyCondition as being result-valued => noting that BodyCondition is referred to as a body expression in OCL c) clarify BodyCondition by renaming to BodyExpression => a meta-model change Both a) and c) seem really bad choices to me. Regards Ed Willink On 06/11/2012 19:54, Steve Cook wrote: Ed In the UML metamodel, in all of the operations, by convention, .result. is the name of the single return parameter. So writing .result = x. in the bodyCondition is a (Boolean) constraint on the value of this parameter. There is certainly a misalignment between OCL and UML, which is that OCL (in section 7.4.6 of version 2.3.1) defines something called a .body expression., which does not appear in UML at all. In this definition it says .The expression must conform to the result type of the operation.. If this maps to anything in UML I guess it would be an OpaqueBehavior whose specification is the Operation. 12.10 of OCL 2.3 purports to explain this but fails. Indeed, the whole of section 12 is deeply unsatisfactory. It is supposed to explain how OCL expressions appear within UML models, but since it appears to ignore what the UML metamodel actually is, no UML tool can sensibly implement what it says. In UML, the bodyCondition of an Operation is a Constraint, and Constraint is constrained to have a Boolean value. The issue at hand is that UML is defined in UML, and if it is to satisfy its own well-formedness constraints, every Constraint and hence every bodyCondition must have a Boolean value. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 06 November 2012 18:27 To: uml25-ftf@omg.org Subject: Re: Report on today's call Hi 4. Steve raised issue 15259: meaning of bodyCondition, and pointed out that all of the bodyConditions currently in the metamodel are invalidly-typed according to the UML spec which requires them to have a Boolean value. Currently they all evaluate as expressions giving the value of the result. The fix appears to be to prepend .result = . to all of these expressions in the spec. This was done in 2.4 but for various reasons got lost in the OCL sort-out for UML 2.5 I'm not clear quite what the problem is, but the solution definitely seems wrong. "result" is only defined and useable in post-condition constraints, where post: result = ... verifies that a comparison of the result with a required value is as intended. Historically there was a misunderstanding that body: result = ... was a way of assigning to the result. It isn't. ---- In the event that multiple return/outs/inouts are required, there is a UML/OCL misalignment; OCL operations only supports a single return for any number of inputs. A sensible solution is that multiple results are returned as a Tuple in which the part names and types emulate the return/out/inout parameter names and types. Regards Ed Willink No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5875 - Release Date: 11/05/12 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5877 - Release Date: 11/06/12 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5877 - Release Date: 11/06/12 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5878 - Release Date: 11/06/12 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=MudrtQqe c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=AeFP_lyPgAIA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=yMhMjlubAAAA:8 a=7OUVe7TeAAAA:8 a=KHpXyVWLAAAA:8 a=oCcaPWc0AAAA:8 a=EYBrC1902dwEmxLUvZEA:9 a=bF2WUcAqBzCECXgr:21 a=P22-kg0SVtKVkr8Y:21 a=jsPnpAFswwD8Dgsd:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=y1fuBQt2dhcA:10 a=WP4_USCxRkkA:10 Date: Wed, 03 Jul 2013 14:35:09 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: "uml25-ftf@omg.org" Subject: Re: Issue 15259 X-Virus-Scanned: amavisd-new at omg.org Hi Steve This appears to be only half of what I suggested as the "Smarter solution". Whether "result = " appears in the UML specification text is cosmetic and can be covered by front matter. What appears in the XMI serialization of the UML metamodel is not cosmetic. "result = (...)" must be wrapped by the XMI emitter (unless UML makes a major metamodel change from bodyCondition to bodyExpression). [I think there is a typo in your message. Since 2007, Eclipse OCL has had a message Body condition must have the form "result = " on operation "{0}" This comes from four control paths and so is not that diagnostic. Checking through a JUnit test that validates result = (if true then 'red' else 'brown' endif) the most likely failure is due to schizophrenic Booleans. RSA is probably not using the UML 2.4.1 compliant version of Eclipse MDT/UML2 and so does not understand the separated PrimitiveTypes package. So the error message is erroneously reporting that the internal Boolean-valued result is not compatible with the outer Boolean requirement.] Regards Ed Willink On 03/07/2013 13:05, Steve Cook wrote: I am revisiting issue 15259, which concerns body conditions (see the email trail below). I did some experiments with adding result= to the beginning of body conditions. Unfortunately when I do this for some of them . in fact those whose operation.s return type is Boolean . I get an error. For example, Classifier::conformsTo() : Boolean, when the body condition is defined as result = (self = other or allParents()->includes(other)) Gives the somewhat surprising error: Parsing Error: Body condition must have the for .result = . on operation .conformsTo.. Given this, rather than changing all of the bodyConditions so that all the Boolean ones give a parsing error, I feel inclined to explain in the front matter that all of the body conditions are typed with the result of the operation, and are thus strictly-speaking invalid. Any better suggestions welcomed! -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 08 November 2012 17:09 To: uml25-ftf@omg.org Subject: RE: Report on today's call I think a simple solution here is the best solution, .brute force. or otherwise. Any solution that needs to be .very clearly explained in the UML spec. is likely, in my opinion, to never be explained quite clearly enough to avoid confusion in the future. I still think we should proceed pretty much as Steve originally proposed: · Add .result=. to the beginning of all the OCL expressions for bodyConditions in RSA. The problem, I guess, is that .result. is a reserved word in OCL, so to refer to the operation return parameter would require some notation like ._.result.., which is awkward. However, since the reserved work .result. means the operation result, I think we can still use it in an OCL expression, even though this expression is used for a UML bodyCondition, not a UML preCondition or postCondition. · Allow this to be generated as .body: result=.. in the specification document text. · Explain in 6.4 that that .body:. simply introduces a UML bodyCondition for the operation and that it is not OCL syntax. There is no requirement that we use OCL syntax here, since operations and their bodyConditions are represented in the metamodel as UML, not OCL. Only the expression itself needs to conform to OCL syntax. I would suggest that any further issues of UML and OCL alignment should then be taken up in revisions of the OCL spec, not as part of the UML 2.5 FTF. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Thursday, November 08, 2012 6:37 AM To: uml25-ftf@omg.org Subject: Re: Report on today's call Hi Steve, Yes, although 'valid' is not a word that can always be used with precision in regards to the OCL specification. Since the OCL specification is still looking forwards to aligning with UML 2.0, the OCL specification can be clarified. My earlier long response was explaining how both "body result: result = value" and "body: result = value" and "body: value" could become equivalent and valid in 'OCL 2.5'. The full explanation of the UML bodyCondition / OCL bodyExpression mapping belongs in the OCL specification. My one sentence adjustment to 6.4.1 is just a summary. Editorially, the UML specification could easily state that "body:" was just an exposition aid rather than a Complete OCL declaration. But this is an irrelevance to the fundamental issue is that the UML.xmi must contain a Boolean-valued bodyCondition. Regards Ed Willink On 08/11/2012 11:11, Steve Cook wrote: Ed W As I understand it, you are pointing out that the .brute force. solution would result in fragments in the UML spec such as this: realValue() : Real body: result = value Which is not valid OCL because the .body:. syntax is defined by OCL to be a bodyExpression, which has to be typed (in this case) as Real. You are therefore proposing instead that the XMI generation prepends the .result = ., in order to convert body expressions to body conditions in the XMI generation process. Something of the kind is necessary because OCL does not define any syntax for bodyConditions, in the sense used by UML. This process would need to be very clearly explained in the UML spec. Have I understood? -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 08 November 2012 10:50 To: uml25-ftf@omg.org Subject: Re: Report on today's call Hi Ed I'm trying to future-proof the UML 2.5 specification against the 'OCL 2.5' specification with a solution for the problem that "body: result = ..." is not currently 'standard' OCL. Perhaps my sleight of hand and the limited impact on the proposed UML 2.5 text caused you to miss the significance. The solution must accommodate the immovable obstacles: - the behavior of an Operation is specified by a bodyCondition that is a Constraint - all Constraints are Boolean-valued the corollary that - the bodyCondition text in UML.xmi must be Boolean-valued OCL; i.e. "result = ..." and the pragmatics of using IBM RSA - the bodyCondition text is propagated unchanged from the RSA constraint editor field Simple Brute Force Solution Prefix all UML 2.5 Beta 1 bodyCondition texts by "result = " - the additional "result = " then appears in every exposition of a bodyCondition in the UML text. Modify the overview paragraph in 6.4.1 page 8 from: Operations: each specified by its signature, a textual description of the logic of the operation, and a specification of the logic of the operation in OCL. Note that in some cases the OCL is absent. to Operations: each specified by its signature, a textual description of the logic of the operation, and a bodyCondition to specify the logic of the operation in OCL. The mapping from the result-valued OCL bodyExpression to the Boolean-valued UML bodyCondition is expressed explicitly by a comparison of the result parameter with the bodyExpression . Note that in some cases the OCL is absent. Smarter Solution Arrange for the XMI producer to add the "result = " prefix to all the bodyConditions. - the UML text is unchanged, the RSA source is unchanged. Modify the overview paragraph in 6.4.1 page 8 from: Operations: each specified by its signature, a textual description of the logic of the operation, and a specification of the logic of the operation in OCL. Note that in some cases the OCL is absent. to Operations: each specified by its signature, a textual description of the logic of the operation, and a result-valued bodyExpression to specify the logic of the operation in OCL. The Boolean-valued UML bodyCondition may be determined from the OCL bodyExpression by wrapping the bodyExpression in a comparison with the result parameter. Note that in some cases the OCL is absent. ================================ Either way, the OCL specification and OCL tooling must evolve to eliminate the use of non-Boolean-valued bodyConditions. Regards Ed Willink On 07/11/2012 18:34, Ed Seidewitz wrote: Ed . Sorry, but I am losing track of the relevance of your comments to the issue at hand. Multi-returns are not at issue. OCL semantics is not at issue. We are talking about a UML construction (bodyConstraint) with the UML syntax of a Constraint whose specification is a UML ValueSpecification. The only reason OCL is involved is that the ValueSpecification happens to be a UML OpaqueExpression whose body is written in OCL. And this body is just an OCL Boolean expression, not a condition declaration or any other OCL construct. The name of the return parameters of the operation in question is .result., so an expression of the form .result=.. is just an OCL expression that says this return parameter must equal whatever the expression on the right-hand side of the .=. evaluates to. There is no special syntax here. Done deal, it seems to me. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Wednesday, November 07, 2012 3:11 AM To: Ed Seidewitz Cc: uml25-ftf@omg.org Subject: Re: Report on today's call Hi I was concentrating too much on the 'Constraint'. Yes the overriding semantics justifies the separate naming, and anything that is a Constraint is Boolean-valued. For multi-returns, the [0..1] multiplicity on body-condition is unhelpful; each return may benefit from a distinct body-condition rather to avoid an AND of multiple sub-bodyConditions. ?? A separate issue, but see solution below. ----- What does the OCL specification actually say normatively? In OCL 12.10 "The placement of an operation body expression is dependent upon the [forthcoming] UML 2.0 metamodel.". Nothing. The diagram showing the relationship of an OCL result-typed body-expression and a UML body-condition is missing, so any relationship is a proprietary attempt to make sense of the omission. There is no contradiction if UML uses a concrete syntax exposition such as "result = xyzzy" However in OCL 12.12.9, the Complete OCL syntax is "prePostOrBodyDeclCS[1] ::= .body. (simpleNameCS)? .:. OclExpressionCS prePostOrBodyDeclCS[2]?" so in Complete OCL, "body: xyzzy" is the normative way to specify a body-expression. The UML 2.5 exposition omits the redundant "context ..." declarations, so it is not necessary that the UML exposition is a syntactically valid Complete OCL prePostOrBodyDeclCS. An editorial statement that "body: result = xyzzy" is a body-condition comprising a "body:" introducer followed by the OCL for the bodyCondition eliminates the possible contradiction. What is the OCL custom and practice? Warmer and Kleppe, in OCL Getting your models ready for MDA, clearly use the "body: body-expression" syntax, so there is independent agreement with Eclipse OCL usage. ----- A possible OCL solution: The Complete OCL syntax for a body expression has an optional name. I assume that is just there for syntactic symmetry; I have never seen it used. It can be exploited to solve the multiple outputs and bridge the body-expression to body-condition gap. 1) Let Complete OCL semantics define "body X: ..." as the typeof-X-valued body-expression for the return/out/inout parameter named X. "body: ..." is a shortform for "body result: ..." The UML body-condition is then formed from the OCL body-expressions as a conjunction of comparisons. "(result = res) and (A = a) and (B = b)" is therefore the UIML-body-condition encoding of the the OCL body-expressions for an operation with a result, an out parameter A and an inout parameter B body: res body A: a body B: b This would just require an editorial clarification in the UML specification that the exposition of the body-expression as "body: res" is a shortform for the body-condition "result = res". But it would not support maintenance of the UML 2.5 meta-model with today's tools; the UML 2.5 OCL would be missing all the "result=" terms from the body-expression to body-condition encoding. Therefore: ---- 2) Let Complete OCL semantics further define "body X: ...", where "..." does not use "X", as a shortform for "body X: X=(...)". This then allows the UML 2.5 meta-model to be maintained by existing tools provided the "result=" is added manually to every body-condition (Use a text editor on the XML). The OCL in the UML 2.5 meta-model should be parseable by today's tooling but will only be executable by tooling that understands the body-expression/body-condition encoding. The OCL exposition in the UML 2.5 specification need not change, provided the auto-generator strips the redundant "result=" while formatting the OCL from the UML metamodel. The UML 2.5 specification could impose a constraint on the body-condition as a conjunction of output-name comparisons, but this is a useful simplification for OCL tooling rather than a necessary characteristic of the specification. Regards Ed Willink On 06/11/2012 21:43, Ed Seidewitz wrote: Ed . An Operation::bodyCondition is a Constraint. The .boolean_value. constraint on Constraint says .The ValueSpecification for a Constraint must evaluate to a Boolean value.. For the Constraints in question, the ValueSpecification is an OpaqueExpression whose body is an OCL expression, which must therefore evaluate to a Boolean value. The difference between a preCondition and a bodyCondition is given in 9.6.3: .The bodyCondition for an Operation constrains the return result. The bodyCondition differs from postconditions in that the bodyCondition may be overridden when an Operation is redefined, whereas postconditions may only be added during redefinition.. This ability to override is actually important in the way operations are used in the UML abstract syntax metamodel. Perhaps it would have been better to have defined a bodyExpression rather than a Boolean bodyCondition. But don.t think that is not something that is going to change at this point. There is no clash with OCL semantics, since bodyCondition is a UML syntactic construct, not something usable just with OCL. As Steve has said, the real issue is really that OCL attempted some tighter integration with UML, but didn.t specify it entirely properly (even though it has gotten a bit better in later versions). In any case, the update that Steve is proposing seems to be a perfectly acceptable way to make all the bodyConditions into correct Boolean expressions meaning exactly what we want. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Tuesday, November 06, 2012 3:46 PM To: uml25-ftf@omg.org Subject: Re: Report on today's call Hi Steve It's not clear to me that 12-10-24 requires the Body Condition to have a Boolean value. I see: "An optional Constraint on the result values of an invocation of this Operation." and "The bodyCondition for an Operation constrains the return result." [As a formal "Constraint" the value should be Boolean, but as an informal "constraint" it only provides a mechanism to validate a characteristic.] If you want a Boolean condition then bodyCondition is redundant. You might as well just use a post-condition for which 'result = ...' would be correct. It would appear that the OCL 2.0 authors recognised the confusing 'Body Condition' wording and so chose to use 'Body Expression'. For UML 2.5, I see the following choices a) reword BodyCondition to specify Boolean-valued => requires insertion of 'result =' in all body constraints => requires an explanation as to why bodycondition is indistiguishable from a postcondition => obscures the computable body with an idiomatic redundant comparison => introduces a head-on clash with OCL semantics => requires 'result' to be visible in more than post conditions. b) clarify BodyCondition as being result-valued => noting that BodyCondition is referred to as a body expression in OCL c) clarify BodyCondition by renaming to BodyExpression => a meta-model change Both a) and c) seem really bad choices to me. Regards Ed Willink On 06/11/2012 19:54, Steve Cook wrote: Ed In the UML metamodel, in all of the operations, by convention, .result. is the name of the single return parameter. So writing .result = x. in the bodyCondition is a (Boolean) constraint on the value of this parameter. There is certainly a misalignment between OCL and UML, which is that OCL (in section 7.4.6 of version 2.3.1) defines something called a .body expression., which does not appear in UML at all. In this definition it says .The expression must conform to the result type of the operation.. If this maps to anything in UML I guess it would be an OpaqueBehavior whose specification is the Operation. 12.10 of OCL 2.3 purports to explain this but fails. Indeed, the whole of section 12 is deeply unsatisfactory. It is supposed to explain how OCL expressions appear within UML models, but since it appears to ignore what the UML metamodel actually is, no UML tool can sensibly implement what it says. In UML, the bodyCondition of an Operation is a Constraint, and Constraint is constrained to have a Boolean value. The issue at hand is that UML is defined in UML, and if it is to satisfy its own well-formedness constraints, every Constraint and hence every bodyCondition must have a Boolean value. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 06 November 2012 18:27 To: uml25-ftf@omg.org Subject: Re: Report on today's call Hi 4. Steve raised issue 15259: meaning of bodyCondition, and pointed out that all of the bodyConditions currently in the metamodel are invalidly-typed according to the UML spec which requires them to have a Boolean value. Currently they all evaluate as expressions giving the value of the result. The fix appears to be to prepend .result = . to all of these expressions in the spec. This was done in 2.4 but for various reasons got lost in the OCL sort-out for UML 2.5 I'm not clear quite what the problem is, but the solution definitely seems wrong. "result" is only defined and useable in post-condition constraints, where post: result = ... verifies that a comparison of the result with a required value is as intended. Historically there was a misunderstanding that body: result = ... was a way of assigning to the result. It isn't. ---- In the event that multiple return/outs/inouts are required, there is a UML/OCL misalignment; OCL operations only supports a single return for any number of inputs. A sensible solution is that multiple results are returned as a Tuple in which the part names and types emulate the return/out/inout parameter names and types. Regards Ed Willink No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5875 - Release Date: 11/05/12 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5877 - Release Date: 11/06/12 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5877 - Release Date: 11/06/12 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5878 - Release Date: 11/06/12 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3204/6458 - Release Date: 07/02/13 From: Steve Cook To: Ed Willink , "uml25-ftf@omg.org" Subject: RE: Issue 15259 Thread-Topic: Issue 15259 Thread-Index: Ac535Gz1TYOQ7Ov8QRK2S1i/nAtusQADbXaAAABko0A= Date: Wed, 3 Jul 2013 13:54:57 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.104] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(377454003)(377424004)(479174003)(24454002)(189002)(5403001)(199002)(56776001)(65816001)(47446002)(77982001)(59766001)(4396001)(51856001)(20776003)(47976001)(74662001)(69226001)(81342001)(46102001)(54316002)(80022001)(83072001)(50986001)(55846006)(47736001)(49866001)(81542001)(33656001)(16236675002)(31966008)(71186001)(15202345003)(74876001)(512954002)(63696002)(76482001)(54356001)(56816003)(79102001)(74366001)(53806001)(6806003)(15974865002)(44976004)(77096001)(19300405004)(76786001)(16406001)(76796001)(74502001)(74706001)(16601075003)(559001)(579003);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB004;H:TK5EX14MLTC104.redmond.corp.microsoft.com;CLIP:131.107.125.37;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0896BFCE6C X-Virus-Scanned: amavisd-new at omg.org Yes, there is a typo in the message I quoted. RSA does not allow that message to be copied so I did it by hand. I think you are right that the problem is the different Booleans. Getting the XMI transformation to insert the .result=(.). would be possible, but that would be dependent on Nicolas.s private tool chain. A topic for one of our calls, I think. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 03 July 2013 14:35 To: uml25-ftf@omg.org Subject: Re: Issue 15259 Hi Steve This appears to be only half of what I suggested as the "Smarter solution". Whether "result = " appears in the UML specification text is cosmetic and can be covered by front matter. What appears in the XMI serialization of the UML metamodel is not cosmetic. "result = (...)" must be wrapped by the XMI emitter (unless UML makes a major metamodel change from bodyCondition to bodyExpression). [I think there is a typo in your message. Since 2007, Eclipse OCL has had a message Body condition must have the form "result = " on operation "{0}" This comes from four control paths and so is not that diagnostic. Checking through a JUnit test that validates result = (if true then 'red' else 'brown' endif) the most likely failure is due to schizophrenic Booleans. RSA is probably not using the UML 2.4.1 compliant version of Eclipse MDT/UML2 and so does not understand the separated PrimitiveTypes package. So the error message is erroneously reporting that the internal Boolean-valued result is not compatible with the outer Boolean requirement.] Regards Ed Willink On 03/07/2013 13:05, Steve Cook wrote: I am revisiting issue 15259, which concerns body conditions (see the email trail below). I did some experiments with adding result= to the beginning of body conditions. Unfortunately when I do this for some of them . in fact those whose operation.s return type is Boolean . I get an error. For example, Classifier::conformsTo() : Boolean, when the body condition is defined as result = (self = other or allParents()->includes(other)) Gives the somewhat surprising error: Parsing Error: Body condition must have the for .result = . on operation .conformsTo.. Given this, rather than changing all of the bodyConditions so that all the Boolean ones give a parsing error, I feel inclined to explain in the front matter that all of the body conditions are typed with the result of the operation, and are thus strictly-speaking invalid. Any better suggestions welcomed! -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 08 November 2012 17:09 To: uml25-ftf@omg.org Subject: RE: Report on today's call I think a simple solution here is the best solution, .brute force. or otherwise. Any solution that needs to be .very clearly explained in the UML spec. is likely, in my opinion, to never be explained quite clearly enough to avoid confusion in the future. I still think we should proceed pretty much as Steve originally proposed: · Add .result=. to the beginning of all the OCL expressions for bodyConditions in RSA. The problem, I guess, is that .result. is a reserved word in OCL, so to refer to the operation return parameter would require some notation like ._.result.., which is awkward. However, since the reserved work .result. means the operation result, I think we can still use it in an OCL expression, even though this expression is used for a UML bodyCondition, not a UML preCondition or postCondition. · Allow this to be generated as .body: result=.. in the specification document text. · Explain in 6.4 that that .body:. simply introduces a UML bodyCondition for the operation and that it is not OCL syntax. There is no requirement that we use OCL syntax here, since operations and their bodyConditions are represented in the metamodel as UML, not OCL. Only the expression itself needs to conform to OCL syntax. I would suggest that any further issues of UML and OCL alignment should then be taken up in revisions of the OCL spec, not as part of the UML 2.5 FTF. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Thursday, November 08, 2012 6:37 AM To: uml25-ftf@omg.org Subject: Re: Report on today's call Hi Steve, Yes, although 'valid' is not a word that can always be used with precision in regards to the OCL specification. Since the OCL specification is still looking forwards to aligning with UML 2.0, the OCL specification can be clarified. My earlier long response was explaining how both "body result: result = value" and "body: result = value" and "body: value" could become equivalent and valid in 'OCL 2.5'. The full explanation of the UML bodyCondition / OCL bodyExpression mapping belongs in the OCL specification. My one sentence adjustment to 6.4.1 is just a summary. Editorially, the UML specification could easily state that "body:" was just an exposition aid rather than a Complete OCL declaration. But this is an irrelevance to the fundamental issue is that the UML.xmi must contain a Boolean-valued bodyCondition. Regards Ed Willink On 08/11/2012 11:11, Steve Cook wrote: Ed W As I understand it, you are pointing out that the .brute force. solution would result in fragments in the UML spec such as this: realValue() : Real body: result = value Which is not valid OCL because the .body:. syntax is defined by OCL to be a bodyExpression, which has to be typed (in this case) as Real. You are therefore proposing instead that the XMI generation prepends the .result = ., in order to convert body expressions to body conditions in the XMI generation process. Something of the kind is necessary because OCL does not define any syntax for bodyConditions, in the sense used by UML. This process would need to be very clearly explained in the UML spec. Have I understood? -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 08 November 2012 10:50 To: uml25-ftf@omg.org Subject: Re: Report on today's call Hi Ed I'm trying to future-proof the UML 2.5 specification against the 'OCL 2.5' specification with a solution for the problem that "body: result = ..." is not currently 'standard' OCL. Perhaps my sleight of hand and the limited impact on the proposed UML 2.5 text caused you to miss the significance. The solution must accommodate the immovable obstacles: - the behavior of an Operation is specified by a bodyCondition that is a Constraint - all Constraints are Boolean-valued the corollary that - the bodyCondition text in UML.xmi must be Boolean-valued OCL; i.e. "result = ..." and the pragmatics of using IBM RSA - the bodyCondition text is propagated unchanged from the RSA constraint editor field Simple Brute Force Solution Prefix all UML 2.5 Beta 1 bodyCondition texts by "result = " - the additional "result = " then appears in every exposition of a bodyCondition in the UML text. Modify the overview paragraph in 6.4.1 page 8 from: Operations: each specified by its signature, a textual description of the logic of the operation, and a specification of the logic of the operation in OCL. Note that in some cases the OCL is absent. to Operations: each specified by its signature, a textual description of the logic of the operation, and a bodyCondition to specify the logic of the operation in OCL. The mapping from the result-valued OCL bodyExpression to the Boolean-valued UML bodyCondition is expressed explicitly by a comparison of the result parameter with the bodyExpression . Note that in some cases the OCL is absent. Smarter Solution Arrange for the XMI producer to add the "result = " prefix to all the bodyConditions. - the UML text is unchanged, the RSA source is unchanged. Modify the overview paragraph in 6.4.1 page 8 from: Operations: each specified by its signature, a textual description of the logic of the operation, and a specification of the logic of the operation in OCL. Note that in some cases the OCL is absent. to Operations: each specified by its signature, a textual description of the logic of the operation, and a result-valued bodyExpression to specify the logic of the operation in OCL. The Boolean-valued UML bodyCondition may be determined from the OCL bodyExpression by wrapping the bodyExpression in a comparison with the result parameter. Note that in some cases the OCL is absent. ================================ Either way, the OCL specification and OCL tooling must evolve to eliminate the use of non-Boolean-valued bodyConditions. Regards Ed Willink On 07/11/2012 18:34, Ed Seidewitz wrote: Ed . Sorry, but I am losing track of the relevance of your comments to the issue at hand. Multi-returns are not at issue. OCL semantics is not at issue. We are talking about a UML construction (bodyConstraint) with the UML syntax of a Constraint whose specification is a UML ValueSpecification. The only reason OCL is involved is that the ValueSpecification happens to be a UML OpaqueExpression whose body is written in OCL. And this body is just an OCL Boolean expression, not a condition declaration or any other OCL construct. The name of the return parameters of the operation in question is .result., so an expression of the form .result=.. is just an OCL expression that says this return parameter must equal whatever the expression on the right-hand side of the .=. evaluates to. There is no special syntax here. Done deal, it seems to me. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Wednesday, November 07, 2012 3:11 AM To: Ed Seidewitz Cc: uml25-ftf@omg.org Subject: Re: Report on today's call Hi I was concentrating too much on the 'Constraint'. Yes the overriding semantics justifies the separate naming, and anything that is a Constraint is Boolean-valued. For multi-returns, the [0..1] multiplicity on body-condition is unhelpful; each return may benefit from a distinct body-condition rather to avoid an AND of multiple sub-bodyConditions. ?? A separate issue, but see solution below. ----- What does the OCL specification actually say normatively? In OCL 12.10 "The placement of an operation body expression is dependent upon the [forthcoming] UML 2.0 metamodel.". Nothing. The diagram showing the relationship of an OCL result-typed body-expression and a UML body-condition is missing, so any relationship is a proprietary attempt to make sense of the omission. There is no contradiction if UML uses a concrete syntax exposition such as "result = xyzzy" However in OCL 12.12.9, the Complete OCL syntax is "prePostOrBodyDeclCS[1] ::= .body. (simpleNameCS)? .:. OclExpressionCS prePostOrBodyDeclCS[2]?" so in Complete OCL, "body: xyzzy" is the normative way to specify a body-expression. The UML 2.5 exposition omits the redundant "context ..." declarations, so it is not necessary that the UML exposition is a syntactically valid Complete OCL prePostOrBodyDeclCS. An editorial statement that "body: result = xyzzy" is a body-condition comprising a "body:" introducer followed by the OCL for the bodyCondition eliminates the possible contradiction. What is the OCL custom and practice? Warmer and Kleppe, in OCL Getting your models ready for MDA, clearly use the "body: body-expression" syntax, so there is independent agreement with Eclipse OCL usage. ----- A possible OCL solution: The Complete OCL syntax for a body expression has an optional name. I assume that is just there for syntactic symmetry; I have never seen it used. It can be exploited to solve the multiple outputs and bridge the body-expression to body-condition gap. 1) Let Complete OCL semantics define "body X: ..." as the typeof-X-valued body-expression for the return/out/inout parameter named X. "body: ..." is a shortform for "body result: ..." The UML body-condition is then formed from the OCL body-expressions as a conjunction of comparisons. "(result = res) and (A = a) and (B = b)" is therefore the UIML-body-condition encoding of the the OCL body-expressions for an operation with a result, an out parameter A and an inout parameter B body: res body A: a body B: b This would just require an editorial clarification in the UML specification that the exposition of the body-expression as "body: res" is a shortform for the body-condition "result = res". But it would not support maintenance of the UML 2.5 meta-model with today's tools; the UML 2.5 OCL would be missing all the "result=" terms from the body-expression to body-condition encoding. Therefore: ---- 2) Let Complete OCL semantics further define "body X: ...", where "..." does not use "X", as a shortform for "body X: X=(...)". This then allows the UML 2.5 meta-model to be maintained by existing tools provided the "result=" is added manually to every body-condition (Use a text editor on the XML). The OCL in the UML 2.5 meta-model should be parseable by today's tooling but will only be executable by tooling that understands the body-expression/body-condition encoding. The OCL exposition in the UML 2.5 specification need not change, provided the auto-generator strips the redundant "result=" while formatting the OCL from the UML metamodel. The UML 2.5 specification could impose a constraint on the body-condition as a conjunction of output-name comparisons, but this is a useful simplification for OCL tooling rather than a necessary characteristic of the specification. Regards Ed Willink On 06/11/2012 21:43, Ed Seidewitz wrote: Ed . An Operation::bodyCondition is a Constraint. The .boolean_value. constraint on Constraint says .The ValueSpecification for a Constraint must evaluate to a Boolean value.. For the Constraints in question, the ValueSpecification is an OpaqueExpression whose body is an OCL expression, which must therefore evaluate to a Boolean value. The difference between a preCondition and a bodyCondition is given in 9.6.3: .The bodyCondition for an Operation constrains the return result. The bodyCondition differs from postconditions in that the bodyCondition may be overridden when an Operation is redefined, whereas postconditions may only be added during redefinition.. This ability to override is actually important in the way operations are used in the UML abstract syntax metamodel. Perhaps it would have been better to have defined a bodyExpression rather than a Boolean bodyCondition. But don.t think that is not something that is going to change at this point. There is no clash with OCL semantics, since bodyCondition is a UML syntactic construct, not something usable just with OCL. As Steve has said, the real issue is really that OCL attempted some tighter integration with UML, but didn.t specify it entirely properly (even though it has gotten a bit better in later versions). In any case, the update that Steve is proposing seems to be a perfectly acceptable way to make all the bodyConditions into correct Boolean expressions meaning exactly what we want. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Tuesday, November 06, 2012 3:46 PM To: uml25-ftf@omg.org Subject: Re: Report on today's call Hi Steve It's not clear to me that 12-10-24 requires the Body Condition to have a Boolean value. I see: "An optional Constraint on the result values of an invocation of this Operation." and "The bodyCondition for an Operation constrains the return result." [As a formal "Constraint" the value should be Boolean, but as an informal "constraint" it only provides a mechanism to validate a characteristic.] If you want a Boolean condition then bodyCondition is redundant. You might as well just use a post-condition for which 'result = ...' would be correct. It would appear that the OCL 2.0 authors recognised the confusing 'Body Condition' wording and so chose to use 'Body Expression'. For UML 2.5, I see the following choices a) reword BodyCondition to specify Boolean-valued => requires insertion of 'result =' in all body constraints => requires an explanation as to why bodycondition is indistiguishable from a postcondition => obscures the computable body with an idiomatic redundant comparison => introduces a head-on clash with OCL semantics => requires 'result' to be visible in more than post conditions. b) clarify BodyCondition as being result-valued => noting that BodyCondition is referred to as a body expression in OCL c) clarify BodyCondition by renaming to BodyExpression => a meta-model change Both a) and c) seem really bad choices to me. Regards Ed Willink On 06/11/2012 19:54, Steve Cook wrote: Ed In the UML metamodel, in all of the operations, by convention, .result. is the name of the single return parameter. So writing .result = x. in the bodyCondition is a (Boolean) constraint on the value of this parameter. There is certainly a misalignment between OCL and UML, which is that OCL (in section 7.4.6 of version 2.3.1) defines something called a .body expression., which does not appear in UML at all. In this definition it says .The expression must conform to the result type of the operation.. If this maps to anything in UML I guess it would be an OpaqueBehavior whose specification is the Operation. 12.10 of OCL 2.3 purports to explain this but fails. Indeed, the whole of section 12 is deeply unsatisfactory. It is supposed to explain how OCL expressions appear within UML models, but since it appears to ignore what the UML metamodel actually is, no UML tool can sensibly implement what it says. In UML, the bodyCondition of an Operation is a Constraint, and Constraint is constrained to have a Boolean value. The issue at hand is that UML is defined in UML, and if it is to satisfy its own well-formedness constraints, every Constraint and hence every bodyCondition must have a Boolean value. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 06 November 2012 18:27 To: uml25-ftf@omg.org Subject: Re: Report on today's call Hi 4. Steve raised issue 15259: meaning of bodyCondition, and pointed out that all of the bodyConditions currently in the metamodel are invalidly-typed according to the UML spec which requires them to have a Boolean value. Currently they all evaluate as expressions giving the value of the result. The fix appears to be to prepend .result = . to all of these expressions in the spec. This was done in 2.4 but for various reasons got lost in the OCL sort-out for UML 2.5 I'm not clear quite what the problem is, but the solution definitely seems wrong. "result" is only defined and useable in post-condition constraints, where post: result = ... verifies that a comparison of the result with a required value is as intended. Historically there was a misunderstanding that body: result = ... was a way of assigning to the result. It isn't. ---- In the event that multiple return/outs/inouts are required, there is a UML/OCL misalignment; OCL operations only supports a single return for any number of inputs. A sensible solution is that multiple results are returned as a Tuple in which the part names and types emulate the return/out/inout parameter names and types. Regards Ed Willink No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5875 - Release Date: 11/05/12 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5877 - Release Date: 11/06/12 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5877 - Release Date: 11/06/12 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5878 - Release Date: 11/06/12 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3204/6458 - Release Date: 07/02/13