影響度分析は個々の要素のトレーサビリティを使用して影響範囲を確認することです。RDRAは個々の要素がつながることでトレーサビリティを確保しており、このつながりをGraphとして表現します。

UC（ユースケース）や情報などの個々の定義を行っているときに、シンプルな関係を心がけていたとしても、俯瞰して見てみると想定以上に複雑な関係になっていることがあります。それを防ぐためには、適宜全体を俯瞰して関係性を確認する必要があります。

このツールでは全アイコンをダブルクリックすることで、より詳細なつながりを表現できます。

※オブジェクトの役割に応じて表示される要素が変わります

※画面、イベントはダブルクリックに対応しません

影響範囲を分析するためには、起点となるオブジェクトを把握できている必要があります。対象のオブジェクトが明確な場合は、メニュー「オブジェクト一覧」から対象のオブジェクトを選ぶことでダイアグラムを表示できます。

「オブジェクト一覧」はアクターや情報などのモデル毎に全オブジェクトが階層構造で表示されます。フィルターを使ってオブジェクトを絞り込むことで大量のオブジェクトから個別のオブジェクトを探すことができます。

RDRAの要素は階層構造として管理されています。

• 上位階層

業務、BUC、コンテキスト、アクター群、外部システム群

• 下位階層

アクティビティ、UC、画面、外部システム、

情報、条件、バリエーション、タイマー

RDRAではビジネスルールを条件や状態モデルとして表現でき、条件の軸としてバリエーションがあります。システムを理解するためにはビジネスルールの把握が欠かせません。しかし、要件レベルでは条件の詳細には踏み込まみません。同じくバリエーションの値も、説明として列挙する程度の記述になります。つまり条件とバリエーションのトレーサビリティだけを管理します。

システムに対する変更要求が起こるのは、ビジネスルールと入出力です。システムの利用者からは入出力とビジネスルールしか見えないので、変更はそこからしか発生しません。従って変更の影響度分析は変更起点からのつながりを調べることで分析できます。入出力はUCにつながるのでUCを調べることで入出力を確認できます。

「オブジェクト一覧」のフィルターを使って変更対象のオブジェクトを調べ、そのオブジェクトから変更の影響範囲を確認します。

中規模以上（UCが30以上）のシステムになると、RDRAの粒度でも全体を把握することが困難になります。そのため少数のオブジェクトで全体を表現する必要があります。RDRAは階層構造で管理しているので、上位階層同士の関係を表現することで全体を俯瞰できるようになります。

メニュー「業務/BUC/UC」で確認できる。

RDRAは階層構造のルートとして業務（ビジネス）とコンテキスト（システム）、アクター群、外部システム群（関係者）をもち、それぞれをビジネス、システム、関係者として整理できます。

• ビジネス 「業務／BUC」

⇒　アクティビティ

• システム 「コンテキスト」

⇒　情報、状態モデル、条件、バリエーション

• 関係者 「アクター群、外部システム群」

⇒　アクター、外部システム

システムを俯瞰する場合はこの上位階層の関係で表現することでビジネスとシステムをつなげて俯瞰することができます。

全体を俯瞰するためにビジネスとシステム、ビジネスと関係者の２つの関係で把握します。二つの関係はUC（ユースケース）がつなぎ、システム境界の役割を担います。

• ビジネス ←→ システム：

  • • 導出：「アクティビティ ⇔ UC ⇔ 情報」

• ビジネス ←→ 関係者：

  • • 導出：「アクティビティ ⇔ UC ⇔ 画面 ⇔ アクター」

    • 導出：「アクティビティ ⇔ UC ⇔ イベント ⇔ 外部システム」

ビジネスの集約単位は業務とBUCの二段階の階層で表現され、通常はBUCとシステム、BUCと関係者で俯瞰します。大規模なシステムの場合は業務との関係で全体を把握します。

上位階層同士の関係を見ることで結合度を測ることができます。上位階層の関係は下位要素の関係から導出されるので、関係が密な場合はその要素をダブルクリックし階層を下っていくことで導出元の関係を確認できます。

適切な凝集度と結合度は各々のつながりの偏りで判断することができます。会員や在庫などのようにリソース系のコンテキストはつながりの中心的な存在となり、放射状につながる傾向があります。一方トランザクション系のコンテキストは、業務/BUCとのつながりが少ない傾向にあります。このようなつながり方を把握することでシステムの特徴を理解することができます。

コンテキストの関係は「情報モデル」で確認できます。

コンテキストはRDRAのシステムレイヤーに位置付けられ、システムに関わるものが含まれます。その中心が情報になり、役割の同じ情報をまとめたものがコンテキストの単位になります。同じく情報間の関係からコンテキストの関係を導出し、コンテキスト間の結合度が決まｒます。その他の状態モデル、条件、バリエーションは情報と関係が深いものを集めて一つのコンテキストとして定義します。

コンテキストの凝集度は要素間の関りの強さで決まり、強さは以下の関係性が成立するほど強くなります。

• 情報には状態があり、UCが情報を操作することで状態を変える。

• UCは条件に従い、条件はバリエーションを軸とする。

• バリエーションは情報の項目として関わる。

このようにコンテキスト内の要素は互いに関係があり、関係のあるものだけで構成されたコンテキストは凝集度が強いと言えます。

UCには重要なものとそうでないものがあります。重要なUCがわかれば開発の優先順位をつけることもできます。重要なUCはコンテキストをまたぐものと状態を変えるUCと考えることができます。

・複数のコンテキストに関わるUC

・複数の状態に関わるUC

上記ダイアグラムに現れるUCは重要なUCと考えられます。