1 object oriented analysis and design with uml unit 4
TRANSCRIPT
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...