EPL603 – Topics in Software Engineering

(1)

Lecture 4 - Software Reuse

EPL603 – Topics in Software

Engineering

Efi Papatheocharous

Visiting Lecturer

(2)

Topics covered



Software reuse



The reuse landscape



Design reuse



Libraries or toolkits



Application frameworks



Design patterns



Architectures



Software product lines



COTS product reuse



ERP Systems

Lecture 4: Software reuse 2

(3)

Software reuse (1/4)



Reuse

is often referred to as “

not reinventing the wheel

”.



In most engineering disciplines,

systems are designed

by

composing existing components

that have been used in

other systems.

(4)

Software reuse (2/4)



The ability to

reuse software

relies in the ability to build

larger

systems from smaller parts

, and being able to identify

commonalities

among those parts.



The level of reuse in each system may vary.

4 Lecture 4: Software reuse

25/09/2012

Reuse maturity level

(5)

Software reuse (3/4)



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 a design process that is based on

systematic

software reuse

.



There has been a major switch to reuse-based development over the

past 10 years.



“By software reuse we mean the

repeated use

of

any part of a software

system

, such as, documentation, code, design, requirements, test cases

and test data.”



“Software researchers believe that reuse has

great potential

for increasing

productivity and reducing cost and some efforts to apply reuse technologies

confirmed their belief.”

[Pfleeger and Atlee, 2010]

25/09/2012

(6)

Software reuse (4/4)



“

Software reuse

is the process whereby an organization defines

a

set of systematic operating procedures

to

specify, produce,

classify, retrieve

and

adapt

software artefacts for the purpose of

using them in its development activities.”

[Mili et al., 2002]



Software artefacts

include all software products, from requirements

and proposals, to specifications and designs, to source code, to

components, development artefacts, to patterns, and templates, to

user manuals and test suites.



Anything that is produced from a software development effort

can potentially be reused.

25/09/2012 Lecture 4: Software reuse 6

(7)

Reuse-based software engineering

25/09/2012



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.

 Little or no original software development is required; a whole system is configured for the needs of an organization.



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.

(8)

Reuse-based software engineering process

(9)

Benefits of software reuse (1/2)

Benefit Explanation

Increased dependability Reused software, which has been tried and tested in working systems, should be more dependable than new software. Its design and implementation faults should have been found and fixed.

Reduced process risk The cost of existing software is already known, whereas the costs of development are always a matter of judgment. This is an important factor for project management because it reduces the margin of error in project cost estimation. This is particularly true when relatively large software components such as subsystems are reused.

Effective use of specialists

Instead of doing the same work over and over again,

application specialists can develop reusable software that encapsulates their knowledge.

(10)

Benefits of software reuse (2/2)

Benefit Explanation

Standards compliance Some standards, such as user interface standards, can be implemented as a set of reusable components. For example, if menus in a user interface are implemented using reusable components, all applications present the same menu formats to users. The use of standard user interfaces improves dependability because users make fewer mistakes when presented with a familiar interface.

Accelerated development Bringing a system to market as early as possible is often more important than overall development costs. Reusing software can speed up system production and

efficiency because both development and validation time may be reduced.

(11)

Substantial return on investment (1/2)



Metrics collected in two reuse programs at Hewlett-Packard

demonstrated improved quality, increased productivity, and

reduced time to market.

(12)

Substantial return on investment (2/2)



Ericsson engineering teams in Sweden and Norway built two

large-scale, distributed telecom systems containing several reused

components.



The systems were evaluated in terms of the

effect of software

reuse

on

product defects

and

stability

.



The analysis showed that reused components had a

lower

defect density

than non-reused ones, with defect density

calculated by dividing the number of defects by the number of

lines of code.



Among successive releases reusable components were less

likely to be modified, as measured by the percentage of code

that was modified. Thus, the reused components were

far more

stable

than their non-reused counterparts.

(13)

Problems with reuse (1/2)

Problem Explanation

Increased maintenance costs

If the source code of a reused software system or component is not available then maintenance costs may be higher because the reused elements of the system may become increasingly incompatible with system changes.

Lack of tool support Some software tools do not support development with reuse. It may be difficult or impossible to integrate these tools with a component library system. The software process assumed by these tools may not take reuse into account. This is particularly true for tools that support embedded systems engineering, less so for object-oriented development tools.

Not-invented-here (ΝΙΗ) syndrome

Some software engineers prefer to rewrite components

because they believe they can improve them or they believe they cannot be any good unless they wrote it themselves. This is partly to do with trust and partly to do with the fact that writing original software is seen as more challenging than reusing other people’s software.

(14)

Problems with reuse (2/2)

Problem Explanation

Creating, maintaining, and using a component library is expensive

Populating a reusable component library and ensuring

the software developers can use this library can be

expensive. Development processes have to be adapted to ensure that the library is used.

Finding,

understanding, and adapting reusable

components is difficult

Software components have to be discovered in a library,

understood and, sometimes, adapted to work in a new environment. Engineers must be reasonably confident of finding a component in the library before they include a component search as part of their normal development process.

Legal issues Legal issues can arise with contract software. Usually in the type of contracts drawn up between a client and a software development organization, the software product belongs to the customer. Therefore, if a developer reuses a component of one client’s product essentially violates

the first client’s copyright.

25/09/2012

Sources : Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010

(15)

Experiences with reuse

 Raytheon

 A Missile Systems Division’s Information Processing Systems Organization.

 Observed 60% of its business applications design and code were redundant and thus were good candidates for reuse.

 Classified source code into 3 major module classes (edit, update and report).

 Reported that a new system contained an average of 60% reused code, increasing productivity by 50%.  GTE Data Services

 Established incentives and rewards for programmers, i.e., they were paid: • Up to $100 for every component accepted to the library

• Royalties whenever their components were reused by a new project.

 Bonus for the “reuser of the month” award.

 In the first year, reported 14% reuse on its projects, valued at a savings of $1.5m.  Nippon Novel

 Paid 5c per line of code to a developer who reused a component.

 The program cost far less than the cost of writing the equivalent code.

 However, some organizations have reported cost increases for making a component reusable of 200% up to 480%.

(16)

Open source software reuse



Open source development

is an approach to software

development in which the

source code

of a software system

is

published

and

volunteers

are invited to participate in the

development process



Its

roots

are in the

Free Software Foundation

which advocates that

source code should not be

proprietary

but rather should always be

available for users

to examine and modify as they wish

.



Open source systems offer an

opportunity

for effective

software reuse since it provides rich collection of software

projects.



Examples of best-known open source product is, of course, the

Linux

OS which is widely used as a server system and, increasingly,

as a desktop environment.



Other important open source products are

Java

, the

Apache

web

server and the

mySQL

database management system.

(17)

Open source issues



Should the product that is being developed make use of open

source components?



The

type of software

developed should be taken into

consideration. If the software is for sale, then

time to market

and

reduced costs

are critical.



The

domain

for which the software is developed is also critical. If

for the domain you are developing there are high-quality open

source systems available , then you can save time and money by

using these systems.



If the system has

specific

set of

organizational requirements

,

then open source components may not be an option. You may

have to integrate your software with existing systems that are

compatible with available open source systems.



Even then, it could be quicker and cheaper to modify the open

source system rather than redevelop the functionality that you need.

(18)

Open source licensing (1/2)



A

fundamental principle

of open-source development is that

source code should be freely available

; this does not mean that

anyone can do as they wish with that code.



Legally, the

developer

of the code (either a company or an

individual)

still owns the code

. They can place

restrictions

on

how it is used by including legally binding conditions in an

open

source software license

.

• Some open source developers believe that if an open source

component is used to develop a new system, then that

system should also be open source.

• Others are willing to allow their code to be used without this

restriction. The developed systems may be proprietary and

sold as closed source systems

Richard Stallman in “Hackers: Wizards of the Electronic Age”, 2010.

http://www.youtube.com/watch?v=oIrXuv-JjeE&feature=youtube_gdata_player. Internet and Web Pioneers: Richard Stallman, 2006.

(19)

Open source licensing (2/2)



The GNU General Public License (GPL)



This is a so-called ‘reciprocal’ license that means that if you use

open source software that is licensed under the GPL license,

then you must make that software open source.



The GNU Lesser General Public License (LGPL)



This is a variant of the GPL license where you can write

components that link to open source code without having to

publish the source of these components.



The Berkley Standard Distribution (BSD) License



This is a non-reciprocal license, which means you are not

obliged to re-publish any changes or modifications made to open

source code. You can include the code in proprietary systems

that are sold.

(20)

The reuse landscape (1/2)



Although reuse is often simply thought of as the reuse of

system components, there are many different

approaches to reuse that may be used.



Reuse is possible at a range of levels from simple

functions to complete application systems.



The

reuse landscape

covers the range of possible

reuse techniques.

(21)

The reuse landscape (2/2)

25/09/2012 Legacy system

(22)

Approaches that support software reuse (1/3)

Approach Description

Architectural patterns Standard software architectures that support common types of application systems are used as the basis of applications.

Design patterns Generic abstractions that occur across applications are represented as design patterns showing abstract and concrete objects and interactions.

Component-based software development (CBSE)

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

Legacy system wrapping

Legacy systems (old systems that are still useful and are often critical to business operations) are ‘wrapped’ by defining a set of interfaces and providing access to these legacy systems through these interfaces.

(23)

Approaches that support software reuse (2/3)

Application frameworks Collections of abstract and concrete classes are adapted and extended to create application systems.

Service-oriented systems

Systems are developed by linking shared services, which may be externally provided.

Software product lines (SPL)

An application type is generalized around a common architecture so that it can be adapted for different customers.

COTS product reuse Systems are developed by configuring and integrating existing application systems.

ERP systems Large-scale systems that encapsulate generic business functionality and rules are configured for an organization.

Configurable vertical applications

Generic systems are designed so that they can be configured to the needs of specific system customers.

(24)

Approaches that support software reuse (3/3)

Program libraries Class and function libraries that implement commonly used abstractions are available for reuse.

Model-driven engineering

Software is represented as domain models and implementation independent models and code is generated from these models.

Program generators A generator system embeds knowledge of a type of application and is used to generate systems in that domain from a user-supplied system model.

Aspect-oriented

software development

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

(25)

Types of reuse and domain analysis



Vertical reuse



Involves the same application area or domain.



Horizontal reuse



Does not involve the same domain, but cuts across domains.

[Pfleeger & Atlee]



With

any

form of reuse a “

robust

” library needs to be discovered.



The process where the entities in libraries are determined to be

appropriate for use in new applications is the

domain analysis

process

.



Domain analysis process is the process of identification, analysis

and specification of common requirements from a specific

application domain, typically for

reuse on multiple projects

within

the application domain.

[Pressman]

(26)

Reuse planning factors (1/2)

25/09/2012

Factor Description

Development schedule

If the software has to be developed quickly, use COTS integration rather than CBSE. Even though the fit to requirements may be imperfect, it minimizes the amount of development required.

Expected lifetime If the system lifetime is long the maintainability of the system is critical. Probably it is better to avoid reuse with unavailable or inaccessible code, such as COTS and systems from external suppliers; suppliers may not be able to continue support for the reused software.

Development team All reuse technologies are fairly complex. If the development teams’ background, skills and experience is related to any of the reuse areas, this is probably where you should turn in to.

Criticality and non-functional

requirements

(27)

Reuse planning factors (2/2)

25/09/2012

Factor Description

Application domain If the system is for a specific application domain, such as manufacturing and medical information systems, several configurable vertical application reuse methods may be considered a good solution. There are several generic products that may be reused for configuring them to a local solution.

Application Platform

(28)

Black-box and white-box reuse

Black-box reuse

• Assets are integrated into target

system

without modification

.

• Greater benefit.

• Higher information hiding

.

• Simplifies reuse for the

“consumer” because he does not

need to know the internal

workings to compose assets.

• Harder to realize for the

“producer” (the one that creates

reusable components).

White-box reuse

• Assets are

modified

before they

are integrated into the target

system.

• Requires

deep understanding

of

the

inner-working

of the asset.

• Requires

re-assessment

of the

qualitative

properties of the

asset.

• Needs to be

tested

anew.

• Loss of “guarantee” from the

“producer”.

• Smaller benefit.

(29)

Reuse during design and implementation



Reuse within:

a) A library or a toolkit

b) A framework

c) A design pattern

d) A software

architecture

(a)

(b)

(c)

(d)



During design different types of reuse may be carried

out, some of which carry over into implementation.

Source: Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, 2007.

(30)

Reuse with a library or toolkit



A

library

or a

toolkit

is used.



Examples:

• .

• Java GUI Widget Toolkit

The

designer

and

developer

are responsible

for the

control

logic of the

product as a

whole

.

Source: Schach, S.R., _{Object-Oriented and}

(31)

Reuse with a library or toolkit benefits



The library or toolkit supplies parts for conducting specific operations

of the product.



Tested modules (designs and implementations) are incorporated

into the product. Thus, the overall design and implementation can be

produced more

quickly

and it is likely to have a

higher quality

than

when everything is created from scratch.

Reuse with a library or toolkit problems



Library reuse (rather than toolkit reuse) promotes code reuse

more rather than design reuse.



It can be alleviated with the object-oriented paradigm.

(32)

Reuse with a framework



Software reuse with a

framework

is when designers design

application-specific operations and specific classes are inserted

from/into the framework.



Examples:

The

designer

and

developer

supply the

control logic of

specific

operations

.

Source: Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, 2007. Framework for building

online information systems in Java

MacApp framework for application software on

Macintosh Microsoft’s Foundation

Class Library (MFC) contains large collection of

frameworks for building GUIs in Windows apps Visual Components Library

(VCL) an update of Object Windows Library (OWL);

(33)

Application frameworks



Application frameworks

consist of a software framework used by

software developers to implement the

standard structure of an

application for a specific development environment

(such as an

operating system or a web application).



Frameworks are moderately

large entities

that can be

reused

.



Frameworks are somewhere between system and component reuse.



Frameworks are sub-system designs made up of a

collection of

abstract and concrete classes

and the

interfaces between them

.



The sub-system is implemented by adding components to fill in

parts of the design and by instantiating the abstract classes in the

framework.

(34)

Framework classes

 System infrastructure frameworks

 Support the development of system infrastructures such as communications, user interfaces and compilers.

 Middleware integration frameworks

 Standards and classes that support component communication and information exchange.

 Examples include Microsoft’s .NET and Enterprise Java Beans (EJB).

 Support standardized component models.

 Enterprise application frameworks

 Support the development of specific types of application such as telecommunications or financial systems.

 Embed application domain knowledge and support the development of end-user applications.

 Web application frameworks (WAF)

 Support the construction of dynamic websites and incorporate specialized features.

(35)

Web application frameworks



WAF are widely applicable and support the construction of

dynamic websites

as a

front-end for web applications

.



WAF are now

available

for all of the commonly used web

programming languages e.g. Java, Python, Ruby, etc.



Their architecture is based on the

Model-View-Controller

(

MVC

) composite pattern.



Recommends the separation of the business logic from the

presentation layer and the use of a controller to coordinate the flow

of requests from the client to the server and the actions taken on

those requests.

(36)

WAF features



Security

 WAF may include classes to help implement user authentication (login) and access.



Dynamic web pages

 Classes are provided to help you define web page templates and to populate these dynamically from the system database.



Database support

 The framework may provide classes that provide an abstract interface to different databases.



Session management

 Classes to create and manage sessions (a number of interactions with the system by a user) are usually part of a WAF.



User interaction

 Most web frameworks now provide AJAX support, which allows more interactive web pages to be created.

(37)

Reuse with framework’s benefits



Frameworks are

generic

but can also be

specialized to a domain

.



Frameworks reuse offers

faster development

than reuse with toolkits

with libraries because:



More of design is reused with frameworks and there is less to

design from scratch.



The portion of the design that is reused with a framework (the

control logic) is harder to design than the functions; so the

quality

of the

design

is likely to be

higher

than when a toolkit is used.



If the implementation is based on a framework then the resulting

product is likely to be

maintained easily

because the control logic

has already been tested in other products.



Frameworks are often implementations of

multiple design patterns

.



Frameworks are

concrete

and can be

extended

.

(38)

Extending frameworks



Frameworks are generic and are

extended

to create a

more specific application or sub-system. They provide a

skeleton architecture

for the system.



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.



Problem with frameworks is their

complexity

which means

that it takes a long time to use them effectively.

(39)

Example with extending frameworks

UML Notation

Implementation

package FrameworkPackage;

abstract class AbstractClass....

package FrameworkPackage;

class DerivedClass extends AbstractClass {

int att; ... ....

void myMethod2 (ReferencedClass c) { ...}

}

package of classes

abstract class

inheritance

(40)

Reuse with design patterns



Design patterns

consist of a solution to a general design problem in

the form of a set of interacting classes that are customized to create

a specific design.



Example:



We want a program that generates families of related objects, without

specifying concrete classes.



Abstract Car Factory

Classes

that

must be

(41)

Abstract widget factory design pattern



We want a program that

generates widgets

(menus, windows,

scrollbars, sliders) that can

run under different

operating systems.

(42)

Reuse based on software architecture (1/2)



Various architectures used for churches, cathedrals and temples.



Reuse in

software architecture

is applying a design of a product as a

whole, and usually encompasses a variety of issues:

• Components organization and physical distribution

• Product-level control structures

• Communication and synchronization issues

• Databases and data access

• Choice of alternatives …

Renaissance (façade) (Sant’ Andrea della Valle, Italy) Gothic (façade)

(Notre-Dame, France)

Source: Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, 2007.

Byzantine (Hagia Sophia, Turkey) Ancient Greek, Doric

(43)

Reuse based on software architecture (2/2)



[defn]

“Abstractly,

software architecture

involves the description of

elements

from which systems are built,

interactions

among those

elements,

patterns that guide their composition

, and

constraints

on those patterns

.”



Architecture includes patterns as a subfield.



Example:

• An architecture consisting of:

– A framework

– Three design patterns

– A toolkit

Source: Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed.,

(44)

Software product lines (1/2)



Software product lines

or

application families

are collections of

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.



A set of software intensive systems sharing a common managed set of

features that satisfy the specific needs of a

particular market segment or

mission

and that are developed from a common set of core assets in a

prescribed way.

25/09/2012

(45)

Hall of fame case studies

Software product lines (2/2)

 High proportion of the application code is reused.

 Product lines embed detailed domain and platform information.

 Are made up of a family of applications, usually owned by the same organization.

 Adaptations may involve:

 Existing component and system configuration

 Adding new components to the system

 Selecting from a library of existing components

 Modifying components to meet new requirements

 Examples

 Embedded software for mobile phones

 Control application for equipment (e.g, family of printers)

 Business support software

 Computer games

(46)

Product instance development process

 Elicit stakeholder requirements

 Use existing family member as a prototype

 Choose closest-fit family member (starting point)

 Find the family member that best meets the requirements for modification

25/09/2012



Re-negotiate requirements

 Adapt requirements as necessary to capabilities of the software, to minimize the changes needed.



Adapt existing system

 Develop new modules and make changes for family member



Deliver new family member

 Document key features for other member developments in the future

(47)

Product line specialization



Platform specialization



Different versions of the application are developed for different

platforms. E.g., Windows, Mac OS, Linux.



Environment specialization



Different versions of the application are created to handle different

operating environments e.g. different types of communication

equipment (peripheral devices).



Functional specialization



Different versions of the application are created for customers with

different requirements.



Process specialization



Different versions of the application are created to support

different business processes.

(48)

COTS product reuse



A commercial-off-the-shelf (COTS) product

is a software system

that can be adapted for different customers

without changing the

source code

of the system.



COTS systems have

generic features

and so can be used/reused in different

environments.



COTS products are adapted by using

built-in configuration mechanisms

that 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 patients.



Benefits

with COTS reuse include:



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

.



Businesses (the customers) can focus on their core activity without having

to devote a lot of resources to IT systems development. Technology

updates are simplified as are usually

responsibility of the vendor

.

(49)

Problems of COTS reuse



Requirements

usually have to be

adapted

to reflect the functionality

and mode of operation of the COTS product. This may disrupt existing

business processes.



The COTS product may be

based on assumptions

that are

practically

impossible

to

change

. The customer thus needs to adapt

their business to these assumptions.



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. Thus, the customer relies on the vendor’s advice which

may be biased and geared to selling products and services rather

than meeting the customer’s real needs.



The COTS product vendor controls system support and evolution.

The vendor may go out of business, be taken over, or make changes

that cause difficulties for customers.

(50)

COTS-solution and COTS-integrated systems (1/2)

25/09/2012

COTS-solution systems COTS-integrated systems

Product Single product Several heterogeneous system

products are integrated

Functionality Provides the functionality

required by a customer

Provide customized functionality for customers

Solution and processes

Based around a generic solution and standardized processes

Based on several flexible

solutions that may be developed for supporting customer processes

Development focus

On system configuration On system integration

Responsible for maintenance

System vendor System owner

Provides platform for the system

(51)

COTS-solution and COTS-integrated systems (2/2)



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.



COTS-integrated systems

are applications that include two or more COTS

products and/or legacy application systems.



One may prefer them when there is

no single COTS system

that meets

all needs or when a new COTS product is integrated with systems that

are already in use.



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

.



For example, an

Enterprise Resource Planning (ERP) system

is a

generic system that supports common business processes such as

ordering and invoicing, manufacturing, etc.

(52)



A defined set of

business

processes

, associated

with each module, which

relate to activities in that

module.



A set of

business rules

that apply to all data in the

database.

The architecture of an ERP system

25/09/2012

A number of

modules

to support different

business functions.

A

common database

that maintains information

about all related business functions.

Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010.

*

(53)

Issues in ERP configuration



Select the

required functionality

from the system.



Establish a

data model

that defines how the organization’s data

will be structured in the system database.



Define

business rules

that apply to that data.



Define the

expected interactions

with

external systems

.



Design the

input forms

and the

output reports

generated by

the system.



Design

new business processes

that conform to the

underlying process model supported by the system.



Set

parameters

that define how the system is

deployed

on its

underlying platform.

(54)

Design choices with COTS-solutions



Which

COTS

products

offer the most appropriate

functionality?



Typically, there will be several COTS products

available, which can be combined in different ways.



How

will

data

be

exchanged

?

25/09/2012



Different products normally use unique data structures

and formats. You have to write adaptors that convert

from one representation to another.



What

features

of a product will

actually be used

?

(55)

Service-oriented COTS interfaces



COTS-integration can be simplified if a

service-oriented

approach is

used.



A service-oriented approach means

allowing access to the

application system’s functionality through a standard service

interface

, with a

service

for each discrete unit of functionality.



Some applications may offer a

service interface

but, sometimes,

this service interface has to be implemented by the system

integrator.

25/09/2012 Source: Sommerville, I., Software _{Engineering, 9th ed., Addison}

Wesley, 2010. Build a wrapper

that hides the

application system and provides

externally visible services.

*

(56)

COTS-integration system problems



Lack of control

over functionality and performance



COTS systems may be less effective than they appear.



Problems with COTS system

interoperability



Different COTS systems may make different assumptions that

means integration is difficult.



No

control

over system

evolution



COTS vendors not system users control evolution.



Support

from COTS vendors



COTS vendors may not offer support over the lifetime of the

product.

(57)

Key points (1/2)



Most new business software systems are now developed by

reusing

knowledge and code

from previously implemented systems.



There are

many different ways

to reuse software. These range from

the reuse of classes and methods in libraries to the reuse of complete

application systems.



The

advantages

of software reuse are lower costs, faster software

development and lower risks. System dependability is increased.

Specialists can be used more effectively by concentrating their

expertise on the design of reusable components.



Reuse can be accomplished through a

library

or a

toolkit

, a

framework

, a

design pattern

and

software architectures

.



Application frameworks

are collections of concrete and abstract

objects that are designed for reuse through specialization and the

addition of new objects. They usually incorporate good design practice

through design patterns.

(58)

Key points (2/2)



Software product lines

are related applications that are developed from a

common base. This generic system is adapted to meet specific

requirements for functionality, target platform or operational configuration.



COTS

product reuse is concerned with the reuse of large-scale,

commercial off-the-shelf

systems. These provide a lot of functionality and

their reuse can radically reduce costs and development time. Systems may

be developed by configuring a single, generic COTS product or by

integrating two or more COTS products.



Enterprise Resource Planning

(

ERP

) systems are examples of

large-scale COTS reuse. You create an instance of an ERP system by configuring

a generic system with information about the customer’s business processes

and rules.



Potential

problems

with COTS-based reuse include lack of control over

functionality and performance, lack of control over system evolution, the

need for support from external vendors and difficulties in ensuring that

systems can inter-operate.

25/09/2012

(59)

Readings



Chapter 16, Sommerville, I., Software Engineering, 9th ed., Addison

Wesley, 2010.



Chapter 8, Sections 8.2-8.5.4, Schach, S.R., Object-Oriented and

Classical Software Engineering, 7th ed., WCB/McGraw-Hill, 2007.



Chapter 12 – Section 12.4, Pfleeger, S. L. and Atlee, J. M., Software

Engineering, Fourth Edition, Pearson, 2010.



Chapter 21 – Sections 21.2.1/2 Pressman, R.S., Software Engineering:

a Practitioner’s Approach, 5th Rev. Ed., McGraw-Hill, 2000.

Credits



Slides adapted from Ian Sommerville Software Engineering, 9/E