Title: Structure, Part 2

Author: Martin Moene

Date: 20 June 2010 08:57:00 +01:00 or Sun, 20 June 2010 08:57:00 +01:00

Summary: In the last part we spoke about structure in terms of ignoring detail. We now go on to formalise our thinking.

Body: 

Identifying structure

We can see from what's been said that it is not sufficient just to use a structured language to ensure a structured result. We must apply some thinking to the layout too. (Interestingly, it's just as easy to use languages like BASIC to produce structured code, once you understand the principles.)

We mean two things by structure.

1. Logical That is, the logical sequence of events that a program takes. Task D follows task C follows task B follows task A.


2. Presentation That is, the appearance of the printed statements for each task on the page. Page headings, indenting, use of variables names and whitespace fall into this category.

These two are completely independent. It would be possible to present a program :

         Task E
         Task A Task B
         Task D
         Task C

which was completely structured from the logical point of view; A calls B. B calls C and C calls D and E. But its use of variable names, indentation and layout give no clue as to the flow or structure.

Similarly, we could have a beautifully presented program:

         /* this is a nice heading */
         Task boil_kettle
         Task Fill_kettle
         Task boil_kettle
         Task fill_teapot
         Task make_tea
         Task fill_teapot

In this case the program logic is not present.

In a strict definition of the phrase, "structured programming" we mean logical structure. I would suggest however, that the two should be considered so closely related as to be inseparable.

Let's assume therefore, that by structure we mean; a logical breakdown of a program into hierarchical levels, where each level is presented in such as way that this logical structure is clear. We can now move on to consider more formally what structure may be taken to mean.

Let's look at our example again.

	Start
	Boil Kettle
	Kettle already boiled ?	End
Is kettle full ?	Is lid off ?	Take off lid
	Fill kettle
	Put on lid
	Plug in kettle
	Fuse gone ?
	Boiled ?	End
	End

Not a very structured looking flow chart, but why not? Everything is at the right level, we've asked all the right questions. True - but another golden rule for structured programs is so called single entry - single exit routines.

Why? Well for a start, consider trying to find out why this function wasn't working. Let's say it's ending at 'blown fuse' all the time and we don't know why. How has it got there ? Or consider a case where operation seems to stick at 'fill kettle'. There are an infinite number of times we might have looped around testing the lid and full conditions and no way of knowing how many, or how it eventually falls out at 'is lid off'.

Now consider this flow diagram for the same thing:

	Start Clear flags Reset TIMER
flag = boiled OK	Is kettle boiled ?
flag = timeout	TIMER out ?
	Open lid
	Full ?	fill
	Close lid Plug in
flag = fused	Fuse OK ?
	Increment TIMER
	End

In this case the task has a single entry and a single exit. Considering sub parts, each sub part also has a single entry and single exit. Only in the case of the first decision box does this appear to have two entry possibilities. The rule in this case is that such a situation would be catered for by a loop instruction. eg for(), do, while etc. (Never jump back with a goto !)

Translated to 'C', this might become a while construct.

eg    while(kettle not boiled)
          {
          :
          :
          } /* end of while */

Finding out what is going on is now quite straightforward. Now, if we are getting stuck at filling the kettle there is only one possible path which got us there.

Further, even although there may be no final use for it, including a variable such as 'timer' can be very useful. We can use this to check and monitor the progress of a loop and, as in this case, to detect an error condition. Notice that the use of a for() loop allows this variable to be handled and also provide loop termination.

eg    for (timer = 0; timer < TOO_LONG; timer++)
           {
           if (kettle == boiled)
               {
               flag = OK;
               break;
               }
           :
           :

Identifying, or coding, single entry and single exit tasks can become quite tricky with a more complex situation. It becomes easier with practice and familiarity with the language, however.

If loops are becoming nested and intertwined to such a degree that their purpose is becoming obscure then the time has come to create another level. In languages such as 'C', this further subdivision causes very little overhead resulting in very little increase in execution time.

Let's recap:-

To produce a structured program we must:-

• Concentrate initially on high level tasks.
• Recognise special cases.
• Produce simple, single entry/exit processes.

In the next part we'll look at moving from the problem being considered to starting to produce some code.

Notes: 

More fields may be available via dynamicdata ..