JP2009080648A - ワークフロー作成管理システム及びワークフロー作成管理方法 - Google Patents

Abstract

【課題】ワークフローの構成要素に対して種々の制約を一元的かつ包括的に設定することができると共に設定した制約の違反を回避しつつ容易にワークフローを作成できる他、他システムの制約違反を監視しつつ他システムと連携動作することができるワークフロー作成管理システムを提供する。
【解決手段】本発明に係るワークフロー作成管理システムは、基底ワークフローをカスタマイズした派生ワークフローを作成するワークフロー編集部と、基底ワークフロー及び派生ワークフローに含まれる状態及び状態の定義情報を格納するワークフロー定義データベースと、を備え、ワークフロー編集部は、基底ワークフローに含まれる状態と、状態に対応する派生ワークフローの状態との差分を定義することによって前記派生ワークフローを作成する、ことを特徴とする。
【選択図】 図１

Description

本発明は、ワークフロー作成管理システム及びワークフロー作成管理方法に係り、特に、ワークフローを定義して作成すると共に、作成されたワークフローを管理、運用するワークフロー作成管理システム及びワークフロー作成管理方法に関する。

ビジネスプロセスを自動化し、帳票・タスク等が複数の担当者間で受け渡される仕組みを定義したものをワークフローと呼ぶ。ワークフロー作成管理システムは、ワークフローを実現する情報システムであり、ワークフローの定義、管理、運用、分析等を行う機能を有する。ワークフローの例としては、事務手続きの承認手順や、製品開発における不具合管理手順などが挙げられる。

ワークフローは状態遷移モデルとして表現することが出来る。ワークフローは、状態遷移モデルに含まれる状態、状態が受け取るイベント、イベントによって引き起こされる遷移に加えて、ワークフロー上でやり取りされる帳票の種類やそれらが含む属性情報、ワークフロー上で属性情報を入力したりイベントを発生させたりするユーザの役割等によって定義される。

組織・企業においては、1つのワークフローは単一の部門で運用されるだけでなく、複数の部門間で共有されることが多い。複数部門で利用する場合、そのままの形ではなく、個別の部門の事情に合わせてカスタマイズを施して運用されることが多い。例えば、事業部全体で原則を定めた基底ワークフローを提供し、Ａ製品開発部・Ｂ製品開発部・Ｃ製品開発部がそれぞれの製品の特徴や部門メンバの利用法に合わせてカスタマイズを施した上で運用するような場合が考えられる。

特許文献１には、基底ワークフローを継承して派生ワークフローを作成する技術の一例が開示されている。例えば、基底ワークフローを事業部で作成し、Ａ製品開発部でこの基底ワークフローをカスタマイズして派生ワークフローを作成するような場合に適用される技術である。基底ワークフローは、複数の状態と、状態間の遷移関係とを明示することによって定義されている。

派生ワークフローを作成するときには、基底ワークフローに含まれる特定の状態に対して上書きを行って新たな状態の定義を行っている。つまり、基底ワークフローに対する差分を記述することによって派生ワークフローを作成している。基底ワークフローに含まれる夫々の状態には、上書きの禁止、或いは許可を示す情報が予め割り付けられている。状態毎に割り付けられた上書き禁止／許可情報によって、無秩序に派生ワークフローが作成されることを防止している。
特開２００３−２０８５００号公報

基底ワークフローから派生ワークフローを作成する場合、共通のルールがない状態で各部門にカスタマイズを許すと、事業部全体としてのワークフローが本来の役割を果たせなくなる虞がある。ワークフローによって実現したい役割を果たすための条件のことを「ワークフロー要件」と呼ぶ。例えば、どのイベントをどのユーザが実行可能かといったセキュリティに関するワークフロー要件、必須レビューを省略してはならないといった状態遷移に関するワークフロー要件等が破られると、業務上大きな問題が発生する可能性がある。

特許文献１では、状態毎に割り付けられた上書き禁止／許可情報によって、無秩序に派生ワークフローが作成されることを防止する技術が開示されているが、このような従来技術だけではワークフロー要件を十分遵守するのには不十分であり、以下のような課題がある。

第１の課題は、ワークフロー要件を満たすための制約の種類や対象が従来技術では十分に規定されていない点にある。前述したように、ワークフローの構成要素としては、「状態」、状態の遷移を引き起こす「イベント」、状態の「遷移先」、各状態で作成される帳票類の「属性」、ユーザの役割や権限等がある。特許文献１等の従来技術では、上記の構成要素のうちの「状態」に対してのみ、その制約として上書き禁止／許可情報の記述が規定されている。しかしながら、「状態」以外のワークフローの各構成要素（例えば、「イベント」、「遷移先」、「属性」等）に対する制約（カスタマイズを行う際の制約）までは提供されていない。このため、各部門で種々のカスタマイズを行った結果、ワークフロー要件が守られていない派生ワークフローが作成され、運用されてしまう問題があった。また、逆に、制約の表現能力が不十分であるために、用途に応じてカスタマイズしにくくなり、ワークフローの保守性が低くなるという問題があった。

第２の課題は、共通的な制約を一元的に規定し、或いは複数の制約を包括的に規定する手段が従来技術では提供されていない点にある。ワークフローに対してカスタマイズを行う際の制約には、特定のワークフローに依存せず総てのワークフローに対して定義できる制約も存在する。例えば、「基底ワークフローから作成する総ての派生ワークフローでは、イベントの削除は許可しない。」といった制約は派生ワークフロー全体に共通する制約である。しかしながら、従来技術では、共通的な制約であっても一元的に管理する手法が提供されておらず、ある特定の制約は特定のワークフローに従属しており、他のワークフローで利用することが出来なかった。このため、複数のワークフローの夫々に対して同じ制約をいちいち記述する必要があり、不便であった。

また、ワークフロー要件は必ずしも１種類の制約で表現できるとは限らない。従来技術では複数の制約を集約した単位で包括的に管理する手段が提供されておらず、このため、ワークフロー要件単位で複数の制約を管理することができなかった。

第３の課題は、基底ワークフローや派生ワークフローを作成するときに、規定した制約が遵守されているか否かを判断すると共に、判断結果をワークフロー作成者に通知する手段が従来技術では提供されていなかった。つまり、ワークフロー作成を支援するための手段が提供されていなかった。このため、ワークフローの作成に時間を要し、また作成されたワークフローの信頼性（制約が確実に遵守されたワークフローであるかという観点での信頼性）も十分ではなかった。

第４の課題は、異なったワークフロー作成管理システム間での連携運用を可能とする手段が従来技術では提供されていない点である。同じ基底ワークフローからカスタマイズしたワークフローを複数のワークフロー管理システム上で動作させて連携させると、基底ワークフローとワークフロー要件を共有できるため、ワークフロー間の整合を取ることが容易になるメリットがある。例えば、あるワークフロー作成管理システムから他のワークフロー作成管理システムに対して特定の処理を委託する場合等である。

しかしながら、処理を委託する先のワークフローが、カスタマイズ制約を破って定義されていた場合、そのことを確認することが出来ないと、委託する先のワークフローが基底ワークフローフローの要件を満たすことが保証できない。しかし、従来のワークフロー作成管理システムは、このような確認を行う手段を提供していなかった。

本発明は、上記事情に鑑みてなされたものであり、基底のワークフローをカスタマイズして派生ワークフローを作成する際に、ワークフローの構成要素に対して種々の制約を一元的かつ包括的に設定することができると共に設定した制約の違反を回避しつつ容易にワークフローを作成できる他、他システムの制約違反を監視しつつ他システムと連携動作することができるワークフロー作成管理システム、及びワークフロー作成管理方法を提供することを目的とする。

上記課題を解決するため、本発明に係るワークフロー作成管理システムは、請求項１に記載したように、状態遷移モデルとして表現されるワークフローを作成し管理するワークフロー作成管理システムにおいて、基底ワークフローを継承した派生ワークフローを定義することによって、前記基底ワークフローをカスタマイズした前記派生ワークフローを作成するワークフロー編集部と、前記基底ワークフロー及び前記派生ワークフローに含まれる状態及び状態の定義情報を格納するワークフロー定義データベースと、を備え、前記ワークフロー編集部は、前記基底ワークフローに含まれる状態と、前記状態に対応する前記派生ワークフローの状態との差分を定義することによって前記派生ワークフローを作成する、ことを特徴とする。

また、上記課題を解決するため、本発明に係るワークフロー作成管理方法は、請求項９に記載したように、状態遷移モデルとして表現されるワークフローを作成し管理するワークフロー作成管理方法において、（ａ）基底ワークフローを継承した派生ワークフローを定義することによって、前記基底ワークフローをカスタマイズした前記派生ワークフローを作成し、（ｂ）前記基底ワークフロー及び前記派生ワークフローに含まれる状態及び状態の定義情報を格納する、ステップを備え、ステップ（ａ）では、前記基底ワークフローに含まれる状態と、前記状態に対応する前記派生ワークフローの状態との差分を定義することによって前記派生ワークフローを作成する、ことを特徴とする。

本発明に係る本発明に係るワークフロー作成管理システム、及びワークフロー作成管理方法によれば、基底のワークフローをカスタマイズして派生ワークフローを作成する際に、ワークフローの構成要素に対して種々の制約を一元的かつ包括的に設定することができると共に設定した制約の違反を回避しつつ容易にワークフローを作成できる他、他システムの制約違反を監視しつつ他システムと連携動作することができる。

本発明に係るワークフロー作成管理システム、及びワークフロー作成管理方法の実施形態について、添付図面を参照して説明する。

（１）システム構成
図１は、本発明の実施形態に係るワークフロー作成管理システム１の構成例を示すブロック図である。ワークフロー作成管理システム１は、ワークフロー制御部１０、ワークフロー編集部２０、及びカスタマイズ制約編集部３０を有する他、状態データデータベース１１、ワークフロー定義データベース２１、カスタマイズルール／ポリシ定義データベース３１の各データベースを有している。

また、ワークフロー作成管理システム１はワークフロー連携部４０を有しており、ワークフロー連携部４０を介して他のワークフロー作成管理システム１と連接可能な構成となっている。

ワークフロー作成管理システム１で実現される各種の機能は、アプリケーションソフトウェア５０を介してワークフロー管理者やワークフローユーザに提供される。アプリケーションソフトウェア５０は、典型的には、ウェブブラウザやメールユーザエージェントである。

ワークフロー制御部１０の主要な機能は、ワークフロー編集部２０にて作成及び編集されたワークフロー定義と、ワークフローユーザから入力されるデータとに基づいてワークフローの状態遷移を処理し、状態データデータベース１１の状態データを更新することである。

ワークフロー編集部２０の主要な機能は、ユーザ（ワークフロー管理者）にワークフローを編集するための機能を提供し、ワークフロー定義データを更新することである。後述するように、ワークフローの編集は、カスタマイズルール／ポリシ定義データベース３１に格納されたカスタマイズルールやカスタマイズポリシによって制限される。

カスタマイズ制約編集部３０の主要な機能は、ユーザ（ワークフロー管理者）にカスタマイズルールおよびカスタマイズポリシを編集する機能を提供し、カスタマイズルール／ポリシ定義データベース３１のデータを更新することである。

ワークフロー連携部４０の主要な機能は、状態データおよびワークフロー定義データの情報を他のワークフロー作成管理システム１と送受信することである。

図１中のワークフロー管理者は、主にワークフローを編集定義し、カスタマイズ制約（カスタマイズルール及びカスタマイズポリシ）を定義するユーザである。また、ワークフローユーザは、実際のプロジェクトでワークフローに基づいて作業し、状態データの入力を行うユーザである。

図２は、ワークフロー作成管理システム１の主たる運用とその流れを例示した図である。図２（ａ）及び（ｂ）は、上位部門（例えば、本社の事業部）のワークフロー管理者の作業によって、カスタマイズポリシが付加された基底ワークフローを作成する流れを示している。このとき、図２（ａ）の流れに示したように、カスタマイズルールとカスタマイズポリシとからなるワークフロー作成、編集に関する制約が予め定義される。この制約定義は、カスタマイズ制約編集部３０の機能を利用して行われる。

一方、ワークフロー編集部２０の機能を利用して基底ワークフローが作成され、その後、先に定義したカスタマイズポリシを基底ワークフローに付加する。

他方、図２（ｄ）に示したように、下位部門（例えば、事業部に属する開発部Ａ）のワークフロー管理者は、基底ワークフローをカスタマイズして、自部門に適合した派生ワークフローを作成、編集する。基底ワークフローにはカスタマイズポリシが付加されているため、派生ワークフローの作成、編集には、原則としてカスタマイズポリシの制約が課せられることになる。

ワークフローユーザは、図２（ｃ）、（ｅ）に示したように、ワークフロー管理者が作成、編集した基底ワークフロー、或いは派生ワークフローに従って作業を行うが、このときワークフロー制御部１０の機能を利用する。

上記のように構成されたワークフロー作成管理システム１の詳細動作について以下順次説明する。

（２）ワークフローの作成・編集
最初に、以下の説明で使用するワークフローの例について説明する。ワークフロー作成管理システム１は、製品開発プロジェクトにおける不具合管理のワークフローを管理し運用するものとする。また、このワークフローで扱われる帳票は、不具合の属性情報を表わすものとする。

図３（ａ）に示したワークフローＷＦ１は、製品開発プロジェクトにおける不具合管理の基本となるワークフロー（基底ワークフロー）の例を示したものである。ワークフローＷＦ１は、製品のテストによって不具合が発見された後の処理手順を定義している。一般にワークフローは、複数の「状態」と「状態」間の遷移関係を示す状態遷移モデルによって表現することが出来る。本例のワークフローＷＦ１では、「登録待ち」、「処置待ち」、「確認待ち」、及び「終了」の４つの状態を有している。

「登録待ち」状態は、テスト担当者により発見された不具合を登録するための状態である。不具合発見時の属性情報を入力することが出来る。「登録」イベントにより「処置待ち」状態に遷移する。

「処置待ち」状態は、開発担当者により不具合への修正処置が施されるまでの状態である。修正処置に関する属性情報を入力することが出来る。「処置」イベントにより「確認待ち」状態に遷移する。

「確認待ち」状態は、開発担当者による修正処置の結果、製品が正しい状態になったことをテスト担当者が確認するまでの状態である。確認結果に関する属性情報を入力することが出来る。「確認」イベントにより「終了」状態に遷移する。

「終了」状態は、不具合の処置と確認が完了した状態である。入力可能な属性情報はない。「終了」状態に遷移することによって、ワークフローＷＦ１は終了する。

図３（ｂ）及び（ｃ）に示したワークフローＷＦ２、ＷＦ３は、製品の重要度に対応して基底ワークフローＷＦ１の一部を変更してカスタマイズした派生ワークフローである。

ワークフローＷＦ２は、開発担当者により多くの権限を与えることで、不具合管理処理全体の効率化をねらってカスタマイズした例である。開発担当者が、報告された不具合に対して、不具合に該当しないことを判断して終了扱いとすることができるように、「処置待ち」状態に「破棄」イベントを追加している。

ワークフローＷＦ３は、技術的に困難な製品に対してより厳重な工程を踏むようにカスタマイズした例である。「処置待ち」状態を細分化し、開発部隊内に処置承認者を置き、開発担当者の処置内容の申請を受けて処置承認者である開発リーダが処置内容の承認を行うようにしている。「処置申請待ち」状態と「処置承認待ち」状態は、別途ワークフローＷＦ４として定義されている。

各ワークフローの作成、編集作業は、ワークフロー編集部２０の機能を利用して行われる。具体的には、ワークフロー定義データベース２１に格納する各種の定義テーブルを作成、編集することによってワークフローの作成、編集を行っている。

図４は、ワークフロー定義データベース２１に格納する各種の定義テーブルを例示する図であり、ワークフロー定義データベース２１は、ワークフロー定義テーブル２００、状態定義テーブル２０１、状態継承定義テーブル２０２、属性定義テーブル２０３、状態／属性関連定義テーブル２０４、イベント定義テーブル２０５等を有している。

図５は、ワークフロー定義テーブル２００の具体例を示す図である。ワークフロー定義テーブル２００には、ワークフローの基本データが格納される。ワークフロー定義テーブル２００は、ワークフロー名を主キーとして、少なくとも、ワークフローの説明と対応する基底ワークフローをカラムとして持つ。図５の表の１行目は、ワークフローＷＦ１が基本工程であることと、対応する基底ワークフローを持たないことから、ワークフローＷＦ１自体が基底ワークフローであることを示している。

また、図５の表の２行目は、対応する基底ワークフローがワークフローＷＦ１であることが示されている。これは、ワークフローＷＦ２が、基底ワークフローＷＦ１を継承してカスタマイズされた派生ワークフローであることに対応している。

ワークフローＷＦ３、ＷＦ５、ＷＦ１０についても同様であり、夫々が基底ワークフローＷＦ１を継承してカスタマイズされた派生ワークフローであることを表わしている。

一方、ワークフローＷＦ４は、前述したようにワークフローＷＦ３の中に組み込まれる部分ワークフローであるが、ワークフローＷＦ４自体は単独に基底ワークフローとして定義されることを示している。

図６に示した状態定義テーブル２０１は、各ワークフローにどの状態が含まれるかを定義するテーブルである。ワークフロー定義テーブル２０１は、ワークフロー名を主キーとして、少なくとも、当該ワークフローに含まれる状態名及び状態の種別をカラムとして持つ。図６の表の１行目から４行目に示したように、ワークフローＷＦ１は、「登録待ち」、「処置待ち」、「確認待ち」、及び「終了」の４つの状態を持つことを定義している。

状態の種別は、ワークフローにおいて配置可能な位置によって、「開始」、「中途」、及び「終結」に分類できる。ワークフローは、必ず１つの「開始」種別の状態から始まり、「途中」種別の状態を経過して、「終結」種別の状態に到って処理が完了する。１つのワークフローについて、「途中」種別の状態の数はいくつあっても構わない。ゼロであってもよい。また、「終結」種別の状態の数は１つ以上複数あっても構わないが、「開始」種別の状態の数は１つである。図６は、「登録待ち」状態はワークフローの開始であること、「終了」状態は、ワークフローの終結であることを示している。

図７に示した状態継承定義テーブル２０２は、基底ワークフローと派生ワークフローにおける状態の対応付けを定義するテーブルである。状態継承定義テーブル２０２は、ワークフロー名と状態名の組み合わせを主キーとして、少なくとも、対応付けられる「状態の実体」と対応付けの方法とをカラムとして持つ。「状態の実体」とは、基底ワークフローの状態が派生ワークフローのどの状態と対応付けられるのかを定義するものである。

例えば、ワークフロー定義テーブル２００（図５）によってワークフローＷＦ２が基底ワークフローＷＦ１をカスタマイズした派生ワークフローであることが定義されており、状態定義テーブル２０１（図６）によってワークフローＷＦ２が「処置待ち´」状態を有することが定義されている。状態継承定義テーブル２０２では、さらに、基底ワークフローＷＦ１の中のどの状態をカスタマイズしたのか、またカスタマイズによってどの「状態の実体」に対応付けられるのかを定義している。具体的には、図７の５行目に示したように、基底ワークフローＷＦ１の中の「処置待ち」状態が、派生ワークフローＷＦ２では、「処置待ち´」状態に対応付けられていることを示している。

対応付けは、「状態」から「状態」への対応付けの他、「状態」から「部分ワークフロー」への対応付けも可能である。例えば、図７の６行目に示したように、基底ワークフローＷＦ１の中の「処置待ち」状態が、派生ワークフローＷＦ３では、部分ワークフローＷＦ４に対応付けられていることを示している。

対応付けの方法は、「継承」と「上書き」の２つの方法に分類できる。カスタマイズ後の状態とカスタマイズ前の状態の対応付け方法を定義するものであるが、詳しくは後述する。図７の例では、ワークフローＷＦ２における「処置待ち´」状態の対応付けは「継承」であり、ワークフローＷＦ５における「処置待ち´」状態の対応付けは「上書き」であることを示している。

図８に示した属性定義テーブル２０３は、不具合管理のワークフローでやり取りされる帳票データの属性の種類とそのデータタイプを定義するテーブルである。属性名を主キーとして、データタイプをカラムとして持つ。各属性の実際のデータ入力は、ワークフローユーザがワークフロー制御部１０を利用して入力するものであり、属性定義テーブル２０３では、「整数」、「文字列」、「日付」といったデータタイプの定義を行っている。データタイプのうち「選択」は、別途定義された選択肢のグループ（モジュール名のグループや、ユーザ名のグループ）の中から選んで入力されることを示している。

図９に示した状態／属性関連定義テーブル２０４は、ワークフローの中の各状態とその状態で入力、編集が可能な属性（以下、関連属性という）との関連付けを定義している。状態／属性関連定義テーブル２０４は、ワークフローと状態の組を主キーとして、少なくとも、その状態に関連付けられた関連属性名及び必須入力属性をカラムとして持つ。例えば、図９の１行目から８行目にかけて、ワークフローＷＦ１の「登録待ち」状態では、「不具合番号」、「タイトル」、「発生日付」、「症状」、「重要度」、「優先度」、「発見者」、「発生モジュール」の８種類の関連属性が入力、編集可能であり、このうち、「症状」と「発生モジュール」以外は「登録待ち」状態での入力が必須であることを示している。

図１０に示したイベント定義テーブル２０５は、ワークフローの各状態の遷移関係を定義するテーブルである。イベント定義テーブル２０５は、ワークフローと状態とを主キーとして、少なくとも、その状態が受け入れるイベント、イベントを受け入れた後の遷移先、イベントを起こすことが出来るイベント実行権限者をカラムとして持つ。例えば、図１０の１行目は、ワークフローＷＦ１の「登録待ち」状態では、「テスト担当」者が「登録」イベントを入力することが可能であり、かつ「登録」イベントの入力によって「登録待ち」状態から「処置待ち」状態に遷移することを示している。

上述した各定義テーブルを作成、編集することによって、基底ワークフローや、基底ワークフローをカスタマイズした派生ワークフローを作成、編集することができる。なお、各定義テーブルは上記の形態に限定されるものではなく、例えば、複数の定義テーブルを１つの定義テーブルに統合しても良いし、逆に１つの定義テーブルを複数の定義テーブルに分割してもよい。

次に、派生ワークフローの作成、編集の方法について、ユーザインタフェース画面の具体例を提示しつつ説明する。なお、基底ワークフローの作成、編集方法についても、派生ワークフローの説明の中で適宜説明を加える。ユーザインタフェース画面は、例えば、ワークフロー編集部２０やアプリケーションソフトウェア５０によって提供されるものである。

ワークフロー管理者がある特定の基底ワークフローから派生ワークフローを作成しようとする場合、まず図１１に例示したワークフロー定義画面Ｗ１を表示させる。ワークフロー定義画面Ｗ１には、新規に作成するワークフローの名前を入力するテキストボックス３００、対応する基底ワークフローを選択するドロップダウンリスト３０１、及びワークフローの説明を入力するテキストボックス３０２が表示されている。図１１は、作成しようとする派生ワークフローの名前を「ＷＦ２」と入力し、この派生ワークフローに対応する基底ワークフローとして「ＷＦ１」を選択している例を示している。

これらのデータの入力後、「作成」ボタン３０３をクリックすることによって、派生ワークフローＷＦ２の名前と基底ワークフローＷＦ１とのワークフローレベルでの継承関係が定義される。

なお、基底ワークフローＷＦ１を定義する場合には、基底ワークフローを選択するドロップダウンリスト３０１から、例えば「−」を選択して、対応する基底ワークフローが存在しないことを定義すればよい。

ワークフロー定義画面Ｗ１からの入力、更新によって、ワークフロー定義テーブル２００（図５）が作成、編集される。

ワークフローの定義が終了すると、次に、図１２に示した状態定義画面Ｗ２を表示させる。状態定義画面Ｗ２はワークフロー名（本例では、「ＷＦ２」）を指定して表示させる。

先のワークフロー定義によって、ワークフローＷＦ２が基底ワークフローＷＦ１を継承した派生ワークフローであることが定義されている。派生ワークフローでは、基底ワークフローに含まれる状態や、状態の属性、イベント等の定義が引き継がれる。ワークフローの継承は任意の回数行うことができる。この場合には、派生ワークフローは継承関係を遡り、総ての基底ワークフローの状態や、状態の属性、イベント等が引き継がれる。

引き継がれた基底ワークフローの状態や、状態の属性、イベント等は、変更しない部分についてはあらためて記述する必要は無くそのまま利用することが出来る。つまり、派生ワークフローを作成する場合には、基底ワークフローに対する差分のみを記述すればよい。

図１２では、基底ワークフローＷＦ１で定義されている状態（「登録待ち」、「処置待ち」、「確認待ち」、「終了」）とその種別が状態定義画面Ｗ２に自動的に表示される。

他方、派生ワークフローＷＦ２は、基底ワークフローＷＦ１の「処置待ち」状態をカスタマイズして「処置待ち´」状態を新たに付加するものである（図３参照）。そこで、テキストボックス３１３に「処置待ち´」を入力すると共に、ドロップダウンリスト３１４から「処置待ち´」状態の種別として「中途」を選択し、「追加」ボタンをクリックする。この操作によって、基底ワークフローＷＦ１に対する差分として、派生ワークフローＷＦ２に「処置待ち´」状態が定義されることになる。

なお、状態定義画面Ｗ２のテキストボックス３１０、３１１に表示されている基底ワークフローＷＦ１の状態や状態の種別に新たなデータを入力し、「更新」ボタン３１２をクリックすることによって、基底ワークフローＷＦ１の状態や状態の種別を変更することができる。

状態定義画面Ｗ２からのデータ入力、更新によって、状態定義テーブル２０１（図６）を作成、編集することができる。

また、状態定義画面Ｗ２を利用して、基底ワークフローの状態を新たに定義することもできる。基底ワークフローを定義する場合には、状態や状態の種別を夫々新規に入力することになる。

次に、状態継承の定義画面Ｗ３を表示させる。状態継承の定義画面Ｗ３は、基底ワークフローでカスタマイズしたい部分を含む状態を指定し、派生ワークフローの新しい状態に対応付けるための画面である。

ワークフローのカスタマイズは、状態の単位でイベントや属性を追加、削除することで行う。このため、まず、基底ワークフローでカスタマイズしたい部分を含む状態を指定し、派生ワークフローの新しい状態に対応付ける。基底ワークフローの状態に対応付けられる新しい状態のことを、「状態の実体」と呼ぶものとする。基底ワークフローのある状態Ａに派生ワークフローの状態Ｂが「状態の実体」として対応付けられている場合、状態Ａの振る舞いは、状態Ｂに委譲されて処理される。ワークフローの連携運用を定義する場合などには、派生ワークフローを基底ワークフローであるとみなして、基底ワークフローの状態を対象として連携を定義できるが、実際の処理は「状態の実体」に委譲される。

状態の対応付けの方法は、「継承」と「上書き」のいずれかを選ぶことが出来る。「継承」は、カスタマイズされる状態のイベントや属性を引き継いで、状態の実体で追加や削除によるカスタマイズを行うための方法である。「上書き」はカスタマイズされる状態のイベントや属性を捨てて、新たに定義する状態で置き換えることでカスタマイズを行うための方法である。

対応付けられる状態の種別は一致していなければならない。すなわち、種別が「開始」状態は同じく「開始」の状態としか対応付けを行うことが出来ない。

図１３では、基底ワークフローＷＦ１の「処置待ち」状態に対して状態の実体としての「処置待ち´」状態を対応付け、対応付けの方法として「継承」を選択している。つまり、基底ワークフローＷＦ１から継承した「処置待ち」状態が、派生ワークフローＷＦ２ で定義した「処置待ち´」状態によって「継承」の対応付けによってカスタマイズされることを定義している。この結果、派生ワークフローＷＦ２の「処置待ち´」状態は、自身に定義されたイベントや関連属性だけでなく、ＷＦ１の「処置待ち」状態と同じイベントや関連属性も引き継いで持つことになる。

状態継承の定義画面Ｗ３に状態の実体や対応付けの方法を入力、編集することによって、状態継承定義テーブル２０２（図７）が作成、編集される。

派生ワークフローＷＦ２の中の状態の実体（カスタマイズの対象となる状態）とその対応付け方法の定義がされた後は、状態の実体に対して具体的な編集（カスタマイズ）の作業に移行する。

図１４は、状態の実体に対して関連属性を編集する画面Ｗ４を例示するものである。図１４では、派生ワークフロー中の「処置待ち´」状態を指定し、「処置待ち´」状態で入力可能な（或いは編集可能な）関連属性と、必須入力項目であるか否かをチェックマーク「レ」で選択している様子を示している。

派生ワークフローＷＦ２の「処置待ち´」状態は、基底ワークフローＷＦ１の「処置待ち」状態を「継承」している。従って、基底ワークフローＷＦ１の「処置待ち」状態で定義されている関連属性（「担当者」と「処置内容」）及びその必須属性をそのまま引き継いでいる。

一方、派生ワークフローＷＦ２の「処置待ち´」状態に対して、新たな関連属性として「棄却理由」を付加するため、該当する欄にチェックマーク「レ」を入力している。

基底ワークフローＷＦ１の「処置待ち」状態で既に定義されている関連属性や必須属性を変更することも出来る。あらたに関連属性や必須属性を付加する場合は該当する欄にチェックマーク「レ」を付加すれば良いし、定義済みの関連属性や必須属性を削除する場合には、チェックマーク「レ」の上からクリックしてチェックマーク「レ」を消去すれば良い。

また、基底ワークフローの各状態における関連属性や必須属性を定義する場合にも、図１４の示した関連属性編集画面Ｗ４からチェックマーク「レ」を入力して定義することができる。ここで入力、編集したデータによって、状態／属性関連定義テーブル２０４（図９）が作成、編集される。

図１５は、イベント編集画面Ｗ５の一例を示す図である。イベント編集画面Ｗ５は状態を指定することによって表示される。イベント編集画面Ｗ５によって、状態遷移を引き起こすための「イベント」と遷移先の状態とを編集することができる。

図１５では、基底ワークフローＷＦ１の「処置待ち」状態から継承されている「処置」イベントと、遷移先である「確認待ち」状態が自動的に表示されている。さらに図１５では、派生ワークフローＷＦ２の「処置待ち´」状態に新たに追加する「棄却」イベントをテキストボックス３４０に入力し、その遷移先である「終了」状態をドロップダウンリスト３４１から選択している様子を示している。

イベント編集画面Ｗ５では、既に定義されている基底ワークフローの状態のイベントや遷移先を「更新」ボタン３４２や「削除」ボタン３４３を利用して変更することもできる。また、基底ワークフローの状態に関するイベントや遷移先を新たに定義する場合にもイベント編集画面Ｗ５を利用することができる。

イベント編集画面Ｗ５で入力、編集されたデータによって、イベント定義テーブル２０５（図１０）が作成、編集される。

基底ワークフローの状態は、他の状態だけではなく、別のワークフローに対応付けることも出来る。このとき、対応付けられるワークフローを部分ワークフローと呼ぶ。

基底ワークフローの状態に、部分ワークフローを継承で対応付ける場合のイベントや関連属性については次のように扱う。まず基底ワークフローの状態の関連属性は、部分ワークフローに含まれる状態の総てに対してそのまま引き継がれる。但し、部分ワークフロー側で関連属性を追加或いは削除するが可能である。

一方、カスタマイズされる状態に入ってくるイベントによる状態遷移先は、部分ワークフローの「開始」種別に該当する状態となる。また、カスタマイズされる状態から出て行くイベントは、部分ワークフローの「終結」種別に該当する状態に遷移したときに自動的に発生するイベントとなる。具体例で説明する。図３（ｃ）に示したワークフローＷＦ３は、基底ワークフローＷＦ１を継承してカスタマイズした派生ワークフローである。

ワークフローＷＦ３では、基底ワークフローＷＦ１の「処置待ち」状態が部分ワークフローＷＦ４に「継承」の方法で対応付けられている。

この場合、部分ワークフローＷＦ４の「処置申請待ち」状態及び「処置承認待ち」状態は、基底ワークフローＷＦ１の「処置待ち」状態に定義されている関連属性と同じ関連属性を引き継ぐことになる。また、部分ワークフローＷＦ４に対しては図９において別途関連属性が定義されているため、上記の引き継いだ関連属性の他、「処置申請待ち」状態には「処置申請者」属性が、また「処置承認待ち」状態には「処置承認者」属性が新たに関連属性として定義されることになる。

一方、基底ワークフローＷＦ１の「処置待ち」状態に入ってくるイベント（即ち、「登録」イベント）による遷移先は、部分ワークフローＷＦ４の「開始」種別に該当する状態（即ち、「処置申請待ち」状態）となる。また、「処置待ち」状態から出て行くイベントは、部分ワークフローの「終結」種別に該当する状態（即ち「終了」状態）に遷移したときに自動的に発生するイベントとなる。つまり、「処置承認」イベントの結果、最終的には「確認待ち」に遷移することになる。

（３）ワークフローカスタマイズの制約方法
ここまでは、説明の便宜上、基底ワークフローから派生ワークフローをカスタマイズする際の制約がないものと仮定して派生ワークフローの作成、編集方法を説明してきた。しかしながら、前述したように、本実施形態に係るワークフロー作成管理システム１では、基底ワークフローをカスタマイズする場合に何らかの制約を課すことができることを特徴の１つとしている。以下、カスタマイズの制約方法について、（３−１）カスタマイズ制約のためのルールやポリシの定義フェーズ、（３−２）ルールやポリシの整合性確認フェーズ、（３−３）カスタマイズ制約の利用フェーズ、の３つのフェーズに分けて説明する。

（３−１）カスタマイズ制約のためのルールやポリシの定義
本実施形態では、図２（ａ）或いは図１６に示したように、ワークフロー管理者がカスタマイズ制約編集部３０を利用してカスタマイズルールを定義し（カスタマイズルール定義テーブル３０２）、さらに定義したカスタマイズルールを統合してカスタマイズポリシを定義し（カスタマイズポリシ定義テーブル３０３）、これらのルールやポリシをカスタマイズルール／ポリシ定義データベース３１に格納している。また、カスタマイズルールの定義に際しては、カスタマイズルール定義用データ３０１を予め作成してデータベース３１に格納しておき、このカスタマイズルール定義用データ３０１を参照してカスタマイズルールを定義している。

図１７は、カスタマイズルール定義用データ３０１の一例を示したものである。カスタマイズルールは、「ルールの対象」、「カスタマイズの種類」、「制約の方法」、及び「ルールの適用範囲」を規定することによって定義される。「ルールの対象」には、「状態」、属性（関連属性）、及びイベント（イベントによる遷移先も含む）がある。

「カスタマイズの種類」、「制約の方法」、及び「ルールの適用範囲」の具体的な内容は、図１７に示したように、ルールの対象によって異なっている。なお、「カスタマイズの種類」を特定することによって自動的に「ルールの対象」も特定されることになる。例えば、「カスタマイズの種類」として「状態を追加・削除」を特定した場合には、「ルールの対象」として「状態」が自動的に特定されることになる。

なお、図１７のデフォルト欄は、それぞれのルールについて特に指定がなかった場合に、どの範囲でどのようなカスタマイズ制約がかかるかを示している。

図１８は、カスタマイズルール編集画面Ｗ１０の一例を示した図である。カスタマイズルールは、「Ｒ１」、「Ｒ２」等のようにルール毎にルールＩＤを付す。そして、ルール毎に、「カスタマイズの種類」、「制約の方法」、及び「ルールの適用範囲」をドロップダウンリストやテキストボックスから選択或いは入力して定義する。「カスタマイズの種類」欄及び「制約の方法」欄には、図１７に示した定義用データの中の該当する欄の項目がドロップダウンリストの選択肢として示される。

図１９は、カスタマイズルール編集画面Ｗ１０への入力によって定義されたカスタマイズルール定義テーブル３０２の一例を示す図である。このカスタマイズルール定義テーブル３０２によれば、カスタマイズルール「Ｒ１」は、ワークフロー中の「処置待ち」状態に対して適用されるルールであり、「処置待ち」状態の関連属性の種類に対して追加のみを認めるルールである。このルールが適用されると、例えば、基底ワークフローＷＦ１の「処置待ち」状態の関連属性が「担当者」と「処置内容」である場合、これらの関連属性を削除したり他の種類に変更したりすることは禁止されることになる。

他方、カスタマイズポリシは、１つのカスタマイズルール又は複数のカスタマイズルールを統合して構成されるものである。1つのカスタマイズルールでは、ワークフロー要件の全体を表現することが困難である場合がある。このような場合に、個々のカスタマイズルールを組み合わせたカスタマイズポリシを定義することによって、ワークフロー要件の全体を表現する制約として管理することが可能になる。カスタマイズポリシには、任意の数のカスタマイズルールを含めることが出来る。

図２０は、カスタマイズポリシの編集画面Ｗ１１の一例を示す図である。１つのカスタマイズポリシには、例えば「Ｐ１」や「Ｐ２」といった名称をテキストボックスに入力することによってその名称がポリシＩＤとして割り付けられる。また、「ポリシに含むルール」欄のテキストボックスに、１つ又は複数のカスタマイズルールのルールＩＤを入力することによって、１つのカスタマイズポリシを構成するカスタマイズルールを定義することができる。これらのカスタマイズポリシや構成要素であるカスタマイズルールの組み合わせは、「更新」、「削除」ボタンによって編集することができる。

図２１は、カスタマイズポリシ編集画面Ｗ１１への入力によって定義されたカスタマイズポリシ定義テーブル３０３の一例を示す図である。このカスタマイズポリシ定義テーブル３０３によれば、カスタマイズポリシ「Ｐ１」は、２つのカスタマイズルール「Ｒ１」、「Ｒ２」の集合によって定義されていることを示している。また、カスタマイズポリシ「Ｐ１０」も、２つのカスタマイズルール「Ｒ１２」、「Ｒ２２」の集合によって定義されていることを示している。なお、カスタマイズポリシ「ＲＬＳＰ」については後述する。

このように、カスタマイズ制約編集部３０の機能を利用してカスタマイズルール及びカスタマイズポリシが定義され、カスタマイズルール／ポリシ定義データベース３１に格納される。

上記のように、カスタマイズポリシは、ワークフローとは別個に定義される。このことは、カスタマイズポリシの独立性を高めることになり、一旦定義されたカスタマイズポリシは、異なるワークフローに対して任意に付加することができる。このことはまた、カスタマイズポリシの再利用性を高めることにもなる。

基底ワークフローにカスタマイズポリシを適用する場合には、別途基底ワークフローにカスタマイズポリシを付加する必要がある。カスタマイズポリシを基底ワークフローに付加する処理は、ワークフロー編集部２０の機能を利用して行っている。

一旦基底ワークフローに付加されたカスタマイズポリシは、ワークフローが継承されるたびに、その派生ワークフローに継承されていく。また、継承されたカスタマイズポリシは、派生ワークフロー側で適用を除外するように定義することも出来る。これによってカスタマイズポリシを種々の目的に応じて再利用することが可能になる。

図２２は、ワークフロー編集部２０が提供するカスタマイズポリシ付加・編集画面Ｗ２０の一例を示す図である。図２１に示した例では、基底ワークフローＷＦ１に対してカスタマイズポリシ「Ｐ１」が付加されていることを示している。

また、基底ワークフローＷＦ１を継承する各派生ワークフローＷＦ２、ＷＦ３、ＷＦ４に対しては、基底ワークフローＷＦ１に付加したカスタマイズポリシＰ１が自動的に継承されることも示している。

なお、派生ワークフローＷＦ１０に対しては、一旦継承されたカスタマイズポリシＰ１の適用を除外し、新たにカスタマイズポリシＰ１０を付加している。この場合、派生ワークフローＷＦ１０に対してはカスタマイズポリシＰ１０だけが適用されることになる。

図２２には示していないが、１つの基底ワークフローに対して複数のカスタマイズポリシを付加することもできる。また、派生ワークフローに継承されたカスタマイズポリシに対して、新たに別のカスタマイズポリシを付加することもできる。

（３−２）ルールやポリシの整合性確認
カスタマイズルールは個々に独立に定義される。カスタマイズポリシが２以上の複数のカスタマイズルールで構成される場合、１つのカスタマイズポリシ内におけるカスタマイズルール間の整合性が問題となる。つまり、互いに排他的なカスタマイズルールを組み合わせて１つのカスタマイズポリシを定義してしまうと、カスタマイズポリシによる制約に矛盾が生じてしまうことになるため、このようなことが起こらないように予めカスタマイズルール間のルールの整合性を確認しておく必要がある。カスタマイズルール間の整合性の確認が必要となる場面は、カスタマイズポリシを定義したときだけでなく、複数のカスタマイズポリシを１つの基底ワークフローに付加したときや、基底ワークフローを継承した派生ワークフローに対して新たなカスタマイズポリシを付加したとき等である。

図２３は、カスタマイズルール間の整合性を確認する処理例を示すフローチャートであり、主にどの場面で整合性確認の処理を行うかを示している。

ステップＳＴ１はカスタマイズルールを定義する処理であり、ステップＳＴ２はカスタマイズポリシを定義する処理である。いずれもカスタマイズ制約編集部３０の機能を利用して行う処理である。カスタマイズポリシを定義した時点で、定義したカスタマイズポリシ内のルール間の整合性を確認する（ステップＳＴ３）。この確認処理はカスタマイズ制約編集部３０が行う。具体的には次のようにして整合性確認を行う。

２つのルールが、同じカスタマイズの種類について、互いに包含するか重複する適用範囲であり、異なる制約の方法を定義している場合をルールが矛盾しているとし、その逆をルールの整合が取れているとする。ルールの適用範囲が重複せず互いに独立である場合は、同じカスタマイズの種類について複数のルールが存在して良い。例えば、ある状態に対してはイベントの追加のみを許可し、別のある状態に対してはイベントの追加を禁止するようなルールは矛盾せず、整合が取れている。

１つのカスタマイズポリシの整合性を確認するためには、カスタマイズポリシ内に含まれるカスタマイズルールのそれぞれが互いに整合が取れていることを確認する。例えば、全ての状態に対してイベントの追加のみを定義するルールと、ある特定の状態に対してイベントの削除のみを定義するルールを含むカスタマイズポリシは整合が取れていない。

ステップＳＴ３にて整合性の確認されたカスタマイズポリシだけが、データベース３１に格納される（ステップＳＴ４）。

ステップＳＴ５は、カスタマイズポリシを基底ワークフローに付加する処理であり、ステップＳＴ６は、カスタマイズポリシが付加された基底ワークフローを継承しカスタマイズして派生ワークフローを作成する処理である。いずれの処理もワークフロー編集部２０の機能を利用する処理である。これらの処理の後に、基底ワークフロー内、派生ワークフロー内、或いは継承したワークフローの各階層間での整合性を確認する（ステップＳＴ７）。

図２４は、ステップ７のより詳細な処理例を示すフローチャートである。

まず、ステップＳＴ１１にて、ワークフロー編集部２０は、ワークフロー定義データベース２１、及びカスタマイズルール／ポリシ定義データベース３１を参照して、編集しようとしているワークフローを特定する。編集しようとしているワークフローが派生ワークフローの場合は、その基底ワークフローを特定する（基底ワークフローにさらに基底ワークフローがある場合は、先祖側に継承関係をたどり、もっとも先祖側の基底ワークフローを特定する）。

次に、特定したワークフローにカスタマイズポリシが付加されているか否かを確認し（ステップＳＴ１２）、さらにそのカスタマイズポリシの適用が除外されていなかどうか確認する（ステップＳＴ１３）。

次に、適用が除外されていないカスタマイズポリシに対して、カスタマイズポリシ内のルール間での整合性を確認する（ステップＳＴ１４）。

引き続いて、ワークフローに付加されているカスタマイズポリシが複数ある場合は、複数のカスタマイズポリシに含まれる総てのカスタマイズルール間での整合性を確認する（ステップＳＴ１５）。

次に、継承階層の異なる基底ワークフローに付加されているカスタマイズルールに含まれる総てのカスタマイズルールの整合を確認する（ステップＳＴ１６）。

先祖側から子孫側に継承関係をたどりながら夫々のワークフローに対してステップ１２からステップＳＴ１６までの処理を繰り返す（ステップＳＴ１７、ステップＳＴ１８）。

以上の整合性確認処理によって、１つの基底ワークフローに付加された複数のカスタマイズポリシの整合性、及び継承によって生成される複数階層の派生ワークフロー全体におけるカスタマイズポリシの整合性を確認することができる。

なお、階層間のルールの整合条件は、同一カスタマイズポリシ内における整合条件を緩和したものとする。つまり、継承関係において子孫側のワークフローに付加されたカスタマイズポリシは、先祖に付加されたカスタマイズポリシと同じカスタマイズの種類・同じ制約の仕方であり、かつルールの適用範囲が子孫側のほうが狭ければ、整合しているものとする。同じカスタマイズの種類・制約の仕方であっても親より広い適用範囲を持つルールや、異なる制約の仕方を定義したルールは、継承関係があっても整合しないものとする。カスタマイズルールの整合条件に付いて整理したものを図２５に示す。

（３−３）カスタマイズ制約の利用
上述したように、ワークフロー管理者は、ワークフロー編集部２０の機能を利用して基底ワークフローや派生ワークフローを定義しこれらのワークフローの作成や編集を行う。ワークフローのカスタマイズは、つまるところワークフローの構成要素である「状態」、「関連属性」、「イベント」、「遷移先」等の追加や削除等の編集作業の繰り返しである。他方、カスタマイズの制約は、ワークフローの構成要素である「状態」、「関連属性」、「イベント」、「遷移先」等の追加や削除等の編集作業に対する制約として定義されるものである。

本実施形態に係るワークフロー作成管理システム１では、定義したカスタマイズ制約が確実に遵守されるよう、カスタマイズ制約を具現化したユーザインタフェースを提供している。具体的には、前もってカスタマイズ制約に違反するような編集操作が出来ないようにユーザインタフェースの機能に制限を課すようにしている。これにより、編集作業を効率化してワークフロー管理者を支援することが可能になる。

図２６は、ユーザインタフェースを構成する要素（以下、ユーザインタフェース部品、或いはＵＩ部品という）とその機能制限の方法の一例を示す図である。

ワークフローの編集画面等のユーザインタフェースは、図２６に例示したように、「テキストボックス」、「ドロップダウンリスト」、「ラジオボタン」、「操作ボタン」、リンクメニュー」等のＵＩ部品によって構成されている。これらのＵＩ部品に対して、図２５に示したような入力制限方法を適用して外観や機能を変更することにより、編集画面等からのデータ入力やデータ選択を制限することができる。

図２７は、カスタマイズ制約の対象と成るＵＩ部品を選択し、選択したＵＩ部品の外観や機能を変更する処理の一例を示すフローチャートである。図２７に示した処理は、例えばワークフロー編集部２０で実現されるものである。

まず、対象とするワークフローに含まれているある１つのカスタマイズルールを特定する。例えばカスタマイズルールＲａを選ぶ（ステップＳＴ３１）。次に、選んだカスタマイズルールＲａについて、ワークフロー編集部２０が提供する機能、即ち編集画面上で提供するそれぞれの機能について、禁止されているか否かを調べる（ステップＳＴ３２）。例えば、指定された「状態」のイベント編集画面において、イベントの削除や追加、遷移先の変更、利用権限の変更の機能を提供しているとする。この場合、これらの機能が選んだカスタマイズルールＲａによって制限されるか否かを判定する（ステップＳＴ３２）。

カスタマイズルールＲａによって制限されている場合には、編集画面状のＵＩ部品について、どのＵＩ部品が選んだカスタマイズルールＲ１と関係するかを順番に確認し、関係するＵＩ部品の形態（外観や機能）をカスタマイズルールＲａに従って変更する（ステップＳＴ３４、３５、３６、３７）。

次に、カスタマイズルールＲａを他のカスタマイズルールに変更し、ステップＳＴ３２からステップＳＴ３７までの処理を繰り返す。これを、対象とするワークフローに含まれる総てのカスタマイズルールに対して実行する（ステップＳＴ３８、３９）。

以下、上記の処理を２つの具体例を用いて説明する。

図２８は派生ワークフローＷＦ２の「処置待ち´」状態を定義する際に、関連属性を編集するために提供されるユーザインタフェース（関連属性の編集画面Ｗ４）を模式的に示している。画面には、帳票データに定義されている属性の一覧が示され、設定を更新するための「更新」ボタンが提供されている。ワークフロー管理者は、チェックボックスにチェックを付けることで、現在編集中の状態に対する関連属性を設定し、「更新」ボタンをクリックすることで変更を反映することが出来る。

「処置待ち´」状態は、基底ワークフローＷＦ１の「処置待ち」状態と「継承」によって対応付けられているので、「処置待ち」状態の関連属性の設定を引き継いでいる。ここでは、「担当者」「処置内容」がそれに該当する。

ワークフローＷＦ２の基底ワークフローであるＷＦ１には、図２２に示したようにカスタマイズポリシＰ１が付加されている。また、カスタマイズポリシＰ１は、図２１に示したようにカスタマイズルールＲ１を含む。カスタマイズルールＲ１は、図１９に示したように「処置待ち」状態において、「関連属性の種類変更」を「追加のみ」に制限するルールである。

そこで、ワークフロー編集部２０は、カスタマイズルールＲ１に従い、基底ワークフローから継承された状態（この場合「処置待ち´」状態）の関連属性の削除が出来ないようにする変更をユーザインタフェースのＵＩ部品に加える。具体的には、「担当者」、「処置内容」に対応するチェックボックスの入力ができないように外観と機能を変更する。図２８では、「担当者」、「処置内容」に該当するチェックボックスがグレーで表示されているが、これが外観の変更を示しており、機能的にもチェックマークが削除できないように変更されている。他方、グレー表示以外のチェックボックスでは追加が可能であり、図２８に示しように「棄却理由」が追加可能である。このように、カスタマイズルールＲ１に従って、関連属性は、追加することは出来るが、削除が出来ないことがユーザインタフェース上で明確になっている。

図２８は、カスタマイズルールＲ１を含むカスタマイズポリシＰ１を継承している場合のユーザインタフェースの変化例を示しているが、他のカスタマイズポリシが適用された場合には、これとは異なったユーザインタフェースに変化する。例えば、派生ワークフローＷＦ１０のように、カスタマイズポリシＰ１の適用を除外し、新たにカスタマイズポリシＰ１０を適用したとする（図２２参照）。カスタマイズポリシＰ１０には、「処置待ち」状態の関連属性の変更を一切禁止するカスタマイズルールＲ１１が含まれている（図１９、２１参照）。この場合、図２８の「更新」ボタンが無効化され、関連属性の編集画面Ｗ４は、参照だけが可能な状態となる。

図２９はユーザインタフェース変更の第２の具体例を示す図である。図２９では、ワークフローＷＦ２の「処置待ち´」状態を定義する際に、受け入れ可能なイベントを編集するために提供されるユーザインタフェースとしてイベント編集画面Ｗ５を模式的に示している。画面には、編集中の状態で受け入れ可能なイベントの一覧が表示されている。定義済みのイベントの設定を更新するための「更新」ボタン、イベントの削除を行うための「削除」ボタン、状態遷移先を変更するためのドロップダウンリスト、新しいイベントの名前を入力するためのテキストボックス、イベントの新規追加を行うための「追加」ボタンが提供されている。ワークフロー管理者は、定義済みイベントの状態遷移先をドロップダウンリストから選択したのち「更新」ボタンを押して設定を変更したり、「削除」ボタンを押してイベントを削除したり、テキストボックスとドロップダウンリストに新たなイベントの情報を入力してのち「追加」ボタンをしてイベントを追加したりすることが出来る。

「処置待ち´」は、基底ワークフローＷＦ１の「処置待ち」状態と「継承」によって対応付けられているので、「処置待ち」状態のイベントの設定を引き継いでいる。ここでは、「処置」がそれに該当する。

ところで、派生ワークフローＷＦ２の基底ワークフローであるＷＦ１に付加されているカスタマイズポリシＰ１はカスタマイズルールＲ２を含んでいる（図２１参照）。また、カスタマイズルールＲ２は、ワークフロー全体の状態において、「イベントの追加削除」を「追加のみ」に制限するルールである（図１９参照）。

ワークフロー編集部２０は、カスタマイズルールＲ２に従って、基底ワークフローから継承された状態のイベントの削除が出来ないようにする変更をユーザインタフェースに加える。図２９では、「確認」イベントの削除操作に対応する「削除」ボタンは入力が無効化されている。図２９のうちグレーで表示されている部分が無効化されている部分である。このことにより、ユーザインタフェース上で、この状態のイベントは、追加することは出来るが、削除が出来ないことが明確になっている。

図２９のイベント編集画面Ｗ５において、他のカスタマイズポリシが適用されていた場合にはユーザインタフェースの変更内容も異なったものとなる。例えば、ワークフロー全体に対してイベントによる遷移先の変更を禁止するカスタマイズルールＲ１２を含むカスタマイズポリシＰ１０（図２１参照）が適用されていた場合は、ドロップダウンリストが無効化され、遷移先が変更できないようにユーザインタフェースが変更される。一方、カスタマイズポリシＰ１０は、カスタマイズルールＲ２を含んでいないためイベントの削除は可能である。従って、「削除」ボタンは無効化されないことになる。

（４）ワークフローの運用制御
上述したように、主としてカスタマイズ制約編集部３０の機能を利用してカスタマイズ制約が作成・編集され、ワークフロー編集部２０の機能を利用してカスタマイズ制約によって制限されたワークフローが作成・編集される。これらの作成・編集は、主にワークフロー管理者の操作による。

一方、作成・編集されたワークフローは、ワークフロー制御部１０の機能を利用して運用される。ワークフロー運用に関する操作は、主にワークフローユーザによって行われる。ワークフローユーザの主たる操作は、該当する「状態」の関連属性の入力と、イベントの入力である。

図３０は、ワークフロー制御部１０で行われる関連属性の入力やイベントの入力を受け付けるための処理、及びその後の処理例を示すフローチャートである。このフローチャートを、ワークフローＷＦ２を例に挙げて説明する。

ステップＳＴ４１は、現在の状態での関連属性の入力受付処理である。ワークフローは「開始」種別の「状態」から始める。ワークフロー制御部１０は、まず「開始」種別に該当する「状態」を特定するために、ワークフローＷＦ２についての状態定義テーブル２０１（図６）を参照する。状態定義テーブル２０１から、ワークフローＷＦ２では、「開始」種別に該当する「状態」は定義されていないことがわかる。そこで、ワークフロー定義テーブル２００（図５）を参照すると、ワークフローＷＦ２がワークフローＷＦ１を継承していることがわかる。そこで、ワークフローＷＦ１についての状態定義テーブル２０１を参照すると、ワークフローＷＦ１の「開始」種別に該当する「状態」が「登録待ち」状態であることがわかる。つまり、ワークフローＷＦ２の開始では、ワークフローＷＦ１の「登録待ち」状態と同様の振る舞いをすることになる。

「登録待ち」状態の振る舞いは、状態／属性関連定義テーブル２０４（図９）や、イベント定義テーブル２０５（図１０）を参照することによって特定できる。具体的には、状態／属性関連定義テーブル２０４から、「登録待ち」状態で入力可能な関連属性は、「不具合番号」、「タイトル」、「発生日付」、「症状」、「重要度」等であることがわかる。また、これらの関連属性のうちどれが必須属性であるかもわかる。さらに、イベント定義テーブル２０５から、「登録待ち」状態で受け付けるイベントは、「登録」イベントであることがわかる。

ワークフロー制御部１０は、これらの関連属性やイベントを入力するためのユーザインタフェース（入力画面）を提供する。ワークフローユーザは、ワークフロー制御部１０が提供するこれらのユーザインタフェースに対して関連属性やイベントを入力する。ワークフロー制御部１０は、入力された関連属性やイベントを受け付ける（ステップＳＴ４１、ステップＳＴ４３）。また必須属性が総て入力されたか否かを判断し（ステップＳＴ４２）、必須属性が総て入力されていない場合は適宜入力を促すための表示等を行う。

関連属性やイベントを入力すると、ワークフロー制御部１０はイベント特定処理（ステップＳＴ４４）と遷移先特定処理（ステップＳＴ４５）に移行する。

図３１は、イベント特定処理（ステップＳＴ４４）の細部処理例を示すフローチャートである。

ステップＳＴ５１では、現在の状態に入力されたイベントが定義されているか否かを判定する。定義されていない場合には、基底ワークフローが存在するか否かを判断し（ステップＳＴ５２）、その基底ワークフローに対応関係のある「状態」が存在するかどうかをさらに判断し（ステップＳＴ５３）、対応関係にある「状態」に入力されたイベントが定義されているかどうかを判断する（ステップＳＴ５４）。これを、対応関係にある「状態」に入力されたイベントが定義されている基底ワークフローが見つかるまで繰り返す（ステップＳＴ５５）。イベントの定義が確認されると、そのイベントを正しいイベントとして特定する（ステップＳＴ５６）。

今の例では、ワークフローＷＦ２には「登録」イベントは定義されていないため、基底ワークフローＷＦ１の「登録待ち」状態のイベント定義テーブルを参照する。ここには「登録」イベントが定義されているため、「登録」イベントを正しいイベントとして特定する。

次に遷移先特定処理（ステップＳＴ４５）に移る。図３２は、遷移先特定処理の細部処理例を示すフローチャートである。

ステップＳＴ６１では、現在の状態と特定されたイベントに対して遷移先が定義されているか否かを判定する。定義されていない場合には、基底ワークフローが存在するか否かを判断し（ステップＳＴ６２）、その基底ワークフローに対応関係のある「状態」が存在するかどうかをさらに判断し（ステップＳＴ６３）、対応関係にある「状態」と、特定されたイベントに対して遷移先が定義されているかどうかを判断する（ステップＳＴ６４）。これを、遷移先が定義されている基底ワークフローが見つかるまで繰り返す（ステップＳＴ６５）。遷移先の定義が確認されると、その遷移先が「状態の実体」をもつか否かを判断する（ステップＳＴ６６）。「状態の実体」を持たない場合は、先に確認した遷移先を正しい遷移先とした特定する（ステップＳＴ６８）。一方、「状態の実体」を持つ場合には、「状態の実体」に対応付けられている「状態」に変更して（ステップＳＴ６７）、ステップＳＴ６６へ戻る。

この処理を前述の例で説明すると、確定された「登録」イベントによる遷移先はワークフローＷＦ１の「処置待ち」状態である。さらに、現在のワークフローで「処置待ち」状態がカスタマイズされているかを調べると、ワークフローＷＦ２で「処置待ち」状態の実体として、「処置待ち´」状態が定義されていることが分かる。従って、ワークフローは「処置待ち´ 」状態に遷移する。

次に、ワークフロー制御部１０が「処置待ち´」状態で、「処置」イベントを受け取ったとする。ワークフロー制御部１０は、「処置待ち´」状態に対してイベント特定処理を実行する。イベント定義テーブル２０５を参照して「処置待ち´」状態の受け入れ可能イベントに「処置」イベントがあるかどうかを調べると、それがないことが分かる。そこで、基底ワークフローＷＦ１での定義を調べるために、状態継承定義テーブル２０２を参照すると、「処置待ち´」状態はワークフローＷＦ１の「処置待ち」状態を「継承」の方法でカスタマイズしていることが分かる。そこで、イベント定義テーブル２０５を参照して「処置待ち」状態の受け入れ可能イベントを調べると、「処置」イベントが受け入れ可能であり、遷移先が「確認待ち」状態であることが分かる。この結果、ワークフローを遷移先である「確認待ち」状態に遷移させれば良いことが分かる。遷移先である「確認待ち」状態は、ワークフローＷＦ２ではカスタマイズされていないので、基底ワークフローであるワークフローＷＦ１の「確認待ち」を参照する。

ワークフローＷＦ２の「確認待ち´」状態は、ワークフローＷＦ１の「確認待ち」状態と同様の振る舞いをする。つまり、「確認」イベントによってワークフローＷＦ２の「確認待ち´」状態から、ワークフローＷＦ２の「終了」状態に遷移する。ワークフロー制御部１０は、状態遷移が完了するごとに、ワークフローが「終結」種別の状態に達したかどうかのチェックを行う。ワークフローＷＦ２の「終了」状態に対応するワークフローＷＦ１の「終了」状態は、状態定義テーブルによると、「終結」種別の状態であるので、ワークフローＷＦ２の処理はここで完了する。

（５）複数のワークフロー作成管理システム間での連携動作
本実施形態に係るワークフロー作成管理システム１では、複数のワークフロー作成管理システム１間でワークフローを連携させて運用することも出来る。ワークフローの連携方法は、連携元ワークフロー作成管理システム１で定義する。連携を定義するワークフロー作成管理システム１は、連携させたいワークフローの任意のイベントの遷移先として、例えば別サーバで稼動する他のワークフロー作成管理システム１の任意のワークフローの任意の状態を指定する。このワークフローを運用する場合は、ワークフロー連携部４０により、イベントや状態データを連携先のワークフロー作成管理システム１にネットワーク（図示せず）を介して送信する。

複数のワークフロー作成管理システム１間でワークフローを連携する場合、基底ワークフローとカスタマイズポリシとを互いに共有し、そこから派生させたワークフロー同士を連携させることによって状態の対応付けなどが容易となる。さらに、ワークフロー作成管理システム１毎に、基底ワークフローから派生してカスタマイズした派生ワークフローが基底ワークフローに付加されていたカスタマイズポリシに違反していないことを確認することで、連携先のワークフローが、基底ワークフローの要件を満たしていることを確認できる。また、連携定義したワークフローを運用する際にも、同様の確認を行うことで、いつのまにかカスタマイズポリシに違反するようなカスタマイズが行われてしまった場合にも、運用中に異常を検出することが出来る。

以下にワークフローを連携定義する際に、カスタマイズポリシの遵守を確認するための手順を示す。なお、連携先のワークフローは、連携元のワークフローと基底ワークフローおよび付加されるカスタマイズポリシを共有しているものとする。

（ＳＴＥＰ１）
ワークフロー管理者は、連携元のワークフロー作成管理システム１で、連携方法を指定する。具体的には、連携先に遷移する「状態」及びその「イベント」、連携先のワークフロー作成管理システム１が稼動するサーバ等の機器識別情報、連携先のワークフロー名、遷移先の「状態」等を指定する。

（ＳＴＥＰ２）
連携元のワークフロー作成管理システム１は、ワークフロー管理者が指示した連携先の別サーバのワークフロー作成管理システム１に対して、連携先のワークフローが基底ワークフローを継承しており、かつ指定したカスタマイズポリシに違反してカスタマイズされていないことを問い合わせる。

具体的には、連携先のワークフロー、基底ワークフロー、遵守すべきカスタマイズポリシの情報を、ワークフロー連携部４０を介して送信する。

（ＳＴＥＰ３）
連携先のワークフロー作成管理システム１は、ワークフロー連携部４０を介して問い合わせ内容を受信する。ワークフロー連携部４０は、連携定義することが妥当であるかを確認する。具体的には、指定された連携先ワークフローおよびその基底ワークフローが存在すること、指定された指定されたワークフローおよび基底ワークフローに指定された「状態」が存在し継承関係があること、指定されたカスタマイズポリシが存在すること、指定されたカスタマイズポリシが指定された基底ワークフローに適用されていること、指定されたワークフローが指定されたカスタマイズポリシを守ってカスタマイズされていること、等を確認する。

（ＳＴＥＰ４）
連携先のワークフロー作成管理システム１は、確認結果を問い合わせ元のワークフロー作成管理システム１に送信する。

（ＳＴＥＰ５）
連携元のワークフロー作成管理システム１は、問い合わせへの回答を受信し、回答の内容によって処理を変更する。回答内容が正常であれば現在の連携定義のままで連携動作が可能である。逆に、回答内容が異常であればワークフロー管理者にその旨を通知する。

上記の確認処理は、ワークフローを連携定義するときだけでなく、連携定義したワークフローを運用する際にも同様の手順で行うことが出来る。

ワークフローを連携させるために共有すると有益なカスタマイズポリシの例としては、リスコフ置換原則(ＬＳＰ: Liskov Substitution Principle)が挙げられる。ＬＳＰはオブジェクト指向プログラミングにおいて、クラスの多態性を利用して派生クラスを基底クラスであるかのように扱い、オブジェクトの互換性を利用するための条件を示したものである。ＬＳＰでは、あるクラスＳのオブジェクトＯ２を用いて記述されたプログラムＰにおいて、別のクラスＴのオブジェクトＯ１を用いても、プログラムＰの結果が変わらない場合にクラスＳをクラスＴの派生型と呼ぶ。これをクラスにおいて実現するためには、クラスＳにおいてプログラムＰで利用されるメソッドのインタフェースがクラスＴよりも広く、クラスＳによる状態変化がより狭い範囲になる必要がある。

ＬＳＰは、プログラミングにおける原則であるので、ワークフローの定義に直接適用することは出来ない。ワークフローでこの条件を実現する場合、クラスのメソッドによる状態変化の作用をワークフローのイベントによる状態遷移と帳票の属性の変化に対応付ける方法が考えられる。この方法（ＬＳＰに準拠した方法）で定義したカスタマイズルールの例（Ｒ２１〜Ｒ２６）を図３３に示す。状態については、上書きによる編集は許可しない。イベントについては、イベントの削除は禁止し、派生ワークフローの既存のイベントの遷移先の状態は、継承した元のワークフローの状態か、それをカスタマイズした状態でなければならない。属性については、編集可能属性および必須属性はより少なく、入力できる属性値の範囲はより狭く定義する。

ＬＳＰに準拠した方法で定義されたカスタマイズルール（Ｒ２１〜Ｒ２６）を組み合わせたカスタマイズポリシをＰＬＳＰと呼ぶ。ＰＬＳＰをワークフローに適用することで、連携元システムから、派生ワークフローを基底ワークフローのように扱っても、状態遷移の範囲及び属性値の変化が基底ワークフローと連携した場合の範囲に限定される。また、基底ワークフローが持つイベントが保持されるので、連携の定義において指定する状態同士の関係を変更する必要がなく、カスタマイズが行われた場合でも、連携の再定義が必要ない。このように、ＰＬＳＰを遵守することで、ワークフローを連携して定義運用する上で互換性を維持することが出来る。

以上説明してきたように、本実施形態に係るワークフロー作成管理システム１及びワークフロー作成管理方法によれば、ワークフローをカスタマイズする際に、単純に「状態」の上書きの許可・禁止を行うだけではなく、より詳細にカスタマイズ制約を記述することができる。具体的には、「状態」、「イベント（遷移先も含む）」、及び「属性」の各要素に対して様々なカスタマイズ制約を定義することができる。また、個々の「状態」、「イベント」、「属性」のみを対象にしてカスタマイズ制約を定義するだけではなく、ワークフローの全体、特定の状態等といった制約の適用範囲も定義することができる。

この結果、ワークフローの要件を守りつつ、派生ワークフローのカスタマイズ制約をより詳細かつ効率的に定義することができる。

また、ワークフローのカスタマイズ制約は、ワークフローと独立したカスタマイズポリシとして定義し、カスタマイズポリシを自由に組み合わせてワークフローに付加することができる。このため、同種のカスタマイズ制約を繰り返し記述することなく、複数のワークフローに対して一元的に管理されたカスタマイズポリシを適用することができる。

また、カスタマイズ制約は階層化して定義することができる。具体的には、カスタマイズ制約を、１種類のカスタマイズ制約を表現するカスタマイズルールと、複数のカスタマイズルールから構成されるカスタマイズポリシとして定義し、複数のカスタマイズルールを包括的に定義することができる。また、１つのワークフローに複数のカスタマイズポリシを付加することもできる。さらに、必要に応じてカスタマイズポリシの適用を除外したり追加したりすることもできる。

この結果、カスタマイズ制約の表現が簡潔となり、カスタマイズ制約の管理や利用が容易となる他、様々な用途に応じて柔軟にカスタマイズ制約を利用することができる。

また、本実施形態にかかるワークフロー作成管理システム１では、定義したカスタマイズ制約を具現化するユーザインタフェースを提供している。具体的には、ワークフローを編集するための編集画面において、一部のＵＩ部品を無効化する、或いは選択できる入力候補の範囲を絞る等して、カスタマイズ制約に違反したワークフローの編集操作ができないようにしている。

この結果、規定されたワークフロー制約をいちいち参照、確認することなく、カスタマイズ制約が遵守されたワークフローを容易に編集することができる。

また、本実施形態に係るワークフロー作成管理システム１及びワークフロー作成管理方法によれば、複数のワークフロー作成管理システム１間で連携したワークフローの定義及び運用が可能となる。基底ワークフローとそれに付加されたカスタマイズポリシを共有すると共に、連携先のワークフロー作成管理システム１におけるカスタマイズ制約を確認することによって、基底ワークフロー要件が満たせないようなワークフローとの連携を回避することができる。

このように、本実施形態に係るワークフロー作成管理システム１及びワークフロー作成管理方法によれば、基底のワークフローをカスタマイズして派生ワークフローを作成する際に、ワークフローの構成要素に対して種々の制約を一元的かつ包括的に設定することができると共に設定した制約の違反を回避しつつ容易にワークフローを作成できる他、他システムの制約違反を監視しつつ他システムと連携動作することができる。

なお、本発明は上記の実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせても良い。

本発明の実施形態に係るワークフロー作成管理システムの構成例を示す図。 ワークフロー作成管理システムの運用状況の一例を示す図。 ワークフローの一例を示す図であり、（ａ）は基底ワークフロー、（ｂ）及び（ｃ）は派生ワークフローの一例を示す図。 ワークフロー定義データベースに格納するテーブルの例を示す図。 ワークフロー定義テーブルの一例を示す図。 状態定義テーブルの一例を示す図。 状態継承定義テーブルの一例を示す図。 属性定義テーブルの一例を示す図。 状態／属性関連定義テーブルの一例を示す図。 イベント定義テーブルの一例を示す図。 ワークフロー定義編集画面の一例を示す図。 状態定義編集画面の一例を示す図。 状態継承定義編集画面の一例を示す図。 関連属性編集画面の一例を示す図。 イベント編集画面の一例を示す図。 カスタマイズルール／ポリシ定義データベースに格納するデータ、テーブルの一例を示す図。 カスタマイズルールの定義用データの一例を示す図。 カスタマイズルールの編集画面の一例を示す図。 カスタマイズルール定義テーブルの一例を示す図。 カスタマイズポリシの編集画面の一例を示す図。 カスタマイズポリシ定義テーブルの一例を示す図。 カスタマイズポリシ付加編集画面の一例を示す図。 カスタマイズ制約の定義及び整合性確認処理例を示すフローチャート。 ワークフローにおけるカスタマイズルール／ポリシ整合性確認処理例を示すフローチャート。 カスタマイズルール間の整合性判定基準例を要約した表。 ユーザインタフェースの入力制限方法の一例を示す表。 ＵＩ部品に対する入力制限機能付加処理例を示すフローチャート。 カスタマイズ制約が課された関連属性の編集画面の一例を示す図。 カスタマイズ制約が課されたイベント編集画面の一例を示す図。 ワークフローの運用制御処理の一例を示すフローチャート。 イベント特定処理の一例を示すフローチャート。 遷移先特定処理の一例を示すフローチャート。 ＬＳＰに準拠したカスタマイズルールの定義例を示す表。

符号の説明

１ ワークフロー作成管理システム
１０ ワークフロー制御部
１１ 状態データデータベース
２０ ワークフロー編集部
２１ ワークフロー定義データベース
３０ カスタマイズ制約編集部
３１ カスタマイズルール／ポリシ定義データベース
４０ ワークフロー連携部

Claims (16)

1. 状態遷移モデルとして表現されるワークフローを作成し管理するワークフロー作成管理システムにおいて、
   基底ワークフローを継承した派生ワークフローを定義することによって、前記基底ワークフローをカスタマイズした前記派生ワークフローを作成するワークフロー編集部と、
   前記基底ワークフロー及び前記派生ワークフローに含まれる状態及び状態の定義情報を格納するワークフロー定義データベースと、
   を備え、
   前記ワークフロー編集部は、
   前記基底ワークフローに含まれる状態と、前記状態に対応する前記派生ワークフローの状態との差分を定義することによって前記派生ワークフローを作成する、
   ことを特徴とするワークフロー作成管理システム。
2. 前記状態の定義情報には、
   前記状態の属性、前記状態の遷移を引き起こすイベント、及び遷移先、並びにこれらの関連付けが定義された情報、
   が含まれることを特徴とする請求項１に記載のワークフロー作成管理システム。
3. 前記ワークフロー編集部は、
   前記基底ワークフローに含まれる特定の状態を他の状態に対応付けることによって、又は前記特定の状態を部分ワークフローに対応付けることによって、前記差分を定義する、
   ことを特徴とする請求項１に記載のワークフロー作成管理システム。
4. 前記ワークフロー編集部は、
   前記対応付けにおいて、前記特定の状態の定義情報を前記他の状態の定義情報として継承することが可能である一方、継承した前記状態の定義情報の一部を変更することが可能である、
   ことを特徴とする請求項３に記載のワークフロー作成管理システム。
5. 前記基底ワークフローをカスタマイズして派生ワークフローを作成するときに課す制約を定義し編集する制約編集部、をさらに備え、
   前記ワークフロー編集部は、
   前記制約に基づいて前記派生ワークフローの作成を制限する、
   ことを特徴とする請求項１に記載のワークフロー作成管理システム。
6. 前記ワークフロー編集部は、
   前記派生ワークフローを定義するさいのユーザインタフェースの一部を無効化することによって前記派生ワークフローの作成を制限する、
   ことを特徴とする請求項５に記載のワークフロー作成管理システム。
7. 他のワークフロー作成管理システムと連接してワークフローの連携を行うワークフロー連携部、をさらに備え、
   前記ワークフロー連携部は、
   連携を行おうとするワークフローに関して、前記他のワークフロー作成管理システムから送信された制約と自己の制約編集部にて編集された制約とを照合し、両制約間に矛盾が検出された場合にはその旨を前記他のワークフロー作成管理システムに通知する、
   ことを特徴とする請求項５に記載のワークフロー作成管理システム。
8. 前記状態の属性の入力及び前記状態の遷移を引き起こすイベントの入力によって、作成された前記基底ワークフロー又は前記派生ワークフローの運用を制御するワークフロー制御部、をさらに備え、
   前記ワークフロー制御部は、
   前記派生ワークフローの運用を制御する場合には、継承元の前記基底ワークフローの状態及びその状態の定義情報を参照する、
   ことを特徴とする請求項１に記載のワークフロー作成管理システム。
9. 状態遷移モデルとして表現されるワークフローを作成し管理するワークフロー作成管理方法において、
   （ａ）基底ワークフローを継承した派生ワークフローを定義することによって、前記基底ワークフローをカスタマイズした前記派生ワークフローを作成し、
   （ｂ）前記基底ワークフロー及び前記派生ワークフローに含まれる状態及び状態の定義情報を格納する、
   ステップを備え、
   ステップ（ａ）では、
   前記基底ワークフローに含まれる状態と、前記状態に対応する前記派生ワークフローの状態との差分を定義することによって前記派生ワークフローを作成する、
   ことを特徴とするワークフロー作成管理方法。
10. 前記状態の定義情報には、
    前記状態の属性、前記状態の遷移を引き起こすイベント、及び遷移先、並びにこれらの関連付けが定義された情報、
    が含まれることを特徴とする請求項９に記載のワークフロー作成管理方法。
11. ステップ（ａ）では、
    前記基底ワークフローに含まれる特定の状態を他の状態に対応付けることによって、又は前記特定の状態を部分ワークフローに対応付けることによって、前記差分を定義する、
    ことを特徴とする請求項９に記載のワークフロー作成管理方法。
12. ステップ（ａ）では、
    前記対応付けにおいて、前記特定の状態の定義情報を前記他の状態の定義情報として継承することが可能である一方、継承した前記状態の定義情報の一部を変更することが可能である、
    ことを特徴とする請求項１１に記載のワークフロー作成管理方法。
13. （ｃ）前記基底ワークフローをカスタマイズして派生ワークフローを作成するときに課す制約を定義し編集するステップ、をさらに備え、
    ステップ（ａ）では、
    前記制約に基づいて前記派生ワークフローの作成を制限する、
    ことを特徴とする請求項９に記載のワークフロー作成管理方法。
14. ステップ（ａ）では、
    前記派生ワークフローを定義するさいのユーザインタフェースの一部を無効化することによって前記派生ワークフローの作成を制限する、
    ことを特徴とする請求項１３に記載のワークフロー作成管理方法。
15. （ｄ）他のワークフロー作成管理システムと連接してワークフローの連携を行う、ステップをさらに備え、
    ステップ（ｄ）では、
    連携を行おうとするワークフローに関して、前記他のワークフロー作成管理システムから送信された制約と自己の制約編集部にて編集された制約とを照合し、両制約間に矛盾が検出された場合にはその旨を前記他のワークフロー作成管理システムに通知する、
    ことを特徴とする請求項１３に記載のワークフロー作成管理方法。
16. （ｅ）前記状態の属性の入力及び前記状態の遷移を引き起こすイベントの入力によって、作成された前記基底ワークフロー又は前記派生ワークフローの運用を制御する、ステップをさらに備え、
    ステップ（ｅ）では、
    前記派生ワークフローの運用を制御する場合には、継承元の前記基底ワークフローの状態及びその状態の定義情報を参照する、
    ことを特徴とする請求項９に記載のワークフロー作成管理方法。

Images