Deterministic finite state automata

First be cautioned, what is described below is to give a basic understanding of the state machines in Litium, and more or less simplified. For more information, see Finite-state machine on Wikipedia.

State automata

This means they are "state machines", machines that transform an input to an output. Imagine the above diagram as a schematic for a machine that work on something and transforms it to something else. To understand it better, look at the example in the Practical perspective article. The whole process changed a random person browsing the e-commerce site into a customer. It did not just transfer an amount of money from one account to another, and move the items bought from one location (warehouse) to another (the customer's home).

There are three different inputs (order, payment and delivery) and three different outputs, which is the reason for drawing three machines, rather than just one. Of course the machines are not independent of each other, learn more about that in Related state transitions.

Finite

This means that this machine is going to process its input in a finite number of steps, which means that the number of steps can be counted and the counting has an endpoint, it will not go on forever. In e-commerce order processing, this will usually be just a few steps. 

Deterministic

This means that if the conditions are the same, no matter how many times the process is repeated, this machine will produce identical results. For example, if we set the condition that if the user doesn't accept the delivery, the delivery will be treated as Failed. Hence, for any orders where the customer does not accept the delivery, irrespective of anything else, the delivery will be in a Failed state.

Programming implications

Why we went into great detail defining and explaining the DFSA is to show you the programming implications when programming state transitions.

1. The number of transitions and also the number of states you build should be finite. That means, the machine should be able to produce the output in a limited number of steps. If you do not keep this principle when programming, you might end up coding a indefinite loop. The best way to avoid loops is to keep your state machines small and simple.
2. The code you produce should always produce the same set of transitions and therefore going in the same execution path under identical conditions. If not, you will see a different output at different times. The machine you program should be deterministic. For this reason, you should not have any class local variables in the state transition builder classes. Also, the input condition for a state should not depend on a class local variable.