this task, and provided means of accessing a large data base, and facilities for on-line program development. It worked reasonably well, but as the project has evolved, people have used the on-line system less and less, and are now starting to switch to a batch system running on the machine for which the military system is being developed. There could be many reasons for this — unreliability of the on-line system was certainly one. However, I believe that another was that people preferred to spend their money developing software which would be useful for development, for the computer for which they were developing the military system.
Cress and Graham: (from Production of software in the university environment)
»The danger of writing a special piece of software to expedite production is that we have a project within a project. Often the inner project is more interesting and it is certainly more volatile in design. Thus it is never really complete, as its effectiveness is not known until it is used. This makes it extremely difficult to make deadlines and stick to them.«
5.3.2. CONCEPTS
The above title has been chosen, perhaps somewhat arbitrarily, for a report on a discussion about the basic techniques or ways of thinking, that software engineers should be trained in.
It is perhaps indicative of the present state of software production that this topic was one of the most difficult to report on.
Ross: I would like to present some ideas of mine merely as a starting point for this discussion. The hope is that we will trade ideas on the actual techniques whereby we might work toward the evolution of a true software engineering discipline and technology. The three main features of my view of what software engineering and technology are all about are:
1. The underlying theory or philosophy, about what I call the ‘plex’ concept.
2. How this translates into the ideas put forward by McIlroy on software components — for which I use the term ‘integrated package of routines’.
3. How you systematically compose large constructs out of these smaller constructs — for which I use the term ‘automated software technology’.
A ‘plex’ has three parts: Data, Structure, and Algorithm (i.e. behaviour). You need all three aspects if you are going to have a complete model of something — it is not sufficient to just talk about data structures, though this is often what people do. The structure shows the inter-relationships of pieces of data, and the algorithm shows how this structured data is to be interpreted. (For example a data structure could stand for two different things if you didn’t know how to interpret it.) The key thing about the plex concept is that you are trying to capture the totality of meaning, or understanding, of some problem of concern. We want to do this in some way that will map into different mechanical forms, not only on different hardware, but also using different software implementations. An ‘idealised plex’ is one in which the mechanical representation has been thrown away. This is done by degenerating the data and structure aspects of a plex — not throwing them away — but, putting the entire discussion into the algorithm domain. Thus for example one avoids talking about data, by using read and store procedures which do whatever handling of the data is necessary. Such a pair of procedures is called an ‘idealised component’, which represents a data item (and the ‘box’ which contains it) that is accessed by the procedures. An ‘idealised element’ is composed of idealised components glued together, so that they can’t be taken apart, and is represented by a create-destroy procedure pair. Finally an ‘idealised plex’ is a set of ‘idealised elements’ which have been hooked together into a whole structure, with many inter-relationships. So one needs further procedures for adding elements to the plex (a growth function) and what we call a ‘mouse’ function, which is one which can be used to trace relationships, and to apply a procedure to the elements visited during the tracing. These idealised facilities allow me to talk abstractly about any object I wish to model. To actually use these ideas one needs mechanizations of the facilities. For example, a read-store procedure pair could be handled as subroutine calls, or could be compiled, if the compiler had been given declarations of the data structures being used.