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: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: jsa@alexandria.organon.com (Jon S Anthony) Subject: Re: Usefullness of design-by-contract (was Re: The stupidity of all the Ariane 5 analysts.) Date: 1997/07/22 Message-ID: #1/1 X-Deja-AN: 258177271 Distribution: world References: <33C835A5.362A@flash.net> <33CEAF05.6389@flash.net> <33D2827B.41C67EA6@eiffel.com> <33d38a16.195337670@news.geccs.gecm.com> <5r1drj$8ih@jupiter.milkyway.org> Organization: PSINet Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-22T00:00:00+00:00 List-Id: In article <5r1drj$8ih@jupiter.milkyway.org> jtc@jupiter.milkyway.org (Jim Cochrane) writes: > I have changed the subject line for this post becuase it is about the > usefulness design by contract and does not address whether it would have > helped with the Ariane 5 mishap. I'm not saying that assertions don't more or less help a bit. In many cases they can, and it is a nice feature that Eiffel does a pretty good job of supporting them. But, they are not any good (well any _much_ good) at capturing the intended context of use of whatever they annotate. In this sense, they don't buy you much with respect to the so-called "contract" and, in fact, can actually lead you astray and _cause_ problems if you take them too seriously. This is _not_ news - it is old hat in the "formal methods" and reuse field. It is also basically the same thing as the problem of "natural kinds" in knowledge representation. Often it is not too hard to come up with _some_ reasonable set of necessary conditions. OTOH, it is typically impossible to come up with a set of sufficient conditions for all contexts of potential use. Generally, it won't even be possible to apriori come up with this set of contexts. What are the necessary and sufficient conditions to call something an "elephant" (to use an old worn out example [1])?? What are the necessary and sufficient conditions to say that X is a usable inertial reference component for a launch vehicle? Ken Garlington got at this a bit when for the X in question here, he stated the context of intended use as "A vehicle with the Ariane IV flight profile". Now, you can say that is not particularly precise - but it is at least _accurate_. What is the "precise" set of necessary and sufficient conditions which completely captures that statement? What is the precise set of necessary and sufficent conditions which completely captures the notion of "elephant"? Precision without accuracy is a well known form of false knowledge, and anyone fool enough to allow himself to be comforted simply because he has stated a whole wadge of precise conditions is going to end up in big trouble. It's this sort of pretentious arrogance that _will_ lull you into a false sense of security. > implicitly questioning. The basic assumptions, as I see them, are: > > 1. Documenting precise specifications in the form of pre- and post-conditions > and class invariants for all component interfaces and making this > documentation easily available to anyone using the components will help > in producing systems that fulfill their requirements correctly. > > 2. Coding as many of these specifications as possible helps in ensuring > their precision and allows them to be checked while testing, further > increasing the chances that the systems developed in this manner will > fulfill their requirements correctly. > > 3. Using a language and environment that directly supports both the > documentation and the coding of these specifications will make the > specification process easier, more complete, and less error prone, thus > further increasing the chances that the systems developed in this manner > will fulfill their requirements correctly. Yes, though the indications are that Meyer believes this will do more than simply "help a bit" - he pretty much seems to believe that this will solve the problem of reuse. It won't. Also, I'd add one more that seems to be implicit: software is a kind of mathematics. It's not. Software systems are much closer to elephants than to first order systems or some such. And no amount of wishing otherwise is going to change this. Those who disregard this do so at their (and _our_) risk. This is part of why as a pilot (and a mathematician) I am much more comfortable with people like Ken Garlington designing and implementing flight control software than people like Meyer. Yes, I agree these are pretty much the assumptions. But they are _stunningly_ naive. /Jon [1] Brachman, R.J.; "I Lied about the Trees" Or, Defaults and Definitions in Knowledge Representation, in The AI Magazine, Fall 1985 -- Jon Anthony OMI, Belmont, MA 02178 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari