|
|
|
| Re: Derived attributes differ randomly [message #660986 is a reply to message #660778] |
Tue, 22 March 2011 14:45   |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Michael
Your observation that results change randomly is a little vague.
Do you mean that you get a different result each time you load the
model, rather than while you are using the model.
You OCL includes a number of Sets, flatten, asSequences, and firsts. I
suspect that you may be experiencing unpredictable results from the
accidental ordering of hashCodes which may not be repeatable.
You might find the OCL easier to understand and the problem easier to
debug by introducing intermediate properties.
transient, volatile etc should not have an effect.
You didn't specify which versions you were using. If you're using the
new Interactive Xtext OCL Console, you could be using the new evaluator
that fixes a number of corner case evaluations for the stable
observation, and the old LPG driven evaluator for the unstable observ
ations.
I suspect that any further investigation will require a full repro.
Regards
Ed Willink
On 21/03/2011 07:53, Michael Schorer wrote:
> Hi,
>
> my derivation are rather complex. But I'll try to explain them.
> I don't use allInstances(), though.
>
> The main concept of the statements is to compute a tree structure from
> a set of so called integration steps, based on a non-containment
> reference named"has_components". The children of each integration
> step are the steps which have a subset of the integration step's
> components.
> The integration steps are contained in a so called schedule.
>
> children:
> in_schedule.consists_of_integration_steps->excluding(self)-
> >select(step:vi_integration_step|self.has_components->includesAll(step.has_components)
> and self.has_components->notEmpty())
> ->reject(step:vi_integration_step|
> in_schedule.consists_of_integration_steps->excluding(self)-
> >excluding(step)->exists(step2:vi_integration_step|
> step2.has_components->includesAll(step.has_components) and
> step2.has_components->symmetricDifference(step.has_components)-
> >size() <
> self.has_components->symmetricDifference(step.has_components)- >size()))
> ->asOrderedSet()
>
> The reference parent is the opposite of the children reference.
> parent:
> in_schedule.consists_of_integration_steps->select(children-
> >includes(self))->asSequence()->first()
>
> The last derived reference is the one which causes the said behavior.
> The components have dependencies on other components. The derivation
> shall find the integration steps which has the components to satisfy
> the dependencies. Therefore it collects all components on which the
> step's components are depending inside of the step's tree branch and
> selects the "closest" step which satisfies the dependency.
>
> dependency_on_step:
> self.has_components->collect(comp:vi_general_component|comp.has_dependency_on-
> >reject(comp3:vi_general_component|
> comp3.is_part_of_integration_step->includes(self))->
> collect(comp2:vi_general_component|comp2.is_part_of_integrat ion_step-
> >asSet()->intersection(self->closure(parent)->asSet())
> ->sortedBy(comp2.is_part_of_integration_step->closure(parent)-
> >size())->first() ))->asBag()->flatten()
>
>
> I hope I could describe it well enough..
>
> Best regards
> Michael
|
|
|
| Re: Derived attributes differ randomly [message #660994 is a reply to message #660764] |
Tue, 22 March 2011 15:47 |
Michael Schorer
Messages: 6
Registered: June 2010 |
Junior Member |
|
|
Hi Ed,
I am using OCL version 3.0.2. I am sorry but I don't know if this is the new Xtext Interactive Console (It only says Interactive OCL when I'm opening the console).
The error is only present when I open the model and look at its derived references. When I use the OCL interactive console and compute the values with the same ocl statements, that I have in my ecore, I will ALWAYS get the correct values.
Is there any information on how the order of the computation of the derivations is performed? Can it be influenced?
In my case, if the derivation which depends on a second derivation's values is performed before the second derivation, it would compute wrong values, wouldn't it?
Simple example (OCLinEcore style):
class my_object {
property a_reference : my_third_object[?];
attribute X : ecore_0::EInt[?] {
derivation:
a_reference->size();
}
}
class my_second_object{
attribute Y: ecore_0::EInt[?] {
derivation:
a_second_reference->size()+self.X;
}
property a_second_reference : my_object[1];
}
The attribute Y will only have the correct values, if the derivation for X is computed first, right?
Best regards,
Michael
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 3.82713 seconds
] 
Search
Help
Register
Login
Home
