From: Iain K. Hanson (ikh_at_[hidden])
Date: 2004-05-28 08:00:25
On Fri, May 28, 2004 at 12:29:01AM +0200, Andreas Huber wrote:
> No, that would be wrong. UML requires that in a self-transition the exit and
> the entry action is called (see StopWatch for an example where such a
> transition makes sense). This is not the case for an in-state reaction.
What UML requires is not necessarily what is good for a generic FSM
framework. The UML model is IMHO over complex and probably broken.
An example is entry and exit actions for states. It is some what oxymoronic
that a single state should actually consist of three sub-states because
of entry and exit actions. The idea that they must be paired is particularly
strange as one of the most common uses of the concept in the networl
protocol work that I am familar with is prior to entering the idle stae
some initialisation work is necessary and prior to re-entering an idle
state from an exit event we want to do some clean-up. This whole concept
is much better modeled *IMHO* by transitory states. These have the advantage
that they do not have to be paired and they allow same/self-transition
to be a no-op which is a very common requirement.
Classical FSM's are a mapping from state/event pairs to behaviour and
transitions. The Idea that a state should maintain its own data and
thereby become stateful also seems to be bad modeling and against the
My comments are based, so far, are based on a breif reading of the
documentation and I plan to re-read it more carefully along with the
implementation and provide further feedback. My gut feel is that this
framework is too heavy weight and a one size fits all solution. Whereas
I think that an FSM equivelent to STL collections would be a better
There are two other approaches to FSM's that do not apear to be discussed in
the rationale; Herb Sutter, in an article hints at using boost::function
for FSM's and the GOF state pattern tals of using singleton, flyweight
states which are re-enterant and therefore offer exelent MT performance.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk