UMLはUnified Modeling Languageの略で，オブジェクト指向分析，設計におい てシステムをモデル化する際の記法(図法)を規定した言語(ビジュアル・ラン ゲージ)です．UMLは現在のソフトウェア開発において事実上の標準となってき ており，これを学ぶことは開発者として必須要件になってきました．では，何 のためにUMLで図を書くのかって？用途はいろいろ考えられますが，以下の３ つのレベルが考えられます．

• レベル1: プログラムを書く前に，図で自分の考えを整理する．
• レベル2: チーム開発において，図でコミュニケーションする．
• レベル3: ユーザや顧客と仕様を検討する．

それぞれのレベルでの使い方を簡単に説明しましょう．

■ レベル1
プログラミングを始めてしばらくすると，動くプログラムを書くことがシステ ム開発だと誤解することがあります．完全な間違いではありませんが，仮に一 人で書いていたとしても，プログラムの規模が3,000行を超えたあたりで壁に ぶち当たるはずです．行き当たりばったりでコーディングしていたのでは見通 しがたたず，つぎはぎだらけのプログラムになってしまいます．

これを乗り越えるには，自分の考えを整理することが必要になります．プログ ラムだけを見ていたのでは，どうしても視点が小さくなりがちです．このよう なとき，プログラムをUMLで図解してみましょう．UMLはプログラムの構造や動 きを図でとらえることができるため，見通しよく全体を目で捉えることができま す．これが，UMLの利用法レベル１です．

さらに，プログラムの規模が30,000行を超えると一人で開発するのが難しくな ります．チームを組んで開発することになりますが，その際には分担を決めた り，システム全体の構造（アーキテクチャ）を決めたりする必要があります． 職業としてシステムを開発する，いわゆる「プロ」の現場では，これが通常の 姿でしょう．

その際に，設計を検討するための図としてUMLを使うことができます．数人でシステ ムの設計を討議することがよくあるでしょう．ホワイトボードなどを使って絵を描く 際にもUMLは役立ちます．全員がUMLの語彙を持っていれば，簡潔かつビジュアルに設 計の方針を示すことができます．あるいは，UMLの図をきれいに効率良く描くことが できる市販のCASEツールがいくつか存在します．これらを使ってもかまいません．こ れが，UMLの利用法レベル２です．

最後に，これがもっとも大切なことなのですが，システム開発とは「プログラ ムを正しく書く」ことではなく，「正しいプログラムを書く」ことです．プロ グラムが正しいかどうかを決めるのは，そのシステムのユーザやそのシステム に対価を支払う人，すなわち顧客です．ですから， システム開発では開発者がユーザや顧客と対話をして，どういうシステムを作る のかを合意する必要があります．この場面でも，UMLは活躍します．ユーザや顧客は一 般的にシステムを利用する機能に興味があり，プログラムの内部構造には興味は ありません．UML では，システムがどういう機能を持つのかをも表現できます． UMLで機能を記述し，それをもってユーザや顧客と話合い，システムの仕様を 決めます．これが，UMLの利用法レベル３ということになります．

以上のように，UMLを理解することでさまざまなレベルでのコミュニケーショ ンに役立つことになります．さらに，より多くの人がUMLを理解すれば，その コミュニケーションはいっそう容易になります．自分のために，チームのため に，さらには正しいシステムを作るために，UMLを習得しましょう．

ソフトウェアの図法としては，古くはフローチャートやデータフロー図， データベースのER 図などが知られています．オブジェクト指向が脚光を浴び， 90年代前半にオブジェクト指向分析，設計を支援する様々な方法論(メソドロジー)が出現しました． Grady Booch による Booch Method，Jim Rumbaughによる OMT(Object Modeling Technique)などが有名です．

この時代の問題は，各方法論で図の記法が異なっていたことです． その後しばらく記法にまつわる「宗教論争」のため，記法の統一がなされませんでした． 表現されている概念が同じであるのに表記法が異なっていたので， 実際に記法を使用する設計者たちは混乱してしまいました． 例えば，OMT ではクラスは長方形で描かれたのに対して， Booch Methodではクラスは雲型で書かれていたのです．また，両記法は開発者寄りで， ビジネスや利用者の視点が少なかったことも問題です．

記法統一への試みは，1994年に始まります． Grady Booch と Jim Rumbaugh が手を組んで，Unified Method 統合への協力が開始されました． また，ビジネスや利用者の視点でシステムを捉える「ユースケース」の概念を初めて著した OOSE (Object Oriented Software Engineering)の Ivar Jacobson も1995年にこれに加わり， UML1.0 が 1997 年に発表されました．この3人のメソドロジストのことを，愛着を込めて スリー・アミーゴ(three amigos)と呼ぶことがあります．

この間，多くの他の研究者からの提案が加えられています．

UML 1.0 は OMG(Object Management Group) に提案され，改良されたUML 1.1 が，OMG より標準化認定を受けることになりました．その後も，UML RTF(Revision Task Force)によってUMLの改訂は続けられています．1998年に UML 1.2 が，1999年にUML 1.3 がRTFから提出されました．UML 1.3は非常に安 定したバージョンであり，現在広く認知・利用されています．2001年秋現在の 最新バージョンは，UML1.4 となっています．詳細な仕様は，以下からダウン ロード可能です(もちろん英語)．

http://www.omg.org/technology/documents/formal/uml.htm

また，おそらくバージョン1最後のマイナーバージョンとなるUML1.5の改訂作業も続けられています． さらに，最初のメジャーバージョンアップである，UML 2.0へのロードマップも定まってきているようです．

さらに，2002年に向けて，UMLをISO(International Organization for Standardization) 標準に提案する動きもあるようです．こうなれば，UMLは完全な業界標準となり 産業界に大きなインパクトを与えるようになるでしょう．

UML は，オブジェクト指向分析・設計においてモデリングを行う言語です． え，言語なの？と思われるかもしれません．言語とは，意図を表現し，伝達し， 記録するものであると広く捉えるならば，日本語や英語が自然言語であり， JavaやC++がプログラミング言語である，というのと同じ意味で，UMLは 「モデリング言語」と言うことができます．さらに，JavaやC++がテキスト言語 であるのに対して，UMLはビジュアル言語ということができるでしょう．

UMLは，扱おうとしている問題を明らかにしたり(分析)，その解決法を組み立 てる(設計)際に，問題を図としてモデリングする過程を助けます．描かれたモ デルを複数人で共有してコミュニケーションしたり，自分一人でも考えをまと め，アイディアを展開する作業を助けます．これらの側面から，UMLの意図を 表現し，伝え記録するという役割，すなわち「言語」としての役割が明らかになると思います．

さて，UMLに規定されている図を，ダイアグラムと呼びます．UMLのダイアグラムには以下のものがあります．

UML では記法(ノーテーション)とその意味(セマンティクス)が定義されていま す．ただし，その図をどの開発フェーズでどのように使用するか，という「開 発プロセス」(開発工程)には意図的に触れられていません．これは，UMLの統 一過程で，プロセスと記法とが一体になって論争の的となるのを避け，まずは 記法のみを統一しようとしたことの現れでしょう．

とはいっても，実際の開発でどのように使うのかを明確にしないと，なかなか 利用しにくいと思います．ここでは，大まかな使用法の例を書いて見ます． なお，実際にプロセスの中でUMLを利用する具体例は，3章で詳しく解説します．

[分析フェーズ]
ここでは，ユースケース図を中心に要求を分析，定義します．個々のユース ケースに対してユースケース記述(具体的な処理の手順)を書き，そこから問題 領域の概念(クラス)の抽出が行われます．それらをクラス図を使ってモデリン グしたものを「概念モデル」とします．アクティビティ図，状態図，シーケン ス図，コラボレーション図なども補助的に使用されます．この「概念モデル」 ではシステムをユーザや顧客の言葉でモデリングすることが重要です．ここで は UML は，ユーザや顧客とのコミュニケーションを助ける言語という位置付 けです．

[設計フェーズ]
要求モデルを元に，決定されたアーキテクチャ(後述)の中に論理的な設計モデ ルを構築します．この作業には，クラス図を中心に，アクティビティ図，状態 図，シーケンス図，コラボレーション図等が使用されます．扱う問題領域に よって，不可欠な図もありますが，ほとんど使用されない図もあるかもしれま せん．このようにして作成された設計モデルが，設計フェーズの成果物となり ます．ここでは UML は設計者間のコミュニケーションのための言語という位 置づけです．

一方，システムの論理的な側面とは別に「アーキテクチャ」を決めておくこと が重要となります．アーキテクチャは使用するハードウェアや分散環境，デー タベース，通信，GUI, 言語やライブラリなどの開発基盤，さらには過去の資 産や組織体制などの環境的，政治的要因で決定されます．全く新規の開発では， アーキテクチャの決定は設計フェーズで行われることが多いですが，現実的 には，分析と並行して行われることもありますし，すでに決定されたアーキテ クチャにしたがって設計を進めることも多くあります．

UML では，物理的なソフトウェアおよびハードウェアの構成はそれぞれコン ポーネント図や配置図で記述することができます．

[実装フェーズ]
設計モデルを元に実際のコーディング(プログラミング)が行われ，コードが生 成されます．ここでは UML 図を見ながら，Java/C++/C# と言ったプログラミ ング言語を用いてプログラミングすることになります．しかし，設計モデルを CASE ツール等を使って書いている場合，そのモデルからコードのスケルトン (雛型)を生成することができることが多いようです．また，UML 2.0 で導入さ れる予定のアクションセマンティクスやアクション言語を利用すれば，コード までも完全自動で生成することも可能になるかもしれません．しかし現時点で は，このような完全自動のコード生成は，ごく限られた分野でのみしか現実性 がありません．実装フェーズの後にはテストフェーズがあります．重要なフェーズで すが，ここでは触れないことにします．

[パターン]
UMLとは直接関係ありませんが，分析，設計，アーキテクチャ決定の際には「パ ターン」を利用するのが現代的な手法です．パターンは，過去に有用さが実証されて いる分析時や設計時に現れる解を，「問題」，「文脈」，「解決」の組にして提示 し，名前を付けたものです．パターンは一つの「設計カタログ」として利用する ことができます．

分析においての概念モデル構築の際には，「アナリシスパターン」 (*)という分析レ ベルのパターンがまとめられています．また，設計モデルの構築の際には，「デザイ ンパターン」という設計イディオムがあります．さらに，アーキテクチャのパターン を集めた「アーキテクチャパターン」も存在します．

パターンには，それを利用する際のトレードオフや他のパターンとの関係なども記述 されています．パターンを知ることで過去何度となく繰り返された設計・分析上の発 明・発見のエッセンスを知識として得ることができます．現代的な設計者にとって， パターンのボキャブラリは必須科目となるでしょう(*)．