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: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public From: Ken Garlington Subject: Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/25 Message-ID: <33383A6F.3A5A@lmtas.lmco.com>#1/1 X-Deja-AN: 228292269 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> Organization: Lockheed Martin Tactical Aircraft Systems Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1997-03-25T00:00:00+00:00 List-Id: Jean-Marc Jezequel wrote: > > In article <3332C049.2A0F@lmtas.lmco.com>, Ken Garlington writes: > > >"It should be noted that for reasons of physical law, it is not > >feasible to test the SRI as a "black box" in the flight environment, > >unless one makes a completely realistic flight test, but it is possible > > OK, it seems that some people refuse to get the point of our paper > (design by contract is need when you attempt to reuse "black-boxes"). > It is their pure right. I would be a pity if it would degenerate into a > flame bait. So I won't continue to argue... So far, the only arguments I've seen from either author are: (a) It's not really black-box testing to test an IRS as described in the paper. (Why this even matters, I don't know, but I disagree with it in any case. See below.) (b) It's not just Eiffel, it's Design by Contract plus Eiffel. (Which is what I said. Specifically, it's definitely NOT Design by Contract plus any language. Eiffel is required. So, I'm glad we all agree on this point. :) Left unchallenged are the interesting arguments: Does the ability to specify an assertion mean that the assertion would have been specified, in the case of the Ariane 5? Does the specification of an assertion mean that it will detect errors (either by manual review, static analysis, or dynamic analysis) of the type detected on Ariane 5? Too bad. > > >to do ground testing by injecting simulated accelerometric signals in > >accordance with predicted flight parameters, while also using a > >turntable to simulate launcher angular movements. Had such a test been performed > > That is, opening the black box... THIS TEST DOES NOT REQUIRE OPENING THE BOX! (1) Put the black box on the turntable. (2) Hook the connectors to the EXTERIOR of the black box. (3) Feed the signals through the connector! Lord have mercy, why do people who have never tested an IRS INSIST on explaining it to those of us who have! > > >the supplier or as part of the acceptance test, the failure mechanism > >would have been exposed." > > >As someone who, today, is performing testing of coupled IRS and flight > >control systems in a ground-based environment, I am quite confident in > >the conclusions of the paper on this point. > > I understand that you feel touchy on the subject since it is your job that is at > stake. But you do not need to worry: our point was not that test is not necessary: > it is! But it is not sufficient (I expect that you would agree on that). (a) I'm a software engineer. My job is not at stake in any of this. (b) If the test is necessary, and Design by Contract does not require testing, and Ariane 5 did not plan to do the test, then Design by Contract by itself would not have prevented the accident. QED. Remove "probably yes" from the paper, or add a statement that Design by Contract, PLUS V&V, system engineering (specifying the Ariane V flight profile to the IRS team), etc. would have prevented the problem. At this point, you have no other intellectually honest option. This has nothing to do with whether DBC/E (Design by Contract/Eiffel) would detect errors that might be missed otherwise. If you want to discuss such an abstraction, feel free. Your paper is written in terms of a specific problem in a specific environment. You admit that test was (a) possible, (b) not done, and (c) required. If you add (d), that DBC/E does not require V&V with realistic data (and there is nothing in the paper that contradicts this), your argument is dead. We don't even have to discuss whether or not being able to specific the specific assertion required in this case would have been specified by the design team, FOR THE ARIANE 5 CASE. I don't expect a response to this, of course, but there it is nonetheless. > Also, testing is a part of V&V, which is itself a part of the > larger goal of making a project succesful (whatever be the meaning of that). Completely missed the point. Too bad. > > -- > 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 -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" For job listings, other info: http://www.lmtas.com or http://www.lmco.com