JP2004118553A - ワークフロー実行方法とシステム、およびそのためのプログラム - Google Patents
ワークフロー実行方法とシステム、およびそのためのプログラム Download PDFInfo
- Publication number
- JP2004118553A JP2004118553A JP2002281375A JP2002281375A JP2004118553A JP 2004118553 A JP2004118553 A JP 2004118553A JP 2002281375 A JP2002281375 A JP 2002281375A JP 2002281375 A JP2002281375 A JP 2002281375A JP 2004118553 A JP2004118553 A JP 2004118553A
- Authority
- JP
- Japan
- Prior art keywords
- workflow
- state
- execution
- information
- change
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 82
- 230000007704 transition Effects 0.000 claims abstract description 176
- 230000008859 change Effects 0.000 claims abstract description 92
- 238000011156 evaluation Methods 0.000 claims description 18
- 238000012545 processing Methods 0.000 abstract description 43
- 230000008569 process Effects 0.000 abstract description 15
- 230000007547 defect Effects 0.000 description 66
- 238000012937 correction Methods 0.000 description 38
- 238000010586 diagram Methods 0.000 description 10
- 238000012790 confirmation Methods 0.000 description 8
- 230000000694 effects Effects 0.000 description 5
- 238000012508 change request Methods 0.000 description 3
- 238000007562 laser obscuration time method Methods 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000001174 ascending effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000008570 general process Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Landscapes
- Stored Programmes (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【解決手段】アプリケーション110は、ユーザUからの要求を受けて、制御データ120やワークフロー定義140を変更する。ワークフロー駆動部130は、ワークフロー定義140に従って、制御データ120を参照し、状態データ150を遷移させ、状態遷移の履歴をワークフロー実行履歴160として記録する。ワークフロー駆動部130はまた、制御データ120やワークフロー定義140等のデータの変更時にワークフロー実行履歴160を参照し、その情報の変更により影響を受ける状態を特定して、その特定された状態から、情報の変更を反映したワークフローに基づいて状態遷移を再実行する。
【選択図】 図1
Description
【発明の属する技術分野】
本発明は、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフロー実行方法とシステムに係り、特に、ソフトウェア開発における不具合管理に好適なワークフロー実行方法とシステムに関する。
【0002】
【従来の技術】
ソフトウェア開発の分野では、想定される多様な状況において常に安定した信頼性の高い動作を行うことのできる高品質のソフトウェアを開発することが重要である。このことから、ソフトウェア開発においては、一般的に、作成したソフトウェア全体に亘って不具合の有無を詳細にチェックし、発見された不具合を修正している。このようなテスト工程においては、発見された不具合を漏れなく修正しなければならない。
【0003】
そのためには、発見された不具合の状況、すなわち、その不具合が「修正中」なのか、「修正が終わった」のかといった状況を正確に把握し、管理する必要がある。このような活動は、一般的に、「不具合管理」と呼ばれている。この「不具合管理」は、不具合の処理手順を明確にし、個々の不具合が、手順通りに処理されているか否かを管理するものである。
【0004】
このような「不具合管理」は、従来は、書面に不具合の情報を記入し、決められたルートで回付することで行われており、実質的に手作業主体の管理であった。しかし、近年、開発規模の増大で、不具合件数も増加しており、より効率的な不具合管理が必要となっている。その一つの解決策として、不具合管理を電子化し、大量の不具合管理を効率的に処理する不具合管理システムの導入が考えられる。
【0005】
また、以上のような「不具合管理」において、不具合の処理手順は、組織やプロジェクトにより様々であるが、一般的には例えば、図10に示すような手順で不具合処理が行われる。この図10に示すように、開発者によって作成されたソフトウェアについて、その開発者またはその他の担当者により何らかの不具合が「発見」される(1010)と、その「発見」された不具合は、その不具合の重要度に応じて修正すべきか否かに「振分け」られる(1020)。なお、この場合に、一般的には、修正すべきか否かの判断だけでなく、修正担当者の振分けを行う。
【0006】
そして、修正すべき不具合として振分けられた不具合については、開発者により「修正」される(1030)。なお、このような不具合の修正(1030)後、さらに振分けられて修正される(1020、1030)場合もある。いずれの場合でも、不具合の修正後、不具合の発見者である担当者またはその他の担当者により、不具合が修正されていることが「確認」された(1040)時点で、処理を完了する(1050)。また、「発見」された不具合の重要度が低く、特に修正する必要がない場合、仕様上の制約で不具合とならない場合、あるいは、報告済みの不具合が登録された場合等には、「ノーバグ」として、何ら対処することなしに処理を完了する(1060)。なお、実際上は、重要度が低くてもこの段階でノーバグにすることは稀である。
【0007】
なお、不具合の振分けとしては、修正すべきか否かだけでなく、不具合の重要度に応じて、優先処理と一般処理に振分ける等、複数の処理への振分けを行うこともある。また、複数の開発者によりソフトウェアを協同開発する場合には、不具合の箇所や種類、重要度等に応じて複数の開発者に振分けることが多い。逆に、組織やプロジェクトによっては、「振分け」を必要としない場合もある。
【0008】
一方、不具合が修正されていることの「確認」についても、担当者が行う場合だけでなく、担当者と管理者の二重で行われる場合もある。さらに、不具合の重要度に応じて、修正内容に対する管理者の承認を必要とする場合もある。
【0009】
以上のように、不具合の処理手順は、組織やプロジェクトにより様々であるため、不具合の処理手順を柔軟に定義でき、その手順に従って各不具合の状態を管理する仕組みが求められている。そのような仕組みとしては、ワークフローシステムが適している。従来、ワークフローシステムに関する技術としては、実行履歴を利用して作業ステップの作業者の割り付けを自動化するワークフローシステムが提案されている(例えば、特許文献1参照)。また、実行履歴を利用して回覧ルートの動的な制御を行うもの(例えば、特許文献2参照)、プロセス定義の正当性検証のためにトレースを行うもの(例えば、特許文献3参照)、ワークフロー状態とアプリケーションの状態との整合性を維持するもの(例えば、特許文献4参照)、等も提案されている。
【0010】
【特許文献1】
特開2000−3393号公報
【特許文献2】
特開平11−85877号公報
【特許文献3】
特開平8−190587号公報
【特許文献4】
特開2000−29956号公報
【0011】
【発明が解決しようとする課題】
しかしながら、上述したような従来のワークフローシステムは、不具合管理に利用できる反面、次のような問題点がある。
【0012】
まず、データ変更による不整合を生じるという問題点がある。すなわち、処理手順の定義(本明細書中ではワークフロー定義と呼ぶ)によっては、分岐条件として外部情報を参照することがあるが、そのような場合に、分岐後に分岐条件として参照した外部情報がデータ変更されると、ワークフローシステムがワークフロー定義に基づいて決定した状態と参照した外部情報との間に不整合が生じてしまう。この点について、図11のワークフロー定義を参照して説明する。
【0013】
まず、図11のワークフロー定義では、開発者またはその他の担当者により何らかの不具合が「発見」される(1110)と、その「発見」された不具合について、「振分け」(1120)で不具合情報の重要度を参照し、分岐先を決定するよう定義されている。このワークフロー定義に従って不具合を処理していくと、重要度が「A」の不具合は「優先処理」(1131)に遷移し、重要度が「B」の不具合は「一般処理」(1132)に遷移することになる。
【0014】
そして、これらの「優先処理」(1131)または「一般処理」(1132)で開発者により不具合が修正された後、不具合の発見者である担当者またはその他の担当者により、不具合が修正されていることが「確認」された(1140)時点で、処理を完了する(1150)。また、「発見」された不具合の重要度が低く、特に修正する必要がない場合には、「ノーバグ」として、何ら対処することなしに処理を完了する(1160)。
【0015】
このような図11のワークフロー定義において、発見された不具合は、「振分け」(1120)で外部情報である不具合情報の重要度が参照され、重要度が「A」である場合には「優先処理」(1131)に遷移することになる。しかし、この場合に、外部情報である不具合情報の重要度が後から「B」に変更されると、その不具合は、本来なら「一般処理」(1132)に遷移すべきにも拘わらず、「優先処理」(1131)に遷移することになる。このように、従来のワークフローシステムにおいては、参照先の外部情報を変更すると、ワークフロー定義に基づいて決定した状態と外部情報との間に不整合が生じる可能性がある。また、ワークフロー定義の分岐条件を変更した場合にも、変更前に決定した状態と外部情報との間に同様の不整合が生じる可能性がある。
【0016】
このようなデータ変更による不整合の問題を回避するために、外部情報を勝手に変更させず、一旦、「差戻し」等の処理を行って整合性を壊さない手順でデータを変更する方法を採用することも考えられる。しかし、この方法には、以下のデメリットがある。
(1)差戻し手順をワークフロー定義する必要があり、ワークフロー定義が複雑になる。
(2)データ変更には、「差戻し」→「再登録」という手順を踏むことから、オーバーヘッドが大きくなる。
このうち、特に、(2)のデメリットは、大量の不具合を処理しなければならない不具合管理システムでは大きな問題である。
【0017】
なお、以上のような問題点は、ソフトウェア開発における不具合管理システムに限らず、ワークフローシステムを採用した各種の分野における情報管理システム一般に同様に存在している。
【0018】
本発明は、上述したような従来技術の問題点を解決するために提案されたものであり、その目的は、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することである。特に、ソフトウェア開発における不具合管理システムに好適で、データ変更による不整合の問題を生じることなしに大量の不具合を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することである。
【0019】
【課題を解決するための手段】
本発明は、状態遷移の実行時に参照するデータやワークフロー定義等の変更を受け付けた場合に、実行履歴を利用して状態遷移を再実行することにより、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理できるようにしたものである。
【0020】
請求項1の発明は、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフロー実行方法において、状態特定ステップと再実行ステップとを含むことを特徴としている。ここで、状態特定ステップは、ワークフローに影響を与える情報の変更を受け付けた場合に、実行履歴から情報の変更により影響を受ける状態を特定するステップである。また、再実行ステップは、特定された状態から、情報の変更を反映したワークフローに基づいて状態遷移を再実行するステップである。
【0021】
請求項6の発明は、請求項1の発明をシステムの観点から把握したものであり、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローシステムにおいて、請求項1の発明における状態特定ステップと再実行ステップに対応する状態特定手段と再実行手段を備えたことを特徴としている。
【0022】
請求項8の発明は、請求項1、請求項6の発明をコンピュータプログラムの観点から把握したものであり、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローを実行するためのプログラムにおいて、請求項1の発明における状態特定ステップと再実行ステップに対応する状態特定機能と再実行機能をコンピュータに実現させることを特徴としている。
【0023】
請求項2の発明は、請求項1のワークフロー実行方法において、履歴更新ステップを含むことを特徴としている。ここで、履歴更新ステップは、再実行された状態遷移と実行履歴に保存された状態遷移とを比較し、これら状態遷移の間に差がある場合は、再実行された状態遷移にかかる実行履歴を保存するステップである。
【0024】
請求項3の発明は、請求項1または請求項2のワークフロー実行方法において、状態遷移のうち、少なくとも一つの状態から次の状態への遷移は、予め指定されたデータを参照して実行され、情報の変更はそのデータの変更を含むことを特徴としている。
請求項4の発明は、請求項1乃至請求項3のいずれかのワークフロー実行方法において、ワークフローは、状態遷移を定義したワークフロー定義に基づいて決定され、情報の変更はそのワークフロー定義の変更を含むことを特徴としている。
【0025】
請求項7の発明は、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローシステムにおいて、第1〜第3の格納部と実行手段を備えたことを特徴としている。ここで、第1の格納部は、状態名、次に遷移する状態の候補、遷移先を決定する条件、に関する情報を用いて状態遷移を定義したワークフロー定義を記憶する格納部である。また、第2の格納部は、ワークフロー定義に含まれる条件を評価するためのデータを記憶する格納部である。また、実行手段は、ワークフロー定義を用いてワークフローを特定し、データを参照してその特定されたワークフローに基づく状態遷移を実行する手段であり、第3の格納部は、状態遷移の実行履歴を記憶する格納部である。さらに、実行手段は、ワークフロー定義もしくはデータの少なくとも一方の情報が変更された場合に、実行履歴からその情報の変更により影響を受ける状態を特定し、その特定された状態から、情報の変更を反映したワークフローに基づいて状態遷移を再実行するように構成される。
【0026】
請求項9の発明は、請求項7の発明をコンピュータプログラムの観点から把握したものであり、ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローを実行するためのプログラムにおいて、実行機能、履歴格納機能、状態特定機能、再実行機能、をコンピュータに実現させることを特徴としている。ここで、実行機能は、請求項7の発明における第1と第2の格納部に対応する各格納部にアクセスし、ワークフロー定義を用いてワークフローを特定し、データを参照してその特定されたワークフローに基づく状態遷移を実行する機能である。また、履歴格納機能は、状態遷移の実行履歴を第3の格納部に格納する機能である。また、状態特定機能は、ワークフロー定義もしくはデータの少なくとも一方の情報が変更された場合に、第3の格納部にアクセスして実行履歴を参照し、その情報の変更により影響を受ける状態を特定する機能である。さらに、再実行機能は、特定された状態から、情報の変更を反映したワークフローに基づいて状態遷移を再実行する機能である。
【0027】
以上のような発明によれば、状態遷移の実行時に参照するデータやワークフロー定義等の情報の変更を受け付けた場合に、実行履歴を利用して状態遷移を再実行することにより、「情報の変更」を反映したワークフローに基づいて遷移先の状態を決定することができるため、決定した状態と参照先のデータとの間の整合性を維持できる。したがって、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理することができる。
【0028】
また、再実行された状態遷移に係る実行履歴を保存することにより、保存された実行履歴と外部情報との間の整合性を維持できる。さらに、本発明による情報変更時の状態遷移の再実行は、通常の状態遷移の実行に準じた処理であるため、通常の状態遷移の実行を行う実行手段を利用して容易に実現可能である。すなわち、通常の実行手段に状態特定機能と再実行機能を持たせることにより、本発明による情報変更時の状態特定と状態遷移の再実行を容易に実現することができる。
【0029】
請求項5の発明は、請求項1乃至請求項4のいずれかのワークフロー実行方法において、状態特定ステップが履歴調整ステップを含むことを特徴としている。ここで、履歴調整ステップは、情報の変更を受け付けた際に、実行履歴中に同一の状態が複数回出現する場合には、その複数回の状態のうち、最終回以外の状態が影響を受ける状態として特定されないように、実行履歴の調整を行うステップである。
【0030】
この発明によれば、同じ状態が複数繰り返される場合でも、最終回1回の状態のみを特定することにより、「ワークフローに影響を与える情報の変更」を受け付けていない場合に状態遷移を再実行してしまう誤りを防止できる。すなわち、本発明においては、同じ状態が複数回繰り返され、各回の状態の遷移先が異なるような場合に、各回の状態から状態遷移を再実行すると、「ワークフローに影響を与える情報以外の情報の変更」を受け付けたにも拘わらず、「ワークフローに影響を与える情報の変更」で状態が変化したものと誤って判断してしまう可能性がある。この種の誤りは、上記のような実行履歴の調整を行うことにより、確実に防止することができる。
【0031】
【発明の実施の形態】
以下には、本発明の実施形態を図面に沿って具体的に説明する。ただし、ここで記載する実施形態は、本発明を何ら限定するものではなく、本発明の一態様を例示するものにすぎない。
【0032】
本発明は、典型的には、コンピュータをソフトウェアで制御することにより実現される。この場合のソフトウェアは、コンピュータのハードウェアを物理的に活用することで本発明の作用効果を実現するものであり、また、従来技術を適用可能な部分には好適な従来技術が適用される。さらに、本発明を実現するハードウェアやソフトウェアの具体的な種類や構成、ソフトウェアで処理する範囲などは自由に変更可能であり、例えば、本発明を実現するプログラムは本発明の一態様である。
【0033】
[1.システム構成]
図1は、本発明を適用した一つの実施形態に係るワークフローシステムの構成を示すブロック図である。この図1に示すように、本実施形態におけるワークフローシステム100は、アプリケーションプログラム110と組み合わされ、ソフトウェア開発における不具合管理システム等の情報管理システムを構成している。このワークフローシステム100は、制御データ120、ワークフロー駆動部130、ワークフロー定義140、状態データ150、ワークフロー実行履歴160、等のプログラムやデータから構成されている。
【0034】
これらのプログラムやデータは、コンピュータが基本的に備えているハードディスク等の記憶部に記憶されており、RAM等の作業領域上に読み出されてCPU等の演算処理部を活用することで、ワークフローシステムの機能をコンピュータに実現させるようになっている。以下には、このワークフローシステムの構成要素について順次説明する。
【0035】
アプリケーションプログラム(以下にはアプリケーションと略記する)110は、ワークフローシステム100を利用しようとする利用者または他のシステム等のユーザUからの要求を受けて、制御データ120、ワークフロー駆動部130、ワークフロー定義140等を操作するプログラムであり、制御データ120やワークフロー定義140の変更を受け付けるようになっている。
制御データ120は、ワークフロー駆動部130によりワークフロー定義の分岐条件評価時に参照されるデータであり、コンピュータの記憶部あるいは外部記憶装置における所定の格納領域(第2の格納部)に記憶されている。
【0036】
ワークフロー駆動部130、ワークフロー定義140、状態データ150、ワークフロー実行履歴160、等のプログラムやデータの集合は、ワークフローシステムの機能をアプリケーション110に提供するワークフローマネージャ170を構成している。なお、図1中においては、ワークフローマネージャ170を構成するプログラムやデータが、論理的または物理的に独立して存在している場合を示しているが、これらのプログラムやデータは明確に独立せずに部分的あるいは全体的に混然一体となって存在している場合もある。すなわち、本発明のワークフローシステムを構成するプログラムやデータの具体的な構造や保存形式は何ら限定されるものではなく、多様な構造や保存形式が可能である。
【0037】
ワークフロー駆動部130は、ワークフロー定義140に基づく状態遷移を実行するとともに、制御データ120やワークフロー定義140の変更時に状態遷移を再実行するプログラムである。すなわち、このワークフロー駆動部130は、ワークフロー定義140に従って、制御データ120を参照し、状態データ150を遷移させる実行機能と、状態遷移の履歴をワークフロー実行履歴160として記録する履歴格納機能を有するものである。
【0038】
このワークフロー駆動部130はまた、制御データ120やワークフロー定義140等のデータの変更時にワークフロー実行履歴160を参照し、その情報の変更により影響を受ける状態を特定する状態特定機能と、その特定された状態から、情報の変更を反映したワークフローに基づいて状態遷移を再実行する再実行機能を有するものであり、本発明における実行手段あるいは再実行手段を構成する。
【0039】
ワークフロー定義140は、状態とその遷移を定義したデータであり、各状態の定義は、状態名、遷移先の状態(次に遷移する状態の候補)、分岐条件(遷移先を決定する条件)等を含む。このワークフロー定義140は、コンピュータの記憶部における所定の格納領域(第1の格納部)に記憶されている。
状態データ150は、現在の状態を表現するデータであり、コンピュータの記憶部における所定の格納領域に記憶されている。状態データ150の状態は、ワークフロー定義140で定義されている。状態データ150は、制御データ120の一部として扱う場合もある。
【0040】
ワークフロー実行履歴160は、状態遷移の履歴を記録したデータであり、制御データ120やワークフロー定義140等のデータの変更時にワークフロー駆動部130によりそのデータ変更による不整合を解消するための処理に利用される。このワークフロー実行履歴160は、コンピュータの記憶部における所定の格納領域(第3の格納部)に記憶されている。
【0041】
[2.ワークフロー定義]
ワークフロー定義は、前述したように、状態とその遷移を定義したデータである。ここで、「状態」をその遷移に応じて大別すると、開始状態、途中状態、終了状態に分類できる。すなわち、開始状態から遷移を開始し、途中状態を経て、終了状態で遷移を終了する。なお、開始状態からそのまま終了状態に遷移する場合もある。
【0042】
いずれの場合であれ、開始状態の定義は、少なくとも、「状態名」、「遷移先の状態」、「分岐条件」を含む。途中状態の定義も、同様に、少なくとも、「状態名」、「遷移先の状態」、「分岐条件」を含む。これに対して、遷移を終了する終了状態の定義は、少なくとも「状態名」を含む。また、ワークフロー定義に使用されるこれらの情報:(「状態名」、「遷移先の状態」、「分岐条件」)はさらに、次のように定義される。
【0043】
「状態名」は、状態の名称を示す情報であり、実際の名称に限らず、簡略化された名称やその状態を示す番号や記号等、状態を特定可能な情報を広く含む概念である。
「遷移先の状態(以下では「遷移先」と略記する)」は、次に遷移する状態の候補を示す情報である。「遷移先」のいずれに遷移するかは、分岐条件により決定される。
「分岐条件」は、遷移する分岐先を決定するロジック(条件)である。「分岐条件」は、複雑な判断や、制御データやアプリケーションから渡されたデータの参照を含む場合がある。
【0044】
このような、「状態名」、「遷移先の状態」、「分岐条件」等の情報によって定義される状態を組み合わせることで、様々な処理手順のワークフロー定義を行うことができる。図2は、このようなワークフロー定義の一例を示す状態遷移図である。この図2においては、1つの開始状態210、4つの途中状態221〜224、3つの終了状態231〜233、という合計8個の状態の遷移が表現されている。
【0045】
この図2において、途中状態4(224)以外の3つの途中状態221〜223はいずれも、それぞれ2つの遷移先が定義されているため、分岐条件を評価して次の状態を決定することになる。この図2においては、一例として、途中状態1(221)に対して、「承認なら途中状態2へ、否認なら終了状態3へ」という分岐条件が定義され、また、途中状態2(222)に対して、「『金額』フィールドの値が10万未満なら途中状態3へ、10万以上なら途中状態4へ」という分岐条件が定義されている。
【0046】
なお、このようなワークフロー定義は、図1に示すように、ワークフロー駆動部130と論理的または物理的に独立して存在している場合もあるが、ワークフロー駆動部130に組み込まれている場合もある。すなわち、前述したように、本発明のワークフローシステムを構成するプログラムやデータの具体的な構造や保存形式は何ら限定されるものではなく、多様な構造や保存形式が可能であるため、ワークフロー駆動部やワークフロー定義の具体的な構造や保存形式についても、多様な構造や保存形式が可能である。
【0047】
[3.ワークフロー実行履歴]
ワークフロー実行履歴は、前述したように、状態遷移の履歴を記録したデータである。ワークフロー実行履歴としては、具体的には、「シーケンス番号」、「状態」、「アプリケーションから渡されたデータ」、「変更記録」、等の情報が記録される。また、ワークフロー実行履歴として記録されるこれらの情報:(「シーケンス番号」、「状態」、「アプリケーションから渡されたデータ」、「変更記録」)はさらに、次のように定義される。
【0048】
「シーケンス番号」は、ワークフロー実行履歴中における状態の時間的順序を示す一意的な番号である。
「状態」は、ワークフロー実行履歴中では、通過した状態を示しており、1つのシーケンス番号に1つの状態が対応付けられる。
【0049】
「アプリケーションから渡されたデータ」は、ワークフロー実行履歴中の各状態においてアプリケーションから渡されたデータを示しており、制御データに限らず、アプリケーションから渡された全てのデータを含む広い概念である。例えば、承認や否認などの指示は、制御データとは別にアプリケーションから一時的に渡される可能性があるが、そのようなデータを含む広い概念である。そして、「アプリケーションから渡されたデータ」の全てが、ワークフロー実行履歴の一部として記録される。
【0050】
「変更記録」は、再実行された状態遷移の履歴が再実行前の履歴から変更した場合にその履歴の変更を示す情報である。例えば、状態遷移の再実行前において、シーケンス番号「n」の状態「Sn」の遷移先は、シーケンス番号「n+1」の状態「Sn+1」であるが、状態遷移の再実行後に、シーケンス番号「n」の状態「Sn」の遷移先が、状態「Sn+1」以外のシーケンス番号「m」(m>n)の状態「Sm」に変更した場合には、シーケンス番号「n」の状態「Sn」の変更記録「An」に、そのシーケンス番号「m」を記録する。この場合、シーケンス番号「n」の変更記録「An」に記録されたシーケンス番号「m」は、シーケンス番号「n」の履歴の次の履歴がシーケンス番号「m」の履歴に変更されたことを示す。
【0051】
表1は、「シーケンス番号」、「状態」、「アプリケーションら渡されたデータ」、「変更記録」という4つの項目からなるワークフロー実行履歴を示している。この表1は、図2に示したワークフロー定義に基づいて通常の状態遷移を実行した場合のワークフロー実行履歴の一例を示しており、変更記録は空欄である。この表1の履歴は、シーケンス番号を昇順に、すなわち、1→2→3→4→5の順で遷移したことを示している。
【0052】
【表1】
【0053】
また、表2は、表1に示すワークフロー実行履歴について、状態遷移を再実行した後に、3行目のシーケンス番号「3」の状態「途中状態2」の遷移先が変更してそのシーケンス番号「3」の変更記録に、シーケンス番号「6」が記録された一例を示している。この場合、シーケンス番号「3」の変更記録に記録されたシーケンス番号「6」は、シーケンス番号「3」の履歴の次の履歴がシーケンス番号「6」の履歴に変更されたことを示している。すなわち、この例における変更後の履歴は、1→2→3→6となる。
【0054】
【表2】
【0055】
[4.ワークフローシステムの動作]
図3は、本実施形態におけるワークフローシステムの動作の概略を示すフローチャートである。この図3に示すように、アプリケーション110は、ユーザUからのデータ登録要求を受け付けると(S301のYES)、入力されたデータを制御データ120として記録する(S302)。この場合に、アプリケーション110は、ワークフロー駆動部130に状態遷移の実行を指示し、この指示に従って、ワークフロー駆動部130は、通常の動作である状態遷移を実行する(S303)。
【0056】
これに対して、アプリケーション110は、ユーザUからの、制御データ120またはワークフロー定義140の変更要求を受け付けると(S301のNO、S311のYES)、入力されたデータに応じて、制御データ120またはワークフロー定義140を更新する(S312)。この場合に、アプリケーション110は、データ変更による不整合を自動的に解消するために、ワークフロー駆動部130に状態遷移の再実行を指示し、この指示に従って、ワークフロー駆動部130は、ワークフロー実行履歴を利用して状態遷移を再実行する(S313)。
【0057】
[4−1.ワークフロー駆動部の通常の動作]
図4は、ワークフロー駆動部130の通常の動作を示すフローチャートであり、図3に示す状態遷移の実行ステップ(S303)のサブルーチンに相当する。
【0058】
この図4に示すように、ワークフロー駆動部130は、状態データ150から現在の状態を読み込む(S401)。ワークフロー駆動部130は次に、その読み込んだ状態について、ワークフロー定義140から、その状態の定義を読み込む(S402)。ワークフロー駆動部130は、読み込んだ状態の定義に含まれる分岐条件を評価して、評価の結果に基づき、読み込んだ状態の定義に含まれる遷移先の中から次に遷移する状態を決定する(S403)。この場合、分岐条件の内容に応じて、制御データ120やアプリケーション110から渡されたデータを評価に利用することもある。
【0059】
ワークフロー駆動部130は、状態遷移の実行結果をワークフロー実行履歴160に記録する(S404)。すなわち、アプリケーション110から渡されたデータがある場合には、ワークフロー実行履歴160の現在の最終行にそのデータを記録すると共にさらに1行追加し、決定した遷移先の状態を記録する。また、アプリケーション110から渡されたデータがない場合には、ワークフロー実行履歴160に1行追加して決定した遷移先の状態の記録のみを行うことになる。なお、決定した遷移先の状態は、現在の状態を示す状態データ150にも記録される(S405)。
【0060】
例えば、前記図2のワークフロー定義に基づく前記表1のワークフロー実行履歴の例において、現在の状態が2行目の状態「途中状態1」であり、アプリケーションから「承認」のデータを渡されてその「途中状態1」の状態遷移を実行し、次の遷移先を「途中状態2」に決定した際の記録処理は、次のようになる。すなわち、この場合に、ワークフロー駆動部130は、データ「承認」を「アプリケーションから渡されたデータ」として記録すると共に、さらに3行目を追加し、決定した遷移先の状態「途中状態2」の記録を追加することになる。
【0061】
[4−2.ワークフロー駆動部による状態遷移の再実行]
前述したように、制御データ120またはワークフロー定義140の変更が行われた場合に、ワークフロー駆動部130は、データ変更による不整合を自動的に解消するために、ワークフロー実行履歴160を利用して状態遷移を再実行する。図5は、このようなワークフロー駆動部130による状態遷移を再実行するフローチャートであり、図3に示す状態遷移の再実行ステップ(S313)のサブルーチンに相当する。
【0062】
この図5に示すように、ワークフロー駆動部130はまず、ワークフロー実行履歴160中に同一の状態が複数回出現する場合における状態遷移の再実行を正常に行うために、ワークフロー実行履歴の調整を行うことにより、状態遷移の再実行の対象となる実行履歴を抽出する(S501)。なお、このワークフロー実行履歴の調整の詳細については後述するため、ここでは説明を省略する。
【0063】
ワークフロー駆動部130は次に、調整によって抽出されたワークフロー実行履歴の先頭行「n」(シーケンス番号「k」)に記録された履歴を読み込み(S502)、その履歴の状態について、ワークフロー定義140の中から、その状態の定義を読み込む(S503)。ワークフロー駆動部130は、読み込んだ状態の定義に含まれる分岐条件を評価し、遷移先の状態を決定する(S504)。ここで、分岐条件が、アプリケーション110から渡されたデータの参照を含む場合、状態遷移の再実行時にはアプリケーション110からデータを渡されないので、代わりにワークフロー実行履歴160に記録されている「アプリケーションから渡されたデータ」を参照する。
【0064】
ワークフロー駆動部130は続いて、ワークフロー実行履歴160から、前回読み込んだ履歴の次の履歴を示す行を読み込む。すなわち、前回読み込んだ履歴の変更記録にシーケンス番号が記録されていない場合には、S502で状態を読み込んだn行目のシーケンス番号「k」より大きく、「k」に最も近いシーケンス番号「k+α」(α≧1)の行の履歴を、「次の履歴」として読み込む。これに対して、前回読み込んだ履歴の変更記録にシーケンス番号が記録されている場合には、そのシーケンス番号で示される履歴を、「次の履歴」として読み込む(S505)。
【0065】
そして、S504の評価結果として決定した状態と、S505で読み込んだ履歴の状態とを比較する(S506)。評価結果と履歴の状態が一致している場合(S506のYES)には、S505で読み込んだ行を未検索の先頭行「n」として、S503から繰り返す。すなわち、S506の比較結果が一致している間、あるいは、ワークフロー実行履歴160の最後に達しない間(S507のNO)は、S503〜S506を繰り返す。
【0066】
ワークフロー実行履歴の最後まで比較した場合(S507のYES)は、状態が変化しなかったものと判定し、何もせずに終了する。また、比較結果が一致しない場合(S506のNO)には、状態が変化したものと判定し、ワークフロー実行記録160に1行追加し、S504の評価結果として決定した状態を記録する(S508)。この場合、評価した状態の行に変更記録もつける。なお、評価結果として決定した状態は、現在の状態を示す状態データ150にも記録される(S509)。
【0067】
例えば、前記図2のワークフロー定義に基づく前記表1のワークフロー実行履歴の例において、状態遷移を再実行した場合に、3行目の状態「途中状態2」の分岐条件の評価により決定した状態が、「途中状態4」となり、ワークフロー実行履歴中における次の行(4行目)の状態「途中状態3」と一致しない場合の記録内容は、次のようになる。すなわち、この場合に、ワークフロー駆動部130は、表1に示すワークフロー実行記録にシーケンス番号「6」の6行目を追加し、評価結果として決定した状態「途中状態4」を記録する。この場合、評価した状態「途中状態2」の行の変更記録に、次の履歴のシーケンス番号である「6」を記録することになる。このような記録の更新により、表2に示すような変更後のワークフロー実行履歴が得られる。
【0068】
[4−3.ワークフロー実行履歴の調整]
前述したように、ワークフロー駆動部130は、ワークフロー実行履歴中に同一の状態が複数回出現する場合における状態遷移の再実行を正常に行うために、ワークフロー実行履歴の調整を行う。ここではまず、同一の状態が複数回出現する場合について、すなわち、ワークフロー実行履歴の調整が必要な場合について説明する。
【0069】
一般的に、ワークフローシステムでは、ループになったワークフロー定義をすることがある。その場合、同じ状態を何度も通る可能性があり、1回目と2回目で制御データが変更すれば遷移先が変わる可能性もある。このような場合に、ワークフロー実行履歴の先頭から検索をすると、2回目で更新されたデータを使って1回目の状態をチェックするため、状態の変更が発生したと誤認識する可能性がある。
【0070】
この誤認識の問題について、図6に示すワークフロー定義に基づく状態遷移を、表3に示すワークフロー実行履歴で実行した場合を例に説明する。ここで、図6のワークフロー定義においては、「発見」610、「修正」620、「部長承認」631、「課長承認」632、「確認」640、「完了」650、という状態とその遷移が定義されている。このワークフロー定義の内容は次の通りである。
【0071】
すなわち、開発者によって作成されたソフトウェアについて、状態「発見」610において発見された不具合は、状態「修正」620において開発者によって修正され、そのバグランクが登録/変更される。この場合、状態「修正」620には、遷移先として、状態「部長承認」631、「課長承認」632の2つが定義されており、分岐条件として、「バグランク:A→部長承認、A以外→課長承認」が定義されている。バグランクは、制御データの一部であり、「修正」時に開発者によって登録/変更される。これに関連して、表3のワークフロー実行履歴には、便宜的に、その時点の制御データのバグランクも併記した。
【0072】
また、状態「部長承認」631、「課長承認」632の遷移先としては、状態「確認」640、「修正」620の2つが定義されており、分岐条件として、「承認→確認、否認→修正」が定義されている。さらに、状態「確認」640の遷移先としては、状態「完了」650、「修正」620の2つが定義されており、分岐条件として、「確認結果:OK→完了、NG→修正」が定義されている。確認結果は、制御データの一部であり、「確認」時に担当者によって登録/変更される。
【0073】
【表3】
【0074】
この表3に示すワークフロー実行履歴では、1度目の「修正」時にはバグランクを「B」として登録したが、2度目の「修正」で「A」に変更している。その後、分岐条件とは関係ない制御データを変更し、ワークフロー実行履歴の先頭から状態遷移を再実行すると、バグランクが「A」になっているため、遷移先として「部長承認」が導き出されてしまう。この場合、ワークフロー実行履歴と状態遷移の再実行で得られた結果が異なるため、ワークフロー駆動部130は、データ変更で状態が変化したものと判断し、新しい状態を「部長承認」と決定してしまう。
【0075】
次の表4は、この場合のワークフロー実行履歴と状態遷移の再実行で得られた結果の比較を示しており、「○」は一致、「×」は不一致である。しかし、本来は、分岐条件とは関係ない制御データを変更しているため、状態は変わらないはずである。
【表4】
【0076】
このように、同じ状態を複数回通っていると、状態遷移の再実行を正常に行うことができなくなるという問題を生じる。本実施形態のワークフローシステムでは、この問題を解決するために、ワークフロー実行履歴の調整を行う。具体的な調整の方法は、いくつか考えられるが、ここでは、代表的な2つの方法として、「同一の状態が複数回出現するか否かをチェックする方法」と、「ユーザに指定された状態が最後に出現する位置をチェックする方法」について説明する。
【0077】
まず、「同一の状態が複数回出現するか否かをチェックする方法」は、ワークフロー実行履歴を先頭からチェックして、「一度出現した状態が次に出現する場合には、その前回の状態の位置から今回の状態が出現する前までの履歴を削除する」、という処理を、ワークフロー実行履歴の最後まで行う方法である。表3の例では、シーケンス番号「2」の状態「修正」が、シーケンス番号「5」にも出現するため、シーケンス番号「2」から「4」までの行を削除することになる。この結果、次の表5に示すような、調整後のワークフロー実行履歴が得られる。
【0078】
【表5】
【0079】
この表5に示すように、ワークフロー実行履歴中に同一の状態が複数回出現する場合であっても、その複数回の状態のうち、最終回の状態のみが残るので、ワークフロー駆動部130は、状態遷移の再実行を正常に行うことができる。表6は、表5に示すワークフロー実行履歴を用いて状態遷移を再実行した場合における、ワークフロー実行履歴と状態遷移の再実行で得られた結果の比較を示している。
【0080】
【表6】
【0081】
次に、「ユーザに指定された状態が最後に出現する位置をチェックする方法」は、ユーザに状態遷移の再実行を開始する状態を指定させ、ワークフロー実行履歴を最後からチェックして、その状態が出現する位置を特定し、その位置よりも前の履歴を削除する方法である。表3の例では、状態「修正」から状態遷移の再実行が指定されたとすると、ワークフロー実行履歴の最後から状態「修正」を探すことになる。シーケンス番号「5」において状態「修正」が出現するので、シーケンス番号「5」よりも前の行を削除することになる。この結果、次の表7に示すような、調整後のワークフロー実行履歴が得られる。
【0082】
【表7】
【0083】
この表7に示すように、ワークフロー実行履歴中に同一の状態が複数回出現する場合であっても、その複数回の状態のうち、最終回の状態より前は無視するので、ワークフロー駆動部130は、状態遷移の再実行を正常に行うことができる。表8は、表7に示すワークフロー実行履歴を用いて状態遷移を再実行した場合における、ワークフロー実行履歴と状態遷移の再実行で得られた結果の比較を示している。
【0084】
【表8】
【0085】
[5.ワークフロー駆動部の動作例]
以下には、具体的なワークフロー定義とワークフロー実行履歴を想定した上で、ワークフロー駆動部の具体的な動作例について説明する。まず、ワークフロー定義としては、図6に示すワークフロー定義を使用するものとする。この図6に示すワークフロー定義の内容については前述したため、ここでは説明を省略する。このワークフロー定義を用いて、状態「修正」まで遷移した時点でのワークフロー実行履歴と状態データを、次の表9、表10に示す。
【0086】
【表9】
【表10】
【0087】
以下の説明では、図6のワークフロー定義に基づくこの状態「修正」から通常の状態遷移を実行した場合の動作例と、その後に状態遷移を再実行した場合の動作例について、具体的な制御データ等を含めて詳細に説明する。
【0088】
[5−1.通常の動作]
ここでは、表9、表10に示すように、図6のワークフロー定義を用いて状態「修正」まで遷移した時点で、ユーザにより制御データが入力され、アプリケーション110から次の状態に遷移するように指示された場合のワークフロー駆動部130の動作について説明する。ワークフロー駆動部130の通常の動作は、前述したように、図4のフローチャートに沿って行われる。なお、ユーザから入力された制御データは、図7に示すような、「発見日時」、「発見者」、「危険度」、「バグランク」、「現象」、等の情報を含む帳票データであるものとする。
【0089】
ワークフロー駆動部130はまず、状態データ150から現在の状態である「修正」を読み込む(S401)。ワークフロー駆動部130は次に、その読み込んだ状態「修正」について、ワークフロー定義140から、その状態「修正」の定義を読み込む(S402)。ワークフロー駆動部130は、読み込んだ状態「修正」の定義に含まれる分岐条件を評価して遷移先を決定する(S403)。この場合、状態「修正」の分岐条件は、制御データのバグランクの参照を含む。図7に示す制御データのバグランクは「B」であるため、ワークフロー駆動部130は、状態「課長承認」を遷移先として決定する。
【0090】
ワークフロー駆動部130は、状態「課長承認」に遷移したことをワークフロー実行履歴に記録する(S404)。すなわち、表9に示すワークフロー実行履歴にさらにシーケンス番号「3」の行を1行追加し、決定した遷移先の状態「課長承認」を記録する。なお、決定した新しい状態「課長承認」は、現在の状態を示す状態データにも記録される(S405)。次の表11、表12は、この時点でのワークフロー実行履歴と状態データをそれぞれ示している。
【0091】
【表11】
【表12】
【0092】
[5−2.状態遷移の再実行]
ここでは、表11、表12に示すように、図6のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザにより制御データまたはワークフロー定義の変更要求が入力され、アプリケーション110がその変更要求に基づくデータ変更を行った際に、アプリケーション110からの状態遷移の再実行の指示に基づくワークフロー駆動部130の動作について説明する。
【0093】
ワークフロー駆動部130による状態遷移の再実行は、前述したように、図5のフローチャートに沿って行われるが、その具体的な動作の流れは、制御データの変更が状態を変化させない場合、制御データの変更が状態を変化させる場合、ワークフロー定義を変更した場合、でそれぞれ異なるため、以下には、この3パターンの動作例について順次説明する。なお、ワークフロー実行履歴の調整には、前述した2つの方法のうち、「同一の状態が複数回出現するか否かをチェックする方法」を採用するものとする。
【0094】
[5−2−1.制御データの変更が状態を変化させない場合]
ここでは、表11、表12に示すように、図6のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザの変更要求に基づき、アプリケーション110により、図7の制御データ中の「現象」のデータが、図8に示すように変更されたものとする。
【0095】
この場合に、ワークフロー駆動部130はまず、ワークフロー実行履歴の調整を行うことにより、状態遷移の再実行の対象となる状態を特定する(S501)。この場合、表11に示すワークフロー実行履歴を先頭からチェックしても、一度出現した状態が次に出現することはないため、この表11に示すワークフロー実行履歴がそのまま状態遷移の再実行の対象として特定されることになる。
【0096】
ワークフロー駆動部130は次に、表11に示すワークフロー実行履歴のシーケンス番号「1」の1行目に記録された状態「発見」を読み込み(S502)、その状態「発見」について、図6のワークフロー定義の中から、その状態「発見」の定義を読み込む(S503)。ワークフロー駆動部130は、読み込んだ状態「発見」の定義に含まれる分岐条件を評価し、次の状態を決定する(S504)。この場合、状態「発見」には分岐条件がないので、無条件に次の状態「修正」が決定される。
【0097】
ワークフロー駆動部130は続いて、表11のワークフロー実行履歴から、状態「発見」を読み込んだ1行目の次の行である2行目の履歴を読み込む(S505)。この場合、評価結果として決定した状態と、ワークフロー実行履歴中の次の状態とを比較すると、いずれも「修正」で一致している(S506のYES)ので、S505で読み込んだ行の状態「修正」について、図6のワークフロー定義の中から、その状態「修正」の定義を読み込む(S503)。
【0098】
ワークフロー駆動部130は、読み込んだ状態「修正」の定義に含まれる分岐条件を評価し、次の状態を決定する(S504)。この場合、状態「修正」の分岐条件は、制御データのバグランクの参照を含むが、図8の制御データ中で変更されたのは「現象」のデータだけであり、バグランクは何ら変更されていないので、次の状態は「課長承認」となる。
【0099】
ワークフロー駆動部130は続いて、表11のワークフロー実行履歴から、状態「修正」を読み込んだ2行目の次の行である3行目の履歴を読み込む(S505)。この場合、評価結果として決定した状態と、ワークフロー実行履歴中の次の状態とを比較すると、いずれも「課長承認」で一致している(S506のYES)。この場合、表11に示すワークフロー実行履歴の最後の行に達した(S507のYES)ので、状態は変化しなかったものと判断し、何もせずに終了する。
【0100】
次の表13は、表11に示すワークフロー実行履歴と以上の状態遷移の再実行で得られた結果の比較を示している。
【表13】
【0101】
[5−2−2.制御データの変更が状態を変化させる場合]
ここでは、表11、表12に示すように、図6のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザの変更要求に基づき、アプリケーション110により、図7の制御データ中では「B」であったバグランクが、図9に示すように「A」に変更されたものとする。
【0102】
この場合に、ワークフロー駆動部130はまず、ワークフロー実行履歴の調整を行うが、前述したように、表11に示すワークフロー実行履歴を先頭からチェックしても、一度出現した状態が次に出現することはないため、この表11に示すワークフロー実行履歴がそのまま状態遷移の再実行の対象として特定されることになる。
【0103】
ワークフロー駆動部130が、表11に示すワークフロー実行履歴の1行目に記録された状態「発見」を読み込み、その状態「発見」の定義を読み込んで次の状態を「修正」に決定し、ワークフロー実行履歴中の次の状態と比較した後、その状態「修正」の定義を読み込むまでの動作は、前述した「制御データの変更が状態を変化させない場合」の動作と同様である。
【0104】
この場合、読み込んだ状態「修正」の定義に含まれる分岐条件を評価すると、図9の制御データ中でバグランクが「B」から「A」に変更されているので、次の状態は「部長承認」となる(S504)。ワークフロー駆動部130は続いて、表11のワークフロー実行履歴から、状態「修正」を読み込んだ2行目の次の行である3行目の履歴を読み込む(S505)。
【0105】
次に、評価結果として決定した状態と、ワークフロー実行履歴中の次の状態とを比較すると、決定した状態「部長承認」と履歴中の次の状態「課長承認」とは一致していない(S506のNO)ので、状態は変化したものと判定して、表11に示すワークフロー実行記録にシーケンス番号「4」の4行目を追加し、評価結果として決定した状態「部長承認」を記録する(S508)。この場合、評価した状態「修正」の行の変更記録に、次の履歴のシーケンス番号である「4」を記録する。変更後の新しいワークフロー実行履歴は、1→2→4となる。なお、評価結果として決定した状態「部長承認」は、現在の状態を示す状態データにも記録される(S509)。
【0106】
次の表14は、表11に示すワークフロー実行履歴と以上の状態遷移の再実行で得られた結果の比較を示している。
【表14】
【0107】
また、次の表15、表16は、以上の状態遷移の再実行で更新された変更後のワークフロー実行履歴と状態データをそれぞれ示している。
【表15】
【表16】
【0108】
[5−2−3.ワークフロー定義を変更した場合]
ここでは、表11、表12に示すように、図6のワークフロー定義を用いて状態「課長承認」まで遷移した時点で、ユーザの変更要求に基づき、アプリケーション110により、図6に示すワークフロー定義中の「修正」の分岐条件が、「バグランク:A→部長承認、A以外→課長承認」から、「バグランク:A、B→部長承認、A、B以外→課長承認」に変更されたものとする。
【0109】
この場合に、ワークフロー駆動部130が、表11に示すワークフロー実行履歴をそのまま状態遷移の再実行の対象として特定した後、ワークフロー実行履歴の1行目に記録された状態「発見」とその定義を読み込んで次の状態を「修正」に決定し、ワークフロー実行履歴中の次の状態と比較した後、状態「修正」の定義を読み込むまでの動作は、前述した「制御データの変更が状態を変化させない場合」の動作と同様である。
【0110】
この場合、読み込んだ状態「修正」の定義に含まれる分岐条件を評価すると、制御データ中のバグランクは「B」と変わっていないが、分岐条件自体が「バグランク:A、B→部長承認、A、B以外→課長承認」に変更されているので、次の状態は「部長承認」となる(S504)。ワークフロー駆動部130は続いて、表11のワークフロー実行履歴から、状態「修正」を読み込んだ2行目の次の行である3行目の履歴を読み込み(S505)、評価結果として決定した状態と比較する(S506)。
【0111】
この場合、決定した状態「部長承認」と履歴中の次の状態「課長承認」とは一致していない(S506のNO)ので、状態は変化したものと判定して、表11に示すワークフロー実行記録にシーケンス番号「4」の4行目を追加し、評価結果として決定した状態「部長承認」を記録する(S508)。この場合、評価した状態「修正」の行の変更記録に、次の履歴のシーケンス番号である「4」を記録する。変更後の新しいワークフロー実行履歴は、1→2→4となる。なお、評価結果として決定した状態「部長承認」は、現在の状態を示す状態データにも記録される(S509)。
【0112】
次の表17は、表11に示すワークフロー実行履歴と以上の状態遷移の再実行で得られた結果の比較を示している。
【表17】
【0113】
また、次の表18、表19は、以上の状態遷移の再実行で更新された変更後のワークフロー実行履歴と状態データをそれぞれ示している。
【表18】
【表19】
【0114】
[6.実施形態の作用効果]
以上のような本実施形態のワークフローシステムとワークフロー実行方法によれば、状態遷移の実行時に参照する制御データやワークフロー定義等の情報の変更を受け付けた場合に、ワークフロー実行履歴を利用して状態遷移を再実行することにより、「情報の変更」を反映したワークフローに基づいて遷移先の状態を決定することができるため、決定した状態と参照先の制御データとの間の整合性を維持できる。
【0115】
したがって、本実施形態の手法によれば、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順をワークフローとして定義し、そのワークフロー定義に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理することができる。このような本実施形態の手法は、特に、ソフトウェア開発における不具合管理に好適であり、データ変更による不整合の問題を生じることなしに大量の不具合を効率よく適切に処理することができる。
【0116】
また、再実行された状態遷移に係るワークフロー実行履歴を保存することにより、保存されたワークフロー実行履歴と制御データ等の外部情報との間の整合性を維持できる。さらに、本発明による情報変更時の状態遷移の再実行は、通常の状態遷移の実行に準じた処理であるため、通常の状態遷移の実行を行うワークフロー駆動部の機能を若干変更するだけで容易に実現可能である。すなわち、通常のワークフロー駆動部に状態特定機能と再実行機能を持たせることにより、本発明による情報変更時の状態遷移の再実行を容易に実現することができる。
【0117】
さらに、ワークフロー実行履歴中に同じ状態が複数回出現する場合でも、ワークフロー実行履歴の調整を行い、その複数回の状態のうち、最終回の状態のみを特定して状態遷移を再実行することにより、状態遷移の再実行を正常に行うことができる。
【0118】
[7.他の実施形態]
なお、本発明は、前述した実施形態に限定されるものではなく、本発明の範囲内で他にも多種多様な形態が実施可能である。
【0119】
まず、図1に示したシステム構成や、図3〜図5に示したワークフロー実行手順は、一例にすぎず、具体的なシステム構成や実行手順は自由に変更可能である。また、図6に示したワークフロー定義や図7に示した制御データも一例にすぎず、本発明で具体的に使用するデータやプログラムを含めた具体的なデータ構造は自由に選択可能である。さらに、本発明は、前述した通り、ソフトウェア開発における不具合管理に好適であるが、それに限らず、ワークフローシステムを採用した各種の分野における情報管理システム一般に広く適用可能であり、同様に優れた効果が得られるものである。
【0120】
【発明の効果】
以上詳述したように、本発明によれば、状態遷移の実行時に参照するデータやワークフロー定義等の変更を受け付けた場合に、実行履歴を利用して状態遷移を再実行することにより、情報管理システムの中心となる処理手順として、「差戻し」等の処理を含まない簡略な処理手順を定義し、その手順に従ってデータ変更による不整合の問題を生じることなしに大量の情報を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することができる。
【0121】
したがって、本発明によれば、ソフトウェア開発における不具合管理システムに好適で、データ変更による不整合の問題を生じることなしに大量の不具合を効率よく適切に処理可能なワークフロー実行方法とシステムを提供することができる。
【図面の簡単な説明】
【図1】本発明を適用した一つの実施形態に係るワークフローシステムの構成を示すブロック図。
【図2】図1に示すワークフローシステムで使用するワークフロー定義の一例を示す状態遷移図。
【図3】図1に示すワークフローシステムの動作の概略を示すフローチャート。
【図4】図1に示すワークフロー駆動部の通常の動作として、図3に示す状態遷移の実行ステップのサブルーチンに相当する動作を示すフローチャート。
【図5】図1に示すワークフロー駆動部のデータ変更時の動作として、図3に示す状態遷移の再実行ステップのサブルーチンに相当する動作を示すフローチャート。
【図6】図1に示すワークフローシステムで使用するワークフロー定義の一例を示す状態遷移図。
【図7】図1に示すワークフローシステムで使用する制御データの一例を示す説明図。
【図8】図7に示す制御データを変更した一例を示す説明図。
【図9】図7に示す制御データを変更した別の一例を示す説明図。
【図10】ソフトウェア開発における不具合処理手順の一例を示す状態遷移図。
【図11】ワークフロー定義に基づいて決定した状態と参照した外部情報との間に不整合を生じるという問題点を説明するための説明図。
【符号の説明】
100...ワークフローシステム
110...アプリケーションプログラム
120...制御データ
130...ワークフロー駆動部
140...ワークフロー定義
150...状態データ
160...ワークフロー実行履歴
170...ワークフローマネージャ
U...ユーザ(利用者または他のシステム)
Claims (9)
- ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフロー実行方法において、
前記ワークフローに影響を与える情報の変更を受け付けた場合に、前記実行履歴から前記情報の変更により影響を受ける状態を特定する状態特定ステップと、
前記特定された状態から、前記情報の変更を反映したワークフローに基づいて状態遷移を再実行する再実行ステップとを含む、
ことを特徴とするワークフロー実行方法。 - 前記再実行された状態遷移と前記実行履歴に保存された状態遷移とを比較し、これら状態遷移の間に差がある場合は、再実行された状態遷移にかかる実行履歴を保存する履歴更新ステップを含む、
ことを特徴とする請求項1に記載のワークフロー実行方法。 - 前記状態遷移のうち、少なくとも一つの状態から次の状態への遷移は、予め指定されたデータを参照して実行され、前記情報の変更はそのデータの変更を含む、
ことを特徴とする請求項1または請求項2に記載のワークフロー実行方法。 - 前記ワークフローは、前記状態遷移を定義したワークフロー定義に基づいて決定され、前記情報の変更はそのワークフロー定義の変更を含む、
ことを特徴とする請求項1乃至請求項3のいずれかに記載のワークフロー実行方法。 - 前記状態特定ステップは、前記情報の変更を受け付けた際に、前記実行履歴中に同一の状態が複数回出現する場合には、その複数回の状態のうち、最終回以外の状態が前記影響を受ける状態として特定されないように、実行履歴の調整を行う履歴調整ステップを含む、
ことを特徴とする請求項1乃至請求項4のいずれかに記載のワークフロー実行方法。 - ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローシステムにおいて、
前記ワークフローに影響を与える情報の変更を受け付けた場合に、前記実行履歴から前記情報の変更により影響を受ける状態を特定する状態特定手段と、
前記特定された状態から、前記情報の変更を反映したワークフローに基づいて状態遷移を再実行する再実行手段とを備えた、
ことを特徴とするワークフローシステム。 - ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローシステムにおいて、
状態名、次に遷移する状態の候補、遷移先を決定する条件、に関する情報を用いて前記状態遷移を定義したワークフロー定義を記憶する第1の格納部と、
前記ワークフロー定義に含まれる前記条件を評価するためのデータを記憶する第2の格納部と、
前記ワークフロー定義を用いてワークフローを特定し、前記データを参照してその特定されたワークフローに基づく状態遷移を実行する実行手段と、
前記状態遷移の実行履歴を記憶する第3の格納部とを備え、
前記実行手段は、前記ワークフロー定義もしくは前記データの少なくとも一方の情報が変更された場合に、前記実行履歴からその情報の変更により影響を受ける状態を特定し、その特定された状態から、前記情報の変更を反映したワークフローに基づいて状態遷移を再実行するように構成された、
ことを特徴とするワークフローシステム。 - ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローを実行するためのプログラムにおいて、
前記ワークフローに影響を与える情報の変更を受け付けた場合に、前記実行履歴から前記情報の変更により影響を受ける状態を特定する状態特定機能と、
前記特定された状態から、前記情報の変更を反映したワークフローに基づいて状態遷移を再実行する再実行機能と、
をコンピュータに実現させることを特徴とするワークフロー実行プログラム。 - ワークフローに基づいて状態遷移を実行するとともに、その実行履歴を保存するワークフローを実行するためのプログラムにおいて、
状態名、次に遷移する状態の候補、遷移先を決定する条件、に関する情報を用いて前記状態遷移を定義したワークフロー定義を記憶する第1の格納部と、前記ワークフロー定義に含まれる前記条件を評価するためのデータを記憶する第2の格納部にアクセスし、前記ワークフロー定義を用いてワークフローを特定し、前記データを参照してその特定されたワークフローに基づく状態遷移を実行する実行機能と、
前記状態遷移の実行履歴を第3の格納部に格納する履歴格納機能と、
前記ワークフロー定義もしくは前記データの少なくとも一方の情報が変更された場合に、前記第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 true JP2004118553A (ja) | 2004-04-15 |
JP4150566B2 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) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005285101A (ja) * | 2004-03-02 | 2005-10-13 | Ricoh Co Ltd | プロセス管理装置、プロセス編集装置、プロセス管理プログラム、プロセス編集プログラム、記録媒体、プロセス管理方法及びプロセス編集方法 |
JP2009505226A (ja) * | 2005-08-09 | 2009-02-05 | マイクロソフト コーポレーション | サーバ側のプロジェクトマネージャ |
JP2009110276A (ja) * | 2007-10-30 | 2009-05-21 | Toshiba Corp | 顧客対応作成管理装置、顧客対応管理システム、及び顧客対応作成管理プログラム |
JP2009258912A (ja) * | 2008-04-15 | 2009-11-05 | Canon Inc | ワークフロー実行装置、ワークフロー実行方法、及びコンピュータプログラム |
JP2009271839A (ja) * | 2008-05-09 | 2009-11-19 | Canon Software Inc | 情報処理システム、情報処理方法、プログラム、及び、記録媒体 |
JP2018195040A (ja) * | 2017-05-17 | 2018-12-06 | 株式会社日立製作所 | ビジネスプロセス評価装置及びビジネスプロセス評価方法 |
JP2019159421A (ja) * | 2018-03-07 | 2019-09-19 | 株式会社リコー | 電子機器、プログラム、ワークフロー実行制御方法及び情報処理システム |
CN112416476A (zh) * | 2020-11-25 | 2021-02-26 | 武汉联影医疗科技有限公司 | 工作流执行方法、装置、计算机设备和存储介质 |
JP2021060802A (ja) * | 2019-10-07 | 2021-04-15 | 富士ゼロックス株式会社 | 情報処理装置及びプログラム |
-
2002
- 2002-09-26 JP JP2002281375A patent/JP4150566B2/ja not_active Expired - Fee Related
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005285101A (ja) * | 2004-03-02 | 2005-10-13 | Ricoh Co Ltd | プロセス管理装置、プロセス編集装置、プロセス管理プログラム、プロセス編集プログラム、記録媒体、プロセス管理方法及びプロセス編集方法 |
JP4676784B2 (ja) * | 2004-03-02 | 2011-04-27 | 株式会社リコー | プロセス管理装置、プロセス管理方法及びプロセス管理プログラム |
JP2009505226A (ja) * | 2005-08-09 | 2009-02-05 | マイクロソフト コーポレーション | サーバ側のプロジェクトマネージャ |
JP2009110276A (ja) * | 2007-10-30 | 2009-05-21 | Toshiba Corp | 顧客対応作成管理装置、顧客対応管理システム、及び顧客対応作成管理プログラム |
JP2009258912A (ja) * | 2008-04-15 | 2009-11-05 | Canon Inc | ワークフロー実行装置、ワークフロー実行方法、及びコンピュータプログラム |
JP2009271839A (ja) * | 2008-05-09 | 2009-11-19 | Canon Software Inc | 情報処理システム、情報処理方法、プログラム、及び、記録媒体 |
JP2018195040A (ja) * | 2017-05-17 | 2018-12-06 | 株式会社日立製作所 | ビジネスプロセス評価装置及びビジネスプロセス評価方法 |
JP2019159421A (ja) * | 2018-03-07 | 2019-09-19 | 株式会社リコー | 電子機器、プログラム、ワークフロー実行制御方法及び情報処理システム |
JP2021060802A (ja) * | 2019-10-07 | 2021-04-15 | 富士ゼロックス株式会社 | 情報処理装置及びプログラム |
JP7395934B2 (ja) | 2019-10-07 | 2023-12-12 | 富士フイルムビジネスイノベーション株式会社 | 情報処理装置及びプログラム |
CN112416476A (zh) * | 2020-11-25 | 2021-02-26 | 武汉联影医疗科技有限公司 | 工作流执行方法、装置、计算机设备和存储介质 |
CN112416476B (zh) * | 2020-11-25 | 2023-03-24 | 武汉联影医疗科技有限公司 | 工作流执行方法、装置、计算机设备和存储介质 |
Also Published As
Publication number | Publication date |
---|---|
JP4150566B2 (ja) | 2008-09-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106030533B (zh) | 通过拆分过程执行自动重试事务 | |
US5191534A (en) | Engineering and manufacturing change control mechanism | |
US9703692B2 (en) | Development supporting system | |
US8225302B2 (en) | System and method for managing source code and acquiring metrics in software development | |
US7844948B2 (en) | Maintaining multiple valid concurrent serialized object versions | |
JP4937022B2 (ja) | 順序関係解析装置、方法及びプログラム | |
JP2009527055A (ja) | 同期ピア参加モデル | |
WO2019047480A1 (zh) | 程序更新方法、计算机可读存储介质、终端设备及装置 | |
US10380085B2 (en) | Method, apparatus and computer program for migrating records in a database from a source database schema to a target database schema | |
JP2004118553A (ja) | ワークフロー実行方法とシステム、およびそのためのプログラム | |
CN106484618B (zh) | 一种基于访存依赖对的并行重放方法和装置 | |
JP2017045217A (ja) | ログ管理装置、ログ管理方法、およびログ管理プログラム | |
US20080172659A1 (en) | Harmonizing a test file and test configuration in a revision control system | |
US20070226172A1 (en) | File-management apparatus, file-management method, and computer product | |
US8904348B2 (en) | Method and system for handling errors during script execution | |
JP2009026029A (ja) | トランザクション制御装置、トランザクション制御方法、トランザクション制御プログラムおよびそのプログラムを記憶した記憶媒体 | |
US20070234281A1 (en) | Apparatus for analyzing task specification | |
JP3104586B2 (ja) | 設計支援方法 | |
JP2843748B2 (ja) | 排他制御方式 | |
JP4413810B2 (ja) | 製品構成管理プログラム、製品構成管理方法および製品構成管理装置 | |
JPH1153391A (ja) | データベースアクセス方法 | |
JPH0546378A (ja) | プログラムの修正処理方法 | |
JP4604666B2 (ja) | 入出力対象変更制御方法 | |
US20230325248A1 (en) | Computer system and data consistency maintenance method | |
JP2006172065A (ja) | チェックポイント採取方法、システム及びプログラム |
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 |