1 / 25

CS 501: Software Engineering Fall 2000

CS 501: Software Engineering Fall 2000. Lecture 14 System Architecture I Data Intensive Systems. Administration. Midterm examination, October 16, 7:30 to 8:30 p.m. -- Hollister B14 (note change of room) -- See course notices for sample questions. System Architecture.

dasan
Download Presentation

CS 501: Software Engineering Fall 2000

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. CS 501: Software EngineeringFall 2000 Lecture 14 System Architecture I Data Intensive Systems

  2. Administration Midterm examination, October 16, 7:30 to 8:30 p.m. -- Hollister B14 (note change of room) -- See course notices for sample questions

  3. System Architecture The overall design of a system: • Computers and networks (e.g., monolithic, distributed) • Interfaces and protocols (e.g., http, CORBA) • Databases (e.g., relational, distributed) • Security (e.g., smart card authentication, SSL) • Operations (e.g., backup, archiving, audit trails) • Software environments (e.g., languages, source control tools)

  4. Data Intensive Systems Examples • Electricity utility customer billing • Telephone company call recording and billing • Car rental reservations (e.g., Hertz) • Stock market brokerage (e.g., Charles Schwab) • Web sales (e.g., Amazon.com)

  5. Example 1: Electricity Utility Billing First attempt: Bill Master file Transaction Data input Each transaction handled as it arrives.

  6. Criticisms of First Attempt Where is this first attempt weak? The requirements have not been specified!!!

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

  8. Typical Requirements • All payments to be credited on day received • Customers must be able to query account by telephone • Cutting off service for non-payment requires management authorization • Data input staff should process n transactions per day per person • Error rate must be below 0.01% • System available 99.9% of business hours

  9. Batch Processing: Validation errors Edit & validation Incoming transactions Validated transactions Data input read only Master file

  10. Batch Processing: Master File Update Reports errors Validated transactions in batches Sort by account Bills Master file update Instructions

  11. Benefits of Batch Updating • All transactions for an account are processed together • Backup and recovery have fixed checkpoints • Better management control of operations • Efficient use of staff and hardware

  12. Online Inquiry Customer service read only Bills Master file Transactions Data input

  13. Example 2: A Small-town Stockbroker • Transactions Received by mail or over telephone For immediate or later action • Complex customer inquiries • Highly competitive market

  14. A Database Architecture Database(s): • Customer and account database • Financial products (e.g., account types, pension plans, savings schemes) • External databases (e.g., stock markets, mutual funds, insurance companies)

  15. Database Architecture Products & services database External services Customer & account database

  16. Real-time Transaction Real-time transactions Products & services database External services Customer & account database

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

  18. Architectural considerations • Real-time service during scheduled hours + batch processing overnight • Combine information from several databases • Database consistency after any type of failure two-phase commit reload from checkpoint + log detailed audit trail • How will transaction errors be avoided? • How will transaction errors be corrected?

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

  20. Merger of Two Banks: Options A B ??? ???

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

  22. Distributed Computing: General Problem An application that is running on one computer wishes to use data or services provided by another: • Network connection private, public, or virtual private network location of firewalls • Protocols point-to-point, multicast, broadcast message passing, RPC, distributed objects stateful or stateless • Quality of service

  23. Network Choices Public Internet: Ubiquitous -- worldwide Low cost Private network: Security Predictable performance Choice of protocols (e.g., IBM's SNA)

  24. Quality of Network Services Performance Maximum throughput Variations in throughput Real-time media (e.g., audio) Business Suppliers Trouble shooting and maintenance Upgrades

  25. Firewall Private network Public 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

More Related