CS 501: Software Engineering

1
CS 501 Software Engineering
Lecture 15 System Architecture and Design 2
2
Administration
3
Quiz 2, Question 1
You are developing the requirements for an online
shopping system. To place an order, a user
connects to the system, searches to find items to
purchase, selects one or more items, and supplies
credit card information to pay for
them. (i) Create a scenario for a user making a
purchase.
A scenario should follow an individual user
through a single interaction with the system. See
Lecture 8, slides 11 to 14 for a typical example.
4
Quiz 2, Question 1
(ii) Develop a use case diagram and brief
specification for a use case, PlaceOrder, which
is modeled on this scenario. The use case should
show a relationship to a previously specified use
case, Pay, which models credit card payments.
(You do not need to specify the Pay use case.)
ltltincludesgtgt
Pay
PlaceOrder
Shopper
The subject of a use case is an actor, with a
generic role. For an example of a specification,
see Lecture 8 slides 26-27
5
Quiz 2, Question 1
(iii) A user might interact with the online
shopping system in other ways. Draw a diagram
for a different use case in which the same actor
interacts with the online shopping system.
CheckOrder
Shopper
Note same actor for this different use case.
6
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.
7
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
8
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.
9
Architectural Style Repository with Storage
Access Layer
Repository
Input components
Transactions
Storage Access
This is sometimes called a "glue" layer
Data Store
Advantages Data Store subsystem can be changed
without modifying any component except the
Storage Access.
10
Architectural StyleModel/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.
11
Architectural Style Client/Server
Example the Web
Apache server
Mozilla client
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.
12
Architectural Style Pipe
Example A three-pass compiler
Lexical analysis
Code generation
Parser
Output from one subsystem is the input to the
next.
13
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
Performance quality of service
14
Network Choices
Public Internet Ubiquitous -- worldwide Low
cost Private network Security /
reliability Predictable performance Choice of
protocols (not constrained to TCP/IP)
15
Quality of Network Services
Criteria in choosing a system architecture Perform
ance Maximum throughput Latency Variations in
throughput Real-time media (e.g.,
audio) Business Suppliers, cost Trouble
shooting and maintenance
16
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.
17
Distributed Data
two copies of the same data
18
Distributed Data and Replication
Distributed Data Data is held on several computer
systems. A transaction may need to assemble data
from several sources. 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.
19
Distributed Computing Searching
Broadcast Searching
User interface server
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).
20
Distributed ComputingStateless Protocol v.
Stateful
Stateless protocol Example http Open
connection Send message Return reply Close
connection State in http must be sent with every
message (e.g., as parameter string) Cookies are
a primitive way of retaining some state
21
Stateless Protocol v. Stateful
Stateful (session) protocol Example
Z39.50 Open connection Begin session Interactiv
e session End session Close connection Client
and server remember the results of previous
transactions (e.g., authentication, partial
results) until session is closed.
22
Distributed Computing UseNet
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.
23
Distributed Computing The Domain Name System
First attempt to resolve www.cs.cornell.edu
.edu server
1
cornell.edu server
2
3
cs.cornell.edu server
24
Distributed ComputingThe Domain Name System
Better method
.edu server
local DNS server
1
2
cornell.edu server
almaden.ibm.com cornell.edu ece.cmu.edu ibm.com ac
m.org .edu
3
Local cache
cs.cornell.edu server
25
Distributed ComputingDomain 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?number1035
26
Distributed Computing Web Server
http message
daemon
TCP port 80
spawned processes
The daemon listens at port 80 When a message
arrives it spawns a processes to handle the
message returns to listening at port 80
27
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
28
Time-Critical System Autonomous Land Vehicle
GPS
Steer
Sonar
Model
Control signals
Throttle
Laser
Controls
Sensors
Signal processing
29
Time-Critical SystemCD Controller
3
4
1
2
Input block
5
Output block
6
7
Circular buffer
30
Software Considerations of System Architectures
In some types of system architecture,
non-functional requirements of the system may
dictate the software design and development
process.
31
Time-Critical System Routers and Other Network
Computing
Interoperation with third party devices
Support for several versions of protocols
Restart after total failure Defensive
programming -- must survive gt erroneous or
malicious messages gt extreme loads Time
outs, dropped packets, etc. Evolution of
network systems
32
Time-Critical System Software Development

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

33
Software Considerations of System Architectures
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
34
Software Considerations of System Architectures
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.
35
Time-Critical SystemEmbedded 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.
36
Software ConsiderationsEmbedded 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.
37
Software Considerations of System Architectures
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.