FSE/ASE2011 勉強会 F12 Mining 2012/03/21 井垣　宏(大阪大学 楠本研究室)

Presentation on theme: "FSE/ASE2011 勉強会 F12 Mining 2012/03/21 井垣　宏(大阪大学 楠本研究室)"— Presentation transcript:

1 FSE/ASE2011 勉強会 F12 Mining 2012/03/21 井垣　宏(大阪大学 楠本研究室)

2 On the Congruence of Modularity and Code Coupling
Fabian Beck, Stephan Diehl(University of Trier, Germany)

3 概要 複雑なシステムは適切な設計原理に則ってモジュール化されるべきである ただし，実際にどのような設計原理が利用されているかは分からない
16のOSSを対象として結合則の関連を分析することで，どのような設計原理が適用されているかを調査した 以上

4 対象となる設計原理 Low Coupling and High Cohesion Information Hiding
Conway’s Law Others reuse-release equivalence principle pipes-and-filters aspect-oriented …. Conway’s Law: 組織構成とアプリケーションモジュールは一貫性を確保すべき

5 対象となる結合則 Structural Dependencies Fan-Out Similarity
継承/呼び出し等の直接的なクラス間依存関係 Fan-Out Similarity 間接的なStructural Dependencies Evolutional Coupling 良く同時に修正されるクラス Code Clones クローン片を共有するクラス Code Ownership 特定の開発者が開発しているクラス Semantic Similarity そのクラスを説明する語彙が似通っているクラス ConwayとCode OwnershipやSDとLow coupling

6 Research Questions RQ1.異なる結合則がお互いにどのように関連しているか？
どの設計原理が適用されているかを直接評価することは困難である 結合則の集合としてソフトウェアプロジェクトを抽象化し，設計原則との関係を分析した

7 R.Q.1 結合則間の関係を表したマトリックス 基本的にはまばらに相関を示している
Figure 1: Correlation between coupling graphs

8 R.Q.2 結合則をグラフ化し，システムの階層構造(モジュール構造)との関連を評価した
結合則を満たすクラス同士が含まれるパッケージの距離を用いて算出 同じパッケージ内の関係だとcohesionが上がる 違うパッケージの関係だとcouplingが上がる． in out それぞれについて算出し，cohesion/coupling + cohesionを計算したものがこのbox plotになる Type1クローンは同じパッケージに多い． SDの関係にあるクラスは 同一か近接パッケージであることが多い 同時に更新されるのは近接パッケージが多い Figure 2: Coupling-modularity congruence and average class coupling-modularity congruence

9 R.Q.3 モジュール種別によって異なった結合則-モジュール構造関係を示す
FO.InhIは共通するクラスの拡張か実装をしているクラス間の関係を表す Figure 3: Coupling-modularity congruence for the most frequently occurring package types

10 Discussion Conway’s Lawはあまり用いられていない コードクローンはシステムのモジュール構造と明確に関連している
ただし特定のどの設計原則に基づくものであるのかは不明である 設計支援ツールはモジュール種別等のコンテキストに応じて開発者のサポートをすべきである

11 Fuzzy Set and Cache-based Approach for Bug Triaging
Ahmed Tamrawi,Tung Thanh Nguyen, Jafar M. Al-Kofahi, Tien N. Nguyen Electrical and Computer Engineering Department Iowa State University

12 この研究の貢献 スケーラブルで効率的で正確なBug triaging Approachの提案 バグ修正活動の現場発見支援
定量的に既存手法と比較した バグ修正活動の現場発見支援 最近バグ修正をした開発者は次の修正者になり易い バグ修正の専門知識を特徴付ける語彙の特定 Bug triaging 発見されたバグを適切な修正者に割り当てる手法

13 Motivating Example EclipseのBug reportにおいて，James Moody氏がVCM関連のバグを引き受けていた CVS repository connection path ソフトウェアシステムは複数の技術的観点を持つ 技術的観点は複数の技術用語と関連付けられる． バグレポートは複数の技術的観点と関連がある ある開発者がしばしば特定の技術的観点に関するバグを修正しているとき そのような開発者をその観点におけるバグ修正専門家であるとする repository resource editor

14 Bugzieのアプローチ Bugzie 学習用バグレポート Fixer J 新しいバグレポート Fixer J Fixer A CVS
repository Bugzie connection path CVS repository connection path Fixer J 修正者と技術用語の関連，修正時期を学習 Fixer J Fixer J Fixer J repository resource repository resource repository resource editor repository resource editor editor editor 学習用バグレポート 技術用語との関連だけでなく，最近修正活動をしている開発者をフィルタすることで 精度を犠牲にすることなく時間効率をあげることができる Initial Training Recommending Updating Fixer ??? 技術用語をBugzie に投入 適切な修正者 を推薦 CVS repository connection path Fixer J 新しいバグレポート

15 評価実験 準備 Step1: Bugzieを用いて初期訓練データセットをもとに学習
すべてのバグレポートを時系列で11のフレームに分割し，最初のフレームを初期訓練データセットとする Step1: Bugzieを用いて初期訓練データセットをもとに学習 Step2：前Stepの結果にもとづいて，次のフレームのバグレポートを対象としてBugzieが修正者群を推薦 Step3：実際の修正者が推薦結果に含まれていれば”hit”とし，推薦結果を新たな学習データとする Step4：Step2,3を全フレーム分繰り返し

16 実験結果(1/4) 全てのプロジェクトにおいてキャッシュサイズ40%以下程度で精度が最大化している
精度を上げるのにキャッシュサイズを増やす必要がない Term cacheとDeveloper cacheはフルサイズでもたなくても良い

17 実験結果(2/4) 修正者と関連のある技術用語の数が3~20程度で精度が最大化している
精度を上げるのに開発者に関連する技術用語数を増やす必要がない Fixerごとの関連する語彙をどの程度保持するか

18 実験結果(3/4) developer cacheと技術用語数が精度にどのような影響を与えるか

19 実験結果(4/4):既存手法との比較 精度は全ての手法に優っており，処理時間もほぼ優っている

20 Conclusions fuzzy setとcacheを利用した自動bug triagingツール「Bugzie」を提案した