Chapter 6, System Design Design Patterns II - PowerPoint PPT Presentation

Loading...

PPT – Chapter 6, System Design Design Patterns II PowerPoint presentation | free to download - id: 68b858-NTIwO



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Chapter 6, System Design Design Patterns II

Description:

Chapter 6, System Design Design Patterns II – PowerPoint PPT presentation

Number of Views:90
Avg rating:3.0/5.0
Slides: 68
Provided by: BerndB7
Learn more at: http://www.eecs.qmul.ac.uk
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Chapter 6, System Design Design Patterns II


1
Chapter 6,System Design Design Patterns II
2
Outline
  • A little discourse on Advanced Object modeling
  • Sequence Diagrams
  • Tie together use cases and participating objects
  • Object types Entity objects, boundary objects,
    control objects
  • Review of design pattern concepts
  • What is a design pattern?
  • Modifiable designs
  • More patterns
  • Abstract Factory
  • Proxy
  • Command
  • Observer
  • Strategy

3
I found all my use cases and participating
objects. Now what?
4
Sequence Diagrams
  • Use cases and participating objects are found.
    What now?
  • Sequence diagram - A diagram that shows object
    interactions arranged in time sequence for a
    specific use case or scenario.
  • A sequence diagram includes time but does not
    include object relationships.
  • Sequence diagrams are used to describe use cases
    (i.e., all possible interactions between
    participating objects) and scenarios (i.e., one
    possible interaction, see next slide)
  • In other words A sequence diagram is useful to
    model a use case or scenario with its
    participating objects. It often leads to the
    detection of new participating objects.

5
Drawing Sequence Diagrams
  • Each column represents an object that is
    participating in the interaction.
  • The vertical axis represents time (from top to
    bottom). Messages are shown by full arrows.
  • Labels on full arrows represent message names and
    arguments.
  • Activations (i.e., the time it takes to perform
    an operation) are depicted by a rectangle
    attached to an object. The height of the
    rectangle is indicative for the duration of the
    operation
  • The vertical rectangle shows that an object is
    active, that is, it is handling a request made by
    another object.
  • The operation can itself send other requests to
    other objects
  • An object can request an operation from itself
    (looping arrow)

6
Sequence Diagrams vs Interaction Diagrams
  • In the Design Pattern book sequence diagrams are
    called interaction diagrams..
  • A solid vertical line indicates the lifetime of a
    particular object
  • If the object does not get instantiated until
    after the beginning of time as recorded in the
    diagram, then its vertical line is dashed until
    the point of creation, where it becomes solid.

7
Example of a Sequence Diagram
Report Emergency_Control
Report
ReportEmergency
Emergency
Manage

FieldOfficer
EmergencyButton
Form
Report
Emergency_Control
press()
create()
create()
fillContents()
submit()
submitReport()
create()
submitReportToDispatcher()
8
Increase the Reuse of your Model even more
Structuring the Participating Objects
Control Objects
Boundary Objects
Entity Objects
9
Different Object Types
  • Boundary objects
  • Implement the interaction with the user
  • Constructed from UI components
  • Subject to most modification
  • Entity objects
  • Represent the domain model
  • Often represent persistent data
  • Least often modified
  • Control objects
  • Implement the transactions with the user
  • Constructed with Command objects
  • Modified frequently but less often than boundary
    objects

10
Identifying Boundary Objects
  • Boundary objects model the system interface with
    the actors.
  • In each use case, each actor interacts at least
    through one boundary object.
  • The boundary object collects the information from
    the actor and translates it into an interface
    neutral form that can be used by the control and
    entity objects.

11
Identifying Control Objects
  • Control objects are responsible for coordinating
    boundary and entity objects.
  • There is often a close relationship between a use
    case and a control object.
  • A control object is usually created at the
    beginning of a use case and ceases to exist at
    its end.
  • It is responsible for collecting information from
    the boundary objects and dispatching it to entity
    objects.
  • For example, control objects describe the
    behavior associated with the sequencing of forms,
    undo and history queues, and dispatching
    information in a distributed system

12
Some Heuristics for Identification of Interface
and Control Objects
  • Identify one control object per use case or more
    if the use case is complex and can be divided
    into shorter flows of events,
  • Identify one control object per actor in the use
    case,
  • The life span of a control object should be
    extent of the use case or the extent of a user
    session. If it is difficult to identify the
    beginning and the end of a control object
    activation, the corresponding use case may not
    have a well define entry and exit condition.

13
Some Heuristics for Good Sequence Diagrams
  • Column 1 models the actor who initiated the use
    case
  • Column 2 should be a boundary object (that the
    actor used to initiate the use case)
  • Column 3 should be the control object that
    manages the rest of the use case
  • Control objects are created by boundary objects
    initiating use cases
  • Boundary objects are created by control objects
  • Entity objects are accessed by control and
    boundary objects
  • Entity objects never access boundary or control
    objects. This makes it easier to share them
    across use cases.

14
Back to the main topic Design patterns
  • A design pattern is
  • a template solution to a recurring design
    problem
  • Look before re-inventing the wheel just one more
    time
  • reusable design knowledge
  • Higher level than classes or datastructures (link
    lists,binary trees...)
  • Lower level than application frameworks
  • an example of modifiable design
  • Learning to design starts by studying other
    designs

15
Why are modifiable designs important?
  • A modifiable design enables
  • an iterative and incremental development cycle
  • concurrent development
  • risk management
  • flexibility to change
  • to minimize the introduction of new problems
    when fixing old ones
  • to deliver more functionality after initial
    delivery

16
What makes a design modifiable?
  • Low coupling and high coherence
  • Clear dependencies
  • Explicit assumptions
  • How do design patterns help?
  • They are generalized from existing systems
  • They provide a shared vocabulary to designers
  • They provide examples of modifiable designs
  • Abstract classes
  • Delegation

17
Interface Inheritance vs Implementation
inheritance
  • Interface inheritance(i.e., subtyping)
  • describes when different types of objects can be
    used in place of each other
  • Implementation inheritance
  • an objects implementation is defined in terms of
    the implementation of another.

18
Interface inheritance vs. implementation
inheritance
  • Interface inheritance
  • separates interface and implementation
  • implementations may be transparently substituted
  • decreases coupling
  • Implementation inheritance (class inheritance)
  • introduces dependencies among an ancestor and its
    descendents (inherited state)
  • mixes interface specification and implementation
  • can be achieved with delegation instead
  • The Design Patterns book shows how to avoid
    implementation inheritance with a mix of
    interface inheritance and delegation

19
Interface and class inheritance in Java
  • An interface defines constants and abstract
    methods.
  • An interface can extend (i.e., inherit from)
    zero, one, or many interfaces.
  • An interface does not define any behavior or
    attributes
  • A class defines attributes and methods.
  • A class can extend (i.e., inherit behavior and
    attributes from) zero or one class.
  • A class can implement (i.e., comply with) zero,
    one, or many interfaces in addition to extending
    a super class.
  • Abstract classes should be realized by interfaces
    in Java.
  • Concrete classes should be realized by classes in
    Java.

20
On to More Patterns!
  • Structural pattern
  • Proxy
  • Creational Patterns
  • Abstract Factory
  • Builder
  • Behavioral pattern
  • Command
  • Observer
  • Strategy

21
Proxy Pattern Motivation
  • It is 1500pm. I am sitting at my 14.4 baud modem
    connection and retrieve a fancy web site from the
    US, This is prime web time all over the US. So I
    am getting 10 bits/sec.
  • What can you do?

22
Proxy Pattern
  • What is expensive?
  • Object Creation
  • Object Initialization
  • Defer object creation and object initialization
    to the time you need the object
  • Proxy pattern
  • Reduces the cost of accessing objects
  • Uses another object (the proxy) that acts as a
    stand-in for the real object
  • The proxy creates the real object only if the
    user asks for it

23
Proxy pattern (207)
  • Interface inheritance is used to specify the
    interface shared by Proxy and RealSubject.
  • Delegation is used to catch and forward any
    accesses to the RealSubject (if desired)
  • Proxy patterns can be used for lazy evaluation
    and for remote invocation.
  • Proxy patterns can be implemented with a Java
    interface.

24
Proxy Applicability
  • Remote Proxy
  • Local representative for an object in a different
    address space
  • Caching of information Good if information does
    not change too often (PAID!)
  • Virtual Proxy
  • Object is too expensive to create or too
    expensive to download
  • Proxy is a stand-in
  • Protection Proxy
  • Proxy provides access control to the real object
  • Useful when different objects should have
    different access and viewing rights for the same
    document.
  • Example Grade information for a student shared
    by administrators, teachers and students.

25
Virtual Proxy example
realSubject
  • Images are stored and loaded separately from text
  • If a RealImage is not loaded a ProxyImage
    displays a grey rectangle in place of the image
  • The client cannot tell that it is dealing with a
    ProxyImage instead of a RealImage
  • A proxy pattern can be easily combined with a
    Bridge

26
Before
27
Controlling Access
28
After
29
Towards a Pattern Taxonomy
  • Structural Patterns
  • Adapters, Bridges, Facades, and Proxies are
    variations on a single theme
  • They reduce the coupling between two or more
    classes
  • They introduce an abstract class to enable future
    extensions
  • Encapsulate complex structures
  • Behavioral Patterns
  • Concerned with algorithms and the assignment of
    responsibilies between objects Who does what?
  • Characterize complex control flow that is
    difficult to follow at runtime.
  • Creational Patterns
  • Abstract the instantiation process.
  • Make a system independent from the way its
    objects are created, composed and represented.

30
A Pattern Taxonomy
Command
31
Command Pattern Motivation
  • You want to build a user interface
  • You want to provide menus
  • You want to make the user interface reusable
    across many applications
  • You cannot hardcode the meanings of the menus for
    the various applications
  • The applications only know what has to be done
    when a menu is selected.
  • Such a menu can easily be implemented with the
    Command Pattern

32
Command pattern
Invoker
Command execute()
Client
binds
  • Client creates a ConcreteCommand and binds it
    with a Receiver.
  • Client hands the ConcreteCommand over to the
    Invoker which stores it.
  • The Invoker has the responsibility to do the
    command (execute or undo).

33
Menu Example
Menu

Menu Item
Command execute()
Application

binds
34
Command pattern Applicability
  • Encapsulate a request as an object, thereby
    letting you
  • parameterize clients with different requests,
  • queue or log requests, and
  • support undoable operations.
  • Uses
  • Undo queues
  • Database transaction buffering

35
Command pattern Editor with unlimited undos
36
Structuring the objects
ConcreteCommands (Control objects)
Invoker (Boundary objects)
UndoQueue
Menu
MoveCommand
Triangle
Editor
Rectangle
Circle
Receiver (Entity objects)
37
Command pattern typical sequence
aUser
anEditor
Drags mouse
newCommand(info)
MoveCommand1
store(MoveCommand1)
execute()
move(x, y)
38
A Pattern Taxonomy
Pattern
Creational Pattern
Structural Pattern
Behavioral Pattern
Abstract Factory
Builder Pattern
Command
Command
Observer
Strategy
Observer
39
Observer pattern (293)
  • Define a one-to-many dependency between objects
    so that when one object changes state, all its
    dependents are notified and updated
    automatically. (p. 293)
  • Also called Publish and Subscribe
  • Uses
  • Maintaining consistency across redundant state
  • Optimizing batch changes to maintain consistency

40
Observer pattern (continued)
Subject
Observers
9DesignPatterns2.ppt
41
Observer pattern (continued)

observers
subject
  • The Subject represents the actual state, the
    Observers represent different views of the state.
  • Observer can be implemented as a Java interface.
  • Subject is a super class (needs to store the
    observers vector) not an interface.

42
Sequence diagram for scenario Change filename
to foo
aListView
anInfoView
aFile
getState()
foo
43
Animated Sequence diagram
44
Observer pattern implementation in Java
  • // import java.util
  • public class Observable extends Object
  • public void addObserver(Observer o)
  • public void deleteObserver(Observer o)
  • public boolean hasChanged()
  • public void notifyObservers()
  • public void notifyObservers(Object arg)
  • public abstract interface Observer
  • public abstract void update(Observable o, Object
    arg)
  • public class Subject extends Observable
  • public void setState(String filename)
  • public string getState()

45
Example from a Real Project JAMES Project
  • Nonfunctional Requirements
  • Foundation for wide range of smartcard
    applications
  • Bonus system, vehicle personalization, travel
    planning,
  • Flexibility and extendability for future
    applications
  • Integration of various computing platforms and
    devices
  • Central database hosts, home and dealership PCs,
    onboard computer, speech system, device
    controllers, smartcards
  • Scalability
  • Support for large number of mobile clients and
    servers
  • Openness
  • Use of open standards and commercial components
  • These requirements lead to the use of the
    observer pattern -gt JAMES Event Service

46
James Event Service
  • Event channels are the main means of
    communication in James

currently, only used for onboard communication
between various subsystems in vehicle
however, could be used also for wide-area
communication
47
JAMES Event Service Requirements
  • Peers can be created and deleted dynamically
  • Peers can subscribe dynamically as publishers or
    subscribers
  • A peer can subscribe to many event channels at
    the same time
  • A peer can be publisher and subscriber on a event
    channel at the same time
  • Publishers do not know their subscribers (only
    the event channel)
  • Event channels allow plug-and-play with cardlets
  • Use of the Observer Pattern leads to scalable
    and extensible architecture


48
James Event Service as a set of objects
  • View (Boundary objects)Viewlets
  • Controller (Control Object)Event Channel
  • Model (Entity Objects) Cardlets and Vehicle
    Subsystem
  • Cardlets and Viewlets act as peers on the onboard
    software bus
  • cardlets are applications running on a Java
    smartcard
  • viewlets are the corresponding GUI frontends on
    the onboard computer

49
Cardlets and Viewlets
50
Cardlet Communication in James
Onboard GUI
Smartcard
Onboard Bus
BonusCardlet
Bonus Viewlet
51
A Pattern Taxonomy
Strategy
52
Strategy Pattern
  • Many different algorithms exists for the same
    task
  • Examples
  • Breaking a stream of text into lines
  • Parsing a set of tokens into an abstract syntax
    tree
  • Sorting a list of customers
  • The different algorithms will be appropriate at
    different times
  • Rapid prototyping vs delivery of final product
  • We dont want to support all the algorithms if we
    dont need them
  • If we need a new algorithm, we want to add it
    easily without disturbing the application using
    the algorithm

53
Strategy Pattern
Context ContextInterface()

Strategy
ConcreteStrategyC AlgorithmInterface()
ConcreteStrategyB AlgorithmInterface()
ConcreteStrategyA AlgorithmInterface()
54
Applying a Strategy Pattern in a Database
Application
Database Search() Sort()

Strategy
ShellSort Sort(CustomerList)
QuickSort Sort(CustomerList)
BubbleSort Sort(CustomerList)
55
Applicability of Strategy Pattern
  • Many related classes differ only in their
    behavior. Strategy allows to configure a single
    class with one of many behaviors
  • Different variants of an algorithm are needed
    that trade-off space against time. All these
    variants can be implemented as a class hierarchy
    of algorithms

56
A Pattern Taxonomy
Abstract Factory
Strategy
57
Abstract Factory Motivation
  • Consider a user interface toolkit that supports
    multiple looks and feel standards such as Motif,
    Windows 95 or the finder in MacOS.
  • How can you write a single user interface and
    make it portable across the different look and
    feel standards for these window managers?
  • Consider a facility management system for an
    intelligent house that supports different control
    systems such as Siemens Instabus, Johnson
    Control Metasys or Zumtobes proprietary
    standard.
  • How can you write a single control system that is
    independent from the manufacturer?

58
Abstract Factory
AbstractProductA
AbstractFactory CreateProductA CreateProductB
Client
ProductA1
ProductA2
AbstractProductB
CreateProductA CreateProductB
ConcreteFactory1
ProductB1
ProductB2
CreateProductA CreateProductB
ConcreteFactory2
59
Applicability for Abstract Factory Pattern
  • Independence from Initialization or
    Representation
  • The system should be independent of how its
    products are created, composed or represented
  • Manufacturer Independence
  • A system should be configured with one of
    multiple family of products
  • You want to provide a class library for a
    customer (facility management library), but you
    dont want to reveal what particular product you
    are using.
  • Constraints on related products
  • A family of related products is designed to be
    used together and you need to enforce this
    constraint
  • Cope with upcoming change
  • You use one particular product family, but you
    expect that the underlying technology is changing
    very soon, and new products will appear on the
    market.

60
OWL System for the The Intelligent Workplace at
Carnegie Mellon University
LightBulb
IntelligentWorkplace InitLightSystem InitBlindSys
tem InitACSystem
Facility Mgt System
InstabusLight Controller
ZumbobelLight Controller
Blinds
InitLightSystem InitBlindSystem InitACSystem
SiemensFactory
InstabusBlind Controller
ZumtobelBlind Controller
InitLightSystem InitBlindsystem InitACSystem
ZumtobelFactory
61
Builder Pattern Motivation
  • Conversion of documents
  • Software companies make their money by
    introducing new formats, forcing users to
    upgrades
  • But you dont want to upgrade your software every
    time there is an update of the format for Word
    documents
  • Idea A reader for RTF format
  • Convert RTF to many text formats (EMACS,
    Framemaker 4.0, Framemaker 5.0, Framemaker 5.5,
    HTML, SGML, WordPerfect 3.5, WordPerfect 7.0,
    .)
  • Problem The number of conversions is open-ended.
  • Solution
  • Configure the RTF Reader with a builder object
    that specializes in conversions to any known
    format and can easily be extended to deal with
    any new format appearing on the market

62
Builder Pattern (97)
BuildPart()
Construct()
Builder
Director
For all objects in Structure
Builder-gtBuildPart()
Represen- tation B
BuildPart() GetResult()
ConcreteBuilderB
BuildPart() GetResult()
ConcreteBuilderA
Represen- tation A
63
Example
Parse()
RTFReader
ConvertCharacter() ConvertFontChange ConvertPara
graph()
TextConverter
While (t GetNextToken()) Switch t.Type
CHAR builder-gtConvertCharacter(t.Char) FONT
bulder-gtConvertFont(t.Font) PARA
builder-gtConvertParagraph
ConvertCharacter() ConvertFontChange ConvertPar
agraph() GetASCIIText()
AsciiConverter
ConvertCharacter() ConvertFontChange ConvertPar
agraph() GetASCIIText()
HTMLConverter
ConvertCharacter() ConvertFontChange ConvertPar
agraph() GetASCIIText()
TexConverter
HTMLText
AsciiText
TeXText
64
Applicability for Builder Pattern
  • The creation of a complex product must be
    independent of the particular parts that make up
    the product
  • In particular, the creation process should not
    know about the assembly process (how the parts
    are put together to make up the product)
  • The creation process must allow different
    representations for the object that is
    constructed. Examples
  • A house with one floor, 3 rooms, 2 hallways, 1
    garage and three doors.
  • A skyscraper with 50 floors, 15 offices and 5
    hallways on each floor. The office layout varies
    for each floor.

65
Abstract Factory vs Builder
  • Abstract Factory
  • Focuses on product family
  • The products can be simple (light bulb) or
    complex
  • The abstract factory does not hide the creation
    process
  • The product is immediately returned
  • Builder
  • The underlying product needs to be constructed as
    part of the system but is very complex
  • The construction of the complex product changes
    from time to time
  • The builder patterns hides the complex creation
    process from the user
  • The product is returned after creation as a final
    step
  • Abstract Factory and Builder work well together
    for a family of multiple complex products

66
Summary
  • Structural Patterns
  • Focus How objects are composed to form larger
    structures
  • Problems solved
  • Realize new functionality from old
    functionality,
  • Provide flexibility and extensibility
  • Behavioral Patterns
  • Focus Algorithms and the assignment of
    responsibilities to objects
  • Problem solved
  • Too tight coupling to a particular algorithm
  • Creational Patterns
  • Focus Creation of complex objects
  • Problems solved
  • Hide how complex objects are created and put
    together

67
Conclusion
  • Design patterns
  • Provide solutions to common problems.
  • Lead to extensible models and code.
  • Can be used as is or as examples of interface
    inheritance and delegation.
  • Apply the same principles to structure and to
    behavior.
  • Design patterns solve all your software
    engineering problems
  • My favorites Composite, Bridge, Builder and
    Observer
About PowerShow.com