1. CS 5150 1 CS 5150 Software Engineering Lecture 14 System Architecture 2

2. CS 5150 2 Administration Second assignment Everybody should have received comments on their presentation and report. Several teams were asked to contact the Teaching Assistant (e.g., a better schedule or improved visibility). Grading was rather generous.

3. CS 5150 3 Administration Next and final presentations Sign up now Team members who were unable to come to the first presentation should attend the second

4. CS 5150 4 Administration Tests There are 4 tests, each with 2 questions. The final grade will be based on the best 6 questions out of 8. Uncollected answer books are at 301 College Avenue. Average grades: Test 1 Q1Test 1 Q2Test 2 Q1Test 2 Q2 7.8 7.2 6.6 8.7 Last time that this course was taught, poor test results were a common reason for getting a poor overall grade for the course

5. CS 5150 5 System Design: Data Intensive Systems Examples Electricity utility customer billing (e.g., NYSEG) Telephone call recording and billing (e.g., Verizon) Car rental reservations (e.g., Hertz) Stock market brokerage (e.g., Charles Schwab) E-commerce (e.g., Amazon.com) University grade registration (e.g., Cornell)

6. CS 5150 6 Example: Electricity Utility Billing Requirements analysis has identified several transaction types: Create account / close account Meter reading Payment received Other credits / debits Check cleared / check bounced Account query Correction of error etc., etc., etc., Architectural Style: Master File Update

7. CS 5150 7 Electricity Utility Billing First attempt: Data input Master file Transaction Bill Each transaction is handled as it arrives.

8. CS 5150 8 Criticisms of First Attempt Where is this first attempt weak? A bill is sent out for each transaction, even if there are several per day Bills are not sent out on a monthly cycle Awkward to answer customer queries No process for error checking and correction All activities are triggered by a transaction

9. CS 5150 9 Electricity Utility Billing Batch Processing: Edit and Validation Data input Master file Edit & validation read only errors Batches of validated transactions Batches of incoming transactions

10. CS 5150 10 UML Deployment Diagram: Validation MasterFile Check EditCheck ValidData DataInput RawData

11. CS 5150 11 Electricity Utility Billing Batch Processing: Master File Update Master file update Bills Validated transactions in batches Sort by account errors Reports Batches of input data Checkpoints and audit trail

12. CS 5150 12 Electricity Utility Billing Benefits of Batch Updating All transactions for an account are processed together at appropriate intervals Backup and recovery have fixed checkpoints Better management control of operations Efficient use of staff and hardware Error detection and correction is simplified

13. CS 5150 13 Architectural Style: Master File Update (basic) Master file update Data input and validation Mailing and reports Example: billing system for electric utility Advantages: Efficient way to process batches of transactions. Disadvantages: Information in master file is not updated immediately. No good way to answer customer inquiries. Sort

14. CS 5150 14 Online Inquiry: Use Case CustomerServer AnswerCustomer NewTransaction > A customer calls the utility and speaks to a customer service representative. The representative can read the master file, but not make changes to it. If the representative wishes to change information in the master file, a new transaction is created as input to the master file update system.

15. CS 5150 15 Online Inquiry Master file read only Customer Service Customer Service department can read the master file, make annotations, and create transactions, but cannot change the master file. New transaction

16. CS 5150 16 Architectural Style: Master File Update (full) Example: billing system for electric utility Advantages: Efficient way to answer customer inquiries. Disadvantages: Information in master file is not updated immediately. Customer services Master file update Data input and validation Mailing and reports Sort

17. CS 5150 17 Data Intensive Systems with Real Time Transactions Transactions Received by mail or over telephone For immediate or later action Complex customer inquiries Highly competitive market Example: A Small-town Stockbroker

18. CS 5150 18 Real-time Transactions & Batch Processing Customer & account database Real-time transactions Data input This is a combination of the Repository style and the Master File Update style

19. CS 5150 19 Extending the Repository Architectural Style: A Small-town Stockbroker Databases Customer and account database Financial products (e.g., account types, pension plans, savings schemes) Links to external databases (e.g., stock markets, mutual funds, insurance companies)

20. CS 5150 20 Real-time Transactions Customer & account database Products & services database Real-time transactions External services

21. CS 5150 21 Real-time Transactions & Batch Processing Customer & account database Products & services database Real-time transactions Batch processing Data input External services

22. CS 5150 22 Stock Broker: Interface Diagram CustomerDB ProductDB OnLineTR BatchTR External

23. CS 5150 23 Practical considerations to include in Architecture and Specification Can real-time service during scheduled hours with batch processing overnight? How will the system guarantee database consistency after any type of failure? reload from checkpoint + log detailed audit trail How will transaction errors be avoided and identified? How will transaction errors be corrected? How will staff dishonesty be controlled? These practical considerations may be major factors in the choice of architecture.

24. CS 5150 24 Combining Architectural Styles: Merger of Two Banks Each bank has a database with its customer accounts. The databases are used by staff at many branches and for back-office processing. These systems are examples of Repository Architectural Style. The requirement is to integrate the two banks so that they appear to the customers to be a single organization and to provide integrated service from all branches. This is an example of working with legacy systems.

25. CS 5150 25 Merger of Two Banks: Options ??? A B

26. CS 5150 26 Merger of Two Banks: Interface between the Databases Accounts database Batch input Teller transactions Accounts database Batch input Teller transactions Bank A Bank B Both systems follow the repository style

27. CS 5150 27 Merger of Two Banks: Architectural Options I.Convert everything to System A convert databases retrain staff enhance System A (software and hardware) discard System B II.Build an interface between the databases in System A and System B III.Extend client software so that it can interact with either System A or System B database

28. CS 5150 28 Merger of Two Banks: Interface between the Databases Accounts database Batch input Teller transactions Accounts database Batch input Teller transactions Bank ABank B Data exchange API Problem Accounts databases are rarely exactly equivalent. Data trans- form

29. CS 5150 29 Systems Architecture for Network Systems: Firewall Public network Private network Firewall A firewall is a computer at the junction of two network segments that: Inspects every packet that attempts to cross the boundary Rejects any packet that does not satisfy certain criteria, e.g., an incoming request to open a TCP connection an unknown packet type Firewalls provide security at a loss of flexibility and a cost of system administration.

30. CS 5150 30 Time-Critical Systems A time-critical (real time) system is a software system whose correct functioning depends upon the results produced and the time at which they are produced. A soft real time system is degraded if the results are not produced within required time constraints e.g., a router is permitted to time out or lose a packet A hard real time system fails if the results are not produced within required time constraints e.g., a fly-by-wire control system for an airplane, must respond within specified time limits.

31. CS 5150 31 Time-Critical System: Buffering Input block Output block 1 2 3 4 5 6 7 Circular buffer Example: A CD Controller for an Automobile The controller attempts to keep the next 12 seconds of sound in the buffer

32. CS 5150 32 Time Critical System: Architectural Style - Daemon Daemon Example: Web server The daemon listens at port 80 When a message arrives it: spawns a processes to handle the message returns to listening at port 80 Spawned process A daemon is used when messages sometimes arrive at closer intervals than the the time to process them.

33. CS 5150 33 Architectural Style - Model/View/Controller Model Controller View Example: Control of a unmanned model aircraft Controller: Receives instrument readings from the aircraft and sends controls signals to the aircraft. Model: Translates data received from and sent to the aircraft, and instructions from the user into a model of flight performance. Uses domain knowledge about the aircraft and flight. View: Displays information about the aircraft to the user and transmits instructions to the model.

34. CS 5150 34 Time-Critical System Example: Autonomous Land Vehicle Sensors GPS Sonar Laser Signal processing ModelControl signals Steer Throttle Controls

35. CS 5150 35 Model/View/Controller for Web Applications ModelControllerView HTML HTTP WebBrowser Receives user input, e.g., GET or PUT Generates response, e.g., displays information

36. CS 5150 36 Model/View/Controller for Web Applications 1User interacts with the user interface (e.g., presses a mouse button). 2Controller handles input event from the user interface, (e.g., via a registered handler or callback) and converts the event into appropriate user action. 3Controller notifies Model of user action, possibly resulting in a change in Model's state (e.g., update shopping cart.). 4View interacts with Model to generate an appropriate user interface response (e.g., list shopping cart's contents). 5User interface waits for further user interactions. from Wikipedia 10/18/2009

37. CS 5150 37 Software Considerations In some types of system architecture, non-functional requirements of the system may dictate the software design and development process.

38. CS 5150 38 Software Considerations: Time-Critical System Developers of advanced time-critical software spend almost all their effort developing the software environment: Monitoring and testing -- debuggers Crash restart -- component and system-wide Downloading and updating Hardware troubleshooting and reconfiguration etc., etc., etc.

39. CS 5150 39 Software Considerations: Testing Example: Testing multi-threaded and parallel systems Several similar threads operating concurrently: Re-entrant code -- separation of pure code from data for each thread May be real-time (e.g., telephone switch) or non-time critical The difficult of testing real-time, multi-threaded systems may determine the entire software architecture. Division into components, each with its own acceptance test.

40. CS 5150 40 Software Considerations: Continuous Operation Many systems must operate continuously Software update while operating Hardware monitoring and repair Alternative power supplies, networks, etc. Remote operation These functions must be designed into the fundamental architecture.