Community
Participate
Working Groups
UML.metamodel.uml defines Classifier.conformsTo to have result = (self=other) or (self.allParents()->includes(other)) This is only valid as a postcondition, since only postconditions have a result variable predefined. It is not entirely surprising that this is wrong because the OCL specification is only half-defined in this area. The actual OCL in UML 2.1.2 and 2.3 is Classifier::conformsTo(other: Classifier): Boolean; conformsTo = (self=other) or (self.allParents()->includes(other)) which is even less valid; the operation name is not a variable in at least OCL 2.x. My interpretation of the valid options are either to define a <<postcondition>> with "result = (self=other) or (self.allParents()->includes(other))" or a <<body>> with "(self=other) or (self.allParents()->includes(other))", the latter being executable rather than checkable. This has come to light because Bug 286931 introduces an ExpressionInOCLAdapter that endeavours to execute bodies, and bombs on the undefined 'result' variable. [This bug is no doubt systemic to all UML2's OCL.]
This should be fixed as part of adopting UML 2.4(.1).
(In reply to comment #1) > This should be fixed as part of adopting UML 2.4(.1). Or more realistically UML 2.5, which should finally use OCL tooling to eliminate the 300 odd errors in the OCL aspects of the UML specification. In the branch for Bug 279638, I'm developing an Acceleo template that takes a *.genmodel and emits *Operation classes with the prevailing API and auto-generated Java for the corresponding OCL. This is much more efficient than OCL interpretation (and first time parsing), and for some complicated iterations may be faster than naive manual code. Further improvements to the OCL execution speed will occur incrementally as smarter/lazier values classes are added and preliminary analyses are exploited. With UML's OCL changing subtly in many constraints and significantly in some, it may be appropriate to move to auto-generation. Help on genmodel integration welcome.
Yeah, I was under the impression that some/most of the OCL had been cleaned up in UML 2.4 but it's being done for UML 2.5.
See Bug 419324 for a more plausible approach. UML specifies that a Constraint body must be Boolean-valued. Therefore UML requires that type-valued Operation bodyies are converted to Boolean-valued by a "result = (....)" wrapper. Therefore "result =" appears in the UML XMI, and somewhere a UML2OCL specification must specify unwrapping. Bug 419324 considers this for UML2EAnnotationOCL.
