第1部：ダイアグラム解説篇

Q1-2）UMLの9種類のダイアグラムとは？

羽生田栄一
株式会社豆蔵 取締役会長

2003/5/22

---

■UMLにはさまざまなダイアグラムがある

　UMLはモデリングのためのツールです。そしてモデリングはさまざまな目的を持っており、その目的に応じてツールとしてのUMLダイアグラムもいろいろ用意されています。ですから、UMLでモデリングをする皆さんは、目的に応じて適切なダイアグラムを選ぶ必要があります。

構造図	クラス図		モデルの組み立て部品の集合のこと。クラスと関係によって、（クラスの）構造と（クラス間の）関係を表現する
	オブジェクト図		システムのある時点でのスナップショット
振る舞い図	ユースケース図		システムのコンテキストと外部機能（ファンクショナリティ）の設定
	相互作用図	シーケンス図	相互作用するオブジェクトの時間順序系列すなわち、オブジェクトの集団メッセージ送信の時系列表現である
		コラボレーション図	オブジェクト集団における相互作用の直接表現やオブジェクト集団の接続トポロジーとメッセージ、スレッドの順序などを表現する
	ステートチャート図		1つのオブジェクトの生成から消滅までの状態遷移、すなわちあるクラスに属するオブジェクトの「ライフサイクル表現」を提供する
	アクティビティ図		1つのインタラクション全体における手続きの制御フロー。状態図の相対表現としてワークフローに焦点を当てる図
実装図	コンポーネント図		ソフトウェア-ユニット間の依存関係を示すもので、ソフトウェアモジュールの構成やバージョン管理も表現することができる
	配置図		オブジェクトやパッケージ、ファイルなどを実際のプラットフォームやネットワークノード上のどこに配置するのか、さらにはどのプロセス上で実行するのか、といった物理的な視点でシステム構成を表現する
図1 UMLの全ダイアグラム

■モデルの目的とUMLダイアグラムの種類

　UMLでモデルを作成する＝モデリングする目的はさまざまですが、基本的には大きく4つあるでしょう。

（1）	業務や問題領域の概念を整理し業務モデルや概念モデルとして表現する
（2）	システム化要求＝要件を整理しシステムの仕様を表現する
（3）	システムのデザイン（システム設計、アーキテクチャ）を表現する
（4）	システムの実装（記述言語やプラットフォームAPIレベルの詳細設計やサーバ、プロセス、コンポーネントの物理配置など）を表現する

　この4つ以外にもあるかもしれませんが、システム開発に直接かかわらないものはだいたい（1）の問題領域・問題整理の表現と考えておけばよいと思います。

　例えば、新しい製品企画のアイデアをまとめてクラス図で整理したという場合は、いちおう（1）に入るといえるでしょうし、ある会社の新しい事業展開シナリオを、オブジェクト図、クラス図、アクティビティ図、シーケンス図でビジネスモデリングしてみたいという場合も（1）に区分できるかと思います。

　目的（1）に限らず、とにかく最初は使えるダイアグラムで便利で見やすいと思えるものは何でも総動員すればよいのです。たいていのダイアグラムは、UMLのいずれかの種類のバリエーションとして解釈できると思いますが、もし、UMLとはみなせない図でありながら、どうしても使いたいものが現れれば、プロジェクトの中でUMLの補足ドキュメントという形で、メンバーがきちんと意味を理解できるように定義して利用することが重要です。

　逆に、ありがちなのが、意味のないUMLの使い方として、ソースコードをCASEツールを使ってリバースしただけのUML図です。これは、ドキュメントの納品物としての分量を増やすという意味はあるのかもしれませんが、ソースコードと同じ情報が表示されているだけですから読み手にとってはあまりうれしくありません。上記（4）の目的でUMLダイアグラムを使う場合には、詳細設計をするうえでポイントとなる個所を選んでフォーカスを当て、その部分だけモデルを作るようにしましょう。その方が設計や実装方針の趣旨が明確になり、伝達手段としてのモデルの効果が上がります。

　以下に、目的ごとの典型的なダイアグラム種別を書いておきますが、いまいったように、これにとらわれる必要はありません。便利なものは使ってください。

	構造	機能・振る舞い	状態活動	物理構成
概念	クラス図、オブジェクト図	ビジネスユースケース	アクティビティ図
仕様 （要求）		ユースケース図
仕様 （分析）		相互作用図（シーケンス図、コラボレーション図）	ステートチャート図（アクティビティ図）	（パッケージ図）、コンポーネント図、配置図
実現 （設計）
実現 （実装）
表2 モデリングの目的とUMLのダイアグラム

■UMLダイアグラムの記法共通ルール

（1）クラス（型）とインスタンスの区別

　UMLの基本はオブジェクト指向のモデル化です。従って、クラスとインスタンスを区別できる必要があります。UMLでは具体的なインスタンスをクラスから区別するのに、「オブジェクト名：属するクラス名」のようにオブジェクト名に下線を引くことで表します。

図1_1 インスタンスとクラスの区別

（2）パッケージ

　いくつかのオブジェクトやクラスをまとめて扱いたいとき、それらをパッケージに包含して表します。書類フォルダ型のアイコンで表示します。パッケージをさらにパッケージで包含して入れ子にすることも可能です。

図1_2 パッケージの例

（3）注釈や制約

　任意のUMLモデル要素に対して注釈を付加することができます。注釈を付けたい要素から破線を引いて付せん型アイコン内に記述します。また、制約は、｛｝でくくって自然言語や数式、OCLなどの論理式で表現します。制約とは、モデル要素が常に満たすべき条件のことです。

図1_3 注釈と制約の例

　なお、ほかにも細かな共通ルールは存在しますが、ダイアグラムを書くのに不都合はないので本連載では触れません。興味のある方は、UML仕様書を読んでください。

■各ダイアグラムの基本構造

　実は、さまざまな目的に対してどのダイアグラムを利用するかはお好みで選んでよいわけですが、上に述べたように、典型的なダイアグラムのセットというのはだいたい決まっています。その目的に便利なように、ダイアグラムの基本構成要素とビジュアルな表記が各ダイアグラムに用意されているのです。

　どのダイアグラムも一見すると複雑そうに見えますが、その中に含まれている基本構成要素をしっかりと押さえておけば、レントゲン写真を見るようにその図の骨格がすっきり見えるようになります。クラス図の基本はクラスと関係の織り成すグラフ構造ですし、シーケンス図の場合には各インスタンスを表すオブジェクト生存線とそれらの間のメッセージですし、ステートチャート図の場合には状態とイベントによる遷移からなる方向付きグラフです。

　そうした基本骨格のうえに、関係の種類（関連、集約、汎化、実現、依存）や特徴（ロール、多重度）を表す修飾が付いたり、状態や遷移にアクションを貼り付けたりして、より詳細なモデルに仕上げているわけですね。そうしたダイアグラムの成り立ちを原理的に理解したい人は、ぜひUMLのメタモデルを勉強するとよいでしょう（Q3-1）「UMLには言語としての文法があるんですよね？」参照）。

ダイアグラムの種類	基本構成要素	その他の主要要素
ユースケース図	アクター、ユースケース、関連	依存関係、拡張点
クラス図	クラス、関係（関連、汎化）	属性、操作、ロール、インターフェイス、関係（依存、実現）
オブジェクト図	インスタンス、関連	属性
シーケンス図	インスタンス、生存線、メッセージ	活性区間
コラボレーション図	インスタンス、リンク、メッセージ	シーケンス番号、スレッド
ステートチャート図	状態、イベント、遷移	アクション、アクティビティ
アクティビティ図	ステート状態、遷移、同期バー	依存関係、オブジェクト、送信、受信
コンポーネント図	コンポーネント、依存関係	インターフェイス、実現関係
配置図	ノード、リンク、コンポーネント	プロセス、依存関係、オブジェクト
(パッケージ図)	パッケージ、依存関係	インターフェイス
表3 UMLダイアグラムとその基本構成要素

■オブジェクト指向開発とUMLダイアグラムの関係

　では今度は開発の中でUMLダイアグラムがどのように使われていくかをまとめてみましょう。開発の上流工程では、業務や問題を整理し、要求や仕様をまとめる作業が行われます。開発の中、下流ではシステムの仕様を検証しながらアーキテクチャを検討し、システム設計、詳細設計、実装する作業が行われます。オブジェクト指向開発では、これらを複数回の繰り返しを通して段階的に完成させていくわけですが、いまは話を複雑にしないために、反復のことは脇に置いておきます。

[概念整理と分析]

　まず、問題や業務を整理して、そこに登場する概念とそれらの意味的関係を鳥瞰（ちょうかん）するのにクラス図を使います。これは属性や操作はほとんど定義していない非常にラフな概念クラス図を使います。その際、具体例をオブジェクト図で描いて、一般ユーザーの理解を促進するのも有効です。次に、ユースケース図を使って、システムの置かれたコンテキストをアクターとともに確定し、システムが外部ユーザーに対して提供すべきサービスのセットをユースケース図として定義します。それらのユースケースを分析して、システム仕様を定義するのに、ユースケース図に加えて主要なサブシステムやクラスのインターフェイスを定義したクラス図と重要なシステム操作に関するシーケンス図（および分野やシステムの特性によってはステートチャート図）を利用します。

[システム設計]

　仕様を実現するためのシステム構成をクラス図の一種であるパッケージ図で表すとともに、各ユースケースのサービス内容をシステムとして実現するためのオブジェクト連携をシーケンス図（またはコラボレーション図）で検討し、結果を設計クラス図にまとめていきます。

[詳細設計と実現]

　詳細設計を進める中で、設計クラス図を洗練していきます。クラス間での責務の割り振りや操作の詳細はシーケンス図やコラボレーション図を用いて検討します。設計に悩んだら、具体例をオブジェクト図を描いてイメージし、それを抽象化します。特に操作の事前条件と事後条件をオブジェクト図で表し、その途中を埋めるための設計を考えるというのはよい手段です。

図2 オブジェクト指向開発の流れとUMLダイアグラム

■ダイアグラム間の依存関係

　対象をモデリングする場合、何種類かのUMLダイアグラムを組み合わせてモデルを作りますが、それぞれのダイアグラムは独立しているわけではありません。どれも同じ対象を違う角度、視点から表現しているだけですから、その背後では互いに依存関係を持っているわけです。

　特にオブジェクト指向モデルではクラス図が重要といわれますが、その理由は、すべてのダイアグラムの情報が最終的にはクラス図に集約されていき、それがプログラムコードにつながっていくからです。ただ、どうしてもクラス図に反映しきれない情報というのがいくつか残ります。システム要求を表現したユースケースとオブジェクトの動的振る舞いを表現したシーケンス図（分野によってはステートチャート図）です。ですから、クラス図を中心にユースケース図とシーケンス図を含めて基本UMLダイアグラム3点セットとしているわけです。この三種の神器でモデルの90％は記述できますが、それ以外の微妙な部分は、モデル以外の補足文書や画面イメージとアクティビティ図、コラボレーション図、配置図、コンポーネント図などを適切に選んで利用することで、効率的なコミュニケーションが成り立つように工夫してください。その際、以下にまとめたような各ダイアグラム間の意味的な依存関係（セマンティクス）に十分注意してください。

ダイアグラムの種類	クラス図との関係	他のUML図との関係
ユースケース図	各ユースケースの実現は、適切なコラボレーションを表わすクラス図で表現 アクターは利用者や認証関連クラスの候補	アクティビティ図ないしはステートチャート図で各ユースケースに対応する業務ロジックを表現 コラボレーション図で実現方式を検討ユースケース多数の場合には、パッケージ図で分割管理もあり得る
オブジェクト図	オブジェクト図であたりをつけてから、共通性を考慮してクラス図に抽象化 オブジェクト図でクラス図中のある操作の事前条件と事後条件を表現する	オブジェクト図はコラボレーション図の一種
シーケンス図	登場する各オブジェクトの属するクラスはクラス図で定義されていること 各メッセージはその受信オブジェクトの属するクラスの操作として定義 シーケンス図でクラス図中のクラスの操作のセマンティクスを表現する	コラボレーション図に変換可能 あるユースケースの1シナリオを表現
コラボレーション図	（シーケンス図と同じ。加えて以下） オブジェクト間のリンクは、可視性を含めて、対応するクラス図と整合的であること	（シーケンス図と同じ。加えて以下） シーケンス図よりもオブジェクト間リンクの情報が加わっている
ステートチャート図	通常、クラス図内のあるクラスに属するオブジェクトのライフサイクルを表現 各状態や遷移のガード条件は、対応するクラス定義の属性で表現可能 各アクションはクラス図内に相当する操作が定義されている	相互作用図（シーケンス図、コラボレーション図）内の1オブジェクトに着目した際の受信メッセージとその副作用をすべてマージしたものが、そのオブジェクトの属するクラスのステートチャート図になっている
アクティビティ図	各アクション状態（プロセス）は、ユースケースや操作の候補 プロセスに付随する入出力オブジェクトはクラス図中で定義されていること	あるユースケースや操作の詳細定義 ステートチャート図で同等のことを表現可能
コンポーネント図	クラス図中のクラスやインターフェイスの実体(コンポーネントやファイル)の間の依存関係や使用関係、パッケージ包含関係等を表現	ここで規定されたコンポーネントの運用環境での配置や利用を配置図で表現
配置図	クラス図やパッケージ図で定義されたクラスやインターフェイスが実際のシステム運用環境にマッピングされる状況を表現	ここで規定されたノードに配置 利用されるコンポーネントはクラス図やコンポーネント図で定義
(パッケージ図)	各パッケージ内に個々のクラス図が対応する 各パッケージの可視性やインターフェイスと個々のクラス図の整合がとれていること	パッケージ図はクラス図の一種 コンポーネント図や配置図の代用にすることもある
表4 （クラス図を中心とした）UMLダイアグラム間の依存関係

■そのほかのダイアグラム（パッケージ図、ロバストネス分析図）

　ところで、UMLでは正確には何種類のダイアグラムが定義されているのか、というのは難しい問題です。数え方によって、人によって、微妙に変わってきます。いちおうこの連載では、9種類としておきましたが、人によって（例えば『UMLモデリングのエッセンス第2版（原題：UML Distilled）』のマーチン・ファウラー）は、パッケージ図を含めて10種類としている場合があります。

　パッケージ図は、UMLモデル要素の１つであるパッケージの間の依存関係を表現することを目的としたダイアグラムです。ここでいうパッケージというのは、複数のクラスをまとめたり、さらに小さなパッケージを内に含むソフトウェアモジュールのようなソフトウェア単位を表したり、対象システムを目的や構造で分割するための論理単位を意味します。ですから、典型的なパッケージ図の使い方としては、そのシステムの全体的な構成を表すために、レイヤ分割やサブシステム分割の様子やそれらの間の依存関係や可視関係を示すものです。つまり、パッケージ図はシステムのアーキテクチャの概要を示すのに有効といえるでしょう。

図3 パッケージ図の例

　また、オブジェクト指向開発方法論によっては、分析モデルを洗練し、設計モデルに移行する際にロバストネス図というクラス図の一種を作成することがあります。通常、ユースケースごとにロバストネス図を作成し、各ユースケースに登場するクラスをその役割（バウンダリ、コントロール、エンティティ）をヒントにして識別します。これらをマージして第1次近似の設計クラス図を作成するのです。ロバストネス図は、クラス図だけれど一方でそのユースケースの各シナリオをその図の上でトレースして検証するという使い方をするので、一種のコラボレーション図という意味合いもあります。いずれにせよ、通常のUMLダイアグラムの分類には含まれませんが。

図4 ロバストネス図の例

　もっと原理的な話をすると、オブジェクト図はコラボレーション図の一種だということができます。つまり、コラボレーション図でメッセージ送信を表現していければそれはオブジェクト図と見なせるわけです。また、アクティビティ図というのもステートチャート図の一種だということができます。大ざっぱにいうと、遷移および状態内アクション・アクティビティをすべてプロセス（アクションステート）として明示化したものがアクティビティ図だといえます（実は、アクティビティ図はステートチャート図と双対dualだという方がもう少し正確ではあるのですが）。

◆

　今回はUMLの9種類のダイアグラムとそれらの間の論理的な関係についてお話ししました。しかし、Q1-1）「UMLダイアグラムの基本を教えてください」でも述べたとおり、すべてのダイアグラムを利用する必要はありません。そのプロジェクトの目的やメンバーのスキルに応じて最小セットを利用するように心掛けましょう。ドキュメントを意味もなく複雑にすることは、プロジェクト管理をそれだけ難しくするからです。逆にいえば、そのプロジェクトのリーダーないしアーキテクトにはその問題ドメインやシステムの特性とメンバーのスキルを見抜いて適切なUMLドキュメントを選定するだけの技量が求められます。

［参考文献］
◇「UMLユーザーガイド」
　グラディ・ブーチ著、羽生田栄一監訳、ピアソン・エデュケーション
◇「UMLモデリングのエッセンス第2版」
　マーチン・ファウラーほか著、羽生田栄一監訳、翔泳社

Development Style FAQ UML篇 INDEXへ戻る

IT Architect 連載記事一覧