8/14/2019 schach5-chap14-14[1]

1/85

Slide 14.1

The McGraw-Hill Companies, 2002

Object-Oriented andClassical Software

Engineering

Fifth Edition, WCB/McGraw-Hill, 2002

Stephen R. Schachsrs@vuse.vanderbilt.edu

8/14/2019 schach5-chap14-14[1]

2/85

Slide 14.2

The McGraw-Hill Companies, 2002

CHAPTER 14

IMPLEMENTATIONPHASE

8/14/2019 schach5-chap14-14[1]

3/85

Slide 14.3

The McGraw-Hill Companies, 2002

Overview

q Choice of programming language

q Fourth generation languages

q Good programming practice

q Coding standards

q Module reuse

q Module test case selection

q Black-box module-testing techniques

q Glass-box module-testing techniques

8/14/2019 schach5-chap14-14[1]

4/85

Slide 14.4

The McGraw-Hill Companies, 2002

Overview (contd)

q Code walkthroughs and inspections

q Comparison of module-testing techniques

q Cleanroom

q Potential problems when testing objects

q Management aspects of module testing

q When to rewrite rather than debug a module

q CASE tools for the implementation phase

q Air Gourmet Case Study: Black-box test casesq Challenges of the implementation phase

8/14/2019 schach5-chap14-14[1]

5/85

Slide 14.5

The McGraw-Hill Companies, 2002

Implementation Phase

q Programming-in-the-many

q Choice of Programming Language Language is usually specified in contract

q But what if the contract specifies

The product is to be implemented in the mostsuitable programming language

q What language should be chosen?

8/14/2019 schach5-chap14-14[1]

6/85

Slide 14.6

The McGraw-Hill Companies, 2002

Choice of Programming Language (contd)

q Example QQQ Corporation has been writing COBOL

programs for over 25 years

Over 200 software staff, all with COBOL expertise

What is most suitable programming language?

q Obviously COBOL

8/14/2019 schach5-chap14-14[1]

7/85

Slide 14.7

The McGraw-Hill Companies, 2002

Choice of Programming Language (contd)

q What happens when new language (C++, say)

is introduced New hires

Retrain existing professionals

Future products in C++

Maintain existing COBOL products Two classes of programmers

COBOL maintainers (despised)

C++ developers (paid more)

Need expensive software, and hardware to run it 100s of person-years of expertise with COBOL

wasted

8/14/2019 schach5-chap14-14[1]

8/85

Slide 14.8

The McGraw-Hill Companies, 2002

Choice of Programming Language (contd)

q Only possible conclusion COBOL is the most suitable programming

language

q And yet, the most suitable language for thelatest project maybe C++

COBOL is suitable for only DP applicationsq How to choose a programming language

Cost-benefit analysis

Compute costs, benefits of all relevant languages

8/14/2019 schach5-chap14-14[1]

9/85

8/14/2019 schach5-chap14-14[1]

10/85

Slide 14.10

The McGraw-Hill Companies, 2002

Fourth Generation Languages

q First generation languages Machine languages

q Second generation languages Assemblers

q

Third generation languages High-level languages (COBOL, FORTRAN,C++)

q Fourth generation languages (4GLs)

One 3GL statement is equivalent to 510assembler statements

Each 4GL statement intended to be equivalentto 30 or even 50 assembler statements

8/14/2019 schach5-chap14-14[1]

11/85

Slide 14.11

The McGraw-Hill Companies, 2002

Fourth Generation Languages (contd)

q It was hoped that 4GLs would Speed up application-building

Applications easy, quick to change Reducing maintenance costs

Simplify debugging Make languages user friendly

Leading to end-user programming

q Achievable if 4GL is a user

friendly, very high-level language

8/14/2019 schach5-chap14-14[1]

12/85

Slide 14.12

The McGraw-Hill Companies, 2002

Fourth Generation Languages (contd)

q Example (Just in Case You Wanted to Know box, page 438)

q The power of a nonprocedural language, andthe price

8/14/2019 schach5-chap14-14[1]

13/85

Slide 14.13

The McGraw-Hill Companies, 2002

Productivity Increases with a 4GL?

q The picture is not uniformly rosy

q Problems with Poor management techniques

Poor design methods

q James Martin suggests use of Prototyping

Iterative design

Computerized data management

Computer-aided structuring

q Is he right? Does he (or anyone else) know?

8/14/2019 schach5-chap14-14[1]

14/85

Slide 14.14

The McGraw-Hill Companies, 2002

Actual Experiences with 4GLs

q Playtex used ADF, obtained an 80 to 1productivity increase over COBOL However, Playtex then used COBOL for later

applications

q

4GL productivity increases of 10 to 1 overCOBOL have been reported However, there are plenty of reports of bad

experiences

8/14/2019 schach5-chap14-14[1]

15/85

Slide 14.15

The McGraw-Hill Companies, 2002

Actual Experiences with 4GLs (contd)

q Attitudes of 43 Organizations to 4GLs Use of 4GL reduced users frustrations

Quicker response from DP department

4GLs slow and inefficient, on average

Overall, 28 organizations using 4GL for over 3 years feltthat the benefits outweighed the costs

8/14/2019 schach5-chap14-14[1]

16/85

Slide 14.16

The McGraw-Hill Companies, 2002

Fourth Generation Languages (contd)

q Market share No one 4GL dominates the software market

There are literally hundreds of 4GLs

Dozens with sizable user groups

q Reason No one 4GL has all the necessary features

q Conclusion Care has to be taken in selecting the appropriate 4GL

8/14/2019 schach5-chap14-14[1]

17/85

Slide 14.17

The McGraw-Hill Companies, 2002

Key Factors When Using a 4GL

q Large sums for training

q Management techniques for 4GL, not for COBOL

q Design methods must be appropriate, especiallycomputer-aided design

q Interactive prototypingq 4GLs and complex products

8/14/2019 schach5-chap14-14[1]

18/85

8/14/2019 schach5-chap14-14[1]

19/85

Slide 14.19

The McGraw-Hill Companies, 2002

Good Programming Practice

q Use of consistent and meaningful variable

names Meaningful to future maintenance programmer

Consistent to aid maintenance pyrogrammer

8/14/2019 schach5-chap14-14[1]

20/85

Slide 14.20

The McGraw-Hill Companies, 2002

Good Programming Practice Example

q

Module contains variables

freqAverage,frequencyMaximum, minFr, frqncyTotl

q Maintenance programmer has to know iffreq,frequency, fr, frqncy all refer to the same thing

If so, use identical word, preferably frequency, perhapsfreq orfrqncy, notfr

If not, use different word (e.g., rate) for different quantity

q Can use frequencyAverage, frequencyMyaximum,

frequencyMinimum, frequencyTotalq Can also use averageFrequency, maximumFrequency,

minimumFrequency, totalFrequency

q All four names must come from the same set

8/14/2019 schach5-chap14-14[1]

21/85

Slide 14.21

The McGraw-Hill Companies, 2002

Good Programming Practice (contd)

q Issue of self-documenting code Exceedingly rare

q Key issue: Can module be understood easily andunambiguously by

SQA team Maintenance programmers

All others who have to read the code

8/14/2019 schach5-chap14-14[1]

22/85

Slide 14.22

The McGraw-Hill Companies, 2002

Good Programming Practice (contd)

q Example VariablexCoordinateOfPositionOfRobotArm Abbreviated to xCoord

Entire module deals with the movement of the robot arm

But does the maintenance programmer know this?

8/14/2019 schach5-chap14-14[1]

23/85

Slide 14.23

The McGraw-Hill Companies, 2002

Prologue Comments

q Mandatory at top of every single module

Minimum information Module name

Brief description of what the module does

Programmers name

Date module was coded

Date module was approved, and by whom

Module parameters

Variable names, in alphabetical order, and uses

Files accessed by this module

Files updated by this module Module i/o

Error handling capabilities

Name of file of test data (for regression testing)

List of modifications made, when, approved by whom

Known faults, if any

8/14/2019 schach5-chap14-14[1]

24/85

Slide 14.24

The McGraw-Hill Companies, 2002

Other Comments

q Suggestion

Comments are essential whenever code is written in anon-obvious way, or makes use of some subtle aspectof the language

q Nonsense!

Recode in a clearer way We must never promote/excuse poor programming

However, comments can assist maintenanceprogrammers

q Code layout for increased readability Use indentation

Better, use a pretty-printer

Use blank lines

8/14/2019 schach5-chap14-14[1]

25/85

Slide 14.25

The McGraw-Hill Companies, 2002

NestedifStatements

q Example Map consists of two squares. Write code to determine

whether a point on the Earths surface lies inmap square1 ormap square 2, or is not on the map

8/14/2019 schach5-chap14-14[1]

26/85

Slide 14.26

The McGraw-Hill Companies, 2002

NestedifStatements (contd)

q Solution 1. Badly formatted

8/14/2019 schach5-chap14-14[1]

27/85

Slide 14.27

The McGraw-Hill Companies, 2002

NestedifStatements (contd)

q Solution 2. Well-formatted, badly constructed

8/14/2019 schach5-chap14-14[1]

28/85

Slide 14.28

The McGraw-Hill Companies, 2002

NestedifStatements (contd)

q Solution 3. Acceptably nested

8/14/2019 schach5-chap14-14[1]

29/85

8/14/2019 schach5-chap14-14[1]

30/85

Slide 14.30

The McGraw-Hill Companies, 2002

Programming Standards

q Can be both a blessing and a curse

q Modules of coincidental cohesion arise fromrules like Every module will consist of between 35 and 50

executable statementsq Better

Programmers should consult their managers beforeconstructing a module with fewer than 35 or more

than 50 executable statements

8/14/2019 schach5-chap14-14[1]

31/85

Slide 14.31

The McGraw-Hill Companies, 2002

Remarks on Programming Standards

q No standard can ever be universally applicable

q Standards imposed from above will be ignored

q Standard must be checkable by machine

8/14/2019 schach5-chap14-14[1]

32/85

Slide 14.32

The McGraw-Hill Companies, 2002

Remarks on Programming Standards (contd)

q Examples of good programming standards Nesting ofifstatements should not exceed a

depth of 3, except with prior approval from theteam leader

Modules should consist of between 35 and 50

statements, except with prior approval from theteam leader

Use ofgotos should be avoided. However, withprior approval from the team leader, a forward gotomay be used for error handling

8/14/2019 schach5-chap14-14[1]

33/85

Slide 14.33

The McGraw-Hill Companies, 2002

Remarks on Programming Standards (contd)

q Aim of standards is to make maintenance easier If it makes development difficult, then must be modified

Overly restrictive standards are counterproductive

Quality of software suffers

S f Q C

8/14/2019 schach5-chap14-14[1]

34/85

Slide 14.34

The McGraw-Hill Companies, 2002

Software Quality Control

q After preliminary testing by the programmer, the

module is handed over to the SQA group

M d l R

8/14/2019 schach5-chap14-14[1]

35/85

Slide 14.35

The McGraw-Hill Companies, 2002

Module Reuse

q The most common form of reuse

M d l T t C S l ti

8/14/2019 schach5-chap14-14[1]

36/85

Slide 14.36

The McGraw-Hill Companies, 2002

Module Test Case Selection

q Worst wayrandom testing

q Need systematic way to construct test cases

M d l T t C S l ti ( td)

8/14/2019 schach5-chap14-14[1]

37/85

Slide 14.37

The McGraw-Hill Companies, 2002

Module Test Case Selection (contd)

q Two extremes to testingq 1. Test to specifications (also called black-

box, data-driven, functional, or input/outputdriven testing) Ignore code. Use specifications to select test cases

q 2. Test to code (also called glass-box, logic-driven, structured, or path-oriented testing) Ignore specifications. Use code to select test cases

F ibilit f T ti t S ifi ti

8/14/2019 schach5-chap14-14[1]

38/85

Slide 14.38

The McGraw-Hill Companies, 2002

Feasibility of Testing to Specifications

q Example

Specifications for data processing product include 5types of commission and 7 types of discount

35 test cases

q

Cannot say that commission and discount arecomputed in two entirely separate modulesthestructure is irrelevant

F ibilit f T ti t S ifi ti

8/14/2019 schach5-chap14-14[1]

39/85

Slide 14.39

The McGraw-Hill Companies, 2002

Feasibility of Testing to Specifications

q Suppose specs include 20 factors, each taking

on 4 values 420 or 1.1 1012 test cases

If each takes 30 seconds to run, running all test casestakes > 1 million years

q Combinatorial explosion makes testing tospecifications impossible

F ibilit f T ti t C d

8/14/2019 schach5-chap14-14[1]

40/85

Slide 14.40

The McGraw-Hill Companies, 2002

Feasibility of Testing to Code

q Each path through module must be executed

at least once Combinatorial explosion

F ibilit f T ti t C d ( td)

8/14/2019 schach5-chap14-14[1]

41/85

Slide 14.41

The McGraw-Hill Companies, 2002

Feasibility of Testing to Code (contd)

q Flowchart has over 1012 different paths

F ibilit f T ti t C d ( td)

8/14/2019 schach5-chap14-14[1]

42/85

Slide 14.42

The McGraw-Hill Companies, 2002

Feasibility of Testing to Code (contd)

q Can exercise every path without detecting every

fault

Feasibilit of Testing to Code (contd)

8/14/2019 schach5-chap14-14[1]

43/85

Slide 14.43

The McGraw-Hill Companies, 2002

Feasibility of Testing to Code (contd)

q

Path can be tested only if it is presentq Weaker Criteria

Exercise both branches of all conditional statements

Execute every statement

Feasibility of Testing to Code (contd)

8/14/2019 schach5-chap14-14[1]

44/85

Slide 14.44

The McGraw-Hill Companies, 2002

Feasibility of Testing to Code (contd)

q Can exercise every path without detecting every

faultq Path can be tested only if it is presentq Weaker Criteria

Exercise both branches of all conditional statements

Execute every statement

Coping with the Combinatorial Explosion

8/14/2019 schach5-chap14-14[1]

45/85

Slide 14.45

The McGraw-Hill Companies, 2002

Coping with the Combinatorial Explosion

q Neither testing to specifications nor testing to

code is feasibleq The art of testing:

q Select a small, manageable set of test cases to

Maximize chances of detecting fault, while Minimizing chances of wasting test case

q Every test case must detect a previouslyundetected fault

Coping with the Combinatorial Explosion

8/14/2019 schach5-chap14-14[1]

46/85

Slide 14.46

The McGraw-Hill Companies, 2002

Coping with the Combinatorial Explosion

q We need a method that will highlight as

many faults as possible First black-box test cases (testing to

specifications)

Then glass-box methods (testing to code)

8/14/2019 schach5-chap14-14[1]

47/85

Equivalence Testing (contd)

8/14/2019 schach5-chap14-14[1]

48/85

Slide 14.48

The McGraw-Hill Companies, 2002

Equivalence Testing (contd)

q Range (1..16,383) defines three different

equivalence classes: Equivalence Class 1: Fewer than 1 record

Equivalence Class 2: Between 1 and 16,383 records

Equivalence Class 3: More than 16,383 records

Boundary Value Analysis

8/14/2019 schach5-chap14-14[1]

49/85

Slide 14.49

The McGraw-Hill Companies, 2002

Boundary Value Analysis

q Select test cases on or just to one side of the

boundary of equivalence classes This greatly increases the probability of detecting

fault

8/14/2019 schach5-chap14-14[1]

50/85

8/14/2019 schach5-chap14-14[1]

51/85

Overall Strategy

8/14/2019 schach5-chap14-14[1]

52/85

Slide 14.52

The McGraw-Hill Companies, 2002

Overall Strategy

q Equivalence classes together with boundary

value analysis to test both input specificationsand output specifications Small set of test data with potential of uncovering

large number of faults

Glass Box Module Testing Methods

8/14/2019 schach5-chap14-14[1]

53/85

Slide 14.53

The McGraw-Hill Companies, 2002

Glass-Box Module Testing Methods

q Structural testing

Statement coverage

Branch coverage

Linear code sequences

All-definition-use path coverage

Structural Testing: Statement Coverage

8/14/2019 schach5-chap14-14[1]

54/85

Slide 14.54

The McGraw-Hill Companies, 2002

Structural Testing: Statement Coverage

q Statement coverage:

Series of test cases to check every statement

CASE tool needed to keep track

q Weakness

Branch statements

q Both statements can be

executed without thefault showing up

Structural Testing: Branch Coverage

8/14/2019 schach5-chap14-14[1]

55/85

Slide 14.55

The McGraw-Hill Companies, 2002

Structural Testing: Branch Coverage

q Series of tests to check all branches (solves

above problem) Again, a CASE tool is needed

q Structural testing: path coverage

8/14/2019 schach5-chap14-14[1]

56/85

All-definition-use-path Coverage

8/14/2019 schach5-chap14-14[1]

57/85

Slide 14.57

The McGraw-Hill Companies, 2002

All-definition-use-path Coverage

q Each occurrence of variable, zz say, is labeled

either as The definition of a variable

zz = 1 orread (zz)

or the use of variable

y = zz + 3 orif (zz < 9) errorB ()

q Identify all paths from the definition of a variableto the use of that definition

This can be done by an automatic toolq A test case is set up for each such path

All-definition-use-path Coverage (contd)

8/14/2019 schach5-chap14-14[1]

58/85

Slide 14.58

The McGraw-Hill Companies, 2002

All definition use path Coverage (contd)

q Disadvantage:

Upper bound on number of paths is2d, where d isthe number of branches

q In practice The actual number of paths is proportional to d in

real cases

q This is therefore a practical test caseselection technique

Infeasible Code

8/14/2019 schach5-chap14-14[1]

59/85

Slide 14.59

The McGraw-Hill Companies, 2002

Infeasible Code

q It may not be

possible to testa specificstatement May have an

infeasible path(dead code)in the module

q Frequently thisis evidence ofa fault

Measures of Complexity

8/14/2019 schach5-chap14-14[1]

60/85

Slide 14.60

The McGraw-Hill Companies, 2002

Measures of Complexity

q Quality assurance approach to glass-box testing

Module m1 is more complex than module m2

q Metric of software complexity Highlights modules mostly likely to have faults

q

If complexity is unreasonably high, then redesign,reimplement Cheaper and faster

8/14/2019 schach5-chap14-14[1]

61/85

Other Measures of Complexity

8/14/2019 schach5-chap14-14[1]

62/85

Slide 14.62

The McGraw-Hill Companies, 2002

Other Measures of Complexity

q Cyclomatic complexity M (McCabe)

Essentially the number of decisions (branches) in themodule

Easy to compute

A surprisingly good measure of faults (but see later)

q Modules with M > 10 have statistically moreerrors (Walsh)

Software Science Metrics

8/14/2019 schach5-chap14-14[1]

63/85

Slide 14.63

The McGraw-Hill Companies, 2002

Software Science Metrics

q [Halstead] Used for

fault prediction Basic elements are

the number ofoperators and

operands in themodule

q Widely challenged

q Example

8/14/2019 schach5-chap14-14[1]

64/85

Code Walkthroughs and Inspections

8/14/2019 schach5-chap14-14[1]

65/85

Slide 14.65

The McGraw-Hill Companies, 2002

Code Walkthroughs and Inspections

q Rapid and thorough fault detection

Up to 95% reduction in maintenance costs[Crossman, 1982]

8/14/2019 schach5-chap14-14[1]

66/85

SComparison: Module Testing Techniques (contd)

8/14/2019 schach5-chap14-14[1]

67/85

Slide 14.67

The McGraw-Hill Companies, 2002

Comparison: Module Testing Techniques (contd)

q Tests of 32 professional programmers, 42

advanced students in two groups (Basili andSelby, 1987)

q Professional programmers Code reading detected more faults

Code reading had a faster fault detection rateq Advanced students, group 1

No significant difference between the three methods

q Advanced students, group 2 Code reading and black-box testing were equally good

Both outperformed glass-box testing

8/14/2019 schach5-chap14-14[1]

68/85

Slid 14 69Cleanroom

8/14/2019 schach5-chap14-14[1]

69/85

Slide 14.69

The McGraw-Hill Companies, 2002

q Different approach to software development

q Incorporates Incremental process model

Formal techniques

Reviews

Slid 14 70Cleanroom (contd)

8/14/2019 schach5-chap14-14[1]

70/85

Slide 14.70

The McGraw-Hill Companies, 2002

( )

q Case study

q 1820 lines of FoxBASE (U.S. NavalUnderwater Systems Center, 1992) 18 faults detected by functional verification

Informal proofs

19 faults detected in walkthroughs beforecompilation

NO compilation errors

NO execution-time failures

Slide 14 71Cleanroom (contd)

8/14/2019 schach5-chap14-14[1]

71/85

Slide 14.71

The McGraw-Hill Companies, 2002

( )

q Fault counting procedures differ:

q Usual paradigms Count faults after informal testing (once SQA starts)

q Cleanroom Count faults after inspections (once compilation

starts)

8/14/2019 schach5-chap14-14[1]

72/85

Slide 14 73Testing Objects

8/14/2019 schach5-chap14-14[1]

73/85

Slide 14.73

The McGraw-Hill Companies, 2002

g j

q We must inspect classes, objects

q We can run test cases on objectsq Classical module

About 50 executable statements

Give input arguments, check output arguments

q Object About 30 methods, some with 2, 3 statements

Do not return value to callerchange state

It may not be possible to check stateinformationhiding

Method determine balanceneed to know accountBalancebefore, after

Slide 14 74Testing Objects (contd)

8/14/2019 schach5-chap14-14[1]

74/85

Slide 14.74

The McGraw-Hill Companies, 2002

g j ( )

q Need additional methods to return values of all

state variables Part of test plan

Conditional compilation

q

Inherited method may still have to be tested

Slide 14 75Testing Objects (contd)

8/14/2019 schach5-chap14-14[1]

75/85

Slide 14.75

The McGraw-Hill Companies, 2002

g j ( )

q Java implementation

of tree hierarchy

Slide 14 76Testing Objects (contd)

8/14/2019 schach5-chap14-14[1]

76/85

Slide 14.76

The McGraw-Hill Companies, 2002

g j ( )

q Top halfq When displayNodeContentsis invoked inBinaryTree, it

uses RootedTree.printRoutine

8/14/2019 schach5-chap14-14[1]

77/85

8/14/2019 schach5-chap14-14[1]

78/85

8/14/2019 schach5-chap14-14[1]

79/85

Slide 14.80Module Testing: Management Implications

8/14/2019 schach5-chap14-14[1]

80/85

The McGraw-Hill Companies, 2002

q We need to know when to stop testing

Costbenefit analysis Risk analysis

Statistical techniques

Slide 14.81When to Rewrite Rather Than Debug

8/14/2019 schach5-chap14-14[1]

81/85

The McGraw-Hill Companies, 2002

q When a module has too many faults It is cheaper to redesign, recode

q Risk, cost of further faults

Slide 14.82Fault Distribution In Modules Is Not Uniform

8/14/2019 schach5-chap14-14[1]

82/85

The McGraw-Hill Companies, 2002

q [Myers, 1979]

47% of the faults in OS/370 were in only 4% of themodules

q [Endres, 1975] 512 faults in 202 modules of DOS/VS (Release 28)

112 of the modules had only one fault

There were modules with 14, 15, 19 and 28 faults,respectively

The latter three were the largest modules in the product,with over 3000 lines of DOS macro assembler language

The module with 14 faults was relatively small, and veryunstable

A prime candidate for discarding, recoding

Slide 14.83Fault Distribution In Modules Not Uniform (contd)

8/14/2019 schach5-chap14-14[1]

83/85

The McGraw-Hill Companies, 2002

q For every module, management must

predetermine maximum allowed number offaults during testing

q If this number is reached Discard

Redesign

Recode

q Maximum number of faults allowed after

deliveryis ZERO

Slide 14.84Air Gourmet Case Study: Black-Box Test Cases

8/14/2019 schach5-chap14-14[1]

84/85

The McGraw-Hill Companies, 2002

q Sample black-box test cases

q Appendix J contains complete set

Slide 14.85Challenges of the Implementation Phase

8/14/2019 schach5-chap14-14[1]

85/85

q Module reuse needs to be built into the product

from the very beginningq Reuse must be a client requirement

q Software project management plan must

incorporate reuse