stops on the programming side with the choice of a basic language to use, just as in conventional design practice you start with the engineers handing over a machine language. In this approach the designers can hand over a language at a higher level, but it need not pay any attention to the standards that exist in the field at the given time, it should just embody their best understanding of the tools, concepts and ideas of programming. If ultimate users use that language they would use it in the same way they would use an assembly language furnished by the manufacturer. At any rate, the systems designers can then hand over to compiler implementers something which is more complete and takes account of more problems before the languages demanded by the market place are implemented. The systems designers, on the other hand, hand over to the engineers a gross logical organization. Then logical detailing and circuit development takes place. Circuit development and logic nowadays are getting closely intertwined. With the programmers and engineers, there will be feedback going on for a considerable time, for months or even a year. But this is feedback into one place, the place where there is some central, authoritative, decision making. That is not at the time the machine has been designed; it is before you have anything at all.
There is one more source of feedback, besides the logic designers and compiler implementers, namely from the world of application. Whenever an application acquires a uniqueness, enormous size perhaps, or extraordinary complexity, that does not seem to fit into the existing languages, there are three paths of feedback, one is into the area of language design, which will take care of the question of expression. The other is into the area of logic design, because completely new logic devices may be required. Third, into the one point which is right at the top, the area of system design, where people are concerned with the organization of hardware and programs together.
In all this, we don’t have to wait for theory; in fact, unless you look at the problem in this way we will never get a theory.
4.1.3. RELATION TO MATHEMATICS
A few statements were made on the importance of mathematics in software design.
Perlis: Software systems are mathematical in nature. A mathematical background is not necessary for a designer, but can only add to the elegance of the design.
Bauer: What is needed is not classical mathematics, but mathematics. Systems should be built in levels and modules, which form a mathematical structure.
Kolence: (from On the interaction between software design techniques and software management problems’)
»At the abstract level, a concise mathematical notation is required by which to express the essential structures and relationships irrespective of the particular software product being implemented. For example, in the area of computer central processor design, the notation that satisfies this requirement is Boolean Algebra. The notation of Ken Iverson is an attempt to provide an equivalent notation for software.«
4.2. DESIGN CRITERIA
4.2.1. GENERAL DESIGN CRITERIA
Several general design criteria were stressed.
Perlis: I adopt as a basic principle of design that the user should be able, in principle, though perhaps not shown how by the manufacturer, to reach every variable which actually appears in the implementation. For example, in formatting, if the system uses a variable that sets margins, then that should be available. You may perhaps not find it in the first volume of system description, but you should come across it later on.
Letellier: (from The adequate testing and design of software packages)
»… it will always be found that extensions are to be made after some time of use and a software package must be thought of as open-ended, which means enough syntactic flexibility in the input and modularity in the implementation«