複雑度と機能量に基づくアプリケーションフレームワークの実験的評価 †藤原 晃　†楠本 真二　†井上 克郎　 ‡大坪 稔房　 ‡湯浦 克彦 †大阪大学大学院基礎工学研究科 ‡株式会社日立製作所ビジネスソリューション事業部 大阪大学の藤原です。 本日は「複雑度と機能量に基づくアプリケーションフレームワークの実験的評価」 というタイトルで発表させていただきます。

研究の背景 再利用のひとつとしてフレームワークを用いた手法が注目されている． フレームワーク：アプリケーション開発者がカスタマイズできるアプリケーションの半完成品 開発組織によっては現場独自の再利用の仕組みを確立しており，フレームワークを用いた再利用手法を新たに導入するのは難しい． フレームワークを用いた再利用手法の効果を定量的に示す必要がある． はじめに研究の背景について説明します。 現在ソフトウェアの大規模化と複雑化に伴い、高品質なソフトウェアを一定期間内に効率よく開発することが重要になってきています。そのための1つのアプローチとして再利用があります。とくにオブジェクト指向開発においては、再利用手法のひとつとして、フレームワークを用いた手法が注目されております。フレームワークとはアプリケーション開発者がカスタマイズできるアプリケーションの半完成品です。開発者はアプリケーションに必要な他の部分を作成し、フレームワークと合成してひとつのアプリケーションを完成させることにより開発期間の短縮、品質の向上などの目標を達成します。 しかし、開発組織によっては現場独自の再利用の仕組みを確立しており，フレームワークを用いた再利用手法を新たに導入するのは難しくなっております。 そこで、フレームワークを用いた再利用手法の効果を定量的に示し、フレームワーク導入の動機付けをすることが必要になっています。しかし、われわれの知る限りでは、このようなフレームワークを用いた再利用の効果を定量的に示した例はありません。

研究の目的 フレームワークを用いた再利用手法の効果を定量的に評価する． 工数が削減されるか、品質は向上するか． 対象：特定のアプリケーション開発（地方自治体向け窓口アプリケーション） 開発言語：Java 次に本研究の目的について説明します。 本研究では、フレームワークを用いた再利用手法の効果を定量的に評価します。 比較は、工数が削減されるか、品質は向上するかの2つの視点から行います。 今回はある開発組織で行われる地方自治体向け窓口アプリケーション開発を対象としました。 このアプリケーションを、その組織で従来から用いられている再利用手法とフレームワークを用いた再利用と 2通りの方法で開発し、比較しました。 このアプリケーションはＪＡＶＡで開発されています。

従来の再利用手法 各画面単位で処理プログラムを部品化して再利用する． (a)地方自治体A向けアプリケーション 画面遷移制御部 A11：データ 問い合わせ A12：問い合わせ 結果表示 A13： データの更新 (a)地方自治体A向けアプリケーション (b)地方自治体B向けアプリケーション B1：データベース更新プログラム 画面遷移制御部 次に従来の再利用手法とフレームワークを用いた再利用手法について説明します。 まず従来の再利用手法ですが、従来は各画面単位でプログラムを部品化し、再利用を行っています。 データベースの更新を行うアプリケーションを例に説明します。 図(a)は地方自治体Ａ向けのデータベース更新アプリケーションです。 このアプリケーションは「データ問い合わせ」「問い合わせ結果表示」「データの更新」 の3つの画面で構成されます。 ユーザは「データ問い合わせ」画面でデータの検索条件を入力し、 「問い合わせ結果表示」画面で検索されたデータから更新したいデータを選びます。 そして「データの更新」画面で更新するデータの値を入力し、データベースの更新を行います。 図の四角はプログラムをあらわし、線はプログラムの呼び出しを表します。 各画面にはそれぞれＡ１１、Ａ１２、Ａ１３の各画面処理プログラムが対応します。 Ａ１はデータベース更新プログラムで、全体の処理、制御を行います。 Ａ１の中にある画面遷移制御部はこの3つの画面の遷移を制御しています。 （クリック） 地方自治体Ａ向けアプリケーションを開発したあとに、地方自治体Ｂに対して同様のアプリケーションを開発する場合を考えます。グレーの部分が再利用される部分です。このとき、画面処理プログラムＢ１１、Ｂ１２、Ｂ１３はそれぞれＡ１１、Ａ１２、Ａ１３を一部修正して再利用を行います。従来の再利用手法では、このように1つの画面に１つの画面処理プログラムを作成し、それを部品とすることによって再利用を行っていました。しかしこの手法では画面遷移制御部を改めて作り直す必要があります。 B11：データ 問い合わせ B12：問い合わせ 結果表示 B13： データの更新

フレームワークを用いた再利用手法 画面単位の処理プログラムの部品化に加え，画面遷移単位の処理をフレームワーク化し，再利用する 選択，検索，更新，参照などの処理が持つ画面遷移のタイプごとにフレームワーク化 地方自治体Ｂ固有の パラメータ データベース更新 プログラム　B データベース更新 プログラム　A F1：　フレームワーク これに対し、フレームワークを用いた再利用では、 画面単位の処理プログラムの部品化に加えて画面遷移単位の処理をフレームワーク化して再利用を行います。 選択、検索、更新、参照などの処理が持つ画面遷移のタイプごとにフレームワーク化し、それを部品としてあらかじめ用意しておきます。 先ほどと同様に地方自治体向けのデータベース更新アプリケーションを例に説明します。 更新処理を行うアプリケーションでは、「データ問い合わせ」「問い合わせ結果表示」「データの更新」 という決まった画面遷移のパターンがあります。このパターンがフレームワークとしてあらかじめ用意されています。 このフレームワークを用いて地方自治体Ａ向けのデータベース更新アプリケーションを開発する場合、開発者はフレームワークＦ１に地方自治体Ａ固有のパラメータを渡します。これにより、フレームワークが画面遷移の制御を行います。開発者は全体の制御を行うデータベース更新プログラムＡを作成し、フレームワークと合成し、アプリケーションを完成させます。 （クリック） 地方自治体A向けアプリケーションを開発したあとに地方自治体Ｂ向けアプリケーションを開発する場合、このようにフレームワークに与えるパラメータとデータベース更新プログラムＢを開発するだけでアプリケーションを開発することができます。従来の手法では、画面遷移制御部を作り直していましたが、フレームワークが画面遷移制御を行うため、開発者は画面遷移を行うプログラムを作成する必要がありません。 データベース更新フレームワーク 地方自治体Ａ固有の パラメータ データ 問い合わせ 問い合わせ 結果表示 データの更新

評価方法 従来の再利用手法とフレームワークを利用した場合の再利用とで工数や品質に関する比較を行う． 使用するメトリクス (ケーススタディ1)　類似アプリケーションを複数開発する場合． (ケーススタディ2)　あるアプリケーションに対して機能を順次追加していく場合． 使用するメトリクス 工数：　オブジェクト指向ファンクションポイント（OOFP）→機能量 品質：　ChidamberとKemererのメトリクス（Ｃ‐Ｋメトリクス）→複雑度 計測対象：Javaソースコード 次に2つの再利用手法を評価する方法について説明します。 従来の再利用手法とフレームワークを用いた場合の再利用手法で工数や品質に関する比較を行うため、 ２つのケーススタディを行いました。 ケーススタディ１　類似アプリケーションを複数開発する場合、 ケーススタディ２　あるアプリケーションに対して機能を順次追加していく場合．　です 本来は開発にかかった実際の工数と、発見されたバグ数を計測するべきですが、残念ながら今回はそのデータが 収集できなかったため、メトリクスを用いて比較を行いました。 工数を予測するメトリクスとしてオブジェクト指向ファンクションポイントＯＯＦＰで機能量を計測します。 機能量が高いほど工数が多くなると予想されます。 また、品質を予測するメトリクスとしてChidamberとKemererのメトリクス（Ｃ‐Ｋメトリクス）で複雑度を 計測します。複雑度が高いほど発見されるバグ数が多くなると考えられます。 これらのメトリクスはJavaソースコードを対象に計測します。 次に各メトリクスについて説明します。

機能量（１） 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

OOFP=OOFPILF+OOFPEIF+OOFPSR

機能量（３） OOFPの算出方法（２） JavaソースコードからＯＯＦＰを算出するため、ＯＯＦＰの各概念とJavaの要素を以下のように対応させた。 OOFP Java 論理ファイル ＩＬＦ アプリケーション内部のクラス ＥＩＦ アプリケーション外部のクラス ＤＥＴ クラスの単純な（int型など）属性の数 ＲＥＴ クラスの複雑な（クラス型）属性の数 ＳＲ アプリケーション内部のメソッド DET メソッドの参照する単純な引数、インスタンス変数、クラス変数の数 ＦＴＲ メソッドの参照する複雑な引数、インスタンス変数、クラス変数、オブジェクトへの参照の数

複雑度 ChidamberとKemererのメトリクス オブジェクト指向プログラムの複雑度をあらわす６つのメトリクス. 継承 DIT 継承木の根からそのクラスまでの段数 NOC あるクラスが持つサブクラスの数 結合 RFC あるクラスのメソッド数とそのメソッドの中で呼び出されるメソッド数の和 CBO あるクラスがメソッドの呼び出しを行う相手クラスの数 メソッド WMC クラスあたりの重み付きメソッド数 LCOM あるクラスのメソッドすべての組み合わせのうち，参照する属性に共通するもののない組み合わせのない数から，共通するものがある組み合わせの数を引いたもの

ケーススタディ１ 評価対象 4つの機能 fa, fb, fc, fd の各機能を持つアプリケーション． fa Ca Pa fb Cb Pb ケーススタディ１ 評価対象 4つの機能 fa, fb, fc, fd の各機能を持つアプリケーション． C : フレームワークを用いて開発したアプリケーション P : フレームワークを用いずに開発したアプリケーション 開発方法 フレームワークあり フレームワークなし 機能 fa Ca Pa fb Cb Pb fc Cc Pc fd Cd Pd ケーススタディ１では類似アプリケーションを開発する場合について比較を行います。 4つの機能 fa, fb, fc, fd の各機能を持つアプリケーションをフレームワークを用いて開発する場合と 用いずに開発する場合の2通りで開発します。 フレームワークを用いて開発したアプリケーションをＣ フレームワークを用いずに開発したアプリケーションをＰであらわします。 この表のように、たとえば機能faをもつアプリケーションをフレームワークを用いて開発した場合Ca フレームワークを用いずに開発した場合Paとあらわします。ケーススタディ１ではこの8つのアプリケーションに対してメトリクスを計測します。

ケーススタディ１ 概要 同機能を持つアプリケーションの開発において，フレームワークを用いる場合と用いない場合の機能量と複雑度を比較する． フレームワークあり Ca フレームワークなし Pa 機能 fa FW ケーススタディ１では、同機能を持つアプリケーションの開発において，フレームワークを用いる場合と用いない場合の機能量と複雑度を比較します。たとえば機能faをフレームワークを用いて開発したアプリケーションＣａとフレームワークを用いずに開発したアプリケーションＰａとで機能量と複雑度を計測し、比較します。図でグレーの部分がメトリクスの計測範囲です。フレームワークを用いた場合は、フレームワークＦＷと開発者が作成した部分とを合成して1つのアプリケーションを構成します。フレームワークの部分ＦＷについてはあらかじめ用意されており、アプリケーションの開発者が作成するわけではないので、計測範囲に含まないものとします。 FW：フレームワーク C：フレームワークを用いたアプリケーション P：フレームワークを用いないアプリケーション ・・・計測範囲

ケーススタディ１：計測結果 クラス数 OOFP CBO RFC WMC LCOM Ca Cb Cc Cd 5 11 8 176 180 418 252 3.8 5.8 5.4 4.1 14.4 18.2 33.1 17.8 7.4 7.6 8.1 6.4 21.4 23.2 28.7 13.8 Pa Pb Pc Pd 25 29 28 526 671 672 2.1 2.3 3.0 2.4 5.9 8.6 3.3 3.4 4.3 2.0 15.7 各アプリケーションについて計測範囲のクラス数、ＯＯＦＰ値、ＣＫメトリクス値を表にまとめました。 ここで、ＯＯＦＰは各クラスの合計値です。またＣＫメトリクスの値については各クラスの複雑度の平均値です。 今回計測したアプリケーションでは、クラスの継承がほとんど用いられておらず、継承に関する複雑度を示すＮＯＣとＤＩＴの値はどちらもほとんど0になったため省略しました。 ＝＝＝＝＝＝＝＝＝ ＦＷのクラス数は４７ ＯＯＦＰは1298

ケーススタディ１：OOFP計測結果 176 526 180 418 671 252 672 fa fb fc fd フレームワークあり フレームワークなし 機能 fa 176 526 fb 180 fc 418 671 fd 252 672 全体としてフレームワークを用いている方が機能量が少なくなっている。 とくにfa,fb,fdでみるとフレームワークを用いた方がＯＯＦＰ値は半分以下。 よってフレームワークによって開発する部分が少なくなることで開発工数が削減されることが期待できます。 ※各クラスのＯＯＦＰ値の総和 フレームワークを用いている方が機能量が少ない． 　→フレームワークによって開発工数が削減されている．

ケーススタディ１：複雑度計測結果（１） ＣＢＯの平均 ＲＦＣの平均 フレームワーク あり なし 機能 fa 3.8 2.1 14.4 5.8 fb 2.3 18.2 5.9 fc 5.4 3.0 33.1 7.4 fd 4.1 2.4 17.8 8.6 次にクラス間の結合に関する複雑度を示すＣＢＯとＲＦＣについて比較します。 複雑度はクラスごとに算出されますので、ここではアプリケーション内の1クラスあたりの平均値で比較を行います。 フレームワークを用いた方がＣＢＯではおよそ倍、ＲＦＣでは2倍から3倍くらいになっております。 ＣＫメトリクスの定義から、フレームワークありの方がクラス間のメソッド呼び出しが多く、クラス間の結合の視点から複雑であるといえる。 しかし、フレームワークありのアプリケーションにおいて、ＣＢＯとＲＦＣが高いクラスについてソースコードを調べたところ、呼び出すメソッドはすべてフレームワークに属するクラスのメソッドであることがわかりました。よって、フレームワーク部分の品質が高ければ影響は少ないと考えられます。 ※各クラスのメトリクス値の平均 フレームワークありの方がクラス間のメソッド呼び出しが多い． →呼び出すメソッドはすべてフレームワーク内のクラスのメソッドなので、フレームワーク部分の品質が高ければ影響は少ない．

ケーススタディ１：複雑度計測結果（２） ＷＭＣの平均 ＬＣＯＭの平均 フレームワーク あり なし 機能 fa 7.4 3.3 21.4 2.1 fb 7.6 23.2 fc 8.1 3.4 28.7 2.0 fd 6.4 4.3 13.8 15.7 次にメソッドに関する複雑度を示すＷＭＣとＬＣＯＭについて比較します。 ＷＭＣではフレームワークありの方が倍以上になっております。 またＬＣＯＭは定義からメソッドの組みあわせ数で算出するため、fa,fb,fcではフレームワークありの方が 10倍以上の値になっています。よってメソッドに関してフレームワークありの方が複雑であるといえます。 しかし、フレームワークありのアプリケーションのクラスのうち、ＷＭＣとＬＣＯＭの高いクラスのソースコードを調べたところ、メソッドのほとんどは属性のset,getメソッドでした。 これらのメソッドは単に属性への値の代入と属性への参照をカプセル化するためだけのメソッドで、処理は1行程度であり、複雑度の数字で現れているほどには品質に影響しないと思われます。 ※各クラスのメトリクス値の平均 フレームワークを用いたほうがクラスあたりのメソッド数が多い． →属性のset, get（処理が１行程度のメソッド）がほとんどなので品質にあまり影響しない．

ケーススタディ２ 評価対象 アプリケーションに機能を fa, fb, fc, fd の順に追加していく． fa Ca Pa fa+b ケーススタディ２ 評価対象 アプリケーションに機能を fa, fb, fc, fd の順に追加していく． C : フレームワークを用いて開発したアプリケーション P : フレームワークを用いずに開発したアプリケーション 開発方法 フレームワークあり フレームワークなし 機能 fa Ca Pa fa+b Ca+b Pa+b fa+b+c Ca+b+c Pa+b+c fa+b+c+d Ca+b+c+d Pa+b+c+d 続いてケーススタディ2について説明します。 ケーススタディ2では、fa,fb,fc,fdの順に機能を追加していき、最終的に4つの機能すべてを持った アプリケーションを開発します。ケーススタディ１と同様にフレームワークを用いて開発したアプリケーションをＣ、フレームワークを用いずに開発したアプリケーションをＰとします。また機能faに機能fbに追加したものをfa+bとあらわしています。Ｃａ、Ｐａはケーススタディ１にあったものと同一です。この表にある8つのアプリケーションについて比較を行います。フレームワークなしのアプリケーションの方は、機能追加時に従来の再利用を用いて画面処理に関する部分は再利用しています。

ケーススタディ２ 概要 システムに新たに機能を追加する時の機能量、複雑度の変化をフレームワークを用いる場合と用いない場合で比較する Ca+b ケーススタディ２　概要 システムに新たに機能を追加する時の機能量、複雑度の変化をフレームワークを用いる場合と用いない場合で比較する 機能 fa+b フレームワークあり Ca+b フレームワークなし Pa+b フレームワークあり Ca フレームワークなし Pa FW 機能 fa ケーススタディ２では、システムに新たに機能を追加する時の機能量、複雑度の変化をフレームワークを用いる場合と用いない場合で比較します。 図のグレーの部分が計測範囲です。 ケーススタディ1の時と同様フレームワーク部分はあらかじめ用意されているので計測範囲外とします。 Ｃａ、Ｐａは機能faの機能を持つアプリケーションです。これに機能fbを追加すると （クリック） このようになります。このときのメトリクスの増加量を比較します。 FW：フレームワーク C：フレームワークを用いたアプリケーション P：フレームワークを用いないアプリケーション ・・・計測範囲

ケーススタディ２：計測結果 クラス数 OOFP CBO RFC WMC LCOM Ca Ca+b Ca+b+c Ca+b+c+d 5 7 15 20 176 251 578 743 3.8 5.0 5.9 5.8 14.4 16.7 30.1 28.3 7.4 7.6 8.3 7.9 21.4 20.1 28.6 25.6 Pa Pa+b Pa+b+c Pa+b+c+d 25 29 39 46 526 615 849 1084 2.1 2.8 3.7 4.0 6.9 8.6 10.5 3.3 3.9 2.0 1.8 10.0 各アプリケーションについて計測範囲のクラス数、ＯＯＦＰ値、ＣＫメトリクス値を表にまとめました。 ケーススタディ１と同様、ＯＯＦＰは各クラスの合計値で、ＣＫメトリクスの値は各クラスの平均値です。

ケーススタディ２：OOFP計測結果（１） 176 526 251 615 578 849 743 1084 fa fa+b fa+b+c フレームワークあり フレームワークなし 機能 fa 176 526 fa+b 251 615 fa+b+c 578 849 fa+b+c+d 743 1084 75 327 165 89 234 235 ※各クラスのＯＯＦＰ値の総和 まずＯＯＦＰについて比較します。各アプリケーションのＯＯＦＰはこの表のようになりました。 ここから各機能を追加するときのメトリクス値の増加量を求めます。 （クリック） 四角の中の数字が増加量です。fb,fd追加時にはフレームワークありの方がフレームワークなしよりも増加量が少なくなっています。 しかしfcを追加するときはフレームワークありの方が増加量が多くなっています。実際にフレームワークを用いて開発した開発者に確認したところ、機能ｆｃとフレームワークとの適合性がよくないとのことでした。フレームワークに機能ｆｃにあわせたコンポーネントを追加することが必要と考えられます。 機能 fc を追加する時にフレームワークありのほうがＯＯＦＰ値が高い →機能 fc とフレームワークの適合性がよくない 　　機能 fc の機能にあわせたコンポーネントが必要

ケーススタディ２：OOFP計測結果（２） 176 526 251 615 578 849 743 1084 fa fa+b fa+b+c フレームワークあり フレームワークなし 機能 fa 176 526 fa+b 251 615 fa+b+c 578 849 fa+b+c+d 743 1084 ※各クラスのＯＯＦＰ値の総和 次に4つの機能すべてを追加したアプリケーションを比較します。 フレームワークありでは７４３、なしでは１０８４であり、 フレームワークありの方がＯＯＦＰ値は少なくなっており、全体としてフレームワークを用いたことで 従来の再利用よりも開発工数が削減されることが期待されます。 fa+b+c+d ではフレームワークを用いた方がＯＯＦＰ値が小さい →全体ではフレームワークを用いたことにより開発工数が削減された

ケーススタディ２：複雑度計測結果（１） ＣＢＯ値 ＲＦＣ値 フレームワーク あり なし 機能 fa 3.8 2.1 14.4 5.8 fa+b 5.0 2.8 16.7 6.9 fa+b+c 5.9 3.7 30.1 8.6 fa+b+c+d 4.0 28.3 10.5 2.3 13.4 -1.8 1.1 1.7 1.9 1.2 0.9 -0.1 0.3 次にクラス間の結合の複雑さを示すＣＢＯとＲＦＣについて比較します。 各アプリケーションの複雑度はこの表のようになりました。ここから機能を追加するときの メトリクスの増加量を求めます。 （クリック） ＣＢＯについては変化量にそれほど大きな差は見られませんでした。 ＲＦＣについてはフレームワークありで機能fcを追加したときに増加量が大きくなっています。 実際にソースコードを調べたところ機能ｆｃでは他の機能fa,fb,fdに比べて処理するデータ項目が多くなっています。そのためフレームワーク内のクラスのメソッドを呼び出す回数が多くなっていると考えられます。 ※各クラスのメトリクス値の平均 フレームワークありで機能fcを追加したとき、ＲＦＣ値の増加量が大きい →機能fcは処理するデータ項目が多いため、フレームワーククラスのメソッド呼び出しが多くなっている。

ケーススタディ２：複雑度計測結果（２） ＣＢＯ値 ＲＦＣ値 フレームワーク あり なし 機能 fa 3.8 2.1 14.4 5.8 fa+b 5.0 2.8 16.7 6.9 fa+b+c 5.9 3.7 30.1 8.6 fa+b+c+d 4.0 28.3 10.5 次に4つの機能すべてを追加したアプリケーションで比較をします。 ＣＢＯ、ＲＦＣともにフレームワークありの方が高くなっていることから、クラス間のメソッド呼び出しが多く、クラス間の結合に関して複雑であることがわかります。フレームワークありのアプリケーションのクラスのうち、ＣＢＯとＲＦＣの高い物についてソースコードを調べたところ、呼び出しているメソッドはすべてフレームワークに含まれるクラスのメソッドであることがわかりました。したがってケーススタディ1と同様、フレームワーク部分の品質が高ければアプリケーション全体への影響は少ないと考えられます。 ※各クラスのメトリクス値の平均 fa+b+c+dではフレームワークありの方がメソッド呼び出しが多い →呼び出しているメソッドはすべてフレームワークに含まれるクラスのメソッドなので、フレームワーク部分の品質が高ければ影響は少ない．

ケーススタディ２：複雑度計測結果（３） ＷＭＣ値 ＬＣＯＭ値 フレームワークあり フレームワークなし フレームワーク あり なし 機能 fa 7.4 3.3 21.4 2.1 fa+b 7.6 20.1 2.0 fa+b+c 8.3 28.6 1.8 fa+b+c+d 7.9 3.9 25.6 10.0 -1.3 8.5 -3.0 -0.1 -0.2 8.2 0.2 0.7 -0.4 0.0 0.6 次にメソッドの複雑さを示すＷＭＣとＬＣＯＭについて比較します。 各アプリケーションの複雑度はこの表のようになりました。ここから機能を追加するときの メトリクスの増加量を求めます。 （クリック） ＬＣＯＭはクラス内のメソッドのすべての組み合わせから算出するため、値の変動が大きくなっています。 フレームワークありのアプリケーションで機能fcを追加する場合にＬＣＯＭの増加量が増加量が大きくなっています。 機能fcでは処理するデータ項目が多いため、機能fcを追加するときに追加されたクラスではset,getメソッドが多くなっていました。 ※各クラスのメトリクス値の平均 フレームワークありで機能ｆｃを追加するときにＬＣＯＭ値の増加量が多い →処理するデータ項目が多いため、属性のset,getメソッドが多い

ケーススタディ２：複雑度計測結果（４） ＷＭＣ値 ＬＣＯＭ値 フレームワークあり フレームワークなし フレームワーク あり なし 機能 fa 7.4 3.3 21.4 2.1 fa+b 7.6 20.1 2.0 fa+b+c 8.3 28.6 1.8 fa+b+c+d 7.9 3.9 25.6 10.0 -1.3 8.5 -3.0 -0.1 -0.2 8.2 0.2 0.7 -0.4 0.0 0.6 またフレームワークなしで機能fdを追加するときにＬＣＯＭ値の増加量が多くなっています。 機能fdを追加するときにフレームワークなしで作成されたクラスのソースコードを調べると、複雑な画面処理を行うクラスが存在し、そのクラスでＬＣＯＭが 非常に高くなっていることがわかりました。フレームワークありの場合、このような画面処理はフレームワーク内で行うため、ＬＣＯＭが増加しませんでした。 ※各クラスのメトリクス値の平均 フレームワークなしで機能fdを追加するときにＬＣＯＭ値の増加量が多い →機能fdでは複雑な画面処理があり、その処理を行うクラスでＬＣＯＭが高かった.　フレームワークありの場合、この画面処理はフレームワークが行っている。

ケーススタディ２：複雑度計測結果（５） ＷＭＣ値 ＬＣＯＭ値 フレームワークあり フレームワークなし フレームワーク あり なし 機能 fa 7.4 3.3 21.4 2.1 fa+b 7.6 20.1 2.0 fa+b+c 8.3 28.6 1.8 fa+b+c+d 7.9 3.9 25.6 10.0 次に4つの機能すべてを追加したアプリケーションで比較をします。 ＷＭＣ、ＬＣＯＭともにフレームワークを用いた方が値が高くなっており、メソッド数が多く、クラスのメソッドの視点から複雑であるといえます。 フレームワークありのアプリケーションのクラスのうち、メトリクス値の高いクラスのソースコードを調べたところ、 ほとんどがset,getメソッドでした。set,getメソッドは単純であるため、品質にはあまり影響しないと思われます。 ※各クラスのメトリクス値の平均 fa+b+c+dではフレームワークを用いたほうがクラスあたりのメソッド数が多い． →属性のset, get（処理が１行程度のメソッド）がほとんどなので品質にあまり影響しない．

まとめ 主な結果 今後の課題 ChidamberとKemererのメトリクス，OOFPを用いてフレームワークの効果を評価する手法を検討した． 実際のアプリケーションを対象にOOFPとC-Kメトリクスを用いて機能量と複雑さの計測と評価を行った． 全体的にフレームワークを用いた方が機能量が少なく、複雑度が高くなる フレームワーク部分の品質が高ければアプリケーション全体の品質には影響が少ないと考えられる 今後の課題 計測結果の妥当性の評価． ファンクションポイントを用いた機能量の計測． 他のアプリケーションからもメトリクスを計測する。 今回はソースから自動的に計測できるＯＯＦＰで計測したが、 ＦＰ法での機能量を計測する