Design by Contract: A Simple Story ..

Design by Contract: A Simple Story ..

[geldridg]

  [ 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

Re: Design by Contract: A Simple Story ..

[Samuel Mize]

I don't consider Geoff's post too far off-topic for comp.lang.ada,
as it's pointing people to look at a technology that's related to
ongoing discussions there.

However, I would ask that follow-ups that are general discussion
about Eiffel pare off comp.lang.ada (like in my follow-up line).

The reason comp.lang.ada is thrashing over the Ariane paper is
its claim (perhaps implied, perhaps unjustly inferred) that Ada
with normal design methods was inadequate to prevent the Ariane
5 loss.  Most of us are not arguing that Eiffel or DBC are
useless, just that this limited conclusion is flawed and unfair.
(Normal design methods were circumvented in that project.)

Geoff, I'm glad you've found something so useful for your work,
and I do consider it an interesting technology.

Samuel Mize