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

キーワードと書きかけのコードから開発者の意図を推測する API 呼び出し記述支援手法の検討
西本 匡志

川端 英之

弘中 哲夫

複雑な知的活動であるソフトウェア開発を効率化する試みには様々なものがある．しかし，要求に対する仕様の明確化やプログラム部品の詳細設計，実装，テストなど，担当者の開発経験によって開発効率が左右される要因は未だに多く存在する．近年は多様なフレームワークやライブラリの組み合わせによるアプリケーション構築が不可欠であり，開発者には API の使い方への熟練が求められる．これに対し，多くのソースコードから API 使用に関するノウハウを抽出して，API の呼び出し系列の記述を補助する仕組みが研究されている．我々はさらなる開発効率向上を目指し，開発者の意図を汲み取った上で支援する手法を検討した．本手法は開発者の手元にあるコードの編集状況や開発者が与えるキーワードから，実現しようとしている機能や追加が必要な処理を推測し，コードの修正案を提示する．本稿では，本手法に基づく支援ツールの有効性について，プロトタイプを用いた評価を踏まえて考察する．

や，開発するソフトウェアに対する徹底したドキュメ1 はじめにント整備や仕様詳細化が重要であることは言うまでコンピュータシステムが社会基盤を支える現代におもない．しかしながらこれらは，柔軟な手法とは言いて，ソフトウェアの開発や保守の効率化は極めて重い難く，また開発者の能力に頼ったナイーブな対処法要な課題である．と言えよう．一方で，プログラミングを支援するツー

ソフトウェア開発効率向上を阻む事象には様々なもル，すなわち，構文認識，コード補完，デバッガ機能のが考えられるが，多様なフレームワークやライブラ等を備える統合開発環境やソースコードのバージョンリを組み合わせる必要があるという点が，今日のアプ管理システムの活用等も不可欠である．しかし，多くリケーションの構築の難しさの一つの特徴と言えるの汎用ツールは最大公約数的な機能の提供をするのだろう．ソフトウェア開発者には，多様かつ大量のラみで，アプリケーションごとに異なる「開発の文脈」

イブラリのインターフェース，すなわち Applicationを把握したサポートがなされるわけではない．近年でProgramming Interface (API) の熟知と，それらをは，DroidAssist [7] のように，API の呼び出し系列情適切に組み合わせる作業の遂行が求められる．この報を踏まえたコード補完・レコメンドツールが提案さことは，規模の大きなソフトウェアを業務として開発れているが，その効果は限定的と言わざるをえない．

する場面においては特に，ソフトウェア開発者にとっ我々は，これに対し，開発者の意図を汲み取ってて大きな負担となっていると考えられる．

API 呼び出しの組み合わせに基づくプログラミング

API の組み合わせによる大規模ソフトウェア構築をサポートする API 呼び出し記述支援手法を提案すを効率的にこなすためには，フレームワークおよびる．我々の手法に基づくツールは，書きかけのソース

その API の学習のような開発者自身のスキルアップ

コードやユーザが与えるキーワードを踏まえて開発状況を把握し，要求される仕様に対してどのようなMasashi Nishimoto, Hideyuki Kawabata, Tetsuo Hironaka, 広島市立大学大学院 情報科学研究科, Graduate School of Computer Sciences, Hiroshima City
University.

機能が欠けているかを判断できる．また，どこにどのような記述を挿入する必要があるかなどの情報を，既存のコードに即して指示する機能を備える．

Keyword: Sensor

Response from the tool:

Words in limited range are taken into

account to generate a recommendation

Recipe for "Sensor"
in onCreate:
1. onCreate
2. setContentView<--- MISSING !?
3. getSystemService <--- MISSING !?
4. findViewById
in onResume:
1. onResume
2. ...

Whole program is analyzed

Response from the tool:

Choices:
1. mSensorManager
2. List
3. ...

(a) DroidAssist [7] による方式．編集中のプロ
グラムのカーソル位置における入力候補を提示する（断片的な情報に基づいた平均的な候補の提示）．
図1

to generate a recommendation(b) 我々の方式．編集中のプログラム全体及びキーワー
ド入力を踏まえてプログラマの意図を把握し，「足りないものは何か」を提示する．

API 呼び出し記述を支援する機能とそのインターフェースの違い（我々の方式は (b)）

本研究では，提案する API 呼び出し記述支援手法くつかの試みが研究されている．DroidAssist [7] はを実現するツールのプロトタイプを設計し，その効果Android Studio [4] のプラグインとして提供されて，を確認した．本稿では，提案手法に基づくツールの設編集中ソースコードにおけるカーソル位置のオブジェ計，及び，プロトタイプの実装を踏まえた本手法の有クトを対象として，呼び出すべき API をレコメンド

効性の評価について述べる．

する．レコメンドの仕組みはソースコード中で現れる

以下，第 2，3 章では，提案する開発支援環境の持対象オブジェクトに関する API 呼び出し系列と，複つべき機能やその設計について述べる．また，第 4 章

数の既存ソフトウェアから抽出した API 呼び出しので提案する開発支援環境のプロトタイプを用いた予系列とを比較して，カーソル位置の次に実装すべき備的実験結果を踏まえつつ，我々の方法の可能性につAPI 呼び出しをアドバイスするものである (図 1(a))．

いて第 5 章で議論する．

しかしながら，DroidAssist は多くのソフトウェアで実装される頻度が高い API 呼び出し系列のパター

2 提案：API 呼び出し記述支援ツールンを元にアドバイスを行っているため，編集中のソー2. 1 既存手法とその問題スコードを実装している開発者の思惑や意図が API

開発者が API の使い方を習得するためには，API呼び出し系列のパターンには含まれていない．そのた仕様のドキュメントを読んだり，API の開発者が提め，DroidAssist から提供されるアドバイスは開発者供するサンプルコードを実行して動作を確認したりすが望むアドバイスになっていない可能性がある．

る．また Google に代表される検索エンジンに API 名

開発者は実現したい機能を頭に思い浮かべて，編集を入力することによって，Qiita [6] や Stack Overflow

中のソースコードに不足した処理や不要な処理が無い[10] などの技術情報共有サービスから API の使い方かどうかなどの確認を行ったり，新たな機能を追加すに関する情報を得ることもある．しかし，これらのるにはどうしたらよいかなどを考えているはずであ方法は多くの API に関する情報を理解したり，多くる．それらの思惑や意図を十分に考慮した上で適切なの情報の中から開発者自身にとって必要な情報を取アドバイスを行うことが重要であり，我々はユーザの捨選択したりしなければならず，開発者への負担が大意図を踏まえた支援が可能なシステムの実現を目指

きい．

して，次の特徴的な機能を持つユーザ支援ツールを検このような開発者への負担を軽減するためにい討した．図 1(b) に示すのは我々の方式に基づく API

呼び出し記述支援ツールのインターフェースの外観である．次節で我々の方式について詳細に述べる．
API呼び出し記述支援ツール

2. 2 我々の方式：ユーザの意図を踏まえた支援
2. 2. 1 特徴 1：キーワード入力の活用

API呼び出し
書きかけのソースコード

ユーザの意図を支援ツールに伝えるためには，キーワード入力を用いることが容易かつ直接的であると考API呼び出し

記述モデル

情報解析器
アドバイス生成器

機能実現に必要な情報機能実現のキーワード

える．キーワードだけでは実装したい機能の仕様記述にはなり得ないが，記述すべき API 呼び出し系列を特定するヒントとして効果的に使えると期待できる．

図2

API 呼び出し記述支援ツールの構造

例えば特殊なデバイスの制御に必要な一連の記述はアプリケーションを問わず共通したものになる．

2. 2. 2 特徴 2：書きかけのソースコードを踏まえた情報提示
ユーザの意図は，開発中のソースコードにも現れデル（3. 2 節参照）を元に不足している（あるいは不適当な）API 呼び出し（の系列）に関する機能実現に必要な情報が生成され，ユーザに示される．
個々の構成要素の働きについて以下に述べる．ていると見ることができる．我々のツールは，キーワードで与えた情報に基づいて取り出される「レシ3. 2 API 呼び出し記述モデル

ピ」とでもいうべき API 呼び出し系列のパターンと，我々のツールは，API 呼び出し記述モデルと呼ぶ

書きかけの（必ずしも特定の機能の実装が完了してリポジトリを中心に据えて動作する．API 呼び出しいない）ソースコードを見比べて，どこにどのような記述モデルは，アプリケーション構築に用いられるAPI 呼び出しを挿入する必要があるのかをユーザに様々な機能の実現における標準的な API 呼び出し情提示する．

報 (3. 2. 1 節参照) の集合である．なお，ここで述べ我々のツールは，書きかけのソースコードに対してた機能とは，「カメラで写真を撮る」や「加速度セン

ユーザが実現したい機能を表すキーワードから，ユーサーの値を取得する」など単独のアプリケーションとザの意図を汲み取り，記述すべき API 呼び出し (のして動作可能な最小構成のことを示す．

系列) を提示する．

本研究では API 呼び出し記述モデルはライブラリやフレームワークのマニュアル等から，機能毎に手作

3 API 呼び出し記述支援ツールの設計業で API 呼び出し情報を作成して使用する．将来的

3. 1 ツールの構造と処理の流れには，ソフトウェアリポジトリマイニング等による自本ツールの構造の概略を図 2 に示す．本ツールは，動生成を行って構築することを考えている．

次の構成要素からなる．

• API 呼び出し情報解析器

3. 2. 1 API 呼び出し情報
API 呼び出し情報はユーザ定義クラス内に標準的• アドバイス生成器に実装されるべきメソッドの集合を集めたものであ• API 呼び出し記述モデル

る．それら個々のメソッド中で呼び出されるべき API

本ツールの動きについて図 2 の構成要素を用いての名前情報のリストが API 呼び出し系列として把握述べる．まず，ユーザが書きかけのソースコードはされる．

「API 呼び出し情報解析器」によって分析され，API

図 3 は図 4 のプログラムから得られる API 呼び出呼び出し情報が抽出される．次に，API 呼び出し情し情報を表している．この例を用いて API 呼び出し

報とユーザから与えられた機能実現のキーワードは情報とプログラムとの対応関係を説明する．図 4 は「アドバイス生成器」に渡され，API 呼び出し記述モスマートフォンに搭載された照度センサーの値を取onAccuracyChanged のようなメソッド中に API 呼

API呼び出し情報:MainActivity

API呼び出し系列1:

API呼び出し系列2:

API呼び出し系列3:

び出しが 1 つもない場合は API 呼び出し系列としてActivity.onCreate

Activity.onResume

SensorEventListener.
onSensorChanged扱わない．

Activity.
onCreate

Activity.
onResumeSensorEvent.
getType

Activity.
setContentView

SensorManager.
getSensorList

TextView.
setText

Activity.
getSystemService

List<Sensor>.
size

呼び出しの順序関係を有向グラフで表現したものがActivity.
findViewById

List<Sensor>.
get

API 呼び出しは「クラス名. メソッド名」で表記されSensorManager.
registerListener

またユーザが定義したメソッド onCreate では，on-Create，setContentView，getSystemService，findViewById の順に API が呼び出されている．この API
図 3 中の API 呼び出し系列 1 である．なお図中のている．

3. 3 API 呼び出し情報解析器
図3

API 呼び出し情報

API 呼び出し情報解析器はソースコードから 3. 2. 1
節の API 呼び出し情報を抽出する役割を持つ．対象のソースコードに対して構文解析を行って，ユーザ定1 public class MainActivity extends Activity
2 implements S e n s o r E v e n t L i s t e n e r {3private SensorManager mSensorManager ;4private TextView mTextView ;56@Override
7public void onCreate ( Bundle s av e dI n st a nc e St a te ) {8super . onCreate ( s a ve d In s ta n ce S ta t e );9setC ontentView ( R . layout . main );10
11mSen sorManager = ( SensorManager ) getSystemServi ce (12Context . SENSOR_SERVICE );13mTextView = ( TextView ) findViewById ( R . id . value );
14}
15
16
@Override17
protected void onResume () {18super . onResume ();19
20
List < Sensor > sensors = mSensorManager . getSensorList (21Sensor . TYPE_LIGHT );22if ( sensors . size () > 0) {23
Sensor sensor = sensors . get (0);24mSensorManager . registerListener (25this ,26sensor ,27
SensorManager . SENSOR_DELAY_UI );
28}
29}
30
31
@Override32
public void o nAc cur acy Ch ang ed ( Sensor sensor , int accuracy ) {33}3435@Override36
public void onSensorChanged ( SensorEvent event ) {37switch ( event . sensor . getType ()){
38
case Sensor . TYPE_LIGHT :39
int value = ( int )( event . values [0]);40mTextView . setText ( String . valueOf ( value ));41
break ;
42}
43}
44 }

義クラス，その中で実装されるメソッドやメソッド内で呼ばれている API 呼び出しを抽出する．その抽出した情報を API 呼び出し情報の形式に整える．

3. 4 アドバイス生成器
アドバイス生成器は，書きかけのソースコードのAPI 呼び出し情報と機能実現のキーワードを使って，API 呼び出し記述モデルからユーザの意図に合ったAPI 呼び出し情報を選び，機能実現に必要な情報 (不足した API 呼び出しやその系列) を生成する．
アドバイス生成は次の 2 段階のステップで行われる．

3. 4. 1 ステップ 1：ユーザの意図に合った API
呼び出し情報の選択

API 呼び出し記述モデルを検索して，キーワードに合致する API 名やクラス名が含まれる API 呼び出し情報を全て選び出す．なおキーワード，クラス名や API 名は全て小文字に変換し，部分一致によってキーワードが含まれているかどうか判断する．

図4

Android アプリケーションのプログラム例

図 5 を用いて，ステップ 1 の処理の流れを説明する．図 5 はキーワード”B”に対してそれに「関連」す得するプログラムであり，MainActivity クラスの中る API 呼び出し情報を取り出す様子を表している．に 4 つのメソッド，onCreate，onResume，onAccu-

まず IA の AS1 の各 API 呼び出しのクラス名や API

racyChanged，onSensorChanged が定義された形で名にキーワード”B”が含まれている否かを調べる．IA実装されている．図 3 に示すように，この定義されの AS1，AS2 にはキーワードが”B”が含まれていな

た 1 つのメソッドが 1 つの API 呼び出し系列となる．

い．次に IB の BS1 を調べると B.b1 の API 呼び出しAPI呼び出し記述モデル
IA

ユーザの意図に合ったAPI呼び出し情報

IB
AS1

AS2

A.
a1A.
a4A.
a2

A.
a5

IC
BS1
B.
b1

BS2

BS3

IB
CS1

B.
b2

B.
b4C.
c1

B.
b3

B.
b5C.
c2

BS1

BS2

BS3

B.
b1

B.
b2

B.
b4B.
b3

B.
b5②合致すればA.
a3

抽出する

書きかけのソースコード
IX

ユーザの意図に合ったAPI呼び出し情報
IB

XS1

XS2

BS1

BS2

BS3A.
a1A.
a4B.
b1

B.
b2

B.
b4B.
b1

B.
b2B.
b3

B.
b5

A.
a2

C.
c4

BS2

XS2
A.
a4

B.
b2

有B.
b2

C.
c4

C.
c1

無B.
b3

C.
c2

API

①キーワードが各API呼び出しのクラス名やメソッド名に呼び出し含まれているものを検索する

情報

API

呼び出し系列

API

呼び出し

凡例：

B

①各API呼び出し系列同士を比較してキーワード同じAPI呼び出しがあるかどうかを調べる②同じAPI呼び出しがある場合，ユーザの意図に合ったAPI呼び出し系列にあって，書きかけのソースコードにはないAPI呼び出しを抽出する

図5

ステップ 1：ユーザの意図に合った API 呼び出し情報の選択

図6

ステップ 2：不足 API 呼び出しの抽出があり，クラス名 B にキーワード B が含まれている．

B3 が不足した API 呼び出しである．また，BS3 のそこで，BS1 が属する IB を，「ユーザの意図に合ったAPI 呼び出し系列をユーザにアドバイスする．

API 呼び出し情報」としてステップ 2 で用いる．
3. 4. 2 ステップ 2：機能実現に必要な情報の生成

4 プロトタイプの実装とその評価

ステップ 1 で選択したユーザ意図に合った API 呼本研究では，提案する支援ツールの有効性を評価す

び出し情報と書きかけのソースコードの API 呼び出るため，プロトタイプを実装した．本章では開発したし情報の双方に含まれる API 呼び出し系列を比較しプロトタイプの実装について述べて動作例を示す．て，同じ API 呼び出しがあるかどうかを調べる．同じAPI 呼び出しがある場合は，書きかけのソースコー

4. 1 プロトタイプの実装

ドの API 呼び出し系列になく，ユーザ意図に合ったプロトタイプを実装するにあたって，スマートフォ

API 呼び出し系列にある API 呼び出しを探す．もしンの代表的なフレームワークの 1 つである Android

該当する API 呼び出しがあれば，機能を実現する上アプリケーション開発を支援対象とした．

で書きかけのソースコードに不足した API 呼び出し

図 2 の書きかけのソースコードは Android フレーである．また，この API 呼び出しが属する API 呼び

ムワークを用いて Java で書かれ，機能実現のキー出し情報において，書きかけのソースコード中で使用ワードは，書きかけのソースコードにおいて実現したされていない API 呼び出し系列がある場合は機能をい機能を英単語 1 つで表現した．また，出力される機実現する上で足りない系列があることを表している．

能実現に必要な情報は，クラス名と API 名から成る

図 6 を用いてステップ 2 の処理の流れを説明する．

API 呼び出し (もしくはその系列) の情報と，書きかまず，API 呼び出し情報 IX の API 呼び出し系列 XS1

けのソースコード中にある挿入する位置を表す開始・と IB の BS1 を比較する．両者で B1 が共通してい終了の行番号である．

るが，BS1 は B1 のみの系列で他に API 呼び出しは「API 呼び出し情報解析器」は入力された書きかなく不足はなし．次に，XS1 と BS2 を比較して両者けの Java のソースコードを解析するために，Eclipseで共通する API 呼び出しはなく不足はなし．XS1 とJava development tools [3] の Java 用の構文解析ライBS3，XS2 と BS1，XS2 と BS3 の組み合わせについブラリを用いて構築した．ても同様である．XS2 と BS2 は両者 B2 が共通していて，BS2 には B2 の後に B3 があるのにもかかわらず，XS2 の B2 以降には B3 は存在しない．つまり，

4. 2 プロトタイプの動作例

ルの形式に関して改良の余地が多い．

書きかけのソースコードがキーワードで示す機能を

API 呼び出し記述モデルへの引数情報導入 我々の満たしたものかどうかを API 呼び出し記述支援ツー

プロトタイプでは，引数によって動作が変化するルのプロトタイプで確認可能かを動作例を示しながような API 呼び出しが含まれている場合に対処ら述べる．

できない．引数情報はユーザの意図の判別に必要

図 4 のソースコードは Activity に属する onCreateな場合もある．

や onResume をオーバーライドして独自の処理を記

キーワード検索の精度向上 プロトタイプでのキー載するような最も標準的な Android アプリケーショ

ワードの活用の仕方は限定的で，現時点では APIンである．また，自身のクラスや別クラスでユーザ定呼び出し記述モデルの検索においては API 名に義された関数を呼び出すこともなく，センサー制御と対する文字列部分一致の有無のみでの判断となっ画面表示に関する 2 つの機能で構成された，非常にている．結果，例えば名前に context や text をシンプルな例である．

含む API はいずれも文字列 text で取り出され我々はこのソースコードに対して，いくつかのコーる．キーワードを用いた検索精度の向上には，英ドを欠落させてキーワードとともに API 呼び出し記単語としての意味の区切りを意識させるなどの述支援ツールのプロトタイプに入力した．結果を表 1

配慮が求められる．に示す．動作例 1〜3 は Sensor に関する API 呼び出制御構造の詳細な把握 我々のプロトタイプではしを 1 つ，複数，あるいはメソッド自体を欠落させAPI 呼び出し系列の把握の仕方が単純で，例えて実行した結果である．いずれも不足した API 名とば API 呼び出し系列が複数の関数に分割されて挿入すべき位置が正しくアドバイスされた．動作例 4いるときに分割されていない場合と同一視するは TextView に関する API 呼び出しを 1 つ欠落させことができない．関数呼び出しのネストに対するて実行した結果である．動作例 4 に関しても不足し洗練された把握が求められる．

た API 名と挿入すべき位置が正しくアドバイスされた．なお，この結果から，複数の機能が混在したソー

5. 2 API 呼び出し記述モデルの自動生成についてスコードに対して，特定の機能へのアドバイスが行え我々のツールの可用性は，API 呼び出し記述モデることが確認できた．動作例 5 の結果から，不足がルが如何に幅広く API 呼び出し系列に関する情報を無いときに誤ったアドバイスを行わないことが確認で蓄えられているかに左右される．API 呼び出し記述

きた．

モデルの拡充には，既存ソフトウェアからの API 呼このように，我々のツールは不足した API 呼び出び出し記述モデルの自動生成機能が不可欠である．

しを書きかけのソースコードとキーワードを入力す機能ごとに整理された API 呼び出し系列の抽出ると得られるという特徴を持っていることが表 1 の既存ソフトウェアは一般には多くの機能をひと結果から確かめられた．

つのアプリケーションの中に実装したものであって，個別の機能に対応した API 呼び出し系列の5 議論マニュアルやカタログとはみなせない．従って，第 4 章では，我々のツールのプロトタイプを用いて情報収集時には個々の機能ごとに関連する API基本的な機能の実現可能性や有用性についての実験呼び出し系列を分離する必要がある．これを実現結果を示した．しかしながら，我々のツールには改良するには，API 呼び出し系列だけでなく，関連の余地が多い．以下，その幾つかについて述べる．

する制御フローやデータ依存関係についての情報の収集も必要である．

5. 1 API 呼び出し記述モデルによる情報把握
我々のプロトタイプでは，API 呼び出し記述モデ同種の機能に対する複数の API 呼び出し系列の扱い多くの既存ソフトウェアを解析して抽出した場

表1

動作例 1
動作例 2
動作例 3
動作例 4
動作例 5

API 呼び出し記述支援ツールのプロトタイプの挙動

入力（未完成のコードとキーワード）
未完成コードキーワード
図 4 11∼12 行目欠落
“Sensor”（API 呼び出し一つ欠落）
図 4 20∼23 行目欠落
“Sensor”（API 呼び出し複数欠落）
図 4 35∼43 行目欠落
“Sensor”（API 呼び出し系列自体の欠落）
図 4 13 行目欠落
“TextView”（API 呼び出し一つ欠落）
図 4 と同じ（不足なし）“Sensor”

出力（ツールによるレコメンド情報）
不足 API の指摘
挿入すべき位置
getSystemService
図 4 10∼12 行目

getSensorList, size, get

図 4 19∼23 行目

getType

図 4 34 行目以降

findViewById

図 4 10 行目

指摘なし

指摘なし

合，同じ機能に関する API 呼び出し情報が複数

従って，Sensor というキーワード入力に対してユー得られ得る．また，不具合を含むものや obsolete

ザが Sensor と GPS のどちらを意図しているのかをな API を含むなど，アドバイス生成に使用する判断できなければ，有用なレコメンドを提供することことが難しい API 呼び出し情報が抽出される可は難しい．

能性がある．これに対し，API 呼び出し系列の単語と技術用語の関係をユーザが正確に把握して出現確率などを踏まえた API 呼び出し記述モデいない可能性を考慮すると，個々のキーワードから類ルの「精製」機能が検討される必要がある．

推されるユーザの意図は正確には判定しえない．書きソースコードではない表現からの情報収集 例えばかけのソースコード中に現れる情報や，自然言語処理

Java 言語を支援対象とする場合には，ソースコー的な観点での類義語を総合して提示情報を選別した

ドではなくバイトコードレベルでのリポジトリり，ユーザとのインタラクションにより提示情報を絞マイニングからも API 呼び出し系列情報を得るり込んだりする機能が必要である．には可能と考えられる [8]．

6 関連研究5. 3 ユーザの意図の把握手法についてAPI の使い方を学ぶことを支援するいくつかの試み

現時点の我々のツールでは，ユーザの意図の把握のが研究されている．Raychev ら [9] の SLANG は既存ための情報源はキーワードに頼っている．しかしながのプロジェクトより API 呼び出しの前後関係を抽出ら，ユーザが書きかけのコードは，それ自体がユーして，N-Gram や Recurrent Neural Network(RNN)

ザの意図を色濃く反映したものでありうる．例えば，を用いて学習する．そして編集中のコードにおいて，ソースコード中に現れる識別子名，特にクラス，変数次に呼び出される関数を予測するシステムを提案しや関数の名称は処理の内容を表すように命名されてた．また，Pham ら [8] は API 呼び出しの前後関係にいることが多い．これらの識別子名に対する自然言語

ついて Hidden Markov Model を用いてモデル化し処理的な解析により，対象のソースコードがどのようた HAPI を提案した．これらの研究に対し，本研究な機能・処理を実装中かを推測できる可能がある．

は，API の呼び出しの前後関係だけではなく，どのような関数から呼び出されるかも含めてモデル化す

5. 4 キーワードの解釈手法についてることにより，どこにどのような処理を挿入すべきかユーザが入力したキーワードは自然言語で表現さを判断可能とする点が新しい．また，開発者によってれていて曖昧さがある．例えば，一般用語としての実現が要求される仕様が入力され，内容を把握した上Sensor という単語の意味は幅広く，加速度センサーでアドバイスするため，今までの研究のように一般的や GPS などを示すことがある．しかし Android フ

な API 使い方のみで提示するシステムに比べて，開レームワークにおいては，GPS に関連する API 呼び

発者が要求した内容に即した情報を提示可能である．

出し系列は一般の Sensor とは明確に異なっている．

また API の使い方に対して開発者の意図を汲んだ

上でアドバイスしようという試みも研究されている．

参 考 文 献

例えば，Gvero らの AnyCode [5] は開発者が実装し[ 1 ] Apple Inc.: Xcode, https://developer.apple.
com/xcode/.
[ 2 ] Eclipse Contributors and others: Eclipse, http://www.eclipse.org/.
[ 3 ] Eclipse Contributors and others: Eclipse Javadevelopment tools(JDT), http://www.eclipse.org/jdt/.
[ 4 ] Google Inc.: Android Studio, https://developer.
android.com/studio/index.html.
[ 5 ] Gvero, T. and Kuncak, V.: Synthesizing Java
expressions from free-form queries, Acm Sigplan
Notices, Vol. 50, No. 10(2015), pp. 416–432.
[ 6 ] Increments Inc.: Qiita, https://qiita.com/.
[ 7 ] Nguyen, T. T., Pham, H. V., Vu, P. M.,
and Nguyen, T. T.: Recommending api usages
for mobile apps with hidden markov model, Automated Software Engineering (ASE), 2015 30th
IEEE/ACM International Conference on, IEEE,
2015, pp. 795–800.
[ 8 ] Pham, H. V., Vu, P. M., Nguyen, T. T., et al.:Learning API usages from bytecode: a statistical approach, Proceedings of the 38th International
Conference on Software Engineering, ACM, 2016,
pp. 416–427.
[ 9 ] Raychev, V., Vechev, M., and Yahav, E.: Codecompletion with statistical language models, ACM
SIGPLAN Notices, Vol. 49, No. 6, ACM, 2014,
pp. 419–428.
[10] Stack Exchange Inc.: Stack Overflow, http://stackoverflow.com/.

たい処理を表した自然言語を入力すると，それに基づいたコードが補完される．AnyCode は入力された自然言語から開発者の実装意図を汲んだ上で，補完するため，本研究と目指す方向性が似ている．AnyCodeは 1 つの関数呼び出しが補完対象であるが，本研究では関数の呼び出しの「系列」をアドバイスしようとしているところが異なる．

7 おわりに
本研究では，開発者の意図を汲みとった上で，書きかけのソースコードに対してアドバイスを提供する

API 呼び出し記述支援手法の検討，設計，そしてプロトタイプ実装を行って評価した．
その結果，シンプルな例であるが，キーワードが表す機能を実現するにあたり，書きかけのソースコードに足りない API 呼び出しの名称や挿入位置をアドバイスすることができた．
今後の課題としては，第 5 章で述べた項目，特にAPI 呼び出し記述モデルの形式とアドバイス生成に関する改善検討を行って，システムの実現を目指す．