Critique of Ariane 5 paper (finally)

[adaworks@netcom.com (AdaWorks)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3649 bytes --]


From: Richard Riehle
To:   DBC Discussion

Design by Contract (DBC) is a powerful idea.  It is more powerful than
the notion of assertions, alone. Although, I believe assertions can
be an important aspect of DBC, restricting our discussion to assertions
probably leads us to taking too small a view of DBC.    

I think DBC includes:

  1) Explicit separation of the contract from the implementation
  2) Ability to maximize contract violations at compile time
  3) Clear statement to client of the contract of what is promised
  4) Conditions under which the contract would be violated
  5) Conditions under which the contract would be broken
 
�There are probably others.

Ada supports all five of these in very important ways. In particular,
Ada provides the superb support for 1), separation of contract
from implementation through the specification/body model for packages.
Number 2) is also a strong point of Ada because the language is designed
with exactly that goal in mind.  

To expand a little on item number 2). No programming language is
more effective at supporting this than Ada. The package specification 
rigorously defines the profile of every public method (subprogram) thereby 
permitting strict compile-time checking on any call; the scope and
visibility rules, draconion in the view of some programmers, prevents
a client from falling into some ambiguity trap,  concientious use of
named association further ensures compile-time checking, the type
model guarantees that collisons between incompatible data elements
will not occur, and the accessiblity rules raise the probability that
pointer-related errors will be caught at compile time.

Number three implies both traceability and understandability. This is
well-supported in Ada through both the scope and visibility rules and
the separation of the contract into a visible part and a non-visible
part.  The addition of private children in Ada 95 allows us to improve
upon this even further.  Ada does not take a back seat to any other
language on this point, even though Eiffel also supports this 
very well.

The fourth and fifth points are closely-related yet subtly different.
For this discussion, we consider them together.  Ada has taken a more
conservative view of the contract than some languages.  The type-safe
model does include an invariant for the type.  It also includes a
simple pre- and post-condition in the form of range constraints. While
this is not as sophisticated as explicit assertions, it works quite
well when coupled with the other rules for subprogram invocation and
visibility control.  

All of that begin said, I do like the idea of adding assertions to
Ada as additional support for 5) & 6).  It is important to realize,
though, that an assertion may be incorrectly stated more easily than
one would like.  A wrongly-formed assertion might be more of a problem
than no assertion at all.  

We would probably profit from exploring the DBC notion in greater
depth.  But the benfits from that exploration will be greatest if
we define it a higher level of abstraction than simple assertions.
I think Bertrand would agree with this "assertion".  
I hope others will.

Richard Riehle
AdaWorks
Suite 30
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815

                    P.S. My News Server is acting funny right now so
                         it is difficult for me to respond directly to
                         postings until it gets fixed.
                                               RR

 
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 30
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112