Lecture 10
Reuse, Components, Patterns and Collaborations
(Based on Stevens and Pooley, 2006, Chapter 18,
Fowler 2004, Chapter 15)
David Meredith
Software Projects: Software Engineering
and Research Methods
• Reuse covers any situation in which work
done for one project is used to help
• We address the following questions:
– What can be reused and how?
– Why reuse?
– Why is reuse hard?
– Which components are genuinely reusable?
– What about building your own components?
– What difference does object orientation make
to reuse?
What can be reused?
• The following can be reused
Architecture (including frameworks)
Code (particularly, components)
Designs or parts of a design (such as patterns)
• Other labour-saving techniques usually not
considered to be reuse. For example,
– Training a developer in a language for a project and
then using him/her in another project
– Tools that can be used to assist with several projects
(e.g., test harnesses, IDEs, debuggers)
How is reuse carried out?
• Cut and paste!
– Changes in the original don’t get propagated
to the copies
• Component reuse just about only area
where reuse involves more than just cutand-paste
• Reuse of class libraries in languages such
as Java has grown rapidly over the past
What is a component really?
• Defined component to be a reusable,
replaceable module that is a coherent
abstraction with a well-defined interface and low
coupling with the rest of the system
– This is a fairly broad definition
• Rational’s definition: a component is a physical
and replaceable part of a system that conforms
to and provides the realization of a set of
– “replaceable” here means replaceable at runtime
– Stevens and Pooley mean replaceable at
maintenance time
• More in line with definition of component in UML 2
• Component only replaceable within a particular
Why reuse?
• Developers’ time saved
– Using a pre-existing component saves on analysis,
design, reviews, documentation and testing
– If good solution developed once, then less
experienced developers can benefit from special
expertise of component developer
• Products can be more reliable because of
‘cumulative debugging’
• Speeds up development
• Promotes component-based development which
can lead to more reliable and more easily
maintained designs
Why is reuse hard?
• Finding the right component for the job is often
not easy – particularly if there are many
components to choose from
• May be tempted to adapt user requirements in
order to use existing components
• Component may not work properly
– Even if source is available, may be harder to debug
than your own code
• Component may not be well-documented
– Makes it hard to learn how to use the component
• May need to import things you don’t need to
satisfy component’s context dependencies
– Leads to “software bloat”
Which components are reusable?
• Component needs to be just general enough
– Larger the interface, longer it takes to learn how to use it
– More common for interface to be too large and complex than for
it to be too small and simple
• Component needs to be properly documented
– Specify interfaces and context dependencies
– Can provide use case diagram showing tasks that component
• Component must be especially thoroughly tested
– Developer of module may not be around to repair module when
bug found by client developer
– Component may be used in lots of different environments so
must be robust to changes provided that context dependencies
are satisfied and required interfaces are provided
What about building your own
• Making a reusable component is usually harder and takes longer
than making a module for one-off use
– Have to make the component more robust to changes in the
environment in which it will be used
• Implies more thorough testing
– Have to document the component more thoroughly so that it can be
maintained by someone other than the developer
• No guarantee that a component that is designed to be reused
actually will be
• Long-established tradition in software that people prefer to build new
things than use what already exists
– Leads to immense amount of duplication of effort and “reinvention”
• Must change culture so that people are encouraged to look hard for
existing components that do the job before trying to build them
– Using components is easier, cheaper and more reliable than
building them
• Benefits of component-based development arise from using
components, not from building them
When can component-building be
• In a commercial environment where goal
is to develop and market a product, hard
to find extra time required to make
component reusable
• Company has to adopt culture of investing
time and manpower into making the
modules it makes reusable
– Need to convince people that, in the mid-tolong term, this makes good economic sense
What difference does objectorientation make?
• Object-orientation encourages high cohesion/low
coupling style of programming which promotes
• OO analysis focuses on determining suitable classes of
domain objects which probably do not need to change
very much over time and so can therefore be reused in
different applications in the domain
• Domain objects tend to recur in different contexts and so
make good reuse candidates
• In OO, a class can be reused as the base class of a new
more specialized subclass
– Can adopt the “Open-Closed Rule”: develop classes that are
coherent and encapsulated (closed) and extensible through
specialization (open)
– However, inheritance not always a good thing
• Creates strong coupling – subclass depends on base class
• Does not reduce amount of testing required on new subclass
Design patterns
• A pattern is a named, well-defined, good solution to a problem that
is common within a particular context
• Concept of a design pattern originally developed in architecture by
Alexander, Ishikawa, & Silverstein (1977) in their book, A Pattern
Language, (OUP)
• Alexander et al. proposed 253 patterns, each solving a common
problem in architecture, construction and urban planning
– e.g., “Teenager’s Cottage”
• Aims to solve problem that a teenager and his/her family need to be
mutually supportive, whilst teenager becomes more independent
• Static architecture that keeps teenager in a child’s bedroom does not satisfy
needs of family and teenager
• Solution is to have a “teenager’s cottage” which is strongly attached to main
home but has its own entrance.
– Alexander describes several variant solutions with diagrams
– Discusses objections such as that cottage becomes useless after teenager has
grown up
» Possibly solved by using cottage as an office or study
• A very similar situation arises in software engineering
– Certain basic design problems recur again and again
• Instead of solving same problem again and again from scratch, accumulate
knowledge of best solutions and reuse these solutions
• Allows novices to learn by example and become experts more quickly
• Allows you to build the best, known solution straight away without having to12
find it yourself by perhaps constructing many suboptimal solutions
Design patterns
• Patterns document, at a suitable level of abstraction,
designs that are effective, thoroughly tested and well
• Not only good for novices – also good for experienced
– Having a clearly understood, named solutions to common
• Makes it easier to discuss designs
• Allows for more structured research programmes that aim to
improve the solutions
• Helps us to have a clear idea of what the state of the art is
• Pattern should achieve just the right level of abstraction
– Too abstract – hard to implement, platitudinous
– Too concrete – not applicable in a wide range of situations
Format of a pattern catalogue
• Certain information should be provided for each pattern:
– Name (and possibily aliases)
– Abstract – brief description of pattern in about 3 sentences
– Context – brief description of the class of situations in which the pattern
can be applied
– Problem that pattern solves; usually describes conflicting forces to be
satisfied, requirements and constraints
– Solution – explanatory text, models, CRC cards, etc.
– Variants and related patterns – including patterns used in this pattern,
variant solutions
– Examples of implementations of the pattern
– Consequences of using the pattern
• Books on patterns
– Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995). Design
Patterns: Elements of Reusable Object-Oriented Software.AddisonWesley.
– Buschmann, F., Henney, K. and Schmidt, D. (2007). Pattern-oriented
Software Architecture: On Patterns and Pattern Languages. Wiley.
An example pattern: Façade
• Name Façade
• Abstract Façade defines a clean, high-level interface to a
component, hiding its structure to make it easier to use
• Context Building easy-to-use components
• Problem If a component consists of many related classes,
developer must understand much about structure of
component in order to use it. Changes in structure of
component may also necessitate changes in its clients.
• Solution Add Façade class which provides single, unified
interface to component. All messages to the component are
received by the Façade class which forwards the messages
to the appropriate classes within the component. No class
within the component depends on the Façade class. All
classes apart from Façade class should be hidden inside
the component.
• Consequences Clients don’t depend on structure of
component. Structure of component can be changed without
necessitating changes elsewhere in the system provided 15
that Façade class is not changed.
• Patterns can be represented in UML using
• Collaboration describes structure of
collaborating elements (roles) which
collectively accomplish a particular task
• Collaboration at top left represents the roles
that have to be played by objects in a typical
A u c tio n
b u ye r
o ffe r
s e lle r
lo t
c ollaboration
– Whole collaboration enclosed in dashed
– Each square box represents a role (not a
class – note non-capitalized names)
c ollaboration us e
A u c tio n
• Diagram at bottom left shows use or
occurrence of the Auction collaboration in
the particular case of a house auction
role binding
o ffe r
b u ye r, s e lle r
B id
lo t
b u ye r
P a rty
s e lle r
– An object of the Bid class fulfils the role of
offer in the Auction collaboration
– Objects of the Party class fulfil the roles of
buyer and seller in the Auction collaboration
– Object of class House fulfils role of lot in
Auction collaboration
• Links between collaboration icon and
16 are
classes that realize roles in collaboration
called role bindings
Representing patterns by collaborations
fa c a d e
s u b s ys te m
c la s s 1
s u b s ys te m
c la s s 3
s u b s ys te m
c la s s 2
F ac ade
s ubs ys tem c las s
fac ade
B ook
s ubs ys tem c las s
J ournal
C opy
M em berO fS taff
LibraryM em ber
• An OO system that uses a pattern will
contain a family of objects that are
bound to the roles in the pattern
– e.g., component that uses Façade pattern
will contain object bound to façade role
• facade object receives messages sent to
the component and forwards them to the
appropriate subsystem classes within
• Subsystem classes navigable from the
façade class but not vice versa
• Pattern represented by collaboration
• Application of a pattern in a particular
system represented by collaboration
– e.g., if other library systems need to
access library system, could provide
access to information on Books and
Journals held by library via a façade class,
Library, associated with the Book and
Journal classes within the Library system
What can be reused?
– Architecture, code, patterns, documentation, tests
How is reuse carried out?
– Cut and paste, components, class libraries
What is a component?
– Reusable, replaceable, coherent module with good interface and low coupling
Why reuse?
– Saves development time, improves reliability and maintainability
Why is reuse hard?
– Sometimes hard to find appropriate, reliable component
What makes a component reusable?
– Just general enough, properly documented, thoroughly tested
Always use components if you can rather than build them yourself
What difference does OO make to reuse?
– OO encourages high cohesion/low coupling programming style
– OO encourages modelling stable domain objects
– inheritance allows adoption of "Open-Closed" Rule
– Named, well-defined solution to a common problem
– Avoids reinvention of best solutions
– Using collaborations to represent patterns in UML

CIS224 Software Projects: Software Engineering and