EPL603 – Topics in Software Engineering
Lecture 4 - Software Reuse
EPL603 – Topics in Software
Engineering
Efi Papatheocharous
Visiting Lecturer
efi.papatheocharous@cs.ucy.ac.cy
Office FST-B107, Tel. ext. 2740
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
25/09/2012
Lecture 4: Software reuse
2
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.
25/09/2012
Lecture 4: Software reuse
3
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.
(a)
(b)
(c)
Reuse maturity level
25/09/2012
Lecture 4: Software reuse
4
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]
Source: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010.
25/09/2012
Lecture 4: Software reuse
5
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.
Source: Mili et al., Reuse Based Software Engineering: Techniques, Organization, and Measurement. Wiley, 2002
25/09/2012
Lecture 4: Software reuse
6
Reuse-based software engineering
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.
the unit of reuse
25/09/2012
Lecture 4: Software reuse
7
Reuse-based software engineering process
Source: Sommerville, I., Software Engineering, 9th ed.,
Addison Wesley, 2010.
25/09/2012
Lecture 4: Software reuse
8
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.
25/09/2012
Lecture 4: Software reuse
9
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.
25/09/2012
Lecture 4: Software reuse
10
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.
Source: Pfleeger, S. L. and Atlee, J. M., Software
Engineering, Fourth Edition, Pearson, 2010.
25/09/2012
Lecture 4: Software reuse
11
Substantial return on investment (2/2)
Ericsson engineering teams in Sweden and Norway built two largescale, 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.
Source: Mohagheghi, P., R. Conradi, O.M. Killi, and H. Schwarz. “An Empirical Study of Software Reuse Vs. Defect-density
and Stability.” In 26th International Conference on Software Engineering, 2004. ICSE 2004. Proceedings, 282 – 291, 2004.
25/09/2012
Lecture 4: Software reuse
12
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 (ΝΙΗ) Some software engineers prefer to rewrite components
syndrome
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.
25/09/2012
Lecture 4: Software reuse
13
Problems with reuse (2/2)
Problem
Explanation
Creating, maintaining, Populating a reusable component library and ensuring
and using a component the software developers can use this library can be
library is expensive
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
Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, 2007
Lecture 4: Software reuse
14
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%.
Sources: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010.
25/09/2012
Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, 2007.
Lecture 4: Software reuse
15
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 (www.fsf.org),
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.
Skip OSS
25/09/2012
Lecture 4: Software reuse
16
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.
25/09/2012
Lecture 4: Software reuse
17
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.
25/09/2012
Internet and Web Pioneers: Richard Stallman, 2006.
http://www.youtube.com/watch?v=ihxGJueWb-I&feature=youtube_gdata_player.
Lecture 4: Software reuse
18
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.
25/09/2012
Lecture 4: Software reuse
19
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.
25/09/2012
Lecture 4: Software reuse
20
The reuse landscape (2/2)
Application
frameworks
Architectural
patterns
Software
product lines
Component-based
software engineering
Model-driven
engineering
Design
patterns
Legacy system
wrapping
Service-oriented
systems
Aspect-oriented
software development
COTS
integration
Configurable
vertical applications
ERP systems
Program
generators
Program
libraries
25/09/2012
Lecture 4: Software reuse
21
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.
25/09/2012
Lecture 4: Software reuse
22
Approaches that support software reuse (2/3)
Approach
Description
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.
25/09/2012
Lecture 4: Software reuse
23
Approaches that support software reuse (3/3)
Approach
Description
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/09/2012
Lecture 4: Software reuse
24
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]
25/09/2012
Sources: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010.
Pressman, R.S., Software Engineering: a Practitioner’s Approach, 5th Rev. Ed., McGraw-Hill, 2000.
Lecture 4: Software reuse
25
Reuse planning factors (1/2)
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 nonfunctional
requirements
If the systems is a critical system (e.g., has stringent performance
requirements) it is probably better to avoid using unavailable or
inaccessible source code or generator-based reuse (generate
code from a reusable domain-specific representation of a system).
25/09/2012
Lecture 4: Software reuse
26
Reuse planning factors (2/2)
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
Consider the platform your system is designed for; you
may only be able to use specific components. Also, if the
component models or generic application systems you are
using are platform-specific, such as .NET component models
are specific to Microsoft platforms, you may only be able to
reuse these.
25/09/2012
Lecture 4: Software reuse
27
Black-box and white-box reuse
Black-box reuse
White-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).
Source: Pfleeger, S. L. and Atlee, J. M., Software
Engineering, Fourth Edition, Pearson, 2010.
25/09/2012
•
•
•
•
•
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.
Lecture 4: Software reuse
28
Reuse during design and implementation
During design different types of reuse may be carried
out, some of which carry over into implementation.
Reuse within:
(a) A library or a toolkit
(b) A framework
(c) A design pattern
(d) A software
architecture
(a)
(b)
(c)
(d)
Source: Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, 2007.
25/09/2012
Lecture 4: Software reuse
29
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.
25/09/2012
Lecture 4: Software reuse
Source: Schach, S.R.,
Object-Oriented and
Classical Software
Engineering, 7th ed.,
WCB/McGraw-Hill, 2007.
30
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.
Source: Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, 2007.
25/09/2012
Lecture 4: Software reuse
31
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:
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
The designer
and developer
supply the
control logic of
specific
operations.
Visual Components Library
(VCL) an update of Object
Windows Library (OWL);
similar functionality to
MFC
25/09/2012
Lecture 4: Software reuse
Source: Schach, S.R., Object-Oriented
and Classical Software Engineering,
7th ed., WCB/McGraw-Hill, 2007.
32
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.
25/09/2012
Lecture 4: Software reuse
33
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.
25/09/2012
Lecture 4: Software reuse
34
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.
25/09/2012
Lecture 4: Software reuse
35
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.
25/09/2012
Lecture 4: Software reuse
36
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.
Source: Schach, S.R., Object-Oriented and
Frameworks are concrete and can be extended. Classical
Software Engineering, 7th ed.,
WCB/McGraw-Hill, 2007.
25/09/2012
Lecture 4: Software reuse
37
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.
25/09/2012
Lecture 4: Software reuse
38
Example with extending frameworks
UML Notation
Implementation
package of classes
abstract class
package FrameworkPackage;
abstract class AbstractClass....
package FrameworkPackage;
inheritance
attribute
method
class DerivedClass extends AbstractClass
{
int att;
......
....
void myMethod2 (ReferencedClass c)
{ ...}
}
25/09/2012
Lecture 4: Software reuse
39
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.
Interacting classes
Abstract Car Factory
Classes that
must be
customized for
a specific
product.
25/09/2012
Lecture 4: Software reuse
Source: Schach,
S.R., ObjectOriented and
Classical Software
Engineering, 7th
ed.,
WCB/McGraw-Hill,
2007.
40
Abstract widget factory design pattern
We want a program that
generates widgets
(menus, windows,
scrollbars, sliders) that can
run under different
operating systems.
Source: Schach, S.R., ObjectOriented and Classical Software
Engineering, 7th ed., WCB/McGrawHill, 2007.
25/09/2012
Lecture 4: Software reuse
41
Reuse based on software architecture (1/2)
Various architectures used for churches, cathedrals and temples.
Ancient Greek, Doric
(Parthenon, Greece)
Byzantine
(Hagia Sophia, Turkey)
Gothic (façade)
Renaissance (façade)
(Notre-Dame, France) (Sant’ Andrea della Valle, Italy)
Reuse in software architecture is applying a design of a product as a
whole, and usually encompasses a variety of issues:
•
•
•
•
•
25/09/2012
Components organization and physical distribution
Product-level control structures
Communication and synchronization issues
Databases and data access
Source: Schach, S.R., ObjectOriented and Classical Software
Choice of alternatives …
Lecture 4: Software reuse
Engineering, 7th ed., WCB/McGraw42
Hill, 2007.
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
25/09/2012
Lecture 4: Software reuse
Source: Schach,
S.R., ObjectOriented and
Classical Software
Engineering, 7th
ed.,
WCB/McGraw-Hill,
2007.
43
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.
[SEI, http://www.sei.cmu.edu/productlines/]
?
refine / decide / plan
software
products
repository
software assets
25/09/2012
Lecture 4: Software reuse
package
44
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
25/09/2012
Hall of fame case studies
http://splc.net/fame.html
Source: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010.
Lecture 4: Software reuse
45
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
Source: Sommerville, I.,
Software Engineering, 9th ed.,
Addison Wesley, 2010.
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
25/09/2012
Lecture 4: Software reuse
46
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.
25/09/2012
Lecture 4: Software reuse
47
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.
25/09/2012
Lecture 4: Software reuse
48
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.
25/09/2012
Lecture 4: Software reuse
49
COTS-solution and COTS-integrated systems (1/2)
COTS-solution systems
COTS-integrated systems
Product
Single product
Functionality
Provides the functionality
required by a customer
Based around a generic
solution and standardized
processes
On system configuration
Several heterogeneous system
products are integrated
Provide customized functionality for
customers
Based on several flexible
solutions that may be developed
for supporting customer processes
On system integration
Solution and
processes
Development
focus
Responsible for
System vendor
maintenance
Provides platform System vendor
for the system
25/09/2012
System owner
System owner
Lecture 4: Software reuse
50
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.
25/09/2012
Lecture 4: Software reuse
51
The architecture of an ERP system
A defined set of business
processes, associated
with each module, which
relate to activities in that
module.
A number of modules to support different
business functions.
A set of business rules
that apply to all data in the
database.
*
*A common database that maintains information
about all related business functions.
Source: Sommerville, I.,
Software Engineering, 9th ed.,
Addison Wesley, 2010.
25/09/2012
Lecture 4: Software reuse
52
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.
25/09/2012
Lecture 4: Software reuse
53
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?
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?
COTS products may include more functionality than
you need and functionality may be duplicated across
different products.
25/09/2012
Lecture 4: Software reuse
54
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.
*
* Build a wrapper
that hides the
application system
and provides
externally visible
services.
25/09/2012
Lecture 4: Software reuse
Source: Sommerville, I., Software
Engineering, 9th ed., Addison
Wesley, 2010.
55
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.
25/09/2012
Lecture 4: Software reuse
56
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.
25/09/2012
Lecture 4: Software reuse
57
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 largescale 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.
Open Source?
25/09/2012
Lecture 4: Software reuse
58
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
(http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/).
25/09/2012
Lecture 4: Software reuse
59
EPL603 – Topics in Software
Engineering
Efi Papatheocharous
Visiting Lecturer
efi.papatheocharous@cs.ucy.ac.cy
Office FST-B107, Tel. ext. 2740
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
25/09/2012
Lecture 4: Software reuse
2
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.
25/09/2012
Lecture 4: Software reuse
3
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.
(a)
(b)
(c)
Reuse maturity level
25/09/2012
Lecture 4: Software reuse
4
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]
Source: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010.
25/09/2012
Lecture 4: Software reuse
5
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.
Source: Mili et al., Reuse Based Software Engineering: Techniques, Organization, and Measurement. Wiley, 2002
25/09/2012
Lecture 4: Software reuse
6
Reuse-based software engineering
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.
the unit of reuse
25/09/2012
Lecture 4: Software reuse
7
Reuse-based software engineering process
Source: Sommerville, I., Software Engineering, 9th ed.,
Addison Wesley, 2010.
25/09/2012
Lecture 4: Software reuse
8
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.
25/09/2012
Lecture 4: Software reuse
9
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.
25/09/2012
Lecture 4: Software reuse
10
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.
Source: Pfleeger, S. L. and Atlee, J. M., Software
Engineering, Fourth Edition, Pearson, 2010.
25/09/2012
Lecture 4: Software reuse
11
Substantial return on investment (2/2)
Ericsson engineering teams in Sweden and Norway built two largescale, 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.
Source: Mohagheghi, P., R. Conradi, O.M. Killi, and H. Schwarz. “An Empirical Study of Software Reuse Vs. Defect-density
and Stability.” In 26th International Conference on Software Engineering, 2004. ICSE 2004. Proceedings, 282 – 291, 2004.
25/09/2012
Lecture 4: Software reuse
12
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 (ΝΙΗ) Some software engineers prefer to rewrite components
syndrome
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.
25/09/2012
Lecture 4: Software reuse
13
Problems with reuse (2/2)
Problem
Explanation
Creating, maintaining, Populating a reusable component library and ensuring
and using a component the software developers can use this library can be
library is expensive
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
Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, 2007
Lecture 4: Software reuse
14
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%.
Sources: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010.
25/09/2012
Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, 2007.
Lecture 4: Software reuse
15
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 (www.fsf.org),
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.
Skip OSS
25/09/2012
Lecture 4: Software reuse
16
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.
25/09/2012
Lecture 4: Software reuse
17
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.
25/09/2012
Internet and Web Pioneers: Richard Stallman, 2006.
http://www.youtube.com/watch?v=ihxGJueWb-I&feature=youtube_gdata_player.
Lecture 4: Software reuse
18
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.
25/09/2012
Lecture 4: Software reuse
19
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.
25/09/2012
Lecture 4: Software reuse
20
The reuse landscape (2/2)
Application
frameworks
Architectural
patterns
Software
product lines
Component-based
software engineering
Model-driven
engineering
Design
patterns
Legacy system
wrapping
Service-oriented
systems
Aspect-oriented
software development
COTS
integration
Configurable
vertical applications
ERP systems
Program
generators
Program
libraries
25/09/2012
Lecture 4: Software reuse
21
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.
25/09/2012
Lecture 4: Software reuse
22
Approaches that support software reuse (2/3)
Approach
Description
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.
25/09/2012
Lecture 4: Software reuse
23
Approaches that support software reuse (3/3)
Approach
Description
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/09/2012
Lecture 4: Software reuse
24
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]
25/09/2012
Sources: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010.
Pressman, R.S., Software Engineering: a Practitioner’s Approach, 5th Rev. Ed., McGraw-Hill, 2000.
Lecture 4: Software reuse
25
Reuse planning factors (1/2)
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 nonfunctional
requirements
If the systems is a critical system (e.g., has stringent performance
requirements) it is probably better to avoid using unavailable or
inaccessible source code or generator-based reuse (generate
code from a reusable domain-specific representation of a system).
25/09/2012
Lecture 4: Software reuse
26
Reuse planning factors (2/2)
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
Consider the platform your system is designed for; you
may only be able to use specific components. Also, if the
component models or generic application systems you are
using are platform-specific, such as .NET component models
are specific to Microsoft platforms, you may only be able to
reuse these.
25/09/2012
Lecture 4: Software reuse
27
Black-box and white-box reuse
Black-box reuse
White-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).
Source: Pfleeger, S. L. and Atlee, J. M., Software
Engineering, Fourth Edition, Pearson, 2010.
25/09/2012
•
•
•
•
•
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.
Lecture 4: Software reuse
28
Reuse during design and implementation
During design different types of reuse may be carried
out, some of which carry over into implementation.
Reuse within:
(a) A library or a toolkit
(b) A framework
(c) A design pattern
(d) A software
architecture
(a)
(b)
(c)
(d)
Source: Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, 2007.
25/09/2012
Lecture 4: Software reuse
29
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.
25/09/2012
Lecture 4: Software reuse
Source: Schach, S.R.,
Object-Oriented and
Classical Software
Engineering, 7th ed.,
WCB/McGraw-Hill, 2007.
30
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.
Source: Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, 2007.
25/09/2012
Lecture 4: Software reuse
31
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:
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
The designer
and developer
supply the
control logic of
specific
operations.
Visual Components Library
(VCL) an update of Object
Windows Library (OWL);
similar functionality to
MFC
25/09/2012
Lecture 4: Software reuse
Source: Schach, S.R., Object-Oriented
and Classical Software Engineering,
7th ed., WCB/McGraw-Hill, 2007.
32
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.
25/09/2012
Lecture 4: Software reuse
33
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.
25/09/2012
Lecture 4: Software reuse
34
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.
25/09/2012
Lecture 4: Software reuse
35
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.
25/09/2012
Lecture 4: Software reuse
36
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.
Source: Schach, S.R., Object-Oriented and
Frameworks are concrete and can be extended. Classical
Software Engineering, 7th ed.,
WCB/McGraw-Hill, 2007.
25/09/2012
Lecture 4: Software reuse
37
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.
25/09/2012
Lecture 4: Software reuse
38
Example with extending frameworks
UML Notation
Implementation
package of classes
abstract class
package FrameworkPackage;
abstract class AbstractClass....
package FrameworkPackage;
inheritance
attribute
method
class DerivedClass extends AbstractClass
{
int att;
......
....
void myMethod2 (ReferencedClass c)
{ ...}
}
25/09/2012
Lecture 4: Software reuse
39
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.
Interacting classes
Abstract Car Factory
Classes that
must be
customized for
a specific
product.
25/09/2012
Lecture 4: Software reuse
Source: Schach,
S.R., ObjectOriented and
Classical Software
Engineering, 7th
ed.,
WCB/McGraw-Hill,
2007.
40
Abstract widget factory design pattern
We want a program that
generates widgets
(menus, windows,
scrollbars, sliders) that can
run under different
operating systems.
Source: Schach, S.R., ObjectOriented and Classical Software
Engineering, 7th ed., WCB/McGrawHill, 2007.
25/09/2012
Lecture 4: Software reuse
41
Reuse based on software architecture (1/2)
Various architectures used for churches, cathedrals and temples.
Ancient Greek, Doric
(Parthenon, Greece)
Byzantine
(Hagia Sophia, Turkey)
Gothic (façade)
Renaissance (façade)
(Notre-Dame, France) (Sant’ Andrea della Valle, Italy)
Reuse in software architecture is applying a design of a product as a
whole, and usually encompasses a variety of issues:
•
•
•
•
•
25/09/2012
Components organization and physical distribution
Product-level control structures
Communication and synchronization issues
Databases and data access
Source: Schach, S.R., ObjectOriented and Classical Software
Choice of alternatives …
Lecture 4: Software reuse
Engineering, 7th ed., WCB/McGraw42
Hill, 2007.
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
25/09/2012
Lecture 4: Software reuse
Source: Schach,
S.R., ObjectOriented and
Classical Software
Engineering, 7th
ed.,
WCB/McGraw-Hill,
2007.
43
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.
[SEI, http://www.sei.cmu.edu/productlines/]
?
refine / decide / plan
software
products
repository
software assets
25/09/2012
Lecture 4: Software reuse
package
44
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
25/09/2012
Hall of fame case studies
http://splc.net/fame.html
Source: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, 2010.
Lecture 4: Software reuse
45
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
Source: Sommerville, I.,
Software Engineering, 9th ed.,
Addison Wesley, 2010.
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
25/09/2012
Lecture 4: Software reuse
46
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.
25/09/2012
Lecture 4: Software reuse
47
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.
25/09/2012
Lecture 4: Software reuse
48
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.
25/09/2012
Lecture 4: Software reuse
49
COTS-solution and COTS-integrated systems (1/2)
COTS-solution systems
COTS-integrated systems
Product
Single product
Functionality
Provides the functionality
required by a customer
Based around a generic
solution and standardized
processes
On system configuration
Several heterogeneous system
products are integrated
Provide customized functionality for
customers
Based on several flexible
solutions that may be developed
for supporting customer processes
On system integration
Solution and
processes
Development
focus
Responsible for
System vendor
maintenance
Provides platform System vendor
for the system
25/09/2012
System owner
System owner
Lecture 4: Software reuse
50
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.
25/09/2012
Lecture 4: Software reuse
51
The architecture of an ERP system
A defined set of business
processes, associated
with each module, which
relate to activities in that
module.
A number of modules to support different
business functions.
A set of business rules
that apply to all data in the
database.
*
*A common database that maintains information
about all related business functions.
Source: Sommerville, I.,
Software Engineering, 9th ed.,
Addison Wesley, 2010.
25/09/2012
Lecture 4: Software reuse
52
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.
25/09/2012
Lecture 4: Software reuse
53
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?
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?
COTS products may include more functionality than
you need and functionality may be duplicated across
different products.
25/09/2012
Lecture 4: Software reuse
54
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.
*
* Build a wrapper
that hides the
application system
and provides
externally visible
services.
25/09/2012
Lecture 4: Software reuse
Source: Sommerville, I., Software
Engineering, 9th ed., Addison
Wesley, 2010.
55
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.
25/09/2012
Lecture 4: Software reuse
56
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.
25/09/2012
Lecture 4: Software reuse
57
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 largescale 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.
Open Source?
25/09/2012
Lecture 4: Software reuse
58
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
(http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/).
25/09/2012
Lecture 4: Software reuse
59