メソッドの同時更新履歴を用いたクラスの機能別分類法

Presentation on theme: "メソッドの同時更新履歴を用いたクラスの機能別分類法"— Presentation transcript:

1 メソッドの同時更新履歴を用いたクラスの機能別分類法
井上研究室　 博士前期課程2年 楠田泰三

2 Feature Location ソフトウェアの持つ機能と、その実装箇所の対応を特定する ソフトウェア理解のコストの増大[1]
保守作業を行う上では、ソフトウェア全体の理解よりも保守作業に応じた一部の詳細な理解の方が重要[2] ソフトウェアの持つ機能と、その実装箇所の対応を特定する 入力ファイルを読み込む データを解析する 解析結果を出力する ソースコード [1] Encyclopedia of Software Engineering. Pigoski T. M.,1994 [2] Partial Comprehension of Complex Programs. K.Erdos et al. IWPC'98

3 Feature Locationの既存手法とその問題点
ソースコードを解析する 関数の呼び出しグラフを用いる ⇒動的に実行経路が決定するオブジェクト指向プログラムでは、解析が困難 プログラムの実行履歴を解析する プログラムを様々な入力の元で実行 ⇒ 非常に時間がかかる

4 版管理システム 3.更新を反映 1.コピー 2.更新 1.コピー 2.更新 3.更新を反映 リポジトリ 開発者領域
開発のプロセス　(一回の更新作業) リポジトリとよばれるデータベースから必要なプロダクト（ソースコードなど)をコピー コピーしたプロダクトを更新する 行った更新をリポジトリに反映させる（チェックイン） 一回の更新作業で複数のプロダクトが更新され、その全ての履歴がリポジトリに存在 ソフトウェアの機能を追加・修正するために行ったソースコードの更新の情報を含む

5 ⇒ソフトウェアの持つ機能と、その実装箇所の対応を特定する
研究の概要 目的 オブジェクト指向言語で記述されたソフトウェアのクラスを機能別に分類 ⇒ソフトウェアの持つ機能と、その実装箇所の対応を特定する 手法 版管理システムの保持している開発履歴情報を用いる 同一の機能を実装している箇所は同時に更新されることが多い 同時に更新される傾向が強いクラス群を同一の機能を実装しているクラス群と考え、グループ化する

6 提案手法概要 1.1 同時更新情報の抽出 1.2 多くのクラスにまたがる更新作業の除去 2.1メトリクス値の計算 2.2更新傾向グラフの作成
A.a2() B.b() A.a1() C.c() { A.a1() , A.a2() , B.b() , C.c() } { A.a1() , A.a2() , B.b() } { A.a1() , B.b() } { A.a2() , C.c() } {A , B} {A , C} 版管理システムのリポジトリ 同時更新傾向の強いクラス群 メソッドの同時更新の情報 1.1 同時更新情報の抽出 1.2 多くのクラスにまたがる更新作業の除去 2.1メトリクス値の計算 2.2更新傾向グラフの作成 3.1更新傾向グラフのクラスタリング 3.2同時更新傾向の強いクラス群の決定 更新傾向グラフ

7 { A.a1() , B.b() , C.c() , D.d() , E.e() }
手順1.1 - 同時更新情報の抽出 { A.a1() , B.b() } { A.a2() , C.c() } { A.a1() , A.a2() , B.b() } { A.a1() , A.a2() , B.b() , C.c() } { A.a1() , B.b() , C.c() , D.d() , E.e() } 版管理システムのリポジトリ 同時更新されたメソッド群のリスト 一回の更新作業により更新されたメソッド群を同時に更新されたメソッド群と考える メソッドの更新 メソッドの記述内容が更新 メソッドが追加 対象とするソフトウェアに対して行われた全ての更新作業について、同時更新されたメソッド群を抽出し、そのリストを作成

8 手順1.2 - 多くのクラスにまたがる更新作業の除去
同時に更新されたメソッド群が多くのクラスにまたがる場合、その更新作業を除去 複数の機能の修正をまとめてチェックイン リファクタリングなどによる大規模なコードの修正 箱髭図を用いた分析 箱髭図 四分位点を用いてデータのばらつきを見るための図 各更新作業において、同時に更新されたメソッド群がまたがるクラスの個数をデータとして箱髭図を作成し、上の髭にあたる部分を越える更新作業を除去 髭 箱 髭 箱髭図

9 手順2.1 - 同時更新の強さを表すメトリクスの計算
{ A.a1() , B.b() } { A.a2() , C.c() } { A.a1() , A.a2() , B.b() } { A.a1() , A.a2() , B.b() , C.c() } ： 外れ値を除去した同時更新されたメソッド群のリスト メトリクス値 同時更新の強さ = どの程度同時に更新される傾向があるかを数値で表現 Zimmermann らが提案した confidence メトリクス[1]を用いる [1] Zimmermann et al. How History Justifies System Architecture ( or not ) . IWPSE2003

10 手順2.2 - 更新傾向グラフの作成 頂点はメソッド 頂点間の辺は始点と終点のメソッドの同時更新の強さを保持 0.5 1.0
A.a1() A.a2() 1.0 ： B.b() C.c() メトリクス値 更新傾向グラフ 頂点はメソッド 頂点間の辺は始点と終点のメソッドの同時更新の強さを保持 始点をメソッド A 、終点をメソッド B とした時 A → B の辺は を保持

11 手順3.1 - 更新傾向グラフのクラスタリング 群平均法を用いる 0.58 0.58 1.0 0.83 0.48 0.375 0.375
手順3.1 -　更新傾向グラフのクラスタリング 群平均法を用いる 初期状態の頂点の一つずつをクラスタにする クラスタ間の近さの値が最大の２つのクラスタを一つのクラスタに統合 クラスタ間の近さの値は、各クラスタに含まれる頂点間のすべての組み合わせの近さの値の平均 頂点A,B間の近さは 全てのクラスタ間の近さが閾値 より小さくなるまで繰り返す 1.0 0.375 0.58 A.a2() B.b() A.a1() C.c() 0.375 0.58 0.83 0.48 クラスタ化更新傾向グラフ 更新傾向グラフ

12 手順3.2 - 同時更新傾向の強いクラス群の決定 クラスタリングの結果を開発者に提示する。開発者が適切にクラスタリングできていないと判断した場合は、閾値を設定し直し、再びクラスタリングを行う。 機能数に対してクラスタの数が多すぎる場合は閾値を低くする クラスタ化更新傾向グラフ中の各クラスタに含まれるメソッド群が属しているクラス群を、同時更新傾向が強いクラス群と考える 閾値を再設定 一つの機能を実装しているクラス群 A.a2() B.b() A.a1() C.c() A.a2() B.b() A.a1() C.c() { A ,B } { A ,C } 同時更新傾向の強いクラス群 クラスタリング 更新傾向グラフ クラスタ化更新傾向グラフ

13 検証実験 対象とするソフトウェアに対し本手法を適用し、適切にクラスがグループ化できているかを調べる 実験対象
CREBASS ( Cvs REpository Browse And Search System ) CVS リポジトリ閲覧・検索システム

14 実験結果 データ解析部について評価 で10個のクラス群が特定 各機能の実装クラスを最も多く含むクラス群を割り当て 機能名 実装クラス
抽出クラス 該当クラス データベースを作成する 8 10 7 データベースからデータを取得する 6 5 Cのファイルを構文解析する 3 RCSファイルを解析する 設定ファイルを読み込む 2 折れ線グラフを作成する リビジョン条件の比較する 関数データを管理する ヒストリデータを管理する 14 プロジェクトデータを管理する 計 60 65 49 各機能の実装クラスを最も多く含むクラス群を割り当て

15 実験結果の考察 本手法は有効 概ね高い適合率、再現率 いくつかのオープンソースソフトウェアで再現率が低い
例) jPicEdtというソフトウェアは再現率が0.22 ある程度開発を行ってから版管理システムの利用開始していたため ⇒版管理システムの利用を開始する前の履歴が取得できない

16 まとめ ソフトウェアの開発履歴を用いてクラスを機能別にグループ化 検証実験 今後の課題
ソフトウェアの全体ではなく、一部を詳細に理解することを支援 検証実験 本手法は有効 版管理システムの利用開始時期が遅い場合、適切にクラスが特定できない場合もある 今後の課題 変更の内容を考慮 ソースコードの静的解析と組み合わせる 既存手法との結果の比較