UMLはプログラマの役に立つ

UMLは素人を騙すくらいにしか役に立たないらしい。 - 並列メモ？さんより、「UMLはプログラマの役には立たない」と言われて凹んだと言う話*1。

コメント欄より、

単に統一された記法が必要なら、C#だって一応世界標準が決まってるわけで、C#でよいですよね？
ただ、C#で書いてしまうと、プログラムが読めない人に「こんなの読めない」と言われて終わりなので、そういう場面で、「プログラムが読めない人にも読めるように図になっていて、かつ、世界標準」というのは意味があると思うので、「素人云々」と、言ったわけです。

UMLは素人を騙すくらいにしか役に立たないらしい。 - 並列メモ？

前提として「同じモノを、テキストベースの言語と図形言語で書いた場合、図形言語の方が（訓練していない人間にも）理解しやすい」としています。なんか 手足を縛る話とか、世間の一部でさも定説のように扱われているのですが、コレって、本当でしょうか。

たとえば回路図とかブロック図とかなら「図」でも 「素人でも簡単」と思われることはないでしょ？ コードと同じ情報量のUMLとか図形言語だって似たようなもので、とても素人の手に負えるものじゃないと思うのですよ。これって神話？それとも実は真実？――ということを考えてみるのは、ちょっと面白いのじゃないか、と思いました。

1.内容が軽いから。

一つ考えられるのは、通常UMLで書かれるようなものが、擬似コード相当の内容でしかないから、というのがあります。

実コードと 擬似コードを比べれば、そりゃ擬似コードの方が読みやすいです。なぜなら本質だけしか書いて無い。書くべき内容（＝関心事）についてもっとも簡潔に書いてあるから。簡潔さは力なり。簡潔さは Lightweight Language が Lightweight たる源泉ですね。ただ、この場合はUMLだから、じゃなくって内容に依存してるだけの話です。

2.図の方が向いてる内容だから。

だとしても、その内容は、図のほうが表現するのに向いている、というのはあるかもしれません。テキストは万能な表現ではなですし、実際技術本でも表とか図を交えながら解説しています。ただ、そうだとするならば、これは「素人にやさしい」じゃなくって、素人に限らない「人間にやさしい」じゃないかなぁ、と思います。

たとえば GoF のデザインパターン

オブジェクト指向における再利用のためのデザインパターン

これには、「UMLのようなもの*2」がいっぱい描かれています。この絵があるから素人にもデザインパターンが理解できる？・・・んにゃんにゃ、そんなことはないです。あれはちゃんとプログラムを書ける人じゃないと、「理解」は出来ないとわたしは思う。

じゃあ、読者がプログラマなのだから、あの図はいらないかというと、そんなことは無くって、あの図のおかげで理解がとても助けられます。（このケースでは UML に助けられるのは素人じゃなくってプログラマですね）

3.図の方がテキストよりも力があるから。

デザインパターンでも、図だけじゃなくテキストやサンプルコードを織り交ぜて説明してるとおり、全てにおいて図がテキストに勝る、というわけでは無いと思います。ようは適材適所、かな？じゃあ、図が向いている/向いていないって何でしょうか。

図はテキストに比べて大きな情報量を小さな規模で伝えることが出来ます。ぱっと見で情報の概略を掴み、じっと見で詳細を得ることができる、さすがは人類最強の視覚魔導の力*3。けれど、ある規模以上の情報を伝えるのに図は向きません。

漫画に小説が勝るものは饒舌さ。コンピュータは実行に饒舌なプログラムを要求するから 未だプログラミング言語は人に取って低レベルで、多かれ少なかれ「饒舌な言語」です。そうであれば図形ベースよりテキストベースのほうが向いていようというものです。

* * *

そんなわけで、プログラムとUMLダイアグラムは補完関係にあるとわたしは思います。ばっさりプログラムの構造について俯瞰したいときはUMLがいいけれど、実行可能コードはテキストベースの言語で書きたい。UMLの恩恵を受けるのは主にプログラマ。でも、ドメインエキスパート（素人さん）向けに説明するような内容の表記にも向いてます。

このような使い方をするとき、UMLはスケッチとして利用するのがもっとも上手い手だと思います。――つまり、わたしは「スケッチとしてのUML」の信者ってこと!

わたしの場合、設計する際いきなりコードを書きながら考えることも多いですが、UMLでスケッチしつつ考える、というのもそれなりに行います。書く媒体はだいたいホワイトボード、でなければ紙とペン。考えを纏めて整理しつつ設計を続けるときにスケッチをしたりします。それとプチプレゼンによく使いますね。

あとオススメなのが未熟プログラマの教育で、一緒に一つのホワイトボードに向かって対話しながら設計します。わたしはこれが好きです。

スケッチのコツは特徴をとらえて強調し、余計なディテールは省くこと。

これらが強調しているのは、完璧な仕様よりも、選択可能なコミュニケーションなのです。 というわけで「なんでもかんでもあったら分かりにくい（包括性は理解の敵）」なり。

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?cmd=view&p=UmlAsSketch&key=%A5%B9%A5%B1%A5%C3%A5%C1

包括性は理解の敵なり。くぅ〜、格好イイですな〜。なんだか座右の銘にしたい言葉だと思います。

蛇足：CASEツールについて

と言う文脈だと、ディテールの省き方を機械任せにして上手くやれるのなら CASEツールはよいのかもしれないと思ったり。わたしは殆ど使ったことはないので解らないのですが、実際 CASEツールをつかうとプログラマは楽になれるのかしらん？

*1:先生はやめて/一瞬、「minekoa先生…OOPがしたいです…」というネタかと思った

*2:OMT法

*3:関係ないけれど、速読って図を読むように文章を読む力だと思うのです（←妄想）