1 / 29

ICSE 2012 勉強会 セッション : Code Recommenders

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 担当： 早瀬. 概要. コード補完の研究が活発

martin-blanchard
Download Presentation

ICSE 2012 勉強会 セッション : Code Recommenders

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ICSE 2012 勉強会セッション: Code Recommenders 早瀬，小山田，中村 筑波大学 北川研究室

  2. Automatic ParameterRecommendation for Practical API Usage Cheng Zhang, JuyuanYang, Yi Zhang, Jing Fan, Xin Zhang, JianjunZhao, PeizhaoOu Shanghai Jiao Tong University, China 担当： 早瀬

  3. 概要 • コード補完の研究が活発 • 必要なコードが，上位に出てくれば有用 • メソッド名の選択までしか支援してくれないものが多い→ 実引数も推薦して欲しい • Eclipse プラグイン Precise を開発 • コードベースから知識を蓄積 • 補完しようとしている場所の，直前までのコードを検索クエリとする • Top10 までの評価で，53%の正答率 (さらに，64%は有用なヒントになる) • 問題: 実引数には複雑な式を書けるため，膨大な候補が存在しうる • 変数，メソッド呼び出し，リテラル，配列アクセス • それらを組み合わせた式

  4. 予備調査 • 実際のコードでは，どのような式が実引数に書かれている? 約9割は「単純な」式． ⇒ 算術演算などの「複雑な構造」を取り扱わないことにする 出典: “Automatic ParameterRecommendation for Practical API Usage”, ICSE2012 もう1つの調査: 95% の各実引数は要素数3つ以下だった． ⇒ 補完候補も，要素数3つまでに限定

  5. 手法 • シンプルな構造の実引数のみを取り扱う • 文献[9]の手法に基づいている • 既存コードベースから知識を構築 • 補完対象の文脈で，知識を検索 • 見付かった事例を，現在の文脈に適合させて挿入 [9] M. Bruch et al., Learningfrom examples to improve code completion systems. ESEC/FSE ’09

  6. 知識の構築と検索に用いる特徴 • コードベース中の各実パラメータに対して，4種類の特徴を収集 注目 (p1 と命名) 出典: “Automatic ParameterRecommendation for Practical API Usage”, ICSE2012

  7. 特徴1： 仮引数 • どの仮引数にバインドされるか⇒ Panel::setAttrib::1(int) 出典: “Automatic ParameterRecommendation for Practical API Usage”, ICSE2012

  8. 特徴2：所属メソッドのシグネチャ ⇒addButton(Panel) (戻り値の型は含まれない?) 出典: “Automatic ParameterRecommendation for Practical API Usage”, ICSE2012

  9. 特徴3：実引数で使われている変数に対する，メソッド呼出し特徴3：実引数で使われている変数に対する，メソッド呼出し • この例で，登場する変数は b ⇒ <<init>(), setVisible(boolean), setAttrib(int)> 出典: “Automatic ParameterRecommendation for Practical API Usage”, ICSE2012

  10. 特徴4：実引数が使われる際のベースオブジェクトに対する，メソッド呼出し特徴4：実引数が使われる際のベースオブジェクトに対する，メソッド呼出し ⇒ <init(),addElement(Object), setAttrib(int)>. 出典: “Automatic ParameterRecommendation for Practical API Usage”, ICSE2012

  11. Active Code Completion Cyrus Omar, YoungSeokYoon, Thomas D. LaToza, Brad A. Myers Carnegie Mellon University 担当： 早瀬

  12. モチベーション • 既存のコード補完システムは，選択肢ベースのものがほとんど • もっとリッチなシステムが欲しい • 例: 選択肢だけではなく， 名前での検索が可能 出典: Omar et al., “Active Code Completion”, ICSE 2012

  13. 提案手法: Active code completion • ライブラリ開発者が，簡単に，高度なコード補完システムを作れる枠組み • オブジェクトの生成を対象 • 作成にあたり，473人のソフトウェア開発者に質問を実施 (Section II) • 質問の結果と，コードコーパスの調査から，要求を決定 (Section III) • 開発者がどんなパレットを欲しがっているかを調査 (Section IV) • Active code completion の設計および，実装である「Graphite」の説明 (Section V) • デザイン上のトレードオフについても説明 • 実験 (Section VI)，関連研究(Section VII), Conclusion (Section VIII) • 本発表では省略します

  14. Section II. Survey • 対象: reddit.com で募集した開発者 696 人 • Mockupを提示 • Color class • regular expression class • SQL query class • 質問の内容 • 普段，インスタンスを作るとき，どのようにしているか? → 外部ツールが使われている • (もしツールがあるなら)どれくらいの頻度で使いたいか? → 好評．特にRegular expressionは需要が高そう • 自由記述

  15. 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 • 同じクラスでも，人によって要求は違う

  16. 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

  17. 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側でコードをパースしなければいけない

  18. Section V ... • 作成してみたパレット • Color selection (最初に提示したもの) • Regular Expressions 出典: Omar et al., “Active Code Completion”, ICSE 2012 実験以降は省略

  19. On The Naturalness of SoftwareA. 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を推薦 担当: 小山田 (筑波大)

  20. ソースコードに対する統計的言語モデル • 作成手順 • ソースコードから n-gram のトークン列を切り出す • 先頭 n-1 トークンが等しい n-gram 毎に出現確率を計算 • 例: 3-gram で先頭 2 トークンが for, ( • スムージング • ゼロ頻度問題への対処 • 出現確率の低い n-gram の出現確率を補正 • 良好な結果を示したModified Kneser-Ney を採用 • 他には Good–Turing が有名 for, (, float for, (, int for, (, double for, (, int for, (, int for, ( から始まる 3-gram 自然言語処理でよく使われる スムージング方式

  21. 有効性の確認 • 疑問 • ソースコードに対して言語モデルは有効？ • きちんと特徴をとらえることができる？ • 英語との比較（言語モデルの質, Perplexity） • ソースコードの方が良い言語モデルに • プログラミング言語の構文が限られているため？ • ソフトウェアのカテゴリと言語モデルの関係 • 言語モデルはカテゴリの特徴をよく表現できる • データベースシステム, ペイントソフト, OS, … • 新規プロジェクト: コーパス (ソースコード) が無い • 同じカテゴリに属すコーパスの言語モデルを利用できる →検証実験により有効性を確認

  22. 補完機能の実装 • 実装: Eclipse の補完プラグイン • コーパスベースな 3-gram 統計的言語モデル • 実験:標準の補完機構からの性能向上率 • 標準のものよりも高い性能を示す • suggest されるトークンの文字列が長くなるほど性能向上率が下がる • 長いトークンのコーパス内出現頻度は低く低精度 • 改善:標準の補完機構との組合せ • トークンの文字数が一定以上なら Eclipse 標準の補完機構を用いる tooLongLongNameよりも x のほうがよく出現する

  23. Recommending Source Code for Use in Rapid Software Prototypes Collin McMillan†, Negar Hariri‡, Denys Poshyvanyk†, Jane Cleland-Huang‡, and BamshadMobasher‡ †College of William and Mary ‡DePaul University Presenter : 筑波大学 北川研 中村高士

  24. Introduction • 目的 • Software prototypesの作成の高速化 • 手法 • オープンソースのソフトウェアリポジトリから機能説明やソースコードをマイニングすることで，ソフトウェアを再利用 • 既存手法の短所に対処 • 必要最低限のパッケージ単位の推薦を行うことで，ソースコードの理解や統合に必要なコストを軽減

  25. 手法の流れ 1 3 2 ※論文より引用

  26. 1.リポジトリからの情報抽出 • 機能の説明から機能を抽出しクラスタ化 • ソースコードからモジュールを抽出 • 機能とモジュールを関連付け • Portfolio[24]を利用

  27. 2.機能の推薦 • 初めにユーザが必要とする機能の概要を記述し，それに基づき関連する機能を推薦 • 推薦された機能をユーザが選択することで，選択した機能と関連する機能を推薦 • K-NN法を利用 ※論文より引用

  28. 3.モジュールの推薦 • 2.で選択した機能と関連するモジュールを推薦 • 目標 • 目的の機能をより多くカバーする • 推薦されるプロジェクト数を最小化する • 推薦されるパッケージのモジュール間の結合度 (external coupling) を最小化する • 必要な機能を全てカバーするパッケージ集合を求めるのは NP-complete なので，近似解を用いる[34]

  29. 評価と結果 • 現行手法[24]と提案手法のそれぞれによって推薦されたパッケージ集合を評価してもらい，結果を比較 • 被験者はプログラミング経験のある31人 • 比較する観点は Relevance, Precision, Coverage, Timeの4つ ※論文より引用

More Related