Page 188 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes 8( 1) : n>m ==> TRUE
14( 7) : r!=0 ==> TRUE
14( 7) : r!=0 ==> TRUE
14( 7) : r!=0 ==> FALSE
This shows the number of times each edge is executed along each path. (See Table 9.1)

Table 9.1: Matrix of Edge Incidence for Basis Paths B1-B3 and Other Path P

Path/
Edge 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
B1 1 0 1 0 0 0 1 1 0 1 0 0 0 1 1
B2 1 1 0 1 1 1 1 1 0 1 0 0 0 1 1
B3 1 0 1 0 0 0 1 1 1 1 1 1 1 1 1
P 1 1 0 1 1 1 1 1 2 1 2 2 2 1 1

One interesting property of foundation sets is that each edge of a flow graph is traversed through
at least one path in every foundation set. Put another way, executing a foundation set of paths
will always cover every control branch in the module. This income that to cover all edges never
requires more than the cyclomatic complexity number of paths. However, executing a basis set
just to cover all edges is overkill. Covering all edges can usually be accomplished with fewer
paths. In this example, paths B2 and B3 cover all edges without path B1. The relationship between
basis paths and edge coverage is discussed.
Note that apart from forming a basis together, there is nothing special about paths B1 through
B3. Path P in combination with any two of the paths B1 through B3 would also form a basis.
The fact that there are many sets of basis paths through most programs is important for testing,
since it means it is possible to have considerable freedom in selecting a basis set of paths to test.

Show the relationship of the attribute for metric value?

9.1.3 Limiting Cyclamate Complexity to 10

There are many reasons to limit cyclomatic complexity. Overly complex modules are more prone
to error, are harder to understand, are harder to test, and are harder to modify. Deliberately
limiting complexity at all stages of software development, for example as a departmental
standard, helps avoid the pitfalls associated with high complexity software. Many organizations
have successfully implemented complexity limits as part of their software programs. The
precise number to use as a limit, however, remains somewhat controversial. The original limit
of 10 as proposed by McCabe has significant supporting evidence, but limits as high as 15
have been used successfully as well. Limits over 10 should be reserved for projects that have
several operational advantages over typical projects, for example experienced staff, formal
design, a modern programming language, structured programming, code walkthroughs, and
a comprehensive test plan. In other words, an organization can pick a complexity limit greater
than 10, but only if it is sure it knows what it is doing and is willing to devote the additional
testing effort required by more complex modules. Somewhat more interesting than the exact
complexity limit are the exceptions to that limit.

182 LOVELY PROFESSIONAL UNIVERSITY