This post is an interlude from the mainline discussion of Model-Based Design. Today I will discuss the differences between flow charts and state machines. The most fundamental difference between the two is that a state machine has knowledge of the past based on its current state(s).
The southern snow problem
To give an example, if you live, or have lived, in the southern part of the United States you are aware of the syndrome known as snow panic. The south can be an pleasant place in the winter filled mild walk able days (see left hand state “EverythingIsFine”) but once snow is predicted they enter into the right hand state “OhMyGodSnow” and huddle up “SafeAtHome” until either the snow is gone or food runs out. All of this logic is captured in 4 states and can be evaluated in a with a maximum of 2 operations [(noSnow==FALSE)&&(food<=deltaFood)].
By contrast the flow chart version of this has a average of three operations and manually maintains a state (wasInSnow).
But how does it scale….
When I first learned C programming my instructor provided the rule of thumb “Never nest If/Then/Else statements more than 3 deep.” That rule of thumb still holds for State Charts (MAAB: NA_0038) and ladder logic . Fortunately both can be “nested” in logical containers known as Subcharts. Recommendations for when to sub-chart can be found here,MAAB: NA_0040.
So which do I use?
Like most engineering questions the answer is “the correct one.” Remember the way to tell which is correct is ask yourself, do past states matter, then a state chart may be the way to go. If everything is based on current information then use flow chart logic. In the end favor clarity over dogma.
In the next post I will return to adoption time line: exploration phase part II.