JP2004038965A - 拡張可能なオンデマンドプロパティシステム - Google Patents

Abstract

【課題】オブジェクトのプロパティを処理するシステムおよび方法を提供すること。
【解決手段】より具体的には、このシステムおよび方法は、プロパティ間の関係を形式的に表現する依存関係機構を提供する。この関係は、グローバルまたはローカルに適用することができる。依存関係機構を使用して、このプロパティシステムはプロパティ間の関係を監視することができ、異なるプロパティ間の循環性を実行中に検出することができる。このシステムおよび方法はまた、プロパティのうちのいずれかについての値を計算する評価機構を提供する。プロパティシステムがオンデマンドであるので、ローカル記憶域に値を格納する必要がない。依存関係機構と評価機構は拡張可能であり、それにより、プロパティシステムが直接的関係、継承、逆継承、プロパティシート、カプセル化などのどんなタイプの関係もモデル化することが可能となる。
【選択図】　図２

Description

【背景技術】
【０００１】
今日、大部分のアプリケーションはオブジェクトを使用して書かれている。このオブジェクトは、第３者から供給を受けることができ、またはあるアプリケーション向けに特に開発することができる。オブジェクトを使用することにより、コードを容易に再利用することができ、および変更を行うことなく多数の異なるアプリケーションにコードを組み込むことができる。加えて、変更が必要な場合、オブジェクトの機能を継承する新しいオブジェクトを作成することができる。次いで、必要に応じてその新しいオブジェクトに新しい特定の機能を追加することができる。このように既存のオブジェクトを再利用および修正できることにより、新しいアプリケーションの開発時間が削減され、時には数ヶ月から数週間にまで削減されることもある。
【０００２】
しかし、オブジェクトの使用が非常に一般的になり、有益であるが、このオブジェクト中のプロパティを処理する現在の手法はいくつかの欠点を有する。例えば、オブジェクト中の第１のプロパティが別のオブジェクト中の第２のプロパティに依存する場合、開発者は、第２のプロパティを監視（すなわち聴取）し、それが変化したときに第１のプロパティを変更するコードを書かなければならない。この機能を実行する単純化したコードの一部は、以下のようなものである。
【０００３】

【考案の開示】
【発明が解決しようとする課題】
【０００４】
上記のように、このコールバック関数は、第１のプロパティ（例えばＢｕｔｔｏｎ１　Ｐｒｅｓｓｅｄ）が変化したときはいつでも、第２のプロパティ（すなわちＢａｃｋｇｒｏｕｎｄＣｏｌｏｒ）についての値を返す。したがって、第１のプロパティの状態が変化するごとに、コールバック中に値（例えば、赤色または灰色）が計算され、第２のプロパティ内に格納される。この技法は第２のプロパティについてのオブジェクト内に記憶域を必要とする。この記憶域は、第２のプロパティについての現状態を保つのに使用される。
【０００５】
開発者はこれらのオブジェクトを別々に開発することができるので、様々なオブジェクト内のプロパティの一部の間で循環が生じる可能性がある。例えば、上記の例で続けると、Ｂｕｔｔｏｎ１　Ｐｒｅｓｓｅｄプロパティの状態を変更する、ｂａｃｋｇｒｏｕｎｄＣｏｌｏｒプロパティについてのコールバック関数を追加することができる。ｂａｃｋｇｒｏｕｎｄＣｏｌｏｒが変化したためにｂｕｔｔｏｎ　ｐｒｅｓｓｅｄプロパティの状態を変更するコールバック関数を有することはあまり現実的ではなく、通常はアプリケーションで生じないが、２つのプロパティが互いの状態を変更するときに生じる問題を示す助けになる。実際のアプリケーションでは、通常、２つのパラメータは互いの状態を直接変更しないが、他の従属プロパティにより、この単純な例によって示される循環性が引き起こされる。したがって、上記の例が与えられた場合、実行時に、２つのプロパティの一方が状態を変更すると、両者は無期限に状態を変更し続けることになる。その場合、適切なオペレーションを行う前にこの循環性の問題を識別し、訂正しなければならない。遺憾ながら、プロパティ変化のあらゆる組合せをテストすることは非常に難しい。したがって、この循環性の問題の一部が、ソフトウェア製品をリリースした後になって表面化する可能性がある。
【０００６】
少なくともこれらの制約のために、オブジェクトのプロパティを処理する現在のモデルは理想的ではない。
【０００７】
本発明は、従属プロパティに関連するオペレーションが呼び出されるまで、第１プロパティの変化が従属プロパティに影響を及ぼさないようにオブジェクトのプロパティを処理するシステムおよび方法を目的とする。
【課題を解決するための手段】
【０００８】
したがって、オンデマンドタイプのプロパティシステムが提供される。より具体的には、このシステムおよび方法は、プロパティ間の関係を形式的に表現する依存関係メカニズムを提供する。この関係は、グローバルまたはローカルに適用することができる。依存関係メカニズムを使用して、このプロパティシステムはプロパティ間の関係を監視することができ、異なるプロパティ間の循環性を実行中に検出することができる。このシステムおよび方法はまた、登録されたプロパティのうちのいずれかについての値を計算する評価メカニズムを提供する。依存関係メカニズムと評価メカニズムは共に拡張可能であり、それにより、プロパティシステムが直接的関係、継承、逆継承、プロパティシート、カプセル化などのどんなタイプの関係もモデル化することが可能となる。
【０００９】
本発明の一利点は、ローカル記憶域に値を格納する必要がないことである。加えて、プロパティシステムがオンデマンドであるので、本発明のプロパティシステムは、速度やメモリ性能に関して、よりスケーラブルである。
【００１０】
本発明の別の利点は、開発中のプロパティを適切に処理するための複雑なリスナやコールバック関数をもはや開発者が書く必要がないことである。
【００１１】
本発明のさらに別の利点は、オブジェクト内のプロパティ用の記憶域の管理がより効率的になり、便利になることである。各オブジェクトインスタンスはもはや、そのオブジェクト内に各プロパティについてのローカル記憶域を有する必要がない。
【００１２】
本発明のさらに別の利点は、プロパティシステムが実行時にプロパティ間の循環性を検出し、この循環性を遮断することである。
【発明を実施するための最良の形態】
【００１３】
簡潔に述べると、本発明はオンデマンドプロパティシステムを提供する。このオンデマンドプロパティシステムは、従属プロパティに関連するオペレーションが呼び出されるまで、第１プロパティの変化が従属プロパティに影響を及ぼさないようにオブジェクトのプロパティを処理する。より具体的には、このシステムおよび方法は、プロパティ間の関係を形式的に表現する依存関係メカニズムを提供する。この関係は、グローバルまたはローカルに適用することができる。依存関係メカニズムを使用して、このプロパティシステムはプロパティ間の関係を監視することができ、異なるプロパティ間の循環性を実行中に検出することができる。このシステムおよび方法はまた、プロパティのうちのいずれかについての値を計算する評価メカニズムを提供する。プロパティシステムがオンデマンドであるので、ローカル記憶域に値を格納する必要がない。依存関係メカニズムと評価メカニズムは拡張可能であり、それにより、プロパティシステムが直接的関係、継承、逆継承、プロパティシート、カプセル化などのどんなタイプの関係もモデル化することが可能となる。本発明の上記その他の態様は、以下の詳細な説明を読んだ後に明らかになるであろう。
【００１４】
図１を参照すると、本発明を実施する１つの例示的システムは、コンピューティング装置１００などのコンピューティング装置を含む。非常に基本的な構成では、コンピューティング装置１００は一般に、少なくとも１つのプロセッサ１０２およびメモリ１０４を含む。コンピューティング装置の厳密な構成およびタイプに応じて、システムメモリ１０４は、揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはその２つの組合せとすることができる。システムメモリ１０４は、一般にオペレーティングシステム１０５、および１つまたは複数のプログラムモジュール１０６を含み、およびプログラムデータ１０７を含むことができる。プログラムモジュール１０６の例には、ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ　ＣｏｒｐｏｒａｔｉｏｎによるＶｉｓｕａｌ　Ｓｔｕｄｉｏ　ＩｎｔｅｌｌｉＳｅｎｓｅや、オブジェクトライブラリを使用する他のソフトウェアプログラミング環境が含まれる。加えて、プログラムモジュール１０６には、ソフトウェアプログラミング環境を使用して作成されたソフトウェアアプリケーションが含まれる。これらのソフトウェアアプリケーションがプロセッサ１０２上で実行されるとき、プロパティエンジンが、本発明によるソフトウェアアプリケーションを処理する。プロパティエンジンはオペレーティングシステム１０５の一部でよく、または別のプログラムモジュール１０６でよい。このコンピューティング装置１００の基本的構成を、図１では破線１０８内の構成要素によって示す。
【００１５】
コンピューティング装置１００は、追加の特徴または機能を有することができる。例えばコンピューティング装置１００は、例えば磁気ディスク、光ディスク、あるいはテープなどの（取外し可能および／または取外し不能な）追加のデータ記憶装置も含むことができる。図１では、このような追加の記憶装置をリムーバブル記憶装置１０９およびノンリムーバブル記憶装置１１０で示す。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶するための何らかの方法または技術で実装された、揮発性／不揮発性のリムーバブル／ノンリムーバブル媒体を含むことができる。システムメモリ１０４、リムーバブル記憶装置１０９、およびノンリムーバブル記憶装置１１０はすべて、コンピュータ記憶媒体の例である。コンピュータ記憶媒体には、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）、または他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、または他の磁気記憶装置、あるいは、所望の情報を記憶するのに使用することができ、コンピューティング装置１００でアクセスすることができる他のどんな媒体も含まれる。このようなどんなコンピュータ記憶媒体も装置１００の一部とすることができる。コンピューティング装置１００はまた、キーボード、マウス、ペン、音声入力装置、タッチ入力装置などの入力装置１１２も含むことができる。ディスプレイ、スピーカ、プリンタなどの出力装置１１４を含めることもできる。これらの装置は当技術分野で周知であり、ここで詳細に論じる必要はない。
【００１６】
コンピューティング装置１００はまた、ネットワーク経由などでその装置が他のコンピューティング装置１１８と通信することを可能にする通信接続１１６も含むことができる。通信接続１１６は通信媒体の一例である。通信媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータにより、搬送波または他の移送メカニズムなどの被変調データ信号として実施することができ、その通信媒体にはどんな情報送達媒体も含まれる。「被変調データ信号」という用語は、信号の特性集合のうちの１つまたは複数を有する信号、または情報を符号化するように変化する信号を意味する。例えば、限定はしないが、通信媒体には、ワイヤードネットワークまたはダイレクトワイヤード接続などのワイヤード媒体、ならびに音響媒体、ＲＦ媒体、赤外線媒体、および他のワイヤレス媒体などのワイヤレス媒体が含まれる。本明細書で使用するコンピュータ可読媒体という用語は、記憶媒体と通信媒体のどちらも含む。
【００１７】
図２は、本発明によるプロパティシステムの１つの例示的実装を説明する際に使用するプロパティ関係の図式的表現である。このプロパティ関係は、直接的関係２１０および継承関係２２０を含む。概略として、直接的関係２１０のプロパティ変化が、最終的に継承関係２２０内のプロパティに影響を及ぼす。図２にモデル化したプロパティ関係はプロパティ間の直接的関係および継承関係を表すが、本発明のプロパティシステムを、逆継承、データバインディング、カプセル化、プロパティシートなどの他の関係をモデル化するのに使用できることを当業者なら理解するであろう。したがって、図２にモデル化した関係を、本発明の機能の非限定的な例として示す。
【００１８】
直接的関係２１０は、２つのノード２１２および２１４を含む。以下の議論では、ノードとは、プロパティに作用させるためにプロパティエンジンに対して２つの共通インターフェースを公開するオブジェクトを指す。簡単に言えば、図４と共に後に詳細に説明するが、２つの共通インターフェースは、照会機能と１組の機能を含む。ノード２１２は、ボタンに関するＰｒｅｓｓｅｄプロパティなどのＰｒｏｐｅｒｔｙ１　２１６を含む。ノード２１４は、ボタンの背景についてのＣｏｌｏｒプロパティなどのＰｒｏｐｅｒｔｙ２　２１８を含む。始めに説明したように、従来のプロパティシステムは、Ｐｒｏｐｅｒｔｙ１　２１６を監視するリスナ機能を実装し、Ｐｒｏｐｅｒｔｙ１　２１６が変化したとき、従来のプロパティシステムはそれに応じてＰｒｏｐｅｒｔｙ２　２１８を更新する。
【００１９】
しかし、対照的に本発明のプロパティシステムは、Ｐｒｏｐｅｒｔｙ１　２１６とＰｒｏｐｅｒｔｙ２　２１８の間の関係をモデル化する。この関係の場合、ノード２１２はノード２１４に対するソースとして指定される。ノード２１４は従属部と呼ばれる。一般には、ソースは別のノードに影響を及ぼすノードを表す。従属部は、別のノードの影響を受けるノードを表す。上記で示した例では、アプリケーション内の任意のオブジェクトは、Ｐｒｏｐｅｒｔｙ２　２１８に作用させるために共通インターフェースの一方を使用することができる。簡単に言えば、後で図５および６と共にそれぞれ詳細に説明するｇｅｔＶａｌｕｅ（）メソッドおよびｓｅｔＶａｌｕｅ（）メソッドにより、すべてのノードによって共通インターフェースが提供されることが保証される。この共通インターフェースにより、プロパティエンジンおよび任意のオブジェクトが、共通インターフェースを使用して所望のプロパティにアクセスすることが可能となる。例えば、照会（すなわちｇｅｔＶａｌｕｅ）は、そのソースのうちの１つから、関係のある値を最終的に得る。図２に示す直接的関係２１０では、このソースはノード２１２である。したがって、ノード２１４内にＰｒｏｐｅｒｔｙ２　２１８のためのローカル記憶域を必要とせずに、所望のオペレーションがオンデマンドで実行される。
【００２０】
継承関係２２０は、複数のノード２２２〜２３０を含む。ノードは、リーフノード（例えばノード２２４〜２３０）中のプロパティがリーフノードの継承プロパティである継承Ｐｒｏｐｅｒｔｙ２　２３４〜２４０それぞれのためのローカル記憶域を必ずしも有さないことを除き、継承のために従来型の階層式に構築される。むしろ本発明によれば、これらのプロパティ２３４〜２４０についての値を照会および設定する２つの共通インターフェースを使用して、プロパティにオンデマンドに作用させる。
【００２１】
直接的関係２１０中のノード２１４と、継承関係２２０中のノード２２２が実際には同じノードであることに気付くであろう。このノードを別々に図示したのは、単に本発明がモデル化することのできる２つのタイプの関係を説明するのに好都合であるからに過ぎない。しかし、ノード２１４およびノード２２２は実際には同じであるので、アプリケーション内の任意のオブジェクトは、値を照会するなど子プロパティ（例えばＰｒｏｐｅｒｔｙ２　２４０）に作用させるために、共通インターフェースの一方を使用することができる。この照会により、ノードのうちの１つから最終的に値が得られる。値の取得元のノードは直接的ソースでよく、またはノード２３０の直接的ソース（すなわちノード２２６）から間接的に導出された間接的ソースでよい。一部のノード（例えばノード２２６）がノード２２２に対する従属部としてのラベルであっても、その同じノードが別のノードに対するソースとなれることを当業者なら理解するであろう。例えば、ノード２２６は従属ノード２３０に対するソースである。これらのすべての依存関係は個々にモデル化することができる。
【００２２】
１つのノードがいくつかのソースを有することができ、その１つのノードがそれ自体、複数のノードに対するソースとなれることを当業者なら理解するであろう。これらの関係はそれぞれ、本発明に従ってモデル化される。しかし、関係がモデル化された後は、ソースのうち１つに対して、別のソースをそのソースに追加するなどの変更が行われた場合、元のノードを修正する必要はない。むしろ本発明によれば、元のノードはこの変更をほとんど認識せず、プロパティエンジンが、その変更に影響を及ぼすように必要な基礎的メカニズムを実行する。これにより、開発者に大きな利点がもたらされる。
【００２３】
直接的関係および継承関係をモデル化するときのプロパティシステムのオペレーションを概略的に説明したので、次に基礎的メカニズムを説明する。一般には、プロパティシステムは、他のプロパティに影響を及ぼす、あるプロパティに対する変更をプロパティエンジンが認識できるように、プロパティ間のこれらの関係を記述する依存関係メカニズム（例えばｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド）を提供する。加えて、プロパティシステムは、作用を受けているプロパティを評価する評価メカニズム（例えばｅｖａｌｕａｔｅメソッド）を提供する。本発明の一実施形態では、これらのメカニズムは共に、クラス（例えばＥｘｐｒｅｓｓｉｏｎクラス）を通じて提供される。
【００２４】
図３は、例示的なＥｘｐｒｅｓｓｉｏｎクラスの図式的表現である。このＥｘｐｒｅｓｓｉｏｎクラスは、コンストラクタ３０２、ｅｖａｌｕａｔｅメソッド３０４、ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６、およびｓｅｔＶａｌｕｅメソッド３０８を含む。加えて、Ｅｘｐｒｅｓｓｉｏｎクラスは、ソースがデータベースフィールドなどの外部であるときのための外部ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３１０を含むことができる。コンストラクタ３０２は、コンストラクタ３０２がｅｘｐｒｅｓｓｉｏｎオブジェクトを作成している対象の従属プロパティに対するソースを指定するソースパラメータ３０３を取る。したがってこのｅｘｐｒｅｓｓｉｏｎクラス４００は、ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６を介して依存関係メカニズムを提供し、Ｅｖａｌｕａｔｅメソッド３０４を介して評価メカニズムを提供する。開発者は、登録されたパラメータごとにｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６およびＥｖａｌｕａｔｅメソッド３０４を上書きする。ｅｖａｌｕａｔｅメソッド３０４、ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６、およびｓｅｔＶａｌｕｅメソッド３０８がそれぞれ、一方がノードを指定し、他方がプロパティＩＤを介してプロパティを指定する少なくとも２つのパラメータを有することに気付くであろう。
【００２５】
図２の継承関係を用いて続けると、１つの例示的Ｅｖａｌｕａｔｅメソッド３０４は以下のようなものでよい。

【００２６】
したがって、この上書きされたＥｖａｌｕａｔｅメソッド３０４は、パラメータとして渡されたオブジェクトの親からの値を返そうと試みる。ノードと、評価中の従属部に関連するｐｒｏｐｅｒｔｙＩＤがパラメータとして渡される。次いで値がそのソースから計算される。上記の継承の例では、そのソースは親を含む。しかし、親もモデル化され、上書きされたｅｖａｌｕａｔｅメソッドを有するので、評価プロセスは、最終的に値が返されるまで、ツリーの上方に向かって、他のソースまで続く可能性がある。図２では、ｇｅｔＶａｌｕｅがノード２１２に対して実行されるときにこのことが生じる。値を得るための検索経路を決定する責任を開発者が負うことを当業者なら理解するであろう。例えば上記の継承の例では、ノード２２２に関連するｅｖａｌｕａｔｉｏｎメソッドはデフォルト値を提供することができる。したがってｅｘｐｒｅｓｓｉｏｎクラスにより、どこから値を得るべきかを決定し、およびどのシーケンスを検索するかを決定する際に、評価メカニズムを非常に拡張的にすることが可能となることを当業者なら理解するであろう。
【００２７】
ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６もまた、形式的な依存関係をプロパティシステムに対して指定するために開発者により上書きされる。簡単に言えば、図６および７の流れ図と共により詳細に説明するが、ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６は、変更されたソースを有する各従属部を無効にすることを担う。従属部のうちの１つがソースである場合、そのソースに対するｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッドが起動され、その従属部が無効にされる。したがって、ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔプロセスは、変更の影響を受けるすべての関係を無効にするまで再帰的に続行する。一実施形態では、プロパティエンジンによって提供されるインターフェース（例えばＮｏｄｅ．ＭａｒｋＤｅｐｅｎｄｅｎｔ（ＰｒｏｐｅｒｔｙＩＤ））によって従属部が無効とマークされる。以下は、図２で説明した継承関係についての例示的な上書きされたｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６である。
【００２８】
【表１】

【００２９】
【表２】

【００３０】
したがって、この例示的な上書きされたｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６では、あらゆる子に関するＰｒｏｐｅｒｔｙ２が無効にされる。加えて、ノードの親プロパティが変化した場合、あらゆる子に関する、継承されたあらゆるプロパティを無効とマークしなければならない。本発明の別の改良では、一実施形態において、いくつかのプロパティをすぐに無効にする特別な無効化メソッドが提供される。
【００３１】
前述のように、プロパティシステムがこの形式的依存関係を提供するために、特定の共通ＡＰＩが各ノードで利用可能にされる。これらの共通ＡＰＩにより、プロパティエンジンおよび任意のオブジェクトが共通インターフェース（例えばＡＰＩ）を使用して所望のプロパティにアクセスすることが可能となる。
【００３２】
図４は、本発明による、特定の共通インターフェースをノードに提供するプログラミングモデル４００の図式的表現である。以下の議論では、オブジェクトという用語は、クラスのインスタンスを指すのに用いる。各オブジェクトについて、オブジェクトがインスタンス化される元のクラスが存在することを当業者なら理解するであろう。さらに、オブジェクトは複数のクラスから導出された機能を有することができる。プログラミングモデル４００はノードクラス４０２を提供する。プロパティエンジンはノードクラス４０２について認識している。ノードクラス４０２は、ｓｅｔＶａｌｕｅ（）メソッド４０６およびｇｅｔＶａｌｕｅ（）メソッド４０８を含む。ｓｅｔＶａｌｕｅ（）メソッド４０６およびｇｅｔＶａｌｕｅ（）メソッド４０８は、各ノードによって提供される共通インターフェースを表す。開発者オブジェクト４０４は、ノードクラス４０２（すなわちｓｅｔＶａｌｕｅ（）メソッド４０６およびｇｅｔＶａｌｕｅ（）メソッド４０８）によって提供される機能を継承する。開発者オブジェクト４０４は、１つまたは複数のプロパティ（例えばＰｒｏｐｅｒｔｙ１およびＰｒｏｐｅｒｔｙ２）を含むことができる。開発者オブジェクト４０４内では、命令が書き込まれ、ｒｅｇｉｓｔｅｒＰｒｏｐｅｒｔｙコール（例えばｒｅｇｉｓｔｅｒＰｒｏｐｅｒｔｙコール４１０および４１２）を使用して１つまたは複数の各プロパティが登録される。
【００３３】
ｒｅｇｉｓｔｅｒＰｒｏｐｅｒｔｙメソッド４２２は、プロパティエンジン内のプロパティマネージャ４２０によって提供される。プロパティマネージャ４２０は、登録されたプロパティ（例えばＰｒｏｐｅｒｔｙ１およびＰｒｏｐｅｒｔｙ２）を管理し、登録されたプロパティに関する関連情報がプロパティ情報ストア４３０に格納される。プロパティ情報ストア４２０は、図１に示すコンピュータシステム１００内のメモリに常駐する。あるいは、プロパティ情報ストア４２０の一部をキャッシュしたり、記憶媒体上に格納したりすることができる。プロパティ情報ストア４２０は、登録されたプロパティごとのプロパティエントリ（例えばプロパティエントリ４３２および４３４）を含む。本発明によれば、プロパティエントリ４３４は、プロパティ識別子フィールド４３６および式フィールド４３８を含む。加えて、プロパティエントリ４３４は、名前フィールド、タイプフィールド、デフォルト値フィールドなどの、登録されたプロパティに関係する他のフィールドを含むことができる。デフォルト値フィールドは、プロパティについてのデフォルト値を格納する。このデフォルト値は、式がソースから値を計算することができない場合に使用される。
【００３４】
プロパティエントリ４３４は、登録されたプロパティごとにプロパティ識別子フィールド４３６内に固有プロパティ識別子を格納する。一実施形態では、固有プロパティ識別子は、ＲｅｇｉｓｔｅｒＰｒｏｐｅｒｔｙ（）によって生成される。式フィールド４３８は、固有プロパティ識別子に関連する導出式オブジェクトを格納する。この導出式オブジェクトは、レジスタプロパティコール（例えばレジスタプロパティコール４１０および４１２）中の式パラメータ４４０から得られる。前述のように、導出式オブジェクトは、上書きされたｅｖａｌｕａｔｅ（）メソッドおよび上書きされたｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔ（）メソッドを含む。したがって、各プロパティを登録した後は、依存関係メカニズムおよび評価メカニズムは、登録されたプロパティに関連する導出式オブジェクトを介してグローバルに利用可能である。別の実施形態では、グローバル式をローカル式で上書きすることができる。ローカル式は、ローカル値について認識している式によって提供される。これらのローカル式は、ノードクラス中のプロパティエンジンによって提供されるｒｅａｄＬｏｃａｌＶａｌｕｅを使用して、ローカル値を取り出す。したがってローカル式により、ノード上にローカルに格納された値を取り出すことが可能となる。
【００３５】
ノードクラス４０２が、ｒｅａｄＬｏｃａｌＶａｌｕｅ（）メソッド（図示せず）およびｗｒｉｔｅＬｏｃａｌＶａｌｕｅ（）メソッド（図示せず）などの内部で使用される追加のメソッドも提供することを当業者なら理解するであろう。一実施形態では、ｒｅａｄＬｏｃａｌＶａｌｕｅ（）メソッドは、前述のようなローカル式によって使用される。ローカル式はｇｅｔＶａｌｕｅによって間接的に呼び出される。ｗｒｉｔｅＬｏｃａｌＶａｌｕｅ（）は、ｓｅｔＶａｌｕｅ（）メソッド４０６によって使用される。式が、「子」の式に関連するｅｖａｌｕａｔｅ（）メソッドを「親」の式が呼び出す他の式を含むことを当業者はさらに理解されよう。「子」の式は、親の式に対する間接的ソースと呼ばれる。
【００３６】
図５は、本発明による、登録されたプロパティについての値を取り出す例示的ｇｅｔＶａｌｕｅプロセスを示す論理的流れ図である。処理はブロック５０１で始まり、ブロック５０１では、プロパティ（以後、当該のプロパティと呼ぶ）に関する照会を開始する。処理はブロック５０２に進む。
【００３７】
ブロック５０２では、プロセスはキャッシュをチェックし、当該のプロパティについての値を以前にキャッシュしているかどうかを判定する。通常は、検索を最適化するために当該のプロパティがキャッシュされる。処理は判定ブロック５０４に進む。
【００３８】
判定ブロック５０４では、当該のプロパティを以前にキャッシュしているかどうかについて判定を行う。当該のプロパティを以前にキャッシュしている場合、プロセスはキャッシュした値を使用し、ブロック５１２に進む。あるいは、プロセスはブロック５０６に進む。
【００３９】
ブロック５０６では、プロセスは、当該のプロパティについての式を評価する。前述のように、この式は、登録されたグローバル式でよく、または現ノードについてのグローバル式を上書きするローカル式でよい。グローバル式がローカル値を理解し、および式がローカルに格納される場合に式を評価する限りにおいて、ローカル式はグローバル式を上書きすることができる。これらの式は、プロパティシート、データベースフィールドなどの様々なソースを検索することを含むことができる。開発者はまた、評価メソッドを変更することにより、それに応じてソースの検索順序に優先順位を付けることもできる。ソースのうち１つが値を有すると、式は評価を停止する。しかし、従属部である各ソースもまた、ｇｅｔＶａｌｕｅプロセス５００の間に検索されるソースを有する。処理は判定ブロック５０８に進む。
【００４０】
判定ブロック５０８では、式プロセスが首尾よく値を計算したかどうかについて判定を行う。式プロセスが成功した場合、取り出された値が返され、プロセスはブロック５１２に進む。あるいは、式プロセスが成功しなかった場合、処理はブロック５１０に進む。
【００４１】
ブロック５１０では、当該のプロパティについてのデフォルト値を取り出す。デフォルト値は、当該のプロパティが登録されたときにプロパティ情報内に格納される。デフォルト値は、ｒｅｇｉｓｔｅｒＰｒｏｐｅｒｔｙコール内のパラメータとして渡される。処理はブロック５１２に進む。
【００４２】
ブロック５１２では、アプリケーションは、値を受け取ったときの式のステージ、値を決定する際に取得したホップの数などに基づいて重みメトリックを計算することができる。重みメトリックを格納し、後の検索を最適化する目的で当該のどのプロパティをキャッシュするかについて知的な判定を行うためにその重みメトリックを使用する。重みメトリックは、値を取り出すときに必要であったホップの数に基づく。ホップとは、コールされた各ｇｅｔＶａｌｕｅ（）メソッドを指す。次いで処理は終了する。
【００４３】
図６は、本発明による、登録されたプロパティについての値を設定するｓｅｔ　ｖａｌｕｅプロセスを示す論理的流れ図である。このプロセスはブロック６０１で始まる。ブロック６０１では、アプリケーションが実行中であり、プロパティが登録されている。処理はブロック６０２に進む。
【００４４】
ブロック６０２では、アプリケーションは当該のプロパティについてｓｅｔＶａｌｕｅ（）をコールする。始めに述べたように、各オブジェクトは共通インターフェース（例えばｇｅｔＶａｌｕｅ（）およびｓｅｔＶａｌｕｅ（））を提供するノードクラスから派生する。処理は判定ブロック６０４に進む。
【００４５】
判定ブロック６０４では、式がそれ自体で値の格納を処理したかどうかについて判定を行う。これにより、ノード上のローカル記憶域以外の別の位置に式が値を格納することが可能となる。例えば、式がデータバインディングをモデル化している場合、設定する必要のある値は外部のデータベース内に常駐する。したがって、式が外部のデータベース内の値を設定した後は、ブロック６０６および６０８を迂回し、式は、値の格納を処理したことをｓｅｔＶａｌｕｅに伝える。したがって、式が実際の値の格納を処理する場合、処理は終了に進む。そうでない場合、処理はブロック６０６に進む。
【００４６】
ブロック６０６では、ｓｅｔＶａｌｕｅ（）コールでパラメータとして提供された新しい値が、ｓｅｔＶａｌｕｅ（）コール中のパラメータとしても渡されたプロパティ識別子に関連するオブジェクト上にローカルに格納される。オブジェクトは一般に、オブジェクト内にローカルにオブジェクトのプロパティ用の記憶域を有さないので、新しい値を格納するために動的な記憶域を割り振ることができる。処理はブロック６０８に進む。
【００４７】
ブロック６０８では、ｎｏｔｉｆｙ　ｄｅｐｅｎｄｅｎｔｓプロセスを開始する。簡単に言えば、図７と共に後で詳細に説明するが、このｎｏｔｉｆｙ　ｄｅｐｅｎｄｅｎｔｓは、依存関係メカニズムを使用して、当該のプロパティがソースである各従属部を無効にする。前述のように、この無効化は、当該のプロパティに対する変更によって影響を受ける直接的従属部または間接的従属部が存在しなくなるまで行われる、反復的な性質のものである。次いで処理は完了する。
【００４８】
図７は、図６のｓｅｔ　ｖａｌｕｅプロセスで使用するのに適した例示的な報告プロセスを示す論理的流れ図である。処理はブロック７０１で始まる。ブロック７０１では、ソースについての値が既に変化している。処理はブロック７０２に進む。
【００４９】
ブロック７０２では、変更通知をキューに入れる。変更通知が特定のノード上の特定のプロパティに対して使用可能にされる場合、現在の値は常にキャッシュされる。これは、変更通知で使用される古い値を表す。したがって、キャッシュを消去する前に、古い値を変更通知内に格納する。次いで、新しい値を計算し、再キャッシュする。その後、通知はファイアする準備ができている。処理はブロック７０６に進む。
【００５０】
ブロック７０６では、当該のプロパティに関してキャッシュをクリアする。当該のあるプロパティについて、プロパティエンジンで維持されるキャッシュが、当該のプロパティについての値を含まない可能性があることを当業者なら理解するであろう。したがって、式が、キャッシュから当該のプロパティについての誤った値を意図せずに取り出すことがない。処理はブロック７０８に進む。
【００５１】
ブロック７０８では、従属プロバイダを起動する。この従属プロバイダは、式（すなわちｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔｓ）である。ｍａｒｋＤｅｐｅｎｄｅｎｔプロセスは、それ自体の他の従属部を有する従属部を「マーク」している可能性があるので、これらの他の従属部ごとのｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッドを起動する。これらの他の従属部のｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッドをそれぞれ起動したとき、新しいｍａｒｋＤｅｐｅｎｄｅｎｔプロセスが開始される。したがって、各ｍａｒｋＤｅｐｅｎｄｅｎｔプロセスは、異なる従属部に関して処理している。このプロセスの間、プロパティエンジンは、無効にしたプロパティのリストを維持し、そのプロパティのうちの１つが２回現れた場合、プロパティエンジンは、このソースに関連する従属関係が循環性であることを認識する。したがって、プロパティエンジンは循環性を遮断する。これは従来のプロパティシステムに勝る別の利点である。次いで処理は完了し、リターンに進む。
【００５２】
上記の仕様、例、およびデータにより、本発明の構成の製造および使用についての完全な説明が与えられる。本発明の精神および範囲から逸脱することなく、本発明の多数の実施形態を作成することができるので、本発明は、頭記の特許請求の範囲に属する。
【００５３】
以下に、本発明の拡張可能な性質を示す。この例（すなわちＤＢＢｉｎｄＥｘｐｒｅｓｓｉｏｎ）は、外部データベースフィールドについての値を設定し、取り出す２方向バインディングを示す。

【図面の簡単な説明】
【００５４】
【図１】本発明の１つの例示的実施形態で使用することのできる例示的コンピューティング装置を示す図である。
【図２】本発明による、プロパティシステムによってモデル化することのできるプロパティ関係の図式的表現である。
【図３】本発明の一実施形態による、依存関係メカニズムおよび評価メカニズムを与えるＥｘｐｒｅｓｓｉｏｎクラスについての例示的シンタックスを示す図である。
【図４】本発明による、ノードへの特定の共通インターフェースを提供するプログラミングモデルの図式的表現である。
【図５】本発明による、登録されたプロパティについての値を取り出すｇｅｔ　ｖａｌｕｅプロセスを示す論理的流れ図である。
【図６】本発明による、登録されたプロパティについての値を設定するｓｅｔ　ｖａｌｕｅプロセスを示す論理的流れ図である。
【図７】図６のｓｅｔ　ｖａｌｕｅプロセスで使用するのに適した例示的な報告プロセスを示す論理的流れ図である。
【符号の説明】
【００５５】
１００　コンピューティング装置
１０２　プロセッサ
１０４　メモリ
１０５　オペレーティングシステム
１０６　プログラムモジュール
１０７　プログラムデータ
１０９　リムーバブル記憶装置
１１０　ノンリムーバブル記憶装置
１１２　入力装置
１１４　出力装置
１１６　通信接続
１１８　他のコンピューティング装置
２１０　直接的関係
２２０　継承関係
２１２、２１４、２２２、２２４、２２６、２２８、２３０　ノード
２１６　Ｐｒｏｐｅｒｔｙ１
２１８、２３４、２３６、２３８、２４０　Ｐｒｏｐｅｒｔｙ２
３０２　コンストラクタ
３０４　ｅｖａｌｕａｔｅメソッド
３０６　ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド
３０８　ｓｅｔＶａｌｕｅメソッド
３１０　ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド
４００　ｅｘｐｒｅｓｓｉｏｎクラス、プログラミングモデル
４０２　ノードクラス
４０４　開発者オブジェクト
４０６　ｓｅｔＶａｌｕｅ（）メソッド
４０８　ｇｅｔＶａｌｕｅ（）メソッド
４１０、４１２　ｒｅｇｉｓｔｅｒＰｒｏｐｅｒｔｙコール
４２０　プロパティマネージャ
４３０　プロパティ情報ストア
４３２、４３４　プロパティエントリ
４３６　プロパティ識別子フィールド
４３８　式フィールド
４４０　式パラメータ

Claims (25)

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. 前記第１プロパティに依存する他のプロパティの値が、前記第１プロパティの前記値の変化に応答して無効にされることを特徴とする請求項２４に記載のコンピュータ可読媒体。

Images