1 / 31

Presented By: Ken Waller EEL 6883 – Software Engineering II

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.

mio
Download Presentation

Presented By: Ken Waller EEL 6883 – Software Engineering II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 Waller EEL 6883 – Software Engineering II

  2. 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

  3. 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

  4. Paper Introduction • Goal: Simplify software design by capturing (thus allowing reuse) and exploitingDesign 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

  5. 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

  6. Software Architecture Requirements (from customer) Req 1 Req 2 … Req n System Conceptual Arch. Breakdown Analysis Req 1..i Subsys. 1 Req i..j Subsys. 2 Req j..n Subsys. 3

  7. 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

  8. 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

  9. 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

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

  11. Filter 1 (Source) Filter 2 (Sink) Pipe 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

  12. 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

  13. 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 (source) Filter Filter (pipe) (source) (sink) (sink) Doesn’t constrain the direction of communication

  14. Pipe Read_from() Write_to() 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) Still cannot ensure proper use (cannot formally specify)

  15. 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)

  16. 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( ) Filter Source Pipe Sink Filter Pipe Enqueue() Dequeue()

  17. 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

  18. 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

  19. 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

  20. 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)

  21. 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

  22. More on Design Patterns • Examples • Creational • Factory • Singleton • Structural • Adapter • Bridge • Behavioral • Memento • Mediator

  23. 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

  24. 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

  25. Originator Memento GetState() SetState() SetMemento(Memento m) CreateMemento() state state Example of a Design Pattern:Memento (continued) • Structure Caretaker • Participants: • Memento: Stores internal state • Originator: Creates and uses mementos • Caretaker: Manages mementos

  26. Example of a Design Pattern:Memento (continued) • Collaborations: Caretaker Originator Memento CreateMemento( ) new SetState( ) SetMemento(Memento) GetState( )

  27. 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

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

  29. 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)

  30. Questions? Comments?

  31. Thank you!

More Related