Transcript V - qwik.jp

ICSE 2012 勉強会
セッション: Code Recommenders
早瀬，小山田，中村
筑波大学 北川研究室
Automatic Parameter Recommendation
for Practical API Usage
Cheng Zhang, Juyuan Yang, Yi Zhang, Jing Fan,
Xin Zhang, Jianjun Zhao, Peizhao Ou
Shanghai Jiao Tong University, China
担当： 早瀬
概要
• コード補完の研究が活発
– 必要なコードが，上位に出てくれば有用
– メソッド名の選択までしか支援してくれないものが多い
→ 実引数も推薦して欲しい
– Eclipse プラグイン Precise を開発
• コードベースから知識を蓄積
• 補完しようとしている場所の，直前までのコードを検索クエリとする
– Top10 までの評価で，53%の正答率 (さらに，64%は有用なヒントにな
る)
• 問題: 実引数には複雑な式を書けるため，膨大な候補が存在しう
る
– 変数，メソッド呼び出し，リテラル，配列アクセス
– それらを組み合わせた式
予備調査
• 実際のコードでは，どのような式が実引数に
書かれている?
約9割は「単純な」式．
⇒ 算術演算などの「複雑な構
造」を取り扱わないことにする
出典: “Automatic Parameter Recommendation
for Practical API Usage”, ICSE2012
もう1つの調査: 95% の各実引数は要素数3つ以下だった．
⇒ 補完候補も，要素数3つまでに限定
手法
• シンプルな構造の実引数のみを取り扱う
• 文献[9]の手法に基づいている
– 既存コードベースから知識を構築
– 補完対象の文脈で，知識を検索
– 見付かった事例を，現在の文脈に適合させて挿
入
[9] M. Bruch et al., Learning from examples to improve code completion systems. ESEC/FSE ’09
知識の構築と検索に用いる特徴
• コードベース中の各実パラメータに対して，4
種類の特徴を収集
注目 (p1 と命名)
出典: “Automatic Parameter Recommendation for Practical API Usage”, ICSE2012
特徴1： 仮引数
• どの仮引数にバインドされるか
⇒ Panel::setAttrib::1(int)
出典: “Automatic Parameter Recommendation for Practical API Usage”, ICSE2012
特徴2： 所属メソッドのシグネチャ
⇒ addButton(Panel)
(戻り値の型は含まれない?)
出典: “Automatic Parameter Recommendation for Practical API Usage”, ICSE2012
特徴3： 実引数で使われている変数に
対する，メソッド呼出し
• この例で，登場する変数は b
⇒ <<init>(), setVisible(boolean), setAttrib(int)>
出典: “Automatic Parameter Recommendation for Practical API Usage”, ICSE2012
特徴4：実引数が使われる際のベース
オブジェクトに対する，メソッド呼出し
⇒ <init(), addElement(Object), setAttrib(int)>.
出典: “Automatic Parameter Recommendation for Practical API Usage”, ICSE2012
Active Code Completion
Cyrus Omar, YoungSeok Yoon,
Thomas D. LaToza, Brad A. Myers
Carnegie Mellon University
担当： 早瀬
モチベーション
• 既存のコード補完システムは，選択肢ベース
のものがほとんど
– もっとリッチなシステムが欲しい
• 例:
選択肢だけではなく，
名前での検索が可能
出典: Omar et al., “Active Code Completion”, ICSE 2012
提案手法: Active code completion
• ライブラリ開発者が，簡単に，高度なコード補完システムを作れる枠組み
• オブジェクトの生成を対象
• 作成にあたり，473人のソフトウェア開発者に質問を実施 (Section II)
• 質問の結果と，コードコーパスの調査から，要求を決定 (Section III)
• 開発者がどんなパレットを欲しがっているかを調査 (Section IV)
• Active code completion の設計および，実装である「Graphite」の説明
(Section V)
– デザイン上のトレードオフについても説明
• 実験 (Section VI)，関連研究(Section VII), Conclusion (Section VIII)
– 本発表では省略します
Section II. Survey
• 対象: reddit.com で募集した開発者 696 人
• Mockupを提示
– Color class
– regular expression class
– SQL query class
• 質問の内容
– 普段，インスタンスを作るとき，どのようにしているか?
→ 外部ツールが使われている
– (もしツールがあるなら)どれくらいの頻度で使いたいか?
→ 好評．特にRegular expressionは需要が高そう
– 自由記述
Section III : Design Criteria
開発者の意見を整理
• A. Maintaining Separation of
Concerns
– インスタンスを作りやすいために，
結果的に，モジュラリティが下がっ
てしまうとの懸念
– prototyping には向いていそう
• B. Integration with Testing
Frameworks
– RegexpのUIでは，簡単に記述した
正規表現をテストできるようにした
– 入力した内容を使って，単体テスト
を生成して欲しいの意見
• C. Support for Reinvocation
– 生成されたコードから，補完パレッ
トの状態を復元させたいとの意見
• D. Support for Palette Settings
and History
• E. Support for Nested Expressions
– Mockupでは，定数を使った生成し
かできなかった
– 周囲の変数やメソッドを使った生
成もしたい
•
•
•
•
F. Keyboard Navigability
G. Responsiveness
H. IDE and Language Portability
I. Varying User Needs
– 同じクラスでも，人によって要求は
違う
Section IV : Use Cases
提示したMockup以外に，どのような補完パレットがあったら嬉しいか?
• A. Graphical Elements
• B. Query Language
• C. Simplified or Domain-Specific Syntax
– 文字列のエスケープや，HTMLの入力，数式など
– Java で， ArrayList や HashMap の初期化を楽にしてほしい
• Fig. 4 に， Code Corpus の調査結果
• D. Unclear Parameter Implications
– 分かりにくいパラメータを，その場で試して確認したい
– 例: オーディオやアニメーションを操作するクラスのパラメータを，その場で再
生することで確認する
•
•
•
•
E. Integrating with Documentation and Examples
F. Complex Instantiation and Cleanup Procedures
G. Instantiation by Example
H. Proof Assistants
Section V. System Design and
Implementation
調査結果を踏まえて， Graphite (Eclipseプラグイン)の設計方針を決定
• A. HTML5-Based Pallets
– UI構築の容易さや，移植性を重視
•
B. Palette API
– シンプルな Javascript API を策定
•
C. Palette Discovery
– Annotation-based: クラスにアノテーションを付与することで，どのパレットを使うかを示す
– Explicit: IDEの利用者が個別に設定・選択する (クラスを編集できない場合などに使用)
•
設計上のトレードオフ
–
–
–
–
Javascript を採用するため，補完対象となる言語の要素を直接使用することが難しい
ポップアップウィンドウの中で完結する必要がある
周辺のコードを取得することは難しい
パレットのReinvocationを実現するには，Javascript側でコードをパースしなければいけない
Section V ...
• 作成してみたパレット
– Color selection (最初に提示したもの)
– Regular Expressions
出典: Omar et al., “Active Code Completion”, ICSE 2012
実験以降は省略
On The Naturalness of Software
A. Hindle*, M. Gabel**, P. Devanbu*
* UC Davis, ** UT Dallas
• IDE の補完機能
変数の型 (クラス) を特定し
そのメンバを補完候補とする
– 型情報に基づく
– もっとリッチな補完ができないか？
• 言語モデル
– 入力文章が “どれだけその言語らしいか” (確率分布)
• 私, の, 猫 → 0.3
• 私, な, 猫 → 0.0001
• 本研究: 言語モデルを使ったコード補完
– コードをn-gramトークン列と解釈し言語モデル作成
– 例: C 言語で “for (“ の後に続くトークンを補完
• for, (, int → 0.3
• for, (, float → 0.005
最も「C らしい」 int を推薦
担当: 小山田 (筑波大)
ソースコードに対する統計的言語モデル
• 作成手順
– ソースコードから n-gram のトークン列を切り出す
– 先頭 n-1 トークンが等しい n-gram 毎に出現確率を計算
– 例: 3-gram で先頭 2 トークンが for, (
for, (, int
for, (, float
for, (, double
for, (, int
for, (, int
for, ( から始まる 3-gram
3-gram
確率
for, (, int
3/5 = 0.6
for, (, float
1/5 = 0.25
for, (, double
1/5 = 0.25
• スムージング
– ゼロ頻度問題への対処
自然言語処理でよく使われる
スムージング方式
• 出現確率の低い n-gram の出現確率を補正
– 良好な結果を示した Modified Kneser-Ney を採用
• 他には Good–Turing が有名
有効性の確認
• 疑問
– ソースコードに対して言語モデルは有効？
– きちんと特徴をとらえることができる？
→ 検証実験により有効性を確認
• 英語との比較（言語モデルの質, Perplexity）
– ソースコードの方が良い言語モデルに
– プログラミング言語の構文が限られているため？
• ソフトウェアのカテゴリと言語モデルの関係
– 言語モデルはカテゴリの特徴をよく表現できる
• データベースシステム, ペイントソフト, OS, …
– 新規プロジェクト: コーパス (ソースコード) が無い
• 同じカテゴリに属すコーパスの言語モデルを利用できる
補完機能の実装
• 実装: Eclipse の補完プラグイン
– コーパスベースな 3-gram 統計的言語モデル
• 実験: 標準の補完機構からの性能向上率
– 標準のものよりも高い性能を示す
– suggest されるトークンの文字列が長くなるほど性
能向上率が下がる
• 長いトークンのコーパス内出現頻度は低く低精度
tooLongLongName よりも x のほうがよく出現する
• 改善: 標準の補完機構との組合せ
– トークンの文字数が一定以上なら Eclipse 標準の
補完機構を用いる
Recommending Source Code for Use
in Rapid Software Prototypes
Collin McMillan†, Negar Hariri‡, Denys Poshyvanyk†,
Jane Cleland-Huang‡, and Bamshad Mobasher‡
†College of William and Mary
‡DePaul University
Presenter : 筑波大学 北川研 中村高士
Introduction
• 目的
– Software prototypes の作成の高速化
• 手法
– オープンソースのソフトウェアリポジトリから
機能説明やソースコードをマイニングすることで，
ソフトウェアを再利用
– 既存手法の短所に対処
• 必要最低限のパッケージ単位の推薦を行うことで，
ソースコードの理解や統合に必要なコストを軽減
手法の流れ
1
3
2
※論文より引用
1.リポジトリからの情報抽出
• 機能の説明から機能を抽出しクラスタ化
• ソースコードからモジュールを抽出
• 機能とモジュールを関連付け
– Portfolio[24]を利用
2.機能の推薦
• 初めにユーザが必要とする機能の概要を記
述し，それに基づき関連する機能を推薦
• 推薦された機能をユーザが選択することで，
選択した機能と関連する機能を推薦
– K-NN法を利用
※論文より引用
3.モジュールの推薦
• 2.で選択した機能と関連するモジュールを推
薦
– 目標
• 目的の機能をより多くカバーする
• 推薦されるプロジェクト数を最小化する
• 推薦されるパッケージのモジュール間の結合度
(external coupling) を最小化する
– 必要な機能を全てカバーするパッケージ集合を
求めるのは NP-complete なので，近似解を用い
る[34]
評価と結果
• 現行手法[24]と提案手法のそれぞれによって
推薦されたパッケージ集合を評価してもらい，
結果を比較
– 被験者はプログラミング経験のある31人
– 比較する観点は Relevance, Precision, Coverage,
Time の4つ
※論文より引用