社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

ソースコードの修正作業状況に基づく
メソッド移動リファクタリング推薦に向けて
氏原 直哉†

アリ ウニ†

石尾隆†

井上 克郎†† 大阪大学情報科学研究科 〒 565–0871 大阪府吹田市山田丘 1–5
E-mail: †{naoya-u,ali,ishio,inoue}@ist.osaka-u.ac.jp
あらまし メソッド移動リファクタリングはソフトウェアの品質を向上させるために役立つ技術である．本研究では，

Java プログラムの修正作業によって発生したクラス間の依存関係の変化を可視化し，不必要な依存関係を取り除く可能性の高いメソッド移動リファクタリングを推薦，実行するツールを開発した．
キーワード メソッド移動リファクタリング，

floss リファクタリング， ソフトウェア品質， ソフトウェア保守

Towards Move Method Refactoring Recommendation
using Change Task Context
Naoya UJIHARA† , Ali OUNI† , Takashi ISHIO† , and Katsuro INOUE†† Graduate School of Information Science and Technology, Osaka University
Yamadaoka 1–5, Suita-shi, 565–0871 Japan
E-mail: †{naoya-u,ali,ishio,inoue}@ist.osaka-u.ac.jp
Abstract Move Method Refactoring is an eﬀective technique to improve software quality. In this research, we havedeveloped a refactoring tool that visualizes changes of dependence relation among classes caused by a maintenancetask and makes a recommendation of move method refactroings to remove unnecessary dependence relations.
Key words move method refactoring, floss refactoring, software quality, software maintenance1. ま え が き

推奨している [5]．
リファクタリングのためのソースコード修正の操作は，Fowler

リファクタリングとは，ソフトウェアの外部的振る舞いをら [5] によって 72 種類に分類，定義されているが，その中でも保ったままで，内部の構造を改善していく作業を指す [5]．大規

欠かすことのできないリファクタリングとして挙げられている

模システムのソースコードは，既存機能の拡張や，新機能の追のがメソッド移動リファクタリング，すなわち，あるメソッド

加，欠陥修正などのために，継続的に変更され続け，時間の経を実装しているクラスから他のクラスへと移動させる操作であ過とともに，設計上の品質は低下していく．そのため，適切なる．Java プログラムにおけるメソッド移動リファクタリング

リファクタリングを実施することで，ソースコードの可読性，は，あるクラス内に定義されているメソッドが，所属クラスのソフトウェアの拡張性や保守性等，ソフトウェア品質を改善し，属性よりも他のクラスの属性を利用し，また，所属クラスの他

ソフトウェア保守作業のコストを低下させることが重要である．

のメソッドよりも他のクラスのメソッドから利用されることがMurphy-Hill らは，リファクタリングを，実施される際の戦多い場合に実施すると，クラス間の結合度を減少させることが略によって floss リファクタリングと root-canal リファクタリ

でき，Feature Envy や Shotgun Surgery といった設計上の欠

ングの 2 つに分類している [6]．Floss リファクタリングは，欠陥であるコードスメルを取り除くことにもつながる．

陥修正や機能追加など他の変更作業の途中に，高品質なコー

ソフトウェア開発において，特に大規模ソフトウェアの開発

ドを維持するために行われるリファクタリングのことである．

では，移動すべきメソッドを開発者が自力で特定することは難Root-canal リファクタリングは，リファクタリング活動に専念

しい．そのため，メソッド移動リファクタリング候補を自動的する時間を確保して，設計上の欠陥を取り除くために行われるに特定するための手法が多数提案されている．しかし，それらリファクタリングのことである．Fowler らは，リファクタリン

の多くは，ソフトウェア全体から設計上の欠陥を特定し，そのグのための時間を設けるのではなく，floss リファクタリングを

欠陥を修正するようなるメソッド移動リファクタリングを推薦—1—する手法である．そのような手法は，root-canal リファクタリというツールを提案している [13]．

ングを行う開発者にとっては非常に役に立つが，一方で，floss

これらの手法は，ソフトウェアの品質を向上させる有用なリリファクタリングを行う開発者にとっては，推薦候補の多くがファクタリング候補を推薦するが，これらの手法では，開発者

修正作業に関連しないため，あまり有用ではない．

がソフトウェアに設計上の欠陥がありそうであると感じたとき

そこで本研究では，開発者の修正作業状況に基づいて flossにツールを実行してもらう必要がある．また，推薦の対象がソリファクタリングを支援するメソッド移動リファクタリング推

フトウェア全体となるため，推薦されるメソッド移動リファク

薦ツール c-JRefRec を提案する．具体的な方法としては，開発

タリングの候補にはソフトウェア全体の様々なコードに関連し作業中のある時点のソースコード（通常はバージョン管理シスたものが含まれることになる．個別のリファクタリングを実施

テムからチェックアウトした直後）の状態でクラス間の依存関するかどうかの判断には，そのコードに関連する設計の理解が係を計測しておき，開発者が行った修正によって生じた依存関

求められるうえ，コードの設計に関する知識や理解がない開発係の増減を表示することで，クラスごとの他クラスとの依存関者や経験の浅い開発者がその判断を行うと新たな欠陥を作りこ係の強さと，修正作業による依存関係への影響を可視化し，リむ可能性もあることから，実際にツールによって推薦されたメ

ファクタリング活動の必要性の判断材料を提供する．また，開ソッド移動リファクタリング候補をソフトウェアに対して実施

発者が熟知していると思われる，修正作業に関連したコードだ

するかどうかの判断を行うことは，開発者にとって非常に大きけをメソッド移動リファクタリング候補の探索対象とすることな負担となる．

で，開発者が推薦されたリファクタリングを実際に実施するか

2. 2 リファクタリング活動の調査

どうかの判断を容易に行える，実施によって欠陥を作りこむ可リファクタリングは設計上の欠陥を取り除く活動として知ら

能性の低い候補を提示する．
以降，2. 章では研究の背景について，3. 章では開発したツールの設計および機能について述べる．4. 章ではツールの利用シ
ナリオを紹介し，5. 章でまとめと今後の課題について述べる．

2. 背

景

れている．たとえば Suryanarayana ら [14] は，技術的負債によって生じるコードスメルとその解決方法としてのリファクタ
リングを整理している．
しかし，リファクタリングはコードスメルのようなソフト
ウェアの設計上の欠陥を取り除く目的以外にも実施されている
ことが報告されている．Bavota らは，リファクタリングとソ

リファクタリングに関する研究としては，リファクタリング

フトウェア品質に関する調査を行った結果，実際に行われたリ作業を支援する手法の研究と，開発者が実施したリファクタリ

ファクタリングのほとんどは，コードスメルを取り除いていな

ングの検出および分析に関する研究が行われている．

いと報告した [1]．また，Cedrim らの調査でも同様に，多くの

2. 1 メソッド移動リファクタリング候補推薦

場合，リファクタリングの実施によってコードスメルは取り除

メソッド移動リファクタリングを支援する手法として，リ

かれておらず，むしろコードスメルを生み出しているような場

ファクタリング候補を推薦する様々な手法が提案されている．

合もあったと報告されている [3]．メソッド移動リファクタリン

これらの手法は，不適切なクラスに配置されたメソッドを検出

グを対象に行われた Silva らの調査 [11] によると，実際のソフ

し，それらのメソッドを配置することでソフトウェアの品質を

トウェア開発現場において実施されているメソッド移動リファ

現状よりも改善できるようなクラスを移動先の候補として推薦

クタリングは，メソッドをより適切なクラスに移動させるため，する．

メソッドを再利用するため，クラス間の参照回数を減少させる

Tsantalis らは，凝集度と結合度に基づいて，Feature Envy

ためであったと報告している．

という設計上の欠陥を検出し，それを修正するようなメソッド

開発者は，自分が書いたコードや修正を行っているコードに

移動リファクタリング候補を推薦するツール JDeodorant を対して，修正作業と並行したリファクタリングを実施している．

提案している [4], [15]．JDeodorant は，推薦するメソッド移動

Murphy らによるリファクタリング活動に関する調査では，リリファクタリングの候補がソフトウェアの振る舞いを保つかど

ファクタリング活動を floss と root-canal に分類し，floss リうか，実施の前提条件の検証を行うことで，問題が起きないリ

ファクタリングの方が root-canal リファクタリングよりも主にファクタリング候補だけを提示する．しかし，リファクタリン

用いられている戦略であると結論付けている [7]．また，Hoque

グ候補推薦の際に，意味的な凝集度に関しては考慮していない．

らの調査でも，修正作業と同時に行われている floss リファク

Bavota ら [2] は，メソッド間の構造的関係に加えて，メソッ

タリングの方が，他の作業とは区別して行われる root-canal リドの内容についての関係トピックモデルを導入した．同じ機能

ファクタリングよりも，頻繁に行われていると述べている [8]．

に関係したメソッドの集合を特定することで Feature Envy とOrrúらのリファクタリングとソースコードの所有権に関する調いう設計上の欠陥を検出し，それを修正するようなメソッド移査では，開発者は何度もコミットしているファイルに対して，

動リファクタリング候補を推薦するツール MethodBook としリファクタリングを実施していることや，ソースコードは，修て実現している．

正を行った回数が多い開発者によって，リファクタリングが行

Sales らは，メソッドの静的依存集合の類似度によって，不われていることが報告されている [9]．

適切なクラスに実装されたメソッドを特定し，それを修正する

開発者がソフトウェアの修正作業の一部としてリファクタリ

ようなメソッド移動リファクタリング候補を推薦する JMove

ングを実施する場合，2. 1 節に記述した既存研究のツールを適—2—

用しても，出力結果のほとんどは修正作業や開発者自身とは無メソッド内に使われている単語を抽出することで，クラスやメ関係なコードに対するリファクタリングの推薦となってしまう．

ソッド間の意味的類似度を求める semantic 解析も行う．

また，ある修正作業によって，新たに作られたメソッドや修正

c-JRefRec は，Class State View と Refactoring Candidates

されたメソッドが，正しいクラスに実装されているか，依存関

View という，2 つのビューを持つ．Class State View は，最係に悪影響を及ぼしていないかを確認するためには，その修正新のグラフと初期のグラフを比較することで，修正作業により作業ごとにツールを実行し，自分の作業に関係したクラスに関クラスの依存関係がどれだけ変化しているかを表示し，1 つ目

する推薦結果だけを閲覧する必要がある．

の修正作業に関するクラスの状態表示機能のために表示する．

本研究では，既存のメソッド移動リファクタリング候補推薦

Refactoring Candidates View は，有向依存グラフによる依存

ツールと，実際のリファクタリング戦略との不一致を解消する

関係の解析と semantic 解析に基づいて，メソッド移動リファ

ために，修正作業状況に基づいたメソッド移動リファクタリン

クタリング候補推薦機能のために表示する．それぞれのビュー

グ候補の推薦手法を提案する．Rajlich [10] によると，修正作業について，以下で説明する．

の一部として実施されるリファクタリング活動は，ソフトウェ

3. 2 クラス状態ビュー

ア変更を容易にするようなソースコードの変更であるプレファ

このビューは，クラスの結合度や凝集度を示すための以下のクタリングと，変更後のソフトウェアのソースコードの可読性などを向上するポストファクタリングに分類される．本研究の4 つのメトリクスを表示する．
•

methods(C) は，クラス C に含まれる，いずれかのクラ提案手法は，メソッドなどの記述が完了した後に実行するポス

スと依存関係があるメソッドの数を示す．この値が大きいほど、

トファクタリングの支援という位置づけとなる．開発者の作業

そのクラスの責務は大きいことを意味する．

状況の考慮という観点は Sae-Lim ら [12] も導入しているが，•edges(C) は，クラス C に含まれるメンバーが持つ，他

この手法は未解決のバグ修正等に備えて修正すべきコードスメのクラスとの辺の数を示す．この値が大きいほど，クラスの凝ルを探すプレファクタリングの支援であり，本研究とは立ち位集度が低いことを意味する．

置が異なる．

3. ツール概要
このツールは，Change task context based Java REFactor-•

clients(C) は，クラス C のメンバを使うクラスの数を示す．この値が大きいほど，クラスの凝集度は低いことを意味する．

•

dependents(C) は，C に含まれるメソッドによって使わing RECommendation を省略して，c-JRefRec と名付けた．

れるメンバを含んでいるクラスの数を示す．この値が大きいほ

c-JRefRec が持つ機能は，修正作業に関するクラスの状態表示

ど，クラスの凝集度は低いことを意味する．

機能と，メソッド移動リファクタリング候補推薦機能である．

修正作業の間に，修正されたメソッドを含んでいるクラス，

1 つ目は，私たちが定義した，クラスレベルの 4 つの構造的メ

そのメソッドのクライアントクラス，ディペンデントクラスのトリクスが修正作業によってどれだけ変化したのかを表示する

ことを修正作業に関連したクラスとし，それらのクラスに関しことで，リファクタリング活動の必要性の判断材料を提供するて，これらのメトリクスを表示する．図 1 で示されているよ機能である．2 つ目は，修正されたコードに関連するメソッド

うに，各列には，クラスの名前，ツールを起動した時点におけ

移動リファクタリング候補を推薦することで，開発者の floss リ

るメトリクスと，修正作業によるメトリクスの初期値からの増ファクタリングを支援する機能である．

減値が表示される．このリストは，4 つのメトリクスの増減値

3. 1 ツール設計の総和が大きい順にソートされている．このビューは，ソース

c-JRefRec は，Eclipse plugin として実装した．Eclipse 上でコードが修正されて，保存される度に，自動的に更新されるた修正を行うソースコードを開いた状態で，このツールを起動すめ，開発者は，自分が行った修正作業による依存関係への影響

ると，クラスやメソッド間の関係を解析するために，Eclipse

を知ることができる．

Java Developer Tool の AST Parser を用いて，有向依存グラ

修正作業に関連したリファクタリング候補を知りたい場合，

フを生成する．このグラフは，メソッド呼び出しとフィールド

ビュー右上のボタンをクリックすることで，リファクタリング

アクセスを辺の情報とし，メソッドとクラスが頂点である．す候補の推薦を要求することができる．また，クラス名をダブル

なわち，ソフトウェア全体に対する，メソッド呼び出しとフィー

クリックすることで，そのクラスに関するリファクタリング候

ルドアクセスの情報を持っている．メソッド呼び出し，もしく補だけの推薦を要求することもできる．

は，フィールドアクセスが存在するメソッドやクラス間の関係

3. 3 リファクタリング候補ビュー

を，依存関係と定義する．また，開発者がソースファイルを修正し，保存したときに，このグラフは自動的に更新される．ここのビューは，メソッド移動リファクタリング候補と，4 つのメトリクスに関する値を表示する．

のツールは，ツール起動時のソフトウェアの状態のグラフと，メトリクスは，以下のように定義した．

最新の状態のグラフの２つを持ち，この 2 つのグラフの差から，•修正作業による依存関係への影響を計算する．
さらに，メソッド移動リファクタリング候補を特定する際に，

c-JRefRec は，ソフトウェアの構造情報だけでなく，クラスや∆edges(R, C) は，メソッド移動リファクタリング R を適用することで，追加・減少するクラス C の辺の数である．

•∆clients(R, C) は，メソッド移動リファクタリング Rを適用することで，追加・減少するクラス C のクライアントク—3—

ラスの数である．

だけ増加し，クライアントクラスの数は，29 から変わっておら∆dependents(R, C) は，メソッド移動リファクタリング

ず，依存クラスの数は，8 から 1 だけ増加していることがわか

R を適用することで，追加・減少するクラス C のディペンデン

る．この修正作業は，Axis クラスと AxisLabelLocation クラス

トクラスの数である．

に対して行われているが，新しく作られた AxisLabelLocation

グラフ全体に含まれる辺の数が減少するか，依存関係にあるククラスに対して，Axis クラスは，様々なクラスと依存関係を持•

ラス数が減少する場合，そのメソッド移動リファクタリング R

つ非常に大きいクラスとなっている．そのため，Axis クラスにを実施すべきであると仮定する．

新しく追加されたメソッドのうち，AxisLabelLocation クラス

また，semantic なメトリクスとして，メソッド m と，クラスと関連したものを，AxisLabelLocation クラスに移動させるこC の意味的類似度を，SS(m, C) = cosine(tf − idf (m), tf −とで，より凝集度の高いソフトウェアへとすることができるとidf (C)) として，tf-idf ベクトルを用いて，計算する．C1 クラ考えられる．このようにして，開発者は，ソースコードの各クスに含まれる m が，C1 クラスよりも C2 クラスとの意味的類

ラスの結合度や凝集度に関する影響を分析することができる．

似度が大きい場合，メソッド m は C2 に移動させるべきである

そこで，開発者が，AxisLabelLocation クラスにリファクと仮定する．

タリング候補があるかを知りたり場合，その行をダブルク

こ れ ら の メ ト リ ク ス を 用 い て ，メ ソ ッ ド 移 動 リ フ ァ ク

リックすることで求めることができる．結果として，図 2 で

タ リ ン グ 候 補 と 判 断 す る た め の 条 件 は ，以 下 の 通 り で示されるような，Refactoring Candidates View が自動的に

あ る ．∆edges(R, Coriginal ) + ∆edges(R, Ctarget ) > 0 OR

表示される．このビューは，移動させるべきメソッド名，移∆clients(R, Coriginal ) + ∆clients(R, Ctarget )動先クラスの名前とメトリクスの値が表示される．このメ+ ∆dependents(R, Coriginal ) + ∆dependents(R, Ctarget ) > 0

トリクスは，∆edges(R, Coriginal )，∆Clients(R, Coriginal )，OR SS(m, Coriginal ) < SS(m, Ctarget )∆Dependents(R, Coriginal ，∆edges(R, Ctarget )，参照本数の減少，依存関係クラスの減少，意味的類似度の向∆Clients(R, Ctarget ), ∆Dependents(R, Ctarget ) の順に表示

上，いずれかの条件を満たす場合にリファクタリング候補とすされている．図 2 の一番上のメソッド移動リファクタリング候ることで，現在欠陥となっているメソッドだけでなく，今後欠補について説明すると，Axis クラスの labelAnchorH() メソッ

陥となりそうなメソッドに対しても，リファクタリング候補とドを，AxisLabelLocation クラスへ移動させるリファクタリン

して，推薦する．

グを推薦している．Axis クラスと labelAnchorH() メソッド

図 2 のように，このビューは，リファクタリング候補として，間で，辺が 4 本増えるけれども，AxisLabelLocation クラスと移動させるメソッドの名前と移動先クラスの名前だけでなく，labelAnchorH() メソッド間で，辺が 6 本減るため，ソフトウェ

このリファクタリングによって，移動元クラスと，移動先クラア全体では，辺が 2 本減ることがわかる．このメソッド移動リスの構造的メトリクスにどのような影響があるかも，表示する．

ファクタリングによって，クライアントクラスの数とディペン

そのため，開発者は，リファクタリングを適用するかの判断がデントクラスの数は，変わらない．しかし，labelAnchorH()

容易に行える．

メソッドは，Axis クラスと意味的類似度が 16.6% しかないが，4. ユーザシナリオ

AxisLabelLocation クラスとは，61.8% もあることがわかる．
すなわち，クラス間の参照本数は減少し，labelAnchorH() メ

c-JRefRec の 使 い 方 を 紹 介 す る た め に ，リ フ ァ ク タ リ ン

ソッドの実装されているクラスとの意味的類似度は向上するこ

グ対象のソフトウェアとして，有名なオープンソースソフとがわかる．このようにして，各リファクタリングを実施する

ト ウ ェ ア で あ る JFreeChart を 選 ん だ ．github に 記 録 さ れことによって，どのようなメリットがあるか，依存関係の観点ている，コミット ID c7e8c72 内の修正作業に対して，このと，semantic な観点から，開発者は確認することができる．まツールが，どのように機能するかを示す．このコミット内でた，これらのメトリクスの値は，??で定義した条件を満たすのは，org.jfree.chart.axis.AxisLabelLocation クラスが作られ，で，c-JRefRec は，labelAnchoer() メソッドを Axis クラスか

org.jfree.chart.axis.Axis クラス内で，フィールドとメソッドのら AxisLabelLocation クラスへ移動させるリファクタリング

追加と修正が行われている．

を候補として，推薦している．

c-JRefRec を起動させると，まず，Class State View が表示

図 3 は，図 1 の状態から，labelAnchor() メソッドを，Axis ク

される．Class State View は，ソースコードが変更されて，保ラスから AxisLabelLocation クラスへと移動させた後の，Class

存される度に，自動的に更新される．図 1 は，そのコミットにおState View である．Axis クラスは，修正作業によりメソッド

ける修正作業が行われた後の Class State View の状態である．

の数は，+6 に増加していたが，メソッドを 1 つ他のクラスへと

このコミット内で，AxisLabelLocation クラスは，新しく作ら移動させたため，+5 へと減少している．辺の数は，修正作業にれたクラスであるため，メソッドの数は 0 から 5 だけ増加し，より+26 に増加していたが，リファクタリングによって，+24

辺の数は 0 から 23 だけ増加し，クライアントクラスの数は 0へと減少していることがわかる．同様に，AxisLabelLocation

から 2 だけ増加し，依存クラスの数は 0 から 1 だけ増加していクラスは，メソッドの数が+5 から+6 へと増加しているが，辺ることがわかる．同様に，Axis クラスも修正されているため，の数は，+23 から+21 へと 2 だけ減少したことがわかる．

メソッドの数は，67 から 6 だけ増加し，辺の数は，389 から 26

このようにして，開発者は開発作業と並行して，修正作業に—4—

図 2 Refactoring Candidates View

図 1 Class State View (リファクタリング前)

図 3 Class State View (リファクタリング後)関連したコードに対するリファクタリング活動を実施することる予定である．また，人為的にメソッドを不適切な場所に移動ができる．

し，それらを元の場所に戻せるかによっても評価を行うことを

5. まとめと今後の課題
本研究では，開発者の修正作業状況に基づいて floss リファ
クタリングを支援するためのメソッド移動リファクタリング候
補推薦手法を提案し，c-JRefRec として実装した．具体的には，
修正によって生じた依存関係の増減を表示することで，リファ
クタリング活動の必要性の判断材料を提供し，修正作業に関連したコードだけをメソッド移動リファクタリング候補の探索対象とすることで，開発者が推薦されたリファクタリングを実際に実施するかどうかの判断を容易に行える，実施によって欠陥を作りこむ可能性の低い候補を提示する．
今後の課題は，本手法によって推薦されるメソッド移動リ
ファクタリング候補の評価と，それが開発者の作業に与える影響の調査である．リファクタリング候補の評価としては，実際のソフトウェア開発で実施された floss リファクタリングにおけるメソッド移動リファクタリングを，提案ツールを用いてリ
ファクタリング実施前の修正作業から推薦できるかを調査す考えている．開発者の作業に与える影響については，開発者に

c-JRefRec が有効な状態で開発作業を行ったとき，リファクタ
リングがどれだけ実施されるかを調査する予定である．
謝辞

本 研 究 は JSPS 科 研 費 JP25220003, JP26280021,

JP15H02683 の助成を受けたものです．
文

献[1] G. Bavota, A. D. Lucia, M. D. Penta, R. Oliveto, and F.
Palomba. An Experimental Investigation on the Innate Relationship between Quality and Refactoring. Journal of Systems and Software, vol.107, pp.1–14, 2015.
[2] G. Bavota, R. Oliveto, M. Gathers, D. Poshyvanyk, andA. D. Lucia. Methodbook: Recommending Move Method
Refactoring via Relational Topic Models. IEEE Transactions on Software Engineering, vol.40, issue.7, pp.671–694,
2014.
[3] D. Cedrim, L. Sousa, A. Garcia, and R. Gheyi. Does refactoring improve software structural quality? A longitudinal
study of 25 project. In Proc. of SBES, pp.73–82, 2016.
[4] M. Fokaefs, N. Tsantalis, and A. Chatzigeorgiou. Jdeodorant: Identification and removal of feature envy bad smells.”
In Proc. of ICSM, pp.519–520, 2007.
[5] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts.

—5—

[6]

[7]

[8]

[9]

[10]
[11]

[12]

[13]

[14]
[15]

Refactoring: Improving the Design of Existing Code.
Addison-Wesley Longman Publishing Co, Inc, 1999.
E. Murphy-Hill and A. P. Black. Refactoring Tools: Fitness for Purpose. IEEE Software, vol.25, issue.5, pp.38–44,
Sept.-Oct. 2008.
E. Murphy-Hill, C. Parnin, and A. P. Black. How We Refactor, and How We Know It. IEEE Transactions on Software
Engineering, vol.38, issue.1, pp.5–18, 2012.
M. I. Hoque, V. N. Ranga, A. R. Pedditi, R. Srinath, M.
A. A. Rana, M. E. Islam, and A. Somani. An Empirical
Study on Refactoring Activity. ACM Computing Research
Repository abs/1412.6359, 2014.
M. Orrú and M. Marchesi. A case study on the relationshipbetween code ownership and refactoring activities in a Javasoftware system. In Proc. of WETSom, pp.43–49, 2016.
V. Rajlich. Software Engineering: The Current Practice.
CRC Press, 2011.
D. Silva, N. Tsantalis, and M. T. Valente. Why We Refactor? Confessions of GitHub Contributors. In Proc. of FSE,
pp.858–870, 2016.
N. Sae-Lim, S. Hayashi, and M. Saeki. Context-Based CodeSmells Prioritization for Prefactoring. In Proc. of ICPC,
pp.1–10, 2016.
V. Sales, R.Terra, L.F. Miranda, and M. T. Valente. Recommending Move Method Refactorings using Dependency
Sets. In Proc. of WCRE, pp.232–241, 2013.
G. Suryanarayana, G. Samarthyam, and T. Sharma. Refactoring for Software Design Smells. Morgan Kaufmann, 2015.
N. Tsantalis and A. Chatzigeorgiou. Identification of movemethod refactoring opportunities. IEEE Transactions on
Software Engineering, vol.35, issue. 3, pp.347–367, 2009.

—6—