Is a state machine the appropriate design when certain steps have to be followed in a clear order?

Question

Should the question be asked on programmers.stackexchange please just move it or notify me.

Imagine a program with the sole purpose to measure temperature with a sensor. There are two inputs, the sensor and the user (user can press an abort button).

When the program starts, certain conditions have to be met. Lets say the sensor must not have a temperature higher than x. If the condition is met, the program moves on to the next step, if not, the user is being told to make sure the condition is met.

Once it is met, the user is presented with the next thing to do, like "now stick the sensor into the object you want to measure". The program now measures. Assume this process requires more than a snapshot of the sensor but some rather complex filtering etc. Once certain criteria have been met, the user is being told what to do next.

At some point the user is being presented with the result. The user can decide at any point to abort the whole thing (go back to start or close).

Why im struggling with this is, what if at some point another step is introduced, or some step is removed but they will always follow the same workflow. Im in the beginning of a new program and i want to create a maintainable system.

Im not sure if a state machine is a good solution for this or if i completely misunderstood what a state machine is for or if there is a simpler solution.

Answer 1

Under a loose definition, any program you write would classify as a state machine. Your program changes state as it moves from one line of code to another, and as the variables change values.

When we talk about using a state machine as a design pattern, it usually involves separating out the main state transitions into separate modules (classes), where each object's fields store the state information that it's interested in, and its main execution method deals with the primary task of that current state, and then returns information about the next state that you should move into. A main control loop invokes each state's main execution method until a defined end-state is returned.

This pattern has the advantage of closely mirroring the structure of a visual workflow that you might create in Visio or some such. When each main state of the program has vastly different responsibilities, then this helps you to naturally group your code following the Single Responsibility Principle. And when each state can only move into one or two other states, you end up with relatively loosely-coupled code, which also helps to make things more maintainable.

The program you describe seems to be a good candidate for this pattern.

1. It sounds like it will be complex enough that you don't want to define the whole workflow in a single class or method.
2. It sounds like each state will allow you to move to a limited number of other states.
3. It sounds like the expected operations in each state are different enough to merit their own classes. If changes are made to the workflow, they will probably affect one or two states, and not the entire workflow, so it makes sense to split your classes up this way.

Answer 2

Yeah, any sequential process can be modeled as a state machine. The reason that EVERY sequential process is not implemented as a state machine is that usually (almost always) you can build a "smaller" machine (fewer conceptual flip-flops/variables and NAND gates/if statements, eg) using other techniques -- and "smaller" usually means "easier to understand".

However, because a state machine is so general, with a small number of well-defined rules, it is sometimes the best ("smallest" and easiest to understand) actual realization for a system with an irregular structure, especially if the structure is poorly understood and/or apt to need frequent modification.

Additionally, there are cases, in hardware at least, where devices such as a "programmable logic array" (PLA) implement a state machine rather cleanly -- more cleanly (and more cheaply) than a custom-designed integrated circuit.