Design by contracts: Correctness and Quality of software 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 software engineering 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 Bertrand Meyer developed a method of software engineering called Design by Contract 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 preconditions); 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 precondition 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 invariant 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 use case: 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