CS 696: Advanced OO
Spring Semester, 1997
Doc 6, Metrics
To Lecture Notes Index
San Diego State University -- This page last updated Feb 20, 1997
Contents of Doc 6, Metrics
| References | slide # 1 |
| Motivation for Metrics | slide # 2 |
| Weyuker's List of Desirable
Properties of Metrics | slide # 3 |
| Chidamber and Kemerer Metric
Suite | slide # 6 |
| ...Weighted Methods Per Class | slide # 6 |
| ...Depth of Inheritance Tree | slide # 7 |
| ...Number of Children | slide # 7 |
| ...Lack of Cohesion in Methods | slide # 8 |
| ...Coupling between Objects | slide # 11 |
| ...Response for a Class | slide # 12 |
| Other Coupling Metrics | slide # 13 |
| ...Message-Passing Coupling (MPC) | slide # 13 |
| ...Violations of Demeter | slide # 14 |
| Metric Properties Satisfied | slide # 15 |
| Metrics Case Study | slide # 16 |
References
Used
Chidamber and Kemerer, 1991, "Towards a Metric Suite for Object-Oriented Design", Proc.
OOPSLA'91, Sigplan Notices, 26(11), 197-211
Henderson-Sellers, 1996, Object-Oriented Metrics: Measures of Complexity, Prentice Hall
Cited
Chidamber and Kemerer, 1993, "A Metric Suite for Object-Oriented Design", Working Paper
#249, MIT Center for Information Systems, Cambridge, MA, 40 pp
Chidamber and Kemerer, 1994, "A Metric Suite for Object-Oriented Design", IEEE
Transactions on Software Engineering, 20(6), 476-493
Conte, Dunsmore, Shen, 1986, Software Engineering Metrics and Models,
Benjamin/Cummings
Haynes and Menzies, 1994, The Effect of Class Coupling on Class Size in Smalltalk Systems,
in TOOLS15, eds. Mingins and Meyer
Henderson-Sellers, 1995, A BOOK of Object-Oriented Knowledge, 2nd Ed. , Prentice Hall
Li and Henry, 1993, Object-Oriented Metrics that Predict Maintainability, J. Sys. Software, 23,
11-122
Lorenz and Kidd, 1994, Object-Oriented Software Metrics, Prentice Hall
Sharble and Cohen, 1993, The Object-Oriented Brewery: A Comparison of Two Object
Oriented Development Methods, ACM SIGSOFT Software Engineering Notes, 18(2), 60-73
Weyuker, 1988, "Evaluating Software Complexity Measures," IEEE Transactions on Software
Engineering, 14(9), September, 1357-1365
Motivation for Metrics
- Estimate the cost & schedule of future projects
- Evaluate the productivity impacts of new tools and
techniques
- Establish productivity trends over time
- Improve software quality
- Forecast future staffing needs
- Anticipate and reduce future maintenance needs
Weyuker's List of Desirable Properties of Metrics
Let m be a metric for program entities
Property 1: Non-coarseness
- Given any program entity P there is another program
entity Q such that:
- m(P) != m(Q)
Property 2: Non-uniqueness
- There exists program entities P and Q such that:
- m(P) = m(Q)
Property 3: Permutation is significant
- There exists program entities P and Q such that Q is a re
arrangement of P and m(P) != m(Q)
Property 4: Implementation is important
- There exists program entities P and Q such that they
produce the same output given the same input and
- m(P) != m(Q)
Weyuker's List of Desirable Properties of Metrics
Property 5: Monotonicity
- For all program entities P and Q we must have:
- m(P) <= m(P + Q)
- m(Q) <= m(P + Q)
- where P+Q is the concatenation of P and Q
Property 6: Non-equivalence of interaction
- There exists program entities P, Q, and R such that:
- m(P) = m( Q) and m(P+R) != m(Q+R)
- where P+R is the concatenation of P and R
Property 7: Interaction increase complexity
- There exists program entities P and Q such that:
- m(P) + m(Q) <= m(P+Q)
Property 8: Finiteness
- Given a nonnegative number c, there are only a finite
- number of program entities such that m( P ) = c
Weyuker's List of Desirable Properties of Metrics
Property 9: Rose principle
- If P is a renaming of Q, then m(P) = m(Q)
Chidamber and Kemerer Metric Suite
Metric 1: (WMC)
Weighted Methods Per Class
Let C be a class, with methods M1 ,
M2 ,... , Mk
Let c1 , c2 ,... , ck be
the complexity of the methods
"complexity is deliberately not defined more specifically here
in order to allow for the most general application of this metric"
In the paper cj = 1 for all j
Then
- WMC = c1 + c2 + ... +
ck
Viewpoints: (of Chidamber and Kemerer)
The number of methods and complexity of methods is an
indicator of how much time and effort is required to
develop and maintain the object
The larger the number of methods in an object, the
greater the potential impact on the children
Objects with large number of methods are likely to be
more application specific, limiting the possible reuse
Metric 2: (DIT)
Depth of Inheritance Tree
The depth of inheritance of the class is the DIT metric for the
class
Viewpoints:
- The deeper a class is in the hierarchy, the more methods
it is likely to inherit, making it more complex
- Deeper trees indicate greater design complexity
Metric 3: (NOC)
Number of Children
NOC = the number of immediate sub-classes of the class
Viewpoints:
- Depth is generally better than breadth in class hierarchy,
since it promotes reuse of methods through inheritance
- Not all classes should have the same number of sub
classes. Classes higher up in the hierarchy should have
more sub-classes then those lower down.
- NOC gives an idea of the potential influence a class has on
the design. Classes with large number of children may
require more testing.
Metric 4: (LCOM)
Lack of Cohesion in Methods
The definition of this metric was ill defined in the original
paper
Chidamber and Kemerer (1993) provided a new definition
Henderson-Sellers (1995) proposed different definition, which
is easier to compute
Chidamber and Kemerer (1993) LCOM
Let C be a class, with methods M1 ,
M2 ,... , Mm
Let Ik = the set of instance variables used by
method Mk
Let P = { (Ik, Ij ) | Ik
and Ij do not intersect }
Let Q = { (Ik, Ij ) | Ik
and Ij do intersect }
If | P | > | Q | then
- LCOM = | P | - | Q |
else
- LCOM = 0
Henderson-Sellers LCOM*
Consider a set of m methods, M1 ,
M2 ,... , Mm
The methods access a data attributes, A1 ,
A2 ,... , Aa
Let a(Mk) = number of attributes accessed by
method Mk
Let m(Ak) = number of methods that access data
Ak
Then
If each method accesses all attributes then
m(Ak) = m so
If each method accesses only one attribute and a different
attribute then we have:
So at maximum cohesion LCOM* = 0
At Henderson-Sellers' "minimum cohesion" LCOM* = 1
Coupling Metrics
Metric 5: (CBO)
Coupling between Objects
CBO for a class is a count of the number of related couples
with other classes.
Chidamber & Kemerers(1994) modified the definition of CBO
The Fan-out of a class, C, is the number of other classes that
are referenced in C
A reference to another class, A, is an reference to a method or
a data member of class A
In the fan-out of a class multiple accesses are counted as one
access
The Fan-in of a class, C, is the number of other classes that
reference in C
Definition
- CBO = fan-out of a class
High fan-outs represent class coupling to other classes/objects
and thus are undesirable
High fan-ins represent good object designs and high level of
reuse
It does not seem possible to maintain high fan-in and low fan
outs across the entire system
Metric 6: (RFC)
Response for a Class
RFC = NLM + NRM
where:
- NLM = number of local methods in the class
- NRM = number of remote methods called by methods in
the class
- A given remote method is counted only once
Viewpoints
- The larger the number of methods:
- testing and debugging becomes more complicated
- the greater the complexity of the object
- the harder it is to understand
Other Coupling Metrics
Message-Passing Coupling (MPC)
Proposed separately by Li & Henry(1993), and Lorenz & Kidd
(1994)
MPC = number of send statements defined in a class
| fan-out (CBO) | count one if two classes interact |
| RFC | count one per unique service accessed |
| MPC | count one per method call |
VOD
Violations of Demeter
Number of times the Law of Demeter is violated
Haynes and Menzies(1994) Equation
Studied several Smalltalk system and detected a possible
linear relation between class coupling and class size
They claim:
SLOC = lines of source code
- "A line of code is any line of program text that is not a
comment or blank line, regardless of the number of
statements or fragments of statements on the line.
- This specifically includes all lines containing program
headers, declarations, and executable and non-executable
statements."
From Conte et al. (1986) via Henderson-Sellers (1995)
Metric Properties Satisfied
by Chidamber & Kemerer's Metric Suite
| Metric | P1 | P2 | P3 | P4 | P5 | P6 | P7 |
| WMC | Yes | Yes | No | Yes | Yes | Yes | No |
| DIT | Yes | Yes | No | Yes | No | Yes | No |
| NOC | Yes | Yes | No | Yes | Yes | Yes | No |
| RFC | Yes | Yes | No | Yes | Yes | No | No |
| LCOM | Yes | Yes | No | Yes | Yes | Yes | No |
| CBO | Yes | Yes | No | Yes | Yes | Yes | No |
| Property 1: Non-coarseness |
| Property 2: Non-uniqueness |
| Property 3: Permutation is significant |
| Property 4: Implementation is important |
| Property 5: Monotonicity |
| Property 6: Non-equivalence of interaction |
| Property 7: Interaction increase complexity |
| WMC | Weighted Methods Per Class |
| DIT | Depth of Inheritance Tree |
| NOC | Number of Children |
| RFC | Response for a Class |
| LCOM | Lack of Cohesion in Methods |
| CBO | Coupling between Objects
|
Metrics Case Study
Sharble & Cohen (1993)
Two OO designs of same system were studied
One design was produced using responsibility-driven
methodology (Wirfs-Brock)
One design was produced using data-driven methodology
(Coad, Booch, Rumbugh)
9 Metrics were measured
Data
Driven | Respon.
Drive | | |
| 130 | 71 | WMC | Weighted Methods Per Class |
| 21 | 19 | DIT | Depth of Inheritance Tree |
| 19 | 13 | NOC | Number of Children |
| 42 | 20 | CBO | Coupling between Objects |
| 293 | 127 | RFC | Response for a Class |
| 64 | 21 | LCOM | Lack of Cohesion in Methods |
| 64 | 44 | VOD | Violations of Demeter |
| 0 | 0 | NOT | Number of Tramps |
| 40 | 0 | WAC | Weighted Attributes per Class |
NOT = total number of extraneous parameters in signature of
methods
Metrics Case Study
Data
