導入

---

概要

UML 2.0は図を二つの主要なカテゴリ:

カテゴリ	目的
構造図	要素の物理的構成を捉える——オブジェクトどうしがどのように関係しているか
振る舞い図	要素がどのように相互作用し、状態を変化させ、時間とともに振る舞いを処理するかに注目する

💡 重要な原則：UMLモデルは、一つ以上の図から構成される。各図は、モデル化されているシステムに対する特定の視点または関心システムを表します。個々の要素は、複数の図にまたがって現れることが多いです。

---

🔷 構造図

構造図は、システムの静的アーキテクチャ——「どのように」ではなく「何であるか」をモデル化します。

1. クラス図

目的: モデルクラス、インターフェース、およびそれらの静的関係。

主要な要素:

• 属性と操作を持つクラス

• インターフェースと実装関係

• 関連、集約、合成、および一般化

• 可視性修飾子（+, -, #, ~)

• 多重度の指定（1, 0..*, 1..5)

使用例:使用するタイミング:

クラスのステレオタイプと種類

図はステレオタイプを使用しています（角括弧内にテキストで示され、例えば <<entity>>）を使用して、各クラスの役割を分類しています：

• 境界クラス（<<境界>>): これはシステムとそのエイクター（ユーザーまたは外部システム）の間のインタラクションを処理します。

• 例： コンソールウィンドウ および ダイアログボックス.

• 制御クラス（<<制御>>): これはアプリケーションの調整、トランザクション、およびビジネスロジックのフローを管理します。

• 例： 描画コンテキスト および データコントローラ.

• エンティティクラス（<<エンティティ>>): これはシステムが追跡するコアデータまたは永続的な情報を表します。

• 例： フレーム, ウィンドウ, イベント, 形状, 円, 長方形, 多角形、および点.

• 抽象クラス： この 形状 クラスは抽象的な概念を表しています。特定の形状の基本的な設計図として機能し、独自に直接インスタンス化することはできません。

---

クラスの構造

標準的なUMLクラスボックスはコンパートメントに分割されています。以下の 円 クラスを例に見てみましょう：

• クラス名： 上部のコンパートメントに配置されています（円).

• 属性： 中央のコンパートメントに配置されており、データフィールドを表しています。

• -半径 : float （マイナス記号は - プライベート属性を示しています）。

• -中心 : 符号なし整数

• 操作（メソッド）： 下部のコンパートメントに配置されており、振る舞いまたは関数を表しています。

• +area(半径 : float) : double (プラス記号は+ 公開メソッドを示す).

• +circum(), +setCenter()、および+setRadius().

---

関係とリンク

クラスを結ぶ線と矢印は、それらがどのように相互作用し、互いに依存しているかを定義する：

一般化（継承）

実線と 空洞の矢印先 親クラスを向いている。これは、子クラスが親クラスから属性と振る舞いを継承する「は-a」関係を示している。

• Window は Frame.

• ConsoleWindow および DialogBox は Window.

• Circle, Rectangle、およびポリゴン抽象クラスから継承する形状（例：円は形状）

集約

実線と、コンテナ側に空洞のダイヤモンドが描かれた線で表される。これは、子が親とは独立して存在できる、緩い「所有」関係や全体-部分関係を示している。

• ウィンドウは形状（多重度1から*）。ウィンドウは複数の（*）の形状を含むことができるが、ウィンドウが閉じられた場合でも、形状自体はメモリ上や別の文脈において概念的に存在し続けることができる。

合成

実線と、コンテナ側に黒色の塗りつぶされたダイヤモンドが描かれた線で表される。これは、コンテナと部品の寿命が一致する強い「所有」関係を示している。コンテナが破棄されると、部品も同時に破棄される。

• 円は点オブジェクトで構成される（多重度1 から *). 円は中心点または境界点がなければ存在できない。円を破壊すると、これらの特定の点への参照も破壊される。

依存関係

は によって表される破線の矢印。これは、あるクラスが別のクラスに依存していることを示しており、ターゲットクラスに変更を加えると、ソースクラスに影響を与える可能性があることを意味する。

• ウィンドウ は に依存しているイベント （破線の矢印が に向かって示す）イベント）。ウィンドウは、 のような操作を実行するためにイベントのトリガーに依存している。handleEvent().

関連

単純な実線で表される。これは、あるクラスのオブジェクトが別のクラスのオブジェクトと接続されている構造的関係を示している。

• ダイアログボックス は と関連しているDataController。これは、情報のやり取りや振る舞いの調整のために、互いに通信していることを意味する。

---

ドキュメント要素

• メモ： 図には、折り返された角を持つメモボックスがあり、破線で に接続されている。ウィンドウ クラスに接続されている。これは人間が読みやすい文脈を提供する：「アプリケーションのメインウィンドウ。」

• オブジェクト指向ソフトウェアアーキテクチャの設計

• ドメインモデルの文書化

• コードスケルトンの生成

---

2. コンポーネント図

目的: 実装単位の構成と依存関係を示す。

主な要素:

• コンポーネント（ステレオタイプとして «component»)

• 提供/要求されるインターフェース（ボールアンドソケット記法）

• アセンブリ接続子と依存関係

• アーティファクト（コンパイル出力：JAR、DLL、実行可能ファイル）

使用例:使用するタイミング:

コンポーネントとモジュール境界

図の中心にあるのは、コンポーネントという概念であり、システムの自律的かつモジュール的な単位で、内部内容をカプセル化し、明確なインターフェースを通じて振る舞いを示す。大きな外側の境界は、全体的な Terminal コンポーネントであり、サブシステムまたはコンテナとして機能する。このコンテナ内には、より小さい、専門的な内部コンポーネントが存在する——すなわち SafetyInspection, Staff, Defect、および Map。これらの内部ユニットのそれぞれは、Terminalの責任を果たすために協働するモジュール型のソフトウェアまたはデータ管理ロジックを表している。

インターフェースは契約として

コンポーネントは内部ロジックを直接公開しない。代わりに、アーキテクチャ上の契約として機能する明確に定義されたインターフェースを通じて相互作用する。

• 提供インターフェース： 「ラムネ」または円の記号で表され、コンポーネントが実装し、環境に提供するサービス、データ、または操作を示します。たとえば、外側のTerminalコンポーネントは、外部に公開される提供インターフェースとしてState, Details、およびInspection Itemを公開しており、外部クライアントがそのコンポーネントから要求できる内容を示しています。

• 要件インターフェース： 「ソケット」または半円の記号で表され、コンポーネントが正常に動作するために他のエンティティから必要とするサービスやデータを指定します。図の右側では、TerminalコンポーネントがAccountおよびInspection IDの要件インターフェースを明示的に公開しており、外部サブシステムへの依存関係を示しています。

ポートと内部配線

データおよび制御の流れを管理しつつカプセル化を保つために、システムはポートと委譲関係を使用します。

• ポート：コンポーネントの境界上に配置された小さな四角形がポートを表します。これらは、コンポーネントの内部構造が外部世界と接続するための明確な相互作用ポイントとして機能します。ポートにより、コンポーネントは内部配線を外部環境から分離でき、内部コンポーネントを置き換えたり変更したりしても、親コンポーネントが外部に見せる外観が変わらないことを意味します。

• 委譲と構成：Terminal内部では、線がこれらのインターフェースを接続して構造的アセンブリを形成します。外側のポートにある提供インターフェースは、受信したリクエストを内部コンポーネントの提供インターフェースに直接委譲します（StateおよびDetailsのパスがSafetyInspectionに接続されている様子から明らかです）。逆に、内部コンポーネントは、自身の要件インターフェース（ソケット）を隣接コンポーネントの提供インターフェース（ラムネ）に直接接続します。たとえば、SafetyInspectionコンポーネントはInspectorインターフェースに依存しています。スタッフ、その欠陥の詳細 によって提供されるインターフェース欠陥、および場所 によって提供されるインターフェース地図、緊密に連携したが緩く結合された内部エコシステムを構築する。

• モジュール型システムアーキテクチャの計画

• ビルド依存関係の管理

• 再利用可能なコンポーネントライブラリの文書化

---

3. コンポジット構造図（UML 2.0で追加）

主要な要素:

• 部品（全体と部分の関係を持つプロパティ）

• ポート（提供/要求されるインターフェースとのインタラクションポイント）

• 接続子（部品間のランタイムリンク）

• 協働の発生

使用例：モデル化する車:

カプセル化分類子（クラス）

外側の長方形は、この場合、車クラスである。コンポジット構造図では、この境界はシステムの内部ランタイム構成をカプセル化するコンテナとして機能する。個々のインスタンスが協働してより広範な動作目的を達成するための文脈を定義し、外部エントリティから「車」が内部でどのように動作しているかの複雑さを隠す。

部品（内部構造）

Carの境界内の内部長方形は、部品部品は、包含する分類子の実行中にインスタンスの集合が果たす役割を説明する。標準的なクラス図のように静的なコンパイル時関係を示すのではなく、これらの部品は特定のアーキテクチャ的スロットを埋める実行時インスタンスを示す。

• -t : トランスミッション：トランスミッションシステムの役割を果たすインスタンス。

• -e : エンジン：エンジンの駆動源の役割を果たすインスタンス。

• -s : ステアリングシステム：ステアリング機構の役割を果たすインスタンス。

コロン記法は、これらがそれぞれのクラスによって型付けられた構造的役割であることを示しており、運用中のCarに必ず存在しなければならないコンポーネントを正確に定義している。

ポートと境界

外側の分類子境界および内部部品境界に埋め込まれた小さな四角形は、ポートを表している。ポートは、分類子の内部構造と外部環境を分離するための明確な相互作用ポイントである。

• Carの境界にある外部ポート—たとえば：ホイール, ：ガスペダル、および：ステアリングホイール—は、Carが外部世界や物理環境とどのように相互作用するかを示すが、その相互作用を処理しているどの内部部品がその相互作用を処理しているかを明かさない。

• 内部部品（トランスミッションやエンジンブロックのポートなど）のポートは、これらのサブシステムが互いに通信する方法、または親境界と通信する方法を制御する。

接続子と内部配線

ポートを結ぶ太い線は、接続子を表している。接続子は、実行時に部品間、または部品と外部ポート間の通信経路を定義する。

• 委任接続子：コンテナの外部ポートを、部品の内部ポートに直接接続する。たとえば、外部の: ホイール ポートは直接 トランスミッション、そして外部の : ステアリングホイール は直接 ステアリングシステム。これにより、外部からの刺激が正しい内部アクターにスムーズに委譲されることを保証します。

• アセンブリコネクタ： 内部部品を結びつけて協働を可能にする。トランスミッション と エンジン は、これら2つの異なる実行時役割が信号、データ、または機械的力を直接交換することで、車両が統合された全体として機能することを示している。

使用するタイミング:

• デザインパターンの文書化

• 複雑な内部協働のモデル化

• クラス設計とコンポーネント実装の橋渡し

---

4. デプロイ図

目的: ソフトウェアアーティファクトをハードウェア実行環境にマッピングする。

主な要素:

• ノード（デバイス、実行環境）

• アーティファクト（デプロイ可能な単位）

• ノード間の通信経路

• デプロイ仕様（構成詳細）

使用例:使用するタイミング:

ノードと物理インフラ

コードの配置やクラス構造をモデル化する論理設計図とは異なり、デプロイメント図はハードウェアの構造に注目します。主な構成要素はノード、これらは視覚的に三次元の立方体として表現されます。ノードは、ソフトウェア要素が実際に実行される物理的な計算資源または実行環境を示します：

• <<processor>> ノード： ステレオタイプが付与された立方体として<<processor>>（例えばキャッシュサーバー, プライマリサーバー、および一般的なサーバーブロック）は、ソフトウェアバイナリを実行できる計算能力、メモリ、処理能力を持つノードを表します。

• <<network>> ノード： 長方形の立方体でラベル付けされたローカルネットワークは個別のコンピュータではなく、通信経路またはルーティングインフラを表します。接続されたプロセッサがデータパケットストリームを交換できる物理的な基盤を示しています。

• デバイスノード： ステレオタイプが付与されていないノードとしてインターネットおよびモデムバンクは、外部トラフィックをコアシステム環境にルーティングするために必要な境界ハードウェアコンポーネントまたは外部の物理インフラを表します。

関連付けと通信経路

三次元の立方体を結ぶ実線は関連デプロイメント図では、これらの関連がノード間の物理的な通信経路、ネットワークリンク、またはハードウェア接続を示している。

• の間の線はインターネットとモデムバンク外部の公開データがハードウェアスタックに入り込むエントリポイントを示している。

• から延びる関連はモデムバンクの下にあるキャッシュサーバー受信トラフィックの物理的なルーティングをエッジキャッシュ層まで示している。

• と結びついている関連はキャッシュサーバーとその下にあるプライマリサーバークラスタをローカルネットワーク内部コンポーネントが共有された高速なローカルバスまたはネットワークスイッチインフラストラクチャを介してどのように通信するかを確立している。

トポロジカルレイヤリングと冗長性

図中のノードの配置は、高可用性および負荷分散のためのデプロイメントトポロジとアーキテクチャ設計の選択を明示的に示している。

• エッジキャッシュレイヤー：エントリポイントのモデムハードウェアの直下には、2つの異なる並列なキャッシュサーバーノードがある。この構成は、リクエストが深層インフラストラクチャに到達する前に、受信トラフィックの負荷を分散し、アセットをキャッシュするように設計された冗長なエッジレイヤーを視覚的に示している。

• 内部サーバーファーム：スタックの最下部に配置され、ローカルネットワークを介して接続されているのは、コアサーバーのクラスタである。プライマリサーバー および隣接する汎用 サーバー ノードはマスターレプリカまたはプライマリセカンダリアーキテクチャのレイアウトを視覚的に示し、データの永続性と重い計算ワークロードが内部データセンター環境内で安全に調整されることを保証する。

目的: クラスファイアおよび複雑なパターンの内部構造をモデル化する。

• システムインフラの計画

• 分散アーキテクチャの文書化

• フェイルオーバーおよび冗長性戦略の指定

---

5. パッケージ図

目的: 論理的なグループ化を通じて名前空間を整理および管理する。

主な要素:

• パッケージ（タブ付きの長方形）

• インポート/アクセス関係（«インポート», «アクセス»)

• マージ関係（«マージ»)

• 可視性（+ パブリック、 - プライベート）

使用例:

サブシステムおよびパッケージの境界

図は、設計要素の論理的グループ化を表すために「フォルダ」表記に大きく依存している。

• サブシステム： 大きな外側のフォルダは、<<subsystem>> 注文管理 物理システムの主要な、封印された動作単位を表す。注文管理を実行するために必要な関連するコンポーネントやパッケージをグループ化する高レベルのコンテナとして機能する。

• パッケージ： サブシステム内および外の小さなフォルダ（例えばUI, 注文処理、およびGUIManager）は標準的なパッケージである。これらは要素を管理可能なグループに整理し、名前空間を確立し、アーキテクチャ内の可視性の境界を定義するために使用される。

依存関係とレイヤリング

ダッシュ線の矢印は依存関係を示しており、あるパッケージ（ターゲット）の変更が、元のパッケージ（ソース）の機能に影響を与える可能性があることを確立している。

• 内部依存関係： 注文管理サブシステム内では、明確なトップダウン型のアーキテクチャレイヤリングが見える。UIパッケージは注文処理に依存しており、さらにその価格計算および外部ストレージに依存している。これは、上位レベルのプレゼンテーション要素が、コアとなるビジネスロジックおよびデータアクセスレイヤーに依存するアーキテクチャフローを表している。

• 外部パッケージへの依存関係：パッケージは、自らの即時サブシステム境界の外にある要素に依存することもできる。例えば、UI パッケージは外部のものに依存していますGUIManager 同様に、Random Storage および Stream Storage パッケージは下部でサブシステムの境界を越えて外部のデータ構造に依存しており、サブシステムがより大きなソフトウェアエコシステムにどのように統合されているかを強調しています。

抽象化と継承（一般化）

図は特殊なスタイルと関係矢印を使用して、モジュールアーキテクチャに適用された抽象的な設計パターンを示しています。

• 抽象的パッケージと具象的パッケージ： 抽象的な要素を含む、またはインターフェースのような構造を定義するパッケージは斜体で表記されます（たとえば、External Storage および StorageManagement 一方、実行コードの実装を含むパッケージは、Repository および FileStorage といったものでは、標準的なテキストを使用して、具象パッケージであることを示しています。

• 一般化： 実線と、親パッケージを向いている開いた空洞の三角形で表されます。これは継承または実装関係を示しています。サブシステム内では、Random Storage および Stream Storage は抽象的な External Storage インターフェースを特殊化または実装しています。サブシステム外では、具象の Repository および FileStorage パッケージは抽象化へと一般化される ストレージ管理 パッケージは、多態性の振る舞いや構造的分類がパッケージレベルでどのようにモデル化できるかを示している。

  

• 使用するタイミング:

• 大規模なコードベースの管理

• モジュールの境界の定義

• コンパイル依存関係の制御

---

6. オブジェクト図

目的：特定の瞬間におけるインスタンスとそのリンクのスナップショットを表示する。

主な要素:

• オブジェクト（下線付きの名前：myCar:Car)

• オブジェクトインスタンス間のリンク

• 実行時における属性値

使用例:

オブジェクトと具体的なインスタンス

クラス図が抽象的で設計レベルの構成を示すのに対し、オブジェクト図はメモリ上に存在する実際のインスタンスを捉える。オブジェクトは長方形で表され、インスタンス化を示すために名前は常に下線を引かれる。

• 名前付きオブジェクト： 以下の構文に従うインスタンス名 : クラス名。たとえば、c : Company は名前が「c」の特定の会社インスタンスを表し、p : Person は名前が「p」の特定の個人インスタンスを表す。

• 匿名オブジェクト： 特定のインスタンス識別子が省略されたり、シナリオに関係がなかったりする場合、コロンで始まるクラス名のみが提示される（例：: ContactInformation）。これは、連絡情報の具体的なインスタンスが存在し、構造に接続されていることを示しているが、この文脈では固有の変数名を必要としないことを意味する。

状態と属性値

オブジェクト長方形の下側の領域には、その特定の状態が含まれており、その瞬間に属性に割り当てられた明示的な値によって定義される。データ型を単に列挙するのではなく、これらの項目は属性 = 値という代入形式を用いて現実を反映している：

• 部門インスタンスd1は属性値name = 営業部.

• 別の異なる部門インスタンスd2は値name = 研究開発.

• 人物インスタンスpは完全な状態データセットを保持しており、特定のプロファイルを示している：name = デレク, employeeID = D-12821、およびtitle = マネージャー.

リンクと関係

オブジェクトを結ぶ実線はリンク. リンクは、クラスの間に定義された関連の具体的なインスタンスです。クラス図が「会社には部門がある」と述べている場合、オブジェクト図はそれらの間の実際の実行時接続を示します。

• 会社のインスタンス cは、部門のインスタンス d1（営業）および d2（研究開発）に積極的にリンクしています。

• この図は、階層的なインスタンス接続も示しており、d1 : Department（営業）は、Department型のサブ部門インスタンスにリンクしており、（name = 米国営業).

• 最後に、個人のインスタンス p（デレク）は米国営業部門のインスタンスにリンクしていますが、同時に彼の物理住所を含む匿名の: ContactInformationインスタンスともリンクしています。

使用するタイミング:

• クラス図の設計の検証

• 複雑なオブジェクト関係のデバッグ

• 例示的な実行時状態の提示

---

🔶 挙動図

挙動図は、システムが時間とともにどのように振る舞うかという動的な側面をモデル化します。

7. 活動図

目的: ワークフロー、ビジネスプロセス、アルゴリズム論理をモデル化する。

主要な要素:

• アクション（丸みを帯びた長方形）

• 制御ノード：初期、決定、マージ、フォーク、ジョイン、最終

• オブジェクトノードとピン

• 責任割り当てのためのパーティション（スイムレーン）

• 例外ハンドラと中断可能な領域

使用例：注文処理ワークフロー

構造的組織（スイムレーンとパーティション）

図は垂直方向に大きな列に整理されており、これらは互換的に「スイムレーンまたはパーティション」として知られている。これらの境界は、それらの内部に含まれるアクションの責任を分類し、ステップを特定の役割やビジネスユニットにマッピングする。

• カスタマーセールスインターフェース：顧客対応のライフサイクルを所有し、クライアントの初期化、代替ルーティング、最終的な提示を処理する。

• プロポーザル所有者：コア計画、運用分析、および正式なプロポーザルデータ構造の編集を管理する。

• 見積もり所有者：財務評価と特定の見積もり指標の準備にのみ注力する。

制御フローとアクション状態

段階的な手順的実行は、制御ノードと方向性のある経路によって制御される。

• 初期ノード：上部の実心黒丸で表され、すべてのアクティビティワークフローの開始点を示す。

• アクション： 丸みを帯びた長方形（例：連絡先を初期化, 代替を検索、および追加情報を編集) は実行シーケンス内の単一で分解不能なステップまたはタスクを表します。

• 制御フロー： 要素を結ぶ実線矢印は、ワークフローの順次進行を規定しており、次のアクションが開始される前に、どのアクションが必ず完了しなければならないかを明確に示しています。

• アクティビティ終了ノード： 下部にあるダーツボード記号（空洞の輪の中に実線の円）は、プロセス実行の絶対的な終了点を示しています。

ルーティングとガード付き論理（決定ノード）

ダイアモンド型の記号は、決定ノードを表し、ワークフローにおける条件分岐をモデル化しています。

• 入力制御パスは、特定の入力に基づいて複数の排他的な出力パスに分岐されます。

• どのパスを取るかを規定する条件は、四角括弧で囲まれており、ガード条件と呼ばれます（たとえば[承認済み], [却下済み]、および[他のサプライヤーと統合する、または要件を変更する]）。プロセスは実行時、これらのガードを評価して、適切な機能パスに実行をルーティングします。

並列処理（フォークノードとジョインノード）

図中の実線の黒いバーは、並行または並列実行ストリームを管理する同期ポイントとして機能します。

• フォークノード（図のポインターで「フロー・ノード」とラベル付けされています）：単一の入力制御フローがバーに入り、複数の独立した並行実行スレッドに分岐します。ここでは、プロジェクト計画を作成した後、プロセスがフォークされ、提案担当者が分析および納品計画を実行する一方で、見積もり担当者が見積もり作成を同時に処理できるようにします。

• ジョインノード：複数の並行パスを再び単一の制御フローに統合する同期バーです。プロセスは、すべての入力される並行ストリームがバーに正常に到達するまで、ジョインノードを通過できません。これにより、最終パッケージのコンパイルに進む前に、見積もりの統合と提案書の作成が完全に完了していることが保証されます。

データ統合（オブジェクトノード）

標準的な長方形は、オブジェクトノードを示し、制御中心のアクティビティ図にデータフローを導入します。

• オブジェクトノードは、アクションによって生成または消費される特定のデータや物理的アーティファクトのインスタンスを表し、インスタンス名 : クラス名表記規則（例：提案 : 提案 および 計画 : 配信プロジェクト計画).

• 明示的にマークされた 作成矢印は、アクションがデータ構造をインスタンス化または更新する正確なタイミングを示し、運用の実行と並行してデータがタスクからタスクへどのように流れているかを示している。

使用するタイミング:

• ビジネスプロセスの文書化

• ユースケースの実現のモデル化

• 複雑なアルゴリズムの指定

---

8. 状態機械図（Statecharts）

目的：オブジェクトのライフサイクルおよび状態依存の振る舞いをモデル化する。

主な要素:

• 状態（エントリ／エグジット／実行アクティビティを備えた丸い長方形）

• 遷移（トリガー[ガード]/効果）

• 擬似状態：初期、選択、分岐、結合、履歴、終了

• 複合状態と直交領域

使用例：電話システムの設定

状態とシステム状態

この図は、電話システムの設定といった特定のシステムの振る舞いを、そのさまざまな離散的な状態や条件をマッピングすることによって捉えている。

• 状態： 丸い長方形は状態を表す（例：アイドル, ダイヤルトーン, ダイヤル中, 接続中、および接続済み）。状態とは、オブジェクトのライフサイクルにおいて、ある条件を満たす、活動を実行する、またはイベントを待つ期間を表す。

• 初期擬似状態： 左端の実線の黒丸は、状態機械の開始点を表している。これは真の状態ではなく、擬似状態であり、オブジェクトがインスタンス化された際にデフォルトのアクティブ状態を指すだけである（アイドル).

• 最終状態： 右端のブルーサイドシンボルは、状態機械の実行の終了を表しており、オブジェクトがライフサイクルを完了したことを示している。

遷移とイベント駆動ルーティング

状態を結ぶ矢印線は遷移であり、特定のトリガーに対する反応として、一つの状態から別の状態への移動を表している。

• 標準遷移：特定のイベント（ユーザー操作やシステム応答など）によって発動され、線に注記される。たとえば、アイドルからダイヤルトーンへの移行は、onHookイベントが発動されたときに発生し、ダイヤルトーンからダイヤル中 は、 が発生したときに起こる。digit(n) イベントが受信されたとき。

• 自己遷移： 状態から出て再び同じ状態に戻る遷移矢印（ に見られるように）。Dialing 状態で、digit(n) トリガー）。これは、イベントが処理され、内部状態コンテキストが更新されること（例：新たにダイヤルされた桁を記録する）を示しており、オブジェクトがその全体的な運用状態を終了または変更することなく行われることを意味する。

代替パスとエラー処理

状態機械は、実行中のさまざまな条件に基づいて、行動論理とエラー分岐を示すことに長けている。

• 成功した実行パス： 中央の水平パイプラインは最適なパスを示している：Idle $rightarrow$ DialTone $rightarrow$ Dialing $rightarrow$ Connecting $rightarrow$ Ringing $rightarrow$ Connected $rightarrow$ Disconnected.

• 例外およびエラー処理状態： システムは、障害や遅延に対応するために専用の処理状態に分岐する。接続中に番号がビジー状態の場合、システムはnumberBusy 进入するための遷移ビジーターン 状態。ユーザーが通話中に長時間一時停止すると、タイムアウト イベントによりシステムは警告 またはタイムアウト 状態に移行する。誤ったシーケンスが検出されると、無効な番号 トリガーによりシステムは録音メッセージ 状態にルーティングされ、システムがすべての現実世界の境界ケースを安全に処理できることを保証する。

 

使用するタイミング:

• 組み込みシステムやプロトコル実装のモデル化

• UIの状態管理の指定

• オブジェクトのライフサイクルルールの文書化

---

9. 準備図

4つの図の種類は、オブジェクト間の協調の異なる側面に注目する：

a) シーケンス図(最も一般的)

目的：ライフライン間の時間順序付きメッセージ交換を表示する。

主な要素:

• ライフライン（垂直の破線）

• メッセージ（実線／破線の矢印とラベル）

• 実行発生（アクティベーションバー）

• 結合断片：alt, opt, loop, par, break

使用例:

ライフラインと実行コンテキスト

図は左から右に読み進んで参加者を設定し、上から下に読み進んで時間を表す。

• ライフライン： 上部に接続された破線の垂直線に付いているボックスがライフラインを表す。これらは、次の表記に従って、相互作用における個々の参加者をモデル化する。インスタンス名 : クラス名 表記規則（例：window : UI, aChain : HotelChain、およびaHotel : Hotel）。破線は、その参加者がシーケンス全体にわたって存在していることを追跡する。

• アクティベーションバー： ライフラインの上に置かれた細い色付きの垂直長方形は、アクティベーション（または実行発生）を示す。これらのバーは、オブジェクトが操作を実行中であるか、ネストされたサブコールの戻りを待っているかを正確に示す。

• 停止： の下部にある大きな「X」記号はwindow : UIライフラインは破壊または終了を示し、この特定の参加者のライフサイクルが終了し、そのリソースが解放されたことを表しています。

メッセージの種類と通信

参加者間の通信は、メッセージを表す水平の矢印でモデル化され、階層的な番号付けシステム（例：1、1.1、1.1.1）を使用して順次番号が付けられます。

• 同期メッセージ：実線と実線の矢印（例：1: makeReservationおよび1.1: makeReservation）は同期呼び出しを示します。送信者は実行をブロックし、受信オブジェクトが処理を完了するのを待つことになります。

• 自己メッセージ： 同じアクティベーションバー上で開始および終了するメッセージループ（例：1.1.1: available(roomId, date): isRoomによって実行されるaHotel）は自己メッセージを表します。これは、オブジェクトが自身の操作の一つを呼び出す内部メソッドの実行を示しています。

• 作成メッセージ： 点線と開放矢印頭がオブジェクトボックスを直接指すもの（例：メッセージ1.1.2:がaReservation : Reservation）はオブジェクトの作成を表します。これは、aHotelインスタンスが、実行時シーケンスのその瞬間にaReservationオブジェクトを動的にインスタンス化することを示しています。

結合フラグメントと制御フロー

シーケンスの一部を囲む大きな長方形のボックスは結合フラグメント複雑な論理、分岐、反復を管理するために、相互作用演算子を使用する。

• ループ断片：ラベルが付いた外側のボックスループガード条件を伴い[毎日]これは反復を表す。このボックス内に含まれるすべての相互作用は、予約要求で指定された毎日に対して連続的に繰り返される。

• 代替結合断片（Alt）：ループ内に埋め込まれたalt断片（図のポインタで「If」と注釈されている）は条件分岐を処理する。ガード条件を評価する[isRoom = true]。条件が満たされると、シーケンスはそのブロック内の特定のパスを実行する——aReservationインスタンスを作成し、その後メッセージを発信する2:をインスタンス化するためのaNotice : 確認。条件が偽であった場合、代替パス（または何も実行されない）が選択される。

  

b) コミュニケーション図

目的：メッセージのタイミングよりもオブジェクト間の関係性に重点を置く。

主な要素:

• オブジェクトをノードとして

• 番号付きで方向性を持つメッセージを伴うリンク

• 「誰が誰に話しかけているか」に焦点を当てる

c) 相互作用概要図

目的：アクティビティ図記法を用いた制御の高レベルな流れを示す。

主要な要素:

• 相互作用の発生をアクティビティノードとして

• 分岐のための決定/マージ

• 並列処理のためのフォーク/ジョイン

d) 時間図

目的: 精密なタイミング制約をモデル化する（リアルタイムシステム）。

主要な要素:

• 各ライフラインの状態タイムライン

• 時間スケールと制約

• 期間マーカー付きのメッセージ矢印

相互作用を使用するタイミング:

• ユースケースの実現を指定する

• 複雑なメッセージフローのデバッグ

• APIの使用パターンの文書化

• リアルタイムプロトコルのタイミングをモデル化する

---

10. ユースケース図

目的: 外部アクターの視点から機能要件を捉える。

主要な要素:

• ユースケース（楕円または分類子長方形）

• アクター（棒人形または分類子）

• 関連（アクター ↔ ユースケース）

• 関係: «include», «拡張»、一般化

• システム境界ボックス

使用例：ATMシステム

使用するタイミング:

• ステークホルダーとの要件収集

• システムの範囲と境界の定義

• テストシナリオの計画

---

🎯 適切な図の選択：意思決定ガイド

目的	推奨される図
クラス構造の設計	クラス、オブジェクト、パッケージ
実行時相互作用のモデル化	順序図、通信図
ビジネスワークフローの文書化	アクティビティ図、ユースケース図
オブジェクトのライフサイクルの指定	状態機械図
システムの展開計画	展開図、コンポーネント図
複雑な内部構造のモデル化	複合構造図
リアルタイム制約の把握	タイミング図
要件の定義	ユースケース図、アクティビティ図

---

🔑 モデリングの基本原則

1. シンプルから始めよう: 即時の目標に最も合った図の種類から始めましょう。

2. 繰り返し改善する: 理解が深まるにつれてモデルを改善しましょう—初稿で「最終版」となる図は存在しません。

3. 対象読者に応じる: 読者（開発者 vs. ステークホルダー）に応じて詳細度を調整しましょう。

4. 複数の視点を組み合わせる: 複数の図を用いて、包括的な物語を伝える（例：ユースケース → シーケンス → クラス）。

5. 慎重に拡張する: 領域固有のニーズに応じてステレオタイプ、タグ付き値、プロファイルを使用するが、規約は文書化すること。

6. 読みやすく保つ: 関係のない詳細は省略し、補足的な文脈は注記で記載する。

📌 思い出そう: 「UMLは手法ではなく、言語である。」 それはプロセスではなく、記法を提供する。チェックボックスを埋めるための図ではなく、コミュニケーションを明確にする図を選ぶこと。

結論