Software Reuse

1
 Organization of this Lecture

•Introduction
•Basic issues
•Domain analysis
•Reuse at organization level
•Summary
2
 Introduction
• Software is becoming very expensive:
– a possible way to reduce cost:
•reuse parts from previously made
software.
•assemble software from off-the-shelf
components.

3
 Introduction
• Advantages of reuse also include:
– reduced number of defects:
•standard and well-tested components
are reused.
– reduced development time:
•provide early market access for
products.

4
 Software reuse
• Software development with
reuse:
–similar to an electronic engineer
building an electronic circuit:
•uses standard types of electronic
ICs and other components.

5
 What can be reused?
•Specification
•Design
•Code
•Test cases
•At the most abstract level:
–knowledge

6
 Reuse of Knowledge
• More difficult compared to
day-to-day reuse of knowledge:
– developers vary over time and over
projects
– difficult to remember details of
potentially reusable development
knowledge.

7
 Why almost no software reuse so far?
• Engineers working in industry often
have a frustrated feeling:
– current system is similar to last few
systems they have already built
– everything is being built from scratch
– current system is behind schedule:
• no one has time to figure out what this
similarity really means.

8
 A major problem
• Creation of components reusable in
different applications:
– other than the application for which
these were originally designed.
– Very difficult to identify right kind of
reusable information:
•and to make them available to the user.

9
 Another complaint
• In spite of having software
components available for reuse:
– programmers have preferred to
create their own, because:
•available components are difficult to
understand
•difficult to adapt to new application

10
Libraries of software components
• No one in his right mind:
– would think of writing a routine to
compute sine or cosine.
• By investigating the question:
– why reuse of mathematical functions is so
easy?
– several interesting aspects emerge

11
Libraries of software components
• Standard terminology and concepts:
– cosine means same to all
– what arguments it takes, what it does.
• Small interface:
– exactly one number needed to compute
cosine
• Standardized data format

12
 Basic Issues in Software Reuse

• Component creation
• Component indexing
• Search
• Understanding
• Adaptation
• Repository maintenance
13
 Basic Issues
• Component creation:
– Identify reusable components
• Component indexing:
– classification of reusable components
– so that they can be easily searched
when we look for a component to
reuse.

14
 Basic Issues
•Search:
–search for right components in a
database of components
–requires a proper method to
describe components

15
 Basic Issues
• Understanding:
–to decide whether we can use some
component
•we need a precise and sufficiently
complete understanding of what the
component does.

16
 Basic Issues
• Adaptation:
– A selected component may not
exactly fit the problem at hand
– Tinkering with the code is not
satisfactory:
•in any case justified only if thoroughly
understood

17
 Basic Issues
• Repository maintenance:
– component entering
– tracking faulty components
– new applications emerge
•older applications become obsolete
•components might need changes
•obsolete components might have to be
removed
18
 A possible reuse approach

• Introduce building block approach

into the production process.
– identify reusable components after
development finishes
– enhance reusability of the identified
reusable components
•catalogue into a component library.

19
 Domain analysis
•Aim:
–identify reusable components
for a problem domain.
•identification of right kind of
reusable information is a difficult
problem.
20
 Reuse Domain
• A body of information
– considered to be a problem domain
for reuse if:
•a deep and comprehensive relationship
exists among information items :
•characterized by patterns of similarity
among software products.

21
 Reuse Domain
• A domain is a shared understanding of
some community:
– technical knowledge of some problem
area.
– characterized by notations that show
coherence
– examples of domains:
• accounting software
• banking software
• business presentation software
22
 Reuse Domain
• Just to become familiar with the
vocabulary of a domain:
–requires months of interaction
with experts
–often one needs to be familiar
with a network of related
domains
23
 Domain analysis
• Domain analysis identifies:
– objects, operations and relationship
among them.
• Consider airline reservation:
– objects are
•seats, flights, airports, crew, meal
orders
– Operations are
•scheduling a flight, reserving a seat,
assigning a crew to a flight, etc.
24
 Domain analysis
• Generalizes an application domain:
– a domain model transcends specific
applications.
•Common characteristics of similar systems
are generalized.

25
 Domain analysis
• Domain analysis is a more difficult
problem:
– compared to structured analysis.
• If we succeed in creating domain
components:
– we can define a domain specific
language.
26
 Domain analysis
• Ultimate result of domain analysis:
– Problem oriented languages (aka
application generators)
– application development standards
• During domain analysis:
– a specific community of software
developers get together
• discuss community-wide solutions.

27
 Domain analysis
• Analysis of an application domain:
–to identify the reusable
components
–Actual construction of reusable
components for a domain
•is called domain engineering.

28
 Domain analysis
• Domains slowly develop.
• As a domain develops, we may
distinguish various stages:
– Stage 1:
•no clear set of notations
•all software is written from scratch
•experience builds up from previous
mistakes

29
 Domain analysis
• Stage 2:
– similar problems are solved in similar
ways.
– knowledge reuse
• Stage 3:
– domain is ripe for reuse
– set of concepts has stabilized
– standard solutions for standard problems
– knowledge and component reuse

30
 Domain analysis
• Stage 4:
– domain has been fully explored
– software development for the
domain can be largely automated
– we do not program in the traditional
way any more:
•use a domain specific language
•application generators

31
 Classification
• If we look at hardware components
for clue:
– hardware components are classified
in a multilevel hierarchy
• Naming conventions are
standardized.

32
 Classification
• At the lowest level:
– description of components are given in several
forms
• natural language description
• logic schema
• timing information
• Description must be at a higher level:
– than complete specification of program logic
• ambiguity is inherent in the descriptions.

33
 Classification
• Prieto-Diaz’s classification scheme:
– each component described using a
number of different characteristics (or
facets)

34
 Prieto-Diaz’s classification
• Object classification scheme:
– actions they embody
– objects they manipulate
– data structures used
– systems they are part of, etc.

35
 Faceted classification
• Classifying a component
–choosing an n-tuple that best fits
that component.

36
 Faceted classification
• Faceted classification has advantages over
enumerative classification:
– strictly enumerative schemes use a predefined
hierarchy
– force you to search for a node that best fits the
component to be classified
– though cross reference to other nodes can be
included:
• the resulting network becomes complicated.

37
 Faceted classification
• Offers the possibility to expand questions:
– by considering components that are close to
the one sought
– closeness can be determined by appropriate
measures of distance between facets

38
 Searching
• A domain repository may contain
thousands of reuse items
– How can we locate the specific items
we are looking for?
• A popular search approach:
– provide web interface to the
repository.

39
 Searching
• A possible search approach with
web interface:
– Approximate automated search:
•search using key words
– Browsing:
•use links from items found during
approximate search to look up related
items

40
 Searching
• Approximate automated search:
– locate products that appear to fulfill some
of the specified requirements
• Browsing:
– Use keyword-to-keyword,
keyword-to-product, and
product-to-product links
– locate additional products and compare
their detailed attributes.
41
 Searching
• The search attributes represent
– the requirements of a product.
• Search support for:
– domain knowledge
– models of existing systems
– software components

42
 Searching
• The products located through
approximate search:
– serve as a starting point for browsing the
repository
– the developer may follow links to other
products
• until a sufficiently good match is found

43
 Searching
• Finding an acceptable solution
– may require several iterations of
approximate search
• followed by browsing
– with each iteration
• developer should have a better
understanding of the available products and
their differences.

44
 Repository maintenance
• Software industry is always trying to
– implement something that has not been
quite done before.
• As patterns of requirements emerge:
– reusable solutions also emerge
– eventually these solutions become more
or less standard.

45
 Repository maintenance
• However as technology advances:
– some components still reusable,
• do not wholly address required functions
• On the other hand:
– restricting reuse to highly mature solution
components
– neglect greatest potential reuse
opportunities.

46
 Repository maintenance
• Entering products in reuse database:
– deciding about search attributes
– relating it with other products for
approximate search
• Making a product available:
– before it has been thoroughly assessed
can be counter productive
– negative experiences tend to dissolve
trust in the entire reuse framework

47
 Reuse without modifications

• Once standard solutions emerge:

–no modifications to program parts
may be necessary
–direct plug-in parts

48
 Reuse without modifications
• Reuse without modifications is extremely
successful:
– classical program libraries
– supported by compilers through linkage to
run-time support routines (Application
generators)

49
 Application Generators
• Application generators translate
specifications into application programs.
• The specification usually is written in a
language called 4GL:
– or, the specification might appear in a visual
form
• the programmer creates a graphical drawing using
some standard available symbols

50
 Defining variant and invariant
parts
• Defining what is variant and what is
invariant:
– corresponds to parameterizing a
subroutine to make it reusable
– a subroutine’s parameters are variants
• programmers can specify them when calling
the subroutine.
– parts of the subroutine that are not
parameterized cannot be changed.

51
 Application generators vs. parameterized
programs
• Application generators have significant
advantages over simple parameterized
programs:
– can represent variant information in an
appropriate language
• rather than being restricted to function
parameters, named constants, or tables.

52
 Advantages of application
generators
• Application generators offer several
advantages:
– no need to bother about implementation
details
– development effort is substantially
reduced
– fewer errors
– easier to maintain

53
 Shortcomings of simple
application generators
• Application generators are handicapped
– if it becomes necessary to support some new
concepts or features
– some application generators overcome this
handicap
• through an escape mechanism
• programmer can write code in some 3GL through this
mechanism

54
 Application generators
• Application generators have been applied
successfully to:
– data processing applications
– user interface development
– compiler development
• Application generators are less successful
with
– real-time systems

55
 Reuse at organization level
• Reusability should be a standard part
in:
– specification, design, implementation,
test, etc.
• Ideally there is a steady flow of
reusable components:
– in practice, things are not so simple.

56
 Reuse at organization level
• Extracting reusable knowledge
from past projects:
– presents difficulties not encountered
in working with a current project
– typically original developers are no
longer available for consultation.

57
 Reuse at organization level
• Development of new systems leads to an
assortment of products:
– reusability ranges from immediate to highly
improbable.
• Steps for reusable component creation:
– assess product’s potential for reuse
– refine product for greater reusability
– integrate product with reuse repository

58
Assessing a product’s potential for reuse
• Questions can be devised to assess a
component’s reusability:
– is the component’s functionality required
for future implementations?
– how common is the component’s function
within the domain?
– is there duplication of the function within
the domain?
59
Assessing a product’s potential for reuse

• Is the component hardware dependent?

• Is the design of the components optimized
enough?
• Is it possible to decompose a non-reusable
component?
– to yield a reusable component?
• Can we parameterize a non-reusable
component?
– so that it becomes reusable.
60
Refining products for greater reusability
• For a product to be reusable:
– it must be relatively easy to adapt to
different contexts.
– machine dependency must be abstracted
out.
• localized using data encapsulation
techniques.

61
Refining products for greater reusability

• Name generalization:
– names should be general
• rather than direct reflection of some specific
application.
• Operation generalization:
– add operations to make it more general
– remove operations specific to an
application

62
Refining products for greater reusability

• Exception generalization:
– Involves checking each component to see
which exceptions it might generate.
– For a general component:
• several types of exceptions might have to be
handled

63
 Portability problems
• Machine architecture problems:
– program makes some assumption
•regarding information representation in
the underlying machine
•these assumptions are not true for all
machines

64
 Operating system problems
• The program calls an operating
system facility
– these are not available on all machines

65
 Library problems
• Program uses some function libraries:
– these are not available on all host
machines

66
Portability solution
Application System

Portability Interface

Operating System
Data References
and I/O calls

67
 Portability solution
• Rather than call O.S. and I/O procedures
directly:
– abstract versions of these are called by the
application program
– all platform-related features are routed through
the portability interface
• The problem with this solution:
– significant overhead

68
 Current State of Reuse
• Many factors restricting reuse are
non-technical:
– need for management commitment
– documentation for supporting reusable
components
– adequate incentives to reward those who
reuse
– providing access to and information about
reusable components

69
 Summary
• Basic issues in reuse:
– Component creation
– Component indexing
– Search
– Understanding
– Adaptation
– Repository maintenance

70
 Summary
• Creation of highly reusable components
is a very difficult problem
– a promising approach is domain analysis
• Domain analysis:
– aims to identify reusable components
for a problem domain

71
 Summary
• Application generators:
– translate specifications into application
programs.
– facilitate reuse
– not very flexible, if new concepts need
to be supported.

72
 Summary
• Reuse at organization level
– assess product’s potential for reuse
– refine product for greater reusability
– integrate product with reuse
repository

73