o n

c ti
tr u
n s
C o
r e
S E tf w
a
E U So
R 4 1 1
S E

1
OVERVIEW
Introduction to Software Reuse
Reusable Software Units
The Reuse Landscape
Reuse Dimensions
Benefits of Reuse
Problems with Reuse
DfR vs. DwR
Reuse Techniques

2
SOFTWARE REUSE
In most engineering disciplines, systems are designed by composing existing
components that have been used in other systems.

Software engineering has been more focused on original development but it is

now recognized 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.

3
SOFTWARE REUSE
Software reuse is the process of implementing or updating software systems using existing
software components.
Reuse: using components of one product to facilitate the development of a different
product with a different functionality.
A reusable component need not necessarily be a module or a code fragment. It can be:
 a design
 a database
 a set of test data & procedures
 a part of a manual
 a duration & cost estimate

4
REUSABLE SOFTWARE UNITS

5
REUSABLE SOFTWARE UNITS
Function Reuse (from subroutine libraries)
Class Reuse (from class libraries)
API – Application Programming Interface
Component Reuse
Application Framework Reuse
Application System Reuse

6
THE REUSE LANDSCAPE – 1/3

7
THE REUSE LANDSCAPE – 2/3
Design patterns
 Generic abstractions that occur across applications are represented as design patterns showing
abstract and concrete objects and interactions.
Component-based development
 Systems are developed by integrating components (collections of objects) that conform to
component-model standards.
Application frameworks
 Collections of abstract and concrete classes can be adapted and extended to create application
systems.
Legacy system wrapping
 Legacy systems can be ‘wrapped’ by defining a set of interfaces and providing access to these
legacy systems through these interfaces.
Service-oriented systems
 Systems are developed by linking shared services, which may be externally provided.

8
THE REUSE LANDSCAPE – 3/3
Application product lines
 An application type is generalized around a common architecture so that it can be adapted for
different customers.
COTS integration
 Systems are developed by integrating existing application systems.
Configurable vertical applications
 A generic system is designed so that it can be configured to the needs of specific system
customers.
Program libraries
 Class and function libraries implementing commonly used abstractions are available for reuse.
Program generators
 A generator system embeds knowledge of a particular type of application and can generate
systems or system fragments in that domain.

9
REUSE DIMENSIONS
Things being reused: components, concepts, …
Scope: horizontal vs vertical
Approach: systematic or opportunistic
Technique: compositional or generative
Use: black-box or white-box
Product being reused: source code, design, …

10
HORIZONTAL VS. VERTICAL REUSE
Horizontal reuse
• Reuse across a broad range of application areas
• Data structures, sorting algorithms, user interface mechanisms

Vertical Reuse
• Components within a given application area that can be reused in similar
applications within the same problem domain
OPPORTUNISTIC VS. SYSTEMATIC REUSE
Opportunistic Reuse
 a.k.a. Accidental Reuse
 Developers of a new product realize that a component of a previously
developed product can be reused in the new product.
Systematic Reuse
 a.k.a. Deliberate Reuse
 Utilization of software components constructed specifically for possible
future reuse.
 Easier & safer to reuse.

12
BENEFITS OF SOFTWARE REUSE
Increased dependability
Reduced process risk
Effective use of specialists
Standards compliance
Accelerated development
Higher quality products
Less development time
Higher scheduling accuracy
Reliability

13
SOFTWARE DEVELOPMENT FOR/WITH REUSE
Often two separate development processes:

Develop for reuse (DfR)

 Identify units of reusable knowledge
 Store the reusable knowledge into a “knowledge base”

Develop with reuse (DwR)

 Search the reusable knowledge
 Modify the reusable knowledge to fit new situations
 Combine the reusable knowledge with your project

14
SOFTWARE DEVELOPMENT FOR/WITH REUSE
Develop for reuse
 Active
 Reusable assets are developed, rather than found by accident

Develop with reuse

 Passive
 Component library evolves randomly

15
FIVE STEPS OF DEVELOPMENT FOR/WITH REUSE
Develop for reuse
 Abstraction: Identify units of reusable knowledge and concisely represent them in abstract
form
 Classification: Store the reusable knowledge into a “knowledge base” that is indexed and
classified
Develop with reuse
 Selection: Query the reusable knowledge into parameterized form (e.g. function with formal
parameters)
 Specialization: Modify the reusable knowledge to fit new situations (e.g. function with
actual parameters)
 Integration: Combine the reusable knowledge with your project (e.g. invocation, weaving,
etc.)

16
SOFTWARE DEVELOPMENT FOR REUSE

17
SOFTWARE DEVELOPMENT WITH REUSE

18
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

19
CHARACTERISTICS OF SUCCESSFUL REUSE PROGRAMS
Extensive management support
Organizational support structure
Incremental implementation
Significant success
High incentives
Domain analysis done
Attention to architectural issues

20
NON-TECHNICAL ASPECTS OF SOFTWARE REUSE
Economics: it is a long term investment
Management: it does not happen spontaneously
Psychology: people do not want to reuse someone else’s code

21
REUSE DEVIL’S LOOP

22
PROBLEMS WITH REUSE
Increased maintenance costs
Lack of tool support
Not-invented-here (NIH) syndrome
Creating and maintaining a component library
Finding, understanding and adapting reusable components
Legal issues

23
REUSE TECHNIQUES

24
SOFTWARE PRODUCT LINES
Software product lines or application families are applications with generic
functionality that can be adapted and configured for use in a specific context.
A software product line is a set of applications with a common architecture and
shared components, with each application specialized to reflect different
requirements.
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.

25
BASE SYSTEMS FOR A SOFTWARE PRODUCT LINE

26
COMPONENT-BASED SOFTWARE ENGINEERING
CBSE is an approach to software development that relies on reuse
CBSE emerged from the failure of object-oriented development to support
reuse effectively
Objects (classes) are too specific and too detailed to support design for
reuse work
Components are more abstract than classes and can be considered to be
stand-alone service providers

27
ENGINEERING OF COMPONENT-BASED SYSTEMS - PART 1
Software team elicits system requirements
Architectural design is established
Team determines requirements are amenable to composition rather than construction
 Are commercial off-the-shelf (COTS) components available to implement the requirement?
 Are internally developed reusable components available to implement the requirement?
 Are the interfaces for available components compatible with the proposed system
architecture?
Team attempts to remove or modify requirements that cannot be implemented with COTS
or in-house components

28
ENGINEERING OF COMPONENT-BASED SYSTEMS - PART 2
For those requirements that can be addressed with available components
the following activities take place:
 component qualification
 component adaptation
 component composition
 component update
Detailed design activities commence for remainder of the system

29
DEFINITION OF TERMS
Component Qualification
 candidate components are identified based on services provided and means by which
consumers access them
Component Adaptation
 candidate components are modified to meet the needs of the architecture or discarded
Component Composition
 architecture dictates the composition of the end product from the nature of the connections
and coordination mechanisms
Component Update
 updating systems that include COTS is made more complicated by the fact that a COTS
developer must be involved

30
COTS PRODUCT REUSE
A commercial-off-the-shelf (COTS) product
 a software that can be adapted for different customers without changing the
source code of the system.
COTS products have generic features
 can be used/reused in different environments.
COTS products are adapted by using built-in configuration mechanisms
 allow the functionality of the system to be tailored to specific customer needs.
 For example, in a hospital patient record system, separate input forms and
output reports might be defined for different types of patient.

31
BENEFITS OF COTS REUSE
As with other types of reuse, more rapid deployment of a reliable system may be
possible.
It is possible to see what functionality is provided by the applications and so it is
easier to judge whether or not they are likely to be suitable.
Some development risks are avoided by using existing software. However, this
approach has its own risks.
Businesses can focus on their core activity without having to devote a lot of
resources to IT systems development.
As operating platforms evolve, technology updates may be simplified as these are
the responsibility of the COTS product vendor rather than the customer.

32
PROBLEMS OF COTS REUSE
Requirements usually have to be adapted to reflect the functionality and mode
of operation of the COTS product.
The COTS product may be based on assumptions that are practically impossible
to change.
Choosing the right COTS system for an enterprise can be a difficult process,
especially as many COTS products are not well documented.
There may be a lack of local expertise to support systems development.
The COTS product vendor controls system support and evolution.

33
COTS SOLUTION SYSTEMS
COTS-solution systems are generic application systems that may be
designed to support a particular business type, business activity or,
sometimes, a complete business enterprise.
 For example, a COTS-solution system may be produced for dentists that
handles appointments, dental records, patient recall, etc.

Domain-specific COTS-solution systems, such as systems to support a

business function (e.g. document management) provide functionality that
is likely to be required by a range of potential users.

34
ERP SYSTEMS
An Enterprise Resource Planning (ERP) system is a generic system that
supports common business processes such as ordering and invoicing,
manufacturing, etc.

These are very widely used in large companies - they represent probably
the most common form of software reuse.

The generic core is adapted by including modules and by incorporating

knowledge of business processes and rules.

35
THE ARCHITECTURE OF AN ERP SYSTEM

36
ERP ARCHITECTURE
A number of modules to support different business functions.
A defined set of business processes, associated with each module, which
relate to activities in that module.
A common database that maintains information about all related business
functions.
A set of business rules that apply to all data in the database.

37
ERP CONFIGURATION
Selecting the required functionality from the system.
Establishing a data model that defines how the organization’s data will be structured in
the system database.
Defining business rules that apply to that data.
Defining the expected interactions with external systems.
Designing the input forms and the output reports generated by the system.
Designing new business processes that conform to the underlying process model supported
by the system.
Setting parameters that define how the system is deployed on its underlying platform.

38
POPULAR ERP VENDORS

Reference:
Chapter 15: Software Reuse
From Software Engineering by Ian Sommerville (Tenth Edition)
39