情報処理学会論文誌

Vol.56 No.2 692–700 (Feb. 2015)

API 呼び出しとメソッド周辺の識別子の実績に基づいた
API 集合推薦手法
早瀬 康裕1,a)

鬼塚 勇弥2

山本 哲男3,b)

石尾 隆2,c)

井上 克郎2,d)

受付日 2014年5月19日, 採録日 2014年11月10日

概要：現代の多くのソフトウェア開発では，膨大なライブラリから必要な API を選び出し，それをどのよ
うに組み合わせればよいかを調べなければならない．本研究では，開発者が新規作成したいメソッドの名前を記述したときに，そのメソッド本体で使用される可能性のある API の集合を推薦することで，API の選択を支援する手法を提案する．使用される可能性のある API の推薦には大規模なソースコード集合から抽出した相関ルールを使用する．相関ルールには，メソッド名などの識別子から得た情報と，使用されたAPI との関係が記録されている．本手法によって開発者に有用な API 集合を推薦できるかを調査したところ，推薦の上位に適切な API が含まれていることを確認した一方，手法に改善の余地があることも分かった．
キーワード：API，メソッド本体，相関ルールマイニング，コード補完

Recommending API Sets for a New Method
Based on Surrounding Identifiers and API Usage History
Yasuhiro Hayase1,a) Yuya Onizuka2 Tetsuo Yamamoto3,b)Takashi Ishio2,c) Katsuro Inoue2,d)Received: May 19, 2014, Accepted: November 10, 2014

Abstract: In modern software development, developers have to select and combine appropriate APIs fromvast amount of software libraries to implement features. This paper proposes an approach that takes as
input a method name which a developer is attempting to create, and suggests APIs that are likely used as atemplate of method body. By using the template as a reference and/or editing the template, the developer
can write the method body. Our approach generates templates from association rules that associate APIs
with identiﬁers such as method names, class names, and ﬁeld names included in a large set of source ﬁles.
Keywords: API, method body, association rule mining, code completion

1

2

3

a)
b)
c)
d)

1. まえがき
筑波大学システム情報系
Faculty of Engineering, Information and Systems, Universityof Tsukuba, Tsukuba, Iraraki 305–8573, Japan
大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology,
Osaka University, Suita, Osaka 565–0871, Japan
日本大学工学部情報工学科
Department of Computer Science, College of Engineering,
Nihon University, Koriyama, Fukushima 963–8642, Japanhayase@cs.tsukuba.ac.jp
tetsuo@cs.ce.nihon-u.ac.jp
ishio@ist.osaka-u.ac.jp
inoue@ist.osaka-u.ac.jp

c 2015 Information Processing Society of Japan

高品質なソフトウェアを短期間で開発することが社会から求められており，それに応えるための方法の 1 つとして過去に開発されたソフトウェアの再利用が行われている．社会的要求の背景には，社会基盤がソフトウェアへ依存する度合いが高まっていることや，急速な技術の進歩に遅れをとらないために納期が短くなっていることなどがある．過去に開発されたソフトウェアは新規に開発するソフ
トウェアよりも品質が高いことが多いため，ソフトウェア

692

情報処理学会論文誌

Vol.56 No.2 692–700 (Feb. 2015)の再利用は開発期間の短縮とソフトウェアの品質とを両立

ソッド本体での API の呼び出しと，メソッド名やクラス名させる方法だと考えられている．ソフトウェアの再利用になどの識別子との間の相関ルールを，既存のソースコード

は，目的に適った再利用対象ソフトウェアを発見し，それ集合から学習する．この相関ルールは，前提部がメソッドを利用する適切な方法を調べる必要があるが，この作業に名やメソッド周辺の識別子（クラス名，フィールド名など）

開発者の手間と時間とを要するという難しさがある．

からなり，帰結部は本体で呼び出される API 集合である．

ソフトウェア再利用の方法の 1 つに，Application Pro-

推薦が行われる状況を満たす相関ルール集合によって，本gramming Interface（API）を通して既存ソフトウェアを体で呼び出される可能性が高い API 集合を得る．開発者

利用する方法がある．多種多様な API を組み合わせて目は推薦された API 集合を見ることで，その API を呼び出的の機能を実装することは，現代的なソフトウェア開発のして使用したり，ライブラリや API の調査の手がかりとし一般的な手順となっている．たとえば多くのウェブアプリ

て利用したりすることができる．

ケーションでは，ウェブアプリケーションフレームワーク

以下，2 章で提案手法を詳説し，3 章で提案手法の実装にに加えて，複数のライブラリ（例：クライアントから送らついて述べる．4 章では提案手法の有効性を評価する実験れるデータを処理するライブラリや，データベースにアクとその結果を示す．5 章で関連研究を紹介し，最後に 6 章

セスするライブラリなど）を組み合わせて利用する．このでまとめと今後の課題について説明する．

ように，ソフトウェア開発者は適切なライブラリとそこで提供されている API を選択し，適切な組合せを発見するという手順を日常的に繰り返している．

2. 提案手法
本章では，開発者が Java のメソッド名までを記述した

現在では多種多様なライブラリが提供されているため，段階で，メソッド本体で使用する可能性が高いと考えられ多くの機能が再利用によって実現できるようになっている

る API の集合（メソッドの雛形）を推薦する手法を提案すが，その一方で適切なライブラリと API を組み合わせてる．提案手法は，Java プログラムの開発者が膨大な API

ソフトウェア開発を行うのは，難しく手間がかかる作業と集合から適切な API を選択する作業を支援することを目なっている．なぜならば，開発者は目的を達成するために的としている．

必要なすべての機能を調べ出し，その機能を提供するライ

図 1 に示すように，提案手法は 2 つのステップからな

ブラリを見つけ，そのライブラリの API を組み合わせて利る．ステップ 1 はメソッド本体と識別子の関連の学習で用する方法を調べなければならないためである．さらに，あり，推薦の実施に先立って 1 度だけ実施される．学習にライブラリには同時に使用することのできない組合せが存

よって得られた知識は，相関ルールの形でデータベースに在するため，個々の機能を提供するライブラリを見つけた

記録される．ステップ 2 はメソッド本体の雛形の推薦であとしても，目的を達成できるとは限らない．

り，開発者が推薦を要求するたびに実行される．雛形の推ライブラリや API を利用することの難しさを軽減するこ

薦では，推薦が要求されたソースコードの状態を用いて，とを目的として，開発者がこれから書こうとしているコー

事前に構築したルール DB を参照し，雛形を生成する．雛ドを，直前に書かれた文の並びから予測して推薦する手法

形は複数個生成されるため，開発者には雛形のリストが提が提案されている．Bunch ら [5] は，統合開発環境（IDE）

示される．

のコード補完が大量の候補を出力するために選択が難しい

2 つのステップの詳細を，2.1 節と 2.2 節で述べる．

という問題に着目し，補完が実行された箇所の直前で呼び出されている API を利用して補完候補を絞り込む手法を提案した．同様に直前の API 呼び出しを利用することで，2.1 ステップ 1：メソッド本体と識別子の関連の学習
ステップ 1 では，既存のソースコード集合を分析するこ山本ら [14] は，具体的かつ大きなコード片を推薦する手法とで，メソッド内での API 利用とメソッドに関連する識別を提案した．これらの 2 つの手法では，どちらもいくつか

子との間の関連を，相関ルールの形で抽出する．本ステッの API 呼び出しが直前に書かれていることを前提として

プは 2 つのサブステップからなる（図 1）．サブステップいるため，開発者がどのようなライブラリや API を使用す

1-a では，相関ルールマイニングに必要となるトランザク

るかを決められない状況では，適用することができない．

ション集合を構築する．サブステップ 1-b では，構築した

そこで本研究では，Java プログラムで新規にメソッド

トランザクション集合に対して相関ルールマイニングを行を作成しようとしている開発者に対して，メソッド本体がい，その結果から推薦に使用できる形式の相関ルールのみ

書かれておらずメソッド名までのみが記述されている状態を取り出して，ルール DB に保存する．

で，メソッド本体で使用する可能性の高い API 集合を推薦

2.1.1 サブステップ 1-a：トランザクション集合の構築する手法を提案する．推薦には API 呼び出しに関連する

このサブステップでは，相関ルールマイニングを行う準相関ルール [4] を利用する．具体的には，メソッド名とメ

備として，相関ルールマイニングの入力となるトランザク

ソッド本体の間に強い関連がある [6], [9] ことに着目し，メション集合を構築する．ソースコード集合内の 1 つのメ

c 2015 Information Processing Society of Japan


693

情報処理学会論文誌

Vol.56 No.2 692–700 (Feb. 2015)

図 1

提案手法の全体像

Fig. 1 Overview of proposed method.
表 1 トランザクションの要素となる項目

Table 1 Elements in a transaction.

割する．次に，単語列の先頭の単語が既知の動詞であるかを 3 つの辞書（OpenNLP [2]，WordNet [3]，独自の辞書）

項目名

説明

を検索して判定し，既知の動詞であった場合にはそれをメ

クラス名

メソッドを所有するクラスの名前

ソッド名の動詞として抽出する．独自の辞書には，我々の親クラス名

メソッドを所有するクラスの経験からメソッド名において実質的な動詞として使われて親クラスの名前
インタフェース名

メソッドを所有するクラスが実装するインタフェースの名前

フィールド名呼び出しメソッドいると判断される 7 つの単語 to，new，init，calc，cleanup，

setup，shutdown が登録されている．先頭の単語が動詞とメソッド本体がアクセスする

して判断された場合には，残る単語列から同じ辞書を用い

フィールドの名前て名詞と判定される単語の連続を取り出し，これを目的語

メソッド本体で呼び出しているメソッド

として抽出する．

（クラスの完全限定名とメソッド名とを，

2.1.2 サブステップ 1-b：必要な相関ルールの抽出

ピリオドで連結した文字列）
メソッド名の動詞

メソッド名の動詞部

メソッド名の目的語

メソッド名に含まれる名詞節

このサブステップでは，前サブステップで構築したトラ
ンザクション集合に対して相関ルールマイニングを行い，その結果から API 推薦に使用できる形式の相関ルールのソッド定義が，1 つのトランザクションに対応する．トラ

みを取り出して，雛形 DB に保存する．

ンザクションの要素としてソースコードから取得される相関ルール [4] とは，「ある要素の集合 A がトランザク

データを，表 1 に示す．トランザクションの各要素には項ションに出現する場合には，そのトランザクションに別の目の種類を示す接頭辞が付けられるため，同名であってもある要素の集合 B も出現する可能性が高い」という関係を種類が異なる場合には別の要素として区別される．

表すルールであり，A → B と表記される．前者の集合を

トランザクションの要素を取得する方法を説明する．まず，クラス名，親クラス名，インタフェース名，フィールド

前提部，後者の集合を帰結部と呼ぶ．相関ルールには，支持度と確信度と呼ばれる 2 つの指標値がある．

名，呼び出しメソッドの 5 つは，メソッド定義を含むソー相関ルールマイニングは，トランザクション集合にスコードを構文解析および意味解析することによって得ら含まれる任意の要素の組合せに対して相関ルールの関れる．ソースコードの解析には，統合開発環境 Eclipse [1]

係を発見するが，本手法で利用できるのは，帰結部にメの一部である ASTParser を使用する．呼び出しメソッ

ソッド呼び出しを持つ相関ルールのみである．なぜならドの取得では，ASTParser によってメソッドの所属する

ば，本手法で推薦されるのはメソッド内で呼び出されう

クラスを取得し，そのクラスの完全限定名とメソッド名

る API であるため，帰結部にメソッド呼び出し以外のとをピリオドで連結した文字列を生成する．たとえば，

要素があっても推薦時には役立たないためである．そこ

java.util.ArrayList 型の変数に対して add メソッドが呼びで，相関ルールマイニングによって得られる相関ルール

出されている場合，完全限定名とメソッド名をピリオドで集合のうち，{ 呼び出しメソッド以外のアイテム集合 } ⇒連結したうえで，呼び出しメソッドの接頭辞である call:を{ 呼び出しメソッドの集合 } という形式となるもののみを，付与した，call:java.util.ArrayList.add がトランザ

ルール DB に保存する．

クションの要素として抽出される．

2.1.2.1 雛形優先度のパラメータチューニング

残る要素であるメソッド名の動詞と目的語の取得は，

ルール DB を構築した直後に，ステップ 2 の実行に必要

ASTParser によって取得したメソッド名に対して，以下のとなるパラメータのチューニングを行う．チューニングの手順を実施する．まず，Java の標準的な命名方法である

説明にはステップ 2 の詳細についての知識が必要となるた

Camel Case ルールに従って，メソッド名を単語列へと分め，手順の詳細は，2.2.3.1 で述べる．

c 2015 Information Processing Society of Japan


694

情報処理学会論文誌

Vol.56 No.2 692–700 (Feb. 2015)

2.2 ステップ 2：メソッド本体の雛形の推薦

れぞれの相関ルールから帰結部を取り出してメソッド本体

本ステップは，メソッド名のみが記述された状態のソーの雛形を作る．一般に，検索では複数のルールが発見されスコードがあるときに，開発者に対して，メソッド本体で呼るため，雛形もまた複数のものが生成される．そのため，びだされる可能性が高い API の集合（雛形）のリストを提雛形の集合は適切な順序で並べ替え，雛形のリストとして示し，メソッド本体の開発を支援する．本ステップは，3 つ開発者に提示される．

のサブステップ (2-a) 推薦コンテキストの取得，(2-b) デー
タベースの検索，(2-c) 候補の提示，からなる．まず (2-a)

雛形は，呼び出しメソッドの集合そのままであるため，特別な処理は行わない．

では，推薦が行われるメソッドの周辺から識別子を収集し，雛形の並べ替えでは，開発者が使用する可能性が高い雛推薦コンテキストとして次のサブステップに渡す．(2-b)

形を上位に置く必要がある．そこでいくつかの基準を組みでは推薦コンテキストを用いてルール DB を検索し，推薦合わせた優先度を設定し，その値の大きい順にリストを並する状況に合致する相関ルールを発見する．(2-c) では，各

べ替えることとする．優先度の計算には，相関ルールの性

相関ルールの帰結部にあるメソッド呼び出しの集合を雛形質である以下の 4 つの変数を用いる．

とし，適切な並べ替えを行ったうえで開発者に提示する．

Br ：支持度

以下，各サブステップの詳細を説明する．

2.2.1 サブステップ 2-a：推薦コンテキストの取得
このサブステップでは，推薦が行われたメソッドの周辺から情報を収集し，次のサブステップ (2-b) へと引き渡す．

Cr ：確信度
Nr ：前提部の要素数
Mr ：帰結部の各呼び出しメソッドの IDF [8] の総和（学習に用いたメソッド全体を文書集合とする）

取得するデータは表 2 に示す 6 項目である．これは表 1

各指標を採用した理由を説明する．Br 支持度と Cr 確信に示した項目と似ているが，メソッド本体が存在しないこ度は，相関ルールの信頼性を表す指標であり，どちらの指とに起因して 2 つの違いがある．1 点目は呼び出しメソッ

標も高い値であるほど帰結部が成り立つ可能性が高いと考ドが含まれていないことであり，2 点目はフィールド名がえられるためである．前提部の要素数が多いほど，多くのクラスの持つフィールドとなっていることである．項目の要素が推薦の状況にあてはまっていることを示しているた違いを除けば，要素の抽出方法は 2.1.1 項で説明した手順めである．最後の，帰結部の各呼び出しメソッドの IDF のと同じであり，項目の種類ごとに付与する接頭辞も同じ文

総和は，推薦されるメソッド（API）の珍しさを表してお字列を用いる．

り，この値が大きいほど推薦を受けたときに開発者が得る

2.2.2 サブステップ 2-b：データベースの検索

情報量 [11] が多いと考えられるためである．

このサブステップでは，前サブステップから得た推薦コ
ンテキストをクエリとして，ルール DB を検索して推薦の状況に合致する相関ルールを発見する．推薦する状況に合致する相関ルールとは，ルール DB に記録された相関ルー

優先度 Pr は下の式で定義され，4 つの変数を重みつきで足し合わせることによって求める．

Pr = bBr + cCr + nNr + mMr

ルのうち，前提部がクエリの部分集合となっているルール

2.1.2.1 で説明したように，4 つのパラメータ b，c，n，mのことである．推薦が行われる状況は，検索されたルール

はルール DB を構築した直後に行われるパラメータチューの前提部を満たしているため，帰結部が成り立つと推測さニングによって決定する．

れる．

2.2.3.1 雛形優先度のパラメータチューニングの手順

2.2.3 サブステップ 2-c：候補の提示
このサブステップでは，前サブステップで検索されたそ

4 つのパラメータ b，c，n，m を決定するために，ルール DB の構築直後にパラメータチューニングを行う．まず，学習に使用したものとは重複しないソースコード集合

表 2 推薦時にソースコードから取得される項目

Table 2 Elements extracted from source code when suggesting.

（チューニング集合）を用意し，チューニング集合に含まれるすべてのメソッド定義に対して，メソッド本体を削除し

項目名

説明

たうえで雛形の集合を算出する．削除されたメソッド本体

クラス名

メソッドを所有するクラスの名前

で実際に呼び出されていたメソッドの集合を正解とし，雛親クラス名

メソッドを所有するクラスの親クラスの名前

インタフェース名フィールド名メソッドを所有するクラスが実装する

形リストが正解に近づくようなパラメータを発見する．
雛形リストと正解と近さは，下で説明する指標で評価す

インタフェースの名前

る．ソースコード集合中のメソッド定義の集合 M と，メ

メソッド本体を所有するクラスにソッド定義 m ∈ M が与えられたときに候補リスト L(m)所属するフィールドの名前を生成するリスト生成器 L が与えられたとき，評価値

メソッド名の動詞

メソッド名の動詞部

E(M, L) は以下のように計算できる．ここで C(m) は，あ

メソッド名の目的語

メソッド名に含まれる名詞節

るメソッド定義 m ∈ M のメソッド本体に記述されている

c 2015 Information Processing Society of Japan


695

情報処理学会論文誌

Vol.56 No.2 692–700 (Feb. 2015)

呼び出しメソッド集合であり，重複したメソッド呼び出しは排除されている．

E(M, L) =m∈M c∈C(m)wratio(c, m)
maxRank(c, L(m))

式中の wratio(c, m) 関数は，メソッド m における，呼び出しメソッド c の重み付けされた割合であり，IDF を用いて以下のように定義する．

wratio(c, m) = 

IDF(c)d∈C(m) IDF(d)定 義 よ り ，任 意 の メ ソ ッ ド m に つ い て ，d∈C(m) wratio(d, m)

図 2 ツールを利用できる場面（メソッド名と戻り値が書かれた状態）

Fig. 2 Usage scenario: (1) Invoke proposed method when
method name and return type is written.

= 1 という関係が成立する．

wratio 関数の設計意図は，メソッド m で特異的に用いられているメソッドを正しく推薦したときに評価値を大きく増加させる一方で，equals や toString のように多くのメソッ
ドで呼び出される汎用的で著名なメソッドが正しく推薦されたときの評価値の増加を小さくとどめることである．
式中の maxRank(c, L(m)) 関数は，候補リスト L(m) の上から何番目に c が出現するかを取得する関数である．

L(m) はメソッド本体の雛形のリストであり，メソッド本
体の雛形は呼び出しメソッドの集合でできている．
実際に使用するパラメータは，それぞれのパラメータを[0, 1] の範囲で細かく分割し，すべての組合せで E(M, L)
が最も大きくなったパラメータの組合せを使用する．

3. 提案手法の実装
提案手法を，Eclipse IDE の Java 開発環境で動作するツールとして実装した．ツールが有効となった Eclipse に

図 3

ツールを起動すると，API の集合がリストとして提示される

Fig. 3 Usage scenario: (2) List of API sets are suggested.

おいて，Java のメソッドの名前のみが記述された状態でメ
ソッド名の直後にカーソルを合わせて Eclipse の持つコード補完機能（コードアシスト）を起動すると，提案手法に
よってメソッド本体の雛形リストが，コード補完の候補として提示される．リストから雛形を 1 つ選択することで，コメントに API が記述されたメソッド本体が生成される．
ツールの動作を，具体例とスクリーンショットを用いて説明する．開発者が TestDatabase というクラスを編集している場面を考える（図 2）．TestDatabase クラスにはい
くつかのフィールドが宣言されており，ここに開発者は新

図 4

API 集合を 1 つ選択すると，メソッドの雛形が入力される

Fig. 4 Usage scenario: (3) Select one element from the list,
then a template of method body is inserted.

しいメソッド test を作成しようとしている．このとき，開発者がコードアシストを起動すると提案手法が実行され，作成しようとしているメソッドの本体で使用される可能性

4. 実験の高い API の集合が，リストとして提示される（図 3）．

本手法によって推薦される API 集合が，開発者にとってこのリストから 1 つを選択すると，選択された候補の API

有用なものであるかどうかを調査するために，評価実験をがコメントとして記述されたメソッド本体が，雛形として行った．本手法では，記述中のソースコードにおいて必要生成される（図 4）．1 行のコメントが 1 つの API 呼び出な API が分からない開発者に対して，そのソースコードでしに対応しており，=> という文字列の右側がメソッド名記述されるであろう API 集合を提案することで，開発者を，左側がメソッドの所属するクラスの完全修飾名を表す．

に手がかりを与えることを期待している．そこで本実験では，開発者に有用な API 集合を推薦できるか調査するた

c 2015 Information Processing Society of Japan


696

情報処理学会論文誌

Vol.56 No.2 692–700 (Feb. 2015)

表 3 推薦された候補リストの概要

めに，以下の 3 つのリサーチクエスチョン（RQ）を設定

Table 3 Summary of suggested API lists.

した．

RQ1：推薦された API 集合はメソッド本体で使用されそうな API 集合であるか．

RQ2：ソースコードから取得したコンテキストのうち，ど内訳

候補リストの分類

2,979

1 つも候補が含まれなかった

21,837の項目が有用な推薦の手がかりとして使用されたか．

RQ3：直前に書かれた呼び出しメソッドの列から次に書
かれそうなコードの候補を推薦する既存手法との連携が期待できるか．

4.1 方法と結果

1 つ以上の候補が候補リストに含まれたが，その中に1 つも正しい呼び出しメソッドが含まれなかった

27,835

1 つ以上の正しい呼び出しメソッドが含まれていた

表 4

候補リストの一部と全体における適合率・再現率

Table 4 Precision and recall of suggested API lists.
適合率 1

適合率 2

適合率 3

再現率

1位

0.128

0.133

0.133

0.031

1〜5 位

0.109

0.102

0.074

0.078

うべき API の手がかりを与えられるか調査するために，学

1〜10 位

0.096

0.089

0.058

0.103

習に使用したソースコードとは別のソースコードに対して

1〜30 位

0.082

0.068

0.036

0.148

本ツールで API 集合の推薦を行い，実際にメソッド本体に

全体

0.053

0.027

0.008

0.290

本手法を実装したツールで，開発者にメソッド本体で使記述されている呼び出しメソッドとの比較や，候補に使用した相関ルールを調査する方法を用いた．
学習に用いたソースコード集合は，ソフトウェア検索シ

つ以上の候補を提示した 49,672 のメソッドにおいては，候補リストの長さの平均は 1,440，中央値は 526 であった．

ステム SPARS TYPE:R [7] の検索対象であり，プロジェク

次に，情報検索システムの評価で広く用いられている適ト数は 443，ファイル数は 198,324 である．ここから，学習合率と再現率を用いて，候補リストを評価する．ここでによって 5,401,676 の相関ルールを得た．並べ換え優先度

は，候補の並べ替えを評価することを目的として，一定ののパラメータチューニングは，学習に用いた Java ファイル

順位までの候補に限定した適合率および再現率を求める．

とは異なる 10,000 の Java ソースファイルを用いて実施し，

ここで問題となるのは，本手法の出力（推薦結果）が集合

パラメータを b = 0.0007425，c = 0.001502，n = 1.000，のリストであり，一般的な情報検索の出力とは異なるため

m = 0.1209 と決定した．

に，一般的な適合率と再現率の定義を適用できないことで評価には，学習およびパラメータチューニングとは異なある．そこで，適合率と再現率の定義を修正して用いるこるソースコード集合を用いる．まず，オープンソースソフととする．また，適合率については開発者が候補リストを

トウェアのプロジェクトホスティングサイトから，517 プ

利用する際の観点を考慮して，3 種類の基準を用いることロジェクトの，310,166 ファイルを収集し，ここからランとした．以下に，具体的な適合率と再現率の定義を示す．

ダムに 10,000 ファイルを取り出す．含まれていたメソッ

適合率 1：提示した API 集合候補のうち，正解となる API

ド数は 85,390 個であり，その中からボディで 1 つ以上のを 1 つ以上含んでいた候補の割合

メソッド呼び出しを行っていた 52,651 個のメソッドを評

適合率 2：提示した API 集合候補に含まれる API をすべ価の対象とする．評価対象の 1 メソッドあたりの呼び出して集めた多重集合を構成し，その中で正解となる API

メソッド数は，平均 7.0 個であり，中央値は 3 であった．

4.1.1 RQ1：推薦された API 集合はメソッド本体で使用されそうな API 集合であるか
評価用のソースコードに対して本ツールで API 集合の推薦を行い，実際にメソッド本体に記述されていた呼び出しメソッドをどれくらい再現できるかを評価した．手順とが占める割合適合率 3：提示した API 集合候補に含まれる API を重複を除いて集めた集合を構成し，その中で正解となる

API が占める割合
再現率：全正解 API 中，API 集合候補に含まれる API の割合

しては，まず，評価用のソースコードのメソッド定義から候補リストのトップからそれぞれ 1 位，5 位，10 位，30

メソッド本体を削除し，そのメソッドに対して本ツールで位までについて，各適合率と再現率を求めた結果を，表 4

推薦を行う．そして，推薦された API 集合のリストと，削に示す．また，適合率 1，2，3 と再現率から計算した F 値除したメソッド本体で呼び出されていた API とを比較す

を表 5 に示することで評価を行う．

4.1.2 RQ2：ソースコードから取得したコンテキストのまず，ツールが出力した候補リストの概要を表 3 に示す．
半数以上の事例で，候補リストに正しい呼び出しメソッド

うち，どの項目が有用な推薦の手がかりとして使用されたかを含んでいた一方で，2,979 個（全体の 5.7%）のメソッド

推薦コンテキストのうち，どの項目が良い推薦結果を出に対しては 1 つも候補を提示することができなかった．1

力するのに貢献したかを知るために，候補リスト中でメc 2015 Information Processing Society of Japan


697

Vol.56 No.2 692–700 (Feb. 2015)

情報処理学会論文誌

表 5 候補リストの一部と全体における F 値

在しないため，表 4 や表 5 の値について，良いか悪いかを

Table 5 F-measure values of suggested API lists.

評価することは難しい．ここで，提案手法は API の利用実適合率 1 に適合率 2 に適合率 3 に

績に基づいて推薦を行うため，学習に用いたソースコード

基づく F 値基づく F 値基づく F 値集合で利用されなかった API を推薦することは，原理的に

1位

0.050

0.050

0.050

不可能である．この事実をふまえると，29%という再現率

1〜5 位

0.091

0.088

0.076

1〜10 位

0.100

0.096

0.075

1〜30 位

0.106

0.093

0.058

全体

0.090

0.049

0.011

は良いものであると考えている．以上から，RQ1 については，推薦された API 集合はメソッド本体で使用されそうな

API 集合を含んでいたと結論づけたい．
推薦コンテキストの項目が良い推薦につながったかを評

表 6 正解を含む相関ルールにおける，前提部の識別子の種類の割合

価した表 6 を見ると，項目によって値の違いが大きいこと

Table 6 Elements of precondition in association rulesが分かる．なかでも，メソッド名の動詞は 84.3%と特に大containing at least one correct API.

きい値となっており，メソッド名の動詞が果たした役割が項目

割合大きいことが分かる．この結果は，メソッド名とメソッド

メソッド名の動詞

84.3%

本体の関係を調べた先行研究 [6], [9] の知見とも一致する．

メソッド名の目的語

2.0%

一方で，動詞以外の項目が果たした役割は小さいため，ここ

クラス名

11.0%

親クラス名

11.0%

インタフェース名

8.6%

ないかと考えられる．たとえば，本手法ではクラス名やイフィールド名

5.4%

ンタフェース名は名前の内部構造には触れず，識別子名がを工夫することで推薦リストを改善する余地があるのでは一致することをルールマッチの条件とした．しかし，クラソッド本体と一致する候補を出力することに貢献した相関ス名もまた複数の単語の組合せからなることが多いため，そルールを取り出し，前提部にどの項目を含むかを調査した．

の名前が完全に一致することは稀である．クラス名などの前提部の項目の種類の割合を表 6 に示す．各前提部は複数

識別子についても，それを構成する単語に分割することで，の項目からなるため，割合の合計は 100%とはならない．

API 利用との関連を見つけることができるかもしれない．

4.1.3 RQ3：直前に書かれた呼び出しメソッドの列からRQ3 については，前半の呼び出しメソッドを推薦でき次に書かれそうなコードの候補を推薦する既存手た候補が全体の約 8.1%と低い割合であったため，現時点

法との連携が期待できるか

では既存手法と直接的に連携することは難しいと考えられもし提案手法がメソッドの前半で呼び出す API を推薦

る．学習と推薦をメソッド本体の前半で行われる API 呼

できたとすると，それに続くメソッド呼び出しを既存手び出しに絞って行うなどの最適化によって，連携が可能に

法 [5], [14] によって得られると期待される．そこで，メなるかもしれない．

ソッド本体の前半に記述されている呼び出しメソッドが，評価対象のメソッドを調査したところ，評価対象のソー本手法でどれくらい提案できているかを調査した．具体的

スコード集合で記述された呼び出しは全部で 344,250 個でには，メソッド本体に 2 つ以上の呼び出しメソッドが記述あったが，そのうち 61,754 個（約 18%）は同一クラス内でされているメソッド定義を対象として，正解メソッドの前定義されたメソッドであり，さらにそのうち 17,007 個（全半分（小数点以下切り捨て）すべてが含まれるメソッド定

体の約 5%）はプライベートメソッドであった．提案手法

義はどの程度あるかを調査した．

ではこのような呼び出しを推薦することは原理的に不可能

まず，評価対象ソースファイル 10,000 には，2 つ以上のであるため，再現率や適合率の評価値を下げる原因となっAPI 呼び出しを含むメソッドが 85,389 個存在した．提案ている．さらに，このような API は開発者が変更している手法により，前半部分の呼び出しメソッドすべてを候補リ

メソッドに近い場所で定義されているものであるため，提ストによって推薦できたのは 6,945 個であり，これは全体案手法によって推薦する必要性も低いと考えられる．今後の約 8.1%であった．

は，クラス内などの近い場所で定義されたメソッド呼び出
しを評価対象から除くとともに，近い場所で定義されたメ

4.2 評価と考察
表 4 の結果を見ると，どの適合率の定義においても，候補の順位が上がるにつれて適合率の値が減少する傾向にあ

ソッドの利用を支援する方法についても考える必要がある．

5. 関連研究る．これは，上位の候補に正解となる呼び出しメソッドが山本らは，大規模なソースコード集合から適切なコード多く含まれていることを示しており，このことから本手法片を推薦する手法を提案した [14]．この手法は，IDE で書で提案した並べ替え基準は一定の妥当性を持っていると考

きかけのソースコード片を入力として，そのソースコード

えられる．しかし，本手法と直接比較できる既存研究が存片に対応した残りのソースコード片を頻度の多い順に出力

c 2015 Information Processing Society of Japan


698

情報処理学会論文誌

Vol.56 No.2 692–700 (Feb. 2015)するという手法で推薦を行う．山本らの研究では，メソッ
ド本体に記述された呼び出しメソッドの列から次に書かれそうなコード片を推薦するのに対し，本研究では，メソッの推薦を行うことも考えている．
謝 辞 本 研 究 は JSPS 科 研 費 25730036，25220003，

26280021 の助成を受けたものです．

ド本体に何も記述されていない状態で推薦を行う．また，山本らの研究で挿入されるコードはそのままメソッド本体

参考文献

で使用できる完全なコード片なのに対し，本研究で挿入さ

[1]
[2]
[3]

れるコードは編集が必要な雛形である点も異なる．

Wang らは，開発者があるメソッドを呼び出すよう記述した際に，そのメソッドの利用例と説明文を提示する手法[4]

APIExample を提案した [12]．この手法はまず，開発者が記述したメソッドの完全限定名に，java と example の 2 語を加え，Google を用いてウェブページ検索を行う．そし[5]て，検索結果の上位 300 件のページからコード片と周囲のテキストを抽出し，クラスタリングしたうえで開発者に提示する．Wang らの手法は特定のメソッドの利用例を示すのに対し，提案手法はある名前を持つメソッドの中で呼び[6]出すメソッドの候補を提示する点が異なる．また，Wangらの手法が利用する情報源が一般のウェブページであるのに対し，提案手法の情報源は既存のソフトウェアのソース[7]

コードである点も異なる．

Monperrus らは，オブジェクト指向言語のソースコード
中で不足している呼び出しメソッドの自動検出手法を実装[8]した DMMC [10] というツールを提案している．この手法
では，ある程度記述されたソースコードに対して必要であ[9]

ろう API を提案するが，本手法では，これから記述する新規のメソッドに対して API を提案する点が異なる．

Ye ら [13] や島田ら [15] は IDE 内で使用できるコード片
推薦手法を提案している．これらの手法では，開発者がソースコードを記述している IDE 内から自動的に抽出し[10]たキーワードに関連するソースコードを検索する．本手法
では，開発者が新規作成するメソッドの本体に対して API
集合を推薦する．

[11]

6. まとめと今後の課題
本研究では，膨大な API の中から必要な API を選択し，[12]

その組合せを考えることを支援する手法として，開発者が新規に作成するメソッドの名前を記述した段階で，メソッ
ド本体で使用される可能性が高い API 集合を推薦する手法を提案した．本手法によって開発者に有用な API 集合
を推薦できるかを調査したところ，推薦の際に並べ替えに[13]

よって適切な候補が上位に並べられていることや，開発者の記述中のソースコードに，より適した API 集合を推薦す
る改善案などが分かった．

[14]

今後の課題としては，API を集合としてではなく，呼び出し順序を含めた列として開発者に提示することで，APIの組合せについても支援することを検討している．また，メソッド本体にある程度コードを書いた状態で使用する
コード補完手法と連携することで，より精度の高いコード

c 2015 Information Processing Society of Japan

[15]

Eclipse, available from http://www.eclipse.org/.
OpenNLP, available from http://opennlp.apache.org/.
WordNet, available from http://wordnet.princeton.
edu/.
Agrawal, R., Imieliński, T. and Swami, A.: Mining Association Rules Between Sets of Items in Large Databases,
Proc. 1993 ACM SIGMOD International Conference
on Management of Data, pp.207–216 (1993).
Bruch, M., Monperrus, M. and Mezini, M.: Learning from Examples to Improve Code Completion Systems, Proc. 7th Joint Meeting of the European Software
Engineering Conference and the ACM Symposium on
the Foundations of Software Engineering (ESEC/FSE
2009 ), pp.213–222 (2009).
Høst, E.W. and Østvold, B.M.: Debugging Method
Names, Proc. 23rd European Conference on ObjectOriented Programming (ECOOP 2009 ), pp.294–317(2009).
Inoue, K., Yokomori, R., Yamamoto, T., Matsushita,
M. and Kusumoto, S.: Ranking Signiﬁcance of Software Components Based on Use Relations, IEEE Trans.
Softw. Eng., Vol.31, No.3, pp.213–225 (2005).
Jones, K.S.: A statistical interpretation of term speciﬁcity and its application in retrieval, Journal of Documentation, Vol.28, pp.11–21 (1972).
Kashiwabara, Y., Onizuka, Y., Ishio, T., Hayase, Y.,
Yamamoto, T. and Inoue, K.: Recommending Verbs for
Rename Method using Association Rule Mining, Proc.
IEEE Conference on Software Maintenance, Reengineering, and Reverse Engineering (CSMR-WCRE )(2014).
Monperrus, M., Bruch, M. and Mezini, M.: Detecting Missing Method Calls in Object-Oriented Software,
Proc. 24th European Conference on Object-Oriented
Programming, pp.2–25 (2010).
Shannon, C.E.: A Mathematical Theory of Communication, The Bell System Technical Journal, Vol.27,
pp.379–423, 623–656 (online), available from http://cm.
bell-labs.com/cm/ms/what/shannonday/shannon1948.
pdf (1948).
Wang, L., Fang, L., Wang, L., Li, G., Xie, B. and Yang,
F.: APIExample: An eﬀective web search based usage
example recommendation system for java APIs, Proc.
26th IEEE/ACM International Conference on Automated Software Engineering (ASE 2011 ), pp.592–595(2011).
Ye, Y., Fischer, G. and Reeves, B.: Integrating Active Information Delivery and Reuse Repository Systems, Proc. 8th ACM SIGSOFT International Symposium on Foundations of Software Engineering: Twentyfirst Century Applications, pp.60–68 (2000).
山本哲男，吉田則裕，肥後芳樹：ソースコードコーパスを利用したシームレスなソースコード再利用手法，情報処理学会論文誌，Vol.53, No.2, pp.644–652 (2012).
島田隆次，市井 誠，早瀬康裕，松下 誠，井上克郎：
開発中のソースコードに基づくソフトウェア部品の自動推薦システム A-SCORE，情報処理学会論文誌，Vol.50,
No.12, pp.3095–3107 (2009).

699

情報処理学会論文誌

Vol.56 No.2 692–700 (Feb. 2015)

早瀬 康裕 （正会員）井上 克郎 （フェロー）

平成 14 年大阪大学基礎工学部情報科

昭和 31 年生．昭和 54 年大阪大学基礎学科卒業．平成 19 年同大学大学院博工学部情報工学科卒業．昭和 59 年同士後期課程修了．同年同大学特任助

大学大学院博士課程修了．同年同大学

教．平成 22 年東洋大学総合情報学部

基礎工学部助手．昭和 59〜61 年ハワ

助教．平成 23 年筑波大学システム情イ大マノア校情報工学科助教授．平成報系助教．博士（情報科学）．ソフト

元年大阪大学基礎工学部講師．平成 3

ウェア開発支援，オープンソースソフトウェア開発分析の年同助教授．平成 7 年同教授．平成 14 年大阪大学大学院研究に従事．IEEE 会員．

情報科学研究科教授．平成 24 年大阪大学大学院情報科学
研究科・研究科長．工学博士．ソフトウェア工学，特に，ソフトウェア開発手法，プログラム解析，再利用技術の研

鬼塚 勇弥

究に従事．

平成 24 年大阪大学基礎工学部情報科学科卒業．平成 26 年同大学大学院情報科学研究科博士前期課程修了．現
在，株式会社カプコンに勤務．在学
中はコード補完手法に関する研究に従事．

山本 哲男 （正会員）
平成 9 年大阪大学基礎工学部情報工学科卒業．平成 14 年同大学大学院博士後期課程修了．同年科学技術振興事業
団計算科学技術研究員．平成 16 年立命館大学情報理工学部情報システム学科講師．平成 20 年同学科准教授．平成 23 年日本大学工学部情報工学科准教授．博士（工学）．
ソフトウェア開発支援環境の研究に従事．電子情報通信学会，IEEE-CS 各会員．

石尾 隆 （正会員）
平成 15 年大阪大学大学院基礎工学研
究科博士前期課程修了．平成 18 年同
大学院情報科学研究科博士後期課程修了．同年日本学術振興会特別研究員（PD）．同年ブリティッシュコロンビ
ア大学ポストドクトラルフェロー．平成 19 年大阪大学大学院情報科学研究科コンピュータサイ
エンス専攻助教．博士（情報科学）．プログラムの静的解
析と動的解析，プログラム理解に関する研究に従事．電子情報通信学会，日本ソフトウェア科学会，IEEE，ACM 各
会員．

c 2015 Information Processing Society of Japan

700