1. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.1 Software Engineering: Analysis and Design - CSE3308 Patterns CSE3308/DMS/2002/15

2. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.2 Lecture Outline u What is a Pattern? u Design Patterns v Abstract Factory v Observer u Analysis Patterns v Accountability u Further Information

3. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.3 What is a Pattern? u 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”

4. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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 (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

5. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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

6. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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

7. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.7 Categorising Design Patterns u Purpose v Creational - concern the process of object creation, e.g. » Abstract Factory, Singleton v Structural - deal with the composition of classes and objects, e.g. » Adapter, Facade v Behavioural - characterise the way in which classes or objects interact and distribute responsibility, e.g. » Iterator, Observer 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

8. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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 hard-coding the widgets that make up the interface

9. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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

10. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.10 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

11. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.11 The Structure of Abstract Factory CreateProductA() CreateProductB() CreateProductA() CreateProductB() CreateProductA() CreateProductB() Client AbstractProductA ProductA1 ProductA2 Abstract ProductB ProductB3 ProductB2 AbstractFactory ConcreteFactory1ConcreteFactory2 creates

12. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.12 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

13. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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

14. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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

15. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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

16. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.16 Example a = 50% b = 30% c = 20% subject X Table X Bar Chart X Pie Chart observers change notification requests, modifications a b c

17. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.17 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

18. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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()

19. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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.

20. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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 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

21. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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

22. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.22 Analysis Patterns u Higher level than Design Patterns u Provide common conceptual models which exist across many business domains u Martin Fowler 1997 - Analysis Patterns: Reusable Object Models u Organised into groups of patterns by relevance to a particular conceptual category

23. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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

24. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.24 Party u A concept which links people, roles and organisations Person E-mail Address Telephone Number Company * 0..1 * * * * *

25. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.25 Better Model Party E-mail Address Role Organisation Person Telephone Number * * * 0..1

26. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.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?

27. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.27 A Better Model Organisation Structure Type Organisation Structure Time Period Rule Organisation Sales Office Division Region Operating Unit parent subsidiary * 1 * * * * 1 1 1 1

28. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.28 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 1 1 1 1 * * * *

29. CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 7B.29 References u 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 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