1 / 27

Detecting Similar Software Applications

Detecting Similar Software Applications. Collin McMillan, Mark Grechanik , and Denys Poshyvanyk. 紹介： 大阪 大学大学院情報科学研究科 コンピュータサイエンス専攻 楠本研究室 堀田 圭佑. 研究 概要. “ 似ている ” ソフトウェアを見つける 例： 過去のプロジェクトの中から，新規プロジェクトと似ているプロジェクトを見つける 再利用により，開発に要す る時間や資源を削減可能 過去の類似プロジェクトによって得た知識，経験が活用できる 貢献

phaedra-calliope
Download Presentation

Detecting Similar Software Applications

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. Detecting Similar Software Applications Collin McMillan, Mark Grechanik, and Denys Poshyvanyk 紹介： 大阪大学大学院情報科学研究科 コンピュータサイエンス専攻 楠本研究室 堀田 圭佑

  2. 研究概要 • “似ている”ソフトウェアを見つける • 例：過去のプロジェクトの中から，新規プロジェクトと似ているプロジェクトを見つける • 再利用により，開発に要する時間や資源を削減可能 • 過去の類似プロジェクトによって得た知識，経験が活用できる • 貢献 • API呼び出しに着目した，Javaプログラム間の類似度算出手法を提案 • それを実装したツール，CLANを開発 • 既存ツール MUDABlueよりも高精度で似ているソフトウェアを特定できることを確認

  3. 提案手法の概要 • アプローチ • キーアイデア • 2つのソフトウェアが同じAPI呼び出しを含むならば，そうでない場合よりも類似度が高い • 多くのソフトウェアから呼ばれるAPIは重要度が低く，少数のソフトウェアから呼ばれるAPIは重要度が高い • 2つのソフトウェアが同じAPI呼び出しパターンを含むならば，そうでない場合よりも類似度が高い ソースコード中のキーワード(変数名など)に基づく テキストベースの類似度算出 既存研究 本研究 呼び出されているAPIに着目した類似度算出

  4. 評価方法 • 33人の被験者を使った実験 • 比較対象 • MUDABlue，Combined(MUDABlue & CLAN) • 手順 • ある1つのソフトウェアを入力として，CLAN，MUDABlue，Combinedのそれぞれを使って類似ソフトウェアを検出させる • そのうち上位10のソフトウェアを対象として選択 • 被験者が10のソフトウェアそれぞれについて，入力となったソフトウェアとの類似度を評価 • 1～4の4段階(4が一番類似度が高い)

  5. 評価実験の結果 帰無仮説　『差がない』が有意水準5%で棄却されたかどうか Reject : 棄却　＝　統計的有意差あり Accept : 棄却されず　＝　統計的有意差なし 比較する手法 評価指標 C: Confidence Level P: Precision MUDABlueよりも 高い Confidence Level 高い精度

  6. Content Classification of Development Emails Alberto Bacchelli, Tommaso Dal Sasso, Marco D’Ambros, Michele Lanza University of Lugano 紹介：大阪大学　大学院情報科学研究科　井垣　宏

  7. Motivation JUNK Figure 1 • ML archivesにはシステムを理解するために必要な履歴や設計理念等の重要な情報が埋まっている • 一つのメールの中に複数種類のコンテンツが含まれることを想定して解析しなければならない 自然言語 Stack Trace JUNK ソースコード Patch

  8. Mailpeekを用いたML Archiveの分析 • ArgoUML, Freenet等を対象として著者らの開発したツールによってmailの分析を行った • コンテンツ分類の粒度確認 ->ほぼ行単位でOK • 分類項目の妥当性確認 ->現状の項目で分類できなかった部分は全体の0.2% Figure 2

  9. 行単位での分類結果(手作業) • どんなプロジェクトでも自然言語が一番多い • JUNKも同様 • それ以外の項目はプロジェクトによって異なる

  10. 実験結果

  11. Classification Approach • Term Based Classification • Words, Punctuation, Bi-grams, Context • Parsing Based Classification • Stack Trace, Patch, Source Code, Junk

  12. 実験結果

  13. Conclusion • 機械学習手法とパーサーを組み合わせた行単位でのメール分類手法を提案した • NL text, source code, stack traces, code patches, and junk

  14. Active Refinement of Clone Anomaly Reports Lucia, David Lo, Lingxiao Jiang, and Aditya Budi School of Information Systems Singapore Management University 紹介：大阪大学　大学院情報科学研究科　井垣　宏

  15. 研究背景 • ソフトウェア中の互いに類似するコード片= コードクローン • コードクローンを利用した重要なアプリケーションの一つにバグ検出がある • clone-based anomaly detection • コードクローン間のinconsistenciesを如何に検出するか

  16. Inconsistency among clones Figure 1 • クローンとその周辺コードの一貫性やクローン間の一貫性を調査することで，”anomaly”を検知する If(dentry) anomaly [12] L. Jiang, Z. Su, and E. Chiu, “Context-based detection of clone-related bugs,” in ESEC/SIGSOFT FSE, 2007.

  17. Inconsistency among clones • クローンとその周辺コードの一貫性やクローン間の一貫性を調査することで，”anomaly”を検知する • false positives(問題のないクローンが問題があると指摘される)が非常に多い • [12]の研究では，57/800 Figure 2 FalsePositive [12] L. Jiang, Z. Su, and E. Chiu, “Context-based detection of clone-related bugs,” in ESEC/SIGSOFT FSE, 2007.

  18. Active Refinement of Clone Anomaly Reports • 既存のClone based Anomaly Detection Toolの結果をユーザのフィードバックに基いて改善する • True Positiveを上位に，False Positiveを下位に移動

  19. Active Refinement of Clone Anomaly Reports • 既存のClone based Anomaly Detection Toolの結果をユーザのフィードバックに基いて改善する • True Positiveを上位に，False Positiveを下位に移動

  20. 評価実験 • Linux Kernel: 11%改善 • 変数名等の識別子の名前変更に関するinconsistencyが多かった • 提案手法における分類手法が構文木に基づくものであるため，対応できなかった • Eclipse: 87%改善 • ArgoUML:86%改善 Table II ただし，True Positiveであると判定されたものが本当にバグに 関連するものであるかは著者らによる判断

  21. Identifying Linux Bug Fixing Patches Yuan Tian, Julia Lawall, and David Lo Singapore Management University, Singapore INRIA/LIP6-Regal, France 紹介：大阪大学　大学院情報科学研究科　肥後　芳樹

  22. 研究背景 • ソフトウェアの開発には2つの重要な課題がある • 新しい機能の追加 • 安定性 • しかし，これらを同時に実現するのは難しい．Linuxでは，currentとlongterm supportの2つのバージョン • 前者にはさまざまな変更 • 後者はbug fix のみ • patchの多くはcurrentに対して作られる．しかし bug fix patchはlongterm supportに対しても適用すべき • Current用のpatchの中からbug fix patchを自動的に見つけたい

  23. 提案手法（1/2) • Data Acquisition • Gitのリポジトリから各patchのログ情報とコード情報を（ファイル，削除コード，追加コード）取得 • Feature Extraction • (1) コミットログを構成している重要そうなwordsの集合を抽出する（stop-wordの除去，stemming）．また各wordsの出現回数をカウント • (2) コード情報から，変更された字句のみを特定．そして変更されたのがプログラムのどの部分かを特定（loop？演算子？if文？）．変更回数もカウント

  24. 提案手法（2/2） • Model Learning • LPUとSVMを組み合わせた機械学習 • 既知のbug fix patches とbuf fix かどうかを特定したいpatchesが入力 • LPUを使って調査対象patchesをソート．下位のk個がbug fix ではないと判断される • bug fix ではないと判断されたpatchesを用いてSVMを利用 • Bug Fix Identification • SVMの適用結果より bug fix patchesがわかる

  25. 実験結果 論文の表4 論文の表5 F-measureの計算式

More Related