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: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public From: Bertrand Meyer Subject: Re: Trust but verify (was Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/25 Message-ID: <3338AA0A.7A79CB24@eiffel.com>#1/1 X-Deja-AN: 228429236 References: <332B5495.167EB0E7@eiffel.com> <5giu3p$beb$1@news.irisa.fr> <332ED8AB.21E7@lmtas.lmco.com> <5go8nk$ngf$1@news.irisa.fr> <3332C049.2A0F@lmtas.lmco.com> <5gue93$2md$3@news.irisa.fr> <33383A6F.3A5A@lmtas.lmco.com> <5ha171$dck@flood.weeg.uiowa.edu> Organization: Interactive Software Engineering Inc. Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1997-03-25T00:00:00+00:00 List-Id: Robert S. White wrote: > So don't think it is just him that has been put off by people > saying that "Design By Contract with the Eiffel language" > would have (alone - without simulation or HWIL) testing) > prevented the [Ariane] 5 disaster. In this particular case there is good reason to think that good use of Design by Contract would in fact have evidenced the bug early in the development cycle, long before any simulation or testing. I think anyone that has practiced the method will agree. To repeat the basic point of our (Jezequel's and mine) paper: do not reuse without a contract. But of course this is not a reason to say there should not be simulation, testing, inspections, independent reviews etc. etc. I don't recall anyone even coming close to suggesting this in the present thread. And our paper certainly does not say anything of the sort. (By the way I don't primarily think of Eiffel as a "language", more as a method. But this is not the main point of this particular discussion.) > And it is normal industry practice to have different (from the > designers/coders) personnel do the qualification tests (HWIL) test > procedures and conduct the tests using the "Black Box" requirements. Agreed. Not only normal but excellent practice. I like the modified thread title of your message: "Trust but verify" although I would make it stronger: "Make it trustable, then DON'T trust it" (and so verify it). It would be as absurd to use Design by Contract or other a priori relability techniques as an excuse not to do a posteriori V & V (testing, simulation etc.), as it would be to develop in a sloppy way with the expectation that testing will uncover any problems. If a priori reliability techniques - Design by Contract, static typing, genericity, automatic memory management etc. - were a substitute for testing, why would Eiffel environments bother to include debugging tools? Engineering reliability can only result from the combination of several techniques approaching the product from different angles: some a priori (building the product right in the first place), some a posteriori (not believing that it is right, and test it extensively). That this is not an either-or situation is so obvious as to be almost a platitude (although one does encounter people, including software engineering authors, who believe in only the a priori part or only the a posteriori part). But the need for a posteriori verification is too often an excuse for not applying the proven a priori reliability techniques, such as Design by Contract. This is not only silly but a recipe for disaster of Ariane-5 proportions. It's been amazing in this discussion how some postings have taken to task our paper for ideas that are not there. The points that it makes are pretty simple, and there for everyone to examine (http://www.eiffel.com, link to "Ariane 5 paper"); after reading most of the discussion, and re-reading the paper, I think that its arguments and conclusion are perfectly in line with many useful comments made by people who thought they disagreed with it. Please check what it really has to say. -- Bertrand Meyer, President, ISE Inc., Santa Barbara (California) 805-685-1006, fax 805-685-6869, - ftp://ftp.eiffel.com Visit our Web page: http://www.eiffel.com (including instructions to download Eiffel 4 for Windows)