Home Software Engineering Design by Contract

Design by Contract

‘Design by Contract’ both improves the design and reliability of software, but it does so at a cost.  It has been demonstrated that design by contract could have averted some the software industries biggest disasters. However it is important to realize that it is only a technique and not a “silver bullet”, whilst used appropriately it contribution to software quality can be significant, there is a myriad of other contributing factors , that it does not address

Design by Contract is not an agile practice, whilst it is true that agile practice like XP embrace activities such as Test Driven Development,  which offer similar attitudes towards  test coverage the emphasis and the actual approach is different.  The requirement for documentation can also be considered in conflict with agile principles.  Although Meyer suggests that much of this can be generated if developers are disciplined.  (Meyer, 1992) However the only way of verifying discipline is “expensive” code inspections.

The principle of Design by Contract require that function assert both pre  and post conditions.  Whist languages like Eiffel possessed these capabilities for the start,  until relatively recently many mainstream languages, java included had no means to implement assertions directly within the language.  To achieve similar results they would have to resource to using exceptions with the appropriate level of “defensive coding”.  An approach which at times has proven to be self defeating.(Meyer, 1992).   Indeed Jazequel and Mayer suggests that Design by Contract could have prevented the infamous Arianne disaster(Jazequel & Meyer, 1997), but their example once again is Eiffel biased and they are quick to point out that Ada, the language user for Arianne, had no  build in support  these constructs.

Design by Contract weakens some of the Object Oriented paradigms, basic principals, such as encapsulation.   If the code require to implement the assertions is require to access the internal part of an object it them becomes bound to the implementation and not independent of it.   Modification to the implementation would require modification to the assertions.  To get around these problems it has bee suggested the only public attributes and methods should be used, however this may well mean the public interface of an object is require to be changes and internals exposed to satisfy the assertions.(Cheon et al., 2005)  This vicious cycle now changes the external interface and opens up new contracts that require asserting!   Further; classes are now given an added responsibility that is an implementation requirements and not part of the origin business domain.

With respect the production of, Barry Boehm is quick to point out that up to a 75%  reduction of  defects introduced can be achieved  can through personnel discipline rather that any specific technique.(Boehm & Papaccio, 1988)   No testing technique can proves there are no defects Testing can only show the presence of errors it is designed to detect.  Contract assertions are invariable equally venerable, it can only assert what has been specified.  An incomplete specification is an incomplete assertion.

Design by Contract,  is capable of offering improved quality,  But it requires the introduction of additional code  require to validate the assertion and handle the exceptions.    This code itself is subject to the possibility of errors.  Improvements in quality that arise for the use of these techniques come at a cost and an increase of complexity.



Boehm, B.W. & Papaccio, P.N. (1988) ‘Understanding and controlling software costs’, Software Engineering, IEEE Transactions on, 14 (10), pp. 1462-1477.Doi: 10.1109/32.6191

Cheon, Y., Leavens, G., Sitaraman, M. & Edwards, S. (2005) Model variables: cleanly supporting abstraction in design by contract: Research Articles’, pp.583-599, [Online]. (Accessed: 2-6-20009).Doi http://dx.doi.org/10.1002/spe.v35:6

Jazequel, J.M. & Meyer, B. (1997) ‘Design by contract: the lessons of Ariane’, IEEE Computer, 30 (1), pp. 129-130.Doi: 10.1109/2.562936

Meyer, B. (1992) Applying `design by contract”, IEEE, pp.40-51, [Online]. (Accessed: 21-6-2009).Doi 10.1109/2.161279



 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
Comments Off on Design by Contract  comments