~$18 software reuse

8/9/2019 ~$18 Software Reuse

1/47

Ian Sommerville 2004, Software Engineering, 7th edition, [email protected] 1

Chapter 18

Software Reuse

Ian Sommerville

Lutz Prechelt


2/47


Objectives

To explain the benefits of software reuse andsome reuse problems

To discuss several different ways to implementsoftware reuse

To explain how reusable concepts can berepresented as patterns or embedded in programgenerators

To discuss COTS reuse

To describe the development of software productlines


3/47


4/47


Software reuse

In most engineering disciplines, systems aredesigned by composing existing components thathave been used in other systems.

Software engineering has long been more focusedon original development

but it is now recognised that to reduce cost and toimprove quality and time-to-market, we need to adopt adesign process that is based on systematic reuse.


5/47


Reuse-based software engineering

Application system reuse

The whole of an application system may be reused eitherby incorporating it without change into other systems or

by developing application families.

Component reuse

Components of an application from sub-systems to singleobjects may be reused. Covered in Chapter 19.

Object and function reuse Software components that implement a single well-

defined object or function may be reused.


6/47 Ian Sommerville 2004, Software Engineering, 7th edition, [email protected] 6

Reuse benefits (1)

Increased dependability

Previously used SW tends to have fewer defects.

Reduced process risk

Building a component can fail more easily than reusing anexisting one.

Particularly true for large, complex components (sub-systems).

Sometimes not true, if the adaptability of the reusablecomponent is unclear.

Effective use of specialists

Rare knowledge is encapsulated in a component and isthen more readily and widely available.



Reuse benefits (2)

Standards compliance

Reusing components can promote the adherence tostandards (e.g. user interface look-and-feel).

This improves usability of a component (for programmersand/or for end-users).

Accelerated development Often more important than anything else.



Reuse problems (1)

Increased maintenance cost

External changes to a reused (COTS) component mayforce changes to the reusing software.

Required changes to a reused component may be moredifficult to have than for a custom component.

Lack of tool support

There is little support for maintaining a catalog ofreusable components and for finding components.

Development tools do not support development with allkinds of reusable components well.

Not-invented-here syndrome

Many software engineers tend to prefer rewriting acomponent over reusing it.



Reuse problems (2)

The reuse barrier:

1. A software developer will only search for a reusablecomponent 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 canrecognize 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 beadapted to the problem at hand.

The whole process will start only if the developerexpects all steps to be successful in the beginning.

Reuse works well for many general-purposecomponents, but is difficult for highly domain-

specific ones.



The reuse landscape

Although reuse is often simply thought of as thereuse of system components, there are manydifferent approaches to reuse that may be used.

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

The reuse landscape covers the range of possible

reuse techniques.


11/47


The reuse landscape

Designpatterns

Component-baseddevelopment

Componentframeworks

Service-orientedsystems

COTSintegration

Applicationproduct lines

Legacy systemwrapping

Program

libraries

Programgenerators

Aspect-orientedsoftware development

Configurable verticalapplications


12/47


Reuse approaches (1)

Design patterns Generic abstractions that occur across applicationsare represented as design patterns that showabstract and concrete objects and interactions.

Component-based

development

Systems are developed by integrating components(collections of objects) that conform to component-

model standards. This is covered in Chapter 19.

Application

frameworks

Collections of abstract and concrete classes that

can be adapted and extended to create applicationsystems.

Legacy systemwrapping

Legacy systems (see Chapter 2) that can be'wrapped' by defining a set of interfaces and

providing access to these legacy systems throughthese interfaces.

Service-oriented

systems

Systems are developed by linking shared services

that may be externally provided.


13/47


Reuse approaches (2)

Application

product lines

An application type is generalised around a common

architecture so that it can be adapted in differentways for different customers.

COTS integration Systems are developed by integrating existingapplication 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 types of application and can generatesystems or system fragments in that domain.

Aspect-orientedsoftware

development

Shared components are woven into an application atdifferent places when the program is compiled.


14/47


Reuse planning factors

The development schedule for the software.

The expected software lifetime.

The background, skills and experience of thedevelopment team.

The criticality of the software and its non-

functional requirements. The application domain.

The execution platform for the software.


15/47


Concept reuse

When you reuse program or design components,you have to follow the design decisions made bythe original developer of the component.

This may limit the opportunities for reuse.

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.

The two main approaches to concept reuse are:

Design patterns;

Generative programming.


16/47


Design patterns

A design pattern is a way of reusing abstractknowledge about a problem and its solution.

A pattern is a description of the problem and theessence of its solution.

It should be sufficiently abstract to be reused indifferent settings.

Many patterns aim at flexibility and rely on objectcharacteristics such as inheritance and

polymorphism.


17/47


Pattern elements

Name

A meaningful pattern identifier.

Problem description

Context, requirements, constraints

Solution description

Not a concrete design but a template for a design solutionthat can be instantiated in different ways.

Consequences

The results, variants and trade-offs when applying the

pattern.


18/47


Multiple displays

A: 40B: 25C: 15D: 20

Observer 1

A

B

C

D

Observer 2

Subject

0

50

25

A B C D


19/47


The Observer pattern

Name

Observer.

Description

Separates the display of object state from the objectitself.

Problem description

Used when multiple displays of state are needed and mustbe added and removed at run-time.

Solution description

See slide with UML description.

Consequences

Optimisations to enhance display performance must be

designed for all observers in advance.


20/47


The Observer pattern

Subject Observer

Attach (Observer)

Detach (Observer)

Notify ()

Update ()

ConcreteSubject

GetState ()

subjectState

ConcreteObserver

Update ()

observerState

observerState =subject ->

GetState ()

return subjectState

for all o in observerso -> Update ()


21/47


Generator-based reuse

Program generators involve the reuse ofstandard patterns and algorithms.

These are embedded in the generator and

parameterised by user commands.

Generator-based reuse is possible when domain

abstractions and their mapping to executable codecan be identified.

A domain-specific language is used to compose and

control these abstractions.


22/47


Types of program generator

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.

Generator-based reuse is very cost-effective butits applicability is limited to some applicationdomains.

It is easier for end-users to develop programsusing generators compared to other component-

based approaches to reuse.


23/47


Aspect-oriented development

Aspect-oriented development (AOD) addresses amajor software engineering problem:the separation of concerns.

Concerns are often not simply associated withapplication functionality but are cross-cutting.

E.g. all components may monitor their own operation,

all components may have to maintain security, etc.

In AOD, cross-cutting concerns are implementedseparately (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.


24/47


Aspect-oriented development

Generated code

Aspect 1 Aspect 2

AspectWeaver

Aspect 1

Aspect 2

Input source code

join point 1

join point 2

Any join point may be filled by more than one aspect


25/47


Application frameworks

A framework is a conceptually complete designplus 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.

Implementation is completed by adding

components to fill in the missing parts. Miniature example:

java.util.collections.Collection: static void sort(List list)

Requires that all elements of the list implement interfaceComparable:int compareTo(Object o)

Reusable 'sort' will call user-defined function 'compareTo'.


26/47


Types of framework

System infrastructure frameworks

Support the development of system infrastructures suchas communications, user interfaces and compilers.

Middleware integration frameworks Standards and classes that support resource management

and component communication.

Enterprise application frameworks Support the development of specific types of application

such as telecommunications or financial systems.

A problem with frameworks is their complexity.

It takes long to learn using them effectively.


27/47


Model-View-Controller (MVC)

System infrastructure framework for GUI design.

Allows for multiple presentations of an object andseparate interactions with each.

Using an MVC framework involves the instantiationof a number of design patterns.

E.g. Observer pattern, Strategy pattern, maybeComposite pattern.

Parts of the implementations of these patterns have to beprovided by the framework user.


28/47


Model-View-Controller

Model methods

Controller methods View methods

User

inputs

view modification

messages

Model edits

Model queriesand updates

Controller state View state

Model state


29/47


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.


30/47


COTS product reuse

COTS = Commercial Off-The-Shelf software.

COTS systems are usually complete applicationsystems that offer an API (ApplicationProgramming Interface).

Building large systems by integrating COTSsystems is now a viable development strategy forsome types of system

such as E-commerce systems.

The key benefit is faster application development

and, usually, lower development costs.


31/47


COTS design choices

Which COTS products offer the most appropriatefunctionality?

There may be several similar products that may be used.

Can I later switch my system over to a differentCOTS product if I have to?

If the COTS is decomissioned or does not support future

requirements.

How will data be exchanged?

Individual products use their own data structures and

formats. 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.


32/47


E-procurement system

Client

Web browser E-mail system

Server

E-commerce

system

Ordering and

invoicing system

E-mail system

Adaptor

Adaptor


33/47


COTS products reused

On the client, standard e-mail and web browsingprograms are used.

On the server, an e-commerce platform has to beintegrated 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.


34/47


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 conflictingassumptions so that integration can be difficult.

No control over system evolution

COTS vendors, not system users control evolution.

Finite support from COTS vendors

COTS vendors may not offer support over the lifetime of

the product.


35/47


Software product lines

Software product lines or application families areapplications with generic functionality that can beadapted and configured for use in a specific

context.

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.


36/47


COTS product specialisation

Platform specialisation

Different versions of the application are developed fordifferent platforms.

Environment specialisation Different versions of the application are created to handle

different operating environments e.g. different types of

communication equipment. Functional specialisation

Different versions of the application are created forcustomers with different requirements.

Or for different marketing needs (e.g. "light" versions).

Process specialisation

Different versions of the application are created to

support different business processes.


37/47


COTS configuration

Deployment-time configuration

A generic system is configured by embedding knowledgeof the customers requirements and business processes.

The software itself is not changed.

Design-time configuration

A common generic code is adapted and changedaccording to the requirements of particular customers.

Creates a specific version of the software.

Deployment time configuration:


38/47


Deployment-time configuration:ERP systems

An Enterprise Resource Planning (ERP) system is ageneric system that supports common businessprocesses

such as ordering and invoicing, production planning, etc.

These are very widely used in large companies

and represent probably the most common form of huge-scale software reuse.

The generic core is adapted at deployment time by including modules and

by incorporating knowledge of specific business processesand rules.


39/47


ERP system organisation

Configurationdatabase

System database

Generic ERP system

Configuration

planning tool


40/47


Design time configuration: Product lines

Software product lines that are configured atdesign time are instantiations of genericapplication architectures

as discussed in Chapter 13.

Generic products usually emerge after experience withspecific products.

Architectures must be structured in such a way toseparate different sub-systems and to allow themto be modified

e.g. by separating entities strongly in the architecture:The higher levels in the system access entities throughdescriptions rather than directly.


41/47


Generic resource management system

User inter face

Resourcemanagement

Resource policycontrol

Resourceallocation

Userauthentication

Querymanagement

Resource database

Resourcedelivery

Transaction management


42/47


Vehicle despatching

A specialised resource management system wherethe aim is to allocate resources (vehicles) tohandle incidents.

Adaptations include:

At the UI level, there are components for operator display

and communications;

At the I/O management level, there are components thathandle authentication, reporting and route planning;

At the resource management level, there are componentsfor vehicle location and despatch, managing vehicle statusand incident logging;

The database includes equipment, vehicle and map

databases.


43/47


A vehicle despatching system

User interface

Vehicle statusmanager

Incidentlogger

Operatorauthentication

Querymanager

Equipmentdatabase

Map and routeplanner

Transaction management

Vehicle database

Incident log

Map database

Vehicledespatcher

Equipmentmanager

Vehiclelocator

Reportgenerator

Comms systeminter face


44/47


Product instance development

Elicit

stakeholderrequirements

Choose

closest-fitfamily member

Deliver new

family member

Renegotiate

requirements

Adapt existing

system


45/47


Product instance development

Elicit stakeholder requirements

Use existing family member as a prototype.

Choose closest-fit family member

Find the family member that best meets the requirements.

Re-negotiate requirements

Adapt requirements as necessary to capabilities of the

software.

Adapt existing system

Develop new modules and make changes for family

member. Deliver new family member

Document key features for further member development.


46/47


Key points

Advantages of reuse are lower costs, fastersoftware development and lower risks.

Successful reuse requires overcoming a number of

barriers: Creation/availability, discovery, understanding,fitness, trust, adaptation, evolution.

Design patterns are high-level abstractions that

describe and discuss problem/solution pairs. Reusable concepts may be embedded in a

program generator system.

Application frameworks are collections ofconcrete and abstract objects

that are designed for reuse through specialisation.


47/47

Key points (2)

COTS product reuse is concerned with the reuseof large, off-the-shelf systems.

Problems with COTS reuse include lack of control over

functionality, performance, and evolution and problemswith inter-operation.

ERP systems are created by configuring a generic

system with information about a customersbusiness.

Software product lines are related applications

developed around a common core of sharedfunctionality.

~$18 software reuse

Documents