履歴情報を用いた同一ユースケース実装クラス群抽出法の提案楠田泰三, 川口真司, 松下誠, 井上克郎大阪大学大学院情報科学研究科井上研究室 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 ソフトウェアの可視化ソフトウェア可視化技術ソフトウェアの構造や振る舞いを、図やグラフを用いて表現することで、ソフトウェア理解を支援例) UMLのクラス図オブジェクト指向ソフトウェアの構造理解を支援クラスの継承、依存などの関係を記述できる StateSetter setState() State printMsg() MsgPrinter state : State StateA StateB setState() printMsg() printMsg() printMsg() Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 2 ソフトウェア可視化技術の問題点オブジェクト指向開発では、開発が進むにつれクラス数が増加する大規模なオブジェクト指向ソフトウェアは、その全てのクラスを可視化しても、出力された図も大規模になり理解が難しいクラス数100余りのソフトウェアのクラス図同じユースケースを実装しているクラス群のみを抽出して、可視化する ⇒ 要素数の少ない図を出力 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 3 既存研究の問題点ユースケース抽出の既存手法[1] 静的にコールグラフを解析する動的な側面を考慮せず、呼ばれる可能性がある全てのメソッドに呼び出し辺をつけたコールグラフを作成入力があるメソッドから出力があるメソッドまでの経路を一つのユースケースとする ⇒実際には存在しないメソッドの実行系列が抽出され、多くのユースケースが抽出されるソースコードを静的に解析するだけではユースケースを実装しているクラス群を抽出するのは難しい [1] Lucca et al. Recovering Use Case models from Object-Oriented Code: a Thread-based Approach. WCRE2000 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 4 研究の目的同一のユースケースを実装しているクラス群は同時に更新されることが多いのではないか版管理システムの保持している開発履歴情報を用い、同時に更新される傾向が強いクラス群を同一のユースケースを実装しているクラス群として抽出版管理システム •管理下にある全てのソフトウェアプロダクトに対して行われた全ての更新の履歴を保持 •いつ、誰が、なぜそのような更新を行ったかという情報も含む Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 5 提案手法概要 {A , B , C , D} {A , B , C} {A , C}手順6.1 閾値を再設定手順6.2 {B , D} 版管理システムの同時更新傾向の強い手順4 リポジトリ手順5 クラス群を抽出手順1 閾値を設定して閾値を設定して手順3手順2 メトリクス値の計算フィルタリング同時更新情報の抽出クラスタリング更新傾向グラフの作成： ( 1, 0.67 ) {A , C} A B A B A B {B , D} ( 3, 1.0 ) C D C D C Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University D 6 手順1 - 同時更新情報の抽出 {A , B , C , D} {A , B , C} {A , C} 版管理システムのリポジトリ {B , D} 同時更新されたクラス群のリスト同じコミット作業により更新されたクラス群を同時に更新されたクラス群と考える以下の情報を用いて同じコミット作業により更新されたことを特定更新者更新時のコメント更新時間同時更新されたクラス群のリストを作成 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 7 手順2 - 同時更新の強さを表すメトリクスの計算 {A , B , C , D} {A , B , C} {A , C} {B , D} ：メトリクス値同時更新されたクラス群のリスト同時更新の強さ = どの程度同時に更新される傾向があるかを数値で表現 Zimmermann らが提案したメトリクス[2]を用いる support - 同時に更新された回数クラスとが同時に更新された回数 confidence - 同時に更新された頻度が更新されたとき、も同時に更新される割合 [2] Zimmermann et al. How History Justifies System Architecture ( or not ) . IWPSE2003 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 8 手順3 - 更新傾向グラフの作成 ( 2, 0.67 ) A B ( 3, 1.0 ) ：メトリクス値 C D 更新傾向グラフ頂点はクラス頂点間の辺は始点と終点のクラスの同時更新の強さを保持始点をクラス A 、終点をクラス B とした時 A → B の辺はとを保持 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 9 手順4 - support を用いてフィルタリング複数の関係の無い作業によって偶然同時に更新された場合を考慮しないようにするため support 値として閾値以下の値を持っている辺を更新傾向グラフから除去 A ( 2, 0.67 ) ( 2, 0.67 ) B A ( 2, 0.67 ) B ( 2, 0.67 ) ( 3, 1.0 ) ( 3, 1.0 ) ( 3, 1.0 ) ( 2, 1.0 ) ( 2, 0.67 ) ( 2, 0.67 ) ( 3, 1.0 ) ( 2, 1.0 ) C ( 1, 0.33 ) ( 1, 0.5 ) 更新傾向グラフ D C D フィルタリングした更新傾向グラフ Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 10 手順5 - confidence を用いてクラスタリング群平均法を用いる初期状態の頂点の一つずつをクラスタするクラスタ間の近さの値が最大の２つのクラスタを一つのクラスタに統合 1. 2. クラスタ間の近さの値は、各クラスタに含まれる頂点間のすべての組み合わせの近さの値の平均終了条件が満たされるまで統合を繰り返す頂点A,B間近さはただし、フィルタリングによりA,B間に辺が無い場合は近さは0 終了条件は「全てのクラスタ間の近さが閾値 A ( 2, 0.67 ) より小さい」 B A ( 2, 0.67 ) ( 3, 1.0 ) ( 2, 0.67 ) ( 3, 1.0 ) 1.0 ( 2, 1.0 ) C C D フィルタリングした更新傾向グラフ 0.67 0.67 0.67 0.330 0 0 B 0.83 D クラスタ化更新傾向グラフ Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 11 手順6 - 同時更新傾向の強いクラス群の抽出閾値を変化させ、一つのクラスタに含まれるクラス群が適切な数になるように、フィルタリングとクラスタリングを繰り返すクラスタ化更新傾向グラフ中の各クラスタに含まれるクラス群を同時更新傾向の強いクラス群として抽出を行う 1. 2. 閾値を再設定 A B A B {A , C} {B , D} フィルタリング、 C D 更新傾向グラフクラスタリング C D 同時更新傾向の強いクラス群クラスタ化更新傾向グラフ Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 12 検証実験対象とするソフトウェアに対し本手法を適用し、抽出されるクラス群が同一ユースケース実装クラス群となっているかどうかを調べる実験対象 CREBASS ( Cvs REpository Browse and Search System ) CVS リポジトリ閲覧・検索システム規模 – クラス数 70クラス – 行数 7513行 – 総更新回数 140回実装されている主なユースケース – プロジェクトデータの変遷の折れ線グラフによる表示 – リビジョン情報の検索 – プロジェクト内のファイルのログの表示など Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 13 実験結果の時のクラスタ化更新傾向グラフユースケース実装クラスの時のクラスタ化更新傾向グラフ抽出クラス適合クラス抽出クラス適合クラス折れ線グラフによる表示 4 4 4 20 4 リビジョン検索 7 0 0 7 7 ファイルのログの表示 4 4 4 3 3 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 14 実験結果の考察ユースケース実装クラス抽出クラス該当クラス抽出クラス該当クラス折れ線グラフによる表示 4 4 4 20 4 リビジョン検索 7 0 0 7 7 ファイルのログの表示 4 4 4 3 3 support の閾値複数の関係の無い作業によって偶然同時に更新されたクラス間の support は1, 2程度 [2] フィルタリングは有効クラスの更新回数が少ない時には用いるべきではないユースケース「リビジョン検索」を実装しているクラス群は更新回数が高々2回適切に閾値を設定する必要がある [2] Zimmermann et al. How History Justifies System Architecture ( or not ) . IWPSE2003 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 15 まとめソフトウェアの開発履歴を用いて同一のユースケースを実装しているクラス群を抽出する手法を提案可視化に用いることで、一部を詳細に理解することを支援手法の妥当性を評価するための実験ユースケース実装クラス群を抽出することは可能適切に閾値を設定する必要がある今後の研究手法の改良手法の定量的な評価可視化の方法について考案 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 16