CS 501 Software Engineering Fall 1999 Lecture 10

CS 501: Software Engineering Fall 1999 Lecture 10 System Architecture I Data Intensive Systems

Administration Project Interim Report: Due October 14

Bouncing Ball Diagrams Example: http: //www. cs. cornell. edu/ domain name TCP connection HTTP get Client Servers

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)

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)

Example 1: Electricity Utility Billing First attempt: Transactions Data input Master file Each transaction handled as it arrives. Bills

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

Transaction Types Create account / close account Meter reading Payment received Other credits / debits Check cleared / check bounced Account query Correction of error etc. ,

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 person Error rate must be below 0. 01% System available 99. 9% of business hours

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

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

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

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

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

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)

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

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

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

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?