< Prev Next >
22
NATO SOFTWARE ENGINEERING CONFERENCE 1968
4. Design

4. DESIGN
4.1. INTRODUCTION
4.1.1. SOURCES OF TECHNIQUES
Part of the discussion was concerned with the sources of the right attitude to design. The suggestion that designers should record their wrong decisions, to avoid having them repeated, met the following response:
McClure: Confession is good for the soul —
d’Agapeyeff: — but bad for your career.
A more general suggestion was made:
Naur: (from The profiles of software designers and producers)
»… software designers are in a similar position to architects and civil engineers, particularly those concerned with the design of large heterogeneous constructions, such as towns and industrial plants. It therefore seems natural that we should turn to these subjects for ideas about how to attack the design problem. As one single example of such a source of ideas I would like to mention: Christopher Alexander: Notes on the Synthesis of Form (Harvard Univ. Press, 1964)«
4.1.2. NEED FOR HARDWARE BASED ON PROGRAM STRUCTURE
This point was elaborated in two contributions.
d’Agapeyeff: (from Reducing the cost of software)
»Instead of crude execution of absolute code, allow the machine to use a higher level intermediate code (perhaps through interpretation via a fast read-only store) in order to:
1. increase run time checks and therefore program reliability;

2. provide more facilities for program development;
3. reduce the problem of conversion to new machines;
4. allow all communication with the programmer to be in source language.
Another point is that programming would be simplified if certain processes could be declarative rather than procedural. This is an extension of the idea of channel command words. It appears this could be applied to much of I/O, file processing and checking. The functions must, however, operate in a uniform manner, indicate their progress (e.g. by separate clocks) and allow for dynamic alteration of the declarations.
Finally we need more redundant information, available in the machine, safely recording what has just happened (e.g. last operand addresses and contents, etc.) so that there can be greater automatic retrieval after an error. The current tendency for programs to be arbitrarily thrown off must be reversed.«
Barton: In design you have to start at the level of organization of programs and machines, with the design of hardware and software together. This must be in the hands of one or a few individuals and will require a kind of general purpose person. What do these persons know? As far as programming is concerned they can only know what the state of the art is, what can be learned from existing systems, the extrapolations that people have made on these, and what happens in languages, in operating systems, in control programs. They are not expert programmers or experts in things like syntax directed compilers. They must be people who are interested in synthesizing, extracting essentials out of what has been learned. On the hardware side they are not hardware designers either, but they are concerned about putting together the gross logic of machines. These are the only parts of the design that can be done by just a few people. These people have to rely on two other groups. Their decision making