Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Metrics (Part II). Product Metrics  Product metrics are generally concerned with the structure of the source code (example LOC).  Product metrics.

Similar presentations


Presentation on theme: "Software Metrics (Part II). Product Metrics  Product metrics are generally concerned with the structure of the source code (example LOC).  Product metrics."— Presentation transcript:

1 Software Metrics (Part II)

2 Product Metrics  Product metrics are generally concerned with the structure of the source code (example LOC).  Product metrics are metrics that can be calculated independent of how the document is produced.  They can be calculated for other documents too. For example the number of words in a requirements specification.

3 McCabe’s Cyclomatic Number  McCabes cyclomatic number (also called McCabe’s complexity measure), after LOC, is one of the most commonly used software metrics.  It was introduced in 1976.  It is based on graph theory’s cyclomatic number. Thomas McCabe Sr. http://reengineer.org/stevens/previous.htm

4 A Little Graph Theory  A graph G is planar if it can be drawn on a plane so that none of its edges cross. Planar or not?

5 Strongly Connected Graphs  A directed graph G is strongly connected if thee is a path from any node to any other node. Strongly Connected Not Strongly Connected

6 Weakly Connected Graphs  A graph G is weakly connected, if every node can reach every other node and you don’t care which way the directed edges point. Weakly Connected Not Weakly Connected

7 Strongly Connected Components  A strongly connected component of a graph G is a maximal subgraph of G that is strongly connected. What are the strongly connected component?

8 Euler’s Theorem e = the number of edges n = the number of nodes r = the number of regions formed by the graph Leonhard Euler (1707-1783) proved that for a planar graph G: where 2 = n – e + r

9 Euler’s Theorem  n =  e =  r = n – e + r = 5 6 3 2 Consider the graph below

10 McCabe’s Cyclomatic Number  2 = n – e + r can be rewritten to find the number of regions in a planar graph knowing the number of nodes and edges: r = e – n + 2  McCabe used the number of regions formed by a control flow graph as his software metric and named it “McCabe’s Complexity Measure”

11 McCabe’s Cyclomatic Number  McCabe generalized the number for graphs that contained more than one strongly connected component as: Cyclomatic number (C) = e – n + 2p where p = number of strongly connected components

12 McCabe’s Cyclomatic Number  Find McCabe’s cyclomatic number for the following control flow graph:

13  Calculate McCabe’s cyclomatic number for the following code: /* main routine */ x := 1; while (x = 1) { x := 2; test ( x, 1 ); x := 3; } // End while while (x = 1) { x := 4; x := 5; test ( x, 2 ); } //End while While (x = 1) { x := 6; if (x = 7)x := 8; else test ( x, 3 ); } // End while } // End main

14 Threshold  McCabe analyzed large projects and found that when the cyclomatic number for a module exceeds 10, there is a history of many more errors and difficulties in maintenance.

15 Halstead Measure (1977)  Maurice Halstead did his work in the late 1960’s and early 1970’s.  He was a pioneer in software metrics (as was McCabe).  His goal was to find out what contributed to software complexity.

16 Halstead Metrics  A program is considered to be a collection of tokens.  Tokens are either operators or operands.  Operands were tokens that had a value (typically variables or constants).  Everything else is an operator (commas parenthesis, arithmetic operators, i.e. all the C++ operators)

17 Halstead Metrics  All tokens that occur as pairs, triples, etc. count as one token (example: parenthesis).  Halstead did not count declarations, input or output statements, or comments do not count as tokens.  Most organizations currently count all parts of a program.

18 Halstead Metrics  The count of unique operators is ή 1 (eta one) and the count of unique operands is ή 2 (eta two). z = 0; While x > 0 z = z + y; x = x – 1 End-while; Print (z); Consider the code below: Operators: =While; +->Print ( ) Operands: ή 1 = 8 z0xy1 ή 2 = 5

19 Halstead Metrics  The length (N) of the program is the total count of operators and operands. For example, for: z = 0; While x > 0 z = z + y; x = x – 1 End-while; Print (z); Number of operands = 11 Number of operators = 14 N = 25

20 Halstead Metrics  The Estimate of Length (est N or N_hat) is defined as: Est N = ή 1 * log 2 ή 1 + ή 2 * log 2 ή 2 Est N = ή 1 * log 2 ή 1 + ή 2 * log 2 ή 2  This formula can be used to estimate the total number of tokens, based on the number of different tokens.  The author of your book has found that if N and Est N differ by more than 30%, then it may not be reasonable to apply other software science measures.  Then again, it may be!

21 Halstead Metrics  Halstead’s measure: Est N = ή 1 * log 2 ή 1 + ή 2 * log 2 ή is based on Claude Shannon’s formula for entropy (the amount of information in something) in information theory. H = n * log S where S is the number of possible symbols, and n the number of symbols in a transmission April 30, 1916 – February 24, 2001

22 Halstead Metrics  For the code: z = 0; While x > 0 z = z + y; x = x – 1 End-while; Print (z); ή 1 = 8 ή 2 = 5 Est N = 8 log 2 8 + 5 log 2 5 Est N = 8 * 3 + 5 * 2.32 Est N = 35.6 N = 25 difference = 10.6 / 35.6 = 29.8%

23 Volume  The volume of a program is related to the number of bits needed to encode the program  The volume of a program is defined as: V = N * log 2 (ή 1 + ή 2 ) For our sample code: V = 25 * log 2 (8 + 5) = 25 *3.7 = 25 *3.7 = 92.5 = 92.5

24 Potential Volume  The potential volume is the minimal size of a solution solved in any language.  Halstead defined the potential volume as: V* = (2 + ή 2 *) log 2 (ή 2 *) Where ή 2 * is the minimum set of operands needed to implement the algorithm in any language.

25 Implementation Level  The implementation level is defined as: L = Potential Volume / Volume = V* / V  This relates to how close the current implementation is to the minimal implementation.

26 Henry–Kafura Information Flow  Sallie Henry and Dennis Kafurn developed a software metric to measure the intermodule complexity of code.  For a module, a count is made of all the information flows into the module (fan-ins) and all the information flows out of the module (fan-outs).

27 Henry–Kafura Information Flow  The information flows include: Parameters Global variables Inputs and outputs HK = weight * (out * in) 2 Where the weight is determined by the size of the module and the HK’s are summed over all modules.  Their formula is (for a single module)

28 Advantages: Henry–Kafura Information Flow  They look at higher level complexity, while McCabe looks at lower level complexity. McCabe’s complexity can only be applied when you have detail source code or pseudo-code.  Henry and Kafura’s complexity can be applied during design phase and also at scoping phase if proper information flow block diagrams are drawn

29 Disadvantages: Henry–Kafura Information Flow  If fan-in or fan-out is zero the whole complexity will become zero.  Just imagine you are using Henry and Kafura’s complexity and fan-in or fan-out is zero the quotation is zero Dollars.

30 Disadvantages: Henry–Kafura Information Flow  The length factor is a completely different attribute.  Multiplication of the factor with complexity has been questioned by experts.  Arthimetic calculations can be performed on measurements of similar type.  Example adding 1 litre + 10 volts will yield nothing sensible

31 The End


Download ppt "Software Metrics (Part II). Product Metrics  Product metrics are generally concerned with the structure of the source code (example LOC).  Product metrics."

Similar presentations


Ads by Google