de_DEen_USfa_IRfr_FRhi_INjapl_PLpt_PTru_RUvizh_CNzh_TW

モデリングの基礎とUML

Table of Contents hide
1 1. モデルとは何か？
1.1 モデリングの4つの原則
1.2 UMLとは何か？
1.3 UMLの四本柱
2 2. UML図のエコシステム
3 3. コアUML図の説明
3.1 🔹 ユースケース図
3.2 🔹 アクティビティ図
3.3 🔹 シーケンス図
3.4 🔹 コミュニケーション図
3.5 🔹 コンポーネント図
3.6 🔹 デプロイメント図
4 4. クラス図と関係の習得
4.1 クラスの構造
4.2 関係の種類
5 5. 実践応用：INSPIRE地積モデル
5.1 演習1：コアクラスのモデリング
5.2 演習2：関係のモデリング
6 6. 効果的なUMLモデリングのベストプラクティス
7 結論

1. モデルとは何か？

モデルとは、特定の視点から見たシステムの完全な記述であり、現実の簡略化された表現として機能する。複雑なシステムは全体として完全に理解できないため、モデルを作成する。

モデリングの4つの核心的目的：

  1. 可視化意図されたシステムを可視化する。

  2. 指定システムの構造または動作を指定する。

  3. テンプレートを提供システム構築を指導するためのもの。

  4. 文書化設計意思決定を文書化する。

モデリングの4つの原則

  • 選択するモデルは、問題のアプローチ方を直接的に影響する。

  • すべてのモデルは、異なる精度レベルで表現可能である。

  • 最も効果的なモデルは、現実と密接に結びついている。

  • 単一のモデルでは十分ではない。複雑なシステムには複数の視点が必要である。

UMLとは何か？

その統合モデリング言語（UML）は、オブジェクト管理グループ（OMG）によって管理される標準化されたグラフィカル言語である。明確にメソドロジーや手順ではないが、以下を目的として用いられる技術的かつグラフィカルな仕様である：

「ソフトウェア集約型システムのアーティファクトを可視化し、仕様を定義し、構築し、文書化する。」

UMLは、概念的要素（ビジネスプロセス、システム機能）および具体的実装（コード文、データベーススキーマ、再利用可能なコンポーネント）の両方に対して、普遍的なブループリント形式を提供する。

Foundations of Modeling & UML

UMLの四本柱

目的 説明
可視化 すべてのステークホルダーが同じ言語で話すことを保証する。明確なモデルはコミュニケーションエラーを排除し、モデリングなしでは見えないシステムの側面を明らかにする。
仕様定義 正確で曖昧さがなく、完全なシステム定義を作成する。
構築 プログラミング言語（Java、C++、VB）、RDBMSのテーブル、またはOODBMSのストアに直接対応する。サポートする フォワードエンジニアリング （モデル → コード）および リバースエンジニアリング （コード → モデル）。
文書化 システムアーキテクチャ、要件、テスト計画、プロジェクトスケジュール、リリース管理を記録する。

2. UML図のエコシステム

UML 2.2は 14種類の図タイプ、2つの主要なグループに分類される：

  1. 構造モデル （静的アーキテクチャ）

  2. 振る舞いおよび相互作用モデル （動的プロセス）

異なる図は、異なるステークホルダーの視点を満たす。

  • ユースケースビュー： エンドユーザー機能

  • 論理ビュー： アナリストおよびデザイナー（システム構造）

  • プロセスビュー： ソフトウェア管理（パフォーマンス、スケーラビリティ、スループット）

  • 実装ビュー： プログラマー（具体的なコンポーネント）

  • 展開ビュー： システム統合担当者（トポロジー、インストール、通信）

3. コアUML図の説明

🔹 ユースケース図

  • 目的： システムの意図する機能とその環境をモデル化する。顧客と開発者間の契約として機能する。

  • 構成要素： アクター、ユースケース、およびそれらの関係性。

  • 補助図： アクティビティ図（ユースケース内のフロー）、シーケンス図（ユースケースを実現するためのオブジェクトの協働）

🔹 アクティビティ図

  • 目的： プロセスまたはユースケース内のイベントの段階的流れを可視化する。

  • 主要な要素：

    • アクション：ワークフロー内の離散的なステップ。

    • フロー：活動の順序。

    • 決定：ガード条件に基づいてフローを分岐する[条件].

    • フォーク：並行スレッドの開始。

    • ジョイン：並行スレッドの終了（同期）。

  • 例： チェック、競合解決、並行スケジュール更新を伴う授業登録フロー。

🔹 シーケンス図

  • 目的： オブジェクトが時間とともにどのように相互作用するかを示す。時間 利用ケースを満たすために。

  • 主な要素：

    • ライフライン：時間の経過に伴うオブジェクトの存在を示す垂直線。

    • オブジェクト／クラス：相互作用の参加者。

    • メッセージ：オブジェクト間で交換されるデータまたはメソッド呼び出し。

    • 実行発生：オブジェクトが実際に処理中であることを示す細長い長方形。

    • 結合断片: opt （オプション実行）、loop （繰り返し実行）、ref （別の相互作用を参照する）。

🔹 コミュニケーション図

  • 目的： シーケンス図の代替。時間的順序ではなく、オブジェクト間の構造的関係に重点を置く。構造的関係 オブジェクト間の関係性を、時間的順序よりも重視する。

  • 主な要素：番号付きメッセージでリンク上の相互作用の順序を示す、連結されたオブジェクト。

🔹 コンポーネント図

  • 目的：ソフトウェアコンポーネントレベルでの実行時構造を示す。

  • 主な要素：外部インターフェースの背後に隠されたモジュール構成の部分。実装関係を示すために、しばしばクラスを含む。

🔹 デプロイメント図

  • 目的：ソフトウェアアーティファクトを物理的なハードウェアにマッピングする。

  • 主な要素：

    • ノード：物理的なマシンまたは実行環境を表す。

    • アーティファクト：物理ファイルまたはデプロイ可能なユニットを表す。

    • 所有要素：ネストされたまたは包含関係を示す。

4. クラス図と関係の習得

クラス図は、 静的構造 を描く。これらはデータ仕様（例：INSPIRE）の基盤であり、時間的情報を示さない。しない 時間的情報を示さない。

クラスの構造

コンパートメント 説明
名前 クラスの識別子（例： CadastralParcel）。しばしば «FeatureType».
属性 名前付きのプロパティとデータ型（例：- アドレス : char, - 樹齢 : int）。サポートされる型：Integer、LongInt、Double、Char、Date、Boolean、String、Geometryなど。
操作 クラスの振る舞い／メソッド。形式：+ 操作名(入力型) : 返り値型.

関係の種類

関係 記号 意味
関連 ─────── クラス間の一般的なリンク。役割名、ナビゲーション矢印、および基数（1..*, 0..*, 1..2など）を含む。
一般化 ─────▷ 継承。サブクラス（ソース）はスーパークラス（ターゲット）のすべての特徴を継承する。
集約 ◇───── 「部分-全体」関係。部分独立して存在できる全体の一部である。（空枠のダイヤモンド）
構成 ◆───── 強い「部分-全体」関係。部分の存在は完全に全体に依存する全体に依存する。（塗りつぶされたダイヤモンド）

トレーニング資料からの例：

  • 人物 → 木こり（一般化：木こりは継承する）名前, 性別)

  • 森 ◇─ 木（集約：木は特定の森に依存せずに存在できる）

  • 木こり ◆─ 従業員（構成：この文脈では、従業員は木こりエンティティに依存して独立して存在できない）

5. 実践応用：INSPIRE地積モデル

トレーニング資料は、INSPIRE地積データ仕様を用いて、現実世界におけるUMLの応用を示している。

演習1：コアクラスのモデリング

課題： 作成する 土地境界パーセル クラス。
ソリューション構造：

«featureType» 土地境界パーセル
- 住所 : char
- APN（パーセル番号） : char
- 境界 : GM_Surface
- 中心点 : GM_Point
- ラベル : char
- 国土地籍参照 : String
- 面積値 : double（オプション）
- 参照点 : GM_Point（オプション）

注意：複数の有効な解決策が存在する。属性は一般的な現実世界の特徴を反映するべきである。

演習2：関係のモデリング

タスク： 接続する 土地境界パーセル, 土地境界、および 行政区域.
重要なモデリングの決定事項：

  • 土地境界パーセル ──── 土地境界: 関連/組成 （境界がパーセルを定義する；しばしば 1..1 または 1..* 基数）。役割： +境界を構成する / +境界を持つ.

  • 地籍パーセル ◇── 行政区域: 集約/関連。その区域の存在はパーセルに依存しないパーセルに依存しない。パーセルは複数の階層的な区域に属する（1..*から0..*).

  • 教訓：ライフサイクルの依存関係とビジネスルールに基づいて関係の種類を選択する。図は現実を反映すべきであり、人工的な制約を強いるべきではない。

6. 効果的なUMLモデリングのベストプラクティス

  1. 図を戦略的に使用する：図は特定の視点を可視化する。複雑なシステムは1つの図からでは理解できない。

  2. 図の間で要素を再利用する：1つのクラスはクラス図、状態機械、シーケンス図、配置図にそれぞれ表示され、それぞれ異なる側面を強調することができる。

  3. 精度を対象の観客に合わせる：視聴者がエンドユーザー、開発者、システム統合者、プロジェクトマネージャーのいずれかに応じて、図の複雑さを調整する。

  4. 現実との整合性を検証する：モデル要素、関係、および基数が実際のシステム動作とドメインルールを反映していることを継続的に確認する。

  5. ツールのサポートを活用する：前向き/逆向きエンジニアリング、整合性チェック、コード生成に使用できるUML準拠のツール（例：Sparx Systems）を使用する。

結論

UMLは、ソフトウェアおよびデータ集約型システムのコミュニケーション、設計、文書化のための強力で標準化された言語である。主要な図（特にクラス図、シーケンス図、アクティビティ図、ユースケース図）を習得し、関係の意味論（関連、一般化、集約、合成）を理解することで、概念的な要件と技術的実装の間のギャップを埋める、正確で現実に即した設計図を構築できる。