Software realization of a large-scale Distributed Computing System (DCS) is achieved through the Componentbased Software Development (CBSD) approach. A DCS consists of many autonomous components that interact with each other to coordinate each system activity. The need for such coordination, along with requirements such as heterogeneity, scalability, security, and availability, considerably increases the complexity of code in a distributed system. This chapter depicts a formal method to specify component interactions involving temporal constraints. Using the component interactions, various types of temporal interaction compatibility classes are defined. A simple case study is presented that indicates the benefits of the component interaction specifications discussed in this chapter.
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.
Key Terms in this Chapter
Distributed Computing Systems (DCS): A distributed computing system consists of networked processors, each with its own memory, that communicate with each other by sending messages.
Multi-level Contract: The multi-level contracts indicate contracts of a component as different levels, such as, syntax, semantics, synchronization, quality of service and temporal behavior.
Contract: A contract is the public interface of the component. Traditionally, a contract indicates the details of the methods a component supports.
Partial Temporal Compatibility: A component, as described by its Temporal Interaction Contract (TIC), T1, is said to be partially compatible to another TIC, T2, iff, some input message of T1 is contained by output messages of T2 or some output message of T1 is contained by input messages of T2.
Complete Compatibility: A component, as described by its Temporal Interaction Contract (TIC) T1, is said to be completely compatible to another TIC, T2, iff, starting from the initial state, every input message of T1 can be contained by an output message of T2 or every output message of T1 can be contained by an input message of T2.
Component: An encapsulated software piece that has a private state and public behavior as shown by its interface.
Temporal Interaction Contract (TIC): TIC is software component contract which highlights temporal dependencies involved in the execution of a component.
Temporal Logic of Actions (TLA): TLA is a technique for specifying the behavior of concurrent systems.