(57)【特許請求の範囲】
【請求項１】
１又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定装置であって、
前記複数のプロセスについて排他実行に関する条件と、前記複数のプロセスに係る各モジュールの最短の実行時間から最長の実行時間までの範囲に関するデータとを格納する格納部と、
前記複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で前記格納部に格納された各前記モジュールの前記最短の実行時間から最長の実行時間までの範囲に含まれる１又は複数の実行時間に応じた１又は複数のインスタンスを生成する処理と、
前記格納部に格納された前記条件に基づき、前記複数のプロセスに係る複数のインスタンス間において、特定の資源を排他的に用いることができるようになるまで待つ排他待ちの発生の有無を判定する第１の判定処理と、
前記排他待ちの発生があると判定された場合には当該排他待ちが発生したプロセスのインスタンスに排他待ちを設定する処理と
を含むインスタンス処理を仮想的に時間進展させつつ実行することで、前記複数のプロセスを実行する場合における実行時間を推定する推定部と、
を有し、
前記第１の判定処理は、
前記排他待ちが発生する可能性の有無を判定する第２の判定処理と、
前記第２の判定処理の処理結果に基づき、前記排他待ちの発生の有無を判定する処理と、
を含み、
前記第１の判定処理において、
前記第２の判定処理において前記排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるインスタンスに対して再帰的に前記第２の判定処理を実行する
実行時間推定装置。
【請求項２】
前記インスタンス処理は、
前記複数のプロセスのいずれかのプロセスにおいて分岐が存在する場合には、各分岐先について当該プロセスのインスタンスを生成する処理
をさらに含む請求項１記載の実行時間推定装置。
【請求項３】
前記格納部には、前記複数のプロセスの開始タイミングに関するデータがさらに格納されており、
前記推定部は、
前記開始タイミングに応じて前記複数のプロセスの各々についてインスタンスの生成を開始する
請求項１又は２記載の実行時間推定装置。
【請求項４】
１又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定方法であって、
前記複数のプロセスについて排他実行に関する条件と、前記複数のプロセスに係る各モジュールの最短の実行時間から最長の実行時間までの範囲に関するデータとを格納する格納部にアクセス可能なコンピュータが、
前記複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で、前記格納部に格納された各前記モジュールの前記最短の実行時間から最長の実行時間までの範囲に含まれる１又は複数の実行時間に応じた１又は複数のインスタンスを生成するインスタンス処理を仮想的に時間進展させつつ実行し、
前記インスタンス処理の実行結果に基づき、前記複数のプロセスを実行する場合における実行時間を推定する
処理を実行し、
前記インスタンス処理の実行が、
前記仮想的な時間進展において、
前記格納部に格納された前記条件に基づく前記複数のプロセスに係る複数のインスタンス間において、特定の資源を排他的に用いることができるようになるまで待つ排他待ちが発生する可能性の有無を判定する第１の判定処理を実行し、
前記第１の判定処理の実行において前記排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるインスタンスに対して再帰的に前記第１の判定処理を実行し、
前記第１の判定処理の結果に基づき前記排他待ちの発生があると判定される場合には、当該排他待ちが発生したプロセスのインスタンスに対して排他待ちを設定する
処理を含む実行時間推定方法。
【請求項５】
１又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定プログラムであって、
前記複数のプロセスについて排他実行に関する条件と、前記複数のプロセスに係る各モジュールの最短の実行時間から最長の実行時間までの範囲に関するデータとを格納する格納部にアクセス可能なコンピュータに、
前記複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で、前記格納部に格納された各前記モジュールの前記最短の実行時間から最長の実行時間までの範囲に含まれる１又は複数の実行時間に応じた１又は複数のインスタンスを生成するインスタンス処理を仮想的に時間進展させつつ実行し、
前記インスタンス処理の実行結果に基づき、前記複数のプロセスを実行する場合における実行時間を推定する
処理を実行させ、
前記インスタンス処理の実行が、
前記仮想的な時間進展において、
前記格納部に格納された前記条件に基づく前記複数のプロセスに係る複数のインスタンス間において、特定の資源を排他的に用いることができるようになるまで待つ排他待ちが発生する可能性の有無を判定する第１の判定処理を実行し、
前記第１の判定処理の実行において前記排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるインスタンスに対して再帰的に前記第１の判定処理を実行し、
前記第１の判定処理の結果に基づき前記排他待ちの発生があると判定される場合には、当該排他待ちが発生したプロセスのインスタンスに対して排他待ちを設定する
処理を含む実行時間推定プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のワークフローを実行する場合における実行時間の推定技術に関する。
【背景技術】
【０００２】
データセンタには、多数のＩＴ（Information Technology）機器（サーバ、ストレージ、ネットワークなど）が設置されており、それらはハードウエアだけではなくＯＳ（Operating System）、ミドルウエア及びアプリケーションプログラムの組み合わせにて所望の処理を行うようになっている。また、データセンタでは、複数のＩＴ機器を組み合わせた複数の業務システムが稼働しており、多数のＩＴ機器及び業務システムに対して監視や保守作業が行われている。
【０００３】
このようなデータセンタにおける運用作業を自動化するための技術が存在しており、ある技術においては、業務システムに対する作業手順を記述したワークフローを設計して自動実行をすることで、業務の効率化を図っている。図１に示すように、スタート（Ｓｔａｒｔ）から、エンド（Ｅｎｄ）までに、行うべき作業に対応し且つ予め用意された部品を並べて、実行させるようになっている。
【０００４】
しかし、運用プロセス（ワークフローにパラメタなどの情報を与えて起動することで生成されたインスタンスのことを運用プロセスと呼ぶ）の同時実行や、複雑なワークフローでの分岐などにより、運用プロセスの実行がスケジュール通りに終了できず、後続業務（たとえば、オンライン業務開始）に影響を与えることがある。具体的には、後続業務の開始遅延が発生する。
【０００５】
このように運用プロセスをスケジュール通り実行しないと後続業務に影響を与えるため、運用プロセスの終了時刻を事前に正しく導出することが求められている。
【０００６】
例えば、人の作業をワークフロー化して、実行中の運用プロセスが目標時刻までに終了するかを予測する技術が存在している。このような予測では、作業時間の推測値を定義した情報や過去実施した同一の作業の遂行実績時間の情報を用いて、終了時刻を単純計算で求めるだけである。遂行実績時間については、その計測に時間や手間が掛かるだけではなく、あくまで過去の実績に過ぎず、環境が変わったりすれば異なる結果が得られるようになるため、正確性に欠けるという問題もある。
【０００７】
また、従来の技術では、運用プロセスの重要な特性が考慮されていない。すなわち、運用モジュール（ワークフローに含まれる部品を実際に動作させたときに、実行時間が推定される対象を運用モジュールと呼ぶ）の実行時間は、実行されるサーバの状況により変動するが、最小値及び最大値は求めることは可能である。よって、運用プロセスが１つしかない場合には、運用モジュールの実行時間の最小値及び最大値から、運用プロセスの実行時間の最小値及び最大値を算出することはできる。
【０００８】
しかしながら、複数の運用プロセスを実行する場合には、複数の運用プロセスの間で、排他条件が存在する場合がある。このような場合、排他待ち時間は、排他がいつ解消するかにより定まるが、排他条件が多重的に設定されていると複数の排他条件が相互に影響を及ぼして排他の解消がいつ発生するかは、排他を直接発生させた他の運用プロセスだけでは分からない。すなわち、排他待ち時間は、容易に推定できない。
【０００９】
また、排他の発生は、複数の運用プロセスの実行タイミングにも依存するが、そのような問題についても従来の技術では対処できていない。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開平８−１９０５８４号公報
【特許文献２】特開２００８−８４０８３号公報
【特許文献３】特開２００９−１６９７８７号公報
【特許文献４】特表２００３−５２６１５８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
従って、本発明の目的は、一側面によれば、複数のワークフローを実行する際において排他条件が定義されている場合にも正確に実行時間を推定するための技術を提供することである。
【課題を解決するための手段】
【００１２】
本発明の実行時間推定装置は、１又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定装置である。そして、この実行時間推定装置は、（Ａ）複数のプロセスについて排他実行に関する条件と、複数のプロセスに係る各モジュールの実行時間の範囲に関するデータとを格納する格納部と、（Ｂ）（ｂ１）複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で格納部に格納された各モジュールの実行時間の範囲に応じた１又は複数のケースを生成する処理と、（ｂ２）格納部に格納された上記条件に基づく複数のプロセスに係る複数のケース間における排他待ちの発生の有無を判定する第１の判定処理と、（ｂ３）排他待ちの発生があると判定された場合には当該排他待ちが発生したプロセスのケースに排他待ちを設定する処理とを含むケース処理を仮想的に時間進展させつつ実行することで、複数のプロセスを実行する場合における実行時間を推定する推定部とを有する。この場合、上記第１の判定処理は、排他待ちが発生する可能性の有無を判定する第２の判定処理と、第２の判定処理の処理結果に基づき、排他待ちの発生の有無を判定する処理とを含む。そして、上記第１の判定処理において、第２の判定処理において排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるケースに対して再帰的に第２の判定処理を実行する。
【発明の効果】
【００１３】
一側面によれば、複数のワークフローを実行する際において排他条件が定義されている場合にも正確に実行時間を推定できるようになる。
【図面の簡単な説明】
【００１４】
【図１】図１は、ワークフローの一例を示す図である。
【図２】図２は、本発明の実施の形態に係る情報処理装置の機能ブロック図である。
【図３】図３は、実行制御部のメインの処理フローを示す図である。
【図４】図４は、処理結果の出力例を示す図である。
【図５】図５は、見積もり処理の処理フローを示す図である。
【図６】図６は、開始管理テーブルの一例を示す図である。
【図７】図７は、運用プロセス状態管理部のメインの処理フローを示す図である。
【図８】図８は、更新処理の処理フローを示す図である。
【図９】図９は、ワークフローの第１の例を示す図である。
【図１０】図１０は、ワークフローの第１の例についての排他管理テーブルを示す図である。
【図１１】図１１は、ワークフローの第１の例についての実行時間管理テーブルを示す図である。
【図１２】図１２は、ワークフローの第１の例についてｔ＝０におけるインスタンス管理テーブルの状態を示す図である。
【図１３】図１３は、ワークフローの第１の例についてｔ＝１におけるインスタンス管理テーブルの状態を示す図である。
【図１４】図１４は、インスタンス管理テーブルの状態を模式的に示す図である。
【図１５】図１５は、ワークフローの第１の例についてｔ＝２におけるインスタンス管理テーブルの状態を示す図である。
【図１６】図１６は、インスタンス管理テーブルの状態を模式的に示す図である。
【図１７】図１７は、インスタンス管理テーブルの状態を模式的に示す図である。
【図１８】図１８は、インスタンス管理テーブルの状態を模式的に示す図である。
【図１９】図１９は、状態確定処理の処理フローを示す図である。
【図２０】図２０は、待ち状態確認処理の処理フローを示す図である。
【図２１】図２１は、ワークフローの第２の例を示す図である。
【図２２】図２２は、ワークフローの第２の例についての排他管理テーブルを示す図である。
【図２３】図２３は、ワークフローの第２の例についての実行時間管理テーブルを示す図である。
【図２４】図２４は、ワークフローの第２の例についてｔ＝０におけるインスタンス管理テーブルの状態を示す図である。
【図２５】図２５は、ワークフローの第２の例についてｔ＝１におけるインスタンス管理テーブルの状態を示す図である。
【図２６】図２６は、インスタンス管理テーブルの状態を模式的に示す図である。
【図２７】図２７は、ワークフローの第２の例についてｔ＝２におけるインスタンス管理テーブルの状態を示す図である。
【図２８】図２８は、インスタンス管理テーブルの状態を模式的に示す図である。
【図２９】図２９は、ワークフローの第３の例を示す図である。
【図３０】図３０は、ワークフローの第３の例についての排他管理テーブルを示す図である。
【図３１】図３１は、ワークフローの第３の例についての実行時間管理テーブルを示す図である。
【図３２】図３２は、ワークフローの第２の例についての開始時間管理テーブルを示す図である。
【図３３】図３３は、ワークフローの第３の例についてｔ＝０におけるインスタンス管理テーブルの状態を示す図である。
【図３４】図３４は、ワークフローの第３の例についてｔ＝１におけるインスタンス管理テーブルの状態を示す図である。
【図３５】図３５は、インスタンス管理テーブルの状態を模式的に示す図である。
【図３６】図３６は、ワークフローの第３の例についてｔ＝２におけるインスタンス管理テーブルの状態を示す図である。
【図３７】図３７は、インスタンス管理テーブルの状態を模式的に示す図である。
【図３８】図３８は、ワークフローの第３の例についてｔ＝３におけるインスタンス管理テーブルの状態を示す図である。
【図３９】図３９は、インスタンス管理テーブルの状態を模式的に示す図である。
【図４０】図４０は、ワークフローの第３の例についてｔ＝４におけるインスタンス管理テーブルの状態を示す図である。
【図４１】図４１は、インスタンス管理テーブルの状態を模式的に示す図である。
【図４２】図４２は、ワークフローの第４の例を示す図である。
【図４３】図４３は、ワークフローの第４の例の実行を模式的に示す図である。
【図４４】図４４は、コンピュータの機能ブロック図である。
【発明を実施するための形態】
【００１５】
図２に、実行時間推定装置として動作し、本実施の形態に係る情報処理装置１００の構成例を示す。本実施の形態に係る情報処理装置１００は、実行制御部１１０と、データベース１２０と、同時に実行される運用プロセス毎に起動される運用プロセス状態管理部１３０（図２では運用プロセス状態管理部１３０Ａ乃至１３０Ｃ）とを有する。また、情報処理装置１００は、表示装置や印刷装置、ネットワークに接続された他のコンピュータである出力装置２００と接続されている。
【００１６】
実行制御部１１０は、データベース１２０に格納されているデータに基づき、運用プロセス状態管理部１３０Ａ乃至１３０Ｃの起動や処理などを制御し、処理結果を出力装置２００に出力する。
【００１７】
運用プロセス状態管理部１３０Ａ乃至１３０Ｃは、担当するワークフローの運用プロセスの状態を、実行制御部１１０からの指示に基づき時間を進展させつつ、データベース１２０に格納されているデータに基づき遷移させる等して管理する。
【００１８】
データベース１２０は、ワークフローに含まれる部品毎に実行時間のデータ（実行時間管理テーブル）を格納している。また、データベース１２０は、ワークフロー間の排他条件についてのデータ（例えば排他管理テーブル）をも格納している。さらに、データベース１２０は、ワークフローの運用プロセスの実行タイミングについてのデータ（例えば開始管理テーブル）をも格納している。さらに、データベース１２０は、運用プロセスの状態を管理するためのデータ（例えばインスタンス管理テーブル）をも格納している。
【００１９】
本実施の形態では、複数の運用プロセスを並行して動作させた場合に、運用モジュールの実行時間の予想範囲（最短時間から最長時間）に、排他待ちが発生するケースと発生しないケースがないかを、両方とも確認して、それぞれについて実行時間を導出する。また、運用プロセスに分岐がある場合は、終了時刻は１つに定まらないため、網羅的に実行パターンを求めることで解決する。さらに、人の作業は、すぐに実施される場合と、終了期限ぎりぎりまで何もされない場合等が存在する。従って、人の作業についても、終了時間を最短時間から最長時間までの範囲として設定する。
【００２０】
このように、本実施の形態では、複数の運用プロセスを同時に動作させた場合を、生じ得る実行パターンのそれぞれについてシミュレーションを行う。このシミュレーションにおいては、生じ得る実行パターンのそれぞれについて運用プロセスのインスタンスを生成させて、そのインスタンスの状態の変化を、時間の進展に伴い確認してゆく。
【００２１】
上でも述べたように、複数の運用プロセスは、排他条件に基づき、互いに関連しながら動作する。排他待ちは、運用プロセスＡが、運用プロセスＢの終了を待ち、運用プロセスＢは、運用プロセスＣの終了を待つといったように、多重に発生する可能性があるので、排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性のある運用プロセスに対して、さらに排他待ちが発生する可能性があるか否かを再帰的に判定するようにする。
【００２２】
これによって、排他待ちの解消を適切に検出することができるので、結果として待ち時間が正しく想定されるようになって、正しく実行時間を見積もることができるようになる。
【００２３】
このように生じ得る実行パターンのそれぞれについてシミュレーションを実行するので、各運用モジュール等の実行時間の予測範囲が設定されれば、実行実績が無いような運用プロセスの組み合わせについても、実行時間を推定することができるようになる。
【００２４】
次に、図３乃至図４３を用いて、情報処理装置１００の動作内容について説明する。
【００２５】
まず、実行制御部１１０の動作について、図３を用いて説明する。
【００２６】
実行制御部１１０は、ユーザから予測依頼を受け付ける（図３：ステップＳ１）。予測依頼には、並行して実行されるワークフローの指定が含まれる。
【００２７】
また、実行制御部１１０は、予測依頼に含まれるワークフローに応じて、運用プロセス状態管理部１３０を起動させる（ステップＳ３）。例えば３つのワークフローを並行して実行する場合には、それぞれに対して１つの運用プロセス状態管理部１３０を起動させる。
【００２８】
そして、実行制御部１１０等は、見積もり処理を実行する（ステップＳ５）。見積もり処理については、以下に詳細に説明する。
【００２９】
そして、見積もり処理の結果として、実行制御部１１０は、データベース１２０に格納されているデータから、見積もり結果を、出力装置２００に対して出力する（ステップＳ７）。
【００３０】
本実施の形態では、インスタンス管理テーブルに、各運用プロセスについての最短実行時間に相当するデータと最長実行時間に相当するデータとが登録されるようになる。開始時刻が設定されれば、最短終了時刻最長終了時刻も算出される。
【００３１】
例えば、ワークフローＡとワークフローＢとを同時に実行させた場合の見積もり結果の例を図４に示す。図４の例では、ワークフローＡを９：００に開始し、ワークフローＢを９：１０に開始する。そうした場合、ワークフローＡについては、最短実行時間が０：２７で最短終了時刻は９：２７、最長実行時間が０：３０で最長終了時刻は９：３０となる。一方、ワークフローＢについては、最短実行時間が０：２１で最短終了時刻は９：３１、最長実行時間０：４０で最長終了時刻が９：５０となる。このような結果を示せば、ワークフローＡ及びＢを同時実行した場合には、遅くても９：５０に実行が終了することが分かる。
【００３２】
次に、見積もり処理について図５を用いて説明する。
【００３３】
まず、実行制御部１１０は、時刻ｔを０に設定する（図５：ステップＳ１１）。
【００３４】
そして、実行制御部１１０は、起動させた運用プロセス状態管理部１３０から運用プロセスの全てのインスタンスが完了したという通知を受けたか否かで処理を終了させるか否かを判断する（ステップＳ１３）。
【００３５】
処理を終了させない場合には、実行制御部１１０は、ｔ単位時間後の状態を取得するように、運用プロセス状態管理部１３０に対して予測指示を行う（ステップＳ１５）。ここで、実行制御部１１０は、データベース１２０に格納されている開始管理テーブルを参照して、開始時刻以降となったワークフローについての運用プロセス状態管理部１３０に予測指示を出力する。また、全てのインスタンスが完了したとの通知を受けた運用プロセス状態管理部１３０については、指示を行わない。
【００３６】
開始管理テーブルは、例えば図６に示すようなデータである。図６の例では、ワークフローＡについては、９：００に実行を開始し、ワークフローＢについては、９：１０に実行を開始する。このようなデータの場合には、ワークフローＢをワークフローＡの実行開始から１０分たつまではステップＳ１５の予測指示を行わない。
【００３７】
そして、実行制御部１１０は、ｔを１インクリメントし（ステップＳ１７）、処理はステップＳ１３に戻る。このような処理を実行すれば、各時刻における運用プロセスの状態を運用プロセス状態管理部１３０の各々に記録させることができるようになる。終了させる場合には、実行制御部１１０は、各運用プロセス状態管理部１３０に終了指示を出力する（ステップＳ１９）。
【００３８】
次に、図７乃至図４３を用いて、運用プロセス状態管理部１３０の処理内容について説明する。
【００３９】
まず、運用プロセス状態管理部１３０は、実行制御部１１０から指示を受け取ったか否かを判断する（図７：ステップＳ２１）。指示を受け取っていない場合には、処理はステップＳ２１に戻って指示の受信を待つ。
【００４０】
一方、指示を受信した場合には、運用プロセス状態管理部１３０は、終了指示であるか否かを判断する（ステップＳ２３）。何らかの理由で実行制御部１１０が、見積もり処理を途中で終了させる場合には、終了指示がなされる場合がある。終了指示がなされた場合には、処理は終了する。
【００４１】
一方、終了指示ではない場合には、指示は予測指示となるので、運用プロセス状態管理部１３０は、ｔ単位時間後の状態を登録するように、インスタンス管理テーブルの更新処理を実行する（ステップＳ２５）。この更新処理が完了すると、運用プロセス状態管理部１３０は、担当する運用プロセスについてのインスタンスが全て完了となったか否かを判断する（ステップＳ２７）。少なくとも１つのインスタンスについて動作中又は待機中であれば、処理はステップＳ２１に戻る。
【００４２】
一方、全てのインスタンスが完了となった場合には、運用プロセス状態管理部１３０は、完了を実行制御部１１０に通知する（ステップＳ２９）。そして、処理は終了する。
【００４３】
このような処理によって、インスタンス管理テーブルを単位時間毎に更新できるようになる。
【００４４】
次に、更新処理について、図８乃至図４３を用いて説明する。まず、運用プロセス状態管理部１３０は、インスタンス管理テーブルにおいてｔ＝ｔ−１で未完了のインスタンスのうち、未処理のインスタンスを１つ特定する（図８：ステップＳ３０）。
【００４５】
次に、運用プロセス状態管理部１３０は、指定時刻（ｔ単位時間後の時刻）において、特定されたインスタンスが未完了の場合が存在するか否かを判断する（ステップＳ３１）。
【００４６】
運用モジュールの実行時間が、例えば１単位時間又は２単位時間というように設定されていれば、ｔ−１単位時間後にその運用モジュールの実行時間（以下、経過時間と呼ぶ）が１単位時間であるとすると、その運用モジュールの動作が完了する場合と、もう１単位時間だけ動作する場合とに分かれる。このような場合には、指定時刻において未完了の場合が存在すると判断される。
【００４７】
ステップＳ３１の条件を満たす場合には、運用プロセス状態管理部１３０は、特定されたインスタンスについて、運用モジュールが未完了であることを表すレコードを、データベース１２０におけるインスタンス管理テーブルに登録する（ステップＳ３３）。
【００４８】
一方、ステップＳ３１の条件が満たされない場合には、処理はステップＳ３５に移行する。
【００４９】
さらに、運用プロセス状態管理部１３０は、指定時刻について状態確定処理を実行する（ステップＳ３５）。状態確定処理は、排他待ちの状態を確認するための処理であるので、後に詳しく述べる。
【００５０】
その後、運用プロセス状態管理部１３０は、ステップＳ３５の処理結果に基づき、特定されたインスタンスについて、指定時刻に、排他待ちが発生するか否かを判断する（ステップＳ３７）。
【００５１】
排他待ちが発生したと判断された場合には、運用プロセス状態管理部１３０は、特定されたインスタンスについて、排他待ちが発生したことを表すレコードを、データベース１２０におけるインスタンス管理テーブルに登録する（ステップＳ３９）。
【００５２】
一方、排他待ちが発生しないと判断された場合には、処理はステップＳ４１に移行する。
【００５３】
さらに、運用プロセス状態管理部１３０は、指定時刻に、特定されたインスタンスについて、次の運用モジュールに遷移する場合があるか否かを判断する（ステップＳ４１）。具体的には、ｔ＝ｔ−１においてある運用モジュールの動作が完了する場合が存在するか否かを判断する。なお、次の運用モジュールは、終了（ＥＮＤ）をも含む。
【００５４】
ステップＳ４１の条件を満たす場合には、運用プロセス状態管理部１３０は、特定されたインスタンスについて、現在の運用モジュール（又はスタート）から次の運用モジュールに遷移することを表すレコードを、データベース１２０におけるインスタンス管理テーブルに登録する（ステップＳ４３）。そして処理はステップＳ４５に移行する。一方、ステップＳ４１の条件を満たさない場合にも処理はステップＳ４５に移行する。そして、運用プロセス状態管理部１３０は、インスタンス管理テーブルにおいてｔ＝ｔ−１において、未処理の未完了インスタンスが存在しているか否かを判断する（ステップＳ４５）。未処理の未完了インスタンスが存在する場合には、処理はステップＳ３０に戻る。一方、未処理の未完了インスタンスが存在しない場合には、処理は呼び出し元の処理に戻る。
【００５５】
ここで、処理内容を分かりやすくするため、簡単な例を説明してゆくものとする。具体的には、１つのワークフローを実行する場合を例に説明する。図９に示すようなワークフローを想定する。すなわち、開始後に部品１を実行するが、その後、人による作業３と、部品２とを並行して実行して、それぞれその後終了するものである。なお、部品１にはServiceAについての排他が設定されており、部品１及び２についてHostAについての排他も設定されている。
【００５６】
このような場合、データベース１２０には、図１０に示すような排他管理テーブルが格納される。図１０の例では、ワークフロー番号と、排他資源名（HostAやServiceAなど）と、排他開始番号（すなわち部品番号）及び排他終了番号（すなわち部品番号）とが登録されるようになっている。
【００５７】
また、データベース１２０には、図１１に示すような実行時間管理テーブルが格納される。図１１の例では、各部品番号について、最短時間と最長時間とが登録されるようになっている。この例では、どの部品も、１秒（説明を簡単にするため具体例においては１秒が１単位時間とする）乃至２秒の実行時間ということになる。なお、人による作業の場合には、別途実行時刻を定義するようにしても良い。すなわち、終了タイミングが他の部品の実行後というような設定を別途行うようにしても良い。
【００５８】
なお、データベース１２０には、開始管理テーブルを格納しているが、この例ではワークフローが１つだけなので、ここでは用いられないため説明を省略する。
【００５９】
まず、ｔ＝０の場合、インスタンス管理テーブルは、図１２のような状態となる。図１２に示すように、インスタンス管理テーブルには、レコードの識別番号と、総時間と、ワークフロー番号と、実行中の部品番号と、当該部品についての経過時間と、１秒後のレコード番号と、１秒前のレコード番号と、排他待ちを生じさせているレコード番号である待ち番号と、状態確定処理において特定された待ち状態とが登録されるようになっている。ｔ＝０では、ステップＳ４３において、ワークフロー１の部品１の処理が開始していない状態が、登録される。すなわち、１つのインスタンスのみが存在する。
【００６０】
ｔ＝１となると、インスタンス管理テーブルは、図１３に示すような状態となる。レコード番号「２」についてのレコードは、部品１の処理が未完了の場合のインスタンスを表しており、ステップＳ３３で生成され、経過時間が「１」となる。さらに、部品１の処理が１秒で完了したとすると、部品２に遷移する場合と、部品３に遷移する場合とが生ずる。従って、ステップＳ４３において、レコード番号「３」のレコード及びレコード番号「４」のレコードが生成される。
【００６１】
なお、これらのレコードにおいては、１秒前のレコード番号が「１」と設定され、レコード番号「１」のレコードにおいては、１秒後のレコード番号が「２，３，４」と設定される。以下では説明を省略するが、１秒前のレコード番号と１秒後のレコード番号とを登録することで、状態遷移を双方向で辿ることができるようになる。
【００６２】
このようなインスタンス管理テーブルの状態を模式的に示せば、図１４のようになる。なお、レコード「１」のインスタンスが、３つのインスタンスに分岐したことになる。
【００６３】
ｔ＝２となると、インスタンス管理テーブルは、図１５に示すような状態となる。レコード番号「２」のレコードで表されるインスタンスについては、部品１の処理が完了することになるので、ステップＳ４３で次の運用モジュールに遷移することを表すレコードが登録される。この場合、ワークフロー１の構造から、部品２に遷移する場合と部品３に遷移する場合とがあることが分かるので、レコード番号「５」及び「６」のレコードが生成される。遷移したばかりなので、経過時間は「０」となる。
【００６４】
これらのレコードで表される状態を模式的に示せば、図１６に示すようになる。このように、部品１が２秒かかった後に、部品２に遷移したケース（レコード「５」）と、部品３に遷移したケース（レコード「６」）とが発生する。
【００６５】
また、レコード番号「３」のレコードで表されるインスタンスについては、部品２の処理が１秒で完了して終了する場合と、部品２の処理が継続する場合とが発生する。前者の場合には、ステップＳ４３でレコード番号「７」のレコードが生成され、後者の場合には、ステップＳ３３でレコード番号「８」のレコードが生成されることになる。
【００６６】
これらのレコードで表される状態を模式的に示せば、図１７に示すようになる。このように、部品２の処理が１秒で完了して終了するケース（レコード「７」）と、部品２の処理がもう１秒継続するケース（レコード「８」）とが発生する。
【００６７】
さらに、レコード番号「４」のレコードで表されるインスタンスについては、部品３の処理が１秒で完了して終了する場合と、部品３の処理が継続する場合とが発生する。前者の場合には、ステップＳ４３でレコード番号「９」のレコードが生成され、後者の場合には、ステップＳ３３でレコード番号「１０」のレコードが生成されることになる。
【００６８】
これらのレコードで表される状態を模式的に示せば、図１８に示すようになる。このように、部品３の処理が１秒で完了して終了するケース（レコード「９」）と、部品３の処理がもう１秒継続するケース（レコード「１０」）とが発生する。
【００６９】
このようにｔ＝２では６つのインスタンスに分岐したことになる。これ以降の時刻に関する説明については、同様であるから省略する。
【００７０】
次に、排他待ちが発生する場合について図１９乃至図４３を用いて説明する。ここでステップＳ３５の処理内容について、図１９及び図２０を用いて説明する。
【００７１】
運用プロセス状態管理部１３０は、処理対象のインスタンスの状態を特定する（図１９：ステップＳ５１）。
【００７２】
具体的には、インスタンス管理テーブルにおいて、ｔ＝ｔ−１におけるインスタンスのレコードの待ち番号及び待ち状態のデータを読み出す。初期的には何も登録されていないので、開始管理テーブル及び排他管理テーブルから、排他条件を特定して、排他条件から排他待ちが発生するか否かを判断する。なお、新たな排他待ちが発生する場合もあるので、排他管理テーブルから排他条件を特定して、ｔ＝ｔ−１で生存している他のインスタンスと新たな排他が発生していないかを確認する処理をも行う。
【００７３】
次に、運用プロセス状態管理部１３０は、待ち状態確認処理を実行する（ステップＳ５３）。待ち状態確認処理については、後に詳細に説明する。
【００７４】
そして、運用プロセス状態管理部１３０は、検出された待ち状態から、処理対象のインスタンスについて待ち状態を確定させる（ステップＳ５５）。具体的には、指定時刻（ｔ単位時間後の時刻）において、待ちが解消した場合と、待ちが発生している場合とを特定する。待ちが解消した場合には、待ちが解消することで、実行が開始するので次の運用モジュールに遷移することになる。待ちが発生している場合には、どのようなインスタンスによって待ちが生じさせられているのかを特定する。
【００７５】
次に、待ち状態確認処理について、図２０を用いて説明する。
【００７６】
運用プロセス状態管理部１３０は、処理対象のインスタンスが待ちになる可能性があるか否かを確認する（ステップＳ６１）。インスタンス管理テーブルにおいて、着目しているレコードに待ち番号が登録されているか否かを判断する。
【００７７】
待ちになる可能性がなければ（ステップＳ６３：Ｎｏルート）、呼び出し元の処理に戻る。
【００７８】
一方、待ちになる可能性があれば（ステップＳ６３：Ｙｅｓルート）、運用プロセス状態管理部１３０は、排他を先にとっている運用プロセスのインスタンスに関する時刻ｔのレコードを特定する（ステップＳ６５）。そして、運用プロセス状態管理部１３０は、排他を先にとった運用プロセスのインスタンスについて、待ち状態確認処理を再帰的に実行する（ステップＳ６７）。そして呼び出し元の処理に戻る。
【００７９】
このようにすることで、排他の可能性なしと判定されるまで、排他関係を確認する。
【００８０】
例えば、図２１に示すような具体例を考察する。図２１の例では、ワークフロー１乃至３を並行して実行する場合を想定しており、ワークフロー１には部品１が含まれ、ワークフロー２には部品２が含まれ、ワークフロー３には部品３が含まれる。排他条件としては、部品１乃至３は、それぞれHostBへの排他が設定されている。従って、排他管理テーブルは、図２２に示すような状態となる。すなわち、各ワークフローの部品には、排他資源名としてHostBが設定されている。
【００８１】
また、図２３に示すような実行時間管理テーブルがデータベース１２０に格納されているものとする。図２３の例では、どの部品も実行時間は１秒と簡素化されている。
【００８２】
なお、この例でも開始時刻は同じになっているものとして、開始時刻テーブルについては説明を省略する。
【００８３】
図２２に示すような排他管理テーブルの場合には、ワークフロー１に着目すれば、排他条件がワークフロー２及び３と重複しており、ワークフロー２とワークフロー３とで待ち合せが発生する可能性がある。
【００８４】
ｔ＝０では、図２４に示すようなインスタンス管理テーブルの状態となる。どのワークフローについても、ステップＳ４３で、最初の部品の処理に遷移した状態となる。なお、初期的には状態確定処理においては、待ちが特定されないものとする。
【００８５】
ｔ＝１では、図２５に示すようなインスタンス管理テーブルの状態となる。
【００８６】
レコード番号「１」のレコードで表されるインスタンスについては、部品１の実行時間は１秒なので、実行していれば未完了となることはないので、ステップＳ３３でレコードは登録されない。状態確定処理においては、ステップＳ５１で、排他管理テーブルから、他のワークフローについて設定されている排他条件から、排他待ちが発生するか否かを判断する。図２２に示す排他管理テーブルの場合、ワークフロー１が最初に実行されれば待ちは発生しない。一方、ワークフロー２の部品２及びワークフロー３の部品３と排他の関係にあることが把握される。従って、ワークフロー２の排他待ちと、ワークフロー３の排他待ちとが生ずる。但し、ワークフロー２の排他待ちの場合には、ワークフロー２自体がワークフロー３を排他待ちの場合もある。同様に、ワークフロー３の排他待ちの場合には、ワークフロー３自体がワークフロー２を排他待ちの場合もある。このような状態を特定する。なお、ｔ＝０のレコード番号「１」のレコードには待ち番号が登録されていないので、待ちの可能性はないと判断される。
【００８７】
従って、ステップＳ３９では、ワークフロー２を待つ場合のインスタンスのレコード（レコード番号「５」）と、ワークフロー３を待つ場合のインスタンスのレコード（レコード番号「６」）とを生成する。上で述べたように、ワークフロー２を待つ場合であっても、ワークフロー２のみを待つ場合とワークフロー２がワークフロー３を待つ場合もあるので、その状態を待ち状態の列に登録する。「２−＞３」はワークフロー２がワークフロー３を待つ状態を表している。同様に、ワークフロー３を待つ場合であっても、ワークフロー３のみを待つ場合とワークフロー３がワークフロー２を待つ場合もあるので、その状態を待ち状態の列に登録する。
【００８８】
また、ステップＳ４３では、ワークフロー１の部品１が最初に実行して処理が終了するインスタンスについてのレコード（レコード番号「４」）を、インスタンス管理テーブルに登録する。
【００８９】
ｔ＝１におけるワークフロー１についてのインスタンスの状態を模式的に示せば図２６のようになる。
【００９０】
この具体例においては、ワークフロー２についてのレコード「２」及びワークフロー３についてのレコード「３」についても、同様の判断が行われる。
【００９１】
ワークフロー２については、レコード「８」及び「９」が、ステップＳ３９で生成され、レコード「７」がステップＳ４３で生成される。レコード「８」は、ワークフロー１を待つインスタンスを示すが、ワークフロー１のみを待つ状態とワークフロー１がワークフロー３を待つ状態とを含む。同様に、レコード「９」は、ワークフロー３を待つインスタンスを示すが、ワークフロー３のみを待つ状態とワークフロー３がワークフロー１を待つ状態とを含む。
【００９２】
さらに、ワークフロー３については、レコード「１１」及び「１２」が、ステップＳ３９で生成され、レコード「１０」がステップＳ４３で生成される。レコード「１１」は、ワークフロー１を待つインスタンスを示すが、ワークフロー１のみを待つ状態とワークフロー１がワークフロー２を待つ状態とを含む。同様に、レコード「１２」は、ワークフロー２を待つインスタンスを示すが、ワークフロー２のみを待つ状態とワークフロー２がワークフロー１を待つ状態とを含む。
【００９３】
次に、ｔ＝２では、図２７に示すようなインスタンス管理テーブルの状態となる。ｔ＝２では、レコード「５」「６」「８」「９」「１１」「１２」が処理対象となる。
【００９４】
レコード「５」のインスタンスに着目すると、まだ実行を開始していないので、ステップＳ３３で未完了であることを表すレコードは登録されない。
【００９５】
一方、待ち状態の列に、１秒前の状態が登録されているので、ステップＳ５１でこの状態を特定する。ステップＳ６１では、待ち番号の列にレコード「２」が登録されているので、ステップＳ６３で排他待ちの可能性があると判断される。そうすると、レコード「２」における１秒後番号の列に「７，８，９」が登録されているので、ステップＳ６５でこれらのレコードを特定する。ステップＳ６７においては、特定された３レコードの各々について、再帰的に待ち状態確認処理を実行する。
【００９６】
レコード「７」に着目すると、終了しているので待ちの可能性はない、すなわち待ちが解消している。レコード「８」に着目すると、待ち番号の列に「１」が登録されていることが分かる。しかしながら、現在の処理対象レコードがワークフロー１についてのレコードなので、レコード「８」については考慮せず、排他待ちの可能性無しと判断される。レコード「９」に着目すると、待ち番号の列に「３」が登録されていることが分かる。ここで、ステップＳ６３で排他待ちの可能性が検出される。
【００９７】
そうすると、ステップＳ６５で、レコード「３」を参照して、１秒後番号の列に登録されているレコード「１０」「１１」「１２」を特定する。そして、これらのレコードの各々について、ステップＳ６７において、再帰的に待ち状態確認処理を実行する。
【００９８】
レコード「１０」に着目すると、終了しているので待ちの可能性はない。すなわち待ちが解消している。レコード「１１」に着目すると、待ち番号の列に「１」が登録されていることが分かる。しかしながら、元々ワークフロー１についての排他待ちを判断しているので、レコード「１１」については考慮せず、排他待ちの可能性無しと判断される。レコード「１２」に着目すると、待ち番号の列に「２」が登録されていることが分かる。しかしながら、ワークフロー２についてのレコード「９」が処理対象レコードであるから、レコード「１２」については考慮せず、排他待ちの可能性無しと判断される。このようにレコード「９」についてのインスタンスの排他待ちは解消している。
【００９９】
そうすると、処理はステップＳ５５に戻って、レコード「５」については、レコード「７」からして待ちが解消している場合と、レコード「９」からしてワークフロー２を待つ場合とがある。但し、ワークフロー２を待つ場合については、ワークフロー２のみを待つ状態と、ワークフロー２がワークフロー３を待つ状態とが存在するが、後者については解消しているので、前者のみとなる。従って、レコード「５」については、ワークフロー２についてのレコード「９」のインスタンス待ちが確定する。なお、レコード「７」について待ちが解消している状態も特定されている。
【０１００】
よって、レコード「７」からして待ちが解消していて部品１が実行されて処理が完了した場合を表すレコード「１３」がステップＳ４３でインスタンス管理テーブルに登録される。同様に、レコード「９」を待つ状態を表すレコード「１４」も、ステップＳ３９でインスタンス管理テーブルに登録される。なお、レコード「１４」の待ち状態の列には、上で述べたようにワークフロー２のみを待つことになっているのでワークフロー「２」が登録される。
【０１０１】
以上述べたレコード「５」について処理をまとめると図２８に示すようになる。すなわち、ワークフロー２の部品２の完了を待っていたがワークフロー２の部品２の実行が完了したので、ワークフロー１の部品１の実行を行って終了したことを表すレコード「１３」が生成される。また、ワークフロー３を待っていたワークフロー２がまだ完了していないので、ワークフロー２の完了待ちとなっているレコード「１４」も生成される。
【０１０２】
このような処理は、レコード「６」「８」「９」「１１」「１２」の各々についても実行される。
【０１０３】
レコード「６」については、レコード「１０」からして待ちが解消している場合と、レコード「１２」からしてワークフロー３を待つ場合がある。但し、ワークフロー３を待つ場合については、ワークフロー３のみを待つ状態と、ワークフロー３がワークフロー２を待つ状態とが存在するが、後者については解消しているので、前者のみとなる。従って、ワークフロー３についてのレコード「１２」のインスタンス待ちが確定する。なお、レコード「１０」について待ちが解消している状態も特定されている。
【０１０４】
よって、レコード「１０」からして待ちが解消していて部品１が実行されて処理が完了した場合を表すレコード「１５」がステップＳ４３でインスタンス管理テーブルに登録される。同様に、レコード「１２」を待つ状態を表すレコード「１６」も、ステップＳ３９でインスタンス管理テーブルに登録される。なお、レコード「１６」の待ち状態の列には、上で述べたようにワークフロー３のみを待つことになっているのでワークフロー「３」が登録される。
【０１０５】
レコード「８」については、レコード「４」からして待ちが解消している場合と、レコード「６」からしてワークフロー１を待つ場合がある。但し、ワークフロー１を待つ場合については、ワークフロー１のみを待つ状態と、ワークフロー１がワークフロー３を待つ状態とが存在するが、後者については解消しているので、前者のみとなる。従って、ワークフロー１についてのレコード「６」のインスタンス待ちが確定する。なお、レコード「４」について待ちが解消している状態も特定されている。
【０１０６】
よって、レコード「４」からして待ちが解消していて部品２が実行されて処理が完了した場合を表すレコード「１７」がステップＳ４３でインスタンス管理テーブルに登録される。同様に、レコード「６」を待つ状態を表すレコード「１８」も、ステップＳ３９でインスタンス管理テーブルに登録される。なお、レコード「１８」の待ち状態の列には、上で述べたようにワークフロー１のみを待つことになっているのでワークフロー「１」が登録される。
【０１０７】
レコード「９」については、レコード「１０」からして待ちが解消している場合と、レコード「１１」からしてワークフロー３を待つ場合がある。但し、ワークフロー３を待つ場合については、ワークフロー３のみを待つ状態と、ワークフロー３がワークフロー１を待つ状態とが存在するが、後者については解消しているので、前者のみとなる。従って、ワークフロー３についてのレコード「１１」のインスタンス待ちが確定する。なお、レコード「１０」について待ちが解消している状態も特定されている。
【０１０８】
よって、レコード「１０」からして待ちが解消していて部品２が実行されて処理が完了した場合を表すレコード「１９」がステップＳ４３でインスタンス管理テーブルに登録される。同様に、レコード「１１」を待つ状態を表すレコード「２０」も、ステップＳ３９でインスタンス管理テーブルに登録される。なお、レコード「２０」の待ち状態の列には、上で述べたようにワークフロー３のみを待つことになっているのでワークフロー「３」が登録される。
【０１０９】
レコード「１１」については、レコード「４」からして待ちが解消している場合と、レコード「５」からしてワークフロー１を待つ場合がある。但し、ワークフロー１を待つ場合については、ワークフロー１のみを待つ状態と、ワークフロー１がワークフロー２を待つ状態とが存在するが、後者については解消しているので、前者のみとなる。従って、ワークフロー１についてのレコード「５」のインスタンス待ちが確定する。なお、レコード「４」について待ちが解消している状態も特定されている。
【０１１０】
よって、レコード「４」からして待ちが解消していて部品３が実行されて処理が完了した場合を表すレコード「２１」がステップＳ４３でインスタンス管理テーブルに登録される。同様に、レコード「５」を待つ状態を表すレコード「２２」も、ステップＳ３９でインスタンス管理テーブルに登録される。なお、レコード「２２」の待ち状態の列には、上で述べたようにワークフロー１のみを待つことになっているのでワークフロー「１」が登録される。
【０１１１】
レコード「１２」については、レコード「７」からして待ちが解消している場合と、レコード「８」からしてワークフロー２を待つ場合がある。但し、ワークフロー２を待つ場合については、ワークフロー２のみを待つ状態と、ワークフロー２がワークフロー１を待つ状態とが存在するが、後者については解消しているので、前者のみとなる。従って、ワークフロー２についてのレコード「８」のインスタンス待ちが確定する。なお、レコード「７」について待ちが解消している状態も特定されている。
【０１１２】
よって、レコード「７」からして待ちが解消していて部品３が実行されて処理が完了した場合を表すレコード「２３」がステップＳ４３でインスタンス管理テーブルに登録される。同様に、レコード「８」を待つ状態を表すレコード「２４」も、ステップＳ３９でインスタンス管理テーブルに登録される。なお、レコード「２４」の待ち状態の列には、上で述べたようにワークフロー２のみを待つことになっているのでワークフロー「２」が登録される。
【０１１３】
以下の処理については説明を省略する。
【０１１４】
さらに別の具体例について図２９乃至図４１を用いて説明する。図２９にワークフローの構成例を示す。ワークフロー１は、部品１及び４を有している。ワークフロー２は、部品２を有する。ワークフロー３は、部品３を有する。ワークフロー１については、部品１及び４についてHostCに対する排他条件が設定されており、ワークフロー２については、部品２についてHostCに対する排他条件が設定されており、ワークフロー３については、部品３についてHostCに対する排他条件が設定されている。すなわち、排他管理テーブルについては、図３０に示すような状態となる。排他資源が共通して設定されていることが分かる。
【０１１５】
また、本具体例についての実行時間テーブルについては、図３１に示すように、いずれの部品についても実行時間が１秒としている。
【０１１６】
本具体例では、開始時刻がワークフローによって異なる。これは、データベース１２０において開始管理テーブルに規定される。本具体例では、図３２に示すように、ワークフロー１は直ぐに実行を開始し、ワークフロー２については１秒後、ワークフロー３については２秒後に実行を開始するものとする。このような相対的時刻の指定でも良い。
【０１１７】
ｔ＝０では、ワークフロー１を担当する運用プロセス状態管理部１３０にのみ予測指示がなされる。そうすると、図３３に示すようなデータがインスタンス管理テーブルに登録される。
【０１１８】
ｔ＝０では、ワークフロー１の実行がちょうど開始される状態であるから、排他待ちは発生せず、経過時間も０となる。
【０１１９】
ｔ＝１では、ワークフロー２を担当する運用プロセス状態管理部１３０にも予測指示がなされるようになる。そうすると、図３４に示すようなデータがインスタンス管理テーブルに登録される。
【０１２０】
レコード「２」については、レコード「１」について１秒後を表す。具体的には、１秒で部品１の実行は完了するので、部品４への遷移を表すレコード「２」が、ステップＳ４３で生成される。
【０１２１】
さらに、レコード「３」については、ワークフロー２について、ステップＳ４３で、最初の部品の処理に遷移した状態となる。なお、初期的には状態確定処理においては、待ちが特定されないものとする。
【０１２２】
ｔ＝１の状態を模式的に示すと、図３５に示すようになる。図３５に示すように、ワークフロー１については、部品１の処理が完了して、部品４の処理に遷移している。ワークフロー２については、実行がなされていない。
【０１２３】
ｔ＝２では、ワークフロー３を担当する運用プロセス状態管理部１３０にも予測指示がなされるようになる。そうすると、図３６に示すようなデータがインスタンス管理テーブルに登録される。
【０１２４】
レコード「２」の１秒後については、ワークフロー１の部品４の処理が完了するので、レコード「４」をステップＳ４３で生成して、インスタンス管理テーブルに登録する。
【０１２５】
また、レコード「３」についてステップＳ５１で処理を行うと、ワークフロー２はワークフロー１について排他待ちの発生が検出される。なお、ワークフロー３についても排他待ちが発生し得るが、時刻ｔ＝１ではまだレコードが生成されていない状態であるから、ワークフロー３については排他待ちは発生しない。よって、ｔ＝２では、ワークフロー１についてのレコード「２」を待っていることを表すレコード「５」がステップＳ３９で生成され、インスタンス管理テーブルに登録される。
【０１２６】
さらに、レコード「６」については、ワークフロー３について、ステップＳ４３で、最初の部品の処理に遷移した状態となる。なお、初期的には状態確定処理においては、待ちが特定されないものとする。
【０１２７】
ｔ＝２の状態を模式的に示すと、図３７に示すようになる。図３７に示すように、ワークフロー１のインスタンスについては、部品１も部品４も処理が完了している。一方、ワークフロー２のインスタンスについては、ワークフロー１の排他待ちとなっている。
【０１２８】
ｔ＝３では、図３８に示すようなデータがインスタンス管理テーブルに登録される。
【０１２９】
ワークフロー２についてのレコード「５」について処理を行うと、ワークフロー１の待ち状態であることが分かる。また、レコード「２」が待ち番号として登録されているので、待ち合わせの可能性が存在すると判断される。レコード「２」を参照して１秒後番号として「４」が特定される。レコード「４」はワークフロー１の部品４が完了したことを表している。以上のことから、ワークフロー１の排他待ちは解消と判断される。そうすると、ステップＳ４３で、ワークフロー２の部品２の処理完了を表すレコード「７」がインスタンス管理テーブルに登録される。
【０１３０】
さらに、ワークフロー３についてのレコード「６」についてステップＳ５１で処理を行うと、ワークフロー２について排他待ちの発生が検出される。なお、ワークフロー１についても排他待ちが発生し得るが、時刻ｔ＝２では既に処理が完了しているので、ワークフロー１については排他待ちは発生しない。よって、ｔ＝３では、ワークフロー２についてのレコード「５」を待っていることを表すレコード「８」がステップＳ３９で生成され、インスタンス管理テーブルに登録される。
【０１３１】
ｔ＝３についての状態を模式的に示すと図３９に示すような状態となる。レコード「７」は、ワークフロー２について開始時刻「１」から１秒間待った後、部品２が実行されたことを表している。一方、レコード「８」は、ワークフロー３について開始時刻「２」から１秒間、ワークフロー２の排他待ちとなっている。
【０１３２】
ｔ＝４では、図４０に示すようなデータがインスタンス管理テーブルに登録される。
【０１３３】
ワークフロー３についてのレコード「８」について参照すると、ワークフロー２の待ち状態であることが分かる。また、レコード「５」が待ち番号として登録されているので、待ち合わせの可能性が存在すると判断される。レコード「５」を参照して１秒後番号として「７」が特定される。レコード「７」はワークフロー２の部品２が完了したことを表している。以上のことから、ワークフロー２の排他待ちは解消と判断される。そうすると、ステップＳ４３で、ワークフロー３の部品３の処理完了を表すレコード「９」がインスタンス管理テーブルに登録される。
【０１３４】
ｔ＝４についての状態を模式的に示すと図４１に示すような状態となる。レコード「９」は、ワークフロー３について開始時刻「２」から１秒間待った後、部品３が実行されたことを表している。
【０１３５】
このようして複数のワークフローが並行して実行される場合に、各ワークフローについてのインスタンスを、実行時間や分岐に応じて追加生成しつつ、他のワークフローに対する排他待ちを再帰的に辿ることで、適切な待ち時間を実行時間に反映させることができるようになる。
【０１３６】
例えば、図４２に示すワークフローのような複雑な排他関係が設定されている場合にも対処できる。図４２の例では、ワークフローＡの部品ＡとワークフローＣの部品Ｗ及びＹとに対して同じHostAが排他資源として設定されており、ワークフローＢの部品ＢとワークフローＣの部品Ｙとに対して同じHostYが排他資源として設定されている。さらに、ワークフローＡの部品ＣとワークフローＢの部品Ｃとに対して同じHostBが排他資源として設定されている。
【０１３７】
このような場合に、図４３に模式的に示すように、ワークフローＣの部品Ｗの実行開始が早いと、ワークフローＡの部品Ａについては排他待ちとなる。ワークフローＢの部品Ｂの実行がワークフローＣの部品Ｙの実行よりも早い場合には、ワークフローＣの部品Ｗの実行が完了しても部品Ｙの実行は待ちになる。そうすると、ワークフローＡの部品Ａは、ワークフローＣの部品Ｗの排他待ちだったが、その後部品Ｙの排他待ちも多重に生ずる。このような多重の排他待ちについては、再帰的に待ち状態確認処理を実行することでインスタンス管理テーブルに登録されるレコードで表される。
【０１３８】
その後、ワークフローＢの部品Ｂの実行が完了すると、ワークフローＣの部品Ｙの排他待ち解消が検出されて、ワークフローＣの部品Ｙが実行される。ワークフローＣの部品Ｙの実行が完了すると、ワークフローＡの部品Ａの排他待ち解消が検出されて、ワークフローＡの部品Ａが実行される。
【０１３９】
ワークフローＡの部品Ａの実行が完了しても、部品Ｃについて、ワークフローＢの部品Ｃについての排他待ちを検出する。その後、ワークフローＢの部品Ｃの処理が完了すれば、ワークフローＡの部品Ｃについて排他待ちの解消が検出されて、部品Ｃの実行がなされる。
【０１４０】
図４３では、実行時間が一定であることを想定して簡易に排他関係を示しているが、実行時間に範囲が設定されている場合には、各実行時間についてインスタンスが生成され、排他待ち状態も様々な状態となる。このような場合であっても、状況に応じたインスタンスを生成して、時間進展を行うことで、正確にシミュレーションが行われ、正確な実行時間を推定できるようになる。
【０１４１】
なお、上では説明を省略しているが、実行時間の最短時間及び最長時間に主に着目するので、明らかに最短時間及び最長時間の算出に無関係となるインスタンスのレコードについては途中で破棄する場合もある。
【０１４２】
さらに、上では各部品の実行時間は予め設定されることを前提としていたが、実際にワークフローが実行されるサーバなどの処理の能力などのパラメータから実行時間を推定するようにしても良い。
【０１４３】
以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、処理フローについては処理結果が変わらない限り、処理順番を入れ替えたり、複数のステップを並列実行するようにしても良い。また、図２に示した情報処理装置１００の機能ブロック構成についても一例であって、プログラムモジュール構成とは異なる場合もある。
【０１４４】
さらに、情報処理装置１００は、１台のコンピュータではなく複数台のコンピュータによって実施される場合もある。
【０１４５】
なお、上で述べた情報処理装置１００は、コンピュータ装置であって、図４４に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【０１４６】
以上述べた本実施の形態をまとめると、以下のようになる。
【０１４７】
本実施の形態に係る実行時間推定装置は、１又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定装置である。そして、この実行時間推定装置は、（Ａ）複数のプロセスについて排他実行に関する条件と、複数のプロセスに係る各モジュールの実行時間の範囲に関するデータとを格納する格納部と、（Ｂ）（ｂ１）複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で格納部に格納された各モジュールの実行時間の範囲に応じた１又は複数のケースを生成し、（ｂ２）格納部に格納された上記条件に基づく複数のプロセスに係る複数のケース間における排他待ちの発生の有無を判定する第１の判定処理を実行し、排他待ちの発生があると判定された場合には当該排他待ちが発生したプロセスのケースに排他待ちを設定するケース処理を仮想的に時間進展させつつ実行することで、複数のプロセスを実行する場合における実行時間を推定する推定部とを有する。この場合、上記第１の判定処理は、排他待ちが発生する可能性の有無を判定する第２の判定処理と、第２の判定処理の処理結果に基づき、排他待ちの発生の有無を判定する処理とを含む。そして、上記第１の判定処理において、第２の判定処理において排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるケースに対して再帰的に第２の判定処理を実行する。
【０１４８】
このように、実行時間の範囲が各モジュールに設定されるような場合には、実行時間に応じた１又は複数のケース（実施の形態におけるインスタンス）が随時（又は動的に）生成されるようになるため、排他待ちが発生する場合もあれば、排他待ちが発生しない場合も生ずる。さらに、ケースによっては排他待ちも多重に発生する場合も生ずる。上で述べたような処理を実行すれば、このような複雑な状況に対して対処できるため、正確に実行時間の推定を行うことができる。なお、複数の実行時間が推定されれば、その中で最短時間及び最長時間を特定する場合もある。これによって、複数のプロセスをある時刻までに終了させることができるか否かを正確に判定できるようになる。
【０１４９】
上で述べたケース処理は、複数のプロセスのいずれかのプロセスにおいて分岐が存在する場合には、各分岐先について当該プロセスのケースを生成する処理を含むようにしても良い。これによって、様々なケースを取り扱うことができるようになる。
【０１５０】
さらに、上で述べた格納部には、複数のプロセスの開始タイミングに関するデータがさらに格納されている場合がある。この場合、上で述べた推定部は、開始タイミングに応じて複数のプロセスの各々についてケースの生成を開始するようにしても良い。ワークフローによって開始タイミングのずれがあれば、排他待ちの有無に影響があるので、このように制御すれば、正確な実行時間の推定がなされるようになる。
【０１５１】
また、上で述べた格納部には、複数のプロセスの少なくとも一部に含まれる、人手を要するモジュールについて実行タイミングについてのデータを含む場合もある。このような場合には、上で述べた推定部は、人手を要するモジュールへ遷移し且つ当該人手を要するモジュールを含むプロセスのケースを、実行タイミングまで待ち発生として取り扱うようにしても良い。人手を要するモジュールでも、他のモジュールと同様に実行時間のバリエーションで対処する場合もあれば、実行タイミングで規定される場合もある。
【０１５２】
なお、上で述べたような処理をプロセッサ又はコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭなどの光ディスク、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ等の記憶装置に一時保管される。
【０１５３】
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
【０１５４】
（付記１）
１又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定装置であって、
前記複数のプロセスについて排他実行に関する条件と、前記複数のプロセスに係る各モジュールの実行時間の範囲に関するデータとを格納する格納部と、
前記複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で前記格納部に格納された各前記モジュールの前記実行時間の範囲に応じた１又は複数のケースを生成する処理と、
前記格納部に格納された前記条件に基づく前記複数のプロセスに係る複数のケース間における排他待ちの発生の有無を判定する第１の判定処理と、
前記排他待ちの発生があると判定された場合には当該排他待ちが発生したプロセスのケースに排他待ちを設定する処理と
を含むケース処理を仮想的に時間進展させつつ実行することで、前記複数のプロセスを実行する場合における実行時間を推定する推定部と、
を有し、
前記第１の判定処理は、
前記排他待ちが発生する可能性の有無を判定する第２の判定処理と、
前記第２の判定処理の処理結果に基づき、前記排他待ちの発生の有無を判定する処理と、
を含み、
前記第１の判定処理において、
前記第２の判定処理において前記排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるケースに対して再帰的に前記第２の判定処理を実行する
実行時間推定装置。
【０１５５】
（付記２）
前記ケース処理は、
前記複数のプロセスのいずれかのプロセスにおいて分岐が存在する場合には、各分岐先について当該プロセスのケースを生成する処理
をさらに含む付記１記載の実行時間推定装置。
【０１５６】
（付記３）
前記格納部には、前記複数のプロセスの開始タイミングに関するデータがさらに格納されており、
前記推定部は、
前記開始タイミングに応じて前記複数のプロセスの各々についてケースの生成を開始する
付記１又は２記載の実行時間推定装置。
【０１５７】
（付記４）
１又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定方法であって、
前記複数のプロセスについて排他実行に関する条件と、前記複数のプロセスに係る各モジュールの実行時間の範囲に関するデータとを格納する格納部にアクセス可能なコンピュータが、
前記複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で、前記格納部に格納された各前記モジュールの前記実行時間の範囲に応じた１又は複数のケースを生成するケース処理を仮想的に時間進展させつつ実行し、
前記ケース処理の実行結果に基づき、前記複数のプロセスを実行する場合における実行時間を推定する
処理を実行し、
前記ケース処理の実行が、
前記仮想的な時間進展において、
前記格納部に格納された前記条件に基づく前記複数のプロセスに係る複数のケース間における排他待ちが発生する可能性の有無を判定する第１の判定処理を実行し、
前記第１の判定処理の実行において前記排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるケースに対して再帰的に前記第１の判定処理を実行し、
前記第１の判定処理の結果に基づき前記排他待ちの発生があると判定される場合には、当該排他待ちが発生したプロセスのケースに対して排他待ちを設定する
処理を含む実行時間推定方法。
【０１５８】
（付記５）
１又は複数のモジュールを各々含む複数のプロセスを実行する場合における実行時間を推定する実行時間推定プログラムであって、
前記複数のプロセスについて排他実行に関する条件と、前記複数のプロセスに係る各モジュールの実行時間の範囲に関するデータとを格納する格納部にアクセス可能なコンピュータに、
前記複数のプロセスの各々について、当該プロセスに含まれるモジュールの順番で、前記格納部に格納された各前記モジュールの前記実行時間の範囲に応じた１又は複数のケースを生成するケース処理を仮想的に時間進展させつつ実行し、
前記ケース処理の実行結果に基づき、前記複数のプロセスを実行する場合における実行時間を推定する
処理を実行させ、
前記ケース処理の実行が、
前記仮想的な時間進展において、
前記格納部に格納された前記条件に基づく前記複数のプロセスに係る複数のケース間における排他待ちが発生する可能性の有無を判定する第１の判定処理を実行し、
前記第１の判定処理の実行において前記排他待ちが発生する可能性を検出すると、当該排他待ちを発生させる可能性があるケースに対して再帰的に前記第１の判定処理を実行し、
前記第１の判定処理の結果に基づき前記排他待ちの発生があると判定される場合には、当該排他待ちが発生したプロセスのケースに対して排他待ちを設定する
処理を含む実行時間推定プログラム。
【符号の説明】
【０１５９】
１１０  実行制御部
１２０  データベース
１３０  運用プロセス状態管理部
【図１】
0006369170.tif 000002
【図２】
0006369170.tif 000003
【図３】
0006369170.tif 000004
【図４】
0006369170.tif 000005
【図５】
0006369170.tif 000006
【図６】
0006369170.tif 000007
【図７】
0006369170.tif 000008
【図８】
0006369170.tif 000009
【図９】
0006369170.tif 000010
【図１０】
0006369170.tif 000011
【図１１】
0006369170.tif 000012
【図１２】
0006369170.tif 000013
【図１３】
0006369170.tif 000014
【図１４】
0006369170.tif 000015
【図１５】
0006369170.tif 000016
【図１６】
0006369170.tif 000017
【図１７】
0006369170.tif 000018
【図１８】
0006369170.tif 000019
【図１９】
0006369170.tif 000020
【図２０】
0006369170.tif 000021
【図２１】
0006369170.tif 000022
【図２２】
0006369170.tif 000023
【図２３】
0006369170.tif 000024
【図２４】
0006369170.tif 000025
【図２５】
0006369170.tif 000026
【図２６】
0006369170.tif 000027
【図２７】
0006369170.tif 000028
【図２８】
0006369170.tif 000029
【図２９】
0006369170.tif 000030
【図３０】
0006369170.tif 000031
【図３１】
0006369170.tif 000032
【図３２】
0006369170.tif 000033
【図３３】
0006369170.tif 000034
【図３４】
0006369170.tif 000035
【図３５】
0006369170.tif 000036
【図３６】
0006369170.tif 000037
【図３７】
0006369170.tif 000038
【図３８】
0006369170.tif 000039
【図３９】
0006369170.tif 000040
【図４０】
0006369170.tif 000041
【図４１】
0006369170.tif 000042
【図４２】
0006369170.tif 000043
【図４３】
0006369170.tif 000044
【図４４】
0006369170.tif 000045