ISBN Prentice-Hall, 2006 Unit 6 Writing the Programs Copyright 2006 Pearson/Prentice Hall. All rights reserved.

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.2 © 2006 Pearson/Prentice Hall Contents 7.1 Programming Standards and Procedures 7.2 Programming Guidelines 7.3 Documentation 8.1Software Faults and Failures 8.2Testing Issues 8.3Unit Testing 11.4Measuring Maintenance Characteristics

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 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 PracticePage 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 PracticePage 7.5 © 2006 Pearson/Prentice Hall 7.1 Programming Standards and Procedures Sidebar 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 PracticePage 7.6 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Control 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 PracticePage 7.7 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Example 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 * bonus; goto C; B:if (age < 55) goto C; benefit = benefit * 1.5; C:next statement Rearrange the code if (age < 55) benefit = minimum; elseif (AGE < 65) benefit = minimum + bonus; elseif (AGE < 75) benefit = minimum * bonus; else benefit = maximum;

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.8 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Algorithms 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 PracticePage 7.9 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Data 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 PracticePage 7.10 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Keep the Program Simple Example: Determining Federal Income Tax 1.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 percent 3.For the next $10,000 of income above $20,000, the tax is 15 percent 4.For the next $10,000 of income above $30,000, the tax is 18 percent 5.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 ; else{ tax = tax +.10*taxable_income; goto EXIT; } if (taxable_income > 20000) tax = tax ; else{ tax = tax +.12*(taxable_income-10000): goto EXIT; } if (taxable_income > 30000) tax = tax ; else{ tax = tax +.15*(taxable_income-20000); goto EXIT; } if (taxable_income < 40000){ tax = tax +.18*(taxable_income-30000); goto EXIT; } else tax = tax *(taxable_income-40000); EXIT;

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.11 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Keep the Program Simple Example (continued) Define a tax table for each “bracket” of tax liability Simplified algorithm for (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]); BracketBasePercent , , , ,

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.12 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Data 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 PracticePage 7.13 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines General 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 PracticePage 7.14 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Example of Pseudocode The design for a component of a text processing system states COMPONENT PARSE_LINE Read next eighty characters. IF this is a continuation of the previous line, Call CONTINUE ELSE determine command type ENDIF CASE of COMMAND_TYPE COMMAND_TYPE is paragraph: Call PARAGRAPH COMMAND_TYPE is indent : Call INDENT COMMAND_TYPE is skip line: Call SKIP_LINE COMMAND_TYPE is margin : Call MARGIN COMMAND_TYPE is new page : Call PAGE COMMAND_TYPE is double space : Call DOUBLE_SPACE COMMAND_TYPE is single space : Call SINGLE_SPACE COMMAND_TYPE is break : Call BREAK COMMAND_TYPE is anything else: Call ERROR ENDCASE

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.15 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Example of Pseudocode (continued) Intermediate pseudocode PARAGRAPH: 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 PracticePage 7.16 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Example of Pseudocode (continued) Regrouped FIRST: 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 PracticePage 7.17 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Example of Pseudocode (continued) Final pseudocode INITIAL: 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 eject PARAGRAPH: 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 PracticePage 7.18 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Consumer 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 PracticePage 7.19 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Producer 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 PracticePage 7.20 © 2006 Pearson/Prentice Hall 7.2 Programming Guidelines Sidebar 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 PracticePage 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 PracticePage 7.22 © 2006 Pearson/Prentice Hall 7.3 Documentation Information 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 PracticePage 7.23 © 2006 Pearson/Prentice Hall 8.1 Software Faults and Failures Why 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 PracticePage 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 PracticePage 7.25 © 2006 Pearson/Prentice Hall 8.1 Software Faults and Failures Types 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 PracticePage 7.26 © 2006 Pearson/Prentice Hall 8.1 Software Faults and Failures Typical 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 PracticePage 7.27 © 2006 Pearson/Prentice Hall 8.1 Software Faults and Failures Orthogonal Defect Classification Fault TypeMeaning FunctionFault that affects capability, end-user interface, product interface with hardware architecture, or global data structure InterfaceFault in interacting with other component or drivers via calls, macros, control blocks, or parameter lists CheckingFault in program logic that fails to validate data and values properly before they are used AssignmentFault in data structure or code block initialization Timing/serializationFault in timing of shared and real-time resources Build/package/mergeFault that occurs because of problems in repositories, management changes, or version control DocumentationFault that affects publications and maintenance notes AlgorithmFault involving efficiency or correctness of algorithm or data structure but not design

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.28 © 2006 Pearson/Prentice Hall 8.1 Software Faults and Failures Sidebar 8.1 Hewlett-Packard’s Fault Classification

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.29 © 2006 Pearson/Prentice Hall 8.1 Software Faults and Failures Sidebar 8.1 Faults for one Hewlett-Packard Division

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.30 © 2006 Pearson/Prentice Hall 8.2 Testing Issues Testing 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 PracticePage 7.31 © 2006 Pearson/Prentice Hall 8.2 Testing Issues Testing Organization Illustrated

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.32 © 2006 Pearson/Prentice Hall 8.2 Testing Issues Attitude 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 PracticePage 7.33 © 2006 Pearson/Prentice Hall 8.2 Testing Issues Who Performs the Test? Independent test team –avoid conflict –improve objectivity –allow testing and coding concurrently

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.34 © 2006 Pearson/Prentice Hall 8.2 Testing Issues Views 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 PracticePage 7.35 © 2006 Pearson/Prentice Hall 8.2 Testing Issues White Box Advantage –free of internal structure’s constraints Disadvantage –not possible to run a complete test

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.36 © 2006 Pearson/Prentice Hall 8.2 Testing Issues Clear Box Example of logic structure

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.37 © 2006 Pearson/Prentice Hall 8.2 Testing Issues Sidebar 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 PracticePage 7.38 © 2006 Pearson/Prentice Hall 8.2 Testing Issues Factors 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 PracticePage 7.39 © 2006 Pearson/Prentice Hall 8.3 Unit Testing Code Review Code walkthrough Code inspection

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.40 © 2006 Pearson/Prentice Hall 8.3 Unit Testing Typical Inspection Preparation and Meeting Times Development ArtifactPreparation TimeMeeting Time Requirement Document25 pages per hour12 pages per hour Functional specification45 pages per hour15 pager per hour Logic specification50 pages per hour20 pages per hour Source code150 lines of code per hour 75 lines of code per hour User documents35 pages per hour20 pages per hour

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.41 © 2006 Pearson/Prentice Hall 8.3 Unit Testing Fault Discovery Rate Discovery Activity Faults Found per Thousand Lines of Code Requirements review2.5 Design Review5.0 Code inspection10.0 Integration test3.0 Acceptance test2.0

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.42 © 2006 Pearson/Prentice Hall 8.3 Unit Testing Sidebar 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 PracticePage 7.43 © 2006 Pearson/Prentice Hall 8.3 Unit Testing Proving Code Correct Formal proof techniques Symbolic execution Automated theorem-proving

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.44 © 2006 Pearson/Prentice Hall 8.3 Unit Testing Proving Code Correct: An Illustration

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.45 © 2006 Pearson/Prentice Hall 8.3 Unit Testing Testing versus Proving Proving: hypothetical environment Testing: actual operating environment

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.46 © 2006 Pearson/Prentice Hall 8.3 Unit Testing Steps in Choosing Test Cases Determining test objectives Selecting test cases Defining a test

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.47 © 2006 Pearson/Prentice Hall 8.3 Unit Testing Test 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 PracticePage 7.48 © 2006 Pearson/Prentice Hall 8.3 Unit Testing Relative Strengths of Test Strategies

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.49 © 2006 Pearson/Prentice Hall 8.3 Unit Testing Comparing Techniques Fault discovery Percentages by Fault Origin Discovery TechniquesRequirementsDesignCodingDocumentation Prototyping Requirements review Design Review Code inspection Unit testing15200

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.50 © 2006 Pearson/Prentice Hall 8.3 Unit Testing Comparing Techniques (continued) Effectiveness of fault-discovery techniques Requirements FaultsDesign FaultsCode Faults Documentation Faults ReviewsFairExcellent Good PrototypesGoodFair Not applicable TestingPoor GoodFair Correctness ProofsPoor Fair

Pfleeger and Atlee, Software Engineering: Theory and PracticePage 7.51 © 2006 Pearson/Prentice Hall 8.3 Unit Testing Sidebar 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 PracticePage 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 PracticePage 7.53 © 2006 Pearson/Prentice Hall 11.4 Measuring Maintenance Characteristics External 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 PracticePage 7.54 © 2006 Pearson/Prentice Hall 11.4 Measuring Maintenance Characteristics External 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 PracticePage 7.55 © 2006 Pearson/Prentice Hall 11.4 Measuring Maintenance Characteristics Internal 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 PracticePage 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 position numdigits = 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 PracticePage 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 PracticePage 7.58 © 2006 Pearson/Prentice Hall 11.4 Measuring Maintenance Characteristics Other 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 c 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 PracticePage 7.59 © 2006 Pearson/Prentice Hall 11.4 Measuring Maintenance Characteristics Sidebar 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 PracticePage 7.60 © 2006 Pearson/Prentice Hall 11.4 Measuring Maintenance Characteristics Sidebar 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