Transcript .ppt
Architectural Styles, Design
Patterns, and Objects
Robert T. Monroe (Doctoral Candiate)
Andrew Kompanek (Research Programmer)
Ralph Melton (Graduate Student)
David Garlan (Associate Professor)
(Carnegie Mellon University)
Presented By: Ken Waller
EEL 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)
Conceptual
System
Analysis
Arch. Breakdown
Req 1
Req 2
…
Req n
Req 1..i
Subsys. 1
Req i..j
Subsys. 2
Req j..n
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-toPeer
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)
Pipe
Filter 2
(Sink)
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
(source)
Filter
(pipe)
Filter
(source)
(sink)
(sink)
Doesn’t constrain the direction of communication
Filter
Object-Oriented Design and
Software Architecture
More refined UML class diagram
Filters no longer know about each other
Filter
Filter
(source)
Pipe
(sink)
Filter
(sink)
(source)
Pipe
Read_from()
Write_to()
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
Filter
Source
Write_to( )
Sink
Read_from( )
Pipe
Enqueue()
Dequeue()
Filter
Source
Pipe
Sink
Filter
Architectural Styles and
Design Patterns
Architectural Styles provide their own design
language
Design Patterns utilize UML as the design language
Focus on objects
Architectural Styles tend to solve system wide
problems
Focus on large grain components
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
Structural
Factory
Singleton
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
Originator
Memento
SetMemento(Memento m)
CreateMemento()
GetState()
SetState()
state
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
CreateMemento( )
new
SetState( )
SetMemento(Memento)
GetState( )
Memento
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!