DOC PREVIEW
CORNELL CS 501 - Lecture 13 System Architecture and Design I

This preview shows page 1-2-3-26-27-28 out of 28 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 28 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 28 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 28 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 28 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 28 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 28 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 28 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS 501: Software EngineeringAdministrationProject PresentationsSystem Architecture and DesignA. Data Intensive SystemsData Intensive Systems Example 1: Electricity Utility BillingCriticisms of First AttemptTransaction TypesTypical RequirementsBatch Processing: ValidationBatch Processing: Master File UpdateBenefits of Batch UpdatingOnline InquiryData Intensive Systems Example 2: A Small-town StockbrokerA Database ArchitectureDatabase ArchitectureReal-time TransactionsReal-time Transactions & Batch ProcessingArchitectural considerationsData Intensive Systems Example 3: Merger of Two BanksMerger of Two Banks: OptionsMerger of Two Banks: Architectural OptionsDiscussion of Pfleeger, Chapter 5Question 1: Design ReviewQuestion 2: Architectural StylesQuestion 3: CollaborationQuestion 4: ComponentsQuestion 5: Techniques for Improving Design1CS 501 Spring 2002CS 501: Software EngineeringLecture 13System Architecture and Design I2CS 501 Spring 2002Administration•Quiz 2. Pick up after class or from Rosemary Adessa, Upson 5147•Assignment 2. Remember to submit (a) requirements report(b) individual questionnaires •Project presentations on Wedneday afternoon. Can you start 15 minutes earlier than scheduled?3CS 501 Spring 2002Project PresentationsRequirements AnalysisSystem designUnit & Integration TestingSystem TestingOperation & MaintenanceProgram designCodingAcceptance TestingRequirementsDesignImplementation4CS 501 Spring 2002System Architecture and DesignThe 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)5CS 501 Spring 2002A. Data Intensive SystemsExamples• 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)6CS 501 Spring 2002Data Intensive SystemsExample 1: Electricity Utility BillingFirst attempt:Data inputMaster fileTransactionBillEach transaction handled as it arrives.7CS 501 Spring 2002Criticisms of First AttemptWhere 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 transactionThe requirements have not been specified!!!8CS 501 Spring 2002Transaction Types• Create account / close account• Meter reading• Payment received• Other credits / debits• Check cleared / check bounced• Account query• Correction of error• etc., etc., etc.,9CS 501 Spring 2002Typical 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 hours10CS 501 Spring 2002Batch Processing: ValidationData inputMaster fileEdit & validationread onlyerrorsValidated transactionsIncoming transactions11CS 501 Spring 2002Batch Processing: Master File UpdateMaster fileupdateBillsValidated transactionsin batchesSort by accounterrorsReportsInstructions12CS 501 Spring 2002Benefits 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 hardware13CS 501 Spring 2002Online InquiryMaster fileread onlyCustomer ServiceCustomer Service department can read file, make annotations, and create transactions, but not change the master file.New transaction14CS 501 Spring 2002Data Intensive SystemsExample 2: A Small-town Stockbroker• TransactionsReceived by mail or over telephoneFor immediate or later action• Complex customer inquiries• Highly competitive market15CS 501 Spring 2002A Database ArchitectureDatabase(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)16CS 501 Spring 2002Database ArchitectureCustomer & account databaseProducts & services databaseExternal services17CS 501 Spring 2002Real-time TransactionsCustomer & account databaseProducts & services databaseExternal servicesReal-time transactions18CS 501 Spring 2002Real-time Transactions & Batch ProcessingCustomer & account databaseProducts & services databaseExternal servicesReal-time transactionsBatch processingData input19CS 501 Spring 2002Architectural considerations•Real-time service during scheduled hours with batch processing overnight•Combine information from several databases•Database consistency after any type of failuretwo-phase commitreload from checkpoint + logdetailed audit trail•How will transaction errors be avoided?•How will transaction errors be corrected?•How will staff dishonesty be controlled?20CS 501 Spring 2002Data Intensive SystemsExample 3: Merger of Two BanksEach 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.21CS 501 Spring 2002Merger of Two Banks: Options??????AABB22CS 501 Spring 2002Merger of Two Banks: Architectural OptionsI. Convert everything to System A: convert databasesretrain staffenhance 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.23CS 501 Spring 2002Discussion of Pfleeger, Chapter 5Format:State a question.Ask a member of the class to answer. (Sorry if I pronounce your name wrongly.)Provide opportunity for others to comment.When answering:Stand up.Give your name or NetID. Make sure the TA hears it.Speak clearly so that all the class can hear.24CS 501 Spring


View Full Document

CORNELL CS 501 - Lecture 13 System Architecture and Design I

Documents in this Course
Quiz 2

Quiz 2

2 pages

Usability

Usability

31 pages

Quiz 1

Quiz 1

2 pages

Stulba;''

Stulba;''

33 pages

Load more
Download Lecture 13 System Architecture and Design I
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 13 System Architecture and Design I and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 13 System Architecture and Design I 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?