同時変更が生じたTemplate Method パターンの適用事例の調査

Presentation on theme: "同時変更が生じたTemplate Method パターンの適用事例の調査"— Presentation transcript:

1 同時変更が生じたTemplate Method パターンの適用事例の調査
○齋藤 晃，吉田 則裕， 松下 誠, 井上 克郎 大阪大学 情報科学研究科 井上研究室　 2009/2/23

2 目次 背景 問題点 調査内容 調査方法 調査結果 評価とまとめ 提案メトリクスの説明 デザパタ=テンプレートメソッドパターンをもちいるよ
そもそもデザインパターンとは， プログラム設計における，典型的な問題の解決策をあつめたもの，と定義されており， これは，過去の熟練者が，いままでに経験したノウハウを蓄積したものを解決策としてまとめたものです． デザインパターンはいろいろな種類がありますが，一般にはGammaらの提案した23のパターンがよく知られています． デザインパターンを利用することで得られる利点としては，クラスの保守性・拡張性が向上すること， およびデザインパターンにはそれぞれ名前がついていることから，クラス設計の際に，共通の語彙としてコミュニケーションが取れるなどが 挙げられます

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

4 abstract draw(Graphics g)
Template Methodパターン 親クラスのあるメソッド内で抽象メソッドを呼ぶ Figure void drawFigure(){ 　g.cleargraphics(); draw(g); ・・・ } PrimitiveOperation abstract draw(Graphics g) drawFigure() ・・・・・・・・・・・ TemplateMethod 抽象メソッド １つ以上のクラスが継承 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は異なる処理内容を共通のインターフェースで動作させられる特徴を持ちます． クラス追加 異なる処理を 共通のインターフェースで動作 抽象メソッドをオーバーライド 抽象メソッドをオーバーライド 変更範囲を限定することで保守性が向上

5 問題点(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 多くのクラスに同時に変更が生じるのは望ましくない

6 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() パターンの適用により同時変更が生じる

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

8 仮説の検証方法 手順１：同時変更の検出 同時変更が生じたクラスとそうでないクラスに分類 手順２：クラスの処理内容の差異を表すメトリクスを定義
子クラスの処理内容の差異が大きいほど同時変更が生じやすい 検証方法 手順１：同時変更の検出 同時変更が生じたクラスとそうでないクラスに分類 手順２：クラスの処理内容の差異を表すメトリクスを定義 手順３：それぞれのメトリクス値を比較・評価 マン・ホイットニーのU検定を使用 次に，仮説の検証方法について説明します． まず，子クラスの処理差異を表すメトリクスを定義します． 次に，これらのメトリクス値が低いデザインパターンの適用事例において，同時変更が起こるかどうかを調査します． 仮説内容をみぎはしにかいとく どうやって仮説を検証するか クラスの処理差異をあらわすメトリクス４つ定義 これらメトリクス値の低い適用事例のテンプレートメソッドをさがす 本研究では，変更の起こる要因が以下の２つであると考えました． 仮説説明 同時に変更が生じる以下の３つに着目する これらの例についてせつめいします

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

10 手順１．同時変更の検出 抽象メソッドが変更の前後で以下の条件を満たせば，同時変更は生じていないと判定
条件a: 同一のクラス名を持つクラスで定義されている YES NO クラス消滅 条件b: 同一のメソッド名を持つTemplate Methodから呼び出されている NO Template Methodが同一のクラス名を持つクラスで定義されている YES YES NO 本研究では３つのメトリクスを計測しました． 本発表では型名類似度のみの説明を行いますが， 識別子名類似度も計測方法は同様で，型名以外の識別を 識別子類似度とは，メソッド内に定義されるメソッドの，， 抽象メソッドの数の変更 Template Method消滅 条件c: 同一のメソッド定義を持つ YES NO Primitive Operationの 定義が変更 同時変更なし 10 10

11 手順２．処理内容の差異を表すメトリクスを計測
クラスの処理内容の差異を表すメトリクスを定義 型名類似度SimT メソッド内で利用された型名に着目 識別子名類似度SimⅠ メソッド内で利用された型名を除く識別子名に着目 本研究では３つのメトリクスを計測しました． 本発表では型名類似度のみの説明を行いますが， 識別子名類似度も計測方法は同様で，型名以外の識別を 識別子類似度とは，メソッド内に定義されるメソッドの，， 11 11

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

13 型名類似度SimT 2/2 メソッド内の一時変数・参照変数の型名と呼び出されるメソッドの引数・戻り値の型名の一致割合
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 13 13

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

15 識別子名類似度SimⅠ 2/2 メソッド内の一時変数・参照変数の識別子名と呼び出されているメソッド名の一致割合(ただし型名は除く)
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 15 15

16 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.変更の有無とメトリクス値の関係を評価 変更有 パターン 変更無 パターン 出力：メトリクス値 [2]Nikolaos Tsantalis,Design pattern detection using similarity scoring. IEEE Transactions on Software Engineering, 2006

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

18 結果の分析 次のバージョンで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

19 本調査の妥当性 本調査の妥当性に影響を及ぼす要因 適用事例検出ツールの誤検出 クラス名のみが変更されたときの誤検出
しかし，使用したツールは適合率が高く，対象としたTemplate Methodパターンは検出が比較的容易であるため，影響は小さいと考えられる クラス名のみが変更されたときの誤検出 クラス内部が変更されずに，クラス名のみが変更された場合，クラスが消滅したと扱われる

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

21 ご静聴ありがとうございました 2009/2/23

22 質疑応答 相関係数

23 関連研究 仮説1に従う傾向が得られたが，仮説2,3に反する結果となった
Biemanらは，デザインパターンの適用事例を用いたプログラムの評価を行うために，以下の仮説を調査 仮説1. 規模の大きなクラスは変更されやすい． 仮説2. デザインパターンが適用されているクラスはそうでないクラスより変更されにくい． 仮説3. 継承によって再利用されているクラスはそうでないクラスより変更されにくい． 仮説1に従う傾向が得られたが，仮説2,3に反する結果となった 本調査ではデザインパターンの適用事例の評価基準として変更頻度が高くなる要因に着目した [2] J.Bieman, D.Jain, and H.Yang. OO design patterns, design structure, and program changes: an industrial case study. ICMS ’01 , pp. 580–589, 2001. [3] J.Bieman, G.Straw, H.Wang, P.Munger, and R.Alexander. Design patterns and change proneness: An examination of five evolving systems. METRICS ’03 , pp. 40–49, 2003.

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

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

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

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

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

29 変更結果の例 子クラスの処理差異が変更の要因となっているか？ 処理差異が変更の要因になっている 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

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

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

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

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

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

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

36 同時変更の判定アルゴリズム 1/2 変更の前後で以下の条件を満たせば，同時変更は生じていないと判定
同時変更の判定アルゴリズム 1/2 変更の前後で以下の条件を満たせば，同時変更は生じていないと判定 条件１．同一のクラス名を持つクラスで定義されている 条件２．同一のメソッド名を持つTemplate Methodから呼び出されている 条件３．同一のメソッド定義を持つ 本研究では３つのメトリクスを計測しました． 本発表では型名類似度のみの説明を行いますが， 識別子名類似度も計測方法は同様で，型名以外の識別を 識別子類似度とは，メソッド内に定義されるメソッドの，，