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!