Model Your System With State Machines |
 |
 |
 |
| Written by Graham Stoney | |||
|
Event driven systems can be modelled using state machines. Complex systems may involve one or more interacting state machines in order to fully describe their nature, and a complex state machine can also be hierarchical in nature. As with any design hierarchy, knowing when to stop decomposing is a matter of experience and pragmatism. State machines are often depicted in state diagrams, like this one for a simple push-button switch:  The main entities on the diagram are the States (represented by the circles), the possible Transitions (the curved lines with the arrow heads), the Events (“Push” in this case) and the Actions (shown below the corresponding Event). The machine stays in the current state until an event occurs which can cause a transition from that state, and the machine only responds with some form of action in response to such an event. Events can have arbitrarily complex boolean conditions associated with them, and can be externally generated like a user pushing a button, or internally generated like a timer expiring. A system modelled with multiple interacting state machines can give rise to very complex behaviour; this complexity should reflect the complexity of the problem domain rather than the designer's inability to simplify his solution. State diagrams can represent a lot of information about the allowable events and actions a system has, and are extremely useful in design reviews. However, I have seen their intricacies glossed over by engineers who thought of them as just-another-picture. These tended to be the engineers who did design-on-the-fly, didn't like having their work reviewed and often put critical system design choices off until coding time. For example, reviewing the state diagram above we find that both transitions are triggered by the same action, and there is no feedback from the states to indicate which state is currently active. The user needs to know beforehand what state the system is in, which has negative human-factors implications. For a safety-critical application, this may be unacceptable. One mitigating design choice would be to add an indicator lamp, with associated actions to illuminate the lamp when the switch is on, and extinguish it when the switch is off. A Failure Modes and Effects Analysis may consider the case where the indicator lamp fails, misleading the user to think the switch is off when in fact it is on and may find that this has disastrous consequences. All this may lead to the use of a toggle switch as a better choice. One of the key things to consider when reviewing state machines is the impact of unexpected events on a state. In safety-critical system, it is important that events which the designer considers “can never occur” in a given state are handled without nasty consequences such as a deadlock or hazardous condition for the user. Although this example is quite trivial, these sort of choices is the stuff that engineering is all about. Top-level states in a system are often referred to as “Modes”; like a DVD recorder might be in “Record” mode or “Playback” mode. Anything over 10 states on a state diagram starts getting too complex to represent meaningfully; 15 or more is really pushing it. In this case, I recommend combining the most closely related states and decomposing each of them hierarchically on a separate diagram. I have heard engineers say that it was “too hard” to draw the state diagram because there were just too many states or transitions to represent. This suggests to me that they hadn't found a good way to model the behaviours of the system yet, and were doing design-on-the-fly. If you can't draw a state diagram to model your system, you probably don't understand it fully. Another approach to state machines is to use a state table instead of a diagram. A state table is a tabular list of all the states, along with the allowable events, actions and new transition states. The two are exactly equivalent, but each has pros and cons. If your model is not well thought out, a diagram will show the resulting mass of spaghetti-like transitions immediately where as this isn't as obvious in a table. On the other hand, tables can be easier to review since it can be more obvious when the impact of an event on a given state hasn't been considered. Engineers often have a preference for one or the other; I'm a more visual type so I like the diagram, but tables do the job just as well. This is only the barest of introductions to state machines. There are many tools around for drawing and automating state diagrams, mostly based on UML. Some of these will generate code for you straight from your state diagram or table. I can't say I've ever used them, since I've generally been using very low level tools like assembler; but they are probably worth checking out. One example I've been recommended are the open source tools from Quantum Leaps. Social Bookmark this page:         
|