レイヤリングは、秩序だったグループで機能を表現し、上位レイヤにはアプリケーション固有の機能、中間レイヤには複数のアプリケーション ドメインにわたる機能、下位レイヤには導入環境に固有の機能が含まれます。

レイヤの数と構成は、問題ドメインと解決法領域の両方の複雑さに応じて、次のようになります。

  • 通常は、アプリケーション固有のレイヤは 1 つだけです。
  • 以前のシステムが構築されたドメイン、または小規模な相互運用システムから転向して大規模なシステムが構成されるドメインの場合は、設計チーム間で情報を共有する必要性が強くなります。その結果、ビジネス固有のレイヤは、部分的に存在する可能性が高く、明確にするために複数のレイヤで構成されることがあります。
  • ミドルウェア製品によって明確にサポートされる解決法領域と、複雑なシステム ソフトウェアが大きな部分を占める解決法領域の場合は、明確に開発された下位レイヤを持ち、おそらくミドルウェアとシステム ソフトウェアの複数のレイヤで構成されます。

サブシステムは、レイヤで構成する必要があります。アーキテクチャの上位レイヤにはアプリケーション固有のサブシステム、アーキテクチャの下位レイヤにはハードウェアと運用固有のサブシステムを置き、汎用のサービスがミドルウェアのレイヤを占めます。

4 つのレイヤを持つアーキテクチャのサンプルを次に示します。

  • 最上位のレイヤのアプリケーション レイヤには、アプリケーション固有のサービスが含まれます。
  • 次のレイヤのビジネス固有のレイヤには、ビジネス固有のコンポーネントが含まれ、複数のアプリケーションで使用されます。
  • ミドルウェアのレイヤには、GUI ビルダーなどのコンポーネント、データベース管理システムとのインターフェイス、プラットフォームに依存しないオペレーティング システム サービス、スプレッドシートやダイアグラム エディタなどの OLE コンポーネントが含まれます。
  • 最下位のレイヤのシステム ソフトウェア レイヤには、オペレーティング システム、データベース、特定のハードウェアとのインターフェイスなどのコンポーネントが含まれます。

レイヤ化された構造は、最も一般的なレベルの機能から開始し、より具体的なレベルの機能へと成長します。



Rational Unified Process   2003.06.15