VOL. J102-D NO. 11
NOVEMBER 2019
本PDFの扱いは、電子情報通信学会著作権規定に従うこと。
なお、本PDFは研究教育目的（非営利）に限り、著者が第三者に直接配布することができる。著者以外からの配布は禁じられている。

論

文

メソッドレベルセマンティックバージョニングの提案と評価
林純一† a)

肥後

芳樹†

楠本

真二†

Proposition and Evaluation of Method-level Semantic Versioning
Junichi HAYASHI†a) , Yoshiki HIGO† , and Shinji KUSUMOTO†

あらまし ソフトウェア開発において利用されるライブラリには，機能追加や改善，バグ修正などによる時系
列的変化を区別するためのバージョンが付与される．バージョニング手法に後方互換性の有無を反映させるセマ
ンティックバージョニングと呼ばれる手法がある．この手法でライブラリに付与されたバージョンからライブラ
リの後方互換性の有無は判断できるが，API ごとの後方互換性の有無は判断できない．そこで本研究では，メソッド単位でセマンティックバージョニングを行う手法を提案し，提案手法を用いて Java 言語のメソッドに自動でバージョニングを行うツールを作成した．本手法によりメソッド単位でバージョニングを行うことで，メソッ
ドごとの後方互換性の有無を自動で判断できるようになる．更に，提案手法及び作成したツールの有用性を示す
ために，後方互換性のない変更が行われたメソッドを検出する実験を行い，既存研究との差異を調査した．その結果，提案手法を用いることにより，既存研究では検出できなかった変更を検出できることが分かった．
キーワード メソッドレベルセマンティックバージョニング，バージョン管理システム，ソフトウェアライブ
ラリ，API

ることも指摘している．Kula ら [4] は，ライブラリの1. ま え が き

アップデートへの追従は追加のコストがかかるため優ソフトウェア開発において利用されるライブラリ

先されず，古いバージョンのライブラリに依存し続けには，機能の追加や改善あるいはバグ修正が行われるソフトウェアが存在することを指摘している．これる．このような時系列的変化を区別するために「バーは，ソフトウェア開発者がライブラリのバージョンをジョン」が与えられる．このバージョンを決定する

見ただけでは後方互換性の有無を正確に判断できず，手法としてセマンティックバージョニング（Semantic

アップデートの適用に伴う修正作業の必要性や影響範Versioning）という，一つのバージョンを三つ組の整囲を見積もるのに追加のコストがかかるためであると数を用いて表す方法が提唱されている [1]．

著者らは考える．

セマンティックバージョニングでは，公開されていまた，セマンティックバージョニングを遵守している API（Application Programming Interface）に行る場合でも別の問題が挙げられる．後方互換性がない

われた変更に後方互換性があるかどうかをバージョン

変更が行われた API が一つだけであったとしても，ラに反映させる．Raemaekers らは既存の Java ライブ

イブラリのバージョンは後方互換性がないことを意味

ラリに対して Clirr [2] という API の変更検出ツール

するものになる．そのため，具体的にどの API に後を用いて調査を行い，セマンティックバージョニング

方互換性がないのかということについては別の手段にが遵守されていないライブラリの存在を指摘していより調べる必要がある．このような手間が発生してしる [3]．また，Raemaekers ら はソフトウェアが依存まうこともアップデートへの追従が遅れる要因の一つしているライブラリのアップデートへの追従が遅延すになっていると著者らは考える．
このような問題を解決するために，本論文ではメ†

大阪大学大学院情報科学研究科，吹田市

ソッド単位でバージョンを与える「メソッドレベルセ

Graduate School of Information Science and Technology,

マンティックバージョニング（Method-level Semantic

Osaka University, Suita-shi, 565–0871 Japan

Versioning）」という手法を提案する．また，実際にa) E-mail: j-hayasi@ist.osaka-u.ac.jp
DOI:10.14923/transinfj.2018JDP7074

730

電子情報通信学会論文誌

Java 言語のソースコードに対して提案手法を適用する

c 一般社団法人電子情報通信学会 2019
D Vol. J102–D No. 11 pp. 730–739 

論文／メソッドレベルセマンティックバージョニングの提案と評価ことによって，メソッドごとにバージョンを自動的に

2. 2 セマンティックバージョニングは遵守されていない

与えるツールを作成し，後方互換性のない変更が検出できることを確認する実験を行った．更に，Java ライ

Raemaekers らは，セマンティックバージョニング

ブラリの後方互換性について調査した既存研究 [3] での原則が実際のプロジェクトにおいて遵守されてい用いられた API の変更を検出するツールである Clirr

るか調査した [3]．Raemaekers らは Maven Centralの出力結果と，著者らが作成したツールの出力結果をRepository [5] に公開されている 22,205 個のソフト比較し，作成したツールでのみ検出できる変更を調査

ウェアを対象に調査した結果，本来後方互換性をもした．

つべきであるマイナーリリースの 35.7%，パッチリ

その結果，Clirr では検出できなかったメソッドのリースの 23.8%に後方互換性のない変更が一つ以上属するパッケージ名の変更や，メソッドの引数リスト含まれており，マイナーリリースやパッチリリースにの変更が検出できることが分かった．

は平均で約 30 個の後方互換性のない変更が含まれて

2. セマンティックバージョニング
2. 1 セマンティックバージョニングの定義

いた．

2. 3 バージョニングの問題点
バージョニングには幾つかの問題点がある．

セマンティックバージョニングでは，一つのバージョ

まず，前節で述べたようにセマンティックバージョ

ンを「X.Y .Z 」の形で表記する [1]．X, Y , Z は全て

ニングは遵守されていないことが少なくない．そのた非負整数であり，それぞれメジャーバージョン，マイめ，後方互換性があるはずのマイナーリリースやパッナーバージョン，パッチバージョンという．最初のリ

チリリースが行われたライブラリをアップデートした

リースに与えるバージョンは 1.0.0 とし，以後のリリー際に，実際には後方互換性がなかったために故障が発スに与えるバージョンは，現在のバージョンを基準に生してソースコードを修正しなければならなくなるこ

次のように決定する．

とが発生し得る．

メジャーリリース 公開されている API に後方互換

次に，ライブラリをリリースする際にバージョニン

性のない変更が取り入れられたとき，メジャーバー

グは人の手で主観的に行われることが多い．例えば，

ジョンを 1 増加させ，マイナーバージョンとパッチ

Google Guava というライブラリではバージョニング

バージョンを 0 にする．

のポリシーとしてセマンティックバージョニングを用

マイナーリリース 公開されている API に後方互換いることが定められているが，ツールなどの指定や推性のある変更が取り入れられたとき，あるいは新たに薦はされていない [6]．これは，バージョニングを自動機能が公開されたとき，マイナーバージョンを 1 増加化したり補助したりといったツールが開発されていなさせ，パッチバージョンを 0 にする．メジャーバージョ

い，あるいはそれが普及していないことが理由として

ンは変更しない．

あると考える．その一方で例えばコーディング規約やパッチリリース 誤った振る舞いを修正する後方互換

ソフトウェアテストに関しては，コーディング規約が性のある変更が取り入れられたときに限り，パッチ

守られているか検証するツール（たとえば [7]）やテス

バージョンを一つ増やす．メジャーバージョンとマイトを自動化するライブラリ（たとえば [8]）が存在する．

ナーバージョンは変更しない．
メジャーバージョン，マイナーバージョン，パッチ

別の問題として，セマンティックバージョニングが遵守されていたとしても，図 1 のようにメジャーリバージョンを増加させる変更を，それぞれメジャーレベル，マイナーレベル，パッチレベルの変更という．
メジャーリリースにマイナーレベルやパッチレベルの変更を含むことや，マイナーリリースにパッチレベルの変更を含むことは許可されている．
文献 [1] ではこのほかにプレリリースの扱いなど，幾つかの仕様が定められているが，本論文では以上で定義されるバージョンのみを取り扱う．
図1

ライブラリ単位でのバージョニング731

電子情報通信学会論文誌 2019/11 Vol. J102–D No. 11

リースで行われた変更の中には後方互換性のあるもの

ジョン B のライブラリのメソッドを利用できるとき，（図 1 の例では sort(List) 及び write(int)）が含まれてそのメソッドにはライブラリのバージョン A とバーいる可能性がある [3]．これはセマンティックバージョ

ジョン B の間で後方互換性があると定義する．

ニングの定義で許可されていることだが，メジャーリ

3. 1 適 用 対 象

リースされたライブラリを利用していても，そのリ提案手法は「メソッド」という名称のとおり，あるリースで変更された機能のうち後方互換性のなくなっ

一連の手続きに名前を付けて他の場所から呼び出せる

た機能は使用していない可能性がある．ライブラリの機能をもつ言語を対象としている．また，バージョン

変更内容は，リリースノートなどが用意されていれば管理システムを用いてソースコードのバージョン管理

それを参照することで確認できるが，用意されていなが行われていることも提案手法を適用するための条件

い場合や変更点が網羅しきれていない可能性が考えらとなる．提案手法は，主にライブラリの開発者が開発れる．これについても自動的に変更点を列挙すること中のソフトウェアに対して適用し，バージョンを決定

によって，リリースノートの網羅性を担保したり作成する一つの判断材料とされることを目的としているが，を補助したりすることにつながると考えられる．

リリース済みのバージョンに対して適用することも可

3. メソッドレベルセマンティックバージョ
ニング
本論文では，前章で述べた問題点を解消するために，
ソースコードの変更履歴をもとにメソッド単位でセマ
ンティックバージョニングを行い，各メソッドにバー能である．
提案手法は様々なプログラミング言語に対して適用できると考えられるが，現時点では Java 言語に対してのみ提案手法を適用するツールを作成している．そのため，以降の説明も Java 言語を用いて行う．

3. 2 アルゴリズム

ジョンを与える手法を提案する．以下，この手法を「メ各メソッドのバージョンを以下の手順で決定する．

ソッドレベルセマンティックバージョニング」と呼ぶ．

（ 1 ） メソッドの追跡

従来のバージョニングでは図 1 のようにライブラ（ 2 ） バージョンの決定

リ単位でしか後方互換性を示すことができないが，メ各手順について説明する．

ソッドレベルセマンティックバージョニングを行うこ(1) メソッドの追跡とによって，図 2 のように後方互換性がなくなったメ

あるリビジョン rn で変更されたメソッドが，そのソッド（図の例では get(Path)）を具体的に提示でき前のリビジョン rn−1 におけるどのメソッドかを特定るようになる．これにより，既にリリースされているする必要がある．

ソフトウェアに提案手法を適用した場合は，後方互換

リビジョン rn で変更された各メソッドについて，前性のないメソッドが存在することを利用者に周知するのリビジョン rn−1 に同じシグネチャ（メソッドの名称ことが可能になる．また，これからリリースしようとと引数の型 [9]）をもつメソッドが定義されていれば，しているソフトウェアに提案手法を適用した場合は，それらは同じメソッドであると考えられる．一方，前後方互換性のないメソッドが検出されたことをもってのリビジョン rn−1 に同じシグネチャをもつメソッド

メジャーリリースとする判断材料に用いることがでがない場合，そのメソッドがリビジョン rn で新たにきる．

追加されたメソッドであるのか，そのメソッドとは異

本論文では，あるバージョン A のライブラリの利用者が，ソースコードを修正することなく新しいバーなるシグネチャをもつメソッドのシグネチャを変更したものであるのかを判別しなければならない．
提案手法では，メソッドの本体の一致割合を基準にこれらを判別する．すなわち，リビジョン rn のあるメソッド m について，メソッドの本体が一定割合以上一致しており，かつリビジョン rn で削除されたメソッドがリビジョン rn−1 にある場合は，そのようなメソッドのうち最も一致している割合が大きいものをメソッド m の変更前のメソッドであるとし，そのよう

図 2 メソッド単位でのバージョニング

732

なメソッドがない場合はメソッド m がリビジョン rn

論文／メソッドレベルセマンティックバージョニングの提案と評価

で新たに追加されたメソッドであるとする．

(2) バージョンの決定(1) で得られたメソッドの対応関係から，あるリビ

4. 2 処理の流れ提案ツールが入力リポジトリに対して行う処理の流れを次に示す．

ジョン rn で変更されたメソッドは次の四つに分類でStep 1： コミット履歴を取得

きる．

Step 2： メソッドの追跡
Step 3： バージョンの決定

追加メソッド新たに追加されたメソッド

改名メソッドシグネチャが異なるメソッド

Step 2 と Step 3 は 3. 2 で述べたアルゴリズムに

修正メソッドシグネチャが同じメソッド

対応する．以下，各 Step の具体的な処理について述

削除メソッド削除されたメソッド

べる．

この分類をもとに，リビジョン rn において削除されたメソッドを除く各メソッドのバージョンを以下のStep 1：コミット履歴を取得
Git ではコミットを枝分かれさせてブランチを作っように定める．

たり，複数のブランチを一つのコミットに統合（マー追加メソッド

1.0.0 とする．

ジ）させたりでき，一般にコミットの履歴は図 3 のよ改名メソッドメソッドのシグネチャが変更された場

うなグラフになる．

合，あるいはメソッドのアクセス修飾子が狭まった場

提案ツールは，既定のブランチである master ブラ合（例えば，public 修飾子が private 修飾子に変更

ンチのコミットを解析し，枝分かれについては各コされた場合など）はメジャーバージョンを一つ増やす．

ミットのファーストペアレントのみを解析する．ここ

修正メソッド変更がバグ修正でなければマイナー

で，master ブランチの最新コミットからファーストバージョンを，バグ修正であればパッチバージョンをペアレントを辿り，古いコミットから順に並べたもの

一つ増やす．

を「（master ブランチの）コミット履歴」と呼ぶ．な

上記の修正メソッドの定義において，「変更がバグ修お，コミットの「ファーストペアレント」とはそのコ正である」ことは，その変更を含むコミットのコミッ

ミットが行われた際に HEAD が指していたコミットでトメッセージに “bug” または “ﬁx” という単語が含ある [11]．例えば，図 3 におけるコミット 2d3acf9 のまれていることと定義する．

ファーストペアレントはコミット 5e3ee11 であり，コ

4. Java メソッド自動バージョニングツールバージョン管理システムの一つである Git でバー
ジョン管理が行われている Java ソースコードに対し

ミット 5e3ee11 のファーストペアレントはコミット

420eac9（コミット 420eac9 からブランチ topic をマージした場合）である．以下，コミット履歴において古い方から n 番目のコミットを「n 番目のコミット」と呼ぶ．

て，メソッドレベルセマンティックバージョニングを解析対象のブランチを master ブランチに限定した

自動的に適用するツールを Java 言語を用いて作成しのは，解析した任意の 2 コミット間について，メソッ

た．以下ではこれを「提案ツール」と呼ぶ．提案ツードのバージョンを比較するだけで後方互換性の有無をルでプログラムから Git を操作するためのライブラリ

判別できるようにするためである．

として JGit [10] を採用した．

4. 1 ツールの概要
提案ツールの入力は Java ソースコードを含む Git
リポジトリであり，出力はメソッドレベルセマンティッ
クバージョニングの結果である．入力された Git リポ
ジトリのソースコードにおいて定義されているメソッドのバージョンを計算する．2. で述べたセマンティッ
クバージョニングの定義ではリリースごとにバージョ
ニングを行うとされているが，提案ツールではコミッ
トごとにセマンティックバージョニングを行う．
図3

コミットグラフの例733

電子情報通信学会論文誌 2019/11 Vol. J102–D No. 11

Step 1 ではコミットを遡りながら直近のタグも取得

チャが変更されたものとする．なお，基準値の 30%はする．タグとは Git においてコミットに付けられる別Historage が採用している値と同じである [14]．また，名で，例えば図 3 においてコミットを示す丸の左側にHistorage はリファクタリングなどによってメソッド

書かれた「v1.0.0」や「v1.1.0」である．

が別のクラスに移動されたために元のクラスからは削

Step 2：メソッドの追跡

除された場合も，移動元のメソッドと移動先のメソッ

提案ツールでは，入力された Git リポジトリを His-

ドが上記の基準で同じメソッドである場合は追跡され，

torage リポジトリ [12] に変換することでソースコード

3. 2 で述べた改名メソッドに分類される．同じでないからメソッドの情報を抽出する．Historage はメソッと判断された場合は追跡されず，移動元のメソッドはドレベルでバージョン管理を行える Git ベースのバー

削除メソッドに，移動先のメソッドは追加メソッドに

ジョン管理システムであり，これを用いることで Git分類される．

にメソッドの追跡を任せることができる．

Step 3：バージョンの決定

提案ツールでは Kenja [12], [13] によって Git リポ

Step 2 で求めたメソッドの対応関係から，3. 2 のジトリを Historage リポジトリに変換する．Git リポ(2) で述べた方法に従ってバージョンを決定する．なジトリを Kenja に入力すると，ソースコードからメ

お，提案ツールでは，メソッドの返り値の型が変更さ

ソッドの情報が抽出されて図 4 のような構造のディレれた場合あるいはアクセス修飾子が狭まった場合に後クトリが構築される．

方互換性がない変更が行われたとする．

Web 上 [13] に公開されている Kenja が取得するメソッドの情報はメソッドの引数と本体（図 4 のparameters ファイルと body ファイル）のみであり，

5. 実

験

提案手法の評価を行うために，以下の二つの実験を

返り値の型やアクセス修飾子の情報は取得しない．メ行った．

ソッドの引数と本体だけではメソッドの後方互換性を実験 1 提案手法を用いて，本来後方互換性があるは判断するためには不十分であり，返り値の型及びアクずのマイナーリリース及びパッチリリースにおいて，

セス修飾子の情報も考慮する必要があると考えられる．

後方互換性のない変更を含むリリースの割合を調査

提案ツールでは Kenja が利用する Java 言語のパーする．

サを返り値の型及びアクセス修飾子の情報（図 4 の実験 2 提案手法と既存の API 変更検出ツールであreturn ファイル及び modifiers ファイル）も取得す

る Clirr とを比較し，既存手法との差異を評価する．

るように修正して利用する．
提案ツールでは，コミット履歴の n 番目のコミッ

なお，本実験では public クラスに含まれる public
メソッドを API とみなして提案手法を適用した．

ト cn におけるメソッド fn とその一つ前のコミット

5. 1 実 験 対 象

cn−1 におけるメソッド gn−1 について，body ファイ

Apache Commons プロジェクトにおいて開発されルがバイト数を基準に 30%以上同じであるとき fn とており，かつ以下の条件を全て満たす 28 ライブラリ

gn−1 が同じメソッドであるとし，メソッドのシグネを対象に実験を行った．

•

バージョンが Git リポジトリにおいてタグで示されている．

•

バージョンがセマンティックバージョニングの形式（X.Y .Z ）である．Z は省略されていても可とし，その場合は Z = 0 として取り扱った．

•

バージョン 1.0.0 以上のリリースがある（ベータ版や Release Candidate 版を除く）．

•

複数回リリースされている（ベータ版や Release

Candidate 版を除く）．
実験対象としたライブラリの名称とそのバージョンを
図4734

Git リポジトリ（左）を変換した Historage リポジ
トリ（右）表 1 に示す．
実験対象として Apache Commons プロジェクトを

論文／メソッドレベルセマンティックバージョニングの提案と評価
表1

実験対象のライブラリとそのバージョン．ライブラ
リ名は「Apache Commons」を省略して表記している．

ライブラリ名BCEL
BeanUtils
Chain
CLI
Codec
Collections
Compress
Configuration
CSV
DBCP
DbUtils
Digester
Email
Exec
FileUpload
IO
JCI
Jelly
JEXL
JXPathLang
Logging
Math
Net
Text
Validator
VFS
Weaverバージョン
5.0.0 (2001/12/15)〜6.2.0 (2017/12/09)
1.0.0 (2001/07/14)〜1.9.3 (2016/09/26)
1.0.0 (2004/12/09)〜1.2.0 (2008/06/02)
1.0.0 (2002/11/06)〜1.4.0 (2017/03/09)
1.5.0 (2011/03/29)〜1.11.0 (2017/10/20)
1.0.0 (2007/07/29)〜4.1.0 (2015/11/28)
1.0.0 (2009/05/21)〜1.13.0 (2016/12/29)
1.0.0 (2004/10/11)〜2.2.0 (2017/10/12)
1.0.0 (2014/08/14)〜1.5.0 (2017/09/03)
1.0.0 (2002/08/12)〜2.2.0 (2017/12/27)
1.0.0 (2003/11/10)〜1.7.0 (2017/07/20)
1.0.0 (2007/07/29)〜3.2.0 (2011/12/13)
1.0.0 (2005/09/27)〜1.5.0 (2017/08/01)
1.0.0 (2009/03/15)〜1.3.0 (2014/11/06)
1.1.0 (2005/12/24)〜1.3.3 (2017/06/13)
1.0.0 (2004/05/08)〜2.5.0 (2016/04/22)
1.0.0 (2013/03/03)〜1.1.0 (2013/10/14)
1.0.0 (2005/06/12)〜1.0.1 (2017/09/25)
1.0.0 (2004/09/07)〜3.1.0 (2017/04/14)
1.0.0 (2007/07/29)〜1.3.0 (2008/08/14)
1.0.0 (2002/10/04)〜3.7.0 (2017/11/04)
1.0.3 (2003/04/07)〜1.2.0 (2014/07/11)
1.0.0 (2004/12/06)〜3.6.1 (2016/03/21)
1.0.0 (2003/02/23)〜3.6.0 (2017/02/15)
1.0.0 (2017/03/04)〜1.2.0 (2017/12/12)
1.3.0 (2006/03/24)〜1.6.0 (2017/02/21)
1.0.0 (2007/07/29)〜2.2.0 (2017/10/06)
1.0.0 (2014/03/16)〜1.3.0 (2016/10/18)

選択したのは，プロジェクトの Web サイト [15] において，セマンティックバージョニングに相当するガイ

表2

リリースの種別と後方互換性のないリリースの割合
メジャーリリース
マイナーリリース
パッチリリース

# all
19
163
65

# incomp
19
131
17

割合
100.0%
80.4%
26.2%

図5

マイナーリリースに含まれていた後方互換性のない
変更の例

図6

パッチリリースに含まれていた後方互換性のない変更の例

ドラインが制定されているためである．なお，ApacheCommons BCEL など一部のライブラリではパッチリを含むリリースの個数（# incomp）を，メジャーリ

リースが行われていないが，本実験は後方互換性の有

リース，マイナーリリース，パッチリリースに分けて無を調べるものであるため，パッチリリースの有無は集計したものを表 2 にまとめる．本来は後方互換性

本質でないと考える．そのため，パッチリリースのあのあるはずであるマイナーリリースのうち 8 割以上，るライブラリとないライブラリを区別なく取り扱うこ

パッチリリースのうち 2 割以上には，実際には後方互とによる実験結果への影響はない．

換性のない変更が行われたメソッドが含まれているこ

5. 2 実験 1：誤ったバージョニングの検出とが分かった．また，本来後方互換性のないはずであ

実験対象のライブラリに対して提案ツールを実行し，るメジャーリリースには全て後方互換性のない変更が各リリースにおいて変更された public メソッドの後一つ以上含まれており，マイナーリリースやパッチリ

方互換性の有無を調査した．提案手法及び提案ツール

リースで十分なリリースがメジャーリリースとされてではコミット単位でバージョニングを行っている．そいるような例はなかった．

のため本実験では，リリースのバージョンを示すタグ

提案ツールが検出した後方互換性のない変更の例をが付けられたコミットと，そのバージョンのリリース

図 5 及び図 6 に示す．図 5 はマイナーリリース，図 6

を 1 対 1 に対応付け，リリース間のバージョンをメはパッチリリースに含まれていた後方互換性のない変更

ソッドごとに比較することでリリース間の後方互換性の例である．図 5 では，Apache Commons BCEL 5.1を判定した．

から 5.2 へのマイナーリリースにおいて，ArrayType

リリースの総数（# all）と後方互換性のない変更

クラスの hashcode() メソッドが hashCode() に改名
735電子情報通信学会論文誌 2019/11 Vol. J102–D No. 11

されている．また，図 6 では，Apache Commons IOと funcA(int, int, ﬂoat) の相違度は 1,000×2 = 2,000

1.3.1 から 1.3.2 へのパッチリリースにおいて，File-

であり，funcA(int, ﬂoat) と funcA(int, int) の相違度

Cleaner クラスのインナークラス Tracker の delete()

は 1 である．

メソッドが FileCleaningTracker クラスに移動されている．
このように，Apache Commons プロジェクトには実験の結果，次のような変更についての出力結果が提案ツールと Clirr で異なっていた．

a. メソッドの引数リストの変更

バージョニングのガイドラインが定められているにも

b. メソッドの属するパッケージ名の変更かかわらず，後方互換性のない変更を含んでいる場合

c. 複数のメソッドの追加と削除にマイナーリリースやパッチリリースとした場合があ

各変更の件数を表 3 に示す．それぞれについて，実際ることが分かった．

の検出例を説明する．

後方互換性のあるはずであるマイナーリリースや

a. メソッドの引数リストの変更

パッチリリースに後方互換性のない変更が含まれていApache Commons IO 2.0 において，SizeFileCom-

る場合，そのライブラリの利用者がライブラリをアッparator クラスの compare(Object, Object) メソッド

プデートした際に不具合が発生することが予想される．

の引数が変更されて compare(File, File) メソッドにそこで，本実験で検出されたメソッドが実際に使用さなったと提案ツールが出力した．一方，Clirr はこの変れている例を GitHub のキーワード検索を用いて調べ

更に関して，compare(File, File) メソッドが追加された．その結果，検出されたどのメソッドもライブラリたという情報のみを出力しており，compare(Object,

外から使用しているソフトウェアは見つからなかった．

Object) メソッドが削除されたということは出力されこの原因としては，検出されたメソッドが API としていなかった．

て外部から利用されることを想定したメソッドではな

b. メソッドの属するパッケージ名の変更

い，あるいは需要の少ないメソッドであったため，使Apache Commons DBCP 2.0 に お い て ，org.

用例がないと考えられる．

apache.commons.dbcp パッケ ー ジ が org.apache.

5. 3 実験 2：既存手法との比較

commons.dbcp2 に改称された．このリリースに関し

実験 1 で提案ツールが検出した後方互換性のないリて提案ツールは org.apache.commons.dbcp パッケー

リースに対して Clirr を適用し，提案ツールの出力結ジに含まれるメソッドが org.apache.commons.dbcp2

果と Clirr の出力結果を目視によって比較した．

というパッケージに移動したという出力を行っていた．

Clirr は ，新 旧 二 つ の バ ー ジョン の JAR（Java一方 Clirr の出力は，org.apache.commons.dbcp パッ

Archive）ファイルを入力にとり，それらのバージョ

ケージに含まれるクラスが削除されたという情報と，ン間で後方互換性のない変更を以下の手順で検出する

org.apache.commons.dbcp2 パッケージにクラスが追ツールである．

加されたという情報に分かれていた．

（ 1 ） 新バージョンで削除されたメソッドと追加さ

c. 複数のメソッドの追加と削除れたメソッドの全ての組み合わせに対して相違度を計

Apache Commons IO 2.5 において，ByteArray-（ 2 ） 最も相違度の小さいメソッドの組が対応する

InputStream クラスに以下のような変更があった．
• toBuﬀeredInputStream(InputStream, int) メ

メソッドとし，引数の個数・引数の型・返り値の型のソッドが追加算する．

いずれかが異なっているかアクセス修飾子が狭まって•

toBuﬀeredInputStream() メソッドが削除いる場合に後方互換性がないと判定する．

•

toInputStream() メソッドが追加（ 3 ） (2) で処理したメソッドを除き，削除された

提案ツールはこれを以下のような変更として出力

メソッドか追加されたメソッドがなくなるまで (1) かした．

ら (3) を繰り返す．
上記の (1) における相違度は，メソッドが取る引数の個数に差がある場合は個数の差の絶対値を 1,000 倍した値であり，引数の個数に差がない場合は異なっている引数の型の数である [16]．例えば，メソッド funcA(int)736

表 3 提案ツールと Clirr で出力結果が異なっていた変更
変更内容
a. メソッドの引数リストの変更
b. メソッドの属するパッケージ名の変更
c. 複数のメソッドの追加と削除

件数
293
65
1

論文／メソッドレベルセマンティックバージョニングの提案と評価•

toBuﬀeredInputStream(InputStream, int) メ

ソッドが追加•toBuﬀeredInputStream() メソッドが toInput-

Stream() に改名
一方，Clirr は以下のように出力した．

•

toBuﬀeredInputStream() メ ソッド の 引 数 が追加•

クラスに含まれる public メソッドは全てライブラリ
外部から呼び出すことができ，API を開発者が指定することができない．そのため，API が含まれるクラスだけでなく，あるパッケージに定義されているクラス
を別のパッケージから参照したい場合も，そのクラス
を public とする必要がある．したがって，そのクラスが内部処理のためだけのものであったとしても，そtoInputStream() メソッドが追加

れに定義されている public メソッドは本実験の対象

Clirr はメソッドの削除と追加，及び引数リストに含まれている．すなわち，本実験で API としたメの変化などを検出でき，これらのパターンに基づいソッドには，開発者が API とは想定していないメソッて変更内容を出力する．一方，提案ツールはメソッドが含まれている可能性がある．それらのメソッドを

ド本体の一致率が大きいものを同じメソッドである

特定して実験対象から除いた場合，実験結果が変化すと判断し，シグネチャが変わっている場合は改名さる可能性がある．

れたり引数リストが変更されたりしたものであると

6. 3 メソッドの後方互換性

いう出力を行う．実際，メソッド toBuﬀeredInput-

提案ツールでは，ライブラリの利用者がライブラリ

Stream() と toInputStream() の本体は，toBuﬀered-のバージョンを上げた際にソースコードの修正を行う

InputStream(InputStream, int) よりも一致割合がことなく同じメソッドを使い続けられる場合に，その大きかった．そのため，toBuﬀeredInputStream() とメソッドに後方互換性があるとしてバージョニングを

toInputStream() が同じメソッドであり，前者の名称行っている．しかし，メソッドのシグネチャが同じでが後者に変更されたという出力になったと考えられる．

も，メソッドの中身が変更されたことでそのメソッド

この結果から，提案ツールはメソッド名の変更を検の入力に対する出力が変化した場合も，後方互換性が出することができるといえる．これにより，ライブラないと考えられる．提案ツールではメソッドのシグネ

リのバージョンアップによってメソッド名が変更されチャの変化のみをもって後方互換性の有無を判断してた場合に，ライブラリの利用者が提案ツールの出力結いるため，メソッドの入出力の変化に関しては考慮し果を利用して改名されたメソッドの呼び出し元を一括ていない．より正確に後方互換性の有無を判別するた

置換することができるようになる．これはライブラリ

めには，メソッドの入出力が変化していないかどうか

アップデートへの対応を省力化できると考えられ，そを解析する必要がある．

の点において提案ツールは Clirr よりも優れていると考える．

6. 妥当性への脅威

また，あるコミット c1 で後方互換性のない変更が行われ，その後に別のコミット c2 で c1 を適用する前（c0 とする）と後方互換性のある状態に戻される場合が考えられる．しかしながら，提案手法及び提案ツー6. 1 実験対象の選択

ルではコミットごとにメソッドの後方互換性を判別し本研究では実験 2 を実験 1 に続いて行ったため，どバージョニングを行っているため，このような場合はちらも Apache Commons プロジェクトのライブラリ

c1 ，c2 のそれぞれでメジャーバージョンが一つ増える．

を用いて実験した．Apache Commons プロジェクト

したがって，このメソッドの c0 -c2 間における後方互を実験対象としたのは，実験 1 においてセマンティッ

換性をバージョンから判断すると誤りとなる．本研究クバージョニングを採用しているという前提が必要ででは，このような場合を考慮するとバージョンの決定あったためである．しかし，実験 2 についてはセマンが困難となるため，上述のような扱いになっている．

ティックバージョニングの制約は必要でない．実験 2

6. 4 「バグ修正コミット」の定義

を他のライブラリで実験した場合に異なる実験結果が提案ツールでは，後方互換性のある変更をマイナー得られる可能性がある．

レベルとパッチレベルに分類するために，変更が行わ

6. 2 public メソッドと API の関係

れたコミットのコミットメッセージに特定の文字列が本実験では，public クラスに含まれる public メ

含まれているかどうかによって，その変更がバグ修正

ソッドを全て API とみなした．Java 言語では，publicのためのものであるかどうかを判断した．本研究では737

電子情報通信学会論文誌 2019/11 Vol. J102–D No. 11

後方互換性の有無を議論の焦点としたため，また，正

cies?,” Empirical Software Engineering, vol.23, no.1,
pp.384–417, Feb. 2018.

確にバグ修正であるかどうかを判断することは困難であるとの考えからこのような実装とした．しかし，バ
グ修正が行われたコミットのコミットメッセージに特[5]

MvnRepository, “Maven repository,” Jan. 2018.

[6]

C. Decker, “Releasepolicy - google/guava wiki,”https://mvnrepository.com/

定の単語が含まれていることを前提とすることの是非

Google, Sept. 2017. https://github.com/google/
guava/wiki/ReleasePolicyについては議論の余地があると考えられる．

7. む す び[7]

Checkstyle, “Checkstyle,” Oct. 2018.

[8]

JUnit Team, “JUnit,” Sept. 2018. https://junit.org/[9]

J. Gosling, B. Joy, G.L. Steele, G. Bracha, and A.

http://checkstyle.sourceforge.net

本研究では，メソッドレベルセマンティックバージョ

Buckley, The Java Language Specification, Java SE 8

ニングを提案し，それを Java 言語のメソッドに適用するツールを作成した．また，作成したツールを Apache

Edition, 1st ed., Addison-Wesley Professional, 2014.
[10]

Eclipse Foundation, “JGit,” Oct. 2018.

[11]

S. Chacon and B. Straub, Pro git, Apress, 2014.

[12]

K. Fujiwara, H. Hata, E. Makihara, Y. Fujihara, N.

Commons プロジェクトの 28 ライブラリに対して使用することで，後方互換性のあるはずであるリリースに含まれていた後方互換性のない変更を検出すること

http://www.eclipse.org/jgit/

Nakayama, H. Iida, and K. Matsumoto, “Kataribe: Aができた．更に，既存ツールである Clirr の出力結果

hosting service of historage repositories,” Proc. 11thと比較を行うことにより，Clirr が検出できない変更を

Working Conference on Mining Software Repositories, pp.380–383, New York, USA, 2014.

提案ツールを用いることで検出できることが分かった．
提案ツールはシグネチャや返り値の型が変更された
場合に後方互換性がないと判断してバージョニングを[13]

K. Fujiwara, “niyaton/kenja: Kenja repository,” Dec.

[14]

H. Hata, O. Mizuno, and T. Kikuno, “Historage:

2017. https://github.com/niyaton/kenja

行っている．しかし，より正確には，型（クラス）の

Fine-grained version control system for java,” Proc.

継承関係やメソッドの返り値自体の変化，更には副作

12th International Workshop on Principles of Software Evolution and the 7th Annual ERCIM Work-用なども考慮する必要があると考えられ，これらを考shop on Software Evolution, pp.96–100, IWPSE-

慮することによって後方互換性の有無をより正確に判定できるようにしたいと考えている．

EVOL ’11, ACM, New York, NY, USA, 2011.
[15]

Versioning Guidelines,” Oct. 2018. https://commons.

本研究では，提案ツールと Clirr の比較を行った．しかし，API の変更を検出することができるツールは他にApache Software Foundation, “Apache Commons –apache.org/releases/versioning.html[16]

L. Kühne, “clirr/MethodSetCheck.java at master -も存在し，例えば Moreno らが開発した ARENA [17]ebourg/clirr,” Sept. 2005. https://github.com/というツールがある．ARENA は検出した API の変

ebourg/clirr/blob/master/core/src/java/net/sf/

更をリリースノートとして出力する Web アプリケー

clirr/core/internal/checks/MethodSetCheck.java[17]

L. Moreno, G. Bavota, M.D. Penta, R. Oliveto, A.

ションである．ARENA はメソッド名の変更を追跡す

Marcus, and G. Canfora, “Arena: An approach for

ることが可能であり，提案ツールとメソッドの追跡精

the automated generation of release notes,” IEEE

度や出力に要する時間などを比較したいと考えている．

Trans. Softw. Eng., vol.43, no.2, pp.106–127, Feb.

謝辞 本研究は，科学研究費補助金基盤研究（B）（課題番号：17H01725）の助成を得て行われた．
文
[1]

献

T. Preston-Werner, “Semantic versioning 2.0.0,”
June 2013. https://semver.org/spec/v2.0.0.html[2]

L. Kühne, “Clirr,” Sept. 2005.

[3]

S. Raemaekers, A. van Deursen, and J. Visser, “Se-

http://clirr.sourceforge.net
mantic versioning versus breaking changes: A studyof the maven repository,” 2014 IEEE 14th International Working Conference on Source Code Analysis
and Manipulation, pp.215–224, Sept. 2014.
[4]

R.G. Kula, D.M. German, A. Ouni, T. Ishio, and K.
Inoue, “Do developers update their library dependen-

738

2017.
[18]

藤原賢二，吉田則裕，飯田 元，“構文情報リポジトリを用” 情処学論，vol.56,
いた細粒度リファクタリング検出手法，
no.12, pp.2346–2357, Dec. 2015.
（2018 年 11 月 27 日受付，2019 年 4 月 24 日再受付，
7 月 12 日早期公開）

論文／メソッドレベルセマンティックバージョニングの提案と評価

林純一

平成 30 年大阪大学基礎工学部情報科学科卒業．同年より同大学大学院情報科学研
究科コンピュータサイエンス専攻博士前期課程在学中．

肥後

芳樹

（正員）

2002 年大阪大学基礎工学部情報科学科中退．2006 年同大学大学院博士後期課程修了．2007 年同大学院情報科学研究科コンピュータサイエンス専攻助教．2015 年

同准教授．博士（情報科学）．ソースコー
ド分析，特にコードクローン分析やリファ
クタリング支援に関する研究に従事．日本ソフトウェア科学会，
IEEE 各会員．

楠本

真二

（正員）

昭和 63 年大阪大学基礎工学部情報工学科卒業．平成 3 年同大学大学院博士課程中退．同年同大学基礎工学部助手．平成 8 年
同講師．平成 11 年同助教授．平成 14 年
同大学大学院情報科学研究科助教授．平成17 年同教授．博士（工学）．ソフトウェアの生産性や品質の定量的評価，プロジェクト管理に関する研究に従事．IPSJ，IEICE，JSSST，IEEE，JFPUG，PM 学会，
SEA 各会員．

739