Issue 13258: inconsistency with how constraints are specified in UML and OCL (uml2-rtf) Source: International Business Machines (Mr. James Bruck, nobody) Nature: Uncategorized Issue Severity: 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 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. Resolution: Revised Text: Actions taken: January 14, 2009: received issue Discussion: End of Annotations:===== ubject: Another issue with UML2 spec. X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: James Bruck Date: Wed, 14 Jan 2009 15:21:44 -0500 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 01/14/2009 15:21:48, Serialize complete at 01/14/2009 15:21:48 Hi Juergen, I would like to raise the following issue with the UML2 spec. Name:James Bruck Company: IBM mailFrom: jbruck@ca.ibm.com Notification: Yes Specification: OMG Unified Modeling Language (OMG UML), Superstructure Section: 7.3.10 FormalNumber: ptc/2008-05-05 Version: Version 2.2, Beta 1 RevisionDate: 05/01/08 Page: 58 Nature: Issue Severity: --- There seems to be an 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.