3

これには、大学で行った可能性のある有限状態マシンは含まれません。

誰がなぜそれを作成しなければならなかったのか知りたいのですが?

マシンを作成する上で最も困難だったのはどのような点ですか?

4

5 に答える 5

8

はい、たくさんあります。基本的に、パフォーマンス上の理由から、字句解析プログラムを手動で実装する必要がありました。他の個人的な用途は、FSAがユーザーとの対話の流れを制御するGUI設計でした。

そのようなマシンを作成することはまったく難しいことではありません。それらを変更するのは、FSAの構造の少なくとも一部がコードに厳密に埋め込まれているためです。状態パターンは、これらの遷移の一部を容易にするのに役立ちますが、すべてではありません。

于 2009-02-04T16:58:49.960 に答える
5

何度も！

通信システムで使用されるほとんどのプロトコル スタックは、ステート マシンとして実装されます。CSTA コール モデルは、1 つの良い例です。

また、ほとんどの組み込みシステムは本質的にステート マシンです。

基本的に、現実世界のイベントに反応する必要があるシステムはすべて、ステート マシンとして実装するのに適しています。

ステート マシンで最も難しいのは、最新のドキュメントがない場合にステート マシンが何をするかを理解することです。彼らは認識を超えてバグを修正する傾向があります。

于 2009-02-04T17:23:38.490 に答える
2

確かに、小型のタービン、ポンプ、およびモーターを制御するタービン ガバナーを設計および作成しました。DSPチップを搭載した組み込み機器です。停止、起動、実行中、過速度テストなどの状態があり、実行中の状態には他の制御の可能性をカバーするいくつかの状態があります。

私の場合、ステート マシンの管理で最も困難な部分は、特にステートがサブステートを持つことができる場合に、クリーンな遷移を設計することでした。これは、タービン ガバナの場合、速度出力 (アクチュエータ) を遷移間でスムーズに調整する必要があることを意味していました。その他の課題は、ユーザー インターフェイス (プッシュ ボタンと 7 セグメント LED ディスプレイ) と、それらがステート マシンとどのように相互作用するかに関連していました。そのため、マスター コントロール ステート マシン、関連するユーザー インターフェイス ステート マシン、および関連する通信ステート マシンが存在することになりました (タービンの実行中に特定の値を書き込むことは許可されませんでした)。

私は他のさまざまなプロジェクトでステート マシンを使用してきました。一部の組み込みソフトウェアや標準ソフトウェア、通信からユーザー インターフェイス ソフトウェアまでです。

于 2009-02-04T17:34:52.930 に答える
1

私も持っています。大きなものはメンテナンスの悪夢になるため、私は通常、小さな FSM (いくつかの状態) を作成しますが、FSM は、特定のタスクに対して非常にシンプルでエレガントなデザインである場合があります。

実際の例として、特定の種類のファイルを 1 回修復するための小さなユーティリティを作成しました。ユーザーとのインタラクション パスは 3 つまたは 4 つしかありませんでした。

  • 小さなメッセージを表示し、ファイルを選択します (キャンセルして最初からやり直すこともできます)。
  • ファイルを修復します（キャンセルしてエラーメッセージで終了する場合があります）、
  • 確認メッセージを表示します。

ステート マシンを作成することで、これらのパスが明確になり、実装が容易になりました。

于 2009-02-04T17:44:38.887 に答える
1

上記のように、FSA の目的は、ステップからステップへと進み、すべての処理 (および状態の変更) を 1 つのループで処理することです。そして、プロセスの中で何かが変化した場合、次の論理的なステップに進むのは簡単です。

はい、それらは簡単に実行できます。私は 25 年以上にわたって頻繁に使用してきました。

于 2009-02-04T17:16:17.540 に答える