Download
1 / 16
160 likes | 244 Views
メソッドの同時更新履歴を用いたクラスの機能別分類法. 井上研究室 博士前期課程 2 年 楠田泰三. 入力ファイルを読み込む. 解析結果を出力する. データを解析する. Feature Location. ソフトウェア理解のコストの増大 [1] 保守作業を行う上では、ソフトウェア全体の理解よりも保守作業に応じた一部の詳細な理解の方が重要 [2]. ソフトウェアの持つ機能と、その実装箇所の対応を特定する. ソースコード. [1] Encyclopedia of Software Engineering. Pigoski T. M.,1994
E N D
メソッドの同時更新履歴を用いたクラスの機能別分類法メソッドの同時更新履歴を用いたクラスの機能別分類法 井上研究室 博士前期課程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
Feature Locationの既存手法とその問題点 • ソースコードを解析する • 関数の呼び出しグラフを用いる ⇒動的に実行経路が決定するオブジェクト指向プログラムでは、解析が困難 • プログラムの実行履歴を解析する • プログラムを様々な入力の元で実行 ⇒ 非常に時間がかかる
3.更新を反映 1.コピー 1.コピー 2.更新 3.更新を反映 版管理システム 2.更新 リポジトリ 開発者領域 • 開発のプロセス (一回の更新作業) • リポジトリとよばれるデータベースから必要なプロダクト（ソースコードなど)をコピー • コピーしたプロダクトを更新する • 行った更新をリポジトリに反映させる（チェックイン） 一回の更新作業で複数のプロダクトが更新され、その全ての履歴がリポジトリに存在 ソフトウェアの機能を追加・修正するために行ったソースコードの更新の情報を含む
研究の概要 目的 版管理システムの保持している開発履歴情報を用いる 同一の機能を実装している箇所は同時に更新されることが多い オブジェクト指向言語で記述されたソフトウェアのクラスを機能別に分類 ⇒ソフトウェアの持つ機能と、その実装箇所の対応を特定する 手法 同時に更新される傾向が強いクラス群を同一の機能を実装しているクラス群と考え、グループ化する
1.1 同時更新情報の抽出 1.2 多くのクラスにまたがる更新作業の除去 A.a2() A.a1() B.b() C.c() 2.1メトリクス値の計算 2.2更新傾向グラフの作成 3.1更新傾向グラフのクラスタリング 3.2同時更新傾向の強いクラス群の決定 提案手法概要 { A.a1() , A.a2() , B.b() , C.c() } { A.a1() , A.a2() , B.b() } { A.a1() , B.b() } { A.a2() , C.c() } { A.a1() , B.b() } {A , B} {A , C} 版管理システムのリポジトリ 同時更新傾向の強いクラス群 メソッドの同時更新の情報 更新傾向グラフ
手順1.1 - 同時更新情報の抽出 • 一回の更新作業により更新されたメソッド群を同時に更新されたメソッド群と考える • メソッドの更新 • メソッドの記述内容が更新 • メソッドが追加 • 対象とするソフトウェアに対して行われた全ての更新作業について、同時更新されたメソッド群を抽出し、そのリストを作成 { A.a1() , B.b() } { A.a2() , C.c() } { A.a1() , B.b() } { A.a1() , A.a2() , B.b() } { A.a1() , A.a2() , B.b() , C.c() } { A.a1() , B.b() , C.c() , D.d() , E.e() } 版管理システムのリポジトリ 同時更新されたメソッド群のリスト
手順1.2 - 多くのクラスにまたがる更新作業の除去 • 同時に更新されたメソッド群が多くのクラスにまたがる場合、その更新作業を除去 • 複数の機能の修正をまとめてチェックイン • リファクタリングなどによる大規模なコードの修正 • 箱髭図を用いた分析 • 箱髭図 • 四分位点を用いてデータのばらつきを見るための図 • 各更新作業において、同時に更新されたメソッド群がまたがるクラスの個数をデータとして箱髭図を作成し、上の髭にあたる部分を越える更新作業を除去 髭 箱 髭 箱髭図
手順2.1 - 同時更新の強さを表すメトリクスの計算 { A.a1() , B.b() } { A.a2() , C.c() } { A.a1() , B.b() } { 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
頂点はメソッド 頂点間の辺は始点と終点のメソッドの同時更新の強さを保持 始点をメソッド A 、終点をメソッド B とした時 A → B の辺は を保持 手順2.2 - 更新傾向グラフの作成 A.a2() A.a1() B.b() C.c() 0.5 1.0 ： メトリクス値 更新傾向グラフ
0.58 0.58 0.58 1.0 0.48 0.375 0.375 0.375 A.a1() A.a2() B.b() C.c() 0.83 クラスタ化更新傾向グラフ 手順3.1 - 更新傾向グラフのクラスタリング • 群平均法を用いる • 初期状態の頂点の一つずつをクラスタにする • クラスタ間の近さの値が最大の２つのクラスタを一つのクラスタに統合 • クラスタ間の近さの値は、各クラスタに含まれる頂点間のすべての組み合わせの近さの値の平均 • 頂点A,B間の近さは • 全てのクラスタ間の近さが閾値 より小さくなるまで繰り返す 更新傾向グラフ
A.a2() A.a1() A.a2() A.a1() B.b() C.c() B.b() C.c() 手順3.2 - 同時更新傾向の強いクラス群の決定 • クラスタリングの結果を開発者に提示する。開発者が適切にクラスタリングできていないと判断した場合は、閾値を設定し直し、再びクラスタリングを行う。 • 機能数に対してクラスタの数が多すぎる場合は閾値を低くする • クラスタ化更新傾向グラフ中の各クラスタに含まれるメソッド群が属しているクラス群を、同時更新傾向が強いクラス群と考える 閾値を再設定 一つの機能を実装しているクラス群 { A ,B } { A ,C } 同時更新傾向の強いクラス群 クラスタリング 更新傾向グラフ クラスタ化更新傾向グラフ
検証実験 • 対象とするソフトウェアに対し本手法を適用し、適切にクラスがグループ化できているかを調べる • 実験対象 • CREBASS ( Cvs REpository Browse And Search System ) • CVS リポジトリ閲覧・検索システム
実験結果 データ解析部について評価 で10個のクラス群が特定 各機能の実装クラスを最も多く含むクラス群を割り当て
実験結果の考察 • 本手法は有効 • 概ね高い適合率、再現率 • いくつかのオープンソースソフトウェアで再現率が低い • 例) jPicEdtというソフトウェアは再現率が0.22 ある程度開発を行ってから版管理システムの利用開始していたため ⇒版管理システムの利用を開始する前の履歴が取得できない
まとめ • ソフトウェアの開発履歴を用いてクラスを機能別にグループ化 • ソフトウェアの全体ではなく、一部を詳細に理解することを支援 • 検証実験 • 本手法は有効 • 版管理システムの利用開始時期が遅い場合、適切にクラスが特定できない場合もある • 今後の課題 • 変更の内容を考慮 • ソースコードの静的解析と組み合わせる • 既存手法との結果の比較
