Eclipse Community Forums: OCL » OCL delegate evaluation

Home » Modeling » OCL » OCL delegate evaluation

OCL delegate evaluation [message #1049902]

Fri, 26 April 2013 08:33

Eclipse User

I have a very simple Ecore model contains 3 classes(Class1, Class2, Class3).
Connection between classes are as follows
Class1->Class2
Class2->Class3
Class1->Class3 (derived)

Class3 has boolean attribute with derivation statement
Class1.allInstances().class3->includes(self); // check myself is included in Class1.class3 property.

consider i instantiate this ecore with one instance of Class1 connected 5 instances of Class2 and each instance of Class2 is connected with 5 different instances of Class3.

My question is related to evaluation approach. Will Class1->class3 relation will be evaluated for every instance of class3 or Class1->class3 will be evaluated once?

import ecore : 'http://www.eclipse.org/emf/2002/Ecore#/';

package temp : TEST = 'http://www.eclipse.org/mdt/ocl/oclinecore/tutorial'
{
class Class1
{
property class2#class1 : Class2[*];
property class3#class1 : Class3[*] { derived volatile }
{
derivation: class2.class3->asSet();
}
}
class Class2
{
property class1#class2 : Class1[*] { ordered };
property class3#class2 : Class3[*];
}
class Class3
{
attribute available : ecore::EBooleanObject { derived volatile }
{
derivation: Class1.allInstances().class3->includes(self);
}
property class1#class3 : Class1[*] { ordered derived volatile }
{
derivation: ;
}
property class2#class3 : Class2[*] { ordered };
}
}

Regards,

[Updated on: Fri, 26 April 2013 08:33] by Moderator

Re: OCL delegate evaluation [message #1049928 is a reply to message #1049902]

Fri, 26 April 2013 09:12

Eclipse User

Hi

allInstances() is strongly discouraged because it has potentially
horrendous cost and can usually be avoided easily.

You therefore have a vicious circle; since you should not use it
implementations make little effort to optimize it.

So expect any usage of allInstances() to give dreadful performance.

Regards

Ed Willink

On 26/04/2013 13:33, ModelGeek Mising name wrote:
> I have a very simple Ecore model contains 3 classes(Class1, Class2,
> Class3).
> Connection between classes are as follows
> Class1->Class2
> Class2->Class3
> Class1->Class3 (derived)
>
> Class3 has boolean attribute with derivation statement
> Class1.allInstances().class3->includes(self); // check myself is
> included in Class1.class3 property.
>
> consider i instantiate this ecore with one instance of Class1
> connected 5 instances of Class2 and each instance of Class2 is
> connected with 5 different instances of Class3.
>
> My question is related to evaluation approach. Will Class1->class3
> relation will be evaluated for every instance of class3 or
> Class1->class3 will be evaluated one
>
> import ecore : 'http://www.eclipse.org/emf/2002/Ecore#/';
>
> package temp : TEST =
> 'http://www.eclipse.org/mdt/ocl/oclinecore/tutorial'
> {
> class Class1
> {
> property class2#class1 : Class2[*];
> property class3#class1 : Class3[*] { derived volatile }
> {
> derivation: class2.class3->asSet();
> }
> }
> class Class2
> {
> property class1#class2 : Class1[*] { ordered };
> property class3#class2 : Class3[*];
> }
> class Class3
> {
> attribute available : ecore::EBooleanObject { derived volatile }
> {
> derivation: Class1.allInstances().class3->includes(self);
> }
> property class1#class3 : Class1[*] { ordered derived volatile }
> {
> derivation: ;
> }
> property class2#class3 : Class2[*] { ordered };
> }
> }
>
> Regards,

Re: OCL delegate evaluation [message #1053119 is a reply to message #1049928]

Thu, 02 May 2013 10:28

Eclipse User

Hi,

Thanks, i will avoid allInstances() operation and
Lets suppose, i have changed the derivation statement to avoid allInstances() as following
class2.class1->forAll(c1 : Class1 | c1.class3->includes(self))
Now again my question is same, will Class1->class3 relation be evaluated once or it will be evaluated multiple times depending on available Class3 objects?

import ecore : 'http://www.eclipse.org/emf/2002/Ecore#/';

package temp : TEST = 'http://www.eclipse.org/mdt/ocl/oclinecore/tutorial'
{
class Class1
{
property class2#class1 : Class2[*];
property class3#class1 : Class3[*] { derived volatile }
{
derivation: class2.class3->asSet();
}
}
class Class2
{
property class1#class2 : Class1[*] { ordered };
property class3#class2 : Class3[*];
}
class Class3
{
attribute available : ecore::EBooleanObject { derived volatile }
{
derivation: class2.class1->forAll(c1 : Class1 | c1.class3->includes(self));
}
property class1#class3 : Class1[*] { ordered derived volatile }
{
derivation: ;
}
property class2#class3 : Class2[*] { ordered };
}
}

Re: OCL delegate evaluation [message #1053166 is a reply to message #1053119]

Thu, 02 May 2013 15:23

Eclipse User

Hi

I don't really understand your question.

Having eliminated allInstances you have sensible constraints that should
be evaluated once for each instance.

Regards

Ed Willink

On 02/05/2013 15:28, ModelGeek Mising name wrote:
> Hi,
>
> Thanks, i will avoid allInstances() operation and
> Lets suppose, i have changed the derivation statement to avoid
> allInstances() as following
> class2.class1->forAll(c1 : Class1 | c1.class3->includes(self))
> Now again my question is same, will Class1->class3 relation be
> evaluated once or it will be evaluated multiple times depending on
> available Class3 objects?
>
>
> import ecore : 'http://www.eclipse.org/emf/2002/Ecore#/';
>
> package temp : TEST =
> 'http://www.eclipse.org/mdt/ocl/oclinecore/tutorial'
> {
> class Class1
> {
> property class2#class1 : Class2[*];
> property class3#class1 : Class3[*] { derived volatile }
> {
> derivation: class2.class3->asSet();
> }
> }
> class Class2
> {
> property class1#class2 : Class1[*] { ordered };
> property class3#class2 : Class3[*];
> }
> class Class3
> {
> attribute available : ecore::EBooleanObject { derived volatile }
> {
> derivation: class2.class1->forAll(c1 : Class1 |
> c1.class3->includes(self));
> }
> property class1#class3 : Class1[*] { ordered derived volatile }
> {
> derivation: ;
> }
> property class2#class3 : Class2[*] { ordered };
> }
> }
>
>
>

Re: OCL delegate evaluation [message #1053217 is a reply to message #1053166]

Fri, 03 May 2013 03:51

Eclipse User

May be i did not explain my question properly.

Let's suppose A1 is an integer attribute in Class "C" with derivation statement "2*2".
Now class "C" has two other variables A2 and A3 with derivation statements "A1 + 1" and "A1 + 2" respectively.

Now my question is, will A1 will be re-evaluated for both A2 and A3 as both are using it or A1 will be evaluated once and its evaluation results will be used by A2 and A3?

Cheers,

Re: OCL delegate evaluation [message #1053276 is a reply to message #1053217]

Fri, 03 May 2013 09:46

Eclipse User

Hi

It should depend on whether A1 is volatile or not.

Only an evaluator that takes a global optimization view will avoid the
multiple accesses for volatile variables.

Regards

Ed Willink

On 03/05/2013 08:51, ModelGeek Mising name wrote:
> May be i did not explain my question properly.
>
> Let's suppose A1 is an integer attribute in Class "C" with derivation
> statement "2*2".
> Now class "C" has two other variables A2 and A3 with derivation
> statements "A1 + 1" and "A1 + 2" respectively.
>
> Now my question is, will A1 will be re-evaluated for both A2 and A3 as
> both are using it or A1 will be evaluated once and its evaluation
> results will be used by A2 and A3?
>
> Cheers,

Re: OCL delegate evaluation [message #1053286 is a reply to message #1053276]

Fri, 03 May 2013 10:55

Eclipse User

So it means, if i set A1 to volatile(true) then it will be re-evaluated each time?

One more question, is Pivot able to follow the global optimization?

Cheers,

Re: OCL delegate evaluation [message #1053289 is a reply to message #1053286]

Fri, 03 May 2013 11:23

Eclipse User

Hi

On 03/05/2013 15:55, ModelGeek Mising name wrote:
> So it means, if i set A1 to volatile(true) then it will be
> re-evaluated each time?
I expect so. But I'm worried by your persistence. It seems you are
looking to exploit an unspecified behabiour.

The Impact Analyzer has alternate approaches to reducing re-evaluation
costs.
>
> One more question, is Pivot able to follow the global optimization?
>
The interpreted execution may always be naive.

The code generated execution has some optimizations nad will gain more,
but global constraint validations is a long way away.

Regards

Ed Willink

Re: OCL delegate evaluation [message #1053526 is a reply to message #1053289]

Mon, 06 May 2013 08:00

Eclipse User

Thanks!

Let say i have very complex OCL statement(having lot of recursive operation calls) for Class1.class3 property instead of very simple statement(mentioned in ecore).

Now if i do not use Class1.allInstance() then i need to write an opposite OCL statement to travse to Class1. It means again alot of processing cost.

I have discussed similar kind of problem where you advised my to have two derived properties with different OCL statements. One for Class1.class3 and other for Class3.class1. But my problem is that it will again have a lot of processing cost.

http://www.eclipse.org/forums/index.php/t/356903/

Is there any better alternative to allIntances() instead of writing the complex OCL statement two times?

Cheers

Re: OCL delegate evaluation [message #1053586 is a reply to message #1053526]

Mon, 06 May 2013 11:35

Eclipse User

Hi

The current implementation of unnaigable opposite navigation in the
pivot model uses the allInstnaces() cache.

For the benefit of QVT, I am considering an improved cache that can be
primed with the types for which allInstances is required and the
non-navigable properties that are navigated. This will allow a single
total model traversal to populate the caches for subsequent accesses.
This would probably suit your use case as well as QVT's.

If you're in a hurry, it is LazyModelManager that needs optimization.

Regards

Ed Willink

On 06/05/2013 13:00, ModelGeek Mising name wrote:
> Thanks!
>
> Let say i have very complex OCL statement(having lot of recursive
> operation calls) for Class1.class3 property instead of very simple
> statement(mentioned in ecore).
>
> Now if i do not use Class1.allInstance() then i need to write an
> opposite OCL statement to travse to Class1. It means again alot of
> processing cost.
>
> I have discussed similar kind of problem where you advised my to have
> two derived properties with different OCL statements. One for
> Class1.class3 and other for Class3.class1. But my problem is that it
> will again have a lot of processing cost.
>
> http://www.eclipse.org/forums/index.php/t/356903/
>
> Is there any better alternative to allIntances() instead of writing
> the complex OCL statement two times?
>
> Cheers
>
>

Previous Topic:	Condition in Figure Name
Next Topic:	Help requested for closure constraint.

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 01:26:35 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter