|
| Re: [OCLinEcore] Evalutaion difference beween OCL console and invariant in the model [message #1011881 is a reply to message #1011829] |
Wed, 20 February 2013 12:16   |
 Ed Willink
Messages: 7669
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 13:18 |
Cedric Moonen
Messages: 274
Registered: August 2009 |
Senior Member |
|
|
Ed, thanks again for the reply 
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 #1014867 is a reply to message #1011990] |
Tue, 26 February 2013 16:07 |
Cedric Moonen
Messages: 274
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
|
|
|
|
Powered by
FUDForum. Page generated in 0.06021 seconds
] 
Search
Help
Register
Login
Home
