Software Reuse

UNIT5
Chapter 3

Compiled by : Ms.Crimita Almeida

1 References Ian Sommerville

 What is Reuse
 Type of the software reuse
 The benefits of software reuse
and some reuse problems
 The reuse landscape

2
 What is Reuse
 In most engineering disciplines, systems are
designed by composing existing components th
at have been used in other systems.
 Software engineering has been more focused o
n original development but it is now recogni
zed that to achieve better software, more qu
ickly and at lower cost, we need to adopt a
design process that is based on systematic s
3
oftware reuse
 Reuse-based software engineer
ing
 System reuse
Complete systems, which may include
several application programs may be re
used.
 Application reuse
An application may be reused either
by incorporating it without change int
4
o other or by developing application f
 Reuse-based software engineer
ing
 Component reuse
Components of an application from
sub-systems to single objects may be
reused
 Object and function reuse
Small-scale software components th
at implement a single well defined ob
5
ject or function may be reused
 TYPES OF REUSE
Concerning motivation and driving factors , re
use can be :
• Opportunistic - While getting ready to begi
n a project, the team realizes that there are
existing components that they can reused.
• Planned - A team strategically designs comp
onents so that they'll be reusable in future p
rojects

6
7
Benefits of software reuse
 Benefits of software reuse

8
9 Problems with reuse
10 Problems with reuse
 The reuse landscape
 Although reuse is often simply thought of as the
reuse of system components, there are many
different
approaches to reuse that may be used.
 Reuse is possible at a range of levels from simple
functions to complete application systems.
 The reuse landscape covers the range of possible
reuse
techniques.
11
12 The reuse landscape
 Reuse planning factors
The development schedule for the software.
The expected software lifetime.
The background, skills and experience of the
development team.
The criticality of the software and its non-
functional requirements
The application domain.
The execution platform for the software.

13
 Generator based Reuse
Program generators involve the reuse of standard p
atterns and algorithms
 These are embedded in the generator and parameter
ised by user commands. A program is then automatic
ally generated
 Generator-based reuse is possible when domain abs
tractions and their mapping to executable code can
be identified
 A domain specific language is used to compose and
control these abstractions

14
 Types of program generator 
 Types of program generator
 Application generators for business data processi
ng
 Parser and lexical analyser generators for langua
ge processing
 Code generators in CASE tools
 Generator-based reuse is very cost-effective but
its applicability is limited to a relatively small
number of application domains
It is easier for end-users to develop programs usi
ng generators compared to other component-based ap
proaches to reuse

15
 Application framework
Frameworks are moderately large entities tha
t can be reused. They are somewhere between
system and component reuse.
Frameworks are a sub-system design made up o
f a collection of abstract and concrete clas
ses and the interfaces between them.
The sub-system is implemented by adding comp
onents to fill in parts of the design and by
instantiating the abstract classes in the fr
amework.

16
 Framework classes
System infrastructure frameworks: Support the developme
nt of system infrastructures such as communications, us
er interfaces and compilers.
Middleware integration frameworks: Standards and classe
s that support component communication and information
exchange.
Enterprise application frameworks: Support the developm
ent of specific types of application such as telecommun
ications or financial systems.
Web application frameworks: Support the construction of
dynamic websites as a front-end for web applications.
WAFs are now available for all of the commonly used web p
rogramming languages e.g. Java, Python, Ruby,etc.

17
 Application system reuse
Involves the reuse of entire application eit
her by configuring a system for an environme
nt or by integrating two or more system to c
reate a new application.
Two approaches are covered
COTS product integration
product line development

18
 COTS product reuse
A commercial-off-the-shelf (COTS) product is a softwa
re system that can be adapted for different customers
without changing the source code of the system.
COTS systems have generic features and so can be used
/reused in different environments.
COTS products are adapted by using built-in configura
tion mechanisms that allow the functionality of the s
ystem to be tailored to specific customer needs.

For example, in a hospital patient record system, sepa

19
 COTS product reuse
COTS systems are usually complete applicatio
n systems that offer an API (Application Pro
gramming Interface).
Building large systems by integrating COTS s
ystems is now a viable development strategy
for some types of system such as E-commerce
systems.
 The key benefit is faster application devel
opment and, usually, lower development costs

20
 COTS design choices
Which COTS products offer the most appropria
te functionality? There may be several simil
ar products that may be used. l How will dat
a be exchanged? Individual products use thei
r own data structures and formats. l What fe
atures of the product will actually be used?
Most products have more functionality than i
s needed. You should try to deny access to u
nused functionality.

21
 COTS products reused
On the client, standard e-mail and web brows
ing programs are used.
 On the server, an e-commerce platform has t
o be integrated with an existing ordering sy
stem.
This involves writing an adaptor so that the
y can exchange data. An e-mail system is als
o integrated to generate e- mail for clients
. This also requires an adaptor to receive d
ata from the ordering and invoicing system.

22
 COTS system integration probl
ems 
Lack of control over functionality and perfo
rmance COTS systems may be less effective th
an they appear l
 Problems with COTS system inter-operability
Different COTS systems may make different as
sumptions that means integration is difficul
t
 No control over system evolution COTS vendo
rs not system users control evolution
 Support from COTS vendors COTS vendors may
not offer support over the lifetime of the p
23 roduct
 Software product lines
Software product lines or application families are a
pplications with generic functionality that can be a
dapted and configured for use in a specific context.
A software product line is a set of applications wit
h a common architecture and shared components, with
each application specialized to reflect different re
quirements.
Adaptation may involve:
Component and system configuration;
Adding new components to the system;
Selecting from a library of existing components;
Modifying components to meet new requirements.

24
 COTS product specialization
Platform specialization Different versions of the
application are developed for different platforms.
 Environment specialization Different versions of
the application are created to handle different op
erating environments e.g. different types of commu
nication equipment.
Functional specialization Different versions of th
e application are created for customers with diffe
rent requirements.
 Process specialization Different versions of the
application are created to support different busin
ess processes

25
 COTS configuration 
Deployment time configuration A generic syst
em is configured by embedding knowledge of t
he customer’s requirements and business pro
cesses.
 The software itself is not changed.
 Design time configuration A common generic
code is adapted and changed according to the
requirements of particular customers.

26
 ERP systems
 An Enterprise Resource Planning (ERP) syst
em is a generic system that supports common
business processes such as ordering and invo
icing, manufacturing, etc.
These are very widely used in large companie
s - they represent probably the most common
form of software reuse.
 The generic core is adapted by including mo
dules and by incorporating knowledge of busi
ness processes and rules.

27
 Product line architectures
 Architectures must be structured in such a
way to separate different sub-systems and to
allow them to be modified.
The architecture should also separate entiti
es and their descriptions and the higher lev
els in the system access entities through de
scriptions rather than directly.

28
 Key points
 Application frameworks are collections of concrete a
nd abstract objects that are designed for reuse throu
gh specialization.
 COTS product reuse is concerned with the reuse of la
rge, off-the-shelf systems.
 Problems with COTS reuse include lack of control ove
r functionality, performance, and evolution and probl
ems with inter-operation.
 ERP systems are created by configuring a generic sys
tem with information about a customer’s business.
 Software product lines are related applications dev
eloped around a common core of shared functionality.

29
 THANK YOU

30