1. 1 CS 501 Spring 2004 CS 501: Software Engineering Lecture 19 Reliability 1

2. 2 CS 501 Spring 2004 Administration

3. 3 CS 501 Spring 2004 Quiz 3: The Collision Avoidance System Ship A has two instruments, which provide digital information for navigation: (1) A global positioning system (GPS) measures the position and velocity of Ship A. (2) A radar set measures the distance and bearing of other ships from Ship A. The Collision Avoidance System continually receives data from these two instruments. From the data, a plotting subsystem calculates the track of each other ship relative to Ship A. This is displayed on a screen. If the other ship appears to be on a collision course, the system alerts the crew of the ship.

4. 4 CS 501 Spring 2004 Quiz 3: System Design (a)Using an appropriate architectural style, divide the Collision Avoidance System into a small number of subsystems... The Model/Controller/View architectural style applies (Lecture 15, Slide 10), with two instruments to control. (b)Draw an component diagram showing the system architecture of the Collision Avoidance System. PlotDisplay RadarController GPSController

5. 5 CS 501 Spring 2004 Architectural Style: Model/Controller/View Model Controller 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. Lecture 15 Slide 10

6. 6 CS 501 Spring 2004 Quiz 3: System Design (a)...Give a brief description of the interfaces between these subsystems. The answer to this part depends on whether you assume that the components all run on a single computer. (a)When components run on the same computer, they can pass message using methods of a programming language. (b)When they run on different computers, a protocol is needed.

7. 7 CS 501 Spring 2004 Interfaces: An Example The National Marine Electronics Association provides the NMEA 0183 Standard for interconnecting marine electronics. The standard defines electrical signal requirements, data transmission protocol and time, and specific sentence formats for a 4800-baud serial data bus. Each bus may have only one talker but many listeners. The data is transmitted in the form of "sentences". Each sentence starts with a "$", a two letter "talker ID", a three letter "sentence ID", followed by a number of data fields separated by commas, and terminated by an optional checksum, and a carriage return/line feed. A sentence may contain up to 82 characters including the "$" and CR/LF.

8. 8 CS 501 Spring 2004 Quiz 3: Question 2 (a) During the lifetime of the Collision Avoidance System it is expected that the radar will be replaced by a different instrument. Probably, this will provide navigation data in a new format through a different interface. (i) How would you incorporate this requirement into the program design? The Adapter Design Pattern applies (Lecture 17, slides 37-39). (ii) Draw the appropriate UML class diagram. See Lecture 17, slide 38.

9. 9 CS 501 Spring 2004 Adapter Design Pattern: Class Diagram RadarInterface RequestRadarData() Adapter RequestRadarData() ExistingRadarControl ExistingRequestRadarData() OtherShip Based on Lecture 15 Slide 10

10. 10 CS 501 Spring 2004 Quiz 3: Question 2 (b)Create a UML class diagram for the plotting subsystem as follows. (i) Use noun identification to list the candidate classes. From the data, a plotting subsystem calculates the track of each other ship relative to Ship A. This is displayed on a screen. If the other ship appears to be on a collision course, the system alerts the crew of the ship.

11. 11 CS 501 Spring 2004 Quiz 3: Question 2 Candidate classes: DataInput to plotting subsystem PlottingSubsystemThe entire subsystem Track OtherShip ShipA ScreenOutput device CollisionCourseA special case of Track SystemSame as PlottingSubsystem CrewUser of output -- actor

12. 12 CS 501 Spring 2004 Quiz 3: Question 2 (ii) Select the classes. For each class, list at least one attribute and one operation. ShipAvelocitygetGPSdata() OtherShipbearinggetRadardata() Trackclosestpointalarm() (iii) Draw a possible class diagram. ShipA velocity getGPSdata() OtherShip bearing getRadardata() Track closestpoint alarm() 1 1 1 0..*

13. 13 CS 501 Spring 2004 Quiz 3: Question 1 (c) Instruments sometimes fail or give erroneous data. Where in the system architecture are these errors identified and handled? The RadarController and GPSController subsystems should check for errors in the data streams that are received from the instruments, e.g., missing or malformed data. The Plot subsystem should check the data for consistency with previous data and the model of the ships' tracks. Errors should be reported by the Plot subsystem to the Display subsystem.

14. 14 CS 501 Spring 2004 Dependable and Reliable Systems: The Royal Majesty From the report of the National Transportation Safety Board: "On June 10, 1995, the Panamanian passenger ship Royal Majesty grounded on Rose and Crown Shoal about 10 miles east of Nantucket Island, Massachusetts, and about 17 miles from where the watch officers thought the vessel was. The vessel, with 1,509 persons on board, was en route from St. George’s, Bermuda, to Boston, Massachusetts." "The Raytheon GPS unit installed on the Royal Majesty had been designed as a standalone navigation device in the mid- to late 1980s,...The Royal Majesty’s GPS was configured by Majesty Cruise Line to automatically default to the Dead Reckoning mode when satellite data were not available."

15. 15 CS 501 Spring 2004 The Royal Majesty: Analysis The ship was steered by an autopilot that relied on position information from the Global Positioning System (GPS). If the GPS could not obtain a position from satellites, it provided an estimated position based on Dead Reckoning (distance and direction traveled from a known point). The GPS failed one hour after leaving Bermuda. The crew failed to see the warning message on the display (or to check the instruments). 34 hours and 600 miles later, the Dead Reckoning error was 17 miles.

16. 16 CS 501 Spring 2004 The Royal Majesty: Software Lessons All the software worked as specified (no bugs), but... Since the GPS software had been specified, the requirements had changed (standalone system to part of integrated system). The manufacturers of the autopilot and GPS adopted different design philosophies about the communication of mode changes. The autopilot was not programmed to recognize valid/invalid status bits in message from the GPS (NMEA 0183). The warnings provided by the user interface were not sufficiently conspicuous to alert the crew. The officers had not been properly trained on this equipment.

17. 17 CS 501 Spring 2004 Lectures on Reliability and Dependability Lecture 19, Reliability 1: The development process Reviews Lecture 20, Reliability 2: Different aspects of reliability Programming techniques Lecture 21, Reliability 3:Testing and bug fixing Tools

18. 18 CS 501 Spring 2004 Three Principles for Dependable Systems For a software system to be dependable: Each stage of development must be done well. Changes should be incorporated into the structure as carefully as the original system development. Testing and correction do not ensure quality, but dependable systems are not possible without systematic testing.

19. 19 CS 501 Spring 2004 Key Factors for Reliable Software Organization culture that expects quality Approach to software design and implementation that hides complexity (e.g., structured design, object-oriented programming) Precise, unambiguous specification Use of software tools that restrict or detect errors (e.g., strongly typed languages, source control systems, debuggers) Programming style that emphasizes simplicity, readability, and avoidance of dangerous constructs Incremental validation

20. 20 CS 501 Spring 2004 Building Dependable Systems The human mind can encompass only limited complexity: Comprehensibility Simplicity Partitioning of complexity

21. 21 CS 501 Spring 2004 Quality Management Processes Assumption: Good processes lead to good software The importance of routine: Standard terminology (requirements, specification, design, etc.) Software standards (naming conventions, etc.) Internal and external documentation Reporting procedures

22. 22 CS 501 Spring 2004 Quality Management Processes: Change Change management: Source code management and version control Tracking of change requests and bug reports Procedures for changing requirements specifications, designs and other documentation Release control

23. 23 CS 501 Spring 2004 Reviews of Process (Plan) Objectives: To review progress against plan (formal or informal). To adjust plan (schedule, team assignments, functionality, etc.). Impact on quality: Good quality systems usually result from plans that are demanding but realistic. Good people like to be stretched and to work hard, but must not be pressed beyond their capabilities.

24. 24 CS 501 Spring 2004 Design and Code Reviews DESIGN AND CODE REVIEWS ARE A FUNDAMENTAL PART OF GOOD SOFTWARE DEVELOPMENT Concept Colleagues review each other's work: can be applied to any stage of software development can be formal or informal

25. 25 CS 501 Spring 2004 Benefits of Design and Code Reviews Benefits: Extra eyes spot mistakes, suggest improvements Colleagues share expertise; helps with training An occasion to tidy loose ends Incompatibilities between components can be identified Helps scheduling and management control Fundamental requirements: Senior team members must show leadership Good reviews require good preparation Everybody must be helpful, not threatening

26. 26 CS 501 Spring 2004 Review Team (Full Version) A review is a structured meeting, with the following people Moderator -- ensures that the meeting moves ahead steadily Scribe -- records discussion in a constructive manner Developer -- person(s) whose work is being reviewed Interested parties -- people above and below in the software process Outside experts -- knowledgeable people who have are not working on this project Client -- representatives of the client who are knowledgeable about this part of the process

27. 27 CS 501 Spring 2004 Example: Program Design Moderator Scribe Developer -- the design team Interested parties -- people who created the system design and/or requirements specification, and the programmers who will implement the system Outside experts -- knowledgeable people who have are not working on this project Client -- only if the client has a strong technical representative

28. 28 CS 501 Spring 2004 Review Process Preparation The developer provides colleagues with documentation (e.g., specification or design), or code listing Participants study the documentation in advance Meeting The developer leads the reviewers through the documentation, describing what each section does and encouraging questions Must allow plenty of time and be prepared to continue on another day.