Eclipse Community Forums: OCL » OCL AST - Editing, Parsing and Cloning

Help

Home

Home » Modeling » OCL » OCL AST - Editing, Parsing and Cloning(Any pointers to doc and/or artefacts to use ?)

Show: Today's Messages :: Show Polls :: Message Navigator

OCL AST - Editing, Parsing and Cloning [message #1754168]

Tue, 14 February 2017 21:59

Edoaurd Batot

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

Report message to a moderator

Re: OCL AST - Editing, Parsing and Cloning [message #1754191 is a reply to message #1754168]

Wed, 15 February 2017 08:03

Denis Nikiforov

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.

Report message to a moderator

Re: OCL AST - Editing, Parsing and Cloning [message #1754240 is a reply to message #1754191]

Wed, 15 February 2017 16:06

Ed Willink

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

Report message to a moderator

Re: OCL AST - Editing, Parsing and Cloning [message #1754271 is a reply to message #1754240]

Thu, 16 February 2017 00:57

Edoaurd Batot

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

Report message to a moderator

Re: OCL AST - Editing, Parsing and Cloning [message #1754346 is a reply to message #1754271]

Thu, 16 February 2017 15:35

Ed Willink

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

Report message to a moderator

Re: OCL AST - Editing, Parsing and Cloning [message #1754980 is a reply to message #1754346]

Fri, 24 February 2017 20:08

Edoaurd Batot

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:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

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

.:: Contact :: Home ::.