Re: Papers on the Ariane-5 crash and Design by Contract

[jsa@alexandria (Jon S Anthony)]

In article <5gp3hd$i0l@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:

> rkaiser@dimensional.com (Richard Kaiser) writes:
> 
> >Why is Eiffel saying assertions are a new tool?  C (and now C++) have been
> >using #include <assert.h> for years?  Software engineers have been using
> >assert macros to verify program limits are not exceeded. 
> 
> The major difference between C/C++/Ada assertions and Eiffel style
> design-by-contract is that in the latter, the assertions are part of
> the interface, not just embedded in the implementation.


Well, in this particular sort of case, your claim here is not correct
for Ada:


subtype Bias_Constraint is Integer range Min_Bias..Max_Bias;

function Convert ( High_Bias : Bias_Constraint ) return Integer;


The asserstion is part of the interface, NOT the implementation.
Further, to answer a point of Jean's, it will be inherited in any
appropriate derivation case.  And certainly we could do the same for
the post condition (the return subtype).


Now, as John McCabe, Ken Garlington, myself and others have pointed
out, none of this was (or is in any sense likely to be) sufficient to
prevent the type of error exhibited by this example.  The required
semantic context (scope of use, intended behavior, presumed
environment, etc) is far to rich and complex to be dealt with by such
rudimentary simple minded stuff as pre and post conditions on
signatures.  *THE* most alarming aspect of this entire discussion is
that many, including folks the caliber of Meyer and Jezequel, don't
seem to understand this.  Now that is damn _scary_.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com