CS 501: Software Engineering
Lecture 20
Reliability 2
1
CS 501 Spring 2005
Administration
Projects
Four weeks to the end of the semester.
Leave time for system testing and to make small changes
discovered when the complete system is assembled.
2
CS 501 Spring 2005
Quiz 3
3
Two online retailers, A and B, have agreed to merge. They have
separate computer systems. Each has separately developed (i) a
product database with information about products, suppliers and
prices, (ii) a customer database of customer accounts, and (iii) an
ordering system for online customers.
You are a member of the team that will combine the two systems into
a single system. The strategy chosen is to combine the two product
databases into a single database, based on the software developed by
retailer A, but to keep the customer databases separate.
During Phase 1, the two ordering systems will be kept separate with
minimal changes. In Phase 2, the two ordering systems will be
replaced by a new ordering system that combines features from the
systems provided by both A and B.
CS 501 Spring 2005
Quiz 3 Question 1
i
Draw a UML interface diagram for the system architecture for
Phase 1.
ii Discuss each component in your system architecture. Is it: (a) an
existing component from retailer A or B, or (b) an existing
component with modifications, or (c) a new component? For
existing components, what modifications will be needed?
iii List the principal risks in developing Phase 1.
4
CS 501 Spring 2005
Quiz 3 Question 1
OrderA
CustomerDbA
5
DBInt
ProductDb
OrderB
CustomerDbB
CS 501 Spring 2005
Quiz 3 Question 2
Changes may be needed to the product data base and the ordering
systems for Phase 1. Careful design during Phase 1 will help the
subsequent development of a new ordering system in Phase 2
i
Select a design pattern that applies to this problem. Why is this
design pattern appropriate?
ii Draw a UML class diagram for Phase 1.
iii If your class diagram uses any of the following, explain their
functions:
(a) abstract classes
(b) inheritance
(c) delegation
6
CS 501 Spring 2005
Quiz 3 Question 2
OrderA
OrderBInterface
OrderB
prodRequestB()
Adapter
prodRequestB()
CustDbA
ProdDbA
CustDbB
prodRequestA()
7
CS 501 Spring 2005
Quiz 3 Question 2: Retailer A
OrderA
OrderBInterface
OrderB
prodRequestB()
Adapter
prodRequestB()
CustDbA
ProdDbA
CustDbB
prodRequestA()
8
CS 501 Spring 2005
Adapter Design Pattern:
Class Diagram
Client
abstract class
ClientInterface
LegacyClass
request()
existingRequest()
Adapter
inheritance
9
delegation
request()
CS 501 Spring 2005
Quiz 3 Question 2:
Adapter Design Pattern
OrderA
OrderBInterface
OrderB
prodRequestB()
Adapter
prodRequestB()
delegation
CustDbA
ProdDbA
CustDbB
prodRequestA()
10
CS 501 Spring 2005
Static and Dynamic Verification
Static verification: Techniques of verification that
do not include execution of the software.
• May be manual or use computer tools.
Dynamic verification:
• Testing the software with trial data.
• Debugging to remove errors.
11
CS 501 Spring 2005
Static Validation & Verification
Carried out throughout the software development process.
Validation &
verification
Requirements
specification
Design
Program
REVIEWS
12
CS 501 Spring 2005
Static Verification: Program Inspections
Formal program reviews whose objective is to detect faults
•
Code may be read or reviewed line by line.
• 150 to 250 lines of code in 2 hour meeting.
•
Use checklist of common errors.
•
Requires team commitment, e.g., trained leaders
So effective that it is claimed that it can replace unit testing
13
CS 501 Spring 2005
Inspection Checklist: Common Errors
Data faults: Initialization, constants, array bounds, character
strings
Control faults: Conditions, loop termination, compound
statements, case statements
Input/output faults: All inputs used; all outputs assigned a
value
Interface faults: Parameter numbers, types, and order;
structures and shared memory
Storage management faults: Modification of links,
allocation and de-allocation of memory
Exceptions: Possible errors, error handlers
14
CS 501 Spring 2005
Static Analysis Tools
Program analyzers scan the source of a program for possible
faults and anomalies (e.g., Lint for C programs).
•
Control flow: loops with multiple exit or entry points
•
Data use: Undeclared or uninitialized variables, unused
variables, multiple assignments, array bounds
•
Interface faults: Parameter mismatches, non-use of
functions results, uncalled procedures
• Storage management: Unassigned pointers, pointer
arithmetic
15
CS 501 Spring 2005
Static Analysis Tools (continued)
Static analysis tools
• Cross-reference table: Shows every use of a variable,
procedure, object, etc.
• Information flow analysis: Identifies input variables on which
an output depends.
• Path analysis: Identifies all possible paths through the
program.
16
CS 501 Spring 2005
Failures and Faults
Failure: Software does not deliver the service expected by
the user (e.g., mistake in requirements, confusing user
interface)
Fault (BUG): Programming or design error whereby the
delivered system does not conform to specification (e.g.,
coding error, interface error)
17
CS 501 Spring 2005
Faults and Failures?
Actual examples
(a) A mathematical function loops for ever from rounding error.
(b) A distributed system hangs because of a concurrency problem.
(c) After a network is hit by lightning, it crashes on restart.
(d) A program dies because the programmer typed: x = 1 instead
of x == 1.
(e) The head of an organization is paid $5 a month instead of
$10,005 because the maximum salary allowed by the program
is $10,000.
(f) An operating system fails because of a page-boundary error in
the firmware.
18
CS 501 Spring 2005
Terminology
Fault avoidance
Build systems with the objective of creating faultfree (bug-free) software
Fault tolerance
Build systems that continue to operate when faults
(bugs) occur
Fault detection (testing and validation)
Detect faults (bugs) before the system is put into
operation.
19
CS 501 Spring 2005
Fault Avoidance
Software development process that aims to develop zero-defect
software.
•
•
•
•
•
Formal specification
Incremental development with customer input
Constrained programming options
Static verification
Statistical testing
It is always better to prevent defects than to remove them later.
Example: The four color problem.
20
CS 501 Spring 2005
Defensive Programming
Murphy's Law:
If anything can go wrong, it will.
Defensive Programming:
• Redundant code is incorporated to check system state after
modifications.
•
Implicit assumptions are tested explicitly.
• Risky programming constructs are avoided.
21
CS 501 Spring 2005
Defensive Programming:
Error Avoidance
Risky programming constructs
•
•
•
•
•
•
Pointers
Dynamic memory allocation
Floating-point numbers
Parallelism
Recursion
Interrupts
All are valuable in certain circumstances, but
should be used with discretion
22
CS 501 Spring 2005
Defensive Programming Examples
• Use boolean variable not integer
• Test i <= n not i = = n
• Assertion checking (e.g., validate parameters)
• Build debugging code into program with a switch to
display values at interfaces
• Error checking codes in data (e.g., checksum or
hash)
23
CS 501 Spring 2005
Maintenance
Most production programs are maintained by people
other than the programmers who originally wrote them.
(a) What factors make a program easy for somebody
else to maintain?
(b) What factors make a program hard for somebody
else to maintain?
24
CS 501 Spring 2005
Fault Tolerance
General Approach:
• Failure detection
• Damage assessment
• Fault recovery
• Fault repair
N-version programming -- Execute independent
implementation in parallel, compare results, accept the
most probable.
25
CS 501 Spring 2005
Fault Tolerance
Basic Techniques:
• After error continue with next transaction (e.g.,
drop packet)
• Timers and timeout in networked systems
•
Error correcting codes in data
•
Bad block tables on disk drives
• Forward and backward pointers in databases
Report all errors for quality control
26
CS 501 Spring 2005
Fault Tolerance
Backward Recovery:
•
Record system state at specific events (checkpoints). After
failure, recreate state at last checkpoint.
•
Combine checkpoints with system log that allows
transactions from last checkpoint to be repeated
automatically.
• Test the restore software!
27
CS 501 Spring 2005
Software Engineering for Real Time
The special characteristics of real time computing require
extra attention to good software engineering principles:
• Requirements analysis and specification
• Development of tools
• Modular design
• Exhaustive testing
Heroic programming will fail!
28
CS 501 Spring 2005
Software Engineering for Real Time
Testing and debugging need special tools and environments
29
•
Debuggers, etc., can not be used to test real time
performance
•
Simulation of environment may be needed to test interfaces
-- e.g., adjustable clock speed
•
General purpose tools may not be available
CS 501 Spring 2005
Some Notable Bugs
•
Built-in function in Fortran compiler (e0 = 0)
•
Japanese microcode for Honeywell DPS virtual memory
• The microfilm plotter with the missing byte (1:1023)
• The Sun 3 page fault that IBM paid to fix
•
Left handed rotation in the graphics package
Good people work around problems.
The best people track them down and fix them!
30
CS 501 Spring 2005