PR

 これまで3回にわたって,モデル駆動設計を紹介してきた。「REAとビジネスパターン入門」最終回のこの記事では,これまで繰り返し登場したドメイン・ルールの役割とその可能性について考察してみよう。

ドメイン・ルール

 ドメインとは,問題領域とか専門領域といった意味である。したがって,ドメイン・ルールは,問題領域あるいは専門領域をモデリングするためのルールということになる。では,ドメイン・ルールを用いないモデリングというのがあるのか。実は,単にUMLを使ったモデリングというのがそれであり,多くの場合,私たちはドメイン・ルールなしでモデリングをしているのである。

 UML自身もルールの固まりである。しかし,そのルールの多くは表記法や当然すぎるルールであるため,モデリングの際にそれらをあまり意識することはない。例えば,「関連の両端にはクラスがなければならない」といったルールが存在するのだが,常識的なモデリングでは自然にそれらが守られている。

 REAに登場するドメイン・ルールを紹介する前に,REAモデルの基本的な考え方を知る必要がある。それは以下のようなものである。

●企業が,その制御下にあるリソース全体の価値を増加させたい場合,通常はいくつかのリソースの価値を減少させなければならない。

 すでに説明した通り,リソースを増加させたり減少させたりする行為が交換と変換である。このREAモデルの基本的な考えに基づいて,ドメイン・ルールが登場する。以下に示すのが,REA交換プロセスをモデリングするためのドメイン・ルールである。

(A)あらゆる増加経済イベントは,交換の双対性にしたがって,一つの減少経済イベントに関連しなければならない。
(B)あらゆる増加経済イベントは,流入関係により,一つの経済リソースに関連しなければならない。
(C)あらゆる減少経済イベントは,流出関係により,一つの経済リソースに関連しなければならない。
(D)あらゆる経済イベントは,供給関係によって一つの経済エージェントに,また受領関係によって一つの経済エージェントに関連しなければならない。実行時には,これら二つのエージェントが異なる経済的利益を持つ異なるエンティティを表さなければならない。

 具体的なモデルとして,第1回で説明した銀寿司のアプリケーション・モデルを再度示す。

図1●銀寿司のアプリケーション・モデル。ドメイン・ルールの記号を記入した
図1●銀寿司のアプリケーション・モデル。ドメイン・ルールの記号を記入した
[画像のクリックで拡大表示]

 第1回との違いは,図中に上記ドメイン・ルールの記号を記入した点である。ルールDについては,増加経済イベント側をD-1,減少経済イベント側をD-2とした。また,上記ドメイン・ルールはモデルにおける多重度について言及しているが,図中では省略し,さらに第1回と比べてクラス名などをよりわかりやすくしている。なお,銀寿司と顧客を異なるエンティティとしてモデリングしているため,それらのインスタンスが同一になることはない。したがってルールDの後半部分は自動的に満足されることになる。

 さて,このようなドメイン・ルールはなぜ必要なのだろうか。

 ドメイン・ルールAが存在しなければ,例えば,減少経済イベント側(にぎり寿司の販売)のみをモデリングして,増加経済イベント側(にぎり寿司)のモデリングをおろそかにするなどといったことが起きえる。ドメイン・ルールは当然のことを言っていると思えるが,モデリングの現場でそれが当然のこととみなされる保証はない。

 また,ルールBおよびCにより,イベントに関連するリソースが必ずモデリングされることとなる。同様にルールAの存在によって,交換の対象となる一組のリソースが必ずモデリングされることになる。これらによって,第1回で説明したバリューチェーン・モデルが必ず描けることになる。

 最後にルールDに従うことで,すべての経済イベントに登場する経済リソースに関して,それを供給する人や組織,また受領する人や組織が必ずモデル化される。これによって,人・組織についての分析や調査の漏れがなくなり,イベントの関係者が常にモデル上で明瞭に示されることになる。これらが調査分析活動の対象から漏れると,後から調査分析するのは大変である。また,特に社内や工場内に関するこれら人・組織のモデルは,きめ細かく業務を支援するアプリケーションのモデル作りには不可欠のものである。

ドメイン・ルールによるモデリングの意義

 上記のように,ドメイン・ルールによってビジネス・アプリケーション開発の勘所を確実に押さえたモデリングが可能になる。しかし,勘所を押さえたモデリングを支援するための仕組みであれば,似たような試みがこれまでにもあった。

 ピーター・コード(Peter Coad)らによる『戦略とパターンによるビジネスオブジェクトモデル』(ピアソンエデュケーション発行)では,ビジネス・アプリケーションのモデリングに参考になる様々な構造図の断片を紹介している。また,筆者も親しくしているジム・アーロウ(Jim Arlow)が著書『Enterprise Patterns and MDA』(Addison Wesley発行)で紹介しているArchetype Patternは,それを多少修正して使うことで,受発注システムをはじめとするアプリケーション・モデルが構築可能になるモデル・ライブラリの部品である(Jim Arlowについては,筆者のブログをお読みいただければ幸いである)。

 では,ドメイン・ルールによるモデリングと,これらアプリケーションの断片,あるいはモデルの部品を与えるアプローチとの相違は何か。

 それは,メタな世界が存在しているか否か,別の言い方をすれば,オントロジ(Ontology)を活用しているかどうかという点の相違なのだ。オントロジの活用により,通常のモデリングの世界に対してさらに上位の世界,つまりメタモデル(メタデータ)を定義できるようになる。その結果,アプリケーション・モデルには,普遍的なルールに基づくモデルという特性が加わることとなる。前述のひな型的アプローチにはメタモデルが存在しないため,アプリケーション・モデルの部分部分,そしてそれらから構成される全体は,常にある意味気ままであり,どうにでもすることができる。

 オントロジとメタモデルにより,モデリングは一定の品質を持ち,またモデリング作業は,メタモデルから来る制約によって堅苦しくなる半面で楽になる。なぜなら,メタモデルにおいてあらかじめ定められているルールが,モデリングをガイドしてくれるからである。このルールこそがドメイン・ルールである。

 また,ドメイン・ルールによって制約されたモデルは,ソフトウエア開発における工程間連携プレイの媒体となる。筆者は,ビジネスモデリング道場に寄稿するのは二回目だが,第一回目の寄稿「要求開発でシステム開発の生産性を上げる」で言いたかったのはまさにこの点である。そのときには具体的な方法を十分説明することができなかったが,モデル駆動設計との出会いで一つの道が開けた気がしている。

 ところで,ドメイン・ルールの数には上限があるのだろうか。言い換えれば,ある一定数のドメイン・ルールがあれば十分という状態はあり得るのだろうか。

 おそらくこの答えはNoだろうと筆者は考えている。図2に示したのは,筆者がモデル駆動設計の例を見て考案したレンタル契約のパターン例である。パターンのつもりであるから,エンティティ名が,実際のモデルではエンティティのステレオタイプということになる。通常ならイベントというべきところをレンタル・イベントと呼び,エージェントをレンタル物件所有者やレンタル物件使用者などと呼んでいる。

図2●レンタル契約のパターン例
図2●レンタル契約のパターン例
[画像のクリックで拡大表示]

 このパターンがあれば,レンタル契約のためのモデルはより作りやすくなる。また,「レンタル物件利用権は契約終了後,レンタル物件所有者に返還される」など,独自の意味付けを与えることができる。さらに,このような複雑なイベントであるレンタル・イベントについて,契約と条項が不可欠というドメイン・ルールを付け加えることもできるだろう。

ビジネスパターンによるモデル駆動設計
Pavel Hruby 著
依田 智夫 監修
溝口真理子/依田光江 訳
日経BPソフトプレス 発行
2007年8月
4935円(税込)

 ドメイン・ルールに限界を与えないということは,メタモデルにも限界がないということだ。メタモデルに限界を与えず,いくらでも専門的なものを構築可能とすることで,専門的なモデリングはますます簡単になっていく。上記のレンタル契約パターンを利用して,同一モデル上で不動産賃貸とPCレンタルを同時に即座にモデリングできるかもしれない。

 単純なREAに限らず,レンタル・イベントのような専門的なエンティティについて,メタモデルとドメイン・ルールを必要に応じて構築できるようにすることはきわめて意義のあることと考えている。それが,モデル駆動設計の著者を始めREAの実践者達の目指すところかどうかはよくわからない。

 しかしながら,筆者としてはこの観点こそUMLの拡張やDSL(ドメイン特定言語)の目指すところであり,ぜひとも活用していきたいと考えている。筆者は民間と政府でシステム開発を支援する仕事をしているが,官民を問わずパターンの活用は有用であり,そのためには使い勝手のよいツールがぜひとも必要と考えている。

 最後になるが,10月24日にマイクロソフトの新宿オフィスにて,REAについての講演を予定しているのでお知らせしておきたい。内容は今回の記事と重複するが,さらにビジネス・アプリケーション設計を変革するモデリング技法との観点で内容を補足し,REAについての新しい情報も紹介するつもりである。

(依田 智夫=要求開発アライアンス理事)