UMLモデリングの問題点（まだ仮説）

萩本順三 これだけでわかる!初歩のUMLモデリング―基礎から各種テクニックまで第一人者が伝授!! (@ITハイブックス) を読了。
わかったこと:

1. クラス図の作図には複数の目的がある

クラス図というものは開発のフェーズの進行に伴って何度も描き直される。

• 問題領域の構造を現す「分析モデル」
• 実装寄りの「設計モデル」

など。

2. 実装しない「クラス」もある

分析モデルに描いてあるクラスは、プログラムの class としてそのまま実装されないことも、普通にある。

3. 例えば「関連クラス」という苦しい存在がある

「会社」と「社員」が多対多の多重度を持つとき、社員オブジェクトにスカラー型のプロパティ「社員番号」を持たせると、一人の社員が、所属会社ごとに、異なる複数の社員番号を持てることを表現できない。
そこで、会社クラスと社員クラスの間にER図の交差エンティティのようなクラス「社員付加情報」をおいて、そこに社員番号プロパティを置く。これを関連クラスという。
関連クラスは実装しない。実装時に社員クラスに吸収するらしい。

以下感想。
関連クラスという「実装しないクラス」が出てくるのは、作図の目的が

• 問題領域の構造を現すこと
• クラスの責務を明らかにすること

という、二兎を追っているから。
問題領域の構造を現すには、交差エンティティ的なものを出さざるを得ない。
一方で、「社員番号を返す」責務は、どうしても社員クラスに置きたい。「社員付加情報クラス」というリアルワールドに対応物のないクラスを実装したくない。
それで、クラスなんだけど実装しないでね、という妙なものができてしまう。

「問題領域の構造」と「責務の割り付け」を１枚の絵で表すことはできないのに、それをやろうとしていることが、UMLモデリングなるものの問題なのではないかと。