状態遷移設計を​活用して​起こりうる​状況を​漏れなく​抑える

開発にて設計を進める中で、状態遷移設計はされているでしょうか？
マルチスレッド環境ではシーケンス図が中心となり、状態遷移設計が明示的に残されないケースもあるかもしれません。

状態遷移表は、抜け漏れなく起こりうる状況を整理するために役立ちます。

状態遷移表の​基本的な​書き方

状態遷移表では以下のように、状態とイベントを行列に表現し、セルにはその状態で受けたイベントに対して、何をするのか（アクション）と次状態を表現します。
（行と列は逆に表現されることもあります）

例として、ログイン画面でログイン情報を入力し、ログインボタンを押下することでホーム画面に遷移するというシンプルなケースを考えます。
ログイン処理は認証のために通信が発生し、少し時間がかかると仮定します。
ホーム画面にはログアウトボタンがあり、こちらは押すとすぐにログイン画面に戻るとします。
ログインエラー表示はログイン画面にメッセージを表示するものとします（メッセージボックスは使用しない）。
行に状態、列にイベントを表現し、セルには「アクション/次状態」のフォーマットで記載します。

イベントの​洗い​出しは​重要

重要なのは、イベントの洗い出しです。
ボタン押下や通信による結果の受信以外にも、タイムアウトというケースもありえます。
外部とのやり取りが発生する場合は、エラーケースや異常系も考慮してイベントを洗い出す必要があります。これらが漏れると、必要な状態を漏らしてしまう可能性もあります。
基本的な流れに対して、セルを埋めていくと上の表のような状態になると思います。

入力されていない​セルに​ついて​考える

埋まっていないセルに対して、起こるケースがあり得るとしたらどういう処理が必要か？あるいは絶対に起こりえないのかをチェックします。
ここが、起こりうる状態を漏れなく把握するために大切です。

例えば、状態「ログイン画面」で「ログイン成功通知受信」イベントは絶対に受けないか？を考えます。
「ログイン成功通知受信」イベントを受けるのは "ログイン要求送信" 後です。
考えてみると、もし、「ログイン処理待ち」状態で、「ログイン要求タイムアウト」イベントにより、「ログイン画面」に戻っていた場合、遅れて「ログイン成功通知受信」「ログイン失敗通知受信」イベントが発生する可能性があります。
（20秒でタイムアウトしたけど、25秒経ってから通知が来たような場合ですね）

このように、セル単位でチェックをして起こりうる可能性を一つずつ確認することで、見落とす可能性のあるケースに気づくことができます。

まとめ

状態遷移表を活用して、状態とイベントの組み合わせを網羅的にチェックすることで、見落としがちなケースに気づくことができれば、不具合を設計時点で防止できます。
「この状態でこのイベントが来るとは想定していなかった！」という不具合を事前に防ぐことができます。

また、状態遷移表をもとにテストを実施することで、網羅的なテストも可能になります。
品質の向上に向けて、状態遷移表を活用してみてはいかがでしょうか。