CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.1
Software Engineering: Analysis and Design - CSE3308
Patterns
CSE3308/CSC3080/DMS/2000/12
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.2
Lecture Outline
What is a Pattern?
Design Patterns
Abstract Factory
Observer
Analysis Patterns
Accountability
Further Information
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.3
What is a Pattern?
Inspired by the work of Christopher Alexander, who first described patterns in Architecture
“Each pattern describes a problem which occurs over and over again in our environment, then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”
“An idea that has been useful in one practical context and will probably be useful in others”
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.4
Design Patterns
Design Patterns: Elements of Reusable Object-Oriented Software (1995)
Erich Gamma Richard Helm Ralph Johnson John Vlissides a.k.a. The Gang of Four
Used object modelling techniques to represent common solutions to problems in the design of OO software, taken from multiple actual systems
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.5
A Design Pattern is SMART - an elegant solution not obvious to a novice GENERIC - not dependent upon a system,
programming language or application domain WELL-PROVEN - has been identified from real OO
systems SIMPLE - is usually quite small, involving only a
handful of classes REUSABLE - is documented in such a fashion that it
is easy to reuse OBJECT-ORIENTED - built with OO mechanisms
such as classes, objects, generalization and polymorphism
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.6
A Design Pattern has
a Pattern Name - a handle we can use to describe a design problem, its solutions and consequences
the Problem - describes when to apply the pattern. It explains the problem and its context
the Solution - describes the elements which make up the solution and their relationships
the Consequences - the results and trade-offs of using the design pattern
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.7
Categorising Design Patterns
Purpose Creational - concern the process of object creation Structural - deal with the composition of classes and
objects Behavioural - characterise the way in which classes or
objects interact and distribute responsibility
Scope Class - the pattern is primarily concerned with classes,
they deal with the relationships between classes and their sub-classes. Established through Inheritance and are static.
Object - the pattern is primarily concerned with object relationships which are more dynamic and can change at run-time
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.8
Abstract Factory
Provides an interface for creating families of related or dependent objects without specifying their concrete classes
Abstract Factory has Purpose - Creational Scope - Object
Example - want to have multiple look and feels for different standards, e.g. Win 95 and Win 3.11
Need to avoid hardcoding the widgets that make up the interface
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.9
Abstract Factory Example
CreateScrollBar()CreateWindow()
CreateScrollBar()CreateWindow()
CreateScrollBar()CreateWindow()
Client
Window
Win 3.11Window
Win 95 Window
ScrollBar
Win 3.11ScrollBar
Win 95ScrollBar
WidgetFactory
Win95WidgetFactory Win311WidgetFactory
creates
creates
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.10
Applicability Use Abstract Factory in the following situations: a system should be independent of how its
products are created, composed and represented
A system should be configurable with multiple families of products
A family of related product objects is designed to be used together, and you need to enforce this constraint
You want to provide a a class library of products, and you want to reveal only interfaces and not implementations
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.11
The Structure of Abstract Factory
CreateProductA()CreateProductB()
CreateProductA()CreateProductB()
CreateProductA()CreateProductB()
Client
AbstractProductA
ProductA1ProductA2
Abstract ProductB
ProductB3ProductB2
AbstractFactory
ConcreteFactory1 ConcreteFactory2
creates
creates
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.12
Participants AbstractFactory - declares an interface for
operations that create abstract product objects ConcreteFactory - implements the operations to
create concrete product objects AbstractProduct - declares an interface for a
type of product object ConcreteProduct - defines a product object to be
created by the corresponding concrete factory and implements the AbstractProduct interface
Client - uses only interfaces declared by AbstractFactory and AbstractProduct classes
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.13
Consequences
It isolates concrete classes isolates clients from implementation classes clients manipulate instances through their abstract
interface product class names are isolated in the implementation
of the concrete factory; they do not appear in client code
It makes exchanging product families easy The class of a concrete factory appears only once in the
application, i.e. where it’s instantiated Use different product configurations simply by changing
the concrete factory
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.14
Consequences (2)
It promotes consistency among products When product objects in a family are designed to work
together, it’s important to use only one family at a time Abstract factory makes this constraint easy to implement
Supporting new kinds of products is difficult Abstract Factory fixes the set of products which can be
created To extend the products, means that the Abstract Factory
interface must be changed and all the Concrete Factory subclasses must be changed as well
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.15
Observer Defines a one-to-many dependency between
objects so that when one object changes state, all its dependents are notified and updated automatically
Observer has Purpose - Behavioural Scope - Objects
Example - different views of data in a spreadsheet.
Table view Bar graph view Pie chart view
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.16
Example
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.17
Applicability Use Observer in the following situations: When an abstraction has two aspects, one
dependent upon the other. Encapsulating these aspects in separate objects lets you vary and reuse then independently
When a change to one object requires changing others, and you don’t know how many objects need to be changed
When an object should be able to notify other objects without making assumptions about what these objects are, i.e. you don’t want them tightly coupled
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.18
The Structure of Observer
Get State()SetState()
Update()
Update()
Subject
ConcreteSubject
Observer
ConcreteObserver
*
subject
Attach(Observer)Detach(Observer)Notify() For all o in
observers{ o->Update() }
observers
subjectState Return subjectState
observerState
observerState =subject -> GetState()
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.19
Participants Subject
Knows its observers Any number of Observer objects may observe a subject provides an interface for attaching and detaching Observer objects
Observer defines an updating interface for objects that should be notified of
changes in a subject
ConcreteSubject stores state of interest to ConcreteObserver objects sends a notification to its observers when its state changes
ConcreteObserver maintains a reference to ConcreteSubject object stores state that should stay consistent with subject’s implements the Observer updating interface to keep its state
consistent with the subject’s.
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.20
Consequences Abstract Coupling between Subject and
Observer All a subject knows is it has a list of observers, each
conforming to an abstract and simple interface Subject doesn’t know the concrete class of any observer Coupling is abstract and minimal Subject and Observer can belong to different layers of the
system as they are not tightly coupled
Support for Broadcast Communication Subject needn’t specify the receiver(s) for its message Message is sent to all interested parties who are subscribed Only responsibility of subject is to notify observers Can add or remove observers at will
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.21
Consequences (2)
Unexpected Updates As observers are unaware of each other, they cannot
know the cost of changing the state of the subject A seemingly innocuous operation on the subject could
cause a cascade of updates to observers and their dependent objects
Dependency criteria which are not well-defined or maintained often lead to spurious updates
These can be hard to track down, especially with a simple Update protocol, which doesn’t provide details on what changed in the subject
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.22
Analysis Patterns
Higher level than Design Patterns
Provide common conceptual models which
exist across many business domains
Martin Fowler 1997 - Analysis Patterns:
Reusable Object Models
Organised into groups of patterns by
relevance to a particular conceptual category
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.23
Accountability Category
Concept of a persons or organisations being responsible to one another
Several different variants of the concept Common across many business domains
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.24
Party A concept which links people, roles and
organisations
Person
Address
TelephoneNumber
Company*
0..1
0..1
0..1 0..1
0..1
0..1
**
*
**
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.25
Better Model
Party
Address
Role
Organisation
Person TelephoneNumber
*
*
*
0..1
0..1
0..1
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.26
OperatingUnit
Region DivisionSalesOffice
1 1 1* * *
Organisation Structure Accurate at time, but very inflexible What if there is more than one hierarchy?
Sales Hierarchy Manufacturing Hierarchy
What if a Sales Office reports directly to a Region?
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.27
A Better ModelOrganisation
Structure Type
OrganisationStructure
TimePeriod
Rule
Organisation
Sales Office
Division
Region
OperatingUnit
parent
subsidiary
*
1
*
**
*
1
1
1
1
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.28
Accountability How do we cover a wide range of interparty
responsibilities/relationships? Management Employment Contracts
Person
Organisation
Accountability Party
Time Period
AccountabilityType commisionner
responsible
1
1
1
1
*
**
*