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, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,f66d11aeda114c52 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,f66d11aeda114c52 X-Google-Attributes: gid103376,public From: Bertrand Meyer Subject: Re: Critique of Ariane 5 paper (finally!) Date: 1997/08/20 Message-ID: <33FB41EC.2781E494@eiffel.com>#1/1 X-Deja-AN: 268404641 References: <33E503B3.3278@flash.net> <33E8FC54.41C67EA6@eiffel.com> <33E9B217.39DA@flash.net> <33EA5592.5855@flash.net> <33EB4935.167EB0E7@eiffel.com> <33EB754E.446B9B3D@eiffel.com> <33EBE46D.2149@flash.net> <33EF9487.41C67EA6@eiffel.com> <33F22B91.167EB0E7@eiffel.com> <33F7C3C0.446B9B3D@eiffel.com> <33FA748A.35FE@flash.net> <33FB3B29.41C67EA6@eiffel.com> Organization: Interactive Software Engineering Inc. Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-08-20T00:00:00+00:00 List-Id: Note: Invectives ("complete nonsense", "bogus", "absurd" etc.) serve no useful purpose. In particular they are not a substitute for arguments. We are all very passionate about these things, which is good, but I think we should all continue to accept that the other side is not completely incompetent. I certainly respect Robert Dewar's views, even those (not all) with which I disagree. (End of note.) Robert Dewar initially wrote > > reliability is measured in the terms that matter, i.e. > > it does what it is supposed to do in a highly reliable manner. which says little more than: a system is reliable if it is highly reliable. It would be hard to quarrel with his statement, but as a definition it's not very useful. He then refined this definition into > I said that the > only measure of reliability that made any sense was that a program > behaved in a realiable manner and did what it was supposed to do Again, probably true but not sufficient as a definition. The first part is a tautology (a program is reliable if it behaves in a [reliable] manner -- sure). The second part, "[does] what is supposed to do", is broadly correct as a general, informal definition (although even so one can do better, in particular by distinguishing between two components of reliability, correctness and robustness), but is not enforceable in any way. How do you know that a system "does what it is supposed to do"? The most you can expect (in the absence of formal techniques) is, as I wrote in my earlier message, that the program has "done what it is supposed to do" for a certain period of time, be it 30 seconds or 30 years. (And even that is subject to doubt, as you can hardly be sure that everything was perfectly all right. For example if we take one of the pragmatically reliable COBOL programs that Prof. Dewar cites, assuming it has been computing payroll taxes for the past 10 years, few people would bet $50,000 of their own money that no one will sue and win damages on the basis of wrongful operation of the program during that past period.) These are difficult issues and no one has a silver bullet. But it turns out that it is possible to do better at least at the component level. As Prof. Dewar has correctly pointed out, specifying the behavior of a complete system -- i.e. "what it is supposed to do" -- is hard. But for a component of that system it is often possible to write such a specification, partially or totally formal. This is what Design by Contract is about. The claim that it is necessary has an obvious basis: you can't get the system right if you can't get the components right. To get the components rights, you need to convince enough people, beginning with yourself, that they are "doing what they are supposed to do", and you can't do that without stating what they are supposed to do, as precisely as possible. The good news is that for a component you can realistically be more precise than for a whole system. The more fundamental issue is that we need better ways to achieve the reliability of mission-critical systems. Not just better organization and management, but better techniques. Design by Contract is one such technique. It is not by itself the answer, but I think it is a required part of the answer. -- Bertrand Meyer