Transcript PowerPoint

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 Q1
8.1
CS 5150
Quiz 1, Q2
8.2
Quiz 2 Q1
Quiz 2 Q2
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., etc., 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
DataInput
EditCheck
RawData
ValidData
MasterFile
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
AnswerCustomer
<<uses>>
CustomerServer
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
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
OnLineTR
BatchTR
External
ProductDB
CS 5150
CustomerDB
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
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
Distributed Data
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 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., 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 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.
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