Eclipse Community Forums: OCL » Def expressions in OCLInEcore and the Interactive console.

Help

Home

Home » Modeling » OCL » Def expressions in OCLInEcore and the Interactive console.

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

Def expressions in OCLInEcore and the Interactive console. [message #552467]

Thu, 12 August 2010 09:59

Toñi Reina

Messages: 209
Registered: July 2009

Senior Member

Hi,

I'd like to know if def expressions, such as the ones below are
allowed in OCLInEcore and the Interactive Console.

context Person
def: income : Integer = self.job.salary->sum()
def: nickname : String = ‘Little Red Rooster’
def: hasTitle(t : String) : Boolean = self.job->exists(title = t)

I'm afraid that this kind of expressions are not allowed in the
Interactive Console (as it is asked as exercise in
http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html).
But can they be written in oclinecore??

Report message to a moderator

Re: Def expressions in OCLInEcore and the Interactive console. [message #552572 is a reply to message #552467]

Thu, 12 August 2010 16:16

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Toni

Not really.

A def expression is a CompleteOCL concept and is supported by the
CompleteOCL editor. Unfortunately the Interactive Console has no
mechanism to load a CompleteOCL document for use.

The Xtext CompleteOCL editor extends CompleteOCL to support an import
meta-model capability, that is missing from OMG's CompleteOCL. When
using the RoyalAndLoyal.ocl example you need to provide the import via
the model registry.

There is an experimental 'definition' keyword that can prefix an
operation or attribute for OCLinEcore, but it won't get you very far
since it doesn't go anywhere useful.

Regards

Ed Willink

On 12/08/2010 10:59, Toñi Reina Quintero wrote:
> Hi,
>
> I'd like to know if def expressions, such as the ones below are allowed
> in OCLInEcore and the Interactive Console.
>
> context Person
> def: income : Integer = self.job.salary->sum()
> def: nickname : String = ‘Little Red Rooster’
> def: hasTitle(t : String) : Boolean = self.job->exists(title = t)
>
> I'm afraid that this kind of expressions are not allowed in the
> Interactive Console (as it is asked as exercise in
> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html).
> But can they be written in oclinecore??
>

Report message to a moderator

Re: Def expressions in OCLInEcore and the Interactive console. [message #1833549 is a reply to message #552572]

Fri, 16 October 2020 12:47

Stefan John

Messages: 17
Registered: March 2018

Junior Member

Hi Ed,

10 years passed. Any update on this?
I see that the OCLinEcore tutorial talkes about "Helper Features and Operations" but implements them as standard properties and operations. As I merely want to reuse lengthy OCL expressions which do not necessarily contribute a meaningful semantics to the end user of the metamodel, I am not really happy with that.

I also hoped that an implementation of such definition expressions would probably use some sort of cache and would not have to recalculate a def. expression each time another OCL expressions uses it. Thinking about it, I am not sure if that wish can be fulfilled as I am not sure what the scope of such a cached value would be (when would we have to recalculate?) and in what order one would have to evaluate all definitions. There might even be circular dependencies between different definition expressions. Implementing such a caching feature doesn't seem to be the most trivial thing to. However, someone might have done it, meanwhile?

Also, how do derived attributes implemented by OCLinEcore behave with regard to caching? If they are not set to volatile the implementation to me looks much like a standard attribute. The derived modifier alone does not seem to have any impact?!

Best regards,
Stefan

Report message to a moderator

Re: Def expressions in OCLInEcore and the Interactive console. [message #1833554 is a reply to message #1833549]

Fri, 16 October 2020 19:10

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

Bugs [1], [2], [3], [4] are relevant.

Operation result caching was added for QVT, where the system state is known to be stable, but as you observe that is not necessarily true for OCL enriched Ecore.

Helpers are difficult to support with the current narrow view of the Ecore API. Every non-trivial OCL operation has to discover where the OCL context is by searching for a ResourceSet adapter. Not very clever when an operation calls another operation using the API and so discarding the knowledge in the call. I have therefore been thinking of doubling the API, retaining the existing Ecore-API for OCL-blind call contexts but delegating to a new OCL-aware API that has an extra OCL argument. This should liberate the generated code from a tight-coupling to self/this allowing an OCLHelpers.java to be generated with static functions that can be invoked with the OCL-aware API. The OCL-aware API should successfully bypass many levels of eGet delegation.

Now that someone is interested, my 'thinking about' might reappear closer to the top of my to-do stack.

IIRC I added the support for QVT but then suppressed it pending some inspiration as to how to make it valid for OCL. It requires some ability to identify a suite of OCL operations that occur without a system state change. Could be achieved by a user application, such as QVT, but could also be used during model validation which does now have a workaround for the limitation that it is impossible for OCL validation to know when it starts or finishes unless the user is prepared to invoke start/stop operations or use a derived Diagnostician that does so. A pity that Diagnostician has no 'listener' capability.

(The delegate functionality that was added to EMF, primarily to support OCL is pretty magic. Unfortunately my review comments were ignored and so there are some aspects of the functionality that are needless klunky / restrictive.)

IIRC cached derived features work. You just need to declare an OCL-initialized, !volatile, derived feature to ensure that EMF allocates a field and invokes the setting delegate to initialize.

Regards

Ed Willink

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=491264
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=500519
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=500520
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=500521

Report message to a moderator

Previous Topic:	Class CastException in OCLinEcore generated code
Next Topic:	run OCL on models programmatically

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 12:48:51 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter