Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 321532

Summary:	Inappropriate Classifier.conformsTo constraint
Product:	[Modeling] MDT.UML2	Reporter:	Ed Willink <ed>
Component:	Core	Assignee:	UML2 Inbox <mdt-uml2-inbox>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	P3	CC:	Kenn.Hussey
Version:	3.1.0	Keywords:	plan
Target Milestone:	---
Hardware:	PC
OS:	Windows Vista
Whiteboard:
Bug Depends on:
Bug Blocks:	286931, 418466

Description Ed Willink

2010-08-02 13:51:52 EDT

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.]

Comment 1 Kenn Hussey

2011-07-11 21:22:30 EDT

This should be fixed as part of adopting UML 2.4(.1).

Comment 2 Ed Willink

2011-07-12 01:11:07 EDT

(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.

Comment 3 Kenn Hussey

2011-08-22 23:38:46 EDT

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.

Comment 4 Ed Willink

2013-11-04 01:49:54 EST

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.