1 / 27

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

複雑度と機能量に基づくアプリケーションフレームワークの実験的評価. † 藤原 晃　 † 楠本 真二　 † 井上 克郎　 ‡ 大坪 稔房　 ‡ 湯浦 克彦 † 大阪大学大学院基礎工学研究科 ‡ 株式会社日立製作所ビジネスソリューション事業部. 研究の背景. 再利用のひとつとしてフレームワークを用いた手法が注目されている． フレームワーク：アプリケーション開発者がカスタマイズできるアプリケーションの半完成品 開発組織によっては現場独自の再利用の仕組みを確立しており，フレームワークを用いた再利用手法を新たに導入するのは難しい．

hong
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 複雑度と機能量に基づくアプリケーションフレームワークの実験的評価複雑度と機能量に基づくアプリケーションフレームワークの実験的評価 †藤原 晃　†楠本 真二　†井上 克郎　 ‡大坪 稔房　 ‡湯浦 克彦 †大阪大学大学院基礎工学研究科 ‡株式会社日立製作所ビジネスソリューション事業部

  2. 研究の背景 • 再利用のひとつとしてフレームワークを用いた手法が注目されている． • フレームワーク：アプリケーション開発者がカスタマイズできるアプリケーションの半完成品 • 開発組織によっては現場独自の再利用の仕組みを確立しており，フレームワークを用いた再利用手法を新たに導入するのは難しい． • フレームワークを用いた再利用手法の効果を定量的に示す必要がある．

  3. 研究の目的 • フレームワークを用いた再利用手法の効果を定量的に評価する． • 工数が削減されるか、品質は向上するか． • 対象：特定のアプリケーション開発（地方自治体向け窓口アプリケーション） • 開発言語：Java

  4. B1：データベース更新プログラム 画面遷移制御部 B11：データ 問い合わせ B12：問い合わせ 結果表示 B13： データの更新 (b)地方自治体B向けアプリケーション 従来の再利用手法 • 各画面単位で処理プログラムを部品化して再利用する． A1：データベース更新プログラム 画面遷移制御部 A11：データ 問い合わせ A12：問い合わせ 結果表示 A13： データの更新 (a)地方自治体A向けアプリケーション

  5. データベース更新 プログラム　B 地方自治体Ｂ固有の パラメータ フレームワークを用いた再利用手法 • 画面単位の処理プログラムの部品化に加え，画面遷移単位の処理をフレームワーク化し，再利用する • 選択，検索，更新，参照などの処理が持つ画面遷移のタイプごとにフレームワーク化 データベース更新 プログラム　A F1：　フレームワーク データベース更新フレームワーク 地方自治体Ａ固有の パラメータ データ 問い合わせ 問い合わせ 結果表示 データの更新

  6. 評価方法 • 従来の再利用手法とフレームワークを利用した場合の再利用とで工数や品質に関する比較を行う． (ケーススタディ1)　類似アプリケーションを複数開発する場合． (ケーススタディ2)　あるアプリケーションに対して機能を順次追加していく場合． • 使用するメトリクス • 工数：　オブジェクト指向ファンクションポイント（OOFP）→機能量 • 品質：　ChidamberとKemererのメトリクス（Ｃ‐Ｋメトリクス）→複雑度 • 計測対象：Javaソースコード

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

  8. 機能量（２）OOFPの算出方法（１） OOFP=OOFPILF+OOFPEIF+OOFPSR • 各内部論理ファイル（ＩＬＦ）について、データ項目数（ＤＥＴ）とレコード種類数（ＲＥＴ）からOOFPILFを算出． • 各外部インターフェイスファイル（ＥＩＦ）について、データ項目数（ＤＥＴ）とレコード種類数（ＲＥＴ）からOOFPEIFを算出． • 各トランザクション（ＳＲ）について、データ項目数（ＤＥＴ）と関連ファイル数（ＦＴＲ）からOOFPSRを算出． • 合計し、アプリケーションのOOFPを算出．

  9. 機能量（３）OOFPの算出方法（２） • JavaソースコードからＯＯＦＰを算出するため、ＯＯＦＰの各概念とJavaの要素を以下のように対応させた。

  10. 複雑度ChidamberとKemererのメトリクス • オブジェクト指向プログラムの複雑度をあらわす６つのメトリクス.

  11. ケーススタディ１ 評価対象 • 4つの機能 fa, fb, fc, fdの各機能を持つアプリケーション． • C : フレームワークを用いて開発したアプリケーション • P : フレームワークを用いずに開発したアプリケーション

  12. ケーススタディ１ 概要 • 同機能を持つアプリケーションの開発において，フレームワークを用いる場合と用いない場合の機能量と複雑度を比較する． フレームワークあり Ca フレームワークなし Pa 機能 fa FW FW：フレームワーク C：フレームワークを用いたアプリケーション P：フレームワークを用いないアプリケーション ・・・計測範囲

  13. ケーススタディ１：計測結果

  14. ケーススタディ１：OOFP計測結果 ※各クラスのＯＯＦＰ値の総和 • フレームワークを用いている方が機能量が少ない． • 　→フレームワークによって開発工数が削減されている．

  15. ケーススタディ１：複雑度計測結果（１） ※各クラスのメトリクス値の平均 • フレームワークありの方がクラス間のメソッド呼び出しが多い． • →呼び出すメソッドはすべてフレームワーク内のクラスのメソッドなので、フレームワーク部分の品質が高ければ影響は少ない．

  16. ケーススタディ１：複雑度計測結果（２） ※各クラスのメトリクス値の平均 フレームワークを用いたほうがクラスあたりのメソッド数が多い． →属性のset, get（処理が１行程度のメソッド）がほとんどなので品質にあまり影響しない．

  17. ケーススタディ２ 評価対象 • アプリケーションに機能を fa, fb, fc, fdの順に追加していく． • C : フレームワークを用いて開発したアプリケーション • P : フレームワークを用いずに開発したアプリケーション

  18. フレームワークあり Ca+b フレームワークなし Pa+b 機能 fa+b ケーススタディ２　概要 • システムに新たに機能を追加する時の機能量、複雑度の変化をフレームワークを用いる場合と用いない場合で比較する フレームワークあり Ca フレームワークなし Pa FW 機能 fa FW：フレームワーク C：フレームワークを用いたアプリケーション P：フレームワークを用いないアプリケーション ・・・計測範囲

  19. ケーススタディ２：計測結果

  20. 75 89 327 234 165 235 ケーススタディ２：OOFP計測結果（１） ※各クラスのＯＯＦＰ値の総和 機能 fcを追加する時にフレームワークありのほうがＯＯＦＰ値が高い →機能 fcとフレームワークの適合性がよくない 　　機能 fcの機能にあわせたコンポーネントが必要

  21. ケーススタディ２：OOFP計測結果（２） ※各クラスのＯＯＦＰ値の総和 fa+b+c+dではフレームワークを用いた方がＯＯＦＰ値が小さい →全体ではフレームワークを用いたことにより開発工数が削減された

  22. 1.2 0.9 2.3 1.1 0.9 0.9 13.4 1.7 -0.1 0.3 -1.8 1.9 ケーススタディ２：複雑度計測結果（１） ※各クラスのメトリクス値の平均 フレームワークありで機能fcを追加したとき、ＲＦＣ値の増加量が大きい →機能fcは処理するデータ項目が多いため、フレームワーククラスのメソッド呼び出しが多くなっている。

  23. ケーススタディ２：複雑度計測結果（２） ※各クラスのメトリクス値の平均 fa+b+c+dではフレームワークありの方がメソッド呼び出しが多い →呼び出しているメソッドはすべてフレームワークに含まれるクラスのメソッドなので、フレームワーク部分の品質が高ければ影響は少ない．

  24. -1.3 -0.1 8.5 -0.2 -3.0 8.2 0.2 0.0 0.7 0.0 -0.4 0.6 ケーススタディ２：複雑度計測結果（３） ※各クラスのメトリクス値の平均 フレームワークありで機能ｆｃを追加するときにＬＣＯＭ値の増加量が多い →処理するデータ項目が多いため、属性のset,getメソッドが多い

  25. -1.3 -0.1 8.5 -0.2 -3.0 8.2 0.2 0.0 0.7 0.0 -0.4 0.6 ケーススタディ２：複雑度計測結果（４） ※各クラスのメトリクス値の平均 フレームワークなしで機能fdを追加するときにＬＣＯＭ値の増加量が多い →機能fdでは複雑な画面処理があり、その処理を行うクラスでＬＣＯＭが高かった.　フレームワークありの場合、この画面処理はフレームワークが行っている。

  26. ケーススタディ２：複雑度計測結果（５） ※各クラスのメトリクス値の平均 fa+b+c+dではフレームワークを用いたほうがクラスあたりのメソッド数が多い． →属性のset, get（処理が１行程度のメソッド）がほとんどなので品質にあまり影響しない．

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

More Related