Architectural Styles Design Patterns and Objects Robert T

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 n n Review and Present the Paper Gives my Thoughts on the Paper n n n Strengths Weaknesses Suggestions for Improvement Provide more information on Design Patterns Give an Example of a Design Pattern Questions and Comments from the Class n But feel free to ask questions during the presentation as well

Paper Overview n n n 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 n n Goal: Simplify software design by capturing (thus allowing reuse) and exploiting Design Knowledge Two approaches: n Architectural Level n n n Gross structure Key issues (system wide): scalability, portability, communication protocols, processing rates, performance Informal (block) diagrams Architectural Styles Object Oriented Level n n n Encapsulate data and behavior Define public interfaces Design Patterns

Software Architecture Phase n n n 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 n n Client-server, Layered, Pipes Define modules n 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 n Serves two purposes: n n Captures Behavioral Abstraction (critical requirements) Describes system’s “Conscience” n n 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 n Concerned with: n n 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 n n Capture past experiences with Architectural Design (i. e. Client-Server, Pipes, etc. ) Formal architectural styles provide their own “language” n n n May be graphical/diagram-based (similar to UML) May be textual based (similar to pseudo-code – Wright architecture description language) Provides: n n Common Vocabulary of Design Elements (clients, parsers, database) Design Rules/Constraints Semantics System Analysis

Architectural Styles n Benefits n n n Design Reuse Code Reuse (may be domain dependant) Communication among colleagues Interoperability System Analysis

Architectural Styles n Visual Example: Pipe and filter architecture n n n Easily Conveys the idea Filter 1 may only send data to Filter 2 may only receive data from 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 n n 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 n Consider a simple UML class diagram to describe the Pipe and Filter architecture n Association between two Filter objects (source) Filter (pipe) Filter (source) (sink) Doesn’t constrain the direction of communication Filter

Object-Oriented Design and Software Architecture n More refined UML class diagram n Filters no longer know about each other Filter (source) Pipe (sink) Filter (sink) (source) Pipe Read_from() Write_to() Still cannot ensure proper use (cannot formally specify)

Design Patterns n n Object Oriented approach Captures designs that require cooperation between multiple objects/classes Make common design solutions explicit Requirements for specifying and reusing: n n n 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 n n Only sink may invoke dequeue Only source may invoke enqueue n n Filter Source Write_to( ) Sink Read_from( ) Pipe Enqueue() Dequeue() Filter Source Pipe Sink Filter

Architectural Styles and Design Patterns n Architectural Styles provide their own design language n n Design Patterns utilize UML as the design language n n Focus on objects Architectural Styles tend to solve system wide problems n n Focus on large grain components System wide analysis Design Patterns tend to solve small, specific problems n Can easily be translated into code

Paper Summary n n n Architectural Styles are not “better” than Design Patterns are not “better” than Architectural Styles Both appropriate, but at different times n n n Use architectural styles during architectural (top level) design Use design patterns during detailed (subsystem) design Complimentary to one another

My Thoughts on the Paper n Strengths n n n Use of Diagrams Good description of Architectural Styles advantages vs. Design Patterns Weaknesses n Poor Organization n n 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 n Better organization n Condense related ideas Incorporate a number system More detail on Design Patters

More on Design Patterns n Summerville (in “Software Engineering”, V 7) suggests that a Design Patterns n n n Are abstract designs Include algorithms and data types Have four important elements n n Meaningful Name Problem Description Solution Description (algorithms, data types) Consequences (results and trade-offs)

More on Design Patterns n n Famous book: “Design Patterns: Elements of Reusable Object-Oriented Software” Serves as a Catalog of Design Patterns n n Similar to the idea of a Pattern Handbook Divides patterns into three categories n n n 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 n Examples n Creational n n n Structural n n n Factory Singleton Adapter Bridge Behavioral n n Memento Mediator

More on Design Patterns n Outline used: n n n 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 n n 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) n n Structure Originator Memento Set. Memento(Memento m) Create. Memento() Get. State() Set. State() state Caretaker Participants: n n n Memento: Stores internal state Originator: Creates and uses mementos Caretaker: Manages mementos

Example of a Design Pattern: Memento (continued) n Collaborations: Caretaker Originator Create. Memento( ) new Set. State( ) Set. Memento(Memento) Get. State( ) Memento

Example of a Design Pattern: Memento (continued) n Implementations: class Memento { … private: friend class Originator; Memento(); … }; n n n Sample Code: Not covered here Known Uses: Older applications Related Patterns: Command Iterator

My Experiences with Pattrens n Patterns should be regarded as Frameworks n Will have to modify to “fit” into your program

Additional References n Sommerville, Ian. “Software Engineering Seventh Edition” n n 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” n Memento Design Patter (pages 283 -291)

Questions? Comments?

Thank you!