Enhancing Component Reuse Using Search Techniques - CiteSeerX

82 downloads 0 Views 193KB Size Report
To reuse and integrate a component in the metaCASE environment, users must .... Keyword search forms an essential search technique used widely in library .... visual query paradigm into a CASE repository, the prototype developed was ...
Enhancing Component Reuse Using Search Techniques Zheying Zhang [email protected]

Department of Computer Science and Information Systems University of Jyväskylä, PL 35, FIN-40351 Jyväskylä, Finland

Abstract The focus of this paper is reusable components organised around a hierarchical faceted classification scheme in a metaCASE environment repository. Defining and design a faceted component search tool in a metaCASE environment is analysed based on an overview of current information retrieval techniques and a study of specific features of the components in a metaCASE environment. The suggested design effectively supports query specification and component search. It further guides users to exploit component resources for reuse.

Keywords: component, search, reuse, faceted classification

1. Introduction Component reuse has become increasingly important as the demand for cost-effective software rises. Observers predict that most application software would be built of reusable components by next decade. With the enhancement of reuse, development speed and quality will increase, and time-to-market and maintenance costs will shrink dramatically. MetaCASE forms an environment supporting method specification and the consequent software development. Because a large number of component resources are constructed in the metaCASE environment, it is natural to excite our thinking of reuse. To reuse and integrate a component in the metaCASE environment, users must be able to locate and understand them. If this process fails, reuse can not take place. However, few research has been done on the component reuse in a metaCASE repository - a specification based (meta)model repository instead of a service oriented software component repository. Current metaCASE tools or CASE tools rarely support the reuse process due to the insufficient supports of component specification and retrieval. How to represent and classify components thereby becomes essential to create facilities that support component reuse. In this paper, we focus particularly on the strategies of component classification and search in a metaCASE repository, and take an industry strength environment, MetaEdit+ (Kelly, Lyytinen et al. 1996), as an example. Different search techniques have advanced for information retrieval. When proposing strategies to search component in a metaCASE environment, we must take into account unique demands of such an environment. These demands come from the distinct characteristics of the metaCASE environment that includes complicated information on several information types levels and the integration strategies. Our Proceedings of IRIS 23. Laboratorium for Interaction Technology, University of Trollhättan Uddevalla, 2000. L. Svensson, U. Snis, C. Sørensen, H. Fägerlind, T. Lindroth, M. Magnusson, C. Östlund (eds.)

work is to study the demands of a metaCASE environment and design a search tool that helps users locate reusable components easily and flexibly, and consequently effectively support information system analysis and design. The structure of this paper is organised as follows. In the next section, features of a metaCASE environment and its components are represented. In section 3, basic information search techniques are overviewed and compared. Strategies to search for components in a metaCASE repository are proposed based on the overview of information search techniques. Accordingly, section 4 outlines techniques that can be used to design the component search tool in MetaEdit+. In section 5, we evaluate the current work and plan the strategies for future studies on the enhancement of component reuse.

2. MetaCASE environments – an enriched reuse territory Along with the growing number of available information system development methodologies, the need for flexible computer support of alternative method specifications has become increasingly important. Instead of method dependent CASE tools, a more generic environment, metaCASE environment, came into being. Besides providing support for diverse published methodologies, a metaCASE environment offers tools that allow organisations to design, construct, and adapt methodologies based on their own needs. Accordingly, a metaCASE environment has a large number of components to specify methodologies and model information systems. Among the component collections, some components or their sub-parts have some common features and are represented in the same way. If such repetitive information can be collected for future reuse, the effectiveness of methodology specifications and information system design will be improved on a large scale. The merit of reuse thus will be introduced into the metaCASE environment.

2.1.

Reusable components in a metaCASE environment

In a metaCASE environment, there are two types of reusable components: design artefacts and knowledge embedded in the design artefacts. Design artefacts are specifications represented in form-based specifications, graphs, or chunks of source code. As a metaCASE environment supports both method engineering and information system design, design artefacts are distinguished on two information type levels (Zhang and Lyytinen 2000): the IRD1 definitional level and the IRD level. IRD definitional level (metamodel level) artefacts are metamodels that specify the disciplines and rules of methodologies using predefined metamodelling languages. They are created and populated by method engineers, like the metamodel of a use case diagram in the UML methodology. IRD level (model level) artefacts are instantiated from the metamodels to model the information system application, for example, an 1

The terms of information type level are derived from the data levels of Information Resource Dictionary System (IRDS) framework (ISO 1989) where they are called the IRD schema level, the IRD definition level, the IRD level, and the application level respectively.

inventory use case diagram is a model level artefacts to analyse a Wholesale system. In addition, the knowledge embedded in a design artefact forms another type of reusable component. Unlike a design artefact – a visible entity that can be adapted and reused straightforward, the knowledge is concepts or ideas hidden behind the design artefact. They commonly have no visible representation and can be reused after sufficient understanding of the meaning, semantics, and mechanisms of the design artefact. For example, communications between actors and different use cases in an inventory use case diagram forms a kind of reusable information that can be simplified and adapted to specify the communication cases of a book loan request in a library management system. Meanwhile, the design rationale (Oinas-Kukkonen 1995) that provides the requirements, assumptions, decisions, or alternative solutions of a specific design can be documented as another kind of knowledge to be referred in the reuse process. Design artefacts are components stored in the repository, while embedded knowledge is an extra explanation that depends on user’s understanding. Although two types of components have completely different representation styles, they belong to the same process of method engineering and information system design, and have equal opportunity to reuse. Like software reuse, these components can be reused in different ways: reuse components entirely and without any modification; reuse parts of the component; adapt the reusable component to a new purpose; or merely borrow an idea from a reusable component. Meanwhile, reuse occurs at different abstraction levels and between different information types. As methodologies support the lifecycle of an information system development, reuse can take place at every level of abstraction. A better payoff can be achieved by reusing the highest level representations of components. For example, if a requirement specification component can be reused, then any design that meets those requirements is subject to be reused, and so its implementation. On the metamodel level, if metamodels for a new methodology are constructed by reuse, the design rationale embedded in the instantiation process of the original metamodels can be referred to instantiating the new metamodels. In this wise, reuse improves the development efficiency on the metamodel level and the model level.

2.2.

Representation of reusable components

Component repositories form the dominant paradigm for reuse. A significant issue with that is how to organise and represent components that are available, and how to find them once represented and classified. Without a classification scheme, or with one based on coarse-grained categories, searching would be difficult and dependent on the user looking in the right repository. A metaCASE environment generally has several meta data types for methodology specification and the consequent information system modelling, like GOPRR (Graph, Object, Property, Relationship, and Role) metamodelling language in MetaEdit+ (Smolander 1993). The meta data types and their syntactic and semantic rules are used to specify metamodels of a methodology, which will be instantiated for information system analysis and design. Accordingly, such a metaCASE environment has components in different “sizes”. Some atomic components form the primary meta data types, like a class, a state, or a transition relationship. Some components form the semantic collections of meta data, such as a metamodel of a use case diagram, or its instance, like an inventory use case diagram. Furthermore, there are “bigger”

components which form collections of several (meta)models to represent a complete methodology or an information system development project. The paradigm in MetaEdit+ (Zhang and Lyytinen 2000) distinguishes the component granularity on three levels: a project level, a graph level, and a component unit level, as three types of component “size” stated above. Generally, a project level component is coarser grained, and the unit level component is finer grained. The detailed information representations of components on different granularities are different. A hierarchical faceted scheme is used to represent the concepts of components (Zhang 2000). A faceted scheme is composed of several facets which form perspectives to specify the features of a component. It is represented as an n-tuple. The hierarchical structure derives from distinct component representations at different granularity levels (see Figure 1). Components on the same granularity level have the same facet description scheme, but are distinguished from the faceted scheme on other granularity level components. As one project generally includes different granularity level components which are inter-related, the same project components can share facet descriptions of its coarser grained components through a part-of relationship. Such a part-of relationship can be represented using one facet named as “SuperComp”.

Figure 1: A hierarchical facet scheme to specify components in MetaEdit+ As shown in Figure 1, in MetaEdit+, a project level component is represented using a 4-tuple facet scheme: , while a graph level component using a 6-tuple scheme: . The related coarser grained project level component(s) can be easily achieved by referring to the facet “SuperComp” of a graph level component. The facet descriptions thereby can be shared by the graph level component. To help understand the hierarchical faceted scheme in the MetaEdit+ environment, a Wholesale example modelled in MetaEdit+ is shown below.

Figure 2: Project model of wholesale example in MetaEdit+ Figure 2 represents a project model of a Wholesale example. There are 12 graphic models for the specification the wholesale system. Three methodologies are deployed: Activity Analysis (AA), Object Modelling Technique (OMT), and Structured Analysis and Design (SAD). In detail, some models are instances of AA methodology, such as the activity model of Inventory workflow; some are instantiated from OMT methodology, like the class diagram of Product availability; and models like Sales system are instantiated from the data flow diagram (DFD) in SAD methodology. Different granularity components involved in this system are shown in Figure 3.

Figure 3: Hierarchical component faceted description of project Wholesale Figure 3 forms a hierarchical overview of facet descriptions of components from the

Wholesale system. There are three layers of components: project level component Wholesale is at the top of the figure, the unit level components, like product, are at the bottom, and the rest are graph level components. We can easily follow the hierarchical structure to obtain information of a finer-grained component. For example, Product is the unit level component, and we can get its type, property, and behaviour from its descriptors. Meanwhile, by following the facet SuperComp, we know that Product is one composition of a graph level component Product Availability, which is a class diagram specified at the system analysis stage. In the same manner, we can get its project level component information. Finally we get the complete information of a component Product: a class in a Product Availability class diagram in UML methodology. This class diagram is used at the system analysis stage of a Wholesale project that belongs to the domain of business process engineering. The faceted information enables search tools to retrieve and discriminate between related components. It provides a way to navigate through a hierarchy from fine-grained components to their related coarse-grained components. It also provides an expressive scheme to describe users’ query needs and search for components in a metaCASE repository.

3. Component search Component search is the act of seeking for a component (HWG, 1996). The search outcome forms a list of components that match the predefined matching criteria. A search supports the consequent retrieval process, which is a process to access more detailed component information from repositories and result in the reuse of qualified components. Search and retrieval differ from browse. Browse means reading superficially or at random (HWG, 1996). It consists in inspecting candidate components for possible extraction, but without a predefined criterion (Fischer 1998). Accordingly, search and retrieval concern the component precision: the desired component is first specified, and components should not be retrieved unless they are absolutely relevant; while browsing concerns the recall: the repository is first navigated and inspected and then the desired component is specified based on the recall of the navigation (Fischer 1998). As a metaCASE repository contains a large number of components, a precise search will improve the efficiency of component reuse. We thereby study search techniques to support component retrieval and reuse.

3.1.

Review of information search techniques

When studying information search techniques, we are aware that Internet is the richest information source that human has ever developed. There have been different strategies developed to support information retrieval (Jenkins, Jackson et al. 1998), for example, the catalogue or directory for a manually administered database, the automatic robot search engine to index Internet data, and the meta-search engine to scan search engines in parallel and merge the search results. Although strategies to search for information differ with each other, most of them follow the basic techniques: keyword search, full-text search, and classification-based search. Keyword search forms an essential search technique used widely in library management systems. It allows users to find words and phases located anywhere in the catalogue record. Keyword search would require information providers to provide

appropriate keywords for each piece of information in the repository, which is a manual indexing process requiring skillful personnel. As such a requirement lacks incentive for providers to assign keywords to the information, it limits the power of keyword search. Full text search has existed for over 30 years (ZyLAB 1994). Different from keyword search, it automatically indexes all words in each document, and that avoids pitfalls in manual indexing work. Full text search presents a clear advantage that relevant documents are rarely overlooked due to its completed indexing of document. It is widely used in automated search engines for Internet information retrieval (Jenkins, Jackson et al. 1998), e.g. Alta Vista, Excit, HotBot, and so on. Meanwhile, it also means that irrelevant ones, that happen to contain certain relevant words out of context, can be retrieved if terms are not weighted according to significance. To decrease the number of irrelevant documents, more accurate index terms should be extracted from the documents. For example, Lycos tried index algorithm to deduce keywords that are particularly relevant to the subject of a document (Jenkins, Jackson et al. 1998). Classification based search has classification schemata using a number of predetermined perspectives for information classification and search. Yahoo is the primary classification based search engine on the web. Classification schemata provide stability of meaning through the systematic assignment of entities to groups or classes according to an established set of principles (Jakob 1994). There are several choices of classification based search by means of the different classification schemata. For example, faceted search (Prieto-Díaz 1991) uses faceted classification scheme; attribute-value based search (Frakes and Pole 1994) uses an attribute-value based classification scheme; enumerated search (Dewey 1979) uses a hierarchical enumerated classification scheme; and specification-based classification (Penix and Alexander 1997) basically uses a feature-based classification scheme. Classification based search is widely used in the software component repositories. However, one common problem with this approach lies in mishandling synonyms that cause term mismatch, because studies indicate that people conceptualise and name common objects very differently (Furnas, Landauer et al. 1987). When deploying such an approach, ways to limit the misinterpreting and ambiguity of the synonyms should be considered. In addition, with the development of hypertext techniques, one more search technique, Hypertext-based search, becomes populated. Hypertext-based search enables users move through a hypertext document by following links. It provides one of the newest forms to organise documents by using nodes and links (Conklin 1987). Nodes are associated with information blocks, and different types of links represent the different relationships between the source and destination nodes. Users are not constrained to the linear order of conventional documents any more, and navigate through documents at will, which may lead to a more flexible search process. However, such a free structure of search is subject to the potential that users get lost in the detail of information that can be accessed (Nieslen 1990). To avoid user’s missing, a constraint to limit users’ selection should be deployed in a search process. Search techniqes continue to advance, integrating new and traditional searching methods. An effective search tool should accommodate continually expanding collections, a characteristic of most information repositories. We have reviewed four search techniques. The first three, keyword search, full text search, and classification based search, are index based search in a structured repository, while the

last one, hypertext-based search, navigates the repository by following the predefined links. The hypertext technique can be combined flexibly with other search techniques as a complement to empower information retrieval process. For example, the prototype ORCA and AMHYRST designed for an integrated CASE environment (ICE) (Isakowitz and Kauffman 1996) presents a proposal to combine automated classification and hypertext in a tool that provides navigational capabilities for repository objects. The automatic indexing feature of a full text search has proven that it can be widely used in text-intensive documents like articles and books. Meanwhile, as keyword search and classification based search predefine the keywords or catalogues used as an index to describe concepts relevant to the domain of discourse, they introduce semantic information absent in full text search. Each search technique has advantages and is appropriate in specific circumstances. A suitable search technique should be proposed based on the features of information repository. A summary of search techniques is shown in Table 1. Keywor d search Information organisation Index ing

Full text search

Classificatio n based search

Linear

Linear

Linear

Manual

Autom

Manual/Auto

atic

Hyper text based search Nonlinear -

matic

Semantic information trolled vocabulary Any Any TextCollecti Favou collection classified domain intensive on specified rite specific collection documents with keywords collections Able to accommodate continually expanding collections. Flexib ility Controll ed vocabulary

Uncon

Table 1: Comparison of four search techniques

3.2.

Strategies to search components in a metaCASE environments

Querying the repository of a metaCASE environment was studied several years ago. Strategies and approaches have been proposed, and a prototype named MetaQuery was presented (Liu 1996). However, as the purpose of MetaQuery was to adapt a visual query paradigm into a CASE repository, the prototype developed was limited to users familiar with metamodelling mechanisms to search for the model level objects. Meanwhile, it is a syntax-directed query rather than a domain- or function-oriented query to which the user will pay more attention. MetaQuery is thus difficult to be populated as a general tool for a reuse-oriented component search in a metaCASE environment. In order to effectively support component reuse, the reuse-oriented search strategies should be proposed. Different types of design artefacts as well as the knowledge embedded in the design artefact form the components in a metaCASE environment. The same as Internet information resources, the number of components in the metaCASE repository continuously grows, as new projects are designed and implemented in such

an environment. Differing from the general text-based information resources distributed on Internet, component in a metaCASE environment are more feature and functionality oriented. Terms implying the component characteristics are difficult to be extracted from component representations using automatic full-text search strategy. We need more domain oriented categorised specifications on components, like the hierarchical faceted concept description presented above. It implies that a classification-based search can be taken as an essential way to search for components in a metaCASE environment. As we have seen that there are several paradigms of classification based search based on the construction of the classification scheme. In enumerated search, like the Dewey Decimal Systems (Dewey 1979), the enumerated scheme generally represents a breakdown of knowledge in one dimension, and providing a linear ordering of components. The user should select the components that best fit the query needs by traversing the whole classification hierarchy if he uses any other non-semantic enumeration. Deciding the appropriate component is thereby a difficult and timeconsuming task. In attribute-value based search, the classification scheme is created using component attributes and their values (Frakes and Pole 1994). Although it is an easy way to collect characteristics of components, the domain-irrelevant or semanticirrelevant attributes are also involved in the scheme, which brings unnecessary complication to classification scheme and search. A specification-based search (Penix and Alexander 1997) is specialised in retrieving software components using a featurebased classification scheme which is the same as a faceted classification scheme. In the faceted search, a faceted scheme is composed of a set of predetermined perspectives called facets to represent the characteristics of component. Each facet may have several terms called facet values. To specify a component, we select from each facet the term that best describes the component characteristics in the domain. Such a faceted scheme is easy to maintain and expand. Without a reclassification, we can easily add, delete, and update repository components and the facet list in the classification scheme, which is difficult for an enumerated classification scheme. Faceted classification is synthetic. It is widely used in software component repository, like GTE Data Services’ AMP (Asset Management Program) (Prieto-Díaz 1991) and ORCA (Object Reuse Classification Analyser) in ICE (Isakowitz and Kauffman 1996). It offers features that not only improve search and retrieval, but support the potential reuser’s selection process and contribute to the development of a standard vocabulary for software attributes (Prieto-Díaz 1991). As components in a metaCASE repository are specified uniformly in its properties and functionality, the component characteristics can be extracted and assembled as a faceted classification scheme, like the hierarchical faceted scheme specified in MetaEdit+. Therefore, the faceted search is proposed in our component retrieval in a metaCASE environment. Although we have proven the feasibility of faceted search in a metaCASE repository, we should notice that faceted scheme design is not nothing the matter. The faceted classification scheme should be accurate, consistent, and easy-to-understand. Facets should be easily selected by users to specify the query needs. It is a challenge for component managers, since users may have different query needs according to their search purposes, and component managers should understand components well and represent concepts relevant to the domain of discourse. To support flexible query specification, the facet list can not be limited to the predefined list. It will be more practical if users can be qualified to define their own facets besides using the existing facet list. Therefore, an expansion mechanism of a faceted scheme will help users

specify queries easily and flexibly. Moreover, a range of support techniques can be deployed from Boolean searches that can help users find a document that contains a keyword or a fuzzy matching.

4. Design strategies for component search in MetaEdit+ When using a search tool, there are two main issues that are of concern to users: the ease with which they can locate appropriate components of suitable quality and how they can retrieve them. Once the faceted query scheme is available, providing a range of query specifications for users at various levels of competency will be necessary. It means that the novice user is not deterred by a complicated query and the experienced user is not frustrated to have to use a simple mechanism. Therefore, search tools should offer flexible and easy-to-use user interfaces to both novices and experienced users.

4.1.

Faceted search

In MetaEdit+, we offer a hierarchical faceted scheme to specify the components, as shown in Figure 1. In the same manner, we can organise a query scheme and provide a flexible query specification for the search tool. When a user searches for a unit level component, e.g. a class type component Product, he can specify the query by selecting values of each facet for a unit level component, such as Type and Properties. Meanwhile, because of the hierarchical structure of faceted scheme, a finer-grained component can share the facet description of its corresponding coarser-grained component. The user can thereby also uses the facets of the Graph level or Project level component to specify his query needs. For example, the user can limit the type of graph to a class diagram, the abstraction level at which stage the component is used, like analysis stage, and the application domain in which the unit level component is involved, like business process engineering. Such a query specification is more expressive than that whose facet specification is limited to the component unit level. Moreover, an experienced user can qualify to define the priority of facets according to his query needs. For example, if the user would like to search for a class component in UML methodology, he can specify the methodology facet first and limit the query to the UML methodology. Meanwhile, he can also limit the search to the project Wholesale if he would like to search a component in a specific project. As for a novice, if he can not provide the priority information, the priority will be assigned by tools acquiescently according to the order of user’s selection of facets, which may not be the most effective search order.

4.2.

Refinement search

Normally, specifying queries is difficult. Users may not define the query adequately due to the lack of understanding of facets and facet values used in the system, and the lack of clear concepts of their own needs. In this situation, although search tools provide sophisticated faceted classification and advanced algorithms to match users’ needs to a repository, the search results may still lack precision. How then can we

improve the candidates returned to get a better coverage of the component repository? The key we propose here is to further detail the query. Users can get hints to re-specify a query by inspecting initial search results. Therefore, a refinement search can be used as a complement. The mechanism of the refinement search is the same as the preceding search, and the only difference is that search objects are limited to the preceding search results. It allows users to further refine their search from current search results without having to start over. For example, if a user performed a search for a graph level component using the facet “Type” with the facet value “Class Diagram” and facet “Methodology” with the value “UML”, we would achieve a large number of listings of class diagrams using UML methodology. He could then do a refinement search for a facet “Abstraction level” with its value “design stage” to narrow his search on the list of class diagrams in UML methodology. He can certainly keep refinement search to his satisfied results. It may be still difficult for users to specify a perfect query or several refinement queries to locate the component needed, especially to a novice. Component search is a trial and error process. We should allow users to reject the unsuitable query specification defined in a refinement search process, when the outcome of a refined query is not satisfactory. Thus, users can easily move back and forth between the refined query specifications and elaborate a suitable query specification. Such a mechanism provides a learning process for users to define query needs, which will further improve the accuracy of the query need specification.

4.3.

Complementary techniques supporting query specification

A logical and domain specific faceted classification scheme is the basis to search for components with high recall and precision. The more suitable classification scheme is designed, the more efficient the search will be. Meanwhile, to provide a flexible search condition specification, we should deploy alternative techniques for users to describe component matching criteria. Besides providing a fixed format to describe a query, the search tool should provide a mechanism that guides users to defined the facet values and construct a query at their own will. Search techniques frequently used in keyword or full-text search can be also used in the query description in a faceted search. For example, wildcards, like “*” and “?”, allow search for the facet values that contains a certain string, and Boolean logic allows a number of facet values to be combined using logical operators, such as OR, AND, and NOT. These techniques are not the essential technique suggested in the search process, but they provide a possible way to define a query in a more flexible way, which may suit to an experienced user.

5. Conclusions and future researches Although the reuse topic has been studied for around forty years, it is still an attractive topic stimulated by the increasing demand of time-to-market and quality-proven products in information system products. Meanwhile, the application domain of reuse is getting wider, and a metaCASE repository becomes an important territory of reuse due to its collections of a large number of design artefacts. As has been discussed, component reuse in a metaCASE environment is a new field, but it may offer a high payoff with support of reuse.

The focus of this paper has been on the component search techniques and their deployment in a metaCASE repository. Based on the analysis of the characteristics of components in a metaCASE environment and a comparison of the essential information search techniques, we proposed strategies for component search in MetaEdit+. We can see that the implementation of such a search tool is not difficult, as all supporting techniques are available, and some have existed in the current MetaEdit+. Combining the hierarchical faceted description of component concepts with search strategies and using existing facilities and techniques to design a feasible search tool in MetaEdit+ are main contributions of this paper. However, it is still modest and there is much learning ahead. The next step is to follow the strategies to implement the component search tool and evaluate the effectiveness of reuse. Furthermore, obtaining a list of satisfied candidate components after providing the query specifications does not mean the end of search and reuse. It is a starting point in the reuse process. Users need further study features of the selected component and adapt it to a new project. Therefore, our next research objective is to further study the feasibility of component retrieval. As each component possesses features marked by the previous project, users should study it thoroughly before starting adapting and integrating it. We should plan a suitable strategy to represent component information and to guide users to retrieve the information by using hypertext techniques. Such an information retrieval process will prove the success of the consequent reuse activities.

6. References Conklin, J. (1987). "Hypertext: An introduction and survey." IEEE Computer 20(9): 17 - 41. Dewey, M. (1979). Decimal classification and relative index. Albany, N.Y., Forest Press Inc.

Fischer, B. (1998). Specification-based browsing of software component libraries. Proc. 13th IEEE International Conference on Automated Software Engineering, Honolulu, Hawaii, IEEE Computer Society. Frakes, W. P. and T. P. Pole (1994). "An Empirical Study of Representation Methods for Reusable Software Components." IEEE Transactions on Software Engineering 20(8): 617 - 630. Furnas, G. W., T. K. Landauer, et al. (1987). "The vocabulary problem in human-system communication." Comm. ACM 30(11): 964 - 971. Hypertext Webster Gateway (1996). URL: http://work.ucsd.edu:5141/cgi-bin/http_webster. 1998.

Isakowitz, T. and R. J. Kauffman (1996). "Supporting Search for Reusable Software Objects." IEEE Transactions on Software engineering 22(6): 407 - 423. ISO (1989). Information processing systems: Information Resource Dictionary System (IRDS) Framework. International Standard ISO/IEC DIS 10027. Jakob, E. K. (1994). "Classification and crossdisciplinary communication: Breaching the boundaries imposed by classificatory structure." Advances in Knowledge Organization(4): 101 - 108. Jenkins, C., M. Jackson, et al. (1998). "Searching the world wide web: an evaluation of available tools and methodologies." Information and Software Technology 39: 985 - 994. Kelly, S., K. Lyytinen, et al. (1996). MetaEdit+: a Fully Configurable Multi-User and Multi-Tool CASE and CAME Environment. Advanced Information Systems Engineering, Proceedings of the 8th International Conference CAISE'96, Springer-

Verlag. Liu, H. (1996). On a visual approach of querying the CASE repository. Jyväskylä, Department of CS and IS: 122. Nieslen, N. (1990). "Navigating through hypertext." Comm. ACM 33(3): 297 - 310. Oinas-Kukkonen, H. (1995). Debate Browser - a Design Rationale Tool for MetaEdit+ Environment. Working Paper Series B 40, Dept. of Information Processing Science, Univ. of Oulu. Penix, J. and P. Alexander (1997). "Efficient specification-based component retrieval." Automated Software engineering. Prieto-Díaz, R. (1991). "Implementing Faceted Classification for Software Reuse." Comm. ACM 34(5): 89 - 97. Smolander, K. (1993). GOPRR: a proposal for a meta level model, University of Jyväskylä, Finland. Zhang, Z. (2000). Defining component in a MetaCASE environment. CAiSE*00. Zhang, Z. and K. Lyytinen (2000). A framework for component reuse in a metaCASE based software development. FOSSIL'2000. ZyLAB (1994). Full-text retrieval, imaging and the distribution of information, ZyLAB. 1999.