Reuse Dimensions Liesbeth Dusink
Jan van Katwijk
[email protected] Delft University of Technology Delft, the Netherlands
[email protected] Delft University of Technology Delft, the Netherlands
Abstract
development remains questionable. Our long-term research goals are concerned with modeling
In recent years, there have been much publications on reuse. In order to get an overview of the whole field and also a good
and building a software development environment in which reuse, in various forms, is an integrated element. Study-
impression of the state of the reuse art, we studied reuse literature of the last few years. As basis for comparison, we classified literature according to four (more or less orthogonal) dimensions, based on the actions and knowledge of the reuser, i.e. the software engineer. The dimensions are: actions to be taken to get an existing reusable item; knowledge
ing the vast amounts of reports on previous work, it became apparent that no integrated models for reuse support in software development were available. Building an integrated
to be applied to find an existing reusable item; actions taken to build the complete system needed; knowledge applied to get the complete system needed.
to be to be
The survey shows that research on reuse from the viewpoint of the needed system, receives far less attention than research from the viewpoint of reusable artifacts. We expect reuse to live up to its promise if this topic is addressed as well.
1
Introduction
toolset therefore inevitably requires defining our own reuse supporting development models. The situation is even worse, studying the literature lead us to the conclusion that a consistent picture of the field of software reuse does not exist. A general claim of reuse [1 17] is that if reuse is applied (properly), it will aid in reducing the effects of the software crisis. Typical symptoms of this crisis are: (i) software is delivered late, (ii) software quality is low, and (iii) too much, i.e. up to 75% of software engineer’s capabilities are spent on maintenance[68]. The claims for reuse are based on the following reasoning: 1! if in building new software, existing solutions can be reused, the construction of this new system will more likely be in time.
Software reuse is receiving a lot of attention this last decade. This is not surprising; it is generally believed that reuse has great potentials in making software development into
2. if a single existing solution is used more often, it is iikely that the quaiity of the solution (both w.r.t. func-
software engineering. The essence of reuse, i.e. all activities aiming at reusing previously constructed artifacts within the process of soft-
tionality as well as non-functional constraints) will improve. As a consequence, less time will have to be spent on corrective maintenance.
ware development, is not a particularly new term; the term was originally coined in 1968 by McIlroy [90] who wanted to change the craft of software engineering into the industry of software engineering. The significance of the term is shown by the vast amount of literature devoted to the subject. Books (e.g. [20, 57, 118]) and journal issues (e.g. IEEE Software July 1987, September 1994, IEEE Transactions on Software Engineering September 1984) are devoted to the topic regularly. Nevertheless, the maturity of reuse as an element in software Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association of Computing Machinery.To copy otherwise, or to republish, requires a fee and/or specific permission. SSR ’95, Seattle, WA, USA 0 1995 ACM 0-89791 -739-1 /95/0004 ...$3.50
Typical references, describing claims of reuse and obstacles to its proper use, are: [56], [81], [2]. In earlier literature, several people report on intuitive approaches and feelings. As an example, Jones [71] claims that, on average, less than 1570 of code is ‘new’ code, the other 85q0 has been written in more or less the same form as in previous applications, Meyer [91] also gives a similar remark, he claims to have a dkjh vu when looking at ‘new’ software. Initial claims on the benefits of reuse were based on common sense only. In later stages the claims were supported by calculation and empirical evidence in the form of real experiences and numerical results. Typical examples in this 137
field are Horowitz and Munson[68] who attempt to relate the amount of reuse with the kind of reuse, using some calculation scheme. Gruman reports in [64] on actual reuse. The presented expectations, i.e. 2(I to 50~0 gain, were unfortunately not supported by hard figures. Thomas, Delis and Basili[ 116] present measured benefits of reuse in an Ada development environment: error density was reduced and productivity
did increase.
In this paper we present another organizational
framework for
classifying research on software reuse. We use this particular framework to show the coverage of the various problem area of software reuse by documented research. The survey, presented in this paper, shows white spots that are believed to be obstacles for a successful application need to be addressed in future research.
●
State of the art in reuse w.r.t. a single language, is the viewpoint taken by Dusink et al [44];
●
Ververs et al[120] aim at predicting long term perspectives of reuse.
short term and
A current trend is to cover the state of the art by describing the trends and directions in reuse research. Ververs et al [ 120] and Bott et al[23], discuss patterns in reuse. Both fail, however, to address the impact of the trends in software reuse on software engineering processes. Krueger [75] addresses the impact of some trends. Although he presents a rather detailed overview on reuse, he does not present a clear framework that can be used for classification and evaluation.
of reuse and which As our goal is not addressed by existing reuse surveys, we have a good cause to give yet another reuse survey.
The organization of the survey is based on four (more or less) orthogonal dimensions, representing capabilities
of reusers.
The structure of the paper follows the structure of this survey.
From the “programming side” ‘reuse’ can be viewed from:
of software
construction,
First a rationale for our classification approach is given, next for each of the distinguished dimensions, a brief survey of the state of the art is given. Finally, we will present our
the sofiware side. In this view the software products play a central role. The ‘software side’ view relates to
conclusions research.
the claim that reuse has an impact on the final product (quality). Two opposite views can be identified:
and a brief survey of our current and future
For the purpose of this study, the term ‘reuse’ was defined
1. the viewpoint of the artifact being reused. This is typically the most taken point of view. It is concerned with both reusability of program fragments and with reusable transformations. The point is valid because of the claim that reusable
as: Definition 1.1 reuse Reuse is the systematic application of existing software artifacts during the process of building a new software system, or the physical incorporation a new software system.
artifacts will be of better quality, they are the things to be handled,
of existing software artifacts in ❑
2. from the viewpoint The term ‘artifact’
Definition 1.2 artifact an artifact: a piece of formalized knowledge tribute to the software engineering process.
that can con❑
the zusing engineer’s side. From this viewpoint, the reusing software engineer is taken as the central element.
data types.
The ‘engineer’s side’ view comes from the claim of spending less time on the building process, and from the idea that it is software engineers who have to do the reuse,
A rationale
Many survey-like papers and books have already been presented. However, only a few of them provide a precise description of the ‘state of the art’ in reuse. Many others are merely compositions of relevant papers. Typical surveys are: ●
In view of this,
the environment in which the reused artifacts are used, is central. This point is valid because the reuse of artifacts can make the target system to have a different internai form than without reuse.
This definition of artifact covers designs, transformation rules, as well as e.g. descriptions of how to detect abstract
2
of the target system, being
built with the help of reuse.
was defined as:
and because
Two viewpoints can be identified: 1. the viewpoint of the actions, i.e. the steps of the process, to be taken by the reusing engineer. Since reuse implies a change in the process, investigating the actions, e.g. finding reusable artifacts, is essential to understand the process. The point is raised because new actions, like finding reusable artifacts, are introduced into the software engineering process.
Biggerstaff et al aim at providing a description of the state of the art of reuse[ 19], although his survey is useful, it is somewhat dated. Jones[70] provides another overview with similar aims.
138
2. the viewpoint of knowledge, the reusing engineer should have at his command. Essential for
●
a higher degree of reuse is the reusing engineer’s understanding
development to obtain executable artifacts.
of the reusable artifacts, the pro4. knowledge needed to build target systems with the help of reuse To be able to perform the actions from the pre-
cess, and the actions to be taken. This point is made because knowledge about the artifacts is needed to be able to use them properly. Whh the help of these viewpoints, easier be checked.
being
vious points, a reusing engineer needs to have domain knowledge (in order to understand common architecture, being applicable to that domain, and in order to understand the availability of reuse-supporting artifacts).
the claims of reuse can
With the above mentioned viewpoints as a starting-point, is easy to identify four dimensions in the world of reuse: 1. The artifacts
development may be needed, depending on the degree in which the output needs further
further
reused.
it
A single step in the
software engineering process can be seen as a from an input to an output. The trans j ormation transformation step is often refined into sub-steps, i.e. findlselectlunderstandladapt. Two different views on what is being reused exist:
Construction of reuse-supporting artifacts and application of reuse-supporting artifacts, are complements-y to each other. Thus, reuse according to a certain paradigm is only possible if the reusable components correspond with the paradigm. It may have been noticed that the ‘dimensions’
as given
above, are from the viewpoint of “use”. This is not accidentally; we started this survey from the use-side due to our interest in validating the claim of reuse.
(a) reuse of the output. A process in which output is reused, often called components-based reuse, takes the following
steps:
3
A closer look
i. describe input; ii. find/select and apply existing artifact(s) that fulfill the requirements on the output of the transformation. Emphasis is typically on finding and selecting reusable artifacts.
the appropriate
(b) reuse of the transformation. A process in which the transformation itself is reused, often called transformation-based reuse, takes the following steps:
For each dimension
3.1
the transformation
in the previous section, we
Reusing Artifacts
As stated earlier, a basic step in the software development cycle can be modeled as a triple
i. describe input; ii. instantiate
identified
traced the literature in order to investigate the degree to which the issues, raised in that dimension, are covered, understood and addressed.
input,
transformation,
output
process, i.e.
an automated process that generates or find/selects components such that they fulfill the input description.
Typical extremes to be considered here are: ●
to be able to reuse artifacts. Apart 2. The knowledge from factual knowledge on the products, that are actually reused, the reusing software engineer also needs
components-based reuse This kind of reuse (first introduced by McIlroy in 1968), amounts to reusing selected output parts. In part can be inthis kind of reuse the transformation
metaknowledge, i.e. knowledge about when and how to use a given product with the needed characteristics, is needed.
terpreted as a sequence of (often manually performed) actions: - find a component;
3. The target systems that are being build The reusing engineer might have to adapt, to integrate, andlor further develop artifacts. ●
●
- select a component; - understand the components selected and, if required
may be needed, depending on the degree to which-the available or generated artifacts conform to the required entity;
adaptation
- adapt the components. ●
may be needed, depending on the degree to which the available artifacts form the required system;
transformation-bmedreuse.
The idea of automatic pro-
gramming has existed at least since 1958 (described by e.g. Rich & Waters [105] and Barstow [9, 10]). The transformation-basedkind of reuse amounts to reusing
integration
139
the transformation, i.e. to have available some automated transformer which is capable of generating, selecting and adapting artifacts, together forming output.
the
Obviously, the two extremes presented are extremes indeed, it is easy to envisage intermediate forms where (parts of) the output and (parts of) the transformation
are being reused.
in MERLIN
represent this broader view.
The limitations
of only providing
guidelines
are apparent,
Components are (re)used within aframework, a higher level abstract component which by itself can be reused again. Many reusers, however, are unaware that they are building such frameworks and establishing such requirements [43]. Absence of this awareness is one of the primary inhibitors to
Both Ramamoorthy [ 103] and Biggerstaff [ 15] present similar
scale-up. It is only recently that some people started to focus on such frameworks (Batory, DSSA stuff, Baxter, Basset)
partitionings; artifacts.
Component design issues REDO [26] is an Esprit project where programs will be restructured, documentation is ad-
3.1.1
their focus, however, is limited
Components-Based
reuse
Components-based reuse was originally roy in his description
to the reused
of moving
introduced by McI1-
from a craft
of software
duced and features related to the validation of code are incorporated and enhanced. Castano and De Antonellis [29] describe a method to extract generic components from existing applications. A completely different approach is followed by Alonso and de la Puente [3] in their description
engineering to an industry of software engineering. Ideas, similar to McIlroy’s, are discussed by MacAnAirchinnigh [85].
of design issues for a reusable real-time executive in Ada. An interesting observation is that, in general, the claims on improvement of software and its development are based on common sense reasoning.
Although the steps, required for Components-based reuse, usually will be performed in the context of a software development process, most reported work on finding artifacts, understanding artifacts, modifying artifacts and using artifacts fails to address the issue of integrating these actions within the software development process. Notable exceptions are Fisher and his group [52], and the results of the
Component semantics The 3CS model (Concept, Content and Context) discussed by Tracz [46] and described by Edwards [47] can be used as a guideline as to what groups of knowledge can be recognized. ThR gives help in tinding what knowledge should be parametenzed. Another guideline for how to make a reusable product is the rules of threes (ana-
WISR’91 [79] workshop. In this paragraph we address some issues in componentsbases, and in the actions findfselect, understand and adapt.
Components The topic of reusable sofmare components has received a great deal of attention. Most (reported) attention, however, has been given to elementary syntactical aspects, i.e. what language constraints are to be put on components, what constraints are there to be placed on interfaces, the degree of genericity etc. Component semantics has got much less attention, whereas there is virtually no reported attention on component documentation. Components and syntax Much work has been done on ‘guidelines’, especially in the context if the Ada programming language. The structure of the language is such that building reusable components seems to be encouraged. In order to profit from the structure, several on the construction on reusable components have been published. Typicat examples are Ada design guidelines (see Ausnit [7], Bott [24], Braun [25], Burton [28], MacAnAirchinnigh [84], Nise [94], St.-Dennis [1 12]). The guidelines, notwithstanding their usefulness are essentially limited to specifying syntactical well-formedness constraints. Most of the guidelines for Ada reusable components concentrate on (i) syntactical aspects and on (ii) reusable program parts. In MERLIN [36] the notion of reusable component is extended, by allowing all kinds of program and documentation fragments to become ‘reusable components’. Guidelines
lyze three systems on one domain) from Biggerstaff
[17, 18],
based on the idea that one should do domain analysis rather than system analysis. This helps to find the basic set of functionalities. Here we see the beginning of the notion that reusable components are indeed reused somewhere in a system. Component documentation Looking at the action a software engineer has to take: map an input description to a component; the workload will be less if ●
not only a component is offered but also a higher level description of it, This makes it easier to map the own input description to the component.
. examples of use are given. This makes it easier to see whether a mapping can be useful. In current literature some thought is given as to what a component needs as documentation. Higher level descriptions are suggested, either in keyword form, or in formal language or in informal language. Castano and De Antonellis [29] suggest to provide a set of design suggestions about ways to incorporate reusable components into an application by means of possible adaptations and transformations. Thus, attention is paid to the systems in which the components will be used, Fischer et al. [53] showed that fundamental obstacles to the effective documentation and use of design rationales exist. Components-bases
140
The function of a components-base is to
maintain an adequate set of reusable components. Di Felice [51] describes a code development method which reflects his
between text and software transforming input into output by executing components. The drawback of their
belief that development of code should follow general criteria
method is clear: only code can be retrieved in this way.
for the design and implementation
of reusable components
from what already exists in a and should be independent library. This is contradictory to the idea that the function of a components-base is to maintain an adequate set of reusable components. Since reuse is not done in a vacuum [14, 42], a components-base should reflect a domain rather than being filled with unrelated components. The papers addressing a compilation of a components-base, although agreeing with the quality statement above, do not address maintaining
Reusing
quality when filling a components-base.
According
to the steps given before, four process
Understand The required depth of understanding a component depends on the degree of required adaptations to the components. The number of approaches and tools reported on in literature that might aid in understanding components is surprisingly small. Biggerstaff [ 17] describes Desire-88, a tool aimed at fostering understanding by the human software engineer. Its predecessor, Desire is compared with Draco in [4]. TOELICHTEN: In our feeling, one of the current barriers for reuse is the insufficient attention paid to understanding components.
steps can be identified in the process of reusing an artifact, i.e. (i) find; (ii) select; (iii) understand; (iv) adapt. Finding and Selecting a component Although finding and selecting are named as separate steps in the reuse process, it is hard to make a practical distinction between them. Techniques for
Adaptation of components Often, potentially usable components only match partially to the functionality required. Although the intuitive approach is to adapt the component
especially jinding components have caught rather much attention. Even several support systems have been built. Most
components. Another, and better approach, found in the system’s view is to wait till all components are there and then to decide what to do.
of the described systems (either built or merely proposed) are based on some form of key-word based searching in a common data base. ●
Prieto-Diaz
[101, 99] developed a faceted scheme as
an extension. Experiences with a system based on this scheme is reported on in [100]. Based on this work, Burton et al [271 constructed a reusable Software Library. The faceted scheme was used in REBOOT
as well, re-
sults of the use is described by S@-umg5rd et al [111]. Recent extensions to the original faceted scheme technique are facilities for retrieving higher level design information, such as data flow diagrams and transforming these into queries fitting the faceted scheme [80]. In MERLIN
[36], yet another extension
classification
scheme has a semantic network structure
with links and an underlying The initial restrictions
is used; a
faceted scheme.
found, one might end up by doing far too much work, since the missed functionality
might be obtainable through other
It is generally understood that adaptation of components is made easier when components have a high degree of parametrization, i.e. some form of polymorphism. Early work on parameterized programming can be found in [60]. Other interesting work on the construction of polymorphic components for monomorphic languages is reported by e.g. Grosch en Snelting[62]. A recognized problem with adapting components is maintaining the level of quality. Laskl and Szermer [77] report on regression analysis for reverification
of adapted components.
From the discussion, it is clear that the scope of most of the research is small. It seems evident that integration of work being done on the different steps of this simple paradigm is required, as is integration of the reuse steps in a software engineering process.
3.1.2
Transformation-based
reuse
in the kind of reusable artifacts
in which is used by Chen et al. [30] and incremental query construction [67] based on Frakes’ and Pole’s study [55] that constructing effective queries is as important or more important than the retrieval algorithm.
In its most general form, transformation-based reuse is similar to forms of automatic programming. The idea of automatic programming has existed since 1958 (described by e.g. Rich & Waters [105] and Barstow [9, 10]. This kind of reuse amounts to reusing the transformation. In this kind of reuse, a suitable descriptive pattern is provide as input, the transformer will select and adapt pre-existing artifacts, together forming the (semantically equivalent) output. Standard overviews on transformation-based systems, e.g. [96, 33], do not take the viewpoint of reuse.
. Where most people describe retrieval of components based on text-retrieval systems [6, 48, 54, 83], Podgurski and Pierce [97] use the inherent difference
In general, in a transformation-based reuse system, a high level specification is provided which is analyzed and translated by the reusable component. The user level specification
that could be retrieved were addressed by Fugini and Faustle[58]. They extend the kind of artifacts that can be retrieved with (structured )requirements, designs and correspondences. ●
Signature matching, a completely
differrent
approach
141
is concentrated on an input description. Typical examples of such systems are program generators, e.g. 4th generation language processors as well as attribute grammar processors. In some cases transformation is not completely automatic but requires some form of user guidance. Typical research areas address questions on how end-users write input as opposed by experts [31], on what languages are to understand most easily [37], how to structure the programmers’ task [109], and what knowledge is needed [1 10]. Furthermore, support for transfomning a specification into an efficient program [107] is also addressed. Research, however, is typically
concentrated on the form and
structure of the input.
3.2
Knowledge
to reuse artifacts
As stated before, a reusing engineer needs factual knowledge on the components. Apart from this factual knowledge, actually being able to apply reuse requires some knowledge of how and when to instantiate a component. This kind of Not only pure knowlknowledge is called metaknowledge, edge is required, ability, i.e. experience to be able to apply a component as well as attitude, i.e. willingness to apply it, are required as well. Ability will not be discussed.
transformation-based system. In fact, metaknowledge be seen as a process description. Literature emphasizes product artifacts.
can
Some authors sug-
gest providing meta knowledge implicitly, giving examples. Although this is a nice starting point, criteria are needed to validate the usefulness of the examples. A better approach to encoding metaknowledge on artifacts is giving a decision tree or a design rationale [13, 12].
3.2.3
Attitude
Standish et al [1 13] describe typical obstacles to a fruitful application of reuse. They recognize that, opposite to technological problems that have to be solved, the attitudes should be changed. The management view on reuse, addressing attitude issues, is reasonably covered by literature. Typical references: [125], [34], [123], [32], [35], [104], [89]. Most authors acknowledge the difference in ‘state of the art’ and ‘state of practice’, although authors differ in their explanation: the not invented here (NIH) syndrome, the fact that current software is not made to be reusable, technical barriers, and education. A refinement of the NIH syndrome is given by e.g. Fafcharnps [50].
3.2.1
Factual
Kang and Levy [73] argue that current software is not
Knowledge
developed for reuse. Their discussion was incomplete since they did not consider those circumstances where software was developed for reuse.
Although the requirement of factual knowledge is acknowledged in the field, presentation forms of factual knowledge of reusable artifacts are hardly addressed in current literature. Some authors suggest various specification forms, but fail to address constraints on the contents of such specifications.
Lubars[82]
claims that (i) a change of attitudes by the
software industry and (ii) the establishment of convenient cataloging and indexing tools is needed.
Notable exceptions in this area are: ●
LaSSIE[40]
Rickert [106] expects that a change of attitude will be insufficient by itself, quality of the code should be guaranteed as well.
in which software reuse is promoted by
providing multiple viewpoints of modules, including architectural, domain, and code perspectives. ●
3.2.2
D’ Alessandro et al. [38] who developed a framework for the specification of generic reusable components. All features of the component necessary for its effective use are stored with the component. Documentation, design rationale, formal specifications, reuse history, and access rights are counted to these features.
Based on practical experience, Hulkkonen and Keha [69] claim that both training and information, easy access to components, but in particular encouragement by the management, are the keys to reuse being successful. Their observations are confirmed by Motorola’s experience, described by Joos [72], Based on the above, our observation that the attitude problem is recognized and addressed seems justified.
Metaknowledge
Metaknowledge (a term from cognitive psychology) of a component encompasses the knowledge on envisaged use of this component. Actual (re)use of an artifact not only uses meta knowledge it also extends meta knowledge. Making such metaknowledge explicit, eventually leads to a non-automated kind of
3.3
Building
target
systems
As stated in section 2, the ability of finding components is by itself insufficient for successfully applying reuse in building systems. According to our paradigm, the reusing engineer might have to adapt artifacts, integrate artifacts into new artifacts and might even have to develop other artifacts. 142
Several experiments show that the availability of the right components, and the right tools is insufficient for reuse to take place. Maiden and Sutcliffe [86], in carrying out experiments with reuse of abstract templates and concrete specifications, demonstrate that in the process of choosing components, people tend to focus on surface, i.e. lexical properties of the reusable components, rather than on concepts. Similarly, experiments made by Woodfield et al. [124] show that programmers
underestimate
use of the system for software development. The system provides context-specific guidance on the relevance to a design of existing modules, it provides guidance on deciding what design modifications will be required in order to be able to include them. Another approach is discussed by Dusink [41]. The approach to a development method is presented, the discussion focuses on requirements to be met by development methods for reuse.
the effort needed to adapt
components to their need.
The SRSGEN (Software Reuse Systemen GENerator)
The integration of reuse tools in a software engineering environment, is felt to be essential by Poulin[98] as a precondition for reuse. Based on this observation and a purely “find/select/connect” method, an integrated environment for
tem, described by Ku [76] is a tool generator intended to provide a greater integration between software development activities and the reuse of modules. It takes the viewpoint that reuse must be integrated into the day-to-day operation of projects it affects. PRACTITIONER [65] concentrates on
components-based reuse is being built. On the other hand, others feel that no special ‘method’ is needed for reuse. The mere statement that ‘reuse should be done’ ought to be sufficient
[1 14, 95].
This opinion is not
shared by the authors. In building a target system from exisiting and reusable components, the following activities might have to be performed: ●
sys-
the reuse of concepts rather than on code. Furthermore, it focuses on working with existing software rather than prescribing practices which will lead to the development of new software being reusable. The observation that the number of ‘complete methods’ is small, seems justified. This observation suggests that this element of reuse is still in its infancy.
adaptation of a set of outputs; 3.3.2
Adaptation
c integration of the set of outputs; ●
further development
Building ●
of a set of outputs.
such a system will be facilitated
the development
when:
history of the reusable components
can be traced back. Handbooks on how to document for maintenance provide insight in documenting such that choices are documented.
Contrary to common beliefs in literature, where adaptation is an activity on the level of individual components, adaptation is an activity to be performed prior to the integration of the system. This is required after components have been selected, and the discrepancies between interfaces have become clear. The kind of support required for adaptation becomes clear when looklng at e.g. Batory et al and Baxter, who are providing expert system tools to help with this instantiation process, by managing the sometimes massive number of constraints that have to be met when instantiating.
●
examples of use are given. Components are designed and implemented with a perspective of possible use, stated otherwise, every component has an intended use, both on a functional level as well as on a physical level.
From the view of the system and the actions of a software engineer, we will elaborate on methods, adaptation, integration, and further development.
3.3.1
Complete
methods
Dealing with complete models almost naturally implies the use of a capability model which serves as a basis for understanding and improving an organization’s reuse capacity. Davis [39] describes such a model. Comet[88] discusses a complete system, developed to support reuse on all levels of software design and implementation. The system is built around a continuously growing knowledge base. This knowledge base contains data on the
Arango [5] describes a way of reusing analyses and designs where one first comes up with a design and then looks at the impact of alterations; this is called G-H (graft-host). Anecdotical evidence of the approach within a successor to a recently completed project shows among others the following: while there is a reduction in the number of design iterations for a product release in a recently completed project compared to similar projects, designers of a follow-on project estimate that approximately 70~o of the design will be reused from technology books developed during the previous year. We don’t see much attention for this topic in literature.
3.3.3
Integration
The elements of integration insight
are (i) how, (ii) what to do with integrations, (iii) what to do
into the set of possible
with the new system itsel$
The first element is covered by a variety of module interconnection languages, although the issue of puzzling, i.e.
143
what the appropriate places are for the various pieces, is not addressed.
3.4
Unfortunately,
was found on the second ele-
As stated in section 2 and restated in section 3.2, fac-
ment, i.e. representing the gained insight, Especially in transformation-based reuse, it seems hard to store somehow this kind of knowledge.
tual knowledge, metaknowledge, ability and attitude are attributes needed by reusers. Hard] y any literature deals with
no literature
A discussion on recursiveness of the reuse procedure, the third aspect, was not found in literature. The scaling up of reuse is genuinely hindered by absence of knowledge on this topic. An early discussion Kernighan
on reuse and integration
[74], who shows how well UNIX
compositional
is given by
is designed for
reuse with the simplest of concepts.
Tracz [1 19] implemented LIL [59] and called it LILEANNA (LIL extended with Anna). It is a language for formally specifying and generating Ada packages. Another way of expressing module interconnections (in Ada) is found in [63].
Knowledge
needed to build
target
systems
these topics. It is to be reasoned that construction of a system requires knowledge, both factual knowledge and metaknowledge, about the problem to be solved and the available parts. This knowledge should contain elements of both the problem domain and the software engineering domain. Furthermore, ideas on application and combination of the reusable artifacts are required. There exists some literature on how the way components are learned, influences what can be done with them. All kinds of knowledge can be learned in a functionally in a non-functionally fixed way.
fixed way, or
Hall and Weedon [66] differentiate between horizontal and vertical composition, where the first is a design on one level of abstraction and the other is a design of how a part is
Functional fixedness is a term from cognitive psychology referring to the way in which knowledge for the solution of a specific problem is acquired. For instance, if shown a box with tools and asked to solve problem ‘A’, people will use the tools but not the box. They have learned the box as a
refined. Their interconnection
language, based on this idea,
container of tools only, thus in a functionally
is an algebraic object-oriented
language.
Such fixedness limits the range of perceptual organizations capable of being developed by the problem solver with re-
Reuse is the natural way of working with UNIX. The ease with which integration in UMX can be handled, is a discrepancy as to the other approaches, where compositional reuse is treated as being very difficult, needing heavy tools.
fixed manner.
spect to the knowledge acquired. As a result this fixedness interferes with the problem solving capacity of a reuser. A description of this phenomenon from the psychological side is found in [21, 22, 108]. A description of the influence of this phenomenon on reuse and ways to overcome it is found
3.3.4
Further
Processing
After adaptation and integration, the output may be a complete architecture or an executable. In the first case, further processing is needed in order to get the second case, or preprocessing of the input descriptions is needed before being able to start the reuse process. There is a trend towards larger leaps between input description and output description, from simple Booth-style components [87] to compiler-compilers, or database-generators [11]. The size of the leaps depends on the stability and maturity of domains. There are also large leaps which concentrate on subsystems. Very often they start with an informal description followed by a graphical layout of the subsystem. Some are implemented with the help of hypermedia [16, 61,8, 78]. The higher the input level, the less work has to be done by the reusing engineer to prepare the input, and the greater the possibility that no costly design errors are made (assumed quality of component). Thomas, Delis and Basili [11 6] present a reduced error rate. Summarizing, reuse of components is growing from the reuse of simple library functions to the reuse of large subsystems. Similarly, the size of the development step, i.e. the distance between input description and output description, covered by reuse is growing rapidly.
in [43]. We can conclude that this topic is clearly interesting but that hardly any literature can be found on this topic.
4
Conclusion
Covering the developed framework with the current literature on reuse gives a good impression on the focus of research. Its interpretation provides insight into the degree of development of topics, and thus serves its goal. It becomes clear that attention is not equally spread over the complete research space. Most attention is paid to the component view, while within the component view the product is overemphasized, compared to the attention on the process. Even further, it might be observed that most research still concentrates on components on ‘outer appearance’ of reusable components. On the other hand, at code level there is by far the most choice in languages. In earlier stages of the software engineering traject there is less choice in formally defined notations, in particular the verification of architectures is seldom possible, The reuse field mirrors this phenomenon by having most research concentrating on code components, how to make them and how to store them, and paying less attention to architectures and requirements. 144
As nearly every paper starts with observing that reuse is still not mature while the problem will be solved in the paper
[10] D.R. Barstow. Domain-Specific Automatic Programming. IEEE Transactions on Software Engineering,
in question, a further observation is that reuse still does not live up to its promise.
We are of the opinion that one of the
reasons is the underdevelopment
of research from the system
11(1 1):1321–1336, November 1985, [11] Don Batory and Sean O’Malley. Layered Domains.
view.
Genvoca
In Ruben Prieto-Diaz,
Reuse In Wdhelrn
Schafer, Joachim Cramer, and Stefan Wolf,
We feel it time to gather the fruit from the experiences from different isolated studies (the comparing study from Frakes [55] being an excellent example), and to integrate the partial solutions into an integrated approach with embedding into a regular software development process. Current literature is thought to provide a sufficient mass for such an exercise. We have started a research project in which we develop a reuse supporting method, based on the findings in this survey. The statement “Reuse is all the knowledge a software engineer does no longer need to possess” is untrue, since a lot of the reused knowledge need to be understood by the software engineer for proper reuse.
Proceedings Software
of the First
Reusability,
editors,
Workshop
Germany,
July
on 3-5,
Nr. 57, pages 108-113.1991.
[12] Don Batory, Vlvek Singhal, Jeff Thomas, Sankar Dasari, Bart Geraci, and Marty Sirkin. The GenVoca Model of Software-System Generators. IEEE Software, 11(5):89–94, September 1994. [13] Ira D. Baxter. Design maintenance systems. Communications
of the ACM,
35(4),
1992.
[14] E.V. Berard. Software Reusability Cannot Be Considered in a Vacuum. In Michael [92], pages 390–393. C. Richter. Reusability Framework,
Assessment, and Directions.
References
IEEE
Soflware,
4(2):41–
49, 1987.
[1] W. W. Agresti,
editor. New Paradigms for Software IEEE Computer Society Press, 1986.
[16] Ted J. Biggerstaff, Hypermedia as a Tool to Aid Large Scale Reuse. In Workshop on Software Reuse, Rocky Mountain
Adaptable Software [2] N.A. Alexandridis. ware: Problems and Solutions. Computer,
and Hard-
Institute
of Software
Engineering,
Boulder,
CO, October 1987.
19(2):29–
[17] Ted J. Biggerstaff. Design Recovery for Maintenance and Reuse. Technical Report STP-378-88, Micro-
39, 1986.
[3] Alejandro Alonso and Juan A. de la Puente. Reusable Real-Time Executive in Ada. Design issues. ACM Ada Letters,
Dortmund,
1991, number MEMO
[15] T. Biggerstaffand
Development.
International
X111(2):44-53,
Mar/April
electronics and Computer (MCC), November 1988.
Technology
Corporation
1993.
[4] Guillerrno Arango, Ira Baxter, Peter Freeman, and Christopher Pidgean. Maintenance and Porting of ConSoftware by Design Recovery. In Proceedings ference on Software Maintenance, pages 42-49, Los Alamitos, California, 1985. IEEE Computer Society Press. [5] Guillermo Arango, Eric Schoen, and Robert Pettengill. Design as Evolution and Reuse. In Wleto-Diaz and Frakes [102], pages 9–18. [6] S.P. Arnold and S.L. Stepoway. The REUSE system: Cataloging and retrieval of reusable software. In Michael [92], pages 376–379. [7] C. Ausnit, C. Braun, E. Sterling, J. Goodenough, and R. Simpson. Ada Reusability Guidelines. Technical Report Report no 3285-2-208/2, SofTech Inc., Waltham, MA, April 1985.
[18] T.J. Biggerstaff. and Reuse. IEEE
Design Recovery Computer,
for Maintenance July 1989.
22(7):36-49,
[19] T.J. Biggerstaff and A.J. Perlis. Foreword on ReusabilIEEE Transactions on SofWare Engineering, ity. 10(5):474-476,
September 1984.
[20] T.J. Biggerstaff and A.J. Perlis, editors. Software Reusability, volume 1 & 2 of Frontier Series. ACM Press, 1989. [21] H.G. Birch. The Relation of Previous Experience to Journal of Comparative Insightful Problem-Solving. Psychology,
38:367-383,1945.
[22] H.G. Birch and H.S. Rabinowitz. The Negative Effect of Previous Experience on Productive Thinking. In Wason and Johnson-Laird [122], chapter 3. [23] M.F. Bott. Software Reuse — An Overview. Colloquium
on Reusable
Software
gest No. 68), page 28. IEE, London England,
[8] S.C. Bailin and S. Henderson. Towards a Case-Based Software Engineering Environment. In et al. [49]. [9] D.R. Barstow. A Perspective on Automatic Programming. AZ Magazine, pages 5–27, Spring 1984.
In IEE
Components
(Di-
1987.
[24] M.F. Bott, A. Elliot, and R.J. Gautier. Ada Reuse TechniGuidelines. cal Report ECLIPSE/REUSE/DST/ADA-GUIDE/RP, Software Sciences Ltd., 1986.
145
[25] C.L, Braun, J,B. Goodenough, and R.S. Eanes. Ada Reusability Guidelines. Technical Report TR 3285-2208/2, SoftTech Inc., April 1985.
[41] E.M. Dusink. A Design Method to Make Re-Use Happen, chapter 8, pages 87-96. In Dusink and Hall [45], 1991.
[26] P.T. Breuer and K. Lane. REDO at Oxford. In Dusink and Hall [45], pages 39-49.
[42] E.M. Dusink. Reuse is not done in a Vacuum. In et al. [49].
[27] B.A. Burton, R.W. Aragon, S.A. Bailey, K.D. Koehler, and L.A. Mayes. The Reusable Software Library.
[43] E.M. Dusink and L. Latour. Controlling Functional the Essence of Successful Reuse. In Fixedness: N Wognum, editor, Ecai94, Workshop Proceedings
IEEE
Soflware,
[28] B.A. Burton
4(4):25–33,
1987.
and M.D. Broido.
Ada Package Library.
Development
In NASA’86
[29] S. Castano and V. De Antonellis. Approach to Reuse of Conceptual Prieto-Diaz
Design for Reuse,
of an
[93]. A Constructive Components. In
and Frakes [102], pages 19-28.
[30] P.S. Chen, R, Hennicker, and M. Jarke. On the Retrieval of Reusable Software Components. In PrietoDiaz and Frakes [102], pages 99–108. [31] T.T. Cheng, E.D. Lock, and N.S. Prywes. Use of Very High Level Languages and Program Generation IEEE Transactions by Management Professionals. on Software Engineering, 10(5):552–563, September 1984. [32] J. Clapp. Software Reusability: A Management View. InCOMPSAC’84 [35], pages 479-480,
[44] E.M. Dusink and J, van Katwijk. Reflections Reusable Software and Software Components. Tafvelin [1 15], pages 113–126.
IEEE
So+are,
[34] The Small
Building 5(4):25–33,
Computer
Application July 1988.
(Revolution,
Springer Verlag, 1991. [46] James Baldo Jr. (cd.), Reuse in Practice Workshop Summary. Technical Report IDA Document D-754, Institute for Defense Analyses, April 1990. [47] J. Edwards. Schemas to code. Technical report, Associative Design Technology, Westborough, MA, 1990. [48] D.W. Embley and S.N. Woodfield. A Knowledge Structure for Reusing Abstract Data Types. In Pro-
Generators.
Proceedings
of the 9th International
ware Engineering, terey, California,
of COMPSAC 84, Silver Spring, MD, [35] Proceedings USA, November 1984. IEEE Computer Society Press.
March
ber 26-291992,
[50] Danielle Fafchamps. Reuse. ZEEESoftware,
49, 1991.
ware: A Contribution. Engineering,
IEEE
WorkOcto-
Organizational Factors and 11(5):3141, September 1994.
[52] G. Fischer. Cognitive
[40] P. Devanbu, R.J. Brachman, P.G. Selfridge, and B.W. Ballard. LaSSIE: A knowledge-based software inforof the ACM, 34:35– mation system. Communications
Mon-
1992.
[37] A. Cross. Design Intelligence: and Language Systems. Design 1986.
[39] T. Davis. The Reuse Capability Model: A Basis for Improving an Organization’s Reuse Capability. In Prieto-Diaz and Frakes [102], pages 126–133.
on Soft-
2 1987,
[49] Larry Latour et al., editor. WISR’92, 5th Annual shop on Sojlware Reuse, Palo A lto California,
[51] Paolino Di Felice. Reusability
[38] M. D’Alessandro, P.L. Iachini, and A. Martelli. The Generic Reusable Component: An Approach to Reuse Hierarchical 00 Designs. In Prieto-Diaz and Frakes [102], pages 39-46.
April
USA, pages 360–368, Washington,
[36] Joachim Cramer, Heike Hunnekens, Wdhelm Schafer, and Stefan Wolf. The MERLIN Approach to the Reuse of Software Components. In Dusink and Hall [45], pages 57–75. The Use of Codes Studies, 7(1): 14–19,
Conference
30-
DC, USA, 1987. IEEE Computer Society Press.
of
COMPCON Fall 84, Sept 1984, Silver Spring, VA, USA, 1984, IEEE Computer Society Press.
on In
[45] Liesbeth Dusink and Patrick Hall, editors. Software Re-Use, Utrecht 1989, Workshops in Computing.
ceedings
[33] J.C. Cleveland,
1994.
IEEE
19(8):835–843,
Software,
of Mathematical
Transactions
Soft-
on Sojhvare
August 1993.
View of Reuse and Redesign.
4(4):60-72,
1987.
[53] Gerhard Fischer, Andras C, Lemke, Raymond McCall, and Anders 1. Morch. Making Argumentation Serve Design. to appear in HCI Journal, April 1991. [54] W.B. Frakes and B ,A. Nejmeh. An information system of the IOth Minfor software reuse. In Proceedings nowbrook
Workshop
N. K, July 28-31
1987}.
on Software Syracuse
Reuse University,
(Syracuse, 1987.
[55] W.B, Frakes and T. Pole. An Empirical Study of Representation Methods for Reusable Software Compoon Soflware Engineen”ng, nents. IEEE Transactions August 1994.
146
[56] W.L. Frank. What limits to software gains. Computerworld,
pages 65–70, May 1981.
[57] P. Freeman, editor.
Tutorial:
Software
[73] K.C. Kang and L.S. Levy. Software Reuse: What’s Behind the Buzzword. Technical Report CMU/SEI89-TR-27,ESD-89 -TR-36, Software Engineering In-
Reusability.
stitute, Carnegie Mellon University,
IEEE Computer Society Press, Washington DC, 1987. [58] M.G. Fugini and S. Faustle. Retrieval of Reusable Components in a Development Information System. In Prieto-Diaz and Frakes [102], pages 89–98. [59] J.A. Goguen. LIL- A Library Interconnect Language. Libraries Workshop, pages In Report on Programming 12–5 1, Menlo Park, Calif., October 1983. SRI Inter-
Reusability. neering,
[60] J.A. Goguen.
Parameterized on Software
Programming.
Engineering,
Compo-
Regression
Analysis
In Prieto-Diaz
Object Oriented Module
Owego
New
York, November
[79] Larry Latour, Steve Philbrick, editors. 1991.
ACM
[68] J. B. Horowitz and E. Munson. An Expansive View of on Soflware Reusable Software. IEEE Transactions Engineering, 10(5):477487, September 1984. [69] T.O. Hulkkonen and N.M. Keha. Software Component Library. In Wallis [121], pages 175–182.
10(5):487-493,
[71] T.C. Jones, editor.
Tutorial:
A Survey of
and Chandu Bhavsar,
[82] M.D. Lubars. Engineering
Engineering
Notes,
Code Reusability
in the Large versus
in the Small. SIGSOFT Sojlware Notes, 11(1):21–28, January 1986.
[83] Y.S. Maarek, D.M. Berry, and G.E. Kaiser. An information retrieval approach for automatically conon Software Engineerstructing. IEEE Transactions ing, 17(8) :800-8 13, August 1991. [84] C. MacAnAirchinnigh. Reusable Generic Packages: Design Guidelines Based on Structural Isomorphism. 3rd Annual National Conference on In Proceedings Ada
Technology;
Hyatt
Regency
Houston,
Hous-
pages 132–144. US Army Communications-Electronics Command Fort Monmouth, NJ, US Army, Center for Tactical Computer Systems, 1985. ton,
Productiv-
IEEE Computer Society Press, Washington DC, second edition, 1986. the Eighties.
IEEE
Software
Code Reusability
on Software
[72] Rebecca Joos. Software Reuse at Motorola. Software, 11(5):42J17, September 1994.
Sigsoft
Software Library. 18(1):74-
[81] M.D. Lubars. Affording Higher Reliability Through Software Reusability. SIGSOFT Sofhvare Engineering Notes, 11(5):3942, October 1986.
1984 Programmer
2-41993,
80, January 1993.
[67] Scott Henninger. Using Iterative Refinement to Find IEEE Sof~are, 11(5):48-60, Reusable Software. September 1994.
of and
1993.
[80] Hsian-Chou Liao and Feng-Jian Wang. Reuse Based on a Large Object-Oriented
Interconnection Languages. In Prieto-Diaz and Frakes [102], pages 29-38.
Issues for
and Frakes
the “Understanding for Reuse” Problem. In Larry Latour, editor, WISR’93, 6th Annual Workshop on Software Reuse,
Early Reuse Practice lives up to its Sof~are, 5:87,88,90,91, November
[70] T.C. Jones. Reusability in Programming: the State of the Art. IEEE Transactions
Comput-
[78] Larry Latour. Experiments in Hypermedia Support for
In I%eto-Diaz
[65] Pat Hall, Cornelia Boldyreff, and Jian Zhang. PRACTITIONER: Pragmatic Support for the Re-use of Concepts in Existing Software. In Dusink and Hall [45], pages 97-108.
ity:
In Prieto-Diaz
Reusable Program Components. Frakes [102], pages 134-141.
[63] V. Grover and E. Guerrieri. Expressing Module Interconnections in Ada. In Wallis [121], pages 273–280.
[66] Pat Hall and Ray Weedon.
Engi-
10(5):528-
Polymorphic
nents for Monomorphic Languages. and Frakes [102], pages 47-55.
on Software
SRSGEN — A Software Reuse Tool for
Large Scale Applications. [102], pages 109-115.
Software Reuse Pro-
[62] F.-J. Grosch and G. Snelting.
System and Software
Transactions
[77] J. Laski and W. Szermer.
[61] M. Griss. A Multi-Disciplinary gram. In et al. [49].
Engineering,
The UNIX
[75] Charles W. Krueger. Software Reuse. ACM ing Surveys, 24(2): 13 1–1 83, June 1992.
IEEE
543, September 1984.
[64] Galen Gruman. Promise. IEEE 1988.
IEEE
10(5):5 13–5 18, September 1984.
[76] B.S. Ku.
national.
Transactions
[74] B.W. Kernighan.
May 1989.
Texas, March
1985,
[85] M. MacAnAh-chinnigh. Conceptual Model of an Ada Software Factory. Technical report, Ada-Europe Environment Working Group. Internal report, 1987,
147
[86] Neil Maiden and Alistar use:
Why Cognitive
Sutcliffe.
Aspects
The Abuse of Re-
of Software
[99]
Re-usability
are Important, chapter 10, pages 109–1 13. In Dusink and Hall [45], 1991. [87]
J. Margono and E.V. Berard. A Modified Booth’s Taxonomy for Ada Generic Data Structure Components and Their Implementation. In Tafvelin [115], pages
R. Prieto-Diaz. A Software Classification Scheme. Technical Report 85-19, Department of Information and Computer Science, University of California, Irvine,
1985.
[100] R. Prieto-Diaz. Implementing faceted classification of the 12th Interfor software reuse. In Proceedings national
61-74.
26-30,
Conference
on Sof~are
Engineering
(Mar
1990), pages 300-304, Washington D. C., 1990.
IEEE Computer Society Press. [88] William Mark, Sherman Tyler, James McGuire, and Jon Schlossberg. Commitment-Based Software Deon Software Engineervelopment. IEEE Transactions ing, 18(10):870-885, October 1992.
[101] R. Prieto-Diaz
and P. Freeman. Classifying
for Reusability.
IEEE
Soflware,
4(1):6-16,
[102] Ruben Prieto-Diaz and WNiamB. [89] Y. Matsumoto. Organizational Effort for Reusing Existing Softwares, InCOMPCON’84 [34]. [90] M.D.
McIh-oy.
Mass-Produced
Software
vances
NATO
Engineering Conference
Concepts
ity, March
Compo-
and Techniques;
1968
Engineering,
pages
on Softiare
88–98. Petrocelli/Charter,
Belgium,
1976.
[91 ] Bertmnd Meyer. Reusability: The Case for ObjectMarch Oriented Design. IEEE Software, 4(2):50–64, 1987. [92] G.A. (chair) Michael, Spring national Digest
Joint
editor.
Computer
Conference, of Papers.
Intellectual
Conference
San Francisco,
87;
Leverage; 32nd
Inter-
Feb 23-271987,
IEEE Computer Society Press Wash-
ington DC, 1987. [93] Proceedings plicationsfor
1st Conference
on Ada Programming
the NASA Space Station,
Houston,
Ap-
Reuse:
Second International 24-26,
Frakes, editors. Ad-
Selected
Workshop 1993, Lucca,
Papers from
on Software Italy.
the
Reusabil-
IEEE Computer
Society Press, 1993.
nents. In J.M. Buxton, P.Naur, and B. Randell, editors, Software
in Softiare
Software 1987.
[103] C.V. Ramamoorthy, V. Garg, and A. Prakash. Support on for Reusability in Genesis. IEEE Transactions Soflware Engineering, pages 1145–1 154, 1988. [104] G.E. Raymond and D.M. Hollis. Software Reuse Ecoof the Eighth Annual nomics Model. In Proceedings Washington Ada Symposium, pages 141–155, Virginia, 1991. McLean. [105] C. Rich and R.C. Waters. Automatic Myths and Prospects. IEEE Computer, August 1988. [106] N.W. Rickert. Preconditions Code. ACM
June
11(2):21,
1986,1986.
SIGSOFT
Programming: 21(1 1):40-5
1,
for Widespread Reuse of
So@are
Engineering
Notes,
1986.
[94]
N.S. Nise and C. Griffin.
Considerations for the Design of Ada Reusable Packages. In NASA’86 [93].
[107] A.J, Rockmore. Knowledge-Based Software Turns Electron. Specifications into Efficient Programs. Des.(USA), 33(17):105–12, July 1985.
[95]
James O’Connor, Catharine Mansour, Jerri TurnerHarris, and Grady Campbell. Reuse in Command-
[108] P. Saugstadt and K. Raaheim. Problem-Solving,
and-Control Systems. September 1994, [96]
[97]
Sojhvare,
11(5):70-79,
H. Partsch and R. Steinbrtiggen. Program TransformaSurveys, 15(3): 199– tion Systems. ACM Computing 236, September 1983. reprint in Agresti [1], ppl 89226. Andy Podgurski and Lynn Pierce. Retrieving ACM Reusable Software by Sampling Behavior.
Past
In Wason
[109] M.E. Sime, A.T. Arblaster, and T.R.G. Green. Structuring the programmer’s task, In Bill Curtis, editor, Tutorial:
Human
Factors
in Sojiware
Development
pages 453-464. IEEE Computer Society Press/ North-Holland, 1986. (second
edition),
July 1993.
[110] K, Soloway and E. Ehrlich. Empirical Studies of ProIEEE Transactions on Softgramming Knowledge, ware Engineering, 10(5):595–609, September 1984.
Jeffrey S. Poulin. Integrated Support for Software Reuse in Computer-Aided Software Engineering Notes, (CASE) ”,. ACM Sigsoft Software Engineering 18(4):75–82, October 1993.
[1 11] L.S. S@rumgfud, G. Sindre, and F. Stokke, Experiences from Application of a Faceted Classification Scheme. In Prieto-Diaz and Frakes [102], pages 116– 124.
Transactions ology, [98]
IEEE
Experience and Availability of Functions. and Johnson-Laird [122], chapter 5.
on Software
2(3):286–303,
Engineering
and Method-
148
[1 12] R. St.-Dennis. A Guidebook for Writing Reusable Source Code in Ada. Technical Report CSC-863:8213, Computer Science Center, Honeywell Inc., 1000 Boone Avenue North, Golden Valley, Minnesota 55427,1986. [1
13] T.A. Standish. Transactions
An Essay on Software Reuse. IEEE on Software
Engineering,
10(5) :494–
497, September 1984.
[114] Werner Staringer. Constructing Applications from Reusable Components. IEEE Software, 11(5):61-69, September 1994, [1 15] S. Tafvelin, Tools.
editor. Ada Components:
Proceedings
Conference,
panion 1987.
Libraries
of the Ada-Europe
Stockholm
26-28
Series. Cambridge
May
and
International
Ada ComPress, U. K.,
1987,
University
[1 16] W.M. Thomas, A. Delis, and V.R. Basili. An Evaluation of Ada Source Code Reuse. In J. van Katwijk, tor, Ada: Moving Towards 2000, 1 lth Ada-Europe temational
Conference,
Zandvoort,
Zn-
the Netherlands,
June 1992, Lecture Notes in Computer
pages 80-91. Springer-Verlag,
edi-
Science 603,
1992.
[1 17] W. Tracz. Software Reuse: Motivators In Michael [92], pages 358-363.
and Inhibitors.
[1 18] W. Tracz, editor. Software Reuse: Emerging Technology. IEEE Computer Society Press, Washington DC, 1988. [1 19] W, Tracz. LILEANNA: A Parameterized Programming Language. In Prieto-Diaz and Frakes [102], pages 66–78. [120] F. Ververs, J. van Katwijk, and L. Dusink. Directions in Reusing Software. TechnicaJ Report TR 88-58, Faculty of Mathematics and Informatics, TU Delft, The Netherlands, 1988. [121] P.J.L. Wallis, editor. Ada: Proceedings
Managing
of the Ada-Europe
ence Edinburgh
6-8 May
1986.,
ries. Cambridge University
Selected
Confer-
Ada Companion Se-
Press, 1986.
[122] P.C. Wason and P.N. Johnson-Laird, and Reasoning,
the Transition.
International
Readings.
editors. Thinking Penguin Modern
Psychology. Penguin Books, 1968. [123]
W. Wong. A Management Overview of Software Reuse. Technical Report NBS Special Publication 500-142, NBS, Washington, DC, September 1986.
[124] S.N. Woodfield, D.W. Embley, and D.T. Scott. Can IEEE Software, Programmers Reuse Software? 4(4):52–59, July 198’7. [125]
R.T. Yeh, N. Roussopoulos, and B. Chu. Management of reusable software. In COMPCON’84 [34], pages 311-320.
149
