REAとビジネスパターン入門(4)
これまで3回にわたって，モデル駆動設計を紹介してきた。「REAとビジネスパターン入門」最終回のこの記事では，これまで繰り返し登場したドメイン・ルールの役割とその可能性について考察してみよう。 ドメイン・ルール ドメインとは，問題領域とか専門領域といった意味である。したがって，ドメイン・ルールは，問題領域あるいは専門領域をモデリングするためのルールということになる。では，ドメイン・ルールを用いないモデリングというのがあるのか。実は，単にUMLを使ったモデリングというのがそれであり，多くの場合，私たちはドメイン・ルールなしでモデリングをしているのである。 UML自身もルールの固まりである。しかし，そのルールの多くは表記法や当然すぎるルールであるため，モデリングの際にそれらをあまり意識することはない。例えば，「関連の両端にはクラスがなければならない」といったルールが存在するのだが，常識的なモデリ
REAとビジネスパターン入門(3)
前回までは，個々のREAパターンについて詳細には説明しなかった。今回は，REAパターンの分類に従って具体的なパターンを紹介してみたい。REAパターンの分類はすでに「REAとビジネスパターン入門(1)」（以下，第1回）で説明したが，再度図解すると図1のようになる。 構造パターン－業務レベル アプリケーション・モデルの構造部分を決めるパターンの中で，REA（リソース，イベント，エージェント）を直接的に扱うレベルである。これらのパターンによって，ビジネスにおいて何が起きたのか，つまり実績を記録するためのモデルを作り上げることができる。 REA交換プロセス・パターンを図2に示す。 第1回で示した銀寿司の例は，構造パターンに含まれるいくつかのパターンを適用して構成したモデルだった。それに対して図2は，業務レベルの構造パターンであるREA交換プロセス・パターンだけを示してある。 一見してわかる銀寿司の
REAとビジネスパターン入門(2)
前回から，「REA（Resource，Event，Agent）による新しいモデリング手法」について説明している。REAを使うことで，得られる効果は以下の三つである。 (1)モデルがわかりやすくなる (2)モデルが作りやすくなる (3)モデルを立体的に評価できるようになる 今回は，(2)と(3)について説明しよう。 (2)モデルがつくりやすくなる REAでは，前回説明したように数多くのパターンが用意されている。特に，REAそのものである業務レベルの構造パターンは，交換そして変換（生産・分解）という，ビジネスの世界に密接に結びついたプロセスのパターンから構成されている。そのため，業務レベルの構造パターンを適用するためには，まず問題領域のREAに着目すればよい。つまり，その分野のリソース，イベント，エージェントに着目すればよいのだ。 REAでは，モデリングのためのルールがしっかり決まっているため
REAとビジネスパターン入門(1)
コンサルティング業の片手間に，翻訳業をしている。ここしばらく作品がなかったのだが，今月（2007年8月）は2冊の監修・監訳作業を終えることが出来た。1冊は，まもなく発売される予定の『実践UML 第3版』。もう一冊は，日経BPソフトプレス発行の『ビジネスパターンによるモデル駆動設計』（以下，『モデル駆動設計』と呼ぶ）である。 『モデル駆動設計』のほうが，ちょうど書店に並び始めたので，今回は，そこに登場するREAという概念と，モデル駆動設計の方法について紹介してみたい。翻訳作業が終わって1カ月あまりになるが，この原稿の準備をするなかで，あらためてわかったこの書籍のおもしろみや，類書との類似点や相違点についても触れてみたい。 REAとは何か 『モデル駆動設計』の副題は「REAによる新しいモデリング手法」である。REAとは，リソース（Resource)，イベント（Event），エージェント（Age
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
REA Technology - Technology That Understands Your Business