Assurance for Temporal Compatibility Using Contracts

Introduction

A major component of quality in software is assurance: a system’s ability to perform its job according to the specification and to handle abnormal situations (McGraw, 1999). Assurance is particularly important in the CBSD method because of the special role given by the method to reusability. It is important to obtain reusable software components whose assurance can be trusted in order to create a reliable system from such components.

Reliable software systems can be built using several methods (Musa, 1999). Static typing, for example, is a major help for catching inconsistencies before they have had time to become defects. Reusability also helps, using component libraries produced and (presumably) validated, rather than developing new software for the same purpose. But this is not enough. To be sure that DCS will perform properly, a systematic approach to specifying and implementing object-oriented software elements and their relations in a software system is needed. One such approach is known as design by contract, in Beugnard & Jezequel, et al., 1999. Under the Design by Contract theory, a software system is viewed as a set of communicating components whose interaction is based on precisely defined specifications of the mutual obligations known as contracts. The design by contracts, in a way, is a mechanism to achieve the correctness, and thereby a higher assurance, by a construction paradigm advocated by Dijkstra (1975).

Some benefits of Design by Contract include the following:

• •

  A better understanding of the DCS.

• •

  A systematic approach to building defect-free DCS.

• •

  An effective framework for debugging, testing and, more generally assuring quality.

• •

  A method for documenting software components.

Typically, contracts for software components have been specified at the syntactical level, which provides a description of type information for a particular method of a component. In a DCS, many other aspects of a component need to be considered and hence, Kumari (2004) and Zaremski et al. (1997) have proposed a multi-level contract for components. It augments the basis syntactic level of contract with behavior, synchronization, and quality of service. Thus, the use of such a multi-level contract, during the design and development of a component, increases the assurance about a component provides a better assurance about a DCS made of such components.

The four levels of contract mentioned above are certainly important for developing a component that is to be used in a DCS; however, many DCS are time-sensitive. Hence, it is equally important to consider the timing constraints as a part of a multi-level contract for a component. Another level for component contracts called the temporal level, is proposed in Tilak (2006). In addition to providing the formal mechanism for describing the temporal level contract, Tilak (2006) also discusses the issues of compatibility and replaceability. This chapter presents the details related to the issue of compatibility and how it plays a role in providing timing-related assurance about DCS made from time-sensitive individual components.

This chapter is organized as follows. Section 2 presents a brief overview of the related work and section 3 gives the design details of the Temporal Interaction Contract specifications. Section 4 describes the algorithms to check compatibility between Temporal Interaction Contracts. Section 5 describes an example for an experimental analysis of these concepts. Section 6 provides the conclusion of this research work with the possible future enhancements.