Myths about state machines
Four common misconceptions about finite state machines
Myth 1: FSM state diagrams are too complex for real applications.
Section titled “Myth 1: FSM state diagrams are too complex for real applications.”
Not true: The correct way to implement a complex control system is by designing finite state machines that are simple enough to be well understood, with perhaps 10 to 20 states. Each of these is designed to fulfill a basic function, and groups of them are then supervised by other FSMs to build up a hierarchy of several levels.
Myth 2: FSMs are event driven, and this increases the number of states required.
Section titled “Myth 2: FSMs are event driven, and this increases the number of states required.”In a sense, that can be true, but the idea that an event is consumed when it reaches the FSM must be abandoned. Instead, make inputs that govern state transitions available to the FSM. For more information, refer to VFSM.
Myth 3: The transition diagram cannot express all the details of the application.
Section titled “Myth 3: The transition diagram cannot express all the details of the application.”
Not true: Using the VFSM method, it is possible to specify the complete description of the application’s behavior. “Complete” means that the specification does not require any coding.
Myth 4: Imprecise interpretations of the definition of the state machine.
Section titled “Myth 4: Imprecise interpretations of the definition of the state machine.”The state machine, as defined in automata theory, is the only convincing model that has proved its usefulness in industrial hardware and software control systems. For instance, constructions like state charts are interesting experiments but are not practicable in complex projects. (What is a finite state machine?)
StateWORKS demonstrates the true power of finite state machines for implementing complex behavioral requirements. You ought to use the FSM—it is a very powerful tool when correctly applied.