読者です 読者をやめる 読者になる 読者になる

【アーキテクチャパターン】POSA Vol.1のPresentation-Abstraction-Control

Presentation-Abstraction-Controlアーキテクチャパターン(PAC)は,協調するエージェントの階層と言う形で,対話型ソフトウェアシステムのための構造を定義する.このエージェントはその1つずつがアプリケーション機能の特定の一面を実現する責務を負っており,3つの部分から構成される.3つの部分とは,Presentationコンポーネント,Abstractionコンポーネント,Controlコンポーネントである.これらのコンポーネントへ分割することにより,エージェントの機能中核部分や他のエージェントとの通信から,人間とコンピュータの対話機能が分離される.

前提

エージェントを利用する対話型システムの開発

課題

協調するエージェントから構成されるアーキテクチャでは,各エージェントが特別なタスクを専門的に行うよう定義される. このエージェントの協働によりシステム全体の機能を提供する. このアーキテクチャでは水平分割と垂直分割が行われる.

フォースを見てみる.

  • エージェントが自身の状態とデータを保持している
  • 対話型エージェントのそれぞれが,独自のインターフェースを提供する
  • 時間経過により,システムが拡張される.

解決策

対話型アプリケーションをPACエージェントからなる木構造化する.

  • トップレベルに一つのエージェント
  • 中間レベルに複数のエージェント
  • ボトムレベルにはそれよりも数の多いエージェント

とする. 各エージェントそれぞれアプリ機能の一部を分担する. 各エージェントは3つの下記コンポーネントを持つ.

  • Presentation
    • エージェントの振る舞いを可視化
  • Abstraction
    • エージェントが実現するデータモデルを管理
  • Control
    • PresentationとAbstractionの接続
    • エージェントが他のPACエージェントと通信する機能の提供

各エージェントは,木構造の自分より上位のエージェント全てに依存する.

f:id:yusuke_ujitoko:20161118221445p:plain この政治選挙システム例では,

  • トップレベルエージェント
    • data repository
  • 中間レベルエージェント
    • view coordinator
  • ボトムレベルエージェント
    • spreadsheet
    • pie chart
    • bar chart
    • seat distribution

ユーザはspreadsheetに対してデータ入力し,pie chartやbar chartなどがビューの役割を果たす. view coordinatorは3つのビューエージェントを管理する. spreadsheetはトップレベルエージェントと直接のリンクを持つ.

静的側面

トップレベルエージェント

f:id:yusuke_ujitoko:20161118223712p:plain:w500

システムの機能中核となる部分を提供する. その他のPACエージェントは,このエージェントに依存し,このエージェントを操作するもの.

複数の責務を持つことが多い.

  • Presentation
    • システム共通のUIを提供する
  • Abstraction
    • グローバルモデルを維持管理する
  • Control
    • 下位のエージェントに対して,トップレベルエージェントが提供するサービスを利用できるようにする.
    • PACエージェントの階層を調整する
    • ユーザとシステムの相互作用についての情報を維持管理する

ボトムレベルエージェント

f:id:yusuke_ujitoko:20161118223729p:plain:w500

自己完結的な意味的概念を表現する システムのユーザはその概念に対してアクションを行う.

  • Presentation
    • 意味的概念に対する1つのビューを提供する
  • Abstraction
    • エージェント固有のデータを管理する
  • Control
    • AbstractionとPresentationの一貫性を維持する

中間レベルエージェント

f:id:yusuke_ujitoko:20161118223740p:plain:w500

自分よりも下位に位置するエージェントの組み合わせや,そのようなエージェント間の関係を表現する.

動的側面

シナリオ1

新しいビューを開く.

f:id:yusuke_ujitoko:20161118225311p:plain

  • ユーザがViewCoordinatorに対してBarchartを開くようリクエストを送ると,そのインスタンスが生成される
  • ボトムレベルエージェントがトップレベルエージェントからデータを取得する際には,中間レベルエージェントが仲介する.

シナリオ2

新しいデータの入力.

f:id:yusuke_ujitoko:20161118225828p:plain

  • ユーザがspreadsheetに書き込む
  • トップレベルエージェントにデータ転送し,トップレベルのabstractionコンポーネントを更新する. その更新通知をすべてのエージェントに送る.

実装

  1. アプリケーションのモデルを定義する。
  2. PAC階層を組織的に作成するための汎用戦略を定義する。
  3. トップレベルエージェントを設計する。
  4. ボトムレベルエージェントを設計する。
  5. システムサービスを行うボトムレベルエージェントを特定する。
  6. 下位に位置するPACエージェントから構成される中間レベルエージェントを設計する。
  7. 下位に位置するPACエージェントを調整する役割を持つ中間レベルエージェントを設計する。
  8. 中核機能とヒューマン-コンピュータ相互作用を分離する。
  9. 外部インタフェースを提供する。
  10. 階層をリンクする。

バリエーション

以下の2つのPACのバリエーションでは,マルチタスクの実現というフォースを解決している.

  • アクティブオブジェクトとしてのPACエージェント
  • プロセスとしてのPACエージェント

適用例

結論

PACパターンの利点

  • 関心の分離
    • 意味的概念をエージェントで分けられる
  • 変更と拡張の支援
  • マルチタスクの支援

PACパターンの欠点

yusuke-ujitoko.hatenablog.com