Object Oriented Analysis and Design with UML

1. UNIT 4 Object OrientedAnalysis and Designwith UML

2. Summary Unit 3... Dynamic Modeling with UML • How do the things described by static models : • Cooperate to manage their tasks • Communicate with each other • Change their state • Provide the functionality of the system • Describes what happens during the life cycle of the system

3. Summary Unit 3... • Different Message Types Synchronous Asynchronous Simple Synchronous with Immediate return

4. Summary Unit 3... • State Diagrams • Focus on state, behaviour and events inc/hours := hours +1 modulo 24 inc/minutes := minutes +1 modulo 60 Set hours Display Set minutes modeButton() modeButton() do/displayhours do/displaycurrent time do/displayminutes modeButton()

5. Print(ps-file) :Computer :PrintServer :Printer Print(ps-file) [no queue]Print(ps-file) Summary Unit 3... • Sequence Diagrams • Focus on time aspect of interaction and communication Object Message Activation Return Lifeline

6. Summary Unit 3... • Collaboration Diagrams • Focus on space aspect of interaction and communication

7. Summary Unit 3... • Activity Diagrams • Focus on work aspect of interaction and communication ShowMessageBox“Disk full” on screen [disk full] printFile() ShowMessageBox“Printing” on screen [free disk space] Remove MessageBox Create Postscript file ^Printer.print(file)

8. UNIT 4 Patterns

9. What are Patterns? (1) • Christopher Alexander : • Patterns in buildings and towns “Each pattern describes a problemwhich occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solutiona million times over, without doing itthe same way twice”

10. What are Patterns? (2) • Solutions for Object-Oriented Systems Smart • Elegant solutions that a novice would not think of Generic • Independent on specific system type, language Well-proven • Successfully tested in several systems Simple • Combine them for more complex solutions

11. What are Patterns? (3) • Four essential elements in patterns • Pattern name • Increase of design vocabulary • Problem description • When to apply the pattern, in what context to use it • Solution description (generic !) • The elements that make up the design, their relationships, responsibilities, and collaborations • Consequences • Results and trade-offs of applying the pattern

12. Patterns Provide... • Reusable solutions to common problems • based on experiences from real systems • Names of abstractions above class and object level • a common vocabulary for developers • Handling of functional and non-functional aspects • separating interfaces/implementation, loose coupling between parts, … • A base for frameworks and toolkits • basic constructs to improve reuse • Education and training support

13.    Different Types of Patterns Analysis Patterns Analysis Patterns : reusable object modelsFowler,Addison Wesley, 1997, ISBN 0-201-89542-0 Design Patterns Design Patterns : elements of reusable object-oriented softwareGamma-Helm-Johnson-Vlissides, Addison Wesley, 1995, ISBN 0-201-63361-2 Anti Patterns Antipatterns:refactoring software, architectures, and projects in crisisBrown, Malveau, Hays, McCormick, MowbrayJohn Wiley & Sons, 1998, ISBN 0-471-19713-0

14. Design Patterns

15. Categories of Design Patterns • Creational Patterns • Instantiation and configuration of classes and objects • Structural Patterns • Usage of classes and objects in larger structures, separation of interfaces and implementation • Behavioural Patterns • Algorithms and division of responsibility

16. Creational Patterns • Abstract factory • Builder • Factory Method • Prototype • Singleton

17. Structural Patterns • Adapter • Bridge • Composite • Decorator • Façade • Proxy

18. Behavioural Patterns • Chain of responsibility • Command • Flyweight • Interpreter • Iterator • Mediator • Memento • Observer • State • Strategy • Template • Visitor

19. Abstract Factory Pattern (1) • Category • Creational • Intent • Provide an interface for creating families of related or dependent objects without specifying their concrete classes • Also known as • Kit

20. Abstract Factory Pattern (2) • Motivation

21. Abstract Factory Pattern (3) • Applicability • Use the abstract factory pattern when : • a system should be independent of how its products are created, composed, and represented • a system should be configured with one of 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 class library of products, and you want to reveal just their interfaces, not their implementations

22. Abstract Factory Pattern (4) • Structure

23. Abstract Factory Pattern (5) • Participants • AbstractFactory(WidgetFactory) • declares an interface for operations that create abstract product objects • ConcreteFactory(MotifWidgetFactory, PMWidgetFactory) • implements the operations to create concrete product objects • AbstractProduct(Window, ScrollBar) • defines a product object to be created by the corresponding concrete factory • implements the AbstractProduct interface • Client • uses only interfaces declared by AbstractFactory and AbstractProduct classes

24. Abstract Factory Pattern (6) • Collaborations • Normally a single instance of ConcreteFactory is created at run-time • AbstractFactory defers creation of product objects to its ConcreteFactory subclass • Consequences • It isolates concrete classes • It makes exchanging product families easy • It promotes consistency among products • Supporting new kinds of products is difficult

25. Composite Pattern (1) • Category • Structural • Intent • Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly • Also known as • ---

26. Composite Pattern (2) • Motivation

27. Composite Pattern (3) • Applicability • Use the Composite Pattern when : • you want to represent part-whole hierarchies of objects • you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly

28. Composite Pattern (4) • Structure

29. Composite Pattern (5) • Participants • Component(Graphic) • declares the interface for objects in the composition • implements default behaviour for the interface common to all classes, as appropriate • declares an interface for accessing and managing its child components • Leaf(Rectangle, Line, Text, ...) • represents leaf objects in the composition. A leaf has no children • defines behaviour for primitive objects in the composition

30. Composite Pattern (6) • Composite(Picture) • defines behaviour for components having children • stores child components • implements child-related operations in the Component interface • Client • manipulates objects in the composition through the Component interface

31. Composite Pattern (7) • Collaborations • Clients use the Component class interface to interact with objects in the composite structure. Leaves handle requests directly. Composites forward requests to its child components • Consequences • defines class hierarchies consisting of primitive and composite objects. • Makes the client simple. Composite and primitive objects are treated uniformly. (no cases) • Eases the creation of new kinds of components • Can make your design overly general

32. Proxy Pattern (1) • Category • Structural • Intent • Provide a surrogate or placeholder for another object to control access to it • Also known as • Surrogate

33. Proxy Pattern (2) • Motivation

34. Proxy Pattern (3) • Applicability • Use the Proxy Pattern : • A remote proxy provides a local representative for an object in a different address space • A virtual proxy creates expensive objects on demand • A protection proxy controls access to the original object, in order to enforce access rights • A smart reference is a replacement for a bare pointer that performs additional actions when an object is accessed

35. Proxy Pattern (4) • Structure

36. Proxy Pattern (5) • Participants • Proxy(ImageProxy) • maintains a reference that lets the proxy access the real subject • provides an interface identical to Subject’s so that a proxy can be substituted for the real subject • controls access to the real subject and may be responsible for creating and deleting it • Subject(Graphic) • defines the common interface for RealSubject and Proxy so that a Proxy can be used anywhere a RealSubject is expected • RealSubject(Image) • defines the real object that the proxy represents

37. Proxy Pattern (6) • Collaborations • Proxy forwards requests to RealSubject when appropriate, depending on the kind of proxy • Consequences • A remote proxy can hide the fact that an object resides in a different address space • A virtual proxy can perform optimisations such as creating an object on demand • Both protection proxies and smart references allow additional housekeeping tasks when an object is accessed

38. Observer Pattern (1) • Category • Behavioural • Intent • Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically • Also known as • Dependents, Publish-Subscribe

39. Observer Pattern (2) • Motivation

40. Observer Pattern (3) • Applicability • Use the Observer Pattern when : • an abstraction has two aspects, one dependent on the other • a change to one object requires changing others, and you don’t know how many objects need to be changed • an object should be able to notify other objects without making assumptions about who these objects are

41. Observer Pattern (4) • Structure

42. Observer Pattern (5) • Participants • Subject • knows its observers. • 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

43. Observer Pattern (6) • ConcreteObserver • maintains a reference to a ConcreteSubject object • stores state that should stay consistent with the subject’s • implements the Observer updating interface to keep its state consistent with the subject’s

44. Observer Pattern (7) • Collaborations • ConcreteSubject notifies its observers whenever a change occurs that could make its observers’ state inconsistent with its own • After being informed of a change in the concrete subject, a ConcreteObserver object may query the subject for information • Consequences • Abstract coupling between Subject and Observer • Support for broadcast communication • Unexpected updates, cascading of updates

45. Observer Pattern (8)

46. Observer Pattern (9) • Consequences • Abstract coupling between Subject and Observer • Support for broadcast communication • Unexpected updates, cascading of updates

47. Factory Method Pattern

48. Facade Pattern (1)

49. Facade Pattern (2)

50. Flyweight (1)