上記の基準で用いた「フェーズ」の情報は，UML図から取り出すことができない．そこ で，特定の開発プロセスの各フェーズで作成された図の情報を設計者に記述させ，それを 利用する．この情報をプロセス情報と呼ぶ．
プロセス情報は，図5.1のように構成される．図5.1において，パッケージ名にフェーズ の名前を，パッケージ内のクラス名に作成される図の名前を，パッケージ間の依存関係に フェーズの実行順序を示す．
図 5.1: プロセス情報
第 6 章
依存関係の自動生成
本章では，簡単な例を用いて依存関係を自動生成する過程を述べる．例として，クラス
“ElevatorControl”とオブジェクト“:ElevatorControl”の間に基本依存関係を自動生成する 過程を以下に述べ，図6.1に示す．ただし，両UML記述とも，同じフェーズにあると仮定 する．
図 6.1: 依存関係の自動生成法
1. UML記述の組み合わせの抽出 照合規則より，ターゲットをクラス，ソースをオ ブジェクトとする規則「クラスの名前は，オブジェクトの名前に含まれる」を適用す る．この例ではクラス名がオブジェクトの名前に含まれるため，この規則を満たす．
2. 生成モデル要素の検索 表4.1より，クラスとオブジェクトの生成モデル要素は，そ
れぞれClassifier要素とインスタンス要素である．
3. 基本依存関係の型の列挙 図4.1の付加規則より，Classifier要素をターゲット，イン スタンス要素をソースとする基本依存関係の情報共有と同一概念を，両要素をつな ぐ基本依存関係の候補として列挙する．
4. 型の選択 2つの図面が同一フェーズで作成されたことを示すプロセス情報があるた め，選択規則より「情報共有」を選ぶ．
5. 基本依存関係の付加 基本依存関係「情報共有」を，両UML記述間に付加する．
第 7 章
変更波及解析の方法
設定された依存関係を追跡することにより変更波及を解析を行う技術は，文献2, 8, 22 などですでに提案されており，本論文でも同じ手法を採用する．クラス“ElevatorControl”
の変更波及解析例を用いて，その解析方法を以下に述べ，図7.1に示す．
図 7.1: 波及解析方法
1. 変更された要素から波及するUML記述群の取り出し このクラスをターゲットと する依存関係を探し，そのソースのUML記述を取り出す．
2. 波及したUML記述群から，さらに波及する新たなUML記述群の取り出し 前工 程で取り出されたUML記述をターゲットとする依存関係を探し，そのソースのUML 記述を取り出す．
3. (2)の反復 UML記述は一度しか追跡されないとして，UML記述が取り出されなく なるまで繰り返す．
本手法を利用して解析可能な変更波及は，論理的な波及である．変更波及は論理的な波 及と，システムの性能に関する波及の2種類にわけられる[23]．論理的な波及とは，他の 中間成果物との一貫性を論理的に保証するための変更波及であり，システムの性能に関す る波及とは，システム性能の向上を目的として構造や振舞を再構成するための変更波及で ある．
第 8 章 評価
本節では，提案手法の有効性を評価する．題材として，Unified Processの一種である開
発方法論COMET[9]により作成されたエレベータ制御システムとATMシステムをとりあ
げる．エレベータ制御システムは，エレベータを１つのコントローラで制御する集中管理 型のシステムであり，ATMシステムは，ATMと銀行サーバとの連携を含む分散管理型の システムである．これらの題材に本論文で提案した手法を適用して，自動生成された基本 依存関係の精度，および変更波及解析における有用性を評価する．
8.1 評価対象の特徴
評価対象の選択にあたっては，ドメイン，アーキテクチャ，フェーズ構成，フェーズに 出現するUML図の頻度などの観点から以下の二つの例題をとりあげて評価する．以下に エレベータ制御システムとATMシステムの特徴をまとめる．
エレベータ制御システム
1. ドメイン センサー・アクチュエータベースのリアルタイム制御システム 2. アーキテクチャ 集中制御型
3. フェーズ構成の特徴 ユースケースによる機能要求定義，問題領域オブジェクトの 発見と動的モデリング，サブシステム設計，タスク設計
4. 各フェーズで利用している図面の種類と数 ユースケースによる機能要求定義(ユー スケース図2枚)，問題領域オブジェクトの発見と動的モデリング（クラス図2枚，ス
テートチャート図5枚，コラボレーション図5枚），サブシステム設計（クラス図1 枚，コラボレーション図3枚），タスク設計（クラス図1枚，コラボレーション図）
ATMシステム
1. ドメイン トランザクション管理 2. アーキテクチャ クライアントサーバ
3. フェーズ構成の特徴 ユースケースモデルによる機能要求定義，エンティティオブ ジェクトに関するドメイン分析（種々のトランザクション，口座，カード情報など），
アーキテクチャスタイルの決定（クライアントサーバ），クライアントサブシステム およびサーバサブシステムに対するユースケースの割り当て，サブシステムごとの 問題領域オブジェクトの発見，サブシステム内部構造の詳細化，タスク設計
4. 各フェーズで利用している図面の種類と数 ユースケースモデルによる機能要求定 義（ユースケース図1枚），エンティティオブジェクトに関するドメイン分析（種々 のトランザクション，口座，カード情報など）（クラス図6枚），アーキテクチャスタ イルの決定（クライアントサーバ），クライアントサブシステムおよびサーバサブシ ステムに対するユースケースの割り当て（ユースケース図1枚，コラボレーション図 3枚），サブシステムごとの問題領域オブジェクトの発見（クラス図1枚，ステート チャート図6枚，コラボレーション図6枚，シーケンス図2枚），サブシステム内部 構造の詳細化（コラボレーション図2枚），タスク設計（コラボレーション図2枚）