JP2006500670A - 異質分散計算環境内での検証可能なプロセス - Google Patents

異質分散計算環境内での検証可能なプロセス Download PDF

Info

Publication number
JP2006500670A
JP2006500670A JP2004539251A JP2004539251A JP2006500670A JP 2006500670 A JP2006500670 A JP 2006500670A JP 2004539251 A JP2004539251 A JP 2004539251A JP 2004539251 A JP2004539251 A JP 2004539251A JP 2006500670 A JP2006500670 A JP 2006500670A
Authority
JP
Japan
Prior art keywords
executable file
module
test data
corresponding test
display
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.)
Pending
Application number
JP2004539251A
Other languages
English (en)
Inventor
ダンカン、ジョンストン‐ワット
アンドリュー、マーティン、ウエスト
ゲーリー、ピーター、ブラウン
スティーブン、ショーン、マーク、ロス‐タルボット
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Enigmatec Corp
Original Assignee
Enigmatec Corp
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 Enigmatec Corp filed Critical Enigmatec Corp
Publication of JP2006500670A publication Critical patent/JP2006500670A/ja
Pending legal-status Critical Current

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
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86—Event-based monitoring

Abstract

分散計算／処理環境内での検証可能なプロセスの実行に関連する方法、コンピュータプログラムプロダクト、システムについて記載されている。特に、本発明は、異質分散計算環境内でのビジネスロジック仕様の自動的な実施および検証に関する。ビジネスロジック仕様（１０２）は、分散処理環境（１１０）内で実行するための複数の有効なプロセス（１０４）として与えられる（ステップ１１２）。その実行で生成される情報を監視して分析する（ステップ１１４）ことにより、実行するプロセスのビューを関連付けることができる（１０６）。当初の仕様と相関されたビューとが比較され、コンテキスト情報が適用される（ステップ１１６）とともに、結果として仕様に対して補正が行なわれる。本発明は、ほぼ自動的にイベントの全てのサイクルを達成する。

Description

本発明は、分散計算／処理環境内での検証可能なプロセスの実行に関する。特に、本発明は、異質分散計算環境内でビジネスロジックを自律的に実施して検証するための方法、コンピュータプログラムプロダクト、システムに関する。
本発明は、検証可能な制御された自律態様でビジネスロジックのハイレベルな仕様を分散処理環境内で展開させて実行することができ、それにより、実行しているプロセスが当初のビジネスロジックを正確に実施できるようにする。
以下の説明において、用語「検査」は、期待される動作に対してコンポーネントを働かせる（調べる）ための機能に関する。一方、「検証」は、コンポーネントが実行するのに有効であるかどうかを判断する能力のことである。第三世代言語すなわち単に３ＧＬとは、従来のコンパイルされたプログラミング言語、例えばＪａｖａ、Ｃ＃、Ｃ＋＋またはＡｄａのことである。ＸＭＬは拡張マークアップ言語の略語である。
ビジネスロジックとは、ビジネスプロシージャの任意の部分の表示のことである。ビジネスプロシージャは、例えば企業全体にわたる規制政策の普及等のハイレベルなビジネス問題、例えば所定の期限を満たすために原材料を集めて特定数の機械装置を作るといった物流問題、または、例えばネットワークを通じて流れる情報の仲介ルーティング等のインフラ問題であっても良い。
ビジネスプロシージャは、多くの他の表記で表すことができる。ビジネスロジック表示の周知の例としては、標準的なＸＭＬに基づく表示（例えばＢＰＭＬ，ｅｂＸＭＬ、ＢｉｚＴａｌｋ，Ｘｌａｎｇ，ＷＳ−ＢＰＥＬまたはＷＳＦＬ）および登録商標権を有する表示（ＨＩＰＡＡ、ＩＡＡまたはＦＩＰＡ）を挙げることができる。
本発明において、用語「コンテキスト情報」は、ターゲットプラットフォーム（ハードウェアプロセッサとオペレーティングシステムとの組み合わせ）で利用可能なサービスおよびアーキテクチャに関する情報、ターゲットプラットフォームにとって好ましいネイティブ言語についての情報、ターゲットプラットフォームで利用可能なランタイムコンテキストの能力についての情報を包含している。ランタイムテキストは、実行可能ファイルのための標準的な環境をサポートするために、したがって、生成されるべきソースコードの量を最小限に抑えるために与えられることが好ましい。ランタイムコンテキストは、例えば、利用可能なプログラミング環境、利用可能なイベントシステム、ローカルファイルおよびサービスへのアクセス可能性並びに第三者コンポーネントまたはレガシーシステム等のターゲットプラットフォーム内の他の依存性を含んでいる。イベントシステムは、特定の形式のイベントを送り出すシステム、例えばＪａｖａメッセージサービス、ＪａｖａＢｅａｎイベントリスナーメカニズム、ＭＳウインドウズまたはＸウインドウズイベントディスパッチャである。
複数のサイトにあるコンピュータ装置のネットワークは分散ネットワークと称される。１つのネットワークによって接続されたコンピュータ装置のタイプが異なる場合あるいは上記コンピュータ装置が異なるオペレーティングシステムにしたがって動作するだけである場合、そのネットワークは異質であると表現される場合がある。明らかな例を挙げると、インターネットは巨大な異質分散計算ネットワークと見なすことができる。ソフトウェアアプリケーションを開発するための更に伝統的な手法は、スタンドアロンまたはクライアント／サーバソリューションを構築することであった。クライアント／サーバソリューションは、ネットワークにわたる実施に明らかに適している。これらのソリューションは、それらが実行しているコンピュータ装置のＣＰＵおよびメモリリソースによって制約される。コンピュータ装置が更に強力になるにつれて、また、記憶容量が増大するにつれて、アプリケーションの複雑度は、常に、更に高い計算能力を求めるようになる。
サーバ中心のソリューションによってもともと行なわれるタスクを実施するために多くの一連のコンピュータ装置の計算能力を利用できるようにすることにより物理コンピューティングリソースの制約を最小限に抑える手段として分散処理アーキテクチャが開発された。この能力が利用できる分散処理／計算環境は、幾つかの注目に値する成功、例えばＳＥＴＩプロジェクトを有していた。
分散処理環境の１つの大がかりな例はＧＲＩＤである。ＧＲＩＤは、インターネットまたはイントラネットにわたって利用可能なコンピューティングリソースに対して処理タスクを割り当てることができるランタイム環境である。ユーザにとってＧＲＩＤは大きな仮想コンピューティングシステムとして見える。ＧＲＩＤは、個人と企業との間の安全で調整されたリソース共有を容易にする。グリッド計算の分野で規格が規定され（オープングリッドサービスアーキテクチャ）、これらの規格を普及するのに役立つべく組織が確立された（ｈｔｔｐ：／／ｗｗｗ．ｇｌｏｂｕｓ．ｏｒｇ／参照）。
物理コンピューティングリソースの制約は、ビジネスソリューションの分野で確かに感じられる。反応時には、ビジネスソリューションのための分散計算環境の利点に関心が高まった。なお、ＧＲＩＤのようなソリューションは、ビジネスロジックを分解してそれを幅広い利用可能なコンピューティングリソースにわたって実行するのに理想的な実行環境を与えるが、一組の分散された互いにやりとりするプロセス内において検証可能な方法で実行するビジネスロジックの管理を扱わない。
ビジネスブロックが多くの場所にわたって分散されるようになると、管理することが厳しくなるとともに、組織の要求に基づいて発展（変更）させることが更に難しくなる。従来の分散処理環境内でロジックの一部を変更すると、未知の結果を生むかもしれない。
したがって、検証は、ビジネスロジックが当初の目的を反映する態様で実行されるようにする際に重要である。また、検証は、ビジネスロジック表示がその実行する環境のコンテキスト内で有効となるようにする。これにより、ビジネスロジック表示の変化の管理を制御することができる。すなわち、変化が分散環境上で有するインパクトを、変化が展開される前に適切に評価することができる。その結果、より信頼できるビジネスロジックの実行がなされる。
ビジネスロジックの実施に対する従来の手法は、データおよびサーバを中心とする制約されたものであった。この手法は、多くの場合、一貫性がない報告またはエラーの報告の結果として実行可能なコードを補正するために人による分析を必要とする。
本発明においては、ビジネスロジックの一組のプロセス表示にしたがって分散処理環境内で実行するための実行可能ファイルを形成する方法であって、プロセス計算表記でプロセス表示を行なうステップと、上記表示が有効であることを検証する検証ステップと、検証された表示にしたがって実行可能ファイルおよび対応するテストデータを生成する生成ステップと、上記対応するテストデータを使用して上記実行可能ファイルを検査する検査ステップとを含む方法が提供される。
方法は、検査された上記実行可能ファイルを上記分散処理環境内で展開するステップを更に含むことが好ましい。
方法は、展開された上記実行可能ファイルの性能を監視してプロセス実行情報を集める監視ステップを更に含んでいることが好ましい。
方法は、上記監視ステップで集められた上記プロセス実行情報を分析する分析ステップと、分析された上記プロセス実行情報にしたがって上記実行可能ファイルおよび対応する上記テストデータを自律的に変更する変更ステップとを更に含んでいることがより好ましい。
実行可能ファイルを自律的に変更する上記変更ステップは、分析された上記プロセス実行情報にしたがった実行可能ファイルおよびテストデータの生成を変更することを含んでいても良い。
実行可能ファイルを自律的に変更する上記変更ステップは、上記プロセス表示を変更するとともに、上記検証ステップと上記生成ステップと上記検査ステップとを繰り返すことを含んでいても良い。
あるいは、上記変更ステップは、上記実行可能ファイルおよび上記テストデータを直接変更し、上記検査ステップを繰り返すことを含んでいてもよい。
実行可能ファイルを自律的に変更する上記変更ステップがコンテキスト情報にしたがって行なわれても良い。上記コンテキスト情報は、経験則および／またはＩＴ（情報技術）リソース要求を含んでいることが有益である。
上記生成ステップは、コンテキスト情報にしたがって上記実行可能ファイルを生成することが好ましい。
実行可能ファイルを自律的に変更する上記変更ステップは、分析された上記プロセス実行情報と先の一組のプロセス表示とを比較するとともに、上記実行可能ファイルを変更して実行可能ファイル間の著しい差異を減少させることを含んでいることが好ましい。
著しい差異が無いことが上記比較によって示されるまで、上記生成ステップと上記検査ステップと上記分析ステップと上記変更ステップとが繰り返されても良い。
上記実行可能ファイルは、第三世代言語でソースコードとして生成されることが有益である。上記第三世代言語は、Ｃ、Ｃ＋＋、Ｃ＃、Ａｄａ、Ｊａｖａ、Ｄｅｌｐｈｉ、Ｖｉｓｕａｌ Ｂａｓｉｃ、ＦＯＲＴＲＡＮ ９０を含む一組のセットのうちの１つであっても良い。
上記プロセス計算表記はＸＭＬに基づいていることが好ましい。ＲＩＦＭＬは、そのようなプロセス計算表記の適した例である。
本発明の更なる態様においては、分散処理環境内で実行するための実行可能ファイルを形成するコンピュータプログラムプロダクト（すなわちプログラム）であって、プロセス計算表記でプロセス表示を記憶するデータストアと、上記表示が有効であることを検証する検証モジュールと、検証された表示にしたがって実行可能ファイルおよび対応するテストデータを生成する生成モジュールと、上記対応するテストデータを使用して上記実行可能ファイルを検査する検査モジュールとを備えるコンピュータプログラムプロダクトが提供される。
本発明の更に他の態様においては、ビジネスロジックの一組のプロセス表示にしたがって分散処理環境内で実行するための実行可能ファイルを形成するコンピュータシステムであって、プロセス計算表記でプロセス表示を記憶するためのデータストアと、上記表示が有効であることを検証するための検証モジュールと、検証された表示にしたがって実行可能ファイルおよび対応するテストデータを生成する生成モジュールと、上記対応するテストデータを使用して上記実行可能ファイルを検査する検査モジュールとを備えるコンピュータシステムが提供される。
本発明は、異質な分散ランタイム環境にわたって、複雑なビジネスプロセスの迅速なアセンブリ、検査、検証、展開が可能なミドルウェア技術である。本発明は、ビジネス要求の変化に応じてこれらのプロセスを動的に更新することができるとともに、そのランタイム環境を適合させて、その自由になるリソースのインフラ自体の変化に応じた最適な使用を実現する。
したがって、本発明は、ハイレベルなプロセス仕様を、検証された実行可能形式に変換することを試みる。検証された実行可能形式は、その後、分散処理環境内で実行することができるとともに、ランタイム環境を適合させるために使用可能なフィードバックを行なうために監視することができる。また、本発明では、分散処理環境にわたってビジネスロジックを検証可能な方法で実施することにより、ユーザは、ビジネスロジック表示に対して変更を行なうことができるとともに、実行される既存のタスクに影響を与えることなく、それらの変更を分散処理環境にわたって反映させることができる。
変更は、インフラ構造の変化、ビジネス要求および／または実行可能ファイルの先のバージョンの実行からのフィードバックに応じて必要なだけ実施することができる。すなわち、実行可能ファイルを調整して供給するためにコンテキスト情報が使用される。適切な場合、特に、コンテキスト情報は経験則（一連の知識、経験、経験的な操作態様の総和）の形態を成す。
更新されて検証された実現可能形式は、技術または特定の実施とはほぼ無関係に自律的に供給される。
以下、添付図面を参照しながら本発明の実施例について詳細に説明する。
本発明における重要なコンセプトは自律演算という考え方である。自律演算は、人間の介在を最小限に抑えた自己管理された演算システムへのアプローチと見なすことができる。自律演算システムは、人体の自律神経系に類似させることにより、「意思のある認識または関与」を伴うことなく、重要な機能を制御しようとするものである。ここで、開発プロセスが開発ループにわたって進行するにつれて意思のある人間の識者の必要性が最小限に抑えられることが特に望ましい。
この文書の全体にわたって、プロセスは、任意の実行可能なソフトウェア要素、例えばアプリケーション、オブジェクトまたは構成要素となるように規定される。すなわち、用語「ポート」および「チャンネル」は、２つのプロセス間の任意の通信経路を示すために使用される。
図１は本発明に係る自律フィードバックループ１００を示している。ビジネスロジック仕様１０２とも称される一組のビジネスロジック表示は、分散処理環境１１０で実行するための一組の有効プロセス１０４として与えられる（ステップ１１２）。実行する分散ビジネスロジック表示の相関「ビュー」１０６が形成される。
有効プロセス１０４の実行を促すとともに、ビジネスロジック仕様１０２と相関「ビュー」１０６との間の差異を減少させるため、相関ビュー１０６と当初のビジネスロジック仕様１０２とが有利に比較されても良く、また、コンテキスト情報（経験則情報を含む）が適用されても良い（ステップ１１６）。コンテキスト情報の適用は、分散処理環境のコンテキスト内で、プロセス１０４の実行可能な形式の性能を調整するのに役立つ。この比較・調整ステップ（ステップ１１６）は、自律的に繰り返すように設定できるフィードバックループを閉じる。
本発明は、ハイレベル仕様１０２を検証された実行可能な形式１０４に変換するために必要な一連のステップ（ステップ１１２）を開示している。
第１のステップはビジネスロジック検証である。この場合、分散処理環境内のビジネスロジック仕様すなわち一組のビジネスロジック表示の有効性が検証される。
検証された仕様は、分散処理環境内で実行可能なフォーマットに変換される。この変換ステップは、コンテキスト情報を使用することにより、ビジネスロジックに最も適した実行表示を決定するとともに、その実行表示が分散処理環境内で効率的に機能できるようにする。コンテキスト情報の一例は経験則である。経験則は、一連の知識、経験、実際の演算態様である。コンテキスト情報の更なる例はＩＴリソース要求である。すなわち、ＩＴリソース要求が能力を特定する場合、実行可能なプロセスは、これらの要求をサポートできる（したがってプロセスを実行できる）ランタイムノードの一部を特定するために使用されても良いそのランタイム環境から要求する。上記変換は、ビジネスロジックを監視して分析できる一方で分散処理環境内において実行できる方法を実行可能な形式に対して与える。
検証された実行可能なコードは、自動的に形成されたテストケースに対して検査される。当初のビジネスロジックに基づくテストケースにより、ビジネスロジックの実行可能な形式の完全でかつ十分な検査が行なわれる。また、特定のシナリオを実行しかつ環境内に既に展開された既存のビジネスロジックとやりとりするために、更に別の検査が行なわれても良い。
プロセスのランタイム実行の監視および分析によって更なる改良が成される。必要に応じて、必要と思われる任意の変更が変換ステップおよび／または検証ステップに対して自動的にフィードバックされる。
ここで、前述したステップについて更に詳細に説明する。
ビジネスロジック検証
ビジネスロジックを検証するための必要条件は、ビジネスロジックが適切な表記で表わされているということである。分散処理環境内で実行されるビジネスロジックを表わしかつその後の検証を可能にするための１つの適した形式論は、プロセス計算（Ｐｒｏｃｅｓｓ Ｃａｌｃｕｌｕｓ）として知られている。この種の形式論の最も有名な例は一般にＰｉ計算（Ｐｉ Ｃａｌｃｕｌｕｓ）として知られている。
上記プロセス計算によれば、やりとり、一組のメッセージ、それらの有効なプロセス間シーケンスを形式的に規定することができる。プロセス計算の数学により、２つのプロセス定義を示すことができ、代数的操作により２つのプロセス定義を形式的に等しくする（或いは等しくしない）ことができる。
また、プロセス計算は、形式的な態様でやりとりする一組のプロセスの仕様を可能にする。また、プロセスは、他のプロセスとのやりとりを表わすことができるとともに、ポート（またはチャンネル）を交換することができ、また、ポート間でプロセスさえも交換することができる。この自由度は、時として、プロセス通信の「機動性」の観点から表わされる。ビジネスロジックを検証するために必要な段階について図２を参照して説明する。
検証ステップは、ビジネスロジック仕様の構文の検証（ステップ２０２）、通信プロセス間のインタフェース（ポート）を検証すること（ステップ２０４）、ビジネスロジックが安全タイプであることを検証すること（ステップ２０６）、ビジネスロジックが正しいことを検証すること（ステップ２０８）を含んでいる。
第１のレベルの検証（ステップ２０２）は、ビジネスロジック仕様の構文または構造に関連している。構文が有効でない場合には、更なるレベルの検証へと移行することができない。ビジネスロジックがＸＭＬとして表わされる場合には、構文解析ツールを検証する標準的なＸＭＬを用いてビジネスロジックの構文を検証することができる。この場合、何が有効な構文であるかを表わすために、付随するＤＴＤまたはＸスキーマが規定される。
プロセス計算は、強くタイプ付けされたプロセス間のインタフェース（ポートまたはチャンネルとして知られる）を規定する。タイプの定義は、そのようなインタフェースとの関連で、従来のプログラミング言語（例えばＪａｖａ、Ｃ＃、Ｃ＋＋等）において一般的である静的なタイプおよび外部から見ることができるプロセスの動作に基づく「動的な」タイプの両方を含んでいる。それは、プロセス間の「意味的」インタフェースの取得、実際にはポートまたはチャンネルとしてのそれらの表示を可能にする動的タイプの使用である。プロセスは、これらのポートまたはチャンネルを介して互いに通信することにより、意味的に正しい方法で互いにやりとりする。
したがって、次のレベルの検証（ステップ２０４）は、プロセスがその使用しているポートに関連付けられたタイプ仕様に正確に従うようにすることであり、メッセージシーケンスが有効となるようにすることである。更なる制約を加えることにより、パラメータとして通されても良い有効な値を、これらのポートで行なわれる演算に制限することができる。これらの制約の幾つかは、この処理段階中に検証される。一方、その他の制約はランタイムでしか検証することができない。
この制約情報は、検査されるビジネスロジックをより正確に実行するために「テストケース生成」構成要素によって使用することができる。例えば、パラメータが「整数」タイプを表わしている場合には、制約を加えることにより、その値が所定の範囲内となるようにしても良い。ビジネスロジックがパラメータ値を静的なリテラル値として供給しない場合には、この制約がビジネスロジックの静的な分析中に破られたかどうかを決定することはできない。したがって、パラメータの値を検証しかつ無効な値が供給される場合に例外を生成するために、（以下の変換段階によって）ランタイムチェックを挿入する必要がある。
ビジネスロジックがアクセスした情報（すなわち「オブジェクト」）を用いて有効なタスクを実行できるように、更なる検証を行なうことができる。プロセスは、それがアクセスした情報に関連付けられたオブジェクトモデルをナビゲートすることによりおよび／またはその範囲内にある「オブジェクト」上で方法を呼び出すことにより、情報を演算のパラメータとして受けることができる。また、ビジネスロジックは、「オブジェクト」に対して条件を適用するとともに、情報を操作して新たな情報を得ることができる。検証段階は、ビジネスロジック内で使用される情報（または「オブジェクト」）の性質に関するメタ情報にアクセスすることにより、それらが条件を満たしているタイプであるかどうかおよび／またはそれらがビジネスロジック内でのその使用をサポートするために適した方法を規定するかどうかを判断する。
検証処理により、制御および操作の全てにおいて構造が表記によってサポートされなければならず、また、ビジネスロジックが安全タイプの態様でしかタスクを実行しないように制約されなければならない（ステップ２０６）。例えば、「ｉｆ」または「ｗｈｉｌｅ」命令文内で使用されても良い条件によりブールタイプの値が得られなければならず、また、数字タイプの変数／値に関して算術演算しか行なうことができない。
ハイレベルビジネスロジック検証の目的は、構文およびタイピングに関してそれが条件をみたすようにするだけではなく、ビジネスロジック（実行される時）が正確にタスクを実行し（ステップ２０８）、それにより、不必要なランタイムエラーが生じないようにすることである。そのようなエラーの一例は、ローカル状態または出力ポートをそれが初期化される前に使用することである。出力ポートは「ディスカバリ（発見）」サービスから動的に検索され、したがって、適当な発見アクティビティまたは割り当てアクティビティが行われる前にポートが使用される場合には、これがエラーとして警告が与えられ（フラグがたてられ）なければならない。あるいは、関連する演算を行なうために利用できるポートがない場合、ビジネスロジックを実行するだけでランタイムエラーが生じる。
ビジネスロジックの仕様がハイレベルであれば、アクティビティの総合的な意味分析が容易になる。
実行可能な形式への変換
分散処理環境において、所定の装置またはノードのコンテキストは、ネットワーク内のその物理的な場所およびそのソフトウェアのコンフィギュレーションによりその装置に影響を与える任意の一般的な条件を参照する。コンテキスト情報の重要なクラスは、経験則として知られる一連の知識、経験、実際の演算態様である。前述したように、ＩＴリソース要求は更なるクラスのコンテキスト情報を形成し、これにより、ＩＴリソース要求は、実行可能なプロセスがそのランタイム環境から要求する能力を特定する。これらの特定された能力は、それらの要求をサポートできる（したがって、プロセスを実行できる）ランタイムノードの一部を特定するために使用されても良い。
検証されたハイレベルビジネスロジックは、分散処理環境内で展開されて実行される実行可能形式へと変換される。この変換処理は、コンテキスト情報を使用することにより、最も適した効率的な実行可能形式を生成する。変換処理が行なわれる方法に影響を与えることができるコンテキスト要素としては、分散処理環境で使用されるターゲットプログラミング言語、マルチプロセッササーバから携帯端末（ＰＤＡ）に至る、分散処理環境内で使用される装置のタイプ、変換されるビジネスロジックの既存のバージョンの実行によって集められた性能統計値、ＩＴリソース要求および経験則（前述した）を挙げることができる。
したがって、ビジネスロジック（例えば標準的なＸＭＬに基づくプロセス表示のビジネスブロック）は、特にターゲットプラットフォームおよび処理環境に適したプログラミング言語を選択するジェネレータを使用して実行可能なコードに変換される。実行可能なコードの好ましい言語はＪａｖａであるが、他の３ＧＬも適している。すなわち、オブジェクトコード（バイナリ）が直接に生成されても良い。それによって形成される実行可能な表示は、分散処理環境で実行するのに適している。分散処理環境のうちの一例がＪａｖａランタイム環境である。これは、コンテキスト情報にしたがって実行可能な表示を最適化するプロセスの自律ライフサイクル管理の一例である。
この時点で、プロセス表記の構造について詳述することが適当である。
プロセス
これは、分散処理環境内で実行しかつポートを介して他のプロセスとやりとりするビジネスロジック「ユニット」のためのハイレベル「コンテナ」である。プロセスにおいて最も効率的なランタイム実行可能なフォーマットを与えるためには、それを例えばＪａｖａクラスに変換することができる。クラスの実施は、そのプロセスのためのビジネスロジックを表わしており、プロセスに関連付けられるポートで受けられるメッセージに反応する一組のサブプロセス（後述する）として実行される。
ポート定義
明細書のこの部分は、プロセスによって使用されたポートについて説明する。プロセスが他のプロセスからの要求を受けるポートを示すために入力ポートが使用され、また、出力ポートは、このプロセスが他のプロセスに対して要求を行なうことができるポートを規定する。これらのポート定義は、変換ツールへロードされ、このプロセスがランタイム環境内でやりとりする或いはやりとりできるプロセス間でメッセージを受けまたは送るための任意の要求を検証するために使用される。
実行環境は、他のプロセスとの通信を確立するため、プロセスの実行可能なバージョンと、ポートエンドポイントを形成しおよび／または検索するための手段とを与える。したがって、ランタイム環境は通信チャンネルの管理を担っている。プロセスは、これらのポート／チャンネルを使用するビジネスロジックの制定を担っている。
プロセス制約
プロセスは、正確に実行するためにそれがランタイム環境から要求するリソースが何であるのかを示すために使用される一連の制約を規定しても良い。この情報は、プロセスが最も効率的に実行できる場所を決定するために、分散処理環境によって使用される。制約がプロセス定義内で定められる場合には、プロセスが実行するランタイム環境内にも上記制約が存在しなければならない。依存性は、環境（例えば実行言語および／またはバージョン）に関連していても良く、あるいは、システム／コンポーネント依存性（例えば、レガシーシステムまたはライブラリファイルやＪａｖａＪＡＲファイル等のソフトフェアコンポーネント）に関連していても良い。
サブプロセス
プロセスの性質は、それがメッセージ（例えば要求、応答、故障、タイムアウト）に反応するという点である。したがって、プロセスは、それぞれが特定のメッセージに対して応答するようになっている一組のサブプロセスに分解することができる。全てのメッセージが常に１つのプロセスに関連しているとは限らない。プロセスは、その寿命の間、様々な状態にわたって移行する。任意の所定の状態においては、受信され得るメッセージの一部が関心の対象である。この点で、ビジネスロジックの実行可能な形式を、状態機械を実行していると見なすことができる。しかしながら、状態機械の実行は、データベース中心の状態テーブルの操作とは対照的に、実行可能なサブプロセスを中心に展開する。
（特定の刺激を扱うために呼び出された）サブプロセスは、そのタスクを終了すると、その現在の状態でプロセスに関連する刺激の次の組への関心を登録する。したがって、サブプロセス内でエンコードされたビジネスロジックに応じて動的状態移行態様をモデリングできる。
コンセプトをサポートする実行可能言語においては、サブプロセスを「内部クラス」として実施することができる。このタイプのクラスは、それが規定されるクラス（この場合、それが属するプロセスである）に探られる点を除き、通常のクラスとコンセプトが類似している。したがって、サブプロセスの変換は、それが表わす任意のアクティビティ（以下を参照）の実行を担う内部クラスの形成を含んでいる。他の変換義務は、関連する刺激が受けられる時にサブプロセスを形成する方法についての知識をプロセスに対して与えることである。
アクティビティ
サブプロセスの範囲内には、サブプロセスを起動させた刺激の対処に関与するビジネスロジックを表わす詳細なアクティビティが含まれている。
アクティビティのうちの幾つかは以下の制御構造に関連している。
（ｉ）条件文 − ｉｆ ｔｈｅｎ ｅｌｓｅ
条件付きの表現は、「ｔｈｅｎ」または随意的に「ｅｌｓｅ」部分に関連付けられたアクティビティが実行されるかどうかを決定する。条件付きの表現は、有効範囲内の変数に適用される論理演算子（ＡＮＤ、ＯＲ、ＮＯＴ）または算術演算子から成っていても良い。変数は、入力メッセージから受けたパラメータの結果として或いはサブプロセス内で明示的に示されたパラメータの結果として有効範囲内である。
（ｉｉ）ループ構成体
「ｗｈｉｌｅ」ループは、特定の条件付き表現が偽の判断をするまで、含まれているアクティビティを実行することができるようにサポートされる。
（ｉｉｉ）スロー(Throw)例外
ビジネスロジックによってエラーが検出される場合には、それによって「例外」が形成され、現在の実行が終了してしまう可能性がある。制御は、ランタイム環境に戻され、あるいは、１が登録された場合には例外ハンドラに戻される。
実行され得る他のアクティビティとしては、ローカル変数を明示すること、情報を変数に対して割り当てること、変数に関連付けられた情報を検索すること、方法を呼び出すこと、メッセージを送ること、メッセージを受けること、例外を扱うことを挙げることができる。上記アクティビティのうちの幾つかは、サブプロセスの有効範囲内に直接ある変数（すなわち、受けられたメッセージまたは明示された変数におけるパラメータ）において行なうことができ、あるいは、他の組のアクティビティを実行することにより得られるコンテキストで行なうことができる。例えば、ビジネスロジックは、値を戻す明示された変数において方法を呼び出すことができる。その後、この値は、割り当てが実行される「コンテキスト」となり得る。これの一例は、顧客名をパラメータとして供給する、バンクによって保持されるアカウントを表わす変数において方法「ｇｅｔＡｃｃｏｕｎｔ」を呼び出すことである。その後、結果として得られるアカウントは、現在のバランスを補正するため、それに関して実行される割り当てアクティビティを有していても良い。これらのアクティビティのそれぞれは、標準的なプログラミング言語構成要素上にマッピングされても良い。
与えられる仕様情報のタイプの例および結果として得られる変換されたクラスの考えられる構造は、以下の通りであり、
<process name="TradingSystem">
<ports>
<port name="TradeEntryPort"type="input">
....
</port>
<port name="PrinterPort"type="output">
....
</port>
</ports>
<constraint name="printer"type="resource"/>
<subProcess name="ReceiveTrade">
<receive port="TradeEntryPort"operation="validateTrade">
....
<send port="PrinterPort"operation="print">
....
</send>
</receive>
</subProcess>
<subProcess name="SendNotification">
....
</subProcess>
</process>
また、以下の形式に変換される。
public class TradingSystem extends Process {
public TradingSystem (Runtime runtime) {
....
}
public SubProcess getSubProcess (String name) {
if (name. equals ("ReceiveTrade")) {
return (new ReceiveTrade ()) ;
}
....
}
public class ReceiveTrade extends SubProcess {
....
public class SendNotification extends SubProcess{
....
}
}
移行手続きの他の要求は、実行可能な形式を計測することである。この計測は、プロセスがどのように実行して互いにやりとりしているかについての情報を監視する。この情報を使用することにより、更なるレベルの検証および更なるバージョンの実行可能形式の最適化をサポートすることができる。
監視イベントは、特に、何時メッセージがプロセスインスタンス間を通過したか；何時プロセスインスタンスが形成され或いは終了されたか；何時状態情報が更新されたか；何時サブプロセスが行なわれるか；或いは何時決定ポイントが評価されるかを示すために生成される。なお、変換プロセスは、直接に実行可能形式を形成することができ、あるいは、後に実行可能形式にコンパイルされるプログラミング言語で表わされた中間バージョンを形成することができる。
自動的に生成されたテストケースに対する実行可能形式の検査
任意のソフトウェアソリューションの検査に伴う問題の１つは、検査がシステムの全ての態様を行なうことができるようにすることである。テストケースが指定されて適用前に開発される厳しい制御を伴うプロジェクトにおいてさえ、検査が複雑なシステム（特にそれが定期的に機能強化される場合）の全ての態様を実行し損ねる可能性がある。
これに関する主な理由は、それが、何の検査を必要としているかを決定しその後にそれらの検査シナリオを実施して実行するためにマニュアルプロセスに頼っているからである。形式的な技術（特にプロセス計算）に基づいてビジネスロジックを形成する利点は、ビジネスロジックを分析しかつその後に自動的に実行できる関連するテストケースを自動的に形成するためにツールを開発できるという点である。
図３に概略的に示されるように、第１のステップ（ステップ３０２）は、プロセス（またはビジネスロジック）に関連付けられた入力および出力「インタフェース」が環境内の他のコンポーネントを用いて何をやりとりできるかを決定する際にこれらのインタフェースを理解することである。入力ポートは、プロセスに対して送られる要求を得るために使用することができ、また、出力ポートは、それらの対応するプロセスの機能エミュレートするシミュレーションプロセスを形成するために使用することができる。これらのシミュレートされたプロセスは、実行されるテストケースに応じて適切な態様で応答するように形成される。
テストケースジェネレータは、その最も高いレベルで、ビジネスロジックを通る可能な経路毎に少なくとも１つのテストケースを形成する。このことは、任意の条件文を分析することにより、条件のための真の値および偽の値を確保するために何の情報が必要であるかを決定しなければならないことを意味している。また、ビジネスロジックを通る可能な一組の経路を形成するために、サブプロセスがやりとりする方法から得られる依存関係グラフも使用される（ステップ３０４）。
ポートおよびコンポーネントの使用上の制約が特定される（ステップ３０６）。更に詳細な制約情報が規定されて例えばポートの操作のために規定されるパラメータに関連付けられると、極小値および極大値の検査を含む異なる制約検査を用いて依存関係グラフにより異なる経路を使うために更に詳細なテストケースを生成することができる（ステップ３０８）。
ビジネスロジックの計測された実行可能形式から形成された監視情報は、期待された動作に対して各テストケースに関連付けられた実行の経路をトレースするために使用することができる。
プロセスのランタイム実行の分析
分散処理環境内に展開されたビジネスロジック仕様の分散処理実行によって形成される計測情報を分析することにより、通信プロセスインスタンス間でアクティビティを関連付けることができる（図１のステップ１１４）。この情報は、プロセスインスタンスによって送受信されるメッセージから得ることができる。
最初にこれらのプロセスインスタンス間の接続を識別するため、しかし更に重要なことには、分散環境内でビジネスロジックが実行される方法を最適化するために使用できる距離情報を得ることができるように、図４のやりとりのグラフを構成することができる。
図４に示されるやりとりのグラフは、監視イベントの受信（４０２）で始まる。対応するプロセスを実行している間、イベントを静的に受けることができ（すなわち、記録された監視イベントの履歴データベース上での問合せの結果として）あるいは「リアルタイム」で動的に受けることができる。
その後、記録が既に監視されたプロセスインスタンスに属しているかどうか（４０４）を判断するために、プロセスインスタンスがチェックされる。プロセスインスタンスが既に監視されている場合、それは既に監視グラフの一部となる。
プロセスが既に監視されている場合には、メッセージが送られることを監視イベントが示しているかどうかをチェックする必要がある（４０６）。メッセージが送られる場合には、対象リストに対してメッセージＩＤが加えられなければならず（４０８）、これにより、メッセージを受けるプロセスインスタンスについての情報が取得されるようになるとともに、構成される監視グラフ内でプロセス間のつながりが強調される。
監視イベントに関連付けられたプロセスインスタンスが現在監視されていない場合であって、監視イベントが関心対象のプロセスによって既に送られたメッセージを受けるプロセスインスタンスに属していない場合、監視イベントは関心の対象ではない（４１０）。その後においてのみ、「プロセスインスタンス」が監視リストに対して加えられる（４１２）。プロセスインスタンス間の関連性は、既に監視された他のプロセスからのメッセージを受けるプロセスインスタンスによって形成される。プロセスインスタンス間の関連性は、２つのプロセスインスタンス間の通信経路を定める。このことは、「受信する」プロセスインスタンスのための任意のその後の監視イベントがここで更に取得されなければならず、したがって、メッセージを受信したプロセスとメッセージを送信したプロセスとの「アーク」リンクを行なわなければならない（４１４）ことを意味している。
監視イベントが既に監視され或いは監視リストに対して最近加えられている場合には、各監視イベントがそれと関連するプロセスノードおよびサブプロセスノードに関連付けられるようにしなければならない（４１６）。このことは、各ノードに関連付けられたアクティビティ、プロセスインスタンス間のやりとり、例えば要求／応答の待ち時間、あるいは、各プロセスで要する時間のパーセンテージから性能情報を得ることができることを意味している。
（図４に示される処理を使用して構成される）やりとりのグラフは、それ自体、多くのプロセスにわたる特定のビジネストランザクションの実行によってトレースする方法として有益となり得るが、２つのハイレベルな目的のため、すなわち、ビジネスロジックの最終的な検証として、また、実行可能形式を改善するために使用することもできる。
最終的な検証は、実際の性能と始めに定められた目的との間の比較を含んでいる（図１のステップ１１６）。やりとりのグラフは、特定のビジネストランザクションを達成するために複数のプロセス（およびサブプロセス）がどのようにやりとりされたかを示している。この情報を当初のビジネスロジック仕様に対して比較できるように、当該ビジネスロジック表示（またはプロセス）に関連付けられたやりとりのグラフの関連部分が抽出される。その後、このプロセスのコンテキスト内で、やりとりのグラフは、プロセスインスタンスが形成される点から、１または複数のサブプロセスにわたってその終結まで移行することにより、検査することができる。プロセスの性質に応じて、また、取得されたやりとりのグラフの持続時間に応じて、ビジネスロジック仕様の検証は、プロセスの終結まで広げられなくても良い。しかしながら、検証はそれが可能な限り進行し、それにより、関連付けられた監視情報が、ビジネスロジック仕様にわたる経路を、関連する状態変化および決定ポイントと共に正確に特定していることをチェックする。
やりとりのグラフを使用した実行可能形式の改善は、プロセス毎に情報を破壊できるグラフの能力に頼っている。任意の特定のタスクを行なうのに費やされた持続時間およびタスクの一部を他のプロセスインスタンスに任せるのに費やされた時間に関連するメトリクスを得ることができる。このことは、アクティビティの機能停止が生じ得ることを意味しており、プロセスインスタンス内でいかに多くの時間が実際に費やされたのか、処理の一部としてやりとりされたプロセスインスタンスでいかに多くの時間費やされたのか、注目に値すべきなのは、プロセスインスタンス間で要求を通すのにいかに多くの時間（待ち時間）が費やされたのかを示している。この情報は、一組の処理の実行可能形式が異なる方法で分解されるべきかどうかを決定するために使用することができ、そのため、かなりの量の要求が２つのビジネスロジック表示間で通される場合には、それらの要求を同じ場所に再び配置することにより、要求をやりとりするための時間を減らすことができる。
同様に、各コンポーネントをそれが要求するリソースと同じ場所に適切に配置できる場合には、１つのプロセス（および対応するビジネスロジック）を複数のサブコンポーネントに分解できると考えられる。これの典型的な例は、ユーザとの多くのやりとりを行ない、その後、リソース（例えば、レガシーシステムまたはデータベース）と多くのやりとりを行なうプロセスである。プロセスがユーザと同じ場所に配置される場合、リソースへのアクセスは非効率的となり、また、逆も同様である。したがって、プロセスをうまく分解できる場合には、ユーザ集約的なアクティビティがユーザの近くに存在する可能性があり、関連する情報を、１つのリクエストの状態で、リソースと同じ場所に配置される他の分解されたプロセスに対して送ることができる。
本発明にとって好ましい環境は、リアクティブ・インテリジェンス・フレームワーク、すなわち頭文字をとってＲＩＦと称される。ＲＩＦを使用すると、ビジネスは検証可能でかつ自律的に更新される方法でビジネスロジックを実施できる。
例示的なシナリオが図５に示されている。このシナリオは、方針を決定する責任がある「中央方針立案者」５０２に基づいている。このシナリオのビジネスロジックは、ＲＩＦ分散処理環境内で特定することができる。方針は、ＲＩＦのプロセス仕様に対して直接にマッピングする平叙ＸＭＬ形式すなわちＲＩＦマークアップ言語（ＲＩＦＭＬ）５０４でエンコードされる。方針立案者５０２は、方針を実施しなければならない事業体（エンティティ）（以下、広く「構成要素」と称する）５０６Ａ−Ｃに対して方針を供給する。その結果、「構成要素」５０６Ａ−Ｃはその方針に従う（または実施する）責任を有する。
中央方針立案者は、取締機関または企業内の何らかの順守部門であっても良い。構成要素は、監督機関によって取り締まられる企業または企業内の部門に対応していても良い。取締機関であろうと順守部門であろうと、方針立案者５０２は方針を構成要素５０６に対して供給し、構成要素５０６Ａ−Ｃは異なるＩＴインフラ構造を操作し（これにより、我々が言わんとするところは、ビジネス機能をサポートするために計算リソースがネットワークと適切なソフトウェアとを結び付けたということである）、これにより、両者が異質でかつ半自律的となる。中央方針立案者５０２は、方針の実施方法を強要することができず、その方針が何であるかを規定するだけである。
中央方針立案者５０２が知る必要があることは、上記方針が構成要素の異なるＩＴインフラ構造にわたって適切に実施されるということである。方針は、何が許容されるかは示すが、それが実施されるべき方法については示さない。課題は、方針の実施が中央方針立案者が規定したものと同じであることを正式に証明できるということである。この課題の解決によって、一貫した方針管理を動的な状況で行なえなければならない。
方針が何であるかについて、また、同じ方針の構成要素の実施についての中央方針立案者の意志は、例えばレガシーシステムの領域で広がっても良い。不正確にモデリングされたレガシーシステムにおけるラッパーによって無効なメッセージのやりとりが生じ、無効がその方針についての中央方針立案者の規定に対する無効を意味している状況を考える。このような状況は、同期システムを非同期メッセージ受け渡しインフラ構造に送り込む際のタイミングの問題に起因して起こる。これにより、分配されたプロセスの実行からの監視情報が当初のビジネスロジック（すなわち、中央方針立案者によって規定された方針）に対して比較される。これによって、要求された行動と方針の実施との間の任意の差が強調され、それにより、変換機構を自律的に変えることができ、その結果、人の分析を必要とすることなく正確な行動を確保して、ビジネスロジック表示または実行可能ファイルを補正することができる。
自律フィードバックループを示すブロック図である。 検証ステップにおける複数のステップのブロック図である。 テストケース生成ステップのブロック図である。 分析ステップのフローチャートである。 本発明を適用できるシナリオの一実施例を示している。
本発明においては、ビジネスロジックの一組のプロセス表示にしたがって分散処理環境内で実行するための実行可能ファイルを形成する方法であって、プロセス計算表記でプロセス表示を行なうステップと、上記表示が有効であることを検証する検証ステップと、検証された表示にしたがって実行可能ファイルおよび対応するテストデータを生成する生成ステップと、上記対応するテストデータを使用して上記実行可能ファイルを検査する検査ステップと、検査された上記実行可能ファイルを上記分散処理環境内で展開するステップと、展開された上記実行可能ファイルの性能を監視してプロセス実行情報を集める監視ステップと、上記監視ステップで集められた上記プロセス実行情報を分析する分析ステップと、分析された上記プロセス実行情報にしたがって上記実行可能ファイルおよび対応する上記テストデータを自律的に変更する変更ステップとを含む方法が提供される。
実行可能ファイルを自律的に変更する上記変更ステップは、分析された上記プロセス実行情報の一組の表示と先の一組のプロセス表示とを比較するとともに、上記実行可能ファイルを変更して実行可能ファイル間の著しい差異を減少させることを含んでいることが好ましい。
有利には、上記実行可能ファイルを生成するステップは、検証された表示の中間バージョンを第三世代言語で生成し、中間バージョンを実行可能ファイルへコンパイルすることを含む。上記第三世代言語は、Ｃ、Ｃ＋＋、Ｃ＃、Ａｄａ、Ｊａｖａ、Ｄｅｌｐｈｉ、Ｖｉｓｕａｌ Ｂａｓｉｃ、ＦＯＲＴＲＡＮ ９０を含む一組のセットのうちの１つであっても良い。あるいは、上記実行可能ファイルを生成するステップは、実行可能ファイルを直接に生成することを含む。
本発明の更なる態様においては、ビジネスロジックの一組のプロセス表示にしたがって分散処理環境内で実行するための実行可能ファイルを形成するコンピュータプログラムプロダクト（すなわちプログラム）であって、プロセス計算表記でプロセス表示を記憶するデータストアと、上記表示が有効であることを検証する検証モジュールと、検証された表示にしたがって実行可能ファイルおよび対応するテストデータを生成する生成モジュールと、上記対応するテストデータを使用して上記実行可能ファイルを検査する、検査された上記実行可能ファイルを上記分散処理環境内で展開させることができる、検査モジュールと、展開された上記実行可能ファイルの性能を監視してプロセス実行情報を集めるための監視モジュールと、上記監視モジュールによって集められた上記プロセス実行情報を分析するための分析モジュールと、分析された上記プロセス実行情報にしたがって上記実行可能ファイルおよび対応する上記テストデータを自律的に変更する更新モジュールと、を備えるコンピュータプログラムプロダクトが提供される。
本発明の更に他の態様においては、ビジネスロジックの一組のプロセス表示にしたがって分散処理環境内で実行するための実行可能ファイルを形成するコンピュータシステムであって、プロセス計算表記でプロセス表示を記憶するためのデータストアと、上記表示が有効であることを検証するための検証モジュールと、検証された表示にしたがって実行可能ファイルおよび対応するテストデータを生成する生成モジュールと、上記対応するテストデータを使用して上記実行可能ファイルを検査する、検査された前記実行可能ファイルを前記分散処理環境内で展開させることができる、検査モジュールと、展開された前記実行可能ファイルの性能を監視してプロセス実行情報を集めるための監視モジュールと、前記監視モジュールによって集められた前記プロセス実行情報を分析するための分析モジュールと、分析された前記プロセス実行情報にしたがって前記実行可能ファイルおよび対応する前記テストデータを自律的に変更する更新モジュールとを備えるコンピュータシステムが提供される。
したがって、ビジネスロジック（例えば標準的なＸＭＬに基づくプロセス表示のビジネスブロック）は、特にターゲットプラットフォームおよび処理環境に適したプログラミング言語を選択するジェネレータを使用して実行可能なコードに変換される。実行可能ファイルの中間バージョンの好ましい言語はＪａｖａであるが、他の３ＧＬも適している。すなわち、オブジェクトコード（バイナリ）が直接に生成されても良い。それによって形成される実行可能な表示は、分散処理環境で実行するのに適している。分散処理環境のうちの一例がＪａｖａランタイム環境である。これは、コンテキスト情報にしたがって実行可能な表示を最適化するプロセスの自律ライフサイクル管理の一例である。
コンセプトをサポートする言語においては、サブプロセスを「内部クラス」として実施することができる。このタイプのクラスは、それが規定されるクラス（この場合、それが属するプロセスである）に探られる点を除き、通常のクラスとコンセプトが類似している。したがって、サブプロセスの変換は、それが表わす任意のアクティビティ（以下を参照）の実行を担う内部クラスの形成を含んでいる。他の変換義務は、関連する刺激が受けられる時にサブプロセスを形成する方法についての知識をプロセスに対して与えることである。

Claims (51)

  1. ビジネスロジックの一組のプロセス表示にしたがって分散処理環境内で実行するための実行可能ファイルを形成する方法であって、
    プロセス計算表記でプロセス表示を行なうステップと、
    前記表示が有効であることを検証する検証ステップと、
    検証された表示にしたがって実行可能ファイルおよび対応するテストデータを生成する生成ステップと、
    前記対応するテストデータを使用して前記実行可能ファイルを検査する検査ステップと、
    を含む方法。
  2. 検査された前記実行可能ファイルを前記分散処理環境内で展開するステップを更に含む、請求項１に記載の方法。
  3. 展開された前記実行可能ファイルの性能を監視してプロセス実行情報を集める監視ステップを更に含む、請求項２に記載の方法。
  4. 前記監視ステップで集められた前記プロセス実行情報を分析する分析ステップと、分析された前記プロセス実行情報にしたがって前記実行可能ファイルおよび対応する前記テストデータを自律的に変更する変更ステップとを更に含む、請求項３に記載の方法。
  5. 実行可能ファイルを自律的に変更する前記変更ステップは、分析された前記プロセス実行情報にしたがった実行可能ファイルおよびテストデータの生成を変更することを含む、請求項４に記載の方法。
  6. 実行可能ファイルを自律的に変更する前記変更ステップは、前記プロセス表示を変更するとともに、前記検証ステップと前記生成ステップと前記検査ステップとを繰り返すことを含む、請求項４に記載の方法。
  7. 実行可能ファイルを自律的に変更する前記変更ステップがコンテキスト情報にしたがって更に行なわれる、請求項４に記載の方法。
  8. 前記コンテキスト情報が経験則を含んでいる、請求項７に記載の方法。
  9. 実行可能ファイルを生成する前記生成ステップがコンテキスト情報にしたがって更に行なわれる、請求項１に記載の方法。
  10. 実行可能ファイルを自律的に変更する前記変更ステップは、前記実行可能ファイルおよびテストデータを直接に変更するとともに、前記検査ステップを繰り返すことを含む、請求項４に記載の方法。
  11. 実行可能ファイルを自律的に変更する前記変更ステップは、分析された前記プロセス実行情報と先の一組のプロセス表示とを比較するとともに、前記実行可能ファイルを変更して実行可能ファイル間の著しい差異を減少させることを含む、請求項４に記載の方法。
  12. 著しい差異が無いことが前記比較によって示されるまで、前記生成ステップと前記検査ステップと前記分析ステップと前記変更ステップとを繰り返すステップを更に含む、請求項１１に記載の方法。
  13. 前記実行可能ファイルが第三世代言語でソースコードとして生成される、請求項１に記載の方法。
  14. 前記第三世代言語は、Ｃ、Ｃ＋＋、Ｃ＃、Ａｄａ、Ｊａｖａ、Ｄｅｌｐｈｉ、Ｖｉｓｕａｌ Ｂａｓｉｃ、ＦＯＲＴＲＡＮ ９０を含む一組のセットのうちの１つである、請求項１３に記載の方法。
  15. 前記プロセス計算表記がＸＭＬに基づいている、請求項１に記載の方法。
  16. 前記プロセス計算表記がＲＩＦＭＬに基づいている、請求項１３に記載の方法。
  17. ビジネスロジックの一組のプロセス表示にしたがって分散処理環境内で実行するための実行可能ファイルを形成するコンピュータプログラムであって、
    プロセス計算表記でプロセス表示を記憶するデータストアと、
    前記表示が有効であることを検証する検証モジュールと、
    検証された表示にしたがって実行可能ファイルおよび対応するテストデータを生成する生成モジュールと、
    前記対応するテストデータを使用して前記実行可能ファイルを検査する検査モジュールと、
    を備える、コンピュータプログラム。
  18. 前記検査モジュールは、検査された前記実行可能ファイルを前記分散処理環境内で展開させることができる、請求項１７に記載のコンピュータプログラム。
  19. 展開された前記実行可能ファイルの性能を監視してプロセス実行情報を集めるための監視モジュールを更に備える、請求項１８に記載のコンピュータプログラム。
  20. 前記監視モジュールによって集められた前記プロセス実行情報を分析するための分析モジュールと、分析された前記プロセス実行情報にしたがって前記実行可能ファイルおよび対応する前記テストデータを自律的に変更する更新モジュールとを更に備える、請求項１９に記載のコンピュータプログラム。
  21. 実行可能ファイルおよび対応する前記テストデータの自律変更は、分析された前記プロセス実行情報にしたがった生成モジュールの動作の変更を含む、請求項２０に記載のコンピュータプログラム。
  22. 前記更新モジュールは、前記プロセス表示を変更するとともに、前記検証モジュール、前記生成モジュール、前記検査モジュール、前記分析モジュールの一連の動作を促すことにより、前記実行可能ファイルおよび対応する、前記テストデータを自律的に変更する請求項２０に記載のコンピュータプログラム。
  23. 前記更新モジュールはコンテキスト情報にしたがって前記実行可能ファイルを変更する、請求項２０に記載のコンピュータプログラム。
  24. 前記コンテキスト情報が経験則を含んでいる、請求項２３に記載のコンピュータプログラム。
  25. 前記生成モジュールはコンテキスト情報にしたがって前記実行可能ファイルを生成する、請求項１５に記載のコンピュータプログラム。
  26. 前記更新モジュールは、前記実行可能ファイルおよびテストデータを直接に変更するとともに、前記検査モジュールおよび前記分析モジュールの動作を促すことにより、前記実行可能ファイルおよび対応する前記テストデータを自律的に変更する、請求項２０に記載のコンピュータプログラム。
  27. 前記更新モジュールは、分析された前記プロセス実行情報と先の一組のプロセス表示とを比較するとともに、前記実行可能ファイルを変更して実行可能ファイル間の著しい差異を減少させることにより、前記実行可能ファイルおよび対応する前記テストデータを自律的に変更する、請求項２０に記載のコンピュータプログラム。
  28. 前記検証モジュール、前記生成モジュール、前記検査モジュール、前記分析モジュール、前記変更モジュールの一連の動作は、著しい差異が無いことが前記比較によって示されるまで自律的に続く、請求項２０に記載のコンピュータプログラム。
  29. 前記実行可能ファイルが第三世代言語でソースコードとして生成される、請求項１７に記載のコンピュータプログラム。
  30. 前記第三世代言語は、Ｃ、Ｃ＋＋、Ｃ＃、Ａｄａ、Ｊａｖａ、Ｄｅｌｐｈｉ、Ｖｉｓｕａｌ Ｂａｓｉｃ、ＦＯＲＴＲＡＮ ９０を含む一組のセットのうちの１つである、請求項２９に記載のコンピュータプログラム。
  31. 前記プロセス計算表記がＸＭＬに基づいている、請求項１７に記載のコンピュータプログラム。
  32. 前記プロセス計算表記がＲＩＦＭＬに基づいている、請求項３１に記載の方法。
  33. ビジネスロジックの一組のプロセス表示にしたがって分散処理環境内で実行するための実行可能ファイルを形成するコンピュータシステムであって、
    プロセス計算表記でプロセス表示を記憶するためのデータストアと、
    前記表示が有効であることを検証するための検証モジュールと、
    検証された表示にしたがって実行可能ファイルおよび対応するテストデータを生成する生成モジュールと、
    前記対応するテストデータを使用して前記実行可能ファイルを検査する検査モジュールと、
    を備える、コンピュータシステム。
  34. 前記検査モジュールは、検査された前記実行可能ファイルを前記分散処理環境内で展開させることができる、請求項３３に記載のコンピュータシステム。
  35. 展開された前記実行可能ファイルの性能を監視してプロセス実行情報を集めるための監視モジュールを更に備える、請求項１８に記載のコンピュータシステム。
  36. 前記監視モジュールによって集められた前記プロセス実行情報を分析するための分析モジュールと、分析された前記プロセス実行情報にしたがって前記実行可能ファイルおよび対応する前記テストデータを自律的に変更する更新モジュールとを更に備える、請求項１９に記載のコンピュータシステム。
  37. 実行可能ファイルおよび対応する前記テストデータの自律変更は、分析された前記プロセス実行情報にしたがった生成モジュールの動作の変更を含む、請求項２０に記載のコンピュータシステム。
  38. 前記更新モジュールは、前記プロセス表示を変更するとともに、前記検証モジュール、前記生成モジュール、前記検査モジュール、前記分析モジュールの一連の動作を促すことにより、前記実行可能ファイルおよび対応する前記テストデータを自律的に変更する、請求項３６に記載のコンピュータシステム。
  39. 前記更新モジュールはコンテキスト情報にしたがって前記実行可能ファイルを変更する、請求項３６に記載のコンピュータシステム。
  40. 前記コンテキスト情報が経験則を含んでいる、請求項３９に記載のコンピュータシステム。
  41. 前記生成モジュールはコンテキスト情報にしたがって前記実行可能ファイルを生成する、請求項３３に記載のコンピュータプログラム。
  42. 前記更新モジュールは、前記実行可能ファイルおよびテストデータを直接に変更するとともに、前記検査モジュールおよび前記分析モジュールの動作を促すことにより、前記実行可能ファイルおよび対応する前記テストデータを自律的に変更する、請求項３６に記載のコンピュータシステム。
  43. 前記更新モジュールは、分析された前記プロセス実行情報と先の一組のプロセス表示とを比較するとともに、前記実行可能ファイルを変更して実行可能ファイル間の著しい差異を減少させることにより、前記実行可能ファイルおよび対応する前記テストデータを自律的に変更する、請求項３６に記載のコンピュータシステム。
  44. 前記検証モジュール、前記生成モジュール、前記検査モジュール、前記分析モジュール、前記変更モジュールの一連の動作は、著しい差異が無いことが前記比較によって示されるまで自律的に続く、請求項４３に記載のコンピュータシステム。
  45. 前記実行可能ファイルが第三世代言語でソースコードとして生成される、請求項３３に記載のコンピュータシステム。
  46. 前記第三世代言語は、Ｃ、Ｃ＋＋、Ｃ＃、Ａｄａ、Ｊａｖａ、Ｄｅｌｐｈｉ、Ｖｉｓｕａｌ Ｂａｓｉｃ、ＦＯＲＴＲＡＮ ９０を含む一組のセットのうちの１つである、請求項４５に記載のコンピュータプログラム。
  47. 前記プロセス計算表記がＸＭＬに基づいている、請求項３３に記載のコンピュータプログラム。
  48. 前記プロセス計算表記がＲＩＦＭＬに基づいている、請求項４７に記載の方法。
  49. 分散処理環境内で実行するためのビジネスロジックのプロセス表示を検証して実施するための方法であって、
    プロセス計算表記でプロセス表示を行なうステップと、
    前記表示が有効であることを検証するステップと、
    検証された表示にしたがって実行可能ファイルおよび対応するテストデータを生成するステップと、
    前記対応するテストデータを使用して前記実行可能ファイルを検査するステップと、
    プロセス実行情報を分析するステップと、
    分析された前記プロセス実行情報にしたがって前記実行可能ファイルおよび対応する前記テストデータを自律的に変更するステップと、
    を含む方法。
  50. 分散処理環境内で実行するためのビジネスロジックのプロセス表示を検証して実施するためのコンピュータプログラムであって、
    プロセス計算表記でプロセス表示を行なう手段と、
    前記表示が有効であることを検証する手段と、
    検証された表示にしたがって実行可能ファイルおよび対応するテストデータを生成する手段と、
    前記対応するテストデータを使用して前記実行可能ファイルを検査する手段と、
    プロセス実行情報を分析する手段と、
    分析された前記プロセス実行情報にしたがって前記実行可能ファイルおよび対応する前記テストデータを自律的に変更する手段と、
    を含む、コンピュータプログラム。
  51. 分散処理環境内で実行するためのビジネスロジックのプロセス表示を検証して実施するためのコンピュータシステムであって、
    プロセス計算表記でプロセス表示を行なう手段と、
    前記表示が有効であることを検証する手段と、
    検証された表示にしたがって実行可能ファイルおよび対応するテストデータを生成する手段と、
    前記対応するテストデータを使用して前記実行可能ファイルを検査する手段と、
    プロセス実行情報を分析する手段と、
    分析された前記プロセス実行情報にしたがって前記実行可能ファイルおよび対応する前記テストデータを自律的に変更する手段と、
    を含むコンピュータシステム。
JP2004539251A 2002-09-25 2003-09-25 異質分散計算環境内での検証可能なプロセス Pending JP2006500670A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10/254,258 2002-09-25
US10/254,258 US20040060038A1 (en) 2002-09-25 2002-09-25 Verifiable processes in a heterogeneous distributed computing environment
PCT/GB2003/004205 WO2004029800A2 (en) 2002-09-25 2003-09-25 Verifiable processes in a heterogeneous distributed computing environment

Publications (1)

Publication Number Publication Date
JP2006500670A true JP2006500670A (ja) 2006-01-05

Family

ID=31993311

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004539251A Pending JP2006500670A (ja) 2002-09-25 2003-09-25 異質分散計算環境内での検証可能なプロセス

Country Status (8)

Country Link
US (2) US20040060038A1 (ja)
EP (1) EP1543412A2 (ja)
JP (1) JP2006500670A (ja)
CN (1) CN1688971A (ja)
AU (1) AU2003269216A1 (ja)
GB (1) GB2405977B (ja)
NO (1) NO20051241L (ja)
WO (1) WO2004029800A2 (ja)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7237231B2 (en) * 2003-03-10 2007-06-26 Microsoft Corporation Automatic identification of input values that expose output failures in a software object
US7278135B2 (en) * 2003-06-11 2007-10-02 Microsoft Corporation Method and system for generating an efficient test suite from a domain description with given constraints
US8386272B2 (en) * 2003-08-06 2013-02-26 International Business Machines Corporation Autonomic assistance for policy generation
US7861181B2 (en) * 2003-08-29 2010-12-28 International Business Machines Corporation Autonomic user interface widgets
GB2408355B (en) * 2003-11-18 2007-02-14 Ibm A system for verifying a state of an environment
US8799003B2 (en) * 2004-05-18 2014-08-05 International Business Machines Corporation Dynamic binding of principal services in a cross-enterprise business process management system
GB2416048A (en) * 2004-07-10 2006-01-11 Hewlett Packard Development Co Inferring data type in a multi stage process
US8819639B2 (en) * 2004-09-15 2014-08-26 Lakeside Software, Inc. System for selectively blocking execution of applications on a computer system
US7406626B2 (en) * 2004-11-12 2008-07-29 Empirix Inc. Test agent architecture
EP1677197A1 (en) * 2004-12-31 2006-07-05 ST Incard S.r.l. Test case automatic generation method for testing proactive GSM applications on SIM card
US20070046282A1 (en) * 2005-08-31 2007-03-01 Childress Rhonda L Method and apparatus for semi-automatic generation of test grid environments in grid computing
EP1934721A2 (en) * 2005-09-23 2008-06-25 Business Objects, S.A. Apparatus and method for data profile based construction of an extraction, transform, load (etl) task
US7707553B2 (en) * 2005-12-08 2010-04-27 International Business Machines Corporation Computer method and system for automatically creating tests for checking software
US9501463B2 (en) * 2005-12-08 2016-11-22 Microsoft Technology Licensing, Llc Spreadsheet cell-based notifications
US20070180433A1 (en) * 2006-01-27 2007-08-02 International Business Machines Corporation Method to enable accurate application packaging and deployment with optimized disk space usage
CN100571167C (zh) * 2006-02-24 2009-12-16 国际商业机器公司 Web服务业务流程的单元测试的方法和设备
US8726241B1 (en) * 2007-06-06 2014-05-13 Rockwell Collins, Inc. Method and system for the development of high-assurance computing elements
US8627299B2 (en) 2008-02-29 2014-01-07 International Business Machines Corporation Virtual machine and programming language for event processing
US8365149B2 (en) * 2008-02-29 2013-01-29 International Business Machines Corporation Debugger for a declarative event-driven programming model
US8397216B2 (en) * 2008-02-29 2013-03-12 International Business Machines Corporation Compiler for a declarative event-driven programming model
US20110010217A1 (en) * 2009-07-13 2011-01-13 International Business Machines Corporation Service Oriented Architecture Governance Using A Template
US8386282B2 (en) * 2009-07-22 2013-02-26 International Business Machines Corporation Managing events in a configuration of SOA governance components
US8839214B2 (en) * 2010-06-30 2014-09-16 Microsoft Corporation Indexable type transformations
US9043761B2 (en) * 2010-09-01 2015-05-26 International Business Machines Corporation Fault localization using condition modeling and return value modeling
US8893077B1 (en) * 2011-10-12 2014-11-18 Google Inc. Service to generate API libraries from a description
JP5857806B2 (ja) * 2012-03-08 2016-02-10 日本電気株式会社 分散処理システムのテスト方法および分散処理システム
US9389986B2 (en) * 2013-05-06 2016-07-12 Microsoft Technology Licensing, Llc Identifying impacted tests from statically collected data
CN105426231A (zh) * 2014-09-04 2016-03-23 腾讯科技（深圳）有限公司 多进程处理装置和多进程处理方法
CN108509335B (zh) * 2018-01-31 2021-03-19 浙江理工大学 基于遗传算法优化的软件测试数据生成方法
CN111610976B (zh) * 2020-04-08 2023-04-07 中科曙光(南京)计算技术有限公司 异构应用移植方法、装置和计算机设备

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19535084A1 (de) * 1995-09-21 1997-03-27 Ibm Verfahren und Vorrichtung zur dynamischen Optimierung von durch ein Computersystem gemanagten Geschäftsprozessen
US6385765B1 (en) * 1996-07-02 2002-05-07 The Research Foundation Specification and verification for concurrent systems with graphical and textual editors
US6516322B1 (en) * 2000-04-28 2003-02-04 Microsoft Corporation XML-based representation of mobile process calculi
US6968343B2 (en) * 2000-09-01 2005-11-22 Borland Software Corporation Methods and systems for integrating process modeling and project planning
US6868413B1 (en) * 2001-05-10 2005-03-15 Networks Associates Technology, Inc. System and method for customizing and processing business logic rules in a business process system
AU2003259744A1 (en) * 2002-08-09 2004-02-25 Corticon Technologies, Inc. Rule engine

Also Published As

Publication number Publication date
CN1688971A (zh) 2005-10-26
GB2405977B (en) 2005-11-09
US20040060038A1 (en) 2004-03-25
EP1543412A2 (en) 2005-06-22
GB0428115D0 (en) 2005-01-26
WO2004029800A2 (en) 2004-04-08
WO2004029800A3 (en) 2004-08-12
NO20051241D0 (no) 2005-03-10
AU2003269216A1 (en) 2004-04-19
NO20051241L (no) 2005-06-27
GB2405977A (en) 2005-03-16
US20040064806A1 (en) 2004-04-01

Similar Documents

Publication Publication Date Title
JP2006500670A (ja) 異質分散計算環境内での検証可能なプロセス
Woodside et al. The future of software performance engineering
Ter Beek et al. Formal methods for service composition
US7287247B2 (en) Instrumenting a software application that includes distributed object technology
Bozkurt et al. Testing web services: A survey
Bruno et al. Using test cases as contract to ensure service compliance across releases
Lahami et al. Runtime testing approach of structural adaptations for dynamic and distributed systems
Ivanovic et al. Towards data-aware qos-driven adaptation for service orchestrations
Dehraj et al. An empirical assessment of autonomicity for autonomic query optimizers using fuzzy-AHP technique
Aksakalli et al. Systematic approach for generation of feasible deployment alternatives for microservices
Inverardi et al. The future of software: Adaptation and dependability
Petriu Integrating the analysis of multiple non-functional properties in model-driven engineering
Hummer et al. Test coverage of data-centric dynamic compositions in service-based systems
Krichen et al. A resource-aware model-based framework for load testing of ws-bpel compositions
Wirsing et al. Sensoria patterns: Augmenting service engineering with formal analysis, transformation and dynamicity
Ji et al. Test case selection for all-uses criterion-based regression testing of composite service
Vysocký et al. Application instrumentation for performance analysis and tuning with focus on energy efficiency
Magott et al. Combining generalized stochastic Petri nets and PERT networks for the performance evaluation of concurrent processes
Zatout et al. A model-driven approach for the verification of an adaptive service composition
Di Marco et al. A model-driven approach to broaden the detection of software performance antipatterns at runtime
Ivanović et al. An initial proposal for data-aware resource analysis of orchestrations with applications to predictive monitoring
Caporuscio et al. Building design‐time and run‐time knowledge for QoS‐based component assembly
Dorfmeister et al. Integrating heuristiclab with compilers and interpreters for non-functional code optimization
Hummer et al. SEPL—a domain-specific language and execution environment for protocols of stateful Web services
Brandauer et al. MINER-A measurement infrastructure for network research

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20081007

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090303