deim forum 2013 B8-3

ソフトウェアプロダクト間に存在する Logical Coupling を用いた
変更箇所の推薦
中村

高士†

早瀬

康裕††

北川 博之††† 筑波大学大学院システム情報工学研究科 〒 305–8573 茨城県つくば市天王台 1–1–1†† 筑波大学大学院システム情報系情報工学域 〒 305–8573 茨城県つくば市天王台 1–1–1
E-mail: †tnakamura@kde.cs.tsukuba.ac.jp, ††{hayase,kitagawa}@cs.tsukuba.ac.jp
あらまし ソフトウェア開発において，単一ソフトウェアプロダクト内のモジュール間の関連性を表す指標の一つに，

Logical Coupling という関係が存在する．Logical Coupling は，二つのモジュールが同時に変更されやすいことを表す関係であり，変更すべきモジュールの推薦などに利用できる．一方で，一つのソフトウェアプロダクトの開発に他のソフトウェアプロダクトのモジュールが関連している場合，これらのソフトウェアプロダクト間にも Logical Couplingが存在すると考えられる．この関係を検出することで，複数のソフトウェアに跨った変更すべきモジュールの推薦が可能になる．そこで本稿では，ソフトウェアプロダクト間に存在する Logical Coupling を検出する手法を提案する．
そして，検出された Logical Coupling を用いた変更すべきモジュール推薦の可能性について，予備的検討を行う．
キーワード

Logical Coupling，相関ルール，ソフトウェアリポジトリ

Takashi NAKAMURA† , Yasuhiro HAYASE†† , and Hiroyuki KITAGAWA††† Graduate School of Systems and Information Engineering, University of Tsukuba
1–1–1 Tennodai, Tsukuba, Ibaraki, 305–8573 Japan†† Faculty of Engineering, Information and Systems, University of Tsukuba
1–1–1 Tennodai, Tsukuba, Ibaraki, 305–8573 Japan
E-mail: †tnakamura@kde.cs.tsukuba.ac.jp, ††{hayase,kitagawa}@cs.tsukuba.ac.jp

1. は じ め に
近年，多くのソフトウェアが開発され，様々な場面で利用されている．ソフトウェア開発者は世界中に数多く存在し，ソフ在する．例として，あるプロジェクトが別のプロジェクトで開発されているライブラリを利用しており，途中でライブラリの仕様が変更されてしまった場合に，ライブラリを呼び出す関数側も修正しなければならない場合などが挙げられる．

トウェアの開発を行なっている．最近では，OSS（Open Source

一方，単一ソフトウェアプロダクト内の関連するモジュール

Software）の開発も盛んに行われており，多くの開発者が OSSを見つけるため，モジュール間の結合度を評価する指標である

開発プロジェクトに参加している．OSS 開発プロジェクトの多Logical Coupling が提案されている．Logical Coupling とは，くは，プロジェクトホスティングサービスを利用することで，Gall ら [9] によって提案された指標で，「あるモジュールが変更

プロジェクトに参加する開発者を管理し，ソースコードなどのされた際には，ある別のモジュールも変更されている」というリソースを開発者間で共有しながら開発を行なっている．

モジュール同士の関係を表したものである．Logical Coupling

数多くのソフトウェアが開発され，ソフトウェアの構造も複の利用方法としては，ソースコードの変更漏れの防止や，ソフ

雑になるにつれて，複数のプロジェクトに跨って開発が行われトウェアのモジュラリティを評価することによるソフトウェアる状況も増えてきている．OSS 開発では，一人の開発者が複の構造化などが挙げられる．Logical Coupling の計算をするた

数の OSS 開発プロジェクトに参加していることも珍しくなく，めに必要な，複数のモジュールが同時に変更されたという情報

相互に関連する複数のプロジェクトに参加している開発者もは，ソフトウェアの開発履歴を参照することで取得することが多い [11], [12], [14]．また，あるプロジェクトのリソースに変更できる．Zimmermann ら [13] は，Logical Coupling とそのモを加える際，他のプロジェクトとの関連性が深く，複数のプロ

ジュールの変更内容との関連について調査し，複数のモジュー

ジェクトのリソースを一緒に変更しなければならない場面も存ルが共通の目的で同時に変更されていることを示した．Fluri

ら [8] も同様に，Logical Coupling とそのモジュールの変更内
容に関連があることを確認している．

OSS は他の OSS に依存したり関連した形で開発されているため，モジュール間の Logical Coupling は複数のプロジェク
トに跨って存在しているはずである．しかし，既存の Logical

Coupling の検出手法は単一のリポジトリを対象として検出を行
図 1 バージョン管理システム

うため，異なるプロジェクトのモジュール間に存在する Logical

Coupling の検出を行うことはできない．異なるプロジェクトのモジュール間に存在する Logical Coupling を検出するため

また，VCS では複数箇所への変更を一度のコミットでまとめには，それらのモジュールの変更履歴を確認し，ログに含まれてリポジトリへ格納することができる．この複数箇所への変更

る情報を踏まえた上で，どの変更が同時に行われたものであるをまとめた一連の変更のかたまりを，コミットトランザクショ

かを判別する必要がある．

ンと呼ぶ．一般的に，論理的な繋がりをもった一連の変更を，

また，あるプロジェクトと関連する他のプロジェクトのモ

一つのコミットトランザクションに含めることが推奨される．

ジュールを変更する際，変更が必要なモジュールを特定するの

今日の VCS はコミットトランザクションを明示的に管理しては困難である．複数のソフトウェアプロダクトは独立して開発・いるものがほとんどであり，ログを参照することであるコミッ

保守されており，それらに含まれるモジュール間の繋がりを確

トトランザクションに含まれる一連の変更を確認することもで認することはできないためである．この時，Logical Coupling

きる．

を利用することで，あるモジュールの変更に際して，同時に変2. 2 プロジェクトホスティングサービス

更する必要があるモジュールを推薦することができる．

プロジェクトホスティングサービスとは，VCS によって作らそこで，本稿では異なるソフトウェアプロダクト間に存在すれたソフトウェアリポジトリを複数の開発者で共有して，ソフる Logical Coupling を検出する手法を提案する．まず，複数トウェアの開発を行うためのサービスである．プロジェクトホのプロジェクトのモジュールに対して同時に行われた変更を推

スティングサービスを利用することで，異なる場所にいる複数

定し，Logical Coupling の検出を行う．そして，検出されたの開発者が，共通のソフトウェアの開発に継続的に参加するこ

Logical Coupling を用いてモジュールの推薦を行い，それらモとができるようになる．オープンソースソフトウェア（OSS）開ジュールの間に同時に変更すべき関係が存在するかを確認する．

発では，異なる場所にいる複数の開発者で作業を分担して行う

本稿の構成は以下の通りである．まず，2. 節で本研究に関連必要があるため，プロジェクトホスティングサービスが頻繁にする知識と，ベースとなる Logical Coupling の検出手法につ利用されている．プロジェクトホスティングサービスの代表的いて紹介する．次に，3. 節で提案する Logical Coupling の検な例として，GitHub [2] や SourceForge [3]，Google Code [4]出手法について説明し，4. 節でにそれを用いたモジュールの推や CodePlex [5] などがある．

薦ついて述べる．最後に，5. 節でまとめと今後の課題について述べる．

2. 関 連 知 識

プロジェクトホスティングサービスにホストされたリポジト
リは，一部のプライベートなリポジトリを除いて，ソースコー
ドなどのリソースが公開されている．そのため，ユーザは自由にソースコードを確認したり，リポジトリをダウンロードして

本節では，本研究を説明する上で必要な関連知識について述

ソフトウェアを利用することができる．また，リポジトリに対べる．まず，2. 1 節でバージョン管理システムとその変更履歴かして機能の追加やバグ修正などを施した場合，元のリポジトリら得られる情報について述べた後，2. 3 節で Logical Couplingに対して変更を取り込んでもらえる場合もある．

の検出手法を提案した先行研究について紹介する．

また，プロジェクトホスティングサービスでは，ソフトウェア

2. 1 バージョン管理システム開発に関わるやり取りなども公開している．プロジェクトホス

バージョン管理システム (Version Control System またはティングサービスはソフトウェア開発を円滑に行うための様々

VCS) とは，ソフトウェアのリソースを管理し，開発履歴を記録なサービスを提供しているが，それらの履歴等も公開されていするシステムである（図 1）．管理対象としたファイルのスナッるのである．GitHub というプロジェクトホスティングサービ

プショットを保存することで，変更履歴の管理を行う．VCS にスでは，ユーザがリポジトリに対してバグ報告や機能追加の要

よって管理されるソフトウェアのリソースとその変更履歴が保求を行うことができたり，ダウンロードしたリポジトリに対し存されたデータベースをリポジトリと呼び，リポジトリにファて行った修正をダウンロード元のリポジトリに取り込んでもら

イルのスナップショットを保存する作業をコミットと呼ぶ．こうようリクエストを送ったりすることができる．ユーザはリポの時，コミットに伴う情報もログとしてリポジトリに保存されジトリに含まれるリソースだけでなく，こういった開発の履歴

るため，ログを参照することで後からコミットの詳細を確認すについても確認することができる．

ることができる．ログには，コミットを行った開発者のユーザ

2. 3 Logical Coupling の検出

名とメールアドレス，コミット日時，コミットについてのメモ，

まず，VCS から抽出したログを用いて Logical Coupling の変更されたファイル名，変更内容などが含まれる．

検出を行った例として，Gall ら [10] の研究を紹介する．Gall図 3 既存手法と提案手法の比較

図 2 Gall らによる Logical Coupling の検出手法

リポジトリに対して同時に行われる変更を推定し，ソフトウェ
アプロダクト間に存在する Logical Coupling を検出スル手法

らは，VCS によって管理されるソフトウェアの開発履歴を分析することで，Logical Coupling の検出を行う手法を提案した．
また，Gall らは代表的な VCS の一つである CVS [6] のリポジトリを対象としている．

Gall らの手法では，どのファイルが同時に変更されたかという情報を必要とする．しかし，CVS はコミットトランザク
ションを明示的に管理しない VCS である．そのため，Gall らは各ファイルに対して行われた変更が一つのコミットトランザクションに属するものであるかを推定している．

Gall らは，コミットトランザクションを推定するために，以下の二点を同時に満たすことを基準として用いた（図 2）．
（ 1 ） 著者の名前が一致していること．
（ 2 ） 4 分以内に行われた変更であること．
このように，同一の開発者によってとても近い時間に行われた複数の変更は，同一のコミットトランザクションに属すると仮定して，コミットトランザクションの推定を行った．
続いて，Gall らの手法の手順を説明する．まず，VCS のログを参照し，モジュールが変更された時間と変更者の名前を取得
する．そして，上記の条件を満たすコミット群を一つのコミッ
トトランザクションとみなし，それらのコミットによって変更されたモジュールから二つを選択することにっよって，同時に変更されたモジュールのペアを生成する．最後に，モジュールのペアごとに出現回数をカウントし，その数が定めたしきい値を上回っている場合，そのモジュールのペアを Logical Couplingと判定する．このようにして，Gall らは実際のソフトウェア開発記録を用いて，単一リポジトリ内でのモジュール間の結合度を調査した．
また，複数のリポジトリに対して Logical Coupling の検出を行った例として，Fischer ら [7] の研究がある．Fischer らは，同じ製品グループに属するリポジトリ群に対して，Logical

Coupling の検出手法を適用した．複数のリポジトリの開発履歴から得られる情報を統合し，分析を行なっている．これによって Fischer らは，異なるリポジトリに含まれる複数のモジュー
ルが同時に変更されていることを示した．

3. 提案する Logical Coupling の検出手法
本節では，複数のリポジトリの開発履歴を用いて，複数のを提案する．ソフトウェアプロダクト間に存在する Logical

Coupling を検出することによって，異なるプロジェクトのモ
ジュールの変更に関する相関ルールを抽出する．こうして得られた相関ルールを利用することで，開発者があるモジュールを変更した際，次に変更すべきモジュールをプロジェクトの枠を越えて推薦することができる．
また，独立して管理されている複数のリポジトリについて，
それらに対して行われたコミットが同時に行われたものであるかを推定する必要がある（図 3）．これは，複数のリポジトリに跨って複数の変更が同時に行われたという，コミットトラン
ザクションにあたる情報が存在しないため，同時に行われた変更を明示的に確認することができないためである．
本研究では，複数のリポジトリに対して同時に行われた変更を，インターリポジトリコミットトランザクションと呼ぶことにする．インターリポジトリコミットトランザクションを定義することで，複数のリポジトリに対して同時に行われた変更を一つのまとまった変更と見なし，相関ルールの抽出を行うことができるようになる．
また，本手法では代表的な VCS の一つである Git [1] により作成された，Git リポジトリを対象としている．異なるプロ
ジェクトにより管理される複数の Git リポジトリを入力として，別々のリポジトリに含まれる同時に変更すべきモジュール（Logical Coupling）を出力する．
続いて，手法全体の流れを説明する（図 4）．まず，プロジェ
クトホスティングサイトにホストされているリポジトリに対して Git コマンドを用いることで，リポジトリのログを取得する．ここで，取得したログはリレーショナルデータ分析する際に扱いづらいため，必要な情報を整理しデータベースへ格納す
る．対象とする複数のリポジトリに対して同様の操作を実行することで，複数のデータベースを構築する．
次に，データベースに含まれる提案する条件を満たすコミッ
トを，インターリポジトリコミットトランザクションとして推定する．インターリポジトリコミットトランザクションの推定にあたって，通常のコミットトランザクションを推定する場合と比較して，次のようなことを考慮する必要がある．まず，開発者は複数のプロジェクトに参加しているため，開発者を一意に識別する ID の役割を持つものを用意する．また，一人の開を検出するために，以下の条件を提案する．

•

コミット同士が近い時間に行われており，また，同一著者による変更であること．
この時，コミットを行うのはあくまで一人の開発者であるため，コミット同士の時間間隔は比較的短いものでよい．また，同一著者であるかの判定には，コミットのログから得られる開発者の情報を利用する．
次に，リポジトリ間に利用関係がある場合，利用されている
図4

提案手法の流れ側のリポジトリに含まれるモジュールが変更され，利用している側のリポジトリに含まれるモジュールも変更する必要がある，発者によって同時期に為された変更であっても，ある程度離れという状況がある．このような変更を検出するために，以下のた時間間隔でコミットされることが考えられるため，適切な時条件を提案する．

間範囲を設定する必要がある．次に，リポジトリ同士に利用関•

コミット同士が近い時間に行われており，また，変更さ係が存在する場合，利用されている側のリポジトリに含まれるれたモジュールが利用関係の近傍にあるリポジトリに含まれてモジュールが変更された場合，それを利用している側のリポジ

いること．

トリのリポジトリも同時に変更しなければならない場合がある．

リポジトリの利用関係は，ソースコードを調べることで確認

この時，ある開発者が双方のリポジトリを管理するプロジェク

できることがある．ソースコードから確認できるリポジトリ同トに参加しているとは限らないため，コミットを行う開発者が士の利用関係の例として，Java における import 文や，C に異なる状況も考えられる．

おける include 文などがある．また，VCS の機能で他のリポ

最後に，推定されたインターリポジトリコミットトランザク

ジトリを利用指定をしている場合，VCS から利用関係の情報

ションを用いて，モジュールの変更に関する相関ルールを生成を得ることができる．この時，変更が伝搬するのに多少の時間する．この時，単一リポジトリに含まれるモジュール同士に関がかかるため，コミット同士の時間間隔は比較的長い時間を想する相関ルールは，本研究の検出対象ではないため除外する．

定する．

そして，生成された相関ルールについて出現回数と確信度を計

最後に，その他の状況において何らかの共通の要因によって，算し，その両方が定めたしきい値を超えているルールに含まれ異なるプロジェクトに含まれるモジュールが同時行われた変更

るモジュールを Logical Coupling と判定する．

を検出するために，以下の条件を提案する．

まず，3. 1 節でログをデータベースへ格納する方法について説明する．次に，3. 2 節でインターリポジトリコミットトラン
ザクションを推定するための新たな条件を提案する．最後に，

3. 3 節で相関ルールの生成について説明する．

•

コミット同士が近い時間に行われており，また，コミッ

トコメントの内容が類似していること．
コミットコメントの内容を比較する際，コメントの量や，使用されている語句の専門性を考慮する．膨大な量のコメントに

3. 1 データベースへのログの格納おいてその多くの単語が類似している場合，そのコメント同士

Git では，リポジトリに対してログ取得のコマンドを実行すは非常に類似していると考えられる．同様に，あまり一般的にることで，リポジトリに対して行われたコミットのログを時系

使用されない専門的な語句がコメント内に共通して含まれてい列順に取得することができる．取得したログはテキスト形式とる場合，そのコメント同士は類似していると考えられる．

なっているため，ログの形式に沿って必要なデータを抽出し，3. 3 相関ルールの生成

用意したデータベースのスキーマに沿って整理する．

3. 2 節で推定したインターリポジトリコミットトランザクショ

そして，それぞれのリポジトリに対して行われたコミットのンを元に，相関ルールを生成する．本手法では異なるリポジト

一覧と，それらのコミットにより変更されたモジュールの一覧

リのモジュール間に存在する Logical Coupling を検出対象とを関連付けて，データベースへ格納する．これによって，それしているため，相関ルールに含まれるモジュールが同一のリポ

ぞれのコミットがどのリポジトリに対して行われたか，どのモジトリに含まれていないルールのみを生成対象とする．

ジュールがどのコミットにより変更されたかを確認することができる．

本手法では，インターリポジトリコミットトランザクション
を一つのアイテムトランザクションと見なして，相関ルール

3. 2 インターリポジトリコミットトランザクションの推定の生成を行う．インターリポジトリコミットトランザクション

ここでは，複数のリポジトリに対して同時に行われた変更，中における，各モジュール集合の出現頻度を計算する．更に，

即ちインターリポジトリコミットトランザクションを推定する

ルールの前提部のモジュール集合の出現頻度とルール全体のモ条件について述べる．インターリポジトリコミットトランザク

ジュール集合の出現頻度から，各相関ルールの確信度を計算す

ションが発生すると考えられる状況に合わせて，本手法では三る．この時，計算された相関ルールの出現回数と確信度が定め

種類の条件を提案する．

たしきい値を上回っていた場合，ルールに含まれるモジュール

まず，一人の開発者が複数のプロジェクトに参加している状況において，複数のプロジェクトに対して同時期に行った変更

を Logical Coupling と判定する（図 5）．

表1

推薦・評価の結果

推薦対象モジュール推薦されたモジュール

出現回数 確信度

関連性

リポジトリ名モジュール名

リポジトリ名モジュール名senchalabs/connect

lib/patch.js

visionmedia/express

lib/response.js

4

0.57

×

senchalabs/connect

lib/middleware/router.js

visionmedia/express

package.json

4

0.57

×

senchalabs/connect

lib/patch.js

visionmedia/jadeReadme.md

4

0.57

×

rails/rails

railties/html/javascripts

madrobby/scriptaculous

CHANGELOG

14

0.54

〇

/dragdrop.js
visionmedia/express.pomo

visionmedia/jadetest/jade.test.js

4

0.50

×

ajaxorg/ace

src/ace/conf/keybindings

ajaxorg/cloud9

client/ext/tree/tree.xml

4

0.50

×

visionmedia/jadelib/jade.js

4

0.50

×

/default mac.js
visionmedia/express

.pomo

•

同一のインターリポジトリコミットトランザクションに含まれる，二つのモジュールに対して行われたコミットの diffに類似した行が存在する．

•

同一のインターリポジトリコミットトランザクションに含まれる，二つのモジュールに対して行われたコミットのコメ
ントの内容が類似している．

•
図 5 Logical Coupling の判定

一方のモジュールが含まれるプロダクトが，もう一方のモジュールが含まれるプロダクトを利用している．
また，今回は提案手法で述べた三種類の条件のうち，「二つの4. 変更箇所の推薦
本節では，提案手法によって検出した Logical Coupling を用

変更が近い時間に行われており，また，同一著者による変更であること」という条件についてのみ，実験を行った．実験に用いた具体的な基準はそれぞれ次の通りである．

いた変更箇所の推薦の結果について議論する．検出した Logical•

著者のメールアドレスが一致していること．

Coupling を用いてモジュールの推薦を行い，推薦されたモ•

24 時間以内に行われた変更であること．

ジュールが推薦対象のモジュールと一緒に変更すべきモジュールであるかどうかを確認する．

実験によって検出するモジュールの粒度をファイル単位として，Logical Coupling の検出を行う．モジュールの粒度をファ

まず，複数のリポジトリを対象として，提案手法を用いて検イルとした理由は，ファイルの内容や使用言語に影響を受けな出した Logical Coupling を用いて変更箇所の推薦を行う手法

い範囲で，最も粒度の細かい単位であるためである．また，今を紹介する．これによって，あるモジュールの変更に伴って他回は全てのルールのうち，相関ルールの前提部，結論部の要素のプロジェクトのモジュールを変更する場合に，必要な変更をが一つのルールのみを抽出している．

より容易に行うことができると考えられる．

続いて，今回行った変更箇所の推薦の実験に使用したデータ

変更箇所の推薦には，3. 節の手法によって抽出した，モジューと，実験結果について述べる．まず，4. 1 節で使用したデータ

ルの変更に関する相関ルールを利用する．まず，相関ルールのについて説明し，4. 2 節で実験結果について述べる．そして，出現回数と確信度のしきい値を設定し，出現回数・確信度の両

4. 3 節でその結果について考察する．

方が定めたしきい値を超えているルールを抽出する．そして，

4. 1 実験に使用したデータ抽出されたルールについて，ルールの前提部と推薦対象のモ

GitHub にホストされた 100 件のリポジトリを，データセッ

ジュールが一致している場合，ルールの結論部のモジュールをトとして使用した．これらのリポジトリは，GitHub の watch

推薦する．

という機能を用いることで注目しているユーザ数の多いリポジ

次に，推薦結果の評価基準について説明する．推薦結果の相トリを特定し，その数の多い順に 100 件のリポジトリを選択し関ルールに含まれるモジュールが，本当に同時に変更すべきモている．また，100 件のリポジトリに対して行われた総コミッ

ジュールであるかどうかを確認する必要がある．例として，二ト数は 527,317 件であり，ファイルが変更された回数の合計はつのモジュールの間にコードクローンが存在したり，モジュー

1,691,746 回であった．

ルが含まれるリポジトリ間に利用関係などが存在する場合，それらは同時に変更すべきモジュールであると考えることができる．

4. 2 結果

100 件のリポジトリから取得したログを用いて，条件を満たすインターリポジトリコミットトランザクションを推定し，モ二つのモジュールが同時に変更すべきかどうかを客観的に判ジュールの変更に関する相関ルールを生成した．この時生成さ断するため，今回は以下の基準のいずれかを満たすことを条件れた相関ルール数は合計 78,306 件であった．これらのルールとした．

のうち，確信度が 0.5 以上であり，出現回数が 4 回以上のルー

ルを，モジュールの推薦に利用した．

しかし，より近い時間に行われた変更は，同時に行われた変更

結果として，定めたしきい値を満たす相関ルール数は 7 件でである可能性が高いと考えられるため，その点を考慮した推定あった．表 1 はそれらの相関ルールを，確信度の高い順に上位基準を検討する必要がある．また，相関ルールの生成時のパラ10 件を並べたものである．この表では，それぞれの行が一つのメタについても，より良いパラメタを検討する必要がある．

相関ルールを表している．一列目，二列目が推薦対象モジュー

最後に，今回対象としたリポジトリ数が 100 件と少なく，ルと，それに対して推薦されたモジュールを表しており，三列

データセット中に深く関連するプロジェクトがあまり含まれて目，四列目がルールの出現回数と確信度を示している．

いなかったことが考えられる．調査するリポジトリ数が少ない

前述の条件にしたがって，モジュール間に同時に変更すべき関係があるかを判断した結果を，表 1 の五列目に示した．総評
として，モジュール間に関連性が見られたものは 7 件中 1 件
であり，あまり良い推薦結果は得られなかった．

場合，データセット中に深く関連するプロジェクトが含まれる
可能性が低くなるためである．

5. まとめと今後の課題

今回の実験で生成されたルールでは，どのようなモジュール

本稿では，複数のリポジトリに対して Logical Coupling のの変更に対してどのようなモジュールが推薦されていたのか検出を行う手法を提案した．複数のリポジトリに対して同時にを説明する．まず最初に，関連がないと判断した，表 1 の二行われるコミットとはどのようなものかを考え，それに則した

行目のルールについて言及する．推薦対象モジュールは sen-

検出条件を作成した．そして，提案した手法のうち一つを実装

chalabs/connect リポジトリに含まれる lib/patch.js，推薦さし，Logical Coupling の検出を行った．また，提案手法を用いれたモジュールは visionmedia/express リポジトリに含まれて変更すべきモジュールの推薦を行い，その結果の有用性につる lib/response.js である．推薦対象モジュール，推薦されたモ

いて議論した．

ジュールともに，javascript のソースファイルである．それぞ

今後の課題として，まずモジュールの変更回数を考慮するなれのモジュールに対して行われたコミットの diff，コミットのどして，より有用な推薦を行える手法について検討する．また，コメントを確認したが，類似した内容は見られなかった．また，

今回行った実験は対象としているリポジトリ数が少なかったた

それぞれのモジュールが含まれるプロダクト同士に利用関係がめ，より多くのリポジトリを対象として Logical Coupling の無いか探したが，そのような関係を見つけることはできなかっ検出を行う必要がある．多くのリポジトリを対象とすることでた．そのため，今回はこのルールに含まれるモジュール同士に関連があるリポジトリの絶対数が増加するため，同時に変更すは関連がないと判断した．また，表 1 の三，四，六，七，八行

べきモジュールも増加すると考えられる．最後に，今回実験を目のルールについても，同様に内容を確認したが上記の基準を行うことが出来なかった条件についても Logical Coupling の満たさなかったため，ルールに含まれるモジュール同士には関検出を行い，それを用いた場合の推薦結果を評価する．

連がないと判断した．
続いて，関連があると判断した 1 件のルールについて言及

謝辞

本研究は，産総研基盤 A（24240015A）による．

する．推薦対象モジュール rails/rails リポジトリに含まれる

railties/html/javascripts/dragdrop.js，推薦されたモジュール
madrobby/scriptaculous に含まれる CHANGELOG である．
推薦対象モジュールは javascript のソースファイルで，推薦されたモジュールは変更ログファイルである．それぞれのモジュールに対して行われたコミットのコメントを確認したところ，双方のコメントに共通の内容が確認できたため，このルールに含まれるモジュール同士には関連があると判断した．ただし，このルールでは変更ログファイルが推薦されていたため，あまり有用な推薦結果とは言えないだろう．

4. 3 考察

今回の実験では，異なるプロダクト間に存在するモジュールの変更に関する相関ルールを生成したが，ルールに含まれるモジュール間の関連はあまり見られなかった．有用な推薦が行えなかった原因として，推薦されるモジュールの変更回数を考慮
していなかったことが考えられる．相関ルールの性質上，とても頻繁に変更されるモジュールはルールの結論部に出現しやすくなるためである．
また，パラメタについて十分な検討ができていなかったことが考えられる．まず，インターリポジトリコミットトランザク
ションの推定のための時間間隔を一律で 24 時間と設定した．

文

献[1] Git. http://git-scm.com/. accessed on 01/14, 2013.
[2] GitHub. https://github.com/. accessed on 01/14, 2013.
[3] SourceForge. http://sourceforge.net/. accessed on 01/14,
2013.
[4] Google Code. http://code.google.com/. accessed on
01/14, 2013.
[5] CodePlex. http://www.codeplex.com/. accessed on 01/14,
2013.
[6] CVS. http://www.nongnu.org/cvs/. accessed on 01/14,
2013.
[7] Michael Fischer, Johann Oberleitner, Jacek Ratzinger, andHarald Gall. Mining evolution data of a product family.
In Proc. Int’l Workshop on Mining Software Repositories(MSR), 2005.
[8] Beat Fluri, Harald C. Gall, and Martin Pinzger. Fine
grained analysis of change couplings. In Proc. Int’l Workshop on Source Code Analysis and Manipulation (SCAM),
2005.
[9] Harald Gall, Karin Hajek, and Mehdi Jazayeri. Detection oflogical coupling based on product release history. In Proc.
Int’l Conf. Software Maintenance (ICSM), 1998.
[10] Harald Gall, Mehdi Jazayeri, and Jacek Krajewski. CVS
release history data for detecting logical couplings. In Proc.
Int’l Workshop on Principles of Software Evolution (IWPSE), 2003.

[11] Masao Ohira, Naoki Ohsugi, Tetsuya Ohoka, and Ken-ichi
Matsumoto. Accelerating cross-project knowledge collaboration using collaborative filtering and social networks.
In Proc. Int’l Workshop on Mining software repositories(MSR), 2005.
[12] Didi Surian, Nian Liu, David Lo, Hanghang Tong, Ee-Peng
Lim, and Christos Faloutsos. Recommending people in developersćollaboration network. In Proc. Working Conference on Reverse Engineering (WCRE), 2011.
[13] Thomas Zimmermann, Peter Weißgerber, Stephan Diehl,
and Andreas Zeller. Mining version histories to guide software changes. In Proc. Int’l Conf. Software Engineering(ICSE), 2004.
[14] 中村高士，早瀬康裕，北川博之. プロジェクト横断的なオープン
ソースソフトウェア開発記録の分析手法. 情報処理学会 第 74 回
全国大会, 2012.