Measuring Complexity

Transcription

1 Measuring Complexity

2 outline why should we measure the complexity of a software system? what might we want to measure? complexity of the source code within a code module between code modules complexity of the underlying algorithm 2

3 what does software complexity mean? (at least) two questions can be asked about complexity in software how complex is the program code? is it addressing a complicated problem? how good is the program structure code complexity how complex is our algorithm compared with others which do the same job? how complicated is it? how fast does it run? can consider this independently of quality of design or code! algorithmic complexity 3

4 why measure software complexity? code complexity: (said to) help estimate how much effort will be needed to test software how fault-prone code it is how difficult it will be to change the system in the future algorithmic complexity: helps us work out how long it takes for the program to run compared with other ways of calculating the same thing 4

5 code complexity

6 code complexity introduced how well-structured are our code modules? how complicated is flow of logic in a module? if a module does more than one thing how well do they fit together?... need to look at individual program texts how well-structured is our system? higher-level (design) concerns, specifically coupling between modules... need to look at how modules fit together note that measuring these for OO systems will be different from non-oo since a class is different from a module 6

7 measuring code complexity complexity of code structure in module is an internal measure of code can measure complexity of control flow and execution paths within a module e.g. McCabe s Cyclomatic Complexity measure how well the parts of a module fit together cohesion information and data flow between modules: how well modules are separated from each other e.g. coupling, some OO metrics how complex the underlying data structures are 7

8 McCabe s cyclomatic complexity measure one example of metrics that aim to measure how complicated control flow in a program is measures complexity of control flow within a module... by counting how many linearly independent paths there are through the program intended to measure for a program effort needed to test how many paths do we need to test to ensure each code line is executed at least once? maintainability how easy is it to modify the program's control paths? now sometimes seen as measure of underlying complexity of program 8

9 code structure as flowgraph can examine complexity of a program by tracing all possible paths through the code for any procedural code, can build a flowgraph a directed graph in which two nodes, the start node and the stop node, obey special properties: the stopnode has out-degree zero, and every node lies on some path from the start node to the stop node. (F+P:282) what paths can the execution of a program follow? depends on control structures in the code: sequence conditions (if-then-else) looping (repetition, recursion) 9

10 let s build a flowgraph from the following useless piece of code* I ve written: a = 10; b = 23; if (a < b) return 0; c = b a; return c; * one of many 10

11 examples of flowgraph fragments a = 1; line1 b = 23; c = b a; line2 line3 11

12 examples of flowgraph fragments if (A) then { } if if (A) then { } else { } if true true false end end 12

13 examples of flowgraph fragments: note two different types of loop while (A) do { } repeat { } until (A) while repeat loop endwhile until done 13

14 from flowgraph to McCabe s Cyclomatic Complexity measure v(f) v(f) (sometimes called v(g) ) is function of number of arcs and nodes in program's flowgraph given flowgraph F with e arcs and n nodes: v(f) = e n + 2 can be measured by hand or automatically note that v(f) for a sequence of X lines shown individually as arcs is (X 1) X + 2 = 1 i.e. all sequences have v(f) of 1 good way of remembering the formula!... and adding one line to a sequence has no effect on v(f) v(f) also = number of binary decisions in a program

15 how to compute Cyclomatic Complexity: a worked example int a, b, c; a = 1; b = 2; if (a > b) {c = 23;} else {c = 25;} while (b < c) { b = b + 1; } System.print.outline( answer = + b); return(0); 15

16 what can we use McCabe s cyclomatic complexity for? is it related to anything else that is useful? correlation to LOCs, some with defect rates what is a good number? McCabe recommends a maximum of 10 what can we use it for? (claims) managing code complexity estimating effort for programming, testing, enhancements or bug fixing based on numbers of independent paths through code 16

17 critiques of Cyclomatic Complexity Fenton and Pfleeger (p.293): objective and useful when counting linearly independent paths, but it is not at all clear that it paints a complete or accurate picture of program complexity. Martin Shepperd, Software Engineering Journal, Mar based on poor theoretical foundations, inadequate model of software development from empirical evidence, does not provide developer with useful engineering approximation for large class of software, actually a proxy for lines of code and in many cases doesn t work as well as it! 17 another critique: Michael Jackson (JSP) via Grant Rule actually measures structuredness of code not complexity

18 information/data flow complexity how complex is our program in terms of how well-separated its parts are? cohesion: how well does each module fit together? coupling: how well separated are the modules metrics for object-oriented systems the Chidamber and Kemmerer suite 18

19 cohesion how many different things is a code unit trying to do? the fewer, the better! classes of cohesion functional: does only one (well-defined) thing sequential: does more than one thing in sequence communicational: does different things to same data procedural: does more than one part of one procedure temporal: does things that happen at same time logical: does things of the same sort coincidental: does things that are not related module can have more than one type of cohesion e.g. communicational + temporal: two otherwise unrelated functions linked by their happening at the same time to the same data 19

20 can we measure cohesion? F+P: no obvious measurement procedure but we can write down what each module does in one sentence look for relevant content like initialise -> temporal generate output, update files -> logical first, then, after -> sequential more than one verb -> sequential, communicational combine into system-level score ( cohesion ratio ): cohesion ratio = number of modules with functional cohesion / total no. of modules 20

21 coupling how much does one code unit depend on others? why is it useful to know? the more one depends on another the greater the ripple effect the more difficult it is to change one without having to change the other the more likely it is that a fault in one will cause the other to misbehave so low coupling = good and high coupling = bad 21

22 coupling one set of types of coupling (best to worst) R 0 : none none R 1 : data pass simple data as parameters R 2 : stamp pass data structures as parameters R 3 : control pass value that controls receiving module s action R 4 : common share the same data R 5 : content one module relies on specific internal features of another typically need data coupling for most programming languages to work 22

23 measuring coupling an informal statement of quality data- or stamp-coupled modules are loosely coupled common- or content-coupled modules are strongly coupled F+P p.310: valid (measurement theory) ordinal scale measure of coupling between two modules x and y is c (x, y) = i + (n / n+1) where i = number of worst coupling relationship n is number of interconnections between x and y... this is ordinal scale because distance between numbers is meaningless! and global coupling of system is median of this across all x, y pairs 23