Design by contract: the lessons of Ariane

Design by contract is the principle that the interfaces between modules of a software system-especially a mission-critical one-should be governed by precise specifications. The contracts cover mutual obligations (pre-conditions), benefits (post-conditions), and consistency constraints (invariants). Together, these properties are known as assertions, and are directly supported in some design and programming languages. A recent $500 million software error provides a sobering reminder that this principle is not just a pleasant academic ideal. On June 4, 1996, the maiden flight of the European Ariane 5 launcher crashed, about 40 seconds after takeoff. The rocket was uninsured. The French space agency, CNES (Centre National d´Etudes Spatiales), and the European Space Agency (ESA) immediately appointed an international inquiry board. The board makes several recommendations with respect to software process improvement. There is a simple lesson to be learned from this event: reuse without a precise, rigorous specification mechanism is a risk of potentially disastrous proportions. It is regrettable that this lesson has not been heeded by such recent designs as IDL, Ada 95 or Java. None of these languages has built-in support for design by contract. Effective reuse requires design by contract. Without a precise specification attached to each reusable component, no-one can trust a supposedly reusable component. Without a specification, it is probably safer to redo than to reuse