Technical Metrics for OO Systems

Transcription

1 Technical Metrics for OO Systems 1 Last time: Metrics Non-technical: about process Technical: about product Size, complexity (cyclomatic, function points) How to use metrics Prioritize work Measure programmer productivity Makes plans based on predicted effort This time: OO systems and testing

2 Coupling and cohesion Coupling - dependencies among modules Cohesion dependencies within modules Dependencies Call methods, refer to class, share variable Coupling - bad Cohesion - good 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

3 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 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)

4 Abstractness Abstractness = # abstract classes in module / # classes in module Abstractness (0,1) Instability (1,0) Technical OO Metrics Paper (you don t have to read) A Metrics Suite for Object Oriented Design, Shyam R. Chidamber and Chris F. Kemerer IEEE Transactions on Software Engineering, June 1994, pp

5 List of metrics Weighted Methods Per Class (WMC) Depth of Inheritance Tree (DIT) Number of Children (NOC) Coupling between Object Classes (CBO) Response for a Class (RFC) Lack of Cohesion in Methods (LCOM) 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

6 Weighted Methods Per Class The number of methods and the complexity of methods predict 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 Weighted Methods Per Class Number of classes A WMC Metric value

7 Depth of Inheritance Tree Depth of inheritance tree Maximum length from a class to the root of the tree 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

8 Depth of Inheritance Tree Number of classes Series1 DIT metric value 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

9 Number of Children Almost all classes have 0 children Only a handful of classes will have more than five children 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

10 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 Coupling Between Object Classes C++ project: median 0, max 84 Smalltalk project: median 9, max

11 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 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

12 Response for a class C++: median 6, max 120 Smalltalk: median 29, max Lack of Cohesion in Methods # of pairs of methods that don t share instance variables minus # of pairs of methods that share instance variables Cohesiveness of methods is a sign of encapsulation Lack of cohesion implies classes should be split

13 Lack of cohesion of methods C++: median 0, max 200 Smalltalk: median 2, max 17 Smalltalk system had only a few zero 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?

14 Questions? Who looks at these figures? What is done with the results? How do you get the figures? Metrics and Quality Software measurement is a means to an end, not an end in itself 28 14

15 The Goal of Measurement What is causing poor quality? Where are we spending all our time on software development? How accurate are our estimates? What is the most cost-effective way to improve our quality? Software Quality Correctness Reliability Efficiency Integrity Usability Maintainability Flexibility Testability Portability Reusability Interoperability

16 FURPS Functionality Usability Reliability Performance Supportability ISO 9126 adds Portability Verification and Validation Correctness Does the system meet the documented requirements? Functionality Does the system meet the actual requirements of the users? Are the written requirements the actual requirements of the users?

17 Metrics Metrics for correctness # tests for each requirements # tests that pass # outstanding bugs Metrics for functionality Ratings on a survey Average time to complete task on a prototype More Metrics Portability Number of platforms supporting system Number of platform-dependent modules Reliability A number of precise technical metrics Supportability How easy to install/modify/fix

18 Improving quality Where do errors come from? Which module? Which developer? Which practice/language/tool? Improving productivity Do we need to spend more/less time testing? More: we are spending a lot of time fixing bugs that customers report Less: we are spending a lot of time testing and only finding trivial bugs that don t bother customers

19 Quality assurance plan What are your goals for quality? Define metrics How will you tell whether you meet them? Define process for taking measurements What will you do if you don t meet them? Conclusion Know why you are measuring Productivity measure cost, results Quality track defects Technical metrics are less important, usually delegated to design reviews or when other metrics indicate problems

20 Next time: Midterm review Old midterms are posted online Our midterm is on Thu, Oct 22 Makeup midterm in special cases Darko directly