Software-architecture-design-interaction-oriented-architecture
インタラクション指向のアーキテクチャ
対話指向アーキテクチャの主な目的は、ユーザーの対話をデータ抽象化およびビジネスデータ処理から分離することです。 対話指向のソフトウェアアーキテクチャは、システムを3つの主要なパーティションに分解します-
- データモジュール-データモジュールは、データの抽象化とすべてのビジネスロジックを提供します。
- 制御モジュール-制御モジュールは、制御およびシステム構成アクションのフローを識別します。
- * Viewプレゼンテーションモジュール*-Viewプレゼンテーションモジュールは、データ出力の視覚的または音声的プレゼンテーションを担当し、ユーザー入力用のインターフェイスも提供します。
対話指向アーキテクチャには、 Model-View-Controller （MVC）および Presentation-Abstraction-Control （PAC）の2つの主要なスタイルがあります。 MVCとPACはどちらも3つのコンポーネントの分解を提案し、複数のトークとユーザーの対話を伴うWebアプリケーションなどの対話型アプリケーションに使用されます。 制御と組織の流れが異なります。 PACはエージェントベースの階層アーキテクチャですが、MVCには明確な階層構造がありません。
モデルビューコントローラ（MVC）
MVCは、特定のソフトウェアアプリケーションを3つの相互接続された部分に分解します。これは、ユーザーに提示または受け入れられた情報から情報の内部表現を分離するのに役立ちます。
| Module | Function |
|---|---|
| Model | Encapsulation the underlying data and business logic |
| Controller | Respond to user action and direct the application flow |
| View | Formats and present the data from model to user. |
モデル
モデルは、アプリケーションのデータ、ロジック、および制約を直接管理するMVCの中心的なコンポーネントです。 これは、生のアプリケーションデータとインターフェイスのアプリケーションロジックを保持するデータコンポーネントで構成されます。
- 独立したユーザーインターフェイスであり、アプリケーションの問題ドメインの動作をキャプチャします。
- ドメイン固有のソフトウェアシミュレーションまたはアプリケーションの中心構造の実装です。
- 状態が変更されると、関連するビューに通知を送信して更新された出力を生成し、コントローラーが使用可能なコマンドのセットを変更します。
View
ビューを使用すると、ダイアグラムやチャートなどのグラフィック形式で情報の出力を表すことができます。 データの視覚的表現を提供するプレゼンテーションコンポーネントで構成されます
- ビューはモデルから情報を要求し、ユーザーへの出力表現を生成します。
- 管理用の棒グラフや会計士用の表形式ビューなど、同じ情報の複数のビューが可能です。
コントローラ
コントローラーは入力を受け入れ、それをモデルまたはビューのコマンドに変換します。 これは、モデルを変更してユーザーからの入力を処理する入力処理コンポーネントで構成されています。
- これは、関連するモデルとビュー、および入力デバイス間のインターフェースとして機能します。
- モデルにコマンドを送信してモデルの状態を更新し、モデルに関連付けられたビューにコマンドを送信して、モデルのビューの表示を変更できます。
MVC-I
これは、システムが2つのサブシステムに分割されているMVCアーキテクチャのシンプルなバージョンです-
- コントローラービュー-コントローラービューは、入力/出力インターフェイスとして機能し、処理が行われます。
- モデル-モデルはすべてのデータおよびドメインサービスを提供します。
- MVC-Iアーキテクチャ*
モデルモジュールは、データの変更をコントローラービューモジュールに通知し、それに応じてグラフィックデータの表示が変更されるようにします。 コントローラーは、変更時に適切なアクションも実行します。
コントローラービューとモデル間の接続は、subscribe-notifyのパターンで設計することができます（上の図を参照）。これにより、コントローラービューがモデルにサブスクライブし、モデルがコントローラービューに変更を通知します。
MVC-II
MVC–IIは、ビューモジュールとコントローラーモジュールが分離されているMVC-Iアーキテクチャの拡張機能です。 モデルモジュールは、データベースでサポートされるすべてのコア機能とデータを提供することにより、MVC-Iと同様に積極的な役割を果たします。
ビューモジュールはデータを提示し、コントローラーモジュールは入力要求を受け入れ、入力データを検証し、モデル、ビュー、それらの接続を開始し、タスクをディスパッチします。
- MVC-IIアーキテクチャ*
MVCアプリケーション
MVCアプリケーションは、単一のデータモデルに複数のビューが必要で、新しいインターフェイスビューまたは変更インターフェイスビューを簡単にプラグインできるインタラクティブなアプリケーションに効果的です。
MVCアプリケーションは、モジュール間に明確な区分があるアプリケーションに適しているため、さまざまな専門家をそのようなアプリケーションのさまざまな側面で同時に作業するように割り当てることができます。
メリット
- 多くのMVCベンダーフレームワークツールキットが利用可能です。
- 複数のビューが同じデータモデルと同期しました。
- 新しいプラグインまたはインターフェースビューを簡単にプラグインできます。
- グラフィックの専門家、プログラミングの専門家、データベース開発の専門家が設計されたプロジェクトチームで作業しているアプリケーション開発に使用されます。
デメリット
- インタラクティブなモバイルアプリケーションやロボットアプリケーションなど、エージェント指向のアプリケーションには適していません。
- 同じデータモデルに基づいたコントローラーとビューの複数のペアは、データモデルの変更に費用がかかります。
- ビューとコントローラーの区分が明確でない場合があります。
プレゼンテーション抽象化制御（PAC）
PACでは、システムは多くの協力エージェント（トライアド）の階層に配置されます。 インタラクティブな要件に加えて、複数のエージェントのアプリケーション要件をサポートするためにMVCから開発されました。
各エージェントには3つのコンポーネントがあります-
- プレゼンテーションコンポーネント-データの視覚および音声プレゼンテーションをフォーマットします。
- 抽象化コンポーネント-データを取得して処理します。
- 制御コンポーネント-他の2つのコンポーネント間の制御および通信のフローなどのタスクを処理します。
PACアーキテクチャは、プレゼンテーションモジュールがMVCのビューモジュールに似ているという意味で、MVCに似ています。 抽象化モジュールはMVCのモデルモジュールに似ており、制御モジュールはMVCのコントローラーモジュールに似ていますが、制御と編成のフローが異なります。
各エージェントの抽象化コンポーネントとプレゼンテーションコンポーネントの間には直接的な接続はありません。 各エージェントの制御コンポーネントは、他のエージェントとの通信を担当します。
次の図は、PAC設計の単一エージェントのブロック図を示しています。
複数のエージェントを使用したPAC
複数のエージェントで構成されるPACでは、トップレベルのエージェントがコアデータとビジネスロジックを提供します。 最下層のエージェントは、詳細な特定のデータとプレゼンテーションを定義します。 中レベルまたは中レベルのエージェントは、低レベルのエージェントのコーディネーターとして機能します。
- 各エージェントには、固有の割り当てられたジョブがあります。
- 一部の中間レベルのエージェントでは、インタラクティブなプレゼンテーションが必要ないため、プレゼンテーションコンポーネントがありません。
- 制御コンポーネントは、すべてのエージェントが互いに通信するためのすべてのエージェントに必要です。
次の図は、PACに参加する複数のエージェントを示しています。
アプリケーション
- システムを階層的な方法で多くの協調エージェントに分解できるインタラクティブシステムに効果的です。
- エージェントの変更が他に影響を与えないように、エージェント間の結合が緩いと予想される場合に効果的です。
- すべてのエージェントが遠くに分散しており、各エージェントがデータと対話型インターフェースを備えた独自の機能を持つ分散システムに効果的です。
- それぞれが独自の現在のデータと対話型インターフェースを保持し、他のコンポーネントと通信する必要があるリッチGUIコンポーネントを備えたアプリケーションに適しています。
利点
- マルチタスクとマルチビューのサポート
- エージェントの再利用性と拡張性のサポート
- 新しいエージェントのプラグインや既存のエージェントの変更が簡単
- 異なるスレッドまたは異なるデバイスまたはコンピューターで複数のエージェントが並行して実行されている並行性のサポート
デメリット
- プレゼンテーションと抽象化の間のコントロールブリッジ、およびエージェント間のコントロールの通信によるオーバーヘッド。
- 疎結合とエージェント間の高い独立性のため、エージェントの適切な数を決定するのが困難です。
- エージェント間の通信はエージェントのコントロール間でのみ行われるため、各エージェントのコントロールによるプレゼンテーションと抽象化の完全な分離により、開発の複雑さが生じます。
