Re: Critique of Ariane 5 paper (finally!)

[Bertrand Meyer <Bertrand.Meyer@eiffel.com>]

W. Wesley Groleau wrote:
 
> what some people disagree with is the use of two definitions of
> DBC by the same advocates.
> 
> Def'n 1 - Associating specifications with software elements" and
> related practices.
> Def'n 2 - The Eiffel implementation of a subset of these practices.
> 
> Now before anyone denies having used definition 2,  please explain
> what definition of DBC satisfies the claim "only Eiffel directly
> supports DBC"

This has been explained many times. One can to some degree
apply the principles of Design by Contract in any language,
but among commercially commercially available languages Eiffel
is the only one to offer direct support for "associating
specifications with software elements" as part of the software
elements themselves, i.e. using language constructs --
preconditions, postconditions, class invariants, loop invariants,
loop variants.

In other languages you have to resort to purely methodological
guidelines or to comment conventions etc.
It's better than nothing, but does not go as far, because
the presence of the assertion constructs provides Eiffel
users  with major benefits such as: 

	- Documentation tools (in the supporting environments)
	  that extract the specification from the software.
	  Such tools provide a standard form of documentation
	  for reusable components and are essential to the success
	  of reusability efforts.
	  
	- Better reusable libraries (this too is a property
	  of the environments, made possible by the language)
	  thanks to their extensive
	  use of assertions (e.g. EiffelBase). Also,
	  these libraries naturally serve as models and
	  guides for users learning the approach, so they
	  indirectly lead to  more reliable and clearer
	  application software. 

	- Runtime assertion monitoring (again in the
	  environments) providing a particularly effective
	  tool for testing, debugging and quality assurance.

	- Language rules that associate assertions with
	  inheritance: precondition weakening and postcondition
	  strengthening in routine redefinitions, invariant
	  accumulation (a class inherits its parents'
	  integrity constraints). This is essential to
	  control the power of polymorphism and dynamic
	  binding, further decreasing bug sources.

	- Close connection with the exception handling
	  mechanism.

	- Simplification of the software's structure, since
	  supplier classes can avoid redundant checking
	  of special cases in the presence of preconditions.

	- General improvements in software quality: having
	  a construct in the language itself encourages
	  developers to use it -- especially, as noted, thanks to
	  the influence of reusable components --,  more so than
	  a purely methodological injunction to "be good"
	  and specify. In other words, use of Eiffel
	  helps promote a quality-oriented and
	  reliability-conscious mindset. This is a less
	  directly palpable benefit (and please do not
	  construe it as a claim that "Eiffel users make
	  no errors", no one ever said that) but significant
	  all the same.

Most of this is unique to Eiffel among widely used commercial
languages. Again it does not mean that you cannot get any benefit
of Design by Contract in other languages; you can (especially
if you have used Eiffel before: many people have noted that
you can become a better C++ programmer, for example, if you have
been trained in Eiffel; see e.g the educators' testimonials at
http://www.eiffel.com/services/university/). But you will
get much more in Eiffel.


-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with download instructions