2012年1月21日
久しぶりの更新になってしまいましたが、ここのところルールベースエンジン関連の話題が次々と出てきて・・・Droolsはいつのまにか5.3のFinalが出ていて、5.4のβまで出ているし、CorticonはProgressに買収されるし・・・ちなみに最近またDroolsの新しい本が出たようです。
それはそうと、おかげさまで最近私もルールエンジンの仕事がだいぶ増えてきてうれしい限り。ただ、まだまだ人口に膾炙するといったところではないようで、ルールエンジンの動き等に関連していろいろ質問されることが多々あります。
たとえば
・ルールエンジンのプログラムって、if-Thenのルールが並んでいるけれども、上から順にやっていくの??
・(上記に関連して) 通常のプログラムの(単体)テストだと全部のパスを通るようにテストするけれども、 ルールの場合のテストでは、全部のパスを通す…ってどのように考えればよい?
・ルールエンジンのメモリ使用量は何に依存してきまるのでしょうか? ルール数?
・同じようにルールエンジンの処理速度は何できまる?
などなど。
私もこのような質問をされるようになって、あらためてネットなどを調べてもみるのですが、ルールエンジンの動きとかアルゴリズムとか結構情報が少なくて、ルールエンジンの代表的なアルゴリズムであるはずのReteアルゴリズムの日本語の解説などは、ちょっと探してみたところネット上にはほとんど皆無状態でした。
というわけで、これからぼちぼちルールエンジンの動きやアルゴリズムなど気が付いたときに書いていきたいと思います。
さて、最初というわけでルールエンジンの動きから。以前、本宅の記事(プロダクションシステム(ルールベースシステム)とは)にルールエンジンの動きを書きましたが、もともとはこのルールエンジン、人工知能や認知心理学の研究をルーツとするもので
人間が長期記憶にあたる「ルール」を使って、認識した外界の状況(短期記憶に保持される)に合わせて判断を行うという行動がモデルとなっています。
これをルールエンジンの動きとして翻訳してみると、
1.データの集合に対して、たくさんあるルールの条件部分をひとつひとつデータとマッチングさせて、マッチしたルールとデータのカップルを列挙しておく。
2.カップルの中からひとつを選んで実行する。
3.実行によってデータが書き換えられる場合もあるので、再度1.のカップリングを行う。
4.1~3を繰り返してマッチするルールがなくなったところで実行が終了する。
となります。
この動きをみるとわかるように、ルールエンジンでは、すべてのデータに対して、すべてのルールの条件部のマッチングを試し、そののちにルールを実行します。したがってルールの実行順序は必ずしも上から順などといったことではなくて(実はそれなりの実行順の規則はあるのですが)、実行順に過度に依存するようなルールの書き方はむしろお作法に反するものという見方が強いです。
特に最近ルールエンジンがよく使われている入力データのチェックなどは、(チェックそのものだけでいえば)別に順番などはどうでもよく、条件に合うか合わないかで正しくエラーが出ればそれでよいのであって、上記のようなルールエンジンの動きはこの「チェック」という作業に対して非常になじむもののように思います。
カテゴリー: BRMS一般, Drools, 未分類 | コメントはまだありません »
2011年10月16日
先週、ルールエンジンとシステム内製のブログをアップしましたが、「システム内製」 という言葉で私が思い浮かべたのが、建築家のクリストファー・アレグザンダーでした。
クリストファー・アレグザンダーと言えば、ご存知の方も多いかと思いますが、GoFデザインパターンの発想の源であるパターンランゲージを着想し創りあげた建築家。そのアレグザンダーとシステム内製がどのようにつながるのか訝る方もおられるかと思いますが、実はアレグザンダーは有名な「時を超えた建設の道」「パターン・ランゲージ」以後にも(私が思うに)重要な著作を発表しているのですね。それらの著作「オレゴン大学の実験」「まちづくりの新しい理論」は、実はシステム開発の上でも非常に示唆的な考え方を含んでいるのではないかと思っているわけです。
特に「オレゴン大学の実験」は、比較的入りやすいかなあと思いますが、残念ながら今のところ手に入りづらいようなので、そのまま本の目次にもなっている6つの原理を序文から引用しておきましょう。
アレグザンダーらは、コミュニティでの建設と計画の方法を、以下の次の6つの原理にしたがって遂行することで人々が満足する環境を築けるとしています。
(以下引用)
一、有機的秩序の原理 The principle of organic order
二、参加の原理 The principle of participation
三、漸進的成長の原理 The principle of piecemeal growth
四、パターンの原理 The principle of patterns
五、診断の原理 The principle of diagnosis
六、調整の原理 The principle of coodination
(「オレゴン大学の実験」鹿島出版会 p14 から引用)
これだけですと、少々わかりにくいので、一、二、だけでも、さらに説明付で引用すると、
(以下引用)
一、有機的秩序の原理
計画や施工は、全体を個別的な行為から徐々に生み出してゆくようなプロセスによって導かれること。
二、参加の原理
建設内容や建設方法に関するすべての決定は利用者の手に委ねること。
(「オレゴン大学の実験」鹿島出版会 p15 から引用)
となっています。(ちなみにパターンの原理のパターンは、パターンランゲージのパターンです)
さて、この6つの原理を眺めてみると、なんとなく私が「システム開発の上で示唆的」であると言っていることがわかるような気がしません? 今回、「システム内製」と関連して思い浮かべたのが、二、の「参加の原理」。「システム内製」すなわち「ユーザー主体開発」そのものという気がしませんか? また、一、の有機的秩序の原理などは、EA(エンタープライズアーキテクチャ)を、前もってきちんと定めて個々の開発をその枠内で進めていく…という行き方と真逆のことを言っているようでちょっと面白かったりします。
もちろん、都市計画や建築の手法がそのままシステム開発に応用できるとは、万事楽観的な私といえども思ってはいませんが、新たな視点を得るという意味ではなかなか示唆に富むものではないでしょうか。
システム業界では、クリストファー・アレグザンダーと言えばデザインパターンですが、実はデザインパターン以外にも汲み取るべき考え方はまだまだあるのではないかと思っています。
アレグザンダー恐るべし!
カテゴリー: クリストファー・アレグザンダー, システム内製, 本 | コメントはまだありません »
2011年10月10日
先週紹介した日経コンピュータの記事には、クラウドとルールエンジンの組み合わせを使った開発でのメリットとして8つあげられていました。このうちの8番目「内製しやすい」というのが今日のテーマ。
確かにビジネスロジックをルールエンジンを用いて実装すると、ロジックのシステム的な制御部分を隠蔽し、本質的な部分を浮き彫りにさせる効果があります。今回あがっている保険商品の整合性チェックとか保険料の試算などは、ロジック自身はそれほど複雑でないので、ビジネスロジックをたとえば表形式(デシジョンテーブル)でまとめれば、それがほぼそのまま実際に動きます。DroolsではDSL(ドメイン記述言語)もあるので、DSLをうまく設計すれば「日本語で仕様を書けばそれがそのまま動く」といった世界を実現することも夢ではないかもしれません。たとえば
保険料は、基本料率 * ○○割増 * 保険金額である。
ただし
…の場合は○○割増は1.03
…の場合は○○割増は1.05
とかいったような。こんな感じで書いた仕様がそのまま動くとなると、業務に携わる人が直接プログラムを保守するということも現実解として十分考えられるようになってきそうです。
今のところ日本ではBRMS(ビジネスルール管理システム)を使って、現場で業務に携わる人が直接ルールを直すという事例はまだ聞いたことはありません。ただ、ごく一般的な日本の事務現場のExcelシート、マクロの開発力(!!)などを考えると、BRMSでの現場での修正開発も案外いけるのかもしれないなあと思っている今日この頃。
というわけで、最近「システム内製を極める」という本を読みました。基本的に日経コンピュータの記事を集めた内容なので比較的さらっと読めるのですが、最後「おわりに」には、システム開発にたずさわるものとしては考えさせられることが書いてあります。それはまた次の機会に。
カテゴリー: BRA(ビジネスルールアプローチ), BRMS一般, Drools, 本 | コメントはまだありません »
2011年10月2日
Web2.0やマッシュアップという言葉が流行っていたころ、一部で「エンタープライズマッシュアップ」という言葉が使われた時期がありました。まあ、読んで字のごとく、「企業におけるマッシュアップ」ということで、その心は社内外のWeb-APIを組み合わせて企業内のポータルなどを構築する方法論というようなイメージでしょうか。最近はあまり聞かれなくなりましたが、ことさら「マッシュアップ」という言葉を使わなくても、Web上での開発のひとつの方法論としてある程度定着したからなのでしょうか。
さて、この言葉を思い出したのは、最近ある雑誌の記事を読んだからです。日経コンピュータの最新9月29日号の「システムを「作らず」に作った」という記事。今回作ったシステムは、ユーザインタフェース部分でひとつのクラウド、帳票生成サービス用のクラウド、ルールエンジン用のクラウド、3つのクラウドの間で通信しながら処理を行うというまさに 「クラウド間でSOAを実現しちゃいました」 的なちょっとおもしろいシステムです。そこそこのパフォーマンスも出ているようで一昔前なら夢物語だったような世界が手の届くところまで来たということですね。
もちろんこのブログの趣旨からして強調したいのは、ルールエンジンでして・・・^^;。最近のルールエンジンのひとつの典型的な使い方として、今回の例のように、保険料の計算や整合性チェックなどのビジネスロジックの処理部分を、ルールエンジンを用いて独立したWebサービスとして提供するというのがあります。そして将来的には、このサービスをさまざまなアプリケーションで使いまわすということ…もっとも、日本国内で「さまざまなアプリケーションで使いまわす」というところまで行っているところはさすがにまだ聞いたことがないのですが…。
今回、ルールエンジンがクラウドにのったということになると、上記のようなことがやりやすくなるだけでなく、(もちろんセキュリティの面など解決しなければならないことは多いですが)ルールエンジンを用いてビジネスロジックの処理をサービスとして提供するような可能性、幅がより拡がってくことになるでしょう。冒頭に述べた「マッシュアップ」は、ウィジェットを組み合わせてユーザインタフェース部分をひとつにまとめる感が強いですが、今回のケースは、もう少しビジネスのロジックに踏み込み、クラウドに散在するWebサービス間で物事を処理していく、いわばインターネットSOA、クラウドtoクラウドSOAが始まりつつあるということではないでしょうか。
最初はルールエンジンの話を書こうと思っていたのですが、結局最後はSOAの話になってしまいましたね。長くなるのでルールの話はぜひ記事を…。
(2012年1月12日追記) この日経コンピュータの記事は、日経の電子版の12月28日つけ記事「システムを「作らず」に作った…得られた八つの利点」として読めるようになりました。
カテゴリー: BPM、SOA, BRA(ビジネスルールアプローチ), BRMS一般 | コメントはまだありません »
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を使わない方も目を通す価値があるのではないでしょうか。
カテゴリー: BRA(ビジネスルールアプローチ), BRMS一般 | コメントはまだありません »