欢迎来到状态图的世界什么是状态图呢状态图有多种解释方式下面会详细说明。本质上状态图就是一种图形比如这个简单的状态图不过对于想从本网站介绍中获益的软件工程师来说这个图形作用不大。接下来将深入探讨其他描述状态图的方式。定义状态图的原始论文将其描述为“复杂系统的可视化形式化方法”Harel1987下面试着解释一下状态图。状态图简介简单来讲状态图是增强版的状态机。这种增强解决了状态机存在的许多问题特别是随着状态机规模增大而出现的状态爆炸问题。本网站的目标之一就是帮助大家理解什么是状态图以及它们的用途。- 什么是状态机- 什么是状态图为什么要使用状态图状态图能带来一系列意想不到的好处- 理解状态图比理解许多其他形式的代码更容易。- 行为与相关组件解耦- 这使得更改行为更加容易。- 也让分析代码变得更轻松。- 并且行为可以独立于组件进行测试。- 构建状态图的过程会促使对所有状态进行探索。- 研究表明基于状态图的代码缺陷数量比传统代码更少。- 状态图有助于处理异常情况这些情况在其他情况下可能会被忽略。- 随着复杂度的增加状态图可扩展性良好。- 状态图是很好的沟通工具非开发人员可以理解状态图质量保证QA人员可以将状态图用作探索工具。值得注意的是你已经在编写状态机代码了只是它们隐藏在代码之中。为什么不使用状态图使用状态图也有一些缺点需要了解- 程序员通常需要学习新的知识不过其基础状态机对于大多数程序员来说并不陌生。- 这通常是一种非常陌生的编码方式因此团队可能会因为其差异较大而产生抵触情绪。- 提取行为会带来一些开销因为对于较小的状态图代码行数可能会增加。为什么状态图没有得到广泛应用- 人们对它们了解不足且秉持“你不会需要它”YAGNI的观念。反对使用状态图的主要观点有哪些除了上述提到的缺点外还有一些常见的反对观点- 根本不需要。- 与某种技术的理念相悖。- 会增加库的数量对于 Web 应用程序来说这意味着加载时间会增加。上述提到的好处表明引入状态图总体上是利大于弊的。如何使用状态图首先要知道W3C 委员会花了十多年时间2005 年至 2015 年对一种名为 _SCXML_即状态图 XML的标准进行了规范制定它定义了很多语义并规定了如何处理某些边缘情况。有各种语言的工具可以读取、编写甚至执行用 SCXML 编写的状态图。还有一些衍生标准支持与 SCXML 相同的 _模型_但使用不同的语法。此外针对各种平台都有状态图库它们在不同程度上支持 SCXML 所描述的语义。应该考虑使用这些库来处理那些边缘情况。这些库通常会按照正确的顺序执行进入和退出操作等。了解了这些之后继续阅读吧可执行状态图除了使用状态图在与实际运行代码分离的文档中对行为进行建模之外还可以使用各种机器格式既可以用于设计行为也可以在运行时实际实现该行为。其理念是有一个单一的事实来源来描述组件的行为这个单一来源既能驱动实际的运行时代码也可以用于生成精确的状态图可视化图表。这有一些优点和缺点为什么要使用可执行状态图- 无需将图表转换为代码。- 避免手动转换图表时引入的错误。- 图表始终保持同步。- 图表更加精确。为什么不使用可执行状态图- 图表可能会变得非常复杂。- 可执行状态图的格式和工具有限。- 难以在状态图和组件之间强制执行类型安全。如何使用可执行状态图本质上如果你在代码中有状态图的定义你只需要获取该表示并自动生成可视化的状态图。当然如果定义在单独的文件中例如 JSON 或 XML 文件会更简单。这些内容都在如何使用状态图页面中有详细解释与社区交流如果你想和他人交流关于状态图的话题可以访问 gitter.im查看聊天无需登录在那里你会找到一群志同道合的开发者他们可以帮助你理解并从使用状态图中获益。如果你有更多问答需求可以前往 statecharts GitHub 讨论区我们会尽力回答你的问题。很多人以各种方式撰写过关于状态图的书籍或进行过相关演讲这些内容都收录在我们的资源页面中。如果你写过相关内容请通过发布到 GitHub 讨论区与大家分享。有一些页面在文档体系中没有合适的位置在此特别提及- 用例用户界面中的状态图- 概念 —— 状态图中最重要的概念以及它们在图表中的表现形式。- 术语表 —— 讨论状态图时常用术语及其定义的列表。- FizzBuzz —— FizzBuzz 是一个广为人知的问题它被用作解释各种状态图概念的背景。致谢本术语表条目来自 statecharts.dev 项目。你可以在 GitHub 的讨论区找到更多讨论状态图的人。使用 GitHub Pages 从 github.com/statecharts 发布编辑此页面术语表动作 活动 原子状态 自动转换 复合状态 条件状态 延迟事件 延迟转换 进入 事件 退出 最终状态 生成事件 守卫 历史状态 初始状态 内部事件 局部转换 并行状态 伪状态 引发事件 细化 自转换 状态 转换