UML24 — Meaning of BodyCondition and its alignment with OCL

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?

OCL body expressions and UML bodyConditions are inconsistently specified. For the UML spec, the
bodyConditions need to be Boolean. The way we do this is by naming the result parameter of all of the
operations as “result”. Then the body expressions should be of the form “result = <expression>”.
Unfortunately, doing this in RSA causes type errors because RSA gives a well-typed expression its internal
Boolean type which is not the same type as the UML 2.5 PrimitiveType Boolean.
So in order to keep RSA as happy as possible, and reduce error-prone work, we’ll keep the body expressions
in the metamodel in the OCL-like form (without the “result =”) and cause the XMI generation process to
wrap result = (. . . ) around all of the body expressions.
This also resolves 13258.