POSA 本でアーキテクチャパターンを勉強しよう

• パターンとは何か？
• アーキテクチャパターン「混沌から構造へ」より「Layers（レイヤパターン）」
• アーキテクチャパターン「混沌から構造へ」より「Pipes and Filters」
• アーキテクチャパターン「混沌から構造へ」より「Blackboard」

どうも、あかさたです。前回は「Pipes and Filters」を紹介しました。今回は「混沌から構造へ」の最後のパターンである「Blackboard」を紹介します。POSA本で言うところの第2章に相当します。

混沌から構造へ - ブラックボード（Blackboard）

POSA本に書かれているブラックボード（Blackboard）はとらえにくいパターンです。このパターンの特徴は、ブラックボードと呼ばれる（ホワイトボードと呼ばれることもある）分散共有メモリシステムと、状態に応じて柔軟に戦略を選択するための制御コンポーネントが登場することです。両者を同時に説明しようとするとなかなか難しいところがあるので、一つずつ例を絡めて紹介します。

まずは、こちらも名著と名高い達人プログラマーで紹介されているホワイトボードというパターンを簡単に紹介します。このパターンは、ブラックボードのように柔軟な制御戦略を対象とはしていませんが、同様の分散共有メモリシステムが登場します。

もう一つは、レゴマインドストームを Java で制御するためのファームウェア leJOS で提供されているクラス Arbitrator と Behavior を紹介します。これらのクラスは制御するロボットの行動戦略を柔軟に定めるためのクラスです。（ちょうど、レゴを制御する記事も連載しているので、もしよろしければこちらもどうぞ。）

ホワイトボード（達人プログラマーより）

ホワイトボードパターンとは、ホワイトボードと呼ばれる共有のデータ構造上に、さまざまなサブシステムを組み合わせて処理を行うシステムです。ホワイトボードは分散共有メモリの一種です。実装としてはLindaが有名です。Lindaは、キーと値がセットになったタプルと呼ばれるデータを保持するタプルスペースと呼ばれています。

Lindaは、「データの取得（read）」「データの書き込み（write）」「データの取得と同時に削除（take）」「read, write, takeイベントの通知（notify）」などの責務を持ちます。ホワイトボードを採用したシステムは、ホワイトボードを中心に据えて、さまざまなサブシステムが協調動作することになります。

責務のnotifyについて補足します。あるサブシステムが、興味のあるキーに対して起こったread, write, takeイベントの発生を知りたいとします。ホワイトボードはイベントを通知する責務（notify）を持つため、そのサブシステムの要望に対応します。

※ read, write, take, notifyはLindaのJava実装と言えるJavaSpacesのメソッド名で、オリジナルのLindaとは異なります。このメソッド名はRuby実装のRindaでも用いられているため、ここではオリジナルではなくJavaSpacesのメソッド名で統一しました。詳細はこちらを参照してください。

notify に注目してください。あるサブシステムにとって必要なデータがホワイトボードに書き込まれたら、ホワイトボードは変更をそのサブシステムに通知します。一種のイベントドリブンであり、システム全体として処理が行われる順番があまり重要でない場合に配慮した仕組みになっていることに注目してください。（ホワイトボードを使って、順番が重要なパイプラインシステムの実装ができないわけでもありませんし、してはならないわけでもありませんが。）

Arbitrator と Behavior（leJOS より）

leJOS はレゴマインドストーム（LEGO MINDSTORMS）を制御するためのファームウェア（OS）です。Java でレゴで作ったロボットを制御できるのが特徴です。例として、地面に描かれた線を、光センサーで読み取りながら辿っていくロボットカー（ライントレーサ）を想像してください。線上に車がある場合は直進、線から車が外れた場合はその場で回転しながら線を探します。

図「ライントレーサの動作」

このような車には、「直進する」と「線を探す」という振る舞い（Behavior）が存在します。Behavior には、「条件部（takeControl メソッド）」と「実行部（action メソッド）」が存在します。条件部は、振る舞いを開始するかどうか判定します。実行部は振る舞いの内容を記述します。

Arbitrator は登録された Behavior の条件部を全て実行し、現在のシステムの状態に適合する Behavior を一つ選び出し、実行部を実行します。つまり、Arbitrator は Behavior の制御戦略を担うクラスです。複数適合する Behavior が存在する場合は、Arbitorator は優先度の高い Behavior を一つ選択します。優先度は、Behavior は配列で登録されるのですが、index の大きい順に優先度が高くなるように設定されています。

ブラックボード

ホワイトボードもブラックボードも「サブシステムが複数ある」「各サブシステムの実行順は一定とは限らない」「中心に（分散）共有メモリが存在する」という点において共通しています。従って、ホワイトボードを採用したシステムもブラックボードを採用したシステムも、同じような構造になるかもしれません。

両者の違いを端的に言えば、ホワイトボードは、ホワイトボードとそれを利用する複数のサブシステムから成り立っているのに対し、ブラックボードはサブシステムの活性化を制御するControlという要素が登場します。leJOS に Arbitrator というクラスが登場しましたが、やはり制御戦略を担うクラスです。本記事ではホワイトボードと leJOS の Arbitrator とブラックボードの違いに配慮しながら紹介を行います。