階層アーキテクチャ

階層アーキテクチャは、システム全体を階層構造と見なします。階層構造では、ソフトウェアシステムが階層内のさまざまなレベルで論理モジュールまたはサブシステムに分解されます。このアプローチは通常、ネットワークプロトコルやオペレーティングシステムなどのシステムソフトウェアの設計に使用されます。

システムソフトウェア階層の設計では、低レベルのサブシステムが隣接する上位レベルのサブシステムにサービスを提供し、下位レベルのメソッドを呼び出します。下位層は、I / Oサービス、トランザクション、スケジューリング、セキュリティサービスなど、より具体的な機能を提供します。中間層は、ビジネスロジックやコア処理サービスなどのドメイン依存機能を提供します。また、上位層は、GUI、シェルプログラミング機能などのユーザーインターフェイスの形で、より抽象的な機能を提供します。

また、名前空間階層内の.NETクラスライブラリなどのクラスライブラリの編成にも使用されます。すべての設計タイプでこの階層アーキテクチャを実装でき、多くの場合、他のアーキテクチャスタイルと組み合わせることができます。

階層的な建築様式は次のように分けられます-

  • Main-subroutine
  • Master-slave
  • 仮想マシン

メイン-サブルーチン

このスタイルの目的は、モジュールを再利用し、個々のモジュールまたはサブルーチンを自由に開発することです。このスタイルでは、ソフトウェアシステムは、システムの目的の機能に応じてトップダウンの改良を使用することにより、サブルーチンに分割されます。

これらの改良は、分解されたモジュールがその排他的な独立した責任を持つのに十分単純になるまで垂直に進みます。機能は、上位層の複数の呼び出し元によって再利用および共有される場合があります。

データがパラメータとしてサブルーチンに渡される方法は2つあります。

  • Pass by Value −サブルーチンは過去のデータのみを使用し、それを変更することはできません。

  • Pass by Reference −サブルーチンは、パラメーターによって参照されるデータの値を使用および変更します。

利点

  • 階層の改良に基づいてシステムを簡単に分解できます。

  • オブジェクト指向設計のサブシステムで使用できます。

短所

  • グローバルに共有されるデータが含まれているため、脆弱です。

  • 緊密な結合は、変化の波及効果を引き起こす可能性があります。

マスタースレーブ

このアプローチは、「分割統治」の原則を適用し、障害計算と計算精度をサポートします。これは、システムの信頼性とフォールトトレランスを提供するメインサブルーチンアーキテクチャの変更です。

このアーキテクチャでは、スレーブはマスターに重複したサービスを提供し、マスターは特定の選択戦略によってスレーブの中から特定の結果を選択します。スレーブは、異なるアルゴリズムと方法、またはまったく異なる機能によって同じ機能タスクを実行する場合があります。これには、すべてのスレーブを並列に実行できる並列コンピューティングが含まれます。

マスタースレーブパターンの実装は、5つのステップに従います-

  • タスクの計算を等しいサブタスクのセットに分割する方法を指定し、サブタスクの処理に必要なサブサービスを特定します。

  • 個々のサブタスクの処理から得られた結果を利用して、サービス全体の最終結果を計算する方法を指定します。

  • 手順1で特定したサブサービスのインターフェイスを定義します。これはスレーブによって実装され、マスターによって使用されて、個々のサブタスクの処理を委任します。

  • 前のステップで開発した仕様に従ってスレーブコンポーネントを実装します。

  • 手順1〜3で作成した仕様に従ってマスターを実装します。

アプリケーション

  • ソフトウェアの信頼性が重要な問題であるアプリケーションに適しています。

  • 並列および分散コンピューティングの分野で広く適用されています。

利点

  • より高速な計算と簡単なスケーラビリティ。

  • スレーブを複製できるため、堅牢性を提供します。

  • セマンティックエラーを最小限に抑えるために、スレーブを別の方法で実装できます。

短所

  • 通信オーバーヘッド。

  • すべての問題を分割できるわけではありません。

  • 実装が難しく、移植性の問題。

仮想マシンアーキテクチャ

仮想マシンアーキテクチャは、それが実装されているハードウェアやソフトウェアに固有ではない一部の機能を装います。仮想マシンは既存のシステム上に構築され、仮想抽象化、一連の属性、および操作を提供します。

仮想マシンアーキテクチャでは、マスターはスレーブからの「同じ」サブサービスを使用し、分割作業、スレーブの呼び出し、結果の結合などの機能を実行します。これにより、開発者は、まだ構築されていないプラットフォームをシミュレートおよびテストし、実際のシステムでテストするには複雑すぎ、コストがかかり、危険な「災害」モードをシミュレートできます。

ほとんどの場合、仮想マシンはプログラミング言語またはアプリケーション環境を実行プラットフォームから分割します。主な目的は提供することですportability。仮想マシンを介した特定のモジュールの解釈は、次のように認識される場合があります。

  • 解釈エンジンは、解釈されるモジュールから命令を選択します。

  • 命令に基づいて、エンジンは仮想マシンの内部状態を更新し、上記のプロセスが繰り返されます。

次の図は、単一の物理マシン上の標準VMインフラストラクチャのアーキテクチャを示しています。

ザ・ hypervisor, とも呼ばれます virtual machine monitorは、ホストOSで実行され、一致したリソースを各ゲストOSに割り当てます。ゲストがシステムコールを行うと、ハイパーバイザーはそれをインターセプトして、ホストOSでサポートされている対応するシステムコールに変換します。ハイパーバイザーは、CPU、メモリ、永続ストレージ、I / Oデバイス、およびネットワークへの各仮想マシンのアクセスを制御します。

アプリケーション

仮想マシンアーキテクチャは、次のドメインに適しています-

  • 直接的な解決策がない場合は、シミュレーションまたは変換によって問題を解決するのに適しています。

  • サンプルアプリケーションには、マイクロプログラミング、XML処理、スクリプトコマンド言語の実行、ルールベースのシステム実行、SmalltalkおよびJavaインタープリタータイプのプログラミング言語のインタープリターが含まれます。

  • 仮想マシンの一般的な例は、インタープリター、ルールベースのシステム、構文シェル、およびコマンド言語プロセッサーです。

利点

  • 移植性とマシンプラットフォームの独立性。

  • ソフトウェア開発のシンプルさ。

  • プログラムを中断および照会する機能を通じて柔軟性を提供します。

  • 災害作業モデルのシミュレーション。

  • 実行時に変更を導入します。

短所

  • インタプリタの性質上、インタプリタの実行が遅い。

  • 実行に伴う追加の計算のために、パフォーマンスコストが発生します。

レイヤードスタイル

このアプローチでは、システムは階層内のいくつかの上位層と下位層に分解され、各層はシステム内で独自の責任を負います。

  • 各レイヤーは、パッケージ、デプロイされたコンポーネント、またはメソッドライブラリまたはヘッダーファイルの形式のサブルーチンのグループとしてカプセル化された関連クラスのグループで構成されます。

  • 各レイヤーは、その上のレイヤーにサービスを提供し、下のレイヤーへのクライアントとして機能します。つまり、レイヤーi +1への要求は、レイヤーiのインターフェイスを介してレイヤーiによって提供されるサービスを呼び出します。タスクが完了すると、応答はレイヤーi + 1に戻る場合があります。それ以外の場合、レイヤーiは、下のレイヤーi-1からサービスを継続的に呼び出します。

アプリケーション

レイヤードスタイルは以下の分野に適しています−

  • 階層的に編成できる異なるクラスのサービスを含むアプリケーション。

  • アプリケーション固有の部分とプラットフォーム固有の部分に分解できるアプリケーション。

  • コアサービス、重要なサービス、ユーザーインターフェイスサービスなどが明確に区別されているアプリケーション。

利点

  • 抽象化の段階的なレベルに基づいて設計します。

  • 1つのレイヤーの機能への変更が、最大で2つの他のレイヤーに影響を与えるため、拡張の独立性を提供します。

  • 標準インターフェースの分離とその実装。

  • 新しいコンポーネントのプラグアンドプレイを可能にするシステムをはるかに簡単にするコンポーネントベースのテクノロジーを使用して実装されます。

  • 各レイヤーは、移植性をサポートする独立してデプロイされた抽象マシンにすることができます。

  • トップダウンの洗練された方法でタスクの定義に基づいてシステムを分解するのは簡単

  • 同じレイヤーの異なる実装(同一のインターフェース)は交換可能に使用できます

短所

  • 多くのアプリケーションまたはシステムは、階層化された方法で簡単に構造化されていません。

  • クライアントの要求またはクライアントへの応答は潜在的に複数のレイヤーを通過する必要があるため、実行時のパフォーマンスが低下します。

  • また、各レイヤーによるデータのマーシャリングとバッファリングのオーバーヘッドに関するパフォーマンスの懸念もあります。

  • 層間通信の開放はデッドロックを引き起こす可能性があり、「ブリッジング」は緊密な結合を引き起こす可能性があります。

  • 1つの層の障害はすべての呼び出し層に上向きに広がる必要があるため、例外とエラー処理は階層化アーキテクチャの問題です。