2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering

Extensions of Component Rank Modelby Taking into Account for Clone Relations
Reishi Yokomori∗ , Norihiro Yoshida† , Masami Noro∗ and Katsuro Inoue‡∗ Department of Software Engineering, Nanzan University, Nagoya, Aichi, 466–8673, Japan

Email: yokomori@se.nanzan-u.ac.jp, yoshie@nanzan-u.ac.jp† Graduate School of Information Science, Nagoya University, Nagoya, Aichi, 464–8601, Japan

Email: yoshida@ertl.jp‡ Graduate School of Information Science and Technology, Osaka University, Suita, Osaka, 565–0871, Japan

Email: inoue@ist.osaka-u.ac.jp
from a viewpoint how many components each component isused by, and a component graph, which represents components
and use-relationships between components, is produced, andevaluation value of each component is obtained by repetitive
calculation on the component graph.
In this paper, we extend the component rank model by
reﬂecting relationships of code clones between components on
the component graph. In our approach, the target component
graph consists of one software, and components that have
similar code fragments are merged in the graph. And then we
re-calculate evaluation value based on the merged graph, andwe get two evaluation values of each component, before andafter reﬂection of the code-clone relations. We take particularnote of the not merged components, and calculate a degree ofthe change of the evaluation value of each component. We will
discuss how evaluation value of each component may change
through the reﬂection. We consider affected components areused by both of the merged components, and the evaluation
values of these components would decrease.
The goal of our research is to propose a system that
detects components that are commonly used by similar codefragments. We consider that simply extracting componentsthat are commonly used by similar code fragments would
be insufﬁcient bacause we have to consider use relations tothe components from other ones. In the proposed method,
we can consider a degree of the aggregation of use relations
in merging, so we consider a percentage of reduction of
the evaluation value would be useful for detecting assumed
components.
By extracting components that are truely related to theexisting code clone, we can offer a mechanism to prevent a
spread of the code clone. For example, we consider a situationof adding a new component to the existing software. When the
new component uses component whose evaluation value has
decreased, the new component may use the components by thesame method as components that have similar code fragments.
At the time of using such components, the expanded model
can support by warning a possibility of producing a code
clone. We consider that this usage supports developers fromtwo viewpoints: the viewpoint of preventing making a code
clone easily, and the viewpoint which shows existences of

Abstract—The size of software increases in recent years, andthe number of classes and relationships between classes arealso increasingly complicated. We have a large interest about
the way to classify a great deal of components effectively. Our
research group proposed a component rank model in the past,and the model calculates an evaluation value of each component
by using component graph that represents use-relations between
components. In this paper, we suggest a method to reﬂect code
clone’s relation on the component rank model. In the extended
model, code clone’s relations are reﬂected on the component
graph by merging components that have similar code fragments.
When we focus simply on how the evaluation value of eachcomponent has changed, component whose evaluation value falls
would be mainly a component used by both of the merged
components. In the experiment, we applied our method to several
open source projects, and conﬁrmed that the change of evaluation
value of each component was within the scope of the assumption.
And we also searched case examples, and conﬁrmed how muchassumed cases existed in the actual software, and a percentageof the reduction of the evaluation value was useful for detecting
components related with code clone. Through these experiments,
we conﬁrmed that our method is effective to detect componentsthat existing similar code fragments are using.

I. I NTRODUCTION
The size of many software increases continuously becauseof accommodating a lot of additional features. Therefore,
the number of classes that compose such software becomesincreasing, and relationships between such classes also become
increasingly complicated. When implementing new features,developers add new code fragments to the software. Sometimes these code fragments are very similar to the existingcode fragments. This is because, implementing a similarfeature also requires producing codes that have similar codefragments. Such similar code fragments are called code clone[1], and how to manage the software that contains a lot ofcode clones becomes a major matter of concern. It is generally
desirable to remove or not to create a code clone, however,code clones are sometimes woven with developer’s intention.
In such case, developers have to share the intension for keeping
the maintainability of the software.
Our research group proposed a ranking model for recommending desirable components from a lot of components extracted from a lot of software systems and we call it component
rank model [2]. In the model, components are recommended
978-1-5090-1855-0/16 $31.00 © 2016 IEEE
DOI 10.1109/SANER.2016.30

30

code fragments that are useful as examples. In this way, we cankeep away that the existing code clone derives and increases invarious forms. Since differentiated code clones make it more
difﬁcult to detect code clones, so our method would be usefulfor improvement in the quality of software.
Based on the approach, we implemented a system thatshows the components whose evaluation value have changed
after reﬂection of code clone relations, and we conducted two
evaluation experiments. In the ﬁrst experiment, we applied our
method to source codes of open source projects and conﬁrmedthat the evaluation value of components used by several
components in the merged components would decrease. In thesecond experiment, we searched case examples, and conﬁrmed
how much assumed cases existed in the actual software, andconﬁrmed that a percentage of the reduction of the evaluation
value was useful for detecting assumed components.
In Section II, we introduce backgrounds. In Section III,
we discuss how evaluation value of each component may
change by merging components. In Section IV, we introduce
our implementation. In Section V, we introduce conducted
two experiments. Finally, in Section IV, we discuss about theresults and future directions and introduce related works.

2) Repeat calculation 2-1 and 2-2 until convergence.
2-1 Calculate weights of edges from weights of nodes
For each edge 𝑒𝑖𝑗 ∈ 𝐸 from 𝑣𝑖 to 𝑣𝑗 , we deﬁne a weight𝑤′ (𝑒𝑖𝑗 ) of 𝑒𝑖𝑗 as following;𝑤′ (𝑒𝑖𝑗 ) = 𝑑𝑖𝑗 × 𝑤(𝑣𝑖 )Figure 1 (a) depicts this deﬁnition. Here, 𝑑𝑖𝑗 is called a
distribution ratio for edge 𝑒𝑖𝑗 , where 0 ≤ 𝑑𝑖𝑗 ≤ 1, andif there is no edge from 𝑣𝑖 to 𝑣𝑗 , 𝑑𝑖𝑗 = 0. The distribution ratio 𝑑𝑖𝑗 is used for determining the forwarding
weights of 𝑣𝑖 to an adjacent node 𝑣𝑗 . For each node
which has any outgoing edges, the sum of distribution
ratios for outgoing edges is always 1. In the current
implementation, if a node 𝑎 has 𝑛 outgoing edges, andthen distribution ratios of outgoing edges from 𝑎 areall 1/𝑛. In the actual calculation, we have to treat thetarget component graph as a strongly connected graphto guarantee the termination of repeated computation,so we introduce pseudo use relations between all nodes.
This is not on topic, so please refer to [2].
e1iw(vi )

II. BACKGROUNDSw’(eij )vi

A. Component Graph
In general, a component is a modular part of a system that
encapsulates its content and whose manifestation is replaceable within its environment [3]. We model software systems byusing a weighted directed graph, called a Component Graph[2]. In the component graph (𝑉, 𝐸) , a node 𝑣 ∈ 𝑉 representsa software component, and a directed edge 𝑒𝑥𝑦 ∈ 𝐸 fromnode 𝑥 to 𝑦 represents a use relation meaning that component
𝑥 uses component 𝑦.

eij

vj

w(vi )w’(eki )vi

eki

w(vi ) = w’(e1j ) + w’(e2j ) +w’(eij ) = dij w(vi )(a) Weight of Edge

䊶䊶䊶+ w’(e

kj

) +

䊶䊶䊶

(b) Weight of NodeFig. 1. Deﬁnition of weights

2-2 Re-calculate weights of nodes from weights of edges
The weight of a node 𝑣𝑖 is re-deﬁned as the sum of theweights of all incoming edges 𝑒𝑘𝑖 , such that∑𝑤(𝑣𝑖 ) =𝑤′ (𝑒𝑘𝑖 )𝑒𝑘𝑖 ∈ IN(𝑣𝑖 )B. Component Rank Model
Based on the component graph, we proposed Component
Rank Model [2]. In the model, the component graph representsa Markov chain, and a movement of software developer’s
focus on the target software is represented by a probabilistic
state transition. The weight of each node at steady state isregarded as the evaluation value of correspondent component,
and this model calls the order of the components sorted by
the evaluation value component rank of the components. The
component rank model was proposed as a part of component
search engine, and its application result was reasonable suchthat very general and core classes were ranked high (signiﬁcant), and speciﬁc and independent classes were ranked low.
This model introduces several deﬁnitions to calculate evaluation values (weights) for component graph 𝐺 = (𝑉, 𝐸). Eachnode 𝑣 in component graph 𝐺 has a non-negative weight value
𝑤(𝑣) where 0 ≤ 𝑤(𝑣) ≤ 1. The sum of the weights of allnodes in 𝐺 is 1, and total weights of nodes are kept as 1.
The following is a calculation process;1) Set initial weights to each node
Each node has 1/𝑛 as an initial weight if target system
consists of 𝑛 components.

Here, IN(𝑣𝑖 ) is the set of the incoming edges of 𝑣𝑖 .
Figure 1 (b) shows this deﬁnition.
3) The weight of each node at steady state is regarded as
the evaluation value of correspondent component, andcomponents are sorted by the evaluation value.
Figure 2 shows a component graph with evaluation value
at steady state. 𝑣1 has two outgoing edges, and weight 0.4
is evenly divided to two outgoing edges with 0.2 each (i.e.,𝑑12 = 𝑑13 = 0.5). 𝑣3 has two incoming edges, each with weight
0.2, so that the weight of 𝑣3 is 0.4.
III. R EPRESENTING C ODE C LONE R ELATIONS ON THE
C OMPONENT G RAPH
A code clone is a code fragment that has identical or similarcode fragments to it in the source code [1]. Code clones
appear not only in a single component, but also appear between
different components. It is generally desirable not to create a

31

v1

we consider the situation that 𝑥 nodes are merged and thenumber of outgoing edges from a certain node becomes𝑛 to 𝑛 − 𝑥 + 1. Evaluation value of each edge become𝑛𝑛𝑛−𝑥+1 times, however 𝑛−𝑥+1 is equal or less than 𝑥.
∙ We consider a case of component that is used by both ofthe merged components. 𝑉1 is used by both 𝑉4 and 𝑉5 .
Before merging, 𝑉1 gets evaluation value via edges from𝑉4 and 𝑉5 . After merging, outgoing edges from 𝑉4 or 𝑉5
are also aggregated to one outgoing edge, and 𝑉1 gets
evaluation value via edges from 𝑉4′ . Evaluation value of𝑉4′ doesn’t exceed the sum of the one of 𝑉4 and 𝑉5 , so
the evaluation value of 𝑉1 decreases.
∙ We consider a case of component that is used by only
one of the merged components. 𝑉5 uses 𝑉3 and 𝑉4 doesn’t
use 𝑉3 . Before merging, 𝑉3 gets evaluation value via edge
from 𝑉5 . After merging, 𝑉3 gets evaluation value via edge
from 𝑉4′ . The evaluation value of 𝑉4′ is larger than the oneof 𝑉5 , so the evaluation value of 𝑉3 would increase.
∙ Other nodes are affected by the following factor;– In the repeated calculation, decrease or increase ofevaluation values are spread to other nodes throughtheir outgoing edges.
– When a closed path is built by merging components,
components on the closed path give a part of theirevaluation value to other components on the closed
path, so evaluation values of them increase.
As a result, evaluation value of the component, that is usedby several components among the merged ones, decreases. We
also think there is a difference about decreasing degree by how
the component is used by other component. Components thatreceive evaluation values from merged components and othercomponents would be low decreasing degree. On the other
hand, components that are used locally only by the merged
components would be high decreasing degree. So we set a
hypothesis that ”Components whose evaluation value goes
down are tend to be used by similar code fragments in themerged components.”

0.2

0.4

d

=0.5

12

d

13

= 0.5

0.2
0.4
d

31

= 1

v2

0.2

d

23

= 1

0.2

v3
0.4

Fig. 2. An example of stable weights assigned to nodes and edges

sϭ

sϮ

sϯ

sϰ

sϱ

sϲ

sϳ

sϴ

sϵ

sϭ

sϮ
sϰΖ

sϳ

sϯ
sϲ

sϴ

sϵ

Fig. 3. Extending by merging clone-related components

code clone, however, code clones are sometimes woven witha certain intention. In such case, developers have to share
information about the code has similar code fragments, for
keeping software maintainability. This is because developers
have to review another code fragments to keep its consistency
when one of such code fragments should be modiﬁed.
In this paper, we extend the component rank model by
reﬂecting relationships of code clones. As a method forreﬂecting code clone relationships, we merge nodes whichhave the same or similar code fragments. For examples, weconsider a part of component graph in Figure 3. It has 9 nodes(components), and 𝑉4 and 𝑉5 have similar code fragments eachother. In this case, we merge 𝑉4 and 𝑉5 into 𝑉4′ , and draw
edges from 𝑉𝑥 to 𝑉4′ if 𝑉𝑥 uses 𝑉4 or 𝑉5 , and draw edges
from 𝑉4′ to 𝑉𝑥 if 𝑉4 or 𝑉5 uses 𝑉𝑥 , respectively.
In this way, we get two component graphs before and after
reﬂecting code clone relationships, and calculate two component ranks. We focus attention on the components that are notmerged, and calculate differences of the evaluation value ofeach component. In this study, we have an interest about how
the evaluation value of each component changes by reﬂecting
relationships of code clones. We examine how evaluation valueof each component would change as following:

IV. I MPLEMENTATION OF THE ANALYSIS TOOL
We implemented a tool that calculates two component ranks
and compares the difference of each component’s evaluation
value. This tool is implemented by PHP, and Figure 4 is an
overview of the system. Our analysis target is a Java software,and we choose a .java ﬁle as a component. The following is
the analysis procedure:

Incoming edges to 𝑉4 and 𝑉5 are aggregated to one
incoming edge to 𝑉4′ . So, the number of outgoing edges
from 𝑉7 and 𝑉8 decreases and evaluation value of theseedges would increase. So, evaluation value of each incoming edge to 𝑉4′ increases.
′∙ Evaluation value of 𝑉4 is a sum of all incoming edges,
so evaluation value of 𝑉4′ would be larger than the one of
𝑉4 or 𝑉5 . However, evaluation value of 𝑉4′ doesn’t exceed
the sum of 𝑉4 and 𝑉5 . This is because incoming edges to𝑉4 and 𝑉5 are aggregated to one incoming edge, and if
∙

1.

2.

CCFinder [1] analyzes the target and get a result
about code clone. We treat two .java ﬁles have aclone relation if they have similar code fragmentsthat are longer than 30 tokens.
Classycle’s analyzer1 analyzes the target and get use
relations. In the analysis of Classycle’s analyzer, we
get the following as use relations: inheritance ofclass, declaration of variables, creation of instances,

1 http://classycle.sourceforge.net/

32

category is used only once at the most from allof the merged groups, and some of the merged
groups may not use the component.
Group C
Other components. Component of Group C is
not used by any of the merged components.
We conﬁrm that the evaluation values of Group A Components decrease than other components (Group B or C).
Through the experiment, we check the adequacy of ourconsideration, and consider the point which should betaken into consideration in actual use.
2) We get Group A components like experiment1. For eachGroup A component, we investigate whether merged
components use the component in similar way or not,by reviewing code visually, and check the adequacy ofa hypothesis that ”Components whose evaluation value
goes down are tend to be used by similar code fragmentsin the merged components.”^ŽĨƚǁĂƌĞ

ůĂƐƐǇĐůĞ

ĨŝŶĚĞƌ

hƐĞ ZĞůĂƚŝŽŶ

ŽĚĞůŽŶĞhƐĞZĞůĂƚŝŽŶ
ŶĂůǇǌĞƌ

ůŽŶĞ
ŶĂůǇǌĞƌ

ŽŵƉŽŶĞŶƚ
'ƌĂƉŚDĞƌŐĞĚ
ŽŵƉŽŶĞŶƚ
'ƌĂƉŚ/ŵƉůĞŵĞŶƚĂƚŝŽŶ

ŽŵƉŽŶĞŶƚZĂŶŬĂůĐƵůĂƚŽƌ
ŽŵƉŽŶĞŶƚ
ZĂŶŬ;ĞĨŽƌĞͿŽŵƉŽŶĞŶƚ
ZĂŶŬ;ĨƚĞƌͿŽŵƉĂƌĞǀĂůƵĂƚŝŽŶsĂůƵĞƐ
ŝĨĨĞƌĞŶĐĞƐŽĨǀĂůƵĂƚŝŽŶsĂůƵĞƐ

B. Rate of Variability
A number of nodes decreases after merging components.
As an example, we suppose the following situation; At ﬁrst,
a number of nodes in the component graph was 𝑉𝑏𝑒𝑓 𝑜𝑟𝑒 ,and an evaluation value of node 𝑣𝑖 was 𝑤(𝑣𝑖 )𝑏𝑒𝑓 𝑜𝑟𝑒 . Aftermerging, the number of nodes decreased into 𝑉𝑎𝑓 𝑡𝑒𝑟 , and theevaluation value of node 𝑣𝑖 became 𝑤(𝑣𝑖 )𝑎𝑓 𝑡𝑒𝑟 . Because a sumof the evaluation values are always 1, the evaluation value isdistributed to each component much relatively. So we deﬁnea rate of variability of node 𝑣𝑖 as following;

Fig. 4. Overview of the analysis tool

3.
4.

5.
6.

method calls, and reference of ﬁelds. Classycle’s Analyzer’s result is based on relations between classes,
so the result between classes are mapped into relations between ﬁles, so inner classes and anonymous
inner classes and other supplemental classes in acertain ﬁle and use relations of them are merged.
A component rank before merging is calculated.
Our tool merges components that have a clone relation, and use relations are also re-considered on themerged component graph.
A component rank after merging is calculated.
Two component ranks are compared, and the resultof the comparison is outputted as a table.

𝑤(𝑣𝑖 )𝑎𝑓 𝑡𝑒𝑟 × 𝑉𝑎𝑓 𝑡𝑒𝑟
× 100
𝑤(𝑣𝑖 )𝑏𝑒𝑓 𝑜𝑟𝑒 × 𝑉𝑏𝑒𝑓 𝑜𝑟𝑒(1)

C. Experiment1: About Changes of Evaluation Values
We selected 45 open source projects in SourceForge. This
selection was performed via search function of SourceForge,
and we selected projects that have both source code ﬁles (.java)and bytecode (.jar) and we didn’t have other intentions. For
each the project, we got one version of the software andapplied our method to it, and calculated a rate of variability foreach component. We categorized components into Group A,
B, and C and calculated an average of the rate for components
in Group A, B, and C, respectively. We compared them andconﬁrmed that evaluation value of the components in GroupA decreased averagely than the one for Group B and C.
Table I shows an average of the rate for components inGroup A per project, the one for Group B and C per project,
respectively. Some projects didn’t have any components belong to Group A (B, or C), so the number of project foreach category was less than 45. We conﬁrmed that an averagerate of variability for Group A components decreased 10%
and, on the other hand, the one for the components in Group
B and C increased slightly. In this way, the average rate ofvariability for the components in Group A decreased than the
one for Group B and C. Group C components were not affected
directly from merging nodes, so standard deviation of GroupC was smaller than the one of Group A and B.

V. E XPERIMENT
A. Objective
By making a comparison between an evaluation value
before merging and the one after merging, we performed
the following two experiments to conﬁrm that we can detectcomponents that would be a source of code clone generation.
1) We apply our method to source codes of open source
projects. We focus attention on not merged components,
and not merged ones are categorized as following;Group A
Components used by several components inthe merged components. We can imagine asituation that there are several merged groups.
In such case, if the component meets the requirement against at least one of the merged
groups, then the component belongs to this.
Group B
Components used by only one of the merged
components. This means that component of this33

cally signiﬁcant difference between Group A and B (𝛼 =0.01, 𝑑 = 1.04, and 1 − 𝛽 = 0.99988) and there was alsoa statistically signiﬁcant difference between Group A and C(𝛼 = 0.01, 𝑑 = 0.94, and 1 − 𝛽 = 0.99932), respectively.
From these result, we concluded that the evaluation value ofthe component that was used by several components of themerged components decreased than other components.

TABLE IA N AVERAGE OF R ATE OF VARIABILITY FOR EACH PROJECTGroup AGroup B
Group C

Projects
43
41
43

Average
88.5%
107.7%
104.3%

Standard
Deviation
19.6
16.2
6.4

Increased
3
19
20

Decreased
40
22
23

D. Experiment2: Components Used by Merged Components

Some projects didn’t have any components belong to GroupA (B, or C); however, components were present in both GroupA and B in 36 projects, and components were present inboth Group A and C in 37 projects, respectively. For eachproject, we calculated the difference between the average rateof variability for the components in Group A and the one
for Group B, and also calculated the difference between the
one for Group A and the one for Group C. As shown in
Table II, the difference between Group B and Group A (B-A)
and the one between Group C and Group A (C-A) were theplus value as the 15-20%. In 80-90 percent of projects, we
conﬁrmed that Group A components lost evaluation values
than other components. Fig. 5 shows a distribution of thedifferences between Group A and Group B, and Fig. 6 shows a
distribution of the ones between Group A and C, respectively.
Many projects were plotted in a range of 10% from 20%.

We selected 34 open source projects from 45 projects inExperiment1 in the interest of time, and not merged components were categorized in the same manner as Experiment1.
In this experiment, we focused attention on the Group A
components. For each Group A components, we analyzed
how the component was used by the merged components
by reviewing codes visually, and whether the uses of thecomponents caused producing a code clone or not. This meansthat the component was used by similar way inside or outsideof the detected code clone in the merged components, and their
behaviors about using the component were almost the same.
We categorized how the component was used in the merged
components, and discussed the points should be consideredwhen analyzing code clone with considering use relations.
From the 34 open source projects, we extracted 423 components belong to the Group A, and checked whether theuse of the component was a similar way or not. Table III
shows the result, and we conﬁrmed that 269 components wereused by merged components in a similar way, on the other
hand, 154 components were used by merged components ina different way. When it was considered by the percentage,
almost two-thirds of Group A components were used by themerged components in a similar way. There were several
merged groups, so we conﬁrmed 339 case examples fromthe 269 components. we classiﬁed these 339 case examples
based on how the component was used by. In the 195 cases,
we conﬁrmed that components were used by a method-callor creation of an instance, and so on, in the similar codefragments. In much of the remaining case, components were
inherited by several subclasses, and these subclasses had
common descriptions that were recognized as code clone. In
other cases, Group A components were exception classes, andthese components were used in similar exception handlings.

TABLE II
T HE D IFFERENCE OF AVERAGE R ATE OF VARIABILITY

B-A
C-A

Projects
36
37

Average
20.8%
15.8%

projects
<0 >0
3
33
5
32

Standard Deviation
20
16.7

ͳͷ
ͳͲ

ͻͲǦͻͻǤͻͳͲͲǦͳͲͻǤͻͺͲǦͺͻǤͻ͹ͲǦ͹ͻǤͻ͸ͲǦ͸ͻǤͻͷͲǦͷͻǤͻͶͲǦͶͻǤͻ͵ͲǦ͵ͻǤͻʹͲǦʹͻǤͻͲǦͻǤͻͳͲǦͳͻǤͻͲǦͳͲǦͲǤͳͷǦʹͲǦͳͲǤͳ䠢䡎䡁䡍䡑䡁䡊䠿䡕ʹͲ ȋǦȌ 

Fig. 5. A Histogram of the Difference of Average Rate ( B - A )TABLE IIIWAS THE C OMPONENT U SED BY A S IMILAR WAY ?

ͳͷͳͲComponents(Group A)
423
ͳͲͲǦͳͲͻǤͻͻͲǦͻͻǤͻͺͲǦͺͻǤͻ͹ͲǦ͹ͻǤͻ͸ͲǦ͸ͻǤͻͷͲǦͷͻǤͻͶͲǦͶͻǤͻ͵ͲǦ͵ͻǤͻʹͲǦʹͻǤͻͳͲǦͳͻǤͻͲǦͻǤͻͲǦͳͲǦͲǤͳͷǦʹͲǦͳͲǤͳ䠢䡎䡁䡍䡑䡁䡊䠿䡕

ʹͲ

Yes
269

No
154

Percentage
64%

Among 34 projects, there were 24 projects that have morethan 3 components belong to Group A. For each such project,
we calculated a precision ratio for the above-mentioned condition. Fig. 7 shows a distribution of the precision ratio for eachproject. We conﬁrmed that there was a peak of distribution
around the average (64%), on the other hand, there wereseveral projects whose precision ratio are 100%.

 ȋǦȌ 

Fig. 6. A Histogram of the Difference of Average Rate ( C - A )We also analyzed these differences statistically by using
the Welch’s t test, and conﬁrmed that there was a statisti-

34

VI. D ISCUSSION͸䠢䡎䡁䡍䡑䡁䡊䠿䡕ͷ

A. About Result of Experiment1Ͷ͵In the experiment1, we conﬁrmed that the evaluation valuesof the components, those were used by several components
among the merged components (Group A) decreased averagely
than the one of others (Group B and C). On the other hand, we
also conﬁrmed that evaluation values of some components inGroup A increased and the ones of Group B or C components
decreased severely. Especially, there were three projects so thatthe average rate of variability of the Group A components
increased, as shown in the Table I. For such cases, weinvestigated how nodes in the component graph were merged.
∙ We conﬁrmed that there were several groups in themerged component graph. Some of the Group A component was used by several components in a certain
group, however, the component was also used by only
one component in another group. In such case, evaluation
value of such component tends to increase.
∙ When a change of the graph structure was too big, or
when components whose role was quite different weremerged, several closed paths were produced in the mergedgraph. In such case, the distribution of the evaluation
value was strongly affected by the creared closed paths.
From these results, we consider that it isn’t desirable tomerge components gratuitously, and our method would be
improved by setting a restriction for mergence of components
based on relativeness between components. For example, we
consider that we can extract clone relations that have strong
connectivity, by considering relations between packages towhich components belong, or by extracting only a larger sizeof code-clones. As future works, we would like to inspect
the effect of such improvement methods by also considering
conﬁrgation choice problem [4].

ʹ

ͳͲͲΨ

ͻͲǦͻͻǤͻΨͺͲǦͺͻǤͻΨ͹ͲǦ͹ͻǤͻΨ͸ͲǦ͸ͻǤͻΨͷͲǦͷͻǤͻΨͶͲǦͶͻǤͻΨ͵ͲǦ͵ͻǤͻΨʹͲǦʹͻǤͻΨͳͲǦͳͻǤͻΨͲͲǦͻǤͻΨͳWƌĞĐŝƐŝŽŶZĂƚŝŽŽĨ'ƌŽƵƉŽŵƉŽŶĞŶƚƐƉĞƌƉƌŽũĞĐƚ

Fig. 7. A Histogram of the Precision for Each Project

We selected 2 projects, dnsjava2 , Jackcess3 that had morethan 20 Group A components. For each project, Group A
components were arranged in order of the decreasing rate of
the evaluation value, and we calculated a precision ratio for
Top X( X=1,2,3,....,20) components, respectively. Fig. 8 is atransition of the precision ratio for top X dnsjava components,
and Fig. 9 is a transition of the precision ratio for top X
Jackcess components, respectively. In these ﬁgures, a solidline shows a precision ratio for Top X components, anda horizontal line shows an average precision ratio of the
project. The precision ratios decreased totally with spreading
the scope of the ranking, however, the line totally kept over
the average precision ratio. For these projects, we consideredthat components whose evaluation value had decreased a lot
didn’t always ﬁt into our hypothesis; however, it was often thecase that such components ﬁtted into our hypothesis.

䠬䡎䡁䠿䡅䡏䡅䡋䡊 䠮䠽䡐䡅䡋

ͳͲͲ
ͺͲ
͸Ͳ
ͶͲ

B. About Result of Experiment2ʹͲͲIn the experiment2, we conﬁrmed that almost two-thirds ofthe Group A components were used by the merged components in a similar way. For actual use, we consider the ratio
was insufﬁcient to realize the method by simply extracting
components that were commonly used by code-clone related
components. We consider that sorting components based ona rate of variability seems to be efﬁcient as shown in Fig.
8 and Fig. 9, and a hypothesis that ”Components whose
evaluation value goes down are tend to be used by similar codefragments in the merged components.” worked to some extent.
In conjunction with improvement method in Experiment1, we
would like to improve our method.
We also classiﬁed 339 case examples based on how thecomponent was used by merged components. From a viewpoint of clone analysis based on the use relation, this kind ofclassiﬁcation would be useful for identifying a particular kindof use relations are closely related with producing code clones.
For example, we consider that the following support would
be realizable; When developers introducing some classes that
inherit a particular class, it can support by giving advices asͳ ʹ ͵ Ͷ ͷ ͸ ͹ ͺ ͻ ͳͲͳͳ ͳʹ ͳ͵ͳͶ ͳͷ ͳ͸ͳ͹ ͳͺ ͳͻʹͲ ȋȌ

Fig. 8. A Precision Ratio for Top X Components (dnsjava)䠬䡎䡁䠿䡅䡏䡅䡋䡊 䠮䠽䡐䡅䡋

ͳͲͲ
ͺͲ
͸Ͳ
ͶͲ
ʹͲ
Ͳ

ͳ ʹ ͵ Ͷ ͷ ͸ ͹ ͺ ͻ ͳͲ ͳͳͳʹ ͳ͵ ͳͶͳͷ ͳ͸ ͳ͹ͳͺ ͳͻʹͲ ȋ  Ȍ

Fig. 9. The Precision Ratio for Top X Components (Jackcess)

2 http://sourceforge.net/projects/dnsjava/
3 http://jackcess.sourceforge.net/

35also think that an improvement of the precision is necessary
to sense the utility of our approach in the actual use.
As future works, we would like to inspect the effect ofrestriction method for mergence of components based onrelativeness between components. From a viewpoint of clone
analysis based on the use relation, we would like to categorize
use relations that caused code clone in more detail, andinspect what kind of use relations tends to generate code
clone. After considering those pending problems, we would
like to implement a tool where it helps code clones not toincreases in various forms. The tool would contribute thesupport of software-maintenance work and the improvementof the quality of the source code.

there are already some good examples that inherit the class,and these classes serve as a useful reference. Based on suchapproach, we can control that the existing code clone derives
and increases in various forms in the software. Since suchdifferentiated code clones make it more difﬁcult to detect code
clones, so our method would be useful for improvement of thequality of software.
C. Related works
From a viewpoint of use relation (dependency) analysis,architecture recovery is active research area. Zhang represents
OO system by using Weighted Directed Class Graph, andproposed a clustering algorithm for recovering high-levelsoftware architecture [5]. Constantinou represents hierarchicalrelationships between components as D-layer, by contracting
closed paths in component graph, and investigated relationships between architecture layer and design metrics [6]. In thepast research, we proposed a metric representing a change ofcomponent rank as an impact for a source code update [7].
We paid our attention to the change of the evaluation value ofeach component also in this work.
From a viewpoint of clone analysis, Mondal analyzed thestability of several kinds of cloned codes, and they reported
that Type3 clones, known as gapped clones, have higher
stability than other clones [8]. Antoniol analyzed the evolutionof code duplications in 19 versions of the Linux kernel [9].
Yoshida et al. proposed an approach to supporting clone refactoring based on code dependency (e.g., caller-callee, sharedvariable) among code clones [10]. Their approach presents
a coherent set of code clones as a refactoring opportunity.
Our research uses component rank model as a basis forconsolidating clone information and showing the result, thecharacteristics of our research is that it pays its attention
to the components which the code clone uses in common.
In [11], Yamanaka suggested a daily reporting system about
modiﬁcations related with cloned codes. We consider thatchanges of component rank may also be ﬁt to be used in suchreporting system.

ACKNOWLEDGMENT
This research is supported by Nanzan University Pache
Research Subsidy I-A-2 for the 2015 academic year. I would
like to gratefully and sincerely thank to E.Senga. Original ofthis research is based on his master thesis written in Japanese[12]. We were supervisors of it and added considerations,experiments and evaluations thoroughly for this paper.
R EFERENCES[1] T. Kamiya, S. Kusumoto, and K. Inoue, “Ccﬁnder: A multi-linguistic
token-based code clone detection system for large scale source code,”IEEE Transactions. Software Engineering, vol. 28, no. 7, pp. 654–670,
2002.
[2] K. Inoue, R. Yokomori, T. Yamamoto, M. Matsushita, and S. Kusumoto,“Ranking signiﬁcance of software components based on use relations,”
IEEE Transactions on Software Engineering, vol. 31, no. 3, pp. 213–225,
2005.
[3] C. Krueger, “Software reuse,” ACM Computing Surveys, vol. 24, no. 2,
pp. 131–183, 1992.
[4] T. Wang, M. Harman, Y. Jia, and J. Krinke, “Searching for better
conﬁgurations: A rigorous approach to clone evaluation,” in Proceedingsof the 2013 9th Joint Meeting on Foundations of Software Engineering,
2013, pp. 455–465.
[5] Q. Zhangs, D. Qiu, Q. Tian, and L. Sun, “Object-oriented softwarearchitecture recovery using a new hybrid clustering algorithm,” inProceedings of the Seventh International Conference on Fuzzy Systems
and Knowledge Discovery, 2010, pp. 2546–2550.
[6] E. Constantinou, G. Kakarontzas, and I. Stamelos, “Towards open
source software system architecture recovery using design metrics,” inProceedings of the 15th Panhellenic Conference on Informatics, 2011,
pp. 166–170.
[7] R. Yokomori, M. Noro, and K. Inoue, “Evaluation of source code
updates in software development based on component rank,” in Proceedings of 13th Asia Paciﬁc Software Engineering Conference, Bangalore,
India, 2006, pp. 327–334.
[8] M. Mondal, C. Roy, M. Rahman, R. Saha, J. Krinke, and K. Schneider,“Comparative stability of cloned and non-cloned code: An empirical
study,” in Proceedings of the 27th ACM Symposium on Applied Computing, 2012, pp. 1227–1234.
[9] G. Antoniol, U. Villano, E. Merio, and M. D. Penta, “Analyzing cloning
evolution in the linux kernel,” Information and Software Technology,
vol. 44, no. 13, pp. 755–765, 2002.
[10] N. Yoshida, Y. Higo, T. Kamiya, S. Kusumoto, and K. Inoue, “On refactoring support based on code clone dependency relation,” in Proceedingsof the 11th IEEE International Software Metrics Symposium, 2005, pp.
16:1–16:10.
[11] Y. Yamanaka, E. Choi, N. Yoshida, K. Inoue, and T. Sano, “Industrial
application of clone change management system,” in Proceedings of the
6th International Workshop of Software Clones, 2012, pp. 67–71.
[12] E. Senga, “Evaluation of software components considered code clone,”
Master’s thesis, Dept. of Mathematical and Information Science, Nanzan
University, 2013, (In Japanese).

VII. C ONCLUSION
In this paper, we extended component rank model by
reﬂecting relationships of code clones between components
on the component graph, and components that have a similarcode fragment were merged in the graph. We implemented asystem based on the proposed method, and we conducted two
evaluation experiments. In the ﬁrst experiment, we conﬁrmedthat the evaluation value of the component, that was used byseveral components among the merged ones, decreased. In
the second experiment, we conﬁrmed that almost two-thirdsof the components that were used by the several merged
components, were used by merged components in a similarway, and sorting components based on a rate of variability
seemed to be efﬁcient. From these results, we could conﬁrm acertain degree of its utility, and a rate of variability seemed tobe efﬁcient for ﬁltering not-related components. However, we36