CS 552 Spring 2006 Architecture1 Architecture part 1 CS 552 Spring ‘06

CS 552 Spring 2006 Architecture2 Software Architecture Conceptually

CS 552 Spring 2006 Architecture3 Perspective 1960’s: Safeguard’s “On-Interrupt” Code 1970’s: Store and Forward Recovery Subsystem 1980’s: Congestion Management 1990’s: Distributed Computing 2000’s: Web Based Applications State-of-the-Practice: Scenario Testing State-of-the-Art: Software Fault Tolerance

CS 552 Spring 2006 Architecture4 REQUIREMENTS SPECIFICATIONS ALGORITHMS TRAFFIC PROJECTIONS FEATURE ENGINEERING ARCHITECTURE ENGINEERING TRAFFIC ENGINEERING PERFORMANCE ENGINNERING REPORTS SUPPORT AND OPERATIONS - COMPUTER CENTER - DEVELOPMENT MACHINE - TEST MACHINE SOFTWARE DEVELOPMENT HUMAN FACTORS DEVELOPMENT SOFTWARE MANUFACTURING INTEGRATION TO SITES

CS 552 Spring 2006 Architecture5

6 Kruchten’s “4 + 1”Model for Developing Software Architecture + 1 Use Cases + 1 Business Scenario + View 1 Logical -- End Users View 2 Process -- System Integrators View 3 Physical -- Engineers View 4 Development -- Programmers This is an innovative and comprehensive integration of the abstractions needed for software system design

CS 552 Spring 2006 Architecture7 Software Engineering Tailored OO Application Software Reusable Software Vendor Software User Programs Client Personal Computer Client Workstation Application Server Large Data Server

CS 552 Spring 2006 Architecture8 Mars Rovers: Spirit and Opportunity

CS 552 Spring 2006 Architecture9 Search for traces of water on Mars. Two identical rovers: Spirit & Opportunity Sent to opposite sides of the planet Spirit was launched on June 10, 2003 and landed on January 3, 2004 Opportunity launched July 7, 2003, and landed on January 24, 2004

CS 552 Spring 2006 Architecture10 The Problem Timeline June 10, ’03 – Spirit launched January 3, ‘04 – Spirit rover lands January 21, ‘04 –Spirit acknowledges communications, but sends no data. First sign of problems January 23, ’04 – Spirit stops responding to requests.

CS 552 Spring 2006 Architecture11 More Timeline January 23, ’04 – Spirit sends 73Mb of ‘debug’ information January 29, ’04 – Engineers find way to communicate with Spirit Febuary 1, ’04 – Spirit restored

CS 552 Spring 2006 Architecture12 What Went Wrong? Thousands of extra files present in the rover’s memory Files left over from the 7-month flight Onboard software was having trouble managing the files Rover began to reset itself every hour

CS 552 Spring 2006 Architecture13 The Cause Files flooded the onboard flash memory System was not programmed to handle the thousands of files generated during the 7-month flight Case of ‘ thousands of files’ unspecified and untested.

CS 552 Spring 2006 Architecture14 The Cure Remove the thousands of extra files Reformat the flash memory and start from a clean slate

CS 552 Spring 2006 Architecture15 Loss Mission lost almost 10 days of data collection When Spirit was fixed, the same fix was applied to Opportunity before it became a problem.

CS 552 Spring 2006 Architecture16 Software Engineering Lessons Check past assumed boundaries –If the system is only supposed to handle a few hundred files, test it an order of magnitude larger. Allow for remote debugging Watchdog timers are good Beware of Deadlocks

CS 552 Spring 2006 Architecture17 Sensors Computer Antenna Shared Bus Physical View

CS 552 Spring 2006 Architecture18 Development View Source Code Modules Add Debug Traces Complier Loader Executables

CS 552 Spring 2006 Architecture19 Task 1 Reboot Task 2 Gather data -Camera Control -Filter and Compress… Task 3 Send images - Transmitter/Receiver Control - ARQ for Image Files Logical View

CS 552 Spring 2006 Architecture20 Task CPU Bus Time Conflict Deadlock Process View

CS 552 Spring 2006 Architecture21 Deadlocks occur when Processes are granted exclusive access to devices Processes may have multiple copies

CS 552 Spring 2006 Architecture22 Priorities Should Be Task 1 Reboot Task 3 Send images Task 2 Gather data

CS 552 Spring 2006 Architecture23 There was a mismatch between priorities set in: The extended machine The software application The software that controls the bus

CS 552 Spring 2006 Architecture24 Design Steps Object Oriented Modules CRC Design: –C: Class Name –R: Responsibility –C: Collaboration Refactor & Minimize Classes –Inheritance less than 3 Honor Component Constraints

CS 552 Spring 2006 Architecture25 Parnas Modules hide their design decisions form all other modules. Interface technology reveals ‘nothing’ about the inner workings of the module. Components: –Reliable Modules –Single Entry and Exit points. –Normalized data at interfaces.

CS 552 Spring 2006 Architecture26 Interfaces N A Contractor Mgt Heath Check

CS 552 Spring 2006 Architecture27 N A Contractor Mgt Heath Check Security Check

CS 552 Spring 2006 Architecture28 N A Contractor Mgt Heath Check Security Check S

CS 552 Spring 2006 Architecture29 Name = N Age = A, integer Contractor Mgt Heath Check Security Check Sex = M/F Tag = Value Interface Encapsulation Class

CS 552 Spring 2006 Architecture30 Atomicity:Two-Phase Commit Middleware lock records for update Phase One –process tries to lock all records it needs, one at a time –if needed record found locked, start over –(no real work done in phase one) If phase one succeeds, it starts second phase, –performing updates –releasing locks

CS 552 Spring 2006 Architecture31 Case Study: Buffer Failure Analysis Latent Fault in Buffer Flow Control. Software does not return ‘buffer full’ signal. Messages written to full buffers. Messages accepted and partially dropped. Application waits for complete message.

CS 552 Spring 2006 Architecture32 Case Study: Solution Fix the bug by returning appropriate indicator, or Re-launch message handler and avoid the problem: When buffers are half full. Periodically (rejuvenation) When a hang is detected.

CS 552 Spring 2006 Architecture33 Resources Get Resource requires 1.request the resource 2.use the resource 3.release the resource Must wait if request is denied –requesting process may be blocked –may fail with error code

CS 552 Spring 2006 Architecture34 Definition of Deadlock P rocesses are deadlocked when every process waits for an event that only another process in the set can cause One thread, no interrupts None of the processes can … –run –release resources –be awakened

CS 552 Spring 2006 Architecture35 Four Conditions for Deadlock 1. Mutual exclusion condition each resource assigned to 1 process or is available 2. Hold and wait condition process holding resources can request additional 3. No preemption condition previously granted resources cannot forcibly taken away 4. Circular wait condition must be a circular chain of 2 or more processes each is waiting for resource held by next member of the chain