Download Document

CS 501: Software Engineering
Lecture 14
System Architecture and Design 2
1
CS 501 Spring 2008
Administration
2
CS 501 Spring 2008
Data Intensive Systems
Example: A Small-town Stockbroker
• Transactions
Received by mail or over telephone
For immediate or later action
3
•
Complex customer inquiries
•
Highly competitive market
CS 501 Spring 2008
A Database Architecture
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)
4
CS 501 Spring 2008
Real-time Transactions
Real-time
transactions
Products &
services database
5
Customer &
account database
External
services
CS 501 Spring 2008
Real-time Transactions & Batch
Processing
Real-time
transactions
Products &
services database
6
Data
input
Batch
processing
Customer &
account database
External
services
CS 501 Spring 2008
Stock Broker: Interface Diagram
OnLineTR
BatchTR
External
ProductDB
7
CustomerDB
CS 501 Spring 2008
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?
*
8
These practical considerations may be major factors in
the choice of architecture.
CS 501 Spring 2008
Architectural Styles
An architectural style is system architecture that recurs in
many different applications.
See: Mary Shaw and David Garlan, Software architecture:
perspectives on an emerging discipline. Prentice Hall,
1996
9
CS 501 Spring 2008
Architectural Style: Pipe
Example: A three-pass compiler
Lexical
analysis
Code
generation
Parser
Output from one subsystem is the input to the next.
10
CS 501 Spring 2008
Architectural Style: Master File
Update
Example: billing system for electric utility
Data input and
validation
Master file
update
Mailing and
reports
Customer
services
Advantages: Efficient way to process batches of transactions.
Disadvantages: Information in master file is not updated
immediately.
11
CS 501 Spring 2008
Architectural Style: Repository
Example: A digital library
Input
components
Transactions
Repository
Advantages: Flexible architecture for data-intensive systems.
Disadvantages: Difficult to modify repository since all other
components are coupled to it.
12
CS 501 Spring 2008
Architectural Style: Repository with
Storage Access Layer
Repository
Input
components
This is sometimes
called a "glue" layer
Storage
Access
Transactions
Data Store
Advantages: Data Store subsystem can be changed without
modifying any component except the Storage Access.
13
CS 501 Spring 2008
Data Intensive Systems:
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.
14
CS 501 Spring 2008
Merger of Two Banks: Options
A
???
B
???
15
CS 501 Spring 2008
Merger of Two Banks:
Interface between the Databases
Bank A
Teller transactions
Accounts
database
Batch input
16
Bank B
Teller transactions
Both systems
follow the
repository
style
Accounts
database
Batch input
CS 501 Spring 2008
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
17
CS 501 Spring 2008
Merger of Two Banks:
Interface between the Databases
Bank A
Bank B
Teller transactions
Teller transactions
Accounts
database
Batch input
18
Data
transform
Data
exchange
API
Data
transform
Problem Accounts
databases are rarely
exactly equivalent.
Accounts
database
Batch input
CS 501 Spring 2008
Data Intensive Systems:
Distributed Data
Distributed Data
Data is held on several computer systems. A transaction may
need to assemble data from several sources.
19
CS 501 Spring 2008
Architectures for Distributed
Computing
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
20
CS 501 Spring 2008
Architectural Style: Client/Server
Web example: Serving static pages
Firefox
client
Apache
server
The control flows in the client and the server are independent.
communication between client and server follows a protocol.
In a peer-to-peer architecture, the same component acts as
both a client and a server.
21
CS 501 Spring 2008
Architectural Style:
Three Tier Architecture
Presentation
tier
Application
tier
Database
tier
Web example: Serving dynamic pages
Each of the tiers can be replaced by other components
that implement the same interfaces
22
CS 501 Spring 2008
Distributed Computing:
Multicast
Three tier architecture: Broadcast searching
User
User interface
service
Databases
This is an example of a multicast protocol.
The primary difficulty is to avoid troubles at
one site degrading the entire system (e.g.,
every transaction cannot wait for a system to
time out).
23
CS 501 Spring 2008
Networks:
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
24
CS 501 Spring 2008
Networks: Choices
Public Internet:
Ubiquitous -- worldwide
Low cost
Private network:
Security / reliability
Predictable performance
Choice of protocols (not constrained to TCP/IP)
25
CS 501 Spring 2008
Networks:
Routers and Other Network Computing
•
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
•
26
CS 501 Spring 2008
Networks: 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
27
Firewalls provide security at a loss of flexibility and a cost of
system administration.
CS 501 Spring 2008
Distributed Data:
Replication
Replication
Several copies of the data are held in different locations.
Mirror: Complete data set is replicated
Cache: Dynamic set of data is replicated (e.g., most recently used)
With replicated data, the biggest problems are concurrency and
consistency.
28
CS 501 Spring 2008
Distributed Computing:
Distributed Caches
The Domain Name System
First attempt to resolve
www.cs.cornell.edu
.edu
server
1
2
3
29
cornell.edu
server
cs.cornell.edu
server
CS 501 Spring 2008
Distributed Computing:
Distributed Caches
The Domain Name System
Better method
local DNS
server
1
almaden.ibm.com
cornell.edu
Local ece.cmu.edu
cache ibm.com
acm.org
.edu
30
.edu
server
2
cornell.edu
server
3
cs.cornell.edu
server
CS 501 Spring 2008
Distributed Computing:
Distributed Caches
The Domain Name System
For details of the actual protocol read:
Paul Mockapetris, "Domain Names - Implementation and
Specification". IETF Network Working Group, Request for
Comments: 1035, November 1987.
http://www.ietf.org/rfc/rfc1035.txt?number=1035
31
CS 501 Spring 2008
Distributed Computing:
Intermittent Connectivity
This is an example of an epidemic
protocol. Such protocols are
especially useful in networks with
intermittent connectivity, e.g.,
mobile computing.
The biggest problem is ensuring that
the data is distributed effectively.
32
Example: Usenet
CS 501 Spring 2008
Time-Critical Systems
A real time (time-critical) 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
• A hard real time system fails if the results are
not produced within required time constraints
33
CS 501 Spring 2008
Time-Critical System: Buffering a CD
Controller for Automobile
4
Input
block
7
3
2
5
6
Circular buffer
34
1
Output
block
CS 501 Spring 2008
Time Critical System:
Architectural Style - Daemon
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
35
CS 501 Spring 2008
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.
36
CS 501 Spring 2008
Time-Critical System:
Autonomous Land Vehicle
GPS
Steer
Sonar
Model
Laser
Control
signals
Throttle
Controls
Sensors
37
Signal
processing
CS 501 Spring 2008
Time Critical System:
Autonomous Land Vehicle
Extend model/controller/view
Sensors
Model
View
Controller
38
CS 501 Spring 2008
Software Considerations
In some types of system architecture, non-functional
requirements of the system may dictate the software
design and development process.
39
CS 501 Spring 2008
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.
40
CS 501 Spring 2008
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
41
CS 501 Spring 2008
Software Considerations:
Multi-Threading
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.
•
42
Division into components, each with its own
acceptance test.
CS 501 Spring 2008
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.
43
CS 501 Spring 2008
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.
44
CS 501 Spring 2008
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.
45
CS 501 Spring 2008
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.
*
46
CS 501 Spring 2008