モデリングを学ぶ際の壁。
モデリング本を読んでいると、いつも思うことがある。
この類いの本は、読んでいるだけでは駄目で、自分なりの図を描かないと
モノにはならないと。
それは分かっている。そして、実際に描いてみて思う。
で、コレどうなの?
自分で描いたモデル図である。
自分でそれを検証するのは、あまり意義がない。
自分は、それで正しいと思って描いているわけですから。
そうすると、せっかく描いたモデル図を検証することができない。
やはりこういったものは誰か有識者にレビューしてもらわなければならない。
しかしながら、的確にレビューをしてくれる存在が常に傍らにいるかというと、
それはむしろ稀である。幸せというべきだろう。
そうなると、一人で気楽に学ぶことができず、途端に、敷居が高くなるのを
感じる。
そういうわけで、UMLによるオブジェクト指向モデリングセルフレビューノートはとても役に立った。
- 作者: 荒井玲子
- 出版社/メーカー: ディーアート
- 発売日: 2005/04/01
- メディア: 単行本
- 購入: 2人 クリック: 25回
- この商品を含むブログ (33件) を見る
記載したものである。
あるべきモデルはこうであるという、明確な基準を示している。
これと同じようにデータモデリングについても、良い手本となる本はある。
そして、一方で思うことがある。
ある方法論を用いて、作り出したモデルは、誰が書いても同じモデルになるべきではないかと。
UMLは方法論ではない、言語だ。
しかし、データモデリングはT字型ERにせよ、三要素分析法にせよ、TH法にせよ
何がしかの方法論を用いているはずだ。
方法論とは、それを使っていれば、個人的な思想が入り込むことはなく、
誰が利用しても同じ結果になるはずである。
ということは、お手本のモデル図と大部分が合致するはずなのだ。
モデリングは、検証が可能である、そう考えると、敷居は低くなる。
プログラムなんてどうでもよい?
きちんとデータ構造を定義することが、大事で、それをアレコレ、出し入れする
業務アプリケーションのプログラムなんて、極論どうでもいいのかも。
もちろん、データだけあればいいというわけでもない。データは、加工されて、
いい感じで表示してくれる画面や帳票があって、初めて活用される。
その意味で、加工プログラムやUIは必要である。
しかし、データベースは、プログラムが無くとも存在可能であり(アクセス可能であり)
それを利用するプログラムをまた用意してあげれば良いだけだが、
データを利用する側のプログラムは、それ単体では存在意義はない。
当たり前のことだ。業務⇒データ⇒プログラムの順で考える。
業務パッケージの肝となるのも、ソフトウェアじゃない。
パッケージが定義しているデータ構造が、いかに業務にFitするかという
ことではないだろうか。その次に、機能がどうだこうだという話が始めて
できる。カスタマイズは、ソフトウェア上の小手先だと失敗する。
データ構造そのものを、考えてあげる必要がある。
お客さんの投資対象はソフトウェアである。
しかし、最も重要なのはデータ構造であり、そこに蓄積されていくデータなのだ。
プログラムではない。