REA パターンとオントロジー（ビジネスパターンによるモデル駆動設計）

-

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

  • Pavel Hruby (著), 依田 智夫 (監修, 監修), 溝口 真理子 (翻訳), 依田 光江 (翻訳)
  • Model-Driven Design Using Business Patterns
  • 日本語版 発売日 2007/8/9、英語版 発売日 2006/6/22




REA（Resource-Event-Agent）という言葉は本のタイトルに含まれていませんが、この本は REA モデルにもとづく業務アプリケーションの設計パターン本です。

REA とは、ざっくり言えば、「商品を売ってお金をもらった」といったことを、「商品を売る（商品が減る）」、「お金が増える」という２つの双対な経済イベントとしてとらえ、そのイベントに関係するリソース（商品、お金など）と、エージェント（売り手、買い手となる企業や個人）を合わせてモデリングする考え方です。

これは簿記において、取引を借方と貸方で金額が同じによるように仕訳するのと似たような考え方ですが、そもそも REA は汎用の会計モデルとして提案された方法とのことなので、似ているというより包含した考え方のようです。

私は財務会計に関する知識は持ち合わせていないので、会計モデルとの対比云々は語ることができませんが、この本は財務会計の本ではないので会計知識が無くても読めますし、私は REA の双対となる増減イベントの考え方は強く印象に残りました。

また、この本には以下のように書かれています。
  • アプリケーション設計者は、一貫性があり業務の観点から見落としのない構造を手に入れることができるはず

この本が出版された当時に読んだ印象は「面白い視点の本だなー」という程度でしたが、あるきっかけでこの本を読み返してみると、オントロジーとの関連が強いことが分かり、今までとは違った観点で「面白い本だなー」と感じています。

そこで、少し古めの本ではありますが（改定版はないと思いますが）、本ブログで取り上げることにしました。

＜本の内容＞

目次
  • 第１部　構造パターン
    • 第１章　業務レベルにおける構造パターン
    • 第２章　方針レベルにおける構造パターン
    • 第３章　REAベースのアプリケーション例
  • 第２部　振る舞いのパターン
    • 第４章　横断的な関心事
    • 第５章　パターン
    • 第６章　アスペクトベースのアプリケーション例
  • 第３部　モデリングハンドブック
    • 第７章　基本的な交換プロセス
    • 第８章　基本的な変換プロセス
    • 第９章　交換プロセスと変換プロセスのあるバリューチェーン
    • 第１０章　契約を伴うプロセス
  • 付録Ａ　REAオントロジ
  • 付録Ｂ　モデリング上の注意点
  • 付録Ｃ　パターンの書式

パターン本ではありますが、REA モデルの基本的な考え方を押さえておかないと次に進めないため、第１部から順に読み進める必要があると思います。（私はそうでした。）

目次だけ眺めてもピンときませんので、とても大雑把で大変恐縮ですが、話の流れと取り上げられるパターンを見ておきます。

まず第1章では REA モデルの基本的な説明があります。

REA は、Resource、 Event、 Agent の頭文字をとったものですが、これらは以下のように定義されています。（少し省略しています。）
  • 経済リソース（Economic Resource）
    • 経済エージェントにとって役に立つものであり、計画、監視、制御の対象となるもの。
    • 例）製品、サービス、お金、原料、労働力など
  • 経済エージェント（Economic Agent）
    • 経済リソースを制御でき、他の個人や組織に制御を移転したり、他から管理を受けたりする個人もしくは組織。
    • 例）顧客、ベンダー、従業員、企業など
  • 経済イベント（Economic Event）
    • 企業が制御する経済リソースの価値の増加または減少を表すもの。
    • 例）商品の販売、労働力の取得、サービスの提供や利用など

これに REA モデルの基本的な考え方があります。
  • 企業が、その制御下にあるリソース全体の価値を増やしたい場合、通常はいくつかのリソースの価値を下げなければならない。

企業は「交換」や「変換」によってリソースの価値を増やしたり減らしたりします。
  • 交換
    • 企業が他の経済エージェントから経済リソースを受け取り、その見返りとして、その経済エージェントにリソースを与えるプロセスである。
  • 変換
    • 企業が新しいリソースの生産や、既存のリソースの変更のために、リソースを使用あるいは消費するプロセスである。

加えて、交換や変換のプロセスで入力あるいは出力となるリソースをつなぐバリューチェーンでビジネスプロセスをモデリングします。

これらを基本的なスケルトンとして企業の経済活動をモデリングしていくことになります。

なお、ピザ屋のビジネスを例に具体的に説明されているのでイメージがつかみやすいです。

＜業務レベルのパターン＞

  • REA交換プロセス（REA EXCHANGE PROCESS）
    • 取引
  • REA変換プロセス（REA CONVERSION PROCESS）
    • 生産
  • REAバリューチェーン（REA VALUE CHAIN）
    • ビジネスプロセス

上記パターンは、実際に発生した経済的なイベントをモデリングするものですが、システムでは将来発生するイベントやビジネスルールなどもモデリングする必要があります。

第２章では、これらを方針レベルのパターンとしてまとめています。

＜方針レベルのパターン：何が起こり得るか、起こるべきか、起こるべきでないか＞

  • タイプ（TYPE）
    • 同種の集合
  • グループ（GROUP）
    • 異種の集合
  • コミットメント（COMMITMENT）
    • 将来のイベント
  • 契約（CONTACT）
    • 取引におけるコミットメント
  • スケジュール（SCHEDULE）
    • 生産におけるコミットメント
  • 方針（POLICY）
    • ビジネスルール
  • リンケージ（LINKAGE）
    • リソースの構造
  • 責任（RESPONSIBILITY）
    • エージェントの構造
  • 監督（CUSTODY）
    • リソースに対する責任

第３章で、これまでのパターンを利用したピザ屋のサンプル Web アプリケーションが示されていますので、理解の助けになります。

ここまでが第１部で、基本的なスケルトンとなる構造パターンが書かれていますが、続く第２部からは具体的なアプリケーションで必要となる振る舞いをモデリングするためのパターンが書かれています。

振る舞いのパターンで面白いのは、アスペクト指向プログラミングの考え方を導入しているところです。

といっても、本書で AspectJ などのプログラミング言語を利用して振る舞いのパターンをモデリング、実装するわけではありません。

第４章でアスペクトに関するモデリングの説明があり、その後、振る舞いのパターンが示されます。

＜振る舞いのパターン：ビジネスアプリケーションの特定の振る舞い＞

  • 識別（IDENTIFICATION）
    • エンティティのアイデンティティ
  • 期日（DUE DATE）
    • デッドライン
  • 説明（DESCRIPTION）
    • 外部情報
  • 注釈（NOTE）
    • 内部情報
  • ロケーション（LOCATION）
    • イベントが発生する場所
  • 分類（CLASSIFICATION）
    • グループ化
  • 通知（NOTIFICATION）
    • メッセージ
  • 価値（VALUE）
    • 測定単位
  • 転記（POSTING）
    • 履歴の保持
  • 勘定（ACCOUNT）
    • 履歴の取り出し
  • 照合（RECONCILIATION）
    • トランザクションの適合
  • 実体化した請求権（MATERIALIZED CLAIM）
    • 請求書
  • 考案者のパラドックス（INVENTOR’S PARADOX）
    • 新しい振る舞いのパターンを発見する方法

第６章でアスペクトベースのアプリケーションのコード例が示されていますので、理解の助けになります。

第３部はこれまでの集大成のようなもので、「モデリングハンドブック」として、アプリケーションモデル例がパターンの形式で書かれています。

  • 第７章　基本的な交換プロセス
    • 現金販売
    • 商品の返品
    • 貸与と賃貸（個々に識別できるリソース）
    • 融資（個々に識別できないリソース）
  • 第８章　基本的な変換プロセス
    • 新しい製品の生産
    • 変換プロセスのチェーン
    • 製品の改変
    • サービスの生産と消費
  • 第９章　交換プロセスと変換プロセスのあるバリューチェーン
    • 販売と出荷
    • 販売プロセス中に消費されるリソース
    • 人的管理
    • 教育
    • 税金
    • マーケティングと宣伝
    • 廃棄物
    • サービスの購入と販売
    • 一時的なリソース
  • 第１０章　契約を伴うプロセス
    • 購入注文
    • 労働力の取得
    • 保証
    • 保険
    • コミットメントが履行されない場合の罰則
    • 生産計画
    • 輸送

＜感想＞

初版が発売されたとき（2007年）、書籍の帯にあった「ビジネスアプリケーション設計を変革する REA による新しいモデリング技法」というキャッチにひかれて衝動買いした本です（笑）。

購入直後に読んだ時は、ビジネス（企業活動）を考えると、確かに取引（交換）や変換で説明できることが多く、何かが増えれば何かが減るな、と思えたので、「面白い視点だなー」と思いました。

また、アスペクトの考え方をコードに落とすサンプルもとても参考になりました。

しかし、REA モデルの基本的な考え方には共感しつつも、ピザ屋の例やコードを見て理解した気になっただけで、最後まで興味を持って読んだわけではありませんでした。

実は、この本を読む前にモデリングのパターン本として以下のような本を読んでいました。

例えば、REA モデルでは主要な概念としてエージェントがありますが、エージェントの具体的な表現に言及しているわけではありません。REA モデルの関心は、エージェントの表現ではなく、イベントやリソースとの相互作用だからだと思います。

一方、上記のようなパターン本はむしろエージェントの表現を深堀しているので、当時は、こちらのほうが仕事に直接使いやすいと感じてました。

さらに、以前の記事で紹介した『アジャイルに一貫したモデリングから実装を維持する方法を知る本（エリック・エヴァンスのドメイン駆動設計）』に比べて、この本は熱い語り口調もなく、原理原則に基づいて淡々と説明が続くようなイメージがあり、読み物としては退屈な印象が強かった本です。（教科書という感じでしょうか。）

しかし、あるきっかけでこの本を読み返してみると、この本は企業活動のドメインオントロジーに関する本であって、上記のような設計パターン本より少し上位の概念を扱っているもの、ということに気付きました。

当時はスルーしていましたが、付録A 「REAオントロジ」には「GeertsとMcCarthy（Geerts, McCarthy 2000, 2002）は、ビジネスシステムのためのオントロジとして、REAを定式化しました」とあり、本書のモデルとの違いを概観しています。

また、英語版Wikipediaには「 In computer science terms, REA is an ontology.」と書かれてました。

ちなみに、REAに関する論文などは下記のサイトにあるようです。

その観点で本の内容を読むと、確かに、語彙（クラス名や関連の名前）の一つ一つに公理っぽく定義が与えられており、かつ語彙の利用にも一貫性があります。

一方、本書には「REAは、ビジネスシステムにとってユビキタス言語を定義するものと言えるでしょう。」とあります。

先に本書に出てくるパターンを列挙しましたが、仕事で普通に使っていた用語にも関わらず、ユビキタス言語になっていたかどうか（正確な共通認識になっていたか）は怪しいところもあり、なるほど、と思うところも多いです。

こう考えていくと、ユビキタス言語としてのオントロジーの位置付けというものも見えた気がして、とても興味深く思えます。

もう少し言えば、デザインパターンとオントロジーの関係も少し垣間見た気がします。

とはいいつつも、（特に上位オントロジーとの関係を考察する）オントロジーを示されるよりは、オブジェクト指向系でまとめてくれたデザインパターンの方が（現場での実装には）使いやすい気もするので、どちらが良い、悪いという問題ではない気がします。

その意味で、REA オントロジーの解説ではなく、設計パターンとして REA モデルを解説してくれる本書は、REA の考え方の導入としても、業務モデリングへの応用にも使える良い本だと（今更ながら）思いました。

（参考）

実は下記の W3C の勧告になっているオントロジーを読んだ時に思い出したのが、今回取り上げたREAの本でした。

これはざっくり言えば、データや物の Provenance（来歴）を、その作成に関与するエンティティ、アクティビティ、エージェントでとらえるオントロジーです。

これを読んだ時に、何か似たようなものがあったな、と思い出したのが REA です。

「オントロジー工学」でもイベントやプロセスは深く論じられていますが、このような上位のオントロジーを見ていくと、いろいろなものが繋がっていくような気がして、なかなか興味深いです。


関連記事

コメント

コメントを投稿

このブログの人気の投稿

VirtualBoxのスナップショット機能

-
イメージ
本記事では、VirtualBoxのスナップショットがもつ情報と使い方について見ていきます。   【目次】 ［１］はじめに ［２］スナップショットの保存内容 ［３］VirtualBox マネージャのスナップショット画面 ［４］スナップショットの作成 ［５］スナップショットのプロパティの表示と編集 ［６］スナップショットの復元 ［７］「最新の状態」とスナップショットの履歴 ［８］スナップショットの削除 ［９］エクスポート/インポートの注意事項 ［１］はじめに 仮想マシンを利用するの利点の一つは、ある時点の仮想マシンの状態を保存し（スナップショットを作成）、後に、保存した状態を容易に復元することができることかと思います。 例えば、開発環境のある状態を保存しておき、ライブラリのバージョンアップを実行してみて、その結果が悪ければバージョンアップ前の状態に戻す、ということが簡単にできます。 スナップショットは、実行中の仮想マシンの状態（メモリ等の状態）も保存できますので、エディタで編集中の状態まで保存、復元できたりします。（少し言い過ぎですが、ワープロ編集中にでUndoやRedoを利用するのと同じような感覚でしょうか。） また、スナップショットのデータは、仮想マシンと統合管理されているため、保存、復元操作が非常に簡単です。 （一方で、スナップショットは、一般に言うバックアップとは少し目的が異なるため、バックアップの代替えになるとは限らない点に注意が必要です。） 本記事ではVirtualBoxのスナップショットについて見ていきます。 （参考） Vagrantをお使いの場合は、記事『 Vagrantのスナップショット機能とVirtualBox 』も参考にして下さい。 ［２］スナップショットの保存内容 VirtualBoxのスナップショットについては、ユーザマニュアルに記載があります。 User Manual 1.10. Snapshots（ https://www.virtualbox.org/manual/ch01.html#snapshots ） 詳しくは上記ドキュメントをご参照頂くとして、スナップショットは仮想マシンの構成、ディスクとメモリの内容を保存しています。 ハードウェア構成を含む仮想マシン設定の完全なコピーを持っています。 これにより、例えば、ある時点
続きを読む

Google Document AIで画像から表形式データを抽出する（Vision API OCRとの違い）

-
イメージ
本記事では、GoogleのDocument AIを利用して、表形式（テーブル形式）で記載された画像から、表形式の情報を抽出してみます。また、GoogleのVision API OCRを利用した場合との違いについてもみておきます。 【目次】 ［１］はじめに ［２］Document AIとVision API（OCR）の違い ［３］テスト用の表形式画像 （１）英語版表形式画像（shoppinglist.jpg） （２）日本語版表形式画像（okaimonolist.jpg） （３）PDFファイルへの変換 ［４］Vision APIによる表形式画像の認識 （１）実験方法 （２）英語版表形式画像の認識結果 （３）日本語版表形式画像の認識結果 ［５］Document AIによる表形式画像の認識 （１）実験方法 （２）英語版表形式画像の認識結果 （３）日本語版表形式画像の認識結果 ［６］最後に ［１］はじめに Google Vision APIを利用すると、画像から文字を抽出（OCR）できます。 https://cloud.google.com/vision/ Vision APIは、本などの文章の画像や、風景の画像から文字を抽出するといったケースでは、かなりいい感じで文字を抽出してくれます。文章が書かれているような画像の場合は、画像から文字を抽出するだけでなく、大雑把に文書の構造も得ることができます。 しかし、Vision API OCRでは期待した抽出が難しい例もあります。 例えば、下図のような、よくある表形式で書かれた書類です。 文章の画像は、隣接する文字の塊を抽出するだけでも、期待した文章が抽出できることが多いと思います。 しかし、上図のような表形式の書類は、隣接した文字の塊を抽出するだけでは利用価値が低い場合が多く、表形式のデータとして認識する必要があります。 表形式の書類は、人間が見れば、表組の意味を理解して要点を把握しやすい表現だと思います。例えば、「2021/2/2のお菓子の値段は300円であり、同日のお弁当は1,000円」云々と文章でつらつら書かれるより分かりやすいです。 一方で、これを機械的に認識しようとすると、単語レベルの文字列が散らばって配置されているレイアウトのようにも見えて、解釈が難しい場合が多いです。実際、汎用目的の機械的な表の認識を行
続きを読む

Ubuntu/Colab環境でPDFファイルのページを画像化する（pdf2image、pdftoppm、pdftocairo）

-
本記事では、UbuntuやGoogle Colaboratory環境で、オープンソースライブラリのPoppler（poppler-utilsに含まれるpdftoppm、pdftocairo）あるいはPythonライブラリのpdf2imageを利用して、PDFファイルのページをJPEGなどの画像ファイルに変換する方法を見ていきます。 【目次】 ［１］PDFファイルを画像に変換したいとき？ ［２］PDFファイル扱うオープンソースライブラリ （参考）ページの画像化と情報抽出について ［３］コマンドラインからの利用：poppler-utils （１）poppler-utils （２）インストール （３）pdftoppmの利用例 （４）pdftocairoの利用例 ［４］Pythonからの利用：pdf2image （１）pdf2image （２）インストール （３）最も簡単な使い方 （４）メモリを節約する方法（output_folderを利用する方法） （５）メモリを節約する方法（fmtを利用する方法） （６）サムネイルの作成サンプル （７）ページを指定して変換する方法（first_page, last_page） （８）大量ページの変換速度を上げる方法（thread_count） （９）解像度（dpi） （１０）pdftocairo/pdftoppmの画像変換結果を直接利用する（use_pdftocairo） （参考）pdfinfo_from_path関数 ［１］PDFファイルを画像に変換したいとき？ PDF（Portable Document Format）ファイルは広く使われている電子文書です。 PDFファイルは、ブラウザでも表示できますし、無料のAdobe Acrobat Readerをインストールして表示することもできます。 しかし、こういったツールでファイル内容を表示するだけではなく、PDFファイル内のページをJPEGなどの画像ファイルに変換して利用したい場合もあります。 例えば、システム開発において、Webサイトやアプリ内で、PDFファイルの概要をサムネイル表示したいとか、PDFファイルをダウンロードさせたり、ブラウザの別タブでPDFファイルを表示するのではなく、（導線が途切れないように）ページを移動することなく内容を見てもらいたい場合など、いろいろ
続きを読む