UML (統一モデリング言語) とは? 入門最適ガイド

統一モデリング言語 (UML: Unified Modeling Lnaguage) は、構造的にも動作面でも複雑なソフトウェアシステムのアーキテクチャ、設計と実装のための意味論的かつ構文的に豊かな共通の視覚的モデリング言語を打ち立てることを目指して作られました。UML は、ソフトウェアの可視化、統一を実現させ、説明書に対する理解力を向上させる効果があり、システム分析の可視化によりコミュニケーションが効率化できる効果があります。

また、UMLは他の分野で用いられる設計図に類似しており、さまざまな種類の手方で構成されます。UML図は、システムとそのシステム内のオブジェクトの境界、構造や振る舞いを表します。

UMLを使用すれば、複雑なシステムの設計書を簡単に見える化させることができます。

UML図の活用目的と使用メリットは主に以下を参考にして下さい。

• ごちゃごちゃな文字ベースのシステム全体像を可視化
• システムに対する理解力の向上
• 新しいシステムの設計図を作成する際
• システム開発プロジェクトのコミュニケーションの統一

ソフトウェアエンジニアリング界の通称「スリーアミーゴス」は、他の方法論を進化させました。新しい基準を作ることにより、プログラマーによりわかりやすい方法論を打ち立てることを目指したグラディ・ブーチとランボーの間の共同作業により、これら3つの方法論が拡充され、最終成果物として改善されました。

こうした考案者らの取り組みが結実し、1996年に UML 0.9/0.91 が公開されました。その後、Microsoft や Oracle、IBM を始めとする企業が、自社の事業開発に欠かせない要素として UML を捉えていることが明らかとなりました。考案者の3人は、他の個人や企業と共に、本格的なモデリング言語開発のためのリソースを確立し、1999年に「UMLユーザーガイド」を出版しました。さらに2005年の第2版では、UML 2.0 に関する情報を含む最新情報を公開しています。

Object Management Group® (OMG®) は、テクノロジーに関する標準を推進する1989年創設の会員制国際非営利コンソーシアムです (出所: OMG ウェブサイト)。ベンダー、エンドユーザー、学術機関や政府機関が共に OMG の標準を推進しています。OMG タスクフォースでは、多彩なテクノロジーや広範な業界を対象としたエンタープライズ統合型の標準の開発を行っています。UML やモデル駆動型アーキテクチャ® (MDA®) を始めとする OMG のモデリング標準は、ソフトウェアやその他のプロセスの強力な視覚的設計、実行とメンテナンスの実現に寄与しています。

OMG は、UML の仕様の定義とメンテナンスを監督しています。あらゆるシステム規模のソフトウェアライフサイクルの全段階にわたり、エンジニアやプログラマーが1つの言語を多彩な用途に利用できるようにすることがその目標です。

OMG では、UML の目的を以下のように定義しています。

• システムアーキテクト、ソフトウェアエンジニア、ソフトウェア開発者に対し、ソフトウェアベースのシステムの分析、設計や実装、加えてビジネスや同様のプロセスのモデル化のためのツールを提供するもの。
• オブジェクト視覚モデリングツールの相互運用性を実現することで、業界のあり方を進歩させるもの。ただし、ツール間における有意味なモデル情報の交換を実現するためには、意味論と表記法に関する合意が必要となる。

UML は以下の要件を満たします。

• UML の抽象構文を指定する共通の Meta-Object Facility (MOF) ベースのメタモデル公式定義を設定すること。この抽象構文は、UML モデリングの概念の集合、その属例と関係、さらにこれらの概念を組み合わせて部分的または完全な UML モデルを構築するためのルールを定義します。
• UML モデリング概念それぞれの意味論の詳細な説明を提供すること。この意味論は、UML の概念がコンピューターにより実現される方法を技術に依存しない方法で定義します。
• 個別の UML モデリング概念の表現のための対人可読な表記要素、さらにこれらを組み合わせてモデリング対象のシステムのさまざまな側面に対応する多様な種類の図を作成するためのルールを指定すること。
• UML ツールをこの仕様に準拠させる方法を定義すること。この内容は、準拠したツールで実行すべき、対応するモデル交換形式 (XMI) の XML ベースの仕様により (別の仕様において) サポートされています。

UML はプログラマーに人気ですが、データベース開発者の間では通常使われません。理由のひとつとしては、UML の成り立ちがデータベースを主眼としたものでないことが挙げられます。しかしながら、UML は高次の概念データのモデリングに有用であり、さまざまな種類の UML 図で活用することができます。オブジェクト志向のクラスモデルの関係データベースへのレイヤー化については、Database Modeling in UML (UML におけるデータベースモデリング)が参考になります。

UML は継続的に改良されています。アジャイルを含め、開発のより多くの側面に対応するよう、UML の仕様を拡張したものが UML 2.0 で、使いやすさや実装、導入を簡素化するため、UML を再構築し、改良することを目的として作られました。UML 図については、以下のような点が変更されています。

• 構造モデルと行動モデルの間の統合強化
• 階層の定義とソフトウェアシステムのコンポーネントとサブコンポーネントへの分類が可能に
• UML 2.0 では図の数が9から13に拡大

UML で使われる用語に慣れておきましょう。以下のリストでは、OMG に属さないメンバーが一般に使われる用語を理解できるよう、UML 2.4.1ドキュメントから抜粋した内容を紹介しています。

• 抽象構文準拠 ユーザーは、ツールの表記法が異なる場合であっても、さまざまなツールを通じてモデルを移動させることが可能
• 共通ウェアハウスメタモデル (CWM) 分散型異機種環境において、ウェアハウスツール、ウェアハウスプラットフォーム、ウェアハウスメタデータリポジトリ間のウェアハウスとビジネスインテリジェンスメタデータの交換を可能にする標準インターフェイス
• 具象構文準拠 さまざまなツールでユーザーが使い慣れた表記法の使用が可能
• コア UML のコンテキストにおいて、コアは通常、高い再利用性を主目的に設計された完全なメタモデルである「コアパッケージ」を指す
• 言語単位 特定のパラダイムや形式主義に従った検討対象のシステムの側面の表現を可能にする密接に結合したモデリング概念の集合体から構成される
• レベル0 (L0) UML インフラストラクチャの最下位準拠レベル - クラスベースの構造などのモデリングのための単一の言語単位で、最も人気の高いオブジェクト指向プログラミング言語で見られるもの
• Meta Object Facility (MOF) OMG によるモデリング仕様で、OMG の MDA 言語ファミリにおけるメタモデル定義の基礎となるもの
• メタモデル モデル形成の基盤となる言語とプロセスを定義
• メタモデル構造 (LM) UML インフラストラクチャにおける第2の準拠レベル - UML そのものなど、(CMOF を使った) メタモデルの作成に使われるより高度なクラスベースの構造のための追加の言語単位で、UML の準拠レベルは2種類のみ
• モデル駆動型アーキテクチャ (MDA) 一体性のあるモデル駆動型技術仕様の策定のためのアプローチと計画
• オブジェクト制約言語 (OCL) 統一モデリング言語に適用される規則を記述するための宣言型言語。OCL は、自然言語よりも正確で、数学よりも習得しやすい用語やフローチャート記号の提供により UML を補完
• オブジェクトマネジメントグループ (OMG) UML 仕様の定義と維持を行う非営利のコンピューター業界仕様コンソーシアム
• UML 1 統一モデリング言語の最初のバージョン
• 統一モデリング言語 (UML) システムの成果物を指定、構築および記録するための視覚的言語
• XMI 対応するモデル交換形式の XML ベースの仕様
• MDA（Model Driven Architecture) 

MOF ドキュメントの全文を表示。

システムの開発においては、以下の3つの全体的なシステムモデルに重点が置かれます。

• 機能: ユーザーの視点からシステムの機能性を記述するユースケース図が該当します。
• オブジェクト: オブジェクト、属性、関連と操作の観点からシステムの構造を記述するクラス図が該当します。
• 動的: 相互作用図、ステートマシン図やアクティビティ図は、システムの内部動作を記述するために用いられます。

これらのシステムモデルは、構造図と行動図の2種類の図で視覚的に表現されます。

UML におけるオブジェクトとは、身の回りに存在する実世界の実体を指します。ソフトウェア開発において、オブジェクトは、作成対象のシステムをドメインに関連して記述し、モデル化するために用いられます。また、複雑なシステムを1度に1つずつ構築できる理解しやすいコンポーネントに分解する上でも有用です。

以下では、オブジェクト指向の世界における基本的な概念を説明しています。

• オブジェクト 実体を表し、基本的な構成要素となる。
• クラス オブジェクトの設計図。
• 抽象化 実世界に存在する実体の行動。
• カプセル化 データを結合し、外界から隠すメカニズム。
• 継承 既存のクラスから新しいクラスを作成するメカニズム。
• ポリモーフィズム さまざまな型に存在するメカニズムを定義する。

UML図では、要素を用い、それをさまざまな形で関連付けることにより、システムの静的または構造的な側面を表す図や、システムの動的側面を捉えた行動図を作成します。

構造 UML 図

• クラス図 最も広く用いられる UMLの一種で、あらゆるオブジェクト指向ソリューションの基盤となるものです。システム、属性やオペレーション内のクラスに加え、クラス間の関係を階層化するのがクラス図です。大規模なシステムを図式化する場合には、クラスがグループ化されてクラス図となります。

• コンポーネント図 ソフトウェアシステムの構成要素の構造的関係を示すもので、複数の構成要素を含む複雑なシステムに用いられるのが一般的です。構成要素はインターフェイスを通じて交信します。

• 複合構造図 複合構造図は、クラスの内部構造を示すために用いられます。

• 配置図 システムのハードウェアとソフトウェアを示すもので、複数のマシンにわたり、独自の設定でソフトウェアソリューションを使用する際に有用です。

• オブジェクト図 実世界の例を用いてオブジェクト間の関連を示し、一定の時点におけるシステムの状態を図式化するものです。オブジェクト内でデータを利用できるため、オブジェクト間の関連を明確化するために用いることもできます。

• パッケージ間の依存関係は、パッケージのインポートとパッケージの統合という2種類の定義で表します。パッケージによりシステムのさまざまなレベルを表し、そのアーキテクチャを表現することができます。パッケージの依存関係に印をつけ、レベル間の通信メカニズムを示すことができます。

行動 UML 図

• アクティビティ図 事業やオペレーションのワークフローを視覚的に図示し、システム内の一部または一構成要素のアクティビティを示すものです。アクティビティ図はステートマシン図の代替として使用されます。

• コミュニケーション図 シーケンス図に似ていますが、オブジェクト間でやり取りされるメッセージに主眼をおいた図です。1つのシーケンス図とさまざまなオブジェクトを使い、同じ情報を示すこともできます。

　

• 相互作用概要図 相互作用図には7種類あり、アクティビティの行われるシーケンスを示します。
• シーケンス図 オブジェクト間の相互作用と、その相互作用の発生順序を示すものです。特定のシナリオ下での相互作用を図示します。

• ステートマシン図 アクティビティ図と同様に、現在の状態でさまざまに異なるオブジェクトの振る舞いを示すものです。

• タイミング図 シーケンス図と同様に、所定の時間枠内でのオブジェクトの振る舞いを示すものです。含まれるオブジェクトが1つのみであれば、図はシンプルなものとなります。複数のオブジェクトが含まれる場合には、オブジェクト間の相互作用が所定の時間枠内で示されます。

• ユースケース図 システムの特定の機能を表すもので、機能間の関連と内部/外部のコントローラー (アクター) との関連を図示するために作成されます。

さまざまな種類の UML 図を作成する方法を学ぶため、構造図と行動図の作成プロセスを手順別に説明する以下のチュートリアルを試してみましょう。

構造図のチュートリアル

クラス図

クラス図は、クラス、属性、操作やオブジェクトを含むシステムの静的構造を表します。クラス図を使うことで、実装クラスや論理クラスの各形式で計算データや組織データを示すことができます。これらの2つのグループは、互いに重複する可能性もあります。

1. クラスは、3部に分かれた長方形で示されます。上段にはクラス名、中段にはクラスの属性、下段にはクラスの操作 (メソッド) が含まれます。
2. クラス図にクラス図形を追加し、これらのオブジェクト間の関連を図式化します。サブクラスの追加が必要となる場合もあります。
3. 線を使い、クラスとサブクラスの間に関連、継承、多重やその他の関係を表します。これらの線の表記法は、選択する表記スタイルにより異なります。

コンポーネント図

コンポーネント図は、コンポーネントが組み合わせられ、より大きなコンポーネントやソフトウェアシステムを形成する様子を示すもので、システム内の各コンポーネントの依存関係をモデル化する図です。コンポーネントとは、ステレオタイプの機能を実行するために必要な実体を指します。コンポーネントのステレオタイプは、実行可能ファイル、ドキュメント、データベース表、ファイルやライブラリファイルで構成されます。

1. 長方形の図形でコンポーネントを表します。この側面には小さな長方形を2つ追加します。また、この図形のアイコンを使うこともできます。
2. コンポーネント図形の間に、関連を表す線を追加します。

配置図

配置図は、ハードウェアのコンポーネントの物理的展開と構造をモデル化します。システムのコンポーネントが動作する場所と相互に関係して動作する方法を示す図です。

1. 配置図を作成する際には、コンポーネント図と同じ表記法を使用します。
2. 3次元のキューブを使い、物理マシンまたは仮想マシンを示すノードをモデル化します。
3. シーケンス図と同様のスタイルでノードにラベルを付します。必要に応じて他のノードを追加し、線で接続します。

行動図のチュートリアルの例

アクティビティ図

アクティビティ図は、クラスオブジェクト間の管理フローの手順を業務ワークフローなどの組織的プロセスと併せて示します。特別な図形を用いて図を構成し、矢印を使ってこれらを接続します。アクティビティ図の表記セットは、状態図のそれに類似したものです。

1. アクティビティ図の作図は塗りつぶしの丸の描画から開始します。
2. その丸を角丸の長方形で示される最初のアクティビティへ接続します。
3. 次に、プロセス全体の段階的なフローを示す線で各アクティビティを別のアクティビティに接続します。
4. スイムレーンを使用して、各アクティビティを実行するオブジェクトを表すこともできます。

ユースケース図

ユースケースとは、アクター (対象のシステムや外部システムとやり取りをする人間) とシステム自体との間の相互作用を定義する一連の手順を指します。ユースケース図は、ユースケースの仕様を表し、システムの機能単位をモデル化する図です。開発チームが、システム内の人間による相互作用の役割やさまざまなユースケース間の差異を含め、システムの要件を理解する上で有用な図です。ユースケース図では、対象のシステムのすべてのユースケースを示す場合も、類似した機能をもつユースケースのグループ1つのみを示す場合もあります。

1. ユースケース図の作成を開始するには、図の中心に楕円形を追加します。
2. 楕円形の内部にユースケース名を入力します。
3. 図のそばにアクターを表す棒人間を追加し、線を使ってアクターとユースケース間の関連をモデル化します。

シーケンス図

シーケンス図は、イベント図やイベントシナリオとも呼ばれ、シーケンス内のさまざまなオブジェクト間の呼び出しを示すことでプロセス間の相互作用を表す図です。シーケンス図には、垂直方向と水平方向の2つのディメンションがあります。垂直の線は、メッセージと呼び出しのシーケンスを時系列順に示し、水平の要素はメッセージが中継されるオブジェクトのインスタンスを示します。

1. シーケンス図を作成するには、長方形のボックス内にクラスインスタンス名とクラス名を記述します。
2. クラスインスタンス間にメッセージの送受信者を示す線を描画します。
3. 同期メッセージは黒塗りの矢印、非同期メッセージは開いた矢印、応答メッセージは破線でそれぞれ表します。

Lucidchart を使えば、誰でもUML 図の作成をすぐに開始できます。今すぐシンプルで効率的な作図体験を楽しみましょう。

• 使いやすさ UML 図の作成経験があれば、作成の手順はよくご存知でしょう。でも、Lucidchart があれば、完成までのプロセスを最大限に簡略化することができます。Lucidchart の洗練されたインターフェイスとスマートなドラッグ・アンド・ドロップエディターで、作図時間の短縮が実現します。
• 豊富な図形ライブラリ 状態図、アクティビティ図やユースケース図などを作成しましょう。豊富な図形やコネクタのライブラリで、必要なものがすべて見つかります。
• 多くのインテグレーション Lucidchart は、G Suite と完全に連携しています。Lucidchart の利用を開始すると、Gmail や Google Drive と同様、Google の生産性向上スイートの中から直接 Lucidchart の機能が使えるようになります。
• コラボレーションも実現 同僚、顧客や上司との UML ダイアグラムの共有も簡単です。ウェブページに図を埋め込んだり、PDF として公開することも可能です。また、Lucidchart のプレゼンテーションモードを使えば、作成した図を見栄えのする視覚的なプレゼン資料として披露することができます。
• Visio インポート＆エクスポート Lucidchart では Visio ファイルのインポートとエクスポートが簡単にできるため、過去に作成した内容を作り直す必要がありません。手早く、スムーズな移行が実現します。