State Machine/Class Granularity

Say I have a state machine with two superstates. I'll call them S1 and
S2. Both superstates have two substates. I'll call them S11, S12 (for
the S1 superstate), S21, and S22 (for the S2 superstate).

If I were to put this state machine into a class using a switch
statement, it might look like this:

switch(superstate)
{
case S1:
switch(substate)
{
case S11:
// ...
break;

case S12:
// ...
break;
}
break;

case S2:
switch(substate)
{
case S21:
// ...
break;

case S22:
// ...
break;
}
break;
}

Putting aside the various approaches for implementing state machines
(I'm only using a switch statement here because it makes my question
easier to describe), I'm wondering if this is the right granularity for
a class/state machine. Instead of the above, I could divide the class in
two, putting one superstate in one class and the other superstate in
another class. Each class would have an initial state in which it would
ignore all events except the event(s) that causes the superstate it
represents to become active.

In other words, the class representing S1 would have an initial state in
which all it would do is wait for the right event. We could call this
state Waiting or Disabled. Once having received this event, it
transitions to an active state (formerly one of the substates described
above). When this happens, the other class receiving the same event goes
back into a waiting state. Only one of the classes is active at any
time.

I've been using this approach over the past few days, and it seems to
work well. Instead of one large class with two modes, for lack of a
better term, I have two small classes with a well defined, single
responsibility. The cohesiveness seems better. At any rate, I guess my
more general question is that if you are taking an approach of equating
classes with state machines, what is the right granularity? Say you have
a large state machine, how do you divide it up into classes?



.

Relevant Pages

  • Re: State Machine/Class Granularity
    ... I am not a fan of Harel state machines because they almost always ... Beyond that, unless you are writing a code generator, the switch ... FSAs because a state machine state should not depend in any way on ... putting one superstate in one class and the other superstate in ...
    (comp.object)
  • Re: Software architecture using C for mid-range PIC.
    ... switch { ... fFirstCall is true only on their first call. ... Each finite state machine then looks something like this: ... static FsmStateT FsmState; ...
    (comp.arch.embedded)
  • Re: Horror! Using goto statement in finite state machines?
    ... finite state machine" was code simplicity to write, read, debug, modify. ... on a team that worked on a large complex state machine. ... Similarly a simple approach with switch is: ... I know some people do not like the introduction of a state variable, but others do not like the use of goto. ...
    (comp.lang.c)
  • Re: Trying to have a state-machine one the page (newbie)
    ... Anyhow my goal is to have a state machine on one page which from certain results or any other working way will step into a new case called from that same page. ... but even then I do not fall into my case switch as expected, and this is what I'm trying to achieve. ... Still investigating. ... You'll have to replace references to $_POST ...
    (alt.php)
  • Re: state machine?
    ... So, mechanically, does a state machine only require a while loop and a case? ... This is often implemented using a Shift Register. ... " Does each case in the switch box correspond to a state?  ...
    (comp.lang.labview)