object oriented metrics

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


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“


Metrics: general properties

objective normative amenable to

statistical analysis comparable repeatable

consistent reliable useful valid


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


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?


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


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


Non-OO Metrics

Size Metrics Syntactical Structure Metrics Logic Structure Metrics Composite Metrics


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


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


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


Cyclomatic Complexity

control flow graph G e = # edges n = # vertices p = # connected

components V(G) = e – n + 2p


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


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)


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


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


OO Metrics

Measuring on class level Coupling Inheritance Cohesion Size Structural Complexity

Measuring on package / higher level


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


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)


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

*


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


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


Size Metrics

Number of Fields (NOF) Number of Methods (NOM)

variations: consider only private / public / inherited / declared / …


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


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.


Design Quality Metric

well balanced categories are on „main sequence“

Distance D:

D = | A + I – 1 |

restructure any category not near main sequence


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.


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


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


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


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


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 metrics

Documents

good measure

bad designuse metrics

good correlation

total number of operatorsn

number of unique operandsn

number of unique operators

oo programs trivial

future value of attribute