Team Eiffel

At slashdot.org, there's a discussion running about why DBC is not more popular. Leland McInnes writes:

Design by Contract, writing pre- and post-conditions on functions, seemed like straightforward common sense to me. Such conditions, in the form of executable code, not only provide more exacting API documentation, but also provide a test harness ... despite being available (to varying degrees of completeness) for many languages other than Eiffel ... the concept has never gained significant traction, particularly in comparison to unit testing frameworks (which DbC complements nicely), and hype like 'Extreme Programming'. So why did Design by Contract fail to take off?

No doubt some TeamEiffel readers will have valuable comments to post at Slashdot...

Labels: dbc

Yves Le Traon, Benoit Baudry and Jean-Marc Jézéquel have written a very useful article on how DbC improves vigilance and diagnosability. It appeared in the IEEE Transactions of Software Engineering, vol 32, no. 8, August 2006 (yes, magazine somehow ended up at the bottom of my stack). Abstract:

Design by Contract is a lightweight technique for embedding elements of formal specification (such as invariants, pre and postconditions) into an object-oriented design. When contracts are made executable, they can play the role of embedded, online oracles. Executable contracts allow components to be responsive to erroneous states and, thus, may help in detecting and locating faults. In this paper, we define Vigilance as the degree to which a program is able to detect an erroneous state at runtime. Diagnosability represents the effort needed to locate a fault once it has been detected. In order to estimate the benefit of using Design by Contract, we formalize both notions of Vigilance and Diagnosability as software quality measures. The main steps of measure elaboration are given, from informal definitions of the factors to be measured to the mathematical model of the measures. As is the standard in this domain, the parameters are then fixed through actual measures, based on a mutation analysis in our case. Several measures are presented that reveal and estimate the contribution of contracts to the overall quality of a system in terms of vigilance and diagnosability.

The article uses the Franck's Pylon library, which isn't maintained anymore. The article would have even been more useful if the authors had looked at the widely used Gobo libraries.

Labels: dbc