I’ve been a longtime listener of podcasts but I’ve never really put any effort into finding a podcast that was relevant to software development. Until now, I never considered the convenience and benefits of being able to learn about my field of study through my headphones while I perform other tasks. In particular, I have been binge-listening Software Engineering radio because it is technical, topical, and informative while remaining pleasant to listen to. Today, I am going to review and give commentary on Episode 51 of the show.
The topic of this episode is the Design By Contract (DbC) software correctness methodology. One of the hosts of the show, Arno, defines DbC as a way of thinking about and designing interfaces that contain “contracts”. The contract is a metaphor; the idea is that you as the caller must meet the preconditions expected by the method, and the method must meet the postconditions expected by the caller. Arno gives the example of a square-root function:
– As the caller, you must meet the precondition of passing in a value that is zero or greater because of the inability to take square-roots of negative numbers.
– As the method, you must produce the value that, if multiplied by itself, is equal to the value passed in; this is expected by the caller.
Arno goes on to explain that, programatically, these preconditions and postconditions are boolean expressions that are listed in each method and must evaluate to true in order to perform their function. One benefit of designing software in this way is that you provide more provide a more precise specification of what a method does. Another benefit is that this prevents incorrect information from being displayed to the user; DbC evangelists believe that it is worse for the user to receive incorrect output than to not receive any output at all. There are downsides to DbC as well, Arno claims. He states that DbC runs into problems when implemented in a polymorphic system – subtypes of a supertype will inherit all of the contracts agreed upon by that supertype. Arno advises that if somebody wishes to begin designing their code in this way, the first step is to just begin thinking with a contract-oriented mindset. DbC functionality tools are not native to many languages so, if you wish to begin designing in this way in a language like Java, you must acquire them via a third party or start of by using assertions. Arno insists that assertions are not enough to truly implement DbC because you have to manually maintain the checks on postconditions as they will often change based on input.
I selected this episode to be the subject of a blog post because I think that it prescribes a pretty good method of designing quality software. By preventing incorrect input and output at a developer level, you reduce the workload of testers, allowing them to perform more rigorous and extensive testing of input. I have recently been doing a lot of research on various software development and design paradigms and one of the ones that I have dived into extensively is Agile. I feel that DbC is similar to an Agile approach because it entails a process of developers testing as they work, which generally produces a more sustainable and higher quality product. In my next blog post, I will elaborate further on developer testing and how it contributes to the production of high quality software.
This blog post(1/9) is part of an assignment for the Fall 2017 session of CS343 @ Worcester State University.
From the blog CS@Worcester – RM by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.
