UMLとは?書き方とクラス図・シーケンス図などの9つの図を解説

「UMLとはなんですか?」こう質問されたとき、あなたはすぐに回答できるでしょうか?システム開発時によく使う、シーケンス図やアクティビティ図などの説明時に「UMLの一種です。」と記載されていますが「そもそもUMLって何?」となってしまいますよね。

この記事ではUML(統一モデリング言語)の用語解説から代表的な種類の紹介、UMLを使うメリットなどについて解説していきます。

とくにクライアントとの打ち合わせにおいて、専門用語を正しく相手に伝える能力は重要です。クライアントがIT用語に詳しいとは限りません。そのときに自信をもって説明できるよう、この記事を読んで理解しましょう。

UMLとは?

UMLとは?書き方とクラス図・シーケンス図などの9つの図を解説

UMLとはUnified Modeling Languageの略語です。日本語では「統一モデリング言語」と呼ばれています。複雑なシステム開発をグラフィカルに表現し、記述方法を統一することで設計書の読みやすさやコミュニケーションの効率アップに役立ちます

UMLというのは手法の総称であって、UML自体が特定の記述方法を指すわけではないので注意しましょう。たとえば「プログラミング言語」はシステムを動かす言語の総称であって、「Ruby」や「PHP」という個別の言語を指しているわけではないのと同じです。

UMLも同じように、個別の手法は「クラス図」や「ユースケース図」などさまざまです。混乱しないように気をつけましょう。

UMLを使って何をするのか

UMLを使うことによって「システムの分析と全体像の視覚的理解」、「欠陥部分を発見」、「コミュニケーションの促進」といった効果が期待できます。

たとえば、新しくシステムを開発するときや既存システムを保守・機能追加するときに設計書がすべて文字のみで構成されていたら大変ですよね。作るほうもとても労力がかかりますし、別の人が読んだときに理解できるか怪しいです。

UMLはシステムの全体像(もしくは局所的な部分)を、図形を使って表現します。文字ベースの設計書よりもシステムの概要を把握しやすく、問題点の発見も容易になるのがイメージできると思います。

特にUMLが優れているところは、記述のルールが明確に決まっている点です。

UMLを使用するメリット

図形を用いてグラフィカルにシステムを表現しても、作成方法が人によって異なると保守性が高いとは言えません。AプロジェクトとBプロジェクトの設計図で、図表の書き方が異なっているとミスや誤解の原因にもなります。

そういった問題点を解消したのがUML図です。従来の文字ベースの設計書に比べて視覚的に理解しやすく、かつ記述ルールが明確に決まっているので保守性の向上につながります

UMLの歴史

UMLが普及する以前は数多くの表現ルールが乱立し、どのルールを使うべきかシステム開発者を悩ませていました。それがOMGObject Management Group:オブジェクト指向技術の標準化を行なう団体)によって正式に認定されたことを契機に普及が進みました。

UMLが共通言語として一気に普及して以来、開発者が母国語の違いを超えて設計図を読み書きできることができるようになり、その利便性は計り知れません。また、日本語特有のあいまいな表現を使った文書ベースの設計書よりも、UML図を見せたほうがコミュニケーションがスムーズに済むようになりました。

現在ではUML自体を説明する機会は少ないかもしれません。しかし、システム開発に馴染みのない人から質問をうけることが予想されます。UMLはもはや、システム開発にかかわる人は理解必須の概念となっています。正しく理解を深めましょう。

UMLを使って何ができるのか?

umlを使う人

実は、UML自体はあくまで「図形を用いた設計図の記法」に関するルールを定めているだけで、使い方についての定義はありません。つまり、UMLをどう使うかはシステム設計者の裁量に任せられています。

とはいえ、システム開発の実務においてはUMLの使い方はある程度パターンが決まっています。下記で、システム開発時のUML活用法を3パターン紹介します。どのパターンにも共通している点は「イメージの共有」です。

モデリングを使って全体像を描く

要件定義の段階では、クライアントの要望をヒアリングしてシステムの全体像を描く「モデリング」という作業が発生します。このときに、UMLの手法の1つである「クラス図」を用いてモデリングするケースが多いです。

UML(クラス図)を使ってモデリングする理由は、覚えるべきルールが少なく、かつ直感的に理解しやすいためです。ITに詳しくないクライアントでも理解しやすいです。クラス図については下記で詳述します。

ちなみに、モデリングをする人をモデラーと呼び、モデリングで作成した図のことを概念モデルと呼びます。

UMLを使って設計図を書く

全体像をUMLで記述した後、具体的な設計書に落とし込むときもUMLで記述することが可能です。モデリング時と比べて、UML図を作成する目的と厳密性が異なります。

モデリング時は「どのようなシステムを作るか」を意識する一方で、設計時には「どのようにシステムを動かすか」を意識します。モデリング時よりも詳細な内容をUML図に落とし込む必要があります。

また、小規模プロジェクト限定ですがメンバー間で設計方法が共有されている場合は、コーディング後のプログラムから設計書を作成することもあります。

MDAを使ってプログラミング

通常のシステム開発の流れは「モデリング→設計→プログラミング」です。モデリングや設計はUMLを使うことも可能ですが、「プログラミング」はプログラミング言語を使ってコーディングする必要があります。

しかし、ツールを使うことでモデリングからプログラミングまでの流れをUMLだけで完結することが可能です。この技術をMDAModel Driven Architecture)と呼びます。

しかし、実際の現場ではMDAはあまり普及していません。ツール自体が未成熟な技術であることと、業務上の仕様などUMLで記述しきれない部分があるからです。

今後MDAの技術がさらに発展すればUMLのみでプログラミングまで完結するようになるかもしれません。しかし現時点では、コーディングはいまだにプログラマーが設計書を見ながら手作業で行っています。

UMLの種類

umlの種類

最後にUML図の種類についてご紹介します。上記でも少し登場したように、UML図には「アクティビティ図」や「クラス図」「シーケンス図」などといった複数の手法があります。

種類は多いですが、それぞれシステム開発において頻出する単語です。この機会に概念だけでも覚えておきましょう。

クラス図

クラス図とは、クラス同士のつながりを表現した図です。どのクラスがどこのクラスとつながっているか視覚的に理解できるため、システム全体の構成を理解するときに役立ちます。

上記で説明した、システムの全体像をモデリングするときによく使用されます。直感的に理解しやすいので、クライアントへの説明時にも重宝します。

プレゼン時だけでなく、クラス図は分析・設計・実装など全段階で使用されます。クラス図はUMLの中で最も基本的な手法です。必ず理解しておきましょう。

コンポーネント図

コンポーネント図は、システムを実装する際に使われるダイアグラムです。システムを構成する要素(コンポーネント)間の関係を図で視覚的に表します。

関係性を表す、という意味ではクラス図と似ています。しかしコンポーネント図は「複数のクラスで構成される処理を、1つのクラスのように取り扱っている」点に注意です。

コンポーネント図は細かいクラスの集合を1つの要素(コンポーネント)として扱うことで、システムの内部構成を表現することができます。内部構成図を表現できるので、システム実装時に便利です。

配置図

配置図は、システムの物理的な配置構造を図式表現したものです。物理ハード要素と内部のコンポーネント、その間の通信関係を図で表します。

配置図によって、ハード要素ごとの依存関係を視覚的に理解することができます。コンポーネント図に物理的な要素を追加し、要素間の関係を表現したのが配置図と理解すると分かりやすいです。

パッケージ図

パッケージ図はシステム全体のクラスをグループ化するときに使用します。特にサブシステムやモジュール間の構造・依存関係を、視覚的に理解したいときに便利です。

パッケージ図とコンポーネント図は似ていますが、使う目的が異なります。コンポーネント図はシステムのインターフェイスを説明するときに使います。一方でパッケージ図は、システム内で関連しているクラスをグループ化するための手段です。

コンポーネント図はシステムの処理の流れを表現するときに便利です。よってクライアントへの説明時によく利用します。一方、パッケージ図はシステムの流れを把握するには不向きですが、関連する要素をひとつのパッケージとしてまとめて確認する作業に向いています。よって開発時によく使用されます。

パッケージ図を作成するときのルールですが、パッケージはファイルフォルダの形で表します。

ユースケース図

ユースケースとは、利用者目線で「このシステムはこんなことができる」を表現することでシステムのイメージを掴む手法です。ユースケース図を作成することによって、実際にシステムを利用するときの仕組みの流れと関係性が、視覚的に理解できます。

ユース(use)+ケース(case)という言葉を組み合わせて「ユースケース(use case)」というひとつの言葉になっています。ユースケース図は、システムの機能分析で使用されます。設計中のシステムと利用者、外部システムとのやり取りを記述します。

ユースケース図では「アクター」「システム」「ユースケース」「関係」の4要素が含まれます。アクターとは、システムを操作・利用する人のことを指します。それぞれの関係は詳細には示しません。

シーケンス図

シーケンス図は、アクターが操作したシステムがどのように実行されるか、相互作用の関係性を視覚的・時系列的に表した図です。

シーケンス図はユースケース図と似ています。しかしシーケンス図の場合は、命令から実行までの流れを時系列的に詳述している点、オブジェクト間の通信関係を全体的に表示している点が特徴です。

ユースケース図の場合は、アクターとシステムの関係を確認する場合に使用されます。一方、シーケンス図は「あるアクションに対するシステムの処理の流れ」を順番に表現できるので、エンジニア以外の方でも比較的理解しやすいのがポイントです。

コラボレーション図

コラボレーション図は、複雑なシステム処理の流れをロジックに基づいてモデル化するときに使用されます。

システム同士の関係性・相互作用を記述することによって、特定のタスクを実行する場合の、システムの相互関係を視覚的に把握できます。

コラボレーション図とシーケンス図はともてよく似ていますが、得意としている役割が若干異なります。

シーケンス図の特徴は「システム処理の時間の流れ」が分かりやすいという点です。上から下に、順序付けて表現されているためシステムの時系列順の処理がとてもわかりやすいです。

一方のコラボレーション図は「アクターを含む、システム間の相互作用」を分かりやすく明示しています。コラボレーション図でも時系列を番号付けすることで表現することができますが、シーケンス図よりも全体的なオブジェクトの相互関係・システム処理の流れを理解したいときに役立ちます。

ステートチャート

ステートチャート図は、システム上でイベント(アクターからの入力など)が発生した場合、「オブジェクトが実行可能なすべての動作」を図示します。

ステートチャート作成の目的は、オブジェクトの動作開始から終了までの状態変化をすべてモデル化することです。これをシステムのライフサイクルと言います。

シーケンス図では「ひとつのユースケースの事例を表現」するのに対して、ステートチャートは「オブジェクト(システム)の普遍的な状態」を表現しています。

アクティビティ図

アクティビティ図とは「システム実行の流れ」を表現した図です。システムが実行されるときは必ず終了へ向けてプログラムが事項されます。その流れを左から右に、流れに沿って図示したのがアクティビティ図です。

アクティビティ図はフローチャートとほぼ同じなので、比較的簡単に理解することができます。

シーケンス図と似ていると思うかもしれませんが、シーケンス図は「オブジェクト間の相互作用」を表した図です。アクティビティ図はオブジェクトではなく、アクティビティ(処理内容)について順序立てて記述します。

場面に応じてUML図を使い分けよう

UMLについて理解することはできたでしょうか。概念的には理解できても、最後に紹介した手法を使いこなすには実践あるのみです。

UMLを理解するのは大変です。しかし、覚えたらシステムの仕様書などが読めるようになり、一気にシステム開発への理解が深まります。

変化の激しいIT業界ですが、基礎的なルールは意外と変わらないです。経験の浅いうちはUMLに限らず、基本的な用語・開発手法を理解するように心がけましょう。

フローチャートやワイヤーフレーム、プレゼン資料まで作れる | Cacoo(カクー)


記事の監修
砂川 祐樹

Backlog開発チームで開発を担当する傍ら、プロジェクト管理について噛み砕いて解説する入門サイト、サル先生のプロジェクト管理入門サル先生のバグ管理入門の制作に携わった他、プロジェクト管理を楽しく学べるボードゲーム「プロジェクトテーマパーク」を制作。プロジェクト管理を身近なものとして広めるヌーラボの活動に関わっている。


記事の作成
Cacoo編集部

フローチャートやワイヤーフレームに関する情報を発信しています。お役に立てた情報がありましたら是非シェアをお願いします!
フローチャートやワイヤーフレーム、プレゼン資料まで作れる | Cacoo(カクー)
についてはこちら

オンライン コラボレーション作図ツール

250万ものユーザーがなぜ Cacoo を選んでいるのかご自身の目でお確かめください

無料トライアル