オントロジー(2)

そもそもビジネスルールは、その if 部分とワーキングメモリ(一時記憶)の中のファクトとが「パターンマッチ」されることで実行が進んでいくわけで、ファクトの「パターン(文字列)」はきちんと規定されている必要があります。さらにファクトの意味が同じファクト(パターン・・・文字列)に対してブレてしまうと、それぞれのビジネスルールの意味も変わってきてしまうので、ファクトの意味についても厳密に定義されていなければなりません。

ファクトのパターンとその意味が厳密に規定されたモデル・・・ファクトモデルは、このようにビジネスルールのシステムの基盤として非常に重要な存在です。さらにビジネスルールを用いたアプリケーションシステムが多数存在する、「企業」のレベルまで考えを拡げてみましょう。すると、これらビジネスルールの基盤となるファクトモデルは「企業」のレベルで共通のものになっていないとアプリケーションシステム間の相互運用性が保証されないことになってしまいます。

さて、(1)の項でファクトモデルがオントロジーにあたると書きました。すると「企業」のレベルで共通のものになっているファクトモデルとは、「企業」オントロジー・・・エンタープライズ・オントロジーということになります。

実はエンタープライズ・オントロジーというのは、オントロジー研究の中で昔から言われており、古くはエジンバラ大学の応用人工知能研究所研究トロント大学のエンタープライズインテグレーション研究所TOVEプロジェクトなどから、最近は成書も出ていたり、セマンティックWebの観点から注目されたりしてします。

ビジネスルールの世界は実践重視の世界なので敢えてオントロジーという言葉はあまり出てきませんでしたが(この辺の事情は、たとえばBusiness Rules in the Semantic Webなどを参照)、昨年あたりからEUのONTORULEプロジェクトなどというのが出てきたりしています。このプロジェクト、ONTOlogies meet business RULEs という名前が示すとおりオントロジーを基盤としてビジネスルールを用いたシステムを具体化していくプロジェクトです。いよいよオントロジーがビジネスルールの世界で俎上にのぼってきたということでしょうか。



オントロジー(1)

元ジャストシステム社長の浮川さんが作った会社MetaMojiからOntoGearというオントロジー工学をベースにしたツールが公開されるとのこと。

元ジャストシステム浮川氏のMetaMoJi、初の製品となる「OntoGear」を5月に公開

久しぶりに「オントロジー」という言葉をプレスリリースなどで見て勉強しなければ・・・と思った次第。というのも、この「オントロジー(ontology)」、ビジネスルールアプローチやBRMSと非常に関連がありまして・・・(もっとも「OntoGear」というツールはBRMSやBRAというよりもむしろ応用人工知能的なツールです)。

「オントロジー」とはもともと「存在論」という意味の哲学用語ですが、コンピュータの世界で使われるときには物事・概念の間の関係性を記述したモデルとでも言うのでしょうか。イメージ的には、用語間の関係としてみたクラス図とか概念データモデルというと近いかもしれません(実際のオントロジーの実例としては「法造~オントロジー構築・利用の研究サイト~」などを見てもらえばよいかと)。

で、オントロジーをビジネスルール(BRA、BRMS)の世界に持ってくると、これが実はファクトのモデル(fact model)になるわけです。実際、ビジネスルールを書いていく上での基盤となるファクトモデルは、ビジネスルールが対象とするドメインのオントロジーといえます。たとえば企業活動というドメインを考えた場合、まず用語としては「顧客」「注文」「従業員」・・・などがあげられ、その関係性としてのファクトは、「顧客は注文を出す」、「従業員には性別がある」・・・などといったことになりましょう。

(この項続く)

Decision Model

先日、アマゾンに昨年春くらいに予約したまま、ほとんど忘れかけていた本が届きました。Barbara von Halle と Larry Goldberg の「The Decision Model」 という本。データにデータモデル(リレーショナルモデル)があるように、ビジネスのデシジョン(~ビジネスロジック・ビジネスルール)にもデシジョンモデルがあるべきであるとし、そのデシジョンモデルがどのようなものであるか、どうあるべきか具体的なモデルの記法なども含め説明しています。
データは、リレーショナルモデルという理論的に整備されたモデルがあることによりデータの独立性を確立したとし、そのアナロジーから、ビジネスロジックについても、その理論的な背景を明らかにした技術に依存しないモデルを確立して、ビジネスロジックの独立性を確かにしていこうという趣旨のようです。
まだきちんと読んだというわけではないのですが、このデシジョンモデルは、リレーショナルモデルと同様、正規形があったり、動機だけでなく、その構造や手続きについてもリレーショナルモデルと類似の面がある様子。もっとも、ロジックの冗長性をなくし、原子性(atomic)を求めようとすると必然、正規化のような手続きが出てくるのでしょう。
また、後ろのほうの章では、EAのZachmanや、EDMのJames Taylorなどが書いているところもあったり・・・。

これからぼちぼち読んでいくつもり。



ビジネスルールアプローチ(1)

ビジネスルールアプローチ(BRA)というと、何か特別な革命的な方法論があるのか・・・と考える方もいらっしゃるかもしれません。が、むしろ従来からの方法論の漸進的な改善と見たほうが実態を表しているように思います。ビジネスルールとは、端的に言えばビジネスのロジックや制約をルールの形で表したものであるので、システム開発の現場においてビジネスルールが対象とするべきビジネス仕様そのものは、昔から何らかの形で捉えられていたはずです。実際、ビジネスルールを抽出する一つの方法として「レガシーシステムのコードからリバースして抽出する」というのがあるくらいですから、ビジネス仕様は、ルールの形として明示的に捉えられていなかったにしろ認識はされていました。

では、ビジネスルールアプローチと従来の方法論との違いはどこにあるのか・・・というと、「ビジネスルールを明確に意識した開発」かどうかということにつきると言えます。とは言え、これだけでは何のことやらサッパリでしょうから、もう少し噛み砕いていきましょう。Barbara von Halleは、その著書“Business Rules Applied”の中でBRAの原則として次のSTEP原則というのをあげています。

  • Separate rules(ルールを分離せよ)
  • Trace rules(ルールがトレースできるようにせよ)
  • Externalize rules(ルールを外部化せよ)
  • Position rules for change(変更を前提にルールを配置せよ)

それぞれをもうちょっと解説すると

  • Separate・・・ビジネスルールを他のシステム要件から明確に分離することで
    ルールを再利用したり、他のシステム要件から独立して変更したりできる。
  • Trace・・・個々のビジネスルールに対して、その拠って立つビジネスの動機
    (ミッション、ゴール、目的、戦略、戦術、ポリシーなど)へとトレースできる一方、
    そのビジネスルールの実装形へも明確にトレースできる。これにより、ルールの
    正当性が保証でき、またルールを変更したときの影響度合いがわかりやすく
    なる。
  • Externalize・・・ルールを誰にもわかるようなフォーマットで公開すること
    によって、ビジネスを動かしているルールが何であるのか一目瞭然となる。
    今流行りの言葉で言えば、ルールの「見える化」である。
  • Position・・・ルールを容易に変更できるような環境においておくこと。これは
    昨今のビジネス環境の変化の速さを考えれば、当然ビジネスルールの変更
    要請も頻繁になることが想定され、ある意味当然のことと言える。

個人的には、このうち特に”Trace”がポイントなのかなあと思っています。システム開発というと、「そもそもこのシステム要件は何のためのもの?」ってことが存外にあったり(→こんなことがあまりに多ければプロジェクトは失敗ということになってしまいますが)、プロジェクトが進んで実装の段階になると、「プログラムのこの部分はそもそもどんな要件から来ているのか?」というトレースがしんどかったり・・・皆様も経験があるかとおもいます。

従来の感覚ですと、このようにビジネスの動機と実装との間にはかなりのギャップがあり、それを埋めるためには結構な意志と努力が必要です。が、BRAでは、ビジネス仕様をルールで表現することによって、このギャップを軽減し比較的容易にビジネスの動機と実装との間のトレースができるようになります・・・というのが上記「Trace」の意味。これがきちんとできるということはそれだけでも結構魅力。

さて本題に戻ると、von Halleは、著書で、上記の原則に則ってシステム開発の方法論としてのBRAを展開しています。次回は、具体的なBRAの方法論をと行きたいところですが、その前にそもそもビジネスルールとは?といったところをまとめてみたいとおもいます。

BRA(ビジネスルールアプローチ)とBRMS

「ビジネスルールアプローチ(以下BRA)」・・・最近、時々聞かれるようになった言葉ですが、結局いったい何なのかよくわからない方も多いのではないでしょうか。実際、人によって、状況によってその意味するところが若干違う(ように思える)ところもそれに拍車をかけています。実は、姉妹サイトでの「ビジネスルール2つの視点」という記事にも似たようなことを書いているのですが、BRAという言葉を使う場合、ビジネスルールを利用した開発のうち
①BRMSツールでの実装を強調した場合に使う
こともあれば、より上流の
②ルールによる仕様の記述というところを強調した方法論に対して使う
こともあります。

ところでBRAの中の「ビジネスルール」という言葉・概念。この言葉そのものは、一般の要求定義の中でも使われれるように特にツールとしてのBRMSとは関係はありません。たとえば要求定義やユースケースの解説書などでもビジネスルールに1章が割かれていたりします(たとえば「ソフトウェア要求」・・・末尾参照)。②の意味でのBRAはこの意味での「ビジネスルール」に焦点をあて、データ分析やプロセス分析と同じレベルでルール分析を取りあげていこうとする方法論であり、そのルール分析では、ルールを仕様のコア部分として認め、他の要素(データやプロセス)とは意識的に区分して厳密に扱っていこうとするものです。Ross やVon Halleの提唱しているBRAは、この範疇に入ります。

この②の意味でのBRAの歴史を紐解いてみる(A Brief History of the Business Rule Approach-BRCommunity)と、「BRA」といった言葉がなかった90年前後に、すでにその源流が始まっています。そこでは概念データモデルのモデリングで制約などをルールの形でまとめようとしていました。その後、ルールの記述範囲がモデルの制約だけでなく、推論の規則や計算規則などにも拡げられるとともに、記述方法も洗練され、述語論理を基盤とした、項(ターム)、ファクトを要素とした記述となっていきます。実は上に上げた要求定義の解説書に表れている「ビジネスルール」という言葉は、逆にこのBRAを作っていく中から生まれたといってもよいでしょう(ちなみに余談ですが、世界的に有名なデータベースの教科書『データベースシステム概論』を著したC.Dateもビジネスルールアプローチに関する本(What Not How)を書いています・・・末尾参照)。

このようにもともとのBRAは、ソフトウェアツールとしてのBRMSとは全く独立してビジネスを分析していく中から誕生しました(このことは、上に上げたBRAの歴史にも強調されています)。その一方で、ツールとしてのBRMSは、エキスパートシステムの作成などを通じてだんだんと洗練されてきています。そして今、BRMSで用いられているルールベース言語の宣言性、述語論理との親和性からBRAで書かれた実装系としてBRMSが使われるようになったということでしょうか。

(もっともRossVon Halleなどの本で扱われているBRAは、ほとんど「ルール原理主義(?)」的な、かなりがちがちのルールアプローチです。したがってBRAの方法論としてはともかく、現実のBRA適用としては今のところもう少し緩和した上記で言う①寄りの形が主流でしょう)