1 CS 501 Spring 2004

CS 501: Software Engineering

Lecture 19

Reliability 1

2 CS 501 Spring 2004

Administration

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

Plot Display

RadarController

GPSController

5 CS 501 Spring 2004

Architectural Style:Model/Controller/View

ModelController 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 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 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 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 CS 501 Spring 2004

Adapter Design Pattern: Class Diagram

RadarInterface

RequestRadarData()

Adapter

RequestRadarData()

ExistingRadarControl

ExistingRequestRadarData()

OtherShip

Based on Lecture 15 Slide 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 CS 501 Spring 2004

Quiz 3: Question 2

Candidate classes:

Data Input to plotting subsystem

PlottingSubsystem The entire subsystem

Track

OtherShip

ShipA

Screen Output device

CollisionCourse A special case of Track

System Same as PlottingSubsystem

Crew User of output -- actor

12 CS 501 Spring 2004

Quiz 3: Question 2

(ii) Select the classes. For each class, list at least one attribute and one operation.

ShipA velocity getGPSdata()OtherShip bearing getRadardata()Track closestpoint alarm()

(iii) Draw a possible class diagram.

ShipA

velocity

getGPSdata()

OtherShip

bearing

getRadardata()Track

closestpoint

alarm()

1110..*

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 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 late1980s, ...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 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 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 CS 501 Spring 2004

Lectures on Reliability and Dependability

Lecture 19, Reliability 1: The development processReviews

Lecture 20, Reliability 2: Different aspects of reliabilityProgramming techniques

Lecture 21, Reliability 3: Testing and bug fixingTools

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 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 CS 501 Spring 2004

Building Dependable Systems

The human mind can encompass only limited complexity:

• Comprehensibility

• Simplicity

• Partitioning of complexity

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