UMLには(1)システムの静的な側面を示す図，(2)システムの動きを説明する図，(3)システムの構成などを説明する図があり，システムをさまざまな視点から分析し，その結果を図示することができる。今回は，クラス図，ユース・ケース図，ステート・チャート図などのUMLの全図の表記法を説明する。説明するのは図記号や矢印の意味などの表記上のルールで，難しい理屈は無い。限られたページ数で細かい表記ルールまでは説明できないが，簡単な図を読んだり書いたりするには今回説明したことだけで十分である。
システム設計書やプログラム設計書の表記法として有効なUML（Unified Modeling Language）＊を初心者向けに解説するセミナーの第2回である。前回は，UMLの基盤であるオブジェクト指向＊の考え方と，それがUMLの9種類の図で表記できることを説明した。今回は，それぞれの図の役割と基本的な書き方を説明しよう。
前回説明したオブジェクト指向が十分に理解できなかったという人は，オブジェクト指向の具体的なイメージをつかむための手段としてUMLの図記号や書き方を学んでほしい。もしもオブジェクト指向のことを難解な技術だと思っているなら，それがたった9種類の図だけで表せることを知ることで，大きな安心感が得られるはずだ。
基本をマスターしたらどんどん使おう
今回は9種類のすべての図を説明するが，UMLの図を描くために使われる図記号などは，今回説明するものがすべてではなく，もっと多くの図記号がある。しかしそれらを一気に説明すると複雑に感じ，UMLを使う気持ちになれなくなってしまいがちだ。それではUMLを学んだ意味がない。
皆さんは，普段何気なくフローチャート＊を書いていると思う。その書き方は，果たして完ぺきなものだろうか。完ぺきかどうかを気にせずに，思考の道具として自由にフローチャートを使いこなしているはずだ。UMLもフローチャートと同様に，ここで説明する基本だけをマスターし，完ぺきな表記方法かどうかなどは気にせず気軽に使ってほしい。後でささいな間違いに気が付いたら，その都度正しい表記を覚えていけばいいのだ。
1つのシステムの設計においてUMLのすべての図を使う必要はない。UMLは思考の道具である。皆さんの頭の中にある思考を図示する必要があるときに，それに適した図だけを選んで使えばよい。
UMLの9種類の図は，システムの静的な側面を示す図，動的な状態を示す図，プログラムの構成や配置を表す図——の3種類に分類できる（表1[拡大表示]）。以下ではこの分類に従って，各図の基本的な書き方を説明する。具体例を示すときには，電卓アプリケーションを題材として取り上げる。
|
システムの静的な図 |
システムの静的な側面を示す図には，オブジェクト指向設計の基本となるクラスやオブジェクト＊を表す「(1)クラス図」と「(2)オブジェクト図」，システム設計の初期段階に作成すると役立つ「(3)ユース・ケース図」がある。
(1)クラス図
クラスを図示するために使われるのがクラス図である。クラスは，3つの領域で区切られた長方形の図記号で表す（図1[拡大表示]）。上の領域に「クラス名」，中央の領域に「属性」，下の領域に「操作」を記述する。属性とはデータのことで，操作とは処理のことだ。操作はプログラム上関数となるため，操作を表す言葉の末尾に「（）」を付けることがある＊1。一般的に，1つのクラスは複数の属性と操作を持つ。属性と操作を省略し，クラス名だけのクラス図を描くこともできる。より詳しい表現として，属性にデータ型と初期値を明記したり，操作に引数リストと戻り値を明記したりすることもある。
例えば電卓アプリケーションをクラス図で表記すると，ボタン・クラス，液晶画面クラス，土台クラスの3つのクラスで表すことができる（図2[拡大表示]）。属性や操作の前にある「−」や「＋」は，クラスを使う側から利用可能であるかどうか（見えるかどうか）を表すもので，必要に応じて明記する。「−」は見えないこと（プライベート）を表し，「＋」は見えること（パブリック）を表す。
図2のクラス図では個々のクラスが独立しているが，実際は1つのシステムを構成する個々のクラスは何らかの関連を持つ場合が多い。例えば図2の電卓では，1個の土台に17個のボタンと1個の液晶画面が付いているので，土台クラスとボタン・クラス，液晶画面クラスは関連している。クラス間の関連を図に示すには，クラスを表す図記号同士を実線で結び，実線の両端に関連するオブジェクトの数＊2を示し，線の上に関連の方向を表す矢印と関連の説明を記述する（図3[拡大表示]）。
クラス間の関連には，「包含（合成）」や「継承（汎化）」という種類がある。包含（合成）とは，1つのクラスの中に他のクラスが含まれるという関連。継承（汎化）とは，クラスの機能を引き継いで他のクラスを作成するという関連である。クラス図ではいずれの種類の関連も，クラスの図記号を実線で結んで表す。包含の場合は実線の一方の端をひし形とし，継承の場合は実線の一方の端を白抜きの三角形とする。文章だけでの説明では難しく感じるが，とにかく「クラスの図記号を実線で結んで説明を付加し，関連を示す」と覚えてほしい。
(2)オブジェクト図
クラスがメモリー上に実体を持ったものがオブジェクトである。オブジェクト図では，オブジェクトを長方形の図記号で表す（図4[拡大表示]）。長方形を上下2つの領域に分け，上の領域に「オブジェクト名：クラス名」と，下線付きで書く。下の領域には「属性：型＝値」という形式で，オブジェクトの持つ属性の現在の値を明記する。長方形を2つの領域に分けず，「オブジェクト名：クラス名」だけのオブジェクト図でもよい。クラス図と似ているが，長方形の上の領域に下線を付けることで，クラス図とオブジェクト図を区別する。オブジェクト図はシーケンス図などの他の図の中で使い，複数のオブジェクト間の関連によって，システムの動きを表すことになる。
(3)ユース・ケース図
システムとその利用者の対話関係をモデル化した図がユース・ケース図である。ユース・ケース図は利用者から見たシステムを表しているので，開発者とユーザーが一緒に確認できる。ユース・ケース図をうまく使えば，完成したシステムがユーザーの要望に合わなかった，などという悲惨な結末を防ぐことができる。
ユース・ケース図の作成で重要なことは，(1)外部からシステムがどのように見えるかを考え，ユーザーの視点でシステムを見ることと，(2)ユーザーにも理解できるくらい分かりやすく書くことである。ユース・ケース図と後で説明するデプロイメント図は，コンピュータのプロでない，ましてオブジェクト指向など知るはずのないユーザーにも理解できる図である。このような図がUMLにあることは大いに注目すべきであり，大いに活用してほしい。
ユース・ケース図は，システム開発の初期工程で作成する。SEがユーザーの要望をヒアリングし，ユース・ケース図を作成する（図5左[拡大表示]）。ユース・ケース図では，「アクター」と「ユース・ケース」という2つの図記号を使う。アクターはシステムの利用者を示す。システムの外からシステムを起動したり，システムに対して情報を入出力したりするユーザー（人間）や他のシステムのことである。電卓の場合では，電卓を使うユーザーがアクターに当たる。アクターは人間の形の図記号＊3を使い，図記号の下にアクターの名前を記述する（図5右[拡大表示]）。
一方のユース・ケースは，アクターから見たシステムの機能を示す。電卓の場合では，電源を入れる，ボタンを押す，電源を切る——などがユース・ケースになる。ユース・ケースは楕円の図記号を使い，楕円の中にユース・ケースの名前を記述する。
一般的に，1つのシステムには複数のユース・ケースがある。ユース・ケースとアクターの関係は実線で結んで示す。1つのユース・ケースが複数のアクターと関係している場合や，1つのアクターが複数のユース・ケースに関係している場合がある。システムの領域を明確にするために，ユース・ケース全体を長方形で囲んでシステム名を記述する（図5の場合は「電卓」）。
ステレオタイプで関連を表す
ユース・ケース同士が関連を持つ場合があり，そのような場合，ユース・ケースを破線で結び，「＜＜」「＞＞」の記号ではさんで関連を説明する。この図記号は「ステレオタイプ」と呼ぶもので，図記号の中に独自の意味合いを追加する時に使う。ステレオタイプは「＜＜ステレオタイプ名＞＞」という構文で任意のステレオタイプ名（文字列）を記述してよい。ユース・ケースの関連を説明するためによく使うステレオタイプには，あるユース・ケースが他のユース・ケースを呼び出している（含んでいる）ことを表す「＜＜include＞＞」や，ユース・ケースを拡張した形で他のユース・ケースが存在することを表す「＜＜extend＞＞ 」がある。
クラス図などでも必要に応じてステレオタイプを使ってよい。「例外（エラーのこと）」を表す ＜＜exception＞＞ や「インタフェース（クラスの仕様のこと）」を表す ＜＜interface＞＞ などが，一般的によく用いられる。これまで，あれをしてもいい，これをしてもよいと説明してきたが，それぐらい自由に考えてUMLを使ってほしいということだ。
ユース・ケース関連の具体的な例を図6[拡大表示]の電卓のユース・ケース図で見てみよう。「電源を入れる」ユース・ケースが「数値を表示する」ユース・ケースを呼び出す，という関連があるので，2つのユース・ケースを破線で結び，ステレオタイプの＜＜include＞＞で表している。同様に「ボタンを押す」というユース・ケースを拡張した，「数値ボタンを押す」および「計算ボタンを押す」というユース・ケースが存在するので，破線の矢印と＜＜extend＞＞で表している。
皆さんは，「こんなに単純なユース・ケース図だけで，開発者とユーザーがコミュニケーションできるのだろうか？」と疑問に思われるだろう。その通りである。実際のシステム開発では，ユース・ケース図に何らかのドキュメントを付加する。例えば電卓の場合，「ボタンを押す」というユース・ケースに対して表2[拡大表示]のような動作を説明したものや，表3のようなユース・ケースのシナリオを説明したものを記述すると効果的だ。もちろん，表2や表3[拡大表示]の例と異なる表記方法を使ってもよい。ユース・ケースのドキュメントには，ユース・ケースが起動されるタイミングや，アクターとユース・ケースの間で入出力されるデータを明記することがポイントである。
|
システムの静的な図 |
ここからは，「オブジェクト間でどのようなやり取りが行われるのか」，「オブジェクトの状態は処理の流れと共にどのように変わっていくのか」といったシステムの動きを示すUMLの図を説明する。UMLの動的な図には，(4)シーケンス図，(5)コラボレーション図，(6)ステート・チャート図，(7)アクティビティ図——がある。
シーケンス図とコラボレーション図はどちらも，複数のオブジェクト間のメッセージ交信を表した図である。2つの図の違いは，注目しているものの違いである。時間軸に注目してオブジェクト間のメッセージ交信を表した図がシーケンス図。オブジェクト自体に注目してメッセージ交信を表した図がコラボレーション図である。
同様に，ステート・チャート図とアクティビティ図はどちらも，1つのオブジェクトの状態の変化を表した図である。状態自体に注目した図がステート・チャート図で，流れに注目した図がアクティビティ図である。
(4)シーケンス図
オブジェクトの相互作用（メッセージの交信＝操作の呼び出し）を時間軸に沿って示した図が，シーケンス図である。1つのシーケンス図は，1つのユース・ケースを表す。シーケンス図を使えば，特定のユース・ケースのシナリオを実現するために，必要となるオブジェクトの集合とオブジェクト間の交信を示すことができる。
オブジェクト間の交信は，メッセージのやり取りで実現される。プログラム上はオブジェクトの持つ操作（関数）を呼び出すことがメッセージの受け渡しになるが，シーケンス図ではそれを抽象的なメッセージとして矢印で表す。矢印の先は，メッセージを受け取るオブジェクトに向ける。
シーケンス図では縦方向に時間軸を取り，横方向にオブジェクトを並べる（図7[拡大表示]）。オブジェクトは，オブジェクト図で使った図記号で示す。オブジェクトは長方形の図記号で，その中に「オブジェクト名：クラス名」を書いて表すと説明したが，オブジェクト名を省略して「：クラス名」だけでもよい。「：クラス名」のように表記した場合，そのクラスのオブジェクト全般を意味する。
オブジェクトを示す図記号から垂直に破線を引き，その上にオブジェクトの活性区間を長方形で表す。オブジェクトの活性区間とは，オブジェクトが操作を実行していることを表すものだ。最初に操作を実行するオブジェクトの横には，操作を起動するアクターを記述する。シーケンス図は，ユース・ケース図を開発者向けに詳細化したものだと考えてほしい。
図7は，電卓の「ボタンを押す」というユース・ケースのシーケンス図だ。電卓のユーザー（アクター）がボタンを押して操作を開始し，押したボタンの種類に応じた数値がCPUで識別され，液晶画面に数値を表示する，というオブジェクト間の相互作用を示している。これまでに登場しなかった「： CPU」というオブジェクトは，このシーケンス図のために追加した。
メッセージには，単に1つのオブジェクトから他のオブジェクトに制御が移ることだけを示す「シンプル・メッセージ」，メッセージへの応答を待ってから処理を行うことを示す「同期メッセージ」，メッセージへの応答を待たずに処理を行うことを示す「非同期メッセージ」の3種類がある。メッセージの種類は矢頭の形で区別する（図7下[拡大表示]）。メッセージの種類を区別するのを面倒だと思うなら，すべてをシンプル・メッセージで代表させてもよい。
(5)コラボレーション図
コラボレーション図は，シーケンス図と同様に，オブジェクトの相互作用を示す図である。シーケンス図との違いは，コラボレーション図には時間軸が無い点だ。オブジェクトの関連とメッセージの流れが複雑な時，シーケンス図では図が複雑で分かりにくくなる時がある。そのような場合，時間軸が無いコラボレーション図を使うと効果的である。
コラボレーション図は，オブジェクト図にメッセージの流れを追加して作成する。メッセージを表すために使う矢印の種類は，シーケンス図で使うものと同じである＊4。オブジェクト間の関連を実線で示し，それに沿ってメッセージの流れを矢印で示す。矢印にはメッセージの順番を示す番号と，メッセージの内容を「番号：メッセージの内容（）」という形式で書き添える。メッセージの内容の後ろのカッコ内には，メッセージの引数を記述することができる。
図8[拡大表示]は，電卓の「ボタンを押す」というユース・ケースをコラボレーション図で表したもの。このユース・ケースには，(1)ボタンが押されたことをボタンからCPUに通知する，(2)押されたボタンに応じて表示する数値をCPUから液晶画面に通知する，という2つのシナリオがあり，それらのシナリオをメッセージ交信で表した図である。図8で「ボタンを押す」という操作に番号が付いていないのは，電卓のユーザーはシステム内のオブジェクトではないからである。
(6)ステート・チャート図
システムは，時間の経過やオブジェクト間のメッセージの交信によって変化する。システムの変化とは，システムを構成する個々のオブジェクトの状態の変化にほかならない＊5。オブジェクトの状態の変化を表した図が，ステート・チャート図である。システムを機能の集合体と考えた従来の設計スタイルでは，フローチャートで処理の流れを表していた。一方，システムをオブジェクトの集合体と考えるオブジェクト指向設計では，状態の変化が流れを表す。
1つのステート・チャート図で，1つのオブジェクトの状態の変化を表す。オブジェクトの状態は，角の丸い長方形の図記号で表し，長方形の中に状態の名前を記述する。状態の変化は，状態の図記号を実線の矢印で結んで示す。矢印の上には，状態の変化の要因を書き添える。初期状態と最終状態は，塗りつぶされた円，および，内部が塗りつぶされた二重の円で表す（図9上[拡大表示]）。
図9下[拡大表示]は，電卓の液晶画面オブジェクトのステート・チャート図である。液晶画面オブジェクトには「計算結果を表示している状態」，「1つ目の数値を表示している状態」，「2つ目の数値を表示している状態」の3つの状態があり，押されたボタンの種類に応じて状態が変化する様子を示している。「1つ目の数値を表示している状態」で数字ボタンが押された時のように，同じ状態に戻ることも状態の変化とする。
(7)アクティビティ図
アクティビティ図は，オブジェクトのアクティビティ（状態）の変化を表す図である。両端が半円の長方形の図記号でアクティビティを表し，長方形の中にアクティビティ名を記述する。アクティビティの初期状態と最終状態の表し方や，アクティビティの変化の表し方は，ステート・チャート図と同じである。アクティビティの変化の条件分岐は，ひし形の図記号で表す。これは，フローチャートの図記号に似ている（図10[拡大表示]）。
アクティビティ図は，ステート・チャート図と同様の目的で使われる。全く同じ機能の図とは言い切れないが，シーケンス図とコラボレーション図のどちらを使うか，および，ステート・チャート図とアクティビティ図のどちらを使うかは，個人の好みで決めればよい。
|
システムの構成と配置を表す図 |
システムの物理的な構成や配置方法を示す図には，(8)コンポーネント図と(9)デプロイメント図がある。コンポーネント図は，システムの中に存在するソフトウエア・コンポーネントを表す図である。Windows環境であれば，DLLファイル，EXEファイル，ActiveXコントロール（OCXファイル），データ・ファイル，ソース・ファイルなどが該当する。コンポーネントの図記号は，左端に小さな2つの長方形を付加した大きな長方形の図記号で，その中にコンポーネント名（DLLファイルのファイル名など）を記述する（図11左[拡大表示]）。
デプロイメント図は，システムの物理的な構成を示す図である。UMLでは，物理的なハードウエア（PC本体や周辺装置）のことをノードと呼ぶ。ノードは直方体で表し，その中にコンポーネントを配置する（同右）。
ノートとドキュメント
最後に，すべての図に共通した特記事項の書き方を説明する。UMLでは様々な図記号が使われるが，それだけでは表現が不十分な場合，「ノート」や「ドキュメント」を使って説明を補足する。
ノートとは図中に説明を付加する図記号であり，ドキュメントとは図の欄外や表形式で何らかの説明を付加するものだ。UMLは図だからといって，すべてビジュアルな図だけで表記しなければならないわけではない。図だけでは理解できないと思われるなら，ノートやドキュメントで自由に説明を加えるべきだ。
ノートの図記号は，図12左のように角の折れ曲がった長方形で表す。説明の対象となる図記号から引き出し線を延ばし，その先にノートを付ける。ノートの図記号の中に，説明の文書を記述する。ドキュメントの書き方には，特に規定はない。図の欄外に文書を付加するだけでもよいし（図12右[拡大表示]），表形式で説明を付加してもよい。何を書いてもよい。
以上で，UMLの9種類の図の役割と基本的な書き方を説明した。思いのほか簡単だと感じただろう。そして，オブジェクト指向がより明確に見えてきただろう。ここで得た知識があれば，書店で見かける分厚いUMLの解説書を読みこなせ，Rational RoseやVisio 2002，WithClassなどのUML設計ツールを使うことができるはずだ。次回は，システム開発の流れに沿ってUMLの具体的な活用方法を説明し，UMLを思考の道具として使いこなすポイントを解説する予定である。
|
矢沢 久雄（やざわ ひさお） 1961年栃木県足利市生まれ。（株）ヤザワ取締役社長，グレープシティ（株）アドバイザリースタッフ。アプリケーションの開発・販売，プログラミングに関する書籍や雑誌記事の執筆，およびセミナーなどにおける講演活動を行っている。自称，ソフトウエア芸人。 |
