From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: rodemann@mathematik.uni-ulm.de (Joerg Rodemann) Subject: Re: The stupidity of all the Ariane 5 analysts. Date: 1997/07/23 Message-ID: <33d5cc5e.0@news.uni-ulm.de>#1/1 X-Deja-AN: 258296051 References: <33C835A5.362A@flash.net> <33CC0548.4099@flash.net> <5qitoi$fdv$1@news.irisa.fr> <33CD6512.2404@flash.net> <01bc92e6$7a6f9e40$287b7b7a@tlo2> <33CEAF05.6389@flash.net> <33D2827B.41C67EA6@eiffel.com> Followup-To: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Organization: University of Ulm, SAI, Germany Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-23T00:00:00+00:00 List-Id: 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