UMLダイアグラムチュートリアル

「百聞は一見に如かず」と言うように、複雑なソフトウェア開発の世界において、ビジネスユーザーやシステムを理解したいすべての人が理解できる共通の視覚言語を提供するために、統一モデリング言語（UML）が作成されました。このガイドでは、UMLについて知っておくべきことすべてを網羅しています。正式なトレーニングで初めてUMLに触れて以来、あまり使用していない場合でも、一回限りの成果物としてではなく、生きたドキュメントとして使用することで、複雑なシステムを理解しやすい状態に保つ実用的な方法であり続けます。

UMLとは？

統一モデリング言語（UML）は、複雑なソフトウェアシステムのアーキテクチャ、設計、実装において、構造的および振る舞いの両面で、意味論的および構文的に豊かな共通の視覚的モデリング言語を構築するために作成されました。

これは他の分野で使用される設計図に似ており、さまざまな種類のダイアグラムで構成されています。総合すると、UMLダイアグラムは、システムの境界、構造、振る舞い、およびシステム内のオブジェクトを記述します。コードを記述する際、アプリケーションには数千行ものコードが存在するため、ソフトウェアシステム内の関係や階層を追跡するのは困難です。UMLダイアグラムは、そのソフトウェアシステムをコンポーネントとサブコンポーネントに分割します。

問題解決モデルのカテゴリーには、命令型、関数型、宣言型、オブジェクト指向言語の4つがあります。オブジェクト指向言語では、アルゴリズムは「オブジェクト」を定義し、オブジェクト同士を相互作用させることによって表現されます。それらのオブジェクトは操作される対象であり、現実世界に存在します。それらは建物、デスクトップ上のウィジェット、あるいは人間である可能性があります。

オブジェクト指向言語は、現実世界のオブジェクトをモデル化するため、プログラミングの世界を支配しています。UMLは、オブジェクト指向設計、オブジェクトモデリング技術、オブジェクト指向ソフトウェアエンジニアリングといういくつかのオブジェクト指向表記法を組み合わせたものです。

UMLはこれら3つのアプローチの強みを活かし、より一貫性があり使いやすい手法を提示します。UMLは、ソフトウェアおよびビジネスシステムのモデリングのさまざまな側面を構築および文書化するためのベストプラクティスを表しています。UMLは標準化されているため、プログラミング言語や開発プロセスを問わず適用でき、ほとんどのソフトウェア開発者が広く読むことができます。

実際には、UMLは視覚的なドキュメントの一種でもあり、システムを再説明する時間を短縮できます。このドキュメントは、新入社員のオンボーディングから、ステークホルダーへのシステムの迅速な概要説明まで、開発者が会議で時間を無駄にしないよう、さまざまな方法でエンジニアを支援します。

UMLの歴史と起源

ソフトウェアエンジニアリングの「スリーアミーゴス」としても知られるグラディ・ブーチ、ジェームズ・ランボー、イヴァー・ヤコブソンは、新しい標準を作成してプログラマーに明確さを提供するために協力しました。

このグループの取り組みにより、1996年にUML 0.9および0.91のドキュメントがリリースされました。Microsoft、Oracle、IBMを含む複数の組織が、UMLを自社のビジネス開発に不可欠であると見なしていることがすぐに明らかになりました。彼らは他の多くの個人や企業とともに、本格的なモデリング言語を開発できるリソースを確立しました。スリーアミーゴスは1999年に『The Unified Modeling Language User Guide』を出版し、2005年にはUML 2.0を含むアップデートを出版しました。

UMLにおけるObject Management Group（OMG）の役割

Webサイトによると、Object Management Group®（OMG®）は、1989年に設立された、国際的でオープンな会員制の非営利技術標準コンソーシアムです。OMG標準は、ベンダー、エンドユーザー、学術機関、政府機関によって推進されています。OMGのタスクフォースは、幅広い技術とさらに幅広い業界向けの企業統合標準を開発しています。UMLやModel Driven Architecture®（MDA®）を含むOMGのモデリング標準により、ソフトウェアやその他のプロセスの強力な視覚的設計、実行、保守が可能になります。

OMGは、UML仕様の定義と保守を監督しています。この監督により、エンジニアやプログラマーは、あらゆるシステム規模のソフトウェアライフサイクルのすべてのフェーズにおいて、多くの目的で1つの言語を使用できるようになります。

OMGはUMLの目的を次のように定義しています：

• システムアーキテクト、ソフトウェアエンジニア、ソフトウェア開発者に、ソフトウェアベースのシステムの分析、設計、実装のためのツールを提供するとともに、ビジネスや同様のプロセスをモデリングするためのツールを提供すること。

• オブジェクト視覚的モデリングツールの相互運用性を可能にすることで、業界の状態を前進させること。ただし、ツール間でモデル情報の意味のある交換を可能にするには、セマンティクスと表記法に関する合意が必要です。

UMLは以下の要件を満たしています：

• UMLの抽象構文を指定する、共通のMeta-Object Facility（MOF）ベースのメタモデルの正式な定義を設定すること。抽象構文は、UMLモデリング概念のセット、その属性、関係、および部分的または完全なUMLモデルを構築するためにthese概念を組み合わせるルールを定義します。

• 各UMLモデリング概念のセマンティクスの詳細な説明を提供すること。セマンティクスは、UML概念がコンピューターによってどのように実現されるかを、技術に依存しない方法で定義します。

• 個々のUMLモデリング概念を表すための人間が読める表記要素と、モデル化されたシステムのさまざまな側面に対応するさまざまなダイアグラムタイプにそれらを組み合わせるためのルールを指定すること。

• UMLツールをこの仕様に準拠させる方法を定義すること。これは、準拠ツールによって実現されなければならない、対応するモデル交換フォーマット（XMI）のXMLベースの仕様（別の仕様）でサポートされています。

UMLダイアグラムの種類

UMLは要素を使用し、それらをさまざまな方法で関連付けて、静的ダイアグラム（システムの構造的側面を表す）と振る舞いダイアグラム（システムの動的側面を表す）を形成します。未経験者にはUMLダイアグラムが無数にあるように見えるかもしれませんが、実際には、UML標準では14種類のダイアグラムが識別され、以下に定義する2つのグループに分けられています。

構造UMLダイアグラム

• クラス図：これは最も一般的に使用されるUMLダイアグラムであり、オブジェクト指向ソリューションの主要な基盤です。システム内のクラス、属性と操作、および各クラス間の関係を示します。大規模なシステムを図式化する場合、クラスをグループ化してクラス図を作成します。クラスは、垂直に積み重ねられた3つのコンパートメントを含む長方形で表されます。一番上のコンパートメントにはクラス名が含まれており、これは必須ですが、下の2つのコンパートメントにはクラスの属性やクラスの操作または振る舞いに関する詳細が示されます。

• コンポーネント図：コンポーネント図は、本質的にクラス図のより専門的なバージョンであり、両方に同じ表記規則が適用されます。コンポーネント図は、複雑なシステムをより小さなコンポーネントに分解し、それらのコンポーネント間の関係を視覚化します。

• 複合構造図：これらのタイプのダイアグラムは、本質的に分類子の内部構造の設計図です。また、コラボレーションの振る舞いや、ポートを介した環境との分類子の相互作用を示すためにも使用できます。ハードウェアの内部コンポーネントを簡単に描写して、内部の仕組みをより完全に理解できます。

• 配置図：これらのダイアグラムはシステムエンジニアにとって最も有用であり、通常、パフォーマンス、拡張性、保守性、および移植性を示します。ハードウェアコンポーネントが相互に関連して表示されると、ハードウェアメッシュ全体を追跡し、配置時にすべての要素が考慮されていることを確認しやすくなります。

• オブジェクト図：オブジェクト図は、特定の時点におけるデータ構造の例を示します。クラス図を使用して構造を示し、オブジェクト図をテストケースとして使用してクラス図の完全性を検証できます。または、オブジェクト図を作成して、モデル要素とそのリンクに関する情報を検出することもできます。

• パッケージ図：パッケージ図は、システム内の異なるパッケージ間の依存関係を示すために使用されます。フォルダーとして描写されるパッケージは、ユースケースやクラスなどのモデル要素をグループに編成します。パッケージ間で定義される2つの特別な依存関係タイプとして、パッケージのインポートとパッケージのマージがあります。

• プロファイル図：プロファイル図もUML標準の一部であり、主に特定のドメイン向けにUMLを調整する必要がある場合に使用されます。最近UML 2.0に追加されたプロファイル図はユニークであり、仕様で使用されることはほとんどありません。プロファイル図は、特定のドメインやプラットフォーム向けにUMLモデルをカスタマイズするための拡張メカニズムとして理解するのが最善です。

振る舞いUMLダイアグラム

• アクティビティ図：アクティビティ図は、状態マシン図の代替として使用されます。アクティビティ図は、ユースケースで実行されるステップを視覚化します。アクティビティは、連続、分岐、または並行して実行できます。このタイプのUMLダイアグラムは、システムの動的な振る舞いを示すために使用されますが、ビジネスプロセスモデリングでも役立ちます。

• コミュニケーション図：以前はコラボレーション図と呼ばれていたコミュニケーション図は、オブジェクトがどのように相互に関連しているかを示します。システムのアーキテクチャ設計内で、メッセージを介してオブジェクトがどのように関連付けられ、接続されるかをモデル化します。また、ユースケース内の代替シナリオや、さまざまなオブジェクトの連携や相互作用を必要とする操作を示すこともできます。

• インタラクション概要図：このダイアグラムは、相互作用するノード間の制御フローを概観します。これには、初期ノード、フロー最終ノード、アクティビティ最終ノード、決定ノード、マージノード、フォークノード、およびジョインノードが含まれます。

• シーケンス図：イベント図またはイベントシナリオとも呼ばれるシーケンス図は、オブジェクトが相互作用する順序を示します。これにより、単純なランタイムシナリオを視覚的に表現できます。

• 状態図：簡単に言うと、状態図は状態と遷移を描写します。状態とは、オブジェクトが保持できる情報のさまざまな組み合わせを指し、このUMLダイアグラムは、考えられるすべての状態と、オブジェクトが次の状態に遷移する方法を視覚化できます。

• タイミング図：逆シーケンス図と呼ばれることが多いタイミング図は、特定の時間枠内でオブジェクトがどのように相互作用するかを示します。これらのダイアグラムを使用して、プロセスの各ステップにかかる時間を確認し、改善の余地がある領域を見つけます。

• ユースケース図：「アクター」と呼ばれる棒人形で表示されるユーザーが、システムとどのように相互作用するかをモデル化します。このタイプのUMLダイアグラムは、アクターとシステム間の関係のハイレベルな概要である必要があるため、非技術的なオーディエンスにシステムを説明するための優れたツールとなります。

UML用語集

OMG非会員がよく使用される用語を理解できるように、UML 2.4.1ドキュメントから抜粋したこのリストで、UMLの語彙に慣れ親しんでください。

• 抽象構文への準拠：ユーザーは、異なる表記法を使用している場合でも、異なるツール間でモデルを移動できます。

• 共通倉庫メタモデル（CWM）：分散型異種環境において、倉庫ツール、倉庫プラットフォーム、および倉庫メタデータリポジトリ間で、倉庫およびビジネスインテリジェンスのメタデータの交換を可能にするために使用される標準インターフェース

• 具体構文への準拠：ユーザーは、異なるツール間で使い慣れた表記法を引き続き使用できます。

• コア：UMLの文脈において、コアは通常、特にかん高い再利用性のために設計された完全なメタモデルである「コアパッケージ」を指します。

• 言語単位：特定のパラダイムや形式主義に従って研究対象のシステムの側面を表現する能力をユーザーに提供する、密接に結合されたモデリング概念のコレクションで構成されます。

• レベル0（L0）：UMLインフラストラクチャの最下位の準拠レベルであり、最も一般的なオブジェクト指向プログラミング言語で見られる種類のクラスベースの構造をモデリングするための単一の言語単位です。

• Meta Object Facility（MOF）：OMGのMDA言語ファミリーにおけるメタモデル定義の基礎を提供するOMGモデリング仕様

• メタモデル：モデルを形成するための言語とプロセスを定義します。

• メタモデル構造（LM）：UMLインフラストラクチャにおける第2の準拠レベルであり、UML自体などのメタモデルを構築するため（CMOFを使用）に使用される、より高度なクラスベースの構造のための追加の言語単位です。UMLには2つの準拠レベルしかありません。

• モデル駆動型アーキテクチャ（MDA）：モデル駆動型の技術仕様の一貫したセットを達成するためのアプローチと計画

• Object Constraint Language（OCL）：統一モデリング言語に適用されるルールを記述するための宣言型言語です。OCLは、自然言語よりも正確でありながら、数学よりも習得が難しくない用語やフローチャート記号を提供することで、UMLを補完します。

• Object Management Group（OMG）：メンバーがUML仕様を定義および保守する、非営利のコンピューター業界仕様コンソーシアム

• UML 1：統一モデリング言語の最初のバージョン

• 統一モデリング言語（UML）：システムの成果物を指定、構築、文書化するための視覚言語

• XMI：対応するモデル交換フォーマットのXMLベースの仕様

UMLによって指定されるモデリング概念

システム開発では、主に3つの異なるシステムモデルに焦点を当てています：

• 機能面：これらはユースケース図であり、ユーザーの視点からシステムの機能を記述します。
• オブジェクト面：これらはクラス図であり、オブジェクト、属性、関連、および操作の観点からシステムの構造を記述します。
• 動的面：システムの内部的な振る舞いを記述するために、インタラクション図、状態マシン図、およびアクティビティ図が使用されます。

これらのシステムモデルは、構造図と振る舞い図という2つの異なるタイプのダイアグラムを通じて視覚化されます。

UMLにおけるオブジェクト指向の概念

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

オブジェクト指向の世界におけるいくつかの基本的な概念は以下のとおりです：

• オブジェクト：エンティティを表し、基本的な構成要素となります
• クラス：オブジェクトの設計図。
• 抽象化：現実世界のエンティティの振る舞い
• カプセル化：データを結合し、外部の世界から隠蔽するメカニズム
• 継承：既存のクラスから新しいクラスを作成するメカニズム
• 多態性（ポリモーフィズム）：異なる形式で存在するメカニズムを定義します

現代のチーム（特にアジャイルを実践しているチーム）では、これらのオブジェクト指向の概念は、ダイアグラムを「主要なドキュメント」として扱い、一度作成して古くなったままにするのではなく、コードとともに更新する場合に最も簡単に伝達できます。

チームが現在もUMLダイアグラムを使用する理由（特にアジャイルにおいて）

何らかの正式なコードトレーニングを受けたことがあるなら、学校でUMLダイアグラムを紹介されたことでしょう。しかし、その後どれくらい使用しましたか？UMLダイアグラムの作成にはある程度の時間がかかり、アジャイル環境ではすぐに古くなってしまうため、多くのソフトウェア開発者はその存在を忘れてしまっています。

その懸念はもっともです。プロジェクトとともに進化しないダイアグラムは、すぐに価値を失います。しかし、最新の状態に保たれている場合、UMLは開発を迅速化し、コミュニケーションを明確にすることができます。多くのエンジニアはダイアグラムを敬遠しがちですが、アジャイル開発環境においてこれらは有用です。開発の生産性を維持し、焦点を絞るのに役立ちます。単なる「あれば便利」なものと考えるのではなく、UMLダイアグラムをドキュメントの主要な要素として扱いましょう。

UMLダイアグラムは、エンジニアリングチームが以下のことを行うのに役立ちます：

• 新しいチームメンバーやチームを切り替える開発者を迅速に軌道に乗せる。

• ソースコードをナビゲートする。

• プログラミングを行う前に、新しい機能を計画する。

• 技術的なオーディエンスと非技術的なオーディエンスの両方とより簡単にコミュニケーションをとる。

ただし、プロジェクトとともに進化しないダイアグラムは役に立たないため、常に進化し続けるダイアグラムが必要です。チームが保守の負担を軽減する1つの方法は、より軽量なインプット（テキストベースの定義など）からダイアグラムを生成することです。これにより、システムの変化に合わせてドキュメントの柔軟性を維持できます。Lucidchartは、テキストマークアップからUMLシーケンス図を生成できるため、ダイアグラム作成を自動化し、柔軟に行うことができます。

UMLダイアグラムの作成方法

UMLダイアグラムは特定のルールと形状に従っており、各タイプを正しく構築する方法を学ぶにはかなりの時間がかかる場合があります。幸いなことに、クラス図から始まる簡単なチュートリアルを用意しており、プロセスをステップバイステップで説明しています。

ツールに関係なく、実際的なワークフローは一貫しています。質問に一致するダイアグラムタイプ（構造 vs. 振る舞い）を選択し、現在のオーディエンスに必要なものだけをモデル化し、コードや要件の変更に応じてダイアグラムを再確認します。新しいソフトウェアシステムの静的アーキテクチャをマッピングする場合でも、動的なユーザー相互作用を視覚化する場合でも、次のステップに従って効果的なモデルを構築してください：

1. 目的を定義する

視覚化する必要があるものを正確に決定します。システムの静的な構造をマッピングする必要があるのか（構造図）、あるいはコンポーネントが時間の経過とともにどのように相互作用し変化するかを示す必要があるのか（振る舞い図）を検討します。

2. 適切なダイアグラムタイプを選択する

システム要件に基づいて、適切なUMLダイアグラムを選択します。たとえば、オブジェクト指向のシステム構造にはクラス図、時系列の相互作用にはシーケンス図、ユーザーの機能を説明するにはユースケース図を使用します。（ヒント：Lucidchartの作成済みUMLテンプレートのいずれかから始めるのが、最も簡単な開始方法です。）

3. UML図形ライブラリを有効にする

UMLは厳格な視覚的語彙を使用するため、正しい記号が必要です。Lucidchartでは、左側メニューの下部にある［図形を追加］をクリックし、「UML」を検索して、必要な特定の図形ライブラリ（UMLクラス、UML状態、UMLシーケンスなど）のチェックボックスをオンにします。

4. 図形を追加して定義する

キャンバスにエンティティ、オブジェクト、ノード、またはアクターをドラッグ＆ドロップします。これらを論理的に配置し、図形内をダブルクリックして、カスタムテキスト、特定の属性、および操作をオブジェクトに追加します。

5. コンポーネントを接続する

エンティティ間に線を引いて、それらの間の関係を確立します。線の端点（矢印、ひし形など）をカスタマイズして、継承、複合（コンポジション）、依存関係、基本的な関連などの特定のUML関係を正確に反映させます。

6. レビューと共同作業

UMLは、開発者、エンジニア、およびビジネスステークホルダー間の共通言語として機能するように設計されています。ダイアグラムのドラフトが完成したら、Lucidchartのリアルタイム共同作業機能を使用して、チームを招待してアーキテクチャをレビューし、コメントを残して設計図を仕上げます。

UMLのエバンジェリストになる

UMLダイアグラム作成に前向きなのが自分だけでは不十分な場合もあります。結局のところ、ソフトウェア開発者として通常はチームで作業するため、他の全員を巻き込むことが重要です。

チームが開発プロセスへのUMLダイアグラムの統合をためらっている場合は、まず1つのプロジェクトだけで使用することを提案してみてください。UMLダイアグラムがドキュメント化にどれほど有益であるかをチームが実感すれば、それを必要なステップとして捉えるようになるでしょう。

さらに、Lucidchartを使用すれば、UMLダイアグラムの作成は面倒な作業ではなく、資産になります。