UMLモデルを対象とした リファクタリング候補検出手法の提案と実現 井上研究室 増田敬史 UMLモデルを利用したデザインパターン適用支援手法の提案と実現というタイトルで。 井上研究室の増田が発表します。 2019/5/30

リファクタリング ソフトウェアの外部的振る舞いを保ったままで内部の 構造を改善する[1] 将来の機能追加やデバッグ，再利用に備えることが可能 近年モデルに対するリファクタリングの研究が活発[2] デザインパターンを利用したリファクタリング 修正 関連を除去 クラスを抽象化 背景について説明します。 下の図はＵＭＬモデルを複数回リファクタリングすることで徐々に設計が洗練されていく様子です。 またリファクタリング手法の中にはデザインパターンを利用したものがあります。 [1] M．Fowler．Refactoring：Improving the Design of Existing Code．Addison Wesley，1999 [2] T．Mens，G．Taentzer，and D．Muller．Challenges in Model Refactoring． Technical Report from University of Mons-Hainaut，Belgium，2005． 2019/5/30

デザインパターン 過去の開発者が経験的に得た汎用的な 設計パターン[3] 様々なプログラムで再利用可能 リファクタリングの際にデザインパターンを利用可能 デザインパターン適用には慎重な検討が必要 設計が複雑になる パターンA パターンB パターン適用 修正 下の図のようにリファクタリングの際にデザインパターンを利用することができます。 また一般にデザインパターンを適用適用できる箇所であっても将来的に変更が必要のない 箇所に対してはむやみに適用すべきでないという考えがあります。 よってデザインパターン適用には開発者による慎重な検討が必要となります。 [3] E．Gamma，R．Helm，R．Johnson，and J．Vlissides．Design Patterns Elements of Reusable Object-Oriented Software．Addison Wesley，1999． 2019/5/30

表と円グラフ間の変更通知を作り忘れている 例題：成績管理・表示システム(1/2) 複数のGUIから入力・閲覧が可能 データが変更されると，他のGUIに変更を通知する 成績データセット 書込 読込 書込 読込 書込 読込 変更通知 A君 B君 C君 算数 89 44 33 国語 88 99 29 理科 39 59 変更通知 デザインパターンを利用したリファクタリングの例として成績管理・表示システムが挙げられます。 このシステムは複数のＧＵＩから入力・閲覧が可能です。 例えば、表形式のＧＵＩの値が変更された場合、成績データセットに変更を書き込み、 棒グラフ形式のＧＵＩに変更を通知します。 変更通知を受け取った棒グラフ形式のＧＵＩは成績データセットから値を読み込みます。 この設計の場合、ＧＵＩの数だけ相互に変更通知機能を持つ必要があります。 こうした設計は変更に対する柔軟性がない設計だと思われます。 例えば、ここで円グラフ形式のＧＵＩが追加されると、 変更箇所の多さから、表と円グラフの変更通知を作り忘れるなどバグの混入する 危険があります。 この設計に対してデザインパターンを利用し、リファクタリングします。 変更通知 変更通知 表形式のGUI 棒グラフ形式のGUI 円グラフ形式のGUI 表と円グラフ間の変更通知を作り忘れている 2019/5/30

円グラフが追加されても，他のGUIを変更する必要がない 例題：成績管理・表示システム(2/2) Observerパターンを適用 成績データセットは，書込が発生すると他のGUIに 変更を通知 成績データセット 書込 変更通知 読込 A君 B君 C君 算数 89 44 33 国語 88 99 29 理科 39 59 関連 なし 関連 なし 先ほどの設計にObserverパターンと呼ばれるデザインパターンを適用しました。 成績データセットが他のＧＵＩに対して変更通知を一括して行います。 表形式のＧＵＩ、棒グラフ形式のＧＵＩはお互いのデータ変更を知るひつようがありません。 二つのＧＵＩはObserverとして成績データセットの変更を監視しています。 この場合に円グラフ形式のＧＵＩが追加されても他のＧＵＩを変更する必要がありません。 この設計は変更に対する柔軟性があるといえます。 表形式のGUI 棒グラフ形式のGUI 円グラフ形式のGUI 円グラフが追加されても，他のGUIを変更する必要がない 2019/5/30

リファクタリング候補検出 デザインパターンが適用可能な箇所には設計上の 欠点がある可能性がある 開発者が設計を確認可能 将来変更が必要になるかを検討しリファクタリングする 問題点　膨大な数のクラスを持つソフトウェアから 人間の目で探すことは困難 Observerパターンはオブジェクト間の相互関連を除去することで変更に対する柔軟性を もたせることが出来ました。 このように開発者はデザインパターン適用条件に合致する箇所を慎重に検討することで 実際にリファクタリングを行うかの判断をすることができます。 また実際にリファクタリングを行う必要がなかった場合も、適用可能箇所を検討することで 開発者が設計を小さな範囲で確認できるというメリットがある。 問題は大規模なソフトウェアからデザインパターン適用可能箇所を人間の 目で探すことは困難であるという点です。 よってデザインパターン適用可能箇所を自動的に検出し、開発者がスムーズにリファクタリングを 検討できる仕組みが必要と考えられます。 デザインパターン適用可能箇所を自動的に 検出する仕組みが必要 2019/5/30

提案手法の概要 UMLモデルを解析しリファクタリング候補を提示 手順１．デザインパターン適用可能箇所を検出し UMLモデルを修正 検出した部分 検証 開発者 適用するデザインパターン 提案手法 提案手法の概要について述べます。 UMLモデルを解析しリファクタリング候補を提示します。 まず、ＵＭＬモデル上のデザインパターンの適用条件に合致した箇所を検出し、 そのデザインパターンを適用した後のＵＭＬモデルに修正します。 適用条件を変えることで、様々なデザインパターン適用可能箇所を見つけることが出来ます。 次にUMLモデルの集合から検出した箇所を抽出します。 これによりリファクタリングを行う開発者が小さな範囲で設計を確認し、リファクタリングの 検討を行うことが出来ます。 2019/5/30

手順１. デザインパターン適用可能箇所を検出し UMLモデルを修正 例　成績管理・表示システムにObserverパターンを適用 クラス間の相互関連を除去 Hyou ToukeiData BouGraph Observer Table ToukeiData BarGraph Observer EnGraph Hyou ToukeiData BouGraph Table ToukeiData BarGraph EnGraph 提案手法の手順について説明します。 まずUMLモデル上のデザインパターン適用可能箇所を検出し、適用後のＵＭＬモデル に修正します。 例としてObserverパターンを適用した様子を示します。 下の図は先ほど説明した成績管理・表示システムを表すＵＭＬモデルです。 ツール適用前のＵＭＬモデルはToukeiDataクラスとTableクラス、BouGraphクラスが 相互に関連しており、複雑な設計になっています。 この場合EnGraphクラスが追加された場合に多くの変更が必要になります。 ツール適用後のＵＭＬモデルはTableクラスとBouGraphクラスがObserverクラスを継承することで ToukeiDataクラスとの相互関連が取り除いてあります。 この場合、EnGraphクラスが追加されたときもObserverクラスを継承し、ToukeiDataクラスと 関連することで変更が完了できます。 一般にUMLモデルはXMLで表現されます。 よって実装したツールではXMLの木構造を利用し、UMLモデルを解析します。 次のスライドでUMLモデル解析について説明します。 設計が複雑 （b）ツール適用後のUMLモデル （a）ツール適用前のUMLモデル 一般にUMLモデルはXMLで表現される ⇒XMLの木構造を利用しUMLモデルを解析 2019/5/30

UMLモデルの解析・修正 XMLパーサを作成し，UMLモデルのXML表現を解析する 例：Observerパターンの適用条件 <Class> <name = “ToukeiData”> </Class> <name = “Hyou”> <AssociationData> <AssociationEnd> <Classname = “ToukeiData”> <Classname = “Hyou”> </AssociationData> </xml> 例：Observerパターンの適用条件 クラスが相互に関連している ToukeiData 適用条件に合致 関連記述を修正 <GeneralizationData> <ParentClass> <Classname = “ToukeiData”> <ChildClass> <Classname = “Hyou”> </GeneralizationData> Hyou BouGraph 実装したツールではXMLパーサを作成し、UMLモデルの木構造を解析します。 ＵＭＬモデルはＵＭＬモデリングツールを利用してＸＭＬ表現に変換することができます。 左図のToukeiDataクラスとHyouクラスをXMLで表現したものが右図に示されています。 二つのクラス間の相互の関連は右図のＸＭＬ表現ではこのAssociationData記述で表されます。 今回はObserverパターンの適用条件をクラスが相互に関連していることと定義して 解析を行ったので、このＵＭＬモデルは適用条件に合致しているといえます。 ＵＭＬモデルの修正は、ＸＭＬ表現を書き換えることで可能となります。 このようにAssociationData記述を除去することでＵＭＬモデル上でも相互関連が除去されます。 GeneralizationData記述を追加することで、UMLモデル上でも親子関係が追加されます。 （a）UMLモデル （b）UMLモデルのXML表現 2019/5/30

手順２. 修正した箇所のUMLモデルを抽出 デザインパターンを適用すべき箇所をUMLモデル全体 から抽出 デザインパターンが適用できるクラスのあるパッケージを抽出 小さなUMLモデルで適用箇所を確認できる packageA packageB packageA packageB packageC packageB pacakgeB 次に、デザインパターン適用可能箇所をＵＭＬモデルの集合から抽出します。 抽出はパッケージ単位で行います。 これにより開発者は少数のＵＭＬもデルでリファクタリングの検討が行えます。 適用箇所の抽出は先ほどのスライドのようにXML表現を書き換えることで行います。 packageC XML表現を書き換え 適用箇所を抽出 2019/5/30

実験概要 目的 利用するソフトウェア 実験対象 実装したツールのリファクタリング候補特定に対する有効性を確認 ＪＵＤＥ UMLモデルとＸＭL表現の変換を行う 実験対象 デジタル時計のUMLモデル（7クラス，1パッケージ） オージス総研が開発した業務システムのUMLモデル（104クラス，12パッケージ） ANTLR3.0のUMLモデル（178クラス，12パッケージ） ANTLRの説明 実験について説明します。 実験の目的は実装したツールのリファクタリング候補特定に対する有効性を確認することです。 利用するソフトウェアはＵＭＬモデリングツールとしてＪＵＤＥを利用した。 ＵＭＬモデルとＸＭＬ表現の変換を行います。 実験対象としては、画面に時刻を表示するプログラムをあらわすデジタル時計のＵＭＬモデルで 小さなモデルに対するツールの機能を確認し、 オージス総研が開発した教務関係業務システムのＵＭＬモデルと多くの言語に対応した コンパイラ・コンパイラとして知られるＡＮＴＬＲのversion３．０のソースコード から出力したＵＭＬモデルについて実験を行い大規模なソフトウェアのUMLモデルに対して ツールの有効性を確認します。 今回は時間の関係上上の二つの実験についてのみ説明します。 2019/5/30

デジタル時計のUMLモデル UMLモデルに対するデザインパターン適用可能 箇所の検出・修正機能を確認 典型的なリファクタリング例[4] 適用したデザインパターン：Observerパターン 結果：TimeSourceクラスとClockDriverクラスの 相互関連を解消 UMLモデルに対するデザインパターン適用可能 箇所の検出・修正機能を確認 まずデジタル時計のUMLモデルに対して適用実験を行いました。 左のモデルは書籍にObserverパターンが適用可能なモデルとして紹介されており、 現在時刻のデータを持つTimeSourceクラスと現在の時刻をデジタルで表現する DigitalClockDriverクラスが相互に関連しています。 このモデルに実際にObserverパターンを適用しました。 右のツール適用後のモデルはObserverクラスが導入されることで TimeSourceクラスとDigitalClockDriverクラスの相互関連が解消されています。 よって実装したツールが小さなモデルに対するデザインパターン適用可能箇所の 検出機能を持つことが確認できました。 （a） ツール適用前 （b） ツール適用後 [4] R．C．Martin．Agile Software Development．Pearson Education，2004 2019/5/30

業務システムのＵＭＬモデル 大規模な教務関係業務システム 適用したデザインパターン：Observerパターン 結果：104クラス中3組のクラスに適用条件合致 リファクタリング候補を検討 検出箇所が柔軟な設計を持つことがわかった 次にオージス総研が開発した業務システムのＵＭＬモデルに対して適用実験を行いました。 適用したデザインパターンはObserverパターンです。 ツールを適用した結果、104クラス中３組のクラスに適用条件が合致しました。 そのうちの一つを示します。 JugyouKamokuクラスとGakuseiクラスが相互に関連しています。 仕様書を見てさらに細かく確認します。するとRishuuServiceクラスがJugyouKamokuクラスと Gakuseiクラスの間のデータを管理していることがわかりました。 これによりRishuServiceクラスを変更することで他のクラスの追加も出来ると考えられます。 結果としてこの箇所にObserverパターンを適用する必要がないことがわかりました。 これにより大規模なモデルにツールを適用することで開発者が小さな範囲で リファクタリング候補を検討することができるということがわかりました。 開発者が検出箇所に注目しリファクタリングを検討可能 RishuuServiceクラスがJugyouKamokuクラス とGakuseiクラスのデータを管理 2019/5/30

考察と評価 提案手法によりリファクタリング候補の検出を行うことが可能 他のデザインパターンについても同様の支援を行うことが出来ると考えられる 開発者は検出された小さな範囲で設計を確認可能なことがわかった 他のデザインパターンについても同様の支援を行うことが出来ると考えられる 実験に対しての考察と評価を行います。 提案手法によりリファクタリング候補の検出を行うことが出来ました。 実装したツールを適用することで開発者が小さな範囲で設計を確認できることが わかりました。 他の様々なデザインパターンの適用条件と合致する箇所を確認することで設計の特性を知ることが できると考えられます。 2019/5/30

まとめと今後の課題 UMLモデル上でのリファクタリング候補検出手法を提案 今後の課題 デザインパターン適用可能箇所を 開発者に提示 デザインパターン適用可能箇所を　　　　　　開発者に提示 実装したツールを用いた適用実験 今後の課題 より多くの例題に適用し、定量的に評価 まとめと今後の課題です。 2019/5/30

最後までありがとうございました 2019/5/30