Speci cation Matching of Software

Speciication matching is a way to compare two software components. In the context of software reuse and library retrieval, it can help determine whether one component can be substituted for another or how one can be modiied to t the requirements of the other. In the context of object-oriented programming , it can help determine when one type is a be-havioral subtype of another. In the context of system interoperability, it can help determine whether the interfaces of two components mismatch. We use formal speciications to describe the behavior of software components, and hence, to determine whether two components match. We give precise deenitions of not just exact match, but more relevantly , various avors of relaxed match. These deeni-tions capture the notions of generalization, specialization , substitutability, subtyping, and interoperability of software components. We write our formal speciications of components in terms of pre-and post-condition predicates. Thus, we rely on theorem proving to determine match and mismatch. We give examples from our implementation of speciication matching using the Larch Prover. Speciication matching is a process of determining if two software components are related. It underlies understanding this seemingly diverse set of questions: Retrieval. How can I retrieve a component from a software library based on its semantics, rather than syntactic structure? 0 Reuse. How might I adapt a component from a software library to t the needs of a given sub-system? Substitution. When can I replace one software component with another without aaecting the observable behavior of the entire system? Subtype. When is an object of one type a subtype of another? Interoperation. Why is it so diicult to make two independently developed components work together? In retrieval, we search for all library components that satisfy a given query. In reuse, we adapt a component to t its environmental constraints, based on how well the component meets our requirements. In substitution, we expect the behavior of one component to be observably equivalent to the other's; a special case of substitution is when a subtype object is the component substituting for the supertype object. In interoperation, we want one component to interact properly with the other. Common to answering these questions is deciding when one component matches another, where \matches" generically stands for \sat-isses," \meets," \is equivalent to," or \interacts properly with." Common to these kinds of matches is the need to characterize the dynamic behavior, i.e., semantics , of …