1. CS 5150 Software Engineering
Lecture 14
System Architecture 2

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

3. 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 Q1 Quiz 1, Q2 Quiz 2 Q1 Quiz 2 Q2

4. 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)

5. Example: Electricity Utility Billing
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.,

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

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

8. Electricity Utility Billing Batch Processing: Edit and Validation
errors
Batches of incoming transactions
Edit & validation
Batches of validated transactions
Data input
read only
Master file

9. UML Deployment Diagram: Validation
DataInput
EditCheck
RawData
ValidData
MasterFile Check

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

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

12. Architectural Style: Master File Update (basic)
Example: billing system for electric utility
Data input and validation
Master file update
Mailing and reports
Sort
Advantages:
Efficient way to process batches of transactions.
Disadvantages:
Information in master file is not updated immediately. No good way to answer customer inquiries.

13. Online Inquiry: Use Case
AnswerCustomer
<<uses>>
NewTransaction
CustomerServer
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.

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

15. Architectural Style: Master File Update (full)
Example: billing system for electric utility
Data input and validation
Master file update
Mailing and reports
Sort
Customer
services
Advantages: Efficient way to answer customer inquiries.
Disadvantages: Information in master file is not updated immediately.

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

17. Real-time Transactions & Batch Processing
Data input
Real-time transactions
This is a combination of the Repository style and the Master File Update style
Customer & account database

18. 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)

19. Real-time Transactions
Products & services database
Customer & account database
External services

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

21. Stock Broker: Interface Diagram
OnLineTR
BatchTR
External
CustomerDB
ProductDB

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

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

24. Merger of Two Banks: Options
???
???

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

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

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

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

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

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

31. 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)

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

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

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

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

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

37. Time Critical System: Architectural Style - Model/Controller/View
Example: An unmanned aircraft
Model
View
Controller
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.

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

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

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

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

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

43. 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.
• Division into components, each with its own
acceptance test.

44. Software Considerations: Embedded Real-time Systems
Software and hardware are 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.

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

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

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