デザインパターンの適用事例に対するプログラムの安定性の調査

Slides:



Advertisements
Similar presentations
オブジェクト指向 言語 論 第八回 知能情報学部 新田直也. 多相性(最も単純な例) class A { void m() { System.out.println( “ this is class A ” ); } } class A1 extends A { void m() { System.out.println(
Advertisements

ソフトウェア工学 知能情報学部 新田直也. オブジェクト指向パラダイムと は  オブジェクト指向言語の発展に伴って形成され てきたソフトウェア開発上の概念.オブジェク ト指向分析,オブジェクト指向設計など,プロ グラミング以外の工程でも用いられる.  ソフトウェアを処理や関数ではなくオブジェク.
背景 ソフトウェアの大規模化・複雑化 生産性と品質の向上 ↓ オブジェクト指向分析設計の適用 開発ツールの投入.
同時変更が生じたTemplate Method パターンの適用事例の調査
Myoungkyu Song and Eli Tilevich 発表者: 石尾 隆(大阪大学)
情報伝播によるオブジェクト指向プログラム理解支援の提案
研究の背景 コードクローン ソースコード中に存在する一致または類似したコード片
正規性の検定 ● χ2分布を用いる適合度検定 ●コルモゴロフ‐スミノルフ検定
リファクタリングのための 変更波及解析を利用した テスト支援ツールの提案
メソッド名とその周辺の識別子の 相関ルールに基づくメソッド名変更支援手法
プログラム実行履歴を用いたトランザクションファンクション抽出手法
ソースコードの変更履歴における メトリクス値の変化を用いた ソフトウェアの特性分析
ギャップを含むコードクローンの フィルタリング手法の提案
Javaクラスの利用関係を用いた ソフトウェア部品のカテゴリ階層構築法
コードクローンに含まれるメソッド呼び出しの 変更度合の分析
コードクローンに含まれるメソッド呼び出しの 変更度合の調査
アルゴリズムとプログラミング (Algorithms and Programming)
識別子の命名支援を目的とした動詞-目的語関係の辞書構築
ソードコードの編集に基づいた コードクローンの分類とその分析システム
独習JAVA 6.8 コンストラクタの修飾子 6.9 メソッドの修飾子 6.10 ObjectクラスとClassクラス 11月28日(金)
オブジェクト指向 プログラミング 第十三回 知能情報学部 新田直也.
暗黙的に型付けされる構造体の Java言語への導入
コードクローンの分類に基づいた メソッド引き上げ手順の提案とその有効性評価
シーケンス図を用いて実行履歴を可視化するデバッグ環境の試作
利用関係に基づく類似度を用いたJavaコンポーネント分類ツールの作成
11 ソフトウェア工学 Software Engineering デザインパターン DESIGN PATTERNS.
Javaプログラムの変更を支援する 影響波及解析システム
コードクローン検出ツールを用いた ソースコード分析システムの試作と プログラミング演習への適用
リファクタリング支援のための コードクローンに含まれる識別子の対応関係分析
プログラム動作理解支援を目的とした オブジェクトの振舞いの同値分割手法
ソースコードの特徴量を用いた機械学習による メソッド抽出リファクタリング推薦手法
オブジェクト指向言語論 第十一回 知能情報学部 新田直也.
コードクローンの動作を比較するためのコードクローン周辺コードの解析
UMLモデルを対象とした リファクタリング候補検出の試み
コードクローン検出に基づくデザイン パターン適用支援手法の提案と実現
バイトコードを単位とするJavaスライスシステムの試作
コードスメルの深刻度がリファクタリングの実施に与える影響の実証的研究
オブジェクト指向言語論 第十一回 知能情報学部 新田直也.
○ 後藤 祥1,吉田 則裕2 ,井岡 正和1 ,井上 克郎1 1大阪大学 2奈良先端科学技術大学院大学
コードクローンの理解支援を目的としたコードクローン周辺コードの解析
コードクローン分類の詳細化に基づく 集約パターンの提案と評価
コーディングパターンの あいまい検索の提案と実装
「アルゴリズムとプログラム」 結果を統計的に正しく判断 三学期 第7回 袖高の生徒ってどうよ調査(3)
アルゴリズムとプログラミング (Algorithms and Programming)
コードクローン間の依存関係に基づく リファクタリング支援環境の実装
コードクローンの分布情報を用いた特徴抽出手法の提案
プログラミング言語論 第十三回 理工学部 情報システム工学科 新田直也.
ソフトウェア工学 知能情報学部 新田直也.
メトリクス値の変化に基づく コードクローンの編集傾向分析
プログラムスライスを用いた凝集度メトリクスに基づく 類似メソッド集約候補の順位付け手法
設計情報の再利用を目的とした UML図の自動推薦ツール
保守請負時を対象とした 労力見積のためのメトリクスの提案
アスペクト指向言語のための視点に応じた編集を可能にするツール
クローン検出ツールを用いた ソフトウェアシステムの類似度調査
オープンソースソフトウェアに対する コーディングパターン分析の適用
メソッドの同時更新履歴を用いたクラスの機能別分類法
ソフトウェア工学 知能情報学部 新田直也.
ソフトウェア工学 理工学部 情報システム工学科 新田直也.
コードクローン間の依存関係に基づく リファクタリング支援手法の提案と実現
UMLモデルを対象とした リファクタリング候補検出手法の提案と実現
ロールを基にした構造進化の表現 Role based Evolution Dependency Structure Matrix
欠陥検出を目的とした類似コード検索法 吉田則裕,石尾隆,松下誠,井上克郎 大阪大学 大学院情報科学研究科
ソフトウェア理解支援を目的とした 辞書の作成法
ソフトウェア工学 知能情報学部 新田直也.
複雑度メトリクスを用いた JAVAプログラム品質特性の実験的評価
コードクローン解析に基づく デザインパターン適用候補の検出手法
オブジェクト指向言語における セキュリティ解析アルゴリズムの提案と実現
プログラム理解のための 付加注釈 DocumentTag の提案
プログラム依存グラフを用いた ソースコードのパターン違反検出法
Presentation transcript:

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

背景:デザインパターンの重要性 オブジェクト指向設計に関する典型的な問題の解決策 熟練者が過去に蓄積したノウハウ デザインパターンとは オブジェクト指向設計に関する典型的な問題の解決策 クラスの保守性が向上 熟練者が過去に蓄積したノウハウ Gammaらの提案した23個のパターンが有名[1] Template Methodパターン デザインパターンの1例 多くの既存コードで使用されており,ソースコードから検出も比較的容易 他のパターンの一部としてよく使われている デザパタ=テンプレートメソッドパターンをもちいるよ そもそもデザインパターンとは, プログラム設計における,典型的な問題の解決策をあつめたもの,と定義されており, これは,過去の熟練者が,いままでに経験したノウハウを蓄積したものを解決策としてまとめたものです. デザインパターンはいろいろな種類がありますが,一般には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() ・・・・・・・・・・・ 抽象メソッド 1つ以上のクラスが継承 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:子クラスの処理内容の差異が大きいほど 安定性を低下させる要因は何か? ここだけ説明 仮説1:子クラスの処理内容の差異が大きいほど 同時変更が生じやすい 仮説2:子クラスの処理内容の規模が大きいほど  同時変更が生じやすい 仮説1を設定した理由 そこで,デザパタの安定性を低下させる要因を調査します. ここで,安定性が低下するとは,同時変更が生じやすい,と定義しました. 本研究では,安定性が低下する要因を以下のように定義しました. ここでは,1つ目の「子クラスの処理内容の差異が大きいほど同時変更が生じやすい」 という内容について説明します 仮説1の理由としては, 安定性が低下する要因を2つ提起しました. 本発表で1つは,… 仮説1を設定した理由としては,クラスの処理差異によってことなる変更が個別のクラスに加えられやすくなり, 親クラスのメソッドが変更されやすくなるからです 変更に弱いことをせつめいする そこで,本研究では,TMPに着目して,同時変更されやすいパターンとそうでないパターンに分類することを試みます. つまりDPの変更要因の調査をおこないます TMPの構成要素として,抽象メソッドとして定義され子クラスでオーバーライドされるメソッドPO と,それを内部で呼び出すメソッドtmで構成されます. TMPに着目する理由としては… 差異が大きいと子クラスごとに処理を切り替えることが難しくなり,親クラスに変更が波及する 同時変更が起こりやすくなる 特別研究発表会

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

調査する変更 これらの変更の有無を調査 変更前 変更後 抽象メソッドのメソッド定義の変更 抽象メソッドの数の変更 Template Methodの消滅 これらの変更の有無を調査 SuperClass SuperClass templateMethod() primitiveOperation() templateMethod() primitiveOperation(int) templateMethod() primitiveOperation() primitiveOperation2() anotherMethod() クラス名をもっと分かりやすく 意味がよくわからn もじでかくする それぞれについてせつめい これらの変更は,いずれも複数のクラスに変更が及ぶので望ましくない変更といえます. これらの変更が生じたかどうかを調査します. 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(コード行数)の分散 本研究では3つのメトリクスを計測しました. 本発表では型名類似度のみの説明を行いますが, 識別子名類似度も計測方法は同様で,型名以外の識別を 識別子類似度とは,メソッド内に定義されるメソッドの,, 特別研究発表会 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メソッド トリクス計測対象となるのは,この子クラスに定義されるメソッドで, このメソッド内の一時変数・参照変数の型名と関数の引数・戻り値の一致割合を型名類似度と定義します. こちらのクラスで現れる型名はこの3つとなり, …のクラスで現れる型名はこの2つとなり, これらの類似度を次の式のように算出します. 型名類似度とは,メソッド内の一時変数・参照変数の型名と,呼び出される関数の引数・戻り値の型名の一致割合と 定義します. 対象となるメソッドはこのような子クラスのメソッドで,この場合,抽出される型名はこのようになり, 類似度はこのように計算されます. 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個 変更なし 型名類似度 変更あり 類似度 類似度 識別子名類似度 変更なし 変更あり 第3四分位 中央値 計測結果を説明します. 対象となるソフトウェアはオープンソースソフトウェア8種です, 左側が型名類似度で,右側が識別子類似度の計測結果で, グラフ中の左側が,変更の生じなかったパターンの適用事例のメトリクスの分布で,右側が変更の生じたパターンの適用事例のメトリクスの分布 を示します. 図中の長方形の下側の線が第1四分位,上側が第3四分位,真ん中が中央値を表しています. この結果から,変更の生じたパターンの適用事例のほうが,変更の 第1四分位とメジアンに差があった 差があったからなんなの? ⇒メトリクス値を用いた安定性の推定ができるかも このように定義したメトリクスを計測した結果を説明します. 対象となるソフトウェアは,ソフトウェアリポジトリから入手できるオープンソースソフトウェア8種です. 左のグラフが,変更が生じなかったパターンの類似殿分布を示しており,右側が変更の生じたパターンの 類似度分布を示しています. このグラフから,変更の生じたパターンのほうが,類似度が低い傾向にあるということが分かります. また,両者でU検定を行ったところ,危険率1%でも有意差があることが分かりました. 第1四分位 同時変更が生じたパターンの適用事例ほうが類似度が低い傾向 マン・ホイットニーの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パターンの消滅するという変更が生じました. 1つのクラスだけ処理内容が大きいので,処理の切り替えが難しくなり,変更が生じたと考えられます. このような例は,子クラスのメソッドの処理差異が原因で変更されたと考えられますy またそれが提案したメトリクスで計測可能であったことがいえます. 計測したメトリクスは有効!!! 処理の差異というより,単純に記述してない子クラスがふようなだけなんじゃないの? ⇒処理内容がある程度でかくなると,切り替え自体がむずかしくなり,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検定 ノンパラメトリック検定の1つ 順位和による差異を検定 帰無仮説:2群の代表値に差がない(代表値R1= R2:) 対立仮説:2群の代表値に差がある(代表値R1< R2:片側検定) 特別研究発表会 2009/2/23

仮説2について 仮説2:子クラスの処理内容の規模が大きいほど変更されやすい 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 危険率5%で有意差 特別研究発表会 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