[Interest] Parallel state and local transactions issue

[Alessandro Lonardi]

Hi Mandeep,
thanks for the reply.
>
> From your state machine (SM) diagram it's not clear how GUI SM transitions
> from 'third' to 'first' state. Do you have a transition from third state to
> first state?
>
For both GUI and Controller parallel states, local transactions are used.
Local transactions are a particular type of transactions which means that
any sub-state contained in the source state can reach the target state, and
this is represented by the First state's incoming arrow. Its a
specification suitable to reduce the number of transactions, like parallel
states.
So, as you can see, for both GUI and Controller, the First state is
reachable from any parallel substate.
The problem is that whenever I trigger this transaction, the specific
parallel state exits (which may be correct), but even its container exits
(Parallel-container), causing exiting even for the other parallel state
(which is not a good behavior imho).

> Note, if you're exiting _any_ of the parallel SMs and then re-entering it
> (which seems to be your case), then ALL parallel SMs will exit and
> re-enter. This might explain why the controller SM is ending up in first
> state when you exit the GUI SM.

I think you're correct. Honestly, I don't like much this kind of behavior,
but that's exactly the only explaination I can get.
I wonder if Is that the desired behavior or not. I mean, I think that's not
aligned with UML State Charts specifications.

Thanks again,
Alessandro.

2014-10-13 18:40 GMT+02:00 Mandeep Sandhu <mandeepsandhu.chd at gmail.com>:

> From your state machine (SM) diagram it's not clear how GUI SM transitions
> from 'third' to 'first' state. Do you have a transition from third state to
> first state?
>
> Note, if you're exiting _any_ of the parallel SMs and then re-entering it
> (which seems to be your case), then ALL parallel SMs will exit and
> re-enter. This might explain why the controller SM is ending up in first
> state when you exit the GUI SM.
>
> HTH,
> -mandeep
>
>
> On Mon, Oct 13, 2014 at 3:32 AM, Alessandro Lonardi <
> alessandro.lonardi at edalab.it> wrote:
>
>> Hi,
>> I'm having a trouble with a state machine particular case (using Qt 5.3).
>> My state machine has two parallel macro-states. One is meant to model the
>> GUI evolution, the other one is meant to model the controller evolution.
>> Since in both states there's a complex structure, for practicability, I use
>> a local transition to reach some important states from any other states.
>> I've provided a simplified schematic at http://gdurl.com/l9km. As you
>> see for both Controller and GUI sub-states, the first state is reachable
>> from any other state.
>> Using this state machine structure, whenever a local transition triggers,
>> it will cause an exit() from the Parallel-container state, "resetting" the
>> other independent parallel state. For instance, with reference to the
>> proposed example, suppose to be in Controller's Second state and in the GUI
>> Third state. If the GUI local transaction is triggered (to reach its First
>> state), even for the Controller parallel state that happens, since the
>> Parallel-Container for some reason exits and re-enters in itself (which
>> should not happen since the local transactions doesn't start from it).
>> In order to make the thing working anyway, I've made a "wrapper" state
>> for each parallel state (i.e. GUI-wrapper and Controller-wrapper), which
>> intercepts the "exit", without involving the other parallel states into a
>> reset a caused by a global Parallel-container exiting and re-entering.
>> I think that this is an issue worthy of discussion.
>>
>> Hope that helps, and thanks in advance for any clearance.
>> Alessandro.
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20141014/a5cbccf3/attachment.html>