Re-Engineering Your System for CASE
by Richard Green

We all know that bringing a 30 year old assembler based application into the 1990s is no easy task. However as the economic balance between hardware and software steadily weighs heavier on the software side, those applications become economic targets crying out for reform. To date, reforming such targets has involved the introduction of higher level languages in an attempt to reduce labor costs. The common drawback to the higher level language is that the complexity of the application is not reduced, just the number of hand written instructions.

One re-engineering solution is the introduction of a TPF based CASE tool, however such a tool is not yet commercially available. Another solution is to manually place simple reusable mechanisms into an existing system, each of which in its own way supports the gentle introduction of a second-generation CASE tool.

First generation CASE tools are those designed to support a system life cycle resulting in the generation of large customized runtime code modules. These CASE tools currently exist for non-TPF based system. Second generation CASE tools are yet to arrive, but will be based on efficient reusable chunks of processing interacting to support a global system view. This type of CASE tool is ideally suited to the TPF environment.

One such simple mechanism both able to support the future of CASE and reduce front-end application complexity is the Finite State Automaton. Although the Finite State Automaton currently exists in more scientific oriented environments such as UNIX, VAX, etc., until recently it has been a foreign animal to the TPF world. One thing very real about this mechanism, however, is that the quantity and complexity of a coded implementation within TPF is both small and simple regardless of the implementation language. The result, CASE tool or no CASE tool, is at a minimum fewer lines of code performing a greater portion of processing, resulting in a more consistent and stable environment with fewer people required for maintenance.

To help explain what a Finite State Automaton is, as well as the principles behind such a mechanism, it is presented here as an alternative to that 30 year old hierarchically based Lexical Analyzer that we are all familiar with, namely "UII"

Part I: TPF and the finite state automation
Have you ever wondered how those coin operated slot machines know how much you have inserted when there is only one slot through which you insert various denominations of coin? The answer to this question is a Finite State Automaton, or for the purpose of the article, a State Transition Processing mechanism.

In an attempt to explain such a mechanism, let's take the example of the coin operated softdrink machine. In our example a softdrink is priced at 20 cents.

Valid coin combinations are:

1. 20c
2. 10c + 10c
3. 10c + 5c + 5c
4. 5c + 10c + 5c
5. 5c + 5c + 10c
6. 5c + 5c + 5c + 5c

Each of the above coin combinations can be considered a rule for producing a valid combination of 20 cents. A State Transition Processing mechanism is able to apply these rules by ruling out combinations that are no longer valid. For instance, if the first coin is a 10c piece, we know that only coin strings 2 and 3 will produce a valid combination. State Transition Processing has the ability to recognize certain sequences of events (coins) and to transition to a processing state that limits future events (coins) to only those that are valid.

To represent the coin strings within a State Transition Processing (STP) mechanism the following states and events apply.

1. Waiting for coin (initial state). Valid events are:

• 20c, 10c and 5c.
• Processing: 20c transition to deliver drink state.
• 10c transition to 10c state.
• 5c transition to 5c state.

2. 5 cent state. Valid events are:

• 10c, and 5c
  
• Processing: 10c transition to 15c state.
• 5c transition to 10c state.

3. 10 cent state. Valid events are:

• 10c and 5c.
  
• Processing: 10c transition to deliver drink state.
• 5c transition to 15e state.

4. 15 cent state. Valid events are:

• 5c.
  
• Processing: 5c transition to deliver drink state.

5. Deliver drink state.

• Processing: deliver drink, transition to waiting state.

Notice that the further we progress through the STP mechanism, the more focused the valid combinations of coin become. To relate such a mechanism to a world that most of us are familiar with, imagine the following;

You sit down at a signed off reservation system terminal and commence a work session. Supporting this reservation system is a Finite State Automaton implementing a predefined set of states and events within a STP mechanism.

You sign on as a General Sales agent, pass agent/sine validation and transition into a world customized to a GS agent ready to perform any of your initiating actions. (While in this state, the reservation system knows that you are going to enter only transaction initiating actions for a GS agent).

The phone rings, you answer, and initiate the creation of a Passenger Name Record with the entry of a name item. You have now transitioned to a PNR pending state. (In this state the reservation system knows that you will be entering only those actions associated with the creation of a PNR). You enter a direct segment entry, the reservation system knows that a direct segment entry is a valid event for a GS agent in the PNR pending state, so hands it to the reserve application, waits for the reply (assumed to be valid) and transitions back to the current state.

Your customer asks you to retrieve another pre-existing reservation using a PNR address. You enter *RAQRSF to retrieve the reservation and receive an error message. (Once the primary action code of "*" was identified as an invalid event, the State Transition Processing mechanism did not Proceed any further resulting in the rejection of the input).

Note: At this Point the State Transition Processing mechanism's power is beginning to become evident. The STP mechanism did not need to look into the AAA to determine whether a PNR was under construction, neither did it have to invoke an application to validate the retrieve PNR action. The STP mechanism itself knew that the event retrieve PNR within the current state of processing (PNR Pending) was invalid.

The power of the finite state automaton
To carry the STP mechanism's policing power to an extreme, imagine you have a waitlist queue processing agent (agent type QP), whom you wish to restrict to just enough system activity that will permit the agent to perform his/her task.

1. Sign-on pending state. Valid events are:

• BSIA Sign-on
  
• Processing: BSIA- Validate agent/sine, transition to QP initial state.

2. QP initial state. Valid events are:

• BSO Sign-off, QC/12 (Display queue 12 queue count), 0/12 (Enter queue 12).
  
• Processing: BSO - The system transitions to the sign-on pending state. QC/12 -Display the queue count, the sys tem transitions back to the current state (QP initial state).
• Q/12 - Enter queue 12 to commence processing, the system transitions to the Q12 entered state.

3. Q/12 entered state. Valid events are:

• QC/12 (Display queue count)
• *R -(Re-display PNR)
• HK - (Change segment status)
  
• Processing: QC/12- Display queue count, system transitions back to the current state.
• *R - Re-display the current PNR, system transitions back to the current state.
• HK Update PNR segment, transition to Q/12 PNR modified state.

4. 0/12 PNR modified state. Valid events are:

• TTL - (Ticketing Time Limit)
• E -(End transaction)
  
• Processing: 7TL - Update PNR transition back to the current state.
• E - IF (last PNR on queue) transition to the QP initial state. ELSE (not last PNR on queue) transition to Q/12 entered state.

Obviously this example is enforcing extreme control on the QP agent's activities and in reality would not be a valid scenario. However the power of the Finite State Automaton is evident, permitting varying levels of control by introducing additional states with fewer and fewer permitted events. At all times during the QP agent example, the STP mechanism knows exactly where in the cycle of QP agent activity this particular QP agent is, or to phrase it differently, exactly the state of this QP agent's activity.

To place the State Transition Processing mechanism in perspective, it's UII with brains (knowing good from evil). This is a mechanism that has the ability to place a user transaction back into an application as if the current user action had been chained to the prior action with an end-item character.

The future of the finite state automaton
To take a quantum leap forward through the knowledge of an agent's state, the maintaining of a list of permissible events within that state and knowledge of how to “prime” an ECB prior to delivery to an application, we now have a generic chunk of simple processing with the intelligence to literally replace thousands of lines of inline code. Or to leap even further, by chunking the STP mechanism into smaller Parts that know such things as how to perform tasks, and what tasks to perform.

And by placing the knowledge of what tasks to perform into a maintainable database, our Finite State Automaton suddenly becomes a pliable interface between user and root application. Pliable in the sense that the “what to do” portion changes to meet future user requirements, not the “how to do” or the invoked root applications. And to think, all this from that coin operated softdrink machine in the lunch room.

Next...experimentation
No doubt there are those who are dis-believers and those who may be confused. If you are curious and are interested in experimenting with State Transition Processing, a PC based STP mechanism is available for US $20.00 plus US $2.50 shipping and handling from the following address: Pennelynn,Inc., 7221 Rustic Valley Drive, Dallas, TX 75248. Please state your diskette format preference (3.5 or 5.25).

This PC based model is segregated into How-To and What-To chunks resulting in that before mentioned pliable database driven environment. The database language is extremely basic and can be edited in a standard ASCII editor. A description of the database language is provided so you will be able to model your own TPF based reservation or financial functionality to draw your own conclusions as to the power and potential of a TPF based Finite State Automaton. Being database driven, you will also discover how simple it is to completely change your system processing at the drop of a hat (from a reservation system to a financial network to a softdrink machine in the wink of an eye plus 50 nanoseconds).

Three test case examples are included; A reservation processing scenario, a financial transaction scenario and our old friend, the softdrink machine. Along with each test is a diagrammatic representation of the State Transition Process flow.

More to come
Keep an eye on this space. Next, further steps to CASE within TPE The Art of Chunkology (Application Architecture), and the theory and practice of its implementation within an existing environment (examples included).