xPetstore における評価

SunのPetStoreの層優先構築ではなく， petstore，mail，customer，signon，shop-pingcart，invantory，personalization，util，tools，という9つの最上位パッケージ から構成される．xPetstoreは，web，services，domain，という3つの最上位パッ ケージからなり，webパッケージにはクライアントリクエストを処理するモジュー ル，servicesパッケージにはビジネスロジックを実装したセッションBean，domain パッケージにはエンティティBeanがそれぞれ含まれている．

SourceForgeではバージョン1.0は公開されておらず，バージョン2.0およびバー ジョン3.0のみ入手可能である．CRSS，CBLをバージョン2.0，バージョン3.0に 適用し，再利用性，交換可能性を分析する．

xPetstoreの各層再利用性

webパッケージ，servicesパッケージ，domainパッケージに対し，各パッケージ 内のクラスおよびクラス間関係からそれぞれCRSSヒストグラムを作成する．図 5.1，5.2，5.3に結果を示す．

! "$#&%' ()+*-,/.+"0213#)#'

14#$#&5/6

7 8

14#$#&5/6 7

9: ;+9 9: ;+9

図 5.1: xPetstoreにおけるwebパッケージのCRSSヒストグラム

平成19年度修士論文

早稲田大学大学院 理工学研究科 情報・ネットワーク専攻 深澤研究室

! "$#%& '(*)+",-./"012#&#&

13#$#4576 8

9

13#$#4576+: 8

;

< = < < = <

図 5.2: xPetstoreにおけるservicesパッケージのCRSSヒストグラム

! "$#%& '() "*,+-."*/0#$#(

/1#$#2354 6

7 8

/1#$#2354 6

9 8

:8 9.: :8 9.:

図 5.3: xPetstoreにおけるdomainパッケージのCRSSヒストグラム

xPetstore2.0および3.0のパッケージサイズは10以下であった．ここでは，パッ ケージサイズを10と仮定する．また，パッケージ内に分類されたクラスは互いに 依存しているものと仮定する．すなわち，パッケージ内のクラスのCRSSはパッ ケージサイズと等しいことを意味する．パッケージサイズが10のパッケージに属 するクラスのCRSSは10であり，パッケージサイズが10に満たないパッケージに 属するクラスのCRSSはパッケージサイズに等しい(パッケージサイズが3のパッ ケージに属するクラスのCRSSは3である)．この仮定は，パッケージ間に循環依 存が発生しないように設計するという点でベストケースを想定している．可能な 限り多くのクラス間依存を1パッケージに内包するため，パッケージ外部へのクラ ス間依存を最小限にしているからである．パッケージ外部へのクラス間依存が実 質パッケージ間の依存になるため，パッケージ外部へのクラス間依存が少ないほ どパッケージ間の循環依存が発生する可能性は低くなる．問題となるのは，ベス トケースを想定しているにも関わらずパッケージ間の循環依存が発生する場合で あり，その状況下ではパッケージ間の循環依存発生は避けることができない．パッ ケージ間の循環依存関係を破壊するには，クラスレベルでコードを書き換えなけ ればならない．

webパッケージのクラスはバージョン2.0では27個のクラス，3.0では30個の クラスが存在するため，webパッケージには3個のパッケージが存在する（バー ジョン2.0ではパッケージサイズが10のパッケージが2個，パッケージサイズが 7のパッケージが1個）．仮定が成立するとすれば，バージョン2.0では少なくと もCRSS 6∼10に属するクラスが27個，バージョン3.0ではCRSSが6∼10に属 するクラスが30個存在する．仮定から得られたこのCRSSヒストグラムは，パッ ケージ間循環依存が発生しないよう意図的に考えたベストケースのCRSSヒスト グラムである．ベストケースのCRSSヒストグラムは，webパッケージから得ら れたCRSSヒストグラムの分布に従うことができる．したがって，web層内部の パッケージ間に循環依存が発生しないパッケージ構造を構築することできる．

servicesパッケージはバージョン2.0では28個クラスが存在するためパッケー ジは3個存在する(パッケージサイズが10のパッケージが2個，パッケージサイ ズが8のパッケージが1個)．同様に，バージョン3.0では18個のクラスが存在す るため，パッケージが2個存在する(パッケージサイズが10のパッケージが1個，

パッケージサイズが8のパッケージが1個)．仮定が成立するとすれば，少なくと もCRSSが6∼10の範囲にバージョン2.0では28，バージョン3.0では18という ヒストグラムになる．webパッケージの議論と同様にservicesパッケージ内のパッ ケージ間に循環依存が発生しないパッケージ構造を構築することができる．

domainパッケージは，バージョン2.0，3.0ともに44個のクラスが存在するた

平成19年度修士論文

早稲田大学大学院 理工学研究科 情報・ネットワーク専攻 深澤研究室

め，パッケージが5個存在する(パッケージサイズが10のパッケージが4個，パッ ケージサイズが4のパッケージが1個)．問題は，domainパッケージにはCRSSが 16∼20のクラスは20個のクラスが存在することである．CRSSが16∼20をもつク ラスは最大で20個のクラスに推移的に依存することを意味する．すなわち，2個の パッケージに推移的に依存する．domainパッケージ内にはパッケージサイズ10の パッケージが4個あり，CRSSが16∼20のクラスは2個であることから，2個のク ラスを含むパッケージからパッケージサイズ10のパッケージ2つに推移的に依存 すれば循環依存が発生することはない．したがって，domainパッケージ内のパッ ケージ間には循環依存が発生しないパッケージ構造を構築することできる．

パッケージ循環依存関係が発生しないことは，再利用可能なパッケージ構造を構 築するために必要な条件の1つである．xPetstoreはバージョン2.0，3.0は，パッ ケージ循環依存が存在しないという観点からは再利用に適当な構造になっている ことがわかった．パッケージ構造のクリティカルパスの長さも考慮すべき1つの要 素であるが，CRSSヒストグラムからはそれは判断することはできない．

以上からxPetstoreは各層において循環依存関係が発生しないパッケージ構造を

構築できることがわかった．これは，xPetstoreの特定の特定の層内のパッケージ Bのコードを再利用して他のシステムに配置しようとする際に，B以外にもコピー しなければならないコードの量を軽減できることを示す．

xPetstoreの各層交換可能性

各層の交換可能性はCBL値から分析する．xPetstoreのバージョン2.0，3.0の web，services，domainのCBL値の結果を図5.4，図5.5に示す．

x 0.0422 0.0185

domain

x x

0.0595 services

x x

x web

domain services

web

図 5.4: xPetstore2.0各層のCBL値

x 0.0556 0.0159

domain

x x

0.0463 services

x x

x web

domain services

web

図 5.5: xPetstore3.0各層のCBL値 図5.4における0.595は，web層(列)がservices層(行)に依存しており，CBL が0.595であることを示す．バージョン2.0から3.0に変更する際，CBL値の減少 がみられたのはweb層-services層，web層-domain層であり，増加がみられたのは

services層-domain層である．xが記されているセルは層状構造に違反する依存関 係であることを示す．

この結果から，servicesパッケージを意味的に等価なservices’に交換しwebパッ ケージがservices’パッケージを利用するコストはバージョン2.0よりバージョン3.0 の方が小さいと推定する．domainパッケージを意味的に等価なパッケージdomain’

に交換した場合，webパッケージがdomain’パッケージを使用するためにかかる コストはバージョン2.0よりバージョン3.0の方が小さく，servicesパッケージが

domain’パッケージを利用するコストはバージョン2.0よりバージョン3.0の方が

大きいと推定する．