#12. Always keep correctness in mind

-

Bertrand Meyer starts the first chapter of his book Object Oriented Software Construction, 2nd Edition with the following sentence:
Engineering seeks quality; software engineering is the production of quality software.
He goes on to analyze the concept of software quality throughout the chapter. He defines it as a combination of several factors, some external (observable by the users of the software) and other internal (observable only by those who have access to its source code).

External software quality factors are correctness, robustness, extendibility, reusability, compatibility, efficiency, portability, ease of use, functionality and timeliness. All of these are important and should be balanced one against the other. But one clearly stands out among them: correctness. Quoting [Meyer 1997] again:
Correctness is the ability of software products to perform their exact tasks, as defined by their specification.
If a software is not correct, everything else matters little. Correctness should never be compromised for other quality factors.

Since correctness is defined as relative to a specification, it cannot be evaluated without it. When you use a software, you may appreciate its qualities, you may find something which doesn't work, you may consider it a good software product overall, but you cannot formally state whether it is correct.

When you work as a programmer, it is your job to guarantee that the software is correct.

Correctness must spread through your software, and apply to all of its parts. If the architecture of a software project divides it into several layers and modules, such as the user interface, a business logic... correctness must be accordingly defined for all of them, and must be the guiding light to ensure all of them are designed appropriately.

The software requirements specification is hence not enough. It serves the purpose of defining correctness for the full software product. But when this product is divided into layers and building blocks, correctness must also be established for all those layers and building blocks. A modular design affects not only the source code, but also the specifications.

Hence a correct software product is made of correct layers or clusters, these are made of correct modules (classes, in object oriented software construction), and these are made of correct procedures. And this division must include three elements:

  • The definition of correctness.
  • The software code.
  • The verification of the code against the definition of correctness.
Always keep correctness in mind. Never leave it behind.

Bibliography

[Meyer 1997]
Bertrand Meyer: Object-Oriented Software Construction, 2nd Edition, Prentice Hall, 1997.

If you want to know more about correctness, read this book.

Comments

Post a Comment

Popular posts from this blog

#2. Make all type conversions explicit

-
Assignments, function calls and expressions in general should not contain implicit type conversions. All type conversions should be explicit. Type conversions should be isolated in their own line, which should consist only of the assignment of the result of the type conversion to a variable of the target type. A statement should not mix type conversion with other operations. For example, if you need to convert an object to one of another type to pass it as a function parameter, do not do it in the function call itself; instead, do it in a separate instruction in the previous line. Type conversion occurs when an entity of type A is, well, converted to an entity of type B. This may occur in function calls, expressions using operators, or assignments. An explicit type conversion is one which you can read in the code. An implicit type conversion is one which does not appear in the source code, but is done automatically when the software is executed. Making all type conversi
Read more

Welcome to The Deep Blue C++

-
Image
During my years as a software engineer, I have learnt quite a lot of things - and I keep learning every day. I learn from practice, discussions with workmates, reading... I especially learn from mistakes: code that doesn't do what I expect, code that doesn't do anything at all, code that does it but with some occasional crash or two... If you're a programmer, you know what I'm talking about. What I've learnt has substantially changed the way I write code. In my first years as a programmer I tried to avoid mistakes, but I hadn't made enough of them yet to discover the best ways to prevent them. Now I know better. I know there are some things that bring you into trouble very quickly. Other things will silently wait for the worst moment - maybe months or years later, to come to the surface in the form of even more original problems. Disorganized code, uninitialized variables, pointer arithmetics, implicit casts, syntactic overloading, inheritance in which
Read more

#13. Organize your code in classes

-
The minimal unit of code is a statement . The minimal unit of code which can be tested and reused is a function . Functions are rarely practical all by themselves; they are usually organized in modules which offer a set of operations which make as a whole. The class is the main semantical unit in object oriented programming. A class is an abstract data type with an associated implementation. As Bertrand Meyer puts it in Object Oriented Software Construction, 2nd Edition : Classes should be the only modules. These concepts will not be obvious in the integrated development environment you use to create your code. Usually, these IDEs let you create projects, and inside them, they let you add units or files. You know, of course, the C++ syntax; you know there are two keywords, class and struct , that let you define a type with its associated data members (fields) and operations (functions). You are probably aware of the difference between class and struct : the default visibili
Read more