3.1. Swarmにおけるactivityライブラリの役割

activityライブラリは、Swarmにおける動的なオブジェクト指向シミュレーションの土台を提供します。Swarmでは、シミュレートする世界の構造に関するオブジェクト指向表現は、ユーザが定義することとされます。いったんそのような表現が確立されれば、その中での情報の流れや状態の変化については、activityライブラリのコンポーネントが責任を持ってすべて生成します。これらの状態の変化は厳密にコントロールされ、モデルの適切な時刻、適切な場所でそれが発生するようにしなければなりません。activityライブラリは、このようなコントロールを確立するメカニズムを提供します。

動的なモデルのシミュレーションが始まれば、モデルに発生するすべての事柄は、activityライブラリコンポーネントが世界オブジェクトに送るメッセージの直接的な結果として発生します。また、これらのコンポーネントはオブジェクトによって表現されます。コンポーネントを表現するにはそれが最も効果的な手段だからですが、その目的はシミュレートする世界の現在の状態を表すことではありません。目的は、正当な順番にメッセージを送ることによって、世界のオブジェクトに変化を生成することです。activityライブラリのコンポーネントは、2つの基礎的なカテゴリに分かれます。1つは送られるべきメッセージを表現するコンポーネントのカテゴリで(それらを送る順番の制約を含む)、もう1つはこれらの表現が指定したメッセージの送信を、すべての制限に適応することを確認しながら実行するカテゴリです。

モデルのすべての変化は、オブジェクトに送られたメッセージの結果として発生します。これらのメッセージは受け取りオブジェクトのまとまったメソッドを呼び出し、ローカルな状態を変えたり、あるいは他のオブジェクトにメッセージを送って必要なだけ広く効果を拡大することができます。activityライブラリに関係するのは、モデルの処理を始めるトップレベルの関数の呼び出しやメッセージ送信だけです。activityライブラリは、定義されたメソッドを呼び出すことでのみ世界モデルと最終的に作用し合います。したがって、モデルは存在し得る振る舞いと同じほど多くの振る舞いを、しっかりとまとまったメソッドの形であらかじめパッケージできます。activityライブラリは、それ自身の明示的で動的に解釈される表現に従って、あらかじめパッケージされた振る舞いを適切な時刻に発生させます。

また、モデルの実行中に条件が変わるにつれて、モデルはそれ自身を駆動しているアクティビティ構造に含まれる将来の振る舞いの表現を検討し、変更することができます。ただし、将来の振る舞いに対するどの変更も、activityライブラリに開始された現在実行中のあるアクションの結果としてのみ発生します。

3.2. Activityライブラリコンポーネント

activityライブラリには、極めて豊かな表現を持ったメッセージ送信パターンを生成するための基本的なオブジェクト型が一式定義されています。その他に、これらの表現の中で処理されている現在の状態をコントロールし、追跡するためのオブジェクト型もあります。

これらの表現は、どちらも普通のオブジェクト表現より抽象的です。なぜなら、静的な分析ができるような一定の状態を扱うのではなく、そのような状態を生成するための可変的なメッセージパターンを処理するからです。Swarmシミュレーションの基本構造は離散事象シミュレーションのそれに一致しますが、そのアクティビティ表現はそのようなシステムよりたいていは複雑です。

Swarmのアクティビティ表現が潜在的に複雑である理由は、基本的に2つあります。第一に、Swarmは生成されるアクティビティの分散した表現をサポートしています。これにより、シミュレートする振る舞いの性質をかなり反映でき、また、その実行を多重パラレルプロセッサに分散することも可能になります。Swarmでは、切り離されたアクティビティを必要以上の頻繁さで同期しなくても良いように考慮されています。つまり、モデル設計者は潜在的に正当なメッセージ送信のパターンに、余分な制約条件を指定してしまう心配がありません。本質的に、切り離され分散したアクティビティプランに適用する部分的な順序表現は、多くの離散事象シミュレーションシステムが採用している単一の集中事象リストよりも複雑です。

Swarmのアクティビティ表現が複雑である第二の理由は、予定したアクティビティのSwarmの表現を、分離した多くのモジュラーコンポーネントに分割できることにあります。これらのモジュラーコンポーネントは様々な方法でバインドし、より大きなコンポーネントを形成することができます。完全に実装されていれば、Swarmの組立て構造は基本的に、様々なイベントの発生時刻をコントロールする複雑性を備えたプログラミング言語に提供されるモジュール式の抽象概念と同じくらい強力なものです。

この潜在的な複雑性をよそに、たとえば数種の基本的な振る舞いだけを含むモデルのような、あるいは振る舞いがすべて一定の反復ステップで発生するものとして定義するようなシンプルなモデルでは、これらの機能はおそらくどれも必要とされません。Swarmの表現は極めて豊かなので、モデルに構築される従属的な振る舞いを様々に使ってSwarm表現を大きく多重レベルのモデルに高めたり、高度な並列マシンを使ったモデルの実行を容易に実現することができます。さらに、複雑に見える機能の多くは、特にモジュール化した再使用の可能なライブラリコンポーネントを構築するときに便利です。プリビルドされているライブラリはアプリケーションから内部の複雑さを隠すもので、ここには最もヘビーな利用が予想される高度な機能も多くあります。

そこから構築された構造体がいかに複雑でも、すべてのactivityライブラリコンポーネントは、最終的にはモデルのオブジェクトにメッセージを送るという直接的な実行をもたらします。直接的な実行であるがために、それらにはそれぞれ発生し得る、あるいは発生しなければならないメッセージ送信に関して極めて正確な目的を定義することができます。また、実行すべき構造体のすべてのコンポーネントと、その実行のすべてのイベントには、オブジェクト指向表現のインターフェイスを使ってアクセスできます。つまり、どの実行すべきコンポーネントとも対話ができ、また、発生したアクティビティの追跡やデバッグを可能にするツールが構築できます。Swarmの一部として構築されたそのようなツールはまだありませんが、activityライブラリインターフェイスの多くは、通常のライブラリ使用のためでなく、それらのツールをサポートするための追加コンポーネントとして存在しています。

3.3. アクションプラン・コンポーネント

activityライブラリの第一のカテゴリに属するこのコンポーネントは、モデルのオブジェクトに送られるべきメッセージを、それらが送られる順序の制約とともに表現します。それらのコンポーネントはすべて、ActionPlanと呼ばれる1つの総称型のサブタイプとして定義されます。

基本的には、アクションプランはある順序で実行すべきアクションの単純なグループ(ActionGroupと呼びます)と、時刻どおりの離散ポイントで実行すべきアクションの系列(Scheduleと呼びます)という2種類に分かれます。アクションプランの基本エレメントはActionと呼ばれるシンプルなオブジェクトで、これは1つか複数のオブジェクトに送るべき特別なメッセージを定義します。

Swarmのアクションプランの表現は、Objective C言語の動的なメッセージ送信機能にかなり依存しています。Swarmの総称アクティビティ構造の実装にとって、動的メッセージ送信に対するObjective Cのサポートは極めて重要です。Objective Cはセレクタと呼ばれる特別な種類のデータ値を定義します。セレクタはメッセージをその名前で識別します。アクションプランの各アクションには、これらのセレクタ値の1つが格納されます。プランを実行している間、Objective C装置はそのセレクタを使って実際のメッセージ送信を実行します。

アクションプランは、ユーザプログラムが様々な作成時オプションを使って直接的に作成できる独立したオブジェクトです。いったん作成されれば、アクションプランは特別な種類のアクションを含むことで互いに参照し合うことができます。したがって、他のアクションプランを開始させたり、すべてのアクションをその中で実行することが可能です。

個々のアクションは、あるアクションプランの完全にコントロールされたコンポーネントとしてのみ作成できます。それらは、標準のcreateメッセージで作成するのではありません。アクションの作成は、自分の一部としてそのアクションを含むアクションプランに特殊なメッセージ(その名前にcreateActionというフレーズが含まれています)を送ることでなされます。複数のプランに同じアクションが必要なら、プランごとに作成しなければなりません。アクションプラン全体がドロップされると、そのプランのアクションはすべて自動的にドロップされます。したがって、アプリケーションが直接管理しなければならないアクションプランコンポーネントは、アクションプランそのものだけです。

アクションプランは完全に受動的なため、比較的簡単なコンポーネントです。アクションプランが含むアクションは、アプリケーションがそのプランの中に作成したアクションだけです。これらのアクションは、それぞれにそれを削除するための特別なオプションが要求されない限り、永久にプランにとどまります。これらのプランは受動的で、すべての実行装置に対してリードオンリーのコンポーネントです。したがって、同じパターンのアクションを、モデルの複数のポイントで発生させる完璧に有効な方法は、アクションプランにそのアクションのコピーを1つ作り、次にそのアクションが必要とされるところでそのプランを参照することです。

アクションプランは受動的で、それらの中に置かれたものだけを含んでいますが、その内容を固定したままにしておく必要はありません。アクショングループとスケジュールは、どちらもそれらのアクションのコレクションとして直接実装されます。いつでも新しいアクションを追加でき、既存のアクションをドロップしたり、位置を移動させることもできます。アクションプランの内容は、モデルに将来必要となるアクションを表現するために必要なだけ動的であり得ます。これらの変化する内容は、モデルの実行時に実際に処理されるまで、そのモデルに影響を与えません。

3.4. モデル実行コンポーネント

モデル実行で果たされるべき最も重要な責任は、アクションプランに指定されたアクションを、そのプランのあらゆる必要条件に即した順序で実行することです。各アクションプランは、存在するアクションの実行順序に必要なだけ多い、あるいは少ない制約を課すことができます。これらの仕様を与えると、実行オブジェクトは責任を持って実行すべき各アクションを選択し、それを実行します。

順序づけには単純に2つのケースがあり、現在のSwarmデモプログラムでの利用法を含み、ほとんどすべての利用方法はこれらで説明することができます。1つは、アクションが任意の順序で実行されるように許可するケースです。並行実行を行うハードウェアやソフトウェアが利用できるなら、それも含みます。もう1つは、あるシーケンスに従ってアクションが実行されるように要求して、あるアクションの効果をそれに先行するアクションに依存させるケースです。このシーケンスは、あらかじめ定めた固定的なもの、あるいはアクションプランが実行される各時刻に動的に確立されるもののいずれかになります。シーケンスを動的に決定する必要があるときは、アクションが一度にすべて実行されるように選択するときでさえ、アクションプランとそれを実行する実行オブジェクトにカスタムサブクラスを与えることができます。ビルトインされているオプションでは、プランが実行されるたびに完全にランダムなシーケンスが作成されるようになっています。

アクションプランが処理されている各時刻では、実行時処理装置がアクティビティと呼ばれる特別な種類のオブジェクトを完全に自動作成します。これらのアクティビティオブジェクトは、アクションプランを実行する能力を持った仮想プロセッサの内部装置を実装します。モデル上で開始したあらゆるアクティビティを獲得するため、プロセッサは最初に初期化されて、1つのトップレベルのプランを実行します。モデルが存続する間、他のすべてのアクティビティは、このプラン(他のプランのスタートアップを含む場合があります)が始めたアクションの結果として発生しなければなりません。

アクティビティオブジェクトは処理装置に対して内部的なので、通常アプリケーションではそれらの存在を無視できます。様々なアクションプランが開始して完了する間それらは動的に行き来しますが、1つのトップレベルのプロセッサにコントロールされる現在のアクティビティツリーやスタックの中ですべて整理されています。アクティビティオブジェクトは便利な潜在能力を持っています。あるアクションが走っているコンテキスト情報を獲得したり、デバッグやトレースツールを構築して、実行されているアクションを知ることができます。

アクティビティオブジェクトから利用できるコンテキスト情報には、スケジュールが進むにつれて増加する現在時刻のクロック値もあります。スケジュールはアクションプランの一種です。すべてのアクションは特定のポイント、つまりスケジュールの中で明示的に確立された時刻に発生します。スケジュールが実行されているとき、アクティビティオブジェクトは現在の時刻を維持します。この時刻はすべてのモデル実行の開始時を起点としたグローバルな時刻で、スケジュール自身が開始した時刻には関係しません。スケジュールを進めているアクティビティオブジェクトは、その時刻がスケジュールに含まれる時刻に関係せず、グローバルな基礎時刻から連続的に増加するため、タイムラインアクティビティと呼ばれます。

処理中のアクションプランに、別のアクションプランを実行するアクションや、別の自律実行のアクションプランを開始するアクションが含まれていると、かならず新しいアクティビティが作成されます。1つのアクションプランが別のアクションプランを実行すると、新しいアクティビティが別のアクションプランを完了するまでそれ自身の処理は停止します。1つのアクションプランが他を開始すれば、新しいアクションプランは、アクティビティを含んだより高いレベルによってのみコントロールされる自律アクティビティとして開始します。

Swarmは1つのアクティビティであり、開始した他のサブアクティビティをコントロールし、調整するためだけに存在しています。サブアクティビティが同期という特別な形式を明示的に持っていなければ、それらの内部アクションはどれもアクティビティ実行中に明示的に確立されるときを除き、他のプランのアクションに関連した順序づけは要求されません。Swarmは開始したサブアクティビティの単純なコンテナとして役立ちます。サブアクティビティが互いに送るメッセージが同期しても、それは単なる偶然です。Swarmはオブジェクトのコレクションを維持するだけでなく、それらの相互の調整を補助する必要があるときは、そのサブアクティビティを維持するのに使用できます。

仮想処理装置には、Swarm内の同期という特別な形式が構築されます。タイムラインサブアクティビティの処理中は、この同期が連続する時刻値に発生するアクションを挿入します。スケジュールされた基本モデルのアクションを使った表示処理や分析処理を挿入するために、アクションをマージすることもよくあります。サブアクティビティの調整について、Swarmの現行バージョンにこの他のメカニズムは実装されていません。したがって、Swarmのアクティビティ型に与えられた最も重要な現在の役割は、サブスケジュールアクティビティの同期を取ることです。将来のバージョンでは、大きなモデルを、コンポーネントがより濃密に相互作用するクラスタとして組織するための手段としてSwarmが役立つようになり、また並行実行に向けた分解の基礎が提供されるようになります。