UMLの用途
実は、UMLは記法を決めているだけでその使い方までは定義していません。つまり、UMLをどう使うかは利用者に任されているため、記述方法さえ守れば自由にUMLを使って構わないのです。とはいえ、実際のシステム開発の現場では主に3つの用途で使われることが多く、UMLの使い方はそれぞれ異なります。
用途1.モデリング
要件定義フェーズでは、現行システムを理解することや、「何を作るか？」を意識してユーザーの要件を聞き出すために、モデリングという技法を使ってシステムの全体像を描く作業をすることがあります。この作業を行う人のことをモデラーと呼び、モデリングによって作成する図のことを概念モデルと呼びます。概念モデル自体はどのような表現をしても構わないのですが、一般的にはUMLのクラス図を使うことが多いようです。これは、後の設計フェーズを担当する設計者にとって理解し易いため、というのが理由のひとつです。
UMLを使ったモデリングでは、ユーザーの頭の中にある要件を情報として整理し、その情報同士の関係を定義して図式化することでシステムの要件を全体像として捉えます。実際にこの作業を見ていると、まるで最初からそこに存在したかのようにクラス図ができあがっていく様子にとても驚きます。また、クラス図の読み方にいくつか決まり事はあるものの、覚えるべき事はほんのわずかで直感的に判断できるため、UMLに慣れていないユーザーにとっても理解しやすく、ユーザーからの概念モデル（クラス図）に対する評価は総じて高いです。
もし、クラス図を使わずに言葉だけでユーザーの要件を整理しようとすると、部分的な要件の詳細化はできるものの、全体を把握することが難しく、「要するに何か」がぼやけてしまうデメリットがあります。一方、クラス図をユーザーと一緒に作り上げていくモデリングでは、全体像が視覚的に理解でき、さらにユーザー自身が気付かなかった課題も発見できるというメリットがあります。
ただ、モデリングの段階で作成するクラス図は、次に説明する設計レベルのクラス図に比べて非常に粒度が粗く、情報も不足していることが多いため、そのままではプログラミングすることができません。その代わり、「だいたいこんな感じ」というレベルに留めることで、早いうちからユーザーと開発者の間でシステムに対する要求を合意できるため、要件定義フェーズでは非常に有効です。
このように、モデリングではUMLのクラス図を使うことが一般的ですが、抽象度の高いクラス図の情報を具体化して補うステートマシン図やオブジェクト図もよく使われます。なお、システム機能の洗い出しをするためにユースケース図を使うこともありますが、一般の開発現場では機能一覧で代用することの方が多いようです。
用途2.設計
このように、要件定義フェーズにUMLを使って作成した図は、設計フェーズでより具体化されます。例えば、概念モデル（クラス図）やステートマシン図からデータベースの論理設計を行なったり、実装イメージに近づけるためにクラスの詳細化を行なったりします。
設計フェーズでは「どのようにして作るか？」を意識しますが、Javaなどのオブジェクト指向言語で開発することが前提となっている場合、UMLを使って設計図（クラス図やシーケンス図など）を書くことが多いです。実際に動くモノを作るための設計なので、モデリングに比べてより厳密性が求められるのですが、このとき表記方法が明確に定められているUMLが非常に役に立ちます（但し、業務仕様など個別のロジックをUMLで表現することは出来ません）。
設計フェーズにおいてクラス図を使う一番のメリットは、クラス間のインタフェースを早い段階から明確にできる点です。設計フェーズで書くクラス図には、クラスの属性や関係だけでなく操作も表すことになっています。例えば、受注クラスに受注登録という操作を持たせることで、そのクラスを使って受注情報を登録できることが分かります。ここでは、操作を実行するために必要な（入力）情報と、実行結果の（出力）情報を明らかにしてクラスのインタフェースを定義するのですが、その操作自体の中身を詳しく示す必要がないため、必要な情報を最低限の表記で示すことができます。
なお、設計フェーズでクラス図やシーケンス図などを作ることは必須ではなく、比較的小規模のシステムでかつ開発メンバー間で予め設計方法が共有できている場合には、必要に応じてコーディング済のプログラムからリバースしてクラス図などを作成し、設計書を後から作成することもあります。リバース機能は、この後説明するツールでサポートされています。
用途3.プログラミング
実行環境に依存しないUMLモデルから、ツールを使って実際に動くプログラムに変換する技術のことをMDA（Model Driven Architecture）と呼びます。MDAに則ると、モデリング→設計→プログラミングへの変換を全てUMLだけでできるようになるのです。
しかし、実際の現場ではMDAはほとんど普及しておらず、相変わらずプログラマーが設計書を見ながら手でコーディングするスタイルがいまだに続いています。現時点では、ツールそのものがサポートしている技術が未成熟であることもあり、実際の現場でMDAが積極的に使われることになるのはまだまだ先になりそうです。
UMLツールの種類
UMLで図を書く際には一般的にツールを利用します。ツールには無料で使えるものから有償のものまでさまざまですが、どれもUMLで定められている記法に従った図を書く機能を一通り備えています。
日本国内では、チェンジビジョンの無償UMLツール「JUDE/Community」がよく使われています。現時点でこのツールはUML1.4にしか対応していませんが、基本的な利用であれば問題なく使えます。有償版の「JUDE/Professional」はUML2.0に対応しています。
他に、有償ツールでお手頃なものにはスパークスシステムズジャパンの「Enterprise Architect」やマイクロソフトの「Visio」があります。また、プログラミングをしながらもっと手軽に使いたい場合には、ソースコードとの連携が簡単なオープンソースの開発ツール「Eclipse」のプラグイン（無償）も多数提供されています。
おわりに
UMLの記法は、誰が見ても一通りの解釈しかできないように厳密に定義されています。これは一見堅苦しくも思えるのですが、その厳密さによって曖昧さが排除できるメリットは非常に大きなものです。私は、UMLの存在意義は、システム化対象とする実務の世界をシステムの世界へ変換するための手段を提供することであると考えています。全ての開発者がUMLを通して同じものを見ることができるようになれば、情報の伝達はもっとスムーズになるはずです。
