A Finite State Machine (aka FSM) is to software what a Karnaugh map or Venn diagram is to hardware: It contains current state information, transition rules by which a state changes, and often times a history trail as well.

It is extremely useful in synchronizing asynchronous events. One example would be controlling the importing of payables and receivables information into the general ledger after the postings have been made and an intermediate filtering operation has occurred. Another good example is data and process synchronization in an n-tier environment.

A very simple, but also very good, example of FSM usage is the sequence required to place a phone call. The handset must be taken off hook before a dial tone is detected, and the phone numbers must be sequentially entered before a connection is made, at which time communications can commence. Each step is done only if the preceding step was successfully completed.

The FSM object works in conjunction with a database (SQL, Paradox, DBF or Advantage), and while the data organization is fairly standardized, the transition rules are most often customized to meet specific requirements. Separating the structure from the rules makes the design and implementation much easier than the large efforts that are often required to build these.