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: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public From: jezequel@irisa.fr (Jean-Marc Jezequel) Subject: Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/21 Message-ID: <5gth8r$2md$1@news.irisa.fr>#1/1 X-Deja-AN: 227245441 Distribution: world References: <332B5495.167EB0E7@eiffel.com> <5giu3p$beb$1@news.irisa.fr> <332ED8AB.21E7@lmtas.lmco.com> <199703190839.JAA02652@stormbringer.irisa.fr> <33302A36.7434@lmtas.lmco.com> <01bc356c$e3aae860$371883cc@beast.advancedsw.com> Organization: Irisa, Rennes (FR) Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1997-03-21T00:00:00+00:00 List-Id: In article <01bc356c$e3aae860$371883cc@beast.advancedsw.com>, "Roger T." writes: >In general I agree wholeheartedly with Ken's comments but thought I would >> Although I think programming by contract is worthwhile, I still contend >that there >> is no compelling reason to believe it would have avoided *this particular >problem*, for >> two reasons: >Also even if assertions are included it is still possible that the list of >assertions could suddenly become incomplete when the module is used in >another context. The point is that it works the other way round: pre/post/inv serve as documenting the assumption *made in the code*, not about the environment. It is the job of the integration team to check it against the environment. This can be done either by manual verification when it is easy as in this particular Araine501 case, or through costly software tests or even more costly hard/soft tests (Ariane is a commercial program, not a strategic defence program: the budget constraints are not the same to say the least). >It all comes back to incomplete domain analysis. It is clear that we are in a disagreement here. I claim that domain analysis is necessarily incomplete (i.e. can you prove that your domain analysis is complete?). Meanwhile, it is possible to explicitely get all the assumptions present in the code (i.e. software is not, despite many appearences, black magic). BTW making all the assumptions explicit about what does a piece of code is the mere definition of Design by Contract. Despite your apparent anger about CS people, can you see my point? >CS people are too willing to put in some hack to that solves a minor >programming problem without realizing that the change may propagate through >the control loops and cause problems with overall performance. ... >The problem is not the language or the lack or presence of assertions. The >problem is having people doing design who don't understand dynamic systems, >especially feedback. I think you're a bit off-topic here. There are many problems in system design, and nobody claimed that design by contract solved them all. I repeat again, because it seems it does not make it through the brain of some people: the point of the paper on Ariane 5 was that reusing a component without checking its specification can lead to a catastroph. Design by contract helps in getting the proper specification of a component. It replaces by itself neither V&V, system engineering, floral art... -- 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