だらだらメモ:
■変なUML
独自に拡張したような感じの、変なUMLを描く人がいる。
そういう人は、「もしかするとこれはUMLじゃ表現できないものかもしれない」ということを考えてみるべきだと思う。
もしくは、まず非UMLな図で表現してみて、それをUMLに落とし込んでいくのが良いやり方かもしれない。
でも人に見せる時は「非UMLな図」の方が伝わったりする。
絵の上手い下手にもよるけど。
■非UML図を描く時の注意点
非UML図を描く時は、混乱を避けるため、UML に見えてしまわないように気をつける。
■UMLよりもわかりやすく、誰にでも理解できるツールがある
「文章」がそれ。
文章でストーリーを書くと、動きをイメージしやすくなる。
…
以下、かなり想像および妄想入ってます:
■UMLが嫌いな理由
おそらく僕はUMLが嫌いなんだと思う。
どこかの誰かが勝手に決めたことに従わなければならないのが我慢ならないんだと思う。
UMLの思想が気に食わない。
広い範囲をカバーしようとしすぎ。欲張りすぎな気がする。
クラス図とシーケンス図以外はほとんどまともに使ったことがない。
クラス図とシーケンス図に関しては「発明しれくれありがとう」と言いたい。
ていうか、元ネタはこれらできる以前にすでにあったのかな。
今のところUMLには、ソースコードを図に置き換えるぐらいの用途でしかその価値を見いだせない。
ソースコードを図で正確に表せるというのは本当に素晴らしいと思う。
例えば、継承関係を表現するのにクラス図の表記法以外のやりかたは思いつかない。
でも逆にUMLは、ソースコードから離れたところではあまり使い物にならない気がする。
いや、使い物にならないというか、使うメリットがない。
UMLを駆使した基本設計書とかあったとしたら、うーん、見たくない。
結局、UMLはプログラマ同士のコミュニケーションにしか使えない。
それに、プログラマ同士のコミュニケーションにおいてもUMLが有効な範囲は限られてくる。
結局、あるクラスの動きを知りたければJavadoc等を読むことになるし、もっと詳細が知りたければソースを読むことになる。
また、クラス図はクラス同士の関連を表すのに便利なんだけど、Eclipse等の高機能なIDEを使えばだいたいの関連はすぐに把握できてしまう。
詳細なクラス図を見れば、クラス同士の関連がソースコードに近いところまでかなり把握できるけど、やっぱそれにも限界があって、その先はソースを見るしかない。
ま、実際にはクラス図だけを見るなんてことはなくて、それを補足するための文章があったり口頭での説明があったりするんだけど、実はその文章なり言葉なりの方が重要だったりする。
クラス図はたんなる補足資料というわけ。
逆に、クラス図だけを見て、言葉による補足なしにその意味をちゃんと理解できるのかなぁ？って思う。
■UMLの良いところ
UMLによって、多くの人が「絵で表現することの重要性」に気づいた。（多分）
■UMLはアーチストには向かない（戯れ言）
えー、僕は自称アーチストなわけですが、そいう人間にとっては、UMLは表現の幅を狭めるだけのものでしかないわけでして。
で、なんと言いましょうか、アーチストは壁をぶち壊すことも時には必要ですし、そのとき、既存の枠組みは単なる足かせでしかないわけでして。
■道具としてのUML
人は道具によって思考が制限される。
なぜなら、ある道具使い始めると、その道具によって表現可能な方向でしか思考を展開できなくなるから。
人はそういった思考パターンに簡単にハマる。
例えば、Java しか知らないプログラマは、Java の流儀でしかプログラムを考えることができないと思う。
それ以外の可能なプログラムというものを知らないから、想像しようがないのだ。
そういう意味で、UMLは人間の思考をすごく制限してしまう道具だと思うのだ。
クラス図に登場するクラスの箱にメソッドやフィールドの情報が大量に書かれているのを見るのが嫌いだ。
絵で表現できることはたくさんある。
確かに標準化や統一性というものは大事だけども、コミュニケーションにおいて一番重要なのは「最短時間で相手に伝わること」だ。
UMLは、ほとんど箱と矢印で成り立っている。
あと、UMLで書くと特徴のない絵になる
正直、どれもぱっと見ただけだと同じに見えてしまう。
色をつけたりすれば良くなるかもしれないけど、変な小細工は混乱の元になりかねない。
