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.6 required=5.0 tests=BAYES_00,FROM_WORDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,e01bd86884246855 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,fb1663c3ca80b502 X-Google-Attributes: gid103376,public From: "Ken Garlington" Subject: Re: Interresting thread in comp.lang.eiffel Date: 2000/07/12 Message-ID: X-Deja-AN: 645693135 References: <8ipvnj$inc$1@wanadoo.fr> <8j67p8$afd$1@nnrp1.deja.com> <395886DA.CCE008D2@deepthought.com.au> <3958B07B.18A5BB8C@acm.com> <395A0ECA.940560D1@acm.com> <8jd4bb$na7$1@toralf.uib.no> <8jfabb$1d8$1@nnrp1.deja.com> <8jhq0m$30u5$1@toralf.uib.no> <8jt4j7$19hpk$1@ID-9852.news.cis.dfn.de> <3963CDDE.3E8FB644@earthlink.net> <3963DEBF.79C40BF1@eiffel.com> <2LS85.6100$7%3.493920@news.flash.net> <8k5aru$1odtq$1@ID-9852.news.cis.dfn.de> <8k8pk2$20cab$1@ID-9852.news.cis.dfn.de> <_dS95.9945$7%3.666180@news.flash.net> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 963445534 216.215.75.222 (Wed, 12 Jul 2000 18:45:34 CDT) Organization: FlashNet Communications, http://www.flash.net X-MSMail-Priority: Normal NNTP-Posting-Date: Wed, 12 Jul 2000 18:45:34 CDT Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-07-12T00:00:00+00:00 List-Id: "David K Allen" wrote in message news:qe_a5.259$6E.64803@ptah.visi.com... > I think, as Bertrand said earlier, that you two were talking on different > wavelengths. > He was talking "Design By Contract (DBC)" a formal method for designing > reliability into software to faciliate reuse. It is a method which he knows > very well. > Based on the comments you made above, you were talking business contracts, > which you apparently know very well. Actually, I was talking about the use of code constructs (DbC contracts) as part of a binding relationship between parties (business contracts). The words you elided mention this. A previous poster said that DbC contracts represented a committment between the developer and the reuser. My question had to do with the seriousness and dependability of that "committment." > I certainly welcome your criticism of DBC. You are obviously a clear and > critical thinker with considerable experience in software development. But > it will be more productive if you base your criticisms on what DBC really is > about rather than what you think it might be. > Instead of reacting to our attempts to explain DBC to you, one piece at a > time, perhaps it will be more useful for you if you read a clear > introduction to DBC which explains what it is really about. > http://www.eiffel.com/doc/manuals/technology/contract/page.html. Actually, I have read this. I am also familiar with, and/or have used, other examples of similar/related approaches: Ada (and GNAT assertions), SPARK, T-VEC -- and, today, OBLOG (where the contracts are called "quarks"). > Others have tried to explain it, but you counter with examples like those > above which tell me you are criticizing DBC based on the mistaken notion > that it is supposed to perfectly model a business contract. Not at all - I am responding to the suggestion that it is useful to use constructs written at the level of detail inherent in source code as part of the process of specifying the requirements of a system between customer and vendor. These issues are discussed further at http://www.flash.net/~kennieg/ariane.html along with a more comprehensive set of issues related to DbC -- specifically with respect to Ariane 5, by the way. > Applying business principles to the software engineering "Design By > Contract" will not really help much. > Conversely, trying to apply Dr. Meyer's software engineering principles to > the socio-political issues will not help either. > They are two different domains with different principles and techniques. Couldn't agree more. > But the point is that if DBC were a component of the software development > method used to build Ariane, then any attempts to reuse software from a > previous project would force the issue that the new project teams MUST HAVE > the specifications of any modules they intend to reuse. Couldn't *disagree* more (with respect to Ariane 5). The reason, in part, is because of another homonym you mention - "specification". That term, used in the sense of traditional acquisitions, means something very different than it does in DbC. You need both types of specifications to do the required analysis/test correctly. A "hole" in the procurement specification is not necessarily revealed by the DbC specification, particularly if the implicit assumption is that the procurement specification identifies what has changed from the previous procurement. Information at the source code level of detail is rarely seen by those who write the procurement specification, so it will not address their issues. Those who write the source code -- particularly in the context of an element like an IRS -- rarely have sufficient experience and insight to detect potential system-level subtleties like the one that was missed in the Ariane 5 program. I note that this "force the issue" aspect of the DbC argument -- despite the arguments I provide to rebut it -- tends to be accepted as an article of faith, accompanied by various personal testamonials (rarely in the context of an Ariane 5-style environment). Frankly, I almost feel like shouting "Amen!" I would be much more accepting of this "leap of faith" if it were accompanied by examples relevant to Ariane 5. It keeps getting ignored (I suspect because the question can't be answered), but I'll post this example again. The DbC specification for a module is given below. I feel fairly confident that this is considered a good quality example by at least one acknowledged Eiffel/DbC expert. convert (horizontal_bias: INTEGER): INTEGER is require horizontal_bias <= Maximum_bias If, as you say, this would cause the project team to go get information they did not already have, then explain what information it would require and why. (My analysis of this DbC specification is in the link noted above). > If that had been > part of the software develoment culture, then the subcontractor would have > required the additional information and the contractor would have gladly > complied and provided it. Again, couldn't disagree more. > This would have reduced, though not eliminated > the "art of guessing how much a contractor must provide to a subcontractor" > which you described earlier. Not in the context of Ariane 5. As people on both sides of the issue agree, Eiffel/DbC is neither necessary nor sufficient to address an Ariane 5-class failure.