状态机绘制的基本步骤，包括定状态、理流程、明数据。首先根据MECE原则列举业务对象的所有状态，确定起始和结束状态；接着梳理状态间的流转次序及触发动作，明确每个业务行为的输入输出数据；最后通过状态流程图和状态定义表，清晰表达状态机的结构和逻辑，确保状态机设计既精确又易于理解。
状态机绘制基本步骤
状态机的绘制基本上分为以下几个步骤：
- 列举某个业务对象的状态，这里需要使用 MECE 原则，即穷尽而不重复，将业务对象的所有状态都列举出来。
- 梳理哪些状态是起始状态，哪些状态是结束状态，以确定业务的开始和结束。
- 确定状态直接的流转次序，并且列出促使状态流转的动作，也就是具体的业务行为。
- 确定每个具体业务行为需要提交的数据和产生的数据，即业务行为的输入输出。
实际简化出来就是“定状态、理流程、明数据”三个要点，下面我们一个一个来详细说明
定状态
梳理操作流程
在介绍了状态流程与业务流程的关系后，是不是有了业务流程就能梳理出状态流程呢？答案当然是否定的。
业务流程之所以不能帮助我们梳理出状态流程，是因为业务流程只能帮我们提炼出状态三要素中的“状态描述”，无法帮助我们精准的确定另外两个要素——“输入条件”和“终止条件”。
大家都知道，在代码实现中，状态要想在系统中流转，需要精确的指令才能进行下一步，这些指令就是状态的“输入条件”和“终止条件”，而业务流程的粒度显然无法满足系统对“精确”的要求，例如商品流转的业务流程是：
在这个流程中，系统无法知道什么算“商家发货”、什么叫“物流配送”，所以业务流程无法直接指导系统进行状态流转，这时就需要我们梳理出对象在系统中的操作流程，通过系统中明确的操作或业务规则来向系统发出精准指令。
在这个操作流程中，对于系统自动处理的部分，可以通过增加一个名为“系统”的泳道，来体现系统自动完成的操作。
虽然状态流程是在操作流程的基础上梳理的，但操作流程却是在业务流程的基础上细化出来的，所以业务流程也是很重要的。
归纳状态
在梳理的操作流程基础上，我们再依据前面提到的设计原则，提炼、总结出此对象的各个状态。同样的，归纳状态时要明确状态的三个要素分别是什么。
理流程
梳理状态流程
有了第二步梳理的各个状态，顺着操作流程的方向，就能得到我们的状态流程了。为了沟通更方便，表达更清晰，状态流程图就是必不可少的，一般的状态流程图有三种表现形式。
纯状态流转：即流程图中仅体现状态的流转，不展示其他信息，如下图所示。
与操作流程结合：既然状态流程是在操作流程的基础上梳理的，这就说明这两个流程其实是可以合并处理的。如下图所示，在状态输入条件后展现状态名称，到下一状态开始前，中间过程均为属于此状态。这种形式在操作流程较短时比较方便，可以用一张图体现两个流程，但当操作流程较长时，这张图的可读性就比较差了，不同信息间会产生干扰，这时就推荐用第三种方式了。
仅体现状态三要素：如下图所示，这种形式是在上一形式的基础上，去掉中间无关操作，仅保留状态的三要素，这样既可以满足开发同学对触发条件明确的要求，也方便进行讲解汇报。
明数据（整理状态定义表）
示例
我们再举一个我们产品开发的任务管理的例子。对于产品开发的某个需求点，通常会经过需求评审到上线的过程。我们按照上面的步骤进行一下状态机的分析：
- 状态列举：整个过程有待评审、被驳回、待开发、开发中、待测试、待验收、已上线7个状态。
- 待评审属于起始状态，被驳回、已上线属于结束状态。
- 状态的流转图如下：
每个业务行为的输入输出如下表所示：
状态机与流程图的区别
我们看上面的产品开发的任务管理状态机图其实并不是特别合理，我们可以看到不同的状态的流转其实的业务动作是一样的，比如评审不通过和通过实际上的行为应该是评审。之所以会出现这个情况，是因为实际上这里揉和了多个业务对象：需求、开发任务、测试任务等等。这种需要描述多个对象的状态机的情况，那么应该结合流程图来做，如下图所示。这种方式可以将业务对象的状态变化和业务流程串联起来，会更好地知道哪些状态受关联的业务环节影响，比如需求的开发中状态就依赖开发任务的确认开始动作。
可以看到，状态机和流程图某些方面是类似的，都是用来描述业务流转，但是二者也存在明显的不同，状态机更关注的业务环节中某个对象自身的状态变化，而流程图更适合描述整个业务的环节的不同行为如何衔接各个业务对象。也就是，状态机关注的范围相对会更小一些。如果一个业务对象的状态流转无法通过作用于自身的业务行为表示，就可以引入相关业务对象的状态机和流程图来共同绘图表示。由于同时绘制多个业务对象的状态机图可能会很复杂，因此建议将主路径用强调出来，这样可以很清晰地知道主流程如何流转。
没有回复内容