Design by Contract: building reliable software quippeth th basieoneptsof cassobectd you cn byo software modules that implement possibly parameterized types of data structures. Congratulations.This is a significant step in the quest for better software architectures. But the techniques seen so far are not sufficient to implement the comprehensive view of quality introduced at the beginning of this book.The quality factors on which we have concentrated-reusability,extendibility,compatibility-must not be attained at the expense of reliability (correctness and robustness).Although,as recalled next,the reliability concern was visible in many aspects of the discussion,we need more The need to pay more attention to the semantic properties of our classes will be particularly clear if you remember how classes were defined:as implementations of abstract data types.The classes seen so far consist of attributes and routines,which indeed represent the functions of an ADT specification.But an ADT is more than just a list of available operations:remember the role played by the semantic properties,as expressed by the axioms and preconditions.They are essential to capture the true nature of the type's instances.In studying classes,we have-temporarily-lost sight of this semantic aspect of the ADT concept.We will need to bring it back into the method if we want our software to be not just flexible and reusable,but also correct and robust. Assertions and the associated concepts,explained in this chapter,provide some of the answer.Although not foolproof,the mechanisms presented below provide the programmer with essential tools for expressing and validating correctness arguments.The key concept will be Design by Contract:viewing the relationship between a class and its clients as a formal agreement,expressing each party's rights and obligations.Only through such a precise definition of every module's claims and responsibilities can we hope to attain a significant degree of trust in large software systems. In reviewing these concepts,we shall also encounter a key problem of software engineering:how to deal with run-time errors-with contract violations.This leads to the subject of exception handling,covered in the next chapter.The distribution of roles between the two chapters roughly reflects the distinction between the two components of reliability;as you will recall,correctness was defined as the software's ability to perform according to its specification,and robustness as its ability to react to cases not included in the specification.Assertions (this chapter)generally cover correctness,and exceptions (next chapter)generally cover robustness.11 Design by Contract: building reliable software Equipped with the basic concepts of class, object and genericity, you can by now write software modules that implement possibly parameterized types of data structures. Congratulations. This is a significant step in the quest for better software architectures. But the techniques seen so far are not sufficient to implement the comprehensive view of quality introduced at the beginning of this book. The quality factors on which we have concentrated — reusability, extendibility, compatibility — must not be attained at the expense of reliability (correctness and robustness). Although, as recalled next, the reliability concern was visible in many aspects of the discussion, we need more. The need to pay more attention to the semantic properties of our classes will be particularly clear if you remember how classes were defined: as implementations of abstract data types. The classes seen so far consist of attributes and routines, which indeed represent the functions of an ADT specification. But an ADT is more than just a list of available operations: remember the role played by the semantic properties, as expressed by the axioms and preconditions. They are essential to capture the true nature of the type’s instances. In studying classes, we have — temporarily — lost sight of this semantic aspect of the ADT concept. We will need to bring it back into the method if we want our software to be not just flexible and reusable, but also correct and robust. Assertions and the associated concepts, explained in this chapter, provide some of the answer. Although not foolproof, the mechanisms presented below provide the programmer with essential tools for expressing and validating correctness arguments. The key concept will be Design by Contract: viewing the relationship between a class and its clients as a formal agreement, expressing each party’s rights and obligations. Only through such a precise definition of every module’s claims and responsibilities can we hope to attain a significant degree of trust in large software systems. In reviewing these concepts, we shall also encounter a key problem of software engineering: how to deal with run-time errors — with contract violations. This leads to the subject of exception handling, covered in the next chapter. The distribution of roles between the two chapters roughly reflects the distinction between the two components of reliability; as you will recall, correctness was defined as the software’s ability to perform according to its specification, and robustness as its ability to react to cases not included in the specification. Assertions (this chapter) generally cover correctness, and exceptions (next chapter) generally cover robustness