Would use of design by contract have prevented the Ariane 5 disaster?

 

Ariane 5 was a European expendable launch system designed for delivering satellites to space, exploded 40 seconds after the lift –off which caused around 500 million damage to the world.  When developing the Ariane 5 software, some codes were reused from the Ariane 4 system which was used successfully for Ariane 4 but had  different flight characteristics than Ariane 5. Soon after the explosion an inquiry board was called to investigate the disaster and they found that explosion was due to a software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,767, the largest integer storable in a 16 bit signed integer, and thus the conversion failed. (Ladkin, 1998)

The most simplest answer is Yes but if i elaborate more ..

It is known Ariane 5 had failed due to a reuse specification error (Ladkin, 1998). If software engineers and designers had followed the design by contract methodology this disaster could have been avoided.

Design by contract follows set of methods which provide some tools for formulate the contracts, to increase the quality of the software with correctness and robustness. Which would also enhance the performance of  the reusability of software components, which could have avoided and prevented its destruction. Author would like to discuss the following key concepts of DBC which would have prevented Ariane 5 disaster.

• Explicitly handle exceptions from the design stage.

Design by contract force all the fundamental constraints in each code module must be explicitly handled and mentioned from the design state itself. Design by contract propose several approaches to be taken to satisfy the above conditions. Such as preconditions and post conditions which validates fundamentals inside the functions, and invariant which specify the legitimate values of the class attributes(validate the fundamental contracts inside a class). In Ariane 4 if the  software crew had mentioned the constraints, from designing the module itself and put  the needed preconditions post conditions and invariants, this error would have detected from the reusing state  and change the values accordingly in Ariane 5 module. And assertions can be verified during the testing stage to verify the boundaries.

• Provide systematic documentation for the software components.

 “The requirement that the horizontal bias should fit on 16 bits was in fact stated in an obscure part of a document. But in the code itself it was nowhere to be found!” (Jézéquel, 1997)

            If all the critical assertions and exceptions were documented and all the constraints were mentioned in the design specification document, QA team and review team would have given the proper attention to the validations and done the unit tests accordingly. One cannot blame QA team and the review team that they have not done their job right because you cannot test all software components in a large system to a given restricted timeline (you can test a lot but not all). Therefore if the documents are systematically produced reusing stage itself one can identify the defect and fix it. And QA team would give a critical testing on the boundaries and exceptions which had fundamental constraints mentioned in the documentation. Design by contract make the documentation easy and it explicitly mention the pre conditions post conditions and invariant to make the documents more clear.

Design by contract make the code self documenting it clearly classify the exceptions and the constraint which must be handled inside each functions and classes. And if the proper assertions are mention from the code itself review team would identify the critical points of the code, but in Ariane 5 code had not mentioned about the fundamental constraints which leads review team to abound the above error.