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,e01bd86884246855 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,fb1663c3ca80b502 X-Google-Attributes: gid103376,public From: "David K Allen" Subject: Re: Interresting thread in comp.lang.eiffel Date: 2000/07/12 Message-ID: #1/1 X-Deja-AN: 645463473 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.50.4133.2400 X-Complaints-To: abuse@visi.com X-Trace: ptah.visi.com 963407894 209.98.239.164 (Wed, 12 Jul 2000 08:18:14 CDT) X-MSMail-Priority: Normal NNTP-Posting-Date: Wed, 12 Jul 2000 08:18:14 CDT Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-07-12T00:00:00+00:00 List-Id: Riddle: When is a contract not a contract? Answer: When they are two different words representing different concepts but spelled and/or sounding the same (homonyms). ----------------------------------------- "Ken Garlington" wrote in separate posts > Wouldn't both sides have to agree to this contract for it to be legally > valid? > You understand, of course, that standard contracts are in fact negotiated? 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. Your remarks are important in the context of business contracts, but they are confusing in the context of "Design By Contract." Please don't let the fact that "contract" is used as a metaphor in DBC confuse you with the true meaning of the method. Like all metaphors, it simply helps you get started, and adds a certain flavor to the concepts it describes. But the concept itself can only be judged if you understand it accurately. 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. 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. I can understand the confusion - especially in the context of the Ariane disaster. Because, in fact, there are issues of both kinds involved in this situation. There is a role for a discussion of "Design By Contract" as Dr. Meyer has developed it, with the precise meanings of that method. Then there is also a role for discussing how to design software in the context of business contracts among multiple contractors and subcontractors where a conglomerate of different nations are the project sponsors (yikes what a tough deal!). Although they can have some relationship, they are not the same thing. 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. 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. 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. This would have reduced, though not eliminated the "art of guessing how much a contractor must provide to a subcontractor" which you described earlier. -- Best Wishes, David Kreth Allen Software Consultant Minneapolis, Minnesota - USA