「パッシブステートマシン」と呼ぶ論理構造の正しい用語を探しています。
この組み込みデバイスを想像してみてください。下位のプログラム レイヤーがチップ カード リーダーを処理し、「カード イン」、「カード アウト」、「カード エラー」の 3 つの状態を判断することでユーザー入力に反応します。ここでは、適切な低レベルのアクションが実行されます。これをステートマシンと呼びます。
下位層は、変更に反応し、システムの残りの部分と通信する上位プログラム層に状態を報告します。つまり、メッセージを送信したり、LED を切り替えたりします。
この上位層のプログラム ロジックは、単純化されたステート マシンのようにモデル化 (UML 2) することもできます。これには、状態間の遷移と、最も重要なエントリ アクションとエグジット アクションがあります。状態は基本的に下位層と同じですが、必須ではありません (たとえば、「Card OK」、「Card not OK」に縮小される場合があります)。
大きな違いは、この「上位層のステート マシン」が決定を行わないことです。下位レベルから取得した状態に反応してアクションを提供するだけです。状態/遷移/アクション モデルは、適切に配置された方法でロジックを読者に視覚化する (そしてもちろん、コンパイラに何をすべきかを伝える) ための優れた方法です。
または、別の言い方をすれば、「実際の」状態機械では、私が理解しているように、状態のロジックが次に遷移する状態を決定します。「パッシブ」バリアントでは、何らかの外部エンティティが決定を行い、それに応じて状態が続きます。結果:状態間のすべての遷移は上位レベルで可能でなければなりません。
しかし、これは実際には「有限状態マシン」ですか (ここで何かがアクティブになっていると想像します)。それとも、このモデルの受動的な性質を強調するより良い用語はありますか?
編集：返信ありがとうございます！明確にするための2つの図。もちろん、どちらもステートマシンです。ただし、いくつかの質的な違いが見られます。「下位レベル」の SM がハードウェア (バルブ、センサー) に直接接触し、それが反映するシステムを認識していると想像してください。たとえば、状態「通常」のみが「テスト ボタン」に反応し、他の状態は反応しません。すべての移行が可能なわけではありません。「上位レベル」は「ダム」と見なされ、下位レベルから取得した入力のみを視覚化/報告する必要があります。したがって、すべての遷移が可能でなければなりません。状態切り替えロジックはすべての状態で同じであり、冗長性を避けるために (プログラマとして考えて) 状態の外で実装されます。決定するのではなく、出入りのアクションを実行するだけです。
下位レベル:
より高いレベル:
