0% found this document useful (0 votes)
29 views

Lecture 40

The document discusses various techniques for verifying code, including unit testing, code inspections, static analysis, and formal verification. It also covers metrics for measuring code size like lines of code and Halstead's volume, as well as complexity metrics like cyclomatic complexity, which measures the number of decisions in code. Unit testing involves writing test cases to test modules, while code inspections involve teams examining code against checklists to find defects. Static analysis tools can find bugs without executing code. (110 words)

Uploaded by

vipanmittal
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
29 views

Lecture 40

The document discusses various techniques for verifying code, including unit testing, code inspections, static analysis, and formal verification. It also covers metrics for measuring code size like lines of code and Halstead's volume, as well as complexity metrics like cyclomatic complexity, which measures the number of decisions in code. Unit testing involves writing test cases to test modules, while code inspections involve teams examining code against checklists to find defects. Static analysis tools can find bugs without executing code. (110 words)

Uploaded by

vipanmittal
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

Verification

• Code has to be verified before it can be used by


others
• Here we discuss only verification of code written by a
programmer (system verification is discussed in
testing)
• There are many different techniques; key ones – unit
testing, inspection, and program checking
• Program checking can also be used at the system
level

1
Code Inspections
• The inspection process can be applied to code with
great effectiveness
• Inspections held when code has compiled and a few
tests passed
• Usually static tools are also applied before
inspections
• Inspection team focuses on finding defects and bugs
in code
• Checklists are generally used to focus the attention
on defects

2
Code Inspections…
• Some items in a checklist
– Do all pointers point to something
– Are all vars and pointers initialized
– Are all array indexes within bounds
– Will all loops always terminate
– Any security flaws
– Is input data being checked
– Obvious inefficiencies

3
Code inspections…
• Are very effective and are widely used in industry
(many require all critical code segments to be
inspected)
• Is also expensive; for non critical code one person
inspection may be used
• Code reading is self inspection
– A structured approach where code is read inside-out
– Is also very effective

4
Unit Testing
• Is testing, except the focus is the module a
programmer has written
• Most often UT is done by the programmer himself
• UT will require test cases for the module – will
discuss in testing
• UT also requires drivers to be written to actually
execute the module with test cases
• Besides the driver and test cases, tester needs to
know the correct outcome as well

5
Unit Testing…
• If incremental coding is being done, then complete
UT needs to be automated
• Otherwise, repeatedly doing UT will not be possible
• There are tools available to help
– They provide the drivers
– Test cases are programmed, with outcomes being checked
in them
– I.e. UT is a script that returns pass/fail

6
Unit Testing…
• There are frameworks like Junit that can be used for
testing Java classes
• Each test case is a method which ends with some
assertions
• If assertions hold, the test case pass, otherwise it
fails
• Complete execution and evaluation of the test cases
is automated
• For enhancing the test script, additional test cases
can be added easily

7
Static Analysis
• These are tools to analyze program sources and
check for problems
• Static analyzer cannot find all bugs and often cannot
be sure of the bugs it finds as it is not executing the
code
• So there is noise in their output
• Many different tools available that use different
techniques
• They are effective in finding bugs like memory leak,
dead code, dangling pointers,..

8
Formal Verification
• These approaches aim to prove the correctness of
the program
• I.e. the program implements its specifications
• Require formal specifications for the program, as well
as rules to interpret the program
• Was an active area of research; scalability issues
became the bottleneck
• Used mostly in very critical situations, as an
additional approach

9
Metrics for Size
• LOC or KLOC
– non-commented, non blank lines is a standard
definition
– Generally only new or modified lines are counted
– Used heavily, though has shortcomings

10
Metrics for Size…
• Halstead’s Volume
– n1: no of distinct operators
– n2: no of distinct operands
– N1: total occurrences of operators
– N2: Total occurrences of operands
– Vocabulary, n = n1 + n2
– Length, N = N1 + N2
– Volume, V = N log2(n)

11
Metrics for Complexity
• Cyclomatic Complexity is perhaps the most widely
used measure
• Represents the program by its control flow graph
with e edges, n nodes, and p parts
• Cyclomatic complexity is defined as V(G) = e-n+p
• This is same as the number of linearly independent
cycles in the graph
• And is same as the number of decisions
(conditionals) in the program plus one

12
Cyclomatic complexity example…
1. {
2. i=1;
3. while (i<=n) {
4. J=1;
5. while(j <= i) {
6. If (A[i]<A[j])
7. Swap(A[i], A[j]);
8. J=j+1;}
9. i = i+1;}
10. }

13
Example…

14
Example…
• V(G) = 10-7+1 = 4
• Independent circuits
1. bceb
2. bcdeb
3. abfa
4. aga
• No of decisions is 3 (while, while, if);
complexity is 3+1 = 4

15
Complexity metrics…
• Halsteads
– N2/n2 is avg times an operand is used
– If vars are changed frequently, this is larger
– Ease of reading or writing is defined as
D = (n1*N2)/(2*n2)
• There are others, e.g. live variables, knot
count..

16
Complexity metrics…
• The basic use of these is to reduce the
complexity of modules
• One suggestion is that cyclomatic complexity
should be less than 10
• Another use is to identify high complexity
modules and then see if their logic can be
simplified

17
Summary
• Goal of coding is to convert a design into easy to read
code with few bugs
• Good programming practices like structured
programming, information hiding, etc can help
• There are many methods to verify the code of a
module – unit testing and inspections are most
commonly used
• Size and complexity measures are defined and often
used; common ones are LOC and cyclomatic
complexity

18

You might also like