複雑度と機能量に基づくアプリケーションフレームワークの実験的評価

Slides:



Advertisements
Similar presentations
背景 ソフトウェアの大規模化・複雑化 生産性と品質の向上 ↓ オブジェクト指向分析設計の適用 開発ツールの投入.
Advertisements

利用実績に基づくソフトウェア部品検索システムSPARS-J
情報伝播によるオブジェクト指向プログラム理解支援の提案
アクセス修飾子過剰性の変遷に着目したJavaプログラム部品の分析
オブジェクト指向プログラミング(2) OOPの三大要素 「クラス」「ポリモーフィズム」「継承」
フレームワークを用いた 情報システムの継続的開発に関する研究
入出力データ型に透過な Webサービス動的実行システム 松江工業高等専門学校 情報工学科 越田高志 情報処理学会第68回全国大会
CKメトリクスを用いてリファクタリングの 効果を予測する手法の提案
プログラム実行履歴を用いたトランザクションファンクション抽出手法
プログラム実行時情報を用いたトランザクションファンクション抽出手法
ソースコードの変更履歴における メトリクス値の変化を用いた ソフトウェアの特性分析
静的情報と動的情報を用いた プログラムスライス計算法
オブジェクト指向 プログラミング 第十四回 知能情報学部 新田直也.
オブジェクト指向プログラムのための 動的結合メトリクスの評価
Javaクラスの利用関係を用いた ソフトウェア部品のカテゴリ階層構築法
コードクローンに含まれるメソッド呼び出しの 変更度合の分析
コードクローンに含まれるメソッド呼び出しの 変更度合の調査
オブジェクト指向 プログラミング 第十一回 知能情報学部 新田直也.
Javaソースコード蓄積・ 検索システムSPARS-Jの概要
動的依存グラフの3-gramを用いた 実行トレースの比較手法
ソフトウェア工学 知能情報学部 新田直也.
オブジェクト指向プログラムにおける エイリアス解析手法の提案と実現
動的情報を利用したソフトウェア 部品評価手法
シーケンス図を用いて実行履歴を可視化するデバッグ環境の試作
オブジェクト指向 プログラミング 第十四回 知能情報学部 新田直也.
CKメトリクスに基づくリファクタリングの 効果予測手法の提案と実装
ソフトウェアを取り巻く環境の変化がメトリクスに及ぼす影響について
利用関係に基づく類似度を用いたJavaコンポーネント分類ツールの作成
クローンセットに対する主要編集者の分析法の提案と調査
実行時情報に基づく OSカーネルのコンフィグ最小化
利用実績に基づくソフトウェア部品検索システムSPARS-J
コンポーネントランク法を用いたJavaクラス分類手法の提案
ソースコードの特徴量を用いた機械学習による メソッド抽出リファクタリング推薦手法
コードクローンの動作を比較するためのコードクローン周辺コードの解析
ソースコードの静的特性を用いた Javaプログラム間類似度測定ツールの試作
コードクローン検出に基づくデザイン パターン適用支援手法の提案と実現
Parallel Setsによるライブラリの 組み合わせと利用状況の可視化
プログラム理解におけるThin sliceの 統計的調査による有用性評価
バイトコードを単位とするJavaスライスシステムの試作
Javaソフトウェア部品検索システムSPARS-Jの実験的評価
シナリオを用いたレビュー手法PBRの追証実験 - UMLで記述された設計仕様書を対象として -
コンパイラ 2011年10月20日
コードクローン分類の詳細化に基づく 集約パターンの提案と評価
P2P ネットワーク上で 実時間ストリーミングを実現するための 分散制御プロトコルの提案
コーディングパターンの あいまい検索の提案と実装
コードクローン間の依存関係に基づく リファクタリング支援環境の実装
オブジェクトの協調動作を用いた オブジェクト指向プログラム実行履歴分割手法
ソフトウェア工学 知能情報学部 新田直也.
構造的類似性を持つ半構造化文書における頻度分析
設計情報の再利用を目的とした UML図の自動推薦ツール
保守請負時を対象とした 労力見積のためのメトリクスの提案
クローン検出ツールを用いた ソフトウェアシステムの類似度調査
オープンソースソフトウェアに対する コーディングパターン分析の適用
メソッドの同時更新履歴を用いたクラスの機能別分類法
クラスタリングを用いた ベイズ学習モデルを動的に更新する ソフトウェア障害検知手法
ソースコードの編集状況に応じた ソフトウェア部品の自動推薦システム
使用する CSS・JavaScrpitも指定
JAVAを対象とした 動的複雑度メトリクスの実験的評価
ソフトウェア理解支援を目的とした 辞書の作成法
オブジェクト指向開発における フォールト発生早期予測手法の 一提案
エイリアス関係を考慮した Javaプログラム用静的スライシングツール
複雑度メトリクスを用いた JAVAプログラム品質特性の実験的評価
ソフトウェア工学 知能情報学部 新田直也.
コードクローン解析に基づく デザインパターン適用候補の検出手法
オブジェクト指向言語における セキュリティ解析アルゴリズムの提案と実現
オブジェクト指向メトリクスを用いた 開発支援に関する研究 --- VC++とMFCを用いた開発を対象として ---
ベイジアンネットワークと クラスタリング手法を用いたWeb障害検知システムの開発
プログラム理解のための 付加注釈 DocumentTag の提案
オブジェクト指向言語論 第六回 知能情報学部 新田直也.
Presentation transcript:

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

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

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

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

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

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

機能量(1) OOFP(Object Oriented Function Points§) ファンクションポイント(FP)法に基づいて,オブジェクト指向ソフトウェアの開発プロジェクトのサイズを見積る手法. FP法では論理ファイル(内部論理ファイル:ILF、外部インターフェイスファイル:EIF)とトランザクション(外部入力:EI、外部出力:EO、外部照会:EQ)から計測 OOFPでは論理ファイル(ILF、EIF)とトランザクション(Service Request: SR)から計測する. 論理ファイル → クラス トランザクション(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

機能量(3) OOFPの算出方法(2) JavaソースコードからOOFPを算出するため、OOFPの各概念とJavaの要素を以下のように対応させた。 OOFP Java 論理ファイル ILF アプリケーション内部のクラス EIF アプリケーション外部のクラス DET クラスの単純な(int型など)属性の数 RET クラスの複雑な(クラス型)属性の数 SR アプリケーション内部のメソッド DET メソッドの参照する単純な引数、インスタンス変数、クラス変数の数 FTR メソッドの参照する複雑な引数、インスタンス変数、クラス変数、オブジェクトへの参照の数

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

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

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

ケーススタディ1:計測結果 クラス数 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 各アプリケーションについて計測範囲のクラス数、OOFP値、CKメトリクス値を表にまとめました。 ここで、OOFPは各クラスの合計値です。またCKメトリクスの値については各クラスの複雑度の平均値です。 今回計測したアプリケーションでは、クラスの継承がほとんど用いられておらず、継承に関する複雑度を示すNOCとDITの値はどちらもほとんど0になったため省略しました。 ========= FWのクラス数は47 OOFPは1298

ケーススタディ1: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でみるとフレームワークを用いた方がOOFP値は半分以下。 よってフレームワークによって開発する部分が少なくなることで開発工数が削減されることが期待できます。 ※各クラスのOOFP値の総和 フレームワークを用いている方が機能量が少ない.  →フレームワークによって開発工数が削減されている.

ケーススタディ1:複雑度計測結果(1) CBOの平均 RFCの平均 フレームワーク あり なし 機能 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 次にクラス間の結合に関する複雑度を示すCBOとRFCについて比較します。 複雑度はクラスごとに算出されますので、ここではアプリケーション内の1クラスあたりの平均値で比較を行います。 フレームワークを用いた方がCBOではおよそ倍、RFCでは2倍から3倍くらいになっております。 CKメトリクスの定義から、フレームワークありの方がクラス間のメソッド呼び出しが多く、クラス間の結合の視点から複雑であるといえる。 しかし、フレームワークありのアプリケーションにおいて、CBOとRFCが高いクラスについてソースコードを調べたところ、呼び出すメソッドはすべてフレームワークに属するクラスのメソッドであることがわかりました。よって、フレームワーク部分の品質が高ければ影響は少ないと考えられます。 ※各クラスのメトリクス値の平均 フレームワークありの方がクラス間のメソッド呼び出しが多い. →呼び出すメソッドはすべてフレームワーク内のクラスのメソッドなので、フレームワーク部分の品質が高ければ影響は少ない.

ケーススタディ1:複雑度計測結果(2) WMCの平均 LCOMの平均 フレームワーク あり なし 機能 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 次にメソッドに関する複雑度を示すWMCとLCOMについて比較します。 WMCではフレームワークありの方が倍以上になっております。 またLCOMは定義からメソッドの組みあわせ数で算出するため、fa,fb,fcではフレームワークありの方が 10倍以上の値になっています。よってメソッドに関してフレームワークありの方が複雑であるといえます。 しかし、フレームワークありのアプリケーションのクラスのうち、WMCとLCOMの高いクラスのソースコードを調べたところ、メソッドのほとんどは属性のset,getメソッドでした。 これらのメソッドは単に属性への値の代入と属性への参照をカプセル化するためだけのメソッドで、処理は1行程度であり、複雑度の数字で現れているほどには品質に影響しないと思われます。 ※各クラスのメトリクス値の平均 フレームワークを用いたほうがクラスあたりのメソッド数が多い. →属性のset, get(処理が1行程度のメソッド)がほとんどなので品質にあまり影響しない.

ケーススタディ2 評価対象 アプリケーションに機能を fa, fb, fc, fd の順に追加していく. fa Ca Pa fa+b ケーススタディ2 評価対象 アプリケーションに機能を 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つの機能すべてを持った アプリケーションを開発します。ケーススタディ1と同様にフレームワークを用いて開発したアプリケーションをC、フレームワークを用いずに開発したアプリケーションをPとします。また機能faに機能fbに追加したものをfa+bとあらわしています。Ca、Paはケーススタディ1にあったものと同一です。この表にある8つのアプリケーションについて比較を行います。フレームワークなしのアプリケーションの方は、機能追加時に従来の再利用を用いて画面処理に関する部分は再利用しています。

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

ケーススタディ2:計測結果 クラス数 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値、CKメトリクス値を表にまとめました。 ケーススタディ1と同様、OOFPは各クラスの合計値で、CKメトリクスの値は各クラスの平均値です。

ケーススタディ2:OOFP計測結果(1) 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 ※各クラスのOOFP値の総和 まずOOFPについて比較します。各アプリケーションのOOFPはこの表のようになりました。 ここから各機能を追加するときのメトリクス値の増加量を求めます。 (クリック) 四角の中の数字が増加量です。fb,fd追加時にはフレームワークありの方がフレームワークなしよりも増加量が少なくなっています。 しかしfcを追加するときはフレームワークありの方が増加量が多くなっています。実際にフレームワークを用いて開発した開発者に確認したところ、機能fcとフレームワークとの適合性がよくないとのことでした。フレームワークに機能fcにあわせたコンポーネントを追加することが必要と考えられます。 機能 fc を追加する時にフレームワークありのほうがOOFP値が高い →機能 fc とフレームワークの適合性がよくない   機能 fc の機能にあわせたコンポーネントが必要

ケーススタディ2:OOFP計測結果(2) 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 ※各クラスのOOFP値の総和 次に4つの機能すべてを追加したアプリケーションを比較します。 フレームワークありでは743、なしでは1084であり、 フレームワークありの方がOOFP値は少なくなっており、全体としてフレームワークを用いたことで 従来の再利用よりも開発工数が削減されることが期待されます。 fa+b+c+d ではフレームワークを用いた方がOOFP値が小さい →全体ではフレームワークを用いたことにより開発工数が削減された

ケーススタディ2:複雑度計測結果(1) CBO値 RFC値 フレームワーク あり なし 機能 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 次にクラス間の結合の複雑さを示すCBOとRFCについて比較します。 各アプリケーションの複雑度はこの表のようになりました。ここから機能を追加するときの メトリクスの増加量を求めます。 (クリック) CBOについては変化量にそれほど大きな差は見られませんでした。 RFCについてはフレームワークありで機能fcを追加したときに増加量が大きくなっています。 実際にソースコードを調べたところ機能fcでは他の機能fa,fb,fdに比べて処理するデータ項目が多くなっています。そのためフレームワーク内のクラスのメソッドを呼び出す回数が多くなっていると考えられます。 ※各クラスのメトリクス値の平均 フレームワークありで機能fcを追加したとき、RFC値の増加量が大きい →機能fcは処理するデータ項目が多いため、フレームワーククラスのメソッド呼び出しが多くなっている。

ケーススタディ2:複雑度計測結果(2) CBO値 RFC値 フレームワーク あり なし 機能 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つの機能すべてを追加したアプリケーションで比較をします。 CBO、RFCともにフレームワークありの方が高くなっていることから、クラス間のメソッド呼び出しが多く、クラス間の結合に関して複雑であることがわかります。フレームワークありのアプリケーションのクラスのうち、CBOとRFCの高い物についてソースコードを調べたところ、呼び出しているメソッドはすべてフレームワークに含まれるクラスのメソッドであることがわかりました。したがってケーススタディ1と同様、フレームワーク部分の品質が高ければアプリケーション全体への影響は少ないと考えられます。 ※各クラスのメトリクス値の平均 fa+b+c+dではフレームワークありの方がメソッド呼び出しが多い →呼び出しているメソッドはすべてフレームワークに含まれるクラスのメソッドなので、フレームワーク部分の品質が高ければ影響は少ない.

ケーススタディ2:複雑度計測結果(3) WMC値 LCOM値 フレームワークあり フレームワークなし フレームワーク あり なし 機能 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 次にメソッドの複雑さを示すWMCとLCOMについて比較します。 各アプリケーションの複雑度はこの表のようになりました。ここから機能を追加するときの メトリクスの増加量を求めます。 (クリック) LCOMはクラス内のメソッドのすべての組み合わせから算出するため、値の変動が大きくなっています。 フレームワークありのアプリケーションで機能fcを追加する場合にLCOMの増加量が増加量が大きくなっています。 機能fcでは処理するデータ項目が多いため、機能fcを追加するときに追加されたクラスではset,getメソッドが多くなっていました。 ※各クラスのメトリクス値の平均 フレームワークありで機能fcを追加するときにLCOM値の増加量が多い →処理するデータ項目が多いため、属性のset,getメソッドが多い

ケーススタディ2:複雑度計測結果(4) WMC値 LCOM値 フレームワークあり フレームワークなし フレームワーク あり なし 機能 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を追加するときにLCOM値の増加量が多くなっています。 機能fdを追加するときにフレームワークなしで作成されたクラスのソースコードを調べると、複雑な画面処理を行うクラスが存在し、そのクラスでLCOMが 非常に高くなっていることがわかりました。フレームワークありの場合、このような画面処理はフレームワーク内で行うため、LCOMが増加しませんでした。 ※各クラスのメトリクス値の平均 フレームワークなしで機能fdを追加するときにLCOM値の増加量が多い →機能fdでは複雑な画面処理があり、その処理を行うクラスでLCOMが高かった. フレームワークありの場合、この画面処理はフレームワークが行っている。

ケーススタディ2:複雑度計測結果(5) WMC値 LCOM値 フレームワークあり フレームワークなし フレームワーク あり なし 機能 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つの機能すべてを追加したアプリケーションで比較をします。 WMC、LCOMともにフレームワークを用いた方が値が高くなっており、メソッド数が多く、クラスのメソッドの視点から複雑であるといえます。 フレームワークありのアプリケーションのクラスのうち、メトリクス値の高いクラスのソースコードを調べたところ、 ほとんどがset,getメソッドでした。set,getメソッドは単純であるため、品質にはあまり影響しないと思われます。 ※各クラスのメトリクス値の平均 fa+b+c+dではフレームワークを用いたほうがクラスあたりのメソッド数が多い. →属性のset, get(処理が1行程度のメソッド)がほとんどなので品質にあまり影響しない.

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