Design by contracts: Correctness and Quality of

Software Product Quality Factors

There are various definitions offered by researchers and practitioners have divergent views on the subject. There is surprisingly little consensus even on quality definitions with respect to the most important artifact: the source code.

Quality is everything because everything is quality. Meyer provides a comprehensive set of primary quality factors that should cover everyone's viewpoint.

Meyer's Internal and External Software Product Quality Factors

Quality Factors What is it Correctness The ability of software to perform their exact tasks as defined by their specification. Robustness The ability of software systems to react appropriately to abnormal conditions. Efficiency The ability of a software system to place as few demands as possible on hardware resources such as processor time, internal and external memories and communication bandwidth. Ease of use The ease with which people of various backgrounds and qualifications can learn to use software products for their intended role. Functionality The extent of possibilities provided by a system. The applicability of software to solve a range of problems. Timeliness The ability of a software system to be made available when or before its users wants it. Cost The financial cost of developing or acquiring and using the software. Extendibility The ease of adapting software to changes of specification. Compatibility The ease of combining software elements with others. Portability The ease of transferring software products to various hardware and software environments. Reusability The ability of software elements to serve for the construction of many different applications. Understandability The ease with which a programmer can understand the source code of a software system. Testability The ease of testing a software system for correctness and robustness.

What is Defect? There are various definitions in the literature for 'software woes' such as 'bug', 'error', 'fault', 'failure', etc. For our purposes, we will simply use an all-encompassing definition:

Defect: A property of the software that can and should be improved.

Clearly our software development process should seek to minimize the number of defects in the product as early as possible. To achieve this various processes are applied as 'quality filters'. (Some are described later.)

This leads to the Defect Equation:

Di = Di-1 + Ii - Ri for i = 1,2,3,...

The number of defects remaining in the product after the ith development phase (Di) equals the number of defects remaining after the previous phase (Di-1) plus the number of defects injected during the ith phase (Ii) minus the number of defects removed during the ith phase (Ri). The goal is to minimize Di in the last iteration. That is, minimize the number of defects in the final version of the software that is released to users. Correctness of empirical programs

Programs are pieces of software designed for a particular aim. Each program has a required functionality which can be characterized through its behaviour under various circumstances. These circumstances affecting the behavior of a program are determined by the input it gets during run-time. The two crucial questions about software correctness are:

1. What exactly is the software supposed to do? 2. Is it is doing exactly what it is supposed to do?

Correctness is Relative to a Specification

Correctness: the ability of a software system to perform according to the specification, in cases defined by the specification. Robustness: the ability of a software system to react in a reasonable manner to cases not covered by the specification.

One main goals of every program is reliability, that is, correctness and robustness. A program is correct if it performs according to its specification, it is robust if it handles situation that were not covered in the specification in a graceful manner. One way to prove the correctness of a program with respect to a (formal) specification is the Hoare calculus.

Correctness Formula:

Meaning of the Correctness Formula: {P} A {Q}

Any execution of a started in a state satisfying P will terminate in a state satisfying Q

Based on this formal method developed a method of software engineering called which was introduced a decade ago in his definitive work, Object-Oriented Software Construction, and is a cornerstone of his Eiffel language.

Design by Contract: What is it all about?

Software development involves at least two groups of people.

 developer or producer  user or customer

The concept of design by contract makes use of a metaphor, according to which there is a contract between both groups for the use of the software. The contract describes under what conditions the software may be used and which tasks it is supposed to perform. These conditions and tasks can be considered rights and obligations for both parties.

An obligation for one group is a right for the other and vice versa. The producer promises to render the services as described in the contract provided the user promises to meet the conditions. The user gets a guarantee for these services provided he satisfies the conditions. The contract can thus be regarded as a specification of the software. The principal idea of Design by Contract (DBC) is that a class and its clients have a contract with each other: The client must guarantee certain conditions before calling a method specialized on the class (the ); the class guarantees certain properties after the call (the post conditions). If the pre- and post conditions are included in a form that the compiler can check, then any violation of the contract between caller and class can be detected immediately. Properties of Contracts  Binds two parties (or more): client, supplier  Is explicit (written): language  Specifies mutual obligations and benefits conditions  Usually maps obligation for one of the parties into benefit for the other, and conversely

Contracts consist of three primary attributes: Preconditions, Post conditions, and Invariants.

Attributes Description Preconditions Preconditions specify the responsibilities of the caller of some method. They typically specify the state of the object and/or the state and range of the method parameters. It is the responsibility of the caller to verify that the preconditions are satisfied before calling the method. If the preconditions cannot be met, the method should not be called. For this reason, code written with explicit pre-conditions usually uses little in the way of defensive programming; such programming is usually limited to avoiding gross program state corruption. If the is met, then the post conditions specify what services the method Post conditions must perform. This typically involves return values, object state change, or change to the parameters. It is the responsibilities of the method’s author to verify that post conditions are satisfied. Invariants Invariants are class wide conditions that are always true. Both the class and its clients should always be able to rely on these invariants being true. Note that it is permissible to 'temporarily' violate invariants within the scope of a method call, but the author must be certain that the is restored, no matter how the method terminates.

System Behavior Before proceeding to a logical design of how a software application will work, it is necessary to investigate and define its behavior as a “Black Box”. System Behavior is a description of what a system does, without explaining how it does it. Contracts are useful documents that describe system behavior in terms of what a system’s state changes are when a system operation is invoked.

Contracts The system sequence diagram shows the system events that an external actor generates (what), but does not elaborate how it will be achieved.

A contract can be used for a high-level system operation applied to entire system, or for a low-level method of a particular class. A system operation contract describes changes in the state of the overall system when operation is invoked.

How to make a contract

Apply the following advice to create contracts:

To make contracts for each : 1) Identify the system operations from the system sequence diagrams 2) For each system operation, construct an contract 3) Start by writing the Responsibilities section, information describing the purpose of the operation 4) Then complete the Post-conditions section, declaratively describing the state changes that occur to objects in the conceptual model 5) To describe the post-conditions, use the following categories: Instance Creation and Deletion Attribute modification Associations formed and broken

 Use notes section to discuss any design specific details, such as algorithms or the high level sequential steps  Use exceptions section to discuss the reaction to exceptional situations  Remember to establish a memory between existing objects or those newly created by defining the forming of an association.

Best Practices

Pre-conditions: Define assumptions about the state of the system at the beginning of the operations

Post-conditions: Expressed in a declarative state-change fashion and are expressed in the context of the conceptual model. Focus analytically on what must happen, rather than how it is to be accomplished.

Most common mistakes: The most common problem is forgetting the forming of association. Particularly when new instances were created. Contracts for system operations are part of the System Behavior Model:

Contracts for Buy Items Use Case:

Name enter Item (integer upc, integer quantity)

Responsibilities Enter sale of an item and add it to the sale. Display the item description and price.

Type System

Cross References

Notes Use superfast database access

Exceptions If the UPC is not valid, indicate that with an error

Output

Pre-Conditions UPC is know to the system

Post-Conditions  If a new sale, a Sale was created (instance creation)  If a new sale, the new sale was associated with Post(association formed)  A SalesLineItem was created (instance creation)  A SalesLineItem was associated with the Sale (association formed)  SalesLineItem.quantity was set to quantity (attribute modification)  The SalesLineItem was associated with a ProductSpecification, based on UPC match (association formed)

Conclusions The idea is that contracts should always express properties that should be satisfied by the final system implementation but that can or cannot be satisfied by the current system description (Specification, Design or Implementation). Thus, is it possible to have inconsistencies between a system description and its associated contract as well as inside a system description? The dangers of reuse without a contract have been illustrated by the 500 million-dollar failure of the Ariane 5 rocket which has been argued to result from reuse without a properly specified and checkable interface. While such news- worthy incidents highlight the vulnerable nature of software-controlled systems the real tragedy is the more subtle on-going industry-wide drain of human resources wasted due to poorly specified and/or uncheckable interfaces. To know whether a given component can be used within a certain context, there must be a way of telling what the component is supposed to do (its contract) without entering into the details of the how. The B. Meyer's Design by Contracts approach brings pragmatic and lightweight solutions for documentation and validation of software components; in particular, it's possible to adapt the development effort to the acceptable quality level.

Acknowledgement:

This article is inspired by [1] and [7] and my source of Diagrams and UML case studies are taken from these 2 sources. My article is dedicated to them and objective is to help creating better OO designs by Design By contracts.

Finally, a few words about Smartdraw 6.0 (www.smartdraw.com). An excellent software for any drawing solution. Diagrams are created using Smartdraw.

Bibliography and References :

1. Design By Contract: A Missing Link In The Quest For Quality Software Todd Plessel

2. Design by Contract: The Lessons of Ariane by Jean-Marc Jézéquel, IRISA and Bertrand Meyer, ISE 3. http://archive.eiffel.com/doc/manuals/technology/contract/ 4. Meyer, Bertrand, Object-Oriented Software Construction, Second Edition, Prentice Hall 5. Humphrey, Watts, A Discipline for Software Engineering, Addision-Wesley 6. Martin, Robert, "OO Design Quality Metrics," September, 1995. http://www.objectmentor.com/resources/articles/oodmetrc.pdf 7. Applying UML and Design Patterns An introduction to Object-Oriented Analysis and Design, Craig Larman