UMLモデリングの本質第2版を読んだ

きっかけ

そういえば少し前にチームで振り返りをしている時に以下のようなKPTが出たのを思い出した。

初期のDB設計に時間をかけすぎた (Problem)
いや、でもDB設計に時間をかけるのはいいこと (Keep)
次の開発でもDB設計に時間をかける (Try)

そして、それから少し経ったある日、プルリクエストにこんなコメントがあった。

「未来のストーリーを使ってモデルを揺さぶってみるといいかも」

それでこの本の存在を認識したのだった。そしてもっとモデリングをうまくやりたい気持ちしかない我々はこの本を読むしかないのだった...

モデリング

この本で紹介されていたモデルの定義は「ある人にとっての、ある状況、あるいはある状況についての概念の明示的な解釈」。これは「システム仕様の分析学」の著者であるブライアン・ウィルソン(Brian Wilson)という人の言葉らしい。で、この定義のかなめは「ある人の解釈」という点ということだ。「解釈」は人によって様々なので、解釈のズレや誤ちが起きる。

それが前提にあるので、人々がお互いの解釈を明示して、すり合わせて、妥当性を検証する必要があり、モデリング手法というのが必要になり、解釈を表現するためにUMLなどのモデリング言語が生まれた。

この本ではUMLを使って、オブジェクト指向に基づくモデリングを行なっていく。

進め方

この本ではUMLのクラス図を使って「型図」と呼ぶ図を作っていく。ここでいう「型」はプログラミング言語でクラスとして実装すると決める前の概念の表現形式、とのこと。概念レベルの図なので「これどうやって実装するの？」みたいな表現も出てくるけど、そこは「実装レベルへの変換」というところで一応説明されている。

進め方は「図書館システム」と「駅の入出場管理」を例に使って丁寧に説明されていてよかった。

進め方の典型例とモデルの揺さぶりの説明だけ立ち読み風にご紹介しておく。

f:id:takatoshiono:20180709234735j:plain f:id:takatoshiono:20180709234801j:plain

実装レベル

この本では概念の状態遷移を「動的分類」、概念が複数の汎化構造を持つ場合を「多重分類」と呼んでいて、それを実装レベルに落とし込むにはこういう手法がありますよ、ということが紹介されている。コードも少し出てくるのだけど、この辺はまだしっくりきてない。また永続化はO/Rマッピングツールを使います、以上。という感じなので、実際に自分でコードを書いてみないと納得できないなあ、という感想だった。