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

編集履歴から算出した開発者の関心度に基づくコード補完
Liao Ziyang

丸山勝久

近年の統合開発環境は，過去に記述された大量のソースコードから得られる集合知を活用することで，開発者が作成中のソースコード記述において使用する可能性の高いメソッドをより優先的に推薦するコード補完機能を提供している．このような統計データに基づく手法は開発者全体の傾向に合わせたコード補完に適している反面，開発者個人に対して適切な補完候補を提供できるとはかぎらない．本論文では，開発者が過去にソースコードを記述した際の編集履歴を活用することで開発者の関心度を算出し，それに基づき開発者に提示される補完候補の順番を並び替える手法を提案する．この手法を Eclipse プラグインとして実装したシステムを用いることで，それぞれの開発者に適したコード補完が実現でき，プログラム作成における生産性の向上が期待できる．

grated Development Environment）では，コード補1 はじめに完を主要な機能のひとつとしている [10] [13]．たとえ

ソースコードを記述する際，開発者は効率よくプ

ば，Eclipse は，特定のインスタンスを格納した変数ログラムを作成するために，ライブラリやフレームを入力するだけで，そのインスタンスが提供するメワークに存在するクラスやメソッドを再利用して開ソッドの一覧を提示するコード補完を提供している．

発を行う．しかしながら，開発者がすべてのクラス名

開発者は，利用したいメソッドの呼出しコードを正確やメソッド名をあらかじめ覚えておくことは不可能に入力する必要はなく，提示された補完候補の中からである．このため，どのようなクラスやメソッドがフ適切なメソッドを選択するだけでよい．本論文では，レームワークやライブラリに存在するのかを，開発このようなインスタンスへの参照をトリガーとした者は再利用時に調べる必要がある．文献 [7] では，開メソッド呼出しに関するコード補完を対象とする．

発者が Web を利用して検索するクエリーの 34.2%はここで，Eclipse が従来から備えているコード補完API（Application Programming Interface）に関すでは，参照されるインスタンスの型（インスタンスがるものであり，そのようなクエリーの 64.1%が実際の属するクラス）に基づき，単純にメソッドの一覧を提API 名と違う名前で検索されているという事実を報示する．このため，選択される可能性の高いメソッド告している．さらに，再使用したいクラス名やメソッがより優先的に（メソッド選択ウィンドウにおいて上ド名が長いと，それを正確に入力するのは面倒であ位に）提示されるとはかぎらない．このため，膨大なる．クラスやメソッドの再利用を促進するためには，数のメソッドを提供しているインスタンスが参照されクラスやメソッドを探す手間やそれらの名前を入力すた場合に，開発者が適切なメソッドを選択する手間はる手間を削減する必要がある．

大きい [2] [5]．

これに対して，多くの統合開発環境（IDE: Inte-

このような背景を踏まえ，データマイニング技術

Code Completion Using Developer’s Interests basedon Edit History.
Ziyang Liao, Katsuhisa Maruyama, 立命館大学情報理 工 学 部, Department of Computer Science, Ritsumeikan University.

を用いてメソッド呼出しコードを補完する手法やシステムがいくつも提案されている [1] [4] [8] [9] [11] [14]．
これらの手法やシステムでは，大量のソースコードを集合知として扱うことで，一般的な状況下において記述される可能性の高いコードを予測し，その予測に基づきコードを補完する．このような集合知の活用は，開発者全体の傾向に合わせたコード補完の実現に適している．しかしながら，特定の開発チームや開発者個人に対するコード補完という観点からは必ずしも高い精度が得られるとはかぎらない．
本論文では，開発者がソースコードを作成した際の編集履歴を活用することで，開発者の特性や状況をリアルタイムに反映する仕組みを組み込んだコード補完手法と，それを Eclipse プラグインとして実装

図1

Content Assist の動作例したシステムを提案する．本手法では，開発者の特性や状況を，開発者が特定のメソッドをどのように使用しているかという視点から算出した関心度で捉える．
その上で，それぞれのメソッドに対する個々の開発者の関心度に基づき，コード補完時に選択される可能性の高いメソッドをより優先的に提示するように，メソッド呼出しにおける補完候補の一覧を並び替える．
本システムを用いることで，開発者に適したコード補完が実現でき，プログラム作成における生産性の向上が期待できる．
以下，2 章で Eclipse に搭載されているコード補完

図2

Code Recommender の動作例

システムを紹介し，それらの問題点を述べる．その後，3 章で開発者の関心度に基づくコード補完手法とト順に提示されるので，補完したいコードを選択すそのシステムを提案する．最後に，4 章でまとめと今る．選択されたコードが，エディタのカーソルの位置後の課題を述べる．に挿入される．
図 1 に，ECA の動作例を示す．変数 map に格納さ2 コード補完システム

れている HashMap（java.utilHashMap）クラスのイ

本章では，既存のコード補完システムを紹介し，そンスタンスへの参照に対して，そのクラスが提供するの問題点を示す．

メソッドの一覧が補完候補として提示されている．

2. 1. 2 Code Recommenders
2. 1 既存のコード補完システム
ここでは，Eclipse に搭載されている Content Assistと Code Recommenders を紹介する．

Eclipse Code Recommenders（以降，ECR） [4] では，既存のソースコードに登場するメソッドの利用パ
ターンの統計データに基づき，補完候補の順位付けを

2. 1. 1 Content Assist行う．これにより，開発者がより選択する可能性の高

Eclipse Content Assist（以降，ECA） [6] は，開発いメソッドを補完候補の上位に提示する．

者が記述中のコードに応じて，それに関連するコード

図 2 に，ECR の動作例を示す．図 1 とは異なり，補完を支援する．Eclipse の Java エディタにおいて，HashMap が提供するメソッドの一覧が順位付けされ特定のコード上にカーソルを置き，「Ctrl + Space」をている．

押すことでコード補完が起動する．起動によりポップアップウィンドウ上に補完候補の一覧がアルファベッ2. 2 問題点

統計的に処理すると，開発者間の特性の違いが打ち消ECA のようなアルファベット順に提示するコードされることがある．これにより，複数の開発者がそれ補完では，開発者に対する支援として十分とはいえなぞれ頻繁に利用しているメソッドが補完候補の上位にい．たとえば，図 1 と図 2 に示した HashMap には 24提示されないという望ましくない状況が発生する．

個のメソッドがあり，親クラスのメソッドやフィールさらに，メソッドの利用は時間的な局所性をもつ．

ドも含めると，提示される補完候補は全部で 33 個とたとえば，ある開発者が（Java Swing 対応の）GUIなる．同様に，String（java.lang.String）クラスアプリケーションを作成している場合を考える．そのには 67 個のメソッドがあり，提示される補完候補は際，同じメニュー（JMenu クラスのインスタンス）に全部で 76 個となる．このような状況において，ECA対して，複数のメニュー項目（JMenuItem クラスのでは，開発者が利用したいメソッドが下位に提示されインスタンス）を連続的に付け加えることは多い．こることが頻繁に発生し，そのメソッドを選択するための場合，JMenu の add(JMenuItem) メソッドが繰りに多くの時間を費やすことになる．

返し利用される．また，複数のボタン（JButton クラ

これに対して，ECR では，メソッドの利用パタースから生成されたインスタンス群）に対して，それらンの統計データに基づき，選択される可能性が高いメの色やアクションをまとめて設定することも多い．こソッドをより上位に提示する．これにより，ECA にの場合，JButton の setForeground(Color) メソッ

おいて問題であった，メソッドの選択に費やす手間ドや setAction(Action) メソッドが繰り返し利用さを削減することが可能となる．たとえば，ECA におれる．メソッドの利用が連続的であるという局所性

いて 20 番目に提示される HashMap の put(String,は，あるメソッドが利用された場合には，そのメソッString) メソッドは，ECR において 1 番目に提示さドが直後にも利用される可能性が高いことを指してれる（図 2 を参照）．また，String において頻繁にいる．反対に，利用されなくなったメソッドが再度利利用される indexOf(int) メソッドは 2 番目に表示用される可能性は低い．コード補完の効果を高めるたされる（ECA では 23 番目に提示される）．

めには，このような時間的な局所性を考慮する方が一方，ECR にも問題が残されている．コード補完

よい．しかしながら，ECR は，メソッドの利用に関を実現するためには統計的データが必須であり，現するソースコード上の連続性は考慮しているものの，時点では Eclipse API と Java 標準 API の一部しか時間的な連続性は考慮していない．このため，かつてコード補完の対象としていない．つまり，普及していは頻繁に利用されていたが，最近あまり利用されないないライブラリや開発者が独自に作成したライブラメソッドが補完候補として上位に提示されるという望リに対して，ECR は役に立たない．また，用意されましくない状況が発生する．ている統計データはすべての ECR に共通であり，そ以上をまとめると，アルファベット順に補完候補をのデータが個々の開発者の特性や状況を代表している

表示する ECA は，プログラム作成における生産性向とは限らない．

上という観点で十分な効果をもつとはいえない．ま一般的に，プログラミングの習慣や好みは空間的なた，メソッドの利用パターンに関する統計データに基局所性をもち，同じ開発者は特定のクラスに対して同づく ECR は，開発者全体の傾向に合わせたコード補じメソッドを使用する傾向にある．反対に，異なる開完という観点では効果が得られるものの，開発者固有発者は，たとえ同じクラスを利用していたとしても，の特性や状況を反映させたコード補完には対応でき異なるメソッドを使用する可能性がある．たとえば，ていない．

String のメソッドを呼び出して同じ文字列処理を実現する方法はいくつも存在し，開発者によって利用す3 関心度に基づくコード補完るメソッドが異なることはめずらしくない．このよう本章では，従来のコード補完手法の問題点に対処しな場合において，開発者を区別せずに利用パターンをた手法を提案し，その手法を実装したシステムについて説明する．

きいほど DOI の値が高くなるようにしている．単純な比例関係ではなく平方根を採用したのは，F req の

3. 1 コード補完手法

値が大きくなるにつれ，DOI の値の増加率を抑える

提案手法は，2. 2 節で述べた問題点を解決するためためである．α は F req による DOI の増加に対するに，既に存在するソースコードではなく，開発者が影響を調整する係数である．α = 0 のときその影響はソースコードを記述した際の編集履歴を用いる．編

最大となり，α の値を大きくするとその影響は相対的集履歴とは，開発者が過去に実行した編集操作（開発に小さくなる．

者を表す識別子，編集が行われた時刻，編集内容）をまた，2. 2 節で述べたメソッドの利用は局所的であ集めたものを指す [12]．編集操作の取得には，Eclipseるという前提に基づき，Edit の値が増加するにつれ，プラグインの ChangeTracker [3] を活用する．このプ

DOI の値を減少させることにしている．β は F req

ラグインは，Eclipse の Java エディタ上のすべてのによる DOI の減少に対する影響を調整する係数であ編集操作をバックグラウンドで自動的に捕捉する．本る．β = 0 のときその影響は最大となり，β の値を大手法では，エディタ上のコードを直接書き換える編集きくするとその影響は相対的に小さくなる．

操作（タイピングによる文字列の挿入および削除，文本システムの実装では，使用頻度にできるだけ敏感字列のカット/コピー/ペースト，コード補完や簡易修正による文字列の挿入や削除）のみを利用する †1 ．となるように α = 0 とした．また，予備実験の結果

本手法では，編集操作が記録されるたびにそれを分度が減少しないように β = 100 とした．c は DOI の析することで，それぞれのメソッドに対する開発者の値が極めて小さくなる（数値が切り捨てられる）こと関心度をリアルタイムに算出する．コード補完では，を避けるために導入した定数である．本システムの実関心度の高いメソッドを補完候補の上位に提示する．

装では c = 10, 000 とした．

メソッド m に対する開発者 dev の関心度は，次に示に基づき，経過した編集数が少ないときに急激に関心編集操作から取得した開発者の識別子に基づき，そす 2 つの視点に基づき算出する．

れぞれのメソッドに対する関心度を開発者ごとに独立(1) 使用頻度 F req(dev, m)に算出することで，開発者間の特性の違いが打ち消さ

過去の編集において dev が m を使用した回数をれることを避けることができる．また，経過した編集表す．メソッドの使用とは，dev が m を呼び出数に基づき関心度を算出することで，同じ開発者ですコードを記述する，あるいは，コード補完によあっても，ソースコード記述時の状況の違いを考慮しり m を選択することを指す．

たコード補完が可能となる．

(2) 経過した編集数 Edit(dev, m)
過去の編集において dev が m を最後に使用して3. 2 コード補完システム

から，現時点までに実施された編集操作の総数を提案手法を実現するコード補完システムの概要を指す．

図 3 に示す．以下に，それぞれのモジュールの詳細を

開発者の関心度 DOI(dev, m) は，次に示す式を用いて算出する（c > 0，α ≥ 0，β ≥ 0 である）．

√DOI(dev, m) = c ×

α + F req(dev, m)
β + Edit(dev, m)

一般的に，使用頻度が高いメソッドに対して開発者は強い関心を持つといえる．よって，F req の値が大†1 ファイルのオープンやクローズ，メニュー項目の選択などの編集操作は無視する．

説明する．

3. 2. 1 メソッド特定モジュール
このモジュールは，ChangeTracker の出力する編集操作を監視し，それをリアルタイムに分析することで，開発者が使用（記述あるいは選択）したメソッドを特定する．同時に，現時点での編集操作の総数を数え，特定したメソッドが最後に利用された時点を表すシーケンス番号を記録する．

ChangeTracker には，個々の編集操作をイベントと補を検出する．Java の文法においては，自分以外のインスタンスのメソッドを呼び出す際，必ずドット演算子（「.」）をメソッド呼出しの直前に記述しなければならない．本システムでは，この並び替え後の補完候補情報

記法を利用して，メソッドの名前を検出する．
具体的には，受け取った編集操作の挿入文字列を監視し，それがドット文字の場合，それ以降ChangeTracker

Content Assist

編集操作

補完候補情報メソッド特定モジュールに挿入された文字列の収集を開始する．メソッド
呼出しの引数は必ず右括弧（「(」）で始まるので補完候補並べ替え
モジュール（引数がない場合でも括弧は存在するので），ドッ
ト演算子から右括弧までの間に収集された挿入

メソッド情報文字列を結合したものがメソッドの名前候補とな
メソッド呼出し情報管理モジュール

メソッド
呼出し情報

る．たとえば，開発者が str.chars(); と記述した場合を考える．4 文字目のドット文字に関する

図3

システムの概要

編集操作を受け取り，挿入文字列の収集を開始する．10 文字目に到達した時点で，右括弧に関すしてリアルタイムに通知するモードと，編集操作を履る編集操作を受け取るため，その間に収集した文歴としてまとめてファイルに出力するモードがある．

字列 chars がメソッドの名前候補となる．

本システムでは通知モードを利用して，編集操作を受一方，メソッド呼出しコードが補完された場け取る．この編集操作には，開発者を表す識別子，編合，そのコードがまとめて編集操作の挿入文字列集が行われた時刻，編集が行われた Java ソースファに格納される．この場合でも，挿入文字列に含まイルのパス，ソースコードにおける編集箇所を指すオれる右括弧を探すことで，メソッドの名前を取りフセット値，挿入文字列，削除文字列の情報が記録されている．

出すことが可能である．

(b) メソッド情報を取得する処理

さらに，本システムでは，ChangeTracker から受け検出したメソッドの名前候補から，実際に呼取った（コードを直接書き換える）すべての編集操作び出されるメソッドを特定し，その情報（メソッにシーケンス番号を付与する．これは，現時点までド情報）を取得する．本システムは，編集操作に受け取った編集操作の総数を指す．シーケンス番号の監視においてドット演算子を検出した時点で，は，本システム（が組み込まれた Eclipse）が初めてECA が提供する補完候補情報を取得する．これ起動される際に 0 に初期化される．システム終了時

は，org.eclipse.jdt.ui パッケージに存在すには現時点での変更操作の総数（最新の変更操作のる JavaAllCompletionProposalComputer クラシーケンス番号の値）をファイルに保存し，以降の起スの computeCompletionProposals() メソッド

動時にはファイルに保存した前回の値で初期化する．の返り値から取得可能である．取得した補完候メソッドの特定は大きく，メソッドの名前候補を検補情報 P rop に含まれるメソッド名の一覧とメ出する処理と，メソッドの名前候補からメソッド情報

ソッドの名前候補 name を比較し，一致するもを取得する処理に分けられる．以降，それぞれの処理のが見つかった場合，name を名前とするメソッを説明する．

ド m の特定が完了する．一致するものが見つか(a) メソッドの名前候補を検出する処理
開発者が記述中のソースコードにおいて，メソッド呼出しコードを見つけ，メソッドの名前候らなかった場合には，name を破棄し，編集操作の監視を継続する．
ここで，メソッドの名前だけでなく，すべての引数の型まで決定できた場合には，m を一意に特定することが可能である †2 ．しかしながら，• 現時点までに M が使用された回数 T imes

記述中の（不完全な）ソースコードにおいて引数• 現時点での M に対する関心度 Doiの型を決定することは困難である．また，開発者• M の使用履歴（編集操作の集合）History

が補完候補からメソッドを選択した場合，メソッ

デ ー タ ベ ー ス で は ，(N ame, F qn, Dev) を 検 索

ドは一意に特定されているはずである．しかしキーとしてメソッド呼出し情報（このデータ項目ながら，編集操作の挿入文字列だけで，これを判を M [N ame, F qn, Dev] とおく）を管理する．N ame

断することはできない．これら 2 つの理由から，と F qn はメソッド特定モジュールから渡されるメソッ

本システムではメソッドの名前だけを用いて mド情報 I(name, f qn, op, seq) から抜き出したメソッを特定している．

ドの名前 name とそのメソッドが所属するクラスの• M が最後に使用された時点を表す番号 Latest

このような設計判断により，メソッドがオー

完全限定名 f qn である．Dev は，編集操作 op に保バーロード関係を有する場合，name を名前とす存されている開発者を表す識別子を指す．検索による複数のメソッドが P rop において一致する可能り，データベースに M [N ame, F qn, Dev] が見つか性がある．複数のメソッドが一致した場合には，らない場合には，(N ame, F qn, Dev) を検索キーとす

それらのメソッドが所属するクラスの情報をそれるデータ項目を新規に作成し，その T imes と Latest

ぞれ P rop から抜きだし，同じクラスに属するメの両方に初期値 0 を格納する．これにより，データソッドはひとつに統合する．異なるクラスに所属ベースには必ず M [N ame, F qn, Dev] が存在するこするメソッドは，それらを統合せずに，複数のメとが保証される．

ソッドとして扱うことにする．

いま，開発者 d が利用したメソッド m（名前を n，いま，name を名前とする m の所属するクラスのクラスの完全限定名を f とする）のメソッド呼出し情

完全限定名を f qn とする．また，m の特定に成功し報を格納したデータ項目を Mq = M [n, f, d] とおく．

た際の編集操作 op（m を呼び出すコード記述の最初

さらに，Mq の T imes と Latest の値をそれぞれ Tqの編集操作，あるいは，補完候補 m が選択された際にと Lq とする．3. 1 節で述べた使用頻度と経過した編文字列を挿入する編集操作）のシーケンス番号を seq

集数は，次の式を用いてそれぞれ算出する．とする．このモジュールは，m の特定に成功するたび使用頻度 F req(d, m) = Tq + 1に，m に関するメソッド情報 I(name, f qn, op, seq)

経過した編集数 Edit(d, m) = Seq − Lqをメソッド呼出し情報管理モジュールに引き渡す．

3. 2. 2 メソッド呼出し情報管理モジュール

Seq は I(name, f qn, op, seq) から抜き出したシーケ
ンス番号 seq を指す．

このモジュールは，メソッド特定モジュールから渡このようにして求めた F req(d, m) と Edit(d, m)

されたメソッド情報に基づき，メソッド呼出し情報をから関心度 DOI(d, m) を算出し，その値を Mq の収集し，それをデータベース（実際には，マップとDoi に格納する．同時に，F req(d, m) の値を Mq のファイルで実装）に格納する．メソッド呼出し情報に

T imes，Seq の値を Mq の Latest に上書きする．さおけるデータ項目の構造を以下に示す．

らに，I(name, f qn, op, seq) の編集操作 op を Mq の• 開発者が使用したメソッド M の名前 N ame

History に追加する．これにより，メソッド呼出し情• M が所属するクラスの完全限定名 F qn

報の更新（あるいは作成）が完了する．

• M を使用した開発者を表す識別子 Dev†2 メソッドがオーバライド関係を有する場合，実際に呼び出されるメソッドを静的に一意に決定することはできない．ただし，インスタンス参照の宣言型に基づ
き，P rop にはオーバライドメソッドのうちのひとつだけが提示される．よって，m は一意に決定できる．

図 5 に示すソースコードを開発者が上部から順番に記述し，コード補完を起動した際にデータベースに格納されているメソッド呼出し情報を XML 形式で出力した結果を図 4 に示す．<proposal>タグに囲まれている内容がひとつのデータ項目に対応する．たと図4

メソッド呼出し情報を XML 形式で出力した結果

その後，メソッド呼出し情報を格納するデータベースにおいて，この検索キーに一致するデータ項目

Mq [name, f qn, dev] を検索する．データ項目が見つかった場合，List 内の m に Mq の関心度 Doi の値を割り付ける．見つからなかった場合，m には関心度の最小値 0 を割り付ける．
すべてのメソッドに関心度が割り付けられた List に
図5

開発者が記述したソースコードの例

対して，関心度の大きい順に並び替えを適用する．並び替えた結果を P rop に反映させることで，並び替え後のえば，CharSequence クラスの chars() メソッドは，補完候補を開発者に提示する．ECA を拡張する際には，現時点までに 2 回使用されており，それが最後に使

org.eclipse.jdt.ui.text.java パッケージに存在用された時点を表すシーケンス番号は 54 である．まする IJavaCompletionProposalComputer インタフ

た，現時点での関心度の値は 101 となっている．

ェースを実装し，それを拡張ポイント org.eclipse.

3. 2. 3 補完候補並べ替えモジュール

jdt.ui.javaCompletionProposalComputer に登録

このモジュールでは，開発者 dev がコード補完をすればよい．

起動した（「Ctrl + Space」を押した）際，ECA の提開発者が図 5 に示すソースコードを記述中に，変数供する補完候補情報 P opr を取得し，補完候補としてstr に対してコード補完を起動した際の動作例を図 6提示されるメソッドの一覧 List を作成する．List 内に示す．関心度に基づく補完候補の提示結果 (c) を見の各メソッド m に対して，メソッドの名前 name とると，従来の (a) や (b) の提示結果と異なり，図 5 のそのメソッドが所属するクラスの完全限定名 f qn をソースコードにおいて，より直前により頻繁に使用さ取り出し，検索キー (name, f qn, dev) を作成する †3 ．

れたメソッドがより上位に提示されていることが分†3 ChangeTracker と同様に，dev は Eclipse の現在の使用者情報から取得する．

かる．

(a) Content Assist

図6(b) Code Recommenders(c) 関⼼度(DOI)

java.lang.String のインスタンス参照に対するコード補完の動作例

3. 3 議論発を始める前に，それぞれのメソッドに対する関心度

図 6 に示すように，提案手法は開発者の編集履歴を擬似的に設定しておくことができる．

を反映したコード補完を実現している．また，本手法では，従来のデータマイニング技術に基づくコード補4 おわりに完手法のように，あらかじめ既存のソースコードを本論文では，開発者がソースコードを作成した際の大量に収集し，利用パターンを学習させておく必要編集履歴に着目し，開発者の関心度に基づくコード補がない．このため，ECA が起動可能な状況であれば，完手法とそれを実装したシステムを提案した．それぞ開発者が独自に記述した，あるいは，記述中のソースれのメソッドに対する関心度は，(1) 開発者がそのメコードに対しても，開発者の特性や状況に対応したソッドを使用した回数と，(2) 開発者がそのメソッドコード補完が可能である．つまり，本システムの適用を最後に使用してから現時点までに経過した編集数で場面は広い．

算出する．関心度をリアルタイムに算出することで，さらに，本手法は，開発者が記述中のソースコードの編集操作をリアルタイムに分析して，メソッドの使開発者の特性や状況をより反映した補完候補の提示が可能である．

用を補完候補の提示結果に反映させている．このた今後の課題として，実際の開発者を用いた被験者実め，開発者の特性や状況に対して即座に追従するコー験の実施があげられる．我々は，いくつかのサンプルド補完が実現できているといえる．

コードを用いて，本システムの有用性を確認してい一方，本手法では，個々の開発者が記述したソースる．しかしながら，本システムの効果を明確に裏付けコードのみに基づき関心度を算出している．このたる実験データは存在しない．また，現在の関心度の算め，開発の初期段階などにおいて開発者が記述した

出式は著者らの直感と経験に基づいて定義されておソースコードが少ない場合には，コード補完の効果り，その妥当性に関する評価も行っていない．被験者がそれほど期待できない．これは，本システムにお実験を通して，本システムの有用性と関心度の算出式いて，一度も使用されていないメソッドの関心度を 0のチューニングを実施していく予定である．としていることに起因する．

さらに，本システムの実装には，一部不完全な部

この問題に対する解決策として，ECR における統分が存在する．たとえば，ペーストにメソッド呼出計データを，それぞれのメソッドの関心度の初期値にしコードが挿入された場合には ECA が起動しないた反映させることを考えている．また，特定のソース

め，このコード記述に含まれるメソッドの特定に失敗コード集合を用意し，ソースコードの編集時刻順に並する．また，メソッド特定の精度を向上させるためにべ，さらにソースコードを上部から記述したと仮定しは，メソッドの引数の型の決定が必須である．今後，て，編集履歴を擬似的に作成することが考えられる．

本システムの実装の改良も実施する予定である．

擬似的な編集履歴を用いることで，開発者が実際に開謝辞 本研究に関してご討論頂きました，立命館大

学の紙名哲生氏に感謝いたします．本研究の一部は，科研費（15H02685）の助成を受けたものである．
参 考 文 献[ 1 ] Akbar, R. J., Omori, T., and Maruyama, K.:
Mining API Usage Patterns by Applying Method
Categorization to Improve Code Completion, IEICE Transactions on Information and Systems,
Vol. 97, No. 5(2014), pp. 1069–1083.
[ 2 ] Bruch, M., Monperrus, M., and Mezini, M.:
Learning from Examples to Improve Code Completion Systems, Proc. Int’l Symp. Foundations ofSoftware Engineering (FSE’09), 2009, pp. 213–222.
[ 3 ] ChangeTracker: https://github.com/
katsuhisamaruyama/changetracker.
[ 4 ] Code Recommenders: http://www.eclipse.org/recommenders/.
[ 5 ] Duala-Ekoko, E. and Robillard, M. P.: Asking
and Answering Questions about Unfamiliar APIs:
An Exploratory Study, Proc. Int’l Conf. Software
Engineering (ICSE’12), 2012, pp. 266–276.
[ 6 ] Eclipse: http://www.eclipse.org/.
[ 7 ] Hoﬀmann, R., Fogarty, J., and Weld, D. S.:
Assieme: Finding and Leveraging Implicit References in a Web Search Interface for Programmers,
Proc. Symp. User Interface Software and Technology (UIST’07), 2007, pp. 13–22.

[ 8 ] Hou, D. and Pletcher, D. M.: An Evaluation of the Strategies of Sorting, Filtering, andGrouping API Methods for Code Completion, Proc.
Int’l Conf. Software Maintenance (ICSM’11), 2011,
pp. 233–242.
[ 9 ] Hsu, S.-K. and Lin, S.-J.: MACs: Mining API
Code Snippets for Code Reuse, Expert Systems withApplications, Vol. 38(2010), pp. 7291–7301.
[10] Murphy, G. C., Kersten, M., and Findlater,
L.: How Are Java Software Developers Using theEclipse IDE?, IEEE Software, Vol. 23, No. 4(2006),
pp. 76–83.
[11] Nguyen, A. T., Nguyen, T. T., Nguyen, H. A.,
Tamrawi, A., Nguyen, H. V., Al-Kofahi, J., andNguyen, T. N.: Graph-Based Pattern-Oriented,
Context-Sensitive Source Code Completion, Proc.
Int’l Conf. Software Engineering (ICSE’12), 2012,
pp. 69–79.
[12] 大森隆行, 丸山勝久: 開発者による編集操作に基づくソースコード変更抽出, 情報処理学会論文誌, Vol. 49,
No. 7(2008), pp. 2349–2359.
[13] Robbes, R. and Lanza, M.: How Program History Can Improve Code Completion, Proc. Int’lConf. Automated Software Engineering (ASE’08),
2008, pp. 317–326.
[14] Zhong, H., Xie, T., Zhang, L., Pei, J., and Mei,
H.: MAPO: Mining and Recommending API Usage
Patterns, Proc. Euro. Conf. Object-Oriented Programming (ECOOP’09), 2009, pp. 318–343.