JP2008517362A - サブジェクトシステムへの作用 - Google Patents

サブジェクトシステムへの作用 Download PDF

Info

Publication number
JP2008517362A
JP2008517362A JP2007536195A JP2007536195A JP2008517362A JP 2008517362 A JP2008517362 A JP 2008517362A JP 2007536195 A JP2007536195 A JP 2007536195A JP 2007536195 A JP2007536195 A JP 2007536195A JP 2008517362 A JP2008517362 A JP 2008517362A
Authority
JP
Japan
Prior art keywords
model
event
action
actor
meta
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007536195A
Other languages
English (en)
Other versions
JP5128949B2 (ja
Inventor
ピーター ホーキンス
Original Assignee
マンザトロン−アイピー リミテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by マンザトロン−アイピー リミテッド filed Critical マンザトロン−アイピー リミテッド
Publication of JP2008517362A publication Critical patent/JP2008517362A/ja
Application granted granted Critical
Publication of JP5128949B2 publication Critical patent/JP5128949B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G06F8/24—Object-oriented
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Abstract

【課題】サブジェクトシステムへのアクションを生成すること。
【解決手段】アクタ１０−１およびサブジェクトシステム１０−２は、サブジェクトシステム１０−２に影響を与える環境１０−３に存在する。アクタ１０−１は、モデル１１−１およびプロセッサ１１−２を含む。プロセッサ１１−２は、モデル１１−１によってガイド１１−５される。プロセッサ１１−２は、サブジェクトシステム１０−２においてアクションを生成１１−４する。サブジェクトシステム１０−２は、モデル１１−１によって理解１１−３されている。アクタ１０−１は、それ自身のアクションによってモデル１１−１を最新に保つ。プロセッサ１１−２は、モデル１１−１に従って処理するときに、モデル１１−１を、中間アクションおよびサブジェクトシステム１０−２において生成するアクションにより更新する。
【選択図】図１１Ｂ

Description

本発明は、概してモデルを用いたサブジェクトシステムへの作用に関する。特に、本発明は、サブジェクトシステムにおいてアクションを生じるためのアクタ、サブジェクトシステムで生じたアクションのアクタを含む論理型コンピューティング・デバイス、コンパイラ、サブジェクトシステムでアクションを生じさせる方法、コンパイラを制御する方法、およびサブジェクトシステムをモデル化する方法を含む、その様々な態様に関する。
システムの考えは、数十年間で広まった。例えば、Ａｃｋｏｆｆｓの１９７１年の論文「Ｔｏｗａｒｄｓ ａ Ｓｙｓｔｅｍ ｏｆ Ｓｙｓｔｅｍｓ Ｃｏｎｃｅｐｔｓ」（Ｍａｎａｇｅｍｅｎｔ Ｓｃｉｅｎｃｅ、１７（Ｊｕｌｙ） ６６１−６７１）には、いくつかのキーシステム概念の定義が規定されている。システムは、「・・・相互関係エレメントの集合」として定義され、システム状態は、「・・・システムがある［瞬間］に持つ関連した特性の集合」として定義される。そして、システム環境は、「・・・エレメントおよびそれらの関連した特性の集合、そのエレメントはシステムの部分ではなく、システム状態の変化を生成できるいずれかにおける変化」として定義される。また、イベントは、「・・・システム状態（または環境）における・・・変化」として定義され、論文は、「反応」、「応答」および「自主的な作用」を通じて、システムにおけるイベント上のシステム変化の依存性またはその環境を記述する。
現代のシステムを説明することができる１つの方法が、図１に与えられている。汎用コンピュータシステムまたは組み込みコンピュータシステムのような製品１−２が、そのコアである。図１のより広いシステム内のシステムでもある製品１−２は、企業１−１（それはまたシステムの一種として見られてもよい）におけるアクタとして、オンライン技術サポートのようなサービス１−３の提供で採用されていてもよい。サービス１−３は、もう１つのシステムを構成する。製品１−２および／またはサービス１−３は、他の企業（図示せず）によって、または例えば、個人１−５、グループ１−６または世帯１−７等の消費者１−４によって、消費されることができる。消費者１−４は、またシステムとしてモデル化されてもよい。企業１−１および消費者１−４は、社会技術システムであり、サービス１−３は、通常、技術および人的資源の組み合わせによって実現される。これは、現代の複雑な適応システムを分析、設計、構築、試験、実施および運営するにおいて、コンピュータおよび他の機械類の単なる技術的要件以上のものを対象にするのが望ましいことを意味する。最大効果のために、産業および他のプロセスがアプリケーションとどのように相互作用するか、およびこれらのアプリケーションのプロセスを実行するために人々がどのように組織化されるかを理解することが重要である。
この５０年ほどにわたって開発されたツールは、上記のシステムのような現代システムの難問に取り組むためには、不適当に多くの方法を備えている。本発明者は、これは、以下のためであると考える：大部分の実在のシステムが高度に並列または並行であるのに反して、それらの基礎となるアーキテクチャは、実際は基本的に逐次または直列である；
それらは、典型的に、実在のシステムが時間とともに変化することに、それらが適応するのを難しくする静的定義を持つ；それらは、アーキテクチャの異なるレイヤと開発の異なるステージとの間の意味上のギャップを強化する；そして、異なる規律が非常に類似する現象のために異なる言語およびツールを使用するので、特に複雑な社会技術システムにおいてソリューションを共用することを妨げている。特に、この最後の点の帰結として、図１に示されるタイプの現代の複雑な適応技術および社会技術システムの分析、設計、構築、試験、実装および運営に関する先行技術が多くの既存の分野からもたらされる。これらの分野は、以下を含む：同期および非同期シーケンス回路を含む逐次および並列コンピュータハードウェア；イベント駆動型ソフトウェアを含むコンピュータソフトウェア；データ（「トリガ」を含む）およびメタデータ；コンピュータ・オペレーティング・システム；エキスパートシステムを含む人工知能エージェント；システム開発方法論、ツールおよび技術；分析シミュレータおよびデジタル仮想環境；ならびにビジネスプロセス・リエンジニアリングおよび組織設計。
図２は、従来のフォン・ノイマン・コンピュータを表す。それは、制御ユニット２−４および演算＆論理ユニット（ＡＬＵ）２−５を含む中央演算処理装置（ＣＰＵ）２−３を含む。また、コンピュータは、メモリ２−６および入力／出力（Ｉ／Ｏ）コントローラ２−２を含む。ＣＰＵ２−３、メモリ２−６およびＩ／Ｏコントローラ２−２は、内部バス２−１を経由して通信する。そのようなコンピュータのフェッチ、デコード、実行サイクルは、ＣＰＵ２−４に含まれるプログラムカウンタ２−７の制御の下で行われる。
デフォルト設定によって、プログラムカウンタ２−７は、各命令の後に増加し、それゆえ、得られた次のアクションはシーケンスにおける次の命令である。シーケンスのフロー中の例外（またはジャンプ）は、プログラムカウンタ２−７を、実行すべき次の命令のアドレスで上書きする命令によって生じさせることができる。（この制御フロー機構は、１９３６年にＡｌａｎ Ｔｕｒｉｎｇによって提案されたチューリングマシンと同様な、いくつかの特徴を持つように見える。Ｊｏｈｎ Ｖｏｎ ＮｅｕｍａｎｎはＴｕｒｉｎｇのアイデアに気づいていたようだが、彼がそれらを、彼がＡ．Ｐ．ＢｕｒｋｓおよびＨ．Ｈ．Ｇｏｌｄｓｔｉｎｅと共に１９４６年に提出した「Ｐｒｅｌｉｍｉｎａｒｙ Ｄｉｓｃｕｓｓｉｏｎ ｏｆ ｔｈｅ Ｌｏｇｉｃａｌ Ｄｅｓｉｇｎ ｏｆ ａｎ Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｐｕｔｉｎｇ Ｉｎｓｔｒｕｍｅｎｔ」と題された米国陸軍兵站部への報告に適用したかどうかははっきりしない。）
結果としてもたらされた「フロー＆ジャンプ」機構は、フォン・ノイマン型コンピュータに、計算アルゴリズムの広い範囲をサポートすることを可能にする。しかしながら、今日や明日のコンピュータによってサポートされた大部分のアプリケーションは、数十年前に暗号解読やミサイル弾道予測に要求された計算とは大いに異なる。代わりに、それらは、我々の周りの世界のシステムを反映する必要があり、我々が経験する複雑さを我々が管理するのを助けるか、または我々の製品やサービスの精巧さの増大のためにその複雑さを使用するかのいずれかの必要がある。これらの実在のシステムにおいて、多くの同時またはほぼ同時のイベントが認識され、記憶され、そして潜在的に作用される必要があるのかもしれない。これらのシステムの我々のモデルもまた、システムの私達の理解が進むにつれて、連続的に変化する。
同様に、現在のコンピューティング・デバイスの激増は、フォン・ノイマンの時代には予言されていなかった。その時代には、そのようなデバイスの可能性は、科学的および軍事的アプリケーションに限定され、かつ、存在するのは、おそらく数百台に過ぎないコンピュータであるだろうことが予期されていた。しかし、現在では、汎用（例えば、デスクトップコンピュータ）および組み込み（例えば、自動車制御システム）の両方で、数億台のフォン・ノイマン型コンピュータがある。また、これらのデバイスの多くは、通常、いくらか厳密に定義されるコンピュータ・ネットワークを通じてお互いに通信をする。近い将来において、刻々と自身で動的に構成および再構成するネットワークを通じて互いに協働する何十億台もの「コンピュータ」があるだろうことが想像される。本発明者は、そのような大規模な動的コンピュータ・ネットワークの開発のために、フォン・ノイマン・アーキテクチャが大きな抑制要因になるものと考える。
現代のコンピュータの大多数の基礎であるフォン・ノイマン・アーキテクチャは、根本的に逐次的である。「通信逐次プロセス」（ＣＳＰ）、「データフロー」および「アクタ」モデルは、並行処理を提供する試みとして提案された。しかし、これらのアプローチは、粒度の粗い並列処理をただサポートするために、または比較的特別な計算アプリケーションに限られるために、意味上のギャップを強化する傾向がある。
通信逐次プロセスは、Ｃ．Ａ．Ｒ．Ｈｏａｒｅ教授によって考案され（「Ｃｏｍｍｕｎｉｃａｔｉｎｇ Ｓｅｑｕｅｎｔｉａｌ Ｐｒｏｃｅｓｓｅｓ」、ＡＣＭ通信、２１巻、６６６−６７７頁、１９７８年）、Ｄｉｊｋｓｔｒａの仕事の上に築かれた（ＤｌＪＫＳＴＲＡ，Ｅ．Ｗ．（１９７５）、「Ｇｕａｒｄｅｄ Ｃｏｍｍａｎｄｓ， Ｎｏｎｄｅｔｅｒｍｉｎａｃｙ ａｎｄ Ｆｏｒｍａｌ Ｄｅｒｉｖａｔｉｏｎ ｏｆ Ｐｒｏｇｒａｍｓ」、ＡＣＭ通信、１８巻、４５３−４５７頁）。通信逐次プロセスは、同期入力および出力コマンドを介して通信できる並列逐次プロセスに導入された。この分野での初期の仕事は、新しいプログラミング言語を目標としていたが、以来、例えばＩｎｍｏｓ社のトランスピュータ等のハードウェア設計が始められた。
フォン・ノイマン・アーキテクチャのもう１つの代替は、フォン・ノイマン「制御フロー」アプローチと対比させることができる、「データフロー」マシンである。データフローマシンにおいて、プログラムカウンタは除かれ、実行はオペランドの可用性によって単独でなされる。これは、フォン・ノイマンまたは通信逐次プロセスモデルのいずれかよりも、もっと粒度の細かい並列処理を可能にする。
図３は、１９７５年にＭＩＴでＤｅｎｎｉｓおよびＭｉｓｕｎａｓによって設計された初期のデータフロープロセスを示す。このＭＩＴデータフローマシンは、通信ネットワーク３−２を介して内部接続された処理エレメント３−１の集合を含む。処理エレメント３−１内で、アクティビティ記憶部３−５は、アクティビティ・テンプレートを保持する。命令待ち行列３−４は、発せられた命令（すなわち、全ての入力が利用できるためのアクティビティ・テンプレート）のアドレスを保持する。命令待ち行列３−４の第１のエントリは、対応するオペコード、データ、およびアクティビティ記憶部３−５で保持されたアクティビティ・テンプレートを構成するあて先リストを取り出すためにこのエントリを使用するフェッチユニット３−９によって削除される。それから、これは、フェッチユニット３−９によって利用可能なオペレーションユニット３−３に転送されるオペレーショントークンに詰められる。テンプレートにおけるオペランド・スロットは、それからクリアされる。オペレーションユニット３−３は、対応オペランドを使用するオペコードによって特定されるオペレーションを実行し、各あて先のための結果トークンを生成し、そしてトークンのあて先がローカルの処理エレメント３−１にあるか、またはリモートにあるかを決定する送信ユニット３−８にそれらを提供する。あて先がローカルであると決定されると、トークンはローカルの受信ユニット３−７に送信され、更新ユニット３−６に順に渡す。そうでなければ、トークンは、通信ネットワーク３−２を介してあて先である処理エレメント３−１に送られる。命令は、全てのユニットが同時に動作したときからパイプライン方式で処理される。
データフローアプローチは、データフローモデルが認識する唯一のイベントである関数が前もって待ち行列に収容され、予め決定されたトークン照合ルールに基づいて開始されるので、静的相互接続トポロジを持つように記述されている（ＡＧＨＡ，ＧＵＬによる「Ａｃｔｏｒｓ： Ａ Ｍｏｄｅｌ ｏｆ Ｃｏｎｃｕｒｒｅｎｔ Ｃｏｍｐｕｔａｔｉｏｎ ｉｎ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ」、ＭＩＴ Ｐｒｅｓｓ、１９８６）。トークン照合は、データフローマシンに関連する開発努力の多くを消費するアプローチの複雑さを相当に増す。これは、その拡張または再構成できるモデルの動的実行をサポートする能力を制限するのと同様に、ソリューションのデータフローモデルの範囲をそれらが関与する計算に制限する。
データフローアプローチと制御フローアプローチとは、両アプローチの弱点に対処する試みにおいて結合される（例えば、Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ（登録商標） Ｐｒｏの設計（ＣＯＬＷＥＬＬ，Ｒ．Ｐ．、ＳＴＥＣＫ，Ｒ．Ｌ．「Ａ ０．６μｍ ＢｉＣＭＯＳ Ｐｒｏｃｅｓｓｏｒ ｗｉｔｈ Ｄｙｎａｍｉｃ Ｅｘｅｃｕｔｉｏｎ」、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｏｌｉｄ Ｓｔａｔｅ Ｃｉｒｃｕｉｔｓ Ｃｏｎｆｅｒｅｎｃｅ、１９９５年２月））。しかしながら、これは、いずれかのアプローチにおいて根本的に固有の制限に取り組まれることはなかった。
今なお、フォン・ノイマン・アーキテクチャのもう１つの代替は、１９７０年代の後半にＣ．Ｅ．Ｈｅｗｉｔｔ他によって独自に考案され、Ｇｕｌ Ａｇｈａによって［「Ａｃｔｏｒｓ： Ａ Ｍｏｄｅｌ ｏｆ Ｃｏｎｃｕｒｒｅｎｔ Ｃｏｍｐｕｔａｔｉｏｎ ｉｎ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ」、ＭＩＴ Ｐｒｅｓｓ、１９８６］に記述された並行計算の「アクタ」モデルである。このモデルにおいて、アクタは、アクタが関連付けられる予め定義された「動作」を行うための「タスク」内に含まれる「通信」の受信によって活性化される。動作は、場合により条件付きで「コマンド」のコレクションとして定義され、アクタが受信するかもしれない次の通信に応答して自身の動作を潜在的に修正するのと同様に、他のアクタを生成、および／またはさらなる通信を送信させる。アクタシステムが認識する唯一のイベントのタイプは、新しい「タスク」（すなわち、「通信」）の生成である。このゆえに、アクタシステム内の全てのアクティビティは、アクタ間の通信の伝播によって駆動される。これは、アクタシステムの長所および短所の両方である。これらの比較的単純な機構は、並行計算の広い範囲に具体化するために使用できる。アクタモデルが、通信逐次プロセスまたは上記されたデータフローモデル内で定義されることができるどのシステムを実施するのにも十分に強力であることが言える。しかし、それは、並行処理の粒度の程度を個々の動作に制限し、それぞれは複数の条件付きコマンドを含んでいてもよい。また、アクタモデルは、非通信関連イベントを処理するために要求される複雑な機構のように、現代の体系的アプリケーションと基礎となる計算環境との間の意味上のギャップを広くし、それによってその実在のアプリケーションを制限していると言うことができる。
基礎となるほとんどのフォン・ノイマンおよび他の現存するコンピュータ・アーキテクチャは、「同期シーケンス」電子回路である。そのような回路において、状態間の遷移がクロックからのパルスによって開始される。例えば、上記されたフェッチ−実行サイクルの各ステップは、単一のクロックパルスがトリガとなる。このアプローチは、サイクル時間削減の抑制、不必要な電力消費および不適当なノイズならびに電磁波副作用を含むある程度の欠点を持つことが認識されている。これらの欠点の結果として、ここ数年、そのような回路のより複雑な設計および試験要件にもかかわらず、非同期シーケンス回路の開発にかなりの関心が払われてきた。しかし、全コンピュータ・アーキテクチャのレベルの下で実施されたこの研究は、フォン・ノイマン・アーキテクチャの基礎となる順次性に取り組まなかった。
ほとんどのソフトウェアが記述される従来の高級言語は、フォン・ノイマン型コンピュータをよりアクセス可能に制御するマシン語を作る必要から開発された。このようにして、これらの言語は、逐次マシンの制限を具体化する。これは、Ｓｉｌｃ他によって「・・・フォン・ノイマン設計の構造上の特徴は、今日使用され、フォン・ノイマン・アーキテクチャ・パラダイムに由来する逐次的な高級プログラミング言語によって今なお有効である」と記述されている（ＳｌＬＣ，ＪＵＲＩＪ；ＲＯＢＩＣ，ＢＯＲＵＴ；ＵＮＧＥＲＥＲ，ＴＨＥＯ「Ｐｒｏｃｅｓｓｏｒ Ａｒｃｈｉｔｅｃｔｕｒｅ： Ｆｒｏｍ Ｄａｔａｆｌｏｗ ｔｏ Ｓｕｐｅｒｓｃａｌａｒ ａｎｄ Ｂｅｙｏｎｄ」、Ｓｐｒｉｎｇｅｒ、１９９９）。
図４に図示されているように、従来のソフトウェアは、あるプログラミング言語（例えば、Ｃ、Ｊａｖａ（登録商標）等）のプログラムとして書かれている。それから、各プログラムのどの命令も、プログラムが実行されるべきコンピュータのマシン語、または仮想マシン（ＶＭ）上で実行されるべきある中間形式（例えば、「バイトコード」）のいずれかに変換される必要がある。この後者の場合は、個々のオペレーションは、それから次の下のレベルでマイクロ・プログラム（これもまた直列である）になる。
ここで、非常に最新のソフトウェアが「オブジェクト指向型」（ＯＯ）アプローチを使用して設計され、開発されていることに注意すべきである。上記されたヒューイット・アクタアプローチから開発されているＯＯソフトウェアは、プログラム実行を駆動するために、「オブジェクト」間でのメッセージ送信を利用する。これは、「イベント駆動型」としてしばしば記述されるグラフィカル・ユーザ・インターフェース（ＧＵＩ）ソフトウェアの開発において特に明白である。そのような「粒度の粗い」イベントは、ソフトウェアの小さなセグメントの実行を開始し、通常、ＯＯの先行技術で「メソッド」と呼ばれている。しかし、そのようなソフトウェア・セグメントは、フォン・ノイマン・パラダイムに確固として根付いたまま残る。すなわち、それらは基本的に逐次的である。（そのようなコンポーネントがソフトウェア内でアクションを生じさせるので、Ｈｅｗｉｔｔ他によって採用されている名称「アクタ」が、「オブジェクト」よりずっと適切である。しかし、混乱させるかもしれないが、用語「オブジェクト」が先行技術において広く使われている。）同様に、「トリガ」は、データベース管理システム（ＤＢＭＳ）分野に最近導入された。そこでは、ソフトウェアの小片は、データベース内の特定のフィールドに関連されていて、その関連フィールドが更新されるときはいつも実行される。また、これは粒度の粗いイベント駆動型処理のいくつかのエレメントを持つが、ソフトウェアの各小片は、それ自体確固としてフォン・ノイマン・パラダイムに根付いている。
いくつかのイベント駆動型オブジェクト指向型アプローチは、ＩＢＭ Ｔｅｃｈｎｉｃａｌ Ｄｉｓｃｌｏｓｕｒｅ Ｂｕｌｌｅｔｉｎ ＮＮ９５１１４３１「Ｅｖｅｎｔ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ ｉｎ ａｎ Ｏｂｊｅｃｔ Ｏｒｉｅｎｔｅｄ Ｓｙｓｔｅｍ」と同様に、Ｐａｖｉｌｉｏｎ（国際公開第２００１／７７８７２号明細書）、Ｃｏｏｋ他（米国特許第６１７８４３２号明細書）およびＭｕｋｈｅｒｊｅｅ他（米国特許第６１９５６８５号明細書）を含む先行技術において記述される。これらのそれぞれは、上記された粒度の粗いイベント駆動型アプローチの変種であり、このように、実装のための逐次ソフトウェア（通常、ＯＯ「メソッド」）に依存している。
コンピュータのハードウェアとソフトウェアとがどのように相互作用するかを考慮して、図５は、［ＴＡＮＥＮＢＡＵＭ，ＡＮＤＲＥＷ Ｓ．「Ｍｏｄｅｒｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ」Ｐｒｅｎｔｉｃｅ Ｈａｌｌ，２００１］に記述されているのと同様に、現代の階層化コンピュータ・オペレーティング・システムがどのように設計されるのかを示す。コンピュータ・オペレーティング・システムは、基礎となるコンピュータハードウェア資源（例えば、メモリ、ディスク、プリンタ等）を管理し、関係するコンピュータシステムのユーザおよびプログラマのニーズにより適した「仮想マシン」を提供する。それは、ＣＰＵ５−２０上で実行する７つの仮想レイヤ５−１１から５−１７を備える。第１のレイヤ５−１１は、基礎となるハードウェアを隠し、その上で通常のオペレーティング・システムがいくつかの異なるハードウェア構成をサポートするために設計されることができる低レベル仮想マシンを提供する。第２のレイヤ５−１２は、割り込み処理、コンテキスト・スイッチングおよびメモリ管理を含むオペレーティング・システムの基礎構築ブロックを提供する。第３のレイヤ５−１３は、本質的に単一の逐次ＣＰＵ上の多重処理環境を提供することを必須とするオペレーティング・システム内に、管理プロセス、更に特にスレッドを必須とするコンポーネントを含む。第４のレイヤ５−１４は、ＣＰＵに接続された、または接続することができる特定の周辺装置やリソースのそれぞれの使用によって生じる全てのアクティビティを処理するドライバを提供する。この上は、仮想メモリ管理レイヤ５−１５であり、コンピュータに、利用可能な物理メモリを明らかに著しく超過しているそのユーザにメモリ空間を提供することを可能にする。第６のレイヤ５−１６は、ディスクおよび他の長期記憶媒体に保持されたファイルの管理をサポートするために必要な特徴を提供する。第７の、すなわち最上レイヤ５−１７は、システムコールを処理し、それにより、システムリソース上でユーザプログラム５−１８がそれを介してコールすることができるインタフェースを提供する。
ソフトウェアコンポーネントの全てのこれらのレイヤは、コンピュータのＣＰＵ５−２０より上のレイヤに存在し、コンピュータが実行する全てのオペレーションに含まれるようにＣＰＵ５−２０に要求する。いくつかのアプローチは、多重プロセッサ（密結合）、多重コンピュータおよび分散コンピュータ（疎結合）構成を通じて、多重ＣＰＵ間でこの仕事量を分配するように考案された。しかし、基礎となるハードウェアモデルのモノリシックで逐次的な性質に起因して、これらの構成は、結合の疎密に比例して、特にプロセス・スケジューリングおよび同期の領域で重大な複雑さを、サポートするオペレーティング・システムに加える。
近年、「データについてのデータ」として考えられるメタデータを理解することの重要性の認識が大いに高まってきた。この高まった認識は、２つの主要な源から来るように見える。すなわち、データウェアハウスおよびビジネス知的ソリューションの価値を実現する必要、および開発、整備およびウェブサイト間の情報交換に関連する努力を減らす必要である。結果的に、ＸＭＬおよびメタ・オブジェクト・フレームワーク（ＭＯＦ）のような技術におけるソフトウェア・コミュニティについての興味が増大している。データ交換の分野におけるメタデータの価値は、よく理解されている。しかし、たいていの場合、メタデータは、ユーザまたはそれらのアプリケーションに利用することができず、アプリケーションに内在するか、または最終のアプリケーションに翻訳されていない分析および設計フェーズのモデルにおいて保持される。これは、それらが使用されているコンテキストが変化するように適応させるほとんどのそのようなアプリケーションの柔軟性を妨げる。
同様に、メタレベル・プログラミングの分野において、特にＣｏｍｍｏｎ ＬＩＳＰオブジェクトシステム（ＣＬＯＳ）ならびに他のプログラミング言語およびシステムによって採用されているメタ・オブジェクト・プロトコル（ＭＯＰｓ）の使用について、また発展があった。これらのＭＯＰｓは、プログラミング言語またはシステムそれ自体におけるオブジェクトを記述するメタレベル・プログラムのコンテキストにおけるベースレベル・アプリケーション・プログラミングを必要とする。しかし、そのようなＭＯＰｓは、開発中に専門プログラマだけが利用でき、ランタイム、すなわち、コンパイルまたはインタープリート後に、修正のために利用できない。それらは、また、実行の複雑さを相当に加えるように見え、特に並行実行をサポートすることを、それらにとって難しくする。
他のメタデータ関連の先行技術に、Ｎｙｅ（米国特許出願公開第２００３−０１９５８６７号明細書）がある。Ｎｙｅは、「イベントモデルを用いて柔軟に状態遷移を処理する方法」を提供することを請求する。それは、イベントを「条件次第で選択的であり、おそらく空のアクションの集合」として定義し、「内部クロックの各時刻の間、全ての計算可能なイベントはランダム順で処理される」と述べた。このように、それは、従来の粒度の粗いイベント駆動型システムのオペレーションをガイドするメタデータを使用する。
Ｓｔａｆｆｏｒｄ Ｂｅｅｒは、彼の本「Ｄｉａｇｎｏｓｉｎｇ ｔｈｅ Ｓｙｓｔｅｍ ｆｏｒ Ｏｒｇａｎｉｚａｔｉｏｎｓ」（Ｃｈｉｃｈｅｓｔｅｒ：Ｊｏｈｎ Ｗｉｌｅｙ ＆ Ｓｏｎｓ、１９８５）において、「発展可能システム」の概念を導入した。それを、彼は、「・・・特殊な環境［内で］分離した存在を維持できる」システムとして定義した。この本において、Ｂｅｅｒは、それらがなお発展し続けるならば、より適応するためにシステムに必要なものを特定したが、適応させる詳細な機構は記述しなかった。そして、そのような発展可能システムをどのように可能にするのかについては特別な注意を払わなかった。
人工知能エージェントの概念は、コンピューティングの誕生以前から存在していた。１９６０年代から１９７０年代の間に、コンピュータの「知能」を作ることにかなりの注意が払われた。特に、エキスパートシステムは、例えばコンピュータハードウェアの構成におけるＤｉｇｉｔａｌ Ｅｑｕｉｐｍｅｎｔ社の「Ｒ１」システムのように、認識可能な技術的効果を有する適所を見出した。しかし、そのようなエージェントは、それらの複雑さおよびそれらの構築の費用のために、持続的な商業的価値が限定された。また、それらは、典型的に、実行時間性能に乏しい。それらを発展可能にするであろう機構（Ｂｅｅｒによって論じられた意味において）は、記述されなかった。
図６は、［ＲＵＳＳＥＬＬ，ＳＴＵＡＲＴおよびＮＯＲＶＩＧ，ＰＥＴＥＲ「Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ： Ａ Ｍｏｄｅｒｎ Ａｐｐｒｏａｃｈ」、Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ、１９９５］によって定義されたような学習エージェントの一般モデルを示す。エージェント６−０は、パフォーマンス基準および環境からの入力を取り入れ、環境に作用する。エージェント６−０において、パフォーマンス・エレメント６−１は、センサ６−２からの入力として知覚を取り入れ、アクションを決定し、それからそれはイフェクタ６−３に出力する。学習エレメント６−４は、エージェントがどのように振る舞うかに関する批評部６−５からの入力と共に、パフォーマンス・エレメント６−１についてのある知識を取り入れ、将来のためにパフォーマンスを改善するという視点でパフォーマンス・エレメント６−１にどのような変化を送るかを決定する。問題発生機６−６は、学習エレメント６−４から供給される学習目標に基づく新しく有益な経験に導くだろうアクションをパフォーマンス・エレメント６−１に提案する。
エキスパートシステムおよび他の知識ベースシステムにおいて、パフォーマンス・エレメント６−１は、「プロダクションルール」として知られている「ＩＦ＜条件＞ＴＨＥＮ＜推論＞」ルールの形式の知識をしばしば含む。そのようなシステムは、これらのルールとともに「前方連鎖」検索アルゴリズムを用いて、アクションを開始させることができ、しばしば新しい「知識」を生成することができる推論を見出す。エキスパートシステムは、上記されたＲ１システムがしたように、いくらかの重要な技術的効果および商業的成功を得たが、プロダクションルールは、前方連鎖検索アルゴリズムによって消費されるリソース、および限られたアプリケーションによって乏しいパフォーマンスを持つように見られる。結果的に、設計者は、しばしば、知識を得るために、フレームシステムやニューラルネットワークのような他の方法に頼らなければならない。結果として、統合するのが困難ないくつかの異なる知識表現機構は、今日の知識ベースシステムにおいて表すことができる。
Ｋｏｎｉｎｋｌｉｊｋｅ ＫＰＮ（国際公開第２００２／０５４２９６号明細書および欧州特許第１２５３５３３号明細書）およびＲｏｓｓ（米国特許第６５９８０３３号明細書）を含むいくつかの先行技術は、問題領域の知識−電気通信サービス規定およびアラーム相関性をそれぞれ解決する知識ベースアプローチを採用することを請求する。しかし、これらは、先に記述されたように、知識ベースシステムよりも、従来のオブジェクト指向型アプローチにより多くを負っている。いくつかのモデリング技術は、異なるタイプのルールシステムを記述するために使用されている。
コンピュータソフトウェアは、図７に示されるような従来のフローチャートから、統一モデリング言語（ＵＭＬ）、そしてオブジェクト制約言語（ＯＣＬ）のような関連言語で記述されるようなオブジェクト指向型技術まで、いくつかのグラフィック技術を使用して、記述および／または設計されている。ＵＭＬは、図８Ａおよび８ＢのＵＭＬクラス図およびＵＭＬアクティビティ図によってそれぞれ図示されている。また、数学の集合論は、「Ｚ」のように言語を通じて採用されている。
コンピュータハードウェアは、伝統的に、ブロック図または電子回路図を用いてグラフィカルにモデル化されている。近年、Ｖｅｒｙ Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ（ＶＨＤＬ）は、モデルに採用され、その後、ハードウェアコンポーネントおよびシステムの構造および動作をソフトウェアのようなルールを使用してシミュレートする。
産業および他のプロセスは、ソフトウェア設計者によって使用される従来のフローチャートを用いて通常は記述および／または設計された。これらのフローチャートは、しばしば今日のワークフロー・ソリューションの基礎となる。また、プロセスは、図８Ｃおよび８Ｄにそれぞれ示されるＩＤＥＦ０およびＩＤＥＦ３のそれらのように、専用プロセスモデリング技術によって記述および／または設計される。
プロセス、ソフトウェアおよびハードウェアの設計に採用されている技術が異なるという事実は、それらの異なる分野にわたるシステムを記述および／または設計することは困難であるので、重大な問題である。一方、これらは、共通して多くの特徴を持つ。また、これらは、システムの動作に関係する全てのルールをとらえることはできないので、不完全である。例えば、ビジネスシステムを適切に記述するために必要である制約の多くを得るために、ＯＣＬがＵＭＬへのアドオンとして要求されることに注意してもよい。また、これらの技術は、基本的にフロー型または逐次的である。ＩＤＥＦ０およびＵＭＬは、システムのフロー型の記述を要求しないが、動作の完全記述を得るために、フロー型または逐次コンポーネントが要求される。特に、これらのコンポーネントは、ＩＤＥＦ０のためのＩＤＥＦ３プロセスフローおよびＵＭＬのためのメソッドである。Ｚモデルはフロー型ではないため、それらはイベント駆動型システムを記述するための機構を持たない。それらはソリューション・システムに組み込まれないので、これらの技術は、概して最終システムから断ち切られる。最後に、これらの技術は、適応した動作をサポートするそれらの能力を制限するオブジェクトに沿ってメタ・オブジェクトが簡単にモデル化されるのを許さない。
いくつかのプロセステンプレート（または「方法論」）は、図１に示される技術的および／または社会技術システムを開発するために提案されている。それらは、典型的には、図９Ａに示される情報エンジニアリング方法論のように、「ウォーターフォール」スタイル、または図９Ｂに示されるようにオブジェクト指向型方法論において採用されていたかもしれない「反復」スタイルである。いずれの場合においても、これらの方法論は、そのようなシステムが正しく定義されるならば、開発プロセスが実行されるべき、しばしば繰り返されるが常にシーケンシャルな順序を定義する。どちらのアプローチも、いくつかのアクティビティは、そのような開発を正常に完了するために、並列に続行できるか、あるいはしなければならない実在の状況を認識もしないし、適切に反映しもしない。
「Ｔｈｅ Ｆｉｆｔｈ Ｄｉｓｃｉｐｌｉｎｅ： Ｔｈｅ Ａｒｔ ＆ Ｐｒａｃｔｉｃｅ ｏｆ Ｔｈｅ Ｌｅａｒｎｉｎｇ Ｏｒｇａｎｉｚａｔｉｏｎ」（１９９０年、ロンドン、Ｃｅｎｔｕｒｙ Ｂｕｓｉｎｅｓｓ）において、Ｐｅｔｅｒ Ｓｅｎｇｅは、システムに関連する複雑さの２つのタイプ、すなわち「詳細な複雑さ」と「動的な複雑さ」とを区別する。詳細な複雑さは、「多くの変数」の複雑さであり、それらのモデル内の正確なルールを得ようとする、ソフトウェア開発者およびビジネスプロセス・モデラーに良く知られている。一方、動的な複雑さは、システムのエレメント間の予測しない相互作用が意外な効果、特にオーバータイムを持つ、「非自明な結果」の複雑さである。詳細な複雑さのテストは、特別なプログラムまたはシステムが特定のテスト条件の下で期待通りの動きをするかを確認するための繰り返しテストケースが生成される、従来のソフトウェアテスト環境の分野である。シミュレーションの役割は、動的な複雑さを探索することである。
シミュレータは、２つのクラスの１つから考えることができる。これらは以下の通りである：通常それが設計され、組み立てられ、あるいは修正される間、全システムの動力学を理解するために用いられる分析シミュレータ；そして、ゲームまたはトレーニング状況において典型的な複雑な仮想システムで人間と相互作用することが可能であるように使用されるデジタル仮想環境。
分析シミュレータに焦点を合わせると、Ｚｅｉｇｌｅｒ他（ＺｌＥＧＬＥＲ，ＢＥＲＮＡＲＤ Ｐ．；ＰＲＡＥＨＯＦＥＲ，ＨＥＲＢＥＲＴ；ＫｌＭ，ＴＡＮ ＧＯＮ「Ｔｈｅｏｒｙ ｏｆ Ｍｏｄｅｌｌｉｎｇ ａｎｄ Ｓｉｍｕｌａｔｉｏｎ： Ｉｎｔｅｇｒａｔｉｎｇ Ｄｉｓｃｒｅｔｅ Ｅｖｅｎｔ ａｎｄ Ｃｏｎｔｉｎｕｏｕｓ Ｃｏｍｐｌｅｘ Ｄｙｎａｍｉｃ Ｓｙｓｔｅｍｓ」、Ａｃａｄｅｍｉｃ Ｐｒｅｓｓ、１９９９年）は、基本的にシステムをモデル化できる以下の３つの方法があることを示した。微分方程式によって記述される連続的システムとして（微分方程式システム仕様−ＤＥＳＳ）；各離散的期間後のシステム状態を示す方程式のコレクションとして（離散的時間システム仕様−ＤＴＳＳ）；またはシステム状態が１つの離散的イベントからもう１つの離散的イベントまでどのように変化するのかを記述する方程式のコレクションとして（離散的イベントシステム・シミュレーション−ＤＥＶＳ）。ＤＥＶＳシミュレータは、量子化ＤＥＳＳモデルおよびＤＴＳＳのために記述されることができる（Ｚｅｉｇｌｅｒ他、１９９９年、参照）ので、ＤＥＶＳは、３つのシステムモデル化メソッドのキーとして考えられる。
ＤＥＶＳは、システム力学を、以下に示す方程式の集合を通じてモデル化する。それぞれが外部イベントに関連する入力値の集合；状態の集合；出力値の集合；内部状態遷移関数；外部状態遷移関数；出力関数；および休止時間関数。そのようなシミュレーションによって認識された唯一のイベントは、内部イベントを構成する予め決定された期間（すなわち、休止時間）の経過、または外部イベントを構成する入力の到着である。これらの内部および外部イベントは、そのようなシミュレーション内でアクティビティを起こすが、これは、通常オブジェクト指向型プログラミング言語内の逐次プログラムまたはメソッドとして実装される状態遷移関数への粒度の粗いトリガとなる。そのようなシミュレーションモデル内に、時間の経過以外の状態の内部変化がトリガとなるアクティビティを持つのは容易ではない。
並列および分散システムシミュレーション（ＰＤＥＳ−ＦＵＪＩＭＯＴＯ，ＲＩＣＨＡＲＤ Ｍ．「Ｐａｒａｌｌｅｌ ＆ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｉｍｕｌａｔｉｏｎ Ｓｙｓｔｅｍ」、Ｊｏｈｎ Ｗｉｌｅｙ ＆ Ｓｏｎｓ、２０００）において、並列および分散シミュレーションモデルは、ＤＥＶＳシミュレータのコレクションとして記述されることができる。ＰＤＥＳは、典型的に粒度の粗い並列処理（並行処理は別々の逐次論理プロセスを異なるプロセッサに割り当てることを通じて達成される）を提供する。並列および分散シミュレーション間の根本的な相違は、シミュレーションにおける「論理プロセス」間の通信待ち時間である。シミュレーションには、異なる種類の時間が含まれることに注意しなければならない。すなわち、物理時間、シミュレーション時間および壁時計時間であり、これらはＰＤＥＳのために特に重要である。物理時間は、シミュレートされた物理システムにおける時間である。シミュレーション時間は、シミュレーションによって採用されている物理時間の抽出である。これは、通常、シミュレーションのニーズに合わせるために、物理時間をスピードアップしている（だが、それをスピードダウンしてもよい）。壁時計時間は、シミュレーションの実行の間の現実の時間であり、特に分散シミュレーションにとって重要である。
分析シミュレータのいくつかのクラスおよびデジタル仮想環境が、シングルプロセッサおよびマルチプロセッサ（すなわち、並列および分散）アーキテクチャの双方のために定義されているが、そのようなシミュレーションは、逐次状態遷移関数として定義される。これは、新しいシステムまたは変化するシステムの詳細なルールから別々に定義されなければならない。それによって、どのシミュレーションも主な設計の流れから分離され、せいぜい粒度の粗い並列処理に抑制される。これは、シミュレーション・プロジェクトにしばしば大きな見返りが要求されるにもかかわらず、シミュレーションが比較的まれにしか使用されないという１つの理由であるかもしれない。
先行技術は、Ｂｏｒｓｃｈｅｖ他（「Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｉｍｕｌａｔｉｏｎ ｏｆ Ｈｙｂｒｉｄ Ｓｙｓｔｅｍｓ ｗｉｔｈ ＡｎｙＬｏｇｉｃ ａｎｄ ＨＬＡ」、ＸＰ００４３４８２３ＰＤ）のように、そのようなシミュレータのアプリケーションを含む。それは、その他に記述された並列または分散シミュレーションのいくつかの課題に対する潜在的なソリューションと同様に、粒度の粗いイベント駆動型オブジェクト指向アプローチを採用する（例えば、Ｓｔｅｉｎｍａｎ−米国特許第６３２４４９５号明細書）。
上記先行技術のいくつかの重要な制約の特徴は、以下のようである。
フォン・ノイマン・アーキテクチャは、ほとんど全ての現在コンピューティング・ソリューションに「フロー＆ジャンプ」機構を組み込んだ。これは、世界の逐次的／直列的な見方を強化する助けとなる。並行計算モデル（例えば、ＣＳＰ）を定義する際のいくつかのより一般的な試みでさえ、この視点によって抑制され、達成できる並列処理の粒度が限定される。
ハードウェアおよびソフトウェア設計者が、コンピュータをより便利にするように働くにつれて、２つの重要な意味上のギャップが導かれた。第１は、ハードウェア設計者が、パイプラインのような技術を備えるフォン・ノイマン・アーキテクチャの制限を乗り越えようと試みるにつれて、高級言語と基礎となるコンピュータハードウェアとの間で展開されたギャップである。第２は、計算の１つからシステム表現の１つにまで適応されている問題の本質としてより深刻になっている問題分野とソフトウェアとの間のギャップである。
先行技術に記述されるいくつかの方式は、粒度の粗いイベント駆動型および通常のオブジェクト指向型アプローチに採用されている。しかし、それらは、「イベント」、「状態」、「アクション」および「オブジェクト」の定義の多様性、そして実装のためのフォン・ノイマン型逐次ソフトウェア・セグメント（通常、ＯＯ「メソッド」）への依存性の両方によって制約を受けている。
今日使用されているツールの大部分は、それらがサブジェクトシステムの変化の理解として適応する能力のデザイン・インを可能にしないので、システムの理解および設計が不満足なものとなる傾向がある。結果的に、変化は抵抗され、それが最終的に避けられなくなったときに、それは外傷となりうる。例えば、毎年、多額のお金が失敗するＩＴプロジェクトに消費される。
システムの異なるコンポーネント間の相互作用は、その状況のそれらのコンポーネントを見るために異なるツール（異なるモデル化技術のように）を持つ人々によって異なる規律から対処されるので、しばしば見落とされる。多くのＩＴプロジェクトの失敗は、特別な技術的ソリューションの「人員変更管理」の意味を認識できないことによって引き起こされる。なぜならば、主として、アプリケーション開発者および変更管理の専門家は、他の視点の理解を助けるツールおよび言語を欠いている。
本発明は、いくつかの関連概念を提供する。その多くは、個別に、および組み合わせで、潜在的に適応ルール集合の並列実行を可能とし、問題分野とソフトウェアおよびハードウェア・ソリューションの間の意味上のギャップを除去する統一的な全体論的なフレームワークを生成する。総合すれば、これらの概念は、一般の複雑な技術的および社会技術的システム、そして適応可能な大規模なマイクロ並列コンピューティング・システム、自己適応発展可能知能エージェントおよび特に発展可能な事業の分析、設計、構築、試験、実装およびオペレーションに、新しいアプローチを提案する。
本発明の第１の態様によれば、サブジェクトシステムにアクションを生成するためのアクタを提供する。アクタは、前記サブジェクトシステムの内部オブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、前記オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、を含む前記サブジェクトシステムのモデルと、前記モデルの前記ルールによって定義されるように、前記イベントに依存する前記サブジェクトシステムで、１つ以上のアクションを開始することによって、前記サブジェクトシステムにおいてイベントに応答するプロセッサと、を備える。
また、２つ以上の状態のうち１つを持つことができるオブジェクトである限り、唯一の状態を持つことができるモデルにおけるオブジェクトであってもよい。
オブジェクトの状態の全ての変化は、イベントとして考えられてもよい。しかし、重要であるイベントに関連するルールだけ、開始されるべき１つ以上のアクションを必要とする限りにおいて、モデルに含まれることが要求される。
本発明に従って構成されたアクタのプロセッサは、フォン・ノイマン・プログラムカウンタによって生成されたように、恣意的な逐次パラダイムに抑制しなくてもよい。それゆえ、その不利益点を避けるように構成されることができる。
そのように構成されたアクタのプロセッサは、粒度の細かい並列オペレーションをサポートすることができる。
プロセッサがモデルを直接的に実行するので、モデルとプロセッサとの間に意味上のギャップはない。更に、プロセッサによって理解されたフォーマットへのモデルの変形によって引き起こされる開発ステージに意味上のギャップはない。
それを表現するサブジェクトシステムとしてモデルを表現することは、そこにおいて、サブジェクトシステムとモデルとの間の意味上のギャップがないという結果をもたらすことができる。
本発明に従うアクタは、ＯＯ「メソッド」のような詳細なアクションを記述するためのプログラム・コンポーネントに依存しないモデルを使用することを可能にする。
モデルは、粒度の細かい並列アクタ（例えば、コンピュータ、産業機械）を直接的に駆動することができる。モデルは、通常は付加的な言語（例えば、ＵＭＬのためのＯＣＬ）を要求するであろう制約を表現できるように作られることができる。
適切なアクタの構築により、計算だけではなく、広い範囲のサブジェクトシステムをサポートできる。これは、データフローまたはアクタパラダイムに似ておらず、勝っている。
全てのイベントおよびアクションは、オブジェクトとして構成されてもよい。
これは、使いやすいより単純なモデルに寄与する。
プロセッサは、単一のステップで直接的に単一のイベントに応じて開始されたアクションを実行するように調整されてもよい。そのようなアクションは、「基本アクション」として言及されることができる。モデルにおいて、イベントに応じて開始される合成アクションは、合成アクションの実行から直接的または間接的に生じるイベントに応じて開始されるサブ・アクションとして定義されてもよい。各サブ・アクションは、基本アクションであっても、他の合成アクションであってもよい。これは、実在のあるイベントのより正確な表現を可能にし、粒度の細かい並列実行を可能にすると同様に、単純なモデル化を可能にする。１つのレベルで単一のステップで直接的にプロセッサによって実行されることができる基本アクションは、高いレベルのプロセッサが精緻化された基礎となるプロセッサためのより低いレベルの複数のアクションへの精緻化を要求してもよいということに注意すべきである。しかし、この場合、これらのより低いレベルのアクションのそれぞれは、同様に同じ意味でイベント駆動型であろう。
前記モデルは、２つ以上のサブ・モデルを含むようにしてもよく、前記サブ・モデルのそれぞれは、前記サブジェクトシステムのサブ・システムのモデルである。この特徴を使用して、１つのプロセッサは、複数のモデルを操作することができる。
好ましくは、前記アクタは、メタ・モデルおよびメタ・プロセッサを備えるメタ・アクタを含み、前記メタ・モデルは、前記モデル内のオブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、前記モデルにおけるオブジェクトの状態の変化であるイベントに応じてアクションが開始されることを定義するルールと、を含み、前記メタ・プロセッサは、前記メタ・モデルによって定義されるように、前記イベントに依存する前記モデルで、１つ以上のアクションを開始することによって、前記モデルにおいてイベントに応答するように調整される。
ここで、メタ・モデルは明示的であるので、モデルは、実行中に修正されることができ、アクタは、オペレーション中に、例えばコンパイラまたはツールセットの供給者によって前もって修正されたメタ・モデルの要件を潜在的に回避しながら、その動作を適応させることができる。
前記メタ・モデルは前記モデルの部分を形成してもよく、かつ／または前記メタ・プロセッサは前記プロセッサの部分を形成してもよい。これらの特徴により、アクタは、オペレーション中にモデルの新しいタイプを引き受けることができる。
前記メタ・モデルは、２つ以上のサブ・メタ・モデルを含んでいてもよく、前記サブ・メタ・モデルのそれぞれは、前記モデルのサブ・システムのモデルである。このように、１つのメタ・プロセッサは、複数のメタ・モデルを操作することができる。
好ましくは、前記プロセッサのアクションは、ルート・メタ・モデルおよびルート・メタ・プロセッサを備えるルート・メタ・アクタによって生じ、前記ルート・メタ・モデルは、前記モデルと同じタイプのモデルを処理するための一般モデルであって、一般モデル実行システム内のオブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、を含み、前記ルート・メタ・プロセッサは、イベントがトリガされたときに、もしあるならば、どのアクションが開始されるべきかを決定し、当該アクションを開始するために、前記モデルにおける前記イベントの定義を検査する際と、アクションが開始されたときに、もしあるならば、どのオブジェクトがそれらの状態を変化されるべきかを決定し、それに応じて当該オブジェクトの状態を変えるために、前記モデルにおける前記アクションの定義を検査する際と、オブジェクトの状態が変化させられたときに、もしあるならば、どのイベントがトリガされるべきかを決定し、当該イベントをトリガするために、前記モデルにおける前記オブジェクトの定義を検査する際と、に前記ルート・メタ・モデルをガイドするように調整される。
これは、上記された第１のアクタの汎用実現を提供するということができる。
好ましくは、アクタは、メタ・アクタおよびルート・メタ・アクタを含む。
この場合、メタ・モデルが明示的であるので、モデルは、実行中に修正されることができ、アクタは、オペレーション中にその動作を適応させることができる。
前記メタ・モデルは、前記モデルの部分を形成してもよい。これは、また、オペレーション中に、アクタに新しいタイプのモデルを引き受けることを可能にする。代わりに、または加えて、前記ルート・メタ・モデルは、前記メタ・モデルの部分を形成してもよい。これは、ある環境下で実行中に、ルート・メタ・モデルを修正することを可能にする。また、これは、例えばコンパイラまたはツールセットの供給者によって前もって修正されたメタ・モデルの要件を潜在的に回避する。
上記アクタのいずれかにおいて、前記プロセッサ、または１つ以上の多重プロセッサは、前記モデルにおける前記イベントの定義を検査し、もしあるならば、開始すべきアクションがいずれであるかを決定し、その後当該アクションを開始するイベントのトリガに応じて動作可能な１つ以上のアクティベータと、前記アクションを生じるように調整され、かつ、前記モデルのアクションの定義を検査し、もしあるならば、前記サブジェクトシステムにおいて状態を変化するオブジェクトがいずれであるかを決定し、その後それに応じて当該オブジェクトの状態を変化するアクションの開始に応じて動作可能な１つ以上のエグゼキュータと、アクションの出力結果を記録するように調整され、かつ、前記モデルにおける前記オブジェクトの定義を検査し、もしあるならば、前記サブジェクトシステムにおけるいずれのイベントが前記オブジェクトの状態の変化からの結果であるかを決定し、当該イベントをトリガするオブジェクトの状態の変化を認識することに応じて動作可能な１つ以上のレコーダと、前記アクタが他のアクタまたは外部世界に接続される外部チャネルへの１つ以上のインタフェースと、前記アクティベータ、前記エグゼキュータ、前記レコーダおよび前記インタフェースに接続される１つ以上の内部チャネルと、を備える。
メタ・アクタを含む上記アクタにおいて、前記メタ・プロセッサ、または１つ以上の多重メタ・プロセッサは、前記メタ・モデルにおける前記イベントの定義を検査し、開始するモデルのアクションがいずれであるかを決定し、その後当該アクションを開始するイベントのトリガに応じて動作可能な１つ以上のアクティベータと、前記アクションを生じさせるように調整され、かつ、前記メタ・モデルにおけるアクションの定義を検査し、もしあるならば、前記モデルにおいて状態を変化するオブジェクトがいずれであるかを決定し、その後それによって当該オブジェクトを変化させるアクションの開始に応じて動作可能な１つ以上のエグゼキュータと、前記メタ・モデル内のオブジェクトの生成、修正または削除を含み、アクションの出力結果を記録するように調整されており、かつ、前記メタ・モデルにおける前記オブジェクトの定義を検査し、もしあるならば、前記モデルにおけるいずれのイベントが前記オブジェクトの状態の変化からの結果であるかを決定し、当該イベントをトリガするオブジェクトの状態の変化に応じて動作可能な１つ以上のレコーダと、前記アクタが他のアクタまたは外部世界に接続される外部チャネルへの１つ以上のインタフェースと、前記アクティベータ、前記エグゼキュータ、前記レコーダおよび前記インタフェースに接続される１つ以上の内部チャネルと、を備える請求項６から請求項９のいずれかに記載のアクタ。
ルート・メタ・アクタを含む上記アクタにおいて、前記ルート・メタ・プロセッサ、または１つ以上の数の多重ルート・メタ・プロセッサは、前記ルート・メタ・モデルにおける前記イベントの定義を検査し、いずれのアクションを開始するかを決定するイベントのトリガに応じて動作可能な１つ以上のアクティベータと、前記アクションを生じるように調整されており、かつ、前記ルート・メタ・モデルにおける前記アクションの定義を検査し、もしあるならば、前記プロセッサにおいて状態を変化するオブジェクトがいずれであるかを決定し、その後それによって当該オブジェクトを変化させるアクションの開始に応じて動作可能な１つ以上のエグゼキュータと、前記ルート・メタ・モデル内のオブジェクトの生成、修正または削除を含み、アクションの出力結果を記録するように調整されており、かつ、前記ルート・メタ・モデルにおいて前記オブジェクトの定義を検査し、もしあるならば、前記プロセッサにおけるいずれのイベントがオブジェクトの状態の変化からの結果であるかを決定し、当該イベントをトリガするオブジェクトの状態の変化に応じて実施可能な１つ以上のレコーダと、前記アクタが他のアクタまたは外部世界に接続される外部チャネルへの１つ以上のインタフェースと、前記アクティベータ、前記エグゼキュータ、前記レコーダおよび前記インタフェースに接続される１つ以上の内部チャネルと、を備える。
これらの特徴は、上記アクタによって基本的なイベント駆動型実行サイクルを反映することを可能にするコンポーネントへのプロセッサの分解を可能にする。イベント駆動型実行サイクルの実装は、このように粒度の細かい並列処理を可能にする。接続は、バス、リングのようなチャネルシステム、またはその他のチャネル・トポロジによって達成されることができる。
アクティベータ、エグゼキュータ、レコーダ、インタフェースまたはチャネルの１つ以上が、上に列挙されたように、アクタであってよい。これは、同じモデルに従って、プロセッサ・コンポーネントの分解を可能にする。
上記アクタのいずれかにおいて、前記モデルは、仮想アクタのａ）プロセッサ、ｂ）メタ・プロセッサまたはｃ）ルート・メタ・プロセッサの１つで構成されるプロセッサ・エンティティを精緻化し、その結果、前記プロセッサ・エンティティは、第１のアクタのプロセッサ、メタ・プロセッサまたはルート・メタ・プロセッサのいずれかによって直接的に実行され得る請求項１から請求項１７のいずれかに記載のアクタ。これは、物理プロセッサ上の仮想プロセッサの階層化を提供する。
このようなアクタは、シミュレータであってよく、その場合、前記アクタは、代理サブジェクトシステムにおいてアクションを開始し、シミュレーション、物理および壁時計時間の関係を処理し、第１のアクタの詳細なモデルで定義される内部および外部イベントの配分を処理し、シミュレートされたアクタの生成および削除、ならびにシミュレートされたモデル内における役割の割り当ておよび再割り当てを処理し、シミュレートされたアクタから物理アクタへの割り当ておよび精緻化を処理するルールを更に含むモデルを含む。
これは、動的分析、あるいはゲームまたはトレーニングのいずれかのために、類似するアーキテクチャ内で、アクタのシミュレーションを可能にできる。
いずれのケースにおいても、前記仮想アクタは、更なる仮想アクタのプロセッサ・エンティティを精緻化するために調整されてよい。これは、例えば、オペレーティング・システムにおける使用のために、仮想プロセッサの多重レイヤを提供する。
精緻化モデルを含むこれらのアクタのいずれにおいても、前記モデルは、２つ以上のサブ・モデルを含み、前記サブ・モデルのそれぞれは、１つ以上の他の仮想アクタのプロセッサ・エンティティの動作を精緻化する請求項１８から請求項２０のいずれかに記載のアクタ。これは、単一の物理プロセッサによって、多重仮想プロセッサをサポートすることを可能にする。
本発明は、また、上記されたアクタを２つ以上備え、各アクタが、それぞれ少なくとも１つの他のアクタに各自のチャネルを経由して接続された、共通サブジェクトシステムにおいてアクションを生じさせるために調整されるシステムを提供する。チャネルは、アクタを互いに通信させることが可能である。
前記各アクタは、前記アクタの部分を形成する第１のインタフェース、および前記チャネルの部分を形成する第２のインタフェースによって、各自の前記チャネルに接続されてもよい。従って、チャネルは、アクタにインタフェースを提供する。
いずれかまたは全てのチャネルまたはインタフェースは、上記のようなアクタであってもよい。このように、いくつかまたは全てのチャネルおよび／またはインタフェースを提供することは、本発明のアクタと関連して、上に概説した利点をもたらすことができる。
上に概説したアクタは、上に概説したようなシステムを備えてもよい。これは、アクタに、アクタのシステムを備えることを可能にする。
本発明の第２の態様によれば、サブジェクトシステムにおいてアクションを生じさせるためのアクタを含む論理型コンピューティング・デバイスであって、前記サブジェクトシステムの内部オブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、前記オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、を含む前記サブジェクトシステムのモデルを実装する手段と、前記モデルの前記ルールによって定義されるように、前記イベントに依存する前記サブジェクトシステムで、１つ以上のアクションを開始することによって、前記サブジェクトシステムにおいてイベントに応答するプロセッサを実装する手段と、を備えるデバイスが提供される。
これは、本発明のアクタから導き出されるような、上に挙げられた全ての利益をコンピューティング分野に供給できる論理型コンピューティング・デバイスを提供する。
この論理型コンピューティング・デバイスのプロセッサは、１つ以上のアクティベータ、１つ以上のエグゼキュータ、１つ以上のレコーダ、１つ以上の内部チャネルおよび１つ以上のインタフェースを備えてもよい。これは、粒度の細かい並列オペレーションが可能であるデバイスを提供する。これは、逐次的であることが必須であるフォン・ノイマン・パラダイムとは似ていない。これは、また、粒度の粗い並列処理だけをサポートするＣＳＰパラダイムとも似ていない。これは、また、データフローまたはアクタパラダイムのいずれかよりも一般的な状況に適用可能である。
好ましくは、少なくとも１つのアクティベータは、イベント待ち行列におけるアイテムへの参照を含むように動作可能なイベント待ち行列レジスタと、現在のイベントへの参照を含むように動作可能なイベントレジスタと、現在のイベントのタイプを含むように動作可能なイベントタイプレジスタと、を含む。これらの特徴は、従来のフォン・ノイマン・コンピュータのプログラムカウンタを置き換えると考えることができる。
有利なことに、少なくとも１つのエグゼキュータは、アクション待ち行列におけるアイテムへの参照を含むように動作可能なアクション待ち行列レジスタと、現在のアクションへの参照を含むように動作可能なアクションレジスタと、現在のアクションのタイプを含むように動作可能なアクションタイプレジスタと、を含む。これらの特徴は、命令レジスタと、更に命令デコーダと共に従来のフォン・ノイマン・コンピュータの制御ユニットを置き換えると考えることができる。
このようなデバイスは、単一の処理ユニットまたは集積回路に共に設けられている、単一のアクティベータ、単一のエグゼキュータ、単一のレコーダ、１つ以上の内部チャネルおよび１つ以上のインタフェースを備えてもよい。これは、単一のＣＰＵを有する従来のコンピュータと同等に、デバイスが単一のプロセッサを使用して実装されることを可能にする。しかし、それは、アクタのモデルを処理する能力があり、ここでは直接的には並列モデルである。
代わりに、デバイスは、単一のアクティベータ、単一のエグゼキュータ、単一のレコーダおよび１つ以上のインタフェースを備えてもよい。これらのコンポーネントのそれぞれは、各自の処理ユニットまたは集積回路に設けられ、コンポーネントは１つ以上のチャネルを経由して互いに接続されている。これは、修正なしに、しかしより大きなスループットで同等の並列モデルを直接的に処理する能力がある多重プロセッサの実装を提供する。これは、並列に実行させることを可能にするプログラムに実体化されたシステムの逐次的な記述を変換するために、かなりの複雑さを加えがちな従来の多重ＣＰＵアーキテクチャに、現実的な等価物を持たない。
ここで、複数のアクティベータは、１つ以上のチャネルを経由して接続されることができ、少なくとも２つのアクティベータは、共通イベント待ち行列を共有してもよい。これは、粒度の細かい並列起動の準備に関係する。
また、複数のエグゼキュータは、１つ以上のチャネルを経由して接続されることができ、少なくとも２つのエグゼキュータは、共通アクション待ち行列を共有することができる。これは、粒度の細かい並列実行の準備に関係する。
更に、複数のレコーダは、１つ以上のチャネルを経由して接続されることができ、少なくとも２つのレコーダは、共通オブジェクト待ち行列を共有することができる。これは、粒度の細かい並列記録の準備に関係する。
アクティベータまたは１つ以上のアクティベータは、それぞれ、上記論理型デバイスのいずれかを備えてよい。エグゼキュータまたは１つ以上のエグゼキュータは、それぞれ、上記論理型デバイスのいずれかを備えてよい。レコーダまたは１つ以上のレコーダは、それぞれは、上記論理型デバイスのいずれかを備えてよい。これらの特徴は、スループットを増加させるのと共に、大規模並列プロセッサの実装を可能にする。
２つ以上のコンポーネントは、異なる配置に分散してもよい。本発明はコンピューティング・デバイスを、それらを同じ物理配置にする必要性なしに多重接続コンポーネントで形成することが可能であるので、これは可能である。
１つの精緻化モデルを含む上記アクタのいずれにおいても、アクタのモデルは、フォン・ノイマン型アーキテクチャを備えるコンピュータまたはコンピュータシステム上、もしくは、フォン・ノイマン型アーキテクチャを備えるコンピュータまたはコンピュータシステムのリソースを管理あるいは単純インタフェースを提供するオペレーティング・システム上で、プロセッサ、メタ・プロセッサまたはルート・メタ・プロセッサの精緻化を可能にするルールを含むようにしてもよい。これは、従来のフォン・ノイマン・ハードウェアに、疑似ルート・メタ・アクタ型コンピューティング・システムまたはデバイスのように動作することを可能にする。
本発明のもう１つの態様は、複数のリソースを持つコンピュータシステムを提供する。各リソースは上記のようなアクタまたはコンピューティング・デバイスによって管理され、上記のようなアクタまたはコンピューティング・デバイスのサブジェクトシステムを構成する。これは、パーソナル・コンピューティング・システムのように、密結合または疎結合の統合コンピューティング・システムを提供する構成を可能にする。インタフェース・アクティビティを専用インタフェースプロセッサに分配することは、そのようなアクティビティに含まれていることから基本プロセッサを自由にでき（従来のフォン・ノイマン・プロセッサとは似ていない）、基本プロセッサのスループットを潜在的に著しく増加する。
本発明のもう１つの態様は、上記アクタのうちのある１つ、および、アクタのモデルを、フォン・ノイマン・コンピュータ、またはコンピュータシステム、またはフォン・ノイマン・コンピュータもしくはコンピュータシステムのリソースを管理する、あるいはそれらにより単純なインタフェースを供給するオペレーティング・システムの、オブジェクトまたはコードに静的に変換する、フォン・ノイマン・コンピュータまたは階層化オペレーティング・システムのモデルを使用するように調整されたコンパイラを提供する。有利に、コンパイラは、アクタのモデルを静的に変換するように調整されたメタ・トランスレータおよびハードウェア・メタ・モデルを含む。これらの特徴は、アクタ型モデル、メタ・モデルまたはルート・メタ・モデルに、従来のフォン・ノイマン・ハードウェア上で静的に変換される、もしくは動作されること、または従来の、例えば階層化された、オペレーティング・システムを使用することを可能にする。
上記のような、精緻化モデルと共に複数のアクタを備えるシステムは、コンピュータシステムのリソースを管理すると共に、コンピュータシステム上で１つ以上のモデル、メタ・モデルまたはルート・メタ・モデルの同時実行を可能とするように調整されてもよい。このシステムは、本明細書に記述される有利な原則に従って動作するオペレーティング・システムを構成することができる。コンピュータシステムは、フォン・ノイマン型コンピュータまたはコンピュータシステムであってもよく、また、それは、ルート・メタ・アクタ論理型コンピューティング・デバイスまたはそのようなデバイスのシステムであってもよい。
代理サブジェクトシステムにおいてアクションを開始し、精緻化モデルを含むアクタを用いて、プロセッサは、上に定義されるような論理型コンピューティング・デバイスを構成してもよい。これは、大規模並列シミュレーションを可能にする。大規模並列シミュレーションを管理する複雑さは、たとえ並列であっても、従来のフォン・ノイマン・ハードウェア上で実行される状況と比べると、相当に減らすことができる。
本発明の第３の態様によれば、フォン・ノイマン型コンピュータのモデル、または、フォン・ノイマン型コンピュータの資源を管理もしくはフォン・ノイマン型コンピュータにより単純なインタフェースを提供するオペレーティング・システムのモデルを使用し、アプリケーションモデルにおけるオブジェクトを表し、所定の時間に２つの以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、前記オブジェクトの状態の変化であるイベントに応じて開始されるアクションを定義するルールと、を備えるアプリケーションモデルを、フォン・ノイマン型コンピュータもしくはコンピュータシステム、または、フォン・ノイマン型コンピュータもしくはコンピュータシステムの資源を管理する、あるいは当該フォン・ノイマン型コンピュータもしくはコンピュータシステムにより単純なインタフェースを提供するオペレーティング・システム、のオブジェクトまたは機械またはアセンブラ・コードに静的に変換するコンパイラを提供する。
このことは、上述したアクタと同様に、イベント型並列アクションを実装するために、従来のコンピュータまたはオペレーティング・システムの使用を可能にするコンパイラを提供する。アプリケーションモデルは、請求項のアクタのモデルの他の特徴のいずれかを付加的に含んでいてもよい。
本発明は、また、上記のアクタのうち第１から第５のアクタで構成され、当該第１から第５のアクタは、それぞれ、オペレーションまたは変形プロセスを実行するように動作可能であるオペレーティングアクタ、システムの目的およびパフォーマンス目標を決定し、かつ当該目的およびパフォーマンス目標を他のアクタに提供するように動作可能であるディレクティングアクタ、前記ディレクティングアクタによって提供された目的およびパフォーマンス目標を達成するために、前記システム内の他のアクタの全てを制御するために動作可能であるマネージングアクタ、他のアクタそれぞれの部分を形成する少なくとも１つのモデルを開発および保守するために動作可能である学習アクタ、第１〜第５のアクタの責務を達成するために動作可能であるサブ・アクタを提供するために動作可能である実現アクタ、であるシステムを提供する。これは、これを用いて発展可能システム（すなわち、人工知能エージェントまたはビジネス企業のように、分離された存在を維持できるシステム）が形成されることができるコンポーネントを提供する。
１つ以上の前記第１から第５のアクタは、それぞれ直上のパラグラフに記述されるようなシステムを備えていてもよい。これは、再帰的に定義される発展可能システムを提案する。これは、特に、発展可能な知能エージェントまたは発展可能なビジネス企業のような、複雑な発展可能システムの設計時に有用である。
上記のような第１〜第５のアクタを備えるシステムにおいて、前記オペレーティングアクタは、オブジェクト、アクション、およびイベントについてのルールをモデル化し、目標システム、問題システム、および機会システムの１つ以上におけるアクタの役割の割り当ておよび精緻化をし、詳細なルールを試験して結果システムの動きを分析するために結果モデルをシミュレートすることによって、何を変化させる必要があるかを決定する前記目標システムにおける問題または機会を調査する調査サブ・システムと、前記調査サブ・システムが、調査システムでモデル化された目標システムおよび他のシステムにおけるオブジェクト、ルール、およびアクタのモデル化によって、ならびに、詳細なルールを試験して結果システムの動きを分析するために結果モデルをシミュレートすることによって、目標システムに対する変化をモデル化およびシミュレートするのを完了したことに応答する開発サブ・システムと、前記調査サブ・システムが、調査システムでモデル化された目標システムおよび他のシステムにおけるオブジェクト、ルール、およびアクタのモデル化によって、ならびに、詳細なルールを試験して結果システムの動きを分析するために結果モデルをシミュレートすることによって、変化を展開できる一時システムをモデル化およびシミュレートするのを完了したことに応答する準備サブ・システムと、前記開発サブ・システムおよび前記準備サブ・システムが、前記準備サブ・システムにおいてモデル化およびシミュレートされたシステムを実行し、ならびに前記開発サブ・システムにおいてモデル化およびシミュレートされた変化を配置するのを完了したことに応答する配置サブ・システムと、を備える変化システムを操作可能なように有利に調整される。
これは、システム開発のためのルート・メタ・アクタ型アプローチに適用され、発展可能学習システムとしてシステムプロジェクトを確立することを可能にする。発展可能学習システムは、他の発展可能学習システムと同じ機構を使用して目標システムを生成または変更するために、指示され、操作され、管理され、可能にされ、適応される。
本発明の第４の態様によれば、サブジェクトシステムにアクションを生成する方法であって、前記サブジェクトシステムの内部オブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、前記オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、を含む前記サブジェクトシステムのモデルを維持し、前記モデルの前記ルールによって定義されるように、前記イベントに依存する前記サブジェクトシステムで、１つ以上のアクションを開始することによって、前記サブジェクトシステムにおいてイベントに応答するプロセッサを制御する方法を提供する。
アクタ発明について上に概説された全ての利益と同様に、この方法は、コンピュータ、機械類、人間および組織を含むアクタの多くのクラスに付加的に適用可能であり、それゆえ複雑な社会技術システムの設計および開発をサポートすることができる。
本発明の第５の態様によれば、サブジェクトシステムにおいてアクションを生じさせる方法であって、前記サブジェクトシステムの内部オブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、前記オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、を含む前記サブジェクトシステムのモデルを実装する手段を、論理型コンピューティング・デバイスにおいて維持し、前記モデルの前記ルールによって定義されるように、前記イベントに依存する前記サブジェクトシステムで、１つ以上のアクションを開始することによって、前記サブジェクトシステムにおいてイベントに応答するプロセッサを実装する手段を、前記論理型コンピューティング・デバイスにおいて維持する方法を提供する。
本発明の第６の態様によれば、フォン・ノイマン型コンピュータのモデル、または、フォン・ノイマン型コンピュータの資源を管理もしくはフォン・ノイマン型コンピュータにより単純なインタフェースを提供するオペレーティング・システムのモデルを使用し、アプリケーションモデルにおけるオブジェクトを表し、所定の時間に２つの以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、前記オブジェクトの状態の変化であるイベントに応じて開始されるアクションを定義するルールと、を備えるアプリケーションモデルを、サブジェクトシステムにおいて動作するように、フォン・ノイマン型コンピュータもしくはコンピュータシステム、または、フォン・ノイマン型コンピュータもしくはコンピュータシステムの資源を管理する、あるいは当該フォン・ノイマン型コンピュータもしくはコンピュータシステムにより単純なインタフェースを提供するオペレーティング・システム、のオブジェクトまたは機械またはアセンブラ・コードに静的に変換するコンパイラを制御する方法を提供する。
本発明の第７の態様によれば、サブジェクトシステムをモデル化する方法であって、前記サブジェクトシステムの内部オブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、前記オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、実行により直接的または間接的に生じるイベントに応じてそれぞれが開始されるサブ・アクションとして、イベントに応じて開始された合成アクションを定義するルールと、を含む前記サブジェクトシステムのモデルを維持する方法を提供する。
本発明の第８の態様によれば、システムを操作する方法であって、イベントがトリガされたときに、もしあるならば、どのアクションが開始されるべきかを決定し、当該アクションを開始するために、前記イベントの定義を検査し、アクションが開始されたときに、もしあるならば、どのオブジェクトが状態に関して変化されるべきかを決定し、それに応じて当該オブジェクトを変えるために、前記アクションの定義を検査し、オブジェクトの状態が変化させられたときに、変化した状態がいずれかのイベントをトリガすべきか否かを決定し、当該イベントをトリガするために、前記オブジェクトの状態変化の定義を検査する方法を提供する。
本発明の第９の態様によれば、システムを操作する装置であって、前記イベントの定義を検査し、開始すべきアクションがいずれであるかを決定し、決定した当該アクションを開始するイベントのトリガに反応する１つ以上のアクティベータと、前記アクションの定義を検査し、状態にかんして変化されるべきオブジェクトがいずれであるかを決定し、当該決定に応じたオブジェクトの状態を変化させるアクションの開始に反応する１つ以上のエグゼキュータと、前記オブジェクトの状態変化の定義を検査し、いずれのイベントがトリガされるべきであるかを決定し、決定した当該イベントをトリガするオブジェクトの状態の変化に反応する１つ以上のレコーダと、を備える装置を提供する。
第８および第９の態様は、本当のイベント型システムオペレーションを可能にすることができ、ある実装においてはフロー・ジャンプ・コンピューティングの回避を完全に可能にすることができる。
本明細書において、いくらかの用語に、以下のような意味を与える。
プロセッサ：モデルによってガイドされるサブジェクトシステムにおいて、アクションを生成するもの。
サブジェクトシステム：状態を持ち、実体的または概念的に相互作用するオブジェクトのコレクション。コレクションは、オブザーバまたはモデラによって定義されるように環境内に分離した存在を持つ。そして、それは、１つ以上のアクタによって生じるアクションのサブジェクトである。
サブジェクトシステムにおけるオブジェクト：実体的または概念的なもの。サブジェクトシステムにおけるいくつかのオブジェクトは、２つの以上の状態を持つことができる。サブジェクトシステムにおけるオブジェクトは、物理的な３次元項目であってもよい。いくつかの実施形態において、サブジェクトシステムにおけるオブジェクトは、人的、技術的、金融的または他のリソースのような発展可能なビジネスシステムのコンポーネントであってもよい。
モデルにおけるオブジェクト：サブジェクトシステムにおけるオブジェクトを表し、２つの以上の異なる状態を持ってもよいもの。
イベント：オブジェクトの離散的状態における瞬間的な変化。
アクティベータ：イベントに応答して、１つ以上のモデルからいずれのアクションを開始するかを決定する物理または仮想アクタあるいはデバイス。
エグゼキュータ：１つ以上のモデルに従って、１つ以上のオブジェクトを変化させるためのアクションを生成する物理または仮想アクタあるいはデバイス。
レコーダ：１つ以上のモデルの部分を形成するオブジェクトを管理し、そのようなオブジェクトの離散状態の変化がそれらと同じモデルに従うイベントをトリガする時を認識する物理または仮想アクタあるいはデバイス。
エラボレータ：典型的により低いレベルの別のプロセッサ上での直接実行を可能にするプロセッサの動作を明確に解釈する物理または仮想アクタあるいはデバイス。
本発明の実施形態の例を、添付図面を参照して説明する。
図１０を参照すると、本発明が実施されるアクティブシステムが図示されている。このシステムにおいて、アクタ１０−１は、サブジェクトシステム１０−２にアクションを生成（１０−４）することができる。アクタ１０−１およびサブジェクトシステム１０−２は、サブジェクトシステム１０−２に影響を与えることができる環境１０−３に存在する。アクタ１０−１もサブジェクトシステム１０−２も、環境１０−３を制御しない。
アクタ１０−１は、図１１Ａにて詳しく説明される。ここで、アクタ１０−１は、モデル１１−１およびプロセッサ１１−２を含むことが分かる。プロセッサ１１−２は、モデル１１−１によってガイド（１１−５）される。プロセッサ１１−２は、サブジェクトシステム１０−２においてアクションを生成（１１−４）するように調整されている。プロセッサ１１−２はアクタ１０−１の部分を形成するので、サブジェクトシステム１０−２におけるアクションの生成（１１−４）は、図１０におけるアクションの生成（１０−４）と同じものである。サブジェクトシステム１０−２は、アクタ１０−１の部分を形成するモデル１１−１によって理解（１１−３）されている。これは、モデル１１−１、プロセッサ１１−２、およびサブジェクトシステム１０−２を含むループを完成する。これにより、アクタ１０−１は、サブジェクトシステム１０−２のモデル１１−１によって、サブジェクトシステム１０−２上でのアクション１１−４をガイドされることができる。したがって、アクタ１０−１は、「モデル型アクタ」といえる。
イベントは、モデル１１−１によってガイドされるアクタ１０−１のアクションを通じてか、あるいはサブジェクトシステム１０−２に作用する他のアクタ（図示せず）のアクションを通じてか、あるいはサブジェクトシステムそれ自体の状態における変化（例えば、化学反応の進行）またはその環境１０−３の状態における変化（例えば、時間の経過）を通じてかのいずれかで、サブジェクトシステム１０−２に起こり得る。アクタ１０−１は、それ自身のアクションによってモデル１１−１を最新に保つ。プロセッサ１１−２は、モデル１１−１に従って処理するときに、モデル１１−１を、中間アクションおよびサブジェクトシステム１０−２において生成するアクションにより更新する。アクタ１０−１は、イベント、すなわち、他のアクタのアクションによって、あるいはサブジェクトシステムそれ自体またはその環境１０−３の状態の変化によって引き起こされた、サブジェクトシステム１０−２におけるオブジェクトの状態の変化を検知することができる。
図１１Ｂに示されるように、サブジェクトシステム１０−２は、３つの異なるルートを経由する３つの方法でモデル１１−１「に理解される」。第１のルート１１−６は、サブジェクトシステム１０−２を識別し、オブジェクト、イベント、アクション等、重要と考えるものに関して、そのモデル１１−１を構築するモデラ１１−７を経由する。これは、プロセッサ１１−２のアクションをガイドするルールがモデル１１−１において確立される機構である。モデラ１１−７は、システムの環境１０−３にあり、アクタ１０−１から分離されるように、図１１Ｂに示される。しかしながら、本発明のある態様においては、モデラ１１−７は、アクタ１０−１の部分である。例えば、メタ・プロセッサがプロセッサまたはルート・メタ・プロセッサと分離されていようが、その部分であろうが、それを含むアクタ１０−１において、モデラ１１−７の役割は、メタ・プロセッサをガイドするメタ・モデル内に含まれるルールに従ってメタ・プロセッサによって引き受けられる。これは、例えば、図１５のアクタに関連する以下の記述を追うことによって理解されるだろう。第２のルート１１−８は、サブジェクトシステム１０−２においてイベントまたはオブジェクトの状態の変化を検出するために、センサ１１−９を使用するプロセッサを経由している。プロセッサ１１−２は、ルート１１−１０を経由して、サブジェクトシステム１０−２の現在の状態、およびサブジェクトシステムにおいて認識されるイベントでモデルを更新する。第３のルート１１−１２は、特に、プロセッサ１１−２がイフェクタ１１−１１を経由してサブジェクトシステム１０−２に生成する、中間アクションを含むアクションの出力結果でモデル１１−１を更新するための、プロセッサ１１−２による直接的なモデル１１−１の更新である。ルート１１−８、１１−１０、および１１−１２はいずれも、図１１Ａのルート１１−３と等価である。
モデル１１−１は、図１２に詳細に示されている。モデル１１−１は、サブジェクトシステム１０−２を、それがサブジェクトシステム１０−２内の重要なオブジェクトを表すオブジェクト１２−３を含み、各オブジェクト１２−３の状態１２−１のいずれの変化が、プロセッサ１１−２によって開始されるアクション１２−４を順に引き起こすイベント１２−２をトリガすべきかを定義するルールを持つという意味で「理解」する。図１２において、オブジェクト１２−３の状態１２−１の変化、またはオブジェクト１２−３の生成もしくは削除を反映するイベント１２−２は、アクション１２−４を開始する。各アクション１２−４は、１つ以上のオブジェクト１２−３において変化を生じさせることができる。イベント１２−２なしに開始されるアクション１２−４はない。モデル１１−１は、それゆえ、イベント駆動型モデルとして記述されることができる。この図において、矢印は、各オブジェクト（状態、イベント、またはアクション）から他のオブジェクト（状態、イベント、またはアクション）への参照を表す。したがって、例えば、アクション１２−４とイベント１２−２との間の矢印１２−５は、アクション１２−４が唯一のイベント１２−２によって開始されることを示す。一方、１つのイベント１２−２は、１つ以上のアクション１２−４を開始することができる。アクション１２−４とオブジェクト１２−３との間の両矢印１２−８は、各アクション１２−４が１つ以上のオブジェクト１２−３における変化を生じさせることができ、かつ各オブジェクト１２−３は１つ以上のアクション１２−４によって変化され得ることを示す。矢印１２−９は、状態１２−１が１つのオブジェクト１２−３のみに関連することを示す。イベント１２−２は、矢印１２−６によって示される１つの状態から、矢印１２−７によって示される他の状態までの、オブジェクト１２−３の状態１２−１における瞬間的な変化である。オブジェクト１２−３の生成または削除は、存在と非存在との間の状態における変化として考えられる。
アクションの出力結果は、モデル内におけるオブジェクトの生成、修正、または削除を含んでいてもよい。それら出力結果はそれぞれ、オブジェクトの状態における変化であると考えられる。オブジェクトは、生成または破棄される代わりに、それぞれアクティブまたは非アクティブにされてもよく、これは結果として、オブジェクト処理をより容易にすることができる。
プロセッサ１１−２は、図１３において詳細に示されている。ここで、イベント１２−２は、それに依存する１つ以上のアクション１２−４を開始することによって応答される。イベント１２−２に依存するアクション１２−４は、モデル１１−１によって定義される。各アクション１２−４は、１つ以上のオブジェクト１２−３を変化させることができる。オブジェクト１２−３の変化は、１つ以上の更なるイベント１２−２をトリガすることができる。これは、イベント実行サイクルと呼ぶことができる。イベント実行サイクルは、アクション１２−４によって、またはオブジェクト１２−３の変化（例えば、環境１０−３のイベントから）によって、新しいイベント１２−２が生成されなくなり、全てのイベント１２−２が処理されて完了するまで続く。
図１１〜１３のシステムのアプリケーションを図示する、例えば、エンジン動力計の自動化制御において使用されるようなイベント駆動型制御モデルは、図１４に示される。図２２Ａは、図１４へのキーである。図１４のモデルにおいて、実行は、図の左手側に示される６つのオブジェクトの生成によって開始する。以下では、「アクセル」は、「アクセラレーション」の短縮形式として使用される。アクセル率１４−１、アクセル期間１４−２１、エンジン速度１４−３、および最終アクセル時刻１４−４をラベル付けられるオブジェクトのそれぞれの生成は、順にアクションを開始するイベントをトリガーする。この場合には、これらのオブジェクトのそれぞれの初期値をセットする。モデルの開始イベント１４−５が、ある他の残りのアクティビティを開始するまでは、これ以上のことは何も起こらない。第１のアクション１４−６は、アクセル乗算器１４−２の値を計算する。アクション１４−６の完了は、現在時刻オブジェクト１４−８に０１：００の時刻を割り当てるための更なるアクション１４−７を開始する。現在時刻オブジェクト１４−８への値の割り当ては、下記のように、変化イベント１４−２０をトリガする。この時刻割り当てアクション１４−７の完了は、また、現在時刻オブジェクト１４−８によって与えられた値を、この例では、アクション１４−９の入力として与えられた７２：００（すなわち、７２時間）がセットされたモデルの最終時刻と比較するアクション１４−９を、その後開始するできる２つの可能なイベントのうちの一方である。アクション１４−９が「真」の状態で完了した場合、モデルは、アクション１４−１０で１時間ずつ現在時刻１４−８をインクリメントすることによって、継続する。インクリメントするアクション１４−１０の完了は、アクション１４−９による現在時刻オブジェクト１４−８の値の最終時刻の値との比較を開始する第２のイベントである。
図１４のモデルを詳細に観察すると、基本処理サイクルが従来の「フロー」の制御によっては進行しないが、代わりに、オブジェクトの状態の変化を認識するイベント、または１つ以上のさらなるアクションのイニシエータとしてのアクションを通じて進行することが明らかである。アクションおよびイベントは、特化されたタイプのオブジェクトである。例えば、現在時刻オブジェクト１４−８の値がアクション１４−７またはアクション１４−１０によって変化させられたときはいつも、イベント１４−２０は、順にアクション１４−１２での現在時刻オブジェクト１４−８の値と最終アクセル時刻オブジェクト１４−４の値との差を求め、結果値をアクション１４−１３でのアクセル期間オブジェクト１４−２１の値と比較する合成アクション１４−１１を開始する。ここで、アクセル期間オブジェクト１４−２１の値は、アクション１４−１４によって、最初は０６：００（すなわち、６時間）にセットされる。アクション１４−１３の結果がアクセル期間オブジェクト１４−２１の値より大きい場合、２つの並列アクション１４−１５、１４−１６が開始される。これらのアクションのうち第１の並列アクション１４−１５は、最終アクセル時刻オブジェクト１４−４の値を現在時刻オブジェクト１４−８の値にセットし、第２の並列アクション１４−１６は、モデルの始めで計算されたアクセル乗算器オブジェクト１４−２の値を使用して新しいエンジン速度を計算する。同様に、エンジン速度１４−３の値が変化させられるときはいつも、イベント１４−１７がトリガされ、このモデルが接続され得る自動化制御システムで利用できるであろう、現在時刻およびエンジン速度オブジェクト１４−８、１４−３の値を印刷するアクション１４−１８を順に開始する。この他のアクションも図１４に示されているが、その目的および効果は、当業者にとって自明であるだろう。この例において、イベントは、しばしばアクションの完了によって引き起こされるが、またオブジェクトの変化によって引き起こされてもよい。
図１５は、環境１０−３内のサブジェクトシステム１０−２に作用するルート・メタ・アクタ１５−０を示す。ルート・メタ・アクタ１５−０は、図１１〜１３に示されたアクタ１０−１の拡張である。図１１〜１３に示されるシステムと同様に、モデル１１−１は、プロセッサ１１−２をガイド（１１−５）する。モデル１１−１それ自体は、メタ・モデル（ＭＭ）１５−１によって理解される。メタ・モデル１５−１は、モデル１１−１に含まれ、かつモデル１１−１の部分を形成してもよい。よって、モデル１１−１は、自らのモデル（メタ・モデル１５−１）を含むと考えることができる。メタ・モデル１５−１は、モデル（モデル１１−１）のモデルである。すなわち、それは、そのサブジェクトシステムが別のモデル（モデル１１−１）であるモデルである。メタ・モデル１５−１は、メタ・プロセッサ（ＭＰ）１５−２をガイドする。メタ・プロセッサ１５−２は、プロセッサ１１−２に含まれ、かつプロセッサ１１−２の部分を形成してもよい。メタ・プロセッサ１５−２は、モデル１１−１にアクションを生成する。あるいは、メタ・プロセッサ１５−２は、プロセッサ１１−２の外部にあってもよい。
メタ・モデル１５−１は、含まれるオブジェクトのタイプと、これらオブジェクトのタイプを関連付ける方法と、を定義することによって、モデル１１−１の構造を形づくる。メタ・モデル１５−１は、また、モデル１１−１におけるアクションの生成に採用されるイベントおよびアクションの有効な組み合わせを定義することによって、モデル１１−１内の動作を形づくる。メタ・モデル１５−１によるモデル１１−１の制御は、モデル１１−１における全てのアクションが生成するメタ・プロセッサ１５−２を経由して行われる。したがって、メタ・プロセッサ１５−２は、また「モデルアダプタ」と呼ばれてもよい。
メタ・モデル１５−１およびメタ・プロセッサ１５−２がモデル１１−１およびプロセッサ１１−２の外側にそれぞれ位置する場合、メタ・モデル１５−１それ自体内にアクションまたは変化が生成されることはない。しかし、メタ・モデル１５−１がモデル１１−１の部分で、メタ・プロセッサ１５−２がプロセッサ１１−２の１つのコンポーネントまたは関数である場合、示されているように、メタ・モデル１５−１は、プロセッサ１１−２によって適応されることができる。換言すれば、モデル１１−１は、それ自体のモデル（モデル１５−１）を反射的に含み、したがって、モデル１１−１の構造およびプロセッサ１１−２の動作（モデル１１−１によってガイドされる）が、ルート・メタ・アクタ１５−０の動作中に変化させられることができる。これは、上記先行技術に記述されたメタ・オブジェクト・フレームワークおよびメタ・オブジェクト・プロトコル・アプローチとは著しく対照的である。
メタ・モデル１５−１およびメタ・プロセッサ１５−２の組み合わせの概念は、図１１〜１３に示されるアクタのモデル１１−１およびプロセッサ１１−２の組み合わせと類似するパターンを追うことで知ることができる。
メタ・アクタ１５−２、１５−１のサブジェクトシステムは、１つ以上のモデル１１−１のシステムである。メタ・プロセッサ１５−２は、また、基本サブジェクトシステム１０−２のモデル化においてアクタ１１−１、１１−２のためのモデラとして作用する。メタ・アクタ１５−２、１５−１のためのメタ・モデラは、メタ・モデル１５−１がモデル１１−１の部分でなければ、メタ・アクタ１５−２、１５−１（およびアクタ１１−１、１１−２）の外部にある。しかし、メタ・モデル１５−１がモデル１１−１の部分であれば、メタ・プロセッサ１５−２は、モデラと同様に、メタ・モデラの役割を引き受ける。
プロセッサー１１−２は、ルート・メタ・モデル１５−３が同じクラスのプロセッサ１１−２によって共有されるモデル実行のための汎化モデルであるという意味で、メタ・モデル１５−１の部分を形成するルート・メタ・モデル（ＲＭ）１５−３によって理解されている。ルート・メタ・モデル１５−３は、また、メタ・モデル１５−１の汎化モデルとして、それゆえに、また、モデル１１−１の汎化モデルとして認識されることができる。メタ・モデル１５−１およびモデル１１−１における全てのオブジェクトは、ルート・メタ・モデル１５−３におけるオブジェクトのインスタンスまたは特化である。ルート・メタ・プロセッサ１５−４は、ルート・メタ・モデル１５−３に従って、かつガイドの下で、プロセッサ１１−２と、メタ・プロセッサ１１−２に含まれるならばプロセッサ１５−２と、にアクションを生成する。
プロセッサ１１−２は、サブジェクトシステム１０−２において、モデル１１−１によって与えられたアクションを開始するためにイベントに応答する。同様に、メタ・プロセッサ１５−２は、モデル１１−１において、メタ・モデル１５−１によって与えられたアクションを開始するためにイベントに応答する。ルート・メタ・プロセッサ１５−４は、プロセッサ１１−２において、ルート・メタ・モデル１５−３によって与えられたアクションを開始するためにイベントに応答する。それゆえ、ルート・メタ・プロセッサ１５−４は、汎化ルート・メタ・モデル１５−３が表すクラスからいずれかのモデル（またはメタ・モデル）によって順にガイドされることができるいずれのプロセッサ（またはメタ・プロセッサ）の関数も引き受けることができる。したがって、プロセッサ１１−２もメタ・プロセッサ１５−２も、それらの関数がルート・メタ・プロセッサ１５−４によって実行されると考えることができるので、独立のプロセッサとして物理的に存在する必要はない。プロセッサ１１−２およびプロセッサ１５−２は、それゆえに、仮想的である。
ルート・メタ・モデル１５−３は、特定のクラスの全てのメタ・モデル１５−１の汎化版である。例えば、それは、図１６を参照して下に記述されたイベント駆動型モデルの汎化版であることができる。このように、ルート・メタ・モデル１５−３は、いずれのメタ・モデル１５−１、それゆえ、いずれのモデル１１−１においても具体化されることができる有効な構造および動作を定義する。プロセッサ１１−２に代わってルート・メタ・プロセッサ１５−４においてアクションを開始するイベントは、サブジェクトシステム１０−２または環境１０−３に生成される。メタ・プロセッサ１５−２に代わってルート・メタ・プロセッサ１５−４においてアクションを開始するイベントは、モデル１１−１（それはメタ・モデル１５−１のサブジェクトシステムである）、または環境１０−３に生成される。
イベントは、いずれのアクションも生じさせなくてもよく、また、１つまたは２つ以上のアクションを生じさせてもよい。また、開始されたアクションのそれぞれは、概して１つ以上のオブジェクトの状態変化を生じさせるが、１つ以上のさらなるイベントを次々に生じさせてもよい。これらのイベントのそれぞれは、それから、プロセッサ１１−２、メタ・プロセッサ１５−２、およびルート・メタ・プロセッサ１５−４の適切な１つによって処理され、処理は更なるイベントが生成されなくなるまで継続する。
ルート・メタ・モデル１５−３がメタ・モデル１５−１およびモデル１１−１の外側に位置する場合、ルート・メタ・モデルそれ自体は、ルート・メタ・プロセッサ１５−４の実際の「配線」構造および動作に適応させることができない。しかし、ルート・メタ・モデル１５−３が、示されるように、モデル１１−１内のメタ・モデル１５−１の部分として定義される場合、ルート・メタ・プロセッサ１５−４は、メタ・プロセッサ１５−２（その関数は、メタ・プロセッサ１５−２が引き受ける）を通じてルート・メタ・モデル１５−３を適応させることができ、それによってその構造および動作は自由に適応できる。
ルート・メタ・アクタを形成するためのルート・メタ・モデル１５−３およびルート・メタ・プロセッサ１５−４の組み合わせの概念は、図１１〜１３に示されるアクタのモデル１１−１およびプロセッサ１１−２の組み合わせに類似するパターンを追うことで知ることができる。
ルート・メタ・アクタ１５−３、１５−４のサブジェクトシステムは、一般モデル実行システムである。
ここで、ルート・メタ実行サイクルを示す図１６を参照する。１つのレベル上で、サイクルは、イベント１２−２によって駆動（１６−１）されるアクション１２−４を含む。アクション１２−４は、オブジェクト１２−３における変化をもたらす（１６−２）ことができ、続いてイベント１２−２をもたらす（１６−３）ことができる。サイクルのこのレベルは、上述したように、図１３に示されている。
図１６のルート・メタ実行サイクルは、以下の通りである。イベント１２−２がトリガされたときに、ルート・メタ・プロセッサ１５−４は、どのアクション定義１６−７がイベント１２−２に関連し、それゆえ、どのアクションがイベント１２−２によって開始される（１６−１）べきかを、決定する（１６−６）ために、そのイベントの定義１６−５を検査する（１６−４）。これらのアクション１２−４は、それから開始される（１６−８）。アクション１２−４が開始されるときに、ルート・メタ・プロセッサ１５−４は、どのオブジェクト定義１６−１０が影響を受けるかを決定する（１６−１５）ために、アクションの定義１６−７を使用し（１６−９）、それから、所定の関連オブジェクト１２−３における変化（１６−２）を開始する（１６−１１）。オブジェクト１２−３が変化させられたときに、ルート・メタ・プロセッサ１５−４は、オブジェクト１２−３における変化がいずれかのさらなるイベント定義１６−５をトリガ（１６−１３）すべきかどうかを見出すために、オブジェクトの定義１６−１０を検査する（１６−１２）。肯定の決定がなされた（１６−１４）場合、さらなるイベント１２−２がトリガされ（１６−３）、それにより、新しくトリガされたイベントのための更なるルート・メタ実行サイクルを開始する。前述において、オブジェクト１２−３の変化は、オブジェクト１２−３の状態における変化によって構成され、どのイベントがオブジェクトの状態の変化によってトリガされるべきかの決定は、オブジェクトの状態の変化の定義１６−１０を検査することを含む。アクションは、更に、または代わりに、状態における変化の特化タイプであるオブジェクト１２−３の生成または削除をもたらしてもよい。オブジェクト１２−３が生成または削除されるべきか否かは、アクション定義１６−７によって決定される。
図１６は、「粒度の細かい」イベント駆動型実行サイクルを、上記先行技術に開示されたＯＯ ＧＵＩおよびＤＢＭＳトリガの「粒度の粗い」イベント駆動型処理と対比して表す。従来のソフトウェアにおける命令と等価である基本アクション（以下に図１７を参照して記述する）まで下がれば、全ての単一のアクションは、他のアクションを表すオブジェクトを含むオブジェクトの状態における変化として認識されたイベントに応じて開始される。これは、本発明のこの態様を、並列コンピューティング・アーキテクチャ、特に、図２９および３０を参照して以下に記述されるものに対して相当により受け入れやすくする。
この実行サイクルに基づくプロセッサまたはシステムを構築するときに、実際の実装における検討事項を取り扱う更なるルールが必要となるかもしれない。例えば、図１４を再び参照すると、アクション１４−９を開始するＡＮＹイベントのような、あるイベントは、それら自身が他のアクションの完了に、この場合はアクション１４−７または１４−１０の完了に関連している。しかし、アクション１４−７および１４−１０の両者は、現在時刻オブジェクト１４−８を修正することによって１４−２０でのオブジェクト変化イベントをトリガする。それゆえ、システムは、イベント１４−２０によって開始された合成アクション１４−１１も完了するまでは、アクション１４−７または１４−１０のいずれをも完了したとみなすことができない。これは、実行システムまたはプロセッサに、その結果の全ても完了であるときにだけ、アクションを完了とみなすというルールを含むことを必要とする。
図１７Ａおよび１７Ｂは、ルート・メタ・モデル１５−３の構造的コンポーネントを示す。これは、モデルまたはメタ・モデルを記述するために要求される主要なオブジェクトタイプと、それらの間の主要な関係の単純化モデル（すなわち、これは図１８に示される、いくつかの動作の詳細を無視する）である。それは、２つの次元の重なりからなる４つの象限に分解することによって、もっとも容易に理解される。１つの次元において、オブジェクトタイプは、アーキタイプまたはインスタンスのタイプであり、第２の次元において、それはモデルの構造または動作のコンポーネントであることができる。これは、４つの象限、すなわち図１７Ａに示される構造的アーキタイプおよび動作的アーキタイプと、図１７Ｂに示される構造的インスタンスおよび動作的インスタンスとを与える。図２２Ａおよび２２Ｂは、図１７Ａおよび１７Ｂへのキーを提供する。
はじめに、このモデル上の全てのボックスがオブジェクトタイプを表すことに注意すべきである。各オブジェクトタイプは、同じ特性または属性、および動作を備えるオブジェクトのグループを表す。このモデルにおける全てのオブジェクトタイプは、モデル内における「オブジェクト」のインスタンスでもある。すなわち、全てのオブジェクトタイプは、「オブジェクト」オブジェクトタイプのサブ・タイプである。それゆえ、オブジェクトタイプ「オブジェクト」は、４つの象限全てをカバーする。全てのオブジェクトは、少なくとも１つの有限コレクションのメンバである。
当然のことながら、特別な注意が必要な、このモデルのいくつかの態様がある。１つは、オブジェクト・コレクションのサブ・コレクションであるオブジェクトタイプ・コレクションであり、次に、オブジェクトタイプ・コレクションのインスタンスである。これは、ルート・メタ・モデル１５−３を含むいずれのメタ・モデル１５−１またはモデル１１−１も、メタ・プロセッサ１５−４の制御の下で、メタ・モデルまたはモデルの特定のオブジェクトタイプが付加される前に、ルート・メタ・モデルからコアオブジェクトタイプおよびオブジェクトがまず準備されなければならないということを意味する。
構造的インスタンスは、図１７Ｂに示されている。全ての構造的インスタンスは、単純または複雑のいずれかである。そのようなモデルにおける単純オブジェクトは、唯一のエレメントを持ち、値オブジェクト１７−１または参照オブジェクト１７−２のいずれかである。値オブジェクト１７−１は、整数または日付のようなオブジェクトであり、任意の時点において、その内容は、典型的には無限であるが、明確な集合の単純で単一の存在である。一方、参照オブジェクト１７−２は、ある他のオブジェクトを指す。複雑なオブジェクトは、１つの以上のエレメント１７−４を持ち、合成オブジェクト１７−３またはコレクション１７−６のいずれかである。合成オブジェクト１７−３は、典型的には異なるタイプの、１つ以上の他のオブジェクトから構成される。合成オブジェクトは、従来の高級プログラミング言語と（おそらく可変の）レコード構造が類似すると考えることができる。システム１７−５は、少なくとも２つの他のオブジェクトを含み、少なくともその１つは参照オブジェクト１７−２であるかまたはそれを含む、特別な種類の合成オブジェクト１７−３である。同様に、アクタは、本明細書に定義されるように、別のシステム、すなわちサブジェクトシステムにおいてアクションを生成することができるシステムの特化タイプである。コレクション１７−６は、その名称が暗示するように、類似するタイプのオブジェクトのグループである。コレクションは、無限コレクション１７−７、有限コレクション１７−８または派生コレクション１７−９であってもよい。派生コレクション１７−９は、他のコレクションへの参照で定義される。無限コレクション１７−７は、整数の集合ように、典型的に値の無限グループを表す。しかし、モデル内の大部分のコレクション１７−６は、通常、有限コレクション１７−８であり、それは、直接的に（すなわち、明示的に列挙された）、またはそのメンバを導き出せるある公式を通じてのいずれかにより、典型的にはモデル内の他のオブジェクトへの参照で定義される。有限コレクション１７−８の全てのメンバ１７−１０は、有限コレクション（下記参照）に関連したオブジェクトタイプ１７−１４によって定義される構造および動作を持つ。サブ集合のような派生コレクション１７−９は、基礎値集合として予め定義されなければならないものでもなく、完全に列挙されるものでもないが、後述する適用アクションタイプ１７−２４内に含まれる公式を通じて定義されるメンバシップを持つ。
構造的アーキタイプは、図１７Ａに示されている。それらは、各コレクションの全てのメンバに共通する構造（および、後述のように、動作的アークタイプに関連する動作）を定義する。このゆえに、値オブジェクトタイプ１７−１１は、このタイプの全ての値オブジェクト１７−５の値が取らなければならないコレクション１７−６（典型的には整数ような無限集合）を識別する。また、値オブジェクトタイプ１７−１１は、値オブジェクト１７−１の特定の値がそれを通じて導き出されるアクションタイプ１７−１６への参照（後述する）を含んでもよい。また、参照オブジェクトタイプ１７−１２は、このタイプのコレクション１７−６のどのメンバが参照を許可されるのかを示すコレクション１７−６への参照を含む。合成オブジェクトタイプ１７−１３は、このタイプの合成オブジェクト１７−３のコンポーネントを提供するオブジェクトタイプ１７−１４を識別する。コレクションのコレクションのアーキタイプメンバを定義するコレクションタイプ１７−１５は、このタイプのコレクションメンバ１７−１０を引き出さなければならないオブジェクトタイプ１７−１４を識別する。
動作的アーキタイプもまた、図１７Ａに示される。それらは、イベントタイプ１７−３２およびアクションタイプ１７−１６をオブジェクトに関連付けることによってアクションが生成される機構を導入する。オブジェクトタイプ１７−１４もまたオブジェクトであるので、そのような関連付けは、特定のオブジェクトと同様に、オブジェクトタイプ１７−１４についても可能であって、オブジェクトタイプ１７−１４がアーキタイプであるコレクション１７−６全体に関連する動作を許可する。イベントタイプ１７−３２は、基本イベントタイプ１７−１７または合成イベントタイプ１７−１８のいずれかである。基本イベントタイプ１７−１７は、別の状態からの、またはオブジェクトの生成という、ある状態へのオブジェクトの状態の変化を定義する。各状態は、状態オブジェクト１７−１９への参照で定義される。状態オブジェクト１７−１９は、値オブジェクト１７−２０の特化形式である。合成イベントタイプ１７−１８は、新しいイベントタイプを定義するために、他のイベントタイプ１７−３２（基本または合成のいずれか）を結合する。これらのイベントタイプ１７−３２が結合される方法は、典型的には和（ＯＲ）または積（ＡＮＤ）アクションタイプであるアクションタイプ１７−１６を経由して定義される。アクションタイプ１７−１６は、同様に、基本または合成アクションタイプ１７−２１である。基本アクションタイプやアクションタイプの他の形式に適用する関係がないので、基本アクションタイプは、図に示されない。アクションタイプ１７−１６は、このアクションタイプのアクションの実行ために利用できなければならない決定要因１７−２２を持つ。アクションタイプ１７−１６は、また、このアクションタイプのアクションの出力結果を受け入れる結果１７−２３を持つ。アクションタイプ１７−１６の決定要因１７−２２および結果１７−２３は、オブジェクトまたはオブジェクトタイプ１７−１４のいずれかであってもよい。適用アクションタイプ１７−２４は、特定のイベントタイプ１７−３２に関連する、アクションタイプ１７−１６の特定のインスタンスである。アクションタイプ１７−１６および適用アクションタイプ１７−２４間の相違を図示するために、我々は、アクション「加算」（すなわち、２進加算である数学の演算子「＋」）を考えることができる。アクションタイプ「加算」は、２つの決定要因および１つの結果を持ち、それらはそれぞれ数である。適用アクションタイプは、図１４に見られる。ここで、全てのアクション１４−９に従うと、適用アクションタイプ「加算」は、１を「現在時刻」（決定要因）に加え、結果を「現在時刻」（結果）に割り当てるアクション１４−１０で開始される。動作的インスタンスは、また、図１７Ｂによって示されている。それらは、図１６を参照して上述されたように、モデル１１−１の実行を駆動するために、ルート・メタ・プロセッサ１５−４によって直接的に採用されている。オブジェクトタイプ１７−１４の主要な動作的インスタンスは、基本イベント１７−２６または合成イベント１７−２７であってよいイベント１７−２５、および合成アクション１７−２９であってよいアクション１７−２８である。アクション１７−２８および合成アクション１７−２９は、決定要因１７−３０および結果１７−３１を持つ。イベント１７−２５は、イベントタイプ１７−３２のオカレンスである。アクション１７−２８は、適用アクションタイプ１７−２４のオカレンスである。
このルート・メタ・モデル１５−３と、他のモデル化アプローチ、特にオブジェクト指向型モデリングに関連するメタ・モデルとの間の主な相違は、以下の通りである。ルート・メタ・モデル１５−３において、メタ・オブジェクト（すなわち、オブジェクトタイプ１７−１４）は、モデルそれ自体のエレメントであり、それゆえ関連するメタ・プロセッサ１５−２によって拡張または修正されやすい。また、ルート・メタ・モデル１５−３において、動作を捉えるための機構は、究極的には逐次的なメソッドまたはオペレーションには含まれていないが、代わりにイベントタイプ１７−３２およびアクションタイプ１７−１６に含まれる。これは、モデルの動的な並列実行を直接的に可能にする。
図１８は、ルート・メタ・モデル１５−３のようなルート・メタ・モデルの動作的コンポーネントを示す。モデル（図１８Ａおよび１８Ｂ）の左手側は、部分的ではあるが、図１７に示される構造的モデルのより詳細なバージョンである。それは、先のモデルにおけるタイプとして表されるコレクション（図の破線の左側）を、各集合（図の破線の右側）のアーキタイプメンバと同様に、明示的に含む。それは、また、メンバシップ、サブ・コレクションおよび合成関係を示す特殊なタイプの参照矢印を含む。図２２Ａおよび２２Ｂは、図１８へのキーも提供する。モデルの主要な動作的エレメントは、オブジェクト１８−１、イベント１８−２およびアクション１８−３のイベントにそれぞれ関連付けられた３つのグループで、モデル（図１８Ｃおよび１８Ｄ）の右手側に示される。
オブジェクト・イベントグループ１８−１は、オブジェクトに関連するようにしてもよい３つの異なるイベントタイプを示す。それらは、オブジェクトがアクションによって始めて生成（すなわち、「存在しない」から「存在する」への状態の変化）されたときに起こるイベントのタイプである生成イベントタイプ１８−４と、オブジェクトがアクションによって変更された（しかし、生成または削除されたのではない）ときに起こるイベントのタイプである修正イベントタイプ１８−５と、アクションがオブジェクトを削除するときに起こるイベントのタイプである削除イベントタイプ１８−６である。これらの変化がルート・メタ・プロセッサ１５−４によって検出されたときに、このモデルは、変化したオブジェクトに関連する生成イベント１８−７、修正イベント１８−８または削除イベント１８−９をそれぞれ生成することによって応答すべきことを示す。図１６を参照して上述したように、これは、実行サイクルを開始するのに十分である。（これらの動作的エレメントは、オブジェクト・イベントグループ内で引き受けられなければならず、かつ先行技術で良くカバーされている、メモリまたはオブジェクト記憶に対するオブジェクトの単純ライトおよびリードに付加する。）
イベント・イベントグループ１８−２は、イベントに関連する動作的ルールを示す。イベントの生成だけに、関心がある。イベントの生成は、２つの並列アクション１８−９、１８−１０を開始する。第１は、このイベントに関連するイベントタイプがコンポーネントである合成イベントタイプのオカレンスそれぞれのための親イベントを生成する合成アクション１８−９である。この親イベントは、合成イベントタイプに関連する合成アクションの「実行」が、他の必要なイベントの全てもまた起こる（すなわち、「真」状態で完了する）ことを示す場合に限り、生成される。第２のアクション１８−１０は、このイベントに関連するイベントタイプによって開始される各アクションタイプについてアクションのオカレンスを生成する。生成アクション合成アクション１８−１０の部分を形成する生成アクション１８−１１は、生成されたアクション・コンポーネント、すなわち、開始するイベントの参照、それがアプリケーションであるアクションタイプ、およびその決定要因および結果のコレクションにおけるオブジェクトの生成を処理する。アクション１８−９、１８−１０の両者は、多重イベント１７−２５またはアクションをそれぞれ生成することができる。多重イベント１７−２５またはアクション１７−２８が生成されるか否かは、生成されたイベントタイプ１７−３２に関連する合成イベントタイプ１７−１８およびアクションタイプ１７−１６の数に依存する。
アクション・イベントグループ１８−３は、アクション１７−２８に関連する動作のルールを示す。それは、一番関心のあるアクションの生成であり、アクションの生成は２つの並列アクティビティを開始することができる。アクションが開始されるときはいつでも起こる１つのアクティビティは、「開始された」イベント１８−１２を生成することである。このことにより、ルート・メタ・プロセッサ１５−４は、アクションの実行を追跡することができ、更に重要なことには、合成アクションのコンポーネントであり、その開始に依存するアクションを開始することができる。実行アクション・アクティビティ１８−１３は、開始されたアクションが基本アクションであるときだけに開始される。基本アクションだけが、実際にオブジェクに変化を起こす。このアクション１８−１３は、プロセッサに、関連するアクションタイプによって参照されたアクションタイプ、決定要因および結果を使用して、生成された基本アクションを実行させる。上述のように、ルート・メタ・プロセッサ１５−４が変化を検出し、修正イベントを生成するので、そのような基本アクションの出力結果を、結果に割り当てることによって生じるどのような変化も、別の実行サイクルを開始する。実行アクション１８−１３が完了した時点で、ルート・メタ・プロセッサ１５−４は、アクション完了イベントを生成し、続いて他のアクションを開始してもよい完了イベント生成アクション１８−１４を開始する。これらの他のアクションは、典型的には、同じ合成アクションのコンポーネントである。
図１９Ａおよび１９Ｂは、製品組み立てモデルに適用される、上述のオペレーションのシステムを示す。図２２Ａおよび２２Ｂは、図１９Ａおよび１９Ｂへのキーも提供する。モデルの実行の前に、顧客、製品仕様および部品仕様にそれぞれ関連して、「顧客」１９−１、「製品仕様」１９−２および「部品仕様」１９−３とラベル付けされたオブジェクトが生成される。モデルの実行は、特定の顧客１９−６のために特定の製品仕様１９−５を注文する「注文」オブジェクト１９−４の生成によって開始される。注文オブジェクト１９−４の生成は、「製品製造」アクション１９−７を開始するイベントである。実際には、顧客、製品仕様および部品仕様と呼ばれるオブジェクトは複数あるが、図にはこれらのそれぞれ１つだけが示されている。製品製造アクション１９−７の開始は、「部品調達」アクション１９−８を開始する。部品調達アクション１９−８によって調達されるべき部品１９−９は、製品仕様オブジェクト１９−５に関連する部品仕様リストオブジェクト１９−１０において定義されるものである。部品調達アクション１９−８それ自体の開始は、製品仕様オブジェクト１９−５に関連する部品仕様リスト１９−２０の各部品のための部品調達アクションの１つのオカレンス１９−１１を開始する。各部品調達アクション１９−１１（そのうちの１つのみを示す）は、要求された部品が組立部品であるか否かのチェック（１９−１２）を開始することによって開始する。真の場合、ちょうど製品製造アクション１９−７が完成製品のための部品調達アクション１９−８を開始するように、要求された部品の組み立てのために更なる部品調達アクション１９−１３を開始することとなる真状態１９−２１でアクション１９−１２は完了する。全ての部品が利用できるようになった時点で、部品調達アクション１９−１３の完了により、部品組立アクション１９−１４に、オブジェクトの生成またはオブジェクトの状態の変化のいずれかを構成する部品それ自体を組み立てさせる（１９−２２）。もし、部品が組立部品でないと決定されると、アクション１９−１２は、偽状態１９−２３で完了し、それが製造部品であるか否かを決定するためにアクション１９−１５を開始する。真の場合、イベント１９−２４は、部品を製造する部品製造アクション１９−１６を開始する。偽の場合、部品を購入する部品購入アクション１９−１７は、イベント１９−２５によって開始される。
部品仕様リストオブジェクト１９−２０に関する全ての部品が調達された時点で、部品調達アクション１９−１１は完了する。最後の部品調達アクション１９−１８（すなわち、製品製造アクション内で開始されたアクション）が完了すると、製品（図示せず）の組み立てを開始するイベントが生じる。組み立てが完了した時点で、モデルの実行は完了する。
複雑なアクティビティシステムは、図２０に示されている。ここで、サブジェクトシステム１０−２は、図１０に示されているのと同じように、環境１０−３内に含まれる。この場合、アクタ１０−１は、第１および第２のサブ・アクタ２０−１、２０−２を含む。サブ・アクタ２０−１、２０−２は相互接続され、それぞれはサブジェクトシステム１０−２におけるアクションを生成（２０−３、２０−４）する。サブ・アクタ２０−１、２０−２は、サブジェクトシステム１０−２においてアクションを生成（２０−３、２０−４）するために互いに協働すると考えることができる。
部分的に合成された図１５に示されるルート・メタ・プロセッサ１５−４は、図２１に示されている。ここで、ルート・メタ・プロセッサ１５−４は、協働するサブ・アクタ２１−１、２１−２、２１−３のシステムを形成する。アクティベータ・アクタ２１−１はイベントに関係し、エグゼキュータ・アクタ２１−２はアクションに関係し、レコーダ・アクタ２１−３はオブジェクトに関係している。アクタ２１−１、２１−２、２１−３のそれぞれは、図１６を参照して示され記述されたサイクルが実行されることを可能にするために、他のアクタのそれぞれに接続される。（完全に合成されたルート・メタ・プロセッサは、図２３を参照して後述する更なるコンポーネントを必要とすることに注意されたい。それゆえ、完全に合成されたルート・メタ・プロセッサは、図２４を参照して後述する。）
サブ・アクタ２１−１、２１−２、２１−３間のタスクの割り当ては、次の通りである。アクティベータ２１−１は、イベントに応答するように、そして、イベントやモデル１１−１、１５−１、１５−３から、どのアクションを開始するかを決定するように調整される。エグゼキュータ・アクタ２１−２は、開始されることを要求されたものとしてアクティベータ２１−１によって決定されたアクションを生成するために調整される。エグゼキュータ２１−２は、モデル１１−１、１５−１、１５−３に従って、オブジェクトに、決定されたアクションを生成する。レコーダ２１−３は、モデルの部分を形成するオブジェクトを管理し、レコーダ２１−３によって管理されるオブジェクトの状態の変化あるいはオブジェクトの生成または削除によってトリガされたイベントを認識し、続いてアクティベータ２１−１によって更なるアクティビティを開始する。
図１８は、図１８を参照して上述した動作ルールについて、図２１に示すレコーダ２１−３、アクティベータ２１−１およびエグゼキュータ２１−２アクタの主要な責務を示す。レコーダ２１−３は、オブジェクト・イベントグループ１８−１のための、すなわち、オブジェクト生成１８−７、修正１８−８および削除１８−９イベントを検出および生成するための責務を持つ。アクティベータ２１−１は、イベント・イベントグループ１８−２のための、すなわち、イベント生成イベント１８−７を検出し、関連する親（合成）イベントおよびアクション１８−９、１８−１０を生成するための責務を持つ。エグゼキュータ２１−２は、アクション・イベントグループ１８−３のための、すなわち、アクション生成イベント１８−１０を検出し、関連するアクション開始およびアクション完了イベント１８−１２、１８−１４を生成するとともにそのようなアクションを実行するための責務を持つ。
図２０においてアクタ１０−１を形成するためにサブ・アクタ２０−１、２０−２が協働するように、２つのアクタが合成アクタを形成するために協働するときには、通信機構を提供することが必要である。サブ・アクタ２０−１、２０−２の性質に応じて、通信は、連続的または離散的形式をとることができる。第１および第２のサブ・アクタ２０−１、２０−２の接続は、図２３に示されている。ここで、第１のサブ・アクタ２０−１は、第２のサブ・アクタ２０−２にも接続されたチャネル２３−１への接続を含む。このように、サブ・アクタ２０−１、２０−２は、チャネル２３−１によって互いに接続されている。第１のサブ・アクタ２０−１のチャネル２３−１への接続を可能にするために、第１のインタフェース・コンポーネント２３−２は、第１のサブ・アクタ２０−１に含まれ、第１のインタフェース・コンポーネント２３−２は、チャネル２３−２の部分を形成する第２のインタフェース・コンポーネント２３−３に接続されている。同様に、チャネル２３−１の部分を形成する第３のインタフェース・コンポーネント２３−４は、第２のサブ・アクタ２０−２の部分を形成する第４のインタフェース・コンポーネント２３−５に接続される。インタフェース・コンポーネント２３−２、２３−３、２３−４および２３−５のそれぞれは、好ましくは図１５のアクタ１０−１として構成されるアクタを構成する。アクタ２３−２、２３−３、２３−４および２３−５のそれぞれは、そのサブジェクトシステム１０−２として、コンポーネント間の通信を構成する項目を持つ。もし、通信が連続的であれば、通信項目は、例えばパイプを流れる流体または粉体等の物質流の形式を、あるいは例えば電磁波形または電子波形等の信号の形式をとることもできる。離散的通信項目は、例えば製造コンポーネントの発送等のパッケージを構成してもよいし、あるいは例えば注文のような情報パッケージ等のメッセージを構成してもよい。それゆえ、アクタのそれぞれは、通信に使用される項目のモデルを含み、この項目にアクションを生成する。
合成ルート・メタ・プロセッサのための完全な一般モデルは、図２４に示されている。ここで、アクティベータ２１−１、エグゼキュータ２１−２およびレコーダ２１−３は、チャネル２３−１によって互いに接続されたように示されている。チャネル２３−１は、また、例えばチャネル２４−３によってルート・メタ・プロセッサ１５−４を外部システムに接続できるようにするインタフェース２４−２に接続されている。
チャネル２３−１は、示されるように、アクティベータ２１−１、エグゼキュータ２１−２、レコーダ２１−３、およびインタフェース２４−２を互いに直接に接続してもよい。代わりに、レコーダ２１−３がアクティベータ２１−１に接続され、アクティベータ２１−１がエグゼキュータ２１−２に接続され、エグゼキュータ２１−２がレコーダ２１−３に接続されるリング状のチャネルシステムがあってもよい。チャネルシステムは、選択的に、これら両極端な２つのどちらの形式をとってもよい。
サブ・アクタ２１−１、２１−２、２１−３、２３−１または２４−２のそれぞれは、それ自体、アクティベータ、エグゼキュータ、レコーダ、チャネルおよびインタフェースが協働するシステムによって構成されてもよい。これは、図２５に示されている。この図を参照すると、アクティベータ２１−１は、エグゼキュータ２５−１、レコーダ２５−２およびアクティベータ２５−３を含み、全てがチャネル２５−４によって互いに接続されるように示されている。アクティベータ・インターフェース２５−５は、アクティベータ２１−１をチャネル２３−１に接続する。チャネル２３−１それ自体は、レコーダ２５−６、エグゼキュータ２５−７、アクティベータ２５−８およびチャネル２５−９によって構成されるルート・メタ・プロセッサを備える。チャネル２３−１の部分を形成するチャネル２５−９は、図において単に「Ｉ」として示された、更なる個別のインタフェースによって、エグゼキュータ２１−２、レコーダ２１−３、アクティベータ２１−１およびインタフェース２４−２のそれぞれに接続されている。エグゼキュータ２１−２、レコーダ２１−３、インタフェース２４−２および外部チャネル２４−３もまた、関連したコンポーネントを含むルート・メタ・プロセッサによって構成されている。
リング状のチャネルシステム、またはハイブリッド・チャネルシステムは、図２４を参照して上述したように使用されてもよい。
図２５には、ルート・メタ・プロセッサ１５−４のコンポーネントのそれぞれが、ルート・メタ・プロセッサとして示されているが、コンポーネントのそれぞれは、そのように構成される必要はない。いくつかの環境においては、ルート・メタ・プロセッサとして、１つのみ、２つまたは３つのコンポーネントを実装することが要求されるかもしれない。
アクティベータ２１−１のサブジェクトシステムは、サブジェクトシステムにおいてアクションを開始するイベントのシステムである。エグゼキュータ２１−２のサブジェクトシステムは、サブジェクトシステム内でオブジェクトを変化させるアクションのシステムである。レコーダ２１−３のサブジェクトシステムは、オブジェクトと、それらに関連するデータおよび状態と、それらオブジェクトの状態が変化するときにトリガされるイベントのシステムである。チャネル２３−１、２４−３のサブジェクトシステムは、２つ以上のアクタ間の通信のシステムである。インタフェース２４−２のサブジェクトシステムは、アクタと、チャネルまたは外部世界との間の通信のシステムである。
階層化ルート・メタ・アクタのモデルは、図２６に示される。ここで、物理アクタ２６−１は、ルート・メタ・プロセッサ１５−４およびモデル１１−１を備えるように示されている。モデル１１−１は、メタ・モデル１５−１およびルート・メタ・モデル１５−３を含む。ルート・メタ・プロセッサ１５−４は、図２４のルート・メタ・プロセッサのように構成される。すなわち、アクティベータ２１−１、エグゼキュータ２１−２、レコーダ２１−３、チャネル２３−１およびインタフェース２４−２を含む。
モデル１１−１は、仮想ルート・メタ・プロセッサ２６−３、２６−４および２６−５の仮想アクティベータ、エグゼキュータ、レコーダ、チャネルおよびインタフェース、特に、それらの仮想アクティベータ、エグゼキュータ、レコーダ、チャネルおよびインタフェースの動作を、物理ルート・メタ・プロセッサ１５−４によって直接的に実行可能であるように、それぞれ精緻化するサブ・モデル２６−２０、２６−２１、２６−２２を含む。ルート・メタ・プロセッサ１５−４およびそのコンポーネントの動作が関連するルート・メタ・モデル１５−３によって定義されるので、これは、各モデルが効果的に、関連した仮想アクタのルート・メタ・モデルの基本オブジェクト、イベントおよびアクションを、基礎となる物理アクタのルート・メタ・モデルの基本オブジェク、イベントおよびアクションにすることを意味する。この精緻化がどのように成し遂げられるかは、図２７Ａおよび２７Ｂを参照して後述する。
いずれのルート・メタ・アクタのモデルも、それゆえメタ・モデルおよびルート・メタ・モデルも、実際に、ルート・メタ・アクタのルート・メタ・プロセッサのレコーダ内に記憶されることに注意されたい。
この精緻化は、１つ以上の更なるレイヤに拡張されてもよい。例えば、図２６において、第２の仮想アクタ２６−７は、モデル２６−１０内に、第２の仮想アクタ２６−７の仮想ルート・メタ・プロセッサ２６−４によってそれを実行可能にするように、次に第４の仮想アクタ２６−１２のルート・メタ・モデルを精緻化するサブ・モデル２６−２３を含む。
物理アクタ２６−１は、唯一のハードウェアエレメントである。他の全てのエレメントは仮想である。ルート・メタ・プロセッサ２６−３、２６−４および２６−５は、仮想モデル実行エンジンとみなせる。
単一のアクタは、仮想アクタのそれぞれが個別の役割を持つ多重仮想アクタを、単一のアクタの精緻化モデルが仮想アクタの役割それぞれを認識するという条件の下で、サポートすることができる。アクタが多重の役割を持つときには、その精緻化モデルは、役割間の競合を処理するための付加ルールを必要とする。そのようなルールは、各役割の相対的優先権の定義であるかもしれない。
多重の役割を持つアクタを、生産制御コンピュータシステムが製造に使用される状況に適用すると、アクタは、生産をモニタリングする役割と、例えば予定からの遅れ等のどのような生産問題が起こったとしても生産管理のために警告を発する役割とを持つことができる。アクタは、また、既存のプロセスのパフォーマンスを提案されたプロセスのそれと比較することを可能にするために、生産プロセスに対する変更案のシミュレーションを実行する役割を持つことができる。明らかに、生産運転を持続することは、シミュレーションを素早く完了することよりも、重要かつ緊急である。
ここで、コンピュータシステム（図示せず）は、２つの割り当てられた役割、すなわち生産モニタおよびシミュレータを持つ単一の合成アクタである。コンピュータシステムのハードウェアには、両役割に気付くことが必要であり、役割間の潜在的な衝突を処理するためのルールを含む必要がある精緻化モデルが提供される。シミュレータおよび生産モニタの両方が同時に何かをしたい場合、アクタの生産モニタの役割は、より高い優先度を持ち、それゆえシミュレーションの役割に対して先行する。それゆえ、多重アクタ精緻化モデルは、各役割のためのものである２つの個別のモデルを、単一の共通モデル内に含む必要がある。単一のモデルは、また、内部役割の相互作用を処理するルールも持つ。
このコンピュータシステムの役割は、従来のコンピュータ・オペレーティング・システムによって果たされたそれと全く類似する。しかし、それぞれのモデルはイベント駆動型であり、それゆえに逐次よりはむしろ並列であるので、多重アクタで階層化された仮想メタ・アクタのこの要求への応答は改良される。これは、役割の並列実装を可能にする。結果として、多重アクタ精緻化モデルは、役割（それは従来のオペレーティング・システムにおけるプロセッサであることができる）間の切り替えに多くのオーバーヘッドを必要としない。なぜならば、基礎となる物理プロセッサは、いずれの役割からのイベントも、いつでもトリガされることができる単一のモデル（ルール集合）を持つからである。
このアプローチは、それが物理アクタ上に精緻化される仮想アクタのモデルではなく、代わりに仮想ルート・メタ・モデルである点において、類似する既存の階層化アプローチ（例えば、現代の階層化オペレーティング・システムの設計において）とは異なる。これは、精緻化モデルの再利用性を著しく増加させる物理アクタそれ自体の修正を必要とすることなしに、物理アクタ上の仮想ルート・メタ・プロセッサによって実行されることができる仮想アクタのいずれのモデルをも実行する能力を提供する。
エラボレータ１１−１のサブジェクトシステムは、他のプロセッサ、メタ・プロセッサまたはルート・メタ・プロセッサ１５−４によって直接実行が可能なアクタ２６−６、２６−７、２６−８のプロセッサ、メタ・プロセッサまたはルート・メタ・プロセッサを備えるプロセッサデバイス２６−３、２６−４、２６−５、２６−１３の動作の精緻化のシステムである。
精緻化モデル２７−０を、図２７Ａおよび２７Ｂを参照して、説明する。ここで、アプリケーションモデル２７−１の部分は、２つの数ｍおよびｎを乗算して出力数ｒを生成する乗算プロセスを開始するイベント２７−２を含む。エラボレータ・マッピングテーブル２７−１１から、乗算プロセスが開始する前に、数ｍおよびｎが８ビットアドレス２オブジェクト２７−９および８ビットアドレス４オブジェクト２７−８にそれぞれ置かれていることが分かる。この精緻化モデルは、イベントｅ２７−２がアプリケーションモデル２７−１において開始される時はいつでも開始されるイベントｅ’２７−４を持つ。イベントｅ’２７−４は、合成アクション２７−３を開始する。これは、８ビット結果オブジェクトアドレス６（２７−７）にゼロ値を割り当てるアクション２７−５を続いて開始する。ＡＤＤアクション２７−５の完了は、アクションの８つの並列シーケンスを開始し、１つのシーケンスはアドレス４オブジェクト２７−８の各ビットのためのものである。２７−１０で示される並列シーケンスのそれぞれは、アドレス４オブジェクト２７−８の対応ビットがセットされているか否かをテストする。そして、もし真であれば、ＲＯＲアクション２７−１２を使用し、対応するＲＯＲローテート入力で特定されるビット数だけ、更なるアドレス２オブジェクト２７−９の値（数ｍ）をローテートし、結果をアドレス６オブジェクト２７−７の値に加える。ＡＤＤアクション２７−１３は、先行するＲＯＲアクション２７−１２の完了によって単純に開始される。ＲＯＲアクション２７−１２は、「真」状態で完了した関連するＢＩＴアクション２７−１０によって開始される。精緻化プロセスの結果は、アドレス６オブジェクト２７−７に記憶された値であり、それは第３のアドレスオブジェクトの２進数に第２のアドレス４オブジェクト２７−８の２進数を乗じたものに等しい。十分な並列プロセッサを用いると、このモデルは、従来のフォン・ノイマン型コンピュータを利用する同等の乗算アルゴリズムに比べてごくわずかの時間で実行可能である。図２７のエラボレータは、単なる一例であり、エラボレータの正確な形式は、特に、それが実行に必要とする関数に依存する。
上述の合成ルート・メタ・アクタモデルは、単一のプロセッサ、多重プロセッサ、（潜在的に大規模な）マイクロ並列プロセッサおよび分散プロセッサのコンピュータ・アーキテクチャを生成するのに使用できる。このアプローチは、伝統的なフォン・ノイマン型コンピュータにおいて固有であるプログラムカウンタへの依存性を打破し、実装しようとするシステムの意味論を厳密に反映する粒度の細かい並列実装を可能にする。
単一のプロセッサを利用するルート・メタ・アクタ型コンピューティング・デバイスは、図２８に示されている。ここで、コンピューティング・デバイスは、チャネル２３−１によって互いに全てが接続されている、アクティベータ２１−１、エグゼキュータ２１−２、レコーダ２１−３およびインタフェース２４−２を備えている。従って、コンピューティング・デバイスは、図２４のルート・メタ・プロセッサに使用される仕組みに従って構成されている。アクティベータ２１−１は、イベント待ち行列の次のエントリの参照を含むイベント待ち行列レジスタ（ＥＱＲ）２８−１を含む。参照は、従来のコンピューティング・デバイスで使用されるようなアドレスに類似するものとして考えられてもよい。これにより、複数のイベントが同時に処理を待つことができる。アクティベータ２１−１は、また、現在処理されているイベントである現在イベントの参照を含むイベントレジスタ（ＥＲ）２８−２を含む。アクティベータ２１−１は、また、現在のイベントタイプの物理参照を含むイベントタイプレジスタ（ＥＴＲ）２８−３を含む。
エグゼキュータ２１−２は、同様に、アクション待ち行列レジスタ（ＡＱＲ）２８−４、アクションレジスタ（ＡＲ）２８−５およびアクションタイプレジスタ（ＡＴＲ）２８−６を含む。アクション待ち行列レジスタ２８−４は、アクション待ち行列の次のエントリのアドレスを含み、アクションレジスタ２８−５は、処理されている現在のアクションのアドレスを含む。アクションタイプレジスタ２８−６は、従来の命令レジスタと類似すると考えられる現在のアクションタイプのオペレーションコードを含む。エグゼキュータ２１−２は、また、第１から第ｎの汎用レジスタ（ＧＰＲ）２８−７から２８−８を含む。これらのレジスタ２８−７、２８−８は、処理で用いられるパラメータを含む。エグゼキュータ２１−２は、選択的に更に、命令デコーダ（ＩＤ）２８−９および演算・論理ユニット（ＡＬＵ）２８−１０を含む。これらは、マイクロプロセッサ・アーキテクチャにおいて従来のものである。
レコーダ２１−３は、オブジェクト待ち行列の次のエントリの参照を含むオブジェクト待ち行列レジスタ（ＯＱＲ）２１−１１を含む。また、処理されている現在のオブジェクトの参照を含むオブジェクトレジスタ（ＯＲ）２１−１２、および現在のオブジェクトのタイプを含むオブジェクトタイプレジスタ（ＯＴＲ）２１−１３が含まれている。オブジェクトのタイプは、主として、オブジェクト、アクションおよびイベントを区別するために使用される。レコーダ２１−３は、また、メモリに記録され、メモリからフェッチされるデータの記憶に使用されるメモリデータレジスタ（ＭＤＲ）２１−１４、および行われる記憶またはフェッチ命令が保持されるところの参照を含むメモリアクセスレジスタ（ＭＡＲ）２１−１５を含む。オブジェクト記憶部またはメモリ（ＯＳ）２１−１６は、レコーダ２１−３の部分を形成する。
ルート・メタ・アクタ型コンピューティング・デバイスにおいて、ＯＳ２１−１６における全てのオブジェクトへのアクセスは、レコーダ２１−３によって管理される。オブジェクトへのアクセスが要求されたときはいつも、オブジェクトの参照は、オブジェクト待ち行列に配置される。レコーダのＯＱＲ２１−１１は、処理されるべきオブジェクト待ち行列の次のアイテムを指す。オブジェクト待ち行列が空でなく、かつレコーダ２１−３が準備できているときには、それはオブジェクト待ち行列から参照を取得し、それをオブジェクトレジスタ（ＯＲ）２１−１２に配置する。それから、レコーダ２１−３は、ＯＲをＭＡＲ２１−１５に入れ、読み込みまたは書き込み命令をＯＳ２１−１６に発行する。読み込みの場合は、レコーダ２１−３は、ＭＡＲ２１−１５で特定されたＯＳの場所からオブジェクトを取得し、それをＭＤＲ２１−１４に配置する。書き込みの場合は、レコーダ２１−３は、ＭＤＲ２１−１４のオブジェクトを、ＯＳ２１−１６内のＭＡＲ２１−１５によって特定された場所に配置する。オブジェクトがＯＳ２１−１６から読み込まれると、オブジェクトとともに、ＯＴＲ２１−１３に置かれたオブジェクトのタイプに関する情報が得られる。そして、オブジェクトのタイプは、レコーダ２１−３またはアクティベータ２１−１またはエグゼキュータ２１−２によって要求されるように、さらなる処理のために利用できる。
単一プロセッサのルート・メタ・アクタ型コンピューティング・デバイスにおいて、アクティベータ２１−１のイベント待ち行列は、レコーダ２１−３内のＯＳ２１−１６に保持される。イベントがトリガされたときには、それは、トリガするアクタ（例えば、レコーダ２１−３またはインタフェース２４−２）によって、アクティベータ２１−１のイベント待ち行列に置かれる。イベントは、生成されるたびに、この待ち行列に加えられ続ける。ＥＱＲ２８−１は、処理されるべきイベント待ち行列における次のアイテムを指す。イベント待ち行列が空でなく、かつアクティベータ２１−１が準備できているときはいつも、それは、イベント待ち行列における次のアイテムを取得するためにＥＱＲ２８−１における参照を続ける。これは、ＥＲ２８−２に置かれている、レコーダ２１−３内に保持されたイベントオブジェクトへの参照を含む。ＥＲ２８−２における参照は、それから、続いてレコーダにおけるイベントオブジェクトについて保持された情報からイベントのタイプを取得し、これをＥＴＲ２８−３に戻すために使用される。それから、イベントのタイプは、図１８にて説明したように、関連するアクションタイプおよび親イベントタイプを取得するために使用される。
同様に、単一プロセッサのルート・メタ・アクタ型コンピューティング・デバイスのためのエグゼキュータのアクション待ち行列は、レコーダ２１−３内のＯＳ２１−１６に保持される。アクションが開始されると、それは、アクティベータ２１−１によってエグゼキュータのアクション待ち行列に置かれる。アクションは、それらが特定されるたびに、この待ち行列に加えられ続ける。ＡＱＲ２８−４は、処理されるべきアクション待ち行列における次のアイテムを指す。アクション待ち行列が空でなく、かつエグゼキュータ２１−２が準備できているときはいつも、それは、アクション待ち行列における次のアイテムを取得するために、ＡＱＲ２８−４における参照を続ける。これは、ＡＲ２８−５に置かれた、レコーダ内に保持されたアクションオブジェクトへの参照を含むだろう。それから、ＡＲ２８−５における参照は、続いてレコーダ２１−３におけるアクションオブジェクトについて保持された情報からアクションのタイプを取得し、これをＡＴＲ２８−６に戻すために使用される。それから、ＡＲ２８−５およびＡＴＲ２８−６の内容は、図１８にて説明したように、アクションを実行するために使用される。より詳しくは、アクションが基本アクション（すなわち、更により詳細なアクションから構成されておらず、１つのステップでエグゼキュータ２１−２によって直接的に実行されることができる）である場合、ＡＴＲ２８−６におけるアクションタイプは、そのアクションタイプを実装するために、ＡＬＵ２８−１０内に特定の回路構成またはマイクロコーディングを持つ。このように、本発明におけるアクションタイプは、従来のコンピュータにおける命令と同等であり、ＡＴＲ２８−６は、同様に、命令レジスタと同等である。ＯＳ２１−１６における決定要因および結果の配置のように、アクションの実行のために必要な特定の情報は、図１７および１８に示されるように、ＡＲ２８−５で参照されたアクションオブジェクトを経由して提供される。
当然のことながら、アクティベータ、エグゼキュータおよびレコーダ処理サイクルは、それ自身、図１６に示されたルート・メタ実行サイクルのアプリケーションである。これらは、以下によって、プロセッサ構成内で実装されなければならない。それらは、起動、実行および記録サイクルによって使用されるイベント、アクションおよびオブジェクト自体が、実行されたモデルからの「ユーザ」イベント、アクションおよびオブジェクトに優先して処理されることを保証するための、イベント、アクションおよびオブジェクト待ち行列（多重待ち行列または待ち行列内の優先度を使用して）の更なる操作、起動、実行および記録サイクルを実行するために特に設計された付加的な論理回路の実装、または、具体的な機構は根本的に異なる（図２９を参照した以下の記述を参照）が、従来のコンピュータ・アーキテクチャ内のマイクロコーディングの使用に実際に類似すると考えることができる、図２６および２７に示されるような、１つ以上のより低いレベルのマシン上へのアクティベータ２１−１、エグゼキュータ２１−２および／またはレコーダ２１−３の精緻化による。いずれの場合においても、基礎となる論理回路は、アプローチが上に言及される非同期回路設計を採用して設計される。非同期回路設計アプローチを使用すると、同期逐次回路設計におけるクロックのゲート信号は、使用されるアプローチに依存して、付加論理回路、またはより低いレベルのアクティベータ、エグゼキュータおよびレコーダ装置におけるイベント信号によって置き換えられる。類似するイベント信号のアプリケーションは、非同期回路設計の分野において周知である。
当然のことながら、また、例えば、イベント、アクションおよびオブジェクト待ち行列エントリに、それらのタイプを含む、イベント、アクションおよびオブジェクトの詳細を含むような、これら起動、実行および記録サイクルの更なる最適化は有益である。
図２８のコンピューティング・デバイスは、従来のフォン・ノイマン型コンピュータに何らかの形で類似すると見られるだろう。しかし、オペレーションは、フローおよびジャンプよりもむしろ、イベント駆動である。言い換えれば、図２８のコンピューティング・デバイスは、イベント、アクションおよびオブジェクトの処理のためにプログラムカウンタを必要としない。また、アクティベータ２１−１は、上述のように、どのアクションがいつ起こるかを決定し、動作的モデルによってガイドされる。
ルート・メタ・アクタ型コンピューティング・デバイスは、また、多重プロセッサを使用して構成されることができる。これは、図２９に示される。ここでの構造は、図２８のコンピューティング・デバイスのためのものと同じであるが、アクティベータ２１−１、エグゼキュータ２１−２およびレコーダ２１−３のそれぞれは、図２８に示されているコンピューティング・デバイスのもう１つのコピーによって置き換えられる（すなわち、構成される）。アクティベータ２１−１、エグゼキュータ２１−２およびレコーダ２１−３のそれぞれは、それぞれのインタフェース２９−１、２９−２および２９−３によってチャネル２３−１に接続されている。この記述されたアーキテクチャは、いくつか修正することができる。すなわち、アクティベータ２１−１内に含まれるレコーダ２９−４はイベント待ち行列２９−５に制限され、エグゼキュータ２１−２内に含まれるレコーダ２９−６はアクション待ち行列２９−７に制限される。また、アクティベータ２１−１内に含まれるエグゼキュータ２９−８およびレコーダ２１−３内のエグゼキュータ２９−９は、それらのアクタによって必要とされる専門アクションに選択的に制限されてもよい。
図２９に示される多重プロセッサのルート・メタ・アクタ型コンピューティング・デバイスのための起動、実行および記録サイクルは、上述した単一のプロセッサによる実装のためのものに類似する。しかし、この場合には、アクティベータ２１−１、エグゼキュータ２１−２およびレコーダ２１−３のそれぞれは、それ独自のアクティベータ、エグゼキュータおよびレコーダを備えるとともに、多重プロセッサデバイスの全てのコンポーネントを接続するより高いレベルのチャネル２３−１への内部チャネルおよびインタフェースを備える専用プロセッサを明示的に持つ。このことにより、起動、実行および記録サイクルの設計は特化され得る。例えば、アクティベータのレコーダ２９−４内の記録サイクルは、イベント待ち行列におけるイベントの管理を取り扱うように特化できる。そして、アクティベータのエグゼキュータ２９−８内の実行サイクルは、図１８のモデルで説明したように、アクションを特定および開始し、親イベントをトリガするために要求されるそれらのアクションに特化することができる。
図３０は、より洗練されたアクタを形成するために複数のエレメントがどのように協働することができるかを示す。ここで、マイクロ並列処理を使用するルート・メタ・アクタ型コンピューティング・デバイス３０−０は、チャネル２３−１に双方向で接続された複数のアクティベータ２１−１、３０−１および３０−２を含む。各アクティベータ２１−１、３０−１および３０−２は、レコーダ（アクティベータ２１−１がレコーダ３０−３と共に示される）を含む。レコーダ３０−３は、イベント待ち行列３０−１５を含む。他のアクティベータ３０−１および３０−２は、同様に構成されている。図示しないが、各アクティベータ２１−１、３０−１および３０−２は、複数のレコーダを含むことができる。複数のエグゼキュータ２１−２、３０−４および３０−５は、チャネル２３−１に双方向で接続されている。それぞれはレコーダ３０−６を含み、各レコーダはアクション待ち行列３０−７を含む。２つのレコーダ２１−３、３０−８は、チャネル２３−１に双方向で接続されている。それぞれはレコーダ３０−９を含み、各レコーダはオブジェクト待ち行列３０−１０を含む。各待ち行列３０−３、３０−７および３０−１０は、イベント、アクションおよびオブジェクトをそれぞれ、要求に応じて、先入れ先出し方式で提供する。チャネル２３−１は、インタフェース２４−２に双方向で接続されている。チャネル２３−１への様々なコンポーネントの接続は、それらを同じ場所に配置する必要を無くすため、それらは、物理的に分散することができる。
アクティベータ２１−１内に含まれるレコーダ３０−３は、イベント待ち行列３０−１５を含む。他のアクティベータ３０−１、３０−２におけるレコーダ（図示せず）は、イベント待ち行列を含まない。同様に、エグゼキュータ２１−２内に含まれるレコーダ３０−６は、アクション待ち行列３０−７を含む。他のエグゼキュータ３０−４、３０−５におけるレコーダ（図示せず）はいずれも、アクション待ち行列を含まない。アクティベータ２１−１、３０−１、３０−２におけるレコーダは、オブジェクトまたはアクション待ち行列を含まない。エグゼキュータ２１−２、３０−４、３０−５におけるレコーダは、オブジェクトまたはイベント待ち行列を含まない。また、アクティベータ２１−１、３０−１、３０−２（各アクティベータに複数のエグゼキュータがある）内のエグゼキュータまたはエグゼキュータら３０−１１、３０−１２、３０−１３、およびレコーダ２１−３、３０−８内のエグゼキュータ３０−１４は、それらのアクタによって必要とされる専門アクションに限定されてもよい。したがって、並列処理は、多重アクティベータ、エグゼキュータおよびレコーダによって可能である。それぞれは、共通イベント、アクションおよびオブジェクト待ち行列をそれぞれ共有し、アクティビティの、多重プロセッサからの供給と多重プロセッサによる処理を同時に可能にする。
多重アクション待ち行列３０−７、イベント待ち行列３０−１５、およびオブジェクト待ち行列３０−１０は、複数のエグゼキュータ２１−２、アクティベータ２１−１およびレコーダ２１−３がそれぞれ協働しないところで必要とされる。選択的に、各エグゼキュータ、アクティベータおよびレコーダは、関連する待ち行列を持つことができ、協働するエグゼキュータ、アクティベータまたはレコーダの集合において唯一の待ち行列が所定の時刻に使用されるように要求されると待ち行列は無効にされる。
図３０に示されたアーキテクチャに基づくデバイスは、それらのコンポーネントの全てを、単一の物理筐体に結合してもよい。代わりに、コンポーネントのコレクションは、分散コンピュータシステムにおけるように、互いに物理的に離れていてもよい。
図３０を参照して記述されるルート・メタ・アクタ型アプローチにより、並列アーキテクチャは採用され、それらのために、オリジナル問題領域からシステムモデルを適応する必要なく、パフォーマンス改善のために利用されることができる。これは、従来のフォン・ノイマン型アーキテクチャのプログラムカウンタがもはや要求されないけれども達成され、したがって、ハードウェアは、先行技術のコンピュータ・アーキテクチャを決定付ける逐次的／直列的パラダイムから自由になる。このアプローチにおけるルート・メタ・アクタは、また、フォン・ノイマン・アプローチを使用しない他の先行技術のコンピュータ・アーキテクチャに対しても利点を持つ。特に、ルート・メタ・アクタ型モデルにおける並行処理は、根本的にそれを実装するシステムモデルのイベント駆動型性質に由来する。これは、依然として逐次パラダイムに基づく並行逐次プロセスモデルに対比される。すなわち、各プロセッサが、サポートできる並列処理の粒度を限定する基本的に逐次的なマシン上で動作する。また、ルート・メタ・アクタ型モデルにおけるアクション間の依存関係は、明示的に定義され、動的に生成されるイベントを経由する。これは、先行技術のデータフローモデルより、大きな柔軟性と幅広いアプリケーションを提供する。データフローモデルもまたプログラムカウンタを排除し、より粒度の細かい並列処理を可能にするけれども、アクションを駆動するイベントは、暗黙的でコンパイラによって予め決定され、その待ち行列は、照合トークンを受け付けることで開始されるように機能する。また、ルート・メタ・アクタ型モデルは、メッセージの受け付けに応じてのみアクションを開始するアクタモデルに対する改良も提供する。受け付けたメッセージがアクタモデルにおいてアクションを開始することができる唯一のイベントのタイプであるので、その実在のイベント駆動型システムへの適応性は限定される。
加えて、基本プロセスを駆動するイベント駆動型モデルに組み込まれたメタ・モデルおよびルート・メタ・モデルを持つルート・メタ・アクタは、いずれのモデルも意味上のギャップを越えて静的に変換されたオフラインの専門プログラミングにリソースなしに適応させることができるので、明確で適応性の高いシステムをサポートすることができる。これは、オブジェクト指向型アプローチとは対照的であり、例えば、よくても、メタ・モデルは不完全あり、専門開発者だけが利用でき、システムオペレーション中に適応はできない。図３１Ａは、図３０に示される大規模並列アーキテクチャが、密結合または疎結合の統合パーソナル・コンピューティング・システム３１−０を提供するために、どのように構成されるのかを示す。この構成において、１つ以上のアクティベータ３１−１、３１−２、３１−３、エグゼキュータ３１−４、３１−５、３１−６およびレコーダ３１−７、３１−８、３１−９は、いくつかの並行で、おそらく大規模な並列で、イベント駆動型のモデルを同時にサポートすることができるシステムの基本処理能力を提供する。ここで、システムの主なインタフェース（すなわち、人間工学インタフェース３１−１０、長期記憶システム３１−１１、印刷システム３１−１２および通信システム）は、更なるルート・メタ・プロセッサ型マシンによって提供される。これらのルート・メタ・プロセッサ型マシンのそれぞれは、コアプロセッサの基本内部チャネルに接続するためと、人間工学インタフェース３１−１０のキーボードコントローラ３１−１４、または長期記憶システム３１−１１のディスクコントローラ３１−１５のような、専用周辺装置インタフェースに接続するための更なるインタフェースと共に、図示されるように、チャネルを経由して接続された、少なくとも１つのアクティベータ、エグゼキュータおよびレコーダを含む。このインタフェース・アクティビティを専用インタフェースプロセッサ３１−１４、３１−１５に分配することは、そのようなアクティビティに含まれることからコアプロセッサを自由にし（従来のフォン・ノイマン・プロセッサにおけるのとは異なって）、基本プロセッサのスループットを著しく増加させる。この場合、協働するアクティベータ３１−１、３１−２、３１−３、エグゼキュータ３１−４、３１−５、３１−６およびレコーダ３１−７、３１−８、３１−９は、基本プロセッサを構成する。この構成３１−０の処理能力は、例えば、スピーカーやマイクのような関連するデバイスを、独自のルート・メタ・プロセッサを備えるヘッドセット３１−１６に結合することにより、更に分散されることができる。このことにより、ヘッドセット３１−１６は、より広い人間工学インタフェース３１−１０を伴うこともなく、音声認識または音声合成のように、聴覚／経口インタフェースのある態様を請け負うことができる。適切に構成された、そのような統合パーソナル・コンピューティング・システム３１−０は、今日の不完全な統合デバイスのコレクションを損なうデバイスおよびデータの冗長性なしに、従来のパーソナルコンピュータ（ＰＣ）、携帯電話、携帯情報端末（ＰＤＡ）およびデジタル時計の特徴を提供することができるだろう。
図３１Ｂは、そのようなルート・メタ・プロセッサ型統合パーソナル・コンピューティング・システム３１−０のために、オペレーティング・システム３１−２０がどのように設計されるのであろうかを示す。ダイアグラムの最下層は、図３１Ａに示される、チャネルによって接続された統合パーソナル・コンピュータ・ハードウェア構成の選択エレメントを示す。それらの上は、全てのまたはそれぞれ別個のプロセッサタイプに共通するオペレーティング・システムのレイヤである。ユーザアプリケーション３１−２１、システムコールハンドラ３１−２２および低レベルハードウェア隠蔽３１−２３のレイヤは、全てのプロセッサタイプに類似または共通し、従来の階層化オペレーティング・システム（図５参照）における等価レイヤに類似する。従来の階層化オペレーティング・システムとの主要な相違は、中間レイヤにある。仮想起動、仮想実行および仮想オブジェクト管理レイヤ３１−２４、３１−２５、３１−２６はそれぞれ、図１８に示された一般モデルに基づくアクティベータ３１−１、エグゼキュータ３１−４およびレコーダ３１−７のそれぞれのための動作的モデルの実装を提供する。コアプロセッサにおいて、それらの上には、互いに逆の影響を与えることなしに、同時に処理中であるべき多重モデルを提供する仮想モデル実行管理レイヤ３１−２７がある。他の全てのプロセッサタイプは、また、それぞれがそのコアでルート・メタ・プロセッサ構成を持つので、仮想モデル実行管理のいくつかのエレメントと同様に、仮想起動、実行およびオブジェクト管理の共通基盤が必要である。３１−２８、３１−２９、３１−３０および３１−３１には、人間工学インタフェース３１−１０、長期記憶システム３１−１１、印刷システム３１−１２および通信システム３１−１３がそれぞれ示されている。しかし、これらの基盤レイヤ３１−２８、３１−２９、３１−３０、３１−３１の上に何が載るかは、プロセッサの性質に依存する。例えば、長期記憶システム３１−１１は、記憶されるオブジェクトの性質に依存しながら、ディスクドライバ３１−３２、オブジェクト記憶管理システム３１−３３および、おそらくドキュメント管理システムのレイヤを構築する。図２６に示されるように、各レイヤ３１−３４、３１−３３、３１−３２は、それを精緻化するために、下のレイヤに依存する。このアプローチは、各プロセッサタイプから不必要なコンポーネントを取り除き、それらを適切に特化することを可能にする。それは、また、従来の階層化オペレーティング・システムにおけるユーザアプリケーション・レイヤにしばしば委託されているコンポーネントで、オペレーティング・システム３１−２０を豊かにすることを可能にする。例えば、ヘッドセット・オペレーティング・システム３１−１６を特化させると、個々人（ヘッドセット装着者）の音声に合わせられ、統合パーソナル・コンピューティング・システム３１−０内の潜在的なマルチユーザ・アプリケーションに接続できる音声認識エレメント（図示せず）を組み込むことができる。
図３１Ｂに示されるオペレーティング・システムは、図５に示すように、オペレーティング・システムの全レイヤが単一のプロセッサ（ＣＰＵ）上で混ぜ合わされる従来の現代の階層化オペレーティング・システム設計と対比される。それは、また、周知の多重プロセッサ、多重コンピュータおよび分散コンピュータ構成のような、多重プロセッサための先の設計と対比される。特に、ルート・メタ・プロセッサのアーキテクチャによれば、アクティビティ・スケジューリング（従来からの「プロセス」または「スレッド」スケジューリング）およびアクティビティ同期は、従来の多重プロセッサ・オペレーティング・システムための２つの重要な挑戦であり、共に相当に単純化され、密結合から疎結合構成まで広い範囲の多重プロセッサを可能にする。これらは、従来のフォン・ノイマン型プロセッサの多重プロセッサを調整するための複雑さのかなりの増加を余儀なくされるだろう。アクティビティ・スケジューリングは、スケジューラが実行する新しいプロセスを選択するように、逐次プロセスコンテキストがＣＰＵの内外を切り換えられる必要がないので、より単純である。アクティビティ同期は、クロックサイクルおよび自動的に増加するプログラムカウンタによって駆動される従来の逐次プロセスと比較して、イベント駆動型モデルの自然な状態は他のアクティビティからの入力のようなイベントがトリガされるまで待つことであるので、より単純である。
オペレーティング・システムのサブジェクトシステムは、コンピュータのリソースおよび／または仮想マシンのシステムである。
図３２Ａは、従来の（すなわち、フォン・ノイマン型）コンピュータハードウェア上で、コンパイルまたはインタープリートのような静的変換を採用する、仮想ルート・メタ・アクタを精緻化する１つのアプローチを示す。このアプローチにおいて、メタ・トランスレータ３２−１（すなわち、コンパイラまたはインタープリタ）は、基礎となるハードウェアのためのメタ・モデル３２−３とともにアプリケーション・メタ・モデル３２−２を使用して生成される。メタ・トランスレータ３２−１は、基礎となるハードウェアの逐次特性の観点から必要とされる付加ルールおよび制約と共に、仮想階層化メタ・アクタのエラボレータ・コンポーネントと同様のルールを含む。それから、１つ以上のアプリケーションモデル３２−４は、他のコンパイルされたいずれのプログラムとも同様に、基礎となるコンピュータ３２−６上で直接的に実行されることができるオブジェクトコード３２−５に静的に変換されることができる。この図において、メタ・トランスレータ３２−１からオブジェクトコード３２−５への変換３２−７は静的であり、そこから、ハードウェア３２−６上への動的精緻化３２−８がある。メタ・トランスレータ３２−１への入力は、アプリケーションモデル３２−４からのモデル入力である。
ここで、「従来のコンピュータ」という用語は、バスに結合されたプロセッサおよびメモリを持つコンピュータを含み、またスーパーコンピュータのように並列に接続されたプロセッサを持つコンピュータを含むように理解されるだろう。
図３２Ｂは、仮想精緻化マシンを採用し、従来の（すなわち、フォン・ノイマン型）コンピュータハードウェア上で仮想ルート・メタ・アクタを精緻化する代替アプローチを示す。このアプローチにおいて、メタ・トランスレータ３２−１が再び必要とされるが、この場合には、基礎となるコンピュータ３２−６の上で作動する仮想マシン（ＶＭ）のためのオブジェクトコードを生成するために使用される。ＶＭは、ＶＭ特有のアプリケーション・エラボレータ３２−１０を経由して、アプリケーションモデルが精緻化されることができる疑似ルート・メタ・アクタ・マシンを生成する。メタ・トランスレータ３２−１からＶＭオブジェクトコード３２−９への静的変換、および動的エラボレータ３２−１０からＶＭオブジェクトコードへと、そこから基礎となるコンピュータ３２−６への動的精緻化がある。アプリケーション・エラボレータ３２−１０およびＶＭ３２−９は共に、動的な並列モデル、メタ・モデルおよびルート・メタ・モデルと、基礎となるマシン３２−６の静的な逐次的特性との間の意味上のギャップを処理する。
図３０を参照して記述される大規模マイクロ並列プロセッサは、従来のソフトウェアを採用することができるとしても、これは、このアーキテクチャの使用を通じて得られるであろう利益に制限を加えるであろう。従来のソフトウェアは、基本的に逐次的であり、問題分野およびコンピュータ分野にある意味上のギャップを強化する。また、それは、前もって、または実行時に変換を必要とする。これは、ソフトウェアの性能における柔軟性に限界を与える。
反対に、上述の階層化仮想アクタモデルを採用するソフトウェアは、特に図２６に関して、根本的に粒度が細かく、かつ本質的に並列である。これは、意味上のギャップを除去し、部分変換のみを要求する（後述するように）。この部分的変換は、前もって行う必要はなく、実行時にのみ行えばよい。それゆえ、ルート・メタ・アクタ型ソフトウェアは、より柔軟であり、よりパフォーマンスの向上をサポートできる。
ルート・メタ・アクタ型ソフトウェアは、基本アクションのみが基礎となるマシン（エラボレータによって実行されるトランスレーション）上に変換される必要があるという点と、１つのレベルのモデル内での基本アクションが、より低いレベルで、プログラムではなく、マイクロイベント駆動型モデルとして、それぞれ変換されるという点で従来のソフトウェアとは異なる。このマイクロイベント駆動型モデルは、専有するルート・メタ・アクタ型ハードウェアが利用できるという条件の下で、他のモデルに対してそれ自体並列に実行されることができる。
ルート・メタ・アクタ型シミュレータは、意図されたサブジェクトシステムに強い影響を与えることなく、モデルの詳細および動きの両方を調査できるように、モデルが代理サブジェクトシステムに対して実行されることを可能にするエラボレータの特化タイプである。図２６および２７を参照して上述されたエラボレータの特徴に加えて、シミュレータは、以下を処理するためのルールを含む。それらは、シミュレーション、物理および壁時計時間の間の関係と、例えば顧客注文の頻度や、異なる製品仕様に期待する注文の割合といった、内部および外部イベントの配分と、シミュレートされたアクタの生成および削除、ならびにシミュレートされたモデル内でのそれらの役割の割り当ておよび再割り当てと、シミュレーションシステム内の実際の物理アクタに対するシミュレートされたアクタの割り当ておよび精緻化である。最後は、図３０に示されるような分散マイクロ並列アーキテクチャ・ハードウェアの上で行われるシミュレーションにおいて特に重要である。分散システムは、例えば戦争ゲームのように、異なるユニットが異なる場所に配置される状況において使用されるとよい。ここで、マイクロ並列ハードウェアの多重集合があり得、各集合は異なる物理配置にある。１つ以上のシミュレートされたアクタは、物理シミュレーションシステムの各ノードによって処理される。そして、シミュレーション・マネージャは、シミュレートされたアクタが互いに通信するように、異なるノード間でメッセージの経路を制御するためのルールを持つだろう。
ルート・メタ・アクタ型シミュレータ・アプローチは、システムのモデルから直接的に、システム力学のシミュレーションを可能にする。これは、シミュレーションを、ビジネスおよび技術変化プログラムに、より利用しやすくする。これによって、実装された変化の品質およびパフォーマンスにおける結果としてあり得る改良を伴い、シミュレーションが使用される見込みが増加する。
分析シミュレータおよびデジタル仮想環境のいずれも、ルート・メタ・アクタ型基盤上でシミュレートされることができる。これは、ビジネス変化プロジェクトの間の特別な使用である。ここにおいて、モデル化された時点で、特別なプロセスがその見込みのあるパフォーマンスを分析するようにシミュレートされ、それから同じモデルを採用するデジタル仮想環境を通じてワーカーと通信することができる。
ルート・メタ・アクタ型シミュレータは、また、２つの方法により、先行技術よりも洗練されたシミュレーションの機会を提供する。第１に、シミュレーションの間のシミュレートされたアクタの生成および削除を可能にすることによって、複雑なシステムの動きを個々のアクタモデルの詳細から直接的に調査することができる。特に、これは、マーケティングおよび軍事アプリケーションで見出されるように、アクタグループ内に動きがあるシミュレーションに役立つ。例えば、市場シミュレーションにおいて、顧客の個々の行動は、情報を口コミで伝える方法を含めて、モデル化することができる。それから、シミュレーションは、良いニュースが伝わると、新しいアクタを生成することができ、反対に、悪いニュースが広まると、または競争相手が市場シェアを増加させると、アクタを削除することができる。第２に、メタ・モデルを含むモデルのシミュレーションは、シミュレーションが実行されている間に、システムルールの適応を容易に含むことができる。それは、特にあるゲーム、トレーニングまたは設計ワークショップのアプリケーションに役立つことができる。
ルート・メタ・アクタ型シミュレータとルート・メタ・アクタ型コンピューティング基盤との結合は、図３０を参照して上述された大規模マイクロ並列アーキテクチャの粒度の細かい並列処理の開発によって、並列実装された論理プロセス間の同期に関連する複雑さを取り除く。また、分散システムは、例えば戦争ゲームのような、異なるユニットが異なる場所に配置されている状況に用いられるかもしれない。ここで、各セットが異なる物理配置にあるマイクロ並列ハードウェアの多重セットがあってよい。１つ以上のシミュレートされたアクタは、物理シミュレーションシステムの各ノードによって処理され、シミュレータは、シミュレートされたアクタが互いに通信するように、異なるノード間でメッセージの経路制御を管理しなければならない。物理的に、かつ一時的にリモートあるシミュレーションノード間での同期問題が残るが、ルート・メタ・アクタ型シミュレータの使用は、他の複雑さを取り除き、並列および分散シミュレーションの実装を単純にする。
シミュレータのサブジェクトシステムは、アクタの動的パフォーマンスについてのデータの収集および分析、またはデジタル仮想環境の少なくともコンポーネントの生成のいずれかの目的のための、意図されたあるいは実在のサブジェクトシステムの人工複製である。人工複製は、通常、意図されたあるいは実在のサブジェクトシステムにおける場合より、著しく速くまたは遅くすることができるシミュレーション時間の管理を必要とするだろう。
本発明の、自己適応システムへの応用について説明する。高レベルな自己適応システムは、図３３に示されている。ここで、ディレクティングアクタ３３−１、オペレーティングアクタ３３−２、管理アクタ３３−３、学習アクタ３３−４および実現アクタ３３−５は、通信チャネル３３−６にそれぞれ接続されている。図示する５つのアクタはそれぞれ、上述のルート・メタ・アクタであることができる。オペレーティングアクタ３３−２は、時に「変形プロセス」と呼ばれる中心的な動作を行う。ディレクティングアクタ３３−１は、目的、パフォーマンス目標および制約に関して、全体的な命令を提供する。管理アクタ３３−３は、ディレクティングアクタ３３−１によって提供される命令に照らして、システムの動作を計画し、監視し、そして制御する。学習アクタ３３−４は、システム全体のパフォーマンスを改善または最大化するために、自己適応システムが学習することを可能にする。実現アクタ３３−５は、システムにその他のアクティビティの全てを生じさせることが可能なアクタを取得または生成する機能を持つ。この状況において、実現アクタ３３−５によって取得または生成されるアクタは、人間、機械、ソフトウェア等であるだろう。
自己適応システムは、以下に詳述する「発展可能知能エージェント」であってよい。
自己適応アクタのサブジェクトシステムは、単純または合成アクタのためのサブジェクトシステムに類似する。
図３４は、ディレクティングアクタ３３−１、実現アクタ３３−５、オペレーティングアクタ３３−２、学習アクタ３３−４および管理アクタ３３−３のそれぞれが、それら自身の個別の自己適応システムを、どのように含むかを示す。これは、再帰的自己適応システムとして考えることができる。
オペレーティングアクタ３３−２のサブジェクトシステムは、合成自己適応アクタと同じサブジェクトシステムである。すなわち、それは、自己適応アクタのサブジェクトシステム上で実際に動作する自己適応アクタのオペレーティングアクタ・コンポーネントである。ディレクティングアクタ３３−１のサブジェクトシステムは、自己適応アクタのための目的およびパフォーマンス目標のシステムである。管理アクタ３３−３のサブジェクトシステムは、ディレクティングアクタ３３−１によって定義される目的およびパフォーマンス目標に基づく、自己適応アクタのための計画および監視指標のシステムである。学習アクタ３３−４のサブジェクトシステムは、合成自己適応アクタ内の全てのアクタによって採用されているモデルおよびメタ・モデルの（メタ・）システムである。実現アクタ３３−５のサブジェクトシステムは、合成自己適応アクタ内の全てのアクタの責務を実行することができるアクタのシステムである。
多数重なった再帰的自己適応システムは、図３５に示されている。ここで、学習アクタ３３−４は、それ自体が更なる自己適応システムを含む学習アクタ３５−１を含む自己適応システムを含む。同様に、オペレーティングアクタ３３−２は、自己適応システムを含む。そのオペレータ３５−２は、更なる自己適応システムであるオペレーティングアクタ３５−３を持つ更なる自己適応システムを含む。この概念が、実現アクタ３３−５、ディレクティングアクタ３３−１および管理アクタ３３−３内の多重再帰にどのように適用されることができるかが分かる。図３５の例において、最上位のアクタ内の再帰に依存するのは同じアクタであるが、これは必須ではない。実際に、最高レベルのアクタの１つを形成する自己適応システム内で、多重アクタの再帰があり得る。
ルート・メタ・アクタ型人工知能エージェントは、協働する仮想アクタの集合に具体化されることができる。それぞれのアクタは、図３３に示されるアクタの１つを表す。この知能エージェントには、従来のエキスパートシステム推論エンジンに対する多くの重要な相違がある。特に、モデルコンポーネントは、従来のＩＦ、ＴＨＥＮ生成規則を使用するよりもむしろ、完全なイベント駆動型として考えられる。また、一般ルート・メタ・プロセッサは、先のサイクルで生成されたイベントに基づくモデルのルールの部分走査を請け負う。そしてこれは、従来のエキスパートシステム推論エンジンにおいて起こるような、サイクル毎にルールベースの全走査が実行されるスキームと比較して、改善された効率を提供する。更に、新しいルールの検索は、学習アクタ３３−４によって実行される。そして、新しいルールの出力結果は、他のアクタ３３−１、３３−５、３３−２、３３−３のメタ・モデルにおける変化を通じて通信される。従来のエキスパートシステム推論エンジンとは対照的に、メタ・アクタ型知能エージェントは、新しい役割を果たすアクタを募集または生成できる実現アクタ３３−５を含み、その役割は、学習アクタ３３−４によって特定される。そして、適切な権限を与えられて、完全な人工知能エージェントを発展可能にすることができる。
ルート・メタ・アクタ型知能エージェントにセンサおよびアクチュエータを備えると（例えば、ロボット環境の中で）、そのエージェントは、現実世界をサブジェクトシステムとすることができる。
ルート・メタ・アクタ型アプローチをシステム開発に適用すると、発展可能学習システムとしてシステムプロジェクトを確立することができる。これは、他の発展可能学習システムと同じ機構を使用する目標システムを生成または変化させるように、指示され、作動され、管理され、有効にされ、そして適応される。（ここでは、「システム」という単語は、図１を参照して先に述べた全ての意味で使用されることに注意されたい。）４つの従属するアクティビティシステム、すなわち調査、開発、準備および配置システムとして、システム開発プロジェクト・オペレーションを始めることも可能である。調査システムは、システム開発プロジェクト全体の目標であるシステムが中断されることによってトリガされる。その目的は、ある問題または機会を理解し、それにどのように対処すべきかについてのモデルに到達することである。開発システムは、目標システムを調査システムから変化させるための定義された要件によってトリガされる。開発システムは、その変化を設計し、構築し、そしてシミュレートする。準備システムもまた、調査から定義された変化要件によってトリガされる。準備システムは、変化が展開されるであろう一時的なシステムを設計し、構築し、そしてシミュレートする。配置システムは、開発システムおよび準備システムの両者の完了によってトリガされる。配置システムは、開発システムにおいて定義される目標システムに対する変化を実装するための準備システムにおいて定義される一時的なシステムを実行する。
開発および準備システムは、調査システムに類似するパターンのアクティビティ、すなわちモデル化およびシミュレーションを用いて作動される。モデル化パターンは、サブジェクトシステムがこれを用いて作動するルールを定義し、アクタを役割に割り当て精緻化する。そして、各アクタは、それらの役割内の個別の責務を処理する。シミュレーションシステムは、ルールおよびモデル化された役割の詳細をテストし、結果として生じる相互作用の動きを分析する。
これは、図３６に示されている。図３６を参照すると、自己適応システムは、オペレーティングアクタ３７−１が、調査システム３７−２、開発システム３７−３、準備システム３７−４および配置システム３７−５を含むように示される。調査システム内には、モデル化システム３７−６およびシミュレーションシステム３７−７が含まれる。モデル化システムにおいて、ルールは定義され、役割が割り当てられて精緻化される。シミュレーションシステム３７−７において、詳細はテストされ、動作は分析される。開発および準備システム３７−３、３７−４は、また、モデル化およびシミュレーションシステム３７−６、３７−７を含む。しかしながら、これらは明瞭化のために、図から省かれている。開発および準備システム３７−３、３７−４は、調査システム３７−２の出力に並列に接続されている。開発および準備システム３７−３、３７−４は、また、それらが互いに相互作用するように、互いに接続されている。これらのシステムのそれぞれは、配置システム３７−５に接続された出力を持つ。
調査、開発および準備アクティビティシステムの間の重要な相違は、何がモデル化され、シミュレートされるかである。調査システムにとっては、目標システム内でどれがモデル化され、シミュレートされるかが問題または機会である。調査の目的は、開発および準備を開始するために、何が変化される必要があるのかの十分な理解を得ることである。開発システムにとって、目標システムの変化は、それ自体がモデル化およびシミュレートされる。準備システムにとって、モデル化およびシミュレートされるものは、それによって変化が展開されるシステムである。準備システムは、目標システムにおける現在の状態と未来の状態との間の遷移の期間だけ存在する一時的なシステムである。しかし、準備システムは、数ヶ月以上存在してもよい。ここでは、変化は、例えば、大企業に対する顕著な変化であり、トレーニングおよび新しい役割や責務、ハードウェアおよびソフトウェアの調達および設定等を含むかもしれない。
異なるシステムに生成したアクションであるけれども、開発および準備アクティビティシステムは、互いに相互作用する必要がある。準備システムは、何が配置されようとしているかを知る必要がある。そして、開発システムは、異なる設計オプションの配置関係を考える必要がある。そして、必要に応じて、配置努力またはリスクを最小化するようにそのアプローチを変化させる。
このシステム開発方法論は、先行技術のシステム開発方法論（図９Ａおよび９Ｂ参照）において見出されたようなフロー駆動というよりは、イベント駆動である。これもまた、メタ・モデル型であり、再使用できるプロジェクトのクラスを定義するために使用できる。また、システム開発方法論は、学習システムであり、したがって、そのパフォーマンスを向上するための方法を学習することができる。また、この方法論は、階層化仮想アクタをハードウェア・アーキテクチャから高レベル設計に具体化する。
従来のアプローチと比較して、上述のシステム開発方法論は、統合モデルを具体化し、問題および実装分野間での意味上のギャップを含まず、１つのステージのモデルの、後のステージでのモデルへの変換を必要としない。代わりに、それは、アーキテクチャのより低いレイヤにおける１つ以上の仮想アクタのための、エラボレータを提供することだけが必要とされる。また、同じアクティビティおよび技術は、同じものを異なるステージで、かつ例えば、ソフトウェア、ハードウェアおよびプロセス分野等の異なる分野内で行う。これは、サイクルにおいて従来の方法論で見出されるよりも後で、異なるタイプのアクタ
（例えば、ソフトウェアやハードウェア）への役割の割り当てに関する決定をすることができ、より高い柔軟性をもたらす。また、それは、含まれる全てのシステムを駆動する階層化イベント駆動型メタ・モデルが、一般的な再利用可能なコンポーネントを生成するための基礎として、より適切であることができるので、実現されるべき再利用性の見込みおよびその得られる利益を提供する。
システム開発方法論のサブジェクトシステムは、複雑な技術的および社会技術的システム変化を含むシステム変化のシステムである。
以下は、上記実施形態の全てに適用され、いくつかの他の図へのキーの役割を果たす図２２Ａおよび２２Ｂを参照する一般的なコメントである。
ルート・メタ・モデルにおいて、アクティビティシステムの全てのタイプは、サブジェクトシステムのオブジェクト、イベントおよびアクションに関してモデル化される。そして、アクティビティは、アクタの間で共有される。最大の利益を得るために、メタ・レベルでのモデル化は、各モデルの柔軟性および再利用性を最大化する。モデル化アクティビティシステムにおいて、オブジェクトが人物、場所（配置）、イベント、アクションまたは物（例えば、物理オブジェクト）を表現できることを認めるのは有益である。図２２Ａおよび２２Ｂにおいて、Ｏ１からＯ１０およびＯＡからＯＣでラベル付けられた直角コーナーを備える全てのボックスは、オブジェクトを表す。オブジェクトは、例えば、値Ｏ１（例えば、整数または文字）、または参照Ｏ２（例えば、あるものへのポインタ）のように基本であってもよい。オブジェクトは、例えば、合成オブジェクトＯ３や、集合Ｏ６またはＯ７のようなオブジェクトのコレクションのように合成されていてもよい。オブジェクトは、代わりに、順序あるいは配列等（図示せず）としてもよい。
イベントは、別のオブジェクトの状態の瞬間的な変化を反映するオブジェクトと考えられてもよい。図２２Ａおよび２２Ｂにおいて、α、Δ、Ｅ１、Ｔ、Ｆ、ＡＮＹおよびΩでラベル付けられる全ての矢型ボックスは、イベントを表す。イベントは、基本であってよい。その場合においては、それはオブジェクトイベントまたはアクションイベントのいずれかかもしれない。オブジェクトイベントは、生成された（α）、削除された（図示せず）および変化または修正された（Δ）ものを含む。アクションイベントは、開始（明示的に示されない）、完了（Ω）、および完了時の状態（ＴおよびＦ）を含む。開始イベントは、アクションが実行を開始されるときに起こる。図２２Ｂにおいて、Ａ１の左上コーナーからＡ１．１の左上コーナーまでのリンクによって示されるように、イベントＥ１は、アクションＡ１を開始し、次にアクションＡ１．１を開始する。完了（Ω）イベントは、アクションの実行が終了したときに起こる。あるアクションにとって、重要なのはアクションの出力結果である。これは、特に、真Ｔまたは偽Ｆの出力結果となる２値テストに適用できるが、また、２つより多い出力結果の状態（図示せず）があるかもしれないｎ値テスト（例えば高級言語における「ＣＡＳＥ」文）に適用してもよい。結果イベントは、「完了時状態」イベントと名付けることができる。合成イベントは、そのコンポーネントの１つが起こるときに起こるＡＮＹイベントであることができる。あるいは、合成イベントは、そのコンポーネントの全てが起こったときに起こるＡＬＬイベント（図示せず）であることができる。これらは、ＯＲおよびＡＮＤイベントとして考えることができる。
アクションは、イベントに応答して開始され、他のオブジェクトの変化を引き起こすオブジェクトである。図２２Ｂにおいて、Ａ１およびＡ１．１からＡ１．４でラベル付けられた丸いコーナーの全てのボックスは、アクションを表す。アクションは、基本Ａ１．１からＡ１．４、または合成Ａ１であってよい。合成アクションＡ１は、サブ・アクションＡ１．１からＡ１．４で構成されている。それらはそれぞれ、合成アクションの開始によって直接的にまたは間接的にトリガされたイベントによって順に開始される。合成アクション内のイベントおよびサブ・アクションの構成次第で、それは、順序（アクションＡ１．２またはＡ１．３の完了によって開始されるアクションＡ１．４のように、次々と開始されるサブ・アクション）、同時並行（２つ以上のサブ・アクションが並列、図示せず）、再帰（ここで、サブ・アクションは合成アクションを直接的にまたは間接的に参照する、図示せず）、ＩＦ ＴＨＥＮ（スキップ）アクションのような選択、またはＩＦ ＴＨＥＮ ＥＬＳＥ（２分岐）アクション（Ａ１．１が真状態で終了すると開始されるＡ１．２、または偽状態においてＡ１．１が終了すると開始されるＡ１．３の二者択一のアクションが続くテストアクションＡ１．１として示される）、またはＣＡＳＥ（ｎ分岐選択、図示せず）アクション、サブ・アクションを０回以上（ＷＨＩＬＥ、図示せず）または１回以上（ＲＥＰＥＡＴ、図示せず）繰り返す繰り返しを形成することができる。このアプローチを使用して利用できる繰り返しアクションの特化タイプは、同じサブ・アクションがオブジェクト集合の各メンバのために開始され、サブ・アクションの各発生が他と並列に進行する複製（図示せず）である。
ルート・メタ・アクタ型モデルの利点は、それらがルート・メタ・一般実行モデルを採用すること、それらがイベント駆動型および並列（先行技術において見出されるようなフロー駆動および逐次に対照されるように）であることを含む。また、例外処理は、それらの処理が先行技術のモデル化に対してより複雑であるのにもかかわらず、単にイベントのもう１つの種類として処理される。それはまた、人間のための手続きが、機械のための手続きと同じ言語で書かれることを可能にする。更に、制約は、「アドオン」に頼ることなしに、基本モデル化言語内で処理されることができる。これは、例えば、制約がＯＣＬによって処理されることで、ＵＭＬと対照的である。また、ルート・メタ・アクタ型モデルは、人間への通信において必要な視覚表現と共に、ハードウェアおよびソフトウェアのモデル化のために必要となる正確さを提供する。重大なことには、モデルを直接的に実装可能にすることで、別の言語またはパラダイムに変換する必要なしに、それらはテストされ、シミュレートされ、直接的に採用されることができる。
上記実施形態において、各モデルは、いずれの適切な形式をとってもよい。例えば、それは、サブジェクトシステムのグラフィカル表現、または代わりに、コンピュータ可読命令の集合であってもよい。後者の場合、少なくともいくつかの命令は、非逐次的で、例えば、集合理論または数学的表記法でなされる。
上述のコンピューティング・デバイスは、特に図２８、２９および３０に関して、好ましくは電子コンピューティング・デバイスである。あるいは、それらは、生物機械、量子または他のどのようなタイプのコンピュータデバイスを代わりにしてもよい。コンピュータデバイスのそのような他の形式がどのようなもので、どのように構成されればよいかは、関連した技術における当業者によって、理解されるだろう。
上述のいずれのコンピューティング・デバイスも、例えば、汎用コンピュータ、製造またはプロセス制御デバイスシステム、ネットワークインフラ・デバイス、移動体コンピューティング・デバイス、移動体通信デバイス、家電製品、車両、コンピュータ周辺装置またはロボット等の部分として提供、または使用されるようにパッケージされてもよい。
実在の適応または自己適応システムの説明図である。 先行技術のフォン・ノイマン・コンピュータのアーキテクチャを示す図である。 先行技術のデータフローマシンを示す図である。 コンピュータハードウェア上での先行技術のソフトウェア精緻化を体系的に示す図である。 先行技術に従う現代の階層化オペレーティング・システムを示す図である。 先行技術の一般的な学習エージェントを示す図である。 先行技術の製造プロセスの部分を形成するであろうフローチャートである。 公知のＩＤＥＦおよびＵＭＬモデルを示す図である。 公知のＩＤＥＦおよびＵＭＬモデルを示す図である。 公知のＩＤＥＦおよびＵＭＬモデルを示す図である。 公知のＩＤＥＦおよびＵＭＬモデルを示す図である。 先行技術の情報エンジニアリング方法論を示す図である。 先行技術に従う一般のオブジェクト指向型方法論を図式的に示す図である。 本発明の１つの態様に従うアクタを含むアクティブシステムを示す図である。 本発明のある態様に従うモデル型アクタの代替表現を示す図である。 本発明のある態様に従うモデル型アクタの代替表現を示す図である。 図１１のアクタの部分を形成するモデルを詳細に示す図である。 図１１のアクタの部分を形成するプロセッサを詳細に示す図である。 本発明のある態様に従う単純なイベント駆動型制御モデルを示す図である。 本発明のある態様に従うルート・メタ・アクタを示す図である。 本発明のある態様に従い、図１５のルート・メタ・アクタを使用して実装されてもよいルート・メタ・実行サイクルを示す図である。 図１５のルート・メタ・アクタにおいて使用され得る１つの構造上のルート・メタ・モデルを示す図である。 図１５のルート・メタ・アクタにおいて使用され得る１つの構造上のルート・メタ・モデルを示す図である。 図１７Ａおよび１７Ｂのルート・メタ・モデルの動作的コンポーネントを示す図である。 図１７Ａおよび１７Ｂのルート・メタ・モデルの動作的コンポーネントを示す図である。 図１７Ａおよび１７Ｂのルート・メタ・モデルの動作的コンポーネントを示す図である。 図１７Ａおよび１７Ｂのルート・メタ・モデルの動作的コンポーネントを示す図である。 本発明に従って構成された単純イベント駆動型の製品組み立てモデルを示す図である。 本発明に従って構成された単純イベント駆動型の製品組み立てモデルを示す図である。 本発明のある態様に従って、それぞれがサブジェクトシステムに作用する、第１および第２のサブ・アクタを備えるアクタを示す図である。 本発明に使用される部分的な合成ルート・メタ・プロセッサを示す図である。 他のいくつかの図へのキーを示す図である。 他のいくつかの図へのキーを示す図である。 本発明のある態様に従って、チャネルを用いた本発明に従うアクタの接続を示す図である。 本発明のある態様に従い、かつそれによって使用されるルート・メタ・プロセッサを示す図である。 本発明のある態様に従う再帰的ルート・メタ・プロセッサを示す図である。 本発明に従って、多重アクタの精緻化を含むルート・メタ・アクタの階層化を示す図である。 図２６のシステムの部分を形成するかもしれない精緻化モデルの一例を挙げる図である。 図２６のシステムの部分を形成するかもしれない精緻化モデルの一例を挙げる図である。 本発明に従う単一のマイクロプロセッサを使用した電子ルート・メタ・アクタの実装を示す図である。 本発明に従う多重プロセッサを使用する電子ルート・メタ・アクタの実装を示す図である。 図３０は、本発明のある態様に従うマイクロ並列アーキテクチャを使用する電子ルート・メタ・アクタの実装を示す図である。 図３０に示されているマイクロ並列アーキテクチャを採用する統合パーソナル・コンピューティング・システムの実装を示す図である。 図３１Ａに示されている統合パーソナル・コンピューティング・システムを制御するためのオペレーティング・システムの実装を示す図である。 本発明のある態様に従う従来のハードウェア上への静的なメタ・アクタの変換を示す図である。 本発明のある態様に従って、従来のハードウェア上への仮想精緻化マシンの配置を示す図である。 本発明の態様に従って設計された自己適応システムのコンポーネントを示す図である。 更なる再帰を備える図３３のシステムを示す図である。 もっと更なる再帰を備える図３４のシステムを示す図である。 ルート・メタ・アクタを利用する本発明に従う方法論を示す図である。

Claims (128)

  1. サブジェクトシステムにアクションを生成するための装置のアクタであって、
    前記サブジェクトシステムの内部オブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、前記オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、を含む前記サブジェクトシステムのモデルと、
    前記モデルの前記ルールによって定義されるように、前記イベントに依存する前記サブジェクトシステムで、１つ以上のアクションを開始することによって、前記サブジェクトシステムにおいてイベントに応答するプロセッサと、を備えるアクタ。
  2. 全てのイベントおよびアクションは、オブジェクトとして構成される請求項１に記載のアクタ。
  3. サブジェクトシステムにアクションを生成するための装置のアクタであって、
    前記サブジェクトシステムの内部オブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、前記オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、を含む前記サブジェクトシステムのモデルと、
    前記モデルの前記ルールによって定義されるように、前記イベントに依存する前記サブジェクトシステムで、１つ以上のアクションを開始することによって、前記サブジェクトシステムにおいてイベントに応答し、単一のステップで直接的に単一のイベントに応じて開始されたアクション、あるいは、実行により直接的または間接的に生じるイベントに応じて開始されるサブ・アクションとして定義される合成アクション、を実行するプロセッサと、を備えるアクタ。
  4. 全てのイベントおよびアクションは、オブジェクトとして構成される請求項３に記載のアクタ。
  5. 前記モデルは、２つ以上のサブ・モデルを含み、前記サブ・モデルのそれぞれは、前記サブジェクトシステムのサブ・システムのモデルである請求項１から請求項４のいずれかに記載のアクタ。
  6. 前記アクタは、メタ・モデルおよびメタ・プロセッサを備えるメタ・アクタを含み、
    前記メタ・モデルは、前記モデル内のオブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、前記モデルにおけるオブジェクトの状態の変化であるイベントに応じてアクションが開始されることを定義するルールと、を含み、
    前記メタ・プロセッサは、前記メタ・モデルによって定義されるように、前記イベントに依存する前記モデルで、１つ以上のアクションを開始することによって、前記モデルにおいてイベントに応答する請求項１から請求項５のいずれかに記載のアクタ。
  7. 前記メタ・モデルは、前記モデルの部分を形成する請求項６に記載のアクタ。
  8. 前記メタ・プロセッサは前記プロセッサの部分を形成する請求項６または請求項７に記載のアクタ。
  9. 前記メタ・モデルは、２つ以上のサブ・メタ・モデルを含み、前記サブ・メタ・モデルのそれぞれは、前記モデルのサブ・システムのモデルである請求項６から請求項８のいずれかに記載のアクタ。
  10. 前記プロセッサのアクションは、ルート・メタ・モデルおよびルート・メタ・プロセッサを備えるルート・メタ・アクタによって生じ、
    前記ルート・メタ・モデルは、前記モデルと同じタイプのモデルを処理するための一般モデルであって、一般モデル実行システム内のオブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、を含み、
    前記ルート・メタ・プロセッサは、イベントがトリガされたときに、もしあるならば、どのアクションが開始されるべきかを決定し、当該アクションを開始するために、前記モデルにおける前記イベントの定義を検査する際と、アクションが開始されたときに、もしあるならば、どのオブジェクトが状態を変化されるべきかを決定し、それに応じて当該オブジェクトの状態を変えるために、前記モデルにおける前記アクションの定義を検査する際と、オブジェクトの状態が変化させられたときに、もしあるならば、どのイベントがトリガされるべきかを決定し、当該イベントをトリガするために、前記モデルにおける前記オブジェクトの定義を検査する際と、に前記ルート・メタ・モデルをガイドする請求項１から請求項５のいずれかに記載のアクタ。
  11. 前記アクタは、メタ・モデルを更に含み、
    前記メタ・モデルは、前記モデル内のオブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、
    前記モデルにおけるオブジェクトの状態の変化であるイベントの結果として、前記モデルにおけるどのイベントが開始されるべきであるかを定義するルールと、を含む請求項１０に記載のアクタ。
  12. 前記メタ・モデルは、前記モデルの部分を形成する請求項１１に記載のアクタ。
  13. 前記ルート・メタ・モデルは、前記メタ・モデルの部分を形成する請求項１２に記載のアクタ。
  14. 前記プロセッサ、または１つ以上の多重プロセッサは、
    前記モデルにおける前記イベントの定義を検査し、もしあるならば、開始すべきアクションがいずれであるかを決定し、その後当該アクションを開始するイベントのトリガに応じて動作可能な１つ以上のアクティベータと、
    前記アクションを生じるように調整されており、かつ、前記モデルのアクションの定義を検査し、もしあるならば、前記サブジェクトシステムにおいて状態を変化するオブジェクトがいずれであるかを決定し、その後それに応じて当該オブジェクトの状態を変化させるアクションの開始に応じて動作可能な１つ以上のエグゼキュータと、
    アクションの出力結果を記録するように調整されており、かつ、前記モデルにおける前記オブジェクトの定義を検査し、もしあるならば、前記サブジェクトシステムにおけるいずれのイベントが前記オブジェクトの状態の変化からの結果であるかを決定し、当該イベントをトリガするオブジェクトの状態の変化を認識することに応じて動作可能な１つ以上のレコーダと、
    前記アクタが他のアクタまたは外部世界に接続される外部チャネルへの１つ以上のインタフェースと、
    前記アクティベータ、前記エグゼキュータ、前記レコーダおよび前記インタフェースに接続される１つ以上の内部チャネルと、を備える請求項１から請求項１３のいずれかに記載のアクタ。
  15. 前記メタ・プロセッサ、または１つ以上の多重メタ・プロセッサは、
    前記メタ・モデルにおける前記イベントの定義を検査し、開始するモデルのアクションがいずれであるかを決定し、その後当該アクションを開始するイベントのトリガに応じて動作可能な１つ以上のアクティベータと、
    前記アクションを生じさせるように調整され、かつ、前記メタ・モデルにおけるアクションの定義を検査し、もしあるならば、前記モデルにおいて状態を変化するオブジェクトがいずれであるかを決定し、その後それによって当該オブジェクトを変化させるアクションの開始に応じて動作可能な１つ以上のエグゼキュータと、
    前記メタ・モデル内のオブジェクトの生成、修正または削除を含み、アクションの出力結果を記録するように調整されており、かつ、前記メタ・モデルにおける前記オブジェクトの定義を検査し、もしあるならば、前記モデルにおけるいずれのイベントが前記オブジェクトの状態の変化からの結果であるかを決定し、当該イベントをトリガするオブジェクトの状態の変化に応じて動作可能な１つ以上のレコーダと、
    前記アクタが他のアクタまたは外部世界に接続される外部チャネルへの１つ以上のインタフェースと、
    前記アクティベータ、前記エグゼキュータ、前記レコーダおよび前記インタフェースに接続される１つ以上の内部チャネルと、を備える請求項６から請求項９のいずれかに記載のアクタ。
  16. 前記ルート・メタ・プロセッサ、または１つ以上の数の多重ルート・メタ・プロセッサは、
    前記ルート・メタ・モデルにおける前記イベントの定義を検査し、いずれのアクションを開始するかを決定するイベントのトリガに応じて動作可能な１つ以上のアクティベータと、
    前記アクションを生じるように調整されており、かつ、前記ルート・メタ・モデルにおける前記アクションの定義を検査し、もしあるならば、前記プロセッサにおいて状態を変化するオブジェクトがいずれであるかを決定し、その後それによって当該オブジェクトを変化させるアクションの開始に応じて動作可能な１つ以上のエグゼキュータと、
    前記ルート・メタ・モデル内のオブジェクトの生成、修正または削除を含み、アクションの出力結果を記録するように調整されており、かつ、前記ルート・メタ・モデルにおいて前記オブジェクトの定義を検査し、もしあるならば、前記プロセッサにおけるいずれのイベントがオブジェクトの状態の変化からの結果であるかを決定し、当該イベントをトリガするオブジェクトの状態の変化に応じて実施可能な１つ以上のレコーダと、
    前記アクタが他のアクタまたは外部世界に接続される外部チャネルへの１つ以上のインタフェースと、
    前記アクティベータ、前記エグゼキュータ、前記レコーダおよび前記インタフェースに接続される１つ以上の内部チャネルと、を備える請求項１０から請求項１３のいずれかに記載のアクタ。
  17. 前記アクティベータ、前記エグゼキュータ、前記レコーダ、前記インタフェースまたは前記チャネルの１つ以上が、請求項１から請求項１６のいずれかに記載のアクタである請求項１３から請求項１６のいずれかに記載のアクタ。
  18. 前記モデルは、仮想アクタのａ）プロセッサ、ｂ）メタ・プロセッサまたはｃ）ルート・メタ・プロセッサの１つで構成されるプロセッサ・エンティティを精緻化し、その結果、前記プロセッサ・エンティティは、第１のアクタのプロセッサ、メタ・プロセッサまたはルート・メタ・プロセッサのいずれかによって直接的に実行され得る請求項１から請求項１７のいずれかに記載のアクタ。
  19. 前記アクタは、代理サブジェクトシステムにおいてアクションを開始し、
    シミュレーション、物理および壁時計時間の関係を処理し、
    第１のアクタの詳細なモデルで定義される内部および外部イベントの配分を処理し、
    シミュレートされたアクタの生成および削除、ならびにシミュレートされたモデル内における役割の割り当ておよび再割り当てを処理し、
    シミュレートされたアクタから物理アクタへの割り当ておよび精緻化を処理するルールを更に含むモデルを含む、シミュレータとしての請求項１８に記載のアクタ。
  20. 前記仮想アクタは、更なる仮想アクタのプロセッサ・エンティティを精緻化するために調整される請求項１８または請求項１９に記載のアクタ。
  21. 前記モデルは、２つ以上のサブ・モデルを含み、前記サブ・モデルのそれぞれは、１つ以上の他の仮想アクタのプロセッサ・エンティティの動作を精緻化する請求項１８から請求項２０のいずれかに記載のアクタ。
  22. 前記モデル、前記メタ・モデルまたは前記ルート・メタ・モデルは、グラフィカルに示される請求項１から請求項２１のいずれかに記載のアクタ。
  23. 前記モデル、前記メタ・モデルまたは前記ルート・メタ・モデルは、コンピュータ可読な命令の集合として示される請求項１から請求項２１のいずれかに記載のアクタ。
  24. 前記モデル、前記メタ・モデルまたは前記ルート・メタ・モデルは、集合論の数学的表記として示される請求項１から請求項２１のいずれかに記載のアクタ。
  25. 請求項１から請求項２４のいずれかに記載のアクタを２つ以上備え、各アクタが、それぞれ少なくとも１つの他のアクタに各自のチャネルを経由して接続された、共通サブジェクトシステムにおいてアクションを生じさせるために調整されるシステム。
  26. 前記各アクタは、前記アクタの部分を形成する第１のインタフェース、および前記チャネルの部分を形成する第２のインタフェースによって、各自の前記チャネルに接続される請求項２５に記載のシステム。
  27. いくつかまたは全ての前記チャネルまたは前記インタフェースは、請求項１から請求項２４のいずれかに記載のアクタである請求項２５または請求項２６に記載のシステム。
  28. 請求項２５から請求項２７のいずれかに記載のシステムを備える請求項１から請求項２４のいずれかに記載のアクタ。
  29. サブジェクトシステムにおいてアクションを生じさせるためのアクタを含む論理型コンピューティング・デバイスであって、
    前記サブジェクトシステムの内部オブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、前記オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、を含む前記サブジェクトシステムのモデルを実装する手段と、
    前記モデルの前記ルールによって定義されるように、前記イベントに依存する前記サブジェクトシステムで、１つ以上のアクションを開始することによって、前記サブジェクトシステムにおいてイベントに応答するプロセッサを実装する手段と、を備えるデバイス。
  30. 前記プロセッサは、単一のステップで直接的に単一のイベントに応じて開始されたアクションを、あるいは、実行により直接的または間接的に生じるイベントに応じて開始されるサブ・アクションとして定義される合成アクションとして実行する請求項２９に記載のデバイス。
  31. 全てのイベントおよびアクションは、オブジェクトとして構成される請求項２９または請求項３０に記載のデバイス。
  32. 前記プロセッサは、１つ以上のアクティベータ、１つ以上のエグゼキュータ、１つ以上のレコーダ、１つ以上の内部チャネル、および１つ以上のインタフェースを備える請求項２９から請求項３１に記載のデバイス。
  33. 少なくとも１つの前記レコーダは、
    多くのトリガされたイベントを含むことができるイベント待ち行列と、
    多くの開始されたアクションを含むことができるアクション待ち行列と、
    多くの参照または変更されるオブジェクトへの参照を含むことができるオブジェクト待ち行列と、を含む請求項３２に記載のデバイス。
  34. 前記イベント待ち行列は、トリガされた順に前記トリガされたイベントを含むことができ、かつ／または前記アクション待ち行列は、開始された順に前記開始されたアクションを含むことができ、かつ／または前記オブジェクト待ち行列は、発生順に前記参照を含むことができる請求項３３に記載のデバイス。
  35. 少なくとも１つの前記レコーダは、
    前記オブジェクト待ち行列におけるアイテムへの参照を含むように動作可能なオブジェクト待ち行列レジスタと、
    現在のオブジェクトへの参照を含むように動作可能なオブジェクトレジスタと、
    現在のオブジェクトのタイプを含むように動作可能なオブジェクトタイプレジスタと、を更に備える請求項３３または請求項３４に記載のデバイス。
  36. 少なくとも１つの前記アクティベータは、
    前記イベント待ち行列におけるアイテムへの参照を含むように動作可能なイベント待ち行列レジスタと、
    現在のイベントへの参照を含むように動作可能なイベントレジスタと、
    現在のイベントのタイプを含むように動作可能なイベントタイプレジスタと、を含む請求項３３から請求項３５のいずれかに記載のデバイス。
  37. 少なくとも１つの前記エグゼキュータは、
    前記アクション待ち行列におけるアイテムへの参照を含むように動作可能なアクション待ち行列レジスタと、
    現在のアクションへの参照を含むように動作可能なアクションレジスタと、
    現在のアクションのタイプを含むように動作可能なアクションタイプレジスタと、を含む請求項３３から請求項３６のいずれかに記載のデバイス。
  38. 単一の処理ユニットまたは集積回路に共に設けられている、単一のアクティベータ、単一のエグゼキュータ、単一のレコーダ、１つ以上の内部チャネル、および１つ以上のインタフェースを備える請求項２９から請求項３７のいずれかに記載のデバイス。
  39. それぞれが各自の処理ユニットまたは集積回路に設けられ、１つ以上のチャネルを経由して互いに接続された、単一のアクティベータ、単一のエグゼキュータ、単一のレコーダ、および１つ以上のインタフェースを備える請求項２９から請求項３７のいずれかに記載のデバイス。
  40. １つ以上のチャネルを経由して接続された複数の前記アクティベータを備え、少なくとも２つの前記アクティベータは、共通イベント待ち行列を共有する請求項３９に記載のデバイス。
  41. １つ以上のチャネルを経由して接続された複数の前記エグゼキュータを備え、少なくとも２つの前記エグゼキュータは、共通アクション待ち行列を共有する請求項３９または請求項４０に記載のデバイス。
  42. １つ以上のチャネルを経由して接続された複数の前記レコーダを備え、少なくとも２つの前記レコーダは、共通オブジェクト待ち行列を共有する請求項３９から請求項４１のいずれかに記載のデバイス。
  43. 前記アクティベータまたは１つ以上の前記アクティベータは、それぞれ、請求項３８から請求項４２のいずれかに記載のデバイスを備える請求項３９から請求項４２のいずれかに記載のデバイス。
  44. 前記エグゼキュータまたは１つ以上の前記エグゼキュータは、それぞれ、請求項３８から請求項４３のいずれかに記載のデバイスを備える請求項３９から請求項４３のいずれかに記載のデバイス。
  45. 前記レコーダまたは１つ以上の前記レコーダは、それぞれは、請求項３８から請求項４４のいずれかに記載のデバイスを備える請求項３９から請求項４４のいずれかに記載のデバイス。
  46. 全てのコンポーネントは、共通の筐体に配置される請求項３９から請求項４５のいずれかに記載のデバイス。
  47. ２つ以上のコンポーネントは、異なる配置に分散させる請求項３９から請求項４６のいずれかに記載のデバイス。
  48. 前記アクティベータ、前記エグゼキュータ、前記レコーダ、前記インタフェース、または前記チャネルはいずれも、請求項２９から請求項４７のいずれかに記載のデバイスを備える請求項２９から請求項４７のいずれかに記載のデバイス。
  49. 複数の前記アクティベータは、共通イベント待ち行列を共有する請求項４８に記載のデバイス。
  50. 複数の前記エグゼキュータは、共通アクション待ち行列を共有する請求項４８または請求項４９に記載のデバイス。
  51. コンピュータシステムのリソースを管理すると共に、前記コンピュータシステム上で１つ以上のモデル、メタ・モデル、またはルート・メタ・モデルの同時実行を可能とするように調整された請求項１８から請求項２１のいずれかに記載のアクタを備えるシステム。
  52. 前記モデルは、フォン・ノイマン型アーキテクチャを備えるコンピュータまたはコンピュータシステム上、もしくは、フォン・ノイマン型アーキテクチャを備えるコンピュータまたはコンピュータシステムのリソースを管理あるいは単純インタフェースを提供するオペレーティング・システム上で、プロセッサ、メタ・プロセッサ、またはルート・メタ・プロセッサの精緻化を可能にするルールを含む請求項１８から請求項２１のいずれかに記載のアクタ。
  53. 請求項１から請求項１７のいずれかに記載の、または請求項２２から請求項２４もしくは請求項２８のいずれかに記載し請求項１８に従属しない各アクタ、あるいは、請求項２９から請求項４８のいずれかに記載のコンピューティング・デバイスによって管理され、当該アクタまたは当該コンピューティング・デバイスのサブジェクトシステムを構成する複数のリソースを有するコンピュータシステム。
  54. コンパイラは、前記アクタのモデルを、フォン・ノイマン・コンピュータ、またはコンピュータシステム、またはフォン・ノイマン・コンピュータもしくはコンピュータシステムのリソースを管理する、あるいはそれらにより単純なインタフェースを供給するオペレーティング・システムの、前記オブジェクトまたはコードに静的に変換する、フォン・ノイマン・コンピュータまたは階層化オペレーティング・システムのモデルを使用するように調整される、請求項１から請求項１７のいずれかに記載の、または請求項２２から請求項２４もしくは請求項２８のいずれかに記載し請求項１８に従属しないアクタ
  55. 前記コンパイラは、前記アクタのモデルを静的に変換するように調整されたメタ・トランスレータおよびハードウェア・メタ・モデルを含む請求項５４に記載のアクタ。
  56. 前記プロセッサは、請求項２９から請求項５０のいずれかに記載の論理型コンピューティング・デバイスを備える、請求項１７または請求項１７に従属する請求項のいずれかに記載のアクタ。
  57. フォン・ノイマン型コンピュータのモデル、または、フォン・ノイマン型コンピュータの資源を管理もしくはフォン・ノイマン型コンピュータにより単純なインタフェースを提供するオペレーティング・システムのモデルを使用し、
    アプリケーションモデルにおけるオブジェクトを表し、所定の時間に２つの以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、
    前記オブジェクトの状態の変化であるイベントに応じて開始されるアクションを定義するルールと、
    を備えるアプリケーションモデルを、サブジェクトシステムにおいて動作するように、フォン・ノイマン型コンピュータもしくはコンピュータシステム、または、フォン・ノイマン型コンピュータもしくはコンピュータシステムの資源を管理する、あるいは当該フォン・ノイマン型コンピュータもしくはコンピュータシステムにより単純なインタフェースを提供するオペレーティング・システム、のオブジェクトまたは機械またはアセンブラ・コードに静的に変換するコンパイラ。
  58. 請求項１から２４、２８、５２、５４、および５５のいずれかに記載のアクタの第１から第５のアクタで構成され、当該第１から第５のアクタは、それぞれ、
    オペレーションまたは変形プロセスを実行するように動作可能であるオペレーティングアクタ、
    システムの目的およびパフォーマンス目標を決定し、かつ当該目的およびパフォーマンス目標を他のアクタに提供するように動作可能であるディレクティングアクタ、
    前記ディレクティングアクタによって提供された目的およびパフォーマンス目標を達成するために、前記システム内の他のアクタの全てを制御するために動作可能である管理アクタ、
    他のアクタそれぞれの部分を形成する少なくとも１つのモデルを開発および保守するために動作可能である学習アクタ、
    第１〜第５のアクタの責務を達成するために動作可能であるサブ・アクタを提供するために動作可能である実現アクタ、であるシステム。
  59. 前記システムは装置であって、前記第１から第５のアクタは、請求項２９から請求項５０のいずれかに記載のコンピューティング・デバイスである請求項５８に記載のシステム。
  60. 前記システムは機構である請求項５８に記載のシステム。
  61. １つ以上の前記第１から第５のアクタは、それぞれ請求項５８に記載のシステムを備える請求項５８から請求項６０のいずれかに記載のシステム。
  62. 前記オペレーティングアクタは、
    オブジェクト、アクション、およびイベントについてのルールをモデル化し、目標システム、問題システム、および機会システムの１つ以上におけるアクタの役割の割り当ておよび精緻化をし、詳細なルールを試験して結果システムの動きを分析するために結果モデルをシミュレートすることによって、何を変化させる必要があるかを決定する前記目標システムにおける問題または機会を調査する調査サブ・システムと、
    前記調査サブ・システムが、調査システムでモデル化された目標システムおよび他のシステムにおけるオブジェクト、ルール、およびアクタのモデル化によって、ならびに、詳細なルールを試験して結果システムの動きを分析するために結果モデルをシミュレートすることによって、目標システムに対する変化をモデル化およびシミュレートするのを完了したことに応答する開発サブ・システムと、
    前記調査サブ・システムが、調査システムでモデル化された目標システムおよび他のシステムにおけるオブジェクト、ルール、およびアクタのモデル化によって、ならびに、詳細なルールを試験して結果システムの動きを分析するために結果モデルをシミュレートすることによって、変化を展開できる一時システムをモデル化およびシミュレートするのを完了したことに応答する準備サブ・システムと、
    前記開発サブ・システムおよび前記準備サブ・システムが、前記準備サブ・システムにおいてモデル化およびシミュレートされたシステムを実行し、ならびに前記開発サブ・システムにおいてモデル化およびシミュレートされた変化を配置するのを完了したことに応答する配置サブ・システムと、を備える変化システムを操作可能である請求項５８から請求項６１のいずれかに記載のシステム。
  63. サブジェクトシステムにアクションを生成する方法であって、
    前記サブジェクトシステムの内部オブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、
    前記オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、を含む前記サブジェクトシステムのモデルを維持し、
    前記モデルの前記ルールによって定義されるように、前記イベントに依存する前記サブジェクトシステムで、１つ以上のアクションを開始することによって、前記サブジェクトシステムにおいてイベントに応答するプロセッサを制御する方法。
  64. 全てのイベントおよびアクションは、オブジェクトとして構成される請求項６３に記載の方法。
  65. サブジェクトシステムにアクションを生成する方法であって、
    前記サブジェクトシステムの内部オブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、
    前記オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、を含む前記サブジェクトシステムのモデルを維持し、
    前記モデルの前記ルールによって定義されるように、前記イベントに依存する前記サブジェクトシステムで、１つ以上のアクションを開始することによって、前記サブジェクトシステムにおいてイベントに応答し、単一のステップで直接的に単一のイベントに応じて開始されたアクション、あるいは、実行により直接的または間接的に生じるイベントに応じて開始されるサブ・アクションとして定義される合成アクション、を実行するプロセッサを制御する方法。
  66. 全てのイベントおよびアクションは、オブジェクトとして構成される請求項６５に記載の方法。
  67. ２つ以上のサブ・モデルを含み、前記サブ・モデルのそれぞれは、前記サブジェクトシステムのサブ・システムのモデルである前記モデルを維持する請求項６３から請求項６６のいずれかに記載の方法。
  68. 前記モデル内のオブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、
    前記モデルにおけるオブジェクトの状態の変化であるイベントに応じてアクションが開始されることを定義するルールと、を含むメタ・モデルを維持し、
    前記メタ・モデルによって定義されるように、前記イベントに依存する前記モデルで、１つ以上のアクションを開始することによって、前記モデルにおいてイベントに応答するメタ・プロセッサを制御する請求項６３から請求項６７のいずれかに記載の方法。
  69. 前記モデルの部分としての前記メタ・モデルを維持する請求項６８に記載の方法。
  70. 前記プロセッサの部分としての前記メタ・プロセッサを制御する請求項６８または請求項６９に記載の方法。
  71. 前記モデルのサブ・システムのモデルである前記サブ・メタ・モデルを２つ以上含む前記メタ・モデルを維持する請求項６８から請求項７０のいずれかに記載の方法。
  72. 前記プロセッサのアクションを生じさせるために、ルート・メタ・モデルおよびルート・メタ・プロセッサを備えるルート・メタ・アクタを制御し、
    前記ルート・メタ・モデルは、前記モデルと同じタイプのモデルを処理するための一般モデルであって、一般モデル実行システム内のオブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、を維持し、
    前記ルート・メタ・プロセッサは、イベントがトリガされたときに、もしあるならば、どのアクションが開始されるべきかを決定し、当該アクションを開始するために、前記モデルにおける前記イベントの定義を検査する際と、アクションが開始されたときに、もしあるならば、どのオブジェクトが状態を変化されるべきかを決定し、それに応じて当該オブジェクトの状態を変えるために、前記モデルにおける前記アクションの定義を検査する際と、オブジェクトの状態が変化させられたときに、もしあるならば、どのイベントがトリガされるべきかを決定し、当該イベントをトリガするために、前記モデルにおける前記オブジェクトの定義を検査する際と、に前記ルート・メタ・モデルをガイドする請求項６３から請求項６７のいずれかに記載の方法。
  73. メタ・モデルを維持し、
    前記メタ・モデルは、前記モデル内のオブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、
    前記モデルにおけるオブジェクトの状態の変化であるイベントの結果として、前記モデルにおけるどのイベントが開始されるべきであるかを定義するルールと、を含む請求項７２に記載の方法。
  74. 前記メタ・モデルは、前記モデルの部分を形成する請求項７３に記載の方法。
  75. 前記ルート・メタ・モデルは、前記メタ・モデルの部分を形成する請求項７３に記載の方法。
  76. 前記モデルにおける前記イベントの定義を検査し、もしあるならば、開始すべきアクションがいずれであるかを決定し、その後当該アクションを開始するイベントのトリガに応じて動作可能な１つ以上のアクティベータと、
    前記アクションを生じるように調整されており、かつ、前記モデルのアクションの定義を検査し、もしあるならば、前記サブジェクトシステムにおいて状態を変化するオブジェクトがいずれであるかを決定し、その後それに応じて当該オブジェクトの状態を変化させるアクションの開始に応じて動作可能な１つ以上のエグゼキュータと、
    アクションの出力結果を記録するように調整されており、かつ、前記モデルにおける前記オブジェクトの定義を検査し、もしあるならば、前記サブジェクトシステムにおけるいずれのイベントが前記オブジェクトの状態の変化からの結果であるかを決定し、当該イベントをトリガするオブジェクトの状態の変化を認識することに応じて動作可能な１つ以上のレコーダと、
    前記アクタが他のアクタまたは外部世界に接続される外部チャネルへの１つ以上のインタフェースと、
    前記アクティベータ、前記エグゼキュータ、前記レコーダおよび前記インタフェースに接続される１つ以上の内部チャネルと、を備える前記プロセッサ、または１つ以上の多重プロセッサを維持する請求項６３から請求項７５のいずれかに記載の方法。
  77. 前記メタ・モデルにおける前記イベントの定義を検査し、開始するモデルのアクションがいずれであるかを決定し、その後当該アクションを開始するイベントのトリガに応じて動作可能な１つ以上のアクティベータと、
    前記アクションを生じさせるように調整され、かつ、前記メタ・モデルにおけるアクションの定義を検査し、もしあるならば、前記モデルにおいて状態を変化するオブジェクトがいずれであるかを決定し、その後それによって当該オブジェクトを変化させるアクションの開始に応じて動作可能な１つ以上のエグゼキュータと、
    前記メタ・モデル内のオブジェクトの生成、修正または削除を含み、アクションの出力結果を記録するように調整されており、かつ、前記メタ・モデルにおける前記オブジェクトの定義を検査し、もしあるならば、前記モデルにおけるいずれのイベントが前記オブジェクトの状態の変化からの結果であるかを決定し、当該イベントをトリガするオブジェクトの状態の変化に応じて動作可能な１つ以上のレコーダと、
    前記アクタが他のアクタまたは外部世界に接続される外部チャネルへの１つ以上のインタフェースと、
    前記アクティベータ、前記エグゼキュータ、前記レコーダおよび前記インタフェースに接続される１つ以上の内部チャネルと、を備える前記メタ・プロセッサ、または１つ以上の多重メタ・プロセッサを維持する請求項６８から請求項７１のいずれかに記載の方法。
  78. 前記ルート・メタ・モデルにおける前記イベントの定義を検査し、いずれのアクションを開始するかを決定するイベントのトリガに応じて動作可能な１つ以上のアクティベータと、
    前記アクションを生じるように調整されており、かつ、前記ルート・メタ・モデルにおける前記アクションの定義を検査し、もしあるならば、前記プロセッサにおいて状態を変化するオブジェクトがいずれであるかを決定し、その後それによって当該オブジェクトを変化させるアクションの開始に応じて動作可能な１つ以上のエグゼキュータと、
    前記ルート・メタ・モデル内のオブジェクトの生成、修正または削除を含み、アクションの出力結果を記録するように調整されており、かつ、前記ルート・メタ・モデルにおいて前記オブジェクトの定義を検査し、もしあるならば、前記プロセッサにおけるいずれのイベントがオブジェクトの状態の変化からの結果であるかを決定し、当該イベントをトリガするオブジェクトの状態の変化に応じて実施可能な１つ以上のレコーダと、
    前記アクタが他のアクタまたは外部世界に接続される外部チャネルへの１つ以上のインタフェースと、
    前記アクティベータ、前記エグゼキュータ、前記レコーダおよび前記インタフェースに接続される１つ以上の内部チャネルと、を備える前記ルート・メタ・プロセッサ、または１つ以上の数の多重ルート・メタ・プロセッサを維持する請求項７２から請求項７５のいずれかに記載の方法。
  79. 前記アクティベータ、前記エグゼキュータ、前記レコーダ、前記インタフェースまたは前記チャネルの１つ以上が、請求項６３から請求項７８のいずれかに記載の方法を行う請求項７６から請求項７８のいずれかに記載の方法。
  80. 仮想アクタのａ）プロセッサ、ｂ）メタ・プロセッサまたはｃ）ルート・メタ・プロセッサの１つで構成されるプロセッサ・エンティティを精緻化し、その結果、前記プロセッサ・エンティティは、第１のアクタのプロセッサ、メタ・プロセッサまたはルート・メタ・プロセッサのいずれかによって直接的に実行され得る前記モデルを制御する請求項６３から請求項７９のいずれかに記載の方法。
  81. 前記アクタは、代理サブジェクトシステムにおいてアクションを開始する前記アクタを制御し、かつ、
    シミュレーション、物理および壁時計時間の関係を処理し、
    第１のアクタの詳細なモデルで定義される内部および外部イベントの配分を処理し、
    シミュレートされたアクタの生成および削除、ならびにシミュレートされたモデル内における役割の割り当ておよび再割り当てを処理し、
    シミュレートされたアクタから物理アクタへの割り当ておよび精緻化を処理するルールを更に含むモデルを含むアクタを維持することによる、シミュレーションを実行する請求項８０に記載の方法。
  82. 更なる仮想アクタのプロセッサ・エンティティを精緻化する前記仮想アクタを調整する請求項８０または請求項８１に記載の方法。
  83. ２つ以上のサブ・モデルを含み、前記サブ・モデルのそれぞれは、１つ以上の他の仮想アクタのプロセッサ・エンティティの動作を精緻化する前記モデルを維持する請求項８０から請求項８２のいずれかに記載の方法。
  84. 前記モデル、前記メタ・モデルまたは前記ルート・メタ・モデルをグラフィカルに示す請求項６３から請求項８３のいずれかに記載の方法。
  85. 前記モデル、前記メタ・モデルまたは前記ルート・メタ・モデルを、コンピュータ可読な命令の集合として示す請求項６３から請求項８３のいずれかに記載の方法。
  86. 前記モデル、前記メタ・モデルまたは前記ルート・メタ・モデルを、集合論の数学的表記として示す請求項６３から請求項８３のいずれかに記載の方法。
  87. 共通サブジェクトシステムにおいて請求項６３から請求項８６のいずれかに記載の方法を実行するように調整された２つ以上の前記アクタ備え、各アクタを、それぞれ少なくとも１つの他のアクタに各自のチャネルを経由して接続するシステムを操作する方法。
  88. 前記接続をするステップは、前記アクタの部分を形成する第１のインタフェース、および前記チャネルの部分を形成する第２のインタフェースを維持する請求項８７に記載の方法。
  89. いくつかまたは全ての前記チャネルまたは前記インタフェースは、請求項６３から請求項８６のいずれかに記載の方法を実行するように調整される請求項８７または請求項８８に記載の方法。
  90. 請求項８７から請求項８９のいずれかに記載の方法を実行する請求項６３から請求項８６のいずれかに記載の方法。
  91. サブジェクトシステムにおいてアクションを生じさせる方法であって、
    前記サブジェクトシステムの内部オブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、前記オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、を含む前記サブジェクトシステムのモデルを実装する手段を、論理型コンピューティング・デバイスにおいて維持し、
    前記モデルの前記ルールによって定義されるように、前記イベントに依存する前記サブジェクトシステムで、１つ以上のアクションを開始することによって、前記サブジェクトシステムにおいてイベントに応答するプロセッサを実装する手段を、前記論理型コンピューティング・デバイスにおいて維持する方法。
  92. 単一のステップで直接的に単一のイベントに応じて開始されたアクションを、あるいは、実行により直接的または間接的に生じるイベントに応じてそれぞれが開始されるサブ・アクションとして定義される合成アクションとして実行する前記プロセッサを更に制御する請求項９１に記載の方法。
  93. 全てのイベントおよびアクションは、オブジェクトとして構成される請求項９１または請求項９２に記載の方法。
  94. １つ以上のアクティベータ、１つ以上のエグゼキュータ、１つ以上のレコーダ、１つ以上の内部チャネル、および１つ以上のインタフェースを備える前記プロセッサを維持する請求項９１から請求項９３に記載の方法。
  95. 多くのトリガされたイベントを含むことができるイベント待ち行列と、
    多くの開始されたアクションを含むことができるアクション待ち行列と、
    多くの参照または変更されるオブジェクトへの参照を含むことができるオブジェクト待ち行列と、を含む少なくとも１つの前記レコーダを維持する請求項９４に記載の方法。
  96. 前記イベント待ち行列を、トリガされた順に前記トリガされたイベントを含むように制御し、かつ／または前記アクション待ち行列を、開始された順に前記開始されたアクションを含むように制御し、かつ／または前記オブジェクト待ち行列を、発生順に前記参照を含むように制御する請求項９５に記載の方法。
  97. 前記オブジェクト待ち行列におけるアイテムへの参照を含むように動作可能なオブジェクト待ち行列レジスタと、
    現在のオブジェクトへの参照を含むように動作可能なオブジェクトレジスタと、
    現在のオブジェクトのタイプを含むように動作可能なオブジェクトタイプレジスタと、を備える少なくとも１つの前記レコーダを維持する請求項９５または請求項９６に記載の方法。
  98. 前記イベント待ち行列におけるアイテムへの参照を含むように動作可能なイベント待ち行列レジスタと、
    現在のイベントへの参照を含むように動作可能なイベントレジスタと、
    現在のイベントのタイプを含むように動作可能なイベントタイプレジスタと、を備える少なくとも１つの前記アクティベータを維持する請求項９５から請求項９７のいずれかに記載の方法。
  99. 少なくとも１つの前記エグゼキュータは、
    前記アクション待ち行列におけるアイテムへの参照を含むように動作可能なアクション待ち行列レジスタと、
    現在のアクションへの参照を含むように動作可能なアクションレジスタと、
    現在のアクションのタイプを含むように動作可能なアクションタイプレジスタと、を備える少なくとも１つの前記エグゼキュータを維持する請求項９５から請求項９８のいずれかに記載の方法。
  100. 単一の処理ユニットまたは集積回路に共に設けられている、単一のアクティベータ、単一のエグゼキュータ、単一のレコーダ、１つ以上の内部チャネル、および１つ以上のインタフェースを提供する請求項９１から請求項９９のいずれかに記載の方法。
  101. それぞれが各自の処理ユニットまたは集積回路に設けられた、単一のアクティベータ、単一のエグゼキュータ、単一のレコーダ、および１つ以上のインタフェースからなる複数のコンポーネントを提供し、当該コンポーネントを、１つ以上のチャネルを経由して互いに接続する請求項９１から請求項９９のいずれかに記載の方法。
  102. 複数の前記アクティベータを１つ以上のチャネルを経由して互いに接続し、少なくとも２つの前記アクティベータが共通イベント待ち行列を共有するように制御する請求項１０１に記載の方法。
  103. 複数の前記エグゼキュータを１つ以上のチャネルを経由して互いに接続し、少なくとも２つの前記エグゼキュータが共通アクション待ち行列を共有するように制御する請求項１０１または請求項１０２に記載の方法。
  104. 複数の前記レコーダを１つ以上のチャネルを経由して互いに接続し、少なくとも２つの前記レコーダが共通オブジェクト待ち行列を共有するように制御する請求項１０１から請求項１０３のいずれかに記載の方法。
  105. 請求項１００から請求項１０４のいずれかに記載の方法をそれぞれ実行する前記アクティベータまたは１つ以上の前記アクティベータを制御する請求項１０１から請求項１０４のいずれかに記載の方法。
  106. 請求項１００から請求項１０５のいずれかに記載の方法をそれぞれ実行する前記エグゼキュータまたは１つ以上の前記エグゼキュータを制御する請求項１０１から請求項１０５のいずれかに記載の方法。
  107. 請求項１００から請求項１０６のいずれかに記載の方法をそれぞれ実行する前記レコーダまたは１つ以上の前記レコーダを制御する請求項１０１から請求項１０６のいずれかに記載の方法。
  108. 全てのコンポーネントを、共通の筐体に配置する請求項１０１から請求項１０７のいずれかに記載の方法。
  109. ２つ以上のコンポーネントを、異なる配置に分散させる請求項１０１から請求項１０８のいずれかに記載の方法。
  110. 前記アクティベータ、前記エグゼキュータ、前記レコーダ、前記インタフェース、または前記チャネルがいずれも、請求項９１から請求項１０９のいずれかに記載の方法を実行するように制御する請求項９１から請求項１０９のいずれかに記載の方法。
  111. 複数の前記アクティベータが共通イベント待ち行列を共有するように制御する請求項１１０に記載の方法。
  112. 複数の前記エグゼキュータが共通アクション待ち行列を共有するように制御する請求項１１０または請求項１１１に記載の方法。
  113. コンパイラが、前記モデルを、フォン・ノイマン・コンピュータ、またはコンピュータシステム、またはフォン・ノイマン・コンピュータもしくはコンピュータシステムのリソースを管理する、あるいはそれらにより単純なインタフェースを供給するオペレーティング・システムの、前記オブジェクトまたはコードに静的に変換する、フォン・ノイマン・コンピュータまたは階層化オペレーティング・システムのモデルを使用するように制御する請求項６３から請求項７９、または請求項８４から請求項８６、もしくは請求項９０のいずれかに記載の方法。
  114. 前記コンパイラは、前記アクタのモデルを静的に変換するように調整されたメタ・トランスレータおよびハードウェア・メタ・モデルを含む請求項１１４に記載の方法。
  115. フォン・ノイマン型コンピュータのモデル、または、フォン・ノイマン型コンピュータの資源を管理もしくはフォン・ノイマン型コンピュータにより単純なインタフェースを提供するオペレーティング・システムのモデルを使用し、
    アプリケーションモデルにおけるオブジェクトを表し、所定の時間に２つの以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、
    前記オブジェクトの状態の変化であるイベントに応じて開始されるアクションを定義するルールと、
    を備えるアプリケーションモデルを、サブジェクトシステムにおいて動作するように、フォン・ノイマン型コンピュータもしくはコンピュータシステム、または、フォン・ノイマン型コンピュータもしくはコンピュータシステムの資源を管理する、あるいは当該フォン・ノイマン型コンピュータもしくはコンピュータシステムにより単純なインタフェースを提供するオペレーティング・システム、のオブジェクトまたは機械またはアセンブラ・コードに静的に変換するコンパイラを制御する方法。
  116. サブジェクトシステムをモデル化する方法であって、
    前記サブジェクトシステムの内部オブジェクトを表し、所定の時間に２つ以上の状態のいずれであるかを定義するデータに関連するオブジェクトと、
    前記オブジェクトの状態の変化であるイベントに応じて開始されるべきアクションを定義するルールと、
    実行により直接的または間接的に生じるイベントに応じてそれぞれが開始されるサブ・アクションとして、イベントに応じて開始された合成アクションを定義するルールと、を含む前記サブジェクトシステムのモデルを維持する方法。
  117. 請求項６３から８３のいずれかに記載の方法を実行するようにそれぞれ調整された第１から第５のアクタを提供し、それぞれ、
    オペレーションまたは変形プロセスを実行するように動作可能であるオペレーティングアクタ、
    システムの目的およびパフォーマンス目標を決定し、かつ当該目的およびパフォーマンス目標を他のアクタに提供するように動作可能であるディレクティングアクタ、
    前記ディレクティングアクタによって提供された目的およびパフォーマンス目標を達成するために、前記システム内の他のアクタの全てを制御するために動作可能である管理アクタ、
    他のアクタそれぞれの部分を形成する少なくとも１つのモデルを開発および保守するために動作可能である学習アクタ、
    第１〜第５のアクタの責務を達成するために動作可能であるサブ・アクタを提供するために動作可能である実現アクタ、である当該第１から第５のアクタを維持する、システムを操作する方法。
  118. 前記システムは装置であって、前記第１から第５のアクタは、装置のアクタである請求項１１８に記載の方法。
  119. 前記システムは機構である請求項１１８に記載の方法。
  120. 請求項１１８に記載の方法を実行することにより、１つ以上の前記第１から第５のアクタを維持する請求項１１８から請求項１２０のいずれかに記載の方法。
  121. オブジェクト、アクション、およびイベントについてのルールをモデル化し、目標システム、問題システム、および機会システムの１つ以上におけるアクタの役割の割り当ておよび精緻化をし、詳細なルールを試験して結果システムの動きを分析するために結果モデルをシミュレートすることによって、何を変化させる必要があるかを決定する前記目標システムにおける問題または機会を調査する調査サブ・システムを使用し、
    次に、前記調査サブ・システムが、調査システムでモデル化された目標システムおよび他のシステムにおけるオブジェクト、ルール、およびアクタのモデル化によって、ならびに、詳細なルールを試験して結果システムの動きを分析するために結果モデルをシミュレートすることによって、目標システムに対する変化をモデル化およびシミュレートするのを完了したことに応答する開発サブ・システムを使用し、
    前記調査サブ・システムが、調査システムでモデル化された目標システムおよび他のシステムにおけるオブジェクト、ルール、およびアクタのモデル化によって、ならびに、詳細なルールを試験して結果システムの動きを分析するために結果モデルをシミュレートすることによって、変化を展開できる一時システムをモデル化およびシミュレートするのを完了したことに応答する準備サブ・システムを使用し、
    次に、前記開発サブ・システムおよび前記準備サブ・システムが、前記準備サブ・システムにおいてモデル化およびシミュレートされたシステムを実行し、ならびに前記開発サブ・システムにおいてモデル化およびシミュレートされた変化を配置するのを完了したことに応答する配置サブ・システムを使用することにより、前記オペレーティングアクタが変化システムを操作するように制御する請求項１１８から請求項１２１のいずれかに記載の方法。
  122. システムを操作する方法であって、
    イベントがトリガされたときに、もしあるならば、どのアクションが開始されるべきかを決定し、当該アクションを開始するために、前記イベントの定義を検査し、
    アクションが開始されたときに、もしあるならば、どのオブジェクトが状態に関して変化されるべきかを決定し、それに応じて当該オブジェクトを変えるために、前記アクションの定義を検査し、
    オブジェクトの状態が変化させられたときに、変化した状態がいずれかのイベントをトリガすべきか否かを決定し、当該イベントをトリガするために、前記オブジェクトの状態変化の定義を検査する方法。
  123. イベント処理ステップを実行するアクティベータを制御する請求項１２３に記載の方法。
  124. アクション処理ステップを実行するエグゼキュータを制御する請求項１２３または請求項１２４に記載の方法。
  125. オブジェクト処理ステップを実行するレコーダを制御する請求項１２３から請求項１２５のいずれかに記載の方法。
  126. システムを操作する装置であって、
    前記イベントの定義を検査し、開始すべきアクションがいずれであるかを決定し、決定した当該アクションを開始するイベントのトリガに反応する１つ以上のアクティベータと、
    前記アクションの定義を検査し、状態にかんして変化されるべきオブジェクトがいずれであるかを決定し、当該決定に応じたオブジェクトの状態を変化させるアクションの開始に反応する１つ以上のエグゼキュータと、
    前記オブジェクトの状態変化の定義を検査し、いずれのイベントがトリガされるべきであるかを決定し、決定した当該イベントをトリガするオブジェクトの状態の変化に反応する１つ以上のレコーダと、を備える装置。
  127. 前記装置が１つ以上の外部のアクタまたは外部世界に接続される、外部チャネルへの１つ以上のインタフェースを備える請求項１２７に記載の装置。
  128. 前記アクティベータ、前記エグゼキュータ、前記レコーダおよびインタフェースのそれぞれが他のコンポーネントに接続される、１つ以上の内部チャネルを備える請求項１２７または請求項１２８に記載の装置。
JP2007536195A 2004-10-18 2005-10-17 サブジェクトシステムへの作用 Expired - Fee Related JP5128949B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GBGB0423110.6A GB0423110D0 (en) 2004-10-18 2004-10-18 Acting on a subject system
GB0423110.6 2004-10-18
PCT/EP2005/055310 WO2006042841A2 (en) 2004-10-18 2005-10-17 Acting on a subject system

Publications (2)

Publication Number Publication Date
JP2008517362A true JP2008517362A (ja) 2008-05-22
JP5128949B2 JP5128949B2 (ja) 2013-01-23

Family

ID=33462924

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007536195A Expired - Fee Related JP5128949B2 (ja) 2004-10-18 2005-10-17 サブジェクトシステムへの作用

Country Status (7)

Country Link
EP (1) EP1805704A2 (ja)
JP (1) JP5128949B2 (ja)
CN (1) CN101288090B (ja)
AU (1) AU2005296859B2 (ja)
CA (1) CA2583921C (ja)
GB (3) GB0423110D0 (ja)
WO (1) WO2006042841A2 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011517806A (ja) * 2008-03-08 2011-06-16 東京エレクトロン株式会社 自律的に適応する半導体製造
US8725667B2 (en) 2008-03-08 2014-05-13 Tokyo Electron Limited Method and system for detection of tool performance degradation and mismatch
US8744607B2 (en) 2008-03-08 2014-06-03 Tokyo Electron Limited Method and apparatus for self-learning and self-improving a semiconductor manufacturing tool
JP2015503257A (ja) * 2011-10-31 2015-01-29 フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン イベントを同期させるための装置および方法
US9275335B2 (en) 2008-03-08 2016-03-01 Tokyo Electron Limited Autonomous biologically based learning tool
KR20190001711A (ko) * 2017-06-28 2019-01-07 백옥기 인공지능의 신경가소성 및 자가적응 유연성을 구현하기 위하여 자가적응형 동적 다차원 배열을 관리하는 방법과 이를 이용한 컴퓨터 소프트웨어
WO2022208860A1 (ja) * 2021-04-02 2022-10-06 三菱電機株式会社 プログラム生成装置、および、プログラム生成方法

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8401992B2 (en) 2009-02-06 2013-03-19 IT Actual, Sdn. Bhd. Computing platform based on a hierarchy of nested data structures
CA2679786A1 (en) * 2009-09-16 2009-12-16 Ibm Canada Limited - Ibm Canada Limitee Conceptual representation of business processes for cross-domain mapping
CN109460214B (zh) * 2018-11-06 2021-07-27 上海航天测控通信研究所 基于idef建模的航天器软件结构化方法
CN110164082B (zh) * 2019-06-21 2021-01-15 山东大学 家庭安防报警系统的静态控制器设计方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02109127A (ja) * 1988-10-19 1990-04-20 Hitachi Ltd 仕様処理方法
JPH10320005A (ja) * 1997-05-20 1998-12-04 Mitsubishi Electric Corp 分散制御システムの構成管理方法およびこれに用いるデータ
JPH113108A (ja) * 1997-06-13 1999-01-06 Sony Corp 加工制御方法及び加工制御装置

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IE873207L (en) * 1987-11-26 1989-05-26 Schering Ag An energy management system
US5596331A (en) * 1988-05-13 1997-01-21 Lockheed Martin Corporation Real-time control sequencer with state matrix logic
US5638539A (en) * 1994-02-28 1997-06-10 International Business Machines Corporation Tool for defining complex systems
US5887143A (en) * 1995-10-26 1999-03-23 Hitachi, Ltd. Apparatus and method for synchronizing execution of programs in a distributed real-time computing system
AU1724899A (en) * 1997-12-12 1999-06-28 Cacheon, L.L.C. Naturally parallel computing system and method
JP3863069B2 (ja) * 2002-06-06 2006-12-27 本田技研工業株式会社 プラントの制御装置
JP2004164328A (ja) * 2002-11-13 2004-06-10 Fujitsu Ltd 一人ｃａｍシステムおよび一人ｃａｍプログラム
US7006900B2 (en) * 2002-11-14 2006-02-28 Asm International N.V. Hybrid cascade model-based predictive control system
WO2004046835A2 (en) * 2002-11-15 2004-06-03 Applied Materials, Inc. Method, system and medium for controlling manufacture process having multivariate input parameters
JP3940665B2 (ja) * 2002-11-27 2007-07-04 株式会社東芝 ハイブリッドシミュレーション装置およびプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02109127A (ja) * 1988-10-19 1990-04-20 Hitachi Ltd 仕様処理方法
JPH10320005A (ja) * 1997-05-20 1998-12-04 Mitsubishi Electric Corp 分散制御システムの構成管理方法およびこれに用いるデータ
JPH113108A (ja) * 1997-06-13 1999-01-06 Sony Corp 加工制御方法及び加工制御装置

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
CSND199700218001; 青山幹雄（外２名）: '「高水準ペトリネットによるソフトウェア開発方法論」' コンピュータソフトウェア １９９４年７月号（第１１巻，第４号）, 19940715, 第３〜１９頁, 日本ソフトウェア科学会 *
CSND199800719007; 奥村幸年: '「オブジェクト指向分析技法　シュレイアー＆メラー法によるソフトウェア開発（前編）」' インターフェース １９９５年８月号（第２１巻，第８号）, 19950801, 第１４５〜１５４頁, ＣＱ出版株式会社 *
CSND200401433006; 浅海智晴: '「Ｊａｖａデザイン・ノート　第４１回　要求分析（その３）-ユースケース記述のチューニング」' 月刊ジャバワールド（Ｊａｖａ　ＷＯＲＬＤ） ２００４年３月号（第８巻，第３号）, 20040301, 第９４〜１０３頁, 株式会社アイ・ディ・ジー・ジャパン *
JPN6012053234; 原田実監修: 「ＣＡＳＥのすべて」 第１版, 19911125, 第１３５〜１４６頁, 株式会社オーム社 *
JPN6012053235; 浅海智晴: '「Ｊａｖａデザイン・ノート　第４１回　要求分析（その３）-ユースケース記述のチューニング」' 月刊ジャバワールド（Ｊａｖａ　ＷＯＲＬＤ） ２００４年３月号（第８巻，第３号）, 20040301, 第９４〜１０３頁, 株式会社アイ・ディ・ジー・ジャパン *
JPN6012053236; 奥村幸年: '「オブジェクト指向分析技法　シュレイアー＆メラー法によるソフトウェア開発（前編）」' インターフェース １９９５年８月号（第２１巻，第８号）, 19950801, 第１４５〜１５４頁, ＣＱ出版株式会社 *
JPN6012053237; 青山幹雄（外２名）: '「高水準ペトリネットによるソフトウェア開発方法論」' コンピュータソフトウェア １９９４年７月号（第１１巻，第４号）, 19940715, 第３〜１９頁, 日本ソフトウェア科学会 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011517806A (ja) * 2008-03-08 2011-06-16 東京エレクトロン株式会社 自律的に適応する半導体製造
US8725667B2 (en) 2008-03-08 2014-05-13 Tokyo Electron Limited Method and system for detection of tool performance degradation and mismatch
US8744607B2 (en) 2008-03-08 2014-06-03 Tokyo Electron Limited Method and apparatus for self-learning and self-improving a semiconductor manufacturing tool
US9275335B2 (en) 2008-03-08 2016-03-01 Tokyo Electron Limited Autonomous biologically based learning tool
US9424528B2 (en) 2008-03-08 2016-08-23 Tokyo Electron Limited Method and apparatus for self-learning and self-improving a semiconductor manufacturing tool
JP2015503257A (ja) * 2011-10-31 2015-01-29 フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン イベントを同期させるための装置および方法
US9641601B2 (en) 2011-10-31 2017-05-02 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus and method for synchronizing events
KR20190001711A (ko) * 2017-06-28 2019-01-07 백옥기 인공지능의 신경가소성 및 자가적응 유연성을 구현하기 위하여 자가적응형 동적 다차원 배열을 관리하는 방법과 이를 이용한 컴퓨터 소프트웨어
KR102011094B1 (ko) 2017-06-28 2019-08-14 백옥기 인공지능의 신경가소성 및 자가적응 유연성을 구현하기 위하여 자가적응형 동적 다차원 배열을 관리하는 방법과 이를 이용한 컴퓨터 소프트웨어
WO2022208860A1 (ja) * 2021-04-02 2022-10-06 三菱電機株式会社 プログラム生成装置、および、プログラム生成方法

Also Published As

Publication number Publication date
CN101288090A (zh) 2008-10-15
CN101288090B (zh) 2013-09-04
AU2005296859B2 (en) 2011-03-10
WO2006042841A2 (en) 2006-04-27
GB2428322A (en) 2007-01-24
CA2583921C (en) 2017-01-24
EP1805704A2 (en) 2007-07-11
GB0423110D0 (en) 2004-11-17
AU2005296859A1 (en) 2006-04-27
CA2583921A1 (en) 2006-04-27
JP5128949B2 (ja) 2013-01-23
WO2006042841A8 (en) 2008-01-17
GB2428322A9 (en) 2007-02-12
GB2425868A (en) 2006-11-08
GB0613704D0 (en) 2006-08-23
GB2425868B (en) 2007-07-04
GB0618546D0 (en) 2006-11-01

Similar Documents

Publication Publication Date Title
US7822592B2 (en) Acting on a subject system
JP5128949B2 (ja) サブジェクトシステムへの作用
Naujokat et al. CINCO: a simplicity-driven approach to full generation of domain-specific graphical modeling tools
Debbabi et al. Verification and validation in systems engineering: assessing UML/SysML design models
US7809597B2 (en) Progressive refinement model for business processes
US20070226038A1 (en) Modeling of business process data
US20090106011A1 (en) System and method for developing and deploying sensor and actuator applications over distributed computing infrastructure
US20110145704A1 (en) Providing multiple views of a business process definition to different views
Chella et al. Agile passi: An agile process for designing agents
DeLoach et al. The o-mase methodology
O’Donovan et al. Design planning and modelling
DeLoach et al. Using three AOSE toolkits to develop a sample design
Wall Architectural modeling and analysis of complex real-time systems
Degano et al. A two-component language for adaptation: design, semantics and program analysis
Broy et al. Towards a unified view of modeling and programming (ISoLA 2018 track introduction)
Nagrath et al. Run-time dependency graph models for independently developed robotic software components
Szemethy et al. Model transformations in the model-based development of real-time systems
Wand et al. Computing tomorrow: future research directions in computer science
Yannopoulos et al. Metadata, Domain Specific Languages and Visualisations as Internal Artifacts Driving an Agile Knowledge Engineering Methodology
Toro Towards non-threaded Concurrent Constraint Programming for implementing multimedia interaction systems
Adam Systematic inference of the context of utilization of the design knowledge by using a reference model
Fong An Operational Approach to Object-oriented Software
Wilhelm Informatics 10 Years Back, 10 Years Ahead (Dagstuhl Seminar 00352)
Arumí Albó Real-time multimedia on off-the-shelf operating systems: from timeliness dataflow models to pattern languages
Jokes Integration Focus: Rose and the Rationa l Unified Process

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080818

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110802

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20111011

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20111018

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20111124

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20111201

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111226

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20120417

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120816

A911 Transfer of reconsideration by examiner before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20120823

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20121016

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20121101

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151109

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees