Re: [boost] New library in Vault: Msm (Meta State Machine)

Subject: Re: [boost] New library in Vault: Msm (Meta State Machine)
From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2008-10-22 15:11:45

Christophe,

We're now discussing so many different things at once that I think the main
point in all this hasn't gotten the attention it deserves. In this post, I
will therefore only answer where I feel that you did not understand my
arguments, lost the thread or asked a question. Follow up to this thread if
you must. As far as I'm concerned, we're done here. If you are still
interested in discussing the main point then please answer in the following
post:

<http://thread.gmane.org/gmane.comp.lib.boost.devel/181515>

>> Whether you'd want to work with entry & exit points in the alarm-beeps
>> case is a matter of taste. I personally wouldn't bother simply because it
>> seems unlikely that it can be reused anywhere.
>
> Do you mean your example is irrelevant or that reuse is not important?

Of course I meant neither, at least not in the generality you are
suggesting. I meant that *in* *this* *particular* *example* reuse seems very
unlikely and so it is a waste of time to work with entry and exit points as
they only introduce additional complexity without offering any gain.

>> To reach a definite verdict in this particular example we'd need to
>> define
>> first what coupling in a state machine actually means. To my knowledge,
>> nobody has done that so far.
>
> Do you need more than common sense to know that if  you need to see inside
> of a state machine you have coupling?

It's too bad that you've snipped the context because you seem to have lost
the thread. Here's how we got here:

<original-context>
>>>> OTOH, the transition triggered by x can only be made non-state-
>>>> boundary-crossing by introducing a guard, which is IMO less concise
>>>> than allowing for the transition as shown in the chart.
>>>
>>> This is a matter of taste. I personally prefer this as it reduces the
>>> coupling of the system.
>>
>> To reach a definite verdict in this particular example we'd need to
>> define first what coupling in a state machine actually means. To my
>> knowledge, nobody has done that so far.
>
> Do you need more than common sense to know that if  you need to see inside
> of a state machine you have coupling?
</original-context>

Now, if you have a look at the statechart we were discussing
<http://www.codeproject.com/KB/cpp/Statechart.aspx> then you see that the
transition triggered by x is going from an inner state to its direct outer
state. I don't see how your argument of "... that if you need to see inside
of a state machine you have coupling?" applies because here nobody needs to
see inside anything.

>> Just to make sure we're not talking past each other: With "entry/exit
>> states" I guess you mean "entry point pseudostate" and "exit point
>> pseudostate" as defined in UML?
>
> Yes, are there other possibilities?

You are using undefined terminology so I had to make sure ("entry state" &
"exit state" are not mentioned once in the UML standard).

>> You have read the whole paragraph, right? I quote it here for clarity:
>>
>> <quote>
>> A submachine state is semantically equivalent to a composite state. The
>> regions of the submachine state machine are the regions of the composite
>> state. The entry, exit, and behavior actions and internal transitions are
>> defined as part of the state. Submachine state is a decomposition
>> mechanism that allows factoring of common behaviors and their reuse.
>> </quote>
>>
>> Note the first sentence. What is unclear here?
>
> Well, first why there are 2 terms. They are not equal but equivalent. So
> what is the difference?

I've mentioned it before: UML submachines are basically composite states
with entry & exit points thrown in. They are *not* fully fledged state
machines, as the design of Msm seems to suggest.

> And what does it have to do with the subject?

See above.

>> Exactly. However, IIUC, at the moment Msm only supports a single entry
>> point and a single exit point, which IMO also makes reuse harder than
>> necessary, see below.
>
> Again I have to disagree. When a program runs, it calls functions, which
> call other functions, etc. Now if you read a book of Model Driven
> Development, you'll probably find inside that a UML diagram and code are
> two
> views of the same model. And now we have it. You don't mind having a
> single
> entry point in a function, right? Why is it a problem in a diagram?

A composite state is not a single function. Rather, it consists of many
functions (entry actions, transition actions, exit actions) that are called
sequentially. Even without entry/exit points, it lies in the very nature of
a composite state that the sequence in which those actions are called is not
always the same. The only guarantee you have is that the entry action of the
composite state is called first and the exit action is called last. Between
those, the number of calls made to other actions and their sequence can vary
widely depending on what events are processed. So why is it a problem when
the composite state can be entered through multiple different entry points?
Doing so only changes in what order the other actions are called but the
entry/exit action still comes first/last.

>> Firstly, let's be clear that any reasonable semantics definition for FSMs
>> (e.g. Harel, UML) absolutely requires that an entry action of a composite
>> state/submachine is called when the composite state/submachine is entered
>> and it doesn't matter at all how the state is entered (ordinary
>> transition, state-boundary-crossing transition). The same goes for the
>> exit action when the state is left.
>
> Unfortunately I understood it the other way and had to go to great lengths
> in the
> example you gave me to avoid the entry of the composite. Maybe I'm not the
> only unreasonable and this brings confusion?

Not sure why you call yourself unreasonable. What/Who else is unreasonable?

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.