複雑度と機能量に基づくアプリケーション フレームワークの実験的評価 † 藤原 晃 †楠本 真二 †井上 克郎 ‡ 大坪 稔房 ‡湯浦 克彦 † 大阪大学大学院基礎工学研究科 ‡ 株式会社日立製作所ビジネスソリューション事業部 Software Engineering Research Group, Graduate School of Engineering Science, Osaka University 研究の背景 • 再利用のひとつとしてフレームワークを用いた手法が注目されて いる． – フレームワーク：アプリケーション開発者がカスタマイズできるアプリケーションの半完 成品 • 開発組織によっては現場独自の再利用の仕組みを確立してお り，フレームワークを用いた再利用手法を新たに導入するのは 難しい． • フレームワークを用いた再利用手法の効果を定量的に示す必 要がある． Software Engineering Research Group, Graduate School of Engineering Science, Osaka University 研究の目的 • フレームワークを用いた再利用手法の効果を定量的に評価する． – 工数が削減されるか、品質は向上するか． • 対象：特定のアプリケーション開発（地方自治体向け窓口アプリケー ション） – 開発言語：Java Software Engineering Research Group, Graduate School of Engineering Science, Osaka University 従来の再利用手法 • 各画面単位で処理プログラムを部品化して再利用する． A1：データベース更新プログラム 画面遷移制御部 A11：データ 問い合わせ A12：問い合わせ 結果表示 A13： データの更新 (a)地方自治体A向けアプリケーション B1：データベース更新プログラム 画面遷移制御部 B11：データ 問い合わせ B12：問い合わせ 結果表示 B13： データの更新 (b)地方自治体B向けアプリケーション Software Engineering Research Group, Graduate School of Engineering Science, Osaka University フレームワークを用いた再利用手法 • 画面単位の処理プログラムの部品化に加え，画面遷 移単位の処理をフレームワーク化し，再利用する – 選択，検索，更新，参照などの処理が持つ画面遷移のタイプごとにフレーム ワーク化 データベース更新 プログラム B A F1： フレームワーク データベース更新フレームワーク 地方自治体Ｂ固有の 地方自治体Ａ固有の パラメータ データ 問い合わせ 問い合わせ 結果表示 データの更新 Software Engineering Research Group, Graduate School of Engineering Science, Osaka University 評価方法 • 従来の再利用手法とフレームワークを利用した場合の再 利用とで工数や品質に関する比較を行う． (ケーススタディ1) 類似アプリケーションを複数開発する場合． (ケーススタディ2) あるアプリケーションに対して機能を順次追加していく場合． • 使用するメトリクス – 工数： オブジェクト指向ファンクションポイント（OOFP）→機能量 – 品質： ChidamberとKemererのメトリクス（Ｃ‐Ｋメトリクス）→複雑度 • 計測対象：Javaソースコード Software Engineering Research Group, Graduate School of Engineering Science, Osaka University 機能量（１） OOFP（Object Oriented Function Points§) • ファンクションポイント（ＦＰ）法に基づいて，オブジェクト 指向ソフトウェアの開発プロジェクトのサイズを見積る 手法． – ＦＰ法では論理ファイル（内部論理ファイル：ＩＬＦ、外部イン ターフェイスファイル：ＥＩＦ）とトランザクション（外部入力：ＥＩ、 外部出力：ＥＯ、外部照会：ＥＱ）から計測 – ＯＯＦＰでは論理ファイル（ＩＬＦ、ＥＩＦ）とトランザクション （Service Request: SR）から計測する． • 論理ファイル → クラス • トランザクション（ＳＲ） → メソッド §:G.Caldiera, G.Antoniol, R.Fiutem, C.Lokan, “Definition and Experimental Evaluation of Function Points for Object-Oriented Systems”, IEEE, 1998 Software Engineering Research Group, Graduate School of Engineering Science, Osaka University 機能量（２） OOFPの算出方法（１） OOFP=OOFPILF+OOFPEIF+OOFPSR • 各内部論理ファイル（ＩＬＦ）について、データ項目数（ＤＥＴ）とレコード 種類数（ＲＥＴ）からOOFPILFを算出． • 各外部インターフェイスファイル（ＥＩＦ）について、データ項目数（ＤＥＴ） とレコード種類数（ＲＥＴ）からOOFPEIFを算出． • 各トランザクション（ＳＲ）について、データ項目数（ＤＥＴ）と関連ファイ ル数（ＦＴＲ）からOOFPSRを算出． • 合計し、アプリケーションのOOFPを算出． Software Engineering Research Group, Graduate School of Engineering Science, Osaka University 機能量（３） OOFPの算出方法（２） • JavaソースコードからＯＯＦＰを算出するため、ＯＯＦＰの各概念と Javaの要素を以下のように対応させた。 OOFP 論理ファイル Java ＩＬＦ アプリケーション内部のクラス ＥＩＦ アプリケーション外部のクラス ＤＥＴ クラスの単純な（int型など）属性の数 ＲＥＴ クラスの複雑な（クラス型）属性の数 ＳＲ ＳＲ アプリケーション内部のメソッド DET メソッドの参照する単純な引数、インスタンス変 数、クラス変数の数 ＦＴＲ メソッドの参照する複雑な引数、インスタンス変 数、クラス変数、オブジェクトへの参照の数 Software Engineering Research Group, Graduate School of Engineering Science, Osaka University 複雑度 ChidamberとKemererのメトリクス • オブジェクト指向プログラムの複雑度をあらわす６つのメトリクス. 継承 結合 メソッド DIT 継承木の根からそのクラスまでの段数 NOC あるクラスが持つサブクラスの数 RFC あるクラスのメソッド数とそのメソッドの中で呼び出 されるメソッド数の和 CBO あるクラスがメソッドの呼び出しを行う相手クラスの 数 WMC クラスあたりの重み付きメソッド数 LCOM あるクラスのメソッドすべての組み合わせのうち，参 照する属性に共通するもののない組み合わせのな い数から，共通するものがある組み合わせの数を 引いたもの Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ケーススタディ１ 評価対象 • 4つの機能 fa, fb, fc, fd の各機能を持つアプリケーション． – C : フレームワークを用いて開発したアプリケーション – P : フレームワークを用いずに開発したアプリケーション 開発方法 フレームワークあり フレームワークなし fa 機 fb 能 f c Ca Cb Cc Pa Pb Pc fd Cd Pd Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ケーススタディ１ 概要 • 同機能を持つアプリケーションの開発において，フレーム ワークを用いる場合と用いない場合の機能量と複雑度 を比較する． 機能 fa フレームワークあり フレームワークなし Ca Pa FW FW：フレームワーク C：フレームワークを用いたアプリケーション P：フレームワークを用いないアプリケーション Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ・・・計測範囲 ケーススタディ１：計測結果 Ca Cb Cc Cd Pa Pb Pc Pd クラス数 5 5 11 8 25 25 29 28 OOFP CBO RFC WMC LCOM 176 3.8 14.4 7.4 21.4 180 5.8 18.2 7.6 23.2 418 5.4 33.1 8.1 28.7 252 4.1 17.8 6.4 13.8 526 2.1 5.8 3.3 2.1 526 2.3 5.9 3.3 2.1 671 3.0 7.4 3.4 2.0 672 2.4 8.6 4.3 15.7 Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ケーススタディ１：OOFP計測結果 フレームワークあり フレームワークなし fa 176 526 f 180 526 418 671 252 672 機 b 能 f c fd ※各クラスのＯＯＦＰ値の総和 フレームワークを用いている方が機能量が少ない． →フレームワークによって開発工数が削減されている． Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ケーススタディ１：複雑度計測結果（１） ＣＢＯの平均 ＲＦＣの平均 フレームワーク フレームワーク フレームワーク フレームワーク あり なし あり なし fa 3.8 2.1 14.4 5.8 fb 5.8 2.3 18.2 5.9 5.4 3.0 33.1 7.4 4.1 2.4 17.8 8.6 機 能 f c fd ※各クラスのメトリクス値の平均 フレームワークありの方がクラス間のメソッド呼び出しが多い． →呼び出すメソッドはすべてフレームワーク内のクラスのメソッドな ので、フレームワーク部分の品質が高ければ影響は少ない． Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ケーススタディ１：複雑度計測結果（２） ＷＭＣの平均 ＬＣＯＭの平均 フレームワーク フレームワーク フレームワーク フレームワーク あり なし あり なし fa 7.4 3.3 21.4 2.1 fb 7.6 3.3 23.2 2.1 8.1 3.4 28.7 2.0 6.4 4.3 13.8 15.7 機 能 f c fd ※各クラスのメトリクス値の平均 フレームワークを用いたほうがクラスあたりのメソッド数が多い． →属性のset, get（処理が１行程度のメソッド）がほとんどなので品質にあ まり影響しない． Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ケーススタディ２ 評価対象 • アプリケーションに機能を fa, fb, fc, fd の順に追加していく． – C : フレームワークを用いて開発したアプリケーション – P : フレームワークを用いずに開発したアプリケーション 開発方法 フレームワークあり フレームワークなし 機 能 fa Ca Pa fa+b fa+b+c Ca+b Ca+b+c Pa+b Pa+b+c fa+b+c+d Ca+b+c+d Pa+b+c+d Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ケーススタディ２ 概要 • システムに新たに機能を追加する時の機能量、複雑度の 変化をフレームワークを用いる場合と用いない場合で比較 する 機能 fa+b a フレームワークあり フレームワークなし フレームワークなし CCa+b a PPa+b a FW FW：フレームワーク C：フレームワークを用いたアプリケーション P：フレームワークを用いないアプリケーション Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ・・・計測範囲 ケーススタディ２：計測結果 クラス数 Ca Ca+b Ca+b+c Ca+b+c+d Pa Pa+b Pa+b+c Pa+b+c+d 5 7 15 20 25 29 39 46 OOFP 176 251 578 743 526 615 849 1084 CBO 3.8 5.0 5.9 5.8 2.1 2.8 3.7 4.0 RFC 14.4 16.7 30.1 28.3 5.8 6.9 8.6 10.5 Software Engineering Research Group, Graduate School of Engineering Science, Osaka University WMC 7.4 7.6 8.3 7.9 3.3 3.3 3.3 3.9 LCOM 21.4 20.1 28.6 25.6 2.1 2.0 1.8 10.0 ケーススタディ２：OOFP計測結果（１） フレームワークあり フレームワークなし fa 機 能 fa+b fa+b+c fa+b+c+d 75 327 165 176 251 89 234 578 235 743 526 615 849 1084 ※各クラスのＯＯＦＰ値の総和 機能 fc を追加する時にフレームワークありのほうがＯＯＦＰ値が高い →機能 fc とフレームワークの適合性がよくない 機能 fc の機能にあわせたコンポーネントが必要 Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ケーススタディ２：OOFP計測結果（２） フレームワークあり フレームワークなし fa 機 能 fa+b fa+b+c fa+b+c+d 176 251 526 615 578 743 849 1084 ※各クラスのＯＯＦＰ値の総和 fa+b+c+d ではフレームワークを用いた方がＯＯＦＰ値が小さい →全体ではフレームワークを用いたことにより開発工数が削減された Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ケーススタディ２：複雑度計測結果（１） ＣＢＯ値 ＲＦＣ値 フレームワーク フレームワーク フレームワーク フレームワーク あり なし あり なし fa f 機 a+b 能 f a+b+c fa+b+c+d 3.8 1.2 0.9 5.0 0.9 0.9 5.9 -0.1 0.3 5.8 2.1 2.3 2.8 13.4 3.7 4.0-1.8 14.4 5.8 1.1 16.7 6.9 1.7 30.1 8.6 28.3 1.9 10.5 ※各クラスのメトリクス値の平均 フレームワークありで機能fcを追加したとき、ＲＦＣ値の増加量が大きい →機能fcは処理するデータ項目が多いため、フレームワーククラスのメソッド呼 び出しが多くなっている。 Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ケーススタディ２：複雑度計測結果（２） ＣＢＯ値 ＲＦＣ値 フレームワーク フレームワーク フレームワーク フレームワーク あり なし あり なし fa f 機 a+b 能 f a+b+c fa+b+c+d 3.8 5.0 5.9 5.8 2.1 2.8 3.7 4.0 14.4 16.7 30.1 28.3 5.8 6.9 8.6 10.5 ※各クラスのメトリクス値の平均 fa+b+c+dではフレームワークありの方がメソッド呼び出しが多い →呼び出しているメソッドはすべてフレームワークに含まれるクラスのメ ソッドなので、フレームワーク部分の品質が高ければ影響は少ない． Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ケーススタディ２：複雑度計測結果（３） ＷＭＣ値 ＬＣＯＭ値 フレームワーク フレームワーク フレームワーク フレームワーク あり なし あり なし fa 0.2 f 機 a+b 能 f a+b+c 0.7 fa+b+c+d -0.4 7.4 0.0 7.6 0.0 8.3 7.9 0.6 3.3 -1.3 3.3 8.5 3.3 -3.0 3.9 21.4 -0.1 2.1 20.1 2.0 -0.2 28.6 1.8 8.2 25.6 10.0 ※各クラスのメトリクス値の平均 フレームワークありで機能ｆｃを追加するときにＬＣＯＭ値の増加量が多い →処理するデータ項目が多いため、属性のset,getメソッドが多い Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ケーススタディ２：複雑度計測結果（４） ＷＭＣ値 ＬＣＯＭ値 フレームワーク フレームワーク フレームワーク フレームワーク あり なし あり なし fa 0.2 f 機 a+b 能 f a+b+c 0.7 fa+b+c+d -0.4 7.4 0.0 7.6 0.0 8.3 7.9 0.6 3.3 -1.3 3.3 8.5 3.3 -3.0 3.9 21.4 -0.1 2.1 20.1 2.0 -0.2 28.6 1.8 8.2 25.6 10.0 ※各クラスのメトリクス値の平均 フレームワークなしで機能fdを追加するときにＬＣＯＭ値の増加量が多い →機能fdでは複雑な画面処理があり、その処理を行うクラスでＬＣＯＭが 高かった. フレームワークありの場合、この画面処理はフレームワークが 行っている。 Software Engineering Research Group, Graduate School of Engineering Science, Osaka University ケーススタディ２：複雑度計測結果（５） ＷＭＣ値 ＬＣＯＭ値 フレームワーク フレームワーク フレームワーク フレームワーク あり なし あり なし fa f 機 a+b 能 f a+b+c fa+b+c+d 7.4 7.6 8.3 7.9 3.3 3.3 3.3 3.9 21.4 20.1 28.6 25.6 2.1 2.0 1.8 10.0 ※各クラスのメトリクス値の平均 fa+b+c+dではフレームワークを用いたほうがクラスあたりのメソッド数が多い． →属性のset, get（処理が１行程度のメソッド）がほとんどなので品質にあ まり影響しない． Software Engineering Research Group, Graduate School of Engineering Science, Osaka University まとめ • 主な結果 – ChidamberとKemererのメトリクス，OOFPを用いてフレームワークの効果 を評価する手法を検討した． – 実際のアプリケーションを対象にOOFPとC-Kメトリクスを用いて機能量と複 雑さの計測と評価を行った． – 全体的にフレームワークを用いた方が機能量が少なく、複雑度が高くなる – フレームワーク部分の品質が高ければアプリケーション全体の品質には影響 が少ないと考えられる • 今後の課題 – 計測結果の妥当性の評価． – ファンクションポイントを用いた機能量の計測． Software Engineering Research Group, Graduate School of Engineering Science, Osaka University
© Copyright 2024 ExpyDoc
