Re: [boost] [msm]entry point pseudo states and events (Re: [msm] orthogonal region and event consume)

Subject: Re: [boost] [msm]entry point pseudo states and events (Re: [msm] orthogonal region and event consume)
From: Takatoshi Kondo (redboltz_at_[hidden])
Date: 2012-05-31 03:59:32

Hello Christophe,

On Thu, May 31, 2012 at 3:44 PM, Takatoshi Kondo <redboltz_at_[hidden]> wrote:
> Hi Christophe,
>
> I changed the subject. Current topic isn't concerned with orthogonal
> region directly.
>
> On Thu, May 31, 2012 at 5:43 AM, Christophe Henry
> <christophe.j.henry_at_[hidden]> wrote:
>> Hi Takatoshi,
>>
>>
>>>> I read your ticket. Note that it's not UML-conform to have 2 transitions
>>>> originating from Entry1 (11-08-06.pdf §15.3.8 page 551).
>>>> After reading the Standard again twice, I realized that no example
>>>> provided
>>>> there displays any event on both transitions, which is really bad if it's
>>>> what they mean. I need to have a look at other literature.
>>
>>
>>> I read the section that you mentioned carefully. My interpretation of
>>> UML specification is different from yours.
>>> It's really difficult to explain my interpretation. So, I draw the
>>> diagram. See the attached file.
>>> Am I misunderstanding?
>>
>>
>> I will not pretend I have the perfect understanding of the Standard. Here's
>> my take. I also saw the sentence on top of your diagram and didn't fully
>> understand it when reading the Standard. There is also the following
>> sentence in the Standard:
>>
>> "An entry pseudostate is used to join an external transition terminating on
>> that entry point to an internal transition
>> emanating from that entry point".
>>
>> Which sounds logical because on your diagram the regions would not be
>> orthogonal.
>>
>> This means you cannot have transitions triggered by different events leading
>> to the entry point, not can you have different transitions leaving it. You
>> will need more entry points.
>>
>> Caution: I am far from being sure I got it right. That's why I precised my
>> definition of it in the doc. The implemented solution has the advantage that
>> you have the normal transition handling, including multiple transitions and
>> guards, events with data, base events, etc.
>> What you don't have is entry in multiple regions, which only the fork
>> currently provides, at the cost of lesser encapsulation.
>> Correct or not, this is the part of the Standard I chose to implement pseudo
>> entries.
>>
>> To be honest, I'm not of fan of pseudo entries. I prefer the vastly superior
>> solution of entering a submachine the "normal" way, then letting a
>> templatized, enable_if'd on_entry of the submachine do something clever with
>> the event at compile-time.
>
> Aha! I completely overlooked such approach. For example, we can choose the
> initial state in submachine using mpl and initial_state typedef
> instead of using entry_pseudo_state.
> I believe that I've understood your design decisions. I also think
> that following the UML standard blindly is not essential.
>
>>> My goal is to improve sub-machines' re-usability. If we want to reuse
>>> sub-machines in another state machines, sub-machines shouldn't know
>>> the outside information.
>>
>>
>> I agree but is it the case? I mean, if you send normal events to your
>> submachine through your outer machine, it also needs to know them, right?
>> I understand this as: "hi, I'm a submachine and I provide the following
>> entry points: Entry1 requires Event1, Entry2 requires Event2, etc.". A bit
>> like function parameters.
>
> I wanted to explain that as follows:
> "hi, I'm a submachine and I provide the following entry points: Entry1
> accepts any events. Because I don't care that. "
>
> Let me introduce more practical example that requires entry_pseudo_state.
> ScanFinger.png is a sub-machine. This sub-machine's primary purpose is
> to scan fingerprint. Before scanning, the sub-machine checks that
> finger is alive or not. But it's optional. To skip this check
> procedure, the entry point pseudo state ScanOnly is provided.
>
> FingerPrintRegister.png is the parent state machine. It uses
> ScanFinger as a sub-machine twice. In this scenario, alive checking is
> not required. So, the parent machine uses ScanOnly enty_pt. In another
> scenario, not mentioned here, might require the normal entry into
> ScanFinger to check the finger is alive.
>
> ScanFinger machine doesn't care about outer event. In
> FingerPrintRegister, the states RightScnning and LeftScanning have
> different incoming events for ScanOnly entry points. But any events
> are accepted. And then, it's not referred.
>
> Based on your suggestion, I introduce the base event class. As long as
>  the incoming event of entry point is not "none", this approach works
> good.
>
> struct AnyEvent {};
> struct Completed: public AnyEvent {};
> struct StartButtonPressed: public AnyEvent {};
> (See 39_FingerPrintExampleBaseEvent.cpp)
>
> If the incoming event is "none", the transition is stopped. Sometimes
> I want to use "none" as incoming event for entry point in the same
> sub-machine.
> And it is impossible that msm::front::none inherits user event classes
> such as AnyEvent.
>
> I'm trying to find better approach to solve the above problem.

I realized that I should use explicit_entry instead of entry_pseudo_state.
UML's entry point pseudo states should be mapped into
msm::front::explicit_entry.

For example, entry point pseudo state Entry1 in ScanFinger should be mapped
            struct Entry1:msmf::state<>, msmf::explicit_entry<> {};
not
            struct Entry1:msmf::entry_pseudo_state<> {};

There is no restriction that relates to Entry1's outgoing event :)

I forgot to rename Entry1 to ScanOnly. Please consider that they are same.

IMHO, the semantics of UML's entry point pseudo state look more like
Boost.Msm's explicit_entry than entry_pseudo_state.

I believe that I found the best solution of my problem.

Thanks,
Takatoshi

> Thanks,
> Takatoshi
>
>>> See my second mail in this thread. My solution using templates
>>> (entry_pseudo_event_template.cpp) requires the template parameters
>>> same as the number of entry point pseudo states in sub-machine. It's
>>> acceptable but if outgoing transition would be able to use none, I
>>> would remove the template parameters.
>>
>>
>>> In the above case, it is not required to support multiple incoming
>>> transitions to one entry pseudo state. Because the instances of
>>> sub-machine are different.
>>
>>
>> In this case, maybe I could interest you in defining a base event class for
>> Event1 and Event2, then making this base event the event triggering the
>> inside transition. Your first example would be changed this way:
>>
>>   struct BaseEvent {};
>>   struct Event1: public BaseEvent {};
>>  ...
>>  msmf::Row < Entry1,   BaseEvent, State2_2,   msmf::none, msmf::none >
>>
>>
>>
>> Regards,
>> Christophe
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost