はじめに
UMLは覚えておくべき(概念編)
と
UMLは覚えておくべき(ユースケース記述編)
と
UMLは覚えておくべき(クラス図編)
の続編です。
UML関連の記事はこれでおしまい。
UTPっていうUML Test Profileとかいう面白そうなものもありますが、少なくとも今すぐ書こうとは思っていません。
最後はステートマシン図を紹介します。
こちらも、覚えると強力なので、ぜひ覚えてください。
ステートマシン図とは
オブジェクトの状態遷移を記載するものです。
各状態の内容および、状態遷移の条件等を記述します。
カートとユーザの購入履歴のstateMachine図
前回の記事 のカートとユーザの購入履歴でステートマシン図を書くならこんな感じでしょうか。
オブジェクト自体がそこまで複雑ではないので、これは書かなくてもわかりやすいかもしれません。
入力フォームのStateMachine図
メールアドレスを入力するフォームで考えてみましょう。
仕様： 入力し終わったときにメールアドレスの形式以外であれば、エラーメッセージを出すようにする。 逆に、エラーメッセージが出ている間に、入力し終わったときにメールアドレスの形式であれば以上メッセージを削除する。
入力し終わったときなので、入力フォームからフォーカスが離れた瞬間に形式チェックすれば良さそうです。
なので、blurでチェックしたほうが良さそうです。
また、初期表示状態でいきなりエラーメッセージがでているのもよろしくないので、入力開始した後に表示するようにしましょう。
※ blurとは、入力フォームからフォーカスが離れた瞬間のイベントを指します。
現時点では、正常から正常、異常から異常に復帰するときのイベントが無いので、それを追加します。
しかし、仕様の変更が発生しました。
仕様： 入力完了時ではなく、形式エラーが無くなった瞬間にエラーメッセージを削除してほしい。
そうなると、blurのイベントでは仕様を満たすことができません。
形式エラーが無くなった瞬間となると、keyupが適切そうです。
※ keyupとは、キーボードを押した後、指が離れた瞬間を指します。
これで仕様を満たせそうです。
とはなりません。
このままでは、1文字入力した瞬間にエラーメッセージが出力されてしまいます。
その仕様では業務の人は受け入れてくれませんでした。
となると、エラーメッセージが出力されている時だけ、keyupイベントで取得すれば良さそうです。
さて、これで仕様は満たせました。
ただ、最後の仕様追加によって、エラーメッセージの表示状態によって分岐が発生しているので、入力フォームの状態とエラーメッセージの表示状況の二つの状態が存在することを意識する必要があります。
なので、それも含めるとこのような図になります。
おそらく、これで完璧でしょう！
この辺の認識齟齬は良く起きやすいので、混乱したときはStateMachine図で整理するとすっきりします。
私の仕様では、blur時にチェック、という形にしましたが、post前にチェック、またはフロントでは完全にスルー等でも良いですしね。
終わりに
ステートマシン図があると、オブジェクトの遷移がわかりやすくなります。
分かりやすくなった結果、異常に気づきやすくなります。
業務がシンプルではなく、複雑な状態をもつというのは普通なので、一度整理してみてはいかがでしょうか。
少なくとも、業務を通してStateMachine図が無い状態というのは、仕様変更に弱くなってしまうので、作っておくべき資料だと思います。
