1 CS 501 Spring 2008 CS 501: Software Engineering Lecture 20 Reliability 2.
1 CS 501 Spring 2008 CS 501: Software Engineering Lecture 14 System Architecture and Design 2.
-
date post
21-Dec-2015 -
Category
Documents
-
view
216 -
download
0
Transcript of 1 CS 501 Spring 2008 CS 501: Software Engineering Lecture 14 System Architecture and Design 2.
1 CS 501 Spring 2008
CS 501: Software Engineering
Lecture 14
System Architecture and Design 2
2 CS 501 Spring 2008
Administration
3 CS 501 Spring 2008
Data Intensive SystemsExample: A Small-town Stockbroker
• Transactions
Received by mail or over telephone
For immediate or later action
• Complex customer inquiries
• Highly competitive market
4 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)
5 CS 501 Spring 2008
Real-time Transactions
Customer & account database
Products & services database
External services
Real-time transactions
6 CS 501 Spring 2008
Real-time Transactions & Batch Processing
Customer & account database
Products & services database
External services
Real-time transactions
Batch processing
Data input
7 CS 501 Spring 2008
Stock Broker: Interface Diagram
CustomerDBProductDB
OnLineTR BatchTR
External
8 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 commitreload from checkpoint + logdetailed 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.
*
9 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
10 CS 501 Spring 2008
Architectural Style: Pipe
Example: A three-pass compiler
ParserLexical analysis
Code generation
Output from one subsystem is the input to the next.
11 CS 501 Spring 2008
Architectural Style: Master File Update
Master file update
Data input and validation
Mailing and reports
Example: billing system for electric utility
Advantages: Efficient way to process batches of transactions.
Disadvantages: Information in master file is not updated immediately.
Customer services
12 CS 501 Spring 2008
Architectural Style: Repository
Repository
Input components
Transactions
Example: A digital library
Advantages: Flexible architecture for data-intensive systems.
Disadvantages: Difficult to modify repository since all other components are coupled to it.
13 CS 501 Spring 2008
Architectural Style: Repository with Storage Access Layer
Data Store
Input components
Transactions
Advantages: Data Store subsystem can be changed without modifying any component except the Storage Access.
Storage Access
This is sometimes called a "glue" layer
Repository
14 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.
15 CS 501 Spring 2008
Merger of Two Banks: Options
???
???
AA BB
16 CS 501 Spring 2008
Merger of Two Banks: Interface between the Databases
Accounts database
Batch input
Teller transactions
Accounts database
Batch input
Teller transactions
Bank A Bank B
Both systems follow the repository style
17 CS 501 Spring 2008
Merger of Two Banks: Architectural Options
I. Convert everything to System A
convert databasesretrain staffenhance 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
18 CS 501 Spring 2008
Merger of Two Banks: Interface between the Databases
Accounts database
Batch input
Teller transactions
Accounts database
Batch input
Teller transactions
Bank A Bank B
Data exchange
API
Problem Accounts databases are rarely exactly equivalent.
Data trans-form
Data trans-form
19 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.
20 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 connectionprivate, public, or virtual private networklocation of firewalls
• Protocolspoint-to-point, multicast, broadcastmessage passing, RPC, distributed objectsstateful or stateless
• Performance
quality of service
21 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.
22 CS 501 Spring 2008
Architectural Style: Three Tier Architecture
Web example: Serving dynamic pages
Each of the tiers can be replaced by other components that implement the same interfaces
Presentation tier
Application tier
Database tier
23 CS 501 Spring 2008
Distributed Computing: Multicast
User interfaceservice
User
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).
Three tier architecture: Broadcast searching
24 CS 501 Spring 2008
Networks:Quality of Network Services
Criteria in choosing a network architecture
Performance
Maximum throughputLatencyVariations in throughputReal-time media (e.g., audio)
Business
Suppliers, costTrouble shooting and maintenance
25 CS 501 Spring 2008
Networks: Choices
Public Internet:
Ubiquitous -- worldwideLow cost
Private network:
Security / reliabilityPredictable performanceChoice of protocols (not constrained to TCP/IP)
26 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
27 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 connectionan unknown packet type
Firewalls provide security at a loss of flexibility and a cost of system administration.
28 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.
29 CS 501 Spring 2008
Distributed Computing: Distributed Caches
.edu server
cornell.edu server
cs.cornell.edu server
First attempt to resolve www.cs.cornell.edu
1
2
3
The Domain Name System
30 CS 501 Spring 2008
Distributed Computing:Distributed Caches
.edu server
cornell.edu server
cs.cornell.edu server
Better method
3
1
almaden.ibm.comcornell.eduece.cmu.eduibm.comacm.org.edu
2
Localcache
local DNS server
The Domain Name System
31 CS 501 Spring 2008
Distributed Computing:Distributed Caches
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
The Domain Name System
32 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.
Example: Usenet
33 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
34 CS 501 Spring 2008
Time-Critical System: Buffering a CD Controller for Automobile
Input block Output
block
12
345
67
Circular buffer
35 CS 501 Spring 2008
Time Critical System: Architectural Style - Daemon
Daemon
Example: Web server
The daemon listens at port 80
When a message arrives it:spawns a processes to handle the messagereturns to listening at port 80
Spawned process
36 CS 501 Spring 2008
Time Critical System: Architectural Style - Model/Controller/View
ModelController View
Example: An unmanned aircraft
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.
37 CS 501 Spring 2008
Time-Critical System: Autonomous Land Vehicle
Sensors
GPS
Sonar
Laser
Signal processing
Model Control signals
Steer
Throttle
Controls
38 CS 501 Spring 2008
Time Critical System:Autonomous Land Vehicle
Model
Sensors
View
Extend model/controller/view
Controller
39 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.
40 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.
41 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
42 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.
• Division into components, each with its own acceptance test.
43 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.
44 CS 501 Spring 2008
Software Considerations:Embedded Real-time Systems
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.
Hardware v. Software
45 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.
46 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.
*