Software Reuse

CSC 3325: Software Engineering II

Dr. Bouchaib Falah

Objectives
To explain the benefits of software reuse and

some reuse problems

To discuss several different ways to implement
software reuse
To explain how reusable concepts can be
represented as patterns or embedded in program
generators
To discuss COTS reuse
To describe the development of software product
lines

Topics covered
The reuse landscape
Design patterns
Generator based reuse
Application frameworks
Application system reuse

Software reuse
Software reuse is the process of creating software systems

from existing software rather than building software systems

from scratch.
Software engineering has been more focused on original
development but it is now recognised that to achieve better
software, more quickly and at lower cost, we need to adopt
a design process that is based on systematic software
reuse.

Reuse-based software engineering

Application system reuse
The whole of an application system may be reused either by
incorporating it without change into other systems or by developing
application families.
Component reuse
Components of an application from sub-systems to single objects may
be reused.
Object and function reuse
Software components that implement a single well-defined object or
function may be reused.

Reuse benefits 1
Increased dependability

Reused software, that has been tried and tested in working systems,
should be m ore dependable than new software. The initial use of the
software reveals any design and implementation faults. These are then
fixed, thus reducing the number of failures when the software is reused.

Reduced process risk

If software exists, there is less uncertainty in the costs of reusing that

software than in the costs of development. This is an important factor
for project management as it reduces the margin of error in project cost
estimation. This is particularly true when relatively large software
components such as sub-systems are reused.

Effective use of specialists

Instead of application specialists doing the same work on different

projects, these specialists can develop reusable software that
encapsulate their knowledge.

Reuse benefits 2
Standards compliance

Some standards, such as user interface standards, can be

implemented as a set of standard reusable components. For
example, if menus in a user interfaces are implemented using
reusable components, all applications present the same menu
formats to users. The use of standard user interfaces improves
dependability as users are less likely to make mistakes when
presented with a familiar interface.

Accelerated development

Bringing a system to market as early as possible is o ften more

important than overall development costs. Reusing software can
speed up system production because both development and
validation time should be reduced.

Reuse problems

Difficult to quantify cost and benefit of development

with reuse

Some software engineers prefer to rewrite rather than

reuse components

Current techniques for component classification,

cataloging and retrieval are still not mature enough...
The cost of finding suitable components may be high

Concept reuse
When you reuse program or design components, you

have to follow the design decisions made by the

original developer of the component.
This may limit the opportunities for reuse.
However, a more abstract form of reuse is concept
reuse when a particular approach is described in an
implementation independent way and an
implementation is then developed.
The two main approaches to concept reuse are:
Design patterns;
Generative programming.

Introduction to Patterns
A pattern is the outline of a reusable solution to a

general problem encountered in a particular

context.
A pattern is a description of the problem and the
essence of its solution.
Many of them have been systematically
documented for all software developers to use.
Patterns often rely on object characteristics
such as inheritance and polymorphism.

Introduction to Patterns
History

the concept of a "pattern" was first expressed

in Christopher Alexander's work A Pattern

Language in 1977 (2543 patterns)
in 1990 a group of four people called the Gang
Of Four or "GoF" (Gamma, Helm, Johnson,
Vlissides) wrote the book of Design Patterns

Design patterns
A design pattern is a way of reusing abstract knowledge

about a problem and its solution.

Strategy for solving common object-oriented design
problems.
A good pattern should:
Be as general as possible
Contain a solution that has been proven to

effectively solve the problem in the indicated context.

Pattern elements
Name
A meaningful pattern identifier.
Problem description.
Solution description.
Not a concrete design but a template for a design solution that can be
instantiated in different ways.
Consequences
The results and trade-offs of applying the pattern.

Benefits of using patterns

Promoting communication
Pattern names and knowledge of advantages and
disadvantages speeds communication
Improving documentation and understandability
less documentation is needed
Patterns are described well once
Increasing efficiency
Tool support for patterns makes development faster
Supporting reuse
Patterns and their implementations can be reused extensively
Providing ideas
Patterns can be the starting point for design or a basis for
improvements

Gang of Four (GoF) patterns

Creational Patterns

(concerned with abstracting the object-instantiation process)

Factory Method
Builder

Structural Patterns

Abstract Factory
Prototype

Singleton

(concerned with how objects/classes can be combined to form larger structures)

Adapter
Decorator
Proxy

Bridge
Facade

Composite

Behavioral Patterns

(concerned with communication between objects)

Command
Mediator
Strategy
Template Method

Interpreter
Observer
Chain of Responsibility

Iterator
State
Visitor

Observer Pattern: Motivation

The
The Observer
Observer is
is an
an object
object that
that
watches
watches the
the state
state of
of another
another
object
object and
and takes
takes action
action when
when the
the
state
state changes
changes in
in some
some way.
way.
The
The Observable
Observable (subject)
(subject) is
is an
an
object
object that
that allows
allows observers
observers to
to
examine
examine itit (often
(often the
the observable
observable
object
object notifies
notifies the
the observers
observers when
when itit
changes)
changes)

Observer Design Pattern: Intent

The Observer pattern defines an one-to-many dependency

between an observable object and any number of observer

objects so that when the observable changes state, all its
observers are notified and updated automatically.
In order to reuse observable and observer independently,
their relationship has to be decoupled.
The Observer pattern is also known as Dependents and
Publish-Subscribe.

Observer Pattern: Applicability

Use the observer when:
The abstraction has two aspects with one dependent on the other.
Encapsulating these aspects in separate objects will increase the
chance to reuse them independently.
When the subject object doesn't know exactly how many observer
objects it has.
When the subject object should be able to notify it's observer objects
without knowing who these objects are.

Observer Pattern Example

In a spreadsheet program, the

Observer pattern can be applied as in

the following diagram.
Each rectangular box in the diagram
is an object. SpreadSheetFormula,
BarGraph, and PieChart are the
observer objects. SpreadsheetData
is the subject object (Observable).
The SpreadsheetData object notifies
its observers whenever a data
changes that could make it's state
inconsistent with the observers.

Observer Pattern Example

Subject

Spreadsheet Data

Send notify signal to observer

object whenever data changes

Observer

Spreadsheet Formula
Bar Graph
Pie Char

Request subject for change

information in order to update
itself accordingly

Real-World Example
GeneralBroadcast

Observerstuningintothenotification

Observer Pattern: Participants

Subject
Knows its observers provides interface for

attaching/detaching subjects
Observer
Defines an interface for notifying the subjects of changes

to the object (ex. Data)

ConcreteSubject
Sends notification to observers when state changes by

storing state to ConcreteObserver object

ConcreteObserver
Implements Observer interface to keep state consistent

with subject

Observer Pattern: UML

Benefits to Observer
Minimal coupling between the Subject and the Observer
Can reuse subjects without reusing their observers and vice versa
Observers can be added without modifying the subject
All subject knows its list of observers
Subject does not need to know the concrete class of an observer,
just that each observer implements the update interface
Subject and observer can belong to different abstraction layers
Support for event broadcasting
Subject sends notification to all subscribed observers
Observers can be added/removed at any time

The Faade Design Pattern

The faade hides the complexities of the system and

provides an interface to the client from where the client can

access the system.

The
The facade
facade pattern
pattern eases
eases
interaction
interaction between
between aa client
client and
and
aa sub-system
sub-system of
of suppliers
suppliers by
by
providing
providing aa simpler
simpler interface
interface to
to
the
the sub-system.
sub-system.
Analogy: a travel agent

Faade Pattern: Structure

Faade Pattern: Applicability

Use the Facade pattern when there is a need to provide a
simplified interface to a complex sub-system.
Facades can also help decouple systems.

If the faade mediates all interaction with a client, then the sub-system

can be changed without affecting the client.

A facade may work like an adapter by providing a new

interface to a sub-system.

Facade Pattern: Store Example

Lets consider a store. This store has a store keeper. In the

storage, there are a lot of things stored e.g. packing material,

raw material and finished goods.
You, as client want access to different goods. You do not
know where the different materials are stored. You just have
access to store keeper who knows his store well. Whatever
you want, you tell the store keeper and he takes it out of
store and hands it over to you on showing him the
credentials.

Facade Pattern: Check List

Identify a simpler, unified interface for the subsystem
or component.
2) Design a wrapper class that encapsulates
the subsystem.
3) The client uses (is coupled to) the Facade only.
4) Consider whether additional Facades would add value.
1)

Store Example Implementation

1) Identify a simpler, unified interface for the subsystem
or component.

The store can very well be an interface. This only returns

Goods. The goods are of three types as discussed earlier in

the specification. RawMaterialGoods, FinishedGoods and
PackagingMaterialsGoods. All these classes can implement
the Goods interface.

Store Example Implementation

Similarly, the stores are of three types and can implement

the Store interface. Lets have a look at the code for one of
the stores.

Store Example Implementation

2) Design a wrapper class that encapsulates the subsystem
(Faade StoreKeeper)

Store Example Implementation

3) The client uses (is coupled to) the Facade only.
The client program can now create an object of StoreKeeper
class and call method getGoods() passing as parameter the
type of goods required.

Adapter Design Pattern: Intent

Convert the interface of a class into another compatible

interface(clients expect). Adapter lets classes work together

that couldnt otherwise because of incompatible interfaces.
Wrap an existing class with a new interface.
It is also called Wrapper pattern or just Wrapper
Impedance match an old component to a new system

Adapter Design Pattern: Intent

The Adapter pattern is used so that two unrelated interfaces

can work together. Wrap an existing class with a

new interface.
The joining between them is called an Adapter.

Adapter Design Pattern: Applicability

Use adapters when:
You want to use an existing class (that meets your needs), but its

interface doesn't match what you need

You want to create a reusable class that can cooperate with unrelated
classes (some yet undeveloped)

Adapter Design Pattern Example

Assume that we have a 5 Amp plug and a 15 Amp socket in

which the 5 Amp plug cannot fit. We DO NOT have a 5 Amp

socket that it can work. The problem is how to cater to the
client without changing the plug or socket.
The Adapter Pattern can be implemented in two ways:
by Inheritance.
by Association.

Adapter Example: By Inheritance

Example of Adapter by Inheritance:

Adapter Example: By Inheritance

There is a class Plug which wants the input of 5 AMP. This is

the client.

Adapter Example: By Inheritance

Finally, there will be an adapter class. This will inherit the socket and

give output for Plug.

This class implements the getOutput() method of Socket

and sets it to fit the client output.

Adapter Example: By Association

Similarly, lets consider the Association of objects by

which Adapter can be implemented.

First, we create the class Socket that gives the 15 AMP
output.

Adapter Example: By Association

There is an interface Plug.java which has a method

getInput(). This is the client and we need to adapt the output

for this input which is 5 AMP.

Adapter Example: By Association

Plug5AMP is the implementation of Plug which requires 5

AMP of input.

Adapter Example: By Association

The Adapter here takes output from the Socket. If the

output is what is needed, it gives it to the Plug else, it

overrides the value and returns the adapter output.

Application system reuse

Involves the reuse of entire application

systems either by configuring a system for

an environment or by integrating two or
more systems to create a new application.
Two approaches covered here:
COTS product integration;
Product line development.

COTS product reuse

COTS - Commercial Off-The-Shelf systems.
COTS systems are usually complete application

systems that offer an API (Application

Programming Interface).
Building large systems by integrating COTS
systems is now a viable development strategy for
some types of system such as E-commerce
systems.
The key benefit is faster application development
and, usually, lower development costs.

COTS system integration problems

Lack of control over functionality and performance
COTS systems may be less effective than they appear

Problems with COTS system inter-operability

Different COTS systems may make different assumptions that

means integration is difficult

Support from COTS vendors
COTS vendors may not offer support over the lifetime of the

product

Software product lines (SPL)

Software product lines are applications with generic functionality

that can be adapted and configured for use in a specific context.

Set of software-intensive systems that share a common,
managed set of features satisfying the specific needs of a
particular market segment.
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.

Benefits of SPL
Improve productivity
Increase quality
Decrease cost
Decrease labor needs
Decrease time to market (to field, to launch)
Ability to move into new markets in months, not years

Key points
Advantages of reuse are lower costs, faster software

development and lower risks.

Design patterns are high-level abstractions that document
successful design solutions.
Program generators are also concerned with software reuse
- the reusable concepts are embedded in a generator
system.
Application frameworks are collections of concrete and
abstract objects that are designed for reuse through
specialisation.

Key points
COTS product reuse is concerned with the reuse of large,

off-the-shelf systems.
Problems with COTS reuse include lack of control over
functionality, performance, and evolution and problems with
inter-operation.
ERP systems are created by configuring a generic system
with information about a customers business.
Software product lines are related applications developed
around a common core of shared functionality.