モデリングの本質

「UMLモデリングの本質」(児玉公信、2004)という本を読んだ。図書館の蔵書・貸出管理システムとか、航空券の発券システムごときで図を描いて議論するなんて話が大げさすぎるのんとちがうか、というのが第一印象。なんだろ、これはという。一方で、オブジェクト指向ってそういうことだったのかと思った。このパラダイムが特に業務アプリの世界でRDB＋Javaとともに成功してきた理由も少し分かった気がする。クラス図というものをかすかにしか知らなかったぼくには、それなりに面白い読み物だった。この本に出ている実例の図は、なんども繰り返し眺めてみようという気になっている。

ただ、たぶんこの本に限ったことじゃないのだろうけど、モデリングの世界って抽象的なモデルの話をしているようでいて、よくよく見てみると「一般的なオブジェクト指向言語」と書きながら、Javaべったりな実装や製品選択の話、それからJavaでSI的な話がいっぱいで、「ソフトウェアを作る」という視点を考えてみると狭い世界の話にも見える。抽象って常に具象に付かず離れずに議論しないといけないわけで、これはもう当然のことなのだろうけど。

それにしても、たかが足し算と引き算をするだけで「勘定パターン」とか名付けて型にハメないとやっていけないのかしら。そもそもホントにパターンを抽象化して再利用なんてできているのかと、現場の話も聞いてみたいと思った。

ともあれ、色々とクラス図やユースケース図を見ながら考えているうちに、なるほど確かにきちんとモデル化して整理しておかないと、システムの改変が面倒なことになるのかもなという気がしてきた。そもそもユーザーとシステム開発側で共通言語を用意しておくのはいいことなんだろうなぁ。というか、どっちにしろ何か色々と図やまとめ文書を書くほうがいいケースはきっと多くて、だったら先人が工夫を重ねた記法を学んで損はないはず、ということか。そしてそういう世界観を知ってから現実のソフトウェアをみれば、より得るところも多いのかもしれない。実際、Railsのhas_manyやbelongs_toって、つまりそういうことだったのかと、何となくモデル、オブジェクト、RDBの関係を理解しはじめている。「has_many :comments, :dependent => :destroy」みたいな一方のオブジェクトが消えたらごっそり関連するオブジェクトを消滅させるというRailsの記法って、UMLの表記法とも対応していてふつうのコトだったのだと理解した。

どうもぼくはRDBのことが分かってなさすぎだ。