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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: ffc1e,a48e5b99425d742a X-Google-Attributes: gidffc1e,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: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/26 Message-ID: <3339BBB9.4B5A@lmtas.lmco.com> X-Deja-AN: 228599847 References: <332B5495.167EB0E7@eiffel.com> <332D113B.4A64@calfp.co.uk> <5gm8a6$2qu$2@news.irisa.fr> <3332BE49.8F9@lmtas.lmco.com> <33330FE5.3F54BC7E@eiffel.com> <3336D167.6BFC@lmtas.lmco.com> Organization: Lockheed Martin Tactical Aircraft Systems Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.programming.threads,comp.lang.ada Date: 1997-03-26T00:00:00+00:00 List-Id: Robert Dewar wrote: > > Ken Garlington said > > < prevented by a language that has Eiffel-like constructs, but it wasn't > the language's fault?>> > > No one said anything completely silly like that! Ken you are putting words > into someone else's mouth. The most that has been said is something like > "systematic use of xxxx would have prevented the Ariane V incident" Let's review what was said (with the help of DejaNews): [1] jezequel@irisa.fr (Jean-Marc Jezequel) writes in this thread on 1997/03/17: "Basically, our claim in this paper is that it is a reuse issue (and in a lesser extent, a system integration test problem). Reusing a component without a precise specification of it is dangerous. That the component is written in Ada, Eiffel, C, assembly language has nothing to do with the way it is specified. "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." >From this, I deduced (possibly erroneously) that Design by Contract helps in the precise specification of components, and that the implementation language has nothing to do with this specification. Well and good. However, I got the strong sense from the paper that Design by Contract would not have been sufficient in this case. Perhaps this statement was the source of my confusion: [2] http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html "Does this mean that the crash would automatically have been avoided had the mission used a language and method supporting built-in assertions and Design by Contract? Although it is always risky to draw such after-the-fact conclusions, the answer is probably yes:" Note the statement "language and method". The Design by Contract method alone is apparently insufficient: it also requires a language that supports built-in assertions. What languages, then, are considered in this category? Well, we know that they must look something like Eiffel: [3] http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html "To attempt to reuse software without Eiffel-like assertions is to invite failures of potentially disastrous consequences." What languages meet this further criteria? Well, we know which do NOT: [4] http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html "It is regrettable that this lesson has not been heeded by such recent designs as Java (which added insult to injury by removing the modest assert instruction of C!), IDL (the Interface Definition Language of CORBA, which is intended to foster large-scale reuse across networks, but fails to provide any semantic specification mechanism), Ada 95 and ActiveX." Of course, one could argue that these last few statements aren't technically in this thread, and so Dr. Dewar is correct. However, Bertrand Meyer is quick to confirm, and in fact expand upon, this issue: [5] Bertrand Meyer writes on 1997/03/22: "Fergus Henderson wrote: "> Bertrand Meyer writes: > !!! Eiffel is the only [commonly available language] to have built-in support for assertions in the !!! spirit of Design by Contract. > > What about Sather? Doesn't it meet those criteria?" "You are right, I should have mentioned Sather. Sorry and thanks for correcting me. " So, Eiffel and Sather are apparently the only commonly available languages to have built-in support for assertions in the spirit of Design by Contract (unless of course, I am misinterpreting this post). Therefore, I feel that the suggestion raised in [1], that Design by Contract is not related to the implementation language, is not correct. The paper, and Mr. Meyer's statements, appear to me to couple the method with a language, and specifically the Eiffel language (or Sather, I suppose). If someone wishes to argue this point, feel free. Mr. Meyer has posted much on this issue, much of which confirms my observation as quoted above. I think part of the confusion on this issue can be explained by the following quote: [6] Bertrand Meyer writes on 1997/03/25: "(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.)" If Eiffel is a method as well as a language, is it a different method than Design by Contract, or are these synomyms? I suspect the latter. It is unfortunate that the paper does not just refer to the Eiffel method, so that this confusion over nomenclature could be avoided. I also agree that this is a side issue: whether the paper is describing a language-independent or a language-specific approach. Far more interesting, to me, would be for someone to address the language-independent issues related to this paper, such as those I raised in: http://xp7.dejanews.com/getdoc.xp?recnum=9332328&server=dnserver.db97p1x&CONTEXT=859409847.28570&hitnum=128 which has the message header Subject: Re: Papers on the Ariane-5 crash and Design by Contract From: Ken Garlington Date: 1997/03/19 Message-Id: <33303627.4EDE@lmtas.lmco.com> To summarize from the post, they are: 1. Being ABLE to specify the assumption does not mean that the assumption WILL be specified. There is evidence it would not have been specified, even using Design by Contract. 2. SPECIFYING the assumption does not mean that a violation of the assumption will be DETECTED. There is evidence that it would not have been detected before flight. 3. Even if the problem was DETECTED, there is no guarantee that the appropriate ACTION would have been taken. There is evidence that an incorrect action would have been taken. These issues would matter, even if Design by Contract were not coupled to a particular language, in accepting or refuting the claim made in [2]. The only argument made against this post, as far as I can tell, is that the IRS testing related to point #2 would not be "black-box" testing. I disagree with this statement (as do other engineers familiar with such systems), but in fact the nomenclature for this test is irrelevant to issue #2. According to DejaNews, no response was posted. If I missed a post, perhaps someone could post a reference to it? > > That is a statement that is highly NON-contentious, since it is true for > almost all possible xxxx including > "common sense". > > The trouble is that when people start replacing xxxx with specific language > features, it is only to easy to read the statement as saying that the > particular choice of xxxx is somehow the only one or at least a key one. > > I have no problem with the statement above with "Eiffel assertions" or > "Programming by Contract" inserted for the xxxx, which would lead to the statements: systematic use of "Eiffel assertions" would have prevented the Ariane V incident systematic use of "Programming by Contract" would have prevented the Ariane V incident I consider either statement (or both together) to be controversial. See above. > but the suggestion that > only these approaches would be appropriate, or even that in this case they > have some special advantage would be respectively absurd or dubious. The > first allegation simply has not been made in this thread. True. Not even by me! When I said "only have been prevented by a language that has Eiffel-like constructs," I was referring to the single-language issue described above. > Some people have > made the second, and I find the argument dubious. Me, too. Doesn't this contradict the claim you made above, that you have no problem with the two statements generated from the "xxxx"? > The Ariane V goof is not > a particularly instructive one from a language or methodology point of view. However, from a total system development process standpoint, it is extremely valuable. -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" For job listings, other info: http://www.lmtas.com or http://www.lmco.com