デザインパターンの適用事例に対するプログラムの安定性の調査 井上研究室　 齋藤　晃 2009/2/23 特別研究発表会

背景:デザインパターンの重要性 オブジェクト指向設計に関する典型的な問題の解決策 熟練者が過去に蓄積したノウハウ デザインパターンとは オブジェクト指向設計に関する典型的な問題の解決策 クラスの保守性が向上 熟練者が過去に蓄積したノウハウ Gammaらの提案した23個のパターンが有名[1] Template Methodパターン デザインパターンの１例 多くの既存コードで使用されており，ソースコードから検出も比較的容易 他のパターンの一部としてよく使われている デザパタ=テンプレートメソッドパターンをもちいるよ そもそもデザインパターンとは， プログラム設計における，典型的な問題の解決策をあつめたもの，と定義されており， これは，過去の熟練者が，いままでに経験したノウハウを蓄積したものを解決策としてまとめたものです． デザインパターンはいろいろな種類がありますが，一般にはGammaらの提案した23のパターンがよく知られています． デザインパターンを利用することで得られる利点としては，クラスの保守性・拡張性が向上すること， およびデザインパターンにはそれぞれ名前がついていることから，クラス設計の際に，共通の語彙としてコミュニケーションが取れるなどが 挙げられます 特別研究発表会 2009/2/23 [1] E .Gamma, R. Helm, R. Johnson, and J. M. Vlissides. Elements of Reusable Object-Oriented Software. Addison Wesley, 1995.

Template Methodパターン 変更範囲を限定することで保守性が向上 ・・・・・・・・・・・ 親クラスのあるメソッド内で抽象メソッドを呼ぶ void drawFigure(){ 　g.cleargraphics(); draw(g); ・・・ } Figure abstract draw(Graphics g) drawFigure() ・・・・・・・・・・・ 抽象メソッド １つ以上のクラスが継承 Figure f1 = new Circle(); Figure f2 = new Rectangle(); f1.drawFigure(); f2.drawFigure(); Figure f1 = new Circle(); Figure f2 = new Rectangle(); Figure f3 = new Triangle(); f1.drawFigure(); f2.drawFigure(); f3.drawFigure(); Circle Rectangle Triangle draw(Graphics g) draw(Graphics g) draw(Graphics g) デザインパターンをしようすることで安定性が向上する？ がんばる(あにめーしょんつかって) デザインパターンの一例としてTMPが挙げられます TMPはひとつの親クラスとそれを継承する複数の子クラスから構成されます． 親クラスは抽象メソッドを定義し，子クラスがオーバーライドします． また親クラスは抽象メソッドを内部で呼び出す具象メソッドを持ちます． このような構造を持つクラス群をTMPと呼びます． TMPは異なる処理内容を共通のインターフェースで動作させられる特徴を持ちます． クラス追加 異なる処理を 共通のインターフェースで動作 抽象メソッドをオーバーライド 抽象メソッドをオーバーライド 変更範囲を限定することで保守性が向上 特別研究発表会 2009/2/23

問題点(1/2) Template Methodパターンの適用事例の中には，安定性が低いものが存在 安定性が低い…ソフトウェア保守において多くのクラスに変更が生じる ・・・・・ 1つだけ変更 Version1.0 Version1.1 Version1.2 Version1.3 ・・・・・ しかし，DPのなかには，安定性が低いものがあるということが問題点としてあげられます 安定性が低いということは，ソフトウェア進化において，多くのクラスに変更が生じるということです． 例えば上の例は，バージョン間の変化で1つしか変更が起こりませんが， 下の例は，バージョン間の変化によってすべてのクラスが変更されています， このようなクラスは，安定性が低いといえ，多くのクラスに同時に変更が生じるのは望ましくないといえます． ソフトウェアのバージョン進化によって，頻繁に変更されるソフトウェアは 安定性が低いといえます 安定性が低い⇒頻繁に変更されるという論理？ 頻繁に変更される⇒同時に変更される，に置き換わってる？ 次のページにわける バージョン変化をふやす 時系列のイメージ　変更されてるパターンとされてないパターンのずをかく 変更の波及 安定性が低い要因が分かってない しかし，問題点として，変更の種類によっては，かえって変更範囲が増大することがあります． DPを適用することによって，基本的にクラス数は増大しますが，DPに関連するクラスすべてに変更が及ぶことがあります． たとえば，このように，抽象メソッドの引数が変更された場合など，このように，継承するすべての子クラスも修正する必要があります．複数のクラスに同時に変更が生じるのは保守性の観点から見てのぞましくないので，このような変更はよくないといえます． 複数のクラスが変更 Version1.0 Version1.1 Version1.2 Version1.3 多くのクラスに同時に変更が生じるのは望ましくない 特別研究発表会 2009/2/23

abstract draw(Graphics g) 問題点(2/2)　–同時変更の例- 関連するクラス全てを同時に変更する必要がある Figure 変更 Figure abstract draw(Graphics g) drawFigure() abstract draw() drawFigure() Circle Rectangle Triangle draw(Graphics g) draw(Graphics g) draw(Graphics g) 変更 変更 変更 Template Methodパターンの適用による同時変更の例を示します， このように抽象メソッドの定義が変化した場合， 関連するクラスすべても変更する必要があるため，関連するクラスすべて変更する必要があります このように，パターンの適用により同時変更が生じる例は望ましくないといえます Circle Rectangle Triangle draw() draw() draw() パターンの適用により同時変更が生じる 特別研究発表会 2009/2/23

研究内容 デザインパターンの安定性を低下させる要因を調査 安定性が低い‥同時変更が生じやすい 仮説１：子クラスの処理内容の差異が大きいほど 安定性を低下させる要因は何か？ ここだけ説明 仮説１：子クラスの処理内容の差異が大きいほど 同時変更が生じやすい 仮説２：子クラスの処理内容の規模が大きいほど 　同時変更が生じやすい 仮説１を設定した理由 そこで，デザパタの安定性を低下させる要因を調査します． ここで，安定性が低下するとは，同時変更が生じやすい，と定義しました． 本研究では，安定性が低下する要因を以下のように定義しました． ここでは，1つ目の「子クラスの処理内容の差異が大きいほど同時変更が生じやすい」 という内容について説明します 仮説１の理由としては， 安定性が低下する要因を２つ提起しました． 本発表で１つは，… 仮説１を設定した理由としては，クラスの処理差異によってことなる変更が個別のクラスに加えられやすくなり， 親クラスのメソッドが変更されやすくなるからです 変更に弱いことをせつめいする そこで，本研究では，TMPに着目して，同時変更されやすいパターンとそうでないパターンに分類することを試みます． つまりDPの変更要因の調査をおこないます TMPの構成要素として，抽象メソッドとして定義され子クラスでオーバーライドされるメソッドPO と，それを内部で呼び出すメソッドtmで構成されます． TMPに着目する理由としては… 差異が大きいと子クラスごとに処理を切り替えることが難しくなり，親クラスに変更が波及する 同時変更が起こりやすくなる 特別研究発表会

子クラスの処理内容に差異が大きいほど変更されやすい 仮説１の検証方法 仮説1 子クラスの処理内容に差異が大きいほど変更されやすい 検証方法 クラスの処理差異を表すメトリクスを定義し，計測 計測したメトリクスの値が，同時変更に関係があるかどうかを調査 対象とする同時変更 次に，仮説の検証方法について説明します． まず，子クラスの処理差異を表すメトリクスを定義します． 次に，これらのメトリクス値が低いデザインパターンの適用事例において，同時変更が起こるかどうかを調査します． 仮説内容をみぎはしにかいとく どうやって仮説を検証するか クラスの処理差異をあらわすメトリクス４つ定義 これらメトリクス値の低い適用事例のテンプレートメソッドをさがす 本研究では，変更の起こる要因が以下の２つであると考えました． 仮説説明 同時に変更が生じる以下の３つに着目する これらの例についてせつめいします 抽象メソッドのメソッド定義の変更 抽象メソッドの数の変更 Template Methodの消滅 特別研究発表会 2009/2/23

調査する変更 これらの変更の有無を調査 変更前 変更後 抽象メソッドのメソッド定義の変更 抽象メソッドの数の変更 Template Methodの消滅 これらの変更の有無を調査 SuperClass SuperClass templateMethod() primitiveOperation() templateMethod() primitiveOperation(int) templateMethod() primitiveOperation() primitiveOperation2() anotherMethod() クラス名をもっと分かりやすく 意味がよくわからｎ もじでかくする それぞれについてせつめい これらの変更は，いずれも複数のクラスに変更が及ぶので望ましくない変更といえます． これらの変更が生じたかどうかを調査します． SubClass1 SubClass2 SubClass1 SubClass2 primitiveOperation() primitiveOperation() primitiveOperation(int) Operation1() primitiveOperation() primitiveOperation2() primitiveOperation() primitiveOperation2() primitiveOperation(int) Operation() 変更前 変更後 特別研究発表会 2009/2/23

計測するメトリクス 型名類似度SimT 識別子名類似度SimⅠ LOC分散LOCv メソッド内で利用された型名に着目 ここだけ説明 型名類似度SimT メソッド内で利用された型名に着目 識別子名類似度SimⅠ メソッド内で利用された型名を除く識別子名に着目 LOC分散LOCv メソッド内のLOC(コード行数)の分散 本研究では３つのメトリクスを計測しました． 本発表では型名類似度のみの説明を行いますが， 識別子名類似度も計測方法は同様で，型名以外の識別を 識別子類似度とは，メソッド内に定義されるメソッドの，， 特別研究発表会 2009/2/23

型名類似度SimT メソッド内の一時変数・参照変数の型名と呼び出されるメソッドの引数・戻り値の型名の一致割合 抽象メソッドをオーバーライド AbstractScanner templateMethod abstract newScanner() Scanner1 newScanner() Scanner2 メトリクス計測対象となるメソッド Scanner1クラスのnewScannerメソッド protected Scanner newScanner() { ZipScanner zs = new ZipScanner(); zs.setEncoding(encoding); defaultEncoding = false; return zs; } T1 = {boolean, String, ZipScanner} String T2 = {boolean, TarScanner} boolean メトリクス値 Scanner2クラスのnewScannerメソッド トリクス計測対象となるのは，この子クラスに定義されるメソッドで， このメソッド内の一時変数・参照変数の型名と関数の引数・戻り値の一致割合を型名類似度と定義します． こちらのクラスで現れる型名はこの３つとなり， …のクラスで現れる型名はこの２つとなり， これらの類似度を次の式のように算出します． 型名類似度とは，メソッド内の一時変数・参照変数の型名と，呼び出される関数の引数・戻り値の型名の一致割合と 定義します． 対象となるメソッドはこのような子クラスのメソッドで，この場合，抽出される型名はこのようになり， 類似度はこのように計算されます． protected Scanner newScanner() { TarScanner zs = new TarScanner(); defaultEncoding = false; return zs; } SimT = = 0.25 boolean 特別研究発表会 2009/2/23

識別子名類似度SimⅠ メソッド内の一時変数・参照変数の識別子名と呼び出されているメソッド名の一致割合(ただし型名は除く) Scanner1クラスのnewScannerメソッド protected Scanner newScanner() { ZipScanner zs = new ZipScanner(); zs.setEncoding(encoding); defaultEncoding = false; return zs; } Ⅰ1 = {defaultEncoding, zs， 　　　　encoding, setEncoding} Ⅰ2 = {defaultEncoding, zs} メトリクス値 Scanner2クラスのnewScannerメソッド 識別子名類似度も同様に，メトリクス計測対象となるメソッドは同じですが， メソッド内に定義される一時変数・参照変数の識別子名と呼び出されている関数名の一致割合と定義します． ただし方名は除く ただし型名はのぞく 識別子類似度も同様に子クラスのメソッドを対象とし，メソッド内の一時変数・参照変数の識別子および 定義されている関数名の一致割合と定義します． このばあいこのように計算されます protected Scanner newScanner() { TarScanner zs = new TarScanner(); defaultEncoding = false; return zs; } SimⅠ = = 0.5 特別研究発表会 2009/2/23

1.Template Methodパターン検出 変更の検出およびメトリクス計測の流れ 入力：Javaソースコード ：Javaバイトコード ソースコード バージョン1.0 ソースコード バージョン1.1 ソースコード バージョン1.2 バイトコード バージョン1.0 バイトコード バージョン1.1 バイトコード バージョン1.2 1.Template Methodパターン検出 デザインパターン 検出ツール[2] メソッド名，クラス位置などの情報を取得 調査ツール 分類処理部 メトリクス 計測ツール 2.変更の有無による 分類 変更の検出方法について説明します． まず，各バージョンのJavaソースコードとJavaバイトコードを入力とします． Javaバイトコードを用いて，デザインパターン検出ツールによってTemplate Methodパターンの適用事例を検出します． その情報をもとに，デザインパターンの適用事例を，変更の生じたパターンの適用事例と，変更の生じなかった適用事例に分類します． それらに対して，メトリクス計測を行い，変更の生じたパターンの適用事例と変更の生じなかった適用事例で差があったかどうかを調査します． 変更の検出およびメトリクス計測の流れを説明します ． まず，各バージョンのソースコードとJavaバイトコードを入力とします． Javaバイトコードから，デザパタ検出ツールを用いて，デザインパターンの適用事例を検出します． それらの情報とソースコードをもとに，デザインパターンの適用事例に変化が生じたパターンと，変化が生じなかったパターンに分類します． 調査方法を説明します． まずリポジトリから各バージョンごとのソースコードとJavaバイトコードを入手します． javaバイトコードに対して，DP検出ツールを用いて，TMPを検出します． また，メトリクス計測ツールを用いて，メソッド名やクラスパスなど，TMPの詳細なクラス情報を取得します． これらの情報をもとに，ソースコードからTMPに変更が生じたかどうか判断し，変更されたPと変更されなかったPに分類します． それぞれ分類されたパターンから，メトリクス計測します． 計測されたメトリクスか変更の生じたPとそうでないPの間で差異があるかどうかを評価します． つぎに，計測するメトリクスの内容について説明します． 分類データ 3.メトリクス計測 4.変更の有無とメトリクス値の関係を評価 変更有 パターン 変更無 パターン 出力：メトリクス値 特別研究発表会 2009/2/23 [2]Nikolaos Tsantalis,Design pattern detection using similarity scoring. IEEE Transactions on Software Engineering, 2006

メトリクス計測結果 調査対象：オープンソースソフトウェア8個 型名類似度 識別子名類似度 類似度 類似度 Ant, ANTLR, ArgoUML, FindBugs, JFreeChart, JRefactory, JHotDraw, Log4j 変更なし：272個，変更あり：68個 変更なし 型名類似度 変更あり 類似度 類似度 識別子名類似度 変更なし 変更あり 第３四分位 中央値 計測結果を説明します． 対象となるソフトウェアはオープンソースソフトウェア８種です， 左側が型名類似度で，右側が識別子類似度の計測結果で， グラフ中の左側が，変更の生じなかったパターンの適用事例のメトリクスの分布で，右側が変更の生じたパターンの適用事例のメトリクスの分布 を示します． 図中の長方形の下側の線が第１四分位，上側が第３四分位，真ん中が中央値を表しています． この結果から，変更の生じたパターンの適用事例のほうが，変更の 第１四分位とメジアンに差があった 差があったからなんなの？ ⇒メトリクス値を用いた安定性の推定ができるかも このように定義したメトリクスを計測した結果を説明します． 対象となるソフトウェアは，ソフトウェアリポジトリから入手できるオープンソースソフトウェア8種です． 左のグラフが，変更が生じなかったパターンの類似殿分布を示しており，右側が変更の生じたパターンの 類似度分布を示しています． このグラフから，変更の生じたパターンのほうが，類似度が低い傾向にあるということが分かります． また，両者でU検定を行ったところ，危険率１％でも有意差があることが分かりました． 第１四分位 同時変更が生じたパターンの適用事例ほうが類似度が低い傾向 マン・ホイットニーのU検定で有意差 型名類似度：P=0.0014, 識別子名類似度：P=0.0053 特別研究発表会 2009/2/23

結果の分析 次のバージョンでTemplate Methodが消滅 処理内容の差異が原因で，Template Methodが消滅 提案した類似度が低く，変更が生じた例 FigCallAction::layoutActivations SimⅠ = 0.0, SimT = 0.0 protected void layoutActivations() { if (!getSrcFigObject().hasActivations()) { getSrcFigObject().makeActivation( getSrcFigObject().getObjectNode(), (Node) getSrcLinkPort()); ・・・ } else { ・・・ } FigLink layoutEdge abstract layoutActivations 処理を記述 FigCallAction FigReturnAction FigCallAction::layoutActions layoutActivations layoutActivations 子クラスの処理差異が変更の要因となっているか？ 最後に実際に行われた変更の例として， 類似度が小さく，変更された例を示します． この場合，2つの子クラスが継承しているのですが，片方は処理のみ実装され， もう片方には処理が記述されていないクラスが存在しました． このクラスは，次のバージョンでTemplate Methodパターンの消滅するという変更が生じました． １つのクラスだけ処理内容が大きいので，処理の切り替えが難しくなり，変更が生じたと考えられます． このような例は，子クラスのメソッドの処理差異が原因で変更されたと考えられますｙ またそれが提案したメトリクスで計測可能であったことがいえます． 計測したメトリクスは有効！！！ 処理の差異というより，単純に記述してない子クラスがふようなだけなんじゃないの？ ⇒処理内容がある程度でかくなると，切り替え自体がむずかしくなり，TemplateMethodパターン存続が難しくなったんじゃないのかなぁ protected void layoutActivations(){ //TODO: Auto-generated method stub } 処理を記述していない 次のバージョンでTemplate Methodが消滅 処理内容の差異が原因で，Template Methodが消滅 特別研究発表会 2009/2/23

まとめと今後の課題 まとめ 今後の課題 Template Methodパターンの適用事例の安定性を低下させる要因を調査 識別子名類似度・型名類似度の安定性との関係 マン・ホイットニーのU検定で有意差 今後の課題 他のパターンへの適用 同時変更が生じやすい適用事例を自動的に特定 安定性の低い適用事例が実装されたら警告する機能を統合開発環境に実現 特別研究発表会 2009/2/23

ご静聴ありがとうございました 2009/2/23 特別研究発表会

質疑応答 相関係数 特別研究発表会 2009/2/23

検定について 得られたデータは正規分布とは言えなかった マン・ホイットニーのU検定 両側に値が寄っているため コルモゴロフ-スミルノフ検定(KS検定)で確認 マン・ホイットニーのU検定 ノンパラメトリック検定の１つ 順位和による差異を検定 帰無仮説：2群の代表値に差がない(代表値R1= R2:) 対立仮説：2群の代表値に差がある(代表値R1< R2:片側検定) 特別研究発表会 2009/2/23

仮説２について 仮説２：子クラスの処理内容の規模が大きいほど変更されやすい LOC平均を計測 U検定で有意差なし (P= 0.139) 処理内容の規模と同時変更の差異に相関は見られなかった 変更なし 変更あり 特別研究発表会 2009/2/23

LOC分散について 子クラスの抽象メソッドの差異を計測 U検定でP値0.0467 類似度 対数(標準偏差)で表示 変更なし 変更あり 特別研究発表会 2009/2/23

計測したメトリクス値(1/2) LOC平均 LOC分散 特別研究発表会 2009/2/23

計測したメトリクス値(2/2) 識別子類似度 型名類似度 特別研究発表会 2009/2/23

変更結果の例 子クラスの処理差異が変更の要因となっているか？ 処理差異が変更の要因になっている SubClass1 SimⅠ = 0.0, SimT = 0.0 protected boolean isValidElement(MBase o){ return o instanceof MAssociationRole … } SubClass2 protected boolean isValidElement(MBase elem){ return elem instanceof MAssociation … } 引数がObjectに変化 処理差異が変更の要因になっている 特別研究発表会 2009/2/23

計測したメトリクスについて 型名類似度と識別子名類似度の相関 相関係数0.567 変更なし：0.511 変更あり：0.803

LOC分散 U検定でP値0.0467 危険率５％で有意差 特別研究発表会 2009/2/23

LOC平均 U検定でP値0.1392 特別研究発表会 2009/2/23

識別子名類似度 U検定で有意差(P=0.0053)

型名類似度 U検定で有意差(P=0.0014)

計測するメトリクス(1/2) 子クラスのLOC平均LOCa 子クラスのLOC分散LOCv 識別子類似度SimⅠ 型名類似度SimT メソッド内で定義される一時変数・参照変数の識別子名と呼び出されている関数名の一致割合 型名類似度SimT メソッド内で定義される一時変数・参照変数の型名と呼び出される関数の引数・戻り値の型の一致割合 特別研究発表会 2009/2/23