ISBN 0-13-146913-4 Prentice-Hall, 2006 Unit 6 Writing the Programs Copyright 2006 Pearson/Prentice...

ISBN 0-13-146913-4Prentice-Hall, 2006

Unit 6

Writing thePrograms

Copyright 2006 Pearson/Prentice Hall. All rights reserved.

Pfleeger and Atlee, Software Engineering: Theory and Practice

Page 7.2© 2006 Pearson/Prentice Hall

Contents

7.1 Programming Standards and Procedures

7.2 Programming Guidelines

7.3 Documentation8.1 Software Faults and Failures8.2 Testing Issues8.3 Unit Testing11.4 Measuring Maintenance Characteristics



Chapter 7 Objectives

• Standards for programming• Guidelines for reuse• Using design to frame the code• Internal and external documentation



7.1 Programming Standards and Procedures

• Standards for you– Methods of code documentation

• Standards for others– Integrators, maintainers, testers– Prologue documentation– Automated tools to identify dependencies

• Matching design with implementation– Low coupling, high cohesion, well-defined

interfaces



7.1 Programming Standards and ProceduresSidebar 7.1 Programming Standards at Microsoft

• Allow flexibility to be creative and evolve product’s details in stages

• Flexibility does not preclude standards



7.2 Programming GuidelinesControl Structures

• Make the code easy to read• Build the program from modular blocks• Make the code not too specific, and not too

general• Use parameter names and comments to

exhibit coupling among components• Make the dependency among components

visible


.7© 2006 Pearson/Prentice Hall

7.2 Programming GuidelinesExample of Control Structures

• Control skips around among the program’s statements

benefit = minimum;if (age < 75) goto A;benefit = maximum;goto C;if (AGE < 65) goto B;if (AGE < 55) goto C;

A: if (AGE < 65) goto B;benefit = benefit * 1.5 + bonus;goto C;

B: if (age < 55) goto C;benefit = benefit * 1.5;

C: next statement

• Rearrange the codeif (age < 55) benefit = minimum;elseif (AGE < 65) benefit = minimum + bonus;elseif (AGE < 75) benefit = minimum * 1.5 + bonus;else benefit = maximum;



7.2 Programming GuidelinesAlgorithms

• Common objective and concern: performance (speed)

• Efficiency may have hidden costs– cost to write the code faster– cost to test the code– cost to understand the code– cost to modify the code



7.2 Programming GuidelinesData Structures

• Nested Ifs• Several techniques that use the structure of

data to organize the program– Keeping the program simple– Using a data structure to determine a program

structure



7.2 Programming GuidelinesKeep the Program Simple Example: Determining Federal Income Tax1.For the first $10,000 of income, the tax is 10%2.For the next $10,000 of income above $10,000, the tax is 12 percent3.For the next $10,000 of income above $20,000, the tax is 15 percent4.For the next $10,000 of income above $30,000, the tax is 18 percent5.For any income above $40,000, the tax is 20 percent

tax = 0.if (taxable_income == 0) goto EXIT;if (taxable_income > 10000) tax = tax + 1000;else{

tax = tax + .10*taxable_income;goto EXIT;

}if (taxable_income > 20000) tax = tax + 1200;else{

tax = tax + .12*(taxable_income-10000):goto EXIT;

}if (taxable_income > 30000) tax = tax + 1500;else{

tax = tax + .15*(taxable_income-20000);goto EXIT;

}if (taxable_income < 40000){

tax = tax + .18*(taxable_income-30000);goto EXIT;

}else

tax = tax + 1800. + .20*(taxable_income-40000);EXIT;



7.2 Programming GuidelinesKeep the Program Simple Example (continued)

• Define a tax table for each “bracket” of tax liability

• Simplified algorithmfor (int i-2); level=1; i <= 5; i++)

if (taxable_income > bracket[i]) level = level + 1;

tax = base[level]+percent[level]*(taxable_income-bracket[level]);

Bracket Base Percent

0 0 10

10,000 1000 12

20,000 2200 15

30,000 3700 18

40,000 55000 20



7.2 Programming GuidelinesData Structures Example: Rooted Tree

• Recursive data structure

• Graph composed of nodes and lines – Exactly one node as root

– If the lines emanating from the root are erased, the resulting graph is a rooted tree



7.2 Programming GuidelinesGeneral Guidelines to Preserve Quality

• Localize input and output• Employ pseudocode• Revise and rewrite, rather than patch• Reuse

– Producer reuse: create components designed to be reused in future applications

– Consumer reuse: reuse components initially developed for other projects



7.2 Programming GuidelinesExample of Pseudocode

• The design for a component of a text processing system statesCOMPONENT PARSE_LINE

Read next eighty characters.IF this is a continuation of the previous line,

Call CONTINUE

ELSE determine command typeENDIF

CASE of COMMAND_TYPECOMMAND_TYPE is paragraph: Call PARAGRAPHCOMMAND_TYPE is indent : Call INDENTCOMMAND_TYPE is skip line: Call SKIP_LINECOMMAND_TYPE is margin : Call MARGINCOMMAND_TYPE is new page : Call PAGECOMMAND_TYPE is double space : Call DOUBLE_SPACECOMMAND_TYPE is single space : Call SINGLE_SPACECOMMAND_TYPE is break : Call BREAKCOMMAND_TYPE is anything else: Call ERROR

ENDCASE



7.2 Programming GuidelinesExample of Pseudocode (continued)

• Intermediate pseudocodePARAGRAPH:

Break line, flush line buffer. Advance one line between paragraph. If fewer than 2 lines left on page, eject. Set line pointer to paragraph indent.

INDENT:Break line, flush line buffer. Get indent parameter. Set line pointer to indent parameter, set left margin to indent.

SKIP_LINE:Break line, flush line buffer. Get line parameter. Advance (parameter) lines or eject if not enough space left on current page.

MARGIN:Break line, flush line buffer. Get margin parameter. Set line pointer to left margin. Set right margin to margin.

PAGE:Break line, flush line buffer. Eject page. Set line pointer to left margin

DOUBLE_SPACE:Set interline space to 2.

SINGLE_SPACE:Set interline space to 1

BREAK:Break line, flush line buffer. Set pointer to left margin




• RegroupedFIRST:

PARAGRAPH, INDENT, SKIP_LINE, MARGIN, BREAK, PAGE:Break line, flush line buffer.

DOUBLE_SPACE, SINGLE_SPACE :No break line, no flush line buffer.

SECOND:INDENT, SKIP_LINE, MARGIN:

Get parameter.PARAGRAPH, BREAK, PAGE, DOUBLE_SPACE,

SINGLE_SPACE:No parameter needed.

THIRD:PARAGRAPH, INDENT, SKIP_LINE, MARGIN, BREAK, PAGE:

Set new line pointer.DOUBLE_SPACE, SINGLE_SPACE:

New line pointer unchanged.FOURTH:

Individual action taken




• Final pseudocodeINITIAL:

Get parameter for indent, skip_line, margin.Set left margin to parameter for indent.Set temporary line pointer to left margin for all but paragraph;

for paragraph, set to paragraph indent.LINE_BREAKS:

If not (DOUBLE_SPACE or SINGLE_SPACE), break line, flush line buffer and set line pointer to temporary line pointer

If 0 lines left on page, eject page and print page header.INDIVIDUAL CASES:

INDENT, BREAK: do nothing.SKIP_LINE: skip parameter lines or ejectPARAGRAPH: advance 1 line; if < 2 lines or page, eject.MARGIN: right_margin = parameter.DOUBLE_SPACE: interline_space = 2.SINGLE_SPACE: interline_space = 1;PAGE: eject page, print page header



7.2 Programming GuidelinesConsumer Reuse

• Four key characteristics to check about components to reuse – Does the component perform the function or

provide the data needed?– Is it less modification than building the

component from scratch?– Is the component well-documented?– Is there a complete record of the component’s

test and revision history?



7.2 Programming GuidelinesProducer Reuse

• Several issues to keep in mind – Make the components general– Separate dependencies (to isolate sections likely

to change)– Keep the component interface general and well-

defined– Include information about any faults found and

fixed– Use clear naming conventions– Document data structures and algorithms– Keep the communication and error-handling

sections separate and easy to modify



7.2 Programming GuidelinesSidebar 7.2 Selecting Components for Reuse at Lucent

• Reuse Council– Created inventory of components– Formed matrix with the features of all past and

planned projects– Met every week to make component selections,

inspect design documentation, and monitor levels of reuse



7.3 Documentation

• Internal documentation– header comment block– meaningful variable names and statement

labels– other program comments– format to enhance understanding– document data (data dictionary)

• External documentation– describe the problem– describe the algorithm– describe the data



7.3 DocumentationInformation Included in Header Comment Block

• What the component is called• Who wrote the component• Where the component fits in the general

system design• When the component was written and

revised• Why the component exists• How the component uses its data

structures, algorithms, and control



8.1 Software Faults and FailuresWhy Does Software Fail?

• Wrong requirement: not what the customer wants

• Missing requirement• Requirement impossible to implement• Faulty design• Faulty code• Improperly implemented design



8.1 Software Faults and Failures Objective of Testing

• Objective of testing: discover faults• A test is successful only when a fault is

discovered– Fault identification is the process of determining

what fault caused the failure– Fault correction is the process of making

changes to the system so that the faults are removed



8.1 Software Faults and FailuresTypes of Faults

• Algorithmic fault• Computation and precision fault

– a formula’s implementation is wrong

• Documentation fault– Documentation doesn’t match what program does

• Capacity or boundary faults– System’s performance not acceptable when certain limits

are reached

• Timing or coordination faults• Performance faults

– System does not perform at the speed prescribed

• Standard and procedure faults



8.1 Software Faults and FailuresTypical Algorithmic Faults

• An algorithmic fault occurs when a component’s algorithm or logic does not produce proper output– Branching too soon– Branching too late– Testing for the wrong condition– Forgetting to initialize variable or set loop

invariants– Forgetting to test for a particular condition– Comparing variables of inappropriate data types

• Syntax faults



8.1 Software Faults and FailuresOrthogonal Defect Classification

Fault Type Meaning

Function Fault that affects capability, end-user interface, product interface with hardware architecture, or global data structure

Interface Fault in interacting with other component or drivers via calls, macros, control blocks, or parameter lists

Checking Fault in program logic that fails to validate data and values properly before they are used

Assignment Fault in data structure or code block initialization

Timing/serialization Fault in timing of shared and real-time resources

Build/package/merge Fault that occurs because of problems in repositories, management changes, or version control

Documentation Fault that affects publications and maintenance notes

Algorithm Fault involving efficiency or correctness of algorithm or data structure but not design



8.1 Software Faults and FailuresSidebar 8.1 Hewlett-Packard’s Fault Classification



8.1 Software Faults and FailuresSidebar 8.1 Faults for one Hewlett-Packard Division



8.2 Testing IssuesTesting Organization

• Module testing, component testing, or unit testing

• Integration testing• Function testing• Performance testing• Acceptance testing• Installation testing



8.2 Testing IssuesTesting Organization Illustrated



8.2 Testing IssuesAttitude Toward Testing

• Egoless programming: programs are viewed as components of a larger system, not as the property of those who wrote them



8.2 Testing IssuesWho Performs the Test?

• Independent test team– avoid conflict– improve objectivity– allow testing and coding concurrently



8.2 Testing IssuesViews of the Test Objects

• Closed box or black box: functionality of the test objects

• Clear box or white box: structure of the test objects



8.2 Testing IssuesWhite Box

• Advantage– free of internal structure’s constraints

• Disadvantage– not possible to run a complete test



8.2 Testing IssuesClear Box

• Example of logic structure



8.2 Testing IssuesSidebar 8.2 Box Structures

• Black box: external behavior description• State box: black box with state information• White box: state box with a procedure



8.2 Testing IssuesFactors Affecting the Choice of Test Philosophy

• The number of possible logical paths• The nature of the input data• The amount of computation involved• The complexity of algorithms



8.3 Unit TestingCode Review

• Code walkthrough• Code inspection



8.3 Unit TestingTypical Inspection Preparation and Meeting Times

Development Artifact Preparation Time Meeting Time

Requirement Document

25 pages per hour 12 pages per hour

Functional specification 45 pages per hour 15 pager per hour

Logic specification 50 pages per hour 20 pages per hour

Source code 150 lines of code per hour

75 lines of code per hour

User documents 35 pages per hour 20 pages per hour



8.3 Unit TestingSidebar 8.3 The Best Team Size for Inspections

• The preparation rate, not the team size, determines inspection effectiveness

• The team’s effectiveness and efficiency depend on their familiarity with their product



8.3 Unit TestingProving Code Correct

• Formal proof techniques• Symbolic execution• Automated theorem-proving



8.3 Unit TestingProving Code Correct: An Illustration



8.3 Unit TestingTesting versus Proving

• Proving: hypothetical environment• Testing: actual operating environment



8.3 Unit TestingSteps in Choosing Test Cases

• Determining test objectives• Selecting test cases• Defining a test



8.3 Unit TestingTest Thoroughness

• Statement testing• Branch testing• Path testing• Definition-use testing• All-uses testing• All-predicate-uses/some-computational-

uses testing• All-computational-uses/some-predicate-

uses testing



8.3 Unit TestingRelative Strengths of Test Strategies



8.3 Unit TestingComparing Techniques

• Fault discovery Percentages by Fault Origin

Discovery Techniques

Requirements

Design Coding Documentation

Prototyping 40 35 35 15

Requirements review 40 15 0 5

Design Review 15 55 0 15

Code inspection 20 40 65 25

Unit testing 1 5 20 0



8.3 Unit TestingComparing Techniques (continued)

• Effectiveness of fault-discovery techniques

Requirements Faults Design Faults

Code Faults

Documentation Faults

Reviews Fair Excellent Excellent Good

Prototypes Good Fair Fair Not applicable

Testing Poor Poor Good Fair

Correctness Proofs Poor Poor Fair Fair



8.3 Unit TestingSidebar 8.4 Fault Discovery Efficiency at Contel IPC

• 17.3% during inspections of the system design

• 19.1% during component design inspection• 15.1% during code inspection• 29.4% during integration testing• 16.6% during system and regression testing• 0.1% after the system was placed in the

field



11.4 Measuring Maintenance Characteristics

• Maintainability is not only restricted to code, but also including specification, design, and test plan documentations

• Maintainability can be viewed in two ways– External view of the software– Internal view of the software



11.4 Measuring Maintenance CharacteristicsExternal View of Maintainability

• Necessary data– time at which problem is

reported– time lost due to

administrative delay– time required to analyze

problem– time required to specify

which changes are to be made

– time needed to make the change

– time needed to test the change

– Time needed to document the change

• Desirable data– ratio of total change

implementation time to total number of changes implemented

– number of unresolved problems

– time spent on unresolved problems

– percentage of changes that introduce new faults

– number of components modified to implement a change



11.4 Measuring Maintenance CharacteristicsExternal View of Maintainability (continued)

• Graph illustrates the mean time to repair the various subsystems for software at a large British firm



11.4 Measuring Maintenance CharacteristicsInternal Attributes Affecting Maintainability

• Cyclomatic number (McCabe, 1976)– The structural complexity of the source code

• linearly independent path– Based on graph theoretic concept

• Linearly independent path = e - n + 2– e: edges, n : nodes



11.4 Measuring Maintenance Characteristics Example for Calculating Cyclomatic Number• Consider the following code

Scoreboard::drawscore(int n){

while(numdigits-- > 0} {score[numdigits]->erase();

}// build new score in loop, each time update positionnumdigits = 0;// if score is 0, just display “0”if (n == 0) {

delete score[numdigits];score[numdigits] = new Displayable(digits[0]);score[numdigits]->move(Point((700-numdigits*18),40));score[numdigits]->draw();numdigits++;

}while (n) {

int rem = n % 10;delete score[numdigits];score[numdigits] = new Displayable(digits[rem]);score[numdigits]->move(Point(700-numdigits*18),40));score[numdigits]->draw();n /= 10;numdigits++;

}}



11.4 Measuring Maintenance Characteristics Example for Calculating Cyclomatic Number (continued)• Linearly independent path = e - n + 2

– e: edges, n : nodes



11.4 Measuring Maintenance CharacteristicsOther Measures

• Classification tree analysis– Identify product measures that are the best predictors of

interface errors

• Fog index: textual products, readability affects maintainability– F = 0.4 X (number of words/number of sentences) +

percentage of words of three or more syllables

• De Young and Kampen readability– R = 0.295a – 0.499b + 0.13c

• a : the average normalized length of variable• b: number of lines containing statements• c : McCabe’s cyclomatic number



11.4 Measuring Maintenance CharacteristicsSidebar 11.4 Models of Fault Behavior

• Hatton and Hopkins (1989) studied the NAG Fortran scientific subroutine library – Smaller components contained proportionately

more faults than larger ones

• They notes similar evidence – at Siemens– Ada code at Unisys– Fortran products at NASA Goddard



11.4 Measuring Maintenance CharacteristicsSidebar 11.5 Maintenance Measures at Hewlett-Packard

• Used maintainability index– Index was calibrated with a large number of

metrics– A tailored polynomial index was calculated

using extended cyclomatic number, lines of code, number of comments, and an effort measure

– The polynomial was applied to 714 components containing 236,000 lines of C code developed by third party

ISBN 0-13-146913-4 Prentice-Hall, 2006 Unit 6 Writing the Programs Copyright 2006 Pearson/Prentice...

Documents

Transcript of ISBN 0-13-146913-4 Prentice-Hall, 2006 Unit 6 Writing the Programs Copyright 2006 Pearson/Prentice...