JP5354601B2 - プロデューサグラフ指向のプログラミングフレームワークにおけるパラレル化及びインスツルメンテーション - Google Patents

プロデューサグラフ指向のプログラミングフレームワークにおけるパラレル化及びインスツルメンテーション Download PDF

Info

Publication number
JP5354601B2
JP5354601B2 JP2009538644A JP2009538644A JP5354601B2 JP 5354601 B2 JP5354601 B2 JP 5354601B2 JP 2009538644 A JP2009538644 A JP 2009538644A JP 2009538644 A JP2009538644 A JP 2009538644A JP 5354601 B2 JP5354601 B2 JP 5354601B2
Authority
JP
Japan
Prior art keywords
producer
execution
graph
producers
instance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2009538644A
Other languages
English (en)
Other versions
JP2010511233A (ja
Inventor
ファディー シャミエ
エラ エデ
Original Assignee
マーレックス ソシエテ パール アクシオン サンプリフィエ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by マーレックス ソシエテ パール アクシオン サンプリフィエ filed Critical マーレックス ソシエテ パール アクシオン サンプリフィエ
Publication of JP2010511233A publication Critical patent/JP2010511233A/ja
Application granted granted Critical
Publication of JP5354601B2 publication Critical patent/JP5354601B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4494—Execution paradigms, e.g. implementations of programming paradigms data driven
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3404—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for parallel or distributed programming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3495—Performance evaluation by tracing or monitoring for systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4488—Object-oriented
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3428—Benchmarking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Description

本発明の実施形態は、コンピュータの分野に係り、より詳細には、ランタイムでコードをプログラミングして実行する分野に係る。
関連出願への相互参照：適用なし。
オブジェクト指向のプログラミング
オブジェクト指向のプログラミングとは、コンピュータプログラミングパラダイムである。オブジェクト指向のプログラミングの背景にある考え方は、プログラムがファンクションの集合又は単にコンピュータに対するインストラクションのリストとして見える慣習的なビューとは対照的に、コンピュータプログラムが、互いに作用する（オブジェクト又はインスタンスと呼ばれる）個々のユニットの集合より成るものとして見えるというものである。オブジェクトとは、データを、そのデータに対して動作するメソッドと結び付けるための言語メカニズムである。各オブジェクトは、メソッドを通してコールされ、データを処理し、そして結果を他のオブジェクトへ与えることができる。各オブジェクトは、個別の役割又は責任をもつ独立したマシン又はアクターとして見ることができる。
リフレクティブなオブジェクト指向の言語とは、特徴（例えば、クラス、オブジェクト／インスタンス、継承、リフレクション、等）の特定セットを有するプログラミング言語であるが、リフレクティブなオブジェクト指向の言語は、これらの特徴のあるサブセット（例えば、オブジェクト）を有するプログラミング言語をラベリングするのに時々使用される。本書の目的上、「オブジェクト指向のソースコード」及び「オブジェクト指向のコード」という句は、このような特徴を有する言語で書かれたコード（例えば、リフレクティブなオブジェクト指向の言語で書かれたコード、リフレクティブなオブジェクトベースの言語で書かれたコード）を指すのに使用される。手続き型言語、非リフレクティブなオブジェクト指向の言語、及び非リフレクティブなオブジェクトベースの言語は、典型的にこのような特徴をサポートしないプログラミング言語であるが、変換技術を使用して、このような特徴を（例えば、エミュレーションにより）このような言語で適切に書かれたコードに与えることができ、従って、このような技術は、このような言語をリフレクティブなオブジェクトベースの言語又はリフレクティブなオブジェクト指向の言語へ変換する。（これらの技術は、オブジェクト指向又はオブジェクトベースの言語の全ての特徴をエミュレートする必要がなく、本書の残り部分に対して問題となる特徴のみをエミュレートすればよい。）又、本書の目的上、「オブジェクト指向のソースコード」及び「オブジェクト指向のコード」という句は、このように変換された手続き型言語、非リフレクティブなオブジェクト指向の言語、及び非リフレクティブなオブジェクトベースの言語のコードを指すのにも使用される。例えば、これに限定されないが、本書は、主として、リフレクティブなオブジェクト指向の言語で書かれたオブジェクト指向のソースコードについて記述する。又、オブジェクト及びインスタントという語は、ここでは、交換可能に使用する。
オブジェクト指向のプログラミングに主として使用されるメソッドという語は、クラスに排他的に関連したコードの断片（クラスメソッド、スタティックメソッド、又はファクトリメソッドと称される）又はオブジェクトに排他的に関連したコードの断片（インスタンスメソッドと称される）を指す。手続き型プログラミング言語の手続きと同様に、メソッドは、通常、アクションを遂行する一連のステートメント、これらアクションをパラメータ化するための入力パラメータのセット、及びおそらく、返送されるある種の出力値で構成される。
プログラマーがオブジェクト指向の言語を使用してプログラムを書くときに、得られるコードは、概念的には、４つの基本的形式のコードを含むものとして見ることができる。第１の形式は、入力インスタンス（１つ又は複数）に対して動作して出力インスタンス（１つ又は複数）を与えるコマンド（ここでは、「変換」コードと称される）を含み、これは、典型的に、メソッド（ここでは、「変換」メソッドと称される）として書かれる。第２の形式は、ランタイム(runtime)がクラスのインスタンスをインスタンス生成するようにさせるインスタンスインスタンス生成コマンド（ここでは、「インスタンスインスタンス生成」コードと称される）を含む。第３の形式は、前記インスタンスのプロパティメソッド（アクセッサ、ミューテータ、等）をインボークするためのプロパティ操作コマンド（ここでは、「データ準備」コードと称される）を含む。第４の形式は、適切なインスタンス（適切なインスタンスとは、引数として使用するためのインスタンス、インスタンスメソッドにより使用されるインスタンス、及びクラスメソッドにより使用されるメタクラスインスタンスを含む）を使用してメソッドインボケーションシーケンスを生じさせて、インボークすべきどんなインスタンスのどんな変換メソッドを、どの順序で、且つデータ準備コードによってなされた変化に応答してどのインスタンスのどのパラメータで指定するかの一連のコマンド（ここでは、「手動インボケーションシーケンス」コードと称される）を含む。手動インボケーションシーケンスコードは、時々、変換メソッドとは個別のメソッドとして書かれ、従って、手動インボケーションシーケンスコードは、変換メソッドに対する一連のインボケーションコマンドを含む。プログラムは、典型的に、データ準備コードと手動インボケーションシーケンスコード（これは、インスタンスインスタンス生成コードへとディップすることもある）との間で繰り返され、これは、次いで、変換コードをインボークする（これも、インスタンスインスタンス生成コード及びデータ準備コード形式へとディップすることがある）。これは、プログラムの概念的表現であり、従って、プログラムをどのように見るかについて絶対的なものと考えてはならないことに注意されたい。
ランタイム
ここで使用するランタイム(runtime)という語は、同じ及び／又は異なる言語で書かれた他のコードを実行する基本的コードのプログラム又はライブラリーを指す。従って、ランタイムは、オペレーティングシステムで動作して、数学的ファンクション、入力及び出力のようなファシリティを与えることを含めて、その実行中にプログラムをサポートするユーティリティファンクションの集合である。これは、プログラマーが、プログラミング言語で指定されるか又はオペレーティングシステムによって与えられた基本的能力を常時再書き込みするのを不要にする。ランタイムとオペレーティングシステムとの間の境界はぼやけているので、ここで使用するランタイムという語は、オペレーティングシステムとは個別のコード及び／又はオペレーティングシステムの一部であるコードを指すものとする。
ＦＯＲＴＲＡＮの場合のような初期のランタイムは、数学的オペレーションのような特徴を与える。他の言語は、より精巧な特徴、例えば、メモリガベージ収集を、オブジェクトに対するサポートにしばしば関連して追加する。より最近の言語は、著しく多くのファンクションを伴う著しく大きなランタイムを有する傾向がある。多くのオブジェクト指向の言語は、「ディスパッチャー」及び「クラスローダー」として知られているシステムも含む。Ｊａｖａ(登録商標)バーチャルマシン（ＪＶＭ）は、このようなランタイムの一例であり、ポータブルバイナリーＪａｖａプログラム（バイト−コード）をランタイム（run time）時に解釈又はコンパイルする。共通言語ランタイム（ＣＬＲ）フレームワークは、ランタイムの別の例である。
プログラミング及び実行フレームワーク
アプリケーションがエンドユーザに与えられるところの１つのフレームワークは、３つの基本的区分を含む。第１の区分は、オペレーティングシステム及びランタイムの生成を含む。この第１の区分は、非常に高度なプログラミングスキルをもつプログラマーにより遂行される。この区分で働くときには、プログラマーは、各々、オペレーティングシステムプログラマー及びランタイムプログラマーと称される。オブジェクト指向の言語に対してランタイムを生成するときに、ランタイムプログラマーは、変換コード、インスタンスインスタンス生成コード、データ準備コード、及び手動インボケーションシーケンスコードに使用される種々の形式のコマンド（例えば、インスタンスインスタンス生成コマンド、データ準備コマンド、及びメソッドインボケーションコマンド）を実行するためのサポートを含む。
第２の区分は、ランタイムにより実行されるオブジェクト指向のアプリケーションソースコードの生成を含む。この第２の区分も、非常に高度なプログラミングスキルをもつと共にアプリケーションのビジネス目標を理解するプログラマーによって遂行される。この区分で働くときには、プログラマーは、アプリケーションプログラマーと称される。オブジェクト指向のプログラミング言語でアプリケーションを生成するときに、アプリケーションプログラマーは、生成される特定のアプリケーションに対して、特定の変換コード、インスタンスインスタンス生成コードデータ準備コード、及び手動インボケーションシーケンスコードを書き込む。これの一部分として、アプリケーションがグラフィックユーザインターフェイスを要求する場合には、アプリケーションプログラマーは、特定のアプリケーションに対してグラフィックユーザインターフェイスの設計及びコード化も行い、従って、アプリケーションデザイナーとも称される。
第３の区分は、ランタイムによって実行されているアプリケーションプログラムの使用を含む。この第３の区分は、プログラミングスキルを必要としないエンドユーザによって遂行される。
手動インボケーションシーケンスコード
アプリケーションの生成に典型的に関連した最大のコストは、手動インボケーションシーケンスコードのデバッグ及び／又は最適化を含む。データを変更する機会のたびに、アプリケーションプログラマーは、その効果を考慮し、そして適切なインスタンスの適切な変換メソッドを適切な入力により適切な順序でインボークさせるように手動インボケーションシーケンスコードを書かねばならない。アプリケーションプログラマーによりなされるミステークは、例えば、１）適切なインスタンスの適切な変換メソッドを誤った順序でインボークすること、２）あるデータが変更されるのに応答して、１つ以上の要求されたインスタンス変換メソッドをインボークさせるコマンドを含ませるのを忘れること、３）あるデータが変更されるのに応答して、不必要なインスタンス変換メソッドをインボークさせるコマンドを含ませること（例えば、データの変更による影響のないインスタンスの変換メソッドをインボークするコマンドを含ませること）、等を含む。
例えば、手動インボケーションシーケンスコードを発生する１つの技術は、オブザーバーパターン（時々「パブリッシュ・サブスクライブ(publish subscribe)」としても知られている）を使用して、プログラムにおけるインスタンスの状態を観察することである。オブザーバーパターンでは、１つ以上のインスタンス（オブザーバー又はリスナーと呼ばれる）が登録され（又はそれら自体を登録し）、観察されたオブジェクト（主題）により起り得る事象を観察する。ある事象を生じ得る観察されたインスタンスは、一般に、登録されたオブザーバーの集合を維持する。事象が生じると、各オブザーバーは、観察されたインスタンスからのコールバックを受け取る（観察されたインスタンスは、登録されたオブザーバーにおいて「通知(notify)」メソッドをインボークする）。この通知ファンクションは、オブザーバーによって使用できる幾つかのパラメータ（一般的に、発生する事象に関する情報）をパスすることができる。各オブザーバーは、通知ファンクションを具現化し、その結果、通知が生じるときにそれ自身の振舞いを定義する。
観察されたインスタンスは、典型的に、新たなオブザーバーを追加するための登録メソッドと、事象が生じたときに通知されるべきインスタンスのリストからオブザーバーを除去するための非登録メソッドとを有する。更に、観察されたインスタンスは、多数の関連更新の非効率的なカスケード化を防止するために一時的にディスエイブルし、次いで、再イネーブルするためのメソッドも含むことができる。より詳細には、プロパティ値の変化に応答してコールされるコールバックは、しばしば、幾つかの他のプロパティの値も変化させ、付加的なコールバックをトリガーし、等々である。
オブザーバーパターン技術を使用するときには、手動インボケーションシーケンスコードを書くアプリケーションプログラマーは、観察される異なるインスタンスに対してオブザーバーを登録し、非登録とし、ディスエイブルし及び再イネーブルすると共に、各々について通知及びコールバックメソッドを書き込むことにより、どんなインスタンスのどんなメソッドをどの順序で且つどの入力でコールするか指定する。より詳細には、オブザーバーと、観察されるインスタンスとの関係は、オブザーバーパターン内でローカルに管理され（観察される他のインスタンスと同期せずに、観察されるインスタンスのみにより）、従って、観察される複数のインスタンスからの事象と同期する必要のある手動インボケーションシーケンスコードは、典型的に、各オブザーバーの特定のコールバックメソッドの一部分である。
オーバーライティング・揮発性コールスタック
典型的なランタイム(runtime)は、オーバーライティング・揮発性コールスタックを使用して、現在インボークされている未完了のコールを追跡する。オーバーライティング・揮発性コールスタックは、各コールが完了すると、ポップオフしてエントリーを破棄するという点でオーバーライティングであり、且つ実行のたびに破棄されて再構築されるという点で揮発性である。典型的なランタイムがオーバーライティング・揮発性コールスタックを使用するのは、典型的なランタイムが、オーバーライティング・揮発性コールスタックを構築することを、手動インボケーションシーケンスコードの実行に応答して適切な入力で適切なインスタンスの適切な変換メソッドを実際にインボークすることと結合するからである。要約すれば、手動インボケーションシーケンスコードの実行に応答して、典型的なランタイムは、インスタンスシーケンスの変換メソッドをコールごとに（各コールがなされるときに）決定し、そして現在インボークされている未完了のコールのみを追跡するようにオーバーライティング・揮発性コールスタックを維持する。
プログラム実行及びパラレル化
従来、プログラムにおけるメソッドは、手動インボケーションシーケンスコードに基づき逐次に実行される。実行の効率及び速度を改善するために、あるメソッドは、パラレル化をサポートするシステムにおいてパラレルに実行することができる。一般的に、コンピューティングにおけるパラレル化は、複数のプロセス、タスク又はスレッドを同時に実行することである。パラレル化を具現化するために、アプリケーションプログラマーは、パラレルに実行することが望まれるメソッドを識別し、次いで、その識別されたメソッドをパラレルに実行させるように手動インボケーションシーケンスコードを書き直すことができる。
現在、コンピューティングにおいてサポートされる共通のパラレル化メカニズムは、マルチプロセッシング及びマルチスレッディングを含む。マルチプロセッシングでは、アプリケーションプログラムが、典型的に、複数のタスクに分割される。各タスクは、プロセッサにより実行できる計算作業の、論理的に高レベルの、個別の、独立した区分である。パラレル化を達成するために、少なくとも幾つかのタスクが、複数のプロセッサにおいて同時に実行される。プロセッサは、ネットワークを経て互いに結合され、集合的にグリッドと称される。グリッド内のプロセッサは、ローカルプロセッサ、遠隔プロセッサ、又はその両方の組合せを含むことができる。
マルチプロセッシングに加えて、別の共通のパラレル化メカニズムは、マルチスレッディングである。スレッドは、タスクを実行するためのローカルプロセスである。マルチスレッディングをサポートするプロセッサは、複数のスレッドを実質的に同時に実行することができる。このようなプロセッサの一例は、マルチコアプロセッサであり、マルチコアプロセッサの各コアは、スレッドを実行することができる。
例えば、パラレル化における１つの従来の技術は、アプリケーションプログラムのソースコードを分析して、アプリケーションプログラムのコンフィギュレーションを抽出することである。このコンフィギュレーションに基づいて、アプリケーションプログラムは、多数のサブプログラムへ分割され、これらサブプログラムは、サブプログラムの親子関係に基づいてグラフで表わされる。これらサブプログラムは、サブプログラムの親子関係に基づいてパラレルに実行される。
ある従来のコンピューティングシステムにおいては、ソースコードから発生された中間コードの分析を行って、パラレル化を達成することができる。例えば、中間コード（例えば、アッセンブリ言語）の分析及びパラレル化は、コンパイル中に行われる。コンパイラーのパラレライザーは、中間コードを、パラレルに実行可能な形態へ変換する。実行順序デターミナーは、実行される基本的ブロックの順序を決定する。拡張された基本的構築ブロックパラレライザーは、基本的構築ブロックを、パラレルに実行可能なインストラクションで各々形成された実行ユニットへ細分化する。依存性の分析は、インストラクションベースで行われる。
しかしながら、上述した従来の技術は、全て、アプリケーションプログラマーによって書かれたアプリケーションプログラムにおける手動インボケーションシーケンスコードの分析を要求する。従って、パラレル化を正しく遂行するために手動インボケーションシーケンスコードを書くときには相当の注意を払わねばならないので、パラレル化の負担がアプリケーションプログラムに乗せられる。従って、アプリケーションプログラマーは、比較的高いレベルのプログラミングスキルをもつ必要がある。
アプリケーションプログラマーのジョブを容易にするため、高レベルのプログラミングスキルを必要とせずにアプリケーションプログラムのパラレル化を遂行する幾つかの従来技術が開発されている。例えば、逐次プログラムをパラレルに実行するために、普通のデータ形式の周りの特殊な言語構造及び特殊なラッパークラスが設けられる。プログラマーは、プログラムの各部分のパラレル実行を行うために「パラレルプログラム」を書くことが要求されない。パラレル手続き識別子及びその引数をシステムに対して指定することにより発呼点においてパラレル手続きが指定される。異なる部分をパラレルに実行するための実行パラレルファンクションが設けられる。パラレル手続きは、プログラムにおける各パラレル手続きに対応する共通クラスから新たなクラスを導出させることにより書くことができる。システムは、ランタイム(run time)時における依存性を解明し、実際の依存性に遭遇するレベルでパラレル化が行われる。コンパイラーは、パラレル手続きの制御フローグラフの分析によりパラレル手続きにおいて引数を変更できるかどうか決定することができる。
従来の別のコンピューティングシステムにおいては、コンピュータプログラム自体における全てのパラレルサポートをハードコード化する必要なく、アプリケーションプログラムにおけるユーザ定義ファンクションを実行するのにデータベースマネージャーが使用される。ユーザがパラレルに実行することを望むインストラクションでデータベースが定義される。次いで、テーブル内のインストラクションを実行するユーザ定義ファンクションが定義される。データベースマネージャーは、ユーザ定義ファンクションにおいて複数のタスクをパラレルに実行することによりパラレル化を与える。
ソフトウェアインスツルメンテーション
一般的に、ソフトウェアインスツルメンテーションとは、１つ以上のアプリケーションプログラムの振舞いを監視し、そしてアプリケーションプログラム及びその実行に関連したメトリックを収集する技術を指す。従って、シフトウェアインスツルメンテーションは、アプリケーションプログラム及びアプリケーションプログラムの実行を、アプリケーションプログラムの振舞い及び収集したメトリックに基づき種々の仕方で改善できるので、アプリケーションプログラムの開発及びメンテナンスにおいて貴重なツールである。
現在、ソフトウェアインスツルメンテーションを具現化するために種々の技術が開発されている。例えば、１つの技術は、アプリケーションプログラムの実行経歴を記録するためのソフトウェアモジュール又はコードを追加し、記録された実行経歴に基づいてアプリケーションプログラムの将来の実行を管理できるようにすることである。別の実施例では、コンパイラーが、メトリックを監視し及び収集するためのインストラクション及びメタデータを発生する。選択されたインジケータがインストラクションに関連している場合には、インストラクションの実行に関連した事象のカウントを行うことができる。次いで、インストラクションが実行された回数がカウントされる。アプリケーションプログラムを実行した後に、性能改善方法を決定するためのホットスポットが識別され、従って、その性能改善方法を具現化するように、アプリケーションプログラムのソースコードを変更することができる。
インスツルメンテーションにおける従来の別の技術は、アプリケーションプログラムのソースコードから発生された中間表現（ＩＲ）データを使用することである。より詳細には、コンパイラーが、ソースコードからＩＲデータを発生する。コードインスツルメンテーションモジュールは、ＩＲデータに作用して、ＩＲツリーを構成すると共に、ＩＲツリーに基づいてＩＲデータにインスツルメンテーションを追加する。次いで、コンパイラーは、インスツルメンテーションを伴うＩＲデータをオブジェクトコードへ変換することによりコンパイルを終了する。インスツルメンテーションライブラリー（以下、インスツルメンテーションＤＬＬ)を使用して、クラスインスタンスをインスツルメント化することができる。バーチャルマシン（ＶＭ）ランタイムモジュールが、そのインスツルメント化されたクラスインスタンスを実行する。クラスインスタンスのバイトコードにおいてメソッドの名前及びパラメータの宣言が存在する。宣言されたメソッドに対応する実行可能な部分がＶＭランタイムモジュールとは個別のネーティブコードの幾つかのブロックに見出されることを特殊な指示子が指示する。例えば、インスツルメント化されたＪａｖａＶＭバイトコードは、実行中にモニタプロセス及びモニタライブラリー（モニタＤＬＬとしても知られた）により監視することができる。
オブジェクト関連マッピング
オブジェクト関連マッピングとは、関連データベースをオブジェクト指向の言語概念にリンクして「バーチャルオブジェクトデータベース」を（実際に）生成するプログラミング技術である。あるオブジェクト関連マッパーは、メモリにロードされるインスタンスを自動的にデータベースと常時同期状態に保持する。より詳細には、オブジェクト・対・ＳＱＬマッピング問合せを構成した後、最初に返送されるデータが、オブジェクト−ＳＱＬマッピングパッケージと同様に、当該インスタンスのフィールドにコピーされる。そのようになると、インスタンスは、これらの値が変化するかどうか調べるために監視し、次いで、データをデータベースに書き戻すためにプロセスを慎重に逆転しなければならない。
Ｈｉｂｅｒｎａｔｅ３．０は、Ｊａｖａ及びＣＬＤ（ジョージア州アトランタのＪｂｏｓｓ（登録商標）インク）に対するオブジェクト関連マッピング解決策である。従って、Ｈｉｂｅｒｎａｔｅは、オブジェクト指向のドメインモデルを慣例的な関連データベースへマッピングするためのフレームワークを与える。その目標は、ある共通のデータ持続性に関連したプログラミングタスクから開発者を救援することである。Ｈｉｂｅｒｎａｔｅは、クラスからデータベーステーブルへの（及びオブジェクト指向のデータ形式からＳＱＬデータ形式への）マッピングを取り扱うと共に、データ問合せ及び検索ファシリティを与える。Ｈｉｂｅｒｎａｔｅは、インスタンス中心であり、インスタンス間の関係を表すグラフを構築する。
制御の逆転及び依存性逆転原理
ＩＯＣとしても知られている制御の逆転は、コンピュータプログラムに本来ある結合（各プログラムモジュールが互いに他のモジュールに依存する程度）を減少するのに使用できるオブジェクト指向のプログラミング原理である。ＩＯＣは、依存性逆転原理としても知られている。ＩＯＣにおいて、次のいずれかに該当する場合、即ち、１）クラスＸがクラスＹを有して、それにコールするか、２）ＸがＹであるか、又は３）ＸがあるクラスＺに依存し、これがＹに依存する（推移性の）場合に、クラスＸがクラスＹに依存する。ＸがＹに依存することは、ＹがＸに依存することを意味せず、即ち両方が真となる場合にはサイクリック依存性と称され、ＹなしにＸを使用することはできず、又、その逆ことも言えることに注意する価値がある。
実際に、（クラスＸの）オブジェクトｘが、（クラスＹの）オブジェクトｙのメソッドをコールする場合には、クラスＸがＹに依存する。第３のクラス、即ちｘがｙをコールし得る全てのメソッドを含まねばならないインターフェイスクラスＩを導入することにより、依存性が逆転される。更に、Ｙは、それがインターフェイスＩを具現化するように変更されねばならない。ここで、Ｘ及びＹの両方がインターフェイスＩに依存し、クラスＸは、もはやクラスＹに依存しない（ＸがＹをインスタンス生成しないと仮定すれば）。インターフェイスＩを導入することによりＹに対するクラスＸの依存性をこのように排除することは、制御の逆転（又は依存性逆転）であると言える。Ｙは、他のクラスに依存してもよいことに注意されたい。変換が適用される前に、ＸはＹに依存し、従って、Ｘは、Ｙが依存する全てのクラスに間接的に依存する。制御の逆転を適用することにより、これら全ての間接的依存性も崩壊される。新たに導入されるインターフェイスＩは、何物にも依存しない。
スプリングフレームワークは、ＩＯＣ及び依存性逆転を使用するＪａｖａプラットホームに対するオープンソースアプリケーションフレームワークである。より詳細には、スプリングフレームワークの中心は、Ｊａｖａオブジェクトを構成し及び管理する手段をなす制御逆転コンテナである。このコンテナは、ＢｅａｎＦａｃｔｏｒｙ、ＡｐｐｌｉｃａｔｉｏｎＣｏｎｔｅｘｔ又はＣｏｒｅコンテナとしても知られている。このコンテナのオペレーションは、例えば、オブジェクトを生成し、オブジェクトを構成し、初期化メソッドをコールし、そして登録されたコールバックオブジェクトにオブジェクトを通すことである。コンテナにより生成されたオブジェクトは、管理オブジェクト又はビーンとも呼ばれる。典型的に、コンテナは、ビーン定義を含むＸＭＬファイルをロードすることによって構成される。これらは、オブジェクトを生成するのに必要な全ての情報を与える。エラー状態を生じることなくオブジェクトが生成されて構成されると、それらが使用できるようになる。オブジェクトは、依存性ルックアップ又は依存性注入により得ることができる。依存性ルックアップは、発呼者が特定の名前又は特定形式のオブジェクトについてコンテナオブジェクトに尋ねるパターンである。依存性注入は、コンテナが、コンストラクタ、プロパティ又はファクトリメソッドのいずれかを経て、オブジェクトを名前によって他のオブジェクトへ通すパターンである。従って、スプリングフレームワークは、メモリ中心であり、インスタンス間の関係を表すグラフを構築する。
グラフツール
ＪａｖａｄｏｃTMは、Ｊａｖａソースファイルのセットにおける宣言及びドキュメンテーションコメントを構文解析し、そしてパブリック及び保護クラス、ネスト状クラス（匿名の内部クラスではない）、インターフェイス、コンストラクタ、メソッド、及びフィールドを（デフォールトにより）記述するＨＴＭＬページの対応セットを発生するツールである（カリフォルニア州サンタクララのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）インク）。Ｊａｖａｄｏｃは、ソースファイルのセットに対してＡＰＩ（アプリケーションプログラミングインターフェイス）ドキュメンテーション又は具現化ドキュメンテーションを発生するのに使用できる。又、Ｊａｖａｄｏｃは、クラス及びメソッド中心であり、クラス及びそれらのメソッドの組合せ間の関係を表すグラフを構築する。
ソフトウェアアプリケーションを設計するための別のシステムは、コンピュータアプリケーションを表現し及び再生するためにインタープリターにより分析されたオブジェクトのグラフを含む。このシステムは、コードライブラリに記憶された予め書かれたプログラミングクラスを使用し、これは、１９９５年、Addison Wesley、Gamma氏等による“Design Patterns”、１９９８年、Wiley Computer Publishing、Grandによる“Patterns in Java”、及び／又は高レベルのコンピュータ支援型ソフトウェアエンジニアリング（ＣＡＳＥ）ツールに記載された設計パターンに従うように書くことができる。より詳細には、幾つかのこのようなクラスは、オブザーバーの振舞いパターンに基づく。予め書かれたコードのライブラリーは、アプリケーション状態ノード、処理ロジック、及び種々のアプリケーション状態間のシステムのデータ流（即ち、アプリケーションの予め書かれたデータエレメント）を表し、ソフトウェアアプリケーションを生成するときに、ユーザがコードを書き込み、編集し又はコンパイルする必要がないようにする。むしろ、ユーザは、アプリケーション状態ノード内のデータ又はアプリケーション状態ノード内で遂行されるプロセスのような、現在アプリケーション状態ノードに関連した視覚的オブジェクトを編集することにより、グラフィックユーザインターフェイスにおいてソフトウェアアプリケーションを手動で編集する。次いで、現在アプリケーション状態ノードに対してユーザによりなされた変化に基づき、インタープリターは、丁度編集されたアプリケーション状態に対して、更新されたアプリケーション状態をユーザに表示する。システムは、次いで、ユーザ定義された移行エッジに沿って別のアプリケーション状態へ移行することができ、そこで、ユーザは、次のアプリケーション状態又は移行エッジを任意に編集することができる。グラフに対する変更は、ソフトウェアアプリケーションが実行されている間にインタープリターにより具現化されるグラフのインスタンスに対して行うことができる。
ソフトウェアアプリケーションを設計するためのこのシステムは、アプリケーションコントローラで「使用可能」にすることができる実行中のソフトウェアアプリケーションの視覚的表現を含む。実行中のソフトウェアアプリケーションを表す視覚的オブジェクトをユーザが変更するときには、コントローラが入力を使用して、インタープリターがグラフに対する変更を行うよう誘導する。次いで、コントローラは、より多くの変更を待機する。更に、このようなソフトウェアアプリケーションの視覚的表現を、アプリケーション、ひいては、ソフトウェアアプリケーションの視覚的表現を記述するＸＭＬドキュメントとしてインポート又はエクスポートすることができる。
ノード、指令されたエッジ及びアプリケーション状態の視覚的表現の形態でソフトウェアアプリケーションを編集し及び／又は生成するために、アプリケーションプログラムインターフェイス及びアプリケーションエディタをシステムに更に含ませることができる。予め書かれたコードライブラリからのキーワード及び関連定義は、アプリケーション開発者が、実際のアプリケーション構造に厳密に相関したグラフアプリケーションのグラフ的表現をエディタ内に設けることにより、ソフトウェアアプリケーション、処理ステップ、及びソフトウェアアプリケーションの視覚的表現を手動で定義することができるようにする。ユーザは、「アプリケーション定義ウイザード」を通して新たなアプリケーションを定義し、このウイザードは、ある事前の事柄が満足された後に、新たなアプリケーションをエディタワークスペース内のグラフコンポーネントとして表示する。ユーザは、更に、予め生成された考えられるアプリケーションコンポーネントの表示されたリストから選択を行い、そしてＰＣのマウス及びキーボードを使用してワークスペース上でコンポーネントをドラグしてドロップすることにより、アプリケーションと対話する。ユーザは、コンポーネントを選択し、それらを既存のコンポーネントの上に「ドラグ」することができる。新たなコンポーネントが既存のコンポーネント上に「ドロップ」されると、新たなコンポーネントは、アプリケーショングラフ内で既存のコンポーネントの子となる。アプリケーション内のコンポーネントの関係は、エディタ内でのユーザ選択により手動で定義される。従って、アプリケーションを表すツリー構造がユーザによって構築される。アプリケーションが生成されると、ユーザは、アプリケーションナビゲータビューアを選択して、構成されたアプリケーションのツリービューを表示し、アプリケーションの任意のコンポーネントを選択して編集できるようにする。エディタインターフェイスは、アプリケーションエレメントを生成又は削除し、コンポーネントの属性を更新し、そしてアプリケーションの表示プロパティを更新することを含めて、ユーザ入力及び選択を処理する。
上述したシステムは、ソフトウェアアプリケーションの視覚的表現を使用するが、関連データベースを定義し及び更新するための視覚的プログラミングツールとして使用することもできる。このシステムは、ソフトウェアアプリケーションの視覚的表現のＸＭＬ記述を使用する。ツールは、ＸＭＬ記述を構文解析し及び解釈して、同等の関連データベーステーブルスキーマ及びそれに対する変更を発生する。ソフトウェアアプリケーションの視覚的表現内でデータが変更されたときには、変更の記述が、ジャーナルファイルにおける他の変更と共に記憶され、次いで、グループとして処理される。中間プログラム（それ自身のスレッドで動作するＪａｖａアプリケーション）は、ソフトウェアアプリケーションの視覚的表現と、関連データベースとの間のトランザクションを遂行する。Ｊａｖａアプリケーションは、視覚的表現のノード（即ち、データベースのデータ）に対する変更のジャーナルをポーリングし（即ち、チェックし）、そして変更があった場合に、データベースに対して変更を行う。従って、視覚的表現内のデータを変更することにより、システムは、データベースを更新する。データベースからのデータの要求を取り扱うために、ソフトウェアアプリケーションの視覚的表現とデータベースとの間に同様のアプリケーションが存在する。
ソフトウェアを分析するための別のシステムは、コードツリーアナライザ（ＣＴＡ）と称される。ＣＴＡは、オブジェクト指向のプログラミング言語で書かれたスタティックソースコードを分析する。ＣＴＡは、記号テーブル及びコールツリーをスタティックソースコードから発生する。記号テーブルを使用して、ＣＴＡは、クラスダイアグラムを発生する。同様に、コールツリーを使用して、ＣＴＡは、シーケンスダイアグラムを発生する。クラスダイアグラムは、ユーザ選択クラスと、ユーザ選択クラスに関連したクラスとの間の関係を示す。シーケンスダイアグラムは、異なるメソッドがコールされるシーケンスを示す。クラスダイアグラム及びシーケンスダイアグラムの両方を使用して、ＣＴＡは、スタティックソースコードを表す設計アーティファクトを発生する。ユーザがこの設計アーティファクトを変更するときに、ＣＴＡは、シーケンスダイアグラムを使用して、ソースコードの影響部分を識別する。設計アーティファクトは、スタティックソースコードのコードメンテナンス及び／又は逆行分析(reverse engineering)に使用される。
プロデューサグラフ指向のプログラミングフレームワークにおけるパラレル化及び／又はインスツルメンテーションの実施形態が提供される。一実施形態において、アプリケーションプログラムを実行するための要求が受け取られ、アプリケーションプログラムのオブジェクト指向のソースコードは、メソッド及びプロデューサ依存性宣言を含み、所与のメソッドに対するプロデューサ依存性宣言は、所与のメソッドへの入力である出力を伴う０以上のプロデューサのセットを識別し、プロデューサは、少なくともインスタンスと、そのインスタンスに関連したメソッドである。更に、アプリケーションプログラムの実行は、ランタイムを使用してアプリケーションプログラムのプロデューサ間の依存性に基づいてパラレル化することができる。ある実施形態では、アプリケーションプログラムは、ランタイムを使用してインスツルメント化される。
本発明の実施形態を示した添付図面及び以下の詳細な説明を参照することにより本発明が最も良く理解されよう。
本発明の一実施形態によりオブジェクト指向のソースコードにおけるクラスのメソッドに対するプロデューサ依存性宣言と、所与のインスタンスからのそのメソッドに基づくプロデューサのインスタンスとの関係を示すブロック図である。 本発明の一実施形態によるプロデューサ１１０Ａと親プロデューサ１１４Ａ．１との間の関係を例示する。 本発明の一実施形態によるプロデューサ１１０Ａと子プロデューサ１１２Ａ．１との間の関係を例示する。 本発明の一実施形態による親プロデューサ１１４及び子プロデューサ１１２とプロデューサ１１０Ａとの関係の付加的な組合せを例示する。 本発明の一実施形態により、同じクラスの異なるインスタンスが同じ及び／又は異なるメソッドに基づきプロデューサを有することができることを示す。 本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムの再使用性を示すブロック図である。 本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。 本発明の一実施形態により増分的実行及びオーバーライドされたプロデューサ出力もサポートするプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。 本発明の一実施形態により例示的プロデューサグラフの発見及び構築を示すブロック図である。 本発明の一実施形態により図４Ａのプロデューサグラフの初期の実行を示すブロック図である。 本発明の一実施形態により図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。 本発明の一実施形態により従属プロデューサ２がオーバーライドされた後の図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。 本発明の一実施形態により従属プロデューサ２がオーバーライドされそして独立ソースプロデューサ３が変更された後の図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。 本発明の一実施形態により未解明の依存性を含む例示的プロデューサグラフの発見及び構築を示すブロック図である。 本発明の一実施形態により図５Ａのプロデューサグラフの初期の実行と、未解明の依存性の解明とを示すブロック図である。 本発明の一実施形態により図５Ａのプロデューサグラフの初期の実行及び／又は図５Ｂのプロデューサグラフの再実行を示すブロック図である。 本発明の一実施形態により図５Ａのプロデューサグラフの初期の実行及び／又は図５Ｂ又は５Ｃのプロデューサグラフの再実行を示すブロック図である。 本発明の一実施形態により、ランタイムクライアントの論理的実行フローと、プロデューサグラフ指向のプログラミングサポートを伴うランタイムに対するその関係とを示すフローチャートである。 本発明の一実施形態によりショートカット依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による例示的プロデューサのブロック図である。 本発明の一実施形態により非ショートカット依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示すと共に、例示的プロデューサのブロック図である。 本発明の一実施形態により非ショートカット依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による例示的プロデューサのブロック図である。 本発明の一実施形態により依存性決定プロデューサを伴うUpwardDependencyの使用による例示的依存性を示すブロック図である。 本発明の一実施形態により依存性決定プロデューサを伴うWeaklyConstrainedDependencyの使用による例示的依存性を示すブロック図である。 本発明の一実施形態による標準的プロデューサの例示的プロデューサグラフを示す。 図７Ｈのプロデューサグラフを発見し、解明しそして構築するためのプロデューサ依存性及び依存性決定プロデューサの一例を示す。 本発明の一実施形態によりアプリケーションがエンドユーザに与えられるところの第１の例示的フレームワークを示すブロック図である。 本発明の一実施形態によりアプリケーションがエンドユーザに与えられるところの第２の例示的フレームワークを示すブロック図である。 本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０での自由セル選択の例示的スクリーンショット及び使用を示す。 本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０での自由セル選択の別の例示的スクリーンショット及び使用を示す。 本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０でのテーブル生成の例示的スクリーンショット及び使用を示す。 本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０でのテーブル生成の別の例示的スクリーンショット及び使用を示す。 本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第１のスキームを示すブロック図である。 本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第２のスキームを示すブロック図である。 本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第３のスキームを示すブロック図である。 本発明の一実施形態による例示的具現化のブロック図である。 本発明の一実施形態による図１０のクラス追跡構造１０９２の一例を示すブロック図である。 本発明の一実施形態による図１０のインスタンス追跡構造１０６５の一例を示すブロック図である。 本発明の一実施形態による図１０のプロデューサグラフ構造１０６０の一例を示すブロック図である。 本発明の一実施形態による図１０のメソッド追跡構造１０５８の一例を示すブロック図である。 本発明の一実施形態によりマルチプロセッシングに使用されるシリアル化形態のローカルマップの一例を示すブロック図である。 本発明の一実施形態による図１０のランタイム設定構造１０４８の一例を示すブロック図である。 本発明の一実施形態による図１０のプロデューサベースの構成可能な判断構造１０４９の一例を示すブロック図である。 本発明の一実施形態によりマルチプロセッシングをサポートするための図１０の付加的な細部を示すブロック図である。 本発明の一実施形態によりコンティンジェント及びサブスクリプション形式のダイナミックプロデューサ依存性をサポートするための図１０の付加的な細部を示すブロック図である。 本発明の一実施形態による非ショートカット、非ダイナミック（非コンティンジェント、非サブスクリプション）依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による例示的非ショートカット、非ダイナミック（非コンティンジェント、非サブスクリプション）プロデューサ依存性を示すプロデューサのブロック図である。 本発明の一実施形態による非ショートカット、コンティンジェント、非サブスクリプションのプロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による例示的非ショートカット、コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。 本発明の一実施形態による非ショートカット、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット、コンティンジェント、非サブスクリプションのプロデューサ依存性の両方を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による非ショートカット、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット、コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。 本発明の一実施形態によるショートカット、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット、非コンティンジェント、非サブスクリプションのプロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による例示的ショートカット、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット、非コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。 本発明の一実施形態によるショートカット、非ダイナミック（非コンティンジェント、非サブスクリプション）プロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による例示的ショートカット、非ダイナミックプロデューサ依存性を示すプロデューサのブロック図である。 本発明の一実施形態による図１２のサブスクリプションログ１２５０の一例を示すブロック図である。 本発明の一実施形態による非コンティンジェント、アブソーブサブスクリプションプロデューサ依存性を示す例示的プロデューサのブロック図である。 本発明の一実施形態による非コンティンジェント、スティッキーサブスクリプションプロデューサ依存性を示す例示的プロデューサのブロック図である。 本発明の一実施形態により、スティッキーサブスクリプションにより生成される親依存性決定プロデューサに基づく親プロデューサの選択を示す。 本発明の一実施形態により、シーケンス依存性によりリンクされる子依存性決定プロデューサによって生成される親依存性決定プロデューサに基づく親プロデューサの選択を示す。 本発明の一実施形態により新たなインスタンスをインスタンス生成するためのフローチャートである。 本発明の一実施形態により新たなプロデューサ及び非オーバーライドプロデューサをインスタンス生成するためのフローチャートである。 本発明の一実施形態による図１６Ａのブロック１６２３のフローチャートである。 本発明の一実施形態による図１６Ａのブロック１６５０のフローチャートである。 本発明の一実施形態による図１７のブロック１７４５のフローチャートである。 本発明の一実施形態による図１６Ａのブロック１６３０のフローチャートである。 本発明の一実施形態による図１６Ａのブロック１６３５及び１６７０のフローチャートである。 本発明の一実施形態によりプロデューサをオーバーライドするためのフローチャートである。 本発明の一実施形態によりプロデューサ実行モード設定をオーバーライドするためのフローチャートである。 本発明の一実施形態により実行モード設定をランタイムレベルでグローバルにオーバーライドするためのフローチャートである。 本発明の一実施形態によりプロデューサベースの構成可能な判断構造に基づいて実行モード設定をオーバーライドするためのフローチャートである。 本発明の一実施形態により現在プロデューサグラフを実行するためのフローチャートの一部分である。 本発明の一実施形態により現在プロデューサグラフを実行するためのフローチャートの別の部分である。 本発明の一実施形態による図２２Ａのブロック２２０５に対するフローチャートである。 本発明の一実施形態による図２２Ｂのブロック２２６０に対するフローチャートである。 本発明の一実施形態によりレディプロデューサのセットを実質的にパラレルに実行するためのフローチャートの一部分である。 本発明の一実施形態によりレディプロデューサのセットを実質的にパラレルに実行するためのフローチャートの別の部分である。 本発明の一実施形態によりレディプロデューサのセットを実行する前にデータ構造をインスタンス生成するためのフローチャートの一部分である。 本発明の一実施形態によりレディプロデューサのセットを実行する前にデータ構造をインスタンス生成するためのフローチャートの別の部分である。 本発明の一実施形態によりマルチスレッディングを使用してプロデューサを実行するためのフローチャートである。 本発明の一実施形態によりマルチスレッディングにおけるスレッドの実行を示すフローチャートである。 本発明の一実施形態によりスレッド終了コールバックを取り扱うためのフローチャートである。 本発明の一実施形態によりマルチプロセッシング及びローカル実行を使用してプロデューサを実行するためのフローチャートの一部分である。 本発明の一実施形態によりマルチプロセッシング及びローカル実行を使用してプロデューサを実行するためのフローチャートの別の部分である。 本発明の一実施形態によりマルチプロセッシングされるべきプロデューサの入力及び／又はその基礎となるインスタンスをシリアル化するためのフローチャートである。 本発明の一実施形態による遠隔コンピューティングのためのフローチャートの一部分である。 本発明の一実施形態による遠隔コンピューティングのためのフローチャートの別の部分である。 本発明の一実施形態によるプロデューサのローカル実行のためのフローチャートである。
以下の説明において、本発明をより完全に理解するために、ロジックの具現化、ｏｐコード、オペランドを指定する手段、リソースの区分化／分担／複製の具現化、システムコンポーネントの形式及び相互関係、並びにロジックの区分化／一体化の選択のような多数の特定の細部について述べる。しかしながら、当業者であれば、このような特定の細部を伴わずに本発明を実施できることが明らかであろう。他の点では、本発明を不明瞭にしないため、制御構造、データ構造、及び全ソフトウェアインストラクションシーケンスは、詳細に示さない。当業者であれば、過度の実験を行わなくても、ここに含まれた説明で、適切な機能を具現化することができるであろう。
特に指示のない限り、（分割の破線を除いて）図中の破線は、図中でオプションアイテムを表すのに使用される。しかしながら、破線を使用して全てのオプションアイテムを示すことを想定してはおらず、破線で示されたものは、種々の理由で選択されたものである（例えば、より明瞭にするために、容易に示すことができる、等）。
本明細書において、「１つの実施形態」、「一実施形態」、「例示的な実施形態」、等は、ここに述べる実施形態が、特定の特徴、構造又は特性を含むが、各々の実施形態が、必ずしも、特定の特徴、構造又は特性を含まなくてもよいことを指示する。更に、このような句は、必ずしも、同じ実施形態を指すものではない。更に、特定の特徴、構造又は特性が、ある実施形態に関連して説明されるときには、他の実施形態が明確に説明されるかどうかに関わらず、他の実施形態に関連してこのような特徴、構造又は特性に作用を及ぼすことも、当業者の知識の中でなし得るものとする。
以下の説明及び特許請求の範囲において、「結合(coupled)」及び「接続(connected)」という語は、その派生語と共に、使用することができる。これらの語は、互いに類義語として意図されないことを理解されたい。むしろ、特定の実施形態において、「接続」は、２つ以上のエレメントが互いに物理的又は電気的に直接接触することを示すのに使用される。「結合」は、２つ以上のエレメントが直接物理的又は電気的に接触していることを意味する。しかしながら、「結合」は、２つ以上のエレメントが互いに直接的に接触していないが、それでも、互いに協働又は相互作用することも意味する。
あるケースでは、フローチャートのオペレーションを、他のブロック図の例示的な実施形態を参照して説明する。しかしながら、フローチャートのオペレーションは、他のブロック図を参照して述べるもの以外の本発明の実施形態によって遂行することができ、且つ他のブロック図を参照して述べる本発明の実施形態は、フローチャートを参照して述べるもの以外のオペレーションを遂行できることを理解されたい。
図示された技術は、１つ以上のコンピュータに記憶されて実行されるコード及びデータを使用して具現化することができる。このようなコンピュータは、マシン読み取り可能な媒体、例えば、マシン記憶媒体（例えば、磁気ディスク、光学ディスク、ランダムアクセスメモリ、リードオンリメモリ、フラッシュメモリ装置）、及びマシン通信媒体（例えば、電気的、光学的、音響的、又は他の形態の伝播信号、例えば、搬送波、赤外線信号、デジタル信号、等）を使用して、コード及びデータを記憶し通信する（内部で及びネットワークを経て他のコンピュータと）。更に、このようなコンピュータは、典型的に、１つ以上の他のコンポーネント、例えば、記憶装置、多数のユーザ入力／出力装置（例えば、キーボード及びディスプレイ）、及びネットワーク接続部に結合された１つ以上のプロセッサのセットを含む。プロセッサのセット及び他のコンポーネントの結合は、典型的に、１つ以上のバス及びブリッジ（バスコントローラとも称される）を通して行われる。記憶装置及びネットワークトラフィックは、各々、１つ以上のマシン記憶媒体及びマシン通信媒体を表す。従って、所与のコンピュータシステムの記憶装置は、典型的に、そのコンピュータの１つ以上のプロセッサのセットにおいて実行されるコード及びデータを記憶する。もちろん、本発明の一実施形態の１つ以上の部分は、ソフトウェア、ファームウェア及び／又はハードウェアの異なる組合せを使用して具現化することができる。
概略
本発明の１つの態様によれば、プロデューサは、少なくとも特定のインスタンス（又はオブジェクト）及び特定のメソッドであり、プロデューサがランタイム(run time)中に実行される場合には、特定のメソッドが特定のインスタンスにおいて実行される。従って、所与のプロデューサは、所与のインスタンス、及びそのインスタンスに関連した所与のメソッドからインスタンス生成される。クラス、インスタンス及びメソッドと同様に、プロデューサは、ランタイムにより操作される基本的エレメント又はコンストラクトである。従って、プロデューサのインスタンス生成がランタイムによって解釈されて追跡され、従って、ランタイムは、プロデューサにより表わされたインスタンス及びメソッドの組合せを追跡する。換言すれば、プロデューサは、ランタイムインスタンス生成可能な構造であって、これは、ランタイムにより追跡され、即ちランタイムにより実行され、且つ少なくともインスタンスと、そのインスタンスに関連したメソッドとを含み、プロデューサのランタイム実行の結果として、プロデューサのメソッドがプロデューサのインスタンスにおいて実行されるようになる。又、プロデューサのメソッドには、０以上のプロデューサ依存性のセットで、所与のプロデューサに対する０以上のプロデューサのセットを識別するプロデューサ依存性宣言が関連付けられる。より詳細には、プロデューサ依存性は、プロデューサ依存性宣言を使用してメソッドに対して宣言され、所与のメソッドに対するプロデューサ依存性宣言は、０以上のプロデューサ依存性を含み、そして各プロデューサ依存性は、０以上のプロデューサのセットを識別する。従って、プロデューサ依存性宣言、及びそれらが定義するプロデューサ依存性は、ランタイムによって解釈されて追跡され、従って、ランタイムは、プロデューサ依存性宣言により指示されたプロデューサ間の関係を追跡する。
所与のプロデューサが、１つ以上の他のプロデューサのセットに依存する場合には、ランタイムは、所与のプロデューサの前に、他のプロデューサのセットの実行を保証する。従って、プロデューサ依存性宣言は、プロデューサ間の実行関係を表し、一方、プロデューサは、実行されるべきオペレーション（メソッド）及びインスタンスを表す。本発明のある実施形態では、子プロデューサに対する親プロデューサの依存性を、親プロデューサのメソッドに関連したプロデューサ依存性宣言において宣言できる（親プロデューサのプロデューサ依存性宣言が子プロデューサを識別する−ここでは、ダウン方向に宣言されたと称される）が、本発明の他の実施形態では、子プロデューサ（１つ又は複数）のメソッド（１つ又は複数）に関連したプロデューサ依存性宣言において依存性を宣言することもできる（子プロデューサのプロデューサ依存性宣言が１つ以上の親プロデューサを識別する−ここでは、アップ方向に宣言されたと称される）。
本発明の異なる実施形態では、プロデューサは、付加的なものを識別する。例えば、本発明のある実施形態では、プロデューサは、少なくともインスタンスと、そのインスタンスに関連したメソッドとを含むが、本発明の他の実施形態では、プロデューサは、クラス、そのクラスのインスタンス、及びそのインスタンスに関連したメソッドである（例えば、あるプロデューサは、クラス、インスタンス、及びメソッドを直接含み、又、あるプロデューサは、インスタンス及びメソッドを直接含むが、リファレンス（例えば、インスタンスにおけるリファレンス）を通してそのインスタンスのクラスを間接的に識別する）。本発明は、異なるプログラミング言語で書かれたコード（例えば、リフレクティブなオブジェクト指向の言語で書かれたオブジェクト指向のコード、リフレクティブなオブジェクトベースの言語で書かれたオブジェクト指向のコード、手続き型、非リフレクティブなオブジェクト指向、非リフレクティブなオブジェクトベースの言語で書かれて、リフレクティブなオブジェクト指向の言語コードへ変換されたコード）のコンテクストに使用されるが、本発明の実施形態は、リフレクティブなオブジェクト指向のプログラミング言語を参照すると共に、クラス、インスタンス及びメソッドを直接含むプロデューサを参照して、一例として、非限定的に、説明する。又、本発明の一実施形態では、プロデューサのメソッドがインスタンスメソッド（引数として受け取られる入力に加えてインスタンスフィールドを使用できるメソッド）であるが、本発明の別の実施形態は、それに加えて又はそれとは別に、クラスメソッド（全ての入力を引数として受け取り及び／又はインスタンス独立変数を使用するメソッド）であるプロデューサのメソッドをサポートすることもできる（プロデューサのメソッドがインスタンスメソッドである場合には、そのプロデューサのインスタンスは、クラスのインスタンスであるが、プロデューサのメソッドがクラスメソッドである場合には、そのプロデューサのインスタンスは、クラスを表すメタクラスインスタンスである）。
図１Ａは、本発明の一実施形態により、オブジェクト指向のソースコードにおけるクラスのメソッドに対するプロデューサ依存性宣言と、そのクラス、そのクラスの所与のインスタンス、及びそのクラスのメソッドを含むプロデューサとの関係を示すブロック図である。図１Ａにおいて、オブジェクト指向のソースコード１００は、クラス１０２を含むように示され、このクラスは、次いで、メソッド１０４、実行モード設定１０５、及びメソッド１０４に対するプロデューサ依存性宣言１０６を含む。もちろん、クラス１０２は、典型的に、１つ以上のフィールド（図示せず）及び付加的なメソッド（図示せず）を含む。更に、オブジェクト指向のソースコード１００は、典型的に、付加的なクラスを含む。
ランタイム(run time)中に、クラス１０２のインスタンス１０８がインスタンス生成される。インスタンス１０８は、クラス１０２のフィールドのデータを含む。更に、プロデューサ１１０がインスタンス生成され、プロデューサ１１０は、クラス１０２、クラス１０２のインスタンス１０８（クラス１０２のメソッド１０４に関連した）、及びクラス１０２のメソッド１０４を識別する。プロデューサ依存性宣言１０６は、プロデューサ１１０を実行する前に実行されねばならない０以上のプロデューサ１１２のセット（プロデューサ１１０の子プロデューサと称される）をランタイムに対して識別する。換言すれば、プロデューサ１１０は、０以上のプロデューサ１１２のセットに依存する。プロデューサ１１２のセットの出力を消費するのに加えて又はそれに代わって、プロデューサ１１０は、インスタンス１０８のデータを消費することができる。更に、プロデューサ１１０は、少なくとも１つの出力を与え、この出力は、インスタンス１０８に対して内部であってもよく（従って、インスタンス１０８のデータを変更し）、及び／又は外部であってもよく、いずれにせよ、プロデューサ１１０の出力は、０以上の他のプロデューサ１１４のセット（プロデューサ１１０の親プロデューサと称される）によって消費することができる。又、上述したように、そして以下に詳細に述べるように、プロデューサ依存性宣言１０６は、本発明のある実施形態では、０以上のプロデューサ１１４をランタイムに対して識別することもできる。
プロデューサの入力及び出力は、そのプロデューサのベースとなるメソッドの入力及び出力をベースとすることを理解されたい。従って、これらの入力及び出力は、種々のデータ構造を有する複数のパラメータを表すことができる。
所与のメソッドに対するプロデューサ依存性宣言は、インスタンス生成されて実行されるべき０以上のプロデューサのセットをランタイム(run time)時において識別する。例えば、所与のメソッド（例えば、メソッド１０４）に対するプロデューサ依存性宣言（例えば、プロデューサ依存性宣言１０６）が、所与のプロデューサ（この所与のプロデューサは、第１クラス、そのクラスの第１インスタンス、及びその第１インスタンスの第１メソッドを識別する）（例えば、プロデューサ１１２のセットの１つ）に対するプロデューサ依存性を識別する場合には、所与のメソッドのプロデューサ依存性宣言は、第１インスタンスをインスタンス生成すべきである（まだそうでなければ）こと及び第１メソッドを使用して第１インスタンスに対して所与のプロデューサをインスタンス生成すべきであることをランタイムに対して識別する（これらの例において、第１とは、位置や順序を意味するものではない）。
オペレーションにおいて、ランタイムの間に、１つ以上のプロデューサの所与のセットが、関心のあるものであることが指示され、且つそれらに対して宣言されたプロデューサ依存性を有するときに、ランタイムは、１）１つ以上のグラフのセットを自動的に発生し（発見し、構築し、そして任意であるが、解明し）、これらグラフは、マルチレベルのものであり、且つ関心があると指示されたプロデューサの所与のセットから、プロデューサ依存性宣言１０６に基づくソースプロデューサまで種々の形状（例えば、チェーン、ツリー）のものでよく、そして２）グラフのセットのプロデューサの実行をシーケンスして、関心があると指示されたプロデューサの所与のセットの出力（１つ又は複数）を発生する。従って、ランタイムは、プロデューサ依存性宣言１０６を使用して、どんな引数を伴うどんなメソッドをどんなインスタントに対して同期のためにいつ実行すべきか決定する。
ある実施形態では、ランタイムは、実行モード設定１０５をチェックし、プロデューサの実行モードを決定する。異なる実行モードを異なるシステムにおいてサポートすることができる。実行モードのある例は、マルチスレッディング、マルチプロセッシング、及びローカル実行を含む。
プロデューサ依存性は、ランタイムに対するプロデューサの実行のシーケンスを表す。しかしながら、実行のシーケンスを指示するのに加えて、プロデューサ依存性は、本発明の異なる実施形態では、異なる入力対出力関係を表すことができる。例えば、本発明の異なる実施形態は、引数プロデューサ依存性、フィールドプロデューサ依存性、及びシーケンスのみのプロデューサ依存性の１つ以上をサポートすることができる（シーケンスのみのプロデューサ依存性は、ここでは、速記シーケンスプロデューサ依存性と称される）。引数プロデューサ依存性、フィールドプロデューサ依存性、及びシーケンスプロデューサ依存性の各々は、プロデューサ間の実行シーケンス関係を表すが、引数及びフィールドのプロデューサ依存性は、更に、ランタイムが気付くデータも表わす。より詳細には、引数プロデューサ依存性は、ランタイムが子プロデューサの出力を親プロデューサに対する入力パラメータとしてマップするようにさせ、一方、フィールドプロデューサ依存性は、インスタンスのフィールドの使用を指示する。プロデューサ依存性によって表わされる入力対出力関係には関わりなく、プロデューサ依存性の適切な使用は、プロデューサアクセス情報が、その情報に影響するプロデューサの後にシーケンスされるように保証する。
シーケンス依存性は、ランタイムが気付かない仕方でデータを変更するプロデューサと、そのデータを消費するプロデューサとの間で実行順序を保証することを含めて、種々の目的に使用される（子プロデューサは、その出力にアクセスするためのコードを含むことを親プロデューサのメソッドに要求する仕方でその出力を書く（例えば、普通のプロデューサ出力でない、従って、ランタイムにより検出されない出力に影響することにより環境に影響を及ぼすメソッド、例えば、グローバル変数をセットし、プロデューサ出力でないインスタンスにおけるフィールドをセットし、外部データソースに影響する、等のメソッド））。従って、シーケンス依存性は、子プロデューサに対する親プロデューサの依存性を反映するが、コードの書き込みを通して一方から他方へ与える必要のある出力を要求する（例えば、所与のメカニズムに出力を書き込むための子プロデューサのメソッドにおけるコード（例えば、グローバル変数をセットし、外部データソースに影響し、プロデューサ出力でないインスタンスのフィールドをセットし、等々）、及び所与のメカニズムからその出力を読み取るための親プロデューサのメソッドにおけるコード）。このように、シーケンス依存性は、ランタイムで検出できない出力に依存する親プロデューサの実行をランタイムが同期させられるようにする。
本発明の一実施形態では、所与のメソッドに対するプロデューサ依存性宣言１０６は、プロデューサに対する直接的な依存性（例えば、直接的子孫（子供）、これと対照的に間接的子孫（孫、曾孫、等）がある）のみを識別する。このような実施形態では、各プロデューサ依存性宣言は、所与のメソッドからインスタンス生成されたプロデューサにより出力を直接使用できるプロデューサの単一段又は層のみを与え、プロデューサグラフ（１つ又は複数）の付加的な層の発見／構築／解明は、他のプロデューサ依存性宣言のランタイムプロセッシングに託される。
本発明の一実施形態によれば、プロデューサ依存性宣言１０６により識別されるプロデューサの依存性は、プロデューサを含むアプリケーションプログラムのパラレル化及びインスツルメンテーションを具現化するのに有用である。アプリケーションプログラムをパラレル化するために、アプリケーションプログラムの２つ以上のプロデューサが、同じ実行モード又は異なる実行モードで実質的にほぼ同時に実行される。アプリケーションをインスツルメント化するために、プロデューサが実行されるときにプロデューサのメトリックが取得される。パラレル化及びインスツルメンテーションは、本発明の例示的実施形態を参照して、以下に詳細に述べる。
例示的キー
プロデューサは、複数の識別子のセットとして見ることができ、指定の粒度の付加的なレベルごとに１つの識別子がある（クラス、インスタンス、メソッド、等）。更に、本発明のある実施形態は、各識別子を個別のキーとして具現化し、一方、他の実施形態は、幾つかの識別子が１つのキーを共有するようにする。例えば、本発明のある実施形態は、プロデューサを、クラス、インスタンス及びメソッドのトリプレットとして具現化し、そしてトリプレットの各部分が個別キー（クラスキー、インスタンスキー及びメソッドキー）により識別され且つプロデューサがクラスキー、インスタンスキー及びメソッドキーの組合せ（プロデューサキー）により識別されるように、キーを具現化する。
キーを使用する本発明の実施形態は、使用するキーの独特性が変化し得る。例えば、本発明の一実施形態では、各クラスキーが独特であり、各インスタンスキーは、全てのクラスの全てのインスタンスにわたって独特であり、そして各メソッドキーは、全てのクラスの全てのメソッドにわたって独特である。別の例として、本発明の他の実施形態では、各クラスが独特のキーを有し、所与のクラスの各インスタンスは、独特のキーを有し（クラスインスタンスにわたって）、そしてクラスの各メソッドは、独特のキーを有する（クラスメソッドにわたって）が、異なるクラスのインスタンスが同じインスタンスキーを有してもよく、且つ異なるクラスのメソッドが同じメソッドキーを有してもよく、この後者の解決策は、本書の残り部分において、一例として、非限定的に、使用される。例えば、第１クラスがメソッドを含むと共に、それらメソッドの各々に対し、第１クラス内で独特であるキーを有すると仮定すれば、このクラスのインスタンス（各々が互いに独特のキーを有する）には、同じメソッドキーが関連付けられる。別の例として、異なる第２クラスが、第１クラスに使用されたものと同じメソッドキーを有するメソッド（第１クラスのメソッドと幾つか同じ、全部同じ、又は全く同じでない）を含むと仮定する。従って、この異なるクラスのインスタンスには、第１クラスのインスタンスに関連付けられた同じメソッドキーが関連付けられてもよい。
これらキーの使用は、１）プロデューサの識別子によって識別された各エンティティを追跡すること（例えば、各クラス、インスタンス、及びメソッドの追跡）、２）多数の親プロデューサ（相互の存在に気付かない）がそれらのプロデューサ依存性宣言（これは、プロデューサキーを使用してプロデューサ依存性を指定する）に基づいて同じ子プロデューサに接続すること、等を含めて、種々の特徴を許す。本発明の一実施形態では、インスタンスキーは、キー識別子がインスタンス又は別のオブジェクト（ストリングのような）へのリファレンスであるかどうかを指示するインスタンスキー特性と、インスタンス又は別のオブジェクト（ストリングのような）のいずれかへのリファレンスであるキー識別子と、の２つのエレメントを保持するクラスのインスタンス（InstanceKey）である。インスタンスキーにインスタンスリファレンスを記憶することは、プログラマーがこれらのインスタンスを識別するための名前を創案することから逃れさせる。
例示的関係
プロデューサが複数の識別子のセット（指定の粒度の各付加的なレベルに対して１つの識別子をもつ）として見られることに関する前記説明に関連して、本発明の一実施形態では、プロデューサとその子供及び親との間の種々のサポートされる関係は、あるプロデューサと、０以上の親プロデューサのセットとの間で少なくとも１つのこのような識別子が異なり、且つあるプロデューサと、０以上の子プロデューサのセットの各々との間で１つのこのような識別子が異なるというものである。ある例示的関係を与えることにより、第１クラスの第１インスタンス及びその第１クラスの第１メソッドである第１プロデューサがインスタンス生成されると仮定し、且つその第１メソッドに対するプロデューサ依存性宣言がランタイム(run time)時において第２プロデューサを子供として識別すると仮定すると、第２プロデューサは、１）第１クラスの第１インスタンス及びその第１クラスの第２メソッドであり、２）第１クラスの第２インスタンス及びその第１クラスの第２メソッドであり、３）第１クラスの第２インスタンス及び第１クラスの第１メソッドであり、又は４）第２クラスのインスタンス及びその第２クラスのメソッドである。このようなケースでは、第１プロデューサは、第２プロデューサに依存し、従って、第２プロデューサに対する第１プロデューサの入力対出力関係を表す。種々の関係及びそれら関係の組合せは、オブジェクト指向の言語を使用する一実施形態であって、プロデューサが少なくともクラス、インスタンス及びメソッドを識別する本発明の実施形態について以下に説明する。
図１Ｂ−１Ｄは、本発明の一実施形態により、所与のプロデューサと、その親プロデューサのセットと、その子プロデューサのセットとの間の関係を例示する。図１Ｂ−１Ｄは、各々、次のものを示す。１）メソッド１０４Ａ−Ｃと、これらメソッドの各々に対するプロデューサ依存性宣言１０６Ａ−Ｃとを各々含むクラス定義１０２Ａ；２）メソッド１０４Ｄ−Ｅと、これらメソッドの各々に対するプロデューサ依存性宣言１０６Ｄ−Ｅとを各々含むクラス定義１０２Ｂ；３）メソッド１０４Ｆと、このメソッドに対するプロデューサ依存性宣言１０６Ｆとを含むクラス定義１０２Ｃ；４）クラス１０２Ａのインスタンス１０８Ａ；５）クラス１０２Ａ、インスタンス１０８Ａ及びメソッド１０４Ａを識別するプロデューサ１１０Ａ；及び６）プロデューサ１１２及び１１４のセットの１つを各々表わすプロデューサ１１２Ａ．１及びプロデューサ１１４Ａ．１。ボックス内に文字を伴う破線は、図１Ｂ−１Ｄにおいて、関係を例示するために使用される。従って、ボックス内にＡを伴う破線の集合は、１つの関係を表す。図１Ｂにおける関係は、図１Ｃにおける関係と組合せ可能であり、従って、これらの組合せは、プロデューサ１１０Ａに対する親プロデューサ１１４Ａと子プロデューサ１１２Ａとの関係の組合せを表している。更に、図１Ｄは、プロデューサ１１０Ａに対する親プロデューサ１１４Ａと子プロデューサ１１２Ａとの関係のある付加的な組合せを例示している。
図１Ｂは、本発明の一実施形態によるプロデューサ１１０Ａと親プロデューサ１１４Ａ．１との関係を例示している。図１Ｂは、更に、インスタンス１０８Ｂを含む。プロデューサ１１４のセットは、同じクラスの異なるメソッド（１つ又は複数）、同じクラスの異なるインスタンス、及び／又は異なるクラスのメソッド（１つ又は複数）の他のプロデューサ依存性宣言によって識別され、従って、プロデューサ１１４のセットの各々は、１）プロデューサ１１０Ａと同じインスタンス（クラス１０２Ａのインスタンス１０８Ａ）及びそのインスタンスの異なるメソッド（インスタンス１０８Ａからプロデューサ１１４Ａ．１へ及びメソッド１０４Ｂからプロデューサ１１４Ａ．１への破線上のボックス内のＡにより示された）であり；２）クラス１０２Ａの異なるインスタンス及びそのインスタンスの異なるメソッド（クラス１０２Ａからインスタンス１０８Ｂへ、インスタンス１０８Ｂからプロデューサ１１４Ａ．１へ及びメソッド１０４Ｂからプロデューサ１１４Ａ．１への破線上のボックス内のＢにより示された）であり；３）異なるクラスのインスタンス及びそのインスタンスのメソッド（クラス１０２Ｂからインスタンス１０８Ｂへ、インスタンス１０８Ｂからプロデューサ１１４Ａ．１へ及びメソッド１０４Ｄからプロデューサ１１４Ａ．１への破線上のボックス内のＣにより示された）であり；又は４）クラス１０２Ａの（インスタンス１０８Ａとは）異なるインスタンス及びそのインスタンスの同じメソッド（メソッド１０４Ａ）（例えば、以下に述べるコンティンジェント依存性を伴う）（クラス１０２Ａからインスタンス１０８Ｂへ、インスタンス１０８Ｂからプロデューサ１１４Ａ．１へ及びメソッド１０４Ａからプロデューサ１１４Ａ．１への破線上のボックス内のＤにより示された）であり；更に、プロデューサ１１４のセットに複数のプロデューサがある場合には、プロデューサ１１４それ自体が、クラス１０２Ａの同じインスタンス、クラス１０２Ａの異なるインスタンス、異なるクラスの同じインスタンス、異なるクラスの異なるインスタンス、及び／又はそれらの混合の一部分でもよい。
図１Ｃは、本発明の一実施形態によるプロデューサ１１０Ａと子プロデューサ１１２Ａ．１との関係を例示している。図１Ｃは、更に、インスタンス１０８Ｃを含む。プロデューサ１１２Ａのセットの各々は、１）プロデューサ１１０Ａと同じインスタンス（クラス１０２Ａのインスタンス１０８Ａ）及びそのインスタンスの異なるメソッド（インスタンス１０８Ａからプロデューサ１１２Ａ．１へ及びメソッド１０４Ｃからプロデューサ１１２Ａ．１への破線上のボックス内のＥにより示された）であり；２）クラス１０２Ａの異なるインスタンス及びそのインスタンスの異なるメソッド（クラス１０２Ａからインスタンス１０８Ｃへ、インスタンス１０８Ｃからプロデューサ１１２Ａ．１へ及びメソッド１０４Ｃからプロデューサ１１２Ａ．１への破線上のボックス内のＦにより示された）であり；３）異なるクラスのインスタンス及びそのインスタンスのメソッド（クラス１０２Ｃからインスタンス１０８Ｃへ、インスタンス１０８Ｃからプロデューサ１１２Ａ．１へ及びメソッド１０４Ｆからプロデューサ１１２Ａ．１への破線上のボックス内のＧにより示された）であり；又は４）クラス１０２Ａの（インスタンス１０８とは）異なるインスタンス及びそのインスタンスの同じメソッド（メソッド１０４Ａ）（例えば、以下に述べるコンティンジェント依存性を伴う）（クラス１０２Ａからインスタンス１０８Ｃへ、インスタンス１０８Ｃからプロデューサ１１２Ａ．１へ及びメソッド１０４Ａからプロデューサ１１２Ａ．１への破線上のボックス内のＨにより示された）である。従って、プロデューサ１１２Ａのセットの各々は、プロデューサ１１０Ａの同じインスタンス、クラス１０２Ａの異なるインスタンス、又は異なるクラスのインスタンスでよく、更に、プロデューサ１１２Ａのセットに複数のプロデューサがある場合には、プロデューサ１１２Ａそれ自体が、クラス１０２Ａの同じインスタンス、クラス１０２Ａの異なるインスタンス、異なるクラスの同じインスタンス、異なるクラスの異なるインスタンス、及び／又はそれらの混合の一部分でもよい。
図１Ｄは、本発明の一実施形態による親プロデューサ１１４及び子プロデューサ１１２とプロデューサ１１０Ａとの関係の付加的な組合せを例示している。図１Ｄは、更に、インスタンス１０８Ｂ及びインスタンス１０８Ｃを含む。図１Ｄの組合せを以下のテーブル１に示す。
テーブル１
Figure 0005354601
図１Ｅは、本発明の一実施形態により、同じクラスの異なるインスタンスが同じ及び／又は異なるメソッドに基づきプロデューサを有することができることを示す。図１Ｅは、次のものを示す。即ち、１）クラス定義１０２Ａが、メソッド１０４Ａ−Ｃと、各メソッドに対するプロデューサ依存性宣言１０６Ａ−Ｃを各々含むこと；２）インスタンス１０８Ａ及びインスタンス１０８Ｂがクラス１０２Ａのものであること；３）プロデューサ１１０Ａが、クラス１０２Ａのインスタンス１０８Ａのメソッド１０４Ａであること；４）プロデューサ１１０Ｂが、クラス１０２Ａのインスタンス１０８Ａのメソッド１０４Ｂであること；５）プロデューサ１１０Ｃが、クラス１０２Ａのインスタンス１０８Ｂのメソッド１０４Ａであること；及び６）プロデューサ１１０Ｄが、クラス１０２Ａのインスタンス１０８Ｂのメソッド１０４Ｃであること。更に、図１Ｄは、次のことを示す。即ち、１）メソッド１０４Ａのプロデューサ依存性宣言１０６Ａが、ランタイム(run time)時において、プロデューサ１１０Ａ及びプロデューサ１１０Ｃの両方の子プロデューサを識別すること；２）メソッド１０４Ｂのプロデューサ依存性宣言１０６Ｂが、ランタイム(run time)時において、プロデューサ１１０Ｂの子プロデューサを識別すること；及び３）メソッド１０４Ｃのプロデューサ依存性宣言１０６Ｃが、ランタイム(run time)時において、プロデューサ１１０Ｄの子プロデューサを識別すること。
例示的ランタイム
図２は、本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムの再使用性を示すブロック図である。図２において、複数のオブジェクト指向のアプリケーションプログラム（プロデューサ依存性宣言を伴うオブジェクト指向のアプリケーションコード２１０Ａ−Ｉ）は、プロデューサグラフ指向のプログラミングサポートを伴う同じランタイム２２０によって実行される。
図３Ａは、本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。図３Ａにおいて、プロデューサグラフ指向のプログラミングサポート３３５を伴うランタイムは、自動プロデューサグラフ実行モジュール３４０及びプロデューサグラフ実行モジュール３４５を含む。更に、ランタイム３３５は、オブジェクト指向のソースコードを実行するもので、従って、図示されていない付加的なモジュールを含む。
更に、図３Ａは、オブジェクト指向のソースコードにおけるメソッドのためのプロデューサ依存性宣言３２０、出力が問題である１つ以上のプロデューサの現在セット３２５（ここでは、問題とする現在選択されたプロデューサと称される）、及びソースプロデューサの出力３３０（以下で説明する）を示している。自動プロデューサグラフ発生モジュール３４０は、プロデューサ依存性宣言３２０、及び問題とするプロデューサの現在セット３２５を受け取る。
自動プロデューサグラフ発生モジュール３４０は、問題とする現在選択されたプロデューサの入力に直接的及び間接的に貢献する出力を伴う子プロデューサをプロデューサ依存性宣言に基づいて発見し、そして問題とする現在選択されたプロデューサからソースプロデューサである発見されたプロデューサのものまでのプロデューサの互いの入力依存性を表すプロデューサの現在グラフを構築するよう試みる。プロデューサグラフ（１つ又は複数）は、プロデューサグラフ（１つ又は複数）構造３８０に記憶される。
プロデューサグラフ実行モジュール３４５は、自動プロデューサグラフ発生モジュール３４０からの現在プロデューサグラフ（１つ又は複数）及びソースプロデューサ３３０の出力を受け取り、そして現在プロデューサグラフ（１つ又は複数）のプロデューサを実行して、問題とする現在選択されたプロデューサの現在出力を決定する。ある実施形態では、プロデューサグラフ実行モジュール３４５は、パラレル化モジュール３４５１、マルチプロセッシングモジュール３４５３、マルチスレッディングモジュール３４５５、及びローカル実行モジュール３４５７を含む。パラレル化モジュール３４５１は、プロデューサの実行モードを決定し、そしてその決定された実行モードで実行されるべきマルチプロセッシングモジュール３４５３、マルチスレッディングモジュール３４５５及びローカル実行モジュール３４５７の１つにプロデューサを送信することができる。パラレル化は、個々の実行モードによりサポートすることができる。例えば、プロデューサのパラレル実行は、マルチプロセッシングを使用するマルチプロセッシングモジュール３４５３により達成することができる。或いは又、プロデューサのパラレル実行は、マルチスレッディングを使用するマルチスレッディングモジュール３４５５により達成することができる。更に、パラレル化は、実行モードの組合せによりサポートすることができる。換言すれば、プロデューサは、異なる実行モードを使用してパラレルに実行することができる。例えば、２つのプロデューサは、マルチスレッディングモジュール３４５５に１つのプロデューサを送信しそしてローカル実行モジュール３４５７に他方のプロデューサを送信することによりパラレルに実行することができる。実行モジュールの他の組合せを使用してパラレル化を具現化できることが明らかであろう。
プロデューサグラフ実行モジュール３４５は、プロデューサ出力キャッシング３８４により示されたようにプロデューサグラフ構造３８０にプロデューサの現在出力をキャッシュ記憶する。実行中にプロデューサグラフのプロデューサ出力をキャッシュ記憶することで同期をとることができる。例えば、複数の子プロデューサに依存する親プロデューサを実行する適切な時間は、複数の子プロデューサが全て実行された後であり、換言すれば、子プロデューサの１つが実行を完了するたびに親プロデューサを実行するのは無駄である（あるケースでは、不可能である）。プロデューサ出力をキャッシュ記憶することは、親プロデューサの実行を、全ての子プロデューサが実行されてしまうまで延期できるだけでなく、親プロデューサを実行するための適切な時間、即ち全ての子プロデューサが実行されてそれらの出力がキャッシュ記憶されるとき、を決定できるようにする。従って、ランタイムは、プロデューサ出力キャッシング３８４において必要な出力が利用できることをチェックすることによりプログラマーに対してこの同期判断を実行し、換言すれば、このような同期が自動化される（プログラマーは、あるインスタンスの所与のメソッドを実行するための適切な時間を決定する個別のソースコードを含ませる必要がない）。別の例として、複数の親プロデューサが同じ子プロデューサ及び他の異なる子プロデューサに依存する場合には、複数の親プロデューサの各々を実行するための適切な時間が典型的に異なり、ランタイムは、子プロデューサのセットの出力の利用性に基づいて複数の親プロデューサの各々を実行するための適切な時間を自動的に決定する。
以下に詳細に述べるように、プロデューサグラフのある部分は、ダイナミックなプロデューサ依存性のために現在発見できないことがあるので、自動プロデューサグラフ発生モジュール３４０は、プロデューサグラフ全体を発見し構築するように「試みる」が、あるプロデューサが実行されるまでは、最初にプロデューサグラフ全体を完了できないことがある。従って、プロデューサグラフ実行モジュール３４５は、現在プロデューサグラフの実行中に必要なプロデューサ出力を伴う自動プロデューサグラフ発生モジュール３４０をインボークし、現在プロデューサグラフの未解明の残部を完了することができる（これは、図３Ａにおいて、プロデューサグラフ実行モジュール３４５から自動プロデューサグラフ発生モジュール３４０への矢印付き破線で示されており、矢印付き破線は、このようなサポートが任意であるために使用されている）。
図４Ａは、本発明の一実施形態による例示的プロデューサグラフの発見及び構築を示すブロック図である。図４Ａは、問題とするプロデューサの現在セットがプロデューサ１より成ることを示す。プロデューサ及びそのプロデューサ依存性宣言に基づいて、プロデューサ２及びプロデューサ３が発見される。換言すれば、プロデューサ１に対するプロデューサ依存性宣言は、プロデューサ１への入力がプロデューサ２及びプロデューサ３の実行を要求することを示す。従って、プロデューサ１は、従属プロデューサ（１つ以上のプロデューサ依存性を有するプロデューサ）である。又、図４Ａは、プロデューサ３が独立プロデューサ（プロデューサ依存性をもたず、従って、ソースプロデューサであるプロデューサ）であるが、プロデューサ２は、そうでないことも示す。その結果、プロデューサ２のプロデューサ依存性宣言に基づき、プロデューサ４及びプロデューサ５が発見される。図２Ａにおいて、プロデューサ４及びプロデューサ５は、独立プロデューサ（従って、ソースプロデューサ）である。
図４Ｂは、本発明の一実施形態により図４Ａのプロデューサグラフの初期実行を示すブロック図である。図４Ｂにおいて、矢印付きの曲線は、あるプロデューサを実行して出力を発生し、それが別のプロデューサへ入力として与えられることを示す。図３Ａに示すように、ソースプロデューサ３３０の出力は、プロデューサグラフ実行モジュール３４５に与えられ、対照的に、従属プロデューサ１−２の出力は、図４Ｂに示すようにプロデューサの実行によって決定される。従って、図４Ｂでは、次のことが生じる。即ち、１）ソースプロデューサ４及びソースプロデューサ５の出力が従属プロデューサ２に与えられ、従属プロデューサ２が実行され、３）従属プロデューサ２及びソースプロデューサ３の出力がプロデューサ１に与えられ、そして４）プロデューサ１が実行され、且つその出力が、問題とする現在出力として与えられる。図４Ｂのプロデューサグラフは、データがグラフを上るようにあるプロデューサから別のプロデューサへ流れる方向に駆動されるデータであることに注意する価値がある。
ある実施形態では、プロデューサ４及びプロデューサ５は、これらプロデューサ４及び５が互いに独立であるから、パラレル化（例えば、マルチプロセッシング、マルチスレッディング、等）をサポートする異なる実行モード又は単一実行モードを使用してパラレルに実行することができる。しかしながら、ここに示す例では、プロデューサ２がプロデューサ４及び５に依存するので、プロデューサ２は、プロデューサ４及び５とパラレルに実行されないことがある。従って、ランタイムは、プロデューサ２を実行する前にプロデューサ４及び５が終了するのを待機する。プロデューサ３については、プロデューサ３が、プロデューサ４及び５と独立しているので、プロデューサ３は、プロデューサ４及び５とパラレルに実行される。或いは又、プロデューサ３は、それがプロデューサ２とも独立しているので、プロデューサ２とパラレルに実行されてもよい。ある実施形態では、プロデューサ３の実行は、プロデューサ３、４及び５を実行するのにどれほどの時間がかかるかに基づいて、プロデューサ４及び５の実行、並びにプロデューサ２の実行と時間的に重畳してもよい。
従って、プロデューサ依存性宣言３２０は、発生されると考えられるプロデューサグラフの境界を定め、一方、問題とするプロデューサの現在選択セット３２５は、発生されるべき現在プロデューサグラフの開始ノード（１つ又は複数）を識別する。これらの２つから、自動プロデューサグラフ発生モジュール３４０がプロデューサグラフを発見して構築する。発見及び構築は、自動プロデューサグラフ発生モジュール３４０に、プロデューサグラフ（例えば、プログラマーにより手動で識別される必要がない）も、プロデューサグラフ内のプロデューサのリストも与えられないという点で、自動的である。むしろ、自動プロデューサグラフ発生モジュール３４０は、問題とするプロデューサの現在選択セットのプロデューサ依存性宣言（１つ又は複数）を構文解析して、それらの子プロデューサを発見し、次いで、それらの発見されたプロデューサのプロデューサ依存性宣言を構文解析し、等々で、ソースプロデューサまで行う（以下に述べる本発明のある実施形態では、これは、プロデューサグラフ実行モジュール３４５の助けで行われてもよい）。プロデューサグラフがツリーである場合には、問題とする現在選択されたプロデューサが典型的に根ノードであり、プロデューサ依存性宣言は、葉ノード（ソースプロデューサ）が発見されるまで構文解析される。
オーバーライドされたプロデューサ及び増分的実行
図３Ｂは、本発明の一実施形態により、増分的実行及びオーバーライドされたプロデューサ出力もサポートするプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。増分的実行及びオーバーライドされたプロデューサ出力は、各々、独立した任意の特徴であり、従って、本発明の異なる実施形態では、一方を具現化してもよいし、両方を具現化してもよいことを理解されたい。図３Ｂには明確に示されないが、図３Ａのパラレル化モジュール３４５１、マルチプロセッシングモジュール３４５３、マルチスレッディングモジュール３４５５、及びローカル実行モジュール３４５７は、図３Ｂのプロデューサグラフ実行モジュール３７０がプロデューサの実行においてパラレル化を実施できるように図３Ｂのプロデューサグラフ実行モジュール３７０に含まれてもよいことが明らかであろう。
図３Ｂにおいて、プロデューサグラフ指向のプログラミングサポートを伴うランタイム３６０は、自動プロデューサグラフ発生モジュール３６５、プロデューサグラフ実行モジュール３７０、及びオーバーライドプロデューサ出力モジュール３９０を備えている。ランタイム３６０は、オブジェクト指向のソースコードを実行するものであり、従って、図示されていない付加的なモジュールを備えている。
更に、図３Ｂは、オブジェクト指向のソースコードにおけるメソッドに対する依存性宣言３２０、出力が問題である１つ以上のプロデューサの現在セット３２５（ここでは、問題とする現在選択されたプロデューサとも称される）、及びソースプロデューサの出力３５０も示している。ソースプロデューサの出力３５０は、ソースコードにおける独立プロデューサセットの出力３５２（例えば、定数、デフォールト値、等）、及び現在オーバーライドされたプロデューサ出力３５４（出力が現在オーバーライドされた独立プロデューサ及び／又は従属プロデューサの出力）を含む。
本発明のある実施形態では、プロデューサの出力は、現在与えられた値で明確にオーバーライドすることができる（即ち、プロデューサを実行してその現在入力に基づいてその出力値を決定するのではなく、プロデューサに対する出力値が明確に与えられる）。プロデューサグラフの独立プロデューサに加えて、プロデューサグラフのソースプロデューサは、現在オーバーライドされたプロデューサを含む。
オーバーライドプロデューサ出力モジュール３９０は、オーバーライドされたプロデューサ出力３５４を受け取る（これは、どのプロデューサがオーバーライドされそしてどんな出力値でオーバーライドされるか識別する）。本発明の一実施形態では、プロデューサは、プロパティプロデューサ又はメソッドプロデューサとして分類することができる。プロパティプロデューサは、プロパティメソッド（例えば、ゲット及びセット）に基づくものである。メソッドプロデューサは、非プロパティメソッドに基づくものである。オーバーライドプロデューサ出力モジュール３９０は、オーバーライドされたプロパティプロデューサのためのオーバーライドプロパティプロデューサ出力モジュール３９２と、オーバーライドされたメソッドプロデューサのためのオーバーライドメソッドプロデューサ出力モジュール３９４とを備えている。オーバーライドプロパティプロデューサ出力モジュール３９２は、オーバーライドされた値を、プロデューサ出力キャッシング３８４及びインスタンスのデータに記憶させ、一方、オーバーライドメソッドプロデューサ出力モジュール３９４は、オーバーライドされた値をプロデューサ出力キャッシング３８４に記憶させる。本発明の実施形態に基づき、この因果関係は、直接的でも間接的でもよい。図３Ｂは、オーバーライドログ３９６を使用して間接的に行わせることを示し、このオーバーライドログは、オーバーライドプロデューサ出力モジュール３９０の出力を収集するもので、プロデューサグラフ実行モジュール３７０によって消費される。最適化のために、オーバーライドロジック３９６は、オーバーライドを遅延させ、複数のオーバーライドをバッチ処理のために収集できるようにする。
自動プロデューサグラフ発生モジュール３４０と同様に、自動プロデューサグラフ発生モジュール３６５は、１）プロデューサ依存性宣言３２０及び問題とするプロデューサの現在セット３２５を受け取り、そして２）プロデューサ依存性宣言に基づいて、問題とする現在選択されたプロデューサの入力に直接的及び間接的に貢献する出力を伴うプロデューサを発見し、且つ問題とする現在選択されたプロデューサから、発見された非ソースプロデューサを経て、ソースプロデューサ（独特プロデューサ及び現在オーバーライドされたプロデューサ）である発見されたプロデューサのものまで、プロデューサの互いの入力依存性を表すプロデューサの現在グラフを構築するよう試みる。プロデューサグラフ（１つ又は複数）は、プロデューサグラフ（１つ又は複数）構造３８０に記憶される。
プロデューサグラフ実行モジュール３４５と同様に、プロデューサグラフ実行モジュール３７０は、自動グラフモジュール３６５からの現在プロデューサグラフ及びソースプロデューサ３５０の出力を受け取り、そして現在プロデューサグラフのプロデューサを実行して、問題とする現在選択されたプロデューサの現在出力を決定する。プロデューサグラフ実行モジュール３７０は、プロデューサ出力キャッシング３８４により示されたように、プロデューサグラフ構造３８０にプロデューサの現在出力をキャッシュ記憶する。
上述したように、実行中にプロデューサ出力をキャッシュ記憶することで同期をとることができる（例えば、図４Ｂのプロデューサ２をいつ実行すべきか決定するために個別のソースコードを書き込む必要がなく、むしろ、ランタイムは、プロデューサ出力キャッシング３８４において必要な出力が利用できることをチェックすることによりプログラマーに対してこの同期判断を実行し、換言すれば、このような同期が自動化される）。更に、実行中にプロデューサ出力をキャッシュ記憶することで、プロデューサ実行をパラレル化することができる。というのは、ランタイムは、プロデューサ出力キャッシング３８４において必要な出力が利用できることをチェックすることによりどのプロデューサが実行の準備ができたか判断できるからである。実行の準備ができたプロデューサは、パラレルに実行することができる。換言すれば、パラレル化も自動化することができる。従って、どのプロデューサをパラレルに実行すべきか決定し又は指示するのに、個別のソースコードが必要とされない。更に、このプロデューサ出力キャッシング３８４は、増分的実行に使用される。より詳細には、プロデューサグラフが最初に発生されて実行された後に、現在プロデューサグラフにおけるプロデューサをオーバーライドするのに、ある程度の再実行レベルが要求される。本発明のある実施形態は、グラフ全体を単純に再実行するが、本発明の別の実施形態は、増分的実行をサポートする（オーバーライドにより影響されるプロデューサグラフの部分のみを再実行する）。増分的実行をサポートするある例示的実施形態は、どのプロデューサが再実行を要求するか決定する上で助けとなるように、プロデューサグラフ（１つ又は複数）構造３８０に増分的実行マーキング３８２を使用する。従って、プロデューサグラフを維持することは、複数の実行にわたって必要に応じてプロデューサグラフのリンクを変更して、それらを現在状態（最新状態）に保持することを指し、一方、増分的実行は、プロデューサグラフ（１つ又は複数）を維持し、且つ現在（最新）プロデューサグラフを使用して、オーバーライドにより影響されるプロデューサグラフの部分のみを再実行することを指す。
図３Ａと同様に、ダイナミック依存性に対する任意のサポートを表すために、プロデューサグラフ実行モジュール３７０から自動プロデューサグラフ実行モジュール３６５へと矢印付き破線が延びている。ダイナミック依存性は、プロデューサグラフの再実行中に変化し得ることに注意されたい。
図４Ｃは、本発明の一実施形態により図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。図４Ｃにおいて、プロデューサ５の出力は、明確に変更されているが、プロデューサ３及びプロデューサ４の出力は、変更されていない。プロデューサグラフにおける出力対入力依存性の追跡と、プロデューサ５の出力のみが明確に変更されていることに基づいて、プロデューサ２及びプロデューサ１だけがこの変更により影響されることが決定される。その結果、プロデューサ１の更新された出力を決定するのに、プロデューサ５の新たな出力と、プロデューサ４及びプロデューサ３の以前の出力とでプロデューサ２及びプロデューサ１を再実行することしか要求されない。プロデューサグラフのこの部分的な再実行は、図４Ｃにおいて、プロデューサ５からプロデューサ２へそしてプロデューサ２からプロデューサ１への矢印付き曲線が存在するが、プロデューサ４からプロデューサ２へ又はプロデューサ３からプロデューサ１へは存在しないことにより示される。プロデューサ４からプロデューサ２へ及びプロデューサ３からプロデューサ１への矢印付き曲線が存在しないことは、プロデューサ３及びプロデューサ４の出力が必要ないことを指示するのではなく、むしろ、プロデューサ３及びプロデューサ４の以前の出力が（例えば、プロデューサグラフの以前の実行からキャッシュ記憶されて）利用できる場合には、それらプロデューサを再実行する必要がないことを指示する。
図４Ｃの比較的簡単な例は、増分的実行の結果として処理リソースを節約できることを示している。このような節約は、多数のファクタ（例えば、再実行する必要のないプロデューサの数、それらプロデューサが要求する処理の量、等）に依存する。増分的実行を遂行する本発明の一実施形態が例示されたが、別の実施形態を別の仕方で具現化することもできる（例えば、別の実施形態は、変更に応答して全てのプロデューサを再実行することができる）。
図４Ｄは、本発明の一実施形態により従属プロデューサ２がオーバーライドされた後の図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。図４Ｄにおいて、プロデューサ２の出力は、明確に変更されているが、プロデューサ３の出力は、変更されていない。プロデューサグラフと、プロデューサ２の出力のみが明確に変更されたこととに基づいて、この変更によりプロデューサ１だけが影響されると決定される。その結果、プロデューサ１の更新された出力を決定するのに、プロデューサ２のオーバーライドされた出力と、プロデューサ３の以前の出力とでプロデューサ１を再実行することしか要求されない。プロデューサグラフのこの部分的再実行は、図４Ｄにおいて、プロデューサ２からプロデューサ１への矢印付き曲線が存在するが、プロデューサ４及び５からプロデューサ２へ又はプロデューサ３からプロデューサ１へは存在しないことにより示される。
図４Ｅは、本発明の一実施形態により従属プロデューサ２がオーバーライドされそして独立ソースプロデューサ３が変更された後の図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。プロデューサグラフと、プロデューサ２及びプロデューサ３の出力のみが変更されたこととに基づいて、この変更によりプロデューサ１だけが影響されると決定される。その結果、プロデューサ１の更新された出力を決定するのに、プロデューサ２のオーバーライドされた出力と、プロデューサ３の以前の出力とでプロデューサ１を再実行することしか要求されない。プロデューサグラフのこの部分的再実行は、図４Ｅにおいて、プロデューサ２及び３からプロデューサ１への矢印付き曲線が存在するが、プロデューサ４及び５からプロデューサ２へは存在しないことにより示される。
オーバーライドプロデューサ出力をサポートする本発明の一実施形態は、非オーバーライドプロデューサ出力もサポートするが、本発明の別の実施形態は、そのようにしない。非オーバーライドプロデューサをサポートする本発明の一実施形態は、オーバーライドされたプロデューサを、それが特に非オーバーライドされるまで、オーバーライドされたままにするが、本発明の別の実施形態は、異なる仕方で具現化されてもよい（例えば、オーバーライドされたプロデューサを、その子孫の１つがオーバーライドされるときに非オーバーライド化する）。
本発明の一実施形態において、プロデューサグラフ指向のプログラミングフレームワークは、プロデューサ依存性宣言と共に書かれていないプログラムとインターフェイスするのに使用される外部インターフェイスを含む。この外部フレームワークは、１）発呼部分（ランタイムクライアントと称される）、及び２）被呼部分（外部データソースと称される）を含む。プロデューサが外部データソースから直接データを読み取る場合には、プロデューサが生成されるときにデータを読み取るだけでよく、又、そのように命令されたときにデータを読み取る（手動リフレッシュ）か、又はそれにサブスクライブするだけでよい。手動リフレッシュ及びサブスクライブの場合には、外部データソースが変化した結果、プロデューサのセットメソッドがインボークされ且つプロデューサの出力が変更される（オーバーライドされたプロデューサと同じものが処理される）。
プロデューサグラフ構築及び実行
本発明の異なる実施形態は、プロデューサグラフを発見して、異なる程度に構築するように具現化することができる（例えば、根ノードからの全ての経路が独立プロデューサにおいて終了するまでプロデューサグラフを構築し（このケースでは、プロデューサグラフの終了ノードが独立プロデューサであり、オーバーライドされたプロデューサが中間ノードであるおそれがある）；根ノードからの各経路が、オーバーライドされたプロデューサ又は独立プロデューサのいずれか最初に到着する方で終了するまで、プロデューサグラフを構築する（このケースでは、プロデューサグラフの各終了ノードが独立プロデューサ又はオーバーライドされたプロデューサのいずれかである））。
「実行スタートプロデューサ」とは、プロデューサグラフのプロデューサであって、そこからプロデューサグラフの所与の実行が開始されるプロデューサを指す。プロデューサグラフの初期実行に対して、異なる実施形態は、異なるプロデューサからスタートすることができる（例えば、根ノードからの全ての経路が独立プロデューサにおいて終了するまでプロデューサグラフを構築する本発明の実施形態では、終了ノード（これは独立プロデューサである）から；ソースプロデューサ（これは、独立プロデューサノード及び任意のオーバーライドされたプロデューサノードを含む）から；少なくとも１つの経路を間に伴う独立プロデューサと、オーバーライドされたプロデューサを含まない根プロデューサと、オーバーライドされたプロデューサとの組合せより成るソースプロデューサのサブセットから；或いはオーバーライドされた子孫を伴わないオーバーライドされたプロデューサと、少なくとも１つの経路を間に伴う独立プロデューサと、オーバーライドされたプロデューサを含まない根プロデューサとの組合せより成るソースプロデューサのサブセットから；実行をスタートすることができ、更に、オーバーライドされたプロデューサの下でのプロデューサグラフが、そのようなプロデューサが非オーバーライドである場合及び非オーバーライドにされるまで構築されないような本発明の実施形態では、終了ノード（独立プロデューサ及び／又はオーバーライドされたプロデューサである）から実行をスタートすることができ、等々である）。
プロデューサグラフのその後の実行に対して、異なる実施形態は、異なるプロデューサからスタートすることができる（例えば、プロデューサグラフの独立プロデューサから（例えば、増分的実行をサポートしない本発明の実施形態において）；プロデューサグラフのソースプロデューサから（例えば、増分的実行をサポートしない本発明の実施形態において）；最後の実行以来オーバーライドされ及び／又は追加されたソースプロデューサより成るソースプロデューサのサブセットから（例えば、増分的実行をサポートする本発明の実施形態において）；最後の実行以来オーバーライドされ及び／又は追加されたソースプロデューサのうち、オーバーライドされた子孫を伴わないオーバーライドされたプロデューサと、少なくとも１つの経路を間に伴う追加されたプロデューサと、オーバーライドされたプロデューサを含まない根プロデューサとの組合せから（例えば、増分的実行をサポートする本発明の実施形態において）；等）。
実行スタートプロデューサの前記概念に関して、プロデューサグラフの実行の処理フローも、異なる実施形態の間で相違する。例えば、本発明の一実施形態では、実行スタートプロデューサの祖先が決定されて集合に入れられ、実行スタートプロデューサが実行され、そして全ての依存性が実行されたところのプロデューサに対して集合が繰り返しスキャンされ、最終的には、根ノードに到達する。別の例として、本発明の一実施形態では、実行スタートプロデューサが実行され、実行スタートプロデューサの親が識別され、それらの親が実行され、そしてそれらの親が識別されて実行され、等々となる。本発明の後者の実施形態を、一例として、非限定的に、以下に使用する。
依存性の例示的形式
例示的なダイナミックプロデューサ依存性
ダイナミックプロデューサ依存性は、ランタイム(run time)時まで解明できないプロデューサ依存性である。プロデューサ依存性を解明するための基準は、ソースコードに存在し、従って、プロデューサ依存性を解明できるプロデューサが制限される。図３Ａを参照すれば、プロデューサグラフ実行モジュール３４５から自動プロデューサグラフ発生モジュール３４０への矢印付き破線は、現在プロデューサグラフ全体を発見し構築するのに必要な現在プロデューサグラフにおける１つ以上のプロデューサを実行するためのサポートを表す。換言すれば、ダイナミックプロデューサ依存性をサポートする本発明の実施形態は、プロデューサグラフ全体が発見され、構築され、解明され及び実行されるまで、自動プロデューサグラフ発生モジュール３４０とプロデューサグラフ実行モジュール３４５との間を繰り返す（即ち、１）そのとき解明できる現在プロデューサグラフの部分を発見し構築するために自動プロデューサグラフ発生モジュールをインボークすることと、２）現在プロデューサグラフのプロデューサを実行するためにプロデューサグラフ実行モジュールをインボークすること、との間を繰り返す）。この意味で、発見とは、プロデューサ依存性宣言にアクセスし、それらが識別するプロデューサを決定することを指し、構築とは、プロデューサをロードし、それらをプロデューサグラフに追加することを意味し、そして解明とは、現在解明されていないダイナミックプロデューサ依存性を決定することを指す。
図５Ａは、本発明の一実施形態により未解明の依存性を含む例示的プロデューサグラフの発見及び構築を示すブロック図である。図５Ａは、プロデューサ１より成る、問題とするプロデューサの現在セットを示す。プロデューサ１及びそのプロデューサ依存性宣言に基づいて、プロデューサ２及びプロデューサ３が発見される。換言すれば、プロデューサ１の依存性宣言は、プロデューサ１がプロデューサ２及びプロデューサ３の出力を入力として要求することを示す。又、図５Ａは、プロデューサ３は、独立プロデューサ（従って、ソースプロデューサ）であるが、プロデューサ２は、そうでないことも示している。その結果、プロデューサ２の依存性宣言に基づいて、プロデューサ４及びプロデューサ５が発見される。更に、図５Ａは、プロデューサ４は、独立プロデューサ（従って、ソースプロデューサ）であるが、プロデューサ５は、そうでないことも示している。その結果、プロデューサ５の依存性宣言に基づいて、プロデューサ６及び現在未解明の依存性が発見される。又、図５Ａは、現在未解明の依存性がプロデューサ７Ａ及び／又はプロデューサ７Ｂに対するものであることも示している。
図５Ｂは、本発明の一実施形態により、図５Ａのプロデューサグラフの初期の実行と、未解明の依存性の解明とを示すブロック図である。図５Ｂは、図５Ａのプロデューサグラフを示すもので、矢印付きの曲線は、プロデューサの実行と、それら出力の、従属親プロデューサへの付与とを示している。更に、図５Ｂは、プロデューサ５の未解明の依存性がプロデューサ７Ａに対する依存性として解明され、そしてプロデューサ７Ａが独立プロデューサであることを示している。プロデューサ７Ａは、それ自身で実行されてもよいし、又はプロデューサ６とパラレルに実行されてもよいし、又はプロデューサ４とパラレルに実行されてもよいし、プロデューサ３とパラレルに実行されてもよいし、又はプロデューサ３、４及び６の組合せとパラレルに実行されてもよいことに注意されたい。このようなパラレル実行が許されるのは、プロデューサ７Ａがプロデューサ３、４及び６と独立しているからである。
図５Ｃは、本発明の一実施形態により、図５Ａのプロデューサグラフの初期の実行及び／又は図５Ｂのプロデューサグラフの再実行を示すブロック図である。図５Ｃは、図５Ａのプロデューサグラフを示すもので、矢印付きの曲線は、プロデューサの実行と、それら出力の、従属親プロデューサへの付与とを示している。更に、図５Ｃは、プロデューサ５の未解明の依存性がプロデューサ７Ｂに対する依存性として解明され、そしてプロデューサ７Ｂが独立プロデューサであることを示している。その結果、プロデューサ７Ｂの依存性宣言に基づいて、プロデューサ８が発見される。プロデューサ８は、独立プロデューサ（従って、ソースプロデューサ）である。図５Ｃが、図５Ａのプロデューサグラフの初期実行を表すと仮定すれば、図５Ｃにおける全ての矢印付き曲線が使用される。しかしながら、図５Ｃが、図５Ｂのプロデューサグラフの再実行を表すと仮定すれば、再実行の結果、ダイナミック依存性が異なる仕方で解明される（プロデューサ５がプロデューサ７Ａに依存することからプロデューサ７Ｂに依存することへとスイッチする）。更に、再実行が増分的実行を伴わずに行われる場合には、図５Ｃにおける全ての矢印付き曲線が使用されるが、増分的実行が使用される場合には、矢印付き非破線曲線しか使用されない（プロデューサ８からプロデューサ７Ｂへ、プロデューサ７Ｂからプロデューサ５へ、プロデューサ５からプロデューサ２へ、及びプロデューサ２からプロデューサ１へ）。又、図５Ｃに示す依存性のダイナミック変化は、例示に過ぎず、従って、多数の異なる状況が生じ得ることも理解されたい（例えば、ダイナミックな変化が決して生じない；プロデューサ５が最初はプロデューサ７Ｂに依存し、次いで、プロデューサ７Ａへと変化する；プロデューサ５が最初はプロデューサ７Ｂに依存し、且つダイナミックな変化は、ずっと生じない；プロデューサ５が図５Ｄに示すようにプロデューサ７Ａ及び７Ｂの両方に依存することが分かる；等々）。異なる実施形態では、異なる仕方でダイナミックプロデューサ依存性を解明できるが、幾つかの例について以下に述べる。
従って、プロデューサグラフの自動再実行は、プロデューサが変更され且つその直接的な親が再実行されることに制限されず、むしろ、変化が、ランタイムによりプロデューサグラフを通して自動的に波及されて、適切なプロデューサ及び依存性に影響を及ぼす。というのは、プロデューサグラフが維持される（且つ増分的実行がサポートされるところでそれが使用される）からである。従って、変化は、必要な付加的な発見、構築、解明及び実行を生じさせる。従って、プロデューサグラフの再実行は、プロデューサグラフのどのプロデューサが影響されるかユーザ／プログラマーが決定しておそらく手動でグラフを修正する必要がないという意味で、自動的である。
スタティックプロデューサ依存性
スタティック依存性とは、ランタイム(run time)時の前に知られているものである。従って、コンティンジェント及びサブスクリプションダイナミック依存性をサポートする実施形態では、非コンティンジェント及び非サブスクリプション依存性がスタティック依存性である。図４Ａの例示的なプロデューサグラフは、スタティック依存性のプロデューサグラフを示している。
プロデューサグラフ形状
オブジェクト指向のプログラミング言語におけるプロデューサは、少なくともクラス、そのクラスのインスタンス、及びそのインスタンスに関連したメソッドであるから、プロデューサグラフは、クラス、インスタンス及びメソッド中心である。従って、プロデューサグラフは、インスタンス及びそれらインスタンスに関連したメソッドを表すグラフであり、従って、プロデューサグラフは、少なくともインスタンス及びメソッド中心である。プロデューサが少なくともクラス、メソッド及びインスタンスである本発明の実施形態では、プロデューサグラフは、少なくともクラス、メソッド及びインスタンス中心である。
プロデューサグラフは、種々の異なる形状（例えば、プロデューサの単一チェーン、ツリー、等）をとり得ることを理解されたい。図５Ｂの例示的プロデューサグラフは、プロデューサ１の根ノードがあって、そこから、プロデューサ２及びプロデューサ３の各々へ２つの分岐があるツリーである。プロデューサ３が葉ノードである場合には、プロデューサ２は、そこから、プロデューサ４及びプロデューサ５の各々へ延びる２つの分岐を有する。プロデューサ５は、そこから、プロデューサ６及びプロデューサ７Ａへ各々延びる２つの分岐を有する。図５Ｂの例示的プロデューサグラフは、マルチレベルと言われ、レベル１は、根ノードプロデューサ１を含み、レベル２は、プロデューサ２及びプロデューサ３を含み、レベル３は、プロデューサ４及びプロデューサ５を含み、レベル４は、プロデューサ６及びプロデューサ７Ａを含む（図５Ｃでは、レベル４は、プロデューサ７Ｂを含み、そしてレベル５は、プロデューサ８を含む）。ある実施形態では、パラレル化は、各レベルのプロデューサをパラレルに実行することにより具現化できる。プロデューサの実行は、図５Ｃにおけるレベル５のような最低レベルのプロデューサで始まり、次いで、レベルごとにアップ方向に移動する。あるレベルにおけるプロデューサの実行をスタートする前に、ランタイムは、手前の低いレベルにおける全てのプロデューサがレディとなり、即ち手前の低いレベルにおけるプロデューサの出力が返送されるまで、待機する。プロデューサ２を伴うプロデューサ１からの分岐を考慮するときには、分岐の第１プロデューサは、プロデューサ２であり、そして分岐の最後のプロデューサは、図５Ｂにおいて、プロデューサ４、プロデューサ６及びプロデューサ７Ａである。
図５Ｂは、問題とするプロデューサの現在セットが単一プロデューサを含むようなプロデューサグラフを示すが、問題とする２つ以上の現在プロデューサをサポートする本発明の実施形態は、その各々に対してプロデューサグラフを発見し構築する。問題とするプロデューサが同時に複数ある場合には、それにより得られるプロデューサグラフは、独立でもよいし、又は交差してもよいことを理解されたい。プロデューサグラフが交差する場合には、本発明の実施形態は、次のように具現化できる。即ち、１）個別のプロデューサグラフを維持するようにプロデューサを複製する；又は２）このような複製を回避し、交差するプロデューサグラフを維持する。又、このような交差するプロデューサグラフは、別のプロデューサグラフのサブセットであるプロデューサグラフを含んでもよいことも理解されたい。例えば、プロデューサ５が、問題とするプロデューサの現在セットにプロデューサ１と共に含まれた場合には、プロデューサ５の根ノードを伴う第１プロデューサグラフと、プロデューサ１の根ノードを伴う第２プロデューサグラフとがあり、ここで、第２プロデューサグラフが第１プロデューサグラフを含む。例えば、プロデューサ７Ｂが、問題とするプロデューサの現在セットにプロデューサ１及びプロデューサ５と共に含まれた場合には、第１及び第２のプロデューサグラフとは個別で、図５Ｂにおけるプロデューサ７Ｂの根ノードを伴う第３のプロデューサグラフがある。更に、プロデューサ５のダイナミック依存性がプロデューサ７Ａからプロデューサ７Ｂへと変化した場合には（図５Ｃ）、この変化の結果、第２プロデューサグラフ及び第３プロデューサグラフが残され（第１プロデューサグラフはそのようにならないが）、第３プロデューサグラフは、残っている第２プロデューサグラフのサブセットとなり、そして第２プロデューサグラフは、第１プロデューサグラフのサブセットとなる。上述したように、本発明の実施形態は、プロデューサグラフ（１つ又は複数）の合併及び分割を容易にするために、（グラフの集合ではなく）グラフを形成するように互いにリンクされるプロデューサの集合としてプロデューサグラフ（１つ又は複数）を記憶し操作することができる。一例として、これに限定されないが、プロデューサの集合としてプロデューサグラフ（１つ又は複数）を記憶し操作する本発明の実施形態をここに説明する。
例示的実行フロー
図６は、本発明の一実施形態により、ランタイムクライアントの論理的実行フローと、プロデューサグラフ指向のプログラミングサポートを伴うランタイムに対するその関係とを示すフローチャートである。図６において、破線の分割線６００は、ランタイムクライアント６１０の論理的実行フローを、プロデューサグラフ指向のプログラミングサポートを伴うランタイム６４０から分離している。
ランタイムクライアント６１０の論理的実行フローは、ブロック６１５、６２０、６２５及び６３０を含み、一方、プロデューサグラフ指向のサポートを伴うランタイム６４０は、ブロック６４５、６５０、６６０及び任意の６５５を含む。矢印付きの実線は、ブロック６３０からブロック６６０への直接的因果関係を示す。対照的に、矢印付きの点線は、ランタイムクライアント６１０の論理的実行フローにおけるブロック６１５及び６２５から、プロデューサグラフ指向のサポートを伴うランタイムにおけるブロック６４５及び６５０への因果関係を各々示し、本発明の実施形態に基づき、この因果関係は、直接的でも間接的でもよい。例えば、図６は、破線６００の、プロデューサグラフ指向のサポートを伴うランタイム６４０の側で、破線楕円におけるコマンドログ６６５の使用により任意の間接的な因果関係を示す。コマンドログ６６５は、コマンドログ６６５は、ランタイムクライアント６１０の論理的実行フローのブロック６１５及び６２５から生じるコマンドを収集し、そしてコマンドログ６６５は、ブロック６３０に応答して、処理ブロック６６０により消費される。従って、コマンドログ６６５は、コマンドを遅延させて、複数のコマンドを一緒に収集し、それらを最適化のためにバッチ処理できるようにする。従って、コマンドログ６６５は、図３Ｂのオーバーライドログ３９６と同様であり、実際上、本発明の幾つかの実施形態にはオーバーライドログ３９６が含まれる。
ブロック６１５において、問題とする１つ以上のプロデューサのセットは、問題とするプロデューサの現在セットとして決定され、制御がブロック６２０へ通される。ブロック６１５とブロック６４５との間の因果関係に応答して、ブロック６４５は、問題とするプロデューサの現在セットがインスタンス生成されることを示すと共に、ランタイムクライアント６１０におけるプロデューサ依存性宣言に基づき、インスタンス及びそのプロデューサを必要に応じてインスタンス生成することも含めて、各々プロデューサグラフ（１つ又は複数）を発見し、構築し、且つ解明するよう試みる（ダイナミック依存性がサポートされ且つその１つ以上がプロデューサグラフにおいて発見される場合に）ことを示す。図３Ａ及び３Ｂを参照すれば、自動プロデューサグラフ発生モジュール３４０及び３６５が各々インボークされる。
ブロック６２０において、プロデューサ出力オーバーライドがあるかどうか決定される。もしあれば、制御がブロック６２５へ回され、さもなければ、制御がブロック６３０へ回される。
ブロック６２５において、１つ以上のプロデューサ出力オーバーライドが、１つ以上のプロデューサのセットに対して受け取られ、制御がブロック６３０へ回される。ブロック６２５とブロック６５０との間の因果関係に応答して、ブロック６５０は、オーバーライドされたプロデューサの現在セットがインスタンス生成され（ブロック６４５においてまだインスタンス生成されていない場合）、それらの出力が変更され、そしてそれらが追跡されることを示す。オーバーライドされたプロデューサは、ブロック６４５においてプロデューサグラフ（１つ又は複数）の一部分であることが既に発見されているので、既にインスタンス生成されているかもしれない。しかしながら、オーバーライドされたプロデューサは、未解明のダイナミック依存性のものであるので、ブロック６４５においてまだ発見されていないかもしれない。従って、このオーバーライドされたプロデューサは、ダイナミック依存性が解明されたときにプロデューサグラフに追加されることを予想して、インスタンス生成されオーバーライドされる。又、既に述べたように、図３Ｂのオーバーライドログ３９６は、それが具現化された場合に、ブロック６２５とブロック６５０との間に存在し、そしてコマンドログ６６５の一部分となる。更に、オーバーライドされたプロデューサのセットは、増分的実行をサポートする本発明の幾つかの実施形態において追跡される。オーバーライドログ３９６／コマンドログ６６５をサポートする本発明の実施形態において、追跡はログの一部分であるが、本発明の別の実施形態では、追跡は、異なるメカニズムを伴うブロック６５０において個別に遂行される。
ブロック６３０において、プロデューサグラフ実行モジュールがインボークされ、そして制御がブロック６１５及び／又はブロック６２５へ任意に戻される。ブロック６３０とブロック６６０との間の因果関係に応答して、ブロック６６０は、現在プロデューサグラフ（１つ又は複数）がウォーキングされ、そして実行を要求するプロデューサが、追跡に基づいて実行される。プロデューサグラフのプロデューサを実行するための種々の技術が上述され、それらをここに適用することができる。図３Ａ及び３Ｂを参照すれば、プロデューサグラフ実行モジュール３４５及び３７０が各々インボークされる。更に、コマンドログ６６５が具現化される本発明の実施形態では、因果関係は、コマンドログ６６５を消費し、そしてブロック６６０の前に処理ブロック６４５及び６５０を遂行することを含む。更に、未解明の依存性の可能性をサポートする本発明の実施形態では、制御が必要なときにブロック６６０からブロック６６５へ流れる。
ブロック６５５において、未解明の依存性を解明し、そしてインスタンス及びそのプロデューサをインスタンス生成することを含めて、プロデューサグラフ（１つ又は複数）の残りを発見し構築するように試みられる。ブロック６５５から、制御は、ブロック６６０へ戻される。
プロデューサ依存性宣言の例示的形態
図７Ａ−Ｆは、本発明の一実施形態によるプロデューサ依存性宣言に対する幾つかの例示的形態を示す。図７Ａ−Ｆは、引数、フィールド及びシーケンス依存性をサポートする実施形態を示すが、異なる実施形態が、３つの依存性形態のうちの１つ又は２つだけをサポートしてもよいことが理解されよう。図７Ａ−Ｆに示す本発明の実施形態では、プロデューサ依存性宣言は、プロデューサ依存性宣言ステートメント、及び任意のものとして、明示的プロデューサ依存性宣言コードで構成される。非ショートカット宣言プロデューサ依存性は、明示的プロデューサ依存性宣言コードが使用されるものであり、一方、ショートカット宣言プロデューサ依存性は、明示的プロデューサ依存性宣言コードが使用されない（むしろ、ランタイムがプロデューサ依存性宣言コードを使用せず、及び／又はそれを、プロデューサ依存性宣言ステートメントの情報に基づいてオンザフライで具現化する）ものである。
本発明の異なる実施形態は、プロデューサ依存性を宣言するために異なるシンタックスを使用することができる。例えば、本発明の異なる実施形態は、生成できるプロデューサ依存性の形式を強く制約し、弱く制約し、及び／又は制約しない異なるシンタックを、プロデューサ依存性宣言ステートメントに使用するために含ませることができる。強く制約されるプロデューサ依存性は、生成できるプロデューサ依存性の形式を実質的に制限するシンタックスがプロデューサ依存性宣言ステートメントに使用されるというものであり、弱く制約されるプロデューサ依存性は、生成できるプロデューサ依存性の形式をあまり制限しないシンタックスがプロデューサ依存性宣言ステートメントに使用されるというものであり、そして非制約のプロデューサ依存性は、生成できるプロデューサ依存性の形式を制限しないシンタックスがプロデューサ依存性宣言ステートメントに使用されるというものである。
例えば、これに限定されないが、以下に述べる本発明の実施形態は、次のものを含む。即ち、１）引数に対して強く制約されたプロデューサ依存性のためのシンタックス（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は、図示されていないが、図７Ｇを参照して詳細に説明する）。従って、プロデューサ依存性宣言ステートメント７０５の引数は、メソッドアルファ７１０の引数に対応し、そしてプロデューサ依存性宣言ステートメント７０５における引数の引数ＩＤは、それらが識別する子プロデューサに関して追跡される。
図７Ｃは、本発明の一実施形態により非ショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示すと共に、例示的プロデューサのブロック図である。図７Ｃは、図７Ａのプロデューサ依存性宣言ステートメント７０５及びメソッドアルファ７１０を示すと共に、図７Ｂのプロデューサ７２０及び７２５を示す。更に、図７Ｃは、引数依存性１に関連したプロデューサ依存性宣言コード７１５も含む。ランタイム中に、ランタイムは、プロデューサ依存性宣言ステートメント７０５の引数依存性１に応答してプロデューサ依存性宣言コード７１５にアクセスして実行する。プロデューサ依存性宣言コード７１５の実行は、プロデューサ７２５を引数依存性１のためのプロデューサ依存性として返送する。従って、図７Ｃは、プロデューサ依存性宣言コード７１５が（メソッドアルファ７１０以外の）メソッドの一部分でよいが、プロデューサの一部分ではないような本発明の実施形態を示す。
図７Ｄは、本発明の一実施形態により非ショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図７Ｅは、 本発明の一実施形態による例示的プロデューサのブロック図である。図７Ｄは、図７Ａのプロデューサ依存性宣言ステートメント７０５及びメソッドアルファ７１０を示し、一方、図７Ｅは、図７Ｂからのプロデューサ７２０及び７２５を示す。更に、図７Ｄは、１）プロデューサ依存性宣言ステートメント７５０、及び２）プロデューサ依存性宣言コード７６０を含むメソッドベータ７５５も示している。又、図７Ｄは、プロデューサ依存性宣言ステートメント７０５の引数依存性１が、引数依存性１に対して依存性を返送するメソッドベータ７５５に基づいてプロデューサ（図７Ｅにプロデューサ７６５として示された）を識別することも示している。ランタイム(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及び２１。
図８Ｄの場合と同様に、図８Ｅは、ゲットプロパティメソッドがマップされたビューアのセルがオーバーライドされることも示している。例えば、図８Ｆは、ゲットプロパティメソッド「誕生日」がマップされた列の第２行のセルがオーバーライドされた場合、出力が現在そのセルにポピュレートしているプロデューサの出力のオーバーライド、グローバルな実行コマンドのインボケーション（これは、ゲットプロパティメソッド「年齢」がマップされたセルに出力が現在ポピュレートしているプロデューサの再実行を生じさせる）、及びディスプレイの必要な更新を引き起こすことを示している。
図８Ｃ−Ｆは、構成及びマッピンググラフィックユーザインターフェイスモジュール８４２により発生されるスクリーンを例示している。レンダリング及びインタラクティブなグラフィックユーザインターフェイスモジュール８４６により発生されるスクリーンは、（ゲットプロパティメソッドを伴う）クラス８５２のリスト、構成及びマッピングビューア８５４が、表示される構成及びマッピングビューア８５４と同じ映像を含むレンダリング及びインタラクティブなビューア（図示せず）に置き換えられることを除いて、同じである（相違は、マッピング特徴がもはや得られないことである）。
例示的ランタイム配布スキーム
図９Ａ−Ｃは、本発明の一実施形態によるプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための種々のスキームを示す。これらの配布スキームは、例示に過ぎず、従って、本発明の範囲内で他のスキームも考えられる。
図９Ａは、本発明の一実施形態によるプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第１のスキームを示すブロック図である。図９Ａにおいて、オブジェクト指向のソースコード９０５（プロデューサ依存性宣言を含む）が、プロデューサグラフ指向のプログラミングサポートを伴うランタイム９１０の上に示されており、このランタイムは、クラスローディング、ダイナミッククラスインスタンス生成、ダイナミック単一メソッドインボケーション、及びクラス／メソッドイントロスペクションを伴うランタイム９１５の上にあり、そしてこのランタイムは、オペレーティングシステム９２０の上にある。図９Ａにおいて、ランタイム９１０は、ランタイム９１５と共に働く。ランタイム９１０をランタイム９１５と共に働かせるのに多数のメカニズムを使用できるが、一例として、メタデータファシリティについて説明する。メタデータファシリティは、付加的な情報をソースコードに追加することができ、この情報は開発ツールにより使用される。例えば、Ｊａｖａ仕様のメタデータファシリティは、開発ツール、配備ツール又はランタイムライブラリーにより特殊な仕方で処理されねばならないことを指示する特殊な属性を有するとしてフィールド、メソッド及びクラスにアノテーション付けするためのＡＰＩを定義する（Ｊａｖａ仕様要求１７５）。この例では、オブジェクト指向のソースコード９０５をプログラミングするプログラマーは、プロデューサ依存性宣言の形態でメソッドにアノテーションを追加する。これらアノテーションは、ランタイム９１５によりランタイム９１０へハンドオフされるので、ランタイム９１０は、プロデューサ依存性宣言のシンタックスを指令する。図９Ａにおいて、ランタイム９１０及び９１５は、異なる組織によって開発され及び／又は配布されてもよい。
図９Ｂは、本発明の一実施形態によるプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第２のスキームを示すブロック図である。図９Ｂにおいて、オブジェクト指向のソースコード９２５（プロデューサ依存性宣言を含む）がランタイム（クラスローディング、ダイナミッククラスインスタンス生成、ダイナミック単一メソッドインボケーション、及びクラス／メソッドイントロスペクション、並びにプロデューサグラフ指向のプログラミングサポートを伴う）９３０の上に示されており、そしてこのランタイムは、オペレーティングシステム９３５の上にある。図９Ａとの比較において、ランタイム９１０及び９１５が単一のランタイム９３０へと合成されている。この合成の結果として、ランタイム９３０は、プロデューサ依存性宣言のシンタックスを指令する。従って、オブジェクト指向のソースコード９２５をプログラミングするプログラマーは、要求されるシンタックスにプロデューサ依存性宣言を追加する。
図９Ｃは、本発明の一実施形態によるプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第３のスキームを示すブロック図である。図９Ｃにおいて、オブジェクト指向のソースコード９４０（プロデューサ依存性宣言を含む）がオペレーティングシステムランタイム（クラスローディング、ダイナミッククラスインスタンス生成、ダイナミック単一メソッドインボケーション、及びクラス／メソッドイントロスペクション、並びにプロデューサグラフ指向のプログラミングサポートを伴う）９４５の上に示されている。図９Ｂと比較して、ランタイム９２０及びオペレーティングシステム９３５が単一エンティティへと合成されている。この合成の結果として、オペレーティングシステムランタイム９４５は、プロデューサ依存性宣言のシンタックスを指令する。従って、オブジェクト指向のソースコード９４０をプログラミングするプログラマーは、要求されるシンタックスにプロデューサ依存性宣言を追加する。
ランタイムが、クラスローディング、ダイナミッククラスインスタンス生成、ダイナミック単一メソッドインボケーション、及びクラス／メソッドイントロスペクションを有するような実施形態を説明したが、別の実施形態は、より多くの又はより少ない特徴を含んでもよい（例えば、インスタンスクローンニング、ダイナミックプロキシー、プリミティブ形式変換、等）。
例示的効果
本発明の一実施形態においては、手動インボケーションシーケンスコードを使用せずに適切なインスタンスを使用して（ここで、適切なインスタンスは、引数として使用すべきインスタンス、インスタンスメソッドにより使用されるべきインスタンス、及びクラスメソッドにより使用されるメタクラスインスタンスを含む）メソッドインボケーションシーケンスを指定する仕方としてメソッドに対してプロデューサ依存性が宣言された。実際に、手動インボケーションシーケンスコードの幾つか又は全部を発生する作業は、次のものに置き換えられる。即ち、１）プロデューサ依存性宣言を書き込むためにアプリケーションプログラマーによって行われる作業；及び２）プロデューサグラフ（１つ又は複数）を発見及び構築し、そしてこれらプロデューサグラフ（１つ又は複数）のプロデューサを実行するためにランタイムにより行われる作業。換言すれば、手動インボケーションシーケンスコードに以前に含まれていたロジックは、プロデューサ依存性宣言に基づき、ランタイム(run time)中に、ランタイム(runtime)により発見することができる。従って、プロデューサ依存性宣言は、どんな引数を伴うどんなインスタンスのどんなメソッドを同期のためにいつ実行すべきかランタイムへ通知する。ランタイムを書くための努力は、比較的多大であるが、ランタイムに対して書かれたオブジェクト指向のアプリケーションを実行するのに使用できるという点で、一度書くだけでよく、対照的に、典型的なアプリケーションの場合、プロデューサ依存性宣言を書くための努力は、手動インボケーションシーケンスコードを書くことに比べて比較的僅かである。
プログラミングミステークの減少
プロデューサグラフ指向のプログラミングは、典型的に、手動インボケーションシーケンスコードのデバッグ及び／又は性能同調に関するコストを減少する。これは、少なくとも、アプリケーションプログラムのインフラストラクチャーが、概念的に、特定入力に対して動作するオブジェクトの変換メソッドの非公式化グラフのセットである（オブジェクトの１つのメソッドの出力は、別のメソッドへの入力となり、等々）という理由で言えることである。プロデューサ依存性宣言、及びプロデューサグラフ指向のプログラミングサポートを伴うランタイムは、これらのグラフをプロデューサグラフとして公式化する。従って、データが変化する機会のたびに、アプリケーションプログラマーは、適切なインスタンスの適切な変換メソッドを適切な入力と共に適切な順序でインボークさせるために、その作用を考慮して手動インボケーションシーケンスコードを書き込む必要がない。換言すれば、データが変化する機会のたびに、アプリケーションプログラマーは、どのグラフが影響を受けるか、及びそれらグラフ内のインスタンスのどの変換メソッドが影響を受けるか考慮する必要がない。むしろ、自動プロデューサグラフ発生モジュールがプロデューサグラフを発見及び構築し、そしてプロデューサグラフ実行モジュールが、データの変化を反映するように、必要に応じてプロデューサグラフを再実行する。この自動化は、次のようなミステークを回避する上でアプリケーションプログラマーの助けとなる。１）適切なインスタンスの適切な変換メソッドを間違った順序でインボークし、２）グラフにおけるインスタンスの１つ以上の要求された変換メソッドをあるデータの変化に応答してインボークさせるためのコマンドを入れ忘れ、３）あるデータの変化に応答してインスタンスの不必要な変換メソッドをインボークさせるコマンドを含ませる（例えば、データの変化により影響されるグラフの部分でないインスタンスの変換メソッドをインボークするコマンドを含ませ；データの変化により影響されるグラフの部分であるが、それ自身は影響のないインスタンスの変換メソッドをインボークするコマンドを含ませ；等々）。
同期
上述したように、実行中にプロデューサ出力をキャッシュ記憶することで、同期をとることができる。従って、オブザーバーパターンとの比較に関して、プロデューサ依存性宣言は、プロデューサグラフ指向のプログラミングサポートを伴うランタイムに依存性を通知し、そしてランタイムは、どんなプロデューサがいつコールバックするか決定する。
結果を完全に説明する能力
本発明の一実施形態では、ドリル／ビュー(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（これは２つのエレメントを保持する：即ち、キー識別子がインスタンス又は別のオブジェクト（ストリングのような）に対するリファレンスであるかどうか指示するインスタンスキーネイチャー；及びインスタンス又は別のオブジェクト（ストリングのような）のいずれかに対するリファレンスであるキー識別子）のインスタンスであるインスタンスキーもサポートする本発明の実施形態では、ブロック１５２０及び１５３０は、プロデューサグラフ指向のプログラミングサポートを伴うランタイムが気付くやり方でインスタンス及びクラスがインスタンス生成され／ロードされるかどうか問合せする。プロデューサグラフ指向のプログラミングサポートを伴うランタイムが、既にロードされたクラスに気付かないケースでは、クラスがロードされず、クラスは、クラス追跡構造１０９２に追加され、そしてメソッドは、メソッド追跡構造１０５８に追加される。プロデューサグラフ指向のプログラミングサポートを伴うランタイムが、既にインスタンス生成されたインスタンスに気付かないケースでは、インスタンスがインスタンス生成されず、インスタンスは、インスタンス追跡構造１０６５に追加される。
新プロデューサ及び非オーバーライドコマンド
図１６Ａは、本発明の一実施形態により新たなプロデューサをインスタンス生成し、そしてプロデューサを非オーバーライドするためのフローチャートである。図１０を参照すれば、図１６Ａのフローは、自動プロデューサグラフ発生モジュール１０４０及びオーバーライドプロデューサモジュール１０４５（又は図１０に関する別の実施形態を参照して述べるように、オーバーライド及び非オーバーライドを取り扱うモジュール）により遂行される。
新プロデューサコマンドに応答して（ブロック１６００）、制御はブロック１６０５へ進む。本発明の一実施形態では、新プロデューサコマンドは、種々の状況に応答して実行することができる。以下のテーブル２は、本発明の一実施形態によりパスされる種々の状況及びパラメータを示す。
テーブル２
Figure 0005354601
ブロック１６０５において、プロデューサが既に存在するかどうか決定される。存在しなければ、制御はブロック１６１０へ進み、さもなければ、制御はブロック１６７０へ進む。ブロック１６０５は、新プロデューサコマンドの一部分として（例えば、キー及び／又はリファレンスにより）識別されたクラス、インスタンス及びメソッドにアクセスすることにより遂行される。プロデューサキーをサポートする一実施形態では、ブロック１６０５は、新プロデューサコマンドの一部分として与えられたプロデューサキー（テーブル２の被呼プロデューサ列におけるプロデューサキー）に対して図１０のプロデューサグラフ（１つ又は複数）構造１０６０にアクセスすることにより遂行される。
ブロック１６１０では、新インスタンスモジュールが新インスタンスコマンドでコールされ、制御はブロック１６１５へ進む。本発明の一実施形態では、ブロック１６１０は、テーブル２の被呼プロデューサ列のプロデューサキーからのインスタンスキーを使用して図１５のフローチャートをコールすることにより遂行される。
ブロック１６１５では、プロデューサのインスタンスのクラス定義がアクセスされ、制御はブロック１６２０へ進む。図１０を参照すれば、クラス追跡構造１０９２に基づいてクラス１０５４の適切な１つにアクセスするために、テーブル２の被呼プロデューサ列におけるプロデューサキーからのクラスキーを使用することによりブロック１６１５が遂行される。
ブロック１６２０では、プロデューサのメソッド及びプロデューサ依存性宣言ステートメントがアクセスされ、制御はブロック１６２３へ進む。図１０を参照すれば、ブロック１６１５で位置付けられたクラスからメソッド及びプロデューサ依存性宣言１０５６の適切な１つにアクセスするために、テーブル２の被呼プロデューサ列におけるプロデューサキーからメソッドキーを使用することによりブロック１６２０が遂行される。
ブロック１６２３では、プロデューサ実行モードが決定され、制御はブロック１６２５へ進む。ブロック１６２３が遂行される１つの例示的なやり方を以下に説明する。幾つかの実施形態では、デフォールト実行モードは、コードレベルにおいてアノテーションとして定義される。振舞いは、エンドユーザによるか又はクライアントコードによりプロデューサベースの構成可能な判断構造（例えば、図１０のプロデューサベースの構成可能な判断構造１０４９）を通してクラスベース、メソッドベース、インスタンスベース又はその組合せでランタイムにおいてオーバーライドすることができる。更に、コンピューティング環境（例えば、単一マシンにおける多数のプロセッサの利用性、グリッドの利用性、プロセッサ（１つ又は複数）の負荷、等）に基づいて所定の実行モードで実行を強制的に行わせることによりこれらのプログラミングアノテーション又はユーザ定義構成をランタイムが無視できるようにランタイム設定を与えることができる。
ブロック１６２５では、プロデューサグラフにプロデューサが追加され、制御はブロック１６３０へ進む。図１１Ｃにおける本発明の実施形態を参照すれば、最初の３つの列がポピュレートされる。
ブロック１６３０では、各々の登録されたサブスクリプションに対して、サブスクリプションフィルタリング基準が処理されて、プロデューサが一致するかどうか決定する。図１４Ａにおける本発明の実施形態を参照すれば、サブスクリプションは、それがサブスクリプションログに追加されたときに登録されたと考える。サブスクリプションを登録するための例示的オペレーションを以下に説明する。ブロック１６３０は、自動プロデューサグラフ発生とプロデューサグラフ実行との間に分割されるべきインスタンス生成されたプロデューサをスキャンする作業を許す任意の最適化である。従って、本発明の別の実施形態では、ブロック１６３０を遂行しなくてもよい。
ブロック１６３５では、プロデューサは、依存性のためにコールされた場合にプロデューサグラフ（１つ又は複数）にリンクされる。ブロック１６３５から、制御は、ブロック１６４０へ進む。ブロック１６３５を遂行する仕方は、新プロデューサコマンドが実行される状況に依存する。例えば、状況が、それが問題とするプロデューサであるか又はオーバーライドされるプロデューサであるというものである場合には、依存性のためにそれがコールされず、何も行われない。対照的に、状況が非サブスクリプション下方宣言である場合には、非サブスクリプション下方宣言依存性のためにそれがコールされ、図１１Ｃにおける本発明の実施形態を参照すれば、次のことが行われる。１）被呼子プロデューサの親プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１５０（テーブル２の被呼プロデューサ列）が、親発呼プロデューサの行に対する親プロデューサリファレンス（テーブル２の発呼プロデューサ列）、及び依存性決定プロデューサリファレンス（テーブル２の依存性決定プロデューサリファレンス列）で変更され；及び２）親発呼プロデューサの行の子プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１６０（テーブル２の発呼プロデューサ列）が、被呼子プロデューサの行に対する子プロデューサリファレンス（テーブル２の被呼プロデューサ列）、依存性決定プロデューサリファレンス（テーブル２の依存性決定プロデューサリファレンス列）、及びリンクモード（テーブル２のリンクモード列によりセットされる）で変更される。
対照的に、状況がスティッキーサブスクリプションである場合には、それは、識別されるトリガープロデューサのためにコールされたものであり、図１１Ｃにおける本発明の実施形態を参照すれば、次のことが行われる。１）発呼子プロデューサの親プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１５０（テーブル２の発呼プロデューサ列）が、親被呼プロデューサの行に対する親プロデューサリファレンス（テーブル２の被呼プロデューサ列）、及び依存性決定プロデューサリファレンス（テーブル２の依存性決定プロデューサリファレンス列）で変更され；及び２）親被呼プロデューサの行の子プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１６０（テーブル２の被呼プロデューサ列）が、発呼子プロデューサの行に対する子プロデューサリファレンス（テーブル２の発呼プロデューサ列）、依存性決定プロデューサリファレンス（テーブル２の依存性決定プロデューサリファレンス列）、リンクモード（テーブル２のリンクモード列によりセットされる）、及びスティッキーを指示するようにセットされたスティッキーインジケータで変更される。この点に関して、非サブスクリプション上方宣言依存性の状況は、スティッキーサブスクリプションと同様に取り扱われる。
ブロック１６４０において、プロデューサは、非実行とマークされ、制御はブロック１６４５へ進む。図１１Ｃにおける本発明の実施形態を参照すれば、適切な行の増分的実行マーキング列１１８０に、非実行指示がポピュレートされる。
ブロック１６４５では、プロデューサが何らかの依存性を有しそしてオーバーライドされないかどうか決定される。もしそうであれば、制御はブロック１６５０へ進み、さもなければ、制御はブロック１６６５へ進む。ブロック１６４５は、ブロック１６２０においてアクセスされたプロデューサ依存性宣言及びテーブル２のコール形式列をチェックすることにより遂行される。
ブロック１６５０では、現在解明されるべきプロデューサ依存性宣言の各依存性に対して、プロデューサの数が決定され、そして各々に対して新プロデューサコマンドがインボークされる。ブロック１６５０から、制御はブロック１６５５へ進む。本発明の異なる実施形態は、異なる時間に異なる形式の依存性を決定し、本発明の一実施形態においてブロック１６５０を遂行する仕方について以下に説明する。
ブロック１６５５では、プロデューサは、その全ての従属プロデューサが存在しそして実行された場合に実行スタートログに追加される。ブロック１６５５から、制御はブロック１６６０へ進む。このフローの現在繰り返しの一部分としてインスタンス生成される所与のプロデューサに対して、ブロック１６５５が遂行されるときには、従属プロデューサに対するこのフローの別の繰り返しのインボケーションでプロデューサの実行状態が返送される（ブロック１６６０を参照）（例えば、図１１Ｃの本発明の実施形態に関しては、適切な行（１つ又は複数）の増分的実行マーキング列１１８０からの状態）。全ての従属プロデューサが存在し且つ全ての従属プロデューサの実行状態が実行される場合には、現在繰り返しのプロデューサが実行スタートログに追加される。
ブロック１６６０では、プロデューサの実行状態がパラメータとして返送される。
ブロック１６６５では、プロデューサが実行スタートログに追加され、制御はブロック１６６０へ進む。
ブロック１６７０では、ブロック１６３５と同様に、プロデューサは、依存性のためにコールされた場合にプロデューサグラフ（１つ又は複数）にリンクされる。ブロック１６７０から、制御はブロック１６７５へ進む。種々の理由でブロック１６７０に到達する。例えば、プロデューサがプロデューサオーバーライドコマンドに応答して以前にインスタンス生成されたがプロデューサグラフにリンクされないために、ブロック１６７０に到達する。別の例として、プロデューサがプロデューサグラフの既に一部分でありそして別のものに追加される（例えば、問題とするプロデューサ、問題とするプロデューサの子孫、等であることに応答して以前にインスタンス生成された）ためにブロック１６７０に到達することがある。
ブロック１６７５では、オーバーライド、スティッキーサブスクリプション依存性、又は非サブスクリプション上方宣言依存性のために、新プロデューサフローがコールされるかどうか決定される。もしそうであれば、制御はブロック１６８０へ進み、さもなければ、制御はブロック１６６０へ進む。ブロック１６７５は、テーブル２のコール形式列をチェックして、それが、オーバーライドされたプロデューサに対するコールであるか、スティッキーサブスクリプション依存性に対するコールであるか、又は非サブスクリプション上方宣言依存性に対するコールであるか調べることにより、遂行される。
ブロック１６８０では、ブロック１６４０と同様に、プロデューサは、非実行とマークされ、制御はブロック１６６５へ進む。ブロック１６８０は、種々の理由で到達する。
プロデューサ非オーバーライドコマンドに応答して（ブロック１６９０）、制御はブロック１６９５へ進む。ブロック１６９５では、プロデューサが非オーバーライドとマークされ、制御はブロック１６４０へ進む。図１１Ｃの本発明の実施形態を参照すれば、プロデューサの行のプロデューサ出力キャッシング及びオーバーライドプロデューサ出力指示列１１７０がアクセスされ、そしてプロデューサがもはやオーバーライドされないことを指示するように変更される。このフローを続けると、ブロック１６４０は、ブロック１６４５へ通じ、又、プロデューサが何らかの依存性を有する場合には、ブロック１６５０へ通じ、これは、プロデューサのもとでのプロデューサグラフがまだない場合には、それを発見し構築するようにさせる。プロデューサのもとでのプロデューサグラフが既に発見され構築されている場合には、新プロデューサコマンドをインボークすると、フローが１６００から１６０５へ、１６７０へ、等々と進み、更に、ブロック１６６０においてプロデューサのもとでのグラフのプロデューサの実行状態を返送すると、ブロック１６５５において実行スタートログにプロデューサが追加されるかどうか決定される。しかしながら、プロデューサのもとでのプロデューサグラフが発見及び構築されない場合には、新プロデューサコマンドをインボークすると、それが発見及び構築され、フローは、１６００から１６０５へ、１６１０へ、等々と進む。
図１６Ｂは、本発明の一実施形態による図１６Ａのブロック１６２３のフローチャートである。従って、制御は、ブロック１６２０からブロック１６２３のブロック１６２３１へと進む。ブロック１６２３１では、ランタイム実行設定オーバーライドがチェックされる。次いで、ブロック１６２３３においてランタイム実行設定オーバーライドがイネーブルされるかどうか決定される。もしセットされる場合には、ブロック１６２３４においてランタイム実行に基づいて実行モードがセットされる。さもなければ、エンドユーザからの実行モード選択に対するプロデューサベースの構成可能な判断構造がブロック１６２３５においてチェックされて、そして制御はブロック１６２３６へ進む。ブロック１６２３６では、エンドユーザが実行モード選択を行ったかどうか決定される。もしそうであれば、ブロック１６２３７においてプロデューサベースの構成可能な判断構造における設定に基づいて実行モードがセットされる。さもなければ、ブロック１６２３８において、コードレベルでアノテーションとして定義された実行モードに対してプロデューサのメソッド定義がチェックされ、そしてアノテーションに基づいて実行モードがセットされる。ブロック１６２３８又はブロック１６２３７から、制御はブロック１６２３９へと進み、ブロック１６２３内の処理を終了させる。
図１７は、本発明の一実施形態による図１６のブロック１６５０のためのフローチャートである。従って、制御は、ブロック１６４５からブロック１６５０におけるブロック１７００へと進む。ブロック１７００において、プロデューサのプロデューサ依存性宣言における各依存性に対して（各ArgumentDependenciy、FieldDependency、SequencingDependency、UpwardDependency及びWeaklyConstrainedDependencyに対して１つづつ）、次のブロック１７０５−１７４５が遂行される。図１０及び１１Ｄを参照すれば、メソッド追跡構造がアクセスされ、プロデューサ依存性に関する情報が決定される。又、ブロック１７１５、１７２５、１７３０、１７４０、１７４５及び１７５０は、プロデューサグラフを実行する前に遂行されたときに最適となることも理解されたい。
ブロック１７０５では、依存性が、スティッキー依存性のために既にリンクされた引数依存性であるかどうか決定される。もしそうであれば、制御はブロック１７１０へ進み、そこで、この依存性に対してフローが完了し、さもなければ、制御はブロック１７１５へ進む。図１１Ｃに示す本発明の実施形態に関しては、スティッキーインジケータがチェックされ、この依存性の引数ＩＤがスティッキーサブスクリプション引数依存性を受けるか又は上方宣言引数依存性を受けるかを決定する。
ブロック１７１５では、依存性がコンティンジェント依存性であるかどうか決定される。もしそうであれば、制御はブロック１７２０へ進み、さもなければ、制御はブロック１７２５へ進む。ブロック１７１５は、依存性により識別された子プロデューサのプロデューサ依存性宣言をチェックして、それが空である（子プロデューサが独立プロデューサである）かどうか決定することにより、遂行される。図１３Ａ−Ｊを参照すれば、これは、破線の丸内の数字を伴うプロデューサ（例えば、図１３Ｄでは、プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡ）については真であるが、他のプロデューサ（例えば、図１３Ｄでは、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡ）については真でない。従って、図１３Ｄを参照すれば、ブロック１７１５は、丸１、４及び８により表わされる。ブロック１７１５及びそこからブロック１７２５−１７５０を通るフローは、最適なものであって、破線の丸内の数字を伴うプロデューサをプロデューサグラフに追加／リンクすることと、プロデューサを実行する作業を自動プロデューサグラフ発生とプロデューサグラフ実行との間で分割すること、の両方を回避する。
ブロック１７２０では、依存性決定プロデューサに対する新プロデューサコマンドがインボークされ、そしてフローが終了となる。例えば、図１３Ｄを参照すれば、ブロック１７２０は、丸５、６及び７で表わされたものを生じさせる。
ブロック１７２５では、依存性決定プロデューサが実行され、制御はブロック１７３０へ進む。例えば、図１３Ｄを参照すれば、ブロック１７２５が丸１１で示されている（従って、図１７のフローは、図１３Ｄの丸９及び１０が遂行されない前記実施形態を示している）。
ブロック１７３０では、依存性が非サブスクリプション依存性であるかどうか決定される。もしそうであれば、制御はブロック１７５０へ進み、さもなければ、制御はブロック１７４０へ進む。換言すれば、ブロック１７２５では、親プロデューサのプロデューサ依存性宣言の一部分である依存性決定プロデューサのメソッドにおけるプロデューサ依存性決定コードが実行される。この依存性がサブスクリプション依存性であるかどうか識別するこのプロデューサ依存性宣言コードが実行されると、親プロデューサのプロデューサ依存性の形式が決定される。図１３Ｄの例に関して、丸１１は、ブロック１７３０からブロック１７５０へ進む図１７のフローを生じさせる。
ブロック１７５０では、ブロック１７２５における依存性決定プロデューサの実行により返送されるプロデューサの数が決定され、そして１７２５において実行された依存性決定プロデューサリファレンスを含めて、テーブル２に示す引数を使用して、各々に対して新プロデューサコマンドがインボークされる。例えば、図１３Ｄを参照すれば、ブロック１７５０が丸１２及び１３と、丸Ｃ及びＤとを生じさせる。
図１４Ｂのアブソービングサブスクリプション実施例を参照すれば、ブロック１７２５は丸４を表し、これは、ブロック１７３０を通してブロック１７４０へと進むフローを生じさせる。
ブロック１７４０において、サブスクリプションがサブスクリプションログに追加され、そしてサブスクリプションがアブソービングである場合には、それが未完了とマークされる。ブロック１７４０から、制御はブロック１７４５へ進む。図１４Ａに示す本発明の実施形態を参照すれば、サブスクリプションログは、上述したようにサブスクリプションでポピュレートされる。
ブロック１７４５では、インスタンス生成された全てのプロデューサがスキャンされ、それらがサブスクリプションの基準に一致する（従って、トリガープロデューサである）かどうか調べられ、そして一致が処理される。
図１８は、本発明の一実施形態による図１７のブロック１７４５に対するフローチャートである。従って、制御は、ブロック１７４０から、ブロック１７４５におけるブロック１８００へ進む。ブロック１８００では、インスタンス生成される各プロデューサに対して、次のブロック１８１０−１８３０が遂行される。
ブロック１８１０では、プロデューサがサブスクリプションの基準を満足するかどうか決定される。もしそうであれば、制御はブロック１８１５へ進み、さもなければ、制御はブロック１８３０へ進み、そこで、現在処理されているプロデューサについてフローが終了となる。図１１Ｃ及び１４Ａに示す本発明の実施形態を参照すれば、プロデューサグラフ（１つ又は複数）がアクセスされ、それらが、サブスクリプションの基準を満足するプロデューサを含むかどうか決定する。
マッチングプロデューサを処理する仕方は、処理されるサブスクリプションの形式に依存する。ブロック１８１５を参照すれば、サブスクリプションがアブソービング形式である場合には、制御はブロック１８２５へ進み、さもなければ、制御はブロック１８２０へ進む。ブロック１８１５は、１７４０又は２２３５において追加されるサブスクリプションの形式に応答して遂行される。
ブロック１８２５では、マッチングプロデューサがサブスクリプションログに追加されそしてアブソービングサブスクリプションを伴うプロデューサがマッチングプロデューサにリンクされる。ブロック１８２５から、制御はブロック１８３０へ進む。図１１Ｃ及び図１４Ａ−Ｂに示す本発明の実施形態を参照すれば、次のことが行われる。１）トリガープロデューサ列１４１０のためのサブスクリプション基準からのサブスクリプション基準がブロック１８１０に使用され、そしてマッチングプロデューサが探索され（例えば、プロデューサ１５６０Ａ−Ｎの１つ）；２）マッチングプロデューサが、サブスクリプションの行においてマッチングプロデューサ列１４１５に追加され；そして３）アブソービングサブスクリプションを伴うプロデューサ（例えば、プロデューサ１４５０）が図１１Ｃのプロデューサグラフ（１つ又は複数）構造におけるマッチングプロデューサ（例えば、プロデューサ１４６０Ａ−Ｎの１つ）にリンクされる（所与のアブソービングサブスクリプションに対してサブスクリプションログ１４Ａの依存性決定プロデューサリファレンス列１４２１から抽出された依存性決定プロデューサリファレンスを使用して）。
ブロック１８２０では、生成されるべき親プロデューサに対して新プロデューサコマンドがインボークされる。ブロック１８２０から、制御はブロック１８３０へ進み、そこで、ブロック１８００において選択された現在プロデューサに対してフローが終了となる。図１４Ａ及び１４Ｃに示す本発明の実施形態を参照すれば、次のことが行われる。１）トリガープロデューサ列１４１０に対するサブスクリプション基準からのサブスクリプション基準がブロック１８１０において使用され、そしてマッチングプロデューサが探索され（例えば、プロデューサ１４７５）；そして２）次のようにセットされたテーブル２のパラメータで新プロデューサコマンドがインボークされる。ａ）コール形式はスティッキーサブスクリプションであり；ｂ）発呼プロデューサは、発呼子プロデューサ（例えば、プロデューサ１４７５）のプロデューサキーであり；ｃ）被呼プロデューサは、生成されるべき被呼親プロデューサ（例えば、プロデューサ１４８０）のプロデューサキーであり、このプロデューサキーは、生成されるべき親プロデューサに対するスティッキーサブスクリプション特性からの親クラス、インスタンス及びメソッドキー（図１４Ａ、列１４３０、１４３５及び１４３７）を使用して（インスタンスキーが空である場合には、発呼子プロデューサのインスタンスキーを使用して）形成され；及びｄ）被呼親プロデューサに対するリンクモード（図１４Ａ、リンクモード列１４２５）、並びにｅ）所与のスティッキーサブスクリプションに対するサブスクリプションログ１４Ａの依存性決定プロデューサリファレンス列１４２１から抽出される依存性決定プロデューサリファレンス。
図１９は、本発明の一実施形態による図１６のブロック１６３０のためのフローチャートである。従って、制御は、ブロック１６２５から、ブロック１６３０におけるブロック１９００へと進む。図１９は、図１８に非常に良く似ている。より詳細には、図１９のブロック１９１０、１９１５、１９２０及び１９３０は、ブロック１８１０、１８１５、１８２０及び１８３０と同一であり、一方、ブロック１９００及び１９２５は、ブロック１８００及び１８２５とは異なる。従って、相違点のみについてここに説明する。
ブロック１９００は、各登録されたサブスクリプションに対してフローが遂行されることを示し、一方、ブロック１８００は、各インスタンス生成されたプロデューサに対してフローが遂行されることを示す。従って、図１８のフローは、単一のサブスクリプションを中心として全てのプロデューサをスキャンするが、図１０のフローは、単一のプロデューサを中心として全てのサブスクリプションをスキャンする。
ブロック１９２５は、アブソービングサブスクリプションが未完了とマークされることを除いて、ブロック１８２５と同じである。図１４Ａに示す本発明の実施形態を参照すれば、適切な行における完了列１４２０が、未完了を示すように更新される。
図２０は、本発明の一実施形態による図１６のブロック１６３５及び１６７０のためのフローチャートである。従って、制御は、ブロック１６０５及びブロック１６３０から、ブロック１６３５及び１６７０におけるブロック２００５へ進む。ブロック２００５において、図１６のフローチャートのこの繰り返しが、依存性のために（例えば、以前の繰り返しのブロック１６３０（ブロック１９２０）又は１６５０（ブロック１７２０、１７５０又は１７４５／１８２０から）インボークされたものであるかどうか決定される。もしそうでなければ、制御は、どこからフローに入ったか（ブロック１６３０又は１６０５から）に基づいてブロック１６４０又は１６７５へ進む。
ブロック２０１０において、フローがスティッキーサブスクリプション又は非サブスクリプション上方宣言状態のためにコールされたかどうか決定される。もしそうでなければ、制御はブロック２０１５へ進み、さもなければ、制御はブロック２０２０へ進む。ブロック２０１０は、テーブル２からのコール形式パラメータ（即ち、コール形式がスティッキーサブスクリプション又は非サブスクリプション上方宣言であるかどうか）をチェックすることにより遂行される。図１８及び１９に示す本発明の実施形態を参照すれば、新プロデューサコマンドは、ブロック１８２０又は１９２０からインボークされる。
ブロック２０２０では、現在親プロデューサが、発呼側の子プロデューサにリンクされる。図１１Ｃ及び図１４Ｃに示す本発明の実施形態を参照すれば、テーブル２の被呼プロデューサ列からのパラメータにより識別された被呼親プロデューサ（例えば、プロデューサ１４８０）は、図１１Ｃのプロデューサグラフ（１つ又は複数）構造において、テーブル２のリンクモード及び依存性決定プロデューサリファレンス列からのパラメータにより識別されたリンクモード及び依存性決定プロデューサリファレンスを使用して、テーブル２の発呼プロデューサ列からのパラメータにより識別された発呼子プロデューサ（例えば、プロデューサ１４７５）へリンクされる。親が以前に存在した場合には、ブロック２０２０の振舞いは、０以上の子プロデューサへマップできる引数が１つであるという意味で、アブソービングサブスクリプション依存性の振舞いと同様になる。
ブロック２０１５では、発呼親プロデューサは、現在被呼子プロデューサにリンクされる。図１１Ｃに示す本発明の実施形態を参照すれば、テーブル２の発呼プロデューサ列からのパラメータにより識別された発呼親プロデューサは、図１１Ｃのプロデューサグラフ（１つ又は複数）構造において、テーブル２の依存性決定プロデューサリファレンス列により識別された依存性決定プロデューサリファレンスを使用して、テーブル２の被呼プロデューサ列からのパラメータにより識別された被呼子プロデューサにリンクされる。ブロック２０１５及び２０２０から、制御は、フローがどこに入ったか（ブロック１６０５又は１６３０から）に基づいてブロック１６４０又は１６７５へ進む。
図２１Ａは、本発明の一実施形態によりプロデューサをオーバーライドするためのフローチャートである。図１０を参照すれば、図２１Ａのフローは、オーバーライドプロデューサモジュール１０４５（又は図１０に関する別の実施形態を参照して述べたように、オーバーライド及び非オーバーライドを取り扱うモジュール）により遂行される。
オーバーライドプロデューサコマンドに応答して（ブロック２１１０）、制御はブロック２１２０へ進む。ブロック２１２０では、オーバーライドプロデューサコマンドにより識別されたプロデューサに対して新プロデューサコマンドがインボークされ、制御はブロック２１３０へ進む。ブロック２１２０は、本発明の一実施形態では、オーバーライドされるべきプロデューサがまだインスタンス生成されていない場合、プロデューサを非実行とマークし（ブロック１６４０又は１６８０）そしてそれを実行スタートログにログする（ブロック１６６５）ように遂行される。まだインスタンス生成されていないプロデューサのオーバーライドを許さない本発明の別の実施形態では、ブロック１６０５と１６１０との間で付加的なチェックを行って、この新プロデューサコマンドがオーバーライドプロデューサコマンドに応答してコールされたかどうか決定し、そしてこの新プロデューサコマンドがオーバーライドプロデューサコマンドに応答してコールされた場合にはエラーを指示する。
ブロック２１３０では、プロデューサ出力キャッシュ（及びフィールドの場合にはインスタンス）における出力がセットされ、そしてプロデューサが、オーバーライドされたとしてマークされる。
図２１Ｂは、本発明の一実施形態によりプロデューサ実行モードをオーバーライドするためのフローチャートである。図１０を参照すれば、図２１Ｂのフローは、パラレル化モジュール１０７６（又は図１０に関する別の実施形態を参照して述べたように、パラレル化を取り扱うモジュール）により遂行される。
オーバーライド実行モードコマンドに応答して（ブロック２１５０）、制御はブロック２１５５へ進む。ブロック２１５５では、プロデューサグラフ構造１０６０においてプロデューサ実行モード設定がオーバーライドされる。
図２１Ｃは、本発明の一実施形態によりプロデューサ実行モードをオーバーライドするためのフローチャートである。図１０を参照すれば、図２１Ｃのフローは、パラレル化モジュール１０７６（又は図１０に関する別の実施形態を参照して述べたように、パラレル化を取り扱うモジュール）により遂行される。
ランタイム実行モード設定オーバーライドコマンドに応答して（ブロック２１６０）、制御はブロック２１６５へ進む。ブロック２１６５では、ランタイム設定構造１０４８においてプロデューサ実行モード設定がグローバルにオーバーライドされる。
図２１Ｄは、本発明の一実施形態によりプロデューサ実行モードをオーバーライドするためのフローチャートである。図１０を参照すれば、図２１Ｃのフローは、パラレル化モジュール１０７６（又は図１０に関する別の実施形態を参照して述べたように、パラレル化を取り扱うモジュール）により遂行される。
構成可能な実行モード判断構造オーバーライドプロデューサコマンドに応答して（ブロック２１７０）、制御はブロック２１７５へ進む。ブロック２１７５では、プロデューサ実行モード設定は、プロデューサベースの構成可能な判断構造において、クラスベース、メソッドベース、インスタンスベース、又はその組合せでグローバルにオーバーライドされる。
グローバルな実行コマンド
図２２Ａは、本発明の一実施形態により現在プロデューサグラフを実行するためのフローチャートの一部分であり、一方、図２２Ｂは、本発明の一実施形態により現在プロデューサグラフを実行するためのフローチャートの別の部分である。図１０を参照すれば、図２２のフローは、プロデューサグラフ実行モジュール１０７０により遂行される。
グローバルな実行コマンドに応答して、ブロック２２００は、候補プロデューサのセットが、実行スタートログにおけるプロデューサに基づいて実行されるべく選択されることを示し、制御はブロック２２０５へ進む。オーバーライドされたプロデューサが非実行とマークされ、それを実行すると、それらのオーバーライドされた結果が返送される（それらのメソッドを実行させるのではなく）本発明の一実施形態では、候補プロデューサの現在セットは、実行スタートログにおけるプロデューサである。オーバーライドされたプロデューサが非実行とマークされ、それを実行すると、それらのオーバーライドされた結果が返送される（それらのメソッドを実行させるのではなく）本発明の一実施形態を上述したが、別の実施形態は、異なる仕方で動作してもよい（例えば、オーバーライドされたプロデューサを実行とマークし、そして候補プロデューサの現在セットの選択時に、実行スタートログの独立プロデューサ及び実行スタートログにおけるオーバーライドされたプロデューサの親が選択される）。
ブロック２２０５では、実行の準備ができたプロデューサのサブセットが候補プロデューサのセットから選択され、そして制御はブロック２２０７へ進む。ブロック２２０５を遂行する例示的な仕方をここに説明する。
ブロック２２０７では、レディプロデューサの現在セットにおけるプロデューサは、パラレル化がイネーブルされた場合には、パラレル化と共に実行される。ブロック２２０７を遂行する例示的な仕方をここに説明する。制御は、ブロック２２０７からブロック２２０８へ進む。
ブロック２２０８では、サポートされる実行モードの結果タスク待ち行列の１つからタスクが読み取られ、取り出される。ここに示す例では、結果タスク待ち行列は、ＭＰ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥ、ＭＴ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥ、及びＬＯＣＡＬ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥを含む。ブロック２２０８から、制御はブロック２２０９へ進む。
ブロック２２０９では、ランタイムは、プロデューサの後処理がスキップされたかどうか決定する。ベンチマーキングがイネーブルされた場合には、プロデューサは、ローカルで実行され且つマルチ処理される。従って、プロデューサの後処理は、ローカル実行の後にスキップされる。ベンチマーキングの詳細は以下に述べる。図２２Ａへ戻ると、後処理をスキップしなければならない場合には、制御は、図２２Ｂのブロック２２４８へ進む。さもなければ、制御はブロック２２１０へ進む。
ブロック２２１０では、レディプロデューサの現在セットの中のプロデューサは、形式により分類され、標準プロデューサは、ブロック２２２０へ進み、そして依存性決定プロデューサは、ブロック２２３５へ進む。本発明の一実施形態では、ブロック２２１０は、プロデューサのリターンクラスをチェックすることにより遂行される。図１０及び図１１Ｄを参照すれば、メソッド追跡構造がアクセスされ、プロデューサの出力クラスがＤＥＰであるかどうか決定し、従って、このプロデューサは、依存性決定プロデューサである。
ブロック２２２０では、これらの実行された標準プロデューサのいずれかにアブソービングサブスクリプションを有する親がもしあれば、サブスクリプションは、未完了とマークされる。図１４Ａを参照すれば、完了列１４２０の適切な行は、未完了を指示するようにセットされる。
ブロック２２３５では、発見されたプロデューサに対して新プロデューサコマンドが実行され、サブスクリプションに対してサブスクリプションログ及び処理が遂行され、次いで、制御はブロック２２４０へ進む。ブロック２２３５の新プロデューサコマンド部分は、ブロック１７５０と同様に遂行され、一方、サブスクリプションログ及び処理は、ブロック１７４０及び１７４５と同様に遂行される。
ブロック２２４０では、実行スタートログに新たに追加された候補プロデューサのセットに追加がなされる。ブロック２２４０から、制御はブロック２２４５へ進む。ブロック２２４０は、ブロック２２３５の結果として実行スタートログに新たに追加されたプロデューサのみが候補プロデューサのセットに追加されることを除いて、ブロック２２００と同様に遂行される。
ブロック２２４５では、実行されたプロデューサが、実行されたとマークされ、プロデューサ出力キャッシング（及びインスタンスキャッシング）が、必要に応じて更新され、プロデューサメトリック（もし取得されれば）が、図１０のプロデューサグラフ構造１０６０において更新され、実行されたプロデューサの親プロデューサが候補プロデューサの現在セットに追加され、そして実行されたプロデューサが候補及びレディプロデューサの現在セットから除去される。幾つかの実施形態では、プロデューサメトリックは、それに対応するタスクメトリック及びそれに対応するジョブリファレンスを読み取ることにより更新することができる。ジョブリファレンスを使用すると、ジョブメトリックは、ジョブメトリックマップから読み取ることができる。或いは又、プロデューサメトリックは、ジョブメトリックマップが使用されない場合にはタスクメトリック及びジョブメトリックを読み取ることにより更新することができる。タスクメトリック、ジョブメトリック、及びジョブメトリックマップの更なる詳細は、以下に述べる。ブロック２２４５から、制御はブロック２２４８へ進む。
ブロック２２４８では、結果タスク待ち行列がチェックされ、それらが全て空であるかどうか決定される。結果タスク待ち行列の少なくとも１つが空でない場合には、制御がブロック２２０８へ戻り、非空結果タスク待ち行列（１つ又は複数）における結果の処理が続けられる。さもなければ、結果タスク待ち行列の全てが空である場合には、制御はブロック２２５０へ進む。
ブロック２２５０では、レディプロデューサのセットが空であるかどうか決定される。もし空でなければ、制御がブロック２２０５へ戻り、さもなければ、制御はブロック２２５５へ進む。
ブロック２２５５では、全てのサブスクリプションが完了されたかどうか決定される。もしそうであれば、制御はブロック２２６５へ進み、そこで、フローが終了となるが、さもなければ、制御はブロック２２６０へ進む。図１４Ａにおける本発明の実施形態を参照すれば、未完了のアブソービングサブスクリプションに対してサブスクリプション形式列１４０５及び完了列１４２０がスキャンされる。
ブロック２２６０では、未完了のアブソービングサブスクリプションが処理され、制御がブロック２２０５へ戻る。ブロック２２６０を遂行する例示的な仕方について、以下に説明する。
図２３は、本発明の一実施形態による図２２のブロック２２０５のためのフローチャートである。従って、制御は、ブロック２２００から、ブロック２２０５のブロック２３０５へ進む。ブロック２３０５では、候補プロデューサのセットにおける各プロデューサに対して、次のブロック２３１０−２３２５が遂行される。
ブロック２３１０では、プロデューサが、未完了のアブソービングサブスクリプション依存性を有するかどうか決定される。もしそうであれば、制御はブロック２３２５へ進み、さもなければ、制御はブロック２３１５へ進む。図１４Ａの実施形態を参照すれば、現在選択されたプロデューサ及びアブソービングサブスクリプション形式への一致に対してサブスクライバープロデューサキー列１４００及びサブスクリプション形式列１４０５がスキャンされ、一致が見つかった場合には、適切な行における完了列１４２０がチェックされて、そのアブソービングサブスクリプション依存性の状態を決定する。
ブロック２３１５では、現在選択されたプロデューサが依存するところのプロデューサが実行されるかどうか決定される。実行されない場合には、制御がブロック２３１５へ進み、さもなければ、制御がブロック２３２０へ進む。図１１Ｃに示す本発明の実施形態に関して、子依存性の行に対する増分的実行マーキング列１１８０がチェックされて、現在選択されたプロデューサの子の実行状態が決定される。
ブロック２３２０では、現在選択された候補プロデューサがレディプロデューサの現在セットに追加され、制御はブロック２３２５へ進む。
ブロック２３２５では、ブロック２３０５で選択された現在プロデューサに対してフローが終了となる。
図２４は、本発明の一実施形態による図２２のブロック２２６０のフローチャートである。従って、制御は、ブロック２２５５からブロック２２６０におけるブロック２５０５へ進む。ブロック２５０５では、未完了のアブソービングサブスクリプション依存性を伴う各プロデューサに対して、次のブロック２５１０−２５２５が遂行される。
ブロック２５１０では、全てのマッチングプロデューサが実行されたかどうか決定される。もしそうであれば、制御はブロック２５１５へ進み、さもなければ、制御はブロック２５２５へ進む。図１１Ｃ及び１４Ａの実施形態を参照すれば、適切な行におけるマッチングプロデューサ列１４１５がアクセスされて、マッチングプロデューサが決定され、そして適切な行における増分的実行列１１８０が各マッチングプロデューサについてチェックされる。
ブロック２５１５では、アブソービングサブスクリプションが完了とマークされ、制御はブロック２５２０へ進む。図１４Ａの実施形態を参照すれば、適切な行における完了列１４２０が、完了を指示するようにセットされる。
ブロック２５２０では、ブロック２５０５で選択されたプロデューサが候補プロデューサの現在セットに追加され、そして制御はブロック２５２５へ進む。
ブロック２５２５では、ブロック２５０５で選択されたプロデューサについてフローが終了となる。
図２５及び２６は、本発明の一実施形態による図２２のブロック２２０７のためのフローチャートである。従って、制御は、図２５において、ブロック２２０５からブロック２６１０へ進む。ブロック２６１０では、マルチプロセッシング、マルチスレッディング及びローカル実行のための種々のタスク待ち行列、並びにマルチプロセッシングのためのジョブのインスタンス生成が遂行される。ブロック２６１０を遂行するための例示的な仕方は、以下で説明する。ブロック２６１０から、制御はブロック２６２０へ進む。
ブロック２６２０では、レディプロデューサのセットがスキャンされて、セット内のプロデューサが１つ１つ処理される。ブロック２６２０から、制御はブロック２６２２へ進む。
ブロック２６２２では、プロデューサの実行モードが、図１１Ｃのグラフ構造のようなプロデューサグラフ構造から読み取られる。次いで、制御は、ブロック２６２５へ進む。
ブロック２６２５では、プロデューサ及びプロデューサの出力をリファレンスするタスクが生成される。ブロック２６２５から、制御はブロック２６３０へ進む。
ブロック２６３０では、どの実行モードでプロデューサを実行すべきか決定される。幾つかの実施形態では、３つの実行モード、即ちマルチプロセッシング、マルチスレッディング及びローカル実行がサポートされる。実行モードがローカル実行であると決定された場合には、制御はブロック２６３２へ進む。実行モードがマルチスレッディングであると決定された場合には、制御はブロック２６３４へ進む。実行モードがマルチプロセッシングであると決定された場合には、制御はブロック２６３５へ進む。
ブロック２６３２では、プロデューサのタスクが、ローカル実行のための実行タスク待ち行列、即ちＬＯＣＡＬ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥへプッシュされる。次いで、制御はブロック２６４０へ進む。
ブロック２６３４では、プロデューサのタスクが、マルチスレッディングのための実行タスク待ち行列、即ちＭＴ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥへプッシュされる。次いで、制御はブロック２６４０へ進む。
ブロック２６３５では、プロデューサのタスクが、マルチプロセッシングのための実行タスク待ち行列、即ちＭＰ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥへプッシュされる。次いで、制御はブロック２６３６へ進む。ブロック２６３６では、遠隔実行とローカル実行との間のベンチマーキングが要求されたかどうか決定される。要求されない場合には、制御はブロック２６４０へ進む。しかしながら、ベンチマーキングが要求された場合には、制御はブロック２６３７へ進む。
ブロック２６３７では、ＭＰ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥにプッシュされたタスクは、後実行処置をスキップするとマークされる。次いで、ブロック２６３８において、プロデューサ及びプロデューサの出力をリファレンスする新たなタスクが生成されて、ローカル実行のための実行タスク待ち行列、即ちＬＯＣＡＬ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥにプッシュされる。次いで、制御は、ブロック２６３９へ進み、ＭＰ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥに追加されたタスクに、後でマッチングをとるために、ＬＯＣＡＬ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥに追加されたタスクに対するリファレンスを記憶する。ブロック２６３９の後に、制御はブロック２６４０へ進む。
ブロック２６４０では、レディプロデューサのセットにおける全てのプロデューサがスキャンされたかどうか決定される。スキャンされていない場合には、制御がブロック２６２０へ進み、レディプロデューサのセットにおけるプロデューサのスキャンが続けられる。さもなければ、制御は、図２６Ｂのブロック２６４２へ進む。
ブロック２６４２では、ランタイムは、ＭＴ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥが空であるかどうか決定する。もしそうであれば、制御は２６６０へ進む。さもなければ、制御はブロック２６４４へ進む。
ブロック２６４４では、ランタイムは、スレッドプールメカニズムがまだ開始されていなければ、それを開始する。ブロック２６４４から、制御はブロック２６５０へ進む。
ブロック２６５０では、ＭＴ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥ内のタスクに対してマルチスレッディングを遂行するために個別のスレッドがインスタンス生成される。ブロック２６５０を遂行する例示的な仕方は、以下に説明する。ブロック２６５０から、制御はブロック２６６０へ進む。
ブロック２６６０では、ＭＰ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥ及びＬＯＣＡＬ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥ内のタスクを実行するために、マルチプロセッシング及びローカル実行が行われる。ブロック２６６０を遂行する例示的な仕方は、以下に説明する。ブロック２６６０から、制御はブロック２６７０へ進む。
ブロック２７６０では、ＭＴ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥの現在サイズが、ＭＴ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥの初期サイズに等しいかどうか決定される。等しくなければ、制御は、ブロック２６７０に留まる。というのは、マルチスレッディングがＭＴ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥ内の全タスクについてまだ完了されていないからである。さもなければ、制御は、ブロック２６７０からブロック２６９０へ進み、そしてブロック２２０７のプロセスが終了となる。マルチスレッディング、マルチプロセッシング及びローカル実行は、上述した例示的フローでは、順次に遂行されるが、幾つかの別の実施形態では、マルチスレッディング、マルチプロセッシング及びローカル実行を任意の組合せでパラレルに遂行できることが明らかであろう。
図２７Ａ及び２７Ｂは、本発明の一実施形態による図２６のブロック２６１０のためのフローチャートである。従って、制御は、図２７Ａにおいて、ブロック２２０５からブロック２７１０へ進む。ブロック２７１０では、ＭＴ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥがインスタンス生成されるかどうか決定される。そうであれば、ブロック２７１５において、ＭＴ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥがクリアされる。さもなければ、ブロック２７１３において、ＭＴ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥがインスタンス生成される。次いで、制御は、ブロック２７１３又はブロック２７１５からブロック２７２０へ進む。
ブロック２７２０では、ＭＴ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥがインスタンス生成されるかどうか決定される。もしそうであれば、ブロック２７２５においてＭＴ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥがクリアされる。さもなければ、ブロック２７２３において、ＭＴ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥがインスタンス生成される。次いで、制御は、ブロック２７２３又はブロック２７２５からブロック２７３０へ進む。
ブロック２７３０では、ＭＰ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥがインスタンス生成されるかどうか決定される。もしそうであれば、ブロック２７３５において、ＭＰ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥがクリアされる。さもなければ、ブロック２７３３において、ＭＰ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥがインスタンス生成される。次いで、制御は、ブロック２７３３又はブロック２７３５からブロック２７４０へ進む。
ブロック２７４０では、ＭＰ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥがインスタンス生成されるかどうか決定される。もしそうであれば、ブロック２７４５において、ＭＰ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥがクリアされる。さもなければ、ブロック２７４３において、ＭＰ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥがインスタンス生成される。次いで、制御は、ブロック２７４３又はブロック２７４５から、図２７Ｂのブロック２７５０へ進む。
ブロック２７５０では、ＬＯＣＡＬ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥがインスタンス生成されるかどうか決定される。もしそうであれば、ブロック２７５５において、ＬＯＣＡＬ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥがクリアされる。さもなければ、ブロック２７５３において、ＬＯＣＡＬ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥがインスタンス生成される。次いで、制御は、ブロック２７５３又はブロック２７５５からブロック２７６０へ進む。
ブロック２７６０では、ＬＯＣＡＬ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥがインスタンス生成されたかどうか決定される。もしそうであれば、ブロック２７６５において、ＬＯＣＡＬ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥがクリアされる。さもなければ、ブロック２７６３において、ＬＯＣＡＬ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥがインスタンス生成される。次いで、制御は、ブロック２７６３又はブロック２７６５からブロック２６２０へ進む。
図２８Ａは、本発明の一実施形態によるマルチスレッディングを遂行するプロセスのためのフローチャートである。上述したように、マルチスレッディングを遂行するために、図２６のブロック２６５０において個別のスレッドがインスタンス生成される。
ブロック２８２０では、ＭＴ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥが空であるかどうか決定される。ＭＴ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥが空であり、即ちＭＴ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥ内の全タスクがそれに対応する実行スレッドに送られた場合には、プロセスが終了となる。さもなければ、即ち、実行スレッドへ送られるべき少なくとも１つのタスクがある場合には、制御がブロック２８２５へ進んで、プールに利用可能なスレッドがあるかどうか決定される。プールに使用可能なスレッドがない場合には、利用可能なスレッドがあるまで、制御はブロック２８２５に留まる。利用可能なスレッドがあるときには、制御はブロック２８３０へ進む。
ブロック２８０３では、ＭＴ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥからタスクが取り出され、その取り出されたタスクが利用可能なスレッドへ送られる。次いで、制御は、ブロック２８２０へ戻されて、全てのタスクがＭＴ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥから取り出されるまで、ブロック２８２０、２８２５及び２８３０を繰り返す。ブロック２８２０、２８２５及び２８３０のプロセスは、フローの残り部分が詰まるのを回避するために、インスタンス生成されたスレッドによって遂行されてもよいことに注意されたい。
図２８Ｂは、スレッド内のタスクの実行を任意のメトリック取得と共に示すフローチャートである。インスツルメンテーションが要求される場合には、ランタイムは、ブロック２８１０において、タスク実行時間の測定をスタートする。さもなければ、ブロック２８１０がスキップされる。ブロック２８１０から、制御はブロック２８３１へ進む。ブロック２８３１では、スレッド内のタスクは、適切なインスタンス及び入力でタスクのメソッドをコールすることにより実行される。タスクの実行が終了すると、出力及び／又は変更されたインスタンスがメソッドから返送され、そしてスレッドが終了となる。ブロック２８３１から、制御はブロック２８１５へ進む。インスツルメンテーションが要求される場合には、ランタイムは、ブロック２８１５において、タスク実行時間の測定を終了する。さもなければ、ブロック２８１５がスキップされる。
図２８Ｃは、本発明の一実施形態によるスレッド終了コールバックに応答するプロセスのためのフローチャートである。ブロック２８３２において、スレッド終了コールバックが受け取られる。
ブロック２８３４では、終了したスレッド内のタスク及び取得したメトリック（タスク実行時間のような）の出力がもしあれば、それが、終了したスレッドにより実行されたタスクに記憶され、そしてタスクは、出力及び取得したメトリックがもしあれば、それと共に、ＭＴ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥへプッシュされる。制御はブロック２８３６へ進む。ブロック２８３６では、終了したスレッドが、スレッドのプールで利用可能とマークされる。
図２９Ａ及び２９Ｂは、本発明の一実施形態による図２６のブロック２６６０のためのフローチャートである。従って、制御は、ブロック２６５０から、図２９Ａのブロック２９１０へ進む。インスツルメンテーションのために遂行されるが、プロデューサ実行のパラレル化を具現化するのに使用されないブロックは、図２９Ａ及び２９Ｂにおいて、破断破線境界をもつブロックで示されることに注意されたい。
ブロック２９１０では、ＭＰ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥが空であるかどうかチェックされる。ＭＰ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥが空である場合には、マルチプロセッシングされるべきタスクはなく、従って、制御はブロック２６７０へ進む。さもなければ、制御はブロック２９１５へ進む。
ブロック２９１５では、ジョブがインスタンス生成され、そしてジョブ識別子（ＩＤ）がジョブに割り当てられる。更に、ブロック２９１５において、ＴＡＳＫＳ＿ＬＯＣＡＬ＿ＭＡＰもインスタンス生成される。次いで、制御はブロック２９１８へ進む。インスツルメンテーションが要求される場合には、ブロック２９１８は、ジョブの全時間の測定をスターするように遂行される。さもなければ、ブロック２９１８がスキップされる。次いで、制御は、ブロック２９２０へ進む。
ブロック２９２０では、タスクが、ＭＰ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥから読み取られ、取り出される。次いで、制御は、ブロック２９２１へ進む。インスツルメンテーションが要求される場合には、ブロック２９２１は、タスクの全時間の測定をスタートするように遂行される。さもなければ、ブロック２９２１がスキップされる。次いで、制御は、ブロック２９２３へ進む。
ブロック２９２３では、独特のタスク識別子（ＩＤ）がタスクに割り当てられ、そしてタスクリファレンスと共にＴＡＳＫＳ＿ＬＯＣＡＬ＿ＭＡＰに記憶される。次いで、制御はブロック２９２５へ進み、タスクシリアル化フォームをインスタンス生成すると共に、タスクシリアル化フォームを、タスクＩＤ、クラス名、及びタスクに対応するプロデューサのメソッド名で埋める。次いで、制御はブロック２９３０へ進む。
ブロック２９３０では、全入力プロデューサの各々及びその基礎となるインスタンスのシリアル化フォームが既に生成されていれば、それが見出される。或いは又、シリアル化フォームがまだ生成されていない場合には、ブロック２９３０において、それが生成される。ブロック２９３０を遂行する例示的な仕方をここに説明する。ブロック２９３０から、制御はブロック２９６０へ進む。
ブロック２９６０では、ジョブのシリアル化タスク実行待ち行列、即ちＪＯＢ．ＳＥＲＩＡＬＩＺＥＤ＿ＴＡＳＫＳ＿ＥＸＥＣＵＴＩＯＮ＿ＱＵＥＵＥにタスクシリアル化フォームが追加される。次いで、制御はブロック２９６５へ進む。
ブロック２９６５では、ＭＰ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥが空であるかどうか決定される。ＭＰ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥが空でない場合には、制御はブロック２９２０に戻り、ＭＰ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥ内の残りのタスクを進み続ける。さもなければ、制御はブロック２９７０へ進む。
ブロック２９７０では、ジョブが多数の遠隔プロセッサのグリッドへ送られる。プロセッサのグリッドは、ジョブを実行するための遠隔コンピューティングを遂行する。遠隔コンピューティングの１つの例示的なフローの詳細をここに述べる。次いで、制御はブロック２９７２へ進み、ローカル実行を行う。ブロック２９７２から、制御はブロック２９７３へ進む。
ブロック２９７３では、ジョブが終了したかどうか決定される。終了しない場合には、ジョブが終了するまで制御はブロック２９７３に留まる。ジョブが終了すると、制御は、図２９Ｂのブロック２９７５へ進む。
図２９Ｂを参照すれば、ブロック２９７５において、ジョブバーチャルローカル処理時間がゼロにセットされる。本発明の１つの態様によれば、ジョブバーチャルローカル処理時間は、ジョブの全タスクをローカルで実行するのに要する時間である。ブロック２９７５から、制御はブロック２９７７へ進む。
ブロック２９７７では、ジョブのシリアル化結果待ち行列、即ちＪＯＢ．ＳＥＲＩＡＬＩＺＥＤ＿ＴＡＳＫＳ＿ＲＥＳＵＬＴ＿ＱＵＥＵＥからタスクが読み取られ、取り出される。次いで、制御はブロック２９７９へ進み、ＴＡＳＫＳ＿ＬＯＣＡＬ＿ＭＡＰに記憶されたタスクＩＤを使用してタスクリファレンスを見出す。次いで、制御はブロック２９８０へ進む。
インスツルメンテーションが要求された場合には、ブロック２９８０は、出力シリアル化フォームのサイズを決定し、そして出力のローカルデシリアル化時間の測定をスタートするように遂行される。さもなければ、ブロック２９８０は、スキップされ、制御はブロック２９８１へ進む。ブロック２９８１では、タスク出力における出力がデシアル化される。ブロック２９８１から、制御はブロック２９８２へ進む。この場合も、インスツルメンテーションが要求される場合には、ブロック２９８２は、ローカルデシリアル化時間の測定を終了するように遂行される。更に、インスツルメンテーションが要求される場合には、ブロック２９８４、２９８５、２９８７及び２９８９を遂行することができる。さもなければ、ブロック２９８４、２９８５、２９８７及び２９８９がスキップされ、制御はブロック２９８１からブロック２９９０へ進む。
ブロック２９８４では、ランタイムは、タスク全時間の測定を終了し、そしてタスク全時間からローカル実行時間を除去する。ブロック２９８４から、制御はブロック２９８５へ進む。
ブロック２９８５では、ベンチマーキングが要求されたかどうか決定される。ベンチマーキングが要求された場合には、制御はブロック２９８７へ進み、次いで、ブロック２９８９へ進む。さもなければ、制御は、２９８５から２９８９へ進み、ブロック２９８７をスキップする。
図２５及び２６を参照して上述したように、ベンチマーキングは、ローカル実行時間と遠隔実行時間とを比較することが要求される。従って、本発明の一実施形態によれば、ベンチマーキングが要求された場合に、マルチプロセッシングを使用してタスクがローカル及び遠隔の両方で実行される。従って、ベンチマーキングが要求された場合には、ランタイムは、ブロック２９８７において、ＬＯＣＡＬ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥ内の対応タスクを見出すことができる。更に、ランタイムは、タスクに記憶されたローカル処理時間を、ジョブバーチャルローカル処理時間に加算することができる。従って、ジョブバーチャルローカル処理時間は、全てのタスクが実行されたときにジョブの全タスクのローカル処理時間の和に等しい。ブロック２９８７から、制御は、ブロック２９８９へ進む。
ブロック２９８９では、タスクの全時間のようなタスクメトリックが、ジョブＩＤと共に、タスクに追加される。次いで、制御はブロック２９９０へ進む。インスツルメンテーションが要求される場合には、両ブロック２９８７及び２９８９が遂行されることに注意されたい。さもなければ、両ブロック２９８７及び２９８９がスキップされてもよい。
ブロック２９９０では、タスクがＭＰ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥにプッシュされる。次いで、制御はブロック２９９１へ進む。ブロック２９９１では、ＪＯＢ．ＳＥＲＩＡＬＩＺＥＤ＿ＴＡＳＫＳ＿ＥＸＥＣＵＴＩＯＮ＿ＱＵＥＵＥが空であるかどうか決定される。空でなければ、制御はブロック２９７７へ戻り、待ち行列からのタスクの読み取り及び出力のデシリアル化を継続する。さもなければ、インスツルメンテーションが要求された場合に、制御はブロック２９９２へ進む。インスツルメンテーションが要求されない場合には、制御は、ブロック２９９１から、図２６Ｂのブロック２６７０へ進む。
インスツルメンテーションが要求される場合には、ブロック２９９２、２９９３、２９９５、２９９６及び２９９７を遂行することができる。さもなければ、ブロック２９９２、２９９３、２９９５、２９９６及び２９９７をスキップしてもよい。ブロック２９９２では、ジョブ全時間の測定が終了となり、次いで、ローカル実行時間がジョブ全時間から除去される。ブロック２９９２から、制御はブロック２９９３へ進む。
ブロック２９９３では、ベンチマーキングが要求されるかどうか決定される。ベンチマーキングが要求される場合には、制御はブロック２９９５へ進む。ブロック２９９５では、ジョブバーチャルローカル処理時間をジョブ全時間で除算することによりジョブスピードアップが計算される。次いで、制御はブロック２９９５からブロック２９９６へ進む。ブロック２９９６において、ジョブスピードアップを、グリッドにおけるジョブの実行に専用に利用可能なプロセッサの数で分割することにより、ジョブ効率が計算される。ブロック２９９６から、制御はブロック２９９７へ進む。さもなければ、ベンチマーキングが要求されない場合には、制御はブロック２９９３からブロック２９９７へ直接進む。
ブロック２９９７では、ジョブのメトリック（例えば、ジョブスピードアップ、ジョブ効率、ジョブ全時間、等）が、ジョブ内の各タスクに追加される。ブロック２９９７から、制御は、図２６Ｂのブロック２６７０へ進む。
図３０は、本発明の一実施形態による図２９Ａのブロック２９３０のためのフローチャートである。従って、制御は、ブロック２９２５から、図３０のブロック３０１０へ進む。ブロック３０１０では、入力プロデューサ又はその基礎となるインスタンスのシリアル化フォームが、入力プロデューサキー又はその基礎となるインスタンスキーに基づき、ＳＥＲＩＡＬＩＺＥＤ＿ＦＯＲＭ＿ＬＯＣＡＬ＿ＭＡＰにおいて既に生成されたかどうか決定される。シリアル化フォームが既に生成された場合には、制御はブロック３０１５へ進む。さもなければ、制御は、ブロック３０２０へ進む。
ブロック３０１５では、シリアル化フォームＩＤ及びシリアル化フォームがＳＥＲＩＡＬＩＺＥＤ＿ＦＯＲＭ＿ＬＯＣＡＬ＿ＭＡＰから読み取られる。次いで、制御はブロック３０４０へ進む。
ブロック３０２０では、シリアル化フォーム識別子が、入力プロデューサ又はその基礎となるインスタンスに割り当てられる。次いで、制御はブロック３０２２へ進む。
ブロック３０２２では、ローカルシリアル化時間の測定がスタートされる。次いで、制御はブロック３０２４へ進む。
ブロック３０２４では、入力プロデューサ又はその基礎となるインスタンスに対してシリアル化フォームが生成される。次いで、制御はブロック３０２６へ進む。
ブロック３０２６では、ローカルシリアル化時間の測定が終了される。次いで、制御はブロック３０２８へ進む。
ブロック３０２８では、入力シリアル化フォームサイズが決定される。次いで、制御はブロック３０３０へ進む。
ブロック３０３０では、入力プロデューサキー又はその基礎となるインスタンスキー、シリアル化フォームＩＤ、及びシリアル化フォームが、ＳＥＲＩＡＬＩＺＥＤ＿ＦＯＲＭ＿ＬＯＣＡＬ＿ＭＡＰに記憶される。このＳＥＲＩＡＬＩＺＥＤ＿ＦＯＲＭ＿ＬＯＣＡＬ＿ＭＡＰは、メモリ要件、性能要件、等の種々のファクタに基づいて、グローバルなものでもよいし、或いはジョブごとに割り当てられ解放されるものでもよい。次いで、制御はブロック３０３４へ進む。
ブロック３０３４では、入力シリアル化フォームサイズ及びシリアル化時間が、シリアル化フォームＩＤと共に、ＳＥＲＩＡＬＩＺＥＤ＿ＦＯＲＭ＿ＬＯＣＡＬ＿ＭＡＰに記憶される。次いで、制御はブロック３０４０へ進む。上述したブロック３０２２、３０２６、３０２８及び３０３４は、インスツルメンテーションが要求された場合に遂行される。ブロック３０２２、３０２６、３０２８及び３０３４は、インスツルメンテーションが要求されない場合には、スキップされてもよい。
ブロック３０４０では、シリアル化フォームＩＤがＪＯＢ．ＳＥＲＩＡＬＩＺＥＤ＿ＦＯＲＭ＿ＭＡＰにあるかどうか決定される。もしそうであれば、次いで、制御はブロック３０４５へ進む。さもなければ、制御はブロック３０４３へ進む。
ブロック３０４３では、シリアル化フォームＩＤ及びシリアル化フォームがＪＯＢ．ＳＥＲＩＡＬＩＺＥＤ＿ＦＯＲＭ＿ＭＡＰに記憶される。次いで、制御はブロック３０４５へ進む。
ブロック３０４５では、シリアル化フォームＩＤが、入力として又はその基礎となるインスタンスとして、タスクシリアル化フォームに追加される。ブロック３０４５から、制御はブロック３０５０へ進む。
ブロック３０５０では、まだ処理されていない入力プロデューサが更にあるか又はその基礎となるインスタンスでまだ処理されていなものがあるかどうか決定される。もしそうであれば、次いで、制御はブロック３０１０へ進む。さもなければ、制御は、図２９Ａのブロック２９６０へ進む。
図３１Ａ及び３１Ｂは、本発明の一実施形態によるマルチプロセッシングのための遠隔コンピューティングのフローチャートである。この場合も、破断破線で示されたブロックは、インスツルメンテーションが要求される場合に遂行され、そしてインスツルメンテーションが要求されない場合にはスキップされてもよい。上述したように、プロデューサに対応する多数のタスクを含むジョブは、実行のためにプロセッサのグリッドへディスパッチされる。ワーカーとも称されるグリッド内の各プロセッサは、ＪＯＢ＿ＳＥＲＩＡＬＩＺＥＤ ＦＯＲＭＳ＿ＭＡＰをキャッシュ記憶することができる。例えば、１つのジョブが数千のタスクを保持し、そして１０個のワーカーがそれらタスクを実行する場合には、ＪＯＢ＿ＳＥＲＩＡＬＩＺＥＤ ＦＯＲＭＳ＿ＭＡＰがグリッドディスパッチャーにより各ワーカーへ一度送信され、そしてワーカーレベルにおいてキャッシュ記憶される。ジョブが終了したときには、グリッドディスパッチャーが、キャッシュを解放するためのコマンドをワーカーへ送信する。フローは、ブロック３１０８においてスタートする。
ブロック３１０８では、ＪＯＢ＿ＳＥＲＩＡＬＩＺＥＤ ＦＯＲＭＳ＿ＭＡＰが、入力ＩＤ、クラス名及びメソッド名を保持するタスクシリアル化フォームと共に、グリッドディスパッチャーから受け取られる。次いで、制御はブロック３１１０へ進む。ブロック３１１０では、クラス名を使用してクラスが探索され、そしてメソッド名を使用してメソッドが探索される。クラス及びメソッドは、タスクを再構成するようにロードされる。次いで、制御はブロック３１１２へ進む。
ブロック３１１２では、タスク入力ＩＤ又はインスタンスＩＤがＪＯＢ．ＳＥＲＩＡＬＩＺＥＤ＿ＦＯＲＭ＿ＭＡＰからルックアップされる。次いで、制御はブロック３１２０へ進む。
ブロック３１２０では、入力ＩＤが見つかったかどうか決定される。見つからない場合には、制御がブロック３１９０へ進み、エラーを返送する。さもなければ、制御はブロック３１３０へ進む。
ブロック３１３０では、入力ＩＤに対応するＪＯＢ．ＳＥＲＩＡＬＩＺＥＤ＿ＦＯＲＭＳ＿ＭＡＰエントリーが既にデシリアル化されたかどうか決定される。既にデシリアル化された場合には、次いで、制御はブロック３１５０へ進む。さもなければ、制御はブロック３１３２へ進む。
ブロック３１５０では、入力のデシリアル化フォームが抽出される。次いで、制御はブロック３１５５へ進む。
ブロック３１３２では、遠隔デシリアル化時間の測定がスタートされる。次いで、制御はブロック３１３４へ進み、入力ＩＤに対応するＪＯＢ．ＳＥＲＩＡＬＩＺＥＤ＿ＦＯＲＭＳ＿ＭＡＰをデシリアル化する。ブロック３１３４から、制御はブロック３１３６へ進む。ブロック３１３６では、遠隔デシリアル化時間の測定が終了される。次いで、制御はブロック３１３８へ進む。
ブロック３１３８では、ＪＯＢ．ＳＥＲＩＡＬＩＺＥＤ＿ＦＯＲＭＳ＿ＭＡＰにおける対応エントリーが、デシリアル化フォームでエンリッチされる。次いで、制御はブロック３１４３へ進む。
ブロック３１４３では、インスタンス又は標準的入力がタスク定義に追加される。次いで、制御はブロック３１５５へ進む。
ブロック３１５５では、全ての入力ＩＤ（即ち、基礎となるインスタンスを伴う全ての標準的入力）が処理されたかどうか決定される。換言すれば、タスクが完全に再構成又はデシリアル化されたかどうか決定される。もしそうであれば、制御は、図３１Ｂのブロック３１６０へ進む。さもなければ、制御は、ブロック３１１２へ戻り、次の入力ＩＤを処理する。
図３１Ｂを参照すれば、遠隔処理時間の測定がブロック３１６０においてスタートされる。次いで、制御はブロック３１６２へ進む。
ブロック３１６２では、適切なインスタンス及び入力を伴うメソッドがコールされる。実行の結果として、メソッドは、出力を返送し及び／又はメソッドのインスタンスを変更する。ランタイムは、メソッドから返送された出力及び／又は変更されたインスタンスを受け取る。制御は、ブロック３１６２からブロック３１６６へ進む。
ブロック３１６６では、遠隔処理時間の測定が終了される。次いで、制御はブロック３１７０へ進む。
ブロック３１７０では、遠隔シリアル化時間の測定がスタートされる。次いで、制御はブロック３１７２へ進み、返送された出力及び／又は変更されたインスタンスをシリアル化すると共に、シリアル化された出力及び／又はシリアル化され変更されたインスタンスをタスクへアタッチする。次いで、制御はブロック３１７４へ進む。ブロック３１７４では、遠隔シリアル化時間の測定が終了される。ブロック３１７４から、制御はブロック３１７６へ進む。
ブロック３１７６では、メトリック（例えば、遠隔シリアル化時間、遠隔デシリアル化時間、等）がタスクに記憶される。次いで制御はブロック３１８０へ進む。
ブロック３１８０では、タスクがランタイムのグリッドディスパッチャーへ返送され、フローが終了となる。ここでも、破断破線で示されたブロックは、インスツルメンテーションが要求された場合に遂行され、そしてインスツルメンテーションが要求されない場合にはスキップされる。
図３２は、本発明の一実施形態による図２９Ａのブロック２９７２のためのフローチャートである。従って、制御は、ブロック２９７０から図３２のブロック３２０２へ進む。ここでも、破断破線で示されたブロックは、インスツルメンテーションが要求された場合に遂行され、そしてインスツルメンテーションが要求されない場合にはスキップされる。
ブロック３２０２では、ローカル実行時間の測定がスタートされる。次いで、制御はブロック３２１０へ進む。
ブロック３２１０では、タスクが、ＬＯＣＡＬ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥから取り出され、そして適切なインスタンス及び入力でメソッドをコールすることによりローカルで実行される。実行が終了すると、メソッドは、メソッドの出力及び／又は変更されたインスタンスを返送する。次いで、制御はブロック３２１２へ進む。
ブロック３２１２では、ローカル実行時間の測定が終了される。次いで、制御はブロック３２２０へ進む。
ブロック３２２０では、タスクの出力がタスクに記憶される。次いで、制御はブロック３２２３へ進む。
ブロック３２２３では、メトリック（例えば、ローカル実行時間）がタスクにも記憶される。次いで、制御はブロック３２３０へ進む。
ブロック３２３０では、タスクが、ＬＯＣＡＬ＿ＲＥＳＵＬＴ＿ＴＡＳＫ＿ＱＵＥＵＥへプッシュされる。ブロック３２３０から、制御はブロック３２４０へ進む。
ブロック３２４０では、ＬＯＣＡＬ＿ＥＸＥＣＵＴＩＯＮ＿ＴＡＳＫ＿ＱＵＥＵＥが空であるかどうか決定される。待ち行列が空である場合には、制御は、図２９Ａのブロック２９７３へ進む。さもなければ、制御はブロック３２０２へ戻り、別のタスクをローカルで実行するようにプロセスを繰り返す。
別の実施形態
添付図面のフローチャートは、本発明の実施形態によって遂行されるオペレーションの特定の順序を示しているが、このような順序は、例示に過ぎない（例えば、別の実施形態では、オペレーションを異なる順序で遂行し、あるオペレーションを結合し、あるオペレーションを重畳し、等々も行える）ことを理解されたい。
本発明を多数の実施形態について説明したが、当業者であれば、本発明は、ここに述べる実施形態に限定されず、特許請求の範囲の精神及び範囲内で変更及び修正を伴って実施できることが明らかであろう。従って、この説明は、限定のためではなく例示のためのものと考えるべきである。
１００：オブジェクト指向のソースコード
１０２：クラス定義
１０４：所与のメソッド
１０５：実行モード設定
１０６：所与のメソッドに対するプロデューサ依存性宣言
１０８：インスタンス（データ）
１１０：プロデューサ
１１２、１１４：プロデューサのセット
２１０Ａ、２１０Ｉ：オブジェクト指向のアプリケーションコード
２２０：プロデューサグラフ指向のプログラミングサポートを伴うランタイム
３２０：プロデューサ依存性宣言
３２５：プロデューサの現在セット
３３０：ソースプロデューサの出力
３３５：プロデューサグラフ指向のプログラミングサポートを伴うランタイム
３４０：自動プロデューサグラフ発生モジュール
３４５：プロデューサグラフ実行モジュール
３４５１：パラレル化モジュール
３４５３：マルチプロセッシングモジュール
３４５５：マルチスレッディングモジュール
３４５７：ローカル実行モジュール
３５０：ソースプロデューサの出力
３５２：ソースコードにおける独立プロデューサの出力
３５４：オーバーライドされたプロデューサ出力
３６０：プロデューサグラフ指向のプログラミングサポートを伴うランタイム
３６５：自動プロデューサグラフ発生モジュール
３７０：プロデューサグラフ実行モジュール
３８０：プロデューサグラフ構造
３８２：増分的実行マーキング
３８４：プロデューサ出力キャッシング
３９０：オーバーライドプロデューサ出力モジュール
３９２：オーバーライドプロパティプロデューサ出力モジュール
３９４：オーバーライドメソッドプロデューサ出力モジュール
３９６：オーバーライドログ

Claims (38)

  1. オブジェクト指向のコードで書かれたアプリケーションプログラムを実行するためのコンピュータ実施方法において、
    対象の現行出力を伴うプロデューサをインスタンス生成するステップであって、前記オブジェクト指向のコードは、メソッド及びプロデューサ依存性宣言を含み、所与のメソッドに対するプロデューサ依存性宣言は、０以上のプロデューサのセットをランタイム時に識別し、プロデューサは、少なくともインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであるようなステップと、
    前記インスタンス生成に応答して、対象のプロデューサをプロデューサグラフの一部分として追加するステップと、
    前記プロデューサグラフに既にあるプロデューサのメソッドのプロデューサ依存性宣言に基づき、他のプロデューサをリンクし及び必要に応じてインスタンス生成することにより、前記プロデューサグラフの残り部分を自動的に発生するように試みるステップと、
    前記プロデューサグラフ内のプロデューサを実行して、対象のプロデューサの現行出力を決定するステップであって、前記実行は、前記プロデューサグラフ内のプロデューサ間の依存性に基づきランタイムを使用して前記プロデューサグラフ内の少なくとも２つのプロデューサの実行をパラレル化することを含むようなステップと、
    を備えた方法。
  2. 前記プロデューサグラフ内の少なくとも２つのプロデューサの実行をパラレル化することは、
    前記プロデューサグラフ内のプロデューサ間でレディプロデューサのセットを識別し、 前記レディプロデューサのセットのうちの各プロデューサの実行モードを決定し、
    前記レディプロデューサのセットのうちの各プロデューサをそれに対応する実行モードで実行させる、
    ことを含む請求項１に記載の方法。
  3. 前記実行モードは、ローカル実行モード、マルチプロセッシングモード、及びマルチスレッディングモードの１つである、請求項２に記載の方法。
  4. 前記レディプロデューサのセットのうちの各プロデューサに対するタスクを生成し、
    前記タスクを、それに対応するプロデューサの実行モードにおいて実行させる、
    ことを更に含む請求項２に記載の方法。
  5. 前記レディプロデューサのセットのうちの各プロデューサのタスクは、それに対応するプロデューサに対するリファレンスと、それに対応するプロデューサの出力に対するリファレンスとを含む、請求項４に記載の方法。
  6. 前記レディプロデューサのセットのうちの各プロデューサの実行モードを決定することは、
    その対応プロデューサのメソッドの実行モード設定をチェックし、
    エンドユーザが、クラスベース、メソッドベース及びインスタンスベースの少なくとも１つで別の実行モードを選択する場合にはその対応プロデューサの実行モード設定をオーバーライドし、
    その対応プロデューサの対応実行モード設定がプロデューサグラフにおいて変更された場合には、その対応プロデューサの実行モード設定をプロデューサごとにオーバーライドし、
    前記ランタイムがその対応実行モードを所定の実行モードでグローバルにオーバーライドするようにセットされた場合には、プロデューサグラフにおける対応実行モード設定を所定の実行モードでオーバーライドする、
    ことを含む請求項２に記載の方法。
  7. インスツルメンテーション要求に応答してプロデューサごとに前記ランタイムを使用して前記プロデューサグラフ内のプロデューサの実行に関連したメトリックを取得するステップを更に備え、これは、前記プロデューサグラフ内のプロデューサの実行時間をプロデューサごとに測定することを含む、請求項１に記載の方法。
  8. メトリックを取得する前記ステップは、前記プロデューサグラフ内のプロデューサの実行時間をジョブベースで測定することを含み、ジョブは、マルチプロセッシングされるべき複数のプロデューサを含む、請求項７に記載の方法。
  9. メトリックを取得する前記ステップは、ベンチマーキング要求に応答して前記ジョブの遠隔実行に対してローカル実行をベンチマーキングする段階を含み、この段階は、
    複数のプロデューサをローカルで実行し、
    複数のプロデューサのローカル実行時間を測定し、
    前記ジョブをプロセッサのグリッドへ送信し、プロセッサのグリッドは、複数のプロデューサを実質的にパラレルに実行し、
    前記ジョブの全実行時間を測定し、
    ローカル実行時間を全遠隔実行時間に対して比較し、
    入力ストリームサイズ及び出力ストリームサイズをプロデューサごとに測定する、
    ことを含む請求項８に記載の方法。
  10. オブジェクト指向のコードで書かれたアプリケーションプログラムを実行するためのコンピュータ実施方法において、
    対象の現行出力を伴うプロデューサをインスタンス生成するステップであって、前記オブジェクト指向のコードは、メソッド及びプロデューサ依存性宣言を含み、所与のメソッドに対するプロデューサ依存性宣言は、０以上のプロデューサのセットをランタイム時に識別し、プロデューサは、少なくともインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであるようなステップと、
    前記インスタンス生成に応答して、対象のとするプロデューサをプロデューサグラフの一部分として追加するステップと、
    前記プロデューサグラフに既にあるプロデューサのメソッドのプロデューサ依存性宣言に基づき、他のプロデューサをリンクし及び必要に応じてインスタンス生成することにより、前記プロデューサグラフの残り部分を自動的に発生するように試みるステップと、
    プロデューサグラフ指向のプログラミングサポートを伴うランタイムを使用して前記プロデューサグラフに基づき前記アプリケーションプログラムのインスツルメンテーションを行うステップと、
    を備えた方法。
  11. アプリケーションプログラムのインスツルメンテーションを行う前記ステップは、前記アプリケーションプログラムの実行時間をプロデューサベースで測定することを含む、請求項１０に記載の方法。
  12. アプリケーションプログラムのインスツルメンテーションを行う前記ステップは、
    ジョブをプロセッサのグリッドへ送信する段階であって、該プロセッサのグリッドは、ジョブの複数のプロデューサを実質的にパラレルに実行するものである段階と、
    前記ジョブの全実行時間を測定する段階と、
    を更に備えた請求項１０に記載の方法。
  13. アプリケーションプログラムのインスツルメンテーションを行う前記ステップは、入力ストリームサイズと出力ストリームサイズをプロデューサごとに測定する段階を更に備えた請求項１０ないし１２のいずれか一つに記載の方法。
  14. アプリケーションプログラムのインスツルメンテーションを行う前記ステップは、
    ベンチマーキング要求に応答して前記ジョブの遠隔実行に対してローカル実行をベンチマーキングする段階を含み、この段階は、
    前記ジョブの複数のプロデューサをローカルで実行し、及び
    前記複数のプロデューサのローカル実行時間を測定する、
    ことを含む請求項１２に記載の方法。
  15. 前記ベンチマーキングする段階は、
    前記ローカル実行時間を前記全遠隔実行時間に対して比較し、
    前記ローカル実行時間及び前記全遠隔実行時間から比較メトリックを導出する、
    ことを含む請求項１４に記載の方法。
  16. メソッドに対するプロデューサ依存性宣言及びメソッドに対する実行モード設定を伴うオブジェクト指向のコードを実行するランタイムを備え、プロデューサは、インスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであり、所与のメソッドに対する各プロデューサ依存性宣言は、０以上のプロデューサのセットをランタイム時に識別し、前記ランタイムは、
    対象のプロデューサの指定を受け取り、対象のプロデューサをプロデューサグラフの一部分として追加し、そして前記プロデューサグラフに既にあるプロデューサのメソッドのプロデューサ依存性宣言に基づき、他のプロデューサをリンクし及び必要に応じてインスタンス生成することにより、前記プロデューサグラフの残り部分を自動的に発生するための自動プロデューサグラフ発生モジュールと、
    前記プロデューサグラフにより示された順序で前記プロデューサグラフ内のプロデューサを実行して、対象のプロデューサの出力を決定するための自動プロデューサグラフ実行モジュールであって、各プロデューサを実行すると、そのプロデューサのメソッドがそのプロデューサのインスタンスに対して実行されるようになる自動プロデューサグラフ実行モジュールと、
    を備え、前記自動プロデューサグラフ実行モジュールは、前記複数のプロデューサのうちの２つ以上をパラレルに実行させるパラレル化モジュールを含むものである、装置。
  17. 前記自動プロデューサグラフ実行モジュールは、
    前記パラレル化モジュールに結合されて、ローカル実行の実行モードを有するプロデューサをローカルで実行させるローカル実行モジュール、
    を更に含む請求項１６に記載の装置。
  18. 前記自動プロデューサグラフ実行モジュールは、インスツルメンテーションが要求された場合にローカル実行の実行モードを有するプロデューサのローカル実行時間を測定するためのメトリック取得モジュールを更に含む、請求項１７に記載の装置。
  19. 前記自動プロデューサグラフ実行モジュールは、
    前記パラレル化モジュールに結合され、スレッドプールメカニズムを開始すると共に、マルチスレッディングの実行モードを有するプロデューサに対応するマルチスレッディングタスクを伴う利用可能なスレッドを供給するためのマルチスレッディングモジュール、を更に含む請求項１６に記載の装置。
  20. 前記自動プロデューサグラフ実行モジュールは、インスツルメンテーションが要求される場合にマルチスレッディングの実行モードを有する各プロデューサの実行時間を測定するためのメトリック取得モジュールを更に含む、請求項１９に記載の装置。
  21. 前記自動プロデューサグラフ実行モジュールは、
    前記パラレル化モジュールに結合されて、ジョブをインスタンス生成し、マルチプロセッシングの実行モードを有するプロデューサに対応するマルチプロセッシングタスクをシリアル化し、そのマルチプロセッシングタスクの入力及びその基礎となるインスタンスをシリアル化し、該シリアル化されたマルチプロセッシングタスク、シリアル化された入力及びシリアル化された基礎となるインスタンスを前記ジョブに追加し、そして前記ジョブをグリッドディスパッチャーに与えるためのマルチプロセッシングモジュール、
    を更に含み、前記グリッドディスパッチャーは、複数のプロセッサを有するグリッドに前記ジョブをディスパッチして、前記ジョブ内のマルチプロセッシングタスクを実行する、請求項１６に記載の装置。
  22. 前記自動プロデューサグラフ実行モジュールは、インスツルメンテーションが要求される場合に、マルチプロセッシングの実行モードを有するプロデューサに対応する各マルチプロセッシングタスクの実行時間、前記ジョブ内のマルチプロセッシングタスク入力、出力及びインスタンスのシリアル化時間及びサイズ、前記ジョブ内のマルチプロセッシングタスク入力、出力及びインスタンスのデシリアル化時間及びサイズ、並びに前記ジョブ内のマルチプロセッシングタスクの実行時間を測定するためのメトリック取得モジュールを更に備えた、請求項２１に記載の装置。
  23. ベンチマーキング要求に応答して、前記メトリック取得モジュールは、マルチプロセッシングタスクのローカル実行時間を測定し、マルチプロセッシングタスクのローカル実行時間をジョブの実行時間に対して比較し、そして比較メトリックを導出する、請求項２２に記載の装置。
  24. 前記ランタイムは、
    前記パラレル化モジュールに結合されて、ランタイムクライアントからのクラスキー、インスタンスキー及びメソッドキーの１つ以上の組合せに基づき実行モードを記憶するためのプロデューサベースの構成可能な判断構造、
    を更に備え、前記自動プロデューサグラフ発生モジュールは、実行モード選択、実行モード設定、及びもしあれば、ランタイムオーバーライド設定に基づいて、実行モードを決定するように動作できる、請求項１６に記載の装置。
  25. 前記ランタイムは、更に、
    前記自動プロデューサグラフ発生モジュール及び自動プロデューサグラフ実行モジュールに結合されて、複数のプロデューサの出力、実行モード設定、及びもしあれば、取得したメトリックを記憶するためのプロデューサグラフ構造、
    を更に含む請求項１６に記載の装置。
  26. 前記ランタイムは、グローバル実行モードオーバーライド設定を記憶するためのランタイム設定構造を更に含む、請求項１６に記載の装置。
  27. メソッドに対するプロデューサ依存性宣言及びメソッドに対する実行モード設定を伴うオブジェクト指向のコードを実行するランタイムを備え、プロデューサは、少なくともインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであり、所与のメソッドに対する各プロデューサ依存性宣言は、０以上のプロデューサのセットをランタイム時に識別し、前記ランタイムは、
    対象のプロデューサの指定を受け取り、対象のプロデューサをプロデューサグラフの一部分として追加し、そして前記プロデューサグラフに既にあるプロデューサのメソッドのプロデューサ依存性宣言に基づき、他のプロデューサをリンクし及び必要に応じてインスタンス生成することにより、前記プロデューサグラフの残り部分を自動的に発生するための自動プロデューサグラフ発生モジュールと、
    前記プロデューサグラフにより示された順序で前記プロデューサグラフ内のプロデューサを実行して、対象のプロデューサの出力を決定するための自動プロデューサグラフ実行モジュールであって、各プロデューサを実行すると、そのプロデューサのメソッドがそのプロデューサのインスタンスに対して実行されるようになる自動プロデューサグラフ実行モジュールと、
    を備え、前記自動プロデューサグラフ実行モジュールは、インスツルメンテーションが要求された場合に前記複数のプロデューサの実行に関連したメトリックをプロデューサごとに取得するためのメトリック取得モジュールを含むものである、装置。
  28. 前記メトリック取得モジュールは、前記プロデューサグラフ内のプロデューサの実行時間を測定するように動作できる、請求項２７に記載の装置。
  29. 複数のクラス定義を含むオブジェクト指向のソースコードを与えるマシン読み取り可能な記憶媒体において、各クラス定義は、
    ０以上のフィールドのセットと、
    １つ以上のメソッドのセットと、
    前記メソッドのセットのうちの各メソッドに対するプロデューサ依存性宣言と、
    を備え、前記メソッドの所与の１つに対する前記プロデューサ依存性宣言は、０以上のプロデューサのセットを識別するためにランタイムによって使用され、プロデューサは、少なくとも、ランタイム時における複数のクラスのうちの１つのクラスのインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであり、更に、前記ランタイムは、他のプロデューサのメソッドのプロデューサ依存性宣言に基づき、他のプロデューサをリンクし及び必要に応じてインスタンス生成することにより、対象の指定のプロデューサのプロデューサグラフを自動的に発生すると共に、前記プロデューサグラフにおいて示されたプロデューサ間の依存性に基づき前記プロデューサグラフ内の少なくとも２つのプロデューサを実質的にパラレルに自動的に実行するよう動作できるものである、マシン読み取り可能な記憶媒体。
  30. 前記ランタイムは、インスツルメンテーション要求に応答してプロデューサグラフ内のプロデューサの実行に関連したメトリックを自動的に取得するように動作できる、請求項２９に記載のマシン読み取り可能な記憶媒体。
  31. 前記ランタイムは、ベンチマーキング要求に応答してマルチプロセッシングによる１つ以上のプロデューサの遠隔実行に対して前記プロデューサグラフ内の１つ以上のプロデューサのローカル実行を自動的にベンチマーキングするように動作できる、請求項３０に記載のマシン読み取り可能な記憶媒体。
  32. 前記オブジェクト指向のソースコードは、前記メソッドのセットのうちの各メソッドに対する実行モード設定を更に含む、請求項２９に記載のマシン読み取り可能な記憶媒体。
  33. 前記ランタイムは、各メソッドを実行すべきところの実行モードを、実行モード設定、もしあればエンドユーザ及びクライアントコードの１つからの構成可能な判断構造における第２の実行モード設定、もしあればエンドユーザ及びクライアントコードの１つからのプロデューサグラフ構造における第３の実行モード設定、及びもしあればランタイムオーバーライド設定に基づいて決定する、請求項３２に記載のマシン読み取り可能な記憶媒体。
  34. 前記実行モードは、ローカル実行モード、マルチプロセッシングモード及びマルチスレッディングモードの１つである、請求項３２に記載のマシン読み取り可能な記憶媒体。
  35. 前記複数のクラス定義の１つ以上は、アノテーションにおいて与えられる１つ以上の実行モード設定を更に含む、請求項３２に記載のマシン読み取り可能な記憶媒体。
  36. 前記オブジェクト指向のソースコードは、ランタイムレベルで実行モードをオーバーライドするためのオーバーライドランタイム実行モード設定コマンドを更に含む、請求項２９に記載のマシン読み取り可能な記憶媒体。
  37. 前記オブジェクト指向のソースコードは、実行モードをプロデューサごとにオーバーライドするためのオーバーライドプロデューサ実行モード設定コマンドを更に含む、請求項２９に記載のマシン読み取り可能な記憶媒体。
  38. 前記オブジェクト指向のソースコードは、実行モードをクラス、メソッド及びインスタンスの少なくとも１つに基づいてオーバーライドするための構成可能な判断ツリー実行モード設定コマンドを更に含む、請求項２９に記載のマシン読み取り可能な記憶媒体。
JP2009538644A 2006-12-01 2007-11-30 プロデューサグラフ指向のプログラミングフレームワークにおけるパラレル化及びインスツルメンテーション Active JP5354601B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/607,196 US8307337B2 (en) 2006-12-01 2006-12-01 Parallelization and instrumentation in a producer graph oriented programming framework
US11/607,196 2006-12-01
PCT/EP2007/010407 WO2008064899A2 (en) 2006-12-01 2007-11-30 Parallelization and instrumentation in a producer graph oriented programming framework

Publications (2)

Publication Number Publication Date
JP2010511233A JP2010511233A (ja) 2010-04-08
JP5354601B2 true JP5354601B2 (ja) 2013-11-27

Family

ID=39400444

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009538644A Active JP5354601B2 (ja) 2006-12-01 2007-11-30 プロデューサグラフ指向のプログラミングフレームワークにおけるパラレル化及びインスツルメンテーション

Country Status (7)

Country Link
US (2) US8307337B2 (ja)
EP (1) EP2041655B1 (ja)
JP (1) JP5354601B2 (ja)
CN (1) CN101589366B (ja)
ES (1) ES2473765T3 (ja)
RU (1) RU2435201C2 (ja)
WO (1) WO2008064899A2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9201766B2 (en) 2006-12-01 2015-12-01 Murex S.A.S. Producer graph oriented programming framework with scenario support
US9424050B2 (en) 2006-12-01 2016-08-23 Murex S.A.S. Parallelization and instrumentation in a producer graph oriented programming framework
US10083013B2 (en) 2006-12-01 2018-09-25 Murex S.A.S. Producer graph oriented programming and execution

Families Citing this family (66)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7865872B2 (en) * 2006-12-01 2011-01-04 Murex S.A.S. Producer graph oriented programming framework with undo, redo, and abort execution support
US8671412B2 (en) * 2008-10-24 2014-03-11 International Business Machines Corporation Calculating and communicating level of carbon offsetting required to compensate for performing a computing task
WO2010064260A1 (en) * 2008-12-01 2010-06-10 Kpit Cummins Infosystems Ltd. Method and system for parallelization of sequencial computer program codes
US8863093B1 (en) * 2009-03-06 2014-10-14 Coverity, Inc. Load-time instrumentation of virtual machine program code
US20110016477A1 (en) * 2009-07-14 2011-01-20 Microsoft Corporation Pre-calculation and caching of dependencies
US8843920B2 (en) * 2009-09-15 2014-09-23 Advanced Micro Devices, Inc. Systems and methods for deferring software implementation decisions until load time
US9984327B2 (en) * 2010-06-17 2018-05-29 Palo Alto Research Center Incorporated System and method for parallel graph searching utilizing parallel edge partitioning
US8607191B2 (en) * 2010-06-30 2013-12-10 International Business Machines Corporation Automated discovery of programmatic resources
CN101964749A (zh) * 2010-09-21 2011-02-02 北京网康科技有限公司 一种基于多核构架的报文转发方法及系统
US20120102469A1 (en) * 2010-10-22 2012-04-26 International Business Machines Corporation Deterministic application breakpoint halting by logically relating breakpoints in a graph
US20120117537A1 (en) * 2010-11-02 2012-05-10 Velocio Networks, Inc. Flow Chart Programming Platform for Testers and Simulators
US9519561B2 (en) * 2011-04-15 2016-12-13 Webtrends Inc. Method and system for configuration-controlled instrumentation of application programs
DE112012002465T5 (de) 2011-06-16 2014-03-20 Caustic Graphics, Inc. Grafikprozessor mit nicht blockierender gleichzeitiger Architektur
US8849916B2 (en) * 2011-06-26 2014-09-30 International Business Machines Corporation Infrastructure management operational workflows
US8825861B2 (en) * 2011-06-26 2014-09-02 International Business Machines Corporation System management operational workflow templates
EP2751664A4 (en) * 2011-09-02 2016-11-02 Vu Lam SYSTEMS AND METHOD FOR PROCESSING SOFTWARE APPLICATION METADATA WITH A SOFTWARE APPLICATION
US9003383B2 (en) * 2011-09-15 2015-04-07 You Know Solutions, LLC Analytic engine to parallelize serial code
US9038033B1 (en) * 2011-12-09 2015-05-19 Sencha, Inc. Techniques and mechanisms for web application minification
KR101373550B1 (ko) * 2012-01-11 2014-03-13 (주)마상소프트 네트워크 기반의 플랫폼 시스템
CN103677789B (zh) * 2012-09-25 2017-11-24 深圳市金正方科技股份有限公司 基于grid组件的列表数据展现方法及系统
WO2014058854A1 (en) * 2012-10-09 2014-04-17 Securboration, Inc. Systems and methods for automatically parallelizing sequential code
US10725897B2 (en) 2012-10-09 2020-07-28 Securboration, Inc. Systems and methods for automatically parallelizing sequential code
US10333820B1 (en) 2012-10-23 2019-06-25 Quest Software Inc. System for inferring dependencies among computing systems
US10313433B2 (en) 2013-03-14 2019-06-04 Thoughtwire Holdings Corp. Method and system for registering software systems and data-sharing sessions
US10372442B2 (en) * 2013-03-14 2019-08-06 Thoughtwire Holdings Corp. Method and system for generating a view incorporating semantically resolved data values
US9742843B2 (en) 2013-03-14 2017-08-22 Thoughtwire Holdings Corp. Method and system for enabling data sharing between software systems
US9164740B2 (en) 2013-05-16 2015-10-20 Toshiba Global Commerce Solutions Holdings Corporation System and method for replacing java beans
EP3025227A1 (en) * 2013-07-23 2016-06-01 Huawei Technologies Co., Ltd. Method for constructing a graph-based intermediate representation in a compiler
US11005738B1 (en) 2014-04-09 2021-05-11 Quest Software Inc. System and method for end-to-end response-time analysis
CN105335230A (zh) * 2014-07-30 2016-02-17 阿里巴巴集团控股有限公司 一种服务处理方法及装置
CN104281478B (zh) * 2014-10-28 2018-07-20 小米科技有限责任公司 更新应用程序的方法及装置
US10291493B1 (en) 2014-12-05 2019-05-14 Quest Software Inc. System and method for determining relevant computer performance events
US9678790B2 (en) * 2015-01-07 2017-06-13 Qualcomm Incorporated Devices and methods implementing operations for selective enforcement of task dependencies
US10325014B2 (en) 2015-04-30 2019-06-18 Workiva Inc. System and method for convergent document collaboration
US9158832B1 (en) * 2015-05-18 2015-10-13 Workiva Inc. Method and computing device for maintaining dependencies among reference elements
US10255263B2 (en) 2015-05-18 2019-04-09 Workiva Inc. Data storage and retrieval system and method for storing cell coordinates in a computer memory
US10187260B1 (en) 2015-05-29 2019-01-22 Quest Software Inc. Systems and methods for multilayer monitoring of network function virtualization architectures
US9626171B2 (en) 2015-07-24 2017-04-18 Oracle International Corporation Composing a module system and a non-module system
CN106663011B (zh) * 2015-07-24 2021-08-24 甲骨文国际公司 桥接模块系统和非模块系统
US10078497B2 (en) 2015-07-24 2018-09-18 Oracle International Corporation Bridging a module system and a non-module system
US10104090B2 (en) * 2015-08-25 2018-10-16 Oracle International Corporation Restrictive access control for modular reflection
US10200252B1 (en) 2015-09-18 2019-02-05 Quest Software Inc. Systems and methods for integrated modeling of monitored virtual desktop infrastructure systems
US9823913B2 (en) * 2015-12-03 2017-11-21 International Business Machines Corporation Method of adding local variables in place of global in JavaScript
CN105512304B (zh) * 2015-12-11 2019-03-26 西安道同信息科技有限公司 在线生成互联网应用方法和系统集成方法及支撑平台
US10394528B2 (en) 2016-03-30 2019-08-27 Oracle International Corporation Returning a runtime type loaded from an archive in a module system
US10191753B2 (en) 2016-03-30 2019-01-29 Oracle International Corporation Generating verification metadata and verifying a runtime type based on verification metadata
US10230601B1 (en) * 2016-07-05 2019-03-12 Quest Software Inc. Systems and methods for integrated modeling and performance measurements of monitored virtual desktop infrastructure systems
US10360008B2 (en) 2016-09-16 2019-07-23 Oracle International Corporation Metadata application constraints within a module system based on modular encapsulation
US10387142B2 (en) 2016-09-16 2019-08-20 Oracle International Corporation Using annotation processors defined by modules with annotation processors defined by non-module code
US10642589B2 (en) * 2017-03-13 2020-05-05 Memsql, Inc. Extensibility in a database system
US10846417B2 (en) * 2017-03-17 2020-11-24 Oracle International Corporation Identifying permitted illegal access operations in a module system
US10848410B2 (en) 2017-03-29 2020-11-24 Oracle International Corporation Ranking service implementations for a service interface
US11010361B1 (en) * 2017-03-30 2021-05-18 Amazon Technologies, Inc. Executing code associated with objects in a hierarchial data structure
US10120777B1 (en) * 2017-09-29 2018-11-06 Oracle International Corporation Remediating serialization incompatibilities
CN109388542B (zh) * 2018-10-26 2022-02-22 北京百悟科技有限公司 一种监控方法及装置、计算机可读存储介质
US11070377B1 (en) * 2019-02-14 2021-07-20 Bank Of America Corporation Blended virtual machine approach for flexible production delivery of intelligent business workflow rules
US11755825B2 (en) 2019-09-12 2023-09-12 Workiva Inc. Method, system, and computing device for facilitating private drafting
US11188309B2 (en) * 2019-09-27 2021-11-30 Adp, Llc User interface engine for miniapp development
WO2022013887A1 (en) * 2020-07-16 2022-01-20 Morphing Machines Pvt. Ltd Apparatus for implementing dynamic, data-dependent parallelism for task execution based on an execution model
US11100281B1 (en) 2020-08-17 2021-08-24 Workiva Inc. System and method for maintaining links and revisions
US11443108B2 (en) 2020-08-17 2022-09-13 Workiva Inc. System and method for document management using branching
US11494333B2 (en) * 2020-12-02 2022-11-08 Adp, Inc. File tree structure
US11100277B1 (en) 2021-02-15 2021-08-24 Workiva Inc. Systems, methods, and computer-readable media for flow-through formatting for links
US11354362B1 (en) 2021-05-06 2022-06-07 Workiva Inc. System and method for copying linked documents
CN113590134A (zh) * 2021-08-16 2021-11-02 北京字节跳动网络技术有限公司 一种项目生成方法及装置
US11640495B1 (en) 2021-10-15 2023-05-02 Workiva Inc. Systems and methods for translation comments flowback

Family Cites Families (109)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US73892A (en) * 1868-01-28 Improved cbable
US4558413A (en) 1983-11-21 1985-12-10 Xerox Corporation Software version management system
US5481740A (en) 1986-04-14 1996-01-02 National Instruments Corporation Method and apparatus for providing autoprobe features in a graphical data flow diagram
US5497500A (en) 1986-04-14 1996-03-05 National Instruments Corporation Method and apparatus for more efficient function synchronization in a data flow program
US5481741A (en) 1986-04-14 1996-01-02 National Instruments Corporation Method and apparatus for providing attribute nodes in a graphical data flow environment
US5504917A (en) 1986-04-14 1996-04-02 National Instruments Corporation Method and apparatus for providing picture generation and control features in a graphical data flow environment
US5155836A (en) 1987-01-27 1992-10-13 Jordan Dale A Block diagram system and method for controlling electronic instruments with simulated graphic display
JPS6432337A (en) 1987-07-29 1989-02-02 Hitachi Ltd Method for instructing influence of program change
US5371851A (en) 1989-04-26 1994-12-06 Credence Systems Corporation Graphical data base editor
US5313387A (en) 1989-06-30 1994-05-17 Digital Equipment Corporation Re-execution of edit-compile-run cycles for changed lines of source code, with storage of associated data in buffers
DE69126066T2 (de) 1990-06-29 1997-09-25 Oracle Corp Verfahren und Gerät zur Optimierung des Logbuchaufhebungsgebrauchs
EP0528631B1 (en) 1991-08-13 1998-05-20 Xerox Corporation Electronic image generation
JPH05265975A (ja) 1992-03-16 1993-10-15 Hitachi Ltd 並列計算処理装置
US5416895A (en) 1992-04-08 1995-05-16 Borland International, Inc. System and methods for improved spreadsheet interface with user-familiar objects
US5659747A (en) 1993-04-22 1997-08-19 Microsoft Corporation Multiple level undo/redo mechanism
JPH06332785A (ja) 1993-05-25 1994-12-02 Fujitsu Ltd オブジェクト指向データ処理システム
JPH0713766A (ja) * 1993-06-14 1995-01-17 Internatl Business Mach Corp <Ibm> オブジェクト指向コンピュータ・システムおよびオブジェクト・クラス管理方法
US5758160A (en) * 1993-06-28 1998-05-26 Object Technology Licensing Corporation Method and apparatus for building a software program using dependencies derived from software component interfaces
US5893123A (en) 1995-06-22 1999-04-06 Tuinenga; Paul W. System and method of integrating a spreadsheet and external program having output data calculated automatically in response to input data from the spreadsheet
US6003037A (en) 1995-11-14 1999-12-14 Progress Software Corporation Smart objects for development of object oriented software
US5838976A (en) 1995-11-28 1998-11-17 Hewlett-Packard Co. System and method for profiling code on symmetric multiprocessor architectures
US6067415A (en) 1995-12-26 2000-05-23 Kabushiki Kaisha Toshiba System for assisting a programmer find errors in concurrent programs
US7987427B1 (en) 1996-05-10 2011-07-26 Apple Inc. Graphical editor for program files
US5819293A (en) 1996-06-06 1998-10-06 Microsoft Corporation Automatic Spreadsheet forms
US5966072A (en) * 1996-07-02 1999-10-12 Ab Initio Software Corporation Executing computations expressed as graphs
US5822593A (en) 1996-12-06 1998-10-13 Xerox Corporation High-level loop fusion
JP3730740B2 (ja) * 1997-02-24 2006-01-05 株式会社日立製作所 並列ジョブ多重スケジューリング方法
US6145121A (en) 1997-04-17 2000-11-07 University Of Washington Trace based method for the analysis, benchmarking and tuning of object oriented databases and applications
US6026235A (en) 1997-05-20 2000-02-15 Inprise Corporation System and methods for monitoring functions in natively compiled software programs
US6209125B1 (en) 1997-06-03 2001-03-27 Sun Microsystems, Inc. Method and apparatus for software component analysis
US5990906A (en) 1997-06-25 1999-11-23 National Instruments Corporation Undo feature for a graphical programming system
US6233733B1 (en) 1997-09-30 2001-05-15 Sun Microsystems, Inc. Method for generating a Java bytecode data flow graph
US6704927B1 (en) * 1998-03-24 2004-03-09 Sun Microsystems, Inc. Static binding of dynamically-dispatched calls in the presence of dynamic linking and loading
US6427234B1 (en) * 1998-06-11 2002-07-30 University Of Washington System and method for performing selective dynamic compilation using run-time information
US6223171B1 (en) 1998-08-25 2001-04-24 Microsoft Corporation What-if index analysis utility for database systems
US6111575A (en) 1998-09-24 2000-08-29 International Business Machines Corporation Graphical undo/redo manager and method
US6493868B1 (en) 1998-11-02 2002-12-10 Texas Instruments Incorporated Integrated development tool
US6826752B1 (en) * 1998-12-17 2004-11-30 California Institute Of Technology Programming system and thread synchronization mechanisms for the development of selectively sequential and multithreaded computer programs
JP2000207223A (ja) 1999-01-12 2000-07-28 Matsushita Electric Ind Co Ltd 並列処理向けのプログラム処理方法および装置、並びに並列処理向けのプログラム処理を実行するプログラムを記録した記録媒体および並列処理向けの命令列を記録した記録媒体
US6385770B1 (en) 1999-01-29 2002-05-07 Telefonaktiebolaget Lm Ericsson (Publ) Software upgrade
US6957191B1 (en) 1999-02-05 2005-10-18 Babcock & Brown Lp Automated financial scenario modeling and analysis tool having an intelligent graphical user interface
US6571388B1 (en) 1999-03-09 2003-05-27 Hewlett-Packard Development Company, L.P. Building a custom software environment including pre-loaded classes
US6407753B1 (en) 1999-05-04 2002-06-18 International Business Machines Corporation System and method for integrating entities via user-interactive rule-based matching and difference reconciliation
US6665866B1 (en) 1999-05-28 2003-12-16 Microsoft Corporation Extensible compiler utilizing a plurality of question handlers
JP2001005678A (ja) * 1999-06-18 2001-01-12 Fujitsu Ltd ネットワーク型情報処理装置及び方法
WO2001001206A2 (en) 1999-06-30 2001-01-04 Strategic Simulation Systems, Inc. System dynamics model builder and simulator
US6618851B1 (en) 1999-08-31 2003-09-09 Autodesk, Inc. Method and apparatus for state-reversion
US7055130B2 (en) * 1999-10-05 2006-05-30 Borland Software Corporation Methods and systems for identifying dependencies between object-oriented elements
CA2346231A1 (en) 2000-05-08 2001-11-08 Internet Number Corporation Method and system for accessing information on a network using message aliasing functions having shadow callback functions
US6959429B1 (en) 2000-05-16 2005-10-25 Watterson-Prime Software, Inc. System for developing data collection software applications
US6763515B1 (en) 2000-06-05 2004-07-13 National Instruments Corporation System and method for automatically generating a graphical program to perform an image processing algorithm
US20030005407A1 (en) 2000-06-23 2003-01-02 Hines Kenneth J. System and method for coordination-centric design of software systems
US6889227B1 (en) 2000-07-21 2005-05-03 Sun Microsystems, Inc. Database access bridge system and process
RU2206119C2 (ru) 2000-09-22 2003-06-10 Закрытое акционерное общество "МЦСТ" Способ получения объектного кода
US6973640B2 (en) 2000-10-04 2005-12-06 Bea Systems, Inc. System and method for computer code generation
US20020184401A1 (en) 2000-10-20 2002-12-05 Kadel Richard William Extensible information system
US6826523B1 (en) 2000-11-01 2004-11-30 Sony Computer Entertainment America Inc. Application development interface for multi-user applications executable over communication networks
US6829572B2 (en) 2000-12-07 2004-12-07 Internatinal Business Machines Corporation Method and system for efficiently overriding array net values in a logic simulator machine
US6820256B2 (en) 2000-12-13 2004-11-16 Microsoft Corporation System and method for whole-system program analysis
US7200838B2 (en) 2000-12-20 2007-04-03 National Instruments Corporation System and method for automatically generating a graphical program in response to a state diagram
US6836884B1 (en) 2001-06-04 2004-12-28 Microsoft Corporation Method and system for editing software programs
US20020188616A1 (en) 2001-06-07 2002-12-12 Chinnici Roberto R. Database access bridge system and process
US7051339B2 (en) 2001-06-29 2006-05-23 Goldman, Sachs & Co. System and method to measure latency of transaction information flowing through a computer system
US6995765B2 (en) 2001-07-13 2006-02-07 Vicarious Visions, Inc. System, method, and computer program product for optimization of a scene graph
US6966013B2 (en) 2001-07-21 2005-11-15 International Business Machines Corporation Method and system for performing automated regression tests in a state-dependent data processing system
US7236915B2 (en) 2001-08-09 2007-06-26 Hewlett-Packard Development Company, L.P. Technique and interface for computer system resource assignment
US20040205524A1 (en) 2001-08-15 2004-10-14 F1F9 Spreadsheet data processing system
US7010779B2 (en) 2001-08-16 2006-03-07 Knowledge Dynamics, Inc. Parser, code generator, and data calculation and transformation engine for spreadsheet calculations
US7017084B2 (en) * 2001-09-07 2006-03-21 Network Appliance Inc. Tracing method and apparatus for distributed environments
US8473922B2 (en) 2001-09-19 2013-06-25 Hewlett-Packard Development Company, L.P. Runtime monitoring in component-based systems
US7194475B2 (en) 2001-10-30 2007-03-20 International Business Machines Corporation Method, system, and program for performing an impact analysis of program statements in at least one source code file
US7069547B2 (en) 2001-10-30 2006-06-27 International Business Machines Corporation Method, system, and program for utilizing impact analysis metadata of program statements in a development environment
CA2360650A1 (en) 2001-10-31 2003-04-30 Ibm Canada Limited-Ibm Canada Limitee Algorithm to create and compare debug scenarios of a computer process
JP2003157185A (ja) 2001-11-19 2003-05-30 Nec Corp 計算機の動作の解析・表示装置とその解析・表示方法及びコンピュータプログラム
US7203743B2 (en) 2001-12-28 2007-04-10 Nortel Networks Limited Hierarchical tree-based protection scheme for mesh networks
US7039923B2 (en) 2002-04-19 2006-05-02 Sun Microsystems, Inc. Class dependency graph-based class loading and reloading
US7159211B2 (en) 2002-08-29 2007-01-02 Indian Institute Of Information Technology Method for executing a sequential program in parallel with automatic fault tolerance
US7210128B2 (en) 2002-10-14 2007-04-24 Fujitsu Limited Event-driven observability enhanced coverage analysis
US7272820B2 (en) * 2002-12-12 2007-09-18 Extrapoles Pty Limited Graphical development of fully executable transactional workflow applications with adaptive high-performance capacity
TWI262383B (en) 2003-01-10 2006-09-21 Univ Nat Cheng Kung A generic software testing system and method
US7571431B2 (en) 2003-04-29 2009-08-04 Microsoft Corporation Processing macro information and displaying via GUI in different tools
US7299450B2 (en) 2003-06-17 2007-11-20 Microsoft Corporation Undoing changes in a software configuration management system
KR100513385B1 (ko) 2003-06-19 2005-09-07 삼성전자주식회사 선형 위상 검출기를 이용한 클럭 및 데이터 복원 장치 및 그 방법
US7559050B2 (en) 2003-06-30 2009-07-07 Microsoft Corporation Generating software development tools via target architecture specification
US7739252B2 (en) 2003-07-14 2010-06-15 Oracle America, Inc. Read/write lock transaction manager freezing
US7818718B2 (en) 2003-09-30 2010-10-19 Sap Ag Undoing user actions in a client program
US7454701B2 (en) 2003-10-30 2008-11-18 Sap Ag Systems and methods for implementing formulas
US7536678B2 (en) 2003-12-04 2009-05-19 International Business Machines Corporation System and method for determining the possibility of adverse effect arising from a code change in a computer program
US7792824B2 (en) 2004-01-08 2010-09-07 International Business Machines Corporation Apparatus and method for enabling parallel processing of a computer program using existing database parallelism
KR100643268B1 (ko) 2004-01-17 2006-11-10 삼성전자주식회사 자바 가상 머신의 성능을 향상시키는 방법 및 상기 방법에의해 동작되는 시스템
US7917898B2 (en) 2004-02-02 2011-03-29 Intel Corporation Methods and apparatus to provide a modular native method invocation system
US7316001B2 (en) * 2004-06-05 2008-01-01 Graphlogic Inc. Object process graph system
US7493335B2 (en) 2004-07-02 2009-02-17 Graphlogic Inc. Object process graph relational database interface
US7360209B2 (en) 2004-07-16 2008-04-15 Graphlogic Inc. Object process graph application controller-viewer
US7506320B2 (en) 2004-09-09 2009-03-17 International Business Machines Corporation Generating sequence diagrams using call trees
CA2578385A1 (en) 2004-09-10 2006-03-23 Graphlogic Inc. Object process graph application development system
US7933862B2 (en) 2004-09-27 2011-04-26 Microsoft Corporation One click conditional formatting method and system for software programs
CN1755722A (zh) * 2004-10-01 2006-04-05 微软公司 可扩展工作流模型的声明性表示
US7458072B2 (en) 2004-10-06 2008-11-25 Microsoft Corporation Execution context infrastructure
US20060080660A1 (en) * 2004-10-07 2006-04-13 Dell Products L.P. System and method for disabling the use of hyper-threading in the processor of a computer system
US7831956B2 (en) * 2005-09-13 2010-11-09 Microsoft Corporation Using attributes to identify and filter pluggable functionality
US7904892B2 (en) 2006-01-06 2011-03-08 Northrop Grumman Corporation Systems and methods for identifying and displaying dependencies
US7882498B2 (en) * 2006-03-31 2011-02-01 Intel Corporation Method, system, and program of a compiler to parallelize source code
US7844959B2 (en) * 2006-09-29 2010-11-30 Microsoft Corporation Runtime optimization of distributed execution graph
US8902231B2 (en) 2006-10-20 2014-12-02 Alcatel Lucent Method and apparatus for displaying graphical representations of graph layouts
US8332827B2 (en) 2006-12-01 2012-12-11 Murex S.A.S. Produce graph oriented programming framework with scenario support
US7865872B2 (en) 2006-12-01 2011-01-04 Murex S.A.S. Producer graph oriented programming framework with undo, redo, and abort execution support
US8191052B2 (en) 2006-12-01 2012-05-29 Murex S.A.S. Producer graph oriented programming and execution
US8307337B2 (en) 2006-12-01 2012-11-06 Murex S.A.S. Parallelization and instrumentation in a producer graph oriented programming framework

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9201766B2 (en) 2006-12-01 2015-12-01 Murex S.A.S. Producer graph oriented programming framework with scenario support
US9424050B2 (en) 2006-12-01 2016-08-23 Murex S.A.S. Parallelization and instrumentation in a producer graph oriented programming framework
US10083013B2 (en) 2006-12-01 2018-09-25 Murex S.A.S. Producer graph oriented programming and execution
US10481877B2 (en) 2006-12-01 2019-11-19 Murex S.A.S. Producer graph oriented programming and execution

Also Published As

Publication number Publication date
EP2041655B1 (en) 2014-03-19
CN101589366B (zh) 2013-11-13
WO2008064899A3 (en) 2008-12-18
US20130061207A1 (en) 2013-03-07
US8307337B2 (en) 2012-11-06
US9424050B2 (en) 2016-08-23
ES2473765T3 (es) 2014-07-07
WO2008064899A2 (en) 2008-06-05
EP2041655A2 (en) 2009-04-01
RU2009125050A (ru) 2011-01-10
RU2435201C2 (ru) 2011-11-27
CN101589366A (zh) 2009-11-25
US20080134207A1 (en) 2008-06-05
JP2010511233A (ja) 2010-04-08

Similar Documents

Publication Publication Date Title
JP5354601B2 (ja) プロデューサグラフ指向のプログラミングフレームワークにおけるパラレル化及びインスツルメンテーション
JP5354602B2 (ja) プロデューサグラフ指向のプログラミング及び実行
JP5354603B2 (ja) シナリオサポートを伴うプロデューサグラフ指向のプログラミングフレームワーク
US7865872B2 (en) Producer graph oriented programming framework with undo, redo, and abort execution support
EP1328904B1 (en) Parameterized graphs with conditional components
US20050108684A1 (en) Method and system for generating an application object repository from application framework metadata
de Carvalho Junior et al. Contextual abstraction in a type system for component-based high performance computing platforms
CN113841135A (zh) Dbms中的服务管理

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120705

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20121005

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20121015

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20121105

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20121112

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20121205

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20121212

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130805

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130821

R150 Certificate of patent or registration of utility model

Ref document number: 5354601

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250