(57)【要約】【課題】プロデューサグラフ指向のプログラミング及び実行のための方法及び装置を提供する。【解決手段】本発明の１つの態様によれば、メソッドに対するプロデューサ依存性宣言を解釈するランタイム(runtime)が提供される。プロデューサ依存性宣言は、ランタイム時(run time)に、０以上のプロデューサのセットを識別し、ここで、プロデューサとは、少なくともインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトである。ランタイムは、メソッドがプロデューサ依存性宣言を有するところの問題とするプロデューサの指定を受け取るのに応答して、プロデューサグラフを自動的に発生して実行する。プロデューサグラフは、最初、問題とするプロデューサを含み、そしてプロデューサグラフに既にあるプロデューサのメソッドのプロデューサ依存性宣言に基づいてプロデューサのインスタンス生成を通してその問題とするプロデューサからソースプロデューサへと発生される。ランタイムは、プロデューサグラフにより指示されるようにプロデューサグラフ内のプロデューサの実行をシーケンシングする。【選択図】図２
2010511234.tif 000002
【特許請求の範囲】
【請求項１】
オブジェクト指向のコードを実行するための装置において、
オブジェクト指向のコードにおけるメソッドに対するプロデューサ依存性宣言を解釈するランタイム(runtime)を備え、前記プロデューサ依存性宣言は、ランタイム(run time)時に、０以上のプロデューサのセットを識別し、プロデューサは、少なくともインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであり、前記ランタイムは、
問題とするプロデューサの指定を受け取り、その問題とするプロデューサをプロデューサグラフの一部分として追加し、そして前記プロデューサグラフに既にあるプロデューサのメソッドのプロデューサ依存性宣言に基づいて他のプロデューサをリンクし且つ必要に応じてインスタンス生成することにより前記プロデューサグラフの残り部分を自動的に発生するための自動プロデューサグラフ発生モジュールと、
前記プロデューサグラフによって指示された順序で前記プロデューサグラフにおけるプロデューサを実行するためのプロデューサグラフ実行モジュールであって、各プロデューサの実行で、そのプロデューサのメソッドがそのプロデューサのインスタンスにおいて実行されることになるプロデューサグラフ実行モジュールと、
を備えた装置。
【請求項２】
前記自動プロデューサグラフ発生モジュールは、最初に、前記プロデューサグラフの幾つかのプロデューサが実行されるまで、前記プロデューサグラフの発生を完了することができず、前記プロデューサグラフ実行モジュールは、前記プロデューサグラフの未解明の残り部分を完了するために前記プロデューサグラフの実行中に必要なプロデューサ出力で前記自動プロデューサグラフ発生モジュールをインボークする、請求項１に記載の装置。
【請求項３】
前記プロデューサ依存性宣言の少なくとも１つによりランタイム時に識別される前記プロデューサのセットは、そのプロデューサ依存性宣言のメソッドを含むプロデューサの実行前に実行されるべき少なくとも１つのプロデューサを含む、請求項１に記載の装置。
【請求項４】
前記プロデューサグラフは、そのプロデューサグラフにおけるプロデューサのメソッドのプロデューサ依存性宣言により識別される適切な実行シーケンスを表す、請求項１に記載の装置。
【請求項５】
所与のメソッドに対して前記プロデューサ依存性宣言の少なくとも１つによりランタイム時に識別される前記プロデューサのセットは、前記所与のメソッドへの直接的な入力である出力をもつ少なくとも１つのプロデューサを含む、請求項１に記載の装置。
【請求項６】
前記プロデューサグラフは、問題とするプロデューサから、前記プロデューサグラフのエンドノードであるプロデューサまで、プロデューサの互いの直接的な入力対出力依存性を表す、請求項１に記載の装置。
【請求項７】
前記ランタイムは、更に、
前記プロデューサグラフの現在バージョンにおける１つ以上のプロデューサの出力に対する現在変更を受け取るためのオーバーライドプロデューサ出力モジュールと、
前記自動プロデューサグラフ発生モジュールに結合されて、前記プロデューサグラフの現在バージョン及び現在プロデューサグラフにおける各プロデューサの現在出力を記憶するためのプロデューサグラフ構造と、
を備え、前記プロデューサグラフ実行モジュールは、前記オーバーライドプロデューサ出力モジュール及び前記プロデューサグラフ構造に結合されて、前記現在変更を行い、その現在変更により間接的に影響を受けるために前記プロデューサグラフの現在バージョンにおけるどのプロデューサを実行する必要があるか追跡し、そして前記プロデューサグラフの現在バージョンの一貫性を維持するために現在実行を必要とするプロデューサグラフの現在バージョンのプロデューサのみを実行する、請求項１に記載の装置。
【請求項８】
前記プロデューサグラフ構造は、更に、
現在変更のために前記プロデューサグラフの現在バージョンにおけるどのプロデューサを再実行する必要があるか追跡することで前記プロデューサグラフ実行モジュールを助けるための増分的実行マーキング構造、
を備えた請求項７に記載の装置。
【請求項９】
前記オーバーライドプロデューサ出力モジュール及び前記プロデューサグラフ実行モジュールに結合されて、バッチ処理のために複数のオーバーライドを収集するオーバーライドログを更に備えた、請求項７に記載の装置。
【請求項１０】
前記オーバーライドプロデューサ出力モジュールは、１つ以上のオーバーライドされた出力を非オーバーライドすべきであるという指示も受け取る、請求項７に記載の装置。
【請求項１１】
前記ランタイムは、更に、
前記自動プロデューサグラフ発生モジュールに結合されて、バッチ処理のために複数のコマンドを一緒に収集するコマンドログ、
を備えた請求項１に記載の装置。
【請求項１２】
各プロデューサのメソッドは、そのプロデューサのインスタンスのクラスのメソッドである、請求項１に記載の装置。
【請求項１３】
前記プロデューサ依存性宣言は、オブジェクト指向のコードにおけるクラスに対するクラス定義の一部分である、請求項１２に記載の装置。
【請求項１４】
メソッドは、前記プロデューサ依存性宣言の１つを有する、請求項１に記載の装置。
【請求項１５】
前記ランタイムは、手動インボケーションシーケンスコードの必要性に取って代わり、各プロデューサのメソッドは、変換メソッドであり、そして前記ランタイムは、前記プロデューサ依存性宣言からこれら変換メソッドに対するシーケンスを発見する、請求項１に記載の装置。
【請求項１６】
前記プロデューサグラフのエンドノードは、独立したプロデューサである、請求項１に記載の装置。
【請求項１７】
前記ランタイムは、更に、
前記自動プロデューサグラフ発生モジュール及び前記プロデューサグラフ実行モジュールに結合されて、前記プロデューサのインスタンスに対するリファレンスを記憶するためのインスタンス追跡構造と、
前記自動プロデューサグラフ発生モジュール及び前記プロデューサグラフ実行モジュールに結合されて、前記プロデューサのメソッドに対するリファレンス及びそれらのプロデューサ依存性宣言に関する情報を記憶するメソッド追跡構造と、
を備えた請求項１に記載の装置。
【請求項１８】
前記ランタイムは、更に、
前記インスタンス追跡構造に結合され、現在選択された問題とするプロデューサの指定を受け取り且つ必要に応じてそれをインスタンス生成する新インスタンスモジュールと、
クラスに対するリファレンスを追跡するためのクラス追跡構造と、
前記クラス追跡構造に結合されて、クラス定義をロードし且つイントロスペクトするための新クラスモジュールと、
を備えた請求項１７に記載の装置。
【請求項１９】
前記ランタイムは、更に、現在プロデューサグラフの表現をグラフ表示するためのプロデューサグラフビューアモジュールを備えた、請求項１に記載の装置。
【請求項２０】
前記ランタイムは、更に、前記プロデューサグラフからの出力をグラフ表示しそしてそのプロデューサグラフとのインタラクションを許すための構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュールを備えた、請求項１に記載の装置。
【請求項２１】
前記プロデューサグラフ実行モジュールは、ダイナミックプロデューサ依存性を解明するためのダイナミック依存性モジュールを備え、各プロデューサ依存性宣言は、ダイナミックプロデューサ依存性を含み、そのダイナミックプロデューサ依存性は、プロデューサ依存性宣言がランタイム中に識別する０以上のプロデューサのセットをランタイムがダイナミックに選択するようにさせ、そしてこのダイナミックな選択は、前記プロデューサグラフの異なる実行中に前記セットに対して異なるプロデューサの選択を行わせることができる、請求項１に記載の装置。
【請求項２２】
前記ダイナミックプロデューサ依存性は、コンティンジェントプロデューサ依存性を含み、そのコンティンジェントプロデューサ依存性は、依存性決定プロデューサに依存し、この依存性決定プロデューサそれ自身は、１つ以上の他のプロデューサの出力に依存する、請求項２１に記載の装置。
【請求項２３】
前記ダイナミックプロデューサ依存性は、サブスクリプションを含み、このサブスクリプションは、プロデューサがトリガープロデューサであるかどうか決定するためにプロデューサを比較する基準を識別し、更に、このサブスクリプションは、トリガープロデューサに対する依存性を識別する、請求項２１に記載の装置。
【請求項２４】
前記サブスクリプションの幾つかは、アブソービングサブスクリプションであり、このアブソービングサブスクリプションは、プロデューサ依存性宣言がランタイム中に識別する０以上のプロデューサのセットにトリガープロデューサを前記ランタイムがダイナミックに含ませるようにさせる、請求項２３に記載の装置。
【請求項２５】
前記サブスクリプションの幾つかは、スティッキーサブスクリプションであり、このスティッキーサブスクリプションは、親プロデューサの特性も識別し、更に、このスティッキーサブスクリプションは、探索される各トリガープロデューサに対して、前記ランタイムが、その識別された特性を満足する親プロデューサをインスタンス生成し、且つそれを、そのトリガープロデューサに対するプロデューサ依存性を有するものとしてプロデューサグラフに含ませるようにさせる、請求項２３に記載の装置。
【請求項２６】
前記０以上のプロデューサの幾つかは、その実行でプロデューサの互いの依存性の識別を返送する依存性決定プロデューサである、請求項１に記載の装置。
【請求項２７】
幾つかの前記依存性決定プロデューサの実行は、上方に宣言された依存性を返送する、請求項２６に記載の装置。
【請求項２８】
前記プロデューサグラフによって表わされた依存性の少なくとも幾つかは、引数依存性及びフィールド依存性として指定され、その引数依存性は、前記ランタイムが、子プロデューサの出力を親プロデューサへの入力パラメータとしてマップするようにさせ、そしてそのフィールド依存性は、インスタンスのフィールドの使用を指示する、請求項１に記載の装置。
【請求項２９】
前記プロデューサグラフにより表わされた依存性の少なくとも幾つかは、シーケンスのみの依存性として指定され、このシーケンスのみの依存性は、所与のメカニズムへ出力を書くための子プロデューサのメソッドにおけるコード、及び所与のメカニズムから出力を読むための親プロデューサのメソッドにおけるコードを通して、子プロデューサから親プロデューサへ与える必要のある出力がもしあればそれが発生することを要求する、請求項１に記載の装置。
【請求項３０】
メソッドキーを使用してメソッドを区別し、インスタンスキーを使用して、インスタンスを区別し、プロデューサキーを使用して、プロデューサを区別し、各プロデューサのプロデューサキーは、少なくとも、そのプロデューサのインスタンス及びメソッドのインスタンスキー及びメソッドキーに基づく、請求項１に記載の装置。
【請求項３１】
前記インスタンスは、複数のクラスのインスタンスであり、前記クラスキーは、前記複数のクラスを区別するのに使用され、各プロデューサのプロデューサキーは、そのプロデューサのインスタンスのクラスのクラスキーにも基づく、請求項３０に記載の装置。
【請求項３２】
少なくとも幾つかのプロデューサのインスタンスキーは、プロデューサのインスタンスに対するリファレンスを保持する、請求項３０に記載の装置。
【請求項３３】
前記プロデューサ依存性宣言の少なくとも幾つかは、上方に宣言された依存性を含む、請求項１に記載の装置。
【請求項３４】
前記プロデューサ依存性宣言の少なくとも幾つかは、下方に宣言された依存性を含む、請求項１に記載の装置。
【請求項３５】
前記プロデューサ依存性宣言の少なくとも幾つかは、上方及び下方の両方に宣言された依存性を含む、請求項１に記載の装置。
【請求項３６】
前記自動プロデューサグラフ発生モジュールは、新プロデューサコマンドに応答し、そして前記プロデューサグラフ実行モジュールは、実行コマンドに応答する、請求項１に記載の装置。
【請求項３７】
オブジェクト指向のコードを実行するための装置において、
オブジェクト指向のコードにおけるメソッドに対するプロデューサ依存性宣言を解釈するランタイム(runtime)を備え、前記プロデューサ依存性宣言は、ランタイム(run time)時に、０以上のプロデューサのセットを識別し、プロデューサは、少なくともインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであり、各プロデューサのメソッドは、そのプロデューサのインスタンスのクラスのメソッドであり、前記プロデューサ依存性宣言は、前記オブジェクト指向のコードにおけるクラスのクラス定義の一部分であり、前記プロデューサ依存性宣言の少なくとも幾つかは、下方に宣言された依存性を含み、前記ランタイムは、
問題とするプロデューサの指定を受け取り、その問題とするプロデューサを現在プロデューサグラフの一部分として追加し、そして前記現在プロデューサグラフに既にあるプロデューサのメソッドのプロデューサ依存性宣言に基づいて他のプロデューサをリンクし且つ必要に応じてインスタンス生成することにより前記現在プロデューサグラフの残り部分を自動的に発生するための自動プロデューサグラフ発生モジュールと、
前記自動プロデューサグラフ発生モジュール、前記現在プロデューサグラフ、及び前記現在プロデューサグラフ内の各プロデューサの現在出力に結合されたプロデューサグラフ構造であって、メソッドキーがメソッドを区別するのに使用され、インスタンスキーがインスタンスを区別するのに使用され、そしてプロデューサキーがプロデューサを区別するのに使用され、更に、所与のプロデューサのプロデューサキーが、少なくとも、そのプロデューサのインスタンス及びメソッドのインスタンスキー及びメソッドキーに基づくようなプロデューサグラフ構造と、
前記プロデューサグラフ構造に結合されて、前記現在プロデューサグラフにより指示された順序で前記現在プロデューサグラフにおけるプロデューサを実行するためのプロデューサグラフ実行モジュールであって、前記現在プロデューサグラフは、前記現在プロデューサグラフにおけるプロデューサのメソッドのプロデューサ依存性宣言により識別される適切な実行シーケンスを表し、そして各プロデューサの実行で、そのプロデューサのメソッドがそのプロデューサのインスタンスにおいて実行されることになるプロデューサグラフ実行モジュールと、
を備え、前記プロデューサグラフ実行モジュールは、
ダイナミックプロデューサ依存性を解明するためのダイナミック依存性モジュールを含み、各プロデューサ依存性宣言は、ダイナミックプロデューサ依存性を含み、そのダイナミックプロデューサ依存性は、プロデューサ依存性宣言がランタイム中に識別する０以上のプロデューサのセットを前記ランタイムがダイナミックに選択するようにさせ、このダイナミックな選択は、前記現在プロデューサグラフの異なる実行中に前記セットに対して異なるプロデューサの選択を行わせることができ、前記ダイナミックプロデューサ依存性は、コンティンジェントプロデューサ依存性を含み、そのコンティンジェントプロデューサ依存性は、依存性決定プロデューサに依存し、この依存性決定プロデューサそれ自身は、１つ以上の他のプロデューサの出力に依存する、装置。
【請求項３８】
前記ランタイムは、更に、現在プロデューサグラフの表現をグラフ表示するためのプロデューサグラフビューアモジュールを備えた、請求項３７に記載の装置。
【請求項３９】
前記ランタイムは、更に、前記現在プロデューサグラフからの出力をグラフ表示しそしてその現在プロデューサグラフとのインタラクションを許すための構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュールを備えた、請求項３７に記載の装置。
【請求項４０】
前記ダイナミックプロデューサ依存性は、サブスクリプションを含み、このサブスクリプションは、プロデューサがトリガープロデューサであるかどうか決定するためにプロデューサを比較する基準を識別し、更に、このサブスクリプションは、トリガープロデューサに対する依存性を識別する、請求項３７に記載の装置。
【請求項４１】
前記サブスクリプションの幾つかは、アブソービングサブスクリプションであり、このアブソービングサブスクリプションは、プロデューサ依存性宣言がランタイム中に識別する０以上のプロデューサのセットにトリガープロデューサを前記ランタイムがダイナミックに含ませるようにさせる、請求項４０に記載の装置。
【請求項４２】
前記サブスクリプションの幾つかは、スティッキーサブスクリプションであり、このスティッキーサブスクリプションは、親プロデューサの特性も識別し、更に、このスティッキーサブスクリプションは、探索される各トリガープロデューサに対して、前記ランタイムが、その識別された特性を満足する親プロデューサをインスタンス生成し、且つそれを、現在プロデューサグラフに含ませるようにさせる、請求項４０に記載の装置。
【請求項４３】
前記プロデューサの幾つかは、その実行でプロデューサの互いの依存性の識別を返送する依存性決定プロデューサである、請求項３７に記載の装置。
【請求項４４】
幾つかの前記依存性決定プロデューサの実行は、上方に宣言された依存性を返送する、請求項４３に記載の装置。
【請求項４５】
前記プロデューサ依存性宣言の少なくとも幾つかは、１つ以上の引数依存性及びフィールド依存性を含み、その引数依存性は、前記ランタイムが、子プロデューサの出力を親プロデューサへの入力パラメータとしてマップするようにさせ、そしてそのフィールド依存性は、インスタンスのフィールドの使用を指示する、請求項３７に記載の装置。
【請求項４６】
クラスキーを使用してクラスを区別し、そして各プロデューサに対するプロデューサキーは、そのプロデューサのインスタンスのクラスのクラスキーにも基づく、請求項３７に記載の装置。
【請求項４７】
少なくとも幾つかのプロデューサのインスタンスキーは、プロデューサのインスタンスに対するリファレンスを保持する、請求項３７に記載の装置。
【請求項４８】
前記自動プロデューサグラフ発生モジュールは、問題とするプロデューサの複数の指定を受け取り、且つ複数の現在プロデューサグラフを自動的に発生し、そして前記プロデューサグラフ実行モジュールは、各々が全ての現在プロデューサグラフを実行させるグローバルな実行コマンドに応答する、請求項３７に記載の装置。
【請求項４９】
オブジェクト指向のコードを実行する方法において、
現在問題とする出力をもつプロデューサをインスタンス生成するステップであって、前記オブジェクト指向のコードは、メソッド及びプロデューサ依存性宣言を含み、所与のメソッドに対するプロデューサ依存性宣言は、０以上のプロデューサのセットを識別し、プロデューサは、少なくともインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであるようなステップと、
前記インスタンス生成に応答して、問題とするプロデューサを現在プロデューサグラフの一部分として追加するステップと、
前記現在プロデューサグラフに既にあるプロデューサのメソッドのプロデューサ依存性宣言に基づいて他のプロデューサをリンクし且つ必要に応じてインスタンス生成することにより前記現在プロデューサグラフの残り部分を自動的に発生するように試みるステップと、
前記現在プロデューサグラフ内のプロデューサを実行して、前記問題とするプロデューサに対する現在出力を決定するステップと、
を備えた方法。
【請求項５０】
自動的に発生するよう試みる前記ステップは、更に、問題とするプロデューサへの１つ以上の入力のセットの現在値を発生するのに必要なプロデューサの直接的入力対出力関係を表す現在プロデューサグラフを、前記オブジェクト指向のコードにおけるプロデューサ依存性宣言から自動的に発見し及び構築するように試みる段階を含み、前記現在プロデューサグラフにおける各プロデューサの現在出力は、現在プロデューサグラフにおける１つ以上の別のプロデューサ及び／又は問題とするプロデューサへの直接的入力である、請求項４９に記載の方法。
【請求項５１】
現在プロデューサグラフ内のプロデューサを実行する前記ステップは、更に、現在プロデューサグラフに追加されるべき他のプロデューサの互いの依存性の識別を返送する現在プロデューサグラフの幾つかのプロデューサの実行を通して現在プロデューサグラフの付加的な部分を自動的に発生する段階を含む、請求項４９に記載の方法。
【請求項５２】
前記実行するステップは、ダイナミックプロデューサ依存性を解明する段階を含み、各プロデューサ依存性宣言は、ダイナミックプロデューサ依存性を含み、ダイナミックプロデューサ依存性は、前記プロデューサ依存性宣言がランタイム中に識別する０以上のプロデューサのセットを前記ランタイムがダイナミックに選択するようにさせる、請求項４９に記載の方法。
【請求項５３】
前記ダイナミックプロデューサ依存性宣言は、コンティンジェントなプロデューサ依存性を含み、コンティンジェントなプロデューサ依存性は、依存性決定プロデューサに対する依存性であり、この依存性決定プロデューサそれ自身は、１つ以上の他のプロデューサの出力に依存する、請求項５２に記載の方法。
【請求項５４】
前記ダイナミックプロデューサ依存性は、サブスクリプションを含み、このサブスクリプションは、プロデューサがトリガープロデューサであるかどうか決定するためにプロデューサを比較する基準を識別し、更に、このサブスクリプションは、トリガープロデューサに対する依存性を識別する、請求項５２に記載の方法。
【請求項５５】
前記サブスクリプションの幾つかは、アブソービングサブスクリプションであり、このアブソービングサブスクリプションは、プロデューサ依存性宣言が識別する０以上のプロデューサのセットにトリガープロデューサをダイナミックに含ませる、請求項５４に記載の方法。
【請求項５６】
前記サブスクリプションの幾つかは、スティッキーサブスクリプションであり、このスティッキーサブスクリプションは、親プロデューサの特性も識別し、更に、このスティッキーサブスクリプションは、探索される各トリガープロデューサに対して、その識別された特性を満足する親プロデューサをインスタンス生成し、且つそれを、そのトリガープロデューサに対するプロデューサ依存性を有するものとして現在プロデューサグラフに含ませる、請求項５４に記載の方法。
【請求項５７】
自動的に発生するよう試みる前記ステップは、更に、
まだインスタンス生成されていないプロデューサのインスタンスをインスタンス生成する段階と、
まだインスタンス生成されていないプロデューサをインスタンス生成する段階と、
を含む請求項４９に記載の方法。
【請求項５８】
自動的に発生するよう試みる前記ステップは、更に、
まだロードされていないプロデューサのインスタンスのクラスをロードする段階と、
プロデューサ依存性宣言ステートメントが含まれた、まだイントロスペクトされていないクラスのクラス定義をイントロスペクトする段階と、
を含む請求項４９に記載の方法。
【請求項５９】
自動的に発生するよう試みる前記ステップは、更に、プロデューサのインスタンスのクラスが前記試みの前に既にロードされてイントロスペクトされ、プロデューサのインスタンスが前記試みの前に既にインスタンス生成され、且つプロデューサが前記試みの前に既にインスタンス生成されたところのプロデューサの１つを発見して現在プロデューサグラフへと構築する段階を含む、請求項５８に記載の方法。
【請求項６０】
現在プロデューサグラフの表現をグラフ表示するステップを更に備えた、請求項４９に記載の方法。
【請求項６１】
現在プロデューサグラフからの出力をグラフ表示しそして現在プロデューサグラフとのインタラクションを許すステップを更に備えた、請求項４９に記載の方法。
【請求項６２】
現在プロデューサグラフのプロデューサの現在出力を記憶するステップと、
現在プロデューサグラフの１つ以上のプロデューサの現在出力をオーバーライドするステップと、
前記現在プロデューサグラフ及び前記オーバーライド、並びに前記オーバーライドにより直接的又は間接的に影響されないプロデューサの記憶された現在出力に基づいて、前記オーバーライドにより直接的又は間接的に影響されるプロデューサのみを再実行して、それらの現在出力を決定するステップと、
を更に備えた請求項４９に記載の方法。
【請求項６３】
影響を受ける前記プロデューサは、現在プロデューサグラフ内の全てのプロデューサではない、請求項６２に記載の方法。
【請求項６４】
オーバーライドを非オーバーライドするステップと、
前記現在プロデューサグラフ及び前記非オーバーライド、並びに前記非オーバーライドにより直接的又は間接的に影響されないプロデューサの記憶された現在出力に基づいて、前記非オーバーライドにより直接的又は間接的に影響されるプロデューサのみを再実行して、それらの現在出力を決定するステップと、
を更に備えた請求項６２に記載の方法。
【請求項６５】
前記プロデューサ依存性宣言により宣言される依存性の少なくとも幾つかは、引数依存性及びフィールド依存性として指定され、引数依存性は、子プロデューサの出力を親プロデューサへの入力パラメータとしてマップさせ、そしてフィールド依存性は、インスタンスのフィールドの使用を指示する、請求項４９に記載の方法。
【請求項６６】
前記プロデューサ依存性宣言によって宣言された依存性の少なくとも幾つかは、シーケンスのみの依存性として指定され、このシーケンスのみの依存性は、所与のメカニズムへ出力を書くための子プロデューサのメソッドにおけるコード、及び所与のメカニズムから出力を読むための親プロデューサのメソッドにおけるコードを通して、子プロデューサから親プロデューサへ与える必要のある出力がもしあればそれが発生することを要求する、請求項４９に記載の方法。
【請求項６７】
メソッドキーを使用してメソッドを区別し、インスタンスキーを使用して、インスタンスを区別し、プロデューサキーを使用して、プロデューサを区別し、所与のプロデューサのプロデューサキーは、少なくとも、そのプロデューサのインスタンス及びメソッドのインスタンスキー及びメソッドキーに基づく、請求項４９に記載の方法。
【請求項６８】
前記インスタンスは、複数のクラスのインスタンスであり、前記クラスキーは、前記複数のクラスを区別するのに使用され、各プロデューサのプロデューサキーは、そのプロデューサのインスタンスのクラスのクラスキーにも基づく、請求項６７に記載の方法。
【請求項６９】
少なくとも幾つかのプロデューサのインスタンスキーは、プロデューサのインスタンスに対するリファレンスを保持する、請求項６７に記載の方法。
【請求項７０】
前記プロデューサ依存性宣言の少なくとも幾つかは、上方に宣言された依存性を含む、請求項４９に記載の方法。
【請求項７１】
前記プロデューサ依存性宣言の少なくとも幾つかは、下方に宣言された依存性を含む、請求項４９に記載の方法。
【請求項７２】
前記プロデューサ依存性宣言の少なくとも幾つかは、上方及び下方の両方に宣言された依存性を含む、請求項４９に記載の方法。
【請求項７３】
前記インスタンス生成は、新プロデューサコマンドに応答して遂行され、前記実行は、グローバルな実行コマンドに応答して遂行される、請求項４９に記載の方法。
【請求項７４】
オブジェクト指向のコードを実行するための方法において、
問題とするプロデューサの指示を受け取るステップであって、プロデューサは、少なくともインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであるようなステップと、
前記問題とするプロデューサ及びメソッドに対するプロデューサ依存性宣言ステートメントに基づいてプロデューサグラフを自動的に発生し実行するステップであって、前記プロデューサグラフは、前記問題とするプロデューサ及び複数のレベルの他のプロデューサを含むターゲットサブグラフを含むものであるステップと、
を備え、前記自動的に発生し実行するステップは、
ソースプロデューサに到達するまで次のこと、即ち、
前記ターゲットサブグラフに既にあるプロデューサのうちの１つのプロデューサのメソッドのプロデューサ依存性宣言ステートメントに基づいてプロデューサの判断サブグラフを発見し、構築しそして実行すること、及び
前記判断サブグラフにより返送される１つ以上の他のプロデューサのセットを前記ターゲットサブグラフに追加すること、
を繰り返し遂行する段階と、
前記ターゲットサブグラフにより指示されるようにシーケンスされる前記ターゲットサブグラフ内のプロデューサを実行する段階であって、各プロデューサの実行で、そのプロデューサのメソッドがそのプロデューサのインスタンスにおいて実行されることになる段階と、
を含む、方法。
【請求項７５】
少なくとも１つのプロデューサは、ターゲットサブグラフ及び１つの判断サブグラフの両方の一部分である、請求項７４に記載の方法。
【請求項７６】
前記判断サブグラフの第１は、依存性決定プロデューサであるルートを含むと共に、少なくとも幾つかが標準的プロデューサであるノードを含む、請求項７４に記載の方法。
【請求項７７】
前記ターゲットサブグラフは、標準的プロデューサであるルートを有する、請求項７４に記載の方法。
【請求項７８】
前記判断サブグラフの少なくとも１つは、サブスクリプションを返送する、請求項７４に記載の方法。
【請求項７９】
前記サブスクリプションは、トリガープロデューサに対するアブソービングサブスクリプション基準を指示するアブソービングサブスクリプションである、請求項７８に記載の方法。
【請求項８０】
前記サブスクリプションは、トリガープロデューサのためのスティッキーサブスクリプション基準及び生成されるべき親プロデューサに対するスティッキーサブスクリプション特性を含むスティッキーサブスクリプションである、請求項７８に記載の方法。
【請求項８１】
前記判断サブグラフの少なくとも１つは、上方に宣言されるプロデューサ依存性を返送する、請求項７４に記載の方法。
【請求項８２】
前記プロデューサ依存性宣言ステートメントの少なくとも幾つかは、１つ以上の引数依存性及びフィールド依存性を識別し、その引数依存性は、子プロデューサの出力を親プロデューサへの入力パラメータとしてマップするようにさせ、そしてそのフィールド依存性は、インスタンスのフィールドの使用を指示する、請求項７４に記載の方法。
【請求項８３】
メソッドキーは、メソッドを区別するのに使用され、インスタンスキーは、インスタンスを区別するのに使用され、そしてプロデューサキーは、プロデューサを区別するのに使用され、各プロデューサのためのプロデューサキーは、少なくとも、そのプロデューサのインスタンス及びメソッドのインスタンスキー及びメソッドキーに基づく、請求項７４に記載の方法。
【請求項８４】
前記インスタンスは、複数のクラスのインスタンスであり、クラスキーは、前記複数のクラスを区別するのに使用され、そして各プロデューサのプロデューサキーは、そのプロデューサのインスタンスのクラスのクラスキーにも基づく、請求項８３に記載の方法。
【請求項８５】
少なくとも幾つかのプロデューサのインスタンスキーは、プロデューサのインスタンスに対するリファレンスを保持する、請求項８３に記載の方法。
【請求項８６】
プロデューサグラフの表現をグラフ表示するステップを更に備えた、請求項７４に記載の方法。
【請求項８７】
前記プロデューサグラフからの出力をグラフ表示しそして前記プロデューサグラフとのインタラクションを許すステップを更に備えた、請求項７４に記載の方法。
【請求項８８】
問題とするプロデューサの指示の前記受け入れの後であって且つ前記自動的な発生及び実行の前に実行コマンドを受け入れるステップを更に備えた、請求項７４に記載の方法。
【請求項８９】
オブジェクト指向のコードを実行するための装置において、
問題とするプロデューサ及びメソッドに対するプロデューサ依存性宣言ステートメントに基づいてプロデューサグラフを自動的に発生し実行するためのランタイム(runtime)を備え、プロデューサは、少なくともインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであり、前記ランタイムは、次のような繰り返し関連されるモジュール、即ち、
前記問題とするプロデューサの指定を受け取り、前記問題とするプロデューサを前記プロデューサグラフのターゲットサブグラフに追加し、そしてそのターゲットサブグラフに現在あるプロデューサのメソッドのプロデューサ依存性宣言ステートメントに基づいて判断サブグラフを自動的に発見し構築することにより前記ターゲットサブグラフにおいて複数のレベルの他のプロデューサを自動的に発生するための自動プロデューサグラフ発生モジュールと、
前記プロデューサグラフにおけるプロデューサを実行するためのプロデューサグラフ実行モジュールであって、各プロデューサの実行で、そのプロデューサのメソッドがそのプロデューサのインスタンスにおいて実行されることになり、且つ複数の判断サブグラフの各々の実行で、少なくとも別のプロデューサが前記ターゲットサブグラフに追加されるようなプロデューサグラフ実行モジュールと、
を備えている、装置。
【請求項９０】
少なくとも１つのプロデューサは、ターゲットサブグラフ及び１つの判断サブグラフの両方の一部分である、請求項８９に記載の装置。
【請求項９１】
前記判断サブグラフの第１は、依存性決定プロデューサであるルートを含むと共に、少なくとも幾つかが標準的プロデューサであるノードを含む、請求項８９に記載の装置。
【請求項９２】
前記ターゲットサブグラフは、標準的プロデューサであるルートを有する、請求項８９に記載の装置。
【請求項９３】
前記判断サブグラフの少なくとも１つは、サブスクリプションを返送する、請求項８９に記載の装置。
【請求項９４】
前記サブスクリプションは、トリガープロデューサに対するアブソービングサブスクリプション基準を指示するアブソービングサブスクリプションである、請求項９３に記載の装置。
【請求項９５】
前記サブスクリプションは、トリガープロデューサのためのスティッキーサブスクリプション基準及び生成されるべき親プロデューサに対するスティッキーサブスクリプション特性を含むスティッキーサブスクリプションである、請求項９３に記載の装置。
【請求項９６】
前記複数の判断サブグラフの少なくとも１つは、上方に宣言されるプロデューサ依存性を返送する、請求項８９に記載の装置。
【請求項９７】
前記プロデューサ依存性宣言ステートメントの少なくとも幾つかは、１つ以上の引数依存性及びフィールド依存性を識別し、その引数依存性は、子プロデューサの出力を親プロデューサへの入力パラメータとしてマップするようにさせ、そしてそのフィールド依存性は、インスタンスのフィールドの使用を指示する、請求項８９に記載の装置。
【請求項９８】
メソッドキーは、メソッドを区別するのに使用され、インスタンスキーは、インスタンスを区別するのに使用され、そしてプロデューサキーは、プロデューサを区別するのに使用され、各プロデューサのためのプロデューサキーは、少なくとも、そのプロデューサのインスタンス及びメソッドのインスタンスキー及びメソッドキーに基づく、請求項８９に記載の装置。
【請求項９９】
前記インスタンスは、複数のクラスのインスタンスであり、クラスキーは、前記複数のクラスを区別するのに使用され、そして各プロデューサのプロデューサキーは、そのプロデューサのインスタンスのクラスのクラスキーにも基づく、請求項９８に記載の装置。
【請求項１００】
少なくとも幾つかのプロデューサのインスタンスキーは、プロデューサのインスタンスに対するリファレンスを保持する、請求項９８に記載の装置。
【請求項１０１】
前記ランタイムは、更に、現在プロデューサグラフの表現をグラフ表示するためのプロデューサグラフビューアモジュールを備えた、請求項８９に記載の装置。
【請求項１０２】
前記ランタイムは、更に、前記プロデューサグラフからの出力をグラフ表示しそしてそのプロデューサグラフとのインタラクションを許すための構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュールを備えた、請求項８９に記載の装置。
【請求項１０３】
前記自動プロデューサグラフ発生モジュールは、新プロデューサコマンドに応答し、そして前記プロデューサグラフ実行モジュールは、実行コマンドに応答する、請求項８９に記載の方法。
【請求項１０４】
オブジェクト指向のコードを与えるマシン記憶媒体において、
複数のクラス定義を備え、その各々は、
１つ以上のフィールドのセットと、
１つ以上のメソッドのセットと、
前記メソッドのセットの各々に対するプロデューサ依存性宣言と、
を含み、前記メソッドの所与の１つに対する前記プロデューサ依存性宣言は、０以上のプロデューサのセットを識別するためにランタイムにおいて使用され、プロデューサは、少なくとも、ランタイムにおける複数のクラスのうちの１つのクラスのインスタンス及びそのクラスのメソッドを含むランタイムインスタンス生成可能なコンストラクトであり、
第１のプロデューサは、次のようなコンティンジェントなプロデューサ依存性を有し、即ち
前記メソッドのセットのうちの第１メソッドは、プロパティメソッドであり、
前記メソッドのセットのうちの第２メソッドは、前記プロパティメソッドに基づいてプロパティプロデューサを識別するプロデューサ依存性宣言ステートメントを有すると共に、前記プロパティプロデューサの出力に基づいて第２プロデューサと第３プロデューサとの間で選択を行うためのコードを有し、
前記メソッドのセットのうちの第３メソッドは、前記第２メソッドに基づいて依存性決定プロデューサを識別するプロデューサ依存性宣言ステートメントを有し、前記第１プロデューサは、前記第３メソッドに基づくもので、前記依存性決定プロデューサが現在返送しているのは前記第２及び第３プロデューサのどちらであるかについてのプロデューサ依存性を有する、マシン記憶媒体。
【請求項１０５】
第４プロデューサは、次のようなトリガープロデューサに対するサブスクリプション依存性を有し、即ち
前記メソッドのセットのうちの第４メソッドであって、前記第４プロデューサがこの第４メソッドに基づくような第４メソッド、
トリガープロデューサに対してサブスクリプション基準のセットを指示するコードを有する前記メソッドのセットのうちの第５メソッドであって、サブスクリプションプロデューサがこの第５メソッドに基づくような第５メソッド、及び
前記メソッドのセットのうちの第６メソッドであって、前記トリガープロデューサがこの第６メソッドに基づくと共に、前記トリガープロデューサが前記サブスクリプション基準のセットを満足するので前記サブスクリプション依存性が生成されるような第６メソッド、
を有する、請求項１０４に記載のマシン記憶媒体。
【請求項１０６】
前記サブスクリプション基準のセットは、アブソービングサブスクリプション基準であり、そして前記第４メソッドは、前記サブスクリプションプロデューサを識別するプロデューサ依存性宣言を有する、請求項１０５に記載のマシン記憶媒体。
【請求項１０７】
前記サブスクリプション基準のセットは、スティッキーサブスクリプション基準であり、前記第５メソッドは、親プロデューサに対するスティッキーサブスクリプション特性のセットを指示するコードも含み、前記トリガープロデューサは、前記スティッキーサブスクリプション基準を満足し、そして前記第４プロデューサは、前記スティッキーサブスクリプション特性を満足し且つ前記サブスクリプション依存性の結果としてインスタンス生成されたものである、請求項１０５に記載のマシン記憶媒体。
【請求項１０８】
前記プロデューサ依存性宣言の少なくとも１つは、強く制約された引数依存性を含む、請求項１０４に記載のマシン記憶媒体。
【請求項１０９】
前記プロデューサ依存性宣言の少なくとも１つは、強く制約されたフィールド依存性を含む、請求項１０４に記載のマシン記憶媒体。
【請求項１１０】
第４プロデューサは、次のような第５プロデューサに対するプロデューサ依存性を有し、即ち
前記メソッドのセットのうちの第４メソッドであって、前記第４プロデューサがこの第４メソッドに基づくような第４メソッド、
プロデューサ依存性を上方に宣言するコードを有する前記メソッドのセットのうちの第５メソッド、及び
前記第５メソッドに基づき依存性決定プロデューサを識別するプロデューサ依存性宣言を有する前記メソッドのセットのうちの第６メソッドであって、前記第５プロデューサがこの第６メソッドに基づくと共に、前記第５プロデューサに対する前記第４プロデューサのプロデューサ依存性を返送する前記依存性決定プロデューサに対するプロデューサ依存性を有するような第６メソッド、
を有する、請求項１０４に記載のマシン記憶媒体。
【請求項１１１】
メソッドキーは、前記メソッドのセットを区別するのに使用され、インスタンスキーは、前記複数のクラス定義のインスタンスを区別するのに使用され、そしてプロデューサキーは、プロデューサを区別するのに使用され、各プロデューサのためのプロデューサキーは、少なくとも、そのプロデューサのインスタンス及びメソッドのインスタンスキー及びメソッドキーに基づく、請求項１０４に記載のマシン記憶媒体。
【請求項１１２】
クラスキーは、前記複数のクラスを区別するのに使用され、そして各プロデューサに対するプロデューサキーは、そのプロデューサのインスタンスのクラスのクラスキーにも基づく、請求項１１１に記載のマシン記憶媒体。
【請求項１１３】
少なくとも幾つかのプロデューサのインスタンスキーは、プロデューサのインスタンスに対するリファレンスを保持する、請求項１１１に記載のマシン記憶媒体。
【請求項１１４】
オブジェクト指向のコードを与えるマシン記憶媒体において、
複数のクラス定義を有するプログラム備え、その各クラス定義は、
１つ以上のフィールドのセットと、
１つ以上のメソッドのセットと、
前記メソッドのセットの各々に対するプロデューサ依存性宣言と、
を含み、前記メソッドの所与の１つに対する前記プロデューサ依存性宣言は、０以上のプロデューサのセットを識別するためにランタイムにおいて使用され、プロデューサは、少なくとも、ランタイムにおける複数のクラスのうちの１つのクラスのインスタンス及びそのクラスのメソッドを含むランタイムインスタンス生成可能なコンストラクトであり、
各プロデューサのメソッドは、変換メソッドであり、そして前記プログラムは、手動インボケーションシーケンスコードは含まず、むしろ、ランタイムに依存して、前記プロデューサ依存性宣言から前記変換メソッドに対するシーケンスを自動的に発見する、マシン記憶媒体。
【請求項１１５】
前記プロデューサ依存性宣言の少なくとも幾つかは、ダイナミックプロデューサ依存性を含み、このダイナミックプロデューサ依存性は、０以上のプロデューサのセットをランタイム中にダイナミックに選択するようにさせる、請求項１１４に記載のマシン記憶媒体。
【請求項１１６】
前記ダイナミックプロデューサ依存性は、コンティンジェントなプロデューサ依存性を含み、このコンティンジェントなプロデューサ依存性は、依存性決定プロデューサに依存し、この依存性決定プロデューサそれ自身は、１つ以上の他のプロデューサの出力に依存する、請求項１１５に記載のマシン記憶媒体。
【請求項１１７】
前記ダイナミックプロデューサ依存性は、サブスクリプションを含み、このサブスクリプションは、プロデューサがトリガープロデューサであるかどうか決定するためにプロデューサを比較する基準を識別し、更に、このサブスクリプションは、トリガープロデューサに対する依存性を識別する、請求項１１５に記載のマシン記憶媒体。
【請求項１１８】
前記サブスクリプションの幾つかは、アブソービングサブスクリプションであり、このアブソービングサブスクリプションは、プロデューサ依存性宣言が識別する０以上のプロデューサのセットにトリガープロデューサをダイナミックに含ませるようにさせる、請求項１１７に記載のマシン記憶媒体。
【請求項１１９】
前記サブスクリプションの幾つかは、スティッキーサブスクリプションであり、このスティッキーサブスクリプションは、親プロデューサの特性も識別し、更に、このスティッキーサブスクリプションは、探索される各トリガープロデューサに対して、その識別された特性を満足する親プロデューサをインスタンス生成し、且つそれを、そのトリガープロデューサに対するプロデューサ依存性を有するものとしてプロデューサグラフに含ませるようにさせる、請求項１１７に記載のマシン記憶媒体。
【請求項１２０】
前記プロデューサ依存性宣言により宣言された依存性の少なくとも幾つかは、引数依存性及びフィールド依存性として指定され、その引数依存性は、前記ランタイムが、子プロデューサの出力を親プロデューサへの入力パラメータとしてマップするようにさせ、そしてそのフィールド依存性は、インスタンスのフィールドの使用を指示する、請求項１１４に記載のマシン記憶媒体。
【請求項１２１】
メソッドキーを使用してメソッドを区別し、インスタンスキーを使用してインスタンスを区別し、プロデューサキーを使用してプロデューサを区別し、所与のプロデューサに対するプロデューサキーは、少なくとも、そのプロデューサのインスタンス及びメソッドのインスタンスキー及びメソッドキーに基づく、請求項１１４に記載のマシン記憶媒体。
【請求項１２２】
クラスキーを使用して前記複数のクラスを区別し、そして各プロデューサに対するプロデューサキーは、そのプロデューサのインスタンスのクラスのクラスキーにも基づく、請求項１２１に記載のマシン記憶媒体。
【請求項１２３】
少なくとも幾つかのプロデューサのインスタンスキーは、プロデューサのインスタンスに対するリファレンスを保持する、請求項１２１に記載のマシン記憶媒体。
【請求項１２４】
前記プロデューサ依存性宣言の少なくとも幾つかは、上方に宣言された依存性を含む、請求項１１４に記載のマシン記憶媒体。
【請求項１２５】
１つ以上のクラスのセットの、１つ以上のインスタンスのセットであって、その各クラスは、メソッド及びメソッドに対するプロデューサ依存性宣言を含み、前記インスタンスのセットの各々は、そのクラスの全メソッドに関連され、そして前記プロデューサ依存性宣言は、プロデューサ間の１つ以上の依存性のセットをランタイム時に識別するようなインスタンスのセットと、
プロデューサグラフ構造であって、
各々がランタイム時にインスタンス生成されたコンストラクトであり、且つ前記インスタンスのセットのうちの１つのみ及びそのインスタンスに関連したメソッドの１つのみを含む複数のプロデューサ、
前記複数のプロデューサのマルチレベルグラフを表す複数のリンクであって、前記複数のプロデューサに含まれたメソッドに対するプロデューサ依存性宣言により識別されたプロデューサグラフ内のプロデューサ間の依存性を表している複数のリンク、
前記複数のプロデューサ各々に対するプロデューサキーであって、前記インスタンスのセットのうちの１つ及びそのインスタンスに関連したメソッドのうちの１つを識別する少なくともインスタンスキー及びメソッドキーに各々基づくプロデューサキー、及び
前記プロデューサグラフ内の複数のプロデューサ各々の現在出力、
が記憶されたプロデューサグラフ構造と、
前記インスタンスキーと前記インスタンスのセットとの間の対応性が記憶されたインスタンス追跡構造と、
を記憶しているマシン記憶媒体。
【請求項１２６】
前記プロデューサグラフ構造は、プロデューサグラフ内のプロデューサのメソッドのプロデューサ依存性宣言により識別される実行の適切なシーケンスを表す、請求項１２５に記載のマシン記憶媒体。
【請求項１２７】
前記プロデューサグラフ構造は、問題とするプロデューサから、プロデューサグラフのエンドノードであるプロデューサまでのプロデューサの互いの直接的な入力隊出力依存性を表す、請求項１２５に記載のマシン記憶媒体。
【請求項１２８】
前記プロデューサグラフ構造により表された依存性の少なくとも幾つかは、引数依存性及びフィールド依存性として指定され、その引数依存性は、前記ランタイムが、子プロデューサの出力を親プロデューサへの入力パラメータとしてマップするようにさせ、そしてそのフィールド依存性は、インスタンスのフィールドの使用を指示する、請求項１２５に記載のマシン記憶媒体。
【請求項１２９】
前記プロデューサグラフ構造によって表わされた依存性の少なくとも幾つかは、シーケンスのみの依存性として指定され、このシーケンスのみの依存性は、所与のメカニズムへ出力を書くための子プロデューサのメソッドにおけるコード、及び所与のメカニズムから出力を読むための親プロデューサのメソッドにおけるコードを通して、子プロデューサから親プロデューサへ与える必要のある出力がもしあればそれが発生することを要求する、請求項１２５に記載のマシン記憶媒体。
【請求項１３０】
前記プロデューサグラフ構造は、更に、前記複数のプロデューサの各々に対して、そのプロデューサがオーバーライドされるかどうかの指示及びオーバーライドされた出力値を記憶するオーバーライドプロデューサ出力変更を含む、請求項１２５に記載のマシン記憶媒体。
【請求項１３１】
クラスのセットに対してオブジェクト指向のコードに書かれたクラス定義のセットが更に記憶され、前記プロデューサ依存性宣言の各々は、それに対するメソッドの１つに隣接して位置したプロデューサ依存性宣言ステートメントを含む、請求項１２５に記載のマシン記憶媒体。
【請求項１３２】
少なくとも幾つかのプロデューサのインスタンスキーは、プロデューサのインスタンスに対するリファレンスを保持する、請求項１２５に記載のマシン記憶媒体。
【請求項１３３】
各プロデューサキーは、少なくとも、プロデューサのインスタンスのクラスを識別するクラスキーにも基づく、請求項１２５に記載のマシン記憶媒体。
【請求項１３４】
ランタイム中にロードされイントロスペクトされる複数のクラスの表現であって、メソッド及びプロデューサ依存性宣言をイントロスペクトした結果を含むような表現と、
前記クラスキーと前記クラスのセットの表現との間の対応性が記憶されたクラス追跡構造と、
前記メソッドキーと、前記メソッドをイントロスペクトした結果との間の対応、並びに前記プロデューサ依存性宣言をイントロスペクトした結果に関する情報が記憶されたメソッド追跡構造と、
を更に記憶している請求項１３３に記載のマシン記憶媒体。
【請求項１３５】
クライアントコードを含むオブジェクト指向のソースコードを記憶しており、前記クライアントコードは、
問題とするプロデューサに対するプロデューサキーを有すると共に、オブジェクト指向のコードに対するランタイムが、問題とするプロデューサからスタートしてマルチレベルの発見されたプロデューサを有する現在プロデューサグラフを自動的に発見し、構築し且つ任意に解明するようにさせるプロデューサインスタンス生成コマンド、
を備え、前記プロデューサの各々は、少なくともインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであり、前記ランタイムは、まだインスタンス生成されていない現在プロデューサグラフのプロデューサのいずれかを自動的にインスタンス生成し、プロデューサキーは、プロデューサを区別するのに使用され、メソッドキーは、メソッドを区別するのに使用され、インスタンスキーは、インスタンスを区別するのに使用され、そして各プロデューサに対するプロデューサキーは、少なくとも、そのプロデューサのインスタンス及びメソッドのインスタンスキー及びメソッドキーに基づくものであり、
更に、オブジェクト指向のコードに対するランタイムが、現在プロデューサグラフを実行すると共に、その現在プロデューサグラフにおいて実行されたプロデューサの各々について現在出力をキャッシュ記憶するように各々させる実行コマンドと、
プロデューサキー及びオーバーライド値を各々有し、そしてオブジェクト指向のコードに対するランタイムが、プロデューサキーにより指定されたプロデューサの出力をオーバーライド値でオーバーライドするように各々させるプロデューサ出力オーバーライドコマンドと、
を備えたマシン記憶媒体。
【請求項１３６】
前記ランタイムクライアントは、更に、
オーバーライドされた１つのプロデューサのプロデューサキーを各々有すると共に、オブジェクト指向のコードに対するランタイムが、そのプロデューサの出力を非オーバーライドするように各々させるプロデューサ出力非オーバーライドコマンド、
備えた請求項１３５に記載のマシン記憶媒体。
【請求項１３７】
前記プロデューサインスタンス生成コマンドは、新プロデューサコマンドであり、そして前記プロデューサ出力オーバーライドコマンドは、セットコマンドである、請求項１３５に記載のマシン記憶媒体。
【請求項１３８】
前記プロデューサインスタンス生成コマンド及び前記プロデューサ出力オーバーライドコマンドの因果関係は、オブジェクト指向のコードに対するランタイムにより保持されるログを通して間接的なものである、請求項１３５に記載のマシン記憶媒体。
【請求項１３９】
前記実行コマンドの第１は、初期実行を生じさせ、そして前記実行コマンドの各次々のコマンドは、増分的実行を生じさせる、請求項１３５に記載のマシン記憶媒体。
【請求項１４０】
前記ランタイムクライアントは、更に、
問題とするプロデューサのインスタンスキーを有すると共に、オブジェクト指向のコードに対するランタイムが、問題とするプロデューサのインスタンスをインスタンス生成させるインスタンスインスタンス生成コマンド、
を備えた請求項１３５に記載のマシン記憶媒体。
【請求項１４１】
１つ以上のプロデューサ出力オーバーライドコマンドの各セットは、その後に、１つの実行コマンドが続く、請求項１３５に記載のマシン記憶媒体。
【請求項１４２】
前記クラスキーは、そのインスタンスがインスタンスである複数のクラスを区別するのに使用され、そして各プロデューサのプロデューサキーは、そのプロデューサのインスタンスのクラスのクラスキーにも基づく、請求項１３５に記載のマシン記憶媒体。
【請求項１４３】
前記プロデューサインスタンス生成コマンドは、オブジェクト指向のコードに対するランタイムが、プロデューサインスタンス生成コマンドのプロデューサキーのクラスキーを使用してクラス追跡構造を通してプロデューサのクラスにアクセスし、プロデューサインスタンス生成コマンドのプロデューサキーのインスタンスキーを使用してインスタンス追跡構造を通してプロデューサのインスタンスにアクセスし、そしてプロデューサインスタンス生成コマンドのプロデューサキーのメソッドキーを使用してメソッド追跡構造を通してプロデューサのメソッドのプロデューサ依存性宣言にアクセスすることにより、問題とするプロデューサをインスタンス生成するようにさせる、請求項１４２に記載のマシン記憶媒体。
【請求項１４４】
少なくとも幾つかのプロデューサのインスタンスキーは、プロデューサのインスタンスに対するリファレンスを保持する、請求項１３５に記載のマシン記憶媒体。
【請求項１４５】
前記クライアントコードは、更に、
オブジェクト指向のコードに対するランタイムが、他の現在プロデューサグラフを自動的に発見し、構築し、且つ任意であるが、解明するようにさせる付加的なプロデューサインスタンス生成コマンド、
を含み、前記実行コマンドの各々は、オブジェクト指向のコードに対する前記ランタイムが、全ての現在プロデューサグラフを実行するようにさせる、請求項１３５に記載のマシン記憶媒体。
【請求項１４６】
前記オブジェクト指向のソースコードは、クラス定義も含み、前記クラス定義は、プロデューサ依存性宣言を伴うメソッドで表されたビジネスロジックを含む、請求項１３５に記載のマシン記憶媒体。
【請求項１４７】
前記プロデューサ依存性宣言は、ビジネスロジックを含むクラスのインスタンスがインスタンス生成された後ではなく、それらクラスの定義中にプロデューサ間の連結を定義する、請求項１４６に記載のマシン記憶媒体。
【請求項１４８】
プロデューサ出力レイアウトのための方法において、
プロデューサグラフ内のプロデューサ及びそれらプロデューサの出力の、クラスを含むリストを、それらのゲットプロパティメソッドで表示するステップであって、前記プロデューサグラフは、問題とするプロデューサ及びクラスのメソッドに対するプロデューサ依存性宣言に基づいて自動的に発生され実行され、プロデューサは、少なくとも、クラス、そのクラスのインスタンス、及びそのインスタンスに関連したそのクラスのメソッドを含むランタイムインスタンス生成可能なコンストラクトであり、前記プロデューサグラフ内のプロデューサのメソッドのプロデューサ依存性宣言は、各々、前記プロデューサグラフ内の０以上の他のプロデューサのセットを識別し、更に、前記プロデューサグラフは、前記問題とするプロデューサ及び複数のレベルの他のプロデューサを含むものであるステップと、
セルを有するスプレッドシートを表示するステップと、
１つ以上の表示されたクラスのセットの、複数の表示されたゲットプロパティメソッドを、前記スプレッドシートのセルにマッピングしたものを受け取るステップと、
少なくとも、前記マッピングのセルに、１つ以上のインスタンスのセットの対応ゲットプロパティメソッドの出力をポピュレートするステップと、
を備えた方法。
【請求項１４９】
自動的にポピュレートされたセルのうちの１つのセルの値を受け取るステップと、
出力が現在そのセルにポピュレートしているプロデューサの出力を前記値でオーバーライドするステップと、
前記プロデューサグラフを少なくとも増分的に実行し、前記マッピングのセルを必要に応じて更新するステップと、
を更に備えた請求項１４８に記載の方法。
【請求項１５０】
前記ポピュレートするステップは、更に、１つ以上のインスタンスのセットの選択の指示を受け取る段階を含む、請求項１４８に記載の方法。
【請求項１５１】
１つ以上のインスタンスのセットの選択の指示を受け取る前記段階は、少なくとも前記インスタンスのセットの中の１つのインスタンスのインスタンスキーの指示を受け取ることを含む、請求項１５０に記載の方法。
【請求項１５２】
前記ポピュレートするステップは、更に、前記表示されたクラスのセットの中の少なくとも第１のものであるインスタンスを選択するために適用されるべき複数のフィルタのうちの１つのフィルタの選択の指示を受け取る段階を含み、前記複数のフィルタの各々は、異なる仕方で選択を行うことができる、請求項１４８に記載の方法。
【請求項１５３】
前記ポピュレートするステップは、更に、複数のフィルタのうちの１つのフィルタの選択の指示を受け取る前記段階の前に、前記第１のクラスを前記スプレッドシートのセルの１つにマッピングしたものを受け取る段階を含む、請求項１５２に記載の方法。
【請求項１５４】
複数のフィルタのうちの１つのフィルタの選択の指示を受け取る前記段階は、前記第１クラスがマッピングされた前記スプレッドシートのセルを通して遂行される、請求項１５３に記載の方法。
【請求項１５５】
前記ポピュレートするステップは、更に、複数のフィルタのうちの１つのフィルタの選択の指示を受け取る前記段階の後に、前記選択されたフィルタを使用し、前記第１クラスがマッピングされた前記スプレッドシートのセルを通して、前記第１クラスのインスタンスのうちの１つのインスタンスの選択の指示を受け取る段階を含む、請求項１５４に記載の方法。
【請求項１５６】
前記第１クラスのインスタンスのうちの１つのインスタンスの選択の指示を受け取る前記段階は、前記インスタンスのセットのうちの１つのインスタンスのインスタンスキーの指示を受け取ることを含む、請求項１５５に記載の方法。
【請求項１５７】
前記ポピュレートするステップは、更に、
テーブルを定義するゾーンの指示を受け取る段階であって、前記テーブルが前記スプレッドシートのセルの複数の行列を含むような段階、
を含み、マッピングしたものを受け取る前記段階は、前記テーブルの一方の縁にあるセルのグループに対して遂行され、更に、
前記一方の縁にあるセルのグループに、前記表示されたクラスのセットのうちの第１クラスの第１インスタンスの対応ゲットプロパティメソッドの出力をポピュレートする段階と、
前記テーブルの逆の縁に到達するまで同じ配向を有するセルの各隣接グループに、前記第１クラスの別のインスタンスの対応ゲットプロパティメソッドの出力を繰り返しポピュレートする段階と、
を含む請求項１４８に記載の方法。
【請求項１５８】
前記プロデューサ依存性宣言の少なくとも１つは、ダイナミックプロデューサ依存性を含み、そのダイナミックプロデューサ依存性は、プロデューサ依存性宣言がランタイム中に識別する０以上のプロデューサのセットをダイナミックに選択させる、請求項１４８に記載の方法。
【請求項１５９】
前記ダイナミックプロデューサ依存性は、コンティンジェントなプロデューサ依存性であり、そのコンティンジェントなプロデューサ依存性は、依存性決定プロデューサに依存し、この依存性決定プロデューサそれ自身は、１つ以上の他のプロデューサの出力に依存する、請求項１５８に記載の方法。
【請求項１６０】
前記ダイナミックプロデューサは、サブスクリプションを返送する、請求項１５８に記載の方法。
【請求項１６１】
前記サブスクリプションは、トリガープロデューサに対するアブソービングサブスクリプション基準を指示するアブソービングサブスクリプションである、請求項１６０に記載の方法。
【請求項１６２】
前記サブスクリプションは、トリガープロデューサのためのスティッキーサブスクリプション基準及び生成されるべき親プロデューサに対するスティッキーサブスクリプション特性を含むスティッキーサブスクリプションである、請求項１６０に記載の方法。
【請求項１６３】
前記プロデューサ依存性宣言の少なくとも幾つかは、１つ以上の引数依存性及びフィールド依存性を識別し、その引数依存性は、子プロデューサの出力を親プロデューサへの入力パラメータとしてマップさせ、そしてそのフィールド依存性は、インスタンスのフィールドの使用を指示する、請求項１４８に記載の方法。
【請求項１６４】
クラスキーは、前記クラスを区別するのに使用され、メソッドキーは、メソッドを区別するのに使用され、インスタンスキーは、インスタンスを区別するのに使用され、そしてプロデューサキーは、プロデューサを区別するのに使用され、更に、各プロデューサに対するプロデューサキーは、少なくとも、そのプロデューサのクラス、インスタンス、及びメソッドのクラスキー、インスタンスキー、及びメソッドキーの基づく、請求項１４８に記載の方法。
【請求項１６５】
少なくとも幾つかのプロデューサのインスタンスキーは、プロデューサのインスタンスに対するリファレンスを保持する、請求項１６４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、コンピュータの分野に係り、より詳細には、ランタイムでコードをプログラミングして実行する分野に係る。
【背景技術】
【０００２】
オブジェクト指向のプログラミング
オブジェクト指向のプログラミングとは、コンピュータプログラミングパラダイムである。オブジェクト指向のプログラミングの背景にある考え方は、プログラムがファンクションの集合又は単にコンピュータに対するインストラクションのリストとして見える慣習的なビューとは対照的に、コンピュータプログラムが、互いに作用する（オブジェクト又はインスタンスと呼ばれる）個々のユニットの集合より成るものとして見えるというものである。オブジェクトとは、データを、そのデータに対して動作するメソッドと結び付けるための言語メカニズムである。各オブジェクトは、メソッドを通してコールされ、データを処理し、そして結果を他のオブジェクトへ与えることができる。各オブジェクトは、個別の役割又は責任をもつ独立したマシン又はアクターとして見ることができる。
【０００３】
リフレクティブなオブジェクト指向の言語とは、特徴（例えば、クラス、オブジェクト／インスタンス、継承、リフレクション、等）の特定セットを有するプログラミング言語であるが、リフレクティブなオブジェクト指向の言語は、これらの特徴のあるサブセット（例えば、オブジェクト）を有するプログラミング言語をラベリングするのに時々使用される。本書の目的上、「オブジェクト指向のソースコード」及び「オブジェクト指向のコード」という句は、このような特徴を有する言語で書かれたコード（例えば、リフレクティブなオブジェクト指向の言語で書かれたコード、リフレクティブなオブジェクトベースの言語で書かれたコード）を指すのに使用される。手続き型言語、非リフレクティブなオブジェクト指向の言語、及び非リフレクティブなオブジェクトベースの言語は、典型的にこのような特徴をサポートしないプログラミング言語であるが、変換技術を使用して、このような特徴を（例えば、エミュレーションにより）このような言語で適切に書かれたコードに与えることができ、従って、このような技術は、このような言語をリフレクティブなオブジェクトベースの言語又はリフレクティブなオブジェクト指向の言語へ変換する。（これらの技術は、オブジェクト指向又はオブジェクトベースの言語の全ての特徴をエミュレートする必要がなく、本書の残り部分に対して問題となる特徴のみをエミュレートすればよい。）又、本書の目的上、「オブジェクト指向のソースコード」及び「オブジェクト指向のコード」という句は、このように変換された手続き型言語、非リフレクティブなオブジェクト指向の言語、及び非リフレクティブなオブジェクトベースの言語のコードを指すのにも使用される。例えば、これに限定されないが、本書は、主として、リフレクティブなオブジェクト指向の言語で書かれたオブジェクト指向のソースコードについて記述する。又、オブジェクト及びインスタントという語は、ここでは、交換可能に使用する。
【０００４】
オブジェクト指向のプログラミングに主として使用されるメソッドという語は、クラスに排他的に関連したコードの断片（クラスメソッド、スタティックメソッド、又はファクトリメソッドと称される）又はオブジェクトに排他的に関連したコードの断片（インスタンスメソッドと称される）を指す。手続き型プログラミング言語の手続きと同様に、メソッドは、通常、アクションを遂行する一連のステートメント、これらアクションをパラメータ化するための入力パラメータのセット、及びおそらく、返送されるある種の出力値で構成される。
【０００５】
プログラマーがオブジェクト指向の言語を使用してプログラムを書くときに、得られるコードは、概念的には、４つの基本的形式のコードを含むものとして見ることができる。第１の形式は、入力インスタンス（１つ又は複数）に対して動作して出力インスタンス（１つ又は複数）を与えるコマンド（ここでは、「変換」コードと称される）を含み、これは、典型的に、メソッド（ここでは、「変換」メソッドと称される）として書かれる。第２の形式は、ランタイム(runtime)がクラスのインスタンスをインスタンス生成するようにさせるインスタンスインスタンス生成コマンド（ここでは、「インスタンスインスタンス生成」コードと称される）を含む。第３の形式は、前記インスタンスのプロパティメソッド（アクセッサ、ミューテータ、等）をインボークするためのプロパティ操作コマンド（ここでは、「データ準備」コードと称される）を含む。第４の形式は、適切なインスタンス（適切なインスタンスとは、引数として使用するためのインスタンス、インスタンスメソッドにより使用されるインスタンス、及びクラスメソッドにより使用されるメタクラスインスタンスを含む）を使用してメソッドインボケーションシーケンスを生じさせて、インボークすべきどんなインスタンスのどんな変換メソッドを、どの順序で、且つデータ準備コードによってなされた変化に応答してどのインスタンスのどのパラメータで指定するかの一連のコマンド（ここでは、「手動インボケーションシーケンス」コードと称される）を含む。手動インボケーションシーケンスコードは、時々、変換メソッドとは個別のメソッドとして書かれ、従って、手動インボケーションシーケンスコードは、変換メソッドに対する一連のインボケーションコマンドを含む。プログラムは、典型的に、データ準備コードと手動インボケーションシーケンスコード（これは、インスタンスインスタンス生成コードへとディップすることもある）との間で繰り返され、これは、次いで、変換コードをインボークする（これも、インスタンスインスタンス生成コード及びデータ準備コード形式へとディップすることがある）。これは、プログラムの概念的表現であり、従って、プログラムをどのように見るかについて絶対的なものと考えてはならないことに注意されたい。
【０００６】
ランタイム
ここで使用するランタイム(runtime)という語は、同じ及び／又は異なる言語で書かれた他のコードを実行する基本的コードのプログラム又はライブラリーを指す。従って、ランタイムは、オペレーティングシステムで動作して、数学的ファンクション、入力及び出力のようなファシリティを与えることを含めて、その実行中にプログラムをサポートするユーティリティファンクションの集合である。これは、プログラマーが、プログラミング言語で指定されるか又はオペレーティングシステムによって与えられた基本的能力を常時再書き込みするのを不要にする。ランタイムとオペレーティングシステムとの間の境界はぼやけているので、ここで使用するランタイムという語は、オペレーティングシステムとは個別のコード及び／又はオペレーティングシステムの一部であるコードを指すものとする。
【０００７】
ＦＯＲＴＲＡＮの場合のような初期のランタイムは、数学的オペレーションのような特徴を与える。他の言語は、より精巧な特徴、例えば、メモリガベージ収集を、オブジェクトに対するサポートにしばしば関連して追加する。より最近の言語は、著しく多くのファンクションを伴う著しく大きなランタイムを有する傾向がある。多くのオブジェクト指向の言語は、「ディスパッチャー」及び「クラスローダー」として知られているシステムも含む。Ｊａｖａバーチャルマシン（ＪＶＭ）は、このようなランタイムの一例であり、ポータブルバイナリーＪａｖａプログラム（バイト−コード）をランタイムにおいて解釈又はコンパイルする。共通言語ランタイム（ＣＬＲ）フレームワークは、ランタイムの別の例である。
【０００８】
プログラミング及び実行フレームワーク
アプリケーションがエンドユーザに与えられるところの１つのフレームワークは、３つの基本的区分を含む。第１の区分は、オペレーティングシステム及びランタイムの生成を含む。この第１の区分は、非常に高度なプログラミングスキルをもつプログラマーにより遂行される。この区分で働くときには、プログラマーは、各々、オペレーティングシステムプログラマー及びランタイムプログラマーと称される。オブジェクト指向の言語に対してランタイムを生成するときに、ランタイムプログラマーは、変換コード、インスタンスインスタンス生成コード、データ準備コード、及び手動インボケーションシーケンスコードに使用される種々の形式のコマンド（例えば、インスタンスインスタンス生成コマンド、データ準備コマンド、及びメソッドインボケーションコマンド）を実行するためのサポートを含む。
【０００９】
第２の区分は、ランタイムにより実行されるオブジェクト指向のアプリケーションソースコードの生成を含む。この第２の区分も、非常に高度なプログラミングスキルをもつと共にアプリケーションのビジネス目標を理解するプログラマーによって遂行される。この区分で働くときには、プログラマーは、アプリケーションプログラマーと称される。オブジェクト指向のプログラミング言語でアプリケーションを生成するときに、アプリケーションプログラマーは、生成される特定のアプリケーションに対して、特定の変換コード、インスタンスインスタンス生成コードデータ準備コード、及び手動インボケーションシーケンスコードを書き込む。これの一部分として、アプリケーションがグラフィックユーザインターフェイスを要求する場合には、アプリケーションプログラマーは、特定のアプリケーションに対してグラフィックユーザインターフェイスの設計及びコード化も行い、従って、アプリケーションデザイナーとも称される。
【００１０】
第３の区分は、ランタイムによって実行されているアプリケーションプログラムの使用を含む。この第３の区分は、プログラミングスキルを必要としないエンドユーザによって遂行される。
【００１１】
手動インボケーションシーケンスコード
アプリケーションの生成に典型的に関連した最大のコストは、手動インボケーションシーケンスコードのデバッグ及び／又は最適化を含む。データを変更する機会のたびに、アプリケーションプログラマーは、その効果を考慮し、そして適切なインスタンスの適切な変換メソッドを適切な入力により適切な順序でインボークさせるように手動インボケーションシーケンスコードを書かねばならない。アプリケーションプログラマーによりなされるミステークは、例えば、１）適切なインスタンスの適切な変換メソッドを誤った順序でインボークすること、２）あるデータが変更されるのに応答して、１つ以上の要求されたインスタンス変換メソッドをインボークさせるコマンドを含ませるのを忘れること、３）あるデータが変更されるのに応答して、不必要なインスタンス変換メソッドをインボークさせるコマンドを含ませること（例えば、データの変更による影響のないインスタンスの変換メソッドをインボークするコマンドを含ませること）、等を含む。
【００１２】
例えば、手動インボケーションシーケンスコードを発生する１つの技術は、オブザーバーパターン（時々「パブリッシュ・サブスクライブ(publish subscribe)」としても知られている）を使用して、プログラムにおけるインスタンスの状態を観察することである。オブザーバーパターンでは、１つ以上のインスタンス（オブザーバー又はリスナーと呼ばれる）が登録され（又はそれら自体を登録し）、観察されたオブジェクト（主題）により起り得る事象を観察する。ある事象を生じ得る観察されたインスタンスは、一般に、登録されたオブザーバーの集合を維持する。事象が生じると、各オブザーバーは、観察されたインスタンスからのコールバックを受け取る（観察されたインスタンスは、登録されたオブザーバーにおいて「通知(notify)」メソッドをインボークする）。この通知ファンクションは、オブザーバーによって使用できる幾つかのパラメータ（一般的に、発生する事象に関する情報）をパスすることができる。各オブザーバーは、通知ファンクションを具現化し、その結果、通知が生じるときにそれ自身の振舞いを定義する。
【００１３】
観察されたインスタンスは、典型的に、新たなオブザーバーを追加するための登録メソッドと、事象が生じたときに通知されるべきインスタンスのリストからオブザーバーを除去するための非登録メソッドとを有する。更に、観察されたインスタンスは、多数の関連更新の非効率的なカスケード化を防止するために一時的にディスエイブルし、次いで、再イネーブルするためのメソッドも含むことができる。より詳細には、プロパティ値の変化に応答してコールされるコールバックは、しばしば、幾つかの他のプロパティの値も変化させ、付加的なコールバックをトリガーし、等々である。
【００１４】
オブザーバーパターン技術を使用するときには、手動インボケーションシーケンスコードを書くアプリケーションプログラマーは、観察される異なるインスタンスに対してオブザーバーを登録し、非登録とし、ディスエイブルし及び再イネーブルすると共に、各々について通知及びコールバックメソッドを書き込むことにより、どんなインスタンスのどんなメソッドをどの順序で且つどの入力でコールするか指定する。より詳細には、オブザーバーと、観察されるインスタンスとの関係は、オブザーバーパターン内でローカルに管理され（観察される他のインスタンスと同期せずに、観察されるインスタンスのみにより）、従って、観察される複数のインスタンスからの事象と同期する必要のある手動インボケーションシーケンスコードは、典型的に、各オブザーバーの特定のコールバックメソッドの一部分である。
【００１５】
オーバーライティング・揮発性コールスタック
典型的なランタイムは、オーバーライティング・揮発性コールスタックを使用して、現在インボークされている未完了のコールを追跡する。オーバーライティング・揮発性コールスタックは、各コールが完了すると、ポップオフしてエントリーを破棄するという点でオーバーライティングであり、且つ実行のたびに破棄されて再構築されるという点で揮発性である。典型的なランタイムがオーバーライティング・揮発性コールスタックを使用するのは、典型的なランタイムが、オーバーライティング・揮発性コールスタックを構築することを、手動インボケーションシーケンスコードの実行に応答して適切な入力で適切なインスタンスの適切な変換メソッドを実際にインボークすることと結合するからである。要約すれば、手動インボケーションシーケンスコードの実行に応答して、典型的なランタイムは、変換メソッド／インスタンスシーケンスをコールごとに（各コールがなされるときに）決定し、そして現在インボークされている未完了のコールのみを追跡するようにオーバーライティング・揮発性コールスタックを維持する。
【００１６】
オブジェクト関連マッピング
オブジェクト関連マッピングとは、関連データベースをオブジェクト指向の言語概念にリンクして「バーチャルオブジェクトデータベース」を（実際に）生成するプログラミング技術である。あるオブジェクト関連マッパーは、メモリにロードされるインスタンスを自動的にデータベースと常時同期状態に保持する。より詳細には、オブジェクト・対・ＳＱＬマッピング問合せを構成した後、最初に返送されるデータが、オブジェクト−ＳＱＬマッピングパッケージと同様に、当該インスタンスのフィールドにコピーされる。そのようになると、インスタンスは、これらの値が変化するかどうか調べるために監視し、次いで、データをデータベースに書き戻すためにプロセスを慎重に逆転しなければならない。
【００１７】
Ｈｉｂｅｒｎａｔｅ３．０は、Ｊａｖａ及びＣＬＤ（ジョージア州アトランタのＪｂｏｓｓ（登録商標）インク）に対するオブジェクト関連マッピング解決策である。従って、Ｈｉｂｅｒｎａｔｅは、オブジェクト指向のドメインモデルを慣例的な関連データベースへマッピングするためのフレームワークを与える。その目標は、ある共通のデータ持続性に関連したプログラミングタスクから開発者を救援することである。Ｈｉｂｅｒｎａｔｅは、クラスからデータベーステーブルへの（及びオブジェクト指向のデータ形式からＳＱＬデータ形式への）マッピングを取り扱うと共に、データ問合せ及び検索ファシリティを与える。Ｈｉｂｅｒｎａｔｅは、インスタンス中心であり、インスタンス間の関係を表すグラフを構築する。
【００１８】
制御の逆転及び依存性逆転原理
ＩＯＣとしても知られている制御の逆転は、コンピュータプログラムに本来ある結合（各プログラムモジュールが互いに他のモジュールに依存する程度）を減少するのに使用できるオブジェクト指向のプログラミング原理である。ＩＯＣは、依存性逆転原理としても知られている。ＩＯＣにおいて、次のいずれかに該当する場合、即ち、１）クラスＸがクラスＹを有して、それにコールするか、２）ＸがＹであるか、又は３）ＸがあるクラスＺに依存し、これがＹに依存する（推移性の）場合に、クラスＸがクラスＹに依存する。ＸがＹに依存することは、ＹがＸに依存することを意味せず、即ち両方が真となる場合にはサイクリック依存性と称され、ＹなしにＸを使用することはできず、又、その逆ことも言えることに注意する価値がある。
【００１９】
実際に、（クラスＸの）オブジェクトｘが、（クラスＹの）オブジェクトｙのメソッドをコールする場合には、クラスＸがＹに依存する。第３のクラス、即ちｘがｙをコールし得る全てのメソッドを含まねばならないインターフェイスクラスＩを導入することにより、依存性が逆転される。更に、Ｙは、それがインターフェイスＩを具現化するように変更されねばならない。ここで、Ｘ及びＹの両方がインターフェイスＩに依存し、クラスＸは、もはやクラスＹに依存しない（ＸがＹをインスタンス生成しないと仮定すれば）。インターフェイスＩを導入することによりＹに対するクラスＸの依存性をこのように排除することは、制御の逆転（又は依存性逆転）であると言える。Ｙは、他のクラスに依存してもよいことに注意されたい。変換が適用される前に、ＸはＹに依存し、従って、Ｘは、Ｙが依存する全てのクラスに間接的に依存する。制御の逆転を適用することにより、これら全ての間接的依存性も崩壊される。新たに導入されるインターフェイスＩは、何物にも依存しない。
【００２０】
スプリングフレームワークは、ＩＯＣ及び依存性逆転を使用するＪａｖａプラットホームに対するオープンソースアプリケーションフレームワークである。より詳細には、スプリングフレームワークの中心は、Ｊａｖａオブジェクトを構成し及び管理する手段をなす制御逆転コンテナである。このコンテナは、ＢｅａｎＦａｃｔｏｒｙ、ＡｐｐｌｉｃａｔｉｏｎＣｏｎｔｅｘｔ又はＣｏｒｅコンテナとしても知られている。このコンテナのオペレーションは、例えば、オブジェクトを生成し、オブジェクトを構成し、初期化メソッドをコールし、そして登録されたコールバックオブジェクトにオブジェクトを通すことである。コンテナにより生成されたオブジェクトは、管理オブジェクト又はビーンとも呼ばれる。典型的に、コンテナは、ビーン定義を含むＸＭＬファイルをロードすることによって構成される。これらは、オブジェクトを生成するのに必要な全ての情報を与える。エラー状態を生じることなくオブジェクトが生成されて構成されると、それらが使用できるようになる。オブジェクトは、依存性ルックアップ又は依存性注入により得ることができる。依存性ルックアップは、発呼者が特定の名前又は特定形式のオブジェクトについてコンテナオブジェクトに尋ねるパターンである。依存性注入は、コンテナが、コンストラクタ、プロパティ又はファクトリメソッドのいずれかを経て、オブジェクトを名前によって他のオブジェクトへ通すパターンである。従って、スプリングフレームワークは、メモリ中心であり、インスタンス間の関係を表すグラフを構築する。
【００２１】
グラフツール
ＪａｖａｄｏｃTMは、Ｊａｖａソースファイルのセットにおける宣言及びドキュメンテーションコメントを構文解析し、そしてパブリック及び保護クラス、ネスト状クラス（匿名の内部クラスではない）、インターフェイス、コンストラクタ、メソッド、及びフィールドを（デフォールトにより）記述するＨＴＭＬページの対応セットを発生するツールである（カリフォルニア州サンタクララのＳｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）インク）。Ｊａｖａｄｏｃは、ソースファイルのセットに対してＡＰＩ（アプリケーションプログラミングインターフェイス）ドキュメンテーション又は具現化ドキュメンテーションを発生するのに使用できる。又、Ｊａｖａｄｏｃは、クラス及びメソッド中心であり、クラス及びそれらのメソッドの組合せ間の関係を表すグラフを構築する。
【００２２】
ソフトウェアアプリケーションを設計するための別のシステムは、コンピュータアプリケーションを表現し及び再生するためにインタープリターにより分析されたオブジェクトのグラフを含む。このシステムは、コードライブラリに記憶された予め書かれたプログラミングクラスを使用し、これは、１９９５年、Addison Wesley、Gamma氏等による“Design Patterns”、１９９８年、Wiley Computer Publishing、Grandによる“Patterns in Java”、及び／又は高レベルのコンピュータ支援型ソフトウェアエンジニアリング（ＣＡＳＥ）ツールに記載された設計パターンに従うように書くことができる。より詳細には、幾つかのこのようなクラスは、オブザーバーの振舞いパターンに基づく。予め書かれたコードのライブラリーは、アプリケーション状態ノード、処理ロジック、及び種々のアプリケーション状態間のシステムのデータ流（即ち、アプリケーションの予め書かれたデータエレメント）を表し、ソフトウェアアプリケーションを生成するときに、ユーザがコードを書き込み、編集し又はコンパイルする必要がないようにする。むしろ、ユーザは、アプリケーション状態ノード内のデータ又はアプリケーション状態ノード内で遂行されるプロセスのような、現在アプリケーション状態ノードに関連した視覚的オブジェクトを編集することにより、グラフィックユーザインターフェイスにおいてソフトウェアアプリケーションを手動で編集する。次いで、現在アプリケーション状態ノードに対してユーザによりなされた変化に基づき、インタープリターは、丁度編集されたアプリケーション状態に対して、更新されたアプリケーション状態をユーザに表示する。システムは、次いで、ユーザ定義された移行エッジに沿って別のアプリケーション状態へ移行することができ、そこで、ユーザは、次のアプリケーション状態又は移行エッジを任意に編集することができる。グラフに対する変更は、ソフトウェアアプリケーションが実行されている間にインタープリターにより具現化されるグラフのインスタンスに対して行うことができる。
【００２３】
ソフトウェアアプリケーションを設計するためのこのシステムは、アプリケーションコントローラで「使用可能」にすることができる実行中のソフトウェアアプリケーションの視覚的表現を含む。実行中のソフトウェアアプリケーションを表す視覚的オブジェクトをユーザが変更するときには、コントローラが入力を使用して、インタープリターがグラフに対する変更を行うよう誘導する。次いで、コントローラは、より多くの変更を待機する。更に、このようなソフトウェアアプリケーションの視覚的表現を、アプリケーション、ひいては、ソフトウェアアプリケーションの視覚的表現を記述するＸＭＬドキュメントとしてインポート又はエクスポートすることができる。
【００２４】
ノード、指令されたエッジ及びアプリケーション状態の視覚的表現の形態でソフトウェアアプリケーションを編集し及び／又は生成するために、アプリケーションプログラムインターフェイス及びアプリケーションエディタをシステムに更に含ませることができる。予め書かれたコードライブラリからのキーワード及び関連定義は、アプリケーション開発者が、実際のアプリケーション構造に厳密に相関したグラフアプリケーションのグラフ的表現をエディタ内に設けることにより、ソフトウェアアプリケーション、処理ステップ、及びソフトウェアアプリケーションの視覚的表現を手動で定義することができるようにする。ユーザは、「アプリケーション定義ウイザード」を通して新たなアプリケーションを定義し、このウイザードは、ある事前の事柄が満足された後に、新たなアプリケーションをエディタワークスペース内のグラフコンポーネントとして表示する。ユーザは、更に、予め生成された考えられるアプリケーションコンポーネントの表示されたリストから選択を行い、そしてＰＣのマウス及びキーボードを使用してワークスペース上でコンポーネントをドラグしてドロップすることにより、アプリケーションと対話する。ユーザは、コンポーネントを選択し、それらを既存のコンポーネントの上に「ドラグ」することができる。新たなコンポーネントが既存のコンポーネント上に「ドロップ」されると、新たなコンポーネントは、アプリケーショングラフ内で既存のコンポーネントの子となる。アプリケーション内のコンポーネントの関係は、エディタ内でのユーザ選択により手動で定義される。従って、アプリケーションを表すツリー構造がユーザによって構築される。アプリケーションが生成されると、ユーザは、アプリケーションナビゲータビューアを選択して、構成されたアプリケーションのツリービューを表示し、アプリケーションの任意のコンポーネントを選択して編集できるようにする。エディタインターフェイスは、アプリケーションエレメントを生成又は削除し、コンポーネントの属性を更新し、そしてアプリケーションの表示プロパティを更新することを含めて、ユーザ入力及び選択を処理する。
【００２５】
上述したシステムは、ソフトウェアアプリケーションの視覚的表現を使用するが、関連データベースを定義し及び更新するための視覚的プログラミングツールとして使用することもできる。このシステムは、ソフトウェアアプリケーションの視覚的表現のＸＭＬ記述を使用する。ツールは、ＸＭＬ記述を構文解析し及び解釈して、同等の関連データベーステーブルスキーマ及びそれに対する変更を発生する。ソフトウェアアプリケーションの視覚的表現内でデータが変更されたときには、変更の記述が、ジャーナルファイルにおける他の変更と共に記憶され、次いで、グループとして処理される。中間プログラム（それ自身のスレッドで動作するＪａｖａアプリケーション）は、ソフトウェアアプリケーションの視覚的表現と、関連データベースとの間のトランザクションを遂行する。Ｊａｖａアプリケーションは、視覚的表現のノード（即ち、データベースのデータ）に対する変更のジャーナルをポーリングし（即ち、チェックし）、そして変更があった場合に、データベースに対して変更を行う。従って、視覚的表現内のデータを変更することにより、システムは、データベースを更新する。データベースからのデータの要求を取り扱うために、ソフトウェアアプリケーションの視覚的表現とデータベースとの間に同様のアプリケーションが存在する。
【００２６】
ソフトウェアを分析するための別のシステムは、コードツリーアナライザ（ＣＴＡ）と称される。ＣＴＡは、オブジェクト指向のプログラミング言語で書かれたスタティックソースコードを分析する。ＣＴＡは、記号テーブル及びコールツリーをスタティックソースコードから発生する。記号テーブルを使用して、ＣＴＡは、クラスダイアグラムを発生する。同様に、コールツリーを使用して、ＣＴＡは、シーケンスダイアグラムを発生する。クラスダイアグラムは、ユーザ選択クラスと、ユーザ選択クラスに関連したクラスとの間の関係を示す。シーケンスダイアグラムは、異なるメソッドがコールされるシーケンスを示す。クラスダイアグラム及びシーケンスダイアグラムの両方を使用して、ＣＴＡは、スタティックソースコードを表す設計アーティファクトを発生する。ユーザがこの設計アーティファクトを変更するときに、ＣＴＡは、シーケンスダイアグラムを使用して、ソースコードの影響部分を識別する。設計アーティファクトは、スタティックソースコードのコードメンテナンス及び／又は逆行分析(reverse engineering)に使用される。
【発明の概要】
【００２７】
プロデューサグラフ指向のプログラミング及び実行のための方法及び装置を説明する。本発明の１つの態様によれば、メソッドに対するプロデューサ依存性宣言を解釈するランタイム(runtime)が提供される。プロデューサ依存性宣言は、ランタイム時(run time)に、０以上のプロデューサのセットを識別し、ここで、プロデューサとは、少なくともインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトである。ランタイムは、メソッドがプロデューサ依存性宣言を有するところのインスタンス生成されるべき問題とするプロデューサの指定を受け取るのに応答して、プロデューサグラフを自動的に発生して実行する。プロデューサグラフは、最初、問題とするプロデューサを含み、そしてプロデューサグラフに既にあるプロデューサのメソッドのプロデューサ依存性宣言に基づいてプロデューサのインスタンス生成を通してその問題とするプロデューサからソースプロデューサへと発生される。ランタイムは、プロデューサグラフにより指示されるようにプロデューサグラフ内のプロデューサの実行をシーケンシングする。
【００２８】
本発明の実施形態を示した添付図面及び以下の詳細な説明を参照することにより本発明が最も良く理解されよう。
【図面の簡単な説明】
【００２９】
【図１Ａ】本発明の一実施形態によりオブジェクト指向のソースコードにおけるクラスのメソッドに対するプロデューサ依存性宣言と、そのクラス、そのクラスの所与のインスタンス及びそのクラスのメソッドを含むプロデューサとの関係を示すブロック図である。
【図１Ｂ】本発明の一実施形態によるプロデューサ１１０Ａと親プロデューサ１１４Ａ．１との間の関係を例示する。
【図１Ｃ】本発明の一実施形態によるプロデューサ１１０Ａと子プロデューサ１１２Ａ．１との間の関係を例示する。
【図１Ｄ】本発明の一実施形態による親プロデューサ１１４及び子プロデューサ１１２とプロデューサ１１０Ａとの関係の付加的な組合せを例示する。
【図１Ｅ】本発明の一実施形態により、同じクラスの異なるインスタンスが同じ及び／又は異なるメソッドに基づきプロデューサを有することができることを示す。
【図２】本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムの再使用性を示すブロック図である。
【図３Ａ】本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。
【図３Ｂ】本発明の一実施形態により増分的実行及びオーバーライドされたプロデューサ出力もサポートするプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。
【図４Ａ】本発明の一実施形態により例示的プロデューサグラフの発見及び構築を示すブロック図である。
【図４Ｂ】本発明の一実施形態により図４Ａのプロデューサグラフの初期の実行を示すブロック図である。
【図４Ｃ】本発明の一実施形態により図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。
【図４Ｄ】本発明の一実施形態により従属プロデューサ２がオーバーライドされた後の図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。
【図４Ｅ】本発明の一実施形態により従属プロデューサ２がオーバーライドされそして独立ソースプロデューサ３が変更された後の図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。
【図５Ａ】本発明の一実施形態により未解明の依存性を含む例示的プロデューサグラフの発見及び構築を示すブロック図である。
【図５Ｂ】本発明の一実施形態により図５Ａのプロデューサグラフの初期の実行と、未解明の依存性の解明とを示すブロック図である。
【図５Ｃ】本発明の一実施形態により図５Ａのプロデューサグラフの初期の実行及び／又は図５Ｂのプロデューサグラフの再実行を示すブロック図である。
【図５Ｄ】本発明の一実施形態により図５Ａのプロデューサグラフの初期の実行及び／又は図５Ｂ又は５Ｃのプロデューサグラフの再実行を示すブロック図である。
【図６】本発明の一実施形態により、ランタイムクライアントの論理的実行フローと、プロデューサグラフ指向のプログラミングサポートを伴うランタイムに対するその関係とを示すフローチャートである。
【図７Ａ】本発明の一実施形態によりショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。
【図７Ｂ】本発明の一実施形態による例示的プロデューサのブロック図である。
【図７Ｃ】本発明の一実施形態により非ショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示すと共に、例示的プロデューサのブロック図である。
【図７Ｄ】本発明の一実施形態により非ショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。
【図７Ｅ】本発明の一実施形態による例示的プロデューサのブロック図である。
【図７Ｆ】本発明の一実施形態により依存性決定プロデューサを伴うUpwardDependencyの使用による例示的依存性を示すブロック図である。
【図７Ｇ】本発明の一実施形態により依存性決定プロデューサを伴うWeaklyConstrainedDependencyの使用による例示的依存性を示すブロック図である。
【図７Ｈ】本発明の一実施形態による標準的プロデューサの例示的プロデューサグラフを示す。
【図７Ｉ】図７Ｈのプロデューサグラフを発見し、解明しそして構築するためのプロデューサ依存性及び依存性決定プロデューサの一例を示す。
【図８Ａ】本発明の一実施形態によりアプリケーションがエンドユーザに与えられるところの第１の例示的フレームワークを示すブロック図である。
【図８Ｂ】本発明の一実施形態によりアプリケーションがエンドユーザに与えられるところの第２の例示的フレームワークを示すブロック図である。
【図８Ｃ】本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０での自由セル選択の例示的スクリーンショット及び使用を示す。
【図８Ｄ】本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０での自由セル選択の別の例示的スクリーンショット及び使用を示す。
【図８Ｅ】本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０でのテーブル生成の例示的スクリーンショット及び使用を示す。
【図８Ｆ】本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０でのテーブル生成の別の例示的スクリーンショット及び使用を示す。
【図９Ａ】本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第１のスキームを示すブロック図である。
【図９Ｂ】本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第２のスキームを示すブロック図である。
【図９Ｃ】本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第３のスキームを示すブロック図である。
【図１０】本発明の一実施形態による例示的具現化のブロック図である。
【図１１Ａ】本発明の一実施形態による図１０のクラス追跡構造１０９２の一例を示すブロック図である。
【図１１Ｂ】本発明の一実施形態による図１０のインスタンス追跡構造１０６５の一例を示すブロック図である。
【図１１Ｃ】本発明の一実施形態による図１０のプロデューサグラフ構造１０６０の一例を示すブロック図である。
【図１１Ｄ】本発明の一実施形態による図１０のメソッド追跡構造１０５８の一例を示すブロック図である。
【図１２】本発明の一実施形態によりコンティンジェント及びサブスクリプション形式のダイナミックプロデューサ依存性をサポートするための図１０の付加的な細部を示すブロック図である。
【図１３Ａ】本発明の一実施形態による非ショートカット宣言、非ダイナミック（非コンティンジェント、非サブスクリプション）依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。
【図１３Ｂ】本発明の一実施形態による例示的非ショートカット宣言、非ダイナミック（非コンティンジェント、非サブスクリプション）プロデューサ依存性を示すプロデューサのブロック図である。
【図１３Ｃ】本発明の一実施形態による非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。
【図１３Ｄ】本発明の一実施形態による例示的非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。
【図１３Ｅ】本発明の一実施形態による非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性の両方を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。
【図１３Ｆ】本発明の一実施形態による非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。
【図１３Ｇ】本発明の一実施形態によるショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、非コンティンジェント、非サブスクリプションのプロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。
【図１３Ｈ】本発明の一実施形態による例示的ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、非コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。
【図１３Ｉ】本発明の一実施形態によるショートカット宣言、非ダイナミック（非コンティンジェント、非サブスクリプション）プロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。
【図１３Ｊ】本発明の一実施形態による例示的ショートカット宣言、非ダイナミックプロデューサ依存性を示すプロデューサのブロック図である。
【図１４Ａ】本発明の一実施形態による図１２のサブスクリプションログ１２５０の一例を示すブロック図である。
【図１４Ｂ】本発明の一実施形態による非コンティンジェント、アブソーブサブスクリプションプロデューサ依存性を示す例示的プロデューサのブロック図である。
【図１４Ｃ】本発明の一実施形態による非コンティンジェント、スティッキーサブスクリプションプロデューサ依存性を示す例示的プロデューサのブロック図である。
【図１４Ｄ】本発明の一実施形態により、スティッキーサブスクリプションにより生成される親依存性決定プロデューサに基づく親プロデューサの選択を示す。
【図１４Ｅ】本発明の一実施形態により、シーケンス依存性によりリンクされる子依存性決定プロデューサによって生成される親依存性決定プロデューサに基づく親プロデューサの選択を示す。
【図１５】本発明の一実施形態により新たなインスタンスをインスタンス生成するためのフローチャートである。
【図１６】本発明の一実施形態により新たなプロデューサ及び非オーバーライドプロデューサをインスタンス生成するためのフローチャートである。
【図１７】本発明の一実施形態による図１６のブロック１６５０のフローチャートである。
【図１８】本発明の一実施形態による図１７のブロック１７４５のフローチャートである。
【図１９】本発明の一実施形態による図１６Ａのブロック１６３０のフローチャートである。
【図２０】本発明の一実施形態による図１６Ａのブロック１６３５及び１６７０のフローチャートである。
【図２１】本発明の一実施形態によりプロデューサをオーバーライドするためのフローチャートである。
【図２２Ａ】本発明の一実施形態により現在プロデューサグラフを実行するためのフローチャートの一部分である。
【図２２Ｂ】本発明の一実施形態により現在プロデューサグラフを実行するためのフローチャートの別の部分である。
【図２３】本発明の一実施形態による図２２のブロック２２０５に対するフローチャートである。
【図２４】本発明の一実施形態による図２２のブロック２２２５に対するフローチャートである。
【図２５】本発明の一実施形態による図２２のブロック２２６０に対するフローチャートである。
【発明を実施するための形態】
【００３０】
以下の説明において、本発明をより完全に理解するために、ロジックの具現化、ｏｐコード、オペランドを指定する手段、リソースの区分化／分担／複製の具現化、システムコンポーネントの形式及び相互関係、並びにロジックの区分化／一体化の選択のような多数の特定の細部について述べる。しかしながら、当業者であれば、このような特定の細部を伴わずに本発明を実施できることが明らかであろう。他の点では、本発明を不明瞭にしないため、制御構造、データ構造、及び全ソフトウェアインストラクションシーケンスは、詳細に示さない。当業者であれば、過度の実験を行わなくても、ここに含まれた説明で、適切な機能を具現化することができるであろう。
【００３１】
特に指示のない限り、（分割の破線を除いて）図中の破線は、図中でオプションアイテムを表すのに使用される。しかしながら、破線を使用して全てのオプションアイテムを示すことを想定してはおらず、破線で示されたものは、種々の理由で選択されたものである（例えば、より明瞭にするために、容易に示すことができる、等）。
【００３２】
本明細書において、「１つの実施形態」、「一実施形態」、「例示的な実施形態」、等は、ここに述べる実施形態が、特定の特徴、構造又は特性を含むが、各々の実施形態が、必ずしも、特定の特徴、構造又は特性を含まなくてもよいことを指示する。更に、このような句は、必ずしも、同じ実施形態を指すものではない。更に、特定の特徴、構造又は特性が、ある実施形態に関連して説明されるときには、他の実施形態が明確に説明されるかどうかに関わらず、他の実施形態に関連してこのような特徴、構造又は特性に作用を及ぼすことも、当業者の知識の中でなし得るものとする。
【００３３】
以下の説明及び特許請求の範囲において、「結合(coupled)」及び「接続(connected)」という語は、その派生語と共に、使用することができる。これらの語は、互いに類義語として意図されないことを理解されたい。むしろ、特定の実施形態において、「接続」は、２つ以上のエレメントが互いに直接接触することを示すのに使用される。「結合」は、２つ以上のエレメントが直接接触することを意味する。しかしながら、「結合」は、２つ以上のエレメントが互いに直接的に接触していないが、それでも、互いに協働又は相互作用することも意味する。
【００３４】
あるケースでは、フローチャートのオペレーションを、他のブロック図の例示的な実施形態を参照して説明する。しかしながら、フローチャートのオペレーションは、他のブロック図を参照して述べるもの以外の本発明の実施形態によって遂行することができ、且つ他のブロック図を参照して述べる本発明の実施形態は、フローチャートを参照して述べるもの以外のオペレーションを遂行できることを理解されたい。
【００３５】
図示された技術は、１つ以上のコンピュータに記憶されて実行されるコード及びデータを使用して具現化することができる。このようなコンピュータは、マシン読み取り可能な媒体、例えば、マシン記憶媒体（例えば、磁気ディスク、光学ディスク、ランダムアクセスメモリ、リードオンリメモリ、フラッシュメモリ装置）、及びマシン通信媒体（例えば、電気的、光学的、音響的、又は他の形態の伝播信号、例えば、搬送波、赤外線信号、デジタル信号、等）を使用して、コード及びデータを記憶し通信する（内部で及びネットワークを経て他のコンピュータと）。更に、このようなコンピュータは、典型的に、１つ以上の他のコンポーネント、例えば、記憶装置、多数のユーザ入力／出力装置（例えば、キーボード及びディスプレイ）、及びネットワーク接続部に結合された１つ以上のプロセッサのセットを含む。プロセッサのセット及び他のコンポーネントの結合は、典型的に、１つ以上のバス及びブリッジ（バスコントローラとも称される）を通して行われる。記憶装置及びネットワークトラフィックは、各々、１つ以上のマシン記憶媒体及びマシン通信媒体を表す。従って、所与のコンピュータシステムの記憶装置は、典型的に、そのコンピュータの１つ以上のプロセッサのセットにおいて実行されるコード及びデータを記憶する。もちろん、本発明の一実施形態の１つ以上の部分は、ソフトウェア、ファームウェア及び／又はハードウェアの異なる組合せを使用して具現化することができる。
【００３６】
概略
本発明の１つの態様によれば、プロデューサは、少なくとも特定のインスタンス（又はオブジェクト）及び特定のメソッドであり、プロデューサがランタイム中に実行される場合には、特定のメソッドが特定のインスタンスにおいて実行される。従って、所与のプロデューサは、所与のインスタンス、及びそのインスタンスに関連した所与のメソッドからインスタンス生成される。クラス、インスタンス及びメソッドと同様に、プロデューサは、ランタイムにより操作される基本的エレメント又はコンストラクトである。従って、プロデューサのインスタンス生成がランタイムによって解釈されて追跡され、従って、ランタイムは、プロデューサにより表わされたインスタンス及びメソッドの組合せを追跡する。換言すれば、プロデューサは、ランタイムインスタンス生成可能な構造であって、これは、ランタイムにより追跡され、即ちランタイムにより実行され、且つ少なくともインスタンスと、そのインスタンスに関連したメソッドとを含み、プロデューサのランタイム実行の結果として、プロデューサのメソッドがプロデューサのインスタンスにおいて実行されるようになる。又、プロデューサのメソッドには、０以上のプロデューサ依存性のセットで、所与のプロデューサに対する０以上のプロデューサのセットを識別するプロデューサ依存性宣言が関連付けられる。より詳細には、プロデューサ依存性は、プロデューサ依存性宣言を使用してメソッドに対して宣言され、所与のメソッドに対するプロデューサ依存性宣言は、０以上のプロデューサ依存性を含み、そして各プロデューサ依存性は、０以上のプロデューサのセットを識別する。従って、プロデューサ依存性宣言、及びそれらが定義するプロデューサ依存性は、ランタイムによって解釈されて追跡され、従って、ランタイムは、プロデューサ依存性宣言により指示されたプロデューサ間の関係を追跡する。
【００３７】
所与のプロデューサが、１つ以上の他のプロデューサのセットに依存する場合には、ランタイムは、所与のプロデューサの前に、他のプロデューサのセットの実行を保証する。従って、プロデューサ依存性宣言は、プロデューサ間の実行関係を表し、一方、プロデューサは、実行されるべきオペレーション（メソッド）及びインスタンスを表す。本発明のある実施形態では、子プロデューサに対する親プロデューサの依存性を、親プロデューサのメソッドに関連したプロデューサ依存性宣言において宣言できる（親プロデューサのプロデューサ依存性宣言が子プロデューサを識別する−ここでは、ダウン方向に宣言されたと称される）が、本発明の他の実施形態では、子プロデューサ（１つ又は複数）のメソッド（１つ又は複数）に関連したプロデューサ依存性宣言において依存性を宣言することもできる（子プロデューサのプロデューサ依存性宣言が１つ以上の親プロデューサを識別する−ここでは、アップ方向に宣言されたと称される）。
【００３８】
本発明の異なる実施形態では、プロデューサは、付加的なものを識別する。例えば、本発明のある実施形態では、プロデューサは、少なくともインスタンスと、そのインスタンスに関連したメソッドとを含むが、本発明の他の実施形態では、プロデューサは、クラス、そのクラスのインスタンス、及びそのインスタンスに関連したメソッドである（例えば、あるプロデューサは、クラス、インスタンス、及びメソッドを直接含み、又、あるプロデューサは、インスタンス及びメソッドを直接含むが、リファレンス（例えば、インスタンスにおけるリファレンス）を通してそのインスタンスのクラスを間接的に識別する）。本発明は、異なるプログラミング言語で書かれたコード（例えば、リフレクティブなオブジェクト指向の言語で書かれたオブジェクト指向のコード、リフレクティブなオブジェクトベースの言語で書かれたオブジェクト指向のコード、手続き型、非リフレクティブなオブジェクト指向、非リフレクティブなオブジェクトベースの言語で書かれて、リフレクティブなオブジェクト指向の言語コードへ変換されたコード）のコンテクストに使用されるが、本発明の実施形態は、リフレクティブなオブジェクト指向のプログラミング言語を参照すると共に、クラス、インスタンス及びメソッドを直接含むプロデューサを参照して、一例として、非限定的に、説明する。又、本発明の一実施形態では、プロデューサのメソッドがインスタンスメソッド（引数として受け取られる入力に加えてインスタンスフィールドを使用できるメソッド）であるが、本発明の別の実施形態は、それに加えて又はそれとは別に、クラスメソッド（全ての入力を引数として受け取り及び／又はインスタンス独立変数を使用するメソッド）であるプロデューサのメソッドをサポートすることもできる（プロデューサのメソッドがインスタンスメソッドである場合には、そのプロデューサのインスタンスは、クラスのインスタンスであるが、プロデューサのメソッドがクラスメソッドである場合には、そのプロデューサのインスタンスは、クラスを表すメタクラスインスタンスである）。
【００３９】
図１Ａは、本発明の一実施形態により、オブジェクト指向のソースコードにおけるクラスのメソッドに対するプロデューサ依存性宣言と、そのクラス、そのクラスの所与のインスタンス、及びそのクラスのメソッドを含むプロデューサとの関係を示すブロック図である。図１Ａにおいて、オブジェクト指向のソースコード１００は、クラス１０２を含むように示され、このクラスは、次いで、メソッド１０４、及びメソッド１０４に対するプロデューサ依存性宣言１０６を含む。もちろん、クラス１０２は、典型的に、１つ以上のフィールド（図示せず）及び付加的なメソッド（図示せず）を含む。更に、オブジェクト指向のソースコード１００は、典型的に、付加的なクラスを含む。
【００４０】
ランタイム中に、クラス１０２のインスタンス１０８がインスタンス生成される。インスタンス１０８は、クラス１０２のフィールドのデータを含む。更に、プロデューサ１１０がインスタンス生成され、プロデューサ１１０は、クラス１０２、クラス１０２のインスタンス１０８（クラス１０２のメソッド１０４に関連した）、及びクラス１０２のメソッド１０４を識別する。プロデューサ依存性宣言１０６は、プロデューサ１１０を実行する前に実行されねばならない０以上のプロデューサ１１２のセット（プロデューサ１１０の子プロデューサと称される）をランタイムに対して識別する。換言すれば、プロデューサ１１０は、０以上のプロデューサ１１２のセットに依存する。プロデューサ１１２のセットの出力を消費するのに加えて又はそれに代わって、プロデューサ１１０は、インスタンス１０８のデータを消費することができる。更に、プロデューサ１１０は、少なくとも１つの出力を与え、この出力は、インスタンス１０８に対して内部であってもよく（従って、インスタンス１０８のデータを変更し）、及び／又は外部であってもよく、いずれにせよ、プロデューサ１１０の出力は、０以上の他のプロデューサ１１４のセット（プロデューサ１１０の親プロデューサと称される）によって消費することができる。又、上述したように、そして以下に詳細に述べるように、プロデューサ依存性宣言１０６は、本発明のある実施形態では、０以上のプロデューサ１１４をランタイムに対して識別することもできる。
【００４１】
プロデューサの入力及び出力は、そのプロデューサのベースとなるメソッドの入力及び出力をベースとすることを理解されたい。従って、これらの入力及び出力は、種々のデータ構造を有する複数のパラメータを表すことができる。
【００４２】
所与のメソッドに対するプロデューサ依存性宣言は、インスタンス生成されて実行されるべき０以上のプロデューサのセットをランタイムにおいて識別する。例えば、所与のメソッド（例えば、メソッド１０４）に対するプロデューサ依存性宣言（例えば、プロデューサ依存性宣言１０６）が、所与のプロデューサ（この所与のプロデューサは、第１クラス、そのクラスの第１インスタンス、及びその第１クラスの第１メソッドを識別する）（例えば、プロデューサ１１２のセットの１つ）に対するプロデューサ依存性を識別する場合には、所与のメソッドのプロデューサ依存性宣言は、第１インスタンスをインスタンス生成すべきである（まだそうでなければ）こと及び第１メソッドを使用して第１インスタンスに対して所与のプロデューサをインスタンス生成すべきであることをランタイムに対して識別する（これらの例において、第１とは、位置や順序を意味するものではない）。
【００４３】
オペレーションにおいて、ランタイムの間に、１つ以上のプロデューサの所与のセットが、関心のあるものであることが指示され、且つそれらに対して宣言されたプロデューサ依存性を有するときに、ランタイムは、１）１つ以上のグラフのセットを自動的に発生し（発見し、構築し、そして任意であるが、解明し）、これらグラフは、マルチレベルのものであり、且つ関心があると指示されたプロデューサの所与のセットから、プロデューサ依存性宣言に基づくソースプロデューサまで種々の形状（例えば、チェーン、ツリー）のものでよく、そして２）グラフのセットのプロデューサの実行をシーケンスして、関心があると指示されたプロデューサの所与のセットの出力（１つ又は複数）を発生する。従って、ランタイムは、プロデューサ依存性宣言を使用して、どんな引数を伴うどんなメソッドをどんなインスタントに対して同期のためにいつ実行すべきか決定する。
【００４４】
従って、プロデューサ依存性は、ランタイムに対するプロデューサの実行のシーケンスを表す。しかしながら、実行のシーケンスを指示するのに加えて、プロデューサ依存性は、本発明の異なる実施形態では、異なる入力対出力関係を表すことができる。例えば、本発明の異なる実施形態は、引数プロデューサ依存性、フィールドプロデューサ依存性、及びシーケンスのみのプロデューサ依存性の１つ以上をサポートすることができる（シーケンスのみのプロデューサ依存性は、ここでは、ショートハンドシーケンスプロデューサ依存性と称される）。引数プロデューサ依存性、フィールドプロデューサ依存性、及びシーケンスプロデューサ依存性の各々は、プロデューサ間の実行シーケンス関係を表すが、引数及びフィールドのプロデューサ依存性は、更に、ランタイムが気付くデータも表わす。より詳細には、引数プロデューサ依存性は、ランタイムが子プロデューサの出力を親プロデューサに対する入力パラメータとしてマップするようにさせ、一方、フィールドプロデューサ依存性は、インスタンスのフィールドの使用を指示する。プロデューサ依存性によって表わされる入力対出力関係には関わりなく、プロデューサ依存性の適切な使用は、プロデューサアクセス情報が、その情報に影響するプロデューサの後にシーケンスされるように保証する。
【００４５】
シーケンス依存性は、ランタイムが気付かない仕方でデータを変更するプロデューサと、そのデータを消費するプロデューサとの間で実行順序を保証することを含めて、種々の目的に使用される（子プロデューサは、その出力にアクセスするためのコードを含むことを親プロデューサのメソッドに要求する仕方でその出力を書く（例えば、普通のプロデューサ出力でない、従って、ランタイムにより検出されない出力に影響することにより環境に影響を及ぼすメソッド、例えば、グローバル変数をセットし、プロデューサ出力でないインスタンスにおけるフィールドをセットし、外部データソースに影響する、等のメソッド））。従って、シーケンス依存性は、子プロデューサに対する親プロデューサの依存性を反映するが、コードの書き込みを通して一方から他方へ与える必要のある出力を要求する（例えば、所与のメカニズムに出力を書き込むための子プロデューサのメソッドにおけるコード（例えば、グローバル変数をセットし、外部データソースに影響し、プロデューサ出力でないインスタンスのフィールドをセットし、等々）、及び所与のメカニズムからその出力を読み取るための親プロデューサのメソッドにおけるコード）。このように、シーケンス依存性は、ランタイムで検出できない出力に依存する親プロデューサの実行をランタイムが同期させられるようにする。
【００４６】
本発明の一実施形態では、所与のメソッドに対するプロデューサ依存性宣言は、プロデューサに対する直接的な依存性（例えば、直接的子孫（子供）、これとは対照的に間接的子孫（孫、曾孫、等）がある））のみを識別する。このような実施形態では、各プロデューサ依存性宣言は、所与のメソッドからインスタンス生成されたプロデューサにより出力を直接使用できるプロデューサの単一段又は層のみを与え、プロデューサグラフ（１つ又は複数）の付加的な層の発見／構築／解明は、他のプロデューサ依存性宣言のランタイムプロセッシングに託される。
【００４７】
例示的キー
プロデューサは、複数の識別子のセットとして見ることができ、指定の粒度の付加的なレベルごとに１つの識別子がある（クラス、インスタンス、メソッド、等）。更に、本発明のある実施形態は、各識別子を個別のキーとして具現化し、一方、他の実施形態は、幾つかの識別子が１つのキーを共有するようにする。例えば、本発明のある実施形態は、プロデューサを、クラス、インスタンス及びメソッドのトリプレットとして具現化し、そしてトリプレットの各部分が個別キー（クラスキー、インスタンスキー及びメソッドキー）により識別され且つプロデューサがクラスキー、インスタンスキー及びメソッドキーの組合せ（プロデューサキー）により識別されるように、キーを具現化する。
【００４８】
キーを使用する本発明の実施形態は、使用するキーの独特性が変化し得る。例えば、本発明の一実施形態では、各クラスキーが独特であり、各インスタンスキーは、全てのクラスの全てのインスタンスにわたって独特であり、そして各メソッドキーは、全てのクラスの全てのメソッドにわたって独特である。別の例として、本発明の他の実施形態では、各クラスが独特のキーを有し、所与のクラスの各インスタンスは、独特のキーを有し（クラスインスタンスにわたって）、そしてクラスの各メソッドは、独特のキーを有する（クラスメソッドにわたって）が、異なるクラスのインスタンスが同じインスタンスキーを有してもよく、且つ異なるクラスのメソッドが同じメソッドキーを有してもよく、この後者の解決策は、本書の残り部分において、一例として、非限定的に、使用される。例えば、第１クラスがメソッドを含むと共に、それらメソッドの各々に対し、第１クラス内で独特であるキーを有すると仮定すれば、このクラスのインスタンス（各々が互いに独特のキーを有する）には、同じメソッドキーが関連付けられる。別の例として、異なる第２クラスが、第１クラスに使用されたものと同じメソッドキーを有するメソッド（第１クラスのメソッドと幾つか同じ、全部同じ、又は全く同じでない）を含むと仮定する。従って、この異なるクラスのインスタンスには、第１クラスのインスタンスに関連付けられた同じメソッドキーが関連付けられてもよい。
【００４９】
これらキーの使用は、１）プロデューサの識別子によって識別された各エンティティを追跡すること（例えば、各クラス、インスタンス、及びメソッドの追跡）、２）多数の親プロデューサ（相互の存在に気付かない）がそれらのプロデューサ依存性宣言（これは、プロデューサキーを使用してプロデューサ依存性を指定する）に基づいて同じ子プロデューサに接続すること、等を含めて、種々の特徴を許す。本発明の一実施形態では、インスタンスキーは、キー識別子がインスタンス又は別のオブジェクト（ストリングのような）へのリファレンスであるかどうかを指示するインスタンスキー特性と、インスタンス又は別のオブジェクト（ストリングのような）のいずれかへのリファレンスであるキー識別子と、の２つのエレメントを保持するクラスのインスタンス（InstanceKey）である。インスタンスキーにインスタンスリファレンスを記憶することは、プログラマーがこれらのインスタンスを識別するための名前を創案することから逃れさせる。
【００５０】
例示的関係
プロデューサが複数の識別子のセット（指定の粒度の各付加的なレベルに対して１つの識別子をもつ）として見られることに関する前記説明に関連して、本発明の一実施形態では、プロデューサとその子供及び親との間の種々のサポートされる関係は、あるプロデューサと、０以上の親プロデューサのセットとの間で少なくとも１つのこのような識別子が異なり、且つあるプロデューサと、０以上の子プロデューサのセットの各々との間で１つのこのような識別子が異なるというものである。ある例示的関係を与えることにより、第１クラスの第１インスタンス及びその第１クラスの第１メソッドである第１プロデューサがインスタンス生成されると仮定し、且つその第１メソッドに対するプロデューサ依存性宣言がランタイムにおいて第２プロデューサを子供として識別すると仮定すると、第２プロデューサは、１）第１クラスの第１インスタンス及びその第１クラスの第２メソッドであり、２）第１クラスの第２インスタンス及びその第１クラスの第２メソッドであり、３）第１クラスの第２インスタンス及び第１クラスの第１メソッドであり、又は４）第２クラスのインスタンス及びその第２クラスのメソッドである。このようなケースでは、第１プロデューサは、第２プロデューサに依存し、従って、第２プロデューサに対する第１プロデューサの入力対出力関係を表す。種々の関係及びそれら関係の組合せは、オブジェクト指向の言語を使用する一実施形態であって、プロデューサが少なくともクラス、インスタンス及びメソッドを識別する本発明の実施形態について以下に説明する。
【００５１】
図１Ｂ−１Ｄは、本発明の一実施形態により、所与のプロデューサと、その親プロデューサのセットと、その子プロデューサのセットとの間の関係を例示する。図１Ｂ−１Ｄは、各々、次のものを示す。１）メソッド１０４Ａ−Ｃと、これらメソッドの各々に対するプロデューサ依存性宣言１０６Ａ−Ｃとを各々含むクラス定義１０２Ａ；２）メソッド１０４Ｄ−Ｅと、これらメソッドの各々に対するプロデューサ依存性宣言１０６Ｄ−Ｅとを各々含むクラス定義１０２Ｂ；３）メソッド１０４Ｆと、このメソッドに対するプロデューサ依存性宣言１０６Ｆとを含むクラス定義１０２Ｃ；４）クラス１０２Ａのインスタンス１０８Ａ；５）クラス１０２Ａ、インスタンス１０８Ａ及びメソッド１０４Ａを識別するプロデューサ１１０Ａ；及び６）プロデューサ１１２及び１１４のセットの１つを各々表わすプロデューサ１１２Ａ．１及びプロデューサ１１４Ａ．１。ボックス内に文字を伴う破線は、図１Ｂ−１Ｄにおいて、関係を例示するために使用される。従って、ボックス内にＡを伴う破線の集合は、１つの関係を表す。図１Ｂにおける関係は、図１Ｃにおける関係と組合せ可能であり、従って、これらの組合せは、プロデューサ１１０Ａに対する親プロデューサ１１４Ａと子プロデューサ１１２Ａとの関係の組合せを表している。更に、図１Ｄは、プロデューサ１１０Ａに対する親プロデューサ１１４Ａと子プロデューサ１１２Ａとの関係のある付加的な組合せを例示している。
【００５２】
図１Ｂは、本発明の一実施形態によるプロデューサ１１０Ａと親プロデューサ１１４Ａ．１との関係を例示している。図１Ｂは、更に、インスタンス１０８Ｂを含む。プロデューサ１１４のセットは、同じクラスの異なるメソッド（１つ又は複数）、同じクラスの異なるインスタンス、及び／又は異なるクラスのメソッド（１つ又は複数）の他のプロデューサ依存性宣言によって識別され、従って、プロデューサ１１４のセットの各々は、１）プロデューサ１１０Ａと同じインスタンス（クラス１０２Ａのインスタンス１０８Ａ）及びそのインスタンスに関連した異なるメソッド（インスタンス１０８Ａからプロデューサ１１４Ａ．１へ及びメソッド１０４Ｂからプロデューサ１１４Ａ．１への破線上のボックス内のＡにより示された）であり；２）クラス１０２Ａの異なるインスタンス及びそのインスタンスに関連した異なるメソッド（クラス１０２Ａからインスタンス１０８Ｂへ、インスタンス１０８Ｂからプロデューサ１１４Ａ．１へ及びメソッド１０４Ｂからプロデューサ１１４Ａ．１への破線上のボックス内のＢにより示された）であり；３）異なるクラスのインスタンス及びそのインスタンスに関連したメソッド（クラス１０２Ｂからインスタンス１０８Ｂへ、インスタンス１０８Ｂからプロデューサ１１４Ａ．１へ及びメソッド１０４Ｄからプロデューサ１１４Ａ．１への破線上のボックス内のＣにより示された）であり；又は４）クラス１０２Ａの（インスタンス１０８Ａとは）異なるインスタンス及びそのインスタンスの同じメソッド（メソッド１０４Ａ）（例えば、以下に述べるコンティンジェント依存性を伴う）（クラス１０２Ａからインスタンス１０８Ｂへ、インスタンス１０８Ｂからプロデューサ１１４Ａ．１へ及びメソッド１０４Ａからプロデューサ１１４Ａ．１への破線上のボックス内のＤにより示された）であり；更に、プロデューサ１１４のセットに複数のプロデューサがある場合には、プロデューサ１１４それ自体が、クラス１０２Ａの同じインスタンス、クラス１０２Ａの異なるインスタンス、異なるクラスのインスタンス、及び／又はそれらの混合、の一部分でもよい。
【００５３】
図１Ｃは、本発明の一実施形態によるプロデューサ１１０Ａと子プロデューサ１１２Ａ．１との関係を例示している。図１Ｃは、更に、インスタンス１０８Ｃを含む。プロデューサ１１２Ａのセットの各々は、１）プロデューサ１１０Ａと同じインスタンス（クラス１０２Ａのインスタンス１０８Ａ）及びそのインスタンスに関連した異なるメソッド（インスタンス１０８Ａからプロデューサ１１２Ａ．１へ及びメソッド１０４Ｃからプロデューサ１１２Ａ．１への破線上のボックス内のＥにより示された）であり；２）クラス１０２Ａの異なるインスタンス及びそのインスタンスに関連した異なるメソッド（クラス１０２Ａからインスタンス１０８Ｃへ、インスタンス１０８Ｃからプロデューサ１１２Ａ．１へ及びメソッド１０４Ｃからプロデューサ１１２Ａ．１への破線上のボックス内のＦにより示された）であり；３）異なるクラスのインスタンス及びそのインスタンスに関連したメソッド（クラス１０２Ｃからインスタンス１０８Ｃへ、インスタンス１０８Ｃからプロデューサ１１２Ａ．１へ及びメソッド１０４Ｆからプロデューサ１１２Ａ．１への破線上のボックス内のＧにより示された）であり；又は４）クラス１０２Ａの（インスタンス１０８とは）異なるインスタンス及びそのインスタンスの同じメソッド（メソッド１０４Ａ）（例えば、以下に述べるコンティンジェント依存性を伴う）（クラス１０２Ａからインスタンス１０８Ｃへ、インスタンス１０８Ｃからプロデューサ１１２Ａ．１へ及びメソッド１０４Ａからプロデューサ１１２Ａ．１への破線上のボックス内のＨにより示された）である。従って、プロデューサ１１２Ａのセットの各々は、プロデューサ１１０Ａの同じインスタンス、クラス１０２Ａの異なるインスタンス、又は異なるクラスのインスタンスでよく、更に、プロデューサ１１２Ａのセットに複数のプロデューサがある場合には、プロデューサ１１２Ａそれ自体が、クラス１０２Ａの同じインスタンス、クラス１０２Ａの異なるインスタンス、異なるクラスの同じインスタンス、異なるクラスの異なるインスタンス、及び／又はそれらの混合の一部分でもよい。
【００５４】
図１Ｄは、本発明の一実施形態による親プロデューサ１１４及び子プロデューサ１１２とプロデューサ１１０Ａとの関係の付加的な組合せを例示している。図１Ｄは、更に、インスタンス１０８Ｂ及びインスタンス１０８Ｃを含む。図１Ｄの組合せを以下のテーブル１に示す。
テーブル１
2010511234.tif 000003
【００５５】
図１Ｅは、本発明の一実施形態により、同じクラスの異なるインスタンスが同じ及び／又は異なるメソッドに基づきプロデューサを有することができることを示す。図１Ｅは、次のものを示す。即ち、１）クラス定義１０２Ａが、メソッド１０４Ａ−Ｃと、各メソッドに対するプロデューサ依存性宣言１０６Ａ−Ｃを各々含むこと；２）インスタンス１０８Ａ及びインスタンス１０８Ｂがクラス１０２Ａのものであること；３）プロデューサ１１０Ａが、クラス１０２Ａのインスタンス１０８Ａのメソッド１０４Ａであること；４）プロデューサ１１０Ｂが、クラス１０２Ａのインスタンス１０８Ａのメソッド１０４Ｂであること；５）プロデューサ１１０Ｃが、クラス１０２Ａのインスタンス１０８Ｂのメソッド１０４Ａであること；及び６）プロデューサ１１０Ｄが、クラス１０２Ａのインスタンス１０８Ｂのメソッド１０４Ｃであること。更に、図１Ｄは、次のことを示す。即ち、１）メソッド１０４Ａのプロデューサ依存性宣言１０６Ａが、ランタイムにおいて、プロデューサ１１０Ａ及びプロデューサ１１０Ｃの両方の子プロデューサを識別すること；２）メソッド１０４Ｂのプロデューサ依存性宣言１０６Ｂが、ランタイムにおいて、プロデューサ１１０Ｂの子プロデューサを識別すること；及び３）メソッド１０４Ｃのプロデューサ依存性宣言１０６Ｃが、ランタイムにおいて、プロデューサ１１０Ｄの子プロデューサを識別すること。
【００５６】
例示的ランタイム
図２は、本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムの再使用性を示すブロック図である。図２において、複数のオブジェクト指向のアプリケーションプログラム（プロデューサ依存性宣言を伴うオブジェクト指向のアプリケーションコード２１０Ａ−Ｉ）は、プロデューサグラフ指向のプログラミングサポートを伴う同じランタイム２２０によって実行される。
【００５７】
図３Ａは、本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。図３Ａにおいて、プロデューサグラフ指向のプログラミングサポート３３５を伴うランタイムは、自動プロデューサグラフ発生モジュール３４０及びプロデューサグラフ実行モジュール３４５を含む。更に、ランタイム３３５は、オブジェクト指向のソースコードを実行するもので、従って、図示されていない付加的なモジュールを含む。
【００５８】
更に、図３Ａは、オブジェクト指向のソースコードにおけるメソッドのためのプロデューサ依存性宣言３２０、出力が問題である１つ以上のプロデューサの現在セット３２５（ここでは、問題とする現在選択されたプロデューサと称される）、及びソースプロデューサの出力３３０（以下で説明する）を示している。自動プロデューサグラフ発生モジュール３４０は、プロデューサ依存性宣言３２０、及び問題とするプロデューサの現在セット３２５を受け取る。
【００５９】
自動プロデューサグラフ発生モジュール３４０は、問題とする現在選択されたプロデューサの入力に直接的及び間接的に貢献する出力を伴う子プロデューサ（及び上方宣言依存性をサポートする本発明の幾つかの実施形態では、親プロデューサ）をプロデューサ依存性宣言に基づいて発見するよう試み、そして問題とする現在選択されたプロデューサから、非ソースプロデューサである発見されたプロデューサを経て、ソースプロデューサである発見されたプロデューサのものまで、プロデューサの互いの依存性を表すプロデューサの１つ以上の現在グラフのセットを構築する。現在プロデューサグラフ（１つ又は複数）は、プロデューサグラフ（１つ又は複数）構造３８０に記憶される。本発明の実施形態は、プロデューサグラフ（１つ又は複数）をグラフの集合として記憶するが、本発明の他の実施形態では、（グラフの集合ではなく）グラフ（１つ又は複数）を形成するように互いにリンクされてプロデューサグラフの合併及び分割を容易にするプロデューサの集合としてプロデューサグラフ（１つ又は複数）を記憶し操作することもできる。例えば、これに限定されないが、プロデューサの集合としてプロデューサグラフ（１つ又は複数）を記憶し操作する本発明の実施形態をここに説明する。
【００６０】
プロデューサグラフ実行モジュール３４５は、自動プロデューサグラフ発生モジュール３４０からの現在プロデューサグラフ（１つ又は複数）及びソースプロデューサ３３０の出力を受け取り、そして現在プロデューサグラフ（１つ又は複数）のプロデューサを実行して、問題とする現在選択されたプロデューサの現在出力を決定する。プロデューサグラフ実行モジュール３４５は、プロデューサ出力キャッシング３８４により示されたようにプロデューサグラフ構造３８０にプロデューサの現在出力をキャッシュ記憶する。
【００６１】
実行中にプロデューサグラフのプロデューサ出力をキャッシュ記憶することで同期をとることができる。例えば、複数の子プロデューサに依存する親プロデューサを実行する適切な時間は、複数の子プロデューサが全て実行された後であり、換言すれば、子プロデューサの１つが実行を完了するたびに親プロデューサを実行するのは無駄である（あるケースでは、不可能である）。プロデューサ出力をキャッシュ記憶することは、親プロデューサの実行を、全ての子プロデューサが実行されてしまうまで延期できるだけでなく、親プロデューサを実行するための適切な時間、即ち全ての子プロデューサが実行されてそれらの出力がキャッシュ記憶されるとき、を決定できるようにする。従って、ランタイムは、子プロデューサの実行状態をチェックすることによりプログラマーに対してこの同期判断を行い、換言すれば、このような同期が自動化される（プログラマーは、インスタンスを識別して、そのインスタンスに対してそのインスタンスに関連した所与のメソッドを実行するための適切な時間を決定する個別のソースコードを含ませる必要がない）。別の例として、複数の親プロデューサが同じ子プロデューサ及び他の異なる子プロデューサに依存する場合には、複数の親プロデューサの各々を実行するための適切な時間が典型的に異なり、ランタイムは、子プロデューサのセットの出力の利用性に基づいて複数の親プロデューサの各々を実行するための適切な時間を自動的に決定する。
【００６２】
以下に詳細に述べるように、プロデューサグラフのある部分は、ダイナミックなプロデューサ依存性のために現在発見できないことがあるので、自動プロデューサグラフ発生モジュール３４０は、プロデューサグラフ全体を発見し構築するように「試みる」が、あるプロデューサが実行されるまでは、最初にプロデューサグラフ全体を完了できないことがある。従って、プロデューサグラフ実行モジュール３４５は、現在プロデューサグラフの実行中に必要なプロデューサ出力を伴う自動プロデューサグラフ発生モジュール３４０をインボークし、現在プロデューサグラフの未解明の残部を完了することができる（これは、図３Ａにおいて、プロデューサグラフ実行モジュール３４５から自動プロデューサグラフ発生モジュール３４０への矢印付き破線で示されており、矢印付き破線は、このようなサポートが任意であるために使用されている）。
【００６３】
図４Ａは、本発明の一実施形態による例示的プロデューサグラフの発見及び構築を示すブロック図である。図４Ａは、問題とするプロデューサの現在セットがプロデューサ１より成ることを示す。プロデューサ及びそのプロデューサ依存性宣言に基づいて、プロデューサ２及びプロデューサ３が発見される。換言すれば、プロデューサ１に対するプロデューサ依存性宣言は、プロデューサ１への入力がプロデューサ２及びプロデューサ３の実行を要求することを示す。従って、プロデューサ１は、従属プロデューサ（１つ以上のプロデューサ依存性を有するプロデューサ）である。又、図４Ａは、プロデューサ３が独立プロデューサ（プロデューサ依存性をもたず、従って、ソースプロデューサであるプロデューサ）であるが、プロデューサ２は、そうでないことも示す。その結果、プロデューサ２のプロデューサ依存性宣言に基づき、プロデューサ４及びプロデューサ５が発見される。図２Ａにおいて、プロデューサ４及びプロデューサ５は、独立プロデューサ（従って、ソースプロデューサ）である。
【００６４】
図４Ｂは、本発明の一実施形態により図４Ａのプロデューサグラフの初期実行を示すブロック図である。図４Ｂにおいて、矢印付きの曲線は、あるプロデューサを実行して出力を発生し、それが別のプロデューサへ入力として与えられることを示す。図３Ａに示すように、ソースプロデューサ３３０の出力は、プロデューサグラフ実行モジュール３４５に与えられ、対照的に、従属プロデューサ１−２の出力は、図４Ｂに示すようにプロデューサの実行によって決定される。従って、図４Ｂでは、次のことが生じる。即ち、１）ソースプロデューサ４及びソースプロデューサ５の出力が従属プロデューサ２に与えられ、従属プロデューサ２が実行され、３）従属プロデューサ２及びソースプロデューサ３の出力がプロデューサ１に与えられ、そして４）プロデューサ１が実行され、且つその出力が、問題とする現在出力として与えられる。図４Ｂのプロデューサグラフは、データがグラフを上るようにあるプロデューサから別のプロデューサへ流れる方向に駆動されるデータであることに注意する価値がある。
【００６５】
従って、プロデューサ依存性宣言３２０は、発生されると考えられるプロデューサグラフの境界を定め、一方、問題とするプロデューサの現在選択セット３２５は、発生されるべき現在プロデューサグラフの開始ノード（１つ又は複数）を識別する。これらの２つから、自動プロデューサグラフ発生モジュール３４０がプロデューサグラフを発見して構築する。発見及び構築は、自動プロデューサグラフ発生モジュール３４０に、プロデューサグラフ（例えば、プログラマーにより手動で識別される必要がない）も、プロデューサグラフ内のプロデューサのリストも与えられないという点で、自動的である。むしろ、自動プロデューサグラフ発生モジュール３４０は、問題とするプロデューサの現在選択セットのプロデューサ依存性宣言（１つ又は複数）を構文解析して、それらの子プロデューサ（及び上方宣言依存性をサポートする本発明の幾つかの実施形態では、親プロデューサ）を発見し、次いで、それらの発見されたプロデューサのプロデューサ依存性宣言を構文解析し、等々で、ソースプロデューサまで行う（以下に述べる本発明のある実施形態では、これは、プロデューサグラフ実行モジュール３４５の助けで行われてもよい）。プロデューサグラフがツリーである場合には、問題とする現在選択されたプロデューサが典型的に根(root)ノードであり、プロデューサ依存性宣言は、葉(leaf)ノード（ソースプロデューサ）が発見されるまで構文解析される。
【００６６】
オーバーライドされたプロデューサ及び増分的実行
図３Ｂは、本発明の一実施形態により、増分的実行及びオーバーライドされたプロデューサ出力もサポートするプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。増分的実行及びオーバーライドされたプロデューサ出力は、各々、独立した任意の特徴であり、従って、本発明の異なる実施形態では、一方を具現化してもよいし、両方を具現化してもよいことを理解されたい。
【００６７】
図３Ｂにおいて、プロデューサグラフ指向のプログラミングサポートを伴うランタイム３６０は、自動プロデューサグラフ発生モジュール３６５、プロデューサグラフ実行モジュール３７０、及びオーバーライドプロデューサ出力モジュール３９０を備えている。ランタイム３６０は、オブジェクト指向のソースコードを実行するものであり、従って、図示されていない付加的なモジュールを備えている。
【００６８】
更に、図３Ｂは、オブジェクト指向のソースコードにおけるメソッドに対する依存性宣言３２０、出力が問題である１つ以上のプロデューサの現在セット３２５（ここでは、問題とする現在選択されたプロデューサとも称される）、及びソースプロデューサの出力３５０も示している。ソースプロデューサの出力３５０は、ソースコードにおける独立プロデューサセットの出力３５２（例えば、定数、デフォールト値、等）、及び現在オーバーライドされたプロデューサ出力３５４（出力が現在オーバーライドされた独立プロデューサ及び／又は従属プロデューサの出力）を含む。
【００６９】
本発明のある実施形態では、プロデューサの出力は、現在与えられた値で明確にオーバーライドすることができる（即ち、プロデューサを実行してその現在入力に基づいてその出力値を決定するのではなく、プロデューサに対する出力値が明確に与えられる）。プロデューサグラフの独立プロデューサに加えて、プロデューサグラフのソースプロデューサは、現在オーバーライドされたプロデューサを含む。
【００７０】
オーバーライドプロデューサ出力モジュール３９０は、オーバーライドされたプロデューサ出力３５４を受け取る（これは、どのプロデューサがオーバーライドされそしてどんな出力値でオーバーライドされるか識別する）。本発明の一実施形態では、プロデューサは、プロパティプロデューサ又はメソッドプロデューサとして分類することができる。プロパティプロデューサは、プロパティメソッド（例えば、ゲット及びセット）に基づくものである。メソッドプロデューサは、非プロパティメソッドに基づくものである。オーバーライドプロデューサ出力モジュール３９０は、オーバーライドされたプロパティプロデューサのためのオーバーライドプロパティプロデューサ出力モジュール３９２と、オーバーライドされたメソッドプロデューサのためのオーバーライドメソッドプロデューサ出力モジュール３９４とを備えている。オーバーライドプロパティプロデューサ出力モジュール３９２は、オーバーライドされた値を、プロデューサ出力キャッシング３８４及びインスタンスのデータに記憶させ、一方、オーバーライドメソッドプロデューサ出力モジュール３９４は、オーバーライドされた値をプロデューサ出力キャッシング３８４に記憶させる。本発明の実施形態に基づき、この因果関係は、直接的でも間接的でもよい。図３Ｂは、オーバーライドログ３９６を使用して間接的に行わせることを示し、このオーバーライドログは、オーバーライドプロデューサ出力モジュール３９０の出力を収集するもので、プロデューサグラフ実行モジュール３７０によって消費される。最適化のために、オーバーライドロジック３９６は、オーバーライドを遅延させ、複数のオーバーライドをバッチ処理のために収集できるようにする。
【００７１】
自動プロデューサグラフ発生モジュール３４０と同様に、自動プロデューサグラフ発生モジュール３６５は、１）プロデューサ依存性宣言３２０及び問題とするプロデューサの現在セット３２５を受け取り、そして２）プロデューサ依存性宣言に基づいて、問題とする現在選択されたプロデューサの入力に直接的及び間接的に貢献する出力を伴う子プロデューサ（及び上方宣言依存性をサポートする本発明の幾つかの実施形態では、親プロデューサ）を発見し、且つ問題とする現在選択されたプロデューサから、発見された非ソースプロデューサを経て、ソースプロデューサ（独特プロデューサ及び現在オーバーライドされたプロデューサ）である発見されたプロデューサのものまで、プロデューサの互いの入力依存性を表すプロデューサの１つ以上の現在グラフのセットを構築するように試みる。プロデューサグラフ（１つ又は複数）は、プロデューサグラフ（１つ又は複数）構造３８０に記憶される。
【００７２】
プロデューサグラフ実行モジュール３４５と同様に、プロデューサグラフ実行モジュール３７０は、自動グラフモジュール３６５からの現在プロデューサグラフ及びソースプロデューサ３５０の出力を受け取り、そして現在プロデューサグラフのプロデューサを実行して、問題とする現在選択されたプロデューサの現在出力を決定する。プロデューサグラフ実行モジュール３７０は、プロデューサ出力キャッシング３８４により示されたように、プロデューサグラフ構造３８０にプロデューサの現在出力をキャッシュ記憶する。
【００７３】
上述したように、実行中にプロデューサ出力をキャッシュ記憶することで同期をとることができる（例えば、図４Ｂのプロデューサ２をいつ実行すべきか決定するために個別のソースコードを書き込む必要がなく、むしろ、ランタイムは、プロデューサ出力キャッシング３８４において必要な出力が利用できることをチェックすることによりプログラマーに対してこの同期判断を実行し、換言すれば、このような同期が自動化される）。更に、このプロデューサ出力キャッシング３８４は、増分的実行に使用される。より詳細には、プロデューサグラフが最初に発生されて実行された後に、現在プロデューサグラフにおけるプロデューサをオーバーライドするのに、ある程度の再実行レベルが要求される。本発明のある実施形態は、グラフ全体を単純に再実行するが、本発明の別の実施形態は、増分的実行をサポートする（オーバーライドにより影響されるプロデューサグラフの部分のみを再実行する）。増分的実行をサポートするある例示的実施形態は、どのプロデューサが再実行を要求するか決定する上で助けとなるように、プロデューサグラフ（１つ又は複数）構造３８０に増分的実行マーキング３８２を使用する。従って、プロデューサグラフ（１つ又は複数）を維持することは、複数の実行にわたって必要に応じてプロデューサグラフ（１つ又は複数）のリンクを変更して、それらを現在状態（最新状態）に保持することを指し、一方、増分的実行は、プロデューサグラフ（１つ又は複数）を維持し、且つ現在（最新）プロデューサグラフを使用して、オーバーライドにより影響されるプロデューサグラフ（１つ又は複数）の部分のみを再実行することを指す。
【００７４】
図３Ａと同様に、ダイナミック依存性に対する任意のサポートを表すために、プロデューサグラフ実行モジュール３７０から自動プロデューサグラフ実行モジュール３６５へと矢印付き破線が延びている。ダイナミック依存性は、プロデューサグラフの再実行中に変化し得ることに注意されたい。
【００７５】
図４Ｃは、本発明の一実施形態により図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。図４Ｃにおいて、プロデューサ５の出力は、明確に変更されているが、プロデューサ３及びプロデューサ４の出力は、変更されていない。プロデューサグラフにおける出力対入力依存性の追跡と、プロデューサ５の出力のみが明確に変更されていることに基づいて、プロデューサ２及びプロデューサ１だけがこの変更により影響されることが決定される。その結果、プロデューサ１の更新された出力を決定するのに、プロデューサ５の新たな出力と、プロデューサ４及びプロデューサ３の以前の出力とでプロデューサ２及びプロデューサ１を再実行することしか要求されない。プロデューサグラフのこの部分的な再実行は、図４Ｃにおいて、プロデューサ５からプロデューサ２へそしてプロデューサ２からプロデューサ１への矢印付き曲線が存在するが、プロデューサ４からプロデューサ２へ又はプロデューサ３からプロデューサ１へは存在しないことにより示される。プロデューサ４からプロデューサ２へ及びプロデューサ３からプロデューサ１への矢印付き曲線が存在しないことは、プロデューサ３及びプロデューサ４の出力が必要ないことを指示するのではなく、むしろ、プロデューサ３及びプロデューサ４の以前の出力が（例えば、プロデューサグラフの以前の実行からキャッシュ記憶されて）利用できる場合には、それらプロデューサを再実行する必要がないことを指示する。
【００７６】
図４Ｃの比較的簡単な例は、増分的実行の結果として処理リソースを節約できることを示している。このような節約は、多数のファクタ（例えば、再実行する必要のないプロデューサの数、それらプロデューサが要求する処理の量、等）に依存する。増分的実行を遂行する本発明の一実施形態が例示されたが、別の実施形態を別の仕方で具現化することもできる（例えば、別の実施形態は、変更に応答して全てのプロデューサを再実行することができる）。
【００７７】
図４Ｄは、本発明の一実施形態により従属プロデューサ２がオーバーライドされた後の図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。図４Ｄにおいて、プロデューサ２の出力は、明確に変更されているが、プロデューサ３の出力は、変更されていない。プロデューサグラフと、プロデューサ２の出力のみが明確に変更されたこととに基づいて、この変更によりプロデューサ１だけが影響されると決定される。その結果、プロデューサ１の更新された出力を決定するのに、プロデューサ２のオーバーライドされた出力と、プロデューサ３の以前の出力とでプロデューサ１を再実行することしか要求されない。プロデューサグラフのこの部分的再実行は、図４Ｄにおいて、プロデューサ２からプロデューサ１への矢印付き曲線が存在するが、プロデューサ４及び５からプロデューサ２へ又はプロデューサ３からプロデューサ１へは存在しないことにより示される。
【００７８】
図４Ｅは、本発明の一実施形態により従属プロデューサ２がオーバーライドされそして独立ソースプロデューサ３が変更された後の図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。プロデューサグラフと、プロデューサ２及びプロデューサ３の出力のみが変更されたこととに基づいて、この変更によりプロデューサ１だけが影響されると決定される。その結果、プロデューサ１の更新された出力を決定するのに、プロデューサ２のオーバーライドされた出力と、プロデューサ３の以前の出力とでプロデューサ１を再実行することしか要求されない。プロデューサグラフのこの部分的再実行は、図４Ｅにおいて、プロデューサ２及び３からプロデューサ１への矢印付き曲線が存在するが、プロデューサ４及び５からプロデューサ２へは存在しないことにより示される。
【００７９】
オーバーライドプロデューサ出力をサポートする本発明の一実施形態は、非オーバーライドプロデューサ出力もサポートするが、本発明の別の実施形態は、そのようにしない。非オーバーライドプロデューサをサポートする本発明の一実施形態は、オーバーライドされたプロデューサを、それが特に非オーバーライドされるまで、オーバーライドされたままにするが、本発明の別の実施形態は、異なる仕方で具現化されてもよい（例えば、オーバーライドされたプロデューサを、その子孫の１つがオーバーライドされるときに非オーバーライド化する）。
【００８０】
プロデューサグラフ構築及び実行
本発明の異なる実施形態は、プロデューサグラフを発見して、異なる程度に構築するように具現化することができる（例えば、根ノードからの全ての経路が独立プロデューサにおいて終了するまでプロデューサグラフを構築し（このケースでは、プロデューサグラフの終了ノードが独立プロデューサであり、オーバーライドされたプロデューサが中間ノードであるおそれがある）；根ノードからの各経路が、オーバーライドされたプロデューサ又は独立プロデューサのいずれか最初に到着する方で終了するまで、プロデューサグラフを構築する（このケースでは、プロデューサグラフの各終了ノードが独立プロデューサ又はオーバーライドされたプロデューサのいずれかである））。
【００８１】
「実行スタートプロデューサ」とは、プロデューサグラフのプロデューサであって、そこからプロデューサグラフの所与の実行が開始されるプロデューサを指す。プロデューサグラフの初期実行に対して、異なる実施形態は、異なるプロデューサからスタートすることができる（例えば、根ノードからの全ての経路が独立プロデューサにおいて終了するまでプロデューサグラフを構築する本発明の実施形態では、終了ノード（これは独立プロデューサである）から；ソースプロデューサ（これは、独立プロデューサノード及び任意のオーバーライドされたプロデューサノードを含む）から；少なくとも１つの経路を間に伴う独立プロデューサと、オーバーライドされたプロデューサを含まない根プロデューサと、オーバーライドされたプロデューサとの組合せより成るソースプロデューサのサブセットから；或いはオーバーライドされた子孫を伴わないオーバーライドされたプロデューサと、少なくとも１つの経路を間に伴う独立プロデューサと、オーバーライドされたプロデューサを含まない根プロデューサとの組合せより成るソースプロデューサのサブセットから；実行をスタートすることができ、更に、オーバーライドされたプロデューサの下でのプロデューサグラフが、そのようなプロデューサが非オーバーライドである場合及び非オーバーライドにされるまで構築されないような本発明の実施形態では、終了ノード（独立プロデューサ及び／又はオーバーライドされたプロデューサである）から実行をスタートすることができ、等々である）。
【００８２】
プロデューサグラフのその後の実行に対して、異なる実施形態は、異なるプロデューサからスタートすることができる（例えば、プロデューサグラフの独立プロデューサから（例えば、増分的実行をサポートしない本発明の実施形態において）；プロデューサグラフのソースプロデューサから（例えば、増分的実行をサポートしない本発明の実施形態において）；最後の実行以来オーバーライドされ及び／又は追加されたソースプロデューサより成るソースプロデューサのサブセットから（例えば、増分的実行をサポートする本発明の実施形態において）；最後の実行以来オーバーライドされ及び／又は追加されたソースプロデューサのうち、オーバーライドされた子孫を伴わないオーバーライドされたプロデューサと、少なくとも１つの経路を間に伴う追加されたプロデューサと、オーバーライドされたプロデューサを含まない根プロデューサとの組合せから（例えば、増分的実行をサポートする本発明の実施形態において）；等）。例えば、これに限定されないが、次のことを遂行する本発明の実施形態について以下に述べる。１）このようなプロデューサが非オーバーライドにされる場合及びそれまで、オーバーライドされたプロデューサのもとでプロデューサグラフを構築せず；２）プロデューサグラフの初期実行に対してエンドノード（これは、独立プロデューサ及び／又はオーバーライドされたプロデューサでよい）の実行をスタートし；３）増分的実行を具現化し；及び４）プロデューサグラフのその後の実行に対して、最後の実行以来オーバーライド及び／又は追加されたソースプロデューサより成るソースプロデューサのサブセットから実行をスタートする。
【００８３】
実行スタートプロデューサの前記概念に関して、プロデューサグラフの実行の処理フローも、異なる実施形態の間で相違する。例えば、本発明の一実施形態では、実行スタートプロデューサの祖先が決定されて集合に入れられ、実行スタートプロデューサが実行され、そして全ての依存性が実行されたところのプロデューサに対して集合が繰り返しスキャンされ、最終的には、根ノードに到達する。別の例として、本発明の一実施形態では、実行スタートプロデューサが実行され、実行スタートプロデューサの親が識別され、それらの親が実行され、そしてそれらの親が識別されて実行され、等々となる。本発明の後者の実施形態を、一例として、非限定的に、以下に使用する。
【００８４】
依存性の例示的形式
例示的なダイナミックプロデューサ依存性
ダイナミックプロデューサ依存性は、ランタイム中に変化するプロデューサ依存性である。プロデューサ依存性を解明するための基準は、ソースコードに存在し、従って、プロデューサ依存性を解明できるプロデューサが制限される。図３Ａを参照すれば、プロデューサグラフ実行モジュール３４５から自動プロデューサグラフ発生モジュール３４０への矢印付き破線は、現在プロデューサグラフ全体を発見し構築するのに必要な現在プロデューサグラフにおける１つ以上のプロデューサを実行するためのサポートを表す。換言すれば、ダイナミックプロデューサ依存性をサポートする本発明の実施形態は、プロデューサグラフ全体が発見され、構築され、解明され及び実行されるまで、自働プロデューサグラフ発生モジュール３４０とプロデューサグラフ実行モジュール３４５との間を繰り返す（即ち、１）そのとき解明できる現在プロデューサグラフの部分を発見し構築するために自動プロデューサグラフ発生モジュールをインボークすることと、２）現在プロデューサグラフのプロデューサを実行するためにプロデューサグラフ実行モジュールをインボークすること、との間を繰り返す）。この意味で、発見とは、プロデューサ依存性宣言にアクセスし、それらが識別するプロデューサを決定することを指し、構築とは、プロデューサをインスタンス生成し、それらをプロデューサグラフに追加することを意味し、そして解明とは、現在解明されていないダイナミックプロデューサ依存性を決定することを指す。
【００８５】
図５Ａは、本発明の一実施形態により未解明の依存性を含む例示的プロデューサグラフの発見及び構築を示すブロック図である。図５Ａは、プロデューサ１より成る、問題とするプロデューサの現在セットを示す。プロデューサ１及びそのプロデューサ依存性宣言に基づいて、プロデューサ２及びプロデューサ３が発見される。換言すれば、プロデューサ１の依存性宣言は、プロデューサ１がプロデューサ２及びプロデューサ３の出力を入力として要求することを示す。又、図５Ａは、プロデューサ３は、独立プロデューサ（従って、ソースプロデューサ）であるが、プロデューサ２は、そうでないことも示している。その結果、プロデューサ２の依存性宣言に基づいて、プロデューサ４及びプロデューサ５が発見される。更に、図５Ａは、プロデューサ４は、独立プロデューサ（従って、ソースプロデューサ）であるが、プロデューサ５は、そうでないことも示している。その結果、プロデューサ５の依存性宣言に基づいて、プロデューサ６及び現在未解明の依存性が発見される。又、図５Ａは、現在未解明の依存性がプロデューサ７Ａ及び／又はプロデューサ７Ｂに対するものであることも示している。
【００８６】
図５Ｂは、本発明の一実施形態により、図５Ａのプロデューサグラフの初期の実行と、未解明の依存性の解明とを示すブロック図である。図５Ｂは、図５Ａのプロデューサグラフを示すもので、矢印付きの曲線は、プロデューサの実行と、それら出力の、従属親プロデューサへの付与とを示している。更に、図５Ｂは、プロデューサ５の未解明の依存性がプロデューサ７Ａに対する依存性として解明され、そしてプロデューサ７Ａが独立プロデューサであることを示している。
【００８７】
図５Ｃは、本発明の一実施形態により、図５Ａのプロデューサグラフの初期の実行及び／又は図５Ｂのプロデューサグラフの再実行を示すブロック図である。図５Ｃは、図５Ａのプロデューサグラフを示すもので、矢印付きの曲線は、プロデューサの実行と、それら出力の、従属親プロデューサへの付与とを示している。更に、図５Ｃは、プロデューサ５の未解明の依存性がプロデューサ７Ｂに対する依存性として解明され、そしてプロデューサ７Ｂが独立プロデューサであることを示している。その結果、プロデューサ７Ｂの依存性宣言に基づいて、プロデューサ８が発見される。プロデューサ８は、独立プロデューサ（従って、ソースプロデューサ）である。図５Ｃが、図５Ａのプロデューサグラフの初期実行を表すと仮定すれば、図５Ｃにおける全ての矢印付き曲線が使用される。しかしながら、図５Ｃが、図５Ｂのプロデューサグラフの再実行を表すと仮定すれば、再実行の結果、ダイナミック依存性が異なる仕方で解明される（プロデューサ５がプロデューサ７Ａに依存することからプロデューサ７Ｂに依存することへとスイッチする）。更に、再実行が増分的実行を伴わずに行われる場合には、図５Ｃにおける全ての矢印付き曲線が使用されるが、増分的実行が使用される場合には、矢印付き非破線曲線しか使用されない（プロデューサ８からプロデューサ７Ｂへ、プロデューサ７Ｂからプロデューサ５へ、プロデューサ５からプロデューサ２へ、及びプロデューサ２からプロデューサ１へ）。又、図５Ｃに示す依存性のダイナミック変化は、例示に過ぎず、従って、多数の異なる状況が生じ得ることも理解されたい（例えば、ダイナミックな変化が決して生じない；プロデューサ５が最初はプロデューサ７Ｂに依存し、次いで、プロデューサ７Ａへと変化する；プロデューサ５が最初はプロデューサ７Ｂに依存し、且つダイナミックな変化は、ずっと生じない；プロデューサ５が図５Ｄに示すようにプロデューサ７Ａ及び７Ｂの両方に依存することが分かる；等々）。異なる実施形態では、異なる仕方でダイナミックプロデューサ依存性を解明できるが、幾つかの例について以下に述べる。
【００８８】
従って、プロデューサグラフの自動再実行は、プロデューサが変更され且つその直接的な親が再実行されることに制限されず、むしろ、変化が、ランタイムによりプロデューサグラフを通して自動的に波及されて、適切なプロデューサ及び依存性に影響を及ぼす。というのは、プロデューサグラフが維持される（且つ増分的実行がサポートされるところでそれが使用される）からである。従って、変化は、必要な付加的な発見、構築、解明及び実行を生じさせる。従って、プロデューサグラフの再実行は、プロデューサグラフのどのプロデューサが影響されるかユーザ／プログラマーが決定しておそらく手動でグラフを修正する必要がないという意味で、自動的である。
【００８９】
スタティックプロデューサ依存性
スタティック依存性とは、ランタイム中に変化しないものである。従って、コンティンジェント及びサブスクリプションダイナミック依存性をサポートする本発明の実施形態では（以下に述べる）、非コンティンジェント、非サブスクリプション依存性がスタティック依存性である。図４Ａの例示的なプロデューサグラフは、スタティック依存性のプロデューサグラフを示している。
【００９０】
プロデューサグラフ形状
プロデューサは、少なくとも、インスタンス、及びそのインスタンスに関連したメソッドであるから、プロデューサグラフは、インスタンス及びそれらインスタンスに関連したメソッドを表すグラフであり、従って、プロデューサグラフは、少なくともインスタンス及びメソッド中心である。プロデューサが少なくともクラス、インスタンス及びメソッドである本発明の実施形態では、プロデューサグラフは、少なくともクラス、インスタンス及びメソッド中心である。
【００９１】
プロデューサグラフは、種々の異なる形状（例えば、プロデューサの単一チェーン、ツリー、等）をとり得ることを理解されたい。図５Ｂの例示的プロデューサグラフは、プロデューサ１の根ノードがあって、そこから、プロデューサ２及びプロデューサ３の各々へ２つの分岐があるツリーである。プロデューサ３が葉ノードである場合には、プロデューサ２は、そこから、プロデューサ４及びプロデューサ５の各々へ延びる２つの分岐を有する。プロデューサ５は、そこから、プロデューサ６及びプロデューサ７Ａへ各々延びる２つの分岐を有する。図５Ｂの例示的プロデューサグラフは、マルチレベルと言われ、レベル１は、ルード(rood)ノードプロデューサ１を含み、レベル２は、プロデューサ２及びプロデューサ３を含み、レベル３は、プロデューサ４及びプロデューサ５を含み、レベル４は、プロデューサ６及びプロデューサ７Ａを含む（図５Ｃでは、レベル４は、プロデューサ７Ｂを含み、そしてレベル５は、プロデューサ８を含む）。プロデューサ２を伴うプロデューサ１からの分岐を考慮するときには、分岐の第１プロデューサは、プロデューサ２であり、そして分岐の最後のプロデューサは、図５Ｂにおいて、プロデューサ４、プロデューサ６及びプロデューサ７Ａである。
【００９２】
図５Ｂは、問題とするプロデューサの現在セットが単一プロデューサを含むようなプロデューサグラフを示すが、問題とする２つ以上の現在プロデューサをサポートする本発明の実施形態は、その各々に対してプロデューサグラフを発見し構築する。問題とするプロデューサが同時に複数ある場合には、それにより得られるプロデューサグラフは、独立でもよいし、又は交差してもよいことを理解されたい。プロデューサグラフが交差する場合には、本発明の実施形態は、次のように具現化できる。即ち、１）個別のプロデューサグラフを維持するようにプロデューサを複製する；又は２）このような複製を回避し、交差するプロデューサグラフを維持する。又、このような交差するプロデューサグラフは、別のプロデューサグラフのサブセットであるプロデューサグラフを含んでもよいことも理解されたい。例えば、プロデューサ５が、問題とするプロデューサの現在セットにプロデューサ１と共に含まれた場合には、プロデューサ５の根ノードを伴う第１プロデューサグラフと、プロデューサ１の根ノードを伴う第２プロデューサグラフとがあり、ここで、第２プロデューサグラフが第１プロデューサグラフを含む。例えば、プロデューサ７Ｂが、問題とするプロデューサの現在セットにプロデューサ１及びプロデューサ５と共に含まれた場合には、第１及び第２のプロデューサグラフとは個別で、図５Ｂにおけるプロデューサ７Ｂの根ノードを伴う第３のプロデューサグラフがある。更に、プロデューサ５のダイナミック依存性がプロデューサ７Ａからプロデューサ７Ｂへと変化した場合には（図５Ｃ）、この変化の結果、第３プロデューサグラフは、残されている第２プロデューサグラフのサブセットとなり、且つ第２プロデューサグラフは、第１プロデューサグラフのサブセットとなる。上述したように、本発明の実施形態は、プロデューサグラフ（１つ又は複数）をグラフの集合として記憶し操作できるが、本発明の他の実施形態では、プロデューサグラフの合併及び分割を容易にするために、（グラフの集合ではなく）グラフ（１つ又は複数）を形成するように互いにリンクされるプロデューサの集合としてプロデューサグラフ（１つ又は複数）を記憶し操作することができる。一例として、これに限定されないが、プロデューサの集合としてプロデューサグラフ（１つ又は複数）を記憶し操作する本発明の実施形態をここに説明する。
【００９３】
例示的実行フロー
図６は、本発明の一実施形態により、ランタイムクライアントの論理的実行フローと、プロデューサグラフ指向のプログラミングサポートを伴うランタイムに対するその関係とを示すフローチャートである。図６において、破線の分割線６００は、ランタイムクライアント６１０の論理的実行フローを、プロデューサグラフ指向のプログラミングサポートを伴うランタイム６４０から分離している。
【００９４】
ランタイムクライアント６１０の論理的実行フローは、ブロック６１５、６２０、６２５及び６３０を含み、一方、プロデューサグラフ指向のサポートを伴うランタイム６４０は、ブロック６４５、６５０、６６０及び任意の６５５を含む。矢印付きの実線は、ブロック６３０からブロック６６０への直接的因果関係を示す。対照的に、矢印付きの点線は、ランタイムクライアント６１０の論理的実行フローにおけるブロック６１５及び６２５から、プロデューサグラフ指向のサポートを伴うランタイムにおけるブロック６４５及び６５０への因果関係を各々示し、本発明の実施形態に基づき、この因果関係は、直接的でも間接的でもよい。例えば、図６は、破線６００の、プロデューサグラフ指向のサポートを伴うランタイム６４０の側で、破線楕円におけるコマンドログ６６５の使用により任意の間接的な因果関係を示す。コマンドログ６６５は、コマンドログ６６５は、ランタイムクライアント６１０の論理的実行フローのブロック６１５及び６２５から生じるコマンドを収集し、そしてコマンドログ６６５は、ブロック６３０に応答して、処理ブロック６６０により消費される。従って、コマンドログ６６５は、コマンドを遅延させて、複数のコマンドを一緒に収集し、それらを最適化のためにバッチ処理できるようにする。従って、コマンドログ６６５は、図３Ｂのオーバーライドログ３９６と同様であり、実際上、本発明の幾つかの実施形態にはオーバーライドログ３９６が含まれる。
【００９５】
ブロック６１５において、問題とする１つ以上のプロデューサのセットは、問題とするプロデューサの現在セットとして決定され、制御がブロック６２０へ通される。ブロック６１５とブロック６４５との間の因果関係に応答して、ブロック６４５は、問題とするプロデューサの現在セットがインスタンス生成されることを示すと共に、ランタイムクライアント６１０におけるプロデューサ依存性宣言に基づき、インスタンス及びそのプロデューサを必要に応じてインスタンス生成することも含めて、各々プロデューサグラフ（１つ又は複数）を発見し、構築し、且つ解明するよう試みる（ダイナミック依存性がサポートされ且つその１つ以上がプロデューサグラフにおいて発見される場合に）ことを示す。図３Ａ及び３Ｂを参照すれば、自動プロデューサグラフ発生モジュール３４０及び３６５が各々インボークされる。
【００９６】
ブロック６２０において、プロデューサ出力オーバーライドがあるかどうか決定される。もしあれば、制御がブロック６２５へ回され、さもなければ、制御がブロック６３０へ回される。
【００９７】
ブロック６２５において、１つ以上のプロデューサ出力オーバーライドが、１つ以上のプロデューサのセットに対して受け取られ、制御がブロック６３０へ回される。ブロック６２５とブロック６５０との間の因果関係に応答して、ブロック６５０は、オーバーライドされたプロデューサの現在セットがインスタンス生成され（ブロック６４５においてまだインスタンス生成されていない場合）、それらの出力が変更され、そしてそれらが追跡されることを示す。オーバーライドされたプロデューサは、ブロック６４５においてプロデューサグラフ（１つ又は複数）の一部分であることが既に発見されているので、既にインスタンス生成されているかもしれない。しかしながら、オーバーライドされたプロデューサは、未解明のダイナミック依存性のものであるので、ブロック６４５においてまだ発見されていないかもしれない。従って、このオーバーライドされたプロデューサは、ダイナミック依存性が解明されたときにプロデューサグラフに追加されることを予想して、インスタンス生成されオーバーライドされる。又、既に述べたように、図３Ｂのオーバーライドログ３９６は、それが具現化された場合に、ブロック６２５とブロック６５０との間に存在し、そしてコマンドログ６６５の一部分となる。更に、オーバーライドされたプロデューサのセットは、増分的実行をサポートする本発明の幾つかの実施形態において追跡される。オーバーライドログ３９６／コマンドログ６６５をサポートする本発明の実施形態において、追跡はログの一部分であるが、本発明の別の実施形態では、追跡は、異なるメカニズムを伴うブロック６５０において個別に遂行される。
【００９８】
ブロック６３０において、プロデューサグラフ実行モジュールがインボークされ、そして制御がブロック６１５及び／又はブロック６２５へ任意に戻される。ブロック６３０とブロック６６０との間の因果関係に応答して、ブロック６６０は、現在プロデューサグラフ（１つ又は複数）がウォーキングされ、そして実行を要求するプロデューサが、追跡に基づいて実行される。プロデューサグラフのプロデューサを実行するための種々の技術が上述され、それらをここに適用することができる。図３Ａ及び３Ｂを参照すれば、プロデューサグラフ実行モジュール３４５及び３７０が各々インボークされる。更に、コマンドログ６６５が具現化される本発明の実施形態では、因果関係は、コマンドログ６６５を消費し、そしてブロック６６０の前に処理ブロック６４５及び６５０を遂行することを含む。更に、未解明の依存性の可能性をサポートする本発明の実施形態では、制御が必要なときにブロック６６０からブロック６６５へ流れる。
【００９９】
ブロック６５５において、未解明の依存性を解明し、そしてインスタンス及びそのプロデューサをインスタンス生成することを含めて、プロデューサグラフ（１つ又は複数）の残りを発見し構築するように試みられる。ブロック６５５から、制御は、ブロック６６０へ戻される。
【０１００】
プロデューサ依存性宣言の例示的形態
図７Ａ−Ｆは、本発明の一実施形態によるプロデューサ依存性宣言に対する幾つかの例示的形態を示す。図７Ａ−Ｆは、引数、フィールド及びシーケンス依存性をサポートする実施形態を示すが、異なる実施形態が、３つの依存性形態のうちの１つ又は２つだけをサポートしてもよいことが理解されよう。図７Ａ−Ｆに示す本発明の実施形態では、プロデューサ依存性宣言は、プロデューサ依存性宣言ステートメント、及び任意のものとして、明示的プロデューサ依存性宣言コードで構成される。非ショートカット宣言プロデューサ依存性は、明示的プロデューサ依存性宣言コードが使用されるものであり、一方、ショートカット宣言プロデューサ依存性は、明示的プロデューサ依存性宣言コードが使用されない（むしろ、ランタイムがプロデューサ依存性宣言コードを使用せず、及び／又はそれを、プロデューサ依存性宣言ステートメントの情報に基づいてオンザフライで具現化する）ものである。
【０１０１】
本発明の異なる実施形態は、プロデューサ依存性を宣言するために異なるシンタックスを使用することができる。例えば、本発明の異なる実施形態は、生成できるプロデューサ依存性の形式を強く制約し、弱く制約し、及び／又は制約しない異なるシンタックを、プロデューサ依存性宣言ステートメントに使用するために含ませることができる。強く制約されるプロデューサ依存性は、生成できるプロデューサ依存性の形式を実質的に制限するシンタックスがプロデューサ依存性宣言ステートメントに使用されるというものであり、弱く制約されるプロデューサ依存性は、生成できるプロデューサ依存性の形式をあまり制限しないシンタックスがプロデューサ依存性宣言ステートメントに使用されるというものであり、そして非制約のプロデューサ依存性は、生成できるプロデューサ依存性の形式を制限しないシンタックスがプロデューサ依存性宣言ステートメントに使用されるというものである。
【０１０２】
例えば、これに限定されないが、以下に述べる本発明の実施形態は、次のものを含む。即ち、１）引数に対して強く制約されたプロデューサ依存性のためのシンタックス（ArgumentDependency＝強く制約され下方に宣言された引数［スタティック又はダイナミックそしてダイナミックの場合にはコンティンジェント及び／又はアブソーブサブスクリプション］依存性）；２）フィールドに対して強く制約されたプロデューサ依存性のためのシンタックス（FieldDependency＝強く制約され下方に宣言されたフィールド［スタティック又はダイナミックそしてダイナミックの場合にはコンティンジェント及び／又はアブソーブサブスクリプション］依存性）；３）シーケンス依存性に対して強く制約されたプロデューサ依存性のためのシンタックス（SequencingDependency＝強く制約され下方に宣言されたシーケンス［スタティック又はダイナミックそしてダイナミックの場合にはコンティンジェント及び／又はスティッキーサブスクリプション］依存性）；４）引数、フィールド又はシーケンス依存性に対して弱く制約され上方に宣言されたプロデューサ依存性のためのシンタックス（UpwardDependency＝弱く制約され上方に宣言されたフィールド、引数、又はシーケンス［スタティック又はダイナミックそしてダイナミックの場合にはコンティンジェント］依存性）；及び５）弱く制約されたプロデューサ依存性のためのシンタックス（WeaklyConstrainedDependency＝ａ）下方に宣言されたシーケンスのみ［スタティック又はダイナミックそしてダイナミックの場合にはコンティンジェント及び／又はスティッキーサブスクリプション］依存性、又はｂ）上方に宣言された［引数、フィールド又はシーケンス］［スタティック又はダイナミックそしてダイナミックの場合にはコンティンジェント］依存性）。本発明の幾つかの実施形態は、下方に宣言された引数依存性、下方に宣言されたフィールド依存性、上方に宣言された依存性（上方に宣言された引数、フィールド又はシーケンス依存性を返送できる）、及び弱く制約される依存性（下方に宣言されたシーケンス依存性、上方に宣言された引数、フィールド、又はシーケンス依存性を返送できる）を区別するプロデューサ依存性宣言ステートメントのためのシンタックスをサポートするが、本発明の別の実施形態は、異なるシンタックスを採用してもよい（例えば、サポートされた依存性（下方及び上方に宣言された引数、フィールド及びシーケンス依存性）を返送できる依存性決定プロデューサで全ての依存性を非制約の依存性にさせるシンタックスを有し；サポートされた全ての依存性を区別するシンタックスを有し；下方及び上方に宣言された引数及びフィールド依存性を区別すると共に、上方及び下方に宣言されたシーケンス依存性しか返送できない弱く制約された依存性を区別するシンタックスを有し；下方に宣言された引数及びフィールド依存性を区別すると共に、上方に宣言されたシーケンス依存性しか返送できない上方に宣言された依存性を区別するシンタックスを有し；下方に宣言された引数、フィールド、及びシーケンス依存性を区別する（スティッキーサブスクリプション及び上方に宣言された依存性はサポートされない）シンタックスを有し；等々）。
【０１０３】
プロデューサ依存性宣言ステートメントのシンタックスは、必ずしも、プロデューサグラフに生成されたプロデューサ依存性（例えば、リンク）に等しくないことを理解されたい（例えば、ArgumentDependencyは、引数依存性を生成するが、UpwardDependencyは、引数、フィールド又はシーケンス依存性を生成することができる）。従って、理解のために適切である場合に、修飾子（例えば、引数、フィールド又はシーケンス）と語「依存性」との間のスペースは、ランタイムにより生成される依存性を指すのに使用され、一方、スペースの欠落は、シンタックスを指すのに使用される。
【０１０４】
図７Ａは、本発明の一実施形態によりショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図７Ｂは、本発明の一実施形態による例示的プロデューサのブロック図である。図７Ａは、次のものを示す。１）ArgumentDependencies 1-N、FieldDependencies 1-M、SequencingDependencies 1-L、UpwardDependencies 1-P、及びWeaklyConstrainedDependencies 1-Qを含むプロデューサ依存性宣言ステートメント７０５；及び２）プロデューサ依存性宣言ステートメント７０５からの引数１−Ｎを有するメソッドアルファ７１０。本発明の一実施形態では、プロデューサ依存性宣言ステートメントの引数は、追跡のために各々引数ＩＤを与えるように番号付けされる。図７Ｂは、次のものに対する子依存性を有するプロデューサ７２０を示している。１）引数ＩＤ  １に対するプロデューサ７２５；２）引数ＩＤ  Ｎに対するプロデューサ７３０；３）FieldDependencies 1-Mに対するプロデューサ７４０−７４５；４）SequencingDependencies 1-Lに対するプロデューサ７４６−７４７；及び５）UpwardDependencies 1-Pに対するプロデューサ７４８−７４９（注：WeaklyConstrainedDependencies 1-Qは、図示されていないが、図７Ｇを参照して詳細に説明する）。従って、プロデューサ依存性宣言ステートメント７０５の引数は、メソッドアルファ７１０の引数に対応し、そしてプロデューサ依存性宣言ステートメント７０５における引数の引数ＩＤは、それらが識別する子プロデューサに関して追跡される。
【０１０５】
図７Ｃは、本発明の一実施形態により非ショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示すと共に、例示的プロデューサのブロック図である。図７Ｃは、図７Ａのプロデューサ依存性宣言ステートメント７０５及びメソッドアルファ７１０を示すと共に、図７Ｂのプロデューサ７２０及び７２５を示す。更に、図７Ｃは、ArgumentDependency 1に関連したプロデューサ依存性宣言コード７１５も含む。ランタイム中に、ランタイムは、プロデューサ依存性宣言ステートメント７０５のArgumentDependency 1に応答してプロデューサ依存性宣言コード７１５にアクセスして実行する。プロデューサ依存性宣言コード７１５の実行は、プロデューサ７２５をArgumentDependency 1のためのプロデューサ依存性として返送する。従って、図７Ｃは、プロデューサ依存性宣言コード７１５が（メソッドアルファ７１０以外の）メソッドの一部分でよいが、プロデューサの一部分ではないような本発明の実施形態を示す。
【０１０６】
図７Ｄは、本発明の一実施形態により非ショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図７Ｅは、本発明の一実施形態による例示的プロデューサのブロック図である。図７Ｄは、図７Ａのプロデューサ依存性宣言ステートメント７０５及びメソッドアルファ７１０を示し、一方、図７Ｅは、図７Ｂからのプロデューサ７２０及び７２５を示す。更に、図７Ｄは、１）プロデューサ依存性宣言ステートメント７５０、及び２）プロデューサ依存性宣言コード７６０を含むメソッドベータ７５５も示している。又、図７Ｄは、プロデューサ依存性宣言ステートメント７０５の引数依存性１が、引数依存性１に対して依存性を返送するメソッドベータ７５５に基づいてプロデューサ（図７Ｅにプロデューサ７６５として示された）を識別することも示している。ランタイム(run time)中に、ランタイム(runtime)は、プロデューサ依存性宣言ステートメント７０５の引数依存性１に応答して、プロデューサ７６５を実行し、引数依存性１に対するプロデューサ依存性がプロデューサ７２５であるという識別を返送する。従って、プロデューサ７６５は、依存性決定プロデューサと称され（その出力は、プロデューサ依存性であり、従って、プロデューサグラフ指向のプログラミングサポートを伴うランタイムにより特殊な処理（プロデューサグラフ（１つ又は複数）の操作）に対して監視されるクラス／インスタンスを使用して返送され）、一方、プロデューサ７２５は、標準的プロデューサと称される（その出力がもしあれば、それは、プロデューサグラフを操作するようにランタイムによって直接処理されず；その出力がもしあれば、それは、親プロデューサ（依存性決定プロデューサ又は別の標準的プロデューサ）により消費することができ、及び／又はプロデューサグラフの出力として与えることができる（標準的なプロデューサが問題とするプロデューサであり、従って、根ノードである場合）。
【０１０７】
従って、図７Ｄ−Ｅは、プロデューサ依存性宣言コード７１５が、依存性決定プロデューサと称される別のプロデューサの一部分であるような本発明の実施形態を示す。図７Ｄ−Ｅにおいて、オブジェクト指向のソースコードは、メソッドに明示的プロデューサ依存性宣言コードを含み、そこから、ランタイム時に、非ショートカット宣言依存性に対してランタイムにより依存性決定プロデューサがインスタンス生成されるが、本発明の別の実施形態は、それに加えて又はそれとは別に、ショートカット宣言依存性に対してオンザフライで１つ以上の一般的な依存性決定プロデューサとしてインボークされる一般的なプロデューサ依存性宣言コードを含むようにランタイムを具現化する。又、図７Ｃ−Ｅは、ArgumentDependenciesに関して示されているが、図示された技術は、他の形式の下方に宣言された依存性に適用することができる。更に、図７Ｆ−Ｇは、UpwardDependencies及びWeaklyConstrainedDependenciesに対する依存性決定プロデューサの使用も示している。
【０１０８】
図７Ｆは、本発明の一実施形態により依存性決定プロデューサを伴うUpwardDependencyの使用による例示的依存性を示すブロック図である。図７Ｆは、依存性決定プロデューサ７７２に対するシーケンスプロデューサ依存性を有するプロデューサ７２０を示している。依存性決定プロデューサは、プロデューサ７２０に対する親プロデューサ７４８の非サブスクリプションの上方に宣言された引数、フィールド又はシーケンス依存性を返送することができる。更に、このような依存性決定プロデューサは、ダイナミック依存性（例えば、以下に述べるように、異なる引数ＩＤ間を含めて、データ値に基づき前記のものの間で選択するコンティンジェント依存性）を具現化することができる。本発明のある実施形態は、全てのこれら可能性をサポートするが、本発明の別の実施形態は、サブセットのみ（例えば、非サブスクリプションの上方に宣言されたシーケンス依存性のみ）をサポートする。
【０１０９】
図７Ｇは、本発明の一実施形態により依存性決定プロデューサを伴うWeaklyConstrainedDependencyの使用により考えられる例示的依存性を示すブロック図である。図７Ｇは、依存性決定プロデューサ７７５に対するシーケンスプロデューサ依存性を有するプロデューサ７２０を示している。本発明のある実施形態では、依存性決定プロデューサは、次のいずれかを返送することができる。１）子プロデューサ７８０に対する非サブスクリプションの下方に宣言されたシーケンス依存性；２）プロデューサ７２０に対する親プロデューサ７８５の非サブスクリプションの上方に宣言された引数、フィールド又はシーケンス依存性；及び３）スティッキーサブスクリプション（以下に述べる）。更に、このような依存性決定プロデューサは、ダイナミック依存性（例えば、以下に述べるように、異なる引数ＩＤ間を含めて、データ値に基づき前記のものの間で選択するコンティンジェント依存性）を具現化することもできる。本発明のある実施形態は、全てのこれら可能性をサポートするが、本発明の別の実施形態は、サブセットのみ（例えば、非サブスクリプションの上方に宣言されたシーケンス依存性のみ）をサポートする。
【０１１０】
上述したように、シーケンス依存性は、ランタイムが気付かない仕方でデータを変更するプロデューサと、そのデータを消費するプロデューサとの間で実行順序を確保すること等を含めて、種々の目的で使用することができる（子プロデューサは、その出力にアクセスするコードを含ませるために親プロデューサのメソッドを要求する仕方でその出力を書き込むことができる（例えば、普通のプロデューサ出力でなく、従って、ランタイムにより検出されない出力に作用することにより環境に影響するメソッド、例えば、グローバル変数をセットし、プロデューサ出力でないインスタンスにおいてフィールドをセットし、外部データソースに影響する、等のメソッド））。
【０１１１】
異なる実施形態は、プロパティプロデューサに対してプロデューサ依存性を宣言するための１つ以上の方法をサポートすることができる。より詳細には、本発明の幾つかの実施形態において、フィールドを読み取るプロデューサは、ゲットプロパティ(get property)プロデューサに依存しなければならず、一方、ゲットプロパティプロデューサは、ゲットプロパティメソッドが責任を負うところのフィールドをセットするプロデューサに依存しなければならない。シーケンスプロデューサ依存性をサポートする本発明の実施形態に使用できるこの状況を取り扱う１つの技術は、ゲットプロパティメソッドに対し、そのゲットプロパティメソッドが責任を負うところのフィールドをセットする各メソッドに対するシーケンスプロデューサ依存性を生成するプロデューサ依存性宣言ステートメントを与えることである（例えば、図７Ｇに関して、プロデューサ７８０がフィールドをセットするプロデューサであり、且つプロデューサ７２０がそのフィールドに対して責任のあるゲットプロパティプロデューサである場合には、依存性決定プロデューサ７７５は、プロデューサ７８０に対するプロデューサ７２０の下方に宣言されたシーケンス依存性を返送するように書かれる）。シーケンスプロデューサ依存性及び上方に宣言されたプロデューサ依存性の両方をサポートする本発明の実施形態に使用できるこの状況を取り扱う第１の技術は、フィールドをセットするメソッドに対するプロデューサ依存性宣言ステートメント／コードにおいて、そのフィールドについて責任を負うゲットメソッドに対する上方に宣言されたシーケンスプロデューサ依存性（例えば、UpWardDependency又はWeaklyConstrainedDependenciesを使用する）を含ませることである（例えば、図７Ｇに関して、プロデューサ７２０がフィールドをセットするプロデューサであり、且つプロデューサ７８５がそのフィールドに対して責任のあるゲットプロパティプロデューサである場合には、依存性決定プロデューサ７７５は、プロデューサ７２０に対する親プロデューサ７８５の上方に宣言されたシーケンス依存性を返送するように書かれる）。この第２の技術は、フィールドをセットするメソッドのプログラマーが、適切なゲットメソッドに対するプロデューサ依存性を与える責任をもてるようにするもので、プログラマーがゲットメソッドへと進んでそのプロデューサ依存性宣言ステートメント／コードを変更することを要求するのではない。
【０１１２】
シーケンス依存性を使用するとき、所与のプロデューサが所与の変数に依存するときには、その変数は、プロデューサグラフ（１つ又は複数）の所与の実行においてそのプロデューサの子孫プロデューサの２つ以上により変更されてはならない（コンティンジェント依存性（以下に述べる）により、現在プロデューサグラフ（１つ又は複数）の異なる実行中に、異なる子孫プロデューサがその変数を変更し得ることに注意されたい）。例えば、ゲットプロパティプロデューサは、現在プロデューサグラフ（１つ又は複数）の所与の実行においてそのゲットプロパティプロデューサが責任を負うフィールドをセットする１つの他のプロデューサのみに依存するものでなければならない。
【０１１３】
本発明の異なる実施形態は、図７Ａ−Ｆに示す本発明の実施形態の１つ以上を具現化できることを理解されたい。例えば、本発明の一実施形態は、依存性決定プロデューサを使用してショートカット及び非ショートカット宣言依存性をサポートし、より詳細には、本発明のこの実施形態では、１）オブジェクト指向のソースコードは、メソッドに明示的プロデューサ依存性宣言コードを含み、そこから、ランタイムに、非ショートカット宣言依存性に対してランタイムにより依存性決定プロデューサがインスタンス生成され；２）ランタイムは、ショートカット宣言コンティンジェント依存性（以下に述べる）に対してオンザフライで１つ以上の一般的な依存性決定プロデューサとしてインボークされる一般的なプロデューサ依存性宣言コードを含み；そして３）ランタイムは、ショートカット宣言非コンティンジェントプロデューサ依存性（以下に述べる）を直接リンクするためのサポートを含む。
【０１１４】
別の例として、本発明の一実施形態は、依存性決定プロデューサを使用して非ショートカット及びショートカット宣言プロデューサ依存性をサポートし、より詳細には、本発明のこの実施形態では、１）オブジェクト指向のソースコードは、メソッドに明示的プロデューサ依存性宣言コードを含み、そこから、ランタイム時に、非ショートカット宣言依存性に対してランタイムによって依存性決定プロデューサがインスタンス生成され、そして；２）ランタイムは、ショートカット宣言依存性に対して（形式に関わりなく）オンザフライで１つ以上の一般的な依存性決定プロデューサとしてインボークされる一般的な依存性決定コードを含む。この後者の実施形態は、プロデューサ依存性の一貫した処理を許し、従って、ランタイムを簡単にする。
【０１１５】
更に、本発明の一実施形態では、メソッドに対するプロデューサ依存性宣言ステートメントは、オブジェクト指向のソースコードにおけるそのメソッドの真上に位置されるが、本発明の別の実施形態では、別のところに位置される（例えば、あるクラスの全てのメソッドに対するプロデューサ依存性宣言ステートメントが、そのクラス内で一緒にグループ化され、全てのクラスの全てのメソッドに対するプロデューサ依存性宣言ステートメントが個別のデータテーブルとして一緒にグループ化され、等々）。又、本発明の一実施形態では、プロデューサ依存性宣言コードがプロデューサ依存性宣言ステートメントとは別個であるが、本発明の別の実施形態では、それらが合成される（例えば、プロデューサ依存性宣言コードがプロデューサ依存性宣言ステートメントのカッコ内にあり、プロデューサ依存性宣言コードがプロデューサ依存性宣言ステートメントの真下にあってランタイムにより単一のユニットとして処理され、等々である）。
【０１１６】
図７Ｈ−Ｉは、依存性決定プロデューサのためにプロデューサグラフに存在し得る異なるサブグラフ間の区別を示す。図７Ｈは、本発明の一実施形態による標準的プロデューサのプロデューサグラフを例示する。より詳細には、図７Ｈは、根ノードＳ１を伴うプロデューサグラフ、根ノードＳ５を伴うプロデューサグラフ、及び根ノードＳ１１を伴うプロデューサグラフを示す。標準的プロデューサＳ１は、子の標準的プロデューサＳ２、Ｓ３及びＳ４を有し、標準的プロデューサＳ２及びＳ３は、子の標準的プロデューサＳ７及びＳ８を有し、標準的プロデューサＳ５は、子の標準的プロデューサＳ４及びＳ６を有し、そして標準的プロデューサＳ１１は、子の標準的プロデューサＳ６及びＳ１０を有する。図７Ｈの例示的プロデューサグラフは、多数のプロデューサ依存性及び依存性決定プロデューサを使用して発見し、構築し、解明することができる。図７Ｉは、図７Ｈのプロデューサグラフを発見し、解明し、構築するためのプロデューサ依存性及び依存性決定プロデューサの一例を示す。より詳細には、図７Ｉは、図７Ｈのグラフが、プロデューサグラフの大きなセットのうちのサブグラフであることを示している。換言すれば、図７Ｉのプロデューサグラフは、図７Ｈのグラフ（「ターゲットサブグラフ」と称され、矢印付き実線及び実線の楕円を使用して示されている）と、ターゲットサブグラフの発見、解明、構築を助成するグラフ（「判断サブグラフ」と称され、矢印付き破線及び破線の楕円を使用して示されている）とを含む。図７Ｈの判断サブグラフは、依存性決定プロデューサ（ＤＤＰ）１−１１及び標準的プロデューサＳ９−１０を含む。図７Ｈにおいて、Ｓ１は、ＤＤＰ１−３に依存するとして示され、これらは、各々、Ｓ２、Ｓ３及びＳ４に対するＳ１の下方に宣言されたプロデューサ依存性を返送し、Ｓ４は、ＤＤＰ４に依存するとして示され、これは、Ｓ４に対するＳ５の上方に宣言されたプロデューサ依存性を返送し、Ｓ５は、ＤＤＰ５に依存するとして示され、これは、Ｓ６に対するＳ５の下方に宣言されたプロデューサ依存性を返送し、Ｓ３は、ＤＤＰ６に依存するとして示され、これは、次いで、ＤＤＰ８に依存し、これは、Ｓ９及びＳ１０に対するＤＤＰ６の下方に宣言されたプロデューサ依存性を返送し、これは、ＤＤＰ６が、Ｓ７に対するＳ３の下方に宣言された依存性を返送するようにさせ、Ｓ３は、ＤＤＰ７に依存するとして示され、これは、Ｓ８に対するＳ３の下方に宣言されたプロデューサ依存性を返送し、Ｓ８は、ＤＤＰ９に依存するとして示され、これは、Ｓ６がトリガープロデューサで且つＳ１１が生成された親であるところのスティッキーサブスクリプション（従って、Ｓ６に対するＳ１１のプロデューサ依存性）を返送し、Ｓ２は、ＤＤＰ１０に依存するとして示され、これは、Ｓ７及びＳ８に対するＳ２の下方に宣言されたプロデューサ依存性の集合を返送し、そしてＳ１１は、ＤＤＰ１１に依存するとして示され、これは、Ｓ１０に対するＳ１１の下方に宣言されたプロデューサ依存性を返送する。標準的プロデューサは、ターゲットサブグラフ及び判断サブグラフの両方の一部分でよい（例えば、Ｓ１０を参照）ことを理解されたい。ターゲットサブグラフは、データが、グラフを上るように、ある標準的プロデューサから別の標準的プロデューサへ流れるという意味で、データ駆動されることに注意する価値がある。
【０１１７】
例示的プログラミング及び実行フレームワーク
図８Ａは、本発明の一実施形態によりアプリケーションがエンドユーザに与えられるところの第１の例示的フレームワークを示すブロック図である。図８Ａに示すフレームワークは、３つの基本的な区分を含む。第１区分は、プロデューサグラフ指向のプログラミングサポートを伴うランタイム８１０の生成を含む。この第１区分は、非常に高度なプログラミングスキルをもつプログラマーによって遂行される。この区分で作業するときには、プログラマーは、ランタイムプログラマーと称される。プロデューサグラフ指向のプログラミングサポートを伴うランタイムを生成するときには、ランタイムプログラマーは、プロデューサグラフに対するサポートと、変換コード、インスタンス生成コード及びデータ準備コードに使用される種々の形式のコマンドを実行するためのサポートとを含む。
【０１１８】
第２区分は、ランタイムによって実行されるオブジェクト指向のアプリケーションソースコード８２０の生成を含む。オブジェクト指向のアプリケーションソースコード８２０は、２つの基本的区分を含む。即ち、１）プロデューサ依存性宣言を伴うメソッドで表現されたビジネスロジックを含むクラス定義８２２（これは、グラフィックユーザインターフェイスのような他のファンクションを任意に含むことができ、このケースでは、グラフィックユーザインターフェイスは、プロデューサ及びプロデューサ依存性宣言を使用して書かれ）；及び２）メソッドで表現されたクライアントコードを含むクラス定義８２４。これは、更に、インスタンス生成コード（プロデューサグラフ（１つ又は複数）を発生させるための、問題とするクラス、インスタンス及びプロデューサ（１つ又は複数））８２４Ａ、データ準備コード（例えば、プロデューサ出力のオーバーライドをトリガーするセットコマンドのようなセットコマンド）８２４Ｂ、プロデューサグラフ（１つ又は複数）を実行させるグローバル実行コマンド（例えば、実行及びゲットコマンド）８２４Ｃ、及び必要なグラフィックユーザインターフェイス８２４Ｄ（８２２には含まれず）を含む。プロデューサ依存性宣言は、クラスのインスタンスが生成された後ではなく、ビジネスロジックを含むクラスの定義中に、プロデューサ間の連結を定義するのに使用される。オブジェクト指向のソースコード８２０は、コンパイルされて実行されるハードコード化クラス、インスタンス、及びメソッドである。
【０１１９】
本発明の一実施形態では、グローバル実行コマンドが具現化され、これを実行すると、プロデューサグラフ（１つ又は複数）構造３８０に現在ある全てのプロデューサグラフ（１つ又は複数）の実行が試みられるが、本発明の別の実施形態では、それとは別に又はそれに加えて、実行されるべき現在プロデューサグラフ（１つ又は複数）の所与のグラフの識別を要求するグラフ特有の実行コマンドが具現化される。更に、グローバルな実行コマンドは、ランタイムの具現化に基づき、明示的（例えば、セット、セット、セット、実行、ゲット、ゲット）でもよいし、又は暗示的でもよい。例えば、暗示的なグローバル実行コマンドは、１）問題とするプロデューサに対する第１ゲットコマンド（例えば、セット、セット、セット、ゲット(暗示的実行)、ゲット）によりトリガーすることができ、２）各データ操作（セット(暗示的実行)、セット(暗示的実行)、セット(暗示的実行)）によりトリガーすることができ、等々である。
【０１２０】
第２区分も、プログラミングスキルをもち且つアプリケーションのビジネスオブジェクトを理解するプログラマーによって遂行される。この区分で作業するときには、プログラマーは、ランタイムプログラマーと称される。その一部分として、アプリケーションがグラフィックユーザインターフェイスを要求する場合には、アプリケーションプログラマーは、特定のアプリケーションに対してグラフィックユーザインターフェイスの設計及びコード化も行い、従って、アプリケーションデザイナーとも称される。
【０１２１】
第３区分は、ランタイムにより実行されるアプリケーションプログラムの使用を含む。第３区分は、プログラミングスキルをもつ必要のないエンドユーザによって遂行される。アプリケーションプログラムは、種々の仕方で配布することができる（例えば、ソースコードとして；ソースコードを変換したもの、例えば、バイトコードとして；バイナリーとして；等々）。更に、アプリケーションプログラムは、スタンドアローン使用８３０（このケースでは、全アプリケーションプログラム（及びまだ存在しなければランタイム）がコンピュータシステムに与えられる）及び／又はクライアント／サーバー使用に対して配布することもできる。本発明の一実施形態では、クライアント／サーバー配布は、サーバー使用８３２に対してプロデューサ依存性宣言を伴うメソッドで表現されたビジネスログを含むクラス定義８２２（及びまだ存在しなければランタイム）と、クライアント使用８３４に対してメソッドで表現されたクライアントコードを含むクラス定義８２４（及びまだ存在しなければランタイム）とを配布することを含み、コンピュータシステムにおけるクライアント使用８３４は、サーバーシステムにおけるサーバー使用８３２との通信を生じさせる。
【０１２２】
又、図８Ａは、スタンドアローン使用８３０及びクライアント使用８３４に対して設けられた任意の構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０も示している。オブジェクト指向のソースコード８２０は、プロデューサグラフ（１つ又は複数）を発生するためにランタイムによって実行され、そして構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０は、プロデューサグラフからの出力をグラフ表示し且つプロデューサグラフと対話できるようにする。より詳細には、構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０は、次のものを含む。即ち、１）レイアウトの構成及び選択されたプロデューサ出力のマッピング（例えば、使用すべきスクリーンのエリア、データをどのように表示するか、等）を許すための構成及びマッピンググラフィックユーザインターフェイスモジュール８４４；及び２）構成されたレイアウトをレンダリングしそしてプロデューサ出力のオーバーライドを許す（その結果、グローバルな実行コマンドを通してプロデューサグラフの更新が生じる）ためのレンダリング及び対話グラフィックユーザインターフェイスモジュール８６４。構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０は、ランタイム８１０を書く同じエンティティにより生成されてもよいし、そうでなくてもよいことを理解されたい。
【０１２３】
図８Ｂは、本発明の一実施形態によりアプリケーションがエンドユーザに与えられるところの第２の例示的フレームワークを示すブロック図である。図８Ｂは、次のことを除いて、図８Ａと同じである。即ち、１）スタンドアローン使用８３０が存在しない；２）オブジェクト指向のソースコード８２０がサーバー使用８３２に与えられ、一方、クライアントコード８２４は、クライアント使用８３４に与えられない；３）構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０は、サーバー使用８３２に与えられ、クライアント使用８３４には与えられない；そして４）一般的な構成可能なインタラクティブなプロデューサ出力レイアウトクライアントインターフェイス８８５がクライアント使用８３４に与えられる。この構成可能なインタラクティブなプロデューサ出力レイアウトクライアントインターフェイス８８５は、構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０とインターフェイスするのに使用される。
【０１２４】
使用するフレームワークに関わりなく、本発明の一実施形態では、プロデューサグラフ指向のプログラミングフレームワークは、プロデューサ依存性宣言と共に描かれていないプログラムとインターフェイスする能力を与える。プロデューサ依存性宣言と共に描かれていないプログラムとインターフェイスするこの能力は、１）発呼部分（プロデューサグラフ指向のプログラミングに基づいて書かれないグラフィックユーザインターフェイスのような）；及び２）被呼部分（プロデューサグラフ指向のプログラミングに基づいて書かれない外部データソースのような）を含む。発呼部分は、クライアントコードを通して、プロデューサグラフ指向のプログラミングコマンドを発行することができる。被呼部分は、被呼部分を取り巻くプロデューサ（「ラッピングプロデューサ」と称される）の一部分として具現化される。被呼部分を実行すると（例えば、データソースからデータを読み取るか又は外部データソースにおけるデータの変化にサブスクライブすると）、インスタンスの変更をトリガーすることができる。これらの変化は、ラッピングプロデューサのコードにおいてプロパティセットメソッドをコールすることにより生じ得る。ゲットプロパティプロデューサ（ゲッター）は、外部データソースに生じる変化によりトリガーされるインスタンス変更がプロデューサグラフを通して適切に伝播されるよう保証するために、これらラッピングプロデューサに対する依存性を有するようにされる。上述したように、異なる実施形態は、プロパティプロデューサに関してプロデューサ依存性を宣言するための１つ以上の仕方をサポートすることができる。例えば、シーケンスプロデューサ依存性をサポートする本発明の幾つかの実施形態では、ラッピングプロデューサに対する非サブスクリプション下方宣言シーケンスプロデューサ依存性を宣言するためにSequencingDependenciesを使用することができる。更に別の例では、シーケンスプロデューサ依存性及び非サブスクリプション上方宣言プロデューサ依存性をサポートする本発明の幾つかの実施形態では、プロパティプロデューサに対する非サブスクリプション上方宣言シーケンスプロデューサ依存性を生成するために、ラッピングプロデューサのプロデューサ依存性宣言にUpwardDependencies及び／又はWeaklyConstrainedDependenciesを入れることができる。
【０１２５】
図８Ｃ−Ｆは、本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０のスクリーンショット及び使用を例示する。本発明の実施形態は、スプレッドシートの形態において現在プロデューサグラフ（１つ又は複数）の選択された出力で構成、マッピング及び対話を与える構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０を参照して説明するが、本発明の別の実施形態は、それに加えて又はそれとは別に、別の形態のサポートを与えるように具現化することもできる。更に、スプレッドシートの形態で構成、マッピング及び対話を遂行する例示的な仕方を、幾つかの実施形態に基づいて説明するが、本発明の他の実施形態は、これらのオペレーションを、異なるインターフェイス及び／又は異なるスクリーンレイアウトを伴う別の仕方で遂行することができる。更に、スプレッドシートは、スプレッドシートに関連した既知のファンクションのいずれもサポートすることができる（例えば、カラー選択、フォント選択、バー／パイ／ラインチャート、ピボットテーブル、セービングレイアウト、ローディングレイアウト、等）。
【０１２６】
図８Ｃ−Ｄは、本発明の一実施形態による自由セル選択のスクリーンショット及び使用を例示し、一方、図８Ｅ−Ｆは、本発明の一実施形態によるテーブル生成のスクリーンショット及び使用を例示している。図８Ｃ−Ｆの各々は、スクリーンの頂部に沿ったメニューバー８５０と、スクリーンの左側に沿った現在プロデューサグラフにおけるプロデューサ及びそれらの出力のクラス（ゲットプロパティメソッドを伴う）のリスト８５２と、スプリットシート状のレイアウトでスクリーンの残りを埋める構成及びマッピングビューア８５４とを含む。更に、図８Ｃ−Ｆは、リスト８５２におけるゲットプロパティメソッドを伴うクラスの、次の例示的リストも示している。１）クラス「個人(PERSON)」；２）名(FIRSTNAME)(例えば、ストリング)、氏(LASTNAME)(例えば、ストリング)、性別(GENDER)(例えば、ストリング)、家の住所(HOMEADDRESS)(クラス「住所(ADDRESS)」のインスタンス)、職場の住所(PROFESSIONALADDRESS)(クラス「住所」のインスタンス)、誕生日(DATEOFBIRTH)(例えば、日付)、及び年齢(AGE)(例えば、整数)；３）クラス「住所」；及び４）都市(CITY)(例えば、ストリング)、州(STATE)(例えば、ストリング)、郵便番号(ZIPCODE) (例えば、ストリング)を含むクラス「住所」のゲットプロパティメソッド。従って、現在プロデューサグラフは、クラス「個人」及び「住所」のプロデューサと、出力がクラス「個人」及び「住所」のものであるプロデューサとを含む。又、ゲットプロパティメソッド「年齢」は、ゲットプロパティメソッド「誕生日」の出力に基づいて年齢を計算し、従って、ゲットプロパティメソッド「年齢」からインスタンス生成されるプロデューサは、ゲットプロパティメソッド「誕生日」からインスタンス生成されるプロデューサに依存する。
【０１２７】
図８Ｃ−Ｄは、ビューアの第１列の連続セルに入れられた次の自由テキスト、即ち「顧客(CUSTOMER」、「名(FIRST NAME)」、「氏(LAST NAME)」、「誕生日(DATE OF BIRTH)」及び「年齢(AGE)」を示し、一方、図８Ｅ−Ｆは、次のもの、即ち、１)ビューアの第１行に入れられた自由テキスト「顧客リスト(CUSTOMER LIST」；及び２)ビューアの第２行の連続セルに入れられた自由テキスト「名(FIRST NAME)」、「氏(LAST NAME)」、「誕生日(LAST NAME)」及び「年齢(AGE)」を示している。
【０１２８】
図８Ｃは、本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０での自由セル選択の例示的スクリーンショット及び使用を示す。図８Ｃは、クラス「個人」及びクラス「個人」の選択されたゲットプロパティメソッドの、ビューアの異なるクラスへのマッピング８５６のセットを示す。より詳細には、クラス「個人」は、自由テキスト「顧客」の右のセルへマップされる。このアクションの一部分として、本発明の幾つかの実施形態は、ユーザが多数のサポートされたフィルタの１つから選択するように促す（フィルタ選択８５８として示す）（例えば、リストをドロップダウンし、スクロール矢印を形成し、等）。これらのフィルタは、選択されたクラスのプロデューサの１つ以上のインスタンスキー、又は出力クラスが選択されたクラスであるプロデューサの１つ以上のインスタンスキーを選択できるようにする。本発明の幾つかの実施形態は、多数のフィルタをサポートするが、本発明の他の実施形態は、１つにデフォールトする（そしてユーザが異なるものを選択すべきかどうか選べるようにする）か、又は１つのみをサポートして、フィルタ選択８５８を行う必要がないようにする。又、マッピング８５６は、クラス「個人」のゲットプロパティメソッド「名」、「氏」、「誕生日」及び「年齢」が、各々、対応する自由テキストをもつセルに隣接するセルへマップされることも示す。このようなマッピングは、ドラグ及びドロップ、ＧＵＩフィールドへのタイプイン、等を含む多数の良く知られた技術で行うことができる。
【０１２９】
図８Ｄは、本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０での自由セル選択の別の例示的スクリーンショット及び使用を示す。図８Ｄは、インスタンス選択８５４を許すためにクラス「個人」がマップされたセルを示している。より詳細には、このセルに使用されるフィルタに基づいて、ユーザには、クラス「個人」のプロデューサのインスタンスキー（１つ又は複数）及びクラス「個人」を生成するプロデューサのインスタンスキーを含むリストからクラス「個人」のインスタンスを選択する機会が与えられる。クラス「個人」のインスタンス（又は単一インスタンスの存在）を選択すると、クラス「個人」のゲットプロパティメソッドがマップされたセルに、そのインスタンスの対応ゲットプロパティメソッドの出力が自動的にポピュレートされる。クラス「個人」のインスタンスに基づくテーブルのこのようなポピュレーションが８５８で示されている。図８Ｄの例では、クラス「個人」のゲットプロパティメソッド「名」、「氏」、「誕生日」及び「年齢」がマップされたセルに、JOHN、SMITH、7/20/1990及び１６が各々ポピュレートされる。
【０１３０】
又、図８Ｄは、ゲットプロパティメソッドがマップされたビューアのセルがオーバーライドされることも示している。例えば、図８Ｄは、ゲットプロパティメソッド「誕生日」がマップされたセルがオーバーライドされた場合に、出力が現在そのセルにポピュレートしているプロデューサの出力のオーバーライド、グローバルな実行コマンドのインボケーション（これは、ゲットプロパティメソッド「年齢」がマップされたセルに出力が現在ポピュレートしているプロデューサの再実行を生じさせる）、及びディスプレイの必要な更新を引き起こすことを示している。
【０１３１】
図８Ｅは、本発明の一実施形態による構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０でのテーブル生成の例示的スクリーンショット及び使用を示す。図８Ｅは、自由テキスト「名(FIRST NAME)」、「氏(LAST NAME)」、「誕生日(DATE OF BIRTH)」及び「年齢(AGE)」を伴うセル（セルの周りを太い破線で示した）の真下に３行の垂直テーブルを識別するようにオペレーションが行われるゾーン及びオリエンテーション選択８６４を示している。本発明の異なる実施形態は、ユーザがこのオペレーションを多数の仕方（次のものを含む：１）マウスのような入力装置でエリアを選択し；及び２）複数のオリエンテーションがサポートされると仮定すれば、ポップアップメニューのようなインターフェイスで垂直、水平又はピボットテーブル間を選択する）で行うのをサポートすることができる。又、図８Ｅは、クラス「個人」の選択されたゲットプロパティメソッドの、ビューアの異なるセルへのマッピング８６６のセットも示している。より詳細には、マッピング８６６は、クラス「個人」のゲットプロパティメソッド「名」、「氏」、「誕生日」及び「年齢」が、それに対応する自由テキストを伴うセルの真下にあるセルへ各々マップングされることを示している。
【０１３２】
図８Ｆは、本発明の一実施形態による構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０でのテーブル生成の別の例示的スクリーンショット及び使用を示す。マッピング８６６は、クラス「個人」のゲットプロパティメソッドがマップされたテーブルの列に、そのクラスのインスタンスの対応ゲットプロパティメソッドの出力を自動的にポピュレートさせる。クラス「個人」のインスタンスに基づくテーブルのこのようなポピュレーションが８６８で示されている。図８Ｄの例では、クラス「個人」のゲットプロパティメソッド「名」、「氏」、「誕生日」及び「年齢」がマップされた列に、次のデータ行がポピュレートされる。即ち、１）STEVE、COLLINS、7/20/1990及び１６；２）JENNIFER、ADAMS、7/20/1990及び１６；及び３）JOHN、SMITH、7/20/1985及び２１。
【０１３３】
図８Ｄの場合と同様に、図８Ｅは、ゲットプロパティメソッドがマップされたビューアのセルがオーバーライドされることも示している。例えば、図８Ｆは、ゲットプロパティメソッド「誕生日」がマップされた列の第２行のセルがオーバーライドされた場合、出力が現在そのセルにポピュレートしているプロデューサの出力のオーバーライド、グローバルな実行コマンドのインボケーション（これは、ゲットプロパティメソッド「年齢」がマップされたセルに出力が現在ポピュレートしているプロデューサの再実行を生じさせる）、及びディスプレイの必要な更新を引き起こすことを示している。
【０１３４】
図８Ｃ−Ｆは、構成及びマッピンググラフィックユーザインターフェイスモジュール８４２により発生されるスクリーンを例示している。レンダリング及びインタラクティブなグラフィックユーザインターフェイスモジュール８４６により発生されるスクリーンは、（ゲットプロパティメソッドを伴う）クラス８５２のリスト、構成及びマッピングビューア８５４が、表示される構成及びマッピングビューア８５４と同じ映像を含むレンダリング及びインタラクティブなビューア（図示せず）に置き換えられることを除いて、同じである（相違は、マッピング特徴がもはや得られないことである）。
【０１３５】
例示的ランタイム配布スキーム
図９Ａ−Ｃは、本発明の一実施形態によるプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための種々のスキームを示す。これらの配布スキームは、例示に過ぎず、従って、本発明の範囲内で他のスキームも考えられる。
【０１３６】
図９Ａは、本発明の一実施形態によるプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第１のスキームを示すブロック図である。図９Ａにおいて、オブジェクト指向のソースコード９０５（プロデューサ依存性宣言を含む）が、プロデューサグラフ指向のプログラミングサポートを伴うランタイム９１０の上に示されており、このランタイムは、クラスローディング、ダイナミッククラスインスタンス生成、ダイナミック単一メソッドインボケーション、及びクラス／メソッドイントロスペクションを伴うランタイム９１５の上にあり、そしてこのランタイムは、オペレーティングシステム９２０の上にある。図９Ａにおいて、ランタイム９１０は、ランタイム９１５と共に働く。ランタイム９１０をランタイム９１５と共に働かせるのに多数のメカニズムを使用できるが、一例として、メタデータファシリティについて説明する。メタデータファシリティは、付加的な情報をソースコードに追加することができ、この情報は開発ツールにより使用される。例えば、Ｊａｖａ仕様のメタデータファシリティは、開発ツール、配備ツール又はランタイムライブラリーにより特殊な仕方で処理されねばならないことを指示する特殊な属性を有するとしてフィールド、メソッド及びクラスにアノテーション付けするためのＡＰＩを定義する（Ｊａｖａ仕様要求１７５）。この例では、オブジェクト指向のソースコード９０５をプログラミングするプログラマーは、プロデューサ依存性宣言の形態でメソッドにアノテーションを追加する。これらアノテーションは、ランタイム９１５によりランタイム９１０へハンドオフされるので、ランタイム９１０は、プロデューサ依存性宣言のシンタックスを指令する。図９Ａにおいて、ランタイム９１０及び９１５は、異なる組織によって開発され及び／又は配布されてもよい。
【０１３７】
図９Ｂは、本発明の一実施形態によるプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第２のスキームを示すブロック図である。図９Ｂにおいて、オブジェクト指向のソースコード９２５（プロデューサ依存性宣言を含む）がランタイム（クラスローディング、ダイナミッククラスインスタンス生成、ダイナミック単一メソッドインボケーション、及びクラス／メソッドイントロスペクション、並びにプロデューサグラフ指向のプログラミングサポートを伴う）９３０の上に示されており、そしてこのランタイムは、オペレーティングシステム９３５の上にある。図９Ａとの比較において、ランタイム９１０及び９１５が単一のランタイム９３０へと合成されている。この合成の結果として、ランタイム９３０は、プロデューサ依存性宣言のシンタックスを指令する。従って、オブジェクト指向のソースコード９２５をプログラミングするプログラマーは、要求されるシンタックスにプロデューサ依存性宣言を追加する。
【０１３８】
図９Ｃは、本発明の一実施形態によるプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第３のスキームを示すブロック図である。図９Ｃにおいて、オブジェクト指向のソースコード９４０（プロデューサ依存性宣言を含む）がオペレーティングシステムランタイム（クラスローディング、ダイナミッククラスインスタンス生成、ダイナミック単一メソッドインボケーション、及びクラス／メソッドイントロスペクション、並びにプロデューサグラフ指向のプログラミングサポートを伴う）９４５の上に示されている。図９Ｂと比較して、ランタイム９２０及びオペレーティングシステム９３５が単一エンティティへと合成されている。この合成の結果として、オペレーティングシステムランタイム９４５は、プロデューサ依存性宣言のシンタックスを指令する。従って、オブジェクト指向のソースコード９４０をプログラミングするプログラマーは、要求されるシンタックスにプロデューサ依存性宣言を追加する。
【０１３９】
ランタイムが、クラスローディング、ダイナミッククラスインスタンス生成、ダイナミック単一メソッドインボケーション、及びクラス／メソッドイントロスペクションを有するような実施形態を説明したが、別の実施形態は、より多くの又はより少ない特徴を含んでもよい（例えば、インスタンスクローンニング、ダイナミックプロキシー、プリミティブ形式変換、等）。
【０１４０】
例示的効果
本発明の一実施形態においては、手動インボケーションシーケンスコードを使用せずに適切なインスタンスを使用して（ここで、適切なインスタンスは、引数として使用すべきインスタンス、インスタンスメソッドにより使用されるべきインスタンス、及びクラスメソッドにより使用されるメタクラスインスタンスを含む）メソッドインボケーションシーケンスを指定する仕方としてメソッドに対してプロデューサ依存性が宣言された。実際に、手動インボケーションシーケンスコードの幾つか又は全部を発生する作業は、次のものに置き換えられる。即ち、１）プロデューサ依存性宣言を書き込むためにアプリケーションプログラマーによって行われる作業；及び２）プロデューサグラフ（１つ又は複数）を発見及び構築し、そしてこれらプロデューサグラフ（１つ又は複数）のプロデューサを実行するためにランタイムにより行われる作業。換言すれば、手動インボケーションシーケンスコードに以前に含まれていたロジックは、プロデューサ依存性宣言に基づき、ランタイム中に、ランタイムにより発見することができる。従って、プロデューサ依存性宣言は、どんな引数を伴うどんなインスタンスのどんなメソッドを同期のためにいつ実行すべきかランタイムへ通知する。ランタイムを書くための努力は、比較的多大であるが、ランタイムに対して書かれたオブジェクト指向のアプリケーションを実行するのに使用できるという点で、一度書くだけでよく、対照的に、典型的なアプリケーションの場合、プロデューサ依存性宣言を書くための努力は、手動インボケーションシーケンスコードを書くことに比べて比較的僅かである。
【０１４１】
プログラミングミステークの減少
プロデューサグラフ指向のプログラミングは、典型的に、手動インボケーションシーケンスコードのデバッグ及び／又は性能同調に関するコストを減少する。これは、少なくとも、アプリケーションプログラムのインフラストラクチャーが、概念的に、特定入力に対して動作するオブジェクトの変換メソッドの非公式化グラフのセットである（オブジェクトの１つのメソッドの出力は、別のメソッドへの入力となり、等々）という理由で言えることである。プロデューサ依存性宣言、及びプロデューサグラフ指向のプログラミングサポートを伴うランタイムは、これらのグラフをプロデューサグラフとして公式化する。従って、データが変化する機会のたびに、アプリケーションプログラマーは、適切なインスタンスの適切な変換メソッドを適切な入力と共に適切な順序でインボークさせるために、その作用を考慮して手動インボケーションシーケンスコードを書き込む必要がない。換言すれば、データが変化する機会のたびに、アプリケーションプログラマーは、どのグラフが影響を受けるか、及びそれらグラフ内のインスタンスのどの変換メソッドが影響を受けるか考慮する必要がない。むしろ、自動プロデューサグラフ発生モジュールがプロデューサグラフを発見及び構築し、そしてプロデューサグラフ実行モジュールが、データの変化を反映するように、必要に応じてプロデューサグラフを再実行する。この自動化は、次のようなミステークを回避する上でアプリケーションプログラマーの助けとなる。１）適切なインスタンスの適切な変換メソッドを間違った順序でインボークし、２）グラフにおけるインスタンスの１つ以上の要求された変換メソッドをあるデータの変化に応答してインボークさせるためのコマンドを入れ忘れ、３）あるデータの変化に応答してインスタンスの不必要な変換メソッドをインボークさせるコマンドを含ませる（例えば、データの変化により影響されるグラフの部分でないインスタンスの変換メソッドをインボークするコマンドを含ませ；データの変化により影響されるグラフの部分であるが、それ自身は影響のないインスタンスの変換メソッドをインボークするコマンドを含ませ；等々）。
【０１４２】
同期
上述したように、実行中にプロデューサ出力をキャッシュ記憶することで、同期をとることができる。従って、オブザーバーパターンとの比較に関して、プロデューサ依存性宣言は、プロデューサグラフ指向のプログラミングサポートを伴うランタイムに依存性を通知し、そしてランタイムは、どんなプロデューサがいつコールバックするか決定する。
【０１４３】
結果を完全に説明する能力
本発明の一実施形態では、ドリル／ビュー(drilling/viewing)モジュール（図示せず）がランタイムの一部分として含まれる。このドリル／ビューモジュールは、エンドユーザによる対話を通して、プロデューサグラフまで掘削して（根ノードからプロデューサグラフまでウォーキングして）、プロデューサグラフの種々のプロデューサの出力を見ることができるようにするグラフィックユーザインターフェイスをなす。これは、エンドユーザが、データ値及び依存性（依存性決定プロデューサにより返送された）を含めて、問題とするプロデューサの出力に貢献した種々の出力を見ることができるようにする。更に、本発明の一実施形態では、このドリル／ビューモジュールは、エンドユーザが、プロデューサのメソッド内のコード、プロデューサのインスタンスの値、及び／又はプロデューサのクラスのコンテンツを見る能力を与える。
【０１４４】
従って、ドリル／ビューモジュールは、デバッグ、出力の説明、等を含む種々の後処理アクティビティを与える。
【０１４５】
例示的な実際のアプリケーション／技術的効果／産業上の利用性
本発明の異なる態様及び実施形態には種々の例示的な実際のアプリケーションがある。例えば、ランタイムは、アプリケーションプログラムの実行の一部分として、マシン記憶媒体から情報を検索し（例えば、プロデューサ依存性宣言を含むオブジェクト指向のソースコードにアクセスし）、マシン記憶媒体に情報を記憶し（例えば、プロデューサグラフ（１つ又は複数）構造、等に類似したデータ構造を記憶し）、ハードウェア処理リソースを動作させ、問題とするプロデューサ（１つ又は複数）の出力を与え（例えば、グラフィックユーザインターフェイスを通して、マシン記憶媒体への記憶、送信、等）、等々を行う。ある意味においては、前処理アクティビティは、このようなアプリケーションプログラムの書き込み及び／又はデータの付与を含み（このデータは、多数の物理的及び／又は実際的なアイテム、例えば、金融的な値、地理的な値、気象学的な値、保険的な値、統計学的な値、物理学的な尺度、マシン状態値、等を表す）、一方、後処理アクティビティは、結果の付与を含む（この結果は、多数の物理的及び／又は実際的なアイテム、例えば、金融的な分析、地理的な分析、気象学的な分析、保険的な分析、統計学的な分析、工業的な尺度、マシン制御情報、等）。特定の例として、後処理アクティビティは、次のものにより与えることができる。１）ランタイムにより発生される現在プロデューサグラフ（１つ又は複数）の表現をグラフ表示するための図１０のプロデューサグラフビューアモジュール１０６２；及び／又は２）プロデューサグラフからの出力をグラフ表示しそしてそれと対話するための構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０（図１０の構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール１０８５も参照されたい）。
【０１４６】
別の例として、ランタイムにより実行されたとき、プロデューサ依存性宣言それ自体を伴うアプリケーションプログラムは、物理的／実際的なアイテムを表し、そして上述したオペレーションを生じさせる。特定例として、これらのプロデューサ依存性宣言は、ランタイムによる実行に応答してデータ構造をマシン記憶媒体に形成するようにさせる。又、プロデューサ依存性宣言は、アプリケーションプログラムと共にマシン記憶媒体に記憶されそしてそこから検索される。更に、これらプロデューサ依存性宣言は、プロデューサ間の関係を表し、一方、プロデューサは、実行されるべきオペレーション（メソッド）及びインスタンスを表す。オブジェクト指向のプログラミングにおけるインスタンスは、物理的及び／又は実際的アイテムを表現するのに使用でき、一方、プロデューサは、それらの表現に対して遂行されるべきオペレーションを表現する。
【０１４７】
別の例として、１つ以上のアプリケーションプログラム及びランタイムのセットは、外国為替、総資産、利子、信用、インフレーション、物価、及びクロスアセット複合商品をカバーするクロスアセットリスク管理ソフトウェアを具現化する。これらの商品は、現金及び物理的にプレーンなバニラ商品から、エキゾチックで複雑なデリバティブ商品までの範囲である。又、これらの商品に対する数学的評価モデルのセット、並びにそれらに関連したマーケットデータ、支払及び会計エントリー発生ルーチン及びそれらに関連した観察可能な校正モデル及びそれに関連した生の入力も含まれる。
【０１４８】
別の例として、１つ以上のアプリケーションプログラム及びランタイムのセットは、ワードプロセッサ、スプレッドシート、通信／ｅ−メールソフトウェア、フォトビューイングソフトウェア、ウィルススキャンソフトウェア、メディアプレーヤ、データベースサーバー、ゲーム、工業用アプリケーション、コンピュータ支援型設計ツールアプリケーション、及び／又はオペレーティングシステムを具現化することができる。もちろん、アプリケーションプログラムは、種々の他のタスクを遂行するように具現化することもできる。
【０１４９】
例示的具現化
例示として、依存性、ダイナミックな依存性（コンティンジェント(contingent)依存性及びサブスクリプション(subscription)依存性を含む）、ショートカット宣言依存性及び非ショートカット宣言依存性に対する明示的依存性決定プロデューサ、ショートカット宣言依存性に対するオンザフライ依存性決定プロデューサ、クラスキー、インスタンスキー、メソッドキー、プロデューサオーバーライド／非オーバーライドコマンド（セットコマンドの形式である）、及びグローバル実行コマンドをサポートする本発明の実施形態について説明する。更に、これら実施形態は、任意であるが、プロデューサグラフのインタラクティブなビューアモジュール及び増分的実行もサポートする。もちろん、本発明の別の実施形態は、より多くの特徴、より少ない特徴及び／又は異なる特徴を具現化することができる。
【０１５０】
図１０は、本発明の一実施形態による例示的具現化のブロック図である。図１０において、破線の分割線１０００は、ランタイムクライアント１００２を、プロデューサグラフ指向のプログラミングサポートを伴うランタイム１００４から分離している。
【０１５１】
ランタイムクライアント１００２の論理的実行フローは、ブロック１０１０、１０２０、１０２５、１０３０及び１０３５を備え、そしてプロデューサグラフ指向のプログラミングサポートを伴うランタイム１００４は、対応するブロック１０９５、１０９８、１０４０、１０４５、及び１０７０を各々備え、一方、矢印付きの実線は、ランタイムクライアント１００２の論理的実行フローのブロック１０３５から、プロデューサグラフ指向のサポートを伴うランタイム１００４のブロック１０７０への直接的因果関係を表し、矢印付き点線は、ランタイムクライアント１００２のブロック１０１０、１０２０、１０２５及び１０３０から、プロデューサグラフ指向のプログラミングサポートを伴うランタイム１００４のブロック１０９５、１０９８、１０４０及び１０４５への因果関係を示している。本発明の実施形態に基づき、これら後者の因果関係は、直接的でも、間接的でもよい。例えば、図６と同様に、コマンドログ（図示せず）及び／又はオーバーライドログ１０４７の使用による任意の間接的因果関係を使用してもよい。更に、ブロック１０９５及び１０９８は、本発明の実施形態に基づき異なるブロックの一部分であるのも任意であるから、破線にされている（例えば、ブロック１０９５は、ブロック１０９８の一部分でよく、ブロック１０９８は、ブロック１０４０の一部分でよく、ブロック１０９５及び１０９８は、ブロック１０４０の一部分でよい）。同様に、ブロック１０４５は、本発明の実施形態に基づき異なるブロックの一部分であるのも任意であるから、破線にされている（例えば、ブロック１０４５は、ブロック１０７０の一部分でもよい）。
【０１５２】
図１０において、ランタイム１００２は、ビジネスロジックを含むクラス定義１０１０を備え、これは、データ１０１２、メソッド１０１４、プロデューサ依存性宣言１０１６、及び任意のクラスキー１０９０を有する。クラス定義１０１０は、オブジェクト指向のプログラミング言語のクラスであり、従って、データ及びメソッド１０１４に対する定義を含む。更に、これらのクラス定義１０１０は、上述したように、メソッド１０１４に対するプロデューサ依存性宣言１０１６を含む。更に、本発明の一実施形態では、各クラスは、追跡のためのクラスキー１０９０を有する。
【０１５３】
ランタイム１００４の新クラスモジュール１０９５は、クラス定義１０１０をロードし、イントロスペクトする（例えば、新クラスコマンドに応答して）。このようにロードしてイントロスペクトすることは、最適化の目的でクラスを選択的にロードするためのものを含めて、多数の良く知られた技術又は将来開発される技術を使用して行うことができる。新クラスモジュール１０９５によりクラスをロードすることは、ランタイム１００４のクラス１０５４で示されている。クラス１０５４をロードしてイントロスペクトする一部分として、新クラスモジュール１０９５は、クラス１０５４におけるメソッド及びプロデューサ依存性宣言１０５６により示されたように、プロデューサ依存性宣言１０１６もロードし、イントロスペクトする。又、新クラスモジュール１０９５は、クラスキーを使用してクラスを追跡するのに使用されるクラス追跡構造１０９２も維持する。従って、クラス追跡構造１０９２は、クラスキーとクラス１０５４へのリファレンスとの間の対応性を維持する。更に、新クラスモジュール１０９５は、メソッドキーを使用してメソッドを追跡するのに使用されるメソッド追跡構造１０５８も維持する。従って、メソッド追跡構造１０５８は、メソッドキーとメソッドへのリファレンスとの間の対応性、並びにプロデューサ依存性宣言に関する情報を維持する。
【０１５４】
又、ランタイムクライアント１００２は、インスタンスキーを伴うインスタンスインスタンス生成コマンド１０２０も備えている。ランタイム１００４の新インスタンスモジュール１０９８は、（例えば、新インスタンスコマンドに応答して）インスタンスキーを伴うインスタンスインスタンス生成コマンド１０２０により指定されたインスタンスをインスタンス生成する。このようにインスタンスをインスタンス生成することは、最適化の目的でインスタンスを選択的にインスタンス生成するためのものを含めて、多数の良く知られた技術又は将来開発される技術を使用して行うことができる。インスタンスをこのようにインスタンス生成する一部分として、新インスタンスモジュール１０９８は、クラス１０５４から適切なクラスにアクセスするために、クラスキーを使用してクラス追跡構造１０９２にアクセスする。新インスタンスモジュール１０９８によりインスタンスをインスタンス生成することは、ランタイム１００４のインスタンス１０５２によって示される。又、新インスタンスモジュール１０９５は、インスタンスキーを使用してインスタンスを追跡するのに使用されるインスタンス追跡構造１０６５も維持する。従って、インスタンス追跡構造１０６５は、インスタンスキーとインスタンス１０５２へのリファレンスとの間の対応性を維持する。上述したように、新クラスモジュール１０９５は、クラス１０５４が、個別の新クラスコマンドではなく、インスタンスのインスタンス生成コマンド１０２０に応答してインスタンス生成されるという点で、新インスタンスモジュール１０９８の一部分であってもよい。
【０１５５】
又、ランタイムクライアント１００２は、プロデューサキーを伴うプロデューサインスタンス生成コマンド１０２５も備えている。ランタイム１００４の自動プロデューサグラフ発生モジュール１０４０は、プロデューサキーを伴うプロデューサインスタンス生成コマンド１０２５により指定されたプロデューサをインスタンス生成する（例えば、問題とするプロデューサの現在セットを指定する新プロデューサコマンドに応答して）。更に、自動プロデューサグラフ発生モジュール１０４０は、上述した問題とするプロデューサの現在セットに応答してプロデューサグラフ（１つ又は複数）を発見し、構築し、及び任意なこととして、解明もする。本発明の一実施形態では、プロデューサキーは、クラスキー、インスタンスキー、及びメソッドキーで構成される。プロデューサのこのインスタンス生成の一部分として、自動プロデューサグラフ発生モジュール１０４０は、１）クラス１０５４から適切なクラスにアクセスするために、クラスキーを使用してクラス追跡構造１０９２にアクセスし；２）インスタンス１０５２から適切なインスタンスにアクセスするために、インスタンスキーを使用してインスタンス追跡構造１０６５にアクセスし；そして３）適切なプロデューサ依存性宣言ステートメントにアクセスするために、メソッドキーを使用してメソッド追跡構造にアクセスする。プロデューサキーを伴うプロデューサインスタンス生成コマンドにより指定されたプロデューサをインスタンス生成し、発見されたプロデューサをインスタンス生成し、そしてプロデューサグラフを構築することが、ランタイム１００４のプロデューサグラフ（１つ又は複数）構造１０６０で示されている。従って、本発明の一実施形態では、プロデューサキーを伴うプロデューサインスタンス生成コマンドにより識別されたプロデューサキー、及びプロデューサグラフ発生を通して発見されたプロデューサキーは、現在プロデューサグラフ（１つ又は複数）を表す追加情報と共に、プロデューサグラフ（１つ又は複数）構造１０６０に記憶される。
【０１５６】
上述したように、ブロック１０９５及び１０９８は、ブロック１０４０の一部分でもよく、従って、どのクラス、インスタンス及びプロデューサをロード／インスタンス生成のためにどんなプロデューサにより駆動するかの判断は、現在プロデューサグラフ（１つ又は複数）において行われる。本発明のこのような実施形態では、クラス、インスタンス、及びプロデューサのロード／インスタンス生成が最適化され、プロデューサ中心となる。
【０１５７】
又、ランタイムクライアント１００２は、プロデューサ出力オーバーライド／非オーバーライドコマンドを含むデータ準備コマンド１０３０も備えている。オーバーライド／非オーバーライドコマンドは、オーバーライド／非オーバーライドされるべきプロデューサのプロデューサキーと、オーバーライドされるときのオーバーライド値とを含む。ランタイム１００４のオーバーライドプロデューサ出力モジュール１０４５は、プロデューサオーバーライド／非オーバーライドコマンドにより指定されたプロデューサをオーバーライド／非オーバーライドさせる。この因果関係は、間接的でも、直接的でもよい。
【０１５８】
間接的な因果関係の場合に、オーバーライドプロデューサ出力モジュール１０４５は、プロデューサグラフ実行モジュール１０７０によって消費するためにオーバーライドログ１０４７をポピュレートする。直接的な因果関係の場合には、オーバーライドプロデューサ出力モジュール１０４５は、プロデューサグラフ（１つ又は複数）構造１０６０のプロデューサ出力キャッシング１０９７及びインスタンス１０５２にアクセスする。より詳細には、オーバーライドプロデューサ出力モジュール３９０を参照すれば、一実施形態において、プロデューサは、プロパティプロデューサ又はメソッドプロデューサとして分類することができ、従って、オーバーライドプロデューサ出力モジュール１０４５は、オーバーライドされたプロパティプロデューサのためのオーバーライドプロパティプロデューサ出力モジュール（図示せず）と、オーバーライドされたメソッドプロデューサのためのオーバーライドメソッドプロデューサ出力モジュール（図示せず）とを含み、プロパティメソッドをオーバーライドすると、オーバーライドされた値を、プロデューサグラフ（１つ又は複数）構造１０６０のプロデューサ出力キャッシング１０９７に記憶させると共に、インスタンス１０５２の適切なインスタンスに記憶させ、一方、メソッドプロデューサをオーバーライドすると、オーバーライドされた値をプロデューサ出力キャッシング１０９７に記憶させる。
【０１５９】
本発明の一実施形態では、プロデューサは、それが一部分であるところのプロデューサグラフが最初に実行されるまでオーバーライドされない（従って、プロデューサは、問題とするプロデューサとして指定される結果、又は自動プロデューサグラフ発生モジュール１０４０により発見される結果として予めインスタンス生成される）。しかしながら、図１０に示す実施形態では、プロデューサは、初期実行の前に、プロデューサオーバーライドコマンドでインスタンス生成されオーバーライドされることにより、オーバーライドすることができる。このようなオーバーライドされたプロデューサは、通常、最終的に、発見プロセスを通してプロデューサグラフの一部分となる（例えば、ダイナミック依存性が解明されるとき）。本発明のある実施形態では、このデータ準備は、他の形式のセットコマンドも含み得る。オーバーライドプロデューサ出力モジュール１０４５は、本発明の別の実施形態では存在しないことがあるので、破線のボックスとして示されている。
【０１６０】
又、プロデューサグラフ（１つ又は複数）構造１０６０は、任意であるが、増分的実行をサポートする本発明の幾つかの実施形態に対して増分的実行マーキング１０８０も含む。図３Ｂの増分的実行マーキング３８２を参照して上述したように、増分的実行マーキング１０８０は、初期実行のものを越えた実行においてプロデューサグラフ（１つ又は複数）の増分的実行を助けるのに使用される。増分的実行マーキング３８２を使用する本発明の異なる実施形態は、それらを異なる仕方で使用する。例えば、コマンドログを有する本発明の１つのこのような実施形態では、どのプロデューサが追加され及び／又は変更されるか追跡するのにログが使用され、そして増分的実行マーキング３８２は、影響を受けるプロデューサ（変更又は追加されたプロデューサの先祖であり、従って、それらに依存する）をマークするのに使用される。別の例として、コマンドログをもたない本発明の１つのこのような実施形態では、増分的実行マーキング３８２は、追加又は変更されるプロデューサ、並びに変更又は追加されるプロデューサの先祖である（従って、それらに依存する）プロデューサをマークするのに使用される。別の例として、コマンドログをもたない本発明の１つのこのような実施形態では、プロデューサの変更及び追加が直ちに行われ、そして増分的実行マーキング３８２は、変更又は追加されるプロデューサの先祖である（従って、それらに依存する）プロデューサをマークするのに使用される。増分的実行をサポートしそして増分的実行マーキングを使用する本発明の実施形態を説明したが、本発明の他の実施形態は、増分的実行マーキングを使用しない増分的実行をサポートする（例えば、どのプロデューサが追加又は変更されたか追跡するのにコマンドログが使用され、そして実行スタートプロデューサのリストが実行スタートログに維持され、ここで、プロデューサグラフ実行モジュール１０７０は、実行スタートプロデューサからスタートし、そしてプロデューサグラフの先祖を最上位まで上るように働き、例えば、これに限定されないが、本発明のこの実施形態は、図１５−２５を参照して、以下に説明する。
【０１６１】
又、ランタイムクライアント１００２は、グローバル実行コマンド１０３５を含む。ランタイム１００４のプロデューサグラフ実行モジュール１０７０は、プロデューサグラフ（１つ又は複数）を実行する。従って、プロデューサグラフ実行モジュール１０７０は、プロデューサ出力キャッシング１０９７を変更し（プロパティプロデューサ及びメソッドプロデューサの場合に）、増分的実行マーキング１０８０（もしあれば）を使用し、そしてインスタンス１０５２のデータを変更する（プロパティメソッドの場合に）。  プロデューサグラフのプロデューサを実行するための種々の技術が、上述され、ここに適用することきる。例えば、コマンドログが具現化される実施形態では、コマンドログが消費され、次いで、プロデューサグラフ（１つ又は複数）が実行される。更に、未解明の依存性の可能性をサポートする本発明の実施形態では、プロデューサグラフ実行モジュール１０７０は、ダイナミック依存性モジュール１０７５を含み、これは、自動プロデューサグラフ発生モジュール１０４０をインボークすることができる。
【０１６２】
又、図１０は、プログラマー／ユーザが、プロデューサグラフ（１つ又は複数）構造のプロデューサグラフ（１つ又は複数）及びプロデューサ出力を見ることができるようにするメカニズム（例えば、グラフィックユーザインターフェイス）を与える任意のプロデューサグラフビューアモジュール１０６２も示している。更に、図１０は、構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０を表すグラフィックユーザインターフェイス（ブロック１０３０及び１０３５のダイナミックインボケーションを含む）を与えるための任意の構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール１０８５も示している。
【０１６３】
コマンドログを使用する本発明の実施形態では、異なるトリガーを使用して、異なるアクションをトリガーすることができる。例えば、プロデューサインスタンス生成コマンドは、明示的コマンド（ロギング開始及びロギング終了）、明示的グローバル実行コマンド（スタート時及び各明示的グローバル実行コマンドの後にロギングが自動的にスタートし、そしてそれに続く明示的グローバル実行コマンドに応答して各ログが処理される）、明示的データ準備コマンド、等に応答して、ログされ、バッチ処理される。同様に、データ準備コマンドは、明示的グローバル実行コマンド、第１ゲットコマンド、各ゲットコマンド、等に応答して、ログされ、バッチ処理される。
【０１６４】
例示的追跡構造
図１１Ａ−Ｄは、本発明の一実施形態による図１０のデータ構造の例示的コンテンツを示すブロック図である。図１１Ａ−Ｄは、これらのデータ構造をテーブルとして示すが、適当なデータ構造（例えば、ハッシュマップ、セット、リスト）を使用できることを理解されたい。
【０１６５】
図１１Ａは、本発明の一実施形態による図１０のクラス追跡構造１０９２の一例を示すブロック図である。図１１Ａにおいて、クラスキー列１１１０及びクラスリファレンス列１１１５は、各々、ロードされるクラスに対するクラスキー及びその対応リファレンスを記憶するように示されている。
【０１６６】
図１１Ｂは、本発明の一実施形態による図１０のインスタンス追跡構造１０６５の一例を示すブロック図である。図１１Ｂにおいて、インスタンスキー列１１２０及びインスタンスリファレンス列１１２５は、各々、インスタンスに対するインスタンスキー及びその対応リファレンスを記憶するように示されている。インスタンスキーが全てのクラスにわたって独特である必要のない本発明の実施形態では、インスタンス追跡構造は、インスタンスのクラスに対するクラスキー又はリファレンスも含む。
【０１６７】
図１１Ｃは、本発明の一実施形態による図１０のプロデューサグラフ（１つ又は複数）構造１０６０の一例を示すブロック図である。図１１Ｃにおいて、クラスリファレンス列１１３５、インスタンスリファレンス列１１４０、及びメソッドリファレンス列１１４５は、現在プロデューサグラフ（１つ又は複数）の現在プロデューサを作り上げるリファレンスを各々記憶するように示されている。これらのリファレンスは、種々の形態をとり得る。例えば、これらの列は、クラス１０５４（或いは１０９２）、インスタンス１０５２（或いは１０６５）、及びメソッド１０５６（或いは１０５８）に対するリファレンスを記憶する。本発明の一実施形態では、これらの列はリファレンスを記憶するが、本発明の別の実施形態では、これら列の１つ以上がキーを記憶してもよい。
【０１６８】
更に、図１１Ｃは、親プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１５０（各リンクに対して親プロデューサリファレンス及び依存性決定プロデューサリファレンスを含む）と、子プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１６０（各リンクに対して、子プロデューサリファレンス（１つ又は複数）、依存性決定プロデューサリファレンス、リンクモード、及びスティッキーリンクインジケータを含む）とを含む。各プロデューサは、０以上の子プロデューサリンクを列１１６０に有する。列１１６０の各子プロデューサリンクは、次のものを含む。１）プロデューサ依存性宣言によりプロデューサ依存性を表すためにプロデューサグラフ（１つ又は複数）構造の他の行に対するリファレンスである子プロデューサリファレンス（１つ又は複数）；２）プロデューサグラフ（１つ又は複数）構造の別の行に対するリファレンスであり且つ子リンクを生成した依存性決定プロデューサを表す依存性決定プロデューサリファレンス；３）プロデューサ依存性が引数、フィールド又はシーケンス依存性の結果であるかどうか識別するプロデューサ依存性形式（図７Ａ−Ｆに関する説明を参照）と、引数の場合には、プロデューサ依存性の引数ＩＤとを伴うリンクモード；及び４）リンクモードが、上方に宣言された依存性の結果（上方に宣言された依存性をサポートする本発明の実施形態における）であるか、又はスティッキーサブスクリプションの結果（スティッキーサブスクリプションをサポートする本発明の実施形態における）であることを指示し、且つこのプロデューサ（即ち、スティッキーインジケータを含む列の行に記憶されたプロデューサ）のプロデューサ引数依存性宣言を通して変更されてはならないスティッキーインジケータ。各プロデューサは、０以上の親プロデューサリンクを列１１５０に有してもよい。列１１５０の各親プロデューサリンクは、次のものを含む。１）別のプロデューサの子プロデューサリファレンスに基づくリファレンスを記憶して戻す親プロデューサリファレンス（即ち、このプロデューサに依存する親プロデューサを表すためのプロデューサグラフ（１つ又は複数）構造の別の行に対するリファレンス）；２）プロデューサグラフ（１つ又は複数）構造の別の行に対するリファレンスであり且つ親リンクを生成した依存性決定プロデューサを表す依存性決定プロデューサリファレンス。従って、リンクが生成されるときには、子プロデューサ行の親プロデューサリンク列、及び親プロデューサ行の子プロデューサリンク列がそのリンクを表すように変更される（そして依存性決定プロデューサリファレンスは、両方において同じである）。本発明の一実施形態では、あるプロデューサグラフ又は異なるプロデューサグラフにおける複数の経路が所与のプロデューサを含むので、所与のプロデューサに対して複数の親プロデューサリンクが存在し得る。
【０１６９】
更に、図１１Ｃは、現在プロデューサ出力、プロデューサがオーバーライドされたかどうかの指示、及びオーバーライドされた出力値を記憶するためのプロデューサ出力キャッシング及びオーバーライドプロデューサ出力変更列１１７０も含む。又、図１１Ｃは、上述した増分的実行マーキングを記憶するための増分的実行マーキング列１１８０も含む。
【０１７０】
図１１Ｄは、本発明の一実施形態による図１０のメソッド追跡構造１０５８の一例を示すブロック図である。図１１Ｄにおいて、メソッドキー列１１９０及びメソッドリファレンス列１１９２は、各々、ロードされるクラスのメソッドに対するメソッドキー及びその対応リファレンスを記憶するように示されている。更に、図１１Ｄは、ArgumentDependencies列１１９４、FieldDependencies列１１９６、SequencingDependencies列１１９５、UpwardDependencies列１１９３、WeaklyConstrainedDependencies列１１９９、出力クラス列１１９７、及び任意の付加的なアノテーション列１１９８も示している。ArgumentDependencies列１１９４、SequencingDependencies列１１９５、UpwardDependencies列１１９３、WeaklyConstrainedDependencies列１１９９、及びFieldDependencies列１１９６は、メソッドのプロデューサ依存性宣言ステートメント（図７Ａの７０５を参照）から構文解析されたプロデューサ依存性情報を記憶し、一方、出力クラス列１１９７は、メソッドの出力の出力クラス（メソッドのシグネチュアにより決定できる−例えば、図７Ａの７１０を参照）に関する情報を記憶する。本発明の幾つかの実施形態で使用されるArgumentDependencies列１１９４、FieldDependencies列１１９６、SequencingDependencies列１１９５、UpwardDependencies列１１９３、及びWeaklyConstrainedDependencies列１１９９の例示的なコンテンツは、以下で述べる。
【０１７１】
ダイナミックプロデューサ依存性
上述したように、本発明の一実施形態は、非ダイナミック及びダイナミックプロデューサ依存性をサポートする。異なる実施形態は、異なる形式のダイナミックプロデューサ依存性をサポートするが、本発明の一実施形態は、コンティンジェント及びサブスクリプション形式のダイナミックプロデューサ依存性をサポートする。従って、非コンティンジェント、非サブスクリプション依存性は、非ダイナミック（スタティック）依存性である。
【０１７２】
図１２は、本発明の一実施形態によりコンティンジェント及びサブスクリプション形式のダイナミックプロデューサ依存性をサポートするための図１０の付加的な細部を示すブロック図である。図１２は、図１０から、破線の分割線１０００、ビジネスロジックを含むクラス定義１０１０（これは、データ１０１２、メソッド１０１４、及びプロデューサ依存性宣言１０１６を含む）、新クラスモジュール１０９５、クラス１０５４（メソッド及びプロデューサ依存性宣言１０５６を含む）、新インスタンスモジュール１０９８、インスタンス１０５２、インスタンス追跡構造１０６５、自動プロデューサグラフ発生モジュール１０４０、プロデューサグラフ（１つ又は複数）構造１０６０、及びプロデューサグラフ実行モジュール１０７０（ダイナミック依存性モジュール１０７５を含む）を含む。
【０１７３】
図１２は、プロデューサ依存性宣言１０１６が、任意であるが、コンティンジェント依存性１２１０、サブスクリプション依存性１２２０、及び複数のプロデューサ１２１５を含むことを示している。ここで、複数のプロデューサ１２１５は、プロデューサの集合を返送するためのプロデューサ依存性の能力を指す。更に、図１２は、コンティンジェント依存性１２１０及びサブスクリプション依存性１２２０を処理するために自動プロデューサグラフ発生モジュール１０４０にサブスクリプションモジュール１２４０及びコンティンジェンシーモジュール１２３０を含む。又、図１２は、サブスクリプションモジュール１２４０がサブスクリプションログ１２５０にアクセスすることも示している。更に、ダイナミック依存性モジュール１０７５は、コンティンジェント依存性１２１０及びサブスクリプション依存性１２２０を処理するためにコンティンジェンシーモジュール１２６０及びサブスクリプションモジュール１２６５を備えている。サブスクリプションモジュール１２６５は、サブスクリプションログ１２５０にアクセスする。
【０１７４】
コンティンジェント及びサブスクリプション依存性の以下の説明は、依存性決定プロデューサによりインスタンスが返送されてプロデューサグラフ指向のプログラミングサポートを伴うランタイムにより分析されるところのクラスＤＥＰ（依存性の省略形）を使用する本発明の実施形態の環境で行われる。クラスＤＥＰは、次のフィールドを含む。１）サブスクリプション、非サブスクリプション下方宣言（サブスクリプションでない子プロデューサ）又は非サブスクリプション上方宣言（サブスクリプションでない親プロデューサ）にセットすることのできるＴＹＰＥ；２）非サブスクリプション下方宣言依存性に使用され且つ子プロデューサの集合である（従って、０以上のプロデューサを記憶できる）ＰＲＯＤ；３）サブスクリプション依存性に使用され且つサブスクリプション依存性の形式を指示するようにセットされるＳＵＢ  ＴＹＰＥ（複数の形式のサブスクリプションをサポートする本発明の実施形態に使用されるが、ここに述べる本発明の実施形態は、スティッキー及びアブソーブの２つの形式をサポートし、別の実施形態は、より多くの、より少ない及び／又は異なるサブスクリプション形式をサポートしてもよい）；４）サブスクリプション依存性に使用され且つサブスクリプション基準を指示するようにセットされるＳＵＢ  ＣＲＩＴ；５）スティッキーサブスクリプション依存性及び非サブスクリプション上方宣言依存性に使用され且つ親プロデューサのどんなリンクモードでなければならないか指示するようにセットされるＰＡＲ  ＬＩＮＫ  ＭＯＤＥ；６）スティッキーサブスクリプション依存性及び非サブスクリプション上方宣言依存性に使用され且つ親プロデューサのどんなクラス（例えば、クラスキー）でなければならないか指示するようセットされるＰＡＲ  ＣＬＡＳＳ；７）スティッキーサブスクリプション依存性及び非サブスクリプション上方宣言依存性に使用され且つ親プロデューサのどんなメソッド（例えば、メソッドキー）でなければならないか指示するようにセットされるＰＡＲ  ＭＥＴＨＯＤ；及び８）スティッキーサブスクリプション依存性及び非サブスクリプション上方宣言依存性に使用され且つ親プロデューサのどんなインスタンス（例えば、インスタンスキー）でなければならないか指示するようにセットされるＰＡＲ  ＩＮＳＴＡＮＣＥ（ＰＡＲＩＮＳＴＡＮＣＥをブランクのままにすると、子プロデューサのインスタンスキーが親プロデューサに対して使用される）。別の実施形態は、スティッキーサブスクリプション依存性及び／又は非サブスクリプション上方宣言依存性の場合に、親プロデューサの集合を使用する（集合の各アイテムは、ＰＡＲ＿ＣＬＡＳＳ、ＰＡＲ＿ＩＮＳＴＡＮＣＥ、ＰＡＲ＿ＭＥＴＨＯＤ、ＰＡＲ＿ＬＩＮＫ  ＭＯＤＥを保持する）。もちろん、本発明の他の実施形態は、異なる構造を使用して、依存性を返送することができる。
【０１７５】
コンティンジェント依存性
本発明の一実施形態において、非コンティンジェント及びコンティンジェントの両プロデューサ依存性がサポートされる。非コンティンジェントのプロデューサ依存性は、他のプロデューサの出力とは独立したものであり、一方、コンティンジェントのプロデューサ依存性は、他のプロデューサの出力に依存したものである。本発明の一実施形態は、非コンティンジェント及びコンティンジェントの両プロデューサ依存性をサポートするが、別の実施形態は、非コンティンジェント又はコンティンジェントしかサポートしない（どちらかのコンティンジェントのプロデューサ依存性がデフォールト値によって最初に駆動されてもよい）。
【０１７６】
上述したように、プロデューサは、指定の粒度の付加的なレベルごとに１つある、複数の識別子のセットとして見ることができる。本発明の実施形態では、コンティンジェントのプロデューサ依存性は、識別子のセットの中のいずれか１つ又は全部を現在データ値に基づいて条件付きで決定できるという意味で、コンティンジェントである。例えば、第１のコンティンジェントのプロデューサ依存性は、インスタンス識別子しか条件付きで決定できず（クラス及びメソッド識別子は固定であり）、一方、第２のコンティンジェントのプロデューサ依存性は、クラス、インスタンス及びメソッドの識別子を条件付きで決定することができる。本発明の一実施形態では、コンティンジェントのプロデューサ依存性の複数の識別子が全て条件付きであるが、本発明の別の実施形態は、異なる仕方で具現化されてもよい（例えば、複数の識別子のうちのサブセットのみを条件付きとすることができる）。
【０１７７】
図１３Ａ−Ｊは、本発明の実施形態による擬似コード及び例示的プロデューサを示すブロック図である。更に、図１３Ａ−Ｊに示す実施形態は、コンティンジェント及び非コンティンジェントの両依存性に対して同じ依存性決定メカニズムを使用するものである。従って、説明上、図１３Ａ−Ｊにおける幾つかの例は、非コンティンジェントプロデューサ依存性の例であり、一方、他のものは、コンティンジェントプロデューサ依存性の例である。更に、非コンティンジェントプロデューサ依存性とは、依存性が、独立プロデューサである依存性決定プロデューサに対するものであり（例えば、本発明の一実施形態では、プロデューサ依存性宣言が空であるために依存性形式が識別可能であり）、一方、コンティンジェントのプロデューサ依存性とは、依存性が、従属プロデューサである依存性決定プロデューサに対するものである（例えば、本発明の一実施形態では、プロデューサ依存性宣言が空でないので依存性形式が識別可能である）。
【０１７８】
更に、丸内の番号及び文字は、図１３Ａ−Ｊでは、本発明の一実施形態に基づいてオペレーションが遂行される順序を示す。又、表記Ｘ：：Ｙ：：Ｚは、図１３Ａ−Ｊでは、クラスキー（Ｘ）、インスタンスキー（Ｙ）及びメソッドキー（Ｚ）で形成されるプロデューサキーを表すのに使用される。更に、破線の丸及び矢印付きの線は、本発明のある実施形態では遂行されないオペレーションを表す。特に、所与の依存性に対する独立した依存性決定プロデューサの実行が、常に、同じ依存性（例えば、独立した依存性決定プロデューサ）を返送する場合には、本発明のある実施形態ではそのような依存性決定プロデューサが実行されるが、プロデューサグラフ（１つ又は複数）においてはインスタンス生成もリンクもなされない。
【０１７９】
明示的依存性決定プロデューサ
図１３Ａは、本発明の一実施形態による非ショートカット宣言、非ダイナミック（非コンティンジェント、非サブスクリプション）依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図１３Ｂは、本発明の一実施形態による例示的非ショートカット宣言、非ダイナミック（非コンティンジェント、非サブスクリプション）プロデューサ依存性を示すプロデューサのブロック図である。図１３Ａは、次のものを示す。１）メソッドアルファ１３０５に対するプロデューサ依存性宣言ステートメント１３００、ここで、プロデューサ依存性宣言ステートメント１３００は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡに対するプロデューサ依存性を含む；及び２）メソッドベータ１３１５に対するプロデューサ依存性宣言ステートメント１３１０、ここで、プロデューサ依存性宣言ステートメント１３１０は空であり、且つメソッドベータ１３１５は、クラスＤＥＰのインスタンスを引数として返送する。メソッドベータ１３１５は、プロデューサ依存性宣言コード１３２０を含み、これは、ＤＥＰ．ＴＹＰＥを非サブスクリプション下方宣言にセットし、ＤＥＰ．ＰＲＯＤをプロデューサ１３にセットし、そしてＤＥＰを返送する。
【０１８０】
図１３Ａにおいて、丸１は、プロデューサ依存性宣言１３００がアクセスされることを指示する（例えば、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサとして指定する結果として、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサの子孫として自動的に発見する結果として、等々）。図１３Ｂにおける丸２は、メソッドアルファ１３０５に基づきプロデューサＣ０：:Ｉ０：：ＡＬＰＨＡがインスタンス生成されることを示している。図１３Ａにおける丸３は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡに対するプロデューサ依存性が処理されて、プロデューサ依存性を決定することを指示し、その結果、丸４は、プロデューサ依存性宣言１３１０がアクセスされることを指示する。図１３Ｂにおける破線の丸５は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡが依存性決定プロデューサ１３８０としてインスタンス生成されることを示している。図１３Ｂにおける破線の丸６は、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡがプロデューサグラフにおいてリンクされることを指示し、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡが子プロデューサであることを指示する。図１３Ｂにおける丸７は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡが実行されることを指示し、そしてプロデューサ１３を識別するためにＤＥＰを返送する。丸８は、プロデューサ１３がインスタンス生成されることを指示し、一方、丸９は、プロデューサ１３がプロデューサグラフにおいて子プロデューサとしてプロデューサＣ０：：Ｉ０：：ＡＬＰＨＡへリンクされることを指示する。図１３Ｂにおいて、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡ及びプロデューサ１３は、標準的プロデューサ１３８５である（それらは、依存性決定プロデューサではない）。
【０１８１】
図１３Ｃは、本発明の一実施形態による非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図１３Ｄは、本発明の一実施形態による例示的非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。更に、図１３Ｄは、ず５Ａのプロデューサ５、７Ａ及び７Ｂと、プロデューサ７Ａに対するプロデューサ５のダイナミック依存性の解明とを指す。
【０１８２】
図１３Ｃは、次のものを示している。１）メソッドアルファ１３０５に対するプロデューサ依存性宣言ステートメント１３００、ここで、プロデューサ依存性宣言ステートメント１３００は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡに対するプロデューサ依存性を含み；２）メソッドベータ１３１５に対するプロデューサ依存性宣言ステートメント１３２５、ここで、プロデューサ依存性宣言ステートメント１３２５は、プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡに対するプロデューサ依存性を含み、そしてメソッドベータ１３１５は、クラスＤＥＰのインスタンスを引数として返送し；３）メソッドデルタ１３３４に対するプロデューサ依存性宣言ステートメント１３３２、ここで、プロデューサ依存性宣言ステートメント１３３２は空であり、そしてメソッドデルタ１３３４は、クラスＤＥＰのインスタンスを引数として返送し；及び４）メソッドガンマ１３４０に対するプロデューサ依存性宣言ステートメント１３３８、ここで、プロデューサ依存性宣言ステートメント１３３８は、空であり、そしてメソッドガンマ１３４０は、変数Ｘを返送する（ここで、Ｘは、外部ソースからのもの、デフォールト値（明示的、又はクラスにおける定数）である）。メソッドベータ１３１５は、プロデューサ依存性宣言コード１３３０を含み、これは、ＤＥＰ．ＴＹＰＥを非サブスクリプション下方宣言にセットし、ＤＥＰ．ＰＲＯＤを、プロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡの出力に基づいてプロデューサ７Ａ又は７Ｂにセットし、そしてＤＥＰを返送する。メソッドデルタ１３３２は、プロデューサ依存性宣言コード１３３６を含み、これは、ＤＥＰ．ＴＹＰＥを非サブスクリプション下方宣言にセットし、ＤＥＰ．ＰＲＯＤをプロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡにセットし、そしてＤＥＰ．ＰＲＯＤを返送する。
【０１８３】
図１３Ｃにおいて、丸１は、プロデューサ依存性宣言１３００がアクセスされることを指示する（例えば、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサとして指定する結果として、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサの子孫として自動的に発見する結果として、等々）。図１３Ｄの丸２は、メソッドアルファ１３０５に基づきプロデューサ５がインスタンス生成されることを示している。図１３Ｃの丸３は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡに対するプロデューサ依存性が処理されてプロデューサ依存性を決定することを示し、その結果、丸４は、プロデューサ依存性宣言１３２５がアクセスされることを示している。図１３Ｂの丸５は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡが依存性決定プロデューサ１３８０としてインスタンス生成されることを示している。図１３Ｄの丸６は、プロデューサ５がプロデューサグラフにおいてリンクされることを指示し、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡが子プロデューサであることを指示する。
【０１８４】
図１３Ｃの丸７は、プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡに対するプロデューサ依存性が処理されてプロデューサ依存性を決定することを指示し、その結果、丸８は、プロデューサ依存性宣言１３３２がアクセスされることを指示する。図１３Ｄの破線の丸９は、プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡが依存性決定プロデューサ１３８０としてインスタンス生成されることを示す。図１３Ｄの破線の丸１０は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡがプロデューサグラフにおいてリンクされることを指示し、プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡが子プロデューサであることを指示する。図１３Ｄの丸１１は、プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡが実行され、そしてＣＸ：：ＩＺ：：ＧＡＭＭＡを識別するためにＤＥＰを返送することを指示する。丸１２は、プロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡがインスタンス生成されることを指示し、一方、丸１３は、プロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡがプロデューサグラフにおいてプロデューサＣＷ：：ＩＹ：：ＢＥＴＡに対して子プロデューサとしてリンクされることを指示する。
【０１８５】
図１３Ｄにおいて、丸Ａは、プロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡが実行され、ＸをプロデューサＣＷ：：ＩＹ：：ＢＥＴＡへ返送することを指示し、一方、丸Ｂは、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡがプロデューサ７Ａを識別するためにＤＥＰを返送することを指示し、丸Ｃは、未解明の残部（メソッドベータ）１３９０が今や解明されそしてプロデューサ７Ａがインスタンス生成されることを指示し、一方、丸Ｄは、プロデューサ５をプロデューサ７Ａにリンクすることを指示する。図１３Ｄにおいて、プロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡ、５及び７Ａは、標準的プロデューサ１３８５である。
【０１８６】
オンザフライの依存性決定プロデューサ
図１３Ｅは、本発明の一実施形態による非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性の両方を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図１３Ｆは、本発明の一実施形態による非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。図１３Ｄと同様に、図１３Ｆは、図５Ａのプロデューサ５、７Ａ及び７Ｂと、プロデューサ７Ａに対するプロデューサ５のダイナミック依存性の解明とを指す。
【０１８７】
図１３Ｅ−Ｆは、次のことを除いて、図１３Ｃ−Ｄと同じである。１）プロデューサ依存性宣言ステートメント１３４２がプロデューサ依存性宣言ステートメント１３２５に置き換わり；２）メソッドフライ(fly)１３４４がメソッドデルタ１３３４に置き換わり；及び３）プロデューサＣＷ：：ＩＹ：：ＦＬＹがプロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡに置き換わる。プロデューサ依存性宣言ステートメント１３４２は、ＣＸ：：ＩＺ：：ＧＡＭＭＡに対するショートカット宣言プロデューサ依存性を含む。従って、図１３Ｅの丸４は、今度は、プロデューサ依存性宣言１３４２がアクセスされることを指示する。図１３Ｅの丸７は、今度は、プロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡに対するショートカット宣言プロデューサ依存性が処理されてプロデューサ依存性を決定し、その結果、ランタイムがメソッドフライ１３４４に基づいてオンザフライで依存性決定プロデューサＣＷ：：ＩＹ：：ＦＬＹをインボークすることを指示する。丸８は、今度は、プロデューサ依存性宣言１３３２がアクセスされることを指示する。図１３Ｆの破線の丸９は、今度は、プロデューサＣＷ：：ＩＹ：：ＦＬＹがインスタンス生成されることを示す。図１３Ｆの破線の丸１０は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡがプロデューサグラフにおいてリンクされることを指示し、プロデューサＣＷ：：ＩＹ：：ＦＬＹが子プロデューサであることを指示する。図１３Ｆの丸１１は、プロデューサＣＷ：：ＩＹ：：ＦＬＹが実行されそしてＣＸ：：ＩＺ：：ＧＡＭＭＡを識別するためにＤＥＰを返送することを指示する。図１３Ｅ−Ｆの残り部分は、図１３Ｃ−Ｄと同じである。
【０１８８】
依存性決定プロデューサＣＷ：：ＩＹ：：ＦＬＹのランタイムによるオンザフライ発生は、アプリケーションプログラマーが、明示的プロデューサ依存性宣言コードを書き込みそしてそれに基づいて依存性決定プロデューサをインスタンス生成しなければならないことから軽減する。更に、アプリケーションプログラマーが、依存性決定プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡを指定するのではなく、メソッドベータ１３１５に対するプロデューサ依存性宣言ステートメントにおいてプロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡに対する依存性を直接指定することを許す。
【０１８９】
ショートカット技術は、種々の状況において使用することができ、更に、種々のフォーマットを有してもよい。例えば、図１３Ｅ−Ｆにおいて、ショートカット宣言依存性は、非コンティンジェント依存性に対するものであり（子プロデューサを直接識別し）、そして依存性決定プロデューサのベースとなるメソッドに対するプロデューサ依存性宣言ステートメント内にあるが、他の状況及びフォーマットは、次のように示される。１）図１３Ｇ−Ｈは、２つのショートカットの使用を示し、その一方は、コンティンジェントなもので、標準的なプロデューサのベースとなるメソッドに対するプロデューサ依存性宣言ステートメントの一部分であり、そしてその他方は、非コンティンジェントなもので、依存性決定プロデューサのベースとなるメソッドに対するプロデューサ依存性宣言ステートメントの一部分であり；そして２）図１３Ｉ−Ｊは、非コンティンジェントなショートカットであって、標準的プロデューサのベースとなるメソッドに対するプロデューサ依存性宣言ステートメント内にあるショートカットの使用を示す。
【０１９０】
図１３Ｇは、本発明の一実施形態によるショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、非コンティンジェント、非サブスクリプションのプロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図１３Ｈは、本発明の一実施形態による例示的ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、非コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。図１３Ｇは、次のものを示す。１）メソッドアルファ１３０５に対するプロデューサ依存性宣言ステートメント１３４５、ここで、プロデューサ依存性宣言ステートメント１３４５は、プロデューサ＜Ｐ＞ＧＥＴＣ１：：Ｉ１：：Ｍ１に対するショートカット宣言、コンティンジェントのプロデューサ依存性を含み；２）メソッドフライ１  １３５５に対するプロデューサ依存性宣言ステートメント１３５０、ここで、プロデューサ依存性宣言ステートメント１３５０は、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１に対するショートカット宣言、非コンティンジェントのプロデューサ依存性を含み、且つメソッドフライ１  １３５５は、ＤＥＰのインスタンスを引数として返送し；３）メソッドフライ２  １３６２に対するプロデューサ依存性宣言ステートメント１３２２、ここで、メソッドフライ２  １３６２は、ＤＥＰのインスタンスを引数として返送し；及び４）メソッドｇｅｔｃ１  １３７０に対するプロデューサ依存性宣言ステートメント１３６５、ここで、メソッドｇｅｔｃ１  １３７０は、ＣＸ又はＣＹの値と共にＣ１を返送する。
【０１９１】
メソッドＦＬＹ１  １３５５及びそのプロデューサ依存性宣言ステートメント１３５０は、ショートカット宣言依存性＜Ｐ＞ＧＥＴＣ１：：Ｉ１：：Ｍ１（これは、クラスキーに対してショートカットが使用されることを指示する）に応答して、ランタイムにより与えられる。メソッドフライ１  １３５５は、プロデューサ依存性宣言コード１３６０を含み、これは、ＤＥＰ．ＴＹＰＥを非サブスクリプション下方宣言にセットし、ＤＥＰ．ＰＲＯＤを、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１により出力されるＣ１の値に基づいてプロデューサＣＸ：：Ｉ１：：Ｍ１又はＣＹ：：Ｉ１：：Ｍ１にセットし、そしてＤＥＰを返送する。図１３Ｈの例において、＜Ｐ＞は、コンティンジェントであるプロデューサのクラスキーであることを示すのに使用されるが、本発明の別の実施形態では、他のシンタックスを使用することもできる。更に、図１３Ｈの例では、＜Ｐ＞は、コンティンジェントであるプロデューサのクラスキーであることを示すのに使用されるが、本発明の一実施形態は、このようにコンティンジェントとして指示されるプロデューサキーを作り上げるより多くの及び／又は異なる識別子をもつこともサポートする。
【０１９２】
図１３Ｇにおいて、丸１は、プロデューサ依存性宣言１３４５がアクセスされることを指示する（例えば、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサとして指定する結果として、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサの子孫として自動的に発見する結果として、等々）。図１３Ｈにおける丸２は、メソッドアルファ１３０５に基づきプロデューサＣ０：:Ｉ０：：ＡＬＰＨＡがインスタンス生成されることを示している。図１３Ｇにおける丸３は、ショートカット宣言プロデューサ依存性が処理されて、プロデューサ依存性を決定することを指示し、その結果、丸４は、プロデューサ依存性宣言１３５０がアクセスされることを指示する。
【０１９３】
図１３Ｈの丸５は、プロデューサＣ０：：Ｉ０：：ＦＬＹ１が依存性決定プロデューサ１３８０としてインスタンス生成されることを示している。図１３Ｈの丸６は、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡがプロデューサグラフにおいてリンクされることを指示し、プロデューサＣ０：:Ｉ０：：ＦＬＹ１が子プロデューサであることを指示する。図１３Ｇの丸７は、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１に対するショートカット宣言プロデューサ依存性が処理されてプロデューサ依存性を決定し、そしてランタイムがメソッドフライ２  １３６２を与えることを指示し、その結果、丸８は、プロデューサ依存性宣言１３３２がアクセスされることを指示する。図１３Ｈの破線の丸９は、プロデューサＣ０：：Ｉ０：：ＦＬＹ２がインスタンス生成されることを示す。図１３Ｈの破線の丸１０は、プロデューサＣ０：：Ｉ０：：ＦＬＹ１がプロデューサグラフにおいてリンクされることを指示し、プロデューサＣ０：：Ｉ０：：ＦＬＹ２が子プロデューサであることを指示する。
【０１９４】
図１３Ｈの丸１１は、プロデューサＣ０：：Ｉ０：：ＦＬＹ２が実行され、そしてプロデューサＣ０：：Ｉ０：：ＧＥＴＣ１を識別するためにＤＥＰを返送することを指示する。丸１２は、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１がインスタンス生成されることを指示し、一方、丸１３は、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１がプロデューサグラフにおいて子プロデューサとしてプロデューサＣ０：：Ｉ０：：ＦＬＹ１にリンクされることを指示する。
【０１９５】
図１３Ｈにおいて、丸Ａは、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１が実行され、そしてＣ１＝ＣＸをプロデューサＣ０：：Ｉ０：：ＦＬＹ１へ返送することを指示し、一方、丸Ｂは、プロデューサＣ０：：Ｉ０：：ＦＬＹ１が実行され、そしてプロデューサＣＸ：：Ｉ１：：Ｍ１を識別するためにＤＥＰを返送することを指示し、又、丸Ｃは、未解明の残部（メソッドフライ１）１３９０が今や解明されたことを指示し、そして丸Ｄは、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡをプロデューサＣＸ：：Ｉ１：：Ｍ１にリンクすることを指示する。図１３Ｈにおいて、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１、Ｃ０：：Ｉ０：：ＡＬＰＨＡ、及びＣＸ：：Ｉ１：：Ｍ１は、標準的プロデューサ１３８５である。
【０１９６】
依存性決定プロデューサＣ０：：Ｉ０：：ＦＬＹ１及びＣ０：：Ｉ０：：ＦＬＹ２のランタイムによるオンザフライ発生は、アプリケーションプログラマーが、明示的プロデューサ依存性宣言コードを書き込みそしてそれに基づいて依存性決定プロデューサをインスタンス生成しなければならないことから軽減する。更に、アプリケーションプログラマーが、依存性決定プロデューサＣＷ：：ＩＹ：：ＢＥＴＡを指定するのではなく、メソッドアルファ１３０５に対するプロデューサ依存性宣言ステートメントにおいてメソッドｇｅｔＣ１を通してプロデューサ＊＊：：Ｉ１：：Ｍ１に対するコンティンジェント依存性を直接指定することを許す。
【０１９７】
図１３Ｉは、本発明の一実施形態によるショートカット宣言、非ダイナミック（非コンティンジェント、非サブスクリプション）プロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図１３Ｊは、本発明の一実施形態による例示的ショートカット宣言、非ダイナミックプロデューサ依存性を示すプロデューサのブロック図である。図１３Ｉは、次のものを示す。１）メソッドアルファ１３０５に対するプロデューサ依存性宣言ステートメント１３７２、ここで、プロデューサ依存性宣言ステートメント１３７２は、プロデューサ１０に対するショートカット宣言プロデューサ依存性を含み；及び２）メソッドフライ１３７６に対するプロデューサ依存性宣言ステートメント１３７４、ここで、プロデューサ依存性宣言ステートメント１３７４は、空であり、そしてメソッドフライ１３７６は、ＤＥＰのインスタンスを引数として返送する。メソッドフライ１７７６及びそのプロデューサ依存性宣言ステートメント１３７４は、ショートカット宣言依存性に応答してランタイムにより与えられる。メソッドフライ１３７６は、プロデューサ依存性宣言コード１３７８を含み、これは、ＤＥＰ．ＴＹＰＥを非サブスクリプション下方宣言にセットし、ＤＥＰ．ＰＲＯＤをプロデューサ１０にセットし、そしてＤＥＰを返送する。
【０１９８】
図１３Ｉにおいて、丸１は、プロデューサ依存性宣言１３７２がアクセスされることを指示する（例えば、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサとして指定する結果として、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサの子孫として自動的に発見する結果として、等々）。図１３Ｊの丸２は、メソッドアルファ１３０５に基づきプロデューサＣ０：:Ｉ０：：ＡＬＰＨＡがインスタンス生成されることを示している。図１３Ｉの丸３は、ショートカット宣言プロデューサ依存性が処理されてプロデューサ依存性を決定し、そしてランタイムがメソッドフライ１３７６を与えることを指示し、その結果、丸４は、プロデューサ依存性宣言１３７４がアクセスされることを指示する。図１３Ｊの破線の丸５は、プロデューサＣ０：：Ｉ０：：ＦＬＹが依存性決定プロデューサ１３８０としてインスタンス生成されることを示す。図１３Ｊの破線の丸６は、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡがプロデューサグラフにおいてリンクされることを指示し、プロデューサＣ０：：Ｉ０：：ＦＬＹ１が子プロデューサであることを指示する。
【０１９９】
図１３Ｊの丸７は、プロデューサＣ０：：Ｉ０：：ＦＬＹ１が実行され、そしてプロデューサ１０を識別するためにＤＥＰを返送することを指示する。丸８は、プロデューサ１０がインスタンス生成されることを指示し、一方、丸９は、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡがプロデューサグラフにおいてリンクされることを指示し、プロデューサ１０が子プロデューサであることを指示する。図１３Ｊにおいて、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡ及びプロデューサ１０は、標準的プロデューサ１３８５である。
【０２００】
ランタイムプログラマーは、本発明の一実施形態において、サポートされる全てのシンタックス及び組合せ（例えば、メソッドフライ１３３４、メソッドフライ１  １３５５、メソッドフライ２  １３６２、メソッドフライ１３７６）を解釈するために単一フライメソッドを書き込み、そしてそれをランタイムに含ませることを理解されたい。これは、アプリケーションプログラマーが、フライメソッドが使用される依存性決定プロデューサに対してコードの書き込みを回避できるだけでなく、ランタイムプログラマーは、一般的なフライメソッド（サポートされる全ての状況に対する単一フライ）を一度書き込むだけでよい。更に、ショートカット宣言依存性は、依存性決定プロデューサを使用するランタイムを許すと同時に、アプリケーションプログラマーがプロデューサ依存性宣言において標準的プロデューサを指示するのを許すことも理解されたい（例えば、図１３Ｇ−Ｊ）。
【０２０１】
メソッド追跡構造
図１１Ｄのメソッド追跡構造に戻って、ArgumentDependencies列１１９４、FieldDependencies列１１９６、SequencingDependencies列１１９５、UpwardDependencies列１１９３、及びWeaklyConstrainedDependencies列１１９９の例示的コンテンツについて以下に説明する。より詳細には、ArgumentDependencies列１１９４は、各ArgumentDependenciesに１つづつあるアイテムの集合を記憶する。本発明の一実施形態では、各アイテムは、次のものを含む。１）引数ＩＤ；２）明示的クラス、同じクラス、及びコンティンジェントクラスの１つであるクラスキーネイチャー識別子；３）クラスキーネイチャー識別子が明示的クラスを指示するときにポピュレートされる明示的クラスキー識別子；４）クラスキーネイチャー識別子がコンティンジェントクラスを指示するときにポピュレートされるコンティンジェントクラス決定メソッドキー識別子；５）明示的インスタンス、同じインスタンス、及びコンティンジェントインスタンスの１つであるインスタンスキーネイチャー識別子；６）インスタンスキーネイチャー識別子が明示的インスタンスを指示するときにポピュレートされる明示的インスタンスキー識別子；７）インスタンスキーネイチャー識別子がコンティンジェントインスタンスを指示するときにポピュレートされるコンティンジェントインスタンス決定メソッドキー識別子；８）明示的メソッド、同じメソッド、及びコンティンジェントメソッドの１つであるメソッドキーネイチャー識別子；９）メソッドキーネイチャー識別子が明示的メソッドを指示するときにポピュレートされる明示的メソッドキー識別子；１０）メソッドキーネイチャー識別子がコンティンジェントメソッドを指示するときにポピュレートされるコンティンジェントメソッド決定メソッドキー識別子；及び１１）プロデューサ依存性宣言ステートメントの引数に対するプロデューサ依存性宣言がショートカットの指示を含むかどうか指示するショートカット識別子（即ち、プロデューサ依存性宣言ステートメントは、依存性決定プロデューサではなく、標準的な子プロデューサを直接識別する）。
【０２０２】
種々のキーネイチャー識別子の「・・・明示的」指示は、プロデューサ依存性宣言ステートメントにおいてプロデューサ依存性に対して明示的キーが設けられる場合に使用される。例えば、図１３Ａのプロデューサ依存性宣言ステートメント１３００のプロデューサ依存性「ＣＷ：：ＩＹ：：ＢＥＴＡ」は、明示的クラス、インスタンス及びメソッドキーを与える。
【０２０３】
本発明の幾つかの実刑形態では、プロデューサ依存性宣言ステートメントに対してショートハンド(shorthand)技術が次のようにサポートされる。１）所与のプロデューサ依存性に対してクラスが設けられない場合には、親プロデューサと同じクラスが使用され；及び２）所与のプロデューサ依存性に対してクラス及びインスタンスが設けられない場合には、親プロデューサと同じクラス及びインスタンスが使用される。本発明の他の実施形態では、クラス、インスタンス及びメソッドの組合せを親と同じにする（全部が同じであることを除いて）のを許すためにシンタックスが使用される（例えば、クラス、インスタンス及びメソッドの各々を指定するのにセパレータが使用され、このようなセパレータがないと、親と同じであることを指示し、特定例によれば、シンタックスは、“＃Ｃ：”、“＃Ｉ”及び“＃Ｍ：”であり、プロデューサ依存性宣言ステートメントにおけるプロデューサ依存性は、＃Ｃ：”クラスキー”：：＃Ｉ：”インスタンスキー”：：＃Ｍ：”メソッドキー”となる）（引用符は、値又は変数のプレースホルダーを示す）。このショートハンド技術がプロデューサ依存性宣言ステートメントに使用される場合には、種々のキーネイチャー識別子の「・・・同じ」指示が使用される。
【０２０４】
上述したように、本発明のある実施形態では、コンティンジェントプロデューサ依存性の指示は、プロデューサ依存性宣言ステートメントそれ自体に使用されるシンタックス（例えば、＜Ｐ＞）を通してサポートされ（図１３Ｇの１３４５を参照）、そしてこのようなシンタックスは、プロデューサ依存性のクラス、インスタンス及びメソッドの１つ以上に使用することができる。種々のキーネイチャー識別子の「・・・コンティンジェント」指示は、このようなコンティンジェントプロデューサ依存性がいつ生じるか識別するのに使用され、一方、「コンティンジェント・・・決定メソッドキー識別子」は、子プロデューサのメソッドキーを指示する（クラス及びインスタンスは、親プロデューサのものと同じである）。例えば、図１３Ｇのプロデューサ依存性宣言１３４５に対するプロデューサ依存性“＜Ｐ＞ＧＥＴＣ１：：Ｉ１：：Ｍ１”は、コンティンジェントクラス（コンティンジェントクラス決定メソッドキーがＧＥＴＣ１である場合）、明示的インスタンスキー、及び明示的メソッドキーを与える。
【０２０５】
SequencingDependencies列１１９５、UpwardDependencies列１１９３、及びWeaklyConstrainedDependencies列１１９５の各々は、SequencingDependencies、UpwardDependencies及びWeaklyConstrainedDependenciesの各々に１つづつの、アイテムの集合を記憶する。本発明の一実施形態では、このような各アイテムは、引数ＩＤを含まないことを除いて、ArgumentDependenciesに対する集合のアイテムと同じ構造を有する。更に、図１３Ａ−Ｊは、依存性決定プロデューサから生じる非サブスクリプション下方宣言依存性を示しているが、上方宣言依存性又は弱い制約の依存性の場合には、依存性決定プロデューサは、図７Ｆ−Ｇを参照して述べた他の依存性を返送することができる。
【０２０６】
FieldDependencies列１１９６は、各FieldDependencyに１つづつあるアイテムの集合を記憶する。本発明の一実施形態では、各アイテムは、プロパティメソッドキーを含むが、本発明の別の実施形態では、SequencingDependenciesからの集合のアイテムと同じ構造を有してもよい。
【０２０７】
サブスクリプション依存性
本発明の一実施形態において、非サブスクリプション及びサブスクリプションの両プロデューサ依存性がサポートされる。所与のメソッドに対してサブスクリプションプロデューサ依存性が宣言され、且つその所与のメソッドから所与のプロデューサがインスタンス生成されるときには、ランタイムは、サブスクリプションの基準を満足する０以上のプロデューサのセットを（他のプロデューサの存在に基づいて）ランタイム中に解明することができる。本発明の一実施形態は、非サブスクリプション及びサブスクリプションの両プロデューサ依存性をサポートするが、別の実施形態は、非サブスクリプションしかサポートしない。更に、本発明の一実施形態では、２つの形式のサブスクリプション依存性（アブソービング及びスティッキー）がサポートされるが、本発明の別の実施形態は、それより多い、それより少ない、及び／又は異なる形式のサブスクリプションプロデューサ依存性をサポートする。
【０２０８】
図１４Ａ−Ｃは、本発明の一実施形態によるアブソービング及びスティッキーサブスクリプションを示すブロック図である。図１４Ａは、本発明の一実施形態による図１２のサブスクリプションログ１２５０の一例を示すブロック図である。図１４Ａは、このログ構造をテーブルとして示しているが、いかなる適当なデータ構造（例えば、ハッシュマップ）が使用されてもよいことを理解されたい。図１４Ｂは、本発明の一実施形態による非コンティンジェント、アブソーブサブスクリプションプロデューサ依存性を示す例示的プロデューサのブロック図である。図１４Ｃは、本発明の一実施形態による非コンティンジェント、スティッキーサブスクリプションプロデューサ依存性を示す例示的プロデューサのブロック図である。図１４Ａのテーブルの２つの行は、図１４Ｂ−Ｃの例で使用されるコンテンツがポピュレートされて示されている。丸付き番号は、図１４Ｂ−Ｃでは、本発明の一実施形態によりオペレーションが遂行される順序を示すのに使用される。
【０２０９】
図１４Ａにおいて、サブスクライバープロデューサキー列１４００、サブスクリプション形式列１４０５、及びトリガープロデューサ用サブスクリプション基準列１４１０が、各々、列の名前に対応するコンテンツを記憶するように示されている。更に、図１４Ａは、サブスクリプション依存性の親プロデューサに対するリンクモードを記憶するための親リンクモード列１４２５も示しており、この情報は、図１４Ｂ−Ｃを参照して詳細に説明する。
【０２１０】
又、図１４Ａは、アブソービングサブスクリプションに使用されるマッチングプロデューサ列１４１５及び完了列１４２０も示している。マッチングプロデューサ列１４１５は、アブソービングサブスクリプションのサブスクリプション基準を満足するトリガープロデューサのプロデューサキーを記憶するのに使用され、一方、完了列１４２０は、プロデューサグラフの現在セットの所与の実行中にアブソービングサブスクリプションが完了したかどうか追跡するのに使用される。マッチングプロデューサ列１４１５及び完了列１４２０は、インスタンス生成されたプロデューサをスキャンする作業を、以下に述べる自動プロデューサグラフ発生とプロデューサグラフ実行との間で分割できるようにする付加的な任意の最適化を与える。
【０２１１】
又、図１４Ａは、スティッキーサブスクリプションに使用される親クラス列１４３０、親メソッド列１４３５、及び親インスタンス列１４３７も示している。これら親クラス列１４３０、親メソッド列１４３５、及び親インスタンス列１４３７は、各々、スティッキーサブスクリプションに対して生成されるべき親プロデューサのクラスキー、メソッドキー、及びインスタンスキーを記憶する。更に、図１４Ａは、サブスクリプションを生成する依存性決定プロデューサに対するリファレンスを記憶する依存性決定プロデューサリファレンス列１４２１も示している。
【０２１２】
アブソービングサブスクリプション
アブソービングサブスクリプションプロデューサ依存性において、依存性は、アブソービングサブスクリプション基準を満足する現在プロデューサグラフ（１つ又は複数）構造の全プロデューサの集合に対するものである。図１４Ｂを参照すれば、丸１は、プロデューサ１４５０がインスタンス生成される（例えば、プロデューサ１４５０を、問題とするプロデューサとして指定する結果として、プロデューサ１４５０を、問題とするプロデューサの子孫として自動的に発見する結果として、等々）ことを指示する。プロデューサ１４５０は、プロデューサ依存性宣言がプロデューサ依存性を含む（例えば、引数ＩＤ  Ｘと共に）ところのメソッドに基づく。丸２は、プロデューサ１４５０のプロデューサ依存性がプロデューサ１４５５を識別するように処理されることを指示する。
【０２１３】
丸３は、プロデューサ１４５０がプロデューサグラフにおいてプロデューサ１４５５へ子プロデューサとして（上記例では、引数ＩＤ  Ｘを通して）リンクされることを指示する。丸４は、プロデューサ１４５５の実行を指示する。プロデューサ１４５５は、アブソービングサブスクリプションプロデューサ依存性を指示すると共にアブソービングサブスクリプション基準を指示するプロデューサ依存性宣言コードを含む依存性決定プロデューサである。従って、プロデューサ１４５５の実行は、サブスクリプションログのポピュレーションを生じさせる。図１４Ａの第１行における例に関して、サブスクライバープロデューサキー列１４００、サブスクリプション形式列１４０５、トリガープロデューサ用サブスクリプション基準列１４１０、親リンクモード列１４２５、及び依存性決定プロデューサリファレンス列１４２１には、各々、プロデューサ１４５０のプロデューサキー、サブスクリプションがアブソービング形式のものであるという指示、プロデューサ１４５５内に含まれたアブソービングサブスクリプション基準、プロデューサ１４５５にリンクされたプロデューサ１４５０のリンクモード（これは、アブソービングサブスクリプションの場合には、引数依存性であり、引数ＩＤを含むが、そのスティッキーインジケータは、スティッキーでないものを指示し、前記の例では、引数ＩＤ  Ｘを指示する）、及びプロデューサ１４５５（サブスクリプションを生成する依存性決定プロデューサ）に対するリファレンスがポピュレートされる。
【０２１４】
丸５Ａ−Ｎは、プロデューサ１４６０Ａ−Ｎのインスタンス生成を指示する。この例では、プロデューサ１４６０Ａ−Ｎは、アブソービングサブスクリプション基準を満足し、従って、トリガープロデューサである。従って、丸６Ａ−Ｎは、プロデューサ１４５０をプロデューサ１４６０Ａ−Ｎにリンクする（前記例では、引数ＩＤ  Ｘを通して）ことを指示する。丸７は、プロデューサグラフ（１つ又は複数）の現在実行に対してアブソービングサブスクリプション依存性が完了したことを指示し、次いで、プロデューサ１４５０が実行される。
【０２１５】
本発明の一実施形態では、アブソービングサブスクリプション基準は、プロデューサキーを作り上げるキーのいずれか１つ以上である。従って、プロデューサキーが、クラスキー、インスタンスキー、及びメソッドキーを含む本発明の実施形態では、サブスクリプション基準は、１つ以上のそのようなキーである。例えば、図１１Ｃを参照すれば、サブスクリプション基準を満足するものについてのインスタンス生成されたプロデューサを通るスキャンは、インスタンス生成されたプロデューサのキーがアブソービングサブスクリプション基準のキーに一致するかどうか決定するための、プロデューサグラフ構造の最初の３列の１つ以上を通るスキャンである。本発明の一実施形態では、アブソービングサブスクリプション基準は、プロデューサキーを作り上げるキーのいずれか１つ以上であるが、本発明の別の実施形態では、アブソービングサブスクリプション基準は、プロデューサを作り上げるキーのサブセットに制限される。
【０２１６】
スティッキーサブスクリプション
スティッキーサブスクリプションプロデューサ依存性において、この依存性は、スティッキーサブスクリプション基準を満足するプロデューサごとに親プロデューサをインスタンス生成させる。図１４Ｃを参照すれば、丸１は、プロデューサ１４７０がインスタンス生成されることを指示する（例えば、プロデューサ１４７０を、問題とするプロデューサとして指定する結果として、プロデューサ１４７０を、シーケンス依存性を通して問題とするプロデューサの子孫として自動的に発見する結果として（例えば、SequencingDependency又はWeaklyConstrainedDependencyの結果として、等々）。プロデューサ１４７０は、スティッキーサブスクリプション、トリガープロデューサのためのスティッキーサブスクリプション基準、及び生成されるべき親プロデューサのためのスティッキーサブスクリプション特性を指示するプロデューサ依存性宣言コードを含む依存性決定プロデューサである。
【０２１７】
プロデューサ１４７０の実行は、サブスクリプションログのポピュレーションを生じさせる。図１４Ａの第２行における例に関して、サブスクライバープロデューサキー列１４００、サブスクリプション形式列１４０５、及びトリガープロデューサ用サブスクリプション基準列１４１０には、各々、プロデューサ１４７０のプロデューサキー、サブスクリプションがスティッキー形式のものであるという指示、及びプロデューサ１４７０内に含まれるトリガープロデューサに対するスティッキーサブスクリプション基準がポピュレートされる。更に、トリガープロデューサにリンクされるべき親プロデューサの親クラス列１４３０、親メソッド列１４３５、親インスタンス列１４３７、及びリンクモード列１４２５には、生成されるべき親プロデューサに対するスティッキーサブスクリプション特性がポピュレートされ、即ち、本発明のこの実施形態では、インスタンス生成されるべき親プロデューサのクラス、インスタンス生成されるべき親プロデューサのメソッド、インスタンス生成されるべき親プロデューサのインスタンス（ブランクのままにされた場合は、トリガープロデューサのインスタンスキーに等しい）、リンクモード（これは、スティッキーサブスクリプションの場合には、１）引数、フィールド又はシーケンス依存性；２）引数依存性の場合の引数ＩＤ、即ちトリガープロデューサにリンクされるべき親プロデューサの引数ＩＤ（例えば、引数ＩＤ  Ｙ））がポピュレートされる。更に、依存性決定プロデューサリファレンス列１４２１には、サブスクリプションを生成した依存性決定プロデューサ（図１４Ｃでは、プロデューサ１４７０）に対するリファレンスがポピュレートされる。
【０２１８】
図１４Ｃを参照すれば、丸２は、プロデューサ１４７５がインスタンス生成されることを指示する（例えば、プロデューサ１４７５を、問題とするプロデューサとして指定する結果として、プロデューサ１４７５を、問題とするプロデューサの子孫として自動的に発見する結果として、等々）。更に、プロデューサ１４７５がトリガープロデューサに対するスティッキーサブスクリプション基準を満足するかどうか決定される。丸３は、トリガープロデューサ１４７５に応答して、プロデューサ１４８０が、生成されるべき親プロデューサに対するスティッキーサブスクリプション特性に基づいてインスタンス生成されることを指示する。図１４Ｃの例示的な第２行を参照すれば、クラスキー、メソッドキー、インスタンスキー、及びリンクモードは、親クラス列１４３０、親メソッド列１４３５、インスタンス列１４３７、及び親リンクモード列１４２５から各々アクセスされる。親プロデューサは、アクセスされたクラスキー、アクセスされたインスタンスキー（ブランクのままにした場合は、トリガープロデューサ（図１４Ｃでは、プロデューサ１４７５）のインスタンスキー）、及びアクセスされたメソッドキーより成るプロデューサキーを有し、即ち図１４Ｃの例では、これは、プロデューサ１４８０である。丸４は、インスタンス生成された親プロデューサ１４８０が、プロデューサグラフにおいて、アクセスされたリンクモード（前記例では、リンクモード形式＝引数依存性；リンクモード引数ＩＤ＝Ｙ）を通して子のトリガープロデューサ１４７５にリンクされることを指示する。又、丸４において、引数依存性の場合に、スティッキーインジケータは、スティッキーであることを指示するようにセットされ、即ちインスタンス生成された親プロデューサ１４８０のベースとなるメソッドに対するプロデューサ依存性宣言ステートメントの位置におけるプロデューサ依存性を、プロデューサ１４８０に対して無視しなければならないことを指示するようにセットされ、これは、スティッキーサブスクリプションプロデューサ依存性により生成されるリンクが、その後の自動プロデューサグラフ発生オペレーションにより上書きされることを防止する。
【０２１９】
本発明の一実施形態では、トリガープロデューサに対するスティッキーサブスクリプション基準は、プロデューサキーを作り上げるキーの１つ以上である。従って、プロデューサキーが、クラスキー、インスタンスキー及びメソッドキーより成る実施形態では、トリガーに対するスティッキーサブスクリプション基準は、クラス、インスタンス及びメソッドキーの１つ以上である。例えば、図１１Ｃを参照すれば、トリガープロデューサに対するスティッキーサブスクリプション基準を満足するものについてのインスタンス生成されたプロデューサを通るスキャンは、インスタンス生成されたプロデューサのキーがトリガープロデューサに対するスティッキーサブスクリプション基準のキーに一致するかどうか決定するための、プロデューサグラフ（１つ又は複数）構造の第１列−第３列の１つ以上を通るスキャンである。本発明の一実施形態では、トリガープロデューサに対するスティッキーサブスクリプション基準は、プロデューサキーを作り上げるキーの１つ以上であるが、本発明の別の実施形態では、アブソービングサブスクリプション基準は、プロデューサを作り上げるより限定された数のキーである。
【０２２０】
図１４Ｄ−Ｅは、本発明の一実施形態による親依存性決定プロデューサに基づく親プロデューサの選択を示す。図１４Ｄ−Ｅは、引数依存性について説明するが、本発明の実施形態は、シーケンス及びフィールド依存性の使用もサポートできる。
【０２２１】
図１４Ｄは、本発明の一実施形態により、スティッキーサブスクリプションにより生成される親依存性決定プロデューサに基づく親プロデューサの選択を示す。図１４Ｃと同様に、図１４Ｄは、スティッキーサブスクリプションプロデューサ１４７０及びトリガープロデューサ１４７５を示しているが、プロデューサ１４８０ではなく、図１４Ｄは、スティッキーサブスクリプションプロデューサ１４７０のスティッキーサブスクリプションを通して生成された依存性決定プロデューサ１４８０を示している。更に、図１４Ｄは、スティッキーサブスクリプションのリンクモードが、引数依存性、引数ＩＤ＝Ｘ、及びスティッキーインジケータ＝スティッキーであることも示している。プロデューサ１４７５から依存性決定プロデューサ１４８０への破線の曲線で示されたように、依存性決定プロデューサにより返送されるＤＥＰは、プロデューサ１４７５それ自体の出力（引数ＩＤ＝Ｘの引数）に基づくものである。図１４Ｄにおいて、依存性決定プロデューサ１４８０は、プロデューサ１４８２に対する非サブスクリプション上方宣言プロデューサ依存性を、引数依存性及び引数ＩＤ＝Ｙを指示するリンクモードと共に返送する。図１４ＤではＸ及びＹの引数ＩＤを使用して、それらが異なることを示すが、それらが等しくてもよいことを理解されたい。
【０２２２】
図１４Ｅは、本発明の一実施形態により、シーケンス依存性によりリンクされる子依存性決定プロデューサによって生成される親依存性決定プロデューサに基づく親プロデューサの選択を示す。図１４Ｅは、図１４Ｄと構造が類似し、より詳細には、プロデューサ１４７５、１４８０及び１４８２が、プロデューサ１４８６、１４９６及び１４９８に置き換えられる。しかしながら、プロデューサ１４８０と１４７５との間にリンクを生成するスティッキーサブスクリプションプロデューサ１４７０ではなく、プロデューサ１４８６は、依存性決定プロデューサ１４９４に対するシーケンス依存性（例えば、UpwardDependency又はWeaklyConstrainedDependencyを通して生成された）を有し、これは、非サブスクリプション上方宣言依存性を通して依存性決定プロデューサ１４９６を生成する。
【０２２３】
スティッキーサブスクリプション及び非サブスクリプション上方宣言依存性（例えば、UpwardDependencies及び／又はWeaklyConstrainedDependenciesを通して生成される）は、プロデューサグラフのボトムアップ構築を生じさせる（先に述べたトップダウン構築ではなく）ことに注意する価値がある。更に、このボトムアップ構築は、単一レベルの構築に制限されず、複数のレベルでもよい（例えば、スティッキーサブスクリプション又は非サブスクリプション上方宣言依存性のために、親プロデューサがインスタンス生成される場合には、その同じ親プロデューサがスティッキーサブスクリプションのためのトリガープロデューサであってもよいし、又は非サブスクリプション上方宣言依存性を含み、別の親プロデューサのインスタンス生成を生じさせ、等々でもよい）。この意味で、スティッキーサブスクリプション及び非サブスクリプション上方宣言依存性は、プロデューサグラフの構築を逆転する。
【０２２４】
本発明の幾つかの実施形態において、スティッキーサブスクリプション特性により識別される親プロデューサは、標準プロデューサであるが（図１４Ｃを参照）、別の実施形態は、他の形式のプロデューサの識別をサポートするように具現化されてもよい。例えば、依存性決定プロデューサを識別するスティッキーサブスクリプション特性を許す本発明の実施形態では（図１４Ｄを参照）、そのような依存性決定プロデューサは、トリガープロデューサの出力にアクセスし、そしてその出力に基づき、子プロデューサにくっつく必要のある親プロデューサとしての特定プロデューサの生成をトリガーすることができる（この親プロデューサは、予め存在してもしなくてもよく、予め存在する場合には、それが単にリンクされそして子プロデューサがその引数に追加されるが、存在しない場合には、それがクリアされる）。依存性決定プロデューサが一定プロデューサを返送するケースは、アブソービングサブスクリプションに類似している。依存性決定プロデューサが、トリガープロデューサごとにインスタンスキーが独特であるプロデューサを返送する（例えば、インスタンスキーがトリガープロデューサのプロデューサキーであるプロデューサを返送する）ケースは、子プロデューサごとに個別の親プロデューサを生じ、純粋なスティッキーサブスクリプションと称される。依存性決定プロデューサが、トリガープロデューサごとに一定でも独特でもないインスタンスキーを返送するケースは、純粋なスティッキーサブスクリプション及びアブソービングサブスクリプションの振舞いを混合することができ、非純粋のスティッキーサブスクリプションと称される。
【０２２５】
例示的な効果
上述したように、本発明の一実施形態では、プロデューサ依存性は、手動インボケーションシーケンスコードを使用せずに、適切なインスタンスを使用してメソッドインボケーションシーケンスを指定する仕方としてメソッドに対して宣言され（ここで、適切なインスタンスは、引数として使用するためのインスタンス、インスタンスメソッドにより使用されるべきインスタンス、及びクラスメソッドにより使用されるメタクラスインスタンスを含み）；実際上、幾つかの又は全ての手動インボケーションシーケンスコードを発生する作業は、次のものに置き換えられる。１）プロデューサ依存性宣言を書き込むためにアプリケーションプログラマーにより行われる作業；及び２）プロデューサグラフ（１つ又は複数）を発見及び構築し、そしてそのプロデューサグラフ（１つ又は複数）のプロデューサを実行するためにランタイムにより行われる作業。ランタイムを書く努力は、比較的多大であるが、ランタイムに対して書かれたオブジェクト指向のアプリケーションを実行するのに使用できるという点で一度書くだけでよく、対照的に、典型的なアプリケーションでは、プロデューサ依存性宣言を書くための努力は、手動インボケーションシーケンスコードを書くのに比して僅かである。
【０２２６】
非ダイナミックなプロデューサ依存性は、非条件付きメソッドインボケーションシーケンスコードを指定する仕方を与え、従って、非条件付き手動インボケーションシーケンスコードを書く必要性を回避する。コンティンジェントのプロデューサ依存性は、条件付き処理を指定する仕方を与え、従って、条件付き手動インボケーションシーケンスコードを書く必要性に取って代わる。プロデューサの集合を返送できるようにするプロデューサ依存性をサポートすることは、パラメータとして通される前に集合の充填を指定する仕方を与え、従って、パラメータとして通される前に集合を充填するために手動インボケーションシーケンスコードに複数のコールを書き込む必要性を回避する。サブスクリプションをサポートすることは、プログラマーが、聴取されるオブジェクトの各形式に対して特定の聴取コードを書き込む必要のない環境を与える（例えば、プロデューサグラフ指向のプログラミングスプレッドシートにおいては、アブソービングサブスクリプション基準で範囲内のセルを識別させ、そしてアブソービングサブスクリプションに新たなプロデューサが追加されるたびに平均値を再計算することにより、アブソービングサブスクリプションを使用して、ある範囲のセル（各セルはプロデューサである）の平均値を計算することができ；又、プロデューサグラフ指向のプログラミングスプレッドシートにおいては、スティッキーサブスクリプション基準で通貨コンテンツを保持するセルを識別させ、そして通貨換算を行うスティッキープロデューサ（１つ又は複数）のスティッキーサブスクリプション特性をインスタンス生成させることにより、スティッキーサブスクリプションを通貨コンバータとして使用することができる（スティッキーサブスクリプションにより生成された（換算金額を保持する）プロデューサは、次いで、他のセルにおいて表示するように使用できる）。
【０２２７】
オペレーション
新インスタンスコマンド
図１５は、本発明の一実施形態により新たなインスタンスをインスタンス生成するためのフローチャートである。図１０を参照して上述したように、図１０の新クラスモジュール１０９５は、新インスタンスモジュール１０９８の一部分として具現化することができる。図１５のフローチャートは、このような実施形態を仮定するもので、新インスタンスモジュール１０９８により遂行され、新クラスモジュール１０９５を表す図１５のフローチャートの一部分は、ブロック１５４０及び１５５０を含む破線ブロック１５８０として示されている。
【０２２８】
新インスタンスコマンドに応答して（ブロック１５１０）、制御はブロック１５２０へ進む。ブロック１５２０において、インスタンスが既に存在するかどうか決定される。もし存在しなければ、制御はブロック１５３０へ進み、さもなければ、インスタンスをインスタンス生成する必要がなく、制御はブロック１５７０へ進み、フローチャートが終了となる。インスタンスキーをサポートする一実施形態では、ブロック１５２０は、新インスタンスコマンドの一部分として与えられるインスタンスキー（及びインスタンスキーがクラスにわたって独特のものである必要がない場合にはクラスキー）に対して図１０のインスタンス追跡構造１０６５にアクセスすることにより遂行される。
【０２２９】
ブロック１５３０では、インスタンスのクラス定義が既にロードされたかどうか決定される。ロードされていない場合は、制御はブロック１５４０へ進み、さもなければ、制御はブロック１５６０へ進む。クラスキーをサポートする一実施形態では、ブロック１５４０は、新インスタンスコマンドの一部分として与えられるクラスキーに対して図１０のクラス追跡構造１０９２にアクセスすることにより遂行される。
【０２３０】
ブロック１５４０では、クラスがロードされ、制御がブロック１５５０へ進む。ブロック１５５０では、（クラス内のメソッドキーにより記憶される−図１１Ｄを参照））プロデューサ依存性宣言ステートメントを含めて、クラス定義がクラスキーに基づいて記憶されそしてイントロスペクトされる。ブロック１５５０から、制御は、ブロック１５６０へ進む。図１０を参照すれば、ブロック１５４０及び１５５０において次のことが遂行される。１）クラスが、ビジネスロジック１０１０を含むクラス定義から、クラス１０５４へロードされ（このロードの結果、クラスのメソッド及びプロデューサ依存性宣言がメソッド及びプロデューサ依存性宣言１０５６に記憶され）；２）クラスがクラス追跡構造１０９２に追加され；そして３）メソッドがメソッド追跡構造１０５８に追加される。更に、メソッドの出力クラスがロードされる。
【０２３１】
ブロック１５６０では、クラスのインスタンスがインスタンスキーに基づいてインスタンス生成され記憶される。図１０を参照すれば、インスタンスは、インスタンス１０５２へとインスタンス生成され、そしてインスタンスは、インスタンス追跡構造１０６５へと追加される。ブロック１５５０から、制御は、ブロック１５７０へ進み、フローチャートが終了となる。オブジェクト関連マッピング技術が使用される本発明の幾つかの実施形態では、データを外部データソースからロードして、インスタンスのフィールドをブロック１５６０の一部分としてポピュレートすることができる。
【０２３２】
本発明の幾つかの実施形態では、クラス及びインスタンスは、プロデューサグラフ指向のプログラミングサポートを伴うランタイムが気付かないやり方でロード／インスタンス生成される（例えば、図９Ａにおいて、ランタイム９１０が気付かない状態でランタイム９１５がロード／インスタンス生成する場合）。このようなケースにおいて、クラスInstanceKey（これは２つのエレメントを保持する：即ち、キー識別子がインスタンス又は別のオブジェクト（ストリングのような）に対するリファレンスであるかどうか指示するインスタンスキーネイチャー；及びインスタンス又は別のオブジェクト（ストリングのような）のいずれかに対するリファレンスであるキー識別子）のインスタンスであるインスタンスキーもサポートする本発明の実施形態では、ブロック１５２０及び１５３０は、プロデューサグラフ指向のプログラミングサポートを伴うランタイムが気付くやり方でインスタンス及びクラスがインスタンス生成され／ロードされるかどうか問合せする。プロデューサグラフ指向のプログラミングサポートを伴うランタイムが、既にロードされたクラスに気付かないケースでは、クラスがロードされず、クラスは、クラス追跡構造１０９２に追加され、そしてメソッドは、メソッド追跡構造１０５８に追加される。プロデューサグラフ指向のプログラミングサポートを伴うランタイムが、既にインスタンス生成されたインスタンスに気付かないケースでは、インスタンスがインスタンス生成されず、インスタンスは、インスタンス追跡構造１０６５に追加される。
【０２３３】
新プロデューサ及び非オーバーライドコマンド
図１６は、本発明の一実施形態により新たなプロデューサをインスタンス生成し、そしてプロデューサを非オーバーライドするためのフローチャートである。図１０を参照すれば、図１５のフローは、自動プロデューサグラフ発生モジュール１０４０及びオーバーライドプロデューサモジュール１０４５（又は図１０に関する別の実施形態を参照して述べるように、オーバーライド及び非オーバーライドを取り扱うモジュール）により遂行される。
【０２３４】
新プロデューサコマンドに応答して（ブロック１６００）、制御はブロック１６０５へ進む。本発明の一実施形態では、新プロデューサコマンドは、種々の状況に応答して実行することができる。以下のテーブル２は、本発明の一実施形態によりパスされる種々の状況及びパラメータを示す。
テーブル２
2010511234.tif 000004
【０２３５】
ブロック１６０５において、プロデューサが既に存在するかどうか決定される。存在しなければ、制御はブロック１６１０へ進み、さもなければ、制御はブロック１６７０へ進む。ブロック１６０５は、新プロデューサコマンドの一部分として（例えば、キー及び／又はリファレンスにより）識別されたクラス、インスタンス及びメソッドにアクセスすることにより遂行される。プロデューサキーをサポートする一実施形態では、ブロック１６０５は、新プロデューサコマンドの一部分として与えられたプロデューサキー（テーブル２の被呼プロデューサ列におけるプロデューサキー）に対して図１０のプロデューサグラフ（１つ又は複数）構造１０６０にアクセスすることにより遂行される。
【０２３６】
ブロック１６１０では、新インスタンスモジュールが新インスタンスコマンドでコールされ、制御はブロック１６１５へ進む。本発明の一実施形態では、ブロック１６１０は、テーブル２の被呼プロデューサ列のプロデューサキーからのインスタンスキーを使用して図１５のフローチャートをコールすることにより遂行される。
【０２３７】
ブロック１６１５では、プロデューサのインスタンスのクラス定義がアクセスされ、制御はブロック１６２０へ進む。図１０を参照すれば、クラス追跡構造１０９２に基づいてクラス１０５４の適切な１つにアクセスするために、テーブル２の被呼プロデューサ列におけるプロデューサキーからのクラスキーを使用することによりブロック１６１５が遂行される。
【０２３８】
ブロック１６２０では、プロデューサのメソッド及びプロデューサ依存性宣言ステートメントがアクセスされ、制御はブロック１６２５へ進む。図１０を参照すれば、ブロック１６１５で位置付けられたクラスからメソッド及びプロデューサ依存性宣言１０５６の適切な１つにアクセスするために、テーブル２の被呼プロデューサ列におけるプロデューサキーからメソッドキーを使用することによりブロック１６２０が遂行される。
【０２３９】
ブロック１６２５では、プロデューサグラフにプロデューサが追加され、制御はブロック１６３０へ進む。図１１Ｃにおける本発明の実施形態を参照すれば、最初の３つの列がポピュレートされる。
【０２４０】
ブロック１６３０では、各々の登録されたサブスクリプションに対して、サブスクリプションフィルタリング基準が処理されて、プロデューサが一致するかどうか決定する。図１４Ａにおける本発明の実施形態を参照すれば、サブスクリプションは、それがサブスクリプションログに追加されたときに登録されたと考える。サブスクリプションを登録するための例示的オペレーションを以下に説明する。ブロック１６３０は、自動プロデューサグラフ発生とプロデューサグラフ実行との間に分割されるべきインスタンス生成されたプロデューサをスキャンする作業を許す任意の最適化である。従って、本発明の別の実施形態では、ブロック１６３０を遂行しなくてもよい。
【０２４１】
ブロック１６３５では、プロデューサは、依存性のためにコールされた場合にプロデューサグラフ（１つ又は複数）にリンクされる。ブロック１６３５から、制御は、ブロック１６４０へ進む。ブロック１６３５を遂行する仕方は、新プロデューサコマンドが実行される状況に依存する（図２０を参照）。例えば、それが問題とするプロデューサであるか又はオーバーライドされるプロデューサであるという状況の場合には、依存性のためにそれがコールされず、何も行われない。対照的に、状況が非サブスクリプション下方宣言である場合には、非サブスクリプション下方宣言依存性のためにそれがコールされ、図１１Ｃにおける本発明の実施形態を参照すれば、次のことが行われる。１）被呼子プロデューサの親プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１５０（テーブル２の被呼プロデューサ列）が、親発呼プロデューサの行に対する親プロデューサリファレンス（テーブル２の発呼プロデューサ列）、及び依存性決定プロデューサリファレンス（テーブル２の依存性決定プロデューサリファレンス列）で変更され；及び２）親発呼プロデューサの行の子プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１６０（テーブル２の発呼プロデューサ列）が、被呼子プロデューサの行に対する子プロデューサリファレンス（テーブル２の被呼プロデューサ列）、依存性決定プロデューサリファレンス（テーブル２の依存性決定プロデューサリファレンス列）、及びリンクモード（テーブル２のリンクモード列によりセットされる）で変更される。
【０２４２】
対照的に、状況がスティッキーサブスクリプションである場合には、それは、識別されるトリガープロデューサのためにコールされたものであり、図１１Ｃにおける本発明の実施形態を参照すれば、次のことが行われる。１）発呼子プロデューサの親プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１５０（テーブル２の発呼プロデューサ列）が、親被呼プロデューサの行に対する親プロデューサリファレンス（テーブル２の被呼プロデューサ列）、及び依存性決定プロデューサリファレンス（テーブル２の依存性決定プロデューサリファレンス列）で変更され；及び２）親被呼プロデューサの行の子プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１６０（テーブル２の被呼プロデューサ列）が、発呼子プロデューサの行に対する子プロデューサリファレンス（テーブル２の発呼プロデューサ列）、依存性決定プロデューサリファレンス（テーブル２の依存性決定プロデューサリファレンス列）、リンクモード（テーブル２のリンクモード列によりセットされる）、及びスティッキーを指示するようにセットされたスティッキーインジケータで変更される。この点に関して、非サブスクリプション上方宣言依存性の状況は、スティッキーサブスクリプションと同様に取り扱われる。
【０２４３】
ブロック１６４０において、プロデューサは、非実行とマークされ、制御はブロック１６４５へ進む。図１１Ｃにおける本発明の実施形態を参照すれば、適切な行の増分的実行マーキング列１１８０に、非実行指示がポピュレートされる。
【０２４４】
ブロック１６４５では、プロデューサが何らかの依存性を有しそしてオーバーライドされないかどうか決定される。もしそうであれば、制御はブロック１６５０へ進み、さもなければ、制御はブロック１６６５へ進む。ブロック１６４５は、ブロック１６２０においてアクセスされたプロデューサ依存性宣言及びテーブル２のコール形式列をチェックすることにより遂行される。
【０２４５】
ブロック１６５０では、現在解明されるべきプロデューサ依存性宣言の各依存性に対して、プロデューサの数が決定され、そして各々に対して新プロデューサコマンドがインボークされる。ブロック１６５０から、制御はブロック１６５５へ進む。本発明の異なる実施形態は、異なる時間に異なる形式の依存性を決定し、本発明の一実施形態においてブロック１６５０を遂行する仕方について以下に説明する。
【０２４６】
ブロック１６５５では、プロデューサは、その全ての従属プロデューサが存在しそして実行された場合に実行スタートログに追加される。ブロック１６５５から、制御はブロック１６６０へ進む。このフローの現在繰り返しの一部分としてインスタンス生成される所与のプロデューサに対して、ブロック１６５５が遂行されるときには、所与のプロデューサが依存するプロデューサに対するこのフローの別の繰り返しのインボケーションでそのプロデューサの実行状態が返送される（ブロック１６６０を参照）（例えば、図１１Ｃの本発明の実施形態に関しては、適切な行（１つ又は複数）の増分的実行マーキング列１１８０からの状態）。全ての従属プロデューサが存在し且つ全ての従属プロデューサの実行状態が実行される場合には、現在繰り返しのプロデューサが実行スタートログに追加される。
【０２４７】
ブロック１６６０では、プロデューサの実行状態がパラメータとして返送される。
【０２４８】
ブロック１６７０では、ブロック１６３５と同様に、プロデューサは、依存性のためにコールされた場合にプロデューサグラフ（１つ又は複数）にリンクされる。ブロック１６７０から、制御はブロック１６７５へ進む。種々の理由でブロック１６７０に到達する。例えば、プロデューサがプロデューサオーバーライドコマンドに応答して以前にインスタンス生成されたがプロデューサグラフにリンクされないために、ブロック１６７０に到達する。別の例として、プロデューサがプロデューサグラフの既に一部分でありそして別のものに追加される（例えば、問題とするプロデューサ、問題とするプロデューサの子孫、等であることに応答して以前にインスタンス生成された）ためにブロック１６７０に到達することがある。
【０２４９】
ブロック１６７５では、オーバーライド、スティッキーサブスクリプション依存性、又は非サブスクリプション上方宣言依存性のために、新プロデューサフローがコールされるかどうか決定される。もしそうであれば、制御はブロック１６８０へ進み、さもなければ、制御はブロック１６６０へ進む。ブロック１６７５は、テーブル２のコール形式列をチェックして、それが、オーバーライドされたプロデューサに対するコールであるか、スティッキーサブスクリプション依存性に対するコールであるか、又は非サブスクリプション上方宣言依存性に対するコールであるか調べることにより、遂行される。
【０２５０】
ブロック１６８０では、ブロック１６４０と同様に、プロデューサは、非実行とマークされ、制御はブロック１６６５へ進む。ブロック１６８０は、種々の理由で到達する。
【０２５１】
ブロック１６６５では、プロデューサは、それがまだ存在しない場合に実行スタートログに追加され、そして制御は、ブロック１６６０へ進む。
【０２５２】
プロデューサ非オーバーライドコマンドに応答して（ブロック１６９０）、制御はブロック１６９５へ進む。ブロック１６９５では、プロデューサが非オーバーライドとマークされ、制御はブロック１６４０へ進む。図１１Ｃの本発明の実施形態を参照すれば、プロデューサの行のプロデューサ出力キャッシング及びオーバーライドプロデューサ出力指示列１１７０がアクセスされ、そしてプロデューサがもはやオーバーライドされないことを指示するように変更される。このフローを続けると、ブロック１６４０は、ブロック１６４５へ通じ、又、プロデューサが何らかの依存性を有する場合には、ブロック１６５０へ通じ、これは、プロデューサのもとでのプロデューサグラフがまだない場合には、それを発見し構築するようにさせる。プロデューサのもとでのプロデューサグラフが既に発見され構築されている場合には、新プロデューサコマンドをインボークすると、フローが１６００から１６０５へ、１６７０へ、等々と進み、更に、ブロック１６６０においてプロデューサのもとでのグラフのプロデューサの実行状態を返送すると、ブロック１６５５において実行スタートログにプロデューサが追加されるかどうか決定される。しかしながら、プロデューサのもとでのプロデューサグラフが発見及び構築されない場合には、新プロデューサコマンドをインボークすると、それが発見及び構築され、フローは、１６００から１６０５へ、１６１０へ、等々と進む。
【０２５３】
図１７は、本発明の一実施形態による図１６のブロック１６５０のためのフローチャートである。従って、制御は、ブロック１６４５からブロック１６５０におけるブロック１７００へと進む。ブロック１７００において、プロデューサのプロデューサ依存性宣言における各依存性に対して（各ArgumentDependenciy、FieldDependency、SequencingDependency、UpwardDependency及びWeaklyConstrainedDependencyに対して１つづつ）、次のブロック１７０５−１７４５が遂行される。図１０及び１１Ｄを参照すれば、メソッド追跡構造がアクセスされ、プロデューサ依存性に関する情報が決定される。又、ブロック１７１５、１７２５、１７３０、１７４０、１７４５及び１７５０は、プロデューサグラフを実行する前に遂行されたときに最適となることも理解されたい。
【０２５４】
ブロック１７０５では、依存性が、スティッキー依存性のために既にリンクされた引数依存性であるかどうか決定される。もしそうであれば、制御はブロック１７１０へ進み、そこで、この依存性に対してフローが完了し、さもなければ、制御はブロック１７１５へ進む。図１１Ｃに示す本発明の実施形態に関しては、スティッキーインジケータがチェックされ、この依存性の引数ＩＤがスティッキーサブスクリプション引数依存性を受けるか又は上方宣言引数依存性を受けるかを決定する。
【０２５５】
ブロック１７１５では、依存性がコンティンジェント依存性であるかどうか決定される。もしそうであれば、制御はブロック１７２０へ進み、さもなければ、制御はブロック１７２５へ進む。ブロック１７１５は、依存性により識別された子プロデューサのプロデューサ依存性宣言をチェックして、それが空である（子プロデューサが独立プロデューサである）かどうか決定することにより、遂行される。図１３Ａ−Ｊを参照すれば、これは、破線の丸内の数字を伴うプロデューサ（例えば、図１３Ｄでは、プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡ）については真であるが、他のプロデューサ（例えば、図１３Ｄでは、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡ）については真でない。従って、図１３Ｄを参照すれば、ブロック１７１５は、丸１、４及び８により表わされる。ブロック１７１５及びそこからブロック１７２５−１７５０を通るフローは、最適なものであって、破線の丸内の数字を伴うプロデューサをプロデューサグラフに追加／リンクすることと、プロデューサを実行する作業を自動プロデューサグラフ発生とプロデューサグラフ実行との間で分割すること、を回避する。
【０２５６】
ブロック１７２０では、依存性決定プロデューサに対する新プロデューサコマンドがインボークされ、そしてフローが終了となる。例えば、図１３Ｄを参照すれば、ブロック１７２０は、丸５、６及び７で表わされたものを生じさせる。
【０２５７】
ブロック１７２５では、依存性決定プロデューサが実行され、制御はブロック１７３０へ進む。例えば、図１３Ｄを参照すれば、ブロック１７２５が丸１１で示されている（従って、図１７のフローは、図１３Ｄの丸９及び１０が遂行されない前記実施形態を示している）。
【０２５８】
ブロック１７３０では、依存性が非サブスクリプション依存性であるかどうか決定される。もしそうであれば、制御はブロック１７５０へ進み、さもなければ、制御はブロック１７４０へ進む。換言すれば、ブロック１７２５では、親プロデューサのプロデューサ依存性宣言の一部分である依存性決定プロデューサのメソッドにおけるプロデューサ依存性決定コードが実行される。この依存性がサブスクリプション依存性であるかどうか識別するこのプロデューサ依存性宣言コードが実行されると、親プロデューサのプロデューサ依存性の形式が決定される。図１３Ｄの例に関して、丸１１は、ブロック１７３０からブロック１７５０へ進む図１７のフローを生じさせる。
【０２５９】
ブロック１７５０では、ブロック１７２５における依存性決定プロデューサの実行により返送されるプロデューサの数が決定され、そして１７２５において実行された依存性決定プロデューサリファレンスを含めて、テーブル２に示す引数を使用して、各々に対して新プロデューサコマンドがインボークされる。例えば、図１３Ｄを参照すれば、ブロック１７５０が丸１２及び１３と、丸Ｃ及びＤとを生じさせる。
【０２６０】
図１４Ｂのアブソービングサブスクリプション実施例を参照すれば、ブロック１７２５は丸４を表し、これは、ブロック１７３０を通してブロック１７４０へと進むフローを生じさせる。
【０２６１】
ブロック１７４０において、サブスクリプションがサブスクリプションログに追加され、そしてサブスクリプションがアブソービングである場合には、それが未完了とマークされる。ブロック１７４０から、制御はブロック１７４５へ進む。図１４Ａに示す本発明の実施形態を参照すれば、サブスクリプションログは、上述したようにサブスクリプションでポピュレートされる。
【０２６２】
ブロック１７４５では、インスタンス生成された全てのプロデューサがスキャンされ、それらがサブスクリプションの基準に一致する（従って、トリガープロデューサである）かどうか調べられ、そして一致が処理される。
【０２６３】
図１８は、本発明の一実施形態による図１７のブロック１７４５に対するフローチャートである。従って、制御は、ブロック１７４０から、ブロック１７４５におけるブロック１８００へ進む。ブロック１８００では、インスタンス生成される各プロデューサに対して、次のブロック１８１０−１８３０が遂行される。
【０２６４】
ブロック１８１０では、プロデューサがサブスクリプションの基準を満足するかどうか決定される。もしそうであれば、制御はブロック１８１５へ進み、さもなければ、制御はブロック１８３０へ進み、そこで、現在処理されているプロデューサについてフローが終了となる。図１１Ｃ及び１４Ａに示す本発明の実施形態を参照すれば、プロデューサグラフ（１つ又は複数）がアクセスされ、それらが、サブスクリプションの基準を満足するプロデューサを含むかどうか決定する。
【０２６５】
マッチングプロデューサを処理する仕方は、処理されるサブスクリプションの形式に依存する。ブロック１８１５を参照すれば、サブスクリプションがアブソービング形式である場合には、制御はブロック１８２５へ進み、さもなければ、制御はブロック１８２０へ進む。ブロック１８１５は、ブロック１７４０又は２２３５において追加されるサブスクリプションの形式に応答して遂行される。
【０２６６】
ブロック１８２５では、マッチングプロデューサがサブスクリプションログに追加されそしてアブソービングサブスクリプションを伴うプロデューサがマッチングプロデューサにリンクされる。ブロック１８２５から、制御はブロック１８３０へ進む。図１１Ｃ及び図１４Ａ−Ｂに示す本発明の実施形態を参照すれば、次のことが行われる。１）トリガープロデューサ列１４１０のためのサブスクリプション基準からのサブスクリプション基準がブロック１８１０に使用され、そしてマッチングプロデューサが探索され（例えば、プロデューサ１５６０Ａ−Ｎの１つ）；２）マッチングプロデューサが、サブスクリプションの行においてマッチングプロデューサ列１４１５に追加され；そして３）アブソービングサブスクリプションを伴うプロデューサ（例えば、プロデューサ１４５０）が図１１Ｃのプロデューサグラフ（１つ又は複数）構造におけるマッチングプロデューサ（例えば、プロデューサ１４６０Ａ−Ｎの１つ）にリンクされる（所与のアブソービングサブスクリプションに対してサブスクリプションログ１４Ａの依存性決定プロデューサリファレンス列１４２１から抽出された依存性決定プロデューサリファレンスを使用して）。
【０２６７】
ブロック１８２０では、生成されるべき親プロデューサに対して新プロデューサコマンドがインボークされる。ブロック１８２０から、制御はブロック１８３０へ進み、そこで、ブロック１８００において選択された現在プロデューサに対してフローが終了となる。図１４Ａ及び１４Ｃに示す本発明の実施形態を参照すれば、次のことが行われる。１）トリガープロデューサ列１４１０に対するサブスクリプション基準からのサブスクリプション基準がブロック１８１０において使用され、そしてマッチングプロデューサが探索され（例えば、プロデューサ１４７５）；そして２）次のようにセットされたテーブル２のパラメータで新プロデューサコマンドがインボークされる。ａ）コール形式はスティッキーサブスクリプションであり；ｂ）発呼プロデューサは、発呼子プロデューサ（例えば、プロデューサ１４７５）のプロデューサキーであり；ｃ）被呼プロデューサは、生成されるべき被呼親プロデューサ（例えば、プロデューサ１４８０）のプロデューサキーであり、このプロデューサキーは、生成されるべき親プロデューサに対するスティッキーサブスクリプション特性からの親クラス、インスタンス及びメソッドキー（図１４Ａ、列１４３０、１４３５及び１４３７）を使用して（インスタンスキーが空である場合には、発呼子プロデューサのインスタンスキーを使用して）形成され；及びｄ）被呼親プロデューサに対するリンクモード（図１４Ａ、リンクモード列１４２５）、並びにｅ）所与のスティッキーサブスクリプションに対するサブスクリプションログ１４Ａの依存性決定プロデューサリファレンス列１４２１から抽出される依存性決定プロデューサリファレンス。
【０２６８】
図１９は、本発明の一実施形態による図１６のブロック１６３０のためのフローチャートである。従って、制御は、ブロック１６２５から、ブロック１６３０におけるブロック１９００へと進む。図１９は、図１８に非常に良く似ている。より詳細には、図１９のブロック１９１０、１９１５、１９２０及び１９３０は、ブロック１８１０、１８１５、１８２０及び１８３０と同一であり、一方、ブロック１９００及び１９２５は、ブロック１８００及び１８２５とは異なる。従って、相違点のみについてここに説明する。
【０２６９】
ブロック１９００は、各登録されたサブスクリプションに対してフローが遂行されることを示し、一方、ブロック１８００は、各インスタンス生成されたプロデューサに対してフローが遂行されることを示す。従って、図１８のフローは、単一のサブスクリプションを中心として全てのプロデューサをスキャンするが、図１０のフローは、単一のプロデューサを中心として全てのサブスクリプションをスキャンする。
【０２７０】
ブロック１９２５は、アブソービングサブスクリプションが未完了とマークされることを除いて、ブロック１８２５と同じである。図１４Ａに示す本発明の実施形態を参照すれば、適切な行における完了列１４２０が、未完了を示すように更新される。
【０２７１】
図２０は、本発明の一実施形態による図１６のブロック１６３５及び１６７０のためのフローチャートである。従って、制御は、ブロック１６０５及びブロック１６３０から、ブロック１６３５及び１６７０におけるブロック２００５へ進む。ブロック２００５において、図１６のフローチャートのこの繰り返しが、依存性のために（例えば、以前の繰り返しのブロック１６３０（ブロック１９２０）又は１６５０（ブロック１７２０、１７５０又は１７４５／１８２０から）インボークされたものであるかどうか決定される。もしそうでなければ、制御は、どこからフローに入ったか（ブロック１６３０又は１６０５から）に基づいてブロック１６４０又は１６７５へ進む。
【０２７２】
ブロック２０１０において、フローがスティッキーサブスクリプション又は非サブスクリプション上方宣言状態のためにコールされたかどうか決定される。もしそうでなければ、制御はブロック２０１５へ進み、さもなければ、制御はブロック２０２０へ進む。ブロック２０１０は、テーブル２からのコール形式パラメータ（即ち、コール形式がスティッキーサブスクリプション又は非サブスクリプション上方宣言であるかどうか）をチェックすることにより遂行される。図１８及び１９に示す本発明の実施形態を参照すれば、新プロデューサコマンドは、ブロック１８２０又は１９２０からインボークされる。
【０２７３】
ブロック２０２０では、現在親プロデューサが、発呼側の子プロデューサにリンクされる。図１１Ｃ及び図１４Ｃに示す本発明の実施形態を参照すれば、テーブル２の被呼プロデューサ列からのパラメータにより識別された被呼親プロデューサ（例えば、プロデューサ１４８０）は、図１１Ｃのプロデューサグラフ（１つ又は複数）構造において、テーブル２のリンクモード及び依存性決定プロデューサリファレンス列からのパラメータにより識別されたリンクモード及び依存性決定プロデューサリファレンスを使用して、テーブル２の発呼プロデューサ列からのパラメータにより識別された発呼子プロデューサ（例えば、プロデューサ１４７５）へリンクされる。親が以前に存在した場合には、ブロック２０２０の振舞いは、０以上の子プロデューサへマップできる引数が１つであるという意味で、アブソービングサブスクリプション依存性の振舞いと同様になる。
【０２７４】
ブロック２０１５では、発呼親プロデューサは、現在被呼子プロデューサにリンクされる。図１１Ｃに示す本発明の実施形態を参照すれば、テーブル２の発呼プロデューサ列からのパラメータにより識別された発呼親プロデューサは、図１１Ｃのプロデューサグラフ（１つ又は複数）構造において、テーブル２の依存性決定プロデューサリファレンス列により識別された依存性決定プロデューサリファレンスを使用して、テーブル２の被呼プロデューサ列からのパラメータにより識別された被呼子プロデューサにリンクされる。ブロック２０１５及び２０２０から、制御は、フローがどこに入ったか（ブロック１６０５又は１６３０から）に基づいてブロック１６４０又は１６７５へ進む。
【０２７５】
図２１は、本発明の一実施形態によりプロデューサをオーバーライドするためのフローチャートである。図１０を参照すれば、図２１のフローは、オーバーライドプロデューサモジュール１０４５（又は図１０に関する別の実施形態を参照して述べたように、オーバーライド及び非オーバーライドを取り扱うモジュール）により遂行される。
【０２７６】
オーバーライドプロデューサコマンドに応答して（ブロック２１１０）、制御はブロック２１２０へ進む。ブロック２１２０では、オーバーライドプロデューサコマンドにより識別されたプロデューサに対して新プロデューサコマンドがインボークされ、制御はブロック２１３０へ進む。ブロック２１２０は、本発明の一実施形態では、オーバーライドされるべきプロデューサがまだインスタンス生成されていない場合、プロデューサを非実行とマークし（ブロック１６４０又は１６８０）そしてそれを実行スタートログにログする（ブロック１６６５）ように遂行される。まだインスタンス生成されていないプロデューサのオーバーライドを許さない本発明の別の実施形態では、ブロック１６０５と１６１０との間で付加的なチェックを行って、この新プロデューサコマンドがオーバーライドプロデューサコマンドに応答してコールされたかどうか決定し、そしてこの新プロデューサコマンドがオーバーライドプロデューサコマンドに応答してコールされた場合にはエラーを指示する。
【０２７７】
ブロック２１３０では、プロデューサ出力キャッシュ（及びフィールドの場合にはインスタンス）における出力がセットされ、そしてプロデューサが、オーバーライドされたとしてマークされる。
【０２７８】
グローバルな実行コマンド
図２２Ａは、本発明の一実施形態により現在プロデューサグラフを実行するためのフローチャートの一部分であり、一方、図２２Ｂは、本発明の一実施形態により現在プロデューサグラフを実行するためのフローチャートの別の部分である。図１０を参照すれば、図２２のフローは、プロデューサグラフ実行モジュール１０７０により遂行される。
【０２７９】
グローバルな実行コマンドに応答して、ブロック２２００は、候補プロデューサのセットが、実行スタートログにおけるプロデューサに基づいて実行されるべく選択されることを示し、制御はブロック２２０５へ進む。オーバーライドされたプロデューサが非実行とマークされ、それを実行すると、それらのオーバーライドされた結果が返送される（それらのメソッドを実行させるのではなく）本発明の一実施形態では、候補プロデューサの現在セットは、実行スタートログにおけるプロデューサである。オーバーライドされたプロデューサが非実行とマークされ、それを実行すると、それらのオーバーライドされた結果が返送される（それらのメソッドを実行させるのではなく）本発明の一実施形態を上述したが、別の実施形態は、異なる仕方で動作してもよい（例えば、オーバーライドされたプロデューサを実行とマークし、そして候補プロデューサの現在セットの選択時に、実行スタートログの独立プロデューサ及び実行スタートログにおけるオーバーライドされたプロデューサの親が選択される）。
【０２８０】
ブロック２２０５では、実行の準備ができたプロデューサのサブセットが候補プロデューサのセットから選択され、そして制御はブロック２２１０へ進む。ブロック２２０５を遂行する例示的な仕方をここに説明する。
【０２８１】
ブロック２２１０では、レディプロデューサの現在セットの中のプロデューサは、形式により分類され、標準プロデューサは、ブロック２２１５へ進み、そして依存性決定プロデューサは、ブロック２２２５へ進む。本発明の一実施形態では、ブロック２２１０は、プロデューサのリターンクラスをチェックすることにより遂行される。図１０及び図１１Ｄを参照すれば、メソッド追跡構造がアクセスされ、プロデューサの出力クラスがＤＥＰであるかどうか決定し、従って、このプロデューサは、依存性決定プロデューサである。
【０２８２】
ブロック２２１５では、レディプロデューサの現在セットにおける標準的プロデューサが実行されて、制御はブロック２２２０へ進む。本発明の一実施形態では、ブロック２２１５は、引数依存性から生じる子プロデューサの出力からマップされた入力パラメータでメソッドをコールすることにより遂行される（引数については、リンクモードの引数ＩＤを使用して、適切な子プロデューサの出力を、実行されているメソッドの適切な入力引数へとマップする。本発明のある実施形態では、このような実行は、所与のメカニズムに出力を書き込む子プロデューサのメソッドにおけるコード（例えば、グローバル変数をセットし、プロデューサ出力でないインスタンスのフィールドをセットし、外部データソースに影響を及ぼし、等々）、又は所与のメカニズムからその出力を読み取る親プロデューサのメソッドにおけるコードを実行させる。ブロック２２２０では、これらの実行された標準プロデューサのいずれかにアブソービングサブスクリプションを有する親がもしあれば、それらに対して、サブスクリプションは、未完了とマークされる。ブロック２２２０から、制御はブロック２２４５へ進む。図１４Ａを参照すれば、完了列１４２０の適切な行は、未完了を指示するようにセットされる。
【０２８３】
ブロック２２２５では、レディプロデューサの現在セットにおける依存性決定プロデューサが実行準備され、そして制御はブロック２２３０へ進む。ブロック２２２５を遂行する例示的な仕方は、以下に述べる。
【０２８４】
ブロック２２３０では、レディプロデューサの現在セットにおける依存性決定プロデューサが実行され、そして制御はブロック２２３５へ進む。本発明の一実施形態では、ブロック２２３０は、ブロック２２１５と同様に遂行される。
【０２８５】
ブロック２２３５では、発見されたプロデューサに対して新プロデューサコマンドが実行され、そしてサブスクリプションに対してサブスクリプションログ及び処理が遂行される。ブロック２２３５の新プロデューサコマンド部分は、ブロック１７５０と同様に遂行され、一方、サブスクリプションログ及び処理は、ブロック１７４０及び１７４５と同様に遂行される。
【０２８６】
ブロック２２４０では、実行スタートログに新たに追加された候補プロデューサのセットに追加がなされる。ブロック２２４０から、制御はブロック２２４５へ進む。ブロック２２４０は、ブロック２２３０及び２２３５の結果として実行スタートログに新たに追加されたプロデューサのみが候補プロデューサのセットに追加されることを除いて、ブロック２２００と同様に遂行される。
【０２８７】
ブロック２２４５では、実行されたプロデューサが、実行されたとマークされ、プロデューサ出力キャッシング（及びインスタンスキャッシング）が、必要に応じて更新され、実行されたプロデューサの親プロデューサが候補プロデューサの現在セットに追加され、そして実行されたプロデューサが候補及びレディプロデューサの現在セットから除去される。ブロック２２４５から、制御はブロック２２５０へ進む。
【０２８８】
ブロック２２５０では、候補プロデューサのセットが空であるかどうか決定される。もし空でなければ、制御がブロック２２０５へ戻り、さもなければ、制御はブロック２２５５へ進む。
【０２８９】
ブロック２２５５では、全てのサブスクリプションが完了されたかどうか決定される。もしそうであれば、制御はブロック２２６５へ進み、そこで、フローが終了となるが、さもなければ、制御はブロック２２６０へ進む。図１４Ａにおける本発明の実施形態を参照すれば、未完了のアブソービングサブスクリプションに対してサブスクリプション形式列１４０５及び完了列１４２０がスキャンされる。
【０２９０】
ブロック２２６０では、未完了のアブソービングサブスクリプションが処理され、制御がブロック２２０５へ戻る。ブロック２２６０を遂行する例示的な仕方について、以下に説明する。
【０２９１】
図２３は、本発明の一実施形態による図２２のブロック２２０５のためのフローチャートである。従って、制御は、ブロック２２００から、ブロック２２０５のブロック２３０５へ進む。ブロック２３０５では、候補プロデューサのセットにおける各プロデューサに対して、次のブロック２３１０−２３２５が遂行される。
【０２９２】
ブロック２３１０では、プロデューサが、未完了のアブソービングサブスクリプション依存性を有するかどうか決定される。もしそうであれば、制御はブロック２３２５へ進み、さもなければ、制御はブロック２３１５へ進む。図１４Ａの実施形態を参照すれば、現在選択されたプロデューサ及びアブソービングサブスクリプション形式への一致に対してサブスクライバープロデューサキー列１４００及びサブスクリプション形式列１４０５がスキャンされ、一致が見つかった場合には、適切な行における完了列１４２０がチェックされて、そのアブソービングサブスクリプション依存性の状態を決定する。
【０２９３】
ブロック２３１５では、現在選択されたプロデューサが依存するところのプロデューサが実行されるかどうか決定される。実行されない場合には、制御がブロック２３２５へ進み、さもなければ、制御がブロック２３２０へ進む。図１１Ｃに示す本発明の実施形態に関して、子依存性の行に対する増分的実行マーキング列１１８０がチェックされて、現在選択されたプロデューサの子の実行状態が決定される。
【０２９４】
ブロック２３２０では、現在選択された候補プロデューサがレディプロデューサの現在セットに追加され、制御はブロック２３２５へ進む。
【０２９５】
ブロック２３２５では、ブロック２３０５で選択された現在プロデューサに対してフローが終了となる。
【０２９６】
図２４は、本発明の一実施形態による図２２のブロック２２２５のフローチャートである。従って、制御は、ブロック２２１０からブロック２２２５におけるブロック２４０５へ進む。ブロック２４０５では、各依存性決定プロデューサに対して、次のブロック２４１０−２４３０が遂行される。
【０２９７】
ブロック２４１０では、現在選択された依存性決定プロデューサにより発生された以前の依存性の形式が決定される。依存性の形式が非サブスクリプションである場合には、制御がブロック２４２０へ進み；その形式がアブソービングサブスクリプションである場合には、制御がブロック２４１５へ進み；一方、その形式がスティッキーサブスクリプションである場合には、制御がブロック２４２５へ進む。ブロック２４１０は、プロデューサ出力キャッシングに記憶されたプロデューサの現在出力をチェックすることにより決定される。クラスＤＥＰを参照すれば、出力は、非サブスクリプション、アブソービングサブスクリプション、及びスティッキーサブスクリプションを指示する。
【０２９８】
両ブロック２４１５及び２４２５において、サブスクリプションログからエントリーが除去される。図１４Ａ−Ｃに示す本発明の実施形態を参照すれば、次のことが行われる。１）アブソービングサブスクリプション（ブロック２４１５）に対して、依存性決定プロデューサ（例えば、プロデューサ１４５５）を使用して、プロデューサグラフ（１つ又は複数）におけるその親プロデューサ（例えば、プロデューサ１４５０）が決定され、次いで、サブスクリプションログにおいて親プロデューサがルックアップされて、そのエントリーが除去され；及び２）スティッキーサブスクリプション（ブロック２４２５）に対して、サブスクリプションログにおいて依存性決定プロデューサ（例えば、プロデューサ１４７０）がルックアップされ、そしてそのエントリーが除去される。ブロック２４１５から、制御がブロック２４２０へ進み；ブロック２４２５から、制御がブロック２４２０へ進む。
【０２９９】
ブロック２４２０では、現在選択された依存性決定プロデューサにより既に生成されたリンクがプロデューサグラフ（１つ又は複数）からクリアされ、そして制御がブロック２４３０へ進む。図１１Ｃに示す本発明の実施形態を参照すれば、次のことが行われる。依存性決定プロデューサが既存のプロデューサにおいて「スティッキー」状態であるかどうか最初に決定される。これは、図１１Ｃにおける依存性決定プロデューサの子プロデューサリンク列をスキャニングし、そしてリンクの１つが、スティッキーを指示するスティッキーインジケータを有するかどうかチェックすることで行われる。
【０３００】
依存性決定プロデューサが既存のプロデューサにおいてスティッキー状態でない場合には、１）非サブスクリプション下方宣言依存性（引数、フィールド又はシーケンス依存性）を発生した依存性決定プロデューサに対して、依存性決定プロデューサの親が、プロデューサグラフにおいて、現在選択された依存性決定プロデューサの行での親プロデューサリファレンス（１つ又は複数）列１１５０を通してアクセスされ、この親プロデューサエントリーにおいて、依存性決定プロデューサリファレンスとマッチングさせるように子プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１６０がアクセスされ、そしてその依存性決定プロデューサリファレンスを有する子プロデューサの全リファレンスがクリアされ；２）非サブスクリプション上方宣言依存性を発生した依存性決定プロデューサに対して、依存性決定プロデューサの親が、プロデューサグラフにおいて、現在選択された依存性決定プロデューサの行での親プロデューサリンク（１つ又は複数）列１１５０を通してアクセスされ、この親プロデューサエントリーにおいて、依存性決定プロデューサリファレンスとマッチングさせるように親プロデューサリンク（１つ又は複数）列１１５０がアクセスされ、そしてその依存性決定プロデューサリファレンスを有する親プロデューサの全リファレンスがクリアされ；３）アブソービングサブスクリプションを発生した依存性決定プロデューサに対して、非サブスクリプション下方宣言依存性と同じ振舞いが遂行され；及び４）スティッキーサブスクリプションを発生した依存性決定プロデューサに対して、サブスクリプションを除去する前にサブスクリプションログ１４Ａの列１４２１から抽出された依存性決定プロデューサリファレンスが、プロデューサグラフ（１つ又は複数）構造において、親プロデューサリンク（１つ又は複数）列１１５０にてルックアップされ、そしてその依存性決定プロデューサリファレンスを有する親プロデューサの全リファレンスがクリアされる。
【０３０１】
非サブスクリプション上方宣言依存性又はスティッキーサブスクリプションの結果として、依存性決定プロデューサが既存のプロデューサにおいてスティッキー状態である場合には、依存性決定プロデューサがスティッキー状態となっている子プロデューサがアクセスされ（スティッキーを指示するスティッキーインジケータを伴う列１１６０における子プロデューサ）、そしてこの子プロデューサエントリーにおいて、依存性決定プロデューサリファレンスとマッチングさせるように親プロデューサリンク（１つ又は複数）列１１５０がアクセスされ、そしてその依存性決定プロデューサリファレンスを有する親プロデューサの全リファレンスがクリアされる。
【０３０２】
ブロック２４３０では、ブロック２４０５で選択された依存性決定プロデューサに対してフローが終了となる。
【０３０３】
図２５は、本発明の一実施形態による図２２のブロック２２６０のためのフローチャートである。従って、制御は、ブロック２２５５から、ブロック２２６０におけるブロック２５０５へ進む。ブロック２５０５では、未完了のアブソービングサブスクリプション依存性を伴う各プロデューサに対して、次のブロック２５１０−２５２５が遂行される。
【０３０４】
ブロック２５１０では、全てのマッチングプロデューサが実行されたかどうか決定される。もしそうであれば、制御はブロック２５１５へ進み、さもなければ、制御はブロック２５２５へ進む。図１１Ｃ及び１４Ａの実施形態を参照すれば、適切な行におけるマッチングプロデューサ列１４１５がアクセスされて、マッチングプロデューサが決定され、そして適切な行における増分的実行列１１８０が各マッチングプロデューサについてチェックされる。
【０３０５】
ブロック２５１５では、アブソービングサブスクリプションが完了とマークされ、制御はブロック２５２０へ進む。図１４Ａの実施形態を参照すれば、適切な行における完了列１４２０が、完了を指示するようにセットされる。
【０３０６】
ブロック２５２０では、ブロック２５０５で選択されたプロデューサが候補プロデューサの現在セットに追加され、そして制御はブロック２５２５へ進む。
【０３０７】
ブロック２５２５では、ブロック２５０５で選択されたプロデューサについてフローが終了となる。
【０３０８】
手続き型言語
上述したように、適切に書かれた手続き型言語、非リフレクティブなオブジェクト指向の言語、及び非リフレクティブなオブジェクトベースの言語コードは、リフレクティブなオブジェクト指向の言語コードへと変換することができる。例えば、あるクラスは、データ構造と、データ構造のインスタンスへのポインタを第１パラメータとして有するスタティックファンクションのセットとを通してエミュレートすることができる。これらファンクションの中には、コンストラクタ及びデストラクタがある。コンストラクタは、データ構造に対するポインタを割り当てた後にランタイムによってインボークされ、データ構造内のエレメントに対するデフォールトを与え、又、デストラクタは、データ構造に対するポインタを解除した後にランタイムによりインボークされる。各クラスは、次のものを含むファイルを通してその記述を有する。１）データ構造；２）クラスを記述し、構造のサイズ及びファンクションに対するポインタのセットを保持する別の構造；３）コードを伴うスタティックファンクションのリスト（非リフレクティブなオブジェクト指向の言語及び非リフレクティブなオブジェクトベースの言語に対して、スタティックファンクションのコードは、リアルクラスのメソッドをスキャンし、そして関連メソッドの有効なインボケーションを遂行するスタティックなファンクションをメソッドごとに生成することにより自動的に発生される）；及び４）各ファンクションの最上部のアノテーション（コメントがプロデューサ依存性宣言を保持する）、及びそれらの形式（コンストラクタ、デストラクタ、プロパティ、等）。手続き型の非リフレクティブなオブジェクト指向又は非リフレクティブなオブジェクトベースの言語におけるクラスのこの定義に加えて、ダイナミックインボケーションも具現化される。より詳細には、コンパイラーは、クラスごとに次のような初期化コード、即ち次のことを行うために（新クラスモジュールにより）一度コールされるコード、を発生する。１）クラスを記述する構造をインスタンス生成し、ファンクションに対するポインタを有効なスタティックファンクションで埋め；２）クラスのマップを伴うこの構造のインスタンス（クラス追跡構造）をクラス名に対応するキーで登録し；及び３）ファンクションのマップにおけるファンクションに対する全ポインタ（メソッド追跡構造）をファンクション名に対応するキーで登録する（ArgumentDependencies、SequencingDependencies、FieldDependencies、UpwardDependencies、WeaklyConstrainedDependencies、出力クラスキー、及び付加的なアノテーションと共に）。マッピングは、次のことを実行できる一般的なインボケーションファンクションの、ランタイムにおける具現化を許す。１）クラスのインスタンスを名前で（新インスタンスモジュールで）インスタンス生成し（より詳細には、ランタイムは、ａ）データ構造のサイズに基づいてメモリを割り当て、クラスを記述する構造に対するポインタを記憶するためにポインタにヘッダを追加し、それ故、スマートポインタ（例えば、それらの形式を問合せできるポインタ）を具現化し）；及びｂ）マップからスタティックファンクションに対する関連ポインタを検索した後に適切なコンストラクタファンクショ��をインボークし）；及び２）マップからスタティックファンクションに対する関連ポインタを検索した後に全てのパラメータが適切にパスしたとすればメソッドを名前でインボークする。ファンクションに対するポインタで識別されたファンクションにパラメータを適切にパスすることは、アッセンブリ言語や、入力及び出力パラメータに対するスタックへの／からのプッシュ及びポップエレメントを通して行われる。上述したメソッドは、データ構造の観念の存在、及び手続き型の非リフレクティブなオブジェクト指向又は非リフレクティブなオブジェクトベース言語におけるファンクションに対するポインタの観念の存在を仮定している。
【０３０９】
例示的なオブジェクト指向のソースコードシンタックス
Ａ．クライアントコード
本発明の一実施形態では、クライアントコードは、次のようなシンタックスをとる（ヘッダ形態で示す）
ProducerKey
New (String ClassKey, InstanceKey InstanceKey, String MethodKey);
Rumtime
New       ()
AddProducerOfInterest     (ProducerKey ProducerOfInterestKey);
SetProducerOutput    (ProducerKey ProducerToOverrideKey, Object
ProducerOutputInstance);
Execute    ();
【０３１０】
ProducerKey及びRuntimeは、クラスであるが、New、AddProducerOfInterest、SetProducerOutput、及びExecuteは、メソッドである。AddProducerOfInterestは、テーブル２の問題とするプロデューサの状態に対して適切な値をもつ新プロデューサコマンドのインボケーションを生じさせる。ProducerOutputInstanceは、オーバーライドされたプロデューサ出力クラスのインスタンスである。従って、これは、対応するプロデューサ出力クラスコンストラクタを通してインスタンス生成される。
【０３１１】
Ｂ．ステートメント
１．依存性宣言ステートメントシンタックス
argumentDependency＝”Argument1Dependency; Argument2Dependency;...”
fieldDependency＝”FieldDependency1; FieldDependency2:...”
sequencingDependency＝”SequencingDependency1; SequencingDependency2;...”
upwardDependency＝”UpwardDependency1; UpwardDependency2;...”
weaklyConstrainedDependency＝”WeaklyConstrainedDependency1; WeaklyConstrainedDependency2;...”
unConstrainedDependency＝”unConstrainedDependency1; unConstrainedDependency2;...”
【０３１２】
２．依存性シンタックス
ａ．fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#C: ClassKey'::#I;'InstanceKey'::#M:'MethodKey'
ｂ．argumentXDependencyシンタックス：
AerumentID::#C:'ClassKey'::#I:'InstanceKey'::#M:'MethodKey'
本発明の一実施形態では、ArgumentIDがシンタックスにおいて省略され、そしてargumentDependenciesが宣言される順序は、ArgumentIDを表す。従って、信頼性を向上させるために、ArgumentIDが追加される。
【０３１３】
３．ショートカット及び非ショートカット
シンタックスは、非ショートカットの場合と同じであるが、プロデューサキーがショートカットを指示する前には＃Ｓ：：を使用する。
ａ．fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#S::#C: ClassKey'::#I;'InstanceKey'::#M:'MethodKey'
ｂ．argumentXDependencyシンタックス：
AerumentID::#S::#C:'ClassKey'::#I:'InstanceKey'::#M:'MethodKey'
この場合に、依存性により指示されるプロデューサキーは、依存性決定プロデューサではない。他のシンタックス具現化は、ショートカットが、ある依存性形式（例えば、フィールド）に対するデフォールト依存性であると仮定し、そして＃Ｓ：：を省略することができる。この場合に、＃ＤＤＰは、ＤＤＰの存在を指示するのに使用できる。
【０３１４】
４．コンティンジェント及び非コンティンジェント
上述したように、＜Ｐ＞は、コンティンジェントなエレメントの前に入れることができる。
ａ．コンティンジェントクラス及びメソッドの例
１）fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#C:<P>'ClassDeterminationMethodKey'::#I:'InstanceKey'::#M:
<P>'MethodDeterminationMethodKey'
２）argumentXDependencyシンタックス：
ArgumentID::#C:<P>'ClassDeterminationMethodKey'::#I:'InstanceKey'::#M
M:<P>'MethodDeterminationMethodKey'
ｂ．コンティンジェントメソッドの例
１）fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#C:'ClassKey'::#I:'InstanceKey'::#M:
<P>'MethodDeterminationMethodKey'
２）argumentXDependencyシンタックス：
ArgumentID::#C:'ClassKey'::#I:'InstanceKey'::#M
<P>'MethodDeterminationMethodKey'
ｃ．コンティンジェントインスタンスの例
１）fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#C:'ClassKey'::#I:<P>'InstanceDeterminationMethodKey'::#M:
'MethodKey'
２）argumentXDependencyシンタックス：
ArgumentID::#C:'ClassKey'::#I
<P>'InstanceDeterminationMethodKey'
【０３１５】
５．ショートハンド技術
親プロデューサエレメントと同一であると考えられるクラス、インスタンス又はメソッドのようなエレメントは、省略される。これは、典型的に、ショートカットフィールドに対するケースである。以下の例は、ショートハンド技術とショートカット宣言とを結合する（ショートカットは、＃Ｓ：:で示される）。
ａ．クラス及びインスタンスが省略される例
１）fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#S::#M:'MethodKey'
２）argumentXDependencyシンタックス：
ArgumentID::#S::#M:'MethodKey'
ｂ．クラスが省略される例
１）fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#S::#I:'InstanceKey'::#M:'MethodKey'
２）argumentXDependencyシンタックス：
ArgumentID::#S::#I:'InstanceKey'::#M:'MethodKey'
【０３１６】
別の実施形態
添付図面のフローチャートは、本発明の実施形態によって遂行されるオペレーションの特定の順序を示しているが、このような順序は、例示に過ぎない（例えば、別の実施形態では、オペレーションを異なる順序で遂行し、あるオペレーションを結合し、あるオペレーションを重畳し、等々も行える）ことを理解されたい。
【０３１７】
本発明を多数の実施形態について説明したが、当業者であれば、本発明は、ここに述べる実施形態に限定されず、特許請求の範囲の精神及び範囲内で変更及び修正を伴って実施できることが明らかであろう。従って、この説明は、限定のためではなく例示のためのものと考えるべきである。
【符号の説明】
【０３１８】
１００：オブジェクト指向のソースコード
１０２：クラス定義
１０４：所与のメソッド
１０５：実行モード設定
１０６：所与のメソッドに対するプロデューサ依存性宣言
１０８：インスタンス（データ）
１１０：プロデューサ
１１２、１１４：プロデューサのセット
２１０Ａ、２１０Ｉ：オブジェクト指向のアプリケーションコード
２２０：プロデューサグラフ指向のプログラミングサポートを伴うランタイム
３２０：プロデューサ依存性宣言
３２５：プロデューサの現在セット
３３０：ソースプロデューサの出力
３３５：プロデューサグラフ指向のプログラミングサポートを伴うランタイム
３４０：自動プロデューサグラフ発生モジュール
３４５：プロデューサグラフ実行モジュール
３４５１：パラレル化モジュール
３４５３：マルチプロセッシングモジュール
３４５５：マルチスレッディングモジュール
３４５７：ローカル実行モジュール
３５０：ソースプロデューサの出力
３５２：ソースコードにおける独立プロデューサの出力
３５４：オーバーライドされたプロデューサ出力
３６０：プロデューサグラフ指向のプログラミングサポートを伴うランタイム
３６５：自動プロデューサグラフ発生モジュール
３７０：プロデューサグラフ実行モジュール
３８０：プロデューサグラフ構造
３８２：増分的実行マーキング
３８４：プロデューサ出力キャッシング
３９０：オーバーライドプロデューサ出力モジュール
３９２：オーバーライドプロパティプロデューサ出力モジュール
３９４：オーバーライドメソッドプロデューサ出力モジュール
３９６：オーバーライドログ
【図１Ａ】
2010511234.tif 000005
【図１Ｂ】
2010511234.tif 000006
【図１Ｃ】
2010511234.tif 000007
【図１Ｄ】
2010511234.tif 000008
【図１Ｅ】
2010511234.tif 000009
【図２】
2010511234.tif 000010
【図３Ａ】
2010511234.tif 000011
【図３Ｂ】
2010511234.tif 000012
【図４Ａ】
2010511234.tif 000013
【図４Ｂ】
2010511234.tif 000014
【図４Ｃ】
2010511234.tif 000015
【図４Ｄ】
2010511234.tif 000016
【図４Ｅ】
2010511234.tif 000017
【図５Ａ】
2010511234.tif 000018
【図５Ｂ】
2010511234.tif 000019
【図５Ｃ】
2010511234.tif 000020
【図５Ｄ】
2010511234.tif 000021
【図６】
2010511234.tif 000022
【図７Ａ】
2010511234.tif 000023
【図７Ｂ】
2010511234.tif 000024
【図７Ｃ】
2010511234.tif 000025
【図７Ｄ】
2010511234.tif 000026
【図７Ｅ】
2010511234.tif 000027
【図７Ｆ】
2010511234.tif 000028
【図７Ｇ】
2010511234.tif 000029
【図７Ｈ】
2010511234.tif 000030
【図７Ｉ】
2010511234.tif 000031
【図８Ａ】
2010511234.tif 000032
【図８Ｂ】
2010511234.tif 000033
【図８Ｃ】
2010511234.tif 000034
【図８Ｄ】
2010511234.tif 000035
【図８Ｅ】
2010511234.tif 000036
【図８Ｆ】
2010511234.tif 000037
【図９Ａ】
2010511234.tif 000038
【図９Ｂ】
2010511234.tif 000039
【図９Ｃ】
2010511234.tif 000040
【図１０】
2010511234.tif 000041
【図１１Ａ】
2010511234.tif 000042
【図１１Ｂ】
2010511234.tif 000043
【図１１Ｃ】
2010511234.tif 000044
【図１１Ｄ】
2010511234.tif 000045
【図１２】
2010511234.tif 000046
【図１３Ａ−Ｂ】
2010511234.tif 000047
【図１３Ｃ−Ｄ】
2010511234.tif 000048
【図１３Ｅ−Ｆ】
2010511234.tif 000049
【図１３Ｇ−Ｈ】
2010511234.tif 000050
【図１３Ｉ−Ｊ】
2010511234.tif 000051
【図１４Ａ】
2010511234.tif 000052
【図１４Ｂ】
2010511234.tif 000053
【図１４Ｃ】
2010511234.tif 000054
【図１４Ｄ】
2010511234.tif 000055
【図１４Ｅ】
2010511234.tif 000056
【図１５】
2010511234.tif 000057
【図１６】
2010511234.tif 000058
【図１７】
2010511234.tif 000059
【図１８】
2010511234.tif 000060
【図１９】
2010511234.tif 000061
【図２０】
2010511234.tif 000062
【図２１】
2010511234.tif 000063
【図２２Ａ】
2010511234.tif 000064
【図２２Ｂ】
2010511234.tif 000065
【図２３】
2010511234.tif 000066
【図２４】
2010511234.tif 000067
【図２５】
2010511234.tif 000068
【国際調査報告】
2010511234.tif 000069
2010511234.tif 000070
2010511234.tif 000071
2010511234.tif 000072
2010511234.tif 000073
2010511234.tif 000074