Verifying Behavioral Component Interoperability Using Positive/egative Model Checking Weimin Ma Dept. of Computer Science The Univ. of Texas at Dallas weiminma@utdallas.edu Lawrence Chung Dept. of Computer Science The Univ. of Texas at Dallas chung@utdallas.edu Kendra Cooper Dept. of Computer Science The Univ. of Texas at Dallas kcooper@utdallas.edu Abstract  Componentbased development needs to establish structural interoperability as well as behavioral interoperability among components. To solve a structural or behavioral mismatch, adapters are generally constructed using the basic scenarios, while ignoring the exceptional scenarios. This paper proposes an approach for extending or refining the integrated components, glued together using adapters, after basic scenarios have been considered. The approach examines the integrated components using exceptional scenarios. Furthermore, formal models for the integrated components are built and verified against safety and liveness properties derived from basic and exceptional scenarios. A traffic signal control system example is given to illustrate the approach. Keywords: Component, behavioral interoperability, positive/negative model, model checking 1. Introduction Componentbased development (CBD) has the potential of reducing effort and time, and taking advantage of the builtin qualities of constituent components. Usually the starting point is to assess the component’s structural interoperability in the interface attributes (name, type match) and interface operations (name, parameter list). A structural match cannot guarantee the sequences of communications among components are consistent. This leads to the assessment of behavioral component interoperability. Adaptors [1][2] are necessary when components are either structurally or behaviorally noninteroperable. Recent work in CBD has focused on the architecture of the components [3][4][5]. However, it is crucial to verify that the integrated components glued together using adapters realize the stakeholders’ requirements in terms of the communications among constituent components. Based on the proposal by Jackson and Zave [6][7], domain knowledge and specification together satisfy the requirements, i.e. D, S |= R, this paper proposes a methodology to address behavioral component interoperability. The behavioral specification of the integrated components consolidates individual component’s behavior, specified using UML statechart, through either basic scenarios (i.e. positive scenarios) or exceptional scenarios (i.e. negative scenarios). The specification of integrated components (i.e. specification model) built following the positive scenarios is a positive model, and the specification model built following the negative scenarios is a negative model. Our approach uses the notion of negative models in gaining insights about the behavior of a positive (i.e. desirably correct) or a negative (i.e. undesirable) model of integrated components. There are infinite number of causes that the positive model fails, and the search space can be reduced by examining the negative model. As shown in Figure 1, exceptional scenarios are depicted using the negative frame (i.e. neg sd) in UML sequence diagram. Scenarios weave the specification components into the specification of the integrated system (i.e. specification model). Properties extracted from sequence diagram, e.g., in the same direction traffic light and pedestrian signal shall not conflict, are checked against the specification model. Domain knowledge is used to specify external events. This paper concerns behavioral component interoperability on the requirements level. Therefore, component is defined as the requirementslevel specification in this paper. The definition of behavioral interoperability is defined as the ability of each individually workable component to be integrated into a system which can work properly with respect to both basic scenarios and negative scenarios. A specification is different from the requirements, as it specifies the general solution to the goals identified in the requirements. Requirements define the full functionalities of the system, which includes hardware and software. This paper benefits from the following related research. The proposal from Zave and Jackson [7] and Grosu and Smolka [8] lays the groundwork of the approach proposed in our paper. Zave and Jackson explain the precious nature of relationships among