State tables for programs.

William Overington

Copyright 2001 William Overington

Monday 16 July 2001

This document contains a setting out of the functionality of the program from the document More programming with colour buttons. in tables.

This is done in a careful, logical manner so as to provide a method of setting out the functionality of programs for Astrolabe Channel. Thus, although this particular case study is for the program from the document "More programming with colour buttons.", the underlying method of setting out the state tables is presented with a far wider, long term view of expressing the functionality of programs for Astrolabe Channel.

The program from the document "More programming with colour buttons.", which is named ast00301, and is hereinafter referred to as the ast00301 program, has four possible user input events, namely pushing the red button, pushing the green button, pushing the yellow button, pushing the blue button.

The program can also exist in a number of states, each of which states may be denoted by the value in the variable storedobeycode.

Most of the time the ast00301 program will be idle, waiting for a push of one of the coloured buttons. One may happily think of the program being in the state that is designated by the value of storedobeycode whilst the program is idle.

So, for the ast00301 program one may say that the program is in one of the following states, state 1, state 51, state 52, state 53, state 54, state 1051, state 1052, state 1053, state 1054, state 2052. I have listed the states in numerical order, as this is convenient for looking them up in a table.

So, for the ast00301 program there are ten possible states.

There are four possible input events.

There are therefore forty (= 10 x 4) situations that need to be programmed.

An interesting aspect of the system is that the answer to the question as to what is a possible next state from an existing state is found by looking along a row of the table, whereas programming takes place by looking down the columns of the table, as the programming acts when an event is received, whereas the program is in some state or other at all times.

Although for the ast00301 program there are forty situations that need to be programmed, in fact many of these are identical once the choice of action has been made. In fact, for the ast00301 program nine actions need to be programmed as responses to a user input event. That is, one for each state that may be reached as a result of a user input event. The programmer also needs to program what is to be done at start up, that is, when state 1 is entered.

That is a total of ten actions, each being an action that is to be carried out upon entering a particular state.

In the ast00301 program, each user input event causes the program to move to a state different from the state in which the program is sitting when the user input event arrives.

In some other programs, however, it might be that a program does not change state after a button is pressed, yet carries out some action as a result of the button being pressed. This is regarded as reentering the same state. So the action table might be regarded as listing the action that is to be carried out upon entering or reentering a particular state. Once a state has been entered, the entry action having been performed, no further action takes place unless an input event is received. For the ast00301 program and for many other programs these input events will be user input events, though I make mention here that other input events are possible, such as from a timing system of some sort, but that is only for background knowledge at this time.

Here are the two tables for the ast00301 program. In some ways, expressing the functionality of the ast00301 program using these tables is perhaps somewhat excessive for such a small program. However, the importance of setting out these tables for the ast00301 program is that doing so provides a good example that will be of benefit when setting out more complicated programs.

Table listing the state to enter or reenter when a user input event is received.

present
state
red
button
pushed
green
button
pushed
yellow
button
pushed
blue
button
pushed
1 51 52 53 54
51 1051 52 53 54
52 51 1052 53 54
53 51 52 1053 54
54 51 52 53 1054
1051 51 52 53 54
1052 51 2052 53 54
1053 51 52 53 54
1054 51 52 53 54
2052 51 52 53 54

Table listing the action to take when entering or reentering a state.

State being entered Action to take.
1 Make the display black.
51 Draw a vertical left half orange bar.
52 Draw a vertical right half orange bar.
53 Draw a horizontal top half magenta bar.
54 Draw a horizonatal bottom half magenta bar.
1051 Make the display black.
1052 Draw a 16 cell orange and magenta chequerboard with orange top left.
1053 Draw a four cell orange and magenta chequerboard with orange top left.
1054 Draw a four cell orange and magenta chequerboard with magenta top left.
2052 Draw a 64 cell orange and magenta chequerboard with orange top left.

Let me clarify that whilst the program is within any particular state, the display on the screen may not always be the same as at some other time when the program is in that same particular state. Also, the values of stored variables may not be the same either.

For this ast00301 program for example, when in state 1, or state 1051, or state 1052, or state 1053, or state 1054, or state 2052, the display will always be the same as for every other occasion of being in that state.

However, for state 51, or state 52, or state 53, or state 54, the display will depend upon the route through the states that was taken before arriving at that particular state.

This is because of the action that was chosen to be programmed for when each state is entered.

If one now looks at the ast00201 program, which is in the document Programming with colour buttons. one may wonder how many states that program should be thought of as having. Certainly the use of the storedobeycode value had not been introduced at that time, so in that sense the ast00201 program may be thought of as having one state. If one were to make a program by adding the storedobeycode value to the ast00201 program then one might say that the program had five states, namely state 1, state 51, state 52, state 53, state 54: yet one might reasonably also say that that program would really only have one state because pushing a button would always have the same effect.

So let us have two possible sets of tables for the ast00201 program as hypothetically extended to have a storedobeycode value within it.

Which format to use? It depends on which is more convenient for the particular program that is to be described. Here first are the tables if one considers the program to have five states.

Table listing the state to enter or reenter when a user input event is received.

present
state
red
button
pushed
green
button
pushed
yellow
button
pushed
blue
button
pushed
1 51 52 53 54
51 51 52 53 54
52 51 52 53 54
53 51 52 53 54
54 51 52 53 54

Table listing the action to take when entering or reentering a state.

State being entered Action to take.
1 Make the display black.
51 Draw a vertical left half orange bar.
52 Draw a vertical right half orange bar.
53 Draw a horizontal top half magenta bar.
54 Draw a horizonatal bottom half magenta bar.

Here are the tables if one considers the program to have one common state.

present
state
red
button
pushed
green
button
pushed
yellow
button
pushed
blue
button
pushed
common
state
51 52 53 54

Table listing the action to take for various values of obeycode.

value
of
obeycode.
Action to take.
1 Make the display black.
51 Draw a vertical left half orange bar.
52 Draw a vertical right half orange bar.
53 Draw a horizontal top half magenta bar.
54 Draw a horizonatal bottom half magenta bar.

The former pair of tables is more general and has the possibility of easy modification if more complex behaviour is added. The latter pair of tables is simpler for a specific program, yet not of the general format.

Either way, I suggest that even for simply structured programs the used of the storedobeycode feature is desirable as it allows for straightforward extension of the program should that be desired. That would then mean that documentation of the response of the program to user input events could then be easily converted to the more general format should a program documented using the simpler format be extended.

 

Astrolabe Channel

Copyright 2001 William Overington

This file is accessible as follows.

http://www.users.globalnet.co.uk/~ngo/ast00400.htm