UML 2.2 RTF Avatar
  1. OMG Issue

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

  • Key: UML22-467
  • Legacy Issue Number: 13258
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    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

    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

  • Reported: UML 2.1.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    merged with 15259

  • Updated: Fri, 6 Mar 2015 20:58 GMT