REA セミナー

第64回 MSDN オフラインセミナー
ビジネスアプリケーション設計を変革するモデリング技法 (REA)
13:30-15:30
マイクロソフト(株) 新宿オフィス

id:aufheben:20070930:1191166990 で紹介した「ビジネスパターンによるモデル駆動設計」の監訳者、依田さんによる REA のセミナーを受講してきた。

ビジネスパターンによるモデル駆動設計

ビジネスパターンによるモデル駆動設計

REA (あーる・いー・えー) とは?

前のエントリでも書きましたが、REA (Resource: リソース、Event: イベント、Agent: エージェント) をベースにしたモデリング技法、パターン。
なぜその業務を行うのか? なぜそのイベントが発生したのか? という why の視点がモデル化されている点が興味深い。

セミナーの内容は、IT Pro の記事、

とほぼ同じなので、まずはそちらをご覧ください。


少しだけ補足。
REA の用途として、主に以下の3つが考えられる。

  • 会計のモデリング
    … そもそも REA は、会計のためのデータモデルとして、ミシガン州立大学の William E. McCarthy によって1982年に提案された。
  • 標準化の基盤
    … ebXML や Open-edi (ISO/IEC 15944-4) のベースとなっている。
  • 上流のビジネスモデリング
    … 依田さんも参加されている要求開発などで。

特に3番目の上流のビジネスモデリングで今後実践を重ねていきたいとのこと。
バリューチェーンが表現されているので、ユーザと会話ができる。

また、記事にも書かれているが、REA のメリットとして、以下の3点を挙げられていた。

  1. モデルがわかりやすくなる
    … クラス名はその時々によって変わるが、オントロジー (概念) は不変。
  2. モデルが作りやすくなる
    … ルールが明確なので迷わずにどんどん書ける。
  3. モデルを立体的に評価できるようになる
    … 実際に REA で書かなくても、評価視点として使える。

質疑応答など

セミナー中、およびセミナー後に何点か質問をさせていただきました。

Q.寿司や現金のように単位が曖昧な場合、経済リソースのインスタンスはどういう単位で定義するか?
A.あまり厳密に考えられていないかも。ドメインルールが満たされていればどんな単位でも良い。
Q.識別子タイプと識別子セットアップタイプの関連が 1..* - 1 であることに違和感があるのはなぜ?
A.きちんと理解できていないかもしれない。

この件に関しては、書籍の P.169 の例を見ると、1..* - 1 で合っていると思います。


その他、思ったことなど。

  • 経済イベントを増加イベント、減少イベントと分けて考えるならば、経済エージェントも視点となるエージェント (企業とか) とそれ以外を分けた方がわかりやすくないか?
  • 銀寿司のクラス図と REA 交換パターンのクラス図でエージェントやリソースの数が違うのは、メタなレベルが違うからですよね。MOF でいうと M1 と M2。
  • カラーUML の「役割」に相当する部分は、振る舞いパターンで実現されているのでは? アスペクトで実装すれば、「パーティ/場所/もの」と分離できます。
  • 振る舞いパターンの「説明」「注釈」は、カラーUML の「説明」とは別物だと思う。
  • レンタルイベントのパターンの追加のお話があったが、オントロジーのレベルでは追加しない方が良くないか。書籍の第8章にあるように、例題のバリエーションを増やすのは良いが。
  • 振る舞いのパターンをアスペクトと呼んでいるのは、実装レベルではなくメタなレベルでウィービングしているから?
    ...と思ったけれど、書籍でも AspectJ を挙げているので、実装レベルでもアスペクトとして扱っているかも。とすると実装例と整合性が取れていない?
  • アスペクト間の連携をイベントで行う話、書籍では実装例 (6.7 アスペクト間のイベントの入れ替え) のことでしょうか? 依田さんは違和感があるようでしたが、僕は特に感じませんでした。
  • 「REA カード」の発想は面白そう。ただし、イベントは必ずしも 1対1 ではないと思いますが。

アスペクトに関して、マイクロソフトの萩原さんが次のようなことを言われていたが、何となく雰囲気はわかるものの、ちゃんとは理解できなかった。(^^;)

まだまだ勉強が足りませんね。

おまけ

ELEVATOR PITCH という小冊子が配布された。エレベータに乗っている間に読める簡単な説明とのこと。