1
日本ソフトウェア科学会第 31 回大会 (2014 年度) 講演論文集

RepositoryProbe: リポジトリマイニングのためのデータセット作成支援ツール
高澤 亮平 坂本 一憲 鷲崎 弘宜 深澤 良彰
ソフトウェアの成果物を対象に分析を行うリポジトリマイニングの研究が盛んに行われている．しかし，数多くの公開されているプロジェクトから，分析の対象とする規模，言語，用途などを満たすプロジェクトを探すことは困難な作業である．そこで我々は，リポジトリマイニングのためのデータセット作成支援ツール RepositoryProbe を提案する．プロジェクト共有ウェブサービス上で特定の条件を指定して検索を行うことで，目的のプロジェクト群を容易に見つけ出すことが可能となり，データセットの構築を支援する．また，ウェブサービス上の開発活動に関するデータを取得することで，オープンソースにおける開発に関するデータの収集も行うことができる．

The studies of Repository Mining have been actively conducted. However, it is diﬃcult to search projects
with specified languages, development scale, purposes and so on. In this paper, we propose RepositoryProbe,
a dataset creation support tool fot the study of repository mining. It makes easier to search and collect theprojects in project hosting service on the web, and supports the creation of datasets. In addition, it cancollect the social metrics, the amount of development activities.

を対象としたリポジトリマイニングの研究も数多く

1 はじめに存在する．OSS とは，ソースコード等の成果物を誰

リポジトリマイニングとは，ソフトウェアのソーでも改変，再頒布を可能としているソフトウェアのスコード，開発ログなどの成果物を対象として分析総称である．Web 上にプロジェクトのリポジトリをを行い，ソフトウェア開発における有益な知見をおく，リポジトリスティングサービスの普及に伴い，導き出す研究分野であり，ソフトウェア工学分野のOSS プロジェクトの数も増加傾向にある [1]．

国際会議である ICSE (International Conference onSoftware Engineering) †1 において MSR (Working

べてソースコード等の入手が容易であることから，取Conference on Mining Software Repositories) †2 がり組みやすいことが特色である．しかしながら，OSS併設されているなど，近年高い関心を集めている分野を対象とした大規模なリポジトリマイニングの実例である．

は少ない．一つの要因として，分析の対象とするプロ

OSS を対象とした研究は，商用ソフトウェアに比企業が自社の商用ソフトウェアを分析する例のみジェクトの検索が困難であるという問題がある．商用

ならず，オープンソースソフトウェア（以下，OSS）ソフトウェアに比べ，ソフトウェアの用途，開発の規RepositoryProbe: Dataset Creation Support Tool forRepository Mining
Ryohei Takasawa, Hironori Washizaki, Yoshiakifukazawa, 早稲田大学基幹理工学研究科情報理工学専攻, Dept. of Computer Science and Engineering,Waseda University.
Kazunori Sakamoto, 国立情報学研究所, National Institute of Informatics.
†1 http://www.icse-conferences.org/†2 http://2014.msrconf.org/

模や期間などを各自で調べる必要がある上，それらを個別に収集，分析することは非常に時間的コストが大
きい．
また，リポジトリマイニングは単にソースコードの解析だけでなく，様々な観点から行われることが一般的である．Schryen [3] らは，コードを公開しないクローズドソースソフトウェアと OSS を脆弱性の観点から比較し，新たなメトリクスを提案することで定量的な評価を行っている．また，Hars [2] らは，開発者が OSS に参加する要因を，内的要因と外的要因に分類し，モチベーションに着目することで分析している． このように，リポジトリマイニングを行う際には幅広いデータが必要となってきており，ただプロジェクトの成果物のみを複製するだけのツールでは十分とは言えない．

ryProbe を開発した点．
2. 収集したプロジェクトに対し，他の測定ツールと連携して測定が可能である点．

3. RepositoryProbe を用いて実際にデータを取り，研究に利用した実例がある点．

RepositoryProbe はプロジェクトホスティングサー
ビスの一つである GitHub †3 上でプロジェクトの検

我々は過去の研究で，リポジトリのテストの成否索を行う．利用者は，実行時にキーワードを指定するに対して，相関性のあるメトリクスを明らかにした．

ことで，対象となる OSS プロジェクトを GitHub 上

その際，GitHub から 750 件以上のリポジトリを収集から検索し，プロジェクトの各種情報を CSV ファイして，各リポジトリからテストの成否とソースコールへ出力する．

かし，GitHub の API では，機能 1) 特定のファイル

RepositoryProbe は Xtend 言語 †4 で開発している．Xtend 言語は Eclipse Foundation †5 によって開を含むリポジトリを検索する機能，機能 2) 特定の検発されているプログラミング言語であり，コンパイル索クエリに対して 1001 件以上の検索結果を取得するすることで Java によるコードに変換され，Java 仮想機能，機能 3) ソーシャルメトリクスの issues およびマシン上で動作する．また，RepositoryProbe 自体

pull requests の数を取得する機能，機能 4) ソース

もオープンソースソフトウェアとして GitHub 上で公開中である †6 ．

ドメトリクス，ソーシャルメトリクスを測定した．しコードメトリクスを取得する機能を提供しておらず，研究の実施にあたり，これらの機能を提供する Javaプログラム群を開発した．我々は同様のリポジトリマ

2 GitHub 上での検索イニングを行う際，機能 1-4 が広く必要な機能である

RepositoryProbe は GitHub 上の OSS プロジェクと考えた．
そこで，本論文では機能 1-4 を満たすリポジトリマイニングツール RepositoryProbe を提案する．

RepositoryProbe は GitHub の標準的なリポジトリ検索機能に加えて，コード検索機能を応用した特定のファイルを含むリポジトリを検索する機能を提供する（機能 1）．また，コード検索機能を利用する場合，検トを対象に，キーワードを用いた検索を行う．GitHubは開発者向けの API †7 を公開しているが，現状のでは対処することができない問題が 2 つ存在する．

1. 特定のファイルを含むリポジトリを検索できない

2. 特定の検索クエリに対して 1001 件以上の検索結果を取得ことができない

索結果の最大数の 1000 件を超えて検索結果の取得に

RepositoryProbe で は こ れ ら の 問 題 に 対 し ，対応する（機能 2）．得られたリポジトリの一覧に対し

GitHub の API を利用することなく，検索結果とて，それぞれソーシャルメトリクスおよびソースコーなる URL を直接生成してウェブスクレイピングを行ドメトリクスを測定（機能 3-4）して，その結果をうことにより，情報の収集を試みている．

CSV ファイルに出力する．現在，RepositoryProbe
は OSS として開発しており，新しいメトリクスの測定機能を追加すれば，検索機能によって得られた各リポジトリに対して，新たにメトリクスを測定することができる．
本論文の主要な貢献点は以下のとおりである．

1. OSS プロジェクトの収集，およびメトリクス測定とデータ出力を自動化するツール Reposito-

トの作成時期，最終更新時期など，通常の検索に比べより細かい条件の指定が可能である．
また，RepositoryProbe ではコード，プロジェクトの検索に対応するクラス CodeSearchQuery, Reposi-torSearchQuery を用意し，それぞれの検索結果に対応をもたせることを可能にしている．表示された検索結果は，ブラウザ操作自動化ツールである Selenium†9 を用いてクローリングする．

2. 2 検索結果の取得
図1

GitHub ではプロジェクトの検索を行った際に，1000コード検索の結果件を超えるプロジェクトを表示することができないという制約がある．この制約は，実際に Web ブラウザを使用して検索を行った場合も解消することができない．

RepositoryProbe では，すべての検索結果を一度に取得するのではなく，対象とするファイルサイズを分割し，複数回に分けて検索を試みることですべての対象となるプロジェクトの情報を収集する．GitHub のAdvanced Search では，ファイルのサイズを指定して検索を行うことができるため，検索結果数が 1000件を超えないサイズを探し，そこまでのプロジェク
図2

トに関してデータの取得を行う．次回の検索はそのサリポジトリ検索の結果イズから開始することで，実質的には 1000 件以上の2. 1 特定のファイルを含むリポジトリの検索プロジェクトの取得が可能となる．RepositoryProbe

GitHub の API では，リポジトリ内に特定のファではこのサイズ選定を自動で行うことで，検索の最適イルが存在するか，などといった複合した条件の検索化を行っている．リスト 1 に，クエリのサイズ調整を行うことができない．これは，図 1 と図 2 に示すを行う部分のソースコードを示す．

ように，特定のキーワードで検索した場合の結果がリ
1

ポジトリ単位とファイル単位とで独立に得られ，それぞれの対応が取れていないことに起因する．

RepositoryProbe では，GitHub の Web サイトに用意されている Advanced Search †8 を利用し，詳細な検索結果を取得する．Advanced Search では，プ

def g e t S e a r c h R e s u l t C o u n t () {queries . map [23val elems = g e t C o u n t e r O f S e a r c h R e s u l t E l e m e n t s ( it )4if ( elems . length > 0) {elems . get (0). extra ctInte ger5} else {607}8

ロジェクトに含まれるファイルの名前や，プロジェク
†3
†4
†5
†6
†7
†8

http://github.com/
http://www.eclipse.org/xtend/
http://www.eclipse.org/org/foundation/
https://github.com/exKAZUu/RepositoryProbe/https://developer.github.com/v3/
https://github.com/search/advanced/]. fold (0 , [l , r | l + r ])910}

List 1

クエリのサイズ調整部†9 http://docs.seleniumhq.org/

表1

GitHub 上の主なソーシャルメトリクス

ジェクトページは，検索時に取得したプロジェクト

watch

プロジェクトへの関心を表す

名:projectName，プロジェクトのオーナーであるユー

star「お気に入り」を表す

ザー名:userName を用いて，以下の URL によって定fork

貢献の意思表示を表す

義される．

issue

バグ報告，コメントなどhttps://github.com/userName/projectName/pull requests

プロジェクトへの変更依頼

watch や star などの値はプロジェクトページに直contributors

開発に関わる人数接表示されているため，検索時と同様に Selenium を用いてクローリングを行う．ただし，watch の値はGitHub にログイン時でないと表示することができ

3 ソーシャルメトリクスの測定ないため，RepositoryProbe ではプロパティファイル

GitHub はバージョン管理システムを利用しており，を用いてログインをサポートしている．具体的には，複数の開発者による協調分散開発が可能なプラット

secret.properties ファイルにログイン ID とパスフォームである．また，Social Coding というキャッワードを記述しておくことで，ログインと同様の情報チフレーズを掲げているように，プロジェクトの成果量を得ることが可能である．また，GitHub 上で検索物を公開し，開発者間で意見交換などを行いながら開を行う場合も，ログイン時の方が比較的速く結果が得発を進めていくのが一般的である．

られるという利点もある．

本論文では，プロジェクトの活動量表す値をソー

closed pull requests の数は，プロジェクトページシャルメトリクスと命名する．ソーシャルメトリクス

上に表示されておらず，GitHub の API でもサポートは，プロジェクトにおける開発者の貢献やモチベーされていない．GitHub の API では各 pull requests

ションに関わることが先行研究から明らかとなっての状態は取得できるものの，すべての状態の取得は時おり，今後の研究，分析に有用な値であると考えら間的コストが大きい．

RepositoryProbe では，closed pull requests のペーれる．

ジに直接アクセスし，総ページ数と末尾のベー字に表示される要素の数を用いて計算している．これにより，GitHub の API ではサポートされていないメトリクスに関しても収集が可能となる．

4 ソフトウェアメトリクスの測定
ソフトウェアメトリクスの測定には，フリーの品質管理プラットフォームである SonarQube †10 を用いる．SonarQube の実行結果の例を 4 に示す．また，SonarQube によって測定可能である代表的なメトリ
図3

プロジェクトページの一例

クスを 2 に示す． 2 に示す以外にも，SonarQube では多数のメトリクスが測定可能であり †11 ，プラグインを導入することで容易に測定対象の拡張が可能でRepositoryProbe によって取得可能な主なソーシャ
ルメトリクスを表 1 に示す．これらのソーシャルメトある．

SonarQube はサーバクライアントモデルを採用しリクスはプロジェクトページに表示され，開発者でなくても閲覧可能である．例として，RepositoryProbeのプロジェクトページを 3 に示す．GitHub のプロ†10 http://www.sonarqube.org/†11 http://docs.codehaus.org/display/SONAR/Metric+definitions/5. 1 実験概要
ソフトウェアテスティングは，ソフトウェアの品質を担保するうえで重要な工程であるが，OSS におけるテストの調査は限定的であり，OSS の開発においてテストの問題が明らかになっていない．そこで筆者
らは，OSS 開発におけるテストの現状を把握することを目的に，リポジトリマイニングを通して分析を行った．
図4

SonarQube 実行結果の一例

RepositoryProbe で検索、収集の対象とした OSSは以下の通りである．

表2

SonarQube によって測定される主なメトリクス

1. Java 言語を使用している
2. Maven を利用しており，設定ファイル pom.xml

lines of code

コード行数

complexity

複雑度

comment ratio

ソースコード中のコメント率

issue

静的解析による問題点の指摘

line coverage

テストのカバー率

unit test success

テストケースの成功率が存在している
上記の条件を満たす GitHub 上のプロジェクトを対象に，SonarQube を用いてメトリクスを測定を行い，データの分析を行った．

5. 2 実験結果
データの取得にはマシン 1 台を用い，Reposito-ており，プロジェクト管理ツールの Maven †12 を通ryProbe を 4 日間動作させることで，GitHub からしてクライアント側で実行することで，サーバ上で静791 プロジェクトを収集することができた．また，的解析とメトリクス測定を行う．SonarQube の結果

SonarQube からの情報の取得も行っており，取得しはブラウザ上で閲覧可能なため，Selenium を用いてたプロジェクトすべてでテスト実行を試行した．そのクローリングを行い，データとして出力する．以上の結果，全プロジェクトのうち 452 プロジェクトでテ

ように，RepositoryProbe では検索，複製したプロスト実行がなされ，残りのプロジェクトではビルドがジェクト群に対し外部ツールと連携した測定が可能で失敗する，もしくはエラーが発生し実行ができないとあり，測定結果はプロジェクト名と紐付けされた形でいう結果が得られた．

CSV ファイルへの出力が可能である．

次に，SonarQube を用いてメトリクス測定を試行した．SonarQube が実行され，テストコードが存在

5 RepositoryProbe の利用例していた 176 プロジェクトからのメトリクス測定を

本節では，RepositoryProbe の利用した研究の例行うことができた．表 5. 2 に，プロジェクトをテストとして，テストコードに着目したマイニングと分析の成功，失敗の 2 群に分けた場合の，各種メトリクの結果を示す．なお，以下で示す実験データに加え，ス値の平均値などの分析の結果を示す．どのメトリク筆者らはこれまでにも RepositoryProbe を利用した

ス値においても，成功の方が失敗より高い平均値をと研究を行っている [9]．

り，統計的に有意な差であるという結果が得られた．
以上の実験から，RepositoryProbe を利用することで分析に耐えうるデータを取得することができ，ツールの利用者は逐次操作する必要なく，条件を指定するだけで必要となるデータセットを得ることができるこ†12 http://maven.apache.org/とが確認できた．

表3

メトリクス測定の結果

Comment Density

Documented API Density

Line Coverage

Branch Coverage

Success

FailureSuccess

FailureSuccess

FailureSuccessFailure

平均値

18.9%

10.8%

52.4%

35.0%

50.5%

31.0%

43.6%

23.2%

分散

0.01020.01000.0957

0.103

0.107

0.07040.09180.0727p値

0.00121 (< 0.05)

0.0223 (< 0.05)

0.0170 (< 0.05)

0.00769 (< 0.05)

く感謝いたします．

6 まとめと今後の展望
本論文では，Web 上の OSS プロジェクトの検索，メトリクス測定を自動化するツール RepositoryProbe

参 考 文 献を提案した．また，実際にデータ収集と分析を行い，[ 1 ] Amit Deshpande, Dirk Riehle: The Total
Grouwth of Open Source, IFIP Advances in Information and Communication Technology, Vol. 275(2008), pp. 197–209.
[ 2 ] Alexander Hars, Shaosong Ou: Working forFree? -Motivations of Participating in Open Source
Projects, International Journal of Electronic commerce, Vol. 6 (2002), pp. 25–69.
[ 3 ] Guido Schryen, Rouven Kadura: Open source
vs.closed source software: towards measurring security, In Proc. of the 24th Annual SCM Symposium
on Applied Computing (2009), pp. 2016–2013.
[ 4 ] Gordon Fraser, Andrea Aruri: Sound Empirical
Evidence in Software Testing, In Proc. of the 34thInternational Conference on Software Engineering(2012), pp. 178-188.
[ 5 ] Raphael Pham, Lief Singer, Olga Liskin, Fernando Figueira Filho, Kurt Schneider: Creatinga Shared Understanding of Testing Culture on aSocial Coding Site. In Proc. of the 35th International Conference on Software Engineering (2013),pp. 112–121.
[ 6 ] Wilson, James Q., and George L. Kelling: Broken windows. Atlantic monthly 249.3 29–38 (1982).
[ 7 ] Oliver Arafat, Dirk Riehle: The Commenting
Practice of Open Source. In Proc. of the 24th ACM
SIGPLAN conference companion on Object oriented programming systems languages and applications (2009), pp. 857–864.
[ 8 ] Paulo Meirelles, Carlos Santos Jr., Joao Miranda, Fabio Kon, Antonio Terceiro, ChristinaChavez: A Study of the Relationsships between
Source Code metrics and Attractiveness in Free
Software Projects, In Proc. of the 24th Brazilian
Symposium on Software Engineering (2010), pp. 10–20.
[ 9 ] 高澤亮平，坂本一憲，鷲崎弘憲，深澤良彰:メトリ
クス測定に基づくオープンソースプロジェクトにおける実証的研究, ソフトウェア工学の基礎 XX (2013),
pp. 197–202.

実験者の操作の必要なしに実時間内に動作すること，一定の規模のデータの取得が行えることなど，ツールの有用性を確認した．
データセット構築のためのツール RepositoryProbeを提案した．今後の展望として，以下の 2 点があげられる．

1. 分散処理への対応
評価でも述べた通り，リポジトリの複製やテスト実行は回線の状況や対象とするプロジェクトによりかかる時間に大きな差が生じる．しかしながら，これらの作業は並列実行が可能であるため，複製済みのプロジェクトのメトリクス測定を行いながら，他のプロジェクトの複製を行うことで，より効率の良いデータ収集が可能となる．

2. Web アプリケーション化
プロジェクトの複製，メトリクス測定をクラウドサーバ上で行うことにより，手元の環境を汚すことなくデータの取得が可能である．OSS の中には実際に動作させた場合に予期せぬ挙動を示すものもあることから，個人のマシンで実行するよりも安全に作業を行える．もちろん，任意のソフトウェアを安全に動作させる環境構築が今後の課題となる．
謝辞
本ツールの開発，並びに評価実験を行うにあたり，数々のご指導をいただいた，奈良先端科学技術大学の伊原彰紀助教，早稲田大学理工学部の本田澄助手に深