By Topic

Design by contract: the lessons of Ariane

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

Formats Non-Member Member
$33 $13
Learn how you can qualify for the best price for this item!
Become an IEEE Member or Subscribe to
IEEE Xplore for exclusive pricing!
close button

puzzle piece

IEEE membership options for an individual and IEEE Xplore subscriptions for an organization offer the most affordable access to essential journal articles, conference papers, standards, eBooks, and eLearning courses.

Learn more about:

IEEE membership

IEEE Xplore subscriptions

2 Author(s)

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

Published in:

Computer  (Volume:30 ,  Issue: 1 )