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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: ffc1e,a48e5b99425d742a X-Google-Attributes: gidffc1e,public X-Google-Thread: fac41,a48e5b99425d742a X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public X-Google-Thread: 107d55,a48e5b99425d742a X-Google-Attributes: gid107d55,public From: wiu09524@rrzc4 (Ulrich Windl) Subject: Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/18 Message-ID: #1/1 X-Deja-AN: 226367527 References: <332B5495.167EB0E7@eiffel.com> Organization: University of Regensburg, Germany Reply-To: Ulrich Windl Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.programming.threads,comp.lang.ada,comp.lang.java.tech Date: 1997-03-18T00:00:00+00:00 List-Id: In article <332DA14C.41C67EA6@eiffel.com> Bertrand Meyer writes: > Robert I. Eachus wrote: > > > How many times do people have to be told that the lack of an > > assertion was NOT the problem here. The assertion existed > > Where? > > > > [...] The real problem was that the software was used unchanged and > > without review [from Ariane 4 to] Ariane 5, where these assumptions > > were not true. > > The real problem was that the assertion was not part of the software. (I've read the story about half a year ago) When I read that story I could not help, but had to shake my head several times. I definitely agree with Dr. Meyer that this case should be handled in every class about software engineering. If I remember things right, the main problem was the interconnection of different components that were almost correct, but failed to communicate: The modules computing course corrrection data both failed due to to problems mentioned (violating the specs for that code); they shut themselves down. But to me the main issue is that the module that received the course correction data did not detect that both computing modules failed and that the data was just a "test pattern" to indicate that event. Probably a better reaction would have been to stop making further corrections instead of driving the engine to its borders. If the modules to compute course correction data would have failed in a more paraniod way (the module had an exception due to overflow and shut itself down. If it would have continue with the appropriately signed maximum possible value, well I don't know). Maybe one could postulate "Every part in a software system that must not fail that receives an unexpected exception should handle the situation as good as possible, even if it can't guarantee its specification". This sounds contrary to programming by contract, but sometimes this can help. Theoreticans might say "quit on the first error encountered" while real hackers might say "continue as long as you can". (Excuse my non-rocket vocabulary, but this is from memory, and English is not my first language, too) > > Successful reuse requires that what you reuse be equipped with a > specification - a contract. That's the point made Jean-Marc Jezequel > and I made in the article at > http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html. Ulrich