UML（統一モデリング言語）

共通言語がなければ、設計図は役に立たない

動画は、こんな想像から始まります。50階建ての高層ビルを建てるのに、配管工はスペイン語しか話せず、電気技師は日本語しか分からず、コンクリートを流す職人は古代の象形文字しか読めない。設計図がどれほど優れていても、2階部分を作る前に崩れてしまいそうです。システム開発の現場でも、同じ「大惨事」がいつも隣り合わせだといいます。

発注する経営層も、プログラミング言語の違うエンジニアも、誤解なく意思疎通できる共通言語が要る。そこで出てくるのがUML（Unified Modeling Language、統一モデリング言語）です。動画の定義は「オブジェクト指向のプログラム設計図の統一的な表記法」。かつては技術者がそれぞれの流儀で設計図を描いていたところに、世界共通のルールを持ち込んだもの、という説明でした。

（補足：UML の仕様は OMG（Object Management Group）が管理していて、最新の正式版は2017年12月の Version 2.5.1 です。なお UML は、2012年版の規格 ISO/IEC 19505（UML 2.5.1 とは別の版）として国際規格にもなっています。規格の版と OMG の最新版は同じではありません。）

動画の比喩では、UML の図は角度や縮尺の違うレンズです。巨大なシステムを1枚の図で表すのは無理なので、見たいものに合わせてレンズを替える。この回では、次の8つの図が登場します。

• ユースケース図・アクティビティ図：エンドユーザーの目線に近い、外側のレンズ。
• シーケンス図・コミュニケーション図：システム内部のやり取りを見るレンズ。
• クラス図・オブジェクト図：構造の「設計」と「実物」を見るレンズ。
• コンポーネント図・ステートマシン図：全体の構成と、1つの要素の内側へのズーム。

ユースケース図：誰が何をするかを描く

動画は、新しい物流サプライチェーンのシステムを設計する場面を例にします。最初に使うのはユースケース図で、エンドユーザーにも分かるように「誰が何をするのか」を図にしたものです。システムに求められる機能的な要求を表します。

ここで出てくる重要な概念が2つあります。1つ目はアクターで、システムを使うユーザーや、連携する外部システムのことです。2つ目はユースケースで、システムが行う処理、つまりシステムの利用の仕方を表します。

（補足：UML の仕様書でも、アクターは「システムと関わる、ユーザーやほかのシステムが担う役割」とされています。ユースケースは、システムが行う一連の動作で、アクターにとって価値のある結果をもたらすものです。）

アクティビティ図：業務の流れと条件分岐

要求が決まったら、次はその機能が現場でどう流れるかを見ます。そこで使うのがアクティビティ図で、システムのアクティビティ（活動）、データの流れ、実施の条件分岐などを表します。流れと条件分岐が見えるので、ユーザーにも理解しやすいのが特徴です。

シーケンス図とコミュニケーション図：内部のやり取りを見る

ここからは、システム内部の「時間」と「関係性」のレンズに切り替えます。まずシーケンス図は、メッセージのやり取りを時系列に沿って並べた図です。メッセージと呼ばれる矢印で、各オブジェクト間の応答を表し、処理の流れを時系列で見せます。上から下へ時間が進み、矢印がポンポンと飛ぶイメージです。

動画が挙げる理由は、処理の順番が命綱だから。もし在庫管理サーバーが「在庫を確保した」という応答を返す前に、決済サーバーがクレジットカードの引き落としを始めたら、商品がないのにお金だけ取られる大クレームになります。誰が誰に矢印を出し、どの応答を待ってから次に進むのかを、時系列で厳密に決めておく必要があるわけです。

（補足：UML 2.5.1 の仕様書では、コミュニケーション図も「メッセージの順序」を表せます。線の上のメッセージに番号を付けて順番を示す方式です。仕様書は、コミュニケーション図は、複合フラグメントなどの構造化の仕組みを使わない単純なシーケンス図に対応する、と書いています。動画の「時間軸と空間軸」という対比は、2つの図の見え方の違いをつかむ覚え方として使えます。ただし、コミュニケーション図は順序をまったく表せない図ではありません。）

クラス図とオブジェクト図：設計と実物を行き来する

動きや関係性の裏側にある、システムの根っこの構造を見るのがクラス図です。システムを構成する概念や物事（事象）と、それらの関係を記述します。抽象的な構造を関係とともに表すときにも使います。

初心者向けのテキストでは、「たい焼きの型と、焼き上がったたい焼き」の例えがよく使われます。動画はそれでは物流システムのような現場には軽すぎるとして、生き物のDNAと、実際の生き物で説明しました。配送トラックというクラスは、種のDNAのようなものです。ナンバープレートや現在の燃料といった属性と、エンジンをかける、荷物を積むといった機能が書かれていますが、目の前に存在するトラックそのものではありません。DNAだけでは荷物を運べないからです。

そこで、システムが実際に動いているある瞬間の実体を捉えるのがオブジェクト図です。システムのある時点のオブジェクト間の関係を表し、クラス図で表したクラスの構成や相互関係を、より具体的なレベルで示します。動画の言い方では「火曜日の午後3時、大雪が降っているある時点で、ナンバー402のトラックの燃料は残り10%」という具体的な1コマです。

この具体的な1コマ同士が、その瞬間にどんな関係を結んでいるかを確かめると、抽象的な設計に矛盾がなかったかを検証できます。クラス図で完璧な設計をして、オブジェクト図で実際の動作環境をシミュレーションする。この抽象と具体の往復が、堅牢なシステムの土台になると動画は話していました。

（補足：UML の仕様書では、オブジェクト図に使うインスタンスの表記は、「ある時点の姿（スナップショット）」を表せるとされています。クラス図は静的な構造を示す図、つまり構造図に分類されます。）

コンポーネント図とステートマシン図：全体と一点

最後の2つは、ソフトウェアの設計を現実の物理的な世界と、オブジェクトの内側にあてはめるレンズです。

コンポーネント図は、動画では、物理的な構成要素からシステムの構造を記述する図で、システムの大まかな構造を視覚化するときに役立つとされました。東京のデータセンターのデータベース群と、大阪のWebサーバー群をどう配置し、どのネットワークでつなぐのか。その配置が、そのままインフラ投資のコストや、セキュリティの物理的なリスクに直結するので、経営層とインフラの議論をするときに欠かせない、という説明です。

そして、巨大な物理構造を見た直後に、たった1つの要素まで限界までズームインするのがステートマシン図です。1つのオブジェクトに注目して、そのオブジェクトの状態が、相互作用の中でどう変わっていくのかを表します。

（補足：仕様書では、ステートマシンは離散的なイベントで動く振る舞いを有限の状態で表す仕組みで、クラスのインスタンスの振る舞いを表すのに使うと説明されています。図のカートの遷移は、動画の例にそって作った設計例です。）

まとめ：8つの図を「見たいもの」で使い分ける

動画の締めくくりは、「いろいろな図があるので、名前と用途をしっかり把握しておくとよい」でした。どれか1つの視点が欠けても、複雑なシステムを安全に作って運用することはできない、という趣旨です。動画で出てきた8つを、見たいものごとに整理します。

図	動画の説明	分類
ユースケース図	誰が何をするか	振る舞い図
アクティビティ図	活動の流れと条件分岐	振る舞い図
シーケンス図	やり取りを時系列で	振る舞い図 （相互作用図）
コミュニケーション図	オブジェクト間の相互作用と関連	振る舞い図 （相互作用図）
クラス図	概念や物事とその関係	構造図
オブジェクト図	ある時点の関係	構造図
コンポーネント図	物理的な構成要素から見た構造	構造図
ステートマシン図	1つのオブジェクトの状態変化	振る舞い図

（補足：UML 2.5.1 では図の種類は全部で14あり、時間と無関係な静的な構造を示す構造図と、動的な振る舞いを示す振る舞い図の2つに大きく分かれます。動画に出てこなかった図には、配置図、パッケージ図、複合構造図、プロファイル図、相互作用概要図、タイミング図があります。仕様書は、この分類は論理的な整理で、境界は厳密には区別されないとも注記しています。）

最後に動画は、UML を自分の悩みにも当てはめてみようと呼びかけます。いまの自分は、アクティビティ図の中で「このままキャリアを進めるか、新しく挑戦するか」という条件分岐に立っているのか。それともステートマシン図の中で、自分の状態が大きく変わる引き金を引こうとしているのか。システムも人も、状態は変わり続ける。図に当てはめて俯瞰すると、解決の糸口が見えるかもしれません。