Re: The stupidity of all the Ariane 5 analysts.

[rodemann@mathematik.uni-ulm.de (Joerg Rodemann)]

Bertrand Meyer (Bertrand.Meyer@eiffel.com) wrote:
> To repeat once again the basic point made in the
> paper by Jean-Marc Jezequel and myself: it is dangerous
> and unjustifiable, especially in a mission-critical setting,
> to reuse a software element without a specification.

Agreed: it should be clearly stated what something is intended for. Although
the idea of preconditions sound very good to me at first sight I am very
sceptical if this is very useful at all since one has to think of EVERY
possibility the routine might be used for. E. g. assume the implementation
of some mathematical function that is not well defined for the complete
complex plane or not continously defined for real numbers. On the other
hand you might have an algorithm at hand that is suitable for every value
the function is defined. (Maybe the Gamma, Beta and Zeta functions are
some examples that meet my assumptions --- I can't remember them exactly right
now.) On the other hand you know that for your actual problem this function
is indeed defined for each possible value since you are --- from your
requirements --- quite sure that some area will not be left. So you could
enter this as a precondition. 

But now guess you like to use this component for some other work --- and 
you are not dealing with complex numbers of different areas of the plane.
It seems to me that you list of preconditions will grow very fast ---
leaving the code quite unreadable. (Kind of a " i++;  // increments i" type
comment.) Code is the more difficult to comprehend the large it is. And
especially emphasizing details may obscure the essential parts. Was not
this abstraction was all about?

From this point of view I would think that easy checkable preconditions
should be checked (e. g. using assertions). Others should be kept in the
documentation. As far as Ariane V is concerned the report clearly states
that the problem was know and discussed during develepment but due to
cpu time limits not every suspected variable was covered. It seems to me
that a lack of knowledge about the actual application was one reason for
the error to occur. (Among the devastating assumption that exceptions are
only to occur when hardware fails!) No pre-/postcondition theology would have
cured that, IMHO. (I believe no methodology could cure that. and this might
be a problem that is not easy if at all to solve for systems that complex.)

Well, just my humble opinion...and I have to admit that I have no experions
within realtime or safety critical applications development.

Yours sincerly

Joerg


--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany