(57)【要約】【課題】情報管理システムの中心となる処理手順として、簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理可能にする。【解決手段】アプリケーション１１０は、ユーザＵからの要求を受けて、制御データ１２０やワークフロー定義１４０を変更する。ワークフロー駆動部１３０は、ワークフロー定義１４０に従って、制御データ１２０を参照し、状態データ１５０を遷移させ、状態遷移の履歴をワークフロー実行履歴１６０として記録する。ワークフロー駆動部１３０はまた、制御データ１２０やワークフロー定義１４０等のデータの変更時にワークフロー実行履歴１６０を参照し、その情報の変更により影響を受ける状態を特定して、その特定された状態から、情報の変更を反映したワークフローに基づいて状態遷移を再実行する。【選択図】　図１
2004118553.tif 000002
【特許請求の範囲】
【請求項１】
ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフロー実行方法において、
前記ワークフローに影響を与える情報の変更を受け付けた場合に、前記実行履歴から前記情報の変更により影響を受ける状態を特定する状態特定ステップと、
前記特定された状態から、前記情報の変更を反映したワークフローに基づいて状態遷移を再実行する再実行ステップとを含む、
ことを特徴とするワークフロー実行方法。
【請求項２】
前記再実行された状態遷移と前記実行履歴に保存された状態遷移とを比較し、これら状態遷移の間に差がある場合は、再実行された状態遷移にかかる実行履歴を保存する履歴更新ステップを含む、
ことを特徴とする請求項１に記載のワークフロー実行方法。
【請求項３】
前記状態遷移のうち、少なくとも一つの状態から次の状態への遷移は、予め指定されたデータを参照して実行され、前記情報の変更はそのデータの変更を含む、
ことを特徴とする請求項１または請求項２に記載のワークフロー実行方法。
【請求項４】
前記ワークフローは、前記状態遷移を定義したワークフロー定義に基づいて決定され、前記情報の変更はそのワークフロー定義の変更を含む、
ことを特徴とする請求項１乃至請求項３のいずれかに記載のワークフロー実行方法。
【請求項５】
前記状態特定ステップは、前記情報の変更を受け付けた際に、前記実行履歴中に同一の状態が複数回出現する場合には、その複数回の状態のうち、最終回以外の状態が前記影響を受ける状態として特定されないように、実行履歴の調整を行う履歴調整ステップを含む、
ことを特徴とする請求項１乃至請求項４のいずれかに記載のワークフロー実行方法。
【請求項６】
ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローシステムにおいて、
前記ワークフローに影響を与える情報の変更を受け付けた場合に、前記実行履歴から前記情報の変更により影響を受ける状態を特定する状態特定手段と、
前記特定された状態から、前記情報の変更を反映したワークフローに基づいて状態遷移を再実行する再実行手段とを備えた、
ことを特徴とするワークフローシステム。
【請求項７】
ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローシステムにおいて、
状態名、次に遷移する状態の候補、遷移先を決定する条件、に関する情報を用いて前記状態遷移を定義したワークフロー定義を記憶する第１の格納部と、
前記ワークフロー定義に含まれる前記条件を評価するためのデータを記憶する第２の格納部と、
前記ワークフロー定義を用いてワークフローを特定し、前記データを参照してその特定されたワークフローに基づく状態遷移を実行する実行手段と、
前記状態遷移の実行履歴を記憶する第３の格納部とを備え、
前記実行手段は、前記ワークフロー定義もしくは前記データの少なくとも一方の情報が変更された場合に、前記実行履歴からその情報の変更により影響を受ける状態を特定し、その特定された状態から、前記情報の変更を反映したワークフローに基づいて状態遷移を再実行するように構成された、
ことを特徴とするワークフローシステム。
【請求項８】
ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローを実行するためのプログラムにおいて、
前記ワークフローに影響を与える情報の変更を受け付けた場合に、前記実行履歴から前記情報の変更により影響を受ける状態を特定する状態特定機能と、
前記特定された状態から、前記情報の変更を反映したワークフローに基づいて状態遷移を再実行する再実行機能と、
をコンピュータに実現させることを特徴とするワークフロー実行プログラム。
【請求項９】
ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローを実行するためのプログラムにおいて、
状態名、次に遷移する状態の候補、遷移先を決定する条件、に関する情報を用いて前記状態遷移を定義したワークフロー定義を記憶する第１の格納部と、前記ワークフロー定義に含まれる前記条件を評価するためのデータを記憶する第２の格納部にアクセスし、前記ワークフロー定義を用いてワークフローを特定し、前記データを参照してその特定されたワークフローに基づく状態遷移を実行する実行機能と、
前記状態遷移の実行履歴を第３の格納部に格納する履歴格納機能と、
前記ワークフロー定義もしくは前記データの少なくとも一方の情報が変更された場合に、前記第３の格納部にアクセスして前記実行履歴を参照し、その情報の変更により影響を受ける状態を特定する状態特定機能と、
前記特定された状態から、前記情報の変更を反映したワークフローに基づいて状態遷移を再実行する再実行機能と、
をコンピュータに実現させることを特徴とするワークフロー実行プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフロー実行方法とシステムに係り、特に、ソフトウェア開発における不具合管理に好適なワークフロー実行方法とシステムに関する。
【０００２】
【従来の技術】
ソフトウェア開発の分野では、想定される多様な状況において常に安定した信頼性の高い動作を行うことのできる高品質のソフトウェアを開発することが重要である。このことから、ソフトウェア開発においては、一般的に、作成したソフトウェア全体に亘って不具合の有無を詳細にチェックし、発見された不具合を修正している。このようなテスト工程においては、発見された不具合を漏れなく修正しなければならない。
【０００３】
そのためには、発見された不具合の状況、すなわち、その不具合が「修正中」なのか、「修正が終わった」のかといった状況を正確に把握し、管理する必要がある。このような活動は、一般的に、「不具合管理」と呼ばれている。この「不具合管理」は、不具合の処理手順を明確にし、個々の不具合が、手順通りに処理されているか否かを管理するものである。
【０００４】
このような「不具合管理」は、従来は、書面に不具合の情報を記入し、決められたルートで回付することで行われており、実質的に手作業主体の管理であった。しかし、近年、開発規模の増大で、不具合件数も増加しており、より効率的な不具合管理が必要となっている。その一つの解決策として、不具合管理を電子化し、大量の不具合管理を効率的に処理する不具合管理システムの導入が考えられる。
【０００５】
また、以上のような「不具合管理」において、不具合の処理手順は、組織やプロジェクトにより様々であるが、一般的には例えば、図１０に示すような手順で不具合処理が行われる。この図１０に示すように、開発者によって作成されたソフトウェアについて、その開発者またはその他の担当者により何らかの不具合が「発見」される（１０１０）と、その「発見」された不具合は、その不具合の重要度に応じて修正すべきか否かに「振分け」られる（１０２０）。なお、この場合に、一般的には、修正すべきか否かの判断だけでなく、修正担当者の振分けを行う。
【０００６】
そして、修正すべき不具合として振分けられた不具合については、開発者により「修正」される（１０３０）。なお、このような不具合の修正（１０３０）後、さらに振分けられて修正される（１０２０、１０３０）場合もある。いずれの場合でも、不具合の修正後、不具合の発見者である担当者またはその他の担当者により、不具合が修正されていることが「確認」された（１０４０）時点で、処理を完了する（１０５０）。また、「発見」された不具合の重要度が低く、特に修正する必要がない場合、仕様上の制約で不具合とならない場合、あるいは、報告済みの不具合が登録された場合等には、「ノーバグ」として、何ら対処することなしに処理を完了する（１０６０）。なお、実際上は、重要度が低くてもこの段階でノーバグにすることは稀である。
【０００７】
なお、不具合の振分けとしては、修正すべきか否かだけでなく、不具合の重要度に応じて、優先処理と一般処理に振分ける等、複数の処理への振分けを行うこともある。また、複数の開発者によりソフトウェアを協同開発する場合には、不具合の箇所や種類、重要度等に応じて複数の開発者に振分けることが多い。逆に、組織やプロジェクトによっては、「振分け」を必要としない場合もある。
【０００８】
一方、不具合が修正されていることの「確認」についても、担当者が行う場合だけでなく、担当者と管理者の二重で行われる場合もある。さらに、不具合の重要度に応じて、修正内容に対する管理者の承認を必要とする場合もある。
【０００９】
以上のように、不具合の処理手順は、組織やプロジェクトにより様々であるため、不具合の処理手順を柔軟に定義でき、その手順に従って各不具合の状態を管理する仕組みが求められている。そのような仕組みとしては、ワークフローシステムが適している。従来、ワークフローシステムに関する技術としては、実行履歴を利用して作業ステップの作業者の割り付けを自動化するワークフローシステムが提案されている（例えば、特許文献１参照）。また、実行履歴を利用して回覧ルートの動的な制御を行うもの（例えば、特許文献２参照）、プロセス定義の正当性検証のためにトレースを行うもの（例えば、特許文献３参照）、ワークフロー状態とアプリケーションの状態との整合性を維持するもの（例えば、特許文献４参照）、等も提案されている。
【００１０】
【特許文献１】
特開２０００−３３９３号公報
【特許文献２】
特開平１１−８５８７７号公報
【特許文献３】
特開平８−１９０５８７号公報
【特許文献４】
特開２０００−２９９５６号公報
【００１１】
【発明が解決しようとする課題】
しかしながら、上述したような従来のワークフローシステムは、不具合管理に利用できる反面、次のような問題点がある。
【００１２】
まず、データ変更による不整合を生じるという問題点がある。すなわち、処理手順の定義（本明細書中ではワークフロー定義と呼ぶ）によっては、分岐条件として外部情報を参照することがあるが、そのような場合に、分岐後に分岐条件として参照した外部情報がデータ変更されると、ワークフローシステムがワークフロー定義に基づいて決定した状態と参照した外部情報との間に不整合が生じてしまう。この点について、図１１のワークフロー定義を参照して説明する。
【００１３】
まず、図１１のワークフロー定義では、開発者またはその他の担当者により何らかの不具合が「発見」される（１１１０）と、その「発見」された不具合について、「振分け」（１１２０）で不具合情報の重要度を参照し、分岐先を決定するよう定義されている。このワークフロー定義に従って不具合を処理していくと、重要度が「Ａ」の不具合は「優先処理」（１１３１）に遷移し、重要度が「Ｂ」の不具合は「一般処理」（１１３２）に遷移することになる。
【００１４】
そして、これらの「優先処理」（１１３１）または「一般処理」（１１３２）で開発者により不具合が修正された後、不具合の発見者である担当者またはその他の担当者により、不具合が修正されていることが「確認」された（１１４０）時点で、処理を完了する（１１５０）。また、「発見」された不具合の重要度が低く、特に修正する必要がない場合には、「ノーバグ」として、何ら対処することなしに処理を完了する（１１６０）。
【００１５】
このような図１１のワークフロー定義において、発見された不具合は、「振分け」（１１２０）で外部情報である不具合情報の重要度が参照され、重要度が「Ａ」である場合には「優先処理」（１１３１）に遷移することになる。しかし、この場合に、外部情報である不具合情報の重要度が後から「Ｂ」に変更されると、その不具合は、本来なら「一般処理」（１１３２）に遷移すべきにも拘わらず、「優先処理」（１１３１）に遷移することになる。このように、従来のワークフローシステムにおいては、参照先の外部情報を変更すると、ワークフロー定義に基づいて決定した状態と外部情報との間に不整合が生じる可能性がある。また、ワークフロー定義の分岐条件を変更した場合にも、変更前に決定した状態と外部情報との間に同様の不整合が生じる可能性がある。
【００１６】
このようなデータ変更による不整合の問題を回避するために、外部情報を勝手に変更させず、一旦、「差戻し」等の処理を行って整合性を壊さない手順でデータを変更する方法を採用することも考えられる。しかし、この方法には、以下のデメリットがある。
（１）差戻し手順をワークフロー定義する必要があり、ワークフロー定義が複雑になる。
（２）データ変更には、「差戻し」→「再登録」という手順を踏むことから、オーバーヘッドが大きくなる。
このうち、特に、（２）のデメリットは、大量の不具合を処理しなければならない不具合管理システムでは大きな問題である。
【００１７】
なお、以上のような問題点は、ソフトウェア開発における不具合管理システムに限らず、ワークフローシステムを採用した各種の分野における情報管理システム一般に同様に存在している。
【００１８】
本発明は、上述したような従来技術の問題点を解決するために提案されたものであり、その目的は、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することである。特に、ソフトウェア開発における不具合管理システムに好適で、データ変更による不整合の問題を生じることなしに大量の不具合を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することである。
【００１９】
【課題を解決するための手段】
本発明は、状態遷移の実行時に参照するデータやワークフロー定義等の変更を受け付けた場合に、実行履歴を利用して状態遷移を再実行することにより、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理できるようにしたものである。
【００２０】
請求項１の発明は、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフロー実行方法において、状態特定ステップと再実行ステップとを含むことを特徴としている。ここで、状態特定ステップは、ワークフローに影響を与える情報の変更を受け付けた場合に、実行履歴から情報の変更により影響を受ける状態を特定するステップである。また、再実行ステップは、特定された状態から、情報の変更を反映したワークフローに基づいて状態遷移を再実行するステップである。
【００２１】
請求項６の発明は、請求項１の発明をシステムの観点から把握したものであり、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローシステムにおいて、請求項１の発明における状態特定ステップと再実行ステップに対応する状態特定手段と再実行手段を備えたことを特徴としている。
【００２２】
請求項８の発明は、請求項１、請求項６の発明をコンピュータプログラムの観点から把握したものであり、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローを実行するためのプログラムにおいて、請求項１の発明における状態特定ステップと再実行ステップに対応する状態特定機能と再実行機能をコンピュータに実現させることを特徴としている。
【００２３】
請求項２の発明は、請求項１のワークフロー実行方法において、履歴更新ステップを含むことを特徴としている。ここで、履歴更新ステップは、再実行された状態遷移と実行履歴に保存された状態遷移とを比較し、これら状態遷移の間に差がある場合は、再実行された状態遷移にかかる実行履歴を保存するステップである。
【００２４】
請求項３の発明は、請求項１または請求項２のワークフロー実行方法において、状態遷移のうち、少なくとも一つの状態から次の状態への遷移は、予め指定されたデータを参照して実行され、情報の変更はそのデータの変更を含むことを特徴としている。
請求項４の発明は、請求項１乃至請求項３のいずれかのワークフロー実行方法において、ワークフローは、状態遷移を定義したワークフロー定義に基づいて決定され、情報の変更はそのワークフロー定義の変更を含むことを特徴としている。
【００２５】
請求項７の発明は、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローシステムにおいて、第１〜第３の格納部と実行手段を備えたことを特徴としている。ここで、第１の格納部は、状態名、次に遷移する状態の候補、遷移先を決定する条件、に関する情報を用いて状態遷移を定義したワークフロー定義を記憶する格納部である。また、第２の格納部は、ワークフロー定義に含まれる条件を評価するためのデータを記憶する格納部である。また、実行手段は、ワークフロー定義を用いてワークフローを特定し、データを参照してその特定されたワークフローに基づく状態遷移を実行する手段であり、第３の格納部は、状態遷移の実行履歴を記憶する格納部である。さらに、実行手段は、ワークフロー定義もしくはデータの少なくとも一方の情報が変更された場合に、実行履歴からその情報の変更により影響を受ける状態を特定し、その特定された状態から、情報の変更を反映したワークフローに基づいて状態遷移を再実行するように構成される。
【００２６】
請求項９の発明は、請求項７の発明をコンピュータプログラムの観点から把握したものであり、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローを実行するためのプログラムにおいて、実行機能、履歴格納機能、状態特定機能、再実行機能、をコンピュータに実現させることを特徴としている。ここで、実行機能は、請求項７の発明における第１と第２の格納部に対応する各格納部にアクセスし、ワークフロー定義を用いてワークフローを特定し、データを参照してその特定されたワークフローに基づく状態遷移を実行する機能である。また、履歴格納機能は、状態遷移の実行履歴を第３の格納部に格納する機能である。また、状態特定機能は、ワークフロー定義もしくはデータの少なくとも一方の情報が変更された場合に、第３の格納部にアクセスして実行履歴を参照し、その情報の変更により影響を受ける状態を特定する機能である。さらに、再実行機能は、特定された状態から、情報の変更を反映したワークフローに基づいて状態遷移を再実行する機能である。
【００２７】
以上のような発明によれば、状態遷移の実行時に参照するデータやワークフロー定義等の情報の変更を受け付けた場合に、実行履歴を利用して状態遷移を再実行することにより、「情報の変更」を反映したワークフローに基づいて遷移先の状態を決定することができるため、決定した状態と参照先のデータとの間の整合性を維持できる。したがって、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理することができる。
【００２８】
また、再実行された状態遷移に係る実行履歴を保存することにより、保存された実行履歴と外部情報との間の整合性を維持できる。さらに、本発明による情報変更時の状態遷移の再実行は、通常の状態遷移の実行に準じた処理であるため、通常の状態遷移の実行を行う実行手段を利用して容易に実現可能である。すなわち、通常の実行手段に状態特定機能と再実行機能を持たせることにより、本発明による情報変更時の状態特定と状態遷移の再実行を容易に実現することができる。
【００２９】
請求項５の発明は、請求項１乃至請求項４のいずれかのワークフロー実行方法において、状態特定ステップが履歴調整ステップを含むことを特徴としている。ここで、履歴調整ステップは、情報の変更を受け付けた際に、実行履歴中に同一の状態が複数回出現する場合には、その複数回の状態のうち、最終回以外の状態が影響を受ける状態として特定されないように、実行履歴の調整を行うステップである。
【００３０】
この発明によれば、同じ状態が複数繰り返される場合でも、最終回１回の状態のみを特定することにより、「ワークフローに影響を与える情報の変更」を受け付けていない場合に状態遷移を再実行してしまう誤りを防止できる。すなわち、本発明においては、同じ状態が複数回繰り返され、各回の状態の遷移先が異なるような場合に、各回の状態から状態遷移を再実行すると、「ワークフローに影響を与える情報以外の情報の変更」を受け付けたにも拘わらず、「ワークフローに影響を与える情報の変更」で状態が変化したものと誤って判断してしまう可能性がある。この種の誤りは、上記のような実行履歴の調整を行うことにより、確実に防止することができる。
【００３１】
【発明の実施の形態】
以下には、本発明の実施形態を図面に沿って具体的に説明する。ただし、ここで記載する実施形態は、本発明を何ら限定するものではなく、本発明の一態様を例示するものにすぎない。
【００３２】
本発明は、典型的には、コンピュータをソフトウェアで制御することにより実現される。この場合のソフトウェアは、コンピュータのハードウェアを物理的に活用することで本発明の作用効果を実現するものであり、また、従来技術を適用可能な部分には好適な従来技術が適用される。さらに、本発明を実現するハードウェアやソフトウェアの具体的な種類や構成、ソフトウェアで処理する範囲などは自由に変更可能であり、例えば、本発明を実現するプログラムは本発明の一態様である。
【００３３】
［１．システム構成］
図１は、本発明を適用した一つの実施形態に係るワークフローシステムの構成を示すブロック図である。この図１に示すように、本実施形態におけるワークフローシステム１００は、アプリケーションプログラム１１０と組み合わされ、ソフトウェア開発における不具合管理システム等の情報管理システムを構成している。このワークフローシステム１００は、制御データ１２０、ワークフロー駆動部１３０、ワークフロー定義１４０、状態データ１５０、ワークフロー実行履歴１６０、等のプログラムやデータから構成されている。
【００３４】
これらのプログラムやデータは、コンピュータが基本的に備えているハードディスク等の記憶部に記憶されており、ＲＡＭ等の作業領域上に読み出されてＣＰＵ等の演算処理部を活用することで、ワークフローシステムの機能をコンピュータに実現させるようになっている。以下には、このワークフローシステムの構成要素について順次説明する。
【００３５】
アプリケーションプログラム（以下にはアプリケーションと略記する）１１０は、ワークフローシステム１００を利用しようとする利用者または他のシステム等のユーザＵからの要求を受けて、制御データ１２０、ワークフロー駆動部１３０、ワークフロー定義１４０等を操作するプログラムであり、制御データ１２０やワークフロー定義１４０の変更を受け付けるようになっている。
制御データ１２０は、ワークフロー駆動部１３０によりワークフロー定義の分岐条件評価時に参照されるデータであり、コンピュータの記憶部あるいは外部記憶装置における所定の格納領域（第２の格納部）に記憶されている。
【００３６】
ワークフロー駆動部１３０、ワークフロー定義１４０、状態データ１５０、ワークフロー実行履歴１６０、等のプログラムやデータの集合は、ワークフローシステムの機能をアプリケーション１１０に提供するワークフローマネージャ１７０を構成している。なお、図１中においては、ワークフローマネージャ１７０を構成するプログラムやデータが、論理的または物理的に独立して存在している場合を示しているが、これらのプログラムやデータは明確に独立せずに部分的あるいは全体的に混然一体となって存在している場合もある。すなわち、本発明のワークフローシステムを構成するプログラムやデータの具体的な構造や保存形式は何ら限定されるものではなく、多様な構造や保存形式が可能である。
【００３７】
ワークフロー駆動部１３０は、ワークフロー定義１４０に基づく状態遷移を実行するとともに、制御データ１２０やワークフロー定義１４０の変更時に状態遷移を再実行するプログラムである。すなわち、このワークフロー駆動部１３０は、ワークフロー定義１４０に従って、制御データ１２０を参照し、状態データ１５０を遷移させる実行機能と、状態遷移の履歴をワークフロー実行履歴１６０として記録する履歴格納機能を有するものである。
【００３８】
このワークフロー駆動部１３０はまた、制御データ１２０やワークフロー定義１４０等のデータの変更時にワークフロー実行履歴１６０を参照し、その情報の変更により影響を受ける状態を特定する状態特定機能と、その特定された状態から、情報の変更を反映したワークフローに基づいて状態遷移を再実行する再実行機能を有するものであり、本発明における実行手段あるいは再実行手段を構成する。
【００３９】
ワークフロー定義１４０は、状態とその遷移を定義したデータであり、各状態の定義は、状態名、遷移先の状態（次に遷移する状態の候補）、分岐条件（遷移先を決定する条件）等を含む。このワークフロー定義１４０は、コンピュータの記憶部における所定の格納領域（第１の格納部）に記憶されている。
状態データ１５０は、現在の状態を表現するデータであり、コンピュータの記憶部における所定の格納領域に記憶されている。状態データ１５０の状態は、ワークフロー定義１４０で定義されている。状態データ１５０は、制御データ１２０の一部として扱う場合もある。
【００４０】
ワークフロー実行履歴１６０は、状態遷移の履歴を記録したデータであり、制御データ１２０やワークフロー定義１４０等のデータの変更時にワークフロー駆動部１３０によりそのデータ変更による不整合を解消するための処理に利用される。このワークフロー実行履歴１６０は、コンピュータの記憶部における所定の格納領域（第３の格納部）に記憶されている。
【００４１】
［２．ワークフロー定義］
ワークフロー定義は、前述したように、状態とその遷移を定義したデータである。ここで、「状態」をその遷移に応じて大別すると、開始状態、途中状態、終了状態に分類できる。すなわち、開始状態から遷移を開始し、途中状態を経て、終了状態で遷移を終了する。なお、開始状態からそのまま終了状態に遷移する場合もある。
【００４２】
いずれの場合であれ、開始状態の定義は、少なくとも、「状態名」、「遷移先の状態」、「分岐条件」を含む。途中状態の定義も、同様に、少なくとも、「状態名」、「遷移先の状態」、「分岐条件」を含む。これに対して、遷移を終了する終了状態の定義は、少なくとも「状態名」を含む。また、ワークフロー定義に使用されるこれらの情報：（「状態名」、「遷移先の状態」、「分岐条件」）はさらに、次のように定義される。
【００４３】
「状態名」は、状態の名称を示す情報であり、実際の名称に限らず、簡略化された名称やその状態を示す番号や記号等、状態を特定可能な情報を広く含む概念である。
「遷移先の状態（以下では「遷移先」と略記する）」は、次に遷移する状態の候補を示す情報である。「遷移先」のいずれに遷移するかは、分岐条件により決定される。
「分岐条件」は、遷移する分岐先を決定するロジック（条件）である。「分岐条件」は、複雑な判断や、制御データやアプリケーションから渡されたデータの参照を含む場合がある。
【００４４】
このような、「状態名」、「遷移先の状態」、「分岐条件」等の情報によって定義される状態を組み合わせることで、様々な処理手順のワークフロー定義を行うことができる。図２は、このようなワークフロー定義の一例を示す状態遷移図である。この図２においては、１つの開始状態２１０、４つの途中状態２２１〜２２４、３つの終了状態２３１〜２３３、という合計８個の状態の遷移が表現されている。
【００４５】
この図２において、途中状態４（２２４）以外の３つの途中状態２２１〜２２３はいずれも、それぞれ２つの遷移先が定義されているため、分岐条件を評価して次の状態を決定することになる。この図２においては、一例として、途中状態１（２２１）に対して、「承認なら途中状態２へ、否認なら終了状態３へ」という分岐条件が定義され、また、途中状態２（２２２）に対して、「『金額』フィールドの値が１０万未満なら途中状態３へ、１０万以上なら途中状態４へ」という分岐条件が定義されている。
【００４６】
なお、このようなワークフロー定義は、図１に示すように、ワークフロー駆動部１３０と論理的または物理的に独立して存在している場合もあるが、ワークフロー駆動部１３０に組み込まれている場合もある。すなわち、前述したように、本発明のワークフローシステムを構成するプログラムやデータの具体的な構造や保存形式は何ら限定されるものではなく、多様な構造や保存形式が可能であるため、ワークフロー駆動部やワークフロー定義の具体的な構造や保存形式についても、多様な構造や保存形式が可能である。
【００４７】
［３．ワークフロー実行履歴］
ワークフロー実行履歴は、前述したように、状態遷移の履歴を記録したデータである。ワークフロー実行履歴としては、具体的には、「シーケンス番号」、「状態」、「アプリケーションから渡されたデータ」、「変更記録」、等の情報が記録される。また、ワークフロー実行履歴として記録されるこれらの情報：（「シーケンス番号」、「状態」、「アプリケーションから渡されたデータ」、「変更記録」）はさらに、次のように定義される。
【００４８】
「シーケンス番号」は、ワークフロー実行履歴中における状態の時間的順序を示す一意的な番号である。
「状態」は、ワークフロー実行履歴中では、通過した状態を示しており、１つのシーケンス番号に１つの状態が対応付けられる。
【００４９】
「アプリケーションから渡されたデータ」は、ワークフロー実行履歴中の各状態においてアプリケーションから渡されたデータを示しており、制御データに限らず、アプリケーションから渡された全てのデータを含む広い概念である。例えば、承認や否認などの指示は、制御データとは別にアプリケーションから一時的に渡される可能性があるが、そのようなデータを含む広い概念である。そして、「アプリケーションから渡されたデータ」の全てが、ワークフロー実行履歴の一部として記録される。
【００５０】
「変更記録」は、再実行された状態遷移の履歴が再実行前の履歴から変更した場合にその履歴の変更を示す情報である。例えば、状態遷移の再実行前において、シーケンス番号「ｎ」の状態「Ｓｎ」の遷移先は、シーケンス番号「ｎ＋１」の状態「Ｓｎ＋１」であるが、状態遷移の再実行後に、シーケンス番号「ｎ」の状態「Ｓｎ」の遷移先が、状態「Ｓｎ＋１」以外のシーケンス番号「ｍ」（ｍ＞ｎ）の状態「Ｓｍ」に変更した場合には、シーケンス番号「ｎ」の状態「Ｓｎ」の変更記録「Ａｎ」に、そのシーケンス番号「ｍ」を記録する。この場合、シーケンス番号「ｎ」の変更記録「Ａｎ」に記録されたシーケンス番号「ｍ」は、シーケンス番号「ｎ」の履歴の次の履歴がシーケンス番号「ｍ」の履歴に変更されたことを示す。
【００５１】
表１は、「シーケンス番号」、「状態」、「アプリケーションら渡されたデータ」、「変更記録」という４つの項目からなるワークフロー実行履歴を示している。この表１は、図２に示したワークフロー定義に基づいて通常の状態遷移を実行した場合のワークフロー実行履歴の一例を示しており、変更記録は空欄である。この表１の履歴は、シーケンス番号を昇順に、すなわち、１→２→３→４→５の順で遷移したことを示している。
【００５２】
【表１】
2004118553.tif 000003
【００５３】
また、表２は、表１に示すワークフロー実行履歴について、状態遷移を再実行した後に、３行目のシーケンス番号「３」の状態「途中状態２」の遷移先が変更してそのシーケンス番号「３」の変更記録に、シーケンス番号「６」が記録された一例を示している。この場合、シーケンス番号「３」の変更記録に記録されたシーケンス番号「６」は、シーケンス番号「３」の履歴の次の履歴がシーケンス番号「６」の履歴に変更されたことを示している。すなわち、この例における変更後の履歴は、１→２→３→６となる。
【００５４】
【表２】
2004118553.tif 000004
【００５５】
［４．ワークフローシステムの動作］
図３は、本実施形態におけるワークフローシステムの動作の概略を示すフローチャートである。この図３に示すように、アプリケーション１１０は、ユーザＵからのデータ登録要求を受け付けると（Ｓ３０１のＹＥＳ）、入力されたデータを制御データ１２０として記録する（Ｓ３０２）。この場合に、アプリケーション１１０は、ワークフロー駆動部１３０に状態遷移の実行を指示し、この指示に従って、ワークフロー駆動部１３０は、通常の動作である状態遷移を実行する（Ｓ３０３）。
【００５６】
これに対して、アプリケーション１１０は、ユーザＵからの、制御データ１２０またはワークフロー定義１４０の変更要求を受け付けると（Ｓ３０１のＮＯ、Ｓ３１１のＹＥＳ）、入力されたデータに応じて、制御データ１２０またはワークフロー定義１４０を更新する（Ｓ３１２）。この場合に、アプリケーション１１０は、データ変更による不整合を自動的に解消するために、ワークフロー駆動部１３０に状態遷移の再実行を指示し、この指示に従って、ワークフロー駆動部１３０は、ワークフロー実行履歴を利用して状態遷移を再実行する（Ｓ３１３）。
【００５７】
［４−１．ワークフロー駆動部の通常の動作］
図４は、ワークフロー駆動部１３０の通常の動作を示すフローチャートであり、図３に示す状態遷移の実行ステップ（Ｓ３０３）のサブルーチンに相当する。
【００５８】
この図４に示すように、ワークフロー駆動部１３０は、状態データ１５０から現在の状態を読み込む（Ｓ４０１）。ワークフロー駆動部１３０は次に、その読み込んだ状態について、ワークフロー定義１４０から、その状態の定義を読み込む（Ｓ４０２）。ワークフロー駆動部１３０は、読み込んだ状態の定義に含まれる分岐条件を評価して、評価の結果に基づき、読み込んだ状態の定義に含まれる遷移先の中から次に遷移する状態を決定する（Ｓ４０３）。この場合、分岐条件の内容に応じて、制御データ１２０やアプリケーション１１０から渡されたデータを評価に利用することもある。
【００５９】
ワークフロー駆動部１３０は、状態遷移の実行結果をワークフロー実行履歴１６０に記録する（Ｓ４０４）。すなわち、アプリケーション１１０から渡されたデータがある場合には、ワークフロー実行履歴１６０の現在の最終行にそのデータを記録すると共にさらに１行追加し、決定した遷移先の状態を記録する。また、アプリケーション１１０から渡されたデータがない場合には、ワークフロー実行履歴１６０に１行追加して決定した遷移先の状態の記録のみを行うことになる。なお、決定した遷移先の状態は、現在の状態を示す状態データ１５０にも記録される（Ｓ４０５）。
【００６０】
例えば、前記図２のワークフロー定義に基づく前記表１のワークフロー実行履歴の例において、現在の状態が２行目の状態「途中状態１」であり、アプリケーションから「承認」のデータを渡されてその「途中状態１」の状態遷移を実行し、次の遷移先を「途中状態２」に決定した際の記録処理は、次のようになる。すなわち、この場合に、ワークフロー駆動部１３０は、データ「承認」を「アプリケーションから渡されたデータ」として記録すると共に、さらに３行目を追加し、決定した遷移先の状態「途中状態２」の記録を追加することになる。
【００６１】
［４−２．ワークフロー駆動部による状態遷移の再実行］
前述したように、制御データ１２０またはワークフロー定義１４０の変更が行われた場合に、ワークフロー駆動部１３０は、データ変更による不整合を自動的に解消するために、ワークフロー実行履歴１６０を利用して状態遷移を再実行する。図５は、このようなワークフロー駆動部１３０による状態遷移を再実行するフローチャートであり、図３に示す状態遷移の再実行ステップ（Ｓ３１３）のサブルーチンに相当する。
【００６２】
この図５に示すように、ワークフロー駆動部１３０はまず、ワークフロー実行履歴１６０中に同一の状態が複数回出現する場合における状態遷移の再実行を正常に行うために、ワークフロー実行履歴の調整を行うことにより、状態遷移の再実行の対象となる実行履歴を抽出する（Ｓ５０１）。なお、このワークフロー実行履歴の調整の詳細については後述するため、ここでは説明を省略する。
【００６３】
ワークフロー駆動部１３０は次に、調整によって抽出されたワークフロー実行履歴の先頭行「ｎ」（シーケンス番号「ｋ」）に記録された履歴を読み込み（Ｓ５０２）、その履歴の状態について、ワークフロー定義１４０の中から、その状態の定義を読み込む（Ｓ５０３）。ワークフロー駆動部１３０は、読み込んだ状態の定義に含まれる分岐条件を評価し、遷移先の状態を決定する（Ｓ５０４）。ここで、分岐条件が、アプリケーション１１０から渡されたデータの参照を含む場合、状態遷移の再実行時にはアプリケーション１１０からデータを渡されないので、代わりにワークフロー実行履歴１６０に記録されている「アプリケーションから渡されたデータ」を参照する。
【００６４】
ワークフロー駆動部１３０は続いて、ワークフロー実行履歴１６０から、前回読み込んだ履歴の次の履歴を示す行を読み込む。すなわち、前回読み込んだ履歴の変更記録にシーケンス番号が記録されていない場合には、Ｓ５０２で状態を読み込んだｎ行目のシーケンス番号「ｋ」より大きく、「ｋ」に最も近いシーケンス番号「ｋ＋α」（α≧１）の行の履歴を、「次の履歴」として読み込む。これに対して、前回読み込んだ履歴の変更記録にシーケンス番号が記録されている場合には、そのシーケンス番号で示される履歴を、「次の履歴」として読み込む（Ｓ５０５）。
【００６５】
そして、Ｓ５０４の評価結果として決定した状態と、Ｓ５０５で読み込んだ履歴の状態とを比較する（Ｓ５０６）。評価結果と履歴の状態が一致している場合（Ｓ５０６のＹＥＳ）には、Ｓ５０５で読み込んだ行を未検索の先頭行「ｎ」として、Ｓ５０３から繰り返す。すなわち、Ｓ５０６の比較結果が一致している間、あるいは、ワークフロー実行履歴１６０の最後に達しない間（Ｓ５０７のＮＯ）は、Ｓ５０３〜Ｓ５０６を繰り返す。
【００６６】
ワークフロー実行履歴の最後まで比較した場合（Ｓ５０７のＹＥＳ）は、状態が変化しなかったものと判定し、何もせずに終了する。また、比較結果が一致しない場合（Ｓ５０６のＮＯ）には、状態が変化したものと判定し、ワークフロー実行記録１６０に１行追加し、Ｓ５０４の評価結果として決定した状態を記録する（Ｓ５０８）。この場合、評価した状態の行に変更記録もつける。なお、評価結果として決定した状態は、現在の状態を示す状態データ１５０にも記録される（Ｓ５０９）。
【００６７】
例えば、前記図２のワークフロー定義に基づく前記表１のワークフロー実行履歴の例において、状態遷移を再実行した場合に、３行目の状態「途中状態２」の分岐条件の評価により決定した状態が、「途中状態４」となり、ワークフロー実行履歴中における次の行（４行目）の状態「途中状態３」と一致しない場合の記録内容は、次のようになる。すなわち、この場合に、ワークフロー駆動部１３０は、表１に示すワークフロー実行記録にシーケンス番号「６」の６行目を追加し、評価結果として決定した状態「途中状態４」を記録する。この場合、評価した状態「途中状態２」の行の変更記録に、次の履歴のシーケンス番号である「６」を記録することになる。このような記録の更新により、表２に示すような変更後のワークフロー実行履歴が得られる。
【００６８】
［４−３．ワークフロー実行履歴の調整］
前述したように、ワークフロー駆動部１３０は、ワークフロー実行履歴中に同一の状態が複数回出現する場合における状態遷移の再実行を正常に行うために、ワークフロー実行履歴の調整を行う。ここではまず、同一の状態が複数回出現する場合について、すなわち、ワークフロー実行履歴の調整が必要な場合について説明する。
【００６９】
一般的に、ワークフローシステムでは、ループになったワークフロー定義をすることがある。その場合、同じ状態を何度も通る可能性があり、１回目と２回目で制御データが変更すれば遷移先が変わる可能性もある。このような場合に、ワークフロー実行履歴の先頭から検索をすると、２回目で更新されたデータを使って１回目の状態をチェックするため、状態の変更が発生したと誤認識する可能性がある。
【００７０】
この誤認識の問題について、図６に示すワークフロー定義に基づく状態遷移を、表３に示すワークフロー実行履歴で実行した場合を例に説明する。ここで、図６のワークフロー定義においては、「発見」６１０、「修正」６２０、「部長承認」６３１、「課長承認」６３２、「確認」６４０、「完了」６５０、という状態とその遷移が定義されている。このワークフロー定義の内容は次の通りである。
【００７１】
すなわち、開発者によって作成されたソフトウェアについて、状態「発見」６１０において発見された不具合は、状態「修正」６２０において開発者によって修正され、そのバグランクが登録／変更される。この場合、状態「修正」６２０には、遷移先として、状態「部長承認」６３１、「課長承認」６３２の２つが定義されており、分岐条件として、「バグランク：Ａ→部長承認、Ａ以外→課長承認」が定義されている。バグランクは、制御データの一部であり、「修正」時に開発者によって登録／変更される。これに関連して、表３のワークフロー実行履歴には、便宜的に、その時点の制御データのバグランクも併記した。
【００７２】
また、状態「部長承認」６３１、「課長承認」６３２の遷移先としては、状態「確認」６４０、「修正」６２０の２つが定義されており、分岐条件として、「承認→確認、否認→修正」が定義されている。さらに、状態「確認」６４０の遷移先としては、状態「完了」６５０、「修正」６２０の２つが定義されており、分岐条件として、「確認結果：ＯＫ→完了、ＮＧ→修正」が定義されている。確認結果は、制御データの一部であり、「確認」時に担当者によって登録／変更される。
【００７３】
【表３】
2004118553.tif 000005
【００７４】
この表３に示すワークフロー実行履歴では、１度目の「修正」時にはバグランクを「Ｂ」として登録したが、２度目の「修正」で「Ａ」に変更している。その後、分岐条件とは関係ない制御データを変更し、ワークフロー実行履歴の先頭から状態遷移を再実行すると、バグランクが「Ａ」になっているため、遷移先として「部長承認」が導き出されてしまう。この場合、ワークフロー実行履歴と状態遷移の再実行で得られた結果が異なるため、ワークフロー駆動部１３０は、データ変更で状態が変化したものと判断し、新しい状態を「部長承認」と決定してしまう。
【００７５】
次の表４は、この場合のワークフロー実行履歴と状態遷移の再実行で得られた結果の比較を示しており、「○」は一致、「×」は不一致である。しかし、本来は、分岐条件とは関係ない制御データを変更しているため、状態は変わらないはずである。
【表４】
2004118553.tif 000006
【００７６】
このように、同じ状態を複数回通っていると、状態遷移の再実行を正常に行うことができなくなるという問題を生じる。本実施形態のワークフローシステムでは、この問題を解決するために、ワークフロー実行履歴の調整を行う。具体的な調整の方法は、いくつか考えられるが、ここでは、代表的な２つの方法として、「同一の状態が複数回出現するか否かをチェックする方法」と、「ユーザに指定された状態が最後に出現する位置をチェックする方法」について説明する。
【００７７】
まず、「同一の状態が複数回出現するか否かをチェックする方法」は、ワークフロー実行履歴を先頭からチェックして、「一度出現した状態が次に出現する場合には、その前回の状態の位置から今回の状態が出現する前までの履歴を削除する」、という処理を、ワークフロー実行履歴の最後まで行う方法である。表３の例では、シーケンス番号「２」の状態「修正」が、シーケンス番号「５」にも出現するため、シーケンス番号「２」から「４」までの行を削除することになる。この結果、次の表５に示すような、調整後のワークフロー実行履歴が得られる。
【００７８】
【表５】
2004118553.tif 000007
【００７９】
この表５に示すように、ワークフロー実行履歴中に同一の状態が複数回出現する場合であっても、その複数回の状態のうち、最終回の状態のみが残るので、ワークフロー駆動部１３０は、状態遷移の再実行を正常に行うことができる。表６は、表５に示すワークフロー実行履歴を用いて状態遷移を再実行した場合における、ワークフロー実行履歴と状態遷移の再実行で得られた結果の比較を示している。
【００８０】
【表６】
2004118553.tif 000008
【００８１】
次に、「ユーザに指定された状態が最後に出現する位置をチェックする方法」は、ユーザに状態遷移の再実行を開始する状態を指定させ、ワークフロー実行履歴を最後からチェックして、その状態が出現する位置を特定し、その位置よりも前の履歴を削除する方法である。表３の例では、状態「修正」から状態遷移の再実行が指定されたとすると、ワークフロー実行履歴の最後から状態「修正」を探すことになる。シーケンス番号「５」において状態「修正」が出現するので、シーケンス番号「５」よりも前の行を削除することになる。この結果、次の表７に示すような、調整後のワークフロー実行履歴が得られる。
【００８２】
【表７】
2004118553.tif 000009
【００８３】
この表７に示すように、ワークフロー実行履歴中に同一の状態が複数回出現する場合であっても、その複数回の状態のうち、最終回の状態より前は無視するので、ワークフロー駆動部１３０は、状態遷移の再実行を正常に行うことができる。表８は、表７に示すワークフロー実行履歴を用いて状態遷移を再実行した場合における、ワークフロー実行履歴と状態遷移の再実行で得られた結果の比較を示している。
【００８４】
【表８】
2004118553.tif 000010
【００８５】
［５．ワークフロー駆動部の動作例］
以下には、具体的なワークフロー定義とワークフロー実行履歴を想定した上で、ワークフロー駆動部の具体的な動作例について説明する。まず、ワークフロー定義としては、図６に示すワークフロー定義を使用するものとする。この図６に示すワークフロー定義の内容については前述したため、ここでは説明を省略する。このワークフロー定義を用いて、状態「修正」まで遷移した時点でのワークフロー実行履歴と状態データを、次の表９、表１０に示す。
【００８６】
【表９】
2004118553.tif 000011
【表１０】
2004118553.tif 000012
【００８７】
以下の説明では、図６のワークフロー定義に基づくこの状態「修正」から通常の状態遷移を実行した場合の動作例と、その後に状態遷移を再実行した場合の動作例について、具体的な制御データ等を含めて詳細に説明する。
【００８８】
［５−１．通常の動作］
ここでは、表９、表１０に示すように、図６のワークフロー定義を用いて状態「修正」まで遷移した時点で、ユーザにより制御データが入力され、アプリケーション１１０から次の状態に遷移するように指示された場合のワークフロー駆動部１３０の動作について説明する。ワークフロー駆動部１３０の通常の動作は、前述したように、図４のフローチャートに沿って行われる。なお、ユーザから入力された制御データは、図７に示すような、「発見日時」、「発見者」、「危険度」、「バグランク」、「現象」、等の情報を含む帳票データであるものとする。
【００８９】
ワークフロー駆動部１３０はまず、状態データ１５０から現在の状態である「修正」を読み込む（Ｓ４０１）。ワークフロー駆動部１３０は次に、その読み込んだ状態「修正」について、ワークフロー定義１４０から、その状態「修正」の定義を読み込む（Ｓ４０２）。ワークフロー駆動部１３０は、読み込んだ状態「修正」の定義に含まれる分岐条件を評価して遷移先を決定する（Ｓ４０３）。この場合、状態「修正」の分岐条件は、制御データのバグランクの参照を含む。図７に示す制御データのバグランクは「Ｂ」であるため、ワークフロー駆動部１３０は、状態「課長承認」を遷移先として決定する。
【００９０】
ワークフロー駆動部１３０は、状態「課長承認」に遷移したことをワークフロー実行履歴に記録する（Ｓ４０４）。すなわち、表９に示すワークフロー実行履歴にさらにシーケンス番号「３」の行を１行追加し、決定した遷移先の状態「課長承認」を記録する。なお、決定した新しい状態「課長承認」は、現在の状態を示す状態データにも記録される（Ｓ４０５）。次の表１１、表１２は、この時点でのワークフロー実行履歴と状態データをそれぞれ示している。
【００９１】
【表１１】
2004118553.tif 000013
【表１２】
2004118553.tif 000014
【００９２】
［５−２．状態遷移の再実行］
ここでは、表１１、表１２に示すように、図６のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザにより制御データまたはワークフロー定義の変更要求が入力され、アプリケーション１１０がその変更要求に基づくデータ変更を行った際に、アプリケーション１１０からの状態遷移の再実行の指示に基づくワークフロー駆動部１３０の動作について説明する。
【００９３】
ワークフロー駆動部１３０による状態遷移の再実行は、前述したように、図５のフローチャートに沿って行われるが、その具体的な動作の流れは、制御データの変更が状態を変化させない場合、制御データの変更が状態を変化させる場合、ワークフロー定義を変更した場合、でそれぞれ異なるため、以下には、この３パターンの動作例について順次説明する。なお、ワークフロー実行履歴の調整には、前述した２つの方法のうち、「同一の状態が複数回出現するか否かをチェックする方法」を採用するものとする。
【００９４】
［５−２−１．制御データの変更が状態を変化させない場合］
ここでは、表１１、表１２に示すように、図６のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザの変更要求に基づき、アプリケーション１１０により、図７の制御データ中の「現象」のデータが、図８に示すように変更されたものとする。
【００９５】
この場合に、ワークフロー駆動部１３０はまず、ワークフロー実行履歴の調整を行うことにより、状態遷移の再実行の対象となる状態を特定する（Ｓ５０１）。この場合、表１１に示すワークフロー実行履歴を先頭からチェックしても、一度出現した状態が次に出現することはないため、この表１１に示すワークフロー実行履歴がそのまま状態遷移の再実行の対象として特定されることになる。
【００９６】
ワークフロー駆動部１３０は次に、表１１に示すワークフロー実行履歴のシーケンス番号「１」の１行目に記録された状態「発見」を読み込み（Ｓ５０２）、その状態「発見」について、図６のワークフロー定義の中から、その状態「発見」の定義を読み込む（Ｓ５０３）。ワークフロー駆動部１３０は、読み込んだ状態「発見」の定義に含まれる分岐条件を評価し、次の状態を決定する（Ｓ５０４）。この場合、状態「発見」には分岐条件がないので、無条件に次の状態「修正」が決定される。
【００９７】
ワークフロー駆動部１３０は続いて、表１１のワークフロー実行履歴から、状態「発見」を読み込んだ１行目の次の行である２行目の履歴を読み込む（Ｓ５０５）。この場合、評価結果として決定した状態と、ワークフロー実行履歴中の次の状態とを比較すると、いずれも「修正」で一致している（Ｓ５０６のＹＥＳ）ので、Ｓ５０５で読み込んだ行の状態「修正」について、図６のワークフロー定義の中から、その状態「修正」の定義を読み込む（Ｓ５０３）。
【００９８】
ワークフロー駆動部１３０は、読み込んだ状態「修正」の定義に含まれる分岐条件を評価し、次の状態を決定する（Ｓ５０４）。この場合、状態「修正」の分岐条件は、制御データのバグランクの参照を含むが、図８の制御データ中で変更されたのは「現象」のデータだけであり、バグランクは何ら変更されていないので、次の状態は「課長承認」となる。
【００９９】
ワークフロー駆動部１３０は続いて、表１１のワークフロー実行履歴から、状態「修正」を読み込んだ２行目の次の行である３行目の履歴を読み込む（Ｓ５０５）。この場合、評価結果として決定した状態と、ワークフロー実行履歴中の次の状態とを比較すると、いずれも「課長承認」で一致している（Ｓ５０６のＹＥＳ）。この場合、表１１に示すワークフロー実行履歴の最後の行に達した（Ｓ５０７のＹＥＳ）ので、状態は変化しなかったものと判断し、何もせずに終了する。
【０１００】
次の表１３は、表１１に示すワークフロー実行履歴と以上の状態遷移の再実行で得られた結果の比較を示している。
【表１３】
2004118553.tif 000015
【０１０１】
［５−２−２．制御データの変更が状態を変化させる場合］
ここでは、表１１、表１２に示すように、図６のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザの変更要求に基づき、アプリケーション１１０により、図７の制御データ中では「Ｂ」であったバグランクが、図９に示すように「Ａ」に変更されたものとする。
【０１０２】
この場合に、ワークフロー駆動部１３０はまず、ワークフロー実行履歴の調整を行うが、前述したように、表１１に示すワークフロー実行履歴を先頭からチェックしても、一度出現した状態が次に出現することはないため、この表１１に示すワークフロー実行履歴がそのまま状態遷移の再実行の対象として特定されることになる。
【０１０３】
ワークフロー駆動部１３０が、表１１に示すワークフロー実行履歴の１行目に記録された状態「発見」を読み込み、その状態「発見」の定義を読み込んで次の状態を「修正」に決定し、ワークフロー実行履歴中の次の状態と比較した後、その状態「修正」の定義を読み込むまでの動作は、前述した「制御データの変更が状態を変化させない場合」の動作と同様である。
【０１０４】
この場合、読み込んだ状態「修正」の定義に含まれる分岐条件を評価すると、図９の制御データ中でバグランクが「Ｂ」から「Ａ」に変更されているので、次の状態は「部長承認」となる（Ｓ５０４）。ワークフロー駆動部１３０は続いて、表１１のワークフロー実行履歴から、状態「修正」を読み込んだ２行目の次の行である３行目の履歴を読み込む（Ｓ５０５）。
【０１０５】
次に、評価結果として決定した状態と、ワークフロー実行履歴中の次の状態とを比較すると、決定した状態「部長承認」と履歴中の次の状態「課長承認」とは一致していない（Ｓ５０６のＮＯ）ので、状態は変化したものと判定して、表１１に示すワークフロー実行記録にシーケンス番号「４」の４行目を追加し、評価結果として決定した状態「部長承認」を記録する（Ｓ５０８）。この場合、評価した状態「修正」の行の変更記録に、次の履歴のシーケンス番号である「４」を記録する。変更後の新しいワークフロー実行履歴は、１→２→４となる。なお、評価結果として決定した状態「部長承認」は、現在の状態を示す状態データにも記録される（Ｓ５０９）。
【０１０６】
次の表１４は、表１１に示すワークフロー実行履歴と以上の状態遷移の再実行で得られた結果の比較を示している。
【表１４】
2004118553.tif 000016
【０１０７】
また、次の表１５、表１６は、以上の状態遷移の再実行で更新された変更後のワークフロー実行履歴と状態データをそれぞれ示している。
【表１５】
2004118553.tif 000017
【表１６】
2004118553.tif 000018
【０１０８】
［５−２−３．ワークフロー定義を変更した場合］
ここでは、表１１、表１２に示すように、図６のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザの変更要求に基づき、アプリケーション１１０により、図６に示すワークフロー定義中の「修正」の分岐条件が、「バグランク：Ａ→部長承認、Ａ以外→課長承認」から、「バグランク：Ａ、Ｂ→部長承認、Ａ、Ｂ以外→課長承認」に変更されたものとする。
【０１０９】
この場合に、ワークフロー駆動部１３０が、表１１に示すワークフロー実行履歴をそのまま状態遷移の再実行の対象として特定した後、ワークフロー実行履歴の１行目に記録された状態「発見」とその定義を読み込んで次の状態を「修正」に決定し、ワークフロー実行履歴中の次の状態と比較した後、状態「修正」の定義を読み込むまでの動作は、前述した「制御データの変更が状態を変化させない場合」の動作と同様である。
【０１１０】
この場合、読み込んだ状態「修正」の定義に含まれる分岐条件を評価すると、制御データ中のバグランクは「Ｂ」と変わっていないが、分岐条件自体が「バグランク：Ａ、Ｂ→部長承認、Ａ、Ｂ以外→課長承認」に変更されているので、次の状態は「部長承認」となる（Ｓ５０４）。ワークフロー駆動部１３０は続いて、表１１のワークフロー実行履歴から、状態「修正」を読み込んだ２行目の次の行である３行目の履歴を読み込み（Ｓ５０５）、評価結果として決定した状態と比較する（Ｓ５０６）。
【０１１１】
この場合、決定した状態「部長承認」と履歴中の次の状態「課長承認」とは一致していない（Ｓ５０６のＮＯ）ので、状態は変化したものと判定して、表１１に示すワークフロー実行記録にシーケンス番号「４」の４行目を追加し、評価結果として決定した状態「部長承認」を記録する（Ｓ５０８）。この場合、評価した状態「修正」の行の変更記録に、次の履歴のシーケンス番号である「４」を記録する。変更後の新しいワークフロー実行履歴は、１→２→４となる。なお、評価結果として決定した状態「部長承認」は、現在の状態を示す状態データにも記録される（Ｓ５０９）。
【０１１２】
次の表１７は、表１１に示すワークフロー実行履歴と以上の状態遷移の再実行で得られた結果の比較を示している。
【表１７】
2004118553.tif 000019
【０１１３】
また、次の表１８、表１９は、以上の状態遷移の再実行で更新された変更後のワークフロー実行履歴と状態データをそれぞれ示している。
【表１８】
2004118553.tif 000020
【表１９】
2004118553.tif 000021
【０１１４】
［６．実施形態の作用効果］
以上のような本実施形態のワークフローシステムとワークフロー実行方法によれば、状態遷移の実行時に参照する制御データやワークフロー定義等の情報の変更を受け付けた場合に、ワークフロー実行履歴を利用して状態遷移を再実行することにより、「情報の変更」を反映したワークフローに基づいて遷移先の状態を決定することができるため、決定した状態と参照先の制御データとの間の整合性を維持できる。
【０１１５】
したがって、本実施形態の手法によれば、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順をワークフローとして定義し、そのワークフロー定義に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理することができる。このような本実施形態の手法は、特に、ソフトウェア開発における不具合管理に好適であり、データ変更による不整合の問題を生じることなしに大量の不具合を効率よく適切に処理することができる。
【０１１６】
また、再実行された状態遷移に係るワークフロー実行履歴を保存することにより、保存されたワークフロー実行履歴と制御データ等の外部情報との間の整合性を維持できる。さらに、本発明による情報変更時の状態遷移の再実行は、通常の状態遷移の実行に準じた処理であるため、通常の状態遷移の実行を行うワークフロー駆動部の機能を若干変更するだけで容易に実現可能である。すなわち、通常のワークフロー駆動部に状態特定機能と再実行機能を持たせることにより、本発明による情報変更時の状態遷移の再実行を容易に実現することができる。
【０１１７】
さらに、ワークフロー実行履歴中に同じ状態が複数回出現する場合でも、ワークフロー実行履歴の調整を行い、その複数回の状態のうち、最終回の状態のみを特定して状態遷移を再実行することにより、状態遷移の再実行を正常に行うことができる。
【０１１８】
［７．他の実施形態］
なお、本発明は、前述した実施形態に限定されるものではなく、本発明の範囲内で他にも多種多様な形態が実施可能である。
【０１１９】
まず、図１に示したシステム構成や、図３〜図５に示したワークフロー実行手順は、一例にすぎず、具体的なシステム構成や実行手順は自由に変更可能である。また、図６に示したワークフロー定義や図７に示した制御データも一例にすぎず、本発明で具体的に使用するデータやプログラムを含めた具体的なデータ構造は自由に選択可能である。さらに、本発明は、前述した通り、ソフトウェア開発における不具合管理に好適であるが、それに限らず、ワークフローシステムを採用した各種の分野における情報管理システム一般に広く適用可能であり、同様に優れた効果が得られるものである。
【０１２０】
【発明の効果】
以上詳述したように、本発明によれば、状態遷移の実行時に参照するデータやワークフロー定義等の変更を受け付けた場合に、実行履歴を利用して状態遷移を再実行することにより、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することができる。
【０１２１】
したがって、本発明によれば、ソフトウェア開発における不具合管理システムに好適で、データ変更による不整合の問題を生じることなしに大量の不具合を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することができる。
【図面の簡単な説明】
【図１】本発明を適用した一つの実施形態に係るワークフローシステムの構成を示すブロック図。
【図２】図１に示すワークフローシステムで使用するワークフロー定義の一例を示す状態遷移図。
【図３】図１に示すワークフローシステムの動作の概略を示すフローチャート。
【図４】図１に示すワークフロー駆動部の通常の動作として、図３に示す状態遷移の実行ステップのサブルーチンに相当する動作を示すフローチャート。
【図５】図１に示すワークフロー駆動部のデータ変更時の動作として、図３に示す状態遷移の再実行ステップのサブルーチンに相当する動作を示すフローチャート。
【図６】図１に示すワークフローシステムで使用するワークフロー定義の一例を示す状態遷移図。
【図７】図１に示すワークフローシステムで使用する制御データの一例を示す説明図。
【図８】図７に示す制御データを変更した一例を示す説明図。
【図９】図７に示す制御データを変更した別の一例を示す説明図。
【図１０】ソフトウェア開発における不具合処理手順の一例を示す状態遷移図。
【図１１】ワークフロー定義に基づいて決定した状態と参照した外部情報との間に不整合を生じるという問題点を説明するための説明図。
【符号の説明】
１００．．．ワークフローシステム
１１０．．．アプリケーションプログラム
１２０．．．制御データ
１３０．．．ワークフロー駆動部
１４０．．．ワークフロー定義
１５０．．．状態データ
１６０．．．ワークフロー実行履歴
１７０．．．ワークフローマネージャ
Ｕ．．．ユーザ（利用者または他のシステム）
【図１】
2004118553.tif 000022
【図２】
2004118553.tif 000023
【図３】
2004118553.tif 000024
【図４】
2004118553.tif 000025
【図５】
2004118553.tif 000026
【図６】
2004118553.tif 000027
【図７】
2004118553.tif 000028
【図８】
2004118553.tif 000029
【図９】
2004118553.tif 000030
【図１０】
2004118553.tif 000031
【図１１】
2004118553.tif 000032