Re: Interresting thread in comp.lang.eiffel

["Ken Garlington" <Ken.Garlington@computer.org>]

"David K Allen" <dkallen@visi.com> 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.