9

ちょっとした裏話として、マシン アプリケーションに最適なアーキテクチャについて質問しているこの質問を読むことができますが、この質問で私を助けるために完全に必要というわけではありません。

有限ステート マシンの (特に実装に関する) 私の理解は少し若く、少し欠けているかもしれませんが、私はこのアプリケーションを 1 つとして実装しており、ネストされた FSM が必要な場所があります。基本的に、マシンにはいくつかの高レベルの状態があります (コールド [別名]、ホーミング イン、セットアップ、実行準備完了、実行中、レポート、リセット中)。 (レンズのロード、エッジの位置の特定、くさびの測定、真円度の測定、および完了 [そこにさらにいくつかある場合があります])。

私の質問はこれです:状態がサブ状態のリストを持つことができ、システムがそれらのサブ状態に入り、それらのサブ状態が親状態に戻ることができる「ネストされた状態」を持つ機能を組み込む必要がありますか? それとも、FSM 実装を Running 状態の中に置き、それらを 2 つの別個の FSM として保持する必要がありますか? それとも、私が愚かなことをしている、または考えているので、考え直すべきだと思いますか?

考え、提案、批判、アドバイスはすべて大歓迎です。

4

4 に答える 4

10

ネストされたステート マシンは UML の標準的な概念であるため、これは必ずしも愚かなことではありません。詳細はこちら。

于 2009-08-24T20:00:01.980 に答える
4

逆に。FSM をネストできるのは良いことです。

ネストを行うためだけに FSM をネストするべきではありませんが、FSM が非常に大きくなることがあります。このような大規模な図面を使用すると、FSM モデルの目的が損なわれます。内部の作業がよく見えないからです。それは、多くの詳細への道を持つ巨大な図になります。

クラスと比較できると思います。すべてを 1 つのクラスに固執すると (さらに悪いことに、すべてを静的にすると)、クラスを持つ目的と利点が失われます。

FSM についても同様です。

例を挙げると、私のカレッジローは、FSM を使用して犬の行動を非常に「現実的」にモデル化しています。彼は巨大なモデルを持っており、FSM を入れ子にすることで、私はほんの数分でモデルを理解することができました。

したがって、適切に使用すれば、それは間違いなく良いことです。

于 2009-08-24T20:13:46.133 に答える
3

ネストされた状態 (UML FSM 内) は、実行中の状態内に個別の FSM を「配置」することと同じではないことを付け加えたいだけです。

実際の階層 FSM では、イベントは最初に現在のネストされた状態にポストされます。その状態がそれらを処理しない場合、それらは親状態にポストされます。これにより、ネストされた状態から親状態への一般的な状態遷移を「リファクタリング」できます。

于 2011-01-20T11:38:22.003 に答える