Deterministic Finite State Automata

First be cautioned, what is described below is to understand the state machines in Litium Studio, and more or less overly simplified. For more information use Finite State Automata (Wikipedia).

To understand it, first lets take a look at the previous diagram again.

Above diagram shows three, deterministic, finite, state automata (Automata is the plural for automation).
Following is an explanation of what each term means.

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 we provided in "Practical perspective" article. The whole process changed a ordinary person browsing the ecommerce site into a customer Not only that it transfered an amount of money from one account to another and at the same time it moved product items bought from one location (warehouse) to another location (customers home).

Now you can see, we have 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, we will come to learn about that later under "related state transitions".

Finite

This means that this machine is going to process its input in "Finite" number of steps: the number of steps can be counted and counting will end, without going to infinity. In ECommerce order processing, this will usually be few steps. 

Deterministic

What this means is, if the conditions are the same, however how many times we are repeating the processing, this machine will produce identical results. For example, if we set a condition; if the user doesn't accept the delivery, the delivery is treated as "Failed". So, for all orders, irrespective of anything else, if customer doesnt accept, the delivery will be in a "Failed" state!.

Programming Implecations

Why we went into great detail defining and explaining the DFSA is to show you the programming implecations 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 out put in a limited number of steps. If you do not keep this principle when programming, you might end up coding a indefinite loop!. 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 different output at different times. So, the machine you program should be deterministic. Because of 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.