Object Oriented Metrics

1. ObjectOrientedMetrics XP project group 30.08. – 08.10.2004 Saskia Schmitz

2. Contents • Why Metrics? • Properties of Metrics • Measurement, Validity, Usage • Non OO Metrics • OO Metrics • GQM Paradigm • Metric Suites • Visualization • Conclusion object oriented software metrics

3. Why Metrics? • goal: good software design low costs • small testing effort • low maintenance costs • many reusable fragments • definition of measurable criterions to distinguish „good“ from „bad“ design • use metrics to indicate source of „badness“ object oriented software metrics

4. objective normative amenable to statistical analysis comparable repeatable consistent reliable useful valid Metrics: general properties object oriented software metrics

5. Software metrics: properties • robust • prescriptive • computable (automatically + deterministically) • obtainable early in lifecycle • dimensionless or expressed in some unit system • nonsize metrics should be size independent • language independent object oriented software metrics

6. Validity • theoretical soundness / „meaning“ of a measure: • how well does the measure cover the attribute? • how well are current and future situations estimated? • how general is the measure? object oriented software metrics

7. Measurement • direct measurement: one independent attribute • indirect measurement: involves measurement of several attributes • Assessment measurement: current measure of an attribute • Predictive measurement: predicts future value of attribute A based on mathematical model relating A to current measure of attributes object oriented software metrics

8. Usage • measured values… • do not hold „immediate“ information • do not imply a obvious recipe of what should be changed • threshold values („alarm“) • measured attributes should show values within certain ranges • empirically determined object oriented software metrics

9. Non-OO Metrics • Size Metrics • Syntactical Structure Metrics • Logic Structure Metrics • Composite Metrics object oriented software metrics

10. Lines of Code (LOC) • Advantages • easy to compute • applicable to all kinds of programs • Disadvantages • different possible counting methods • language and programmer dependent • no implications about maintainability or complexity object oriented software metrics

11. Halstead Metrics • η¹ = number of unique operators • η² = number of unique operands • N¹ = total number of operators • N² = total number of operands • Difficulty • Volume • Effort E = V * D object oriented software metrics

12. Halstead Metrics (2) • Advantages • easy to compute (scanner) • applicable for all languages • empirical studies: good measure for complexity • Disadvantages • only lexical / textual complexity • no namesspaces / visibility / … • language dependend object oriented software metrics

13. Cyclomatic Complexity • control flow graph G • e = # edges • n = # vertices • p = # connected components • V(G) = e – n + 2p object oriented software metrics

14. Cyclomatic Complexity (2) • rule of thumb: • begin restructuring your code with the component with highest V(G) object oriented software metrics

15. Cyclomatic Complexity (3) • Advantages • easy to compute (parser) • empirical studies: good correlation between cyclomatic complexity and understandability • Disdvantages • only control flow • no data flow • may be inappropriate for OO programs (trivial functions) object oriented software metrics

16. Composite Metrics • Problem • All introduced metrics are limited to one specific aspect in their ability to predict / measure software quality • Solution: • Combine these metrics to a new metric object oriented software metrics

17. Maintainability Index (MI) • Combination of presented Metrics • V = average Halstead volume per module • V(G) = average cyclomatic complexity per module • LOC = average LOC per module • C = average percentage of comment lines MI = 171 – 5.2ln(V) – 0.23V(G) – 16.2ln(LOC) + 50sin√(2.4C) • high MI  good maintainability • MI < 30  code restructuring necessary object oriented software metrics

18. OO Metrics • Measuring on class level • Coupling • Inheritance • Cohesion • Size • Structural Complexity • Measuring on package / higher level object oriented software metrics

19. Measures of Coupling • Fan-Out / Coupling between Objects (CBO) • CBO(c) = #{class d | a method of class c calls a method or references a field of class d } • low CBO is desired  independent classes • Responce for Class (RFC) • RFC(c) = # methods of c (NLM) + # methods of other classes invoked by c (NRM, recursively) • measure of potential inter-class communication object oriented software metrics

20. Measures of Coupling (2) • Message Passing Coupling • # send statements in a defined class (= number of procedure calls originating from a method in the class and going to other classes) object oriented software metrics

21. Measuring Inheritance • Depth of Inheritance Tree (DIT) • high DIT has been found to increase faults • Number of Overridden Methods (NORM) • Specialization Index (SIX) • high value: specialisation sub-classing • low value: implementation sub-classing • Number of Children (NOC) • only immediate subclasses are counted • Number of Descendants (NOD) • all subclasses are counted object oriented software metrics

22. Measuring Inheritance (2) • Reuse Ratio • value near 1: linear hierarchy  poor design • value near 0: shallow depth • Specialization Ratio • value near 1: poor design • high value: good capture of abstractions in superclasses object oriented software metrics

23. Cohesion Metrics • Lack of Cohesion of Methods (LCOM) • NOMAF = number of methods that access a field • LCOM*: • value of 0: perfect cohesion • value of 1: complete lack of cohesion  split class • value >1: there is a field in C that is never used by a method of C object oriented software metrics

24. Size Metrics • Number of Fields (NOF) • Number of Methods (NOM) • variations: consider only private / public / inherited / declared / … object oriented software metrics

25. Structural Metrics • Weighted Methods per Class (WMC) • good predictor of how much time / effort is required to implement / maintain the class • variant: use size of method as weight object oriented software metrics

26. Metrics on higher levels • Identify groups of highly cohesive classes (=„categories“) and measure: • Afferent Couplings CA: #classes outside category that depend on classes within category • Efferent Couplings CE: #classes outside category on which a class inside the category depend(1) • Instability I: • Abstractness A: (1) dsp, 30.11.05, corrected. Wrong defintion in the original better. Better defintion in later ones. object oriented software metrics

27. well balanced categories are on „main sequence“ Distance D: D = | A + I – 1 |  restructure any category not near main sequence Design Quality Metric object oriented software metrics

28. GQM Approach • List major Goals of measurement • From each goal derive the Questions that must be answered to determine if the goals are met. • Decide what Metrics must be collected in order to answer the questions. object oriented software metrics

29. Metric Suites: Chidamber & Kemerer • includes WMC, DIT, NOC, CBO, RFC, LCOM • Advantages • OO Design is considered • NOC and RFC give some ideas as to budgeting for testing a class • Drawbacks • no good size and effort estimation • focus on design phase, not planning phase object oriented software metrics

30. Metrics Suite: MOOD • Attribute Hiding Factor (AHF) • ideally 100 % • Method Hiding Factor (MHF) • low: insufficient abstraction • high: little functionality • Attribute Inheritance Factor (AIF) • Method Inheritance Factor (MIF) • AIF and MIF should be within acceptable range, neither too high nor too low object oriented software metrics

31. MOOD • Polymorphism Factor (PF) • should be within acceptable range • Coupling Factor (CF) • high CF values should be avoided • MOOD conclusion • designed to measure overall quality of an OO project • not appropriate for projects relying mostly on forms and standard modules object oriented software metrics

32. Visualize Metrics Results • Class Blueprint • Elements of a class are graphically represented as boxes • Their shape, size and color reflect semantical information. • The two dimensions of the box are given by two metrics object oriented software metrics

33. Conclusion • Remaining problems: • metrics may not be valid in specific project • we need unambiguous interpretation for software metrics (individual result / result sets) to evaluate design • we need a transformation from design rules  measure, which would immediately lead to • recovery of design info • localization of design problems object oriented software metrics