1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 15 System Architecture and Design I

2 CS 501 Spring 2003 Administration Quiz 2 will not be counted towards the final grade. The quiz total grade will be the best three quizzes from the other four. Quiz 2 may be used to move borderline final grades up.

3 CS 501 Spring 2003 Project Presentations Requirements Analysis System design Unit & Integration Testing System Testing Operation & Maintenance Program design Coding Acceptance Testing Requirements Design Implementation

4 CS 501 Spring 2003 System Architecture and Design 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) Operations (e.g., backup, archiving, audit trails) Software environments (e.g., languages, source control tools)

5 CS 501 Spring 2003 Device-Aware User Interfaces Examples of devices: desk-top computer, fast network connection laptop computer, intermittent connectivity PalmPilot, intermittent use of cradle Smart telephone Digital camera, camcorder Device-aware user interfaces are aware of: => Performance of device => Connectivity

6 CS 501 Spring 2003 System Design: 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) E-commerce (e.g., Amazon.com)

7 CS 501 Spring 2003 Data Intensive Systems Example 1: Electricity Utility Billing First attempt: Data input Master file Transaction Bill Each transaction handled as it arrives.

8 CS 501 Spring 2003 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 No way to answer customer queries No process for error checking and correction All activities are triggered by a transaction

9 CS 501 Spring 2003 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.,

10 CS 501 Spring 2003 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

11 CS 501 Spring 2003 Batch Processing: Validation Data input Master file Edit & validation read only errors Validated transactions Incoming transactions

12 CS 501 Spring 2003 Batch Processing: Master File Update Master file update Bills Validated transactions in batches Sort by account errors Reports Instructions

13 CS 501 Spring 2003 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

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

15 CS 501 Spring 2003 Data Intensive Systems Example 2: A Small-town Stockbroker Transactions Received by mail or over telephone For immediate or later action Complex customer inquiries Highly competitive market

16 CS 501 Spring 2003 A Database Architecture Database(s): 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)

17 CS 501 Spring 2003 Real-time Transactions Customer & account database Products & services database External services Real-time transactions

18 CS 501 Spring 2003 Real-time Transactions & Batch Processing Customer & account database Products & services database External services Real-time transactions Batch processing Data input

19 CS 501 Spring 2003 Architectural considerations Real-time service during scheduled hours with 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? How will staff dishonesty be controlled?

20 CS 501 Spring 2003 Data Intensive Systems Example 3: 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. This is an example of working with legacy systems.

21 CS 501 Spring 2003 Merger of Two Banks: Options ??? A B

22 CS 501 Spring 2003 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.

23 CS 501 Spring 2003 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 Performance quality of service

24 CS 501 Spring 2003 Network Choices Public Internet: Ubiquitous -- worldwide Low cost Private network: Security / reliability Predictable performance Choice of protocols (not constrained to TCP/IP)

25 CS 501 Spring 2003 Quality of Network Services Criteria Performance Maximum throughput Variations in throughput Real-time media (e.g., audio) Business Suppliers Trouble shooting and maintenance

26 CS 501 Spring 2003 Distributed Computing: 1. Extensibility in Web Browsers Data types: helper applications, plug-ins Protocols HTTP, WAIS, Gopher, FTP, etc. proxies Executable code CGI scripts at server JavaScript at client Java applets Style sheets

27 CS 501 Spring 2003 Web Interface: Basic Web servers Web browser Static pages from server All interaction requires communication with server

28 CS 501 Spring 2003 Web User Interface: CGI Script User interface tables CGI Scripts Web servers Web browser Scripts can configure pages Scripts can validate information All interaction requires communication with server

29 CS 501 Spring 2003 Web User Interface: JavaScript User interface tables CGI Scripts Web servers Web browser JavaScripts can validate information as typed Some interactions are local Server interaction constrained by web protocols Java Script html

30 CS 501 Spring 2003 Web User Interface: Applet Any server Web servers Web browser Any executable code can run on client Client can connect to any server Applets

31 CS 501 Spring 2003 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.

32 CS 501 Spring 2003 Distributed Computing Example 2: Distributed Database two copies of the same data

33 CS 501 Spring 2003 Distributed Data and Replication Distributed Data Data is held on several computer systems. A transaction may need to assemble data from several sources. Replication Several copies of the data are held in different locations. Mirror: Complete data set is replicated Cache: Dynamic set of data is replicated (e.g., most recently used) With replicated data, the biggest problems are concurrency and consistency.

34 CS 501 Spring 2003 Distributed Computing Example 3: Searching User interface server User Databases This is an example of a multicast protocol. The primary difficulty is to avoid troubles at one site degrading the entire system (e.g., every transaction cannot wait for a system to time out). Broadcast Searching

35 CS 501 Spring 2003 Stateless Protocol v. Stateful Stateless protocol Example: http Open connection Send message Return reply Close connection State in http must be sent with every message (e.g., as parameter string) Cookies are a primitive way of retaining some state

36 CS 501 Spring 2003 Stateless Protocol v. Stateful Stateful (session) protocol Example: Z39.50 Open connection Begin session Interactive session End session Close connection Server remembers the results of previous transactions (e.g., authentication, partial results) until session is closed.