Re: Ariane5 FAQ

[Richard Riehle <richard@adaworks.com>]

"Robert I. Eachus" wrote:

> Berend de Boer wrote:
>
> > Except requirements it seems. And I think you should have a look at
> > Design By Contract and in particular Eiffel.
>
> No.  And that is what all the sound and fury has been about.  The
> mapping from requirements to actual code was perfectly done.  The
> problem was that the requirements which were perfectly filled were for
> the Ariane 4, not the Ariane 5.

I suspect Berend was referring to the concept of including the requirements
as assertions in the code.   DbC is a technique for doing this.  However,
there are other approaches to DbC that are more effective for safety-critical

systems than that found in Eiffel.  I am thinking here of SPARK.

In general, the safety-critical community does not like the Eiffel model
because it relies on assertion-errors at run-time.   While this is just
fine for non-safety-critical software, it is not appropriate for a system
such as Ariane V, or any other similar system.

Also, assertions themselves require that someone declare the appropriate
assertions.  In the case of Ariane V, if anyone had felt the need to do that,

even thought about it, they would also have made the same mistake they
made in Ada because the assumptions were wrong from the start.

I favor the DbC model and admire the work done by Bertrand Meyer in
refining this idea.  However, it is all too easily over-simplify this kind of

thing after the fact and suggest that, "If you had simply done things my way,

you would not have had this problem."    DbC and Eiffel would not have
made a whit of difference in this engineering problem, articles and arguments

to the contrary notwithstanding.    Ada use correctly would have been OK.
C++ used wisely would have been OK.  Eiffel and DbC   used carefully
would have been OK.  Java, of course, would not have been OK under
any circumstances.

In the final analysis, Arianne V was not a function of programming language,
or design method, or development tools.  It was an engineering mistake that
began with poor management making incorrect assumptions.   That same
engineering mistake would have occurred regardless of tools, languages,
and systems.

Richard Riehle