Software Reuse

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 2

 Topics covered

l The reuse landscape

l Design patterns
l Generator based reuse
l Application frameworks
l Application system reuse

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 3

 Software reuse

l In most engineering disciplines, systems are

designed by composing existing components
that have been used in other systems.
l 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.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 4

Reuse-based software engineering
l Application system reuse
• The whole of an application system may be reused
either by incorporating it without change into other
systems (COTS reuse) or by developing application
families.
l Component reuse
• Components of an application from sub-systems to
single objects may be reused. Covered in Chapter 19.
l Object and function reuse
• Software components that implement a single well-
defined object or function may be reused.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 5

 Reuse benefits 1

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 6

 Reuse benefits 2

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 7

 Reuse problems 1

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 8

 Reuse problems 2

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 9

 The reuse landscape

l Although reuse is often simply thought of as

the reuse of system components, there are
many different approaches to reuse that may
be used.
l Reuse is possible at a range of levels from
simple functions to complete application
systems.
l The reuse landscape covers the range of
possible reuse techniques.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 10

 The reuse landscape

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 11

 Reuse approaches 1

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 12

 Reuse approaches 2

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 13

 Reuse planning factors

l The development schedule for the software.

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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 14

 Concept reuse
l When you reuse program or design components,
you have to follow the design decisions made by
the original developer of the component.
l This may limit the opportunities for reuse.
l 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.
l The two main approaches to concept reuse are:
• Design patterns;
• Generative programming.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 15

 Design patterns

l A design pattern is a way of reusing abstract

knowledge about a problem and its solution.
l A pattern is a description of the problem and
the essence of its solution.
l It should be sufficiently abstract to be reused
in different settings.
l Patterns often rely on object characteristics
such as inheritance and polymorphism.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 16

 Pattern elements

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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 17

 Multiple displays

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 18

 The Observer pattern
l Name
• Observer.
l Description
• Separates the display of object state from the object itself.
l Problem description
• Used when multiple displays of state are needed.
l Solution description
• See slide with UML description.
l Consequences
• Optimisations to enhance display performance are
impractical.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 19

 The Observer pattern

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 20

 Generator-based reuse
l Program generators involve the reuse of
standard patterns and algorithms.
l These are embedded in the generator and
parameterised by user commands. A program
is then automatically generated.
l Generator-based reuse is possible when
domain abstractions and their mapping to
executable code can be identified.
l A domain specific language is used to
compose and control these abstractions.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 21

 Types of program generator
l Types of program generator
• Application generators for business data processing;
• Parser and lexical analyser generators for language
processing;
• Code generators in CASE tools.
l Generator-based reuse is very cost-effective but its
applicability is limited to a relatively small number of
application domains.
l It is easier for end-users to develop programs using
generators compared to other component-based
approaches to reuse.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 22

 Reuse through program generation

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 23

 Aspect-oriented development
l Aspect-oriented development addresses a major
software engineering problem - the separation of
concerns.
l 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.
l Cross-cutting concerns are implemented as aspects
and are dynamically woven into a program. The
concern code is reuse and the new system is
generated by the aspect weaver.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 24

 Aspect-oriented development

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 25

 Application frameworks

l Frameworks are a sub-system design made

up of a collection of abstract and concrete
classes and the interfaces between them.
l The sub-system is implemented by adding
components to fill in parts of the design and by
instantiating the abstract classes in the
framework.
l Frameworks are moderately large entities that
can be reused.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 26

 Framework classes
l System infrastructure frameworks
• Support the development of system infrastructures
such as communications, user interfaces and
compilers.
l Middleware integration frameworks
• Standards and classes that support component
communication and information exchange.
l Enterprise application frameworks
• Support the development of specific types of
application such as telecommunications or
financial systems.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 27

 Extending frameworks
l Frameworks are generic and are extended to create a
more specific application or sub-system.
l Extending the framework involves
• Adding concrete classes that inherit operations from
abstract classes in the framework;
• Adding methods that are called in response to events
that are recognised by the framework.
l Problem with frameworks is their complexity which
means that it takes a long time to use them effectively.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 28

 Model-view controller

l System infrastructure framework for GUI

design.
l Allows for multiple presentations of an object
and separate interactions with these
presentations.
l MVC framework involves the instantiation of a
number of patterns (as discussed earlier under
concept reuse).

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 29

 Model-view-controller

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 30

 Application system reuse

l 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.
l Two approaches covered here:
• COTS product integration;
• Product line development.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 31

 COTS product reuse
l COTS - Commercial Off-The-Shelf systems.
l COTS systems are usually complete
application systems that offer an API
(Application Programming Interface).
l Building large systems by integrating COTS
systems is now a viable development
strategy for some types of system such as E-
commerce systems.
l The key benefit is faster application
development and, usually, lower
development costs.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 32
 COTS design choices
l Which COTS products offer the most appropriate
functionality?
• There may be several similar products that may be
used.
l How will data be exchanged?
• Individual products use their own data structures and
formats.
l 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.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 33

 E-procurement system

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 34

 COTS products reused

l On the client, standard e-mail and web

browsing programs are used.
l 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.
• 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.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 35

COTS system integration problems
l Lack of control over functionality and performance
• COTS systems may be less effective than they appear
l Problems with COTS system inter-operability
• Different COTS systems may make different
assumptions that means integration is difficult
l No control over system evolution
• COTS vendors not system users control evolution
l Support from COTS vendors
• COTS vendors may not offer support over the lifetime
of the product

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 36

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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 37

 COTS product specialisation
l Platform specialisation
• Different versions of the application are developed for
different platforms.
l Environment specialisation
• Different versions of the application are created to
handle different operating environments e.g. different
types of communication equipment.
l Functional specialisation
• Different versions of the application are created for
customers with different requirements.
l Process specialisation
• Different versions of the application are created to
support different business processes.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 38

 COTS configuration

l 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.
l Design time configuration
• A common generic code is adapted and changed
according to the requirements of particular
customers.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 39

 ERP system organisation

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 40

 ERP systems
l An Enterprise Resource Planning (ERP)
system is a generic system that supports
common business processes such as ordering
and invoicing, manufacturing, etc.
l These are very widely used in large
companies - they represent probably the most
common form of software reuse.
l The generic core is adapted by including
modules and by incorporating knowledge of
business processes and rules.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 41

 Design time configuration

l Software product lines that are configured at

design time are instantiations of generic
application architectures as discussed in
Chapter 13.
l Generic products usually emerge after
experience with specific products.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 42

 Product line architectures

l Architectures must be structured in such a way

to separate different sub-systems and to allow
them to be modified.
l The architecture should also separate entities
and their descriptions and the higher levels in
the system access entities through
descriptions rather than directly.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 43

 A resource management system

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 44

 Vehicle despatching
l A specialised resource management system where the aim
is to allocate resources (vehicles) to handle incidents.
l 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.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 45

 A despatching system

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 46

 Product instance development

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 47

 Product instance development
l Elicit stakeholder requirements
• Use existing family member as a prototype
l Choose closest-fit family member
• Find the family member that best meets the
requirements
l Re-negotiate requirements
• Adapt requirements as necessary to capabilities of the
software
l Adapt existing system
• Develop new modules and make changes for family
member
l Deliver new family member
• Document key features for further member
development
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 48
 Key points
l Advantages of reuse are lower costs, faster software
development and lower risks.
l Design patterns are high-level abstractions that
document successful design solutions.
l Program generators are also concerned with software
reuse - the reusable concepts are embedded in a
generator system.
l Application frameworks are collections of concrete and
abstract objects that are designed for reuse through
specialisation.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 49

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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 50