SOFTWARE REUSE

• - re-application of knowledge about one

system to another similar system in order
to reduce the effort of development and
maintenance of the similar system.
(Biggerstaff 89)

• - use of existing components of source

code to develop new software programs or
applications. (Poulin 96)

1
Software Components
 executable programs, code segments,
documentation, requirements, design,
architectures, test data, test plans,
experiences, domain models, software
architectures... (knowledge)
•

2
Some Expected Benefits of
Reuse
 lower development cost
 increase productivity
 easier maintenance
 increase quality
 lower risk
 lower training cost

3
Why reuse?
– reduce maintenance costs (50-75%) of life-
cycle costs.
– demand for high quality sw increasing
• often reused - fewer faults
– demand for improved productivity increasing
– reduce life cycle costs
– demand for early proof-of-concept increasing
– reuse can help meet this demand

4
Reuse generally takes 2 forms
in an organization
• AD-hoc - opportunistic reuse
– (happens by accident) White box reuse
• Systematic Reuse
– organization plans and designs reuse into their
development process.

– White box and Black box reuse

5
White box reuse
• Modifying existing software to make it fit.
• Modified Component must undergo the
same testing, maintenance,
documentation, as a new component.
• Achieves a marginal savings which does
not extend beyond the development phase.

6
White box reuse
• Development phase not as costly nor time-
consuming as the design, testing, and
maintenance phases.
• To make truly large gains in productivity
and quality -- reduce effort in design,
testing, and maintenance also.

7
Black Box Reuse
– Black box assets - unmodified software
components.
– Reuse of a software component without altering
the source file.
– Black box assets must have been built for
reuse. Modification, if allowed, is automated
and provided for.
– Developer requires behavior modification then
the assets may provide for this (Ex: parameter
setting)

8
Advantage of Black Box:
– The assets has been fully tested as well as
alternate versions.
– Fully documented, design is finalized.
– Understanding of its implementation not
necessary (not modifying)
– Understanding how to use it / its effect
– Significantly reduces effort - code, design, unit
test ,and maintenance.

9
Advantage of Black Box
• Raises the abstraction level required to
program
• Lowers perceived complexity
• Reduces the effort to enhance and
maintain the final product.
 Black Box reuse requires planning -
systematic reuse

10
systematic reuse
– large up-front cost, time, money, people,
resources to produce the assets.
– requires commitment by management
– may take 2 or 3 uses of the reusable asset (set
of assets) to see payoff.
– Need team of producers of assets.
– Not an easy task, No Rule book to follow,
challenging, requires committed, resourceful,
creative people.

11
systematic reuse
– Requires that the organization plan for reuse
and formally integrate it into a well-defined
software development process.
– Need Reuse Consumers: seek to reduce costs
through the work products of others.
– Need Reuse Producers: Produce the reusable
assets.
– But first:
– What software do we need to make reusable?
Identify the software to reuse.
– How do we make it reusable?

12
Identify- sw to reuse: Domain Analysis

Domain Analysis
• a well structured intense study of a
collection of related problems or a
collections of related applications
programs.
• Domain - area bounded by these
problems/applications.

13
Identify sw to reuse: Domain Analysis:
• strives to identify common parts of a
problem that occur in many other similar
problems in the domain.
• strives to develop an understanding of the
problems within the domain
• leads to models of the domain
• lead to preliminary design of the domain -
the general classes of problems and the
design of their solutions.
• domain architectures, reference architectures

14
Domain Analysis tasks -
– Characterize and understand the problem
space - factor out commonalties.
– Characterize and understand the solution
space
• (both what the solution space is now and what it
should be after factoring commonalities)
– Create a model of the Domain - (May take the
Form of a Domain Architecture or Reference
Architecture)
• Domain Engineering extends the domain analysis to
include the actual design and construction of the new
solution space.

15
Reuse -points to come
 External vs. Internal
 Horizontal vs. Vertical
• related to Domain-indep/dep sw
 Views of Reuse
• expansive, narrow, ad-hoc...
 Code Reuse vs. Design Reuse

16
External vs. Internal Reuse
• External Reuse
– Rule of thumb: software developed for reuse
external to the organization or external to the
application being developed.
• Count use of this software as reuse.
• Internal Reuse
– Refers to software developed and used
repeatedly by the same people working on the
same application.
• Good programming - Not production and use of
reusable assets.

17
Count as Reuse or not ?
– To be classified as reusable sw asset it needs
to be developed for use by other similar
applications and reused as part of the
application being developed.

– Use of Compilers, Operating systems,

developments, and other software that helps
with development of software should not be
counted as reuse.
• Should only count reuse within a project as applied
to code that must be developed as part of that
project.

18
Horizontal Reuse and Vertical
Reuse
• A typical Software Application is made up
of three classes of Software:
– Most generic - Domain-independent Software. -
Horizontal Reuse
– Specific to the Current Domain (Domain-
Specific) - Vertical Reuse
– Application Specific Software

19
Domain-independent
Software.
– Graphical User Interface Functions, Math
Libraries, Abstract data types
– This accounts for about 20% of an application
as a rule of thumb. [Poulin]
– Efforts at Reuse of this type of software can
hope to reduce development effort by 20%.
– Called Horizontal Reuse - Cuts across several
Domains.

20
Domain-Specific Software
– Navigation and Control for Aircraft, Database
Management Systems, Spreadsheet Software,
Word-processing, Desktop Publishing.
– Can account for up to 80% of the code.
– Efforts at Reuse of software from this category
can hope to reduce development effort by up to
80%.
– Called Vertical Reuse - Reuse is within the
domain only.
– Largest payoff points to concentration on
Vertical Reuse.

21
Application-specific
– Application Specific Software
• Handles the unique details of a customers
requirements. Custom Code.
• Typically accounts for about 15% of an application.
• Little potential for reuse of Custom Code.
• Domain-specific, Application-specific,
Domain-independent
– These Classifications can help form the basis
for developing an organizational reuse strategy.
– Help organization set reuse goals.

22
Reuse -points to come
 External vs. Internal
 Horizontal vs. Vertical
• related to Domain-indep/dep sw
 Code Reuse vs. Design Reuse
 Inhibiting factors of reuse
 fundamental problems

23
code reuse vs design reuse
Code Reuse
 10-15% project time and effort spent in
coding. (if reuse only at code level -
save 10-15% effort)
– Design reuse -more significant effort reduction
can be seen through the reuse of components
of a higher abstraction level such as design
components and design knowledge.

24
Reuse Code vs. Design
Code Reuse-
– take coded components and form a library of
reusable code.
– if domain is very narrow, very well defined,
success is much more likely.
– Otherwise, user will need more than just the code
to be able to reuse it successfully, either with or
without modification.
– many times the code itself is not reusable but the
general design ideas are. Reflects the way
experienced designers, developers work -

25
Code reuse: Generality and SIZE
• Increase in generality (applicable across domains) can
cause decrease in potential reuse payoff.
– Reuse of Technologies that are general /domain independent
(accounts for 15 -20 % of code) tend to have much lower
payoff than systems that are more narrowly focused (domain-
specific) (accounts for up to 80 of code).
• Component Size
– As component grows in size the payoff for reusing increases >
linearly.
– But - becomes more specific - reducing the level of its reuse
and increase in cost of reusing due to need to modify.

26
Design Reuse
• problem - current design representations
too close to code, too specific.
• Payoff potential for reuse of Design
information is high. Can lead to substantial
increases in productivity and quality.

27
Design Reuse/VLSR
 requirements
• !New representations! needed that allow
specification, retrieval, and processing of a
broad range of reuse - related knowledge
• Standards are also needed.

28
New Representations needed that

• allow large-grain component structure to

be specified ,component interface,
functionality
• allow broader range of information to be
specified than source code can.
– design structure, architecture, pattern of usage,
rationale, design decisions, rules for reuse,
context rules (rules of effect of change in
environment on reuse of component).

29
Standards are needed:
– apply to data interchanged
– apply to architectural structure
– impose broad structural patterns on systems
– govern reusable assets produced and
consumed.
– There is a strong relationship between
standards and architectures
– open the path for true product development by
assembly/composition based on functionality,
inputs and outputs.

30
** Inhibiting Factors of Reuse
– lack of representation for designs that foster
reusability. (Hardest to overcome)
– lack of a clear process and direction -
(management has to commit)
– requires a critical mass of reusable
components to really payoff.
• Cost of reuse library population.
– NIH (not invented here syndrome) has to be
overcome. A strong inhibitor. Organization has
to reward for reuse.

31
summarize inhibitors as
 high initial investment
 management indifference
 lack of a mature technology base

32
**fundamental problems
• identification of candidate components
(Domain Analysis)
• representation of components
• finding components to reuse (from a
library)
• understanding the component (in order to
reuse it)
• modifying the component (in order to reuse
it)
• composing components
33
Finding Components
– locate a highly similar component to reuse .
– smaller the component the easier to find a good
match.
– larger the component, more difficult.
component will perform more complex
functionality, introduce more dependencies and
assumptions about context of its use.
– more specific with regard to when it can be used.
– mitigated by restricting to domain-specific/vertical
reuse.
– previous work: classification schemes (Prieto-
Diaz, Ricter Katz to name a few)
34
Understanding Components
– reuse without modification - larger payoff -
understand function input, output, rules to
connect it.
– with modification - requires deeper
understanding -
– Reuse Requires the user be able to acquire a
mental model of the components computations
and the context.
– One approach: use hypertext systems to
annotate components, integrate text, graphics,
code.
– web of linked nodes. Each node can contain
designs, diagrams, rationale, test cases,
requirements, .. 35
Modifying Components
– probably over optimistic to think you can build a
reusability system that allows significant reuse
w/o modifying some portion of the component.
– Few tools to provide any measure of help.
Understanding is the key.
• The actual modification is largely a human task.
(With the exception of some code and application
generators that can create various versions,
instances, instantiations within a very well defined
domain.)

36
Composing Components
– taking a set of reusable components and
putting them together such that they will solve a
problem / subproblem at hand.
– difficult since a component generally has both
local and global (beyond the component)
effects.
– requires a representation that supports this kind
of activity.
– Recent work in software architecture and
ADLs.
• abstract representations define a system as a set of
components, connectors and connections - and rules
concerning each.
37
Stop
• There is a set of notes on Software Reuse
taken from Chapter 20 on the web site.
• Read chapter 20, look at the notes on that
chapter plus this set of notes.
 Final exam - comprehensive - over all
chapters that we covered in class and
the notes. - untested chapters will
constitute > 50% of test.

38