$18 Software Reuse

Chapter 18
Software Reuse
Ian Sommerville
Lutz Prechelt
© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 1

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

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

Software reuse
z In most engineering disciplines, systems are
designed by composing existing components that
have been used in other systems.
z Software engineering has long been more focused

on original development
but it is now recognised that to reduce cost and to
improve quality and time-to-market, we need to adopt a
design process that is based on systematic reuse.

Reuse-based software engineering
z 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.
z Component reuse
Components of an application from sub-systems to single
objects may be reused. Covered in Chapter 19.
z Object and function reuse

Software components that implement a single well-
defined object or function may be reused.

Reuse benefits (1)
z Increased dependability
Previously used SW tends to have fewer defects.
z Reduced process risk

Building a component can fail more easily than reusing an
existing one.
Particularly true for large, complex components (sub-
systems).
• Sometimes not true, if the adaptability of the reusable
component is unclear.
z Effective use of specialists

Rare knowledge is encapsulated in a component and is
then more readily and widely available.
Reuse benefits (2)
z Standards compliance
Reusing components can promote the adherence to
standards (e.g. user interface look-and-feel).
This improves usability of a component (for programmers
and/or for end-users).
z Accelerated development
Often more important than anything else.

Reuse problems (1)
z Increased maintenance cost
External changes to a reused (COTS) component may
force changes to the reusing software.
Required changes to a reused component may be more
difficult to have than for a custom component.
z Lack of tool support
There is little support for maintaining a catalog of
reusable components and for finding components.
Development tools do not support development with all
kinds of reusable components well.
z Not-invented-here syndrome
Many software engineers tend to prefer rewriting a
component over reusing it.

Reuse problems (2)
z The reuse barrier:
1. A software developer will only search for a reusable
component if s/he expects to find an appropriate one.
2. S/he will only find it if it is described in a way s/he can
recognize as providing a solution.
3. S/he will only use it if s/he can understand it.
4. Use will only be successful if the component can be
adapted to the problem at hand.
The whole process will start only if the developer
expects all steps to be successful in the beginning.
z Reuse works well for many general-purpose

components, but is difficult for highly domain-
specific ones.
The reuse landscape
z Although reuse is often simply thought of as the
reuse of system components, there are many
different approaches to reuse that may be used.
z Reuse is possible
at a range of granularity levels
• from simple functions to complete application systems
at a range of abstraction levels
• from requirements to code etc.
at a range of scales
• from one-time-reuse to mass-marketing
z The reuse landscape covers the range of possible
reuse techniques.
The reuse landscape
Design
patterns
Component Application
frameworks product lines Aspect-oriented
software development
Component-based COTS Program

development integration generators
Legacy system
wrapping
Configurable vertical
applications
Service-oriented
systems
Program
libraries

Reuse approaches (1)
Design patterns Generic abstractions that occur across applications
are represented as design patterns that show
abstract and concrete objects and interactions.
Component- Systems are developed by integrating components
based (collections of objects) that conform to component-
development model standards. This is covered in Chapter 19.
Application Collections of abstract and concrete classes that
frameworks can be adapted and extended to create application
systems.
Legacy system Legacy systems (see Chapter 2) that can be
wrapping 'wrapped' by defining a set of interfaces and
providing access to these legacy systems through
these interfaces.
Service-oriented Systems are developed by linking shared services
systems that may be externally provided.

Reuse approaches (2)
Application An application type is generalised around a common
product lines architecture so that it can be adapted in different
ways for different customers.
COTS integration Systems are developed by integrating existing
application systems.
Configurable A generic system is designed so that it can be
vertical configured to the needs of specific system
applications customers.
Program libraries Class and function libraries implementing commonly-
used abstractions are available for reuse.
Program A generator system embeds knowledge of a
generators particular types of application and can generate
systems or system fragments in that domain.
Aspect-oriented Shared components are woven into an application at
software different places when the program is compiled.
development

Reuse planning factors
z The development schedule for the software.
z The expected software lifetime.
z The background, skills and experience of the
development team.
z The criticality of the software and its non-
functional requirements.
z The application domain.
z The execution platform for the software.

Concept reuse
z 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.
z However, a more abstract form of reuse is concept

reuse:
A particular approach is described in an implementation-
independent way.
At reuse time, an implementation is then developed.
z The two main approaches to concept reuse are:

Design patterns;
Generative programming.
Design patterns
z A design pattern is a way of reusing abstract
knowledge about a problem and its solution.
z A pattern is a description of the problem and the

essence of its solution.
z It should be sufficiently abstract to be reused in

different settings.
z Many patterns aim at flexibility and rely on object

characteristics such as inheritance and
polymorphism.

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

Multiple displays
50
D
A
C 25
A B C D
B 0
Subject
Observer 1 A: 40 Observer 2
B: 25
C: 15
D: 20

The Observer pattern
z Name
Observer.
z Description
Separates the display of object state from the object
itself.
z Problem description
Used when multiple displays of state are needed and must
be added and removed at run-time.
z Solution description
See slide with UML description.
z Consequences
Optimisations to enhance display performance must be
designed for all observers in advance.

The Observer pattern
Subject Observer
Attach (Observer) Update ()

Detach (Observer)
Notify () for all o in observers
o -> Update ()
ConcreteSubject ConcreteObserver
observerState =
GetState () return subjectState Update ()
subject ->
GetState ()
subjectState observerState

Generator-based reuse
z Program generators involve the reuse of
standard patterns and algorithms.
These are embedded in the generator and
parameterised by user commands.
z Generator-based reuse is possible when domain

abstractions and their mapping to executable code
can be identified.
A domain-specific language is used to compose and
control these abstractions.

Types of program generator
z Types of program generator
Application generators for business data processing;
Parser and lexical analyser generators for language
processing (e.g. compilers);
Code generators in CASE tools.
z Generator-based reuse is very cost-effective but

its applicability is limited to some application
domains.
z It is easier for end-users to develop programs

using generators compared to other component-
based approaches to reuse.
Aspect-oriented development
z Aspect-oriented development (AOD) addresses a
major software engineering problem:
the separation of concerns.
z Concerns are often not simply associated with
application functionality but are cross-cutting.
E.g. all components may monitor their own operation,
all components may have to maintain security, etc.
z In AOD, cross-cutting concerns are implemented
separately (as 'aspects') and are dynamically
woven into a program.
The concern code is reused and the new system is
generated by the aspect weaver.
Requires extensions to existing programming languages.

Aspect-oriented development
Aspect 1 Aspect 2
Input source code Generated code

Aspect <statements 1>
<statements 1> Weaver
join point 1 Aspect 1
<statements 2> <statements 2>
join point 2 Aspect 2
<statements 3> <statements 3>
Any join point may be filled by more than one aspect

Application frameworks
z A framework is a conceptually complete design
plus an incomplete implementation.
Typically object-oriented: a collection of abstract and
concrete classes and the interfaces between them.
Describes a sub-system or complete system.
z Implementation is completed by adding
components to fill in the missing parts.
z Miniature example:
java.util.collections.Collection: static void sort(List list)
Requires that all elements of the list implement interface
Comparable:
int compareTo(Object o)
Reusable 'sort' will call user-defined function 'compareTo'.

Types of framework
z System infrastructure frameworks
Support the development of system infrastructures such
as communications, user interfaces and compilers.
z Middleware integration frameworks
Standards and classes that support resource management
and component communication.
z Enterprise application frameworks
Support the development of specific types of application
such as telecommunications or financial systems.
z A problem with frameworks is their complexity.

It takes long to learn using them effectively.

Model-View-Controller (MVC)
z System infrastructure framework for GUI design.
z Allows for multiple presentations of an object and

separate interactions with each.
z Using an MVC framework involves the instantiation

of a number of design patterns.
E.g. Observer pattern, Strategy pattern, maybe
Composite pattern.
Parts of the implementations of these patterns have to be
provided by the framework user.

Model-View-Controller
User Controller state view modification View state

inputs messages
Controller methods View methods
Model queries
Model edits and updates
Model state
Model methods

Application system reuse
z 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.
z Two approaches covered here:

COTS product integration;
Product line development.

COTS product reuse
COTS = Commercial Off-The-Shelf software.
z COTS systems are usually complete application
systems that offer an API (Application
Programming Interface).
z Building large systems by integrating COTS
systems is now a viable development strategy for
some types of system
such as E-commerce systems.
z The key benefit is faster application development
and, usually, lower development costs.

COTS design choices
z Which COTS products offer the most appropriate
functionality?
There may be several similar products that may be used.
z Can I later switch my system over to a different
COTS product if I have to?
If the COTS is decomissioned or does not support future
requirements.
z How will data be exchanged?
Individual products use their own data structures and
formats.
z What features of the product will actually be used?
Most products have more functionality than is needed.
You should try to deny access to unused functionality.

E-procurement system
Client
Web browser E-mail system
Server
E-commerce Ordering and

Adaptor
system invoicing system
E-mail system Adaptor

COTS products reused
z On the client, standard e-mail and web browsing
programs are used.
z On the server, an e-commerce platform has to be

integrated with an existing ordering system.
This involves writing an adaptor so that they can
exchange data.
z An e-mail system is also integrated to generate e-

mail for clients.
This also requires an adaptor to receive data from the
ordering and invoicing system.

COTS system integration problems
z Lack of control over functionality and performance
COTS systems may be less effective than they appear.
z Problems with COTS system inter-operability
Different COTS systems may make conflicting
assumptions so that integration can be difficult.
z No control over system evolution
COTS vendors, not system users control evolution.
z Finite support from COTS vendors
COTS vendors may not offer support over the lifetime of
the product.

Software product lines
z Software product lines or application families are
applications with generic functionality that can be
adapted and configured for use in a specific
context.
z 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.

COTS product specialisation
z Platform specialisation
Different versions of the application are developed for
different platforms.
z Environment specialisation
Different versions of the application are created to handle
different operating environments e.g. different types of
communication equipment.
z Functional specialisation
Different versions of the application are created for
customers with different requirements.
Or for different marketing needs (e.g. "light" versions).
z Process specialisation
Different versions of the application are created to
support different business processes.
COTS configuration
z Deployment-time configuration
A generic system is configured by embedding knowledge
of the customer’s requirements and business processes.
The software itself is not changed.
z Design-time configuration
A common generic code is adapted and changed
according to the requirements of particular customers.
Creates a specific version of the software.

Deployment-time configuration:
ERP systems
z An Enterprise Resource Planning (ERP) system is a
generic system that supports common business
processes
such as ordering and invoicing, production planning, etc.
z These are very widely used in large companies

and represent probably the most common form of huge-
scale software reuse.
z The generic core is adapted at deployment time

by including modules and
by incorporating knowledge of specific business processes
and rules.

ERP system organisation
Configuration
planning tool
Generic ERP system

Configuration
database
System database

Design time configuration: Product lines
z Software product lines that are configured at
design time are instantiations of generic
application architectures
as discussed in Chapter 13.
Generic products usually emerge after experience with
specific products.
z Architectures must be structured in such a way to
separate different sub-systems and to allow them
to be modified
e.g. by separating entities strongly in the architecture:
The higher levels in the system access entities through
descriptions rather than directly.

Generic resource management system
User inter face
User Resource Query

authentication delivery management
Resource Resource policy Resource

management control allocation
Transaction management
Resource database

Vehicle despatching
z A specialised resource management system where
the aim is to allocate resources (vehicles) to
handle incidents.
z Adaptations include:
At the UI level, there are components for operator display
and communications;
At the I/O management level, there are components that
handle authentication, reporting and route planning;
At the resource management level, there are components
for vehicle location and despatch, managing vehicle status
and incident logging;
The database includes equipment, vehicle and map
databases.
A vehicle despatching system
User interface Comms system

inter face
Operator Map and route Report Query

authentication planner generator manager
Vehicle status Incident Vehicle Equipment Vehicle

manager logger despatcher manager locator
Transaction management Incident log

Equipment
database Vehicle database Map database

Product instance development
Renegotiate
requirements
Elicit Choose
stakeholder closest-fit
requirements family member
Adapt existing Deliver new
system family member

Product instance development
z Elicit stakeholder requirements
Use existing family member as a prototype.
z Choose closest-fit family member
Find the family member that best meets the requirements.
z Re-negotiate requirements
Adapt requirements as necessary to capabilities of the
software.
z Adapt existing system
Develop new modules and make changes for family
member.
z Deliver new family member
Document key features for further member development.

Key points
z Advantages of reuse are lower costs, faster
software development and lower risks.
Successful reuse requires overcoming a number of
barriers: Creation/availability, discovery, understanding,
fitness, trust, adaptation, evolution.
z Design patterns are high-level abstractions that
describe and discuss problem/solution pairs.
z Reusable concepts may be embedded in a
program generator system.
z Application frameworks are collections of
concrete and abstract objects
that are designed for reuse through specialisation.

Key points (2)
z 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.
z ERP systems are created by configuring a generic
system with information about a customer’s
business.
z Software product lines are related applications
developed around a common core of shared
functionality.

$18 Software Reuse

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

$18 Software Reuse

Uploaded by

Copyright:

Available Formats

Chapter 18

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 1

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 2

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 3

z Software engineering has long been more focused

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 4

z Object and function reuse

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 5

z Reduced process risk

z Effective use of specialists

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 7

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 8

z Reuse works well for many general-purpose

Component-based COTS Program

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 11

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 12

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 13

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 14

z However, a more abstract form of reuse is concept

z The two main approaches to concept reuse are:

z A pattern is a description of the problem and the

z It should be sufficiently abstract to be reused in

z Many patterns aim at flexibility and rely on object

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 16

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 17

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 18

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 19

Attach (Observer) Update ()

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 20

z Generator-based reuse is possible when domain

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 21

z Generator-based reuse is very cost-effective but

z It is easier for end-users to develop programs

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 23

Input source code Generated code

Any join point may be filled by more than one aspect

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 24

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 25

z A problem with frameworks is their complexity.

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 26

z Allows for multiple presentations of an object and

z Using an MVC framework involves the instantiation

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 27

User Controller state view modification View state

Controller methods View methods

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 28

z Two approaches covered here:

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 29

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 30

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 31

Web browser E-mail system

E-commerce Ordering and

E-mail system Adaptor

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 32

z On the server, an e-commerce platform has to be

z An e-mail system is also integrated to generate e-

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 33

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 34

z Adaptation may involve:

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 35

© Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 37

z These are very widely used in large companies