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.