Implementation Phase

1
Implementation Phase

• Chapter 13
• Classical Object-Oriented Software Engineering
  by Stephen R. Schach

2
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.

3
Outline

• Choice of programming language
• Good Programming Languages
• Testing Techniques

4
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

5
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.

6
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

7
Prologue Comments

• Mandatory at top of every single module
• module name
• brief description of what module does
• programmers 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

8
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

9
Nested if Statements
10
Nested if Statements CNTD
11
Nested if Statements CNTD
12
Nested if Statements CNTD
13
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 ltcondition1gt
• if ltcondition2gt
• is frequently equivalent to single condition
• if ltcondition1gt ltcondition2gt
• Note if programming language supports
  short-circuit evaluation of logical operations,
  they can always be equivalent.

14
Nested if Statements CNTD

• Some basic rules
• if conditions are interdependent, use if-else
  statement instead of a sequence of if statements
• Dont 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

15
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

16
Module Testing

• After preliminary testing by programmer, each
  module is handed over to SQA group for formal
  testing.
• How to methodically test a module?

17
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

18
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 gt 1 million years!!
• Combinatorial explosion makes exhaustive testing
  to specification unfeasible.

19
Feasibility Of Testing To Code

• Each path through module must be executed at
  least once
• Combinatorial explosion flow chart has over 1012
  different paths

20
Feasibility Of Testing To Code CNTD

• Can exercise every path without detecting every
  fault
• Example
• if ( (xyz)/ 3 x)
• cout ltltx, y, z are equalltltendl
• else
• cout ltltx, y, z are not equalltltendl
• Test case 1 x1, y2, z3
• Test case 2 x2, y2, z2

21
Feasibility Of Testing To Code CNTD

• Path can be tested only if it is present
• Example 1
• if (d0)
• zeroDivisionRoutine()
• else
• x n/d
• Example 2
• x n/d

22
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

23
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.

24
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

25
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)

26
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

27
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 gt 1 t 0) // should have been
  
• X 8
• Test case S2, t0
• Both statements can be executed without fault
  showing up

28
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

29
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.

30
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. zz1 or read(zz)
• or use of variable
• e.g. Y zz 1 or if (zz gt 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.

31
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

32
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 lt 2)
• if ( k gt 3)
• // dead code .
• Dead code is frequently an indication of a fault

33
Glass-Box Testing -- Quality Assurance

• Module m1 is more "complex" than module "m2"
• gt m1 is likely to have more faults
• Software complexity
• highlights modules most likely to have faults
• Unreasonably high complexity
• gt re-design and re-code

34
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

35
Measures of Complexity

• Cyclomatic Complexity
• Essentially number of decisions (branches) in
  module
• Easy to compute
• Good measure of faults

36
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

37
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.

38
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

39
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

40
(No Transcript)
41
(No Transcript)
42
(No Transcript)
43
(No Transcript)
44
(No Transcript)
45
(No Transcript)
46
(No Transcript)
47
(No Transcript)
48
(No Transcript)
49
(No Transcript)
50
(No Transcript)
51
(No Transcript)
52
Approaches to Real Time Testing

• Non-execution based
• Structure analysis techniques
• deadlock detection methods
• formal methods for modeling system behavior that
  can take synchronization into consideration
• e.g. PetriNets

53
Approaches to Real Time Testing (CNTD)

• Execution Based
• Systematic testing
• all possible ordering of inputs
• often impossible (combinatorial explosion)
• Simulation is the most important testing method
  for real-time systems