UML22 — inconsistency with how constraints are specified in UML and OCL

In OCL 2.0 specification, section Operation Body Expression, it specifies that
expression must conform to the result type of the operation.

However, in UML 2.1.2 specificaiton, it is specified that bodyCondition of an
operation is a constratin which must evaluates to a boolean expression.

The problem is that UML equates the term "constraint" with "boolean-valued
expression that holds true at some time." The OCL usage of the term is not so
narrow. A constraint is a model element that specifies more precise semantics
for another model element than what its structure alone can achieve.

So, for example, an attribute constrains its values to conform to some type,
but a derivation expression (whose value conforms to the attribute type) more
precisely constrains its values. Likewise the operation body expression
constrains the value of an operation by computing it from the parameters and
the context object. Note that OCL actually calls this constraint a "body
expression," not a "body condition" as UML does. OCL's notion of "constraint"
even extends to definition of helper operations and attributes.

Consider what it means to require boolean values for operation body
constraints. They must be formulated like postconditions, as boolean
expressions on the "result" variable. In OCL, the body condition does not have
a "result" variable; only post-conditions have it. Furthermore, consider an
example: an operation phi() defined in the Real primitive type. According to
UML's rules, it could be defined like this:

context Real::phi() : Real
body: result = (1.0 + 5.0.sqrt()) / 2.0

or like this:

context Real::phi() : Real
body: (result - 1.0) = (1.0 / result)

These are isomorphic constraints, but neither is friendly to OCL tool
implementations (certainly not the second). According to OCL, the constraint
would by formulated like this:

context Real::phi() : Real
body: (1.0 + 5.0.sqrt()) / 2.0

and there really is no other kind of formulation. IMO, this is much more
practical for all concerned.

Consider an operation that has parameters, for which I write an ineffectual
body constraint like this:

context Foo::doSomething(bar1 : Bar, bar2 : Bar) : Baz
body: bar1 <> bar2

What does this mean?

All in all, it is far mare useful to have an OCL expression that can readily be
evaluated to compute the value of the operation. This leaves no room for
ambiguity.

The UML stipulation that Constraints in all contexts must be boolean
expressions, as in operation precondition and classifier invariant context, is
unnecessary. What is the benefit? It would be nice to see it removed in UML
2.3.

merged with 15259