15 Design and
documentation : 1
The examples given in earlier chapters, particularly Chapter 12, have in a rather
informal way illustrated a design style known as "top-down functional decomposition".
"Top down functional decomposition" is a limited approach to design. It works very
well for simple scientific and engineering applications that have the basic structure:
get the input data
process the data
print the results
and where the "data" are something simple and homogeneous, like the array of double
precision numbers in the heat diffusion example. Top down functional decomposition
is not a good strategy for the overall design of more complex programs, such as those
that are considered in Parts IV and V. However, it does reappear there too, in a minor
role, when defining the individual "behaviours of objects".
Although the approach is limited, it is simple and it does apply to a very large
number of simple programs. So, it is worth learning this design approach at least as a
The first section in this chapter simply summarizes materials from earlier examples
using them to illustrate a basic strategy for program development. The second section
looks briefly at some of the ways that you can document design decisions. Here, simple
textual documentation is favoured.
TOP DOWN FUNCTIONAL DECOMPOSITION
As it says, you start the top with "program", decompose it into functions, then you
iterate along the list of functions going down one level into each to decompose into
Design and documentation
auxiliary functions. The process is repeated until the auxiliary functions are so simple
that they can be coded directly.
Note the focus on functions. You don't usually have to bother much about the data
because the data will be simple – a shared array or something similar.
You begin with a phrase or one sentence summary that defines the program:
The program models a two-dimensional heat diffusion experiment. e.g..
The program plays the game of "hangman".
and try to get a caricature sk