Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?

Subject: Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?
From: Krzysztof Jusiak (krzysztof_at_[hidden])
Date: 2016-02-15 05:08:08

On Fri, Feb 12, 2016 at 6:44 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 12/02/2016 12:20, Krzysztof Jusiak a écrit :
>
>> On Thu, Feb 11, 2016 at 12:28 PM, Vicente J. Botet Escriba <
>> vicente.botet_at_[hidden]> wrote:
>>
>>
>>> It seems that we need to inspect the UML2.1 documentation to check what
>>> is
>>> the specified behavior. If it is undefined, the argument in MSM would be
>>> valid.
>>>
>>
>> I checked UML2.5 specification and I have found "Transition execution
>> sequence" (14.2.3.9.6 / page 316).
>> However, there is no much info about the sequence there. It's mostly about
>> that exit of the main state has to happen before entry to the target
>> state.
>> I can't find anything about when guard/action should happen in the
>> sequence
>> :/ buy it's a long document so maybe it might be found somewhere?
>>
>> On page 377 I see an example where the order is clear
>
> xS11; t1; xS1; t2; eT1; eT11; t3; eT111
>
> Where xAAA means exit action on state AAA and eAAA entry on state AAA.
> ti are actions on the segmented transitions.
>
> Just before this example you can find
>
> *"Transition execution sequence **
> *Every Transition, except for internal and local Transitions, causes
> exiting of a source State, and entering of the target State. These two
> States, which may be composite, are designated as the main source and the
> main target of a Transition respectively.
> The main source is a direct substate of the Region that contains the
> source States, and the main target is the substate of the Region that
> contains the target States.
> NOTE. A Transition from one Region to another in the same immediate
> enclosing composite State is not allowed. Once a Transition is enabled and
> is selected to fire, the following steps are carried out in order:
> 1. Starting with the main source State, the States that contain the main
> source State are exited according to the rules of State exit (or, composite
> State exit if the main source State is nested) as described earlier.
> 2. The series of State exits continues until the first Region that
> contains, directly or indirectly, both the main source and main target
> states is reached. The Region that contains both the main source and main
> target states is called their least common ancestor. At that point, the
> effect Behavior of the Transition that connects the sub-configuration of
> source States to the sub-configuration of target States is executed. (A
> “sub-configuration” here refers to that subset of a full state
> configuration contained within the least common ancestor Region.)
> 3. The configuration of States containing the main target State is
> entered, starting with the outermost State in the least common ancestor
> Region that contains the main target State. The execution of Behaviors
> follows the rules of State entry (or composite State entry) described
> earlier. "
>
> I believe this is clear enough.
> 1 exits
> 2 action
> 3 entries

For me it is semi clear, but I do agree with your conclusion though.
However, there is no info about guards being executed before src state exit.
It might be implied by the statement that transition has to be enabled, but
I'm not sure about it.

>
>
> BTW. I have a question related to local transitions. Concept seems to be
>>>
>>>> nice but I don't undesrtand why exit/entry is NOT triggered only 'if the
>>>> main target state is a substate of the main source'.
>>>> Why this concept can't be more general? Wouldn't that be nice?
>>>>
>>>> s1 + e1 = s2 // exit from s1 / entry to s2
>>>> s1 ^ e1 = s2 // no exit from s1 / no entry to s2
>>>>
>>>>
>>>> A local transition will ensure that there is no exit on s1, but there
>>>>
>>> should be an entry in s2 if s2 is not s1.
>>> You will need to have a nested examples to see the difference between an
>>> external and a local transition.
>>>
>>
>> Yea, I do get it. Cheers. Do have any example when local transitions are
>> useful? I see some usage for them but I struggle really to find a really
>> good use case for them.
>>
>>
>>
>> Let say that you have a state S with two sub-states S1 and S2.
> While in state S, if you receive the event E1 you want to go to S1, but
> don't want to execute the exit of state S. However you want to execute the
> exit of S1 or S2.
>
> S ^ E1 = S1;
>
> Think of E1 as an event that interrupts whatever you were doing on S1 or
> S2.
>
>
Yea, yea I do get that. I was asking more about real life example. I mean,
what use case would require such behavior, because I can't think of any,
but I know there are some.
I'm asking because I don't have any experience with local transition and it
is hard to justify adding a new feature without a meaningful rationale.

Thank you for you feedback, it is very useful.

>
> Vicente
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>