Migrating from CompleteOCL to OCLinEcore [message #1776796] |
Tue, 21 November 2017 17:20 |
Sina Madani Messages: 160 Registered: November 2015 Location: York, UK |
Senior Member |
|
|
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 #1778463 is a reply to message #1777007] |
Thu, 14 December 2017 14:25 |
Sina Madani Messages: 160 Registered: November 2015 Location: York, UK |
Senior Member |
|
|
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 14:37] Report message to a moderator
|
|
|
|
Re: Migrating from CompleteOCL to OCLinEcore [message #1778467 is a reply to message #1778465] |
Thu, 14 December 2017 15:10 |
Sina Madani Messages: 160 Registered: November 2015 Location: York, UK |
Senior Member |
|
|
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 15:24] Report message to a moderator
|
|
|
|
|
Re: Migrating from CompleteOCL to OCLinEcore [message #1778524 is a reply to message #1778480] |
Fri, 15 December 2017 17:04 |
Sina Madani Messages: 160 Registered: November 2015 Location: York, UK |
Senior Member |
|
|
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 17:08] Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04323 seconds