Classifying Components by Behavioral Abstraction

We present an approach for classifying and retrieving reusable software based on exemplary descriptions of its functionality. The functionality of reusable components is described by a set of tuples with each tuple representing a characteristic input-output (or stimulus-response) transformation of the component at hand. With careful choice of these characteristic tuples, information equivalent to conventional formal speciications is given, except that (re-)users not versed in formal speciication can provide such queries. The concept just introduced depends on the dis-criminative potential of the tuples provided and on the equivalence of behavior representations by the librarian and by the (re-)user. The former can be assured by the librarians professionalism, the latter by an adequate user-interface of the system supporting a dialog, based on what the system has to ooer rather than on guesses about what the (re-)user is looking for. 1 Motivation We depart from the assumption that in black box reuse the user is not interested in retrieving a particular piece of code from a library of reusable components, but that his/her interest is the functionality needed. This func-tionality can be { and usually is { described by natural language descriptors or, on a more detailed level, by formal speciications. However, the former are in general too weak to select an appropriate component, and the latter are in general too complicated to write down for the requester. Based on the analogy of checking out books from open-stock libraries where catalogs provide just rough guidance and the nal decision of the reader is made after browsing through some books suitable for the question at hand, we bank on the operational semantics of software. In contrast to 1] we do not use randomly generated data. We rather focus on discriminatory tuples. As discussed in 2] we have to distinguish between the (re-)users intent and the speciic representational form used to describe this intent. Likewise, the component sought can be described at various levels of abstraction and in various representational forms. Considering the component itself, three broad categories stick out for its description: Textual algorithmic description: This is the conventional description of a component's source code, written in some compilable programming language. In general we may assume this textual description to be procedural code, ready for execution after com-pilation/interpretation. Predicative (intensional) description: This refers to formal speciications, irrespective of the language used. While speciications are text too, they are not linear text but a …