Software Reuse

z Building software from

reusable components

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 1

Software Reuse
z In most engineering disciplines, systems are
designed by composing existing components that
have been used in other systems.
z Software engineering has been more focused on
original development but it is now recognised
that to achieve better software, more quickly and
at lower cost, we need to adopt a design process
that is based on systematic reuse.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 2

Benefits of Reuse
z Increased reliability
– Components exercised in working systems
z Reduced process risk
– Less uncertainty in development costs
z Effective use of specialists
– Reuse components instead of people
z Standards compliance
– Embed standards in reusable components
z Accelerated development
– Avoid original development and hence speed-up production

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 3
 Reusable Component Types
z Application system reuse
– The whole of an application system may be reused on a
different machine. Usually referred to as program
portability.
z Sub-system reuse
– Major sub-systems such as a pattern-matching system may
be reused.
z Modules or object reuse
– The reusable component is a collection of functions or
procedures.
z Function reuse
– The reusable component is a single function.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 4

Reuse Practice
z Application system reuse
– Widespread. It is common practice for developers of systems
(e.g., Microsoft) to make their products available on several
platforms.
z Sub-system and module reuse
– Practiced informally in that individual engineers reuse previous
work. Little systematic reuse but increasing reuse awareness.
z Function reuse
– Common in some application domains (e.g., engineering) where
domain-specific libraries of reusable functions have been
established. Reuse is the principal reason why languages such as
FORTRAN are still used.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 5

Four Aspects of Reuse

z Software development with reuse
– Developing software given a base of reusable components.
z Software development for reuse
– How to design generic software components for reuse.
z Generator-based reuse
– Domain-specific reuse through application generation.
z Application system reuse
– How to write application systems so that they may be
readily ported from one platform to another.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 6
Software Development with Reuse
z Attempts to maximize the use of existing
components.
z These components may have to be adapted in
a new application.
z Fewer components need be specified, designed
and coded.
z Overall development costs should therefore be
reduced.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 7

Further Advantages
z System reliability is increased.
z Overall risk is reduced.
z Effective use can be made of specialists.
z Organizational standards can be embodied in
reusable components.
z Software development time can be reduced.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 8

Development with Reuse Process

Design Search for Incorporate

Specify
system reusable discovered
components
aachitecture components components

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 9
 Requirements for Reuse
z It must be possible to find appropriate reusable
components in a component data base.
z Component re-users must be able to understand
components and must have confidence that they
will meet their needs.
z The components must have associated
documentation discussing HOW they can be
reused and the potential costs of reuse.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 10

Reuse-driven Development
z Rather than reuse being considered after the
software has been specified, the specification
takes into account the existence of reusable
components.
z This approach is commonplace in the design of
electronic, electrical and mechanical systems.
z If adopted for software, should significantly
increase the proportion of components reused.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 11

Reuse-driven Development
Modify requirements
Outline Search for
according to
system reusable
discovered
requirements components
components

Specify system
Search for components
Architectural
reusable based on reusable
design
components components

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 12
 Reuse Problems
z Difficult to quantify costs and benefits of
development with reuse.
z CASE tool sets do not support development
with reuse. They cannot be integrated with a
component library systems.
z Some software engineers prefer to rewrite
rather than reuse components.
z Current techniques for component classification,
cataloging and retrieval are immature. The cost of
finding suitable components is high.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 13

Software Development for Reuse

z Software components are not automatically
reusable. They must be modified to make them
usable across a range of applications.
z Software development for reuse is a development
process which takes existing components and
aims to generalize and document them for reuse
across a range of applications.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 14

Development for Reuse

z The development cost of reusable components is
higher than the cost of specific equivalents.
z This extra reusability enhancement cost should be
an organization rather than a project cost
z Generic components may be less space-efficient
and may have longer execution times than their
specific equivalents.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 15
 Reusability Enhancement
z Name generalization
– Names in a component may be modified so that they are not a
direct reflection of a specific application entity.
z Operation generalization
– Operations may be added to provide extra functionality and
application specific operations may be removed.
z Exception generalization
– Application specific exceptions are removed and exception
management added to increase the robustness of the component.
z Component certification
– Component is certified as reusable.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 16

Domain-specific Reuse
z Components can mostly be reused in the
application domain for which they were
originally developed as they reflect domain
concepts and relationships.
z Domain analysis is concerned with studying
domains to discover their elementary
characteristics.
z With this knowledge, components can be
generalized for reuse in that domain.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 17

Domain-specific Reuse
z Reusable components should encapsulate a
domain abstraction.
z The abstraction must be parameterized to allow
for instantiation in different systems with specific
requirements.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 18
The Abstract Data Structures Domain
z Well-understood application domain.
z Important as a foundation for many types of
software system.
z The requirements for reusable abstract data
structures have been published by several
authors (e.g., Booch).
z A classification scheme for such components
has been invented.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 19

ADS generalization
z Involves adding operations to a component to
ensure domain coverage.
z Operations required include:
– Access operations
– Constructor operations
– I/O operations
– Comparison operations
– Iterator operations, if the component is a collection of
components

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 20

Model of a Reusable ADS

Exported type
I/O operations
names

Access Abstract data Iterator

operations structure operations

Constructor Comparison
operations operations

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 21
 Reuse Guidelines
z Implement data structures as generic
packages.
z Provide operations to create and assign
instances.
z Provide a mechanism to indicate whether or not
operations have been successful.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 22

Reuse Guidelines
z Implement operations which can fail as
procedures and return an error indicator as an
out parameter.
z Provide an equality operation to compare
structures.
z Provide an iterator which allows each element
in a collection to be visited efficiently without
modification to that element.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 23

Reusable Component Example

z Linked list of elements where each element
maintains a pointer to the next element in the list.
z Commonly implemented in application systems
but application-specific components are rarely
generic as their operations reflect specific
application needs.
z Linked list operations are usually independent of
the type of element in the list.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 24
C++ template <class elem> class List
{
public:

Linked List List();

~List();
// Automatic constructor
// Automatic destructor
// Basic list operations
elem Head (error_indic &Err) ;
int Length ( ) ;
List <elem> Tail (error_indic &Err) ;
// Equality operations
friend List <elem> operator == (List <elem> L1, List <elem> L2) ;
friend List <elem> Equivalent (List <elem> L1, List <elem> L2) ;
// Constructor operations for linked list
void Append (elem E, error_indic &Err) ;
void Add (elem E, error_indic &Err) ;
void Add_before (elem E, error_indic &Err) ;
void Add_after (elem E, error_indic &Err) ;
void Replace (elem E, error_indic &Err) ;
void Clear (error_indic &Err ) ;
void Prune (error_indic &Err ) ;
void Prune_to (elem E, error_indic &Err ) ;
void Prune_from (elem E, error_indic &Err ) ;
void Remove (elem E, error_indic &Err ) ;
void Remove_before (elem E, error_indic &Err ) ;
void Remove_after (elem E, error_indic &Err ) ;

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 25

C++
// I/O functions
void Print(error_indic &Err) ;
void Write_list(char* filename, error_indic &Err) ;

Linked List void Read_list(char* filename, error_indic &Err) ;

private:
typedef struct Linkedlist {
elem val;
Linkedlist* next;
} Linkedlist;

Linkedlist* Listhead ; // (Internal) Pointer to start of list

};

template <class elem> class Iterator {

friend class List <elem> ;
public:
Iterator () ;
~Iterator () ;
void Create (List <elem> L, error_indic &Err) ;
void Go_next (error_indic &Err) ;
elem Eval (error_indic &Err) ;
boolean At_end () ;
private:
Linkedlist* iter ;
};

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 26

Language-dependent Reuse
z Reuse guidelines for domain abstractions are
independent of the implementation language.
z Some reuse guidelines may be language
independent.
– In C++, always pass the array size as a parameter to reusable
components which operate on arrays.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 27
 Component Adaptation
z Extra functionality may have to be added to a
component. When this has been added, the new
component may be made available for reuse.
z Unneeded functionality may be removed from a
component to improve its performance or reduce
its space requirements.
z The implementation of some component
operations may have to be modified. This
suggests that the original generalization decisions
may be incorrect.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 28

Reuse and Inheritance

z Objects are inherently reusable because they
package state and associated operations. they
can be self-contained with no external
dependencies.
z Inheritance means that a class inherits
attributes and operations from a super-class.
Essentially, these are being reused.
z Multiple inheritance allows several objects to
act as a base class so attributes and operations
from several sources are reused.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 29

A Class Lattice
Attributes and
operations reused by
Peripheral inheritance down the
hierarchy

Storage Output Input

Text Position
Tape Disk Printer Screen
input sensor

Dot-matrix Laser Film Ink-jet

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 30
 Problems with Inheritance
z As component classes are developed, the
inheritance lattice becomes very complex with
duplications across the lattice.
z To understand a component, many classes in
the hierarchy may have to be examined and
understood.
z In many cases, it may be impossible to avoid
inheriting unneeded functionality.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 31

Generator-based Reuse
z Program generators involve the reuse of
standard patterns and algorithms.
z These are embedded in the generator and
parameterized by user commands. A program is
then automatically generated.
z Compilers are program generators where the
reusable patterns are object code fragments
corresponding to high-level language commands.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 32

Reuse Through Program Generation

Application Program generator Generated program

description

Application domain
Database
knowledge

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 33
 Types of Program Generator
z Types of program generator
– Application generators for business data processing.
– Parser and lexical analyzer generators for language processing.
– Code generators in CASE tools.
z Generator-based reuse is very cost-effective but
its applicability is limited to a relatively small
number of application domains.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 34

Application System Portability

z Portability is a special case of reuse where an
entire application is reused on a different
platform.
z The portability of a program is a measure of the
amount of work required to make that program
work in a new environment.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 35

Application Program Interfaces (APIs)

Libraries

Run-time Application Operating

system program system

Memory and CPU

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 36
 Portability Dependencies
z Operating system dependencies
– Dependencies on operating system characteristics.
z Run-time system problems
– Dependencies on a particular run-time support system.
z Library problems
– Dependencies on a specific set of libraries.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 37

Development for Portability

z Isolate parts of the system which are
dependent on the external program interfaces.
z Define a portability interface to hide operating
system characteristics.
z To port the program, only the code behind the
portability interface need be rewritten.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 38

A Portability Interface
Application system

Portability interface

Data Operating system

references and I/O calls

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 39
 Operating System Dependencies
z The program relies on the use of specific
operating system calls such as facilities to support
process management.
z The program depends on a specific file system
organization supported by the operating system.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 40

Portability Interface Implementation

Application

Abstract data type interface

OR

Unix filestore Database system

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 41

Standards
z Standards are an agreement across the
community which reduces the amount of
variability in software systems.
z The development of standards in the 1980s
means that program portability is now much
simpler than before.
z In principle, as standards are further
developed, heterogeneous systems may be
developed where parts of a program may run
on completely different machines.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 42
 Existing Standards
z Programming language standards
– Ada, Pascal, C, C++, FORTRAN.
z Operating system standards
– UNIX, MS Windows (de-facto standard).
z Networking standards
– TCP/IP protocols, X400, X500, Sun NFS, OSI layered
model, HTML, WWW.
z Window system standards
– X-windows, Motif tool kit.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 43

Component-based Development
z Component-based software engineering (CBSE)
is an approach to software development that
relies on reuse.
z It emerged from the failure of object-oriented
development to support effective reuse. Single
object classes are too detailed and specific.
z Components are more abstract than object classes
and can be considered to be stand-alone service
providers.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 44

Components
z Components provide a service without regard to
where the component is executing or its
programming language.
– A component is an independent executable entity that can be
made up of one or more executable objects.
– The component interface is published and all interactions are
through the published interface.
z Components can range in size from simple
functions to entire application systems.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 45
 Component Interfaces

Requires interface Component Provides interface

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 46

Component Interfaces
z Provides interface
– Defines the services that are provided by the component to other
components
z Requires interface
– Defines the services that specifies what services must be made
available for the component to execute as specified

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 47

Printing Services Component

Requires interface PrintService Provides interface

GetPDfile Print
GetQueue
PrinterInt Remove
Transfer
Register
Unregister

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 48
 Component Abstractions
z Functional abstraction
– The component implements a single function such as a mathematical function
z Casual groupings
– The component is a collection of loosely related entities that might be data
declarations, functions, etc.
z Data abstractions
– The component represents a data abstraction or class in an object-oriented
language
z Cluster abstractions
– The component is a group of related classes that work together
z System abstraction
– The component is an entire self-contained system

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 49

CBSE Processes
z Component-based development can be integrated
into a standard software process by incorporating
a reuse activity in the process.
z However, in reuse-driven development, the
system requirements are modified to reflect the
components that are available.
z CBSE usually involves a prototyping or an
incremental development process with
components being ‘glued together’ using a
scripting language.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 50

CBSE Problems
z Component incompatibilities may mean that cost
and schedule savings are less then expected.
z Finding and understanding components.
z Managing evolution as requirements change in
situations where it may be impossible to change
the system components.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 51
 Application Frameworks
z Frameworks are a sub-system design made up of
a collection of abstract and concrete classes and
the interfaces between them.
z The sub-system is implemented by adding
components to fill in parts of the design and by
instantiating the abstract classes in the
framework.
z Frameworks are moderately large entities that can
be reused.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 52

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

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 53

Extending Frameworks
z Frameworks are generic and are extended to
create a more specific application or sub-system.
z 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
z Problem with frameworks is their complexity and
the time it takes to use them effectively.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 54
 Model-view Controller
z System infrastructure framework for GUI design
z Allows for multiple presentations of an object
and separate interactions with these presentations
z MVC framework involves the instantiation of a
number of patterns (discussed later)

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 55

Model-view Controller

View state view modification Controller state

messages User inputs
View methods Controller methods

Model queries
and updates Model edits
Model state

Model methods

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 56

COTS Product Reuse

z COTS - Commercial Off-The-Shelf systems.
z COTS systems are usually complete application
systems that offer an API (Application
Programming Interface).
z Building large systems by integrating COTS
systems is now a viable development strategy for
some types of system such as E-commerce
systems.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 57
 COTS System Integration Problems
z Lack of control over functionality and performance
– COTS systems may be less effective than they appear
z Problems with COTS system inter-operability
– Different COTS systems may make different assumptions that means
integration is difficult
z No control over system evolution
– COTS vendors not system users control evolution
z Support from COTS vendors
– COTS vendors may not offer support over the lifetime of the product

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 58

OOD Patterns Topics

z Terminology and Motivation
z Reusable OO Design Patterns:
– Adapter
– Facade
– Iterator
– Composite
– Template
– Abstract Factory
– Observer
– Master-Slave

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 59

Design Patterns
z Good designers know not to solve every problem
from first principles. They reuse solutions.
z Practitioners do not do a good job of recording
experience in software design for others to use.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 60
 Design Patterns (Cont’d)
z A Design Pattern systematically names,
explains, and evaluates an important and
recurring design.
z We describe a set of well-engineered design
patterns that practitioners can apply when crafting
their applications.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 61

Becoming a Master Designer

z First, One Must Learn the Rules:
– Algorithms
– Data Structures
– Languages
z Later, One Must Learn the Principles:
– Structured Programming
– Modular Programming
– OO Programming

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 62

Becoming a
Master Designer (Cont’d)
z Finally, One Must Study the Designs of Other
Masters:
– Design patterns must be understood, memorized, and applied.
– There are thousands of existing design patterns.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 63
 The Adapter Pattern
z Intent: Convert the interface of a class into
another interface clients expect. Adapter lets
classes work together that couldn’t otherwise
because of incompatible interfaces.
z Motivation: When we want to reuse classes in an
application that expects classes with a different
interface, we do not want (and often cannot) to
change the reusable classes to suit our application.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 64

Example of the Adapter Pattern

Shape TextView
Editor
BoundingBox() GetExtent()
CreateManipulator()

text

LineShape TextShape
BoundingBox() BoundingBox() return text -> GetExtent()
CreateManipulator() CreateManipulator()
return new Text Manipulator

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 65

Structure of the Adapter Pattern

Using Multiple Inheritance
Target Adaptee
Client
Request() SpecificRequest()

(implementation)

Adapter
Request() SpecificRequest()

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 66
 Structure of the Adapter Pattern
Using Object Composition
Target Adaptee
Client
Request() SpecificRequest()

adaptee

Adapter
Request() SpecificRequest()

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 67

Participants of the
Adapter Pattern
z Target: Defines the application-specific interface
that clients use.
z Client: Collaborates with objects conforming to
the target interface.
z Adaptee: Defines an existing interface that needs
adapting.
z Adapter: Adapts the interface of the adaptee to
the target interface.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 68

The Facade Pattern (Intent)

z Provide a unified interface to a set of interfaces in
a subsystem. Facade defines a higher-level
interface that makes the subsystem easier to use.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 69
 The Facade Pattern (Motivation)
z Structuring a system into subsystems helps
reduce complexity.
z A common design goal is to minimize the
communication and dependencies between
subsystems.
z Use a facade object to provide a single, simplified
interface to the more general facilities of a
subsystem.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 70

Example of the Facade Pattern

Compiler
Compile()

Scanner Token

CodeGenerator Parser

ProgNodeBuilder
RISCCG
ProgNode
StackMachineCG

Statement Node

Expression Node

Compiler Subsystem Classes Variable Node

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 71

Structure of the Facade Pattern

Client Classes

Facade

Subsystem Classes
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 72
 Participants of the
Facade Pattern
z Facade:
– Knows which subsystem classes are responsible for a request.
– Delegates client requests to appropriate subsystem objects.
z Subsystem Classes:
– Implement subsystem functionality.
– Handle work assigned by the facade object.
– Have no knowledge of the facade; that is, they keep no
references to it.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 73

The Iterator Pattern (Intent)

z Provide a way to access the elements of an
aggregate object sequentially without exposing its
underlying representation.
z Move the responsibility for access and traversal
from the aggregate object to the iterator object.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 74

The Iterator Pattern (Motivation)

z One might want to traverse an aggregate object in
different ways.
z One might want to have more than one traversal
pending on the same aggregate object.
z Not all types of traversals can be anticipated a
priori.
z One should not bloat the interface of the
aggregate object with all these traversals.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 75
 Example of the Iterator Pattern

list
List ListIterator
Count()
First()
Append(Element)
Next()
Remove(Element)
IsDone()
…
CurrentItem()

index

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 76

Structure of the Iterator Pattern

Aggregate Iterator
CreateIterator() First()
Next()
IsDone()
CurrentItem()

ConcreteAggregate
CreateIterator() ConcreteIterator

return new ConcreteIterator(this)

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 77

Participants of the
Iterator Pattern
z Iterator: Defines an interface for accessing and
traversing elements.
z Concrete Iterator: Implements an iterator
interface and keeps track of the current position in
the traversal of the aggregate.
z Aggregate: Defines an interface for creating an
iterator object.
z Concrete Aggregate: Implements the iterator
creation interface to return an instance of the
proper concrete iterator.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 78
 The Composite Pattern (Intent)
z Compose objects into tree structures to represent
part-whole hierarchies.
z Composite lets clients treat individual objects and
compositions of objects uniformly.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 79

The Composite Pattern

(Motivation)
z If the composite pattern is not used, client code
must treat primitive and container classes
differently, making the application more complex
than is necessary.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 80

Example of the
Composite Pattern
Graphic
Draw()
Add(Graphic)
Remove(Graphic)
GetChild(int)

graphics
Line Rect. Text Picture
Draw()
Draw() Draw() Draw()
Add(Graphic)
Remove(Graphic)
GetChild(int)

forall g in graphics
g.Draw()

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 81
 Structure of the
Composite Pattern
Client

Component
Operation()
Add(Component)
Remove(Component)
GetChild(int)

children
Leaf Composite
forall g in children
Operation()
Operation() g.Operation()
Add(Component)
Remove(Component)
GetChild(int)

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 82

Participants of
Composite Pattern
z Component:
– Declares the interface for objects in the composition.
– Implements default behavior for the interface common to all
classes.
– Declares an interface for accessing and managing its child
components.
– Defines an interface for accessing a component’s parent in the
recursive structure (optional).

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 83

Participants of
Composite Pattern (Cont’d)
z Leaf:
– Represents leaf objects in the composition. A leaf has no children.
– Defines behavior for primitive objects in the composition.
z Composite:
– Defines behavior for components having children.
– Stores child components.
– Implements child-related operations in the component interface.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 84
 Participants of
Composite Pattern (Cont’d)
z Client:
– Manipulates objects in the composition through the component
interface.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 85

The Template Pattern (Intent)

z Define the skeleton of an algorithm in an
operation, deferring some steps to subclasses.
z The Template Method lets subclasses redefine
certain steps of an algorithm without changing
the algorithm’s structure.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 86

The Template Pattern

(Motivation)
z By defining some of the steps of an algorithm,
using abstract operations, the template method
fixes their ordering.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 87
 Structure of the Template Pattern
AbstractClass ...
TemplateMethod() PrimitiveOp1()
PrimitiveOp1() PrimitiveOp2()
PrimitiveOp2() ...

ConcreteClass
PrimitiveOp1()
PrimitiveOp2()

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 88

Structure of the Template Pattern

z Abstract Class:
– Defines abstract primitive operations that concrete subclasses
define to implement steps of an algorithm.
– Implements a template method defining the skeleton of an
algorithm. The template method calls primitive operations as
well as operations defined in Abstract Class or those of other
objects.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 89

Structure of the
Template Pattern (Cont’d)
z Concrete Class: Implements the primitive
operations to carry out subclass-specific steps to
the algorithm.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 90
 The Abstract Factory Pattern
(Intent)
z Provides an interface for creating families of
related or dependent objects without specifying
their concrete classes.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 91

The Abstract Factory Pattern

(Behavior)
z Sometimes we have systems that support
different representations depending on external
factors.
z There is an Abstract Factory that provides an
interface for the client. In this way the client can
obtain a specific object through this abstract
interface.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 92

Example of the
Abstract Factory Pattern
WidgetFactory Client
CreateScrollBar()
Create Window()

Window

MotifWidgetFactory PMWidgetFactory PMWindow MotifWindow

CreateScrollBar() CreateScrollBar()
Create Window() Create Window()

ScrollBar

PMScrollBar MotifScrollBar

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 93
 Structure of the
Abstract Factory Pattern
AbstractFactory Client
CreateProductA()
CreateProductB()

AbstractProductA

ConcreteFactory1 ConcreteFactory2 ProductA1 ProductA2

CreateProductA() CreateProductA()
CreateProductB() CreateProductB()

AbstractProductB

ProductB1 ProductB2

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 94

Participants of the
Abstract Factory Pattern
z Abstract Factory:
– Declares an interface for operations that create abstract product
objects.
z Concrete Factory:
– Implements the operations to create concrete product objects.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 95

Participants of the Abstract

Factory Pattern (Cont’d)
z Abstract Product:
– Declares an interface for a type of product object.
z Concrete Product:
– Defines a product object to be declared by the corresponding
concrete factory. (Implements the Abstract Product interface).
z Client:
– Uses only interfaces declared by Abstract Factory and Abstract
Product classes.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 96
 The Observer Pattern (Intent)
z Define a one-to-many dependency between
objects so that when one object changes state, all
its dependents are notified and updated
automatically.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 97

The Observer Pattern

(Motivation)
z A common side-effect of partitioning a system
into a collection of cooperating classes is the need
to maintain consistency between related objects.
z You don’t want to achieve consistency by making
the classes tightly coupled, because that reduces
their reusability.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 98

Example of the Observer Pattern

a b c b
x 6030 10
y 503020 a c
z 8010 10 a b c

a = 50%
b = 30%
c = 20%

requests, modifications change notification

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 99
 Structure of the Observer Pattern
observers
Subject Observer
Attach(Observer)
Detach(Observer)
Update()
for all o in
Notify()
observers {
o -> Update()}

ConcreteObserver
observerState =
Update()
subject subject->GetState()
ConcreteSubject observerState
GetState()
SetState()
return subjectState
subjectState

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 100

Structure of the Observer Pattern

z The key objects in this pattern are subject and
observer.
– A subject may have any number of dependent observers.
– All observers are notified whenever the subject undergoes a
change in state.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 101

Participants of the
Observer Pattern
z Subject:
– Knows its numerous observers.
– Provides an interface for attaching and detaching observer
objects.
– Sends a notification to its observers when its state changes.
z Observer:
– Defines an updating interface for concrete observers.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 102
 Participants of the
Observer Pattern (Cont’d)
z Concrete Subject:
– Stores state of interest to concrete observers.
z Concrete Observer:
– Maintains a reference to a concrete subject object.
– Stores state that should stay consistent with the subject's.
– Implements the updating interface.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 103

The Master-Slave Pattern (Intent)

z Handles the computation of replicated services
within a software system to achieve fault
tolerance and robustness.
z Independent components providing the same
service (slaves) are separated from a component
(master) responsible for invoking them and for
selecting a particular result from the results
returned by the slaves.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 104

The Master-Slave Pattern

(Motivation)
z Fault tolerance is a critical factor in many
systems.
z Replication of services and delegation of the
same task to several independent suppliers is a
common strategy to handle such cases.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 105
 Example of the M/S Pattern
Slave1

RadLevel()

NuclearPP Voter Slave2

acceptableRL() RadLevel()
RadLevel()

return max(
Slave3
slave1->RadLevel(),
slave2->RadLevel(),
RadLevel()
slave3->RadLevel())

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 106

Structure of the M/S Pattern

Slave1

ServiceImp1()
forward
request

Client Master forward

Slave2
request
Compute() service()
ServiceImp1()
request
service
forward
request
Slave3

ServiceImp1()

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 107

Participants of the M/S Pattern

z Slave:
– Implements a service.
z Master:
– Organizes the invocation of replicated services.
– Decides which of the results returned by its slaves is to be
passed to its clients.
z Client:
– Requires a certain service in order to solve its own task.

©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 14 Slide 108