Super-states

[Emir Mulabegovic]

Hello,
Is there any guidelines how to handle super-states using current version of the SMC. The original version of SMC 1.x had support for these but I don't see it as of release 2.x. The closest I can find is a notion of maps and default transitions but I cannot nest maps and define entry and exist actions.

Any comments? I might be missing something to please educate me.

Thank you ..

EMir Mulabegovic

[Charles Rapp]

EMir,

I believe your are confusing my SMC with Bob Martin's which does have super-states. My SMC does support multiple maps. state entry/exit actions, transition guards and push/pop transitions but not super-states. Instead, I use the Default state and Default transtion definitions.

See http://smc.sourceforge.net/SmcFaq.htm#RipOff for why my and Bob Martin's SMCs are different.

Charles Rapp

[Ed K]

Hi,

How would you recommend implementing super-states using your SMC?  For example:
If I have two super-states called connected and disconnected.  Within each there are two states called monitoring and idle.  So I implement two maps, each with two states.  How do I make the SMC execute entry and exit functions when entering each map in addition to executing functions when entering a specific state within a map?

So, I'm kind of trying to do something like this syntax (that you don't support):

%map Connected
Entry { EnterConnectMap(); }
Exit { ExitConnectMap(); }
%%

Monitoring
Entry {StartMonitoring();}
Exit {StopMonitoring();}
{
sometransitions
}
Idle
{
sometransitions
}
Default
{
Disconnect[Monitor==true]   Disconnected::Monitoring    {}
Disconnect   Disconnected::Idle   {}
}
%%

%map Disonnected
Entry { EnterDisconnectMap(); }
Exit { ExitDisconnectMap(); }
%%

Monitoring
Entry {StartDiscMonitoring();}
Exit {StopDiscMonitoring();}
{
sometransitions
}
Idle
{
sometransitions
}
Default
{
Connect   Connected::Monitoring    {}
}
%%

So if I'm in the Disconnected::Monitoring state and I transition to the Connected::Monitoring state, the code executes the following function sequence StopDiscMonitoring(), ExitDisconnectMap(), EnterConnectMap(), StartMonitoring().

Thanks,
Ed.

[Charles Rapp]

I view maps as a way of logically grouping states. There is no entering and exiting a map only entering and exiting states. The only way to associate Entry/Exit actions with a map is by placing them on states. This is easily done for entering a map: always enter the map at one particular state, never transition to the state from within the map and put the "map" Entry actions into that state. Exit actions are problematic. Since Exit actions are executed when you leave the state and these transitions may both be inside and outside the map, there is no way to distinguish between the transitions and so the "map" Exit actions are taken even for internal transitions.

SMC is simply too established to be considering syntax changes like super states.

[oslsachem]

"There is no entering and exiting a map only entering and exiting states."
I agree with this and your vision and I don't mean that you implement maps as superstates.

"I view maps as a way of logically grouping states."
Naturally, but there may be more than one level of grouping states: there are states that are more closely related than others and they may be grouped again in a map inside a bigger map.

Having a map nested inside other map would provide an inner default state that would recognize the commonalities of a more selected group of states inside the bigger group of states.

"SMC uses the idea of multiple machines and pushing and popping states as way of breaking complicated behavior up into simpler parts."
That's the idea but doing that process more than once: breaking again each one of those simpler parts in even simpler parts.

"UML achieves much the same by grouping states into superstates. They may be equivalent in ability but I find the idea of pushing to a new state easier to understand because it is similar to the subroutine call."
The feature of nesting maps inside maps provides the availability of inner default states that would make your model more equivalent in ability to the HSMs (Hierarchical State Machines) but keeping your philosophy.
The idea behind this is providing the means for constructing layers of abstraction.

IMHO, the SMC model is at half way between Flat State Machines that:
-Tend to have replicated transitions: this is solved with default states and default transitions
-Experience exponential growth of states ("combinatorial state explosion") due to lack of support for concurrency. No idea how to address this problem
-Are "Flat" and thus do not provide the means for constructing layers of abstraction. This could be completely solved with deeper level grouping maps

and HSMs that eliminate these problems.

Therefore I hope this feature is viable because on the other hand the simplicity and clarity of the SMC scripting is really amazing :)