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,a48e5b99425d742a X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public X-Google-Thread: ffc1e,a48e5b99425d742a X-Google-Attributes: gidffc1e,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public From: jezequel@irisa.fr (Jean-Marc Jezequel) Subject: Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/19 Message-ID: <5goe44$ngf$2@news.irisa.fr>#1/1 X-Deja-AN: 226691331 Distribution: world References: <332B5495.167EB0E7@eiffel.com> <332D113B.4A64@calfp.co.uk> <5gl1f5$a26$2@quasar.dimensional.com> <332E8D5D.400F@calfp.co.uk> <5gnttg$jkc$1@quasar.dimensional.com> Organization: Irisa, Rennes (FR) Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.programming.threads,comp.lang.ada Date: 1997-03-19T00:00:00+00:00 List-Id: In article <5gnttg$jkc$1@quasar.dimensional.com>, rkaiser@dimensional.com (Richard Kaiser) writes: >But this software was Never tested. No end-to-end test with the hardware, nor >even a software only simulation. If the testing is not performed assertions >will not be executed to detect a problem. With proper testing the simulated >flight would have failed with or without the assertions. Yes. But in some cases, actual testing can be extremely hard to perform. If you do not want to test during a rocket launch, you have to simulate the supposed environment of this rocket. aka a software simulated launch. Enabling this is possible, but you have to design your software *with this purpose in mind*. Most notably, it means decoupling your software from your hardware, and simulating the expected behavior of the later one. Still, you're never 100% sure that you didn't miss something in your simulation of the environment. Because the Ariane4 SRI was designed as a *functional* black-box, that is vertically integrated, this approach was simply not possible, unless you re-designed everything instead of re-using the black-box. You cannot fool an inertial reference system, e.g. to make it believe it follows a given trajectory, unless you make it follow this trajectory, i.e. you launch it! So our point in the paper is that yes, better testing would have caught the problem. But don't throw the stone to the testers. It's not always as easy as it seems. OTOH, assertions always help software component verification during reviews. This is where the problem should have been detected, provided it was made explicit enough through design by contract. >Why is Eiffel saying assertions are a new tool? C (and now C++) have been >using #include for years? Software engineers have been using >assert macros to verify program limits are not exceeded. Yes. This is nice. But the original point in Eiffel is that assertions are tighly integrated within the language, and serve as a design tool before simplifying the debugging and testing processes. Eiffel assertions belong to a method specification (along with the method signature), not to the method implementation. For example, they are inherited, even when a method is overidded (BTW, if you know a simple way of doing that in C/C++, I'm a taker). Also, it is not trivial to check class invariants in C/C++ (how do you know, without compiler support, that the call to a class method originates from outside or inside the class? In the former case, the class invariant has to be checked upon entering and exiting the method, and not in the later case). As a consequence of this tight integration, a class abstractor can automatically collect all the assertions and present a complete abstract data type view of a class (including all inherited pre/post conditions and class iinvariants), whatever its position in the class hierachy. For more details on that, you can check my book: "Object-Oriented Software Engineering with Eiffel" Addison-Wesley Eiffel in Practice Series, ISBN 0-201-63381-7 http://www.irisa.fr/pampa/EPEE/book.html -- Jean-Marc Jezequel Tel : +33 2 99847192 IRISA/CNRS Fax : +33 2 99847171 Campus de Beaulieu e-mail : jezequel@irisa.fr F-35042 RENNES (FRANCE) http://www.irisa.fr/pampa/PROF/jmj.html