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

既存 Android アプリケーションの実装状況に基づいた実装すべきメソッドの提示手法
薄井 駿 名倉 正剛

高田 眞吾

Android アプリケーションはイベント駆動型ソフトウェアである．開発者は Android API 内のコールバックメソッドを継承し内部を記述することでイベントに対する処理を定義する．処理を定義しない場合，アプリケーションは予想外の振る舞いをする可能性がある．本論文は既存プロジェクトを解析して得たコールバックメソッドの実装頻度と実装の共起関係を基に，開発者に実装すべきコールバックメソッドを提示する手法を提案する．

を提案する．これは既存の Android アプリの実装状

1 序論

況に基づき，開発者が実装していないコールバックメ

Android アプリケーション（以下，Android アプ

ソッドの中で実装すべきものを特定することによってリ）は，Android OS 上で動作するソフトウェアであ実現する．提案手法により，開発者にコールバックメる．この Android アプリは処理を記述したファイル

ソッドの実装漏れを認識させ，実装を行う機会を与えと，アプリの見た目のレイアウトを記述したファイルることができる．の 2 種類で構成される．一般的に処理を記述したファ

本論文の構成は次のようになっている．2 章ではイルは Java で，レイアウトを記述したファイルはコールバックメソッドの実装と実装漏れによる問題をXML で記述する．Java ファイル内では通常の Java述べる．3 章では提案手法の概要および，各部分の詳

API の他に，Google の提供する Android フレーム細について述べる．4 章では提案手法の実装についてワークを利用することができる．

述べる．5 章ではケーススタディについて述べる．6

Android フレームワークには各種イベントに反応して実行するコールバックメソッドが含まれている．

章では関連研究について述べる．7 章では本論文の結論を述べる．

これを含むクラスを継承し処理を記述することで，開発者はイベントに対する Android アプリの振る舞い

2 コールバックメソッドと実装の欠落の問題を定義できる．開発者がコールバックメソッドの実装

Android アプリはイベント駆動型のソフトウェアを忘れた場合，Android アプリは想定外の振る舞いである．これは実行開始後待機状態になり，特定のイをする可能性がある．

ベントが発生すると対応する処理を行い再度イベン

本論文ではコールバックメソッドの実装し忘れを防ト発生を待つようなソフトウェアである．このイベ

ぐために，開発者が実装を行っている際にリアルタイ

ントには画面のクリック操作やセンサーの値の変化，ムで実装すべきコールバックメソッドを提示する手法

Android アプリの起動や画面遷移など様々な種類がある．これらのイベントに対し，Android フレーム

Recommending methods based on implementations ofexisting Android applications
Hayato Usui, 慶應義塾大学, Keio University.
Masataka Nagura, 日本大学, Nihon University.
Shingo Takada, 慶應義塾大学, Keio University.

ワークのライブラリはそれらを処理するためのコールバックメソッドのインタフェースを定義している．
開発者はコールバックメソッドを含むクラスやインタフェースを基底クラスとして継承しメソッドに具体

1
2
3
4
56

ソースコード 1 コールバックメソッドの実装の例@Override
public void onCallStateChanged(int state, StringincomingNum){if(state==TelephonyManager.
CALL STATE RINGING){musicPlayer.pause();}}

ソースコード 2 自動的に挿入されたメソッド宣言の例@Override
public void onCallStateChanged(int state, StringincomingNum){3 }12場合など，メソッド宣言だけ自動的に挿入されても，イベントを処理するためのメソッドの実装を忘れるこ的な処理を記述することで，個々のイベントに対すともある．そのような場合も，結果として Androidる処理を定義できる．例えば，OnClickListener インタ

アプリが開発者の意図しない振る舞いをしてしまう．

フェースを継承した場合には onClick メソッドを実装することにより画面内のボタンがクリックされた際の3 提案手法処理を定義でき，SensorEventListener インタフェース

3. 1 概要を継承した場合には onSensorChanged メソッドを実装

2 章で述べた課題を解決するため，我々は既存のプすることで端末のセンサーが新しく発生させたイベロジェクトを解析し，既存アプリに対するメソッドのントに対する処理を定義することができる．

実装状況を基に，実装すべきコールバックメソッドをコールバックメソッドの実装を，音楽再生アプリ開発者に提示する手法を提案する．我々の事前調査 [1]における onCallStateChanged メソッドを例に述べる．

では，Android アプリのコールバックメソッドの実装

onCallStateChanged メソッドは端末の着信状態の変化

状況には，次の特徴が存在することを明らかにした．というイベントによって実行されるメソッドである．

• 特徴 1 : 基底クラス／メソッドによって実装頻

ソースコード 1 は，開発者が onCallStateChanged メ

度が異なる場合があるソッドを実装したものである．3 行目は if 文によってある基底クラスを継承してクラスを作成する場着信状態をチェックしており，着信中の場合 4 行目の合，継承元の基底クラスによっては特定のコール処理が実行される．4 行目ではアプリによる音楽の再バックメソッドに対する実装頻度が，他のメソッ生を停止するメソッドを実行する．このような実装にドに比べて有意に高いメソッドが存在した．

より端末が着信中になった時 Android アプリは音楽• 特徴２：コールバックメソッド間で実装に共起の再生を停止する．

関係が存在する

ソースコード 1 のようにコールバックメソッドが実あるクラスであるメソッドが実装されている場合

装されている場合，Android アプリは開発者の意図に，別のクラスで特定のメソッドが実装される場した通りの振る舞いをする．しかしながら実装をして合があった．

いない場合，想定外の振る舞いをする可能性がある．

提案手法では，既存アプリに含まれるメソッドに

ソースコード 1 では，3 行目から 5 行目が無いと着信

対するこれらの実装状況を利用し，実装すべきメソッが来ても曲の再生が停止しなくなる．

ドを開発者に提示する．提案手法の処理の流れを図IDE によっては開発者がインタフェースや抽象ク

1 に示す．提案手法はまずライブラリ解析部により，ラスを継承した時に，ソースコード 2 のようなメソッAndroid フレームワークで提供されるライブラリファド宣言を自動的に挿入する機能を持つ． この場合，イルからメソッドやクラスを取得し，クラス間の継承開発者は挿入されたメソッド宣言に対して必要な処理関係とメソッドの実装やオーバーライドの関係を解を記述することで実装する．このように，コールバッ析する．次に，既存プロジェクト解析部はプロジェク

クメソッドの実装忘れに対し気づきを与えることがでトリポジトリから既存 Android プロジェクトのソーきる．しかし，コールバックメソッドの数が多くなるスファイルを取得する．そして，コールバックメソッ

図1

提案手法の処理の流れ

ドと Android フレームワークで提供されるメソッドファイルをすべて列挙し，クラス宣言とメソッドシグ

インタフェースに対する実装関係や，メソッドのオーネチャを取得する．取得したクラス宣言から，クラスバーライドの関係を解析し，既存プロジェクトでの実間の継承関係を作成し，継承関係のあるクラス間で同装状況を示すメトリクスを算出する．その上で，実装一シグネチャを持っているメソッドは，オーバーライ漏れ検出部が開発者の Android プロジェクトに含まドされているものとみなす．

れるソースファイルを解析し，実装状況メトリクスに従って実装漏れを検出する．これにより，開発者の3. 3 実装状況を示すメトリクス値の算出

Android プロジェクトのソースファイルに対して実3. 1 節で述べたように節事前調査においてコール装すべきコールバックメソッドを自動的に検出する．

バックメソッドの種類で実装頻度が異なること，コー以降では，3. 2 節にライブラリ解析部によるクラス間ルバックメソッド間に実装の共起関係が存在すること継承関係やメソッド間実装関係の解析手順を，3. 3 節を発見した．そこで図 1 の既存プロジェクト解析部に既存プロジェクト解析部による実装状況を表すメトは前者の関係を表す各メソッドの実装率と，後者の関リクス値の算出手順を，3. 4 節に実装漏れ検出部によ係を表すメソッドの実装共起率を示す 2 つのメトリる実装漏れ検出手順を述べる．

クス値を，既存プロジェクトのクラスの継承関係や、メソッドの実装状況から求める．本節ではこれらの算3. 2 ライブラリ解析の流れ
図 1 のライブラリ解析部は Android SDK [2] に含出方法を述べる．

3. 3. 1 メソッド実装率

まれる Jar ファイルからメソッドやクラスを取得し，コールバックメソッドにはよく実装されるものと，クラス間の継承関係とメソッドの実装やオーバーライあまり実装されないものがある．例えば Android 端末ドの関係を解析する．ライブラリに含まれるクラスはタッチパネルを持つものが多いため，クリック操作にplementedClasses は 2 となる．よって，メソッド M1の実装率は 50%(2/4) となる．メソッド M2 に注目すると，クラス Y で実装が行われる．クラス Y を継承するクラスでは，メソッド M2 のメソッド宣言のみを新たに記述しない限り，クラス Y でメソッドM2 に記述した処理がそのまま継承され，実装した場合と同じ状態になる．そのためクラス Y，A，B，C の全てにおいてメソッド M2 の処理が存在してお図2

Android フレームワークに含まれるクラスを継承したメソッド実装の例

り#ImplementedClasses は 4 となるため，メソッドM2 の実装率は 100%(4/4) となる．
3. 3. 2 メソッド実装共起率反応するメソッドである View.onClick() メソッドはよくメソッドには，C 言語の malloc() と free() のように実装される．また，端末のセンサーが発生させたイベ同時に利用される組み合わせが存在する．これらとントに反応する SensorEventListener.onSensorChanged()

同様に，コールバックメソッドにおいて同時に実装さメソッドもよく実装される．一方でセンサーの精度の変れている組み合わせがある．例えば LocationListener

化に反応する SensorEventListener.onAccuracyChanged()

インタフェースの onProviderEnabled() メソッドと on-メソッドは実装されることが少ない．開発者が Sen-ProviderDisabled() メソッドは，それぞれどちらかが実

sorEventListener インタフェースを継承し上記の on-装されている時に，高い割合でもう一方も実装されてSensorChanged() メソッドと onAccuracyChanged() メソいる．このように同時に実装されていることを実装のッドの両方を実装しなかった時，実装漏れの可能性が共起と呼ぶ．クラス内に実装されているコールバック

高いのは実装されることが多い onSensorChanged() メ

メソッドと共起する回数が多いメソッドの実装が欠落ソッドである．本提案手法ではメソッド単体についてしている場合，実装し忘れである可能性がある．そこの実装漏れを示すために，実装される割合である実装でメソッドの組み合わせから実装漏れを示すために，率を定義する．

メソッド間の共起の割合である共起率を定義する．

あるクラス（またはインタフェース）X に属する共起率を定義する際には，同じクラスのメソッド間

コールバックメソッド M の実装率は次の計算式で求と，異なるクラスのメソッド間の 2 つの場合に分けめる．て考える．同じクラスの場合はクラス単位で共起率を#ImplementedClasses#InheritedClasses
ここで#ImplementedClasses は X を基底クラス計算し，異なるクラスの場合はプロジェクト単位で共起率を計算する．

• クラス内メソッド実装共起率に持ち M が実装されているクラス数，#Inherited-

あるクラス（またはインタフェース）X を継承

Classes は X を基底クラスに持つクラス数である．

したサブクラス Y でコールバックメソッド M1

例として図 2 を考える．図 2 は Android フレームが実装されている時，クラス X に含まれる別のワーク内のインタフェース X を Android アプリプロ

コールバックメソッド M2 がクラス Y に実装さジェクトのクラス Y が実装し，さらにクラス Y をれる割合（クラス内メソッド実装共起率）を，次クラス A，B，C が継承している．インタフェースの計算式で求める．

X を基底クラスに持つクラスはクラス Y，A，B，Cであり，#InheritedClasses はそのクラス数である 4#ImplementedClassesOf M 1andM 2#ImplementedClassesOf M 1となる．インタフェース X のメソッド M1 は，クラここで#ImplementedClassesOfM1andM2 は X

ス Y，C の 2 クラスでは実装されないため，#Im-を基底クラスに持ち M1 と M2 の両方が実装されているクラス数，#ImplementedClassesOfM1
は X を基底クラスに持ち M1 の実施する処理が3. 4 実装漏れメソッドの検出
図 1 の実装漏れ検出部は，開発者の開発している定義されているクラス数である．

Android アプリのソースコードに対し，3. 3 節で算出

図 2 ではメソッド M1 はクラス A，B で，メソッした実装率と実装共起率のそれぞれの基準に従って，

ド M2 はクラス A，B，C で処理が記述されてい実装すべきコールバックメソッドを特定する．そしる．したがって両方のメソッドに処理が記述されて，それぞれの基準において実装すべき順に開発者にているのはクラス A，B の 2 つになる．そのた提示する．

めメソッド M2 が実装されている 4 クラスのう実装漏れ検出部はまず開発者の編集しているソー

ちの 2 クラスでメソッド M1 が実装されており，スコードを解析し，その中に含まれるクラスと，それ実装共起率は 50%(2/4) である．また，メソッドらが継承しているコールバックメソッドの実装の有無

M1 が実装されている 2 クラスの両方でメソッドを取得する．そして，実装されていないコールバックM2 が実装されており，実装共起率は 100%(2/2)

メソッドについて，既存プロジェクト解析部の取得しである．

たコールバックメソッドの実装率と実装共起率から，• クラス間実装共起率実装率に注目した場合と，実装共起率に注目した場あるクラス（またはインタフェース）X を継承し合のそれぞれについて実装すべきコールバックメソッ

たサブクラス Y でコールバックメソッド M1 がドを求める．

実装されている時，クラス XX を継承した別の実装率の基準に従った場合，実装率が高いにもかかサブクラス YY でコールバックメソッド M3 がわらず実装されていないコールバックメソッドは，実実装される割合（クラス間実装共起率）を次の計装漏れの可能性がある．そのため，実装率の高い順に算式で求める．

開発者に提示する．
実装共起率の基準に従った場合，あるメソッドが実#P rojectsImplementingM 1andM 3#P rojectsImplementingM 1

装されていた場合の共起率が高いにもかかわらず実

こ こ で#ProjectsImplementingM1andM3 は装されていないコールバックメソッドは，実装漏れのM1 と M3 を実装するクラスを持つプロジェクト可能性がある．そのため，開発者のあるクラスに着目数，#ProjectsImplementingM1 は M1 を実装すした時に，クラス内で実装されていないコールバックるクラスを持つプロジェクト数である．

メソッドの中で，同一クラスや別クラス内で実装され

図 2 では，メソッド M1 がクラス A，B で実装ているコールバックメソッドと実装の共起があるものされており，またメソッド M3 がクラス YY でを抽出する．そして，抽出したコールバックメソッド実装されている．この例では図示した 1 つのプと，そのメソッドに対する実装の共起率を提示する．

ロジェクトしか解析対象にしていないため，メその際に，同一クラス内で実装されているメソッドにソッド M1 を実装しているクラスを持つプロジェ共起している場合はクラス内実装共起率を，別クラスクト数である#ProjectsImplementingM1 は 1 で内で実装されているメソッドに共起している場合はクある．また，メソッド M1 とメソッド M3 はともラス間実装共起率を，それらの実装共起率の種類によにこのプロジェクトで実装されている．両方のらず，高い順にメソッドをソートした上で提示する．

メソッドを実装しているプロジェクト数である

開発者は提示された検出結果表示から，実際に開発#ProjectsImplementingM1andM3 は 1 である．

者の意図しない実装漏れであるかどうかを確認する

よってメソッド M1 とメソッド M3 のクラス間実ことができる．

装共起率は 100%(1/1) となる．

た情報を組み合わせ，図 2 のようなクラスの継承関

4 実装係を抽出する．その際に，基底クラスで実装されてい4. 1 全体の構成るメソッドについては，すべてのサブクラスに対して本章では 3 章で述べた提案手法の実装について述べ実装されているものとマークする．同時に各プロジェる．提案手法のうち，実装漏れ検出は Android Studio

クトのクラスのうち，抽象クラスまたはインタフェー[2] のプラグインとして実装を行った．一方ライブラス以外のクラスにおいて，ライブラリ解析部の抽出

リ解析と既存プロジェクト解析は処理時間を要するしたメソッドを継承している場合，そのメソッドが実ため，プラグインとは別個に実装した．ライブラリ解装されているかどうかに基づいて，実装率を算出す析と既存プロジェクト解析によって得たデータはデーる．さらに，同じクラスに，Android フレームワータベースに蓄積し，プラグインはデータベースからクの特定のクラスのメソッドが複数個実装されていメソッド一覧や実装状況を表すメトリクスを取得する場合は，クラス内実装共起率を算出する．Androidるように実装した．そして，全ての処理は Java を用

フレームワーク内の全てのクラスを起点とする探索いて実装し，データベースには SQLite3 [3] を用いた．

が終了した後，各既存プロジェクトを確認し，1 つの以降では 4. 2 節でライブラリ解析部と既存プロジェプロジェクト内で異なるクラスのメソッドが実装されクト解析部の実装を，4. 3 節では実装漏れ検出部の実ている場合，クラス間実装共起率を算出する．最後

装を，4. 4 節では実装したプラグインによる提示を述に，Android フレームワーク内の各メソッドについべる．て，3. 3 節で述べた計算式を用いて実装率と実装共起率を計算し，算出した値をデータベースに蓄積する．

4. 2 ライブラリ解析処理と既存プロジェクト解析処理

4. 3 実装漏れ検出処理

ライブラリ解析部は，ライブラリファイルからメ

本節では実装漏れ検出処理の実装について述べる．

ソッドやクラスの関係を解析する，まず Android SDK

実装漏れ検出部は Android Studio のプラグインとしに付属の，ユーザが実装に利用できるクラスファイルて実装した．プラグインを実行すると，現在開発者をまとめた android.jar が含む全クラスから，それぞが編集しているプロジェクトの Java ファイルを解析れのインスタンスを生成する．そして，リフレクショする．解析には IntelliJ Platform SDK [6] を利用し，ン API を利用して各インスタンスからクラス名，ク各 Java ファイル内のクラスごとに，そのクラスが継ラスに含まれるメソッドのシグネチャ，クラスやメ承しているメソッドと実装しているメソッドを取得

ソッドの継承関係を抽出する．

する．

既存プロジェクト解析部は，既存 Android プロジェ

開発者によって編集作業中の Java ファイルに含まクトのソースファイルを取得し，コールバックメソッれるクラスが別のクラスを継承しており，未実装のドの実装率や実装共起率を算出する．入力であるプ

コールバックメソッドが存在する場合，データベースロジェクトリポジトリのソースコードには，F-Droidから実装率を取得し，それらのメソッドを実装率が高[4] に公開されている全ての Android アプリプロジェ

い順に提示する．

クト 2,196 個のうち，完全に Java 以外の言語で記述

また，編集中のクラスで実装済みのコールバックされている 46 個のプロジェクトを除外した 2,150 個

メソッドについては，データベースからそのメソッドを用いた．これらのプロジェクトのソースコードをと実装の共起があるコールバックメソッドを検索し，入力すると，既存プロジェクト解析部は Eclipse Java

そのようなメソッドが存在する場合は，実装共起率をdevelopment tools [5] の AST パーサを利用して，全取得する．検出の結果として得られたコールバックメてのクラスからメソッド宣言と基底クラスの情報を取ソッドのうち，実装されていないものを抽出し，実装得する．これらの情報とライブラリ解析部の抽出し共起率が高い順に提示する．

4. 4 プラグインによる検出結果の提示

表1

コミット C0 におけるメソッドの実装状況

本節では提案手法を実装したプラグインによる，実装すべきコールバックメソッドの提示について述べる．図 3 は Android Studio の画面であり，下半分にあるウィンドウが検出結果の提示部分である．プラグクラス P

クラス Q

onLocationChanged◯×onProviderEnabled

××

onProviderDisabled

××

onStatusChanged

××

インを実行すると，直前に編集していた Java ファイル (図 3 の上部に表示されている Java ファイル) を

表2

コミット C1 におけるメソッドの実装状況

解析し，提案手法により検出した実装すべきコールバックメソッドを下半分のウィンドウに表示する．実装すべきコールバックメソッドは木構造を用いて表される．木の根には解析した Java ファイル名を表示し，

クラス P

クラス Q

onLocationChanged◯◎onProviderEnabled

××

onProviderDisabled

××

onStatusChanged◎◎

その直下には Java ファイル内で宣言されているすべてのクラスの名前とその先頭の行番号を表示する．無onLocationChanged メソッド，onStatusChanged メソッ

名クラスを宣言している場合は，実装元の基底クラド，onProviderEnabled メソッド，onProviderDisabled メスの名前を表示する．クラス名の下には実装率につソッドの 4 つのコールバックメソッドを持つ．コミッ

いての情報（Frequencies）と，実装共起率について

ト C0 において開発者は表 1 のようにそれぞれのコーの情報（Co-occurrences）を表示する．Frequencies

ルバックメソッドを実装していた．には，4. 3 節で求めた実装率に基づき検出された実装

開発者は，2 日後に次のコミット C1 を行った．そし漏れコールバックメソッドの候補が実装率の高い順にて実装状況は，表 2 のように変化した． コミット C0

提示され，Co-occurrences には実装共起率に基づきからコミット C1 の間に，開発者はクラス P の onSta-

検出された実装漏れコールバックメソッドの候補が実

tusChanged メソッド，クラス Q の onLocationChanged

装共起率の高い順に提示される．なお，複数のコールメソッドと onStatusChanged メソッドを実装していた

バックメソッドが特定の未実装のコールバックメソッ（表 2 では，◎で示す）．なお表 2 内で〇や◎でマードと共起する場合，この未実装のメソッドに関してクしたメソッドは，その後のコミットでも削除される算出された複数の共起率の中で最も高い値を提示すことはなく，また×でマークしたメソッドは，その後る．実装漏れメソッドの候補には，そのコールバックのコミットでも追加されることはなかった．

メソッドを定義している Android フレームワークの

ここで，コミット C0 直後の時点に着目し，コミッ基底クラスと，実装率や実装共起率の計算に用いた

ト C1 で実装されたメソッド群 （表 2 の◎で示した数値を表示する．Co-occurrences についてはさらに，メソッド群）を，実装漏れにより追加されたメソッド

表示対象のクラスのどのメソッドとの共起によって提群であるとみなす．そしてコミット C0 直後のソース示されているかの情報も合わせて表示する．

コードに対して提案手法のツールを適用し，実装すべきコールバックメソッドを抽出し，提示させた．そ5 ケーススタディの結果，クラス P と Q に対しそれぞれ図 4 と図 5 の本章では実際の開発中のプロジェクトに対して提ように実装漏れコールバックメソッドの候補が提示さ案手法を適用した時に，実装漏れを指摘できるかをれた．

確認する．対象としたプロジェクトは，GitHub [7]図 4，図 5 では Frequencies に未実装のコールバッで公開されている地図アプリである．このプロジェ

クメソッドそれぞれの実装率を，高い順に提示する．

クトでは，あるコミット C0 であるクラス内に Loca-

また Co-occurrences には，そのクラスで実装されてtionListener インタフェースを実装したクラス P と Qいるコールバックメソッドとの実装共起率を，高い順を作成していた．LocationListener インタフェースはに提示する．クラス P では onLocationChanged メソッ

図3

提案手法による検出結果の提示

図5

コミット C0 直後のクラス Q に対する実装漏れメソッド候補の提示

図4

コミット C0 直後のクラス P に対する実装漏れメソッド候補の提示

ドが実装されているため，図 4 は，onLocationChanged
メソッドと他のコールバックメソッドとの実装共起率が提示されている．いずれの値も小さくなっており，実装されていないことを示す以上の働きができまた，コールバックメソッドの実装漏れに対するるとは考え難い．また，図 5 のクラス Q に対する表研究として，テストが挙げられる．Adamsen らは通示では，C0 時点ではどのメソッドも未実装であるた常とは異なる状況でテストを行う Thor を提案した

め，Co-occurrences については表示しない．しかし，[14]．Amalfitano らは外部イベントを含むテストを行Frequencies から，onLocationChanged メソッドの実装

う ExtendedRipper を提案した [15]．また，Yu は継率が非常に高いことがわかる．これにより，開発者に承されていない Android API のメソッドを引き起こ

onLocationChanged メソッドの実装の必要性を気付かすイベントを含むテストケースの生成手法を提案しせることができる．

た [16]．これらの研究はテストの段階で実装に問題がなお，この例で利用したプロジェクトに含まれるメあることを発見する．しかしながらテストで発見したソッド群は，共起して実装されることがあまりなかっ問題の修正のために開発への手戻りが発生し，これにたため，図 4 に示すように実装共起率がそれほど高はコストがかかる．本提案手法は開発段階で実装すくならなかった．

べきメソッドを提示するため，手戻りが少なくなる．
一方で提案手法は実装漏れの指摘であり実装内容の6 関連研究不備を指摘することはできない．

関連研究として，コードレコメンデーションに関する研究が挙げられる．コードレコメンデーションと7 結論

は，開発者がプログラムを記述している時に内容を本論文では，既存 Android アプリケーションにお補完するコードを提示することである．Ye らは入力

けるコールバックメソッドの実装率，実装共起率に基中の文字列や開発者のユーザモデルを基に，開発者づいた，実装すべきメソッドの提示手法を提案した．の知らないメソッドの利用を提示する手法を提案しこれにより，コールバックメソッドの実装漏れを防ぐた [8]．渡邉らは開発者が記述しているコードに関連ことができる．

したサンプルプログラムを，連想検索エンジンを用

今後の課題としては開発者に提示する基準や内容いてリポジトリから検索し提示する Selene を提案しの増加および，提案手法の評価実験が挙げられる．

た [9]．村上らは開発者が記述しているメソッドの呼び出し関係や編集履歴を用いた手法を提案した [10]．
またその他の関連研究として，メソッドのチェンジレコメンデーションに関する研究が挙げられる．チェ
ンジレコメンデーションとは開発が進みプログラムに変更が加わった時，変更する必要があるメソッドを提示することである．Xia らはプログラム内の依存関係のグラフ化，グラフの探索および遺伝的アルゴリズムによって変更すべき箇所を提示する SupLocatorを提案した [11]．Rolfsnes らはアソシエーションルー
ルマイニングをチェンジレコメンデーションに用いることが有効であることを示す調査を行った [12] [13]．
これらの研究は開発者が実装すべきメソッドの存在を知り，それを実装している時や実装した後に利用できるものである．提案手法は開発者が実装していないメソッドを提示し，実装漏れを防ぐという点でこれらの研究と異なる．

参 考 文 献[1] H. Usui, M. Nagura and S, Takada, “Investigating
Tendencies in Callback Method Implementations inAndroid Applications”, Proceedings of the 8th IEEE
International Workshop on Empirical Software Engineering in Practice, pp. 23-28, 2017.
[2] Google, “Android Studio (online),” available
from, https://developer.android.com/studio/index.
html, accessed Aug.31, 2017.
[3] SQLite, “SQLite (online),”, https://sqlite.
org/index.html, accessed Aug.31, 2017.
[4] F-Droid, “F-Droid (online),” available from,https://f-droid.org/, accessed Aug.31, 2017.
[5] The Eclipse Foundation, “Eclipse Java development tools (online),” available from http://www.
eclipse.org/jdt/, accessed Aug.31, 2017.
[6] JetBrains, “IntelliJ Platform SDK (online),”available from http://www.jetbrains.org/intellij/sdk/docs/welcome.html, accessed Aug.31, 2017.
[7] GitHub, “GitHub (online),”, https://github.
com, accessed Aug.31, 2017.
[8] Y. Ye and G, Fischer, “Supporting Reuse by De-

livering Task-Relevant and Personalized Information”, Proceedings of the 24th International Conference on Software Engineering, pp. 513-523, 2002.
[9] T. Watanabe and H, Masuhara, “A Spontaneous
Code Recommendation Tool Based on AssociativeSearch”, Proceedings of the 3rd International Workshop on Search-Driven Development: Users, Infrastructure, Tools, and Evaluation, pp. 17-20, 2011.
[10] N. Murakami, H. Masuhara and T, Aotani, “CodeRecommendation Based on a Degree-of-InterestModel”, Proceedings of the 3rd International Workshop on Search-Driven Development: Users, Infrastructure, Tools, and Evaluation, pp. 17-20, 2011.
[11] X. Xia and D, Lo, “An eﬀective change recommendation approach for supplementary bug fixes”,
Automated Software Engineering, vol. 24, num. 2,pp. 455-498, 2017.
[12] T, Rolfsnes, L. Moonen, S. D. Alesio, R, Behjati
and D. Binkley, “Improving Change Recommendation using Aggregated Association Rules”, Proceedings of the 13th International Conference on Min-ing Software Repositories, pp. 73-84, 2016.
[13] L. Moonen, S. D. Alesio, D. Binkley and T, Rolfsnes, “Practical Guidelines for Change Recommendation using Association Rule Mining”, Proceedingsof the 31st IEEE/ACM International Conference
on Automated Software Engineering, pp. 732-743,
2016.
[14] C. Q. Adamsen, G. Mezzetti and A. Moller, “Systematic execution of Android test suites in adverse conditions”, Proceedings of 2015 International
Symposium on Software Testing and Analysis, pp.
83-93, 2015.
[15] D. Amalfitano, A. R. Fasolino and P. Tramontana, “Considering Context Events in EventBased Testing of Mobile Applications”, Proceedings of Software Testing, Verification and Validation Workshops, pp. 126-133, 2013.
[16] S. Yu and S. Takada, “Mobile application test casegeneration focusing on external events”, Proceedingsof 1st International Workshop on Mobile Development, pp. 43-44, 2016.