Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 14 System Architecture II."— Presentation transcript:

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

2 2 CS 501 Spring 2002 Administration

3 3 CS 501 Spring 2002 Quiz 2, Question 2 A microwave oven has the following buttons: clearClear all settings high-powerSet high-power cooking (default) low-powerSet low-power cooking runRun until time expires pausePause without changing settings open doorPause and open door and a rotary dial: set-clockSet the clock (default is zero)

4 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 5 CS 501 Spring 2002 InitialReadyRunDoor 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 6 CS 501 Spring 2002 InitialReadyRunDoor 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 7 CS 501 Spring 2002 InitialReadyRunDoor 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 8 CS 501 Spring 2002 InitialReadyRunDoor open clear [ok_to_run] run [time_up] open_door pause close_door set_clock high/low clear Quiz 2, Question 2 Settings Note. These settings do not change state, but may trigger ok_to_run

9 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 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

10 10 CS 501 Spring 2002 Network Choices Public Internet: Ubiquitous -- worldwide Low cost Private network: Security / reliability Predictable performance Choice of protocols (not constrained to TCP/IP)

11 11 CS 501 Spring 2002 Quality of Network Services Criteria Performance Maximum throughput Variations in throughput Real-time media (e.g., audio) Business Suppliers Trouble shooting and maintenance

12 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 connection an unknown packet type Firewalls provide security at a loss of flexibility and a cost of system administration.

13 13 CS 501 Spring 2002 Distributed Computing Example 1: Distributed Database two copies of the same data

14 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 15 CS 501 Spring 2002 Distributed Computing Example 2: Broadcast Search 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).

16 16 CS 501 Spring 2002 Distributed Computing Example 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 17 CS 501 Spring 2002 Stateless 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

18 18 CS 501 Spring 2002 Stateless Protocol v. Stateful Stateful (session) protocol Example: Z39.50 Open connection Begin session Interactive session End session Close connection Server remembers the results of previous transactions (e.g., authentication, partial results) until session is closed.

19 19 CS 501 Spring 2002 Distributed Computing Example 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 20 CS 501 Spring 2002 Distributed Computing Example 4: The Domain Name System.edu server cornell.edu server cs.cornell.edu server Better method 3 1 almaden.ibm.com cornell.edu ece.cmu.edu ibm.com acm.org.edu 2 Local cache local DNS server

21 21 CS 501 Spring 2002 Distributed Computing Example 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 22 CS 501 Spring 2002 Distributed Computing Example 5: Web Server http message daemon spawned processes TCP port 80 The daemon listens at port 80 When a message arrives it: spawns a processes to handle the message returns to listening at port 80

23 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 24 CS 501 Spring 2002 Time-Critical System Example 1: Autonomous Land Vehicle Sensors GPS Sonar Laser Signal processing ModelControl signals Steer Throttle Controls

25 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 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 27 CS 501 Spring 2002 Time-Critical System Example 3: CD Controller Input block Output block 1 2 3 4 5 6 7 Circular buffer

28 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 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 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 31 CS 501 Spring 2002 Time-Critical System Example 4: Dartmouth Time Shared System Communications processor Central processor Central processor Central processor I/O Mulitplexor master processor

32 32 CS 501 Spring 2002 Techniques Special purpose hardware Multi-threading and multi-tasking Parallel processing => digital signal processing Interrupts => levels and priorities

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


Download ppt "1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 14 System Architecture II."

Similar presentations


Ads by Google