第 5 章 評価および考察 31
5.2 考察
5.2.1 xPetstore に対する考察
JPetStoreの各層交換可能性
各層の交換可能性はCBL値から分析する．JPetStoreのバージョン3.0，4.0の presentation，service，persistence，domainのCBL値の結果を図5.10，図5.11に 示す．
x 0.113 0.15 0.183
domain
x x
-persistence
x x
x 0.0208 service
x x
x x
presentation
domain persistence service
presentation
図 5.10: JPetStore3.0各層のCBL値
x 0.119 0.259 0.0463
domain
x x
0.238
-persistence
x x
x 0.0833 service
x x
x x
presentation
domain persistence service
presentation
図 5.11: JPetStore4.0各層のCBL値 バージョン3.0から4.0へ変更する際，CBLが増加した層間はpresentation-service，
service-domain，persistence-domainである．CBLが減少した層間は persistence-domainである．service-persistence層間の依存関係はバージョン4.0で導入された ため，バージョン3.0と比較することはできない．xが記されているセルは層状構 造に違反する依存関係であることを示し，-は依存関係は認められているが存在し ていないことを表す．
平成19年度修士論文
早稲田大学大学院 理工学研究科 情報・ネットワーク専攻 深澤研究室
セッションBeanであり，EJBコンテナにその処理の詳細を委譲していることに よる．
domainパッケージにおいてCRSSが1∼5の範囲にあるクラスは，utilクラスお よびアプリケーションデータを実装したエンティティBeanである．utilクラスは 他のクラスから利用されるためCRSSは低い．エンティティBeanは，永続処理の 詳細をコンテナに委譲しているため低いCRSSを示している．CRSS6∼10の範囲 にあるクラスはエンティティBeanのうち，CustomerやOrderItemといった他の エンティティBeanを参照しているエンティティBeanである．例えばCustomerエ ンティティBeanはCRSSが1∼5のAddressエンティティBeanに依存しているた めにCRSSが6∼10となる．同様に，CRSSが16∼20を示すクラスはOrderエン ティティBeanに関係するクラスであり，CRSSが6∼10のエンティティBeanに依 存しているためである．
CRSSヒストグラムから判別できることは，パッケージサイズおよびクラス間依 存関係からパッケージ間循環が発生しないパッケージ構造を構築することができ るかどうかであり，クラスをその責務にしたがってどのパッケージに分類するかま では述べていない．パッケージ間循環依存が不可避なパッケージ構造になってい る場合，クラスをパッケージ間で移し変える操作だけではパッケージ間の循環依 存を破壊することはできず，クラスレベルでソースコードを書き換えなければな らない．アプリケーションを構成するクラス数が多い場合に，CRSSヒストグラム の形状からパッケージ間に循環依存関係が発生するかどうかを判別できることは 非常に有用である．本稿で示したCRSSヒストグラムの形状とパッケージ依存の 議論は厳密なものではないため，数学的証明によるCRSSヒストグラムの形状と パッケージ依存の議論は今後の課題である．
また，交換可能性に関して本稿ではコストの増減を裏付けるデータはないため CBLの有用性の検証には不十分であるが，今後のためにCBL値を算出しておくこ とは重要である．
5.2.2 JPetStore に対する考察
xPetstoreと異なりJPetStoreはPOJOで実装されているがpresentation，service，
persistence，domainパッケージ内のクラスのCRSSは低くパッケージ間循環依存 は発生しない．
presentationパッケージのほぼ全てのクラスのCRSSが1∼5の範囲内にあるの は，presentationパッケージ内のクラスがStrutsの提供するクラスを用いているた
めである．フレームワークが提供するクラスを利用するとCRSSが低くなる傾向 にある．
JPetStoreのserviceパッケージはバージョン3.0，4.0ともにクラス数が2，3で あり，serviceパッケージ内のクラスPetStoreServiceは，presentation層からのメ ソッド呼び出しにより，domain層のクラスのメソッドを呼び出すメソッドをもち，
presentation層とdomain層の結合度を下げるはたらきをする．
persistenceパッケージは全クラスのCRSSが1∼5の範囲に存在する．persistence パッケージは，アプリケーションデータに対応するDAOおよび同DAOのインター フェースからなり，DAOインターフェースはシグニチャの定義，DAOはdomainパッ ケージのアプリケーションデータを表すクラスに依存している．結果，persistence パッケージのクラスのCRSSは1∼5の範囲内にとどまっている．
domainパッケージのクラスうちバージョン3.0では80%のクラス，バージョン
4.0では89%のクラスが1∼5であり，これらはAccount，CartItem，Categoryと いったアプリケーションデータである．CRSS6∼10のクラスはアプリケーション データOrderでCRSS1∼5のクラスに依存する．
総じて，JPetStoreの各層は，StrutsをはじめとしたフレームワークおよびJava EEのデザインパターンにより，CRSSが低くなっていると考える．結果，JPetStore のクラス間依存関係から循環依存のないパッケージ構造が構築可能となる．しか
し，5.2.1節で述べたとおり，CRSSヒストグラムからクラスをその責務にしたがっ
てどのパッケージに分類するかまでは断定することはできない．
xPetstore同様，交換可能性に関して本稿ではコストの増減を裏付けるデータは
見つけることができなかったが、今後のために各層のCBL値を算出した．
5.2.3 提案した分析法の適用可能性
本稿の分析法が適用可能なアプリケーションの種類は，層優先構築に従ったパッ ケージ構造を持つ，ソースコード解析が可能なJava EEアプリケーションである．
この適用可能性には以下のような問題点がある．
第1に，層状構造からパッケージ構造への対応付けが層優先構築しか考慮して いない点である．節で述べたとおり，他の層状構造からパッケージ構造への対応 付けとしてサブシステム，セキュリティ，スキルセットなどに基づいた対応付けが 存在するため，層優先構築以外の文脈で分析法の適用を考えるなら，それらにつ いても考慮しなければならない．層優先構築以外で本稿の分析法を利用する場合，
実装から層状構造を抽出しなければならないため，抽出される層状構造は抽出法 の精度に依存するという問題がある．
平成19年度修士論文
早稲田大学大学院 理工学研究科 情報・ネットワーク専攻 深澤研究室
第2に，DIコンテナのようにモジュール間依存関係をソースコードに記述しな い機構を使用した場合，提案した分析法は適用できないという点である．本稿の 分析法はソースコード解析により得られたCDGやPDGグラフをを分析法の基礎 としている．DIコンテナを使用した場合，モジュール間の依存関係を設定ファイ ルに記述するため，ソースコード解析によってCDGやPDGを得ることはできな い．理論上，設定ファイルに記述された依存関係の情報を抽出することでソース コード解析から得られるグラフとは特性の異なるグラフを生成することはできる が，本稿の分析法はその特性の異なるグラフに対しては適用することはできない．
層状構造やパッケージデザインに関する研究は，以下に示すように多く存在す る．しかし，本研究のように層状構造とパッケージを関連付けて層状構造の品質 特性を分析した事例はなく，本研究の独自性を示している．
6.1 層状構造関連
6.1.1 層状構造からの逸脱度
Sarkarらは，ソースコードから抽出して得られるモジュール間依存グラフとシ
ステムのアーキテクチャ文書を基に，層状構造の原則に違反している箇所の特定 し、違反の程度を測定する手法を提案した[27]．層と層に含まれるモジュールを 厳密に定義した上で，構造上の原則に対する違反項目として次の3つを挙げてい る．(1)Back-call principle: 上位層は下位層に依存し，下位層は上位層に依存する べきではない(2)Skip-call principle: 各々の層は，直下の層とのみ依存関係を持つ (3)Cyclic Dependency principle: 循環依存関係を持つとき，循環依存が複数の層を 越えて行われると，層状構造の境界が不明確になり層の分離が困難になるため，循 環依存は1つの層内で完結すべきである．各々の違反項目に対し，特定の層に属す る全モジュールの中で違反項目に該当するモジュールの割合を求め，その層の違 反の度合いとして算出する．Sarkarらは，逸脱度の大きさとコストの大きさの相 関性の有無を示すことを今後の課題としている．
6.1.2 開発フェーズにおける層状構造の維持
Parkらは，2.2.3で述べた層状構造を対象とし，レイヤ間の継承関係をレイヤ 関係として定義し，ソースコードからレイヤ関係をもとに層状構造を抽出し，抽 出した層状構造がアーキテクチャデザインに適合しているかどうかを調べた[28]．
ParkらはArgoUMLのソースコードを分析対象としている．開発者が使用してい
平成19年度修士論文
早稲田大学大学院 理工学研究科 情報・ネットワーク専攻 深澤研究室
るArgoUML Cookbookによれば，ArgoUMLは層状構造を採用しており設計上，”
上位レベルのコンポーネントは下位レベルのコンポーネントに依存し，下位レベ ルコンポーネントが上位コンポーネントに依存してはならない．コンポーネント は同位レベルのコンポーネントにも依存してはならない”という制約がある．Park らは，ArgoUMLを構成する1207のクラス(89のパッケージに分類されている)か ら層状構造を読み取ることが困難なため，レイヤ関係をもとに層状構造を抽出し，
ArgoUMLの実装がその抽出した層状構造に適合していないことを指摘した．具体
的には，抽出した層状構造において下位レイヤのコンポーネントが上位コンポー ネントを呼び出している箇所を特定した．
6.1.3 Dependency Structured Matrix による層状構造の実装
Dependency Structured Matrixは，システム内の依存関係を表した行列である．
依存関係をグラフ形式で表すCDGやPDGと異なり，システム全体の依存関係を 容易に把握することができる．”容易に”という概念は感覚的だが，ここでは依存関 係の理解のしやすさや一覧性のことを指す．以下の図6.1，6.2は.NET Framework 2.0のmscorlibアセンブリmscorlibをDSMおよびグラフ形式で表現したものであ る．一覧性、理解容易性を定量的に評価することはできないが，依存関係を理解 する場合にはDSMの方が適していることが分かる．