UMLモデリングの本質 (日経ITプロフェッショナルBOOKS)

UMLモデリングの本質 (日経ITプロフェッショナルBOOKS)

UMLを使ったモデリングについて、著者の長年の経験から導き出された方法や考え方が、分かりやすく具体的に記述されており、非常に参考になる。その中でもカテゴリー化の必要性の説明方法として、RDBの第３正規型と同じ理由をあげていて、そういえばそうかと改めて納得できた。全体的に、著者が実際にモデリングしてきた経験からの記述であり、机上の空論とは違い、内容に重さが感じられる。
実践問題が２つあり、１つめは「酒問屋の在庫管理」。どこかで見たと思ったら、これは山崎さん（私など足下にも及ばないほどの酒飲み）が作った、おもに形式記述言語の例題として使われている問題じゃありませんか。これって、時系列があるから、静的なクラス図だけで考えていたらダメなんだよな。なるほど、シーケンス図、アクティビティ図、オブジェクト図を使って、少しずつモデリングを良くしていく過程を説明するのは分かりやすい。２つめの問題は「航空券の予約」。こちらは、実際に若手３人にモデリングさせてみて、それを評価しながら説明しており、こちらも分かりやすい。
２つの例題で、『ゆさぶり』でモデルを洗練させるというのがある。概念モデリングが一通り終わった時点で、現時点での要求には入っていないが今後にあり得る要求を仮定して、それが実現できるようにモデルを修正する作業を行うとしてある。これにより、仕様変更などに強い柔軟なモデルが作られると説明してある。そして、実装のモデルには、概念モデルの全てを書くのではなく、その時点で必要な部分だけを実装モデルに書くと記述されている。仕様追加があった場合は、モデルにクラスなどを追加（変更では無い）だけで対応できるのが良いそうだ。
まさに、それは私も理想と思うモデリング方法であるが、そこまでは出来ていないし、たぶんやることもないと思う。私の場合、要件を満たす必要最小限の概念モデルは書くけど、概念モデルに未来の可能性を含めて書くことは無い。ただし、未来を否定する要素が現在のモデルにあったら、それは修正します。結果としては、シンプルで依存性が少ないモデルになるようです。
必要最小限の必要とは、誰にとって必要なのかと、いつの時点で必要なのかという、２つの範囲が大切だと思う。いつの時点については、本書では概念モデルでは未来の可能性を含むと明確に記述されいて、いろいろと刺激を受けて多くを考えるきっかけになった。
いろいろな意味で良い本でした。ちょっと時間をおいて、また読み直したい。
追記：この本の通りにモデリングするとアナリシスパターンのような感じになります。著者は開発でOODBを使っていると書いているので問題ないようだが、RDBを使うとしたら非常に苦労することになるだろう。RDBを使うことを前提にすると、概念のクラス図の書き方から変えた方が良いのかなと、最近は思っている。去年に研究系の開発で、OOバリバリなモデルをRDBに格納するために、O/Rモデル・マッピングに非常に苦労したもので。あれこそ、OODBを使うべきであった。でも、ある程度のパターンが見えてきたので、いつか整理したいものだ。