(57)【要約】【課題】複数の相互関係にあるルールセットおよびビジネスプロセスを処理し、かつ調和させることを可能にするシステムおよび方法を提供すること。加えて、ビジネスアナリストおよび専門家が、既存のビジネス処理手順および自動化されたシステムとの相互運用性を煩雑なコーディングの要求事項なしに可能にするフォーマットで、ポリシー、タスク、ルール、および目的を表現することを可能にするシステムおよび方法を提供すること。【解決手段】1つの観点において、本発明は、第1および第2のルールセットが、共通のワークフローモデルによって、呼び出される、第1のルールセットおよび第2のルールセット間の関係を伝播するための方法に関する。この方法は、経路を、ワークフローモデルを通して第1のルールセットから第2のルールセットへ、順方向にトレースすることを含む。第1のルールセットから第2のルールセットへ順方向に拡張する関係を列挙することは、方法において、別のステップである。加えて、多値論理を使用して、ワークフローモデルを通して、第1のルールセットから第2のルールセットへの制御流れの関係に関する効果を計算すること、ワークフローモデルを通して、第2のルールセットから第1のルールセットへ、逆方向に経路をトレースすること、第2のルールセットから第1のルールセットへ逆方向に拡張する関係を列挙すること、および多値論理を使用して、ワークフローモデルを通して、第2のルールセットから第1のルールセットへの逆方向への制御流れの関係に関する効果を計算することも、また、この方法におけるステップである。【選択図】図２【特許請求の範囲】
【請求項１】
第1および第2のルールセットが、共通のワークフローモデルによって、呼び出される、前記第1および第2のルールセット間の関係を伝播するための方法であって、
経路を、前記ワークフローモデルを通して前記第1のルールセットから前記第2のルールセットへ、順方向にトレースし、
前記第1のルールセットから前記第2のルールセットへ順方向に拡張する関係を列挙し、かつ
多値論理を使用して、前記ワークフローモデルを通して、前記第1のルールセットから前記第2のルールセットへの制御流れの関係に関する前記効果を計算する方法。
【請求項２】
経路を、前記ワークフローモデルを通して、前記第2のルールセットから前記第1のルールセットへ、逆方向にトレースするステップと、
前記第2のルールセットから前記第1のルールセットへ逆方向に拡張する関係を列挙するステップと、
多値論理を使用して、前記ワークフローモデルを通して、前記第2のルールセットから前記第1のルールセットへの逆方向への制御流れの前記関係に関する前記効果を計算するステップとを、さらに、有する請求項１に記載の方法。
【請求項３】
前記方法が、前記ワークフローモデルに埋め込まれた前記通常の手順コードのために、フローグラフを作成し、前記フローグラフ内のノード間の関係を伝播することを含む請求項１に記載の方法。
【請求項４】
前記方法が、前記ワークフローモデルに埋め込まれた前記ビジネスルールのために、フローグラフを作成し、前記フローグラフ内のノード間の関係を伝播することを含む請求項１に記載の方法。
【請求項５】
前記多値論理が、二値論理である請求項１に記載の方法。
【請求項６】
前記少なくとも1つのシーケンスの前記再使用が容易にされるように、ワークフローステップおよびルールセットの少なくとも1つのシーケンスをメモリに格納するための方法であって、
(a) 前記シーケンスを格納し、かつ
(b) 関係情報が、シーケンス再使用を容易にするためにオペレータにアクセス可能なままである、前記シーケンス内で使用された各変数に対して計算された前記関係情報を格納する方法。
【請求項７】
前記シーケンスが、メタ情報を有する請求項６に記載の方法。
【請求項８】
前記シーケンスが、1つの入力および1つの出力を有する請求項６に記載の方法。
【請求項９】
前記関係情報が、インタフェースを通してアクセス可能である請求項６に記載の方法。
【請求項１０】
前記シーケンスが、階層に基づいて配置される請求項６に記載の方法。
【請求項１１】
ワークフローステップのシーケンスをビジネスプロセスモデルに挿入するための方法であって、
(a) 各変数に対して前記シーケンスに格納された前記関係情報を前記ビジネスプロセスモデルに対して計算された前記関係情報と比較し、
(b) 前記シーケンス内の各変数を初期化するために、コンピュータ初期化命令を作成し、かつ
(c) 前記コンピュータ初期化命令がワークフローステップの前記シーケンスの前に実行されるように、前記コンピュータ初期化命令を前記ビジネスプロセスモデルに挿入する方法。
【請求項１２】
(d) 前記シーケンス内の前記変数の前記値を前記ビジネスプロセスモデルにより使用可能である形に変換することにより、前記シーケンスを最終決定するために、コンピュータ最終決定命令を作成するステップと,
(e) 前記コンピュータ最終決定命令が、ワークフローステップの前記シーケンスの後に実行されるであろうように、前記コンピュータ最終決定命令を前記ビジネスプロセスモデルに挿入するステップとを、さらに、有する請求項１に記載の方法。
【請求項１３】
前記ビジネスプロセスモデルが、サブプロセスである請求項１に記載の方法。
【請求項１４】
関係論理管理システムであって、
少なくとも1つの論理的コンポーネントを有する、ビジネス論理を生成するために適合させられたモデラー、
前記モデラーにより生成されたビジネス論理を格納するための少なくとも1つのリポジトリ、および
ルールセットエレメント間の関連性が、双方向性の比較のプロセスを使用して決定可能である少なくとも2つのルールセットを有するシステム。
【請求項１５】
前記ビジネス論理が、少なくとも1つのワークフローを有する請求項１４に記載のシステム。
【請求項１６】
前記モデラーに応答してコードを生成するために適合させられた1つのコード・ジェネレータを、さらに、有する請求項１４に記載のシステム。
【請求項１７】
前記コード・ジェネレータからコードを受け取りかつ前記コードの一部を実行するための少なくとも1つのコード実行プログラムを、さらに、有する請求項１６に記載のシステム。
【請求項１８】
前記モデラーが、グラフィカルユーザインタフェースを含む請求項１４に記載のシステム。
【請求項１９】
各ルールセットが、少なくとも1つのルールを含む請求項１４に記載のシステム。
【請求項２０】
少なくとも1つのルールセットが、パターンマッチングルールを含む請求項１４に記載のシステム。
【請求項２１】
ビジネスプロセスモデルを解析するためのシステムであって、
少なくとも1つのルールを有する第1のルールセット、
少なくとも1つのルールを有する第2のルールセット、
前記ビジネスプロセスモデルの少なくとも一部を定義するためのワークフロー、
ルールパラメータを識別するための手段、および
前記ワークフローを変更するためのインタフェース手段を有するシステム。
【請求項２２】
前記ワークフローが、再使用可能なチャンクを有する請求項２１に記載のシステム。
【請求項２３】
ルールパラメータを識別するための手段が、入力および出力パラメータにより、ルール間の従属の関連性を検知する請求項２１に記載のシステム。
【請求項２４】
前記インタフェース手段が、グラフィカルユーザインタフェースを有する請求項２１に記載のシステム。
【請求項２５】
前記ワークフローが、少なくとも1つの経路および少なくとも1つのノードを有する請求項２１に記載のシステム。
【請求項２６】
第1および第2のビジネスパラメータが、共通のワークフローモデルにより呼び出される、前記第1のビジネスパラメータおよび前記第2のビジネスパラメータ間の関係を伝播するための方法であって、
第1の方向に沿って、前記ワークフローモデルを通して、前記第1のビジネスパラメータから前記第2のビジネスパラメータへ、経路をトレースし、
前記第1の方向に沿って、前記第1のビジネスパラメータから前記第2のビジネスパラメータへ、拡張する関係を列挙し、
多値論理を使用して、前記ワークフローモデルを通して、前記第1のビジネスパラメータから前記第2のビジネスパラメータへの制御流れの前記関係に関する前記効果を計算する方法。
【請求項２７】
第2の方向に沿って、前記ワークフローモデルを通して、前記第2のビジネスパラメータから前記第1のビジネスパラメータへ、経路をトレースするステップと、
前記第2の方向に沿って、前記第2のビジネスパラメータから前記第1のビジネスパラメータへ、拡張する関係を列挙するステップと、
多値論理を使用して、前記ワークフローモデルを通して、前記第2のビジネスパラメータから前記第1のビジネスパラメータへの逆方向への制御流れの前記関係に関する前記効果を計算するステップとを、さらに、有する請求項２６に記載の方法。
【請求項２８】
各ビジネスパラメータが、ワークフロー、ルールセット、およびルールから成るグループから選ばれる請求項２６に記載の方法。
【請求項２９】
前記第1の方向が、順方向を有する請求項２６に記載の方法。
【請求項３０】
前記第1の方向が逆方向を有する請求項２６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ビジネス管理に関し、特に、複数の相互作用プロセスおよびルールセットを含むシステムの管理に関する。
【背景技術】
【０００２】
（関連出願の相互参照）
本出願は、その開示が本明細書にその全体において参照として組み込まれている特許文献１に対する利点および優先権を請求する。
【０００３】
大企業は、商品(goods)とサービスの効率的な供給に集中された何千ものプロセスから構成される複雑な環境である。これらのビジネスプロセスの何れもが、変化するビジネスの要求を満たすのに、不十分である場合、この結果は、より高いコスト、より低い顧客満足度、および増収および増益を生む好機を逃すこととなる可能性がある。
【０００４】
会社は、自動化および手動のプロセスの組み合わせを通じて、この課題に対処している。自動化されたビジネスアプリケーションは、当初、ルーチンプロセスを扱うために、導入された。アプリケーション開発業者は、複数の別個のアプリケーションを供給し、ビジネスの敏捷性を限定し続ける限定された統合を有する個別の機能的アイランド(functional islands)を作成することにより、複雑さを管理することを試みている。ビジネス情報をこれらアプリケーションにハードコード(hard code)する従来の方法は、時折、ビジネスソリューションのために必要とされる全ての複雑さおよび柔軟性を扱うには、柔軟性がないことを示すことがある。加えて、アプリケーション内でハードコードされたこのようなビジネス情報を維持しかつ更新する高いコストは、全てのビジネスの変化がIT開発プロジェクトを要求する時、ビジネスの好機を逃すことのコストを増加させる。
【０００５】
動的な会社に対する課題は、非常に複雑なビジネスプロセスの全ての観点を扱うように設計されたシステムを選ぶことである。BPMS（ビジネスプロセス管理システム(Business Process Management Systems)）と称されるソフトウェアが、近年、会社が複雑な企業全体のプロセス管理システムを構築しかつ維持することが可能とするために開発された。最低でも、BPMSは、構造化ワークフローエンジンおよびビジネスルールエンジンの両方を含まなければならない。一般に、会社のビジネスプロセスの全体の制御流れは、構造化ワークフローモデル内に取り込まれ、一方、プロセスの複雑な意思決定コンポーネントは、形式的ビジネスルール内に取り込まれる。制御流れは、それによってビジネスプロセスがプロセスまたはモデル内の異なるステージで調整されるステップを説明する。
【０００６】
プログラムは、過去に、形式的ビジネスルールを使用して実施されるビジネスコンポーネントを解析するために、開発された。これらプログラムは、一般に、一度に１つのセットのルールを解析するように、限定される。この結果、これらプログラムは、それらがBPMSを使用して実施されるビジネスプロセスに適用される時、BPMSを使用して実施されるシステムが、典型的には、複数のセットのルールを含み、かつこれらルールセットが、しばしば、複雑な相互作用を含むであろうために、限定された有用性を有す。
【０００７】
従って、複数の相互関係にあるルールセットおよびビジネスプロセスを処理し、かつ調和させることを可能にするシステムおよび方法に対するニーズが存在する。加えて、ビジネスアナリストおよび専門家が、既存のビジネス処理手順および自動化されたシステムとの相互運用性を煩雑なコーディングの要求事項なしに可能にするフォーマットで、ポリシー、タスク、ルール、および目的を表現することを可能にするシステムおよび方法に対するニーズが存在する。
【０００８】
【特許文献１】米国仮特許出願番号第60/475,674 号(filed on June 4, 2003)
【非特許文献１】Charles L. Forgy's "RETE: A fast algorithm for the many pattern/many object pattern match problem", Artificial Intelligence 19(1): 17-37, September 1982
【発明の開示】
【発明を解決するための手段】
【０００９】
RLMS（関係論理管理システム(Relational Logic Management System)）の観点を詳細に議論する前に、本明細書で使用される幾つかの特有の専門語の説明は、有益であろう。しかしながら、本明細書で議論される用語の範囲は、限定することを意図するものではなく、むしろそれらの使用を明らかにし、および用語の最も広い意味を当業者に公知であるように組み込むことを意図する。特に、本明細書で要約される幾つかの用語は、ワークフロー(workflow),制御流れ(control flow)、ビジネス論理(business logic)、関連性(relationship),情報(information)、関係情報(relational information)、およびメタ情報(meta-information)を含む。
【００１０】
ワークフローは、２つ以上のビジネスユニット（または、個人）が、共同で共有し、管理し、および情報に基づいて動作させる、その手順を含む。ワークフローは、特別のシーケンスにおいて実行される一連のタスクを含む。これらのタスクの実行の結果、ビジネスにより望まれる結果が、達成される。このことは、個人および／または部門間のワークのフローが、定義かつ追跡されることを可能にする。その結果、会社のワークフローは、一般的に、複数のユーザおよびステージを含む。
【００１１】
ワークフローは、特別のワークプロセス、ワークを実行する時に使用される情報従属性、および決定とアクティビティのシーケンスを含む、ワークのフローおよびそれの関連するコンポーネントのグラフィック表示であることが可能である。ワークフローは、入力が要求される所、決定ノードの位置、および出力経路における代替の分岐を定義することができる。ワークフローは、個人および／または部門間のワークのフローを追跡すること、並びに、行われるべきワークの基本説明を提供すること容易にする。このように、ワークフローは、一実施例において、ライン、分岐、ノード、および機能ブロックを組み込んでいるグラフにより一般に特徴付けられることが可能である。
【００１２】
制御流れは、ビジネスプロセスがそのプロセスにおいて異なるステージで調整されるステップを説明する。一実施例において、制御流れは、次のタスクがスタート可能な前に、１つのプロセスステップが完成されるという必要条件のような、より大きなワークフローにおける様々の制限を説明する。制御流れは、順番に、どのように、何時、および誰によって、ステップが、論理的関連性に基づいて実行可能かを説明する、if、then、およびelseステートメントによって、定義可能である。
【００１３】
ビジネス論理は、また、ビジネスに関連する考えを表現するために、量、関連性、引数、決定および他の概念を表す記号および式の使用を含む。加えて、ビジネス論理は、結論が1つ以上の入力から導出可能であるように、任意のビジネス関連表現および／または情報に関する。典型的には、これらの入力は、ビジネスのタスク、プロセス、およびワーク製品に関する。1つの観点において、ビジネス論理は、ワークフロー、ビジネスルール、およびルーティングルールの少なくとも1つを含むが、これらに限定されるわけではない。
【００１４】
関連性(relationship)または関係(relation)は、所定のエレメントに関連する少なくとも1つの属性に部分的に基づく2つのエレメント間のリンクまたは接続を説明する。さらにまた、関連性は、同じまたは異なるセットのエレメント間で、具体的である、抽象的である、存在するまたは可能である、エレメントの相互作用を特徴付ける、結合または接続である。加えて、1つ以上のエレメント間の関連性は、それらの互いに対する個々の従属、それらのお互いの相互従属、および／またはそれらの無従属性を説明する。2つのエレメントおよびその個々のエレメント自体間の接続のためのタイプおよびベースは、限定されない。
【００１５】
いくつかの典型的なエレメントは、ルール、変数、プロセス、ワークフローコンポーネント、プロジェクト、タスク、およびビジネスユニットを含むことが可能であるが、それらに限定されるわけではない。それらの間に関連性が存在することが可能な他の適切なエレメントは、本出願を通して説明される。
【００１６】
関連性は、異なるエレメントが互いに関連づけられる方法を列挙することができる。例えば、いくつかのエレメントは、多対多の関連性、多対1の関連性、１対多の関連性、１対1の関連性、またはそれらの組み合わせを有することができる。他の具体例において、エレメントは、原因と結果の関連性を共有することができる。異なるエレメント間の様々の他の関連性は、本出願を通して議論される。
【００１７】
部分的に、情報という用語は、コミュニケーションおよび使用が可能な或る形のデータを説明するために使用される。情報は、知識の表現である。このように、情報は、任意の媒体または形における、事実、仮定、またはコンテンツを含むが、これらに限定されるわけではない。情報の適切な形は、テキスト、数字、変数、グラフィックス、イメージ、聴覚的信号およびそれらの組み合わせを含むが、これらに限定されるわけではない。関係情報は、1つ以上のエレメント間の関連性に関する何かを伝達する。
【００１８】
メタ情報は、いくつかの基礎をなすコンテンツに関して、間接的に定義される。従って、メタ情報は、2次情報であり、このように、それは、情報に関する情報である。ドキュメントのコンテキストにおいて、著者の識別、または原稿が最初に書かれた時は、両方とも、ドキュメント自体の情報コンテンツに対比して、メタ情報である。
【００１９】
関係管理システムは、様々の観点および特定の実施例を含む。1つの観点において、本発明は、第1および第2のルールセットが、共通のワークフローモデルによって、呼び出される、第1のルールセットおよび第2のルールセット間の関係を伝播するための方法に関する。この方法は、経路を、ワークフローモデルを通して第1のルールセットから第2のルールセットへ、順方向にトレースすることを含む。第1のルールセットから第2のルールセットへ順方向に拡張する関係を列挙することは、方法において、別のステップである。加えて、多値論理を使用して、ワークフローモデルを通して、第1のルールセットから第2のルールセットへの制御流れの関係に関する効果を計算することは、方法において、別のステップである。従って、方法は、順方向に、動作することができる。
【００２０】
一実施例において、方法は、また、経路を、ワークフローモデルを通して第2のルールセットから第1のルールセットへ、逆方向にトレースするステップと、第2のルールセットから第1のルールセットへ逆方向に拡張する関係を列挙するステップと、多値論理を使用して、ワークフローモデルを通して、第2のルールセットから第1のルールセットへの逆方向への制御流れの関係に関する効果を計算するステップとを含む。よって、一実施例において、方法は、順方向、逆方向、または両方の組み合わせた方向に、動作することができる。
【００２１】
一実施例において、方法は、ワークフローモデルに埋め込まれた通常の手順コードのために、フローグラフを作成すること、フローグラフ内のノード間の関係を伝播することを含む。別の実施例において、方法は、ワークフローモデルに埋め込まれたビジネスルールのために、フローグラフを作成すること、フローグラフ内のノード間の関係を伝播することを含む。さらに別の実施例において、多値論理は、二値論理である。
【００２２】
別の観点において、本発明は、少なくとも1つのシーケンスの再使用が容易にされるように、ワークフローステップおよびルールセットの少なくとも1つのシーケンスをメモリに格納するための方法に関する。方法は、シーケンスを格納すること、および関係情報が、シーケンス再使用を容易にするためにオペレータにアクセス可能なままである、シーケンス内で使用された各変数に対して計算された関係情報を格納することを含む。
【００２３】
方法の一実施例において、シーケンスは、メタ情報を含む。方法の別の実施例において、シーケンスは、1つの入力および1つの出力を有する。方法のさらに別の実施例において、関係情報は、インタフェースを通してアクセス可能である。方法のさらに別の実施例において、シーケンスは、階層に基づいて配置される。
【００２４】
別の観点において、本発明は、ワークフローステップのシーケンスをビジネスプロセスモデルに挿入するための方法に関する。方法は、各変数に対してシーケンスに格納された関係情報をビジネスプロセスモデルに対して計算された関係情報と比較すること、シーケンス内の各変数を初期化するために、コンピュータ初期化命令を作成すること、およびコンピュータ初期化命令がワークフローステップのシーケンスの前に実行されるであろうように、コンピュータ初期化命令をビジネスプロセスモデルに挿入すること含む。
【００２５】
一実施例において、方法は、さらに、シーケンス内の変数の値をビジネスプロセスモデルにより使用可能である形に変換することにより、シーケンスを最終決定するために、コンピュータ最終決定命令(computer finalization instructions)を作成するステップと、コンピュータ最終決定命令が、ワークフローステップのシーケンスの後に実行されるであろうようにコンピュータ最終決定命令をビジネスプロセスモデルに挿入するステップとを含む。別の実施例において、ビジネスプロセスモデルは、サブプロセスである。
【００２６】
さらに別の観点において、本発明は、関係論理管理システムに関する。システムは、ビジネス論理を生成するために適合させられたモデラー、モデラーにより生成されたビジネス論理を格納するための少なくとも1つのリポジトリ；および少なくとも2つのルールセットを含む。モデラーは、少なくとも1つの論理的コンポーネントを含む。加えて、ルールセットエレメント間の関連性は、双方向性の比較のプロセスを使用して、決定可能である。
【００２７】
システムの一実施例において、ビジネス論理は、少なくとも1つのワークフローを含む。別の実施例において、システムは、さらに、モデラーに応答してコードを生成するために適合させられた少なくとも1つのコード・ジェネレータを含む。さらに別の実施例において、システムは、さらに、コード・ジェネレータからコードを受け取りかつコードの一部を実行するための少なくとも1つのコード実行プログラムを含む。システムのさらに別の実施例において、モデラーは、グラフィカルユーザインタフェースを含む。システムのさらなる実施例において、各ルールセットは、少なくとも1つのルールを含む。システムのさらなる実施例において、少なくとも1つのルールセットは、パターンマッチングルールを含む。一実施例において、パターンマッチングルールは、実行時に正しいデータを捜し出すために、ルールエンジンに依存して、それが動作するデータを説明するために、1つ以上のパターンマを使用するルールである。非パターンマッチングルールは、それらが動作するデータを特定するために、名前付き変数を使用する。
【００２８】
さらに別の観点において、本発明は、ビジネスプロセスモデルを解析するためのシステムに関する。システムは、少なくとも1つのルールを含む第1のルールセットおよび少なくとも1つのルールを含む第2のルールセットを含む。加えて、システムは、ビジネスプロセスモデルの少なくとも一部を定義するためのワークフロー、ルールパラメータを識別するための手段、およびワークフローを修正するためのインタフェース手段を含む。
【００２９】
システムの一実施例において、ワークフローは、再使用可能な論理的シーケンスを含む。システムの別の実施例において、ルールパラメータを識別するための手段は、ルール間の入力および出力パラメータにより、従属の関連性を検知する。システムのさらに別の実施例において、インタフェース手段は、グラフィカルユーザインタフェースを有する。システムのさらに別の実施例において、ワークフローは、少なくとも1つの経路および少なくとも1つのノードを含む。
【００３０】
別の観点において、本発明は、第1および第2のビジネスパラメータが、共通のワークフローモデルにより呼び出される、第1のビジネスパラメータおよび第2のビジネスパラメータ間の関係を伝播するための方法に関する。この方法は、第1の方向に沿って、ワークフローモデルを通して、第1のビジネスパラメータから第2のビジネスパラメータへ、経路をトレースすること、第1の方向に沿って、第1のビジネスパラメータから第2のビジネスパラメータへ、拡張する関係を列挙すること、多値論理を使用して、ワークフローモデルを通して、第1のビジネスパラメータから第2のビジネスパラメータへの制御流れの関係に関する効果を計算することを含む。一実施例において、方法は、また、第2の方向に沿って、ワークフローモデルを通して、第2のビジネスパラメータから第1のビジネスパラメータへ、経路をトレースするステップと、第2の方向に沿って、第2のビジネスパラメータから第1のビジネスパラメータへ、拡張する関係を列挙するステップと、多値論理を使用して、第2の方向に沿って、ワークフローモデルを通して、第2のビジネスパラメータから第1のビジネスパラメータへ、制御流れの関係に関する効果を計算するステップとを含む。一実施例において、各ビジネスパラメータは、ワークフロー、ルールセット、およびルールから成るグループから選ばれる。一実施例において、第1の方向は、順方向である。別の実施例において、第1の方向は、逆方向である。
【００３１】
本発明の1つの観点において、RLTコンポーネントは、(1)ワークフローを通してフォロー可能である複数の経路を考慮して、情報を、順方向および逆方向にワークフローを通して伝播することができ、および(2)用語および用語の定義に関する制約を含むプロセスに関するメタ情報を用いて動作することができ、このことによって、RLTコンポーネントがビジネス論理の意味並びに構文解析を実行することを可能にする。
【００３２】
別の観点において、本発明は、新しいコンテキストにおけるビジネス論理の既存のフラグメントまたはモジュールの再使用を容易にするための方法を含む。RLMSにおける再使用のユニットは、多くの特性を伴う、ワークフローステップのシーケンス、ルールセット、または両方である。特性は、RLMSが、新しい環境における再使用のためにシーケンスを適合させる時、含まれるステップの多くを自動化することを可能にする。
【００３３】
本発明の他の特徴および利点は、以下の詳細な説明および図面から明らかになるであろう。
【発明を実施するための最良の形態】
【００３４】
本発明の目的および特徴は、以下に説明される図面および請求項を参照して、より良く理解することができるであろう。これらの図面はスケールが比例的に示されておらず、その代わり、一般に、本発明の原理を例示する部分が強調されて示されている。図面において、同じ番号は、様々の図を通して、同じパーツを示すために使用される。
【００３５】
この時点で公知の本発明を実施するための最良の形態を含む本発明の好適および代替の実施例は、添付の図面と関連して、本明細書で、詳細に説明される。しかしながら、本発明がこれら実施例に限定されるわけではないことは、明白に留意されるが、むしろその意図は、当業者に明らかであり、かつそれらの等価物である変更もまた含まれるということである。
【００３６】
本発明は、本明細書において、関係論理管理システム(RLMS)と称される、部分的に、強化されたビジネスプロセス管理システムである、新しいシステムの観点を含む。RLMSは、ビジネス論理を取り込み、管理し、解析し、配布し、および実行するために、モデル化環境、実行環境、および論理リポジトリを提供する。RLMSの解析コンポーネントは、RLMSの関係論理テクノロジ(RLT)コンポーネントと称される。高度なルールエンジンと高度なビジネスプロセス管理システムとを組み合わせることは、ビジネスアナリストが、既存のビジネスをモデル化し、テストし、最適化し、および解析することを可能にする、効率的に統合されたアプローチとなる。この統合されたアプローチは、本発明の1つの観点を表す。
【００３７】
RLTコンポーネントは、コンフリクトする専門語を使用する異なるルールセットから生じる問題を含む、多くの問題点に対処する。RLTは、個々のルールセットおよび個々のルールセットを含むワークフローを理解し、かつ統合する。RLTコンポーネントは、典型的には、解析的および視覚化特徴を含む。これらは、ビジネスプロセス設計における、正確さ、整合性および完全性を保証するために、使用される。本発明の観点は、さらに、論理エラー、不完全または矛盾しているルール、および欠陥のあるワークフローに関する視覚フィードバックを提供することにより、これら目標をサポートする。このことは、新しいビジネス要求を満たし、かつユーザのフィードバックに応答することができる変化を可能にする。複数のルールセットを用いて、複数のワークフローステップにわたって、部門内で、または企業にわたって、全体の、複雑なビジネスプロセスを解析する能力は、多くの利点をビジネスアナリストに提供する。本発明のこれらおよび他の観点は、以下にさらに詳細に議論される。
【００３８】
図1を参照すると、RLMシステム10は、ビジネス論理をモデル化し、かつ生成するために、ビジネスアナリストおよび情報テクノロジ(IT)スタッフのために、モデラー12を含む。モデラー12は、幾つかの論理的コンポーネントを有する。異なる典型的論理的コンポーネントを有する典型的なモデラーは、図2に示される。一実施例において、典型的なモデラーは、プロセスモデラー13a、メタデータモデラー13b、ルールモデラー13c、および／または関連性モデラー13dを含むことができる。しかしながら、別の実施例において、モデラーは、所定のビジネスアプリケーションに対して典型的なエレメントおよび情報をモデル化することができる1つ以上の一般化された論理的コンポーネントを含む。
【００３９】
論理が、モデル化された後、それは、論理リポジトリ14に格納される。システムは、決定サポートおよびワークフロービジネス論理のために、コード、一実施例においてはJavaコードを生成する。このコードは、論理サーバー16により実行され、このサーバーは、モデラー12により定義されたルールおよびプロセス用のコードを実行するための、堅牢かつ拡張性のある環境である。サーバー16は、ビジネスプロセスが、完成される必要がある時、アプリケーションソフトウェアおよびユーザを自動的に促すことができる。加えて、それは、進行を追跡し、実行をモニターし、および包括的な履歴監査証跡を維持することができる。論理サーバー16は、業界標準RETEまたは強化されたRETE照合(matcher)を用いるルールエンジンに基づくことが可能である。本発明の一実施例の使用に適した典型的なRETEアルゴリズムは、その開示が、本明細書に、その全体において、参照として組み込まれる、非特許文献１に開示されている。しかしながら、論理サーバー16は、他の論理的エンジンまたは企業システムコンポーネントを含むことができる。示されるアナライザ18は、一旦、それが、ユーザにより最終決定される時、またはビジネスモデルの開発における中間段階で、そのビジネスモデルを検討し、かつ特徴付けるために、関係論理テクノロジを使用する。
【００４０】
複数のリポジトリが、可能であるにもかかわらす、RLMSは、好ましくは、ビジネス論理の格納および管理用の単一の共通のリポジトリ14を有する。また、図2に示されるように、モデラーからの論理は、XMLベースのフォーマットで表されることが可能であり、それが、RLMSおよび他のビジネスアプリケーション間を素早く移動させることを可能にする。しかしながら、他の実施例において、論理は、任意の適切なフォーマット、プロトコル、またはプログラミング言語により、表現可能である。論理が共通のフォーマットで表されるので、それは、企業にわたって、ビジネス論理の整合的な概観を提供する。トランスレータ・ディプロイヤー19は、RETEエンジンのような論理エンジン20用のXMLまたは別の適切なフォーマットを転送または変換するために、使用可能である。オプションのワーク管理プログラム21は、また、オペレーション・スタック要員、ビジネス経営陣、および他の会社従業員間の協調を可能にするタスク管理能力を提供する、RLMSのいくつかの実施例において、組み込み可能である。
【００４１】
モデラー12は、典型的には、ユーザがワークフローを作成することを可能にするグラフィカル、ドラッグ・アンド・ドロップインタフェースを使用する。しかしながら、情報をモデラーに伝達するための任意の適切なインタフェースは、使用可能である。いくつかの実施例において、ワークフローは、分岐により相互接続される機能ブロックにより、表わされる。グラフィックユーザインタフェース(GUI)に組み込んでいる典型的なワークフローは、図3Aに示される。
【００４２】
図3Aに示されるワークフローは、例えば、モーゲージリファイナンスプロセスのようなビジネスプロセスがどのように表わされることが可能かを示す。図示されるグラフィカル表現は、図2に関して導入されたRLMSのモデラー部分の1つの実施例に対応する。典型的なワードプロセッサまたは図表作成プログラムは、静的グラフィックスを生成する、しかしながら、モデラーは、インテリジェントかつ進化するツールである。図3Aに示されるような異なるプロセスに対応する一連のブロックは、分岐およびノードにより、互いに接続可能である。フローライン、分岐およびノードを接続するこの集合は、一般的に、グラフと称される。情報は、異なる入力および出力の間を通過する。加えて、異なるルールセットは、情報およびデータのフローをコントロールするために、ブロックのいくつかまたは全てに対して、定義可能である。手動および自動のプロセスの両方は、RLMSを使用して、モデル化可能である。一旦、モデルが完成すると、RLMSの異なる観点は、使用可能であるルールを解析し、かつそれらの相互作用をワークフローに示された連関に部分的に基づいて記述する。加えて、現在の、履歴のまたはシミュレートされたデータは、モデルをテストし、かつ特定のビジネス操作を評価するために、導入可能である。
【００４３】
RLTが解決するように設計されたコンフリクトするルール問題の具体例として、モーゲージ貸し出し組織により、使用可能であろう2つのルールを考慮されたい。この具体例に関する典型的なワークフローは、図3Bに示される。モデラーにおける、ワークフロー実施例は、買い手が、財産価値の少なくとも5%の頭金を有さなければならないことを述べるビジネスルールを有するセールス部門を示す。モーゲージ実行部門は、モーゲージをその財産価値の90%を超えて発行することができないという、ビジネスルールを有する可能性があろう。これらのルールは、独立した状態では、合理的であるが、それらは、ギャップを有し、従って、コンフリクトする。
【００４４】
しかしながら、2つの理由のために、既存のシステムは、一般的に、このコンフリクトを見つけないであろう。第一に、ルールは、異なるルールセット内にあり、そのルールセットの第一のものは、セールス部門により使用され、そのルールセットの第2のものは、実行部門により使用される。これら2つのルールセットは、単に、両方が同じ全体のビジネスプロセスの部分であるので、リンクされる。しかしながら、両方の典型的なルールは、プロセスの異なるステージで、実行される。第二に、ルールは、異なる専門語：「頭金(down payment)」額に対して「モーゲージ(mortgage)」を使用する。このコンフリクトを識別するために、本システムは、用語「頭金」、「モーゲージ」および「財産価値(property value)」間の関係を知らなければならないであろう。
【００４５】
RLMSは、2つのモーゲージ・レート・ルール間のコンフリクトを認識することができる。従って、ビジネスアナリストは、論理エラーに関する即時の視覚フィードバック、不完全または矛盾しているルール、および正しくないワークフローを受け取る。この場合、視覚フィードバックは、図3Bのこの典型的実施例において、様式化された感嘆符により示される。さらに、RLMSシステムの実施例に組み込まれたGUIインタフェースの結果として、視覚フィードバックインジケータをクリックすることは、エラーメッセージに関するさらなる詳細およびシステムの異なる部分へのアクセスを可能とする。図4Aおよび4Bに示すように、GUIは、図3Bのワークフロー内のコンフリクトするルールがさらに詳細に調べられることを可能にする。しかしながら、図4Aおよび4Bに示されるコンフリクトは、2つの異なるルール間の衝突に関係する。
【００４６】
特に、図4Aおよび4Bは、図3Aおよび3BのDetermine Rate ブロックに関連する情報の幾つかを示し、かつ拡張する。図4Aにおいて、Determine Rate ブロックに関連するルールが、示される。一方、図4Bにおいて、衝突しているルールの特有の性質、並びにルールを記述する特定のIf、Then論理的関係を示す、ルール解析およびルール比較ウインドウが、示される。従って、不完全性、未使用の変数、全般的な優先権または公式的ルールの違反、またはルール範囲内のコンフリクトの多くのタイプを含むビジネスモデルの包括的な解析は、可能である。このように、ビジネスアナリストは、会社に対して不動産金融のプロセスを改善するために、ルールを調整する、またはワークフローを変化させることができるであろう。ルールモデル化およびワークフローの柔軟な性質は、迅速な変化および正確なビジネスモデル化を可能とする。
【００４７】
ワークフローは、その各々がアイコンにより表わされる、行われる必要があるプロセス、選択、ループ、および他の形の枝分かれを含むことができる。一旦、プロセス、選択、または他のオプションが選択されると、ユーザは、その選択のためのプロセスまたはルールを定義することができる。モデラーのこの観点は、プログラミングまたは記号操作に経験のないビジネス 専門家が、特定のビジネスユニットまたはプロセスの動作を作成することを可能にする。
【００４８】
ワークフローを論理的にアセンブルするために使用される幾つかのブロックは、複数のコンポーネントに拡張される。例えば、２方向の分割は、一方端では、分岐、およびその分岐が一緒になった後の他端では論理的排他論理和(XOR)である。分岐している部分において、ユーザは、その分岐を支配するであろうルールを識別することができる。この具体例は、そのStart Fulfillmentブロックで、図3Aおよび3Bに示される。例えば、変数が第1の値を有する場合、そのフローは、一方向に分岐し、およびそれが第2の値を有する場合、その時は、第2の方向に分岐する；例えば、受け取られるインボイスは、額を表す変数の値、または請求されている部門を表す変数に依存して、異なってルートを決められる可能性がある。図3Aおよび3Bにおいて、デフォルトルールは、マーケティングに送信される実行プロセスのスタートに存在する情報に対してである。しかしながら、アプリケーションプロセスがアプリケーションの受け入れになった場合、その情報は、保険の引受業務に送信される。
【００４９】
プロセスブロック範囲内で、システムは、入力に関して動作する、1つの、幾つかの、または多くのルールを有することができ、潜在的に多くの分岐ステップの代わりをし、かつフローの複雑さを低減する。従って、大きな複雑な非効率的なタスクは、ワークフローにおいて個別のプロセスブロックを形成するために、組み合わせ可能である。
【００５０】
ワークフローを定義し、かつ自動的にコードを生成するために、グラフィカルユーザインタフェースおよびドラッグ・アンド・ドロップシステムの使用は、ルール解析およびビジネスモデル化プロセスを単純化する。本発明の実施例によるモデラーにおいて、しかしながら、ワークフローのコンポーネントは、明確に定義され、かつ相対的に少ない数の特別の機能タイプに制約される。ユーザは、ステップ間のフローを示すために、ステップ間のラインに入らないで、2つの他のプロセス間のプロセスまたはブロックをドロップすることができ、この場合、ライン、それ故それらの間のフローは、自動的に確立されるであろう。代替の経路を作成するために、ユーザは、複数の分岐を有するブロック作成するために、分割または選択を選ぶことができる。この制約されたシステムは、分岐間のフローのような、作成可能であろう幾つかのフローを限定することができる。しかし、このシステムにおいて、可能ではないフローは、あまり使用されずかつ他の方法で表現可能である。いくつかの実施例において、制約されたオプションのセットを保持することにより、さらに効率的な結果およびモデル作成は、提供される。
【００５１】
関係論理管理プラットフォームは、ルールを基に構築され、かつ本質的にそのルールをその基礎をなす言語として使用する。関連性モデラーは、関係論理モデル化（例えば、アクティビティ間の従属性を解析すること）をサポートし、また、ランタイム実行（例えば、トランザクション管理）のための概念上のレイヤを提供する。図5に示すように、関連性管理は、少なくとも3つのレベル：変数、ルール、およびチャンクと称される情報の論理的シーケンスを有することができる。一般に、“チャンク”は、RLMSのコンポーネントにより再使用可能な情報の一部またはシーケンスである。ワークフローステップおよび／またはルールセット、および特性を有する論理のシーケンスは、一実施例において、特別のタイプのチャンクであることができる。チャンキングの概念および利点は、以下に詳細に、議論される。
【００５２】
一般に、異なる特徴および機能性は、所定の関連性モデラー実施例と関連可能である。関連性モデラーは、異なる関連性管理レベルにおいて、関連性を定義することができ、および図3Aと3Bに概略的に示されるような関連性を表すことができる。これに代えて、関係マップは、図6に示されるように、異なる階層のレベルで構成されたモデルを視覚化するために、使用可能である。図6の関係マップは、図3A〜4Bにより説明されるモデルの一部に対応する。関係マップは、ルール、ワークフロー、および変数の可能な影響をトレースするのを助ける変数間の関連性の概観を提供する。
【００５３】
ユーザがズームインおよびズームアウト操作を用いて階層をナビゲートすることを可能にするために、プロセスフローレベルで、およびアクティビティレベルでのような異なるレベルで関連性を示しかつ管理することは、関連性モデラーの別の観点である。さらに、所定の関連性モデラーは、ルール間の従属の関連性およびチャンクを導出することができる。この導出プロセスは、任意の入力パラメータが最初に定義される必要がある否かを決定するために、アップストリームで解析される、チャンクの入力パラメータに基づくことができる。ルールの入力および出力パラメータにより定義されたルール間の潜在的な従属の関連性を見つけることは、また、モデラーの機能セットの範囲内である。
【００５４】
確立された関連性を利用すると、モデラーは、ルールおよびプロセス変更に対して、影響解析を実行することができる。任意の変更されたルールまたはプロセスステップに対して、それは、全ての他の影響されたステップとルールおよび変更に起因する可能な影響を示す。
【００５５】
関連性管理は、モデル化ステージおよび実行ステージの両方で、役割を果たすことができる。モデル化ステージの間、関連性管理は、様々の機能を実行することができる。或る典型的な機能は、チャンク／ルール従属性解析（入力従属性、変化管理）；変数定数変化管理；制約妥当性確認；コンフリクト検知；および「what if」影響解析を含むが、それらに限定されるわけではない。同様に、実行ステージ中、関連性管理システムは、変数定数変化管理；制約妥当性確認；およびコンフリクト検知を含むが、これらに限定されるわけではない機能を実行することができる。
【００５６】
関係論理テクノロジシステムは、変数、ワークフローステップ、個々のルール、ルールのグループ、完成したルールセット、およびワークフローステップおよびルールセットのユーザ定義のグルーピングをも含むビジネスプロセスの全てのコンポーネント間の関係を捜し出し、かつ解析する。関係は、RLTコードにより、自動的に、導出可能であり、それらは、ユーザにより供給可能であり、およびそれらは、RLTコードにより、提示可能でありかつユーザにより認可または不認可が可能である。
【００５７】
関係のこの解析は、ビジネスプロセスの継続時間の間に、複数度、有効である。プロセスモデル化の時、RLTは、(1)ビジネス論理内の問題を捜し出すために、プロセスの構文および意味解析を実行するために、(2)論理に対する提案された変化の影響解析を実行するために、および(3)システムが特別の状況で何を行うかを決定するために、論理のwhat-if解析を実行するために、使用可能である。実行時には、RLTにより作成された情報は、変数がモニター可能である、制約が実施可能である、および統計が取り込み可能であるように、プロセスをモニターするために使用可能である。デバッグ時には、RLTにより作成された情報は、プログラマーがシステムの基礎をなす動作を理解することを助けるために、使用可能である。
【００５８】
RLTシステムは、幾つかの有効である以下の特徴を有する：(1)設計およびメンテナンス時における、形式的ビジネスルールおよび構造化ワークフローの両方を表す共通のモデル、(2)形式的ビジネスルールおよび構造化ワークフローの両方のための共通の実行プラットフォーム、および(3)関係の計算法を実施するコンピュータコード。ルールおよびワークフローの両方のための共通のモデルは、RLTコンピュータコードが、ルールおよびワークフローの両方に関して、動作することを可能にし、2つのルールセット間のみではなく、2つのワークフローステップ間およびルールおよびワークフローステップ間にも関係を見つけ出す。例えば、変数がワークフローステップ内にセットされ、かつ続くルールセット内で使用される場合、RLTコードは、ルールの2つのセット間の関係を、認識しかつ扱うことができる。
【００５９】
共通の実行プラットフォームは、RLTが実行時にルールおよびワークフローの両方に関して、動作することを可能にする。例えば、システムは、実行時に、制約がルールによりまたはワークフローステップにより違反されるか否かに関係なく、制約違反を識別することができる。RLTは、  ルールコンフリクト、曖昧さ、不一致、オーバーラップ、冗長性、および完全性、並びに完成したプロセスの範囲内かつ全体での優先権および公式的な関連性の実施を識別する。加えて、RLTのアプリケーションは、また、プロセスの範囲内かつ全体にわたって、ルール、ワークフロー、およびそれらの変数間の従属性および関連性を検知することができる。
【００６０】
本発明の1つの実施例によるRLTは、好ましくは、以下の4つの機能の少なくとも1つを含む：
(1) 組み合わされたモデルにおいて、ワークフローステップおよびビジネスルールの両方から関係を抽出すること；
(2) ルールに対する関係ルールを、ルールセットからルールセットへ、ワークフローステップからワークフローステップへ、およびワークフローステップおよびルール間へ、伝播すること；
(3)設計時に、関係により、発見される意味エラーを認識すること；および
(4)ランタイム統計を収集し、並びに制約のランタイム違反を見つけるために、ワークフローおよびビジネスルールプロセスの実行を、実行時にモニターすること。
【００６１】
全部のRLMSおよび関係論理テクノロジコンポーネントは、所定のプロセス、サブプロセス、または全部のワークフローを通して、制御流れの部分を定義するために、ルールを使用する。ルールは、変数および制約をそれらのデータ項目として使用する。同時に、それらは、所定のルールのためにコンテキスト環境を作り上げる。各定数は、宣言的に定義される、名前、タイプ、および値を有することができる。変数の値は、ランタイムの時に、変化可能である（例えば、ルールを通して変更される）。各変数は、名前、タイプ、初期値、および特別基準を有することができる。しかしながら、他の特徴は、異なる実施例において、所定の変数に関連可能である。
【００６２】
ルールは、典型的には、If部分およびThen部分（Else部分がオプションのルール部分である）を有する。AndおよびORのようなブール部分は、また、ルールの範囲内で、組み込み可能である。従って、会社のクレジット処理手順に対する、2つの特別の典型的な相互関係のあるルールは、以下のように書かれるであろう：
2007526535.tif 000002
【００６３】
このルールの“if”部は、条件を含み、およびルールの“then”部は、アクションを含む。ルール符号化のためのこのフォーマットは、また、図4Bに関して、上記で示される。
【００６４】
しかしながら、RLMS用に選択されたルールエンジン実施例が、共通のフォーマットで書かれた論理を使用するので、符号化フォーマットをベースとする任意のタイプのルールは、それがRLMSを通して一貫して使用される限り、使用可能である。
【００６５】
メタデータは、また、特定のルールに対して、定義可能である。ルールに対するメタデータは、以下を含むことが可能である：
分類：特別のルール分類するための、（属性値）使用された対のリスト
・管轄：ルールが適用される構成を識別するために使用された（属性値）対のリスト
・入力パラメータ：ルールに使用されたコンテキストデータ
・出力パラメータ：ルールにより変化させられたコンテキストデータ
・任意の拡張子（例えば、ルール関連性を取り込む）
【００６６】
ルールおよび変数間に、多対多の関連性が存在する、すなわち、各ルールは、多くの変数を有することができ、および各変数は、多くのルールにおいて、使用可能である。しかしながら、ルールおよび変数間の他のさらに限定された関連性も、また、可能である。変数およびルール間の垂直的な関連性は、効率的な照会のために、取り込み可能である。例えば、変数の値が変化される時、システムは、変数を使用する全てのルールを見つけることができる。
【００６７】
伝播は、一般に、全体のワークフローおよびそのコンポーネントを解析し、かつさらに十分に理解するために、特定のワークフローの構成するエレメント間の相互関連性を調べることを指す。伝播は、データを上記議論された技術を使用して準備された適用可能なモデルに導入することにより、ビジネスデータのテストするために、使用可能である。これに代えて、伝播は、ルールコンフリクト、冗長性、またはオーバーラップをチェックするために、使用可能である。好適な実施例において、RLTシステムは、関連性の様々のクラスを識別かつ解析することができる。RLMSの範囲内で使用可能であるまたはそれによって解析可能ないくつかの典型的な関連性は、メンバーシップ、変数、ルール、およびルールグループ関連性を含むが、それらに限定されるわけではない。加えて、階層の分類基準、構成構造、意味ネットワーク、論理的従属性、時間性、および入力／出力関連性は、また、識別かつ解析可能である。従って、変数、ルール、プロセス、ワークフローステップ、およびRLMSの他のエレメント間のこれらのタイプの関係は、ビジネスの観点をモデル化し、かつその操作を効率的にするために、使用可能である。
【００６８】
メンバーシップ関連性は、RLMSのエレメントが使用および／または類別される方法を説明する。変数のメンバーシップは、様々の方法で、識別可能である。変数は、ルール内で使用可能である。変数は、ルールの条件において使用可能である。変数は、ルールのアクションにおいて、使用可能である。変数は、ルールのその条件およびアクションの両方において使用可能である。変数は、ルーティング条件において、使用可能である。変数は、ワークフローステップにおいて使用可能である。所定のルールは、ルールグループまたはルールセットに属することが可能である。これに代えて、特定のルールは、一意的に、定義可能である。
【００６９】
異なるエレメントのメンバーシップ関係に加えて、変数の関連性の特別の機能的観点は、ルールを特定し、プロセスをモデル化し、および所定のモデルを最適化するために、定義かつ使用可能である。変数は、他の変数のブール関数であることが可能である。変数は、他の変数の定性的関数であることが可能である。変数は、他の変数の定量的関数であることが可能である。所定の変数の特徴および機能的特性は、任意の営業活動のために、必要に応じて、定義可能である。所定の共通のワークフローモデルに対する複数のルールセット間に関連性を伝播することは、RLMSの別の観点である。
【００７０】
ルールセット間の関係を伝播することは、様々のルールパラメータおよびルールエンジンにより確立された定義の機能であることが可能である。ルールエンジンは、２つ以上のルールに対して、コンフリクト、衝突、包含しているイベント、影響、不可能な条件および不完全性を定義する基準を提供することができる。いくつかの典型的な  ルール相互作用基準は、以下の通りである：
・2つのルールが、等価な条件および異なるアクションを有する場合、ルールは、別のルールとコンフリクトする、
・2つのルールが、異なる条件および等価なアクションを有する場合、ルールは、別のルールと衝突する。
・第1のルールが第2のルールより、それらの条件において、より一般的である場合、ルールは、別のルールを包含する。例えば、ルール1は、条件(A and B)を有し、かつルール2は、条件(A)を有し、ルール2は、ルール1を包含する。
・2つのルールの条件が、同じデータの全てではないが、一部により満たされる場合、ルールは、別のルールにオーバーラップする。
・2つのルールが等価な条件およびアクションを有する場合、ルールは、別のルールに意味論的に等価である。
・第1のルールのアクションが、第2のルールに影響を有する場合、ルールは、別のルールに影響する。例えば、ルール1がルール2において定義される変数を使用する場合、ルール2は、ルール1に影響する。
・他のルールが、ルールの条件部が満たされる状況を作成することができない場合、ルールは、達成されない。
・ルールの条件が、生じる可能性がある状況の全てではないが一部をカバーする場合、ルールのグループは、不完全である。
【００７１】
一般に、ルールグループ（ルールセット）は、所定のルールに適用される同じ技術を使用して、評価かつ伝播可能である。よって、ルールエンジンは、ルールグループ間の相互作用の性質を定義する基準を提供することができる。いくつかの典型的な  ルールグループ相互作用基準は、以下の通りである：
・それらが、いくつかのルールを共有する場合、ルールグループは、別のルールグループで、オーバーラップされる。
・それらが、任意のルールを共有しない場合、ルールグループは、別の  ルールグループから独立している。
・第1のグループ内のルールが、第2のグループのルールに影響する場合、ルールグループは、別のルールグループに影響する。
・第1のグループ内のルールが、第2のグループ内のルールとコンフリクトする場合、ルールグループは、別のルールグループとコンフリクトする。
・第1のグループ内のルールが、第2のグループ内のルールと衝突する場合、ルールグループは、別のルールグループと衝突する。
【００７２】
上記で議論された関連性のカテゴリに加えて、様々の他のカテゴリは、異なる実施例において、可能である。RLMSは、所定の変数、ルール、ルールグループ、および／またはワークフローステップの分類を反映する階層的分類基準を、用いることができる。所定の変数、ルール、ルールグループ、および／またはワークフローステップのための管轄を示す構成構造の関連性(organization structure relationship)も、また、使用可能である。変数、ルール、ルールグループ、およびワークフローステップ間の意味および相互関係を示す意味論のネットワークは、また、確立可能である。真理維持(truth maintenance)のような、異なる伝播エレメント間の論理的従属性は、関連性カテゴリを定義するのに役立つことができる。さらに、AがBとCの両方に依存する一具体例において、この従属は、また、関連性カテゴリとして役立つことが可能である。最後に、時間的関連性および入力／出力関連性は、変数、ルール、ルールグループ、およびワークフローステップ間の関係を伝播する時、使用可能である。幾つかのこれら特徴は、ビジネスプロセスの解析を容易にするために、異なる関係マップを使用して、グラフィカルに、示すことができる。
【００７３】
当業者に公知の他の関連性カテゴリは、異なる実施例において、使用可能である。各関係は、その意味と一致する方法で、識別されかつ扱われる。従来技術において適切な技術を有するプログラマーは、これら関連性の多くを識別しかつ解析するために、コードを書くことができる。残りの関係は、RLMSのユーザにより、明示的に、特定可能である。
【００７４】
ルールセットおよびワークフローステップ間でこれら関連性を伝播するために使用される、コンピュータコードは、所定のビジネスプロセスモデルを通して多くの実行経路が存在する可能性があるという事実により、複雑にされる可能性がある。消費者向け貸し出しコンテキストにおける資産評価に関するさらに複雑なビジネスモデルは、RLMSのモデラーを使用して、図7に示される。図7において、スタートポイントからエンドポイントへ、データは、複数の分岐および決定ポイントを通過し、およびモデルのエンドに達する前に、異なるポリシーの影響を受ける。手動のワークステップが、含まれている。加えて、図7は、データが、既存のレガシー・データベースおよびデータの他の外部ソースから、ビジネスモデルに入っている可能性があることを示す。モデルの複雑さの幾つかは、データがモデルに入り、かつ処理されている異なる位置の全てを原因として発生する。RLTは、これを考慮するために、設計される。
【００７５】
関係が順方向または逆方向に伝播される時、システムは、以下を識別する(a)決定ポイント、(b)結合ポイント、および(c)モデルを介したパラレルな経路。RLTコードは、全ての可能な経路を介して、トレースし、関係に関する各経路の効果を決定し、次に、効果を結合結果に組み合わせる。簡単な具体例として、実行の2つの可能な経路を作成する選択ポイントが存在すると仮定されたい、および変数Xが、一方の経路上に設定されるが、他方には設定されないと仮定されたい。これら2つの実行の経路が一緒になるポイントで、RLTシステムは、Xがそのポイントで、（明確にと対立するものとして）可能性として設定されるという結果を与えるために、Xに関する関係を組み合わせるであろう。
【００７６】
入力が利用できることを保証するために、RLMSの制約-チェッキング部分は、どの変数が定義されるか、およびどれが可能性として定義されるかを決定するために、グラフ内の各ノードに対して、そのノードから逆方向に、すべての可能な経路に従って、移動することができる。それは、これらの定義をノードの入力の要求事項と比較し、かつ問題を報告する。
【００７７】
どの変数が任意のポイントで定義されるかを決定するための論理は、簡単である。“A”は、Aが定義されていることを示し、“(A)”は、Aが可能性として定義されていることを示す、と仮定されたい。RLMS用のいくつかの典型的な論理関係は、以下を含むが、これらに限定されるわけではない：
・Aがノードの前で定義される場合、Aは、ノードの後で定義される。
・Aがノードによって設定される場合、それは、そのノードの後で定義される。
・(A)が、ノードによって設定され、かつAが、ノードの前に、明確に定義されない場合、(A)は、ノードの後で定義される。
・分割-結合セクションがプロセスまたはワークフローステップ内に存在する場合、結合後のAの定義のレベルは、任意の経路に関してAの定義の最も高いレベルである。すなわち（ここで“+”は、ORを表す）；
2007526535.tif 000003
【００７８】
決定-結合セクションが存在する場合、結合後のAの定義レベルは、個々の経路に対して計算された定義レベルのANDであり、ここで、ANDは、以下により定義される：
2007526535.tif 000004
【００７９】
出力が使用されることを保証するために、プログラムは、各ノードから順方向に進み、そのノードからの出力が後で使用されるか否かをチェックする。或る入力に対する応答内に検知可能な、いくつかのエラー条件は、以下を含むが、それらに限定されるわけではない：
・Aが要求され、かつAも(A)も利用可能でない場合、エラーである。
・Aが要求され、かつ(A)のみが利用可能である場合、予想エラーである。
・Aが可能性として要求され、かつ(A)のみが利用可能である場合、予想エラーである。
・Aが可能性として要求され、かつAも(A)も利用可能でない場合、予想エラーである。
【００８０】
よって、エラー条件は、また、出力に対して検知可能である。Aが設定される、または可能性としてノードにより設定可能であり、かつAも(A)も次のノードに対する任意の入力上に現れない場合、システムは、警告を提供するべきである。これは、プログラムまたは図3Bにおいて上記議論された感嘆符インジケータのような、インタフェースにより使用される視覚化キューの１つにより表示されるテキストメッセージであることが可能である。
【００８１】
伝播を実行するための幾つかの方法がある。伝播することは、順方向または逆方向プロセスを使用して、実行可能である。子カテゴリを明らかにするドリルダウンプロセスおよび親カテゴリを明らかにする対応するドリルアッププロセスは、関係を伝播する時、また、使用可能である。入力完全性および出力必要性は、また、関係を伝播する、または結果をフィルタリングするためのベースとしての役割を果たすことができる。加えて、一般的な影響解析は、影響を受けている位置を判別するために、使用可能である。特別のwhat-if解析は、どの様に所定の関連性が影響されるであろうかを決定するために、使用可能である。
【００８２】
一実施例において、関連性の伝播を実行することは、論理的システムを使用する。典型的には、多値論理が、使用される。所定の関係に対して、モデルにおける任意のポイントで、関係は、真(true)、偽(false)、または可能性として真(possibly-true)。述語は、特定のステートメントが変数、ルール、または関係のようなオペランドに応答して行われることを可能とする演算子である。従って、対象となるステートメントが、「請求書は、未払いである」の場合、「請求書」は、オペランドまたは変数であり、「未払いである」は、述語である。このことは、P（オペランド）の形で書かれることができる。Aが特定の変数または他のRLMSエレメントである場合、関係は、P(A)=true、P(A)=false、P(A)=unknown(possibly-true)により、表わされることができる。典型的な論理のセットにおいて、演算AND(“*”)およびOR(“+”)は、以下の関連性に従って、定義される：
2007526535.tif 000005
【００８３】
これらの関係が、RLMSシステムのコンポーネント範囲内で、使用されるが、ビジネスプロセスのモデル化は、典型的には、ビジネス論理の具体的なカテゴリを含む。RLMS用に適切な、いくつかの典型的なビジネス論理カテゴリは、図8に示される。
【００８４】
グラフにおいて、一般的に遭遇する、幾つかの実行タイプがある。図9は、レンタカー会社の運営の部分を記述するビジネスモデルである。図7および9に示されるビジネスモデルは、幾つかのさらに共通の実行タイプを示す。共通のタイプは、シーケンシャル実行、パラレル実行、および相互に排他的な実行を含む。シーケンシャル実行は、コントロールがグラフのノードを通過する時、述語が扱われる方法を記述する。パラレル実行は、コントロールが、分割および結合間の全ての経路に沿って通過する方法を特定する、グラフの分割-結合構成要素に関する。結合は、パラレルな経路が共に戻ってくるグラフ内のポイントであり、およびコントロールは、単一の経路に沿って続く。これは、コントロールが結合ノードを通過し、パラレル実行が、述語が扱われる方法を特定する場合である。相互に排他的な実行は、グラフにおいて決定-結合構成要素を記述する。このタイプの実行は、コントロールが決定および結合ノード間の経路の1つを正確に通過する方法を特定する。RLMSは、実行のこれらタイプを扱うための多くのアプローチを有する。
【００８５】
一実施例において、これらケースを扱うためのRLMSに組み込まれた論理は、以下の通りである：
・シーケンシャル実行：述語Aに対して：
ノードがAを変化させない場合、Aは、ノードの後とノードの前で、同じ値を有する。
ノードがAを真とする場合、ノードの後で、P(A)=trueである。
ノードがAを偽とする場合、ノードの後でP(A)=falseである。
ノードが、Aを可能性として真とし、かつP’(A)が、ノード前の述語の値である場合ノードの後で、P(A)=[P’(A)+unknown]である。
ノードが、Aを可能性として偽とする場合、かつP’(A)がノード前で、述語の値である場合、ノード後で、P(A)=false if P’(A)=false、さもなければP(A)=unknownである。
・パラレル実行：結合ノードの後、P(A)は、パラレルな経路により生成される、Aの全ての値のORである。
・相互に排他的な実行：結合ノードの後、P(A)は、パラレルな経路によって生成されるAの全ての値のANDである。
【００８６】
いくつかの述語をワークフローグラフを通して逆方向に伝播することは、また、望ましい。同じ論理は、述語の逆方向の伝播のために、使用される。逆方向の伝播は、例えば、或るノードでの変数セットが、それが設定された後、使用されるか否かを決定するために、有効である。
【００８７】
ワークフローグラフ内のいくつかのノードは、通常の実行可能なコードを含む。フローグラフは、このコードのために、構成可能であり、および述語は、フローグラフにおいてそれらがワークフローグラフでと同じ方法で扱われる。ルールのセットは、通常のif-thenステートメントのセット同様に、扱われることが可能である。実行時に、関連性を特徴付け、かつ解析するためのコードは、それが代替の可能な経路を処理する必要がないので、より簡単である。システムの各所定の実行の場合、1つの選択肢のみが取られる。
【００８８】
伝播は、また、ループ、分岐、および表現される他の構造の様々のタイプを扱うための基準を含む。これらのタイプのコネクタの具体例は、図9に示される。例えば、“do while”ループのようなループにおいてシステムは、変数の定義および関連性を決定するために、ループを通って、一回、進むことができる。例えば、1つの変数が定義された量より小さく、かつループを通して増加される時、或るタスクが行われるループにおいて、プロセスがループを通して何回循環するかに関係なくその値は、なお定義される。
【００８９】
従って、システムは、各関連性を識別するために、かつワークフローに関する報告を準備するために、ノードからノードへ進む。この報告は、コンフリクトするルール、未定義変数の使用、またはエラーを引き起こす可能性のある他の状況とデバッキングを伴なうアシスト、またはワークフローの他の管理を識別することができる。一実施例において、システムは、変数の各々に対して、これらの変数がフロー全体を通して定義されるか否か、または未定義経路が存在するか否かを決定することができる。さらなる追加として、システムは、特定の変数に対して定義された値が、増加または減少される場合、その値を使用する他の変数における方向（増加または減少）を決定することができる。例えば、システムは、プライム貸し付け金利が減少する時、他の変数の影響は何かを決定することができるであろう。伝播技術のさらに別のアプリケーションにおいて、変数の値は、特定の変数または定数の変化の結果として他の変数の変化を決定することを試みるために、増加させるまたは減少させることが可能である。本質的に、このことは、ワークフローの中で部分的な金融派生商品を決定することに類似している。
【００９０】
RLMS内の様々の変数を相互に関係づけるための定義のセットも、また、使用可能である。例えば、上記議論された不動産金融に関する具体例を使用すると、システムは、ローンが貸し出された時、家の価値が、ローン金額と頭金の合計であること、および頭金が純資産に等しいことを定義することができる。最初のローン金額の決定後の期間に関して、純資産は、評価額マイナス未払いローン金額として、定義可能である。頭金の変化は、純資産の要求事項における変化として、検知されるであろう。この情報は、家の純資産貸付限度額のために、使用可能であろう。
【００９１】
さらに一般的な具体例を使用するために、A+B=C、かつCが定数であることが知られている場合、RLMSは、Aにおける変化を調べることができ、かつ異なる部門で使用される、異なるルールセット内のルールにおいてコンフリクトまたは衝突を識別するために使用可能である、Bにおける相殺する変化が存在することを決定することができる。
【００９２】
本発明の一実施例において説明されるような伝播の概念は、或る値が、ノードからノードへ、真、偽、または可能性として真(unknown)であるかどうかを確立するために、論理的関連性および論理表のセットの使用を含む。加えて、この実施例において、経路は、関連性、強調問題を識別し、かつワークフローの解析を準備するために、多くの経路、好ましくは、全ての利用可能な経路を通って、順方向および逆方向に伝播される。
【００９３】
BPMSにおいて新しいビジネス論理を実施することは、実施される論理を理解するビジネスアナリストと形式的コンピュータ言語で論理を特定する責任を負うプログラマー間の緊密な相互作用を要求するかもしれない。インタフェースルールおよびデータルールの両方を固有的に実行する、適切なルールエンジンが、一般的には、選択され、構成化において直面されるビジネス問題の広範囲にわたって、使いやすさおよび柔軟性を可能とする。加えて、いくつかの実施例において、エンジンの論理的処理は、ビジネスプロセスが、完了される必要がある時、アプリケーションソフトウェアおよび人々を自動的に促す。
【００９４】
しかしながら、既存のサブプロセスが、新しい環境に適合させられている時でさえ、サブプロセスワークを新しいコンテキスト内に作成するために、多くのステップが、必要となる可能性がある。ビジネス情報および論理の前もってモデル化されたシーケンスは、ビジネスアナリストが、予めプログラマーを要求したタスクを実行することを可能にする。本発明のこの観点は、会社の日々のオペレーションに最も直接含まれる関係者によるビジネスモデルの迅速な開発を容易にする。
【００９５】
ビジネスアナリストは、チャンクをライブラリから選択し、かつそのチャンクのグラフィカル表現をビジネスプロセス内にドロップすることができる。RLMSは、この新しい環境にチャンクワークを作成する際に含まれる、複雑なタスクを自動的に実行することができる。RLMSは、必要に応じて、入力および出力コードをそのシーケンスに加えることができ、および必要に応じて、チャンクの内部の変更さえ行う。
【００９６】
この様にチャンクを使用することは、幾つかの重要な利点を提供する：新しいビジネス論理は、従来の方法より、さらに迅速に、かつ低コストで、実施可能である；なぜならば、論理の既存のフラグメントを適合させるために要求される複雑な論理の大部分が、自動化され、多くのヒューマンエラーが、回避可能であり；およびチャンクライブラリの存在は、ユーザが再使用可能なチャンクを書くことに、インセンティブをもたらすからである。スタートシーケンスおよびエンドシーケンスのブロック間に配置されるエレメントにより表わされる典型的なチャンクは、図7に示される。
【００９７】
チャンクが、RLMSのコンポーネントにより再使用可能な情報の一部のまたはシーケンスとして、大まかに説明されるにもかかわらず、典型的な“チャンク”は、また、ワークフローステップのシーケンス、ルールセット、および他のチャンクの組み合わせを含むことが可能である。本発明の一実施例において、すべてのチャンクは、以下の特性を有する：
・シーケンスは、1つの入力および1つの出力を有する。
・シーケンスは、シーケンス内の個々のステップの全て、およびシーケンス内で使用された変数の全てが、可視である（標準のコンポーネントアーキテクチャにおいて隠されない）という点で、透明である。
・RLMSがシーケンスのために有する関係論理情報の全てが、シーケンスと共に記録される。
・シーケンスに関連するRLMSが有する全てのメタ情報は、シーケンスと共に記録される。
【００９８】
チャンクは、新しい環境に挿入可能な、モジュールのような論理のユニットを提供するために使用される。チャンクは、1つ以上の論理的エレメントを含むことができる。チャンクのこの挿入は、簡単であるが、それは、以下の多くのファクタにより、複雑にされる可能性がある：
・新しい環境は、等価な概念に対して、異なる変数の名前を使用することができる。
・新しい環境は、同じ情報に対して、異なる表現を使用することができる。例えば、新しい環境は、“New York”のような州名を、略さずに書くかも知れないが、一方、チャンクは、“NY”のような略語を使用するかも知れない。
・チャンクは、新しいコンテキストにおいて、潜在的であるが明白ではない情報を使用可能である。例えば、チャンクは、タウンシップの名前を要求するかも知れないが、新しい環境は、それを含まなくても良い。新しい環境が、郵便番号を述べる場合、タウンシップの名前は、それから、決定可能である。
【００９９】
本発明の実施例は、これら問題を扱うための方法を含む。チャンクが、新しい環境に置かれる場合、変数に関する情報およびメタ情報は、変数を正しくリンクアップするために、使用される。このことは、特別の条件に基づく様々の異なる方法で、達成可能である。例えば、新しい環境における変数がチャンク内の変数に等価である場合、チャンク内の変数は、名前を変えられる。環境における変数が、チャンク内の変数からの異なる表現を有する場合、変換コードは、チャンクの入力および出力に加えられる。環境の変数における情報は、チャンクへの入力で、変換されかつチャンクの変数に割り当てられる。逆変換および割り当ては、チャンクの出力で、実行される。加えて、チャンクの変数が、環境においていくつかのプロセスを介して情報から導出可能である場合、導出プロセスは、チャンへの入力で、実行され、かつ必要に応じて、プロセスは、チャンクの出力で、逆にされる。
【０１００】
チャンクが、新しい環境に入れられる時、ユーザは、最初のチャンクを有する論理的接続を維持するまたは供給するかどうかの選択を有する。接続が維持される場合、最初のチャンクに対して続いて作成可能である任意の変化は、新しい環境におけるチャンクに対して自動的に伝播する。例えば、公式が、方法を変化させるために、変更された場合、変数は、変更が他のエリアに伝播可能である、ルールの1つのセットに対して、決定される。この従属性は、従って、簡単なテンプレイトとは異なるチャンクを作成する。
【０１０１】
変化が最初のチャンクから伝播される時、システムは、チャンクが、最初に新しい環境に挿入された時に実行されたオペレーションに類似した、マッピング・オペレーションを実行しなければならない場合がある。システムは、チャンクが、最初に挿入された時に、それが当初作成した全ての情報を保つ。当初の挿入オペレーションで扱われ、かつそれらが前に有した同じ情報およびメタ情報を依然として有する任意の変数は、まさにそれらが以前のように扱われる。任意の新しい変数およびその情報またはメタ情報において変化を有した任意の変数は、上記説明されたマッピングプロセスを使用して、再び、処理される。
【０１０２】
チャンクは、それが、再使用可能であるように、永続的に作成されるべきである。XMLスキーマは、これを達成するようにチャンクを表すために、開発可能である。チャンクおよびプロセスが、トップレベルのアクティビティおよびプロセスコンテキストデータを含む、一般に多くを共有するので、同じプロセススキーマは、チャンクを表すために、使用可能である。言い換えると、チャンクは、軽量のプロセスとして、示すことができる：それは、プロセスの要求されるエレメントと属性の全て、およびオプションのエレメントと属性の幾つかを含む。しかしながら、プロセスがパッケージ内に存在し、かつチャンクが、プロセスの一部であるので、パッケージコンテキスト変数、ドメインオブジェクト、およびドメインアクションを含む、いくつかのパッケージのレベル情報は、チャンク内で、使用可能である。この結果、この情報は、チャンクが異なるパッケージにわたって再使用可能であるように、パッケージから切り離される。
【０１０３】
クライアントツールは、プロセスを独立して作成し、かつそれをチャンクとして保存するために、使用可能である、またはチャンクは、既存のプロセスから作成可能である。クライアントツールのために、任意のアクティビティは、それが、簡単なアクティビティまたは複雑なアクティビティの何れであっても、選択可能であり、かつチャンクとして保存可能である。チャンクが、チャンクリポジトリ（図1における論理リポジトリの部分）内に格納されるので、それは、名前を付けられ、かつパッケージ情報と共に提供される。選択されたアクティビティは、アクティビティの中で使用され、かつ新しいプロセス構造に保存される、全てのプロセスコンテキスト変数を識別するために、解析される。さらにまた、パッケージコンテキスト変数、ドメインオブジェクト、およびドメインアクションを含む、全てのパッケージレベル情報は、識別され、かつ新しく作成されたプロセス構造を指す、新しいチャンク定義(chunkdef)構造に保存される。
【０１０４】
チャンクを作成する別の方法は、それらが、単一の入口および単一の出口を有する構造を形成するので、シーケンスアクティビティ内の連続するアクティビティのサブセットを選択することである。このことをサポートするために、クライアントツールは、シーケンスアクティビティの中の連続するアクティビティサブセットを選択することができ、かつそれをチャンクとして保存することができる。シーケンスアクティビティが、別のシーケンスアクティビティの中に、入れ子にされることが可能であり、かつこのような選択は、境界にわたって進むことを可能とされることを留意されたい。
【０１０５】
図10に示されるように、連続するアクティビティa1、a2、およびa3のサブセットを含むチャンクは、それらが異なるシーケンスアクティビティに属する場合でさえ、およびシーケンスs3が、シーケンスs1に入れ子にされているシーケンスs2に入れ子にされる場合でさえ、作成可能である。このようなチャンクを作成するために、最初に、アクティビティa1、a2、およびa3を含む、新しいシーケンスアクティビティが、作成される。システムは、次に、シーケンスアクティビティおよび新しいプロセス構造を指す新しいチャンク定義構造を含む新しいプロセス構造を作成する。
【０１０６】
既存のプロセス内にチャンク構造を示すために、1つのアクティビティを含むチャンクに対して、それが、チャンクリポジトリ内のチャンク対応することを示すラベルは、アクティビティ内に導入可能である。しかしながら、連続するアクティビティのサブセットを含むチャンクに対して、チャンクラベルをアタッチする1つのアクティビティは存在しない。従って、整合性のために、仮想のチャンク構造が、関連されるアクティビティまたはアクティビティを含むために、作成される。1つのアクティビティを含むチャンクに対して、それは、その中にアクティビティを含む、プロセスチャンクエレメントにより、表わされる。連続するアクティビティのサブセットを含むチャンクに対して、それは、アクティビティのサブセットが異なるシーケンスアクティビティを交差することができるので、仮想のプロセスチャンクエレメントにより、表わされ、そのため、それは、ポインターを通して間接的に参照されるのみである。複数の仮想のプロセスチャンクは、1つのシーケンスアクティビティに対して、連続するアクティビティの1つより多いサブセットが存在する可能性があるので、作成可能である。すべての仮想のプロセスチャンクは、それらが、それから作成されるシーケンスアクティビティにアタッチされる。
【０１０７】
XML定義は、既存のプロセス内にチャンク構造を示すためのプロセススキーマに対する拡張子として、使用可能である。各チャンクの中に、既存のプロセス内のコンテキスト変数とチャンク内の使用されたコンテキスト変数との間の変数結合インタフェースが、含まれる。このような情報は、必ずしも必要ではないが、チャンク作成または再使用を取り消すことが、望まれる場合、それは、含まれる。
【０１０８】
従って、チャンクは、繰り返して使用可能である共通に使用される論理の一部を表す。1つの有利な点は、プロセスを作成および／または拡張するための効率的な方法を提供する能力である。チャンクを再使用するために、チャンク内のコンテキスト変数は、チャンクが、プロセスとスムーズに適合するように、現在のプロセス内の対応する変数にマッピングされる。アクティビティが必要とされるプロセスのあらゆるところにおいて、そこは、チャンクリポジトリ内の既存のチャンクで、十分満たすことが可能である。それは、また、実行時間に、既存のプロセスに対して接続を確立するプロセスコールで十分満たすことが可能である。チャンクは両方とも共通のアクティビティの再使用を可能にするという点で、サブプロセスに似ているが、違いは、サブプロセスに対して、変数マッピングは、実行時間に、扱われ、一方、チャンクに対して、変数マッピングは、モデル化時に行われることである。従って、チャンクの再使用は、マクロな置換およびサブプロセスの再使用は、従来のプログラミング言語における、手続き呼び出しに似ている。
【０１０９】
各チャンク構造は、チャンク内で使用された各コンテキスト変数を現在のプロセスコンテキスト内の定義されたコンテキスト変数にマッピングする結合エレメントを含む。チャンク構造が、作成される時、サーバーサイドは、新しいチャンクが、現在のプロセスと適合するように、一連の変数置換を行う。チャンクの再使用のために、プロセスチャンクエレメントのみが、作成される。仮想のプロセスチャンクは、既存のプロセスでチャンク自体を記録することの方法として、シーケンスアクティビティのアクティビティのサブセットのためのチャンクを作成することの副産物である。一旦、チャンクが、チャンクリポジトリ内に、作成かつ保存されると、それは、プロセスチャンクとして、別のプロセス内で、再使用可能である。
【０１１０】
チャンクは、アクティビティの意味のあるグルーピングを含むので、それは、どのチャンクまたはアクティビティが、どの他のチャンクまたはアクティビティの前にあるかを記述するチャンク間の時間的制約を含むチャンク間の様々の関連性、およびどの変数が、どのアクティビティおよびチャンク内に含まれるか、他のアクティビティおよびチャンク内に含まれることが可能かを示すメンバーシップ関連性を調べるために、有効である。
【０１１１】
チャンクが、簡単なまたは複雑なアクティビティを含むので、それは、また、別のアクティビティまたはチャンクを用いて時間的制約を特定するために、使用可能である。全ての参照されるアクティビティが、すでに、プロセス内に存在し、かつ任意の時間的制約を特定するために、直接使用可能であるので、一方、仮想のチャンクは、時間的制約可能とされるべきではない。この結果、チャンクノードは、時間的制約を特定するために、およびプロセスモデルに対してそれらを検査するために、ユーザに公開される。
【０１１２】
チャンクおよび仮想のチャンクは、メンバーシップ概観に示されることが可能である。何故ならば、それらは、構成階層の部分であり、およびそれが、込み合ったウインドウ内で、レベルごとにドリルダウンされない限り、プロセスのワークフロー概観に、容易に表示されることが可能でないからである。単一のプロセスに対して、全てのアクティビティおよびチャンクは、ツリー構造で、示されることが可能である。図11は、仮想のチャンクと共に、シーケンスアクティビティのメンバーシップ概観を示す。
【０１１３】
チャンクが、連続して作成される時、リポジトリ内に、多くのチャンクが存在する。1つの望ましいタスクは、どのチャンクが、他のどのチャンク内で使用されるかを決定するために、異なるチャンク間のメンバーシップ関連性を検討することである。このような関連性は、複数の階層がしばしば存在する；対象の大部分が、アクティビティではなくチャンクに関してである；および或るチャンクは、他のチャンク内で、繰り返して使用可能であるという点で、プロセスに対するそれとは異なる。その結果、グラフは、メンバーシップ関連性に対して、チャンクリポジトリ内の異なるチャンク間で実施される。
【０１１４】
本明細書で説明されるこの方法およびシステムは、汎用コンピュータ上のソフトウェア、サーバー、またはバスを使用して、それらと接続されている他のプロセッサ内で、適切な磁気的、光学的またはコンピュータまたはサーバーの一部である他の記憶を用いて実行可能である。プロセスは、また、アプリケーション指定集積回路のような、ハードウェアおよびソフトウェアの組み合わせにおいて、全体的にあるいは部分的に実行可能である。ソフトウェアは、1つ以上のコンピュータ、サーバー、または他の適切なデバイス内に、格納可能であり、かつ磁気または光学ディスクのような取り外し可能な記憶媒体上にもまた保存可能である。
【０１１５】
一実施例において、本発明は、適切なアダプタを通して、様々の外部のリポジトリおよびアプリケーションに接続することができる。適切なアダプタは、以下の標準のインタフェースをサポートするために、提供可能である：Javaクラス、EJB(Enterprise Java Beans)、ウェブサービス(WSDL、UDDI & SOAP)、JDBC(Java Database Connectivity)、JMS(Java Messaging Service)、およびそれらの組み合わせ。他の適切な標準のインタフェースは、当業者に公知であるように、使用可能である。
【０１１６】
請求された本発明のさまざまな観点が、記載されたシステム、本明細書に開示されたRLMSの方法およびプロセスの一部に向けられていることは、理解されるべきである。さらに、本明細書に使われる用語および式は、説明の用語とし使用され、制限として使用されるものではなく、また、このような用語および式の使用において、図と共に記載された特徴またはそれの一部の任意の等価物を除外する意図はないが、さまざまな変更が、請求される本発明の範囲内で可能であることは、理解される。よって、特許権により保護されることが望まれるものは、すべての等価物を含む添付の請求項において定義されかつ区別される発明である。
【図面の簡単な説明】
【０１１７】
【図１】本発明の例示の実施例による、RLMSの線図である。
【図２】本発明の例示の実施例による、モデラーおよび論理エンジン間の関連性を示す線図的ブロック図である。
【図３Ａ】本発明の例示の実施例による、RLMSのモデラーコンポーネントの線図である。
【図３Ｂ】本発明の例示の実施例による、RLMSのモデラーコンポーネントの線図である
【図４Ａ】本発明の例示の実施例による、ルール情報のグラフィックユーザインタフェース表現である。
【図４Ｂ】本発明の例示の実施例による、ルール情報のグラフィックユーザインタフェース表現である。
【図５】本発明の例示の実施例による、典型的なルール管理階層を示す線図である。
【図６】本発明の例示の実施例による、ビジネスモデルの一部を示す関係マップ線図である。
【図７】本発明の例示の実施例を使用して作成された資産評価ビジネスモデルの線図である。
【図８】本発明の実施例の使用に適している、様々の典型的なビジネス論理カテゴリを示す表である。
【図９】本発明の例示の実施例による、様々のアクティビティおよびサブプロセスを示すレンタカービジネスプロセスの線図である。
【図１０】本発明の例示の実施例による、連続するアクティビティのシーケンスを含む典型的なチャンクを示すブロック線図である。
【図１１】本発明の例示の実施例による、仮想のチャンク、シーケンス、およびプロセス間の関連性を示すツリー・グラフである。
【符号の説明】
【０１１８】
10   RLMシステム
12  モデラー
13a  メタデータモデラー
13b  プロセスモデラー
13c  ルールモデラー
13d  関連性モデラー
14  論理リポジトリ
16  論理サーバー
18  アナライザ
19  トランスレータ・ディプロイヤー
20  論理エンジン
【図１】
2007526535.tif 000006
【図２】
2007526535.tif 000007
【図３Ａ】
2007526535.tif 000008
【図３Ｂ】
2007526535.tif 000009
【図４Ａ】
2007526535.tif 000010
【図４Ｂ】
2007526535.tif 000011
【図５】
2007526535.tif 000012
【図６】
2007526535.tif 000013
【図７】
2007526535.tif 000014
【図８】
2007526535.tif 000015
【図９】
2007526535.tif 000016
【図１０】
2007526535.tif 000017
【図１１】
2007526535.tif 000018