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

関心度に基づいたソースコード推薦システム
村上 直也

増原 英彦

青谷 知幸

コード推薦システムの多くは，開発者が編集中の行の周辺行に類似したプログラムを大規模コードリポジトリから検索し，開発者が次に書くと予測されるコードとして類似部分の後続行を提示する．検索の際に周辺行だけでなくその背景情報—これから記述しようとしている内容やそれが使われている場所—も用いればより精度の高い予測が出来ると予想されるが，そのような情報をコードから抽出することは容易でない．そこで我々は，統合開発環境の編集操作履歴からコードの背景情報を抽出し，それを背景情報として用いた検索を行うコード推薦システムを提案する．シ
ステムは既存のコード推薦システム Selene を拡張し，コード編集操作履歴から開発者が最近に閲覧・編集したコード中の単語を抽出し，それらを重み付けして編集中の行の周辺行の単語情報と共に検索コード推薦を行う．単語重みは，複数の開発者の開発記録を基に機械学習し決定する．

べる．コード推薦は，開発者が現在編集中のクラスや

1 はじめにメソッドにおいて次に書くであろうコード断片を提示

開発環境において開発者のソースコード編集を補することとする．コード断片を提示することで，複数助する機能であるコード推薦やコード補完の重要性

メソッドを呼び出す場合のメソッド呼出順序を開発者が，ライブラリやフレームワークの種類の増大・APIが知ることが出来る．コード補完はメソッド名，変数の巨大化に伴い高まっている．種類の増大・API の名を提示したり自動的に挿入したりすることとする．

巨大化によって，開発者が調査や記憶すべき量も増加

本研究はコード推薦システムを開発する．コード推している．調査や記憶すべき内容は，使用すべきクラ薦がコード補完に対して優れている点は，開発者にス名やメソッド名，そして複数メソッドを呼び出す場とって未知の情報や既知だが思い出せない情報を提示

合のメソッド呼出順序などである．また，たとえ開発出来ることである．そのようなことは開発者が作成中者がソースコード編集に必要な内容を記憶していてのコード内容や開発者が記述したクエリを基に，コーも入力の手間は減るほうが良い．コード推薦やコードド断片を検索または合成し提示することで可能になっ補完はそのような問題に対処する．ている．例えば Strathcona [2] は，開発者が編集中の本研究におけるコード推薦とコード補完の定義を述

メソッドの中に InputStream.read(byte[]) と入力
すると，既存のソフトウェアのプログラムに対して検A Source Code Recommendation System Based on
Degree of Interest.
Naoya Murakami, 東京大学大学院総合文化研究科広域科学専攻, Dept. of General Systems Studies, Graduate School of Arts and Sciences, the University ofTokyo.
Hidehiko Masuhara, Tomoyuki Aotani, 東京工業大学
大学院情報理工学研究科 数理・計算科学専攻, Dept.
of Mathematical and Computing Sciences, Graduate School of Information Science and Engineering,Tokyo Institute of Technology.

索し，read メソッドが使用されているコード断片を提示する．
コード推薦システムには様々な種類があるが我々が開発するシステムは，開発者がクエリを入力すること無しにシステムが自動的にクエリを作成し，オープンソースのプログラムが格納されたデータベース（以降では単にリポジトリと呼ぶ）からコード断片を検索・提示する種類のものである．コード推薦システムは以hhhh
hhhh
h

表1

コード推薦システムの分類

クエリ作成者

hhhh
開発者
hhhh
推薦コード作成方法
hh
既存コード[5] [6]

合成[1] [3]下の 2 つの観点から分類することが出来る．(表 1)
クエリの作成者システム[2] [9] [11]，本研究開発者はテキストエディタを作ろうとしている．
そのためにテキストエディタのメニューバーを表

クエリとはリポジトリの検索に用いる情報のこす OpenFileMB クラス (Listing 1) を作成した．とであり，開発者が入力するものとシステムが自そしてその次に，選択したファイルの文字列を動的に作成するものがある．クエリをシステムがエディタペインにセットする actionPerformed

作成するシステムに着目したのは，推薦システメソッドを，OpenFileMB クラス内に定義した．

ムの使用に伴う手間が少なくて済むからである．

そして actionPerformed メソッドでファイルか

しかしその分開発者の意図をクエリに反映させら文字列を読み込むために，FileUtil クラスることが困難であり，その問題は本研究で扱う．

(Listing 2) の readFile メソッドを作成し始め

推薦コード作成方法
推薦コード作成方法とは推薦されるコードをどのように用意するかということであり，既存のプログラムをそのまま用いるものと，ライブラリやた．しかし，開発者は行単位で文字列を読み込む方法が思い出せないでいる．
図1

開発者の作業状況の例

既存のプログラムを基に合成して作成するものがある．既存のプログラムをそのまま用いるシステムに着目したのは，実際に使用されているソースコードということで現実的な推薦が出来るからである．反面開発者に役立つ推薦結果が得られるようにするには巨大なリポジトリを作成する必要があるが，現在ではオープンソースの膨大な量のプログラムを利用出来るため問題ない．
我々が開発した Selene を基に，本研究のシステムを開発する．同種のシステムの研究には，Strathcona

Listing 1 OpenFileMB クラス
class OpenFileMB extends JMenuBar {Application app ;JFileChooser chooser ;void a c ti on P er fo r me d( ActionEvent event ) {File file =chooser . ge tS e le c te dF i le () ;app . getEditorPane () . setText (readFile ( file ) ) ;}}[2]，Reverb [9] がある．Strathcona は型情報を基にクエリを作成するが，本研究は単語情報を基にしているのでリポジトリを巨大にしても検索速度への影響が少ないという利点がある．Reverb は過去に訪問した

Web ページ上のコードをリポジトリにしていて，本研究のシステムのリポジトリよりも限定されたもの

Listing 2 FileUtil クラス
class FileUtil {String readFile ( File file ) {InputStream is =new InputStream (new F il eI n pu tS t re a m ( file ) ) ;となっている．て図 1 のような状況を仮定する．その状況下でもし

1. 1 コード推薦システムの役割

コード推薦システムが以下のコードを提示すれば，開コード推薦システムの役割は， 開発者が次に書く発者はその推薦コードから次にどう書くべきかが知であろうコード断片を提示することである．例としることが出来る．

得する．
編集中ソースファイルの単語頻度情報算出
編集中ソースファイル中の単語 †1 がそれぞれ何回出現するかという頻度情報を算出する．単語頻度情報の算出の際に，Selene では編集中の行の周辺を重視するために，カーソル行に近いほど単語の頻度に重みをつける．
類似ソースファイルの検索
頻度情報をクエリとして，類似したソースファイル群をリポジトリから検索する．検索には GETA

[10] [12] を利用している．リポジトリは約 200 万
図2

Selene の機構のオープンソースのプログラムで構成されている．
類似コード断片のランク付け
類似ソースファイルをコード断片に分割し，そのコード断片を編集中ソースコードのカーソル行

Buffered Reader br =new BufferedReader (new In pu tSt rea mRe ade r ( is ) ) ;while (( tmp = br . readLine () ) != null ) {周辺に類似しているかでランク付けする．ランクが高いコード断片について，そのコード断片以降を中心にしたソースコードを Selene の推薦結果として表示する．ランク付けは，単語の並びの類

本研究は，リポジトリに対する検索のクエリの作成似度の比較によって行っている．

方法を改良することで，コード推薦システムの推薦結
果の質の向上を図る．クエリの作成の際に，これから記述しようとしている内容やそれが使われている場所も用いることでより良いクエリを作成する．

2. 2 既存のコード推薦システムの問題点
開発者が書こうとしている一連の処理が複数のモジュールに跨がる場合，既存のコード推薦システムで第 2 節では既存のコード推薦システムとその問題は一部のモジュール，多くても編集中の 1 ファイル点を述べる．第 3 節では提案手法の概要を説明する．

上に存在するものしかクエリ作成に使用していない．

第 4 節では本研究のシステムの構築方法を説明する．

もしモジュール間の依存関係を算出出来れば，一連の第 5 節ではシステムで用いるモデルの調整方法を，第処理全体をクエリ作成に用いることは可能であろう．

6 節では関連研究と本研究との比較を行う．第 7 節でしかし編集中のソースファイルが書き途中で意味解析はまとめと今後の課題を報告する．

出来ない状態のときは正確には算出できない．また，デザインパターンを使ったプログラムのように依存関

2 既存のコード推薦システムとその問題点
2. 1 コード推薦システム Selene係が直接的でない場合もある．
上記の問題点を図 1 の状況を仮定して説明する．そ

本研究のシステムの基となる Selene について，図2 を用いて以下の 4 段階で説明する．
編集中ソースファイルの取得

Selene のフロントエンドは Eclipse のプラグインとなっていて，Eclipse で開発者が編集中のソースファイル一つを取得する．カット& ペースト
や行単位のカーソルの移動のたびに自動的に取†1 現在の Selene では連結した英字を単語としていて，大文字小文字を区別しない．
†2 http://www.herongyang.com/Swing/JEditorPane-File-Chooser-Dialog-Box.htmlに掲載されたソースコードの一部を改変し使用した．
†3 http://www.javadb.com/reading-objectsfrom-file-using-objectinputstreamに掲載されたソースコードの一部を改変し使用した．

ている．Listing 2 に出現している readFile という
Listing 3 行ごとに文字列を読み込むコード †2File selectedFile = chooser .
g etSe lectedFile () ;InputStream fis =new FileInputStream ( selectedFile ) ;I n pu t S t rea mRe ad er in =new In put Str eam Rea de r ( fis ) ;Buffered Reader br =new BufferedReader ( in ) ;while (( tmp = br . readLine () ) != null ) {略}単語が，Listing 4 のみに存在するからである．もしListing 1 と Listing 2 を合わせたものと比較すれば，Listing 3 が Listing 4 よりも類似している．Listing 1に出現している getSelectedFile や chooser といった単語が，Listing 3 のみに存在するからである．しかし，既存のシステムでは Listing 2 しかクエリ作成に使用しない．

3 関心度に基づくコード推薦
3. 1 提案手法の概要

Listing 4 オブジェクトを読み込むコード †3String readFile ( File filename ) {inputStream =new Ob je ctI npu tSt rea m (new FileInputStream ( filename ) ) ;Object obj = null ;while (( obj = inputStream . readObject ())!= null ) {if ( obj instanceof Property ) {list . add ((( Property ) obj ) . getSettings () ) ;}}}編集中の行の周辺だけではなく，その直前に編集したコード断片も含めて類似したソースコードを検索し提示すれば，開発者にとってより良い推薦が出来ると予想する．2. 2 節で述べた問題は，クエリ作成に用いる情報から背景情報が欠如していることの問題だと言い換えることが出来る．ただし背景情報の定義は次のようなものとする．
背景情報 開発者が作ろうとしている機能と，その機能の他の機能との関係のこと
機能 ソフトウェアの振る舞い，働きのこと:行単位でファイルを読み込む，AST のパーサを作成する，FTP で接続するといった粒度
先ほどの例でいうと背景情報は，行単位でファイルをの状況下では，既存のシステムは Listing 3 と List-読む機能を作ろうとしていて，それはメニューバーでing 4 のようなコード断片を推薦し，Listing 4 が選択したファイルからテキスト読込をするためとな

Listing 3 より上位に推薦される可能性がある．

る．そして最近閲覧・編集したコードは，背景情報のListing 3 は Listing 4 よ り も 開 発 者 に とって 役

良い近似となっている．何故なら一連の処理が複数

立 つ 推 薦 結 果 で あ る ．Listing 3 が 役 立 つ の は ，のモジュールに跨がっていても，閲覧・編集はどのモ

BufferedReader.readLine() を用いてファイルかジュールに対しても行われるからである．また，開発ら行単位で文字列を読み込んでいるからである．List-

者は今作ろうとしている機能と関係が深いコードを同

ing 4 が Listing 3 よりも劣るのは，オブジェクトを時期に閲覧・編集することが多いことも理由である．

ストリームから読み込むデシリアライズをしていて，よって最近閲覧・編集したコードから背景情報を抽出文字列読込をしている開発者の作業と関係が遠いかして，それをクエリに用いることでより良い推薦を行らである．

うことが出来る．

既存のシステムで Listing 3 が Listing 4 よりも上位の推薦結果とならないのは，開発者のプログラ

3. 2 推薦システムの概要

ムでは一連の処理が 2 つのクラス (OpenFileMB と最近閲覧・編集したコードから背景情報を抽出するFileUtil) に分散されているからである．Listing 2

ために，Degree Of Interest(以降では関心度と呼ぶ)と比較すれば，Listing 4 が Listing 3 よりも類似しという指標を改良して用いる．関心度は統合開発環

刻 †4 である．DOI(n) は 1 番目から n 番目までの各イベントのスコアの合計を求め，それから時間経過による減衰度を引くことで求まる．イベントのスコDOI

アは関数 S で求まり，イベントの種類ごとに値が異なる．減衰度は関数 decay で求まり，decay は t と比0

例関係にある．ただし特別な規則として，メソッド mに対するイベントが発生した際に関心度が負ならば，n と t をリセットする．この規則は，イベントが発生0t1

t2t

図3

メソッド m の関心度の推移

境 Eclipse のタスク管理システム Mylyn [4] で導入された指標であり，統合開発環境の操作履歴を基にした指標なので背景情報の抽出に有効だと考えた．本研したにもかかわらず関心度が負になる事態を防ぐことを目的とする．

DOI(n) を，メソッド m の関心度の推移を表している図 3 を用いて説明する．図 3 では以下を仮定している．

1. メソッド閲覧イベントのスコアは a，メソッド編集イベントのスコアが b

究における関心度は，開発中のプロジェクトに含まれ2. メソッド m に対して t = 0, t1 でメソッド閲覧るメソッド名と実数の組で表される値で，どれだけ最イベントが，t = t2 でメソッド編集イベントが近に，どれだけ多くの閲覧・編集をメソッドが受けたかを示している．

発生

3. decay(t) = ct

Selene の推薦システムの類似ファイル検索で用い

まず DOI(2) を例にして考えると，t = t1 までにメる単語頻度情報に関心度を反映させる．前述したよ

ソッド閲覧イベントとメソッド編集イベントがメソッ

うに，類似ファイル検索では単語頻度情報の類似度にド m に対して１つずつ発生しているので，よって検索している．本研究では Selene の行による

DOI(2) = (a + b) − ct1

重み付けの代わりに，関心度で単語頻度情報を重み付けする．開発中プロジェクトの全ファイル中の単語となる．次に，DOI(3) を例にして考えると，について，メソッド内で現れている単語はそのメソッ
ドの関心度で重みを付ける．

DOI(3) = DOI(1′ ) = a − c × 0となる．DOI(1′ ) となっているのは，イベント発生

3. 3 関心度モデル

時に関心度が負だったため n と t がリセットされた

Mylyn の関心度モデルを説明する．関心度アルゴからである．

リズムを式にすると以下のようになる．

DOI(n) =n∑

S(ki ) − decay(tn )i=0

3. 4 関心度に基づくコード推薦の例
本研究のシステムでの推薦方法を具体例で説明す

DOI(n) はメソッド m の関心度である．n はメソッる．2. 2 節で例示した状況下で，関心度は 3. 3 節でド m に関するイベント列の n 番目のことである．イ

説明した算出方法によって {actionPerformed=10,

ベントとは，開発中のプロジェクトの要素に対するreadFile=20} となったとする．InputStream とい操作のことである．開発中のプロジェクトの要素とう単語は readFile メソッドに 2 つ存在し，その頻度は，プロジェクト中のフォルダやソースファイル，クラス，メソッドなどである．ki は i 番目のイベントの種類を表し，tn は n 番目のイベントが発生した時†4 時刻は他のメソッドに対するイベントも含めて，イベントが発生するごとに進む．ただしイベントの種類で時刻の進み幅は異なる．

単語頻度例

操作の種類，発生時間，イベントが対象とする要素の単語頻度

重み付き頻度

具体名を保持する．開発中プロジェクトのメソッドのInputStream

240

選択や編集に関係するイベントのリストをメソッド

getSelectedFile

110

操作履歴と定義する．メソッドの選択に関係するイベchooser

110

ントとは，Eclipse のビューやエディターでメソッド表2をマウスで選択することである．メソッドの編集に関係するイベント (以降ではメソッド編集イベントと呼ぶ) とは，エディタでのメソッド上のカーソル移動を伴う操作のことである．文字の入力と削除，メソッド内のカーソル位置の移動などが含まれ，それらはEclipse による操作感知の仕様に基づき一定間隔で 1つのイベントにまとめられる．Mylyn のイベント履
歴収集では上記のイベント以外も収集するので，本研究で使用するイベントの履歴のみを保存するように改良した．

5 関心度モデル調整
図4

本研究のシステムの構成

5. 1 理由
関心度計算モデルの調整が必要なのは，Mylyn のを関心度で重み付けすると 2 × 20 = 40 となる．開発

関心度を本研究のシステムで用いるにあたって次の 2者が開発中プロジェクトの全てのソースファイル中のつの問題点が存在するからである．

単語について，表 2 のような関心度で重み付けした

1. 本研究では開発者にタスクを宣言させたくない頻度を求め，その単語頻度を類似ファイル検索に用

2. 推薦システムに合わせた関心度の値の調整がいる．

必要

Mylyn では，開発者が明示的にタスクを作成，切り4 推薦システム構築

替えることでタスクごとに操作履歴を記録する．しか推薦システムの構築にあたって行うべきことは，メし本研究ではタスク作成の手間を軽減させるために，ソッド操作履歴収集プラグインの作成である．Selene

タスクという概念を導入しない．言い換えれば，１の類似ファイル検索で，単語頻度情報に対する重みとつのタスクを永続的にアクティブにしている状態でして関心度を用いるように改良することで，推薦シスある．この使用方法は Mylyn では想定されていないテムを構築する．関心度はメソッド操作履歴を関心度ため，パラメータの調整が必要となる．Mylyn では

モデルに入力することで得ることが出来，その関心度

3. 3 節の関数 decay は t の増加によって線形に増加すモデルは Mylyn のものを使用する．よって，メソッる．タスクに関連しないメソッドはあまり操作しない

ド操作履歴を収集するプラグインを作成することがため，減衰度を時間経過と共に急激に大きくさせる必必要となる．

要がないからである．しかしタスクを永続的にアクMylyn のイベント履歴収集機能を使用し，メソッティブにしているので関数 decay を線形に増加させドの選択や編集に関係するイベントを収集するようにると，多くのメソッドの関心度が高止まりしてしまう改良する．Mylyn では関心度を計算するために，開恐れがある．よって指数関数的に増加させれば良いと発者が統合開発環境を使用中にイベントが発生した履予想されるが，その予想が正しいかは明らかではな

歴の保存をバックグラウンドで行う．各イベントは，く，最適な増加率も明らかではない．

Listing 5class Event {Time t ;Kind k ;File f ;Patch patch ;}データ構造

関心度の使用目的が Mylyn と異なり Selene の行重
みの代わりとして用いるので，関心度の値の調整が必要である．関数 S と関数 decay の大きさを変更する
ことで調整する．それらのパラメータの調整の縛りとして，DOI(n) の大きさを行重みと同等の大きさにListing 6 再現率の計算アルゴリズム
evaluate Syste m ( QnA , eHis ) {for ( Pair pair : QnA ) {//qEve.t 時の DOI を算出
dois = calcDOI ( eHis , qEve . t ) ;//qEve.t 時の開発中プロジェクトを復元
proj = reProj ( eHis , qEve . t ) ;// 推薦コード断片を取得
recomSnips = gRecom ( dois , proj ) ;//aEve.t 時の開発中プロジェクトを復元
neProj = reProj ( eHis , aEve . t ) ;ansFrag = proj と neProj の増分コード断片// 再現率を計算
calcRecall ( ansFrag , recomSnips ) ;}}すればよいと予想される．しかしパラメータの最適値は不明である．

編集イベントの発生ごとにソースコードの差分を取得する．その拡張したプラグインを複数の開発者に

5. 2 方法

使用してもらい，メソッド操作イベントの集合 eHis

複数の開発者のメソッド操作履歴とソースコードかを取得する．メソッド操作イベントのデータ構造はら問題セットと正解セットを作成し，それを基に推薦Listing 5 のようになっていて，メソッド操作イベンシステムのパラメータを最適化する．我々が Selene

トの種類がメソッド編集イベントならば，patch にの最適化に用いた方法 [7] を用いる．ただし Selene のソースコードの差分が代入されている．そして eHis

調整では既存のソースコードを分割することで問題を基に，問題セットとなるイベント (qEve とする) とセットと正解セットを作成したが，本研究ではメソッ

正解セット作成のためのイベント (aEve とする) のペ

ド操作履歴とソースコードからソースコードの編集過アのリスト QnA を作成する．qEve は，その発生時に程を復元し，それを基に問題セットと正解セットを作推薦システムを使用したと仮定するイベントのこと成する点が異なる．推薦システムのパラメータとは，である．そして aEve は，qEve 発生時に推薦された以下の２つのこととする．

コード断片を参考にしてコードを書き終えた段階の1. 関数 decay を線形関数にするか指数関数にする
かの選択

2. 関心度の計算式のパラメータイベントである．1 節で述べた推薦システムの役割を考慮すると，開発者がこれまでの段階で書いていないメソッドやコンストラクタが qEve と aEve の間で呼この 2 つのパラメータの最適値を推定するために，推び出されている場合に，開発者が推薦システムを使薦システムの性能評価指標として再現率 [7] を用いる．

用すると近似できる．よって qEve と aEve の間隔は，その再現率を指標として，山登り法でパラメータの調そのようなメソッド，コンストラクタを記述しかつ数整を行う．

行の長さとなるようなイベント間隔にすればよい．

再現率を測定するための入力データの収集方法を述

再現率の測定アルゴリズムを，Listing 6 を用いてべる．4 節で紹介したプラグインを拡張することで，述べる．アルゴリズムの入力は，eHis と QnA である．

メソッド操作履歴に加え，メソッド編集イベント発アルゴリズムは QnA 中のペアについての繰り返しと生時の統合開発環境上のソースファイルも収集する．

なっているので，繰り返しの内容を 2 段階に分けてソースファイルをイベント発生ごとに収集すると最以下で述べる．

終的なデータのサイズが大きくなるので，メソッド推薦システム使用状況の復元と推薦結果取得

まず，イベント発生履歴 eHis から qEvent.t 時の開発中プロジェクトのメソッドの DOI を算出

Bu ffered Reade r br =new Buffe redRea der ( sr ) ;する (dois)．次に eHis から，qEvent.t 時まで

この中に含まれる単語は，InputStreamReader，sr，のイベントの patch を順に当てることで，開発is，BufferedReader，br の 5 つである．

中プロジェクトを復元する (proj)．プロジェク

そして推薦されたものが次のコード断片だったとト中のソースファイルの名前とその内容を復元可する．

能である．そして dois と proj があれば本研究

I n pu t S t r e a m R e a d e r isr =new I n p u t S t r e a m R e a d e r (System . in () ) ;Bu ffered Reade r br =new Buffe redRea der ( isr ) ;の推薦システムを使用することが出来るので，推薦されたコード断片群を取得する (recomSnips)．
正解セット作成と再現率計算
まず，qEvent.t 時の開発中プロジェクトの復元

正解セットと推薦されたコード断片の両方に含まれると同様に，aEvent.t 時の開発中プロジェクトの単語は，InputStreamReader，BufferedReader，brファイルを復元する (neProj)．次に qEvent.t 時の 3 つである．よって再現率は 3/5 となる．と aEvent.t 時の編集中ソースコードの増分を取ることで，正解セット ansFrag を作成する．そ6 関連研究して推薦されたコード断片群 recomSnips と正コード推薦システムの違いについては 1 節で紹介

解セット ansFrag を比較することで再現率を算済みなので，本節では推薦システムに履歴を使うこと出する (calcRecall)．

に関してのみ議論する．

再現率は，次に書くべきコード断片を推薦結果がど

本研究のようにメソッドの選択履歴まで使用してれだけ予測できたかを数値化した指標である．推薦さいる研究はないが，編集履歴を使用した研究には，れたコード断片と正解セットを単語の重複を許さない

Robbes らの研究 [8] と Reverb [9] がある．Robbes ら集合に変換し，それぞれを s，a とする．推薦されたの研究は，統合開発環境のコード補完候補を統合開発

コード断片は実際は複数だが，説明の簡略化のために単数とする †5 ．ここでいう単語は，現在の Selene に環境の編集履歴から抽出，ランク付けしている．最近おける単語から，予約語を除外したものとする．予約れているメソッド名ほどコード補完の上位に位置づ語を除くのは，予約語は開発者にとって既知だと考えけされるように編集履歴を使用している．よって本研られるからである．そのとき再現率は以下の式で定義

究とは異なり，編集頻度は考慮せず，編集履歴を数値される．

情報に変換して使用してもいない．本研究でそうしrecall(s, a) =|s ∩ a||a|

編集されたメソッドのメソッド名やその中で呼び出さない理由は，開発者は複数のメソッドを同時に閲覧，編集すると考えられ，その行動から背景情報を抽出す

この式は，s，a 両方に出現する単語の種類数を，aるためには数値化が必要だからである．履歴を用いたに出現する単語の種類数で割るということを意味す

コード補完の評価には，本研究と同様に履歴からコーる．正解セットと問題セットの組ごとに再現率が求ま

ド補完の使用状況を復元して正解率を測定している．

るので，その平均を取ったものを推薦システムの性能その結果標準的なコード補完よりも履歴を用いたコーとする．

ド補完の方が正解率が上回った．

再現率の算出方法を具体例で説明する．正解セット

Reverb は，開発者が過去に閲覧した Web ページが次のコード断片だとする．に掲載されているコード断片の中から，現在作成中のI np u tS t rea mRe ad er sr =new I n put Str eam Rea de r ( is ) ;コードに関係するものを推薦する．本研究とは異な†5 正確なアルゴリズムは [7] に記載されている．

り，統合開発環境の編集履歴ではなく Web ページの閲覧履歴を推薦に使用している．しかし本研究と同様

に，最近の閲覧や頻繁な閲覧ほど重みが大きくなるよ

語種類の一致率を再現率として定義し，全問題セットうに検索の重み付けを行っている．

に対する再現率の平均値を推薦システムの性能評価

次に書くであろうことを編集中の行の周辺から推指標とし，それに基づいてパラメータの調整を行う．

測している研究には，Strathcona [2] がある．Strath-cona は，クラス，メソッド，又はフィールドのどれ

7. 2 評価方法と今後の課題

か 1 つを開発者が指定すると，それに関連する情報

従来の推薦システムとの比較評価のため，Seleneをもとに推薦を行う．メソッドを指定した場合は，そとの比較を行う予定である．そのために 5 節でのパのメソッド定義内のメソッド呼出の型情報，メソッドラメータの決定の際に，問題セットと正解セットのが属するクラス名，その親クラス・インターフェース組の集合をランダムに k 個に分割し，k-fold Cross-名を基に推薦を行う．Strathcona は現状では履歴をValidation を行う．再現率の平均値による山登り法

用いていないが，指定した１つの要素が一連の処理のは，訓練データセットに対して行う．そして山登り法一部分でしかない可能性が存在する．その場合，本研によって求まったパラメータを推薦システムに適用す究で提案した手法で複数のファイルから要素を選択でる．その推薦システムをテストデータセットに対しきればより良い推薦が出来ると思われる．て用い，再現率の平均値を求める．Selene もテスト推薦システムがクエリを作成する研究には，CodeConjurer [3] や Mishne ら の 研 究 [6] が あ る ．Code

データセットに対して用い再現率の平均値を求め比較する．

Conjurer はクラスを模したクエリをもとに，推薦を現時点では編集履歴収集プラグインの作成を行った行う．そのクエリに類似したクラスを推薦することが段階である．既存のコード推薦システム Selene との目的なので，本研究のシステムとは推薦の目的が異な比較評価の結果次第では，リポジトリの改良も必要とる．よって我々が提案した手法を用いる必要はない．

なる可能性がある．現状のリポジトリは各ソースファ

Mishne らの研究は，API の呼出の並びを記したクイルの単語頻度ベクトルの集合である．よって複数のエリを基に推薦を行う．開発者自身がクエリを入力すモジュールにまたがる一連の処理が分散している場合るため，本研究のように履歴を導入するのは難しいともあるため，関心度に基づいたクエリを作成した効果思われる．そしてクエリに開発者が行いたい一連の処が出ない可能性も考えられるからである．そして再現理の全てが含まれているかは，開発者の入力次第で率を基にパラメータ調整をし，その再現率を評価指標ある．

として Selene と比較をするため，評価の信頼性の問題がある．そのため，将来的には再現率による推薦シ

7 まとめ，評価方法と今後の課題ステムの評価と実際の開発者の開発効率との相関を7. 1 まとめ検証する必要がある．

本研究の貢献は以下の点である.

1. 統合開発環境の編集操作履歴を用いた，背景情報のクエリ作成に対する活用

2. 複数の開発者のコード編集履歴を用いた，本研
究のシステムのパラメータ調整

1 のためにまず，統合開発環境の編集操作履歴から背景情報抽出のための指標として関心度を定めた．そしてリポジトリへの検索のクエリである単語頻度ベクトルに，関心度で重みを付けた．2 のためにはまず，複数の開発者のコード編集履歴から問題セットと正解セットを作成した．正解セットと推薦コード断片の単

参 考 文 献[ 1 ] Black Duck Software, Inc.: Ohloh. https://www.ohloh.net/.
[ 2 ] Holmes, R., Walker, R. J., and Murphy, G. C.:
Approximate structural context matching: An approach to recommend relevant examples, Software Engineering, IEEE Transactions on, Vol. 32,No. 12(2006), pp. 952–970.
[ 3 ] Hummel, O., Janjic, W., and Atkinson, C.:
Code conjurer: Pulling reusable software out of thin
air, Software, IEEE, Vol. 25, No. 5(2008), pp. 45–52.
[ 4 ] Kersten, M. and Murphy, G. C.: Using task

context to improve programmer productivity, Proceedings of the 14th ACM SIGSOFT international
symposium on Foundations of software engineering,ACM, 2006, pp. 1–11.
[ 5 ] Mandelin, D., Xu, L., Bodı́k, R., and Kimelman, D.: Jungloid mining: helping to navigate theAPI jungle, ACM SIGPLAN Notices, Vol. 40, No. 6,ACM, 2005, pp. 48–61.
[ 6 ] Mishne, A., Shoham, S., and Yahav, E.:
Typestate-based semantic code search over partial programs, ACM SIGPLAN Notices, Vol. 47,No. 10(2012), pp. 997–1016.
[ 7 ] Murakami, N. and Masuhara, H.: Optimizing a search-based code recommendation system,Recommendation Systems for Software Engineering(RSSE), 2012 Third International Workshop on,IEEE, 2012, pp. 68–72.
[ 8 ] Robbes, R. and Lanza, M.: How program history
can improve code completion, Automated SoftwareEngineering, 2008. ASE 2008. 23rd IEEE/ACM

International Conference on, IEEE, 2008, pp. 317–326.
[ 9 ] Sawadsky, N., Murphy, G. C., and Jiresal, R.:
Reverb: recommending code-related web pages,
Proceedings of the 2013 International Conference on Software Engineering, IEEE Press, 2013,
pp. 812–821.
[10] Takano, A.: Association computation for information access, Discovery Science, Springer, 2003,
pp. 33–44.
[11] Watanabe, T. and Masuhara, H.: A spontaneous code recommendation tool based on associative search, Proceedings of the 3rd International
Workshop on Search-Driven Development: Users,Infrastructure, Tools, and Evaluation, ACM, 2011,
pp. 17–20.
[12] 高野明彦, 西岡真吾, 丹羽芳樹: 連想に基づく情報ア
クセス技術: 汎用連想計算エンジン GETA を用いて, 情報の科学と技術, Vol. 54, No. 12(2004), pp. 634–639.