现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.
システムアーキテクチャ設計・コンポーネントおよびミドルウェア技術における高度なスキル
1. コンポーネントの定義
定義 1:ソフトウェア コンポーネントは、標準化されたインターフェイス仕様と明示的なコンテキスト依存関係を持つアセンブリ単位です。ソフトウェア コンポーネントは独立して展開でき、サードパーティが自由に組み立てることができます。
定義 2:コンポーネントは、明確に定義されたアーキテクチャのコンテキスト内で明確な機能を果たす、システムの貴重なほぼ独立した交換可能な部分です。
定義 3:コンポーネントは、そのインターフェイスを通じてそのサービスにアクセスできる、独立して公開された機能部分です。
アーティファクトは、通常は同時にデプロイする必要があるアトミック コンポーネントのセットです。
コンポーネントとアトミック コンポーネントの違いは、アトミック コンポーネントは個別にデプロイできますが、ほとんどのアトミック コンポーネントは個別にデプロイされないことです。対照的に、ほとんどのアトミック コンポーネントはコンポーネント ファミリに属しており、展開には多くの場合ファミリー全体が関係します。
アトミック コンポーネントは、モジュールとリソースのセットです。
アトミック コンポーネントは、展開、バージョン管理、および置換の基本単位です。アトミック コンポーネントは通常、グループにデプロイされますが、個別にデプロイすることもできます。モジュールは個別のリソースを持たないアトミックなコンポーネントです(この厳密な定義では、Java パッケージはモジュールではありません。Java でのデプロイメントのアトミックな単位はクラス ファイルです。単一のパッケージは、複数の個別のクラス ファイルにコンパイルされます。それぞれが共通です)クラスには 1 つあります)。
モジュールはクラスのセットであり、場合によってはプロシージャや関数などの非オブジェクト指向構造です。
モジュール、オブジェクト、コンポーネントの違いは次のとおりです。
コンポーネントの特徴は、(1) 独立した展開単位、(2) サードパーティとしての組み立て単位、(3) (外部に) 可視状態がないことです。(コンテナを使用して、その外部の表示状態を管理できます)
コンポーネントには複数のクラス要素を含めることができますが、クラス要素は 1 つのコンポーネントにのみ属することができます。デプロイメントのためにクラスを分割することは、通常は意味がありません。
オブジェクトの特徴は次のとおりです。 (1) 一意の識別子を持つインスタンス ユニット。(2) 外観から見える状態がある場合があります。(3) 自身のステータスと
動作をカプセル化します。
2. コンポーネントシステムのアーキテクチャの特徴
コンポーネントシステム アーキテクチャは、一連のプラットフォーム決定、一連のコンポーネント フレームワーク、およびコンポーネント フレームワーク間の相互運用性の設計で構成されます。
コンポーネントフレームワークは、専用のアーキテクチャ (通常はいくつかの主要なメカニズムを中心とする) であり、コンポーネント レベルのメカニズムに固定的に作用する一連の戦略です。
概念的なフレームワークの相互運用性の設計には、システム アーキテクチャによって接続されているすべてのフレームワーク間の相互運用性のルールが含まれています。
コンポーネントは、通常は同時にデプロイする必要があるアトミック コンポーネントのセットです。コンポーネントとアトミック コンポーネントの違いは、アトミック コンポーネントは個別にデプロイできますが、ほとんどのアトミック コンポーネントは個別にデプロイされないことです。
アトミック コンポーネントはモジュールとリソースのセットです。
モジュールはクラスのセットであり、場合によってはプロシージャや関数などの非オブジェクト指向構造も含まれます。
リソースは、型指定された項目の固定されたコレクションです。
口リソースの概念には、コード リソース、つまりモジュールが含まれる場合があります。問題は、モジュールまたはパッケージのコンパイル時にコンパイラーによって生成されるリソースに加えて、他のリソースが存在する可能性があることです。「純粋なオブジェクト」アプローチでは、リソースは外部の不変オブジェクトです。コンポーネントには永続化フラグがなく、コピーを区別できないため、不変です。
ソフトウェアシステムをコンポーネントの集合とみなすと、システムを構成するコンポーネントはコンポーネントの外形から 【5つのカテゴリ】に分類できます。
(1)独立した成熟したコンポーネント。独立した成熟したコンポーネントは実際の動作環境で何度もテストされており、このタイプのコンポーネントはすべてのインターフェイスを非表示にし、ユーザーは所定のコマンドを使用するだけで済みます。たとえば、データベース管理システムやオペレーティング システムなどです。
(2)制限されたコンポーネント。制限されたコンポーネントは、インターフェイスを提供し、使用の条件と前提条件を示します。このタイプのコンポーネントは、組み立て時にリソースの競合、カバレッジ、その他の影響があり、使用時にテストする必要があります。たとえば、さまざまなオブジェクト指向プログラミング言語の基本クラス ライブラリです。
(3)適応可能なコンポーネント。適応可能なコンポーネントはパッケージ化されるか、インターフェース技術を使用して非互換性やリソースの競合などに対処し、直接使用できます。このコンポーネントは、さまざまな環境で変更せずに使用できます。たとえばActiveXなど。
(4)組み立て部品。アセンブリのコンポーネントがインストールされると、オペレーティング システム、データベース管理システム、または情報システムのさまざまなレベルで組み立てられ、グルー コードを使用して接続して使用できます。現在、一部のソフトウェア ベンダーによって提供されているほとんどのソフトウェア製品は、このカテゴリに分類されます。
(5)変更可能なコンポーネント。 変更可能なコンポーネントはバージョンに置き換えることができます。エラーが修正されたり、元のコンポーネントに新しい機能が追加された場合は、再パッケージ化するかインターフェイスを作成することでコンポーネントを置き換えることができます。この種のコンポーネントは、アプリケーション システム開発で頻繁に使用されます。
3. ミドルウェアの概要
ミドルウェアは、分散アプリケーション ソフトウェアが異なるテクノロジー間でリソースを共有するのに役立つ独立したシステム ソフトウェアまたはサービス プログラムです。ミドルウェアは次のことができます。
1. クライアントとサーバー間の接続と通信、およびクライアントとアプリケーション層間の効率的な通信メカニズムを担当します。
2. アプリケーションの負荷分散と高可用性、セキュリティ メカニズムと管理機能、さらにトランザクションの一貫性を確保するためのトランザクション管理メカニズムを提供します。
3. アプリケーション層の異なるサービス間の相互運用性メカニズム、およびアプリケーション層とデータベース間の接続および制御メカニズムを提供します。
4. マルチレイヤ アーキテクチャのアプリケーション開発および運用プラットフォームと、モジュール型アプリケーション開発をサポートするアプリケーション開発フレームワークを提供します。
5. ハードウェア、オペレーティング システム、ネットワーク、データベースの違いを保護します。
6. 作業の重複を避け、アプリケーション間のコラボレーションを可能にするために、さまざまな機能を実行するための共通サービスのセットを提供します。
ミドルウェアはコンポーネントの一種です。
ミドルウェアはシステムソフトウェアの一種です。
構造を簡素化し、相違点を保護し、再利用を容易にします。
ミドルウェア技術を使用する利点:
- (1)需要志向。つまり、デザイナーはビジネス ロジック自体に焦点を当てます。
- (2)ビジネスの分離と包括。アプリケーション開発者は、さまざまなビジネスに応じて機能を分割でき、それがさまざまなインターフェイスや対話モードに反映されます。
- (3)設計と実装の分離。コンポーネントの外部効果やコンポーネント間の相互作用はすべてインターフェイスを通じて実行されます。コンポーネントのユーザーはコンポーネントのインターフェイスを知るだけでよく、内部実装について気にする必要はありません。これが設計と実装を分離するための鍵です。 。
- (4)複雑なシステムリソースを分離します。このアーキテクチャの非常に重要な機能は、システム リソースをアプリケーション コンポーネントから分離することであり、これはコンポーネントの再利用、さらには「プラグ アンド プレイ」が可能であることを保証するための基礎であり、ミドルウェアの意図と一致しています。
- (5)標準に準拠した対話モデル。ミドルウェアはアーキテクチャ モデルを実装し、標準プロトコルを実装します。
- (7)ソフトウェアの再利用。ミドルウェアは、コンポーネントのカプセル化、対話ルール、環境からの分離、およびその他のメカニズムを提供し、ソフトウェアを再利用するための便利なソリューションを提供します。
- (8)アプリケーションコンポーネントの管理を提供します。ミドルウェアベースのソフトウェアは、コンポーネントを識別メカニズムを通じて常に分割できるため、管理が容易です。
4. CBSDコンポーネントベースモデル（コンポーネントアセンブリモデル/コンポーネントベースのソフトウェア開発）
コンポーネント (Component) は、再利用可能な価値と比較的独立した機能を備えたソフトウェア単位です。コンポーネントベースのソフトウェア開発 (CBSD) モデルは、モジュール化手法を使用してシステム全体をモジュール化し、特定のコンポーネント モデルのサポートを受けて、コンポーネント ライブラリ内の 1 つまたは複数のソフトウェア コンポーネントを組み合わせ手段によって再利用します。高効率と高品質を実現します。
コンポーネントベースの開発モデルには、スパイラル モデルの多くの特徴が組み込まれており、本質的に進化的であり、開発プロセスは反復的です。コンポーネントベースの開発モデルは、ソフトウェア要件の分析と定義、アーキテクチャ設計、コンポーネント ライブラリの確立 (コンポーネント ライブラリにはコンポーネントの取得とコンポーネントの管理が含まれます)、アプリケーション ソフトウェアの構築、テストとリリースの 5 つの段階で構成されます。図に示すように:
CBSE コンポーネントには次の特性が必要です。
- アセンブリ可能性: すべての外部対話は、公的に定義されたインターフェイスを通じて発生する必要があります。
- 導入可能性: コンポーネントは常にバイナリ形式であり、プラットフォーム上で独立したエンティティとして実行できます。
- ドキュメント: ユーザーはコンポーネントが要件を満たしているかどうかをドキュメントに基づいて判断します。
- 独立性: 他の特別なコンポーネントを使用せずに組み立てて展開できます。
- 標準化: 特定の規格に準拠したコンポーネント モデル。
CBSE コンポーネントの組み立て順序:
- 順次アセンブリ: 既存のコンポーネントを順番に呼び出します。2 つの既存のコンポーネントを使用して、新しいコンポーネントを作成できます。
- 階層アセンブリ: 呼び出されるコンポーネントの「提供された」インターフェイスは、呼び出し側コンポーネントの「要求」インターフェイスと互換性がある必要があります。
- オーバーレイ アセンブリ: 複数のコンポーネントを結合して新しいコンポーネントを形成します。新しいコンポーネントは、元のコンポーネントの機能を統合し、外部世界への新しいインターフェイスを提供します。
重要なソフトウェア技術およびツールとして、コンポーネントは大幅に開発されており、これらの新しい技術標準およびツールには、Microsoft の DCOM/COM、Sun の EJB、OMG の CORBA などが含まれます。コンポーネントベースの開発活動は、コンポーネントの候補を特定することから始まります。既存のコンポーネント ライブラリを検索して、必要なコンポーネントが既に存在するかどうかを確認します。既に存在する場合はコンポーネント ライブラリから抽出して再利用し、存在しない場合はオブジェクトを使用します。指向性のあるメソッドを開発します。抽出されたコンポーネントが構文チェックとセマンティック チェックに合格した後、これらのコンポーネントはグルー コードを通じて組み立てられ、システムが実装されます。このプロセスは反復的です。
コンポーネントベース開発手法では、ソフトウェア開発をゼロから開始する必要がなくなり、開発プロセスはコンポーネントの組み立てプロセスであり、保守プロセスはコンポーネントのアップグレード、交換、拡張のプロセスであり、コンポーネントの組み立てモデルが次のことにつながるという利点があります。ソフトウェアの再利用と改善ソフトウェア開発の効率が向上します。コンポーネントは一方の当事者によって定義され、別の当事者によって実装され、その後、使用するために第三者に提供されます。コンポーネント アセンブリ モデルにより、複数のプロジェクトを同時に開発できるため、コストが削減され、改善されます。保守性が向上し、ソフトウェア製品を段階的に提出できるようになります。
欠点は、カスタマイズされたアセンブリ構造標準を使用しているため、普遍的なアセンブリ構造標準が欠如しており、導入にはリスクがあり、再利用性とソフトウェア効率を調整するのが容易ではなく、有能で経験豊富なアナリストと開発者が必要であることです。開発者が関与できない場合、顧客満足度は低くなり、コンポーネントに過度に依存し、コンポーネント ライブラリの品質が製品の品質に影響を及ぼします。
コンポーネントのアセンブリとは、コンポーネント ライブラリ内のコンポーネントを適切な修正後に相互に接続するか、現在の開発プロジェクト内のコンポーネント要素に接続して、最終的に新しいターゲット ソフトウェアを形成することを指します。
部品組立技術は、機能ベースの組立技術、データベースの組立技術、オブジェクト指向組立技術に大別されます。
5. コンポーネントの再利用
レベルは、コンポーネントの組み立てプロセスのさまざまなタスクに対応します。
再利用の
次元 水平再利用：業界分野を問わず普遍的。
垂直再利用: 業界分野に分割され、専用化されます。
5.1 コンポーネントの検索と抽出
既存のコンポーネント分類方法は、キーワード分類、ファセット分類、およびハイパーテキスト編成方法という 3 つの主要なカテゴリに分類できます。
-
キーワード分類:コンポーネントライブラリを編成する最も単純な方法であり、その基本的な考え方は、ドメイン分析の結果に従って、アプリケーション分野の概念を抽象から具体の順にツリー構造または有向非巡回グラフ構造に分解することです。各概念は、説明的なキーワードによって表されます。非分解可能なアトミック キーには、それに属する特定の構成要素が含まれています。
-
ファセット分類手法：ファセット分類の仕組みでは、部品の特性を記述するために使用される多数の「ファセット」（ファセット）が定義され、各ファセットにはいくつかの概念が含まれており、これらの概念は部品の特性を表面上に表現します。説明では、コンポーネントが実行する機能、コンポーネントが操作するデータ、コンポーネントが使用されるコンテキスト、またはその他の特性を説明できます。
-
ハイパーテキスト編成方法:ハイパーテキスト編成方法は、データベース システムに基づくコンポーネント ライブラリの編成方法とは異なります。全文検索テクノロジに基づいています。主な考え方は次のとおりです。すべてのコンポーネントは、詳細な機能または動作の説明文書によって補足されなければなりません。重要です。説明に現れる概念やコンポーネントはネットワークリンクの形で相互に接続されており、文書を読む過程で、検索者は人間の接触思考に従って、関連する概念やコンポーネントを含む文書にジャンプできます。全文検索システムユーザーが指定したキーワードと説明ドキュメントを組み合わせます。テキストを照合して、ブラウズ形式のコンポーネントの検索を実現します。
5.2 コンポーネントの理解と評価
5.3 コンポーネントの変更
5.4 コンポーネントの組み立て
システム コンポーネントのアセンブリは、カスタマイズ、統合、拡張の 3 つの異なるレベルに分かれています。これら 3 つのレベルは、コンポーネントの組み立てプロセスにおけるさまざまなタスクに対応します。
6. 成分規格
7. 主なミドルウェア
サーバント: CORBA オブジェクトの実際の実装。クライアント要求を完了する役割を果たします。
オブジェクト アダプタ: ORB カーネルの実装の詳細を保護し、サーバー オブジェクトの実装者が ORB 内の特定の関数を使用できるように抽象インターフェイスを提供するために使用されます。
オブジェクト リクエスト ブローカー: 呼び出しを解釈し、リクエストを実装するオブジェクトを検索し、見つかったオブジェクトにパラメータを渡し、結果を返すメソッドを呼び出します。クライアントは、サービス オブジェクトの場所、通信方法、実装、アクティブ化、または保存メカニズムを知る必要はありません。
CORBA システムの主な内容には次の部分が含まれます。
- (1)オブジェクト リクエスト ブローカー (ORB)。分散環境でリクエストと応答を透過的に送受信するオブジェクトを担当し、分散オブジェクト アプリケーションを構築し、異種環境または同種環境でアプリケーション間の相互運用性を実現するための基礎となります。
- (2)オブジェクトサービス。オブジェクトの使用と実装のために提供される基本オブジェクトのコレクション。これらのサービスはアプリケーション ドメインから独立している必要があります。
- (3)一般的なファシリタイツ。システム管理、結合ドキュメント、電子メールなど、一連の共有サービス インターフェイスをエンド ユーザーに提供します。
- (4)アプリケーションインターフェイス。インターフェイスを制御するベンダーによって提供される製品は、従来のアプリケーション層表現に対応しており、参照モデルの最上位にあります。
- (5)ドメインインターフェース。PDM システム用に OMG 組織によって開発された仕様など、アプリケーション ドメイン サービスに提供されるインターフェイス。