UMLはプログラマの役に立つについて、簡潔に。
先日のエントリーで、抽象度が高いと図が有利で、具象的なのはテキストが有利 みたいに途中から脱線してしまいました。
図とテキストの得意範疇は抽象度に強く依存しているわけじゃないです。複雑になってくると図のメリットが薄くなるということだけ。自分で自分の文章に混乱してしまいました。あまりにお馬鹿なのでリベンジです。（でも結局は「ファウラー読め」で終わる話になっちゃったり）
* * *
たとえば概念の構造を書く場合とか、文章で説明するよりも概念間の関連を線で結んだような図の方が解りやすい（パッと理解出来る/理解が早い）と思います。
ただ、ある程度複雑になっちゃうと、文章を読むように 線をたどらないと解らなくちゃっちゃうし、それ以上複雑になると、そもそも線を引く余地が無くなってしまう。図は万能ではないですし、本質的に難しいものは何で書いたって難しいです。（前提おわり）
ここに、UMLを「図」として捉えるか、完全な「モデル記述言語」として捉えるかという話があります。
UMLの本質についても見方が異なります。わたしの考えでは、UMLのユーザー、特にスケッチのユーザーは、UMLの本質はダイアグラムであると考えている人が殆どだと思います。しかし、UMLの作成者はダイアグラムを二次的なものとし、UMLの本質はモデルにあると考えています。ダイアグラムはメタモデルの表現にすぎないと言う見方です。この考え方は、設計図面としてのUMLユーザーとUMLプログラミング言語派のユーザーにとって納得のいくものです。
設計図面と捉えれば、既にモデルをプログラミング言語を用いて書ける人間には「UML、なにそれ、おいしいの？」かも*1。なれば、「UMLはプログラミング言語が使えない素人向け」となるのもつながります。
ただ、設計図面として UML を使うときは、正しいことと包括的な、「図面」だけで完結するようなものを求めます。そうなると図といえども複雑で読むのが大変だし、そもそも内容のハードルが高いので、「設計図面」をソフトウェアの素人に扱えるとは、あんまり思えないですね。なるほど、だから素人を解った気にさせる＝「騙す」か〜。
一方、コードをUMLと交換したいなんて思わない、普通(?)のプログラマが恩恵を受ける UMLの使い方が、スケッチとしてのUML です。
「ここはね、こうなって居るんだ」とポイントをスケッチを押さえて説明するのはとても有意義です。自分で設計を考えているときのデッサンにもいい。そのためには「完全であること」よりも「よく伝わること」が大切です。
設計図面としての UML がジャンジャカ宣伝して目立っているから、この使い方はハックのように感じてしまうかもしれないけれど、そう特殊な用法でなくって、多分誰でも目にしていると思います。
例えば、GoF のデザインパターン本では、ダイアグラムと本文、サンプルコードを併用して説明しているけれど、このダイアグラムはスケッチ。肝心要の部分ををスケッチで説明してくれるのは、理解をしやすいでしょ？、とか。
わたしの場合、設計する際いきなりコードを書きながら考えることも多いですが、UMLでスケッチしつつ考える、というのもそれなりに行います。書く媒体はだいたいホワイトボード、でなければ紙とペン。考えを纏めて整理しつつ設計を続けるときにスケッチをしたりします。それとプチプレゼンによく使いますね。
あとオススメなのが未熟プログラマの教育で、一緒に一つのホワイトボードに向かって対話しながら設計します。わたしはこれが好きです。
スケッチは、「図 VS テキスト」の図式にマッピングしたら擬似コードに近い存在、になるのかな？コツは特徴をとらえて強調し、余計なディテールは省くこと。
これらが強調しているのは、完璧な仕様よりも、選択可能なコミュニケーションなのです。 というわけで「なんでもかんでもあったら分かりにくい（包括性は理解の敵）」なり。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?cmd=view&p=UmlAsSketch&key=%A5%B9%A5%B1%A5%C3%A5%C1
包括性は理解の敵なり。くぅ〜、格好イイですな〜。なんだか座右の銘にしたい言葉だと思います。
（よしっ！つながった！）
* * *
このテーマにはいろいろ思うところがあって、
- 昔の抽象データ型のOO から派生した、認識の分類法的な考えから発展したOOADと UML は善くマッチするのかもしれない。そういえば 新聞記事を UML に翻訳するとかあったなぁ。そう言う人たちは、その分析をそのまま書けるプログラミング言語が欲しいのかもなぁ。（分析したけれど、今のOOPLだと力不足でそのまま実装に落とせない、――というフレーズをよく耳にしたような）
- 図は空間に意味を持たせるのが強みだけれど、だからこそ空間が制約になるのかな？モデルは物理的に存在するものじゃないから、図の制約の中に必ず書けるとは限らないのが問題だ、とか。逆にこの制約がいい、とか。と、素人考えするのだけれど。
とかとか。これらについてはそのうちおいおい。
