[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

JP5354603B2 - シナリオサポートを伴うプロデューサグラフ指向のプログラミングフレームワーク - Google Patents

シナリオサポートを伴うプロデューサグラフ指向のプログラミングフレームワーク Download PDF

Info

Publication number
JP5354603B2
JP5354603B2 JP2009538646A JP2009538646A JP5354603B2 JP 5354603 B2 JP5354603 B2 JP 5354603B2 JP 2009538646 A JP2009538646 A JP 2009538646A JP 2009538646 A JP2009538646 A JP 2009538646A JP 5354603 B2 JP5354603 B2 JP 5354603B2
Authority
JP
Japan
Prior art keywords
producer
producers
graph
dependency
scenario
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
JP2009538646A
Other languages
English (en)
Other versions
JP2010511235A (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 JP2010511235A publication Critical patent/JP2010511235A/ja
Application granted granted Critical
Publication of JP5354603B2 publication Critical patent/JP5354603B2/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
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • 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/36—Preventing errors by testing or debugging software
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)
  • Measuring Or Testing Involving Enzymes Or Micro-Organisms (AREA)

Description

本発明の実施形態は、コンピュータの分野に係り、より詳細には、ランタイムでコードをプログラミングして実行する分野に係る。
関連出願への相互参照：適用なし。
オブジェクト指向のプログラミング
オブジェクト指向のプログラミングとは、コンピュータプログラミングパラダイムである。オブジェクト指向のプログラミングの背景にある考え方は、プログラムがファンクションの集合又は単にコンピュータに対するインストラクションのリストとして見える慣習的なビューとは対照的に、コンピュータプログラムが、互いに作用する（オブジェクト又はインスタンスと呼ばれる）個々のユニットの集合より成るものとして見えるというものである。オブジェクトとは、データを、そのデータに対して動作するメソッドと結び付けるための言語メカニズムである。各オブジェクトは、メソッドを通してコールされ、データを処理し、そして結果を他のオブジェクトへ与えることができる。各オブジェクトは、個別の役割又は責任をもつ独立したマシン又はアクターとして見ることができる。
リフレクティブなオブジェクト指向の言語とは、特徴（例えば、クラス、オブジェクト／インスタンス、継承、リフレクション、等）の特定セットを有するプログラミング言語であるが、リフレクティブなオブジェクト指向の言語は、これらの特徴のあるサブセット（例えば、オブジェクト）を有するプログラミング言語をラベリングするのに時々使用される。本書の目的上、「オブジェクト指向のソースコード」及び「オブジェクト指向のコード」という句は、このような特徴を有する言語で書かれたコード（例えば、リフレクティブなオブジェクト指向の言語で書かれたコード、リフレクティブなオブジェクトベースの言語で書かれたコード）を指すのに使用される。手続き型言語、非リフレクティブなオブジェクト指向の言語、及び非リフレクティブなオブジェクトベースの言語は、典型的にこのような特徴をサポートしないプログラミング言語であるが、変換技術を使用して、このような特徴を（例えば、エミュレーションにより）このような言語で適切に書かれたコードに与えることができ、従って、このような技術は、このような言語をリフレクティブなオブジェクトベースの言語又はリフレクティブなオブジェクト指向の言語へ変換する。（これらの技術は、オブジェクト指向又はオブジェクトベースの言語の全ての特徴をエミュレートする必要がなく、本書の残り部分に対して問題となる特徴のみをエミュレートすればよい。）又、本書の目的上、「オブジェクト指向のソースコード」及び「オブジェクト指向のコード」という句は、このように変換された手続き型言語、非リフレクティブなオブジェクト指向の言語、及び非リフレクティブなオブジェクトベースの言語のコードを指すのにも使用される。例えば、これに限定されないが、本書は、主として、リフレクティブなオブジェクト指向の言語で書かれたオブジェクト指向のソースコードについて記述する。又、オブジェクト及びインスタントという語は、ここでは、交換可能に使用する。
オブジェクト指向のプログラミングに主として使用されるメソッドという語は、クラスに排他的に関連したコードの断片（クラスメソッド、スタティックメソッド、又はファクトリメソッドと称される）又はオブジェクトに排他的に関連したコードの断片（インスタンスメソッドと称される）を指す。手続き型プログラミング言語の手続きと同様に、メソッドは、通常、アクションを遂行する一連のステートメント、これらアクションをパラメータ化するための入力パラメータのセット、及びおそらく、返送されるある種の出力値で構成される。
プログラマーがオブジェクト指向の言語を使用してプログラムを書くときに、得られるコードは、概念的には、４つの基本的形式のコードを含むものとして見ることができる。第１の形式は、入力インスタンス（１つ又は複数）に対して動作して出力インスタンス（１つ又は複数）を与えるコマンド（ここでは、「変換」コードと称される）を含み、これは、典型的に、メソッド（ここでは、「変換」メソッドと称される）として書かれる。第２の形式は、ランタイム(runtime)がクラスのインスタンスをインスタンス生成するようにさせるインスタンスインスタンス生成コマンド（ここでは、「インスタンスインスタンス生成」コードと称される）を含む。第３の形式は、前記インスタンスのプロパティメソッド（アクセッサ、ミューテータ、等）をインボークするためのプロパティ操作コマンド（ここでは、「データ準備」コードと称される）を含む。第４の形式は、適切なインスタンス（適切なインスタンスとは、引数として使用するためのインスタンス、インスタンスメソッドにより使用されるインスタンス、及びクラスメソッドにより使用されるメタクラスインスタンスを含む）を使用してメソッドインボケーションシーケンスを生じさせて、インボークすべきどんなインスタンスのどんな変換メソッドを、どの順序で、且つデータ準備コードによってなされた変化に応答してどのインスタンスのどのパラメータで指定するかの一連のコマンド（ここでは、「手動インボケーションシーケンス」コードと称される）を含む。手動インボケーションシーケンスコードは、時々、変換メソッドとは個別のメソッドとして書かれ、従って、手動インボケーションシーケンスコードは、変換メソッドに対する一連のインボケーションコマンドを含む。プログラムは、典型的に、データ準備コードと手動インボケーションシーケンスコード（これは、インスタンスインスタンス生成コードへとディップすることもある）との間で繰り返され、これは、次いで、変換コードをインボークする（これも、インスタンスインスタンス生成コード及びデータ準備コード形式へとディップすることがある）。これは、プログラムの概念的表現であり、従って、プログラムをどのように見るかについて絶対的なものと考えてはならないことに注意されたい。
ランタイム
ここで使用するランタイム(runtime)という語は、同じ及び／又は異なる言語で書かれた他のコードを実行する基本的コードのプログラム又はライブラリーを指す。従って、ランタイムは、オペレーティングシステムで動作して、数学的ファンクション、入力及び出力のようなファシリティを与えることを含めて、その実行中にプログラムをサポートするユーティリティファンクションの集合である。これは、プログラマーが、プログラミング言語で指定されるか又はオペレーティングシステムによって与えられた基本的能力を常時再書き込みするのを不要にする。ランタイムとオペレーティングシステムとの間の境界はぼやけているので、ここで使用するランタイムという語は、オペレーティングシステムとは個別のコード及び／又はオペレーティングシステムの一部であるコードを指すものとする。
ＦＯＲＴＲＡＮの場合のような初期のランタイムは、数学的オペレーションのような特徴を与える。他の言語は、より精巧な特徴、例えば、メモリガベージ収集を、オブジェクトに対するサポートにしばしば関連して追加する。より最近の言語は、著しく多くのファンクションを伴う著しく大きなランタイムを有する傾向がある。多くのオブジェクト指向の言語は、「ディスパッチャー」及び「クラスローダー」として知られているシステムも含む。Ｊａｖａ（登録商標）バーチャルマシン（ＪＶＭ）は、このようなランタイムの一例であり、ポータブルバイナリーＪａｖａプログラム（バイト−コード）をランタイム時に解釈又はコンパイルする。共通言語ランタイム（ＣＬＲ）フレームワークは、ランタイムの別の例である。
プログラミング及び実行フレームワーク
アプリケーションがエンドユーザに与えられるところの１つのフレームワークは、３つの基本的区分を含む。第１の区分は、オペレーティングシステム及びランタイムの生成を含む。この第１の区分は、非常に高度なプログラミングスキルをもつプログラマーにより遂行される。この区分で働くときには、プログラマーは、各々、オペレーティングシステムプログラマー及びランタイムプログラマーと称される。オブジェクト指向の言語に対してランタイムを生成するときに、ランタイムプログラマーは、変換コード、インスタンスインスタンス生成コード、データ準備コード、及び手動インボケーションシーケンスコードに使用される種々の形式のコマンド（例えば、インスタンスインスタンス生成コマンド、データ準備コマンド、及びメソッドインボケーションコマンド）を実行するためのサポートを含む。
第２の区分は、ランタイムにより実行されるオブジェクト指向のアプリケーションソースコードの生成を含む。この第２の区分も、非常に高度なプログラミングスキルをもつと共にアプリケーションのビジネス目標を理解するプログラマーによって遂行される。この区分で働くときには、プログラマーは、アプリケーションプログラマーと称される。オブジェクト指向のプログラミング言語でアプリケーションを生成するときに、アプリケーションプログラマーは、生成される特定のアプリケーションに対して、特定の変換コード、インスタンスインスタンス生成コードデータ準備コード、及び手動インボケーションシーケンスコードを書き込む。これの一部分として、アプリケーションがグラフィックユーザインターフェイスを要求する場合には、アプリケーションプログラマーは、特定のアプリケーションに対してグラフィックユーザインターフェイスの設計及びコード化も行い、従って、アプリケーションデザイナーとも称される。
第３の区分は、ランタイムによって実行されているアプリケーションプログラムの使用を含む。この第３の区分は、プログラミングスキルを必要としないエンドユーザによって遂行される。
手動インボケーションシーケンスコード
アプリケーションの生成に典型的に関連した最大のコストは、手動インボケーションシーケンスコードのデバッグ及び／又は最適化を含む。データを変更する機会のたびに、アプリケーションプログラマーは、その効果を考慮し、そして適切なインスタンスの適切な変換メソッドを適切な入力により適切な順序でインボークさせるように手動インボケーションシーケンスコードを書かねばならない。アプリケーションプログラマーによりなされるミステークは、例えば、１）適切なインスタンスの適切な変換メソッドを誤った順序でインボークすること、２）あるデータが変更されるのに応答して、１つ以上の要求されたインスタンス変換メソッドをインボークさせるコマンドを含ませるのを忘れること、３）あるデータが変更されるのに応答して、不必要なインスタンス変換メソッドをインボークさせるコマンドを含ませること（例えば、データの変更による影響のないインスタンスの変換メソッドをインボークするコマンドを含ませること）、等を含む。
例えば、手動インボケーションシーケンスコードを発生する１つの技術は、オブザーバーパターン（時々「パブリッシュ・サブスクライブ(publish subscribe)」としても知られている）を使用して、プログラムにおけるインスタンスの状態を観察することである。オブザーバーパターンでは、１つ以上のインスタンス（オブザーバー又はリスナーと呼ばれる）が登録され（又はそれら自体を登録し）、観察されたオブジェクト（主題）により起り得る事象を観察する。ある事象を生じ得る観察されたインスタンスは、一般に、登録されたオブザーバーの集合を維持する。事象が生じると、各オブザーバーは、観察されたインスタンスからのコールバックを受け取る（観察されたインスタンスは、登録されたオブザーバーにおいて「通知(notify)」メソッドをインボークする）。この通知ファンクションは、オブザーバーによって使用できる幾つかのパラメータ（一般的に、発生する事象に関する情報）をパスすることができる。各オブザーバーは、通知ファンクションを具現化し、その結果、通知が生じるときにそれ自身の振舞いを定義する。
観察されたインスタンスは、典型的に、新たなオブザーバーを追加するための登録メソッドと、事象が生じたときに通知されるべきインスタンスのリストからオブザーバーを除去するための非登録メソッドとを有する。更に、観察されたインスタンスは、多数の関連更新の非効率的なカスケード化を防止するために一時的にディスエイブルし、次いで、再イネーブルするためのメソッドも含むことができる。より詳細には、プロパティ値の変化に応答してコールされるコールバックは、しばしば、幾つかの他のプロパティの値も変化させ、付加的なコールバックをトリガーし、等々である。
オブザーバーパターン技術を使用するときには、手動インボケーションシーケンスコードを書くアプリケーションプログラマーは、観察される異なるインスタンスに対してオブザーバーを登録し、非登録とし、ディスエイブルし及び再イネーブルすると共に、各々について通知及びコールバックメソッドを書き込むことにより、どんなインスタンスのどんなメソッドをどの順序で且つどの入力でコールするか指定する。より詳細には、オブザーバーと、観察されるインスタンスとの関係は、オブザーバーパターン内でローカルに管理され（観察される他のインスタンスと同期せずに、観察されるインスタンスのみにより）、従って、観察される複数のインスタンスからの事象と同期する必要のある手動インボケーションシーケンスコードは、典型的に、各オブザーバーの特定のコールバックメソッドの一部分である。
オーバーライティング・揮発性コールスタック
典型的なランタイムは、オーバーライティング・揮発性コールスタックを使用して、現在インボークされている未完了のコールを追跡する。オーバーライティング・揮発性コールスタックは、各コールが完了すると、ポップオフしてエントリーを破棄するという点でオーバーライティングであり、且つ実行のたびに破棄されて再構築されるという点で揮発性である。典型的なランタイムがオーバーライティング・揮発性コールスタックを使用するのは、典型的なランタイムが、オーバーライティング・揮発性コールスタックを構築することを、手動インボケーションシーケンスコードの実行に応答して適切な入力で適切なインスタンスの適切な変換メソッドを実際にインボークすることと結合するからである。要約すれば、手動インボケーションシーケンスコードの実行に応答して、典型的なランタイムは、インスタンスシーケンスの変換メソッドをコールごとに（各コールがなされるときに）決定し、そして現在インボークされている未完了のコールのみを追跡するようにオーバーライティング・揮発性コールスタックを維持する。
オブジェクト関連マッピング
オブジェクト関連マッピングとは、関連データベースをオブジェクト指向の言語概念にリンクして「バーチャルオブジェクトデータベース」を（実際に）生成するプログラミング技術である。あるオブジェクト関連マッパーは、メモリにロードされるインスタンスを自動的にデータベースと常時同期状態に保持する。より詳細には、オブジェクト・対・ＳＱＬマッピング問合せを構成した後、最初に返送されるデータが、オブジェクト−ＳＱＬマッピングパッケージと同様に、当該インスタンスのフィールドにコピーされる。そのようになると、インスタンスは、これらの値が変化するかどうか調べるために監視し、次いで、データをデータベースに書き戻すためにプロセスを慎重に逆転しなければならない。
Ｈｉｂｅｒｎａｔｅ３．０は、Ｊａｖａ及びＣＬＤ（ジョージア州アトランタのＪｂｏｓｓ（登録商標）インク）に対するオブジェクト関連マッピング解決策である。従って、Ｈｉｂｅｒｎａｔｅは、オブジェクト指向のドメインモデルを慣例的な関連データベースへマッピングするためのフレームワークを与える。その目標は、ある共通のデータ持続性に関連したプログラミングタスクから開発者を救援することである。Ｈｉｂｅｒｎａｔｅは、クラスからデータベーステーブルへの（及びオブジェクト指向のデータ形式からＳＱＬデータ形式への）マッピングを取り扱うと共に、データ問合せ及び検索ファシリティを与える。Ｈｉｂｅｒｎａｔｅは、インスタンス中心であり、インスタンス間の関係を表すグラフを構築する。
制御の逆転及び依存性逆転原理
ＩＯＣとしても知られている制御の逆転は、コンピュータプログラムに本来ある結合（各プログラムモジュールが互いに他のモジュールに依存する程度）を減少するのに使用できるオブジェクト指向のプログラミング原理である。ＩＯＣは、依存性逆転原理としても知られている。ＩＯＣにおいて、次のいずれかに該当する場合、即ち、１）クラスＸがクラスＹを有して、それにコールするか、２）ＸがＹであるか、又は３）ＸがあるクラスＺに依存し、これがＹに依存する（推移性の）場合に、クラスＸがクラスＹに依存する。ＸがＹに依存することは、ＹがＸに依存することを意味せず、即ち両方が真となる場合にはサイクリック依存性と称され、ＹなしにＸを使用することはできず、又、その逆ことも言えることに注意する価値がある。
実際に、（クラスＸの）オブジェクトｘが、（クラスＹの）オブジェクトｙのメソッドをコールする場合には、クラスＸがＹに依存する。第３のクラス、即ちｘがｙをコールし得る全てのメソッドを含まねばならないインターフェイスクラスＩを導入することにより、依存性が逆転される。更に、Ｙは、それがインターフェイスＩを具現化するように変更されねばならない。ここで、Ｘ及びＹの両方がインターフェイスＩに依存し、クラスＸは、もはやクラスＹに依存しない（ＸがＹをインスタンス生成しないと仮定すれば）。インターフェイスＩを導入することによりＹに対するクラスＸの依存性をこのように排除することは、制御の逆転（又は依存性逆転）であると言える。Ｙは、他のクラスに依存してもよいことに注意されたい。変換が適用される前に、ＸはＹに依存し、従って、Ｘは、Ｙが依存する全てのクラスに間接的に依存する。制御の逆転を適用することにより、これら全ての間接的依存性も崩壊される。新たに導入されるインターフェイスＩは、何物にも依存しない。
スプリングフレームワークは、ＩＯＣ及び依存性逆転を使用するＪａｖａプラットホームに対するオープンソースアプリケーションフレームワークである。より詳細には、スプリングフレームワークの中心は、Ｊａｖａオブジェクトを構成し及び管理する手段をなす制御逆転コンテナである。このコンテナは、ＢｅａｎＦａｃｔｏｒｙ、ＡｐｐｌｉｃａｔｉｏｎＣｏｎｔｅｘｔ又はＣｏｒｅコンテナとしても知られている。このコンテナのオペレーションは、例えば、オブジェクトを生成し、オブジェクトを構成し、初期化メソッドをコールし、そして登録されたコールバックオブジェクトにオブジェクトを通すことである。コンテナにより生成されたオブジェクトは、管理オブジェクト又はビーンとも呼ばれる。典型的に、コンテナは、ビーン定義を含むＸＭＬファイルをロードすることによって構成される。これらは、オブジェクトを生成するのに必要な全ての情報を与える。エラー状態を生じることなくオブジェクトが生成されて構成されると、それらが使用できるようになる。オブジェクトは、依存性ルックアップ又は依存性注入により得ることができる。依存性ルックアップは、発呼者が特定の名前又は特定形式のオブジェクトについてコンテナオブジェクトに尋ねるパターンである。依存性注入は、コンテナが、コンストラクタ、プロパティ又はファクトリメソッドのいずれかを経て、オブジェクトを名前によって他のオブジェクトへ通すパターンである。従って、スプリングフレームワークは、メモリ中心であり、インスタンス間の関係を表すグラフを構築する。
グラフツール
ＪａｖａｄｏｃTMは、Ｊａｖａソースファイルのセットにおける宣言及びドキュメンテーションコメントを構文解析し、そしてパブリック及び保護クラス、ネスト状クラス（匿名の内部クラスではない）、インターフェイス、コンストラクタ、メソッド、及びフィールドを（デフォールトにより）記述するＨＴＭＬページの対応セットを発生するツールである（カリフォルニア州サンタクララのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）インク）。Ｊａｖａｄｏｃは、ソースファイルのセットに対してＡＰＩ（アプリケーションプログラミングインターフェイス）ドキュメンテーション又は具現化ドキュメンテーションを発生するのに使用できる。又、Ｊａｖａｄｏｃは、クラス及びメソッド中心であり、クラス及びそれらのメソッドの組合せ間の関係を表すグラフを構築する。
ソフトウェアアプリケーションを設計するための別のシステムは、コンピュータアプリケーションを表現し及び再生するためにインタープリターにより分析されたオブジェクトのグラフを含む。このシステムは、コードライブラリに記憶された予め書かれたプログラミングクラスを使用し、これは、１９９５年、Addison Wesley、Gamma氏等による“Design Patterns”、１９９８年、Wiley Computer Publishing、Grandによる“Patterns in Java”、及び／又は高レベルのコンピュータ支援型ソフトウェアエンジニアリング（ＣＡＳＥ）ツールに記載された設計パターンに従うように書くことができる。より詳細には、幾つかのこのようなクラスは、オブザーバーの振舞いパターンに基づく。予め書かれたコードのライブラリーは、アプリケーション状態ノード、処理ロジック、及び種々のアプリケーション状態間のシステムのデータ流（即ち、アプリケーションの予め書かれたデータエレメント）を表し、ソフトウェアアプリケーションを生成するときに、ユーザがコードを書き込み、編集し又はコンパイルする必要がないようにする。むしろ、ユーザは、アプリケーション状態ノード内のデータ又はアプリケーション状態ノード内で遂行されるプロセスのような、現在アプリケーション状態ノードに関連した視覚的オブジェクトを編集することにより、グラフィックユーザインターフェイスにおいてソフトウェアアプリケーションを手動で編集する。次いで、現在アプリケーション状態ノードに対してユーザによりなされた変化に基づき、インタープリターは、丁度編集されたアプリケーション状態に対して、更新されたアプリケーション状態をユーザに表示する。システムは、次いで、ユーザ定義された移行エッジに沿って別のアプリケーション状態へ移行することができ、そこで、ユーザは、次のアプリケーション状態又は移行エッジを任意に編集することができる。グラフに対する変更は、ソフトウェアアプリケーションが実行されている間にインタープリターにより具現化されるグラフのインスタンスに対して行うことができる。
ソフトウェアアプリケーションを設計するためのこのシステムは、アプリケーションコントローラで「使用可能」にすることができる実行中のソフトウェアアプリケーションの視覚的表現を含む。実行中のソフトウェアアプリケーションを表す視覚的オブジェクトをユーザが変更するときには、コントローラが入力を使用して、インタープリターがグラフに対する変更を行うよう誘導する。次いで、コントローラは、より多くの変更を待機する。更に、このようなソフトウェアアプリケーションの視覚的表現を、アプリケーション、ひいては、ソフトウェアアプリケーションの視覚的表現を記述するＸＭＬドキュメントとしてインポート又はエクスポートすることができる。
ノード、指令されたエッジ及びアプリケーション状態の視覚的表現の形態でソフトウェアアプリケーションを編集し及び／又は生成するために、アプリケーションプログラムインターフェイス及びアプリケーションエディタをシステムに更に含ませることができる。予め書かれたコードライブラリからのキーワード及び関連定義は、アプリケーション開発者が、実際のアプリケーション構造に厳密に相関したグラフアプリケーションのグラフ的表現をエディタ内に設けることにより、ソフトウェアアプリケーション、処理ステップ、及びソフトウェアアプリケーションの視覚的表現を手動で定義することができるようにする。ユーザは、「アプリケーション定義ウイザード」を通して新たなアプリケーションを定義し、このウイザードは、ある事前の事柄が満足された後に、新たなアプリケーションをエディタワークスペース内のグラフコンポーネントとして表示する。ユーザは、更に、予め生成された考えられるアプリケーションコンポーネントの表示されたリストから選択を行い、そしてＰＣのマウス及びキーボードを使用してワークスペース上でコンポーネントをドラグしてドロップすることにより、アプリケーションと対話する。ユーザは、コンポーネントを選択し、それらを既存のコンポーネントの上に「ドラグ」することができる。新たなコンポーネントが既存のコンポーネント上に「ドロップ」されると、新たなコンポーネントは、アプリケーショングラフ内で既存のコンポーネントの子となる。アプリケーション内のコンポーネントの関係は、エディタ内でのユーザ選択により手動で定義される。従って、アプリケーションを表すツリー構造がユーザによって構築される。アプリケーションが生成されると、ユーザは、アプリケーションナビゲータビューアを選択して、構成されたアプリケーションのツリービューを表示し、アプリケーションの任意のコンポーネントを選択して編集できるようにする。エディタインターフェイスは、アプリケーションエレメントを生成又は削除し、コンポーネントの属性を更新し、そしてアプリケーションの表示プロパティを更新することを含めて、ユーザ入力及び選択を処理する。
上述したシステムは、ソフトウェアアプリケーションの視覚的表現を使用するが、関連データベースを定義し及び更新するための視覚的プログラミングツールとして使用することもできる。このシステムは、ソフトウェアアプリケーションの視覚的表現のＸＭＬ記述を使用する。ツールは、ＸＭＬ記述を構文解析し及び解釈して、同等の関連データベーステーブルスキーマ及びそれに対する変更を発生する。ソフトウェアアプリケーションの視覚的表現内でデータが変更されたときには、変更の記述が、ジャーナルファイルにおける他の変更と共に記憶され、次いで、グループとして処理される。中間プログラム（それ自身のスレッドで動作するＪａｖａアプリケーション）は、ソフトウェアアプリケーションの視覚的表現と、関連データベースとの間のトランザクションを遂行する。Ｊａｖａアプリケーションは、視覚的表現のノード（即ち、データベースのデータ）に対する変更のジャーナルをポーリングし（即ち、チェックし）、そして変更があった場合に、データベースに対して変更を行う。従って、視覚的表現内のデータを変更することにより、システムは、データベースを更新する。データベースからのデータの要求を取り扱うために、ソフトウェアアプリケーションの視覚的表現とデータベースとの間に同様のアプリケーションが存在する。
ソフトウェアを分析するための別のシステムは、コードツリーアナライザ（ＣＴＡ）と称される。ＣＴＡは、オブジェクト指向のプログラミング言語で書かれたスタティックソースコードを分析する。ＣＴＡは、記号テーブル及びコールツリーをスタティックソースコードから発生する。記号テーブルを使用して、ＣＴＡは、クラスダイアグラムを発生する。同様に、コールツリーを使用して、ＣＴＡは、シーケンスダイアグラムを発生する。クラスダイアグラムは、ユーザ選択クラスと、ユーザ選択クラスに関連したクラスとの間の関係を示す。シーケンスダイアグラムは、異なるメソッドがコールされるシーケンスを示す。クラスダイアグラム及びシーケンスダイアグラムの両方を使用して、ＣＴＡは、スタティックソースコードを表す設計アーティファクトを発生する。ユーザがこの設計アーティファクトを変更するときに、ＣＴＡは、シーケンスダイアグラムを使用して、ソースコードのインパクト部分を識別する。設計アーティファクトは、スタティックソースコードのコードメンテナンス及び／又は逆行分析(reverse engineering)に使用される。
シナリオサポートを伴うプロデューサグラフ指向のプログラミングフレームワークの実施形態が提示される。一実施形態において、アプリケーションプログラム上の変化による潜在的なインパクトを評価するための要求が受け取られる。アプリケーションプログラムは、少なくとも、インスタンス及びそのインスタンスに関連したメソッドを各々有するプロデューサのセットを含む。その要求に応答して、アプリケーションプログラムは、プロデューサの既存の状態及び既存の出力が保存される間にその変化でシミュレーションすることができる。
本発明の実施形態を示した添付図面及び以下の詳細な説明を参照することにより本発明が最も良く理解されよう。
本発明の一実施形態によりオブジェクト指向のソースコードにおけるクラスのメソッドに対するプロデューサ依存性宣言と、そのクラス、そのクラスの所与のインスタンス及びそのクラスのメソッドを含むプロデューサとの関係を示すブロック図である。 本発明の一実施形態によるプロデューサ１１０Ａと親プロデューサ１１４Ａ．１との間の関係を例示する。 本発明の一実施形態によるプロデューサ１１０Ａと子プロデューサ１１２Ａ．１との間の関係を例示する。 本発明の一実施形態による親プロデューサ１１４及び子プロデューサ１１２とプロデューサ１１０Ａとの関係の付加的な組合せを例示する。 本発明の一実施形態により、同じクラスの異なるインスタンスが同じ及び／又は異なるメソッドに基づきプロデューサを有することができることを示す。 本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムの再使用性を示すブロック図である。 本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。 本発明の一実施形態により増分的実行及びオーバーライドされたプロデューサ出力もサポートするプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。 本発明の一実施形態により例示的プロデューサグラフの発見及び構築を示すブロック図である。 本発明の一実施形態により図４Ａのプロデューサグラフの初期の実行を示すブロック図である。 本発明の一実施形態により図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。 本発明の一実施形態により従属プロデューサ２がオーバーライドされた後の図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。 本発明の一実施形態により従属プロデューサ２がオーバーライドされそして独立ソースプロデューサ３が変更された後の図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。 本発明の一実施形態により未解明の依存性を含む例示的プロデューサグラフの発見及び構築を示すブロック図である。 本発明の一実施形態により図５Ａのプロデューサグラフの初期の実行と、未解明の依存性の解明とを示すブロック図である。 本発明の一実施形態により図５Ａのプロデューサグラフの初期の実行及び／又は図５Ｂのプロデューサグラフの再実行を示すブロック図である。 本発明の一実施形態により図５Ａのプロデューサグラフの初期の実行及び／又は図５Ｂ又は５Ｃのプロデューサグラフの再実行を示すブロック図である。 本発明の一実施形態により、ランタイムクライアントの論理的実行フローと、プロデューサグラフ指向のプログラミングサポートを伴うランタイムに対するその関係とを示すフローチャートである。 本発明の一実施形態によりショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による例示的プロデューサのブロック図である。 本発明の一実施形態により非ショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示すと共に、例示的プロデューサのブロック図である。 本発明の一実施形態により非ショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による例示的プロデューサのブロック図である。 本発明の一実施形態により依存性決定プロデューサを伴うUpwardDependencyの使用による例示的依存性を示すブロック図である。 本発明の一実施形態により依存性決定プロデューサを伴うWeaklyConstrainedDependencyの使用による例示的依存性を示すブロック図である。 本発明の一実施形態による標準的プロデューサの例示的プロデューサグラフを示す。 図７Ｈのプロデューサグラフを発見し、解明しそして構築するためのプロデューサ依存性及び依存性決定プロデューサの一例を示す。 本発明の一実施形態によりアプリケーションがエンドユーザに与えられるところの第１の例示的フレームワークを示すブロック図である。 本発明の一実施形態によりアプリケーションがエンドユーザに与えられるところの第２の例示的フレームワークを示すブロック図である。 本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０での自由セル選択の例示的スクリーンショット及び使用を示す。 本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０での自由セル選択の別の例示的スクリーンショット及び使用を示す。 本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０でのテーブル生成の例示的スクリーンショット及び使用を示す。 本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０でのテーブル生成の別の例示的スクリーンショット及び使用を示す。 本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第１のスキームを示すブロック図である。 本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第２のスキームを示すブロック図である。 本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第３のスキームを示すブロック図である。 本発明の一実施形態による例示的具現化のブロック図である。 本発明の一実施形態による図１０のクラス追跡構造１０９２の一例を示すブロック図である。 本発明の一実施形態による図１０のインスタンス追跡構造１０６５の一例を示すブロック図である。 本発明の一実施形態による図１０のプロデューサグラフ構造１０６０の一例を示すブロック図である。 本発明の一実施形態による図１０のメソッド追跡構造１０５８の一例を示すブロック図である。 本発明の一実施形態によりコンティンジェント及びサブスクリプション形式のダイナミックプロデューサ依存性をサポートするための図１０の付加的な細部を示すブロック図である。 本発明の一実施形態による非ショートカット宣言、非ダイナミック（非コンティンジェント、非サブスクリプション）依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による例示的非ショートカット宣言、非ダイナミック（非コンティンジェント、非サブスクリプション）プロデューサ依存性を示すプロデューサのブロック図である。 本発明の一実施形態による非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による例示的非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。 本発明の一実施形態による非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性の両方を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。 本発明の一実施形態によるショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、非コンティンジェント、非サブスクリプションのプロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による例示的ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、非コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。 本発明の一実施形態によるショートカット宣言、非ダイナミック（非コンティンジェント、非サブスクリプション）プロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示す。 本発明の一実施形態による例示的ショートカット宣言、非ダイナミックプロデューサ依存性を示すプロデューサのブロック図である。 本発明の一実施形態による図１２のサブスクリプションログ１２５０の一例を示すブロック図である。 本発明の一実施形態による非コンティンジェント、アブソーブサブスクリプションプロデューサ依存性を示す例示的プロデューサのブロック図である。 本発明の一実施形態による非コンティンジェント、スティッキーサブスクリプションプロデューサ依存性を示す例示的プロデューサのブロック図である。 本発明の一実施形態により、スティッキーサブスクリプションにより生成される親依存性決定プロデューサに基づく親プロデューサの選択を示す。 本発明の一実施形態により、シーケンス依存性によりリンクされる子依存性決定プロデューサによって生成される親依存性決定プロデューサに基づく親プロデューサの選択を示す。 本発明の一実施形態により新たなインスタンスをインスタンス生成するためのフローチャートである。 本発明の一実施形態により新たなプロデューサ及び非オーバーライドプロデューサをインスタンス生成するためのフローチャートである。 本発明の一実施形態による図１６のブロック１６５０のフローチャートである。 本発明の一実施形態による図１７のブロック１７４５のフローチャートである。 本発明の一実施形態による図１６のブロック１６３０のフローチャートである。 本発明の一実施形態による図１６のブロック１６３５及び１６７０のフローチャートである。 本発明の一実施形態によりプロデューサをオーバーライドするためのフローチャートである。 本発明の一実施形態により現在プロデューサグラフを実行するためのフローチャートの一部分である。 本発明の一実施形態により現在プロデューサグラフを実行するためのフローチャートの別の部分である。 本発明の一実施形態による図２２のブロック２２０５に対するフローチャートである。 本発明の一実施形態による図２２のブロック２２２５に対するフローチャートである。 本発明の一実施形態による図２２のブロック２２６０に対するフローチャートである。 シナリオをサポートする本発明の別の実施形態を示す。 本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポート及びシナリオサポートを伴うランタイムを示すブロック図である。 本発明の一実施形態により増分的実行及びオーバーライドされたプロデューサ出力並びにシナリオもサポートするプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。 異なるシナリオに対するアプリケーションプログラムの例示的プロデューサグラフを示す図である。 異なるシナリオに対するアプリケーションプログラムの例示的プロデューサグラフを示す図である。 異なるシナリオに対するアプリケーションプログラムの例示的プロデューサグラフを示す図である。 異なるシナリオに対するアプリケーションプログラムの例示的プロデューサグラフを示す図である。 本発明の一実施形態により、ランタイムクライアントの論理的実行フローと、プロデューサグラフ指向のプログラミングサポートを伴うランタイムに対するその関係とを示すフローチャートである。 シナリオをサポートする本発明の一実施形態による別の具現化のブロック図である。 クラス追跡構造の一実施形態を示す。 インスタンス追跡構造の一実施形態を示す。 プロデューサグラフ構造の一実施形態を示す。 シナリオ追跡構造の一実施形態を示す。 シナリオオブジェクト追跡構造の一実施形態を示す。 インパクトリストの一実施形態を示す。 本発明の一実施形態による新シナリオインスタンス生成の流れを示すフローチャートである。 本発明の一実施形態によりシナリオをサポートする新インスタンス生成の流れを示すフローチャートである。 本発明の一実施形態によりターゲットシナリオにおいて新ストレス型プロデューサのインスタンス生成を示すフローチャートである。 本発明の一実施形態によりターゲットシナリオにおいて新ストレス型プロデューサのインスタンス生成を示すフローチャートである。 本発明の一実施形態によりターゲットシナリオにおいて新ストレス型プロデューサのインスタンス生成を示すフローチャートである。 本発明の一実施形態によりターゲットシナリオにおいて新ストレス型プロデューサのインスタンス生成を示すフローチャートである。 本発明の一実施形態によりターゲットシナリオにおいて新ストレス型プロデューサのインスタンス生成を示すフローチャートである。 本発明の一実施形態によりターゲットシナリオにおいて新ストレス型プロデューサのインスタンス生成を示すフローチャートである。 本発明の一実施形態によりターゲットシナリオにおいて新ストレス型プロデューサのインスタンス生成を示すフローチャートである。 本発明の一実施形態によりストレス型プロデューサグラフ実行の流れを示すフローチャートである。 本発明の一実施形態によりストレス型プロデューサグラフ実行の流れを示すフローチャートである。
以下の説明において、本発明をより完全に理解するために、ロジックの具現化、ｏｐコード、オペランドを指定する手段、リソースの区分化／分担／複製の具現化、システムコンポーネントの形式及び相互関係、並びにロジックの区分化／一体化の選択のような多数の特定の細部について述べる。しかしながら、当業者であれば、このような特定の細部を伴わずに本発明を実施できることが明らかであろう。他の点では、本発明を不明瞭にしないため、制御構造、データ構造、及び全ソフトウェアインストラクションシーケンスは、詳細に示さない。当業者であれば、過度の実験を行わなくても、ここに含まれた説明で、適切な機能を具現化することができるであろう。
特に指示のない限り、（分割の破線を除いて）図中の破線は、図中でオプションアイテムを表すのに使用される。しかしながら、破線を使用して全てのオプションアイテムを示すことを想定してはおらず、破線で示されたものは、種々の理由で選択されたものである（例えば、より明瞭にするために、容易に示すことができる、等）。
本明細書において、「１つの実施形態」、「一実施形態」、「例示的な実施形態」、等は、ここに述べる実施形態が、特定の特徴、構造又は特性を含むが、各々の実施形態が、必ずしも、特定の特徴、構造又は特性を含まなくてもよいことを指示する。更に、このような句は、必ずしも、同じ実施形態を指すものではない。更に、特定の特徴、構造又は特性が、ある実施形態に関連して説明されるときには、他の実施形態が明確に説明されるかどうかに関わらず、他の実施形態に関連してこのような特徴、構造又は特性に作用を及ぼすことも、当業者の知識の中でなし得るものとする。
以下の説明及び特許請求の範囲において、「結合(coupled)」及び「接続(connected)」という語は、その派生語と共に、使用することができる。これらの語は、互いに類義語として意図されないことを理解されたい。むしろ、特定の実施形態において、「接続」は、２つ以上のエレメントが互いに直接接触することを示すのに使用される。「結合」は、２つ以上のエレメントが直接接触することを意味する。しかしながら、「結合」は、２つ以上のエレメントが互いに直接的に接触していないが、それでも、互いに協働又は相互作用することも意味する。
あるケースでは、フローチャートのオペレーションを、他のブロック図の例示的な実施形態を参照して説明する。しかしながら、フローチャートのオペレーションは、他のブロック図を参照して述べるもの以外の本発明の実施形態によって遂行することができ、且つ他のブロック図を参照して述べる本発明の実施形態は、フローチャートを参照して述べるもの以外のオペレーションを遂行できることを理解されたい。
図示された技術は、１つ以上のコンピュータに記憶されて実行されるコード及びデータを使用して具現化することができる。このようなコンピュータは、マシン読み取り可能な媒体、例えば、マシン記憶媒体（例えば、磁気ディスク、光学ディスク、ランダムアクセスメモリ、リードオンリメモリ、フラッシュメモリ装置）、及びマシン通信媒体（例えば、電気的、光学的、音響的、又は他の形態の伝播信号、例えば、搬送波、赤外線信号、デジタル信号、等）を使用して、コード及びデータを記憶し通信する（内部で及びネットワークを経て他のコンピュータと）。更に、このようなコンピュータは、典型的に、１つ以上の他のコンポーネント、例えば、記憶装置、多数のユーザ入力／出力装置（例えば、キーボード及びディスプレイ）、及びネットワーク接続部に結合された１つ以上のプロセッサのセットを含む。プロセッサのセット及び他のコンポーネントの結合は、典型的に、１つ以上のバス及びブリッジ（バスコントローラとも称される）を通して行われる。記憶装置及びネットワークトラフィックは、各々、１つ以上のマシン記憶媒体及びマシン通信媒体を表す。従って、所与のコンピュータシステムの記憶装置は、典型的に、そのコンピュータの１つ以上のプロセッサのセットにおいて実行されるコード及びデータを記憶する。もちろん、本発明の一実施形態の１つ以上の部分は、ソフトウェア、ファームウェア及び／又はハードウェアの異なる組合せを使用して具現化することができる。
概略
本発明の１つの態様によれば、プロデューサは、少なくとも特定のインスタンス（又はオブジェクト）及び特定のメソッドであり、プロデューサがランタイム中に実行される場合には、特定のメソッドが特定のインスタンスにおいて実行される。従って、所与のプロデューサは、所与のインスタンス、及びそのインスタンスに関連した所与のメソッドからインスタンス生成される。クラス、インスタンス及びメソッドと同様に、プロデューサは、ランタイムにより操作される基本的エレメント又はコンストラクトである。従って、プロデューサのインスタンス生成がランタイムによって解釈されて追跡され、従って、ランタイムは、プロデューサにより表わされたインスタンス及びメソッドの組合せを追跡する。換言すれば、プロデューサは、ランタイムインスタンス生成可能な構造であって、これは、ランタイムにより追跡され、即ちランタイムにより実行され、且つ少なくともインスタンスと、そのインスタンスに関連したメソッドとを含み、プロデューサのランタイム実行の結果として、プロデューサのメソッドがプロデューサのインスタンスにおいて実行されるようになる。又、プロデューサのメソッドには、０以上のプロデューサ依存性のセットで、所与のプロデューサに対する０以上のプロデューサのセットを識別するプロデューサ依存性宣言が関連付けられる。より詳細には、プロデューサ依存性は、プロデューサ依存性宣言を使用してメソッドに対して宣言され、所与のメソッドに対するプロデューサ依存性宣言は、０以上のプロデューサ依存性を含み、そして各プロデューサ依存性は、０以上のプロデューサのセットを識別する。従って、プロデューサ依存性宣言、及びそれらが定義するプロデューサ依存性は、ランタイムによって解釈されて追跡され、従って、ランタイムは、プロデューサ依存性宣言により指示されたプロデューサ間の関係を追跡する。
所与のプロデューサが、１つ以上の他のプロデューサのセットに依存する場合には、ランタイムは、所与のプロデューサの前に、他のプロデューサのセットの実行を保証する。従って、プロデューサ依存性宣言は、プロデューサ間の実行関係を表し、一方、プロデューサは、実行されるべきオペレーション（メソッド）及びインスタンスを表す。本発明のある実施形態では、子プロデューサに対する親プロデューサの依存性を、親プロデューサのメソッドに関連したプロデューサ依存性宣言において宣言できる（親プロデューサのプロデューサ依存性宣言が子プロデューサを識別する−ここでは、ダウン方向に宣言されたと称される）が、本発明の他の実施形態では、子プロデューサ（１つ又は複数）のメソッド（１つ又は複数）に関連したプロデューサ依存性宣言において依存性を宣言することもできる（子プロデューサのプロデューサ依存性宣言が１つ以上の親プロデューサを識別する−ここでは、アップ方向に宣言されたと称される）。
本発明の異なる実施形態では、プロデューサは、付加的なものを識別する。例えば、本発明のある実施形態では、プロデューサは、少なくともインスタンスと、そのインスタンスに関連したメソッドとを含むが、本発明の他の実施形態では、プロデューサは、クラス、そのクラスのインスタンス、及びそのインスタンスに関連したメソッドである（例えば、あるプロデューサは、クラス、インスタンス、及びメソッドを直接含み、又、あるプロデューサは、インスタンス及びメソッドを直接含むが、リファレンス（例えば、インスタンスにおけるリファレンス）を通してそのインスタンスのクラスを間接的に識別する）。本発明は、異なるプログラミング言語で書かれたコード（例えば、リフレクティブなオブジェクト指向の言語で書かれたオブジェクト指向のコード、リフレクティブなオブジェクトベースの言語で書かれたオブジェクト指向のコード、手続き型、非リフレクティブなオブジェクト指向、非リフレクティブなオブジェクトベースの言語で書かれて、リフレクティブなオブジェクト指向の言語コードへ変換されたコード）のコンテクストに使用されるが、本発明の実施形態は、リフレクティブなオブジェクト指向のプログラミング言語を参照すると共に、クラス、インスタンス及びメソッドを直接含むプロデューサを参照して、一例として、非限定的に、説明する。又、本発明の一実施形態では、プロデューサのメソッドがインスタンスメソッド（引数として受け取られる入力に加えてインスタンスフィールドを使用できるメソッド）であるが、本発明の別の実施形態は、それに加えて又はそれとは別に、クラスメソッド（全ての入力を引数として受け取り及び／又はインスタンス独立変数を使用するメソッド）であるプロデューサのメソッドをサポートすることもできる（プロデューサのメソッドがインスタンスメソッドである場合には、そのプロデューサのインスタンスは、クラスのインスタンスであるが、プロデューサのメソッドがクラスメソッドである場合には、そのプロデューサのインスタンスは、クラスを表すメタクラスインスタンスである）。
図１Ａは、本発明の一実施形態により、オブジェクト指向のソースコードにおけるクラスのメソッドに対するプロデューサ依存性宣言と、そのクラス、そのクラスの所与のインスタンス、及びそのクラスのメソッドを含むプロデューサとの関係を示すブロック図である。図１Ａにおいて、オブジェクト指向のソースコード１００は、クラス１０２を含むように示され、このクラスは、次いで、メソッド１０４、及びメソッド１０４に対するプロデューサ依存性宣言１０６を含む。もちろん、クラス１０２は、典型的に、１つ以上のフィールド（図示せず）及び付加的なメソッド（図示せず）を含む。更に、オブジェクト指向のソースコード１００は、典型的に、付加的なクラスを含む。
ランタイム中に、クラス１０２のインスタンス１０８がインスタンス生成される。インスタンス１０８は、クラス１０２のフィールドのデータを含む。更に、プロデューサ１１０がインスタンス生成され、プロデューサ１１０は、クラス１０２、クラス１０２のインスタンス１０８（クラス１０２のメソッド１０４に関連した）、及びクラス１０２のメソッド１０４を識別する。プロデューサ依存性宣言１０６は、プロデューサ１１０を実行する前に実行されねばならない０以上のプロデューサ１１２のセット（プロデューサ１１０の子プロデューサと称される）をランタイムに対して識別する。換言すれば、プロデューサ１１０は、０以上のプロデューサ１１２のセットに依存する。プロデューサ１１２のセットの出力を消費するのに加えて又はそれに代わって、プロデューサ１１０は、インスタンス１０８のデータを消費することができる。更に、プロデューサ１１０は、少なくとも１つの出力を与え、この出力は、インスタンス１０８に対して内部であってもよく（従って、インスタンス１０８のデータを変更し）、及び／又は外部であってもよく、いずれにせよ、プロデューサ１１０の出力は、０以上の他のプロデューサ１１４のセット（プロデューサ１１０の親プロデューサと称される）によって消費することができる。又、上述したように、そして以下に詳細に述べるように、プロデューサ依存性宣言１０６は、本発明のある実施形態では、０以上のプロデューサ１１４をランタイムに対して識別することもできる。
プロデューサの入力及び出力は、そのプロデューサのベースとなるメソッドの入力及び出力をベースとすることを理解されたい。従って、これらの入力及び出力は、種々のデータ構造を有する複数のパラメータを表すことができる。
所与のメソッドに対するプロデューサ依存性宣言は、インスタンス生成されて実行されるべき０以上のプロデューサのセットをランタイム時において識別する。例えば、所与のメソッド（例えば、メソッド１０４）に対するプロデューサ依存性宣言（例えば、プロデューサ依存性宣言１０６）が、所与のプロデューサ（この所与のプロデューサは、第１クラス、そのクラスの第１インスタンス、及びその第１クラスの第１メソッドを識別する）（例えば、プロデューサ１１２のセットの１つ）に対するプロデューサ依存性を識別する場合には、所与のメソッドのプロデューサ依存性宣言は、第１インスタンスをインスタンス生成すべきである（まだそうでなければ）こと及び第１メソッドを使用して第１インスタンスに対して所与のプロデューサをインスタンス生成すべきであることをランタイムに対して識別する（これらの例において、第１とは、位置や順序を意味するものではない）。
オペレーションにおいて、ランタイムの間に、１つ以上のプロデューサの所与のセットが、関心のあるものであることが指示され、且つそれらに対して宣言されたプロデューサ依存性を有するときに、ランタイムは、１）１つ以上のグラフのセットを自動的に発生し（発見し、構築し、そして任意であるが、解明し）、これらグラフは、マルチレベルのものであり、且つ関心があると指示されたプロデューサの所与のセットから、プロデューサ依存性宣言に基づくソースプロデューサまで種々の形状（例えば、チェーン、ツリー）のものでよく、そして２）グラフのセットのプロデューサの実行をシーケンスして、関心があると指示されたプロデューサの所与のセットの出力（１つ又は複数）を発生する。従って、ランタイムは、プロデューサ依存性宣言を使用して、どんな引数を伴うどんなメソッドをどんなインスタンスに対して同期のためにいつ実行すべきか決定する。
従って、プロデューサ依存性は、ランタイムに対するプロデューサの実行のシーケンスを表す。しかしながら、実行のシーケンスを指示するのに加えて、プロデューサ依存性は、本発明の異なる実施形態では、異なる入力対出力関係を表すことができる。例えば、本発明の異なる実施形態は、引数プロデューサ依存性、フィールドプロデューサ依存性、及びシーケンスのみのプロデューサ依存性の１つ以上をサポートすることができる（シーケンスのみのプロデューサ依存性は、ここでは、ショートハンドシーケンスプロデューサ依存性と称される）。引数プロデューサ依存性、フィールドプロデューサ依存性、及びシーケンスプロデューサ依存性の各々は、プロデューサ間の実行シーケンス関係を表すが、引数及びフィールドのプロデューサ依存性は、更に、ランタイムが気付くデータも表わす。より詳細には、引数プロデューサ依存性は、ランタイムが子プロデューサの出力を親プロデューサに対する入力パラメータとしてマップするようにさせ、一方、フィールドプロデューサ依存性は、インスタンスのフィールドの使用を指示する。プロデューサ依存性によって表わされる入力対出力関係には関わりなく、プロデューサ依存性の適切な使用は、プロデューサアクセス情報が、その情報にインパクトを与えるプロデューサの後にシーケンスされるように保証する。
シーケンス依存性は、ランタイムが気付かない仕方でデータを変更するプロデューサと、そのデータを消費するプロデューサとの間で実行順序を保証することを含めて、種々の目的に使用される（子プロデューサは、その出力にアクセスするためのコードを含むことを親プロデューサのメソッドに要求する仕方でその出力を書く（例えば、普通のプロデューサ出力でない、従って、ランタイムにより検出されない出力に影響することにより環境にインパクトを及ぼすメソッド、例えば、グローバル変数をセットし、プロデューサ出力でないインスタンスにおけるフィールドをセットし、外部データソースにインパクトを及ぼす、等のメソッド））。従って、シーケンス依存性は、子プロデューサに対する親プロデューサの依存性を反映するが、コードの書き込みを通して一方から他方へ与える必要のある出力を要求する（例えば、所与のメカニズムに出力を書き込むための子プロデューサのメソッドにおけるコード（例えば、グローバル変数をセットし、外部データソースにインパクトを及ぼし、プロデューサ出力でないインスタンスのフィールドをセットし、等々）、及び所与のメカニズムからその出力を読み取るための親プロデューサのメソッドにおけるコード）。このように、シーケンス依存性は、ランタイムで検出できない出力に依存する親プロデューサの実行をランタイムが同期させられるようにする。ソース（例えば、グローバルな変数又は外部データソース）に影響を与えてもランタイムがそれに気付かずそれらソースから読み取りすることは、シナリオ能力が要求されるプロデューサにおいて回避されねばならない特徴である。
本発明の一実施形態では、所与のメソッドに対するプロデューサ依存性宣言は、プロデューサに対する直接的な依存性（例えば、直接的子孫（子供）、これとは対照的に間接的子孫（孫、曾孫、等）がある））のみを識別する。このような実施形態では、各プロデューサ依存性宣言は、所与のメソッドからインスタンス生成されたプロデューサにより出力を直接使用できるプロデューサの単一段又は層のみを与え、プロデューサグラフ（１つ又は複数）の付加的な層の発見／構築／解明は、他のプロデューサ依存性宣言のランタイムプロセッシングに託される。
例示的キー
プロデューサは、複数の識別子のセットとして見ることができ、指定の粒度の付加的なレベルごとに１つの識別子がある（クラス、インスタンス、メソッド、等）。更に、本発明のある実施形態は、各識別子を個別のキーとして具現化し、一方、他の実施形態は、幾つかの識別子が１つのキーを共有するようにする。例えば、本発明のある実施形態は、プロデューサを、クラス、インスタンス及びメソッドのトリプレットとして具現化し、そしてトリプレットの各部分が個別キー（クラスキー、インスタンスキー及びメソッドキー）により識別され且つプロデューサがクラスキー、インスタンスキー及びメソッドキーの組合せ（プロデューサキー）により識別されるように、キーを具現化する。
キーを使用する本発明の実施形態は、使用するキーの独特性が変化し得る。例えば、本発明の一実施形態では、各クラスキーが独特であり、各インスタンスキーは、全てのクラスの全てのインスタンスにわたって独特であり、そして各メソッドキーは、全てのクラスの全てのメソッドにわたって独特である。別の例として、本発明の他の実施形態では、各クラスが独特のキーを有し、所与のクラスの各インスタンスは、独特のキーを有し（クラスインスタンスにわたって）、そしてクラスの各メソッドは、独特のキーを有する（クラスメソッドにわたって）が、異なるクラスのインスタンスが同じインスタンスキーを有してもよく、且つ異なるクラスのメソッドが同じメソッドキーを有してもよく、この後者の解決策は、本書の残り部分において、一例として、非限定的に、使用される。例えば、第１クラスがメソッドを含むと共に、それらメソッドの各々に対し、第１クラス内で独特であるキーを有すると仮定すれば、このクラスのインスタンス（各々が互いに独特のキーを有する）には、同じメソッドキーが関連付けられる。別の例として、異なる第２クラスが、第１クラスに使用されたものと同じメソッドキーを有するメソッド（第１クラスのメソッドと幾つか同じ、全部同じ、又は全く同じでない）を含むと仮定する。従って、この異なるクラスのインスタンスには、第１クラスのインスタンスに関連付けられた同じメソッドキーが関連付けられてもよい。
これらキーの使用は、１）プロデューサの識別子によって識別された各エンティティを追跡すること（例えば、各クラス、インスタンス、及びメソッドの追跡）、２）多数の親プロデューサ（相互の存在に気付かない）がそれらのプロデューサ依存性宣言（これは、プロデューサキーを使用してプロデューサ依存性を指定する）に基づいて同じ子プロデューサに接続すること、等を含めて、種々の特徴を許す。本発明の一実施形態では、インスタンスキーは、キー識別子がインスタンス又は別のオブジェクト（ストリングのような）へのリファレンスであるかどうかを指示するインスタンスキー特性と、インスタンス又は別のオブジェクト（ストリングのような）のいずれかへのリファレンスであるキー識別子と、の２つのエレメントを保持するクラスのインスタンス（InstanceKey）である。インスタンスキーにインスタンスリファレンスを記憶することは、プログラマーがこれらのインスタンスを識別するための名前を創案することから逃れさせる。
例示的関係
プロデューサが複数の識別子のセット（指定の粒度の各付加的なレベルに対して１つの識別子をもつ）として見られることに関する前記説明に関連して、本発明の一実施形態では、プロデューサとその子供及び親との間の種々のサポートされる関係は、あるプロデューサと、０以上の親プロデューサのセットとの間で少なくとも１つのこのような識別子が異なり、且つあるプロデューサと、０以上の子プロデューサのセットの各々との間で１つのこのような識別子が異なるというものである。ある例示的関係を与えることにより、第１クラスの第１インスタンス及びその第１クラスの第１メソッドである第１プロデューサがインスタンス生成されると仮定し、且つその第１メソッドに対するプロデューサ依存性宣言がランタイム時において第２プロデューサを子供として識別すると仮定すると、第２プロデューサは、１）第１クラスの第１インスタンス及びその第１クラスの第２メソッドであり、２）第１クラスの第２インスタンス及びその第１クラスの第２メソッドであり、３）第１クラスの第２インスタンス及び第１クラスの第１メソッドであり、又は４）第２クラスのインスタンス及びその第２クラスのメソッドである。このようなケースでは、第１プロデューサは、第２プロデューサに依存し、従って、第２プロデューサに対する第１プロデューサの入力対出力関係を表す。種々の関係及びそれら関係の組合せは、オブジェクト指向の言語を使用する一実施形態であって、プロデューサが少なくともクラス、インスタンス及びメソッドを識別する本発明の実施形態について以下に説明する。
図１Ｂ−１Ｄは、本発明の一実施形態により、所与のプロデューサと、その親プロデューサのセットと、その子プロデューサのセットとの間の関係を例示する。図１Ｂ−１Ｄは、各々、次のものを示す。１）メソッド１０４Ａ−Ｃと、これらメソッドの各々に対するプロデューサ依存性宣言１０６Ａ−Ｃとを各々含むクラス定義１０２Ａ；２）メソッド１０４Ｄ−Ｅと、これらメソッドの各々に対するプロデューサ依存性宣言１０６Ｄ−Ｅとを各々含むクラス定義１０２Ｂ；３）メソッド１０４Ｆと、このメソッドに対するプロデューサ依存性宣言１０６Ｆとを含むクラス定義１０２Ｃ；４）クラス１０２Ａのインスタンス１０８Ａ；５）クラス１０２Ａ、インスタンス１０８Ａ及びメソッド１０４Ａを識別するプロデューサ１１０Ａ；及び６）プロデューサ１１２及び１１４のセットの１つを各々表わすプロデューサ１１２Ａ．１及びプロデューサ１１４Ａ．１。ボックス内に文字を伴う破線は、図１Ｂ−１Ｄにおいて、関係を例示するために使用される。従って、ボックス内にＡを伴う破線の集合は、１つの関係を表す。図１Ｂにおける関係は、図１Ｃにおける関係と組合せ可能であり、従って、これらの組合せは、プロデューサ１１０Ａに対する親プロデューサ１１４Ａと子プロデューサ１１２Ａとの関係の組合せを表している。更に、図１Ｄは、プロデューサ１１０Ａに対する親プロデューサ１１４Ａと子プロデューサ１１２Ａとの関係のある付加的な組合せを例示している。
図１Ｂは、本発明の一実施形態によるプロデューサ１１０Ａと親プロデューサ１１４Ａ．１との関係を例示している。図１Ｂは、更に、インスタンス１０８Ｂを含む。プロデューサ１１４のセットは、同じクラスの異なるメソッド（１つ又は複数）、同じクラスの異なるインスタンス、及び／又は異なるクラスのメソッド（１つ又は複数）の他のプロデューサ依存性宣言によって識別され、従って、プロデューサ１１４のセットの各々は、１）プロデューサ１１０Ａと同じインスタンス（クラス１０２Ａのインスタンス１０８Ａ）及びそのインスタンスに関連した異なるメソッド（インスタンス１０８Ａからプロデューサ１１４Ａ．１へ及びメソッド１０４Ｂからプロデューサ１１４Ａ．１への破線上のボックス内のＡにより示された）であり；２）クラス１０２Ａの異なるインスタンス及びそのインスタンスに関連した異なるメソッド（クラス１０２Ａからインスタンス１０８Ｂへ、インスタンス１０８Ｂからプロデューサ１１４Ａ．１へ及びメソッド１０４Ｂからプロデューサ１１４Ａ．１への破線上のボックス内のＢにより示された）であり；３）異なるクラスのインスタンス及びそのインスタンスに関連したメソッド（クラス１０２Ｂからインスタンス１０８Ｂへ、インスタンス１０８Ｂからプロデューサ１１４Ａ．１へ及びメソッド１０４Ｄからプロデューサ１１４Ａ．１への破線上のボックス内のＣにより示された）であり；又は４）クラス１０２Ａの（インスタンス１０８Ａとは）異なるインスタンス及びそのインスタンスの同じメソッド（メソッド１０４Ａ）（例えば、以下に述べるコンティンジェント依存性を伴う）（クラス１０２Ａからインスタンス１０８Ｂへ、インスタンス１０８Ｂからプロデューサ１１４Ａ．１へ及びメソッド１０４Ａからプロデューサ１１４Ａ．１への破線上のボックス内のＤにより示された）であり；更に、プロデューサ１１４のセットに複数のプロデューサがある場合には、プロデューサ１１４それ自体が、クラス１０２Ａの同じインスタンス、クラス１０２Ａの異なるインスタンス、異なるクラスのインスタンス、及び／又はそれらの混合、の一部分でもよい。
図１Ｃは、本発明の一実施形態によるプロデューサ１１０Ａと子プロデューサ１１２Ａ．１との関係を例示している。図１Ｃは、更に、インスタンス１０８Ｃを含む。プロデューサ１１２Ａのセットの各々は、１）プロデューサ１１０Ａと同じインスタンス（クラス１０２Ａのインスタンス１０８Ａ）及びそのインスタンスに関連した異なるメソッド（インスタンス１０８Ａからプロデューサ１１２Ａ．１へ及びメソッド１０４Ｃからプロデューサ１１２Ａ．１への破線上のボックス内のＥにより示された）であり；２）クラス１０２Ａの異なるインスタンス及びそのインスタンスに関連した異なるメソッド（クラス１０２Ａからインスタンス１０８Ｃへ、インスタンス１０８Ｃからプロデューサ１１２Ａ．１へ及びメソッド１０４Ｃからプロデューサ１１２Ａ．１への破線上のボックス内のＦにより示された）であり；３）異なるクラスのインスタンス及びそのインスタンスに関連したメソッド（クラス１０２Ｃからインスタンス１０８Ｃへ、インスタンス１０８Ｃからプロデューサ１１２Ａ．１へ及びメソッド１０４Ｆからプロデューサ１１２Ａ．１への破線上のボックス内のＧにより示された）であり；又は４）クラス１０２Ａの（インスタンス１０８とは）異なるインスタンス及びそのインスタンスの同じメソッド（メソッド１０４Ａ）（例えば、以下に述べるコンティンジェント依存性を伴う）（クラス１０２Ａからインスタンス１０８Ｃへ、インスタンス１０８Ｃからプロデューサ１１２Ａ．１へ及びメソッド１０４Ａからプロデューサ１１２Ａ．１への破線上のボックス内のＨにより示された）である。従って、プロデューサ１１２Ａのセットの各々は、プロデューサ１１０Ａの同じインスタンス、クラス１０２Ａの異なるインスタンス、又は異なるクラスのインスタンスでよく、更に、プロデューサ１１２Ａのセットに複数のプロデューサがある場合には、プロデューサ１１２Ａそれ自体が、クラス１０２Ａの同じインスタンス、クラス１０２Ａの異なるインスタンス、異なるクラスの同じインスタンス、異なるクラスの異なるインスタンス、及び／又はそれらの混合の一部分でもよい。
図１Ｄは、本発明の一実施形態による親プロデューサ１１４及び子プロデューサ１１２とプロデューサ１１０Ａとの関係の付加的な組合せを例示している。図１Ｄは、更に、インスタンス１０８Ｂ及びインスタンス１０８Ｃを含む。図１Ｄの組合せを以下のテーブル１に示す。
テーブル１
Figure 0005354603
図１Ｅは、本発明の一実施形態により、同じクラスの異なるインスタンスが同じ及び／又は異なるメソッドに基づきプロデューサを有することができることを示す。図１Ｅは、次のものを示す。即ち、１）クラス定義１０２Ａが、メソッド１０４Ａ−Ｃと、各メソッドに対するプロデューサ依存性宣言１０６Ａ−Ｃを各々含むこと；２）インスタンス１０８Ａ及びインスタンス１０８Ｂがクラス１０２Ａのものであること；３）プロデューサ１１０Ａが、クラス１０２Ａのインスタンス１０８Ａのメソッド１０４Ａであること；４）プロデューサ１１０Ｂが、クラス１０２Ａのインスタンス１０８Ａのメソッド１０４Ｂであること；５）プロデューサ１１０Ｃが、クラス１０２Ａのインスタンス１０８Ｂのメソッド１０４Ａであること；及び６）プロデューサ１１０Ｄが、クラス１０２Ａのインスタンス１０８Ｂのメソッド１０４Ｃであること。更に、図１Ｄは、次のことを示す。即ち、１）メソッド１０４Ａのプロデューサ依存性宣言１０６Ａが、ランタイム時において、プロデューサ１１０Ａ及びプロデューサ１１０Ｃの両方の子プロデューサを識別すること；２）メソッド１０４Ｂのプロデューサ依存性宣言１０６Ｂが、ランタイム時において、プロデューサ１１０Ｂの子プロデューサを識別すること；及び３）メソッド１０４Ｃのプロデューサ依存性宣言１０６Ｃが、ランタイム時において、プロデューサ１１０Ｄの子プロデューサを識別すること。
例示的ランタイム
図２は、本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムの再使用性を示すブロック図である。図２において、複数のオブジェクト指向のアプリケーションプログラム（プロデューサ依存性宣言を伴うオブジェクト指向のアプリケーションコード２１０Ａ−Ｉ）は、プロデューサグラフ指向のプログラミングサポートを伴う同じランタイム２２０によって実行される。
図３Ａは、本発明の一実施形態によりプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。図３Ａにおいて、プロデューサグラフ指向のプログラミングサポート３３５を伴うランタイムは、自動プロデューサグラフ発生モジュール３４０及びプロデューサグラフ実行モジュール３４５を含む。更に、ランタイム３３５は、オブジェクト指向のソースコードを実行するもので、従って、図示されていない付加的なモジュールを含む。
更に、図３Ａは、オブジェクト指向のソースコードにおけるメソッドのためのプロデューサ依存性宣言３２０、出力が問題である１つ以上のプロデューサの現在セット３２５（ここでは、問題とする現在選択されたプロデューサと称される）、及びソースプロデューサの出力３３０（以下で説明する）を示している。自動プロデューサグラフ発生モジュール３４０は、プロデューサ依存性宣言３２０、及び問題とするプロデューサの現在セット３２５を受け取る。
自動プロデューサグラフ発生モジュール３４０は、問題とする現在選択されたプロデューサの入力に直接的及び間接的に貢献する出力を伴う子プロデューサ（及び上方宣言依存性をサポートする本発明の幾つかの実施形態では、親プロデューサ）をプロデューサ依存性宣言に基づいて発見するよう試み、そして問題とする現在選択されたプロデューサから、非ソースプロデューサである発見されたプロデューサを経て、ソースプロデューサである発見されたプロデューサまで、プロデューサの互いの依存性を表すプロデューサの１つ以上の現在グラフのセットを構築する。現在プロデューサグラフ（１つ又は複数）は、プロデューサグラフ（１つ又は複数）構造３８０に記憶される。本発明の実施形態は、プロデューサグラフ（１つ又は複数）をグラフの集合として記憶するが、本発明の他の実施形態では、（グラフの集合ではなく）グラフ（１つ又は複数）を形成するように互いにリンクされてプロデューサグラフの合併及び分割を容易にするプロデューサの集合としてプロデューサグラフ（１つ又は複数）を記憶し操作することもできる。例えば、これに限定されないが、プロデューサの集合としてプロデューサグラフ（１つ又は複数）を記憶し操作する本発明の実施形態をここに説明する。
プロデューサグラフ実行モジュール３４５は、自動プロデューサグラフ発生モジュール３４０からの現在プロデューサグラフ（１つ又は複数）及びソースプロデューサ３３０の出力を受け取り、そして現在プロデューサグラフ（１つ又は複数）のプロデューサを実行して、問題とする現在選択されたプロデューサの現在出力を決定する。プロデューサグラフ実行モジュール３４５は、プロデューサ出力キャッシング３８４により示されたようにプロデューサグラフ構造３８０にプロデューサの現在出力をキャッシュ記憶する。
実行中にプロデューサグラフのプロデューサ出力をキャッシュ記憶することで同期をとることができる。例えば、複数の子プロデューサに依存する親プロデューサを実行する適切な時間は、複数の子プロデューサが全て実行された後であり、換言すれば、子プロデューサの１つが実行を完了するたびに親プロデューサを実行するのは無駄である（あるケースでは、不可能である）。プロデューサ出力をキャッシュ記憶することは、親プロデューサの実行を、全ての子プロデューサが実行されてしまうまで延期できるだけでなく、親プロデューサを実行するための適切な時間、即ち全ての子プロデューサが実行されてそれらの出力がキャッシュ記憶されるとき、を決定できるようにする。従って、ランタイムは、子プロデューサの実行状態をチェックすることによりプログラマーに対してこの同期判断を行い、換言すれば、このような同期が自動化される（プログラマーは、インスタンスを識別して、そのインスタンスに対してそのインスタンスに関連した所与のメソッドを実行するための適切な時間を決定する個別のソースコードを含ませる必要がない）。別の例として、複数の親プロデューサが同じ子プロデューサ及び他の異なる子プロデューサに依存する場合には、複数の親プロデューサの各々を実行するための適切な時間が典型的に異なり、ランタイムは、子プロデューサのセットの出力の利用性に基づいて複数の親プロデューサの各々を実行するための適切な時間を自動的に決定する。
以下に詳細に述べるように、プロデューサグラフのある部分は、ダイナミックなプロデューサ依存性のために現在発見できないことがあるので、自動プロデューサグラフ発生モジュール３４０は、プロデューサグラフ全体を発見し構築するように「試みる」が、あるプロデューサが実行されるまでは、最初にプロデューサグラフ全体を完了できないことがある。従って、プロデューサグラフ実行モジュール３４５は、現在プロデューサグラフの実行中に必要なプロデューサ出力を伴う自動プロデューサグラフ発生モジュール３４０をインボークし、現在プロデューサグラフの未解明の残部を完了することができる（これは、図３Ａにおいて、プロデューサグラフ実行モジュール３４５から自動プロデューサグラフ発生モジュール３４０への矢印付き破線で示されており、矢印付き破線は、このようなサポートが任意であるために使用されている）。
図４Ａは、本発明の一実施形態による例示的プロデューサグラフの発見及び構築を示すブロック図である。図４Ａは、問題とするプロデューサの現在セットがプロデューサ１より成ることを示す。プロデューサ及びそのプロデューサ依存性宣言に基づいて、プロデューサ２及びプロデューサ３が発見される。換言すれば、プロデューサ１に対するプロデューサ依存性宣言は、プロデューサ１への入力がプロデューサ２及びプロデューサ３の実行を要求することを示す。従って、プロデューサ１は、従属プロデューサ（１つ以上のプロデューサ依存性を有するプロデューサ）である。又、図４Ａは、プロデューサ３が独立プロデューサ（プロデューサ依存性をもたず、従って、ソースプロデューサであるプロデューサ）であるが、プロデューサ２は、そうでないことも示す。その結果、プロデューサ２のプロデューサ依存性宣言に基づき、プロデューサ４及びプロデューサ５が発見される。図２Ａにおいて、プロデューサ４及びプロデューサ５は、独立プロデューサ（従って、ソースプロデューサ）である。
図４Ｂは、本発明の一実施形態により図４Ａのプロデューサグラフの初期実行を示すブロック図である。図４Ｂにおいて、矢印付きの曲線は、あるプロデューサを実行して出力を発生し、それが別のプロデューサへ入力として与えられることを示す。図３Ａに示すように、ソースプロデューサ３３０の出力は、プロデューサグラフ実行モジュール３４５に与えられ、対照的に、従属プロデューサ１−２の出力は、図４Ｂに示すようにプロデューサの実行によって決定される。従って、図４Ｂでは、次のことが生じる。即ち、１）ソースプロデューサ４及びソースプロデューサ５の出力が従属プロデューサ２に与えられ、従属プロデューサ２が実行され、３）従属プロデューサ２及びソースプロデューサ３の出力がプロデューサ１に与えられ、そして４）プロデューサ１が実行され、且つその出力が、問題とする現在出力として与えられる。図４Ｂのプロデューサグラフは、データがグラフを上るようにあるプロデューサから別のプロデューサへ流れる方向に駆動されるデータであることに注意する価値がある。
従って、プロデューサ依存性宣言３２０は、発生されると考えられるプロデューサグラフの境界を定め、一方、問題とするプロデューサの現在選択セット３２５は、発生されるべき現在プロデューサグラフの開始ノード（１つ又は複数）を識別する。これらの２つから、自動プロデューサグラフ発生モジュール３４０がプロデューサグラフを発見して構築する。発見及び構築は、自動プロデューサグラフ発生モジュール３４０に、プロデューサグラフ（例えば、プログラマーにより手動で識別される必要がない）も、プロデューサグラフ内のプロデューサのリストも与えられないという点で、自動的である。むしろ、自動プロデューサグラフ発生モジュール３４０は、問題とするプロデューサの現在選択セットのプロデューサ依存性宣言（１つ又は複数）を構文解析して、それらの子プロデューサ（及び上方宣言依存性をサポートする本発明の幾つかの実施形態では、親プロデューサ）を発見し、次いで、それらの発見されたプロデューサのプロデューサ依存性宣言を構文解析し、等々で、ソースプロデューサまで行う（以下に述べる本発明のある実施形態では、これは、プロデューサグラフ実行モジュール３４５の助けで行われてもよい）。プロデューサグラフがツリーである場合には、問題とする現在選択されたプロデューサが典型的に根(root)ノードであり、プロデューサ依存性宣言は、葉(leaf)ノード（ソースプロデューサ）が発見されるまで構文解析される。
オーバーライドされたプロデューサ及び増分的実行
図３Ｂは、本発明の一実施形態により、増分的実行及びオーバーライドされたプロデューサ出力もサポートするプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。増分的実行及びオーバーライドされたプロデューサ出力は、各々、独立した任意の特徴であり、従って、本発明の異なる実施形態では、一方を具現化してもよいし、両方を具現化してもよいことを理解されたい。
図３Ｂにおいて、プロデューサグラフ指向のプログラミングサポートを伴うランタイム３６０は、自動プロデューサグラフ発生モジュール３６５、プロデューサグラフ実行モジュール３７０、及びオーバーライドプロデューサ出力モジュール３９０を備えている。ランタイム３６０は、オブジェクト指向のソースコードを実行するものであり、従って、図示されていない付加的なモジュールを備えている。
更に、図３Ｂは、オブジェクト指向のソースコードにおけるメソッドに対する依存性宣言３２０、出力が問題である１つ以上のプロデューサの現在セット３２５（ここでは、問題とする現在選択されたプロデューサとも称される）、及びソースプロデューサの出力３５０も示している。ソースプロデューサの出力３５０は、ソースコードにおける独立プロデューサセットの出力３５２（例えば、定数、デフォールト値、等）、及び現在オーバーライドされたプロデューサ出力３５４（出力が現在オーバーライドされた独立プロデューサ及び／又は従属プロデューサの出力）を含む。
本発明のある実施形態では、プロデューサの出力は、現在与えられた値で明確にオーバーライドすることができる（即ち、プロデューサを実行してその現在入力に基づいてその出力値を決定するのではなく、プロデューサに対する出力値が明確に与えられる）。プロデューサグラフの独立プロデューサに加えて、プロデューサグラフのソースプロデューサは、現在オーバーライドされたプロデューサを含む。
オーバーライドプロデューサ出力モジュール３９０は、オーバーライドされたプロデューサ出力３５４を受け取る（これは、どのプロデューサがオーバーライドされそしてどんな出力値でオーバーライドされるか識別する）。本発明の一実施形態では、プロデューサは、プロパティプロデューサ又はメソッドプロデューサとして分類することができる。プロパティプロデューサは、プロパティメソッド（例えば、ゲット及びセット）に基づくものである。メソッドプロデューサは、非プロパティメソッドに基づくものである。オーバーライドプロデューサ出力モジュール３９０は、オーバーライドされたプロパティプロデューサのためのオーバーライドプロパティプロデューサ出力モジュール３９２と、オーバーライドされたメソッドプロデューサのためのオーバーライドメソッドプロデューサ出力モジュール３９４とを備えている。オーバーライドプロパティプロデューサ出力モジュール３９２は、オーバーライドされた値を、プロデューサ出力キャッシング３８４及びインスタンスのデータに記憶させ、一方、オーバーライドメソッドプロデューサ出力モジュール３９４は、オーバーライドされた値をプロデューサ出力キャッシング３８４に記憶させる。本発明の実施形態に基づき、この因果関係は、直接的でも間接的でもよい。図３Ｂは、オーバーライドログ３９６を使用して間接的に行わせることを示し、このオーバーライドログは、オーバーライドプロデューサ出力モジュール３９０の出力を収集するもので、プロデューサグラフ実行モジュール３７０によって消費される。最適化のために、オーバーライドロジック３９６は、オーバーライドを遅延させ、複数のオーバーライドをバッチ処理のために収集できるようにする。
自動プロデューサグラフ発生モジュール３４０と同様に、自動プロデューサグラフ発生モジュール３６５は、１）プロデューサ依存性宣言３２０及び問題とするプロデューサの現在セット３２５を受け取り、そして２）プロデューサ依存性宣言に基づいて、問題とする現在選択されたプロデューサの入力に直接的及び間接的に貢献する出力を伴う子プロデューサ（及び上方宣言依存性をサポートする本発明の幾つかの実施形態では、親プロデューサ）を発見し、且つ問題とする現在選択されたプロデューサから、発見された非ソースプロデューサを経て、ソースプロデューサ（独特プロデューサ及び現在オーバーライドされたプロデューサ）である発見されたプロデューサまで、プロデューサの互いの入力依存性を表すプロデューサの１つ以上の現在グラフのセットを構築するように試みる。プロデューサグラフ（１つ又は複数）は、プロデューサグラフ（１つ又は複数）構造３８０に記憶される。
プロデューサグラフ実行モジュール３４５と同様に、プロデューサグラフ実行モジュール３７０は、自動グラフモジュール３６５からの現在プロデューサグラフ及びソースプロデューサ３５０の出力を受け取り、そして現在プロデューサグラフのプロデューサを実行して、問題とする現在選択されたプロデューサの現在出力を決定する。プロデューサグラフ実行モジュール３７０は、プロデューサ出力キャッシング３８４により示されたように、プロデューサグラフ構造３８０にプロデューサの現在出力をキャッシュ記憶する。
上述したように、実行中にプロデューサ出力をキャッシュ記憶することで同期をとることができる（例えば、図４Ｂのプロデューサ２をいつ実行すべきか決定するために個別のソースコードを書き込む必要がなく、むしろ、ランタイムは、プロデューサ出力キャッシング３８４において必要な出力が利用できることをチェックすることによりプログラマーに対してこの同期判断を実行し、換言すれば、このような同期が自動化される）。更に、このプロデューサ出力キャッシング３８４は、増分的実行に使用される。より詳細には、プロデューサグラフが最初に発生されて実行された後に、現在プロデューサグラフにおけるプロデューサをオーバーライドするのに、ある程度の再実行レベルが要求される。本発明のある実施形態は、グラフ全体を単純に再実行するが、本発明の別の実施形態は、増分的実行をサポートする（オーバーライドにより影響されるプロデューサグラフの部分のみを再実行する）。増分的実行をサポートするある例示的実施形態は、どのプロデューサが再実行を要求するか決定する上で助けとなるように、プロデューサグラフ（１つ又は複数）構造３８０に増分的実行マーキング３８２を使用する。従って、プロデューサグラフ（１つ又は複数）を維持することは、複数の実行にわたって必要に応じてプロデューサグラフ（１つ又は複数）のリンクを変更して、それらを現在状態（最新状態）に保持することを指し、一方、増分的実行は、プロデューサグラフ（１つ又は複数）を維持し、且つ現在（最新）プロデューサグラフを使用して、オーバーライドにより影響されるプロデューサグラフ（１つ又は複数）の部分のみを再実行することを指す。
図３Ａと同様に、ダイナミック依存性に対する任意のサポートを表すために、プロデューサグラフ実行モジュール３７０から自動プロデューサグラフ実行モジュール３６５へと矢印付き破線が延びている。ダイナミック依存性は、プロデューサグラフの再実行中に変化し得ることに注意されたい。
図４Ｃは、本発明の一実施形態により図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。図４Ｃにおいて、プロデューサ５の出力は、明確に変更されているが、プロデューサ３及びプロデューサ４の出力は、変更されていない。プロデューサグラフにおける出力対入力依存性の追跡と、プロデューサ５の出力のみが明確に変更されていることに基づいて、プロデューサ２及びプロデューサ１だけがこの変更により影響されることが決定される。その結果、プロデューサ１の更新された出力を決定するのに、プロデューサ５の新たな出力と、プロデューサ４及びプロデューサ３の以前の出力とでプロデューサ２及びプロデューサ１を再実行することしか要求されない。プロデューサグラフのこの部分的な再実行は、図４Ｃにおいて、プロデューサ５からプロデューサ２へそしてプロデューサ２からプロデューサ１への矢印付き曲線が存在するが、プロデューサ４からプロデューサ２へ又はプロデューサ３からプロデューサ１へは存在しないことにより示される。プロデューサ４からプロデューサ２へ及びプロデューサ３からプロデューサ１への矢印付き曲線が存在しないことは、プロデューサ３及びプロデューサ４の出力が必要ないことを指示するのではなく、むしろ、プロデューサ３及びプロデューサ４の以前の出力が（例えば、プロデューサグラフの以前の実行からキャッシュ記憶されて）利用できる場合には、それらプロデューサを再実行する必要がないことを指示する。
図４Ｃの比較的簡単な例は、増分的実行の結果として処理リソースを節約できることを示している。このような節約は、多数のファクタ（例えば、再実行する必要のないプロデューサの数、それらプロデューサが要求する処理の量、等）に依存する。増分的実行を遂行する本発明の一実施形態が例示されたが、別の実施形態を別の仕方で具現化することもできる（例えば、別の実施形態は、変更に応答して全てのプロデューサを再実行することができる）。
図４Ｄは、本発明の一実施形態により従属プロデューサ２がオーバーライドされた後の図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。図４Ｄにおいて、プロデューサ２の出力は、明確に変更されているが、プロデューサ３の出力は、変更されていない。プロデューサグラフと、プロデューサ２の出力のみが明確に変更されたこととに基づいて、この変更によりプロデューサ１だけが影響されると決定される。その結果、プロデューサ１の更新された出力を決定するのに、プロデューサ２のオーバーライドされた出力と、プロデューサ３の以前の出力とでプロデューサ１を再実行することしか要求されない。プロデューサグラフのこの部分的再実行は、図４Ｄにおいて、プロデューサ２からプロデューサ１への矢印付き曲線が存在するが、プロデューサ４及び５からプロデューサ２へ又はプロデューサ３からプロデューサ１へは存在しないことにより示される。
図４Ｅは、本発明の一実施形態により従属プロデューサ２がオーバーライドされそして独立ソースプロデューサ３が変更された後の図４Ｂのプロデューサグラフの増分的実行を示すブロック図である。プロデューサグラフと、プロデューサ２及びプロデューサ３の出力のみが変更されたこととに基づいて、この変更によりプロデューサ１だけが影響されると決定される。その結果、プロデューサ１の更新された出力を決定するのに、プロデューサ２のオーバーライドされた出力と、プロデューサ３の以前の出力とでプロデューサ１を再実行することしか要求されない。プロデューサグラフのこの部分的再実行は、図４Ｅにおいて、プロデューサ２及び３からプロデューサ１への矢印付き曲線が存在するが、プロデューサ４及び５からプロデューサ２へは存在しないことにより示される。
オーバーライドプロデューサ出力をサポートする本発明の一実施形態は、非オーバーライドプロデューサ出力もサポートするが、本発明の別の実施形態は、そのようにしない。非オーバーライドプロデューサをサポートする本発明の一実施形態は、オーバーライドされたプロデューサを、それが特に非オーバーライドされるまで、オーバーライドされたままにするが、本発明の別の実施形態は、異なる仕方で具現化されてもよい（例えば、オーバーライドされたプロデューサを、その子孫の１つがオーバーライドされるときに非オーバーライド化する）。
プロデューサグラフ構築及び実行
本発明の異なる実施形態は、プロデューサグラフを発見して、異なる程度に構築するように具現化することができる（例えば、根ノードからの全ての経路が独立プロデューサにおいて終了するまでプロデューサグラフを構築し（このケースでは、プロデューサグラフの終了ノードが独立プロデューサであり、オーバーライドされたプロデューサが中間ノードであるおそれがある）；根ノードからの各経路が、オーバーライドされたプロデューサ又は独立プロデューサのいずれか最初に到着する方で終了するまで、プロデューサグラフを構築する（このケースでは、プロデューサグラフの各終了ノードが独立プロデューサ又はオーバーライドされたプロデューサのいずれかである））。
「実行スタートプロデューサ」とは、プロデューサグラフのプロデューサであって、そこからプロデューサグラフの所与の実行が開始されるプロデューサを指す。プロデューサグラフの初期実行に対して、異なる実施形態は、異なるプロデューサからスタートすることができる（例えば、根ノードからの全ての経路が独立プロデューサにおいて終了するまでプロデューサグラフを構築する本発明の実施形態では、終了ノード（これは独立プロデューサである）から；ソースプロデューサ（これは、独立プロデューサノード及び任意のオーバーライドされたプロデューサノードを含む）から；少なくとも１つの経路を間に伴う独立プロデューサと、オーバーライドされたプロデューサを含まない根プロデューサと、オーバーライドされたプロデューサとの組合せより成るソースプロデューサのサブセットから；或いはオーバーライドされた子孫を伴わないオーバーライドされたプロデューサと、少なくとも１つの経路を間に伴う独立プロデューサと、オーバーライドされたプロデューサを含まない根プロデューサとの組合せより成るソースプロデューサのサブセットから；実行をスタートすることができ、更に、オーバーライドされたプロデューサの下でのプロデューサグラフが、そのようなプロデューサが非オーバーライドである場合及び非オーバーライドにされるまで構築されないような本発明の実施形態では、終了ノード（独立プロデューサ及び／又はオーバーライドされたプロデューサである）から実行をスタートすることができ、等々である）。
プロデューサグラフのその後の実行に対して、異なる実施形態は、異なるプロデューサからスタートすることができる（例えば、プロデューサグラフの独立プロデューサから（例えば、増分的実行をサポートしない本発明の実施形態において）；プロデューサグラフのソースプロデューサから（例えば、増分的実行をサポートしない本発明の実施形態において）；最後の実行以来オーバーライドされ及び／又は追加されたソースプロデューサより成るソースプロデューサのサブセットから（例えば、増分的実行をサポートする本発明の実施形態において）；最後の実行以来オーバーライドされ及び／又は追加されたソースプロデューサのうち、オーバーライドされた子孫を伴わないオーバーライドされたプロデューサと、少なくとも１つの経路を間に伴う追加されたプロデューサと、オーバーライドされたプロデューサを含まない根プロデューサとの組合せから（例えば、増分的実行をサポートする本発明の実施形態において）；等）。例えば、これに限定されないが、次のことを遂行する本発明の実施形態について以下に述べる。１）このようなプロデューサが非オーバーライドにされる場合及びそれまで、オーバーライドされたプロデューサのもとでプロデューサグラフを構築せず；２）プロデューサグラフの初期実行に対してエンドノード（これは、独立プロデューサ及び／又はオーバーライドされたプロデューサでよい）の実行をスタートし；３）増分的実行を具現化し；及び４）プロデューサグラフのその後の実行に対して、最後の実行以来オーバーライド及び／又は追加されたソースプロデューサより成るソースプロデューサのサブセットから実行をスタートする。
実行スタートプロデューサの前記概念に関して、プロデューサグラフの実行の処理フローも、異なる実施形態の間で相違する。例えば、本発明の一実施形態では、実行スタートプロデューサの祖先が決定されて集合に入れられ、実行スタートプロデューサが実行され、そして全ての依存性が実行されたところのプロデューサに対して集合が繰り返しスキャンされ、最終的には、根ノードに到達する。別の例として、本発明の一実施形態では、実行スタートプロデューサが実行され、実行スタートプロデューサの親が識別され、それらの親が実行され、そしてそれらの親が識別されて実行され、等々となる。本発明の後者の実施形態を、一例として、非限定的に、以下に使用する。
依存性の例示的形式
例示的なダイナミックプロデューサ依存性
ダイナミックプロデューサ依存性は、ランタイム中に変化するプロデューサ依存性である。プロデューサ依存性を解明するための基準は、ソースコードに存在し、従って、プロデューサ依存性を解明できるプロデューサが制限される。図３Ａを参照すれば、プロデューサグラフ実行モジュール３４５から自動プロデューサグラフ発生モジュール３４０への矢印付き破線は、現在プロデューサグラフ全体を発見し構築するのに必要な現在プロデューサグラフにおける１つ以上のプロデューサを実行するためのサポートを表す。換言すれば、ダイナミックプロデューサ依存性をサポートする本発明の実施形態は、プロデューサグラフ全体が発見され、構築され、解明され及び実行されるまで、自働プロデューサグラフ発生モジュール３４０とプロデューサグラフ実行モジュール３４５との間を繰り返す（即ち、１）そのとき解明できる現在プロデューサグラフの部分を発見し構築するために自動プロデューサグラフ発生モジュールをインボークすることと、２）現在プロデューサグラフのプロデューサを実行するためにプロデューサグラフ実行モジュールをインボークすること、との間を繰り返す）。この意味で、発見とは、プロデューサ依存性宣言にアクセスし、それらが識別するプロデューサを決定することを指し、構築とは、プロデューサをインスタンス生成し、それらをプロデューサグラフに追加することを意味し、そして解明とは、現在解明されていないダイナミックプロデューサ依存性を決定することを指す。
図５Ａは、本発明の一実施形態により未解明の依存性を含む例示的プロデューサグラフの発見及び構築を示すブロック図である。図５Ａは、プロデューサ１より成る、問題とするプロデューサの現在セットを示す。プロデューサ１及びそのプロデューサ依存性宣言に基づいて、プロデューサ２及びプロデューサ３が発見される。換言すれば、プロデューサ１の依存性宣言は、プロデューサ１がプロデューサ２及びプロデューサ３の出力を入力として要求することを示す。又、図５Ａは、プロデューサ３は、独立プロデューサ（従って、ソースプロデューサ）であるが、プロデューサ２は、そうでないことも示している。その結果、プロデューサ２の依存性宣言に基づいて、プロデューサ４及びプロデューサ５が発見される。更に、図５Ａは、プロデューサ４は、独立プロデューサ（従って、ソースプロデューサ）であるが、プロデューサ５は、そうでないことも示している。その結果、プロデューサ５の依存性宣言に基づいて、プロデューサ６及び現在未解明の依存性が発見される。又、図５Ａは、現在未解明の依存性がプロデューサ７Ａ及び／又はプロデューサ７Ｂに対するものであることも示している。
図５Ｂは、本発明の一実施形態により、図５Ａのプロデューサグラフの初期の実行と、未解明の依存性の解明とを示すブロック図である。図５Ｂは、図５Ａのプロデューサグラフを示すもので、矢印付きの曲線は、プロデューサの実行と、それら出力の、従属親プロデューサへの付与とを示している。更に、図５Ｂは、プロデューサ５の未解明の依存性がプロデューサ７Ａに対する依存性として解明され、そしてプロデューサ７Ａが独立プロデューサであることを示している。
図５Ｃは、本発明の一実施形態により、図５Ａのプロデューサグラフの初期の実行及び／又は図５Ｂのプロデューサグラフの再実行を示すブロック図である。図５Ｃは、図５Ａのプロデューサグラフを示すもので、矢印付きの曲線は、プロデューサの実行と、それら出力の、従属親プロデューサへの付与とを示している。更に、図５Ｃは、プロデューサ５の未解明の依存性がプロデューサ７Ｂに対する依存性として解明され、そしてプロデューサ７Ｂが独立プロデューサであることを示している。その結果、プロデューサ７Ｂの依存性宣言に基づいて、プロデューサ８が発見される。プロデューサ８は、独立プロデューサ（従って、ソースプロデューサ）である。図５Ｃが、図５Ａのプロデューサグラフの初期実行を表すと仮定すれば、図５Ｃにおける全ての矢印付き曲線が使用される。しかしながら、図５Ｃが、図５Ｂのプロデューサグラフの再実行を表すと仮定すれば、再実行の結果、ダイナミック依存性が異なる仕方で解明される（プロデューサ５がプロデューサ７Ａに依存することからプロデューサ７Ｂに依存することへとスイッチする）。更に、再実行が増分的実行を伴わずに行われる場合には、図５Ｃにおける全ての矢印付き曲線が使用されるが、増分的実行が使用される場合には、矢印付き非破線曲線しか使用されない（プロデューサ８からプロデューサ７Ｂへ、プロデューサ７Ｂからプロデューサ５へ、プロデューサ５からプロデューサ２へ、及びプロデューサ２からプロデューサ１へ）。又、図５Ｃに示す依存性のダイナミック変化は、例示に過ぎず、従って、多数の異なる状況が生じ得ることも理解されたい（例えば、ダイナミックな変化が決して生じない；プロデューサ５が最初はプロデューサ７Ｂに依存し、次いで、プロデューサ７Ａへと変化する；プロデューサ５が最初はプロデューサ７Ｂに依存し、且つダイナミックな変化は、ずっと生じない；プロデューサ５が図５Ｄに示すようにプロデューサ７Ａ及び７Ｂの両方に依存することが分かる；等々）。異なる実施形態では、異なる仕方でダイナミックプロデューサ依存性を解明できるが、幾つかの例について以下に述べる。
従って、プロデューサグラフの自動再実行は、プロデューサが変更され且つその直接的な親が再実行されることに制限されず、むしろ、変化が、ランタイムによりプロデューサグラフを通して自動的に波及されて、適切なプロデューサ及び依存性に影響を及ぼす。というのは、プロデューサグラフが維持される（且つ増分的実行がサポートされるところでそれが使用される）からである。従って、変化は、必要な付加的な発見、構築、解明及び実行を生じさせる。従って、プロデューサグラフの再実行は、プロデューサグラフのどのプロデューサが影響されるかユーザ／プログラマーが決定しておそらく手動でグラフを修正する必要がないという意味で、自動的である。
スタティックプロデューサ依存性
スタティック依存性とは、ランタイム中に変化しないものである。従って、コンティンジェント及びサブスクリプションダイナミック依存性をサポートする本発明の実施形態では（以下に述べる）、非コンティンジェント、非サブスクリプション依存性がスタティック依存性である。図４Ａの例示的なプロデューサグラフは、スタティック依存性のプロデューサグラフを示している。
プロデューサグラフ形状
プロデューサは、少なくとも、インスタンス、及びそのインスタンスに関連したメソッドであるから、プロデューサグラフは、インスタンス及びそれらインスタンスに関連したメソッドを表すグラフであり、従って、プロデューサグラフは、少なくともインスタンス及びメソッド中心である。プロデューサが少なくともクラス、インスタンス及びメソッドである本発明の実施形態では、プロデューサグラフは、少なくともクラス、インスタンス及びメソッド中心である。
プロデューサグラフは、種々の異なる形状（例えば、プロデューサの単一チェーン、ツリー、等）をとり得ることを理解されたい。図５Ｂの例示的プロデューサグラフは、プロデューサ１の根ノードがあって、そこから、プロデューサ２及びプロデューサ３の各々へ２つの分岐があるツリーである。プロデューサ３が葉ノードである場合には、プロデューサ２は、そこから、プロデューサ４及びプロデューサ５の各々へ延びる２つの分岐を有する。プロデューサ５は、そこから、プロデューサ６及びプロデューサ７Ａへ各々延びる２つの分岐を有する。図５Ｂの例示的プロデューサグラフは、マルチレベルと言われ、レベル１は、ルード(rood)ノードプロデューサ１を含み、レベル２は、プロデューサ２及びプロデューサ３を含み、レベル３は、プロデューサ４及びプロデューサ５を含み、レベル４は、プロデューサ６及びプロデューサ７Ａを含む（図５Ｃでは、レベル４は、プロデューサ７Ｂを含み、そしてレベル５は、プロデューサ８を含む）。プロデューサ２を伴うプロデューサ１からの分岐を考慮するときには、分岐の第１プロデューサは、プロデューサ２であり、そして分岐の最後のプロデューサは、図５Ｂにおいて、プロデューサ４、プロデューサ６及びプロデューサ７Ａである。
図５Ｂは、問題とするプロデューサの現在セットが単一プロデューサを含むようなプロデューサグラフを示すが、問題とする２つ以上の現在プロデューサをサポートする本発明の実施形態は、その各々に対してプロデューサグラフを発見し構築する。問題とするプロデューサが同時に複数ある場合には、それにより得られるプロデューサグラフは、独立でもよいし、又は交差してもよいことを理解されたい。プロデューサグラフが交差する場合には、本発明の実施形態は、次のように具現化できる。即ち、１）個別のプロデューサグラフを維持するようにプロデューサを複製する；又は２）このような複製を回避し、交差するプロデューサグラフを維持する。又、このような交差するプロデューサグラフは、別のプロデューサグラフのサブセットであるプロデューサグラフを含んでもよいことも理解されたい。例えば、プロデューサ５が、問題とするプロデューサの現在セットにプロデューサ１と共に含まれた場合には、プロデューサ５の根ノードを伴う第１プロデューサグラフと、プロデューサ１の根ノードを伴う第２プロデューサグラフとがあり、ここで、第２プロデューサグラフが第１プロデューサグラフを含む。例えば、プロデューサ７Ｂが、問題とするプロデューサの現在セットにプロデューサ１及びプロデューサ５と共に含まれた場合には、第１及び第２のプロデューサグラフとは個別で、図５Ｂにおけるプロデューサ７Ｂの根ノードを伴う第３のプロデューサグラフがある。更に、プロデューサ５のダイナミック依存性がプロデューサ７Ａからプロデューサ７Ｂへと変化した場合には（図５Ｃ）、この変化の結果、第３プロデューサグラフは、残されている第２プロデューサグラフのサブセットとなり、且つ第２プロデューサグラフは、第１プロデューサグラフのサブセットとなる。上述したように、本発明の実施形態は、プロデューサグラフ（１つ又は複数）をグラフの集合として記憶し操作できるが、本発明の他の実施形態では、プロデューサグラフの合併及び分割を容易にするために、（グラフの集合ではなく）グラフ（１つ又は複数）を形成するように互いにリンクされるプロデューサの集合としてプロデューサグラフ（１つ又は複数）を記憶し操作することができる。一例として、これに限定されないが、プロデューサの集合としてプロデューサグラフ（１つ又は複数）を記憶し操作する本発明の実施形態をここに説明する。
例示的実行フロー
図６は、本発明の一実施形態により、ランタイムクライアントの論理的実行フローと、プロデューサグラフ指向のプログラミングサポートを伴うランタイムに対するその関係とを示すフローチャートである。図６において、破線の分割線６００は、ランタイムクライアント６１０の論理的実行フローを、プロデューサグラフ指向のプログラミングサポートを伴うランタイム６４０から分離している。
ランタイムクライアント６１０の論理的実行フローは、ブロック６１５、６２０、６２５及び６３０を含み、一方、プロデューサグラフ指向のサポートを伴うランタイム６４０は、ブロック６４５、６５０、６６０及び任意の６５５を含む。矢印付きの実線は、ブロック６３０からブロック６６０への直接的因果関係を示す。対照的に、矢印付きの点線は、ランタイムクライアント６１０の論理的実行フローにおけるブロック６１５及び６２５から、プロデューサグラフ指向のサポートを伴うランタイムにおけるブロック６４５及び６５０への因果関係を各々示し、本発明の実施形態に基づき、この因果関係は、直接的でも間接的でもよい。例えば、図６は、破線６００の、プロデューサグラフ指向のサポートを伴うランタイム６４０の側で、破線楕円におけるコマンドログ６６５の使用により任意の間接的な因果関係を示す。コマンドログ６６５は、コマンドログ６６５は、ランタイムクライアント６１０の論理的実行フローのブロック６１５及び６２５から生じるコマンドを収集し、そしてコマンドログ６６５は、ブロック６３０に応答して、処理ブロック６６０により消費される。従って、コマンドログ６６５は、コマンドを遅延させて、複数のコマンドを一緒に収集し、それらを最適化のためにバッチ処理できるようにする。従って、コマンドログ６６５は、図３Ｂのオーバーライドログ３９６と同様であり、実際上、本発明の幾つかの実施形態にはオーバーライドログ３９６が含まれる。
ブロック６１５において、問題とする１つ以上のプロデューサのセットは、問題とするプロデューサの現在セットとして決定され、制御がブロック６２０へ通される。ブロック６１５とブロック６４５との間の因果関係に応答して、ブロック６４５は、問題とするプロデューサの現在セットがインスタンス生成されることを示すと共に、ランタイムクライアント６１０におけるプロデューサ依存性宣言に基づき、インスタンス及びそのプロデューサを必要に応じてインスタンス生成することも含めて、各々プロデューサグラフ（１つ又は複数）を発見し、構築し、且つ解明するよう試みる（ダイナミック依存性がサポートされ且つその１つ以上がプロデューサグラフにおいて発見される場合に）ことを示す。図３Ａ及び３Ｂを参照すれば、自動プロデューサグラフ発生モジュール３４０及び３６５が各々インボークされる。
ブロック６２０において、プロデューサ出力オーバーライドがあるかどうか決定される。もしあれば、制御がブロック６２５へ回され、さもなければ、制御がブロック６３０へ回される。
ブロック６２５において、１つ以上のプロデューサ出力オーバーライドが、１つ以上のプロデューサのセットに対して受け取られ、制御がブロック６３０へ回される。ブロック６２５とブロック６５０との間の因果関係に応答して、ブロック６５０は、オーバーライドされたプロデューサの現在セットがインスタンス生成され（ブロック６４５においてまだインスタンス生成されていない場合）、それらの出力が変更され、そしてそれらが追跡されることを示す。オーバーライドされたプロデューサは、ブロック６４５においてプロデューサグラフ（１つ又は複数）の一部分であることが既に発見されているので、既にインスタンス生成されているかもしれない。しかしながら、オーバーライドされたプロデューサは、未解明のダイナミック依存性のものであるので、ブロック６４５においてまだ発見されていないかもしれない。従って、このオーバーライドされたプロデューサは、ダイナミック依存性が解明されたときにプロデューサグラフに追加されることを予想して、インスタンス生成されオーバーライドされる。又、既に述べたように、図３Ｂのオーバーライドログ３９６は、それが具現化された場合に、ブロック６２５とブロック６５０との間に存在し、そしてコマンドログ６６５の一部分となる。更に、オーバーライドされたプロデューサのセットは、増分的実行をサポートする本発明の幾つかの実施形態において追跡される。オーバーライドログ３９６／コマンドログ６６５をサポートする本発明の実施形態において、追跡はログの一部分であるが、本発明の別の実施形態では、追跡は、異なるメカニズムを伴うブロック６５０において個別に遂行される。
ブロック６３０において、プロデューサグラフ実行モジュールがインボークされ、そして制御がブロック６１５及び／又はブロック６２５へ任意に戻される。ブロック６３０とブロック６６０との間の因果関係に応答して、ブロック６６０は、現在プロデューサグラフ（１つ又は複数）がウォーキングされ、そして実行を要求するプロデューサが、追跡に基づいて実行される。プロデューサグラフのプロデューサを実行するための種々の技術が上述され、それらをここに適用することができる。図３Ａ及び３Ｂを参照すれば、プロデューサグラフ実行モジュール３４５及び３７０が各々インボークされる。更に、コマンドログ６６５が具現化される本発明の実施形態では、因果関係は、コマンドログ６６５を消費し、そしてブロック６６０の前に処理ブロック６４５及び６５０を遂行することを含む。更に、未解明の依存性の可能性をサポートする本発明の実施形態では、制御が必要なときにブロック６６０からブロック６６５へ流れる。
ブロック６５５において、未解明の依存性を解明し、そしてインスタンス及びそのプロデューサをインスタンス生成することを含めて、プロデューサグラフ（１つ又は複数）の残りを発見し構築するように試みられる。ブロック６５５から、制御は、ブロック６６０へ戻される。
プロデューサ依存性宣言の例示的形態
図７Ａ−Ｆは、本発明の一実施形態によるプロデューサ依存性宣言に対する幾つかの例示的形態を示す。図７Ａ−Ｆは、引数、フィールド及びシーケンス依存性をサポートする実施形態を示すが、異なる実施形態が、３つの依存性形態のうちの１つ又は２つだけをサポートしてもよいことが理解されよう。図７Ａ−Ｆに示す本発明の実施形態では、プロデューサ依存性宣言は、プロデューサ依存性宣言ステートメント、及び任意のものとして、明示的プロデューサ依存性宣言コードで構成される。非ショートカット宣言プロデューサ依存性は、明示的プロデューサ依存性宣言コードが使用されるものであり、一方、ショートカット宣言プロデューサ依存性は、明示的プロデューサ依存性宣言コードが使用されない（むしろ、ランタイムがプロデューサ依存性宣言コードを使用せず、及び／又はそれを、プロデューサ依存性宣言ステートメントの情報に基づいてオンザフライで具現化する）ものである。
本発明の異なる実施形態は、プロデューサ依存性を宣言するために異なるシンタックスを使用することができる。例えば、本発明の異なる実施形態は、生成できるプロデューサ依存性の形式を強く制約し、弱く制約し、及び／又は制約しない異なるシンタックを、プロデューサ依存性宣言ステートメントに使用するために含ませることができる。強く制約されるプロデューサ依存性は、生成できるプロデューサ依存性の形式を実質的に制限するシンタックスがプロデューサ依存性宣言ステートメントに使用されるというものであり、弱く制約されるプロデューサ依存性は、生成できるプロデューサ依存性の形式をあまり制限しないシンタックスがプロデューサ依存性宣言ステートメントに使用されるというものであり、そして非制約のプロデューサ依存性は、生成できるプロデューサ依存性の形式を制限しないシンタックスがプロデューサ依存性宣言ステートメントに使用されるというものである。
例えば、これに限定されないが、以下に述べる本発明の実施形態は、次のものを含む。即ち、１）引数に対して強く制約されたプロデューサ依存性のためのシンタックス（ArgumentDependency＝強く制約され下方に宣言された引数［スタティック又はダイナミックそしてダイナミックの場合にはコンティンジェント及び／又はアブソーブサブスクリプション］依存性）；２）フィールドに対して強く制約されたプロデューサ依存性のためのシンタックス（FieldDependency＝強く制約され下方に宣言されたフィールド［スタティック又はダイナミックそしてダイナミックの場合にはコンティンジェント及び／又はアブソーブサブスクリプション］依存性）；３）シーケンス依存性に対して強く制約されたプロデューサ依存性のためのシンタックス（SequencingDependency＝強く制約され下方に宣言されたシーケンス［スタティック又はダイナミックそしてダイナミックの場合にはコンティンジェント及び／又はスティッキーサブスクリプション］依存性）；４）引数、フィールド又はシーケンス依存性に対して弱く制約され上方に宣言されたプロデューサ依存性のためのシンタックス（UpwardDependency＝弱く制約され上方に宣言されたフィールド、引数、又はシーケンス［スタティック又はダイナミックそしてダイナミックの場合にはコンティンジェント］依存性）；及び５）弱く制約されたプロデューサ依存性のためのシンタックス（WeaklyConstrainedDependency＝ａ）下方に宣言されたシーケンスのみ［スタティック又はダイナミックそしてダイナミックの場合にはコンティンジェント及び／又はスティッキーサブスクリプション］依存性、又はｂ）上方に宣言された［引数、フィールド又はシーケンス］［スタティック又はダイナミックそしてダイナミックの場合にはコンティンジェント］依存性）。本発明の幾つかの実施形態は、下方に宣言された引数依存性、下方に宣言されたフィールド依存性、上方に宣言された依存性（上方に宣言された引数、フィールド又はシーケンス依存性を返送できる）、及び弱く制約される依存性（下方に宣言されたシーケンス依存性、上方に宣言された引数、フィールド、又はシーケンス依存性を返送できる）を区別するプロデューサ依存性宣言ステートメントのためのシンタックスをサポートするが、本発明の別の実施形態は、異なるシンタックスを採用してもよい（例えば、サポートされた依存性（下方及び上方に宣言された引数、フィールド及びシーケンス依存性）を返送できる依存性決定プロデューサで全ての依存性を非制約の依存性にさせるシンタックスを有し；サポートされた全ての依存性を区別するシンタックスを有し；下方及び上方に宣言された引数及びフィールド依存性を区別すると共に、上方及び下方に宣言されたシーケンス依存性しか返送できない弱く制約された依存性を区別するシンタックスを有し；下方に宣言された引数及びフィールド依存性を区別すると共に、上方に宣言されたシーケンス依存性しか返送できない上方に宣言された依存性を区別するシンタックスを有し；下方に宣言された引数、フィールド、及びシーケンス依存性を区別する（スティッキーサブスクリプション及び上方に宣言された依存性はサポートされない）シンタックスを有し；等々）。
プロデューサ依存性宣言ステートメントのシンタックスは、必ずしも、プロデューサグラフに生成されたプロデューサ依存性（例えば、リンク）に等しくないことを理解されたい（例えば、ArgumentDependencyは、引数依存性を生成するが、UpwardDependencyは、引数、フィールド又はシーケンス依存性を生成することができる）。従って、理解のために適切である場合に、修飾子（例えば、引数、フィールド又はシーケンス）と語「依存性」との間のスペースは、ランタイムにより生成される依存性を指すのに使用され、一方、スペースの欠落は、シンタックスを指すのに使用される。
図７Ａは、本発明の一実施形態によりショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図７Ｂは、本発明の一実施形態による例示的プロデューサのブロック図である。図７Ａは、次のものを示す。１）ArgumentDependencies 1-N、FieldDependencies 1-M、SequencingDependencies 1-L、UpwardDependencies 1-P、及びWeaklyConstrainedDependencies 1-Qを含むプロデューサ依存性宣言ステートメント７０５；及び２）プロデューサ依存性宣言ステートメント７０５からの引数１−Ｎを有するメソッドアルファ７１０。本発明の一実施形態では、プロデューサ依存性宣言ステートメントの引数は、追跡のために各々引数ＩＤを与えるように番号付けされる。図７Ｂは、次のものに対する子依存性を有するプロデューサ７２０を示している。１）引数ＩＤ １に対するプロデューサ７２５；２）引数ＩＤ Ｎに対するプロデューサ７３０；３）FieldDependencies 1-Mに対するプロデューサ７４０−７４５；４）SequencingDependencies 1-Lに対するプロデューサ７４６−７４７；及び５）UpwardDependencies 1-Pに対するプロデューサ７４８−７４９（注：WeaklyConstrainedDependencies 1-Qは、図示されていないが、図７Ｇを参照して詳細に説明する）。従って、プロデューサ依存性宣言ステートメント７０５の引数は、メソッドアルファ７１０の引数に対応し、そしてプロデューサ依存性宣言ステートメント７０５における引数の引数ＩＤは、それらが識別する子プロデューサに関して追跡される。
図７Ｃは、本発明の一実施形態により非ショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示すと共に、例示的プロデューサのブロック図である。図７Ｃは、図７Ａのプロデューサ依存性宣言ステートメント７０５及びメソッドアルファ７１０を示すと共に、図７Ｂのプロデューサ７２０及び７２５を示す。更に、図７Ｃは、ArgumentDependency 1に関連したプロデューサ依存性宣言コード７１５も含む。ランタイム中に、ランタイムは、プロデューサ依存性宣言ステートメント７０５のArgumentDependency 1に応答してプロデューサ依存性宣言コード７１５にアクセスして実行する。プロデューサ依存性宣言コード７１５の実行は、プロデューサ７２５をArgumentDependency 1のためのプロデューサ依存性として返送する。従って、図７Ｃは、プロデューサ依存性宣言コード７１５が（メソッドアルファ７１０以外の）メソッドの一部分でよいが、プロデューサの一部分ではないような本発明の実施形態を示す。
図７Ｄは、本発明の一実施形態により非ショートカット宣言依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図７Ｅは、 本発明の一実施形態による例示的プロデューサのブロック図である。図７Ｄは、図７Ａのプロデューサ依存性宣言ステートメント７０５及びメソッドアルファ７１０を示し、一方、図７Ｅは、図７Ｂからのプロデューサ７２０及び７２５を示す。更に、図７Ｄは、１）プロデューサ依存性宣言ステートメント７５０、及び２）プロデューサ依存性宣言コード７６０を含むメソッドベータ７５５も示している。又、図７Ｄは、プロデューサ依存性宣言ステートメント７０５の引数依存性１が、引数依存性１に対して依存性を返送するメソッドベータ７５５に基づいてプロデューサ（図７Ｅにプロデューサ７６５として示された）を識別することも示している。ランタイム(run time)中に、ランタイム(runtime)は、プロデューサ依存性宣言ステートメント７０５の引数依存性１に応答して、プロデューサ７６５を実行し、引数依存性１に対するプロデューサ依存性がプロデューサ７２５であるという識別を返送する。従って、プロデューサ７６５は、依存性決定プロデューサと称され（その出力は、プロデューサ依存性であり、従って、プロデューサグラフ指向のプログラミングサポートを伴うランタイムにより特殊な処理（プロデューサグラフ（１つ又は複数）の操作）に対して監視されるクラス／インスタンスを使用して返送され）、一方、プロデューサ７２５は、標準的プロデューサと称される（その出力がもしあれば、それは、プロデューサグラフを操作するようにランタイムによって直接処理されず；その出力がもしあれば、それは、親プロデューサ（依存性決定プロデューサ又は別の標準的プロデューサ）により消費することができ、及び／又はプロデューサグラフの出力として与えることができる（標準的なプロデューサが問題とするプロデューサであり、従って、根ノードである場合）。
従って、図７Ｄ−Ｅは、プロデューサ依存性宣言コード７１５が、依存性決定プロデューサと称される別のプロデューサの一部分であるような本発明の実施形態を示す。図７Ｄ−Ｅにおいて、オブジェクト指向のソースコードは、メソッドに明示的プロデューサ依存性宣言コードを含み、そこから、ランタイム時に、非ショートカット宣言依存性に対してランタイムにより依存性決定プロデューサがインスタンス生成されるが、本発明の別の実施形態は、それに加えて又はそれとは別に、ショートカット宣言依存性に対してオンザフライで１つ以上の一般的な依存性決定プロデューサとしてインボークされる一般的なプロデューサ依存性宣言コードを含むようにランタイムを具現化する。又、図７Ｃ−Ｅは、ArgumentDependenciesに関して示されているが、図示された技術は、他の形式の下方に宣言された依存性に適用することができる。更に、図７Ｆ−Ｇは、UpwardDependencies及びWeaklyConstrainedDependenciesに対する依存性決定プロデューサの使用も示している。
図７Ｆは、本発明の一実施形態により依存性決定プロデューサを伴うUpwardDependencyの使用による例示的依存性を示すブロック図である。図７Ｆは、依存性決定プロデューサ７７２に対するシーケンスプロデューサ依存性を有するプロデューサ７２０を示している。依存性決定プロデューサは、プロデューサ７２０に対する親プロデューサ７４８の非サブスクリプションの上方に宣言された引数、フィールド又はシーケンス依存性を返送することができる。更に、このような依存性決定プロデューサは、ダイナミック依存性（例えば、以下に述べるように、異なる引数ＩＤ間を含めて、データ値に基づき前記のものの間で選択するコンティンジェント依存性）を具現化することができる。本発明のある実施形態は、全てのこれら可能性をサポートするが、本発明の別の実施形態は、サブセットのみ（例えば、非サブスクリプションの上方に宣言されたシーケンス依存性のみ）をサポートする。
図７Ｇは、本発明の一実施形態により依存性決定プロデューサを伴うWeaklyConstrainedDependencyの使用により考えられる例示的依存性を示すブロック図である。図７Ｇは、依存性決定プロデューサ７７５に対するシーケンスプロデューサ依存性を有するプロデューサ７２０を示している。本発明のある実施形態では、依存性決定プロデューサは、次のいずれかを返送することができる。１）子プロデューサ７８０に対する非サブスクリプションの下方に宣言されたシーケンス依存性；２）プロデューサ７２０に対する親プロデューサ７８５の非サブスクリプションの上方に宣言された引数、フィールド又はシーケンス依存性；及び３）スティッキーサブスクリプション（以下に述べる）。更に、このような依存性決定プロデューサは、ダイナミック依存性（例えば、以下に述べるように、異なる引数ＩＤ間を含めて、データ値に基づき前記のものの間で選択するコンティンジェント依存性）を具現化することもできる。本発明のある実施形態は、全てのこれら可能性をサポートするが、本発明の別の実施形態は、サブセットのみ（例えば、非サブスクリプションの上方に宣言されたシーケンス依存性のみ）をサポートする。
上述したように、シーケンス依存性は、ランタイムが気付かない仕方でデータを変更するプロデューサと、そのデータを消費するプロデューサとの間で実行順序を確保すること等を含めて、種々の目的で使用することができる（子プロデューサは、その出力にアクセスするコードを含ませるために親プロデューサのメソッドを要求する仕方でその出力を書き込むことができる（例えば、普通のプロデューサ出力でなく、従って、ランタイムにより検出されない出力に作用することにより環境にインパクトを与えるメソッド、例えば、グローバル変数をセットし、プロデューサ出力でないインスタンスにおいてフィールドをセットし、外部データソースにインパクトを与える、等のメソッド））。
異なる実施形態は、プロパティプロデューサに対してプロデューサ依存性を宣言するための１つ以上の方法をサポートすることができる。より詳細には、本発明の幾つかの実施形態において、フィールドを読み取るプロデューサは、ゲットプロパティ(get property)プロデューサに依存しなければならず、一方、ゲットプロパティプロデューサは、ゲットプロパティメソッドが責任を負うところのフィールドをセットするプロデューサに依存しなければならない。シーケンスプロデューサ依存性をサポートする本発明の実施形態に使用できるこの状況を取り扱う１つの技術は、ゲットプロパティメソッドに対し、そのゲットプロパティメソッドが責任を負うところのフィールドをセットする各メソッドに対するシーケンスプロデューサ依存性を生成するプロデューサ依存性宣言ステートメントを与えることである（例えば、図７Ｇに関して、プロデューサ７８０がフィールドをセットするプロデューサであり、且つプロデューサ７２０がそのフィールドに対して責任のあるゲットプロパティプロデューサである場合には、依存性決定プロデューサ７７５は、プロデューサ７８０に対するプロデューサ７２０の下方に宣言されたシーケンス依存性を返送するように書かれる）。シーケンスプロデューサ依存性及び上方に宣言されたプロデューサ依存性の両方をサポートする本発明の実施形態に使用できるこの状況を取り扱う第１の技術は、フィールドをセットするメソッドに対するプロデューサ依存性宣言ステートメント／コードにおいて、そのフィールドについて責任を負うゲットメソッドに対する上方に宣言されたシーケンスプロデューサ依存性（例えば、UpWardDependency又はWeaklyConstrainedDependenciesを使用する）を含ませることである（例えば、図７Ｇに関して、プロデューサ７２０がフィールドをセットするプロデューサであり、且つプロデューサ７８５がそのフィールドに対して責任のあるゲットプロパティプロデューサである場合には、依存性決定プロデューサ７７５は、プロデューサ７２０に対する親プロデューサ７８５の上方に宣言されたシーケンス依存性を返送するように書かれる）。この第２の技術は、フィールドをセットするメソッドのプログラマーが、適切なゲットメソッドに対するプロデューサ依存性を与える責任をもてるようにするもので、プログラマーがゲットメソッドへと進んでそのプロデューサ依存性宣言ステートメント／コードを変更することを要求するのではない。
シーケンス依存性を使用するとき、所与のプロデューサが所与の変数に依存するときには、その変数は、プロデューサグラフ（１つ又は複数）の所与の実行においてそのプロデューサの子孫プロデューサの２つ以上により変更されてはならない（コンティンジェント依存性（以下に述べる）により、現在プロデューサグラフ（１つ又は複数）の異なる実行中に、異なる子孫プロデューサがその変数を変更し得ることに注意されたい）。例えば、ゲットプロパティプロデューサは、現在プロデューサグラフ（１つ又は複数）の所与の実行においてそのゲットプロパティプロデューサが責任を負うフィールドをセットする１つの他のプロデューサのみに依存するものでなければならない。
本発明の異なる実施形態は、図７Ａ−Ｆに示す本発明の実施形態の１つ以上を具現化できることを理解されたい。例えば、本発明の一実施形態は、依存性決定プロデューサを使用してショートカット及び非ショートカット宣言依存性をサポートし、より詳細には、本発明のこの実施形態では、１）オブジェクト指向のソースコードは、メソッドに明示的プロデューサ依存性宣言コードを含み、そこから、ランタイムに、非ショートカット宣言依存性に対してランタイムにより依存性決定プロデューサがインスタンス生成され；２）ランタイムは、ショートカット宣言コンティンジェント依存性（以下に述べる）に対してオンザフライで１つ以上の一般的な依存性決定プロデューサとしてインボークされる一般的なプロデューサ依存性宣言コードを含み；そして３）ランタイムは、ショートカット宣言非コンティンジェントプロデューサ依存性（以下に述べる）を直接リンクするためのサポートを含む。
別の例として、本発明の一実施形態は、依存性決定プロデューサを使用して非ショートカット及びショートカット宣言プロデューサ依存性をサポートし、より詳細には、本発明のこの実施形態では、１）オブジェクト指向のソースコードは、メソッドに明示的プロデューサ依存性宣言コードを含み、そこから、ランタイム時に、非ショートカット宣言依存性に対してランタイムによって依存性決定プロデューサがインスタンス生成され、そして；２）ランタイムは、ショートカット宣言依存性に対して（形式に関わりなく）オンザフライで１つ以上の一般的な依存性決定プロデューサとしてインボークされる一般的な依存性決定コードを含む。この後者の実施形態は、プロデューサ依存性の一貫した処理を許し、従って、ランタイムを簡単にする。
更に、本発明の一実施形態では、メソッドに対するプロデューサ依存性宣言ステートメントは、オブジェクト指向のソースコードにおけるそのメソッドの真上に位置されるが、本発明の別の実施形態では、別のところに位置される（例えば、あるクラスの全てのメソッドに対するプロデューサ依存性宣言ステートメントが、そのクラス内で一緒にグループ化され、全てのクラスの全てのメソッドに対するプロデューサ依存性宣言ステートメントが個別のデータテーブルとして一緒にグループ化され、等々）。又、本発明の一実施形態では、プロデューサ依存性宣言コードがプロデューサ依存性宣言ステートメントとは別個であるが、本発明の別の実施形態では、それらが合成される（例えば、プロデューサ依存性宣言コードがプロデューサ依存性宣言ステートメントのカッコ内にあり、プロデューサ依存性宣言コードがプロデューサ依存性宣言ステートメントの真下にあってランタイムにより単一のユニットとして処理され、等々である）。
図７Ｈ−Ｉは、依存性決定プロデューサのためにプロデューサグラフに存在し得る異なるサブグラフ間の区別を示す。図７Ｈは、本発明の一実施形態による標準的プロデューサのプロデューサグラフを例示する。より詳細には、図７Ｈは、根ノードＳ１を伴うプロデューサグラフ、根ノードＳ５を伴うプロデューサグラフ、及び根ノードＳ１１を伴うプロデューサグラフを示す。標準的プロデューサＳ１は、子の標準的プロデューサＳ２、Ｓ３及びＳ４を有し、標準的プロデューサＳ２及びＳ３は、子の標準的プロデューサＳ７及びＳ８を有し、標準的プロデューサＳ５は、子の標準的プロデューサＳ４及びＳ６を有し、そして標準的プロデューサＳ１１は、子の標準的プロデューサＳ６及びＳ１０を有する。図７Ｈの例示的プロデューサグラフは、多数のプロデューサ依存性及び依存性決定プロデューサを使用して発見し、構築し、解明することができる。図７Ｉは、図７Ｈのプロデューサグラフを発見し、解明し、構築するためのプロデューサ依存性及び依存性決定プロデューサの一例を示す。より詳細には、図７Ｉは、図７Ｈのグラフが、プロデューサグラフの大きなセットのうちのサブグラフであることを示している。換言すれば、図７Ｉのプロデューサグラフは、図７Ｈのグラフ（「ターゲットサブグラフ」と称され、矢印付き実線及び実線の楕円を使用して示されている）と、ターゲットサブグラフの発見、解明、構築を助成するグラフ（「判断サブグラフ」と称され、矢印付き破線及び破線の楕円を使用して示されている）とを含む。図７Ｈの判断サブグラフは、依存性決定プロデューサ（ＤＤＰ）１−１１及び標準的プロデューサＳ９−１０を含む。図７Ｈにおいて、Ｓ１は、ＤＤＰ１−３に依存するとして示され、これらは、各々、Ｓ２、Ｓ３及びＳ４に対するＳ１の下方に宣言されたプロデューサ依存性を返送し、Ｓ４は、ＤＤＰ４に依存するとして示され、これは、Ｓ４に対するＳ５の上方に宣言されたプロデューサ依存性を返送し、Ｓ５は、ＤＤＰ５に依存するとして示され、これは、Ｓ６に対するＳ５の下方に宣言されたプロデューサ依存性を返送し、Ｓ３は、ＤＤＰ６に依存するとして示され、これは、次いで、ＤＤＰ８に依存し、これは、Ｓ９及びＳ１０に対するＤＤＰ６の下方に宣言されたプロデューサ依存性を返送し、これは、ＤＤＰ６が、Ｓ７に対するＳ３の下方に宣言された依存性を返送するようにさせ、Ｓ３は、ＤＤＰ７に依存するとして示され、これは、Ｓ８に対するＳ３の下方に宣言されたプロデューサ依存性を返送し、Ｓ８は、ＤＤＰ９に依存するとして示され、これは、Ｓ６がトリガープロデューサで且つＳ１１が生成された親であるところのスティッキーサブスクリプション（従って、Ｓ６に対するＳ１１のプロデューサ依存性）を返送し、Ｓ２は、ＤＤＰ１０に依存するとして示され、これは、Ｓ７及びＳ８に対するＳ２の下方に宣言されたプロデューサ依存性の集合を返送し、そしてＳ１１は、ＤＤＰ１１に依存するとして示され、これは、Ｓ１０に対するＳ１１の下方に宣言されたプロデューサ依存性を返送する。標準的プロデューサは、ターゲットサブグラフ及び判断サブグラフの両方の一部分でよい（例えば、Ｓ１０を参照）ことを理解されたい。ターゲットサブグラフは、データが、グラフを上るように、ある標準的プロデューサから別の標準的プロデューサへ流れるという意味で、データ駆動されることに注意する価値がある。
例示的プログラミング及び実行フレームワーク
図８Ａは、本発明の一実施形態によりアプリケーションがエンドユーザに与えられるところの第１の例示的フレームワークを示すブロック図である。図８Ａに示すフレームワークは、３つの基本的な区分を含む。第１区分は、プロデューサグラフ指向のプログラミングサポートを伴うランタイム８１０の生成を含む。この第１区分は、非常に高度なプログラミングスキルをもつプログラマーによって遂行される。この区分で作業するときには、プログラマーは、ランタイムプログラマーと称される。プロデューサグラフ指向のプログラミングサポートを伴うランタイムを生成するときには、ランタイムプログラマーは、プロデューサグラフに対するサポートと、変換コード、インスタンス生成コード及びデータ準備コードに使用される種々の形式のコマンドを実行するためのサポートとを含む。
第２区分は、ランタイムによって実行されるオブジェクト指向のアプリケーションソースコード８２０の生成を含む。オブジェクト指向のアプリケーションソースコード８２０は、２つの基本的区分を含む。即ち、１）プロデューサ依存性宣言を伴うメソッドで表現されたビジネスロジックを含むクラス定義８２２（これは、グラフィックユーザインターフェイスのような他のファンクションを任意に含むことができ、このケースでは、グラフィックユーザインターフェイスは、プロデューサ及びプロデューサ依存性宣言を使用して書かれ）；及び２）メソッドで表現されたクライアントコードを含むクラス定義８２４。これは、更に、インスタンス生成コード（プロデューサグラフ（１つ又は複数）を発生させるための、問題とするクラス、インスタンス及びプロデューサ（１つ又は複数））８２４Ａ、データ準備コード（例えば、プロデューサ出力のオーバーライドをトリガーするセットコマンドのようなセットコマンド）８２４Ｂ、プロデューサグラフ（１つ又は複数）を実行させるグローバル実行コマンド（例えば、実行及びゲットコマンド）８２４Ｃ、及び必要なグラフィックユーザインターフェイス８２４Ｄ（８２２には含まれず）を含む。プロデューサ依存性宣言は、クラスのインスタンスが生成された後ではなく、ビジネスロジックを含むクラスの定義中に、プロデューサ間の連結を定義するのに使用される。オブジェクト指向のソースコード８２０は、コンパイルされて実行されるハードコード化クラス、インスタンス、及びメソッドである。
本発明の一実施形態では、グローバル実行コマンドが具現化され、これを実行すると、プロデューサグラフ（１つ又は複数）構造３８０に現在ある全てのプロデューサグラフ（１つ又は複数）の実行が試みられるが、本発明の別の実施形態では、それとは別に又はそれに加えて、実行されるべき現在プロデューサグラフ（１つ又は複数）の所与のグラフの識別を要求するグラフ特有の実行コマンドが具現化される。更に、グローバルな実行コマンドは、ランタイムの具現化に基づき、明示的（例えば、セット、セット、セット、実行、ゲット、ゲット）でもよいし、又は暗示的でもよい。例えば、暗示的なグローバル実行コマンドは、１）問題とするプロデューサに対する第１ゲットコマンド（例えば、セット、セット、セット、ゲット(暗示的実行)、ゲット）によりトリガーすることができ、２）各データ操作（セット(暗示的実行)、セット(暗示的実行)、セット(暗示的実行)）によりトリガーすることができ、等々である。
第２区分も、プログラミングスキルをもち且つアプリケーションのビジネスオブジェクトを理解するプログラマーによって遂行される。この区分で作業するときには、プログラマーは、ランタイムプログラマーと称される。その一部分として、アプリケーションがグラフィックユーザインターフェイスを要求する場合には、アプリケーションプログラマーは、特定のアプリケーションに対してグラフィックユーザインターフェイスの設計及びコード化も行い、従って、アプリケーションデザイナーとも称される。
第３区分は、ランタイムにより実行されるアプリケーションプログラムの使用を含む。第３区分は、プログラミングスキルをもつ必要のないエンドユーザによって遂行される。アプリケーションプログラムは、種々の仕方で配布することができる（例えば、ソースコードとして；ソースコードを変換したもの、例えば、バイトコードとして；バイナリーとして；等々）。更に、アプリケーションプログラムは、スタンドアローン使用８３０（このケースでは、全アプリケーションプログラム（及びまだ存在しなければランタイム）がコンピュータシステムに与えられる）及び／又はクライアント／サーバー使用に対して配布することもできる。本発明の一実施形態では、クライアント／サーバー配布は、サーバー使用８３２に対してプロデューサ依存性宣言を伴うメソッドで表現されたビジネスログを含むクラス定義８２２（及びまだ存在しなければランタイム）と、クライアント使用８３４に対してメソッドで表現されたクライアントコードを含むクラス定義８２４（及びまだ存在しなければランタイム）とを配布することを含み、コンピュータシステムにおけるクライアント使用８３４は、サーバーシステムにおけるサーバー使用８３２との通信を生じさせる。
又、図８Ａは、スタンドアローン使用８３０及びクライアント使用８３４に対して設けられた任意の構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０も示している。オブジェクト指向のソースコード８２０は、プロデューサグラフ（１つ又は複数）を発生するためにランタイムによって実行され、そして構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０は、プロデューサグラフからの出力をグラフ表示し且つプロデューサグラフと対話できるようにする。より詳細には、構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０は、次のものを含む。即ち、１）レイアウトの構成及び選択されたプロデューサ出力のマッピング（例えば、使用すべきスクリーンのエリア、データをどのように表示するか、等）を許すための構成及びマッピンググラフィックユーザインターフェイスモジュール８４４；及び２）構成されたレイアウトをレンダリングしそしてプロデューサ出力のオーバーライドを許す（その結果、グローバルな実行コマンドを通してプロデューサグラフの更新が生じる）ためのレンダリング及び対話グラフィックユーザインターフェイスモジュール８６４。構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０は、ランタイム８１０を書く同じエンティティにより生成されてもよいし、そうでなくてもよいことを理解されたい。
図８Ｂは、本発明の一実施形態によりアプリケーションがエンドユーザに与えられるところの第２の例示的フレームワークを示すブロック図である。図８Ｂは、次のことを除いて、図８Ａと同じである。即ち、１）スタンドアローン使用８３０が存在しない；２）オブジェクト指向のソースコード８２０がサーバー使用８３２に与えられ、一方、クライアントコード８２４は、クライアント使用８３４に与えられない；３）構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０は、サーバー使用８３２に与えられ、クライアント使用８３４には与えられない；そして４）一般的な構成可能なインタラクティブなプロデューサ出力レイアウトクライアントインターフェイス８８５がクライアント使用８３４に与えられる。この構成可能なインタラクティブなプロデューサ出力レイアウトクライアントインターフェイス８８５は、構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０とインターフェイスするのに使用される。
使用するフレームワークに関わりなく、本発明の一実施形態では、プロデューサグラフ指向のプログラミングフレームワークは、プロデューサ依存性宣言と共に描かれていないプログラムとインターフェイスする能力を与える。プロデューサ依存性宣言と共に描かれていないプログラムとインターフェイスするこの能力は、１）発呼部分（プロデューサグラフ指向のプログラミングに基づいて書かれないグラフィックユーザインターフェイスのような）；及び２）被呼部分（プロデューサグラフ指向のプログラミングに基づいて書かれない外部データソースのような）を含む。発呼部分は、クライアントコードを通して、プロデューサグラフ指向のプログラミングコマンドを発行することができる。被呼部分は、被呼部分を取り巻くプロデューサ（「ラッピングプロデューサ」と称される）の一部分として具現化される。被呼部分を実行すると（例えば、データソースからデータを読み取るか又は外部データソースにおけるデータの変化にサブスクライブすると）、インスタンスの変更をトリガーすることができる。これらの変化は、ラッピングプロデューサのコードにおいてプロパティセットメソッドをコールすることにより生じ得る。ゲットプロパティプロデューサ（ゲッター）は、外部データソースに生じる変化によりトリガーされるインスタンス変更がプロデューサグラフを通して適切に伝播されるよう保証するために、これらラッピングプロデューサに対する依存性を有するようにされる。上述したように、異なる実施形態は、プロパティプロデューサに関してプロデューサ依存性を宣言するための１つ以上の仕方をサポートすることができる。例えば、シーケンスプロデューサ依存性をサポートする本発明の幾つかの実施形態では、ラッピングプロデューサに対する非サブスクリプション下方宣言シーケンスプロデューサ依存性を宣言するためにSequencingDependenciesを使用することができる。更に別の例では、シーケンスプロデューサ依存性及び非サブスクリプション上方宣言プロデューサ依存性をサポートする本発明の幾つかの実施形態では、プロパティプロデューサに対する非サブスクリプション上方宣言シーケンスプロデューサ依存性を生成するために、ラッピングプロデューサのプロデューサ依存性宣言にUpwardDependencies及び／又はWeaklyConstrainedDependenciesを入れることができる。
図８Ｃ−Ｆは、本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０のスクリーンショット及び使用を例示する。本発明の実施形態は、スプレッドシートの形態において現在プロデューサグラフ（１つ又は複数）の選択された出力で構成、マッピング及び対話を与える構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０を参照して説明するが、本発明の別の実施形態は、それに加えて又はそれとは別に、別の形態のサポートを与えるように具現化することもできる。更に、スプレッドシートの形態で構成、マッピング及び対話を遂行する例示的な仕方を、幾つかの実施形態に基づいて説明するが、本発明の他の実施形態は、これらのオペレーションを、異なるインターフェイス及び／又は異なるスクリーンレイアウトを伴う別の仕方で遂行することができる。更に、スプレッドシートは、スプレッドシートに関連した既知のファンクションのいずれもサポートすることができる（例えば、カラー選択、フォント選択、バー／パイ／ラインチャート、ピボットテーブル、セービングレイアウト、ローディングレイアウト、等）。
図８Ｃ−Ｄは、本発明の一実施形態による自由セル選択のスクリーンショット及び使用を例示し、一方、図８Ｅ−Ｆは、本発明の一実施形態によるテーブル生成のスクリーンショット及び使用を例示している。図８Ｃ−Ｆの各々は、スクリーンの頂部に沿ったメニューバー８５０と、スクリーンの左側に沿った現在プロデューサグラフにおけるプロデューサ及びそれらの出力のクラス（ゲットプロパティメソッドを伴う）のリスト８５２と、スプリットシート状のレイアウトでスクリーンの残りを埋める構成及びマッピングビューア８５４とを含む。更に、図８Ｃ−Ｆは、リスト８５２におけるゲットプロパティメソッドを伴うクラスの、次の例示的リストも示している。１）クラス「個人(PERSON)」；２）名(FIRSTNAME)(例えば、ストリング)、氏(LASTNAME)(例えば、ストリング)、性別(GENDER)(例えば、ストリング)、家の住所(HOMEADDRESS)(クラス「住所(ADDRESS)」のインスタンス)、職場の住所(PROFESSIONALADDRESS)(クラス「住所」のインスタンス)、誕生日(DATEOFBIRTH)(例えば、日付)、及び年齢(AGE)(例えば、整数)；３）クラス「住所」；及び４）都市(CITY)(例えば、ストリング)、州(STATE)(例えば、ストリング)、郵便番号(ZIPCODE) (例えば、ストリング)を含むクラス「住所」のゲットプロパティメソッド。従って、現在プロデューサグラフは、クラス「個人」及び「住所」のプロデューサと、出力がクラス「個人」及び「住所」のものであるプロデューサとを含む。又、ゲットプロパティメソッド「年齢」は、ゲットプロパティメソッド「誕生日」の出力に基づいて年齢を計算し、従って、ゲットプロパティメソッド「年齢」からインスタンス生成されるプロデューサは、ゲットプロパティメソッド「誕生日」からインスタンス生成されるプロデューサに依存する。
図８Ｃ−Ｄは、ビューアの第１列の連続セルに入れられた次の自由テキスト、即ち「顧客(CUSTOMER」、「名(FIRST NAME)」、「氏(LAST NAME)」、「誕生日(DATE OF BIRTH)」及び「年齢(AGE)」を示し、一方、図８Ｅ−Ｆは、次のもの、即ち、１)ビューアの第１行に入れられた自由テキスト「顧客リスト(CUSTOMER LIST」；及び２)ビューアの第２行の連続セルに入れられた自由テキスト「名(FIRST NAME)」、「氏(LAST NAME)」、「誕生日(LAST NAME)」及び「年齢(AGE)」を示している。
図８Ｃは、本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０での自由セル選択の例示的スクリーンショット及び使用を示す。図８Ｃは、クラス「個人」及びクラス「個人」の選択されたゲットプロパティメソッドの、ビューアの異なるクラスへのマッピング８５６のセットを示す。より詳細には、クラス「個人」は、自由テキスト「顧客」の右のセルへマップされる。このアクションの一部分として、本発明の幾つかの実施形態は、ユーザが多数のサポートされたフィルタの１つから選択するように促す（フィルタ選択８５８として示す）（例えば、リストをドロップダウンし、スクロール矢印を形成し、等）。これらのフィルタは、選択されたクラスのプロデューサの１つ以上のインスタンスキー、又は出力クラスが選択されたクラスであるプロデューサの１つ以上のインスタンスキーを選択できるようにする。本発明の幾つかの実施形態は、多数のフィルタをサポートするが、本発明の他の実施形態は、１つにデフォールトする（そしてユーザが異なるものを選択すべきかどうか選べるようにする）か、又は１つのみをサポートして、フィルタ選択８５８を行う必要がないようにする。又、マッピング８５６は、クラス「個人」のゲットプロパティメソッド「名」、「氏」、「誕生日」及び「年齢」が、各々、対応する自由テキストをもつセルに隣接するセルへマップされることも示す。このようなマッピングは、ドラグ及びドロップ、ＧＵＩフィールドへのタイプイン、等を含む多数の良く知られた技術で行うことができる。
図８Ｄは、本発明の一実施形態により構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０での自由セル選択の別の例示的スクリーンショット及び使用を示す。図８Ｄは、インスタンス選択８５４を許すためにクラス「個人」がマップされたセルを示している。より詳細には、このセルに使用されるフィルタに基づいて、ユーザには、クラス「個人」のプロデューサのインスタンスキー（１つ又は複数）及びクラス「個人」を生成するプロデューサのインスタンスキーを含むリストからクラス「個人」のインスタンスを選択する機会が与えられる。クラス「個人」のインスタンス（又は単一インスタンスの存在）を選択すると、クラス「個人」のゲットプロパティメソッドがマップされたセルに、そのインスタンスの対応ゲットプロパティメソッドの出力が自動的にポピュレートされる。クラス「個人」のインスタンスに基づくテーブルのこのようなポピュレーションが８５８で示されている。図８Ｄの例では、クラス「個人」のゲットプロパティメソッド「名」、「氏」、「誕生日」及び「年齢」がマップされたセルに、JOHN、SMITH、7/20/1990及び１６が各々ポピュレートされる。
又、図８Ｄは、ゲットプロパティメソッドがマップされたビューアのセルがオーバーライドされることも示している。例えば、図８Ｄは、ゲットプロパティメソッド「誕生日」がマップされたセルがオーバーライドされた場合に、出力が現在そのセルにポピュレートしているプロデューサの出力のオーバーライド、グローバルな実行コマンドのインボケーション（これは、ゲットプロパティメソッド「年齢」がマップされたセルに出力が現在ポピュレートしているプロデューサの再実行を生じさせる）、及びディスプレイの必要な更新を引き起こすことを示している。
図８Ｅは、本発明の一実施形態による構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０でのテーブル生成の例示的スクリーンショット及び使用を示す。図８Ｅは、自由テキスト「名(FIRST NAME)」、「氏(LAST NAME)」、「誕生日(DATE OF BIRTH)」及び「年齢(AGE)」を伴うセル（セルの周りを太い破線で示した）の真下に３行の垂直テーブルを識別するようにオペレーションが行われるゾーン及びオリエンテーション選択８６４を示している。本発明の異なる実施形態は、ユーザがこのオペレーションを多数の仕方（次のものを含む：１）マウスのような入力装置でエリアを選択し；及び２）複数のオリエンテーションがサポートされると仮定すれば、ポップアップメニューのようなインターフェイスで垂直、水平又はピボットテーブル間を選択する）で行うのをサポートすることができる。又、図８Ｅは、クラス「個人」の選択されたゲットプロパティメソッドの、ビューアの異なるセルへのマッピング８６６のセットも示している。より詳細には、マッピング８６６は、クラス「個人」のゲットプロパティメソッド「名」、「氏」、「誕生日」及び「年齢」が、それに対応する自由テキストを伴うセルの真下にあるセルへ各々マップングされることを示している。
図８Ｆは、本発明の一実施形態による構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０でのテーブル生成の別の例示的スクリーンショット及び使用を示す。マッピング８６６は、クラス「個人」のゲットプロパティメソッドがマップされたテーブルの列に、そのクラスのインスタンスの対応ゲットプロパティメソッドの出力を自動的にポピュレートさせる。クラス「個人」のインスタンスに基づくテーブルのこのようなポピュレーションが８６８で示されている。図８Ｄの例では、クラス「個人」のゲットプロパティメソッド「名」、「氏」、「誕生日」及び「年齢」がマップされた列に、次のデータ行がポピュレートされる。即ち、１）STEVE、COLLINS、7/20/1990及び１６；２）JENNIFER、ADAMS、7/20/1990及び１６；及び３）JOHN、SMITH、7/20/1985及び２１。
図８Ｄの場合と同様に、図８Ｅは、ゲットプロパティメソッドがマップされたビューアのセルがオーバーライドされることも示している。例えば、図８Ｆは、ゲットプロパティメソッド「誕生日」がマップされた列の第２行のセルがオーバーライドされた場合、出力が現在そのセルにポピュレートしているプロデューサの出力のオーバーライド、グローバルな実行コマンドのインボケーション（これは、ゲットプロパティメソッド「年齢」がマップされたセルに出力が現在ポピュレートしているプロデューサの再実行を生じさせる）、及びディスプレイの必要な更新を引き起こすことを示している。
図８Ｃ−Ｆは、構成及びマッピンググラフィックユーザインターフェイスモジュール８４２により発生されるスクリーンを例示している。レンダリング及びインタラクティブなグラフィックユーザインターフェイスモジュール８４６により発生されるスクリーンは、（ゲットプロパティメソッドを伴う）クラス８５２のリスト、構成及びマッピングビューア８５４が、表示される構成及びマッピングビューア８５４と同じ映像を含むレンダリング及びインタラクティブなビューア（図示せず）に置き換えられることを除いて、同じである（相違は、マッピング特徴がもはや得られないことである）。
例示的ランタイム配布スキーム
図９Ａ−Ｃは、本発明の一実施形態によるプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための種々のスキームを示す。これらの配布スキームは、例示に過ぎず、従って、本発明の範囲内で他のスキームも考えられる。
図９Ａは、本発明の一実施形態によるプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第１のスキームを示すブロック図である。図９Ａにおいて、オブジェクト指向のソースコード９０５（プロデューサ依存性宣言を含む）が、プロデューサグラフ指向のプログラミングサポートを伴うランタイム９１０の上に示されており、このランタイムは、クラスローディング、ダイナミッククラスインスタンス生成、ダイナミック単一メソッドインボケーション、及びクラス／メソッドイントロスペクションを伴うランタイム９１５の上にあり、そしてこのランタイムは、オペレーティングシステム９２０の上にある。図９Ａにおいて、ランタイム９１０は、ランタイム９１５と共に働く。ランタイム９１０をランタイム９１５と共に働かせるのに多数のメカニズムを使用できるが、一例として、メタデータファシリティについて説明する。メタデータファシリティは、付加的な情報をソースコードに追加することができ、この情報は開発ツールにより使用される。例えば、Ｊａｖａ仕様のメタデータファシリティは、開発ツール、配備ツール又はランタイムライブラリーにより特殊な仕方で処理されねばならないことを指示する特殊な属性を有するとしてフィールド、メソッド及びクラスにアノテーション付けするためのＡＰＩを定義する（Ｊａｖａ仕様要求１７５）。この例では、オブジェクト指向のソースコード９０５をプログラミングするプログラマーは、プロデューサ依存性宣言の形態でメソッドにアノテーションを追加する。これらアノテーションは、ランタイム９１５によりランタイム９１０へハンドオフされるので、ランタイム９１０は、プロデューサ依存性宣言のシンタックスを指令する。図９Ａにおいて、ランタイム９１０及び９１５は、異なる組織によって開発され及び／又は配布されてもよい。
図９Ｂは、本発明の一実施形態によるプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第２のスキームを示すブロック図である。図９Ｂにおいて、オブジェクト指向のソースコード９２５（プロデューサ依存性宣言を含む）がランタイム（クラスローディング、ダイナミッククラスインスタンス生成、ダイナミック単一メソッドインボケーション、及びクラス／メソッドイントロスペクション、並びにプロデューサグラフ指向のプログラミングサポートを伴う）９３０の上に示されており、そしてこのランタイムは、オペレーティングシステム９３５の上にある。図９Ａとの比較において、ランタイム９１０及び９１５が単一のランタイム９３０へと合成されている。この合成の結果として、ランタイム９３０は、プロデューサ依存性宣言のシンタックスを指令する。従って、オブジェクト指向のソースコード９２５をプログラミングするプログラマーは、要求されるシンタックスにプロデューサ依存性宣言を追加する。
図９Ｃは、本発明の一実施形態によるプロデューサグラフ指向のプログラミングサポートを伴うランタイムを配布するための第３のスキームを示すブロック図である。図９Ｃにおいて、オブジェクト指向のソースコード９４０（プロデューサ依存性宣言を含む）がオペレーティングシステムランタイム（クラスローディング、ダイナミッククラスインスタンス生成、ダイナミック単一メソッドインボケーション、及びクラス／メソッドイントロスペクション、並びにプロデューサグラフ指向のプログラミングサポートを伴う）９４５の上に示されている。図９Ｂと比較して、ランタイム９２０及びオペレーティングシステム９３５が単一エンティティへと合成されている。この合成の結果として、オペレーティングシステムランタイム９４５は、プロデューサ依存性宣言のシンタックスを指令する。従って、オブジェクト指向のソースコード９４０をプログラミングするプログラマーは、要求されるシンタックスにプロデューサ依存性宣言を追加する。
ランタイムが、クラスローディング、ダイナミッククラスインスタンス生成、ダイナミック単一メソッドインボケーション、及びクラス／メソッドイントロスペクションを有するような実施形態を説明したが、別の実施形態は、より多くの又はより少ない特徴を含んでもよい（例えば、インスタンスクローンニング、ダイナミックプロキシー、プリミティブ形式変換、等）。
例示的効果
本発明の一実施形態においては、手動インボケーションシーケンスコードを使用せずに適切なインスタンスを使用して（ここで、適切なインスタンスは、引数として使用すべきインスタンス、インスタンスメソッドにより使用されるべきインスタンス、及びクラスメソッドにより使用されるメタクラスインスタンスを含む）メソッドインボケーションシーケンスを指定する仕方としてメソッドに対してプロデューサ依存性が宣言された。実際に、手動インボケーションシーケンスコードの幾つか又は全部を発生する作業は、次のものに置き換えられる。即ち、１）プロデューサ依存性宣言を書き込むためにアプリケーションプログラマーによって行われる作業；及び２）プロデューサグラフ（１つ又は複数）を発見及び構築し、そしてこれらプロデューサグラフ（１つ又は複数）のプロデューサを実行するためにランタイムにより行われる作業。換言すれば、手動インボケーションシーケンスコードに以前に含まれていたロジックは、プロデューサ依存性宣言に基づき、ランタイム中に、ランタイムにより発見することができる。従って、プロデューサ依存性宣言は、どんな引数を伴うどんなインスタンスのどんなメソッドを同期のためにいつ実行すべきかランタイムへ通知する。ランタイムを書くための努力は、比較的多大であるが、ランタイムに対して書かれたオブジェクト指向のアプリケーションを実行するのに使用できるという点で、一度書くだけでよく、対照的に、典型的なアプリケーションの場合、プロデューサ依存性宣言を書くための努力は、手動インボケーションシーケンスコードを書くことに比べて比較的僅かである。
プログラミングミステークの減少
プロデューサグラフ指向のプログラミングは、典型的に、手動インボケーションシーケンスコードのデバッグ及び／又は性能同調に関するコストを減少する。これは、少なくとも、アプリケーションプログラムのインフラストラクチャーが、概念的に、特定入力に対して動作するオブジェクトの変換メソッドの非公式化グラフのセットである（オブジェクトに関連した１つのメソッドの出力は、別のメソッドへの入力となり、等々）という理由で言えることである。プロデューサ依存性宣言、及びプロデューサグラフ指向のプログラミングサポートを伴うランタイムは、これらのグラフをプロデューサグラフとして公式化する。従って、データが変化する機会のたびに、アプリケーションプログラマーは、適切なインスタンスの適切な変換メソッドを適切な入力と共に適切な順序でインボークさせるために、その作用を考慮して手動インボケーションシーケンスコードを書き込む必要がない。換言すれば、データが変化する機会のたびに、アプリケーションプログラマーは、どのグラフが影響を受けるか、及びそれらグラフ内のインスタンスのどの変換メソッドが影響を受けるか考慮する必要がない。むしろ、自動プロデューサグラフ発生モジュールがプロデューサグラフを発見及び構築し、そしてプロデューサグラフ実行モジュールが、データの変化を反映するように、必要に応じてプロデューサグラフを再実行する。この自動化は、次のようなミステークを回避する上でアプリケーションプログラマーの助けとなる。１）適切なインスタンスの適切な変換メソッドを間違った順序でインボークし、２）グラフにおけるインスタンスの１つ以上の要求された変換メソッドをあるデータの変化に応答してインボークさせるためのコマンドを入れ忘れ、３）あるデータの変化に応答してインスタンスの不必要な変換メソッドをインボークさせるコマンドを含ませる（例えば、データの変化により影響されるグラフの部分でないインスタンスの変換メソッドをインボークするコマンドを含ませ；データの変化により影響されるグラフの部分であるが、それ自身は影響のないインスタンスの変換メソッドをインボークするコマンドを含ませ；等々）。
同期
上述したように、実行中にプロデューサ出力をキャッシュ記憶することで、同期をとることができる。従って、オブザーバーパターンとの比較に関して、プロデューサ依存性宣言は、プロデューサグラフ指向のプログラミングサポートを伴うランタイムに依存性を通知し、そしてランタイムは、どんなプロデューサがいつコールバックするか決定する。
結果を完全に説明する能力
本発明の一実施形態では、ドリル／ビュー(drilling/viewing)モジュール（図示せず）がランタイムの一部分として含まれる。このドリル／ビューモジュールは、エンドユーザによる対話を通して、プロデューサグラフまで掘削して（根ノードからプロデューサグラフまでウォーキングして）、プロデューサグラフの種々のプロデューサの出力を見ることができるようにするグラフィックユーザインターフェイスをなす。これは、エンドユーザが、データ値及び依存性（依存性決定プロデューサにより返送された）を含めて、問題とするプロデューサの出力に貢献した種々の出力を見ることができるようにする。更に、本発明の一実施形態では、このドリル／ビューモジュールは、エンドユーザが、プロデューサのメソッド内のコード、プロデューサのインスタンスの値、及び／又はプロデューサのクラスのコンテンツを見る能力を与える。
従って、ドリル／ビューモジュールは、デバッグ、出力の説明、等を含む種々の後処理アクティビティを与える。
例示的な実際のアプリケーション／技術的効果／産業上の利用性
本発明の異なる態様及び実施形態には種々の例示的な実際のアプリケーションがある。例えば、ランタイムは、アプリケーションプログラムの実行の一部分として、マシン記憶媒体から情報を検索し（例えば、プロデューサ依存性宣言を含むオブジェクト指向のソースコードにアクセスし）、マシン記憶媒体に情報を記憶し（例えば、プロデューサグラフ（１つ又は複数）構造、等に類似したデータ構造を記憶し）、ハードウェア処理リソースを動作させ、問題とするプロデューサ（１つ又は複数）の出力を与え（例えば、グラフィックユーザインターフェイスを通して、マシン記憶媒体への記憶、送信、等）、等々を行う。ある意味においては、前処理アクティビティは、このようなアプリケーションプログラムの書き込み及び／又はデータの付与を含み（このデータは、多数の物理的及び／又は実際的なアイテム、例えば、金融的な値、地理的な値、気象学的な値、保険的な値、統計学的な値、物理学的な尺度、マシン状態値、等を表す）、一方、後処理アクティビティは、結果の付与を含む（この結果は、多数の物理的及び／又は実際的なアイテム、例えば、金融的な分析、地理的な分析、気象学的な分析、保険的な分析、統計学的な分析、工業的な尺度、マシン制御情報、等）。特定の例として、後処理アクティビティは、次のものにより与えることができる。１）ランタイムにより発生される現在プロデューサグラフ（１つ又は複数）の表現をグラフ表示するための図１０のプロデューサグラフビューアモジュール１０６２；及び／又は２）プロデューサグラフからの出力をグラフ表示しそしてそれと対話するための構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０（図１０の構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール１０８５も参照されたい）。
別の例として、ランタイムにより実行されたとき、プロデューサ依存性宣言それ自体を伴うアプリケーションプログラムは、物理的／実際的なアイテムを表し、そして上述したオペレーションを生じさせる。特定例として、これらのプロデューサ依存性宣言は、ランタイムによる実行に応答してデータ構造をマシン記憶媒体に形成するようにさせる。又、プロデューサ依存性宣言は、アプリケーションプログラムと共にマシン記憶媒体に記憶されそしてそこから検索される。更に、これらプロデューサ依存性宣言は、プロデューサ間の関係を表し、一方、プロデューサは、実行されるべきオペレーション（メソッド）及びインスタンスを表す。オブジェクト指向のプログラミングにおけるインスタンスは、物理的及び／又は実際的アイテムを表現するのに使用でき、一方、プロデューサは、それらの表現に対して遂行されるべきオペレーションを表現する。
別の例として、１つ以上のアプリケーションプログラム及びランタイムのセットは、外国為替、総資産、利子、信用、インフレーション、物価、及びクロスアセット複合商品をカバーするクロスアセットリスク管理ソフトウェアを具現化する。これらの商品は、現金及び物理的にプレーンなバニラ商品から、エキゾチックで複雑なデリバティブ商品までの範囲である。又、これらの商品に対する数学的評価モデルのセット、並びにそれらに関連したマーケットデータ、支払及び会計エントリー発生ルーチン及びそれらに関連した観察可能な校正モデル及びそれに関連した生の入力も含まれる。
別の例として、１つ以上のアプリケーションプログラム及びランタイムのセットは、ワードプロセッサ、スプレッドシート、通信／ｅ−メールソフトウェア、フォトビューイングソフトウェア、ウィルススキャンソフトウェア、メディアプレーヤ、データベースサーバー、ゲーム、工業用アプリケーション、コンピュータ支援型設計ツールアプリケーション、及び／又はオペレーティングシステムを具現化することができる。もちろん、アプリケーションプログラムは、種々の他のタスクを遂行するように具現化することもできる。
例示的具現化
例示として、依存性、ダイナミックな依存性（コンティンジェント(contingent)依存性及びサブスクリプション(subscription)依存性を含む）、ショートカット宣言依存性及び非ショートカット宣言依存性に対する明示的依存性決定プロデューサ、ショートカット宣言依存性に対するオンザフライ依存性決定プロデューサ、クラスキー、インスタンスキー、メソッドキー、プロデューサオーバーライド／非オーバーライドコマンド（セットコマンドの形式である）、及びグローバル実行コマンドをサポートする本発明の実施形態について説明する。更に、これら実施形態は、任意であるが、プロデューサグラフのインタラクティブなビューアモジュール及び増分的実行もサポートする。もちろん、本発明の別の実施形態は、より多くの特徴、より少ない特徴及び／又は異なる特徴を具現化することができる。
図１０は、本発明の一実施形態による例示的具現化のブロック図である。図１０において、破線の分割線１０００は、ランタイムクライアント１００２を、プロデューサグラフ指向のプログラミングサポートを伴うランタイム１００４から分離している。
ランタイムクライアント１００２の論理的実行フローは、ブロック１０１０、１０２０、１０２５、１０３０及び１０３５を備え、そしてプロデューサグラフ指向のプログラミングサポートを伴うランタイム１００４は、対応するブロック１０９５、１０９８、１０４０、１０４５、及び１０７０を各々備え、一方、矢印付きの実線は、ランタイムクライアント１００２の論理的実行フローのブロック１０３５から、プロデューサグラフ指向のサポートを伴うランタイム１００４のブロック１０７０への直接的因果関係を表し、矢印付き点線は、ランタイムクライアント１００２のブロック１０１０、１０２０、１０２５及び１０３０から、プロデューサグラフ指向のプログラミングサポートを伴うランタイム１００４のブロック１０９５、１０９８、１０４０及び１０４５への因果関係を示している。本発明の実施形態に基づき、これら後者の因果関係は、直接的でも、間接的でもよい。例えば、図６と同様に、コマンドログ（図示せず）及び／又はオーバーライドログ１０４７の使用による任意の間接的因果関係を使用してもよい。更に、ブロック１０９５及び１０９８は、本発明の実施形態に基づき異なるブロックの一部分であるのも任意であるから、破線にされている（例えば、ブロック１０９５は、ブロック１０９８の一部分でよく、ブロック１０９８は、ブロック１０４０の一部分でよく、ブロック１０９５及び１０９８は、ブロック１０４０の一部分でよい）。同様に、ブロック１０４５は、本発明の実施形態に基づき異なるブロックの一部分であるのも任意であるから、破線にされている（例えば、ブロック１０４５は、ブロック１０７０の一部分でもよい）。
図１０において、ランタイム１００２は、ビジネスロジックを含むクラス定義１０１０を備え、これは、データ１０１２、メソッド１０１４、プロデューサ依存性宣言１０１６、及び任意のクラスキー１０９０を有する。クラス定義１０１０は、オブジェクト指向のプログラミング言語のクラスであり、従って、データ及びメソッド１０１４に対する定義を含む。更に、これらのクラス定義１０１０は、上述したように、メソッド１０１４に対するプロデューサ依存性宣言１０１６を含む。更に、本発明の一実施形態では、各クラスは、追跡のためのクラスキー１０９０を有する。
ランタイム１００４の新クラスモジュール１０９５は、クラス定義１０１０をロードし、イントロスペクトする（例えば、新クラスコマンドに応答して）。このようにロードしてイントロスペクトすることは、最適化の目的でクラスを選択的にロードするためのものを含めて、多数の良く知られた技術又は将来開発される技術を使用して行うことができる。新クラスモジュール１０９５によりクラスをロードすることは、ランタイム１００４のクラス１０５４で示されている。クラス１０５４をロードしてイントロスペクトする一部分として、新クラスモジュール１０９５は、クラス１０５４におけるメソッド及びプロデューサ依存性宣言１０５６により示されたように、プロデューサ依存性宣言１０１６もロードし、イントロスペクトする。又、新クラスモジュール１０９５は、クラスキーを使用してクラスを追跡するのに使用されるクラス追跡構造１０９２も維持する。従って、クラス追跡構造１０９２は、クラスキーとクラス１０５４へのリファレンスとの間の対応性を維持する。更に、新クラスモジュール１０９５は、メソッドキーを使用してメソッドを追跡するのに使用されるメソッド追跡構造１０５８も維持する。従って、メソッド追跡構造１０５８は、メソッドキーとメソッドへのリファレンスとの間の対応性、並びにプロデューサ依存性宣言に関する情報を維持する。
又、ランタイムクライアント１００２は、インスタンスキーを伴うインスタンスインスタンス生成コマンド１０２０も備えている。ランタイム１００４の新インスタンスモジュール１０９８は、（例えば、新インスタンスコマンドに応答して）インスタンスキーを伴うインスタンスインスタンス生成コマンド１０２０により指定されたインスタンスをインスタンス生成する。このようにインスタンスをインスタンス生成することは、最適化の目的でインスタンスを選択的にインスタンス生成するためのものを含めて、多数の良く知られた技術又は将来開発される技術を使用して行うことができる。インスタンスをこのようにインスタンス生成する一部分として、新インスタンスモジュール１０９８は、クラス１０５４から適切なクラスにアクセスするために、クラスキーを使用してクラス追跡構造１０９２にアクセスする。新インスタンスモジュール１０９８によりインスタンスをインスタンス生成することは、ランタイム１００４のインスタンス１０５２によって示される。又、新インスタンスモジュール１０９５は、インスタンスキーを使用してインスタンスを追跡するのに使用されるインスタンス追跡構造１０６５も維持する。従って、インスタンス追跡構造１０６５は、インスタンスキーとインスタンス１０５２へのリファレンスとの間の対応性を維持する。上述したように、新クラスモジュール１０９５は、クラス１０５４が、個別の新クラスコマンドではなく、インスタンスのインスタンス生成コマンド１０２０に応答してインスタンス生成されるという点で、新インスタンスモジュール１０９８の一部分であってもよい。
又、ランタイムクライアント１００２は、プロデューサキーを伴うプロデューサインスタンス生成コマンド１０２５も備えている。ランタイム１００４の自動プロデューサグラフ発生モジュール１０４０は、プロデューサキーを伴うプロデューサインスタンス生成コマンド１０２５により指定されたプロデューサをインスタンス生成する（例えば、問題とするプロデューサの現在セットを指定する新プロデューサコマンドに応答して）。更に、自動プロデューサグラフ発生モジュール１０４０は、上述した問題とするプロデューサの現在セットに応答してプロデューサグラフ（１つ又は複数）を発見し、構築し、及び任意なこととして、解明もする。本発明の一実施形態では、プロデューサキーは、クラスキー、インスタンスキー、及びメソッドキーで構成される。プロデューサのこのインスタンス生成の一部分として、自動プロデューサグラフ発生モジュール１０４０は、１）クラス１０５４から適切なクラスにアクセスするために、クラスキーを使用してクラス追跡構造１０９２にアクセスし；２）インスタンス１０５２から適切なインスタンスにアクセスするために、インスタンスキーを使用してインスタンス追跡構造１０６５にアクセスし；そして３）適切なプロデューサ依存性宣言ステートメントにアクセスするために、メソッドキーを使用してメソッド追跡構造にアクセスする。プロデューサキーを伴うプロデューサインスタンス生成コマンドにより指定されたプロデューサをインスタンス生成し、発見されたプロデューサをインスタンス生成し、そしてプロデューサグラフを構築することが、ランタイム１００４のプロデューサグラフ（１つ又は複数）構造１０６０で示されている。従って、本発明の一実施形態では、プロデューサキーを伴うプロデューサインスタンス生成コマンドにより識別されたプロデューサキー、及びプロデューサグラフ発生を通して発見されたプロデューサキーは、現在プロデューサグラフ（１つ又は複数）を表す追加情報と共に、プロデューサグラフ（１つ又は複数）構造１０６０に記憶される。
上述したように、ブロック１０９５及び１０９８は、ブロック１０４０の一部分でもよく、従って、どのクラス、インスタンス及びプロデューサをロード／インスタンス生成のためにどんなプロデューサにより駆動するかの判断は、現在プロデューサグラフ（１つ又は複数）において行われる。本発明のこのような実施形態では、クラス、インスタンス、及びプロデューサのロード／インスタンス生成が最適化され、プロデューサ中心となる。
又、ランタイムクライアント１００２は、プロデューサ出力オーバーライド／非オーバーライドコマンドを含むデータ準備コマンド１０３０も備えている。オーバーライド／非オーバーライドコマンドは、オーバーライド／非オーバーライドされるべきプロデューサのプロデューサキーと、オーバーライドされるときのオーバーライド値とを含む。ランタイム１００４のオーバーライドプロデューサ出力モジュール１０４５は、プロデューサオーバーライド／非オーバーライドコマンドにより指定されたプロデューサをオーバーライド／非オーバーライドさせる。この因果関係は、間接的でも、直接的でもよい。
間接的な因果関係の場合に、オーバーライドプロデューサ出力モジュール１０４５は、プロデューサグラフ実行モジュール１０７０によって消費するためにオーバーライドログ１０４７をポピュレートする。直接的な因果関係の場合には、オーバーライドプロデューサ出力モジュール１０４５は、プロデューサグラフ（１つ又は複数）構造１０６０のプロデューサ出力キャッシング１０９７及びインスタンス１０５２にアクセスする。より詳細には、オーバーライドプロデューサ出力モジュール３９０を参照して述べるように、一実施形態において、プロデューサは、プロパティプロデューサ又はメソッドプロデューサとして分類することができ、従って、オーバーライドプロデューサ出力モジュール１０４５は、オーバーライドされたプロパティプロデューサのためのオーバーライドプロパティプロデューサ出力モジュール（図示せず）と、オーバーライドされたメソッドプロデューサのためのオーバーライドメソッドプロデューサ出力モジュール（図示せず）とを含み、プロパティメソッドをオーバーライドすると、オーバーライドされた値を、プロデューサグラフ（１つ又は複数）構造１０６０のプロデューサ出力キャッシング１０９７に記憶させると共に、インスタンス１０５２の適切なインスタンスに記憶させ、一方、メソッドプロデューサをオーバーライドすると、オーバーライドされた値をプロデューサ出力キャッシング１０９７に記憶させる。
本発明の一実施形態では、プロデューサは、それが一部分であるところのプロデューサグラフが最初に実行されるまでオーバーライドされない（従って、プロデューサは、問題とするプロデューサとして指定される結果、又は自動プロデューサグラフ発生モジュール１０４０により発見される結果として予めインスタンス生成される）。しかしながら、図１０に示す実施形態では、プロデューサは、初期実行の前に、プロデューサオーバーライドコマンドでインスタンス生成されオーバーライドされることにより、オーバーライドすることができる。このようなオーバーライドされたプロデューサは、通常、最終的に、発見プロセスを通してプロデューサグラフの一部分となる（例えば、ダイナミック依存性が解明されるとき）。本発明のある実施形態では、このデータ準備は、他の形式のセットコマンドも含み得る。オーバーライドプロデューサ出力モジュール１０４５は、本発明の別の実施形態では存在しないことがあるので、破線のボックスとして示されている。
又、プロデューサグラフ（１つ又は複数）構造１０６０は、任意であるが、増分的実行をサポートする本発明の幾つかの実施形態に対して増分的実行マーキング１０８０も含む。図３Ｂの増分的実行マーキング３８２を参照して上述したように、増分的実行マーキング１０８０は、初期実行のものを越えた実行においてプロデューサグラフ（１つ又は複数）の増分的実行を助けるのに使用される。増分的実行マーキング３８２を使用する本発明の異なる実施形態は、それらを異なる仕方で使用する。例えば、コマンドログを有する本発明の１つのこのような実施形態では、どのプロデューサが追加され及び／又は変更されるか追跡するのにログが使用され、そして増分的実行マーキング３８２は、影響を受けるプロデューサ（変更又は追加されたプロデューサの先祖であり、従って、それらに依存する）をマークするのに使用される。別の例として、コマンドログをもたない本発明の１つのこのような実施形態では、増分的実行マーキング３８２は、追加又は変更されるプロデューサ、並びに変更又は追加されるプロデューサの先祖である（従って、それらに依存する）プロデューサをマークするのに使用される。別の例として、コマンドログをもたない本発明の１つのこのような実施形態では、プロデューサの変更及び追加が直ちに行われ、そして増分的実行マーキング３８２は、変更又は追加されるプロデューサの先祖である（従って、それらに依存する）プロデューサをマークするのに使用される。増分的実行をサポートしそして増分的実行マーキングを使用する本発明の実施形態を説明したが、本発明の他の実施形態は、増分的実行マーキングを使用しない増分的実行をサポートする（例えば、どのプロデューサが追加又は変更されたか追跡するのにコマンドログが使用され、そして実行スタートプロデューサのリストが実行スタートログに維持され、ここで、プロデューサグラフ実行モジュール１０７０は、実行スタートプロデューサからスタートし、そしてプロデューサグラフの先祖を最上位まで上るように働き、例えば、これに限定されないが、本発明のこの実施形態は、図１５−２５を参照して、以下に説明する。
又、ランタイムクライアント１００２は、グローバル実行コマンド１０３５を含む。ランタイム１００４のプロデューサグラフ実行モジュール１０７０は、プロデューサグラフ（１つ又は複数）を実行する。従って、プロデューサグラフ実行モジュール１０７０は、プロデューサ出力キャッシング１０９７を変更し（プロパティプロデューサ及びメソッドプロデューサの場合に）、増分的実行マーキング１０８０（もしあれば）を使用し、そしてインスタンス１０５２のデータを変更する（プロパティメソッドの場合に）。 プロデューサグラフのプロデューサを実行するための種々の技術が、上述され、ここに適用することきる。例えば、コマンドログが具現化される実施形態では、コマンドログが消費され、次いで、プロデューサグラフ（１つ又は複数）が実行される。更に、未解明の依存性の可能性をサポートする本発明の実施形態では、プロデューサグラフ実行モジュール１０７０は、ダイナミック依存性モジュール１０７５を含み、これは、自動プロデューサグラフ発生モジュール１０４０をインボークすることができる。
又、図１０は、プログラマー／ユーザが、プロデューサグラフ（１つ又は複数）構造のプロデューサグラフ（１つ又は複数）及びプロデューサ出力を見ることができるようにするメカニズム（例えば、グラフィックユーザインターフェイス）を与える任意のプロデューサグラフビューアモジュール１０６２も示している。更に、図１０は、構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール８４０を表すグラフィックユーザインターフェイス（ブロック１０３０及び１０３５のダイナミックインボケーションを含む）を与えるための任意の構成可能なインタラクティブなプロデューサ出力レイアウトグラフィックユーザインターフェイスモジュール１０８５も示している。
コマンドログを使用する本発明の実施形態では、異なるトリガーを使用して、異なるアクションをトリガーすることができる。例えば、プロデューサインスタンス生成コマンドは、明示的コマンド（ロギング開始及びロギング終了）、明示的グローバル実行コマンド（スタート時及び各明示的グローバル実行コマンドの後にロギングが自動的にスタートし、そしてそれに続く明示的グローバル実行コマンドに応答して各ログが処理される）、明示的データ準備コマンド、等に応答して、ログされ、バッチ処理される。同様に、データ準備コマンドは、明示的グローバル実行コマンド、第１ゲットコマンド、各ゲットコマンド、等に応答して、ログされ、バッチ処理される。
例示的追跡構造
図１１Ａ−Ｄは、本発明の一実施形態による図１０のデータ構造の例示的コンテンツを示すブロック図である。図１１Ａ−Ｄは、これらのデータ構造をテーブルとして示すが、適当なデータ構造（例えば、ハッシュマップ、セット、リスト）を使用できることを理解されたい。
図１１Ａは、本発明の一実施形態による図１０のクラス追跡構造１０９２の一例を示すブロック図である。図１１Ａにおいて、クラスキー列１１１０及びクラスリファレンス列１１１５は、各々、ロードされるクラスに対するクラスキー及びその対応リファレンスを記憶するように示されている。
図１１Ｂは、本発明の一実施形態による図１０のインスタンス追跡構造１０６５の一例を示すブロック図である。図１１Ｂにおいて、インスタンスキー列１１２０及びインスタンスリファレンス列１１２５は、各々、インスタンスに対するインスタンスキー及びその対応リファレンスを記憶するように示されている。インスタンスキーが全てのクラスにわたって独特である必要のない本発明の実施形態では、インスタンス追跡構造は、インスタンスのクラスに対するクラスキー又はリファレンスも含む。
図１１Ｃは、本発明の一実施形態による図１０のプロデューサグラフ（１つ又は複数）構造１０６０の一例を示すブロック図である。図１１Ｃにおいて、クラスリファレンス列１１３５、インスタンスリファレンス列１１４０、及びメソッドリファレンス列１１４５は、現在プロデューサグラフ（１つ又は複数）の現在プロデューサを作り上げるリファレンスを各々記憶するように示されている。これらのリファレンスは、種々の形態をとり得る。例えば、これらの列は、クラス１０５４（或いは１０９２）、インスタンス１０５２（或いは１０６５）、及びメソッド１０５６（或いは１０５８）に対するリファレンスを記憶する。本発明の一実施形態では、これらの列はリファレンスを記憶するが、本発明の別の実施形態では、これら列の１つ以上がキーを記憶してもよい。
更に、図１１Ｃは、親プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１５０（各リンクに対して親プロデューサリファレンス及び依存性決定プロデューサリファレンスを含む）と、子プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１６０（各リンクに対して、子プロデューサリファレンス（１つ又は複数）、依存性決定プロデューサリファレンス、リンクモード、及びスティッキーリンクインジケータを含む）とを含む。各プロデューサは、０以上の子プロデューサリンクを列１１６０に有する。列１１６０の各子プロデューサリンクは、次のものを含む。１）プロデューサ依存性宣言によりプロデューサ依存性を表すためにプロデューサグラフ（１つ又は複数）構造の他の行に対するリファレンスである子プロデューサリファレンス（１つ又は複数）；２）プロデューサグラフ（１つ又は複数）構造の別の行に対するリファレンスであり且つ子リンクを生成した依存性決定プロデューサを表す依存性決定プロデューサリファレンス；３）プロデューサ依存性が引数、フィールド又はシーケンス依存性の結果であるかどうか識別するプロデューサ依存性形式（図７Ａ−Ｆに関する説明を参照）と、引数の場合には、プロデューサ依存性の引数ＩＤとを伴うリンクモード；及び４）リンクモードが、上方に宣言された依存性の結果（上方に宣言された依存性をサポートする本発明の実施形態における）であるか、又はスティッキーサブスクリプションの結果（スティッキーサブスクリプションをサポートする本発明の実施形態における）であることを指示し、且つこのプロデューサ（即ち、スティッキーインジケータを含む列の行に記憶されたプロデューサ）のプロデューサ引数依存性宣言を通して変更されてはならないスティッキーインジケータ。各プロデューサは、０以上の親プロデューサリンクを列１１５０に有してもよい。列１１５０の各親プロデューサリンクは、次のものを含む。１）別のプロデューサの子プロデューサリファレンスに基づくリファレンスを記憶して戻す親プロデューサリファレンス（即ち、このプロデューサに依存する親プロデューサを表すためのプロデューサグラフ（１つ又は複数）構造の別の行に対するリファレンス）；２）プロデューサグラフ（１つ又は複数）構造の別の行に対するリファレンスであり且つ親リンクを生成した依存性決定プロデューサを表す依存性決定プロデューサリファレンス。従って、リンクが生成されるときには、子プロデューサ行の親プロデューサリンク列、及び親プロデューサ行の子プロデューサリンク列がそのリンクを表すように変更される（そして依存性決定プロデューサリファレンスは、両方において同じである）。本発明の一実施形態では、あるプロデューサグラフ又は異なるプロデューサグラフにおける複数の経路が所与のプロデューサを含むので、所与のプロデューサに対して複数の親プロデューサリンクが存在し得る。
更に、図１１Ｃは、現在プロデューサ出力、プロデューサがオーバーライドされたかどうかの指示、及びオーバーライドされた出力値を記憶するためのプロデューサ出力キャッシング及びオーバーライドプロデューサ出力変更列１１７０も含む。又、図１１Ｃは、上述した増分的実行マーキングを記憶するための増分的実行マーキング列１１８０も含む。
図１１Ｄは、本発明の一実施形態による図１０のメソッド追跡構造１０５８の一例を示すブロック図である。図１１Ｄにおいて、メソッドキー列１１９０及びメソッドリファレンス列１１９２は、各々、ロードされるクラスのメソッドに対するメソッドキー及びその対応リファレンスを記憶するように示されている。更に、図１１Ｄは、ArgumentDependencies列１１９４、FieldDependencies列１１９６、SequencingDependencies列１１９５、UpwardDependencies列１１９３、WeaklyConstrainedDependencies列１１９９、出力クラス列１１９７、及び任意の付加的なアノテーション列１１９８も示している。ArgumentDependencies列１１９４、SequencingDependencies列１１９５、UpwardDependencies列１１９３、WeaklyConstrainedDependencies列１１９９、及びFieldDependencies列１１９６は、メソッドのプロデューサ依存性宣言ステートメント（図７Ａの７０５を参照）から構文解析されたプロデューサ依存性情報を記憶し、一方、出力クラス列１１９７は、メソッドの出力の出力クラス（メソッドのシグネチュアにより決定できる−例えば、図７Ａの７１０を参照）に関する情報を記憶する。本発明の幾つかの実施形態で使用されるArgumentDependencies列１１９４、FieldDependencies列１１９６、SequencingDependencies列１１９５、UpwardDependencies列１１９３、及びWeaklyConstrainedDependencies列１１９９の例示的なコンテンツは、以下で述べる。
ダイナミックプロデューサ依存性
上述したように、本発明の一実施形態は、非ダイナミック及びダイナミックプロデューサ依存性をサポートする。異なる実施形態は、異なる形式のダイナミックプロデューサ依存性をサポートするが、本発明の一実施形態は、コンティンジェント及びサブスクリプション形式のダイナミックプロデューサ依存性をサポートする。従って、非コンティンジェント、非サブスクリプション依存性は、非ダイナミック（スタティック）依存性である。
図１２は、本発明の一実施形態によりコンティンジェント及びサブスクリプション形式のダイナミックプロデューサ依存性をサポートするための図１０の付加的な細部を示すブロック図である。図１２は、図１０から、破線の分割線１０００、ビジネスロジックを含むクラス定義１０１０（これは、データ１０１２、メソッド１０１４、及びプロデューサ依存性宣言１０１６を含む）、新クラスモジュール１０９５、クラス１０５４（メソッド及びプロデューサ依存性宣言１０５６を含む）、新インスタンスモジュール１０９８、インスタンス１０５２、インスタンス追跡構造１０６５、自動プロデューサグラフ発生モジュール１０４０、プロデューサグラフ（１つ又は複数）構造１０６０、及びプロデューサグラフ実行モジュール１０７０（ダイナミック依存性モジュール１０７５を含む）を含む。
図１２は、プロデューサ依存性宣言１０１６が、任意であるが、コンティンジェント依存性１２１０、サブスクリプション依存性１２２０、及び複数のプロデューサ１２１５を含むことを示している。ここで、複数のプロデューサ１２１５は、プロデューサの集合を返送するためのプロデューサ依存性の能力を指す。更に、図１２は、コンティンジェント依存性１２１０及びサブスクリプション依存性１２２０を処理するために自動プロデューサグラフ発生モジュール１０４０にサブスクリプションモジュール１２４０及びコンティンジェンシーモジュール１２３０を含む。又、図１２は、サブスクリプションモジュール１２４０がサブスクリプションログ１２５０にアクセスすることも示している。更に、ダイナミック依存性モジュール１０７５は、コンティンジェント依存性１２１０及びサブスクリプション依存性１２２０を処理するためにコンティンジェンシーモジュール１２６０及びサブスクリプションモジュール１２６５を備えている。サブスクリプションモジュール１２６５は、サブスクリプションログ１２５０にアクセスする。
コンティンジェント及びサブスクリプション依存性の以下の説明は、依存性決定プロデューサによりインスタンスが返送されてプロデューサグラフ指向のプログラミングサポートを伴うランタイムにより分析されるところのクラスＤＥＰ（依存性の省略形）を使用する本発明の実施形態の環境で行われる。クラスＤＥＰは、次のフィールドを含む。１）サブスクリプション、非サブスクリプション下方宣言（サブスクリプションでない子プロデューサ）又は非サブスクリプション上方宣言（サブスクリプションでない親プロデューサ）にセットすることのできるＴＹＰＥ；２）非サブスクリプション下方宣言依存性に使用され且つ子プロデューサの集合である（従って、０以上のプロデューサを記憶できる）ＰＲＯＤ；３）サブスクリプション依存性に使用され且つサブスクリプション依存性の形式を指示するようにセットされるＳＵＢ ＴＹＰＥ（複数の形式のサブスクリプションをサポートする本発明の実施形態に使用されるが、ここに述べる本発明の実施形態は、スティッキー及びアブソーブの２つの形式をサポートし、別の実施形態は、より多くの、より少ない及び／又は異なるサブスクリプション形式をサポートしてもよい）；４）サブスクリプション依存性に使用され且つサブスクリプション基準を指示するようにセットされるＳＵＢ ＣＲＩＴ；５）スティッキーサブスクリプション依存性及び非サブスクリプション上方宣言依存性に使用され且つ親プロデューサのどんなリンクモードでなければならないか指示するようにセットされるＰＡＲ ＬＩＮＫ ＭＯＤＥ；６）スティッキーサブスクリプション依存性及び非サブスクリプション上方宣言依存性に使用され且つ親プロデューサのどんなクラス（例えば、クラスキー）でなければならないか指示するようセットされるＰＡＲ ＣＬＡＳＳ；７）スティッキーサブスクリプション依存性及び非サブスクリプション上方宣言依存性に使用され且つ親プロデューサのどんなメソッド（例えば、メソッドキー）でなければならないか指示するようにセットされるＰＡＲ ＭＥＴＨＯＤ；及び８）スティッキーサブスクリプション依存性及び非サブスクリプション上方宣言依存性に使用され且つ親プロデューサのどんなインスタンス（例えば、インスタンスキー）でなければならないか指示するようにセットされるＰＡＲ ＩＮＳＴＡＮＣＥ（ＰＡＲＩＮＳＴＡＮＣＥをブランクのままにすると、子プロデューサのインスタンスキーが親プロデューサに対して使用される）。別の実施形態は、スティッキーサブスクリプション依存性及び／又は非サブスクリプション上方宣言依存性の場合に、親プロデューサの集合を使用する（集合の各アイテムは、ＰＡＲ＿ＣＬＡＳＳ、ＰＡＲ＿ＩＮＳＴＡＮＣＥ、ＰＡＲ＿ＭＥＴＨＯＤ、ＰＡＲ＿ＬＩＮＫ ＭＯＤＥを保持する）。もちろん、本発明の他の実施形態は、異なる構造を使用して、依存性を返送することができる。
コンティンジェント依存性
本発明の一実施形態において、非コンティンジェント及びコンティンジェントの両プロデューサ依存性がサポートされる。非コンティンジェントのプロデューサ依存性は、他のプロデューサの出力とは独立したものであり、一方、コンティンジェントのプロデューサ依存性は、他のプロデューサの出力に依存したものである。本発明の一実施形態は、非コンティンジェント及びコンティンジェントの両プロデューサ依存性をサポートするが、別の実施形態は、非コンティンジェント又はコンティンジェントしかサポートしない（どちらかのコンティンジェントのプロデューサ依存性がデフォールト値によって最初に駆動されてもよい）。
上述したように、プロデューサは、指定の粒度の付加的なレベルごとに１つある、複数の識別子のセットとして見ることができる。本発明の実施形態では、コンティンジェントのプロデューサ依存性は、識別子のセットの中のいずれか１つ又は全部を現在データ値に基づいて条件付きで決定できるという意味で、コンティンジェントである。例えば、第１のコンティンジェントのプロデューサ依存性は、インスタンス識別子しか条件付きで決定できず（クラス及びメソッド識別子は固定であり）、一方、第２のコンティンジェントのプロデューサ依存性は、クラス、インスタンス及びメソッドの識別子を条件付きで決定することができる。本発明の一実施形態では、コンティンジェントのプロデューサ依存性の複数の識別子が全て条件付きであるが、本発明の別の実施形態は、異なる仕方で具現化されてもよい（例えば、複数の識別子のうちのサブセットのみを条件付きとすることができる）。
図１３Ａ−Ｊは、本発明の実施形態による擬似コード及び例示的プロデューサを示すブロック図である。更に、図１３Ａ−Ｊに示す実施形態は、コンティンジェント及び非コンティンジェントの両依存性に対して同じ依存性決定メカニズムを使用するものである。従って、説明上、図１３Ａ−Ｊにおける幾つかの例は、非コンティンジェントプロデューサ依存性の例であり、一方、他のものは、コンティンジェントプロデューサ依存性の例である。更に、非コンティンジェントプロデューサ依存性とは、依存性が、独立プロデューサである依存性決定プロデューサに対するものであり（例えば、本発明の一実施形態では、プロデューサ依存性宣言が空であるために依存性形式が識別可能であり）、一方、コンティンジェントのプロデューサ依存性とは、依存性が、従属プロデューサである依存性決定プロデューサに対するものである（例えば、本発明の一実施形態では、プロデューサ依存性宣言が空でないので依存性形式が識別可能である）。
更に、丸内の番号及び文字は、図１３Ａ−Ｊでは、本発明の一実施形態に基づいてオペレーションが遂行される順序を示す。又、表記Ｘ：：Ｙ：：Ｚは、図１３Ａ−Ｊでは、クラスキー（Ｘ）、インスタンスキー（Ｙ）及びメソッドキー（Ｚ）で形成されるプロデューサキーを表すのに使用される。更に、破線の丸及び矢印付きの線は、本発明のある実施形態では遂行されないオペレーションを表す。特に、所与の依存性に対する独立した依存性決定プロデューサの実行が、常に、同じ依存性（例えば、独立した依存性決定プロデューサ）を返送する場合には、本発明のある実施形態ではそのような依存性決定プロデューサが実行されるが、プロデューサグラフ（１つ又は複数）においてはインスタンス生成もリンクもなされない。
明示的依存性決定プロデューサ
図１３Ａは、本発明の一実施形態による非ショートカット宣言、非ダイナミック（非コンティンジェント、非サブスクリプション）依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図１３Ｂは、本発明の一実施形態による例示的非ショートカット宣言、非ダイナミック（非コンティンジェント、非サブスクリプション）プロデューサ依存性を示すプロデューサのブロック図である。図１３Ａは、次のものを示す。１）メソッドアルファ１３０５に対するプロデューサ依存性宣言ステートメント１３００、ここで、プロデューサ依存性宣言ステートメント１３００は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡに対するプロデューサ依存性を含む；及び２）メソッドベータ１３１５に対するプロデューサ依存性宣言ステートメント１３１０、ここで、プロデューサ依存性宣言ステートメント１３１０は空であり、且つメソッドベータ１３１５は、クラスＤＥＰのインスタンスを引数として返送する。メソッドベータ１３１５は、プロデューサ依存性宣言コード１３２０を含み、これは、ＤＥＰ．ＴＹＰＥを非サブスクリプション下方宣言にセットし、ＤＥＰ．ＰＲＯＤをプロデューサ１３にセットし、そしてＤＥＰを返送する。
図１３Ａにおいて、丸１は、プロデューサ依存性宣言１３００がアクセスされることを指示する（例えば、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサとして指定する結果として、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサの子孫として自動的に発見する結果として、等々）。図１３Ｂにおける丸２は、メソッドアルファ１３０５に基づきプロデューサＣ０：:Ｉ０：：ＡＬＰＨＡがインスタンス生成されることを示している。図１３Ａにおける丸３は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡに対するプロデューサ依存性が処理されて、プロデューサ依存性を決定することを指示し、その結果、丸４は、プロデューサ依存性宣言１３１０がアクセスされることを指示する。図１３Ｂにおける破線の丸５は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡが依存性決定プロデューサ１３８０としてインスタンス生成されることを示している。図１３Ｂにおける破線の丸６は、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡがプロデューサグラフにおいてリンクされることを指示し、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡが子プロデューサであることを指示する。図１３Ｂにおける丸７は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡが実行されることを指示し、そしてプロデューサ１３を識別するためにＤＥＰを返送する。丸８は、プロデューサ１３がインスタンス生成されることを指示し、一方、丸９は、プロデューサ１３がプロデューサグラフにおいて子プロデューサとしてプロデューサＣ０：：Ｉ０：：ＡＬＰＨＡへリンクされることを指示する。図１３Ｂにおいて、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡ及びプロデューサ１３は、標準的プロデューサ１３８５である（それらは、依存性決定プロデューサではない）。
図１３Ｃは、本発明の一実施形態による非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図１３Ｄは、本発明の一実施形態による例示的非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。更に、図１３Ｄは、ず５Ａのプロデューサ５、７Ａ及び７Ｂと、プロデューサ７Ａに対するプロデューサ５のダイナミック依存性の解明とを指す。
図１３Ｃは、次のものを示している。１）メソッドアルファ１３０５に対するプロデューサ依存性宣言ステートメント１３００、ここで、プロデューサ依存性宣言ステートメント１３００は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡに対するプロデューサ依存性を含み；２）メソッドベータ１３１５に対するプロデューサ依存性宣言ステートメント１３２５、ここで、プロデューサ依存性宣言ステートメント１３２５は、プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡに対するプロデューサ依存性を含み、そしてメソッドベータ１３１５は、クラスＤＥＰのインスタンスを引数として返送し；３）メソッドデルタ１３３４に対するプロデューサ依存性宣言ステートメント１３３２、ここで、プロデューサ依存性宣言ステートメント１３３２は空であり、そしてメソッドデルタ１３３４は、クラスＤＥＰのインスタンスを引数として返送し；及び４）メソッドガンマ１３４０に対するプロデューサ依存性宣言ステートメント１３３８、ここで、プロデューサ依存性宣言ステートメント１３３８は、空であり、そしてメソッドガンマ１３４０は、変数Ｘを返送する（ここで、Ｘは、外部ソースからのもの、デフォールト値（明示的、又はクラスにおける定数）である）。メソッドベータ１３１５は、プロデューサ依存性宣言コード１３３０を含み、これは、ＤＥＰ．ＴＹＰＥを非サブスクリプション下方宣言にセットし、ＤＥＰ．ＰＲＯＤを、プロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡの出力に基づいてプロデューサ７Ａ又は７Ｂにセットし、そしてＤＥＰを返送する。メソッドデルタ１３３２は、プロデューサ依存性宣言コード１３３６を含み、これは、ＤＥＰ．ＴＹＰＥを非サブスクリプション下方宣言にセットし、ＤＥＰ．ＰＲＯＤをプロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡにセットし、そしてＤＥＰ．ＰＲＯＤを返送する。
図１３Ｃにおいて、丸１は、プロデューサ依存性宣言１３００がアクセスされることを指示する（例えば、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサとして指定する結果として、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサの子孫として自動的に発見する結果として、等々）。図１３Ｄの丸２は、メソッドアルファ１３０５に基づきプロデューサ５がインスタンス生成されることを示している。図１３Ｃの丸３は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡに対するプロデューサ依存性が処理されてプロデューサ依存性を決定することを示し、その結果、丸４は、プロデューサ依存性宣言１３２５がアクセスされることを示している。図１３Ｂの丸５は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡが依存性決定プロデューサ１３８０としてインスタンス生成されることを示している。図１３Ｄの丸６は、プロデューサ５がプロデューサグラフにおいてリンクされることを指示し、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡが子プロデューサであることを指示する。
図１３Ｃの丸７は、プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡに対するプロデューサ依存性が処理されてプロデューサ依存性を決定することを指示し、その結果、丸８は、プロデューサ依存性宣言１３３２がアクセスされることを指示する。図１３Ｄの破線の丸９は、プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡが依存性決定プロデューサ１３８０としてインスタンス生成されることを示す。図１３Ｄの破線の丸１０は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡがプロデューサグラフにおいてリンクされることを指示し、プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡが子プロデューサであることを指示する。図１３Ｄの丸１１は、プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡが実行され、そしてＣＸ：：ＩＺ：：ＧＡＭＭＡを識別するためにＤＥＰを返送することを指示する。丸１２は、プロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡがインスタンス生成されることを指示し、一方、丸１３は、プロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡがプロデューサグラフにおいてプロデューサＣＷ：：ＩＹ：：ＢＥＴＡに対して子プロデューサとしてリンクされることを指示する。
図１３Ｄにおいて、丸Ａは、プロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡが実行され、ＸをプロデューサＣＷ：：ＩＹ：：ＢＥＴＡへ返送することを指示し、一方、丸Ｂは、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡがプロデューサ７Ａを識別するためにＤＥＰを返送することを指示し、丸Ｃは、未解明の残部（メソッドベータ）１３９０が今や解明されそしてプロデューサ７Ａがインスタンス生成されることを指示し、一方、丸Ｄは、プロデューサ５をプロデューサ７Ａにリンクすることを指示する。図１３Ｄにおいて、プロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡ、５及び７Ａは、標準的プロデューサ１３８５である。
オンザフライの依存性決定プロデューサ
図１３Ｅは、本発明の一実施形態による非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性の両方を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図１３Ｆは、本発明の一実施形態による非ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。図１３Ｄと同様に、図１３Ｆは、図５Ａのプロデューサ５、７Ａ及び７Ｂと、プロデューサ７Ａに対するプロデューサ５のダイナミック依存性の解明とを指す。
図１３Ｅ−Ｆは、次のことを除いて、図１３Ｃ−Ｄと同じである。１）プロデューサ依存性宣言ステートメント１３４２がプロデューサ依存性宣言ステートメント１３２５に置き換わり；２）メソッドフライ(fly)１３４４がメソッドデルタ１３３４に置き換わり；及び３）プロデューサＣＷ：：ＩＹ：：ＦＬＹがプロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡに置き換わる。プロデューサ依存性宣言ステートメント１３４２は、ＣＸ：：ＩＺ：：ＧＡＭＭＡに対するショートカット宣言プロデューサ依存性を含む。従って、図１３Ｅの丸４は、今度は、プロデューサ依存性宣言１３４２がアクセスされることを指示する。図１３Ｅの丸７は、今度は、プロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡに対するショートカット宣言プロデューサ依存性が処理されてプロデューサ依存性を決定し、その結果、ランタイムがメソッドフライ１３４４に基づいてオンザフライで依存性決定プロデューサＣＷ：：ＩＹ：：ＦＬＹをインボークすることを指示する。丸８は、今度は、プロデューサ依存性宣言１３３２がアクセスされることを指示する。図１３Ｆの破線の丸９は、今度は、プロデューサＣＷ：：ＩＹ：：ＦＬＹがインスタンス生成されることを示す。図１３Ｆの破線の丸１０は、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡがプロデューサグラフにおいてリンクされることを指示し、プロデューサＣＷ：：ＩＹ：：ＦＬＹが子プロデューサであることを指示する。図１３Ｆの丸１１は、プロデューサＣＷ：：ＩＹ：：ＦＬＹが実行されそしてＣＸ：：ＩＺ：：ＧＡＭＭＡを識別するためにＤＥＰを返送することを指示する。図１３Ｅ−Ｆの残り部分は、図１３Ｃ−Ｄと同じである。
依存性決定プロデューサＣＷ：：ＩＹ：：ＦＬＹのランタイムによるオンザフライ発生は、アプリケーションプログラマーが、明示的プロデューサ依存性宣言コードを書き込みそしてそれに基づいて依存性決定プロデューサをインスタンス生成しなければならないことから軽減する。更に、アプリケーションプログラマーが、依存性決定プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡを指定するのではなく、メソッドベータ１３１５に対するプロデューサ依存性宣言ステートメントにおいてプロデューサＣＸ：：ＩＺ：：ＧＡＭＭＡに対する依存性を直接指定することを許す。
ショートカット技術は、種々の状況において使用することができ、更に、種々のフォーマットを有してもよい。例えば、図１３Ｅ−Ｆにおいて、ショートカット宣言依存性は、非コンティンジェント依存性に対するものであり（子プロデューサを直接識別し）、そして依存性決定プロデューサのベースとなるメソッドに対するプロデューサ依存性宣言ステートメント内にあるが、他の状況及びフォーマットは、次のように示される。１）図１３Ｇ−Ｈは、２つのショートカットの使用を示し、その一方は、コンティンジェントなもので、標準的なプロデューサのベースとなるメソッドに対するプロデューサ依存性宣言ステートメントの一部分であり、そしてその他方は、非コンティンジェントなもので、依存性決定プロデューサのベースとなるメソッドに対するプロデューサ依存性宣言ステートメントの一部分であり；そして２）図１３Ｉ−Ｊは、非コンティンジェントなショートカットであって、標準的プロデューサのベースとなるメソッドに対するプロデューサ依存性宣言ステートメント内にあるショートカットの使用を示す。
図１３Ｇは、本発明の一実施形態によるショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、非コンティンジェント、非サブスクリプションのプロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図１３Ｈは、本発明の一実施形態による例示的ショートカット宣言、コンティンジェント、非サブスクリプションのプロデューサ依存性、及びショートカット宣言、非コンティンジェント、非サブスクリプションのプロデューサ依存性を示すプロデューサのブロック図である。図１３Ｇは、次のものを示す。１）メソッドアルファ１３０５に対するプロデューサ依存性宣言ステートメント１３４５、ここで、プロデューサ依存性宣言ステートメント１３４５は、プロデューサ＜Ｐ＞ＧＥＴＣ１：：Ｉ１：：Ｍ１に対するショートカット宣言、コンティンジェントのプロデューサ依存性を含み；２）メソッドフライ１ １３５５に対するプロデューサ依存性宣言ステートメント１３５０、ここで、プロデューサ依存性宣言ステートメント１３５０は、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１に対するショートカット宣言、非コンティンジェントのプロデューサ依存性を含み、且つメソッドフライ１ １３５５は、ＤＥＰのインスタンスを引数として返送し；３）メソッドフライ２ １３６２に対するプロデューサ依存性宣言ステートメント１３２２、ここで、メソッドフライ２ １３６２は、ＤＥＰのインスタンスを引数として返送し；及び４）メソッドｇｅｔｃ１ １３７０に対するプロデューサ依存性宣言ステートメント１３６５、ここで、メソッドｇｅｔｃ１ １３７０は、ＣＸ又はＣＹの値と共にＣ１を返送する。
メソッドＦＬＹ１ １３５５及びそのプロデューサ依存性宣言ステートメント１３５０は、ショートカット宣言依存性＜Ｐ＞ＧＥＴＣ１：：Ｉ１：：Ｍ１（これは、クラスキーに対してショートカットが使用されることを指示する）に応答して、ランタイムにより与えられる。メソッドフライ１ １３５５は、プロデューサ依存性宣言コード１３６０を含み、これは、ＤＥＰ．ＴＹＰＥを非サブスクリプション下方宣言にセットし、ＤＥＰ．ＰＲＯＤを、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１により出力されるＣ１の値に基づいてプロデューサＣＸ：：Ｉ１：：Ｍ１又はＣＹ：：Ｉ１：：Ｍ１にセットし、そしてＤＥＰを返送する。図１３Ｈの例において、＜Ｐ＞は、コンティンジェントであるプロデューサのクラスキーであることを示すのに使用されるが、本発明の別の実施形態では、他のシンタックスを使用することもできる。更に、図１３Ｈの例では、＜Ｐ＞は、コンティンジェントであるプロデューサのクラスキーであることを示すのに使用されるが、本発明の一実施形態は、このようにコンティンジェントとして指示されるプロデューサキーを作り上げるより多くの及び／又は異なる識別子をもつこともサポートする。
図１３Ｇにおいて、丸１は、プロデューサ依存性宣言１３４５がアクセスされることを指示する（例えば、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサとして指定する結果として、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサの子孫として自動的に発見する結果として、等々）。図１３Ｈにおける丸２は、メソッドアルファ１３０５に基づきプロデューサＣ０：:Ｉ０：：ＡＬＰＨＡがインスタンス生成されることを示している。図１３Ｇにおける丸３は、ショートカット宣言プロデューサ依存性が処理されて、プロデューサ依存性を決定することを指示し、その結果、丸４は、プロデューサ依存性宣言１３５０がアクセスされることを指示する。
図１３Ｈの丸５は、プロデューサＣ０：：Ｉ０：：ＦＬＹ１が依存性決定プロデューサ１３８０としてインスタンス生成されることを示している。図１３Ｈの丸６は、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡがプロデューサグラフにおいてリンクされることを指示し、プロデューサＣ０：:Ｉ０：：ＦＬＹ１が子プロデューサであることを指示する。図１３Ｇの丸７は、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１に対するショートカット宣言プロデューサ依存性が処理されてプロデューサ依存性を決定し、そしてランタイムがメソッドフライ２ １３６２を与えることを指示し、その結果、丸８は、プロデューサ依存性宣言１３３２がアクセスされることを指示する。図１３Ｈの破線の丸９は、プロデューサＣ０：：Ｉ０：：ＦＬＹ２がインスタンス生成されることを示す。図１３Ｈの破線の丸１０は、プロデューサＣ０：：Ｉ０：：ＦＬＹ１がプロデューサグラフにおいてリンクされることを指示し、プロデューサＣ０：：Ｉ０：：ＦＬＹ２が子プロデューサであることを指示する。
図１３Ｈの丸１１は、プロデューサＣ０：：Ｉ０：：ＦＬＹ２が実行され、そしてプロデューサＣ０：：Ｉ０：：ＧＥＴＣ１を識別するためにＤＥＰを返送することを指示する。丸１２は、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１がインスタンス生成されることを指示し、一方、丸１３は、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１がプロデューサグラフにおいて子プロデューサとしてプロデューサＣ０：：Ｉ０：：ＦＬＹ１にリンクされることを指示する。
図１３Ｈにおいて、丸Ａは、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１が実行され、そしてＣ１＝ＣＸをプロデューサＣ０：：Ｉ０：：ＦＬＹ１へ返送することを指示し、一方、丸Ｂは、プロデューサＣ０：：Ｉ０：：ＦＬＹ１が実行され、そしてプロデューサＣＸ：：Ｉ１：：Ｍ１を識別するためにＤＥＰを返送することを指示し、又、丸Ｃは、未解明の残部（メソッドフライ１）１３９０が今や解明されたことを指示し、そして丸Ｄは、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡをプロデューサＣＸ：：Ｉ１：：Ｍ１にリンクすることを指示する。図１３Ｈにおいて、プロデューサＣ０：：Ｉ０：：ＧＥＴＣ１、Ｃ０：：Ｉ０：：ＡＬＰＨＡ、及びＣＸ：：Ｉ１：：Ｍ１は、標準的プロデューサ１３８５である。
依存性決定プロデューサＣ０：：Ｉ０：：ＦＬＹ１及びＣ０：：Ｉ０：：ＦＬＹ２のランタイムによるオンザフライ発生は、アプリケーションプログラマーが、明示的プロデューサ依存性宣言コードを書き込みそしてそれに基づいて依存性決定プロデューサをインスタンス生成しなければならないことから軽減する。更に、アプリケーションプログラマーが、依存性決定プロデューサＣＷ：：ＩＹ：：ＢＥＴＡを指定するのではなく、メソッドアルファ１３０５に対するプロデューサ依存性宣言ステートメントにおいてメソッドｇｅｔＣ１を通してプロデューサ＊＊：：Ｉ１：：Ｍ１に対するコンティンジェント依存性を直接指定することを許す。
図１３Ｉは、本発明の一実施形態によるショートカット宣言、非ダイナミック（非コンティンジェント、非サブスクリプション）プロデューサ依存性を使用するメソッドに対するプロデューサ依存性宣言の擬似コードを示し、一方、図１３Ｊは、本発明の一実施形態による例示的ショートカット宣言、非ダイナミックプロデューサ依存性を示すプロデューサのブロック図である。図１３Ｉは、次のものを示す。１）メソッドアルファ１３０５に対するプロデューサ依存性宣言ステートメント１３７２、ここで、プロデューサ依存性宣言ステートメント１３７２は、プロデューサ１０に対するショートカット宣言プロデューサ依存性を含み；及び２）メソッドフライ１３７６に対するプロデューサ依存性宣言ステートメント１３７４、ここで、プロデューサ依存性宣言ステートメント１３７４は、空であり、そしてメソッドフライ１３７６は、ＤＥＰのインスタンスを引数として返送する。メソッドフライ１７７６及びそのプロデューサ依存性宣言ステートメント１３７４は、ショートカット宣言依存性に応答してランタイムにより与えられる。メソッドフライ１３７６は、プロデューサ依存性宣言コード１３７８を含み、これは、ＤＥＰ．ＴＹＰＥを非サブスクリプション下方宣言にセットし、ＤＥＰ．ＰＲＯＤをプロデューサ１０にセットし、そしてＤＥＰを返送する。
図１３Ｉにおいて、丸１は、プロデューサ依存性宣言１３７２がアクセスされることを指示する（例えば、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサとして指定する結果として、メソッドアルファ１３０５に基づくプロデューサを、問題とするプロデューサの子孫として自動的に発見する結果として、等々）。図１３Ｊの丸２は、メソッドアルファ１３０５に基づきプロデューサＣ０：:Ｉ０：：ＡＬＰＨＡがインスタンス生成されることを示している。図１３Ｉの丸３は、ショートカット宣言プロデューサ依存性が処理されてプロデューサ依存性を決定し、そしてランタイムがメソッドフライ１３７６を与えることを指示し、その結果、丸４は、プロデューサ依存性宣言１３７４がアクセスされることを指示する。図１３Ｊの破線の丸５は、プロデューサＣ０：：Ｉ０：：ＦＬＹが依存性決定プロデューサ１３８０としてインスタンス生成されることを示す。図１３Ｊの破線の丸６は、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡがプロデューサグラフにおいてリンクされることを指示し、プロデューサＣ０：：Ｉ０：：ＦＬＹ１が子プロデューサであることを指示する。
図１３Ｊの丸７は、プロデューサＣ０：：Ｉ０：：ＦＬＹ１が実行され、そしてプロデューサ１０を識別するためにＤＥＰを返送することを指示する。丸８は、プロデューサ１０がインスタンス生成されることを指示し、一方、丸９は、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡがプロデューサグラフにおいてリンクされることを指示し、プロデューサ１０が子プロデューサであることを指示する。図１３Ｊにおいて、プロデューサＣ０：：Ｉ０：：ＡＬＰＨＡ及びプロデューサ１０は、標準的プロデューサ１３８５である。
ランタイムプログラマーは、本発明の一実施形態において、サポートされる全てのシンタックス及び組合せ（例えば、メソッドフライ１３３４、メソッドフライ１ １３５５、メソッドフライ２ １３６２、メソッドフライ１３７６）を解釈するために単一フライメソッドを書き込み、そしてそれをランタイムに含ませることを理解されたい。これは、アプリケーションプログラマーが、フライメソッドが使用される依存性決定プロデューサに対してコードの書き込みを回避できるだけでなく、ランタイムプログラマーは、一般的なフライメソッド（サポートされる全ての状況に対する単一フライ）を一度書き込むだけでよい。更に、ショートカット宣言依存性は、依存性決定プロデューサを使用するランタイムを許すと同時に、アプリケーションプログラマーがプロデューサ依存性宣言において標準的プロデューサを指示するのを許すことも理解されたい（例えば、図１３Ｇ−Ｊ）。
メソッド追跡構造
図１１Ｄのメソッド追跡構造に戻って、ArgumentDependencies列１１９４、FieldDependencies列１１９６、SequencingDependencies列１１９５、UpwardDependencies列１１９３、及びWeaklyConstrainedDependencies列１１９９の例示的コンテンツについて以下に説明する。より詳細には、ArgumentDependencies列１１９４は、各ArgumentDependenciesに１つづつあるアイテムの集合を記憶する。本発明の一実施形態では、各アイテムは、次のものを含む。１）引数ＩＤ；２）明示的クラス、同じクラス、及びコンティンジェントクラスの１つであるクラスキーネイチャー識別子；３）クラスキーネイチャー識別子が明示的クラスを指示するときにポピュレートされる明示的クラスキー識別子；４）クラスキーネイチャー識別子がコンティンジェントクラスを指示するときにポピュレートされるコンティンジェントクラス決定メソッドキー識別子；５）明示的インスタンス、同じインスタンス、及びコンティンジェントインスタンスの１つであるインスタンスキーネイチャー識別子；６）インスタンスキーネイチャー識別子が明示的インスタンスを指示するときにポピュレートされる明示的インスタンスキー識別子；７）インスタンスキーネイチャー識別子がコンティンジェントインスタンスを指示するときにポピュレートされるコンティンジェントインスタンス決定メソッドキー識別子；８）明示的メソッド、同じメソッド、及びコンティンジェントメソッドの１つであるメソッドキーネイチャー識別子；９）メソッドキーネイチャー識別子が明示的メソッドを指示するときにポピュレートされる明示的メソッドキー識別子；１０）メソッドキーネイチャー識別子がコンティンジェントメソッドを指示するときにポピュレートされるコンティンジェントメソッド決定メソッドキー識別子；及び１１）プロデューサ依存性宣言ステートメントの引数に対するプロデューサ依存性宣言がショートカットの指示を含むかどうか指示するショートカット識別子（即ち、プロデューサ依存性宣言ステートメントは、依存性決定プロデューサではなく、標準的な子プロデューサを直接識別する）。
種々のキーネイチャー識別子の「・・・明示的」指示は、プロデューサ依存性宣言ステートメントにおいてプロデューサ依存性に対して明示的キーが設けられる場合に使用される。例えば、図１３Ａのプロデューサ依存性宣言ステートメント１３００のプロデューサ依存性「ＣＷ：：ＩＹ：：ＢＥＴＡ」は、明示的クラス、インスタンス及びメソッドキーを与える。
本発明の幾つかの実刑形態では、プロデューサ依存性宣言ステートメントに対してショートハンド(shorthand)技術が次のようにサポートされる。１）所与のプロデューサ依存性に対してクラスが設けられない場合には、親プロデューサと同じクラスが使用され；及び２）所与のプロデューサ依存性に対してクラス及びインスタンスが設けられない場合には、親プロデューサと同じクラス及びインスタンスが使用される。本発明の他の実施形態では、クラス、インスタンス及びメソッドの組合せを親と同じにする（全部が同じであることを除いて）のを許すためにシンタックスが使用される（例えば、クラス、インスタンス及びメソッドの各々を指定するのにセパレータが使用され、このようなセパレータがないと、親と同じであることを指示し、特定例によれば、シンタックスは、“＃Ｃ：”、“＃Ｉ”及び“＃Ｍ：”であり、プロデューサ依存性宣言ステートメントにおけるプロデューサ依存性は、＃Ｃ：”クラスキー”：：＃Ｉ：”インスタンスキー”：：＃Ｍ：”メソッドキー”となる）（引用符は、値又は変数のプレースホルダーを示す）。このショートハンド技術がプロデューサ依存性宣言ステートメントに使用される場合には、種々のキーネイチャー識別子の「・・・同じ」指示が使用される。
上述したように、本発明のある実施形態では、コンティンジェントプロデューサ依存性の指示は、プロデューサ依存性宣言ステートメントそれ自体に使用されるシンタックス（例えば、＜Ｐ＞）を通してサポートされ（図１３Ｇの１３４５を参照）、そしてこのようなシンタックスは、プロデューサ依存性のクラス、インスタンス及びメソッドの１つ以上に使用することができる。種々のキーネイチャー識別子の「・・・コンティンジェント」指示は、このようなコンティンジェントプロデューサ依存性がいつ生じるか識別するのに使用され、一方、「コンティンジェント・・・決定メソッドキー識別子」は、子プロデューサのメソッドキーを指示する（クラス及びインスタンスは、親プロデューサのものと同じである）。例えば、図１３Ｇのプロデューサ依存性宣言１３４５に対するプロデューサ依存性“＜Ｐ＞ＧＥＴＣ１：：Ｉ１：：Ｍ１”は、コンティンジェントクラス（コンティンジェントクラス決定メソッドキーがＧＥＴＣ１である場合）、明示的インスタンスキー、及び明示的メソッドキーを与える。
SequencingDependencies列１１９５、UpwardDependencies列１１９３、及びWeaklyConstrainedDependencies列１１９５の各々は、SequencingDependencies、UpwardDependencies及びWeaklyConstrainedDependenciesの各々に１つづつの、アイテムの集合を記憶する。本発明の一実施形態では、このような各アイテムは、引数ＩＤを含まないことを除いて、ArgumentDependenciesに対する集合のアイテムと同じ構造を有する。更に、図１３Ａ−Ｊは、依存性決定プロデューサから生じる非サブスクリプション下方宣言依存性を示しているが、上方宣言依存性又は弱い制約の依存性の場合には、依存性決定プロデューサは、図７Ｆ−Ｇを参照して述べた他の依存性を返送することができる。
FieldDependencies列１１９６は、各FieldDependencyに１つづつあるアイテムの集合を記憶する。本発明の一実施形態では、各アイテムは、プロパティメソッドキーを含むが、本発明の別の実施形態では、SequencingDependenciesからの集合のアイテムと同じ構造を有してもよい。
サブスクリプション依存性
本発明の一実施形態において、非サブスクリプション及びサブスクリプションの両プロデューサ依存性がサポートされる。所与のメソッドに対してサブスクリプションプロデューサ依存性が宣言され、且つその所与のメソッドから所与のプロデューサがインスタンス生成されるときには、ランタイムは、サブスクリプションの基準を満足する０以上のプロデューサのセットを（他のプロデューサの存在に基づいて）ランタイム中に解明することができる。本発明の一実施形態は、非サブスクリプション及びサブスクリプションの両プロデューサ依存性をサポートするが、別の実施形態は、非サブスクリプションしかサポートしない。更に、本発明の一実施形態では、２つの形式のサブスクリプション依存性（アブソービング及びスティッキー）がサポートされるが、本発明の別の実施形態は、それより多い、それより少ない、及び／又は異なる形式のサブスクリプションプロデューサ依存性をサポートする。
図１４Ａ−Ｃは、本発明の一実施形態によるアブソービング及びスティッキーサブスクリプションを示すブロック図である。図１４Ａは、本発明の一実施形態による図１２のサブスクリプションログ１２５０の一例を示すブロック図である。図１４Ａは、このログ構造をテーブルとして示しているが、いかなる適当なデータ構造（例えば、ハッシュマップ）が使用されてもよいことを理解されたい。図１４Ｂは、本発明の一実施形態による非コンティンジェント、アブソーブサブスクリプションプロデューサ依存性を示す例示的プロデューサのブロック図である。図１４Ｃは、本発明の一実施形態による非コンティンジェント、スティッキーサブスクリプションプロデューサ依存性を示す例示的プロデューサのブロック図である。図１４Ａのテーブルの２つの行は、図１４Ｂ−Ｃの例で使用されるコンテンツがポピュレートされて示されている。丸付き番号は、図１４Ｂ−Ｃでは、本発明の一実施形態によりオペレーションが遂行される順序を示すのに使用される。
図１４Ａにおいて、サブスクライバープロデューサキー列１４００、サブスクリプション形式列１４０５、及びトリガープロデューサ用サブスクリプション基準列１４１０が、各々、列の名前に対応するコンテンツを記憶するように示されている。更に、図１４Ａは、サブスクリプション依存性の親プロデューサに対するリンクモードを記憶するための親リンクモード列１４２５も示しており、この情報は、図１４Ｂ−Ｃを参照して詳細に説明する。
又、図１４Ａは、アブソービングサブスクリプションに使用されるマッチングプロデューサ列１４１５及び完了列１４２０も示している。マッチングプロデューサ列１４１５は、アブソービングサブスクリプションのサブスクリプション基準を満足するトリガープロデューサのプロデューサキーを記憶するのに使用され、一方、完了列１４２０は、プロデューサグラフの現在セットの所与の実行中にアブソービングサブスクリプションが完了したかどうか追跡するのに使用される。マッチングプロデューサ列１４１５及び完了列１４２０は、インスタンス生成されたプロデューサをスキャンする作業を、以下に述べる自動プロデューサグラフ発生とプロデューサグラフ実行との間で分割できるようにする付加的な任意の最適化を与える。
又、図１４Ａは、スティッキーサブスクリプションに使用される親クラス列１４３０、親メソッド列１４３５、及び親インスタンス列１４３７も示している。これら親クラス列１４３０、親メソッド列１４３５、及び親インスタンス列１４３７は、各々、スティッキーサブスクリプションに対して生成されるべき親プロデューサのクラスキー、メソッドキー、及びインスタンスキーを記憶する。更に、図１４Ａは、サブスクリプションを生成する依存性決定プロデューサに対するリファレンスを記憶する依存性決定プロデューサリファレンス列１４２１も示している。
アブソービングサブスクリプション
アブソービングサブスクリプションプロデューサ依存性において、依存性は、アブソービングサブスクリプション基準を満足する現在プロデューサグラフ（１つ又は複数）構造の全プロデューサの集合に対するものである。図１４Ｂを参照すれば、丸１は、プロデューサ１４５０がインスタンス生成される（例えば、プロデューサ１４５０を、問題とするプロデューサとして指定する結果として、プロデューサ１４５０を、問題とするプロデューサの子孫として自動的に発見する結果として、等々）ことを指示する。プロデューサ１４５０は、プロデューサ依存性宣言がプロデューサ依存性を含む（例えば、引数ＩＤ Ｘと共に）ところのメソッドに基づく。丸２は、プロデューサ１４５０のプロデューサ依存性がプロデューサ１４５５を識別するように処理されることを指示する。
丸３は、プロデューサ１４５０がプロデューサグラフにおいてプロデューサ１４５５へ子プロデューサとして（上記例では、引数ＩＤ Ｘを通して）リンクされることを指示する。丸４は、プロデューサ１４５５の実行を指示する。プロデューサ１４５５は、アブソービングサブスクリプションプロデューサ依存性を指示すると共にアブソービングサブスクリプション基準を指示するプロデューサ依存性宣言コードを含む依存性決定プロデューサである。従って、プロデューサ１４５５の実行は、サブスクリプションログのポピュレーションを生じさせる。図１４Ａの第１行における例に関して、サブスクライバープロデューサキー列１４００、サブスクリプション形式列１４０５、トリガープロデューサ用サブスクリプション基準列１４１０、親リンクモード列１４２５、及び依存性決定プロデューサリファレンス列１４２１には、各々、プロデューサ１４５０のプロデューサキー、サブスクリプションがアブソービング形式のものであるという指示、プロデューサ１４５５内に含まれたアブソービングサブスクリプション基準、プロデューサ１４５５にリンクされたプロデューサ１４５０のリンクモード（これは、アブソービングサブスクリプションの場合には、引数依存性であり、引数ＩＤを含むが、そのスティッキーインジケータは、スティッキーでないものを指示し、前記の例では、引数ＩＤ Ｘを指示する）、及びプロデューサ１４５５（サブスクリプションを生成する依存性決定プロデューサ）に対するリファレンスがポピュレートされる。
丸５Ａ−Ｎは、プロデューサ１４６０Ａ−Ｎのインスタンス生成を指示する。この例では、プロデューサ１４６０Ａ−Ｎは、アブソービングサブスクリプション基準を満足し、従って、トリガープロデューサである。従って、丸６Ａ−Ｎは、プロデューサ１４５０をプロデューサ１４６０Ａ−Ｎにリンクする（前記例では、引数ＩＤ Ｘを通して）ことを指示する。丸７は、プロデューサグラフ（１つ又は複数）の現在実行に対してアブソービングサブスクリプション依存性が完了したことを指示し、次いで、プロデューサ１４５０が実行される。
本発明の一実施形態では、アブソービングサブスクリプション基準は、プロデューサキーを作り上げるキーのいずれか１つ以上である。従って、プロデューサキーが、クラスキー、インスタンスキー、及びメソッドキーを含む本発明の実施形態では、サブスクリプション基準は、１つ以上のそのようなキーである。例えば、図１１Ｃを参照すれば、サブスクリプション基準を満足するものについてのインスタンス生成されたプロデューサを通るスキャンは、インスタンス生成されたプロデューサのキーがアブソービングサブスクリプション基準のキーに一致するかどうか決定するための、プロデューサグラフ構造の最初の３列の１つ以上を通るスキャンである。本発明の一実施形態では、アブソービングサブスクリプション基準は、プロデューサキーを作り上げるキーのいずれか１つ以上であるが、本発明の別の実施形態では、アブソービングサブスクリプション基準は、プロデューサを作り上げるキーのサブセットに制限される。
スティッキーサブスクリプション
スティッキーサブスクリプションプロデューサ依存性において、この依存性は、スティッキーサブスクリプション基準を満足するプロデューサごとに親プロデューサをインスタンス生成させる。図１４Ｃを参照すれば、丸１は、プロデューサ１４７０がインスタンス生成されることを指示する（例えば、プロデューサ１４７０を、問題とするプロデューサとして指定する結果として、プロデューサ１４７０を、シーケンス依存性を通して問題とするプロデューサの子孫として自動的に発見する結果として（例えば、SequencingDependency又はWeaklyConstrainedDependencyの結果として、等々）。プロデューサ１４７０は、スティッキーサブスクリプション、トリガープロデューサのためのスティッキーサブスクリプション基準、及び生成されるべき親プロデューサのためのスティッキーサブスクリプション特性を指示するプロデューサ依存性宣言コードを含む依存性決定プロデューサである。
プロデューサ１４７０の実行は、サブスクリプションログのポピュレーションを生じさせる。図１４Ａの第２行における例に関して、サブスクライバープロデューサキー列１４００、サブスクリプション形式列１４０５、及びトリガープロデューサ用サブスクリプション基準列１４１０には、各々、プロデューサ１４７０のプロデューサキー、サブスクリプションがスティッキー形式のものであるという指示、及びプロデューサ１４７０内に含まれるトリガープロデューサに対するスティッキーサブスクリプション基準がポピュレートされる。更に、トリガープロデューサにリンクされるべき親プロデューサの親クラス列１４３０、親メソッド列１４３５、親インスタンス列１４３７、及びリンクモード列１４２５には、生成されるべき親プロデューサに対するスティッキーサブスクリプション特性がポピュレートされ、即ち、本発明のこの実施形態では、インスタンス生成されるべき親プロデューサのクラス、インスタンス生成されるべき親プロデューサのメソッド、インスタンス生成されるべき親プロデューサのインスタンス（ブランクのままにされた場合は、トリガープロデューサのインスタンスキーに等しい）、リンクモード（これは、スティッキーサブスクリプションの場合には、１）引数、フィールド又はシーケンス依存性；２）引数依存性の場合の引数ＩＤ、即ちトリガープロデューサにリンクされるべき親プロデューサの引数ＩＤ（例えば、引数ＩＤ Ｙ））がポピュレートされる。更に、依存性決定プロデューサリファレンス列１４２１には、サブスクリプションを生成した依存性決定プロデューサ（図１４Ｃでは、プロデューサ１４７０）に対するリファレンスがポピュレートされる。
図１４Ｃを参照すれば、丸２は、プロデューサ１４７５がインスタンス生成されることを指示する（例えば、プロデューサ１４７５を、問題とするプロデューサとして指定する結果として、プロデューサ１４７５を、問題とするプロデューサの子孫として自動的に発見する結果として、等々）。更に、プロデューサ１４７５がトリガープロデューサに対するスティッキーサブスクリプション基準を満足するかどうか決定される。丸３は、トリガープロデューサ１４７５に応答して、プロデューサ１４８０が、生成されるべき親プロデューサに対するスティッキーサブスクリプション特性に基づいてインスタンス生成されることを指示する。図１４Ｃの例示的な第２行を参照すれば、クラスキー、メソッドキー、インスタンスキー、及びリンクモードは、親クラス列１４３０、親メソッド列１４３５、インスタンス列１４３７、及び親リンクモード列１４２５から各々アクセスされる。親プロデューサは、アクセスされたクラスキー、アクセスされたインスタンスキー（ブランクのままにした場合は、トリガープロデューサ（図１４Ｃでは、プロデューサ１４７５）のインスタンスキー）、及びアクセスされたメソッドキーより成るプロデューサキーを有し、即ち図１４Ｃの例では、これは、プロデューサ１４８０である。丸４は、インスタンス生成された親プロデューサ１４８０が、プロデューサグラフにおいて、アクセスされたリンクモード（前記例では、リンクモード形式＝引数依存性；リンクモード引数ＩＤ＝Ｙ）を通して子のトリガープロデューサ１４７５にリンクされることを指示する。又、丸４において、引数依存性の場合に、スティッキーインジケータは、スティッキーであることを指示するようにセットされ、即ちインスタンス生成された親プロデューサ１４８０のベースとなるメソッドに対するプロデューサ依存性宣言ステートメントの位置におけるプロデューサ依存性を、プロデューサ１４８０に対して無視しなければならないことを指示するようにセットされ、これは、スティッキーサブスクリプションプロデューサ依存性により生成されるリンクが、その後の自動プロデューサグラフ発生オペレーションにより上書きされることを防止する。
本発明の一実施形態では、トリガープロデューサに対するスティッキーサブスクリプション基準は、プロデューサキーを作り上げるキーの１つ以上である。従って、プロデューサキーが、クラスキー、インスタンスキー及びメソッドキーより成る実施形態では、トリガーに対するスティッキーサブスクリプション基準は、クラス、インスタンス及びメソッドキーの１つ以上である。例えば、図１１Ｃを参照すれば、トリガープロデューサに対するスティッキーサブスクリプション基準を満足するものについてのインスタンス生成されたプロデューサを通るスキャンは、インスタンス生成されたプロデューサのキーがトリガープロデューサに対するスティッキーサブスクリプション基準のキーに一致するかどうか決定するための、プロデューサグラフ（１つ又は複数）構造の第１列−第３列の１つ以上を通るスキャンである。本発明の一実施形態では、トリガープロデューサに対するスティッキーサブスクリプション基準は、プロデューサキーを作り上げるキーの１つ以上であるが、本発明の別の実施形態では、アブソービングサブスクリプション基準は、プロデューサを作り上げるより限定された数のキーである。
図１４Ｄ−Ｅは、本発明の一実施形態による親依存性決定プロデューサに基づく親プロデューサの選択を示す。図１４Ｄ−Ｅは、引数依存性について説明するが、本発明の実施形態は、シーケンス及びフィールド依存性の使用もサポートできる。
図１４Ｄは、本発明の一実施形態により、スティッキーサブスクリプションにより生成される親依存性決定プロデューサに基づく親プロデューサの選択を示す。図１４Ｃと同様に、図１４Ｄは、スティッキーサブスクリプションプロデューサ１４７０及びトリガープロデューサ１４７５を示しているが、プロデューサ１４８０ではなく、図１４Ｄは、スティッキーサブスクリプションプロデューサ１４７０のスティッキーサブスクリプションを通して生成された依存性決定プロデューサ１４８０を示している。更に、図１４Ｄは、スティッキーサブスクリプションのリンクモードが、引数依存性、引数ＩＤ＝Ｘ、及びスティッキーインジケータ＝スティッキーであることも示している。プロデューサ１４７５から依存性決定プロデューサ１４８０への破線の曲線で示されたように、依存性決定プロデューサにより返送されるＤＥＰは、プロデューサ１４７５それ自体の出力（引数ＩＤ＝Ｘの引数）に基づくものである。図１４Ｄにおいて、依存性決定プロデューサ１４８０は、プロデューサ１４８２に対する非サブスクリプション上方宣言プロデューサ依存性を、引数依存性及び引数ＩＤ＝Ｙを指示するリンクモードと共に返送する。図１４ＤではＸ及びＹの引数ＩＤを使用して、それらが異なることを示すが、それらが等しくてもよいことを理解されたい。
図１４Ｅは、本発明の一実施形態により、シーケンス依存性によりリンクされる子依存性決定プロデューサによって生成される親依存性決定プロデューサに基づく親プロデューサの選択を示す。図１４Ｅは、図１４Ｄと構造が類似し、より詳細には、プロデューサ１４７５、１４８０及び１４８２が、プロデューサ１４８６、１４９６及び１４９８に置き換えられる。しかしながら、プロデューサ１４８０と１４７５との間にリンクを生成するスティッキーサブスクリプションプロデューサ１４７０ではなく、プロデューサ１４８６は、依存性決定プロデューサ１４９４に対するシーケンス依存性（例えば、UpwardDependency又はWeaklyConstrainedDependencyを通して生成された）を有し、これは、非サブスクリプション上方宣言依存性を通して依存性決定プロデューサ１４９６を生成する。
スティッキーサブスクリプション及び非サブスクリプション上方宣言依存性（例えば、UpwardDependencies及び／又はWeaklyConstrainedDependenciesを通して生成される）は、プロデューサグラフのボトムアップ構築を生じさせる（先に述べたトップダウン構築ではなく）ことに注意する価値がある。更に、このボトムアップ構築は、単一レベルの構築に制限されず、複数のレベルでもよい（例えば、スティッキーサブスクリプション又は非サブスクリプション上方宣言依存性のために、親プロデューサがインスタンス生成される場合には、その同じ親プロデューサがスティッキーサブスクリプションのためのトリガープロデューサであってもよいし、又は非サブスクリプション上方宣言依存性を含み、別の親プロデューサのインスタンス生成を生じさせ、等々でもよい）。この意味で、スティッキーサブスクリプション及び非サブスクリプション上方宣言依存性は、プロデューサグラフの構築を逆転する。
本発明の幾つかの実施形態において、スティッキーサブスクリプション特性により識別される親プロデューサは、標準プロデューサであるが（図１４Ｃを参照）、別の実施形態は、他の形式のプロデューサの識別をサポートするように具現化されてもよい。例えば、依存性決定プロデューサを識別するスティッキーサブスクリプション特性を許す本発明の実施形態では（図１４Ｄを参照）、そのような依存性決定プロデューサは、トリガープロデューサの出力にアクセスし、そしてその出力に基づき、子プロデューサにくっつく必要のある親プロデューサとしての特定プロデューサの生成をトリガーすることができる（この親プロデューサは、予め存在してもしなくてもよく、予め存在する場合には、それが単にリンクされそして子プロデューサがその引数に追加されるが、存在しない場合には、それがクリアされる）。依存性決定プロデューサが一定プロデューサを返送するケースは、アブソービングサブスクリプションに類似している。依存性決定プロデューサが、トリガープロデューサごとにインスタンスキーが独特であるプロデューサを返送する（例えば、インスタンスキーがトリガープロデューサのプロデューサキーであるプロデューサを返送する）ケースは、子プロデューサごとに個別の親プロデューサを生じ、純粋なスティッキーサブスクリプションと称される。依存性決定プロデューサが、トリガープロデューサごとに一定でも独特でもないインスタンスキーを返送するケースは、純粋なスティッキーサブスクリプション及びアブソービングサブスクリプションの振舞いを混合することができ、非純粋のスティッキーサブスクリプションと称される。
例示的な効果
上述したように、本発明の一実施形態では、プロデューサ依存性は、手動インボケーションシーケンスコードを使用せずに、適切なインスタンスを使用してメソッドインボケーションシーケンスを指定する仕方としてメソッドに対して宣言され（ここで、適切なインスタンスは、引数として使用するためのインスタンス、インスタンスメソッドにより使用されるべきインスタンス、及びクラスメソッドにより使用されるメタクラスインスタンスを含み）；実際上、幾つかの又は全ての手動インボケーションシーケンスコードを発生する作業は、次のものに置き換えられる。１）プロデューサ依存性宣言を書き込むためにアプリケーションプログラマーにより行われる作業；及び２）プロデューサグラフ（１つ又は複数）を発見及び構築し、そしてそのプロデューサグラフ（１つ又は複数）のプロデューサを実行するためにランタイムにより行われる作業。ランタイムを書く努力は、比較的多大であるが、ランタイムに対して書かれたオブジェクト指向のアプリケーションを実行するのに使用できるという点で一度書くだけでよく、対照的に、典型的なアプリケーションでは、プロデューサ依存性宣言を書くための努力は、手動インボケーションシーケンスコードを書くのに比して僅かである。
非ダイナミックなプロデューサ依存性は、非条件付きメソッドインボケーションシーケンスコードを指定する仕方を与え、従って、非条件付き手動インボケーションシーケンスコードを書く必要性を回避する。コンティンジェントのプロデューサ依存性は、条件付き処理を指定する仕方を与え、従って、条件付き手動インボケーションシーケンスコードを書く必要性に取って代わる。プロデューサの集合を返送できるようにするプロデューサ依存性をサポートすることは、パラメータとして通される前に集合の充填を指定する仕方を与え、従って、パラメータとして通される前に集合を充填するために手動インボケーションシーケンスコードに複数のコールを書き込む必要性を回避する。サブスクリプションをサポートすることは、プログラマーが、聴取されるオブジェクトの各形式に対して特定の聴取コードを書き込む必要のない環境を与える（例えば、プロデューサグラフ指向のプログラミングスプレッドシートにおいては、アブソービングサブスクリプション基準で範囲内のセルを識別させ、そしてアブソービングサブスクリプションに新たなプロデューサが追加されるたびに平均値を再計算することにより、アブソービングサブスクリプションを使用して、ある範囲のセル（各セルはプロデューサである）の平均値を計算することができ；又、プロデューサグラフ指向のプログラミングスプレッドシートにおいては、スティッキーサブスクリプション基準で通貨コンテンツを保持するセルを識別させ、そして通貨換算を行うスティッキープロデューサ（１つ又は複数）のスティッキーサブスクリプション特性をインスタンス生成させることにより、スティッキーサブスクリプションを通貨コンバータとして使用することができる（スティッキーサブスクリプションにより生成された（換算金額を保持する）プロデューサは、次いで、他のセルにおいて表示するように使用できる）。
オペレーション
新インスタンスコマンド
図１５は、本発明の一実施形態により新たなインスタンスをインスタンス生成するためのフローチャートである。図１０を参照して上述したように、図１０の新クラスモジュール１０９５は、新インスタンスモジュール１０９８の一部分として具現化することができる。図１５のフローチャートは、このような実施形態を仮定するもので、新インスタンスモジュール１０９８により遂行され、新クラスモジュール１０９５を表す図１５のフローチャートの一部分は、ブロック１５４０及び１５５０を含む破線ブロック１５８０として示されている。
新インスタンスコマンドに応答して（ブロック１５１０）、制御はブロック１５２０へ進む。ブロック１５２０において、インスタンスが既に存在するかどうか決定される。もし存在しなければ、制御はブロック１５３０へ進み、さもなければ、インスタンスをインスタンス生成する必要がなく、制御はブロック１５７０へ進み、フローチャートが終了となる。インスタンスキーをサポートする一実施形態では、ブロック１５２０は、新インスタンスコマンドの一部分として与えられるインスタンスキー（及びインスタンスキーがクラスにわたって独特のものである必要がない場合にはクラスキー）に対して図１０のインスタンス追跡構造１０６５にアクセスすることにより遂行される。
ブロック１５３０では、インスタンスのクラス定義が既にロードされたかどうか決定される。ロードされていない場合は、制御はブロック１５４０へ進み、さもなければ、制御はブロック１５６０へ進む。クラスキーをサポートする一実施形態では、ブロック１５４０は、新インスタンスコマンドの一部分として与えられるクラスキーに対して図１０のクラス追跡構造１０９２にアクセスすることにより遂行される。
ブロック１５４０では、クラスがロードされ、制御がブロック１５５０へ進む。ブロック１５５０では、（クラス内のメソッドキーにより記憶される−図１１Ｄを参照））プロデューサ依存性宣言ステートメントを含めて、クラス定義がクラスキーに基づいて記憶されそしてイントロスペクトされる。ブロック１５５０から、制御は、ブロック１５６０へ進む。図１０を参照すれば、ブロック１５４０及び１５５０において次のことが遂行される。１）クラスが、ビジネスロジック１０１０を含むクラス定義から、クラス１０５４へロードされ（このロードの結果、クラスのメソッド及びプロデューサ依存性宣言がメソッド及びプロデューサ依存性宣言１０５６に記憶され）；２）クラスがクラス追跡構造１０９２に追加され；そして３）メソッドがメソッド追跡構造１０５８に追加される。更に、メソッドの出力クラスがロードされる。
ブロック１５６０では、クラスのインスタンスがインスタンスキーに基づいてインスタンス生成され記憶される。図１０を参照すれば、インスタンスは、インスタンス１０５２へとインスタンス生成され、そしてインスタンスは、インスタンス追跡構造１０６５へと追加される。ブロック１５５０から、制御は、ブロック１５７０へ進み、フローチャートが終了となる。オブジェクト関連マッピング技術が使用される本発明の幾つかの実施形態では、データを外部データソースからロードして、インスタンスのフィールドをブロック１５６０の一部分としてポピュレートすることができる。
本発明の幾つかの実施形態では、クラス及びインスタンスは、プロデューサグラフ指向のプログラミングサポートを伴うランタイムが気付かないやり方でロード／インスタンス生成される（例えば、図９Ａにおいて、ランタイム９１０が気付かない状態でランタイム９１５がロード／インスタンス生成する場合）。このようなケースにおいて、クラスInstanceKey（これは２つのエレメントを保持する：即ち、キー識別子がインスタンス又は別のオブジェクト（ストリングのような）に対するリファレンスであるかどうか指示するインスタンスキーネイチャー；及びインスタンス又は別のオブジェクト（ストリングのような）のいずれかに対するリファレンスであるキー識別子）のインスタンスであるインスタンスキーもサポートする本発明の実施形態では、ブロック１５２０及び１５３０は、プロデューサグラフ指向のプログラミングサポートを伴うランタイムが気付くやり方でインスタンス及びクラスがインスタンス生成され／ロードされるかどうか問合せする。プロデューサグラフ指向のプログラミングサポートを伴うランタイムが、既にロードされたクラスに気付かないケースでは、クラスがロードされず、クラスは、クラス追跡構造１０９２に追加され、そしてメソッドは、メソッド追跡構造１０５８に追加される。プロデューサグラフ指向のプログラミングサポートを伴うランタイムが、既にインスタンス生成されたインスタンスに気付かないケースでは、インスタンスがインスタンス生成されず、インスタンスは、インスタンス追跡構造１０６５に追加される。
新プロデューサ及び非オーバーライドコマンド
図１６は、本発明の一実施形態により新たなプロデューサをインスタンス生成し、そしてプロデューサを非オーバーライドするためのフローチャートである。図１０を参照すれば、図１５のフローは、自動プロデューサグラフ発生モジュール１０４０及びオーバーライドプロデューサモジュール１０４５（又は図１０に関する別の実施形態を参照して述べるように、オーバーライド及び非オーバーライドを取り扱うモジュール）により遂行される。
新プロデューサコマンドに応答して（ブロック１６００）、制御はブロック１６０５へ進む。本発明の一実施形態では、新プロデューサコマンドは、種々の状況に応答して実行することができる。以下のテーブル２は、本発明の一実施形態によりパスされる種々の状況及びパラメータを示す。
テーブル２
Figure 0005354603
ブロック１６０５において、プロデューサが既に存在するかどうか決定される。存在しなければ、制御はブロック１６１０へ進み、さもなければ、制御はブロック１６７０へ進む。ブロック１６０５は、新プロデューサコマンドの一部分として（例えば、キー及び／又はリファレンスにより）識別されたクラス、インスタンス及びメソッドにアクセスすることにより遂行される。プロデューサキーをサポートする一実施形態では、ブロック１６０５は、新プロデューサコマンドの一部分として与えられたプロデューサキー（テーブル２の被呼プロデューサ列におけるプロデューサキー）に対して図１０のプロデューサグラフ（１つ又は複数）構造１０６０にアクセスすることにより遂行される。
ブロック１６１０では、新インスタンスモジュールが新インスタンスコマンドでコールされ、制御はブロック１６１５へ進む。本発明の一実施形態では、ブロック１６１０は、テーブル２の被呼プロデューサ列のプロデューサキーからのインスタンスキーを使用して図１５のフローチャートをコールすることにより遂行される。
ブロック１６１５では、プロデューサのインスタンスのクラス定義がアクセスされ、制御はブロック１６２０へ進む。図１０を参照すれば、クラス追跡構造１０９２に基づいてクラス１０５４の適切な１つにアクセスするために、テーブル２の被呼プロデューサ列におけるプロデューサキーからのクラスキーを使用することによりブロック１６１５が遂行される。
ブロック１６２０では、プロデューサのメソッド及びプロデューサ依存性宣言ステートメントがアクセスされ、制御はブロック１６２５へ進む。図１０を参照すれば、ブロック１６１５で位置付けられたクラスからメソッド及びプロデューサ依存性宣言１０５６の適切な１つにアクセスするために、テーブル２の被呼プロデューサ列におけるプロデューサキーからメソッドキーを使用することによりブロック１６２０が遂行される。
ブロック１６２５では、プロデューサグラフにプロデューサが追加され、制御はブロック１６３０へ進む。図１１Ｃにおける本発明の実施形態を参照すれば、最初の３つの列がポピュレートされる。
ブロック１６３０では、各々の登録されたサブスクリプションに対して、サブスクリプションフィルタリング基準が処理されて、プロデューサが一致するかどうか決定する。図１４Ａにおける本発明の実施形態を参照すれば、サブスクリプションは、それがサブスクリプションログに追加されたときに登録されたと考える。サブスクリプションを登録するための例示的オペレーションを以下に説明する。ブロック１６３０は、自動プロデューサグラフ発生とプロデューサグラフ実行との間に分割されるべきインスタンス生成されたプロデューサをスキャンする作業を許す任意の最適化である。従って、本発明の別の実施形態では、ブロック１６３０を遂行しなくてもよい。
ブロック１６３５では、プロデューサは、依存性のためにコールされた場合にプロデューサグラフ（１つ又は複数）にリンクされる。ブロック１６３５から、制御は、ブロック１６４０へ進む。ブロック１６３５を遂行する仕方は、新プロデューサコマンドが実行される状況に依存する（図２０を参照）。例えば、それが問題とするプロデューサであるか又はオーバーライドされるプロデューサであるという状況の場合には、依存性のためにそれがコールされず、何も行われない。対照的に、状況が非サブスクリプション下方宣言である場合には、非サブスクリプション下方宣言依存性のためにそれがコールされ、図１１Ｃにおける本発明の実施形態を参照すれば、次のことが行われる。１）被呼子プロデューサの親プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１５０（テーブル２の被呼プロデューサ列）が、親発呼プロデューサの行に対する親プロデューサリファレンス（テーブル２の発呼プロデューサ列）、及び依存性決定プロデューサリファレンス（テーブル２の依存性決定プロデューサリファレンス列）で変更され；及び２）親発呼プロデューサの行の子プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１６０（テーブル２の発呼プロデューサ列）が、被呼子プロデューサの行に対する子プロデューサリファレンス（テーブル２の被呼プロデューサ列）、依存性決定プロデューサリファレンス（テーブル２の依存性決定プロデューサリファレンス列）、及びリンクモード（テーブル２のリンクモード列によりセットされる）で変更される。
対照的に、状況がスティッキーサブスクリプションである場合には、それは、識別されるトリガープロデューサのためにコールされたものであり、図１１Ｃにおける本発明の実施形態を参照すれば、次のことが行われる。１）発呼子プロデューサの親プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１５０（テーブル２の発呼プロデューサ列）が、親被呼プロデューサの行に対する親プロデューサリファレンス（テーブル２の被呼プロデューサ列）、及び依存性決定プロデューサリファレンス（テーブル２の依存性決定プロデューサリファレンス列）で変更され；及び２）親被呼プロデューサの行の子プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１６０（テーブル２の被呼プロデューサ列）が、発呼子プロデューサの行に対する子プロデューサリファレンス（テーブル２の発呼プロデューサ列）、依存性決定プロデューサリファレンス（テーブル２の依存性決定プロデューサリファレンス列）、リンクモード（テーブル２のリンクモード列によりセットされる）、及びスティッキーを指示するようにセットされたスティッキーインジケータで変更される。この点に関して、非サブスクリプション上方宣言依存性の状況は、スティッキーサブスクリプションと同様に取り扱われる。
ブロック１６４０において、プロデューサは、非実行とマークされ、制御はブロック１６４５へ進む。図１１Ｃにおける本発明の実施形態を参照すれば、適切な行の増分的実行マーキング列１１８０に、非実行指示がポピュレートされる。
ブロック１６４５では、プロデューサが何らかの依存性を有しそしてオーバーライドされないかどうか決定される。もしそうであれば、制御はブロック１６５０へ進み、さもなければ、制御はブロック１６６５へ進む。ブロック１６４５は、ブロック１６２０においてアクセスされたプロデューサ依存性宣言及びテーブル２のコール形式列をチェックすることにより遂行される。
ブロック１６５０では、現在解明されるべきプロデューサ依存性宣言の各依存性に対して、プロデューサの数が決定され、そして各々に対して新プロデューサコマンドがインボークされる。ブロック１６５０から、制御はブロック１６５５へ進む。本発明の異なる実施形態は、異なる時間に異なる形式の依存性を決定し、本発明の一実施形態においてブロック１６５０を遂行する仕方について以下に説明する。
ブロック１６５５では、プロデューサは、その全ての従属プロデューサが存在しそして実行された場合に実行スタートログに追加される。ブロック１６５５から、制御はブロック１６６０へ進む。このフローの現在繰り返しの一部分としてインスタンス生成される所与のプロデューサに対して、ブロック１６５５が遂行されるときには、所与のプロデューサが依存するプロデューサに対するこのフローの別の繰り返しのインボケーションでそのプロデューサの実行状態が返送される（ブロック１６６０を参照）（例えば、図１１Ｃの本発明の実施形態に関しては、適切な行（１つ又は複数）の増分的実行マーキング列１１８０からの状態）。全ての従属プロデューサが存在し且つ全ての従属プロデューサの実行状態が実行される場合には、現在繰り返しのプロデューサが実行スタートログに追加される。
ブロック１６６０では、プロデューサの実行状態がパラメータとして返送される。
ブロック１６７０では、ブロック１６３５と同様に、プロデューサは、依存性のためにコールされた場合にプロデューサグラフ（１つ又は複数）にリンクされる。ブロック１６７０から、制御はブロック１６７５へ進む。種々の理由でブロック１６７０に到達する。例えば、プロデューサがプロデューサオーバーライドコマンドに応答して以前にインスタンス生成されたがプロデューサグラフにリンクされないために、ブロック１６７０に到達する。別の例として、プロデューサがプロデューサグラフの既に一部分でありそして別のものに追加される（例えば、問題とするプロデューサ、問題とするプロデューサの子孫、等であることに応答して以前にインスタンス生成された）ためにブロック１６７０に到達することがある。
ブロック１６７５では、オーバーライド、スティッキーサブスクリプション依存性、又は非サブスクリプション上方宣言依存性のために、新プロデューサフローがコールされるかどうか決定される。もしそうであれば、制御はブロック１６８０へ進み、さもなければ、制御はブロック１６６０へ進む。ブロック１６７５は、テーブル２のコール形式列をチェックして、それが、オーバーライドされたプロデューサに対するコールであるか、スティッキーサブスクリプション依存性に対するコールであるか、又は非サブスクリプション上方宣言依存性に対するコールであるか調べることにより、遂行される。
ブロック１６８０では、ブロック１６４０と同様に、プロデューサは、非実行とマークされ、制御はブロック１６６５へ進む。ブロック１６８０は、種々の理由で到達する。
ブロック１６６５では、プロデューサは、それがまだ存在しない場合に実行スタートログに追加され、そして制御は、ブロック１６６０へ進む。
プロデューサ非オーバーライドコマンドに応答して（ブロック１６９０）、制御はブロック１６９５へ進む。ブロック１６９５では、プロデューサが非オーバーライドとマークされ、制御はブロック１６４０へ進む。図１１Ｃの本発明の実施形態を参照すれば、プロデューサの行のプロデューサ出力キャッシング及びオーバーライドプロデューサ出力指示列１１７０がアクセスされ、そしてプロデューサがもはやオーバーライドされないことを指示するように変更される。このフローを続けると、ブロック１６４０は、ブロック１６４５へ通じ、又、プロデューサが何らかの依存性を有する場合には、ブロック１６５０へ通じ、これは、プロデューサのもとでのプロデューサグラフがまだない場合には、それを発見し構築するようにさせる。プロデューサのもとでのプロデューサグラフが既に発見され構築されている場合には、新プロデューサコマンドをインボークすると、フローが１６００から１６０５へ、１６７０へ、等々と進み、更に、ブロック１６６０においてプロデューサのもとでのグラフのプロデューサの実行状態を返送すると、ブロック１６５５において実行スタートログにプロデューサが追加されるかどうか決定される。しかしながら、プロデューサのもとでのプロデューサグラフが発見及び構築されない場合には、新プロデューサコマンドをインボークすると、それが発見及び構築され、フローは、１６００から１６０５へ、１６１０へ、等々と進む。
図１７は、本発明の一実施形態による図１６のブロック１６５０のためのフローチャートである。従って、制御は、ブロック１６４５からブロック１６５０におけるブロック１７００へと進む。ブロック１７００において、プロデューサのプロデューサ依存性宣言における各依存性に対して（各ArgumentDependenciy、FieldDependency、SequencingDependency、UpwardDependency及びWeaklyConstrainedDependencyに対して１つづつ）、次のブロック１７０５−１７４５が遂行される。図１０及び１１Ｄを参照すれば、メソッド追跡構造がアクセスされ、プロデューサ依存性に関する情報が決定される。又、ブロック１７１５、１７２５、１７３０、１７４０、１７４５及び１７５０は、プロデューサグラフを実行する前に遂行されたときに最適となることも理解されたい。
ブロック１７０５では、依存性が、スティッキー依存性のために既にリンクされた引数依存性であるかどうか決定される。もしそうであれば、制御はブロック１７１０へ進み、そこで、この依存性に対してフローが完了し、さもなければ、制御はブロック１７１５へ進む。図１１Ｃに示す本発明の実施形態に関しては、スティッキーインジケータがチェックされ、この依存性の引数ＩＤがスティッキーサブスクリプション引数依存性を受けるか又は上方宣言引数依存性を受けるかを決定する。
ブロック１７１５では、依存性がコンティンジェント依存性であるかどうか決定される。もしそうであれば、制御はブロック１７２０へ進み、さもなければ、制御はブロック１７２５へ進む。ブロック１７１５は、依存性により識別された子プロデューサのプロデューサ依存性宣言をチェックして、それが空である（子プロデューサが独立プロデューサである）かどうか決定することにより、遂行される。図１３Ａ−Ｊを参照すれば、これは、破線の丸内の数字を伴うプロデューサ（例えば、図１３Ｄでは、プロデューサＣＵ：：ＩＶ：：ＤＥＬＴＡ）については真であるが、他のプロデューサ（例えば、図１３Ｄでは、プロデューサＣＷ：：ＩＹ：：ＢＥＴＡ）については真でない。従って、図１３Ｄを参照すれば、ブロック１７１５は、丸１、４及び８により表わされる。ブロック１７１５及びそこからブロック１７２５−１７５０を通るフローは、最適なものであって、破線の丸内の数字を伴うプロデューサをプロデューサグラフに追加／リンクすることと、プロデューサを実行する作業を自動プロデューサグラフ発生とプロデューサグラフ実行との間で分割すること、を回避する。
ブロック１７２０では、依存性決定プロデューサに対する新プロデューサコマンドがインボークされ、そしてフローが終了となる。例えば、図１３Ｄを参照すれば、ブロック１７２０は、丸５、６及び７で表わされたものを生じさせる。
ブロック１７２５では、依存性決定プロデューサが実行され、制御はブロック１７３０へ進む。例えば、図１３Ｄを参照すれば、ブロック１７２５が丸１１で示されている（従って、図１７のフローは、図１３Ｄの丸９及び１０が遂行されない前記実施形態を示している）。
ブロック１７３０では、依存性が非サブスクリプション依存性であるかどうか決定される。もしそうであれば、制御はブロック１７５０へ進み、さもなければ、制御はブロック１７４０へ進む。換言すれば、ブロック１７２５では、親プロデューサのプロデューサ依存性宣言の一部分である依存性決定プロデューサのメソッドにおけるプロデューサ依存性決定コードが実行される。この依存性がサブスクリプション依存性であるかどうか識別するこのプロデューサ依存性宣言コードが実行されると、親プロデューサのプロデューサ依存性の形式が決定される。図１３Ｄの例に関して、丸１１は、ブロック１７３０からブロック１７５０へ進む図１７のフローを生じさせる。
ブロック１７５０では、ブロック１７２５における依存性決定プロデューサの実行により返送されるプロデューサの数が決定され、そして１７２５において実行された依存性決定プロデューサリファレンスを含めて、テーブル２に示す引数を使用して、各々に対して新プロデューサコマンドがインボークされる。例えば、図１３Ｄを参照すれば、ブロック１７５０が丸１２及び１３と、丸Ｃ及びＤとを生じさせる。
図１４Ｂのアブソービングサブスクリプション実施例を参照すれば、ブロック１７２５は丸４を表し、これは、ブロック１７３０を通してブロック１７４０へと進むフローを生じさせる。
ブロック１７４０において、サブスクリプションがサブスクリプションログに追加され、そしてサブスクリプションがアブソービングである場合には、それが未完了とマークされる。ブロック１７４０から、制御はブロック１７４５へ進む。図１４Ａに示す本発明の実施形態を参照すれば、サブスクリプションログは、上述したようにサブスクリプションでポピュレートされる。
ブロック１７４５では、インスタンス生成された全てのプロデューサがスキャンされ、それらがサブスクリプションの基準に一致する（従って、トリガープロデューサである）かどうか調べられ、そして一致が処理される。
図１８は、本発明の一実施形態による図１７のブロック１７４５に対するフローチャートである。従って、制御は、ブロック１７４０から、ブロック１７４５におけるブロック１８００へ進む。ブロック１８００では、インスタンス生成される各プロデューサに対して、次のブロック１８１０−１８３０が遂行される。
ブロック１８１０では、プロデューサがサブスクリプションの基準を満足するかどうか決定される。もしそうであれば、制御はブロック１８１５へ進み、さもなければ、制御はブロック１８３０へ進み、そこで、現在処理されているプロデューサについてフローが終了となる。図１１Ｃ及び１４Ａに示す本発明の実施形態を参照すれば、プロデューサグラフ（１つ又は複数）がアクセスされ、それらが、サブスクリプションの基準を満足するプロデューサを含むかどうか決定する。
マッチングプロデューサを処理する仕方は、処理されるサブスクリプションの形式に依存する。ブロック１８１５を参照すれば、サブスクリプションがアブソービング形式である場合には、制御はブロック１８２５へ進み、さもなければ、制御はブロック１８２０へ進む。ブロック１８１５は、ブロック１７４０又は２２３５において追加されるサブスクリプションの形式に応答して遂行される。
ブロック１８２５では、マッチングプロデューサがサブスクリプションログに追加されそしてアブソービングサブスクリプションを伴うプロデューサがマッチングプロデューサにリンクされる。ブロック１８２５から、制御はブロック１８３０へ進む。図１１Ｃ及び図１４Ａ−Ｂに示す本発明の実施形態を参照すれば、次のことが行われる。１）トリガープロデューサ列１４１０のためのサブスクリプション基準からのサブスクリプション基準がブロック１８１０に使用され、そしてマッチングプロデューサが探索され（例えば、プロデューサ１５６０Ａ−Ｎの１つ）；２）マッチングプロデューサが、サブスクリプションの行においてマッチングプロデューサ列１４１５に追加され；そして３）アブソービングサブスクリプションを伴うプロデューサ（例えば、プロデューサ１４５０）が図１１Ｃのプロデューサグラフ（１つ又は複数）構造におけるマッチングプロデューサ（例えば、プロデューサ１４６０Ａ−Ｎの１つ）にリンクされる（所与のアブソービングサブスクリプションに対してサブスクリプションログ１４Ａの依存性決定プロデューサリファレンス列１４２１から抽出された依存性決定プロデューサリファレンスを使用して）。
ブロック１８２０では、生成されるべき親プロデューサに対して新プロデューサコマンドがインボークされる。ブロック１８２０から、制御はブロック１８３０へ進み、そこで、ブロック１８００において選択された現在プロデューサに対してフローが終了となる。図１４Ａ及び１４Ｃに示す本発明の実施形態を参照すれば、次のことが行われる。１）トリガープロデューサ列１４１０に対するサブスクリプション基準からのサブスクリプション基準がブロック１８１０において使用され、そしてマッチングプロデューサが探索され（例えば、プロデューサ１４７５）；そして２）次のようにセットされたテーブル２のパラメータで新プロデューサコマンドがインボークされる。ａ）コール形式はスティッキーサブスクリプションであり；ｂ）発呼プロデューサは、発呼子プロデューサ（例えば、プロデューサ１４７５）のプロデューサキーであり；ｃ）被呼プロデューサは、生成されるべき被呼親プロデューサ（例えば、プロデューサ１４８０）のプロデューサキーであり、このプロデューサキーは、生成されるべき親プロデューサに対するスティッキーサブスクリプション特性からの親クラス、インスタンス及びメソッドキー（図１４Ａ、列１４３０、１４３５及び１４３７）を使用して（インスタンスキーが空である場合には、発呼子プロデューサのインスタンスキーを使用して）形成され；及びｄ）被呼親プロデューサに対するリンクモード（図１４Ａ、リンクモード列１４２５）、並びにｅ）所与のスティッキーサブスクリプションに対するサブスクリプションログ１４Ａの依存性決定プロデューサリファレンス列１４２１から抽出される依存性決定プロデューサリファレンス。
図１９は、本発明の一実施形態による図１６のブロック１６３０のためのフローチャートである。従って、制御は、ブロック１６２５から、ブロック１６３０におけるブロック１９００へと進む。図１９は、図１８に非常に良く似ている。より詳細には、図１９のブロック１９１０、１９１５、１９２０及び１９３０は、ブロック１８１０、１８１５、１８２０及び１８３０と同一であり、一方、ブロック１９００及び１９２５は、ブロック１８００及び１８２５とは異なる。従って、相違点のみについてここに説明する。
ブロック１９００は、各登録されたサブスクリプションに対してフローが遂行されることを示し、一方、ブロック１８００は、各インスタンス生成されたプロデューサに対してフローが遂行されることを示す。従って、図１８のフローは、単一のサブスクリプションを中心として全てのプロデューサをスキャンするが、図１０のフローは、単一のプロデューサを中心として全てのサブスクリプションをスキャンする。
ブロック１９２５は、アブソービングサブスクリプションが未完了とマークされることを除いて、ブロック１８２５と同じである。図１４Ａに示す本発明の実施形態を参照すれば、適切な行における完了列１４２０が、未完了を示すように更新される。
図２０は、本発明の一実施形態による図１６のブロック１６３５及び１６７０のためのフローチャートである。従って、制御は、ブロック１６０５及びブロック１６３０から、ブロック１６３５及び１６７０におけるブロック２００５へ進む。ブロック２００５において、図１６のフローチャートのこの繰り返しが、依存性のために（例えば、以前の繰り返しのブロック１６３０（ブロック１９２０）又は１６５０（ブロック１７２０、１７５０又は１７４５／１８２０から）インボークされたものであるかどうか決定される。もしそうでなければ、制御は、どこからフローに入ったか（ブロック１６３０又は１６０５から）に基づいてブロック１６４０又は１６７５へ進む。
ブロック２０１０において、フローがスティッキーサブスクリプション又は非サブスクリプション上方宣言状態のためにコールされたかどうか決定される。もしそうでなければ、制御はブロック２０１５へ進み、さもなければ、制御はブロック２０２０へ進む。ブロック２０１０は、テーブル２からのコール形式パラメータ（即ち、コール形式がスティッキーサブスクリプション又は非サブスクリプション上方宣言であるかどうか）をチェックすることにより遂行される。図１８及び１９に示す本発明の実施形態を参照すれば、新プロデューサコマンドは、ブロック１８２０又は１９２０からインボークされる。
ブロック２０２０では、現在親プロデューサが、発呼側の子プロデューサにリンクされる。図１１Ｃ及び図１４Ｃに示す本発明の実施形態を参照すれば、テーブル２の被呼プロデューサ列からのパラメータにより識別された被呼親プロデューサ（例えば、プロデューサ１４８０）は、図１１Ｃのプロデューサグラフ（１つ又は複数）構造において、テーブル２のリンクモード及び依存性決定プロデューサリファレンス列からのパラメータにより識別されたリンクモード及び依存性決定プロデューサリファレンスを使用して、テーブル２の発呼プロデューサ列からのパラメータにより識別された発呼子プロデューサ（例えば、プロデューサ１４７５）へリンクされる。親が以前に存在した場合には、ブロック２０２０の振舞いは、０以上の子プロデューサへマップできる引数が１つであるという意味で、アブソービングサブスクリプション依存性の振舞いと同様になる。
ブロック２０１５では、発呼親プロデューサは、現在被呼子プロデューサにリンクされる。図１１Ｃに示す本発明の実施形態を参照すれば、テーブル２の発呼プロデューサ列からのパラメータにより識別された発呼親プロデューサは、図１１Ｃのプロデューサグラフ（１つ又は複数）構造において、テーブル２の依存性決定プロデューサリファレンス列により識別された依存性決定プロデューサリファレンスを使用して、テーブル２の被呼プロデューサ列からのパラメータにより識別された被呼子プロデューサにリンクされる。ブロック２０１５及び２０２０から、制御は、フローがどこに入ったか（ブロック１６０５又は１６３０から）に基づいてブロック１６４０又は１６７５へ進む。
図２１は、本発明の一実施形態によりプロデューサをオーバーライドするためのフローチャートである。図１０を参照すれば、図２１のフローは、オーバーライドプロデューサモジュール１０４５（又は図１０に関する別の実施形態を参照して述べたように、オーバーライド及び非オーバーライドを取り扱うモジュール）により遂行される。
オーバーライドプロデューサコマンドに応答して（ブロック２１１０）、制御はブロック２１２０へ進む。ブロック２１２０では、オーバーライドプロデューサコマンドにより識別されたプロデューサに対して新プロデューサコマンドがインボークされ、制御はブロック２１３０へ進む。ブロック２１２０は、本発明の一実施形態では、オーバーライドされるべきプロデューサがまだインスタンス生成されていない場合、プロデューサを非実行とマークし（ブロック１６４０又は１６８０）そしてそれを実行スタートログにログする（ブロック１６６５）ように遂行される。まだインスタンス生成されていないプロデューサのオーバーライドを許さない本発明の別の実施形態では、ブロック１６０５と１６１０との間で付加的なチェックを行って、この新プロデューサコマンドがオーバーライドプロデューサコマンドに応答してコールされたかどうか決定し、そしてこの新プロデューサコマンドがオーバーライドプロデューサコマンドに応答してコールされた場合にはエラーを指示する。
ブロック２１３０では、プロデューサ出力キャッシュ（及びフィールドの場合にはインスタンス）における出力がセットされ、そしてプロデューサが、オーバーライドされたとしてマークされる。
グローバルな実行コマンド
図２２Ａは、本発明の一実施形態により現在プロデューサグラフを実行するためのフローチャートの一部分であり、一方、図２２Ｂは、本発明の一実施形態により現在プロデューサグラフを実行するためのフローチャートの別の部分である。図１０を参照すれば、図２２のフローは、プロデューサグラフ実行モジュール１０７０により遂行される。
グローバルな実行コマンドに応答して、ブロック２２００は、候補プロデューサのセットが、実行スタートログにおけるプロデューサに基づいて実行されるべく選択されることを示し、制御はブロック２２０５へ進む。オーバーライドされたプロデューサが非実行とマークされ、それを実行すると、それらのオーバーライドされた結果が返送される（それらのメソッドを実行させるのではなく）本発明の一実施形態では、候補プロデューサの現在セットは、実行スタートログにおけるプロデューサである。オーバーライドされたプロデューサが非実行とマークされ、それを実行すると、それらのオーバーライドされた結果が返送される（それらのメソッドを実行させるのではなく）本発明の一実施形態を上述したが、別の実施形態は、異なる仕方で動作してもよい（例えば、オーバーライドされたプロデューサを実行とマークし、そして候補プロデューサの現在セットの選択時に、実行スタートログの独立プロデューサ及び実行スタートログにおけるオーバーライドされたプロデューサの親が選択される）。
ブロック２２０５では、実行の準備ができたプロデューサのサブセットが候補プロデューサのセットから選択され、そして制御はブロック２２１０へ進む。ブロック２２０５を遂行する例示的な仕方をここに説明する。
ブロック２２１０では、レディプロデューサの現在セットの中のプロデューサは、形式により分類され、標準プロデューサは、ブロック２２１５へ進み、そして依存性決定プロデューサは、ブロック２２２５へ進む。本発明の一実施形態では、ブロック２２１０は、プロデューサのリターンクラスをチェックすることにより遂行される。図１０及び図１１Ｄを参照すれば、メソッド追跡構造がアクセスされ、プロデューサの出力クラスがＤＥＰであるかどうか決定し、従って、このプロデューサは、依存性決定プロデューサである。
ブロック２２１５では、レディプロデューサの現在セットにおける標準的プロデューサが実行されて、制御はブロック２２２０へ進む。本発明の一実施形態では、ブロック２２１５は、引数依存性から生じる子プロデューサの出力からマップされた入力パラメータでメソッドをコールすることにより遂行される（引数については、リンクモードの引数ＩＤを使用して、適切な子プロデューサの出力を、実行されているメソッドの適切な入力引数へとマップする。本発明のある実施形態では、このような実行は、所与のメカニズムに出力を書き込む子プロデューサのメソッドにおけるコード（例えば、グローバル変数をセットし、プロデューサ出力でないインスタンスのフィールドをセットし、外部データソースにインパクトを与え、等々）、又は所与のメカニズムからその出力を読み取る親プロデューサのメソッドにおけるコードを実行させる。ブロック２２２０では、これらの実行された標準プロデューサのいずれかにアブソービングサブスクリプションを有する親がもしあれば、それらに対して、サブスクリプションは、未完了とマークされる。ブロック２２２０から、制御はブロック２２４５へ進む。図１４Ａを参照すれば、完了列１４２０の適切な行は、未完了を指示するようにセットされる。
ブロック２２２５では、レディプロデューサの現在セットにおける依存性決定プロデューサが実行準備され、そして制御はブロック２２３０へ進む。ブロック２２２５を遂行する例示的な仕方は、以下に述べる。
ブロック２２３０では、レディプロデューサの現在セットにおける依存性決定プロデューサが実行され、そして制御はブロック２２３５へ進む。本発明の一実施形態では、ブロック２２３０は、ブロック２２１５と同様に遂行される。
ブロック２２３５では、発見されたプロデューサに対して新プロデューサコマンドが実行され、そしてサブスクリプションに対してサブスクリプションログ及び処理が遂行される。ブロック２２３５の新プロデューサコマンド部分は、ブロック１７５０と同様に遂行され、一方、サブスクリプションログ及び処理は、ブロック１７４０及び１７４５と同様に遂行される。
ブロック２２４０では、実行スタートログに新たに追加された候補プロデューサのセットに追加がなされる。ブロック２２４０から、制御はブロック２２４５へ進む。ブロック２２４０は、ブロック２２３０及び２２３５の結果として実行スタートログに新たに追加されたプロデューサのみが候補プロデューサのセットに追加されることを除いて、ブロック２２００と同様に遂行される。
ブロック２２４５では、実行されたプロデューサが、実行されたとマークされ、プロデューサ出力キャッシング（及びインスタンスキャッシング）が、必要に応じて更新され、実行されたプロデューサの親プロデューサが候補プロデューサの現在セットに追加され、そして実行されたプロデューサが候補及びレディプロデューサの現在セットから除去される。ブロック２２４５から、制御はブロック２２５０へ進む。
ブロック２２５０では、候補プロデューサのセットが空であるかどうか決定される。もし空でなければ、制御がブロック２２０５へ戻り、さもなければ、制御はブロック２２５５へ進む。
ブロック２２５５では、全てのサブスクリプションが完了されたかどうか決定される。もしそうであれば、制御はブロック２２６５へ進み、そこで、フローが終了となるが、さもなければ、制御はブロック２２６０へ進む。図１４Ａにおける本発明の実施形態を参照すれば、未完了のアブソービングサブスクリプションに対してサブスクリプション形式列１４０５及び完了列１４２０がスキャンされる。
ブロック２２６０では、未完了のアブソービングサブスクリプションが処理され、制御がブロック２２０５へ戻る。ブロック２２６０を遂行する例示的な仕方について、以下に説明する。
図２３は、本発明の一実施形態による図２２のブロック２２０５のためのフローチャートである。従って、制御は、ブロック２２００から、ブロック２２０５のブロック２３０５へ進む。ブロック２３０５では、候補プロデューサのセットにおける各プロデューサに対して、次のブロック２３１０−２３２５が遂行される。
ブロック２３１０では、プロデューサが、未完了のアブソービングサブスクリプション依存性を有するかどうか決定される。もしそうであれば、制御はブロック２３２５へ進み、さもなければ、制御はブロック２３１５へ進む。図１４Ａの実施形態を参照すれば、現在選択されたプロデューサ及びアブソービングサブスクリプション形式への一致に対してサブスクライバープロデューサキー列１４００及びサブスクリプション形式列１４０５がスキャンされ、一致が見つかった場合には、適切な行における完了列１４２０がチェックされて、そのアブソービングサブスクリプション依存性の状態を決定する。
ブロック２３１５では、現在選択されたプロデューサが依存するところのプロデューサが実行されるかどうか決定される。実行されない場合には、制御がブロック２３２５へ進み、さもなければ、制御がブロック２３２０へ進む。図１１Ｃに示す本発明の実施形態に関して、子依存性の行に対する増分的実行マーキング列１１８０がチェックされて、現在選択されたプロデューサの子の実行状態が決定される。
ブロック２３２０では、現在選択された候補プロデューサがレディプロデューサの現在セットに追加され、制御はブロック２３２５へ進む。
ブロック２３２５では、ブロック２３０５で選択された現在プロデューサに対してフローが終了となる。
図２４は、本発明の一実施形態による図２２のブロック２２２５のフローチャートである。従って、制御は、ブロック２２１０からブロック２２２５におけるブロック２４０５へ進む。ブロック２４０５では、各依存性決定プロデューサに対して、次のブロック２４１０−２４３０が遂行される。
ブロック２４１０では、現在選択された依存性決定プロデューサにより発生された以前の依存性の形式が決定される。依存性の形式が非サブスクリプションである場合には、制御がブロック２４２０へ進み；その形式がアブソービングサブスクリプションである場合には、制御がブロック２４１５へ進み；一方、その形式がスティッキーサブスクリプションである場合には、制御がブロック２４２５へ進む。ブロック２４１０は、プロデューサ出力キャッシングに記憶されたプロデューサの現在出力をチェックすることにより決定される。クラスＤＥＰを参照すれば、出力は、非サブスクリプション、アブソービングサブスクリプション、及びスティッキーサブスクリプションを指示する。
両ブロック２４１５及び２４２５において、サブスクリプションログからエントリーが除去される。図１４Ａ−Ｃに示す本発明の実施形態を参照すれば、次のことが行われる。１）アブソービングサブスクリプション（ブロック２４１５）に対して、依存性決定プロデューサ（例えば、プロデューサ１４５５）を使用して、プロデューサグラフ（１つ又は複数）におけるその親プロデューサ（例えば、プロデューサ１４５０）が決定され、次いで、サブスクリプションログにおいて親プロデューサがルックアップされて、そのエントリーが除去され；及び２）スティッキーサブスクリプション（ブロック２４２５）に対して、サブスクリプションログにおいて依存性決定プロデューサ（例えば、プロデューサ１４７０）がルックアップされ、そしてそのエントリーが除去される。ブロック２４１５から、制御がブロック２４２０へ進み；ブロック２４２５から、制御がブロック２４２０へ進む。
ブロック２４２０では、現在選択された依存性決定プロデューサにより既に生成されたリンクがプロデューサグラフ（１つ又は複数）からクリアされ、そして制御がブロック２４３０へ進む。図１１Ｃに示す本発明の実施形態を参照すれば、次のことが行われる。依存性決定プロデューサが既存のプロデューサにおいて「スティッキー」状態であるかどうか最初に決定される。これは、図１１Ｃにおける依存性決定プロデューサの子プロデューサリンク列をスキャニングし、そしてリンクの１つが、スティッキーを指示するスティッキーインジケータを有するかどうかチェックすることで行われる。
依存性決定プロデューサが既存のプロデューサにおいてスティッキー状態でない場合には、１）非サブスクリプション下方宣言依存性（引数、フィールド又はシーケンス依存性）を発生した依存性決定プロデューサに対して、依存性決定プロデューサの親が、プロデューサグラフにおいて、現在選択された依存性決定プロデューサの行での親プロデューサリファレンス（１つ又は複数）列１１５０を通してアクセスされ、この親プロデューサエントリーにおいて、依存性決定プロデューサリファレンスとマッチングさせるように子プロデューサ（１つ又は複数）リンク（１つ又は複数）列１１６０がアクセスされ、そしてその依存性決定プロデューサリファレンスを有する子プロデューサの全リファレンスがクリアされ；２）非サブスクリプション上方宣言依存性を発生した依存性決定プロデューサに対して、依存性決定プロデューサの親が、プロデューサグラフにおいて、現在選択された依存性決定プロデューサの行での親プロデューサリンク（１つ又は複数）列１１５０を通してアクセスされ、この親プロデューサエントリーにおいて、依存性決定プロデューサリファレンスとマッチングさせるように親プロデューサリンク（１つ又は複数）列１１５０がアクセスされ、そしてその依存性決定プロデューサリファレンスを有する親プロデューサの全リファレンスがクリアされ；３）アブソービングサブスクリプションを発生した依存性決定プロデューサに対して、非サブスクリプション下方宣言依存性と同じ振舞いが遂行され；及び４）スティッキーサブスクリプションを発生した依存性決定プロデューサに対して、サブスクリプションを除去する前にサブスクリプションログ１４Ａの列１４２１から抽出された依存性決定プロデューサリファレンスが、プロデューサグラフ（１つ又は複数）構造において、親プロデューサリンク（１つ又は複数）列１１５０にてルックアップされ、そしてその依存性決定プロデューサリファレンスを有する親プロデューサの全リファレンスがクリアされる。
非サブスクリプション上方宣言依存性又はスティッキーサブスクリプションの結果として、依存性決定プロデューサが既存のプロデューサにおいてスティッキー状態である場合には、依存性決定プロデューサがスティッキー状態となっている子プロデューサがアクセスされ（スティッキーを指示するスティッキーインジケータを伴う列１１６０における子プロデューサ）、そしてこの子プロデューサエントリーにおいて、依存性決定プロデューサリファレンスとマッチングさせるように親プロデューサリンク（１つ又は複数）列１１５０がアクセスされ、そしてその依存性決定プロデューサリファレンスを有する親プロデューサの全リファレンスがクリアされる。
ブロック２４３０では、ブロック２４０５で選択された依存性決定プロデューサに対してフローが終了となる。
図２５は、本発明の一実施形態による図２２のブロック２２６０のためのフローチャートである。従って、制御は、ブロック２２５５から、ブロック２２６０におけるブロック２５０５へ進む。ブロック２５０５では、未完了のアブソービングサブスクリプション依存性を伴う各プロデューサに対して、次のブロック２５１０−２５２５が遂行される。
ブロック２５１０では、全てのマッチングプロデューサが実行されたかどうか決定される。もしそうであれば、制御はブロック２５１５へ進み、さもなければ、制御はブロック２５２５へ進む。図１１Ｃ及び１４Ａの実施形態を参照すれば、適切な行におけるマッチングプロデューサ列１４１５がアクセスされて、マッチングプロデューサが決定され、そして適切な行における増分的実行列１１８０が各マッチングプロデューサについてチェックされる。
ブロック２５１５では、アブソービングサブスクリプションが完了とマークされ、制御はブロック２５２０へ進む。図１４Ａの実施形態を参照すれば、適切な行における完了列１４２０が、完了を指示するようにセットされる。
ブロック２５２０では、ブロック２５０５で選択されたプロデューサが候補プロデューサの現在セットに追加され、そして制御はブロック２５２５へ進む。
ブロック２５２５では、ブロック２５０５で選択されたプロデューサについてフローが終了となる。
シナリオ
ある実施形態では、シナリオは、同じインスタンスの同じメソッドを異なるパラメータで複数回インボークする結果を伴う集合のファイリングを指定する仕方を与え、従って、異なるパラメータで同じインスタンスの同じメソッドを複数回インボケーションすることを手動インボケーションシーケンスコードに書き込む必要性を回避する。ダイナミック依存性をサポートする本発明の幾つかの実施形態では、異なるインスタンス、異なるメソッド、及び／又は異なるクラスがシナリオに使用される場合に、アプリケーションの２つの異なるシナリオが、構造上個別のプロデューサグラフ又はサブグラフをアプリケーションのプロデューサグラフに有することができる。例えば、数値の名前付きベクトルを入力として得る数学的モデルに基づいて出力を計算するための例示的アプリケーションプログラムが与えられる。異なる名前付きベクトルを使用するインパクトを評価するため、異なるベクトルインスタンスを使用するシナリオを生成することができ、ここで、各インスタンスは、個別のベクトルに対応する。或いは又、例示的アプリケーションプログラムは、同じベクトルインスタンスを使用するが、異なる数学的モデルを使用して、問題とする出力を計算してもよい。第２の数学的モデルの採用に対する第１の数学的モデルの採用のインパクトを評価するために、第１のシナリオ及び第２のシナリオを生成することができる。第１のシナリオでは、第１モデルを表す第１メソッドがインボークされる。第２のシナリオでは、第２モデルを表す第２メソッドがインボークされる。更に、第１シナリオにおけるクラスは、第２シナリオにおけるクラスと同じでもよいし、そうでなくてもよい。第１及び第２のメソッドが同じクラス内であるように定義される場合には、クラスは、第１及び第２シナリオにおいて同じままである。しかしながら、第１メソッドが第１クラス内であるように定義され、且つ第２メソッドが第１クラスとは異なる第２クラス内であるように定義される場合には、第１及び第２のシナリオは、異なるクラスを有する。第１クラスの第１メソッド及び第２クラスの第２メソッドは、同じ名前を有してもよいし、そうでなくてもよいことに注意されたい。
図２６は、シナリオをサポートする本発明の別の実施形態を示す。図１Ａに示した１つの実施形態と同様に、オブジェクト指向のソースコード１００は、クラス１０２を含み、このクラスは、次いで、メソッド１０４、及びメソッド１０４に対するプロデューサ依存性宣言１０６を含む。もちろん、クラス１０２は、典型的に、１つ以上のフィールド（図示せず）及び付加的なメソッド（図示せず）を含む。更に、オブジェクト指向のソースコード１００は、典型的に、付加的なクラスを含む。
図１Ａを参照して上述したように、ランタイム中に、クラス１０２のインスタンス１０８がインスタンス生成される。インスタンス１０８は、クラス１０２のフィールドのデータを含む。更に、プロデューサ１１０がインスタンス生成され、プロデューサ１１０は、クラス１０２、クラス１０２のインスタンス１０８（クラス１０２のメソッド１０４に関連した）、及びクラス１０２のメソッド１０４を識別する。プロデューサ依存性宣言１０６は、プロデューサ１１０を実行する前に実行されねばならない０以上のプロデューサ１１２のセット（プロデューサ１１０の子プロデューサと称される）をランタイムに対して識別する。換言すれば、プロデューサ１１０は、０以上のプロデューサ１１２のセットに依存する。プロデューサ１１２のセットの出力を消費するのに加えて又はそれに代わって、プロデューサ１１０は、インスタンス１０８のデータを消費することができる。更に、プロデューサ１１０は、少なくとも１つの出力を与え、この出力は、インスタンス１０８に対して内部であってもよく（従って、インスタンス１０８のデータを変更し）、及び／又は外部であってもよく、いずれにせよ、プロデューサ１１０の出力は、０以上の他のプロデューサ１１４のセット（プロデューサ１１０の親プロデューサと称される）によって消費することができる。幾つかの実施形態では、プロデューサ１１０、親プロデューサ１１４、及び子プロデューサ１１２を含むプロデューサグラフは、独特の第１シナリオキーを有する第１シナリオに関連付けられる。
第１シナリオとは個別の第２シナリオに対するプロデューサグラフ又はサブグラフを生成するために、１つ以上のプロデューサ１１０、１１２及び１１４をストレス化することができる。プロデューサをストレス化するために、プロデューサが複写される。一実施形態では、プロデューサは、クラス宣言１０２、所与のメソッド１０４、及びプロデューサ依存性宣言１０６からプロデューサをインスタンス生成することにより複写することができる。或いは又、プロデューサは、リファレンスシナリオ（上述した第１シナリオのような）に対して対応する既存のプロデューサをクローン化又はコピーすることにより複写されてもよい。両技術の幾つかの実施形態の詳細を以下に述べる。一般的には、直接的にインパクトされる全てのプロデューサがストレス化される。更に、直接的にインパクトされるプロデューサに依存するプロデューサ、即ち間接的にインパクトされるプロデューサがストレス化されてもよい。一実施形態では、間接的にインパクトされるプロデューサは、その間接的にインパクトされるプロデューサが、問題とするプロデューサと、直接的にインパクトされるプロデューサとの間の経路に入る場合に、ストレス化される。図２６に戻ると、プロデューサ１１０が第２シナリオに対する直接的にインパクトされるプロデューサであるとすれば、プロデューサ１１０は、第２シナリオに対するストレス化プロデューサを発生するようにストレス化される。プロデューサ１１０の全ての親プロデューサ１１４は、その全ての親プロデューサ１１４がプロデューサ１１０に依存するので、間接的にインパクトされる。親プロデューサ１１４のセット内の親プロデューサが、問題とするプロデューサと、プロデューサ１１０との間の経路に入る場合には、親プロデューサがストレス化される。プロデューサ１１０のストレス化された親プロデューサ（１つ又は複数）の集合は、第２のシナリオに対してセット２６１４により表される。更に、セット２６１４内の幾つかのプロデューサ間にダイナミック依存性がある場合に、セット２６１４内のプロデューサは、第２のシナリオに対して繰り返しストレス化されてもよい。プロデューサ１１０の子プロデューサ１１２に関して、子プロデューサ１１２は、第２のシナリオに対してストレス化されなくてもよい。というのは、子プロデューサ１１２は、プロデューサ１１０に依存しないからである。しかしながら、セット１１２内の子プロデューサが第２のシナリオにおいて直接的又は間接的にインパクトされる場合には、セット１１２内のインパクトされる子プロデューサは、第２のシナリオに対してストレス化された子プロデューサを発生するようにストレス化されてもよい。プロデューサ２６１０、２６１２及び２６１４間の依存性は、第２のシナリオにおいて不変のままでもよい。或いは又、プロデューサ２６１０、２６１２及び２６１４間の依存性の幾つか又は全部が第２のシナリオにおいて変化してもよい。図２６において、第２のシナリオのプロデューサグラフが破線で示されている。
本発明の一実施形態において、アプリケーションプログラムの第１プロデューサグラフ内の全てのプロデューサが新たなシナリオに対してストレス化される。その結果、ストレス化されたプロデューサのプロデューサグラフが生成されて、アプリケーションプログラムを表すプロデューサグラフの集合に追加される。しかしながら、幾つかの実施形態では、プロデューサのサブセットのみをストレス化して、新たなシナリオに対して第１プロデューサグラフ内のサブグラフを生成するように、最適化を許すことができる。シナリオに対するプロデューサグラフ又はサブグラフの生成の幾つかの実施形態の更なる詳細を以下に述べる。
図２７Ａは、本発明の一実施形態により、プロデューサグラフ指向のプログラミングサポート及びシナリオサポートを伴うランタイムを示すブロック図である。参照番号３２０、３２５、３３０、３３５、３４０、３８０、３８４及び３４５の詳細を、図３Ａを参照して述べる。シナリオをサポートするために、ランタイム３３５は、シナリオインスタンス生成情報３２８も受け取る。このシナリオインスタンス生成情報３２８は、種々の仕方を経て、例えば、クライアントコード（例えば、グラフィックユーザインターフェイス（ＧＵＩ）、コマンドラインインターフェイス（ＣＬＩ）、等）を経て、ランタイム３３５に与えることができる。或いは又、シナリオインスタンス生成情報３２８は、プロデューサ依存性宣言（例えば、プロデューサ依存性宣言ステートメント又はプロデューサ依存性宣言コード）において指定されてもよい。或いは又、シナリオインスタンス生成情報３２８の幾つか又は全部が、ストレス化プロデューサ発生プロデューサのメソッドのソースコードにおいて指定されてもよい。ストレス化プロデューサ発生プロデューサの詳細を以下に述べる。
本発明の一実施形態によれば、シナリオインスタンス生成情報３２８がランタイム３３５の新シナリオモジュール３３７に与えられる。シナリオインスタンス生成情報３２８に基づいて、新シナリオモジュール３３７は、新たなシナリオをインスタンス生成する。幾つかの実施形態では、ランタイム３３５は、シナリオキーと、１つ以上の直接的にインパクトされるプロデューサのセット及びその直接的にインパクトされるプロデューサの対応所定出力又は出力変換を指定できるシナリオオブジェクトに対するリファレンスと、シナリオによりインパクトされるプロデューサのリストをその後に保持するインパクト経路追跡構造と、を記憶するためのシナリオ追跡構造３３８を含む。出力を問題とする１つ以上のストレス化されたプロデューサの現在セット３２５に基づいて、自動プロデューサグラフ発生モジュール３４０は、シナリオ追跡構造３３８に作用することにより問題とする１つ以上のストレス化されたプロデューサに対するプロデューサグラフ又はサブグラフを発生することができる。シナリオにおける１つ以上の直接的にインパクトされるプロデューサの１つ以上の所定の出力により問題とするストレス化されたプロデューサに及ぼされるインパクトを評価するために、プロデューサグラフ実行モジュール３４５は、シナリオに対する所定の出力又は出力変換により直接的又は間接的にインパクトされるプロデューサを実行するために発生されるプロデューサグラフ又はサブグラフを通してウオークすることができる。
幾つかの実施形態では、シナリオ情報３２８は、リファレンスシナリオキーと、ターゲットシナリオキーと、１つ以上の直接的にインパクトされるプロデューサ及びその直接的にインパクトされるプロデューサの対応する所定の出力のリストと、を含む。一般的に、シナリオキーとは、シナリオを識別するための独特のキーである。ある実施形態では、リファレンスシナリオとは、アプリケーションプログラムの現在状態及び出力を含む既存のシナリオである。ターゲットシナリオとは、直接的にインパクトされるプロデューサ及びそれに対応する出力のリストに起因するインパクトの集合である。ターゲットシナリオの場合に、直接的にインパクトされるプロデューサのリストにより識別されるプロデューサの出力は、そのリストに指定された出力でオーバーライドされようとする。ランタイム３３５は、リファレンスシナリオを使用して、直接的にインパクトされるプロデューサにより間接的にインパクトされるプロデューサを見出すことができる。直接的にインパクトされるプロデューサにより問題とするストレス化されたプロデューサに及ぼされるインパクトは、リファレンスシナリオを上書き又は変更せずにターゲットシナリオを使用して評価することができる。換言すれば、プロデューサの既存の出力及び／又はインスタンスは、第１シナリオに対して保存され又は維持される。ある実施形態では、リファレンスシナリオのプロデューサグラフの一部分は、問題とするプロデューサがその一部分に依存し且つその一部分がターゲットシナリオにおける直接的にインパクトされるプロデューサにより直接的又は間接的にインパクトされない場合には、ターゲットシナリオのプロデューサグラフにリンクすることができる。換言すれば、リファレンスシナリオのプロデューサグラフ内にターゲットシナリオのサブグラフを生成することができる。
図２７Ｂは、本発明の一実施形態により、増分的実行及びオーバーライドされたプロデューサ出力、並びにシナリオもサポートするプロデューサグラフ指向のプログラミングサポートを伴うランタイムを示すブロック図である。コンポーネント３２０、３２５、３５０、３５２、３５４、３６０、３６５、３８０、３８２、３８４、３７０、３９６、３９０、３９２及び３９４の詳細は、図３Ｂを参照して上述した。シナリオをサポートするために、シナリオインスタンス生成情報３２８が自動プロデューサグラフ発生モジュール３６５へ入力される。シナリオインスタンス生成情報３２８の幾つかの実施形態の詳細は、図２７Ａを参照して上述した。シナリオインスタンス生成情報３２８に基づいて、自動プロデューサグラフ発生モジュール３６５は、各シナリオに対するプロデューサグラフ又はサブグラフを構成することができる。シナリオに対するプロデューサグラフ又はサブグラフの構造の幾つかの実施形態を以下に詳細に述べる。問題とするストレス化されたプロデューサ（即ち、特定のシナリオに対する問題とするプロデューサ）に対するインパクトを評価するために、プロデューサグラフ実行モジュール３７０は、そのシナリオに対して生成されたプロデューサグラフ又はサブグラフを通してウオークし、それに応じてプロデューサを実行する。シナリオに対するプロデューサグラフ又はサブグラフの実行の幾つかの実施形態を以下に詳細に述べる。
幾つかの実施形態では、シナリオインスタンス生成情報３２８は、対応するシナリオにおける１つ以上の直接的にインパクトされるプロデューサの出力をオーバーライドするオーバーライドプロデューサ出力モジュール３９０に送られる。このオーバーライドプロデューサ出力モジュール３９０のオペレーションの詳細は、図３を参照して上述した。
図２８Ａ−Ｄは、異なるシナリオに対するアプリケーションプログラムの幾つかの例示的プロデューサグラフを示す。図２８Ａを参照すれば、シナリオ１に対するプロデューサグラフが上部に示され、そしてシナリオ２に対するプロデューサグラフが下部に示されている。シナリオ１及び２は、各々、シナリオキー“Ｓ１”及び“Ｓ２”を有する。幾つかの実施形態では、シナリオ１は、デフォールトシナリオ又はリファレンスシナリオとも称される。サンプルアプリケーションプログラムは、少なくとも７つのプロデューサ、即ちプロデューサ１ないしプロデューサ７を有し、ここで、プロデューサ１は、プロデューサ３及びプロデューサ４に直接依存し、プロデューサ２は、プロデューサ４に直接依存し、プロデューサ３は、プロデューサ５及びプロデューサ６に直接依存し、そしてプロデューサ４は、プロデューサ７に直接依存する。シナリオ１において、プロデューサ７の出力は、Ｘ1の値を有し、そしてプロデューサ１の出力は、Ｚ1の値を有する。
幾つかの実施形態において、ストレス化されたプロデューサは、一対のプロデューサキー及びシナリオキーにより識別される。例えば、シナリオ２におけるストレス化されたプロデューサ１は、対｛プロデューサ１、Ｓ２｝により識別される。ストレス化されたプロデューサは、種々の仕方を経て、例えば、クライアントコード（例えば、ＧＵＩ、ＣＬＩ、等）を経て、ユーザにより指定することができる。或いは又、アプリケーションプログラムは、１つ以上のストレス化されたプロデューサを発生するためにストレス化プロデューサ発生プロデューサを含んでもよい。ストレス化プロデューサ発生プロデューサ、即ちプロデューサ８の実施形態が図２８Ｂに示されている。図２８Ｂを参照すれば、プロデューサ８の例示的疑似コードが図面の右側に示されている。最初、ストレス化プロデューサのクラスは、問題とするプロデューサキーを表すフィールド及びシナリオを表すフィールドを有するものとして定義される。ここに示す例では、プロデューサ８は、独立であり、プロデューサ８のプロデューサ依存性宣言ステートメントは、ナルである。次いで、プロデューサ８のメソッドは、シナリオ２のシナリオ情報を与え、ストレス化プロデューサのフィールドに値を指定し、そしてストレス化プロデューサの集合を出力することができる。
図２８Ａに戻ると、シナリオ２は、次のシナリオ情報により定義される。即ち、リファレンスシナリオキー＝ナル、ターゲットシナリオキー＝Ｓ２、並びに直接的にインパクトされるプロデューサ及びそれに対応する出力のリスト。ここに示す例では、直接的にインパクトされるプロデューサのリストは、指定出力Ｘ2を有する１つのプロデューサ、即ちプロデューサ７しか有していない。しかしながら、シナリオには直接的にインパクトされるプロデューサが複数あることが明らかであろう。幾つかの実施形態では、図２８Ａに示すように、プロデューサ１ないしプロデューサ７の各々を生成することにより、シナリオ２に対してプロデューサグラフ全体が再現される。シナリオ２に対するプロデューサグラフにおいて、直接的にインパクトされるプロデューサ、即ちプロデューサ７の出力は、シナリオ２の定義で指定された出力、即ちＸ2でオーバーライドされる。ここに示す例における問題とするプロデューサは、プロデューサ１である。シナリオ２に対するプロデューサグラフを実行することにより、問題とするストレス化プロデューサ、即ちシナリオ２のプロデューサ１の出力がＺ2であることが決定される。既存のプロデューサグラフ内のシナリオに対するサブグラフを発生するための別の解決策を利用することができ、その幾つかの実施形態を以下に説明する。
シナリオ２に対する第２のプロデューサグラフが生成されるので、シナリオ２に対してなされる変更（例えば、プロデューサ７の出力をオーバーライドすること）がシナリオ１に対するプロデューサグラフに影響を及ぼすことはない。従って、シナリオ１に対するプロデューサの出力は、シナリオ２に対してなされる変更でアプリケーションプログラムを実行することにより上書きされない。従って、シナリオを生成する技術は、アプリケーションプログラムにおけるプロデューサの既存の出力を失うことなく、変更の潜在的な又は考えられるインパクト及び／又は作用を評価する上で有用である。種々の理由で、例えば、限定された相違を使用してプロデューサの導関数を自動的に決定するために、プロデューサの既存の出力を保持し又は保存することが有用である。図２８Ａの実施形態に戻り、そしてＺ1、Ｚ2、Ｘ1及びＸ2が数値であると仮定すれば、シナリオ１からシナリオ２への問題とするプロデューサ、即ちプロデューサ１の導関数は、シナリオ１及びシナリオ２の両方からの出力を使用して次のように容易に計算することができる。

プロデューサ１の導関数＝(Ｚ2−Ｚ1)／(Ｘ2−Ｘ1)

更に、高次の導関数、即ちＮ次の導関数（但し、Ｎは、１より大きい整数）も、異なるシナリオからの出力を使用して容易に計算することができる。幾つかの実施形態では、あるシナリオから別のシナリオへ２つ以上の入力が変化するときに、問題とするプロデューサの出力の交差導関数を計算することができる。例えば、あるシナリオから別のシナリオへ入力Ｘ1及びＹ1がＸ2及びＹ2へ各々変化されると仮定する。その結果、問題とするプロデューサの出力がＺ1からＺ2へ変化される。次いで、問題とするプロデューサの出力の交差導関数は、次のように計算することができる。

問題とするプロデューサの交差導関数＝(Ｚ2−Ｚ1)2／((Ｘ2−Ｘ1)＊(Ｙ2−Ｙ1))

ランタイムは、異なるシナリオに対するプロデューサ出力を追跡でき且つプロデューサの導関数を自動的に決定できるので、プログラマーは、手動のインボケーションシーケンスコードを書き込んで、アプリケーションプログラムを複数回実行し、それに対応する出力を追跡し、そしてそれに対応する出力を使用して導関数を計算するメソッドをコード化する必要がない。
上述したように、シナリオ２に対するサブグラフを発生するための別の解決策を利用することができる。幾つかの別の解決策が図２８Ｃ及び２８Ｄに例示されている。
図２８Ｃを参照すれば、シナリオ１（即ち、リファレンスシナリオ）に対するプロデューサグラフの一部分をリンクするための技術を使用して、シナリオ２（即ち、ターゲットシナリオ）に対するプロデューサグラフが発生される。最初、ランタイムは、問題とするプロデューサがプロデューサ１であることを指示するために、ユーザからクライアントコードを経て新ストレス化プロデューサコマンドを受け取ることができる。或いは又、ストレス化プロデューサ発生プロデューサ、例えば、プロデューサ８が、新ストレス化プロデューサコマンドのインボケーションをトリガーしてもよい。新ストレス化プロデューサコマンドに応答して、ランタイムは、デフォールトシナリオ又はリファレンスシナリオとも称されるシナリオ１に対するプロデューサ１のためのプロデューサグラフを構成する。次いで、第２の新ストレス化プロデューサコマンドがユーザからクライアントコードを経て受け取られるか、又はストレスプロデューサ発生プロデューサ（例えば、プロデューサ８）によりトリガーされて、問題とするプロデューサがプロデューサ２であることを指示する。第２の新ストレス化プロデューサコマンドに応答して、ランタイムは、プロデューサ２をシナリオ１のためのプロデューサグラフへ追加する。
次いで、ランタイムは、シナリオ２を定義するシナリオ情報を受け取る。この場合も、シナリオ情報は、クライアントコードからのものでよい。シナリオ情報は、リファレンスシナリオキーが“Ｓ１”であると指定し、ターゲットシナリオキーが“Ｓ２”であると指定し、そしてターゲットシナリオに対する直接的にインパクトされるプロデューサ及びその対応出力のリストを指定する。直接的にインパクトされるプロデューサのリストは、ここに示す例では１つのプロデューサ、即ちプロデューサ７、及びプロデューサ７の出力、即ちＸ2しか含まない。
アプリケーションプログラムにおいて、プロデューサ１のようなプロデューサに対するシナリオ２のインパクト又は作用、即ちプロデューサ７の出力をＸ2に変化させることを評価するために、プロデューサ１が、問題とするプロデューサとして識別される。更に、プロデューサが、問題とするシナリオで識別される。従って、問題とするプロデューサキー及びシナリオキーの対であるストレス化プロデューサが識別され、即ち｛プロデューサ１、Ｓ２｝となる。幾つかの実施形態では、問題とするプロデューサが、ユーザにより、ＧＵＩ、ＣＬＩ、等のクライアントコードを経て識別される。或いは又、問題とするプロデューサが、ストレス化プロデューサ発生プロデューサ（例えば、プロデューサ８）の出力において識別されてもよい。
プロデューサとシナリオ情報との間の依存性に基づいて、ランタイムは、シナリオ２に対する直接的及び間接的にインパクトされる両プロデューサを識別することができる。直接的及び間接的にインパクトされるプロデューサの識別は、追跡と称されてもよい。直接的及び間接的にインパクトされるプロデューサは、インパクトされた経路追跡構造（ＩＰＴＳ）を使用して追跡することができる。ここに示す例では、インパクトされた経路追跡構造は、プロデューサ７、プロデューサ４、プロデューサ１、及びプロデューサ２を含む。プロデューサ１、２及び４は、シナリオ２に対する間接的にインパクトされるプロデューサであり、一方、プロデューサ７は、直接的にインパクトされるプロデューサであることに注意されたい。幾つかの実施形態では、シナリオ２のインパクトリストを使用して、ランタイムは、直接的にインパクトされるプロデューサ（１つ又は複数）を識別することができる。次いで、ランタイムは、シナリオ１に対するプロデューサグラフを使用して、図２８Ｃに［Ｂ］、［Ｃ］、［Ｄ］及び［Ｅ］で示すように、直接的にインパクトされるプロデューサからシナリオ１に対するプロデューサグラフを横断することにより、間接的にインパクトされるプロデューサを追跡することができる。シナリオ１に対するプロデューサグラフがまだ構成されていない場合には、ランタイムは、間接的にインパクトされるプロデューサを追跡する前に、シナリオ１に対するプロデューサグラフを構築することができる。或いは又、リファレンスシナリオが与えられないか、又はリファレンスシナリオのプロデューサグラフがまだ構成されない場合に、ランタイムは、問題とするプロデューサ、直接的にインパクトされるプロデューサ、及びシナリオ２に対してこれら問題とするプロデューサと直接的にインパクトされるプロデューサとの間の経路に入る中間プロデューサを、前記プロデューサの対応するメソッド及びプロデューサ依存性宣言を使用して、生成することができる。
幾つかの実施形態では、ランタイムは、インパクトされた経路追跡構造を通して進み、そのインパクトされた経路追跡構造における各インパクトされたプロデューサに対する新ストレス化プロデューサコマンドをインボークする。発生されたストレス化プロデューサは、シナリオ１に対する既存のプロデューサグラフのサブグラフを形成するように相互接続される。インボケーションのシーケンスは、重要でない。というのは、新ストレス化プロデューサ（即ち、シナリオ２に対するプロデューサ１、２、４及び７）は、図２８Ｃに［Ｇ］で示されたように、それらが生成されるときに互いに相互接続されるからである。問題とするプロデューサがリファレンスシナリオに存在しない実施形態では、そのような問題とするプロデューサは、インパクトされた経路追跡構造において追跡されない。それでも、ランタイムは、そのような問題とするプロデューサに対して新ストレス化プロデューサコマンドをインボークし、シナリオ２に対するプロデューサグラフを生成する。
シナリオ２に対するプロデューサグラフを最適化するために、プロデューサ７によって直接的又は間接的にインパクトされず問題とするプロデューサに依存するプロデューサ、即ちプロデューサ１は、シナリオ２において複写又はストレス化されなくてもよい。むしろ、それらのプロデューサは、シナリオ１からシナリオ２のプロデューサグラフにリンクされる。ここに示す例では、これらプロデューサは、プロデューサ３、５及び６を含み、ここで、プロデューサ１はプロデューサ３に直接依存し、プロデューサ３はプロデューサ５及び６に直接依存する。図２８Ｃに示すように、［Ｆ］においてシナリオ１のプロデューサ３をシナリオ２のプロデューサ１にリンクするためのリンクが生成される。従って、プロデューサ３及びプロデューサ３の子プロデューサ（即ち、プロデューサ５及びプロデューサ６）を有するシナリオ１のプロデューサグラフのサブセットがシナリオ２のプロデューサグラフにリンクされる。換言すれば、シナリオ１に対するプロデューサグラフ内のサブグラフがシナリオ２に対して生成される。プロデューサ３は、プロデューサ７に直接的又は間接的に依存しないので、シナリオ２に対するプロデューサ７へのインパクトは、プロデューサ３に影響しないことに注意されたい。
シナリオ２のプロデューサグラフを生成するプロセスを更に最適化するために、ランタイムは、問題とするプロデューサが直接的又は間接的に依存していないプロデューサを、そのようなプロデューサがシナリオ２においてインパクトされるかどうかに関わらず、複写もストレス化もしない。このような最適化の一例が図２８Ｄに示されている。図２８Ｃと同様に、シナリオ１に対するプロデューサグラフが生成され、そしてプロデューサ１がシナリオ２における問題とするプロデューサとして識別され、ここで、シナリオ２は、上述したように定義される。幾つかの実施形態では、図２８Ｄに［Ａ］で示すように、問題とするプロデューサ、即ちプロデューサ１において、新ストレス化プロデューサコマンドがインボークされる。この新ストレス化プロデューサコマンドは、ユーザによりクライアントコードを経てインボークされてもよいし、又はストレス化プロデューサ発生プロデューサ、例えば、図２８Ｂのプロデューサ８によりトリガーされてもよい。
初期依存性宣言順序に基づき、ランタイムは、プロデューサ１がその順序において依存するプロデューサ上で新ストレス化プロデューサコマンドをインボークすることができる。例えば、初期依存性宣言においてプロデューサ４の前にプロデューサ３が到来する場合には、新ストレス化プロデューサコマンドが、先ず、プロデューサ３上で、次いで、プロデューサ４上でインボークされ、そしてその逆のことも言える。新ストレス化プロデューサコマンドがプロデューサ３上でインボークされると、プロデューサ３はシナリオ２においてインパクトされないので、シナリオ２におけるプロデューサ１をシナリオ１におけるプロデューサ３にリンクするためのリンクが［Ｆ］において生成される。新ストレス化プロデューサコマンドがプロデューサ４上でインボークされると、図２８Ｄに［Ｇ］で示すように、ストレス化プロデューサ４がシナリオ２においてクローン化される。ストレス化プロデューサ４をシナリオ２においてクローン化するために、ランタイムは、プロデューサ４からの情報をシナリオ１のプロデューサグラフに使用して、シナリオ２に対するサブグラフにおいてプロデューサ４のコピーを作成することができる。或いは又、ランタイムは、プロデューサ４のプロデューサ依存性宣言及びメソッドに基づいてプロデューサ４をインスタンス生成することにより新たなプロデューサ４を生成してもよい。ストレス化プロデューサ４がプロデューサグラフに追加された後に、図２８Ｄに［Ｈ］で示すように、プロデューサ７上で新ストレス化プロデューサコマンドがインボークされて、シナリオ２に対するプロデューサ７をストレス化する。プロデューサ４と同様に、プロデューサ７は、インスタンス生成又はクローン化によりストレス化されてもよい。たとえプロデューサ２がプロデューサ７により間接的にインパクトされても、シナリオ２における問題とするプロデューサ即ちプロデューサ１がプロデューサ２に直接的にも又は間接的にも依存しないので、シナリオ２においてプロデューサ２をストレス化せずに、図２８Ｄに示すように、シナリオ２に対するサブグラフが今や完全に構成されたことに注意されたい。その結果、シナリオ２に対するサブグラフを生成するプロセスが更に最適化される。
図２９は、本発明の一実施形態により、ランタイムクライアントの論理的実行フローと、プロデューサグラフ指向のプログラミングサポートを伴うランタイムに対するその関係とを示すフローチャートである。図２９において、破線の分割線６００は、ランタイムクライアント６１０の論理的実行フローを、プロデューサグラフ指向のプログラミングサポートを伴うランタイム６４０から分離している。ブロック６１５、６２０、６２５、６３０、６４５、６５０、６５５及び６６０の詳細は、図６を参照して上述した。シナリオをサポートするために、ランタイムクライアント６１０は、先ず、ブロック６１６において、新たなシナリオがあるかどうかチェックする。新たなシナリオがある場合には、ランタイムクライアント６１０は、ブロック６１７において、新たなシナリオ情報を決定する。更に、新たなシナリオをインスタンス生成するために、シナリオインスタンス生成コマンドがインボークされ又はコマンドログ６６５にログインされる。新たなシナリオコマンドに応答して、ランタイム６４０は、ブロック６４８において、新たなシナリオをインスタンス生成する。次いで、ランタイムクライアント６１０は、ブロック６１５へ移行して、実行フローを続ける。さもなければ、ランタイムクライアント６１０は、ブロック６１７をスキップし、ブロック６１５へ移行して、実行フローを続ける。ブロック６１５では、ランタイムクライアント６１０は、出力が問題である１つ以上のストレス化プロデューサのセットを決定する。次いで、ランタイムクライアント６１０は、図６を参照して上述したように、ブロック６２０へ移行して、実行フローを続ける。
シナリオに対する問題とする１つ以上のプロデューサへのインパクトを評価するために、ブロック６３０において、プロデューサグラフ実行モジュールがインボークされる。次いで、プロデューサグラフ実行モジュールは、ブロック６６０において、プロデューサグラフ又はシナリオのサブグラフを通してウオークし、追跡に基づき実行されるべきプロデューサを実行することができる。ブロック６３０では、プロデューサグラフ実行モジュールがインボークされ、そして制御は、任意であるが、ブロック６１５、ブロック６２５、及び／又はブロック６１６へ戻る。
図３０は、シナリオをサポートする本発明の一実施形態による別の具現化のブロック図である。図３０において、破線の分割線１０００は、ランタイムクライアント１００２を、プロデューサグラフ指向のプログラミングサポートを伴うランタイム１００４から分離している。ランタイムクライアント１００２及びランタイム１００４の種々のコンポーネントの詳細は、図１０を参照して上述した。従って、以下の説明は、シナリオに関連したコンポーネントに集中して行う。幾つかの実施形態では、ランタイム１００４は、更に、シナリオをサポートするために新シナリオモジュール１０９６及びシナリオ追跡構造１０５０を備えている。
図１０を参照して上述したように、新クラスモジュール１０９５は、クラス定義１０１０に基づくクラスをインスタンス生成する。インスタンス生成されたクラスの情報は、クラス追跡構造１０９２に記憶される。クラス追跡構造１０９２の一実施形態が図３１Ａに示されている。図３１Ａを参照すれば、クラスキー１１１０及びクラスリファレンス１１１５（クラスポインタのような）が、インスタンス生成されるクラスごとにクラス追跡構造に記憶される。図３０に戻ると、ランタイムクライアント１００２の側のクラス定義１０１０は、本発明の一実施形態によりストレス化プロデューサ発生プロデューサコード１０１８を含む。図２８Ｂを参照して上述したように、ストレス化プロデューサ発生プロデューサは、プロデューサキー及びシナリオキーを各々含むストレス化されたプロデューサの集合を出力するプロデューサである。ストレス化プロデューサ発生プロデューサコード１０１８の幾つかの例示的疑似コードも、図２８Ｂに示されている。シナリオをサポートするために、ランタイムクライアント１００２は、シナリオキーを伴うシナリオインスタンス生成コマンド１０１９を更に与える。シナリオキーは、インスタンスをそれに対応するシナリオ（１つ又は複数）に関連付けるために新たなインスタンスのインスタンス生成に使用される。インスタンス生成されたインスタンスの情報は、インスタンス追跡構造１０６５に記憶される。インスタンス追跡構造１０６５の実施形態が図３１Ｂに示されている。インスタンス生成されたインスタンスごとに、シナリオキー１１２３、インスタンスリファレンス１１２０、及びストレス化インスタンスリファレンス１１２５が、図３１Ｂの例示的インスタンス追跡構造に記憶される。
図３０に戻ると、ランタイムクライアント１００２は、新たなシナリオを生成するために独特のシナリオキーでシナリオインスタンス生成コマンド１０１９をインボークすることができる。シナリオインスタンス生成コマンド１０１９に応答して、新シナリオモジュール１０９６は、新たなシナリオ情報（図２７Ａのシナリオ情報３２８のような）をシナリオ追跡構造１０５０にセーブすることができる。シナリオ追跡構造１０５０の実施形態が図３１Ｄに示されている。幾つかの実施形態では、シナリオ追跡構造１０５０は、図３１Ｄに示すように、シナリオキーの列、シナリオリファレンスの列、及びインパクト経路追跡構造の列を有するテーブルを含む。シナリオキー３１１０は、シナリオを識別するためにシナリオに指定された独特なキーでよい。シナリオリファレンス３１１２は、シナリオオブジェクトを指す。インパクト経路追跡構造３１１３は、それに対応するシナリオにおいてインパクトされるプロデューサを追跡する。
図３１Ｅは、シナリオオブジェクト追跡構造の一実施形態を示す。シナリオオブジェクト追跡構造は、シナリオごとに行を有するテーブルを含む。シナリオごとに、リファレンスシナリオキー３１２０、ターゲットシナリオキー３１２２、及びインパクトリストへのリファレンス３１２４が、シナリオオブジェクト追跡構造に記憶される。ターゲットシナリオキー３１２２は、構築されるべきシナリオを識別する。従って、ターゲットシナリオキー３１２２は、図３１Ｄのシナリオ追跡構造における対応シナリオキー３１１０と同じである。リファレンスシナリオキー３１２０は、ターゲットシナリオを構築するベースとなるシナリオを識別する。リファレンスシナリオがない場合には、リファレンスシナリオキー３１２０がナルである。シナリオのインパクトリストへのリファレンス３１２４は、図３１Ｆに示す例示的インパクトリストのような、シナリオのインパクトリストを指す。
図３１Ｆにおいて、シナリオの例示的インパクトリストは、次の各々に対する列を含む。即ち、直接的にインパクトされるプロデューサキー３１３０、相対的又は絶対的インジケータ３１３４、出力インスタンス３１３２、変換パラメータ３１３６、変換メソッド名及びメソッドクラス３１３８。対応するシナリオにおける各直接的にインパクトされるプロデューサは、インパクトリストの行を占有する。直接的にインパクトされるプロデューサキー３１３０は、シナリオにおける直接的にインパクトされるプロデューサを識別する。
幾つかの実施形態では、出力値に絶対値又は相対値が指定される。相対的又は絶対的インジケータ３１３４は、出力値に絶対値が指定されるか相対値が指定されるか指示する。インジケータ３１３４が、それが絶対値であることを指示する場合には、直接的にインパクトされるプロデューサへの入力に関わらず、直接的にインパクトされるプロデューサの出力値が出力インスタンス３１３２であると指定される。さもなければ、変換パラメータ３１３６が、直接的にインパクトされるプロデューサの現在出力（即ち、リファレンスシナリオのための直接的にインパクトされるプロデューサの出力）に適用され、変換メソッド名及びメソッドクラス３１３８と共に変換メソッドを使用して直接的にインパクトされるプロデューサの現在出力を変換する。次いで、ターゲットシナリオに対する直接的にインパクトされるプロデューサの出力が、変換された現在出力でオーバーライドされる。直接的にインパクトされるプロデューサの出力は、値（数値のような）でもインスタンスでもよいことに注意されたい。例えば、直接的にインパクトされるプロデューサの現在出力が数値であり、変換パラメータ３１３６が係数値であり、そして変換メソッドが乗算である場合には、ターゲットシナリオに対する直接的にインパクトされるプロデューサの出力は、係数値と、直接的にインパクトされるプロデューサの現在出力値との積に等しい値である。別の例では、変換パラメータ３１３６が拡散値であり、そして変換メソッドが加算である場合には、ターゲットシナリオに対する直接的にインパクトされるプロデューサの出力は、拡散値と、直接的にインパクトされるプロデューサの現在出力値との和に等しい。直接的にインパクトされるプロデューサの出力値は、他の実施形態では、他の式を現在出力値の関数として使用して発生されてもよいことが明らかであろう。
図３０に戻ると、自動ストレス化プロデューサグラフ発生モジュール３０４０がシナリオ追跡構造１０５０にアクセスする。プロデューサキー及びシナリオキーを伴うストレス化プロデューサインスタンス生成コマンド１０２５に応答して、自動ストレス化プロデューサグラフ発生モジュール３０４０は、シナリオ追跡構造１０５０、クラス追跡構造１０９２、メソッド追跡構造１０５８、インスタンス追跡構造１０６５、及びインスタンス１０５２からの対応シナリオのシナリオ情報に基づき、ストレス化プロデューサをインスタンス生成することができる。或いは又、クラス定義１０１０内のストレス化プロデューサ発生プロデューサコード１０１８は、ストレス化プロデューサ発生プロデューサ３０５４のクラス及びストレス化プロデューサ３０５６を発生するメソッドを発生するためにランタイム１００４により処理される。発生されたクラス及びメソッドは、自動ストレス化プロデューサグラフ発生モジュール３０４０へ入力され、このモジュールは、それに応じてストレス化プロデューサをインスタンス生成する。自動ストレス化プロデューサグラフ発生モジュール３０４０は、対応するシナリオのためのプロデューサグラフ又はサブグラフを発生するためにインスタンス生成されたストレス化プロデューサを相互接続する。シナリオをサポートする新ストレス化プロデューサインスタンス生成フローの幾つかの実施形態を、図３４Ａ−３４Ｇを参照して以下に詳細に説明する。
本発明の一実施形態によれば、プロデューサグラフがプロデューサグラフ構造１０６０に記憶される。例示的なプロデューサグラフ構造が図３１Ｃに示されている。プロデューサグラフ構造は、図１１Ｃに示すものと実質的に同じである。各シナリオは、それに対応するプロデューサグラフ又はサブグラフにおいて個々に追跡されるので、ストレス化プロデューサグラフ実行モジュール３０７０は、シナリオに対する対応プロデューサグラフ又はサブグラフを通してウオークし、シナリオに対するストレス化プロデューサの少なくとも幾つかを実行して、シナリオに対する問題とする１つ以上のストレス化プロデューサへのインパクトを、他のシナリオに対するプロデューサの出力を上書きも変更もせずに評価することができる。シナリオをサポートするプロデューサグラフの実行フローの幾つかの実施形態を、図３５Ａ及び３５Ｂを参照して以下に詳細に説明する。
上述したランタイムクライアント１００２及びランタイム１００４においてシナリオをサポートするモジュール及び構造は、図１２に示されたもののようなコンティンジェント及びサブスクリプション形式のダイナミックプロデューサ依存性をサポートする幾つかの実施形態に追加できることに注意されたい。
図３２は、本発明の一実施形態による新シナリオインスタンス生成フローを示すフローチャートである。ブロック３２１０において、ランタイムは、新シナリオインスタンス生成コマンドを受け取る。次いで、ランタイムは、ブロック３２２０において、新シナリオインスタンス生成コマンドにより識別されたシナリオが既に存在するかどうかチェックする。シナリオが既に存在する場合には、ブロック３２９０において、新シナリオインスタンス生成のフローが終了となる。さもなければ、ランタイムは、シナリオ情報、例えば、ターゲットシナリオキー、リファレンスシナリオキー、及びシナリオのインパクトリストへのリファレンスを、ブロック３２３０において、シナリオ追跡構造に追加する。次いで、ランタイムは、ブロック３２９０へ移行し、新シナリオインスタンス生成フローが終了となる。
図３３は、本発明の一実施形態によりシナリオをサポートする新インスタンスインスタンス生成フローを示すフローチャートである。図３３は、図１５に実質的に類似し、フローの詳細は、図１５を参照して上述したことに注意されたい。シナリオをサポートするために、ランタイムは、図３３のブロック３３６０において、クラスのインスタンスをインスタンス生成し、そしてインスタンスをインスタンスキー、ストレス化インスタンスリファレンス及びシナリオキー（１つ又は複数）と共に記憶する。上述したように、シナリオごとに独特のシナリオキーがある。従って、インスタンスが複数のシナリオに関連付けられる場合には、複数のシナリオキーが存在する。一実施形態では、図３１Ｂに示したように、インスタンスキー及びシナリオキー（１つ又は複数）がインスタンス追跡構造に記憶される。図３１Ｂを参照すれば、インスタンス追跡構造は、シナリオキー１１２３、インスタンスキー１１２０、及びストレス化インスタンスリファレンス１１２５の各々に対して１つの列を含む。
図３４Ａ−３４Ｇは、本発明の一実施形態によるターゲットシナリオにおける新ストレス化プロデューサのインスタンス生成のフローチャートである。図３４Ａ−３４Ｃは、新ストレス化プロデューサのインスタンス生成の全フローを示し、一方、図３４Ｄ−３４Ｇは、全フローにおける幾つかのオペレーションの拡張フローを示す。
図３４Ａを参照すれば、ランタイムは、ブロック１６００において、新ストレス化プロデューサコマンドを受け取る。新ストレス化プロデューサコマンドは、プロデューサキー及びターゲットシナリオキーを指定する。プロデューサキー及びターゲットシナリオキーを伴うプロデューサは、新ストレス化プロデューサコマンドにより発生されるストレス化プロデューサである。本発明の一実施形態では、新ストレス化プロデューサコマンドは、種々の状況に応答して実行することができる。以下のテーブル３は、本発明の実施形態により通用される種々の状況及びパラメータを示す。
テーブル３
Figure 0005354603
新ストレス化プロデューサコマンドに応答して、ランタイムは、ブロック１６０５において、ストレス化プロデューサ（即ち、プロデューサキー及びターゲットシナリオキーを伴うプロデューサ）が既に存在するかどうかチェックする。ストレス化プロデューサが既に存在する場合には、ブロック１６７０において、プロデューサが依存性のためにコールされれば、ランタイムがプロデューサをプロデューサグラフにリンクする。さもなければ、ストレス化プロデューサが存在しない場合には、ブロック１６０１において、プロデューサが問題とするプロデューサであれば、ランタイムが、直接的及び間接的にインパクトされるプロデューサの両方を識別する。ブロック１６０１の詳細は、図３４Ｄを参照して以下に述べる。次いで、ランタイムは、ブロック１６０２へ移行して、シナリオを取り扱い、その間に、ランタイムは、プロデューサ生成の値をセットする。幾つかの実施形態では、プロデューサ生成は、３つの考えられる値、即ち、無生成、新生成、及びクローン化を有する。ブロック１６０２の詳細は、図３４Ｅを参照して以下に述べる。ランタイムは、ブロック１６０３において、プロデューサ生成の値をチェックする。プロデューサ生成が新生成である場合には、ランタイムは図３４Ｂの入口点Ａへ移行する。プロデューサ生成がクローン化である場合には、ランタイムは、図３４Ｂの入口点Ｂへ移行する。プロデューサ生成が無生成である場合には、ランタイムは、ブロック１６７０へ移行する。
ブロック１６７０の後に、ランタイムは、ブロック１６７５において、プロデューサがオーバーライドされたか、スティッキーサブスクリプションを有するか、又は上方に宣言されたかをチェックする。もしそうであれば、ランタイムは、ブロック１６８０において、プロデューサを非実行とマークすると共に、ブロック１６６５において、プロデューサを実行スタートログにログさせる。次いで、ランタイムは、ブロック１６６０において、プロデューサの実行状態を返送する。さもなければ、プロデューサがオーバーライドさればい場合には、ランタイムがブロック１６６０へ移行して、プロデューサの実行状態を返送する。図３４Ｂを参照すれば、プロデューサ生成が新生成である場合には、ランタイムが入力点Ａへ進む。入力点Ａから、ランタイムはブロック１６１０へ移行し、新たなインスタンスモジュールをコールする。次いで、ランタイムは、ブロック１６１５において、プロデューサのインスタンスのクラス定義にアクセスする。次いで、ランタイムは、ブロック１６２０において、クラス定義におけるプロデューサのメソッド及びプロデューサ依存性宣言ステートメントにアクセスする。次いで、ランタイムは、ブロック１６２５において、プロデューサをターゲットシナリオのプロデューサグラフに追加する。ランタイムは、その後、ブロック１６０４へ移行する。
図３Ａのブロック１６０３へ戻ると、プロデューサ生成がクローン化である場合には、ランタイムは、図３４Ｂの入口点Ｂへ移行する。入口点Ｂから、ランタイムは、ブロック１６２６へ移行して、新インスタンスモジュールをコールし、空インスタンスをインスタンス生成する。次いで、ランタイムは、ブロック１６２７において、プロデューサキー及びリファレンスシナリオキーを伴うプロデューサから情報をコピーし、空インスタンスを埋める。次いで、ランタイムは、ブロック１６２８において、埋められたインスタンスでプロデューサをクローン化する。次いで、ランタイムは、ブロック１６２９において、ターゲットシナリオキーを伴うクローン化されたプロデューサをプロデューサグラフに追加する。その後、ランタイムは、ブロック１６０４へ移行する。
ブロック１６０４において、ランタイムは、プロデューサがシナリオのインパクトリストにある場合にインパクトを処理する。ブロック１６０４の詳細は、図３４Ｇを参照して以下に述べる。次いで、ランタイムは、ブロック１６３０において、登録された各サブスクリプションに対してサブスクリプションフィルタリング基準を処理する。プロデューサが依存性のためにコールされる場合に、ランタイムは、１６３５において、プロデューサをプロデューサグラフへリンクする。次いで、ランタイムは、入口点Ｃへ移行する。
図３４Ｃを参照すれば、ランタイムは、入口点Ｃからブロック１６４０へ移行して、プロデューサを非実行とマークする。幾つかの実施形態では、ランタイムは、ブロック１６９０において、プロデューサ非オーバーライドコマンドを受け取る。プロデューサ非オーバーライドコマンドに応答して、ランタイムは、ブロック１６９５において、プロデューサをオーバーライドされずとマークし、次いで、ブロック１６４０へ移行する。
ブロック１６４０から、ランタイムは、ブロック１６４５へ移行し、プロデューサが何らかの依存性を有し、且つオーバーライドされていないかどうかチェックする。プロデューサが依存性をもたず、且つオーバーライドされていない場合には、ランタイムは、入口点Ｄへ移行し、図３４Ａのブロック１６６５へ戻る。さもなければ、ランタイムは、ブロック１６５０へ移行する。ブロック１６５０において、ここで決定されるべき依存性宣言における各依存性に対して、ランタイムは、プロデューサの数を決定し、そしてその各々について新ストレス化プロデューサコマンドをインボークする。全ての依存プロデューサが存在し且つ実行されている場合には、ランタイムは、ブロック１６５５において、実行スタートログにプロデューサを追加し、そして入口点Ｅへ移行して、図３４Ａのブロック１６６０へ戻る。
図３４Ｄは、本発明の一実施形態によるブロック１６０１の拡張フローチャートである。ランタイムは、先ず、ブロック３４０５において、シナリオ追跡構造及びシナリオキーを使用してインパクト経路追跡構造を探索する。次いで、ランタイムは、ブロック３４１０において、シナリオ追跡構造におけるインパクト経路追跡構造が既にインスタンス生成されたかどうか決定する。インパクト経路追跡構造が既にインスタンス生成された場合には、直接的及び間接的にインパクトされたプロデューサの両方が既に識別されている。従って、ランタイムは、ブロック３４１９へ移行して、フローを終了する。さもなければ、ランタイムは、ブロック３４１２へ移行する。ブロック３４１２では、インパクト経路追跡構造がインスタンス生成され、そしてシナリオ追跡構造に記憶される。次いで、ランタイムは、ブロック３４１３へ移行する。シナリオ定義における各直接的にインパクトされたプロデューサに対し、ランタイムは、シナリオ定義において対応プロデューサキー及びリファレンスシナリオキーを伴うプロデューサを探す。ランタイムは、ブロック３４１５において、このようなプロデューサが存在するかどうか決定する。このようなプロデューサが存在する場合には、ランタイムは、ブロック３４１７において、プロデューサを全ての祖先と共にインパクト経路追跡構造に追加し、次いで、ブロック３４１８へ移行する。さもなければ、ランタイムは、ブロック３４１７をスキップし、ブロック３４１８へ移行する。ブロック３４１８では、ランタイムは、更に多くの直接的にインパクトされたプロデューサがシナリオ定義にあるかどうかチェックする。もしあれば、ランタイムは、ブロック３４１３へ戻り、上述したオペレーションを繰り返す。さもなければ、ランタイムはブロック３４１９へ移行して、フローを終了する。
図３４Ｅは、本発明の一実施形態によるブロック１６０２の拡張フローチャートである。ランタイムは、ブロック３４２０において、インパクト経路追跡構造が空であるかどうかチェックする。インパクト経路追跡構造が空である場合には、ランタイムはブロック３４２９へ移行する。さもなければ、ランタイムは、ブロック３４２２において、リファレンスシナリオキーを伴うプロデューサがインパクト経路追跡構造にあるかどうかチェックする。もしあれば、ランタイムは、ブロック３４２４において、プロデューサ生成を「クローン化」にセットする。さもなければ、ランタイムは、ブロック３４２６において、リファレンスシナリオを伴うプロデューサグラフにプロデューサが存在するかどうかチェックする。もし存在すれば、ランタイムは、ブロック３４２８において、プロデューサ生成を「無生成」にセットする。これは、ターゲットシナリオに対するプロデューサグラフの一部分しか複写させない最適化である。生成もクローン化もされないプロデューサは、リファレンスシナリオからターゲットシナリオに対するサブグラフへリンクされる。さもなければ、ランタイムは、ブロック３４２９へ移行する。ブロック３４２９では、ランタイムは、プロデューサ生成を「新生成」にセットする。
図３４Ｆは、本発明の一実施形態による図３４Ａのブロック１６０５の拡張図である。ブロック１６０５において、ランタイムは、ストレス化プロデューサが既に存在するかどうかチェックする。幾つかの実施形態では、ランタイムは、クラスキー、インスタンスキー、メソッドキー、及びシナリオキーの組み合せがプロデューサテーブルに既に存在するかどうかチェックする。その組み合わせが存在する場合には、ストレス化プロデューサが存在する。さもなければ、ストレス化プロデューサは、存在しない。
図３４Ｇは、本発明の一実施形態によるブロック１６０４の拡張フローチャートである。幾つかの実施形態では、プロデューサ出力を得てセットするための対応する専用インターフェイスがある。ブロック３４３０において、ランタイムは、プロデューサへのインパクトが相対的であるかどうかチェックする。もしそうでなければ、プロデューサへのインパクトは絶対的である。従って、ランタイムは、ブロック３４３６において、シナリオのインパクトリストからの出力インスタンスをターゲットシナリオにおけるプロデューサの新たな出力として指定する。次いで、ランタイムは、ブロック３４４０へ移行する。さもなければ、プロデューサへのインパクトは相対的であり、ランタイムは、ブロック３４３２において、プロデューサの現在出力を得る。次いで、ランタイムは、ブロック３４３４において、現在出力及びそれに対応する変換メソッド並びにシナリオのインパクトリストにおける対応変換パラメータを使用して、プロデューサの新たな出力を発生する。次いで、ランタイムは、ブロック３４４０へ移行する。
幾つかの実施形態では、ランタイムは、拡散値を現在出力に追加することにより新たな出力を発生することができる。或いは又、ランタイムは、現在出力に係数値を乗算することにより新たな出力を発生することができる。
ブロック３４４０において、ランタイムは、出力がフィールドである場合に、プロデューサの出力を、プロデューサ出力キャッシュ及びインスタンスに発生される新たな出力値にセットする。次いで、ランタイムは、ブロック３４４２において、プロデューサをオーバーライドされたとマークし、そして図３４Ｂのブロック１６３０へ移行する。
図３５Ａ−３５Ｂは、本発明の一実施形態によるストレス化プロデューサグラフ実行フローを示すフローチャートである。ブロック２２００において、ランタイムは、実行スタートログにおけるプロデューサに基づき実行されるべき候補プロデューサのセットを候補プロデューサの現在セットとして選択する。次いで、ランタイムは、ブロック２２０５において、実行する準備のできた候補プロデューサの現在セットからのプロデューサのサブセットをレディプロデューサの現在セットとして選択する。レディプロデューサの現在セットにおける各プロデューサに対して、ランタイムは、ブロック２２１０において、プロデューサの形式をチェックする。一実施形態では、３つの形式のプロデューサ、即ち標準プロデューサ、ストレス化プロデューサ発生プロデューサ、及び依存性宣言プロデューサがある。
プロデューサが標準プロデューサである場合には、ランタイムは、ブロック２２１５へ移行し、プロデューサを実行する。次いで、ランタイムは、ブロック２２２０において、実行されたプロデューサに対するアブソービングサブスクリプション依存性を有する親を未完了とマークし、入口点Ａへ移行する。
プロデューサがストレス化プロデューサ発生プロデューサである場合には、ランタイムは、ブロック３７１０へ移行して、プロデューサを実行する。次いで、ランタイムは、ブロック３７２０において、実行されたプロデューサに対するアブソービングサブスクリプション依存性を有する親を未完了とマークする。次いで、ランタイムは、ブロック３７３０において、発見されたプロデューサに対するストレス化プロデューサコマンドをインボークし、サブスクリプションをログしそして処理する。次いで、ランタイムは、ブロック３７４０において、実行スタートログに新たに追加されるプロデューサに基づき候補プロデューサのセットに追加する。次いで、ランタイムは、入口点Ａへ移行する。
プロデューサが依存性宣言プロデューサである場合には、ランタイムは、ブロック２２２５において、依存性決定プロデューサを準備する。次いで、ランタイムは、ブロック２２３０において、依存性決定プロデューサを実行して、解明される準備のできた未解明の依存性を解明する。次いで、ランタイムは、ブロック２２３５において、発見されたプロデューサに対する新たなストレス化プロデューサコマンドをインボークし、サブスクリプションをログしそして処理する。ランタイムは、ブロック２２４０において、実行スタートログに新たに追加されたプロデューサを候補プロデューサのセットに追加する。次いで、ランタイムは、入口点Ａへ移行する。
図３５Ｂを参照すれば、ランタイムは、入口点Ａからブロック２２４５へ移行する。ブロック２２４５において、ランタイムは、プロデューサを実行されたとマークし、そしてプロデューサ出力キャッシング及びインスタンスキャッシングを必要に応じて更新する。更に、ランタイムは、親プロデューサを、実行されるべき候補プロデューサのセットに追加し、非実行とマークする。ランタイムは、更に、候補及びレディプロデューサの現在セットから、実行されたプロデューサを除去する。ブロック２２４５から、ランタイムは、ブロック２２５０へ移行して、候補プロデューサのセットが空であるかどうかチェックする。もし空でない場合には、ランタイムは、入口点Ｂを経てブロック２２０５へ移行し、上述したフローを繰り返す。候補プロデューサのセットが空である場合には、ランタイムは、ブロック２２５５へ移行して、全てのサブスクリプションが完了されたかどうかチェックする。完了でなければ、ランタイムは、ブロック２２６０において、未完了のアブソービングサブスクリプションプロデューサを処理し、次いで、入口点Ｂを経てブロック２２０５へ戻る。さもなければ、全てのサブスクリプションが完了されており、ランタイムは、ブロック２２４８へ移行する。ブロック２２４８において、シナリオ追跡構造がスキャンされ、全てのインスタンス経路追跡構造が解除される。次いで、ランタイムは、ブロック２２６５へ移行し、フローを終了する。
手続き型言語
上述したように、適切に書かれた手続き型言語、非リフレクティブなオブジェクト指向の言語、及び非リフレクティブなオブジェクトベースの言語コードは、リフレクティブなオブジェクト指向の言語コードへと変換することができる。例えば、あるクラスは、データ構造と、データ構造のインスタンスへのポインタを第１パラメータとして有するスタティックファンクションのセットとを通してエミュレートすることができる。これらファンクションの中には、コンストラクタ及びデストラクタがある。コンストラクタは、データ構造に対するポインタを割り当てた後にランタイムによってインボークされ、データ構造内のエレメントに対するデフォールトを与え、又、デストラクタは、データ構造に対するポインタを解除した後にランタイムによりインボークされる。各クラスは、次のものを含むファイルを通してその記述を有する。１）データ構造；２）クラスを記述し、構造のサイズ及びファンクションに対するポインタのセットを保持する別の構造；３）コードを伴うスタティックファンクションのリスト（非リフレクティブなオブジェクト指向の言語及び非リフレクティブなオブジェクトベースの言語に対して、スタティックファンクションのコードは、リアルクラスのメソッドをスキャンし、そして関連メソッドの有効なインボケーションを遂行するスタティックなファンクションをメソッドごとに生成することにより自動的に発生される）；及び４）各ファンクションの最上部のアノテーション（コメントがプロデューサ依存性宣言を保持する）、及びそれらの形式（コンストラクタ、デストラクタ、プロパティ、等）。手続き型の非リフレクティブなオブジェクト指向又は非リフレクティブなオブジェクトベースの言語におけるクラスのこの定義に加えて、ダイナミックインボケーションも具現化される。より詳細には、コンパイラーは、クラスごとに次のような初期化コード、即ち次のことを行うために（新クラスモジュールにより）一度コールされるコード、を発生する。１）クラスを記述する構造をインスタンス生成し、ファンクションに対するポインタを有効なスタティックファンクションで埋め；２）クラスのマップを伴うこの構造のインスタンス（クラス追跡構造）をクラス名に対応するキーで登録し；及び３）ファンクションのマップにおけるファンクションに対する全ポインタ（メソッド追跡構造）をファンクション名に対応するキーで登録する（ArgumentDependencies、SequencingDependencies、FieldDependencies、UpwardDependencies、WeaklyConstrainedDependencies、出力クラスキー、及び付加的なアノテーションと共に）。マッピングは、次のことを実行できる一般的なインボケーションファンクションの、ランタイムにおける具現化を許す。１）クラスのインスタンスを名前で（新インスタンスモジュールで）インスタンス生成し（より詳細には、ランタイムは、ａ）データ構造のサイズに基づいてメモリを割り当て、クラスを記述する構造に対するポインタを記憶するためにポインタにヘッダを追加し、それ故、スマートポインタ（例えば、それらの形式を問合せできるポインタ）を具現化し）；及びｂ）マップからスタティックファンクションに対する関連ポインタを検索した後に適切なコンストラクタファンクションをインボークし）；及び２）マップからスタティックファンクションに対する関連ポインタを検索した後に全てのパラメータが適切にパスしたとすればメソッドを名前でインボークする。ファンクションに対するポインタで識別されたファンクションにパラメータを適切にパスすることは、アッセンブリ言語や、入力及び出力パラメータに対するスタックへの／からのプッシュ及びポップエレメントを通して行われる。上述したメソッドは、データ構造の観念の存在、及び手続き型の非リフレクティブなオブジェクト指向又は非リフレクティブなオブジェクトベース言語におけるファンクションに対するポインタの観念の存在を仮定している。
例示的なオブジェクト指向のソースコードシンタックス
Ａ．クライアントコード
本発明の一実施形態では、クライアントコードは、次のようなシンタックスをとる（ヘッダ形態で示す）
ProducerKey
New (String ClassKey, InstanceKey InstanceKey, String MethodKey);
Rumtime
New ()
AddProducerOfInterest (ProducerKey ProducerOfInterestKey);
SetProducerOutput (ProducerKey ProducerToOverrideKey, Object
ProducerOutputInstance);
Execute ();
ProducerKey及びRuntimeは、クラスであるが、New、AddProducerOfInterest、SetProducerOutput、及びExecuteは、メソッドである。AddProducerOfInterestは、テーブル２の問題とするプロデューサの状態に対して適切な値をもつ新プロデューサコマンドのインボケーションを生じさせる。ProducerOutputInstanceは、オーバーライドされたプロデューサ出力クラスのインスタンスである。従って、これは、対応するプロデューサ出力クラスコンストラクタを通してインスタンス生成される。
Ｂ．ステートメント
１．依存性宣言ステートメントシンタックス
argumentDependency＝”Argument1Dependency; Argument2Dependency;...”
fieldDependency＝”FieldDependency1; FieldDependency2:...”
sequencingDependency＝”SequencingDependency1; SequencingDependency2;...”
upwardDependency＝”UpwardDependency1; UpwardDependency2;...”
weaklyConstrainedDependency＝”WeaklyConstrainedDependency1; WeaklyConstrainedDependency2;...”
unConstrainedDependency＝”unConstrainedDependency1; unConstrainedDependency2;...”
２．依存性シンタックス
ａ．fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#C: ClassKey'::#I;'InstanceKey'::#M:'MethodKey'
ｂ．argumentXDependencyシンタックス：
AerumentID::#C:'ClassKey'::#I:'InstanceKey'::#M:'MethodKey'
本発明の一実施形態では、ArgumentIDがシンタックスにおいて省略され、そしてargumentDependenciesが宣言される順序は、ArgumentIDを表す。従って、信頼性を向上させるために、ArgumentIDが追加される。
３．ショートカット及び非ショートカット
シンタックスは、非ショートカットの場合と同じであるが、プロデューサキーがショートカットを指示する前には＃Ｓ：：を使用する。
ａ．fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#S::#C: ClassKey'::#I;'InstanceKey'::#M:'MethodKey'
ｂ．argumentXDependencyシンタックス：
AerumentID::#S::#C:'ClassKey'::#I:'InstanceKey'::#M:'MethodKey'
この場合に、依存性により指示されるプロデューサキーは、依存性決定プロデューサではない。他のシンタックス具現化は、ショートカットが、ある依存性形式（例えば、フィールド）に対するデフォールト依存性であると仮定し、そして＃Ｓ：：を省略することができる。この場合に、＃ＤＤＰは、ＤＤＰの存在を指示するのに使用できる。
４．コンティンジェント及び非コンティンジェント
上述したように、＜Ｐ＞は、コンティンジェントなエレメントの前に入れることができる。
ａ．コンティンジェントクラス及びメソッドの例
１）fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#C:<P>'ClassDeterminationMethodKey'::#I:'InstanceKey'::#M:
<P>'MethodDeterminationMethodKey'
２）argumentXDependencyシンタックス：
ArgumentID::#C:<P>'ClassDeterminationMethodKey'::#I:'InstanceKey'::#M
M:<P>'MethodDeterminationMethodKey'
ｂ．コンティンジェントメソッドの例
１）fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#C:'ClassKey'::#I:'InstanceKey'::#M:
<P>'MethodDeterminationMethodKey'
２）argumentXDependencyシンタックス：
ArgumentID::#C:'ClassKey'::#I:'InstanceKey'::#M
<P>'MethodDeterminationMethodKey'
ｃ．コンティンジェントインスタンスの例
１）fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#C:'ClassKey'::#I:<P>'InstanceDeterminationMethodKey'::#M:
'MethodKey'
２）argumentXDependencyシンタックス：
ArgumentID::#C:'ClassKey'::#I
<P>'InstanceDeterminationMethodKey'
５．ショートハンド技術
親プロデューサエレメントと同一であると考えられるクラス、インスタンス又はメソッドのようなエレメントは、省略される。これは、典型的に、ショートカットフィールドに対するケースである。以下の例は、ショートハンド技術とショートカット宣言とを結合する（ショートカットは、＃Ｓ：:で示される）。
ａ．クラス及びインスタンスが省略される例
１）fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#S::#M:'MethodKey'
２）argumentXDependencyシンタックス：
ArgumentID::#S::#M:'MethodKey'
ｂ．クラスが省略される例
１）fieldDependencyX, sequencingDependencyX,
upwardDependencyX, weaklyConstrainedDependencyX,
unConstrainedDependencyXシンタックス：
#S::#I:'InstanceKey'::#M:'MethodKey'
２）argumentXDependencyシンタックス：
ArgumentID::#S::#I:'InstanceKey'::#M:'MethodKey'
別の実施形態
添付図面のフローチャートは、本発明の実施形態によって遂行されるオペレーションの特定の順序を示しているが、このような順序は、例示に過ぎない（例えば、別の実施形態では、オペレーションを異なる順序で遂行し、あるオペレーションを結合し、あるオペレーションを重畳し、等々も行える）ことを理解されたい。
本発明を多数の実施形態について説明したが、当業者であれば、本発明は、ここに述べる実施形態に限定されず、特許請求の範囲の精神及び範囲内で変更及び修正を伴って実施できることが明らかであろう。従って、この説明は、限定のためではなく例示のためのものと考えるべきである。
１００：オブジェクト指向のソースコード
１０２：クラス定義
１０４：所与のメソッド
１０５：実行モード設定
１０６：所与のメソッドに対するプロデューサ依存性宣言
１０８：インスタンス（データ）
１１０：プロデューサ
１１２、１１４：プロデューサのセット
２１０Ａ、２１０Ｉ：オブジェクト指向のアプリケーションコード
２２０：プロデューサグラフ指向のプログラミングサポートを伴うランタイム
３２０：プロデューサ依存性宣言
３２５：プロデューサの現在セット
３３０：ソースプロデューサの出力
３３５：プロデューサグラフ指向のプログラミングサポートを伴うランタイム
３４０：自動プロデューサグラフ発生モジュール
３４５：プロデューサグラフ実行モジュール
３４５１：パラレル化モジュール
３４５３：マルチプロセッシングモジュール
３４５５：マルチスレッディングモジュール
３４５７：ローカル実行モジュール
３５０：ソースプロデューサの出力
３５２：ソースコードにおける独立プロデューサの出力
３５４：オーバーライドされたプロデューサ出力
３６０：プロデューサグラフ指向のプログラミングサポートを伴うランタイム
３６５：自動プロデューサグラフ発生モジュール
３７０：プロデューサグラフ実行モジュール
３８０：プロデューサグラフ構造
３８２：増分的実行マーキング
３８４：プロデューサ出力キャッシング
３９０：オーバーライドプロデューサ出力モジュール
３９２：オーバーライドプロパティプロデューサ出力モジュール
３９４：オーバーライドメソッドプロデューサ出力モジュール
３９６：オーバーライドログ

Claims (26)

  1. オブジェクト指向のコードで書かれたアプリケーションプログラムを実行するためのコンピュータ実施方法において、
    対象の現行出力を伴うプロデューサをインスタンス生成するステップであって、前記オブジェクト指向のコードがメソッド及びプロデューサ依存性宣言を含み、所与のメソッドに対するプロデューサ依存性宣言が０以上のプロデューサのセットをランタイム時に識別し、プロデューサは、少なくともインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであるようなステップと、
    前記インスタンス生成に応答して、前記対象のプロデューサを第１プロデューサグラフの一部分として追加するステップと、
    前記第１プロデューサグラフに既にあるプロデューサのメソッドのプロデューサ依存性宣言に基づき、他のプロデューサをリンクし及び必要に応じてインスタンス生成することにより、前記第１プロデューサグラフの残り部分を自動的に発生及び実行するステップと、
    前記対象のプロデューサを実行するステップと、
    を備え、
    前記第１プロデューサグラフ及び当該第１プロデューサグラフのプロデューサの出力は、第１シナリオに対応し、
    方法は、さらに、
    前記第１プロデューサグラフにおけるプロデューサの前記出力を保持しながら前記出力の一つ以上の変化を表す第２シナリオで前記アプリケーションプログラムをシミュレーションするステップと、
    を備えた方法。
  2. 前記変化は、前記第２シナリオのための１つ以上の直接的にインパクトされるプロデューサの出力にある、請求項１に記載の方法。
  3. 前記シミュレーションするステップは、さらに、
    前記第１シナリオを識別するリファレンスシナリオキー、前記第２シナリオを識別するターゲットシナリオキー、及びその第２シナリオに対する１つ以上の直接的にインパクトされるプロデューサのインパクトリストへのリファレンス、を含むシナリオ情報、並びに前記１つ以上の直接的にインパクトされるプロデューサの出力の変化に関する情報を受け取るステップと、
    前記シナリオ情報を使用して前記第２シナリオを生成するステップと、
    を更に備えた請求項２に記載の方法。
  4. 第２シナリオを生成する前記ステップは、
    前記第１プロデューサグラフにおけるプロデューサのうちのどのプロデューサを、前記第１プロデューサグラフを使用して１つ以上の直接的にインパクトされるプロデューサの出力でインパクトすべきか決定する段階と、
    前記インパクトされたプロデューサをインパクト経路追跡構造にログする段階と、
    を含む請求項３に記載の方法。
  5. 第２シナリオを生成する前記ステップは、
    少なくとも、対象のプロデューサ、１つ以上の直接的にインパクトされるプロデューサ、及び前記対象のプロデューサが依存する前記インパクトプロデューサ追跡構造におけるいずれかのインパクトされたプロデューサ、のコピーを有する第２のプロデューサグラフを生成する段階と、
    前記インパクトリストの情報に基づいて前記１つ以上の直接的にインパクトされるプロデューサのコピーの出力を変化させる段階と、
    を含む請求項４に記載の方法。
  6. 前記インパクトリストの情報に基づいて前記１つ以上の直接的にインパクトされるプロデューサのコピーの出力を変化させる前記段階は、前記第２プロデューサグラフにおける１つ以上の直接的にインパクトされるプロデューサのコピーの出力を、前記インパクトリストにおける情報で指定された所定値でオーバーライドすることを含む、請求項５に記載の方法。
  7. 前記インパクトリストの情報に基づいて前記１つ以上の直接的にインパクトされるプロデューサのコピーの出力を変化させる前記段階は、
    前記第１シナリオにおけるプロデューサの出力を決定し、そして
    前記第１シナリオにおけるプロデューサの出力及び前記インパクトリストの情報を使用して前記第２シナリオにおける直接的にインパクトされるプロデューサのコピーの出力を発生する、
    ことを含む請求項５に記載の方法。
  8. 第２のプロデューサグラフを生成する前記段階は、前記第１プロデューサグラフにおける１つ以上のプロデューサを前記第２プロデューサグラフにリンクすることを含み、その１つ以上のプロデューサは、前記直接的にインパクトされるプロデューサとは独立している、請求項５に記載の方法。
  9. 第２のプロデューサグラフを生成する前記段階は、対象のプロデューサ、及びこの対象のプロデューサが依存するいずれかのインパクトされたプロデューサを、前記第１プロデューサグラフを使用してクローン化することを含む、請求項５に記載の方法。
  10. 第２のプロデューサグラフを生成する前記段階は、対象のプロデューサ、及びこの対象のプロデューサが依存するインパクトされたプロデューサを、対象のプロデューサ、及びこの対象のプロデューサが依存するインパクトされたプロデューサ各々のメソッドのメソッド定義及び依存性宣言から生成することを含む、請求項５に記載の方法。
  11. 前記シミュレーションするステップは、さらに、
    １つ以上の直接的にインパクトされるプロデューサのコピーの変化した出力を使用して前記第２のプロデューサグラフを実行し、対象のプロデューサ、１つ以上の直接的にインパクトされるプロデューサ、及び前記第１シナリオに対するインパクトされたプロデューサの既存の出力を保持しながら前記第２プロデューサグラフにおける対象のプロデューサのコピーの出力を決定する段階と、
    前記第１シナリオに対する対象のプロデューサの既存の出力をキャッシュに保持しながら前記第２シナリオに対する対象のプロデューサのコピーの出力をキャッシュに記憶する段階と、
    前記第１シナリオに対する１つ以上の直接的にインパクトされるプロデューサの既存の出力をキャッシュに保持しながら前記第２シナリオに対する１つ以上の直接的にインパクトされるプロデューサのコピーの変化した出力をキャッシュに記憶する段階と、
    前記第１シナリオに対するインパクトされたプロデューサの既存の出力をキャッシュに保持しながら対象のプロデューサと第２シナリオに対する１つ以上の直接的にインパクトされるプロデューサとの間の経路におけるインパクトされたプロデューサのコピーの出力をキャッシュに記憶する段階と、
    を更に含む請求項５に記載の方法。
  12. 前記第２シナリオに対する対象のプロデューサのコピーの出力及び前記第１シナリオに対する対象のプロデューサの出力を使用して前記第１シナリオから第２シナリオへの対象のプロデューサの出力の導関数を自動的に決定する段階を更に含む、請求項１１に記載の方法。
  13. １より大きい整数をＮとすれば、前記第１シナリオから第２シナリオへの対象のプロデューサの出力の導関数を使用してＮ次導関数及び交差導関数の少なくとも１つを自動的に且つ繰り返し決定する段階を更に含む、請求項１２に記載の方法。
  14. アプリケーションプログラムをシミュレーションする前記ステップは、ストレス化プロデューサ発生プロデューサを実行して、前記第２プロデューサにおけるプロデューサの少なくとも１つをダイナミックに生成する段階を含む、請求項５に記載の方法。
  15. メソッドに対するプロデューサ依存性宣言を伴うオブジェクト指向のコードを実行するランタイムを備え、プロデューサは、少なくともインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであり、所与のメソッドに対する各プロデューサ依存性宣言は、０以上のプロデューサのセットをランタイム時に識別し、そして前記ランタイムは、
    ターゲットシナリオのシナリオ情報を受け取る新シナリオモジュールと、
    前記新シナリオモジュールに結合されて、対象の出力を伴う選択された現行プロデューサを受け取り、そしてシナリオ情報を使用して前記ターゲットシナリオに対するプロデューサグラフを構築するための自動ストレス化プロデューサグラフ発生モジュールであって、前記プロデューサグラフは、選択された現行プロデューサ、シナリオ情報に基づきターゲットシナリオにおいて変化された出力を有する直接的にインパクトされた１つ以上のプロデューサ、及び１つ以上のプロデューサと選択された現行プロデューサとの間の中間プロデューサ、の各々のコピーを含むものである自動ストレス化プロデューサグラフ発生モジュールと、
    前記自動ストレス化プロデューサグラフ発生モジュールに結合されて、前記ターゲットシナリオに対するプロデューサグラフにおける直接的にインパクトされた１つ以上のプロデューサの変化した出力を受け取り、そしてその変化した出力を、前記ターゲットシナリオに対するプロデューサグラフの他のプロデューサに適用して、前記ターゲットシナリオにおける選択された対象の現行プロデューサの出力を決定するための自動ストレス化プロデューサグラフ実行モジュールと、
    を含むものであるシステム。
  16. 前記シナリオ情報は、リファレンスシナリオキー、ターゲットシナリオキー、直接的にインパクトされる１つ以上のプロデューサのリストへのリファレンス、及び対応する直接的にインパクトされるプロデューサの出力を所定値に変化させるか又はその対応する直接的にインパクトされるプロデューサの既存の出力から発生させるかを指示するために前記直接的にインパクトされるプロデューサの各々に関連付けられたインジケータを含む、請求項１５に記載のシステム。
  17. 前記ランタイムは、更に、前記直接的にインパクトされるプロデューサ各々の出力をオーバーライドするために前記自動ストレス化プロデューサグラフ発生モジュールに結合されたオーバーライドプロデューサ出力モジュールを備えた、請求項１５又は１６に記載のシステム。
  18. 前記ランタイムは、更に、記憶された既存のプロデューサグラフに上書きせずに前記ターゲットシナリオに対するプロデューサグラフを記憶するために前記自動ストレス化プロデューサグラフ発生モジュールに結合されたプロデューサグラフ構造を備え、そのプロデューサグラフ構造は、更に、前記選択された対象の現行プロデューサ、中間プロデューサ、及び記憶された１つ以上のプロデューサの既存の出力に上書きせずに、前記選択された対象の現行プロデューサの出力、中間プロデューサの出力、及び前記ターゲットシナリオに対する直接的にインパクトされた１つ以上のプロデューサの変化した出力を記憶するためのプロデューサ出力キャッシング構造を備えた、請求項１５に記載のシステム。
  19. 前記ランタイムは、更に、前記新シナリオモジュールに結合されたシナリオ追跡構造を備え、前記新シナリオモジュールは、前記シナリオ追跡構造にシナリオ情報を追加するよう動作できる、請求項１５に記載のシステム。
  20. クラスをロードしてインスタンス生成し、メソッドをインボークし、そしてクラス及びメソッドの少なくとも１つでイントロスペクションを遂行するように動作できる第２のランタイムを更に備え、この第２のランタイムは、前記ランタイムとは論理的に個別である、請求項１５に記載のシステム。
  21. 前記ランタイムは、更に、クラスをロードしてインスタンス生成し、メソッドをインボークし、そしてクラス及びメソッドの少なくとも１つでイントロスペクションを遂行するように動作できる、請求項１５に記載のシステム。
  22. オペレーティングシステムを更に備え、前記ランタイムは、そのオペレーティングシステム内に一体化される、請求項１５に記載のシステム。
  23. 複数のクラスの複数のクラス定義を含むオブジェクト指向のコードを与えるマシン読み取り可能な記憶媒体において、前記複数のクラス定義の各々は、
    ０以上のフィールドのセットと、
    １つ以上のメソッドのセットと、
    前記メソッドのセットの各々に対するプロデューサ依存性宣言と、
    を備え、前記メソッドの所与の１つに対する前記プロデューサ依存性宣言は、０以上のプロデューサのセットを識別するためにランタイム時において使用され、プロデューサは、少なくとも、複数のクラスのうちの１つのクラスのインスタンス及びそのインスタンスに関連したメソッドを含むランタイムインスタンス生成可能なコンストラクトであり、更に、前記複数のクラス定義のうちの一つは、１つ以上のストレス化プロデューサのセットを発生するために１つ以上のストレス化プロデューサ発生メソッドを有する複数のクラスのうちの一つを定義し、前記１つ以上のストレス化プロデューサ発生メソッドの各々は、対象のプロデューサを識別すると共にターゲットシナリオを定義するためのコードを含み、前記ランタイムが前記ストレス化プロデューサ発生メソッドを実行して、前記ターゲットシナリオに対する前記対象のプロデューサへのインパクトを評価するよう動作できるようにした、マシン読み取り可能な記憶媒体。
  24. 前記１つ以上のストレス化プロデューサ発生メソッドの各々は、リファレンスシナリオキー、ターゲットシナリオキー、直接的にインパクトされる１つ以上のプロデューサのリストへのリファレンス、及び対応する直接的にインパクトされるプロデューサの出力を所定値に変化させるか又はその対応する直接的にインパクトされるプロデューサの既存の出力から発生させるかを指示するために前記直接的にインパクトされるプロデューサの各々に関連付けられたインジケータを指定する、請求項２３に記載のマシン読み取り可能な記憶媒体。
  25. 前記１つ以上のストレス化プロデューサ発生メソッドの各々は、前記ランタイムにより実行されたときに、前記ランタイムが、前記ターゲットシナリオにおいて１つ以上のストレス化プロデューサを生成すると共に、そのストレス化プロデューサを前記ターゲットシナリオのプロデューサグラフに追加するようにさせる、請求項２３に記載のマシン読み取り可能な記憶媒体。
  26. 前記１つ以上のストレス化プロデューサの各々は、プロデューサを識別するためのプロデューサキーと、シナリオを識別するためのシナリオキーとを含む、請求項２５に記載のマシン読み取り可能な記憶媒体。
JP2009538646A 2006-12-01 2007-11-30 シナリオサポートを伴うプロデューサグラフ指向のプログラミングフレームワーク Active JP5354603B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/607,199 US8332827B2 (en) 2006-12-01 2006-12-01 Produce graph oriented programming framework with scenario support
US11/607,199 2006-12-01
PCT/EP2007/010410 WO2008064902A2 (en) 2006-12-01 2007-11-30 Producer graph oriented programming framework with scenario support

Publications (2)

Publication Number Publication Date
JP2010511235A JP2010511235A (ja) 2010-04-08
JP5354603B2 true JP5354603B2 (ja) 2013-11-27

Family

ID=39358358

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009538646A Active JP5354603B2 (ja) 2006-12-01 2007-11-30 シナリオサポートを伴うプロデューサグラフ指向のプログラミングフレームワーク

Country Status (9)

Country Link
US (2) US8332827B2 (ja)
EP (1) EP1958062B1 (ja)
JP (1) JP5354603B2 (ja)
CN (1) CN101601012B (ja)
AT (1) ATE435453T1 (ja)
DE (1) DE602007001443D1 (ja)
ES (1) ES2327797T3 (ja)
RU (1) RU2438161C2 (ja)
WO (1) WO2008064902A2 (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 (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050071135A1 (en) * 2003-09-30 2005-03-31 Vredenburgh David W. Knowledge management system for computer-aided design modeling
US8751950B2 (en) 2004-08-17 2014-06-10 Ice Edge Business Solutions Ltd. Capturing a user's intent in design software
US7865872B2 (en) * 2006-12-01 2011-01-04 Murex S.A.S. Producer graph oriented programming framework with undo, redo, and abort execution support
US8370812B2 (en) * 2007-04-02 2013-02-05 International Business Machines Corporation Method and system for automatically assembling processing graphs in information processing systems
US8863102B2 (en) * 2007-04-02 2014-10-14 International Business Machines Corporation Method and system for assembling information processing applications based on declarative semantic specifications
US8307372B2 (en) 2007-04-02 2012-11-06 International Business Machines Corporation Method for declarative semantic expression of user intent to enable goal-driven information processing
CN101689111A (zh) * 2007-04-03 2010-03-31 Ldra技术公司 软件需求验证的自动化管理
US10248915B2 (en) * 2008-03-07 2019-04-02 International Business Machines Corporation Risk profiling for enterprise risk management
EP2252951B1 (en) 2008-03-11 2021-05-05 Ice Edge Business Solutions, Ltd. Automatically creating and modifying furniture layouts in design software
US9245064B2 (en) 2009-11-24 2016-01-26 Ice Edge Business Solutions Securely sharing design renderings over a network
US8595709B2 (en) * 2009-12-10 2013-11-26 Microsoft Corporation Building an application call graph from multiple sources
US20120117546A1 (en) * 2010-11-08 2012-05-10 International Business Machines Corporation Run-time Module Interdependency Verification
US8897900B2 (en) * 2011-03-18 2014-11-25 Rockwell Automation Technologies, Inc. Graphical language for optimization and use
US9230358B2 (en) * 2011-03-31 2016-01-05 International Business Machines Corporation Visual connectivity of widgets using event propagation
EP2718861A4 (en) 2011-06-11 2015-03-18 Dirtt Environmental Solutions AUTOMATIC REUSE OF STRUCTURAL COMPONENTS
US9292422B2 (en) 2012-10-12 2016-03-22 Vmware, Inc. Scheduled software item testing
US8839202B2 (en) * 2012-10-12 2014-09-16 Vmware, Inc. Test environment managed within tests
US9069902B2 (en) 2012-10-12 2015-06-30 Vmware, Inc. Software test automation
US9684587B2 (en) 2012-10-12 2017-06-20 Vmware, Inc. Test creation with execution
US8949794B2 (en) 2012-10-12 2015-02-03 Vmware, Inc. Binding a software item to a plain english control name
US10387294B2 (en) 2012-10-12 2019-08-20 Vmware, Inc. Altering a test
US9292416B2 (en) 2012-10-12 2016-03-22 Vmware, Inc. Software development kit testing
US10067858B2 (en) 2012-10-12 2018-09-04 Vmware, Inc. Cloud-based software testing
US8839201B2 (en) 2012-10-12 2014-09-16 Vmware, Inc. Capturing test data associated with error conditions in software item testing
US9201649B2 (en) * 2012-10-26 2015-12-01 Inforsys Limited Systems and methods for estimating an impact of changing a source file in a software
SG11201609800SA (en) 2012-12-10 2016-12-29 Dirtt Environmental Solutions Efficient lighting effects in design software
EP2948929B1 (en) 2013-01-25 2021-11-10 Dirtt Environmental Solutions, Ltd. Real-time depth of field effects with design software
CA2817497C (en) 2013-01-31 2021-05-25 Dirtt Environmental Solutions, Ltd. Method and system for efficient modeling of specular reflection
JP5707430B2 (ja) * 2013-01-31 2015-04-30 京セラドキュメントソリューションズ株式会社 アプリケーション開発プログラム
CA2817402C (en) 2013-01-31 2021-03-16 Dirtt Environmental Solutions, Ltd. Visual distortion effects through translucent structures in design software
US9292405B2 (en) 2013-03-08 2016-03-22 Sap Se HANA based multiple scenario simulation enabling automated decision making for complex business processes
US9389986B2 (en) * 2013-05-06 2016-07-12 Microsoft Technology Licensing, Llc Identifying impacted tests from statically collected data
CA2883079C (en) 2013-05-31 2021-10-26 Ice Edge Business Solutions Ltd. Associating computer-executable objects with three-dimensional spaces within an architectural design environment
RU2656580C9 (ru) * 2014-01-30 2020-01-22 Общество с ограниченной ответственностью "Аби Девелопмент" Определение порядка инициализации статических объектов
US10922450B2 (en) 2014-06-09 2021-02-16 Dirtt Environmental Solutions, Ltd. Associating computer-executable objects with timber frames within an architectural design environment
US9465723B2 (en) * 2014-10-27 2016-10-11 Software Ag Usa, Inc. Systems and/or methods for monitoring live software
WO2016099318A2 (ru) * 2014-12-19 2016-06-23 Сергей Анатольевич ГОРИШНИЙ Система и способ управления функционально связанными данными
US20170090890A1 (en) * 2015-09-30 2017-03-30 Semmle Limited Virtual compositions
CN105739983B (zh) * 2016-01-29 2019-03-15 腾讯科技（深圳）有限公司 脚本程序编辑装置及其实现方法
CN105867907A (zh) * 2016-03-23 2016-08-17 沈阳师范大学 去除业务耦合性的JSS多层Web开发框架设计方法
CN109644153B (zh) * 2016-04-12 2020-10-13 伽德诺克斯信息技术有限公司 具有被配置为实现安全锁定的相关设备的特别编程的计算系统及其使用方法
US10146530B1 (en) 2017-07-12 2018-12-04 International Business Machines Corporation Simulating and evaluating code branch merge
US11651128B2 (en) * 2019-03-25 2023-05-16 Aurora Labs Ltd. Verifying integrity of controller software updates
US11113030B1 (en) * 2019-05-23 2021-09-07 Xilinx, Inc. Constraints for applications in a heterogeneous programming environment
US11776060B2 (en) 2019-06-03 2023-10-03 Cerebri AI Inc. Object-oriented machine learning governance
CN111857683A (zh) * 2020-07-01 2020-10-30 北京黄金管家科技发展有限公司 Java高效编程系统

Family Cites Families (105)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4558413A (en) 1983-11-21 1985-12-10 Xerox Corporation Software version management system
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
US5481740A (en) 1986-04-14 1996-01-02 National Instruments Corporation Method and apparatus for providing autoprobe features in a graphical data flow diagram
US5481741A (en) 1986-04-14 1996-01-02 National Instruments Corporation Method and apparatus for providing attribute nodes in a graphical data flow environment
US5497500A (en) 1986-04-14 1996-03-05 National Instruments Corporation Method and apparatus for more efficient function synchronization in a data flow program
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
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
AU2001253712A1 (en) 2000-04-21 2001-11-07 Togethersoft 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
AU2002243335A1 (en) 2000-10-20 2002-06-18 Polexis, Inc. Extensible information system (xis)
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
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
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
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
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
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
US7444287B2 (en) * 2004-07-01 2008-10-28 Emc Corporation Efficient monitoring system and method
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
WO2006031640A2 (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
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
US7865872B2 (en) 2006-12-01 2011-01-04 Murex S.A.S. Producer graph oriented programming framework with undo, redo, and abort execution support
US8307337B2 (en) 2006-12-01 2012-11-06 Murex S.A.S. Parallelization and instrumentation in a producer graph oriented programming framework
US8191052B2 (en) 2006-12-01 2012-05-29 Murex S.A.S. Producer graph oriented programming and execution
US8332827B2 (en) 2006-12-01 2012-12-11 Murex S.A.S. Produce graph oriented programming framework with scenario support

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
EP1958062B1 (en) 2009-07-01
RU2009125011A (ru) 2011-01-10
WO2008064902A3 (en) 2008-07-17
ATE435453T1 (de) 2009-07-15
JP2010511235A (ja) 2010-04-08
WO2008064902A2 (en) 2008-06-05
DE602007001443D1 (de) 2009-08-13
ES2327797T3 (es) 2009-11-03
RU2438161C2 (ru) 2011-12-27
US20080134152A1 (en) 2008-06-05
EP1958062A2 (en) 2008-08-20
US20130104109A1 (en) 2013-04-25
CN101601012B (zh) 2014-03-19
US8332827B2 (en) 2012-12-11
CN101601012A (zh) 2009-12-09
US9201766B2 (en) 2015-12-01

Similar Documents

Publication Publication Date Title
JP5354603B2 (ja) シナリオサポートを伴うプロデューサグラフ指向のプログラミングフレームワーク
JP5354602B2 (ja) プロデューサグラフ指向のプログラミング及び実行
JP5354601B2 (ja) プロデューサグラフ指向のプログラミングフレームワークにおけるパラレル化及びインスツルメンテーション
US7865872B2 (en) Producer graph oriented programming framework with undo, redo, and abort execution support
CN113841135B (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: 5354603

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

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250