オブジェクト指向の世界（13）
モノとコトによるモデリング

（有）オブジェクトデザイン研究所
河合昭男
2005/12/23

　前回（「“what ＆ why”4原因説をビジネスモデルに応用」）はアリストテレスの4原因説（形相因、質料因、始動因、目的因）の応用編として「ビジネス→ビジネスモデル→情報システム」の因果関係について適用を試みました。

　現象（what）にすぐに目が移りがちですが、その前に必ず原因・理由（why）があるはずです。「what＝形相因＋質料因」「why＝始動因＋目的因」というとらえ方をし、各原因はさらにその原因という原因連鎖（因果関係）があります。情報システムは真にビジネスの効率化に、ビジネスの対象となる顧客満足につながるというトレーサビリティが必要です。

情報システムの “what ＆ why”

what： 形相因＝設計（←ビジネスモデル） 質料因＝ソフトウェア＋ハードウェア

why： 始動因＝依頼主 目的因＝ビジネスの効率化（←依頼主の顧客の満足）

　 今回は少し話題を変えてモノとコトによるモデリングについて考えてみたいと思います。この考え方自体はよく知られた一般的なもので、すでに一部現場でも応用されています。

　オブジェクト指向の特徴であり、同時にオブジェクト指向を分かりにくくしている「何でもオブジェクト」の問題についてあらためて考えてみたいと思います。物理的なモノを表すオブジェクト（モノ）と事象を表すオブジェクト（コト）を区別するとオブジェクト指向は理解しやすくなると思います。さらにこの事象をモノとモノとの関連クラスとして表すと、その意味がより明確になります。

◆ モノとコト

　物事という言葉があります。モノとコトすべてを表す便利な言葉です。人間社会の活動はモノとコトでとらえることができます。例えば「書店で本を買う」という状況を考えてみましょう。書店にはたくさんの本があります。そこに客が来店して平積みにしてある本を手に取り、少し読みます。読んだ書籍を何冊か購入します。

• モノ：客、書籍
  
  
• コト：読む、購入する

　モノとコトの違いは何でしょうか。

広辞苑（第4版）より一部抜粋 物：形のある物体をはじめとして、広く人間が感知しうる対象 事：意識・思考の対象のうち、具象的・空間的でなく、抽象的に考えられるもの

　簡単にいえば、モノは形ある物体でコトは現象です。モノはそれ自体で存在可能ですが、コトはそれ自体で存在できません。

　新聞記事には事件がニュースとして取り上げられます。事件はコトですが、必ずベースとなるモノが必要です。モノだけではニュースになりません。ニュースにするには、あるモノを発明・発見したとか、モノの状態に予測外の変化が起きたとか何らかのコトが必要です。人間社会の事件には必ず人や組織が絡んできます。自然現象にはその対象となるモノが必ず絡んできます。

　例えば松井選手の契約金が約60億円というニュースがありました。

• モノ：松井、ヤンキース
  
  
• コト：契約する

　松井選手をモノ扱いするのはけしからんという声が聞こえてくるかもしれませんが、モノとコトの分類では人はモノと考えます。60億円というのは契約するというコトの内容です。誰と誰が契約するのかというモノが存在しないと契約だけでは存在できません（「契約」については、次回お話しする予定です）。

　天候や地震などの自然現象はコトですが、その現象が起きる場所があります。場所をモノというのも変ですが、モノとコトの分類ではモノと考えます。

• モノ：場所
  
  
• コト：天候、地震

◆ 何でもオブジェクト

　オブジェクト指向の特徴の1つは、現実世界に存在するもの（モノ＋コト）はほとんど何でもオブジェクトと考えることができることです。人・車・書籍・PC……など物理的なもの（モノ）のほか、予約・注文・契約・会議……など概念的なもの（コト）など識別可能なものはほとんど何でもオブジェクトと考えることができます。

　これはオブジェクト指向の長所に違いないのですが、対象領域（問題領域）からオブジェクトを抽出する目的は、対象領域を理解するためにオブジェクトによる単純明解なモデルを作成するためです。何でもオブジェクトとしてしまうとオブジェクトを抽出した後のモデリングは簡単ではありません。その原因の1つは物理的なオブジェクト（モノ）と概念的なオブジェクト（コト）という取り扱いの異なるオブジェクトが同列に混在していることです。

◆ リソースとイベント

　オブジェクトをモノとコトにはっきりと分離してとらえると分かりやすくなります。先ほどの物理的なものは「モノ」、概念的なものは「コト」です。データベース設計で佐藤正美氏の提唱されている「T字形ER技法」ではデータをリソース系とイベント系に分けていますが、これはとても分かりやすい方法だと思います。オブジェクトも同様に考えてみましょう。つまりモノはリソース系オブジェクト、コトはイベント系オブジェクトです。

　リソース系オブジェクトは顧客、商品などそれ自身で存在し得るオブジェクトです。しかし注文などイベント系オブジェクトは顧客と商品を前提として初めて存在し得るオブジェクトです。

◆ 顧客が商品を注文する

　例題として「顧客が商品を注文する」を考えてみましょう。初期状態では顧客と商品が存在しますが、注文オブジェクトはまだ存在しません。「注文する」というイベントは顧客と商品の存在を前提として発生する現象です。UMLではこれは2項関連として表現します。

　図1（a）のオブジェクト図は「Aさん：顧客」が「ノートPC：商品」を注文するというイベントの結果リンクが張られた状態を示します。

図1 コトとリンク属性（オブジェクト図）

　次の問題は例えば注文日のような注文というイベントが持つべき属性をどこに表現するかです。これは「Aさん」の属性でもなく「ノートPC」の属性でもありません。注文日は注文するというリンクが持つべき属性です。注文日はリンク属性と呼び、UMLでは図1（b）のように注文日を属性として持つオブジェクト「：注文」を作成してリンクの中央と破線で結びます。

　つまり「：注文」というオブジェクトは注文するというイベントの結果生成されたコトを表すオブジェクトです。このようにコトはリンク属性で表現できる場合があります。厳密にはコトが発生した結果の状態ですが、ここではコトと呼びます。

◆ コトと関連クラス

　オブジェクト図をクラス図にしてみましょう。リンク属性はそのまま関連クラスとして表現します（図2（a））。この関連クラスは間にはめ込んで通常の2つの2項関連として表現することができます（図2（b））。

図2 コトと関連クラス（クラス図）

　さてここで図2（a）（b）が表している意味内容は同じですが、どちらが分かりやすいでしょう。（a）はコトが関連クラスで表現されていますが（b）はモノとコトが同列で表現されています。（a）では注文するというイベントがあって初めて注文オブジェクトが生成されるということが理解しやすいですが、（b）の図からはそこがはっきりしません。

　モデリングの方法は人によってさまざまです。中には、「関連クラス派」と「関連クラスを使わない派」のような派閥もあります。関連クラスは分析モデルで使用するものであり、通常設計モデルでは使用できません。その理由は、関連クラスという概念そのままをJavaなどの実装言語では表現できないからです。ちなみに、筆者は関連クラス派です。関連クラスを使わない派の主張は次のようなものです。

（1）関連クラスの理解が難しいから無理してそんな面倒なものを使わずとも、簡単な2項関連で十分である （2）設計レベルでは関連クラスは使用できず結局（b）のスタイルにするのだから、初めからそうしておけばよい

　これらの主張に対する筆者の考えを示します。まず（1）についてですが、オブジェクト指向は現実世界をそのままモデリングできるのが特徴の1つです。現実世界から図1（a）→図1（b）の流れはそれを示しています。これをそのままクラス図にしたものが図2（a）です。難しさも面倒さもありません。最初から現実世界から直接、図2（b）を導く方がよほど不自然でかつ困難です。

　（2）についてですが、そもそも分析モデルと設計モデルは別物です。分析モデルを省略して一気に設計モデルを作成するのは簡単ではありません。分析モデルでは関連クラスが自然で分かりやすいと思います。

　筆者は関連クラスでモデリングに開眼した経験があるので関連クラス派です。初心者の方には関連クラスをお勧めしています。

◆

　今回はモノとコトによるモデリングについて考えました。人間社会の活動はモノとコトを分離してとらえることにより自然にモデリングできます。コトはリンクで表し、必要ならそこにリンク属性を追加します。通常コトにはその事象が発生した時間が付属します。これはリンク属性です。オブジェクト図のリンク属性はそのままクラス図の関連クラスとなります。

　さて初めに例として挙げた「松井選手はヤンキースと60億円で契約した」はどのようにモデリングできるでしょう。次回は今回の続きをもう少し考えてみたいと思いますので、皆さまもこの宿題をちょっと考えてみてください……。

プロフィール

河合昭男（かわいあきお） 　 大阪大学理学部数学科卒業、日本ユニシス株式会社にてメインフレームのOS保守、性能評価の後、PCのGUI系基本ソフト開発、クライアント／サーバシステム開発を通してオブジェクト指向分析・設計に携わる。 　オブジェクト指向の本質を追究すべく1998年に独立後、有限会社オブジェクトデザイン研究所設立、理論と実践を目指し現在に至る。 　ビジネスモデリング、パターン言語の学習と普及を行うコミュニティ活動に参画。著書『まるごと図解 最新オブジェクト指向がわかる』（技術評論社）、『まるごと図解 最新UMLがわかる』（技術評論社）。『UML Press』（技術評論社）、『ソリューションIT』（リックテレコム）ほかの専門誌に多数執筆。ホームページ「オブジェクト指向と哲学」。

IT Architect 連載記事一覧

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）