Jan 6, 1995 - appropriate for the expected usage and returns from the second tier. ..... Person. Bin. Index. Figure 3: An Overview of the Reuse 'Web' Structure.
A Flexible Approach to Constructing Virtual Reuse Libraries Tim Kelly, Wing Lam, Ben Whittle Rolls-Royce Systems and Software Engineering University Technology Centre Department of Computer Science University of York York YO1 5DD United Kingdom Contact: {tpk | wing | ben}@minster.york.ac.uk WWW: http://dcpu1.cs.york.ac.uk:6666/utc/utc.html The development and population of a reuse library is likely to be the largest investment that an organisation will make in adopting reuse. The content of the library is potentially vast, particularly in situations where knowledge reuse must be supported across the lifecycle. In this paper we present our experience with a two tier reuse library. The first tier forms a conventional library of reusable components. The second tier, the concern of this paper, contains the larger amount of potentially reusable, but at present project specific, components. Reuse libraries are often constructed by copying and restructuring the contents of project filestores. Instead, we create a virtual library, using World-WideWeb techniques, that provides intuitive structuring and browsing facilities over the existing filestore. This approach has many advantages, including: • •
• •
Scaleability - by providing a distributed 'lightweight' solution that is appropriate for the expected usage and returns from the second tier. Representation - of the implicit inherent structure(s) of the underlying domain. e.g. using the functional and physical break-down of the design as an intuitive aid to browsing and searching the library. Flexibility - in adding components and information that enables the library to easily expand with increasing project information. Prototyping - enabling library facilities to be developed and evaluated at low-cost.
The approach we describe is suitable for organisations who: • •
need to support reuse, but are unsure of the library support facilities they require. have a large number of potentially reusable resources, but where the cost of a dedicated library is prohibitive.
•
1.
have a distributed operation and could therefore benefit from the networking features of the WWW technology.
Introduction and Background
Reuse commonly and naturally occurs in many engineering disciplines. However, this reuse tends to be of an ad-hoc, or opportunistic, nature. Discovering ‘opportunities’ for reuse depends largely upon awareness of similarities either across one project (requiring a total project view) or with existing projects (requiring an engineering expertise and/or organisational view) and the accessibility of those current or past project results. Over recent years the drive has been towards ‘systematic’ reuse, making the process and ethic of reuse explicit and therefore more easily managed and improved. Systematic reuse has been defined by Whittle as [Whittle95a]: The planned use of systems artifacts and process in the development of solutions to similar problems. The two central claims of such reuse are often described in the following terms [Dusink95]: • •
If, in a new development, existing solutions can be employed the cost and timeliness of the development will be improved. The quality of a solution is improved the more it is used and refined and therefore less corrective maintenance will be required.
These are desirable goals for almost any organisation. To achieve them, an organisation must adopt a reuse strategy, such as that outlined in [Hill94], [Whittle96]. The strategy should identify the potential for reuse; define the objectives in adopting reuse; identify roles, responsibilities and required tool support; and monitor, manage and improve the organisation’s reuse activity. For the reuse process itself, Basili, in [Basili90], provides a simple model showing the four key steps that must be considered: 1. 2. 3. 4.
Identifying the candidate reusable pieces of the old artifact, Understanding them Modifying them to your needs, and Integrating them into the process.
Implicitly underlying Basili’s model, lies the notion of a repository, a means of storing and retrieving ‘reusable’ components (as shown in figure 1). Old artifacts are stored in a repository, they are then retrieved and transformed in order to form some new object.
Context
Old Object
Context
Transformation
New Object
Repository
Figure 1: Simple Reuse Model (modified from [Basili90]) The reuse model sounds, in principle, straightforward and uncomplicated. However when considering the needs and processes surrounding the notion of a reuse repository, for example required in a high integrity development environment, there are a number of key additional considerations to be made: •
Generalisation and Refinement of Components We consider generalisation and refinement to be the effort required to make a component ‘reusable’. Project artifacts are rarely sufficiently general to be immediately reusable. Unless the component has been particularly developed for reuse it must typically be further abstracted and generalised, separating those elements of the component that change from those that do not change. For example, for a software module this may involve extra parameterisation of the module’s operation. There is also an onus of responsibility on the developer when declaring a component reusable to ensure that it is sufficiently dependable and efficient. Any mistakes made in the development of one reusable component will have effect many times over when that component is used. One must ensure that components are made as robust and efficient as reasonably practicable for the application domain. There is therefore an overhead when developing ‘reusable’ components for a reuse repository.
•
Classification and Storage of Components The acceptability of candidate reusable components must be scrutinised when populating a reuse library. One must address whether a component is of sufficient quality, in the ‘corporate style’, and compatible with existing components. Typically these checks are made by some person or group acting in the role of ‘reuse librarian’. This person must also, for successful candidate components, decide how to store the component, i.e. how to classify or describe it. For example, using the faceted classification scheme described by Prieto-Diaz [Prieto-Diaz90] the librarian must select appropriately descriptive attributes for each of the facets defined for the
development domain. Both these activities may sound trivial, however it is an overhead that must be considered for each component entered into the library. •
Management of Stored Components There are necessary day-to-day management activities associated with maintaining a library of reusable components including: controlling updates to components, handling versions and variants of the same component and retiring redundant or ‘out-of-date’ components. With the typical (and pessimistically safe) single point of storage reuse repository these management and auditing procedures are typically carried out, as above, by a reuse librarian. Maintaining a reuse library in a consistent, correct and up-to-date state is another example of an overhead associated with reuse repositories.
•
Retrieval, Adaptation and Application of Components When dealing with high integrity systems it is crucial to track where reusable components are applied such that if an error was found in, or an update made to, a library component, affected applications of that component could be readily identified. When retrieving a component an explicit request or withdrawal from the library must be made. This way, it would be possible to maintain a record of where each library component was being used. There is therefore an overhead even in retrieving a library component. Tracking the usage of library components could also have other uses:For example, if it was found that a reusable component extracted from the reuse library was commonly being adapted into other form, it is possible that that adaptation should itself be stored as a reusable component, thus avoiding the adaptation being made over and over again.
The overheads associated with maintaining a library of reusable components, in addition to the initial set up costs, do not invalidate the usefulness of the concept. However, it can lead us to recognise that not all potentially reusable information can afford to be stored in a conventional reuse library. The per-item overheads associated with refining, storing, maintaining and tracking a high integrity reusable component limit, certainly initially, the number of components one can support. However, one of the characteristics of existing ad hoc components is that it often draws upon a large and diverse universe of past information. We are therefore faced with a problem, how can we effectively support existing ad hoc reuse when the number of components we can afford to maintain is limited by punitive library overheads? Frakes and Fox, in a recent survey into reuse documented in [Frakes95], have also concluded that reuse repositories do not, in themselves, improve levels of code reuse. If this is really the case, then we need to adopt a more flexible and
cost-effective approach to storing reuseable lifecycle artifacts that supports and complements existing intuitive patterns of reuse. In the section two we describe the approach we have adopted in creating a reuse library. In section three we outline how this approach has been implemented using the technology and techniques from the World-Web-Web Initiative. Section four provides a example of the approach in operation. Finally, in section five, some conclusions about the approach are drawn.
2.
A Flexible Approach to Supporting Reuse
By analysing the existing work patterns within Rolls-Royce we have identified two forms of reuse: • •
Reuse of ‘reuse-ready’ components - reuse of components developed on past projects that have been modified or developed for obvious and direct application in other projects. Reuse of ‘general project knowledge’ reuse of project specific components and information created for previous projects that cannot costeffectively be generalised sufficiently to warrant the label ‘reusable’.
Both forms of reuse are equally valid, but for different types of components and applications. A piece of information does not have to be immediately ‘reusable’ for it to help in the development of a new project. It is common engineering practice to make analogies between projects in order that previous solutions can be ‘mapped’ across to aid in solving a new problems. Maiden and Sutcliffe in [Maiden92] have observed this behaviour when reusing software specifications. Klein and Calderwood [Klein88] also describe how analogues are commonly employed when making project decisions. However, reuse of this latter kind is, at present, limited by an engineer’s or manager’s comprehension, visibility or ability access previous (perhaps archived) project material. Engineers and managers with experience know the problems that were tackled by past projects, what difficulties were faced, how solutions were constructed, etc. This knowledge is used to focus and constrain their search when plundering the project archives. However, without this knowledge an unconstrained search of past project information typically requires such effort as to make it unprofitable (i.e. the payback from the past project information is less than the effort required to find it). To support both of the above forms of reuse we have adopted a two tiered reuse library approach consisting of the following elements: •
Repository - a project independent store of components that are, or have been designed to be, reusable. The components stored will typically be key to organisation’s project activity. As such, working in a high-integrity environment, the repository will implement all of the measures described in section one.
•
Knowledge Store - a project independent archive of a large and wide range of components and information, generated by previous projects. These components are unmodified from the projects in which they were applied. No additional effort has gone into making them ‘reusable’.
As examples of typical candidates for each of the two tiers, consider the following two components: a sort routine and a bus interface module. The sort routine has been refined, optimised and tested over many years, it would be natural to describe it as a reusable component and therefore store it in the repository. The bus interface module, on the other hand, differs in each project and implementation ( i.e. differences in what data is sent and received, how that data is packaged and presented, etc.) and it would take considerable effort to develop a component for the general case. However, it is still useful to have access to such a component, even if it is not immediately ‘reusable’, when developing (or evolving) the next and latest version. The bus component, and related information, could therefore be stored in the knowledge store so, although not rigorously controlled, it remains accesible and visible to engineers on future projects. When populating a reuse library, especially initially, there is the difficult issue of determining the subset of the organisation’s components that should be stored as ‘reusable’ components. Through an analysis of the development and application domains, we might hope to make some predictions about the reusability of certain components. Those components with the greatest reuse potential and payback can then be refined further for storage within the reuse library. However, as described earlier, we can rarely afford to support all the components identified at this stage. It may also be that our reusability predictions were wrong, e.g. a potentially highly reusable component was underestimated or vice versa. In either case, the benefit of the two tier approach is that, through the knowledge store, we provide an intermediate ‘catch- all’ where accepting a greater degree of informality in configuration management, revision tracking, etc. allows us to store a larger and wider range of components with less overheads.
2.1 The Relationship Between Project and Library Figure 2 depicts the flow of project and reusable artifacts between two entities: the project and the reuse library. The library is composed of the reuse repository and the reuse knowledge store. There is a bi-directional flow of information between project and the constituent parts of the library, and within the library between the repository and store.
The information flow can be described as: Repository Project Store Project Repository Store
use of repository components in a project → Project → Repository new reusable components from the project entered in the repository use of knowledge from the store in the project → Project project information transferred to store during or at → Store the end of the project components that are not (frequently) reused are → Store retired to the store → Repository frequently used store components are used to generate new reusable components
Project Project Specific Components Project Experience
New Reusable Components Reusable Components
Store
New Reusable Components
Repository
Retired non-reused Components
Reuse Library Figure 2: Relationship Between the Project and Reuse Library (Repository and Store) The description and figure above describes the flows of information between the project and library (repository and store) but not how the flows take place or how the flow is funded. These are management issues outside the scope of this paper. For the Knowledge Store to operate in the manner described above, it is crucial that it is easily and efficiently managed and has low overhead running costs. Contrasting with the considerations made for a ‘fully fledged’ reuse library given in section one, the Knowledge Store must take into account the following considerations:
•
•
•
•
Management and Control (Flexibility) - centralised control is desirable for a fully configured library (e.g. the repository) but not for the knowledge store. To have centralised control typically necessitates the involvement of a reuse librarian, thus increasing the library’s overheads. Instead it would be better to distribute control and to enforce control by defined procedures. Scaleability - the Knowledge Store has to accommodate a large amount of project information. We need to ensure that new components and new component types can be easily added. Per-component overheads (indexing, retrieval, representation) should be kept to an absolute minimum. Representation - a defining purpose of the Knowledge Store is to improve the visibility and accessibility of past project information in a intuitive manner that mimics and improves upon existing reuse patterns. Bell, in [Bell93] describes the problem of reducing “cognitive distance”. Cognitive distance is defined by Bell as being the ‘mental gap’ that exists between the context in which a reusable component was developed and application context. Comprehension of a components purpose, applicability etc., is made more difficult the larger the cognitive distance. The Knowledge Store must reduce cognitive distance by allowing information to be presented in a framework that maps easily to the underlying domain. Prototyping - the Knowledge Store must be flexible enough to allow different library configurations and layouts to be prototyped without necessary change in the underlying data stored.
To avoid large development costs, it is also highly desirable to use, as far as possible, preexisting technology and tools. In the next section we describe technology and tools associated with the World-Wide-Web were used to construct a ‘virtual’ knowledge store that addresses the above considerations.
3.
Creating the Technology
‘Virtual’
Library
using
WWW
The World-Wide-Web (WWW) is a network of different forms of linked information across the Internet. The World-Wide-Web initiative originated from CERN, the European Laboratory for Particle Physics, in Switzerland and now has many participants. The WWW uses multimedia and hypertext techniques to provide a user-friendly of browsing and contributing to the Internet. The WWW world consists of documents and links. Documents are written in text marked up using HTML (HyperText Markup Language). HTML is used to determine the structure and style of a document, for example, defining heading levels, character attributes. It also allows allows different media to be integrated into a document, such as pictures, audio and video. HTML also allows links to be embedded into documents. Internal links can be
made to allow navigation within a document. External links can also made to point either to another HTML document or another type of document. To browse the WWW requires a client browser, such as the Netscape Navigator developed by Netscape Communications or NCSA Mosaic. Such tools are capable of accepting and displaying HTML documents. They communicate to WWW servers on the Internet using HTTP (HyperText Transfer Protocol). HTTP is a lightweight efficient protocol designed specifically for the WWW. It is a generic, stateless, object-oriented protocol that, amongst other features, allows negotiation of data representation, allowing systems to be built independently of new developing representations. Browsers, such as Netscape, are capable of displaying or handling many types of information e.g. text, graphics, audio, video. If a browser cannot present a particular information type itself, it is usually capable of automatically passing that information to a client (or ‘helper’) application that can. In addition to support for the WWW, such browsers also commonly provide access to many of the existing Internet service forms, such as Gopher and FTP (File Transfer Protocol) and NFS (Network Filing System).
3.1 Strengths of the World-Wide-Web The growth of the WWW as a medium for exchanging and publishing information over the past few years has been phenomenal. Before describing how the technology was applied in creating a ‘virtual’ reuse library, it is worth first considering two of the key features that have made the WWW such a success (and therefore what features we wish to preserve when constructing the knowledge store): •
•
•
Appeal and Ease of Use - The integrated presentation of text, graphics and audio and the ‘point and click’ hypertext based information navigation make the WWW both an attractive presentation medium and an attractive retrieval mechanism. Unlike the earlier forms of Internet service (e.g. FTP) the details of Internet access are hidden from the user: users do not have to remember long addresses or lists of commands. The WWW is also still perceived as a novelty and is therefore appealing to use. Distributed Control - Local information providers are responsible for their own information. There is no central body controlling how or what is distributed on the world wide web. This has the advantage that users can and do contribute freely to information available on the WWW. It is easy for people to provide their own personal home pages or to start up new servers. However, there are also disadvantages, including lack of control over the type of material being circulated using the WWW or guarantees regarding reliability or quality of service (except by the information provider themselves), i.e. an item of information could be available one day and then gone the next. Platform Independence - Good quality WWW browsers are available for all of the major operating systems (UNIX, VMS, MS-DOS, Macintosh,
Windows NT). In addition to this, the use of accepted data formats, such as GIF (Graphics Interchange Format) for graphics and PostScript for documents, has meant that the WWW provides an excellent means for communicating across different platforms. We wished to capture and exploit the above points when constructing the reuse system using the WWW technology: The system was designed to make it both easy and inviting for engineers to use. Engineers are able to freely browse and contribute to the store of information. The knowledge store is distributed to avoid the overheads associated with centralised control (central servers, disks, reuse librarian effort, artifact handling procedures, etc.). The knowledge store can be accessed across the multiple computing platforms that exist in Rolls-Royce: Where possible stored data has been converted into an open ‘base’ type, e.g. HTML, ASCII, PostScript or GIF. Platform independence in this way provides the added flexibility of not committing the library, or the artifacts contained within, to a particular platform.
3.2 Overview of the Reuse Library Implementation The approach adopted to implement the knowledge store combines the strength of the WWW for indexing, retrieval and distribution purposes and the use of the filing system for storage, access control, etc. Figure 3 provides an overview of the implemented knowledge store structure: Reuse Web
Knowledge Store
People
Person
Projects
Generic Project
Repository
Functional
Physical
Process
Functional
Physical
Process
Functions
Modules
Functions Procedures
Functions
Modules
Functions Procedures
Index
Index
Index
Index
Index
Index
Bin
Bin
Bin
Bin
Bin
Bin
Index A
B
C
C1
C2
Bin
C1.1
C1.2
Functional
Physical
Process
Functions
Modules
Procedures
Index
Index
Index
Bin
Bin
Bin
C3
Figure 3: An Overview of the Reuse ‘Web’ Structure There are four main elements to the structure shown in figure 3: The Knowledge Store, the People area, the Generic Project and the Repository (not addressed in this paper).Linked WWW pages were used to create the indexing structure shown above the dashed line (Figure 4 shows the top most WWW page being viewed).
Figure 4: Top Level Reuse Library Web Page All of the web index pages are created and maintained by the reuse librarian and are located on a central server (running an HTTP daemon). At present a Microsoft Access database is used to maintain and generate all the HTML files for the top level indexing structure. The indexing structure shown in figure 3 categorises by major engine projects, engine series, engine mark and engine variant (e.g. “RB211”, ”Trent”, ”T700”,”T700.X”). The index is then further sub-divided, on a per-variant basis, using a functional, physical and process (project organisation) viewpoint decomposition. (Shaded entities in the diagram indicate multiple separate instances.) Table 5 shows some of the typical subcategories under each of these headings: Functional Viewpoint: Physical Viewpoint: Functions Modules Control Engine Box Architecture Thrust Reverser Calibration Heat Management Transducers Ratings Actuators Thrust Settings Mechanical Pumps Ambient Conditions Mechanical Generators Air Data Power Supply Communications Construction Details Figure 5: Function, Physical and Process Sub-Categories
Process Viewpoint: Procedures Plans Procedures Organisation Methods Tools Facilities Equipment
Underlying the indexing structure (i.e. below the dashed line in figure 3) files are stored on the filing system. Artifacts (components, information etc.) are stored in ‘bins’. Bins
are simply nominated directories of the filing system, their location determined by the accessibility and convenience for the project members concerned. Each bin (directory) contains an index file. An index file is a simple text document containing a list and brief description of items contained in a particular bin (figure 6 shows an index file for artifacts related to engine starting). Any type of artifact can be stored in a bin: requirements documents, code modules, design diagrams. Controlling access to the bins is handled on a purely local and per-project basis. However, the purpose of the reuse web is to make accessible as much of the project information as possible. INDEX for STARTING COMPONENTS bin --------------------------------Last Modified 1/6/95 by /tpk Notes ----Note that some components control or supervise e.g. initiate manual start, whilst others provide an interface to parts of the engine system, such as fuel valve control. Manual and automatic starts both generate events for the fuel valve, air valve and igniter components. COMPONENTS ---------: Initiate_Manual_Start: generates events associated with a manual start dependent on cockpit signals. Schedules air and fuel flow, and controls igniters. Automated_Start: generates events associated with an auto start dependent on cockpit signals. Schedules air and fuel flow, and controls igniters. Fuel_Valve_Control: control of the fuel valve, given an input of fuel flow required. Starter_Air _Valve_Control: controls the started air valve. Ignition_Control: control and schedule of igniter sequencing, for different start scenarios.
Figure 6: Starting Components Bin Index File In addition to project related information, a portion of the reuse library web has been allocated to providing personnel information, the ‘People’ area. This area contains an index of all staff. Staff bins are be maintained on a personal basis and are located off user home directories. Staff are allowed to create their own web pages, both serious and frivolous. As on the Internet web, they are encouraged to build lists of ‘useful’ links to the reuse web, e.g. to most commonly used components, as such pages can become a quick and efficient means for extracting information from the web. In addition, engineers are encouraged to make their “Calcs” file, a form of engineering log-book, accessible from their bin, such that this information can be shared and distributed among all the engineers.
Staff pages are referred to by the Process aspects of Project index, i.e. who worked on a project, who was responsible for what, etc. By explicitly including people in this manner, people are encouraged to use the reuse web, additional ‘indices’ are evolved over time by users creating ‘hot-lists’ of links, and engineering experience can be shared.
3.3 Using the Reuse Library The stored artifacts in the reuse library web can be accessed in a number of ways: The generic project index typically provides the entry point for general browsing. The generic project index is structured as a typical project, based upon a general domain model. It links to no artifacts directly, but instead links to where artifacts can be found. For example, if we wished to browse artifacts on thrust reversers, we might go to the generic project, functional, thrust reverser index. Links are then listed by the index, as shown in figure 7, to wherever related artifacts can be found, both in the reuse repository (i.e. to guaranteed, regulated, components) and to project specific artifacts in the knowledge store.
Figure 7: Generic Project Thrust Reverser Index. Artifacts can also be retrieved directly by using the Knowledge Store, Projects, Major Engine Projects, Engine Series, Engine Mark, Engine Variant access path. Having accessed the Thrust Reverser index in this manner, related indices from other projects are also referenced allowing the browser to’hop’ from project to project in a particular subject area. It may also be that an engineer, in personal web pages has decided to link to
the areas of projects he/she has had an involvement in. In such a case, one could browse these areas by accessing the reuse web through the people section. Figure 8 shows the possible links for retrieving information from the reuse web: by generic project; by specific and ‘similar’ project and by person.
Generic Project
People
Functional
J. Bloggs
Thrust Reverser
Index
Index
Bin
Bin C1.1
D2.2
Functional
Functional
Thrust Reverser
Thrust Reverser
Index
Index
Bin
Bin
Figure 8: Access paths for retrieving information from the reuse web.
3.4 Operating Guidelines The knowledge store operates on a certain degree of informality. However, for the smooth running of the system is is necessary to have some simple operating guidelines. These include the following: • • • •
Bin locations on the filing system should ideally be fairly static, as these are referenced from the above indexing structure. Changes of bin location should be notified to the reuse librarian. Additional hyperlinks should only be made in the upper (indexing) structure of the reuse web. If an additional link is required (other than from personal web pages), the reuse librarian should be notified. Artifacts should be placed in the appropriate bin. Index files should be kept consistent with the contents of the attached bin.
3.5 Benefits of the approach
The reuse library is virtual to the extent that although through the WWW indexing structure it appears as a single collection of information, the data may in fact be distributed across many machines and disks. The distribution of the data and control is hidden from the user. The flexibility of the approach stems from the freedom to change the way the library operates, simply by altering the top level indexing structure: The indexing structure we have presented in this paper represents our first attempt at a retrieval structure we believe to be intuitive for engineers to use. However, if we decided, after using this structure for some months that it was not intuitive, we could replace it with an alternative web of indices, without having to alter the underlying storage or content of the knowledge store artifacts. In this way, the approach supports optimisation and prototyping of new retrieval structures and representations of the project breakdown structure. It might also be possible to maintain multiple indexing structures to represent different viewpoints over the project information. The approach is also flexible in its scaleability: The reuse library web can be accessed using multiple platforms. The indexing structure is of a known and finite size and can therefore be easily accommodated on a single machine. The lightness of the HTTP protocol means that requests via indices do not pose a significant bottleneck on the retrieval process. By maintaining the artifacts themselves on the filing system, scaleability is only limited by the underlying filing system (i.e. through maximum number of directory entries, disk space available etc.).
4.
Conclusion
Using the techniques described in this paper we have developed a prototype reuse library and knowledge store for Rolls-Royce in under two months. The library is currently being populated with components and has proven popular with engineers. The indexing structure of the library has been tailored to speed up artifact retrieval with the domain specific key terms updating to reflect changes in common parlance. Above all, we have recognised the benefits of supporting informal reuse.
5.
Acknowlegdements
The authors acknowledge the financial support given by Rolls-Royce plc. for the work reported in this paper. We would also like to acknowledge the valuable contribution made by various employees of Rolls-Royce, particularly Mr M. Bardill.
6.
References
[Basili90]
V. R. Basili Viewing Maintenance as Reuse Oriented Software Development
IEEE Software 7(1) 1990 [Bell93]
P. J. Bell Reducing Cognitive Distance: The Role of an Effective Reuse Program in Proceedings of Sixth Annual Workshop on Software Reuse 1993
[Klein88]
G. Klein, R. Calderwood How do people use analogue to make decisions? in Proceedings of DARPA Workshop on Case Based Reasoning 1988 AI Magazine 12(2) 1991
[Dusink95]
L. Dusink, J. Katwijk Reuse Dimensions in Proceedings of Symposium of Software Reusability 1995
[Frakes95]
W. B. Frakes, C. J. Fox Sixteen Questions about Software Reuse Communications of the ACM 38(6) 1995
[Maiden92]
N. Maiden, A. Sutcliffe Analogously based reusability Behaviour and Information Technology 11(2) 1992
[Prieto-Diaz91] R. P-Diaz Implementing Facetted Classification for Software Reuse Communications of the ACM 34(5) 1991 [Hill94]
J. Hill, K. Harper, J. McDermid, R.Rimmer, B. Whittle, M. Yates 'Reuse of Engine Control Technology 1994 Avionics Conference and Exhibition 'Systems Integration is the Sky the Limit?' Heathrow 30th November - 1st December.
[Whittle95]
B. Whittle Software Component Reuse PhD Thesis, University of Wales Aberystwyth, Dept of Computer Science, 1995.
[Whittle96]
B. Whittle, W. Lam and T. Kelly A Pragmatic Approach to Reuse Introduction in an Industrial Setting Accepted for International Workshop on Systematic Reuse, Jan. 1996, Liverpool John-Moores University, UK.
