CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.1 Software Engineering: Analysis and Design - CSE3308 Patterns CSE3308/CSC3080/DMS/2000/12

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.2 Lecture Outline u What is a Pattern? u Design Patterns v Abstract Factory v Observer u Analysis Patterns v Accountability u Further Information

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.3 What is a Pattern? u Inspired by the work of Christopher Alexander, who first described patterns in Architecture u “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 “An idea that has been useful in one practical context and will probably be useful in others”

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.4 Design Patterns u Design Patterns: Elements of Reusable Object-Oriented Software (1995) v Erich Gamma v Richard Helm v Ralph Johnson v John Vlissides v 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

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.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

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.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

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.7 Categorising Design Patterns u Purpose v Creational - concern the process of object creation v Structural - deal with the composition of classes and objects v Behavioural - characterise the way in which classes or objects interact and distribute responsibility u Scope v 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. v Object - the pattern is primarily concerned with object relationships which are more dynamic and can change at run-time

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.8 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 look and feels for different standards, e.g. Win 95 and Win 3.11 u Need to avoid hardcoding the widgets that make up the interface

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.9 Abstract Factory Example CreateScrollBar() CreateWindow() CreateScrollBar() CreateWindow() CreateScrollBar() CreateWindow() Client Window Win 3.11 Window Win 95 Window ScrollBar Win 3.11 ScrollBar Win 95 ScrollBar WidgetFactory Win95WidgetFactoryWin311WidgetFactory creates

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.10 Applicability u Use Abstract Factory in the following situations: u a system should be independent of how its products are created, composed and represented u A system should be configurable with multiple families of products u A family of related product objects is designed to be used together, and you need to enforce this constraint u You want to provide a a class library of products, and you want to reveal only interfaces and not implementations

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.11 The Structure of Abstract Factory CreateProductA() CreateProductB() CreateProductA() CreateProductB() CreateProductA() CreateProductB() Client AbstractProductA ProductA1 ProductA2 Abstract ProductB ProductB3 ProductB2 AbstractFactory ConcreteFactory1ConcreteFactory2 creates

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.12 Participants u AbstractFactory - declares an interface for operations that create abstract product objects u ConcreteFactory - implements the operations to create concrete product objects u AbstractProduct - declares an interface for a type of product object u ConcreteProduct - defines a product object to be created by the corresponding concrete factory and implements the AbstractProduct interface u Client - uses only interfaces declared by AbstractFactory and AbstractProduct classes

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.13 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

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.14 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

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.15 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

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.16 Example

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.17 Applicability u Use Observer in the following situations: u When an abstraction has two aspects, one dependent upon the other. Encapsulating these aspects in separate objects lets you vary and reuse then independently u When a change to one object requires changing others, and you don’t know how many objects need to be changed u 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/CSC Software Engineering: Analysis and DesignLecture 5B.18 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()

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.19 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.

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.20 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 needn’t 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

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.21 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

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.22 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

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.23 Accountability Category u Concept of a persons or organisations being responsible to one another u Several different variants of the concept u Common across many business domains

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.24 Party u A concept which links people, roles and organisations Person Address Telephone Number Company * 0..1 * * * * *

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.25 Better Model Party Address Role Organisation Person Telephone Number * * * 0..1

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.26 Operating Unit RegionDivision Sales Office 11 1 * * * Organisation 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?

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.27 A Better Model Organisation Structure Type Organisation Structure Time Period Rule Organisation Sales Office Division Region Operating Unit parent subsidiary * 1 * * * *

CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.28 Accountability u How do we cover a wide range of interparty responsibilities/relationships? v Management v Employment v Contracts Person Organisation AccountabilityParty Time Period Accountability Type commisionner responsible * * * *