はじめに
PlantUML では、ステート図を描くことができますが、状態遷移表を描くことができません。
その代用として、JSONデータの表示機能を使い、トリガーの一覧表を描くようにしました。
その一覧表は、Microsoft MakeCode for micro:bit 向けのpxt-mstate拡張機能で出力することができます。
出力例
Display JSON Data on State diagram
PlantUMLには、JSONデータを表形式で表示する機能があります。
描画例
@startuml
json TableName {
"key1": "value1",
"key1'": "**value1**\\n__value2__(\\\\n)",
"**key1''**": ["element1", "element2"],
"Key2": { "SubKey1": "line1\\nline2"
, "SubKey2": ["row1", "row2"]
, "SubKey3\\n(\\\\n)": ["row1\\nrow1-line2", "row2\\nrow2-line2"]
},
"Key3 stringlength": {"Sub1": "string length", "Sub2": "value"}
}
@enduml
最初の検討
まず、最初に状態の一覧表を検討しました。
パターンS1
状態、説明（description）、トリガー（trigger）と順に表示するようにしました。
トリガーは複数ありますので、<<CASEn>>と表示して区別できるようにしています。
パターンS2
同一トリガーを1行にグループ化しました。
パターンS3
descriptionやtriggerを見出しにしました。
パターンS4
トリガー内の状態遷移をグループ化し、<<CASEn>>表記を廃止しました。
JSON構造 - パターンS4
どのような表が必要か
ここまで、状態を基準（ルート）に、その一覧と説明、トリガーを表にしましたが、状態の一覧は、ブロックのソースコードやUMLのステート図でも容易に確認できます。また、説明の一覧についてもUMLのステート図の方が確認しやすく感じます。
そこで、トリガーを基準（ルート）とした一覧表を検討します。
パターンT1
トリガー、状態の順に表示しました。
パターンT2
トリガー内にすべての状態を列挙しました。
これにより、トリガーの影響を受けない状態が明確になりました。また、状態列の表示幅が揃い、見た目も良くなったと思います。
状態遷移表の代用として、この形式の表を採用しました。
JSON構造 - パターンT2
{
"**__start command__**": ["**default state**","状態S"],
"**(__completion__)**": [
{ "**state**": {"": ["**[guard] / effect**", "**state to**"]}
, "状態1": {"":["[ガード1] / エフェクト1","状態X"]}
, "状態2": { "": ["[ガード2] / エフェクト2","**[__X__]**"]
, "": ["[ガード3] / エフェクト3","状態Z"]}
, "状態99999": {"":["",""]}
}
],
"**トリガー1**": [
{ "**state**": {"": ["**[guard] / effect**", "**state to**"]}
, "状態1": {"":[" / エフェクト1","状態X"]}
, "状態2": {"":["",""]}
, "状態99999": { "": ["[ガード222222222222222222222]","状態Y"]
, "": ["[ガード3]","状態Z"]}
}
],
"**トリガー999999999**": [
{ "**state**": {"": ["**[guard] / effect**", "**state to**"]}
, "状態1": {"":["",""]}
, "状態2": {"":["",""]}
, "状態99999": { "": ["","**[__X__]**"]}
}
]
}
まとめ
状態遷移表の代用として、PlantUMLのJSONデータ表示機能を使い、トリガーの一覧表を検討しました。
検討の結果、パターンT2の形式を採用し、pxt-mstate拡張機能で、出力できるようにしました。
ステートマシンを設計する際、ステート図とトリガーの一覧表とを使って、状態とトリガーの双方の視点から、状態遷移に抜け漏れがないことを確認することができます。