We have tried to demonstrate by these examples that
it is almost always incorrect to begin the decomposition
of a system into modules on the basis of a flowchart.
We propose instead that one begins with a list of
difficult design decisions or design decisions which are
likely to change. Each module is then designed to hide
such a decision from the others. Since, in most cases,
design decisions transcend time of execution, modules
will not correspond to steps in the processing. To
achieve an efficient implementation we must abandon
the assumption that a module is one or more subroutines, and instead allow subroutines and programs
to be assembled collections of code from various
modules.
