CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 5B.1 Software Engineering:...

CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 5B.1

Software Engineering: Analysis and Design - CSE3308

Patterns

CSE3308/CSC3080/DMS/2000/12


Lecture Outline

What is a Pattern?

Design Patterns

Abstract Factory

Observer

Analysis Patterns

Accountability

Further Information


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”


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


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


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


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


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


Abstract Factory Example

CreateScrollBar()CreateWindow()



Client

Window

Win 3.11Window

Win 95 Window

ScrollBar

Win 3.11ScrollBar

Win 95ScrollBar

WidgetFactory

Win95WidgetFactory Win311WidgetFactory

creates

creates


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


The Structure of Abstract Factory

CreateProductA()CreateProductB()



Client

AbstractProductA

ProductA1ProductA2

Abstract ProductB

ProductB3ProductB2

AbstractFactory

ConcreteFactory1 ConcreteFactory2

creates

creates


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


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


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


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


Example


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


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()


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.


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


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


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


Accountability Category

Concept of a persons or organisations being responsible to one another

Several different variants of the concept Common across many business domains


Party A concept which links people, roles and

organisations

Person

E-mail

Address

TelephoneNumber

Company*

0..1

0..1

0..1 0..1

0..1

0..1

**

*

**


Better Model

Party

E-mail

Address

Role

Organisation

Person TelephoneNumber

*

*

*

0..1

0..1

0..1


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?


A Better ModelOrganisation

Structure Type

OrganisationStructure

TimePeriod

Rule

Organisation

Sales Office

Division

Region

OperatingUnit

parent

subsidiary

*

1

*

**

*

1

1

1

1


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

*

**

*

CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 5B.1 Software Engineering:...

Documents

Transcript of CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 5B.1 Software Engineering:...