SOFTWARE VERIFICATION RESEARCH CENTRE DEPARTMENT OF COMPUTER SCIENCE THE UNIVERSITY OF QUEENSLAND Queensland 4072 Australia TECHNICAL REPORT No. 95-41 A Unifying Model for Retrieval from Reusable Software Libraries Steven Atkinson December 1995 Phone : +61 7 3365 1003 Fax : +61 7 3365 1533 Note : Most SVRC technical reports are available via anonymous ftp , from ftp.cs.uq.edu.au in the directory / pub/SVRC/techreports . A Unifying Model for Retrieval from Reusable Software Libraries Steven Atkinson Software Verification Research Centre Department of Computer Science University of Queensland QLD 4072 AUSTRALIA Phone : +61 7 3365 1003 Fax : +61 7 3365 1533 E-mail : atkis@cs.uq.edu.au Abstract The central problem associated with libraries of reusable software components is that of retrieval : how to find in the library those components that can be used in the construction of a particular application . There have been three major proposed solutions to this problem : faceted -LRB- classification -RRB- , signaturematching -LRB- structural -RRB- and behavioural -LRB- functional -RRB- retrieval . The aim of this paper is to unify these existing approaches to the component retrieval problem into a formally specified framework , providing a model upon which meaningful comparisons are made and principles formulated . 1 Introduction The problem of retrieval from component libraries has long been considered to be the central technical issue surrounding the task of software library construction -LSB- 15 , 2 -RSB- . However the recent movement towards organization and domain-specific software reuse strategies has simplified the retrieval problem by narrowing the scope of the universe of discourse . This has enabled specialist techniques such as domainmodelling -LSB- 21 -RSB- and controlled-vocabulary -LSB- 8 -RSB- retrieval methods to be applied with some success . However there remains the desire to develop software retrieval strategies suited for large scale domain-spanning repositories -LSB- 7 , 11 -RSB- . In such an environment , there are obvious advantages to having many retrieval methods available , the major advantage being that of maximizing assistance to the library searcher in locating components of interest . The aim of this paper is to unify existing approaches to the component retrieval problem into a formally specified framework , providing a model upon which meaningful comparisons are made and principles formulated . The formal framework developed is useful not only for comparing retrieval methods but also as a common model in which to implement software library retrieval systems . However , the focus in this paper is on using the model to compare existing retrieval methods , rather than implement a retrieval system . There exists a spectrum of retrieval methods , based upon the nature of the indices used as representations of -LRB- i.e. surrogates for -RRB- components . 1 . External Indices : Keywords , faceted -LSB- 22 -RSB- and feature-based -LSB- 3 -RSB- classification techniques all seek to find relevant components based upon controlled vocabularies , properties and ontologies external to the component ; 2 . Internal Static Indices : Structural-matching techniques , notably signature -LSB- 25 -RSB- and specification matching -LSB- 12 , 23 -RSB- , seek to find relevant components based upon elements of the structure of software components ; 3 . Internal Dynamic Indices : Behavioural retrieval techniques seek to take advantage of the distinguishing property of software | executability . Behaviourbased techniques -LSB- 1 , 18 , 10 -RSB- seek to find relevant components by comparing input and output spaces of components . The retrieval methods formally specified in this paper each exemplify an approach from each of the above three points on the spectrum . The rest of this paper is organized as follows . Section 2 presents an abstract model of the retrieval process , which is used as the basis for the formal models of each of the three retrieval methods presented in Sections 3-5 . Section 6 uses the formal models to identify a number of similarities and differences , and to formulate important principles . The paper concludes with a summary of the issues raised by the formal models . Throughout this paper , the Z notation is used to specify concepts . In the main , Z is much like standard mathematical notation ; readers unfamiliar with the notation may wish to consult -LSB- 19 , 24 -RSB- . 2 An Abstract Retrieval Model In this section an abstract model of retrieval is formalized . This model comprises the concepts that occur in any retrieval method . Any retrieval method must have a view of what a library is , what queries and components are , how the components are ordered , and how indices are compared to find components that most closely match a given query . The goal of this abstract model is to provide an architecture that can be instantiated to describe concrete retrieval methods . A query is a description of an information need supplied by a library searcher . A component is a software artifact residing in a library . The concept of retrieval does not depend on the exact nature of queries or components , but merely that queries and components exist . Hence in this abstract model it is assumed that Query and Component are given types : -LSB- Query -RSB- -LSB- Component -RSB- Retrieval methods depend upon an ability to order components in the library . Therefore in this abstract model it is assumed that an ordering mechanism is a given type : -LSB- Ordering -RSB- A retrieval environment -LRB- Env -RRB- consists of a component library to search -LRB- Library -RRB- , and an ordering over components -LRB- Ordering -RRB- to enable comparison of components . At this level of abstraction , a library is viewed as a set of components which can be ordered using an ordering from an environment ; no further structure is assumed . Library == PComponent Env == Library ? Ordering The goal of retrieval is to select those components out of a library which best match a given query . This general concept is formalized as the function retrieve below . retrieve : Env ? Query ! Library 8 -LRB- ae ; q -RRB- : Env ? Query ffl retrieve -LRB- ae ; q -RRB- = fc : first -LRB- ae -RRB- j c 2 match -LRB- ae ; q -RRB- g When provided with a retrieval environment ae and a query q , the retrieve function returns a set of components c -LRB- i.e. a library -RRB- , derived from the library provided in ae , which best match the query q . The goal of matching a query and component is to measure similarity , with the notion of similarity being quantified differently for each retrieval method . The general concept of matching a query and component is formalized as the function match below . match : Env ? Query ! Library 8 ae : Env ; q : Query ; c : Component ffl c 2 match -LRB- ae ; q -RRB- , F -LSB- ae ; q ; c -RSB- Within a retrieval environment ae , a query q and a component c are said to match if some formula F involving ae , q and c holds . The precise nature of the formula is not of concern at this level of abstraction ; such details will be provided by each instantiation of this abstract model . In order to define a formal model of a retrieval method by instantiating the abstract architecture presented above , the following definitions must be provided and their requirements met : ffl Query and Component : formal representations for queries and components must be given . These representations must meaningfully characterize the view of queries and components taken by the retrieval method being defined ; ffl Ordering : the formal definition of component ordering must be made in such a way as to allow components to be ordered for comparison . Obviously the precise nature of the ordering depends upon the representation of a component . ffl match : a formula , which when given a query , selects components from an ordered library -LRB- i.e. Env -RRB- must be provided . This depends on the above three definitions for queries , components and the ordering . The next three sections present formal models for faceted , signature-matching and behavioural retrieval methods . Each model is an instantiation of the abstract model discussed in this section . 3 Faceted Retrieval In this section a formal model for faceted retrieval is presented . The model is based upon the scheme proposed in -LSB- 22 -RSB- . Faceted classification schemes for software reuse consist of a collection of facets , or classifications , which represent the type of information that is relevant for identifying reusable components . Each facet has an associated term-space , which is an ordered collection of terms used to describe aspects of a facet . For example , one facet of a software component may be the kind of object the component acts upon . Such a facet may be called Object and a term in its term space may be Stack . All components that could be used to affect a Stack in some way would have the term Stack in their Object facet . Prieto-Diaz 's classification system -LSB- 20 -RSB- for software reuse is the best known system based on a faceted scheme . Six facets for describing software components were chosen ; three describe component functionality and three describe component environment . They are Function , Object , Medium , System-Type , Functional - Area and Setting . The term-space of each of these facets contain words depicting allowable values for the facet -LRB- e.g. \ Locate '' , \ Regular Expression '' , \ File '' , \ Line Editor '' , \ Editing '' , \ Laboratory '' -RRB- . Each software component is represented by a function which yields one term for each facet which best describes that facet of the component . Formally , there exists a set of names denoting facets and a set of basic terms used to define term spaces . Let -LSB- Name -RSB- and -LSB- Term -RSB- denote the sets of all such names and terms . A facet comprises a named collection of terms , hence define Facet == Name ? PTerm : In order to completely model a faceted classification scheme , concrete representations for a query , component , ordering and a matching formula must be defined . A query takes the form of a function from facet Names to terms , thus Query == Name 7 ! Term : For example , a query issued by a library searcher looking for a regular expression locator component may be : -LRB- Function -- > `` Locate '' , Object -- > `` Regular Expression '' , Medium -- > `` File '' , System -- > `` Line Editor '' -RRB- In order to increase the recall1 of a query , faceted retrieval defines orderings on terms . For each facet -LRB- i.e. collection of terms -RRB- a relationship on terms is defined that relates terms with similar meanings . Effectively , this yields a thesaurus for each facet . Such term orderings can be pre-computed for a domain by the software librarian . Formally , the term orderings are represented as a function from facet Names to a relationship between terms : Ordering == Name ! -LRB- Term $ Term -RRB- : Suppose the following -LRB- incomplete -RRB- ordering was in the retrieval environment when the above query was issued : -LRB- Function -- > -LCB- -LRB- `` Search '' , `` Locate '' -RRB- , ... -RCB- Object -- > -LCB- -LRB- `` Pattern '' , `` Regular Expression '' -RRB- , ... -RCB- Medium -- > -LCB- -LRB- `` File System '' , `` Line Editor '' -RRB- , ... -RCB- . . -RRB- The library may then respond to the query with the most suitable candidate component , the grep utility , which is described as : -LRB- Function -- > `` Search '' , Object -- > `` Pattern '' , Medium -- > `` File '' , System -- > `` File System '' , Area -- > `` Editing '' , Setting -- > `` Software Engineering '' -RRB- As the component above shows , faceted retrieval models components as functions from facet Names to terms , hence Component == Name 7 ! Term : Additionally , it can be seen that the ordering has had a role to play in this retrieval , since the pairs of terms in the ordering for each facet correspond to the different terms used in the query and component . There are many matching mechanisms for faceted classification schemes , many of which are metrics based on weights of facets and thesaurus relationships . However , 1Recall is the ratio of the number of relevant items found using a query over the number of relevant items . while the modelling of such extensions is possible within the abstract model of Section 2 , it is beyond the scope of the paper . Specified here is the simplest form of faceted-classification matching . That is , a query q is said to match a component c if a matching term for each facet f of q can be found in the corresponding facet g of c , where the matching is relaxed via an ordering -LRB- i.e. a term thesaurus -RRB- for each facet 's term space . This is expressed formally by the function match : match : Env ? Query ! Library 8 -LRB- L ; O -RRB- : Env ; q : Query ; c : Component ffl c 2 match -LRB- -LRB- L ; O -RRB- ; q -RRB- , 8 f : dom q ffl 9 g : dom c ffl f = g ^ -LRB- q -LRB- f -RRB- ; c -LRB- g -RRB- -RRB- 2 O -LRB- f -RRB- The variances between inputs and outputs of faceted retrieval provide useful information about how to adapt components retrieved so that they can operate in the context implied by a query . The adaptation guidelines derived from these variances can be pre-computed by a software librarian , in much the same way as term orderings are pre-computed . Faceted-classification retrieval schemes are one of many retrieval methods based upon external classification of software components . Examples of similar external classification schemes include retrieval using frames -LSB- 4 -RSB- , features -LSB- 3 -RSB- , descriptors -LSB- 16 -RSB- and lexical affinity -LSB- 14 -RSB- . The formal model presented here could be modified and extended within the abstract framework of Section 2 to model these retrieval methods as well . 4 Signature-Matching Retrieval In this section a formal model for a signature-matching retrieval is presented . The model is based upon the scheme proposed in -LSB- 25 -RSB- . The signature-matching scheme for reuse of module components primarily relies upon type-matching under typetransformations . Modules of functions are represented by a multiset of function signatures , where a function signature records the input and output types of a function in a module . Underlying signature-matching schemes is the assumption that a set of allowable types used to construct signatures in the system is known . Let Type denote such a set . It is assumed that the set Type includes ffl simple types -LRB- e.g. integers , naturals -RRB- ; ffl constructed types -LRB- i.e. using constructors such as \ ! '' for constructing types from other types -RRB- ; ffl user-defined types -LRB- i.e. domain-specific programmed types -RRB- ; and ffl type variables -LRB- e.g. type variable may placehold for any type -RRB- . The signature of a function is represented as a constructed type , hence define : Signature == Type Exact equivalence between signatures can be weakened by introducing transformations on types that preserve the types , but change their structure . Such transformations are introduced in order to increase the recall of signature-matching by allowing type-matching between transformed types . A type transformation is modelled as a relation between Types : TypeTransform == Type $ Type Examples of type transformations used in -LSB- 25 -RSB- are : flip ; curry ; uncurry ; generalize ; specialize : TypeTransform Type transformations will be used in the definition of the matching formula given later in this section . In order to complete the model of a signature-matching retrieval method , concrete representations for a query , component , ordering and a matching formula must be defined . A query takes the form of a multiset of signatures , where the multiset represents the function signatures of the desired module . The query is a multiset because one may wish to search for a module containing distinct functions with the same signature . Formally , a query is represented as : Query == bag Signature For example , a query issued by a library searcher looking for a module that controls a set of integers may be2 : -LSB- -LSB- construct : nil ! ff ; add : integer ? ! ff ; remove : integer ? ! -RSB- -RSB- In order to increase the recall of a query , signature-matching retrieval requires an ordering on types . Such a relationship on the set Type relates types based upon the similarity of their operational behaviour and their generalization/specialization 2The named labels for each signature in the query are included for clarity ; the labels are not significant when matching signatures . relationship . This relationship on Type can be pre-computed by a software librarian for particular domains . Formally , the ordering on Type is represented as : Ordering == Type $ Type : Suppose the following -LRB- incomplete -RRB- ordering was in the retrieval environment when the above query was issued : f -LRB- integer ; real -RRB- ; -LRB- ff ; -RRB- ; : : : : : g The library may then respond to the query above with the most suitable candidate , a module controlling sets of real numbers , which is represented as : -LSB- -LSB- construct : nil ! ; add : real ! ! ; remove : real ! ! -RSB- -RSB- As the component in the example above shows , components are also represented as multisets of signatures , because they represent a collection of function types in a module . Hence , a component is formally modelled as : Component == bag Signature : Additionally , it can be seen that the ordering has had a role to play in this retrieval , since the pairs of types in the ordering correspond to the different types used in the query and component . It should also be noted that the curry type transformation has been applied to the signatures labelled add and remove in the query in order to match those signatures in the component . There are many module matching mechanisms proposed in -LSB- 25 -RSB- . The matching specified here is called generalized relaxed ? match . Generalized relaxed ? match is mentioned as the module matching mechanism most likely to be commonly used in practice . A query q is said to match a component c if for each signature in q a unique , matching signature in c can be found , where the matching is relaxed by the type ordering O , and by any sequence of type transformations T . Formally , let T denote any sequence of type transformations . The function match for signature-based module matching can then be defined as : match : Env ? Query ! Library 8 -LRB- L ; O -RRB- : Env ; q : Query ; c : Component ffl c 2 match -LRB- -LRB- L ; O -RRB- ; q -RRB- , 8 sigq : dom q ffl 91 sigc : dom c ffl -LRB- sigq ; sigc -RRB- 2 O _ -LRB- T -LRB- sigq -RRB- ; sigc -RRB- 2 O _ -LRB- sigq ; T -LRB- sigc -RRB- -RRB- 2 O _ -LRB- T -LRB- sigq -RRB- ; T -LRB- sigc -RRB- -RRB- 2 O These internal , static retrieval methods return component descriptions which when compared to queries also provide useful information in terms of how to adapt the component retrieved to suit the context of the query . For example , each type transformation indicates one possible way in which the code of a component would have to change to meet the requirements of a query . Hence the sequence of type transformations applied to match query and component signatures can be used to guide the sequence of adaptations to the actual component code . Signature-matching retrieval schemes are one of a number of retrieval methods based upon internal , static properties of software components . Other such retrieval methods include specification matching using higher order unification -LSB- 23 -RSB- and specification matching using order-sorted logics -LSB- 13 -RSB- which build upon signature matching but also match using pre - and post - condition assertions of components . 5 Behavioural Retrieval In this section a formal model for behavioural retrieval is presented . The model is based upon the schemes proposed in -LSB- 18 , 1 -RSB- . Behaviour-based retrieval schemes for software reuse are based on the notion of exploiting the executability of software components to classify the components . The process of sending a program to a component yields dynamic responses which are collected . The collected responses are what is called the behaviour of the component . An ordering on behaviours is then used to classify components and to search through a library of components . The formal model of behavioural retrieval in this section is based upon the objectbased methodology presented in -LSB- 1 -RSB- . Let Class denote the set of all object-oriented classes . A class can be envisaged as a collection of objects , where each object has a common set of operations and responds in a similar way to a given program . Let Name denote the set of all possible operations -LRB- methods -RRB- , and let Val denote the set of all possible input and output values associated with operations . An object can be sent a message , which is a request to perform a named operation with some particular input , hence define Msg == Name ? Val In general , an object can be sent not just one message , but a program consisting of a finite sequence of messages , hence define Prog == seq Msg When sent a program , an object will respond by executing each message in the sequence and producing a corresponding output sequence . Of course , an object may reject messages for various reasons , such as violated preconditions or operation name mismatches . In that case the output sequence will be shorter than the sequence of messages in the program . The overall response to the program is therefore some sequence of outputs in Val , hence define Response == seq Val In general , an object may respond to a given program in many different ways . The behaviour of an object -LRB- exhibited in the context of a program p -RRB- is defined to be a collection of all possible responses to p , hence define Behaviour == PResponse In order to compute the behaviour of an object , a notion of executability is required . An execution function is a function which when provided with a program and a class yields the behaviour of objects of the class . Formally , an execution function is defined as ExecuteFunc == Prog ! Class ! Behaviour An ordering is imposed on behaviours in order to assist the matching process . The ordering is defined in such a way that behaviours having only small differences in the number of responses exhibited -LRB- determinism -RRB- and the position and number of rejected messages -LRB- failures -RRB- are more closely related than others . The precise definition of the ordering is given in -LSB- 1 -RSB- . It is formally modelled here as a relationship between behaviours : BehaviourOrdering == Behaviour $ Behaviour In order to complete the model of a behavioural retrieval method , concrete representations for a query , component , ordering and a matching formaula must be defined . A query takes the form of a program together with a desired behaviour that the ideal component would yield having executed the program . Formally , a query is represented as : Query == Prog ? Behaviour For example , a query issued by a library searcher looking for a class containing a change-dispensing operation may be : Prog == h -LRB- Change ; $ 100 -RRB- ; -LRB- Change ; $ 100 -RRB- i Behaviour == fh -LSB- -LSB- $ 20 ; $ 20 ; $ 20 ; $ 20 ; $ 20 -RSB- -RSB- ; -LSB- -LSB- $ 20 ; $ 20 ; $ 20 ; $ 20 ; $ 20 -RSB- -RSB- i ; h -LSB- -LSB- $ 50 ; $ 50 -RSB- -RSB- ; -LSB- -LSB- $ 20 ; $ 20 ; $ 20 ; $ 20 ; $ 20 -RSB- -RSB- ig The query is formed in such a way that the searcher is asking for a change dispensing machine class with an operation called Change that when fed two one-hundred dollar notes either dispenses two groups of five twenty dollar bills , or a group of two fifty dollar bills followed by a group of five twenty dollar bills . Components -LRB- i.e. classes -RRB- are represented by declaring classes in an object-oriented language . A component is therefore modelled as a class : Component == Class An example of a component specified in the formal specification language ObjectZ -LSB- 5 -RSB- which may be returned as the result of the above query is : ChangeDispenser Note == f $ 10 ; $ 20 ; $ 50 ; $ 100g -LSB- Other dispenser operations omitted -RSB- Change note ? : Note notes ! : bag Note note ? = $ 100 -RRB- notes ! = -LSB- -LSB- $ 50 ; $ 50 -RSB- -RSB- note ? = $ 50 -RRB- notes ! = -LSB- -LSB- $ 20 ; $ 20 ; $ 10 -RSB- -RSB- note ? = $ 20 -RRB- notes ! = -LSB- -LSB- $ 10 ; $ 10 -RSB- -RSB- note ? = $ 10 -RRB- notes ! = -LSB- -LSB- $ 10 -RSB- -RSB- The class ChangeDispenser has an operation named Change which changes different note denominations . When the program in the query above is executed on this class , the behaviour yielded is : fh -LSB- -LSB- $ 50 ; $ 50 -RSB- -RSB- ; -LSB- -LSB- $ 50 ; $ 50 -RSB- -RSB- ig The behaviour of the component ChangeDispenser is not the same as the desired behaviour given in the query , because the choice of dispensing $ 20 notes when given a $ 100 note is not present . A behavioural ordering -LRB- i.e. a BehaviourOrdering -RRB- has been used to match these query and component behaviours . However , in order to provide an ordering for components as required by the abstract model in Section 2 , it is necessary to have both an execution function -LRB- to obtain component behaviour -RRB- and a behavioural ordering -LRB- to order the behaviours , thereby ordering components -RRB- . Hence the required ordering is modelled as : Ordering == ExecuteFunc ? BehaviourOrdering The matching scheme specified here is presented in detail in -LSB- 1 -RSB- . Depending on the choice of representation for Class and Val , a number of different matching schemes can be defined , but in general behaviour-based matching searches the behaviourspace of components searching for a behaviour that is close to the behaviour desired . A query q is said to match a component c if the behaviour of c in response to the program p in q is among those behaviours of other components that are closest to the desired behaviour b given in q . This definition of matching involves two conceptual processes ; firstly , the behaviours of components must be derived using an execution function , and secondly those behaviours closest to the desired behaviour must be selected . This is captured formally by the function match , where E is the execution function , v is the behavioural ordering , and program p with desired behaviour b form the query . match : Env ? Query ! Library 8 -LRB- L ; -LRB- E ; v -RRB- -RRB- : Env ; -LRB- p ; b -RRB- : Query ; c : Component ffl c 2 match -LRB- -LRB- L ; -LRB- E ; v -RRB- -RRB- ; -LRB- p ; b -RRB- -RRB- , E -LRB- p -RRB- -LRB- c -RRB- 2 select -LRB- map -LRB- E -LRB- p -RRB- -RRB- -LRB- L -RRB- ; b ; v -RRB- The function select chooses a set of behaviours from a given set of behaviours . The set of behaviours chosen are those which are closest to a given behaviour using a behavioural ordering . The select function can be formally modelled as : select : PBehaviour ? Behaviour ? BehavOrder ! PBehaviour In -LSB- 1 -RSB- the ordering formed a lattice , and lattice operations were used to achieve selection . In -LSB- 17 -RSB- theorem prover results establish a metric which was used for selection , while the selection scheme of -LSB- 18 -RSB- was based on variance between actual and expected outputs . Component behaviour is an internal , dynamic property of a component , since behaviour is derived from the internal structure of a component , and behaviour is exhibited within the context of a program execution . Variances between the behaviour of a retrieved component and the behaviour desired in a query can also be used as a guide to the adaptation of retrieved components . Removing unwanted responses and extending rejected responses are processes which frequently occur during code development , so having precise differences between actual and desired responses is a solid foundation upon which adaptation can take place . A different style of behaviour-based retrieval has been proposed in -LSB- 10 -RSB- . The major difference in this approach is that functional compositions of component behaviour are also searched , allowing small programs consisting of composed components to be selected . This is especially useful in the case where no component directly satisfying a query can be found , but a small collection of components can together produce the desired behaviour . This extension can be incorporated into the model presented above without compromising the abstract model of retrieval in Section 2 . 6 Comparing Retrieval Methods This section provides a comparison of the retrieval methods which have been modelled in the previous three sections . The formal models are used to identify similarities , differences and to formulate four important principles . Frakes and Pole -LSB- 9 -RSB- make the point that not many comparative studies of different retrieval methods have been undertaken . The formal model of Section 2 provides a framework based on the similarities of retrieval methods in which it is easy to see precisely how they differ . 6.1 Similarities There are three major similarities between the three retrieval methods modelled . Firstly , because retrieval methods are each defined by providing representations for Query , Component , Ordering and match , they have similar surface structure . An advantage of taking this uniform view of retrieval methods is to permit multiple retrieval methods to co-exist and plug together , thus providing a framework for a multiple-domain retrieval tool . Queries can be pipelined because the result of a query is a library , which can be used with a different retrieval method to further narrow the search space . This leads to the first principle : Principle of Uniformity : There should exist a formal underlying architecture which provides a uniform interface upon which retrieval methods can be defined . It is suggested that the h Query , Component , Ordering , match i formalism introduced in this paper provides such a uniform interface . Secondly , the retrieval methods all depend upon the behaviour of the components in a library , even though the behaviour is represented differently in each . For facetedclassification retrieval , the behaviour of the components is concentrated implicitly into the terms used in each facet . For signature-matching retrieval , the behaviour of the components is more dilute , residing in the type-signature of each function of a module . A very explicit input-output model of component behaviour is used in behavioural retrieval . Recognising that all retrieval methods are attempting to harness the behaviour of components points to a need for \ behaviour-conversions '' . A behaviour-conversion takes the behaviour as specified by terms in a facet , a type-signature or an inputoutput pair and converts the behaviour into a corresponding behaviour in one of the other representations . This assists the retrieval process by taking advantage of multiple and hybrid -LSB- 6 -RSB- retrieval methods with one query . This leads to the statement of the second principle : Principle of Behaviour Representation : Each retrieval method is obliged to utilize some representation of component behaviour , because it is the behaviour of components that is of most concern when building applications . The third similarity between the three retrieval methods modelled is that they all allow results of retrieval to be used as inputs to a component adaptation engine . Variances between the queries and the retrieved components can be analyzed -LRB- either in a pre-computed or dynamic fashion -RRB- to assist the library searcher to adapt the retrieved component -LRB- s -RRB- into the context implied by the query -LRB- e.g. -LSB- 12 -RSB- -RRB- . However , because behaviour is represented in varying degrees of concentration , the adaptation engine will vary in the precision of the advice given . The higher the concentration of behaviour representation , the less specific the adaptation assistance . This leads to the third principle : Principle of Adaptation through Retrieval : Retrieval methods should not be decoupled from component adaptation methods , because information found during retrieval can be used as input to an adaptation engine . 6.2 Differences There are two major differences between the three retrieval methods modelled . Firstly , each retrieval method makes a different assumption about the nature of the software components and indices used to represent them . The third column of Figure 1 shows the different component indices for each retrieval method . Retrieval Method Query Component Faceted Name 7 ! Term Name 7 ! Term Signature bag Signature bag Signature Behavioural Program ? Behaviour Class Figure 1 : Different Query and Component Representations For faceted retrieval , names and terms are chosen from a vocabulary that is constructed from the domain , not from the component itself . There is no underlying assumption about the structure of actual components , so faceted schemes are generally applicable . Signatures are constructed from types used in the components themselves . The assumption in the model of Section 4 was that actual components were modules of functions . A Class represents the dynamic behaviour of a component responding to program executions . The assumption in the model of Section 5 was that an actual component was an object-oriented class . These differences correspond to the spectrum introduced in Section 1 , and highlight the need for consistency of representation between retrieval methods and library contents . Secondly , Figure 1 shows faceted and signature matching retrieval methods have the same query and component representations . This reflects the fact that both terms and signatures are static properties associated with components , and so , for ease of matching , queries and components can be statically represented in the same manner . Behavioural retrieval sees the representation of the query differ from the representation of the component , because behaviour -LRB- i.e. the basis for the ordering of behavioural retrieval -RRB- depends on the program contained in the query . As a result , the process of matching and selection becomes more computationally expensive , because the index -LRB- i.e. the behaviour -RRB- of each component is dynamically calculated using the program part of the query . In contrast , static indexes such as faceted terms and signatures can be pre-computed . However , the cost of dynamic computation of behaviour indices can be reduced by using classification and structural matching regimes as necessary pre-conditions for the calculation of behaviour -LRB- e.g. program-to-class conformance tests -RRB- . These differences indicate that retrieval methods vary in performance , and that depending upon the formulation of a query and the goal of the libary searcher , some retrieval methods are potentially more profitable than others . This leads to the fourth principle : Principle of Situational Retrieval : No single retrieval method can be expected to be best in all situations . For any given library search , some retrieval methods are potentially more profitable than others . In other words , each retrieval method is more suited to different situations . Classification -LRB- i.e. external index -RRB- retrieval methods are more appropriate for well-defined domains with standardized vocabularies or ontologies . Adaptation and system construction engines based on classification retrieval results are expected to require manual input , since the concentration of behaviour in keywords and terms is high . Structural -LRB- i.e. internal static index -RRB- retrieval methods are more appropriate for multiple domains , as long as the component representation method has the descriptive power to describe components in many domains . Adaptation and system construction can take place semi-automatically , with some adaptations being determined by the internal structural variance of queries and components . Behavioural -LRB- i.e. internal dynamic index -RRB- retrieval methods are more appropriate for domains where component interfaces are similar , in order to maximize components with meaningful responses . Near-automatic adaptation and system construction can take place , because complete response differences can be derived from queries and components . 7 Conclusion By introducing a unifying framework for software library retrieval methods we have been able to specify formal models for three of the major retrieval methods proposed . The unifying framework seeks a uniform view of retrieval methods in order to provide a basis for ffl comparison of retrieval methods ; and ffl a software library system incorporating multiple or hybrid retrieval methods . It should be emphasized that this paper concentrates on the specification of the unifying framework and comparison of retrieval methods , rather than construction and analysis of a library system incorporating multiple retrieval methods . Comparison of retrieval methods has highlighted relative merits of each , and has led to the formulation of the four principles of retrieval presented in Section 6 . The eventual goal of this research is to formally specify a class-based reusable-software repository by integrating frameworks for retrieval methods with frameworks for other repository operations . Acknowledgements The author is a holder of an Australian Postgraduate Award . The author would like to thank Roger Duke for his helpful suggestions on earlier versions of this paper . References -LSB- 1 -RSB- S. Atkinson and R. Duke . Behavioural retrieval from class libraries . Australian Computer Science Communications , 17 -LRB- 1 -RRB- :13 -LCB- 20 , January 1995 . An extended version appears as Software Verification Research Centre Technical Report 94 - 28 , 1994 . -LSB- 2 -RSB- T.J. Biggerstaff and A.J. Perlis . Software Reusability : Concepts and Models , vol I. Frontier Series . ACM -LRB- Addison Wesley -RRB- , New York , 1989 . -LSB- 3 -RSB- J. B?orstler . Feature-Oriented Classification for Software Reuse . In Proc . Seventh International Conference of Software Engineering and Knowledge Engineering -LRB- SEKE ' 95 -RRB- , 1995 . -LSB- 4 -RSB- M. del Rosario Girardi and B. Ibrahim . A similarity measure for retrieving software artifacts . In Proceedings of the Sixth International Conference on Software Engineering and Knowledge Engineering -LRB- SEKE ' 94 -RRB- , pages 478 -LCB- 485 . Jurmala , Latvia , June 1994 . -LSB- 5 -RSB- R. Duke , G. Rose , and G. Smith . Object-Z : a Specification Language Advocated for the Description of Standards . Technical Report 94-45 , Software Verification Research Centre , Dept. of Computer Science , Univ. of Queensland , Australia , 1994 . To appear in a special issue of Computer Standards and Interfaces on Formal Methods and Standards , September 1995 . -LSB- 6 -RSB- D.A. Eichmann . A Hybrid Approach to Software Repository Retrieval : Blending Faceted Classification and Type Signatures . In Proc . International Conference on Software Engineering and Knowledge Engineering -LRB- SEKE ' 91 -RRB- , pages 236 -LCB- 240 , June 1991 . -LSB- 7 -RSB- D.A. Eichmann . Supporting Multiple Domains in a Single Reuse Repository . In Proc . Fourth International Conference of Software Engineering and Knowledge Engineering -LRB- SEKE ' 92 -RRB- , pages 164 -LCB- 169 , June 1992 . -LSB- 8 -RSB- W.B. Frakes and P.B. Gandel . Representing reusable software . Information and Software Technology , 32 -LRB- 10 -RRB- , 1990 . -LSB- 9 -RSB- W.B. Frakes and T.P. Pole . An Empirical Study of Representation Methods for Reusable Software Components . IEEE Trans . Software Eng. , 20 -LRB- 8 -RRB- :617 -LCB- 630 , August 1994 . -LSB- 10 -RSB- R. J. Hall . Generalized behavior-based retrieval . In Proceedings of the 15th International Conference on Software Engineering , pages 371 -LCB- 380 , May 1993 . -LSB- 11 -RSB- R. Helm and Y.S. Maarek . Integrating information retrieval and domain specific approaches for browsing and retrieval in object-oriented class libraries . In Proc . 7th ACM Conf . on Object-Oriented Programming : Systems , Languages and Applications -LRB- OOPSLA ' 91 -RRB- , pages 47 -LCB- 61 , 1991 . -LSB- 12 -RSB- J. Jeng and B. H. C. Cheng . Using analogy to determine program modifications based on specification changes . In Proc . of IEEE 5th Int ' l Conf . on Tools with Artificial Intelligence , pages 113 -LCB- 116 , Boston , MA , November 1993 . -LSB- 13 -RSB- J. Jeng and B. H. C. Cheng . A formal approach to reusing more general components . In IEEE 9th Knowledge-Based Software Engineering Conference , Monterey , California , September 1994 . -LSB- 14 -RSB- Y.S. Maarek , D.M. Berry , and G.E. Kaiser . An information retrieval approach for automatically constructing software libraries . IEEE Trans . Software Eng. , 17 -LRB- 8 -RRB- :800 -LCB- 813 , August 1991 . -LSB- 15 -RSB- M. D. McIlroy . Mass produced software components . Proceedings of the 1969 NATO Conference on Software Engineeering , 1969 . -LSB- 16 -RSB- B. Meyer . Eiffel : The Language . Prentice Hall Object-Oriented Series . Prentice Hall -LRB- UK -RRB- Ltd , 66 Wood Lane End , Hertforshire HP24RG , 1992 . -LSB- 17 -RSB- A. Mili , R. Mili , and R. Mittermeir . Storing and retrieving software components : A refinement based system . In Proceedings of the 16th International Conference on Software Engineering , pages 91 -LCB- 100 . IEEE Computer Society Press , May 1994 . -LSB- 18 -RSB- A. Podgurski and L. Pierce . Behaviour sampling : A technique for automated retrieval of reusable components . In Proceedings of the 14th International Conference on Software Engineering , pages 349 -LCB- 360 , 1992 . -LSB- 19 -RSB- B. Potter , J. Sinclair , and D. Till . An Introduction to Formal Specification and Z. International Series in Computer Science . Prentice-Hall , 1990 . -LSB- 20 -RSB- R. Prieto-Diaz . Implementing faceted classification for software reuse . Commun . ACM , 34 -LRB- 5 -RRB- :88 -LCB- 97 , May 1991 . -LSB- 21 -RSB- R. Prieto-Diaz and G. Arango , editors . Domain Analysis and Software Systems Modeling , Los Alamitos , CA , 1991 . IEEE Computer Society . -LSB- 22 -RSB- R. Prieto-Diaz and P. Freeman . Classifying Software for Reusability . IEEE Software , 4 -LRB- 1 -RRB- :6 -LCB- 16 , 1987 . -LSB- 23 -RSB- E. J. Rollins and J. M. Wing . Specifications as search keys for software libraries : A case study using lambda prolog . Technical Report CMU-CS-90-159 , Carnegie Mellon University , School of Computer Science Carnegie Mellon University Pittsburgh , PA 15213-3890 , September 1990 . -LSB- 24 -RSB- J.M. Spivey . The Z Notation : A Reference Manual . International Series in Computer Science . Prentice-Hall , 1989 . -LSB- 25 -RSB- A. M. Zaremski and J. M. Wing . Signature matching : A key to reuse . Technical Report CMU-CS-93-151 , Carnegie Mellon University , School of Computer Science , Carnegie Mellon University , Pittsburgh , PA 15213 , May 1993 .

O O O O O O O O O O O O O O O O O O O O O O O B O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O B O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O

components
formal methods
retrieval
reuse
software libraries