HD28
.M414
no.
53^5
-
^1
MAY BE
LAW
COPYRIGHT
BY
PROTECTED
(TITLE 17 U.S. CODE)
NOTICE. THIS MATERIAL
TOWARDS A METRICS SUITE
FOR OBJECT ORIENTED DESIGN
Shyam Chidamber
Chris
F.
Kemerer
June 1991
CISR
Sloan
WP
WP
No. 226
No. 3323-91 -MSA
©1991 MIT
Accepted for publication in the sixth annual ACM conference on Object Oriented
Programming, Systems, Languages and Applications (OOPSLA). October 1991.
for Information Systems Research
Sloan School of Management
Massachusetts Institute of Technology
Center
TOWARDS
A METRICS SUITE FOR OBJECT ORIENTED DESIGN
Abstract
This paper presents theoretical woric that builds a suite of metrics for object-oriented design.
In particular, these metrics are based
upon measurement theory and
are also
informed by the
insights of experienced object-oriented software developers. In evaluating these metrics
against a standard set of
suggest
some ways
in
criteria,
they are found to both (a) perform relatively well, and (b)
which Lhe object oriented approach
may
differ in terms of desirable or
necessary design features from more traditional approaches.
In order for object-oriented software production to fulfill
development and maintenance from
the current 'craft'
closely resembling conventional engineering,
it
its
promise
in
moving software
environment into something more
will require metrics of the process to aid the
software management, project planning and project evaluation functions. While software
metrics are a generally desirable feature in any software environment, they are of special
imponance
in the object-oriented
approach, since
it
represents a non-trivial technological
change for the organization.
The metrics presented
in this
paper are the
first
steps in a project
aimed
at
measuring and
evaluating the use of object oriented design principles in organizations.
Accepted for publication in the sixth annual ACM conference on Object Oriented Programming, Systems,
Languages and Applications (OOPSLA), October 1991.
I.
INTRODUCTION
In order for objea-oriented sofrware production to
development and maintenance from the current
resembling conventional engineering,
fulfill its
'craft'
in
moving software
environment into something more closely
measures or metrics of the process. While
will require
it
promise
software metrics are a generally desirable feanire in the software management functions of project
planning and project evaluation, they are of special importance with a
new
technology such as the
object-oriented approach.
This
is
due
to the significant
need
to train current
and new software engineers
object-oriented principles. This paper presents theoretical
object-oriented design
(OOD).
work
in generally accepted
that builds a suite of metrics for
In particular, these metrics are based
upon measurement theory and
are informed by the insights of experienced object-oriented software developers.
metrics are evaluated against a widely-accepted
list
The proposed
of seven software metric evaluation
criteria,
and
the formal results of this evaluation are presented.
Development and
benefits.
validation of software metrics
In general, techniques that provide
software system can be used to aid management
is
measures of the size and of the complexity of a
in:
-
estimating the cost and schedule of future projects,
-
evaluating the productivity impacts of
-
establishing productivity trends over time,
-
improving software
-
forecasting future staffing needs, and
-
anticipating
More
new
expected to provide a number of practical
tools
and techniques,
quality,
and reducing future maintenance requirements.
specifically, given the relative
newness of the
00 approach, metrics oriented towards 00 can
aid in evaluating the degree of object orientation of an implementation as a learning tool for staff
members who
are
new
to the
approach. In addition, they
criteria in setting design standards for
This paper
is
may
also eventually be useful objective
an organization.
organized as follows.
Section
n
presents a very brief
summary of
the need for
research in this area. Section EQ describes the theory underlying the approach taken. Section IV
presents the proposed metrics, and Section
criteria
[Weyuker, 1988].
metrics, and
Section
V presents Weyuker's list of software metric evaluation
VI contains
some concluding remarks
the results of the evaluation of the proposed
are presented in Section
VIL
RESEARCH PROBLEM
II.
There are two types of
criticisms that
can be applied to current software metrics. The
first
category
are those criticisms that are leveled at conventional software metrics as they are applied to
conventional,
non-00
software design and development. These metrics are generally criticized as
being without solid theoretical bases
^
and failing to display what might be termed normal
predictable behavior [Weyuker, 1988].
The second
category
around modeling the
is
more
world
real
traditional approaches that
Given the fundamentally
specific to
00 design
terms of
in
its
and development. The
objects,
which
emphasize a function-oriented view
different notions inherent in these
that software metrics developed with traditional
methods
is in stark
00 approach centers
contrast to older,
that separated data
two views,
in inind
do not
it
is
more
and procedures.
not surprising to find
readily lend themselves to
notions such as classes, inheritance, encapsulation and message passing. Therefore, given that
current software metrics are subject to
key
to
GO concepts,
it
seems appropriate
measure unique aspects of
the
general criticism and are easily seen as not supporting
to develop a set, or suite of
metrics especially designed
shortcomings of existing metrics and the need for new metrics
00. Some proposals
are set out
suggested rather than theoretically driven [1988].
by Morris, although they are empirically
Pfleeger also suggests the need for
measures, and uses counts of objects and methods to develop and
OO
new
00 approach.
Some early work has recognized the
especially designed for
some
test
new
a cost estimation model for
development [Pfleeger, 1989; Pfleeger and Palmer, 1990]. Moreau and Dominick suggest
three metrics for
00 graphical information systems, but do not provide formal, testable definitions
[1989]. In contrast, Lieberherr and his colleagues present a well-articiilated, formal approach in
documenting
the
Law
Demeter™ [1988] The Demeter system
of
represents a formal attempt at
defining the rules of correct object oriented programming style, building on concepts of coupling
and cohesion
that are
used
in traditional
Given the extant software metrics
programming.
literature, the
approach taken here
is to
develop theoretically-
driven metrics that can be shown to offer desirable properties, and then choose the most promising
candidates for future empirical study. This paper
is
an
initial presentation
of six candidate metrics
specifically developed for measuring elements contributing to the size and complexity of object-
oriented design. Since object design
metrics directly address
this task.
is
The
considered to be a unique aspect of
OOD,
the proposed
metrics are constructed with a firm basis in theoretical
concepts in measurement, while capturing empirical notions of software complexity.
'For example, see [Vessey and Weber, 1984] and [Kearney,
et al., 1986].
III.
THEORY BASED METRICS FOR OOD
Booch (1986) defines
object oriented design to be the process of identifying objects and their
attributes, identifying operations required
objects.
3)
Design of classes involves three
communication between
implement the
attributes
objects.
on each object and establishing interfaces between
steps: 1) definition of objects, 2) attributes
Methods design involves defining procedures which
and operations suffered by objects. Class design
level of abstraction than the traditional data/procedures
design).
It is
& Hechi,
the task of class design that
1990].
et al. [1989],
The reader
Pamas,
is
makes
is
approach (which
therefore at a higher
is
closer to
methods
OOD different than data/procedure design [Taylor
referred to works
et al. [1986],
of objects and
by Deutsch,
et al. [1983],
Meyer
[1988], Page,
Seidewitz and Stark [1986] and others for an introduction to
the fundamental concepts and terminology of object-oriented design.
Figure
1
shows
the fundamental elements of object oriented design as outlined
by Booch [1986].
(jDmmunication
Among Objects
Rgurcl: Elements ofObject Oriented Design
Measurement theory base
A design
can be viewed as a relational system, consisting of object elements, empirical relations
and binary operations
Notationally: design
that
P=
can be performed on the object elements.
(A, Rj... Rn,0i...0in)
where
A is a set of object elements
Rl...Rn are empirical relations on object elements
A
(e.g,
bigger than, smaller than, etc)
Oi...Oryi are binary
A
useful
way
operanons
concatenation)
(e.g.,
to conceptualize empirical relations
consider the measurement of complexity.
which object
objects, as to
notion of a viewT^oint
retrieval
systems and
was
is
is
set
of object elements
in this
context
is
to
designer has ideas about the complexity of different
more complex than
another. This idea
is
defined as a viewpoint.
The
originally introduced to describe evaluation measures for information
applied here to capture designer views [Chemiavsky, 1971].
relation is the
embodiment of a viewpoint.
A
is
viewpoint
A
on a
a binary relation .> defined on the set P.
For P,
P',
P" e set
P
,
An
empirical
the following
axioms must hold:
P
.>
P
P
.>
P or P
(reflexivity)
.>
P
=> P.>
P.>
P',
i.e.,
a viewpoint
To
P'.> P"
(completeness)
P"
(transitivity)
must be of weak order [Zuse,
1987].
be able to measure something about a object design, the empirical relational system as defined
above needs
to be transformed to
di
formal relational system [Roberts, 1979]. Therefore,
formal relational system
Q be defined as follows:
Qh (C,
bm)
C
is
Si... Sn, h\...
let
a
a set of elements (e.g., real numbers)
^XQ formal relations on
S\...
Sn
b\...
bjn are binary operations
This
is
C
|i(a)
=)
(e.g., +,-,*)
accomplished by a metric
every element a € P,
(e.g., >, <,
\i
which maps an empirical system P
to a formal
system Q. For
e Q.
Definitions
The ontological
basis principles proposed by
Bunge
the basis of the concept of objects [Bunge, 1977].
in his "Treatise
on Basic Philosophy" forms
Consistent with
this
ontology, objects are
defined independent of implementation considerations and encompass the notions of encapsulation,
independence and inheritance. According
things,
to this
ontology, the world
referred to as substantial individuals ,and concepts.
is
The key
viewed as composed of
notion
is that
substantial
A
individuals possess properues.
An
inherently.
properly
is
observer can assign features
to an individual, these are attributes
All substantial individuals possess a finite set of properties.
properties.
possesses
a feature that a substantial individual
and not
"There are no bare
individuals except in our imagination" [Bunge, 1979].
Some
of the attributes of an individual will
only through
A known
attributes.
Propenies do not exist on
their
property must have
own
[Wand, 1987;
An object can be represented in
X = <x, p(x)> where x is the
X can be considered
Indeed, properties are recognized
at least
one
A
substantial individual
Wand and Weber,
the following
al.,
and
its
the other hand,
properties collectively
manner
substantial individual and p(x)
is
the finite collection of
object oriented terminology, the instance variables together with
the object [Baneijee, et
On
it.
1990].
be the token or name by which the individual
to
attribute representing
but are "attached" to individuals.
individuals are not bundles of properties.
constitute an object
reflect its properties.
its
is
properties.
its
represented in a system. In
methods
are the properties of
1987].
Coupling
Two
is
things are coupled
said to act upon
Y
if
and only
if
the history of
one of them "acts upon" the other [Wand, 1990].
if at least
Y
is
affected
by X, where history
is
X
defined as the
chronologically ordered states that a thing traverses in time.
let
X = <x, p(x)> and Y = <y,
p(x)
=
{
P(y)
=
{
Sx u Ix
Sy u ly
where
{
Si
}
)
)
is
{
{
p(y)> be two objects.
}
)
the set of
methods and
{
Ij
)
is
the set of instance variables of object
Using the above defmition of coupling, any
coupling, as does any action by
{Sy on (Sx)
}
one object using methods or instance
consistent with the law of
of objects
it
is
Demeter™
action by
/.
(Sx) on (Sy) or {ly)
constitutes
or (ly). Therefore, any evidence of a
method of
variables of another object constitutes coupling.
[Lieberherr, et al., 1988].
This
is
In order to promote encapsulation
generally considered good practice to reduce coupling between objects.
Cohesion
Bunge [1977]
the
two
defines similarity o() of
to be the intersection of
tfie
sets of properties
of
objects:
a(X,Y) = p(x)
Following
the
two objects
n p(y)
this general principle of defining similarity in terms of sets, the
methods within
by
that are used
the object can be defined to be the intersection of the sets of instance variables
the methods.
properties of methods, but
variables have
it
some degree
o(Mi,M2...Mn) =
{
Mj
)
should be clearly understood that instance variables, are not
It
makes
intuitive sense that
The degree of similarity
(i.e.,
methods
that operate
on the same instance
of similarity.
n M2 n M3
(
{
)
where a() = degree of similarity and
engineering,
degree of similarity of
{
Mj
}
=
...
)
set
{
Mn
)
of instance variables used by method Mi.
of methods relates both to the conventional notion of cohesion in software
keeping related things together) as well as encapsulation of objects, that
bimdling of methods and instance variables
in
is,
the
an object. Cohesion of methods can be defmed to
be the degree of similarity of methods. The higher the degree of
similarity of
methods, the greater
the cohesiveness of the methods and the higher the degree of encapsulation of the object
Complexiry of an object
Bunge defmes complexity
of an individual to be the "numerosity of its composition", implying that
a complex individual has a large number of propenies.
complexity of an object can be defined
Complexity of <x, p(x)> = p(x)
I
I,
Using
to be the cardinality of
where p(x)
I
I
is
its set
this definition as a base, the
of properties.
the cardinality of p(x).
Scope of Properties
The scope of
a property P in J
(
a set of objects)
is
the subset
G
(P; J)
of objects possessing the
property.
G(P;
J)
={
X
I
X€
J
and P e p(x)
) ,
where p(x)
is the set
of all properties of all x €
J.
Wand
propeny
C(p;
A
defines a class on the basis of the nouon of scope [1987],
J)
set p is the set
=
n all p
{
of
G(P)
I
The inheritance hierarchy
all
class P with respect to a
objects possessing all properties in p.
P e p(x)
)
a tree structure with classes as nodes, leaves
is
and a root.
Two
useful
concepts which relate to the inheritance hierarchy can be defined. They are depth of inheritance of
number of children of a
a class and the
Depth of Inheritance = height of
The height of
class.
the class in the inheritance tree
a node of a tree refers to the length of the longest path from the node to the root of
the tree.
Number of Children = Number of immediate descendents
Both these concepts
a property
of the class
relate to the notion of scope of properties,
i.e.,
how
far
does the influence of
extend? The number of children and depth of inheritance collectively indiCc^e the
genealogy of a
class.
the properties of
its
Depth of inheritance indicates the extent
ancestors and
number of children
to
which the
class is influenced
indicates the potential impact
by
on descendents.
Methods as measures of communication
In the object oriented approach, objects can
message can cause an object
Methods can be viewed
It is
communicate only through message
to "behave" in a particular
manner by invoking
passing.
a particular
A
method.
as definitions of responses to possible messages [Baneijee, et al., 1987].
reasonable therefore to define a response set for an object in the following manner
Response
set
of an object =
{
set
of all methods that can be invoked in response to a message to the
object}
Note
may
that this set will include
call
methods from other
methods outside the object as well, since methods within the object
objects.
object are finite and there are a finite
The response
set will
number of objects
be fmite, since the properties of an
in a design.
IV.
THE CANDIDATE METRICS
The candidate metrics outlined
were developed over
in this section
a period of several
months.
This was done in conjunction with a team of software engineers in an organization which has used
OOD in
number of different
a
language for
all
projects over the past four years.
projects at this site
was
C+4-, the
to
The viewpoints presented under each metric reflea
specific.
of many of the engineers, and are presented here
Metric
aim was
Weighted Methods Per Class
1:
to
Though
the primary
propose metrics
development
that are not
language
the object oriented design experiences
convey the
intuition behind each of the metrics.
(WMC)
Definition:
Consider
a
Class Ci, with methods Mi,... Mn.
Let
ci,...
Cn be the
static
complexity of the
methods. Then
n
WMC = X
Ci.
i=l
If all static
complexities are considered to be unity,
WMC = n, the number of methods.
Theoretical basis:
WMC relates directiy to the definition of complexity of an object, since methods are properties of
objects and complexity of an object
number of methods
is,
therefore, a
is
determined by the cardinality of
its set
of properties.
measure of object definition as well as being
The
attributes of
an
object, since attributes correspond to properties.
Viewpoints:
The number of methods and
and effon
The
is
the complexity of
methods involved
is
an indicator of how much time
required to develop and maintain the object
larger the
number of methods
children will inherit
all the
in
an object, the greater the potential impact on children, since
methods defined
in the
object
Objects with large numbers of methods are likely to be
possibility of reuse.
more
application specific, limiting the
Metric
Depth of Inheritance Tree (DIT)
2:
Definition:
Depth of inheritance of
the class
is
the
DIT
metric for the class.
Theoretical basis:
DIT
relates to the notion of scope of properties.
can potentially affect
DIT
a
is
measure of how many ancestor classes
this class.
Viewpoints:
The deeper
a class
is
in the hierarchy, the greater the
making
it
Deeper
trees constitute greater design complexity, since
It is
number of methods
it is
likely to inherit,
more complex.
useful to have a measure of
how deep
more methods and
classes are involved
a particular class is in the hierarchy so that the class can
be designed with reuse of inherited methods.
Metric
3:
Number
of children
(NOC)
Definition:
NOC = number of immediate sub-classes subordinated to a class in the class hierarchy.
Theoretical basis:
NOC
relates to the notion of scope
of properties.
going to inherit the methods of the parent
a measure of
It is
how many
sub-classes are
class.
Viewpoints:
Generally
it is
methods through
It is
have depth than breadth
better to
in the class hierarchy, since
it
promotes reuse of
inheritance.
not good practice for
in the hierarchy should
all
classes to have a standard
number of sub-classes. Classes higher up
have more sub-classes than classes lower in the hierarchy.
The number of children
gives an idea of the potential influence a class has on the design. If a class
has a large number of children,
it
may require more
testing of the
methods
in that class.
Metric
Coupling between objects (CBO)
4:
Definition:
CBO for a class is a count of the number of non-inheritance related couples with other classes.
Theoretical basis:
CBO relates to the notion that an object is
other,
coupled to another object
if
two objects act upon each
methods of one use methods or instance variables of another. This
i.e.,
traditional definitions of coupling as
is
consistent with
"measure of the degree of interdependence between modules"
[Pressman, 1987].
Viewpoints:
Excessive coupling between objects outside of the inheritance hierarchy
design and prevents reuse. The more independent an object
is,
the easier
is
detrimental to modular
it is
to reuse
it
in
another
application.
Coupling
that
not associative,
is
i.e., if
A
is
coupled to
B and B
is
coupled to C,
this
does not imply
C is coupled to A.
In order to improve modularity and promote encapsulation, inter-object couples should be kept to a
minimum. The
larger the
number of couples,
the design and therefore maintenance
A measure of coupling is useful
are likely to be.
Metric
5:
The higher the
Response For
to
is
more
the higher the sensitivity to changes in other parts of
difficult
determine
how complex
inter-object coupling, the
a Class
(RFC)
Definition:
RFC =
RS where RS
I
I
is
the response set for the class.
Theoretical basis:
The response
set for the class
RS = {Mi} UaiinlRi)
where Mj = all methods in the
and
{
Ri
)
=
set of
can be expressed
class
methods called by Mi
10
as:
the testing of various parts of a design
more rigorous
the testing needs to be.
The response
set
is
a set of
Since
attributes of an object.
also a
methods available
it
to the object
specifically includes
measure of communication between
and
methods
its
cardinality
is
a
measure of the
called from outside the object,
it is
objects.
Viewpoints:
If a large
number of methods can be invoked
response to a message, the testing and debugging
in
of the object becomes more complicated.
The
number of methods
larger the
that
can be invoked from an object, the greater the complexity of
the objecL
The
number of possible methods
larger the
can be invoked from outside the
that
class, greater the
level of understanding required on the part of the tester.
A
worst case value for possible responses
Metric
6:
Lack
will assist in appropriate allocation of testing dime.
of Cohesion in Methods
(LCOM)
Definition:
Consider a Qass Cj with methods Mj, M2...
method M[. There
,
M^. Let
(li)
=
set
of instance variables used by
are n such sets (Ij),... {In).
LCOM = The number of disjoint sets formed by the intersection of the n sets.
Theoretical basis:
This uses the notion of degree of similarity of methods. The degree of similarity for the methods
in class
o()
C^
is
given by:
= {Ii}n{l2}...n{In)
If there are
no common instance
variables, the
degree of similarity
is
zero.
However,
this
does not
distinguish between the case where each of the methods operates on unique sets of instance
variables and the case where only one method operates on a unique set of variables.
of disjoint sets provides a measure for the disparate nature of methods
sets implies greater similarity of methods.
methods of an
object,
and therefore
is
in the class.
Fewer disjoint
LCOM is intimately tied to the instance variables and
a measure of the attributes of an object
11
The number
Viewpoints:
Cohesiveness of methods within a class
Lack of cohesion implies
Any measure
Low
is
desirable, since
it
promotes encapsulation of objects.
classes should probably be split into
two or more
sub-classes.
of disparateness of methods helps identify flaws in the design of classes.
cohesion increases complexity, thereby increasing the likelihood of errors during the
development process.
Summary
The
table
Metric
below summarizes the
six metrics in relation to the
elements of
OOD shown in figure L
This implies that every object cannot have the same value for a metric, otherwise
it
has lost
its
value as a measurement.
Property 2: Non-umqueness (notion of equivalence)
There can exist
distinct objects
have the same metric value,
Property 3: Permutation
is
i.e.
P and
the
Q such
two objects
Q
such that
if
P
is
different ordering of the elements of
Q) then
Property 4: Implementation not function
important
imply that
are
(i(P)
)i
(P)
= ^(Q). This implies
are equally
that
two objects can
complex.
significant
There exist objects P and
Suppose there
that
is
two object designs P and
= ^(Q). The
a permutation of
\x(P)
Q
^
Q
(i.e.,
elements
in
P
are simply a
(i(Q).
which perform the same function,
intuition behind Property 4 is that
this
does not
even though two object designs
perform the same function, the details of the implementation matter
in
determining the object
design's metric.
Prcoerty 5: Monotoniciry
For
all
objects
P and Q,
the following
must hold:
^(P) < \xi?+Q)
< [i(P+Q)
[i(Q)
where P +
Q implies concatenation
therefore that the combination of
of
P and Q. This
implies that objects are minimally zero, and
two objects can never be
less than either of the
component
objects.
Property 6: Non-equivalence ofinieracdon
Given 3
ji(P)
P,
3 Q, 3 R,
= n(Q) does
not imply that ^t(P+R)
= ^(Q+R).
This implies that interaction between P and
R can
be different than interaction between
Property 7: Interaction increases complexity
3 P and Q such
^i(
P)
+ n(Q) <
The idea
V.
is that
that:
^i(
P+Q)
interaction
between objeas
will tend to increase complexity.
RESULTS: PROPERTIES OF THE CANDIDATE METRICS
13
Q and R.
A
design goal for
the
all six
metrics
is
their use in analysis of object oriented
programming language. in which
the application
is
designs independent of
However, there are some basic
written.
assumptions made regarding the distribution of objects, methods and instance variables
in the
discussions for each of the metric properties.
Assumprion
1:
Xi = The number of methods
Let
in a
given class
i.
Yi = The number of methods called from a given method
Z[
= The number of instance
method
variables used by a
Ci = The number of couplings between a given object
i
/.
/.
and
all
other objects.
Xj, Yi, Zi, Ci are discrete random variables each characterized by some general distribution
function. Further,
all
the Xis are independent
and identically
distributed.
The same
is
true for all
the Yis, Zjs and Qs.
Assumprion 2 Xi >
1 i.e.,
:
Assumption
3
:
each class contains one or more methods.
Two classes
can have identical methods,
in the sense that
combination of the two
classes into one class would result in one of the methods being redundant.
Assumprion 4 The
:
have siblings, and
inheritance tree
leaves.
The
is "full" i.e.,
there is a root, several intermediate
tree is not balanced, i.e.,
nodes which
each node does not necessarily have the
same number of children.
These assimiptions while believed
Metric
Let
1:
Let y = probability
<P<
be reasonable, are of course subject to future empirical
Weighted Methods Per Class
Xp = number of methods
As
to
1
Xp
?t
in class
Xq and
,
from assumption
therefore property
=
such that
|i(P)
does not
alter the
1 is
|i(Q).
1,
satisfied.
(1
(WMC)
P and Xn = number of methods
-
y)
there
=
probability
<
Similarly,
Therefore property 2
number of methods of
1 -
y <
is satisfied.
the object.
in class
3
1,
a
Let
^i(P)
= np and
|i(Q)
=
nq, then ^i(P+Q)
|i(Q), thereby satisfying property 5.
number of methods 9
in
common
Now,
with
Q
such that
^
tiiat
M-(Q),
3 a
Q
Permutation of elements inside the object
Therefore Propeny 3
is
not satisfied.
The
The choice of methods
is
is satisfied.
= np +
let ji(P)
=
nq.
Clearly,
n, \i(Q)
=
n,
^(P+Q) >
3 an object
Q but no methods in common with P.
14
|i(P)
there is a finite probability
function of the object does not define the number of methods in a class.
an implementation decision, therefore Property 4
Q.
Xp = Xq
a fmite probability that
is
test.
|i(P)
R
and ^(P+Q) ^
such that
Let p.(R) =
r.
it
has a
(I(P+R) = n +
r
|i(Q+R) = n + T-d
^(P+Q) * p.(Q+R) and property
therefore
"p + nq
-
d,
where np
have B methods
Clearly,
i.e.,
np + nq
in
|i(P+Q) <
-
2:
the
is
satisfied.
number of methods
in P,
9 < np + nq for
\i(P)
is
number of methods
in
Q
+
[i{Q) for
is
all
all
P and Q.
not satisfied.
4,
every tree has a root and leaves. The depth of inheritance of a leaf
1
nodes with siblings, there
at least
property 2
is satisfied.
will
always exist
is
satisfied.
tree,
In other words, depth of inheritance
when one
is
always
Also, since every tree has at least some
two objects with
the
same depth of inheritance,
and therefore property 3
is
not satisfied. Implementation of an
object involves choosing what properties the object must inherit in order to perform
any two objects P
is
Permutation of the elements within an object does not alter the position
of the object in the inheritance
i)
Q
P and Q.
greater than the root. Therefore, property
When
and P and
Depth of Inheritance Tree (DIT)
Per assumption
i.e.,
nq
For any two objects P and Q, |J.(P+Q) =
common.
Therefore Property 7
Metric
is
6
is
implementation dependent, and property 4
& Q are combined,
is
its
function.
satisfied
there are three possible cases:
a child of the other
In this case, ^(P)
=
n, |i(Q)
=
n
+
1,
but
^(P+Q) =
satisfied.
15
n, i.e.
^(P+Q) <
\i
(Q).
Property 5
is
not
Case
P
ii)
& Q are siblings
In this case, p.(P)
Case
If
iii)
P
|i(Q)
this case, p.(P)
=
P maintains
x, p.(y)
is satisfied.
not satisfied.
)i(P+R)
and y >
Let P and
For any two objects P
is
its
is satisfied.
x.
inheritance. Therefore,
|i(P+Q) =
Since ^i(P+Q) >
Q
be siblings,
= n and |i(Q+R) = n +
Property 7
Property 5
n, i.e.
Q does cannot inherit methods from C, however if P+Q
to P's location in the tree,
to Q's location,
property 5
= n and |i(P+Q) =
& Q are not directly connected.
P+Q moves
moves
=
& Q,
p. (
1.
i.e.
n(P)
|i(P+R)
is
^(P) or
not satisfied.
16
will be in Q's old location. In
M.(P+Q) > ^(P) and p.(P+Q) =
not satisfied for
|i(P) is
i.e.
P+ Q) =
y, i.e.,
P+Q
= |i(Q)=
n,
all
and
(Q) and
possible cases, Property 5
let
R
be a child of
not equal to ^(Q+R). Property 6
= n(Q).
p.
Therefore, ^i(P+Q)
<
^i(P)
P.
is
Then
is satisfied.
+
[i{Q)
i.e.
Metric
Number Of Children (NOC)
3:
Let P and
R
property
is satisfied.
1
be leaves, ^(P) = ^(R) =
Since |i(R) =
0, let
Q
be the root |i(Q)
Property 2
|J.(P),
>
|i(P)
0.
^
p.(Q) therefore
also satisfied. Permutation of elements
is
within an object does not change the number of children of that object, therefore Property 3
within the object,
the sub-classing for the object.
i.e,
dependent upon implementation of the
object.
two objects with np and nq sub-classes
respectively
P and Q,
will yield a single object with np
P and
Q have in common.
nq
> nq. This can be written
^i(P-K^
not
Implementation of an object involves decisions on the scope of the methods declared
satisfied.
-3
is
>
^i(P)
is
=
}i(P)
satisfied.
is
=
n
-
np or nq
^
object obtained by
Therefore property 6
li(Q-i-R).
Q
Given any two objects P and
= np and
is 0.
|i(Q)
is
Now, np
=
the
-i-
is
therefore
Let P and
Q be
Combining
nq).
number of children
nq
-
9 > np and np +
Q.
all
Q each have
Let P and
The
|J.(Q).
P and
all
R be
n children and
combining P and
Q and R will have n
children, whereas an object obtained by combining
that ^(P-i-R)
is satisfied.
8 sub-classes, where d
either
if
(i.e., |J.(P)
sub-classes
as:
and \i(?+Q) > ^(Q) for
Therefore, Property 5
has r children.
Clearly, 3
Therefore, property 4
nq
-i-
The number of
+
R
a child of
will
P which
have (n-1) +
r children, which
r
means
is satisfied.
with np and nq children respectively, the following relationship
holds:
^(P) = np and ^i(Q) = nq.
^i(P+Q) = np + nq
where d
the
is
3
-
number of common
Therefore, |i(P-M5) <
Metric
Let
4:
|i(P)
for class
P
Xq = RFC
for class
Q.
Let y = probability
Xp
Xq =
F(Yi) and
method
in class P.
?t
Xq
,
F(Yj)
Now, FQ
number of methods
random
|i(Q) for all
P and Q. Property 7
is
not satisfied.
Response for a Class (RFC)
Xp = RFC
Xp =
-f-
children.
(1
-
i.e.,
is
y)
=
Xp
called increases.
i.i.d.
resulting in property
such that ^(P) =
1
is
Xp = Xq
some function of
monotonic
variables, as per assumption
variables that are
probability
in
the
number of methods
called by a
Y, since the response set can only increase as the
Yj and Yj are independent identically distributed discrete
Therefore, F(Yi) and F(Yj) are also discrete
1.
Therefore, there
is
a fmite probability that
being satisfied. Also as
<
1 -
y <
^1(0), therefore property 2 is satisfied.
1
3
a
Q
such that
p.(P)
random
#
there is a finite probability that
Implementation of an object involves decision about the methods that need
17
3 a
Q
Permutation of elements within an object
does not change the number of methods called by that object, and therefore property 3
satisfied.
|i(Q)
is
not
to be called
and therefore Propeny 4
Q = nq.
rwo classes
If these
larger of the
RFC
two
|i(R)
=
property 6
is
<
Xp = LCOM
Xq = LCOM
Xp = F(Yi)
method
random
is
=*
|i
for all possible
+
fi(P)
nq).
RFC
of
Clearly, Max(np,nq) > nn
|i(P+Q) > ^(P) and > |i(Q) for
Q and R
which means
|i(Q)
of P = nn and
class, the response for that class will be the
(P+Q) = Max(np,
P and Q.
Let P,
is satisfied.
for class
be three classes such
i.e.,
=
that, |i(P)
all
P and Q.
[i(Q)
= n and
[i(P+Q) = ^i(R+Q). Therefore
P and Q, |i(P+Q) = Max(p.(P),
|i(Q)).
Qearly,
that Property 7 is not satisfied.
and
P
for class Q.
Xp
?i
Xq
(1
,
Xq = F(Yj)
i.e.,
Now,
in class P.
number of
discrete
Q
RFC
Lack Of Cohesion Of Methods (LCOM)
5:
Let y = probability
a
form one
not satisfied. For any two classes
Max(|i(P), |i(Q))
Let
to
Then |i(P+Q) = Max(n,r) and |i(Q+R) + MaxCn^").
r.
Metric
be two classes with
combined
values for P and
and Max(np,nq) > nq
Therefore, property 5
are
Q
Let P and
satisfied.
is
-
y)
Xp
F() is
=
is
probability
some function of
monotonic
in
variables, as per assumption
variables that are
i.i.d.
Q
such that
number of instance
Y, since the
LCOM
variables used
by
can only decrease as the
Therefore, F(Yi) and F(Yj) arc also discrete
1.
therefore property
a finite probability that 3 a
the
Yj and Yj are independent identically distributed
instance variables used increases.
random
Xp = Xq
1 is
|i(P)
Permutation of the elements of an object does not
Also
satisfied.
=
asO<l-y<l.
|i(Q), therefore property
alter the set of
2
then there
is
methods called from
satisfied.
that object,
LCOM
value depends on the construction of methods, which is implementation dependent, making LCOM
also implementation dependent and satisfying property 4. Let P and Q be any two objects with
consequently not changing the value of LCOM. Therefore, property 3
p.(P)
= Hp and
disjoint sets,
p,(Q)
i.e.,
=
nq.
Combining these two objects can
|i(P+Q) = np + nq
-
9 where 9
combination of P and Q. The reduction 9
variables of the two objects
is
is
the
some
not satisfied.
The
potentially reduce the
number of disjoint
sets
number of
reduced due
to the
function of the particular sets of instance
Now, np > 9 and nq > 9
P and Q.
is
obviously cannot be greater than the number of original
sets.
since the reduction in sets
Therefore, the following result
holds:
np + nq -9 > np
np + nq
-
for all
9 > nq for
Property 5
all
P and
Q
and
P and Q.
is satisfied.
P and Q be two objects such
|i(P+Q) = n + r - 9, similarly
Let
[iCQ+R) = n +
r
-
that p.(P)
=
B
18
|J.(Q)
= n and
,
let
R be another object with )i(R) = r.
Given
and B are not functions
thai d
propeny
satisfying
=
For any two objects P and Q, |i(P+Q) = np + nq
6.
|i(P)
+
|i(Q)
^i(P+Q) < ^l(P)
+
|I(Q) for all
}I(P+Q)
Therefore property 7
Metric
6:
they need not be equal,
ot" n,
3 which implies
-
is
i.e.,
-
8.
^ |i(Q+R),
ti(P+R)
i.e.,
that
P and Q.
not satisfied.
Coupling Between Objects (CBO)
As per assumption
1,
satisfying properties
1
there exist objects P,
and
Q
and
R
such
that
|J.(P)
^
|i(Q)
and
|l(P)
= ^(R)
Permutation of the elements inside an object does not change the
2.
number of inter-object
couples, therefore property 3 is not satisfied. Inter-object coupling occurs
when methods of one
object use methods or instance variables of another object,
depends on the construction of methods. Therefore property 4
two objects with
np + nq
3 couples, where 3
-
M-(P+Q) = np
and nq
-t-
3>
-
= np and
}i(P)
nq
-
since
3,
|i(Q)
the
is
where 3
is
±e reduction
=
nn. If
P and
Let
is satisfied.
P and
coupling
Q
be any
Q are combined, the resulting object will have
number of couples reduced due
to the
combination. That
some function of the methods of P and Q.
in
i.e.,
Clearly,
np
-
is
3 >
couples cannot be greater than the original number of couples.
Therefore,
np + nq
np +
i.e.,
-
3 > np for
all
nq-3^nqforallP
}i(P+Q) >
li(P)
Q and
P and
Q
and
and |i(P+Q) >
^i(Q) for all
Q be two objects such that ^(P) = |i(Q) = n
p,(P-HQ)
=n
^(Q-i-R)
=n +
Given
r
-I-
that 3
-
r -
^i(P+Q) = |i(P) + ^1(0)
+
let
R be
is satisfied.
another object with p,(R)
Let P and
= r.
6
and B are not functions of
^i(P)
and
property 5
3, similarly
}i(Q+R), satisfying property
^(P+Q) <
,
P and Q. Thus,
-
is
all
they need not be equal,
For any two objects
3 which implies
^t(Q) for
Therefore property 7
6.
n,
P and Q,
li(P+Q)
i.e.,
|i(P+R)
= np + nq
-
is
not equal to
3.
that
P and Q.
not satisfied.
Summary of results
All six metrics
object
is
fail to
meet property
3,
suggesting that perhaps permutation of elements within an
not significant. The intuition behind this
depend on ordering of elements within
it,
unlike
is
that
measurements on class design should not
program bodies where permutation of elements
should yield different measurements reflecting the nesting of if-then-else blocks.
19
The
rarionaJe behind
complexity due
propeny
Weyuker
this is
"aJlow for the possibility of increased
All six metrics
research in this area
is
needed
a
design
property 6 and the
DIT
is
broken into more objects.
metric
deficiencies are a result of the definition of the two metrics
It is
and
fails to satisfy
property
DIT
metric, as
shown
and note
Summary
of Results
METRIC
5.
These
that this property
may
earlier does not satisfy the monotonicity
property (property 5) only in the case of combining two objects in different parts of the
metrics properties.
Further
worth pointing out that Harrison [1988] and Zuse [1991] have
not be widely applicable. Also, the
may
this,
further refinements will be required
criticized the non-equivalence of interaction property (property 6)
empirical research
meet
to clarify this issue.
fails to satisfy
to satisfy these properties.
fail to
not applicable to object oriented designs. This also raises the issue
complexity could increase, not reduce as
The RFC metric
is to
to potential interaction" [Weyiiker, 1988].
suggesting that perhaps
that
7 according to
tree,
which
demonstrate to be a rare occurrence. Table 2 presents a summary of the
research designed both to extend the current proposed
memc
set
and
to further investigate these
apparent differences seems warranted.
In particular, this set of six proposed metrics
formal metrics for
OOD. They
is
presented as a
are unlikely to be comprehensive,
additions, changes and possible deletions from this suite.
frrst
attempt
at
development of
and further work could
However,
at
a
minimum,
this
should lay the groundwork for a formal language with which to describe metrics for
addition, these metrics
when
may
result in
proposal
OOD.
In
also serve as a generalized solution for other researchers to rely on
seeking to develop specialized metrics for particular purposes or customized environments.
Currently planned empirical research will aaempt to validate these candidate metrics by measuring
them on
will be
actual systems. In particular, a three-phased approach is
measured on
a single pilot system. After this pilot test.
the metrics for multiple systems and simultaneously collecting
for purposes of comparison.
planned
Phase
n
In Phase
I,
the metrics
will consist of calculating
some previously
established metrics
These previously existing metrics could include such well-known
measures as source hnes of code, function points, cyclomatic complexity, software science
metrics, and fan-in/fan-out. Finally, Phase HI of the research will involve collecting performance
data on multiple projects in order to determine the relative efficacy of these metrics in predicting
managerially relevant performance indicators.
It is
often noted that
moving
00 may hold some of the solutions to the software crisis.
00 development management towards a strong theoretical
significant future progress.
21
Further research in
base should provide a basis for
REFERENCES
Abbot, R.
J.
Banerjee,
(1987).
J.,
"Knowledge Abstraction," Communicaiions of the ACM,
et al. (1987).
"Data Model Issues
Transactions on Office Information Systems,
5,
30, 664-671.
for Object Oriented Applications,"
ACM
January, 3-26.
Booch, G. (1986). "Object Oriented Development," IEEE Transactions on Software Engineering,
SE-12, February, 211-221.
Bunge, M. (1977). Treatise on Basic Philosophy
:
Ontology
I
:
The Furniture of the World.
Boston, Riedel.
Bunge, M. (1979). Treatise on Basic Philosophy
:
Ontology
II
:
The World of Systems. Boston,
Riedel.
Chemiavsky, V. and D. G. Lakhuty (1971). "On The Problem of Information System
Evaluation," Automatic Documentation and Mathematical Linguistics, 4, 9-26.
Cunningham, W. and K. Beck (1987). "Constructing Abstractions
for Object Oriented
Applications", Computer Research Laboratory, Textronix Inc. Technical Report CR-87-25, 1987.
Deutsch, P. and A. Schiffman (1983). "An Efficient Implementation of the Smalltalk-80 System,"
Conference record of
the Tenth
Annual
ACM
Symposium on
the Principles
of Programming
Languages.
Fenton, N. and A. Melton (1990). "Deriving Structurally Based Software Measures," Journal of
Systems and Software,
Harrison,
W.
12, 177-187.
(1988). "Software Science and Weyuker's Fifth Property", University of Portland
Computer Science Department
Internal
Repon
Hecht, A. and D. Taylor (1990). "Using
Language,
7,
1988.
CASE
for Object Oriented
Design with C++," Computer
November, Miller Freeman Publications, San Francisco, CA.
22
Kearney,
ACM,
J.
K., et
(1986). "Software Compiexity Measurement,"
al.
Communications of
the
29 (11), 1044-1050.
Lieberherr, K., et
al.
(1988). "Object Oriented
Programming
:
An
Objective Sense of Style," Third
Annual ACM Conference on Object Oriented Programming Systems, Languages and Applications
(OOPSLA). 323-334.
Meyer, B. (1988). Object Oriented Software Construction
(Series in
Computer Science). New
Yoric, Prentice Hall International.
Moreau, D. R. and W. D. Dorainick (1989). "Object Oriented Graphical Information Systems:
Research Plan and Evaluation Metrics," Journal of Systems and Software,
10, 23-28.
Morris, K., (1988). Metrics for Object Oriented Software Development, unpublished Masters
Thesis, M.I.T., Cambridge,
Page, T., et
al.
(1989).
"An
MA.
Object Oriented Modelling Environment," Proceedings of the Fourth
Annual ACM Conference on Object Oriented Programming Systems, Languages and Applications
(OOPSLA).
Pamas, D.
L., et al. (1986).
Enhancing Reusability with Information Hiding. Tutorial: Software
Reusability^ P. Freeman, Ed.,
New
York, IEEE Press. 83-90.
Peterson, G. E. (1987). Tutorial: Object Oriented Computing.
Pfleeger, S. L. (1989).
"A Model of Cost and Productivity
IEEE Computer
Society Press.
for Object Oriented
Development",
Contel Technology Center Technical Report.
Pfleeger, S. L. and
J.
D. Palmer (1990). "Software Estimation for Object Oriented Systems," Fall
International Function Point Users Group Conference. San Antonio, Texas, October 1-4, 181196.
Pressman, R.
S. (1987).
Software Engineering:
Hill.
23
A
Practioner's Approach.
New
York,
McGraw
Robens,
Encyclopedia of Mathemaiics and
F. (1979).
Publishing
M.
Stark (1986). "Towards a General Object Oriented Software Development
ADA
Methodology," First International Conference on the
NASA Space
Vessey,
I.
,
Station. D.4.6.1-D4.6.14.
IEEE Transactions on Software
Y. and R.
Weber
(1990).
"An
(1987).
A
Engineering, SE-10 (4), 394-407.
Ontological
Transactions on Software Engineering, 16,
Wand, Y.
Programming Language Applications
and R. Weber (1984). "Research on Structured Programming: An Empiricist's
Evaluation,"
Wand
Applications. Addison Wellesley
Company.
Seidewitz, E. and
for the
its
N
11,
Model of an Information System," IEEE
November, 1282-1292.
Proposal for a Formal Model of Objects. Research Directions in Object
Oriented Programming. Ed., Cambridge,
MA,
M.I.T. Press. 537-559.
Weyuker, E. (1988). "Evaluating Software Complexity Measures," IEEE Transactions on
Software Engineering, 14,
No 9,
September, 1357-1365.
Wybolt, N. (1990). "Experiences with
C++ and
Object Oriented Software Development,"
USENIX Association C++ Conference Proceedings. San
Francisco,
Zuse, H. (1991). Software Complexity: Measures and Methods.
CA.
New
York, Walter de Grutyer.
Zuse, H. and P. Bellman (1987). "Using Measurement Theory to Describe the Properties and
Scales of Static Software Complexity Metrics", I.B.M. Research Center Technical
13504, August.
24
Repon
RC
5939 .50
Date Due
MIT LIBRARIES DUPl
3
TOaO ODflMbblS
7