SE.Software design Data Intensive system lecture 5c.pdf

software engineering lectures

1. Lecture 5c: Software Design-Data
Intensive Systems

Design and Design Decision Examples
Dec 2024, Orwa

2. 2
System Architecture
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, SSL)
• Operations (e.g., backup, archiving, audit trails)
• Software environments (e.g., languages, source control tools)

3. 3
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)
• Web sales (e.g., Amazon.com)

4. 4
Example 1: Electricity Utility Billing
First attempt:
Data input Master file
Transaction
Bill
Each transaction handled as it arrives.

5. 5
Criticisms of First Attempt
Where is this first attempt weak?
The requirements have not been specified!!!

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

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

8. 8
Batch Processing: Validation
Data input
Master file
Edit &
validation
read only
errors
Validated
transactions
Incoming
transactions

9. 9
Batch Processing: Master File Update
Master file
update
Bills
Validated
transactions
in batches
Sort by
account
errors
Reports
Instructions

10. 10
Benefits of Batch Updating
• All transactions for an account are processed together
• Backup and recovery have fixed checkpoints
• Better management control of operations
• Efficient use of staff and hardware

11. 11
Online Inquiry
Data input Master fileTransactions Bills
read only
Customer
service

12. 12
Example 2: A Small-town Stockbroker
• Transactions
Received by mail or over telephone
For immediate or later action
• Complex customer inquiries
• Highly competitive market

13. 13
A Database Architecture
Database(s):
• Customer and account database
• Financial products (e.g., account types, pension plans, savings
schemes)
• External databases (e.g., stock markets, mutual funds,
insurance companies)

14. 14
Database Architecture
Customer &
account database
Products &
services database
External
services

15. 15
Real-time Transaction
Customer &
account database
Products &
services database
External
services
Real-time
transactions

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

17. 17
Architectural considerations
• Real-time service during scheduled hours + 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?

18. 18
Example: 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.

19. 19
Merger of Two Banks: Options
???
???
A
B

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

21. 21
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
• Quality of service

22. 22
Network Choices
Public Internet:
Ubiquitous -- worldwide
Low cost
Private network:
Security
Predictable performance
Choice of protocols (e.g., IBM's System Network
Architecture, SNA)

23. 23
Quality of Network Services
Performance
Maximum throughput
Variations in throughput
Real-time media (e.g., audio)
Business
Suppliers
Trouble shooting and maintenance
Upgrades

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