Java EE

(1)

クラス間依存関係に基づく

Java EE アプリケーションの品質特性分析

に関する研究

2008 年 2 月 4 日（月）提出

指導 : 深澤良彰教授

早稲田大学大学院理工学研究科情報・ネットワーク専攻学籍番号 : 3604U062-2

斉藤勇樹

(2)

第6章関連研究 44 6.1 層状構造関連 . . . . 44 6.1.1 層状構造からの逸脱度 . . . . 44 6.1.2 開発フェーズにおける層状構造の維持 . . . . 44 6.1.3 Dependency Structured Matrixによる層状構造の実装. . . . 45 6.2 パッケージデザインメトリック関連 . . . . 47 6.2.1 PASTAメトリック . . . . 47 6.2.2 Ducasseらのメトリクス . . . . 48

第7章おわりに 49

謝辞 54

研究業績 55

(4)

第 1 _{章はじめに}

大規模なJava Enterprise Edition（Java EE）アプリケーション開発において，

そのアプリケーションは長期に渡る運用を考え，高い保守性を備える必要がある．

層状構造はソフトウェア開発で広く適用されるアーキテクチャパターンであり、アプリケーションをサブシステムに分割する際にそれらの責務に応じた層に分類することで，保守性，再利用性，交換可能性といった品質特性を満足する[1][2]．しかし，アーキテクチャパターンとして記述される層状構造はそれを実現するための詳細なコーディングまでは言及していない．層状構造を記述したアーキテクチャドキュメントも，層状構造を箱と線の曖昧な図で記述していることが多い[3]．その結果，アプリケーションが再利用性や交換可能性といった層状構造が本来提供する品質特性を保持しているかどうかを，保守者が判断することが困難になる．

Java EEアプリケーションのみに留まらず，大規模なアプリケーションは稼動開

始後の保守フェーズにおいて，そのアプリケーションを構成するサブシステムおよびサブシステム間の構造が，度重なる変更により開発当初の意図から逸脱していくことが知られている[4]．ある時点におけるアプリケーションの構造が，要求された品質特性を満足する構造になっているかどうかを示すことは重要である．

本稿では，層状構造を意図して実装されたJava EEアプリケーションの構造が，

層状構造の品質特性である再利用性および交換可能性を満足するのに適した構造になっているかどうかを分析する方法を提案する．そして，提案した分析法を具体的な層状構造Java EEアプリケーションに適用した結果を検討する．提案した分析法を同一のJava EEアプリケーションの異なるバージョンに適用することで，

特定のバージョンにおけるアプリケーションの構造が再利用性および交換可能性に適した構造になっているかどうかを判別することができる．

本稿の構成は以下の通りである．第2章では，Java EEアーキテクチャの概要，

層状構造の特性について説明する．第3章では，パッケージデザインと再利用性，

交換可能性の関係について述べる．第4章では，クラス間の依存関係に基づき，層

状構造Java EEアプリケーションの各層が再利用性および交換可能性に適した構

造になっているかを分析する方法を提案する．第5章では，提案した分析法を具体的な層状構造Java EEアプリケーションに適用し、その結果の考察を行う．第

(5)

6章で関連研究を参照し，第7章で研究を総括する．

(6)

第 2 _章 Java EE _{アーキテクチャと層} 状構造

2.1 Java EE アーキテクチャ

Java EEは(Javaのバージョンが1.5になる前はJ2EEと呼ばれた)Javaで書かれた分散オブジェクト指向のプログラムをどのように開発し設計するか，そして，

様々なJavaコンポーネントの通信と相互作用に関する標準仕様を提供している[5]．

また，Java EEの各技術であるEJBは，サーバ側のコンポーネントベースのプログラミングモデルについて記述している．全体として見ると，Java EEは企業全体に対するサービスについても記述している．例えば，命名，トランザクション，

コンポーネントのライフサイクル，持続性，そしてこれらのサービスが一様に提供され，アクセスする方法である．Java EE標準に準拠したアプリケーションは，

理論上Java EEのプラットフォームで移植可能である．

Java EEは分散オブジェクト指向システムを構築する1つのアプローチであり，

それ以外のアプローチももちろん存在する．Object Management Group(OMG) のCommon Object Request Broker Architecture(CORBA)を使用して，分散オブジェクト指向システムが構築されている．CORBAモデルでは，object request

broker(ORB)により，オブジェクトがそのインターフェースを外部に公開するこ

とができ，クライアントプログラムがネットワーク上の遠隔に位置するオブジェクトを発見してそれらのサービスを要求することができる．Microsoft社も，分散システム構築のための技術(.NET)を持っている．.NETは，Windowsベースの基盤で分散オブジェクトシステムを構築するためのアーキテクチャである．

以下では，分散システム用の業界標準アーキテクチャの生成につながるビジネスドライバを述べ，Java EEアーキテクチャがどのようにそのニーズに応えたかについて議論する．

(7)

2.1.1 要求と品質

インターネット対応のビジネスシステムの増加する要求に応じて，より多くのエンタープライズ情報システムが分散オブジェクト技術を使用して構築されている．これらのシステムは，規模の拡張可能性，高い性能，移植性，そしてセキュリティ性を要求する．それらは，クライアントからの多くの要求を扱う必要があり，

同時に待ちによるストレスを与えない時間内でその要求に応えなければならない．

多くのeビジネス組織が直面する困難は，Webサイトの構築を成功させることにある．成功したサイトは，大量のアクセスを引き起こす．一日に何百万，もしくはそれをはるかに上回るアクセスを受け取り，しばしばそれらは短時間に爆発的に発生するため，Webサイトのソフトウェアに大きな負荷をもたらす．

この意味で，インターネットは企業のソフトウェアシステムに対する要求を絶えず変化させている．インターネット特有の性質が，従来のネットワークされた情報システムが過去に経験したことのない，アプリケーションに影響を与える新たな要因をもたらしている．アプリケーション膨大な数のユーザからアクセスされると，拡張可能性，セキュリティ性，および信頼性などの品質特性要求が，急激に増加する．表2.1にWebベースのアプリケーションが満たすべき品質特性要求を示す．

表 2.1: 平均的なWebアプリケーションの品質特性要求

品質要求

規模拡張性システムは，人による介入なしに，様々な負荷に対処しなければならない．

可用性/信頼性システムは，極めて短時間の不稼動を除けば，毎日24時間週7 日，稼動しなければならない．

セキュリティ性システムは，ユーザを認証し，権限のないデータに対するアクセスから保護しなければならない．

使いやすさ様々なユーザが，異なる形で異なるコンテンツにアクセス可能でなければならない．

性能ユーザは，応答性の優れたシステムのサービスを提供されなければならない

Sun Microsystems社は，Java EEを開発する際に，このようなシステム構築をサポートする技術基礎の提供を試みた．仕様の一部は以下の通りである．

• Javaで分散オブジェクト指向のビジネスアプリケーションを構築するために，

(8)

平成19年度修士論文

早稲田大学大学院理工学研究科情報・ネットワーク専攻深澤研究室コンポーネントベースのアーキテクチャを提供すること．Java EEの重要部分であるEJBは，異なるベンダーのツールで開発されたコンポーネントを組み合わせることにより，分散アプリケーションの構築を可能にする．

• アプリケーションの作成をより容易にすること．アプリケーション開発者は，

トランザクションと状態管理，マルチスレッド，リソースプーリング，といった下位層の詳細について対処する必要がない．

Java EEは，サーバ側の基盤でJavaコンポーネントの再利用を可能にする．適

切なコンポーネントの組み立てと配備ツールを用いて，GUIビルダツールに関連したプログラミングの容易さを，サーバーアプリケーション開発に提供することが目的である．また，単一の言語(Java)に基づいたJava EE製品に標準フレームワークを提供することによって，Java EEのコンポーネントベースの解決策は，理論上，様々なベンダーから提供されるJava EEプラットフォーム間の移植を可能にすることである．表2.2は，Sunがプログラミングチームの活動を対象に新たに追加した品質特性要求である．

(9)

表 2.2: Java EEに対するSunの品質特性要求

品質特性要求

移植可能性 Java EEは，様々な計算機プラットフォーム上で極めて少しの作業で実装可能でなければならない．

開発可能製アプリケーション開発者は，トランザクション，ネームサービス，セキュリティのような共通のサービスを管理する機能の提供を受け入れなければならない．

均衡の取れた特異性コンポーネント開発者，ベンダー，インテグレータ向けに有効な標準を示すほど詳細であるが，ベンダー固有の機能や最適化を十分可能にする詳しさでなければならない．

実装透過性詳細な内容を意識せずに実装可能にするが，その結果，クライアント側プログラムはオブジェクトの詳細な実装(サーバ側のコンポーネントの位置，オペレーティングシステムベンダーなど)を十分可能にする．

相互運用性異なるベンダーの実装環境に導入されたサーバー側のコンポーネントの相互処理を支援する;CORBA，マイクロソフトのコンポーネント技術などの別の技術と，Java EEの相互運用性の橋渡しを可能にする．

進化可能性増分させて異なるテクノロジーを導入することができる．

機能拡張性新たなテクノロジーが開発された場合，関連するテクノロジーとの統合を可能にする．

2.1.2 Java EE アーキテクチャによる解決策

前小節で議論した品質特性を満たすためのSunのアプローチは，2つの主要なアーキテクチャの仕様であるJava EEとEJBを使用したものである．Java EEは，

コンポーネントベースで，企業全体のアプリケーションの設計・開発・配置に必要な多層アーキテクチャ全般について記述している．EJBはJava EEの核となる技術であり，構築可能性，機能拡張性，そして相互運用性の詳細な技術要求を反映したものである．本小節の残りでは，2つのアーキテクチャのうち層状構造と密接な関係を持つJava EEの多層アーキテクチャに着目する．

Java EEプラットフォームの主な特徴は，以下のとおりである．

• 多層分散アプリケーションモデル

• サーバ側のコンポーネントモデル

• 内蔵のトランザクション制御

(10)

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

Java EEの多層アーキテクチャで表される配置ビューを図2.1にアーキテクチャ

の要素を表2.3に示す．

UML

図 2.1: Java EE多層アーキテクチャの配置ビュー

(11)

表 2.3: Java EE技術のコンポーネント，およびサービスコンポーネント/サー

ビス

説明 Enterprise Jav-

aBeans (EJB) アーキテクチャ

開発者に，エンタープライズに強みのあるサーバ側コンポーネントに基づいたアプリケーション開発，展開，管理を可能にするAPI仕様を定義する．

Java Server Pages (JSP)

動的なWebコンテンツの作成を可能にするメソッドを提供する．

Java Servlet Webアプリケーション開発者に，Webサーバの機能を拡張する

仕組みを提供する．

Java Messaging Ser- vice (JMS)

Java EEアプリケーションいにポイントツーポイント(1対1) かPublisher-Subscriber(多対多)の相互作用のスタイルを用いた非同期のメッセージングを提供する

Java Naming Di- rectory Interface (JNDI)

Java EEのディレクトリサービスは，JavaクライアントとWeb 層のServletが，たとえばEJBや環境エントリー(JDBCドライバーのアドレス等)のユーザが定義したオブジェクトに対する問い合わせの検索を可能にする．

Java Transaction Service (JTS)

EJB，およびクライアントのトランザクション処理を可能にする．

Java EE Connector Services (JCA)

Java EEプラットフォームを異機種のエンタープライズ情報シス

テムに接続する標準的なアーキテクチャを定義する．これには，

ERP(Enterprise Resource Planning)やCRM(Customer Rela- tionship Management)システムのような市販アプリケーションが含まれている．

Client Access Ser- vices COM Bridge

ネットワーク上でCOMとJava EEアプリケーションの統合を可能にする．

RMI over IIOP 開発者にOMGの業界標準IIOP(Internet Inter-ORB Protocol) 上のJava RMI APIの実装を可能にする．

Java Database Con- nectivity

プログラマーに広範なリレーショナルデータベースへの統一されたインターフェースを提供し，その上でもっと高レベルのツールやインターフェースを作成可能にする共通の基盤となる．

(12)

各層の役割は以下のとおりである．

クライアント層 Webアプリケーションでは，クライアント層にHTTPのリクエストを出し，WebサーバからHTMLをダウンロードするインターネットブラウザが含まれている．ブラウザを使用せずに展開されたアプリケーションでは，スタンドアロンのJavaクライアント，あるいはアプレットを使用することができる．これらは，ビジネスコンポーネント層と直接通信する．

Web層 Web層は，Webサーバを実行し，クライアントのリクエストを扱い，そしてJava EEサーブレットあるいはJSP(JSP)を起動し，そのリクエストに応える．サーブレットは，ユーザリクエストのタイプに依存するサーバによって起動される．また，要求された情報のためにビジネスロジック層を検索し，

そのリクエストを満たし，サーバを経由してユーザに返す情報のフォーマットを作成する．

ビジネスコンポーネント層ビジネスコンポーネント層は，アプリケーションの核となるビジネスロジックを含んでいる．このロジックは，EJB (Java EEにサポートされたソフトウェアコンポーネントモデル)によって実現される．EJB は，Web層のサーブレットからリクエストを受け取り，通常，いくつかのデータソースへアクセスしてリクエストを満たし，サーブレットに結果を返す．

EJBコンポーネントは，EJBコンテナとして知られているJava EE環境によってホストされ，トランザクションとライフサイクル管理，状態管理，セキュリティ，マルチスレッド，リソースプーリングを含んだ多くのサービスをEJBに供給する．EJBは，実行時にそれらがコンテナから要求する振る舞いの方を単に定義し，続いてサービスを提供するためにコンテナを信頼する．これは，システムとシステム環境の問題を扱う方法として，コードを書いてビジネスロジックを散在させてしまうことからアプリケーションプログラマを解放する．

エンタープライズ情報システム層これは，通常，メインフレーム，および他のレガシーシステムのような，1つ以上のデータベースとバックエンドアプリケーションから構成される．そしてEJBは，リクエストを処理するためにクエリーを実行する．JDBCドライバは，通常，RDBMS(Relational Database

Management System)であることが多いデータベースに対して使用される．

多層アーキテクチャは，層状構造のバリエーションの1つであり，ビジネスソフトウェアにおける情報システムで採用されることが多い．これは，多層アーキテ

(13)

クチャを導入することで，本節で述べたエンタープライズシステムの品質特性要求を満たすことができるからである．

2.2 _層状構造

2.2.1 層状構造の概要

層状構造は，一般にレイヤーパターンとして知られるアーキテクチャパターンを適用した結果得られた構造のことを指す．パターンとは、繰り返し発生する状況(文脈)において制約条件をもつ問題に対する実証済みの解法の記述である．表 2.4にレイヤーパターンの概要を示す．

表 2.4: レイヤーパターンの概要文脈分割が必要な大規模システム

問題全体を理解するには複雑すぎるシステム保守をすることが困難なシステム

最も不安定な部分が隔離されていないシステム再利用可能な部分を特定することが困難なシステム

複数の異なるスキルセットを持った複数のチームで開発されるシステム

解法システムを適当数のレイヤーで構造化し，それを互いに積み重ねる

Clementsらはソフトウェアアーキテクチャを文書化する際，コードや実装単位

およびそれらの関連を一覧に示した記述したモジュールビュータイプ，動的振る舞いを記述したコンポーネント・コネクタビュータイプ，ハードウェアや開発チームなどソフトウェア以外のエンティティを一覧に示した割り当てビュータイプの3つの視点から行うことを推奨している[3]．本稿の層状構造はモジュールビュータイプのレイヤースタイルに対応し，Clementsらはレイヤースタイルの構成要素，要素間の関係，要素の特性について述べている．以下の表に2.5レイヤースタイルの概要を示す．

(14)

表 2.5: レイヤースタイルの概要

要素レイヤー

関係「allowed to use」の関係．これはモジュールビュータイプの汎

化した「depends on」の関係を特殊かしたものである．モジュールM₁の正確性がモジュールM₂の正確性を伴った実装に依存する場合，M₁はM₂を利用するという．

要素の属性

レイヤーの名称

レイヤーのなかにあるソフトウェアの部位

レイヤーの利用を可能にするソフトウェアこの属性は２箇所で表現される．第1に，レイヤーとレイヤー間のルールを示す．たとえば，「レイヤーは全ての下位のレイヤーのソフトウェアを利用可能である」，そして「ソフトウェアは，同じレイヤー内の他のソフトウェアを利用できない」

といったルールを指す．第2に，ルールに対する許容可能な例外に名前を付ける．

レイヤーの凝集性これはレイヤーによって表現される仮想マシンを記述したものである．

関係の属性モジュールビュータイプに関する．

トポロジーレイヤーAがレイヤーBの上位であれば，レイヤーBはレイヤーAの上位に依存することはできない．ソフトウェアのあらゆる部位は，どれか1つのレイヤーに割り付けられる．

層状構造にしたがって構築されたシステムは，通常，以下の品質特性を備える．

再利用性十分な考察の結果，優れた抽象物として個々のレイヤーが実装され，そのインターフェースの設計も優れており，さらにドキュメントが完備されている場合，そのレイヤーを複数のコンテキストで再利用することができる．

変更容易性標準化されたインターフェースをレイヤー間に用いることで，コード変更に対する労力を，変更されるレイヤーだけに限定することができる．

交換容易性個々のレイヤー実装を意味的に等価な実装に置き換えるのに，多大な労力を必要としない．

(15)

2.2.2 層状構造の表記

層状構造は非形式的に図2.2のように表記される．

A

B

C

図 2.2: 非形式的な層状構造の表記

図2.2が示す通り，層状構造の重要な特性は依存関係の方向である．特定の層に属する要素は，同層に属する要素かまたは直下の層に属する要素へのアクセスのみ許可されている．例えば，層Aに属する要素は，層Aに属する要素か層Bに属する要素にのみアクセスすることができ，層Cに属する要素へのアクセスは許可されていない．図2.2が示す構造は有向非循環グラフと呼ばれる．有向とは依存が一方向に行われ，非循環とは依存関係のパスが循環していないことを指している．

層状構造の表記に用いられるモデリング言語としてUnified Modeling Language

(UML)がある．UMLは層状構造をサポートする機構は備えていないが，以下の図

2.3に示す通り，あらかじめ定義されたパッケージ記法とステレオタイプを用いて表現可能である．

この記法における依存関係は使用の許可であり，特定の層に属する要素が，他の層に属する要素にアクセスすることを許可されていることを示す．

• あるパッケージに属する要素は同パッケージの他の要素へアクセスすることが許可されている．

• あるパッケージが他のパッケージへアクセスすれば，アクセスされたパッケー

ジのpublicな可視性を伴って定義された要素はすべて，アクセスしたパッケー

ジで見ることができる．

(16)

<<layer>> A

<<layer>> B

<<allowed to use>>

図 2.3: UMLパッケージによる層状構造の表記

2.2.3 層状構造のバリエーション

本小節では層状構造の他のバリエーションについても言及し，本稿で扱う層状構造との比較を行う．

リラックスレイヤーシステム

Szyperskiは層間の依存関係に基づき，層状構造を厳密なレイヤーシステムとリ

ラックスレイヤーシステムに区別している[6]．図2.4にリラックスレイヤーシステムを示す．

A

B

C

図 2.4: スタックによる層状構造の表記

厳密なレイヤーシステムが直下のレイヤーのサービスしか利用できないのに対し，リラックスレイヤーシステムでは，各レイヤーがそれよりも下位にあるすべて

(17)

のレイヤーのサービスを使用することができる．リラックスレイヤーシステムでは，

柔軟性とパフォーマンスが向上するが，その代わりに保守性は低下する．UNIXオペレーティングシステムやXウィンドウシステムなどインフラストラクチャとなるシステムで，このバリエーションが採用されるケースが多い．インフラストラクチャシステムは，アプリケーションに比べると，更新が少なく安定しており，保守性よりもパフォーマンスが重視されることが主要な理由である．本稿では前提として厳密なレイヤーシステムとリラックスレイヤーシステムの区別はしない．

継承によるレイヤー化

このバリエーションは，オブジェクト指向システムで採用され，下位レイヤーが基底クラスとして実装される．下位レイヤーにサービスをリクエストする上位レイヤーは，下位レイヤーの実装を継承しており，そのために基底クラスのサービスに対してもリクエストを発行することができる仕組みになっている．以下に，

Observerパターンのクラス図と対応する継承レイヤーの図を示す．

Subject

ConcreteSubject ConcreteObserver Observer

図2.5: Observerパターンのクラス図

Subject

ConcreteSubject ConcreteObserver Observer

Concrete Layer Abstract Layer

layer relationship use relationship

図2.6: Observerパターンに見られるレイヤーこのバリエーションの長所は，上位レイヤーが自らのニーズに応じて下位レイヤーのサービスを変更できることである．短所は，継承関係が上位レイヤーを下位レイヤーに密接に結びつけてしまう所であり，継承によって導入される本質的でないそのような依存性は，基底クラスの脆弱な課題として知られる．本稿では，

ビジネスソフトウェアにおける情報システムを対象にしているため，プレゼンテーションやアプリケーションロジックといった継承によるレイヤーよりも粗粒度なレイヤーを考慮している．

(18)

第 3 章パッケージデザインと再利用性，交換可能性

再利用性および交換可能性は，Javaを始めとしたプログラミング言語が提供するパッケージと密接な関係がある．あるプログラムからコピーしたクラスを別のプログラムに配置して，コピーしたプログラムに全く修正を加えることなくコンパイルが通ることは稀であり，クラス1つでは再利用の基本的な単位にはならない．

たとえば，クラスAのメソッドの引数や戻り値，メソッド本体の内部に他のクラスBの参照型が宣言されていた場合，クラスAはクラスBに依存している．クラスBがドメイン固有の機能を提供するクラスだった場合，クラスBは他のクラスにも依存している可能性が高い．このようにして単一のクラスが再利用の対象になるわけではなく，パッケージが再利用の対象になる．同様に，交換可能性について議論する場合も，単一のクラスを交換の単位として考えるのではなく，パッケージを交換の単位として考える．

本章では，まず優れたパッケージデザインの特性について述べ，再利用性および交換可能性がその優れたパッケージデザインの特性とどのような関係があるかを説明する．

3.1 パッケージデザイン

パッケージはクラスより高い抽象レベルでモジュール管理をするための機構であり，Ada，C++，Javaでサポートされている．パッケージを用いて複数のクラスをサブシステムといった名前付きの単位で管理することできる．パッケージデザインの関心事は，クラスをどのようにパッケージにまとめるかということである．

多数の著者がパッケージデザインの原則を発見しており，それらを異なった名称で呼んでいる．Lakosは実装設計という用語を用いてパッケージデザインの原則について述べている[7]．Martinはパッケージデザインという用語を用いている[8]．

いずれの文献もパッケージデザインにおける2つの原則について述べている．1

(19)

つは，クラス集合をどのようにパッケージに分類するかというパッケージ構成の原則である．2つめは，特定の抽象レベルにおけるパッケージ集合とそれらの依存からなる有向グラフのグラフ特性に関する原則である．

3.1.1 パッケージ構成

Javaにおけるパッケージはクラスまたは他のパッケージを含むため再帰的構造を成す．この再帰的構造により異なる抽象度でサブシステムを表現することができる．すなわちあるパッケージは内部に含むパッケージより，抽象度の高いサブシステムを表している．以下では，パッケージ構成において留意すべきパッケージサイズと独立パッケージについて述べる．

パッケージサイズ

パッケージに含まれる要素数は一定数を越えてはならない．Coadらは，Miller のマジックナンバー7±2をパッケージサイズとして指定している[9][10]．この数字は，Millerの人間の短期記憶で一度に記憶できる数は5∼9であり，パッケージを直ちに理解するには5∼9個のクラスやパッケージという根拠に基づく．他の著者はこの一定数に対して異なる見解を持っている．Lakosは1コンポーネント(抽象度の低いサブシステム)あたり500∼1000LOC，1パッケージ(より抽象度の高いサブシステム)あたり5000∼50000LOCに相当すると定義している[7]．Meyerはクラスタは5∼40個のクラスからなり，1∼4人で開発可能，1人で理解可能であることと定義している[11]．

パッケージ数に決まった値が存在するわけではないが，一定値を定めておくことは重要である．そのような値は組織のポリシーあるいは個人の選択によって決まる．

独立パッケージ

独立パッケージとは他のパッケージへの依存を最小におさえたパッケージのことを指す．図3.1は2つのパッケージとそれらの間の依存関係を示す．パッケージ AがパッケージBに依存する，とはパッケージA内の全クラスをコンパイルするためにパッケージBの一部のまたは全てのクラスが存在しなければならないことを意味する．あるプログラム内のパッケージ群を異なるプログラムに再配置して変更を加えずに動作させたいという再利用の点から，コンパイル依存という概念

(20)

A B

図 3.1: パッケージの依存関係

は重要であり，適当なパッケージサイズの独立パッケージを持つことはシステムの再利用性向上につながる．

3.1.2 グラフの特性

パッケージの独立性をシステム中の全てのパッケージについて調べるため，ここではパッケージ依存グラフ(PDG)を用いる．パッケージの独立性はPDGのトポロジーと密接に関係しており，循環依存を含むもしくはPDGのトポロジーが”

高い”PDGは，再利用が困難であることを意味する．

PDGを，P DG= (N, E)で定義し，Nはある抽象レベルにおけるシステム中のパッケージの集合，Eはパッケージ間のコンパイル依存集合からなる有向辺を表す．以下の図3.2にトポロジーの異なる3つのPDGを示す．3つのPDGは，トポロジーaの辺数を除き（aの辺数はリンク構造になっているため，b，cの辺数より1本多い），同数のパッケージ数，依存数をもつため，パッケージデザインの”

良し悪し”について正当な比較が可能である．

上図の目的は，循環依存やクリティカルパスの長いPDG(以降，クリティカルパ

スの長いPDGを高いPDG，クリティカルパスの短いPDGを水平なPDGと呼ぶ)

に，独立パッケージは存在しないことを示すためである．トポロジーaのPDGの任意の1パッケージを別のプログラムに配置する場合，他の4つのパッケージも全てコピーしなければ，そのパッケージをコンパイルすることができない．別のプログラムへの再配置という観点からコンパイル依存関係は推移的である．図3.2のパッケージ内に示す数字は，そのパッケージを異なるプログラムに再配置する際

(21)

a) b) c)

図 3.2: トポロジーの異なるPDG

に必要な(自身も含む)システム内のパッケージ数である．

トポロジーbのPDGについても同様の議論が可能であり，最上位に位置するパッケージを異なるプログラムに再配置する際に必要なパッケージ数は5となる．

再利用という観点から，トポロジーbのPDGはトポロジーaのPDGよりパッケージデザインが優れている．下位に位置するパッケージであればあるほど，依存している他のパッケージ数が減少していくためである．トポロジーcのPDGは，1 パッケージを他のプログラムに再配置する際，他のパッケージへの依存を最小限にしているため(任意の1パッケージを再配置する際に必要な平均パッケージ数1.8)，

3つのPDGの中で再利用に最も優れている構造である．

現実のシステムをPDGとして表した場合は，ノードの辺の出次数は図3.2の例よりも大きく，より多くの層を持つことが知られている．Lakosは，現実のソフトウェアは平衡二分木のように規則正しい構造を成すことは稀だと述べているが，再利用性という観点から平衡二分木をソフトウェアシステムのデザインの比較対象として参照するとよいと述べている．図3.3に示すとおり，全体のパッケージ数の半数以上が葉にあたる．葉にあたるパッケージは他のパッケージに依存しておらず，全体の1/4のパッケージは再配置の際に必要となるパッケージ数は自身を含めわずかに2である．

(22)

図 3.3: 平衡二分木構造を成すPDG

3.2 再利用性

本節では，前節で述べたパッケージデザインの原則と再利用性との関係について述べる．再利用性とは，ソフトウェアモジュールが2つ以上のコンピュータプログラムもしくはソフトウェアシステムで使用可能な程度を指す[12]．再利用可能なものとして，ソフトウェアアーキテクチャ記述やデザインパターンといった概念的なものから，手続きやクラスやモジュールといったより低レベルのものが存在する．パッケージデザインに関する文献によれば，1つのプログラムのソースコード中の機能再利用はシステム全体の再利用につながる．稼動実績のあるシステムのソースコードを再利用することで開発コストおよび欠陥を軽減することができるためである．

コード再利用とは，1つのプログラム中のソースコードのテキストに変更を加えずに別のプログラムにコピーすることをいう．一方，コードコピーはコピーしたソースコードのテキストに変更を加えて，自らの実行環境でプログラムを動作させることをいう．コードコピーではコピーされたソースコードは度重なる変更により，元のソースコードとは完全に異なったものになる．コードコピーに潜む問題は，コードをコピーした人物がその実装の変更に対して全責任を負い，オリジナルのコードでバグ修正やバージョンアップがあった場合，その新しいバージョンのコードをコピーして使う際に，再び変更を加えなければならなくなる点にある．

独立パッケージは他のパッケージへの依存を最小限におさえているため，あるシステムから別のシステムにコピーするパッケージ数は少なくてすむ．コピーし

(23)

なければならないパッケージが少ないほど，理解しなければならないコード量は減り，バグが潜む可能性低くなる．再利用するためにコピーしなければならないパッケージの数は関心事の1つであるが，それ以上に重要な問題がある．その問題とは，1パッケージがある機能性を提供する際に，そのパッケージが依存する他のパッケージの多くは必ずしも必要ではないことである[7]．前節で述べたように，

水平な，非循環のパッケージ構造はその問題を対処するのに有効な構造である．

高いPDGまたは循環依存を含むPDGは再利用には困難な構造だが，依存反転則(Dependency Inversion Principle)によりパッケージ群を実装とインターフェースに分割することで，水平なPDGに変換することができる[13]．図3.4に，依存反転則(Dependency Inversion Principle)を適用して高いPDGを水平化した例を示す．

a) PDG pre-DIP b) PDG post-DIP

図 3.4: DIPによる高いPDGの水平化

bに示すPDGの方がaのPDGよりも実装パッケージ(Y Impl，Z Impl)に柔軟性があるという点で，より優れたパッケージデザインである．bのPDGの実装パッケージがより柔軟性があるのは，異なる実装パッケージが与えられた場合でも使用可能だからである．たとえば，bに示すYの実装パッケージは，Zの実装パッケージが変更された場合でも使用することができる．bのパッケージ群を再利用する際，実装パッケージを他のシステムに配置する必要がないため，bのパッケージ群は独立性が向上している．例として，Yの実装パッケージを再利用をするのに，

Zの実装パッケージをコピーする必要がない．これは，Yの実装パッケージの再利用の際，Zの実装パッケージに潜在的に含まれるバグを隔離できるため，再利用先のシステムの信頼性が向上を意味する．

このように，再利用性はパッケージ構造と密接な関係を持ち，再利用性を向上

(24)

早稲田大学大学院理工学研究科情報・ネットワーク専攻深澤研究室させるためには，(1)PDGが非循環であること，(2)水平なPDGであること，が考慮すべき重要な事項である．(1)を満たすことは，パッケージ構造が再利用に適した構造であることの1条件を満たしたにすぎない．(1)を満たした上で(2)を考慮する必要があるが，現段階では提案する分析法に組み込むことができなかったため，(2)を考慮することは今後の課題とする．本稿の残りでは再利用性に適した構造かどうかを判断する基準として(1)を用いる．

3.3 交換可能性

交換可能性は，他のサブシステムに影響を与えず特定のサブシステムを意味的に等価なサブシステムに置き換えることができる程度を指す．すなわち交換可能性が高いソフトウェアシステムでは，特定のサブシステムS₁を意味的に等価なモジュールS₂に交換した場合，他のサブシステムがS₂を利用する際のコストを低く抑えられることを意味する．あるサブシステムが異なるサブシステムを利用する際のコストはサブシステム間の依存関係の結合度と関連がある．以下の図3.5，図 3.6に，2つのサブシステムと依存関係を示す．

1

2

図 3.5: 交換が困難な依存関係

1

2

図 3.6: 交換が容易な依存関係図3.5において，サブシステム2を意味的に等価なサブシステム3に交換した場合，サブシステム1はサブシステム3を利用するために全て再実装しなくてはならない．一方，図3.6は，サブシステム間の依存関係はファサードとなるクラス間の依存関係だけである．サブシステム2を意味的に等価なサブシステ4に交換した場合，サブシステム1の外部へ行われる依存はファサードクラスを通して行われるため，サブシステム4への依存もこのサブシステム1のファサードクラスを通して行われる．サブシステム間の依存関係が疎結合であれば，交換されたサブシステムを利用するためのコストが低く抑えられるため，システムの交換可能性が向上する．

(25)

層状構造では交換する単位が1つの層である．図3.5，図3.6に示すとおり，層間の依存関係を疎結合にすることで，1つの層を交換後，システムを再稼動させるために解決しなければならない依存の数が少なくなる．解決しなければならない依存数が少ないほど，労力およびコストを軽減できると考える．したがって，層間の依存関係が疎結合であるシステムは高い交換可能性を備えている．

(26)

第 4 _{章分析法の概要}

本研究で提案する分析法は，第3章で述べた再利用性，交換可能性を定量的な尺度で測定するための測定法を必要とする．まず再利用性分析に関する既存のメトリックClass Reachability Set Size(CRSS)を説明する．そして交換可能性に関するメトリックCoupling Between Layers(CBL)を提案し，最後にCRSSおよびCBL を層状構造をもつシステムに対してどのように適用するかを述べる．

4.1 Class Reachability Set Size(CRSS)

CRSSは，Meltonらがパッケージデザインの品質を測定するために提案したメトリックである[14]．CRSSは，Class Dependency Graph(CDG)の1つのノードに適用することでメトリック値を得る．CDGは，ソフトウェアシステムの特定の部位に属するクラスの集合をノードとし，クラス間のコンパイル依存関係の集合をエッジとしたグラフである．あるクラスCに対するCRSSは，クラスCを表すノードから到達可能なノードの総数である．より厳密には，あるクラスC に対し

てDepends−On(C)は，クラスC をコンパイルするために存在しなければなら

ないクラス集合のことを指す．Javaでは，クラスCをコンパイルするためにクラスパスに存在していなければならない.classファイルの集合である．CRSS(C)は，

Depends−On関係の推移閉包を表す集合のサイズである．

例として，図4.1にCDG，各クラスの到達可能なクラス集合，そしてCRSSを示す．

(27)

3 {i, g, h}

i

3 {h, i, g}

h

3 {g, h, i}

g

4 {f, g, h, i}

f

1 {e}

e

5 {d, f, g, h, i}

d

5 {c, f, g, h, i}

c

2 {b, e}

b

9 {a, b, e, c, f, d, g, h, i}

a

CRSS Reachability Set

Node

図 4.1: CDG，各クラスの到達可能なクラス集合および集合のCRSS

Meltonらによれば，CRSSを使用する目的は，システムのクラス間のコンパイ

ル依存関係が与えられたときに独立パッケージ，パッケージサイズの観点から再利用に最適なパッケージ構造を構築可能かどうかを示すためである．Meltonらは，

単一のクラスのCRSSに着目するのではなく，システム全体のクラスのCRSSの分布に着目するべきだと述べている．図4.1のCDGのCRSSの分布を図4.2にヒストグラムとして示す．

0 1 2 3 4

1 2 3 4 5 6 7 8 9

CRSS Value

Frequency

図 4.2: 図4.1に示すCDGのCRSSヒストグラム

CRSSヒストグラムは，高いCRSSを持つクラスが多く存在した場合，パッケージ間に循環依存が発生するため，再利用に適当なパッケージ構造に変換するため

(28)

には，クラス間の依存関係を破壊する以外に方法がないことを示すためのものである．高いCRSS，あるいは多く存在するという部分を明確にするために具体的な 例を示す．

100個のクラスからなるシステムを考え，パッケージサイズはクラス5個以下とする．パッケージサイズの原則が守られれば，パッケージは少なくとも20個存在するが，ここではクラスを5個持つパッケージサイズが20個存在すると仮定する．

パッケージ内の1つのクラスは，同パッケージ内の全ての他クラスに到達可能であるとする．そして，CRSS分布が以下の図4.3のように，50個のクラスが0∼5，

50個のクラスが60∼69を示しているとする．この条件下で，パッケージ間に循環依存が発生することを示す．

"!

#$%#&'(

!#$%#&'(!#$%#&'(

"!

#$%#&'(

図 4.3: パッケージ間循環依存不可避なCRSS分布

CRSSが9以下のクラス集合をL，CRSSが60∼69のクラス集合をRとする．L に属するクラスは，パッケージ間で循環依存を発生させることなく10個のパッケージに分類することができる．Rに属するクラスは，600以上の他のクラスに推移的に依存しなければならない．600以上の他のクラスは，12以上のパッケージに分類されており，多くて10のパッケージはLに属するクラスのみを含む．したがって，

Rのクラスは，依存する12のパッケージのうち少なくとも2つのパッケージはR のクラスのみを含むパッケージでなければならない．Rのクラス50個についても同様のことが成り立つが，Rのクラスのみを含むパッケージの総数は20-10(Lのクラスを含むパッケージ数)=10しかないため，パッケージ間で循環依存が発生する．循環依存が発生していなければ，パッケージ内部に含むクラスを他のパッケージに移動すればパッケージ構造を変えることができる．しかし，循環依存を破壊

(29)

した場合，コードを修正しなければ循環依存を破壊することはできず，修正の際に新たなバグを作りこむ危険がある．パッケージサイズを大きくすればパッケージ間の循環依存を回避することが可能である．しかし，パッケージ間の循環依存を隠蔽するためだけにパッケージサイズを増加させることは，パッケージ理解の妨げにつながる．CRSSヒストグラムとパッケージサイズが与えられれば，パッケージ間の循環依存を回避できるかどうか判別することができる．

4.2 Coupling Between Layers (CBL)

3.3節で述べたとおり，あるモジュール単位を交換する場合，それらモジュール間の依存関係は疎結合であればあるほど交換発生後に行う修正の箇所が少なくて済む．本稿では層状構造を扱っているため，層間の結合を表す尺度が必要である．

M個のクラスからなる層状構造Aからm個のクラスがN個のクラスからなる層状構造Bのn個のクラスに依存強度xで依存したとする．図4.4に対応するCDGを示す．

A

B

…

M

N

m

n

…

_x

図 4.4: 層間の依存関係と層の結合度

CBLを次式で定義する．

CBL= x

mn m M

n

N = x

MN

(30)

最終的なCBLの式は，層間の依存強度をそれぞれの層のクラス数の積で割った商である．中間結果のうち，第1項x/mnは2部グラフにおける依存数の飽和度を示す．これは，2部グラフでノード数mとノード数nのノード集合に分かれているとき，それらの間の最大依存数はmnであることによる．第2項m/Mは，層A に属するクラスのうち何割のクラスが層Bに依存しているかを表す．第3項n/N も同様に層Bに属するクラスのうち何割のクラスが層Aからの依存をうけているかを示す．CBL値が増加すると，層Bを意味的に等価な層B’と交換した場合に層 Aが下位の層を再び利用する際のコストが増加すると考える．層Aを意味的に等価な層A’と交換した場合，層Bが層A’を利用する際にかかるコストについては言及していない．

4.3 層状構造からパッケージへのマッピング

本節では，Java EEの業界で広く用いられる層状構造のパッケージ戦略ついて

述べる．Java EEアプリケーションにおいて設計段階のレイヤを実装する際，パッ

ケージを基本単位として実装する．オブザベーションによれば2通りの層状構造のパッケージ戦略が存在する[15] [16] [17] [18] [19]．2通りのパッケージ戦略を図 4.5，図4.6に示し，表4.1でそれらの比較を述べる．

1

2

1

2

図 4.5: 層優先構築

1

2

1

2

図 4.6: サブシステム優先構築

(31)

表 4.1: パッケージ戦略の比較

アプローチ利点欠点

層優先構築

• サブシステムごとのモデル管理を単純化する．

• サブシステム間の認められない依存関係の特定が容易になる．

• プロジェクトを更新する際の計画が立てやすくなる

• サブシステム間の結合度を小さくすることで，アーキテクチャ上での表現が容易になる

• サブシステムの再利用性を向上させる

• サブシステム間で一貫性を保つことが困難になる．

例えばデーターベース管理者が全サブシステム層にまたがるデータレイヤーを把握することが難しくなる．

サブシステム優先構

築 • 層内部の一貫性を保つこ

とができる

• 層に適当な技術を割り付けることができる．例えば GUIレイヤーにJSP，ビジネスレイヤーにセッションBean，データレイヤーにエンティティBeanという割り付けが可能になる．

• 層の全てまたは一部の再利用性が向上する

• 例外処理など意味的に層に分類することが難しいコードがある

• アプリケーションの規模が増大すると，1つの層に対応するパッケージの規模も増大し，管理が困難になる．

(32)

層優先構築，サブシステム優先構築以外に開発者のスキルセット，セキュリティ，

オーナーシップ，責務といった要素に基づいた層のパッケージ戦略も存在する[20]．

層状構造をもつシステムに対しCRSSおよびCBLを適用するには，層および層に属するクラスを特定しなければならない．層優先構築では最上位パッケージが1つの層に割り付けられるため，層および層のクラスを一意に特定することができる．

アーキテクチャ文書を参照し，ソースコードから層状構造を抽出する手法も存在

する[21]．しかし抽出した層状構造がアーキテクチャが意図した層状構造かどうか

を一意に判断する方法は困難であり，既存の層状構造の抽出法はいずれも限定された条件下で適用可能である．本稿では，抽出した層状構造の妥当性に関して議論を展開するより，すでに層状構造から適当なパッケージ構造が得られたという前提のもとで議論を進める．具体的には層優先構築にしたがったパッケージ構造

をもつJava EEアプリケーションを対象として，CRSSおよびCBLを適用する．

層状構造をもつシステムにおけるクラス間依存は，層内部に存在するクラス間依存と，層間に及ぶクラス間依存に分けることができる．層内部に存在するクラス間依存はCRSSヒストグラムを生成するために用い，層間に及ぶクラス間依存はCBL値を算出するために用いる．例として，図4.7にCRSSで考慮されるクラス間依存関係とCBLで考慮されるクラス間依存関係を示す．

(33)

_A

_B

_C

図 4.7: CRSS，CBLで考慮されるクラス間依存関係

(34)

第 5 _{章評価および考察}

本章では，節5.2.3章で述べた層優先構築にしたがったパッケージ構造をもつJava EEアプリケーションに対しCRSSおよびCBLを適用し，再利用性，交換可能性の観点から結果を考察する．メトリクスの利用法には異なるプロジェクト間でメトリクス値を比較する場合と，同一プロジェクトの過去のメトリクス値と比較する方が場合がある[22]．CRSSおよびCRLは後者の利用法をとり，同一のアプリケーションの異なるバージョンに適用し特定のバージョンのコードベースの状態を把握する．

5.1 評価

評価の対象としてxPetstore[23]およびJPetStore[24]という2つのJava EEアプリケーションを取り上げる．評価対象のアプリケーションの数が2というのは分析法の有用性を検証するには不十分である．オープンソースのJava EEアプリケーションは多数入手できたが，層優先構築という条件により評価対象とするアプリケーションの数は2となった．また今後のためにCRSSおよびCBL値を測定しておくことは重要である．層状構図を持つかどうかはWeb，Business，Servicesといった最上位パッケージの名前，および最上位パッケージの数から判断した．Java EE アプリケーションの層状構造Web層，ビジネス層といった名前と無関係な名前を最上位パッケージに与えているアプリケーションは考慮していない．層優先構築での最上位パッケージ数は3〜5となるため，この値を大幅に超えた最上位パッケー

ジを持つJava EEアプリケーションも考慮していない．

5.1.1 xPetstore における評価

xPetstoreは，SunがJava EEアプリケーション構築の例として公開したPetStore[25]

をxDocletベースで実装しなおしたものでSourceForgeから入手可能である[26]．

(35)

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ヒストグラム

(36)

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

13#$#4576 8

9

13#$#4576+: 8

;

< = < < = <

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

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

/1#$#2354 6

7 8