cs 501 software engineering l.
Skip this Video
Loading SlideShow in 5 Seconds..
CS 501: Software Engineering PowerPoint Presentation
Download Presentation
CS 501: Software Engineering

Loading in 2 Seconds...

play fullscreen
1 / 43

CS 501: Software Engineering - PowerPoint PPT Presentation

  • Uploaded on

CS 501: Software Engineering Lecture 20 Reliability 2 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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'CS 501: Software Engineering' - jaden

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
cs 501 software engineering
CS 501: Software Engineering

Lecture 20

Reliability 2



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.

quiz 3 sports equipment online
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.

quiz 3 q1
Quiz 3 Q1

(a) For the system architecture of Phase 1:

i Draw a UML deployment diagram.


Product DB


Ordering system


Customer DB

quiz 3 q15
Quiz 3 Q1

Product DB

(a) For the system architecture of Phase 1:

i Draw a UML interface diagram.

Ordering system


Customer DB

quiz 3 q16
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.

quiz 3 q17
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 components

Storage Access

Ordering System


Data Store

quiz 3 q2
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.

[See next two slides]

quiz 3 q29
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

quiz 3 q210
Quiz 3 Q2

Ordering System







quiz 3 q211
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

static validation verification
Static Validation & Verification

Carried out throughout the software development process.

Validation & verification

Requirements specification




reviews design and code
Reviews: Design and Code


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

review team full version
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

example program design
Example: Program Design



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

static and dynamic verification
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.

static verification program inspections
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

inspection checklist common errors
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

static analysis tools
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

static analysis tools continued
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.

security in the software development process
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

agents and components
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

techniques barriers
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


Barriers are most effective when the system can be divided

into subsystems with simple boundaries

techniques authentication authorization
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

example an access model for digital content



Example: An Access Model for Digital Content


Digital material





techniques encryption
Techniques: Encryption

Allows data to be stored and transmitted securely, even when the bits are viewed by unauthorized agents

• Private key and public key

• Digital signatures







security and people
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?

design for security people
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

suggested reading
Suggested Reading

Trust in Cyberspace, Committee on Information Systems Trustworthiness, National Research Council (1999)


Fred Schneider, Cornell Computer Science, was the chair of this study.

failures and faults
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)

faults and failures
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.


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.

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

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

defensive programming error avoidance
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

defensive programming examples
Defensive Programming Examples

• Use boolean variable notinteger

• Test i <= nnot 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)


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?

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

fault tolerance39
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

fault tolerance40
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!

software engineering for real time
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!

software engineering for real time42
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

some notable bugs
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!