CISC 323 Intro to Software Engineering A design pattern identifies - PowerPoint PPT Presentation

✂ ✁ ✂ ✂ ✁ ✁ ✂ ✁ � ✁ ✂ Recall: Design Patterns CISC 323 Intro to Software Engineering A design pattern • identifies and describes the key aspects of a solution to a common design problem Topic 7: Software Architecture Which classes, objects? How do they collaborate? Readings: What is its impact on quality attributes and thus system • in courseware requirements? • taken from: • allows the efficient communication of design expertise Software Architecture – Perspectives on an Emerging A design pattern catalogue Discipline • provides vocabulary/toolbox to discuss and weigh design by M. Shaw and D. Garlan solutions • allows designers to make informed decisions efficiently CISC 323, Winter 2003, Software Architecture 2 Recall: Design Patterns (cont’d) Software Architecture “The architecture of a software system defines that system in But also: terms of computational components and interactions among • A pattern only solves a single, local problem that the system construction poses those components”. --- Shaw & Garlan, page 3 => A system could use/consist of several patterns Examples for • Design patterns are not meant to describe the overall, • components : clients and servers, databases, filters, and global architecture of a system layers in a hierarchical system • While more abstract than code, some patterns are still • interactions : procedure/method calls, shared variable somewhat low-level and implementation-oriented , e.g., accesses, client-server protocols, database protocols etc Iterator An architecture shows Visitor • global topology of system and its Builder • impact on the system requirements CISC 323, Winter 2003, Software Architecture 3 CISC 323, Winter 2003, Software Architecture 4 1

✄ ✄ ✄ ✄ ✄ Very Simple Software Architecture Catalogue Requests for Example book info E-commerce system supporting ordering of books on the WWW HTTP Server Inventory Customers use web browser to find books, read about (e.g. Apache) Requests for delivery time books, make orders Requests for book info, Request delivery times, orders, Order availability Inventory subsystem can estimate time before book is sent etc. placement Order • Some books in inventory, some need to be ordered from System publisher HTML document After order is placed, sent to shipping subsystem to be filled HTTP Client For an example, see http://www.amazon.com (e.g., Netscape, Internet Explorer) CISC 323, Winter 2003, Software Architecture 5 Components and Connectors Example Connectors HTTP Connector : source component issues HTTP requests, target component Component : A software or Component responds with HTML document hardware entity implementing some part of the system’s CGI Connector : source component calls functionality target component; target component responds with HTML document Connector : a mechanism allowing components to interact. Java Call Connector : source component In this example, we have 3 calls method of target component using different connectors standard Java method calling conventions; target component returns some Java type CISC 323, Winter 2003, Software Architecture 7 CISC 323, Winter 2003, Software Architecture 8 2

☎ ✆ ✆ ☎ ✆ ✆ ☎ ☎ ☎ ✆ ☎ Analyzing Architectures Attribute-Driven Design Possibly important quality attributes of this architecture: Use quality attributes to motivate design decisions • Availability : What are risks of system not being Analyze architectural choices based on software architecture available (e.g., going down?) chosen Redundant servers? • Security : What are risks of (e.g.) credit card information being intercepted Perhaps use HTTPS connector instead of HTTP connector? • Performance : What are risks in case of many users? Perhaps use array of servers, with server redirection? • Modifiability : What if we want to add a telephone ordering service? CISC 323, Winter 2003, Software Architecture 9 CISC 323, Winter 2003, Software Architecture 10 Review of Quality Attributes Quality Attributes Recall Runtime • Requirements analysis determines desired quality • Performance, Security, Availability attributes of system Development Time • When designing software architecture, attempt to • Modifiability, Portability, Reusability, Testability Identify areas of risk where quality attributes may not be met Reduce risk through architectural choices • Some attributes amenable to mathematical expression (performance, availability), others less so (modifiability) CISC 323, Winter 2003, Software Architecture 11 CISC 323, Winter 2003, Software Architecture 12 3

✞ ✝ ✝ ✝ ✞ ✞ ✞ ✞ ✝ ✞ ✝ How to Measure Performance? How to Measure Performance? (cont’d) Jitter Feedback time • Time it takes system to respond to user’s actions • Variance in feedback time • For highly interactive tasks (e.g., drawing a box in E.g. in command-line systems such as Unix, low PowerPoint), typical requirement = 100 ms variance in time to complete commands may be more • For less interactive tasks (e.g., clicking a button), typical important than feedback time itself requirement = 1 s • Variance in delivery of continuous media such as video • For computational tasks may be longer (e.g., time to load Broadcast frame rate = 30 frames per second a web page might be acceptable at 10 s) Therefore frames delivered at 33 ms intervals Feedthrough time For video played over Internet (e.g., video on CBC • Time until other users can see result of one user’s actions web site), delivery of frames from remote source may • For highly interactive tasks (e.g., collaborative drawing, not be at such an even rate Internet telephone), typical requirement = 300 ms CISC 323, Winter 2003, Software Architecture 13 CISC 323, Winter 2003, Software Architecture 14 Buffering: Trading off Feedthrough Time How to Measure Performance (cont’d) and Jitter Turnaround time 1) Best Video frames • Average time to complete a batch job Video Video Feedthrough Source Player • For example, a database query Time Throughput Video Video • Average number of jobs / requests processed per time frames frames Video Video 2) Best Jitter Player unit Source Buffer used to • For example, smooth jitter. E.g., buffer 10 s number of database queries per second of frames Questions : number of polygons rendered per second • Which is better for an IP telephone? • Which is better for viewing the CBC news? CISC 323, Winter 2003, Software Architecture 15 CISC 323, Winter 2003, Software Architecture 16 4

✟ ✠ ✟ ✟ ✟ ✟ ✟ ✟ ✠ ✟ Availability Availability (cont’d) May be measured as Intuitively represents how much of the time the system is available for use Mean time to failure System may cease to be available through • Network failure Mean time to failure + Mean time to repair • Computer hardware failure (e.g., bad memory, disk crash) • Software failure Failure of application or operating system For example, if system fails on average every 20 days and takes one day to fix: Failure of application components to correctly Availability = 20 / (20 + 1) = 0.952 interoperate CISC 323, Winter 2003, Software Architecture 17 CISC 323, Winter 2003, Software Architecture 18 Mechanisms for Improving Availability Mechanisms for Improving Availability May improve availability by May improve availability by • increasing mean time to failure, • increasing mean time to failure, • decreasing mean time to repair or • decreasing mean time to repair or • both • both Techniques for decreasing mean time to repair: Techniques for decreasing mean time to repair: • redundancy • checkpointing ? • logging CISC 323, Winter 2003, Software Architecture 19 CISC 323, Winter 2003, Software Architecture 20 5

✡ ✡ ✡ ✡ ✡ ✡ ✡ ✡ ✡ ✡ ✡ ✡ ✡ ✡ Component Redundancy Component Redundancy (cont’d) A component responds to A component responds to requests/updates from other requests/updates from other sources Requests / sources Requests / updates updates Shadow Forwards all Shadow Component Forwards all Component Component Component requests/updates to shadow requests/updates to shadow component (e.g., on component (e.g., on different machine) Requests / different machine) updates Responses Responses If component fails, clients If component fails, clients Requests / reconnect to shadow updates reconnect to shadow component and keep going component and keep going CISC 323, Winter 2003, Software Architecture 21 CISC 323, Winter 2003, Software Architecture 22 Checkpointing/Logging Checkpointing/Logging Check- point If component fails, need to If component fails, need to retrieve its state when it is retrieve its state when it is system restarted state restarted Checkpointing : periodically Checkpointing : periodically updates updates write component state to disk write component state to disk Log Log Component Component Logging : write updates to file Logging : write updates to file on disk; can replay updates on disk; can replay updates when component restarted Requests / Requests / when component restarted updates Responses updates Responses Can combine checkpointing Can combine checkpointing and logging - e.g., log goes and logging - e.g., log goes back to last checkpoint back to last checkpoint CISC 323, Winter 2003, Software Architecture 23 CISC 323, Winter 2003, Software Architecture 24 6