Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
1
Software EngineeringITCS 3155Fall 2008
Dr. Jamie PaytonDepartment of Computer ScienceUniversity of North Carolina at Charlotte
Dec. 2, 2008
Lectures 24 and 25Introduction to Architectural Styles and
Design Patterns
22
AnnouncementsDeliverable 3
Extensions: due Dec. 2 at 11:59 pm (tonight)Assessments• Extensions: due Dec. 3 at 11:59 pm• Use new links
Sent by emailPosted on website
Final examDec. 16 at 11:30 amExam review• In class on Dec. 9• Come to class prepared with questions
Extra creditAttend ACM Distinguished Speaker talk • Friday, Dec. 5 at 3:00 pm • Woodward 106• Sign in with me to get extra credit
33
Lecture Overview
ResourcesChapter 15• Architectural Styles
Chapter 16• Mid-Level Object-Oriented Design Patterns
Chapter 17• Broker Design Patterns
Chapter 18• Generator Design Patterns
Chapter 19• Reactor Design Patterns
GoF Book• Design Patterns: Elements of Reusable Object-Oriented Software
4
Software Design Patterns
A pattern is a way of reusing abstract knowledge about design
a description of the problemthe essence of its solution
Patterns allow programmers to share knowledge about design
Provide a shared design vocabulary
5
History of Design PatternsArchitect Christopher Alexander
A Pattern Language (1977)A Timeless Way of Building (1979)Example architectural pattern• Pools of light
Uniform lighting makes people feel disconnected and disorientedCreate pools of light, will result in pleasant gathering places
6
History of Design Patterns in Software Engineering Community
“Gang of four” (GoF)• Gamma, Helm, Johnson, Vlissides
Design Patterns: Elements of Reusable Object-Oriented Software (1995)
Pattern-oriented Software Architecture (POSA)Buschmann, Meunier, Rohnert, Sommerlad, Stal
Many moreConferences, symposia, other books
7
Applying Patterns in Software Design
Reusable design knowledge can be captured at different levels of abstraction
Architectural styles or patterns• Capture design of entire systems and sub-systemsDesign patterns• Involve several interacting classes or operationsData structures & algorithms• Low-level, detailed design patternsIdioms• Ways of doing things that are specific to a programming
language
8
Architectural Styles
An architectural style describes the kinds of architectural components and their interactions
In other words, a pattern of decomposition of major software parts and their relationships, responsibilities, interactions, etc• DeSCRIPTR concepts
Widely used architectural stylesLayered architecturePipe and filterShared dataEvent drivenModel View Controller (MVC)
9
Example:Information System for Political Elections
A=10%B=40%C=30%D=20%
Application data
A
BC
D
A DCB
Relative Percentages
Y 10 40 30 20
X 15 35 35 15
Z 10 40 30 20
A B C D
Change notification
Requests, modifications
10
Architectural Style Example:Model-View-Controller (MVC)
ApplicabilityInteractive applications with a flexible human-computer interface
Problem context• The display presented to the user frequently changes over time
in response to input or computation• Different users have different needs for how they want to view
the program’s information • Want to reflect data changes to all users in the way that they
want to view them• Want to make it easy to make changes to the user interface
11
Model-View-Controller (MVC)
Solution: separate the data being manipulated from the manipulation logic and the details of displayThree components:
Model• A problem-domain component with data and operations• Independent of the user interface
View• A data display component
Controller• A component that receives and acts on user input
12
MVC Participants and Responsibilities
View Each view is associated with a controller Each view is associated with the modelUser interacts with system only through a view’s controllerDefines an update procedure that is called when model changes
Controller Translates user input into service requests• Input is usually mouse click or keyboard input events • Makes service requests on model or view
May need to define update procedure
13
MVC Participants and Responsibilities
ModelIf model is updated, model notifies all interested parties (registered views and possibly controllers) of changeViews will retrieve new data from model and update displayed information
14
MVC Solution:Static Structure
15
MVC Solution:Behavior
16
Consequences:MVC Advantages
Views and controllers can be easily be added, removed, or changed
No need to change the domain-specific data model
Views can be added or changed during executionUser interface components can be changed, even at runtime
17
Consequences:MVC Disadvantages
Views and controller are often hard to separateFrequent updates may slow data display and degrade user interface performanceThe MVC style makes user interface components (views, controllers) highly dependent on model components
18
Mid-level Design Patterns
A mid-level design pattern model collaborations between modules (typically classes)
Referred to simply as “design patterns”Main focus of research in software design patterns
19
Design Pattern Elements
NameA meaningful pattern identifier
Problem description (Applicability)Solution description
Not a concrete design but a template for a design solution that can be instantiated in different ways
ConsequencesThe results and trade-offs of applying the pattern
2020
Purpose of Patterns
BehavioralDescribe how classes or objects interact and distribute responsibility• Observer (last time)• Mediator
StructuralDescribe how classes or objects should be composed• Façade• Adapter• Proxy
CreationalConcern the process of object creation• Factory method• Abstract Factory
2121
Scope of Patterns
ScopeAnother dimension for classifying patternsClass patterns• Relationships between classes and subclasses
Established through inheritanceFixed at compile-time
Object patterns• Relationships between objects
Changeable at run-time(most patterns)
2222
Purpose and ScopeBehavioral
Class• Use inheritance to describe algorithms and flow of controlObject• Describe how a group of objects cooperate to perform a task
StructuralClass• Use inheritance to compose classesObject• Describe how to compose objects
CreationalClass• Defer some part of object creation to a subclassObject• Defer some part of object creation to another object
2323
Scope Purpose
Creational Structural Behavioral
Class Factory Method Adapter (class) InterpreterTemplate Method
Object Abstract FactoryBuilderPrototypeSingleton
Adapter (object)BridgeCompositeDecoratorFaçadeProxyFlyweight
Chain of ResponsibilityCommandIteratorMediatorMementoObserverStateStrategyVisitor
24
Textbook Classification
Broker patternsa client needs a service from a suppliera broker mediates interaction between client and supplier
Generator patternsa client needs a new instance of a producta generator class supplies the instance
Reactor patternsa client needs to respond to an event in a targetclient delegates this responsibility to a reactor
25
Category Analogies
Brokersstock brokers who mediate interactions between an investor (client) and the stock market (supplier)
Generatorsinterior designers who obtain material from manufacturers (products) on behalf of their clients
Reactors lawn service companies that respond to conditions in a lawn (target) on behalf of a homeowner (client).
26
GoF Taxonomy of Design Patterns
BehavioralObserver (reactor)Mediator (broker)
StructuralAdapter (broker)Façade (broker)Proxy (broker)
CreationalSingleton (generator)Abstract Factory (generator)
Categories by GoF, textbook’s classification in parentheses
2727
Patterns by Example:Multiple Displays Enabled by Observer
A=10%B=40%C=30%D=20%
Application data
A
BC
D
A DCB
Relative Percentages
Y 10 40 30 20
X 15 35 35 15
Z 10 40 30 20
A B C D
Change notification
Requests, modifications
28
Behavioral Pattern Example:The Observer Pattern
NameObserver
DescriptionReduces coupling between interacting classes
Problem descriptionUsed when one or more observers must track changes to an object
Solution descriptionUse a change-propagation mechanism between info provider (subject) and the components that use it to display (observers)• The register and notify approach !!!
2929
The Observer Pattern
NameObserver• a.k.a. publish-subscribe
Description/ApplicabilityGeneral: When change in object state requires consistent reflection of change in other objects• Want dependent objects to be decoupled from one another
Specific: Separates the display of object state from the object itself
Problem descriptionUsed when multiple displays of state are needed• need changes to state to be reflected consistently across all displays
3030
The Observer Pattern
Solution descriptionUse a change-propagation mechanism between info provider (subject) and the components that use it to display (observers)• Subject
Stores state of interestProvides ability for Observers to attach/detachCalls Observer’s update interface
• ObserverProvides an update interfaceAttaches and detaches itself from Subject
3131
The Observer Pattern
Subject
attach (Observer)
detach (Observer)
notify ()
Observer
update()
Concrete Observer
observerStateConcrete Subject
getState()setState()
subjectState
For all x in observers{x.update(); }
observerState=subject getState();
32
Observer Pattern
ConsequencesCan add/remove observers at any time without modifying subjectCan reuse subjects without reusing observers (and vice-versa)Unexpected updates to subject can cause a cascade of unnecessary update operations on observer
32
3333
An Aside:Observer and MVC
People often confuse the Observer design pattern with the MVC architectural style MVC describes an architecture:
Model• Manages data• Executes business processing operationsView• Displays information and supports user interaction
That is, the user interface
Controller• Processes and responds to events • Notifies model of events
Typically responds to user input and invokes operation/change on model
34
Observer’s Relationship to MVC
One way to think about MVC at mid-level design (without the observer pattern):
The model keeps track of all views.
The model is updated then tells each view that the model was updated…
:Model :View
updateBarGraph(b)
updatePieChart(p)
(make some change to state)
35
Observer’s Relationship to MVC
One way to think about MVC at mid-level design (without the observer pattern):
The model keeps track of all views.
The model is updated then tells each view that the model was updated…
…but the whole point of MVC is to remove ties between model and view!
:Model :View
updateBarGraph(b)
updatePieChart(p)
(make some change to state)
36
Observer’s Relationship to MVC
MVC design decoupled with the Observer pattern:
The View previously registered interest in changes to model…
…now, the model doesn’t need to know anything about the views…
…it just notifies registered parties of interest when state changes.
:Model :View
update()
getData()
notify()
3737
MVC Solution:Static Structure Observer
update()
View
myModel
myController
initialize(Model)makeControlleractivate()display()update()
For all x in observers{x.update(); }
Model
attach (Observer)
detach (Observer)notify ()getDataperformService
Controller
myModel
myController
initialize(Model, View)handleEvent(Event)update()
represents
manipulates
calls-service-on
38
GoF Taxonomy of Design Patterns
BehavioralObserver (reactor)Mediator (broker)
StructuralAdapter (broker)Façade (broker)Proxy (broker)
CreationalSingleton (generator)Abstract Factory (generator)
Categories by GoF, textbook’s classification in parentheses
3939
Word Processor Example
Want to build a word-processorNeed to be able to click a “save” button to save workNeed to be able to print a file by clicking “print” button
We have a Button and a ButtonListener class Upon Button click, will notify registered ButtonListeners of event
We have a DocManager class alreadyHas a printDocument() methodCan’t change DocManager; have to use as-is
How can we combine these together?
4040
The Adapter Pattern
DescriptionConvert interface of a class into another interface clients expectAdapter lets classes work together that could not otherwise because of incompatible interfaces
ApplicabilityNeed to use an existing class whose interface does not matchNeed to make use of incompatible classes
4141
The Adapter Pattern (2)
ParticipantsTarget (ButtonListener)• Defines the domain-specific interface that the Client uses
Client (Button)• Collaborates with objects conforming to the Target interface
Adaptee (DocManager)• Defines an existing interface that needs adapting
Adapter (a new thing we’re creating)• Adapts the interface of Adaptee to the Target Interface
4242
The Adapter Pattern: Approaches
Class AdapterAdapter class is a subclass of adaptee• Inherits operations• Overrides operations if needed• Add new operations to provide new interface
Object AdapterAdapter object holds a reference to adaptee• Delegates work to adaptee object
4343
The Adapter (Class) Pattern
4444
The Adapter (Object) Pattern
4545
Class Adapter for Word Processor Example
Button ButtonListener DocManager
MyDocManager
buttonPressed(Event e)buttonPressed(e){print();…}
4646
The Adapter Pattern:Consequences
ConsequencesClass adapter • Adapter commits to the concrete Adapter class
Won’t work when we want to adapt a class and its subclasses• Lets Adapter override some of Adaptee’s behavior• Introduces only one object, no pointer indirection• Cannot block access to public attributes and methods of
AdapteeObject adapter • Lets a single Adapter work with Adaptee and its subclasses• Makes it harder to override Adaptee behavior
Would have to create Adaptee subclass, make Adapter call subclass operations
4747
Applying the Adapter Pattern
AnalogyElectrical travel adapters
Design exampleThread safe PriorityQueue
Design choice between Object and Class Adapter• Must use Object Adapter if:
Adaptee has changeable public attributesCannot subclass adapteeCannot override methods of adaptee
48
GoF Taxonomy of Design Patterns
BehavioralObserver (reactor)Mediator (broker)
StructuralAdapter (broker)Façade (broker)Proxy (broker)
CreationalSingleton (generator)Abstract Factory (generator)
Categories by GoF, textbook’s classification in parentheses
49
Print Spooler Example
Have several printers that can be accessed within a systemPrint jobs are all served in priority order
Ordering can be defined by importance or arrival
Need just one print spooler to coordinate access to set of printers
50
The Singleton Pattern
DescriptionA software entity must be unique
ApplicabilityOnly single instance of a class should existSingle instance should be widely accessibleControl access to resource
50
51
The Singleton Pattern
SolutionRestrict access to constructorCreate only a single instance of a classAllow access only to single instance
51
52
The Singleton Pattern:Static Structure
52
ClientSingleton
-theInstance : Singleton = null
-Singleton()+ instance() : Singleton
if (theInstance == null)theInstance = new Singleton()
return instance
53
The Singleton PatternDynamic Behavior
53
:Client Singleton:Class
s = instance()
s: Singletoncreate[no instance]opt
54
The Singleton Pattern:Consequences
AdvantagesEasy to implementSingleton classes can be subclassed• Design flexibility
54
55
Summary
PatternsCapture reusable elements of designProvide a design vocabularyPattern repositories can provide inspiration, insight into design problem and solution
Patterns are expressed at different levelsArchitectural styles• MVCDesign patterns• Observer
Next timeTwo important design patterns you should know:• Singleton• Proxy