Object Oriented Metrics
XP project group 30.08. – 08.10.2004
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 nAA ,...,1
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
2
21 *2 N
D
)(log* 212 NV
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 – 20 complex program, tolerable risk
21 – 50 complex program, high risk
>50 impossible 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
NOM
NORMDITSIX
*
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
classes # total
essuperclass#U
essuperclass#
s #subclasseS
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
NOFNOM
NOMAFCLCOM Ca
*1)(2
1)(*
NOM
NOMAFNOMCLCOM Ca
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
)(Im
)()(cMm
mVGcWMC
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:
CECA
CEI
categoryin classes# total
categoryin classesabstract #A
(1) dsp, 30.11.05, 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