Software Reuse

(Lecture 15)

Dr. R. Mall

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.

What can be reused?

Specification Design Code Test cases At the most abstract level:

knowledge
6

Reuse of Knowledge
More difficult compared to dayto-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.

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: Consider airline reservation:
objects are
Operations are
seats, flights, airports, crew, meal orders

objects, operations and relationship among them.

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 domain is ripe for reuse set of concepts has stabilized standard solutions for standard problems knowledge and component reuse
30

Stage 3:

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-Diazs classification scheme:
each component described using a number of different characteristics (or facets)

34

Prieto-Diazs 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, keywordto-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 subroutines parameters are variants

parts of the subroutine that are not parameterized cannot be changed.

51

programmers can specify them when calling the subroutine.

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 products potential for reuse refine product for greater reusability integrate product with reuse repository
58

Assessing a products potential for reuse Questions can be devised to assess a components reusability:
is the components functionality required for future implementations? how common is the components function within the domain? is there duplication of the function within the domain?
59

Assessing a products potential for reuse

Is the component hardware dependent? Is the design of the components optimized enough? Is it possible to decompose a nonreusable 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

Operation generalization:

rather than direct reflection of some specific application.

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

Data References

Operating System 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 products potential for reuse refine product for greater reusability integrate product with reuse repository
73