ステートマシンの設計と実装～設計のもったいお化けが出る

他の方がUMLを使って設計されたステートマシンをみると非常に感覚的描いているようだ。

　
　
ステートマシンの状態たイベントの設計には、「妥当性」や「正当性」や「有効（充足性）」という定義が明確にされており、これを意識しないで状態図を描いても得るものは何もない。
　　

「状態の入れ子」「並行状態(直交状態)」が存在するステートマシンのイベントや状態の「妥当性」や「正当性」や「有効（充足性）」という定義を知っているのいないのとでは『天と地』の差がある。
　
　

他の方が描いたステートマシンを見ると
ステートマシンの状態の「妥当性」
ステートマシンの状態の「正当性」
ステートマシンの状態の「有効（充足性）」
が無いか／あるかが瞬時で分かる。
　
　

同じく
ステートマシンのイベントの「妥当性」
ステートマシンのイベントの「正当性」
ステートマシンのイベントの「有効（充足性）」
が無いか／あるかが瞬時で分かる。
　
　

それから、並列・並行があるオブジェクト指向のクラスの状態図にもいても
同様で、ステートマシンのイベントや状態の「妥当性」や「正当性」や「有効（充足性）」であるが、こちらはもっと瞬時に異常なモデルは判定できる。
　
　　　

「妥当性」や「正当性」や「有効（充足性）」を知らない、意識しないで
設計してもこれではレビューやテストがかなり大変になってしまうから不利である。
　
設計の努力が活きないのでもったいない。

それから、状態図に登場するイベントは「ガード条件」はもちろん、イベントを送る先のオブジェクトの制約等をキチンと書こう。
　
　

pack(b:Bottle[b ∊ product])/[product' = product - {b}]
とか
pack(b:Bottle)/[b.maker.product' = b.maker.product - {b}]
である。

お絵かきモデルの状態図から卒業しないと生産性も品質も期待できない。