Usefullness of design-by-contract (was Re: The stupidity of all the Ariane 5 analysts.)

[jtc@jupiter.milkyway.org (Jim Cochrane)]

In article <33d38a16.195337670@news.geccs.gecm.com>,
Ian Begg <ian.begg@gecm.com> wrote:
>On Sun, 20 Jul 1997 14:26:19 -0700, Bertrand Meyer
><Bertrand.Meyer@eiffel.com> wrote:
>  ...
>> ...
>>    some of
>>	  the Ada enthusiasts in these newsgroups have
>>	  mistakenly taken the mention of Ariane as a personal
>>	  affront on their language. The pitch, if any, is for
>>	  the method of Design by Contract. 
>
>How many languages support Design by Contract as part of the language
>as in the case of Eiffel?  I don't have experience of a broad range of
>languages so I can't answer this.  However, if the answer is only
>Eiffel, (plus perhaps some other non relevant langauges) then it is
>not difficult to see how people might interpret your motives as "OK we
>can't be so obvious as to say Eiffel is the answer, but if we say
>Design by Contract is the answer, people will need to find a language
>to support it, hence Eiffel."  You are the only person who knows your
>real motives, but the discussions going on suggest some people are
>interpreting your motives in this way.

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.

Regardless of what Dr. Meyer's motives are, I think there are some
basic assumptions underlying this discussion that some people are
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.


One point of the discussion, I believe, is that the method implied in
the above assumptions is a tool to use along with other valuable tools in
producing high-quality software; it does not replace other usefull tools
such as a good test method and plan - rather, it complements them.

Now perhaps I am biased and am not aware of valid counterarguments, but
I am not able to see how the method that would result from making use
of these assumptions, called design-by-contract in this discussion, would
not significantly increase the quality of a system of substantial size, in
the sense of producing a system that correctly fulfills its requirements.

Assuming that their are no valid counterarguments (if there are, I'm sure
people will post them), the discussion comes down to how practical it
is to implement and use an environment that supports design by contract.

As far as assumption 1., applying precise specifications for component
interfaces, the usefullness and practicality of this technique seems
obvious and just visualizing the consequences of not doing this (for
example, increased time spent figuring out what a component does,
developers' time wasted informing other developers what the interface
specification of a component is, errors in coding due to misunderstanding
an undocumented specification) should be enough to convince anyone that it
would be foolish not to apply this technique on any significant project.

The practicality of applying assumptions 2 and 3 is perhaps not as
obvious as the first assumption, but strong reasons do exist to support
their practicality.  First, coding interface specifications combined
with a good test plan will increase the chance of uncovering defects
and decrease the cost of fixing them (since it is well known that
the later a defect is found, the more it will cost to fix).  Also, using an
environment that provides rich support for the documenting and coding
of interface specifications will make it easier and less time consuming
and thus more practical for developers to use this technique.  Finally,
using such an environment would provide an infrastructure that would
allow development organizations to make the technique of design
by contract a formal part of the development process and thus make the
components of this technique - precise, complete, and testable
specifications - a part of the culture of the development organization,
so that the techniques used to produce high quality software become
habitual (in a positive sense), rather than being something foreign that
is forced upon the developers.

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.  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).  Some of these languages may
provide even more complete and sophisticated support for design by contract
than Eiffel and Sather.  It will be interesting to see what languages
and techniques are being used 20 or 30 years from now (for those of us
who are not retired or dead, that is :-) ).


Jim Cochrane
jtc@dimensional.com