‘BRMS一般’ カテゴリーのアーカイブ

ルールエンジンのアルゴリズム(2)

2012年2月1日 水曜日

(前回の続き)
もっとも、入力データのチェックなどは、ルールのパターンマッチの側面こそ利用していますが、一方でルールの実行中に入力データが変わっていくわけではないので、先に挙げたルールの実行サイクルを何度も回して結果を出すという特徴的なところはあまり利用していないとも言えます。

では、よりルールエンジンの動きの特徴が表れている例というとどんな例があげられるでしょうか。思うに、たとえば質問に対して答えていき最後に結果を出すといったコンサルティングというか、レコメンドというか…といったシステムの例はそのひとつではないでしょうか。

この動きをルールエンジンの実行サイクルに合わせて見てみましょう。まずは、

1.システムは利用者に対して最初の質問を投げます。
2.利用者は質問に対する回答を行いその回答はデータとして(短期)記憶領域に書かれます。
3.システムはこの回答に合ったルールを選び出し、次の質問を利用者に投げます。
4.利用者はさらに回答を行い結果は記憶領域に書かれます。
5.システムは今までに出した質問の結果と今回の質問の結果を合わせて条件に合うルールを選び出し、さらに質問を繰り返していきます…。
6.そして最後に十分に絞り込まれた結果が得られそれ以上尋ねる質問がなくなった(マッチするルールがなくなった)ところで利用者に結果を返します。

これだけではあまりに抽象的なので、もう少しかみくだいた例として、たとえば、料理に合うワインをおすすめするといった場合を考えてみましょう(この具体的な実装は、Clipsというツールの例としてあげられています)。

まず質問としては、

1.料理は肉、魚、鳥料理のうちのどれですか?
2.料理にはソースがかかっていますか?
3.ソースは、スパイシー、甘口、クリーム、トマトのうちのどれですか?
4.料理の味は、繊細、ふつう、強めのうちのどれですか?
5.ワインとしてお好きなのは赤と白とどちらですか?
……

といった感じ。これら質問をルールとして保持し、ルールの実行部分で質問の回答を記憶領域に書くようにしておきます。
さて、まず最初に1.の質問のルールが動き、質問に対して「肉」という回答をすると、(短期)記憶領域に

・「料理は肉」

と書かれます。次に2.の質問に、「ソースがかかっていない」という回答をすると、記憶領域に

・「料理にはソースがかかっていない」

という事実が追加されます。
次に3.の質問。これは本来、料理にソースがかかっていなければ意味のない質問です。したがって、3.の質問を行うルールの条件部分には「料理にはソースがかかっている」という前提条件を加えておきます。そうすると、現在の記憶領域の状態

・「料理は肉」
・「料理にはソースがかかっていない」

に3.の質問ルールはマッチしないので、ルールは実行されません。一方、2.でソースがかかっていると回答すると自然に3.のルールもマッチしてきます。

このように、質問を行う各ルールの前提条件をきちんと書いておけば、意味のない質問をすることもなく、効率的に結果を求めることができましょう。

さて、実は上の議論では少々ゴマカシがあるのですが、お気づきでしょうか。上の議論では、1.から順に実行することが前提となっているような書き方になっていますが、ルールエンジンの一般的な動きでは上から順に動くという保証はありません。順番に関して何も指定していない(*1)と、上記のルールのうち1.2.4.5.のどのルールが最初に動くかの保証は何もありません。
まあ、論理的には最初に1.2.4.5.のどの質問から聞いても結果は同じなのですが、ワインの好みに対して聞く4.5.の順番はともかく、1.2.は気持ちとしては、1.の次に2.を聞くのがふつうかと。こんなときには、
A. 2.の前提条件に料理の種類が決まっている条件。
具体的には、「料理は○○」という事実があるという条件を加える。
B. ルールに優先度をつけて、1.が2.よりも先に動くようにする。
というような解決方法があります。まあ、ルールの一般的なお作法としては、A.のほうが推奨ですが、ケースバイケースで一概にどちらがいいというわけでもありません。
さらに質問のかたまり間で順番をつけたいという場合に、たとえば料理に関する質問のルール、ワインの好みに関する質問のルールといったかたまりの間での順番をつけたいというときには、ルールのかたまりとその順番を定義するという仕組みがたいていのルールエンジンに標準的に装備されています(Droolsでは、アジェンダグループとか、ルールフローとか)。

(*1) 実は、ルールが動く順番は全くのランダムというわけではなく、たいていの場合何らかの規則にしたがって、実行されるルールが選ばれます。この規則を競合解消戦略といって、考え方としては、「最新の情報を優先する」、「一般的な条件のルールと、より特殊な条件のルールと両方にマッチした場合は、特殊な条件のルールを優先する」などといった基準があります。

ルールエンジンのアルゴリズム

2012年1月21日 土曜日

 久しぶりの更新になってしまいましたが、ここのところルールベースエンジン関連の話題が次々と出てきて・・・Droolsはいつのまにか5.3のFinalが出ていて、5.4のβまで出ているし、CorticonはProgressに買収されるし・・・ちなみに最近またDroolsの新しい本が出たようです。

 それはそうと、おかげさまで最近私もルールエンジンの仕事がだいぶ増えてきてうれしい限り。ただ、まだまだ人口に膾炙するといったところではないようで、ルールエンジンの動き等に関連していろいろ質問されることが多々あります。
たとえば
・ルールエンジンのプログラムって、if-Thenのルールが並んでいるけれども、上から順にやっていくの??
・(上記に関連して) 通常のプログラムの(単体)テストだと全部のパスを通るようにテストするけれども、 ルールの場合のテストでは、全部のパスを通す…ってどのように考えればよい?
・ルールエンジンのメモリ使用量は何に依存してきまるのでしょうか? ルール数?
・同じようにルールエンジンの処理速度は何できまる?
などなど。

 私もこのような質問をされるようになって、あらためてネットなどを調べてもみるのですが、ルールエンジンの動きとかアルゴリズムとか結構情報が少なくて、ルールエンジンの代表的なアルゴリズムであるはずのReteアルゴリズムの日本語の解説などは、ちょっと探してみたところネット上にはほとんど皆無状態でした。
 というわけで、これからぼちぼちルールエンジンの動きやアルゴリズムなど気が付いたときに書いていきたいと思います。
 さて、最初というわけでルールエンジンの動きから。以前、本宅の記事(プロダクションシステム(ルールベースシステム)とは)にルールエンジンの動きを書きましたが、もともとはこのルールエンジン、人工知能や認知心理学の研究をルーツとするもので
人間が長期記憶にあたる「ルール」を使って、認識した外界の状況(短期記憶に保持される)に合わせて判断を行うという行動がモデルとなっています。
 これをルールエンジンの動きとして翻訳してみると、
1.データの集合に対して、たくさんあるルールの条件部分をひとつひとつデータとマッチングさせて、マッチしたルールとデータのカップルを列挙しておく。
2.カップルの中からひとつを選んで実行する。
3.実行によってデータが書き換えられる場合もあるので、再度1.のカップリングを行う。
4.1~3を繰り返してマッチするルールがなくなったところで実行が終了する。
となります。
 この動きをみるとわかるように、ルールエンジンでは、すべてのデータに対して、すべてのルールの条件部のマッチングを試し、そののちにルールを実行します。したがってルールの実行順序は必ずしも上から順などといったことではなくて(実はそれなりの実行順の規則はあるのですが)、実行順に過度に依存するようなルールの書き方はむしろお作法に反するものという見方が強いです。
 特に最近ルールエンジンがよく使われている入力データのチェックなどは、(チェックそのものだけでいえば)別に順番などはどうでもよく、条件に合うか合わないかで正しくエラーが出ればそれでよいのであって、上記のようなルールエンジンの動きはこの「チェック」という作業に対して非常になじむもののように思います。



ルールエンジンとシステム内製

2011年10月10日 月曜日

 先週紹介した日経コンピュータの記事には、クラウドとルールエンジンの組み合わせを使った開発でのメリットとして8つあげられていました。このうちの8番目「内製しやすい」というのが今日のテーマ。
 確かにビジネスロジックをルールエンジンを用いて実装すると、ロジックのシステム的な制御部分を隠蔽し、本質的な部分を浮き彫りにさせる効果があります。今回あがっている保険商品の整合性チェックとか保険料の試算などは、ロジック自身はそれほど複雑でないので、ビジネスロジックをたとえば表形式(デシジョンテーブル)でまとめれば、それがほぼそのまま実際に動きます。DroolsではDSL(ドメイン記述言語)もあるので、DSLをうまく設計すれば「日本語で仕様を書けばそれがそのまま動く」といった世界を実現することも夢ではないかもしれません。たとえば

 保険料は、基本料率 * ○○割増 * 保険金額である。
  ただし
 …の場合は○○割増は1.03
 …の場合は○○割増は1.05

とかいったような。こんな感じで書いた仕様がそのまま動くとなると、業務に携わる人が直接プログラムを保守するということも現実解として十分考えられるようになってきそうです。

 今のところ日本ではBRMS(ビジネスルール管理システム)を使って、現場で業務に携わる人が直接ルールを直すという事例はまだ聞いたことはありません。ただ、ごく一般的な日本の事務現場のExcelシート、マクロの開発力(!!)などを考えると、BRMSでの現場での修正開発も案外いけるのかもしれないなあと思っている今日この頃。
 というわけで、最近「システム内製を極める」という本を読みました。基本的に日経コンピュータの記事を集めた内容なので比較的さらっと読めるのですが、最後「おわりに」には、システム開発にたずさわるものとしては考えさせられることが書いてあります。それはまた次の機会に。



エンタープライズマッシュアップ

2011年10月2日 日曜日

 Web2.0やマッシュアップという言葉が流行っていたころ、一部で「エンタープライズマッシュアップ」という言葉が使われた時期がありました。まあ、読んで字のごとく、「企業におけるマッシュアップ」ということで、その心は社内外のWeb-APIを組み合わせて企業内のポータルなどを構築する方法論というようなイメージでしょうか。最近はあまり聞かれなくなりましたが、ことさら「マッシュアップ」という言葉を使わなくても、Web上での開発のひとつの方法論としてある程度定着したからなのでしょうか。

 さて、この言葉を思い出したのは、最近ある雑誌の記事を読んだからです。日経コンピュータの最新9月29日号の「システムを「作らず」に作った」という記事。今回作ったシステムは、ユーザインタフェース部分でひとつのクラウド、帳票生成サービス用のクラウド、ルールエンジン用のクラウド、3つのクラウドの間で通信しながら処理を行うというまさに 「クラウド間でSOAを実現しちゃいました」 的なちょっとおもしろいシステムです。そこそこのパフォーマンスも出ているようで一昔前なら夢物語だったような世界が手の届くところまで来たということですね。

 もちろんこのブログの趣旨からして強調したいのは、ルールエンジンでして・・・^^;。最近のルールエンジンのひとつの典型的な使い方として、今回の例のように、保険料の計算や整合性チェックなどのビジネスロジックの処理部分を、ルールエンジンを用いて独立したWebサービスとして提供するというのがあります。そして将来的には、このサービスをさまざまなアプリケーションで使いまわすということ…もっとも、日本国内で「さまざまなアプリケーションで使いまわす」というところまで行っているところはさすがにまだ聞いたことがないのですが…。

 今回、ルールエンジンがクラウドにのったということになると、上記のようなことがやりやすくなるだけでなく、(もちろんセキュリティの面など解決しなければならないことは多いですが)ルールエンジンを用いてビジネスロジックの処理をサービスとして提供するような可能性、幅がより拡がってくことになるでしょう。冒頭に述べた「マッシュアップ」は、ウィジェットを組み合わせてユーザインタフェース部分をひとつにまとめる感が強いですが、今回のケースは、もう少しビジネスのロジックに踏み込み、クラウドに散在するWebサービス間で物事を処理していく、いわばインターネットSOA、クラウドtoクラウドSOAが始まりつつあるということではないでしょうか。

 最初はルールエンジンの話を書こうと思っていたのですが、結局最後はSOAの話になってしまいましたね。長くなるのでルールの話はぜひ記事を…。

(2012年1月12日追記) この日経コンピュータの記事は、日経の電子版の12月28日つけ記事「システムを「作らず」に作った…得られた八つの利点」として読めるようになりました。

Agile Business Rule Development (ABRD)

2011年9月12日 月曜日

 ずいぶん久しぶりの投稿になってしまいました。というのも最近、ルール関連の案件が増えてきたおかげで、うれしい悲鳴というのでしょうか。多忙な日々をすごしておりました。

 ブログを書かない間、Droolsは5.2が出ているし・・・、「アイログ」と入れてググってみると、アイドルグループ育成ゲームが出てきたりするようになっていたり・・・。それはともかく、本日は本の話。前に Amazon で予約していた本なのですが超多忙な時期に出版・送付されてきたもので本棚に積み上げ状態になっておりました。その本は

Agile Business Rule Development: process, Architecture, and JRules Examples
  Jerome Boyer、 Hafedh Mili

 IBM(アイログ) の JRules を例にとってはいますが、方法論としてはツールに依存したものではなく、JRules以外でも使えます。その名のとおり一般的な Agile な開発方法論をベースにしており、ドキュメントよりも動くソフトウェアを重視する、利用者との密なコミュニケーションなどといったAgile方法論の原則に則った反復型の開発方法論。
 まだ読み始めたばかりのこの本ですが、久しぶりに出版されたビジネスルールによる実践的なシステム開発の本と言えましょう。ボリュームはありますが、その割りには読みやすいように思えます。JRulesを使わない方も目を通す価値があるのではないでしょうか。