CS 5150 Software Engineering Lecture 14 System Architecture 2 CS 5150 1 Administration Second assignment • Everybody who presented last week should have received comments on their presentation and report. • Several teams did not have a good schedule. If you are one of these teams, please create a schedule and include it with your progress report on Friday this week. CS 5150 2 Administration Next and final presentations Sign up now Team members who were unable to come to the first presentation should attend the second CS 5150 3 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 Q1 Test 1 Q2 Test 2 Q1 Test 2 Q2 7.7 6.3 6.1 7.9 Last time that this course was taught, poor test results were a common reason for getting a poor overall grade for the course CS 5150 4 Test 2 Questions 1 (a) Theater Ticket System allows a purchaser to buy theater tickets online. In Phase 1, a purchaser will be able to either: (a) buy tickets online, or (b) change or cancel a previous order. To buy tickets online, the purchaser searches a database of events to discover which tickets are available, chooses tickets, adds them to a shopping cart, and possibly continues buying more tickets for other performances. When all items have been chosen, the purchaser provides information to pay for the tickets by credit card. The purchaser can choose to have the tickets sent by mail, or arrange to collect them at the theater on the day of the performance. CS 5150 5 Test 2 Questions 1 (a) Draw a use case diagram that models the various ways in which a purchaser interacts with this system. The diagram should show a relationship to a use case, PaybyCredit, which models credit card payments. Definition from Lecture 9: A use case is a a task that an actor needs to perform with the help of the system. CS 5150 6 Test 2 Questions 1 (a) Example from Lecture 9: TakeExam <<includes>> Authenticate ExamTaker CS 5150 CheckGrades <<includes>> 7 Test 2 Questions 1 (a) Example from Wikipedia: CS 5150 8 Test 2 Questions 1 (a) FAQ about Use Cases See: http://www.andrew.c mu.edu/course/90754/umlucdfaq.html CS 5150 9 Test 2 Questions 1 (a) Simple Solution BuyTickets <<includes>> Purchaser <<includes>> These could be combined Change PaybyCredit <<includes>> Cancel CS 5150 10 Test 2 Questions 1 (a) More Complex Solution <<extends>> BuyTickets Purchaser SelectTickets <<extends>> AddtoCart <<includes>> PaybyCredit <<includes>> ChangeCancel CS 5150 11 Test 2 Questions 1 (a) Incorrect Solution BuyTickets SelectTickets <<includes>> AddtoCart Purchaser PaybyCredit <<includes>> ChangeCancel CS 5150 12 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) CS 5150 13 Architectural Style: Master File Update 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., CS 5150 14 Electricity Utility Billing First attempt: Transaction Data input Master file Bill Each transaction is handled as it arrives. CS 5150 15 Criticisms of First Attempt Where is this first attempt weak? • All activities are triggered by a transaction • 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 CS 5150 16 Electricity Utility Billing Batch Processing: Edit and Validation errors Batches of incoming transactions Edit & validation Data input Batches of validated transactions read only Master file CS 5150 17 UML Deployment Diagram: Validation DataInput EditCheck RawData ValidData MasterFile Check CS 5150 18 Electricity Utility Billing Batch Processing: Master File Update errors Reports Validated transactions in batches Sort by account Batches of input data Master file update Bills Checkpoints and audit trail CS 5150 19 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 CS 5150 20 Architectural Style: Master File Update (basic) Example: billing system for electric utility Data input and validation Sort Master file update Mailing and reports Advantages: Efficient way to process batches of transactions. Disadvantages: Information in master file is not updated immediately. No good way to answer customer inquiries. CS 5150 21 Online Inquiry: Use Case AnswerCustomer <<uses>> CustomerRep 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. CS 5150 22 Online Inquiry Customer Service Representative read only New transaction Master file Customer Service department can read the master file, make annotations, and create transactions, but cannot change the master file. CS 5150 23 Architectural Style: Master File Update (full) Example: billing system for electric utility Data input and validation Sort Master file update Mailing and reports Customer services Advantages: Efficient way to answer customer inquiries. Disadvantages: Information in master file is not updated immediately. CS 5150 24 Data Intensive Systems with Real Time Transactions Example: A Small-town Stockbroker • Transactions Received by mail or over telephone For immediate or later action • Complex customer inquiries • Highly competitive market CS 5150 25 Real-time Transactions & Batch Processing Real-time transactions This is a combination of the Repository style and the Master File Update style CS 5150 Data input Customer & account database 26 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) CS 5150 27 Real-time Transactions Real-time transactions Products & services database CS 5150 Customer & account database External services 28 Real-time Transactions & Batch Processing Real-time transactions Products & services database CS 5150 Data input Batch processing Customer & account database External services 29 Stock Broker: Interface Diagram OnLineTR BatchTR External ProductDB CS 5150 CustomerDB 30 Practical considerations to include in Architecture and Specification • Can real-time service during scheduled hours be combined 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. CS 5150 31 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. CS 5150 32 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. CS 5150 33 Time Critical System: Architectural Style - Daemon A daemon is used when messages sometimes arrive at closer intervals than the the time to process them. Daemon Spawned process 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 CS 5150 34 Software Considerations In some types of system architecture, non-functional requirements of the system may dictate the software design and development process. CS 5150 35 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. CS 5150 36 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. • CS 5150 Division into components, each with its own acceptance test. 37 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. CS 5150 38