Description Ed Willink 2011-11-19 05:43:04 EST

The OCL constraints in the current UML meta-models have never been tool checked, so they contain many errors. These were of no real consequence, particularly since there was a disconnect between the UML GenModel URI for bodies and the OCL Delegate URI for bodies.

Eclipse OCL now provides an OCL 2 Java code generator integrated with GenModel, so, if the OCL codegen plugin is installed and unless there is a suppressing GenAnnotation, regenmodelling will provide Java code for the embedded OCL. This is variously a problem and an opportunity for MDT/UML2. 

Problem 1: If the embedded OCL has errors, the genmodelling activity will fail. I am currently needing to make many fixes to the Infrastructure.cmof that is copied to form the basis for OCL meta-model. mainly removing "result = " from all bodies, then more technical details. (For invariants "result" is undefined, for queries "result = ..." requires the final result to be used to compute the final result as a comparison of the final result with some expression!]

Opportunity 1: With auto-generated OCL 2 Java, there is no need to manually recode the constraints, Operations classes and OCL.newInstance class can be eliminated.

Opportunity 2: With auto-generated OCL 2 Java, there is a high probability that the execution will match the OMG spec, which will certainly have to evolve as the specified constraints are debugged.

Problem 2: UML and other annotated EMF models have a generated dependency on the OCL run-time. This was already present in the form of OCL.newInstance() calls. But now UML2's own generated models will also have a run-time dependency on the OCL run-time. Fresh from splitting into Core+Tools builds, may be OCL has to split four ways to support the following dependency levels.

{EMF-Core}, {OCL-Runtime,MWE}, {UML2,Xtext}, {OCL-Core,OCL-Tools}, {Acceleo}, {OCL-Codegen}