JP4150566B2 - ワークフロー実行方法とシステム、およびそのためのプログラム - Google Patents
ワークフロー実行方法とシステム、およびそのためのプログラム Download PDFInfo
- Publication number
- JP4150566B2 JP4150566B2 JP2002281375A JP2002281375A JP4150566B2 JP 4150566 B2 JP4150566 B2 JP 4150566B2 JP 2002281375 A JP2002281375 A JP 2002281375A JP 2002281375 A JP2002281375 A JP 2002281375A JP 4150566 B2 JP4150566 B2 JP 4150566B2
- Authority
- JP
- Japan
- Prior art keywords
- workflow
- state
- execution
- sequence number
- history
- 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.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims description 70
- 230000007704 transition Effects 0.000 claims description 162
- 230000008859 change Effects 0.000 claims description 73
- 238000013500 data storage Methods 0.000 claims description 7
- 230000007547 defect Effects 0.000 description 66
- 238000012937 correction Methods 0.000 description 40
- 238000012545 processing Methods 0.000 description 36
- 238000007726 management method Methods 0.000 description 26
- 230000008569 process Effects 0.000 description 17
- 238000011156 evaluation Methods 0.000 description 15
- 238000010586 diagram Methods 0.000 description 10
- 238000012790 confirmation Methods 0.000 description 6
- 238000012508 change request Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 238000007562 laser obscuration time method Methods 0.000 description 4
- 230000008520 organization Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000007796 conventional method Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000001174 ascending effect Effects 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Images
Landscapes
- Stored Programmes (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフロー実行方法とシステムに係り、特に、ソフトウェア開発における不具合管理に好適なワークフロー実行方法とシステムに関する。
【０００２】
【従来の技術】
ソフトウェア開発の分野では、想定される多様な状況において常に安定した信頼性の高い動作を行うことのできる高品質のソフトウェアを開発することが重要である。このことから、ソフトウェア開発においては、一般的に、作成したソフトウェア全体に亘って不具合の有無を詳細にチェックし、発見された不具合を修正している。このようなテスト工程においては、発見された不具合を漏れなく修正しなければならない。
【０００３】
そのためには、発見された不具合の状況、すなわち、その不具合が「修正中」なのか、「修正が終わった」のかといった状況を正確に把握し、管理する必要がある。このような活動は、一般的に、「不具合管理」と呼ばれている。この「不具合管理」は、不具合の処理手順を明確にし、個々の不具合が、手順通りに処理されているか否かを管理するものである。
【０００４】
このような「不具合管理」は、従来は、書面に不具合の情報を記入し、決められたルートで回付することで行われており、実質的に手作業主体の管理であった。しかし、近年、開発規模の増大で、不具合件数も増加しており、より効率的な不具合管理が必要となっている。その一つの解決策として、不具合管理を電子化し、大量の不具合管理を効率的に処理する不具合管理システムの導入が考えられる。
【０００５】
また、以上のような「不具合管理」において、不具合の処理手順は、組織やプロジェクトにより様々であるが、一般的には例えば、図１０に示すような手順で不具合処理が行われる。この図１０に示すように、開発者によって作成されたソフトウェアについて、その開発者またはその他の担当者により何らかの不具合が「発見」される（１０１０）と、その「発見」された不具合は、その不具合の重要度に応じて修正すべきか否かに「振分け」られる（１０２０）。なお、この場合に、一般的には、修正すべきか否かの判断だけでなく、修正担当者の振分けを行う。
【０００６】
そして、修正すべき不具合として振分けられた不具合については、開発者により「修正」される（１０３０）。なお、このような不具合の修正（１０３０）後、さらに振分けられて修正される（１０２０、１０３０）場合もある。いずれの場合でも、不具合の修正後、不具合の発見者である担当者またはその他の担当者により、不具合が修正されていることが「確認」された（１０４０）時点で、処理を完了する（１０５０）。また、「発見」された不具合の重要度が低く、特に修正する必要がない場合、仕様上の制約で不具合とならない場合、あるいは、報告済みの不具合が登録された場合等には、「ノーバグ」として、何ら対処することなしに処理を完了する（１０６０）。なお、実際上は、重要度が低くてもこの段階でノーバグにすることは稀である。
【０００７】
なお、不具合の振分けとしては、修正すべきか否かだけでなく、不具合の重要度に応じて、優先処理と一般処理に振分ける等、複数の処理への振分けを行うこともある。また、複数の開発者によりソフトウェアを協同開発する場合には、不具合の箇所や種類、重要度等に応じて複数の開発者に振分けることが多い。逆に、組織やプロジェクトによっては、「振分け」を必要としない場合もある。
【０００８】
一方、不具合が修正されていることの「確認」についても、担当者が行う場合だけでなく、担当者と管理者の二重で行われる場合もある。さらに、不具合の重要度に応じて、修正内容に対する管理者の承認を必要とする場合もある。
【０００９】
以上のように、不具合の処理手順は、組織やプロジェクトにより様々であるため、不具合の処理手順を柔軟に定義でき、その手順に従って各不具合の状態を管理する仕組みが求められている。そのような仕組みとしては、ワークフローシステムが適している。従来、ワークフローシステムに関する技術としては、実行履歴を利用して作業ステップの作業者の割り付けを自動化するワークフローシステムが提案されている（例えば、特許文献１参照）。また、実行履歴を利用して回覧ルートの動的な制御を行うもの（例えば、特許文献２参照）、プロセス定義の正当性検証のためにトレースを行うもの（例えば、特許文献３参照）、ワークフロー状態とアプリケーションの状態との整合性を維持するもの（例えば、特許文献４参照）、等も提案されている。
【００１０】
【特許文献１】
特開２０００−３３９３号公報
【特許文献２】
特開平１１−８５８７７号公報
【特許文献３】
特開平８−１９０５８７号公報
【特許文献４】
特開２０００−２９９５６号公報
【００１１】
【発明が解決しようとする課題】
しかしながら、上述したような従来のワークフローシステムは、不具合管理に利用できる反面、次のような問題点がある。
【００１２】
まず、データ変更による不整合を生じるという問題点がある。すなわち、処理手順の定義（本明細書中ではワークフロー定義と呼ぶ）によっては、分岐条件として外部情報を参照することがあるが、そのような場合に、分岐後に分岐条件として参照した外部情報がデータ変更されると、ワークフローシステムがワークフロー定義に基づいて決定した状態と参照した外部情報との間に不整合が生じてしまう。この点について、図１１のワークフロー定義を参照して説明する。
【００１３】
まず、図１１のワークフロー定義では、開発者またはその他の担当者により何らかの不具合が「発見」される（１１１０）と、その「発見」された不具合について、「振分け」（１１２０）で不具合情報の重要度を参照し、分岐先を決定するよう定義されている。このワークフロー定義に従って不具合を処理していくと、重要度が「Ａ」の不具合は「優先処理」（１１３１）に遷移し、重要度が「Ｂ」の不具合は「一般処理」（１１３２）に遷移することになる。
【００１４】
そして、これらの「優先処理」（１１３１）または「一般処理」（１１３２）で開発者により不具合が修正された後、不具合の発見者である担当者またはその他の担当者により、不具合が修正されていることが「確認」された（１１４０）時点で、処理を完了する（１１５０）。また、「発見」された不具合の重要度が低く、特に修正する必要がない場合には、「ノーバグ」として、何ら対処することなしに処理を完了する（１１６０）。
【００１５】
このような図１１のワークフロー定義において、発見された不具合は、「振分け」（１１２０）で外部情報である不具合情報の重要度が参照され、重要度が「Ａ」である場合には「優先処理」（１１３１）に遷移することになる。しかし、この場合に、外部情報である不具合情報の重要度が後から「Ｂ」に変更されると、その不具合は、本来なら「一般処理」（１１３２）に遷移すべきにも拘わらず、「優先処理」（１１３１）に遷移することになる。このように、従来のワークフローシステムにおいては、参照先の外部情報を変更すると、ワークフロー定義に基づいて決定した状態と外部情報との間に不整合が生じる可能性がある。また、ワークフロー定義の分岐条件を変更した場合にも、変更前に決定した状態と外部情報との間に同様の不整合が生じる可能性がある。
【００１６】
このようなデータ変更による不整合の問題を回避するために、外部情報を勝手に変更させず、一旦、「差戻し」等の処理を行って整合性を壊さない手順でデータを変更する方法を採用することも考えられる。しかし、この方法には、以下のデメリットがある。
（１）差戻し手順をワークフロー定義する必要があり、ワークフロー定義が複雑になる。
（２）データ変更には、「差戻し」→「再登録」という手順を踏むことから、オーバーヘッドが大きくなる。
このうち、特に、（２）のデメリットは、大量の不具合を処理しなければならない不具合管理システムでは大きな問題である。
【００１７】
なお、以上のような問題点は、ソフトウェア開発における不具合管理システムに限らず、ワークフローシステムを採用した各種の分野における情報管理システム一般に同様に存在している。
【００１８】
本発明は、上述したような従来技術の問題点を解決するために提案されたものであり、その目的は、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することである。特に、ソフトウェア開発における不具合管理システムに好適で、データ変更による不整合の問題を生じることなしに大量の不具合を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することである。
【００１９】
【課題を解決するための手段】
本発明は、状態遷移の実行時に参照するデータやワークフロー定義等の変更を受け付けた場合に、実行履歴を利用して状態遷移を再実行することにより、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理できるようにしたものである。
【００２０】
特に、請求項１の発明は、コンピュータ上で実行されるアプリケーションと、前記アプリケーションによって書き換え可能で、状態名、分岐条件、及びこの分岐条件に従って前記状態名から遷移する遷移先の状態名を使用して、状態とその遷移を定義したワークフロー定義の記憶部と、前記アプリケーションによって書き換え可能で、前記ワークフロー定義の分岐条件の評価時に参照される制御データの記憶部と、前記アプリケーションによって制御され、前記ワークフロー定義及び制御データに基づいて、ある状態から他の状態への遷移であるワークフローを実行させるワークフロー駆動部と、ワークフロー実行時における現在の状態名を記録した状態データの記憶部と、遷移の順番を示すシーケンス番号、状態名、アプリケーションプログラムから渡されたデータ、及び変更記録を使用して、前記ワークフロー駆動部によって実行された状態間の遷移の記録を保存するワークフロー実行履歴の記憶部とを使用したワークフロー実行方法において、前記ワークフロー駆動部が、状態データに記憶されている現在の状態を始点として、制御データを参照して分岐条件を評価し遷移先の状態名を決定することにより、ワークフローを実行するステップと、前記ワークフロー駆動部が、前記ワークフローの実行履歴を、シーケンス番号、状態名、アプリケーションプログラムから渡されたデータ、及び変更記録を使用して、記録するステップと、アプリケーションによって、前記制御データまたは分岐条件が変更された場合に、前記ワークフロー駆動部が、前記ワークフローの実行時と同様に、始点となる状態から変更後の制御データまたは分岐条件に従って、ワークフローを再実行するステップと、前記ワークフロー駆動部が、状態データに再実行後の現在の状態を記録するステップと、前記ワークフロー駆動部が、再実行ステップの実行履歴を記録し、再実行後の現在の状態をシーケンス番号と状態名を用いて実行履歴に記録するとともに、その履歴中の実行時と再実行時とで遷移先の状態が異なるシーケンス番号に対応する変更記録には遷移先に変更があったことを記録するステップと、を有するものである。
【００２１】
特に、請求項１の発明は、前記ワークフロー駆動部が、ワークフローの再実行ステップに先立ち、ワークフロー実行履歴をシーケンス番号順に検査して、そのシーケンス番号に対応して記録されている各状態名を比較して同一の状態名が発見された場合には、前記ワークフロー実行履歴の中から同一の状態名が発見されたシーケンス番号よりも前のシーケンス番号の履歴を削除するステップと、前記ワークフロー駆動部が、状態遷移の再実行ステップを、同一の状態名が発見されたシーケンス番号の状態を始点として開始することを特徴とする。
【００２２】
また、前記のような構成をワークフローシステム及びワークフロー実行プログラムとして実現したものも、本発明の一態様である。
【００２７】
以上のような発明によれば、状態遷移の実行時に参照するデータやワークフロー定義等の情報の変更を受け付けた場合に、実行履歴を利用して状態遷移を再実行することにより、「情報の変更」を反映したワークフローに基づいて遷移先の状態を決定することができるため、決定した状態と参照先のデータとの間の整合性を維持できる。したがって、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理することができる。
【００３０】
この発明によれば、同じ状態が複数繰り返される場合でも、最終回１回の状態のみを特定することにより、「ワークフローに影響を与える情報の変更」を受け付けていない場合に状態遷移を再実行してしまう誤りを防止できる。すなわち、本発明においては、同じ状態が複数回繰り返され、各回の状態の遷移先が異なるような場合に、各回の状態から状態遷移を再実行すると、「ワークフローに影響を与える情報以外の情報の変更」を受け付けたにも拘わらず、「ワークフローに影響を与える情報の変更」で状態が変化したものと誤って判断してしまう可能性がある。この種の誤りは、上記のような実行履歴の調整を行うことにより、確実に防止することができる。
【００３１】
【発明の実施の形態】
以下には、本発明の実施形態を図面に沿って具体的に説明する。ただし、ここで記載する実施形態は、本発明を何ら限定するものではなく、本発明の一態様を例示するものにすぎない。
【００３２】
本発明は、典型的には、コンピュータをソフトウェアで制御することにより実現される。この場合のソフトウェアは、コンピュータのハードウェアを物理的に活用することで本発明の作用効果を実現するものであり、また、従来技術を適用可能な部分には好適な従来技術が適用される。さらに、本発明を実現するハードウェアやソフトウェアの具体的な種類や構成、ソフトウェアで処理する範囲などは自由に変更可能であり、例えば、本発明を実現するプログラムは本発明の一態様である。
【００３３】
［１．システム構成］
図１は、本発明を適用した一つの実施形態に係るワークフローシステムの構成を示すブロック図である。この図１に示すように、本実施形態におけるワークフローシステム１００は、アプリケーションプログラム１１０と組み合わされ、ソフトウェア開発における不具合管理システム等の情報管理システムを構成している。このワークフローシステム１００は、制御データ１２０、ワークフロー駆動部１３０、ワークフロー定義１４０、状態データ１５０、ワークフロー実行履歴１６０、等のプログラムやデータから構成されている。
【００３４】
これらのプログラムやデータは、コンピュータが基本的に備えているハードディスク等の記憶部に記憶されており、ＲＡＭ等の作業領域上に読み出されてＣＰＵ等の演算処理部を活用することで、ワークフローシステムの機能をコンピュータに実現させるようになっている。以下には、このワークフローシステムの構成要素について順次説明する。
【００３５】
アプリケーションプログラム（以下にはアプリケーションと略記する）１１０は、ワークフローシステム１００を利用しようとする利用者または他のシステム等のユーザＵからの要求を受けて、制御データ１２０、ワークフロー駆動部１３０、ワークフロー定義１４０等を操作するプログラムであり、制御データ１２０やワークフロー定義１４０の変更を受け付けるようになっている。
制御データ１２０は、ワークフロー駆動部１３０によりワークフロー定義の分岐条件評価時に参照されるデータであり、コンピュータの記憶部あるいは外部記憶装置における所定の格納領域（第２の格納部）に記憶されている。
【００３６】
ワークフロー駆動部１３０、ワークフロー定義１４０、状態データ１５０、ワークフロー実行履歴１６０、等のプログラムやデータの集合は、ワークフローシステムの機能をアプリケーション１１０に提供するワークフローマネージャ１７０を構成している。なお、図１中においては、ワークフローマネージャ１７０を構成するプログラムやデータが、論理的または物理的に独立して存在している場合を示しているが、これらのプログラムやデータは明確に独立せずに部分的あるいは全体的に混然一体となって存在している場合もある。すなわち、本発明のワークフローシステムを構成するプログラムやデータの具体的な構造や保存形式は何ら限定されるものではなく、多様な構造や保存形式が可能である。
【００３７】
ワークフロー駆動部１３０は、ワークフロー定義１４０に基づく状態遷移を実行するとともに、制御データ１２０やワークフロー定義１４０の変更時に状態遷移を再実行するプログラムである。すなわち、このワークフロー駆動部１３０は、ワークフロー定義１４０に従って、制御データ１２０を参照し、状態データ１５０を遷移させる実行機能と、状態遷移の履歴をワークフロー実行履歴１６０として記録する履歴格納機能を有するものである。
【００３８】
このワークフロー駆動部１３０はまた、制御データ１２０やワークフロー定義１４０等のデータの変更時にワークフロー実行履歴１６０を参照し、その情報の変更により影響を受ける状態を特定する状態特定機能と、その特定された状態から、情報の変更を反映したワークフローに基づいて状態遷移を再実行する再実行機能を有するものであり、本発明における実行手段あるいは再実行手段を構成する。
【００３９】
ワークフロー定義１４０は、状態とその遷移を定義したデータであり、各状態の定義は、状態名、遷移先の状態（次に遷移する状態の候補）、分岐条件（遷移先を決定する条件）等を含む。このワークフロー定義１４０は、コンピュータの記憶部における所定の格納領域（第１の格納部）に記憶されている。
状態データ１５０は、現在の状態を表現するデータであり、コンピュータの記憶部における所定の格納領域に記憶されている。状態データ１５０の状態は、ワークフロー定義１４０で定義されている。状態データ１５０は、制御データ１２０の一部として扱う場合もある。
【００４０】
ワークフロー実行履歴１６０は、状態遷移の履歴を記録したデータであり、制御データ１２０やワークフロー定義１４０等のデータの変更時にワークフロー駆動部１３０によりそのデータ変更による不整合を解消するための処理に利用される。このワークフロー実行履歴１６０は、コンピュータの記憶部における所定の格納領域（第３の格納部）に記憶されている。
【００４１】
［２．ワークフロー定義］
ワークフロー定義は、前述したように、状態とその遷移を定義したデータである。ここで、「状態」をその遷移に応じて大別すると、開始状態、途中状態、終了状態に分類できる。すなわち、開始状態から遷移を開始し、途中状態を経て、終了状態で遷移を終了する。なお、開始状態からそのまま終了状態に遷移する場合もある。
【００４２】
いずれの場合であれ、開始状態の定義は、少なくとも、「状態名」、「遷移先の状態」、「分岐条件」を含む。途中状態の定義も、同様に、少なくとも、「状態名」、「遷移先の状態」、「分岐条件」を含む。これに対して、遷移を終了する終了状態の定義は、少なくとも「状態名」を含む。また、ワークフロー定義に使用されるこれらの情報：（「状態名」、「遷移先の状態」、「分岐条件」）はさらに、次のように定義される。
【００４３】
「状態名」は、状態の名称を示す情報であり、実際の名称に限らず、簡略化された名称やその状態を示す番号や記号等、状態を特定可能な情報を広く含む概念である。
「遷移先の状態（以下では「遷移先」と略記する）」は、次に遷移する状態の候補を示す情報である。「遷移先」のいずれに遷移するかは、分岐条件により決定される。
「分岐条件」は、遷移する分岐先を決定するロジック（条件）である。「分岐条件」は、複雑な判断や、制御データやアプリケーションから渡されたデータの参照を含む場合がある。
【００４４】
このような、「状態名」、「遷移先の状態」、「分岐条件」等の情報によって定義される状態を組み合わせることで、様々な処理手順のワークフロー定義を行うことができる。図２は、このようなワークフロー定義の一例を示す状態遷移図である。この図２においては、１つの開始状態２１０、４つの途中状態２２１〜２２４、３つの終了状態２３１〜２３３、という合計８個の状態の遷移が表現されている。
【００４５】
この図２において、途中状態４（２２４）以外の３つの途中状態２２１〜２２３はいずれも、それぞれ２つの遷移先が定義されているため、分岐条件を評価して次の状態を決定することになる。この図２においては、一例として、途中状態１（２２１）に対して、「承認なら途中状態２へ、否認なら終了状態３へ」という分岐条件が定義され、また、途中状態２（２２２）に対して、「『金額』フィールドの値が１０万未満なら途中状態３へ、１０万以上なら途中状態４へ」という分岐条件が定義されている。
【００４６】
なお、このようなワークフロー定義は、図１に示すように、ワークフロー駆動部１３０と論理的または物理的に独立して存在している場合もあるが、ワークフロー駆動部１３０に組み込まれている場合もある。すなわち、前述したように、本発明のワークフローシステムを構成するプログラムやデータの具体的な構造や保存形式は何ら限定されるものではなく、多様な構造や保存形式が可能であるため、ワークフロー駆動部やワークフロー定義の具体的な構造や保存形式についても、多様な構造や保存形式が可能である。
【００４７】
［３．ワークフロー実行履歴］
ワークフロー実行履歴は、前述したように、状態遷移の履歴を記録したデータである。ワークフロー実行履歴としては、具体的には、「シーケンス番号」、「状態」、「アプリケーションから渡されたデータ」、「変更記録」、等の情報が記録される。また、ワークフロー実行履歴として記録されるこれらの情報：（「シーケンス番号」、「状態」、「アプリケーションから渡されたデータ」、「変更記録」）はさらに、次のように定義される。
【００４８】
「シーケンス番号」は、ワークフロー実行履歴中における状態の時間的順序を示す一意的な番号である。
「状態」は、ワークフロー実行履歴中では、通過した状態を示しており、１つのシーケンス番号に１つの状態が対応付けられる。
【００４９】
「アプリケーションから渡されたデータ」は、ワークフロー実行履歴中の各状態においてアプリケーションから渡されたデータを示しており、制御データに限らず、アプリケーションから渡された全てのデータを含む広い概念である。例えば、承認や否認などの指示は、制御データとは別にアプリケーションから一時的に渡される可能性があるが、そのようなデータを含む広い概念である。そして、「アプリケーションから渡されたデータ」の全てが、ワークフロー実行履歴の一部として記録される。
【００５０】
「変更記録」は、再実行された状態遷移の履歴が再実行前の履歴から変更した場合にその履歴の変更を示す情報である。例えば、状態遷移の再実行前において、シーケンス番号「ｎ」の状態「Ｓn」の遷移先は、シーケンス番号「ｎ＋１」の状態「Ｓn+1」であるが、状態遷移の再実行後に、シーケンス番号「ｎ」の状態「Ｓn」の遷移先が、状態「Ｓn+1」以外のシーケンス番号「ｍ」（ｍ＞ｎ）の状態「Ｓm」に変更した場合には、シーケンス番号「ｎ」の状態「Ｓn」の変更記録「Ａn」に、そのシーケンス番号「ｍ」を記録する。この場合、シーケンス番号「ｎ」の変更記録「Ａn」に記録されたシーケンス番号「ｍ」は、シーケンス番号「ｎ」の履歴の次の履歴がシーケンス番号「ｍ」の履歴に変更されたことを示す。
【００５１】
表１は、「シーケンス番号」、「状態」、「アプリケーションら渡されたデータ」、「変更記録」という４つの項目からなるワークフロー実行履歴を示している。この表１は、図２に示したワークフロー定義に基づいて通常の状態遷移を実行した場合のワークフロー実行履歴の一例を示しており、変更記録は空欄である。この表１の履歴は、シーケンス番号を昇順に、すなわち、１→２→３→４→５の順で遷移したことを示している。
【００５２】
【表１】
【００５３】
また、表２は、表１に示すワークフロー実行履歴について、状態遷移を再実行した後に、３行目のシーケンス番号「３」の状態「途中状態２」の遷移先が変更してそのシーケンス番号「３」の変更記録に、シーケンス番号「６」が記録された一例を示している。この場合、シーケンス番号「３」の変更記録に記録されたシーケンス番号「６」は、シーケンス番号「３」の履歴の次の履歴がシーケンス番号「６」の履歴に変更されたことを示している。すなわち、この例における変更後の履歴は、１→２→３→６となる。
【００５４】
【表２】
【００５５】
［４．ワークフローシステムの動作］
図３は、本実施形態におけるワークフローシステムの動作の概略を示すフローチャートである。この図３に示すように、アプリケーション１１０は、ユーザＵからのデータ登録要求を受け付けると（Ｓ３０１のＹＥＳ）、入力されたデータを制御データ１２０として記録する（Ｓ３０２）。この場合に、アプリケーション１１０は、ワークフロー駆動部１３０に状態遷移の実行を指示し、この指示に従って、ワークフロー駆動部１３０は、通常の動作である状態遷移を実行する（Ｓ３０３）。
【００５６】
これに対して、アプリケーション１１０は、ユーザＵからの、制御データ１２０またはワークフロー定義１４０の変更要求を受け付けると（Ｓ３０１のＮＯ、Ｓ３１１のＹＥＳ）、入力されたデータに応じて、制御データ１２０またはワークフロー定義１４０を更新する（Ｓ３１２）。この場合に、アプリケーション１１０は、データ変更による不整合を自動的に解消するために、ワークフロー駆動部１３０に状態遷移の再実行を指示し、この指示に従って、ワークフロー駆動部１３０は、ワークフロー実行履歴を利用して状態遷移を再実行する（Ｓ３１３）。
【００５７】
［４−１．ワークフロー駆動部の通常の動作］
図４は、ワークフロー駆動部１３０の通常の動作を示すフローチャートであり、図３に示す状態遷移の実行ステップ（Ｓ３０３）のサブルーチンに相当する。
【００５８】
この図４に示すように、ワークフロー駆動部１３０は、状態データ１５０から現在の状態を読み込む（Ｓ４０１）。ワークフロー駆動部１３０は次に、その読み込んだ状態について、ワークフロー定義１４０から、その状態の定義を読み込む（Ｓ４０２）。ワークフロー駆動部１３０は、読み込んだ状態の定義に含まれる分岐条件を評価して、評価の結果に基づき、読み込んだ状態の定義に含まれる遷移先の中から次に遷移する状態を決定する（Ｓ４０３）。この場合、分岐条件の内容に応じて、制御データ１２０やアプリケーション１１０から渡されたデータを評価に利用することもある。
【００５９】
ワークフロー駆動部１３０は、状態遷移の実行結果をワークフロー実行履歴１６０に記録する（Ｓ４０４）。すなわち、アプリケーション１１０から渡されたデータがある場合には、ワークフロー実行履歴１６０の現在の最終行にそのデータを記録すると共にさらに１行追加し、決定した遷移先の状態を記録する。また、アプリケーション１１０から渡されたデータがない場合には、ワークフロー実行履歴１６０に１行追加して決定した遷移先の状態の記録のみを行うことになる。なお、決定した遷移先の状態は、現在の状態を示す状態データ１５０にも記録される（Ｓ４０５）。
【００６０】
例えば、前記図２のワークフロー定義に基づく前記表１のワークフロー実行履歴の例において、現在の状態が２行目の状態「途中状態１」であり、アプリケーションから「承認」のデータを渡されてその「途中状態１」の状態遷移を実行し、次の遷移先を「途中状態２」に決定した際の記録処理は、次のようになる。すなわち、この場合に、ワークフロー駆動部１３０は、データ「承認」を「アプリケーションから渡されたデータ」として記録すると共に、さらに３行目を追加し、決定した遷移先の状態「途中状態２」の記録を追加することになる。
【００６１】
［４−２．ワークフロー駆動部による状態遷移の再実行］
前述したように、制御データ１２０またはワークフロー定義１４０の変更が行われた場合に、ワークフロー駆動部１３０は、データ変更による不整合を自動的に解消するために、ワークフロー実行履歴１６０を利用して状態遷移を再実行する。図５は、このようなワークフロー駆動部１３０による状態遷移を再実行するフローチャートであり、図３に示す状態遷移の再実行ステップ（Ｓ３１３）のサブルーチンに相当する。
【００６２】
この図５に示すように、ワークフロー駆動部１３０はまず、ワークフロー実行履歴１６０中に同一の状態が複数回出現する場合における状態遷移の再実行を正常に行うために、ワークフロー実行履歴の調整を行うことにより、状態遷移の再実行の対象となる実行履歴を抽出する（Ｓ５０１）。なお、このワークフロー実行履歴の調整の詳細については後述するため、ここでは説明を省略する。
【００６３】
ワークフロー駆動部１３０は次に、調整によって抽出されたワークフロー実行履歴の先頭行「ｎ」（シーケンス番号「ｋ」）に記録された履歴を読み込み（Ｓ５０２）、その履歴の状態について、ワークフロー定義１４０の中から、その状態の定義を読み込む（Ｓ５０３）。ワークフロー駆動部１３０は、読み込んだ状態の定義に含まれる分岐条件を評価し、遷移先の状態を決定する（Ｓ５０４）。ここで、分岐条件が、アプリケーション１１０から渡されたデータの参照を含む場合、状態遷移の再実行時にはアプリケーション１１０からデータを渡されないので、代わりにワークフロー実行履歴１６０に記録されている「アプリケーションから渡されたデータ」を参照する。
【００６４】
ワークフロー駆動部１３０は続いて、ワークフロー実行履歴１６０から、前回読み込んだ履歴の次の履歴を示す行を読み込む。すなわち、前回読み込んだ履歴の変更記録にシーケンス番号が記録されていない場合には、Ｓ５０２で状態を読み込んだｎ行目のシーケンス番号「ｋ」より大きく、「ｋ」に最も近いシーケンス番号「ｋ＋α」（α≧１）の行の履歴を、「次の履歴」として読み込む。これに対して、前回読み込んだ履歴の変更記録にシーケンス番号が記録されている場合には、そのシーケンス番号で示される履歴を、「次の履歴」として読み込む（Ｓ５０５）。
【００６５】
そして、Ｓ５０４の評価結果として決定した状態と、Ｓ５０５で読み込んだ履歴の状態とを比較する（Ｓ５０６）。評価結果と履歴の状態が一致している場合（Ｓ５０６のＹＥＳ）には、Ｓ５０５で読み込んだ行を未検索の先頭行「ｎ」として、Ｓ５０３から繰り返す。すなわち、Ｓ５０６の比較結果が一致している間、あるいは、ワークフロー実行履歴１６０の最後に達しない間（Ｓ５０７のＮＯ）は、Ｓ５０３〜Ｓ５０６を繰り返す。
【００６６】
ワークフロー実行履歴の最後まで比較した場合（Ｓ５０７のＹＥＳ）は、状態が変化しなかったものと判定し、何もせずに終了する。また、比較結果が一致しない場合（Ｓ５０６のＮＯ）には、状態が変化したものと判定し、ワークフロー実行記録１６０に１行追加し、Ｓ５０４の評価結果として決定した状態を記録する（Ｓ５０８）。この場合、評価した状態の行に変更記録もつける。なお、評価結果として決定した状態は、現在の状態を示す状態データ１５０にも記録される（Ｓ５０９）。
【００６７】
例えば、前記図２のワークフロー定義に基づく前記表１のワークフロー実行履歴の例において、状態遷移を再実行した場合に、３行目の状態「途中状態２」の分岐条件の評価により決定した状態が、「途中状態４」となり、ワークフロー実行履歴中における次の行（４行目）の状態「途中状態３」と一致しない場合の記録内容は、次のようになる。すなわち、この場合に、ワークフロー駆動部１３０は、表１に示すワークフロー実行記録にシーケンス番号「６」の６行目を追加し、評価結果として決定した状態「途中状態４」を記録する。この場合、評価した状態「途中状態２」の行の変更記録に、次の履歴のシーケンス番号である「６」を記録することになる。このような記録の更新により、表２に示すような変更後のワークフロー実行履歴が得られる。
【００６８】
［４−３．ワークフロー実行履歴の調整］
前述したように、ワークフロー駆動部１３０は、ワークフロー実行履歴中に同一の状態が複数回出現する場合における状態遷移の再実行を正常に行うために、ワークフロー実行履歴の調整を行う。ここではまず、同一の状態が複数回出現する場合について、すなわち、ワークフロー実行履歴の調整が必要な場合について説明する。
【００６９】
一般的に、ワークフローシステムでは、ループになったワークフロー定義をすることがある。その場合、同じ状態を何度も通る可能性があり、１回目と２回目で制御データが変更すれば遷移先が変わる可能性もある。このような場合に、ワークフロー実行履歴の先頭から検索をすると、２回目で更新されたデータを使って１回目の状態をチェックするため、状態の変更が発生したと誤認識する可能性がある。
【００７０】
この誤認識の問題について、図６に示すワークフロー定義に基づく状態遷移を、表３に示すワークフロー実行履歴で実行した場合を例に説明する。ここで、図６のワークフロー定義においては、「発見」６１０、「修正」６２０、「部長承認」６３１、「課長承認」６３２、「確認」６４０、「完了」６５０、という状態とその遷移が定義されている。このワークフロー定義の内容は次の通りである。
【００７１】
すなわち、開発者によって作成されたソフトウェアについて、状態「発見」６１０において発見された不具合は、状態「修正」６２０において開発者によって修正され、そのバグランクが登録／変更される。この場合、状態「修正」６２０には、遷移先として、状態「部長承認」６３１、「課長承認」６３２の２つが定義されており、分岐条件として、「バグランク：Ａ→部長承認、Ａ以外→課長承認」が定義されている。バグランクは、制御データの一部であり、「修正」時に開発者によって登録／変更される。これに関連して、表３のワークフロー実行履歴には、便宜的に、その時点の制御データのバグランクも併記した。
【００７２】
また、状態「部長承認」６３１、「課長承認」６３２の遷移先としては、状態「確認」６４０、「修正」６２０の２つが定義されており、分岐条件として、「承認→確認、否認→修正」が定義されている。さらに、状態「確認」６４０の遷移先としては、状態「完了」６５０、「修正」６２０の２つが定義されており、分岐条件として、「確認結果：ＯＫ→完了、ＮＧ→修正」が定義されている。確認結果は、制御データの一部であり、「確認」時に担当者によって登録／変更される。
【００７３】
【表３】
【００７４】
この表３に示すワークフロー実行履歴では、１度目の「修正」時にはバグランクを「Ｂ」として登録したが、２度目の「修正」で「Ａ」に変更している。その後、分岐条件とは関係ない制御データを変更し、ワークフロー実行履歴の先頭から状態遷移を再実行すると、バグランクが「Ａ」になっているため、遷移先として「部長承認」が導き出されてしまう。この場合、ワークフロー実行履歴と状態遷移の再実行で得られた結果が異なるため、ワークフロー駆動部１３０は、データ変更で状態が変化したものと判断し、新しい状態を「部長承認」と決定してしまう。
【００７５】
次の表４は、この場合のワークフロー実行履歴と状態遷移の再実行で得られた結果の比較を示しており、「○」は一致、「×」は不一致である。しかし、本来は、分岐条件とは関係ない制御データを変更しているため、状態は変わらないはずである。
【表４】
【００７６】
このように、同じ状態を複数回通っていると、状態遷移の再実行を正常に行うことができなくなるという問題を生じる。本実施形態のワークフローシステムでは、この問題を解決するために、ワークフロー実行履歴の調整を行う。具体的な調整の方法は、いくつか考えられるが、ここでは、代表的な２つの方法として、「同一の状態が複数回出現するか否かをチェックする方法」と、「ユーザに指定された状態が最後に出現する位置をチェックする方法」について説明する。
【００７７】
まず、「同一の状態が複数回出現するか否かをチェックする方法」は、ワークフロー実行履歴を先頭からチェックして、「一度出現した状態が次に出現する場合には、その前回の状態の位置から今回の状態が出現する前までの履歴を削除する」、という処理を、ワークフロー実行履歴の最後まで行う方法である。表３の例では、シーケンス番号「２」の状態「修正」が、シーケンス番号「５」にも出現するため、シーケンス番号「２」から「４」までの行を削除することになる。この結果、次の表５に示すような、調整後のワークフロー実行履歴が得られる。
【００７８】
【表５】
【００７９】
この表５に示すように、ワークフロー実行履歴中に同一の状態が複数回出現する場合であっても、その複数回の状態のうち、最終回の状態のみが残るので、ワークフロー駆動部１３０は、状態遷移の再実行を正常に行うことができる。表６は、表５に示すワークフロー実行履歴を用いて状態遷移を再実行した場合における、ワークフロー実行履歴と状態遷移の再実行で得られた結果の比較を示している。
【００８０】
【表６】
【００８１】
次に、「ユーザに指定された状態が最後に出現する位置をチェックする方法」は、ユーザに状態遷移の再実行を開始する状態を指定させ、ワークフロー実行履歴を最後からチェックして、その状態が出現する位置を特定し、その位置よりも前の履歴を削除する方法である。表３の例では、状態「修正」から状態遷移の再実行が指定されたとすると、ワークフロー実行履歴の最後から状態「修正」を探すことになる。シーケンス番号「５」において状態「修正」が出現するので、シーケンス番号「５」よりも前の行を削除することになる。この結果、次の表７に示すような、調整後のワークフロー実行履歴が得られる。
【００８２】
【表７】
【００８３】
この表７に示すように、ワークフロー実行履歴中に同一の状態が複数回出現する場合であっても、その複数回の状態のうち、最終回の状態より前は無視するので、ワークフロー駆動部１３０は、状態遷移の再実行を正常に行うことができる。表８は、表７に示すワークフロー実行履歴を用いて状態遷移を再実行した場合における、ワークフロー実行履歴と状態遷移の再実行で得られた結果の比較を示している。
【００８４】
【表８】
【００８５】
［５．ワークフロー駆動部の動作例］
以下には、具体的なワークフロー定義とワークフロー実行履歴を想定した上で、ワークフロー駆動部の具体的な動作例について説明する。まず、ワークフロー定義としては、図６に示すワークフロー定義を使用するものとする。この図６に示すワークフロー定義の内容については前述したため、ここでは説明を省略する。このワークフロー定義を用いて、状態「修正」まで遷移した時点でのワークフロー実行履歴と状態データを、次の表９、表１０に示す。
【００８６】
【表９】
【表１０】
【００８７】
以下の説明では、図６のワークフロー定義に基づくこの状態「修正」から通常の状態遷移を実行した場合の動作例と、その後に状態遷移を再実行した場合の動作例について、具体的な制御データ等を含めて詳細に説明する。
【００８８】
［５−１．通常の動作］
ここでは、表９、表１０に示すように、図６のワークフロー定義を用いて状態「修正」まで遷移した時点で、ユーザにより制御データが入力され、アプリケーション１１０から次の状態に遷移するように指示された場合のワークフロー駆動部１３０の動作について説明する。ワークフロー駆動部１３０の通常の動作は、前述したように、図４のフローチャートに沿って行われる。なお、ユーザから入力された制御データは、図７に示すような、「発見日時」、「発見者」、「危険度」、「バグランク」、「現象」、等の情報を含む帳票データであるものとする。
【００８９】
ワークフロー駆動部１３０はまず、状態データ１５０から現在の状態である「修正」を読み込む（Ｓ４０１）。ワークフロー駆動部１３０は次に、その読み込んだ状態「修正」について、ワークフロー定義１４０から、その状態「修正」の定義を読み込む（Ｓ４０２）。ワークフロー駆動部１３０は、読み込んだ状態「修正」の定義に含まれる分岐条件を評価して遷移先を決定する（Ｓ４０３）。この場合、状態「修正」の分岐条件は、制御データのバグランクの参照を含む。図７に示す制御データのバグランクは「Ｂ」であるため、ワークフロー駆動部１３０は、状態「課長承認」を遷移先として決定する。
【００９０】
ワークフロー駆動部１３０は、状態「課長承認」に遷移したことをワークフロー実行履歴に記録する（Ｓ４０４）。すなわち、表９に示すワークフロー実行履歴にさらにシーケンス番号「３」の行を１行追加し、決定した遷移先の状態「課長承認」を記録する。なお、決定した新しい状態「課長承認」は、現在の状態を示す状態データにも記録される（Ｓ４０５）。次の表１１、表１２は、この時点でのワークフロー実行履歴と状態データをそれぞれ示している。
【００９１】
【表１１】
【表１２】
【００９２】
［５−２．状態遷移の再実行］
ここでは、表１１、表１２に示すように、図６のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザにより制御データまたはワークフロー定義の変更要求が入力され、アプリケーション１１０がその変更要求に基づくデータ変更を行った際に、アプリケーション１１０からの状態遷移の再実行の指示に基づくワークフロー駆動部１３０の動作について説明する。
【００９３】
ワークフロー駆動部１３０による状態遷移の再実行は、前述したように、図５のフローチャートに沿って行われるが、その具体的な動作の流れは、制御データの変更が状態を変化させない場合、制御データの変更が状態を変化させる場合、ワークフロー定義を変更した場合、でそれぞれ異なるため、以下には、この３パターンの動作例について順次説明する。なお、ワークフロー実行履歴の調整には、前述した２つの方法のうち、「同一の状態が複数回出現するか否かをチェックする方法」を採用するものとする。
【００９４】
［５−２−１．制御データの変更が状態を変化させない場合］
ここでは、表１１、表１２に示すように、図６のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザの変更要求に基づき、アプリケーション１１０により、図７の制御データ中の「現象」のデータが、図８に示すように変更されたものとする。
【００９５】
この場合に、ワークフロー駆動部１３０はまず、ワークフロー実行履歴の調整を行うことにより、状態遷移の再実行の対象となる状態を特定する（Ｓ５０１）。この場合、表１１に示すワークフロー実行履歴を先頭からチェックしても、一度出現した状態が次に出現することはないため、この表１１に示すワークフロー実行履歴がそのまま状態遷移の再実行の対象として特定されることになる。
【００９６】
ワークフロー駆動部１３０は次に、表１１に示すワークフロー実行履歴のシーケンス番号「１」の１行目に記録された状態「発見」を読み込み（Ｓ５０２）、その状態「発見」について、図６のワークフロー定義の中から、その状態「発見」の定義を読み込む（Ｓ５０３）。ワークフロー駆動部１３０は、読み込んだ状態「発見」の定義に含まれる分岐条件を評価し、次の状態を決定する（Ｓ５０４）。この場合、状態「発見」には分岐条件がないので、無条件に次の状態「修正」が決定される。
【００９７】
ワークフロー駆動部１３０は続いて、表１１のワークフロー実行履歴から、状態「発見」を読み込んだ１行目の次の行である２行目の履歴を読み込む（Ｓ５０５）。この場合、評価結果として決定した状態と、ワークフロー実行履歴中の次の状態とを比較すると、いずれも「修正」で一致している（Ｓ５０６のＹＥＳ）ので、Ｓ５０５で読み込んだ行の状態「修正」について、図６のワークフロー定義の中から、その状態「修正」の定義を読み込む（Ｓ５０３）。
【００９８】
ワークフロー駆動部１３０は、読み込んだ状態「修正」の定義に含まれる分岐条件を評価し、次の状態を決定する（Ｓ５０４）。この場合、状態「修正」の分岐条件は、制御データのバグランクの参照を含むが、図８の制御データ中で変更されたのは「現象」のデータだけであり、バグランクは何ら変更されていないので、次の状態は「課長承認」となる。
【００９９】
ワークフロー駆動部１３０は続いて、表１１のワークフロー実行履歴から、状態「修正」を読み込んだ２行目の次の行である３行目の履歴を読み込む（Ｓ５０５）。この場合、評価結果として決定した状態と、ワークフロー実行履歴中の次の状態とを比較すると、いずれも「課長承認」で一致している（Ｓ５０６のＹＥＳ）。この場合、表１１に示すワークフロー実行履歴の最後の行に達した（Ｓ５０７のＹＥＳ）ので、状態は変化しなかったものと判断し、何もせずに終了する。
【０１００】
次の表１３は、表１１に示すワークフロー実行履歴と以上の状態遷移の再実行で得られた結果の比較を示している。
【表１３】
【０１０１】
［５−２−２．制御データの変更が状態を変化させる場合］
ここでは、表１１、表１２に示すように、図６のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザの変更要求に基づき、アプリケーション１１０により、図７の制御データ中では「Ｂ」であったバグランクが、図９に示すように「Ａ」に変更されたものとする。
【０１０２】
この場合に、ワークフロー駆動部１３０はまず、ワークフロー実行履歴の調整を行うが、前述したように、表１１に示すワークフロー実行履歴を先頭からチェックしても、一度出現した状態が次に出現することはないため、この表１１に示すワークフロー実行履歴がそのまま状態遷移の再実行の対象として特定されることになる。
【０１０３】
ワークフロー駆動部１３０が、表１１に示すワークフロー実行履歴の１行目に記録された状態「発見」を読み込み、その状態「発見」の定義を読み込んで次の状態を「修正」に決定し、ワークフロー実行履歴中の次の状態と比較した後、その状態「修正」の定義を読み込むまでの動作は、前述した「制御データの変更が状態を変化させない場合」の動作と同様である。
【０１０４】
この場合、読み込んだ状態「修正」の定義に含まれる分岐条件を評価すると、図９の制御データ中でバグランクが「Ｂ」から「Ａ」に変更されているので、次の状態は「部長承認」となる（Ｓ５０４）。ワークフロー駆動部１３０は続いて、表１１のワークフロー実行履歴から、状態「修正」を読み込んだ２行目の次の行である３行目の履歴を読み込む（Ｓ５０５）。
【０１０５】
次に、評価結果として決定した状態と、ワークフロー実行履歴中の次の状態とを比較すると、決定した状態「部長承認」と履歴中の次の状態「課長承認」とは一致していない（Ｓ５０６のＮＯ）ので、状態は変化したものと判定して、表１１に示すワークフロー実行記録にシーケンス番号「４」の４行目を追加し、評価結果として決定した状態「部長承認」を記録する（Ｓ５０８）。この場合、評価した状態「修正」の行の変更記録に、次の履歴のシーケンス番号である「４」を記録する。変更後の新しいワークフロー実行履歴は、１→２→４となる。なお、評価結果として決定した状態「部長承認」は、現在の状態を示す状態データにも記録される（Ｓ５０９）。
【０１０６】
次の表１４は、表１１に示すワークフロー実行履歴と以上の状態遷移の再実行で得られた結果の比較を示している。
【表１４】
【０１０７】
また、次の表１５、表１６は、以上の状態遷移の再実行で更新された変更後のワークフロー実行履歴と状態データをそれぞれ示している。
【表１５】
【表１６】
【０１０８】
［５−２−３．ワークフロー定義を変更した場合］
ここでは、表１１、表１２に示すように、図６のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザの変更要求に基づき、アプリケーション１１０により、図６に示すワークフロー定義中の「修正」の分岐条件が、「バグランク：Ａ→部長承認、Ａ以外→課長承認」から、「バグランク：Ａ、Ｂ→部長承認、Ａ、Ｂ以外→課長承認」に変更されたものとする。
【０１０９】
この場合に、ワークフロー駆動部１３０が、表１１に示すワークフロー実行履歴をそのまま状態遷移の再実行の対象として特定した後、ワークフロー実行履歴の１行目に記録された状態「発見」とその定義を読み込んで次の状態を「修正」に決定し、ワークフロー実行履歴中の次の状態と比較した後、状態「修正」の定義を読み込むまでの動作は、前述した「制御データの変更が状態を変化させない場合」の動作と同様である。
【０１１０】
この場合、読み込んだ状態「修正」の定義に含まれる分岐条件を評価すると、制御データ中のバグランクは「Ｂ」と変わっていないが、分岐条件自体が「バグランク：Ａ、Ｂ→部長承認、Ａ、Ｂ以外→課長承認」に変更されているので、次の状態は「部長承認」となる（Ｓ５０４）。ワークフロー駆動部１３０は続いて、表１１のワークフロー実行履歴から、状態「修正」を読み込んだ２行目の次の行である３行目の履歴を読み込み（Ｓ５０５）、評価結果として決定した状態と比較する（Ｓ５０６）。
【０１１１】
この場合、決定した状態「部長承認」と履歴中の次の状態「課長承認」とは一致していない（Ｓ５０６のＮＯ）ので、状態は変化したものと判定して、表１１に示すワークフロー実行記録にシーケンス番号「４」の４行目を追加し、評価結果として決定した状態「部長承認」を記録する（Ｓ５０８）。この場合、評価した状態「修正」の行の変更記録に、次の履歴のシーケンス番号である「４」を記録する。変更後の新しいワークフロー実行履歴は、１→２→４となる。なお、評価結果として決定した状態「部長承認」は、現在の状態を示す状態データにも記録される（Ｓ５０９）。
【０１１２】
次の表１７は、表１１に示すワークフロー実行履歴と以上の状態遷移の再実行で得られた結果の比較を示している。
【表１７】
【０１１３】
また、次の表１８、表１９は、以上の状態遷移の再実行で更新された変更後のワークフロー実行履歴と状態データをそれぞれ示している。
【表１８】
【表１９】
【０１１４】
［６．実施形態の作用効果］
以上のような本実施形態のワークフローシステムとワークフロー実行方法によれば、状態遷移の実行時に参照する制御データやワークフロー定義等の情報の変更を受け付けた場合に、ワークフロー実行履歴を利用して状態遷移を再実行することにより、「情報の変更」を反映したワークフローに基づいて遷移先の状態を決定することができるため、決定した状態と参照先の制御データとの間の整合性を維持できる。
【０１１５】
したがって、本実施形態の手法によれば、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順をワークフローとして定義し、そのワークフロー定義に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理することができる。このような本実施形態の手法は、特に、ソフトウェア開発における不具合管理に好適であり、データ変更による不整合の問題を生じることなしに大量の不具合を効率よく適切に処理することができる。
【０１１６】
また、再実行された状態遷移に係るワークフロー実行履歴を保存することにより、保存されたワークフロー実行履歴と制御データ等の外部情報との間の整合性を維持できる。さらに、本発明による情報変更時の状態遷移の再実行は、通常の状態遷移の実行に準じた処理であるため、通常の状態遷移の実行を行うワークフロー駆動部の機能を若干変更するだけで容易に実現可能である。すなわち、通常のワークフロー駆動部に状態特定機能と再実行機能を持たせることにより、本発明による情報変更時の状態遷移の再実行を容易に実現することができる。
【０１１７】
さらに、ワークフロー実行履歴中に同じ状態が複数回出現する場合でも、ワークフロー実行履歴の調整を行い、その複数回の状態のうち、最終回の状態のみを特定して状態遷移を再実行することにより、状態遷移の再実行を正常に行うことができる。
【０１１８】
［７．他の実施形態］
なお、本発明は、前述した実施形態に限定されるものではなく、本発明の範囲内で他にも多種多様な形態が実施可能である。
【０１１９】
まず、図１に示したシステム構成や、図３〜図５に示したワークフロー実行手順は、一例にすぎず、具体的なシステム構成や実行手順は自由に変更可能である。また、図６に示したワークフロー定義や図７に示した制御データも一例にすぎず、本発明で具体的に使用するデータやプログラムを含めた具体的なデータ構造は自由に選択可能である。さらに、本発明は、前述した通り、ソフトウェア開発における不具合管理に好適であるが、それに限らず、ワークフローシステムを採用した各種の分野における情報管理システム一般に広く適用可能であり、同様に優れた効果が得られるものである。
【０１２０】
【発明の効果】
以上詳述したように、本発明によれば、状態遷移の実行時に参照するデータやワークフロー定義等の変更を受け付けた場合に、実行履歴を利用して状態遷移を再実行することにより、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することができる。
【０１２１】
したがって、本発明によれば、ソフトウェア開発における不具合管理システムに好適で、データ変更による不整合の問題を生じることなしに大量の不具合を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することができる。
【図面の簡単な説明】
【図１】本発明を適用した一つの実施形態に係るワークフローシステムの構成を示すブロック図。
【図２】図１に示すワークフローシステムで使用するワークフロー定義の一例を示す状態遷移図。
【図３】図１に示すワークフローシステムの動作の概略を示すフローチャート。
【図４】図１に示すワークフロー駆動部の通常の動作として、図３に示す状態遷移の実行ステップのサブルーチンに相当する動作を示すフローチャート。
【図５】図１に示すワークフロー駆動部のデータ変更時の動作として、図３に示す状態遷移の再実行ステップのサブルーチンに相当する動作を示すフローチャート。
【図６】図１に示すワークフローシステムで使用するワークフロー定義の一例を示す状態遷移図。
【図７】図１に示すワークフローシステムで使用する制御データの一例を示す説明図。
【図８】図７に示す制御データを変更した一例を示す説明図。
【図９】図７に示す制御データを変更した別の一例を示す説明図。
【図１０】ソフトウェア開発における不具合処理手順の一例を示す状態遷移図。
【図１１】ワークフロー定義に基づいて決定した状態と参照した外部情報との間に不整合を生じるという問題点を説明するための説明図。
【符号の説明】
１００...ワークフローシステム
１１０...アプリケーションプログラム
１２０...制御データ
１３０...ワークフロー駆動部
１４０...ワークフロー定義
１５０...状態データ
１６０...ワークフロー実行履歴
１７０...ワークフローマネージャ
Ｕ...ユーザ（利用者または他のシステム）
【発明の属する技術分野】
本発明は、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフロー実行方法とシステムに係り、特に、ソフトウェア開発における不具合管理に好適なワークフロー実行方法とシステムに関する。
【０００２】
【従来の技術】
ソフトウェア開発の分野では、想定される多様な状況において常に安定した信頼性の高い動作を行うことのできる高品質のソフトウェアを開発することが重要である。このことから、ソフトウェア開発においては、一般的に、作成したソフトウェア全体に亘って不具合の有無を詳細にチェックし、発見された不具合を修正している。このようなテスト工程においては、発見された不具合を漏れなく修正しなければならない。
【０００３】
そのためには、発見された不具合の状況、すなわち、その不具合が「修正中」なのか、「修正が終わった」のかといった状況を正確に把握し、管理する必要がある。このような活動は、一般的に、「不具合管理」と呼ばれている。この「不具合管理」は、不具合の処理手順を明確にし、個々の不具合が、手順通りに処理されているか否かを管理するものである。
【０００４】
このような「不具合管理」は、従来は、書面に不具合の情報を記入し、決められたルートで回付することで行われており、実質的に手作業主体の管理であった。しかし、近年、開発規模の増大で、不具合件数も増加しており、より効率的な不具合管理が必要となっている。その一つの解決策として、不具合管理を電子化し、大量の不具合管理を効率的に処理する不具合管理システムの導入が考えられる。
【０００５】
また、以上のような「不具合管理」において、不具合の処理手順は、組織やプロジェクトにより様々であるが、一般的には例えば、図１０に示すような手順で不具合処理が行われる。この図１０に示すように、開発者によって作成されたソフトウェアについて、その開発者またはその他の担当者により何らかの不具合が「発見」される（１０１０）と、その「発見」された不具合は、その不具合の重要度に応じて修正すべきか否かに「振分け」られる（１０２０）。なお、この場合に、一般的には、修正すべきか否かの判断だけでなく、修正担当者の振分けを行う。
【０００６】
そして、修正すべき不具合として振分けられた不具合については、開発者により「修正」される（１０３０）。なお、このような不具合の修正（１０３０）後、さらに振分けられて修正される（１０２０、１０３０）場合もある。いずれの場合でも、不具合の修正後、不具合の発見者である担当者またはその他の担当者により、不具合が修正されていることが「確認」された（１０４０）時点で、処理を完了する（１０５０）。また、「発見」された不具合の重要度が低く、特に修正する必要がない場合、仕様上の制約で不具合とならない場合、あるいは、報告済みの不具合が登録された場合等には、「ノーバグ」として、何ら対処することなしに処理を完了する（１０６０）。なお、実際上は、重要度が低くてもこの段階でノーバグにすることは稀である。
【０００７】
なお、不具合の振分けとしては、修正すべきか否かだけでなく、不具合の重要度に応じて、優先処理と一般処理に振分ける等、複数の処理への振分けを行うこともある。また、複数の開発者によりソフトウェアを協同開発する場合には、不具合の箇所や種類、重要度等に応じて複数の開発者に振分けることが多い。逆に、組織やプロジェクトによっては、「振分け」を必要としない場合もある。
【０００８】
一方、不具合が修正されていることの「確認」についても、担当者が行う場合だけでなく、担当者と管理者の二重で行われる場合もある。さらに、不具合の重要度に応じて、修正内容に対する管理者の承認を必要とする場合もある。
【０００９】
以上のように、不具合の処理手順は、組織やプロジェクトにより様々であるため、不具合の処理手順を柔軟に定義でき、その手順に従って各不具合の状態を管理する仕組みが求められている。そのような仕組みとしては、ワークフローシステムが適している。従来、ワークフローシステムに関する技術としては、実行履歴を利用して作業ステップの作業者の割り付けを自動化するワークフローシステムが提案されている（例えば、特許文献１参照）。また、実行履歴を利用して回覧ルートの動的な制御を行うもの（例えば、特許文献２参照）、プロセス定義の正当性検証のためにトレースを行うもの（例えば、特許文献３参照）、ワークフロー状態とアプリケーションの状態との整合性を維持するもの（例えば、特許文献４参照）、等も提案されている。
【００１０】
【特許文献１】
特開２０００−３３９３号公報
【特許文献２】
特開平１１−８５８７７号公報
【特許文献３】
特開平８−１９０５８７号公報
【特許文献４】
特開２０００−２９９５６号公報
【００１１】
【発明が解決しようとする課題】
しかしながら、上述したような従来のワークフローシステムは、不具合管理に利用できる反面、次のような問題点がある。
【００１２】
まず、データ変更による不整合を生じるという問題点がある。すなわち、処理手順の定義（本明細書中ではワークフロー定義と呼ぶ）によっては、分岐条件として外部情報を参照することがあるが、そのような場合に、分岐後に分岐条件として参照した外部情報がデータ変更されると、ワークフローシステムがワークフロー定義に基づいて決定した状態と参照した外部情報との間に不整合が生じてしまう。この点について、図１１のワークフロー定義を参照して説明する。
【００１３】
まず、図１１のワークフロー定義では、開発者またはその他の担当者により何らかの不具合が「発見」される（１１１０）と、その「発見」された不具合について、「振分け」（１１２０）で不具合情報の重要度を参照し、分岐先を決定するよう定義されている。このワークフロー定義に従って不具合を処理していくと、重要度が「Ａ」の不具合は「優先処理」（１１３１）に遷移し、重要度が「Ｂ」の不具合は「一般処理」（１１３２）に遷移することになる。
【００１４】
そして、これらの「優先処理」（１１３１）または「一般処理」（１１３２）で開発者により不具合が修正された後、不具合の発見者である担当者またはその他の担当者により、不具合が修正されていることが「確認」された（１１４０）時点で、処理を完了する（１１５０）。また、「発見」された不具合の重要度が低く、特に修正する必要がない場合には、「ノーバグ」として、何ら対処することなしに処理を完了する（１１６０）。
【００１５】
このような図１１のワークフロー定義において、発見された不具合は、「振分け」（１１２０）で外部情報である不具合情報の重要度が参照され、重要度が「Ａ」である場合には「優先処理」（１１３１）に遷移することになる。しかし、この場合に、外部情報である不具合情報の重要度が後から「Ｂ」に変更されると、その不具合は、本来なら「一般処理」（１１３２）に遷移すべきにも拘わらず、「優先処理」（１１３１）に遷移することになる。このように、従来のワークフローシステムにおいては、参照先の外部情報を変更すると、ワークフロー定義に基づいて決定した状態と外部情報との間に不整合が生じる可能性がある。また、ワークフロー定義の分岐条件を変更した場合にも、変更前に決定した状態と外部情報との間に同様の不整合が生じる可能性がある。
【００１６】
このようなデータ変更による不整合の問題を回避するために、外部情報を勝手に変更させず、一旦、「差戻し」等の処理を行って整合性を壊さない手順でデータを変更する方法を採用することも考えられる。しかし、この方法には、以下のデメリットがある。
（１）差戻し手順をワークフロー定義する必要があり、ワークフロー定義が複雑になる。
（２）データ変更には、「差戻し」→「再登録」という手順を踏むことから、オーバーヘッドが大きくなる。
このうち、特に、（２）のデメリットは、大量の不具合を処理しなければならない不具合管理システムでは大きな問題である。
【００１７】
なお、以上のような問題点は、ソフトウェア開発における不具合管理システムに限らず、ワークフローシステムを採用した各種の分野における情報管理システム一般に同様に存在している。
【００１８】
本発明は、上述したような従来技術の問題点を解決するために提案されたものであり、その目的は、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することである。特に、ソフトウェア開発における不具合管理システムに好適で、データ変更による不整合の問題を生じることなしに大量の不具合を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することである。
【００１９】
【課題を解決するための手段】
本発明は、状態遷移の実行時に参照するデータやワークフロー定義等の変更を受け付けた場合に、実行履歴を利用して状態遷移を再実行することにより、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理できるようにしたものである。
【００２０】
特に、請求項１の発明は、コンピュータ上で実行されるアプリケーションと、前記アプリケーションによって書き換え可能で、状態名、分岐条件、及びこの分岐条件に従って前記状態名から遷移する遷移先の状態名を使用して、状態とその遷移を定義したワークフロー定義の記憶部と、前記アプリケーションによって書き換え可能で、前記ワークフロー定義の分岐条件の評価時に参照される制御データの記憶部と、前記アプリケーションによって制御され、前記ワークフロー定義及び制御データに基づいて、ある状態から他の状態への遷移であるワークフローを実行させるワークフロー駆動部と、ワークフロー実行時における現在の状態名を記録した状態データの記憶部と、遷移の順番を示すシーケンス番号、状態名、アプリケーションプログラムから渡されたデータ、及び変更記録を使用して、前記ワークフロー駆動部によって実行された状態間の遷移の記録を保存するワークフロー実行履歴の記憶部とを使用したワークフロー実行方法において、前記ワークフロー駆動部が、状態データに記憶されている現在の状態を始点として、制御データを参照して分岐条件を評価し遷移先の状態名を決定することにより、ワークフローを実行するステップと、前記ワークフロー駆動部が、前記ワークフローの実行履歴を、シーケンス番号、状態名、アプリケーションプログラムから渡されたデータ、及び変更記録を使用して、記録するステップと、アプリケーションによって、前記制御データまたは分岐条件が変更された場合に、前記ワークフロー駆動部が、前記ワークフローの実行時と同様に、始点となる状態から変更後の制御データまたは分岐条件に従って、ワークフローを再実行するステップと、前記ワークフロー駆動部が、状態データに再実行後の現在の状態を記録するステップと、前記ワークフロー駆動部が、再実行ステップの実行履歴を記録し、再実行後の現在の状態をシーケンス番号と状態名を用いて実行履歴に記録するとともに、その履歴中の実行時と再実行時とで遷移先の状態が異なるシーケンス番号に対応する変更記録には遷移先に変更があったことを記録するステップと、を有するものである。
【００２１】
特に、請求項１の発明は、前記ワークフロー駆動部が、ワークフローの再実行ステップに先立ち、ワークフロー実行履歴をシーケンス番号順に検査して、そのシーケンス番号に対応して記録されている各状態名を比較して同一の状態名が発見された場合には、前記ワークフロー実行履歴の中から同一の状態名が発見されたシーケンス番号よりも前のシーケンス番号の履歴を削除するステップと、前記ワークフロー駆動部が、状態遷移の再実行ステップを、同一の状態名が発見されたシーケンス番号の状態を始点として開始することを特徴とする。
【００２２】
また、前記のような構成をワークフローシステム及びワークフロー実行プログラムとして実現したものも、本発明の一態様である。
【００２７】
以上のような発明によれば、状態遷移の実行時に参照するデータやワークフロー定義等の情報の変更を受け付けた場合に、実行履歴を利用して状態遷移を再実行することにより、「情報の変更」を反映したワークフローに基づいて遷移先の状態を決定することができるため、決定した状態と参照先のデータとの間の整合性を維持できる。したがって、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理することができる。
【００３０】
この発明によれば、同じ状態が複数繰り返される場合でも、最終回１回の状態のみを特定することにより、「ワークフローに影響を与える情報の変更」を受け付けていない場合に状態遷移を再実行してしまう誤りを防止できる。すなわち、本発明においては、同じ状態が複数回繰り返され、各回の状態の遷移先が異なるような場合に、各回の状態から状態遷移を再実行すると、「ワークフローに影響を与える情報以外の情報の変更」を受け付けたにも拘わらず、「ワークフローに影響を与える情報の変更」で状態が変化したものと誤って判断してしまう可能性がある。この種の誤りは、上記のような実行履歴の調整を行うことにより、確実に防止することができる。
【００３１】
【発明の実施の形態】
以下には、本発明の実施形態を図面に沿って具体的に説明する。ただし、ここで記載する実施形態は、本発明を何ら限定するものではなく、本発明の一態様を例示するものにすぎない。
【００３２】
本発明は、典型的には、コンピュータをソフトウェアで制御することにより実現される。この場合のソフトウェアは、コンピュータのハードウェアを物理的に活用することで本発明の作用効果を実現するものであり、また、従来技術を適用可能な部分には好適な従来技術が適用される。さらに、本発明を実現するハードウェアやソフトウェアの具体的な種類や構成、ソフトウェアで処理する範囲などは自由に変更可能であり、例えば、本発明を実現するプログラムは本発明の一態様である。
【００３３】
［１．システム構成］
図１は、本発明を適用した一つの実施形態に係るワークフローシステムの構成を示すブロック図である。この図１に示すように、本実施形態におけるワークフローシステム１００は、アプリケーションプログラム１１０と組み合わされ、ソフトウェア開発における不具合管理システム等の情報管理システムを構成している。このワークフローシステム１００は、制御データ１２０、ワークフロー駆動部１３０、ワークフロー定義１４０、状態データ１５０、ワークフロー実行履歴１６０、等のプログラムやデータから構成されている。
【００３４】
これらのプログラムやデータは、コンピュータが基本的に備えているハードディスク等の記憶部に記憶されており、ＲＡＭ等の作業領域上に読み出されてＣＰＵ等の演算処理部を活用することで、ワークフローシステムの機能をコンピュータに実現させるようになっている。以下には、このワークフローシステムの構成要素について順次説明する。
【００３５】
アプリケーションプログラム（以下にはアプリケーションと略記する）１１０は、ワークフローシステム１００を利用しようとする利用者または他のシステム等のユーザＵからの要求を受けて、制御データ１２０、ワークフロー駆動部１３０、ワークフロー定義１４０等を操作するプログラムであり、制御データ１２０やワークフロー定義１４０の変更を受け付けるようになっている。
制御データ１２０は、ワークフロー駆動部１３０によりワークフロー定義の分岐条件評価時に参照されるデータであり、コンピュータの記憶部あるいは外部記憶装置における所定の格納領域（第２の格納部）に記憶されている。
【００３６】
ワークフロー駆動部１３０、ワークフロー定義１４０、状態データ１５０、ワークフロー実行履歴１６０、等のプログラムやデータの集合は、ワークフローシステムの機能をアプリケーション１１０に提供するワークフローマネージャ１７０を構成している。なお、図１中においては、ワークフローマネージャ１７０を構成するプログラムやデータが、論理的または物理的に独立して存在している場合を示しているが、これらのプログラムやデータは明確に独立せずに部分的あるいは全体的に混然一体となって存在している場合もある。すなわち、本発明のワークフローシステムを構成するプログラムやデータの具体的な構造や保存形式は何ら限定されるものではなく、多様な構造や保存形式が可能である。
【００３７】
ワークフロー駆動部１３０は、ワークフロー定義１４０に基づく状態遷移を実行するとともに、制御データ１２０やワークフロー定義１４０の変更時に状態遷移を再実行するプログラムである。すなわち、このワークフロー駆動部１３０は、ワークフロー定義１４０に従って、制御データ１２０を参照し、状態データ１５０を遷移させる実行機能と、状態遷移の履歴をワークフロー実行履歴１６０として記録する履歴格納機能を有するものである。
【００３８】
このワークフロー駆動部１３０はまた、制御データ１２０やワークフロー定義１４０等のデータの変更時にワークフロー実行履歴１６０を参照し、その情報の変更により影響を受ける状態を特定する状態特定機能と、その特定された状態から、情報の変更を反映したワークフローに基づいて状態遷移を再実行する再実行機能を有するものであり、本発明における実行手段あるいは再実行手段を構成する。
【００３９】
ワークフロー定義１４０は、状態とその遷移を定義したデータであり、各状態の定義は、状態名、遷移先の状態（次に遷移する状態の候補）、分岐条件（遷移先を決定する条件）等を含む。このワークフロー定義１４０は、コンピュータの記憶部における所定の格納領域（第１の格納部）に記憶されている。
状態データ１５０は、現在の状態を表現するデータであり、コンピュータの記憶部における所定の格納領域に記憶されている。状態データ１５０の状態は、ワークフロー定義１４０で定義されている。状態データ１５０は、制御データ１２０の一部として扱う場合もある。
【００４０】
ワークフロー実行履歴１６０は、状態遷移の履歴を記録したデータであり、制御データ１２０やワークフロー定義１４０等のデータの変更時にワークフロー駆動部１３０によりそのデータ変更による不整合を解消するための処理に利用される。このワークフロー実行履歴１６０は、コンピュータの記憶部における所定の格納領域（第３の格納部）に記憶されている。
【００４１】
［２．ワークフロー定義］
ワークフロー定義は、前述したように、状態とその遷移を定義したデータである。ここで、「状態」をその遷移に応じて大別すると、開始状態、途中状態、終了状態に分類できる。すなわち、開始状態から遷移を開始し、途中状態を経て、終了状態で遷移を終了する。なお、開始状態からそのまま終了状態に遷移する場合もある。
【００４２】
いずれの場合であれ、開始状態の定義は、少なくとも、「状態名」、「遷移先の状態」、「分岐条件」を含む。途中状態の定義も、同様に、少なくとも、「状態名」、「遷移先の状態」、「分岐条件」を含む。これに対して、遷移を終了する終了状態の定義は、少なくとも「状態名」を含む。また、ワークフロー定義に使用されるこれらの情報：（「状態名」、「遷移先の状態」、「分岐条件」）はさらに、次のように定義される。
【００４３】
「状態名」は、状態の名称を示す情報であり、実際の名称に限らず、簡略化された名称やその状態を示す番号や記号等、状態を特定可能な情報を広く含む概念である。
「遷移先の状態（以下では「遷移先」と略記する）」は、次に遷移する状態の候補を示す情報である。「遷移先」のいずれに遷移するかは、分岐条件により決定される。
「分岐条件」は、遷移する分岐先を決定するロジック（条件）である。「分岐条件」は、複雑な判断や、制御データやアプリケーションから渡されたデータの参照を含む場合がある。
【００４４】
このような、「状態名」、「遷移先の状態」、「分岐条件」等の情報によって定義される状態を組み合わせることで、様々な処理手順のワークフロー定義を行うことができる。図２は、このようなワークフロー定義の一例を示す状態遷移図である。この図２においては、１つの開始状態２１０、４つの途中状態２２１〜２２４、３つの終了状態２３１〜２３３、という合計８個の状態の遷移が表現されている。
【００４５】
この図２において、途中状態４（２２４）以外の３つの途中状態２２１〜２２３はいずれも、それぞれ２つの遷移先が定義されているため、分岐条件を評価して次の状態を決定することになる。この図２においては、一例として、途中状態１（２２１）に対して、「承認なら途中状態２へ、否認なら終了状態３へ」という分岐条件が定義され、また、途中状態２（２２２）に対して、「『金額』フィールドの値が１０万未満なら途中状態３へ、１０万以上なら途中状態４へ」という分岐条件が定義されている。
【００４６】
なお、このようなワークフロー定義は、図１に示すように、ワークフロー駆動部１３０と論理的または物理的に独立して存在している場合もあるが、ワークフロー駆動部１３０に組み込まれている場合もある。すなわち、前述したように、本発明のワークフローシステムを構成するプログラムやデータの具体的な構造や保存形式は何ら限定されるものではなく、多様な構造や保存形式が可能であるため、ワークフロー駆動部やワークフロー定義の具体的な構造や保存形式についても、多様な構造や保存形式が可能である。
【００４７】
［３．ワークフロー実行履歴］
ワークフロー実行履歴は、前述したように、状態遷移の履歴を記録したデータである。ワークフロー実行履歴としては、具体的には、「シーケンス番号」、「状態」、「アプリケーションから渡されたデータ」、「変更記録」、等の情報が記録される。また、ワークフロー実行履歴として記録されるこれらの情報：（「シーケンス番号」、「状態」、「アプリケーションから渡されたデータ」、「変更記録」）はさらに、次のように定義される。
【００４８】
「シーケンス番号」は、ワークフロー実行履歴中における状態の時間的順序を示す一意的な番号である。
「状態」は、ワークフロー実行履歴中では、通過した状態を示しており、１つのシーケンス番号に１つの状態が対応付けられる。
【００４９】
「アプリケーションから渡されたデータ」は、ワークフロー実行履歴中の各状態においてアプリケーションから渡されたデータを示しており、制御データに限らず、アプリケーションから渡された全てのデータを含む広い概念である。例えば、承認や否認などの指示は、制御データとは別にアプリケーションから一時的に渡される可能性があるが、そのようなデータを含む広い概念である。そして、「アプリケーションから渡されたデータ」の全てが、ワークフロー実行履歴の一部として記録される。
【００５０】
「変更記録」は、再実行された状態遷移の履歴が再実行前の履歴から変更した場合にその履歴の変更を示す情報である。例えば、状態遷移の再実行前において、シーケンス番号「ｎ」の状態「Ｓn」の遷移先は、シーケンス番号「ｎ＋１」の状態「Ｓn+1」であるが、状態遷移の再実行後に、シーケンス番号「ｎ」の状態「Ｓn」の遷移先が、状態「Ｓn+1」以外のシーケンス番号「ｍ」（ｍ＞ｎ）の状態「Ｓm」に変更した場合には、シーケンス番号「ｎ」の状態「Ｓn」の変更記録「Ａn」に、そのシーケンス番号「ｍ」を記録する。この場合、シーケンス番号「ｎ」の変更記録「Ａn」に記録されたシーケンス番号「ｍ」は、シーケンス番号「ｎ」の履歴の次の履歴がシーケンス番号「ｍ」の履歴に変更されたことを示す。
【００５１】
表１は、「シーケンス番号」、「状態」、「アプリケーションら渡されたデータ」、「変更記録」という４つの項目からなるワークフロー実行履歴を示している。この表１は、図２に示したワークフロー定義に基づいて通常の状態遷移を実行した場合のワークフロー実行履歴の一例を示しており、変更記録は空欄である。この表１の履歴は、シーケンス番号を昇順に、すなわち、１→２→３→４→５の順で遷移したことを示している。
【００５２】
【表１】
また、表２は、表１に示すワークフロー実行履歴について、状態遷移を再実行した後に、３行目のシーケンス番号「３」の状態「途中状態２」の遷移先が変更してそのシーケンス番号「３」の変更記録に、シーケンス番号「６」が記録された一例を示している。この場合、シーケンス番号「３」の変更記録に記録されたシーケンス番号「６」は、シーケンス番号「３」の履歴の次の履歴がシーケンス番号「６」の履歴に変更されたことを示している。すなわち、この例における変更後の履歴は、１→２→３→６となる。
【００５４】
【表２】
［４．ワークフローシステムの動作］
図３は、本実施形態におけるワークフローシステムの動作の概略を示すフローチャートである。この図３に示すように、アプリケーション１１０は、ユーザＵからのデータ登録要求を受け付けると（Ｓ３０１のＹＥＳ）、入力されたデータを制御データ１２０として記録する（Ｓ３０２）。この場合に、アプリケーション１１０は、ワークフロー駆動部１３０に状態遷移の実行を指示し、この指示に従って、ワークフロー駆動部１３０は、通常の動作である状態遷移を実行する（Ｓ３０３）。
【００５６】
これに対して、アプリケーション１１０は、ユーザＵからの、制御データ１２０またはワークフロー定義１４０の変更要求を受け付けると（Ｓ３０１のＮＯ、Ｓ３１１のＹＥＳ）、入力されたデータに応じて、制御データ１２０またはワークフロー定義１４０を更新する（Ｓ３１２）。この場合に、アプリケーション１１０は、データ変更による不整合を自動的に解消するために、ワークフロー駆動部１３０に状態遷移の再実行を指示し、この指示に従って、ワークフロー駆動部１３０は、ワークフロー実行履歴を利用して状態遷移を再実行する（Ｓ３１３）。
【００５７】
［４−１．ワークフロー駆動部の通常の動作］
図４は、ワークフロー駆動部１３０の通常の動作を示すフローチャートであり、図３に示す状態遷移の実行ステップ（Ｓ３０３）のサブルーチンに相当する。
【００５８】
この図４に示すように、ワークフロー駆動部１３０は、状態データ１５０から現在の状態を読み込む（Ｓ４０１）。ワークフロー駆動部１３０は次に、その読み込んだ状態について、ワークフロー定義１４０から、その状態の定義を読み込む（Ｓ４０２）。ワークフロー駆動部１３０は、読み込んだ状態の定義に含まれる分岐条件を評価して、評価の結果に基づき、読み込んだ状態の定義に含まれる遷移先の中から次に遷移する状態を決定する（Ｓ４０３）。この場合、分岐条件の内容に応じて、制御データ１２０やアプリケーション１１０から渡されたデータを評価に利用することもある。
【００５９】
ワークフロー駆動部１３０は、状態遷移の実行結果をワークフロー実行履歴１６０に記録する（Ｓ４０４）。すなわち、アプリケーション１１０から渡されたデータがある場合には、ワークフロー実行履歴１６０の現在の最終行にそのデータを記録すると共にさらに１行追加し、決定した遷移先の状態を記録する。また、アプリケーション１１０から渡されたデータがない場合には、ワークフロー実行履歴１６０に１行追加して決定した遷移先の状態の記録のみを行うことになる。なお、決定した遷移先の状態は、現在の状態を示す状態データ１５０にも記録される（Ｓ４０５）。
【００６０】
例えば、前記図２のワークフロー定義に基づく前記表１のワークフロー実行履歴の例において、現在の状態が２行目の状態「途中状態１」であり、アプリケーションから「承認」のデータを渡されてその「途中状態１」の状態遷移を実行し、次の遷移先を「途中状態２」に決定した際の記録処理は、次のようになる。すなわち、この場合に、ワークフロー駆動部１３０は、データ「承認」を「アプリケーションから渡されたデータ」として記録すると共に、さらに３行目を追加し、決定した遷移先の状態「途中状態２」の記録を追加することになる。
【００６１】
［４−２．ワークフロー駆動部による状態遷移の再実行］
前述したように、制御データ１２０またはワークフロー定義１４０の変更が行われた場合に、ワークフロー駆動部１３０は、データ変更による不整合を自動的に解消するために、ワークフロー実行履歴１６０を利用して状態遷移を再実行する。図５は、このようなワークフロー駆動部１３０による状態遷移を再実行するフローチャートであり、図３に示す状態遷移の再実行ステップ（Ｓ３１３）のサブルーチンに相当する。
【００６２】
この図５に示すように、ワークフロー駆動部１３０はまず、ワークフロー実行履歴１６０中に同一の状態が複数回出現する場合における状態遷移の再実行を正常に行うために、ワークフロー実行履歴の調整を行うことにより、状態遷移の再実行の対象となる実行履歴を抽出する（Ｓ５０１）。なお、このワークフロー実行履歴の調整の詳細については後述するため、ここでは説明を省略する。
【００６３】
ワークフロー駆動部１３０は次に、調整によって抽出されたワークフロー実行履歴の先頭行「ｎ」（シーケンス番号「ｋ」）に記録された履歴を読み込み（Ｓ５０２）、その履歴の状態について、ワークフロー定義１４０の中から、その状態の定義を読み込む（Ｓ５０３）。ワークフロー駆動部１３０は、読み込んだ状態の定義に含まれる分岐条件を評価し、遷移先の状態を決定する（Ｓ５０４）。ここで、分岐条件が、アプリケーション１１０から渡されたデータの参照を含む場合、状態遷移の再実行時にはアプリケーション１１０からデータを渡されないので、代わりにワークフロー実行履歴１６０に記録されている「アプリケーションから渡されたデータ」を参照する。
【００６４】
ワークフロー駆動部１３０は続いて、ワークフロー実行履歴１６０から、前回読み込んだ履歴の次の履歴を示す行を読み込む。すなわち、前回読み込んだ履歴の変更記録にシーケンス番号が記録されていない場合には、Ｓ５０２で状態を読み込んだｎ行目のシーケンス番号「ｋ」より大きく、「ｋ」に最も近いシーケンス番号「ｋ＋α」（α≧１）の行の履歴を、「次の履歴」として読み込む。これに対して、前回読み込んだ履歴の変更記録にシーケンス番号が記録されている場合には、そのシーケンス番号で示される履歴を、「次の履歴」として読み込む（Ｓ５０５）。
【００６５】
そして、Ｓ５０４の評価結果として決定した状態と、Ｓ５０５で読み込んだ履歴の状態とを比較する（Ｓ５０６）。評価結果と履歴の状態が一致している場合（Ｓ５０６のＹＥＳ）には、Ｓ５０５で読み込んだ行を未検索の先頭行「ｎ」として、Ｓ５０３から繰り返す。すなわち、Ｓ５０６の比較結果が一致している間、あるいは、ワークフロー実行履歴１６０の最後に達しない間（Ｓ５０７のＮＯ）は、Ｓ５０３〜Ｓ５０６を繰り返す。
【００６６】
ワークフロー実行履歴の最後まで比較した場合（Ｓ５０７のＹＥＳ）は、状態が変化しなかったものと判定し、何もせずに終了する。また、比較結果が一致しない場合（Ｓ５０６のＮＯ）には、状態が変化したものと判定し、ワークフロー実行記録１６０に１行追加し、Ｓ５０４の評価結果として決定した状態を記録する（Ｓ５０８）。この場合、評価した状態の行に変更記録もつける。なお、評価結果として決定した状態は、現在の状態を示す状態データ１５０にも記録される（Ｓ５０９）。
【００６７】
例えば、前記図２のワークフロー定義に基づく前記表１のワークフロー実行履歴の例において、状態遷移を再実行した場合に、３行目の状態「途中状態２」の分岐条件の評価により決定した状態が、「途中状態４」となり、ワークフロー実行履歴中における次の行（４行目）の状態「途中状態３」と一致しない場合の記録内容は、次のようになる。すなわち、この場合に、ワークフロー駆動部１３０は、表１に示すワークフロー実行記録にシーケンス番号「６」の６行目を追加し、評価結果として決定した状態「途中状態４」を記録する。この場合、評価した状態「途中状態２」の行の変更記録に、次の履歴のシーケンス番号である「６」を記録することになる。このような記録の更新により、表２に示すような変更後のワークフロー実行履歴が得られる。
【００６８】
［４−３．ワークフロー実行履歴の調整］
前述したように、ワークフロー駆動部１３０は、ワークフロー実行履歴中に同一の状態が複数回出現する場合における状態遷移の再実行を正常に行うために、ワークフロー実行履歴の調整を行う。ここではまず、同一の状態が複数回出現する場合について、すなわち、ワークフロー実行履歴の調整が必要な場合について説明する。
【００６９】
一般的に、ワークフローシステムでは、ループになったワークフロー定義をすることがある。その場合、同じ状態を何度も通る可能性があり、１回目と２回目で制御データが変更すれば遷移先が変わる可能性もある。このような場合に、ワークフロー実行履歴の先頭から検索をすると、２回目で更新されたデータを使って１回目の状態をチェックするため、状態の変更が発生したと誤認識する可能性がある。
【００７０】
この誤認識の問題について、図６に示すワークフロー定義に基づく状態遷移を、表３に示すワークフロー実行履歴で実行した場合を例に説明する。ここで、図６のワークフロー定義においては、「発見」６１０、「修正」６２０、「部長承認」６３１、「課長承認」６３２、「確認」６４０、「完了」６５０、という状態とその遷移が定義されている。このワークフロー定義の内容は次の通りである。
【００７１】
すなわち、開発者によって作成されたソフトウェアについて、状態「発見」６１０において発見された不具合は、状態「修正」６２０において開発者によって修正され、そのバグランクが登録／変更される。この場合、状態「修正」６２０には、遷移先として、状態「部長承認」６３１、「課長承認」６３２の２つが定義されており、分岐条件として、「バグランク：Ａ→部長承認、Ａ以外→課長承認」が定義されている。バグランクは、制御データの一部であり、「修正」時に開発者によって登録／変更される。これに関連して、表３のワークフロー実行履歴には、便宜的に、その時点の制御データのバグランクも併記した。
【００７２】
また、状態「部長承認」６３１、「課長承認」６３２の遷移先としては、状態「確認」６４０、「修正」６２０の２つが定義されており、分岐条件として、「承認→確認、否認→修正」が定義されている。さらに、状態「確認」６４０の遷移先としては、状態「完了」６５０、「修正」６２０の２つが定義されており、分岐条件として、「確認結果：ＯＫ→完了、ＮＧ→修正」が定義されている。確認結果は、制御データの一部であり、「確認」時に担当者によって登録／変更される。
【００７３】
【表３】
この表３に示すワークフロー実行履歴では、１度目の「修正」時にはバグランクを「Ｂ」として登録したが、２度目の「修正」で「Ａ」に変更している。その後、分岐条件とは関係ない制御データを変更し、ワークフロー実行履歴の先頭から状態遷移を再実行すると、バグランクが「Ａ」になっているため、遷移先として「部長承認」が導き出されてしまう。この場合、ワークフロー実行履歴と状態遷移の再実行で得られた結果が異なるため、ワークフロー駆動部１３０は、データ変更で状態が変化したものと判断し、新しい状態を「部長承認」と決定してしまう。
【００７５】
次の表４は、この場合のワークフロー実行履歴と状態遷移の再実行で得られた結果の比較を示しており、「○」は一致、「×」は不一致である。しかし、本来は、分岐条件とは関係ない制御データを変更しているため、状態は変わらないはずである。
【表４】
このように、同じ状態を複数回通っていると、状態遷移の再実行を正常に行うことができなくなるという問題を生じる。本実施形態のワークフローシステムでは、この問題を解決するために、ワークフロー実行履歴の調整を行う。具体的な調整の方法は、いくつか考えられるが、ここでは、代表的な２つの方法として、「同一の状態が複数回出現するか否かをチェックする方法」と、「ユーザに指定された状態が最後に出現する位置をチェックする方法」について説明する。
【００７７】
まず、「同一の状態が複数回出現するか否かをチェックする方法」は、ワークフロー実行履歴を先頭からチェックして、「一度出現した状態が次に出現する場合には、その前回の状態の位置から今回の状態が出現する前までの履歴を削除する」、という処理を、ワークフロー実行履歴の最後まで行う方法である。表３の例では、シーケンス番号「２」の状態「修正」が、シーケンス番号「５」にも出現するため、シーケンス番号「２」から「４」までの行を削除することになる。この結果、次の表５に示すような、調整後のワークフロー実行履歴が得られる。
【００７８】
【表５】
この表５に示すように、ワークフロー実行履歴中に同一の状態が複数回出現する場合であっても、その複数回の状態のうち、最終回の状態のみが残るので、ワークフロー駆動部１３０は、状態遷移の再実行を正常に行うことができる。表６は、表５に示すワークフロー実行履歴を用いて状態遷移を再実行した場合における、ワークフロー実行履歴と状態遷移の再実行で得られた結果の比較を示している。
【００８０】
【表６】
次に、「ユーザに指定された状態が最後に出現する位置をチェックする方法」は、ユーザに状態遷移の再実行を開始する状態を指定させ、ワークフロー実行履歴を最後からチェックして、その状態が出現する位置を特定し、その位置よりも前の履歴を削除する方法である。表３の例では、状態「修正」から状態遷移の再実行が指定されたとすると、ワークフロー実行履歴の最後から状態「修正」を探すことになる。シーケンス番号「５」において状態「修正」が出現するので、シーケンス番号「５」よりも前の行を削除することになる。この結果、次の表７に示すような、調整後のワークフロー実行履歴が得られる。
【００８２】
【表７】
この表７に示すように、ワークフロー実行履歴中に同一の状態が複数回出現する場合であっても、その複数回の状態のうち、最終回の状態より前は無視するので、ワークフロー駆動部１３０は、状態遷移の再実行を正常に行うことができる。表８は、表７に示すワークフロー実行履歴を用いて状態遷移を再実行した場合における、ワークフロー実行履歴と状態遷移の再実行で得られた結果の比較を示している。
【００８４】
【表８】
［５．ワークフロー駆動部の動作例］
以下には、具体的なワークフロー定義とワークフロー実行履歴を想定した上で、ワークフロー駆動部の具体的な動作例について説明する。まず、ワークフロー定義としては、図６に示すワークフロー定義を使用するものとする。この図６に示すワークフロー定義の内容については前述したため、ここでは説明を省略する。このワークフロー定義を用いて、状態「修正」まで遷移した時点でのワークフロー実行履歴と状態データを、次の表９、表１０に示す。
【００８６】
【表９】
以下の説明では、図６のワークフロー定義に基づくこの状態「修正」から通常の状態遷移を実行した場合の動作例と、その後に状態遷移を再実行した場合の動作例について、具体的な制御データ等を含めて詳細に説明する。
【００８８】
［５−１．通常の動作］
ここでは、表９、表１０に示すように、図６のワークフロー定義を用いて状態「修正」まで遷移した時点で、ユーザにより制御データが入力され、アプリケーション１１０から次の状態に遷移するように指示された場合のワークフロー駆動部１３０の動作について説明する。ワークフロー駆動部１３０の通常の動作は、前述したように、図４のフローチャートに沿って行われる。なお、ユーザから入力された制御データは、図７に示すような、「発見日時」、「発見者」、「危険度」、「バグランク」、「現象」、等の情報を含む帳票データであるものとする。
【００８９】
ワークフロー駆動部１３０はまず、状態データ１５０から現在の状態である「修正」を読み込む（Ｓ４０１）。ワークフロー駆動部１３０は次に、その読み込んだ状態「修正」について、ワークフロー定義１４０から、その状態「修正」の定義を読み込む（Ｓ４０２）。ワークフロー駆動部１３０は、読み込んだ状態「修正」の定義に含まれる分岐条件を評価して遷移先を決定する（Ｓ４０３）。この場合、状態「修正」の分岐条件は、制御データのバグランクの参照を含む。図７に示す制御データのバグランクは「Ｂ」であるため、ワークフロー駆動部１３０は、状態「課長承認」を遷移先として決定する。
【００９０】
ワークフロー駆動部１３０は、状態「課長承認」に遷移したことをワークフロー実行履歴に記録する（Ｓ４０４）。すなわち、表９に示すワークフロー実行履歴にさらにシーケンス番号「３」の行を１行追加し、決定した遷移先の状態「課長承認」を記録する。なお、決定した新しい状態「課長承認」は、現在の状態を示す状態データにも記録される（Ｓ４０５）。次の表１１、表１２は、この時点でのワークフロー実行履歴と状態データをそれぞれ示している。
【００９１】
【表１１】
［５−２．状態遷移の再実行］
ここでは、表１１、表１２に示すように、図６のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザにより制御データまたはワークフロー定義の変更要求が入力され、アプリケーション１１０がその変更要求に基づくデータ変更を行った際に、アプリケーション１１０からの状態遷移の再実行の指示に基づくワークフロー駆動部１３０の動作について説明する。
【００９３】
ワークフロー駆動部１３０による状態遷移の再実行は、前述したように、図５のフローチャートに沿って行われるが、その具体的な動作の流れは、制御データの変更が状態を変化させない場合、制御データの変更が状態を変化させる場合、ワークフロー定義を変更した場合、でそれぞれ異なるため、以下には、この３パターンの動作例について順次説明する。なお、ワークフロー実行履歴の調整には、前述した２つの方法のうち、「同一の状態が複数回出現するか否かをチェックする方法」を採用するものとする。
【００９４】
［５−２−１．制御データの変更が状態を変化させない場合］
ここでは、表１１、表１２に示すように、図６のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザの変更要求に基づき、アプリケーション１１０により、図７の制御データ中の「現象」のデータが、図８に示すように変更されたものとする。
【００９５】
この場合に、ワークフロー駆動部１３０はまず、ワークフロー実行履歴の調整を行うことにより、状態遷移の再実行の対象となる状態を特定する（Ｓ５０１）。この場合、表１１に示すワークフロー実行履歴を先頭からチェックしても、一度出現した状態が次に出現することはないため、この表１１に示すワークフロー実行履歴がそのまま状態遷移の再実行の対象として特定されることになる。
【００９６】
ワークフロー駆動部１３０は次に、表１１に示すワークフロー実行履歴のシーケンス番号「１」の１行目に記録された状態「発見」を読み込み（Ｓ５０２）、その状態「発見」について、図６のワークフロー定義の中から、その状態「発見」の定義を読み込む（Ｓ５０３）。ワークフロー駆動部１３０は、読み込んだ状態「発見」の定義に含まれる分岐条件を評価し、次の状態を決定する（Ｓ５０４）。この場合、状態「発見」には分岐条件がないので、無条件に次の状態「修正」が決定される。
【００９７】
ワークフロー駆動部１３０は続いて、表１１のワークフロー実行履歴から、状態「発見」を読み込んだ１行目の次の行である２行目の履歴を読み込む（Ｓ５０５）。この場合、評価結果として決定した状態と、ワークフロー実行履歴中の次の状態とを比較すると、いずれも「修正」で一致している（Ｓ５０６のＹＥＳ）ので、Ｓ５０５で読み込んだ行の状態「修正」について、図６のワークフロー定義の中から、その状態「修正」の定義を読み込む（Ｓ５０３）。
【００９８】
ワークフロー駆動部１３０は、読み込んだ状態「修正」の定義に含まれる分岐条件を評価し、次の状態を決定する（Ｓ５０４）。この場合、状態「修正」の分岐条件は、制御データのバグランクの参照を含むが、図８の制御データ中で変更されたのは「現象」のデータだけであり、バグランクは何ら変更されていないので、次の状態は「課長承認」となる。
【００９９】
ワークフロー駆動部１３０は続いて、表１１のワークフロー実行履歴から、状態「修正」を読み込んだ２行目の次の行である３行目の履歴を読み込む（Ｓ５０５）。この場合、評価結果として決定した状態と、ワークフロー実行履歴中の次の状態とを比較すると、いずれも「課長承認」で一致している（Ｓ５０６のＹＥＳ）。この場合、表１１に示すワークフロー実行履歴の最後の行に達した（Ｓ５０７のＹＥＳ）ので、状態は変化しなかったものと判断し、何もせずに終了する。
【０１００】
次の表１３は、表１１に示すワークフロー実行履歴と以上の状態遷移の再実行で得られた結果の比較を示している。
【表１３】
［５−２−２．制御データの変更が状態を変化させる場合］
ここでは、表１１、表１２に示すように、図６のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザの変更要求に基づき、アプリケーション１１０により、図７の制御データ中では「Ｂ」であったバグランクが、図９に示すように「Ａ」に変更されたものとする。
【０１０２】
この場合に、ワークフロー駆動部１３０はまず、ワークフロー実行履歴の調整を行うが、前述したように、表１１に示すワークフロー実行履歴を先頭からチェックしても、一度出現した状態が次に出現することはないため、この表１１に示すワークフロー実行履歴がそのまま状態遷移の再実行の対象として特定されることになる。
【０１０３】
ワークフロー駆動部１３０が、表１１に示すワークフロー実行履歴の１行目に記録された状態「発見」を読み込み、その状態「発見」の定義を読み込んで次の状態を「修正」に決定し、ワークフロー実行履歴中の次の状態と比較した後、その状態「修正」の定義を読み込むまでの動作は、前述した「制御データの変更が状態を変化させない場合」の動作と同様である。
【０１０４】
この場合、読み込んだ状態「修正」の定義に含まれる分岐条件を評価すると、図９の制御データ中でバグランクが「Ｂ」から「Ａ」に変更されているので、次の状態は「部長承認」となる（Ｓ５０４）。ワークフロー駆動部１３０は続いて、表１１のワークフロー実行履歴から、状態「修正」を読み込んだ２行目の次の行である３行目の履歴を読み込む（Ｓ５０５）。
【０１０５】
次に、評価結果として決定した状態と、ワークフロー実行履歴中の次の状態とを比較すると、決定した状態「部長承認」と履歴中の次の状態「課長承認」とは一致していない（Ｓ５０６のＮＯ）ので、状態は変化したものと判定して、表１１に示すワークフロー実行記録にシーケンス番号「４」の４行目を追加し、評価結果として決定した状態「部長承認」を記録する（Ｓ５０８）。この場合、評価した状態「修正」の行の変更記録に、次の履歴のシーケンス番号である「４」を記録する。変更後の新しいワークフロー実行履歴は、１→２→４となる。なお、評価結果として決定した状態「部長承認」は、現在の状態を示す状態データにも記録される（Ｓ５０９）。
【０１０６】
次の表１４は、表１１に示すワークフロー実行履歴と以上の状態遷移の再実行で得られた結果の比較を示している。
【表１４】
また、次の表１５、表１６は、以上の状態遷移の再実行で更新された変更後のワークフロー実行履歴と状態データをそれぞれ示している。
【表１５】
［５−２−３．ワークフロー定義を変更した場合］
ここでは、表１１、表１２に示すように、図６のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザの変更要求に基づき、アプリケーション１１０により、図６に示すワークフロー定義中の「修正」の分岐条件が、「バグランク：Ａ→部長承認、Ａ以外→課長承認」から、「バグランク：Ａ、Ｂ→部長承認、Ａ、Ｂ以外→課長承認」に変更されたものとする。
【０１０９】
この場合に、ワークフロー駆動部１３０が、表１１に示すワークフロー実行履歴をそのまま状態遷移の再実行の対象として特定した後、ワークフロー実行履歴の１行目に記録された状態「発見」とその定義を読み込んで次の状態を「修正」に決定し、ワークフロー実行履歴中の次の状態と比較した後、状態「修正」の定義を読み込むまでの動作は、前述した「制御データの変更が状態を変化させない場合」の動作と同様である。
【０１１０】
この場合、読み込んだ状態「修正」の定義に含まれる分岐条件を評価すると、制御データ中のバグランクは「Ｂ」と変わっていないが、分岐条件自体が「バグランク：Ａ、Ｂ→部長承認、Ａ、Ｂ以外→課長承認」に変更されているので、次の状態は「部長承認」となる（Ｓ５０４）。ワークフロー駆動部１３０は続いて、表１１のワークフロー実行履歴から、状態「修正」を読み込んだ２行目の次の行である３行目の履歴を読み込み（Ｓ５０５）、評価結果として決定した状態と比較する（Ｓ５０６）。
【０１１１】
この場合、決定した状態「部長承認」と履歴中の次の状態「課長承認」とは一致していない（Ｓ５０６のＮＯ）ので、状態は変化したものと判定して、表１１に示すワークフロー実行記録にシーケンス番号「４」の４行目を追加し、評価結果として決定した状態「部長承認」を記録する（Ｓ５０８）。この場合、評価した状態「修正」の行の変更記録に、次の履歴のシーケンス番号である「４」を記録する。変更後の新しいワークフロー実行履歴は、１→２→４となる。なお、評価結果として決定した状態「部長承認」は、現在の状態を示す状態データにも記録される（Ｓ５０９）。
【０１１２】
次の表１７は、表１１に示すワークフロー実行履歴と以上の状態遷移の再実行で得られた結果の比較を示している。
【表１７】
また、次の表１８、表１９は、以上の状態遷移の再実行で更新された変更後のワークフロー実行履歴と状態データをそれぞれ示している。
【表１８】
［６．実施形態の作用効果］
以上のような本実施形態のワークフローシステムとワークフロー実行方法によれば、状態遷移の実行時に参照する制御データやワークフロー定義等の情報の変更を受け付けた場合に、ワークフロー実行履歴を利用して状態遷移を再実行することにより、「情報の変更」を反映したワークフローに基づいて遷移先の状態を決定することができるため、決定した状態と参照先の制御データとの間の整合性を維持できる。
【０１１５】
したがって、本実施形態の手法によれば、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順をワークフローとして定義し、そのワークフロー定義に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理することができる。このような本実施形態の手法は、特に、ソフトウェア開発における不具合管理に好適であり、データ変更による不整合の問題を生じることなしに大量の不具合を効率よく適切に処理することができる。
【０１１６】
また、再実行された状態遷移に係るワークフロー実行履歴を保存することにより、保存されたワークフロー実行履歴と制御データ等の外部情報との間の整合性を維持できる。さらに、本発明による情報変更時の状態遷移の再実行は、通常の状態遷移の実行に準じた処理であるため、通常の状態遷移の実行を行うワークフロー駆動部の機能を若干変更するだけで容易に実現可能である。すなわち、通常のワークフロー駆動部に状態特定機能と再実行機能を持たせることにより、本発明による情報変更時の状態遷移の再実行を容易に実現することができる。
【０１１７】
さらに、ワークフロー実行履歴中に同じ状態が複数回出現する場合でも、ワークフロー実行履歴の調整を行い、その複数回の状態のうち、最終回の状態のみを特定して状態遷移を再実行することにより、状態遷移の再実行を正常に行うことができる。
【０１１８】
［７．他の実施形態］
なお、本発明は、前述した実施形態に限定されるものではなく、本発明の範囲内で他にも多種多様な形態が実施可能である。
【０１１９】
まず、図１に示したシステム構成や、図３〜図５に示したワークフロー実行手順は、一例にすぎず、具体的なシステム構成や実行手順は自由に変更可能である。また、図６に示したワークフロー定義や図７に示した制御データも一例にすぎず、本発明で具体的に使用するデータやプログラムを含めた具体的なデータ構造は自由に選択可能である。さらに、本発明は、前述した通り、ソフトウェア開発における不具合管理に好適であるが、それに限らず、ワークフローシステムを採用した各種の分野における情報管理システム一般に広く適用可能であり、同様に優れた効果が得られるものである。
【０１２０】
【発明の効果】
以上詳述したように、本発明によれば、状態遷移の実行時に参照するデータやワークフロー定義等の変更を受け付けた場合に、実行履歴を利用して状態遷移を再実行することにより、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することができる。
【０１２１】
したがって、本発明によれば、ソフトウェア開発における不具合管理システムに好適で、データ変更による不整合の問題を生じることなしに大量の不具合を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することができる。
【図面の簡単な説明】
【図１】本発明を適用した一つの実施形態に係るワークフローシステムの構成を示すブロック図。
【図２】図１に示すワークフローシステムで使用するワークフロー定義の一例を示す状態遷移図。
【図３】図１に示すワークフローシステムの動作の概略を示すフローチャート。
【図４】図１に示すワークフロー駆動部の通常の動作として、図３に示す状態遷移の実行ステップのサブルーチンに相当する動作を示すフローチャート。
【図５】図１に示すワークフロー駆動部のデータ変更時の動作として、図３に示す状態遷移の再実行ステップのサブルーチンに相当する動作を示すフローチャート。
【図６】図１に示すワークフローシステムで使用するワークフロー定義の一例を示す状態遷移図。
【図７】図１に示すワークフローシステムで使用する制御データの一例を示す説明図。
【図８】図７に示す制御データを変更した一例を示す説明図。
【図９】図７に示す制御データを変更した別の一例を示す説明図。
【図１０】ソフトウェア開発における不具合処理手順の一例を示す状態遷移図。
【図１１】ワークフロー定義に基づいて決定した状態と参照した外部情報との間に不整合を生じるという問題点を説明するための説明図。
【符号の説明】
１００...ワークフローシステム
１１０...アプリケーションプログラム
１２０...制御データ
１３０...ワークフロー駆動部
１４０...ワークフロー定義
１５０...状態データ
１６０...ワークフロー実行履歴
１７０...ワークフローマネージャ
Ｕ...ユーザ（利用者または他のシステム）
Claims (3)
- コンピュータ上で実行されるアプリケーションと、
前記アプリケーションによって書き換え可能で、状態名、分岐条件、及びこの分岐条件に従って前記状態名から遷移する遷移先の状態名を使用して、状態とその遷移を定義したワークフロー定義の記憶部と、
前記アプリケーションによって書き換え可能で、前記ワークフロー定義の分岐条件の評価時に参照される制御データの記憶部と、
前記アプリケーションによって制御され、前記ワークフロー定義及び制御データに基づいて、ある状態から他の状態への遷移であるワークフローを実行させるワークフロー駆動部と、
ワークフロー実行時における現在の状態名を記録した状態データの記憶部と、
遷移の順番を示すシーケンス番号、状態名、アプリケーションプログラムから渡されたデータ、及び変更記録を使用して、前記ワークフロー駆動部によって実行された状態間の遷移の記録を保存するワークフロー実行履歴の記憶部とを使用したワークフロー実行方法において、
前記ワークフロー駆動部が、状態データに記憶されている現在の状態を始点として、制御データを参照して分岐条件を評価し遷移先の状態名を決定することにより、ワークフローを実行するステップと、
前記ワークフロー駆動部が、前記ワークフローの実行履歴を、シーケンス番号、状態名、アプリケーションプログラムから渡されたデータ、及び変更記録を使用して、記録するステップと、
アプリケーションによって、前記制御データまたは分岐条件が変更された場合に、前記ワークフロー駆動部が、前記ワークフローの実行時と同様に、始点となる状態から変更後の制御データまたは分岐条件に従って、ワークフローを再実行するステップと、
前記ワークフロー駆動部が、状態データに再実行後の現在の状態を記録するステップと、
前記ワークフロー駆動部が、再実行ステップの実行履歴を記録し、再実行後の現在の状態をシーケンス番号と状態名を用いて実行履歴に記録するとともに、その履歴中の実行時と再実行時とで遷移先の状態が異なるシーケンス番号に対応する変更記録には遷移先に変更があったことを記録するステップと、
前記ワークフロー駆動部が、ワークフローの再実行ステップに先立ち、ワークフロー実行履歴をシーケンス番号順に検査して、そのシーケンス番号に対応して記録されている各状態名を比較して同一の状態名が発見された場合には、前記ワークフロー実行履歴の中から同一の状態名が発見されたシーケンス番号よりも前のシーケンス番号の履歴を削除するステップと、
前記ワークフロー駆動部が、状態遷移の再実行ステップを、同一の状態名が発見されたシーケンス番号の状態を始点として開始することを特徴とするワークフロー実行方法。 - コンピュータ上で実行されるアプリケーションと、
前記アプリケーションによって書き換え可能で、状態名、分岐条件、及びこの分岐条件に従って前記状態名から遷移する遷移先の状態名を使用して、状態とその遷移を定義したワークフロー定義の記憶部と、
前記アプリケーションによって書き換え可能で、前記ワークフロー定義の分岐条件の評価時に参照される制御データの記憶部と、
前記アプリケーションによって制御され、前記ワークフロー定義及び制御データに基づいて、ある状態から他の状態への遷移であるワークフローを実行させるワークフロー駆動部と、
ワークフロー実行時における現在の状態名を記録した状態データの記憶部と、
遷移の順番を示すシーケンス番号、状態名、アプリケーションプログラムから渡された データ、及び変更記録を使用して、前記ワークフロー駆動部によって実行された状態間の遷移の記録を保存するワークフロー実行履歴の記憶部とを有するワークフローシステムにおいて、
前記ワークフロー駆動部は、
状態データに記憶されている現在の状態を始点として、制御データを参照して分岐条件を評価し遷移先の状態名を決定することにより、ワークフローを実行し、
前記ワークフローの実行履歴を、シーケンス番号、状態名、アプリケーションプログラムから渡されたデータ、及び変更記録を使用して、前記ワークフロー実行履歴記憶部に記録し、
アプリケーションによって、前記制御データまたは分岐条件が変更された場合に、前記ワークフローの実行時と同様に、始点となる状態から変更後の制御データまたは分岐条件に従って、ワークフローを再実行し、
前記状態データに再実行後の現在の状態を、前記状態データ記憶部に記憶し、
前記再実行時の実行履歴を記録し、再実行後の現在の状態をシーケンス番号と状態名を用いて実行履歴に記録するとともに、その履歴中の実行時と再実行時とで遷移先の状態が異なるシーケンス番号に対応する変更記録には遷移先に変更があったことを記録し、
前記ワークフローの再実行ステップに先立ち、ワークフロー実行履歴をシーケンス番号順に検査して、そのシーケンス番号に対応して記録されている各状態名を比較して同一の状態名が発見された場合には、前記ワークフロー実行履歴の中から同一の状態名が発見されたシーケンス番号よりも前のシーケンス番号の履歴を削除し、
前記再実行を、同一の状態名が発見されたシーケンス番号の状態を始点として開始することを特徴とするワークフローシステム。 - コンピュータ上で実行されるアプリケーションと連携するワークフロー実行プログラムであって、コンピュータ上に、
前記アプリケーションによって書き換え可能で、状態名、分岐条件、及びこの分岐条件に従って前記状態名から遷移する遷移先の状態名を使用して、状態とその遷移を定義したワークフロー定義の記憶部と、
前記アプリケーションによって書き換え可能で、前記ワークフロー定義の分岐条件の評価時に参照される制御データの記憶部と、
前記アプリケーションによって制御され、前記ワークフロー定義及び制御データに基づいて、ある状態から他の状態への遷移であるワークフローを実行させるワークフロー駆動部と、
ワークフロー実行時における現在の状態名を記録した状態データの記憶部と、
遷移の順番を示すシーケンス番号、状態名、アプリケーションプログラムから渡されたデータ、及び変更記録を使用して、前記ワークフロー駆動部によって実行された状態間の遷移の記録を保存するワークフロー実行履歴の記憶部とを実現させ、
前記ワークフロー駆動部により、
状態データに記憶されている現在の状態を始点として、制御データを参照して分岐条件を評価し遷移先の状態名を決定することにより、ワークフローを実行し、
前記ワークフローの実行履歴を、シーケンス番号、状態名、アプリケーションプログラムから渡されたデータ、及び変更記録を使用して、前記ワークフロー実行履歴記憶部に記録し、
アプリケーションによって、前記制御データまたは分岐条件が変更された場合に、前記ワークフローの実行時と同様に、始点となる状態から変更後の制御データまたは分岐条件に従って、ワークフローを再実行し、
前記状態データに再実行後の現在の状態を、前記状態データ記憶部に記憶し、
前記再実行時の実行履歴を記録し、再実行後の現在の状態をシーケンス番号と状態名を用いて実行履歴に記録するとともに、その履歴中の実行時と再実行時とで遷移先の状態が異なるシーケンス番号に対応する変更記録には遷移先に変更があったことを記録し、
前記ワークフローの再実行ステップに先立ち、ワークフロー実行履歴をシーケンス番号順に検査して、そのシーケンス番号に対応して記録されている各状態名を比較して同一の状態名が発見された場合には、前記ワークフロー実行履歴の中から同一の状態名が発見されたシーケンス番号よりも前のシーケンス番号の履歴を削除し、
前記再実行を、同一の状態名が発見されたシーケンス番号の状態を始点として開始することを特徴とするワークフロー実行プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002281375A JP4150566B2 (ja) | 2002-09-26 | 2002-09-26 | ワークフロー実行方法とシステム、およびそのためのプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002281375A JP4150566B2 (ja) | 2002-09-26 | 2002-09-26 | ワークフロー実行方法とシステム、およびそのためのプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004118553A JP2004118553A (ja) | 2004-04-15 |
| JP4150566B2 true JP4150566B2 (ja) | 2008-09-17 |
Family
ID=32275831
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002281375A Expired - Fee Related JP4150566B2 (ja) | 2002-09-26 | 2002-09-26 | ワークフロー実行方法とシステム、およびそのためのプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4150566B2 (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4676784B2 (ja) * | 2004-03-02 | 2011-04-27 | 株式会社リコー | プロセス管理装置、プロセス管理方法及びプロセス管理プログラム |
| US7657454B2 (en) * | 2005-08-09 | 2010-02-02 | Microsoft Corporation | Server-side project manager |
| JP2009110276A (ja) * | 2007-10-30 | 2009-05-21 | Toshiba Corp | 顧客対応作成管理装置、顧客対応管理システム、及び顧客対応作成管理プログラム |
| JP5178293B2 (ja) * | 2008-04-15 | 2013-04-10 | キヤノン株式会社 | ワークフロー実行装置、ワークフロー実行方法、及びコンピュータプログラム |
| JP5128365B2 (ja) * | 2008-05-09 | 2013-01-23 | キヤノンソフトウェア株式会社 | 情報処理システム、情報処理方法、プログラム、及び、記録媒体 |
| JP2018195040A (ja) * | 2017-05-17 | 2018-12-06 | 株式会社日立製作所 | ビジネスプロセス評価装置及びビジネスプロセス評価方法 |
| JP7098967B2 (ja) * | 2018-03-07 | 2022-07-12 | 株式会社リコー | 電子機器、プログラム、ワークフロー実行制御方法及び情報処理システム |
| JP7395934B2 (ja) * | 2019-10-07 | 2023-12-12 | 富士フイルムビジネスイノベーション株式会社 | 情報処理装置及びプログラム |
| CN112416476B (zh) * | 2020-11-25 | 2023-03-24 | 武汉联影医疗科技有限公司 | 工作流执行方法、装置、计算机设备和存储介质 |
-
2002
- 2002-09-26 JP JP2002281375A patent/JP4150566B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004118553A (ja) | 2004-04-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7844948B2 (en) | Maintaining multiple valid concurrent serialized object versions | |
| US9898280B2 (en) | Automatic code review and code reviewer recommendation | |
| US9207933B2 (en) | Identifying authors of changes between multiple versions of a file | |
| US20080282231A1 (en) | Automated software testing framework using independent test scripts | |
| US6938186B2 (en) | System and method for performing a path-sensitive verification on a program | |
| JPH0228831A (ja) | バージョン管理方法 | |
| US10380085B2 (en) | Method, apparatus and computer program for migrating records in a database from a source database schema to a target database schema | |
| US20090271661A1 (en) | Status transition test support device, status transition test support method, and recording medium | |
| JP4150566B2 (ja) | ワークフロー実行方法とシステム、およびそのためのプログラム | |
| JP2005228241A (ja) | バグ管理方法および装置 | |
| US8904348B2 (en) | Method and system for handling errors during script execution | |
| US11176022B2 (en) | Health diagnostics and analytics for object repositories | |
| JPS63237165A (ja) | 工程計画支援装置 | |
| JPH1153391A (ja) | データベースアクセス方法 | |
| JP2009026029A (ja) | トランザクション制御装置、トランザクション制御方法、トランザクション制御プログラムおよびそのプログラムを記憶した記憶媒体 | |
| JP2000112800A (ja) | ファイル履歴管理システム | |
| CN113687859B (zh) | 一种软件开发的分支管理方法、装置、电子设备及介质 | |
| JP3104586B2 (ja) | 設計支援方法 | |
| US20220404159A1 (en) | Mass transportation ridership data import | |
| JP2006099452A (ja) | Ｓｉ対象ファイルおよびｓｉ関連ファイル管理システム | |
| JP2000112722A (ja) | 版数管理システム、管理方法及び記憶媒体 | |
| Roy et al. | Ranking Co-change Candidates of Micro-Clones | |
| JP2002007561A (ja) | サービスコードの自動算定方法 | |
| CN115770390A (zh) | 模型骨骼修复方法、装置、存储介质与电子设备 | |
| KR100764621B1 (ko) | 데이터 풀링 방법 및 데이터 풀링 시스템 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050518 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20071212 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071218 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080218 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080401 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080602 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20080609 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080624 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080630 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110704 Year of fee payment: 3 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 4150566 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110704 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120704 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130704 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |