£Y
HD28
.M414
A METRICS SUITE FOR
OBJECT ORIENTED DESIGN
Chidamber
Chris F. Kemerer
Shyam
R.
December 1992
CISR
Sloan
WP
WP
No. 249
No. 3524-93
Center for Information Systems Research
Massachusetts Institute of Technology
Sloan School of Management
77 Massachusetts Avenue
Cambridge, Massachusetts, 02139
A METRICS SUITE FOR
OBJECT ORIENTED DESIGN
Shyam
Chidamber
Chris F. Kemerer
R.
December 1992
CISR
Sloan
©1992
S.R.
WP
WP
No. 249
No. 3524-93
Chidamber, C.F. Kemerer
Center for Information Systems Research
Sloan School of Management
Massachusetts Institute of Technology
-
3
1993
A METRICS SUITE FOR OBJECT ORIENTED DESIGN
Shyam R. Chidamber
Chris
F.
Kemerer
Abstract
Given the
central role that software development plays in the delivery and application of
information technology, managers are increasingly focusing on process improvement in the
software development area. This demand has spurred the provision of a number of new and/or
improved approaches to software development, with perhaps the most prominent being objectorientation (00). In addition, the focus on process improvement has increased the demand for
software measures, or metrics with which to manage the process. The need for such metrics is
particularly acute when an organization is adopting a new technology for which established
practices have yet to be developed. This research addresses these needs through the development
and implementation of a new suite of metrics for
design. Metrics developed in previous
research, while contributing to the field's understanding of software dev«»'.jpment processes, have
generally been subject to serious criticisms, including the lack of a theoretical base. Following
Wand and Weber, the theoretical base chosen for the metrics was the ontology of Bunge. Six
design metrics are developed, and then analytically evaluated against Weyuker's proposed set of
measurement principles. An automated data collection tool was then developed and implemented to
collect an empirical sample of these metrics at two field sites in order to demonstrate their feasibility
and suggest ways in which managers may use these metrics for process improvement.
00
TABLE OF CONTENTS
"A
Metrics Suite For Object Oriented Design"
Introduction
Research Problem
Theory Base for
00
Metrics
Measurement Theory Base
Definitions
Metrics Evaluation Criteria
Empirical Data Collection
Results
Metric 1: Weighted Methods Per Class
(WMC)
Metric 2: Depth of Inheritance Tree (DIT)
Metric 3:
Number of children (NOC)
Metric 4: Coupling between objects (CBO)
Metric 5: Response For a Class (RFC)
Metric 6: Lack of Cohesion in Methods
The Metrics Suite and Booch
OOD Steps
Summary of Analytical Results
Concluding Remarks
Bibliography
(LCOM)
Introduction
It
has been widely recognized that an important component of process improvement
measure the process. Given the central role
that software
development plays
is
the ability to
in the delivery
and
application of information technology, managers are increasingly focusing on process
improvement
that this
in the
The
software development area. This emphasis has had two effects.
demand has spurred
the provision of a
first is
number of new and/or improved approaches
to
software development, with perhaps the most prominent being object-orientation (OO). Second,
the focus
on process improvement has increased the demand for software measures, or metrics
with which to manage the process.
organization
is
The need
new technology
adopting a
for such metrics is particularly acute
for
when an
which established practices have yet
to be
developed.
new
This research addresses these needs through the development and implementation of a
metrics for
OO design.
suite of
Previous research on software metrics, while contributing to the field's
understanding of software development processes, have generally been subject to one or more
types of criticisms.
These include: lacking a theoretical basis [26], lacking
measurement properties
dependent
Following
[30],
being insufficiently generalized or too implementation technology
[31],
and being too labor-intensive to collect
Wand and Weber,
ontology of Bunge
[4, 5,
28].
[15].
the theoretical base chosen for the
OO
design metrics was the
Six design metrics were developed, and analytically evaluated
against a previously proposed set of
measurement
was then developed and implemented
sites in
principles.
to collect an empirical
An
automated data collection
sample of these metrics
order to demonstrate their feasibility and to suggest ways in which managers
metrics for process
The key
in desirable
at
may
two
tool
field
use these
improvement
contributions of this paper are the development and empirical validation of a set of
theoretically-grounded metrics of
next section presents a brief
OO design.
The
rest
of this paper
is
organized as follows. The
summary of the research problem followed by
theory underlying the approach taken.
Then Weyuker's
list
a section describing the
of software metric evaluation
are presented, along with a brief description of the empirical data collection sites.
criteria
The Results
section presents the metrics, their analytical evaluation, the empirical data and a managerial
interpretation of the data for
section.
each metric. Some concluding remarks are presented
in the final
Research Problem
There are two general types of criticisms
that
can be applied
category are those theorencal criticisms that are leveled
applied to traditional,
at
to current software metrics.
The
first
conventional software metrics as they are
non-00 software design and development.
Kearney, et
al. criticized
software complexity metrics as being without solid theoretical bases and lacking appropriate
properties
14].
(
structured
Vessey and Weber also commented on the general lack of theoretical rigor
programming
literature [26].
Both Prather and Weyuker proposed
in the
that traditional
software complexity metrics do not possess appropriate mathematical properties, and consequently
fail to
display what might be termed normal predictable behavior [23, 31].
This suggests that
software metrics need to be constructed with a stronger degree of theoretical and mathematical
rigor.
The second category of
criticisms
is
more
specific to
approach centers around modeling the real world
older,
more
traditional approaches that
in
00
design and development.
terms of
its
Given the fundamentally
which
emphasize a function-oriented view
procedures. Several theoretical discussions have speculated that
different problem-solving behavior
objects,
and cognitive processing
different notions inherent in these
is
The
OO
in contrast to
that separate data
and
OO approaches may even induce
in the
design process, e.g. [3, 16].
two views,
it is
not surprising to find
that
software metrics developed with traditional methods in mind do not readily lend themselves
00
notions such as classes, inheritance, encapsulation and message passing [12].
to
Therefore,
given that current software metrics are subject to some general criticism and are easily seen as not
supporting key
00
concepts,
it
seems appropriate
especially designed to measure unique aspects of the
The shortcomings of
existing metrics
to
develop a
set,
or suite of
new
metrics
OO approach.
and the need for new metrics especially designed for
Some
have been suggested by a number of authors.
initial
OO
proposals are set out by Morris,
although they are not tested [20]. Lieberherr and his colleagues present a more formal attempt
at
defining the rules of correct object oriented programming style, building on concepts of coupling
and cohesion that are used
metrics for
in traditional
OO graphical information systems,
Pfleeger also suggests the need for
to
programming
develop and
test a cost
Chidamber and Kemerer,
empirical data
[8,
but
Sheetz, et
al.,
Moreau and E)ominick suggest
do not provide formal,
new measures, and
estimation model for
[18].
OO
three
testable definitions [19].
uses simple counts of objects and methods
development
[22].
Other authors, such as
and Whitmire propose metrics, but do not offer any
25, 32]. Despite the growing research interest in this area, no empirical metrics
data from commercial object oriented applications has been published in the archival literature.
Given the extant software metrics
literature, this
paper has a three fold agenda:
1)
to
propose
metrics that are constructed with a firm basis in theoretical concepts in measurement and the
ontology of objects, and which incorporate the experiences of professional software developers; 2)
evaluate the proposed metrics against established criteria for validity, and 3) present empirical data
from commercial projects to demonstrate the
ways
in
feasibility of collecting these metrics
and suggest
which these metrics may be used.
Theory Base for
OOD
Metrics
While there are many object oriented design (OOD) methodologies, one
features of
OOD
is
presented in Booch (1991). 1
He
that reflects the essential
outlines four major steps involved in the
object-oriented design process:
1) Identification
are identified
of Classes and Objects In this step, key abstractions
and labeled as potential classes and objects.
in the
problem space
Semantics of Classes and Objects In this step, the meaning of the classes and
objects identified in the previous step is established, this includes definition of the lifecycles of each object from creation to destruction.
2) Identify the
Relationships between classes (and objects) In this step, class and object
interactions, such as patterns of inheritance among classes and patterns of visibility
among objects and classes (what classes and objects should be able to "see" each other)
are identified.
3) Identify
4)
Implementation of Classes and Objects In this step, detailed internal views are
constructed, including definitions of methods and their various behaviors.
The metrics outlined
in this
paper will
map
to the first three (non-implementation) stages outlined
by Booch, since they parsimoniously capture the essential features of
metrics are specifically
aimed
at addressing the
constructs, the potential benefits
at later
will
OOD.
Since the proposed
design phase and do not depend on code-based
of this information can be substantially greater than metrics aimed
phases in the life-cycle of an application. In addition, implementation-independent metrics
be applicable to a larger set of users, especially in the early stages of industry's adoption of
00 before dominant implementation standards emerge.
Measurement theory base
An object oriented design can
be conceptualized as a relational system, which
as an ordered tuple consisting
of a
l
set
For a comparison and critique of six different
is
defined by Roberts
of elements, a set of relations and a set of binary operations.
OO
analysis
and design methodologies see
[10].
4
More
[24].
specifically, an object oriented design, D,
is
conceptualized as a relational system
consisting of object elements (classes and objects), empirical relations and binary operations that
can be performed on the object elements. Notationally:
D
= (A. Rl... R n
.
Ol...O m )
where
A
is
a set of object elements
Rl...R n are empirical relations
Oi...O
A
useful
m are
way
understand empirical relations on a
to
A
(e.g.,
bigger than, smaller than,
equally complex.
set
of object elements
to consider the
is
which element
is
more complex than another or which ones
For example, a designer intuitively understands that a class
more complex,
generally
ceteris paribus, than
The notion of
intuitive idea is defined as a viewpoint.
one
that has only a
a viewpoint
was
describe evaluation measures for information retrieval systems and
designer views
etc.)
designer generally has some intuitive ideas about the complexity of
different object elements, as to
is
A
binary operations (e.g., concatenation)
measurement of complexity.
methods
on object elements
More
[7].
is
that has
arc
many
few methods. This
originally introduced to
applied here to capture
recently, Fenton states that viewpoints characterize intuitive
understanding and that viewpoints must be the logical starting point for the definition of metrics
[9].
An
empirical relation
is
identical to a viewpoint,
for the sake of consistency with the
A
viewpoint
P" €
P
,
the following
P >P
P.£
a binary relation
is
or P' >
P',
P
.>
complex than P
i.e.,
a viewpoint
To be
measurement theory
> defined on
two axioms must
P (completeness: P
=>
P"
,
is
P
is
(the set of all possible designs).
For
P, P',
if
P
is
P' or
P
is
more complex than P)
more complex than
P'
and
P' is
more
than P")
[24].
able to measure something about a object design, the empirical relational system as defined
above needs
to
be transformed to a formal relational system. Therefore,
system F be defined as follows:
F <C.Si...S n ,Bi...B
C
P
more complex than
more complex
must be of weak order
a set
literature.
hold:
P.> P" (transitivity:
then
and the two terms are distinguished here only
is
m
)
a set of elements (e.g., real
numbers)
let
a formal relational
S\...
S n are formal relations on
B\...
Bm
(e.g., >, <,
=)
are binary operations (e.g., +,-,*)
This required transformation
formal system F.
is
system
accomplished by a metric n which maps an empirical system
For every element a e D,
school children illustrates the
relational
C
(i(a)
e F. The example below involving a
mapping between an empirical
[13]:
Empirical Relational System
relational system
D
to a
set of
and a formal
encompass the notions of
arc defined independent of implementation considerations and
encapsulanon, independence and inheritance. According
composed
or"
A
An
possesses inherenUy.
not properties.
property
is
viewed
is
as
that
a feature that a substantial individual
is
observer can assign features to an individual, but these are attributes and
All substantial individuals possess a finite set of properties: "there are no bare
individuals except in our imagination"
[4, p.
26]
of the attributes of an individual will reflect
A known
only through attributes.
do not
Properties
world
and concepts. The key notion
things, referred to as substantial individuals,
substantial individuals possess properties.
Some
to this ontology, the
on
exist
their
its
property must have
at least
own, but are "attached"
individuals are not simply bundles of properties.
Indeed, properties are recognized
properties.
A
one
attribute representing
to individuals.
On
it.
the other hand,
substantial individual and
its
properties
its
properties.
collectively constitute an object [27, 28].
An
X
x
object can be represented
= <x, p(x)> where x
in the
following
manner
the substantial individual
is
and p(x)
is
the finite collection of
can be considered to be the token or name by which the individual
object oriented terminology, the instance variables 2 together with
the object
[
its
is
represented in a system. In
methods 3 arc the properties of
1 ]
Using these representations of objects, previous research has defined concepts
similarity that are relevant to object oriented
systems
[4, 27].
Following
like
this tradition, this
defines two important software design concepts for objects, coupling and cohesion.
refers to the degree of interdependence
X
said to act
is
upon
Y
if
if
the history of
and only
X
= <x, p(x)> and
p(x)
2
3
=
{
MX u
}
Y
{
I
Y
is
)
An instance variable is i repository for part of the stale
A method is an operation on an object that is defined as
one of them "acts
affected by X,
= <y, p(y)> be two objects.
X
good software design
if at least
defined as the chronologically ordered states that a thing traverses in time
Let
Coupling
and maximizing cohesiveness.
Coupling. In ontological terms, two things are coupled
upon" the other.
paper
between parts of a design, while cohesion refers to the
internal consistency within parts of the design. All other things being equal,
practice calls for minimizing coupling
scope and
of the object.
part of the declaration of the class.
[4].
where history
is
p(y)
where
(
{M Y ]u(I Y
=
Mj
}
is
the set of
]
methods and
(
l[
}
is
the set of instance variables of object
i.
(Mx) on (My) or {Iy} constitutes
(Ix)- When Mx calls My. Mx alters the
Using the above definition of coupling, any action by
coupling, as does any action by
history of the usage of
Iy.
My,
{My} on (Mx)
similarly
when
or
Mx uses ly,
it
alters the access
and usage history of
Therefore, any evidence of a method of one object using methods or instance variables of
another object constitutes coupling.
Cohesion.
Bunge defines
two things to be the intersection of the
similarity c() of
sets
of properties
of the two things:
o(X,Y) = p(x)
Following
the
used by the methods. This
of methods.
it
is
terms of
this general principle of defining similarity in
methods within the object can be defined
that are
but
n p(y)
It
is
sets, the
degree of similarity of
be the intersection of the sets of instance variables
to
an extension of Bunge's definition of similarity to similarity
should be clearly understood that instance variables are not properties of methods,
consistent with the notion that methods of an object are intimately connected to
its
instance
variables.
a(M!,M 2 ...M n ) -
{
Ii J
n
{
2
}.
n
{
3
}
...
{
I
n
}
where a() = degree of similarity of methods Mi and
{
I{
}
=
set
of instance variables used by method Mj.
The degree of similarity of methods
engineering,
(i.e.,
relates both to the
conventional notion of cohesion in software
keeping related things together) as well as encapsulation of objects, that
bundling of methods and instance variables in an object.
be defined to be a major aspect of object cohesiveness.
is,
the
The degree of similarity of methods can
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
Complexity of an object. Bunge defines complexity of an individual to be the "numerosity of
composition", implying that a complex individual has a large number of properties
Using
its
set
this definition as a base, the
I
I,
[4, p. 43].
complexity of an object can be defined to be the cardinality of
of properties.
Complexity of <x, p(x)> = p(x)
its
where p(x)
I
I
is
the cardinality of p(x).
8
Scope of Properties. The scope of
P
a property
of objects)
G
(P; J)
of
the set of all objects possessing all properties in g.
In
in J (a set
is
the subset
objects possessing the property (27].
G(P;
Class
A
J)
=
x
(
Qp;
J)
I
x
=
e
^ all
P with respect
class
simple terms, a class
and P 6 p(x)
J
P
G(P)
I
I
},
Pe
where p(x)
g()
to a property set g
is
is
)
where
is
the set of all properties of x e
g() is a
common
a set of objects that have
J.
given set of properties. 4
The
properties.
inheritance hierarchy, a
directed acyclic graph will be described as a tree structure with classes as nodes, leaves and a root.
In
any design application, there can be many possible hierarchies of classes. Design choices on the
hierarchy employed to represent the application are essentially choices about restricting or
expanding the scope of properties of the objects
relate to the inheritance hierarchy
objects and the
number of children of the
a
node of a
Two design
decisions which
can be defined. They are depth of inheritance of
a class of
class.
Depth of Inheritance = height of the class
The height of
in the application.
in the inheritance tree
tree refers to the length of the
maximal path from
the
node
to the root of
the tree.
Number
of Children
= Number of immediate descendants of the
Both these concepts relate to the notion of scope of properties,
i.e.,
how
class
far
does the influence of a
property extend? Depth of inheritance indicates the extent to which the class
properties of
its
ancestors and
number of
only through message passing. 5
influenced by the
children indicates the potential impact on descendants.
The depth of inheritance and number of children
Methods as measures of communication.
is
collectively indicate the
genealogy of a
In the object oriented approach, objects
A message can cause an object to
"behave"
can communicate
in a particular
by invoking a particular method. Methods can be viewed as definitions of responses
messages
[1].
following
manner
It is
manner
to possible
reasonable, therefore, to define a response set for a class of objects in the
Response set of a class of objects =
message to an object of the class
4
class.
ln strict ontological terms,
n
^j p
{
G(P)
I
P e
{
set
of
all
methods
that
can be invoked
g() )is the definition of a "kind", bui
is
used here
in response to a
to define the
concept of
i
class.
'While objects can communicate through more complex mechanisms like bulletin boards, the majority of
employ message passing as the only mechanism for communicating between objects.
OO
designers
9
Note
that this set will include
methods outside the
may call methods from other classes. The
are finite and there are a finite
response set will be
number of classes
methods within
the class
finite since the properties
of a class
class as well, since
in a design.
Metrics Evaluation Criteria
recommended
Several researchers have
properties that software metrics should possess to increase
For example, Basili and Reiter suggest that metrics should be sensitive
to
externally observable differences in the development environment and
must also correspond
to
intuitive notions about the characteristic differences
artifacts
their usefulness.
[2].
The majority of recommended
between the software
properties are qualitative in nature
being measured
and consequently, most
proposals for metrics have tended to be informal in their evaluation of metrics.
More
Weyuker developed
recently however,
a formal
list
of desiderata for software metrics and
Two
has evaluated a number of existing software metrics using these properties [31]. 6
Weyuker's nine properties are rudimentary
number of cases having
the
measured object changes,
met by
all
is that
same complexity metric and
the other is that
the metric should remain unchanged.
when
the
finite
name of
Both these properties are
the
typically
permutation of elements within the object being measured must change the
metric value. The intent
if-then-else blocks
by an
is
to
ensure that metric values change, for example, in case the nesting of
change due to permutation of program statements.
Chemiavsky and Smith
property were to be
seems
is
changed, which seems
at
odds with
OO design.
specifically suggest that this property is not appropriate for
because "the rationales used
this property
If this
OOD complexity metric, values for a class will change when the order of declaration
of methods or instance variables
remaining
one requires that there are only a
metrics and will not be considered in this paper. 7
Another property
satisfied
in nature;
of
to be
may
based
be applicable only to traditional programming"
strictly in the traditional
six properties are repeated
paradigm,
it
is
And,
in fact,
OOD metrics
[6, p. 638].
Since
not considered further. The
below. 8
^Weyuker's properties are not without criticism (e.g.. [11, 6. 9, 331, *nd some of thes* critiques will be discussed below.
HoweveT, her list remains the currently most widely used list of such criteria, and therefore is the list chosen for this
evaluation.
'Since class libraries have a finite number of classes, no metric value can be repeated
depends on the name of an object, the second pr operty is also easily met.
infinitely.
And, unless the metric
'Readers familiar with Weyuker's work should note that the exclusion of these three properties makes the property numbers
used here no longer consistent with the original property numbers. It should also be noted that Weyuker's definitions have
been modified where necessary to use the term object rather than program.
10
Property
I
:
Non-coarseness
Given an object P and a metric
p.
another object
Q can
always be found such
that: u,(P)
This implies that not every object can have the same value for a metric, otherwise
it
*
u,(Q).
has lost
its
value as a measurement.
Property 2: Non-uniqueness motion of equivalence)
There can exist distinct objects P and
have the same metric value,
i.e.,
the
Q
such that
u.(P)
=
|i(Q).
This implies that two objects can
two objects are equally complex.
Property 3: Design Implementation not function
is
important
Given two object designs, P and Q, which provide the same functionality, does not imply that
=
|i(Q).
The
intuition behind Property 3 is that
u.(P)
even though two object designs perform the same
function, the details of the design matter in determining the object design's metric.
Property 4: Monotonicity
For
all
objects
P and Q,
the following
implies concatenation of
P and Q.
9
must hold: n(P)
<,
|i(P+Q) and u,(Q) < ^(P+Q) where
P+
Q
This implies that the metric for the combination of two objects
can never be less than the metric for either of the component objects.
Property 5: Non-equivalence of interaction
3 P, 3 Q, 3 R, such that
u(P) = u.(Q) does not imply that u.(P+R)
= ^(Q+R).
This suggests that interaction between P and
resulting in different complexity values for
R
can be different than interaction between
Q and R
P+R and Q+R.
Property 6: Interaction increases complexity
3 P and 3
u.(
Q such thac
P) + uXQ)
<: ^i(
P+Q)
Designers' empirical operations of combining two objects in order to achieve belter representation are formally denoted
shown with a + sign. Concatenation results in a single joint stale space of instance variables and
methods instead of two separate slate spaces, the only definite result of concatenation of two objects is the elimination of
here as concatenation and
all
prior
messages between
ihe
two component objects.
11
The
principle behind this property
is
that
when two
objects are combined, the interaction between
objects will tend to increase the complexity metric value.
Some
Assumptions.
basic assumptions
made regarding
the distribution of
methods and instance
variables in the discussions for each of the metric properties.
Assumption
Let
X
1:
= The number of methods
in a given class
i.
Y = The number of methods called from a given method
Z = The number of instance
variables used by a
C = The number of couplings
Xj, Yi, Zi,
Q
i.
i.
between a given class of objects
random
are discrete
method
variables each characterized
i
and
(i.i.d.).
:
finite
number of
methods
"identical"
combination of the two classes into one class would result in one
identical
The same
is
true
and Qs.
Assumption 2 In general, two classes can have a
that a
other classes.
by some general distribution
function. Further, all the Xjs are independent and identically distributed
for all the Yis, Zis
all
in the sense
class's version
of the
there is a root, several intermediate nodes
which
methods becoming redundant.
Assumption 3 The inheritance
:
The
have siblings, and leaves.
necessarily have the
tree is "full",
i.e.,
tree is not necessarily balanced, i.e.,
each node does not
same number of children.
Empirical Data Collection
As defined
a design encompasses the implicit ideas designers have about complexity.
earlier,
These viewpoints are the empirical relations Ri, R2,
D.
The viewpoints
that
were used
...
Rn
in the
formal definition of the design
in constructing the metrics presented in this
paper were gathered
from extensive collaboration with a highly experienced team of software engineers from a software
development organization. This organization has used
the past five years.
Though
C++, the research aim was
data were collected at
two
The metrics proposed
research at
is
development language for
to propose metrics that
sites
in this
which used
company
class libraries.
all projects at this site
were language independent As a
test
of
was
this,
different languages.
paper were collected using automated tools developed for this
two different organizations which
a software
C++
the primary
OOD in more than four large projects over
that uses
will
be referred to here as Site
A and Site B.
Site
A
OOD in their development work and has a collection of different
Metrics data from 634 classes from two class libraries that are used in the
12
design of graphical user interfaces (GUI) were collected. These two class libraries are written
C++
and are typically used
language programs
Site
B
A
conjunction with other
in
development of software sold
to
UNIX
C++
libraries
workstation users.
developing flexible machine control and manufacturing systems.
producnon of VLSI
Metrics were collected on the
implementation of a computer aided manufacturing system
class libraries used in the
circuits.
Over 30 engineers worked on
from
Site
B were
for the
this application, after extensive training
and experience with object orientation and the Smalltalk environment
classes
and traditional C-
semiconductor manufacturer and uses the Smalltalk programming language for
a
is
in the
at Site
in
Metrics data from 1459
collected-
Results
Metric
1:
Weighted Methods Per Class
Definition. Consider a Class Ci, with
the methods.
Then
(WMC)
methods
Ml,...
Mn
.
Let
CI,...
c n be the complexity 10 of
:
n
WMC = X
c
i
1=1
If all
method complexities are considered
Theoretical basis.
methods
WMC relates directly
are properties of class objects
properties.
to be unity, then
The number of methods
attributes of a class, since attributes
to
Bunge's definition of complexity of a thing, since
and complexity
is,
WMC = n, the number of methods.
therefore, a
is
determined by the cardinality of its
measure of class definition as well
set of
as being
correspond to properties.
Viewpoints.
•
The number of methods and
time and effort
•
The
is
larger the
the complexity of methods involved
is
an indicator of
how much
required to develop and maintain the class.
number of methods
children will inherit
all
the
in a class the greater the potential
methods defined
10 Complexity
impact on children, since
in the class.
u deliberately not defined more specifically here in order to allow for the mo»t general application of thii
can be argued that developer* approach the task of writing a method as they would a traditional program, and
therefore some traditional static complexity metric, such as McCabe's Cyclomahc number, may be appropriate. This is left
as an implementation decision, as the general applicability of any existing static complexity metric has not been generally
agreed upon. The general nature of the
metric is presented as a strength, not a weakness as has been suggested
metric.
It
WMC
elsewhere
(
121.
13
Classes with large numbers of methods are likely to be more application specific, limiting the
•
possibility of reuse.
Analytical Evaluation of Weighted
From assumption
1,
the
Methods Per Class (WMC)
number of methods
that there is a finite probability that
Similarly, there
number of methods
is
ji(Q)
=
n(P+Q) ^
n,
|i(P)
H(P+R) = n +
(3
r
R
methods
-
3
a
R
|i(P)
*
Q are
M-(R)-
this implies
i.i.d.,
\i(Q), therefore property
such that n(P) =
object does not define the
is satisfied.
and |i(P+Q) >
and 3 an object
assumption 2) and
such that
class
is satisfied.
1
Therefore property 2
number of methods
in a class.
is
The choice
a design implementation decision and independent of the functionality of
the class, therefore Property 3
Clearly,
Q
a finite probability that
The function of the
satisfied.
the
is
3
P and another
in class
such that
in
Let n(P) = np and n(Q) = nq, then |i(P+Q) = n p + n Q-
p.(Q), thereby satisfying Property 4.
it
common
has a number of methods d in
with P. Let |i(R)
=
Now,
common
let |i(P)
with
Q
=
n,
(as per
r.
p
H(Q+R) = n + r - 3
n(P+Q) * M-(Q+R) and Property 5 is satisfied. For any two objects P and Q, p.(P+Q) =
np + nQ - 8, where np is the number of methods in P, nQ is number of methods in Q and P and Q
therefore
have d methods
+
(J.(Q) for all
in
common.
P and
Clearly,
np + nQ - 8 < np + nQ
Q. Therefore, Property 6
is
for all
P and
not satisfied.
Empirical Data
The histograms and summary
300
statistics
from both
r
sites are
1000
200
100
d=D^
55
WMC
Site
A
110
-
shown below:
Q i.e.,
M-(
p+ Q) ^
M-(P)
14
Site
15
must
properties the object
inherit in order to
inheritance is design implementation dependent,
When any two
assumed
objects
P and
Q
i)
P and
If
ii)
P and
=
|i(Q)
P
maintains
=
Property 4
is satisfied.
x,
can be shown thai Property 5
will
its
the tree,
one
is satisfied.
is
:
i)
P and
Q
are siblings
ii)
P and
Q
it is
are neither
the child of the other.
n, i.e.
Property 4
is satisfied.
be equal
to
Max(n
is
p
Q cannot inherit methods from X, however if P+Q moves
inheritance.
n(Q) = y and y >
case, n(P)
and p.(P+Q)
iii)
= n and M-(P+Q) =
P+Q moves to P's location in
*It
words, depth of
Q are neither children nor siblings of each other.
to Q's location,
1
In other
Q are siblings
In this case, |i(P)
Case
and Property 3
no multiple inheritance 11 )
that there is
function.
its
are combined, there are three possible cases (in all cases,
children nor siblings of each other and
Case
perform
x.
satisfied
-hiq).
Therefore,
^i(P+Q) =
y, i.e.,
P+Q
^i(P+Q) >
even with multiple inheritance.
Consequendy u(P+Q)
will
will be in Q's old location.
u.(P)
ti(P)
and ^(P+Q) =
and M-(Q)
will
be n
always be greater than ot equal
to
p
|i
In this
(Q) and
and i1q respectively
u(P) and u(Q).
16
in)
when one
is
a child of the
In this case, u.(P)
=
other
n, p.(Q)
= n +
1,
but
H(P+Q) =
n, i.e.
|i(P+Q) <
(Q)-
M-
Property 4
is
not
satisfied.
For
all
three cases, let
P and Q' be
siblings,
|i(P+R) = n and |i(Q'+R) = n +
1. i.e.,
For any two objects P and Q,
P+ Q) =
Property 6
is
[i(
i.e.
|i(P+R)
p.(P)
= n(Q')=
n,
and
let
R
not equal to |o.(Q'+R).
is
be a child of
Property 5
P.
Then
is satisfied.
n(P) or = n(Q). Therefore, |i(P+Q) < ^i(P) + n(Q),
i.e.,
not satisfied.
Empirical Data
The histograms and summary
statistics
from both
sites are
shown below
(all
integers):
250
200
400
+
300
--
200
-
150
100
100
50
|l
0.0
3.9
DIT
Site
n
" -
n-
|_
7.8
5.0
0.0
DIT
A
Site
B
Histograms for the DIT metric
metric values are
17
Site
18
•
The number of children gives an idea of
class has a large
number
of children,
Analytical Evaluation of Number
Let P and
R
property
is
1
be leaves.
satisfied.
|i(P)
=
it
may
more
require
u.(R)
=
0, let
Q
be the root ^(Q) >
is
Therefore. Property 3
Q
Let P and
ng,).
all
-
Combining P and Q,
P and
child of
all
np + ng
have (n-1) +
r
Q with
|i(P)
Q
where d
-d
p.(P-i-R)
Property 6
the
is
n
the design implementation of the class.
in
common.
with np +
Clearly, d
> ng. This can be written
is
if
is
The
-
np or ng
|i(P)
Q each
* (i(Q+R). Therefore Property
5
Q
and
is
the
Now, np +
is 0.
and |!(P+Q) ^ H(Q) for
R be a
P and R will
have n children and
class obtained by
combining
= np and |i(Q) =
d sub-classes, where d
either
p.(P+Q) >
Let P and
satisfied.
n(P) = n = \i(Q).
as:
ng
|i(P)
(i.e.,
R
is satisfied.
combining
will
have n +
r children,
Given any two classes P
children respectively, the following relationship holds:
= n p and ^(Q) =
is
have
r children.
np and ng
H(P+Q) =
u(P) * ^i(Q) therefore
0.
the sub-classing for the class.
i.e.,
sub-classes respectively
children, whereas a class obtained by
which means that
and
ng
will yield a single class
Q. Therefore, Property 4
P which has
upon
therefore dependent
be two classes with np and
d > np and
in that class.
is satisfied.
number of children P and
ng
a
also satisfied. Design of a class involves
decisions on the scope of the methods declared within the class,
is
methods
testing of the
If
Of Children (NOC)
Since |!(R) = n(P), Property 2
The number of sub-classes
on the design.
the potential influence a class has
ng
p + ng - 3
number of common
children.
Therefore, M.(P+Q)
^ H(P) +
not satisfied.
Empirical Data
The histograms and summary
statistics
from both
sites are
shown below:
M-(Q) for a11
p
^d
Q-
19
600
r
400 -•
200
-
1500
t
1000
-
500
L
22
NOC
Site
A
26
44
NX
Site
B
52
20
order to improve modularity and promote encapsuladon. inter-object couples should be kept to
•
In
a
minimum. The
larger the
number of
couples, the higher the sensitivity to changes in other pans
of the design and therefore maintenance
•
A measure
of coupling
are likely to be.
is
is
more
useful to determine
The higher
difficult.
how complex
the inter-object coupling, the
Analytical Evaluation of Coupling Between Objects
As
per assumption
there exist objects P,
1,
thereby satisfying properties
1
and
2.
Q
and R such that
|i(P)
Inter-object coupling occurs
i.e.,
* n(Q) and
when methods
u,(P)
=
u.(R)
of one object
coupling depends on the manner
in
which
and not on the functionality provided by P. Therefore Property 3 is
Let P and Q be any two objects with u.(P) = np and n(Q) = nq. If P and Q are
combined, the resulting object will have np + t\q
reduced due
to the
combination. That
methods of P and Q. Clearly, np
greater than the original
i.e.,
testing needs to be.
are designed
satisfied.
3 >
all
P and
Q and
for all
P and
Q
-
d > np for
np + nq
-
d>
nq
-
is
-
d couples, where d
u,(P+Q) = np
and
nq
-
9 >
+
i\q
-
d,
is
where d
the
is
number of couples
some function of
the
since the reduction in couples cannot be
number of couples. Therefore,
t\q
np +
more ngorous the
pans of a design
(CBO)
use methods or instance variables of another object,
methods
the testing of various
^ H(Q) for all P and Q. Thus, Property 4 is satisfied. Let P and
= ji(Q) = n and let R be another object with M-(R) = r.
u.(P+Q) > M-(P) and u.(P+Q)
Q be two objects such
H(P+Q) = n +
r
u.(Q+R) = n +
r
Given
that
-
-
that u.(P)
,
3, similarly
B
d and B are independent functions, they
will not be equal,
u.(Q+R), satisfying Property 5. For any two objects P and Q, |i(P+Q)
u,(P+Q) = H(P) + ti(Q)
u.(P+-Q)
£ n(P) + n(Q)
Therefore Property 6
is
-
3 which implies
for all
P and Q.
not satisfied.
that
i.e.,
p.(P+R)
= np + nq
-
is
9.
not equal to
21
Empirical Data
The histograms and summary
600
t
400
-
200
-
statistics
from both
sites are
800
tb-
-
shown below:
22
Metric 5: Response For a Class
RFC
Definition.
=
Theoretical basis.
RS =
I
l
RFC)
RS where RS
is
I
The response
the response set for the class.
set for the class
as:
{M}UaUi{Ri)
where
Rj
(
The response
attributes of
}
=
set
of methods called by method
set is a set of
methods available
an object. Since
it
i
and
M
{
to the object
specifically includes
measure of communication between
also a
can be expressed
}
and
=
set
its
of
all
methods
cardinality
in the class
a measure of the
is
methods called from outside
the object,
it
is
objects.
Viewpoints.
•
If
number of methods can
a large
of the class
the
•
pan of
The
be invoked in response to a message, the testing and debugging
becomes more complicated
since
requires a greater level of understanding required on
it
the tester.
larger the
number of methods
that
can be invoked from an class, the greater the complexity of
the class.
•
A
worst case value for possible responses will assist in appropriate allocation of testing time.
Analytical Evaluation of Response for a Class
Let
Xp
Xp = RPC for class P
Xq = RFC for class Q.
and
Xq
are functions of the
respectively.
that
i.i.d.)
It
|i(P)
=
Xp and Xq are i.i.d.
is satisfied.
Let
have no
np + nQ.
Q
have any
Q
to
common
common methods
2) In the
is
Since the choice of methods
class, the
methods. Clearly
,
RFC
Q
is
of P = np and
P and
Q
variables are also
Q
such that
Q
|J.(P)
*
such that
a design decision.
RFC
of
Q
= nQ.
If
response for that class will depend on
there are
two possible
and therefore the combined class P +
second case, P and
random
a finite probability that 3 a
is
be two classes with
form one
i.i.d.
a finite probability that 3 a
being satisfied. Also there
P and
the external coupling of
(since functions of
Therefore, there
two classes are combined
whether P and
Q
1
1
u.(Q), therefore property 2 is satisfied.
Property 3
these
number of methods and
follows from assumption
u.(Q) resulting in property
and
(RFC)
have methods
in
cases: 1)
when P
Q will have a response set =
common, and
the response set will
23
smaller than rip
+
Mathematically, u.(P + Q) =
riQ.
methods of P and Q. Clearly, np +
u(P+Q) >
Let
P and
u.(P)
and > \i(Q) for
all
Q be two objects such
riQ
-
|j.(P)
+
riQ
-
3 > np and np + t\q
P and Q.
that
rip
=
d,
-
= n and
,
let
R
is
d > nr\ for
Therefore, Property 4
u.(Q)
where d
is
some
all
function of the
possible
P and Q.
satisfied.
be another object with
u.(R)
=
r.
u,(P+Q) = n + r - 3, similarly
u.(Q+R) = n + r - Q
Given
that
d and B are independent functions, they will not be equal,
|i(Q+R), satisfying Property
H(P+Q) =
^i(P+Q) <
^i(P)
^i(P)
5.
is
p.(P+R)
For any two objects P and Q, M-(P+Q) = np +
+ n(Q) - 9 which implies
+ [i(Q) for all P and Q.
Therefore Property 6
i.e.,
nq
-
is
3.
that
not satisfied.
Empirical Dam
The histograms and summary
300
statistics
from both
sites are
+
500
200
100
shown below:
-r
400
-
-
300
--
200
-•
100
-
m-h
fthn,.
60
210
120
rTv
rT\^
Site
A
Site
Histograms for the
Site
RFC
metric
B
420
not equal to
24
potenoal invocation of methods. This reinforces the argument that a small number of classes
be responsible for a large number of the methods that executed
effort
were concentrated on these outlier classes,
in
a bulk of the
an application, and that
dynamic behavior of
if
may
testing
the object
oriented systems can be checked for customer acceptance.
Another
interesting aspect is the difference in values for
mean, median and
maximum
possible hypothesis
may
Smalltalk and C++.
C++ on
Smalltalk.
RFC
values of
B has
the other hand,
necessitates extensive
is
that
=
LCOM =
(
(I^Ij)
IPI - IQI,
=
n
Ij
*
=
memory
usage of message passing
intensive and requires periodic garbage
to object
oriented principles in Smalltalk
{a,b,e}
n methods
Mi,
M2-...
are n such sets (Ii),... {I n
Mn
}.
Let
.
(Ij)
P=
Let
(
=
set of instance
(Ij Ij)
I
Ii
n
Ij
-
)
iflPI>IOJ
C
with three methods Mi,
and {13} = {x,y,z}.
LCOM
is
the
{11}
n
number of
{12}
is
M2
and M3. Let (11} =
non-empty, but
null intersections
-
{
1 1
n
}
{13}
(a,b,c,d,e)
and
number of non-empty
{12}
n
and
{13}
intersections,
is 1.
two methods
in class
a()={Ii}n{I 2
The
to object
message passing through method invocation.
Theoretical basis. This uses the notion of degree of similarity of methods.
for
provided by
otherwise
are null sets and
which
provided by
facilities
)
Example: Consider a class
{12}
One
(LCOM)
Ci with
method Mj. There
Ii
I
that the
A.
at Site
method invocation, whereas C++'s incremental approach
Definition. Consider a Class
Q
is
complete adherence
Metric 6: Lack of Cohesion in Methods
and
values
memory management
deter, at the design phase, the
orientation gives designers alternatives to
variables used by
and B. Note
does not provide automatic garbage collection mechanisms for
through method invocation, since this
Another possibility
RFC
memory management
the benefit of automatic
memory management. This could
collection.
A
between Site
are higher than the
relate to the differences in the
Site
RFC
larger the
Ci
given by:
)
number of
traditional notions of
is
similar methods, the
more cohesive
the class,
which
is
consistent with
cohesion that measure the inter relatedness between portions of a program.
none of the methods of a class display any instance behavior,
variables, they have
The degree of similarity
no similarity and the
i.e.
do not use any
LCOM value for the class will be zero.
The
If
instance
LCOM value
25
provides a measure for the disparate nature of methods
A
in the class.
number of disjoint
smaller
pairs (elements of set P) implies greater similarity of methods.
LCOM
instance variables and methods of an object, and therefore
measure of the attributes of an
a
is
is
intimately tied to the
object.
Viewpoints.
•
Cohesiveness of methods within a class
•
Lack of cohesion
•
Any measure
is
desirable, since
it
promotes encapsulation.
implies classes should probably be split into
two or more sub-classes.
of disparateness of methods helps identify flaws in the design of classes.
• Low cohesion increases complexity, thereby increasing the likelihood of errors during the
development process.
Analytical Evaluation of Lack
Let
Of Cohesion Of Methods (LCOM)
Xp = LCOM for class P
Xq = LCOM for class Q.
Xp
and
Xq
are functions of the
respectively.
i.i.d.)
that
It
follows from assumption
Xp and Xq are i.i.d..
|i(Q) resulting in property
= n(Q),
u\(P)
is
=
t\q.
1
therefore property 2
is satisfied.
nq - d where 9
the
is
i.i.d.
random variables
a finite probability that 3 a
is
P and
Q
are also
such that (i(P)
a finite probability that 3 a
Q
Q such
*
that
Since the choice of methods and instance variables
is satisfied.
Let
Combining these two objects can
|i(P+Q) = np +
is
being satisfied. Also there
1
the instance variables of
(since functions of
Therefore, there
a design decision, Property 3
|i(Q)
number of methods and
P and
Q be any two objects
potentially reduce the
number of disjoint
sets
with n(P)
number of disjoint
= np and
sets,
i.e.,
reduced due to the combination of P
and Q. The reduction B is some function of the particular sets of instance variables of the two
objects P and Q. Now, np > d and t\q > 9 since the reduction in sets obviously cannot be greater
than the
number of original
Therefore, the following result holds:
np + nq-d^np
for all
P and
np + nq - 8 £ nq
for all
P and Q.
Property 4
Let
sets.
P and
Q and
is satisfied.
Q be two objects such that p.(P) = p.(Q) = n
|i(P+Q) = n + r
-
^(Q+R) = n +
-
r
3, similarly
B
,
and
let
R be another object with |i(R) = r.
Given
that
satisfying
3 and 6 arc independent functions, they will not be equal,
Propeny
For any two objects P and Q, |i(P+Q) = np + r\Q
5.
H(P+Q) =
p.(P)
+ |i(Q)
-
u(P+Q) <
|i(P)
+
for all
Therefore Property 6
mQ)
is
i.e.,
-
3.
|j.(P+R)
i.e.,
3 which implies that
P and Q.
not sarisfied.
Empirical Data
The histograms and summary
600
400
statistics
from both
-f-
sites arc
500
--
400
--
300
--
200
--
100
--
shown below:
-
200
-+-
0.0
-+-
67.5
135.0
1 CP-
+
0.00
202.5
LCOM
Site
LCOM
A
Site
Histograms for the
Site
LCOM
metric
B
5.25
* |i(Q+R),
27
A
high
LCOM value indicates disparateness in the functionality provided by the class.
can be used to identify classes that are attempting to achieve
many
This metric
different objectives,
and
consequently behave in less predictable ways than classes. Such classes could be more error prone
and more
difficult to test
and could possibly be broken up into two or more classes
well defined in their behavior.
The
LCOM
that are
metric can be used by senior designers and project
managers as a relatively simple way
to track
design of an application and advise
necessary, at an earlier phase in the design cycle.
The Metrics Suite and Booch
The
six metrics
if
more
whether the cohesion principle
is
adhered to in the
OOD Steps
attempt to capture the three non-implementation steps in Booch's definition of
NOC directly relate to the layout of the class hierarchy, and WMC is an aspect of
the complexity of the class. This suggests that WMC, DIT and NOC relate to the object definition
OOD. DIT and
step in
OOD.
messages.
WMC
and
For example,
(since a potentially large
to capture the extent
methods external
if
RFC
a class has a large
number of methods can
how
the class
WMC or RFC,
execute).
The
it
is
has
"behaves"
many
when
it
gets
possible responses
CBO and RFC metrics also attempt
of communication between classes by counting the inter-object couples and
to a
given class. The table below summarizes the six metrics in relation to the
steps in Booch's definition of
Metric
attempt to capture
OOD.
28
considered, then
that metrics that fail to
not use these metrics
[33].
metrics
all six
meet
to, for
would
satisfy Property 6.
Zuse
s
analysis of Property 6 suggests
property cannot be used as a ratio scale, and therefore one could
this
example, demonstrate
that
one class
twice as complex as another
is
'3
Failing to meet Property 6 implies that a complexity metric could increase, rather than reduce,
object
in this
is
divided into more objects. Interestingly, the experienced
memory management and
study found that
difficult
when
was
complexity can increase
6
that
may
there are a large
number of
when
not be an essential feature for
The only other
violation of
than one of
its
This
is
children. In
an
OO designers who participated
run-time detection of errors are both more
objects to deal with.
objects are divided into
In other words, their viewpoint
more
objects. Therefore, Property
OO software design complexity metrics.
Weyuker's properties
is
DIT
for the single case of the
metric fails to satisfy Property 4 (monotonicity) only in cases where
child relationship.
if
metric.
two objects
The DIT
are in a parent-
because the distance from the root of a parent cannot become greater
all
other cases, the
DIT
metric satisfies Property
4. 14
Concluding Remarks
This research has developed and implemented a
new
set
of software metrics for
OO design.
These
OO
metrics are based in measurement theory and also reflect the viewpoints of experienced
software developers. In evaluating these metrics against a set of standard criteria, they are found to
both (a) possess a number of desirable properties, and (b) suggest
approach
may
approaches.
differ in terms
Clearly,
some
some ways
in
which
the
OO
of desirable or necessary design features from more traditional
future research designed to further investigate these apparent
differences seems warranted.
In addition to the proposal
and analytic
test
of theoretically grounded metrics, this paper has also
presented empirical data on these metrics from actual commercial systems.
independence of these metrics
is
demonstrated
in
pan through data
The implementation
collection from both
C++
and
Smalltalk implementations, two of the most widely used object oriented environments. These data
are used to demonstrate not only the feasibility of data collection, but also to suggest
which these metrics might be used by managers.
valid measurements,
'•'Property 6
14 It
is
is
In addition to the usual benefits obtained
in
from
OO design metrics should offer needed insights into whether developers are
ihe only property lhal requires ratio scales.
interesting to note that other authors
Weyuker's.
ways
For example, see (11].
have also observed
difficulties in
applying this particular property of
29
following
00 principles in their designs.
that a significant percentage of classes
via inheritance. This use of metrics
For example,
in the results
were not benefiting from
may
be an especially
process of migrating their staffs toward the adoption of
presented here
it
was shown
the potential reuse opportunities
critical
one as organizations begin the
00 principles.
who may
Collectively, the suite provides senior designers and managers,
not be completely
familiar with the design details of an application, with an indication of the integrity of the design.
They can use
application.
it
By
as a vehicle to address the architectural
and structural consistency of the entire
may
using the metrics suite they can identify areas of the application that
more rigorous
testing
potential flaws
and other leverage points
and areas
that
should be redesigned.
in the
Using the metrics in
this
require
manner,
design can be identified and dealt with earlier in the
design-develop-test-maintenance cycle of an application. Yet another benefit of using these metrics
is
the
added insight gained about trade-offs made by designers between conflicting requirements
such as increased reuse (via more inheritance) and ease of testing (via a less complicated
inheritance hierarchy).
OO
Since there are typically
many
possible
one
that is
most appropriate to the goals of the
application, these metrics can help in selecting
designs for the same
organization, such as reducing the cost of development, testing and maintenance over the life of the
application.
Thit-set of six proposed metrics
metrics for
OOD. By
Weyuker's evaluation
on commercial
is
presented as the
first
empirically validated proposal for formal
bringing together the rigor of measurement theory, Bunge's ontology,
criteria
and empirical data from professional software developers working
projects, this paper seeks to
demonstrate the level of rigor required in the
development of usable metrics for design of software systems. Of course, there
believe that the proposed metrics will be found to be comprehensive, and further
in additions,
changes and possible deletions from
for all three of Booch's steps for
groundwork
OOD
this suite.
and, at a
no reason
work could
to
result
However, they do provide coverage
minimum,
for a formal language to describe metrics for
is
this
OOD.
metrics suite should lay the
In addition, these metrics
also serve as a generalized solution for other researchers to rely
on when seeking
to
may
develop
specialized metrics for particular purposes or customized environments.
It is
often noted that
moving
00 may hold some of the solutions to the software crisis.
Further research in
00 development management towards a strong theoretical base should provide a basis for
significant future progress.
30
Bibliography
1]
[
m
J. et al., "Data Model Issues tor Object Oriented Applications",
Information Systems, vol. 5, pp. 3-26, 1987.
Banerjee,
()fflce
ACM
Transactions
[2] Basili. V. and Reiter, R., Evaluating Automatable Measures of Software Models, IEEE
Workshop on Quantitative Software Models, 1979, Kiamesha, NY, pp. 107-1 16.
Booch, G., Object Oriented
[3]
CA:Benjarnin/Cummings, 1991.
Design
Bungc, M., Treatise on Basic Philosophy
Boston:Riedel, 1977.
[4]
:
Bunge, M., Treatise on Basic Philosophy
Boston:Riedel, 1979.
[5]
[6]
Chemiavsky,
Measures",
IEEE
Applications,
with
Ontology
:
I
Ontology
:
Redwood
The Furniture of
II
:
City,
the World,
The World of Systems,
J.C. and Smith, C.H., "On Weyuker's Axioms for Software Complexity
Transactions on Software Engineering, vol. 17, pp. 636-638, 1991.
[7] Chemiavsky, V. and Lakhuty, D.G., "On The Problem of Information System Evaluation",
Automatic Documentation and Mathematical Linguistics, vol. 4, pp. 9-26, 1971.
[8] Chidamber, S.R. and Kemerer, C.F., Towards a Metrics Suite for Object Oriented Design,
Proc. of the 6th
Conference on Object Oriented Programming, Systems, Languages and
Applications (OOPSLA), 1991, Phoenix, AZ, pp. 197-211.
ACM
Fenton, N., "When a software measure
pp. 357-362, September 1992.
[9]
is
not a measure". Software Engineering Journal, vol.
Fichman, R. and Kemerer, C, "Object-Oriented and Conventional Analysis and Design
Methodologies: Comparison and Critique", IEEE Computer, vol. 25, pp. 20-39, October 1992.
[10]
[11] Harrison, W., "Software Science and Weyuker's Fifth Property", University of Portland
Computer Science Department Internal Report 1988.
Object-Oriented Systems Development, 26th
Annual Hawaii International Conference on System Science, 1993, Maui, Hawaii, pp. 759-768.
[12] Kalakota, R. et al..
[13] Kaposi, A.A.,
The Role of Complexity
Measurement Theory,
in
in
McDermid,
J.
ed..
Software Engineer's Reference
Book, Oxford: Butterworth-Heinemann Ltd., 1991.
[14] Kearney, J.K. et al., "Software
vol. 29, pp.
Complexity Measurement", Communications of the
ACM,
1044-1050, 1986.
Kemerer, C.F., "Reliability of Function Points Measurement:
Communications of the ACM, vol. 36, pp. 85-97, February 1993.
[15]
A
Field Experiment",
"Cognitive Processes in Logical Design: Comparing Object-Oriented
and Traditional Functional Decomposition Software Methodologies", Carnegie Mellon University
Graduate School of Industrial Administration working paper 1991.
[
16]
Kim.
J.
and Lerch,
J.F.,
31
[17] Kriz, J., Facts and Artifacts in Social Science: An Epistemological and methodological
analysis of empirical social science techniques. New York:McGraw Hill, 1988.
[18] Lieberherr, K. et al.. Object Oriented
Annual
Programming
:
An
Objective Sense of Style, Third
ACM Conference on Object Oriented Programming Systems, Languages and Applications
(OOPSLA), 1988,
pp. 323-334.
[19] Moreau, D.R. and Dominick, W.D., "Object Oriented Graphical Information Systems:
Research Plan and Evaluation Metrics", Journal of Systems and Software, vol. 10, pp. 23-28,
1989.
[20] Morris, K., Metrics for Object Oriented Software Development,
Masters thesis, 1988.
[21] Parsons, J. and
University of British
Wand,
Y., "Object-Oriented Systems Analysis:
Columbia Working Paper January 1993.
A
M.I.T. Sloan School
Representational View",
[22] Pfleeger, S.L. and Palmer, J.D., Software Estimation for Object-Oriented Systems, 1990
International Function Point Users Group Fall Conference, 1990, San Antonio, Texas, pp. 181196.
[23] Prather, R.E., "An Axiomatic
vol. 27, pp. 340-346, 1984.
[24] Roberts, F.,
Theory of Software Complexity Measures", Computer Journal,
Encyclopedia of Mathematics and
its
Applications, Addison Wesley Publishing
Company, 1979.
[25] Sheetz, S.D. et al.,
"Measuring Object-Oriented System Complexity", University of Colorado
Working Paper 1992.
[26] Vessey, I. and Weber, R., "Research on Structured Programming: An Empiricist's
Evaluation", IEEE Transactions on Software Engineering, vol. SE-10, pp. 394-407, 1984.
A
Proposal for a Formal Model of Objects, in Kim, W. and Lochovsky, F. ed.,
[27] Wand, Y.,
Object-Oriented Concepts, Databases and Applications, Reading, MA: Addison- Wesley, 1989.
[28]
Wand, Y. and Weber,
[29]
Wand, Y. and Weber,
An
Ontological Evaluation of Systems Analysis and Design
Methods, in Falkenberg, EI), and Lindgreen, P. ed., Information Systems Concepts: An In-depth
Analysis, Amsterdam: Elsevier Science Publishers, 1989.
R.,
R.,
"An
Ontological
Transactions on Software Engineering, vol. 16, pp.
[30]
Wand, Y. and Weber,
R.,
Model of an Information System", IEEE
1282-1292, November 1990.
Toward A Theory Of The Deep
Structure
Of Information
Systems,
International Conference on Information Systems, 1990, Copenhagen, Denmark, pp. 61-71.
[31] Weyuker, E., "Evaluating Software Complexity Measures",
Engineering, vol. 14, pp. 1357-1365, September 1988.
IEEE Transactions on Software
[32] Whirmire, S., Measuring Complexity in Object-Oriented Software, Third International
Conference on Applications of Software Measurement, 1992, La Jolla, California.
[33] Zuse, H., "Properties of
December 1992.
Software Measures", Software Quality Journal, vol.
1,
pp. 225-260,
Date D ue
S£P-
•9
may 3
•}
1994
r,
'
1988
MIT LIBRARIES
3
TOflO
ODAMbZflO 3