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,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: jezequel@irisa.fr (Jean-Marc Jezequel) Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/16 Message-ID: <5qitoi$fdv$1@news.irisa.fr>#1/1 X-Deja-AN: 257265314 Distribution: world References: <33C835A5.362A@flash.net> <33CC0548.4099@flash.net> Organization: Irisa, Rennes (FR) Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-16T00:00:00+00:00 List-Id: In article <33CC0548.4099@flash.net>, Ken Garlington writes: >Don Harrison wrote: >> You would use them anywhere that a piece of code makes assumptions. For example, >> to help avoid the Ariane fiasco, include contracts in the INS(?) that specify >> Ariane 4 dynamics. Then, in testing, you will get an assertion violation when >> you apply Ariane 5 dynamics to it. > >This is why my blood pressure goes up! > >The _Ada_ implementation did generate an assertion violation the very >first time Ariane 5 dynamics were applied to it. Unfortunately, the very first time >Ariane 5 dynamics were applied to it was at LANUCH! >They were not applied earlier, because the contractor assumed that the >Ariane 5 dynamics were the same as the Ariane 4, so why spend the money testing >to the same conditions already tested earlier? (They were wrong, of course, but they >didn't know that at the time). At the risk of repeating myself, and reopening a thread beaten to death, the all point of design by contract (DBC) is to make this kind of assumptions explicit. Ariane 5 is just a nice striking example of working with assumptions that are true at a point in time (Ariane 4) and no longer later on (Ariane 5). I think we agreed on this previously. To sum up your point, you think that DBC, i.e. expressing hidden assumptions with Eiffel-like assertions would not have been practicable in this case. Others think it would have... You seem to be a specialist in flight software. We are not. But specialists might, from time to time, learn something from people with a broader perspective (this is a general statement, I do not claim in particular that I have a broader perspective than you, or anyone else for that matter;-). Basically, our arguments failed to convinced you. Yours failed to convince us. That's life, and I hope readers can make their mind themselves instead of relying on the one of us who shouts louder. >The other part of the problem was that the _response_ to the assertion >violation was wrong. The designer assumed the assertion would occur due to a hardware >failure, not a software requirements failure, and so the handler shut down the >"offending" hardware, rather than attempting some other action (e.g. replacing the >out-of-range value with a "safe" value). Frankly, I don't know that I would have written the >handler differently myself. Agreed, that's a different problem altogether. >According to Meyer, et. al. Eiffel programmers would have written the >handler differently, and also they would have known to do the testing >differently (even though the requirements specification said that the tests need not change). >However, their explanation as to why this is true is far from convincing (basically, >that "Eiffel programmers believe in quality" or some such nonsense). Their "analysis" >is also on the Web. I've asked them to post my rebuttal to their paper, but I >don't know if they ever did. Just for the record, I'm still waiting for your rebuttal paper to put it on my web alongside with the Computer article. PS: Ken's post was brought to my attention by a colleague: I don't have time to check the news very often these days, and anyway I won't follow-up on this thread to avoid reopening the interminable Ariane thread. -- Jean-Marc Jezequel Tel : +33 299 847 192 IRISA/CNRS Fax : +33 299 847 171 Campus de Beaulieu e-mail : jezequel@irisa.fr F-35042 RENNES (FRANCE) http://www.irisa.fr/pampa/PROF/jmj.html