CS 501: Software Engineering

Lecture 20

Reliability 2

1 CS 501 Spring 2008

 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.
Better to deliver a limited first phase done well than a fuller
system that is incomplete, untested, or without
documentation.

2 CS 501 Spring 2008

 Quiz 3: Sports equipment online

A company that makes sports equipment decides to create a system

for selling sports equipment online. The company already has a
product database with specification, marketing information, and
prices of the equipment that it manufactures.
To sell equipment online the company will need to create: a
customer database, and an ordering system for online customers.
The plan is to develop the system in two phases. During Phase 1,
simple versions of the customer database and ordering system will
be brought into production. In Phase 2, major enhancements will be
made to these components.

3 CS 501 Spring 2008

 Quiz 3 Q1

(a) For the system architecture of

Phase 1:
DeptServer
i Draw a UML deployment diagram.
Product
DB
PersonalComp
Ordering
WebBrowser system

Customer
DB

4 CS 501 Spring 2008

 Quiz 3 Q1

Product
(a) For the system architecture of
DB
Phase 1:
i Draw a UML interface diagram.

WebBrowser Ordering
system

Customer
DB
5 CS 501 Spring 2008
 Quiz 3 Q1

(b) For Phase 1:

i What architectural style would you use for the
customer database?
Repository with Storage Access Layer
ii Why would you choose this style?
It allows the DB to be replaced without
changing the applications that use the DB.

6 CS 501 Spring 2008

 Quiz 3 Q1

(b) For Phase 1:

iii Draw an UML diagram for this architectural style
showing its use in this application.

Customer DB

Input Storage Ordering

components Access System

optional

Data Store
7 CS 501 Spring 2008
 Quiz 3 Q2

Carefully design during Phase 1 will help the subsequent

development of new components in Phase 2.
(a) For the interface between the ordering system and the customer
database:
i Select a design pattern that will allow a gradual transition
from Phase 1 to Phase 2.
Bridge design pattern
(b) Draw a UML class diagram that shows how this design pattern
will be used in Phase 1.
If your diagram relies on abstract classes, inheritance, delegation
or similar properties be sure that this is clear on your diagram.

8
[See next two slides] CS 501 Spring 2008
 Quiz 3 Q2

Abstract class
Abstract classes are superclasses which contain abstract methods
and are defined such that concrete subclasses extend them by
implementing the methods. Before a class derived from an abstract
class can become concrete, i.e. a class that can be instantiated, it
must implement particular methods for all the abstract methods of
its parent classes.
The incomplete features of an abstract class are shared by a group
of subclasses which add different variations of the missing pieces.
Wikipedia 4/2/08

9 CS 501 Spring 2008

 Quiz 3 Q2

Ordering Client
System

OrderingAbstraction DBImplementor

RefinedOrderingAbstraction

ConcreteDBImplementorA

ConcreteDBImplementorB

10 CS 501 Spring 2008

 Quiz 3 Q2

(c) How does this design pattern support:

i Enhancements to the ordering system in Phase 2?
By subclassing OrderingAbstraction
ii A possible replacement of the customer database in Phase 2?
By allowing several ConcreteBDImplementor classes

11 CS 501 Spring 2008

 Static Validation & Verification

Carried out throughout the software development process.

Validation &
verification

Requirements
specification Design Program

REVIEWS

12 CS 501 Spring 2008

 Reviews: Design and Code

Concept
Colleagues review each other's work:
can be applied to any stage of software development
can be formal or informal
Design and code reviews are a fundamental part of good
software development

13 CS 501 Spring 2008

 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 are not working
on this project
Client -- representatives of the client who are knowledgeable
about this part of the process
14 CS 501 Spring 2008
 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 are not working on
this project
Client -- only if the client has a strong technical representative
In a small team, an individual may have several roles
15 CS 501 Spring 2008
 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.

16 CS 501 Spring 2008

 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

17 CS 501 Spring 2008

 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
18 CS 501 Spring 2008
 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

19 CS 501 Spring 2008

 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.

20 CS 501 Spring 2008

 Security in the Software Development
Process
The security goal
The security goal is to make sure that the agents (people or
external systems) who interact with a computer system, its
data, and its resources, are those that the owner of the system
would wish to have such interactions.
Security considerations need to be part of the entire software
development process. They may have a major impact on the
architecture chosen.
Example. Integration of Internet Explorer into Windows

21 CS 501 Spring 2008

 Agents and Components

A large system will have many agents and components:

• each is potentially unreliable and insecure
• components acquired from third parties may have unknown
security problems
• commercial off-the-shelf (COTS) problem
The software development challenge:
• develop secure and reliable components
• protect whole system from security problems in parts of it

22 CS 501 Spring 2008

 Techniques: Barriers

Place barriers that separate parts of a complex system:

• Isolate components, e.g., do not connect a computer to a
network
• Firewalls
• Require authentication to access certain systems or parts
of systems
Every barrier imposes restrictions on permitted uses of the
system
Barriers are most effective when the system can be divided
into subsystems with simple boundaries

23 CS 501 Spring 2008

 Techniques: Authentication &
Authorization

Authentication establishes the identity of an agent:

• What the agent knows (e.g., password)
• What the agent possess (e.g., smart card)
• Where does the agent have access to (e.g., crt-alt-del)
• What are the physical properties of the agent (e.g.,
fingerprint)
Authorization establishes what an authenticated agent may do:
• Access control lists
• Group membership
24 CS 501 Spring 2008
 Example: An Access Model for Digital
Content

User

Roles

Actions
Digital material
Access
Attributes Operations
Policies

25 CS 501 Spring 2008

 Techniques: Encryption

Allows data to be stored and transmitted securely, even

when the bits are viewed by unauthorized agents
Encryption

X Y

Decryption

Y X
• Private key and public key
• Digital signatures

26 CS 501 Spring 2008

 Security and People

People are intrinsically insecure:

• Careless (e.g, leave computers logged on, use simple passwords,
leave passwords where others can read them)
• Dishonest (e.g., stealing from financial systems)
• Malicious (e.g., denial of service attack)
Many security problems come from inside the organization:
• In a large organization, there will be some disgruntled and
dishonest employees
• Security relies on trusted individuals. What if they are
dishonest?
27 CS 501 Spring 2008
 Design for Security: People

• Make it easy for responsible people to use the system

• Make it hard for dishonest or careless people (e.g.,
password management)
• Train people in responsible behavior
• Test the security of the system
• Do not hide violations

28 CS 501 Spring 2008

 Suggested Reading

Trust in Cyberspace, Committee on Information Systems

Trustworthiness, National Research Council (1999)
http://www.nap.edu/readingroom/books/trust/
Fred Schneider, Cornell Computer Science, was the chair
of this study.

29 CS 501 Spring 2008

 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)

30 CS 501 Spring 2008

 Faults and Failures

Actual examples
(a) A program dies because the programmer typed: x = 1 instead
of x == 1.
(b) A mathematical function loops for ever from rounding error.
(c) A distributed system hangs because of a concurrency problem.
(d) After a network is hit by lightning, it crashes on restart.
(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.
31 CS 501 Spring 2008
 Terminology

Fault avoidance
Build systems with the objective of creating fault-
free (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.

32 CS 501 Spring 2008

 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.

33 CS 501 Spring 2008

 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.

34 CS 501 Spring 2008

 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

35 CS 501 Spring 2008

 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)

36 CS 501 Spring 2008

 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?

37 CS 501 Spring 2008

 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.

38 CS 501 Spring 2008

 Fault Tolerance

Basic Techniques:
• Timers and timeout in networked systems
• After error continue with next transaction (e.g.,
drop packet)
• User break options (e.g., force quit, cancel)
• Error correcting codes in data
• Bad block tables on disk drives
• Forward and backward pointers in databases
Report all errors for quality control
39 CS 501 Spring 2008
 Fault Tolerance

Backward Recovery:
• Record system state at specific events (checkpoints). After
failure, recreate state at last checkpoint.
• Backup of files
• Combine checkpoints with system log (audit trail of
transactions) that allows transactions from last checkpoint to
be repeated automatically.
• Test the restore software!

40 CS 501 Spring 2008

 Software Engineering for Real Time

The special characteristics of real time computing require

extra attention to good software engineering principles:
• Requirements analysis and specification
• Special techniques (e.g., locks on data, semaphores, etc.)
• Development of tools
• Modular design
• Exhaustive testing
Heroic programming will fail!

41 CS 501 Spring 2008

 Software Engineering for Real Time

Testing and debugging need special tools and environments

• 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

42 CS 501 Spring 2008

 Some Notable Bugs

Even commercial systems may have horrific 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
• The preload system with the memory leak
Good people work around problems.
The best people track them down and fix them!
43 CS 501 Spring 2008