Specifications as Search Keys for Software Libraries

Searching through a large repository of objects can be a tedious activity if a user cannot easily identify the object of interest. If the object is a file stored in a campus-wide distributed file system, the user might need to know some part of its name, e.g., a partial pathname, and possibly its location, e.g., the host name of the file server. If the object is a database record, the user might need to know the record’s attribute names in order to formulate a query based on the attributes’ values. What if the object is a component in a program module library? We propose searching through software libraries using specificationmatching. We assume a specification, si, is associated with each component, pi, in a software library of i components. For example, a procedure’s specification might consist of a name, a signature, and a pair of preand post-conditions describing the procedure’s behavior. Specification matching is the process of determining whether for a given query, q, and specification, si, si satisfies q. For example, if the query and specification languages are both drawn from the same logical language, then satisfies is logical implication; specification matching is the process of showing an implication holds. The expressiveness of the query and specification languages will determine whether specification matching is decidable. At one extreme, as in traditional program verification, it might require some “heavy-duty” theorem proving with key insights provided by a human user. Through appropriate restrictions on the language and the meaning of satisfies, however, specification matching can be made practical and useful with or without any human guidance. This paper describes one instance of the more general idea of specification