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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8f7e92843da1c5d2,start X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,8f7e92843da1c5d2,start X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,8f7e92843da1c5d2,start X-Google-Attributes: gid1108a1,public X-Google-Thread: fac41,8f7e92843da1c5d2,start X-Google-Attributes: gidfac41,public From: geldridg@progsoc.uts.edu.au Subject: Design by Contract: A Simple Story .. Date: 1997/07/22 Message-ID: <869585285.12801@dejanews.com> X-Deja-AN: 258148341 To: geldridg@progsoc.uts.edu.au X-Http-User-Agent: Mozilla/2.02 (Win95; I) X-Originating-IP-Addr: 192.189.54.59 (myponga.connect.com.au) Organization: A Humble Programmer X-Article-Creation-Date: Tue Jul 22 15:28:06 1997 GMT X-Authenticated-Sender: geldridg@progsoc.uts.edu.au Reply-To: geldridg@progsoc.uts.edu.au Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-22T00:00:00+00:00 List-Id: [ Following the creation of a online version of the Ariane/ ] [ Design by Contract (DBC) Critique WWW page (see my other ] [ post or Ken's), I offer the following in support of DBC ] [ and Bertrand Meyer. ] My contribution to the discussion (being a simple story - I'm not a rocket scientest, fighter programmer) is not in relation to Ariane 5, but for DBC from the point of view of a `practicing electrical engineer' who uses different tools (Perl most recently) and methods to solve real world problems in a `deregulating electricity market'. Starting from a quote from one recent posting to the discussion by Jim Cochrane (jtc@jupiter.milkyway.org) : ``As I see it, Eiffel is simply an evolutionary step in the maturing fields of computer science and software engineering. By directly supporting design by contract it increases the chances that a team of capable developers will produce a quality product.'' As Bertrand Meyer (BM) has stated repeatedely in many forums in one way or another over the last 10 years, that `design by contract' (DBC): ``..brings about a major change to software development, as important as the rest of object technology.'' At the individual level, I first recall reading about DBC (`programming by contract', as it was termed then) in Dr Dobbs article (way back in 1989?, from memory) written by BM where he made, what seemed an usual (and at the very least, provocative) statement: ``defensive [programming] is offensive'' This simple quote is all it took for me and was the start of a very rewarding journal. What he was trying to get across took sometime to sink in (call me `slow' or even a `hobbyist'), and some of my colleagues still have not seen past the `provocation element'. Some years later my approach to programming has changed considerably (and much for the better), even in languages that don't support Eiffel style assertions (eg. Perl). Gone are those noisy `offensive' defensive statements in functions and procedures, their requirements now being documented as commented pre-conditions and left to the client code to test prior to calling (if I choose - `you get what you pay for'!). The comments also document my code and I find that I don't need to look through the supplier code to see how to use it correctly. [ See the Jim McKim and Brian Henderson Sellers TOOLS USA'94 ] [ paper titled `Contracting: What's in it for the Supplier?' ] [ for the `Supplier's' side of the story. ] This was just the start. If you can see past the ``defensive is offensive'' statement and use DBC at this level, then you are well on the way to making a ``a major change to [your] software development'' processes. If you can't see past this then you will probably never see what lies beyond.. As you explore Object Technology (OT), you will want to know more, particular with regard to DBC's `pivotal' role in OT. Another BM quote: ``..[DBC] is an integral part of the technology. That many people try to do O-O development - using Smalltalk, C++, Delphi, Booch, use cases, whatever - without having the slightest idea of this requirement is a reflection on what they have been taught as `object-oriented ', on the intellectual limitations of the methods and tools they use, and on the youth of the field; it does not make Design by Contract less central to the technology.'' The use of DBC and the benefits it brings grows with you. For me, as I explored OT, DBC has been at every corner. Inheritance, exception handling, loops [invariant's and variant's] and abstract iterators [with abstract invariant functions]. The list goes on. For a glimpse, see my paper titled: ``Eiffel: Facilitating the Link between Software Engineering Practice and Formal Methods'' at: http://www.progsoc.uts.edu.au/~geldridg/frsd2/ -- All of the above is discussed in much greater detail and clarity in BM's recently released (a must have): Object-Oriented Software Construction, 2nd Ed. ( See: http://www.eiffel.com/doc/oosc.html ) -- Some of the original contribution's that BM has made to DBC are discussed in detail in OOSC2 and in a c.l.e. posting back in Mar 97. See following link which has been adapted from a newsgroup exchange to an `Eiffel Liberty' article titled: ``Eiffel's Design by Contract: Predecessors and Original Contributions'' at: http://www.progsoc.uts.edu.au/~geldridg/eiffel/liberty/v1/n1/bm/bmdbc.html -- In closing, Jim Cochrane (jtc@jupiter.milkyway.org) writes: ``Some of these languages may provide even more complete and sophisticated support for design by contract than Eiffel and Sather.'' BM has already indicated that much research has been done to extend DBC in the Eiffel context. There are references to this in OOSC2 and is supported by IFL (Intermediate Functional Language, from memory). Others have looked at extending Eiffel in this area. See: ``Putting More Formality into Software Development'' at: http://www.progsoc.uts.edu.au/~geldridg/cpp/ef8743.htm Finally, Jim Cochrane (jtc@jupiter.milkyway.org) writes: ``.. My guess is that other languages (besides Eiffel and Sather, the only ones I'm aware of that directly support design by contract) will appear that also support this technique and that chances are that at least one of them will become mainstream (in the sense of being perhaps as well-known as Java is today, hopefully without the hype.. It will be interesting to see what languages and techniques are being used 20 or 30 years from now..'' It took ten years to get from C++ to Java. From recent discussions it looks like where stuck with Java for another 10 years. Most people will never see past ``defensive is offensive'' and for this it is unlikely that another language will rise above the pack in relation to DBC. My view is that the field is young, but a language and method is already here to help us (it's been here 12 years for that fact). It's called Eiffel! Bertrand Meyer, deserves more credit, respect and support than that which is shown to him on Usenet. Send an email of support to him, he does not deserve the personal attackes he has had to endure. Geoff Eldridge -- geldridg@progsoc.uts.edu.au -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet