Object Oriented Metrics XP project group – Saskia Schmitz

object oriented software metrics 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 Metrics: general properties objective normative amenable to statistical analysis comparable repeatable consistent reliable useful valid

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 EffortE = 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) V(G) Risk 1 – 10 easy program, low risk 11 – 20complex program, tolerable risk 21 – 50complex program, high risk >50impossible to test, extremely high risk

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, , corrected. Wrong defintion in the original better. Better defintion in later ones.

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

object oriented software metrics 28 GQM Approach 1. List major Goals of measurement 2. From each goal derive the Questions that must be answered to determine if the goals are met. 3. 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