Object Oriented Metrics

1
Object Oriented Metrics

• 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

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

4
Metrics general properties

• objective
• normative
• amenable to statistical analysis
• comparable
• repeatable

• consistent
• reliable
• useful
• valid

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

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?

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

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

9
Non-OO Metrics

• Size Metrics
• Syntactical Structure Metrics
• Logic Structure Metrics
• Composite 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

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

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

13
Cyclomatic Complexity

• control flow graph G
• e edges
• n vertices
• p connected components
• V(G) e n 2p

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 20 complex program, tolerable risk
21 50 complex program, high risk
gt50 impossible to test, extremely high risk
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)

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

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)
  50sinv(2.4C)
• high MI ? good maintainability
• MI lt 30 ? code restructuring necessary

18
OO Metrics

• Measuring on class level
• Coupling
• Inheritance
• Cohesion
• Size
• Structural Complexity
• Measuring on package / higher level

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

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)

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

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

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 gt1 there is a field in C that is never
  used by a method of C

24
Size Metrics

• Number of Fields (NOF)
• Number of Methods (NOM)
• variations consider only private / public /
  inherited / declared /

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

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.
27
Design Quality Metric

• well balanced categories are on main sequence
• Distance D
• D A I 1
• ? restructure any category not near main sequence

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.

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

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

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

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

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