Deriving Specifications for Systems That Are Connected to the Physical World - Formal Methods and Hybrid Real-Time Systems - page 385

and norms, both in the design process and in the product's structure and im-
plementation. In Vincenti's words:
. . . the engineer knows at the outset how the device in question works,
what are its customary features, and that, if properly designed along such
lines, it has a good likelihood of accomplishing the desired task.
Normal design is contrasted with radical design ,inwhich:
. . . how the device should be arranged or even how it works is largely
unknown. The designer has never seen such a device before and has no
presumption of success. The problem is to design something that will
function well enough to warrant further development.
Normal design is specialised to each class of system, or product, or device, and
evolves over a long period in a community of designers or engineers who specialise
in the class in question. The design of cars, for example, has evolved over 120
years since Karl Benz's first model of 1886. Many features have now become
standard that were unknown and even unimaginable to Benz: front wheel brakes,
unitary body, and automatic gearbox are just three of a huge number of features
that make modern cars safe, convenient, and reliable. Normal design allows such
inventions to be evaluated by experience, and the results of experience to be
shared and exploited by all members of the particular design community.
Even more important is the effect of a normal design discipline on less obvious
aspects of development. Specification of any system or product is inevitably par-
tial, even for a product as small as an integer function. Specifying the function
value in terms of its arguments may be straightforward, but this specifies only
the abstraction. In constructing the real program to satisfy the abstraction, a
perverse programmer can easily frustrate the specifier's intentions: by devising
a novel algorithm that causes arithmetic overflow in an intermediate result; by
using a memo-style design that can demand an impossibly large amount of stor-
age; by starting a new thread; by gratuitously accessing the web; and in many
other ways. Normal design excludes such perverse choices, because it allows the
specification of a normal device or product to imply an additional set of unstated
conditions.
For a software-intensive system, where the computer interacts with the phys-
ical world, the importance of normal design is even greater. The physical world
has an unbounded capacity for unexpected failures, and only experience can
teach which failures are more likely, and therefore more necessary to handle.
For example, Section 3 discussed the treatment of certain equipment faults, and
pointed out that many faults demand not only an analysis of the rely-condition
of fault-free operation, but also a careful examination of the equipment itself
and of the many ways in which it can fail.
The impact of normal design -or, rather, its lack- can be seen also in the
formalisation of the SluiceGateRequirement . The informally stated requirement
was that the gate should be closed for approximately five sixths of the time over
any substantial period. The formalisation makes this precise in a certain sense.