CSE Software Engineering: Analysis and Design, 2005Lecture 8A.1 Software Engineering: Analysis and Design - CSE3308 Design and Analysis Patterns CSE3308/DMS/2005/19

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.2 Lecture Outline u What is a Pattern? u Design Patterns v Abstract Factory v Observer u Analysis Patterns v Accountability u Further Information

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.3 What is a Pattern? u Inspired by the work of Christopher Alexander, who first described patterns in Architecture [AIS1977]: “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” u The idea was embraced by computing analysis and design theorists and practitioners. Martin Fowler’s definition of a pattern is [Fow1997]: “An idea that has been useful in one practical context and will probably be useful in others”

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.4 Design Patterns u The classic work on the application of patterns in software design is: Design Patterns: Elements of Reusable Object- Oriented Software (1995) v Erich Gamma v Richard Helm v Ralph Johnson v John Vlissides (a.k.a. The Gang of Four) u Used object modelling techniques to represent common solutions to problems in the design of OO software, taken from multiple actual systems

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.5 A Design Pattern is u SMART - an elegant solution not obvious to a novice u GENERIC - not dependent upon a system, programming language or application domain u WELL-PROVEN - has been identified from real OO systems u SIMPLE - is usually quite small, involving only a handful of classes u REUSABLE - is documented in such a fashion that it is easy to reuse u OBJECT-ORIENTED - built with OO mechanisms such as classes, objects, generalization and polymorphism

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.6 A Design Pattern has u a Pattern Name - a handle we can use to describe a design problem, its solutions and consequences u the Problem - describes when to apply the pattern. It explains the problem and its context u the Solution - describes the elements which make up the solution and their relationships u the Consequences - the results and trade-offs of using the design pattern

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.7 Categorising Design Patterns (1) u Purpose vCreational »concern the process of object creation, e.g. n Abstract Factory, Singleton v Structural » deal with the composition of classes and objects, e.g. n Adapter, Facade v Behavioural » characterise the way in which classes or objects interact and distribute responsibility, e.g. n Iterator, Observer

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.8 Categorising Design Patterns (2) u Scope v 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. v Object » the pattern is primarily concerned with object relationships, which are more dynamic and can change at run-time

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.9 Abstract Factory u Provides an interface for creating families of related or dependent objects without specifying their concrete classes u Abstract Factory has v Purpose - Creational v Scope - Object u Example - want to have multiple looks and feels for different standards, e.g. Windows XP and X Windows u Need to avoid hard-coding the widgets that make up the interface

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.10 CreateScrollBar() CreateWindow() XWinWidgetFactory Abstract Factory Example CreateScrollBar() CreateWindow() CreateScrollBar() CreateWindow() Client Window XWin Window WinXP Window ScrollBar XWin ScrollBar WinXP ScrollBar WidgetFactory WinXPWidgetFactory creates

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.11 Applicability u Use Abstract Factory in the following situations: va system should be independent of how its products are created, composed and represented vA system should be configurable with multiple families of products vA family of related product objects is designed to be used together, and you need to enforce this constraint vYou want to provide a a class library of products, and you want to reveal only interfaces and not implementations

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.12 The Structure of Abstract Factory CreateProductA() CreateProductB() CreateProductA() CreateProductB() CreateProductA() CreateProductB() Client AbstractProductA ProductA1 ProductA2 Abstract ProductB ProductB1 ProductB2 AbstractFactory ConcreteFactory1ConcreteFactory2 creates

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.13 Participants u AbstractFactory vdeclares an interface for operations that create abstract product objects u ConcreteFactory vimplements the operations to create concrete product objects u AbstractProduct vdeclares an interface for a type of product object u ConcreteProduct vdefines a product object to be created by the corresponding concrete factory and implements the AbstractProduct interface u Client vuses only interfaces declared by AbstractFactory and AbstractProduct classes

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.14 Consequences u It isolates concrete classes v isolates clients from implementation classes v clients manipulate instances through their abstract interface v product class names are isolated in the implementation of the concrete factory; they do not appear in client code u It makes exchanging product families easy v The class of a concrete factory appears only once in the application, i.e. where it’s instantiated v Use different product configurations simply by changing the concrete factory

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.15 Consequences (2) u It promotes consistency among products v When product objects in a family are designed to work together, it’s important to use only one family at a time v Abstract factory makes this constraint easy to implement u Supporting new kinds of products is difficult v Abstract Factory fixes the set of products which can be created v To extend the products, means that the Abstract Factory interface must be changed and all the Concrete Factory subclasses must be changed as well

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.16 Observer u Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically u Observer has v Purpose - Behavioural v Scope - Objects u Example - different views of data in a spreadsheet. v Table view v Bar graph view v Pie chart view

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.17 Example a = 50% b = 30% c = 20% subject X Table X Bar Chart X Pie Chart observers change notification requests, modifications a b c

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.18 Applicability u Use Observer in the following situations: vWhen an abstraction has two aspects, one dependent upon the other. Encapsulating these aspects in separate objects lets you vary and reuse then independently vWhen a change to one object requires changing others, and you don’t know how many objects need to be changed vWhen 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

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.19 The Structure of Observer Get State() SetState() 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()

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.20 Participants u Subject v Knows its observers v Any number of Observer objects may observe a subject v provides an interface for attaching and detaching Observer objects u Observer v defines an updating interface for objects that should be notified of changes in a subject u ConcreteSubject v stores state of interest to ConcreteObserver objects v sends a notification to its observers when its state changes u ConcreteObserver v maintains a reference to ConcreteSubject object v stores state that should stay consistent with subject’s v implements the Observer updating interface to keep its state consistent with the subject’s.

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.21 Consequences u Abstract Coupling between Subject and Observer v All a subject knows is it has a list of observers, each conforming to an abstract and simple interface v Subject doesn’t know the concrete class of any observer v Coupling is abstract and minimal v Subject and Observer can belong to different layers of the system as they are not tightly coupled u Support for Broadcast Communication v Subject need not specify the receiver(s) for its message v Message is sent to all interested parties who are subscribed v Only responsibility of subject is to notify observers v Can add or remove observers at will

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.22 Consequences (2) u Unexpected Updates v As observers are unaware of each other, they cannot know the cost of changing the state of the subject v A seemingly innocuous operation on the subject could cause a cascade of updates to observers and their dependent objects v Dependency criteria which are not well-defined or maintained often lead to spurious updates v These can be hard to track down, especially with a simple Update protocol, which doesn’t provide details on what changed in the subject

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.23 Analysis Patterns u Higher level than Design Patterns u Provide common conceptual models which exist across many business domains u Martin Fowler Analysis Patterns: Reusable Object Models u Organised into groups of patterns by relevance to a particular conceptual category

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.24 Accountability Category u Concept of a persons or organizations being responsible to one another u Several different variants of the concept u Common across many business domains

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.25 Example: Party u A concept that links people, roles and organizations: they are are all examples of the abstract notion of a “party”. For example, a party can have a telephone number, an address and an address. vNaïve solution: Person Address Telephone Number Company * 0..1 * * * * *

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.26 Better Model Party Address Role Organisation Person Telephone Number * * * 0..1

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.27 Operating Unit RegionDivision Sales Office 11 1 * * * Example: Organization Structure u Accurate at time, but very inflexible u What if there is more than one hierarchy? v Sales Hierarchy v Manufacturing Hierarchy u What if a Sales Office reports directly to a Region?

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.28 A Better Model Organisation Structure Type Organisation Structure Time Period Rule Organisation Sales Office Division Region Operating Unit parent subsidiary * 1 * * * *

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.29 Example: Accountability u How do we cover a wide range of inter-party responsibilities/relationships? v Management v Employment v Contracts Person Organisation AccountabilityParty Time Period Accountability Type commisionner responsible * * * *

CSE Software Engineering: Analysis and Design, 2005Lecture 8A.30 References u [AIS1977] Alexander, C., Ishikawa, S. and Silverstein, M., A Pattern Language: Towns, Buildings, Construction, Oxford University Press, u [GHJ1995] 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). u [Fow1997] Fowler, Martin, Analysis Patterns: Reusable Object Models, Addison-Wesley, 1997 (Ch. 2) A new version of this chapter, dealing with the Accountability pattern, is available via the Resources page