Implementation Phase

Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach Berrached::CS3320::Ch13

Implementation Phase • Aim: to translate the detailed design into code. • Programming-in-the-many: Product is implemented by a team of programmers • All working at same time on different components of the product. Berrached::CS3320::Ch13

Outline • Choice of programming language • Good Programming Languages • Testing Techniques Berrached::CS3320::Ch13

Choice of a Programming Language • Language usually specified in contract by client. • If not, choice should be based on: • cost-benefit analysis • COBOL: for data processing • Object-Oriented Languages • 4th generation Languages: e.g. SQL, DB2, Oracle, PowerBuilder • Higher-level: each line equivalent to 30-50 line of machine code • ease in programming, but slower • mostly for data processing tasks Berrached::CS3320::Ch13

Good Programming Practice • Use of consistent and meaningful variable name • Meaningful to future maintenance programmer • Consistent to aid maintenance programmer Example: • Module contains a variable to represent maximum, minimum, and average temperatures: • MaxFr: too ambiguous • frequencyMax, minFreq: not consistent • maxFrequency, minFreqency, avgFrequency • Companies usually have their own internal conventions. Berrached::CS3320::Ch13

Good Programming Practice CNTD • Self-documenting code: code can be understood without the aid of comments: • very rare • Key question: • Can module be understood easily and unambiguously by • SQA team • maintenance programmers • all others who have to read code • E.g. xCooddinateOfPositionOfRobotArm • abbreviate to xCoord Berrached::CS3320::Ch13

Prologue Comments • Mandatory at top of every single module • module name • brief description of what module does • programmer’s name • date module was coded • date it was approved and by whom • Module parameters • Variable name, alphabetically and their uses • files accessed and updated by module • module I/O • error handling capabilities • name of file of test data • list if modifications made, when, by whom, approved by whom • known faults, if any Berrached::CS3320::Ch13

Other Comments • In-line comments needed to explain code Fallacy: • Comment are only needed when code is written in non-obvious way, or makes use of subtle aspect of language • If that is the case, re-code in clearer way • Code layout for increased readability • use indentation • use blank lines Berrached::CS3320::Ch13

Nested if Statements Berrached::CS3320::Ch13

Nested if Statements CNTD Berrached::CS3320::Ch13

Nested if Statements CNTD • Combination of if-if and if-else-if statements usually difficult to read • simplify by making use of fact that if-if combination if <condition1> if <condition2> is frequentlyequivalent to single condition if <condition1> && <condition2> • Note: if programming language supports “short-circuit” evaluation of logical operations, they can always be equivalent. Berrached::CS3320::Ch13

Nested if Statements CNTD Some basic rules: • if conditions are interdependent, use if-else statement instead of a sequence of if statements • Don’t forget the final else part • Avoid if-if and if-else-if statements by combining conditions using the && operator • Rule of thumb: if-statements nested to depth greater than three should be avoided as poor programming practice Berrached::CS3320::Ch13

Programming Standards • Standards are difficult to enforce • Can be both blessing and curse • setting limits of module size • Examples of good standards • documentation standards • program layout • naming standards • “ nesting of if-statements should not exceed a depth of 3, except with prior approval from team leader” • “Use of goto should be avoided. However, with prior approval from team leader, a forward goto many be used for error handling” Berrached::CS3320::Ch13

Module Testing • After preliminary testing by programmer, each module is handed over to SQA group for formal testing. • How to methodically test a module? Berrached::CS3320::Ch13

Module Test Case Selection • Worst way- random testing • Need systematic way to construct test cases Two extremes to testing: 1. Test to specifications (also called black-box, data driven, functional, or input/output driven testing). • Ignore code. Use spec. document to select test cases 2. Test to code (also called glass-box, logic-driven, structured, or path-oriented testing) • Ignore specifications. Use code to select test cases Berrached::CS3320::Ch13

Feasibility Of Testing To Specs Example: • Specification for a data processing product include 5 commissions and 7 types of discount • 35 test cases • Suppose specs include 20 factors, each taking 4 values • 420 or over 1 trillion test cases • if each takes 30 seconds to run, running all test cases takes > 1 million years!! • Combinatorial explosion makes exhaustive testing to specification unfeasible. Berrached::CS3320::Ch13

Feasibility Of Testing To Code Each path through module must be executed at least once • Combinatorial explosion: flow chart has over 1012 different paths Berrached::CS3320::Ch13

Feasibility Of Testing To Code CNTD • Can exercise every path without detecting every fault Example: if ( (x+y+z)/ 3 ==x) cout <<“x, y, z are equal”<<endl; else cout <<“x, y, z are not equal”<<endl; Test case 1: x=1, y=2, z=3 Test case 2: x=2, y=2, z=2 Berrached::CS3320::Ch13

Feasibility Of Testing To Code CNTD • Path can be tested only if it is present Example 1: if (d==0) zeroDivisionRoutine(); else x = n/d; Example 2: x = n/d; Berrached::CS3320::Ch13

Coping With The Combinatorial Explosion • Exhaustive testing (to specs or to code) is not feasible Art of testing: • Small, manageable set of test cases to • maximize chances of detecting faults, while • minimizing chances of wasting test cases • Every test case must be designed to detect previously undetected faults • Methods that will high-light as many faults as possible • First black-box test cases • Then glass-box methods Berrached::CS3320::Ch13

Black-Box Module Testing • Equivalence Testing Example: • Specs for DBMS state that product must handle any number of records between 1 and 16,000 • if system works for any one test in range [1..16,000], then it will probably work for any test case in range • range [1..16,00] constitutes one equivalence class • Any one member is as good a test case as any other member of the class. Berrached::CS3320::Ch13

Equivalence Testing CNTD • Range [1..16,000] defines three difference equivalence classes: • Equivalence Class 1: Fewer than 1 record • Equivalence Class 2: between 1 and 16,000 records • Equivalence Class 3: More than 16,000 records • Boundary Analysis: • Selecting test case on or just to one side of boundary of equivalence class increases probability of detecting faults Berrached::CS3320::Ch13

Equivalence Testing & Boundary Analysis • DBMS Example: • Test Case 1: 0 record: (member of class 1 & adjacent to boundary value) • Test Case 2: 1 record (Boundary value) • Test Case 3: 2 records (Adjacent to boundary value) • Test Case 4: 8349 records (member of class 2) • Test Case 5: 15,999 recs (Adjacent to Boundary value) • Test Case 6: 16,000 recs (Boundary value) • Test case 7: 16,001 recs (Adjacent to Boundary value) Berrached::CS3320::Ch13

Black-Box Testing Methods CNTD Functional Testing • Test for each item of functionality • Example: • module authenticates user login • Module computes some arithmetic function • Weakness: • Functionality may span several modules Berrached::CS3320::Ch13

Glass-Box Module Testing Methods Statement Coverage • Series of test cases to check every statement • CASE tools needed to keep track • Weakness: • Branch statements if (S > 1 && t = 0) // && should have been || X= 8; Test case: S=2, t=0 Both statements can be executed without fault showing up Berrached::CS3320::Ch13

Glass-Box Module Testing Methods Branch Coverage • Series of tests check all branches. • CASE tool needed Path Coverage • Most powerful form of Glass box testing • Weakness: with loops, number of paths very large , can be infinite • Want weaker condition than all paths but which shows up more coverage than branch coverage Berrached::CS3320::Ch13

Glass-Box Module Testing Methods Path Coverage (continued) Linear code sequences: • Identify set points L from which control flow may jump, including entry and exit points • e.g. • Restrict test cases to paths that begin and end with elements of L • Uncovers many faults without testing every path. Berrached::CS3320::Ch13

Glass-Box Testing Methods CNTD All-definition-use- path coverage • Each occurrence of variable, zz say, is labeled either as • definition of variable: e.g. zz=1 or read(zz) • or use of variable: e.g. Y = zz + 1 or if (zz > 0) …. • Identify all paths from definition of variable to use of that variable • can be done by automated tool • Set up a test case for each such path. Berrached::CS3320::Ch13

Glass-Box Testing Methods CNTD All-definition-use- path coverage CNTD • Disadvantages: • upper bound on number of paths is 2d, where d is number of branches • In practice • Actual number of paths is proportional to d Berrached::CS3320::Ch13

Glass-Box Testing Methods CNTD Infeasible Code • May not be possible to test specific statement because there is an infeasible path ("dead code") if ( k < 2) { if ( k > 3) { // dead code …. • Dead code is frequently an indication of a fault Berrached::CS3320::Ch13

Glass-Box Testing -- Quality Assurance • Module m1 is more "complex" than module "m2" => m1 is likely to have more faults • Software complexity • highlights modules most likely to have faults • Unreasonably high complexity => re-design and re-code Berrached::CS3320::Ch13

Measures of Complexity Lines of code • simplest measure of complexity • underlying assumption: constant probability p that a line of code contains fault. • Number of faults is related to size of product as a whole Berrached::CS3320::Ch13

Measures of Complexity Cyclomatic Complexity • Essentially number of decisions (branches) in module • Easy to compute • Good measure of faults Berrached::CS3320::Ch13

Measures of Complexity Software Science Metrics • Based on number of operators and operands in module • Problem with cyclomatic and software science • Being challenged theoretically and experimentally • The both have high correlation wit LOC • Several experiments have shown that LOC is as good predictor of fault rate as any other metrics • Note: LOC is poor metric of productivity Berrached::CS3320::Ch13

Code Walkthrough and Inspections • Done by SQA team • group of 4-6 members • "walkthrough" code • detect faults (no correction) • Leads to rapid and thorough fault detection • Experiments have shown that they are at least as effective in detecting faults as black-box and glass-box testing techniques. Berrached::CS3320::Ch13

CLEANROOM TESTING • Incorporates several SW development techniques: • incremental process model • Formal techniques for specification and design • non-execution based testing: walkthroughs and inspections • A module is not compiled until it has passed inspection Berrached::CS3320::Ch13

CLEANROOM TESTING • 1820 lines of FoxBASE (U.S. Naval Underwater Systems Center, 1992) • 18 faults detected by "functional verification" • based correctness proving techniques • 19 faults detected in walkthroughs before compilation • NO compilation errors • NO execution errors Berrached::CS3320::Ch13

Berrached::CS3320::Ch13

Implementation Phase