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

[Sean Harmer]

Hi,

On 19/04/2010 15:24, K. Frank wrote:
> On Mon, Apr 19, 2010 at 5:26 AM, Sean Harmer
> <sean.harmer at maps-technology.com>  wrote:
>> 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 think it was mentioned in a talk at Developer Days last year but it is 
quite plain to see that at least the concept of states and transitions 
mapped into QtQuick and Qml by looking at the examples available in the 
Qt 4.7 development branch on gitorious.

I have not had a chance to look at the internal implementation yet but I 
suspect that there is a QStateMachine lurking in there somewhere. Maybe 
one of the devs could confirm?

> 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.

Indeed, we started out with a big mess! Now we have a few custom states, 
guarded transitions, and events together with a small amount of plumbing 
code. It works a treat.

> 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?

Yes, we were already using Qt for our object model so layering the 
behaviour on top of the existing objects was very easy to accomplish 
using the QtStateMachine framework.

>> 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.)

Thanks for the link, I'll take a look.

>
>> ...
>> 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.

Oh, I wasn't trying to advocate such an approach to the OP. I was merely 
saying that it is possible to do it that way. Personally I like the idea 
of hiding the use of a state machine away inside of a concrete class.

I have to admit that I am fairly new to the world of state machines and 
the associated programming paradigm, but for some problems it has been 
invaluable. It does take a while to shift your mindset to thinking about 
problems in the right way to tackle it using a state machine. It is akin 
to shifting from procedural programming to OO programming.

I am now reviewing some of our other projects to see if they could 
benefit at various levels from a state machine.

All the best,

Sean