UNIT 4 Object Oriented Analysis and Design with

UNIT 4 Object Oriented Analysis and Design with UML 1

Summary Unit 3. . . Dynamic Modeling with UML 4 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 4 Describes what happens during the life cycle of the system 2

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

Summary Unit 3. . . 4 State Diagrams – Focus on state, behaviour and events inc/hours : = hours +1 modulo 24 inc/minutes : = minutes +1 modulo 60 Set hours Display do/display current time mode. Button() do/display hours mode. Button() Set minutes mode. Button() do/display minutes 4

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

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

Summary Unit 3. . . 4 Activity Diagrams – Focus on work aspect of interaction and communication [disk full] print. File() [free disk space] Remove Message. Box ^Printer. print(file) Show Message. Box “Disk full” on screen Show Message. Box “Printing” on screen Create Postscript file 7

UNIT 4 Patterns 8

What are Patterns? (1) 4 Christopher Alexander : – Patterns in buildings and towns “Each pattern describes a problem which 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 solution a million times over, without doing it the same way twice” 9

What are Patterns? (2) 4 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 10

What are Patterns? (3) 4 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 11

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

Different Types of Patterns Analysis Patterns : reusable object models Fowler, Addison Wesley, 1997, ISBN 0 -201 -89542 -0 Design Patterns : elements of reusable object-oriented software Gamma-Helm-Johnson-Vlissides, Addison Wesley, 1995, ISBN 0 -201 -63361 -2 Anti Patterns Antipatterns: refactoring software, architectures, and projects in crisis Brown, Malveau, Hays, Mc. Cormick, Mowbray John Wiley & Sons, 1998, ISBN 0 -471 -19713 -0 13

Design Patterns 14

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

Creational Patterns 4 Abstract factory 4 Builder 4 Factory Method 4 Prototype 4 Singleton 16

Structural Patterns 4 Adapter 4 Bridge 4 Composite 4 Decorator 4 Façade 4 Proxy 17

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

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

Abstract Factory Pattern (2) 4 Motivation 20

Abstract Factory Pattern (3) 4 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 21

Abstract Factory Pattern (4) 4 Structure 22

Abstract Factory Pattern (5) 4 Participants – Abstract. Factory (Widget. Factory) • declares an interface for operations that create abstract product objects – Concrete. Factory (Motif. Widget. Factory, PMWidget. Factory) • implements the operations to create concrete product objects – Abstract. Product (Window, Scroll. Bar) • defines a product object to be created by the corresponding concrete factory • implements the Abstract. Product interface – Client • uses only interfaces declared by Abstract. Factory and Abstract. Product classes 23

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

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

Composite Pattern (2) 4 Motivation 26

Composite Pattern (3) 4 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 27

Composite Pattern (4) 4 Structure 28

Composite Pattern (5) 4 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 29

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 30

Composite Pattern (7) 4 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 4 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 31

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

Proxy Pattern (2) 4 Motivation 33

Proxy Pattern (3) 4 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 34

Proxy Pattern (4) 4 Structure 35

Proxy Pattern (5) 4 Participants – Proxy (Image. Proxy) • 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 Real. Subject and Proxy so that a Proxy can be used anywhere a Real. Subject is expected – Real. Subject (Image) • defines the real object that the proxy represents 36

Proxy Pattern (6) 4 Collaborations – Proxy forwards requests to Real. Subject when appropriate, depending on the kind of proxy 4 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 37

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

Observer Pattern (2) 4 Motivation 39

Observer Pattern (3) 4 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 40

Observer Pattern (4) 4 Structure 41

Observer Pattern (5) 4 Participants – Subject • knows its observers. – Observer • defines an updating interface for objects that should be notified of changes in a subject – Concrete. Subject • stores state of interest to Concrete. Observer objects • sends a notification to its observers when its state changes 42

Observer Pattern (6) – Concrete. Observer • maintains a reference to a Concrete. Subject 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 43

Observer Pattern (7) 4 Collaborations – Concrete. Subject 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 Concrete. Observer object may query the subject for information 4 Consequences – Abstract coupling between Subject and Observer – Support for broadcast communication – Unexpected updates, cascading of updates 44

Observer Pattern (8) 45

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

Factory Method Pattern 47

Facade Pattern (1) 48

Facade Pattern (2) 49

Flyweight (1) 50

Flyweight (2) 51

Singleton 52

Builder (1) 53

Builder (2) 54

Builder (3) 55

Antipatterns 56

The 7 Deadly Sins (1) 4 Haste – Hasty decisions lead to compromises in SW quality. Especially testing is a victim. • “Just clean up the code, we ship tomorrow…” 4 Apathy – Not caring about solving known problems • “Reuse? Who’s ever gonna reuse this crappy code? ” 57

The 7 Deadly Sins (2) 4 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” 4 Sloth – Making poor decisions based upon easy answers (lazy developers) • “ZZZZZzzzzz…” 58

The 7 Deadly Sins (3) 4 Avarice – The modelling of excessive details, resulting in complexity due to insufficient abstraction • “I’m impressed ! The most complex model ever done !” 4 Ignorance – Failing to seek understanding. Intellectual sloth • “ 100 pages… let’s find a one page summary on the net” 4 Pride – Reinventing designs instead of reusing them. • “New company motto : ZERO DEFETCS !” 59

Categories of Antipatterns 4 Development antipatterns – technical problems/solutions encountered by programmers 4 Architectural antipatterns – identification of common problems in system structures 4 Managerial antipatterns – addresses common problems in software processes and development organizations 60

Development Antipatterns 4 The Blob 4 Dead End 4 Continuous Obsolescence 4 Lava Flow 4 Spaghetti Code 4 Ambiguous Viewpoint 4 Functional Decomposition 4 Poltergeists 4 Minefield Walking 4 Golden Hammer 4 Cut-and-Paste 4 Boat Anchor 4. . . 61

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

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

The Blob (1) 4 Category – Software Development 4 Also Known as – Winnebago, The God Class 4 Scale – Application 4 Refactored Solution Name – Refactoring of Responsibilities 64

The Blob (2) 4 Root Causes – Sloth, Haste 4 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 65

The Blob (3) 4 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, . . . 66

Vendor Lock-in (1) 4 Category – Software Architecture 4 Also Known as – Connector Conspiracy, Product Dependent Architecture 4 Scale – System 4 Refactored Solution Name – Isolation Layer 67

Vendor Lock-in (2) 4 Root Causes – Sloth, Apathy, Pride/Ignorance 4 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 68

Vendor Lock-in (3) 4 Refactored Solution – Isolation of application software from lowerlevel infrastructure – Changes to the underlying infrastructure anticipated in the life cycle – A more convenient programming interface is useful or necessary for abstraction levels 69

Remember 4 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. . . 70