Software-architecture-design-component-based-architecture

コンポーネントベースのアーキテクチャ

コンポーネントベースのアーキテクチャは、メソッド、イベント、プロパティを含む明確に定義された通信インターフェイスを表す個々の機能コンポーネントまたは論理コンポーネントへの設計の分解に焦点を当てています。 それは、より高いレベルの抽象化を提供し、問題をサブ問題に分割します。それぞれがコンポーネントパーティションに関連付けられています。

コンポーネントベースのアーキテクチャの主な目的は、*コンポーネントの再利用性*を確保することです。 コンポーネントは、ソフトウェア要素の機能と動作を再利用可能で自己展開可能なバイナリユニットにカプセル化します。 COM/DCOM、JavaBean、EJB、CORBA、.NET、Webサービス、グリッドサービスなど、多くの標準コンポーネントフレームワークがあります。 これらのテクノロジーは、グラフィックJavaBeanコンポーネント、MS ActiveXコンポーネント、COMコンポーネントなど、ローカルデスクトップGUIアプリケーション設計で広く使用されており、ドラッグアンドドロップ操作で簡単に再利用できます。

コンポーネント指向のソフトウェア設計には、次のような従来のオブジェクト指向のアプローチよりも多くの利点があります-

• 既存のコンポーネントを再利用することにより、市場での時間と開発コストを削減しました。
• 既存のコンポーネントの再利用による信頼性の向上。

コンポーネントとは何ですか？

コンポーネントは、その実装をカプセル化し、より高いレベルのインターフェースとしてエクスポートする、明確に定義されたモジュール式のポータブルで交換可能な再利用可能なセットです。

コンポーネントとは、特定の機能または一連の機能をカプセル化し、他のコンポーネントと対話することを目的としたソフトウェアオブジェクトです。 明確に定義されたインターフェイスを持ち、アーキテクチャ内のすべてのコンポーネントに共通の推奨動作に準拠しています。

ソフトウェアコンポーネントは、契約で指定されたインターフェイスと明示的なコンテキスト依存関係のみを持つ構成単位として定義できます。 つまり、ソフトウェアコンポーネントは独立して展開でき、サードパーティによる構成の対象となります。

コンポーネントのビュー

コンポーネントには、オブジェクト指向ビュー、従来のビュー、プロセス関連のビューという3つの異なるビューがあります。

オブジェクト指向ビュー

コンポーネントは、1つ以上の連携するクラスのセットと見なされます。 各問題ドメインクラス（分析）とインフラストラクチャクラス（設計）を説明して、その実装に適用されるすべての属性と操作を識別します。 また、クラスが通信して連携できるようにするインターフェースを定義することも含まれます。

従来のビュー

これは、処理ロジック、処理ロジックの実装に必要な内部データ構造、コンポーネントを呼び出してデータを渡すことができるインターフェースを統合するプログラムの機能要素またはモジュールと見なされます。

プロセス関連ビュー

このビューでは、システムは各コンポーネントを一から作成する代わりに、ライブラリに保持されている既存のコンポーネントから構築しています。 ソフトウェアアーキテクチャが定式化されると、ライブラリからコンポーネントが選択され、アーキテクチャの設定に使用されます。

• ユーザーインターフェイス（UI）コンポーネントには、グリッド、コントロールと呼ばれるボタン、およびユーティリティコンポーネントが含まれ、他のコンポーネントで使用される機能の特定のサブセットを公開します。
• 他の一般的なタイプのコンポーネントは、リソースを集中的に使用するものであり、頻繁にアクセスされないため、ジャストインタイム（JIT）アプローチを使用してアクティブ化する必要があります。
• エンタープライズJavaBean（EJB）、. NETコンポーネント、CORBAコンポーネントなどのエンタープライズビジネスアプリケーションやインターネットWebアプリケーションで配布される多くのコンポーネントは非表示です。

コンポーネントの特性

• 再利用性-コンポーネントは通常、さまざまなアプリケーションのさまざまな状況で再利用されるように設計されています。 ただし、一部のコンポーネントは特定のタスク用に設計されている場合があります。
• 交換可能-コンポーネントは、他の同様のコンポーネントと自由に置き換えることができます。
• コンテキスト固有ではありません-コンポーネントは、さまざまな環境およびコンテキストで動作するように設計されています。
• 拡張可能-コンポーネントを既存のコンポーネントから拡張して、新しい動作を提供できます。
• カプセル化された-コンポーネントは、呼び出し元がその機能を使用できるようにするインターフェイスを表し、内部プロセスまたは内部変数または状態の詳細を公開しません。
• 独立-コンポーネントは、他のコンポーネントに最小限の依存関係を持つように設計されています。

コンポーネントベースの設計の原則

コンポーネントレベルの設計は、何らかの中間表現を使用して表現できます（例： グラフィカル、表形式、またはテキストベース）。ソースコードに変換できます。 データ構造、インターフェイス、およびアルゴリズムの設計は、エラーの発生を回避するために確立されたガイドラインに準拠する必要があります。

• ソフトウェアシステムは、再利用可能な、まとまりのある、カプセル化されたコンポーネントユニットに分解されます。
• 各コンポーネントには、必要なポートと提供されたポートを指定する独自のインターフェイスがあります。各コンポーネントは、詳細な実装を隠します。
• コンポーネントは、コンポーネントの既存の部分に内部コードを作成したり、設計を変更したりせずに拡張する必要があります。
• 抽象化コンポーネントに依存することは、他の具体的なコンポーネントに依存しないため、消耗性が難しくなります。
• コネクタはコンポーネントを接続し、コンポーネント間の相互作用を指定および決定します。 対話タイプは、コンポーネントのインターフェースによって指定されます。
• コンポーネントの対話は、メソッド呼び出し、非同期呼び出し、ブロードキャスト、メッセージ駆動型対話、データストリーム通信、およびその他のプロトコル固有の対話の形式をとることができます。
• サーバークラスの場合、クライアントの主要なカテゴリにサービスを提供するための特別なインターフェイスを作成する必要があります。 クライアントの特定のカテゴリに関連する操作のみをインターフェイスで指定する必要があります。
• コンポーネントは他のコンポーネントに拡張でき、独自の拡張ポイントを提供できます。 これは、プラグインベースのアーキテクチャの概念です。 これにより、プラグインは別のプラグインAPIを提供できます。

コンポーネントベースの設計の原則

コンポーネントレベルの設計ガイドライン

アーキテクチャモデルの一部として指定されたコンポーネントの命名規則を作成し、コンポーネントレベルモデルの一部として洗練または詳細化します。

• 問題ドメインからアーキテクチャコンポーネント名を取得し、それらがアーキテクチャモデルを表示するすべての利害関係者に意味を持つようにします。
• 他のエンティティに関連する依存関係なしに独立して存在できるビジネスプロセスエンティティを抽出します。
• これらの独立したエンティティを新しいコンポーネントとして認識し、発見します。
• 実装固有の意味を反映するインフラストラクチャコンポーネント名を使用します。
• 依存関係を左から右へ、継承を上（基本クラス）から下（派生クラス）へとモデル化します。
• コンポーネントの依存関係は、コンポーネント間の直接の依存関係として表すのではなく、インターフェイスとしてモデル化します。

コンポーネントレベルの設計の実施

分析モデルおよびアーキテクチャモデルで定義された問題ドメインに対応するすべての設計クラスを認識します。

• インフラストラクチャドメインに対応するすべての設計クラスを認識します。
• 再利用可能なコンポーネントとして取得されないすべての設計クラスを説明し、メッセージの詳細を指定します。
• 各コンポーネントの適切なインターフェイスを識別し、属性を詳述し、それらを実装するために必要なデータ型とデータ構造を定義します。
• 擬似コードまたはUMLアクティビティ図を使用して、各操作内の処理フローを詳細に説明します。
• 永続データソース（データベースとファイル）について説明し、それらを管理するために必要なクラスを特定します。
• クラスまたはコンポーネントの動作表現を開発および詳述します。 これは、分析モデル用に作成されたUML状態図を作成し、設計クラスに関連するすべてのユースケースを調べることで実行できます。
• 展開図を作成して、追加の実装の詳細を提供します。
• クラスインスタンスを使用し、特定のハードウェアおよびオペレーティングシステム環境を指定することにより、システム内の主要なパッケージまたはコンポーネントのクラスの場所を示します。
• 最終的な決定は、確立された設計原則とガイドラインを使用して行うことができます。 経験豊富な設計者は、最終設計モデルに落ち着く前に、すべての（またはほとんどの）代替設計ソリューションを検討します。

利点

• 展開の容易さ-新しい互換バージョンが利用可能になると、他のコンポーネントやシステム全体に影響を与えることなく、既存のバージョンを簡単に置き換えることができます。
• コストの削減-サードパーティのコンポーネントを使用すると、開発とメンテナンスのコストを分散できます。
• 開発の容易さ-コンポーネントは、定義された機能を提供する既知のインターフェイスを実装し、システムの他の部分に影響を与えることなく開発を可能にします。
• 再利用可能-再利用可能なコンポーネントの使用は、複数のアプリケーションまたはシステムに開発および保守コストを分散するために使用できることを意味します。
• 技術的な複雑さの修正-コンポーネントは、コンポーネントコンテナとそのサービスを使用して複雑さを修正します。
• 信頼性-各コンポーネントの信頼性が再利用によりシステム全体の信頼性を高めるため、システム全体の信頼性が向上します。
• システムのメンテナンスと進化-残りのシステムに影響を与えることなく、簡単に実装を変更および更新できます。
• 独立-コンポーネントの独立性と柔軟な接続性。 異なるグループによるコンポーネントの独立した開発。 ソフトウェア開発と将来のソフトウェア開発の生産性。