複雑なシステムを設計するには、それらが何をするかを知るだけでは不十分である。理解することが必要となる。いつそれを行うタイミングである。ここがステート図がエンジニアやアーキテクトにとって不可欠なツールとなる場所である。ステート図はしばしばステートマシン図と呼ばれるが、システムの動的動作を視覚的に表現する。システムが動作する条件と、特定のイベントに対してどのように反応するかを明示する。
シンプルな自動販売機から分散型クラウドインフラストラクチャまで、モデル化する対象が何であれ、明確さが最も重要である。このガイドでは業界で用いられる標準的な表記法を検討し、特にUML（統合モデル化言語）とMSC（メッセージシーケンスチャート）に焦点を当てる。記号、構文、ベストプラクティスを分解し、意図を曖昧なく伝える図を構築するのに役立つ。
🧩 ステートマシン図とは何か？
ステートマシン図は、オブジェクトまたはシステムコンポーネントのライフサイクルをモデル化する。根本的な問いに答える。
- システムが取りうる明確な状態（ステート）とは何か？
- 一つの状態から別の状態への変化を引き起こす要因（遷移）とは何か？
- 変化が発生したときに何が起こるか（アクション）？
- 開始点は何か、終了を示すのは何か？
フローチャートとは異なり、フローチャートはプロセスを通じたデータまたは制御の流れに注目するが、ステート図はエンティティのステートに注目する。この違いは、記憶機能や永続的な状態を持つシステム、たとえば認証システム、信号制御装置、ネットワークプロトコルなどにおいて極めて重要である。
🔍 UMLステートマシン表記法：標準
統合モデル化言語（UML）は、ソフトウェアシステムをモデル化するための最も広く採用されている標準である。UML 2.xでは、より複雑なシナリオに対応できるようにステートマシン図が洗練された。UML表記の核心的な要素を理解することは、習得への第一歩である。
1. コア要素
すべてのステート図は、いくつかの基盤となる要素に依存している。これらは繰り返し使用する構成要素である。
- ステート：角が丸い長方形で表される。オブジェクトが何らかの不変条件を満たす、ある活動を実行する、またはイベントを待機している状態を示す。
- 遷移：2つのステートを結ぶ有向線。システムがイベントに応じて一つのステートから別のステートに移動することを示す。
- イベント：遷移を開始するトリガー。信号、時間イベント、または呼び出しのいずれかである。
- ガード条件：四角括弧で囲まれた論理式。この条件が真である場合にのみ、遷移が発生する。
[ ]。この条件が真である場合にのみ、遷移が発生する。 - アクション：遷移中に実行される活動、またはステートにいる間に実行される活動。しばしばスラッシュの後に記述される。
/.
2. エントリおよびエグジットポイント
状態は静的ではない。それぞれにライフサイクルがある。状態に入ると、特定のアクションが発生する。状態を離れるときには、他のアクションが発生する。UML表記は、このライフサイクルを明確に捉えている。
- エントリアクション（entry /）：状態に入ると直ちに実行される。
- ドゥアクティビティ（do /）：状態がアクティブな間、継続的に実行される。モーターの回転やタイマーの進行といった継続的なプロセスに有用である。
- エグジットアクション（exit /）：状態を離れる直前に実行される。
たとえば、オンラインショッピングカートシナリオにおいて、処理状態に入ると、entry / validate_stock()アクションが発生する。この状態にいる間、システムはdo / update_inventory()ループを実行するかもしれない。状態を離れる際には、exit / send_confirmation().
3. 初期状態と最終状態
すべての図には明確な開始点と終了点が必要である。これらは、通常の状態と区別するために特定の形状で表される。
- 初期状態：塗りつぶされた黒い円。システムの開始点である。図ごとに初期状態は1つだけである。
- 最終状態：黒い円が輪郭線で囲まれたもの（ブルーザイ）である。システムのライフサイクルの終了を示す。状態機械は複数の最終状態を持つことができる。
📡 MSC：メッセージシーケンスチャート
UMLは単一のオブジェクトやコンポーネントの状態に注目するのに対し、MSC（メッセージシーケンスチャート）は時間の経過とともに複数のオブジェクト間の相互作用に注目する。これらはしばしば状態図と併用され、全体像を明確に示すために用いられる。
MSC表記は特に次のような場面で有用である：
- コンポーネント間で交換されるメッセージの順序を可視化する。
- タイミング制約および遅延を特定する。
- 並列プロセスを示す。
MSCでは、垂直線がインスタンス（オブジェクト）を表し、水平の矢印がメッセージを表す。垂直軸は時間の進行を下向きに表す。これは状態図を補完し、誰が状態変化を引き起こしたイベントを送信した。
🛠 記法比較表
違いを明確にするために、標準的なモデル化記法における一般的な記号とその意味の分解を以下に示す。
| 記号の形状 | 名称 | UMLの意味 | 一般的な使用法 |
|---|---|---|---|
| ●（塗りつぶされた円） | 初期点 | 状態機械の開始 | 常に最初のノード |
| ◎（ブルーザイ） | 終了点 | 状態機械の終了 | プロセスの終了 |
| ⬜（ラウンドされた長方形） | 状態 | オブジェクトの現在の状態 | 状態を記述する（例：開いている、閉じている） |
| ➡️（矢印） | 遷移 | 一つの状態から別の状態への変化 | 状態を接続する |
| ◀（ダイアモンド） | 決定ノード | 条件に基づく分岐 | ガード条件の評価 |
| ⬤（小さな塗りつぶされた円） | 履歴状態 | 以前の状態への再入 | 途中で中断した場所に戻る |
| 🔗（リンク） | 結合 | 並行なフローのマージ | 並行な状態の結合 |
🚀 高度なUML概念
基本を理解したら、高度なUML機能を使ってより複雑な振る舞いをモデル化できます。これらの概念により、階層構造と並行性を実現でき、現実世界のシステムには不可欠です。
1. ネストされた状態（サブステート）
複雑な状態はしばしばサブステートを含みます。たとえば、Vehicle状態には、EngineOn, EngineOff、およびIgnitionKeyInといったサブステートを含むことがあります。これを状態の階層構造と呼びます。親状態がアクティブなとき、子状態もアクティブになります。これにより図の混雑を減らし、関係を明確に示せます。
2. 直交領域（並行性）
1つのオブジェクトが、その状態が直交している場合、同時に複数の状態に存在できます。これは、実線で状態ボックスを別々の領域に分割することで表現されます。たとえば、SmartphoneはCharging状態にある一方で、同時にScreenOn状態にあります。これらの領域は並行して動作します。
3. 偽状態
偽状態は真の状態ではなく、フローを管理するための制御ポイントです。特定の記号で描かれることが多く、システムが一時的に留まる状態を表すものではありません。
- ディープヒストリー： 最後にアクティブだったサブ状態に戻って再入する。
- シャロウヒストリー： 初期のサブ状態に戻って再入する。
- フォーク： 1つの遷移を複数の並行遷移に分割する。
- ジョイン： 複数の並行遷移が完了するのを待ってから進行する。
📝 初心者向けのベストプラクティス
図を描くことは一つのことで；良い 図を描くことは別の話です。読みやすく、保守しやすいようにするため、以下のガイドラインに従ってください。
- 状態を原子的に保つ： 状態は単一の整合性のある条件を表すべきです。状態名の中に複雑な論理を含めないようにしましょう。
- 一貫した命名を用いる： 状態（例：常に大文字）と遷移（例：動詞ベース）の命名にはルールを設けましょう。
- 遷移の複雑さを制限する： 遷移に guarding 条件が多すぎる場合は、複数の遷移や状態に分割することを検討しましょう。
- クロスリファレンスを避ける： 遷移を現在の状態に限定するようにしましょう。遠く離れた状態への長距離ジャンプは読者を混乱させる可能性があります。
- イベントを明確にラベルする： イベント名が説明的であることを確認してください。例えば
e1ではなく、user_login_attempt. - アクションを文書化する： 線を引くだけではなく、線にアクションを記録しましょう。どのようなデータが渡されるのか？何が更新されるのか？
⚠️ 避けたい一般的なミス
経験豊富なモデラーでさえミスを犯すことがあります。一般的な落とし穴に注意することで、レビュー中に時間を節約できます。
- デッドロック：すべての状態が終了または別の状態への有効なパスを持っていることを確認してください。出力遷移（最終状態を除く）がない状態は、潜在的なデッドロックを示しています。
- 到達不可能な状態：すべての状態が初期状態から到達可能であることを確認してください。状態が孤立している場合、設計にバグがあることを示唆しています。
- エラー処理の欠如：実際のシステムは障害に直面します。図にエラーイベントとエラー状態または回復状態への遷移を含めるようにしてください。
- 過剰設計：すべての可能なエッジケースをすぐにモデル化しないでください。ハッピーパスから始め、段階的に複雑さを追加してください。
🔗 UMLを超えて：ハレルのステートチャート
UMLが標準になる前、デイビッド・ハレルがステートチャートを導入しました。UMLステートマシンの多くの機能は、ハレルの研究から直接派生しています。レガシードキュメントに遭遇した場合、次のような記述が見られることがあります：
- AND状態：UMLの直交領域と似ています。
- 排他的OR状態：そのうちの一つだけがアクティブになる状態のグループです。
これらの起源を理解しておくと、古い技術仕様を読むときや、UML 2.x以前に存在する特定のドメイン固有のモデリング言語を使用する際に役立ちます。
🛡️ セキュリティとステートモデリング
ステート図はセキュリティ分析においても重要です。認証システムの状態を可視化することで、次のような点を特定できます：
- 機密データにアクセス可能な状態。
- 特権昇格を許す可能性のある遷移。
- 適切な検証ガードが欠如している状態。
たとえば、決済ゲートウェイでは、保留中状態が直接完了イベントなしで成功状態に遷移できないことはセキュリティ要件です。このフローを可視化することで、監査が容易になります。
📌 主なポイントのまとめ
- 状態図は、時間の経過に伴うシステムの動的動作をモデル化する。
- UMLは、状態、遷移、イベントの標準的な表記法を提供する。
- MSCは、相互作用のシーケンスを示すことによって、状態図を補完する。
- 擬似状態とネストされた状態により、複雑で階層的なモデル化が可能になる。
- 明確な命名と論理的な流れは、複雑なグラフィックよりも重要である。
- 実装の前に、デッドロックや到達不能な状態について常に検証する。
これらの表記法を習得するには練習が必要である。簡単なシステムから始め、ルールを適用し、段階的に複雑さを増していく。目標は完璧な図を描くことではなく、曖昧さを減らし、チーム内のコミュニケーションを向上させる図を描くことである。
思い出してください。図の価値は、他人が読みやすく理解できるかどうかにある。簡潔に保ち、一貫性を持たせ、定義しようとしている動作に焦点を当てるようにしよう。これらのツールを手元に備えていれば、システムモデリングの課題に適切に対処できる。