情報処理学会研究報告
IPSJ SIG Technical Report

抽象構文木を利用した API の変更の分類
入山 優1,a)

肥後 芳樹1,b)

楠本 真二1,c)

概要：ライブラリがアップグレードされると，API も変更される．API の変更は様々で，それらを自動で分類することはコードレビューやリリースノートの作成に役立つ．API の変更を自動で検出し，その種類ごとに分類するツールとして APIDiﬀ がある．APIDiﬀ は Java ライブラリの 2 つのバージョンを入力として受け取り，静的解析とコードの類似性に基づいて API の変更を検出して分類する．しかし，コードの類似性の閾値を適切に設定することは難しく，APIDiﬀ はリファクタリングとして分類すべき API の変更
を誤って分類する場合がある．そこで提案手法では，コードの類似性の閾値に依存せず抽象構文木を用いてリファクタリングを検出する RefactoringMiner を利用し，API の変更を分類する．8 個のオープンソー
スソフトウェアに対して実験を行った結果，既存手法と比べて API の変更をより高い精度で分類できることを確認した．また，提案手法により API に対して行われたリファクタリングの検出数が増加したことが明らかになった．

1. はじめにストをもとに，API の変更を検出してその種類ごとに分類する．

多くのソフトウェアにおいて生産性の向上のためライブ

この APIDiﬀ を利用してさまざまな研究が行われていラリが活用されている [1, 2]．ライブラリは，アプリケー

る．例えばライブラリの安定性 [6]，API の互換性が失わ

ション・プログラミング・インターフェース（以下 API）

れる変更がクライアントに与える影響 [6]，開発者が APIを介して機能を提供している．ライブラリがアップグレーの互換性が失われる変更を行なった理由 [7, 8]，API の互

ドされると，API も変更される場合がある．API の変更は換性が失われる変更の危険性に対する開発者の認識 [9] な

新機能の追加や不必要な機能の削除， 保守性の向上を目的

どを明らかにするための研究が行われている．

としたリファクタリングなど様々である．API の変更を自

しかし，APIDiﬀ には課題点がある．RefDiﬀ においてコー動で分類することは，コードレビューやリリースノートのドの類似性の閾値を適切に設定することは難しく，APIDiﬀ

作成に役立つ [3]．

は API メソッドのパラメータリストの変更やフィールドAPI の変更を自動で検出し分類するツールとして，APID-

名の変更といったリファクタリングとして分類すべき API

iﬀ [4] が提案されている．APIDiﬀ は Java ライブラリの 2の変更を API の削除および API の追加として誤って分類つのバージョンを入力として受け取ると，そのバージョする場合がある．その結果，開発者や API の利用者が APIン間で適用された API の変更操作のリストを出力する．

の変更に対して誤った認識を持つ可能性がある．

APIDiﬀ は RefDiﬀ [5] と呼ばれるリファクタリング検出

そこで本研究は，コードの類似性の閾値に依存しない方

ツールを利用している．RefDiﬀ は静的解析とコードの類法を用いて API の変更をより高い精度で分類できるように似性に基づいて 2 つのバージョン間で適用されたリファクすることを目的とする．APIDiﬀ を改造し，RefDiﬀ の代わ

タリング操作のリストを出力する．APIDiﬀ は静的解析をりに RefactoringMiner [10] を用いて，API の変更を分類行うことでバージョンごとの API の要素（クラス，メソッする手法を提案する．RefactoringMiner は Java ライブラ

ド，フィールド）を検出し，変更前後の API 要素の比較結リの 2 つのバージョンを入力として受け取ると，ステート

果と RefDiﬀ によって得られるリファクタリング操作のリ

メントマッピング情報と抽象構文木のノード置換に基づい大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology, Osaka University
m-iriyam@ist.osaka-u.ac.jp
higo@ist.osaka-u.ac.jp
kusumoto@ist.osaka-u.ac.jp

リストを出力する．これによってコードの類似性の閾値にてそのバージョン間で適用されたリファクタリング操作の
1

a)
b)
c)

c 1959 Information Processing Society of Japan⃝

依存せずにリファクタリングを検出できる．提案手法では静的解析を行うことでバージョンごとの API の要素を検出し，変更前後の API 要素の比較結果と RefactoringMiner

1

情報処理学会研究報告
IPSJ SIG Technical Report

入力

Step 1
ライブラリのインスタンスの
作成

変更前

変更後

変更前後の
ライブラリ

Step 3
変更前後のAPI要素の対応付け

Step 4
API要素とリファクタリング操作の対応付け

Step 5
APIの変更操作の
リスト作成

クラス1
-フィールドa-メソッドb
クラス2-メソッドc-メソッドd・・・

クラス1-フィールドa-メソッドb
クラス2-メソッドc-メソッドd・・・

クラス1-フィールドa-メソッドb
クラス2-メソッドc-メソッドd・・・

クラス1-フィールドa-メソッドB
クラス2-メソッドd-メソッドe・・・

クラス1-フィールドa-メソッドB
クラス2-メソッドd-メソッドe・・・

クラス1-フィールドa-メソッドB
クラス2-メソッドd-メソッドe・・・

ライブラリのインスタンス

対応付けられたAPI要素

リファクタリング操作と対応付けられたAPI要素

Step 2
リファクタリングの検出

RefDiff

出力
クラス1の非推奨化
フィールドaの型の変更
メソッドbからメソッドBにリネーム
メソッドcの削除
メソッドdの戻り値の型変更
メソッドeの追加
・・・

APIの変更操作のリスト⚫ 変更前後で対応付けられたAPI要素⚫ 変更前後で対応付けできなかったAPI要素⚫ リファクタリング操作と対応付けられたAPI要素

メソッドのリネーム
クラス1のメソッドbから
クラス1のメソッドBへ
・・・

リファクタリング操作のリスト

図 1 APIDiﬀ の概要によって得られるリファクタリング操作のリストをもとStep 2 バージョン間で行われたリファクタリングの検出に，API の変更を検出してその種類ごとに分類する．8 個

Step 3 変更前後の API 要素の対応付けのオープンソースソフトウェア（以下 OSS）に対して実験

Step 4 API の要素とリファクタリング操作の対応付けを行った結果，既存手法と比べて API の変更をより高い

Step 5 API の変更操作のリストを作成

精度で分類できることを確認した．また，提案手法によりStep 1 では入力として受け取った Java ライブラリの 2

API に対して行われたリファクタリングの検出数が増加しつのバージョンに対して静的解析を行い，バージョンごとたことが明らかになった．

のライブラリのインスタンスを作成する．このインスタン

2. 準備
2.1 RefDiﬀ

スは可視性修飾子が public または protected で外部に公開されているクラス，メソッド，フィールドといった APIの要素の情報を保持している．

RefDiﬀ とはリファクタリングを検出するツールの 1 つStep 2 では APIDiﬀ の入力として与えられた Java ライである．Java ライブラリの 2 つのバージョンを入力としてブラリの 2 つのバージョンを RefDiﬀ の入力として与え，受け取り，静的解析とコードの類似性に基づいてそのバー

そのバージョン間で適用されたリファクタリング操作のリジョン間で適用されたリファクタリング操作のリストを出ストを得る．

力する．このリストには API に対して行われたリファク

Step 3 では Step 1 で得られた変更前後のライブラリイ

タリング操作だけでなく，プライベートメソッドに対するンスタンスを比較し，変更前後の API 要素の対応付けをリファクタリングのように API 以外のクラスやメソッド，

行う．クラスについては完全限定名が一致するクラスを，フィールドに対して行われたリファクタリング操作も含まメソッドについてはそのメソッドが所属するクラスの完全れている．コードの類似性の閾値は，10 個の OSS からラ

限定名とメソッド名，パラメータの並びの 3 種類全てが一ンダムに選択された 10 個のコミットに対する実験結果を致するメソッドを，フィールドについてはそのフィールド

もとに決定されている．

が所属するクラスの完全限定名とフィールド名が一致する
フィールドを対応付ける．

2.2 APIDiﬀ の検出方法

Step 4 では，Step 3 で対応付けることができなかった

APIDiﬀ は Java ライブラリの 2 つのバージョンを入力とAPI の要素と Step 2 で得られたリファクタリング操作のして受け取り，静的解析と RefDiﬀ を用いてそのバージョン

対応付けを行う．対応付けられなかった API の要素がリ間で API に対して行われた変更操作のリストを出力する．

ファクタリング操作のリストに含まれていれば，リファク

API の変更の検出は次の 5 つのステップで構成される．

タリングされた要素，そうでなければ削除された要素またその概要を図 1 に示す．

は追加された要素として分類する．

Step 1 2 つのバージョンのライブラリインスタンスを作成

c 1959 Information Processing Society of Japan⃝2

情報処理学会研究報告
IPSJ SIG Technical Report

Step 5 では，Step 3 と Step 4 で行われた API 要素の対
応付けの結果と API 要素の情報を参照し，どの API が削
除・追加・リファクタリングされたのか，どの API が非推

変更前

変更後

public void setX(float i){
x = i;}

public void setX(int i){
x = i;}

奨化されたのか、どの API の可視性修飾子が変更されたの⚫ メソッドの削除

か，どのフィールドが型を変更されたのか，どのメソッド
が戻り値の型を変更されたのか，といった情報を得る．それらの情報をもとに API の変更操作のリストを作成する．
図 1 において，Step 3 で対応付けができなかった API の要素は変更前のメソッド b とメソッド c，変更後のメソッ⚫ メソッドの追加(a) APIDiﬀ の出力
変更前

変更後

public void setX(float i){
x = i;}

public void setX(int i){
x = i;}

ド B とメソッド e である．RefDiﬀ によって得られるリス⚫ パラメータリストの変更

トよりメソッド b がメソッド B にリネームされたことがわかるので，メソッド b とメソッド B が対応付けられ，それ以外のメソッド c は削除された API の要素，メソッド eは追加された API の要素だと判断される．

3. 研究目的(b) 実際の API の変更操作
図 2

実際の API の変更操作と APIDiﬀ の出力が異なる例

4.1 RefactoringMiner
RefactoringMiner は Java ライブラリの 2 つのバージョンを入力として受け取ると，メソッド本体のステートメン

APIDiﬀ は RefDiﬀ によって得られるリファクタリング

トに関するマッピング情報と抽象構文木のノード置換に基操作のリストをもとに API の要素をリファクタリングさづいてそのバージョン間で適用されたリファクタリング操れた要素，削除された要素，追加された要素に分類してい作のリストを出力する．これによってコードの類似性の閾る．しかしコードの類似性の閾値を適切に設定することは値に依存せずにリファクタリングを検出できる．ステート

難しく，RefDiﬀ で検出できないリファクタリングが存在

メントマッピングは，メソッドに含まれる各文を変更前後する．そのため RefDiﬀ が API に対するリファクタリング

で対応付けた情報である．リファクタリング操作のリストを検出できなかった場合は，そのリファクタリングされたには API に対して行われたリファクタリング操作だけでAPI の要素を削除された要素または追加された要素としてなく，API 以外のクラスやメソッド，フィールドに対して分類してしまう．

行われたリファクタリング操作も含まれている．

図 2 に実際の API の変更操作と APIDiﬀ の出力が異なる例を示す．変更前後で APIDiﬀ を用いて得られる変更操

4.2 API の変更の分類方法

作は，変更前のメソッド setX(float i) の削除，変更後

既存手法と同様に提案手法における API の変更の分類はのメソッド setX(int i) の追加となる (図 2(a))．しかし，次の 5 つのステップで構成される．その概要を図 3 に示す．

実際に行われた API の変更操作はメソッド setX のパラ

Step 1 2 つのバージョンのライブラリインスタンスを作成

メータを float から int に変更するリファクタリング操

Step 2 バージョン間で行われたリファクタリングの検出作である（図 2(b)）．この違いは，RefDiﬀ の類似性の閾値

Step 3 変更前後の API 要素の対応付けが高く設定されていることが原因であり，APIDiﬀ は API

Step 4 API の要素とリファクタリング操作の対応付けのパラメータの変更として検出することができなかった．

Step 5 API の変更操作のリストを作成

setX(float i) を利用していた API 利用者はパラメータ

Step 1 は既存手法の Step 1 の処理を再利用した．

の型を変更するだけで，その API を利用し続けることがで

Step 2 では APIDiﬀ の入力として与えられた Java ライ

きるのにもかかわらず，setX(float i) が削除されたためブラリの 2 つのバージョンを RefactoringMiner の入力と同様の機能を持つ API を探す必要があると誤った認識をして与え，バージョン間で適用されたリファクタリング操持ち，生産性が下がってしまうおそれがある．

作のリストを得る．

そこで，本研究では類似性の閾値に依存しない方法でAPI の変更をより高い精度で分類する手法を提案する．

4. 提案手法

Step 3 では既存手法と同様に変更前後の API 要素の対応付けを行う．ただしメソッドについてはそのメソッドが所属するクラスの完全限定名とメソッド名，パラメータの並びに戻り値の型を加えた 4 種類全てが一致するメソッドを，提案手法では，ステートメントマッピング情報と抽象構

フィールドについてはそのフィールドが所属するクラスの文木のノード置換に基づいてリファクタリングを検出する

完全限定名とフィールド名にフィールドの型を加えた 3 種RefactoringMiner を利用し，API の変更を分類する．これ

類全てが一致するフィールドを対応付けるように変更した．

によってコードの類似性の閾値に依存せず，API の変更を

これは既存手法のように変更前後で対応付けた API 要素の分類することが可能である．

情報を比較することでフィールドの型の変更やメソッドのc 1959 Information Processing Society of Japan⃝3

情報処理学会研究報告
IPSJ SIG Technical Report

入力

Step 1
ライブラリのインスタンスの
作成

変更前

変更後

変更前後の
ライブラリ

Step 3
変更前後のAPI要素の対応付け

Step 4
API要素とリファクタリング操作の対応付け

Step 5
APIの変更操作の
リスト作成

クラス1
-フィールドa-メソッドb
クラス2-メソッドc-メソッドd・・・

クラス1-フィールドa-メソッドb
クラス2-メソッドc-メソッドd・・・

クラス1-フィールドa-メソッドb
クラス2-メソッドc-メソッドd・・・

クラス1-フィールドa-メソッドB
クラス2-メソッドd-メソッドe・・・

クラス1-フィールドa-メソッドB
クラス2-メソッドd-メソッドe・・・

クラス1-フィールドa-メソッドB
クラス2-メソッドd-メソッドe・・・

ライブラリのインスタンス

対応付けられたAPI要素

リファクタリング操作と対応付けられたAPI要素

Step 2
リファクタリングの検出

Refactoring
Miner

出力
クラス1の非推奨化
フィールドaの型の変更
メソッドbからメソッドBにリネーム
メソッドcの削除
メソッドdの戻り値の型変更
メソッドeの追加
・・・

APIの変更操作のリスト⚫ 変更前後で対応付けられたAPI要素⚫ 変更前後で対応付けできなかったAPI要素⚫ リファクタリング操作と対応付けられたAPI要素

フィールドの型の変更
クラス1のフィールドa
メソッドのリネーム
クラス1のメソッドbから
クラス1のメソッドBへ
メソッドの戻り値の型変更
クラス2のメソッドd・・・

リファクタリング操作の
リスト

図 3

提案手法の概要

戻り値の型変更を検出するのではなく，RefactoringMiner
によってフィールドの型の変更やメソッドの戻り値の型変更を検出し，そのリファクタリング操作と API 要素と対応

5.1 評価項目提案手法を評価するために 3 つの評価項目を設定した．
リファクタリングの検出数付けるためである．これによって変更前後で API 要素が提案手法と既存手法からそれぞれ得られる検出結果を比所属するクラスの完全限定名や API 要素の名前などが一較し，API に対して行われたリファクタリングの検出数に致しない場合でも，フィールドの型の変更やメソッドの戻どのような変化が見られるのかを調べる．またリファクタ

り値の型変更を検出できるようになった．

リングの種類別に検出結果を比較し，どのような変化が見

Step 4，Step 5 では既存手法と同様の方法で API の要素とリファクタリング操作の対応付けと API の変更操作のリスト作成を行う．

られるかを調べる．
分類精度
提案手法によって API の変更をより高い精度で分類でき

図 3 の例において，Step 3 で対応付けができなかった

るかどうかを検証する．提案手法によって改善が期待されAPI の要素は変更前のフィールド a とメソッド b，メソッ

る変更は API に対するリファクタリングであるため，検出

ド c，メソッド d と変更後のフィールド a とメソッド B，メされたリファクタリングが実際に正しいのかを確認する．

ソッド d，メソッド e である．RefactoringMiner によって実行時間得られるリストよりフィールド a の型が変更されたこと，

提案手法の実行時間と既存手法の実行時間を比較し，提メソッド b がメソッド B にリネームされたこと，メソッド

案手法の処理速度を評価する．またどの処理に時間を要す

d の戻り値の型が変更されたことががわかるので，変更前

るのかを確認する．

後のフィールド a，メソッド b とメソッド B，変更前後のメソッド d が対応付けられる．それ以外のメソッド c は削除された API の要素，メソッド e は追加された API の要
素だと判断される．

5. 実験
本章では，提案手法を用いて行なった実験とその結果について述べる．

c 1959 Information Processing Society of Japan
⃝

表 1 実験対象の OSS
プロジェクト名

LOC

コミット数

OkHttp72,061

4,779

対象の最終コミット日

2021 年 1 月 9 日

Retroﬁt

26,995

1,8622020 年 12 月 10 日

MPAndroidChart

25,2322,068

2020 年 10 月 30 日

LeakCanary

26,2071,5542021 年 1 月 6 日

Hystrix

50,5102,108

2018 年 11 月 20 日

iosched23,5502,7572020 年 6 月 26 日

Fresco98,4272,768

2021 年 1 月 12 日

Logger

1,441

144

2018 年 4 月 10 日

4情報処理学会研究報告
IPSJ SIG Technical Report

5.2 実験対象

5.3.2 リファクタリング別の検出数の比較関連研究 [11] で用いられている OSS のうち，コミット

8 個の OSS の中から MPAndoridChart を選択し，提案数が 20,000 以下でスター数が多い OSS から順に 8 個の手法と既存手法からそれぞれ得られる検出結果をリファク

OSS を実験対象とした．実験対象の OSS を表 1 に示す．

タリングの種類別に比較した．その結果が表 3 である．提

コミット数に制限を設けた理由は，大規模な OSS に対し案手法では既存手法で検出された 14 種類のリファクタリて提案手法，既存手法のどちらを適用しても実行時間がングに加えて，Change in Parameter List や Rename Field

長くなり評価が難しいためである．リファクタリング別など新たに 8 種類のリファクタリングを検出した．また両の検出数の比較と分類精度の比較では 8 個の OSS のうち手法で検出された 14 種類のリファクタリングについて提MPAndroidChart のみを対象とした．これは APIDiﬀ の適案手法は既存手法以上の数のリファクタリングを検出した．

用事例でも利用されていた OSS である．

5.4 既存手法との分類精度の比較
5.3 既存手法とのリファクタリングの検出数の比較

8 個の OSS の中から MPAndoridChart を選択し，提案

5.3.1 全リポジトリに対しての検出数の比較

手法と既存手法からそれぞれ得られる検出結果を目視確認

実験対象の 8 個の OSS の master ブランチ*1 上に存在すすることで分類の精度の比較を行なった．提案手法のみでる全てのコミットに対して提案手法と既存手法を適用し検出された API に対するリファクタリングと既存手法のみた．提案手法と既存手法からそれぞれ得られる検出結果で検出された API に対するリファクタリングを目視確認しを比較し，API に対して行われたリファクタリングの検た．提案手法のみで検出された API に対するリファクタリ

出数にどのような変化が見られるのかを調べた．その結ングの数が多かったため，許容誤差 5%，信頼度 95%とな

果が表 3 である．既存手法では実験対象のリポジトリかるように 289 個サンプリングを行った．またリファクタリ

ら 1,985（=1,626+359）個の API に対するリファクタリン

ングの種類ごとに可能な限り均等になるようにサンプリン

グしか検出できなかったのに対して，提案手法では 4,581グを行なった．既存手法のみで検出された API に対する（=1,626+2,955）個の API に対するリファクタリングを検

リファクタリングは全て目視確認を行った．目視確認を行出できた．すべてのプロジェクトにおいて提案手法が検出なった結果が表 3 の通りである．Change in Return Typeした API に対するリファクタリングの数が，既存手法がMethod と Move Method については既存手法の適合率が検出した API に対するリファクタリングの数を上回った．

提案手法の適合率より高くなったが，全体としては既存手

また提案手法のみが検出した API に対するリファクタリ法の適合率が 79.5%であったのに対して提案手法の適合率

ングの数は，提案手法または既存手法によって検出されたが 88.6%と高い結果となった．

API に対するリファクタリングの総数の 31.3%〜76.6%を占めており，その平均は 59.8%であった．それに対して既

5.5 既存手法との実行時間の比較

存手法のみが検出した API に対するリファクタリングの

実験対象の 8 個の OSS の master ブランチ上に存在する数は，提案手法または既存手法によって検出された API に

全てのコミットに対して提案手法と既存手法を適用し，実対するリファクタリングの総数の 3.8%〜17.3%を占めてお行時間を比較した．実験に用いた計算機の性能を表 4 に示り，その平均は 7.3%であった．

す．実験結果を図 4 に示す．図 4 においてチェックアウト
はライブラリを別のバージョンに切り替える処理を表す．
その他には対象の OSS がローカルに存在するのかを確認*1

LeakCanary についてはデフォルトのブランチが main ブランチであるため，main ブランチに対して実験を行なった．
表 2
プロジェクト名する処理やコミットグラフをたどって一致するコミットを

API に対するリファクタリングの検出数

両手法が検出した提案手法のみが検出した

既存手法のみが検出したリファクタリングの数

リファクタリングの数

リファクタリングの数

合計

OkHttp286（51.4%）

174（31.3%）

96（17.3%）

556

Retroﬁt154（48.7%）

135（42.7%）27（ 8.5%）

316

MPAndroidChart709（36.5%）

1,161（59.8%）

LeakCanary

15（16.1%）

66（71.0%）73（ 3.8%） 1,943
12（12.9%）93

Hystrix

128（24.4%）342（65.1%）55（10.5%）525

iosched91（32.7%）

143（51.4%）44（15.8%）

278

Fresco226（19.2%）

901（76.6%）50（ 4.2%） 1,177

Logger17（32.7%）

33（63.5%）2（ 3.8%）

1,626（32.9%）

2,955（59.8%）

合計

c 1959 Information Processing Society of Japan⃝52

359（ 7.3%） 4,940

5情報処理学会研究報告
IPSJ SIG Technical Report
3000

2500

2000

(

実
行
時 1500
間
秒

)
1000

500

0
提
案
手
法

既
存
手
法

提
案
手
法

OkHttp

既
存
手
法

提
案
手
法

Retrofit

既
存
手
法

提
案
手
法

MPAndroidChart

チェックアウト既存手法

LeakCanary

ライブラリのインスタンスの作成

提
案
手
法

既
存
手
法

提
案
手
法

Hystrix

既
存
手
法

提
案
手
法

iosched

リファクタリングの検出

既
存
手
法

提
案
手
法

Fresco

APIの変更の分類

既存
手法

Logger

その他

図 4 API に対する変更の検出に要する時間

順番に生成する処理などが含まれる．

クタリングの検出時間が長くなったためである．また提案

Fresco を除く 7 個の OSS において提案手法の実行時間

手法は既存手法と比較してチェックアウトやライブラリのは既存手法の実行時間より長くなった．主な原因はリファ

インスタンスの作成に要する時間も長くなった．その原因を調べるためにどのメソッドの実行時間が増加したのかを

表 4

実験に用いた計算機の性能調査した結果，APIDiﬀ が外部ライブラリとして使用してOSmacOS Big SurCPUIntel Core i5（1.4GHz，4 コア）

GPUIntel Iris Plus Graphics 645

メモリ

16GB

いる JGit と JDT のメソッドの実行時間が増加していた．
提案手法では RefactoringMiner を利用するために JGit とJDT のバージョンをアップグレードした. それによって

表 3

リファクタリング別の検出数と適合率

両手法が検出した提案手法のみが既存手法のみがリファクタリング

検出したリファクタリング

検出したリファクタリング

リファクタリングの種類

検出数

検出数

Pull Up Method

114

93

Rename Method

147

51

サンプル

サンプル

適合率（%）

検出数

19

100

21

21

100

19

78.9

22

22

66.2

サイズ

適合率（%）

サイズ

Change in Return Type Method

125

42

19

94.7

3

3

100

Move Method

59

39

19

15.8

13

13

61.5

Move Field

45

18

18

100

1

1

100

Push Down Method

27

24

19

100

3

3

100

Inline Method

6

33

19

100

3

3

100

Rename Type

27

2

2

100

2

2

100

Push Down Field

6

2

2

100

1

1

100

Extract Method

0

128

20

85.0

4

4

25.0

Move Type

69

6

6

83.3

0

0

Change in Field Type

53

8

8

100

0

0

Pull Up Field

28

19

19

100

0

0

Move and Rename Type

3

2

2

50.0

0

0

Change in Parameter List

0

558

20

100

0

0

Rename Field

0

48

19

100

0

0

Extract Supertype

0

36

19

94.7

0

0

Move and Rename Method

0

31

19

73.7

0

0

Extract Type

0

13

13

92.3

0

0

Extract Field

0

3

3

100

0

0

Move and Rename Field

0

3

3

100

0

0

Extract Subtype

0

2

2

100

0

0

709

1,161

289

88.6

73

73

平均

c 1959 Information Processing Society of Japan
⃝

79.5

6

情報処理学会研究報告
IPSJ SIG Technical Report
変更前

変更後

public Entry getEntryForXIndex(int x) {return null;}public FillFormatter getFillFormatter() {return null;}⚫ メソッドの戻り値の型変更(a) 提案手法の出力
変更前

変更後

public Entry getEntryForXIndex(int x) {return null;}public FillFormatter getFillFormatter() {return null;}⚫ メソッドの削除⚫ メソッドの追加(b) 実際の API の変更操作
図 5

提案手法が Change in Return Type として誤って検出した例

JGit と JDT の API の処理が変更され，その API を利用

getEntryForXIndex(int x) と getFillFormatter() がしていたチェックアウトやライブラリのインスタンスの作

異なるメソッドであると RefactoringMiner が判別できな

成の実行時間が増加した.

かったことが原因である．これを解決するためにはメソッ

6. 考察

ド本体の文が一致するかどうかだけでなく，一致する文がいくつあるのかも考慮する．

表 3 において提案手法の適合率より既存手法の適合率が高い Change in Return Type Method および Move Method

6.2 Move Method

について考察する．また Extract Supertype および Extract

表 3 において提案手法の検出数は既存手法の検出数より

Method について，検出数に違いが見られた要因をコードの多いが，適合率が 15.8%と低い値となっている．これは，類似性の閾値以外の観点から考察する．Extract Supertype

RefactoringMiner が一部の Pull Up Method と Push Down

は既存手法でも仕様上検出可能とされている種類だが，実Method を Move Method として出力してしまうためであ際には検出されなかった変更である．Extract Method はる．提案手法では RefactoringMiner の検出結果を利用し両手法で検出可能なリファクタリングの種類のうち両手法ているため，本来 Pull Up Method や Push Down Methodが検出した数が 0 であった変更である．

として分類すべき変更を Move Method として誤って分類してしまう．これを解決するためには RefactoringMiner

6.1 Change in Return Type Methodによる誤検出を改善する必要がある．

表 3 において既存手法のみが検出したリファクタリング
は 3 個のみであったのに対して提案手法のみが検出した数

6.3 Extract Supertype および Extract Method

は 42 個となっており，提案手法の方がより多くのリファク

表 3 において Extract Supertype および Extract Method

タリングを検出している．また提案手法の適合率は 94.7%

について検出数に違いが見られた．これは提案手法と既存であり，既存手法の適合率 100%と比べると低いがその差手法で API のクラスおよびメソッドとリファクタリング操

は小さい．

作の対応付けの実装が異なるためである．API のクラスお既存手法では戻り値の型に加えてパラメータリスト

よびメソッドは可視性修飾子が public または protected

お よ び メ ソ ッ ド 名 が 変 更 さ れ た 場 合 ，Change in Re-

であり外部に公開されているクラスおよびメソッドである.

turn Type Method を 検 出 で き な か っ た ．し か し 提 案

まず Extract Supertype について述べる．Extract Su-

手 法 で は そ の よ う な 場 合 で も Change in Return Typepertype とはクラスの一部を切り出してスーパークラスをMethod を検出できた．提案手法がメソッドの削除およ作成する変更である．以降では Extract Supertype によっびメソッドの追加を Change in Return Type Method とて作成されたスーパークラスを抽出されたスーパークラス，

して誤って検出した実際の例を図 5 に示す．変更前後

一部を切り出されるクラスを抽出元のクラスと呼称する．

で提案手法を用いて得られる変更操作は，メソッドの両手法においてまず変更前後でクラスの完全限定名が一致

戻り値の型変更となる (図 5(a))．しかし実際に行われたする API のクラスを対応付ける．対応付けることができ

API の変更操作は getEntryForXIndex(int x) の削除おなかった API のクラスが RefDiﬀ または RefactoringMiner

よび getFillFormatter() の追加である（図 5(b)）．こによって得られるリファクタリング操作のリストに含まれの違いは，メソッド本体の return 文だけではメソッドていれば，リファクタリングされたクラス，そうでなけれ

c 1959 Information Processing Society of Japan⃝7

情報処理学会研究報告
IPSJ SIG Technical Reportば削除されたクラスまたは追加されたクラスとして分類すないリファクタリングについて十分な数を目視確認するこる．変更前後で対応付けることができなかった API のクとや実行時間を短縮できるようにツールを改善することがラスと Extract Supertype の対応付けについて提案手法で挙げられる．

は，対応付けることができなかった変更後の API のクラ

謝辞 本研究の一部は，日本学術振興会科学研究費補助

スが抽出されたスーパークラスなのかを調べる．それに対金基盤研究（B）（課題番号：20H04166）の助成を得て行して既存手法では対応付けることができなかった変更前の

われた．

API のクラスが抽出元のクラスなのかを調べる．提案手法
で検出された Extract Supertype を確認したところ，抽出

参考文献

元のクラスの完全限定名は変更されていなかった．変更前[1]の抽出元のクラスと変更後の抽出元のクラスが対応付けられるため，既存手法ではリファクタリング操作との対応付けが行われず，Extract Supertype の検出数が 0 となった．

[2]

次は Extract Method について述べる．Extract Methodとはメソッドの一部を切り出して別のメソッドにする変更である．以降では Extract Method によって作成されたメ[3]

ソッドを抽出されたメソッド，一部を切り出されるメソッドを抽出元のメソッドと呼称する．変更前後で対応付けることができなかった API のメソッドと Extract Method の対応付けについて提案手法では，対応付けることができな[4]

かった変更後の API のメソッドが抽出されたメソッドなのかを調べる．それに対して既存手法では対応付けることができなかった変更前の API のメソッドが抽出元のメソッ[5]ドなのかを調べる．提案手法または既存手法で検出された

Extract Mehod の大部分で，変更前の抽出元のメソッドと変更後の抽出元のメソッドが対応付けられるため，既存手法ではリファクタリング操作との対応付けが行われず，[6]

Extract Method の検出数が少なくなった．

7. 妥当性の脅威
提案手法の分類の精度を評価するために目視確認を行[7]なった．しかしこの結果は著者の主観に依存しており，リ
ファクタリングでないにも関わらずリファクタリングと判断したり，リファクタリングであるにも関わらずリファク
タリングでないと判断したりしている可能性がある．

[8]

検出数が少ないリファクタリングについて十分な数を目視確認することができなかったため，適合率を適切に求められていない可能性がある．

[9]

8. おわりに本研究では，コードの類似性の閾値に依存せず抽象構文
木を用いてリファクタリングを検出する RefactoringMiner[10]を利用し，API の変更を分類する手法を提案した．提案手法を用いて 8 個の OSS に対して実験を行ったところ，既存手法と比べて API の変更をより高い精度で分類できることを確認した．また，提案手法により API に対して行われたリファクタリングの検出数が増加したことが明らかになった．
今後の課題としては対象の OSS を増やし，検出数が少c 1959 Information Processing Society of Japan⃝[11]

Moser, S. and Nierstrasz, O.: The eﬀect of objectoriented frameworks on developer productivity, Computer, Vol. 29, No. 9, pp. 45–51 (online), DOI:
10.1109/2.536783 (1996).
Michail, A.: Data mining library reuse patterns in userselected applications, 14th IEEE International Conference on Automated Software Engineering, pp. 24–33(online), DOI: 10.1109/ASE.1999.802089 (1999).
Moreno, L., Bavota, G., Penta, M. D., Oliveto, R., Marcus, A. and Canfora, G.: ARENA: An Approach for theAutomated Generation of Release Notes, IEEE Transactions on Software Engineering, Vol. 43, No. 2, pp. 106–127 (online), DOI: 10.1109/TSE.2016.2591536 (2017).
Brito, A., Xavier, L., Hora, A. and Valente, M. T.:
APIDiﬀ: Detecting API breaking changes, 2018 IEEE
25th International Conference on Software Analysis,
Evolution and Reengineering (SANER), pp. 507–511(online), DOI: 10.1109/SANER.2018.8330249 (2018).
Silva, D. and Valente, M. T.: RefDiﬀ: Detecting
Refactorings in Version Histories, 2017 IEEE/ACM
14th International Conference on Mining Software
Repositories (MSR), pp. 269–279 (online), DOI:
10.1109/MSR.2017.14 (2017).
Xavier, L., Brito, A., Hora, A. and Valente, M. T.: Historical and impact analysis of API breaking changes:
A large-scale study, 2017 IEEE 24th International
Conference on Software Analysis, Evolution andReengineering (SANER), pp. 138–147 (online), DOI:
10.1109/SANER.2017.7884616 (2017).
Brito, A., Xavier, L., Hora, A. and Valente, M. T.: Whyand how Java developers break APIs, 2018 IEEE 25th
International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 255–265 (online),
DOI: 10.1109/SANER.2018.8330214 (2018).
Brito, A., Valente, M. T., Xavier, L. and Hora, A.: You
broke my code: understanding the motivations for breaking changes in APIs, Empirical Software Engineering,pp. 1458–1492 (online), DOI: 10.1007/s10664-019-09756z (2020).
Xavier, L., Hora, A. and Valente, M. T.: Why do webreak APIs? First answers from developers, 2017 IEEE
24th International Conference on Software Analysis,
Evolution and Reengineering (SANER), pp. 392–396(online), DOI: 10.1109/SANER.2017.7884640 (2017).
Tsantalis, N., Ketkar, A. and Dig, D.: RefactoringMiner
2.0, IEEE Transactions on Software Engineering, pp.
1–1 (online), DOI: 10.1109/TSE.2020.3007722 (2020).
Cedrim, D., Garcia, A., Mongiovi, M., Gheyi, R., Sousa,
L., de Mello, R., Fonseca, B., Ribeiro, M. and Chávez,
A.: Understanding the Impact of Refactoring on Smells:
A Longitudinal Study of 23 Software Projects, Proceedings of the 2017 11th Joint Meeting on Foundationsof Software Engineering, pp. 465–475 (online), DOI:
10.1145/3106237.3106259 (2017).

8