UMLでデータモデリングをする理由

昨日のモデリングライブの感想をkdmsnrさんとAkaponさんが書いてくださっているのを興味深く読ませていただいた。
中でもkdmsnrさんの

データだけでいいのなら、UMLモデリングする意味がよく分かりません。

という指摘にはグッと来た。もっともな疑問だと思うし、自分自身でもずっと考え続けてきたこと(そして現在も考え中)なので、少し考えを整理しておこうと思う。


まず振る舞いを考えずにデータモデリングを行う理由から。自分は1990年代の初めにオブジェクト指向に出会ってから、ずっと「オブジェクト指向モデリング」を追求してきた。すなわち、コンピュータの中で現実世界を写し取ったオブジェクトがメッセージをやり取りしながら全体の仕事を達成する仕組みを表現しようとしてきた。しかし『奇妙なクラスと実世界』や『オブジェクト指向は本当に「オブジェクト」指向か?』などの文章を書いた頃から、オブジェクト指向と現実世界には共通点はあるものの、実際には「似て非なるもの」と考えるようになった。一方で、ビジネスアプリケーションについて言えば、重要なのは「覚える仕事」、すなわち企業活動の結果を記録する仕事であって、ほとんどのユースケースは登録・更新・削除・参照などの単純なものばかりであり、その企業を取り巻く現実世界の状況はデータ構造に映し出されることを改めて理解した。このため要件定義段階では、データ構造のモデリングを重視するようになった。

UMLを使う理由はいくつかある。1つは自分が慣れ親しんでいるからである。以前はUMLの前身であるOMTを愛用していたため、UMLのクラス図には違和感が少ない。もう1つはUMLが表記法のデファクトスタンダードだからである。普及している技術を使う理由は、それが技術的に最高だからではなく、「普及しているから」である。普及しているからこそ、書籍や周辺ツールの選択肢が広くなり、かつ安く手に入れることができる。


ここまでは特に問題ない。厄介なのは「なぜデータモデリングをするのに識別子を決めないか?」である。このことについては自分でも随分悩んできたし、渡辺幸三さんともたくさん議論した。以下、エンティティの識別子を決めない方がいい、あるいは決めたくないと考える理由を思いつくままに挙げてみる。

まず気になるのは、基本的なエンティティについては、識別子を決めても実際には何も決めたことにならないことである。「社員」の識別子を「社員番号」にすると決めたところで、「すべての社員はユニークな社員番号を持つ」と言っているだけである。「すべての社員」に契約社員を含むのか、退職者が再入社した場合同一人物と見るのかどうか、といった肝心なことについては何も規定していない。

識別子を決める意味は、そこから派生するエンティティのセマンティクスを規定するところにある。これはたとえば、「倉庫」と「商品」の組み合わせで「在庫」を管理することを、「在庫」の識別子を「倉庫ID」「商品ID」の複合キーにすることで簡潔に定義できる。UMLでは限定子を使えば表現できるが、上記のような複数のエンティティの主キーの組み合わせを表現するモデルは視覚的に不格好になる。特に三項関連以上になると最悪である。

しかしモデリングの実務的には、識別子が複数のエンティティに伝搬するのが煩わしい。モデリングの途中段階では、エンティティの追加や削除が頻繁に起きる。識別子を定義していると、識別子に関する変更が起きた場合、その識別子が伝搬する先もすべて変更する必要が出てくる。多くのDOA方法論がデータ辞書を作ることを推奨しているのに、オブジェクトモデリングの方法論の多くがデータ辞書を重視しない理由はここにあると思う。

また識別子を決めようとすると、RDBの物理設計との境界線が曖昧になるのも嫌だ。複合キーにシーケンス番号/タイムスタンプのいずれを使うか、複合キーの数が多過ぎるから別の単一キーを導入しようか、といった議論は、RDBで実装するための設計判断としか思えない。

本質論ではないが、識別子を持ち出すことで、あるべき像の議論に集中しづらくなるという副作用もある。システムを再構築する場合など、既存システムのコード体系を見直すことは多い。こんな状況で識別子の議論を始めると、既存システムのコード体系の問題点やデータの不整合の話で盛り上がってしまう。もちろんどこかの段階できちんとやるべき議論だが、あるべきシステムの全体像を手早くとらえる段階では、この手の議論は後に回したいところである。


と、ここまで書いてみたが、この議論についての自分の考えはずっと揺れてきた。より正確に表現するなら、数年前は「概念モデリングの段階では識別子を定義するべきではない」と確信していたものの、最近ではかなり怪しくなってきたというのが本音である。以前行われたモデリング道場のコンテストの応募作品のバリエーションが多岐にわたっているのを見たときなどは、特にその思いを強くした。

成果物のブレを一定範囲内に収めるためには、自由度の高いオブジェクトモデリングよりも識別子を決めるERモデリングの方が実務的なのかもしれない。しかし自分自身が、そのやり方でモデリングをするのにはかなり抵抗を感じる。今の本音はそんなところである。