JP6369170B2 - 実行時間推定装置及び方法 - Google Patents

Description

本発明は、複数のワークフローを実行する場合における実行時間の推定技術に関する。

データセンタには、多数のＩＴ（Information Technology）機器（サーバ、ストレージ、ネットワークなど）が設置されており、それらはハードウエアだけではなくＯＳ（Operating System）、ミドルウエア及びアプリケーションプログラムの組み合わせにて所望の処理を行うようになっている。また、データセンタでは、複数のＩＴ機器を組み合わせた複数の業務システムが稼働しており、多数のＩＴ機器及び業務システムに対して監視や保守作業が行われている。

このようなデータセンタにおける運用作業を自動化するための技術が存在しており、ある技術においては、業務システムに対する作業手順を記述したワークフローを設計して自動実行をすることで、業務の効率化を図っている。図１に示すように、スタート（Ｓｔａｒｔ）から、エンド（Ｅｎｄ）までに、行うべき作業に対応し且つ予め用意された部品を並べて、実行させるようになっている。

しかし、運用プロセス（ワークフローにパラメタなどの情報を与えて起動することで生成されたインスタンスのことを運用プロセスと呼ぶ）の同時実行や、複雑なワークフローでの分岐などにより、運用プロセスの実行がスケジュール通りに終了できず、後続業務（たとえば、オンライン業務開始）に影響を与えることがある。具体的には、後続業務の開始遅延が発生する。

このように運用プロセスをスケジュール通り実行しないと後続業務に影響を与えるため、運用プロセスの終了時刻を事前に正しく導出することが求められている。

例えば、人の作業をワークフロー化して、実行中の運用プロセスが目標時刻までに終了するかを予測する技術が存在している。このような予測では、作業時間の推測値を定義した情報や過去実施した同一の作業の遂行実績時間の情報を用いて、終了時刻を単純計算で求めるだけである。遂行実績時間については、その計測に時間や手間が掛かるだけではなく、あくまで過去の実績に過ぎず、環境が変わったりすれば異なる結果が得られるようになるため、正確性に欠けるという問題もある。

また、従来の技術では、運用プロセスの重要な特性が考慮されていない。すなわち、運用モジュール（ワークフローに含まれる部品を実際に動作させたときに、実行時間が推定される対象を運用モジュールと呼ぶ）の実行時間は、実行されるサーバの状況により変動するが、最小値及び最大値は求めることは可能である。よって、運用プロセスが１つしかない場合には、運用モジュールの実行時間の最小値及び最大値から、運用プロセスの実行時間の最小値及び最大値を算出することはできる。

しかしながら、複数の運用プロセスを実行する場合には、複数の運用プロセスの間で、排他条件が存在する場合がある。このような場合、排他待ち時間は、排他がいつ解消するかにより定まるが、排他条件が多重的に設定されていると複数の排他条件が相互に影響を及ぼして排他の解消がいつ発生するかは、排他を直接発生させた他の運用プロセスだけでは分からない。すなわち、排他待ち時間は、容易に推定できない。

また、排他の発生は、複数の運用プロセスの実行タイミングにも依存するが、そのような問題についても従来の技術では対処できていない。

特開平８−１９０５８４号公報 特開２００８−８４０８３号公報 特開２００９−１６９７８７号公報 特表２００３−５２６１５８号公報

従って、本発明の目的は、一側面によれば、複数のワークフローを実行する際において排他条件が定義されている場合にも正確に実行時間を推定するための技術を提供することである。

本発明の実行時間推定装置は、１又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定装置である。そして、この実行時間推定装置は、（Ａ）複数のプロセスについて排他実行に関する条件と、複数のプロセスに係る各モジュールの実行時間の範囲に関するデータとを格納する格納部と、（Ｂ）（ｂ１）複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で格納部に格納された各モジュールの実行時間の範囲に応じた１又は複数のケースを生成する処理と、（ｂ２）格納部に格納された上記条件に基づく複数のプロセスに係る複数のケース間における排他待ちの発生の有無を判定する第１の判定処理と、（ｂ３）排他待ちの発生があると判定された場合には当該排他待ちが発生したプロセスのケースに排他待ちを設定する処理とを含むケース処理を仮想的に時間進展させつつ実行することで、複数のプロセスを実行する場合における実行時間を推定する推定部とを有する。この場合、上記第１の判定処理は、排他待ちが発生する可能性の有無を判定する第２の判定処理と、第２の判定処理の処理結果に基づき、排他待ちの発生の有無を判定する処理とを含む。そして、上記第１の判定処理において、第２の判定処理において排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるケースに対して再帰的に第２の判定処理を実行する。

一側面によれば、複数のワークフローを実行する際において排他条件が定義されている場合にも正確に実行時間を推定できるようになる。

図１は、ワークフローの一例を示す図である。 図２は、本発明の実施の形態に係る情報処理装置の機能ブロック図である。 図３は、実行制御部のメインの処理フローを示す図である。 図４は、処理結果の出力例を示す図である。 図５は、見積もり処理の処理フローを示す図である。 図６は、開始管理テーブルの一例を示す図である。 図７は、運用プロセス状態管理部のメインの処理フローを示す図である。 図８は、更新処理の処理フローを示す図である。 図９は、ワークフローの第１の例を示す図である。 図１０は、ワークフローの第１の例についての排他管理テーブルを示す図である。 図１１は、ワークフローの第１の例についての実行時間管理テーブルを示す図である。 図１２は、ワークフローの第１の例についてｔ＝０におけるインスタンス管理テーブルの状態を示す図である。 図１３は、ワークフローの第１の例についてｔ＝１におけるインスタンス管理テーブルの状態を示す図である。 図１４は、インスタンス管理テーブルの状態を模式的に示す図である。 図１５は、ワークフローの第１の例についてｔ＝２におけるインスタンス管理テーブルの状態を示す図である。 図１６は、インスタンス管理テーブルの状態を模式的に示す図である。 図１７は、インスタンス管理テーブルの状態を模式的に示す図である。 図１８は、インスタンス管理テーブルの状態を模式的に示す図である。 図１９は、状態確定処理の処理フローを示す図である。 図２０は、待ち状態確認処理の処理フローを示す図である。 図２１は、ワークフローの第２の例を示す図である。 図２２は、ワークフローの第２の例についての排他管理テーブルを示す図である。 図２３は、ワークフローの第２の例についての実行時間管理テーブルを示す図である。 図２４は、ワークフローの第２の例についてｔ＝０におけるインスタンス管理テーブルの状態を示す図である。 図２５は、ワークフローの第２の例についてｔ＝１におけるインスタンス管理テーブルの状態を示す図である。 図２６は、インスタンス管理テーブルの状態を模式的に示す図である。 図２７は、ワークフローの第２の例についてｔ＝２におけるインスタンス管理テーブルの状態を示す図である。 図２８は、インスタンス管理テーブルの状態を模式的に示す図である。 図２９は、ワークフローの第３の例を示す図である。 図３０は、ワークフローの第３の例についての排他管理テーブルを示す図である。 図３１は、ワークフローの第３の例についての実行時間管理テーブルを示す図である。 図３２は、ワークフローの第２の例についての開始時間管理テーブルを示す図である。 図３３は、ワークフローの第３の例についてｔ＝０におけるインスタンス管理テーブルの状態を示す図である。 図３４は、ワークフローの第３の例についてｔ＝１におけるインスタンス管理テーブルの状態を示す図である。 図３５は、インスタンス管理テーブルの状態を模式的に示す図である。 図３６は、ワークフローの第３の例についてｔ＝２におけるインスタンス管理テーブルの状態を示す図である。 図３７は、インスタンス管理テーブルの状態を模式的に示す図である。 図３８は、ワークフローの第３の例についてｔ＝３におけるインスタンス管理テーブルの状態を示す図である。 図３９は、インスタンス管理テーブルの状態を模式的に示す図である。 図４０は、ワークフローの第３の例についてｔ＝４におけるインスタンス管理テーブルの状態を示す図である。 図４１は、インスタンス管理テーブルの状態を模式的に示す図である。 図４２は、ワークフローの第４の例を示す図である。 図４３は、ワークフローの第４の例の実行を模式的に示す図である。 図４４は、コンピュータの機能ブロック図である。

図２に、実行時間推定装置として動作し、本実施の形態に係る情報処理装置１００の構成例を示す。本実施の形態に係る情報処理装置１００は、実行制御部１１０と、データベース１２０と、同時に実行される運用プロセス毎に起動される運用プロセス状態管理部１３０（図２では運用プロセス状態管理部１３０Ａ乃至１３０Ｃ）とを有する。また、情報処理装置１００は、表示装置や印刷装置、ネットワークに接続された他のコンピュータである出力装置２００と接続されている。

実行制御部１１０は、データベース１２０に格納されているデータに基づき、運用プロセス状態管理部１３０Ａ乃至１３０Ｃの起動や処理などを制御し、処理結果を出力装置２００に出力する。

運用プロセス状態管理部１３０Ａ乃至１３０Ｃは、担当するワークフローの運用プロセスの状態を、実行制御部１１０からの指示に基づき時間を進展させつつ、データベース１２０に格納されているデータに基づき遷移させる等して管理する。

データベース１２０は、ワークフローに含まれる部品毎に実行時間のデータ（実行時間管理テーブル）を格納している。また、データベース１２０は、ワークフロー間の排他条件についてのデータ（例えば排他管理テーブル）をも格納している。さらに、データベース１２０は、ワークフローの運用プロセスの実行タイミングについてのデータ（例えば開始管理テーブル）をも格納している。さらに、データベース１２０は、運用プロセスの状態を管理するためのデータ（例えばインスタンス管理テーブル）をも格納している。

本実施の形態では、複数の運用プロセスを並行して動作させた場合に、運用モジュールの実行時間の予想範囲（最短時間から最長時間）に、排他待ちが発生するケースと発生しないケースがないかを、両方とも確認して、それぞれについて実行時間を導出する。また、運用プロセスに分岐がある場合は、終了時刻は１つに定まらないため、網羅的に実行パターンを求めることで解決する。さらに、人の作業は、すぐに実施される場合と、終了期限ぎりぎりまで何もされない場合等が存在する。従って、人の作業についても、終了時間を最短時間から最長時間までの範囲として設定する。

このように、本実施の形態では、複数の運用プロセスを同時に動作させた場合を、生じ得る実行パターンのそれぞれについてシミュレーションを行う。このシミュレーションにおいては、生じ得る実行パターンのそれぞれについて運用プロセスのインスタンスを生成させて、そのインスタンスの状態の変化を、時間の進展に伴い確認してゆく。

上でも述べたように、複数の運用プロセスは、排他条件に基づき、互いに関連しながら動作する。排他待ちは、運用プロセスＡが、運用プロセスＢの終了を待ち、運用プロセスＢは、運用プロセスＣの終了を待つといったように、多重に発生する可能性があるので、排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性のある運用プロセスに対して、さらに排他待ちが発生する可能性があるか否かを再帰的に判定するようにする。

これによって、排他待ちの解消を適切に検出することができるので、結果として待ち時間が正しく想定されるようになって、正しく実行時間を見積もることができるようになる。

このように生じ得る実行パターンのそれぞれについてシミュレーションを実行するので、各運用モジュール等の実行時間の予測範囲が設定されれば、実行実績が無いような運用プロセスの組み合わせについても、実行時間を推定することができるようになる。

次に、図３乃至図４３を用いて、情報処理装置１００の動作内容について説明する。

まず、実行制御部１１０の動作について、図３を用いて説明する。

実行制御部１１０は、ユーザから予測依頼を受け付ける（図３：ステップＳ１）。予測依頼には、並行して実行されるワークフローの指定が含まれる。

また、実行制御部１１０は、予測依頼に含まれるワークフローに応じて、運用プロセス状態管理部１３０を起動させる（ステップＳ３）。例えば３つのワークフローを並行して実行する場合には、それぞれに対して１つの運用プロセス状態管理部１３０を起動させる。

そして、実行制御部１１０等は、見積もり処理を実行する（ステップＳ５）。見積もり処理については、以下に詳細に説明する。

そして、見積もり処理の結果として、実行制御部１１０は、データベース１２０に格納されているデータから、見積もり結果を、出力装置２００に対して出力する（ステップＳ７）。

本実施の形態では、インスタンス管理テーブルに、各運用プロセスについての最短実行時間に相当するデータと最長実行時間に相当するデータとが登録されるようになる。開始時刻が設定されれば、最短終了時刻最長終了時刻も算出される。

例えば、ワークフローＡとワークフローＢとを同時に実行させた場合の見積もり結果の例を図４に示す。図４の例では、ワークフローＡを９：００に開始し、ワークフローＢを９：１０に開始する。そうした場合、ワークフローＡについては、最短実行時間が０：２７で最短終了時刻は９：２７、最長実行時間が０：３０で最長終了時刻は９：３０となる。一方、ワークフローＢについては、最短実行時間が０：２１で最短終了時刻は９：３１、最長実行時間０：４０で最長終了時刻が９：５０となる。このような結果を示せば、ワークフローＡ及びＢを同時実行した場合には、遅くても９：５０に実行が終了することが分かる。

次に、見積もり処理について図５を用いて説明する。

まず、実行制御部１１０は、時刻ｔを０に設定する（図５：ステップＳ１１）。

そして、実行制御部１１０は、起動させた運用プロセス状態管理部１３０から運用プロセスの全てのインスタンスが完了したという通知を受けたか否かで処理を終了させるか否かを判断する（ステップＳ１３）。

処理を終了させない場合には、実行制御部１１０は、ｔ単位時間後の状態を取得するように、運用プロセス状態管理部１３０に対して予測指示を行う（ステップＳ１５）。ここで、実行制御部１１０は、データベース１２０に格納されている開始管理テーブルを参照して、開始時刻以降となったワークフローについての運用プロセス状態管理部１３０に予測指示を出力する。また、全てのインスタンスが完了したとの通知を受けた運用プロセス状態管理部１３０については、指示を行わない。

開始管理テーブルは、例えば図６に示すようなデータである。図６の例では、ワークフローＡについては、９：００に実行を開始し、ワークフローＢについては、９：１０に実行を開始する。このようなデータの場合には、ワークフローＢをワークフローＡの実行開始から１０分たつまではステップＳ１５の予測指示を行わない。

そして、実行制御部１１０は、ｔを１インクリメントし（ステップＳ１７）、処理はステップＳ１３に戻る。このような処理を実行すれば、各時刻における運用プロセスの状態を運用プロセス状態管理部１３０の各々に記録させることができるようになる。終了させる場合には、実行制御部１１０は、各運用プロセス状態管理部１３０に終了指示を出力する（ステップＳ１９）。

次に、図７乃至図４３を用いて、運用プロセス状態管理部１３０の処理内容について説明する。

まず、運用プロセス状態管理部１３０は、実行制御部１１０から指示を受け取ったか否かを判断する（図７：ステップＳ２１）。指示を受け取っていない場合には、処理はステップＳ２１に戻って指示の受信を待つ。

一方、指示を受信した場合には、運用プロセス状態管理部１３０は、終了指示であるか否かを判断する（ステップＳ２３）。何らかの理由で実行制御部１１０が、見積もり処理を途中で終了させる場合には、終了指示がなされる場合がある。終了指示がなされた場合には、処理は終了する。

一方、終了指示ではない場合には、指示は予測指示となるので、運用プロセス状態管理部１３０は、ｔ単位時間後の状態を登録するように、インスタンス管理テーブルの更新処理を実行する（ステップＳ２５）。この更新処理が完了すると、運用プロセス状態管理部１３０は、担当する運用プロセスについてのインスタンスが全て完了となったか否かを判断する（ステップＳ２７）。少なくとも１つのインスタンスについて動作中又は待機中であれば、処理はステップＳ２１に戻る。

一方、全てのインスタンスが完了となった場合には、運用プロセス状態管理部１３０は、完了を実行制御部１１０に通知する（ステップＳ２９）。そして、処理は終了する。

このような処理によって、インスタンス管理テーブルを単位時間毎に更新できるようになる。

次に、更新処理について、図８乃至図４３を用いて説明する。まず、運用プロセス状態管理部１３０は、インスタンス管理テーブルにおいてｔ＝ｔ−１で未完了のインスタンスのうち、未処理のインスタンスを１つ特定する（図８：ステップＳ３０）。

次に、運用プロセス状態管理部１３０は、指定時刻（ｔ単位時間後の時刻）において、特定されたインスタンスが未完了の場合が存在するか否かを判断する（ステップＳ３１）。

運用モジュールの実行時間が、例えば１単位時間又は２単位時間というように設定されていれば、ｔ−１単位時間後にその運用モジュールの実行時間（以下、経過時間と呼ぶ）が１単位時間であるとすると、その運用モジュールの動作が完了する場合と、もう１単位時間だけ動作する場合とに分かれる。このような場合には、指定時刻において未完了の場合が存在すると判断される。

ステップＳ３１の条件を満たす場合には、運用プロセス状態管理部１３０は、特定されたインスタンスについて、運用モジュールが未完了であることを表すレコードを、データベース１２０におけるインスタンス管理テーブルに登録する（ステップＳ３３）。

一方、ステップＳ３１の条件が満たされない場合には、処理はステップＳ３５に移行する。

さらに、運用プロセス状態管理部１３０は、指定時刻について状態確定処理を実行する（ステップＳ３５）。状態確定処理は、排他待ちの状態を確認するための処理であるので、後に詳しく述べる。

その後、運用プロセス状態管理部１３０は、ステップＳ３５の処理結果に基づき、特定されたインスタンスについて、指定時刻に、排他待ちが発生するか否かを判断する（ステップＳ３７）。

排他待ちが発生したと判断された場合には、運用プロセス状態管理部１３０は、特定されたインスタンスについて、排他待ちが発生したことを表すレコードを、データベース１２０におけるインスタンス管理テーブルに登録する（ステップＳ３９）。

一方、排他待ちが発生しないと判断された場合には、処理はステップＳ４１に移行する。

さらに、運用プロセス状態管理部１３０は、指定時刻に、特定されたインスタンスについて、次の運用モジュールに遷移する場合があるか否かを判断する（ステップＳ４１）。具体的には、ｔ＝ｔ−１においてある運用モジュールの動作が完了する場合が存在するか否かを判断する。なお、次の運用モジュールは、終了（ＥＮＤ）をも含む。

ステップＳ４１の条件を満たす場合には、運用プロセス状態管理部１３０は、特定されたインスタンスについて、現在の運用モジュール（又はスタート）から次の運用モジュールに遷移することを表すレコードを、データベース１２０におけるインスタンス管理テーブルに登録する（ステップＳ４３）。そして処理はステップＳ４５に移行する。一方、ステップＳ４１の条件を満たさない場合にも処理はステップＳ４５に移行する。そして、運用プロセス状態管理部１３０は、インスタンス管理テーブルにおいてｔ＝ｔ−１において、未処理の未完了インスタンスが存在しているか否かを判断する（ステップＳ４５）。未処理の未完了インスタンスが存在する場合には、処理はステップＳ３０に戻る。一方、未処理の未完了インスタンスが存在しない場合には、処理は呼び出し元の処理に戻る。

ここで、処理内容を分かりやすくするため、簡単な例を説明してゆくものとする。具体的には、１つのワークフローを実行する場合を例に説明する。図９に示すようなワークフローを想定する。すなわち、開始後に部品１を実行するが、その後、人による作業３と、部品２とを並行して実行して、それぞれその後終了するものである。なお、部品１にはServiceAについての排他が設定されており、部品１及び２についてHostAについての排他も設定されている。

このような場合、データベース１２０には、図１０に示すような排他管理テーブルが格納される。図１０の例では、ワークフロー番号と、排他資源名（HostAやServiceAなど）と、排他開始番号（すなわち部品番号）及び排他終了番号（すなわち部品番号）とが登録されるようになっている。

また、データベース１２０には、図１１に示すような実行時間管理テーブルが格納される。図１１の例では、各部品番号について、最短時間と最長時間とが登録されるようになっている。この例では、どの部品も、１秒（説明を簡単にするため具体例においては１秒が１単位時間とする）乃至２秒の実行時間ということになる。なお、人による作業の場合には、別途実行時刻を定義するようにしても良い。すなわち、終了タイミングが他の部品の実行後というような設定を別途行うようにしても良い。

なお、データベース１２０には、開始管理テーブルを格納しているが、この例ではワークフローが１つだけなので、ここでは用いられないため説明を省略する。

まず、ｔ＝０の場合、インスタンス管理テーブルは、図１２のような状態となる。図１２に示すように、インスタンス管理テーブルには、レコードの識別番号と、総時間と、ワークフロー番号と、実行中の部品番号と、当該部品についての経過時間と、１秒後のレコード番号と、１秒前のレコード番号と、排他待ちを生じさせているレコード番号である待ち番号と、状態確定処理において特定された待ち状態とが登録されるようになっている。ｔ＝０では、ステップＳ４３において、ワークフロー１の部品１の処理が開始していない状態が、登録される。すなわち、１つのインスタンスのみが存在する。

ｔ＝１となると、インスタンス管理テーブルは、図１３に示すような状態となる。レコード番号「２」についてのレコードは、部品１の処理が未完了の場合のインスタンスを表しており、ステップＳ３３で生成され、経過時間が「１」となる。さらに、部品１の処理が１秒で完了したとすると、部品２に遷移する場合と、部品３に遷移する場合とが生ずる。従って、ステップＳ４３において、レコード番号「３」のレコード及びレコード番号「４」のレコードが生成される。

なお、これらのレコードにおいては、１秒前のレコード番号が「１」と設定され、レコード番号「１」のレコードにおいては、１秒後のレコード番号が「２，３，４」と設定される。以下では説明を省略するが、１秒前のレコード番号と１秒後のレコード番号とを登録することで、状態遷移を双方向で辿ることができるようになる。

このようなインスタンス管理テーブルの状態を模式的に示せば、図１４のようになる。なお、レコード「１」のインスタンスが、３つのインスタンスに分岐したことになる。

ｔ＝２となると、インスタンス管理テーブルは、図１５に示すような状態となる。レコード番号「２」のレコードで表されるインスタンスについては、部品１の処理が完了することになるので、ステップＳ４３で次の運用モジュールに遷移することを表すレコードが登録される。この場合、ワークフロー１の構造から、部品２に遷移する場合と部品３に遷移する場合とがあることが分かるので、レコード番号「５」及び「６」のレコードが生成される。遷移したばかりなので、経過時間は「０」となる。

これらのレコードで表される状態を模式的に示せば、図１６に示すようになる。このように、部品１が２秒かかった後に、部品２に遷移したケース（レコード「５」）と、部品３に遷移したケース（レコード「６」）とが発生する。

また、レコード番号「３」のレコードで表されるインスタンスについては、部品２の処理が１秒で完了して終了する場合と、部品２の処理が継続する場合とが発生する。前者の場合には、ステップＳ４３でレコード番号「７」のレコードが生成され、後者の場合には、ステップＳ３３でレコード番号「８」のレコードが生成されることになる。

これらのレコードで表される状態を模式的に示せば、図１７に示すようになる。このように、部品２の処理が１秒で完了して終了するケース（レコード「７」）と、部品２の処理がもう１秒継続するケース（レコード「８」）とが発生する。

さらに、レコード番号「４」のレコードで表されるインスタンスについては、部品３の処理が１秒で完了して終了する場合と、部品３の処理が継続する場合とが発生する。前者の場合には、ステップＳ４３でレコード番号「９」のレコードが生成され、後者の場合には、ステップＳ３３でレコード番号「１０」のレコードが生成されることになる。

これらのレコードで表される状態を模式的に示せば、図１８に示すようになる。このように、部品３の処理が１秒で完了して終了するケース（レコード「９」）と、部品３の処理がもう１秒継続するケース（レコード「１０」）とが発生する。

このようにｔ＝２では６つのインスタンスに分岐したことになる。これ以降の時刻に関する説明については、同様であるから省略する。

次に、排他待ちが発生する場合について図１９乃至図４３を用いて説明する。ここでステップＳ３５の処理内容について、図１９及び図２０を用いて説明する。

運用プロセス状態管理部１３０は、処理対象のインスタンスの状態を特定する（図１９：ステップＳ５１）。

具体的には、インスタンス管理テーブルにおいて、ｔ＝ｔ−１におけるインスタンスのレコードの待ち番号及び待ち状態のデータを読み出す。初期的には何も登録されていないので、開始管理テーブル及び排他管理テーブルから、排他条件を特定して、排他条件から排他待ちが発生するか否かを判断する。なお、新たな排他待ちが発生する場合もあるので、排他管理テーブルから排他条件を特定して、ｔ＝ｔ−１で生存している他のインスタンスと新たな排他が発生していないかを確認する処理をも行う。

次に、運用プロセス状態管理部１３０は、待ち状態確認処理を実行する（ステップＳ５３）。待ち状態確認処理については、後に詳細に説明する。

そして、運用プロセス状態管理部１３０は、検出された待ち状態から、処理対象のインスタンスについて待ち状態を確定させる（ステップＳ５５）。具体的には、指定時刻（ｔ単位時間後の時刻）において、待ちが解消した場合と、待ちが発生している場合とを特定する。待ちが解消した場合には、待ちが解消することで、実行が開始するので次の運用モジュールに遷移することになる。待ちが発生している場合には、どのようなインスタンスによって待ちが生じさせられているのかを特定する。

次に、待ち状態確認処理について、図２０を用いて説明する。

運用プロセス状態管理部１３０は、処理対象のインスタンスが待ちになる可能性があるか否かを確認する（ステップＳ６１）。インスタンス管理テーブルにおいて、着目しているレコードに待ち番号が登録されているか否かを判断する。

待ちになる可能性がなければ（ステップＳ６３：Ｎｏルート）、呼び出し元の処理に戻る。

一方、待ちになる可能性があれば（ステップＳ６３：Ｙｅｓルート）、運用プロセス状態管理部１３０は、排他を先にとっている運用プロセスのインスタンスに関する時刻ｔのレコードを特定する（ステップＳ６５）。そして、運用プロセス状態管理部１３０は、排他を先にとった運用プロセスのインスタンスについて、待ち状態確認処理を再帰的に実行する（ステップＳ６７）。そして呼び出し元の処理に戻る。

このようにすることで、排他の可能性なしと判定されるまで、排他関係を確認する。

例えば、図２１に示すような具体例を考察する。図２１の例では、ワークフロー１乃至３を並行して実行する場合を想定しており、ワークフロー１には部品１が含まれ、ワークフロー２には部品２が含まれ、ワークフロー３には部品３が含まれる。排他条件としては、部品１乃至３は、それぞれHostBへの排他が設定されている。従って、排他管理テーブルは、図２２に示すような状態となる。すなわち、各ワークフローの部品には、排他資源名としてHostBが設定されている。

また、図２３に示すような実行時間管理テーブルがデータベース１２０に格納されているものとする。図２３の例では、どの部品も実行時間は１秒と簡素化されている。

なお、この例でも開始時刻は同じになっているものとして、開始時刻テーブルについては説明を省略する。

図２２に示すような排他管理テーブルの場合には、ワークフロー１に着目すれば、排他条件がワークフロー２及び３と重複しており、ワークフロー２とワークフロー３とで待ち合せが発生する可能性がある。

ｔ＝０では、図２４に示すようなインスタンス管理テーブルの状態となる。どのワークフローについても、ステップＳ４３で、最初の部品の処理に遷移した状態となる。なお、初期的には状態確定処理においては、待ちが特定されないものとする。

ｔ＝１では、図２５に示すようなインスタンス管理テーブルの状態となる。

レコード番号「１」のレコードで表されるインスタンスについては、部品１の実行時間は１秒なので、実行していれば未完了となることはないので、ステップＳ３３でレコードは登録されない。状態確定処理においては、ステップＳ５１で、排他管理テーブルから、他のワークフローについて設定されている排他条件から、排他待ちが発生するか否かを判断する。図２２に示す排他管理テーブルの場合、ワークフロー１が最初に実行されれば待ちは発生しない。一方、ワークフロー２の部品２及びワークフロー３の部品３と排他の関係にあることが把握される。従って、ワークフロー２の排他待ちと、ワークフロー３の排他待ちとが生ずる。但し、ワークフロー２の排他待ちの場合には、ワークフロー２自体がワークフロー３を排他待ちの場合もある。同様に、ワークフロー３の排他待ちの場合には、ワークフロー３自体がワークフロー２を排他待ちの場合もある。このような状態を特定する。なお、ｔ＝０のレコード番号「１」のレコードには待ち番号が登録されていないので、待ちの可能性はないと判断される。

従って、ステップＳ３９では、ワークフロー２を待つ場合のインスタンスのレコード（レコード番号「５」）と、ワークフロー３を待つ場合のインスタンスのレコード（レコード番号「６」）とを生成する。上で述べたように、ワークフロー２を待つ場合であっても、ワークフロー２のみを待つ場合とワークフロー２がワークフロー３を待つ場合もあるので、その状態を待ち状態の列に登録する。「２−＞３」はワークフロー２がワークフロー３を待つ状態を表している。同様に、ワークフロー３を待つ場合であっても、ワークフロー３のみを待つ場合とワークフロー３がワークフロー２を待つ場合もあるので、その状態を待ち状態の列に登録する。

また、ステップＳ４３では、ワークフロー１の部品１が最初に実行して処理が終了するインスタンスについてのレコード（レコード番号「４」）を、インスタンス管理テーブルに登録する。

ｔ＝１におけるワークフロー１についてのインスタンスの状態を模式的に示せば図２６のようになる。

この具体例においては、ワークフロー２についてのレコード「２」及びワークフロー３についてのレコード「３」についても、同様の判断が行われる。

ワークフロー２については、レコード「８」及び「９」が、ステップＳ３９で生成され、レコード「７」がステップＳ４３で生成される。レコード「８」は、ワークフロー１を待つインスタンスを示すが、ワークフロー１のみを待つ状態とワークフロー１がワークフロー３を待つ状態とを含む。同様に、レコード「９」は、ワークフロー３を待つインスタンスを示すが、ワークフロー３のみを待つ状態とワークフロー３がワークフロー１を待つ状態とを含む。

さらに、ワークフロー３については、レコード「１１」及び「１２」が、ステップＳ３９で生成され、レコード「１０」がステップＳ４３で生成される。レコード「１１」は、ワークフロー１を待つインスタンスを示すが、ワークフロー１のみを待つ状態とワークフロー１がワークフロー２を待つ状態とを含む。同様に、レコード「１２」は、ワークフロー２を待つインスタンスを示すが、ワークフロー２のみを待つ状態とワークフロー２がワークフロー１を待つ状態とを含む。

次に、ｔ＝２では、図２７に示すようなインスタンス管理テーブルの状態となる。ｔ＝２では、レコード「５」「６」「８」「９」「１１」「１２」が処理対象となる。

レコード「５」のインスタンスに着目すると、まだ実行を開始していないので、ステップＳ３３で未完了であることを表すレコードは登録されない。

一方、待ち状態の列に、１秒前の状態が登録されているので、ステップＳ５１でこの状態を特定する。ステップＳ６１では、待ち番号の列にレコード「２」が登録されているので、ステップＳ６３で排他待ちの可能性があると判断される。そうすると、レコード「２」における１秒後番号の列に「７，８，９」が登録されているので、ステップＳ６５でこれらのレコードを特定する。ステップＳ６７においては、特定された３レコードの各々について、再帰的に待ち状態確認処理を実行する。

レコード「７」に着目すると、終了しているので待ちの可能性はない、すなわち待ちが解消している。レコード「８」に着目すると、待ち番号の列に「１」が登録されていることが分かる。しかしながら、現在の処理対象レコードがワークフロー１についてのレコードなので、レコード「８」については考慮せず、排他待ちの可能性無しと判断される。レコード「９」に着目すると、待ち番号の列に「３」が登録されていることが分かる。ここで、ステップＳ６３で排他待ちの可能性が検出される。

そうすると、ステップＳ６５で、レコード「３」を参照して、１秒後番号の列に登録されているレコード「１０」「１１」「１２」を特定する。そして、これらのレコードの各々について、ステップＳ６７において、再帰的に待ち状態確認処理を実行する。

レコード「１０」に着目すると、終了しているので待ちの可能性はない。すなわち待ちが解消している。レコード「１１」に着目すると、待ち番号の列に「１」が登録されていることが分かる。しかしながら、元々ワークフロー１についての排他待ちを判断しているので、レコード「１１」については考慮せず、排他待ちの可能性無しと判断される。レコード「１２」に着目すると、待ち番号の列に「２」が登録されていることが分かる。しかしながら、ワークフロー２についてのレコード「９」が処理対象レコードであるから、レコード「１２」については考慮せず、排他待ちの可能性無しと判断される。このようにレコード「９」についてのインスタンスの排他待ちは解消している。

そうすると、処理はステップＳ５５に戻って、レコード「５」については、レコード「７」からして待ちが解消している場合と、レコード「９」からしてワークフロー２を待つ場合とがある。但し、ワークフロー２を待つ場合については、ワークフロー２のみを待つ状態と、ワークフロー２がワークフロー３を待つ状態とが存在するが、後者については解消しているので、前者のみとなる。従って、レコード「５」については、ワークフロー２についてのレコード「９」のインスタンス待ちが確定する。なお、レコード「７」について待ちが解消している状態も特定されている。

よって、レコード「７」からして待ちが解消していて部品１が実行されて処理が完了した場合を表すレコード「１３」がステップＳ４３でインスタンス管理テーブルに登録される。同様に、レコード「９」を待つ状態を表すレコード「１４」も、ステップＳ３９でインスタンス管理テーブルに登録される。なお、レコード「１４」の待ち状態の列には、上で述べたようにワークフロー２のみを待つことになっているのでワークフロー「２」が登録される。

以上述べたレコード「５」について処理をまとめると図２８に示すようになる。すなわち、ワークフロー２の部品２の完了を待っていたがワークフロー２の部品２の実行が完了したので、ワークフロー１の部品１の実行を行って終了したことを表すレコード「１３」が生成される。また、ワークフロー３を待っていたワークフロー２がまだ完了していないので、ワークフロー２の完了待ちとなっているレコード「１４」も生成される。

このような処理は、レコード「６」「８」「９」「１１」「１２」の各々についても実行される。

レコード「６」については、レコード「１０」からして待ちが解消している場合と、レコード「１２」からしてワークフロー３を待つ場合がある。但し、ワークフロー３を待つ場合については、ワークフロー３のみを待つ状態と、ワークフロー３がワークフロー２を待つ状態とが存在するが、後者については解消しているので、前者のみとなる。従って、ワークフロー３についてのレコード「１２」のインスタンス待ちが確定する。なお、レコード「１０」について待ちが解消している状態も特定されている。

よって、レコード「１０」からして待ちが解消していて部品１が実行されて処理が完了した場合を表すレコード「１５」がステップＳ４３でインスタンス管理テーブルに登録される。同様に、レコード「１２」を待つ状態を表すレコード「１６」も、ステップＳ３９でインスタンス管理テーブルに登録される。なお、レコード「１６」の待ち状態の列には、上で述べたようにワークフロー３のみを待つことになっているのでワークフロー「３」が登録される。

レコード「８」については、レコード「４」からして待ちが解消している場合と、レコード「６」からしてワークフロー１を待つ場合がある。但し、ワークフロー１を待つ場合については、ワークフロー１のみを待つ状態と、ワークフロー１がワークフロー３を待つ状態とが存在するが、後者については解消しているので、前者のみとなる。従って、ワークフロー１についてのレコード「６」のインスタンス待ちが確定する。なお、レコード「４」について待ちが解消している状態も特定されている。

よって、レコード「４」からして待ちが解消していて部品２が実行されて処理が完了した場合を表すレコード「１７」がステップＳ４３でインスタンス管理テーブルに登録される。同様に、レコード「６」を待つ状態を表すレコード「１８」も、ステップＳ３９でインスタンス管理テーブルに登録される。なお、レコード「１８」の待ち状態の列には、上で述べたようにワークフロー１のみを待つことになっているのでワークフロー「１」が登録される。

レコード「９」については、レコード「１０」からして待ちが解消している場合と、レコード「１１」からしてワークフロー３を待つ場合がある。但し、ワークフロー３を待つ場合については、ワークフロー３のみを待つ状態と、ワークフロー３がワークフロー１を待つ状態とが存在するが、後者については解消しているので、前者のみとなる。従って、ワークフロー３についてのレコード「１１」のインスタンス待ちが確定する。なお、レコード「１０」について待ちが解消している状態も特定されている。

よって、レコード「１０」からして待ちが解消していて部品２が実行されて処理が完了した場合を表すレコード「１９」がステップＳ４３でインスタンス管理テーブルに登録される。同様に、レコード「１１」を待つ状態を表すレコード「２０」も、ステップＳ３９でインスタンス管理テーブルに登録される。なお、レコード「２０」の待ち状態の列には、上で述べたようにワークフロー３のみを待つことになっているのでワークフロー「３」が登録される。

レコード「１１」については、レコード「４」からして待ちが解消している場合と、レコード「５」からしてワークフロー１を待つ場合がある。但し、ワークフロー１を待つ場合については、ワークフロー１のみを待つ状態と、ワークフロー１がワークフロー２を待つ状態とが存在するが、後者については解消しているので、前者のみとなる。従って、ワークフロー１についてのレコード「５」のインスタンス待ちが確定する。なお、レコード「４」について待ちが解消している状態も特定されている。

よって、レコード「４」からして待ちが解消していて部品３が実行されて処理が完了した場合を表すレコード「２１」がステップＳ４３でインスタンス管理テーブルに登録される。同様に、レコード「５」を待つ状態を表すレコード「２２」も、ステップＳ３９でインスタンス管理テーブルに登録される。なお、レコード「２２」の待ち状態の列には、上で述べたようにワークフロー１のみを待つことになっているのでワークフロー「１」が登録される。

レコード「１２」については、レコード「７」からして待ちが解消している場合と、レコード「８」からしてワークフロー２を待つ場合がある。但し、ワークフロー２を待つ場合については、ワークフロー２のみを待つ状態と、ワークフロー２がワークフロー１を待つ状態とが存在するが、後者については解消しているので、前者のみとなる。従って、ワークフロー２についてのレコード「８」のインスタンス待ちが確定する。なお、レコード「７」について待ちが解消している状態も特定されている。

よって、レコード「７」からして待ちが解消していて部品３が実行されて処理が完了した場合を表すレコード「２３」がステップＳ４３でインスタンス管理テーブルに登録される。同様に、レコード「８」を待つ状態を表すレコード「２４」も、ステップＳ３９でインスタンス管理テーブルに登録される。なお、レコード「２４」の待ち状態の列には、上で述べたようにワークフロー２のみを待つことになっているのでワークフロー「２」が登録される。

以下の処理については説明を省略する。

さらに別の具体例について図２９乃至図４１を用いて説明する。図２９にワークフローの構成例を示す。ワークフロー１は、部品１及び４を有している。ワークフロー２は、部品２を有する。ワークフロー３は、部品３を有する。ワークフロー１については、部品１及び４についてHostCに対する排他条件が設定されており、ワークフロー２については、部品２についてHostCに対する排他条件が設定されており、ワークフロー３については、部品３についてHostCに対する排他条件が設定されている。すなわち、排他管理テーブルについては、図３０に示すような状態となる。排他資源が共通して設定されていることが分かる。

また、本具体例についての実行時間テーブルについては、図３１に示すように、いずれの部品についても実行時間が１秒としている。

本具体例では、開始時刻がワークフローによって異なる。これは、データベース１２０において開始管理テーブルに規定される。本具体例では、図３２に示すように、ワークフロー１は直ぐに実行を開始し、ワークフロー２については１秒後、ワークフロー３については２秒後に実行を開始するものとする。このような相対的時刻の指定でも良い。

ｔ＝０では、ワークフロー１を担当する運用プロセス状態管理部１３０にのみ予測指示がなされる。そうすると、図３３に示すようなデータがインスタンス管理テーブルに登録される。

ｔ＝０では、ワークフロー１の実行がちょうど開始される状態であるから、排他待ちは発生せず、経過時間も０となる。

ｔ＝１では、ワークフロー２を担当する運用プロセス状態管理部１３０にも予測指示がなされるようになる。そうすると、図３４に示すようなデータがインスタンス管理テーブルに登録される。

レコード「２」については、レコード「１」について１秒後を表す。具体的には、１秒で部品１の実行は完了するので、部品４への遷移を表すレコード「２」が、ステップＳ４３で生成される。

さらに、レコード「３」については、ワークフロー２について、ステップＳ４３で、最初の部品の処理に遷移した状態となる。なお、初期的には状態確定処理においては、待ちが特定されないものとする。

ｔ＝１の状態を模式的に示すと、図３５に示すようになる。図３５に示すように、ワークフロー１については、部品１の処理が完了して、部品４の処理に遷移している。ワークフロー２については、実行がなされていない。

ｔ＝２では、ワークフロー３を担当する運用プロセス状態管理部１３０にも予測指示がなされるようになる。そうすると、図３６に示すようなデータがインスタンス管理テーブルに登録される。

レコード「２」の１秒後については、ワークフロー１の部品４の処理が完了するので、レコード「４」をステップＳ４３で生成して、インスタンス管理テーブルに登録する。

また、レコード「３」についてステップＳ５１で処理を行うと、ワークフロー２はワークフロー１について排他待ちの発生が検出される。なお、ワークフロー３についても排他待ちが発生し得るが、時刻ｔ＝１ではまだレコードが生成されていない状態であるから、ワークフロー３については排他待ちは発生しない。よって、ｔ＝２では、ワークフロー１についてのレコード「２」を待っていることを表すレコード「５」がステップＳ３９で生成され、インスタンス管理テーブルに登録される。

さらに、レコード「６」については、ワークフロー３について、ステップＳ４３で、最初の部品の処理に遷移した状態となる。なお、初期的には状態確定処理においては、待ちが特定されないものとする。

ｔ＝２の状態を模式的に示すと、図３７に示すようになる。図３７に示すように、ワークフロー１のインスタンスについては、部品１も部品４も処理が完了している。一方、ワークフロー２のインスタンスについては、ワークフロー１の排他待ちとなっている。

ｔ＝３では、図３８に示すようなデータがインスタンス管理テーブルに登録される。

ワークフロー２についてのレコード「５」について処理を行うと、ワークフロー１の待ち状態であることが分かる。また、レコード「２」が待ち番号として登録されているので、待ち合わせの可能性が存在すると判断される。レコード「２」を参照して１秒後番号として「４」が特定される。レコード「４」はワークフロー１の部品４が完了したことを表している。以上のことから、ワークフロー１の排他待ちは解消と判断される。そうすると、ステップＳ４３で、ワークフロー２の部品２の処理完了を表すレコード「７」がインスタンス管理テーブルに登録される。

さらに、ワークフロー３についてのレコード「６」についてステップＳ５１で処理を行うと、ワークフロー２について排他待ちの発生が検出される。なお、ワークフロー１についても排他待ちが発生し得るが、時刻ｔ＝２では既に処理が完了しているので、ワークフロー１については排他待ちは発生しない。よって、ｔ＝３では、ワークフロー２についてのレコード「５」を待っていることを表すレコード「８」がステップＳ３９で生成され、インスタンス管理テーブルに登録される。

ｔ＝３についての状態を模式的に示すと図３９に示すような状態となる。レコード「７」は、ワークフロー２について開始時刻「１」から１秒間待った後、部品２が実行されたことを表している。一方、レコード「８」は、ワークフロー３について開始時刻「２」から１秒間、ワークフロー２の排他待ちとなっている。

ｔ＝４では、図４０に示すようなデータがインスタンス管理テーブルに登録される。

ワークフロー３についてのレコード「８」について参照すると、ワークフロー２の待ち状態であることが分かる。また、レコード「５」が待ち番号として登録されているので、待ち合わせの可能性が存在すると判断される。レコード「５」を参照して１秒後番号として「７」が特定される。レコード「７」はワークフロー２の部品２が完了したことを表している。以上のことから、ワークフロー２の排他待ちは解消と判断される。そうすると、ステップＳ４３で、ワークフロー３の部品３の処理完了を表すレコード「９」がインスタンス管理テーブルに登録される。

ｔ＝４についての状態を模式的に示すと図４１に示すような状態となる。レコード「９」は、ワークフロー３について開始時刻「２」から１秒間待った後、部品３が実行されたことを表している。

このようして複数のワークフローが並行して実行される場合に、各ワークフローについてのインスタンスを、実行時間や分岐に応じて追加生成しつつ、他のワークフローに対する排他待ちを再帰的に辿ることで、適切な待ち時間を実行時間に反映させることができるようになる。

例えば、図４２に示すワークフローのような複雑な排他関係が設定されている場合にも対処できる。図４２の例では、ワークフローＡの部品ＡとワークフローＣの部品Ｗ及びＹとに対して同じHostAが排他資源として設定されており、ワークフローＢの部品ＢとワークフローＣの部品Ｙとに対して同じHostYが排他資源として設定されている。さらに、ワークフローＡの部品ＣとワークフローＢの部品Ｃとに対して同じHostBが排他資源として設定されている。

このような場合に、図４３に模式的に示すように、ワークフローＣの部品Ｗの実行開始が早いと、ワークフローＡの部品Ａについては排他待ちとなる。ワークフローＢの部品Ｂの実行がワークフローＣの部品Ｙの実行よりも早い場合には、ワークフローＣの部品Ｗの実行が完了しても部品Ｙの実行は待ちになる。そうすると、ワークフローＡの部品Ａは、ワークフローＣの部品Ｗの排他待ちだったが、その後部品Ｙの排他待ちも多重に生ずる。このような多重の排他待ちについては、再帰的に待ち状態確認処理を実行することでインスタンス管理テーブルに登録されるレコードで表される。

その後、ワークフローＢの部品Ｂの実行が完了すると、ワークフローＣの部品Ｙの排他待ち解消が検出されて、ワークフローＣの部品Ｙが実行される。ワークフローＣの部品Ｙの実行が完了すると、ワークフローＡの部品Ａの排他待ち解消が検出されて、ワークフローＡの部品Ａが実行される。

ワークフローＡの部品Ａの実行が完了しても、部品Ｃについて、ワークフローＢの部品Ｃについての排他待ちを検出する。その後、ワークフローＢの部品Ｃの処理が完了すれば、ワークフローＡの部品Ｃについて排他待ちの解消が検出されて、部品Ｃの実行がなされる。

図４３では、実行時間が一定であることを想定して簡易に排他関係を示しているが、実行時間に範囲が設定されている場合には、各実行時間についてインスタンスが生成され、排他待ち状態も様々な状態となる。このような場合であっても、状況に応じたインスタンスを生成して、時間進展を行うことで、正確にシミュレーションが行われ、正確な実行時間を推定できるようになる。

なお、上では説明を省略しているが、実行時間の最短時間及び最長時間に主に着目するので、明らかに最短時間及び最長時間の算出に無関係となるインスタンスのレコードについては途中で破棄する場合もある。

さらに、上では各部品の実行時間は予め設定されることを前提としていたが、実際にワークフローが実行されるサーバなどの処理の能力などのパラメータから実行時間を推定するようにしても良い。

以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、処理フローについては処理結果が変わらない限り、処理順番を入れ替えたり、複数のステップを並列実行するようにしても良い。また、図２に示した情報処理装置１００の機能ブロック構成についても一例であって、プログラムモジュール構成とは異なる場合もある。

さらに、情報処理装置１００は、１台のコンピュータではなく複数台のコンピュータによって実施される場合もある。

なお、上で述べた情報処理装置１００は、コンピュータ装置であって、図４４に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本実施の形態をまとめると、以下のようになる。

本実施の形態に係る実行時間推定装置は、１又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定装置である。そして、この実行時間推定装置は、（Ａ）複数のプロセスについて排他実行に関する条件と、複数のプロセスに係る各モジュールの実行時間の範囲に関するデータとを格納する格納部と、（Ｂ）（ｂ１）複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で格納部に格納された各モジュールの実行時間の範囲に応じた１又は複数のケースを生成し、（ｂ２）格納部に格納された上記条件に基づく複数のプロセスに係る複数のケース間における排他待ちの発生の有無を判定する第１の判定処理を実行し、排他待ちの発生があると判定された場合には当該排他待ちが発生したプロセスのケースに排他待ちを設定するケース処理を仮想的に時間進展させつつ実行することで、複数のプロセスを実行する場合における実行時間を推定する推定部とを有する。この場合、上記第１の判定処理は、排他待ちが発生する可能性の有無を判定する第２の判定処理と、第２の判定処理の処理結果に基づき、排他待ちの発生の有無を判定する処理とを含む。そして、上記第１の判定処理において、第２の判定処理において排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるケースに対して再帰的に第２の判定処理を実行する。

このように、実行時間の範囲が各モジュールに設定されるような場合には、実行時間に応じた１又は複数のケース（実施の形態におけるインスタンス）が随時（又は動的に）生成されるようになるため、排他待ちが発生する場合もあれば、排他待ちが発生しない場合も生ずる。さらに、ケースによっては排他待ちも多重に発生する場合も生ずる。上で述べたような処理を実行すれば、このような複雑な状況に対して対処できるため、正確に実行時間の推定を行うことができる。なお、複数の実行時間が推定されれば、その中で最短時間及び最長時間を特定する場合もある。これによって、複数のプロセスをある時刻までに終了させることができるか否かを正確に判定できるようになる。

上で述べたケース処理は、複数のプロセスのいずれかのプロセスにおいて分岐が存在する場合には、各分岐先について当該プロセスのケースを生成する処理を含むようにしても良い。これによって、様々なケースを取り扱うことができるようになる。

さらに、上で述べた格納部には、複数のプロセスの開始タイミングに関するデータがさらに格納されている場合がある。この場合、上で述べた推定部は、開始タイミングに応じて複数のプロセスの各々についてケースの生成を開始するようにしても良い。ワークフローによって開始タイミングのずれがあれば、排他待ちの有無に影響があるので、このように制御すれば、正確な実行時間の推定がなされるようになる。

また、上で述べた格納部には、複数のプロセスの少なくとも一部に含まれる、人手を要するモジュールについて実行タイミングについてのデータを含む場合もある。このような場合には、上で述べた推定部は、人手を要するモジュールへ遷移し且つ当該人手を要するモジュールを含むプロセスのケースを、実行タイミングまで待ち発生として取り扱うようにしても良い。人手を要するモジュールでも、他のモジュールと同様に実行時間のバリエーションで対処する場合もあれば、実行タイミングで規定される場合もある。

なお、上で述べたような処理をプロセッサ又はコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭなどの光ディスク、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
１又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定装置であって、
前記複数のプロセスについて排他実行に関する条件と、前記複数のプロセスに係る各モジュールの実行時間の範囲に関するデータとを格納する格納部と、
前記複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で前記格納部に格納された各前記モジュールの前記実行時間の範囲に応じた１又は複数のケースを生成する処理と、
前記格納部に格納された前記条件に基づく前記複数のプロセスに係る複数のケース間における排他待ちの発生の有無を判定する第１の判定処理と、
前記排他待ちの発生があると判定された場合には当該排他待ちが発生したプロセスのケースに排他待ちを設定する処理と
を含むケース処理を仮想的に時間進展させつつ実行することで、前記複数のプロセスを実行する場合における実行時間を推定する推定部と、
を有し、
前記第１の判定処理は、
前記排他待ちが発生する可能性の有無を判定する第２の判定処理と、
前記第２の判定処理の処理結果に基づき、前記排他待ちの発生の有無を判定する処理と、
を含み、
前記第１の判定処理において、
前記第２の判定処理において前記排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるケースに対して再帰的に前記第２の判定処理を実行する
実行時間推定装置。

（付記２）
前記ケース処理は、
前記複数のプロセスのいずれかのプロセスにおいて分岐が存在する場合には、各分岐先について当該プロセスのケースを生成する処理
をさらに含む付記１記載の実行時間推定装置。

（付記３）
前記格納部には、前記複数のプロセスの開始タイミングに関するデータがさらに格納されており、
前記推定部は、
前記開始タイミングに応じて前記複数のプロセスの各々についてケースの生成を開始する
付記１又は２記載の実行時間推定装置。

（付記４）
１又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定方法であって、
前記複数のプロセスについて排他実行に関する条件と、前記複数のプロセスに係る各モジュールの実行時間の範囲に関するデータとを格納する格納部にアクセス可能なコンピュータが、
前記複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で、前記格納部に格納された各前記モジュールの前記実行時間の範囲に応じた１又は複数のケースを生成するケース処理を仮想的に時間進展させつつ実行し、
前記ケース処理の実行結果に基づき、前記複数のプロセスを実行する場合における実行時間を推定する
処理を実行し、
前記ケース処理の実行が、
前記仮想的な時間進展において、
前記格納部に格納された前記条件に基づく前記複数のプロセスに係る複数のケース間における排他待ちが発生する可能性の有無を判定する第１の判定処理を実行し、
前記第１の判定処理の実行において前記排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるケースに対して再帰的に前記第１の判定処理を実行し、
前記第１の判定処理の結果に基づき前記排他待ちの発生があると判定される場合には、当該排他待ちが発生したプロセスのケースに対して排他待ちを設定する
処理を含む実行時間推定方法。

（付記５）
１又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定プログラムであって、
前記複数のプロセスについて排他実行に関する条件と、前記複数のプロセスに係る各モジュールの実行時間の範囲に関するデータとを格納する格納部にアクセス可能なコンピュータに、
前記複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で、前記格納部に格納された各前記モジュールの前記実行時間の範囲に応じた１又は複数のケースを生成するケース処理を仮想的に時間進展させつつ実行し、
前記ケース処理の実行結果に基づき、前記複数のプロセスを実行する場合における実行時間を推定する
処理を実行させ、
前記ケース処理の実行が、
前記仮想的な時間進展において、
前記格納部に格納された前記条件に基づく前記複数のプロセスに係る複数のケース間における排他待ちが発生する可能性の有無を判定する第１の判定処理を実行し、
前記第１の判定処理の実行において前記排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるケースに対して再帰的に前記第１の判定処理を実行し、
前記第１の判定処理の結果に基づき前記排他待ちの発生があると判定される場合には、当該排他待ちが発生したプロセスのケースに対して排他待ちを設定する
処理を含む実行時間推定プログラム。

１１０ 実行制御部
１２０ データベース
１３０ 運用プロセス状態管理部

Claims (5)

1. １又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定装置であって、
   前記複数のプロセスについて排他実行に関する条件と、前記複数のプロセスに係る各モジュールの最短の実行時間から最長の実行時間までの範囲に関するデータとを格納する格納部と、
   前記複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で前記格納部に格納された各前記モジュールの前記最短の実行時間から最長の実行時間までの範囲に含まれる１又は複数の実行時間に応じた１又は複数のインスタンスを生成する処理と、
   前記格納部に格納された前記条件に基づき、前記複数のプロセスに係る複数のインスタンス間において、特定の資源を排他的に用いることができるようになるまで待つ排他待ちの発生の有無を判定する第１の判定処理と、
   前記排他待ちの発生があると判定された場合には当該排他待ちが発生したプロセスのインスタンスに排他待ちを設定する処理と
   を含むインスタンス処理を仮想的に時間進展させつつ実行することで、前記複数のプロセスを実行する場合における実行時間を推定する推定部と、
   を有し、
   前記第１の判定処理は、
   前記排他待ちが発生する可能性の有無を判定する第２の判定処理と、
   前記第２の判定処理の処理結果に基づき、前記排他待ちの発生の有無を判定する処理と、
   を含み、
   前記第１の判定処理において、
   前記第２の判定処理において前記排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるインスタンスに対して再帰的に前記第２の判定処理を実行する
   実行時間推定装置。
2. 前記インスタンス処理は、
   前記複数のプロセスのいずれかのプロセスにおいて分岐が存在する場合には、各分岐先について当該プロセスのインスタンスを生成する処理
   をさらに含む請求項１記載の実行時間推定装置。
3. 前記格納部には、前記複数のプロセスの開始タイミングに関するデータがさらに格納されており、
   前記推定部は、
   前記開始タイミングに応じて前記複数のプロセスの各々についてインスタンスの生成を開始する
   請求項１又は２記載の実行時間推定装置。
4. １又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定方法であって、
   前記複数のプロセスについて排他実行に関する条件と、前記複数のプロセスに係る各モジュールの最短の実行時間から最長の実行時間までの範囲に関するデータとを格納する格納部にアクセス可能なコンピュータが、
   前記複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で、前記格納部に格納された各前記モジュールの前記最短の実行時間から最長の実行時間までの範囲に含まれる１又は複数の実行時間に応じた１又は複数のインスタンスを生成するインスタンス処理を仮想的に時間進展させつつ実行し、
   前記インスタンス処理の実行結果に基づき、前記複数のプロセスを実行する場合における実行時間を推定する
   処理を実行し、
   前記インスタンス処理の実行が、
   前記仮想的な時間進展において、
   前記格納部に格納された前記条件に基づく前記複数のプロセスに係る複数のインスタンス間において、特定の資源を排他的に用いることができるようになるまで待つ排他待ちが発生する可能性の有無を判定する第１の判定処理を実行し、
   前記第１の判定処理の実行において前記排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるインスタンスに対して再帰的に前記第１の判定処理を実行し、
   前記第１の判定処理の結果に基づき前記排他待ちの発生があると判定される場合には、当該排他待ちが発生したプロセスのインスタンスに対して排他待ちを設定する
   処理を含む実行時間推定方法。
5. １又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定プログラムであって、
   前記複数のプロセスについて排他実行に関する条件と、前記複数のプロセスに係る各モジュールの最短の実行時間から最長の実行時間までの範囲に関するデータとを格納する格納部にアクセス可能なコンピュータに、
   前記複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で、前記格納部に格納された各前記モジュールの前記最短の実行時間から最長の実行時間までの範囲に含まれる１又は複数の実行時間に応じた１又は複数のインスタンスを生成するインスタンス処理を仮想的に時間進展させつつ実行し、
   前記インスタンス処理の実行結果に基づき、前記複数のプロセスを実行する場合における実行時間を推定する
   処理を実行させ、
   前記インスタンス処理の実行が、
   前記仮想的な時間進展において、
   前記格納部に格納された前記条件に基づく前記複数のプロセスに係る複数のインスタンス間において、特定の資源を排他的に用いることができるようになるまで待つ排他待ちが発生する可能性の有無を判定する第１の判定処理を実行し、
   前記第１の判定処理の実行において前記排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるインスタンスに対して再帰的に前記第１の判定処理を実行し、
   前記第１の判定処理の結果に基づき前記排他待ちの発生があると判定される場合には、当該排他待ちが発生したプロセスのインスタンスに対して排他待ちを設定する
   処理を含む実行時間推定プログラム。

Images