Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » OCL AST - Editing, Parsing and Cloning(Any pointers to doc and/or artefacts to use ?)
OCL AST - Editing, Parsing and Cloning [message #1754168] Tue, 14 February 2017 21:59 Go to next message
Edoaurd Batot is currently offline Edoaurd BatotFriend
Messages: 90
Registered: March 2015
Member
Bonjour,

I'm working on OCL ASTs provided by the org.eclipse.ocl * framework.
I get from the text document a tree which root is an ExpressionInOCL with its body and context. Then I modify it on the fly depending on certain needs.
Now, I would like to try different transformations/changes on the elements without side effects : I need to clone, a deep cloning. And I would like to have an estimation of how many errors are in the modified structure as a way of measurement. I'm sure these functionalities have been implemented somwhere and I don't want to reinvent the wheel again - I might end up with a square one.

I thus come with three questions - the first be the most critical.

0. How do you overcome the bootstrap syndrome on google ? Looking for Check/Validation and OCL always refers to model validation using OCL - what about checking OCL itself ?

1. I need to clone the ASTs (pointers war) and I wonder, again, where is the tooling to handle the constraints and their structure. Any idea ?

2. As I would like to check partial ASTs.. Is there a package to try syntax on CallExp or other OCL ELement without turning them back to text ?

Thanks,
Edouard
Re: OCL AST - Editing, Parsing and Cloning [message #1754191 is a reply to message #1754168] Wed, 15 February 2017 08:03 Go to previous messageGo to next message
Denis Nikiforov is currently offline Denis NikiforovFriend
Messages: 167
Registered: August 2013
Senior Member
Hi

We use QVTo to transform OCL ASTs. To get additional information about Ecore classes like CallExp you can Ctrl + Click on "CallExp" in the QVTo editor and you will see its properties, and etc. in the Model Explorer.

Also the OCL specification provides a full description the OCL metamodel.
Re: OCL AST - Editing, Parsing and Cloning [message #1754240 is a reply to message #1754191] Wed, 15 February 2017 16:06 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5438
Registered: July 2009
Senior Member
Hi

Eclipse OCL extends Ecore so many facilities are provided by EMF.

EcoreUtil.Copier and friends are useful for cloning, with optional overrides to adjust some behaviors.

Diagnostician is good for validation. OCL can provide validation extensions. See OCLinEcore tutorial and CG thereof.

The JUnit tests do a lot of OCL execution so they demonstrate how to execute things. You should learn to search a bit for usages rather than asking questions at every step.

The old Classic OCL is an uncomfortable parameterized hybrid of OMG-like OCL and Ecore/UML that violates the "do not extend Ecore.ecore EMF guideline". The new Pivot OCL has a uniform OCL+Pivot model; it uses rather than extends Ecore.ecore.

The OMG specification does not fully define or provide a consistent metamodel, but its close for basic usage. The Classic OCL endeavours to do what the specification intended to say ignoring some fundamental problems. The Pivot OCL prototypes solutions to the fundamental problems.

Support for extensibility by QVTd means that the Pivot OCL has a steadily growing family of helper functions in e.g. PivotUtil and PivotHelper.

Regards

Ed Willink
Re: OCL AST - Editing, Parsing and Cloning [message #1754271 is a reply to message #1754240] Thu, 16 February 2017 00:57 Go to previous messageGo to next message
Edoaurd Batot is currently offline Edoaurd BatotFriend
Messages: 90
Registered: March 2015
Member
Thanks for your answers.

Quote:
EcoreUtil.Copier and friends are useful for cloning, with optional overrides to adjust some behaviors.

This is definitely what I'm looking for.

Quote:
Diagnostician is good for validation. OCL can provide validation extensions. See OCLinEcore tutorial and CG thereof.
The diagnostician seems to me to be a tool to validate models with OCL or not. I don't see how to use it to found errors in OCL ASTs. (Maybe this refers to the first question (0) I asked Smile maybe I'm wrong. I'm gonna deepen that new maze of bootstrapping)

Quote:
The old Classic OCL is an uncomfortable parameterized hybrid of OMG-like OCL and Ecore/UML that violates the "do not extend Ecore.ecore EMF guideline". The new Pivot OCL has a uniform OCL+Pivot model; it uses rather than extends Ecore.ecore.
I don't understand that sequence.

Quote:
We use QVTo to transform OCL ASTs
I am sorry but I don't know what is QVTo exactly. But it could be a good idea to look that direction for future work.. editing constraints written in OCL by model transformation sounds fun Smile Maybe less "down to code" than my factory-like approach. Thanks.

Thanks !
Good evening,
Edouard
Re: OCL AST - Editing, Parsing and Cloning [message #1754346 is a reply to message #1754271] Thu, 16 February 2017 15:35 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5438
Registered: July 2009
Senior Member
Hi

"I am sorry but I don't know what is QVTo exactly"

Try Google. The top ten hits are all relevant.

If you use the Pivot-based OCL, you will find that the constraints defined in GIT\org.eclipse.ocl\plugins\org.eclipse.ocl.pivot\model\Pivot.ocl are code generated as Java in the genmodel code, so when you validate a Pivot OCL AST, the constraints are executed. Currently Pivot.ocl has perhaps 50% coverage of potential constraints. You should use the PivotHelper routines since setting the types of templated operation returns and property values is far from trivial.

Regards

Ed Willink
Re: OCL AST - Editing, Parsing and Cloning [message #1754980 is a reply to message #1754346] Fri, 24 February 2017 20:08 Go to previous message
Edoaurd Batot is currently offline Edoaurd BatotFriend
Messages: 90
Registered: March 2015
Member
Metamodel:
Class P {
  P mother
  P father
}


Constraint:
inv noSelfParent : self.mother <> self


Change:
'mother' became 'father', using PropertyCallExp.setReferredProperty(father)
inv noSelfParent : self.father <> self


Result from the Diagnostician.eINSTANCE called on the constraint after the change :
"The 'checkPropertyType' invariant is violated on 'org.eclipse.ocl.ecore.impl.PropertyCallExpImpl@6b09fb41{ocl:///oclenv.ecore#/5/@specification/@bodyExpression/%.1/%/%}'"

This happens systematically, no matter the change.

Any suggestion ?

[Updated on: Fri, 24 February 2017 20:44]

Report message to a moderator

Previous Topic:Extend data types from the Standard Library in UML model
Next Topic:How to integrating OCL expressions in DSL grammar (Xtext project ) ?
Goto Forum:
  


Current Time: Tue Oct 24 00:36:27 GMT 2017

Powered by FUDForum. Page generated in 0.01877 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software