Upload
abner-fox
View
217
Download
0
Tags:
Embed Size (px)
Citation preview
Architectural Styles, Design Patterns, and ObjectsRobert T. Monroe (Doctoral Candiate)Andrew Kompanek (Research Programmer) Ralph Melton (Graduate Student)David Garlan (Associate Professor)(Carnegie Mellon University)
Presented By: Ken WallerEEL 6883 – Software
Engineering II
Agenda Review and Present the Paper Gives my Thoughts on the Paper
Strengths Weaknesses Suggestions for Improvement
Provide more information on Design Patterns
Give an Example of a Design Pattern Questions and Comments from the Class
But feel free to ask questions during the presentation as well
Paper Overview Introduction Define Software Architecture Design Define Architectural Styles Object-Oriented Design and
Software Architecture Define Design Patterns Explore Architectural Styles and
Design Patterns
Paper Introduction Goal: Simplify software design by capturing
(thus allowing reuse) and exploiting Design Knowledge
Two approaches: Architectural Level
Gross structure Key issues (system wide): scalability, portability,
communication protocols, processing rates, performance
Informal (block) diagrams Architectural Styles
Object Oriented Level Encapsulate data and behavior Define public interfaces Design Patterns
Software Architecture Phase Occurs after requirements analysis, before
detailed design Break the (conceptualized) software system
into large grain components (subsystems) Define behavior Define relationships Allocate requirements Several well known
Client-server, Layered, Pipes Define modules
Processes, dynamic libraries, static libraries
Software Architecture
Requirements (from customer)
Req 1Req 2
…Req n
Conceptual System
Analy
sis
Req 1..i
Req i..j
Req j..n
Arch
. Bre
akdow
n
Subsys. 1
Subsys. 2
Subsys. 3
Software Architecture Design Serves two purposes:
Captures Behavioral Abstraction (critical requirements)
Describes system’s “Conscience” Guides system evolution How easily can changes be made? How will system integrity be effective by change? “Load Bearing Walls” – Large Grain components
or subsystems
Software Architecture Design Concerned with:
Structure: Large grain components (subsystems) and their relationships
Interaction: Pipes, Client Server, Peer-to-Peer
System-wide Properties: Data rates, latencies, behavioral change propagation
Suggested simple (1-2 pages) description
Architectural Styles Capture past experiences with Architectural
Design (i.e. Client-Server, Pipes, etc.) Formal architectural styles provide their own
“language” May be graphical/diagram-based (similar to UML) May be textual based (similar to pseudo-code –
Wright architecture description language) Provides:
Common Vocabulary of Design Elements (clients, parsers, database)
Design Rules/Constraints Semantics System Analysis
Architectural Styles
Benefits Design Reuse Code Reuse (may be domain
dependant) Communication among colleagues Interoperability System Analysis
Architectural Styles Visual Example: Pipe and filter architecture
Easily Conveys the idea Filter 1 may only send data to Filter 2 Filter 2 may only receive data from Filter 1 Filter 1 may not receive data Filter 2 may not send data Pipe is the data transport mechanism
Filter 1(Source)
Filter 2(Sink)
Pipe
Object-Oriented Design and Software Architecture
Object-Oriented Design can address some issues associated with architecture design
Downfall of OO is inability to describe rich interfaces and protocols
Object-Oriented Design and Software Architecture Consider a simple UML class diagram to
describe the Pipe and Filter architecture Association between two Filter objects
Filter
Doesn’t constrain the direction of communication
(pipe)
(source)
(sink)
Filter Filter(source)
(sink)
Object-Oriented Design and Software Architecture
More refined UML class diagram Filters no longer know about each
other
Filter
Pipe
Read_from()Write_to()
(source)
(sink)
Filter Filter(source)
(sink)Pipe
Still cannot ensure proper use
(cannot formally specify)
Design Patterns Object Oriented approach Captures designs that require cooperation
between multiple objects/classes Make common design solutions explicit Requirements for specifying and reusing:
Design domain must be well understood Must support encapsulation of design
elements Must have a collection of well-known design
idioms (phrases)
Design Patterns for Pipe and Filter Simplicity is lost (vs. Architectural Styles) Still cannot specify all of the constraints
Only sink may invoke dequeue Only source may invoke enqueue
SourceWrite_to( )
SinkRead_from( )
PipeEnqueue()Dequeue()
Filter
Filter FilterPipeSource Sink
Architectural Styles and Design Patterns Architectural Styles provide their own design
language Focus on large grain components
Design Patterns utilize UML as the design language
Focus on objects Architectural Styles tend to solve system wide
problems System wide analysis
Design Patterns tend to solve small, specific problems
Can easily be translated into code
Paper Summary Architectural Styles are not “better”
than Design Patterns Design Patterns are not “better” than
Architectural Styles Both appropriate, but at different times
Use architectural styles during architectural (top level) design
Use design patterns during detailed (subsystem) design
Complimentary to one another
My Thoughts on the Paper Strengths
Use of Diagrams Good description of Architectural Styles advantages vs.
Design Patterns Weaknesses
Poor Organization No numbering of sections Ideas spread out across many sections Many phrases used multiple times (Perhaps too many
authors?) Not enough on Design Patterns
Areas for Improvement Better organization
Condense related ideas Incorporate a number system
More detail on Design Patters
More on Design Patterns Summerville (in “Software
Engineering”, V7) suggests that a Design Patterns Are abstract designs Include algorithms and data types Have four important elements
Meaningful Name Problem Description Solution Description (algorithms, data types) Consequences (results and trade-offs)
More on Design Patterns Famous book: “Design Patterns: Elements
of Reusable Object-Oriented Software” Serves as a Catalog of Design Patterns
Similar to the idea of a Pattern Handbook Divides patterns into three categories
Creational: Patterns that govern the creation of objects
Structural: Patterns that govern composition of large structures
Behavioral: Patterns that assign responsibilities (algorithms) to objects
More on Design Patterns Examples
Creational Factory Singleton
Structural Adapter Bridge
Behavioral Memento Mediator
More on Design Patterns Outline used:
Intent: Quick description Also known as: Alternative names Motivation: Background of the problem solved Applicability: Situations Structure: UML class diagrams Participants: Classes/objects used Collaborations: UML sequence diagrams Consequences: Tradeoffs and results Implementation: Language specific issues Sample Code: C++ Code snippets Known Uses: Real world examples Related Patterns: Similar patterns
Example of a Design Pattern:Memento
Intent: Capture an objects internal state
AKA: Token Motivation: Undo commands Applicability: When an objects
internal state may need to be restored later
Example of a Design Pattern:Memento (continued)
Structure
OriginatorSetMemento(Memento m)
CreateMemento()
state
MementoGetState()SetState()
state
Caretaker
Participants: Memento: Stores internal state Originator: Creates and uses mementos Caretaker: Manages mementos
Example of a Design Pattern:Memento (continued)
Collaborations:
Caretaker Originator Memento
CreateMemento( ) new
SetState( )
SetMemento(Memento) GetState(
)
Example of a Design Pattern:Memento (continued) Implementations:
class Memento{ … private: friend class Originator; Memento(); …};
Sample Code: Not covered here Known Uses: Older applications Related Patterns: Command and Iterator
My Experiences with Pattrens
Patterns should be regarded as Frameworks Will have to modify to “fit” into your
program
Additional References Sommerville, Ian. “Software Engineering
Seventh Edition” Section 18.2 “Design Patterns” (pages 421-
423) Gamma, Erich; Helm, Richard; Johnson,
Ralph; and Vlissides, John. “Design Patterns: Elements of Reusable Object-Oriented Software” Memento Design Patter (pages 283-291)
Questions? Comments?
Thank you!