Program Design

Suppose you have been asked to write a program that opens a window, fills it with colors, and then keeps changing squares in that window. You already know roughly what the program should do, but you do not yet know how each piece will be coded. A natural first move is to write the plan down as a short list of big steps. The source example does exactly this: open a Mosaic window, fill the window with random colors, and then move around changing squares at random.

This list is a legitimate algorithm, but it is far too vague to turn directly into code. This article follows that plan from its rough form to a refined form, then shows how a program keeps track of where it is while it runs, and how to find the first step where a refined plan goes wrong. Along the way it explains why this kind of design work should happen before construction begins at all.

Three words in that definition carry most of the weight. A program is correct when it does what it is supposed to do, working when it actually runs, and well-written when its structure lets people read and maintain it. Program design is the part of this discipline concerned with planning how a program will be built so that those goals can be met before the code is written.

Within that discipline, software engineers analyze the problem before designing a program to solve it. Accepted and proven methods guide both problem analysis and program design. Analysis asks what the program must accomplish. Design asks how the program will accomplish it. Construction, which is writing the code, comes after both.

A common beginner belief is that building a complex program simply means sitting at a computer and composing the program directly. This belief overlooks the design work that must come first. A complex program should not be composed without prior design, and the order of activities matters: analysis and design come before construction rather than being attempted without preparation.

Each stage hands something to the next. Problem analysis produces an understanding of what the program must do. Program design turns that understanding into a plan of steps and parts. Construction turns the plan into code. Testing then checks whether the code meets what the analysis required. A stage that skips its predecessor leaves the next stage guessing.

The refined Mosaic loop moves around the window, so it needs a record of where it currently is. The author represents the current position with two int variables. currentRow holds the row number of the square where the disturbance is located, and currentColumn holds the column number. A variable holding information like this, which describes what the program is doing at a given moment, is one way of representing program state.

The mosaic has 16 rows and 20 columns of squares. Placing the current position in the center therefore means setting currentRow to 8 and currentColumn to 10. Those two values are the state the loop depends on. Each time the loop moves the current position, these values are the things that must change.

The method is to keep examining each step and asking whether it can be described more precisely. Each pass produces a slightly more detailed algorithm. This process of repeated, gradual elaboration is the heart of stepwise refinement. It also means you do not have to decide everything at once.

In the mosaic example the vague third step, move around changing squares at random, is still too loose to code. The author expands it. The program starts in the middle of the window and then repeatedly moves to new squares and changes their colors, for as long as the window remains open. The expansion adds two things the vague version lacked: a starting condition and a stopping condition. A refined loop usually needs explicit starting and stopping conditions of this kind.

Not every step in a refined outline should be pulled into its own piece. The useful question is whether a step describes a coherent task that can be handled on its own. Filling the window with random colors is a clear, self-contained job. It does not depend on how the program later moves around the window, so it can be worked on separately, and the author therefore writes a separate subroutine for it.

A subroutine is a separate block of code that carries out a specific task. The main routine can call it by name at the point where that task is needed. The source notes that subroutines make the main routine simpler and easier to understand, and that is the reason the mosaic author gives for pulling tasks out. The source already has one such subroutine, Mosaic.open(), which opens the window. The author then decides to write two more to carry out the two tasks inside the while loop, so the main routine reads as a short sequence of calls.

Notice what the source does not do. The starting position and the loop are refinements of the vague third step, and they are not separate subroutines in the source. Refinement produces details at every level, but subroutines are drawn only around units that stand on their own.

A refined algorithm can look correct line by line and still produce the wrong result. To find the fault, trace the state variables after each step and compare them with the trace you intended. The first step where the two traces disagree is where the refinement first departs from what was intended. The check is simple: the values of currentRow and currentColumn are the first place to look.