Technical Metrics for OO Systems

1. Technical Metrics for OO Systems

2. Complexity • Complex systems are • hard to understand • hard to change • hard to reuse Cyclomatic complexity Cohesion and coupling “Software science” 428-1

3. Cyclomatic Complexity • A measure of logical complexity • Tells how many tests are needed to execute every statement of program • Number of branches (if, while, for) + 1 428-1

4. Cyclomatic Complexity def processInterest() : for acc in account_list : if hasInterest(acc) : acc.balance = acc.balance + acc.balance * acc.interest 428-1

5. Cyclomatic Complexity def addInterest for if acc.balance = ... done 428-1

6. Cyclomatic complexity • Number of predicates + 1 • Number of edges - number of nodes + 2 • Number of regions of the flow graph 428-1

7. Testing view • Cyclomatic complexity is the number of independent paths through the procedure • Gives an upper bound on the number of tests necessary to execute every edge of control graph 428-1

8. Metrics view • McCabe found that modules with a cyclomatic complexity greater than 10 were hard to test and error prone. • Look for procedures with high cyclomatic complexity and rewrite them, focus testing on them, or focus reviewing on them. 428-1

9. Coupling and cohesion • Number and complexity of shared variables • Functions in a module should share variables • Functions in different modules should not • Number and complexity of parameters • Number of functions/modules that are called • Number of functions/modules that call me 428-1

10. Dhama’s Coupling Metric Module coupling = 1 / (number of input parameters + number of output parameters + number of global variables used + number of modules called + number of modules calling) .5 is low coupling, .001 is high coupling. 428-1

11. Martin’s Coupling Metric • Ca: Afferent coupling: the number of classes outside this module that depend on classes inside this module • Ce: Efferent coupling: the number of classes inside this module that depend on classes outside this module • Instability = Ce / (Ca + Ce) 428-1

12. A: Abstractness (# abstract classes in module / # classes in module) (0,1) Abstractness (1,0) Instability 428-1

13. Technical Metrics • A Metrics Suite for Object Oriented Design, Shyam R. Chidamber and Chris F. Kemerer IEEE Transactions on Software Engineering, June 1994, pp 476-493 • Chapter 4 of Hamlet and Maybe, especially 4.3 428-1

14. Weighted Methods Per Class • Depth of Inheritance Tree • Number of Children • Coupling between Object Classes • Response for a Class • Lack of Cohesion in Methods 428-1

15. Weighted Methods Per Class WMC for a class is the sum of the complexities of the methods in the class. Possible method complexities • 1 (number of methods) • Lines of code • Number of method calls • Cyclomatic complexity 428-1

16. Weighted Methods per Class • The number of methods and the complexity of methods predicts the time and effort required to develop and maintain a class • The larger the number of methods in a class, the greater the potential impact on children • Classes with large numbers of methods are more likely to be application specific and less reusable 428-1

17. Weighted Methods Per Class 428-1

18. Depth of Inheritance Tree • Depth of inheritance tree • Maximum length from a class to the root of the tree 428-1

19. Depth of Inheritance Tree • The deeper a class is in the hierarchy, the more methods it inherits and so it is harder to predict its behavior • The deeper a class is in the hierarchy, the more methods it reuses • Deeper trees are more complex 428-1

20. Depth of Inheritance Tree 428-1

21. Number of Children • Number of immediate subclasses • More children is more reuse • A class might have a lot of children because of misuse of subclassing • A class with a large number of children is probably very important and needs a lot of testing 428-1

22. Number of Children • Almost all classes have 0 children • Only a handful of classes will have more than five children 428-1

23. Coupling Between Object Classes • Number of other classes to which a class is coupled. • Class A is coupled to class B if there is a method in A that invokes a method of B. • Want to be coupled only with abstract classes high in the inheritance hierarchy. 428-1

24. Coupling between object classes • Coupling makes designs hard to change. • Coupling makes classes hard to reuse. • Coupling is a measure of how hard a class is to test. 428-1

25. Coupling between object classes • C++ project: median 0, max 84. • Smalltalk project: median 9, max 234 428-1

26. Response for a class • Number of methods in a class or called by a class • The response set of a class is a set of methods that can potentially be executed in response to a message received by an object of that class. 428-1

27. Response for a class • If a large number of methods can be invoked in response to a message, testing becomes more complicated • The more methods that can be invoked from a class, the greater the complexity of the class. 428-1

28. Response for a class • C++: median 6, max 120 • Smalltalk: median 29, max 422 428-1

29. Lack of Cohesion in Methods • Number of pairs of methods that don’t share instance variables - number of pairs of methods that share instance variables • Cohesiveness of methods is a sign of encapsulation. • Lack of cohesion implies classes should be split 428-1

30. Lack of cohesion of methods • C++: median 0, max 200 • Smalltalk: median 2, max 17 • Smalltalk system had only a few zero 428-1

31. What is best? • WMC or list of long methods? • DIT or list of classes with depth over 6? • NOC or list of classes with more than 6 children? • CBO or list of classes with high coupling? 428-1

32. Questions? • Who looks at these figures? • What is done with the results? • How do you get the figures? 428-1

33. Next time • Software Measurement Guidebook • http://swg.jpl.nasa.gov/resources/NASA-GB-001-94.pdf • Pages 1-20 and 30-49 428-1