状態遷移表を作る
つくる！
- イベントリスト作成
- 状態遷移図作成
- 状態遷移表作成
の順でつくります
イベントリスト作成
仕様書から、イベントとアクションを見つける。
- イベント：なんらかの処理とか日付とか。業務を行う上で起きるいろいろなこと
- アクション：イベントによって起こること
というざっくりした理解。イベントの表現が難しい
漠然と、契約管理のシステムを例にして考える
| イベント | アクション |
|---|---|
| 申込 | 契約を作る。契約が申込中状態になる |
| 契約予約処理 | 契約が契約予約状態になる。月額商品を翌月1日開始で作成する |
| 月初 | 契約が契約中状態になる。月額課金の開始 |
状態遷移図作成
状態を取り出す
- 申込中
- 契約予約
- 契約中
状態から状態に行く矢印をひいて、アクションを書く
- [なし] -申込-> [申込中]
- [申込中] -契約予約処理-> [契約予約]
- [契約予約] -翌月1日-> [契約中]
ここまでだと矢印が一方通行なので、たとえばキャンセルとかはあるのか？とか考える
- [申込中] -キャンセル-> [？]
ありそう
なしに戻るのか、キャンセル済という新しい状態があるのか迷う。とりあえず新しく作ってみる。
アクションがキャンセルとなしで同じなら、一緒にしてもいいかも。
- [申込中] -キャンセル-> [キャンセル済]
全部つなげて書いてみる
graph LR;
a>開始] --> none(なし);
none(なし) -->|申込| ordered(申込中);
ordered(申込中) -->|契約開始処理| reserved(契約予約)
reserved(契約予約) -->|翌月1日| engaged(契約中)
ordered(申込中)-->|キャンセル| canceled(キャンセル済)
状態遷移表作成
| イベント/契約の状態 | なし(s0) | 申込中(s1) | 契約予約(s2) | 契約中(s3) | キャンセル済(s4) |
|---|---|---|---|---|---|
| 申込 | 契約を作成/s1 | ||||
| 契約予約処理 | 月額課金商品を翌月1日開始で作成/s2 | ||||
| 翌月1日 | s3 | ||||
| キャンセル | s4 |
契約予約→契約中の遷移、月額課金は自動で始まるのでアクションではないかな…と思ったので、状態が変わることだけ書いた。
埋まってないところを考えて、全部埋める。
イベントが起こりえない場合はx
イベント起きるけど、なにもしない場合は/
を書く
| イベント/契約の状態 | なし(s0) | 申込中(s1) | 契約予約(s2) | 契約中(s3) | キャンセル済(s4) |
|---|---|---|---|---|---|
| 申込 | 契約を作成/s1 | x | x | x | x |
| 契約予約処理 | 月額課金商品を翌月1日開始で作成・s2 | ||||
| 翌月1日 | / | / | s3 | / | / |
| キャンセル | s4 | 月額課金商品を削除・s4 |
翌月1日はどの状態でも起こり得るのでなにも起きない場合は/を書く。
申込は契約を新しく作るので、契約なし以外の状態では起こりえないはず。
契約予約キャンセルがありそう。ある想定で書いてみる。
このあたり、書いてなかったらサービス仕様書に反映してもらおう
graph LR;
a>開始] --> none(なし);
none -->|申込| ordered(申込中);
ordered -->|契約開始処理| reserved(契約予約)
reserved -->|翌月1日| engaged(契約中)
ordered -->|キャンセル| canceled(キャンセル済)
reserved -->|キャンセル| canceled
図もこんなかんじに修正
| イベント/契約の状態 | なし(s0) | 申込中(s1) | 契約予約(s2) | 契約中(s3) | キャンセル済(s4) |
|---|---|---|---|---|---|
| 申込 | 契約を作成/s1 | x | x | x | x |
| 契約予約処理 | x | 月額課金商品を翌月1日開始で作成・s2 | x | x | x |
| 翌月1日 | / | / | s3 | / | / |
| キャンセル | x | s4 | 月額課金商品を削除・s4 | x | x |
全部うめたー。
埋めると、このパターンどうだろうって考えるのでヌケモレがなくなる。はず。
所感
今まで見よう見まねで適当に書いてたので、型のお勉強でした。
結構すぐ状態遷移表書いてて、イベントリストや状態遷移図の段階を丁寧にやってなかったけど、やっぱ図のほうが読みやすいなーと思った。全部埋めるという意味では表を使うのが良いけど、見てわかるのは図が強い。
イベントが起こりえないのとなにもしないをあんまり区別してなかったのでちゃんと分けて書くようにする。
契約で話始めたけどこれ申込は別ドメインのほうが良くない？って途中で思ったけど書き直すのが面倒になったのでそのまま行った
参考
状態遷移表による設計手法（3）：状態遷移表を使用した要求分析モデル (1/3) - MONOist http://monoist.atmarkit.co.jp/mn/articles/1207/11/news001.html
