システム工学において、システムモデリング言語（SysML）は、複雑な要件、構造、動作を定義する基盤として機能する。しかし、適切な図の種類を選択することは単なる好みの問題ではなく、コミュニケーション、検証、検証に大きな影響を与える重要な意思決定である。エンジニアは、特定の問題に対してシステムのどの視点が最も適しているかを判断するという課題に直面することが多い。このガイドでは、SysMLの図の種類の違いを検討し、情報に基づいたモデリング選択を行うためのフレームワークを提供する。
各図の種類は独自の視点を提供する。誤った視点を使用すると曖昧さが生じるが、正しい視点を使用すれば意図が明確になり、設計エラーのリスクが低下する。本稿では、構造図、動作図、要件図を検討し、エンジニアリングライフサイクルにおけるそれぞれの具体的な応用を理解する。
🏗️ 構造図：構成とフローの定義
構造図はシステムの静的側面に注目する。システムを構成する部品と、それらの部品どうしの関係を記述する。これらの図は基盤となるものであり、動作図が後に作用するための語彙とトポロジーを確立する。
ブロック定義図（BDD）
ブロック定義図は、あらゆるSysMLモデルの出発点となることが多い。システム階層内に存在するブロックの種類を定義する。これはシステム構成の建築図に相当する。
- 主な機能： ブロックの種類、プロパティ、およびサブブロックを定義する。
- 最も適した用途： 高レベルの分解、インターフェースの定義、継承関係の確立。
- 主な要素： ブロック、プロパティ、参照、および値プロパティ。
実務者は、「このシステムの構成要素は何ですか？」や「システムは階層的にどのように構成されていますか？」といった質問に答える必要がある場合、BDDを選択する。これはシステムの「名詞」側を捉えるために不可欠である。たとえば航空宇宙分野では、BDDは「推進システム」、「誘導システム」、「ペイロード」を別個のブロックとして定義し、誘導システムが全体の「車両」の一部であることを明示する。
複雑なシステムをモデリングする際、BDDは複数の抽象レベルを許容する。トップレベルのBDDで主要なサブシステムを示し、その後のBDDで「推進システム」の詳細に掘り下がるといった形になる。この関心の分離により、モデルは管理可能に保たれる。
内部ブロック図（IBD）
BDDはブロックの「種類」を定義するのに対し、内部ブロック図はブロックの「インスタンス」とその接続を定義する。これは特定のブロックがどのように接続されてシステム機能を達成するかを示す図である。
- 主な機能： 特定のブロックインスタンス間の接続（フロー）を示す。
- 最も適した用途： インターフェースポート、フロー特性、および信号／データ伝送経路の定義。
- 主な要素： ポート、フロー特性、コネクタ、および参照特性。
エンジニアは、部品間の物理的または論理的な接続が主な関心事である場合、IBDを選択する。たとえば「センサーのデータはどのようにコントローラに届くか？」という問いに対して、IBDが適切なツールである。これは情報または物質の流れを可視化する。
熱管理システムを想定する。BDDでは「ヒートシンク」ブロックを定義する。IBDでは、「ヒートシンク」が「ポンプ」と「流体フロー」ポートを介して接続される様子を示す。IBDがなければ、シミュレーションや物理的実装に必要な接続詳細がモデルに欠ける。
パラメトリック図
パラメトリック図は、SysML図の中で唯一無二の存在である。なぜなら、システム動作を支配する数学的制約に焦点を当てるからである。構造的プロパティを方程式と結びつける。
- 主な機能： 性能限界を定義する制約と方程式を捉える。
- 最も適した用途： 性能モデリング、サイズ計算、および設計制約の検証。
- 主要な要素： 制約ブロック、制約プロパティ、および接続子。
システムに厳密な性能検証が必要な場合、パラメトリック図は不可欠となる。たとえば、エンジニアリングチームがバッテリーパックが過熱せずに特定の放電率を維持できるかどうかを検証する必要がある場合、パラメトリック制約を使用する。電流、抵抗、温度の変数を定義し、関連するブロックにリンクする。
「どれだけ」または「どれだけ速く」の質問が生じた場合、実務者はこの図を選びます。これは、システムの物理的構造と数学的現実の間のギャップを埋める。
🔄 挙動図：論理と相互作用の記録
挙動図は、システムが時間とともにどのように変化するかを記述する。システムの動的側面、環境との相互作用や内部状態の変化を捉える。
ユースケース図
ユースケース図は、外部のアクターの視点からシステム機能の高レベルなビューを提供する。
- 主な機能： 機能要件とシステムの範囲を定義する。
- 最も適した用途：ステークホルダーとのコミュニケーションおよび初期要件の収集。
- 主要な要素： アクター、ユースケース、および関係。
この図は、ライフサイクルの初期段階でよく使用される。システムとやり取りするのは誰か？システムは彼らに何を提供するか？という問いに答える。実装の詳細よりも、価値提案に重点を置く。たとえば、医療機器の文脈では、アクターとして「医師」「患者」「保守技術者」が含まれ、ユースケースとして「状態の診断」や「センサーのキャリブレーション」などが挙げられる。
これはエンジニアと非技術的ステークホルダーとの間のコミュニケーションツールとして機能する。構築中のシステムがユーザーのニーズと一致していることを保証する。
アクティビティ図
アクティビティ図はフローチャートに似ているが、オブジェクトフローとスイムレーンといったSysMLの完全な機能を備えている。
- 主な機能： 単一の操作またはワークフローの論理を記述する。
- 最も適した用途： 複雑なプロセス、意思決定論理、並行処理のモデル化。
- 主要な要素： アクション、制御フロー、オブジェクトフロー、スイムレーン。
ステップの順序やプロセス内のデータフローに注目する場合、アクティビティ図が標準的な選択となる。これは運用手順のモデル化に特に効果的である。たとえば、ロケットの「発射シーケンス」はここにモデル化され、「点火」から「ステージ分離」までのステップを示し、エンジン状態の判断ポイントを含む。
操作の順序が特定のオブジェクト間の相互作用のタイミングよりも重要である場合、実務者はシーケンス図よりもこれを好む。並行処理をうまく扱い、論理の並行ブランチを可視化できる。
シーケンス図
シーケンス図は、時間とともにオブジェクト間の相互作用に注目する。時間は下向きに進む垂直的な表現である。
- 主な機能： コンポーネント間のメッセージのやり取りを説明する。
- 主に以下の用途に適している： 時間的遅延、相互作用プロトコル、メッセージの順序を分析する。
- 主な要素： ライフライン、メッセージ、アクティベーションバー。
時間的タイミングやメッセージの順序が重要である場合、エンジニアはシーケンス図を選択する。ソフトウェアが中心となるシステムでは、インターフェースプロトコルを定義する際のデフォルト選択となることが多い。システムがデータ整合性を保証するために厳密なハンドシェイクプロトコルに依存する場合、シーケンス図によりその要件を明確に示すことができる。
これはアクティビティ図を補完する。アクティビティ図は「何が起こるか」を示すのに対し、シーケンス図は「コンポーネントがどのように相互に通信してその結果を実現するか」を示す。
ステートマシン図
ステートマシン図は、単一のオブジェクトまたはサブシステムのライフサイクルを、状態、イベント、遷移に注目して記述する。
- 主な機能： イベントに基づいて、システムまたはコンポーネントの動的動作をモデル化する。
- 主に以下の用途に適している： コントロール論理、組み込みソフトウェア、明確な動作モードを持つシステム。
- 主な要素： 状態、遷移、イベント、ガード。
この図は、離散的なモードで動作するシステムにとって不可欠である。たとえば、自律走行車には「停止中」「走行中」「駐車中」「緊急停止」などの状態がある。ステートマシン図は、ある状態から別の状態へ遷移を引き起こすイベントを正確に定義する。もし「緊急停止」ボタンが押された場合、システムは現在の状態にかかわらず直ちに遷移しなければならない。
論理が線形な手順の連続ではなく、イベントによって駆動される場合、実務者はこの図を選択する。制御ループや状態依存の動作をモデル化する際、アクティビティ図よりも優れた選択となる。
📋 要件：要件と設計のリンク
要件図は構造図でも振る舞い図でもないが、トレーサビリティに不可欠な別カテゴリーである。
- 主な機能： システムの要件と制約を定義する。
- 主に以下の用途に適している： 要件管理、トレーサビリティ、検証。
- 主な要素： 要件、要素、関係。
すべてのSysMLモデルには要件図が必要である。これはシステムが達成すべきことを示す真実の根拠となる。要件をブロック、アクティビティ、その他の要素にリンクすることで、エンジニアは設計のすべての決定が特定の要件に基づいていることを保証する。
この図がなければ、検証は当てずっぽうのゲームになる。要件が明示的にモデル化され、リンクされていなければ、システムが顧客の要件を満たしていることを証明することはできない。
📊 比較表：問題とモデルの対応
意思決定を支援するために、以下の表は一般的な工学的問題に基づいた最適な図の選択を要約している。
| 問題シナリオ | 推奨される図の種類 | なぜですか？ |
|---|---|---|
| システムはどのように構成されていますか？ | ブロック定義図（BDD） | 階層構造と型を定義します。 |
| 部品は物理的にどのように接続されますか？ | 内部ブロック図（IBD） | ポートとフローを示します。 |
| 性能の限界は何ですか？ | パラメトリック図 | 数学を構造に結びつけます。 |
| ユーザーが必要とする機能は何ですか？ | ユースケース図 | 価値と範囲に焦点を当てます。 |
| 段階的なプロセスは何ですか？ | アクティビティ図 | ワークフローと論理をモデル化します。 |
| オブジェクトは時間とともにどのように相互作用しますか？ | シーケンス図 | メッセージのタイミングを可視化します。 |
| システムはどのようにモードを変更しますか？ | ステートマシン図 | 状態と遷移をモデル化します。 |
| 制約は何ですか？ | 要件図 | トレーサビリティを確立します。 |
🧭 選択と一貫性のための戦略
適切な図を選択するには自制心が必要です。よくある間違いは、同じ種類の図をあまりに多く作ることで、重複や混乱を招くことです。以下の戦略は、明確さを保つのに役立ちます。
- 抽象度：ステークホルダー向けには高レベルの図を、エンジニア向けには詳細な図を保持してください。システムレベルのBDDは、サブシステムレベルのBDDと同じ詳細を含んではいけません。
- 一貫性：IBD内のブロックがBDDの定義と一致していることを確認する。BDDでブロックの名前が変更された場合、IBDおよび行動図内のすべての参照を更新する必要がある。
- トレーサビリティ：常に要件をそれらを実装する図にリンクする。これにより、「なぜ」から「どうやって」への明確な道筋が作られる。
- 最小限の実用的モデル：すべてをモデル化する必要はない。現在の問題に価値をもたらす図だけを作成する。図が特定の工学的問いを解決するのを助けない場合は、その必要性を再検討する。
⚠️ モデル構築における一般的な落とし穴
正しいモデルを作成することと同じくらい、誤りを避けることが重要である。SysML図の選定と使用においてよく遭遇する問題を以下に示す。
- BDDとIBDの混同：BDDにフロー属性を設置してはならない。BDDは型のためのものであり、IBDは接続のためのものである。これらを混同すると曖昧性が生じる。
- シーケンス図の過剰使用：シーケンス図はすぐにごちゃごちゃになる。全体のシステム動作ではなく、特定の相互作用ポイントにのみ使用する。
- 状態論理の無視：制御論理に活動図のみに頼ると、複雑でぐちゃぐちゃなフローになる。離散的なモードには状態機械図を使用する。
- 接続されていない要件：設計要素にリンクしない要件図を作成しても、検証において無意味になる。
🔗 統合と一貫性
SysMLの力はこれらの図の統合にある。それらは孤立したものではなく、同じモデルの視点である。一つの図で変更が加えられた場合、適用可能な他の図にその変更が伝搬されるべきである。
例えば、要件図に新しい要件が追加された場合、エンジニアはBDDに新しいブロックが必要かどうか、活動図に新しいアクションが必要かどうか、または状態機械に新しい遷移が必要かどうかを確認しなければならない。この相互参照により、モデルが一貫性を保つことが保証される。
実務者がこの統合を維持するとき、モデルは唯一の真実の源となる。設計が要件と一致しなくなる文書のずれの可能性が低くなる。
🔧 図の選定に関する最終的な考察
適切なSysML図を選ぶことは、経験と意図的な練習を通じて身につけられるスキルである。特定の工学的問いを理解し、それに適したモデリング表記を対応させる必要がある。
構造的定義、行動的フロー、数学的制約の違いを明確にすることで、情報性と実行可能性の両方を持つモデルを構築できる。目標は膨大な図のデータベースを作ることではなく、特定の問題を解決するための焦点を絞った視点のセットを作ることである。
図はコミュニケーションのためのツールであることを忘れないでください。図がチームのシステム理解を助けない場合、それは適切なツールではない可能性がある。各視点の必要性を継続的に評価する。明確さ、トレーサビリティ、一貫性に注目する。このアプローチにより、堅牢なシステム設計とより成功した工学的成果が得られる。
モデルを構築する際は、まず問題を頭に置き、次に図を検討する。要件が構造を決定し、構造が行動を決定するようにする。この階層構造により、SysMLモデルがシステムの目的と一貫性を保つことができる。