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. <<includes>>
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.)
<<includes>>
PlaceOrder
Pay
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
Input components
Storage Access
Transactions
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 Style: Model/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
Performance
Maximum throughput
Latency
Variations in throughput
Real-time media (e.g., audio)
Business
Suppliers, cost
Trouble shooting and maintenance

16. Firewall Private network Public 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.

17. two copies of the same data
Distributed Data
two copies of the same data

18. Distributed Data and Replication
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 Computing: Stateless Protocol v. Stateful
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
Interactive 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
.edu server 1
cornell.edu server 2 3
cs.cornell.edu server

24. Distributed Computing: The Domain Name System
Better method
local DNS server
.edu server 1 2
cornell.edu server
almaden.ibm.com
cornell.edu
ece.cmu.edu
ibm.com
acm.org
.edu 3
Local
cache
cs.cornell.edu server

25. Distributed Computing 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.

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 System: CD Controller4 3 1
Input block 5 2
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
=> erroneous or malicious messages
=> 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 System: 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.

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

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.