Software-architecture-design-data-centered-architecture

提供:Dev Guides
移動先:案内検索

データ中心のアーキテクチャ

データ中心のアーキテクチャでは、データは集中化され、データを変更する他のコンポーネントによって頻繁にアクセスされます。 このスタイルの主な目的は、データの完全性を実現することです。 データ中心のアーキテクチャは、共有データリポジトリを介して通信するさまざまなコンポーネントで構成されています。 コンポーネントは共有データ構造にアクセスし、比較的独立しています。つまり、データストアを介してのみ対話します。

データ中心アーキテクチャの最もよく知られている例は、データベースアーキテクチャです。このアーキテクチャでは、共通のデータベーススキーマがデータ定義プロトコルで作成されます。たとえば、RDBMSのフィールドとデータタイプを持つ関連テーブルのセットです。

データ中心のアーキテクチャのもう1つの例は、共通のデータスキーマ(つまり、 Webのメタ構造)およびハイパーメディアデータモデルに準拠し、プロセスは共有Webベースのデータサービスを使用して通信します。

データ中心のアーキテクチャ

コンポーネントの種類

コンポーネントの2種類があります-

  • *中央データ*構造またはデータストアまたはデータリポジトリ。永続的なデータストレージを提供します。 現在の状態を表します。
  • 中央データストアで動作し、計算を実行し、結果を戻す可能性のある*データアクセサー*または独立したコンポーネントのコレクション。

データアクセサー間の相互作用または通信は、データストアを介してのみ行われます。 データは、クライアント間の通信の唯一の手段です。 制御の流れは、アーキテクチャを2つのカテゴリに区別します-

  • リポジトリアーキテクチャスタイル
  • 黒板のアーキテクチャスタイル

リポジトリアーキテクチャスタイル

リポジトリアーキテクチャスタイルでは、データストアはパッシブであり、データストアのクライアント(ソフトウェアコンポーネントまたはエージェント)はアクティブであり、ロジックフローを制御します。 関与するコンポーネントは、データストアの変更を確認します。

  • クライアントはアクションを実行するためにシステムにリクエストを送信します(例: データを挿入)。
  • 計算プロセスは独立しており、着信要求によってトリガーされます。
  • トランザクションの入力ストリーム内のトランザクションのタイプが実行するプロセスの選択をトリガーする場合、それは従来のデータベースまたはリポジトリアーキテクチャ、またはパッシブリポジトリです。
  • このアプローチは、DBMS、ライブラリ情報システム、CORBAのインターフェイスリポジトリ、コンパイラ、およびCASE(コンピューター支援ソフトウェアエンジニアリング)環境で広く使用されています。

リポジトリアーキテクチャスタイル

利点

  • データの整合性、バックアップおよび復元機能を提供します。
  • エージェントは相互に直接通信しないため、エージェントのスケーラビリティと再利用性を提供します。
  • ソフトウェアコンポーネント間の一時データのオーバーヘッドを削減します。

デメリット

  • 障害に対してより脆弱であり、データの複製または複製が可能です。
  • データストアのデータ構造とそのエージェント間の高い依存関係。
  • データ構造の変更は、クライアントに大きな影響を与えます。
  • データの進化は難しく、高価です。
  • 分散データのためにネットワーク上でデータを移動するコスト。

黒板のアーキテクチャスタイル

Blackboard Architecture Styleでは、データストアはアクティブであり、クライアントはパッシブです。 したがって、論理フローはデータストアの現在のデータステータスによって決定されます。 中央のデータリポジトリとして機能する黒板コンポーネントがあり、さまざまな計算要素によって内部表現が構築および実行されます。

  • 共通のデータ構造で独立して動作する多くのコンポーネントが黒板に保存されます。
  • このスタイルでは、コンポーネントは黒板を介してのみ相互作用します。 データストアは、データストアが変更されるたびにクライアントに警告します。
  • ソリューションの現在の状態は黒板に保存され、処理は黒板の状態によってトリガーされます。
  • データに変更が発生すると、システムは*トリガー*と呼ばれる通知とデータをクライアントに送信します。
  • このアプローチは、特定のAIアプリケーションや、音声認識、画像認識、セキュリティシステム、ビジネスリソース管理システムなどの複雑なアプリケーションに見られます。
  • 中央データ構造の現在の状態が実行するプロセスを選択する主なトリガーである場合、リポジトリは黒板であり、この共有データソースはアクティブなエージェントです。
  • 従来のデータベースシステムとの大きな違いは、黒板アーキテクチャの計算要素の呼び出しは、外部入力ではなく、黒板の現在の状態によってトリガーされることです。

黒板モデルの部品

通常、黒板モデルには3つの主要な部分があります-

ナレッジソース(KS)

ナレッジソースは、*リスナー*または*購読者*とも呼ばれ、別個の独立したユニットです。 問題の一部を解決し、部分的な結果を集計します。 知識ソース間の相互作用は、黒板を通じて一意に行われます。

  • Blackboardデータ構造*

問題解決状態データは、アプリケーション依存の階層に編成されます。 知識源は黒板に変更を加え、それが徐々に問題の解決につながります。

コントロール

コントロールはタスクを管理し、作業状態をチェックします。

Blackboardデータ構造

利点

  • 簡単に追加または更新できるナレッジソースを提供するスケーラビリティを提供します。
  • すべてのナレッジソースが互いに独立しているため、並行して動作できる並行性を提供します。
  • 仮説の実験をサポートします。
  • ナレッジソースエージェントの再利用性をサポートします。

デメリット

  • 黒板と知識ソースの間に密接な依存関係が存在するため、黒板の構造変更はそのすべてのエージェントに大きな影響を与える可能性があります。
  • おおよその解決策のみが予想されるため、推論をいつ終了するかを決定することは困難です。
  • 複数のエージェントの同期の問題。
  • システムの設計とテストにおける主要な課題。