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

　前回までは，個々のREAパターンについて詳細には説明しなかった。今回は，REAパターンの分類に従って具体的なパターンを紹介してみたい。REAパターンの分類はすでに「REAとビジネスパターン入門(1)」（以下，第1回）で説明したが，再度図解すると図1のようになる。

図1●REAパターンの分類

構造パターン－業務レベル

　アプリケーション・モデルの構造部分を決めるパターンの中で，REA（リソース，イベント，エージェント）を直接的に扱うレベルである。これらのパターンによって，ビジネスにおいて何が起きたのか，つまり実績を記録するためのモデルを作り上げることができる。

　REA交換プロセス・パターンを図2に示す。

図2●REA交換プロセス・パターン [画像のクリックで拡大表示]

　第1回で示した銀寿司の例は，構造パターンに含まれるいくつかのパターンを適用して構成したモデルだった。それに対して図2は，業務レベルの構造パターンであるREA交換プロセス・パターンだけを示してある。

　一見してわかる銀寿司の例と図2との違いは，エージェント・エンティティやリソース・エンティティが一つしか存在していないということである。パターンとしてはこのような形式だけでなく，エージェントを供給側，受領側といった役割に応じて別々のエンティティに分け，またリソースを交換されるものごとに異なるエンティティとしている表現している例もよく登場する。どちらがパターンとして正しいのかは迷うところであるが，図2の形式が正式な書き方のようである。

　図2には制約が存在する。それは「増加/減少経済イベントから見て，受領と供給という二つの関連を通じてリンクするエージェントが同一ではいけない」ということ。さらに，「交換の双対性で関連している増加/減少経済イベントからリンクする経済リソースは同一ではいけない」ということだ。これらはクラス図では表現できない。したがって，正確にこれらの制約を表現するならば，オブジェクト制約言語（OCL：Object Constraints Language）などの利用が必要となる。しかし，モデル駆動設計ではすべてクラス図上のコメントとしてそれらが示されている。

　業務レベルの構造パターンとしては，すでに説明しているようにREA交換プロセス・パターン以外に，REA変換プロセス・パターンとバリューチェーン・パターンが存在する。

構造パターン－方針レベル

　これは業務レベルと同様に，アプリケーション・モデルの構造部分を決めるパターンである。しかし，業務レベルと異なり，何が起こりえるか，起こるべきか，起こるべきではないかを表現するモデルを作り上げるためのパターンである。

　もちろん，これらは未来予測をする方法の話ではない。REAの世界で何かが起きるとは何らかのイベントが発生することに他ならない。アプリケーションの外部で発生する様々な事象をイベントとして格納しようとしたときに，どのようなイベントの格納を許し，また許さないかということを判断しなければならない。方針レベルの構造パターンは，そのような判断の根拠を与えるモデリングを支援するものである。

　方針レベルとしてはコミットメント・パターンを紹介しておこう。

図3●コミットメント・パターン（背景色がある部分） [画像のクリックで拡大表示]

　図3は，第1回の銀寿司の例とほぼ同じモデルを，若干異なる観点と方法で示したものだ。この図の中で薄くグレーの背景をつけている部分がコミットメント・パターンに相当する部分である。

　コミットメント・パターンは，増加コミットメントと減少コミットメントを，履行というステレオタイプを持つ関連によってそれぞれ増加経済イベントと減少経済イベントに接続する。また，増加コミットメントと減少コミットメントは，交換の双対性というステレオタイプを持つ関連で結ばれる。さらに，増加コミットメントと減少コミットメントは，新しく登場する経済リソースタイプ・エンティティに，それぞれ流入の予約，流出の予約というステレオタイプを持つ関連によって接続される。

　コミットメントとは将来に対する約束であり，コミットメント・パターンは増加経済イベントまたは減少経済イベントの未来形ということができる。このコミットメント・パターンによって，ビジネスに必要な約束，取り決め，あるいは契約という世界を表現する。

　新しく登場した経済リソースタイプ・エンティティは，コミットメントのために登場した概念である。経済リソース自身は実在するものであり，約束や取り決めをしている段階であらかじめ知ることはできない。そのため実在するもののタイプ（型）として経済リソースタイプ・エンティティが必要となるのである。

　第1回に示した銀寿司の例は，REA交換プロセス・パターン，コミットメント・パターン，そして契約パターンという三つのパターンによって構築されたアプリケーション・モデルである。

振る舞いパターン

　振る舞いとは，アプリケーション・システムの動作のことである。これまで振る舞いレベルのパターンについてほとんど触れなかったので，少し詳しく説明しよう。

　図1に示したようにモデル駆動設計では，パターンの分類として構造パターンと振る舞いパターンの二種類がある。そのため，著名な「オブジェクト指向における再利用のためのデザインパターン」（ソフトバンククリエイティブ発行）で示されているパターンの分類基準である生成，構造，振る舞いの三種と比較すると，生成パターンが足りないということになる。

　モデル駆動設計における振る舞いパターンは，後述するアスペクト指向の考え方によってそのまま実装されていくパターンである。そのため生成パターンは，振る舞いパターンと明確に区別することが困難ということがその理由ではないかと筆者は想像する。

　振る舞いのパターンは，オブジェクトが協調する方法を示すことで，アプリケーションの動作を表現する。つまり振る舞いパターンは，構造パターン（業務レベル＋方針レベル）によって組み上げられたエンティティとそれらの関連から成る構造に対して，オブジェクトが協調動作する方法をパターンとして与え，アプリケーションに息を吹き込む役割を持つ。この協調動作の表現にアスペクト指向を利用する。

図4●パターンを説明するクラス図の例 [画像のクリックで拡大表示]

　図4は，パターンを説明するクラス図である。図中のグループは，方針レベルの構造パターンであるグループ・パターンで説明されているエンティティであり，集合を扱うエンティティである。ここでは，REAエンティティのグループを意味する。

　方針レベルのパターンとしては，グループ・エンティティとREAエンティティの関連が説明されているだけであり，このままではREAエンティティを一意に識別したり，識別子を与えたりすることができない。そのため図4に示すような識別子セットアップと識別子というクラスを別途与える必要がある。そして，この識別子セットアップや識別子に，識別子の生成やそのための基本となる仕組みを実行させるのである。

　識別子の生成や一意性の維持の仕組みは，構造モデルの特定の部分に必要なわけではない。これらは横断的関心事であり，モデルのあちこちに異なる条件で必要とされる。異なる条件とは，例えば，ある部分では識別子の一意性が必要で，ある部分では必要とされない，といった条件のことである。

　モデル駆動設計では，アプリケーション・モデルに対するメタレベルとして，アスペクトタイプを定義し，そのインスタンス（つまりアプリケーション・レベルのクラス）をREAエンティティやその他のアプリケーション・エンティティに対して装着する。

図5●アスペクトタイプを定義し，そのインスタンスをREAエンティティやその他のアプリケーション・エンティティに対して装着する [画像のクリックで拡大表示]

　図5では，アスペクトタイプに定義されている識別アスペクト，識別子タイプ，識別子セットアップ・タイプという構造に対してデータを与える。そうすることによって，特定の識別子について自動ナンバリングが必要かとか，一意性がなければならないといったことを定める。その定義によってアプリケーション・モデルが拡張され，REAエンティティの識別に必要な振る舞いが与えられるのである。

　次回は，REAとビジネスパターン入門の最終回となる。モデル駆動設計の特筆すべき点として筆者が考えているドメイン・ルールについて解説する。

（依田 智夫＝要求開発アライアンス理事）