システム工学は正確さを要求する。抽象的な要件と具体的な実装の間をつなぐ言語が必要となる。システムモデリング言語（SysML）はこの橋渡しを提供し、その図のセットの中でブロック定義図（BDD）は構造モデリングの基盤となる。複雑な航空宇宙システム、医療機器、あるいはソフトウェアアーキテクチャを設計している場合でも、BDDを構築する方法を理解することは根本的なことである。
このガイドは、ブロック定義図を描くメカニズムを探求する。言語の意味論、関係性の背後にある論理、そして明確性を保つために必要な規律に焦点を当てる。特定のソフトウェアツールは言及されていない。原則はモデリング環境を問わず普遍的に適用可能である。目的は、検証に耐えるシステム構造のメンタルモデルを構築することである。
ブロック定義図の理解 🧠
ブロック定義図は、システムの静的構造を定義する。全体を構成する部品、それらが互いにどのように関係しているか、そして各コンポーネントに割り当てられた責任を記述する。内部ブロック図（IBD）が部品間のデータや信号の流れに注目するのに対し、BDDは定義そのものに注目する。
BDDは何を表すのか？
BDDを、家の基礎と耐荷重壁の図面に例えることができる。どの材料が使われているか、壁がどのように接続されているかを教えてくれるが、配線や配管の経路は示さない。SysMLの用語で言えば：
- ブロックは抽象化の主な単位である。システム、サブシステム、またはコンポーネントを表す。
- 関係は、ブロックが構造的にどのように相互作用するかを定義する。
- プロパティは、ブロックが保持する属性やデータを記述する。
- 操作は、ブロックが実行できる振る舞いや行動を記述する。
正しく描かれた場合、BDDはステークホルダーが複雑な振る舞いの流れを追跡せずにシステムの構成を理解できるようにする。この問いに答える：「システムはどのような部品で構成されているのか？」
SysMLのコアとなる構成要素 🧱
自信を持ってBDDを描くためには、言語の原子となる要素を理解する必要がある。各要素には特定の意味論的意味があり、それがモデルの解釈に影響を与える。
1. ブロック
ブロックは複合要素である。構造と振る舞いを統合する。図では、ブロックはプロパティと操作のための特定のコンパートメントを持つ長方形で表される。ブロックは以下の通りである：
- システムブロック：設計対象の最上位エンティティである。
- サブシステムブロック：システム内の主要なコンポーネントである。
- コンポーネントブロック：交換可能な物理的または論理的な部品である。
- パッケージブロック：他のブロックを整理するために使用する（名前空間に似ている）。
2. プロパティ vs. パーツ vs. リファレンス
これはよくある混乱の原因となる領域である。これら3つはすべて関係を定義するが、意味論は大きく異なる。
| 要素 | 意味論 | 例 |
|---|---|---|
| プロパティ | ブロックが保持するスカラー値または単純な属性。 | 重量、電圧、色 |
| 部品 | ブロックに属する内部コンポーネント。部品は所有者なしでは存在できない。 | 車のエンジン、電話のバッテリー |
| 参照 | 外部のブロックへの接続。参照されるブロックは独立して存在可能である。 | 車のドライバー、電話の充電器 |
適切な用語を使用することで、モデルがシステムコンポーネントのライフサイクルと所有関係を正確に反映することが保証される。部品が破棄されると、全体に影響が及ぶ。参照が削除されても、ブロックは機能し続けるが、その動作は異なるものになる。
関係性と接続性 🔗
SysMLの力は、ブロックがどのように接続されるかに尽きる。ブロックはあるが接続がない図は、単なる部品のリストにすぎない。関係性がアーキテクチャを定義する。
1. 関連
関連は、2つのブロック間の構造的接続を表す。一方のブロックのインスタンスが、他方のブロックのインスタンスとリンク可能であることを示す。これは最も一般的な関係の形式である。
- 方向：関連は単方向または双方向であることができる。
- 多重度：何個のインスタンスが関与するかを定義する（例：1..*、0..1）。
- 使用法：所有関係が示されない一般的なリンクに使用する。
2. 聚合
聚合は、部品が全体から独立して存在可能な「全体-部分」関係を表す。これは所有関係の弱い形である。
- 視覚的インジケーター：「全体」側に空洞のダイヤモンド。
- 例：部門には従業員がいる。部門が閉鎖されても、従業員は人々として依然として存在する。
- 制約： 全体が破壊されても、部分は破壊されない。
3. 組成
組成は、集約の強い形態である。厳密な所有関係とライフサイクルの依存関係を意味する。
- 視覚的インジケーター： 「全体」側に塗りつぶされたダイヤモンド。
- 例： カーにはエンジンがある。カーが廃棄されると、エンジンも通常一緒に廃棄される。
- 制約： 部分は全体が存在しなければ存在できない。
4. 汎化
汎化は継承を表す。子ブロックは親ブロックの特殊化されたバージョンである。
- 視覚的インジケーター： 親を向いている空洞の三角形を備えた実線。
- 使用法： ポリモーフィズムや型階層をモデル化するために使用する。
- 利点： 親ブロックに共通のプロパティを定義し、子ブロックに特定のプロパティを定義できる。
ポートとインターフェース 🚪
BDDは構造に注目するが、システムが外部世界とどのように相互作用するかを定義する必要もある。これがポートとインターフェースの役割である。
相互作用ポイントの定義
ポートは相互作用のポイントである。ブロックが実行できる相互作用の集合を定義する構造的要素である。ポートがなければ、ブロックは孤立した島となる。
- 必須ポート： ブロックが機能するために環境から必要とするものを示す。
- 提供ポート： ブロックが環境に提供するものを示す。
インターフェースを介した接続
インターフェースは、ブロックが実行可能または必要とする操作の集合である。実装と相互作用を分離する。
- インターフェースを定義する： インターフェースを表すブロックタイプを作成する（通常はインターフェースブロック）。
- ポートに接続する： ポートをインターフェースに接続してください。
- 接続性の確認： 提供されたポートが、有効なパスを形成するために必要なポートに接続されていることを確認してください。
この分離により、インターフェースが一定のままであれば、ブロックの内部実装を変更しても、システムの他の部分との接続が壊れることなく済みます。
制約とルール ⚖️
構造だけではすべての要件を捉えきれない。制約により、システムインスタンスが満たさなければならないルールを表現できる。
制約の種類
制約は通常、ブロック内のコンパートメントに配置されるか、関係に付随して設置される。
- テキスト制約：ルールの単純なテキスト記述。
- モデル制約：OCL（オブジェクト制約言語）のような形式言語を用いて、数学的または論理的なルールを定義する。
制約シナリオの例
「電源」を表すブロックを考えてみよう。制約として、出力電圧が入力電圧に対して特定の範囲内にある必要があると規定することができる。この制約はブロックに付随しており、電源の任意のインスタンスがこの物理法則に従うことを保証する。
制約により、図は単なる絵から仕様へと変化する。制約はモデルと検証プロセスの間の橋渡しとなる。
スケーラビリティを考慮した構造化 🏗️
システムが大きくなるにつれて、単一の図は読みにくくなる。複雑さを扱いつつも明確さを失わないように、BDDを構造化しなければならない。
抽象度レベル
一つのビューですべてをモデル化しようとしない。詳細を管理するために、抽象度レベルを使用する。
| レベル | 注目点 | 詳細 |
|---|---|---|
| システムレベル | 上位レベルの分解。 | 高レベルのサブシステムのみ。 |
| サブシステムレベル | 主要なコンポーネントの内部構造。 | サブシステム内のブロックとインターフェース。 |
| コンポーネントレベル | 実装の詳細。 | 物理的な部品と詳細なインターフェース。 |
パッケージの使用
ブロックをパッケージに整理する。これはファイルシステムのフォルダと似ている。関連するブロックを論理的にグループ化できる。
- 論理的グループ化： 機能ごとにブロックをグループ化する（例：「熱管理」）。
- 物理的グループ化： 位置ごとにブロックをグループ化する（例：「左翼」）。
- レイヤリング： 定義と使用を分離する。
大きなモデルをナビゲートする際、パッケージは複雑さを隠すことができる。パッケージを高レベルの図における単一のブロックとして見ることができる。
避けるべき一般的な落とし穴 ⚠️
経験豊富なモデラーですらミスをする。これらのパターンを早期に認識することで、技術的負債を防ぐことができる。
1. 「スパゲッティ」図
あまりにも多くの関連が1ページに描かれると、図は読めなくなる。線が交差し、ラベルが重なり、構造が失われる。
- 解決策： パッケージを使用する。システムを分解する。メインビューには高レベルの接続のみを表示する。
2. 部品と参照の混同
意図しているのが部品なのに参照を使用する（またはその逆）と、システムのライフサイクルの意味論が変わる。
- 解決策： 質問する：「所有者が破棄された場合、この部品は消えるか？」もし「はい」なら、コンポジション／アグリゲーションを使用する。もし「いいえ」なら、関連／参照を使用する。
3. 行動の過剰モデリング
アクティビティフローをBDD内に配置しないでください。BDDは構造のためのものである。行動はシーケンス図、アクティビティ図、またはステートマシン図に属する。
- 解決策： BDDを整理し、常に「何であるか」と「どのように構築されているか」に注目する。行動の「どのように動作するか」には注目しない。
4. 多重性の無視
多重性を定義しないと曖昧さが生じる。システムにはエンジンが1つあるのか、10個あるのか？
- 解決策： 常に基数を定義する。単一インスタンスには1、オプションには0..1、必須のコレクションには1..*を使用する。
保守とバージョン管理 🔄
モデルは静的な文書ではない。要件の変化に伴って進化する。BDDの管理には規律が必要である。
変更管理
要件が変更された場合、影響を受けるブロックにその変更を追跡する。BDDを更新し、関連する図（IBDやシーケンス図など）への影響を検証する。
- トレーサビリティ：すべてのブロックが要件にリンクしていることを確認する。
- 影響分析：子ブロックの変更が親のインターフェースを破壊しないか確認する。
ドキュメント戦略
図だけでは不十分である。複雑な構造の背後にある理由を説明するために、テキストコンパートメントを使用する。
- メモ：明らかでない動作をするブロックに説明用のメモを追加する。
- タグ：特定の目的（例：「安全上重要な」、「ソフトウェア専用」）のためにブロックをマークするため、ステレオタイプまたはタグを使用する。
モデリングの規律に関する結論 🛡️
ブロック定義図を描くことは、単に形状を描くことではない。システム構成について明確に考えるということである。命名、関係付け、要素の整理について、規律的なアプローチが求められる。
SysMLの意味論に従うことで、設計と実装の間で信頼できる契約として機能するモデルを作成できる。自然言語仕様に伴う曖昧さを回避できる。すべてのステークホルダーが分析・検証・理解可能な構造を構築できる。
これらの図を描く自信は、ルールを理解することから生まれる。明確さは、図の種類の境界を尊重することから生まれる。構造は簡潔に、関係は意味を持たせ、範囲は適切に保つこと。
主要なコンセプトの要約 📝
- BDD： 静的構造と構成を定義する。
- ブロック： 抽象化の基本単位。
- 組成： 強い所有権、共有ライフサイクル。
- 集約： 弱い所有権、独立したライフサイクル。
- ポート： 通信のための定義された相互作用ポイント。
- 制約： 有効な構成を制限するルール。
- パッケージ： 複雑さとスケーラビリティを管理するために使用される。
これらの原則を一貫して適用する。モデルが設計を導くようにし、逆はしない。このアプローチにより、複雑さが増す中でもシステムアーキテクチャが堅牢を保つことが保証される。
