リアルタイムシステムを設計するには正確さが求められます。信号が特定の時間枠内に到着しなければならない場合や、状態変化が予測可能に発生しなければならない場合、標準的なモデリング手法はしばしば不十分です。あなたが扱っているのは単に流れることだけではない論理であり、脈打つ、待つ、期限切れになるといった特性を持ちます。このような状況下で、適切な統一モデリング言語（UML）記法を選択することは、単なるスタイルの選択ではなく、システムの正しさに影響を与える重要なエンジニアリング意思決定です。
インタラクションモデリングに関する議論を支配する主な図の種類は2つあります：UMLシーケンス図 とUMLタイミング図両方とも動作を可視化しますが、システムの現実の異なる次元を捉えています。一方はメッセージの順序に注目し、他方は時間の経過に伴うオブジェクトの持続時間と状態に注目します。
このガイドでは、深い技術的比較を提供します。それぞれの図が同期、遅延、状態制約をどのように扱うかを詳細に分析します。最終的に、リアルタイム論理アーキテクチャにおいてタイミング図とシーケンス図のどちらをいつ使用すべきかを正確に理解できるようになります。
📡 リアルタイム文脈におけるシーケンス図の理解
UMLシーケンス図は、インタラクションの順序を可視化する業界標準です。オブジェクトが時間とともにどのように通信するかをマッピングし、オブジェクトを縦方向に、メッセージを横方向に配置します。リアルタイム論理の文脈では、論理的フロー ではなく物理的な持続時間.
- 注目点：メッセージの送受信と制御フロー。
- 時間軸：暗黙的。時間は上から下へ流れますが、スケールは定義されていません。
- 主な要素：ライフライン、アクティベーションバー、メッセージ（同期／非同期）、戻り値。
- 最適な用途：アルゴリズム、ハンドシェイクプロトコル、および操作の順序の定義。
リアルタイムシステムをモデリングする際、シーケンス図は次の問いに答えることができます：「次に何が起こるのか？」実行順序に依存する競合状態のデバッグにおいて、非常に価値があります。実行速度ではなく、実行順序に依存するものです。
シーケンス図の主な構成要素
このツールを効果的に使うには、その構造的用語を理解する必要があります：
- ライフライン：クラスやコンポーネントのインスタンスを表します。リアルタイムシステムでは、センサーやコントローラ、通信バスなどを表すことが多いです。
- アクティベーションバー： オブジェクトがアクションを実行しているときに表示します。これは制御の移譲を示しています。
- 同期メッセージ： 実線矢印で表されます。送信者は応答を待ってから次の処理に進みます。これはブロッキングロジックにとって重要です。
- 非同期メッセージ： 空矢印で表されます。送信者はすぐに次の処理に進みます。これはイベント駆動アーキテクチャで一般的な「送信して忘れること」のシナリオをモデル化します。
- 結合フラグメント： 以下のボックスのように
alt,opt、およびloop条件付きロジックや反復処理を図を複雑にせずにモデル化できます。
⏱️ 実時間コンテキストにおけるタイミング図の理解
UMLのタイミング図はしばしば無視されがちですが、時間に敏感な振る舞いをモデル化するための決定的なツールです。シーケンス図が時間の抽象化を行うのに対し、タイミング図は時間を主軸として扱います。オブジェクトの状態が特定のタイムラインに沿ってどのように変化するかを示します。
- 注目点： 時間経過に伴う状態の変化と信号値。
- 時間軸： 明確に表示されます。図の上部を水平方向に走ります。
- 主な要素： 状態機械、値の範囲、信号の遷移、およびデッドライン。
- 最も適している用途： ラテントシーアンストラクション、ジッター解析、および状態の有効期間の定義。
リアルタイム論理において、タイミング図は次の問いに答えます：「これは十分に速く発生しており、どのくらいの期間続くのか？」 システムがセンサー入力に対して5ミリ秒以内に応答しなければならない、または特定の期間にわたり信号電圧をしきい値以上に維持しなければならない場合、これは不可欠です。
タイミング図の主要構成要素
この図を習得するには、その時間的メカニズムに注意を払う必要があります：
- 時間スケール： 横軸は時間を表します。絶対時間（時計時間）または相対時間（経過時間）のいずれかです。
- 状態バー：水平なバーは、オブジェクトの状態（例：アクティブ、アイドル、エラー）を示します。バーの長さは持続時間を表します。
- 値の範囲：離散的なメッセージの代わりに、しばしば値の範囲（例：電圧：0V から 5V）が表示されます。これは物理システムにおいて重要です。
- 信号の遷移：状態バーを横切る垂直線は、値または状態の変化を示します。
- 制約：テキストボックスや注釈でハードデッドライン（例：
<デッドライン>).
🆚 核心的な違い：技術的比較
適切な判断を下すためには、これらの2つの表記法の構造的・意味的な違いを検討する必要があります。以下の表は、リアルタイムシステム設計に関連する違いを概説しています。
| 機能 | シーケンス図 | タイミング図 |
|---|---|---|
| 時間の表現 | 論理的な順序（上から下へ） | 物理的な持続時間（水平軸） |
| 主な焦点 | 相互作用の流れと制御 | 状態の変化と信号の値 |
| メッセージ対状態 | メッセージの送信に注目 | 状態の変化と値に注目 |
| 並行性 | 並行するライフラインを明確に示す | 時間の経過に伴う並行活動を示す |
| デッドライン | メッセージの順序によって示される | 時間軸と制約によって明示される |
| 複雑性 | 長いチェーンに対して高い認知負荷 | 多数の信号に対して高い認知負荷 |
🛠️ 実時間論理の際にシーケンス図を使うべきタイミング
タイミング図は時間的精度において優れているが、シーケンス図は相互作用モデリングの基盤のままである。以下の状況では、シーケンス図を優先すべきである：
- プロトコル定義： 通信プロトコル（例：MQTT、TCP/IPハンドシェイク）を定義している。SYN、ACK、FINパケットの順序の方が、正確なミリ秒単位の遅延よりも重要である。
- エラー処理： システムが障害に対してどのように反応するかを可視化する必要がある。コントローラーはリクエストをどのように再試行するか？ユーザーに通知する方法は？シーケンス図は分岐論理（alt/optフラグメント）をより効果的に扱う。
- コンポーネント統合： 異なるソフトウェアモジュール間の相互作用をマッピングしている。誰が誰を呼び、どのようなデータが渡されるか？
- アルゴリズム論理： 核心的な複雑性は実行時間ではなく、決定木にある。論理が
if (x > 5) then do_yであれば、シーケンス図はこの流れを明確に捉えることができる。 - 非同期イベント： 実時間システムはしばしば割り込みに依存する。メインループが実行中の間に割り込みが発生する様子を示すのに、シーケンス図は非常に優れている。ただし、結合フラグメントを使用する必要がある。
例のシナリオ： 自動ブレーキシステムがセンサー入力を受信する。シーケンス図では、センサーがデータをコントローラーに送信し、コントローラーが入力を処理した後、ブレーキアクチュエーターにコマンドを送信する様子を示す。これは論理的な依存関係をマッピングする。
🕒 実時間論理の際にタイミング図を使うべきタイミング
時間そのものが論理の変数となる場合、タイミング図は必須となる。以下の状況では、この表記に切り替えるべきである：
- ハードデッドラインが存在する： タスクが10ms以内に完了しなければシステムが失敗する場合、タイミング図はその時間枠を可視化する。明示的にデッドラインを示す垂直線を描くことができる。
- 信号の安定性が重要である： エンベデッドシステムでは、信号が認識されるために特定の期間、HIGHの状態を維持する必要があることが多い。タイミング図はパルス幅の要件を示す。
- ジッター解析： システムが変動する遅延（ジッター）を処理しなければならない場合、タイミング図はメッセージの到着時間の可能性の範囲を示すことができる。
- リソース競合： 2つのプロセスがCPUコアを競合する場合、タイミング図はスケジューリングのギャップと、一方のタスクが他方をブロックする様子を示すことができる。
- 状態機械の遷移 デバイスが「ウォームアップ」状態で5秒間待機しなければならない場合、その期間が重要な制約となる。タイムイング図はこれを明確に示す。
例のシナリオ： 温度センサーは100msごとにデータを送信する。コントローラーは次の読み取りが到着する前に、このデータを処理しなければならない。タイムイング図は、読み取り間隔と処理時間の間に重なりがあるか（ないか）を示す。
🔍 深掘り：並行処理と同期の扱い方
リアルタイムの論理はほとんど線形ではない。並行処理が一般的である。両方の図形式はこれを異なる方法で扱い、その違いを理解することはアーキテクチャにとって不可欠である。
シーケンス図における並行処理
シーケンス図は並行なライフラインを使って並行処理を示す。2つのオブジェクトが同時にアクティブな場合、そのアクティベーションバーは横並びに描かれる。しかし、これは時間的に同時に実行されることを保証するものではない。論理的なインタリーブのみを保証する。
- 制限点： プロセスAがプロセスBの開始前に終了しなければならないことを、異なるスレッド上にある場合に簡単に示すことはできない。
- ベストプラクティス： 使用する：
par並行実行ブロックを示すために「par」フラグメントを使用する。これにより、システムが複数のスレッドやプロセスが並行して実行されることを想定していることが明確になる。
タイムイング図における並行処理
タイムイング図は並行処理を空間的に扱う。時間は水平方向に流れることから、複数のライフラインを重ねて、正確にどの部分で時間的に重複しているかを確認できる。
- 利点： 「ビジーワイト」ループが実際に他のタスクをブロックしているかを確認できる。タスクの開始と別のタスクの終了の間のギャップを視覚化できる。
- 制限点： 複数の並行スレッドがあると、すぐに見づらくなってしまう。信号の数が増えるほど視覚的なノイズが増える。
🧩 両方の図の統合
信頼性の高いエンジニアリングでは、片方を選んでもう片方を捨てることはほとんどない。最も効果的なドキュメンテーション戦略は両方を統合することである。これらは設計ライフサイクルにおいて補完的な役割を果たす。
- 高レベル設計： まずシーケンス図 アーキテクチャ、メッセージの流れ、コンポーネントの境界を定義するために使用する。これにより論理的な契約が設定される。
- 低レベル仕様： 重要なパスをタイムイング図 によって精査する。論理が定義されたら、重要な部分に時間的制約を適用する。これによりパフォーマンス契約が定義される。
- 検証： テスト中に、レイテンシを検証するためにタイミング図を使用してください。正しいメッセージが正しい順序で交換されたことを検証するために、シーケンス図を使用してください。
⚠️ 避けるべき一般的な落とし穴
経験豊富なアーキテクトでさえ、リアルタイムシステムをモデル化する際に誤りを犯すことがあります。これらの一般的な誤りに注意を払いましょう。
- シーケンスが期間を意味すると仮定する: シーケンス図を見て、メッセージ間の垂直距離が時間を表していると仮定してしまうという一般的な誤りがあります。実際にはそうではありません。これにより、誤ったレイテンシの仮定が生じます。
- アイドル状態を無視する: タイミング図では、「アイドル」または「スリープ」状態を表現しないと、電力消費の問題が隠れてしまいます。ステートバーがライフサイクル全体をカバーしていることを確認してください。
- 結合フラグメントの過剰使用: シーケンス図では、あまりにも多くの
altまたはoptブロックをネストしすぎると、図が読めなくなってしまいます。複雑な論理をサブ図に分割してください。 - 論理的時間と物理的時間の混同: 明らかにラベル付けしない限り、論理的な順序（シーケンス）と物理的な時間制約（タイミング）を同じ図に混在させてはいけません。混乱を避けるために、これらを明確に区別してください。
- 信号ノイズを無視する: 物理的なハードウェア向けのタイミング図では、信号の遷移が完全であると仮定してはいけません。論理に影響する場合は、ノイズマージンやデバウンス時間を明記してください。
📝 ドキュメント作成のためのベストプラクティス
図がごちゃごちゃになるのではなく、価値を生むようにするため、以下のガイドラインに従ってください。
- 一貫した命名: ライフラインと信号に対して一貫した命名規則を使用してください。ある図で信号を「ReadSensor」と呼ぶなら、別の図では「GetData」とは呼んではいけません。
- 重要なパスに注目する: すべての関数を図示しようとしないでください。タイミング制約や重大な障害が発生するパスに注目してください。ハッピーパスは簡潔に記録する一方、エッジケースは詳細に記録してください。
- 注釈を使用する: 両方の図形式で注釈がサポートされています。単位（ms、µs）、許容誤差、特定の要件を定義するためにそれらを使用してください。単位のない数値はリアルタイム設計において意味がありません。
- バージョン管理: 図をコードのように扱いましょう。バージョン管理に保存してください。タイミング制約の変更は、コードの変更と同様にレビューする必要があります。
- ステークホルダーとレビューする: シーケンス図は開発者（論理）とレビューしてください。タイミング図はシステムエンジニア（性能）とレビューしてください。対象となる聴衆が図の種類と一致していることを確認してください。
🚀 レベルの高い考慮事項：ステートマシン
リアルタイムシステムはしばしばイベント駆動型である。これにより、状態機械とUML図の交差点に到達する。
- シーケンス図 + 状態機械：外部メッセージによって状態機械の遷移がどのように引き起こされるかを示すために、シーケンス図を使用する。メッセージがライフラインに入り、内部状態の変化が発生する様子を示す。
- タイミング図 + 状態機械：タイミング図を使用して、状態の持続時間を示す。たとえば、「タイムアウト」状態は正確に3秒間続くことがある。タイミング図は、他のイベントとの関係においてこの持続時間を可視化する。
複雑な組み込み論理をモデル化する際、状態機械図とタイミング図を組み合わせることは、時間の経過に伴う振る舞いを最も正確に表現する場合が多い。
📊 決定要因の要約
意思決定プロセスを支援するために、このチェックリストを検討してください。
- 主な関心事は操作の順序ですか？ ➝ シーケンス図を使用する。
- 主な関心事は操作の持続時間ですか？ ➝ タイミング図を使用する。
- ソフトウェアインターフェースを定義していますか？ ➝ シーケンス図を使用する。
- ハードウェア信号の要件を定義していますか？ ➝ タイミング図を使用する。
- 論理が締切に依存していますか？ ➝ タイミング図を使用する。
- 論理がメッセージプロトコルに依存していますか？ ➝ シーケンス図を使用する。
🔚 最後の考え
UMLタイミング図とシーケンス図のどちらを選ぶかは好みの問題ではなく、システムの制約に忠実であるかどうかにかかっている。シーケンス図は相互作用の論理を表現する。タイミング図は実行の物理的側面を表現する。
リアルタイム論理の領域では、曖昧さは敵である。適切なツールを選択することで、曖昧さを軽減できる。システムが何をすべきか、そしていつその動作をしなければならないかを明確に区別できる明確な設計図をチームに提供する。この明確さは、堅牢で信頼性が高く安全なシステムへと直接つながる。
流れから始めよ。タイミングを検証せよ。両方を文書化せよ。この二重アプローチにより、リアルタイム論理が機能的に正しいだけでなく、時間的にも妥当であることを保証できる。