[boost] Re: Finite state machine requirements

From: Andreas Huber (spam2002_at_[hidden])
Date: 2002-09-05 19:29:35

Gustavo,

> I did a brief look at you proposal (pity it doesn't have docs), and OMHO
it
> still feels like we have to do much tedious work. And I also think the
state

There are docs now, which should be sufficient if you are familiar with
state machines. What do you mean with too "much tedious work"

> machine becames to spread out and it's dificult to look at the resulting
> final code and recognize the original statemachine as a whole. But it's
much
> better than anything else I've seen so for, so keep up the good work.

I neither like the spread-out nature too much, because you'd have to do much
browsing to reverse engineer a given implementation. OTOH, I have yet to see
(I can't imagine it either) an approach which captures the whole design in
on place (a table?) while providing all the standard features like guards,
nested states, concurrent states...
Design tools like Rhapsody solve this problem by allowing you to hide the
nested states while you are looking at the outer states i.e. you can have
different views at the same thing. With a textual representation happening
to be executable C++ you cannot have different views (apart from header and
body), but you can partition your sources so that unnecessary details (e.g.
a transition 5 levels deeper than the one you're looking at) are hidden in
separate files...

I think in the end it boils down to the problem that there is no clean way
to transform a hierarchically nested graph that can easily outgrow the size
of even the biggest screen in a textual form that
a) is executable C++.
b) allows for different views (in one view you only want to see the states
and the transitions, in the other you want to see all the details like
guards, actions, ...).
c) fits on the same amount of space as the graph does.

Regards,

Andreas