ISBN 0-13-146913-4 Prentice-Hall, 2006 Unit 6 Writing the Programs Copyright 2006 Pearson/Prentice...
-
Upload
hudson-humbles -
Category
Documents
-
view
222 -
download
0
Transcript of 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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.3© 2006 Pearson/Prentice Hall
Chapter 7 Objectives
• Standards for programming• Guidelines for reuse• Using design to frame the code• Internal and external documentation
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.4© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.5© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.6© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.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;
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.8© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.9© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.10© 2006 Pearson/Prentice Hall
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;
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.11© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.12© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.13© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.14© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.15© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.16© 2006 Pearson/Prentice Hall
7.2 Programming GuidelinesExample of Pseudocode (continued)
• 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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.17© 2006 Pearson/Prentice Hall
7.2 Programming GuidelinesExample of Pseudocode (continued)
• 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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.18© 2006 Pearson/Prentice Hall
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?
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.19© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.20© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.21© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.22© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.23© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.24© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.25© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.26© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.27© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.28© 2006 Pearson/Prentice Hall
8.1 Software Faults and FailuresSidebar 8.1 Hewlett-Packard’s Fault Classification
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.29© 2006 Pearson/Prentice Hall
8.1 Software Faults and FailuresSidebar 8.1 Faults for one Hewlett-Packard Division
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.30© 2006 Pearson/Prentice Hall
8.2 Testing IssuesTesting Organization
• Module testing, component testing, or unit testing
• Integration testing• Function testing• Performance testing• Acceptance testing• Installation testing
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.31© 2006 Pearson/Prentice Hall
8.2 Testing IssuesTesting Organization Illustrated
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.32© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.33© 2006 Pearson/Prentice Hall
8.2 Testing IssuesWho Performs the Test?
• Independent test team– avoid conflict– improve objectivity– allow testing and coding concurrently
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.34© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.35© 2006 Pearson/Prentice Hall
8.2 Testing IssuesWhite Box
• Advantage– free of internal structure’s constraints
• Disadvantage– not possible to run a complete test
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.36© 2006 Pearson/Prentice Hall
8.2 Testing IssuesClear Box
• Example of logic structure
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.37© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.38© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.39© 2006 Pearson/Prentice Hall
8.3 Unit TestingCode Review
• Code walkthrough• Code inspection
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.40© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.42© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.43© 2006 Pearson/Prentice Hall
8.3 Unit TestingProving Code Correct
• Formal proof techniques• Symbolic execution• Automated theorem-proving
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.44© 2006 Pearson/Prentice Hall
8.3 Unit TestingProving Code Correct: An Illustration
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.45© 2006 Pearson/Prentice Hall
8.3 Unit TestingTesting versus Proving
• Proving: hypothetical environment• Testing: actual operating environment
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.46© 2006 Pearson/Prentice Hall
8.3 Unit TestingSteps in Choosing Test Cases
• Determining test objectives• Selecting test cases• Defining a test
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.47© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.48© 2006 Pearson/Prentice Hall
8.3 Unit TestingRelative Strengths of Test Strategies
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.49© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.50© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.51© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.52© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.53© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.54© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.55© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.56© 2006 Pearson/Prentice Hall
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++;
}}
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.57© 2006 Pearson/Prentice Hall
11.4 Measuring Maintenance Characteristics Example for Calculating Cyclomatic Number (continued)• Linearly independent path = e - n + 2
– e: edges, n : nodes
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.58© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.59© 2006 Pearson/Prentice Hall
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 7.60© 2006 Pearson/Prentice Hall
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