有限状态机是否应该具有“嵌套”有限状态机？

Question

你可以阅读this question我在哪里询问一个机器应用程序的最佳架构，但是对于帮助我解决这个问题并不是完全必要的。

我对有限状态机的理解（特别是实现）有点年轻，可能缺乏一点，但我将这个应用程序作为一个实现，我有一个地方需要有一个嵌套FSM。基本上这台机器有一些高级状态（冷[又刚启动]，归位，设置，准备运行，运行，报告，重新设置）但是当机器运行时，它需要有自己的小FSM实现（加载Lense，定位边缘，测量楔形，测量圆度和完整[可能在那里更多]）。

我的问题是：我是否应该建立具有“嵌套状态”的能力，其中状态可以有一个子状态列表，系统可以进入这些子状态，那些子状态可以返回到父状态？或者我应该将FSM实现放在Running状态中，并将它们保存为两个不同的FSM？或者你认为我在做什么或者在想一些愚蠢的东西并且应该重新思考它？

欢迎提出想法，建议，批评和建议。

Answer 1

嵌套状态机是UML中的标准概念，所以这不一定是愚蠢的。 More details here

Answer 2

相反。有可能嵌套FSM是一件好事。

不应仅仅为了嵌套而嵌套FSM，但有时FSM会变得非常大。拥有如此大的绘图会破坏FSM模型的目的，因为它不能让您对内部工作有一个很好的了解。它只是一个巨大的图表，可以提供许多细节。

我认为你可以将它与班级进行比较。如果你把所有东西都放在一个类中（更糟糕的是，让一切都变得静止），拥有一个类的目的和优势就会消失。

FSM也一样。

举个例子，我的一个学院的模型非常“逼真”使用FSM的狗的行为。他有一个巨大的模型，通过嵌套的FSM，我能够在几分钟内理解模型。

如果使用得当，这绝对是件好事。

Answer 3

我只想补充说，嵌套状态（在UML FSM中）与将“单独的FSM”放入运行状态不同。

在实际分层FSM中，事件首先发布到当前嵌套状态。如果该状态不处理它们，它们将被发布到父状态，依此类推。这允许人们“重构”从嵌套状态到父状态的公共状态转换。

Answer 4

我通过使用表示状态状态的枚举来解决这个问题。例如 Bunny有一个生育状态。

ProcreationState有一个枚举

   enum State
{
    SettinNewSearchPosition,
    SearchingForFriend, 
    MovingTowardsFriend,
    EstablishingFriendship,
    Mating
}

在状态更新方法中，我只是检查它的状态并正确行动。 我想这限制了这个系统的整体能力。我不是那么有经验所以我试试这个。关于这种方法的任何反馈都是相关的。