(57)【特許請求の範囲】
【請求項１】
プロパティを管理するためのコンピュータ実行方法であって、
前記方法は、
オブジェクトプロパティおよびソースプロパティの間の関係を識別する式を確立するステップであって、前記オブジェクトプロパティは、前記ソースプロパティに従属する、ステップと、
前記ソースプロパティに関連付けられる第１の値に対する修正を受信するステップと、
前記オブジェクトプロパティに関連付けられる第２の値についての要求を受信するステップと、
前記要求および修正を受信したことに応答して、前記オブジェクトプロパティを無効にするステップと、
前記式を評価し、前記第２の値を得るステップであって、前記式は、循環性が前記オブジェクトプロパティおよびソースプロパティの間に存在するかどうかを判定すること、および前記循環性が存在する場合に前記循環性を停止させることによって、前記第１の値に基づいて評価される、ステップと、
前記式の評価に基づいて重みメトリックを計算するステップと、
前記重みメトリックに基づいて前記第２の値をキャッシュするかどうかを判定するステップと、
前記第２の値が前記ソースプロパティから得られる場合に、前記第２の値を返すことによって前記要求に応答するステップと
を備えることを特徴とする方法。
【請求項２】
前記第２の値が前記ソースプロパティから得られない場合に、デフォルト値を返すことによって前記要求に応答するステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記関係は、直接的関係、カプセル化関係、継承関係、データバインディング関係のうち１つを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記式を再評価し、前記修正に基づいて前記オブジェクトプロパティに関連付けられる第３の値を判定するステップであって、前記式は、前記オブジェクトプロパティに関連付けられる第２の値についての後続の要求に応答して再評価される、ステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項５】
前記オブジェクトプロパティを無効にするステップは、前記第２の値をキャッシュからクリアするステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項６】
前記第１の値および前記ソースプロパティを異なる場所に格納するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記第２の値および前記オブジェクトプロパティを異なる場所に格納するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記式を評価することは、前記ソースプロパティから前記第２の値を計算するステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項９】
前記オブジェクトプロパティに依存するプロパティを無効にするステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項１０】
前記式がグローバルである場合に、前記式を登録するステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項１１】
前記式がグローバルである場合に、前記式をローカル式でオーバーライドするステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項１２】
前記ソースプロパティに関連付けられるキャッシュから前記第２の値を得るステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項１３】
プロパティを管理するためのシステムであって、
第１のインターフェースおよび第２のインターフェースを公開するように構成されるプロパティエンジンと、
メモリに格納され、前記第１のインターフェースを介して前記プロパティエンジンと通信するソースプロパティと、
前記メモリに格納され、前記第２のインターフェースを介して前記プロパティエンジンと通信するオブジェクトプロパティであって、前記オブジェクトプロパティは、前記ソースプロパティに従属する、オブジェクトプロパティと
を備え、
プロセッサは、前記プロパティエンジンに、
オブジェクトプロパティおよびソースプロパティの間の関係を識別する式を確立することと、
前記ソースプロパティに関連付けられる第１の値に対する修正を受信することと、
前記オブジェクトプロパティに関連付けられる第２の値についての要求を受信することと、
前記要求および修正を受信したことに応答して、前記オブジェクトプロパティを無効にすることと、
前記式を評価し、前記第２の値を得ることであって、前記式は、循環性が前記オブジェクトプロパティおよびソースプロパティの間に存在するかどうかを判定すること、および前記循環性が存在する場合に前記循環性を停止させることによって、前記第１の値に基づいて評価される、ことと、
前記式の評価に基づいて重みメトリックを計算することと、
前記重みメトリックに基づいて前記第２の値をキャッシュするかどうかを判定することと、
前記第２の値が前記ソースプロパティから得られる場合に、前記第２の値を返すことによって前記要求に応答すること
を行わせることを特徴とするシステム。
【請求項１４】
前記プロパティエンジンは、前記式を再評価し、前記修正に基づいて前記オブジェクトプロパティに関連付けられる第３の値を判定するように構成され、前記式は、前記オブジェクトプロパティに関連付けられる第２の値についての後続の要求に応答して再評価されることを特徴とする請求項１３に記載のシステム。
【請求項１５】
プロパティを管理するためのコンピュータ実行可能命令を格納するコンピュータ読み取り可能な記憶媒体であって、
前記コンピュータ実行可能命令は、コンピュータによって実行される時に、コンピュータに、
オブジェクトプロパティおよびソースプロパティの間の関係を識別する式を確立するステップであって、前記オブジェクトプロパティは、前記ソースプロパティに従属する、ステップと、
前記ソースプロパティに関連付けられる第１の値に対する修正を受信するステップと、
前記オブジェクトプロパティに関連付けられる第２の値についての要求を受信するステップと、
前記要求および修正を受信したことに応答して、前記オブジェクトプロパティを無効にするステップと、
前記式を評価し、前記第２の値を得るステップであって、前記式は、循環性が前記オブジェクトプロパティおよびソースプロパティの間に存在するかどうかを判定すること、および前記循環性が存在する場合に前記循環性を停止させることによって、前記第１の値に基づいて評価される、ステップと、
前記式の評価に基づいて重みメトリックを計算するステップと、
前記重みメトリックに基づいて前記第２の値をキャッシュするかどうかを判定するステップと、
前記第２の値が前記ソースプロパティから得られる場合に、前記第２の値を返すことによって前記要求に応答するステップと
を備える方法を実行させることを特徴とするコンピュータ読み取り可能な記憶媒体。
【請求項１６】
前記式を再評価し、前記修正に基づいて前記オブジェクトプロパティに関連付けられる第３の値を判定するステップであって、前記式は、前記オブジェクトプロパティに関連付けられる第２の値についての後続の要求に応答して再評価される、ステップをさらに備えることを特徴とする請求項１５に記載のコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【背景技術】
【０００１】
今日、大部分のアプリケーションはオブジェクトを使用して書かれている。このオブジェクトは、第３者から供給を受けることができ、またはあるアプリケーション向けに特に開発することができる。オブジェクトを使用することにより、コードを容易に再利用することができ、および変更を行うことなく多数の異なるアプリケーションにコードを組み込むことができる。加えて、変更が必要な場合、オブジェクトの機能を継承する新しいオブジェクトを作成することができる。次いで、必要に応じてその新しいオブジェクトに新しい特定の機能を追加することができる。このように既存のオブジェクトを再利用および修正できることにより、新しいアプリケーションの開発時間が削減され、時には数ヶ月から数週間にまで削減されることもある。
【０００２】
しかし、オブジェクトの使用が非常に一般的になり、有益であるが、このオブジェクト中のプロパティを処理する現在の手法はいくつかの欠点を有する。例えば、オブジェクト中の第１のプロパティが別のオブジェクト中の第２のプロパティに依存する場合、開発者は、第２のプロパティを監視（すなわち聴取）し、それが変化したときに第１のプロパティを変更するコードを書かなければならない。この機能を実行する単純化したコードの一部は、以下のようなものである。
【０００３】
void Button1_OnPressedChanged(bool NewValue)
{      if(newValue == true)
{     BackgroundColor = Color.Red;
}
else
{     BackgroundColor = Color.Grey;
}
).
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記のように、このコールバック関数は、第１のプロパティ（例えばＢｕｔｔｏｎ１  Ｐｒｅｓｓｅｄ）が変化したときはいつでも、第２のプロパティ（すなわちＢａｃｋｇｒｏｕｎｄＣｏｌｏｒ）についての値を返す。したがって、第１のプロパティの状態が変化するごとに、コールバック中に値（例えば、赤色または灰色）が計算され、第２のプロパティ内に格納される。この技法は第２のプロパティについてのオブジェクト内に記憶域を必要とする。この記憶域は、第２のプロパティについての現状態を保つのに使用される。
【０００５】
開発者はこれらのオブジェクトを別々に開発することができるので、様々なオブジェクト内のプロパティの一部の間で循環が生じる可能性がある。例えば、上記の例で続けると、Ｂｕｔｔｏｎ１  Ｐｒｅｓｓｅｄプロパティの状態を変更する、ｂａｃｋｇｒｏｕｎｄＣｏｌｏｒプロパティについてのコールバック関数を追加することができる。ｂａｃｋｇｒｏｕｎｄＣｏｌｏｒが変化したためにｂｕｔｔｏｎ  ｐｒｅｓｓｅｄプロパティの状態を変更するコールバック関数を有することはあまり現実的ではなく、通常はアプリケーションで生じないが、２つのプロパティが互いの状態を変更するときに生じる問題を示す助けになる。実際のアプリケーションでは、通常、２つのパラメータは互いの状態を直接変更しないが、他の従属プロパティにより、この単純な例によって示される循環性が引き起こされる。したがって、上記の例が与えられた場合、実行時に、２つのプロパティの一方が状態を変更すると、両者は無期限に状態を変更し続けることになる。その場合、適切なオペレーションを行う前にこの循環性の問題を識別し、訂正しなければならない。遺憾ながら、プロパティ変化のあらゆる組合せをテストすることは非常に難しい。したがって、この循環性の問題の一部が、ソフトウェア製品をリリースした後になって表面化する可能性がある。
【０００６】
少なくともこれらの制約のために、オブジェクトのプロパティを処理する現在のモデルは理想的ではない。
【０００７】
本発明は、従属プロパティに関連するオペレーションが呼び出されるまで、第１プロパティの変化が従属プロパティに影響を及ぼさないようにオブジェクトのプロパティを処理するシステムおよび方法を目的とする。
【課題を解決するための手段】
【０００８】
したがって、オンデマンドタイプのプロパティシステムが提供される。より具体的には、このシステムおよび方法は、プロパティ間の関係を形式的に表現する依存関係メカニズムを提供する。この関係は、グローバルまたはローカルに適用することができる。依存関係メカニズムを使用して、このプロパティシステムはプロパティ間の関係を監視することができ、異なるプロパティ間の循環性を実行中に検出することができる。このシステムおよび方法はまた、登録されたプロパティのうちのいずれかについての値を計算する評価メカニズムを提供する。依存関係メカニズムと評価メカニズムは共に拡張可能であり、それにより、プロパティシステムが直接的関係、継承、逆継承、プロパティシート、カプセル化などのどんなタイプの関係もモデル化することが可能となる。
【０００９】
本発明の一利点は、ローカル記憶域に値を格納する必要がないことである。加えて、プロパティシステムがオンデマンドであるので、本発明のプロパティシステムは、速度やメモリ性能に関して、よりスケーラブルである。
【００１０】
本発明の別の利点は、開発中のプロパティを適切に処理するための複雑なリスナやコールバック関数をもはや開発者が書く必要がないことである。
【００１１】
本発明のさらに別の利点は、オブジェクト内のプロパティ用の記憶域の管理がより効率的になり、便利になることである。各オブジェクトインスタンスはもはや、そのオブジェクト内に各プロパティについてのローカル記憶域を有する必要がない。
【００１２】
本発明のさらに別の利点は、プロパティシステムが実行時にプロパティ間の循環性を検出し、この循環性を遮断することである。
【発明を実施するための最良の形態】
【００１３】
簡潔に述べると、本発明はオンデマンドプロパティシステムを提供する。このオンデマンドプロパティシステムは、従属プロパティに関連するオペレーションが呼び出されるまで、第１プロパティの変化が従属プロパティに影響を及ぼさないようにオブジェクトのプロパティを処理する。より具体的には、このシステムおよび方法は、プロパティ間の関係を形式的に表現する依存関係メカニズムを提供する。この関係は、グローバルまたはローカルに適用することができる。依存関係メカニズムを使用して、このプロパティシステムはプロパティ間の関係を監視することができ、異なるプロパティ間の循環性を実行中に検出することができる。このシステムおよび方法はまた、プロパティのうちのいずれかについての値を計算する評価メカニズムを提供する。プロパティシステムがオンデマンドであるので、ローカル記憶域に値を格納する必要がない。依存関係メカニズムと評価メカニズムは拡張可能であり、それにより、プロパティシステムが直接的関係、継承、逆継承、プロパティシート、カプセル化などのどんなタイプの関係もモデル化することが可能となる。本発明の上記その他の態様は、以下の詳細な説明を読んだ後に明らかになるであろう。
【００１４】
図１を参照すると、本発明を実施する１つの例示的システムは、コンピューティング装置１００などのコンピューティング装置を含む。非常に基本的な構成では、コンピューティング装置１００は一般に、少なくとも１つのプロセッサ１０２およびメモリ１０４を含む。コンピューティング装置の厳密な構成およびタイプに応じて、システムメモリ１０４は、揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはその２つの組合せとすることができる。システムメモリ１０４は、一般にオペレーティングシステム１０５、および１つまたは複数のプログラムモジュール１０６を含み、およびプログラムデータ１０７を含むことができる。プログラムモジュール１０６の例には、ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ  ＣｏｒｐｏｒａｔｉｏｎによるＶｉｓｕａｌ  Ｓｔｕｄｉｏ  ＩｎｔｅｌｌｉＳｅｎｓｅや、オブジェクトライブラリを使用する他のソフトウェアプログラミング環境が含まれる。加えて、プログラムモジュール１０６には、ソフトウェアプログラミング環境を使用して作成されたソフトウェアアプリケーションが含まれる。これらのソフトウェアアプリケーションがプロセッサ１０２上で実行されるとき、プロパティエンジンが、本発明によるソフトウェアアプリケーションを処理する。プロパティエンジンはオペレーティングシステム１０５の一部でよく、または別のプログラムモジュール１０６でよい。このコンピューティング装置１００の基本的構成を、図１では破線１０８内の構成要素によって示す。
【００１５】
コンピューティング装置１００は、追加の特徴または機能を有することができる。例えばコンピューティング装置１００は、例えば磁気ディスク、光ディスク、あるいはテープなどの（取外し可能および／または取外し不能な）追加のデータ記憶装置も含むことができる。図１では、このような追加の記憶装置をリムーバブル記憶装置１０９およびノンリムーバブル記憶装置１１０で示す。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶するための何らかの方法または技術で実装された、揮発性／不揮発性のリムーバブル／ノンリムーバブル媒体を含むことができる。システムメモリ１０４、リムーバブル記憶装置１０９、およびノンリムーバブル記憶装置１１０はすべて、コンピュータ記憶媒体の例である。コンピュータ記憶媒体には、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）、または他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、または他の磁気記憶装置、あるいは、所望の情報を記憶するのに使用することができ、コンピューティング装置１００でアクセスすることができる他のどんな媒体も含まれる。このようなどんなコンピュータ記憶媒体も装置１００の一部とすることができる。コンピューティング装置１００はまた、キーボード、マウス、ペン、音声入力装置、タッチ入力装置などの入力装置１１２も含むことができる。ディスプレイ、スピーカ、プリンタなどの出力装置１１４を含めることもできる。これらの装置は当技術分野で周知であり、ここで詳細に論じる必要はない。
【００１６】
コンピューティング装置１００はまた、ネットワーク経由などでその装置が他のコンピューティング装置１１８と通信することを可能にする通信接続１１６も含むことができる。通信接続１１６は通信媒体の一例である。通信媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータにより、搬送波または他の移送メカニズムなどの被変調データ信号として実施することができ、その通信媒体にはどんな情報送達媒体も含まれる。「被変調データ信号」という用語は、信号の特性集合のうちの１つまたは複数を有する信号、または情報を符号化するように変化する信号を意味する。例えば、限定はしないが、通信媒体には、ワイヤードネットワークまたはダイレクトワイヤード接続などのワイヤード媒体、ならびに音響媒体、ＲＦ媒体、赤外線媒体、および他のワイヤレス媒体などのワイヤレス媒体が含まれる。本明細書で使用するコンピュータ可読媒体という用語は、記憶媒体と通信媒体のどちらも含む。
【００１７】
図２は、本発明によるプロパティシステムの１つの例示的実装を説明する際に使用するプロパティ関係の図式的表現である。このプロパティ関係は、直接的関係２１０および継承関係２２０を含む。概略として、直接的関係２１０のプロパティ変化が、最終的に継承関係２２０内のプロパティに影響を及ぼす。図２にモデル化したプロパティ関係はプロパティ間の直接的関係および継承関係を表すが、本発明のプロパティシステムを、逆継承、データバインディング、カプセル化、プロパティシートなどの他の関係をモデル化するのに使用できることを当業者なら理解するであろう。したがって、図２にモデル化した関係を、本発明の機能の非限定的な例として示す。
【００１８】
直接的関係２１０は、２つのノード２１２および２１４を含む。以下の議論では、ノードとは、プロパティに作用させるためにプロパティエンジンに対して２つの共通インターフェースを公開するオブジェクトを指す。簡単に言えば、図４と共に後に詳細に説明するが、２つの共通インターフェースは、照会機能と１組の機能を含む。ノード２１２は、ボタンに関するＰｒｅｓｓｅｄプロパティなどのＰｒｏｐｅｒｔｙ１  ２１６を含む。ノード２１４は、ボタンの背景についてのＣｏｌｏｒプロパティなどのＰｒｏｐｅｒｔｙ２  ２１８を含む。始めに説明したように、従来のプロパティシステムは、Ｐｒｏｐｅｒｔｙ１  ２１６を監視するリスナ機能を実装し、Ｐｒｏｐｅｒｔｙ１  ２１６が変化したとき、従来のプロパティシステムはそれに応じてＰｒｏｐｅｒｔｙ２  ２１８を更新する。
【００１９】
しかし、対照的に本発明のプロパティシステムは、Ｐｒｏｐｅｒｔｙ１  ２１６とＰｒｏｐｅｒｔｙ２  ２１８の間の関係をモデル化する。この関係の場合、ノード２１２はノード２１４に対するソースとして指定される。ノード２１４は従属部と呼ばれる。一般には、ソースは別のノードに影響を及ぼすノードを表す。従属部は、別のノードの影響を受けるノードを表す。上記で示した例では、アプリケーション内の任意のオブジェクトは、Ｐｒｏｐｅｒｔｙ２  ２１８に作用させるために共通インターフェースの一方を使用することができる。簡単に言えば、後で図５および６と共にそれぞれ詳細に説明するｇｅｔＶａｌｕｅ（）メソッドおよびｓｅｔＶａｌｕｅ（）メソッドにより、すべてのノードによって共通インターフェースが提供されることが保証される。この共通インターフェースにより、プロパティエンジンおよび任意のオブジェクトが、共通インターフェースを使用して所望のプロパティにアクセスすることが可能となる。例えば、照会（すなわちｇｅｔＶａｌｕｅ）は、そのソースのうちの１つから、関係のある値を最終的に得る。図２に示す直接的関係２１０では、このソースはノード２１２である。したがって、ノード２１４内にＰｒｏｐｅｒｔｙ２  ２１８のためのローカル記憶域を必要とせずに、所望のオペレーションがオンデマンドで実行される。
【００２０】
継承関係２２０は、複数のノード２２２〜２３０を含む。ノードは、リーフノード（例えばノード２２４〜２３０）中のプロパティがリーフノードの継承プロパティである継承Ｐｒｏｐｅｒｔｙ２  ２３４〜２４０それぞれのためのローカル記憶域を必ずしも有さないことを除き、継承のために従来型の階層式に構築される。むしろ本発明によれば、これらのプロパティ２３４〜２４０についての値を照会および設定する２つの共通インターフェースを使用して、プロパティにオンデマンドに作用させる。
【００２１】
直接的関係２１０中のノード２１４と、継承関係２２０中のノード２２２が実際には同じノードであることに気付くであろう。このノードを別々に図示したのは、単に本発明がモデル化することのできる２つのタイプの関係を説明するのに好都合であるからに過ぎない。しかし、ノード２１４およびノード２２２は実際には同じであるので、アプリケーション内の任意のオブジェクトは、値を照会するなど子プロパティ（例えばＰｒｏｐｅｒｔｙ２  ２４０）に作用させるために、共通インターフェースの一方を使用することができる。この照会により、ノードのうちの１つから最終的に値が得られる。値の取得元のノードは直接的ソースでよく、またはノード２３０の直接的ソース（すなわちノード２２６）から間接的に導出された間接的ソースでよい。一部のノード（例えばノード２２６）がノード２２２に対する従属部としてのラベルであっても、その同じノードが別のノードに対するソースとなれることを当業者なら理解するであろう。例えば、ノード２２６は従属ノード２３０に対するソースである。これらのすべての依存関係は個々にモデル化することができる。
【００２２】
１つのノードがいくつかのソースを有することができ、その１つのノードがそれ自体、複数のノードに対するソースとなれることを当業者なら理解するであろう。これらの関係はそれぞれ、本発明に従ってモデル化される。しかし、関係がモデル化された後は、ソースのうち１つに対して、別のソースをそのソースに追加するなどの変更が行われた場合、元のノードを修正する必要はない。むしろ本発明によれば、元のノードはこの変更をほとんど認識せず、プロパティエンジンが、その変更に影響を及ぼすように必要な基礎的メカニズムを実行する。これにより、開発者に大きな利点がもたらされる。
【００２３】
直接的関係および継承関係をモデル化するときのプロパティシステムのオペレーションを概略的に説明したので、次に基礎的メカニズムを説明する。一般には、プロパティシステムは、他のプロパティに影響を及ぼす、あるプロパティに対する変更をプロパティエンジンが認識できるように、プロパティ間のこれらの関係を記述する依存関係メカニズム（例えばｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド）を提供する。加えて、プロパティシステムは、作用を受けているプロパティを評価する評価メカニズム（例えばｅｖａｌｕａｔｅメソッド）を提供する。本発明の一実施形態では、これらのメカニズムは共に、クラス（例えばＥｘｐｒｅｓｓｉｏｎクラス）を通じて提供される。
【００２４】
図３は、例示的なＥｘｐｒｅｓｓｉｏｎクラスの図式的表現である。このＥｘｐｒｅｓｓｉｏｎクラスは、コンストラクタ３０２、ｅｖａｌｕａｔｅメソッド３０４、ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６、およびｓｅｔＶａｌｕｅメソッド３０８を含む。加えて、Ｅｘｐｒｅｓｓｉｏｎクラスは、ソースがデータベースフィールドなどの外部であるときのための外部ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３１０を含むことができる。コンストラクタ３０２は、コンストラクタ３０２がｅｘｐｒｅｓｓｉｏｎオブジェクトを作成している対象の従属プロパティに対するソースを指定するソースパラメータ３０３を取る。したがってこのｅｘｐｒｅｓｓｉｏｎクラス３００は、ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６を介して依存関係メカニズムを提供し、Ｅｖａｌｕａｔｅメソッド３０４を介して評価メカニズムを提供する。開発者は、登録されたパラメータごとにｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６およびＥｖａｌｕａｔｅメソッド３０４を上書きする。ｅｖａｌｕａｔｅメソッド３０４、ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６、およびｓｅｔＶａｌｕｅメソッド３０８がそれぞれ、一方がノードを指定し、他方がプロパティＩＤを介してプロパティを指定する少なくとも２つのパラメータを有することに気付くであろう。
【００２５】
図２の継承関係を用いて続けると、１つの例示的Ｅｖａｌｕａｔｅメソッド３０４は以下のようなものでよい。
Object Evaluate (Node dependentNode, ID dependentID)
{
//親の値を返す
return (dependentNode.Parent.getValue(dependentID));
}
【００２６】
したがって、この上書きされたＥｖａｌｕａｔｅメソッド３０４は、パラメータとして渡されたオブジェクトの親からの値を返そうと試みる。ノードと、評価中の従属部に関連するｐｒｏｐｅｒｔｙＩＤがパラメータとして渡される。次いで値がそのソースから計算される。上記の継承の例では、そのソースは親を含む。しかし、親もモデル化され、上書きされたｅｖａｌｕａｔｅメソッドを有するので、評価プロセスは、最終的に値が返されるまで、ツリーの上方に向かって、他のソースまで続く可能性がある。図２では、ｇｅｔＶａｌｕｅがノード２１２に対して実行されるときにこのことが生じる。値を得るための検索経路を決定する責任を開発者が負うことを当業者なら理解するであろう。例えば上記の継承の例では、ノード２２２に関連するｅｖａｌｕａｔｉｏｎメソッドはデフォルト値を提供することができる。したがってｅｘｐｒｅｓｓｉｏｎクラスにより、どこから値を得るべきかを決定し、およびどのシーケンスを検索するかを決定する際に、評価メカニズムを非常に拡張的にすることが可能となることを当業者なら理解するであろう。
【００２７】
ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６もまた、形式的な依存関係をプロパティシステムに対して指定するために開発者により上書きされる。簡単に言えば、図６および７の流れ図と共により詳細に説明するが、ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６は、変更されたソースを有する各従属部を無効にすることを担う。従属部のうちの１つがソースである場合、そのソースに対するｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッドが起動され、その従属部が無効にされる。したがって、ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔプロセスは、変更の影響を受けるすべての関係を無効にするまで再帰的に続行する。一実施形態では、プロパティエンジンによって提供されるインターフェース（例えばＮｏｄｅ．ＭａｒｋＤｅｐｅｎｄｅｎｔ（ＰｒｏｐｅｒｔｙＩＤ））によって従属部が無効とマークされる。以下は、図２で説明した継承関係についての例示的な上書きされたｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６である。
【００２８】
【表１】
0005279979.tif 000002
【００２９】
【表２】
0005279979.tif 000003
【００３０】
したがって、この例示的な上書きされたｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド３０６では、あらゆる子に関するＰｒｏｐｅｒｔｙ２が無効にされる。加えて、ノードの親プロパティが変化した場合、あらゆる子に関する、継承されたあらゆるプロパティを無効とマークしなければならない。本発明の別の改良では、一実施形態において、いくつかのプロパティをすぐに無効にする特別な無効化メソッドが提供される。
【００３１】
前述のように、プロパティシステムがこの形式的依存関係を提供するために、特定の共通ＡＰＩが各ノードで利用可能にされる。これらの共通ＡＰＩにより、プロパティエンジンおよび任意のオブジェクトが共通インターフェース（例えばＡＰＩ）を使用して所望のプロパティにアクセスすることが可能となる。
【００３２】
図４は、本発明による、特定の共通インターフェースをノードに提供するプログラミングモデル４００の図式的表現である。以下の議論では、オブジェクトという用語は、クラスのインスタンスを指すのに用いる。各オブジェクトについて、オブジェクトがインスタンス化される元のクラスが存在することを当業者なら理解するであろう。さらに、オブジェクトは複数のクラスから導出された機能を有することができる。プログラミングモデル４００はノードクラス４０２を提供する。プロパティエンジンはノードクラス４０２について認識している。ノードクラス４０２は、ｓｅｔＶａｌｕｅ（）メソッド４０６およびｇｅｔＶａｌｕｅ（）メソッド４０８を含む。ｓｅｔＶａｌｕｅ（）メソッド４０６およびｇｅｔＶａｌｕｅ（）メソッド４０８は、各ノードによって提供される共通インターフェースを表す。開発者オブジェクト４０４は、ノードクラス４０２（すなわちｓｅｔＶａｌｕｅ（）メソッド４０６およびｇｅｔＶａｌｕｅ（）メソッド４０８）によって提供される機能を継承する。開発者オブジェクト４０４は、１つまたは複数のプロパティ（例えばＰｒｏｐｅｒｔｙ１およびＰｒｏｐｅｒｔｙ２）を含むことができる。開発者オブジェクト４０４内では、命令が書き込まれ、ｒｅｇｉｓｔｅｒＰｒｏｐｅｒｔｙコール（例えばｒｅｇｉｓｔｅｒＰｒｏｐｅｒｔｙコール４１０および４１２）を使用して１つまたは複数の各プロパティが登録される。
【００３３】
ｒｅｇｉｓｔｅｒＰｒｏｐｅｒｔｙメソッド４２２は、プロパティエンジン内のプロパティマネージャ４２０によって提供される。プロパティマネージャ４２０は、登録されたプロパティ（例えばＰｒｏｐｅｒｔｙ１およびＰｒｏｐｅｒｔｙ２）を管理し、登録されたプロパティに関する関連情報がプロパティ情報ストア４３０に格納される。プロパティ情報ストア４３０は、図１に示すコンピュータシステム１００内のメモリに常駐する。あるいは、プロパティ情報ストア４３０の一部をキャッシュしたり、記憶媒体上に格納したりすることができる。プロパティ情報ストア４３０は、登録されたプロパティごとのプロパティエントリ（例えばプロパティエントリ４３２および４３４）を含む。本発明によれば、プロパティエントリ４３４は、プロパティ識別子フィールド４３６および式フィールド４３８を含む。加えて、プロパティエントリ４３４は、名前フィールド、タイプフィールド、デフォルト値フィールドなどの、登録されたプロパティに関係する他のフィールドを含むことができる。デフォルト値フィールドは、プロパティについてのデフォルト値を格納する。このデフォルト値は、式がソースから値を計算することができない場合に使用される。
【００３４】
プロパティエントリ４３４は、登録されたプロパティごとにプロパティ識別子フィールド４３６内に固有プロパティ識別子を格納する。一実施形態では、固有プロパティ識別子は、ＲｅｇｉｓｔｅｒＰｒｏｐｅｒｔｙ（）によって生成される。式フィールド４３８は、固有プロパティ識別子に関連する導出式オブジェクトを格納する。この導出式オブジェクトは、レジスタプロパティコール（例えばレジスタプロパティコール４１０および４１２）中の式パラメータ４４０から得られる。前述のように、導出式オブジェクトは、上書きされたｅｖａｌｕａｔｅ（）メソッドおよび上書きされたｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔ（）メソッドを含む。したがって、各プロパティを登録した後は、依存関係メカニズムおよび評価メカニズムは、登録されたプロパティに関連する導出式オブジェクトを介してグローバルに利用可能である。別の実施形態では、グローバル式をローカル式で上書きすることができる。ローカル式は、ローカル値について認識している式によって提供される。これらのローカル式は、ノードクラス中のプロパティエンジンによって提供されるｒｅａｄＬｏｃａｌＶａｌｕｅを使用して、ローカル値を取り出す。したがってローカル式により、ノード上にローカルに格納された値を取り出すことが可能となる。
【００３５】
ノードクラス４０２が、ｒｅａｄＬｏｃａｌＶａｌｕｅ（）メソッド（図示せず）およびｗｒｉｔｅＬｏｃａｌＶａｌｕｅ（）メソッド（図示せず）などの内部で使用される追加のメソッドも提供することを当業者なら理解するであろう。一実施形態では、ｒｅａｄＬｏｃａｌＶａｌｕｅ（）メソッドは、前述のようなローカル式によって使用される。ローカル式はｇｅｔＶａｌｕｅによって間接的に呼び出される。ｗｒｉｔｅＬｏｃａｌＶａｌｕｅ（）は、ｓｅｔＶａｌｕｅ（）メソッド４０６によって使用される。式が、「子」の式に関連するｅｖａｌｕａｔｅ（）メソッドを「親」の式が呼び出す他の式を含むことを当業者はさらに理解されよう。「子」の式は、親の式に対する間接的ソースと呼ばれる。
【００３６】
図５は、本発明による、登録されたプロパティについての値を取り出す例示的ｇｅｔＶａｌｕｅプロセスを示す論理的流れ図である。処理はブロック５０１で始まり、ブロック５０１では、プロパティ（以後、当該のプロパティと呼ぶ）に関する照会を開始する。処理はブロック５０２に進む。
【００３７】
ブロック５０２では、プロセスはキャッシュをチェックし、当該のプロパティについての値を以前にキャッシュしているかどうかを判定する。通常は、検索を最適化するために当該のプロパティがキャッシュされる。処理は判定ブロック５０４に進む。
【００３８】
判定ブロック５０４では、当該のプロパティを以前にキャッシュしているかどうかについて判定を行う。当該のプロパティを以前にキャッシュしている場合、プロセスはキャッシュした値を使用し、ブロック５１２に進む。あるいは、プロセスはブロック５０６に進む。
【００３９】
ブロック５０６では、プロセスは、当該のプロパティについての式を評価する。前述のように、この式は、登録されたグローバル式でよく、または現ノードについてのグローバル式を上書きするローカル式でよい。グローバル式がローカル値を理解し、および式がローカルに格納される場合に式を評価する限りにおいて、ローカル式はグローバル式を上書きすることができる。これらの式は、プロパティシート、データベースフィールドなどの様々なソースを検索することを含むことができる。開発者はまた、評価メソッドを変更することにより、それに応じてソースの検索順序に優先順位を付けることもできる。ソースのうち１つが値を有すると、式は評価を停止する。しかし、従属部である各ソースもまた、ｇｅｔＶａｌｕｅプロセス５００の間に検索されるソースを有する。処理は判定ブロック５０８に進む。
【００４０】
判定ブロック５０８では、式プロセスが首尾よく値を計算したかどうかについて判定を行う。式プロセスが成功した場合、取り出された値が返され、プロセスはブロック５１２に進む。あるいは、式プロセスが成功しなかった場合、処理はブロック５１０に進む。
【００４１】
ブロック５１０では、当該のプロパティについてのデフォルト値を取り出す。デフォルト値は、当該のプロパティが登録されたときにプロパティ情報内に格納される。デフォルト値は、ｒｅｇｉｓｔｅｒＰｒｏｐｅｒｔｙコール内のパラメータとして渡される。処理はブロック５１２に進む。
【００４２】
ブロック５１２では、アプリケーションは、値を受け取ったときの式のステージ、値を決定する際に取得したホップの数などに基づいて重みメトリックを計算することができる。重みメトリックを格納し、後の検索を最適化する目的で当該のどのプロパティをキャッシュするかについて知的な判定を行うためにその重みメトリックを使用する。重みメトリックは、値を取り出すときに必要であったホップの数に基づく。ホップとは、コールされた各ｇｅｔＶａｌｕｅ（）メソッドを指す。次いで処理は終了する。
【００４３】
図６は、本発明による、登録されたプロパティについての値を設定するｓｅｔ  ｖａｌｕｅプロセスを示す論理的流れ図である。このプロセスはブロック６０１で始まる。ブロック６０１では、アプリケーションが実行中であり、プロパティが登録されている。処理はブロック６０２に進む。
【００４４】
ブロック６０２では、アプリケーションは当該のプロパティについてｓｅｔＶａｌｕｅ（）をコールする。始めに述べたように、各オブジェクトは共通インターフェース（例えばｇｅｔＶａｌｕｅ（）およびｓｅｔＶａｌｕｅ（））を提供するノードクラスから派生する。処理は判定ブロック６０４に進む。
【００４５】
判定ブロック６０４では、式がそれ自体で値の格納を処理したかどうかについて判定を行う。これにより、ノード上のローカル記憶域以外の別の位置に式が値を格納することが可能となる。例えば、式がデータバインディングをモデル化している場合、設定する必要のある値は外部のデータベース内に常駐する。したがって、式が外部のデータベース内の値を設定した後は、ブロック６０６および６０８を迂回し、式は、値の格納を処理したことをｓｅｔＶａｌｕｅに伝える。したがって、式が実際の値の格納を処理する場合、処理は終了に進む。そうでない場合、処理はブロック６０６に進む。
【００４６】
ブロック６０６では、ｓｅｔＶａｌｕｅ（）コールでパラメータとして提供された新しい値が、ｓｅｔＶａｌｕｅ（）コール中のパラメータとしても渡されたプロパティ識別子に関連するオブジェクト上にローカルに格納される。オブジェクトは一般に、オブジェクト内にローカルにオブジェクトのプロパティ用の記憶域を有さないので、新しい値を格納するために動的な記憶域を割り振ることができる。処理はブロック６０８に進む。
【００４７】
ブロック６０８では、ｎｏｔｉｆｙ  ｄｅｐｅｎｄｅｎｔｓプロセスを開始する。簡単に言えば、図７と共に後で詳細に説明するが、このｎｏｔｉｆｙ  ｄｅｐｅｎｄｅｎｔｓは、依存関係メカニズムを使用して、当該のプロパティがソースである各従属部を無効にする。前述のように、この無効化は、当該のプロパティに対する変更によって影響を受ける直接的従属部または間接的従属部が存在しなくなるまで行われる、反復的な性質のものである。次いで処理は完了する。
【００４８】
図７は、図６のｓｅｔ  ｖａｌｕｅプロセスで使用するのに適した例示的な報告プロセスを示す論理的流れ図である。処理はブロック７０１で始まる。ブロック７０１では、ソースについての値が既に変化している。処理はブロック７０２に進む。
【００４９】
ブロック７０２では、変更通知をキューに入れる。変更通知が特定のノード上の特定のプロパティに対して使用可能である場合、現在の値が常にキャッシュされている。現在の値は、変更通知で使用される古い値、すなわち変更される前の値を表す。次いで、ブロック５０６と同様にプロパティの新しい値を計算し、その新しい値をキャッシュに再登録（更新）する。変更前の古い値をキャッシュから消去する前に、その古い値を変更通知内に含めておく。これで、変更通知の発信準備が完了する。処理はブロック７０６に進む。
【００５０】
ブロック７０６では、当該のプロパティに関してキャッシュをクリアする。当該のあるプロパティについて、プロパティエンジンで維持されるキャッシュが、当該のプロパティについての値を含まない可能性があることを当業者なら理解するであろう。したがって、式が、キャッシュから当該のプロパティについての誤った値を意図せずに取り出すことがない。処理はブロック７０８に進む。
【００５１】
ブロック７０８では、従属プロバイダを起動する。この従属プロバイダは、式（すなわちｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔｓ）である。ｍａｒｋＤｅｐｅｎｄｅｎｔプロセスは、それ自体の他の従属部を有する従属部を「マーク」している可能性があるので、これらの他の従属部ごとのｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッドを起動する。これらの他の従属部のｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッドをそれぞれ起動したとき、新しいｍａｒｋＤｅｐｅｎｄｅｎｔプロセスが開始される。したがって、各ｍａｒｋＤｅｐｅｎｄｅｎｔプロセスは、異なる従属部に関して処理している。このプロセスの間、プロパティエンジンは、無効にしたプロパティのリストを維持し、そのプロパティのうちの１つが２回現れた場合、プロパティエンジンは、このソースに関連する従属関係が循環性であることを認識する。したがって、プロパティエンジンは循環性を遮断する。これは従来のプロパティシステムに勝る別の利点である。次いで処理は完了し、リターンに進む。
【００５２】
上記の仕様、例、およびデータにより、本発明の構成の製造および使用についての完全な説明が与えられる。本発明の精神および範囲から逸脱することなく、本発明の多数の実施形態を作成することができるので、本発明は、頭記の特許請求の範囲に属する。
【００５３】
以下に、本発明の拡張可能な性質を示す。この例（すなわちＤＢＢｉｎｄＥｘｐｒｅｓｓｉｏｎ）は、外部データベースフィールドについての値を設定し、取り出す２方向バインディングを示す。
// DBBindExpression (インスタンスベースのExpression)
internal class DBBindExpression : Expression
{
public DBBindExpression(string pretendDBFieldID):
base(Source.External(), //プロパティエンジン内のpretend DBフィールドを表す
ExpressionOptions.AutoReport) // ソース変更に対する自動レポート添付dep
change
{
// Source.External()は、プロパティエンジン中のpretendDBFieldIDについての
// 識別を与える「ExternalSource」オブジェクトを自動的に作成する。
// 作成されるExternalSourceオブジェクトは、GetSourceES(0)
// (リスト中の最初のもの、すなわち0)を介してアクセスされる。
}
// N[DP] = ExSrc(DBField)
public override object Evaluate(Node n, PropertyID dp)
{// 従属DPは「string」タイプでなければならない。
return pretendDBField;
}
// SetValueコールをDBFieldにプッシュする (フィールドを無効にする)
public override bool SetValue(Node n, PropertyID dp, object o)
{
WriteDBField((string)o);
// この式によって処理されるSetValue
return true;
}
// DBFieldの直接書込みをシミュレートする
public void WriteDBField(string newFieldValue)
{
// pretendデータベースに書き込む
pretendDBField = newFieldValue;
// 外部ソースを無効にする
GetSourceES(0).InvalidateExternal();
}
private string pretendDBField; //「pretendDBFieldID」についての物理的記憶域を表す
【図面の簡単な説明】
【００５４】
【図１】本発明の１つの例示的実施形態で使用することのできる例示的コンピューティング装置を示す図である。
【図２】本発明による、プロパティシステムによってモデル化することのできるプロパティ関係の図式的表現である。
【図３】本発明の一実施形態による、依存関係メカニズムおよび評価メカニズムを与えるＥｘｐｒｅｓｓｉｏｎクラスについての例示的シンタックスを示す図である。
【図４】本発明による、ノードへの特定の共通インターフェースを提供するプログラミングモデルの図式的表現である。
【図５】本発明による、登録されたプロパティについての値を取り出すｇｅｔ  ｖａｌｕｅプロセスを示す論理的流れ図である。
【図６】本発明による、登録されたプロパティについての値を設定するｓｅｔ  ｖａｌｕｅプロセスを示す論理的流れ図である。
【図７】図６のｓｅｔ  ｖａｌｕｅプロセスで使用するのに適した例示的な報告プロセスを示す論理的流れ図である。
【符号の説明】
【００５５】
１００  コンピューティング装置
１０２  プロセッサ
１０４  メモリ
１０５  オペレーティングシステム
１０６  プログラムモジュール
１０７  プログラムデータ
１０９  リムーバブル記憶装置
１１０  ノンリムーバブル記憶装置
１１２  入力装置
１１４  出力装置
１１６  通信接続
１１８  他のコンピューティング装置
２１０  直接的関係
２２０  継承関係
２１２、２１４、２２２、２２４、２２６、２２８、２３０  ノード
２１６  Ｐｒｏｐｅｒｔｙ１
２１８、２３４、２３６、２３８、２４０  Ｐｒｏｐｅｒｔｙ２
３０２  コンストラクタ
３０４  ｅｖａｌｕａｔｅメソッド
３０６  ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド
３０８  ｓｅｔＶａｌｕｅメソッド
３１０  ｒｅｐｏｒｔＤｅｐｅｎｄｅｎｔメソッド
４００  ｅｘｐｒｅｓｓｉｏｎクラス、プログラミングモデル
４０２  ノードクラス
４０４  開発者オブジェクト
４０６  ｓｅｔＶａｌｕｅ（）メソッド
４０８  ｇｅｔＶａｌｕｅ（）メソッド
４１０、４１２  ｒｅｇｉｓｔｅｒＰｒｏｐｅｒｔｙコール
４２０  プロパティマネージャ
４３０  プロパティ情報ストア
４３２、４３４  プロパティエントリ
４３６  プロパティ識別子フィールド
４３８  式フィールド
４４０  式パラメータ
【図１】
0005279979.tif 000004
【図２】
0005279979.tif 000005
【図３】
0005279979.tif 000006
【図４】
0005279979.tif 000007
【図５】
0005279979.tif 000008
【図６】
0005279979.tif 000009
【図７】
0005279979.tif 000010