目的
  • インターフェース、設計クラス、設計サブシステムを獲得するために、分析クラスの相互作用を分析する
  • 可能な場合に再利用を行ってアーキテクチャーを洗練する
  • よく遭遇する設計上の問題に対する共通の解決法を特定する
  • ソフトウェア・アーキテクチャー説明書の論理ビューの項に、アーキテクチャー上重要な設計モデル要素を追加する
役割:  ソフトウェア アーキテクト 
頻度: 反復ごとに 1 回 
ステップ
入力とする成果物:    結果となる成果物:   
ツール・メンター:   
More Information: 

ワークフローの詳細:   

再利用機会の識別 ページの先頭へ

目的 既存のサブシステムかコンポーネント、またはその両方をインターフェースに基づいて再利用できる部分を識別する。 

類似したインターフェースがある既存のサブシステムまたはコンポーネントの探索: 識別した各インターフェースを、既存のサブシステムまたはコンポーネントによって提供されるインターフェースと比較します。通常、完全に一致するものはありませんが、だいたい一致するものが見つかります。まず、類似した振る舞いと戻り値を探し、次にパラメーターを検討します。

整合性を向上させるための新しく識別したインターフェースの修正: インターフェース候補に少し変更を加える機会があれば、既存のインターフェースへの調和は向上します。単純な変更としては、インターフェース候補のパラメーターを並べ替えたり追加したりしてから、インターフェースを分解することが挙げられます。つまり、1 つ以上のインターフェースが既存のコンポーネントのインターフェースと一致するようにインターフェースを複数のインターフェースに分割し、分割したインターフェースに「新しい」振る舞いを配置します。

完全に一致する場合のインターフェース候補の既存インターフェースとの置換: 単純化と分解の終了後、既存のインターフェースと完全に一致するものがある場合、インターフェース候補を取り除いて、既存のインターフェースを使用します。

サブシステム候補の既存コンポーネントへのマッピング: 既存のコンポーネントとサブシステム候補セットに注目します。システムに必要な振る舞いを満たすことができる場合には、常に既存のコンポーネントが使用されるように、サブシステムを分解します。既存のコンポーネントによってサブシステム候補を実現できる場合は、設計サブシステムと、実装モデル内のコンポーネントとの間に追跡可能性を作成します。

サブシステムを再利用可能なコンポーネントにマッピングする際には、サブシステムに関連付けられた設計メカニズムを検討します。操作シグニチャー間で完全に一致しても、性能要求やセキュリティー要求によってコンポーネントが不適格になる場合があります。

コンポーネントとデータベースのリバース・エンジニアリング ページの先頭へ

目的 潜在的に再利用可能なモデル要素を、他のプロジェクト、外部ソース、以前の反復から取り込む。 

既存のコードとデータベースの定義を「有効活用」して、以前のプロジェクトまたは反復で行った作業を現在のプロジェクトまたは反復で利用できるようにします。潜在的な再利用可能性をフィルターとして使用すると、リバース・エンジニアリングする作業を、現在の反復で再利用可能なコンポーネントだけに絞れます。

コンポーネントのリバース・エンジニアリング

類似したシステムを構築する組織では、新システムに必要なアーキテクチャー・メカニズムのかなりの部分を提供する共通コンポーネントのセットがあることがよくあります。また、アーキテクチャー・メカニズムを提供するコンポーネントが市場に出回っている場合もあります。既存のコンポーネントについても、ソフトウェア・アーキテクチャーにおける適合性と互換性を判別するために調査する必要があります。

既存のコンポーネントは、以前の反復の中で開発したがまだ設計モデルに組み込んでいないものや、購入したもののどちらでも、リバース・エンジニアリングを実行し、設計モデルに取り込む必要があります。設計モデルでは、そのようなコンポーネントは一般的に、1 つ以上のインターフェースを持つサブシステムとして表現されます。

データベースのリバース・エンジニアリング

データベースとデータベース内のデータは、再利用可能な資産の中でも最も重要なソースの 1 つです。既存のデータベースで具体化されている暗黙のクラス定義を再利用するには、アプリケーションで使用される情報のうち、既存のデータベースに既に格納されているものを知る必要があります。この情報を保持するデータベース構造を表現するクラスのセットをリバース・エンジニアリングします。同時に、アプリケーションのクラス表現とデータベースで使用される構造との間にマッピングを構築します。

データベースのリバース・エンジニアリングについて詳しくは、『ガイドライン: リレーショナル・データベースからのリバース・エンジニアリング』を参照してください。リレーショナル・データベースにおけるクラスと表の間のマッピングについて詳しくは、『ガイドライン: データ・モデル』を参照してください。

設計モデルの編成の更新 ページの先頭へ

目的 設計モデル組織における新しいモデル要素を説明する。
必要に応じて、設計モデル構造を再バランス処理する。 

設計モデルに新しい要素を追加すると、多くの場合、設計モデル要素の再パッケージ処理が必要になります。再パッケージ処理によっていくつかの目的が達成されます。パッケージ間の結合度が減少し、設計モデルのパッケージ内の凝集度が向上します。終的な目標は、それぞれの個人またはチームが、お互いに独立した異なるパッケージ (およびサブシステム) を設計し開発できるようにすることです。完全な独立性を達成するのはおそらく不可能でも、パッケージが緩やかに結合していると、大規模システムや複雑なシステムの開発が容易になる傾向があります。

「フラット」なモデル構造 (すべてのパッケージとすべてのサブシステムが、システム内で同一の概念レベルに存在する) は小規模なシステムに適しています。大規模システムにはさらに「レイヤリング」と呼ばれる構造化ツールが必要です (『ガイドライン: レイヤリング』を参照)。 レイヤリングのルールによって、特定の型のパッケージ間で許可されている関係に制約を定義します。このルールでは、ある種の依存性が存在すべきでないことを認めています。つまり、アプリケーションの機能は特定のオペレーティング・システムまたはウィンドウ・システムのサービスに直接に依存すべきではありません。低いレベルの実装サービスが変更しても、アプリケーション機能がその影響から遮へいされる、論理的なオペレーティング・システムとウィンドウ・サービスを含む中間層が必要です。 レイヤリングによって、変更の影響を減少させる方法が提供されます。パッケージとサブシステム間の依存関係を制限するルールを施行することによって、パッケージとサブシステム間の結合度が減少し、システムの堅牢性が増します。これにより、変更への耐性が高まります。

システムに新しいモデル要素が追加されるにつれて、既存のパッケージが大きくなり、単独のチームでは管理できなくなることがあります。この場合には、パッケージを複数に分割します。分割されたパッケージは、パッケージ内での凝集度が高く、パッケージ間の結合度は緩やかである必要があります。このように分割するのが難しい場合があります。いくつかの要素が複数のパッケージの要素から利用されているために、特定の 1 つのパッケージの中に収めるのが困難な場合です。これには次の 2 つの解決法があります。要素を複数のオブジェクトに分割して各パッケージに 1 つずつ入れるか (要素に複数の「人格」がある場合や、互いに無関係な責務のセットがある場合に適している)、要素を下位レイヤーのパッケージに入れて上位のすべてのレイヤーの要素からの依存関係が等しくなるようにします。

システムが複雑になるにつれて、構造を保守、理解できるようにするための多数のレイヤーが必要になります。ただし、最大級のシステムでも 7 ~ 10 レイヤーを超えることはほとんどありません。レイヤー数が増大すると、複雑さが増大し、理解可能性が減少するからです。

ミドルウェアのレイヤーとシステム - ソフトウェア・レイヤーを含むレイヤリングの例を次に示します。

Java/Web アプリケーションのレイアウト図

Java/Web ベースのアプリケーション用パッケージのレイヤリングの例。 メモ: TCP/IP サービスの使用は Java VM、java.rmi、Web ブラウザーの中にカプセル化されているため、TCP/IP パッケージへの依存性は、通常、明白にはモデル化されません。ここでは説明の都合上図示してあります。

サブシステムとレイヤーの責務を個人またはチームに割り当てます。各パッケージまたはサブシステムは、1 個人 (範囲が狭い場合) またはチーム (範囲が広い場合) の責務です。

論理ビューの更新 ページの先頭へ

目的 成果物: ソフトウェア・アーキテクチャー説明書 (論理ビュー)が常に最新であるようにする。 

設計クラス、パッケージ、サブシステム (モデル要素) がアーキテクチャーの視点から重要な場合は、成果物: ソフトウェア・アーキテクチャー説明書の論理ビューの項に含める必要があります。 これにより、アーキテクチャー上重要な新規モデル要素が確実にプロジェクト・チームの他のメンバーに伝達されます。

また、ソフトウェア・アーキテクトはプロセス ・エンジニアと連携して、新しく取り入れた設計要素の使用方法について、設計者と実装担当者に対し、詳細なガイダンスを提供します。



Rational Unified Process   2003.06.15