Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » [OCLinEcore] Evalutaion difference beween OCL console and invariant in the model
[OCLinEcore] Evalutaion difference beween OCL console and invariant in the model [message #1011829] Wed, 20 February 2013 05:24 Go to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 270
Registered: August 2009
Senior Member
Hello,

I have an OCL constraint that I have tested on a dynamic instance of my EMF model via the OCL console (in my dynamic instance, right-click on an element and select "Show OCL console"). The OCL constraint works as expected in the console, but if I add this constraint in my domain model, the constraint doesn't work as expected anymore.

This is my constraint:
components->at(1)->closure(linkedComponents)->size() = components->size()


This is my complete domain model:
package components : components = 'platform:/resource/Components/model/components.oclinecore'
{
	class Container
	{
		property components : Component[*] { ordered composes };
		property firstComponent : Component { ordered };
		property lastComponent : Component { ordered };
		property paths : Path[*] { ordered derived transient volatile };
		invariant allComponentsConnected: 
			components->at(1)->closure(linkedComponents)->size() = components->size();
	}

	class Component
	{
		attribute name : String[?] { ordered };
		property linkedComponents#linkedComponents : Component[*] { ordered };
	}

	class Path
	{
		property components : Component[*] { ordered };
	}
}


For the same dynamic instance, the constraint is violated when I validate my dynamic instance and the constraint is not violated if I use the OCL constraint.

I attached the ecore file and the dynamic instance of my domain model which produces the problem: if you validate the root element, the validation will fail, but if you select the root container and paste the OCL constraint in the console: this will give true as a result (which is what I expected).

Is this a bug ?

Thank you
Re: [OCLinEcore] Evalutaion difference beween OCL console and invariant in the model [message #1011881 is a reply to message #1011829] Wed, 20 February 2013 07:16 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4035
Registered: July 2009
Senior Member
Hi

I get consistent results in my development workspace and on Juno SR1.

Validation of Container fails.
Evaluating:
self
Results:
Container

Evaluating:
components->at(1)->closure(linkedComponents)->size() = components->size()
Results:
false

Evaluating:
components->at(1)->closure(linkedComponents)->size()
Results:
4

Evaluating:
components->size()
Results:
5

Evaluating:
components->at(1)->closure(linkedComponents)
Results:
Component comp2
Component comp3
Component comp4
Component comp1

I'm not sure how you got a 'pass'.

However the results are counter-intuitive since in your graph everything
is reachable from everywhere.

The OMG specification sections, which I wrote, have a contradiction:

11.9.1 excludes the source initially, but accumulates all reachable
nodes, including the source if it is transitively reachable. [This
section is a painful read - lexical substitution- Ugh! with the
introduction of lambda expressions this cleans up.]

7.7.5 (non-normative) accumulates source and reachable nodes but then
provides examples demonstrating the explicitly include the source in the
results.

Eclipse OCL is excluding the source at all times; hence 4 rather than 5
results for you. https://bugs.eclipse.org/bugs/show_bug.cgi?id=401302
raised.

Perhaps

components->closure(linkedComponents).linkedComponents->asSet()

gives you a workaround

Regards

Ed Willink

On 20/02/2013 10:24, Cedric Moonen wrote:
> Hello,
>
> I have an OCL constraint that I have tested on a dynamic instance of my EMF model via the OCL console (in my dynamic instance, right-click on an element and select "Show OCL console"). The OCL constraint works as expected in the console, but if I add this constraint in my domain model, the constraint doesn't work as expected anymore.
>
> This is my constraint:
> components->at(1)->closure(linkedComponents)->size() = components->size()
>
> This is my complete domain model:
> package components : components = 'platform:/resource/Components/model/components.oclinecore'
> {
> class Container
> {
> property components : Component[*] { ordered composes };
> property firstComponent : Component { ordered };
> property lastComponent : Component { ordered };
> property paths : Path[*] { ordered derived transient volatile };
> invariant allComponentsConnected:
> components->at(1)->closure(linkedComponents)->size() = components->size();
> }
>
> class Component
> {
> attribute name : String[?] { ordered };
> property linkedComponents#linkedComponents : Component[*] { ordered };
> }
>
> class Path
> {
> property components : Component[*] { ordered };
> }
> }
>
> For the same dynamic instance, the constraint is violated when I validate my dynamic instance and the constraint is not violated if I use the OCL constraint.
>
> I attached the ecore file and the dynamic instance of my domain model which produces the problem: if you validate the root element, the validation will fail, but if you select the root container and paste the OCL constraint in the console: this will give true as a result (which is what I expected).
>
> Is this a bug ?
>
> Thank you
Re: [OCLinEcore] Evalutaion difference beween OCL console and invariant in the model [message #1011906 is a reply to message #1011881] Wed, 20 February 2013 08:18 Go to previous messageGo to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 270
Registered: August 2009
Senior Member
Ed, thanks again for the reply Smile

Evaluating:
components->at(1)->closure(linkedComponents)
Results:
Component comp2
Component comp3
Component comp4
Component comp1


This evaluation seems very strange to me and I think what you get here are not the expected results: the element on which the closure is applied is the first element in the components list (so "comp1"). Component "comp5" is linked to component "comp4" so it should be listed in the results, which is not the case here (in my environment it is correct). I could agree that "comp1" would be out of the results (however, it is added later on because other paths point to it, so I do not fully agree). But I don't agree about the fact that "comp5" is not in the results (or I didn't understand the closure operation).

In my environment (Juno SR2) the result of the evaluation is:
Evaluating:
components->at(1)->closure(linkedComponents)
Results:
Component comp2
Component comp1
Component comp3
Component comp4
Component comp5


So, "comp5" is in the results as expected (and "comp1" is in the results too).

If I understood the closure operation properly, then the expected results would be the results I have on my environment in the console. Also, the order in which the components are listed is coherent with the recursion followed by the closure operation (the order of the elements on your environment is really strange).

However, as I said, I only have those results in the console, not in my domain model (there the results are probably the same as yours but I can't list the elements; I checked whether the collected elements are equals to 4 and this is true, so I suppose the results are the same as yours).

After a bit of investigation I realized this: the closure operation stops completely whenever it encounters an element which has already been added to the closure (so all active recursions are simply exited). It means that if you chain 7 components after each other (like in the attached file), the closure will return only 3 components (and I expected all elements in the result).

Could you try on the attached example which result you have ? Anyway, there is clearly a problem there since in the console I have all 7 elements and in the validation (so calling the OCL embedded in my model) I only have 3 elements. I can be wrong about my interpretation of closure, but at least the results shouldn't be different there.

Thanks
Re: [OCLinEcore] Evalutaion difference beween OCL console and invariant in the model [message #1011933 is a reply to message #1011906] Wed, 20 February 2013 09:34 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4035
Registered: July 2009
Senior Member
On 20/02/2013 13:18, Cedric Moonen wrote:
> After a bit of investigation I realized this: the closure operation stops completely whenever it encounters an element which has already been added to the closure (so all active recursions are simply exited). It means that if you chain 7 components after each other (like in the attached file), the closure will return only 3 components (and I expected all elements in the result).
>
Yes. My conclusion that it was a source problem was premature. As you
say the actual problem is premature recursion termination so the
behaviour depends on Set ordering, which explains the indeterminacy.

Changing ClosureIteration.java line 55 from

if (!accumulatorValue.add(value)) {
return accumulatorValue;
}

to

if (!accumulatorValue.add(value)) {
return null;
}

seems to be all that's required. Now just need a JUnit test and I can
release the fix.

Regards

Ed Willink
Re: [OCLinEcore] Evalutaion difference beween OCL console and invariant in the model [message #1011972 is a reply to message #1011933] Wed, 20 February 2013 11:05 Go to previous messageGo to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 270
Registered: August 2009
Senior Member
Great Smile

Thanks for the support !
Re: [OCLinEcore] Evalutaion difference beween OCL console and invariant in the model [message #1011990 is a reply to message #1011972] Wed, 20 February 2013 11:26 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4035
Registered: July 2009
Senior Member
Hi

https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-tools-kepler-master/385/artifact/MDT-OCL.downloads/mdt-ocl-Update-tools-I201302201053.zip

has just built.

Regards

Ed Willink


On 20/02/2013 16:05, Cedric Moonen wrote:
> Great :)
>
> Thanks for the support !
Re: [OCLinEcore] Evalutaion difference beween OCL console and invariant in the model [message #1014867 is a reply to message #1011990] Tue, 26 February 2013 11:07 Go to previous messageGo to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 270
Registered: August 2009
Senior Member
Hi Ed,

I installed the update and this seems to fix the problem.
However, I also now get stack overflow exceptions when I try to open the model with the OCLinEcore editor.

Furthermore, some of my constraints are now also broken and after debugging, I also realized that it is because of a stack overflow exception being thrown internally. Unfortunately, for the later case, I can't provide any more detail.

However, for the first case (they are maybe related), I can send you my model file. But since it contains confidential information, I can't post it publicly. Would this be possible to send it to you via mail so that you have something on which to debug ?

Thanks,
C├ędric
Re: [OCLinEcore] Evalutaion difference beween OCL console and invariant in the model [message #1014876 is a reply to message #1014867] Tue, 26 February 2013 11:18 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4035
Registered: July 2009
Senior Member
Hi

On 26/02/2013 16:07, Cedric Moonen wrote:
> However, for the first case (they are maybe related), I can send you
> my model file. But since it contains confidential information, I can't
> post it publicly. Would this be possible to send it to you via mail so
> that you have something on which to debug ?
Certainly; ed_at_willink.me.uk

Regards

Ed Willink
Previous Topic:[OCLinEcore] Invariant evaluation only after validation of another invariant
Next Topic:AST AbstractVisitor get occurances of operation arguments in operation's body
Goto Forum:
  


Current Time: Fri Aug 29 06:32:40 EDT 2014

Powered by FUDForum. Page generated in 0.13747 seconds