CS 501: Software Engineering

1
CS 501 Software Engineering
Lecture 19 Reliability 1
2
Administration
3
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
Quiz 3 System Design

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

RadarController
Plot
Display
GPSController
5
Architectural StyleModel/Controller/View
Lecture 15 Slide 10
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.
6
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.
• When components run on the same computer, they
  can pass message using methods of a programming
  language.
• When they run on different computers, a protocol
  is needed.

7
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
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
Adapter Design Pattern Class Diagram
Based on Lecture 15 Slide 10
OtherShip
10
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
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
Quiz 3 Question 2
(ii) Select the classes. For each class, list
at least one attribute and one operation. ShipA ve
locity getGPSdata() OtherShip bearing getRadardat
a() Track closestpoint alarm() (iii) Draw a
possible class diagram.
OtherShip bearing getRadardata()
ShipA velocity getGPSdata()
Track closestpoint alarm()
1
1
0..
1
13
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
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. Georges, 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 Majestys GPS was
configured by Majesty Cruise Line to
automatically default to the Dead Reckoning mode
when satellite data were not available."
15
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
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
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
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
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
Building Dependable Systems
The human mind can encompass only limited
complexity Comprehensibility
Simplicity Partitioning of complexity
21
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 Report
ing procedures
22
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
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
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
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
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
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
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.