El mundo que soñé http://blog.iluminado.jp ビジネスルールとそれにまつわるソフトウェア技術の雑記帳 Sun, 20 May 2012 14:18:54 +0000 http://wordpress.org/?v=2.9.2 ja hourly 1 ビジネスルール管理システムとエキスパートシステム(1) http://blog.iluminado.jp/2012/05/20/%e3%83%93%e3%82%b8%e3%83%8d%e3%82%b9%e3%83%ab%e3%83%bc%e3%83%ab%e7%ae%a1%e7%90%86%e3%82%b7%e3%82%b9%e3%83%86%e3%83%a0%e3%81%a8%e3%82%a8%e3%82%ad%e3%82%b9%e3%83%91%e3%83%bc%e3%83%88%e3%82%b7%e3%82%b9/ http://blog.iluminado.jp/2012/05/20/%e3%83%93%e3%82%b8%e3%83%8d%e3%82%b9%e3%83%ab%e3%83%bc%e3%83%ab%e7%ae%a1%e7%90%86%e3%82%b7%e3%82%b9%e3%83%86%e3%83%a0%e3%81%a8%e3%82%a8%e3%82%ad%e3%82%b9%e3%83%91%e3%83%bc%e3%83%88%e3%82%b7%e3%82%b9/#comments Sun, 20 May 2012 14:18:54 +0000 Y.Tsushima http://blog.iluminado.jp/?p=254 最近、日経BP社 ITproのメールマガジンで「最新ITの“古さ”を知らない危険」という記事を読みました。

まとめてしまえば

最新のIT関連キーワードXXは、つきつめてみると昔流行ったキーワードYYの話である

という発言を情報システム部長などのベテランからよく聞くということ。
そしてそれは、

ある意味正しいが、ある意味正しくない

ということ。これは、

確かに最近のIT関連技術のキーワードは、昔の技術キーワードの蒸し返しであることが多く、ベテランの言うことはそういった面で正しいと言えるが、一方で昔のブーム以降のさまざまな(周辺を含めた)技術の進歩を取り込んで、単純な蒸し返しに終わらない再挑戦、再々挑戦となっているという面で正しくない

というわけ。要するに

最近流行の技術は過去に存在した技術の蒸し返しであることも多いが、単純な蒸し返しであるというわけではない。したがって徒に否定してしまうのは正しくないが、一方で最近の技術を過去の経験と照らし合わせもせず無批判に取り入れるのは、過去と同じ失敗をしてしまう可能性があるのでそれもよくない。

ということのようです。

さて、上に挙げた記事では、実例として、

XXが「スマート…」なら　YYが「ユビキタス」「ブロードバンド」「ニューメディア」
XXが「クラウド」なら　YYは「ASP」「VAN」あるいは「仮想化」

が挙げられていましたが、今回の本題の話に入ると、さしずめ

XXが「ビジネスルール管理システム(BRMS)」なら　YYは「エキスパートシステム」

といったところになるでしょう(ちなみにここで言っているBRMSとは例の記事のビジネスルール特化型のBRMSのことなので念のため、XXがオールインワン型のBRMSというのであれば、YYは自動生成???)。

したがって上の記事の主張に沿うならば、BRMSとエキスパートシステムとの対比と、過去の総括をやっておく必要がでてきます。実際、BRMSのことを上司に話したら、「昔のエキスパートシステムやルールベースの言語とどう違うの？」という質問をされた…という話も最近ちらほら耳にしていますし、

また、私が購読している海の向こう(というか言葉の壁の向こう)のブログでまさにこの対比がホットな話題となっていたりもします。

Follow-Up on ‘Harvesting Business Rules’: Business Rules vs. Expert Systems
Response to: Business Rules vs. Expert Systems: Same or Different?
Additional Response to: Business Rules vs. Expert Systems – Same or Different?

実は、かなり前に当ブログでも関連するようなことを話題にしており、

エキスパートシステムの思ひ出１(なぜ今またルールベースに光があたっているのか)
エキスパートシステムの思ひ出２(なぜ今またルールベースに光があたっているのか)

という記事があるのですが、読んでいてわかりにくい部分などもあるので、ここでは再度、ビジネスルール管理システムとエキスパートシステムとを対比しながらまとめておきましょう。

まず、今回のブームでのBRMSと過去のエキスパートシステムとの一番の大きな違いは

１．適用する対象の違い

と言えましょう。　(この項続く)

]]> http://blog.iluminado.jp/2012/05/20/%e3%83%93%e3%82%b8%e3%83%8d%e3%82%b9%e3%83%ab%e3%83%bc%e3%83%ab%e7%ae%a1%e7%90%86%e3%82%b7%e3%82%b9%e3%83%86%e3%83%a0%e3%81%a8%e3%82%a8%e3%82%ad%e3%82%b9%e3%83%91%e3%83%bc%e3%83%88%e3%82%b7%e3%82%b9/feed/ 0 Drools5.4.0.Final リリース http://blog.iluminado.jp/2012/05/20/drools5-4-0-final-%e3%83%aa%e3%83%aa%e3%83%bc%e3%82%b9/ http://blog.iluminado.jp/2012/05/20/drools5-4-0-final-%e3%83%aa%e3%83%aa%e3%83%bc%e3%82%b9/#comments Sun, 20 May 2012 00:36:38 +0000 Y.Tsushima http://blog.iluminado.jp/2012/05/20/drools5-4-0-final-%e3%83%aa%e3%83%aa%e3%83%bc%e3%82%b9/ 今月の14日に、Drools5.4.0.Finalがリリースされました。

Droolsの開発は結構活発で、追いついていくのが大変。
久しぶりに新しい機能など、きちんと整理しておかなくてはと
思っている今日このごろ。

]]> http://blog.iluminado.jp/2012/05/20/drools5-4-0-final-%e3%83%aa%e3%83%aa%e3%83%bc%e3%82%b9/feed/ 0 通信業界のBRMS http://blog.iluminado.jp/2012/04/17/%e9%80%9a%e4%bf%a1%e6%a5%ad%e7%95%8c%e3%81%aebrms/ http://blog.iluminado.jp/2012/04/17/%e9%80%9a%e4%bf%a1%e6%a5%ad%e7%95%8c%e3%81%aebrms/#comments Tue, 17 Apr 2012 14:36:02 +0000 Y.Tsushima http://blog.iluminado.jp/?p=251 スマホ急増にもBRMSが効く

…実は、日本でも通信業界で(ルールエンジンを主体とした)BRMSはそれほど珍しいものではなかったり。

たとえば

日本テレコム、ILOG JRulesを採用 (2006年7月)

は、料金計算にBRMSを用いていますし(ちなみにILOG JRulesは現在のIBMのBRMS)、

Prologベースプロダクションシステムによるクラウドサービスの運用監視

などは通信の監視としてルールエンジンを用いています(Prologをルールエンジンとして使っています)。

なお料金計算にしても、ネットワークアプライアンスの監視にしても比較的ルールエンジンが適用しやすい分野です。たとえば

Cisco Active Network Abstraction Administrator Guide, 3.6.4 – Drools Rules Engine …

というのはご存知でしょうか。

]]> http://blog.iluminado.jp/2012/04/17/%e9%80%9a%e4%bf%a1%e6%a5%ad%e7%95%8c%e3%81%aebrms/feed/ 0 続々　日経コンピュータの「超高速開発」特集 http://blog.iluminado.jp/2012/04/14/%e7%b6%9a%e3%80%85%e3%80%80%e6%97%a5%e7%b5%8c%e3%82%b3%e3%83%b3%e3%83%94%e3%83%a5%e3%83%bc%e3%82%bf%e3%81%ae%e3%80%8c%e8%b6%85%e9%ab%98%e9%80%9f%e9%96%8b%e7%99%ba%e3%80%8d%e7%89%b9%e9%9b%86/ http://blog.iluminado.jp/2012/04/14/%e7%b6%9a%e3%80%85%e3%80%80%e6%97%a5%e7%b5%8c%e3%82%b3%e3%83%b3%e3%83%94%e3%83%a5%e3%83%bc%e3%82%bf%e3%81%ae%e3%80%8c%e8%b6%85%e9%ab%98%e9%80%9f%e9%96%8b%e7%99%ba%e3%80%8d%e7%89%b9%e9%9b%86/#comments Sat, 14 Apr 2012 06:30:27 +0000 Y.Tsushima http://blog.iluminado.jp/?p=243 ひとつの記事で、ちょっと引っ張りすぎかとも思いますが、もう少し。

この記事で違和感を感じていたことがもうひとつあります。それは、

「超高速開発」が日本を救う

という見出し。システム開発が速く効率的に進められるに越したことはないのですが、それがそのまま日本を救う…？ もちろん見出し特有の誇張だとは思いますが、一方で裏を返せば、開発が速くできればそれでOKという意識が垣間見られて…ちょっと穿ち過ぎでしょうか。

***

一般的なユーザ企業で利用される(コンピュータ)システムの技術には大きく２つの方向があると私は思っています。

  • システム開発ツールや開発方法論などシステムの開発効率をあげる方向。
  • システムをどのように使って現実の問題に対処するか、システムをどのように現実の問題に応用していくか、という方向

私も学生時代を含めると30年近くこの分野に携わっていますが、私の見るに日本の企業向けシステム技術の方向が、ここのところ…というかJavaやUMLが出てきた10数年前から開発効率をあげること…開発方法論とか開発ツール、開発言語に偏重しているような気がしています。

もちろん開発効率をあげることは重要であり、未だに企業内の情報化が進んでいない企業などでは、最重要の課題であることもわかります。その上でやはり、世間一般で、「そもそもどんなシステムを作るのか」という議論が少ないように思うのです。

もっとも私自身、開発方法論こそが大事…と思っていたことがありました。そのころは企業内のコンピュータシステムは汎用機全盛の時代。システム全体での新人研修の言語はCOBOL。構造化プログラミングの話とか。学生時代に多少なりとも抽象データ型とかオブジェクト指向とかを齧ってきたものにとっては、…う～ん。という時代でした。

そんなときに最初に配属されたのが、人工知能やORを用いて生産計画(などなど)のシステムをつくるようなところ。それこそ「システムをどのように使って現実の問題に対処するか」の技術の部署でした。
最適化手法や人工知能など、技術としてそれなりにはおもしろかったのですが、個人的にはシステム開発の方法論が(生意気にも)あまりにもナイーブだなと思って、オブジェクト指向の勉強(*1)をやっていました。

それが、UMLやJava、そしてデザインパターンなどが出てきて世の中の流れが一気に方法論に傾き始めたように思います(特に日本)。もちろんこれによりさまざまな洗練された開発手法がうまれてきたことは確かですし、それ自体は喜ばしいことではあるのですが、一方でそもそもコンピュータを使って何をやるかというところについては停滞気味になってしまっていったのではないでしょうか(特に日本)。そんな中、ここ10数年インターネットが普及するにつれ、従来の企業のシステムからは考えられないようなインターネット上のサービスがうまれてきています。検索エンジンしかり、SNSしかり、動画共有サイトしかり、ECしかり…これらはいずれも「システムをどのように現実の問題に応用していくか」という問いの上に生まれてきたものです。インターネットの世界では、まず「何をつくるか」があります。

翻って従来からの企業のアプリを考えたとき「何をつくるか」というのはだいたい決まっていて、それを「どう効率的に開発するか」ということが焦点になりがちです(特に日本)。

…そろそろ企業のアプリ開発でも、「何を作るか」ということにもうちょっと重心を移していって良いのではないでしょうか(特に日本)。

私が仕事で生産計画や人工知能をやっていたのは20年以上も前。そのときはコンピュータパワーの貧弱さがひとつのネックとなっていました。しかし現在、iPad2などは、そのころの一般的なスーパーコンピュータのひとつCray2/4と同等だとか。昔を知っている人ならわかると思いますが、あのCray(*2)が街中に、電車の中に、家の中にころがっているのです。

こんな時代に20年前と同じような発想でアプリを考えていてはもったいないでしょう。昔できなかった最適化の計算などは、普通に行けたり^^。最近流行りつつある「ビッグデータ」の分析などは、これからのひとつの方向を示しているのかもしれません。

(また、このコンピュータパワーの飛躍的な増大がなければ、(ビジネスルール特化型の)BRMSは存在し得なかったでしょう。)

***

実は(ビジネスルール特化型の)BRMSの世界では、以前からの謳い文句「ビジネスの変化に合わせてITも変更」というところから一歩進んだところ、たとえばデータ分析とBRMSとを組み合わせた意思決定の最適化という方向に重点がシフトしていきつつあります。つまり、開発・保守のスピードを問題にするのではなく、そのスピードを前提にしてそれらをどう活かしていくということが焦点になってきています(*3)。

***

というわけで、

「超高速開発」

するのはよいのですが、それだけで

日本が救われる

とは思えません(笑)。

今の時代、開発が「超高速」かどうかはともかく、定型的な開発などはできるだけ無駄を減らし、手間をかけずに、自動生成できるところはできるだけ自動生成ですませる。そして、システムを現実の問題の解決のためにいかに適用していくかというところ、システムに「付加価値」をどうつけていくかという部分により注力していかないことには「日本は救われない」のではないでしょうか。

「超高速開発」を前提として、その一歩先の話が議論されていくようでないと「日本を救う」と言えないのではないでしょうか。

***

最後の方はかなり調子が高くなってしまいましたが、前回の記事で自動生成ツールについて使えるところではどんどん使っていけばよいと書いた真意はそこにあります。

過去20年間で、コンピュータパワーは飛躍的にアップし、またシステムを利用する要素技術も格段に進歩しました(たとえば機械学習などを含む統計的な数々の手法など)。一方でこれらを現実に適用していくことに関しては緒に就いたばかりで、これからの大きな発展が期待されています。

いままで仕事として、ユーザの業務にも、システム技術にも向き合ってきたはずのSEは、これからのシステムの応用技術を開拓し、新たなビジネスモデルを考えていくのに恰好な人材だと思っているのですがねえ。

***

*1 : ちなみに、そのころ読んだのは、バートランドメイヤーの「オブジェクト指向入門」の第1版。これはおもしろかったです。私のオブジェクト指向の知識のベースはこの本、類いまれなる名著だと思います。
今は第2版が出ていますが、2分冊になってそれぞれが辞書みたいに分厚いのでさすがに読む気になりません(^^;)・・・でも、たぶん読んだらとても勉強になると思います。その他にはOMTやBooch法、Coad&Yourdonの本などを濫読していました。

*2 : そのころはスーパーコンピュータといえばCray、Crayといえばスーパーコンピュータという時代でした。もちろんNECや富士通など日本勢も健闘してはいましたが、デザイン面でのCrayのインパクトにはかないませんでした。

*3 : この辺は、BRMSの記述はあまりありませんが、ちょっと古いダヴェンポートの本。さらに最近の本としては、James TaylorのDecision Management Systemsとかが参考になるかと思います。

]]> http://blog.iluminado.jp/2012/04/14/%e7%b6%9a%e3%80%85%e3%80%80%e6%97%a5%e7%b5%8c%e3%82%b3%e3%83%b3%e3%83%94%e3%83%a5%e3%83%bc%e3%82%bf%e3%81%ae%e3%80%8c%e8%b6%85%e9%ab%98%e9%80%9f%e9%96%8b%e7%99%ba%e3%80%8d%e7%89%b9%e9%9b%86/feed/ 0 続　日経コンピュータの「超高速開発」特集 http://blog.iluminado.jp/2012/04/11/%e7%b6%9a%e3%80%80%e6%97%a5%e7%b5%8c%e3%82%b3%e3%83%b3%e3%83%94%e3%83%a5%e3%83%bc%e3%82%bf%e3%81%ae%e3%80%8c%e8%b6%85%e9%ab%98%e9%80%9f%e9%96%8b%e7%99%ba%e3%80%8d%e7%89%b9%e9%9b%86/ http://blog.iluminado.jp/2012/04/11/%e7%b6%9a%e3%80%80%e6%97%a5%e7%b5%8c%e3%82%b3%e3%83%b3%e3%83%94%e3%83%a5%e3%83%bc%e3%82%bf%e3%81%ae%e3%80%8c%e8%b6%85%e9%ab%98%e9%80%9f%e9%96%8b%e7%99%ba%e3%80%8d%e7%89%b9%e9%9b%86/#comments Wed, 11 Apr 2012 14:32:13 +0000 Y.Tsushima http://blog.iluminado.jp/?p=237 表題の日経記事の「オール・イン・ワン型」自動生成ツール(ＢＲＭＳに分類するのは私としては違和感を禁じ得ないので、あえて自動生成ツールとしておきます)について、前回も書きましたが、私自身は、使えるところであれば積極的に使っていってよいと思っています。ネットを見てみると、否定的か肯定的か極端な意見がわりに多かったですが、現実的に見れば、それほど毛嫌いする理由もないですし、一方で盲信するほど革命的という話でもないでしょう。

最近はシステムの技術も進歩して、こういった自動生成のツールに限らず、フレームワーク(商用、OSSを問わず)などでもそこそこよくできているものなら、ちょっとしたアプリのスケルトンくらい簡単にできてしまいます。

なので、今現在開発の現場にいる方にとっては、これらツールを、分野をある程度限定して、多少の開発ノウハウを加え、洗練させていけば、そこそこのアプリが自動生成できるだろうことは想像つくのではないでしょうか(もちろんそういった自動生成ツールを作るのは簡単ではないとは思います)。またそもそも自動生成するアプリが使えないようなら、ERPや業務用のパッケージはおそらくもっと使えないはず。実際にERPや業務用パッケージが製品として成り立っている以上、自動生成するアプリは少なくともそこそこは使えるでしょう。アプリ的に言えば、あとはそれをそのまま使っていくかどうかの問題だけだと思います。

自動生成ツールが使えないという話は自動生成したアプリそのものが使えないというよりもむしろ、

  • 既存の他システムとのインタフェースをとりづらい。
  • ソースコードを生成するツールの場合、生成したコードを手で微調整するだけの柔軟性はあるが、一方で、あらためてツールを使ってアプリを再構築といったときに手で修正したソースコードの扱いが非常に難しい

といったところでしょうか。逆にこの辺の弱点がうまくクリアできれば(もしくは我慢ができれば)手間をかけずに自動生成できるツールを採用しない手はないのではと思います。

そもそも今ある大部分の業務アプリというのは、事務の台帳をDB化したもの。ロジックそのものに複雑なところがあるわけではありません。そういったアプリに対しては必要以上に人手をかけて開発を行うよりも、
使えるところは自動生成ツールやパッケージを積極的に使ってうまく開発していくのが得策だと最近特に思っています。(続く…)

]]> http://blog.iluminado.jp/2012/04/11/%e7%b6%9a%e3%80%80%e6%97%a5%e7%b5%8c%e3%82%b3%e3%83%b3%e3%83%94%e3%83%a5%e3%83%bc%e3%82%bf%e3%81%ae%e3%80%8c%e8%b6%85%e9%ab%98%e9%80%9f%e9%96%8b%e7%99%ba%e3%80%8d%e7%89%b9%e9%9b%86/feed/ 1 ビジネスルール管理システム (BRMS) の動向　US　2011-2012 http://blog.iluminado.jp/2012/04/06/%e3%83%93%e3%82%b8%e3%83%8d%e3%82%b9%e3%83%ab%e3%83%bc%e3%83%ab%e7%ae%a1%e7%90%86%e3%82%b7%e3%82%b9%e3%83%86%e3%83%a0brms%e3%81%ae%e5%8b%95%e5%90%91%e3%80%80us%e3%80%802011-2012/ http://blog.iluminado.jp/2012/04/06/%e3%83%93%e3%82%b8%e3%83%8d%e3%82%b9%e3%83%ab%e3%83%bc%e3%83%ab%e7%ae%a1%e7%90%86%e3%82%b7%e3%82%b9%e3%83%86%e3%83%a0brms%e3%81%ae%e5%8b%95%e5%90%91%e3%80%80us%e3%80%802011-2012/#comments Thu, 05 Apr 2012 16:14:20 +0000 Y.Tsushima http://blog.iluminado.jp/?p=226 以前、このブログでBRMSの市場について取り上げた記事を書きましたが、最近USでのBRMSの動向について、ブログやレポートを見る機会があったので、個人的な視点含めごく簡単にまとめてみました。(ちなみに、ここで言っているBRMSとは、日経コンピュータの例の記事で言う「ビジネスルール特化型」のことなので念のため。「オールインワン型」はここでは含まれていません)

USのBRMS市場は2008年から2010年にかけて年2ケタ成長を続けており、すべての開発ツールの市場の中でも成長率の非常に高い市場のひとつとなっています。その規模は昨年で軽く6億ドルを超える程度になっていると推計されています。

また、ここ数年合併・統合が多くみられるのもこの市場の特徴です。ビジネスポリシーやルールの急速な変化に合わせて、システムも変更して行こうとすると、BRMSのようにビジネスルールのライフサイクル全般にわたって統合的に管理するツールが必要になってくるのでしょう。大手のベンダは、そのようなBRMSの潜在力に着目し、有望なBRMSベンダを取り込んでいく傾向にあります。Ilogを買収したIBM、HaleyはOracleに、YasuがSAP、InnovationsがBoschに、そして最近ではCorticonがProgressに買収されています。

さて最近のBRMSベンダの状況ですが、ある程度の地歩を保ちながら大企業向けなどで比較的元気のあるのは、以下のベンダー。

  • IBM(旧Ilog JRules)
    言わずと知れたBRMSの巨人。BRMSは、比較的細かい制御が可能な開発者寄りの製品と、細かい制御よりもむしろ簡単に扱えることに重点を置いたビジネスユーザ寄りの製品とがあります。この分類でいえば、IBMのBRMSは、古くからあるだけに、もともとは開発者寄りの製品ではありますが、ビジネスユーザ向けの機能も充実させてきており、幅広い範囲に受け入れられるようになってきています。ただ、IBMはこのところBRMSとしての機能よりもBPMやCEPとの統合に力を入れている様子です。
  • Red Hat JBoss　(JBoss Drools)
    もとはオープンソースのJBoss BRMSは、私は勝手に貧者のJRules(!)と呼んでおり、ここ数年特に、基本機能がかなり充実してきました。ただどちらかというと開発者向けの機能の方が優先で開発され、後からデシジョンテーブルやDSLなどのユーザ向け機能が後から追いつくという感があります。
  • InRule Technology (InRule)
    .Net向けのツールの最右翼。.Netには、IBM Ilog、Corticon、FICOなど対応しているツールは多いですが、その大部分はJavaをメインのターゲットにしているツールであり、.NetはJavaツールの.Net対応版として提供されています。その中でメインターゲットとして.Netを対象としているInRuleは、BRMSとして貴重な存在です。
  • Bosch Software Innovations (Visual Rules)
    BRMSの欧州の雄(Ilog JRules も元々はフランス生まれですが…)。グラフィカルなルール表現が特徴のVisual Rules。欧州では大きく伸びているようです。
  • Progress (Progress Corticon)
    Ilogなどに比べれば新進といえますが、最近の伸びは目を見張るものがあります。もとはユーザ(医者)が中心になってベースを設計しているので、ビジネスユーザ寄りの機能が充実した製品です。Corticonは、上記InRuleやBoschなどとともに顧客を非常に増やしています。

その他BRMSの有名どころでは、

  • FICO (BlazeAdvisor)
    最近はBRMSプラットフォームというよりも、ハイエンドのデシジョンマネジメントの「ソリューション」を提供することに力を入れているのではないかという見方が・・・。

またOracleも自前のBRMSを持っています。

  • Oracle
    Oracleは、実は2つのルールエンジンを持っていて、ひとつは買収したHaley系のOracle Policy Automation、もう一つは Jess がベースとなっている Oracle Business Rules です。このうちOracle Business Rules はOracle SOA Suiteのコンポーネントとしてのみ提供されているようです。

そして、新進気鋭と言える注目ベンダとしては

  • OpenRules
    Excelなどの表形式でルールを記述するオープンソースのBRMS。ビジネスユーザ寄りの製品として機能が充実してきているようです。
  • SparklingLogic
    ベテランのルール専門家がその経験を生かして開発したツール。ビジネスユーザ寄りの機能が充実しており、またReteで有名なForgy博士も顧問として名を連ね、新たなアルゴリズム Rete NT　を採用しています。

ほかに、BPMなどの他の機能とともに提供されたりする(SAP,　Pegaなど)ことも多く、BRMSのベンダは、ここにあげた以上にたくさんあるので、下記のリンクなどを参考にしてみてください。

ブログ

JT on EDM

Business Policy and Rule Vendor Round Up

レポート

Gartner, Vendors in the Business Rule Market, 2012

Forrester, Market Overview: Business Rules Platforms 2011

The Business Value of Business Rules Management Systems
Sponsored by: IBM

]]> http://blog.iluminado.jp/2012/04/06/%e3%83%93%e3%82%b8%e3%83%8d%e3%82%b9%e3%83%ab%e3%83%bc%e3%83%ab%e7%ae%a1%e7%90%86%e3%82%b7%e3%82%b9%e3%83%86%e3%83%a0brms%e3%81%ae%e5%8b%95%e5%90%91%e3%80%80us%e3%80%802011-2012/feed/ 1 日経コンピュータの「超高速開発」特集 http://blog.iluminado.jp/2012/03/29/%e6%97%a5%e7%b5%8c%e3%82%b3%e3%83%b3%e3%83%94%e3%83%a5%e3%83%bc%e3%82%bf%e3%81%ae%e3%80%8c%e8%b6%85%e9%ab%98%e9%80%9f%e9%96%8b%e7%99%ba%e3%80%8d%e7%89%b9%e9%9b%86/ http://blog.iluminado.jp/2012/03/29/%e6%97%a5%e7%b5%8c%e3%82%b3%e3%83%b3%e3%83%94%e3%83%a5%e3%83%bc%e3%82%bf%e3%81%ae%e3%80%8c%e8%b6%85%e9%ab%98%e9%80%9f%e9%96%8b%e7%99%ba%e3%80%8d%e7%89%b9%e9%9b%86/#comments Thu, 29 Mar 2012 14:27:03 +0000 Y.Tsushima http://blog.iluminado.jp/2012/03/29/%e6%97%a5%e7%b5%8c%e3%82%b3%e3%83%b3%e3%83%94%e3%83%a5%e3%83%bc%e3%82%bf%e3%81%ae%e3%80%8c%e8%b6%85%e9%ab%98%e9%80%9f%e9%96%8b%e7%99%ba%e3%80%8d%e7%89%b9%e9%9b%86/ いつのまにか次の号が出てしまっていますが、日経コンピュータの3/15号はBRMS(ビジネスルール管理システム)の特集・・・というか、見出し通りの「超高速開発」の特集でした。

というのも、いわゆる自動生成系の、ここで言う「オールインワン型」というのは、最近一般的に言われるBRMSとはちょっと違うのではないかと・・・。

最近言われているBRMSは、Javaなどのソースコードを生成して、コンパイル・実行するわけではなくて表形式やDSL(ドメイン記述言語)、あるいはルールベース用の言語で書かれたビジネスルールをそのまま実行するのが基本です。また、BRMSで管理するものは本来のビジネスロジックやビジネス上のデータモデルのみであり、画面や物理データベースなどのシステム上のロジックは原則含まれません。

上記のようなBRMSの特徴のおかげで「BRMSを用いるとユーザ自身が本来のビジネスロジックに集中して追加・修正・テスト・実行ができます」という謳い文句が出てくるわけで、この部分を端折って通常のBRMSと自動生成系のツールとを一緒にしてしまうのには、ちょっと違和感を感じてしまいます。

確かに自動生成系のツールは、業務ロジックをルール形式で書いたりするので広義のBRMSであると言えなくもないですが、その重点の置きどころは画面やデータベース、ロジックを含めたシステム全体の開発をできるだけ手間をかけずに極力自動で生成してくるところにあるかと思うので、最近言われているBRMSと自動生成系のツールとでは、最初のコンセプトからして違うのでは。

周囲の話やブログなどを見聞きしているとその辺に若干の誤解がありそうなので念のため記事をまとめてみました。

ちょっと補足しておくと、私は自動生成系のツールに否定的なのではなくて、むしろシステム開発のつまらない部分はどんどん自動生成していったら派です。GeneXusなど非常におもしろそうですよね。プログラムを自動生成する際には、裏でシステム開発の知識を表現したPrologのプログラムが動いているとのこと。南米発というところも気に入っています。

個人的には、これらのツールは、自動生成系のツールでシステムの枠を作って、一般的にいうBRMSでビジネスロジックを作って載せるというような補完的な関係のような気がするのですがいかがでしょうか。

]]> http://blog.iluminado.jp/2012/03/29/%e6%97%a5%e7%b5%8c%e3%82%b3%e3%83%b3%e3%83%94%e3%83%a5%e3%83%bc%e3%82%bf%e3%81%ae%e3%80%8c%e8%b6%85%e9%ab%98%e9%80%9f%e9%96%8b%e7%99%ba%e3%80%8d%e7%89%b9%e9%9b%86/feed/ 2 Reteアルゴリズム(3) http://blog.iluminado.jp/2012/03/29/rete%e3%82%a2%e3%83%ab%e3%82%b4%e3%83%aa%e3%82%ba%e3%83%a03/ http://blog.iluminado.jp/2012/03/29/rete%e3%82%a2%e3%83%ab%e3%82%b4%e3%83%aa%e3%82%ba%e3%83%a03/#comments Wed, 28 Mar 2012 15:17:25 +0000 Y.Tsushima http://blog.iluminado.jp/?p=216 (前回の続き)

ちなみに前回のケースは、条件部分に書かれている

契約(　$id_no : 証券番号,　基本保険金額 > 30000000)

は、制約条件が「基本保険金額 > 30000000」の一つですが、これにたとえば「○○特約付加==true」などという条件が加わると、ネットワーク上は、「基本保険金額 > 30000000」のαノードの次に、「○○特約付加==true」のαノードが直列に付け加わります。

さて次にβノードを用いた実例を見てみましょう。αノードは一つのファクトに対する制約条件でしたが、βノードは複数のファクトにまたがる制約条件を表すノードとなります。このノードは2つの入力(Left Input, Right Input)があり、左の入力はファクトの組、右の入力は、ファクトとなります。またこのそれぞれの入力は、部分的にマッチしたファクトの組やファクトの待機場所となるメモリを持ちます。

ここでは典型的なβノードであるJoinノードを例にとって見てみましょう。

先ほどのルールに加えて、もう一つルールを加えてみます。

package com.sample

declare 契約
証券番号 : String;
基本保険金額 : int;
end

declare 顧客
顧客番号 : String;
保険契約 : java.util.ArrayList;
end

rule “基本保険金額1″
when
契約(
id_no : 証券番号,
基本保険金額 > 30000000
)
then
System.out.println(“証券番号 ” + id_no + ” の基本保険金額が3000万円を超えています。”);
end

rule “基本保険金額2″
when
$c : 契約(
id_no : 証券番号,
基本保険金額 > 30000000
)
顧客(
customer_no : 顧客番号,
保険契約 contains $c
)
then
System.out.println(“顧客番号 ” + customer_no + ” の契約の中に基本保険金額が3000万円を超えている契約があります。”);
end

新たに加えた、基本保険金額2のルールは、顧客タイプのファクトに対する条件を加えています。顧客が持っている保険契約(リスト)に基本保険金額が3000万を超えるものがあればメッセージを出力するというものです。

このルールファイルは以下の形のReteネットワークとなります。

Reteネットワーク2
まず、同じ条件の部分は、２つのルールでグラフのノードが共有されていることに注意ください。さらに新たな種類のノード(黄緑のノード)が表れています。これがβノードの一種であるJoin ノードになります。

  • Joinノード
    LeftInputAdapterノードから入ってくるファクトの組(Left Input)と、Right Input
    からのファクトとを合わせて判断し、条件が満たされれば入力から新たなファクトの
    組をつくり、次に渡す。

では、上記のネットワークにファクトをinsertしてみましょう。以下のファクトを次々に加えていきます。

f-1．契約(証券番号=’10001′, 基本保険金額=40000000)
f-2．契約(証券番号=’10005′, 基本保険金額=20000000)
f-3．顧客(顧客番号=’10005′, 保険契約={f-1,f-2})

まずf-1をinsertします。契約→αノード(基本保険金額>3000万)を通過してLeftInputAdapterノードに入ります。ここでファクトの組(f-1)が生成され、2つの方向に伝播していきます。一方はTerminalノードに行き、ルール”基本保険金額1″と合わさって、実行候補のリストに付け加えられます。もう一方は、黄緑のJoinノードの左入力となります(上の図ではJoinノードの右になっていますが^^;)。

さて、Joinノードの左(上図では右)入力に(f-1)が入ってきました。Joinノードは片方の入力に値が入ってきたので、もう片方の入力のメモリを見に行きます。しかしまだメモリは空なので(f-1)はそのまま左入力のメモリに保存されます。

次にf-2をinsertしましょう。契約→αノード(基本保険金額>3000万)と行きますが、この時点でこのαノードを通過できません。

最後にf-3をinsertしましょう。顧客のファクトなので、顧客に進み、次のJoinノードの入力になります。Joinノードでは、片方の入力としてf-3が入ってきたので、f-3を右入力のメモリに保持すると同時に、左入力のメモリを見に行きます。左入力のメモリには(f-1)が入っていたので、f-3と、(f-1)を使って条件判断をします。f-3には、f-1の保険契約が含まれているので、条件が満たされ新たなファクトの組((f-1),f-3)を生成して次に渡します。最後にこのファクトの組はルール”基本保険金額2″と合わさって、実行候補のリストに加えられます。

以上、このようにしてファクトがinsertされていきます。ファクトが削除(retract)されるときは対象のファクトを入口から流して逆に削除していき、ファクトの更新の場合はretract&insertの動きになります。

以上がReteアルゴリズムの概略です。わかりにくい部分も多々あったかと思いますが、雰囲気はおおよそつかめていただけたのではないかと。

ルールベースのアプリケーションのパフォーマンス見積もりなどでは、簡単なのでついついルール数で概算見積もりをしてしまいます。しかし本来は、パフォーマンスとルール数自身とは直接の関係はありません。パフォーマンスに影響するのは、むしろルールの条件部分のバリエーションの数であるということがおわかりいただけたのではないかと思います。

あと、最近のルールエンジンの使い方から考えると、Reteアルゴリズムは少々オーバースペックなので、使い方に制限があるかわりに、より軽い Sequential アルゴリズムもよく使われますが、それはまたの機会に。

(参考文献)
Michal Bali,  Drools JBoss Rules 5.0 Developer’s Guide PACKT publishing.
Jérôme Boyer, Hafedh Mili, Agile Business Rule Development Process, Architecure, and JRules Examples Springer.

]]> http://blog.iluminado.jp/2012/03/29/rete%e3%82%a2%e3%83%ab%e3%82%b4%e3%83%aa%e3%82%ba%e3%83%a03/feed/ 0 Reteアルゴリズム(2) http://blog.iluminado.jp/2012/03/19/rete%e3%82%a2%e3%83%ab%e3%82%b4%e3%83%aa%e3%82%ba%e3%83%a02/ http://blog.iluminado.jp/2012/03/19/rete%e3%82%a2%e3%83%ab%e3%82%b4%e3%83%aa%e3%82%ba%e3%83%a02/#comments Sun, 18 Mar 2012 16:36:33 +0000 Y.Tsushima http://blog.iluminado.jp/?p=198 (前回の続き)

さて、Reteアルゴリズムは最初にルールをコンパイルしてネットワークの形に表現します。

(なお、ここではDroolsで用いられているReteOOというオリジナルReteの派生形を説明に用いますが、本質的な部分での違いはありません)。

たとえば本家サイトの方で例示しているルール(DroolsTest3.drl)をReteのネットワークにコンパイルすると、

Reteネットワーク0

となり、入口(○)が一つ、出口(●)がルール数だけある有向グラフができます。

(ちなみにDroolsのEclipseプラグインでルールファイル(.drlファイル)を表示するとReteTreeタグで上のようなReteネットワークを見ることができます)

Reteアルゴリズムは、ファクト(データ)を追加/変更/削除するたびにReteネットワークの入口から投入/チェックしていくのですが、まずはこのグラフについて最初に説明しましょう。ただ上記のルールそのままですと説明が複雑になるかと思いますので、最初にルール一つのケースから説明をします。

さて、以下のルールがあったとします。

rule “基本保険金額1″
when
契約(　$id_no : 証券番号,
基本保険金額 > 30000000
)
then
System.out.println(“証券番号 ” + $id_no + ” の基本保険金額が3000万円を超えています。”);
end

このルールは以下の形のReteネットワークとなり、

Reteネットワーク1
それぞれのノードは

  • Reteノード
    ファクトを追加する際の入り口となるノード
  • EntryPointノード
    CEP(Drools Fusion)で複数のエントリーポイントを持つことができるが、今回はデフォルトのエントリーポイントのみを使用。
  • ObjectTypeノード
    ファクトのオブジェクトタイプを識別して、フィルタとして働くノード。上記のルールでは「契約」タイプのオブジェクトを通す。
  • αノード
    条件部での制約をチェックしてフィルタとして働くノード。条件部のひとつのオブジェクトに対する制約条件ひとつがひとつのノードになる。上記の例では、「基本保険金額>30000000」がこれにあたる。
  • LeftInputAdapterノード
    βノード(後述)へのエントリーポイントとなるノード。ここまで関門をくぐり抜けてきたファクトからファクトの組(tuple)を生成する。
  • Terminalノード
    if-thenルールのthen部分にあたるノード。ここまで到達したファクト(の組)がthen部分と合わさって実行候補のリストに登録される(前回の記事の１．で言う「マッチしたルールとデータのカップルを列挙」したリストに登録されるということ)

と呼ばれます。

以上がReteのネットワークの説明ですが、単にルールをネットワーク化しただけではルールの実行サイクルを効率化することには寄与しません。そこで着目するのが、前回書いたように

「ワーキングメモリの中身が変わらなければ、マッチするファクトとルールの組も変わらない。」
「1回のルール実行では、ワーキングメモリの中身はほとんど変わらない。」

という点です。ワーキングメモリにファクトが追加されたり、ワーキングメモリのファクトを変更/削除したりした都度、今作成したReteネットワークの入り口から投入し、ルールの条件にマッチするかしないかを判定します。ここで重要なことは、ファクトとルール条件との判定はルールの実行サイクルの判定のフェーズで行われるのではなく、すでにファクトをワーキングメモリに挿入したり、変更/削除したりするときに同時に判定されるということなのです。

では、上で作成したReteネットワークにファクトを挿入してみましょう。以下の3つのファクトがワーキングメモリにinsertされるとします。

f-1．契約(証券番号=’10001′, 基本保険金額=40000000)
f-2．契約(証券番号=’10005′, 基本保険金額=20000000)
f-3．顧客(顧客番号=’10005′)

この例では、ファクトf-1のみが、ルール基本保険金額1にマッチしますから、基本保険金額1(f-1)といったルールとファクトの組が、ルール実行候補のリストに追加されるはずです。

ではまず、ファクトf-1がinsertされたとしましょう。f-1は、Reteノード、EntryPointノードを通過し、Objectノードに入ります。このObjectノードはObjectの種類が契約であるというフィルタとなっていますがf-1は条件を満たすので、そのまま通過します。次のαノードは、基本保険金額 > 30000000という判定条件ですが、f-1はこれもまた満たすので通過します。次のLeftInputAdapterノードは、次に向かう準備としてf-1をファクトの組(tuple)に変換して、最後のTerminalノードに渡します。TerminalノードではLeftInputAdapterノードでできたファクトの組とルールとを組にして(基本保険金額1(f-1))、ルール実行候補リストに追加します。

次にf-2をinsertしてみましょう。f-2は、f-1と同様に、Reteノード、EntryPointノード、Objectノードは通過しますが、αノードは基本保険金額 > 30000000という判定条件を満たさないのでこれ以上は進めません。

最後にf-3をinsertしてみると、Reteノード、EntryPointノードは通過しますが、Objectノードは条件を満たさないのでこれ以上は進みません。

以上の状況を図にすると、
Reteネットワーク1-1
となります。

(つづく)

]]> http://blog.iluminado.jp/2012/03/19/rete%e3%82%a2%e3%83%ab%e3%82%b4%e3%83%aa%e3%82%ba%e3%83%a02/feed/ 0 Reteアルゴリズム(1) http://blog.iluminado.jp/2012/03/07/rete%e3%82%a2%e3%83%ab%e3%82%b4%e3%83%aa%e3%82%ba%e3%83%a01/ http://blog.iluminado.jp/2012/03/07/rete%e3%82%a2%e3%83%ab%e3%82%b4%e3%83%aa%e3%82%ba%e3%83%a01/#comments Wed, 07 Mar 2012 13:38:34 +0000 Y.Tsushima http://blog.iluminado.jp/?p=196 今日はルールエンジンの代表的なアルゴリズムReteアルゴリズムを。
ルールエンジンのアルゴリズムにも書いたように、ルールエンジンは、

１．ワーキングメモリ(短期記憶)に入ったデータ(ファクト)の集合に対して、たくさんあるルールの条件部分をひとつひとつファクトとマッチングさせて、マッチしたルールとデータのカップルを列挙しておく。
２．カップルの中からひとつを選んで実行する。
３．実行によってワーキングメモリ(短期記憶)のファクトが書き換えられる場合もあるので、再度１．のカップリングを行う。
４．１～３を繰り返してマッチするルールがなくなったところで実行が終了する。

といったサイクルをもって実行が進んでいきます。
さてこのサイクルの １．に注目してみましょう。ここでは論理上常にルールとファクトの組を全部マッチングさせるはずです。これを真っ正直に行っていたら誰が考えても驚くほどの時間がかかってしまうのは明らかでしょう。
というわけで、このあと一生をReteアルゴリズムに捧げる(?)こととなる Charles Forgyは考えました。「確かに論理上は、ルールとファクトの組を全部マッチングさせようとするはずだが、ルールはサイクルあたりひとつしか実行されないのでワーキングメモリの内容の変更分もたかだか一つのルールで変更された分しか変わらないはず」
・・・
「ということは、最初にまとめてルールとファクトのマッチングをチェック・結果を保持しておき後は各サイクルでのワーキングメモリの差分のみをチェック・更新していけば十分なのではないだろうか」

そして彼は、このアイデアを1979年にReteアルゴリズムとしてまとめました。
(続く)

]]> http://blog.iluminado.jp/2012/03/07/rete%e3%82%a2%e3%83%ab%e3%82%b4%e3%83%aa%e3%82%ba%e3%83%a01/feed/ 0