http://www.martinfowler.com/bliki/UmlAsSketch.html

UmlAsSketch uml

この使用方法では、 開発者はUMLをシステムの側面を伝えるのに使います。 設計図と同じように、スケッチをフォワードエンジニアリングやリバースエンジニアリングの方針として使うことが出来ます。 フォワードエンジニアリングでは、 コードを書く前にUMLを描きます。 リバースエンジニアリングでは、 既存のコードからUMLを作成し、 コードを理解しやすくします。

スケッチの肝は取捨選択が可能なところにあります。 フォワードスケッチングを行えば、 今から書こうとするコードのだいたいの項目を挙げて、 チーム内で話し合うことが出来ます。 スケッチを描くと、これからやろうとしていることについてのアイデアや選択肢を話し合う際に役立ちます。 すべてのコードについて話さなくてよいのです。最初に同僚に説明したいと思う重要な個所だけでいいのです。もしくは、プログラミングする前にビジュアライズしておきたい設計個所だけでよいのです。この種のセッションは簡単に済みます。 数時間分のプログラミングについて10分間のセッションで話し合ったり、 2週間分のイテレーションについて一日で話し合ったりします。

リバースエンジニアリングにおいては、 システムのある部分がどうやって動いているのか説明するのにスケッチが使えます。 すべてのクラスを表す必要はありません。 深くコードを見る前に、興味深いところ、話す価値のあるところについて表せばよいのです。

スケッチはとてもインフォーマルでダイナミックなものですから、 素早く、協調しながら行う必要があります。 そのため、ホワイトボードがよく使われます。 スケッチはドキュメントの中でも役に立ちます。 こういった場合、完璧さよりもコミュニケーションが重要視されます。 ライトウェイトなドローイングツールでスケッチを描きます。 UMLのルールに厳密にせよと口うるさく言うひとはあまりいません。 本に載っているほとんどのUMLは（私の本も）スケッチです。 これらが強調しているのは、完璧な仕様よりも、選択可能なコミュニケーションなのです。 というわけで「なんでもかんでもあったら分かりにくい（包括性は理解の敵）」なり。