[Qt-interest] The State Machine Framework - do's and don'ts

[K. Frank]

Hi Sean -

On Mon, Apr 19, 2010 at 5:26 AM, Sean Harmer
<sean.harmer at maps-technology.com> wrote:
> Hi,
>
> On 19/04/2010 09:33, Mihail Naydenov wrote:
>> Thank You for your answer, I will give it a thought. (It really needs :))
>> ...
>> Also Im really curious if they consider implementing fully state driven GUI (where every, easy-to-spot state of controls is indeed implemented as private state) and if its feasible one to implement with the current SM.
>
> Well this is exactly what the new QtQuick and QML stuff does under the
> bonnet. As I understand it, QtQuick uses a QStateMachine to manage a
> QGraphicsScene and it is all declared using the Qml language.

That's very interesting to hear.  I found some Qt blog postings about QtQuick,
but nothing very detailed.  Do you have any more information about the state
machines under the hood, maybe some links to white papers, or something?

I would like to understand better what they're doing here, and it would be
really cool to hear some feedback from the QtQuick developers about how
things went with this approach, and what kind of mileage they got.

> So yes it is possible to control an entire application from a state machine.
>
> In our particular case at work, we are using a QStateMachine to control
> interactions with some hardware devices (over TCP or serial). This has
> simplified our code so much it is not even funny.

Good for you!  It sounds like you are working in one of those application
domains where state machines are very much the right tool, and if you
try something else, you end up with a big mess very quickly.

Out of curiosity, why did you pick the Qt state-machine framework in
particular?  Were you already using Qt for the application, or were you
looking just for a state-machine framework, and Qt's made it to the top
of your list?

> Plus it has the nice
> side-benefit that the entire bahvioural aspects of the system can now be
> shown very compactly in a state chart.

I wouldn't really call that a side benefit.  In some sense it's one of the key
ideas of state machines, or maybe better said, one of the key factors that
determine whether state machines would be a good approach to a problem.

The idea is that when objects have behavior -- or more precisely dynamic
behavior -- state machines can be helpful.  This point of view has been
advocated by Shlaer and Mellor -- you could take a look at their book
"Object Life Cycles: Modeling the World in States."  (Out of print?)

   http://search.barnesandnoble.com/Object-Life-Cycles/Stephen-J-Mellor/e/9780136299400/

(I don't much like the book -- it's very prescriptive.  It has kind of
a "Here's the
only right way to write programs." attitude about it.  But I think
there is wisdom
in some of their design philosophy, if not in the detailed methodology they
propose.)

> ...
> So for the above we have a class that uses a state machine that contains
> a number objects each of which themselves contain a state machine. This
> is just the partitioning of functionality/behaviour that works for us.
> You could however, easily imagine implementing all of the above as one
> large state machine.

But why?  I think it's fine to have separate several state machines that
interact with one another.  (The statecharts crowd seems to have a
tendency to advise putting everything into one giant state machine.
"One state to rule them all...")  After all, in object-oriented design, you
wouldn't try to cram a bunch of separate classes into one giant class.

> ...
> My advice is to try it out in some real applications.

> ...
> Good luck,
>
> Sean

K. Frank