Design by contract

The software development became a crucial parts of the computing field and our lives in general, programs are everywhere; Handling, storing and dealing with personal and critical data about people, business or any entities. Some programs occupy a very safety critical part of a specific process, where others deal with more confidential and crucial information; for all this reasons, it is important to test and correct any possible bugs of software before or during its use. In fact, it’s not enough to build good programs that process and perform the expected tasks well, we should also check for their behavior in different contexts and have in place a good tests plan in order to determine and find any possible bug (whatever might be its impact).

Design by contract is an important methodology in the software engineering field, it is mostly based on pre and post conditions of review that modifications made by a piece of program. Also known as Contract programming or programming by contract is not a technic or a set of tools, it is instead a method or approach in a certain way that help and facilitate conducting different set of tests
As mentioned by Meyer, the contribution of design by contract is “the definition of coherent set of methodological principles to produce correct software with less errors and a systematic approach to the delicate problem of how to deal with abnormal cases” (Meyer, 1992).

The principle idea behind the DbC is that classes and clients are linked with contracts, the clients must satisfy some conditions before calling the class’ methods while this last in return guarantees also certain properties after the call(Leavens & Cheon, 2006). The main difference between DbC and ‘classic’ software tests method is that contracts are defined by program code, and are translated into executable code by the compiler.

If we review carefully the definition, we might note that the consistency and reliability of the methods is being tested based on pre and post conditions. If a test fails, an exception handling should be performed. This might sound not enough to guarantee that the method can’t present any issues or bugs. Errors related to the inner implementation of the algorithm being executed internally cannot be caught by pre and post conditions.

Do you think that this focus on testing pre- and post- conditions will lead to more robust software?
I personally do not think so, the pre- and post- conditions are not the only factor and deterministic criteria to guarantee the robustness of software. Any software program should be tested in different situations and different contexts and not only for pre and post conditions.

Do you think that writing specifications as testable expressions will make it easier or more difficult to understand what an operation is supposed to do?
Here is a good example of a contract for the square method that accepts a number and calculates its square.

Figure 1 : Sqrt method with contract.

We can remark that the contract’s definition is not and easy or simple to understand for the first time, it might require more efforts and specific syntax definition as stated before, this contract is translated to an executable code. My personal point of view is that writing contracts makes it more difficult.

Finally, I personally think that the DbC should be used as part of the global tests plan and not be trusted as the only guarantee of software reliability.

References:

– Bertrand Meyer (1992). Applying “Design by Contract”.IEEE, 0018-9162/92. Available at:http://se.ethz.ch/~meyer/publications/computer/contract.pdf .

– Gary T. Leavens, Yoonsik Cheon (2006). Design by Contract with JML. Department of Computer Science Iowa State University. Available at: ftp://ftp.cs.iastate.edu/pub/leavens/JML/jmldbc.pdf

– Unknown (2012). Design by contract. Available online at: http://c2.com/cgi/wiki?DesignByContract