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!