ルール・エンジンに対する要件

複雑なビジネス・ルールの表現と伝達

ビジネス・ソフトウェア・システムでは、保険請求の処理、荷物配送のための経路選定など、複雑で反復的なタスクを扱うのが一般的であるため、これらのタスクを遂行するための特定のビジネス・ロジックのコードがシステムには実装されています。しかし、こうしたシステムは変更に対して柔軟でなければならないため、開発を単純化して変更を迅速にデプロイできるように、手続き型のコードとは独立してビジネス・ルールを実行するルール・エンジンが作成されています。これらのルール・エンジンを使用すれば、基礎となるコードを変更せずにルールを変更することができます。この記事ではビジネス・ルールに関して、要件を表現し、モデル化して、テストを行うことを目的としたツールと手法について説明します。

2012年 11月 06日 ― アクセシビリティーに対する要件を満たすために、表 3456 の情報の書式を変更しました。

Benjamin A. Lieberman, Ph.D., Principal Architect, BioLogic Software Consulting, LLC

Ben LiebermanBenjamin A. Lieberman は BioLogic Software Consulting のプリンシパル・アーキテクトであり、要件分析、ソフトウェア分析と設計、構成管理、開発プロセス改善など、ソフトウェア開発についての多様なトピックに関して専門的コンサルティングとトレーニングを行っています。彼はオブジェクト指向アーキテクチャーと分散コンピューティングが専門です。



2012年 12月 13日

ソフトウェア開発で最も難しい部分は、一般に信じられているのとは反対で、システムに関する実際のコーディングではなく、曖昧で不完全な上に矛盾があることの多いビジネス要件を表現して、ルール・エンジンに変換することです。要件に関するコミュニケーションの中で早い段階に誤りが紛れ込んでいた場合には、修正コストが非常に高くつくシステムの欠陥を招くこととなり、パッチを開発する必要が生じたり、保守コストが増大したりすることにつながります。そうした誤りが紛れ込む可能性が高いのは、複雑なビジネス・ルールを表現する作業、そしてそれをコーディングする作業においてです。

ビジネス・ルールはさまざまな方法で定義されますが、一般的にはビジネス・プロセスにおいて判断が行われる部分とみなすのが最も適切です。ビジネス・ルールは if-then-else 型のロジックで表現されます。if-then-else 型のロジックでは、if ブロックで指定した特定のビジネス条件が満たされた場合には、then ブロックで指定した特定のアクションが実行され、それ以外の場合 (if ブロックで指定した条件が満たされなかった場合) には else ブロックで指定した何らかのアクションが実行されます。例えば、ある会社が自社のサービスを販促用の価格で提供する場合を考えてください。この販促は限られた期間、特定の製品またはサービスに適用されます。バックエンドの処理システムは、新規顧客にこの販促価格を正しく適用できなければならないのみならず、適切な時点で販促を終了できなければなりません。こうしたシステムの動作はビジネス・ルールに従って行われます。

しかし、ビジネス・ルールをソフトウェア・プログラムの中にコーディングするのは、簡単ではありません。ほとんどのプログラミング言語は、「個別にルールが突き合わされて、一連の条件の結果として起動される」という概念を直接的にはサポートしていないからです。その一方で、現在のビジネス・プロセスは大多数がルール駆動となっています (以下を参照)。

表 1. ルール駆動のビジネス・プロセスの例
ビジネス分野
金融に関する決定融資の組成
保険引受業務損害保険
スケジュール設定や経路選定荷物の配送
製品提供準備携帯電話サービス
在庫管理カンバン方式のサプライチェーン
料金計算航空、船舶、列車、バスによる輸送

この記事では、複雑なビジネス・ルールを表現してモデル化するための分析手法について説明します。一例として、水の汚染検査のための架空のルールを使用します。水の汚染検査に関しては、飲料水の不純物濃度を判断するために EPA (U.S. Environmental Protection Agency: 米国環境保護庁) によって定められた詳細な法規制が (米国には) ありますが、ここでは地域の水道水の水質を監視する政府機関が検査を行うものとします。この例を通じ、単純なルールを複雑な構造と組み合わせて堅牢なビジネス・プロセスを表現する方法を説明します。

ビジネス・ルールの要件を表現する

ルールは、システムの動作を記述するのではなくビジネス・ロジックを記述する、という点でユース・ケースとは異なる振る舞いをします。典型的なユース・ケースでは、アクティビティーのフローは特定のアクターが具体的な目標 (例えば、「水質サンプルの管理」など) の実行に向けてシステムとやり取りすることによって行われます。ルールはそれとは対照的に、他のシステム処理 (例えば、未払い分の支払いをするなど) の結果、そのルールに対する条件が正確に満たされた場合にのみ実行されます。そのため、ビジネス・ルールを表現および検証するための手法は、ユース・ケースを作成するための手法とはまったく異なります。

ルールを定義する

ルールは通常、条件のステートメントとアクションのステートメントのペアが明確に定義された形で構成されています。一般的なベスト・プラクティスとしては、あるルールを実行するために満たすべき全ての条件が含まれた 1 つのセットとして、ルールの条件を作成するようにします。ルール・エンジンによっては、1 つの条件の中で or 構成体を使用できるものもありますが、実際にはそうした構成体によってルールが理解しにくくなり、ルールのテストもしにくくなります。条件を or でつなげたい場合には、条件が満たされる場合が数多くあり得る 1 つの複雑なルールを作成するよりも、or の対象となるそれぞれの状況をカバーするルールを複数作成した方が適切です。従って以下の例では、条件を組み合わせる場合のデフォルトは常に and です (表 2 を参照)。また、ルールを作成する場合には、可能な限り独立して実行されるようにルールを作成し、規定されたアクションを実行するために必要なルールは 1 つのみとなるようにします。そのようにルールを作成することで、各ルールを別々に独立してテストしたり検証したりすることができ、その後で、それらのルールを組み合わせて複雑な動作にすることができます。

表 2. ルールのカテゴリー
カテゴリー説明
検証ルールデータの検証、一貫性のチェック
計算ルール入力データを使用することによる、値の計算
判断ルールビジネス・プロセスのパスの選択
生成ルール新しいデータ・オブジェクトの作成

個々のルール

個々のルールはアトミックなレベルで定義されます。つまり、さまざまな条件の一意の組み合わせを定義することで、ルールの実行をトリガーする条件の集合に対して、ただ 1 つのルールのみが実行されるようにします。単純なルールの定義を表 3 に示します。このルールでは、定められた水質基準を満たすかどうかという観点で水のサンプルを評価します。この場合のアクションは単純に何らかの警告を生成することですが、もっと複雑なアクション (召喚状の発行など) をルールのアクションとして実行することもできます。このルールの定義は、他のルールとは独立して検証および理解できることに注意してください。つまりこのルールの前、または後に実行された可能性のあるルールについて、何も理解する必要がないのです。

表 3 のルールは以下のとおりです。

  • ルール名: Evaluate Water Sample — Benzine (ベンジンに関して、水サンプルを評価する)
  • ルール・グループ: evaluate-water-sample
表 3. 単一ルールの定義
条件アクションコメント
無効ではない水サンプル警告を生成する: ベンジンの基準値を超過していますサンプル中のベンジンの最大許容量は 0.005 mg/L です。
ベンジン濃度 > 0.005 mg/L

場合によると、1 つの条件が存在することによって、別の条件が変更される場合があります。例えば、新たな研究によって、カルボフラン (許容濃度は 0.04 mg/L) が含まれる場合にはベンジンの許容濃度 (通常は 0.005 mg/L) を 50 パーセント引き下げる必要がある (新しい許容濃度 = 0.0025 mg/L) ことが示された場合を考えてみてください。このルールは以下のように表現することができます。

表 4 のルールは以下のとおりです。

  • ルール名: Evaluate Water Sample — Benzine (reduced standard) (ベンジンに関して、水サンプルを評価する (許容濃度が引き下げられた基準の場合))
  • ルール・グループ: evaluate-water-sample
表 4. 単一ルールの定義の変更版
条件アクションコメント
無効ではない水サンプル警告を生成する: ベンジンの基準値を超過しています新しい研究によって、カルボフランが含まれる場合にはベンジンの許容レベルを 50 パーセント引き下げなければならないことが示されています。
ベンジン濃度 > 0.0025 mg/L警告を生成する: ベンジンの基準値は引き下げられています (0.0025 mg/L)
カルボフラン濃度 > 0 mg/L

条件が複数あるだけではなく、アクションも複数あることに注意してください。この 2 つのルールを or 条件の組み合わせで作成することもできますが、上で述べたように、そうすると各ルールを他のルールとは独立して理解したり、テストしたりするのが複雑な作業になります。このことから、アトミックな単位にルールを分離することがベスト・プラクティスなのです。

一部のルールは「判定表」によって最も適切に表現することができます。判定表は一連の条件を共有する多くのルールを要約するための手段にすぎず、アクションはこれらの条件の値の変化に基づいて実行されます。これは金融機関によくあるケースであり、融資の申請を承諾するかどうかの判断は、申請者の信用情報、雇用状況、所有する資産、等々に基づいて下されます。

表 5 のルールは以下のとおりです。

  • ルール名: Determine Loan Eligibility (融資適格性の判断)
  • 説明: 融資審査者は、この表を使用して融資申請者の適格性を判断します。
表 5. 表によるルールの定義
申請額収入負債額アクション
<10,000>45,000<10,0005 パーセントの金利で融資を承認する
<20,000 かつ >10,001>65,000<10,0004.5 パーセントの金利で融資を承認する
<30,000 かつ >20,001>75,000<10,0003 パーセントの金利で融資を承認する
...

上記の各行は別々のルールを表しています。商用およびオープンソースのルール・エンジンの大部分は、表形式でルールを表現することができます。最後は「ツリー」ルールと呼ばれるルール・タイプです。この方法も、前述の例と同様、関連する複数のルールを表現するための簡略化された方法にすぎませんが、この形式を使用すると、ある特定の結論に至るまでに使用された決定木を完全に視覚化することができます。図 1 に示すように、顧客はその顧客に対する優遇レベルや、地理的な場所、顧客が購入する製品スイートに応じて、値引きを受けることができます。

図 1. 決定木
決定木

ルール・グループ

複数のルールが同じ入力データに対して突き合わせを行ったり、同様の一連のアクション (例えば、ルール検証) を実行していたりするなど、密接に複数のルールが関連している場合があります。こうした状況では大抵、関連する複数のルールをグループ化することで、突き合わせを検討するルールを少なく抑えると有効です。こうしたルールのグループ化は、あくまでもそれらを見る人間のために行うものがほとんどであり、ルールの突き合わせの最適化に関しては、ルール・エンジンの強力な最適化アルゴリズムを使えば十分に事足ります。ただし、特定のデータ・セットが処理の初期段階で失敗する場合、それ以降のルール処理ではそのデータ・セットを対象とせず、その入力を無効にしてしまうと非常に大きなメリットがあります。このようにしてデータ・セットを排除すると、それ以降のルールの条件を単純化することができ、エラーが発生する可能性を抑えることができます。

「ルール・グループ」を使用すると、明確に定義されたカテゴリーによってルール・セットを整理し、ルール・フローを作成することができます。図 2 に示すように、ルール・フローは分岐点や結合点を含むことができるため、ルールの実行を非常に高度に管理することができます。ルール・グループとルール・フローを使用することで、ルール・エンジン全体としての動作を明確にモデル化することができ、またルールを個別に検証することができます。

図 2. ルール・グループのモデル
ルール・グループのモデル

ルール・セットがさらに複雑になるにつれ、ビジネスのサブジェクト・マター・エキスパート (SME) がルールとルール・グループとのすべてのやり取りを完全に理解すること (そして検証すること) は次第に困難になります。これらのやり取りや依存関係を視覚的にモデル化すると、開発チーム、テスト・チーム、ビジネス利害関係者の間でコミュニケーションをする上での強力なメカニズムとなります。こうした状況における最も有効なモデルの形態は、ルール・グループに関する構造モデル、グループ間の依存関係マップ、ルール・エンジンによって実行される実行フローの 3 つです。

図 2 に示すように、私は UML (Unified Modeling Language) の «stereotype» 拡張メカニズムを使用して UML アクティビティー図を機能強化し、こうした情報を表現するための視覚モデルを実現しました。«rule-group» ステレオタイプはルール・グループを表し、«rule» は名前が指定されたルールを表します。図 3 では 1 つのルールの定義に対する «condition»«action» のペアを 2 つの方法で表しています。

図 3. ルールの UML モデル
ルールの UML モデル

この方法はルールを文章ではなく視覚的に表現するため、ビジネス・ユーザーと直接作業を行う場合に有効です。この 2 つのモデルのビューは、ルール・グループをモデル化する図と組み合わせることにより、ある 1 つのビジネス・ルール・セットで具体化されるルールの全体像を示すことができます。


要件をルール・エンジンに変換する

必ずしも上記の方法で要件を定義する必要はありませんが、この方法を使用すると、具体的な要件に直接遡ることが可能な、単純化された実装を簡単に行うことができます。表 678 に、JBoss Rules (Drools) というオープンソースのルール・エンジンを使用してコーディングされた 3 つのルール例として、Validate Water Sample (水サンプルを検証する) と、Evaluate Water Sample — Exposure Limit Exceeded (糞便系大腸菌群に関して、水サンプルを評価する)、そして Evaluate Water Sample — Fecal Coliforms (暴露限度の超過に関して、水サンプルを評価する) を示します。

表 6 のルールは以下のとおりです。

  • ルール名: Validate Water Sample (水サンプルを検証する)
  • ルール・グループ: WaterSample
  • 優先度 (salience): 100
表 6. 水サンプルを検証するためのルールの定義の例
条件アクションコメント
無効な水サンプル警告を生成する: 無効なサンプルですこのサンプルは無効であるとされたものです。

表 7 のルールは以下のとおりです。

  • ルール名: Evaluate Water Sample — Fecal coliforms (糞便系大腸菌群に関して、水サンプルを評価する)
  • ルール・グループ: WaterSample
  • 優先度 (salience): 50
表 7. 糞便系大腸菌群に関して水サンプルを評価するためのルールの定義の例
条件アクションコメント
有効な水サンプル警告を生成する: 糞便系大腸菌群が検出されました糞便系大腸菌群というバクテリアがサンプル中に検出された場合には、汚染に関する警告が作成されます。
糞便系大腸菌群 > 0

表 8 のルールは以下のとおりです。

  • ルール名: Evaluate Water Sample — Exposure Limit Exceeded (暴露限度の超過に関して、水サンプルを評価する)
  • ルール・グループ: WaterSample
  • 優先度 (salience): 50
表 8. 暴露限度の超過に関して、水サンプルを評価するためのルールの定義の例
条件アクションコメント
有効な水サンプル警告を生成する: 暴露限度を超過しています収集されたサンプル・データ中に暴露限度を超過しているサンプルが含まれています。
汚染物質濃度 > 暴露限度

図 4 は、この 3 つのルールを Drools で実装した場合を示しています。

図 4. 水サンプルに対する 3 つのルールを Drools で実装する
水サンプルに対する 3 つのルールを Drools で実装する

ルール・エンジンの実装とルール間のやり取りによっては、ルールの実行に優先順位をつけなければならない場合がよくあります。そのための方法は 2 つあり、1 つ目の方法は、先ほど説明したルール・グループとルール実行フローによって優先順位をつける方法です。2 つ目の方法は、個々のルール・レベルで優先順位をつける方法で、ルール・セット内の特定のルールを他のルールよりも優先させます。(Drools エンジンでは、この優先度のことを salience レベルと呼びます)。

場合によると、他の処理ルールを実行する前に検証ルールが適用される場合など、複数のルールが有効な選択として実行される (つまりルールの条件が満たされた) としても、あるルールを実行する前に別のルールを実行しなければならない場合があります。こうした場合には、ルールの条件セットが重複している可能性があったり、一方のルールが最初に実行されない限り、もう一方のルールを実行するべきではなかったりします。

上記の例では、評価ルールと検証ルールは同じルール・グループ (WaterSample) に属していますが、指定される salience レベルに従って、評価ルールは検証ルールの後に実行されます。水サンプルが検証をパスしなかったとすると、そのサンプルのデータは作業メモリーから削除され、それ以降のルールとの突き合わせには使用できなくなります。

テストと検証

ルール・エンジンにビジネス・ルールを実装する作業を終えると、最終的なステップとして、コーディングされたルールが要件を満たすかどうかを確認します。多くのルール・エンジンは、テスト用ツールと、評価用ツールを提供していますが、特別なツールを作成しなければならない場合があります。図 5 に示すように、Drools エンジンに用意されているテスト・ツールを補完するために作成したツールを使用すると、テスト・チームはその場で検証データを選択し、検証結果と実行されたルールの両方を即座に調べることができます。

図 5. ルールの評価とテスト
ルールの評価とテスト

この図からわかるように、ルールの定義、表現、実装をアトミックな単位で行うと、そのルールが正しいかどうかを非常に容易にテストすることができます。さらに自動ツールを使用すると、繰り返しテストを行うこともでき、新しいルールがルール・セットに追加された場合にも、それまでのルールが破られないかどうかを確認することができます。また、この例のツールには、ルール・エンジンの作業状態を維持する機能が含まれていることにも注意してください。これは基本的に、ステートフルなオンザフライのテストができるということであり、前の処理によるデータがルール・エンジンの中にないとルール・セットの実行をテストできないような場合に役立ちます。


まとめ

ソフトウェア・システムの中にビジネス・ルールをコードとして組み込むことは、必要な作業ではあるものの、極めて順調に行われた場合でも困難な作業です。曖昧であったり、不完全であったり、あるいは誤解を招いたりするような要件を提示すると、要件に従った正確な開発をするには問題が複雑になり、大きな費用が発生する誤りにつながってしまいます。視覚的な表現と文章による表現とを組み合わせてビジネス・ルールを記述すると、より正確かつ効果的な方法でビジネス・ルールを表現することができます。このことは、ルール駆動のエンジンを使用して実装する場合には特に言えることです。この記事で説明した手法を使用することで、複雑なビジネス処理ルールを伝達するための強力な分析フレームワークをビジネス・アナリストに提供することができます。

参考文献

学ぶために

製品や技術を入手するために

  • 皆さんの次のオープンソース開発プロジェクトを IBM ソフトウェアの試用版を使用して革新してください。ダウンロード、あるいは DVD で入手することができます。
  • IBM 製品の評価版をダウンロードするか、あるいは IBMソフトウェア試用版で、DB2、Lotus、Rational、Tivoli、WebSphere などが提供するアプリケーション開発ツールやミドルウェア製品を試してみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source
ArticleID=851414
ArticleTitle=ルール・エンジンに対する要件
publish-date=12132012