IEICE TRANS. INF. & SYST., VOL.E88–D, NO.6 JUNE 2005

1284

LETTERA Simple Predictive Method for Discriminating Costly Classes
Using Class Size Metric∗
Hirohisa AMAN†a) , Member, Naomi MOCHIDUKI† , Nonmember, Hiroyuki YAMADA† , Member,and Matu-Tarow NODA† , Nonmember

SUMMARY Larger object classes often become more costly classes
in the maintenance phase of object-oriented software. Consequently classwould have to be constructed in a medium or small size. In order to discusssuch desirable size, this paper proposes a simple method for predictively
discriminating costly classes in version-upgrades, using a class size metric,
Stmts. Concretely, a threshold value of class size (in Stmts) is provided
through empirical studies using many Java classes. The threshold value
succeeded as a predictive discriminator for about 73% of the sample Javaclasses.
key words: object oriented software, modification eﬀort, prediction, classsize, metrics

1. Introduction
Class size is an important attribute of object-oriented software. Larger classes often become more costly classes in
the maintenance phase, since larger ones would need moretime and eﬀort to review, upgrade and/or reconstruct. Consequently class would have to be constructed in a medium
or small size. Eman et al.[1] have discussed the optimal sizeof class, and empirically showed faulty classes tend to belarger than not-faulty classes. We focus on version-upgrades
as well as the number of faults, especially the lines of codes
modified through the upgrades. Version-upgrades can include not only fault fixings but also software refactoringsand evolutions. Consequently version-upgrades would be
important to more software developers and managers. In
order to discuss an optimal class size in terms of versionupgrades, we propose a simple method for predictively discriminating the costly classes from the others, using a classsize metric. Concretely, we empirically derive a thresholdvalue of class size from many version-upgrade cases in Javaclasses, and validate it as a predictive discriminator for the
costly classes.

Manuscript received October 8, 2004.
Manuscript revised January 25, 2005.
†
The authors are with the Department of Computer Science,
Faculty of Engineering, Ehime University, Matsuyama-shi, 790–
8577 Japan.
∗
This paper was presented at the 6th Joint Conf. on
Knowledge-Based Software Eng. (JCKBSE2004), Moscow, Russian Federation, Aug. 2004.
a) E-mail: aman@cs.ehime-u.ac.jp
DOI: 10.1093/ietisy/e88–d.6.1284

2. Predictive Discrimination of Costly Classes by Class
Size Metric
2.1 Costly Class
To discuss costly classes in not only closed software projects
but also open source software projects, this paper focuseson the number of source code lines modified through theversion-upgrade, and considers it to be an important factorof the version-upgrade cost. Formally, let c be a class, and it
has upgraded from the version vi to the next version vi+1 ; werepresent the older version as cvi , and the newer one as cvi+1 .
Then let d(cvi , cvi+1 ) be the number of diﬀerent source codelines between cvi and cvi+1 , i.e., the modified lines throughthe version-upgrade. The diﬀerent lines contain the changed
lines, added lines and deleted lines, excepting the commentstatements and empty lines. After filtering out the commentstatements in source program, those diﬀerent lines can becounted up by the Unix command “diff” with the option“-cbwB”∗∗ . d(cvi , cvi+1 ) would be an important measure of
the version-upgrade cost that went into cvi .
When a class cvi has a large number of diﬀerent lines
with the next version cvi+1 , we consider cvi to be a costly
class. Formally, we define it as follows.
Definition 1 (costly class; decision parameter α):Given n version-upgrade cases for many classes, say{cvi , cvi+1 }. Consider a real number α (0 ≤ α ≤ 1), and ifd(cvi , cvi+1 ) is in the largest α·n cases of all version-upgrade
cases∗∗∗ , then we define cvi to be a costly class. We will say
such {cvi , cvi+1 }’s as “the worst α (%) cases.”
The parameter α would be empirically decided by software managers, to determine their “wrong” version-upgrade
cases. For example, when we have 1234 (= n) versionupgrade cases and α = 0.05 (5%), we select the largest
62 (= 0.05×1234 = 61.7) cases corresponding to theworst 5% cases.
2.2 Class Size Metric
Now we introduce a class size metric for our predictive discrimination of costly classes. Class size is one of the most∗∗GNU diﬀutils version 2.8.1.
The ceiling function  ·  is used for only making α·n into an
approximate natural number.
∗∗∗c 2005 The Institute of Electronics, Information and Communication Engineers
Copyright 

LETTER

1285

Fig. 1

Example of two code fragments whose coding styles are diﬀered.

basic object-oriented software attribute, and understandable
for a lot of developers and managers. We believe that software quality criteria should be simple for becoming widelyused, so we focus on class size in this paper.
We use the metric “Statements (Stmts)” [2] for measuring class size. Stmts value is the number of executable anddeclaration statements in a class. The metric is sensitive tocoding eﬀort, and can provide a coding-style independentmeasurement.
We might used other size metrics such as “lines
of codes (LOC) [3],” “number of methods (NM) [4],”“weighted methods per class (WMC) [5],” and so on. LOC
is also sensitive to coding eﬀort but performs a coding-styledependent measurement: e.g., two code fragments shown in
Fig. 1 have diﬀerent coding-styles, and their LOC values arealso diﬀered (the left fragment’s LOC value is 4 and the rightone’s LOC value is 6) but their Stmts values are the same
(both of their Stmts values are 7; these 7 statements contain
1 while-statement, 3 binary-expressions, 1 if-statement, 1
assignment-expression and 1 unary-expression† ). Although
NM would perform a coding-style independent measurement, it is weakly sensitive to coding eﬀort since this metricuses only the number of methods. WMC might also achievea coding-style independent measurement and be sensitive tocoding eﬀort. However WMC values depend on weight values assigned to methods, and there are various ways for assigning weight values [7]. It is diﬃcult to decide the way for
assigning weight values to be good at any type of software.
For the above reasons, this study will use Stmts as the size
metric.
We represent the Stmts value of class cvi as Stmts(cvi ).
Stmts values can be easily counted up using JavaML [8]which is a XML representation of Java source program: we
can get Stmts(cvi ) value by counting the number of appropriate tags, such as “<if>” and “<loop>,” in JavaML corresponding to cvi . For example, Fig. 2 shows a JavaML whichcorresponds to both of the code fragments shown in Fig. 1;
those two code fragments are identical in JavaML. We
can find 7 appropriate tags for executable/declaration statements in Fig. 2: “<loop>,” three(3) “<binary-expr>”s,“<if>,” “<assignment-expr>” and “<unary-expr>.” Insuch way, we can get Stmts values. JavaML bring us an easeof measurement tool development. We developed a Stmts
measurement tool based on JavaML.
2.3 Predictive Discrimination
We propose a concept of threshold value for predictively

Fig. 2

JavaML corresponding to both of the code fragments in Fig. 1.

discriminating the costly classes from the others by Stmts
values.
Definition 2 (threshold value τ):Consider a natural number τ, and predict as follows:• If Stmts(cvi ) ≥ τ, cvi will be a costly class, i.e., theversion-upgrade {cvi , cvi+1 } will be in the worst α cases;• otherwise, cvi will not be costly class.
All version-upgrade cases are classified into four categories as the contingency table [9] shown in Table 1.
In Table 1, E1 and E2 correspond to the numbers ofcases failed in the prediction by τ. In order to normalize
impact levels of prediction errors E1 and E2 , we formulate
the sum of error rates as follows:ε(τ) =

E1
E2
+
.
N1
N2

(1)

Now we find τ such that ε(τ) has the least value, i.e., thesum of error rates becomes the minimum. Such τ would
be a useful criterion of class size for discriminating costly
classes in object-oriented software development.
The above notations are summarized in Table 2.
†
According to the Java language specification [6], these expressions are called “Expression Statements” which are of executable statements.

IEICE TRANS. INF. & SYST., VOL.E88–D, NO.6 JUNE 2005

1286
Table 1

Contingency table for version-upgrade cases.

worst α cases
othersStmts value
<τ
≥τ

total

E1
S1

N1
N2

Table 2
notationcvi
d(cvi , cvi+1 )αStmts(cvi )
τ
ε(τ)

S2
E2

Table 3

description

versionRelaxer

Schema compiler using RELAX asschema, which can generates Java
programs for processing XML according to RELAX. Relaxer is written in Java.

0.1
0.101
0.11
0.12
0.13
0.14
0.141
0.142

J2EE based application server implemented in 100% Pure Java.

2.2.2
2.4.0
2.4.1
2.4.3
2.4.4
2.4.5

A programmer’s text editor written
in Java.

3.0
3.0.1
3.0.2
3.1
3.2

Notations.
description

version vi of class c
number of diﬀerent lines between cvi and cvi+1
decision parameter selecting the worst α(%) cases;
costly classes
Stmts value of cvi
threshold value for predictively discriminating costly
classes by Stmts values
sum of error rates in the prediction by τOpen source software used as our experimental data.

software

JBoss

JEdit

3. Empirical Study
3.1 Experimental Data Collection
We collected 3514 version-upgrade cases from three open
source software projects: “Relaxer,” [10] “JBoss” and“JEdit” [11]. Table 3 shows brief descriptions of these software.
For each case (class pair), we counted the number of diﬀerent lines between the classes, and calculated Stmts value of the older version; formally, for eachversion-upgrade case {cvi , cvi+1 }, we computed d(cvi , cvi+1 )and Stmts(cvi ).
In this empirical study, we assumed α = 0.05, i.e., we
focused on the worst 5% cases, and predicted their older
versions would be the costly classes. Software managers canuse any α value as remarked above. Since many statisticaltests use “5%” as their significance level, “5%” would bea reasonable boundary for determining some worst cases.
Therefore this study used α = 0.05 as a reasonable example.
In our set of samples, the worst 5% cases corresponded tothe class pairs in which 154 or more lines were modified
through their version-upgrades.
Notice that the testing activity will also have a large
impact on the version-upgrades, though this study focuseson the class size. The higher testing density will decrease
faults in the software, and reduce the version-upgrade cost.
Unfortunately it may be diﬃcult to obtain the testing data inthe open source software development, unlike in the cases ofclosed projects which are managed by software vendors. In
open source software development, we are often able to collect bug reports from the development site instead of testing
data. The bug density† would also be an important factor forthe code quality and the stability of upgrade.
Automatically generated codes and/or reused codes
might be included in our empirical data. Since such codes
are unlikely to be upgraded through application releases,
they would be noise for computing the threshold value. Thus
it is better to exclude those codes from the analysis if we candetect those codes†† ; The study of code clone [12] might behelpful in detecting reused codes.
3.2 Result and Validation
Through the computation for possible τ with α = 0.05,
we found that ε(τ) has the least value when τ = 113 (seeFig. 3). We could obtain a threshold value 113 in Stmts,
which might be a criterion of class size for controlling the
upgrade cost. Notice that the value of τ is computed using
only the version-upgrade cases. However there were many
classes which did not have any changes with the next release, and they were excluded from the computation since
they were not regarded as upgrade cases. In order to see an
eﬀect of τ on not only upgraded classes but also the above
excluded classes, we conducted a follow-up. The initial
versions of the application software shown in Table 3 had
154 classes whose sizes were exceeded the threshold value.
These 154 classes include the classes which did not haveany changes with the next release. We investigated whether
those 154 classes were changed in later releases. As theresult, we found that 118 classes of them (ca. 77%) were
upgraded in a later release. Therefore τ(= 113) would havea certain level of ability in predictive discrimination.
Since the above three software sets are in diﬀerent
application domains, this experimental result does not de†We could get bug reports on “JBoss” and “JEdit” from the development sites. In consequence, the bug densities (= Bugs / 1000
Stmts) were not much diﬀerence between “JBoss” and “JEdit”: thebug density of “JBoss” and “JEdit” were 2.35 and 2.56, respectively. Thus the code quality of “JBoss” would be at about the samelevel as “JEdit.” Unfortunately we could not examine “Relaxer” interms of the bug density, since we could not find any repositories
of bug reports on “Relaxer.”††
In our empirical data collection, it was diﬃcult to find whichfragment of the code is an automatically generated or reused code,so we used all classes as our regular data.

LETTER

1287

Fig. 3ε(τ) values for possible τ.

hancement of predictive-accuracy with extended multivariate methods, (2) analysis of application specific thresholdvalues, (3) study of the impact of bug reports (bug density) on the version-upgrades, and (4) investigation of generated/reused code eﬀect on the version-upgrades.
An analysis of source code changes themselves is also
our important future work; Fischer et al.[13], [14] have studied relationships among software release data and bug reportdata, and Ying et al.[15] have proposed a method for predicting source code changes with mining change history. For
more precise predictive discrimination of costly classes, ourfuture work would consider the source code changes with
their release data and change histories.
Acknowledgments

pend on specific domains, and would have a generality
for discriminating costly classes written in Java. We performed an additional empirical study in order to validate
the generality of the above threshold value. We collected
another set of Java classes containing 556 version-upgrade
cases from two open source software projects “iReport” and“Azureus” [11]† , and computed Stmts value for the older
version in each case. As the result, 408 upgrade-cases (ca.
73%) of them could be successfully discriminated by theabove threshold value. The threshold value seems to havea certain level of generality for discriminating the costly
classes. While this empirical study uses some diﬀerent applications together in order to see the generality, application
specific threshold values can be computed in similar ways.
The application specific threshold values are also of interest,
and would be more useful in some cases.
4. Conclusion and Future Work
Using a class size metric, Stmts, we have proposed a simple method for predictively detecting costly classes that arelikely to need large modifications through their versionupgrades. The method provides a threshold value of classsize (in Stmts) for predictively discriminating those costly
classes. In our empirical study, we have derived the threshold value 113 (in Stmts) from many Java samples of versionupgrades (ca. 3500 pairs of classes). Further, using anotherset of Java samples (ca. 500 pairs of classes), we have validated that the derived threshold value has a certain level ofgenerality for predictively discriminating the costly classes:
it succeeded as a predictive discriminator for about 73% of
our sample classes. The derived threshold value would aid
the development of Java classes as a simple criterion of classsize. This method is simple but would contribute to controlling software maintenance- and/or testing-eﬀorts.
Our future work includes the followings: (1) en†
iReport is a visual reporting tool based on JasperReports written in 100% pure java, and Azureus is a powerful, full-featured,cross-platform java BitTorrent client. The sample version-upgrade
cases are randomly collected from their CVS repositories; thoseevaluated classes are the revisions 1.2 and 1.3 of iReport, and therevisions 1.1, 1.2 and 1.3 of Azureus.

The authors would like to thank the developers of open
source software used in the empirical work. The authors
also wish to thank the anonymous reviewer for his/herthoughtful and helpful comments.
This research was partially supported by the Inamori
Foundation, and the Ministry of Education, Science, Sports
and Culture, Grant-in-Aid for Young Scientists (B), 2004,
16700037.
References[1] K.E. Eman, S. Benlarbi, N. Goel, W. Melo, J. Lounis, and S.N. Rai,
“The optimal class size for object-oriented software,” IEEE Trans.
Softw. Eng., vol.28, no.5, pp.494–509, May 2002.
[2] L.C. Briand, J. Wust, J.W. Daly, and D.V. Porter, “Exploring the relationships between design measures and software quality in objectoriented systems,” J. Syst. Softw., vol.51, pp.245–273, 2000.
[3] S.D. Conte, V.Y. Shenm, and H.E. Dunsmore, Software Engineering
Metrics and Models, Benjamin Cummings Publishing Inc., Calif.,
1986.
[4] L.C. Briand, J. Wust, J.W. Daly, and D.V. Porter, “ Exploring the relationships between design measures and software quality in objectoriented systems,” J. Syst. Softw., vol.51, pp.245–273, 2000.
[5] S.R. Chidamber and C.F. Kemerer, “A metrics suite for object oriented design,” IEEE Trans. Softw. Eng., vol.20, no.6, pp.476–493,
June 1994.
[6] J. Gosling, B. Joy, G. Steele, G. Bracha, and James Java Language
Specification Gosling, The Java Language Specification, Second ed.,Addison-Wesley, Boston, 2000.
[7] M. Takehara, T. Kamiya, S. Kusumoto, and K. Inoue, “Empiricalevaluation of method complexity for C++ program,” IEICE Trans.
Inf. & Syst., vol.E83-D, no.8, pp.1698–1700, Aug.2000.
[8] G.J. Badros, “JavaML: A markup language for Java source code,”
Proc. 9th Int’l World Wide Web Conf., 2000.
[9] E.L. Crow, F.A. Davis, and M.W. Maxfield, Statistics Manual,
Dover, New York, 1955.
[10] http://www.asahi-net.or.jp/˜dp8t-asm/java/tools/Relaxer/[11] http://sourceforge.net/[12] T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder: A multilinguistic token-based code clone detection system for large scale
source code,” IEEE Trans. Softw. Eng., vol.28, no.7, pp.654–670,
July 2002.
[13] M. Fischer, M. Pinzger, and H. Gall, “Analyzing and relating bug report data for feature tracking,” Proc. 10th Working Conf. on Reverse
Engineering (WCSE’03), pp.90–99, 2003.
[14] M. Fischer, M. Pinzger, and H. Gall, “Populating a release history database from version control and bug tracking systems,” Proc.

IEICE TRANS. INF. & SYST., VOL.E88–D, NO.6 JUNE 2005

1288

of the International Conf. on Software Maintenance (ICSM’03),
pp.23–33, 2003.
[15] A.T.T. Ying, G.C. Murphy, R. Ng, and M.C. Chu-Carroll, “Predict-ing source code changes by mining change history,” IEEE Trans.
Softw. Eng., vol.30, no.9, pp.574–586, Sept. 2004.