ドメインモデルはER図と同じ?

この本を読んでみました。
ユースケース入門―ユーザマニュアルからプログラムを作る」
ユースケース入門―ユーザマニュアルからプログラムを作る (Object Technology Series)
ちっとも入門書ではないことも、ICONIXという開発プロセスの説明で
あるという題名に偽り有りの本であることはわかっていました。
開発プロセスの具体的な適用方法を体感したかったので丁度いいと
思ったのです。


でも、どうにもわかりづらくてピンときませんでした。
もう一度頭から読んでみたら最初よりすんなり理解できました。
モデリング初心者にはわかりづらく、ある程度わかっている
人にはわかりやすい本なのでしょう。


ある程度理解できたところで、試しに実践してみよう〜と
やってみたのですが、やっぱり名詞抽出法でつっかかりました。
なんかしっくりこないのです。


こんな記述を見つけました。


オブジェクト指向設計では、構造化手法よりも容易にモデリングが行えます。
例えば、受発注のシステムを考えた時に、データモデリングでは、いきなり「注文」
というエンティティを持ってきたりします。これは、モデリングの経験がある人なら
すぐに思いつきますが、そうでない人にとっては難しいことです。それに比べて
オブジェクト指向設計では、具体的なケースであるシナリオを考えてから、手順を
追って説明に必要な要素を洗い出していきます。こちらの方が、初心者には容易に
入っていけるはずです。」
引用元:オブジェクト指向の広場

どういう初心者を想定しているのかはわかりませんが、私には容易ではありません。
データベース設計に慣れているからでしょうか、「注文」エンティティはすぐに
思いつきます。でも、名詞抽出法だとどうにもやりにくいのです。


この本も読んでみました。
「ワークブック形式で学ぶUMLオブジェクトモデリング―「ユースケース駆動」でソフトウェアを開発する」
ワークブック形式で学ぶUMLオブジェクトモデリング―「ユースケース駆動」でソフトウェアを開発する
これはいいです。最初の本を読んでおくと、とてもわかりやすい。
知識がメキメキとついていくのが実感できます。
しかし、問題領域の名詞抽出法については何も触れられていませんでした。
そこが今一番知りたいとこなのに。


・・・ふと、この本のドメイン分析後のクラス図を見てて気がつきました。
あれ、これって正規化したDBレイアウトにそっくりなんじゃないの?
汎化はDBレイアウトにはないけど、集約って・・・。第2正規化じゃないのか?


よく、クラス図とER図は似ている、あるいは同じものだ、なんて書かれているのを
今まで読んだことをあるけども、ふ〜んそんなものかぐらいにしか思っていませんでした。


でもようやく実感できました。
それに、DBの項目がクラスなら、レコードがインスタンスじゃないですか。
だったら、問題領域に存在する情報を全てDBに格納するつもりで正規化していけば、
問題領域のクラス図ができあがるんじゃないでしょうか。
やってみます。