[Qt-interest] Qt State machine framework

[Mandeep Sandhu]

Hi Frank,

First of all, thanks for taking the time to write such an elaborate
mail and explaining your point of view.

The reason my questions might look out of place is because I have not
given the complete context of my problem (though I've explained it in
different thread on this list).

I'm writing an FSM to emulate the behaviour of a h/w. The h/w vendor
provides lib's to access the underlying h/w which has a propensity to
go into undesirable states if the right command is not given to it.
And the lib also does not guard us from such erroneous behaviour. (I
can't discuss details of the h/w for the usual reasons. Hope you
understand)

So after experimenting a lot with the h/w we finally have an idea of
what works an what doesn't.

Based on this, I've designed my FSM. So the FSM acts as a layer of
protection in that if an event/command is illegal in a particular
state, then it's never issued to the h/w. The FSM tells me, when in a
particular state, what all events/transitions are possible.

Initially I thought of implementing the SM as a "flat" FSM, but when I
read the Qt state machine framework, they talked about using HSMs
(heard of it the first time then!). Then as you and No'am pointed out
I read about HSMs and tried to fit my SM in that model. I ended up
with a pretty neat SM, with considerably less number of
states/transitions (compared to the flat SM approach).

I'm implementing my own "psuedo-driver" for this h/w as a plugin. This
driver maintains the SM and talks to the h/w using the vendor's lib.
Application developers use this plugin to talk to the h/w.

Now coming back to the need for knowing the previous state.

This is mostly for an application developer. The SM itself has no need
to know the previous state.

I think it'll be helpful for the app developer to know where the SM
transitioned from, especially since we can can land up in the same
state from 2 different source states (obviously on 2 diff events at
different times). Some of these events are generated internally (from
an app's point of view). Just knowing the current state might not
suffice. OR it might, if we assume that it's the apps responsibility
to keep track of state transitions (I just tell it whenever a new
transition happens and the new state).

Also, I believe that concepts like history states/ state groups etc
are internal to the SM (since it's used only as a way to express the
SM). From the outside, even if I transition to state group (using
history or default state) I still should be able to find out what
child state I'm in, since that really represents the true state. The
caller is totally ignorant of the state group concept.

Similarly I need to know what's the _current_ state the SM is in. So
if I've transitioned back to to a history state, I'm interested in
knowing what child state it really represents. I've yet to try the API
No'am suggested, so can't say for sure whether that'll return me the
child state the SM is in or the state group/history state.

Hope that explains my requirements and need to go for a SM.

Regards,
-mandeep

On Wed, Mar 24, 2010 at 7:31 PM, K. Frank <kfrank29.c at gmail.com> wrote:
> Hello Mandeep -
>
> You may be trying to do something that doesn't best fit the
> state-machine approach.
>
> On Wed, Mar 24, 2010 at 5:21 AM, Mandeep Sandhu
> <mandeepsandhu.chd at gmail.com> wrote:
>> On Fri, Mar 12, 2010 at 11:03 AM,  <noam.rosenthal at nokia.com> wrote:
>>> Hi Mandeep
>>> Actually both things are supported!
>>>
>>> 1. http://doc.trolltech.com/4.6/qabstracttransition.html#triggered: A signal that gets emitted when a transition is triggered. You can then query the tranistion's source/target properties.
>>
>> Actually this approach has a problem if transitioning to/from a super
>> state or a history state. I'm actually interested in emitting
>> transition info for lowest level child states.
>
> Could you tell us a little about the concrete problem you are tying to solve?
> Maybe there's a better way to map it into the state-machine framework, or
> maybe a non-state-machine approach would be better.
>
>> So eg if I return to a history state, my signal should tell which
>> child state was entered and what was the source state. If the source
>> state had children, then i need info about which child state was left.
>>
>> I can think of recording states on my own (using the onEntry/onExit
>> fxns). Is there any other way?
>
> I'm not knowledgeable about the Qt state-machine framework.  Perhaps
> No'am could give you an informed answer.
>
>> Thanks,
>> -mandeep
>
> I generally don't like answer the question "How do I do X?" with "You
> don't really
> want to do X."  (Especially on lists like this.)  It obviously doesn't
> answer the
> question, and it's kind of a cop-out.
>
> But it does seem like you're trying to do something that doesn't fit perfectly
> the state-machine philosophy.
>
> In a very coarse, high-level sense, just as object-oriented programming is
> about decoupling, encapsulation, and information hiding, state-machine
> programming is to.
>
> A core idea in state machines is that whether you transition from state
> A to C or from state B to C, once you're in state C, you don't care where
> you were before.
>
> A core idea in hierarchical state machines (HSM's) is that from the outside
> of a substate (or the history pseudo-state), you don't care about the internal
> details of the substate (or about the actual state to which the history state
> returns).
>
> Following these principles is part of how you get decoupling and information
> hiding.  (Of course, with real problems you can't always follow such principles
> blindly.  I often find myself changing "private" to "public" in c++ classes.)
>
> It seems that the way you're approaching your problem is pressuring you
> to violate some of the state-machine principles.  Now in the real
> world, sometimes
> this is the best thing to do.  But if you would like to let us know a
> little more
> about the practical problem you're trying to solve, perhaps we might have some
> ideas about how to better map your problem into the state-machine framework
> or be able to suggest a different programming paradigm that would be a better
> fit for your problem.
>
> Good luck.
>
>
> K. Frank
>
>
>>> 2. http://doc.trolltech.com/4.6/qstatemachine.html#configuration: QStateMachine::configuration(), returns a set of current states.
>>>
>>> Hope this answers your question,
>>>
>>> Regards
>>> No'am
>>> ...
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>