Compiler

2376 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 48, NO.
7, JULY 2022
Change-Patterns Mapping: A Boosting Way

for Change Impact Analysis
Yuan Huang , Jinyu Jiang, Xiapu Luo , Xiangping Chen , Member, IEEE,
Zibin Zheng , Senior Member, IEEE, Nan Jia, and Gang Huang , Senior Member, IEEE
Abstract—Change impact analysis (CIA) is a specialized process of program comprehension that investigates the ripple effects of a
code change in a software system. In this paper, we present a boosting way for change impact analysis via mapping the historical
change-patterns to current CIA task in a cross-project scenario. The change-patterns reflect the coupling dependencies between
changed entities in a change set. A traditional CIA tool (such as ImpactMiner) outputs an initial impact set for a starting entity. To boost
the traditional CIA tool, our approach retrieves an equivalent entity from various historical change sets for the starting entity. Then, the
change-patterns between the equivalent entity and the rest of entities in the change set are mapped to the CIA task at hand. For current
CIA task, if an entity in the initial impact set involves the similar change-pattern with the starting entity when comparing with the mapped
change-pattern, we will reward the impacted confidence of the entity. Accuracy improvements are observed in the experiments when
applying our boosting method to three famous CIA tools, i.e., ImpactMiner, JRipples and ROSE.
Index Terms—Change impact analysis, change-patterns, coupling dependency, boosting method
1 INTRODUCTION Decades of research efforts have produced a wide spec-

trum of CIA approaches, ranging from the traditional static
change plays a vital role in software evolu-
S OFTWARE
tion, agile software development, and maintenance
[1]. Change impact analysis (i.e., CIA) is a special topic
and dynamic analysis techniques [3], [4], [5] to the contempo-
rary methods such as those based on coupling dependency
analysis [6], [7], [8] and mining software repositories (MSR)
of program comprehension, where the programmers
[9], [10], [11]. Although ample progress has been made, there
attempt to understand the ripple effect to a software sys-
still remains much work to be done for further improving
tem when making a particular software change. The soft-
the accuracy of the state-of-the-art CIA techniques. For
ware entities in a software system usually have direct or
example, the MSR based CIA methods try to uncover impor-
indirect dependencies after a long-time evolution, a
tant historical dependencies between software entities, e.g.,
slight change may rise ripple effects from an entity to
co-changed software entities in the evolutionary history of a
another [2]. As a result, change impact analysis is a par-
project. The operating principle of the MSR based CIA meth-
ticularly complex task in software systems, especially for
ods has the limitation that they only utilize the historical
the ones with years of development history, many of
dependencies of software entities in a project (i.e., within-
developers, and a multitude of software artifacts includ-
project scenario), rather than the historical dependencies
ing millions of lines of code.
information from other projects. To overcome this limitation,
we generalize the problem to a cross-project scenario, i.e., the
dependency information we referenced is not only from the
Yuan Huang and Zibin Zheng are with the School of Software Engineer- current project, but also from other projects.
ing, Sun Yat-sen University, Guangzhou 510006, China. For two entities with similar functionality in different
E-mail: huangyjn@gmail.com, zhzibin@mail.sysu.edu.cn.
Jinyu Jiang is with the School of Computer Science and Engineering, Sun
projects, it is possible that their changes will have a similar
Yat-sen University, Guangzhou 510006, China. E-mail: exinpie@163.com. ripple effect in the systems. Since these two entities have
Xiangping Chen is with the Guangdong Key Laboratory for Big Data similar functionality, they are likely to build similar logical
Analysis and Simulation of Public Opinion, School of Communication dependencies with the other entities through data interac-
and Design, Sun Yat-sen University, Guangzhou 510006, China.
E-mail: chenxp8@mail.sysu.edu.cn. tion or coupling. And because code change can propagate
Xiapu Luo is with the Department of Computing, The Hong Kong Poly- along coupling dependencies (i.e., the changes will first
technic University, Hong Kong. E-mail: csxluo@comp.polyu.edu.hk. ripple to the entities that have logical dependencies with
Nan Jia is with the School of Information Engineering, Hebei GEO Uni-
the change starting entities) [12], as a result, these two enti-
versity, Shijiazhuang 050031, China. E-mail: jianan_0101@hgu.edu.cn.
Gang Huang is with the Key Laboratory of High Confidence Software ties have similar ripple effects in the systems when they
Technologies, Ministry of Education, Peking University, Beijing 100871, are the change starting entities. We call the coupling
China. E-mail: hg@pku.edu.cn. dependencies between the change starting entity and the
Manuscript received 19 Mar. 2020; revised 4 Feb. 2021; accepted 9 Feb. 2021. impacted entities as change-patterns (will be presented in
Date of publication 16 Feb. 2021; date of current version 18 July 2022. Section 4.3). The change-patterns may be used to facilitate
(Corresponding author: Xiangping Chen.)
Recommended for acceptance by S. Apel. the change impact analysis. For example, there are two
Digital Object Identifier no. 10.1109/TSE.2021.3059481 classes cinit and c~init , and c~init builds a change-pattern with
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/
HUANG ET AL.: CHANGE-PATTERNS MAPPING: A BOOSTING WAY FOR CHANGE IMPACT ANALYSIS 2377
Fig. 1. Different change sets involved in similar change-patterns.
its impacted class c~n , and class cn has similar change-pat- We introduce a set of criteria for evaluating the use-
tern with cinit when comparing with one of c~init and c~n . fulness of our CIA boosting method. Accuracy
Then, cn is likely to be an impacted class by cinit when cinit improvements are observed when applying our
is the change starting point. boosting method to ImpactMiner, JRipples and
Based on such an idea, we propose the change-patterns ROSE.
to boost the performance of the traditional CIA tools in this We have uploaded the source code of the boosting
paper. Specifically, we first download a number of change method to the Github, and the URL is: https://github.
sets from the evolutionary history of more than one hun- com/CIABoosting/Change-Patterns-Mapping. We describe
dred projects, and identify the starting changed class (i.e., the basic requirements and steps for running the proposed
starting class) in each change set. For a starting class cinit in method. Besides, we upload the key dataset to the Github,
the CIA task at hand, we retrieve an equivalent starting such as, the starting classes of the commits, the change-pat-
class c~init with similar functionality from the historical terns, and the original impacted sets generated by the tools
change sets to cinit , and the change-patterns of c~init are Impactminer, Jripples and Rose, etc. The more detailed
mapped to the CIA task of cinit . Meanwhile, we employ a information about the key dataset can be found at the
traditional CIA tool to get an initial impact set for cinit . After URL: https://github.com/CIABoosting/IntermediaryData-
that, we boost the classes in the initial impact set when they for-ChangePatternsMapping.
involve similar change-patterns as comparing with the ones The rest of this paper is organized as follows. Section 2
between c~init and its impacted classes. We chose 7 open- shows a motivating scenario and the overview of main
source projects for CIA tasks, which are considered to be steps. Section 3 introduces the traditional change impact
high-quality, well evolved and widely used in related stud- analysis. Section 4 describes the process of seeking similar
ies [13], [14], [15]. We found that the combination of tradi- change-patterns from the cross-project scenario. Section 5
tional CIA methods and our boosting method is superior to introduces the setups of the case study. The result of the
the standalone CIA methods, i.e., the maximum relative case study is presented in Section 6. Section 7 shows a quali-
improvements of precision for ImpactMiner, JRipples and tative analysis. Section 8 is the discussion and threats to
ROSE are 21.98, 6.52 and 11.81 percent, respectively. validity. Section 9 summarizes the related works. Section 10
The contributions of our work are shown as follows: summarizes our approach and outlines directions of future
work.
We propose the concept of change-pattern to mea-
sure the coupling dependencies between changed
software entities, and using vectorized representa-
2 MOTIVATING SCENARIO AND OVERVIEW
tion make the change-pattern measurable. OF MAIN STEPS
Due to the metrizability, the change-patterns from 2.1 Motivating Scenario
different projects can be used to assist the CIA task This section overviews a motivating scenario with an exam-
at hand, and then the MSR based CIA method is gen- ple that uses the similar change-patterns to determine the
eralized to a cross-project scenario by us. impacted entities in CIA task. As shown in Fig. 1, the start-
We demonstrate that there are a lot of similar ing points JEditTextArea (Fig. 1a) and TextArea-
change-patterns (i.e., 213,554) across projects, which Painter (Fig. 1b) in the two change sets have similar
provides a solid foundation for us using the similar functionality. The source code of these classes is adapted
change-patterns to boost CIA methods. and simplified for presentation purposes. Due to the
2378 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 48, NO. 7, JULY 2022
Fig. 2. Overview of main steps.
method renaming (i.e., code lines with underlines are the class, and generate a ranking list for the impacted classes
changed lines, and “-” denotes code removing, and “+” according to their change confidence. In the boosting phase,
denotes code adding) in JEditTextArea and TextArea- we retrieve a similar starting class from the historical
Painter, JEditTextArea transfers the change ripple change sets for the given starting class, and map the
effect to ChunkCache and DisplayManager, and Tex- change-patterns in the historical change sets to the CIA task
tAreaPainter transfers the change ripple effect to at hand, and use the change-patterns to boost the rankings
Buffer and OffsetManager. of impacted classes obtained by the traditional CIA tools.
We found that classes JEditTextArea and TextArea- To identify a starting class of each change set, we employ
Painter have similar ripple effects on the systems, and they the ISC tool proposed in our previous study [12], [16], which
have similar change-patterns with their impacted entities. As can identify the root change that causes the change of the rest
Fig. 1 shows, JEditTextArea builds change-pattern of entities in a change set. Meanwhile, we employ the tradi-
< SAI,1 MMAIM2 > with DisplayManager, which is the tional CIA tools, ImpactMiner [17], JRipples [18] and ROSE
same with the change-pattern between TextAreaPainter [9], to obtain an initial impact set for a given starting class. To
and OffsetManager. Another change-pattern < CMAIM,3 retrieve a similar starting class from the historical change sets
SAI > between JEditTextArea and ChunkCache is also for the given starting class, we apply code semantic and syn-
similar with the one (i.e., < CMAIM, SAI > ) between Tex- tactic information to measure the similarity between classes.
tAreaPainter and Buffer.
The change-patterns can be used to facilitate the change 3 CHANGE IMPACT ANALYSIS
impact analysis. For example, if JEditTextArea is a start-
3.1 Basic Conceptions
ing point that developer try to change, and he (or she) finds
Given a starting entity (such as a class: cinit ), a traditional
a similar class TextAreaPainter to JEditTextArea
from the historical change set, and the change-patterns change impact analysis approach can infer the software
between TextAreaPainter and its impacted classes (i.e., entities (such as a class: ci ) that need to be further changed
Buffer and OffsetManager) are given. Then, the devel- in the software system [17], [18]. In general, the change
oper can regard the classes that have similar change-pat- impact analysis approach gives a confidence [2], [19] for
terns (comparing with the change-patterns between each entity, that is, the likelihood that further changes be
TextAreaPainter and its impacted classes) to JEdit- applied to the software entity
TextArea as the potentially impacted entities, i.e.,
ChunkCache and DisplayManager. confðcinit ; ci Þ ¼ P ðcinit ; ci Þ: (1)
The notation P ðcinit ; ci Þ indicates the likelihood of ci to be

2.2 Overview of Main Steps
changed when cinit is changed. Different CIA methods
Fig. 2 shows the main steps of the proposed approach. The
employ different mechanisms to estimate the P ðcinit ; ci Þ. For
approach includes three phases: data preprocessing, tradi-
example, the default model of ImpactMiner [17] employs
tional CIA processing and boosting phase (i.e., the parts
latent semantic indexing to estimate the P ðcinit ; ci Þ, and
connected by dotted arrows in Fig. 2). In the data prepro-
JRipples [18] analyzes the software entity dependency
cessing phase, our goal is to identify a starting class for each
graph to estimate the P ðcinit ; ci Þ. ROSE [9] estimates the
change set, and analyze the change-patterns between the
P ðcinit ; ci Þ by analyzing the co-changed entities in the evolu-
starting class and the rest of classes in the change set. In the
tionary history of the project.
traditional CIA processing phase, we employ the traditional
Then, for a starting entity cinit , a CIA method will output
CIA tools to get the initial impact set of a given starting
an impact set that contains all the potentially affected soft-
ware entities
1. SAI: static variable invoking.
2. MMAIM: method invoking through defining a method member
variable. CIAðcinit Þ ¼ Impact Setfc1 ; c2 ; . . . ; cn g: (2)
3. CMAIM: method invoking through defining a class member
variable.
Fig. 3. An example of identifying the starting entity by ISC.
Also, we can get a ranking list for the impacted entities 4 SEEKING SIMILAR CHANGE-PATTERNS
according to their change confidence in descending order.
To determine whether a starting entity cinit and its impacted
Then, several evaluation metrics (e.g., precision and recall)
entity ci have similar change-patterns in historical change
can be introduced to evaluate the performance of a CIA
sets, we need to first identify the starting entity c~init in
method with considering a fixed size of the impacted enti-
each historical change set, and then generate the change-
ties in the ranking list, known as cut-off points in [2], [20]. cd
pattern < c~init ! c~j >; then we can compare the similarity
cd cd
3.2 Ranking Boosting of change-patterns via < cinit ! ci > and < c~init ! c~j >
cd
In order to optimize the performance of the CIA methods, : At last, the similar change-pattern < c~init ! c~j > can be
researchers always want to boost the rankings of truly mapped to the CIA task for cinit .
impacted entities in the list as much as possible. For exam-
ple, Gethers et al., [20] introduce an adaptive approach to
improve the rankings of truly impacted entities via combin- 4.1 Identifying Starting Entity
ing various boosting mechanisms such as information The algorithm of identifying starting entity c~init from a histor-
retrieval, dynamic analysis, etc. Kagdi et al., [2] introduce ical change set has been proposed in our previous study [12],
conceptual couplings to improve the rankings of truly [16], known as ISC, and we employ ISC to identify the start-
impacted entities. ing entity in a historical change set in this paper. The starting
Intuitively, the co-changed entities in the evolution his- entity is also called salient entity in [12], [16], and the salient
tory of a project can be used as a vital reference for the CIA entity is the root change that causes the modification of the
task. Based on this idea, Zimmermann et al. propose to use rest of entities in a change set, while the rest of entities are the
historical co-changed entities for CIA task [9]. Different dependency modification along with the salient one. There-
from the previous works, we introduce the historical fore, the salient entity is the starting entity in this study.
change-patterns to optimize the rankings of truly impacted We added a real world example from jEdit (i.e., commit
entities. We call the coupling dependencies from a starting 22,828) project to illustrate how ISC identifies the starting
entity to impacted entities as change-pattern. For example, entity in a historical change set in this paper, as shown in
in a historical change set, the change-pattern between Figs. 3a, 3b, and 3c. The commit is adapted and simplified
a starting entity c~init and an impacted entity c~j is denoted for presentation purposes. As Fig. 3a shows, developer
cd
by < c~init !~ cj > when c~init builds coupling dependency updates the method abbreviate() to abbreviateView() (the
cd
(i.e., !) with c~j . minus “” represents the deleted code and the plus “+”
A CIA method can recommend an impact set for a start- represents the added code) in class MiscUtilities, and the
ing entity cinit , and the starting entity cinit may have cou- code change has ripple effect cross another 2 classes, i.e.,
pling dependencies with an entity ci in the impact set. Then, Buffer, BufferPrinter1_3 as Figs. 3b and 3c show. Obviously,
if cinit and ci have a similar change-pattern when comparing MiscUtilities is the starting entity.
with c~init and c~j (which come from historical change set), we Because a code change tends to propagate from the initial
can improve the confidence of the impacted entity ci by node of change occurrence to the node that has coupling
rewarding a value of Pscp . Then, the final confidence (i.e., relationship with the initial node, ISC uses structural cou-
conf) of entity ci is pling information between entities as one of the features to
identify the starting entity. For example, the coupling rela-
confðcinit ; ci Þ ¼ P ðcinit ; ci Þ þ Pscp ðcinit ; ci Þ: (3) tionship of method invocation (i.e., abbreviateView())
between classes MiscUtilities and Buffer. Meanwhile, since
After applying Pscp to the confidence of ci , the ranking of the starting entity in a change set is initially modified, start-
ci in the list will be improved. ing and non-starting entities differ in the amount of code
involved in the modification. Therefore, ISC employs the code line of a software entity into syntactic tokens via ana-
update degree (e.g., the number of changed code state- lyzing the abstract syntax tree, then the software entities
ments) of an entity in a change set to identify the starting cinit and c~init corresponds to token sequences TokenList1 and
entity. For example, the number of changed code statements TokenList2, respectively. To measure the syntactic similarity
in MiscUtilities and Buffer are different. In addition, ISC of two entities, the syntax matching method looks for the
also uses the types of commit to distinguish the starting and longest matching subsequence from the two token sequen-
non-starting entities in a change set. For example, the com- ces, as shown in Algorithm 1.
mit 22,828 is a “Re-Engineering” [12], [16] change set as it
Algorithm 1. Syntactic Similarity Computing
involves method renaming. ISC will identify the class Mis-
cUtilities as the starting entity via analyzing these features Input: TokenList1: the token sequence of class 1;
extracted from the commit. ISC achieves an accuracy of TokenList2: the token sequence of class 2;
87 percent in identifying the starting entity. More introduc- Output: SyntaxSimilarity
tion of ISC can be found in [12], [16]. Begin
1: For i = 0 to TokenList1.size do:
4.2 Seeking Equivalent Starting Entity 2: For j = 0 to TokenList2.size do:
3: If (TokenList1.get(i) == TokenList2.get(j)) do:
For a current CIA task, we have a starting entity cinit , and try
4: M[i,j] = 1;
to seek a starting entity c~init with similar functionality to cinit
5: End If
from the historical change sets, and c~init is an equivalent 6: End For
starting entity for cinit , and the change-patterns caused by 7: End For
c~init are used as a reference for the CIA task of cinit . Then, we 8: Foreach M[n,m]do:
need to compare the similarity of cinit and c~init . In general, we 9: While (true) do:
can determine the similarity from the code semantic and syn- 10: If(M[n,m] == 1) do:
tactic information. Code syntax can catch the program func- 11: subseqt .add(M[n,m])
tional information from a perspective of program logic, 12: n = n + 1;
while code semantics can intuitively catch the program func- 13: m = m + 1;
tional information from the word-choices of the source code. 14: remove(M[n,m]);
Not all the words in the source code play a positive role 15: Else:
for the semantic similarity analysis, some noisy words have 16: break;
no actual semantics and may weaken the original code 17: End If
semantics. To eliminate these noisy words, three prepro- 18: End While
cessing rules are applied on the original source code: 1) filter 19: End Foreach
out the function words in the source code, such as: ’and’, 20: Foreach subseqt do:
’the’, ’an’, etc. 2) filter out the keywords of Java, such as: 21: While (true) do:
’public’, ’void’, ’if’, ’import’, ’static’, etc. 3) filter out the letter 22: If gap(subseqt , subseqtþ1 ) < do:
sequence which does not denote a word, such as: ’tttt’, 23: subseqt = link(subseqt , subseqtþ1 );
24: t = t + 1;
’hhhk’, ’kkkk’, etc. In addition, we split the camel-case words
25: remove(subseqtþ1 );
into single words. Then, each entity corresponds to a text,
26: Else:
e.g., cinit and c~init corresponds to T ðcinit Þ and T ð~ cinit Þ.
27: break;
Inspired by Ye et al. [21], we use the asymmetric similar-
28: End If
ity to measure the sematic similarity of T ðcinit Þ and T ð~ cinit Þ. 29: End While
In study [21], the similarity between a word w in T ðcinit Þ 30: End Foreach
and the text T ð~ cinit Þ is defined as 31: SyntaxSimilarity = max lengthfsubseq1 ;subseq2 ;...;subseqt g
max sizefTokenList1;TokenList2g
32: Return SyntaxSimilarity;
cinit ÞÞ ¼
Simðw; T ð~ max simðw; w0 Þ; (4) End
w2T ðcinit Þ
where w0 2 T ð~ cinit Þ and we use WordNet4 to measure the In Algorithm 1, we first compare every token in Token-
normalized similarity simðw; w0 Þ between two words. Then, List1 (corresponding to token sequence 1) with every token
the similarity between two text T ðcinit Þ and T ð~ cinit Þ is in TokenList2 (corresponding to token sequence 2). We use a
matrix to store the result, and every matrix cell M½i; j stores
P
w2T ðcinit Þ Simðw; T ð~ cinit ÞÞ idfðwÞ the result of the comparison between the relevant token i and
SimðT ðcinit Þ; T ð~
cinit ÞÞ ¼ P : the relevant token j. M½i; j ¼ 1 means the relevant tokens are
w2T ðcinit Þ idfðwÞ
matched (i.e., identical). Second, we look for the matched
(5) cells from upper left corner of the matrix. From the first
Namely, an asymmetric similarity SimðT ðcinit Þ; T ð~cinit ÞÞ matched cell, we will further extend up to the first unmatched
is then computed as a normalized, idf-weighted sum of sim- cell on the main diagonal direction. The continuously
ilarities between words in T ðcinit Þ. matched cells form a subsequence. We continue to find out
To measure the syntactic similarity of cinit and c~init , we all the subsequences in the matrix. Third, we check the gap
use the syntax matching method proposed in our previous between any two subsequences in the matrix. If the gap is
study [22]. The syntax matching method first parses each less than a specific number, we link these two subsequences
to form a longer one. In the same manner the gap checking is
4. https://wordnet.princeton.edu/ repeated until we traverse all subsequences, then we can find
TABLE 1 However, in most cases finer-grained coupling depen-

Common Instances of a Variable Usage dencies often exist at the method and variable levels. The
finer-grained CRfg is defined as
Instances Description Abbrev
Method Member Variable mi invokes variable ai MMAUA CRfg ¼ fCi ei ) Cj ej j ei 2 ðAi [ Mi Þ ^ ej 2 ðAj [ Mj Þg;
mi invokes variable aj of Cj MMAIA
mi invokes method mj of Cj MMAIM
(8)
Class Member Variable mi invokes variable ai CMAUA
where ei and ej are the variables or methods contained in Ci
mi invokes variable aj of Cj CMAIA and Cj , respectively. ei ) ej denotes that ei and ej couple
mi invokes method mj of Cj CMAIM together at the variable or method levels. According to the
Function Parameter mi invokes parameter ai FPUA definition, there are 4 possible instances of the finer granu-
mi invokes variable aj of Cj FPIA larity CRfg , namely, Ci ai ) Cj aj , Ci ai ) Cj mj ,
mi invokes method mj of Cj FPIM Ci mi ) Cj aj , Ci mi ) Cj mj .
In our investigation, the instances of Ci ai ) Cj aj
and Ci ai ) Cj mj barely occur in real encoding, while
a longest subsequences at last. Fourth, dividing the length of
Ci mi ) Cj aj and Ci mi ) Cj mj occur in most
the longest subsequences by the max length of token
cases. Thus, we only consider the latter two in the next.
sequence 1 and token sequence 2 is the syntactic similarity.
Coupling Dependency 3. This dependency builds a cou-
Since semantic (i.e., semanSimi) and syntactic similarities
pling relation between mi of Ci and aj of Cj , namely, a
(i.e., syntdeSimi) are equally important in determining whether
Method-to-Variable dependency
two entities are similar, we combine the semantic and syntac-
tic similarities by given them equal weights when calculating CR3 ¼ fCi mi ) Cj aj j mi 2 Mi ^ aj 2 Aj g: (9)
the overall similarity (i.e., weightedSimi), i.e., weightedSimi ¼
1
2 ðsemanSimi þ syntdeSimiÞ. Then, we can retrieve a number The most representative instance for CR3 is Static Variable
of functionality-similar starting entities from the change sets Invoking (SAI).
for cinit , which is used to assist the CIA task of cinit . Coupling Dependency 4. This dependency builds a cou-
pling relation between mi of Ci and mj of Cj , namely, a
4.3 Change-Patterns Identification Method-to-Method dependency
The change-patterns refer to the coupling dependencies
from the change starting entity to the impacted entities in a CR4 ¼ fCi mi ) Cj mj j mi 2 Mi ^ mj 2 Mj g: (10)
change set. Since there can be various coupling dependen-
cies between the starting entity and impacted entities [23], CR4 builds coupling relation at the method level. E.g., Static
there are many types of change-patterns. According to the Method Invoking (SMI); Construction Method Invoking (CMI).
study [23] as well as our observation from the object-ori- In addition to the above mentioned instances for each
ented programming paradigm in previous study [13], we coupling dependencies, there is a most common instance in
get 21 common instances of coupling dependencies from real encoding [25]. This kind of instance uses Cj to define an
the source code, and these coupling dependencies may exist variable ai contained in Ci , where ai may be a Method
at the class level, method level, and variable level. Member Variable or Class Member Variable or Function Parame-
Coupling Dependency 1. For a change set S, a starting class ter. Generally, the defined variable ai is usually used in a
Ci 2 S, and an impacted class Cj 2 S. If Ci and Cj establish method mi of Ci , and there are three usages: 1 using ai
coupling relationship at the class level, they satisfy the directly in a certain method mi of Ci . Because ai is a vari-
Class-to-Class coupling dependency, denoted by able declared by Cj and ai is used in a certain method mi
of Ci , thus we can regard the coupling relation between Ci
CR1 ¼ fCi ) Cj j Ci 2 S; Cj 2 Sg; (6) and Cj as Method-to-Class. E.g., the instances MMAUA,
CMAUA and FPUA satisfy this case, and detailed descrip-
where ’)’ denotes the coupling relationship. In Java pro- tion is shown in Table 1; 2 invoking the variable aj of Cj
gram syntax, Inheritance(IH) and Implementing Interface(II) via ai (because ai is declared by Cj ), and Ci and Cj builds
[24] are the most common cases that satisfy CR1 . a Method-to-Variable coupling relation. As Table 1 shows,
A class Ci includes a sets of variables Ai and methods Mi . the instances MMAIA, CMAIA and FPIA satisfy this case; 3
Namely, Ci = fAi ; Mi g, and Ai = fai1 ; ai2 ; . . . ; ait g, Mi = invoking the method mj of Cj via ai , and Ci and Cj builds
fmi1 ; mi2 ; . . . ; mih g. Ai and Mi are the set of variables and a Method-to-Method coupling relation. As Table 1 shows,
methods of Ci , respectively. Similarly, Cj = fAj ; Mj g, and the instances MMAIM, CMAIM and FPIM satisfy this case.
Aj = faj1 ; aj2 ; . . . ; aju g, Mj = fmj1 ; mj2 ; . . . ; mjv g. Aj and Mj We have classified the coupling dependencies into 4
are the set of variables and methods of Cj , respectively. types at class, variable and method levels. Table 2 shows
Coupling Dependency 2. A method mi of Ci uses the class the 4 coupling dependencies and their corresponding for-
Cj , but it is not intended to define a variable by Cj or call malization expressions and 18 instances. To identify the
the static variables and methods of Cj , the situation satisfies coupling dependencies that two classes satisfy, we get the
the Method-to-Class coupling dependency variable and method definitions and the variable and
method invocations in the two classes via analyzing their
CR2 ¼ fCi mi ) Cj j mi 2 Mi g: (7)
abstract syntax trees by applying the JavaParser5 APIs.
The instances of CR2 are: Type-Casting (TC), Instanceof (IO),
Return Type (RT), and Exception Throws (ET), etc. 5. https://javaparser.org/
TABLE 2
Coupling Dependencies
Name Coupling Dependencies Formalization Instances

CR1 Class-to-Class Ci ) C j IH, II
CR2 Method-to-Class Ci mi ) Cj TC, IO, RT, ET , MMAUA, CMAUA, FPUA
CR3 Method-to-Variable Ci mi ) Cj aj SAI, MMAIA, CMAIA, FPIA
CR4 Method-to-Method Ci mi ) Cj mj SMI, CMI, FPIM, MMAIM, CMAIM
After getting the coupling dependencies between the

starting class Ci and an impacted class Cj , the change-pat- confðcinit ; ci Þ ¼P ðcinit ; ci Þ
tern between Ci and Cj can be represented by a vector X
k
Vcp ðCi ; Cj Þ with 18 dimensions þ cinit ; c~j ÞÞ:
JSimiðVcp;k ðcinit ; ci Þ; Vcp ð~
1
Vcp ðCi ; Cj Þ ¼ < IH; II; TC; IO; . . . ; CMAIM > : (11) (14)
We will determine the values of t and h via the compari-
The value of each dimension in Vcp ðCi ; Cj Þ is the number son experiments, and the optimal values of t and h are 20
of a certain coupling dependency that the two classes satisfy. and 0.8. More discussion regarding the t and h can be found
in Sections 8.1 and 8.2.
4.4 Change-Patterns Mapping
For a starting entity cinit in the current CIA task, we can 5 CASE STUDY DESIGN
retrieve t equivalent starting entities c~init from t historical
To have a meaningful evaluation, we outline 3 change
change sets. Then, the change-patterns between c~init and the
impact analysis methods (namely, ImpactMiner, JRipples
rest of the entities (i.e., c~j ) in a change set can be mapped to
and ROSE) after applying our boosting mechanism. Besides,
the current CIA task to boost the rankings of the entities
we empirically investigate how our approach performs by
that are truly impacted by cinit .
comparing it with a random approach.
We employ Jaccard similarity [26] to measure the similar-
ity of change-patterns. Jaccard similarity is suitable to deal
5.1 Datasets
with the case in this study, because the positive matching of
To collect the historical change sets, we downloaded 182
the coupling dependency on a certain dimension (a certain
projects from Github6 and SourceForge,7 the historical
dimension in two vectors have the same value) is more
change set is also known as commit in most studies [9], [27].
meaningful than negative matching (a certain dimension in
The projects are selected based on the following rules: First,
two vectors have different values). In the similarity mea-
we require that all the selected projects are open source and
surement, the number of negative matching is considered to
implemented in Java. Second, we selected projects that have
be insignificant, and Jaccard similarity can ignore the influ-
active updates in its evolution history. Third, we selected
ence of negative matching.
projects belonging to different domains including graphics
We first find t equivalent starting entities from t historical
editor, text editor, game, programming frame, middleware
change sets for a starting entity cinit according to the code
system, etc. Combining all the above factors, we selected the
semantic and syntactic similarities. Then, for a change-pattern
cd 182 projects from different domains. Not all the commits are
< cinit ! ci >; we try to find its similar change-patterns
cd useful due to the number of classes contained in the commits.
< c~init !~ cj > from the t change sets via the Jaccard Since our approach tries to find the similar change-patterns
similarity from the historical commits, we filter out the commits with
less than 2 classes files (including the commits containing
cinit ; c~j Þ
Vcp ðcinit ; ci Þ \ Vcp ð~ non-source code files). After applying the filter rule, there
cinit ; c~j ÞÞ ¼
JSimiðVcp ðcinit ; ci Þ; Vcp ð~ ;
cinit ; c~j Þ
Vcp ðcinit ; ci Þ [ Vcp ð~ are 94,778 commits in total. A local repository is built to save
(12) these commits, and we use the method described in previous
sections to identify the starting class in each commit, and
generate the change-patterns for each commit.
where, i 2 1; . . . ; n; j 2 1; . . . ; m. When the value of JSimi
We conduct change impact analysis for 7 Java open-
cinit ; c~j ÞÞ is greater than h, we use the
ðVcp ðcinit ; ci Þ; Vcp ð~ source projects in our evaluation. The selected projects are
cd
change-pattern < c~init !~ cj > to boost the final confidence commonly evaluated projects in most of the software engi-
of entity ci . Then, the Pscp ðcinit ; ci Þ in the formula (3) is neering related research [13], [14], [15], i.e., FreeCol [28],
HSQLDB [29], JAMWiki [30], jEdit [31], JHotDraw [32],
X
k Makagiga [33], OmegaT [34]. Since these 7 projects have
Pscp ðcinit ; ci Þ ¼ cinit ; c~j ÞÞ;
JSimiðVcp ðcinit ; ci Þ; Vcp ð~ (13) more than ten years evolution history, they have a relatively
1 high number of commits. The detailed information of the
projects is shown in Table 3.
where, k is the number of change-patterns that their
cinit ; c~j ÞÞ values are greater than h.
JSimiðVcp ðcinit ; ci Þ; Vcp ð~ 6. https://github.com/
The final confidence for ci is 7. https://sourceforge.net/
TABLE 3 histories of the projects. We also use the default setting of

Projects Used in the Case Study ROSE for CIA tasks.
Recall and Precision are widely used to evaluate the per-
Commits Commits
Projects Version Amount Projects Version Amount formance of impact analysis methods [2], [20], [23], which
can evaluate the difference between the impact set esti-
FreeCol 0.3-1.0 2,136 HSQLDB 1.80-2.33 1,137
mated by tools and the actual impact set. Given a starting
JAMWiki 0.5-1.3 899 jEdit 4.0-4.5 1,665
JHotDraw 7.1-7.5 378 Makagiga 2.0-4.12 4,072 class cinit , Eimp represents the impact set estimated by tools,
OmegaT 2.05-3.54 837 and Rimp represents the actual impact set. Then, the recall
and precision are defined as
Note that the 7 datasets are included in the 182 projects, jEimp \ Rimp j
recall ¼ 100% (15)
because the change-patterns in previous commits of the jRimp j
7 projects can be used to guide the current CIA tasks, just
jEimp \ Rimp j
like the traditional MSR based CIA methods, i.e., within- precision ¼ 100%: (16)
project scenario. jEimp j
In many cases, we will evaluate the performance of an

5.2 Evaluation Methodology impact analysis approach under a given cut-off point [2]
We first employ ISC [12] to identify a starting class for (e.g., 5, 10, 20, 30, 40, etc.). That is, we rank the esti-
each commit in Table 3, then the other classes in the same mated impacted classes in descending order, and a given
commit are regarded as the truly impacted ones by the cut-off point will derive an estimated impact set (E.g., a
starting class (ground truth). After that, we use the 3 tra- cut-off point of 5 indicates that the estimated impact set
ditional methods (i.e., ImpactMiner, JRipples and ROSE) with our approach contains 5 entities.), then we can eval-
to analyze the impact set in each project system for each uate the recall and precision of the impact analysis
starting class, and generate a ranking list of the impacted approach under such an estimated impact set. f-measure
classes. The three CIA tools are selected owing to their is the harmonic mean of precision and recall, which can
open-source availability. At last, we apply our boosting be also used to evaluate the performance of the CIA
mechanism, and try to improve the rankings of the truly tools
impacted classes in the list.
When employing ImpactMiner for the CIA tasks, we use 2 precision recall
f measure ¼ 100%: (17)
commit message as textual information to estimate an precision þ recall
impact set via IR technique, known as IRCR component in
ImpactMiner, then we use the second component (i.e.,
Histseed ) of ImpactMiner to mine the past commits of the 6 RESULTS ANALYSIS
starting class to estimate the impact set. To apply JRipples In this paper, we focus on the performance of applying our
to the CIA tasks, we download a complete code of the ver- boosting method to the traditional CIA methods, and we
sion the commit locates in, then we can employ JRipples to investigate the likely benefits of our boosting method for
generate the class dependencies for this version. For the the CIA tasks. The cut-off points in this study are 5, 10, 20,
starting class in a commit, the “next” classes given by JRip- 30 and 40, and the h is 0.8, and the value of t for Impact-
ples are regarded as impact set. JRipples is a plugin of Miner, JRipples and ROSE is 20, and we will discuss the t
Eclipse, and we use the default setting of JRipples for CIA and h choice effect in Sections 8.1 and 8.2.
tasks. Fig. 4 shows the operation interface of ImpactMiner Table 4 presents the results for ImpactMiner as well as the
and JRipples. To run ROSE, we download all the commits results after applying our boosting method, where “Delta
in the evolutionary histories of the 7 projects, then we utilize Improv” represents the delta improvement of the boosting
ROSE to detect the impact set by analyzing the evolutionary method versus the traditional CIA tool under a specific cut-
Fig. 4. Change impact analysis tools.

TABLE 4
Accuracy Boosting for ImpactMiner on all Datasets Using Various Cut-Off Points
Recall(%) Precision(%)
Datasets Approach
5 10 20 30 40 5 10 20 30 40
FreeCol ImpactMiner 9.51 16.81 27.20 36.79 45.73 7.33 6.75 5.67 5.27 4.95
Boosting 15.27 22.76 33.32 41.15 48.27 12.38 9.55 7.07 5.91 5.23
Delta Improv +5.76 +5.95 +6.12 +4.36 +2.54 +5.05 +2.80 +1.40 +0.64 +0.28
HSQLDB ImpactMiner 9.49 16.13 24.66 29.82 34.60 10.90 9.45 7.41 6.15 5.48
Boosting 15.09 21.68 29.89 34.92 38.21 16.85 12.64 9.35 7.45 6.24
Delta Improv +5.60 +5.55 +5.23 +5.10 +3.61 +5.95 +3.19 +1.94 +1.3 +0.76
JAMWiki ImpactMiner 14.76 20.18 27.24 30.07 31.11 11.69 8.62 6.13 4.67 3.67
Boosting 16.26 22.65 28.55 30.54 31.50 13.81 9.88 6.59 4.85 3.75
Delta Improv +1.5 +2.47 +1.31 +0.47 +0.39 +2.21 +1.26 +0.46 +0.18 +0.08
jEdit ImpactMiner 14.71 23.26 30.82 34.70 37.71 11.44 10.22 7.13 5.56 4.58
Boosting 19.79 26.12 33.21 36.02 38.50 16.46 11.30 7.74 5.79 4.72
Delta Improv +5.08 +2.86 +2.39 +1.32 +0.79 +5.02 +1.08 +0.61 +0.23 +0.14
JHotDraw ImpactMiner 7.32 12.20 19.08 23.86 27.38 9.26 8.16 6.62 5.49 4.52
Boosting 9.53 14.26 20.80 24.27 27.67 11.47 9.41 7.24 5.59 4.61
Delta Improv +2.21 +2.06 +1.72 +0.41 +0.29 +2.21 +1.25 +0.62 +0.10 +0.09
Makagiga ImpactMiner 19.38 28.11 38.94 46.16 51.89 12.52 9.34 6.67 5.46 4.66
Boosting 26.66 34.57 44.19 50.28 54.69 17.59 11.89 7.78 6.02 4.99
Delta Improv +7.28 +6.46 +5.25 +4.12 +2.80 +5.07 +2.55 +1.11 +0.56 +0.33
OmegaT ImpactMiner 26.24 38.09 48.77 53.23 56.39 16.53 12.26 8.05 6.11 4.91
Boosting 35.36 43.71 51.00 54.91 57.93 21.98 14.21 8.48 6.30 5.06
Delta Improv +9.12 +5.62 +2.23 +1.68 +1.54 +5.45 +1.95 +0.43 +0.19 +0.15
Avg Improv (%) 5.22 4.42 3.46 1.07 1.71 4.41 2.01 0.94 0.46 0.26
Rlt Improv (%) 36.03 19.99 11.18 2.94 4.20 21.98 14.21 8.48 6.30 5.06
off point. We found that applying our boosting method on remain unchanged (e.g., in FreeCol, JAMWiki, JHotDraw,
ImpactMiner improves the performance over any dataset Makagiga, OmegaT), this is because the number of
comparing with the standalone ImpactMiner. The maxi- impacted entities estimated by JRipples is less than or
mum improvement for recall is 9.12 percent when the equal to 40, and our boosting method works on an initial
cut-off point is 5 on the dataset OmegaT, while the mini- impact set estimated by JRipples, then our method cannot
mum improvement for recall is 0.29 percent when the be superior to JRipples when the total impacted entities
cut-off point is 40 on the dataset JHotDraw. Meanwhile, estimated by JRipples is less than the cut-off points, i.e., 40.
the maximum improvement for precision is 5.59 percent Table 5 also presents the precision for JRipples as well as
when the cut-off point is 5 on the dataset HSQLDB, while the precision after applying the boosting method. The
the minimum improvement for precision is 0.08 percent results show a positive improvement for the precision at
when the cut-off point is 40 on the dataset JAMWiki. The the cut-off points of 5, 10, 20. Table 5 also shows the rela-
average improvements (i.e., Avg Improv, also called abso- tive improvements (i.e., Rlt Improv). The maximum rela-
lute improvement) for recall and precision are 5.22 per- tive improvements of recall and precision for JRipples are
cent and 4.41 percent at the cut-off point of 5, which 6.48 and 6.52 percent at the cut-off point of 5.
means that our method can improve the rankings of the At the same time, we can observe that the average boosting
actual impacted classes. Table 4 also shows the relative improvements on ImpactMiner are more significant than
improvements of the recall or precision achieved by our those on JRipples. This is because the initial impact set esti-
boosting method when comparing with those of Impact- mated by ImpactMiner contains more truly impacted classes,
Miner, i.e., Rlt Improv. The maximum relative improve- and then our method has more chance to boost the sorting
ments of recall and precision for ImpactMiner are 36.03 positions of the actual impact class forward in the ranking list.
and 21.98 percent at the cut-off point of 5. Table 6 presents the recall and precision for ROSE before
Table 5 presents the recall and precision after applying and after applying the boosting method, and the maximum
the boosting method on JRipples. The results indicate a relative improvements of recall and precision for ROSE are
positive improvement for the recall in most of datasets 12.39 and 11.81 percent at the cut-off point of 5. We can
with the cut-off point of 5 when applying the boosting observe that most of the recall and precision are improved
method. When setting the cut-off points as 10 and 20, the when we apply the boosting method to ROSE, while there
recall also shows a positive improvement in most of the are some exceptions, such as the recall and precision after
datasets except for the datasets JHotDraw and OmegaT, applying the boosting method at the cut-off points of 5 and
where the recall shows a slight descent (e.g., 0.44 percent 10 on project FreeCol. In this case, the boosting method
of decline on JHotDraw). When setting the cut-off point as shows a negative effect on the identification of the actual
30, the recall shows a positive improvement. When setting impacted classes of ROSE. However, with the improvement
the cut-off point as 40, we can also observe some recalls of the cut-off point, the boosting method shows a positive
TABLE 5
Accuracy Boosting for JRipples on all Datasets Using Various Cut-Off Points
Datasets Approach
5 10 20 30 40 5 10 20 30 40
FreeCol JRipples 16.40 25.50 31.13 35.01 35.49 15.06 11.57 7.06 5.26 4.01
Boosting 17.38 26.18 31.77 35.08 35.49 14.98 11.66 7.19 5.28 4.01
Delta Improv +0.98 +0.68 +0.64 +0.07 +0.00 –0.07 +0.09 +0.13 +0.02 +0.00
HSQLDB JRipples 15.63 22.49 31.41 37.92 40.79 18.23 13.96 10.12 8.21 6.81
Boosting 16.84 24.96 32.99 38.18 40.89 19.71 15.46 10.60 8.28 6.77
Delta Improv +1.21 +2.47 +1.58 +0.26 +0.10 +1.48 +1.50 +0.48 +0.07 –0.04
JAMWiki JRipples 24.62 32.48 36.10 37.12 37.18 15.79 11.11 6.46 4.48 3.38
Boosting 29.63 33.65 36.24 37.12 37.18 20.58 12.05 6.52 4.48 3.38
Delta Improv +5.01 +1.17 +0.14 0.00 0.00 +4.79 +0.94 +0.06 0.00 0.00
jEdit JRipples 26.10 35.64 44.83 51.26 54.32 23.31 16.43 11.02 8.83 7.22
Boosting 28.26 37.60 46.09 51.85 54.56 24.48 17.40 11.37 8.93 7.23
Delta Improv +2.16 +1.96 +1.26 +0.59 +0.24 +1.17 +0.97 +0.35 +0.10 +0.01
JHotDraw JRipples 11.63 12.72 12.72 13.17 13.17 13.10 8.28 4.14 2.99 2.24
Boosting 11.63 12.28 12.72 12.72 13.17 13.10 7.59 4.14 2.76 2.24
Delta Improv 0.00 –0.44 0.00 –0.35 0.00 0.00 –0.69 0.00 –0.23 0.00
Makagiga JRipples 24.33 27.57 29.47 30.28 30.57 14.77 8.67 4.74 3.27 2.48
Boosting 25.05 27.90 29.49 30.39 30.57 15.40 8.87 4.75 3.29 2.48
Delta Improv +0.72 +0.33 + 0.02 +0.11 0.00 +0.63 +0.30 +0.01 +0.02 0.00
OmegaT JRipples 33.55 35.91 36.10 36.10 36.10 20.99 11.41 5.73 3.82 2.86
Boosting 33.35 35.91 36.10 36.10 36.10 20.92 11.41 5.73 3.82 2.86
Delta Improv –0.20 0.00 0.00 0.00 0.00 –0.07 0.00 0.00 0.00 0.00
Avg Improv (%) 1.41 0.88 0.52 0.08 0.05 1.13 0.43 0.15 0.00 0.00
Rlt Improv (%) 6.48 3.20 1.64 0.23 0.14 6.52 3.70 2.13 0.00 0.00
TABLE 6
Accuracy Boosting for ROSE on all Datasets Using Various Cut-Off Points
Datasets Approach
5 10 20 30 40 5 10 20 30 40
FreeCol ROSE 22.09 33.04 44.19 50.26 54.00 17.39 13.33 9.11 7.02 5.75
Boosting 19.53 31.60 46.33 52.50 56.13 15.45 12.76 9.58 7.37 6.01
Delta Improv –2.56 –1.44 +2.14 +2.24 +2.13 –1.94 –0.57 +0.47 +0.35 +0.26
HSQLDB ROSE 16.12 23.14 30.69 36.15 40.07 16.23 12.56 8.93 7.22 6.15
Boosting 16.77 25.23 34.12 39.09 42.72 16.90 14.03 10.17 7.99 6.65
Delta Improv +0.65 +2.09 +3.43 +2.94 +2.65 +0.67 +1.47 +1.24 +0.77 +0.50
JAMWiki ROSE 34.29 45.19 55.01 61.57 65.26 28.73 19.46 12.06 9.19 7.35
Boosting 37.96 49.33 60.32 64.13 66.91 31.81 21.54 13.42 9.63 7.59
Delta Improv +3.67 +4.14 +5.31 +2.56 +1.65 +3.08 +2.08 +1.36 +0.44 +0.24
jEdit ROSE 26.62 39.52 50.98 57.95 61.74 22.11 16.76 11.22 8.69 7.03
Boosting 31.72 42.76 53.31 59.38 63.46 25.76 18.31 11.62 8.85 7.25
Delta Improv +5.1 +3.24 +2.33 +1.43 +1.72 +3.65 +1.55 +0.40 +0.16 +0.22
JHotDraw ROSE 27.64 37.52 45.48 50.87 53.67 23.56 16.53 10.30 7.83 6.22
Boosting 31.38 41.09 49.78 53.02 55.32 27.12 18.49 11.42 8.22 6.48
Delta Improv +3.74 +3.57 +4.30 +2.15 +1.65 +3.56 +1.96 +1.12 +0.39 +0.24
Makagiga ROSE 22.10 29.20 37.24 42.07 45.94 14.15 9.78 6.51 5.00 4.13
Boosting 27.51 34.07 40.83 44.56 48.00 18.03 11.61 7.23 5.35 4.34
Delta Improv +5.41 +4.87 +3.59 +2.49 +2.06 +3.88 +1.83 +0.72 +0.35 +0.21
OmegaT ROSE 31.91 40.74 48.76 51.75 54.26 21.90 14.44 9.02 6.49 5.08
Boosting 38.30 44.45 51.03 53.30 55.11 26.03 15.71 9.37 6.63 5.16
Delta Improv +6.39 +3.71 +2.27 +1.55 +0.85 +4.13 +1.27 +0.35 +0.14 +0.08
Avg Improv (%) 3.2 2.88 3.33 2.19 1.82 2.43 1.37 0.81 0.37 0.25
Rlt Improv (%) 12.39 8.13 7.48 4.38 3.39 11.81 9.32 8.44 5.03 4.2
Fig. 5. t choice effects on the performance of ImpactMiner, JRipples, and ROSE.
effect on the CIA task of ROSE. Meanwhile, the average commit (#12780) from jEdit and the red dotted circle is the
recall and precision on all the datasets are improved. commit (#1776) from Flyway (Flyway is included in the 182
Based on these results, we conclude that the combination projects). Class JEditTextArea is the change starting point,
of traditional CIA methods and our boosting method is and classes ChunkCache, DisplayManager and TextAr-
shown to be superior to the standalone CIA methods in eaPainter are the actual impacted classes by JEditTex-
most cases, and our boosting method does improve the tArea. In Fig. 6b (left side), Impactminer gives an initial list
average accuracy of the traditional CIA methods in the task of the classes impacted by JEditTextArea. We can observe
of change impact analysis on multiple datasets. that the ranks of the three actual impacted classes are 1, 4,
and 12. Then, we apply our boosting method to the initial
7 QUALITATIVE ANALYSIS result given by Impactminer, and the boosting method rec-
ommends the change-pattern (i.e., < FPIM, CMAIM, CMI > )
In this section, we try to systematically analyze where do between HdfsBlobContainer and HdfsBlobContainer
our boosting method benefits come from. First, we illustrate to the CIA task. Since this change-pattern is similar with the
several examples regarding how the change-patterns affect ones between JEditTextArea and its actual impacted clas-
the positions of the impacted classes in the ranking list. Sec- ses, our boosting method improves the ranks of the three clas-
ond, we empirically analyze the frequency of similar ses in the list, as shows in In Fig. 6b (right side).
change-patterns in historical change sets and further pro- Fig. 7 shows an example (coming from jEdit, commit
vide an empirical evidence to support our boosting method. #2684 (blue dotted circle) and OKhttp, commit #2132 (red
Third, we empirically analyze how many similar change-
patterns coming from across-project and within-project
cases can be utilized by our boosting method.
7.1 Ranking Boosting Examples

We perform a qualitative analysis on the results in order to
better understand where our boosting method benefits come
from. Specifically, we analyze several cases with comparing
the initial ranking lists by the CIA tools (e.g., Impactminer)
and the reordered ranking lists by our boosting method.
Fig. 6 shows an example of applying our boosting method
on Impactminer. In Fig. 6a, the blue dotted circle is the Fig. 6. A boosting case for Impactminer.
TABLE 7
The Top 10 Change-Patterns Across Projects
# of Projects
No. Change-patterns (18 dimens) Amount Crossed
1 <0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0> 18,555 173
2 <0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0> 15,049 159
3 <0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0> 7,061 156
Fig. 7. A boosting case for ROSE. 4 <0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0> 5,531 154
5 <0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0> 3,494 145
6 <0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0> 3,415 143
7 <0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0> 3,385 143
8 <0 0 0 0 0 0 0 0 0 0 0 2 0 1 0 0 0 0> 1,930 129
9 <0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0> 1,915 113
10 <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1> 1,879 130
TABLE 8
The Percentage of Valid Change-Patterns Coming From
Fig. 8. A bad case for JRipples. Cross-Project and Within-Project Cases
dotted circle)) of applying our boosting method on ROSE. As Datasets ImpactMiner JRipples ROSE
Fig. 7a shows, Buffer is the change starting point, and it within cross within cross within cross
builds a change-pattern of < MMAUA, FPIM > with Tex- FreeCol 14,579 7,115 1,853 924 13,762 6,375
tAreaPainter, and a change-pattern of < FPIM, MMAIM, HSQLDB 7,997 858 7,557 666 5,936 707
CMAIM > with OffsetManager, and a change-pattern of JAMWiki 972 478 1,052 423 1,399 704
< FPIM, MMAIM > with JeditTextArea. Our boosting jEdit 6,402 4,663 6,416 4,599 4,819 3,874
method recommends the change-patterns of commit #2132 JHotDraw 416 998 55 175 326 513
Makagiga 10,086 4,836 7,283 3,195 6,839 3,377
from project OKhttp to the CIA task, and both the change- OmegaT 1,200 2,124 871 1,378 766 1,349
patterns between Request and HttpResponseCache, Percentage 66.2% 33.8% 68.8% 31.2% 66.7% 33.3%
Request and HttpEngine, are similar with the change-
pattern between Buffer and TextAreaPainter. As a
result, TextAreaPainter is promoted to the first ranking We count the frequency of the change-patterns across
in the list, as Fig. 7b shows. Meanwhile, benefitting from the different projects. Specifically, for the commits coming from
change-pattern between Request and CacheStrategy, the 182 projects (i.e., the dataset), we extract the change-pat-
the rank of OffsetManager is also improved. terns between the starting class and the rest of classes in a
Fig. 8 shows a bad example (coming from jEdit, commit commit, and then we cluster the same change-pattern in the
#2160 (blue dotted circle) and HSQLDB, commit #4931 (red commits of the 182 projects. In total, we find 233,348
dotted circle)) of applying our boosting method on JRipples, change-patterns in these projects, in which 213,554 change-
where the rank of the actual impacted class goes down patterns can find at least one identical change-pattern, up to
when applying the boosting method. As Fig. 8a shows, 91.5 percent. Table 7 shows the top 10 most frequent
TextAreaPainter is the actual impacted class by the change-patterns, and the number of change-patterns and
change starting point JeditTextArea, while View is not. the number of projects involving in the change-patterns can
Due to the code similarity between JeditTextArea and also be found in the table.
Expression, our boosting method recommends the We can observe that many frequent change-patterns are
change-patterns of commit #4931 from project HSQLDB to across many different projects. E.g., the change-pattern 1
the CIA task. Then, the change-pattern between Expres- (i.e., Implementing Interface, II) is across 173 projects. This sta-
sion and FunctionSQLInvoked is similar with the one tistical result provides a solid foundation for us using the
between JeditTextArea and View, and View is pro- similar change-patterns coming from other projects to boost
moted to the 3rd ranking, and TextAreaPainter is change impact analysis methods.
demoted to the 4th ranking in the list. Then, the actual
impacted class is pulled down in the list. This would
explain why our boosting method has side effects on some 7.3 The Percentage of Valid Change-Patterns
datasets such as JHotDraw in Table 5. We allow the boosting method to find the similar change-
patterns from 20 commits in the experiment. If the change-
patterns in the 20 commits can directly affect the rankings of
7.2 Similar Change-Patterns the classes in the original impact set, we regard it as a valid
We state that the proposed boosting method can use the his- one. Then, the valid change-patterns may come from the his-
torical change-patterns in a cross-project scenario to boost torical commits of the current project, i.e., within-project
CIA tools. The premise of this claim is that there are a lot of case, or coming from other projects, i.e., cross-project case.
similar (or same) change-patterns across projects, and then We count the number of the valid change-patterns com-
the proposed boosting method can utilize the similar ing from the two cases, respectively. We can observe from
change-patterns coming from other projects. Table 8 that about one third of the valid change-patterns are
TABLE 9
Accuracy Boosting for ImpactMiner When Applying Cross- and Within-Project Change-Patterns
Recall Precision
Datasets Approach
5 10 20 30 40 5 10 20 30 40
FreeCol ImpactMiner 9.51 16.81 27.2 36.79 45.73 7.33 6.75 5.67 5.27 4.95
cross 12.88 20.04 30.8 39.44 47.13 10.17 8.26 6.46 5.64 5.10
within 14.15 21.91 32.26 40.96 47.92 11.59 9.22 6.79 5.86 5.17
HSQLDB ImpactMiner 9.49 16.13 24.66 29.82 34.60 10.90 9.45 7.41 6.15 5.48
cross 11.51 18.22 26.85 31.63 35.75 13.35 10.64 8.12 6.58 5.75
within 14.44 21.25 28.88 34.09 37.97 15.61 12.23 8.97 7.19 6.15
JAMWiki ImpactMiner 14.76 20.18 27.24 30.07 31.11 11.69 8.62 6.13 4.67 3.67
cross 15.26 22.15 27.88 30.22 31.33 12.78 9.48 6.33 4.74 3.74
within 16.41 22.15 28.31 30.28 31.34 13.70 9.57 6.45 4.76 3.75
Jedit ImpactMiner 14.71 23.26 30.82 34.7 37.71 11.44 10.22 7.13 5.56 4.58
cross 16.73 24.83 32.35 35.54 38.1 13.58 10.81 7.51 5.69 4.66
within 19.32 25.93 32.84 35.99 38.72 15.78 11.24 7.65 5.79 4.73
JhotDraw ImpactMiner 7.32 12.2 19.08 23.86 27.38 9.26 8.16 6.62 5.49 4.52
cross 8.27 14.02 20.62 24.61 27.33 10.00 8.75 7.06 5.51 4.56
within 9.60 14.69 21.93 24.45 27.10 10.59 8.75 7.13 5.61 4.52
Makagiga ImpactMiner 19.38 28.11 38.94 46.16 51.89 12.52 9.34 6.67 5.46 4.66
cross 24.90 32.38 41.68 48.71 53.89 16.22 10.84 7.23 5.77 4.86
within 25.66 33.95 43.57 49.78 54.74 16.71 11.42 7.57 5.92 4.95
OmegaT ImpactMiner 26.24 38.09 48.77 53.23 56.39 16.53 12.26 8.05 6.11 4.91
cross 33.24 42.58 50.94 54.54 57.55 20.74 13.78 8.42 6.22 5.02
within 34.90 43.96 50.52 54.31 57.50 21.55 14.12 8.36 6.22 5.02
Avg Improv (cross) 3.05 2.78 2.06 1.44 0.90 2.45 1.11 0.49 0.21 0.13
Rlt Improv (cross) 20.28 12.94 7.00 3.90 1.98 21.75 12.34 7.39 3.67 2.72
Avg Improv (within) 4.72 4.15 3.09 2.18 1.50 3.69 1.68 0.75 0.38 0.22
Rlt Improv (within) 34.29 19.99 10.94 6.06 3.48 33.52 18.81 11.20 6.65 4.37
from cross-project case, i.e., 33.8, 31.2 and 33.3 percent for performance of the traditional CIA method even if only the
ImpactMiner, JRipples and ROSE, respectively. Therefore, cross-projects (or within-project) information is available. It
this result confirms that the proposed method can utilize is worth noting that a slight drop in recall is observed on
the change-patterns coming from other projects to boosting some projects when cut-off point is 5 in Table 10 when only
the CIA tasks. In addition, it demonstrates that the historical using the cross-projects information. For example, the recall
change-patterns applying to CIA tasks can be generalized to of JRipples on project HSQLDB is 15.63, while the recall is
a cross-project scenario by our boosting method. 15.59. Meanwhile, the precision of JRipples on project
HSQLDB is improved from 18.23 to 18.73 when cut-off point
is 5. In general, the F-measure (i.e., a weighted harmonic
7.4 Within- and Cross-Project mean of precision and recall) of JRipples has no significant
Change-Patterns Effect difference when cut-off point is 5. When the cut-off points
Section 7.3 shows that about 1/3 of the valid change-pat- go up, we can see the average improvements in term of Avg
terns come from cross-projects, and we want to evaluate the Improv(cross) and Rlt Improv(cross) in Table 10.
performance of the proposed boosting method when only In summary, the recall and precision improvements can
the cross-projects information is available. If our boosting be observed on most of the projects when we only utilize
method works with only the cross-projects information, our the cross-project information, and the proposed boosting
method can be generalized to many more application sce- method is applicable to new project without within-project
narios, such as starting a new project without within-project information.
information. Meanwhile, we also want to evaluate the per-
formance of the proposed boosting method when only the
within-projects information is available. If our boosting 7.5 Practical Significance of the Improvements
method works well, it demonstrates that within-project Tables 4, 5, and 6 show the average improvements in both
change-patterns are also useful to improve the performance precision and recall. Since the average improvements of pre-
of the traditional CIA tools. cision and recall may not directly illustrate the effectiveness
Tables 9, 10 and 11 show the accuracy boosting for of our approach for CIA tasks in practice, we demonstrate
ImpactMiner, JRipples and ROSE when only using cross- the effectiveness of our approach from another perspective.
project or within-project change-patterns. We can observe More precisely, we count the average improved positions of
the average improvements in term of Avg Improv and Rlt the truly impacted classes in the CIA tasks when applying
Improv in Tables 9 and 11. Such improvements indicate our boosting method in each project. For example, when we
that the proposed boosting method can improve the apply our boosting method to ImpactMiner on the project of
TABLE 10
Accuracy Boosting for JRipples When Applying Cross- and Within-Project Change-Patterns
Recall Precision
Datasets Approach
5 10 20 30 40 5 10 20 30 40
FreeCol Jripples 16.4 25.5 31.13 35.01 35.49 15.06 11.57 7.06 5.26 4.01
cross 17.31 26.13 31.36 35.08 35.49 14.81 11.62 7.13 5.28 4.01
within 17.50 25.76 31.80 34.80 35.49 14.98 11.53 7.19 5.25 4.01
HSQLDB Jripples 15.63 22.49 31.41 37.92 40.79 18.23 13.96 10.12 8.21 6.81
cross 15.59 24.1 32.49 38.4 40.74 18.73 14.76 10.48 8.34 6.78
within 16.22 24.68 32.91 38.42 40.88 18.85 14.95 10.49 8.30 6.78
JAMWiki Jripples 24.62 32.48 36.1 37.12 37.18 15.79 11.11 6.46 4.48 3.38
cross 26.11 32.27 36.15 37.12 37.18 18.01 11.35 6.49 4.48 3.38
within 28.92 32.73 36.14 37.12 37.18 19.65 11.58 6.49 4.48 3.38
Jedit Jripples 26.10 35.64 44.83 51.26 54.32 23.31 16.43 11.02 8.83 7.22
cross 24.23 35.79 45.76 51.55 54.38 21.55 16.38 11.31 8.91 7.21
within 27.12 37.14 45.54 51.41 54.38 23.86 17.13 11.20 8.83 7.20
JhotDraw Jripples 11.63 12.72 12.72 13.17 13.17 13.10 8.28 4.14 2.99 2.24
cross 10.69 12.28 12.72 12.72 13.17 13.10 7.59 4.14 2.76 2.24
within 11.43 12.28 12.72 12.72 13.17 12.41 7.59 4.14 2.76 2.24
Makagiga Jripples 24.33 27.57 29.47 30.28 30.57 14.77 8.67 4.74 3.27 2.48
cross 23.96 27.62 29.61 30.34 30.56 14.54 8.74 4.76 3.28 2.48
within 23.34 26.52 28.15 28.71 28.91 13.67 8.02 4.34 2.96 2.23
OmegaT Jripples 33.55 35.91 36.10 36.10 36.10 20.99 11.41 5.73 3.82 2.86
cross 32.38 35.78 36.10 36.10 36.10 20.46 11.37 5.73 3.82 2.86
within 33.72 36.02 36.10 36.10 36.10 21.22 11.41 5.73 3.82 2.86
Avg Improv (cross) –0.19 0.39 0.55 0.30 0.24 0.13 0.15 0.17 0.05 0.03
Rlt Improv (cross) –0.87 1.38 1.69 0.66 0.81 1.47 1.25 2.55 0.86 1.45
Avg Improv (within) 0.95 0.55 0.43 0.01 0.02 0.62 0.21 0.10 –0.02 –0.01
Rlt Improv (within) 4.18 1.79 1.27 –0.30 0.05 3.49 1.04 1.15 –0.97 –0.17
TABLE 11
Accuracy Boosting for ROSE When Applying Cross- and Within-Project Change-Patterns
Recall Precision
Datasets Approach
5 10 20 30 40 5 10 20 30 40
FreeCol ROSE 22.09 33.04 44.19 50.26 54.00 17.39 13.33 9.11 7.02 5.75
cross 19.74 32.00 44.69 51.52 55.48 15.7 12.79 9.23 7.19 5.90
within 18.78 30.68 45.24 51.84 56.09 14.98 12.33 9.32 7.26 5.98
HSQLDB ROSE 16.12 23.14 30.69 36.15 40.07 16.23 12.56 8.93 7.22 6.15
cross 16.65 25.18 32.22 37.54 40.8 16.8 13.72 9.46 7.57 6.28
within 16.44 24.51 33.64 38.55 42.07 16.74 13.39 9.97 7.78 6.47
JAMWiki ROSE 34.29 45.19 55.01 61.57 65.26 28.73 19.46 12.05 9.19 7.35
cross 35.88 47.57 59.43 63.36 66.53 29.96 20.81 13.19 9.47 7.53
within 37.93 48.67 59.83 63.73 67.13 31.27 21.16 13.26 9.56 7.60
Jedit ROSE 23.93 37.87 49.41 56.56 60.54 19.93 16.15 11.1 8.67 7.06
cross 26.30 37.79 50.00 57.24 61.51 21.68 16.37 11.15 8.71 7.16
within 28.25 38.93 50.21 57.25 61.75 22.84 16.78 11.00 8.67 7.17
JhotDraw ROSE 5.57 12.07 13.85 15.20 15.20 6.41 6.79 4.49 3.33 2.50
cross 8.34 13.14 14.49 15.2 15.33 10.51 7.56 4.55 3.33 2.53
within 8.32 13.32 14.98 15.88 16.72 11.03 8.08 4.68 3.46 2.76
Makagiga ROSE 22.10 29.20 37.24 42.07 45.94 14.15 9.78 6.51 5.00 4.13
cross 24.93 32.06 39.51 44.01 47.33 15.84 10.72 6.99 5.23 4.26
within 26.21 32.80 40.00 44.21 47.60 16.88 11.16 7.07 5.29 4.30
OmegaT ROSE 31.91 40.74 48.76 51.75 54.26 21.90 14.55 9.02 6.49 5.08
cross 37.19 44.29 50.81 52.9 55.05 25.19 15.66 9.31 6.60 5.15
within 38.24 44.56 50.45 53.22 55.05 25.82 15.77 9.29 6.60 5.15
Avg Improv (cross) 1.86 1.54 1.71 1.17 0.97 1.56 0.72 0.38 0.17 0.11
Rlt Improv (cross) 12.32 5.44 4.32 2.47 1.92 13.97 6.01 4.16 2.44 2.04
Avg Improv (within) 2.59 1.75 2.17 1.59 1.59 2.12 0.86 0.48 0.24 0.20
Rlt Improv (within) 14.78 5.91 5.92 3.84 4.11 17.43 7.61 5.56 3.80 4.29
TABLE 12 TABLE 13
The Average Improved Positions of the Truly Impacted Classes Recall Comparison for ROSE
Boosting Recall
Projects Datasets h AVG
ImpactMiner JRipples ROSE 5 10 20 30 40
FreeCol 5.60 0.15 3.31 FreeCol 0.5 17.6 29.06 44.31 52.09 56.38 39.89
HSQLDB 6.13 0.71 3.87 0.6 18.65 29.12 45.16 52.49 56.43 40.37
JAMWiki 1.73 1.02 2.71 0.7 19.08 30.01 46.16 52.60 56.41 40.85
JEdit 2.85 0.79 1.62 0.8 19.53 31.60 46.33 52.50 56.13 41.22
JhotDraw 2.68 0.00 3.34 0.9 21.41 33.61 46.16 52.17 55.66 41.80
Makagiga 3.94 0.21 4.07
OmegaT 2.55 0.00 1.89 HSQLDB 0.5 16.71 25.36 34.82 38.97 42.52 31.68
0.6 17.30 25.45 34.5 39.28 42.96 31.89
0.7 16.98 25.28 34.34 39.17 42.49 31.65
0.8 16.77 25.23 34.12 39.09 42.72 31.59
FreeCol, the average improved positions of the truly 0.9 17.31 24.75 32.96 37.71 41.56 30.86
impacted classes is 5.6, which is practical significance for the JEdit 0.5 27.93 39.51 50.27 57.15 62.03 47.38
developers when they do CIA tasks in practice. Imagine that 0.6 28.54 40.04 50.39 57.39 62.21 47.71
ImpactMiner recommends a list of classes to a developer, 0.7 28.37 39.94 50.48 57.51 62.31 47.72
and the truly impacted classes rank at 7 and 8. If a developer 0.8 29.09 39.69 50.34 57.58 62.22 47.78
needs 1 minute (on average) to determine whether a recom- 0.9 28.37 39.94 50.48 57.51 62.31 47.72
mended class is a truly impacted one. Then, before applying
our boosting method, the developer needs at least 8 minutes
to determine the two truly impacted classes. After applying project jEdit, as shown in Figs. 5c, 5f and 5i. Since the three
our boosting method, the truly impacted classes rank at 2 projects are randomly selected and the three CIA tools
and 3, and thus the developer only needs 2 minutes to deter- show best performance when t equals 20 on the projects in
mine the two truly impacted classes. That is, our boosting most of the cases, we set the value of t as 20 when we
method can improve the efficiency of developers doing CIA employ ImpactMiner, JRipples and Rose to conduct the CIA
tasks. Table 12 shows the average improved positions of the tasks in the experiment.
truly impacted classes for each project when we apply the
boosting method to traditional CIA methods. 8.2 h Choice Effect
To evaluate the h choice effect on the performance of our
8 DISCUSSION AND THREATS TO VALIDITY boosting method, we compare the performance of Impact-
In this section, we analyze the parameters that may affect Miner, JRipples and ROSE on the three randomly selected
the experimental results. It is worth noting that the parame- datasets (i.e., HSQLDB, FreeCol, jEdit) across the values of h
ters calibration is performed before we conduct the experi- with 0.5, 0.6, 0.7, 0.8 and 0.9. Tables 13, 14, 15, 16, 17, and 18
ments in Section 6. Meanwhile, the historical change- show the recall and precision when applying different val-
patterns coming from a cross- and within-project scenarios ues of h to ImpactMiner, JRipples and ROSE on the projects
are also discussed in this section. of HSQLDB, FreeCol and jEdit across the cut-off points of 5,
10, 20, 30 and 40.
8.1 t Choice Effect We can observe that ROSE achieves the best average (i.e.,
AVG in Tables 13 and 14) recall and precision when h is 0.9
t is the number of commits that allows our boosting method
on dataset FreeCol, and h is 0.6 on dataset HSQLDB, and h
to find the similar change-patterns from them. To evaluate
is 0.8 on dataset JEdit. It seems that there is no fixed value
the t choice effect on the performance of our boosting
for h that can make ROSE always achieve the best results.
method, we compare the performance of ImpactMiner,
However, there is a pattern on the h choice effect to the per-
JRipples and ROSE on three randomly selected datasets
formance of JRipples, i.e., when h is 0.8, JRipples achieves
(i.e., HSQLDB, FreeCol, jEdit) across the values of t with 5,
the best average recall and precision on the three datasets
10, 15, 20, 25 and 30.
(i.e., AVG in Tables 15 and 16). Similarly, ImpactMiner per-
Fig. 5 shows the average improvement of the f-measure
forms better when h is 0.8 (i.e., AVG in Tables 17 and 18)
when applying different values of t to ImpactMiner, JRip-
half of the time (e.g., average recall on jEdit, average preci-
ples and ROSE on the projects of HSQLDB, FreeCol and
sion on HSQLDB and jEdit). Therefore, we use 0.8 as the
jEdit across the cut-off points of 5, 10, 20, 30 and 40. In gen-
default value of h in the experiment.
eral, we can observe that the average improvements of the
f-measure achieved by ImpactMiner keep growing when
the value of t is less than 20, and ImpactMiner achieves best 8.3 Equivalent Class Choice Effect
improvement when t equals 20 on the projects of HSQLDB In the process of seeking an equivalent class c~init for the
and FreeCol, as shows in Figs. 5a and 5b. Similarly, JRipples starting class cinit , we regard the starting class identified by
and Rose also achieve the best improvement of the f-mea- ISC in each historical commit as the equivalent class, known
sure when t equals 20 on the projects of HSQLDB and Free- as the boosting strategy. To have a meaningful comparison,
Col (Figs. 5d and 5e, 5g and 5h). Meanwhile, we can we also randomly select a class from each historical commit
observe that the performance of the three CIA tools show as the equivalent class, and mapping the change-pattern
little difference when the value of t is greater than 15 on the between the randomly selected class and the rest of classes
TABLE 14 TABLE 16
Precision Comparison for ROSE Precision Comparison for JRipples
Precision Precision
Datasets h AVG Datasets h AVG
5 10 20 30 40 5 10 20 30 40
FreeCol 0.5 14.26 11.69 9.09 7.31 6.04 9.68 FreeCol 0.5 14.13 11.57 7.15 5.28 4.01 8.43
0.6 14.80 11.79 9.31 7.37 6.05 9.86 0.6 14.72 11.62 7.17 5.28 4.01 8.56
0.7 15.07 12.09 9.52 7.39 6.06 10.03 0.7 14.55 11.87 7.17 5.28 4.01 8.58
0.8 15.45 12.76 9.58 7.37 6.01 10.23 0.8 14.98 11.66 7.19 5.28 4.01 8.62
0.9 16.87 13.51 9.55 7.34 5.97 10.65 0.9 14.89 11.53 7.19 5.28 4.01 8.58
HSQLDB 0.5 16.85 13.51 10.26 7.92 6.58 11.02 HSQLDB 0.5 18.11 14.87 10.69 8.25 6.82 11.75
0.6 17.26 13.67 10.26 8.02 6.65 11.17 0.6 18.32 15.03 10.74 8.28 6.80 11.83
0.7 17.11 13.62 10.13 7.93 6.57 11.07 0.7 18.89 14.97 10.66 8.27 6.78 11.91
0.8 16.9 14.03 10.17 7.99 6.65 11.15 0.8 19.71 15.46 10.60 8.28 6.77 12.16
0.9 17.47 13.8 9.72 7.61 6.41 11.00 0.9 19.75 15.01 10.67 8.27 6.75 12.09
jEdit 0.5 22.77 16.88 10.96 8.60 7.17 13.28 jEdit 0.5 21.61 16.49 11.38 8.89 7.16 13.10
0.6 23.08 17.2 10.98 8.62 7.2 13.42 0.6 22.91 16.65 11.38 8.87 7.16 13.39
0.7 23.18 17.26 11.09 8.68 7.23 13.49 0.7 23.71 17.03 11.38 8.89 7.21 13.64
0.8 23.66 17.21 11.07 8.71 7.26 13.58 0.8 24.48 17.40 11.37 8.93 7.23 13.88
0.9 23.18 17.26 11.09 8.68 7.23 13.49 0.9 23.80 17.08 11.24 8.92 7.20 13.65
TABLE 15 TABLE 17
Recall Comparison for JRipples Recall Comparison for ImpactMiner
Recall Recall
Datasets h AVG Datasets h AVG
5 10 20 30 40 5 10 20 30 40
FreeCol 0.5 16.59 25.97 31.58 35.08 35.49 28.94 FreeCol 0.5 13.62 22.18 33.88 43.08 49.36 32.42
0.6 17.04 25.90 31.66 35.08 35.49 29.03 0.6 14.54 23.11 34.61 43.22 49.82 33.06
0.7 16.60 26.63 31.56 35.08 35.49 29.07 0.7 15.28 22.78 33.99 42.51 49.25 32.76
0.8 17.38 26.18 31.77 35.08 35.49 29.18 0.8 15.31 22.80 33.34 41.18 48.28 32.18
0.9 17.12 25.43 31.71 35.08 35.49 28.97 0.9 14.26 21.08 31.76 39.91 47.36 30.87
HSQLDB 0.5 15.74 24.38 33.81 38.11 40.86 30.58 HSQLDB 0.5 16.15 24.13 31.94 35.95 39.17 29.47
0.6 15.71 24.7 33.73 38.14 40.79 30.61 0.6 17.18 24.42 32.12 36.15 38.87 29.75
0.7 16.33 24.46 33.53 38.16 40.80 30.65 0.7 17.27 24.49 31.73 35.90 38.65 29.61
0.8 16.84 24.96 32.99 38.18 40.89 30.77 0.8 17.92 24.35 31.88 35.58 38.38 29.62
0.9 17.15 24.63 33.00 38.13 40.77 30.74 0.9 17.15 23.06 30.65 34.79 37.83 28.69
jEdit 0.5 25.19 36.07 46.13 51.74 54.00 42.63 jEdit 0.5 17.53 25.59 33.51 36.25 39.16 30.41
0.6 26.61 36.29 46.32 51.58 54.18 42.99 0.6 18.64 26.00 33.41 36.46 38.81 30.66
0.7 27.22 36.72 46.16 51.74 54.28 43.22 0.7 18.96 26.42 33.13 36.30 38.71 30.70
0.8 28.26 37.60 46.09 51.85 54.56 43.67 0.8 19.79 26.12 33.21 36.02 38.50 30.73
0.9 26.59 37.00 45.56 51.62 54.34 43.02 0.9 19.18 24.84 32.30 36.63 38.23 30.24
in the commit to the current CIA task (known as the random We can observe from Fig. 9 that the CIA tools with the
strategy). We apply the original CIA tools (i.e., Impact- random strategy outperform the original ones in most
Miner, JRipples and ROSE), the CIA tools with boosting cases, especially for those whose cut-off point is less than
strategy, and the CIA tools with random strategy to the ran- 30. The benefit of the CIA tools with the random strategy
domly selected dataset of jEdit for CIA tasks, and we evalu- comes from the following two cases. First, if the randomly
ate the average precision and recall of these methods across selected class from a commit is exactly the starting class,
5, 10, 20, 30 and 40 cut-off points, with h equal to 0.8. then CIA tools with the random strategy is equivalent to
Fig. 9 shows the accuracy comparison between the the boosting strategy proposed in this paper. Second, if
boosting method and random method for ImpactMiner, the randomly selected class from a commit is not a start-
JRipples and ROSE, respectively. Figs. 9a and 9b show ing class, then the change-pattern between the randomly
ImpactMiner with the boosting strategy achieves the best selected class and the rest of classes in the commit is
precision and recall, and the ImpactMiner with the ran- mapped to the current CIA task. Noting that we require
dom strategy achieves the second best precision and the similarity between change-patterns (i.e., h) should be
recall. Similar results can be observed in Figs. 9c, 9d, 9e, greater than 0.8 in any case. We would use the recom-
and 9f, i.e., JRipples and ROSE with the boosting strat- mended change-patterns to boost the final confidence of
egy achieve the best results, while original JRipples and an impacted class. Therefore, even though we randomly
ROSE achieve worst results. select the equivalent class, the recommended change-
TABLE 18 TABLE 19
Precision Comparison for ImpactMiner The Average Runtime of the Boosting Method
Precision ImpactMiner JRipples ROSE

Datasets h AVG
5 10 20 30 40 Step 1 Step 2 Step 1 Step 2 Step 1 Step 2
FreeCol 0.5 10.83 9.20 7.11 6.14 5.33 7.72 Average Time (Sec) 13.1 62.8 13 73.3 12.8 69.4
0.6 11.87 9.69 7.31 6.18 5.40 8.09
0.7 12.39 9.61 7.21 6.07 5.33 8.12
0.8 12.41 9.57 7.07 5.92 5.23 8.04 average runtime of matching the change-pattern ranges
0.9 11.47 8.83 6.74 5.76 5.15 7.59
from 62.8 seconds to 73.3 seconds on the three CIA tools.
HSQLDB 0.5 14.60 11.79 8.42 6.51 5.44 9.35 The total runtime of the boosting method is about 80 sec-
0.6 15.63 11.91 8.47 6.54 5.40 9.59 onds. The evaluation was conducted on a PC with a com-
0.7 15.84 11.94 8.35 6.49 5.36 9.59
0.8 16.61 11.83 8.38 6.45 5.33 9.72 mon configuration (i.e., Intel Core i5, 3.5 GHz, 32G RAM).
0.9 15.68 11.22 8.01 6.23 5.21 9.27 In a real development environment, the efficiency of the
jEdit 0.5 13.93 11.18 7.90 5.87 4.84 8.74 boosting method can be further increased with better
0.6 15.01 11.34 7.84 5.87 4.79 8.97 computational resources.
0.7 15.38 11.51 7.73 5.82 4.76 9.04
0.8 16.46 11.30 7.74 5.79 4.72 9.20
0.9 15.87 10.87 7.51 5.70 4.67 8.92 8.5 Scalability Discussion
The proposed boosting method is extensible, then we can
take other dependency such as inversion of control (i.e.,
patterns is always similar to the one in the current CIA IoC) [35] into consideration. To detect the IoC change-
task. As a result, the recommended change-patterns will pattern from the source code, we first find the spring.
boost the accuracy of the CIA task. xml file from the root path of the project (if any), and
In summary, we can conclude that the CIA tools with the then analyze the mapping relationship between class
boosting strategy outperform the ones with the random names and their alias in the spring.xml, e.g., class B may
0
strategy in the CIA tasks on dataset jEdit, while the be with an alias of B in the spring.xml. After that, we
CIA tools with the random strategy outperform the go back to the source code of a commit to determine
original ones. whether there is code line of “applicationContext.
0
getBean(B )” in class A. If so, we will check to deter-
mine if the current commit contains both classes A and
8.4 Runtime Discussion B. If all the above conditions are met, IOC dependence
To estimate the average runtime, we divide the process of between A and B is found in this commit. To add the
running the boosting method into two steps, i.e., similar dependencies of IoC to the change-patterns, the vector
starting entity identification (step 1) and change-pattern dimensions of coupling dependencies (i.e., Vcp ðCi ; Cj Þ) is
matching (step 2), and we count the average runtime of changed from 18 to19, and the extra dimension is used
each step. Table 19 shows the results, and we can observe to indicate the dependency of IoC between two classes.
that the average runtime of identifying the similar starting The effort cost on constructing a new change-patterns
entity on the three CIA tools is about 13 seconds, and the mapping repository is low, because we only need to
Fig. 9. Boosting strategy versus random strategy.

TABLE 20
IoC Commits Detected by the Boosting Method
No. Projects # IoC Commits

1 Spring-Security 1
2 Springframework 2
3 Kablink 3
4 Hazelcast 11
5 CAS 96
TABLE 21 Fig. 10. The number of code smells containing in each project
The Code Smells Covered by Jdeodorant and PMD
code smells at the same time, so that they can detect as
Code Smells Jdeodorant PMD
many code smells in the code as possible.
God Method @ @ To detect the code smell from the code of each projects,
Duplicated Code @ @
we need to collect the complete source code of the projects,
God Class @ @
Future Envy @ X because the dataset used in the previous experiments only
Type Checking @ X contain the commits of each project. Since a project may
Data Class X @ have multiple versions of source code, we download the
Long Parameter List X @ version of source code that can cover the latest commit in
our dataset.
After collecting the source code of each project, we use
JDeodorant and PMD to detect the code smells. In particular,
re-detect the IoC dependency for each commit, and the we move the source code of each project to the workspace of
original 18 dimensions of the vector can be reused and Eclipse because JDeodorant and PMD are both Eclipse
keep unchanged. plugin. Since a code smell may be detected by two tools, if
Applying the IoC detection method to dataset of the that happens, we only count once. The two tools found that
182 projects, we find IoC dependency from the commits of 118 projects have code smells, and the number of the code
5 projects, and they are Spring-Security, Springframework, smells ranges from 1 to 832, while the two tools found no
Kablink, Hazelcast and CAS, as shown in Table 20. Spring- code smell in the rest of the projects. Fig. 2 shows the number
Security and Springframework provide the IoC feature, and of code smells containing in each project. Fig. 10 shows the
the rest of the 3 projects is built based on the Spring number of code smells containing in each project.
framework. To determine whether the code quality can affect the per-
formance of our boosting method, we need two datasets:
one containing code smells, i.e., we call it dataset 1, and
8.6 Dataset Quality Effect another one containing no code smell, i.e., we call it dataset
The dataset used in the experiment includes 182 projects. 2. Since it is difficult to judge whether the quality of a proj-
Inevitably, some projects have good-quality code, while ect is poor if it contains 1 or 2 code smells, we select the proj-
some have bad-quality code. We want to study whether ects containing most code smells for analysis. We found 16
there is any relation between using projects datasets with projects that contain more than 100 code smells and thus we
good-quality code and bad-quality code. To achieve this chose these projects for analysis. These 16 projects contain
goal, we conduct a new experiment. We employ two 8,283 commits in total. For a fair comparison, we randomly
famous code smell detection tools (i.e., JDeodorant [36] and select several projects from dataset 2 that they have the simi-
PMD [37]) to detect the code smell in the source code of the lar number of commits as the 16 projects. Specifically, we
182 subject projects, and then we evaluate the quality of the randomly select 22 projects which contain 8,251 commits
projects according to the number of the code smell detected from dataset 2.
from the source code of these projects. Code smells are code Because it is easy to determine which projects the valid
fragments that suggest the possibility of refactoring, which change-patterns come from, a simple and effective evalua-
can degrade quality aspects of the software system [38]. tion way is to analyze the existing experimental results to
Therefore, the number of code smells in a project can reflect find out how many valid change-patterns come from the 16
the quality of the code. projects containing most code smells, and how many valid
JDeodorant is an open-source Eclipse plugin for Java that change-patterns come from the 22 projects containing no
detects five code smells: God Method, Duplicated Code, code smell. Since the valid change-patterns is an equitable
God Class, Feature Envy, and Type Checking. PMD is an mechanism that can be used to indicate the contribution of
open-source tool for Java and an Eclipse plugin that detects the commits of a project to the boosting method, the valid
many problems in Java code, including: God Method, change-patterns can be used to evaluate whether there is
Duplicated Code, God Class, Data Class and Long Parame- any relation between using projects datasets with good-
ter List. We can see from Table 21 that some code smells can quality code and bad-quality code.
be detected by both tools, while some code smells can be For any commit, the boosting method first finds 20
detected by one of them. Then, we chose both tools to detect most similar commits for it, and then we count the valid
TABLE 22 We evaluate the performance of the JRipples when

The Valid Change-Patterns From Case 1 and Case 2 applying the “within-project” and “within-project +
cross-projects” change-patterns. Table 23 shows the accu-
Types # Projects # Commits Valid Change-patterns
racy boosting for JRipples. We can observe the average
Case 1 16 8,283 6.63% improvements in term of Avg Improv and Rlt Improv of
Case 2 22 8,251 6.61%
our boosting method are higher than those of the simpler
boosting method. This result indicates that the change-
patterns come from other projects are useful to improve
change-patterns in the 20 similar commits and how many the performance of the traditional CIA method. In sum-
valid change-patterns come from the 16 projects contain- mary, a simpler boosting method that only using the
ing most code smells (i.e., we call it case 1) and the within-project change-patterns does improve the perfor-
22 projects containing no code smell (i.e., we call it case mance of the CIA tool, but it is even better if we take
2), respectively. At last, we calculate the proportion of the the change-patterns coming from other projects into
valid change-patterns coming from case 1 and case 2 for a consideration.
commit. For other commits, we repeat the calculation,
and we calculate an average proportion of the valid
change-patterns coming from case 1 and case 2 for all 8.8 Threats to Validity
commits. The results in Table 22 shows that the valid In this section, we focus on the threats that could affect the
change-patterns coming from case 1 is 6.63 percent, results of our case studies.
and the valid change-patterns coming from case 2 is Threats to External Validity. One of the threats to external
6.61 percent. There is no significant difference between validity is the potential data leakage from the dataset of 182
these two cases. In summary, we can conclude that there collected projects to the 7 evaluated projects. To avoid the
is no relation between using projects datasets with good- data leakage, given a commit, we only use the commits
quality code and bad-quality code. (both for current projects and other projects) before the cur-
rent commits as reference to find available change-patterns
from them, whereas the commits after the current commit
8.7 A Simpler Boosting Method are not used for current CIA task. This can avoid using the
We found that most of the valid change-patterns come change-patterns contained in the future commits to boosting
from with-projects, then we want to know whether a sim- the CIA task.
pler approach based on logical coupling would help to Another threat to external validity relates to the forks or
boost the performances of the CIA methods that are not duplicated code/commits from the 7 evaluated projects.
based on logical coupling. In the experiment, we evaluate Due to the rise of the pull-request development model, the
the performance of our boosting method on three CIA dataset may contain forks from the evaluated 7 projects.
tool, i.e., ImpactMiner, JRipples, ROSE. ImpactMiner and Although we manually checked that none of the 175 projects
ROSE are the CIA methods based on (or partially based were forked from any of the 7 projects, it is possible that
on) logical coupling of the past commits in the evolution- some of the projects were significantly modified to remove
ary history of a project, while JRipples is not. Then, we the “fork traces”. There might be some duplicated commits
can make comparison for the performance of JRipples in the datasets that were used to boost the CIA tasks. In the
under a simpler logical coupling boosting method and future, further investigation by analyzing the forked proj-
our boosting method. For a simpler boosting method, ects is needed to mitigate this threat.
JRipples can only use the logical coupling (i.e., change- The third threat to external validity relates to the usabil-
patterns) come from the evolutionary history of the same ity of the boosting method. It is possible to use the same
project, i.e., within-project. In contrast, our boosting projects (i.e., 182 collected projects) to do the CIA task for
method can use the logical coupling (i.e., change-patterns) other users. For example, the user can first employ the a tra-
come from the same project and other projects (i.e., ditional CIA tool (e.g., ImpactMiner) to determine an initial
within-project + cross-projects) to boost the performance impacted set according to the starting entity the user pro-
of JRipples. As a result, the contrast experiment turns vided, and then use the boosting method to find the similar
into a comparison between applying the “within-project” change sets from the evolutionary histories of many projects
and “within-project + cross-projects” change-patterns to according to the similarity between starting entities. After
boost the performance of JRipples. that, the change-patterns that have been extracted from the
TABLE 23
Accuracy Improvements for JRipples When Applying Simpler Boosting and Our Boosting Methods
Recall Precision
5 10 20 30 40 5 10 20 30 40
Avg Improv (simpler boosting) 0.95 0.55 0.43 0.01 0.02 0.62 0.21 0.10 –0.02 –0.01
Rlt Improv (simpler boosting) 4.18 1.79 1.27 –0.30 0.05 3.49 1.04 1.15 –0.97 –0.17
Avg Improv (our boosting) 1.41 0.88 0.52 0.08 0.05 1.13 0.43 0.15 0.00 0.00
Rlt Improv (our boosting) 6.48 3.20 1.64 0.23 0.14 6.52 3.70 2.13 0.00 0.00
change sets can be used to boosting the rankings of the truly code and the software documentation [40]. However, map-
impacted entities in the initial impacted set. In the whole ping the concepts (or features) defined in a change request
process, our boosting method only needs to analyze the cou- specification to the source code components is not an easy
pling dependencies between the starting entities and the thing. Existing studies rely on different types of analysis
ones in the initial impacted set, which is a completely auto- (such as: textual, historical, static and dynamic) for the iden-
matic process. On the other hand, the change-patterns from tification of concepts in the source code [41], [42].
other projects have been pre-extracted and stored by our Textual analysis tries to reveal the mappings between the
method. Therefore, any users can use the boosting method concepts and the domain knowledge already encoded in
and the collected change-patterns for their CIA tasks. the form of comments and identifier-names in the source
The four threat to external validity relates to language- code. To achieve this goal, many analysis techniques such
dependency and project-size dependency. The boosting as Natural Language Processing (NLP), Information
method mainly aims at Java language, while it can be gener- Retrieval (IR) are the employed in textual analysis [43], [44],
alized to other object-oriented programming languages. In [45]. With historical analysis, researchers found the software
the paper, we used four types of coupling dependencies entities related to a concept by mining the evolutionary his-
which are observed from the object-oriented programming tory from the version control system such as SVN and Git
paradigm. Although the same instance implemented by dif- [46]. The philosophy behind the historical analysis is that if
ferent object-oriented languages (e.g., C++ and Java) may a software entity is known to be in a concept, entities that
have difference, it can be covered by our defined coupling tend to change in the same commits as that entity might
dependencies, because these four coupling dependencies also be likely candidate locations for that concept [47], [48],
are defined at a high level, including Class-to-Class, [49], [50].
Method-to-Class, Method-to-Variable and Method-to- Static analysis allows developers to identify the relevant
Method. These four coupling dependencies can cover most software entities by the data or control flow dependencies
coupling relationships in the object-oriented programming between them [46]. For example, if one software entity is
paradigm. In addition, the proposed boosting method has known to be part of the concept and it is the only caller of
no dependency with the project size, which can be used another entity, then it is considered likely that this latter
both for small- and large-scale projects. entity is also part of the concept [51], [52]. Dynamic analysis
Threats to Internal Validity. One of the threats to internal refers to the invocation and observation of concept at execu-
validity relates to a commit containing more than one start- tion time: execution traces are analyzed to identify code that
ing entities. By applying ISC method, we employ random is always executed when the concept is exercised in the sys-
forest to predict the probability of a class being a starting tem, and code that is not executed when the concept is not,
one. By default, the class with the highest probability in a thus identifying code that is (exclusively) associated with
commit is the starting one. In the meantime, if the probabili- the concept [53], [54].
ties of more than one classes are greater than 0.5 in a com-
mit, ISC regards all these classes as salient ones [12], [16].
Then, our method will extract the change-patterns between 9.2 Identifying the Candidate Impact Set
each salient class and the rest of the classes in the commit, In the second step of the impact analysis process concerns
and apply the change-patterns to the rank boosting step. the identification of the candidate impact set based on the
We found in previous study [39] that if a commit contains 2 starting impact set identified in the first step. In general,
starting entities, it contains unrelated changes. Then, one dynamic analysis [3], [4], [55], [56], [57] and static analysis
starting entity builds change-patterns between parts of the [5], [10], [58], [59], [60] can be used to identify the candidate
classes in the commit, while another starting entity builds impact set. Dynamic impact analysis obtains the interaction
change-patterns between the other parts of the classes in the and dependency between software entities via the informa-
commit. As a result, the change-patterns in this commit can tion collected from the running time of a program, and then
be equivalent to the change-patterns coming from two com- estimates the impact set for a changed entity. Static analysis
mits. Because we only care the change-patterns rather than gets the dependencies between software entities by analyz-
where they come from, if a change-pattern comes from a ing the static information of the source code. The accuracy
commit containing two starting entities, it can be also used of dynamic change impact analysis is relatively higher.
by our boosting method. Thus, we believe there is little However, dynamic change impact analysis needs to collect
threat to a commit containing more than one starting the dynamic information of the running time of a program,
entities. then its running cost is high, while the running cost of static
change impact analysis is low.
9 RELATED WORK According to different technologies used, the identifica-
tion of the candidate impact set can be divided into two
According to the impact analysis process, the CIA can be types: one based on logical dependency analysis [6], [7], [8],
divided into two steps [40], i.e., identifying the starting [19], [61], [62] and the other based on software repository
impact set and identifying the candidate impact set. mining (MSR) [9], [10], [11]. The dependency analysis based
impact analysis estimates the impact set through the depen-
9.1 Identifying the Starting Impact Set dency relationships (such as invocation relationships, con-
The first step of the impact analysis process concerns the trol relationships.) of software entities in a single version.
identification of the starting impact set that requires the anal- The software repository mining based impact analysis gets
ysis of the change request specification and both the source the dependency relationships between software entities by
mining the update information of software entities in the [2] H. Kagdi, M. Gethers, and D. Poshyvanyk, “Integrating
conceptual and logical couplings for change impact analysis
software evolution. in software,” Empir. Softw. Eng., vol. 18, pp. 933–969, Oct.
Ying et al. [23] state that mining software repositories can 2013.
uncover important historical dependencies between soft- [3] T. Apiwattanapong, A. Orso, and M. J. Harrold, “Efficient and
ware entities, which may not be captured by the methods precise dynamic impact analysis using execute-after sequences,”
in Proc. 27th Int. Conf. Softw. Eng., 2005, pp. 432–441.
that based on logical dependency analysis. However, most [4] J. Law and G. Rothermel, “Whole program path-based
of the impact analysis methods mine the software reposi- dynamic impact analysis,” in Proc. 25th Int. Conf. Softw. Eng.,
tory in a scenario of within-project, which limits the capabil- 2003, pp. 308–318.
[5] S. Park and D. H. Bae, “An approach to analyzing the software
ities of current MSR based methods. To break this process change impact using process slicing and simulation,”
limitation, we generalize the MSR based method to a cross- J. Syst. Softw., vol. 84, no. 4, pp. 528–543, 2011.
project scenario, i.e., the change-patterns we referenced [6] L. C. Briand, Y. Labiche, and G. Soccar, “Automating impact anal-
come not only from the current project, but also from other ysis and regression test selection based on UML designs,” in Proc.
Int. Conf. Softw. Maintenance, 2002, pp. 252–261.
projects. [7] J. Dıaz, J. Perez, J. Garbajosa, and A. L. Wolf, “Change impact
In addition, some researchers propose other type of tech- analysis in product-line architectures,” in Proc. 5th Eur. Conf.
niques to identify the candidate impact set. For example, Softw. Archit., 2011, pp. 114–129.
Ceccarelli et al. [63] employ a vector regression model to [8] T. Rolfsnes, S. D. Alesio, R. Behjati, L. Moonen, and D. W. Binkley,
“Generalizing the analysis of evolutionary coupling for software
model the relationship between code changes, and further change impact analysis,” in Proc. IEEE 23rd Int. Conf. Softw. Anal.
predict the co-changed entities. Canfora et al. [64] use the Evol. Reeng., 2016, vol. 1, pp. 201–212.
text similarity to retrieve similar change requests from the [9] T. Zimmermann, A. Zeller, P. Weissgerber, and S. Diehl, “Mining
version histories to guide software changes,” IEEE Trans. Softw.
code repository to obtain the impact set of code change. Eng., vol. 31, no. 6, pp. 429–445, Jun. 2005.
Gethers et al. [65] use the relational topic model to model [10] G. Canfora and L. Cerulo, “Fine grained indexing of software
the dependencies among software entities and utilize the repositories to support impact analysis,” in Proc. Int. Workshop
topic dependencies among the entities to conduct the Mining Softw. Repositories, 2006, pp. 105–111.
[11] M. Torchiano and F. Ricca, “Impact analysis by means of
change impact analysis. unstructured knowledge in the context of bug repositories,”
in Proc. ACM/IEEE Int. Symp. Empir. Softw. Eng. Meas., 2010,
pp. 47:1–47:4.
[12] Y. Huang, N. Jia, X. Chen, K. Hong, and Z. Zheng, “Salient-class
10 CONCLUSION AND FUTURE WORK location: Help developers understand code change in code
review,” in Proc. 26th ACM Joint Meeting Eur. Softw. Eng. Conf.
Change impact analysis plays an important role in code Symp. Found. Softw. Eng., 2018, pp. 770–774.
change comprehension and software maintenance. This [13] Y. Huang, X. Chen, Z. Liu, X. Luo, and Z. Zheng, “Using discrimi-
paper proposes a novel method to boost the performance native feature in software entities for relevance identification of
code changes,” J. Softw., Evol. Process, vol. 35, pp. 1258–1277, 2020.
of traditional CIA tasks. To improve the rankings of actual [14] B. Dit, A. Holtzhauer, D. Poshyvanyk, and H. H. Kagdi, “A data-
impacted classes, we retrieve equivalent classes from the set from change history to support evaluation of software mainte-
historical change sets for a starting class, and map the nance tasks,” in Proc. 10th Work. Conf. Mining Softw. Repositories,
change-patterns of the equivalent classes to the starting 2013, pp. 131–134.
[15] J. Zhang et al., “Search-based inference of polynomial metamor-
class. Then, the rankings of the classes with similar phic relations, ” in Proc. 29th ACM/IEEE Int. Conf. Autom. Softw.
change-patterns in current CIA tasks will be improved in Eng., 2014, pp. 701–712.
the list. Experimental results demonstrated the feasibility [16] Y. Huang, N. Jia, X. Chen, K. Hong, and Z. Zheng, “Code review
knowledge perception: Fusing multi-features for salient-class
and effectiveness of our approach. In the future, we will location,” IEEE Trans. Softw. Eng., early access, Sep. 2020,
further consider to apply our boosting approach to more doi: 10.1109/TSE.2020.3021902.
CIA tools. [17] B. Dit et al., “ImpactMiner: A tool for change impact analysis,”
in Companion Proc. 36th Int. Conf. Softw. Eng., 2014, pp. 540–543.
[18] J. Buckner, J. Buchta, M. Petrenko, and V. Rajlich, “JRipples: A tool
ACKNOWLEDGMENTS for program comprehension during incremental change,” in Proc.
13th Int. Workshop Program Comprehension, 2005, pp. 149–152.
This work was supported by the Key Area Research and [19] H. Kagdi, M. Gethers, D. Poshyvanyk, and M. L. Collard,
Development Program of Guang dong Province under Grant “Blending conceptual and evolutionary couplings to support
2020B010164002, the National Natural Science Foundation of change impact analysis in source code,” in Proc. 17th Work. Conf.
China under Grants 61902441 and 61722214, Guangdong Reverse Eng., 2010, pp. 119–128.
[20] M. Gethers, B. Dit, H. Kagdi, and D. Poshyvanyk, “Integrated
Basic and Applied Basic Research Foundation under Grant impact analysis for managing software changes,” in Proc. 34th Int.
2020A1515010973, China Postdoctoral Sc ience Foundation Conf. Softw. Eng., 2012, pp. 430–440.
(2018M640855), Hong Kong RGC Project No. 152239/18E, [21] X. Ye, H. Shen, X. Ma, R. Bunescu, and C. Liu, “From word
embeddings to document similarities for improved information
the Fundamental Research Funds for the Central Universities retrieval in software engineering,” in Proc. 38th Int. Conf. Softw.
under Grant 20wkpy06, 20lgpy129, the National Natural Eng., 2016, pp. 404–415.
Science Foundation of China under Grant 61725201, and the [22] Y. Huang, Q. Zheng, X. Chen, Y. Xiong, Z. Liu, and X. Luo,
Beijing Outstanding Young Scientist Program under Grant “Mining version control system for automatically generating com-
mit comment,” in Proc. ACM/IEEE Int. Symp. Empir. Softw. Eng.
BJJWZYJH01201910001004. Meas., 2017, pp. 414–423.
[23] A. T. Ying, G. C. Murphy, R. Ng, and M. C. Chu-Carroll,
REFERENCES “Predicting source code changes by mining change history,” IEEE
Trans. Softw. Eng., vol. 30, no. 9, pp. 574–586, Sep. 2004.
[1] M. Petrenko and V. Rajlich, “Variable granularity for improving [24] E. Nasseri, S. Counsell, and M. Shepperd, “An empirical study of
precision of impact analysis,” in Proc. IEEE 17th Int. Conf. Program evolution of inheritance in Java oss,” in Proc. 19th Australian Conf.
Comprehension, 2009, pp. 10–19. Softw. Eng., 2008, pp. 269–278.
[25] Y. Huang, X. Hu, N. Jia, X. Chen, Y. Xiong, and Z. Zheng, [53] D. Poshyvanyk, Y. Gueheneuc, A. Marcus, G. Antoniol, and
“Learning code context information to predict comment V. Rajlich, “Feature location using probabilistic ranking of
locations,” IEEE Trans. Rel., vol. 69, no. 1, pp. 88–105, Mar. methods based on execution scenarios and information
2020. retrieval,” IEEE Trans. Softw. Eng., vol. 33, no. 6, pp. 420–432,
[26] P. Jaccard, “The distribution of the flora in the alpine zone,” New Jun. 2007.
Phytologist, vol. 11, no. 2, pp. 37–50, 2010. [54] D. Liu, A. Marcus, D. Poshyvanyk, and V. Rajlich, “Feature loca-
[27] M. Barnett, C. Bird, J. A. Brunet, and S. K. Lahiri, “Helping tion via information retrieval based filtering of a single scenario
developers help themselves: Automatic decomposition of code execution trace,” in Proc. 22nd IEEE/ACM Int. Conf. Autom. Softw.
review changesets,” in Proc. 37th Int. Conf. Softw. Eng., 2015, Eng., 2007, pp. 234–243.
pp. 134–144. [55] L. Huang and Y.-T. Song, “Precise dynamic impact analysis
[28] Freecol. 2002. [Online]. Available: http://www.freecol.org with dependency analysis for object-oriented programs,” in
[29] Hsqldb. 2001. [Online]. Available: http://hsqldb.org/ Proc. 5th ACIS Int. Conf. Softw. Eng. Res. Manage. Appl., 2007,
[30] Jamwiki. 2006. [Online]. Available: http://www.jamwiki.org/ pp. 374–384.
[31] jedit. 1999. [Online]. Available: http://www.jedit.org [56] H. Cai and R. Santelices, “Diver: Precise dynamic impact analysis
[32] Jhotdraw. 2000. [Online]. Available: http://www.jhotdraw.org using dependence-based trace pruning,” in Proc. 29th ACM/IEEE
[33] Makagiga. 2005. [Online]. Available: https://makagiga.sourceforge. Int. Conf. Autom. Softw. Eng., 2014, pp. 343–348.
io/ [57] H. Cai and D. Thain, “DistiA: A cost-effective dynamic impact
[34] Omegat. 2002. [Online]. Available: https://omegat.org/ analysis for distributed programs,” in Proc. 31st IEEE/ACM Int.
[35] M. Fowler, “Inversion of control containers and the dependency Conf. Autom. Softw. Eng., 2016, pp. 344–355.
injection pattern,” 2004. [Online]. Available: http://www. [58] M. Acharya and B. Robinson, “Practical change impact analysis
martinfowler.com/articles/injection.html based on static program slicing for industrial software systems,”
[36] N. Tsantalis, T. Chaikalis, and A. Chatzigeorgiou, “JDeodorant: in Proc. ACM SIGSOFT 20th Int. Symp. Found. Softw. Eng., 2012,
Identification and removal of type-checking bad smells,” in Proc. pp. 13:1–13:2.
12th Eur. Conf. Softw. Maintenance Reeng., 2008, pp. 329–331. [59] H. Kagdi, M. Gethers, and D. Poshyvanyk, “Integrating
[37] Pmd. 2017. [Online]. Available: https://pmd.github.io/ conceptual and logical couplings for change impact analysis
[38] A. Yamashita and S. Counsell, “Code smells as system-level indi- in software,” Empir. Softw. Eng., vol. 18, pp. 933–969, Oct.
cators of maintainability: An empirical study,” J. Syst. Softw., 2013.
vol. 86, no. 10, pp. 2639–2653, 2013. [60] H. Abdeen, K. Bali, H. Sahraoui, and B. Dufour, “Learning depen-
[39] Y. Huang, X. Chen, Z. Liu, X. Luo, and Z. Zheng, “Using discrimi- dency-based change impact predictors using independent change
native feature in software entities for relevance identification of histories,” Inf. Softw. Technol., vol. 67, pp. 220–235, 2015.
code changes,” J. Softw.: Evol. Process, vol. 29, no. 7, 2017, Art. no. [61] D. Poshyvanyk, A. Marcus, R. Ferenc, and T. Gyim othy, “Using
e1859. information retrieval based coupling measures for impact analy-
[40] A. De Lucia, F. Fasano, and R. Oliveto, “Traceability management sis,” Empir. Softw. Eng., vol. 14, pp. 5–32, Feb. 2009.
for impact analysis,” in Proc. Front. Softw. Maintenance, 2008, [62] L. C. Briand, J. Wuest, and H. Lounis, “Using coupling measure-
pp. 21–30. ment for impact analysis in object-oriented systems,” in Proc.
[41] N. Wilde, M. Buckellew, H. Page, V. Rajlich, and L. Pounds, IEEE Int. Conf. Softw. Maintenance, 1999, pp. 475–482.
“A comparison of methods for locating features in legacy [63] M. Ceccarelli, L. Cerulo, G. Canfora, and M. Di Penta, “An eclectic
software,” J. Syst. Softw., vol. 65, pp. 105–114, 2003. approach for change impact analysis,” in Proc. 32nd ACM/IEEE
[42] B. Dit, M. Revelle, M. Gethers, and D. Poshyvanyk, “Feature loca- Int. Conf. Softw. Eng., 2010, pp. 163–166.
tion in source code: A taxonomy and survey,” J. Softw.: Evol. Pro- [64] G. Canfora and L. Cerulo, “Impact analysis by mining software
cess, vol. 25, pp. 53–95, 2013. and change request repositories,” in Proc. 11th IEEE Int. Softw.
[43] D. Binkley, D. Lawrie, C. Uehlinger, and D. Heinz, “Enabling Metrics Symp., 2005, pp. 9 pp.-29.
improved IR-based feature location,” J. Syst. Softw., vol. 101, [65] M. Gethers and D. Poshyvanyk, “Using relational topic models
pp. 30–42, 2015. to capture coupling among classes in object-oriented software
[44] D. Liu, A. Marcus, D. Poshyvanyk, and V. Rajlich, “Feature loca- systems,” in Proc. IEEE Int. Conf. Softw. Maintenance, 2010,
tion via information retrieval based filtering of a single scenario pp. 1–10.
execution trace,” in Proc. 22nd IEEE/ACM Int. Conf. Autom. Softw.
Eng., 2007, pp. 234–243.
[45] S. Wang, D. Lo, Z. Xing, and L. Jiang, “Concern localization using
information retrieval: An empirical study on linux kernel,”
in Proc. 18th Work. Conf. Reverse Eng., 2011, pp. 92–96. Yuan Huang received the PhD degree in com-
[46] A. Razzaq, A. L. Gear, C. Exton, and J. Buckley, “An empirical puter science from Sun Yat-sen University,
assessment of baseline feature location techniques,” Empir. Softw. China, in 2017. He is currently a research fellow
Eng., vol. 25, no. 5, pp. 266–321, 2020. with the School of Software Engineering, Sun
[47] M. Chochlov, M. English, and J. Buckley, “A historical, textual Yat-sen University, China. He is particularly inter-
analysis approach to feature location,” Inf. Softw. Technol., vol. 88, ested in software evolution and maintenance,
pp. 110–126, 2017. code analysis and comprehension, and mining
[48] S. Wang and D. Lo, “Version history, similar report, and structure: software repositories.
Putting them together for improved bug localization,” in Proc.
22nd Int. Conf. Program Comprehension, 2014, pp. 53–63.
[49] X. Ye, R. Bunescu, and C. Liu, “Mapping bug reports to relevant
files: A ranking model, a fine-grained benchmark, and feature
evaluation,” IEEE Trans. Softw. Eng., vol. 42, no. 4, pp. 379–402,
Apr. 2016. Jinyu Jiang is currently working toward the
[50] T. Zhang, H. Jiang, X. Luo, and A. Chan, “A literature review undergraduate degree with the Sun Yat-sen
of research in bug resolution: Tasks, challenges and future University, China. His research interest
directions,” Comput. J., vol. 59, no. 5, pp. 741–773, 2016. includes software engineering, code analysis
[51] B. Bassett and N. A. Kraft, “Structural information based term and comprehension, and mining software
weighting in text retrieval for feature location,” in Proc. 21st Int. repositories.
Conf. Program Comprehension, 2013, pp. 133–141.
[52] G. Scanniello, A. Marcus, and D. Pascale, “Link analysis algo-
rithms for static concept location: An empirical assessment,”
Empir. Softw. Eng., vol. 20, pp. 1666–1720, Dec. 2015.
Xiapu Luo received the PhD degree in computer Nan Jia received the PhD degree in computer
science from The Hong Kong Polytechnic Univer- science from Sun Yat-sen University, China, in
sity, China, and was a postdoctoral research fel- 2017. She is currently an associate professor
low with the Georgia Institute of Technology, with the School of Information Engineering, Hebei
Atlanta, Georgia. He is currently an associate GEO University, China. She is particularly inter-
professor with the Department of Computing, ested in data mining and software engineering.
The Hong Kong Polytechnic University, China.
His current research focuses on mobile/IoT secu-
rity and privacy, blockchain/smart contracts, soft-
ware engineering, network security and privacy,
and Internet measurement. His work appeared in
top security, software engineering and networking conferences and jour-
nals, and he received several best paper awards (e.g., INFOCOM’18, Gang Huang (Senior Member, IEEE) is currently
ISPEC’17, ATIS’17, ISSRE’16, etc.). a full professor with the Institute of Software,
Peking University, China. His research interests
include in the area of middleware of cloud com-
Xiangping Chen (Member, IEEE) received the puting and mobile computing.
PhD degree from Peking University, China, in
2010. She is currently an associate professor
with the Sun Yat-sen University, China. Her
research interest includes software engineering
and mining software repositories.
" For more information on this or any other computing topic,

please visit our Digital Library at www.computer.org/csdl.
Zibin Zheng (Senior Member, IEEE) received

the PhD degree from the Chinese University of
Hong Kong, China, in 2011. He is currently a pro-
fessor with Sun Yat-sen University, China. He
published more than 120 international journal
and conference papers, including three ESI high-
lycited papers. His research interests include
blockchain, services computing, software engi-
neering, and financial big data. He was a recipient
of several awards, including the Top 50 Influential
Papers in Blockchain of 2018, the ACM SIG-
SOFT Distinguished Paper Award at ICSE2010, the Best Student Paper
Award at ICWS2010.

Compiler

Uploaded by

Copyright:

Available Formats

Compiler

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Compiler

Uploaded by

Copyright:

Available Formats

2376 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 48, NO.

Change-Patterns Mapping: A Boosting Way

Index Terms—Change impact analysis, change-patterns, coupling dependency, boosting method

1 INTRODUCTION Decades of research efforts have produced a wide spec-

Fig. 1. Different change sets involved in similar change-patterns.

Fig. 2. Overview of main steps.

The notation P ðcinit ; ci Þ indicates the likelihood of ci to be

Fig. 3. An example of identifying the starting entity by ISC.

TABLE 1 However, in most cases finer-grained coupling depen-

Name Coupling Dependencies Formalization Instances

After getting the coupling dependencies between the

TABLE 3 histories of the projects. We also use the default setting of

In many cases, we will evaluate the performance of an

Fig. 4. Change impact analysis tools.

Fig. 5. t choice effects on the performance of ImpactMiner, JRipples, and ROSE.

7.1 Ranking Boosting Examples

Precision ImpactMiner JRipples ROSE

Fig. 9. Boosting strategy versus random strategy.

No. Projects # IoC Commits

TABLE 22 We evaluate the performance of the JRipples when

" For more information on this or any other computing topic,

Zibin Zheng (Senior Member, IEEE) received

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.