Eclipse Community Forums: OCL » Migrating from CompleteOCL to OCLinEcore

Home » Modeling » OCL » Migrating from CompleteOCL to OCLinEcore

Migrating from CompleteOCL to OCLinEcore [message #1776796]

Tue, 21 November 2017 12:20

Eclipse User

I have a large and complex metamodel and a Complete OCL document with numerous constraints and operations ("defs"). I was wondering whether there is some utility which can take the Ecore and OCL files and combine them automatically? As simply copy-pasting across doesn't seem to be straightforward due to the slightly syntactical differences.

The only reason I want to do this is to generate Java code, so if there is a way to generate Java from an Ecore and OCL file that would be more useful.

Re: Migrating from CompleteOCL to OCLinEcore [message #1776851 is a reply to message #1776796]

Wed, 22 November 2017 04:38

Eclipse User

Hi

The underlying tools are used by the OCL and QVTd releng. I put a UI on the reverse conversion a couple of months ago to help the SysML developers: extracting a Complete OCL document from OCL embedded in UML/Ecore. A UI for Complete OCL to embedded Ecore/UML remains a roundtuit; Ecore should be easy UML will probably wait till I re-engineer UML2AS using QVTr.

The basic tool is the /org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/utilities/ConstraintMerger.java that you can see in action in /org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/GeneratePivotModel.mwe2. However this is a rather complicated example since it starts with a QVTo mediated merge of UML.uml, OCL.uml, MDTOCL.uml into Pivot.ecore to which Pivot.ocl is added.

Perhaps the 'simplest' example is /org.eclipse.qvtd.build/src/org/eclipse/qvtd/build/mwe2/GenerateQVTdASModels.mwe2 that merges e.g.
/org.eclipse.qvtd.pivot.qvtimperative/model/QVTimperativeStructural.ecore and /org.eclipse.qvtd.pivot.qvtimperative/model/QVTimperative.ocl into /org.eclipse.qvtd.pivot.qvtimperative/model/QVTimperative.ecore before /org.eclipse.qvtd.pivot.qvtimperative/model/QVTimperative.genmodel controls the generation of Java code.

The OCL2Java CG has been in use for four annual releases and while it nominally handles any OCL construct, as my constraints get more complicated, I still find CG bugs to fix; particularly in regard to use of Ecore types such as EInt rather than Integer. My Complete OCL documents are mostly just constraints. I have used some defined operations and properties. Sometimes they worked, but I'm not confident; I have a nagging doubt that there is some work to be done. I'm pretty sure that CG of additions to arbitrary classes such as OclElement is not yet supported; still waiting for a branch development to be remotivated.

Regards

Ed Willink

Re: Migrating from CompleteOCL to OCLinEcore [message #1776981 is a reply to message #1776851]

Thu, 23 November 2017 06:50

Eclipse User

Hi Ed,

Thanks for the reply. It seems like the simplest solution would be to manually perform the migration and use some simple Ctrl + F regexes to handle syntactic differences (e.g. "inv" and "invariant").

Re: Migrating from CompleteOCL to OCLinEcore [message #1776989 is a reply to message #1776981]

Thu, 23 November 2017 08:01

Eclipse User

Hi

I'm confused. You wrote that a way to generate Java from Ecore and OCL would be more useful so the MWE2 tools should suit you well. In contrast manual migration has to be repeated each time.

I suddenly had an idea that the UI might work already. Load a *.ecore then load a *.ocl into the same editor then save. No such luck, but an OCL->Merge edit action would be an almost trivial AS2AS operation and then it should work. Looking at it now.

Regards

Ed Willink

Re: Migrating from CompleteOCL to OCLinEcore [message #1777003 is a reply to message #1776989]

Thu, 23 November 2017 09:33

Eclipse User

Hi Ed,

Thanks for looking into this. I was meaning that perhaps for this one time it may be easier to do a manual merge but if a long-term solution is trivial to implement then it would indeed be a great feature!

[Updated on: Thu, 23 November 2017 09:35] by Moderator

Re: Migrating from CompleteOCL to OCLinEcore [message #1777007 is a reply to message #1777003]

Thu, 23 November 2017 10:07

Eclipse User

Hi

It rather depends why you have a Complete OCL document.

A separate document is a bit more 'focussed' but editing is a bit fragile since the Complete OCL syntax is badly designed.

If you want a separate document then you want a programmatic merge as provided by the MWE2 tooling.

If yo want a merged document then a one off (for you) manual conversion is tedious. But the UI merge has been on my to-do list for too long. You have motivated me to get round to it.

Regards

Ed Willink

Re: Migrating from CompleteOCL to OCLinEcore [message #1778463 is a reply to message #1777007]

Thu, 14 December 2017 09:25

Eclipse User

Hi Ed,

Thank you for the suggestions. I can confirm that changing the return type to OrderedSet instead of Collection does indeed remove the dependency on OCLStdLib and generation completes without warnings or errors, but the generated code from the genmodel has compile errors as you mention.

Perhaps adding a .getName() to the EnumerationLiteralId BOXED_XXX (and using .equals() instead of == ) should fix this?

UPDATE: I just tried doing this and despite a compilation error in JavaMMTables the program at least ran, but gave wrong results (all constraints satisfied when expecting 1721 unsatisfied). Probably a bug with my code at this point.

[Updated on: Thu, 14 December 2017 09:37] by Moderator

Re: Migrating from CompleteOCL to OCLinEcore [message #1778465 is a reply to message #1778463]

Thu, 14 December 2017 09:48

Eclipse User

Hi

There is probably a simple manual workaround, but I haven't investigated. The underlying problems with Bug 528756 / Bug 528768 seem quite deep seated. It seems that use of nsURI references in a *.ecore is incompatible with a subsequent genmodelling.

EnumerationLiterals are troublesome because they are the only Ecore element that has no eContainer() consequently Ecore EEnumLiterals are not unique. The code is endeavouring to use the equivalent Pivot EnumerationLiteral which is unique.

Locally I suspect that

final /*@Thrown*/ boolean eq_0 = BOXED_inheritance == JavaMMTables.STR_final;

should be

final /*@Thrown*/ boolean eq_0 = BOXED_inheritance == JavaMMTables.EnumerationLiterals._InheritanceKind__final;

but when looking at the couple of preceding lines this looks like a simple code sequence has been overlooked in favour of something quite mad.

Ah!

* md.thrownExceptions->first().type.name = 'CloneNotSupportedException' and md.modifier <> null and md.modifier.visibility = 'public')

which is because you are using strings rather than enumerations. Try

md.modifier.visibility = VisibilityKind::public

Regards

Ed Willink

Re: Migrating from CompleteOCL to OCLinEcore [message #1778467 is a reply to message #1778465]

Thu, 14 December 2017 10:10

Eclipse User

Hi Ed,

I have gone through the Ecore file and replaced all references to EEnum literals with their EEnumType::name as suggested and it has fixed the compilation errors, except for those in JavaMMTables. Perhaps a convenient feature would be to automatically perform this conversion when generating code, since the interpreted OCL can handles literals without any issues.

Looks like I posted in the wrong thread! Though the issues basically stem from the migration so perhaps it's not off-topic.

[Updated on: Thu, 14 December 2017 10:24] by Moderator

Re: Migrating from CompleteOCL to OCLinEcore [message #1778473 is a reply to message #1778467]

Thu, 14 December 2017 10:45

Eclipse User

Hi

If the interpreted code handles strings as literals then that is a different bug. I suspect that you have accidentally used EOL literal no-syntax in OCL which has a literal syntax.

Similarly "implements()" appears to be influenced by EOL inadequacies. OCL has type-literals. implements should be replaceable by something like

def: implements(type : OclType) : Boolean = self->closure(superInterfaces)->includes(type)

IMHO use of strings rather than objects as internal programmatic identifiers is a really bad idea. You end up having to have scoping rules to handle ambiguous names throughout all your code rather than just the input parser. Objects aren't ambiguous.

Regards

Ed Willink

Re: Migrating from CompleteOCL to OCLinEcore [message #1778480 is a reply to message #1778473]

Thu, 14 December 2017 11:52

Eclipse User

Hi

"except for those in JavaMMTables". Those errors go away if you set the genmodel Model option Literals Interface to true, which is normally the default. However your model is larger than EMF's heuristic threshold. If you really need no-literals support please raise an enhancement Bugzilla against Eclipse OCL.

"interpreted OCL can handles literals without any issues". I have tested this. There may be no CG bugs but the functionality is the same. Perhaps you were being fooled by the OclAny commonality that "anEnumLiteral = aString" is always valid but always false. Eclipse OCL now has quite a bit of static analysis to support null/non-null propagation, but this does not yet extend to dead code that could warn that "anEnumLiteral = aString" is always false. https://bugs.eclipse.org/bugs/show_bug.cgi?id=528793 raised.

Regards

Ed Willink

Re: Migrating from CompleteOCL to OCLinEcore [message #1778524 is a reply to message #1778480]

Fri, 15 December 2017 12:04

Eclipse User

Hi Ed,

Thanks for the answers. The code I used in OCL has certainly been "ported" from EVL but the use of String in "implements" operation is for convenience. Both OCL and EOL support type literals, Enum types and closures. For this particular method using String makes sense, but for others I agree.

Regarding the Literals tables, I presume the option you're referring to in the genmodel is the Model Feature Defaults -> Packed Enums? As I don't see any options relating to EEnums or literals in any of the other property categories.

EDIT: I was looking in the root rather than the EPackage, never mind.

[Updated on: Fri, 15 December 2017 12:08] by Moderator

Re: Migrating from CompleteOCL to OCLinEcore [message #1778532 is a reply to message #1778524]

Fri, 15 December 2017 14:40

Eclipse User

Hi

https://bugs.eclipse.org/bugs/show_bug.cgi?id=528768 is fixed. A mixed EnumerationLIteral/String equality comparison is now generated as a simple false.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=528756 is fixed. Use of Collection no longer bombs in GenModel.

An EMF Genmodel enhancement may arise from https://bugs.eclipse.org/bugs/show_bug.cgi?id=528768

OCL fixes available in http://www.eclipse.org/modeling/download.php?file=/modeling/mdt/ocl/downloads/drops/6.4.0/N201712151833/mdt-ocl-Update-N201712151833.zip

Regards

Ed Willink

Re: Migrating from CompleteOCL to OCLinEcore [message #1778600 is a reply to message #1778532]

Mon, 18 December 2017 07:12

Eclipse User

Hi Ed,

Thanks for your help and fixing these issues!

Re: Migrating from CompleteOCL to OCLinEcore [message #1778778 is a reply to message #1776851]

Thu, 21 December 2017 05:37

Eclipse User

Hello,

Ed Willink wrote on Wed, 22 November 2017 04:38

The basic tool is the /org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/utilities/ConstraintMerger.java that you can see in action in /org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/GeneratePivotModel.mwe2. However this is a rather complicated example since it starts with a QVTo mediated merge of UML.uml, OCL.uml, MDTOCL.uml into Pivot.ecore to which Pivot.ocl is added.

Ed Willink

I have the same need (from CompleteOCL to OCLinEcore) and would like to try the mwe2 way. For this, I need the ConstraintMerger component which is in the org.eclipse.ocl.examples.build plugin. This plugin does not seem to be part of the standard OCL distribution. Is it available some where or do I have to build it from the git sources ?

Regards,
Dominique

Re: Migrating from CompleteOCL to OCLinEcore [message #1778779 is a reply to message #1778778]

Thu, 21 December 2017 05:57

Eclipse User

Hi

It should build itself from the GIT sources.

Using EMF as an example; *.examples.* plugins are distributed, *.releng.* are not.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=529068 raised; move org.eclipse.ocl.examples.build to releng.

This does not help you, org.eclipse.ocl.examples.build has too many extra dependencies to be distributed.

More helpful will be a ConstraintMerger in the normal plugins.

I started work on this a couple of weeks ago and got distracted. It is not a high priority for me since it will be replaced anyway once Ecore2AS and AS2Ecore are autogenerated from a QVTr transformation.

What is your requirement?

a) one-off migration
b) occasional refresh
c) automated too chain component

Regards

Ed Willink

Re: Migrating from CompleteOCL to OCLinEcore [message #1778803 is a reply to message #1778779]

Thu, 21 December 2017 10:44

Eclipse User

Hi,

Ed Willink wrote on Thu, 21 December 2017 05:57

It should build itself from the GIT sources.

I've tried several times to build the OCL plugins without success. But I will create another thread for that.

Quote:

What is your requirement?
a) one-off migration
b) occasional refresh
c) automated too chain component

b) is fine for the moment, but I may need c) depending on the increased performance in OCL evaluation.

Regards,
Dominique

Re: Migrating from CompleteOCL to OCLinEcore [message #1778810 is a reply to message #1778803]

Thu, 21 December 2017 11:56

Eclipse User

Hi

Occasional refresh? Why?

Do you prefer to use Complete OCL rather than OCLinEcore, but want the code generation benefits of OCLinEcore?

If so why do you prefer Complete OCL?

(The Complete OCL + Ecore use case could be 99% supported by an import EAnnotation in the Ecore. The residual 1% might require a manual interactive init key.)

Regards

Ed Willink

Re: Migrating from CompleteOCL to OCLinEcore [message #1778816 is a reply to message #1778810]

Thu, 21 December 2017 14:34

Eclipse User

Hi

Ed Willink wrote on Thu, 21 December 2017 11:56

Occasional refresh? Why?

This is a academic tool (http://wdi.supelec.fr/software/RiseClipse/), but we hope that it will be used by utilities beside EDF. We need to mesure the benefit of using OCL -> Java in our use cases. The models behind the tools are regularly updated. And utilities should be allowed to add their own extensions to the standards.

Quote:

Do you prefer to use Complete OCL rather than OCLinEcore, but want the code generation benefits of OCLinEcore?

Yes.

Quote:

If so why do you prefer Complete OCL?

There are constraints imposed by standards (quite stable), but users should be able to add their own business constraints. CompleteOCL allow us to check new constraints once the tool is built. OCLinEcore does not.

Regards,
Dominique

Re: Migrating from CompleteOCL to OCLinEcore [message #1778830 is a reply to message #1778816]

Fri, 22 December 2017 05:03

Eclipse User

Hi

Thanks for the background.

"need to measure". Oh dear, you are going to spot the many opportunities for a CG improvement. At least it's much better than interpreted.

Am I right in thinking that a genmodel import would solve your problems?

Model.genmodel references Model.ecore (conventionally) and Model.ocl (via a new GenAnnotation)

Every time Model.ecore or Model.ocl changes, you just re-invoke Generate Model within the GenModel editor, or from a programmatic GenerateModel.

Regards

Ed Willink

Previous Topic:	Complete OCL for Xtext Validation
Next Topic:	Strange behavior on MS/Win with OCL

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jun 24 22:27:55 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter