“実装できる”概念モデルは悪か

先週モデリング道場の議論が盛り上がった。
みつじさんという方が、バグトラッキングシステムの概念モデルをいくつか提示して、どれがいいかという議論を持ちかけたものだ。(詳細はメーリングリストのアーカイブからどうぞ)。
みつじさんのページ

議論の多くは、動的分類、多重分類の是非についてであった。あのコンセプトは、オデール氏が持ち込んで、ファウラー氏が広めたものだが、改めて実に曲者だと思った。あのコンセプトの魅力は、なんといっても「普通のプログラミング言語ではそのまま実装できない」というところだろう。概念モデリングには「俗世間から離れた、抽象度の高い、崇高な仕事」みたいな気分を味わわせてくれる一面があるが、動的分類&多重分類は、そういった気分を加速させてくれる。

こんな風に少々皮肉っぽく書いているが、自分も一度は動的分類&多重分類に魅力を感じたことがある。その証拠として、オブジェクトの広場にこんな記事が残ってしまっている。



しかし今は動的分類&多重分類は使わないようにしている。

まず開発者とのコミュニケーションの点で問題がある。最初に「実装できないモデル」を作り、あとから「実装できる形に変換する」のは二度手間だし、現場の技術者に理解してもらえないのでは本末転倒である。『アナリシスパターン』や『UMLモデリングの本質』を読み込んで、現場でスキーマ設計やアーキテクチャ設計をバリバリこなせるような技術者に出会うことを期待するよりも、実装しやすく、理解しやすいモデルを渡す方が実践的である。

顧客とのコミュニケーションでも動的分類&多重分類を使うメリットは特にない。ファウラー氏や児玉さんの本を読んでいる顧客に会う確率は、開発者の場合よりもさらに低い。時に、イケてるお客さんだとUMLのクラス図を使って、多くのコミュニケーションができることもあるが、それでも動的分類や多重分類をわざわざ使う必要はない。多重分類が必要な場面では、集合論のベン図を使って仕様を確認した方が確実である。動的分類を使う場面もほとんどは状態遷移である。動的分類では状態を列挙できるが、イベントや状態遷移のルールを表現できない。したがって、動的分類を使いたい局面では、クラス図よりも、ステートマシン図を使うのが筋だと思う。

自分ならば、バグトラッキングシステムの概念モデルは次のようにする。

上記の状態遷移の適切さについては議論の余地があると思う。しかしそういった具体的な疑問が沸くのも、ステートマシン図を作ったことの効果である。モデリングの目的は、仕様を確認するための議論を引き出し、その結果をまとめていくことだから、その目的に合う手法を使うべきだと思う。