1

Object OrientedAnalysis and Design

with UML

UNIT 4

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 withImmediate return

4

Summary Unit 3...

State Diagrams– Focus on state, behaviour and events

modeButton()Display

do/displaycurrent time

Set hours

do/displayhours

Set minutes

do/displayminutes

modeButton()

modeButton()

inc/minutes := minutes +1 modulo 60

inc/hours := hours +1 modulo 24

5

Summary Unit 3... Sequence Diagrams

– Focus on time aspect of interaction and communication

:Computer :PrintServer :PrinterPrint(ps-file)

Print(ps-file) [no queue]Print(ps-file)

Message

Activation

Return

Lifeline

Object

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

ShowMessageBox“Printing” on

screen

RemoveMessageBox

CreatePostscript

file

[disk full]

[free disk space]

^Printer.print(file)

printFile()

8

Patterns

UNIT 4

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 it

the same way twice”

10

What are Patterns? (2)

Solutions for Object-Oriented Systems

Smart

Generic

Well-proven

Simple

• Elegant solutions that a novice would not think of

• Independent on specific system type, language

• Successfully tested in several systems

• 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

Analysis PatternsAnalysis Patterns : reusable object models

Fowler,Addison Wesley, 1997, ISBN 0-201-89542-0

Different Types of Patterns

Design Patterns

Design Patterns : elements of reusable object-oriented softwareGamma-Helm-Johnson-Vlissides, Addison Wesley, 1995, ISBN 0-201-63361-2

Antipatterns:refactoring software, architectures, and projects in crisisBrown, Malveau, Hays, McCormick, MowbrayJohn Wiley & Sons, 1998, ISBN 0-471-19713-0

Anti Patterns

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)

51

Flyweight (2)

52

Singleton

53

Builder (1)

54

Builder (2)

55

Builder (3)

56

Antipatterns

57

The 7 Deadly Sins (1) Haste

– Hasty decisions lead to compromises in SW quality. Especially testing is a victim.

• “Just clean up the code, we ship tomorrow…”

Apathy– Not caring about solving known problems

• “Reuse? Who’s ever gonna reuse this crappy code?”

58

The 7 Deadly Sins (2) Narrow-mindedness

– Refusal to practice solutions that are otherwise widely known to be effective.

• “I don’t need to know, and… I don’t care to know”

Sloth– Making poor decisions based upon easy

answers (lazy developers)• “ZZZZZzzzzz…”

59

The 7 Deadly Sins (3) Avarice

– The modelling of excessive details, resulting in complexity due to insufficient abstraction

• “I’m impressed ! The most complex model ever done !”

Ignorance– Failing to seek understanding. Intellectual sloth

• “100 pages… let’s find a one page summary on the net”

Pride– Reinventing designs instead of reusing them.

• “New company motto : ZERO DEFETCS !”

60

Categories of Antipatterns

Development antipatterns– technical problems/solutions encountered by

programmers

Architectural antipatterns– identification of common problems in system structures

Managerial antipatterns– addresses common problems in software processes and

development organizations

61

Development Antipatterns

The Blob Continuous Obsolescence Lava Flow Ambiguous Viewpoint Functional Decomposition Poltergeists Golden Hammer Boat Anchor

Dead End

Spaghetti Code

Minefield Walking Cut-and-Paste ...

62

Architecture Antipatterns

Autogenerated Stovepipe Stovepipe Enterprise Jumble Cover Your Assets Vendor Lock-in Wolf Ticket Warm Bodies Swiss Army Knife ...

63

Management Antipatterns

Blowhard Jamboree Analysis Paralysis Viewgraph Engineering Death by Planning Fire Drill The Feud E-Mail is Dangerous Intellectual Violence ...

64

The Blob (1)

Category– Software Development

Also Known as– Winnebago, The God Class

Scale– Application

Refactored Solution Name– Refactoring of Responsibilities

65

The Blob (2) Root Causes

– Sloth, Haste

General Form– Designs where one class monopolizes the processing,

and other classes primarily encapsulate data

– Key problem is : majority of responsibilities are allocated to a single class

– In general it is a procedural design• conflicts with OO paradigm

66

The Blob (3)

Refactored Solution– Identify or categorize related attributes and

operations– Look for ‘natural homes’ for these collections

of functionality– Apply OO Design techniques

• e.g. inheritance, ...

67

Vendor Lock-in (1)

Category– Software Architecture

Also Known as– Connector Conspiracy, Product Dependent Architecture

Scale– System

Refactored Solution Name– Isolation Layer

68

Vendor Lock-in (2) Root Causes

– Sloth, Apathy, Pride/Ignorance General Form

– Commercial product upgrades drive the application software maintenance cycle

– Promised product features are delayed or never delivered

– The product varies significantly from the advertised open systems standard

– Repurchase is needed when upgrade is missed

69

Vendor Lock-in (3)

Refactored Solution– Isolation of application software from lower-

level infrastructure– Changes to the underlying infrastructure are

anticipated in the life cycle– A more convenient programming interface is

useful or necessary for abstraction levels

70

Remember

Although it is possible to make buildings by stringing together patterns, in a rather loose way, a building made like this, is an assembly of patterns, and no one would want to live in it...