設計図としてのUML
http://www.martinfowler.com/bliki/UmlAsBlueprint.html
ソフトウェアプロセスに影響を及ぼしたエンジニアリングは、長年、 ソフトウェアの設計をどのように表現すればよいか模索してきました。 (橋の建築に用いられる設計図のように)コードを書く他のグループに設計を渡せるようにするためです。 これは、貴重で単価の高いソフトウェア設計者を設計に集中させ、 多くの単価の安いコーダーを実装に集中させることにつながります。
UmlAsBlueprint はほぼ完璧です。 フォワードエンジニアリングでは、 設計図は設計者(プログラマがコードを書くのに詳細な設計をつくるひと)によって作られるのが理想的です。 設計は完璧でなければなりません。 設計事項は決定されており、 プログラミングは何も考えず、ただただ忠実に設計に従うものでなければなりません。
リバースエンジニアリングでは、 紙ドキュメント上の、もしくは、インタラクティブでグラフィカルなブラウザ上にあるコードの詳細情報を伝える狙いが設計図にはあります。 設計図は図を用いてクラスの詳細情報をすべて表示することが出来ます。開発者は理解しやすいものです。
タスクに必要な詳細情報を取り扱うため、設計図を描くには、スケッチを描くときよりもより洗練されたツールが必要となります。
専門分野に特化したCASEツール(Computer Aided Software Engineering)は、 このカテゴリに入ります(CASEツールという言葉は汚い言葉になってきていて、ベンダーは使わないようにしています)。 フォワードエンジニアリングツールを使えば、 図を描くことができ、それをレポジトリに保存することが出来ます。 リバースエンジニアツールを使えば、 ソースを読み込むことができ、レポジトリに保存し、 ダイアグラムを生成することが出来ます。 リバース、フォワード、どちらもできるツールは、ラウンド・トリップツールと呼ばれています。
ソースコード自体をレポジトリとして扱うツールもあります。ダイアグラムはコードのビューとして扱われます。これはプログラミングと密接に結びついており、プログラミングエディタと統合されている場合もあります。 私はこういうツールを「トリップレスツール」と呼ぶのが好きです。