1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 14 System Architecture II

1 CS 501 Spring 2002

CS 501: Software Engineering

Lecture 14

System Architecture II

2 CS 501 Spring 2002

Administration

3 CS 501 Spring 2002

Quiz 2, Question 2

A microwave oven has the following buttons:

clear Clear all settingshigh-power Set high-power cooking (default)low-power Set low-power cookingrun Run until time expirespause Pause without changing settingsopen door Pause and open door

and a rotary dial:

set-clock Set the clock (default is zero)

4 CS 501 Spring 2002

Quiz 2, Question 2

• Initially and after clear the microwave is set for high-power cooking and the clock is set to zero.

• The microwave is ready to run when the clock is set to a value greater than zero and the door is closed.

• The user can then hit the run button to begin cooking until time expires.

• While cooking, opening the door or hitting the pause button suspends operation without changing any settings; the user can then hit clear, change settings, or hit run to continue.

• Settings can be changed while the door is open; it is not possible to run with the door open.

5 CS 501 Spring 2002

Initial Ready Run

Door open

Quiz 2, Question 2

Hint. It is possible to model this system with only 4 states, but there are correct answers with more states.

States

6 CS 501 Spring 2002

Initial Ready Run

Door open

[ok_to_run] run

[time_up]

open_door

close_door

Quiz 2, Question 2

Major transitions

Note use of automatic transitions. ok_to_run is triggered when all settings complete.

7 CS 501 Spring 2002

Initial Ready Run

Door open

clear

[ok_to_run] run

[time_up]

open_door

pause

close_door clear

Quiz 2, Question 2

Pause and clear transitions

Note. The question does not fully specify these transitions.

8 CS 501 Spring 2002

Initial Ready Run

Door open

clear

[ok_to_run] run

[time_up]

open_door

pause

close_door

set_clock

set_clock

set_clock

high/low

high/low

high/low

clear

Quiz 2, Question 2

Settings

Note. These settings do not change state, but may trigger ok_to_run

9 CS 501 Spring 2002

Distributed Computing: General Problem

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

10 CS 501 Spring 2002

Network Choices

Public Internet:

Ubiquitous -- worldwideLow cost

Private network:

Security / reliabilityPredictable performanceChoice of protocols (not constrained to TCP/IP)

11 CS 501 Spring 2002

Quality of Network Services

Criteria

Performance

Maximum throughputVariations in throughputReal-time media (e.g., audio)

Business

SuppliersTrouble shooting and maintenance

12 CS 501 Spring 2002

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.

13 CS 501 Spring 2002

Distributed ComputingExample 1: Distributed Database

two copies of the same data

14 CS 501 Spring 2002

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.

15 CS 501 Spring 2002

Distributed ComputingExample 2: Broadcast Search

User interfaceserverUser

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

16 CS 501 Spring 2002

Distributed ComputingExample 3: 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.

17 CS 501 Spring 2002

Stateless Protocol v. Stateful

Stateless protocol

Example: http

Open connectionSend message Return replyClose connection

State in http must be sent with every message (e.g., as parameter string)

Cookies are a primitive way of retaining some state

18 CS 501 Spring 2002

Stateless Protocol v. Stateful

Stateful (session) protocol

Example: Z39.50

Open connectionBegin sessionInteractive sessionEnd sessionClose connection

Server remembers the results of previous transactions (e.g., authentication, partial results) until session is closed.

19 CS 501 Spring 2002

Distributed ComputingExample 4: The Domain Name System

.edu server

cornell.edu server

cs.cornell.edu server

First attempt to resolve www.cs.cornell.edu

1

2

3

20 CS 501 Spring 2002

Distributed ComputingExample 4: The Domain Name System

.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

21 CS 501 Spring 2002

Distributed ComputingExample 4: 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

22 CS 501 Spring 2002

Distributed ComputingExample 5: Web Server

http messagedaemon

spawned processesTCP port 80

The daemon listens at port 80

When a message arrives it:spawns a processes to handle the messagereturns to listening at port 80

23 CS 501 Spring 2002

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

24 CS 501 Spring 2002

Time-Critical System Example 1: Autonomous Land Vehicle

Sensors

GPS

Sonar

Laser

Signal processing

Model Control signals

Steer

Throttle

Controls

25 CS 501 Spring 2002

Time-Critical System Example 2: 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

26 CS 501 Spring 2002

Techniques: 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.

27 CS 501 Spring 2002

Time-Critical System Example 3:CD Controller

Input block Output

block

12

345

67

Circular buffer

28 CS 501 Spring 2002

Time-Critical System Example 4: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.

29 CS 501 Spring 2002

Time-Critical System Example 4: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

30 CS 501 Spring 2002

Time-Critical System Example 5:Shared Systems

Many users are using the same equipment at the same time

• Multi-user data processing (common task)

• Time sharing (independent tasks)

31 CS 501 Spring 2002

Time-Critical System Example 4: Dartmouth Time Shared System

Communications processor

Communications processor

Centralprocessor

Centralprocessor

Centralprocessor

I/OMulitplexor

master processor

32 CS 501 Spring 2002

Techniques

• Special purpose hardware

• Multi-threading and multi-tasking

• Parallel processing

=> digital signal processing

• Interrupts

=> levels and priorities

33 CS 501 Spring 2002

Techniques: Multi-Threading

Several similar threads operating concurrently:

• Re-entrant code -- separation of pure code from data for each thread

• Testing -- single thread and multi thread

May be real-time (e.g., telephone switch) or non-time critical

34 CS 501 Spring 2002

Techniques: Real Time Executive

Schedules and dispatches tasks in a real time system

• Real time clock

• Interrupt handler

• Scheduler

• Resource manager

• Dispatcher

Must be extremely reliable

35 CS 501 Spring 2002

Techniques: Timing

Timing mechanisms

• Synchronous (clocked) -- periodic stimuli

• Asynchronous -- wait for next signal

Example: Communications protocols may be synchronous or asynchronous

36 CS 501 Spring 2002

Techniques: Software Considerations

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

37 CS 501 Spring 2002

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.