控制有限状态机

Question

我试图通过在负责将软件部署到临时系统的应用程序中使用它们来提高我对FSM的理解。此应用程序的一个组件负责确保安装git存储库，更新并正确检出。我已将存储库的可能状态建模为有限状态机。我见过的大多数示例都假设将有一系列外部事件驱动FSM，但在这种情况下，只有一个最终目标：确保存储库已安装，最新和签出。我可以硬连接FSM，以便它发出必要的事件以确保它达到检出状态：如果缺少状态，安装;如果状态已过时，请更新;等等。但是，如果我希望系统更灵活，可以扩展到允许多个预定结果呢？我可以写一些控制发送到FSM的事件流的条件语句，但这感觉不对：它首先打败了使用FSM的对象。感觉好像需要多个FSM：一个封装了git存储库的行为，一个或多个描述了达到所需最终目标所需的路径。

此时，我想知道我对FSM的理解是否有缺陷。通过发布达到特定状态所需的事件来自己拥有FSM控件是否常见？那么让一个FSM控制另一个呢？这种类型的系统有名称吗？

更新

根据要求，这是我的状态图：

Answer 1

我不认为你的理解是有缺陷的，但FSM机制似乎没有根据。

“此应用程序的一个组件负责确保安装git存储库，更新并正确检出。我已将存储库的可能状态建模为有限状态机。”

你介意发布你的一个FSM吗？我的猜测是你没有得到非常有趣的东西，因为FSM很难表达你所描述的那种状态转换，例如：

0 -> git repos are installed -1> git repos are up-to-date -2> correctly checked out

你得到一个无趣的FSM，它只是通过一系列状态。如果您有依赖项，则交替（FSM的另一个构建块）没有多大意义。

我想一个简单的依赖序列就足以为你的系统建模：

git repos are correctly checked out <- git repos are up-to-date
git repos are up-to-date <- git repos are installed

意味着要正确检查git repos，必须拥有（取决于）git repos是最新的。如果您只使用依赖关系表示整个系统，拓扑排序就足以产生正确的排序。好的一点是，无论何时在topsort中，您都会找到一组没有依赖关系的节点（想想天真的算法），您可以按任意顺序检查它们中的任何一个......或者如果您愿意，可以并行检查。 FSM形式主义并不容易给你这个。

Answer 2

Event Driven FSM表示由于事件而发生转换。如果您要将其建模为FSM，则每个操作都应在完成时发出一个将反馈给FSM的事件。该事件比确定下一次转换。这种方法并不罕见。我认为FSM在这里运行良好，前提是您使代码符合事件驱动。

关于FSM一起工作 - 有一个hierarchical FSMs

的概念

另一种可能性 - 您可能希望使用进程或作业控制DSL。通常，他们隐藏着一个隐藏在FSM之下的FSM - 但是您使用更高级别的语言来表达您的逻辑。