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: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,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/18 Message-ID: <332ED8AB.21E7@lmtas.lmco.com>#1/1 X-Deja-AN: 226468132 References: <332B5495.167EB0E7@eiffel.com> <5giu3p$beb$1@news.irisa.fr> Organization: Lockheed Martin Tactical Aircraft Systems Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1997-03-18T00:00:00+00:00 List-Id: Jean-Marc Jezequel wrote: > > Please do not start a language war! It is made crystal clear in the paper that > *THIS IS NOT A LANGUAGE PROBLEM* > let me repeat it in case it is not clear: > *THIS IS NOT A LANGUAGE PROBLEM* It is certainly *NOT* clear in Mr. Meyer's IEEE article that this is not a language issue. He asserts repeatedly that the use of Eiffel constructs would have solved the issue. > The all point of the paper is that Design by Contract helps in the precise specification > of components: signatures (a la CORBA) are not enough to specify a behavior, pre- and post > conditions are needed to give more details. > > I'm willing to discuss this last point, but I will not answer any language issue > in this thread. Regarding this last point: It is absolutely not sufficient to specify the specification of the components precisely. It is also required that the assumptions about the environment in which the component is (re)used be thoroughly analyzed, and that the results of that analysis be confirmed by test. In the case of the Ariane V, assume that the most excruciatingly correct specification was given for the module, making it clear that it would fail when given a certain range of inputs. The Ariane V would still have crashed, because: 1. No one on the design team expected the invalid inputs to occur (if they did, they would have added back the Ada check that would have detected the problem). This is not uncommon; oftentimes, the team developing a particular component in a large distributed system like a missile does not have the "big picture" regarding the vehicle's flight characteristics. They are working to a specification developed by a prime contractor, which may not contain a full description of the flight envelope (in some cases, because that envelope is also being changed over time). 2. No one ran a full integration test with realistic flight data, which would have alerted them to the mistake made in #1. Particularly for a distributed mission- critical system, this should be considered an absolute requirement. Although I like some of Mr. Meyer's columns, I found this particular column not only wrong, but dangerous, since it continues the trend of denigrating sound test strategy and common sense system engineering in favor of a software-centric approach. (There is a recent article by Boris Beizer regarding the Cleanroom approach that makes this point better than I can.) > > Best regards, > > -- > 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