IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
Short Notes
VOL. 32,
NO. 3,
MARCH 2006
______________________________________________________________________________________________________
Applicability of Weyuker’s Property 9
to Object Oriented Metrics
Naveen Sharma, Padmaja Joshi, and
Rushikesh K. Joshi
the property are also presented. An inheritance metric called
Number of Polymorphic Dispatches, which satisfies the property, is
introduced in Section 4. We bring out the practicality of this metric
by showing its usefulness in test case formulation.
2
Abstract—Weyuker’s Property 9 has received a mixed response regarding its
applicability to object oriented software metrics. Contrary to past beliefs, the
relevance of this property to object oriented systems is brought out. In support of
the new argument, counterexamples to earlier claims are formulated and two new
metrics highlighting a notion of complexity that is capturable through Property 9
are also presented.
Index Terms—Software metrics, object oriented design, Weyuker’s properties,
interaction complexity.
æ
1
209
INTRODUCTION
WEYUKER [6] proposed a set of axioms to evaluate software
complexity measures. There has been a mixed response from the
community on these axioms. Chidamber and Kemerer have
commented on the unsuitability of some of the axioms to object
oriented design metrics [3]. Questions have also been raised about
the consistency [4] of these axioms. Cherniavsky and Smith [2]
showed that the axioms are not sufficient. Property 9 has been the
most controversial property with respect to object oriented metrics.
The property tries to capture the complexity occurring due to
interaction during composition. It states that there exist compositions which result in complexity greater than the sum of the
complexities of individual components that are composed. In
Briand et al.’s version of the property, the > relation is changed to
the relation [1]. Chidamber and Kemerer name the property
Interaction increases complexity, which is misleading, as noted by
Gurusaran and Roy [5], since the original statement is not
universal. However, Gurusaran and Roy’s naming of the property,
viz. Interaction CAN increase complexity, is also misleading since it
does not imply existentiality, but only asserts permissibility.
Gurusaran and Roy [5] proposed a formalization of inheritance
based on a directed graph abstraction and concluded that Property 9
is not satisfied by any inheritance metrics. However, two counterexamples to their formalization were presented by Zhang and Xie
[7]. They gave an inheritance metric which satisfied Property 9.
However, they were not able to find any practical example for their
metric that satisfied Property 9. Despite all the debate, Weyuker’s
axioms still remain the most commonly used evaluation criteria for
software metrics.
In this paper, first, we attempt to show that most of the
controversial arguments have arisen out of interpretations and
then subsequently bring out the importance of Property 9 in
compositional paradigms. In the next two sections, various
arguments on the applicability of Property 9 to object oriented
metrics are discussed and examples supporting the applicability of
. The authors are with the Department of Computer Science and
Engineering, Indian Institute of Technology, Bombay, Powai, Mumbai400076, India. E-mail: {naveen, padmaja, rkj}@cse.iitb.ac.in.
Manuscript received 9 Dec. 2005; revised 6 Feb. 2006; accepted 9 Feb. 2006;
published online 17 Mar. 2006.
Recommended for acceptance by M. Harman.
For information on obtaining reprints of this article, please send e-mail to:
[email protected], and reference IEEECS Log Number TSE-0321-1205.
POINT OF VIEW OF COHESION
Property 9 essentially points out that interaction can occur during
composition, resulting in increased complexity. Let P and Q be two
programs and ðP QÞ represent composition of P and Q. Let ðpÞ
be the measure of complexity of program p with respect to a given
metric. For Property 9 to hold for the given metric, a case ðP Þ þ
ðQÞ < ðP QÞ should exist.
Although Weyuker’s examples of composition consisted of
simple concatenation, the scope of composition was extended to
include the merger of two classes in the CK suite [3] of Chidamber
and Kemerer. The definition of composition in the CK suite is
based on the ontology of Bunge. In their opinion, Property 9 may
not have a key role to play when evaluating object oriented
metrics. This argument is based on an observation that programmers experience an increase in complexity when a class is split into
many. Chidamber and Kemerer suggest that, since memory
management and runtime detection of errors become more
complex with an increased number of classes, the property may
not hold for composition of classes, which reduces the number of
classes.
However, contrary to this belief that Property 9 is not applicable
to the CK suite, we find that, within the scope of composition
considered by Chidamber and Kemerer, LCOM does satisfy
Property 9, capturing interaction arising due to composition. Lack
of COhesion in Methods (LCOM) is computed as the count of the
number of method pairs that do not share instance variables minus
the count of the method pairs with nonzero sharing. When this value
is negative, LCOM is taken to be zero. CK argued that, for any two
classes P and Q, LCOMðP þ QÞ ¼ LCOMðP Þ þ LCOMðQÞ c,
implying that the property is not satisfied. This observation is
valid for compositions that result in reduction of complexity rather
than increase. It indicates that a merger of two classes may be
cohesive if their instance variables are also merged. However, the
existence of more cohesive compositions cannot be treated as a
proof for Property 9 not holding for LCOM.
In fact, the applicability of Property 9 to object oriented metrics
also means that bad compositions are capturable through the
metric, in this case, LCOM. The example given in Fig. 1
demonstrates this view. We consider two classes, Acad and
Account, as shown in Fig. 1a. Class Acad deals with academics,
whereas class Account deals with fees. The function calFees
calculates fees to be paid by the student based on the category of
student, which is encoded in the roll number string. It can be noted
that LCOM values for classes Acad and Account are 1 and 0,
respectively.
However, in spite of the existence of a common attribute RollNo
and, hence, a possibility of its sharing, the composition of these
two classes does not result in a more cohesive unit. On merger, the
LCOM value of the composition shown in Fig. 1b is 4, which is
greater than the sum of their individual LCOM values. Thus,
LCOM satisfies Property 9, which says that interaction can increase
the complexity. This increase in LCOM value suggests that such a
merger should be avoided as it hampers good abstraction. In this
way, Property 9 may be seen as a scale to compare compositions.
0098-5589/06/$20.00 ß 2006 IEEE
Published by the IEEE Computer Society
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY BOMBAY. Downloaded on April 25, 2009 at 05:20 from IEEE Xplore. Restrictions apply.
210
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
VOL. 32,
NO. 3,
MARCH 2006
Fig. 3. NOPD satisfies Property 9.
Fig. 1. LCOM satisfies Property 9. (a) Before composition. (b) After composition.
before composition. However, after composition, the value of mult
for the composite A E becomes 1. Thus, metric mult satisfies
Property 9. This indicates that the composition has an added
complexity, where the complexity is captured through mult. In this
case, before composition, the two classes used single inheritance,
while the merged composite has to deal with an additional
complexity of resolving ambiguities arising out of multiple
inheritance.
4
Fig. 2. Inheritance example.
3
Point of View of Inheritance
The Chidamber and Kemerer argument on Property 9 not holding
in the case of OO metrics has also been the basis for a debate.
Initially, the argument was supported by Gurusaran and Roy [5],
who presented an argument that Property 9 cannot be satisfied by
any inheritance metric. They continued with the definitions and
assumptions used by Chidamber and Kemerer. They argue that a
class of metrics on a class of inheritance formulations do not satisfy
Property 9. In their graph formulation of an inheritance structure, a
cover property eliminates diamonds formed with three nodes.
Compositions that result in such diamonds are altered by deleting
relevant edges to be able to satisfy the cover property. For example,
a diamond with C1 inheriting C2 and C3 , and C3 inheriting C2 is
excluded. A measure with respect to a given vertex v in graph
fV ; Eg is the cardinality of S, where, S is a subset of V , v 2 S. They
argue that composition, which is the merger of vertices, cannot
satisfy Property 9 over this class of metrics. This argument was
later disproved by Zhang and Xie [7], who provided two
counterexamples containing diamonds satisfying the above cover
property and a valid measure that was shown to satisfy Property 9.
However, if inheritance is considered as a transitive relation, all
diamond formulations are ruled out, which makes the counterexamples of Zhang and Xie inapplicable.
The metric mult discussed below uses constraint-based constructors to define sets of objects. It serves as a counterexample to
Gurusaran and Roy’s formulation, even when all forms of
diamonds are eliminated. The counterexample is captured in
Fig. 2. The metric when applied to a vertex v is defined as
cardinality of the set of all those vertices that are reachable from v
and have an out-degree greater than 1. The metric counts the
number of classes that use multiple inheritance (of classes) in a
given inheritance structure in which v is the most derived leaf
class. It can be seen that the value of mult for classes A and E is 0
POLYMORPHISM AND INTERACTION COMPLEXITY
Inheritance and polymorphism is one compositional paradigm
through which interclass interactions take place. In this section, we
further explore the scope of composition to include inheritance
beyond simple concatenation of Weyuker and class merger
considered by Chidamber and Kemerer, Gurusaran and Roy, and
Zhang and Xie. A measure which is useful for testing is formulated
and is shown to satisfy Property 9. It is shown that a higher value
of this measure has implications on test case formulation.
The metric Number of Polymorphic Dispatches (NOPD) for a given
message m is defined as the count of all possible polymorphic
invocations of m over the given inheritance hierarchy. The
variations are possible since the same call (message) may be
generated through different combinations of variable (name) and
object (value) types. The combinations considered are those which
satisfy the rules of subtyping. For example, a variable x of type X
may be used to refer to an instance of type Y when Y is a subtype of
X. The assignment x = y is valid since Y is a subclass of X. In such a
situation, a statement x ! m, an invocation of method m through x
of type X will dispatch to method Y::m. Similarly, Y::m may also be
invoked through z ! m, where z is of type Z and Y is a subclass of
Z. As an example, consider a hierarchy of two classes, where class
C2 inherits class C1 . In this hierarchy, if m is implemented in both
the classes, the NOPD count for m is three. The reason is that m is
accessible on direct instances of both the classes and also as a
polymorphic dispatch on the subtype from a variable of the
supertype.
4.1
NOPD and Property 9
As shown in Fig. 3, consider a set of object structures S1 and S2. S1
contains two classes, a and b, where b is a subclass of a. S2 contains
just one class, c. NOPD values for message m1 in systems S1 and
S2 are 3 and 1, respectively. If the composition is such that class c is
made a subclass of class a, the number of polymorphic dispatches
of m1 in the composed system becomes five. Thus, the composition
S1 S2 has a value of NOPD which is greater than
NOP DðS1Þ þ NOP DðS2Þ.
In practice, NOPD can be useful in designing test cases for
inheritance structures. NOPD can help in detecting incorrectly
inherited subclasses. The value of NOPD for a given class
hierarchy represents the number of test cases required to test
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY BOMBAY. Downloaded on April 25, 2009 at 05:20 from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
VOL. 32,
NO. 3,
MARCH 2006
211
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
L. Briand, S. Morsca, and V. Basili, “Property-Based Software Engineering
Measurement,” IEEE Trans. Software Eng., vol. 22, no. 1, pp. 68-86, Jan. 1996.
J. Cherniavsky and C. Smith, “On Weyuker’s Axioms for Software
Complexity Measures,” IEEE Trans. Software Eng., vol. 17, no. 6, pp. 636638, June 1991.
S. Chidamber and C. Kemerer, “A Metrics Suite for Object Oriented
Design,” IEEE Trans. Software Eng., vol. 20, no. 9, pp. 476-493, Sept. 1994.
N. Fenton, Software Metrics: A Rigorous Approach. Chapman and Hall, 1994.
Gursaran and G. Roy, “On the Applicability of Weyuker Property Nine to
Object Oriented Structural Inheritance Complexity Metrics,” IEEE Trans.
Software Eng., vol. 27, no. 4, pp. 361-364, Apr. 2001.
E. Weyuker, “Evaluating Software Complexity Measures,” IEEE Trans.
Software Eng., vol. 14, no. 9, pp. 1357-1365, Sept. 1988.
L. Zhang and D. Xie, “Comments on ‘On the Applicability of Weyuker
Property Nine to Object Oriented Structural Inheritance Complexity
Metrics’,” IEEE Trans. Software Eng., vol. 28, no. 5, pp. 526-527, May 2002.
. For more information on this or any other computing topic, please visit our
Digital Library at www.computer.org/publications/dlib.
Fig. 4. Applicability of NOPD. (a) Individual systems. (b) Subclasses with public
inheritance. (c) Implementation bug: Class D uses private inheritance.
invocations of method m over the hierarchy. As an example,
consider two systems represented in Fig. 4a. An inheritance-based
composite of two systems that is shown in Fig. 4b is intended. The
designer identifies the test suite for the composite for testing
invocations of m. The test suite in this case consists of seven
invocations corresponding to the target system’s NOPD value of 7.
After the implementation of the composition (or refactoring), the
test suite is applied. In this case, if class D is incorrectly inherited
as private during implementation, as shown in Fig. 4c, one of the
test cases will dispatch to an unintended method implementation,
allowing the tester to capture this error during the testing phase.
Thus, it can be seen that a metric that satisfies Property 9 can also
be useful in practice.
5
CONCLUSION
The widely criticized Property 9 of Weyuker’s axiomatic system is
shown to be applicable to object oriented systems through
counterexamples to earlier arguments. A new metric called
Number of Polymorphic Dispatches was also formulated. The
metric is shown to satisfy Weyuker’s Property 9. Satisfying
Property 9 indicates that the complexity of object oriented
programs may increase when the number of classes are reduced.
However, the scarcity of metrics that satisfy the property suggests
that metrics that can capture bad compositions are needed.
Contrary to the belief that LCOM does not satisfy Property 9, it
was shown to be capable of capturing bad compositions. The new
measure considering the inheritance aspect further strengthens the
argument that Weyuker’s Property 9 is applicable to object
oriented metrics that have practical implications.
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY BOMBAY. Downloaded on April 25, 2009 at 05:20 from IEEE Xplore. Restrictions apply.