Krysia Broda, Susan Eisenbach, Hessam Khoshnevisan, Steve Vickers.
How do you describe what a computer program does without getting bogged down in how it does it ? If the program hasn't been written yet we can ask the same question using a different tense and slightly different wording: How do you specify what a program should do without determining exactly how it should do it ? Then we can add the question: When the program is written how do you judge that it satisfies its specification ?
In civil engineering one can ask a very similar pair of questions: How can you specify what a bridge should do without determining its design ? And, when it has been designed, how can you judge whether it does indeed do what it should ?
This book is about these questions for software engineering and its answers can
usefully be compared with what happens in civil engineering. First, a specification
is a different kind of thing from a design: the specification of a bridge may talk
about load bearing capacity deflection under high winds and resistance of piers
to water erosion, while the design talks about quite different things such as
structural components and their assembly. For software too, specifications talk
about external matters, and programs talk about internal matters
The second of the two questions is about judging that one thing satisfies another.
The main message of the book and a vitally important one is that judgement
relies upon understanding. This is obviously true in the case of the bridge: the judgement that the bridge can bear the specified load rests on structural
properties of components enshrined in engineering principles which in turn rest
upon the science of materials Thus the judgement rests upon a tower of
understanding. This tower is well established for the older engineering
disciplines: for software engineering it is still being built. We may call it
software science.
The authors have undertaken to tell students in their first or second year about the tower as it now stands rather than dictate principles to them. This is refreshing: in software engineering there has been a tendency to substitute formality for understanding. Since a program is written in a very formal language, and the specification is also often written in formal logical terms, it is natural to emphasize formality in making the judgement that one satisfies the other. But in teaching it is stultifying to formalize before understanding, and software science is no exception.