JP2006504156A - リアルタイム・システム制御のためのコンポーネント・モデル - Google Patents

Abstract

コンポーネント・ベースのソフトウェア・プログラムであり、それぞれのコンポーネントは、コンポーネント・タイプに基づいている。コンポーネント・タイプは、スロット定義を含むベース・クラスから作成される。スロット定義は、識別され、コンポーネント・タイプ・オブジェクトに記憶される。そのコンポーネント・タイプの１又は複数のコンポーネントが作成され、それぞれは、コンポーネント・タイプ・オブジェクトへの参照と、プロパティ・スロット定義と関連付けされた値のための記憶位置をそのコンポーネント・タイプ・オブジェクトの中に有するスロットマップとを含む。プロパティ・スロットのための値は、記憶位置に配置されることによりコンポーネントの中に入力される。また、一意的な名称をコンポーネントに自動的に指定する方法も開示されている。１つのルート・コンポーネントが作成される。更なる非ルート・コンポーネントが、ルート・コンポーネント又はそれ以外のコンポーネントの中に配置され、それによって、すべてのコンポーネントがツリー構造を形成する。コンポーネントには、当該コンポーネントのすべての祖先と当該コンポーネントの名称とのシーケンシャルなリストを含む一意的な識別ストリングが割り当てられる。

Description

関連出願

この特許出願では、「Component Model for Real-Time System Control」と題する、２００２年２月１５日に出願された米国特許出願第６０／３５７，３２９号に基づく３５ＵＳＣ１１９（ｅ）による優先権を主張する。この米国特許出願は、その全体をこの出願において援用する。

技術分野及び背景技術

多くの異なる業務において、固有の問題を解決するためにカスタム・ソフトウェアが必要とされている。典型的には、これらの問題は、例えば、建築自動化の専門家や、工場自動化の専門家、交通制御の専門家など、各分野の専門家には十分に理解されている。しかし、各分野の専門家にオブジェクト指向プログラミングなどの一般的なプログラミング技術を用いる技術を要求するのは、困難である。今日では、各分野の専門家は、希望するシステムを構築するプログラマへの要求を特定することを試みなければならない。このプロセスは、誤りを生じやすく、時間がかかり、誤解が生まれやすい。必要であるのは、問題空間を理解している各分野の専門家がソフトウェア・システムを自分自身で構築することができる能力である。しかし、各分野の専門家が職業的なプログラマになるための時間や意欲を有するようになることを期待するのは無理である。従って、素人によるカスタム・ソフトウェアの作成を可能にするようなツールを提供することが必要である。理想的には、このようなツールは、ソフトウェア・システムのコンフィギュレーション・パラメータ、実行ロジック及びデータがグラフィカルに視覚化されることを可能にするものであるのが望ましい。また、グラフィカルなツールは、各分野の専門家が、むつかしいプログラミング言語のシンタクスを理解することを必要とすることなく、ソフトウェア・システムを作成し、モニタし、変更することを可能にするであろう。

コンポーネント指向システムは、現実世界の必要性に対処するアプリケーションを構築するように接続することができるコンポーネントにソフトウェア関数をカプセル化することによって、これらの特徴のいくつかを提供する新たな概念の一部である。しかし、既知の従来のアプローチは、現実的なシステムを実装するために、プログラミング言語の知識を依然として必要とする。ソフトウェア・コンポーネントは、現時点においては、依然として、コンポーネントを相互に接続して機能的なシステムを作成するのに、プログラミングのスキルを必要としている。更に、既存のコンポーネント技術では、各分野の専門家が、システムの全体をグラフィカルに視覚化し、ランタイムにおいて変更を加えることが可能ではない。例えば、各分野の専門家は、実行フローを変更する、又は、新たな振る舞いをランタイムにおいて追加することを希望し、どのような影響がソフトウェア・システムに生じるのかを直ちに見ることを希望する場合があろう。このような探索的なプログラミングのアプローチは、ソフトウェアを停止させ、リコンパイルし、再スタートすることを要求する現状のソリューションとは整合的でない。パフォーマンスを改善し特徴を追加するなどのためには、ソフトウェアの更なる追加、修正又は更新が必要となる。現在のソリューションは、この場合にも、そのような更新、追加又は修正を行うためにも、ソフトウェアが停止し、リコンパイルし、再スタートされることが要求される。ソフトウェアの停止は、重要なプロセスが制御されているような環境においては、特に困難である。そのようなソリューションを提供する際の別の特別の難問として、各分野の専門家がソフトウェア・コンポーネントを強化又は拡張してそれらを特定の分野の応用例のユニークな必要性に適応させる必要がある。歴史的に、このような追加又は拡張は、一般的なプログラミング・スキル及び知識を必要としてきた。本発明は、以上のような問題及びそれ以外の必要性に対応しようとするものである。

本発明の１つの特徴は、そのコードが、マシン上で実行される同一のコンポーネント・タイプの１又は複数のコンポーネントを含むソフトウェア・プログラムである。そのソフトウェア・プログラムのコンポーネントは、特定の方法によって生成される。その方法では、ベース・クラスは、フレームワークに提供されるが、このベース・クラスは、その少なくとも１つがプロパティ・スロット定義である１又は複数のスロット定義を含む。ベース・クラスの中のすべてのプロパティ・スロット定義が、識別される。これらのプロパティ・スロット定義のそれぞれに対して、ゲッタ及びセッタ・メソッドが配置される。スロット定義を記憶するように構成されたコンポーネント・タイプ・オブジェクトが、生成される。識別されたプロパティ・スロット定義は、次に、そのコンポーネント・タイプ・オブジェクトに記憶される。１又は複数のコンポーネントが生成される。これらのコンポーネントは、それぞれが、スロットマップ・オブジェクトを有し、これは、スロットマップ・クラスからインスタンス化される。それぞれのスロットマップ・オブジェクトは、また、コンポーネント・タイプ・オブジェクトに記憶されているそれぞれのプロパティ・スロット定義に対する値を含む。それぞれの値には、単一のコンポーネントが関連付けられており、よって、それぞれのコンポーネントに一意的なデータを記憶する能力が提供される。

この特徴の更なる発展形では、コンポーネントは、そのプロパティ及びデータ・フィールドの動的スロットを介しての拡張が可能であるように設計される。
別の特徴では、コンポーネント・ベースのソフトウェア・システムの拡張に名称を自動的に指定する方法が提供される。その方法では、ルート・コンポーネントが作成される。ルート・コンポーネントは、親を有していない。１又は複数の非ルート・コンポーネントは、ルート・コンポーネントの中に配置され、１又は複数の他の非ルート・コンポーネントは、非ルート・コンポーネントの中に配置され、それによって、すべての非ルート・コンポーネントは親を有し、全体の構造がツリーを形成する。この時点で、１つのコンポーネントには、そのコンポーネントのすべての祖先とそのコンポーネントの名称とのシーケンシャルなリストを含む一意的な識別ストリングが割り当てられる。

この特徴の更なる発展形では、命名法は、コンポーネントの個別のスロットを識別するように拡張される。
本発明の以上の及びそれ以外の特徴及び効果は、添付の図面と好適実施例に関する以下の説明とからさらに理解されるはずである。

本発明のコンポーネント・モデルは、アプリケーション開発者が非プログラマに適したグラフィカルな環境でソフトウェア・コンポーネントを拡張し修正することを可能にするソフトウェア・コンポーネントのためのユニークなコンポーネント・デザインを提供する。このコンポーネント・モデル・デザインは、通常は必要となるソフトウェアのコーディング・ステップなしに、プロパティ、アクション又はトピックスなどの新たなスロットが標準的なコンポーネントに追加されることを可能にする。

ソフトウェア開発へのコンポーネント・モデル・アプローチは、オブジェクト指向のソフトウェア・デザインの利点を使用しながらエンド・ユース・アプリケーションへの直接的な関係を有するソフトウェア・コンポーネントが作成されることを可能にする。そのように、コンポーネントは、純粋なオブジェクト指向アプローチの場合に存在しているよりも、より高い抽象レベルを提供する。オブジェクトが（ストリングを処理する、バッファ管理を提供するなどの）ソフトウェア関数に適用可能な振る舞いをカプセル化する場合には、コンポーネントは、オブジェクトをアセンブルして、アプリケーションの最終目的（スケジュールを変更する、アラームを検討して確認応答コマンドをアラームを発しているデバイスに戻す、など）の必要性を満たすようにすることができる。

２つのレベルの抽象化が存在する。一方は、コンポーネントの実装を扱うオブジェクト指向レベルであり、他方は、オブジェクト指向レベルを隠して、コンポーネントの使用を通じて特定の現実世界のアプリケーションに関係するアプリケーションの作成を扱うコンポーネント・レベルである。本発明のソフトウェアを動作させ修正する可能性がある人間には少なくとも２種類存在する。開発者とユーザとである。開発者は、オブジェクト指向のコンセプトを用いて本発明によるコンポーネント・モデルを実装する。オプションでは、開発者は、また、コンポーネント・レベルで定義されている機能を作成する。ユーザは、一般に、オブジェクト指向の実装を見ることはない。むしろ、ユーザは、ほとんどコンポーネントだけを扱い、コンポーネント・レベルでシステムをモニタし作成し修正する。もちろん、ユーザと開発者とが同一の人間であることもありうる。

ソフトウェア・プログラムの中のコンポーネントは、コンポーネント・タイプに基づいて作成される。コンポーネント・タイプは、オブジェクト指向プログラミングにおけるクラスの概念に類似しており、すなわち、そのタイプに属するコンポーネント・インスタンスのすべての共通する特徴を記述する抽象化である。好適実施例では、コンポーネント・タイプやコンポーネントに関係するほとんどの他の関数の作成は、フレームワークによってなされるが、これを、われわれはナイアガラ・フレームワーク（Niagara^TM Framework）と称することがある。フレームワークは、コンポーネント・ベースのソフトウェアの中のソフトウェア・モジュールであり、コンポーネント・タイプやコンポーネントの作成などコンポーネント・モデルの実装に関係する複数のユーティリティ関数を満たし、コンポーネントと外部のソフトウェア・モジュールとの間のインターフェースを提供し、スロットを追加することによりコンポーネントを拡張する能力を提供する、などである。フレームワークは、また、初期（ブートストラップ）フェーズの間とコンポーネント・ランタイム実行の間とを含むソフトウェアの実行フローを提供する。

オブジェクト指向プログラムはクラスから構成されるが、クラスは、当該クラスに属するインスタンスを配分するのに用いられるテンプレートを定義する。それぞれのクラスは、メンバと称される下位部分から構成される。メンバは、データを記憶するのに用いられるフィールドであったり、実行可能な振る舞い（behavior）を記憶するのに用いられるメソッドであったりする。

本発明は、オブジェクト指向プリミティブを用いて構築されたコンポーネント・モデルを記述する。コンポーネント・モデルは、次に、非プログラマがコンポーネント指向プログラムを構築するのに用いられ得る。コンポーネント・モデルはコンポーネント・タイプによって構成されており、コンポーネント・タイプは、当該タイプに属するインスタンスを配分するのに用いられるテンプレートを定義する（オブジェクト指向クラスのように）。それぞれのコンポーネント・タイプは、スロットと称される下位部分から構成される（オブジェクト指向メンバのように）。スロットとメンバとの違いは、スロットはより高レベルの抽象化において存在するため、非プログラマやコンポーネント指向プログラムのエンド・ユーザによって直接に用いられ得るという点である。

コンポーネント・モデルには、３つのタイプのスロットが存在する。プロパティは、データ値を記憶するスロットである。プロパティは、コンフィギュレーション・データを記憶し、リアルタイムの状態情報を提供し、又は、それ以外の任意のデータを記憶するのに用いられ得る。アクションは、メソッドと類似しており、実行振る舞いを記憶するスロットである。例えば、エンド・ユーザが呼び出すアクションは、「ファンをオンせよ」（Turn On Fan）でありうる。アクションは、また、純粋にソフトウェア機能を実装することもできる。トピックスが、第３のスロット・タイプである。トピックスは、イベントを表現するのに用いられる。トピックスは、ファイアして、イベントが発生したことを示す。

リンクは、特定の種類のプロパティ・スロットである。リンクは、コンポーネント・ベースのソフトウェアにおいて、実行フローを指定するのに用いられる。より詳しくは、リンクは、２つの異なるスロットの間の因果的関係を作成するのに用いられる。そのような関係は、例えば、ある関数が他のある関数の呼び出しに応答して呼び出されることを意味する。オブジェクト・モデルでは、これらの関係は、静的コードによって定義されるのが通常であり（例えば、条件的プロシージャ・コールなど）、リコンパイルなしで変更されることはできない。コンポーネント・モデルでは、リンクは、多くの場合、動的スロットであるから、ランタイムの間に取り除くことができ、ソフトウェアがリコンパイルされることを必要とせずに、ソフトウェアの実行フローを変更する。

コンポーネント・モデルは、オブジェクト指向プログラムとして構築されるので、オブジェクト指向メンバを用いてコンポーネント・モデルを実装することが必要である。クラス、メンバ、フィールド及びメソッドの用語は、一般的なオブジェクト指向の概念を意味するものとする。コンポーネント・タイプ、スロット、プロパティ、アクション及びトピックの用語は、本発明に関係しているので、コンポーネント指向の概念を意味する。

オブジェクトとコンポーネントとの間の大きな違いの１つとして、コンポーネントはランタイムの間に変更しうる点がある。例えば、新たなメソッドをオブジェクトに追加するには、そのオブジェクトのクラスをリコンパイルすることが要求されるのが一般的である。コンポーネント・モデルによると、コンポーネントにおいてスロットを定義して新たなスロットをランタイムで追加することが可能である。コンパイルされたコードにおいて定義されたスロットは、冷凍されている。冷凍されたスロットは不変であるが、コンパイルされたコードの処理効率を取得する。ランタイムで定義されたスロットは、動的である。

オブジェクト指向プログラミングでは、クラス定義の実行中のプログラムにおける記憶は、コンパイラによって処理され、開発者にはほとんど可視的でない。その理由で、オブジェクト指向プログラミングでは、クラスは、アブストラクトとして参照され、実際のデータ構造としては参照されない。従って、ほとんどのオブジェクト指向環境での開発者は、クラス定義はコンピュータ・メモリのどこかに物理的に存在している必要があるという事実に混乱させられることなく、クラスを実際のオブジェクトの抽象的定義として安全に参照することができる。

本発明のコンポーネント・モデルでは、コンポーネント・タイプは、コンピュータ・メモリに記憶されそこで処理されなければならない。コンポーネント・タイプの記憶は、好ましくは、フレームワークによって、コンポーネント・タイプをオブジェクトに記憶することによって、すなわち、コンポーネント・タイプ・オブジェクトによってなされる。従って、コンポーネント・タイプ・オブジェクトは、コンポーネント・タイプの物理表現である。コンポーネントからコンポーネント・タイプ・オブジェクトへの参照は、与えられたコンポーネントがあるコンポーネント・タイプに属するという事実を表現するのに用いられる。

図１は、コンポーネント・タイプが、あるコンポーネント・タイプ・オブジェクトを作成することによってどのように作成されるか、そして、そのコンポーネント・タイプに基づく複数のコンポーネント・インスタンスがどのように生成されるか、を図解する流れ図である。

新たなコンポーネント・タイプを作成するためには、開発者は、フレームワークにクラス定義、すなわち、ベース・クラスを提供することが必要である（ステップ１００）。好適実施例では、開発者は、それをコンポーネント・ベースのソフトウェアに追加することによって、ベース・クラスを提供する。ベース・クラスのメンバをそのコンポーネント・モデルにおける異なるタイプのスロットにマップする所定の組の規則が存在する。これらの規則は、例えば、ベース・クラスのメンバのタイプ又は名称に基づいている。開発者は、あるコンポーネント・タイプがどのような冷凍されたスロットを有しているべきかを、規則の組に従ってこれらの冷凍されたスロットに対応するベース・クラス定義にメンバを追加することによって、指示する。好適実施例では、開発者は、また、ベース・クラスをフレームワークに一致させるステートメントを追加する。コンポーネント・ベースのソフトウェアは、ベース・クラスの追加の後で、コンパイルされ、実行される。いったんソフトウェアが動作していると、初期化プロシージャの一部として、フレームワークはベース・クラスを検出し、１又は複数のコンポーネント・タイプとそれらに基づく１又は複数のコンポーネントとを作成するために、図１の残りのプロセスを行う。

フレームワークは、ステップ１０１で、ベース・クラスを検査し、関係するメンバをすべて発見する。このステップは、ベース・クラスの内部監視によって達成することができる。

すべてのタイプのスロット（プロパティ、アクション、トピック）は、定義を含む。プロパティ・スロットは、そのプロパティ・スロットが保持するデータのタイプとプロパティ・スロットの名称とを特定する。アクション・スロットの定義は、アクション・スロットの名称と、そのアクションを実行するメソッドを実装するコードとを含む。同様に、トピック・スロット定義は、トピックの名称と、そのトピックを実装するコードとを含む。プロパティ・スロットは同様に値を含み、アクション及びトピック・スロットは値を含まない（しかし、それらを実装するメソッドはコンポーネント・レベルで隠されている任意の数の変数を有する場合がある）。プロパティ・スロットは、値を取得し設定するゲッタ及びセッタ・メソッドを必要とする。これらのゲッタ（getter）及びセッタ（setter）メソッドは、プロパティ・スロット定義の一部であり、ベース・クラスにおいて最初に定義される。

ステップ１０２では、ある１つのプロパティ・スロットに対応するベース・クラスのそれぞれのメンバが、ゲッタ及びセッタ・メソッドのために検査される。慣例により、ゲッタ及びセッタ・メソッドは、これらの関数をそれぞれ実装する標準的なコードと共に、「ゲット（get）」及び「セット（set）」をプロパティ・スロットの名称の前に付することによって命名される。

そして、フレームワークは、コンポーネント・タイプ・オブジェクトを作成する（ステップ１０３）。コンポーネント・タイプ・オブジェクトの目的は、コンポーネント・タイプを指示することである。コンポーネント・タイプ・オブジェクトは、１又は複数のスロット定義を記憶し検索することができるデータ構造を含む。そのようなデータ構造は、例えば、アレイ又はハッシュテーブルでありうる。コンポーネント・タイプ・オブジェクトは、また、コンポーネント・タイプの名称である名称を含む。この名称は、ベース・クラスの名称からコピーされるか、又は、ベース・クラスにおいて特定のフィールドを用いるなどにより別の方法で開発者により識別されるか、のいずれかである。

ステップ１０４では、ベース・クラスのすべてのスロット定義が、コンポーネント・タイプ・オブジェクトに記憶される。これらは、冷凍されたスロット定義と称される。ステップ１０５では、フレームワークは、ステップ１０３で作成されたコンポーネント・タイプ・オブジェクトと関連付けされたスロットマップ・クラスを生成する。このスロットマップ・クラスは、コンポーネント・タイプ・オブジェクトのそれぞれのプロパティ・スロットに対応するメンバを定義する。スロットマップ・クラスは、また、追加的な動的スロットを作成するメソッドを含む。

ここまでのプロセスが、ステップ１０７において、すべての既存のベース・クラスについて反復される。
１又は複数の反復の後で、必要な数のコンポーネント・タイプ・オブジェクトが、ステップ１０６で作成される。それぞれのコンポーネント・タイプ・オブジェクトに対して、対応するスロットマップ・クラスがあり、そのインスタンスは、追加可能な任意の動的スロットだけでなく冷凍されたプロパティ・スロットに対する一意的な値を記憶することができる。

従って、１又は複数のコンポーネント・タイプが作成されるが、このソフトウェアには、依然として、コンポーネント・ベースの機能が欠けている。というのは、これらのコンポーネント・タイプのインスタンスがまったく存在していないからである。ステップ１０６では、１又は複数のコンポーネントが、既存のコンポーネント・タイプ・オブジェクトから生成される。フレームワークは、コンポーネント・レベルの機能を提供するために、コンポーネント・インスタンスを作成する。コンポーネント・インスタンスは、例えば、データ・ファイル又はユーザ入力に基づいて作成される。例えば、データ・ファイルは、開発者又はユーザによって既に指定されているコンポーネント・システムと、コンポーネント・インスタンスと、その組成と、そのコンフィギュレーション・プロパティと、リンクを介して指示されるシステムの中の実行フローとを有効に含むことができる。更に、ユーザは、コンポーネントのインスタンスを作成しフロントエンド・ブラウザなどを介するそれらの間のリンクを作成することによって、グラフィカル・インターフェースをもちいて、そのようなシステムを最初から作成することができる。

好適実施例では、フレームワークは、コンポーネントを作成する最終的な責任を有している。あるコンポーネント・タイプのコンポーネントが作成される必要があるときには、フレームワークは、既存のコンポーネント・ジェネリックなクラスからコンポーネント・インスタンスを作成する。ジェネリックなクラスは、他のコンポーネントとの通信に（そして、コンポーネントの管理に）用いられる１又は複数のユーティリティ・メンバと、スロットマップ又はスロットマップへの参照を挿入するのに適したフィールドとを含む。フレームワークは、作成されるコンポーネントのコンポーネント・タイプと関連付けされたコンポーネント・タイプ・オブジェクトと、そのコンポーネント・タイプと関連付けされたスロットマップ・クラスとを識別する。そして、次に、スロットマップ・クラスからスロットマップ・インスタンスを作成する。フレームワークは、スロットマップ・インスタンスをコンポーネント・インスタンスに付属させ、それによって、スロットマップは、コンポーネントに効果的に含まれる。次に、コンポーネント・インスタンスからコンポーネント・タイプ・オブジェクトへの参照を作成する。この参照（reference）は、通常はポインタであり、インスタンス・タイプの関係を指定する。すなわち、その特定のコンポーネント・インスタンスがコンポーネント・タイプ・オブジェクトによって記述されるコンポーネント・タイプに属するように指定する。

コンポーネント・タイプ・オブジェクトがプロパティ・スロットの定義を含む場合には、フレームワークは、オプションで、それらに対する値を割り当てる。これらの値は、例えば、データ・ファイルから、又は、ユーザ入力から取得できる。フレームワークは、あるプロパティ・スロットに割り当てられる値を有しているときには、その値をスロットマップ・オブジェクトの中の適切なフィールドに設定することによって、それを達成する。これは、プロパティ・スロットの定義におけるセッタ・メソッドにアクセスすることによって、又は、そのコンポーネント若しくはスロットマップに対するセッタ・メソッドにアクセスすることによって、又は、スロット値に直接にアクセスすることによって、達成することができる。スロット値が提供されない場合には、フレームワークは、デフォルトの値を割り当てるか、何もしないかのいずれかである。

別の実施例では、スロットマップ・クラスは、それぞれのコンポーネント・タイプ・オブジェクトに対して作成されず、その代わりに、それぞれのコンポーネントがジェネリックなスロットマップを含み、すなわち、コンポーネント・オブジェクトにおいて定義されたプロパティ・スロットのプロパティ・スロット値に対する記憶位置を提供するデータ構造を含み、更に、動的フィールド定義及び値を記憶することができる。この目的に役立つデータ構造は、この技術において公知であり、アレイやハッシュテーブルなどである。

フレームワークは、名称をそれぞれのコンポーネントに割り当てるが、その名称は、フレームワークによって生成されるか、又は、プロパティ・スロット値と同じ方法で取得される。

このようにして、フレームワークは、１又は複数のコンポーネント・タイプに属する複数のコンポーネントを作成する。図２は、コンポーネント・タイプ・オブジェクト２００によって定義される単一のコンポーネント・タイプに共に属する２つのそのようなコンポーネント２１１及び２１２を図解している。コンポーネント・タイプ・オブジェクトは、名称２０２と冷凍されたスロット２０４の定義とを含む。この図解されている例では、１つの冷凍されたアクション・スロット・スタート２０６と、１つの冷凍されたトピック・スロット・アラーム２０６と、１つの冷凍されたプロパティ・スロットｈｒｓ＿ｒｕｎｎｉｎｇ２１０とが存在する。スロットｈｒｓ＿ｒｕｎｎｉｎｇ２１０は整数を含むが、他の例では、プロパティ・スロットは、より複雑なデータ、データ構造又は他のデータ・タイプを含むことがある。スロット２０６及び２０８は、メソッド及びトピックをそれぞれ実行するのに必要とされるコードを含む。コンポーネント２１１及び２１２は、第１のファン（FirstFan）及び第２のファン（SecondFan）という名称であるが、それぞれが、スロットマップ２１５及び２１６を含む。それぞれのコンポーネントのスロットマップは、冷凍されたプロパティ・スロット２１７及び２１８に対するコンポーネントの値を含む。

好適実施例の顕著な特徴によると、ソフトウェアが実行されている間、動的スロットをコンポーネントに追加することができる。動的スロットは、冷凍されたスロットと同じタイプである。ランタイムの間の動的スロットの追加は、ユーザによって又はソフトウェア自体によってなされる。実装に応じて、動的スロットは、リクエストをフレームワークに対して行うことにより、又は、コンポーネントのユーティリティ・プロシージャを呼び出すことによって、追加される。どちらの方法が用いられるかとは関係なく、動的スロットは、スロットマップに記憶されることによって追加される。動的スロットは、常に定義を有しており、また、プロパティ・スロットである場合には、値も有する。定義はスロットマップに記憶され、値は、適用可能である場合には、同様にそこに記憶される。図３は、２つの動的スロットがコンポーネント２１１に追加された後の図２のコンポーネント・システムを示している。「ストップ」と称される動的アクション・スロットは、その定義をスロットマップ２１５に追加することによって、追加されている。また、ｐｏｗｅｒ＿ｕｓａｇｅと称される動的プロパティ・スロット３０２は、その定義３０３と値３０４とをスロットマップに追加することによって、追加されている。

コンポーネント２１１は依然として同じコンポーネント・タイプ・オブジェクト２００を基準にしていることに注意してほしい。コンポーネント・タイプ・オブジェクトは、動的スロットの追加を登録するためには変更されない。従って、コンポーネント第１のファン２１１は、２つの動的スロットが追加された後でも、依然として同じコンポーネント・タイプである。結果として、コンポーネント２１１及び２１２は、コンポーネント２１１が更に２つのスロットを有しているという事実とは関係なく依然として同じコンポーネント・タイプである。「純粋な」タイプ・インスタンス・モデルからのこのような離脱は、パフォーマンスの理由でなされる。すなわち、それぞれの変更されたコンポーネントに対する新たなコンポーネント・タイプの作成は、システムを低速化し、追加的なメモリをあまりに多く要求する。コンポーネントは、動的スロットに対するそれら自身のスロットマップを調べその定義を外部コンポーネントやフレームワークやソフトウェアの他のモジュールに提供することを可能にするユーティリティ・メソッドを有している。これらのユーティリティ・メソッドは、コンポーネント・タイプ・オブジェクトが動的スロットの定義を保持しないという理由から、必要である。動的スロットは、スロットマップ・オブジェクトの冷凍されたスロットとほぼ同じ態様で、他のコンポーネント、フレームワーク又はソフトウェアの別のモジュールによって、アクセスされうる。

いったん作成されると、動的スロットは、その定義（及び任意の値）をスロットマップから取り除くことによって、後で、削除することができる。これは、例えば、ソフトウェアをリコンパイルせずに、つまり、サービスのどのような中断もなく、導入される新たに提案される特徴やきのうの結果として生じうる。

リコンパイルなしに動的スロットを導入できることにより、ユーザは、プログラム・フローに影響する新たな関係や接続を追加することが可能になる。これは、「リンク」を通じて達成されるが、このリンクは、２つのコンポーネントの間の関係を保持するスロットである。より詳しくは、リンクは、２つの別個のコンポーネントの２つのスロット（そのどちらもリンクではない）の間の因果的関係を保持する。参照を容易にするために、これらの２つのスロットは、ソース及びターゲット・スロットとして参照される。これらのスロットを保持するコンポーネントは、それぞれが、ターゲット及びソース・コンポーネントとして参照される。リンクによって表わすことができる可能性がある因果的な関係は、多く存在する。好適実施例で用いられるリンクのタイプは、次に示す表１にリスト化されており、リンクしているスロットのタイプが示されている。コンポーネント・レベルでは実行フローの概念はプロパティ・フィールドの変化を含むので、表１においてリスト化されているすべてのリンクは、コンポーネント・システムの実行フローを制御する。

ユーザは、様々なコンポーネントの様々なスロットをリンクすることによって、実行のフローを作成することができる。リンクは、冷凍されているか、又は、動的である。動的リンクは、コンポーネント・システムの実行フローがソフトウェアが実行されている間に変更されることを可能にする。実行フローを変更するためには、リンクを作成するか削除すれだけでいい。同一のリンクを作成する及び削除することを回避するために、好適実施例では、リンクが付勢及び消勢されることが可能になっている。これにより、削除することができない冷凍されたリンクは適切に定式化された動的リンクによって消勢することができるという追加的な効果が得られる。消勢されたリンクは、リンクとしては機能するのではなく、ターゲット・コンポーネントの中に依然として存在し、後で付勢することが可能である。

リンクは、スロットのタイプの１つとして実装される。好適実施例では、リンクは、ターゲット・コンポーネント、すなわち、ターゲット・スロットを保持するコンポーネントの中に含まれる。リンクは、好ましくは、以下のスロットを含む。すなわち、ソース・コンポーネントへの参照又はその名称を保持するソース・コンポーネント・フィールドと、ソース・スロットの名称を保持するソース・フィールドと、ターゲット・スロットの名称を保持するターゲット・フィールドと、付勢されているのか消勢されているのかを示す「付勢」フラグと、である。

リンクは、また、付勢及び消勢メソッド、すなわち、ソース・フィールド、ソース・コンポーネント及び／又はターゲット・フィールドを変更するメソッドなど、それらを処理するのに有用なメソッドを含む。ターゲット・コンポーネントへの参照の必要性はこの構成では回避されているが、その理由は、リンクが既にターゲット・コンポーネントに含まれているからである点に注意すべきである。ターゲット・コンポーネントは、リンクの配置によって間接的に参照される。

好適実施例では、リンクは、付勢されると、ソース・コンポーネントにおいてノブを作成する。ノブとは、リンクに類似のデータ構造であり、ソース・コンポーネントのスロットマップにセーブされる。ノブは、ソース・コンポーネントに対して、そのスロットからターゲット・コンポーネントのスロットにイベントを伝搬させなければならないことを示す。ノブは、リンクの場合と類似のデータ・フィールドを含むが、ソース・コンポーネントではなく、ターゲット・コンポーネントの参照又は名称を含む。ノブは、付勢されたフラグは含まない。むしろ、リンクが消勢されると、ノブは単純に取り除かれる。

図４は、動的リンク４０１が追加されている図３のコンポーネントを示している。リンクは、付勢されることにより、対応するノブ４０２が作成されるように作用する。ターゲット及びソース・スロットはプロパティであるから、このリンクの効果は、第１のファンのｈｒｓ＿ｒｕｎｎｉｎｇの値が変化する場合には、第２のファンのｈｒｓ＿ｒｕｎｎｉｎｇの値を第１のファンのｈｒｓ＿ｒｕｎｎｉｎｇの新たな値に変化させることである。換言すると、このリンクは、値２１７が変化すると、値２１８を値２１７に従わせる。リンクは、冷凍されたスロットであるか動的スロットであるかとは関係なく、同じ態様で振る舞う（ただし、動的スロットが呼び出されると、いくらかのパフォーマンス上の低減が存在する）。

図５Ａは、図４のコンポーネント・システムの抽象化された図であるが、実装の詳細は示されていない。コンポーネント・レベルから見たリンクの機能が示されている。ここでは、リンク４０１は、コンポーネント２１１におけるスロットではなく、ソース・スロットからターゲット・スロットへの矢印で表されている。リンク・スロットは、しかし、コンポーネント２１１の中に存在する。

図５Ａは、コンポーネント・モデルの効果の１つを示している。コンポーネント・モジュールによって、複雑な動的システムが抽象化され、比較的単純な態様で示されることが可能になっている。ユーザには視覚的なインターフェースが提供され、コンポーネント・システムのコンポーネントの１又は複数がウィジェッツとして又は図として視覚的に表現されている。実際、視覚的な表現を、図５Ａに示されているものと類似させることが可能である。コンポーネントは、それ自体の表現をプロパティ・スロットに記憶することができる。あるいは、これらの表現は、グラフィカル・モジュールによって処理することができる。好適な視覚的インターフェースの更なる詳細については、この国際出願と同日に出願された「Real-Time Data Interface and Method for Browsers and the Like」という米国特許出願に記載されている。この米国特許出願は、この出願においてその全体を援用する。

いったんコンポーネントがグラフィカル・インターフェースを通じてユーザに向けて表現されると、これらのコンポーネントの様々な関係するスロット及び値が示される。ユーザは、様々なスロットをクリックにより選択する及びコンポーネントの間のリンクをドラッグしてリンクを追加することによって、そのようなインターフェースを通じて、値を変更する、又は、コンポーネントのメソッドを実行することができる。

更に、ユーザは、スクリーン上のリンク、スロット及びコンポーネントの視覚的表現を操作することによって、新たなコンポーネントを追加する、動的プロパティを追加する若しくは削除する、動的リンクを追加する及び削除する、又は、リンクを付勢及び消勢することができる。このようにして、ユーザは、コンポーネント・ベースのシステムを視覚的に再プログラムする。

図５Ｂは、図５Ａに示されているコンポーネント・システムの抽象化された図であるが、リンク４０１が取り除かれた後のものである。リンクの削除は、破線４０１‘によって示されている。削除は、動的リンク・スロット４１１をコンポーネント２１１から取り除くことによって達成される。任意のこれ以外の動的スロットも、同様に取り除くことができる。

好適実施例の効果の１つは、冷凍されたスロットの効率性及び速度と動的スロットの柔軟性と組み合わせた点である。ある時点では、動的スロットは、あまりに非効率であることがわかっている。しかし、好適実施例は、動的スロットを用いて最適なコンフィギュレーションを見つけることによって、コンポーネント・システムを迅速に変更しテストするのに用いることができる。いったん最適なコンフィギュレーションが見つかると、リコンパイルがなされ、すべての動的スロットが冷凍されたスロットに変換される。リコンパイルの後で、システムは、その最適なコンフィギュレーションを保持しているが、パフォーマンスははるかに向上している。

図６は、図３に示されているシステムのコンポーネント２１１がいかにして最適化されるかを図解している。動的スロットを冷凍されたスロットにコンパイルすることの結果として、元のコンポーネント・タイプのコンポーネントすべてが同じ動的スロットでない場合でも、元のコンポーネント・タイプ又は新たなコンポーネント・タイプへの変化が生じる。動的スロット３０１及び３０２は、その定義をスロットマップ２１５から取り除き、コンポーネント・タイプのベース・クラス２００の冷凍されたスロット定義を増加させることによって、冷凍されたスロットに変換される。プロパティ・スロット３０２の値３０４はスロットマップ２１５に留まるが、今度は、同じコンポーネント・タイプのすべてのコンポーネントに共通の冷凍されたスロット定義と関連付けられている。２つの値２１７及び３０４は、これらの定義にリスト化された又はそれらから導かれたオフセットによって、それぞれの定義２１０及び３０３と対にされる。

図７は、コンポーネントをコンポーネント・システムに階層的に編成する好適な方法を図解している。既に記述されているように、コンポーネントは、プロパティ・スロットとして、他のコンポーネントを含むことがある。これは、他のコンポーネントへの参照をプロパティ・スロットとして含むことによって、達成される。別の実施例では、所有者を指定するリンクが、参照の代わりに用いられる。

図７に示されているように、他のコンポーネントを含み、システムのコンポーネントをツリー構造に編成することができるというコンポーネントの能力を用いることが好ましい。これらのコンポーネント・タイプ・オブジェクト７０６、７０７、７０８及び７０９は、それぞれが、コンポーネント・タイプＡ、Ｂ、Ｃ及びＤを記述している。コンポーネント７０１はコンポーネント・タイプＡであり、コンポーネント７０２及び７０３はコンポーネント・タイプＢであり、コンポーネント７０４はコンポーネント・タイプＣであり、コンポーネント７０５はコンポーネント・タイプＤである。コンポーネント７０２、７０３及び７０４は、すべて、コンポーネント７０１の中のスロットとして含まれており、この包含関係は、コンポーネント７０１のスロット７１０における参照によって定義されている。コンポーネント７０４は、コンポーネント７０５を更に含む。目的地としてコンポーネント７０３のソース及びスロット７１２であるコンポーネント７０５のスロット７１１を有する実行フロー・リンク７１３が存在し、太字の矢印で図解されている。他のコンポーネントを含むコンポーネントは、親として参照される。これよりも複雑なシステムを、同様の構造で編成することができる。好適実施例では、システムのすべてのコンポーネントは、単一のツリーとして編成されている。これは、親コンポーネントはただ１つだけあり、ルート・コンポーネントと称され、これは、他のどのコンポーネントにも含まれておらず、そして、その親子関係をルート・コンポーネントまで辿ることができる１又は複数の非ルート・コンポーネントが存在する、ということを意味する。図７では、ルート・コンポーネントは、コンポーネント７０１である。この編成によって、すべてのコンポーネントが、ルートから出発してコンポーネント名で終了するその祖先の名称のシーケンシャルなリストから構成されるストリングを通じて一意的に識別される、という追加的な効果が得られる。この特徴を用いると、異なるベンダ（売主）からの新たなコンポーネントがシステムに連続的に追加されるような複雑なコンポーネント・システムにおいて、コンポーネントの一意的な識別を保証する助けになる。この識別は、フィールド名を用いて拡張が可能であり、コンポーネントのフィールドに対して一意的な識別を同様に提供することができる。

視覚的なインターフェースはコンポーネント・モデルの重要な効果であるから、本発明は、また、視覚的なインターフェースを提供するシステムを含む。このシステムは、特に、コンポーネント・モデルのためのインターフェースを提供するのに有用であるが、その理由は、このシステムが、視覚的なオブジェクト、ウィジェッツ（widgets）に基づいており、それぞれのそのようなウィジェッツがコンポーネントを視覚化するからである。これ以外の有用な特徴として、このシステムは、非常に大きな柔軟性と比較的低いソースの利用とを組み合わせている点がある。

視覚化システムは、ＨＴＭＬブラウザなど、標準化されたファイル・フォーマットでサードパーティのコンテンツを表示するのに用いられる普及しているソフトウェアと互換性を有するように設計されている。好適実施例では、本発明は、ジャバ・アプレットとして、ＨＴＭＬファイルの中に実装されている。ジャバ・アプレットは、エンジンと称される。図８は、視覚化システムの動作を示す流れ図である。ユーザは、ステップ８０１で、このエンジンを用いて、ＨＴＭＬブラウザの上にＨＴＭＬページをロードする。ステップ８０２では、ＨＴＭＬブラウザは、エンジンを実行する。ステップ８０３では、エンジンは、コンフィギュレーション・ファイルをリクエストする。コンフィギュレーション・ファイルは、コンピュータ・ネットワークを介して、又は、ユーザのコンピュータから、リクエストされる。好適実施例では、コンフィギュレーション・ファイルは、ＸＭＬファイルである。コンフィギュレーション・ファイルは、視覚的提供のレイアウトを含み、更に、１又は複数のウィジェッツへの参照、そして、これらのウィジェッツへの配置及び／又はサイズ化情報を含む。

ウィジェッツは、視覚的なオブジェクトである。ウィジェッツの例は、コンポーネントの表現、物理的デバイス、グラフ、パイ型のチャート、表などである。ウィジェッツは、アニメ化することが可能であるし、多数の様々な方法で情報を提供することができる。ウィジェッツは、また、オプションであるが、ユーザと相互作用することも可能である。

それぞれのウィジェッツと関連付けられた実行な可能なコードがあり、コンフィギュレーション・ファイルで参照される。このコードは、拡張（エクステンション）と称される。拡張は、ユーザのコンピュータ、又は、コンピュータ・ネットワークによってユーザのコンピュータに接続された別のコンピュータ上に存在する。拡張は、コンフィギュレーション・ファイルに含まれる参照によって、配置することができる。エンジンは、コンフィギュレーション・ファイルのパージングを行い、拡張を配置することができる。次に、エンジンは、拡張をロードし、それらを、必要な場合にはコンピュータ・ネットワークを介してダウンロードする（ステップ８０４）。エンジンは、次に、すべての拡張を並行的に実行する。拡張は、いったん実行することになると、エンジンの助けを借りながら、ユーザ・インターフェースを表示する。それぞれの拡張は、それが関連付けられているウィジェッツを表示する。エンジンは、コンフィギュレーション・ファイルの中に記述された一般的なレイアウトを表示し、表示されたウィジェッツを操作して、コンフィギュレーション・ファイルに従ってそれらのサイズを決定し配置する。拡張は、オプションであるが、他のソフトウェア・モジュールと通信を行い、これらの通信に従って関連付けられているウィジェッツを変更及び更新する。例示的な実施例では、ウィジェッツはコンポーネントのグラフィカルな表現であり、そのウィジェッツと関連付けられている拡張は、コンピュータ・ネットワークを介してコンポーネントと通信する。拡張は、また、オプションであるが、ユーザによるコマンドを受け入れたりそれに応答したりすることによって、ユーザと相互作用する。拡張は、また、ユーザとの相互作用に基づいて、コンポーネントなどの他のソフトウェア・コンポーネントからの情報を送受信することができる。このように、ウィジェッツは、拡張のソフトウェア・コードに基づいて、他のソフトウェア・モジュールとの通信、及び／又は、ユーザとの相互作用を、連続的に更新する。拡張は、更に、ユーザから受信した制御信号を他のソフトウェア・モジュールに送信することができる。

例えば、ウィジェッツは、サーモスタットを表しており、このサーモスタットはサーモスタット・コンポーネントによって制御されているとする。サーモスタット・ウィジェッツに対応する拡張は、ネットワークを介して、更新された温度の読み取り値に対するリクエストを送信する。サーモスタット・コンポーネントが回答する。すると、拡張は、温度を更新する。ユーザは、ウィジェッツと相互作用する。例えば、ウィジェッツの上をクリックすることにより、ユーザは、温度を、華氏ではなく摂氏の度数で温度を見たいという希望を表現することができる。拡張は、そのリクエストを受け取り、ウィジェッツを更新する。ユーザは、また、ウィジェッツを通じて、コマンドを実際のサーモスタットに送ることもできる。例えば、ユーザがサーモスタットをオフにすることを望む場合、又は、それを電力節約モードに切り換えたい場合には、ウィジェッツは、そのようなコマンドをサーモスタット・コンポーネントに送る。

視覚的インターフェース・システムの別の実施例によると、ネットワーク通信が拡張によって利用されることが多い場合には、より高い効率性が保証される。複数の拡張によって複数のネットワーク通信が、並行的に動作すると、パフォーマンス上の問題が生じることが多いので、この代替的な実施例では、拡張は、ネットワーク通信を開始することはなく、その代わりに、リクエストをエンジンに送る。エンジンは、所定の時間にわたってネットワーク通信リクエストを集合させ、それらをよりサイズが大きなバンドルに合成することを試み、それらをネットワークを介して送ることにより、ネットワーク効率を改善している。同じコンピュータに向かって出ていく通信だけがバンドル化される。また、通信のバンドルを解除することができるソフトウェア・モジュールが受信側に存在していなければならない。エンジンは、また、あるソフトウェア・モジュールから、１又は複数の拡張に向けて送られた通信を含むバンドルを受け取り、それを単独の通信にするべくバンドルを解除し、それらの単独の通信を、その宛先の拡張に送る。この実施例は、多くの拡張が同一のソフトウェア・モジュールと通信する場合に、最も効率的である。

視覚的なインターフェース・システムは、具体性及び明晰性のために、ＨＴＭＬ、ジャバ、ＸＭＬなどの言語、フォーマット及びプロトコルを用いて記述される。視覚的なインターフェース・システムは、これらの言語、フォーマット及びプロトコルに限定されることはない。視覚的なインターフェース・システムは、埋込型アプリケーションを許容する任意の言語と動作するように構成することができる。プロプラエタリ・データ・フォーマットを含む任意のデータ・ファイル・フォーマットを、ＸＭＬの代わりに用いることができる。

ここに記載されたコンポーネント・モデルと共に動作可能な好適な視覚的インターフェースに関する更なる詳細については、再度、上述した、米国特許出願「Real-Time Data Interface and Method for Browsers and the Like」の参照を促しておきたい。

コンポーネント・モデルでは、すべてのソフトウェア・プログラムを実装することは必要ない。コンポーネント・ベースの機能は、伝統的なオブジェクト指向コードよりも、より低速、より大型になる傾向がある。従って、好適実施例では、動的に修正される必要がある、又は、コンポーネント・モデルの他の特徴を用いる必要があるコードの部分だけが、このコンポーネント・モデルでは実装されている。しかし、コンポーネント・モデルにおいて技術的に実装されていないコードでも、コンポーネントにカプセル化して、それが他のコンポーネントに対しては１つのコンポーネントと見えるようにすることが可能である。

この明細書において記載されたコンピュータは、任意の計算装置でありうる。コンピュータ・ネットワークは、無線ネットワークを含む。
本発明は、以上で、特定の実施例との関係で説明されたが、特許請求の範囲によって、限定なく定義されるのであり、構成要素及び方法ステップについての実質的でない変更を含むものとする。

ある１つのコンポーネント・タイプの作成とそのコンポーネント・タイプの複数のコンポーネント・インスタンスとを示す流れ図である。 同一のコンポーネント・タイプから生成された２つのコンポーネントを示すブロック図である。 動的スロットを含むコンポーネント・システムを示すブロック図である。 リンクを含むコンポーネント・システムを示すブロック図である。 図５Ａは、リンクを含むコンポーネント・システムのコンポーネント・レベルの抽象を示すブロック図であり、実装の詳細は隠されている。図５Ｂは、図５Ａに示されているコンポーネント・システムを示すブロック図であり、リンクが取り除かれている。 効率を改善するようにリコンパイルされたコンポーネント・システムのブロック図である。 ツリー構造のコンポーネント・システムを示すブロック図である。 視覚的インターフェースの操作を示す流れ図である。

Claims (26)

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. 請求項２５記載の方法において、前記スロットは動的スロットであることを特徴とする方法。

Images