UMLモデルを対象とした リファクタリング候補検出の試み 増田敬史，○吉田則裕，浜口優，井上克郎 （大阪大学） 2019/4/7

リファクタリング ソフトウェアの外部的振る舞いを保ったまま，内部の構造を改善する作業[1] リファクタリングの分類 将来的な修正コストを削減できる リファクタリングの分類 ソースコードが対象 例：コードクローン（重複コード）の集約 設計モデルが対象 モデルリファクタリング（Model refactoring）と呼ばれる 本発表で取り上げる [1] M．Fowler, Refactoring：Improving the Design of Existing Code, Addison Wesley，1999 2019/4/7

モデルリファクタリング ソフトウェアの外部的振る舞いを保ったままで，モデルの品質を改善させること [2] 設計段階でリファクタリングを行うことができる UMLのクラス図で表されるモデルが対象であることが多い デザインパターンを導入するモデルリファクタリングが提案されている [3] 親クラスの抽出 Employee Developer Programmer Developer Programmer [2] T．Mens，G．Taentzer，and D．Muller, Challenges in Model Refactoring, Proc. WOOR 2007． [3] D. Astels, Refactoring with UML, Proc. International Conference on eXtreme Programming and Flexible Process in Software Engineering, 2002. 2019/4/7

デザインパターン 設計において頻出する問題を解決するための，洗練された設計パターン[4] デザインパターンを導入するリファクタリング 適用すべき状況や利点・欠点についても記述されている デザインパターンを導入するリファクタリング 既存のモデルにデザインパターンを導入する パターンA パターンB パターン適用 修正 [4] E．Gamma，R．Helm，R．Johnson，and J．Vlissides．Design Patterns Elements of Reusable Object-Oriented Software．Addison Wesley，1999． 2019/4/7

表と円グラフ間の変更通知を作り忘れている 例題：成績管理・表示システム(1/2) 複数のGUIから入力・閲覧が可能 データが変更されると，他のGUIに変更を通知する 成績データセット 書込 読込 書込 読込 書込 読込 変更通知 A君 B君 C君 算数 89 44 33 国語 88 99 29 理科 39 59 変更通知 変更通知 変更通知 表形式のGUI 棒グラフ形式のGUI 円グラフ形式のGUI 表と円グラフ間の変更通知を作り忘れている 2019/4/7

円グラフが追加されても，他のGUIを変更する必要がない 例題：成績管理・表示システム(2/2) Observerパターンを適用 成績データセットは，書込が発生すると他のGUIに変更を通知 成績データセット 読込・書込 変更通知 A君 B君 C君 算数 89 44 33 国語 88 99 29 理科 39 59 関連 なし 関連 なし 表形式のGUI 棒グラフ形式のGUI 円グラフ形式のGUI 円グラフが追加されても，他のGUIを変更する必要がない 2019/4/7

リファクタリング前後のUMLモデル （a）リファクタリング前 （b）リファクタリング後 クラス間に双方向の関連が存在 Hyou Seiseki BouGraph Observer Hyou Seiseki BouGraph Observer EnGraph Hyou Seiseki BouGraph EnGraph Hyou Seiseki BouGraph （a）リファクタリング前 （b）リファクタリング後 クラス間に双方向の関連が存在  リファクタリング候補 Observerパターンを導入  双方向の関連が除去 2019/4/7

デザインパターンを導入する リファクタリングの問題点 UMLモデルから，リファクタリングの候補を探すことは困難 特に，大規模なモデルが対象の場合は難しい リファクタリング後のUMLモデルを予測することは困難 開発者は，リファクタリング前後を比較しながら，是非を検討したい リファクタリング支援手法が必要 2019/4/7

提案手法の概要 XML形式で記述されたUMLモデルに対して，以下を行う （１） Observerパターンを導入するリファクタリングの候補を特定 （２） （１）からリファクタリング後のUMLモデルを作成 （３） UMLモデル全体からリファクタリングに関連する部分を抽出 検討 提案手法 リファクタリング候補 UMLモデル全体 開発者 リファクタリング後 のUMLモデル 2019/4/7

リファクタリング候補の特定・修正 XMLパーサを作成し，UMLモデルのXML表現を解析する クラス間に双方向の関連が存在  リファクタリング候補 <xml> <Class> <name = “ToukeiData”> </Class> <name = “Hyou”> <AssociationData> <AssociationEnd> <Classname = “ToukeiData”> <Classname = “Hyou”> </AssociationData> </xml> Seiseki 双方向の関連を特定 継承に変更 <GeneralizationData> <ParentClass> <Classname = “ToukeiData”> <ChildClass> <Classname = “Hyou”> </GeneralizationData> Hyou BouGraph （a）UMLモデル （b）UMLモデルのXML表現 2019/4/7

リファクタリング候補の特定・修正 XMLパーサを作成し，UMLモデルのXML表現を解析する クラス間に双方向の関連が存在  リファクタリング候補 Hyou Seiseki BouGraph Observer Seiseki Hyou BouGraph （a）UMLモデル 2019/4/7

リファクタリングに関連する部分の抽出 UMLモデル全体からリファクタリングを行った部分を抽出 リファクタリングを行ったクラスを含むパッケージを検出 抽出されたUMLモデルで適用部分を確認できる packageA packageB packageA packageB packageC packageB pacakgeB packageC XML表現を書き換え 適用部分を検出 2019/4/7

実験概要 目的 実験対象 実装したツールのリファクタリング候補特定に対する有効性を確認 デジタル時計のUMLモデル 7クラス，1パッケージ 教務関係業務システムのUMLモデル 104クラス，12パッケージ ※UMLモデリングツールJUDEを用いてUMLモデルをXML形式に変換した 2019/4/7

デジタル時計のUMLモデル 典型的なリファクタリング例[4] 結果：TimeSourceクラスとClockDriverクラスの 相互関連を解消 UMLモデルに対するデザインパターン適用可能 部分の検出・修正機能を確認 （a） ツール適用前 （b） ツール適用後 [4] R．C．Martin．Agile Software Development．Pearson Education，2004 2019/4/7

業務システムのＵＭＬモデル(1/2) 3つのクラス対が双方向の関連を持っていたが，リファクタリングを行う必要はなかった Action クラスとActionForward クラス Strutsフレームワークを用いている部分 Kamoku クラスとKyouikukatei クラス間 2つともオペレーションを持たないデータクラス JugyouKamoku クラスとGakusei クラス 2019/4/7

開発者が検出部分に注目しリファクタリングを検討可能 業務システムのＵＭＬモデル (2/2) リファクタリング候補を検討 適用する必要がないことがわかった 開発者が検出部分に注目しリファクタリングを検討可能 RishuuServiceクラスがJugyouKamokuクラス とGakuseiクラスのデータを管理 2019/4/7

考察 提案手法を用いてリファクタリング候補の検出を行うことが可能 検出された部分のみで設計を検討できた 業務ソフトウェアのUMLモデルからは，リファクタリングすべき例が見つからなかった 他の業務ソフトウェアにも適用したい Strutsを用いている部分が検出された 特定のフレームワークを用いている部分は，分析対象から外せるようにしたい 2019/4/7

まとめと今後の課題 UMLモデル上でのリファクタリング候補検出手法を提案 今後の課題 リファクタリング候補を開発者に提示 実装したツールを用いた適用実験 今後の課題 他のソフトウェアへの適用 他のデザインパターンを導入するリファクタリングの支援 リファクタリングに関連する部分の抽出法 リファクタリングを行う効果の評価方法 シーケンス図を対象としたリファクタリング支援 2019/4/7