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) Req 1 Req 2 … Req n Conceptual System Analysis Req 1..i Req i..j Req j..n Arch. Breakdown 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 (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 (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 Source Write_to( ) Sink Read_from( ) Pipe Enqueue() Dequeue() Filter PipeSourceSink

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 Originator SetMemento(Memento m) CreateMemento() state Memento GetState() SetState() state Caretaker Participants: Memento: Stores internal state Originator: Creates and uses mementos Caretaker: Manages mementos

Example of a Design Pattern: Memento (continued) Collaborations: CaretakerOriginatorMemento 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 ) Gamma, Erich; Helm, Richard; Johnson, Ralph; and Vlissides, John. “Design Patterns: Elements of Reusable Object-Oriented Software” Memento Design Patter (pages )

Questions? Comments?

Thank you!