CS 5150 Software Engineering Lecture 14 System Architecture

CS 5150 Software Engineering Lecture 14 System Architecture 2 CS 5150 1

Administration Second and final presentations Sign up now Team members who were unable to come to the first presentation should attend the second CS 5150 2

Administration Quizzes There are 4 quizzes, 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: Quiz 1 Q 1 8. 1 CS 5150 Quiz 1, Q 2 8. 2 Quiz 2 Q 1 Quiz 2 Q 2 7. 4 8. 1 3

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 4

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. , CS 5150 5

Electricity Utility Billing First attempt: Transaction Data input Master file Bill Each transaction is handled as it arrives. CS 5150 6

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 • Awkward to answer customer queries • No process for error checking and correction • All activities are triggered by a transaction CS 5150 7

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 8

UML Deployment Diagram: Validation Data. Input Edit. Check Raw. Data Valid. Data Master. File Check CS 5150 9

Electricity Utility Billing Batch Processing: Master File Update errors Reports Validated transactions in batches CS 5150 Sort by account Batches of input data Master file update Bills 10

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 CS 5150 11

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 12

Online Inquiry: Use Case Answer. Customer. Server <<uses>> New. Transaction 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 13

Online Inquiry Customer Service 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 14

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 15

Data Intensive Systems with Real Time Transactions Example: A Small-town Stockbroker • Transactions Received by mail or over telephone For immediate or later action CS 5150 • Complex customer inquiries • Highly competitive market 16

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 17

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 18

Real-time Transactions Real-time transactions Products & services database CS 5150 Customer & account database External services 19

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

Stock Broker: Interface Diagram On. Line. TR Batch. TR External Product. DB CS 5150 Customer. DB 21

Practical considerations to include in Architecture and Specification • Real-time service during scheduled hours with batch processing overnight • Database consistency after any type of failure two-phase commit 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 22

Combining Architectural Styles: 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. These systems are examples of Repository Architectural Style. 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. CS 5150 23

Merger of Two Banks: Options A ? ? ? B ? ? ? CS 5150 24

Merger of Two Banks: Interface between the Databases Bank A Teller transactions Accounts database Batch input CS 5150 Bank B Teller transactions Both systems follow the repository style Accounts database Batch input 25

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 CS 5150 26

Merger of Two Banks: Interface between the Databases Bank A Bank B Teller transactions Accounts database Batch input CS 5150 Data transform Data exchange API Data transform Problem Accounts databases are rarely exactly equivalent. Accounts database Batch input 27

Systems Architecture for Network Systems: Distributed Data is held on several computer systems. A transaction may need to assemble data from several sources. CS 5150 28

Systems Architecture for Network Systems 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 CS 5150 29

Systems Architecture for Network Systems: Quality of Network Services Criteria in choosing a network architecture Performance Maximum throughput Latency Variations in throughput Real-time media (e. g. , audio) Business Suppliers, cost Trouble shooting and maintenance CS 5150 30

Systems Architecture for Network Systems: Choices Public Internet: Ubiquitous -- worldwide Low cost Private network: Security / reliability Predictable performance Choice of protocols (not constrained to TCP/IP) 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

Systems Architecture for Routers and Other Network Components • Interoperation with third party devices => remote devices may have faulty software • Restart after total failure • Defensive programming -- must survive => erroneous or malicious messages => extreme loads => time outs, dropped packets, etc. Evolution of network systems => Support for several versions of protocols • CS 5150 33

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 34

Time-Critical System: Buffering Example: A CD Controller for an Automobile 4 Input block 7 3 2 5 6 1 Output block The controller attempts to keep the next 12 seconds of sound in the buffer Circular buffer CS 5150 35

Time Critical System: Architectural Style - Daemon A daemon is used when messages sometimes arrive at closer intervals than 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 36

Time Critical System: Architectural Style - Model/Controller/View Example: An unmanned aircraft Controller Model View Controller: Sends control signals to the aircraft and receives instrument readings. Model: Translates data received from and sent to the aircraft into a model of flight performance. It uses domain knowledge about the aircraft and flight. View: Displays information about the aircraft to the user. CS 5150 37

Time-Critical System Example: Autonomous Land Vehicle GPS Steer Sonar Model Laser Control signals Throttle Controls Sensors CS 5150 Signal processing 38

Time Critical System: Autonomous Land Vehicle Extend model/controller/view Sensors Controller Model View Controls CS 5150 39

Software Considerations In some types of system architecture, non-functional requirements of the system may dictate the software design and development process. CS 5150 40

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. CS 5150 41

Software Considerations: Performance Resource considerations may dictate software design and implementation: • Low level language (e. g. , C) where programmer has close link to machine • Inter-process communication may be too slow (e. g. , C fork). • May implement special buffering, etc. , to control timings CS 5150 42

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

Software Considerations: Embedded Real-time Systems Software and hardware combined to provide an integrated unit, usually dedicated to a specific task: • • • Digital telephone Automobile engine control GPS Scientific instruments Seat bag controller The software may be embedded in the device in a manner that cannot be altered after manufacture. CS 5150 44

Software Considerations: Embedded Real-time Systems Hardware v. Software Design of embedded systems requires close understanding of hardware characteristics • Special purpose hardware requires special tools and expertise. • Some functions may be implemented in either hardware of software (e. g. , floating point unit) • Design requires separation of functions Distinction between hardware and software may be blurred. CS 5150 45

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 46

Coupling and Cohesion Coupling is a measure of the dependencies between two subsystems. If two systems are strongly coupled, it is hard to modify one without modifying the other. Cohesion is a measure of dependencies within a subsystem. If a subsystem contains many closely related functions its cohesion is high. An ideal breakdown of a complex system into subsystems has low coupling between subsystems with high cohesion within subsystems. CS 5150 47