REAとビジネスパターン入門(1)

　コンサルティング業の片手間に，翻訳業をしている。ここしばらく作品がなかったのだが，今月（2007年8月）は2冊の監修・監訳作業を終えることが出来た。1冊は，まもなく発売される予定の『実践UML 第3版』。もう一冊は，日経BPソフトプレス発行の『ビジネスパターンによるモデル駆動設計』（以下，『モデル駆動設計』と呼ぶ）である。

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

　『モデル駆動設計』のほうが，ちょうど書店に並び始めたので，今回は，そこに登場するREAという概念と，モデル駆動設計の方法について紹介してみたい。翻訳作業が終わって1カ月あまりになるが，この原稿の準備をするなかで，あらためてわかったこの書籍のおもしろみや，類書との類似点や相違点についても触れてみたい。

REAとは何か

　『モデル駆動設計』の副題は「REAによる新しいモデリング手法」である。REAとは，リソース（Resource)，イベント（Event），エージェント（Agent）の三つの単語の頭文字をつなげたものだ。正確には，これらの単語には「経済」という言葉を付けるのが正しい。つまり，これらの単語は私たちの経済行為，あるいはビジネス活動に登場する，リソース，イベント，エージェントを意味している。これから説明するそれらの具体例は，どれも私たちの身近な概念だ。

　REAは，モデルの材料となるもの，つまりモデリング要素なのであるが，REA以外にもモデリング要素があり，それらが様々なパターンを構成する。そしてREAのユーザー，つまりモデラーは，その様々なパターンを駆使して，対象アプリケーションのモデルを構築することになる。

　パターンには，構造パターンと振る舞いパターンの二つがあり，構造パターンはさらに二つのレベルに分かれる。業務レベルと方針レベルである。REAは，より基本的なレベルである業務レベルに位置している。業務レベルには4個，方針レベルには9個，振る舞いパターンとしては13個が定義されている（図1）。

図1●パターンの全体像 [画像のクリックで拡大表示]

REAによる販売システムのモデル

　REAを身近に感じることができるよう，REAにもとづいたアプリケーション・モデルの例を紹介する（図2）。これは，受注をともなう販売システムの典型的なケースに対して，業務レベル・パターンの一つである交換プロセス・パターンを適用して得られるモデルである。

　『モデル駆動設計』には，Joeという名のピザ屋の例として，ほぼこれと同じモデルが登場する。本稿では，ひと味加えて，ピザ屋を「銀寿司」という架空の寿司屋に変更してみた。

図2●REAモデル（架空の寿司屋）の例 [画像のクリックで拡大表示]

　REAのモデリングでもUMLを用いる。図2は見ての通りクラス図であり，ボックスはクラス，<<契約>>などは，ステレオタイプ（モデル要素の種別）を表している。図2は，大きな二つの矩形領域で上下に分けられている。上の領域に属している部分が，前述した方針レベルのパターンに，下の領域に属している部分が業務レベルのパターンに対応している。

　業務レベルのクラスに付けられたステレオタイプには，リソース，イベント（増加イベント/減少イベント），エージェントの3種類がある。この3種類のステレオタイプが表すクラスの種別が，REA（Resource，Event，Agent）なのである。以下では，『モデル駆動設計』に合わせて，アプリケーション・モデル上のボックスを，クラスではなく，エンティティと呼ぶ。

　REAの構造図には特徴があり，それに慣れるのに少々時間がかかる。図2の説明を続けよう。

• 「現金の受領」という増加イベントによって，「現金」というリソースが流入する
• その流入する「現金」リソースは，「顧客」というエージェントが供給し，「銀寿司」というエージェントが受領する
• 「販売」という減少イベントによって，「にぎり寿司」というリソースが流出する
• 流出する「にぎり寿司」は，「銀寿司」が供給し，「顧客」が受領する

　「銀寿司」と「顧客」は，ともにエージェントである。また，増加イベントと，減少イベントは，必ず両方が同時に存在しなければならない。これを「交換の双対性」と言い，エンティティ同士の関連のステレオタイプになっている。

　ここで概念レベルのクラス図に慣れた人は，多少の疑問なり，違和感を持つことだろう。例えば，「流入」「流出」，あるいは「増加（イベント）」「減少（イベント）」などの言葉は，しっくり来るだろうか。

　筆者は概念モデリングの経験が長いが，常に客観的な言葉遣いをするように心がけている。客観的とは，同じモデルが，見る人によって意味があったり無かったりするような言葉遣いはしないということだ。「流入」「流出」と言っても，「入」か「出」かは，相対的なものだ。また，にぎり寿司の販売によって，「現金が増加」し，「にぎり寿司が減少」するということは，このモデルは，銀寿司の立場にしか立っていないのだろうか。

　結論から言うと，図2は，銀寿司の立場から描かれているのである。そのため，銀寿司ではなく，顧客の立場に立ったモデルが必要ならば，言葉遣いが図2のそれと反対になったクラス図を描くことになるのだ。そうすることによって，リソース系のエンティティは冗長に存在することになるので，冗長なエンティティのペアに対しては，互いに等価であることを図に示すことになる。

　クラス図の立場を切り替えるといっても，それによってそれぞれのクラス図でエンティティの形が変わるわけではない。単に，エンティティ名や関連名の言葉が変わるだけだ。「本当にそうか」と思われた読者は，練習にもなるので，トライしてみると良いだろう。

　冗長なクラス図と言ったが，その冗長性を排除することもできる。そのためには，中立的な言葉遣いをすれば良いだけである。その結果，クラス図には，銀寿司や，顧客といった領域の区別がない一つクラス図ができあがる。

　当初，筆者は「偏り」のあるクラス図になじめずに“どうして中立な表現にしないのか”と思ったものであるが，現在はこの「偏り」が気に入っている。なぜなら，ユーザーとモデルを共有するためには，「偏り」のあるクラス図のほうが，便利だと思うからだ。

　中立的なモデルは，ユーザーと一緒に汗を流す上流工程ではそれほどありがたいものではない。寿司屋さんから見れば，販売によって現金が「流入する」モデルこそ，リアルで親しみがわくと思うのだが，読者の意見はどうだろうか。

　REAモデルに対して抱く初期の疑問として，前述した交換の双対性に関することがあるだろう。交換の双対性によって接続される増加イベントと減少イベントは，必ず同時に発生しなければならないと書いた。それは，何かを売れば同時にその対価として現金がもらえることを意味している。しかし，それがビジネスの世界で常に成立しないことは誰でも知っている。銀寿司の例にしたところで，寿司を注文したときには支払わず，晦日（みそか）や大晦日にまとめてという客がいるかもしれない。

　増加イベントと減少イベントが同時に発生しない場合は，アンバランスが生じる。そのアンバランスが請求権という権利の存在を表すことになる。そして，その権利を行使するのが請求書の発行という行為であり，そのあたりを説明するのが，方針パターンの一つ，「実体化した請求権」だ。