design - programming cmpe 450 fall 2008. dynamic analysis software quality design carefully from the...

46
Design - programming Cmpe 450 Fall 2008

Upload: alban-ford

Post on 17-Jan-2016

215 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Design- programming

Cmpe 450Fall 2008

Page 2: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Dynamic Analysis Software quality

Design carefully from the start Simple and clean Fewer errors

Finding errors introduced in coding Dynamic techniques

Executing program and observe its behaviour

Page 3: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Static Analysis Ensure quality before execution

Design evaluation Code analysis

Manual reviews, tools

Page 4: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Dynamic Techniques Rush through specs and designs Fix up later

Design and implementation mixed, hard to find errors

Cost of fixing an error is higher at later stages

Page 5: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Static Techniques All errors can not be caught

statistically “testing can reveal the

presence of errors but never their absence”

Page 6: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Defensive Programming To increase reliability of the

program by inserting redundant checks Invariants

Runtime assertions Testing invariants explicitly

Page 7: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Defensive Programming To make code bug free in the most

effective way. Always better to write a good code

from scratch than fixing a bad code

When to write runtime assertions? As you write the code, not later...

Page 8: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Runtime Assertions- guidelines Check the precondition at the start of

the procedure No room for misunderstandings about

interfaces between procedures Check the postcondition

Self check Write assertions when operation is

about to be performed that has some external effect

Page 9: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Runtime assertions- mistakes Runtime assertions slow execution

down Write them in testing and turn

them off in the official release? WRONG WRONG PRACTICE

Page 10: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Debugging

Page 11: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Debugging Debugging is the least predictable software

development activity. One usually doesn’t know in advance whether finding the next bug will take five minutes or five weeks.

Some people debug using their intuition. From the nature of the symptom, they can go directly to the parts of the program that are most likely to contain the error.

While such intuition is useful and can be developed if you learn from experience, it is not necessary; there is a general approach to debugging that does not need it.

Page 12: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

General Approach When you run a buggy program on some test data,

initially everything is all right (variables have the right values, the right output is produced, control takes the expected path). Things go wrong after a point in time at which a buggy statement is executed. One can identify the buggy statement by identifying this point in time.

This of course requires the programmer to be able to tell what the right values of variables are at every point in the program.

For programmers other than the original authors, and sometimes even for them, this requires documentation of what the code is meant to do. If this is missing, it has to be recreated.

Page 13: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

The suspect period The suspect period is initially the entire run, the

whole sequence of statements executed by the program. At some point in the middle of the run, you can check whether everything is all right.

If not, you can eliminate the part of the suspect period after the point; the first bug is before that point. There may also be bugs after that point, but you should look for them after the first bug is fixed.

If yes, you can eliminate the part of the suspect period before the point; the first bug detectable by this test case is after that point. Any bugs before that point need another test case.

Page 14: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Binary Search

Page 15: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Approximating binary search

Page 16: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Minimizing the failed test case

Page 17: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Diagnostic printfs

Page 18: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Diagnostic printfs

Page 19: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Debuggers

Page 20: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Forward Execution

Page 21: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Choosing breakpoints

Page 22: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Breakpoints on functions

Page 23: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Global variables

Page 24: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Tracking errors to their source

Page 25: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Core files

Page 26: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Wild pointer errors

Page 27: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Laws of debugging

Page 28: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Some possibly untrue assumptions

Page 29: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Fixing bugs

Page 30: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Type safety

Page 31: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

The magical number seven

Page 32: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Coping with complexity

Page 33: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Abstraction

Page 34: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Modules

Page 35: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Undersanding modular programs

Page 36: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Information hiding

Page 37: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Language support

Page 38: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Declaration vs definition

Page 39: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Declaration vs definition

Page 40: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Declaration vs definition

Page 41: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Type safety convention, part 1

Page 42: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Quiz Is there type safety in C?

Explain yes or no on the sample piece of code.

What is the problem with this code?

Page 43: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

Example

Page 44: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors
Page 45: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

C’s lack of type safety

Page 46: Design - programming Cmpe 450 Fall 2008. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors

The problem