CIS224 Software Projects: Software Engineering and Research Methods

1
CIS224Software Projects Software Engineering
and Research Methods

• Lecture 10
• Reuse, Components, Patterns and Collaborations
• (Based on Stevens and Pooley, 2006, Chapter 18,
• Fowler 2004, Chapter 15)

David Meredith d.meredith_at_gold.ac.uk www.titanmus
ic.com/teaching/cis224-2006-7.html
2
Introduction

• Reuse covers any situation in which work done for
  one project is used to help another
• 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?

3
What can be reused?

• The following can be reused
• Architecture (including frameworks)
• Code (particularly, components)
• Designs or parts of a design (such as patterns)
• Documentation
• Tests
• 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)

4
How is reuse carried out?

• Cut and paste!
• Changes in the original dont get propagated to
  the copies
• Component reuse just about only area where reuse
  involves more than just cut-and-paste
• Reuse of class libraries in languages such as
  Java has grown rapidly over the past decade

5
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
• Rationals definition a component is a physical
  and replaceable part of a system that conforms to
  and provides the realization of a set of
  interfaces
• 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
  architecture

6
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

7
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 dont need to
  satisfy components context dependencies
• Leads to software bloat

8
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 supports
• 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

9
What about building your own components?

• 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 themselves
• Using components is easier, cheaper and more
  reliable than building them
• Benefits of component-based development arise
  from using components, not from building them

10
When can component-building be done?

• 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-to-long
  term, this makes good economic sense

11
What difference does object-orientation make?

• Object-orientation encourages high cohesion/low
  coupling style of programming which promotes
  reusability
• 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

12
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., Teenagers 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
  childs bedroom does not satisfy needs of family
  and teenager
• Solution is to have a teenagers 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 to find it yourself
  by perhaps constructing many suboptimal solutions

13
Design patterns

• Patterns document, at a suitable level of
  abstraction, designs that are effective,
  thoroughly tested and well understood
• Not only good for novices also good for
  experienced developers
• Having a clearly understood, named solutions to
  common problems
• 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

14
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.Addison-Wesley.
• Buschmann, F., Henney, K. and Schmidt, D. (2007).
  Pattern-oriented Software Architecture On
  Patterns and Pattern Languages. Wiley.

15
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 dont depend on structure of
  component. Structure of component can be changed
  without necessitating changes elsewhere in the
  system provided that Façade class is not changed.

16
Collaborations

• Patterns can be represented in UML using
  collaborations
• 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
  auction
• Whole collaboration enclosed in dashed ellipse
• Each square box represents a role (not a class
  note non-capitalized names)
• Diagram at bottom left shows use or occurrence of
  the Auction collaboration in the particular case
  of a house auction
• 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 classes that
  realize roles in collaboration are called role
  bindings

17
Representing patterns by collaborations

• 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 component
• 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 use
• 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

18
Summary

• 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
• Patterns
• Named, well-defined solution to a common problem