cse3308 - software engineering: analysis and design, 2002lecture 7b.1 software engineering: analysis...
Post on 20-Dec-2015
216 views
TRANSCRIPT
CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 7B.1
Software Engineering: Analysis and Design - CSE3308
Patterns
CSE3308/DMS/2002/15
CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 7B.2
Lecture Outline
What is a Pattern?
Design Patterns
Abstract Factory
Observer
Analysis Patterns
Accountability
Further Information
CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.7
Categorising Design Patterns Purpose
Creational - concern the process of object creation, e.g.» Abstract Factory, Singleton
Structural - deal with the composition of classes and objects, e.g.» Adapter, Facade
Behavioural - characterise the way in which classes or objects interact and distribute responsibility, e.g.
» Iterator, Observer
Scope Class - the pattern is primarily concerned with classes, they deal
with the relationships between classes and their sub-classes. These relationships are 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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 hard-coding the widgets that make up the interface
CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.11
The Structure of Abstract Factory
CreateProductA()CreateProductB()
CreateProductA()CreateProductB()
CreateProductA()CreateProductB()
Client
AbstractProductA
ProductA1ProductA2
Abstract ProductB
ProductB3ProductB2
AbstractFactory
ConcreteFactory1 ConcreteFactory2
creates
creates
CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.16
Example
a = 50%b = 30%c = 20%
subject
XTable XBar Chart XPie Chart
observers
change notificationrequests, modifications
a b cx 40 10 50y 50 30 20z 20 40 40
a b c
a
b
c
CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 need not 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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.25
Better Model
Party
Address
Role
Organisation
Person TelephoneNumber
*
*
*
0..1
0..1
0..1
CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 7B.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 - Software Engineering: Analysis and Design, 2002 Lecture 7B.27
A Better ModelOrganisation
Structure Type
OrganisationStructure
TimePeriod
Rule
Organisation
Sales Office
Division
Region
OperatingUnit
parent
subsidiary
*
1
*
**
*
1
1
1
1
CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 7B.28
Accountability How do we cover a wide range of inter-party
responsibilities/relationships? Management Employment Contracts
Person
Organisation
Accountability Party
Time Period
AccountabilityType commisionner
responsible
1
1
1
1
*
**
*
CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 7B.29
References Gamma, Erich; Helm, Richard; Johnson,
Ralph; and Vlissides, John, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995 (Chs. 1, 3, 4, 5).
Fowler, Martin, Analysis Patterns: Reusable Object Models, Addison-Wesley, 1997 (Ch. 2)
NB. A new version of this chapter, dealing with the Accountability pattern, is available on-line at:
http://martinfowler.com/articles.html