ability to estimate the feasibility of constructing a component to match a set of specifications. The opposite approach is for the designer who prefers to estimate the utility of the component that he has decided he can construct.
Clearly the blind application of just one of these approaches would be quite foolish. This is shown all too frequently in the case of designers who perhaps without realizing it are using an extreme ‘bottom-up’ approach, and are surprised when their collection of individually optimized components result in a far from optimum system. The ‘top-down’ philosophy can be viewed mainly as an attempt to redress the balance. In fact a designer claiming to follow the top-down approach, and specifying what a particular component is to do before he designs the component, can hardly avoid using his previous experience and intuition as to what is feasible.
Of the three projects under discussion, those by Parnas and Darringer, and by Zurcher and Randell lay most stress on the top-down approach. Zurcher and Randell in fact state that their aim is to defer decisions as to whether a given component be constructed out of software or of hardware until a late stage in the design process, when cost performance analyses can be made. In contrast, Dijkstra is concerned with the design of a multiprogramming system to run on an existing hardware system, so has at least presented the results of his design effort as if produced by a bottom-up approach.
The Place of Simulation in the Design Process
Since the computer profession insists on building systems which are more complicated than it can analyze mathematically, many designers have made extensive use of simulation. Probably the most successful uses have been for investigation of isolated problem areas such as storage interference or I/O buffering, and for detailed modelling of completed designs (see for example Nielsen [6]). Two of the three projects under discussion, namely SODAS and the Iterative Multi-level Modelling technique, involve the use of simulation. However in these projects simulation is regarded not as an adjunct to, but rather as an integral part of, the entire design effort.
In many design efforts it is difficult to identify exactly what is in the design at any given stage. Usually the partially completed design will consist of inaccurate and out-of-date documentation, unwritten ‘understandings’ between groups of designers, and in late stages of the design, partially constructed components (hardware or software). The intent of the above two projects is to keep the design so formal that at each stage in the design process it is capable of objective evaluation — being machine-executable is a very practical means of achieving this goal. The machine-executable partial design is, since it can obviously not be doing the complete job required of the system, therefore just a ‘simulation’ of the complete system. As design work progresses this simulation will gradually evolve into the real system.
With this view of simulation as part of the design process, there is no room for arguments that the design has not been simulated faithfully, that the simulation results are hopelessly pessimistic and in any case only apply to last month’s design, etc. The simulation is the design.
Future Problems
It would be easy to talk about the problems directly corrected with providing an effective tool for use by a large group of designers in simulating their system as the design progresses. However it is fairly clear that we have barely started to tackle the problem of finding an effective methodological approach to computing system design.
We are sorely in need of techniques for representing our partial designs so that at each stage the spectrum of possible future design decisions is made clearer, and the consequences of a particular choice can be more easily evaluated. (For example in programming the choice as to whether to make multiple copies of a given set of information, or to maintain just a single set and access it from different places by varying levels of indirection, is often very arbitrary). Similarly, if we could find some way of guiding designers as to what might be a good order in which to take decisions, this might have a considerable effect on the overall quality of our system designs.
Acknowledgements
The author’s initial work in this area was carried out jointly with Frank Zurcher, with much valuable advice and criticism from Carl Kushner, Meir Lehman and Hans Schlaeppi. The viewpoints, both on existing approaches