　これは（1）のノートとモデルに矛盾がある場合と似ていますが、こちらの場合はもっと深刻です。名前はモデル図のありとあらゆるところに出てきます。そもそも名前はモデリングの最初の一歩であり、基本中の基本の「キ」です。モデル図を読むときは、まずモデル図に登場する名前から連想してモデルを読み解きます。その名前が道先案内人、最初の道しるべです。

　例えば、機能クラス（データを持っていなくて機能（操作）しかないクラス）にも関わらず、いかにもその名詞のデータを持っているかのようなクラス名が失敗例になります。この例としては文書検索だけをするためのクラスの名前を「文書検索DcoumentRetrieval」とせずに「文書Document」とすると、文書データを持っているように思わせ、このモデル図を読み進めることになります。そして後になって機能クラスであったことが分かり、名前を恨むことになります。

　矛盾がある名前もモデル図では害悪ですが、情報量の少ない名前も良くありません。クラスの属性に「情報」とか「データ」とかの名前を付ける必要はありません。属性は全て情報であり、データであるのは当たり前ですので情報量が増えません。同様にユースケースに○○○機能のように機能を後ろに付ける必要はありません。

（5）その他の矛盾がある図

　上記以外に、関係があるのに矢印がない図や同じグループに入っているはずなのに別に記載している図（例．クラス図で1個のクラスの属性であるはずなのに別のクラスに属しているなど）、同じものが重複している図、明らかにあるはずのものが描かれていない図などがあります。このように矛盾は至るところに出てきます。

（6）モデルの正確さと完全性（曖昧さと捨象化）

　ここはモデル図の失敗例の紹介ではありません。モデルの正確さと完全性（または曖昧さと捨象化）と、ここで紹介している矛盾があるモデル図との関係を見ていきます。第1回の記事でも書いたように、モデル図はプログラムと違います。目的も粒度も必要となる正確さや完全性も違います。ここの矛盾があるモデル図の失敗例を見ると、モデル図にも正確性と完全性を求めているように思うかも知れませんが、決してそうではありません。

　矛盾しないように正確さを求めることとや、登場人物の関係を間違いなく描く完全性を求めることはしていません。まだ決定できていないところや変更が入りそうなところをホットスポットとして記述し、当たり前なことなので描かずに済ませてしまう（捨象する）こともモデリングでは必要です。

　これとうっかり、ついつい、本当に忘れてしまったこととは明確に区別することです。このためにはホットスポットであることを明記して将来変更が入るために描かないことを理解させ、また用語辞書などを整備して描かない範囲を明記することが必要になってきます。手抜きはどしどし行ってください。ただし計画的な手抜きだけです。アドホックな手抜きは駄目です。

効率が悪いモデル図