作者 | 颜超敏
个人网站 craft6.cn

【注】本图用Visual Paradigm UML 10.0制作。如需安装文件,可以公众号联系我。
本图是我专门制作的示例图,并非实际的正确业务图,所以业务正确性上请不要较真。
本图涵盖了UML状态图常见元素,通过阅读理解本图可以一次性了解。
最左侧实心黑点为开始状态,一般写一个动作,表示如何启动本状态流。
开始状态一般只有一个,如果涉及多种一个,则可以通过【进入点】来处理其它入口。
结束状态可以有多个,一般一个为正常结束,其它的为异常结束。
动作
子状态机一般用于对若干状态进行分组,并且当这些状态具备共同的业务处理时更加时候。
比如关闭、锁定。放在子状态机上面,表示这些状态的情况均可以这样处理。
进入点和结束点
进入点对应图中是【货到付款】那个蓝色圆圈。
结束点对应图中是【关闭】状态前面的叉叉圆圈。
进入点表示非常规的进入方式。
结束点表示非常规的结束方式。
菱形符号表示分支,即状态流转时,根据条件判断走那一个分支,图中 [是否签收] 是一个判断。
黑色实心竖条(或横条)表示并发,配对出现。表示到这里并行的开始和汇聚。
历史记录用于当状态从主状态流跳出时,记录上一个或者更早时期的状态。
记录的上一个状态为【浅层历史记录】,用于状态撤回。用一个 H 符号表示。 对于本图是:已确认 撤回到 已支付、已支付 撤回到 未支付。
记录的更早时期的状态为【深层历史记录】,用于当撤回时,没有特定的上一个状态的情况。用一个 H+ 符号表示。 比如对于本图是 锁定 状态 解锁时,要恢复到历史记录状态。历史记录状态一般有一个专门的字段存储。
其它
泳道:状态流一般不需要用到,活动图才需要。但是你也可以加上去,用于区分不同状态对应的参与者。
事件:活动图中有专门的事件图型,状态图没有。一般用文字描述,补充在状态连接线的描述中即可。状态图更注重状态的流转定义,而不是大而全的描述。
是否可以用活动图绘制?其实完全可以,我也经常用活动图来绘制状态图,关于这点,我将在活动图文章中描述。
当我们拿到一份客户需求时,客户不一定会直接告诉你这些业务实体有那些状态,或者他们只是告诉你他们知识范围内的状态,但是在系统中实现,往往却不是这个样子,状态可能会进行增减,那么我们如何基于需求来分析出状态流呢?
找出要分析的领域对象
数据实体和其关联行为,比如订单、客户等。
业务流程,比如开店审批流程。
设备控制(比如电梯、电话、播放器等)
找出和该领域对象相关的所有参与者
即找出所有和该对象相关的相关人,无论直接相关还是间接相关。
比如对于订单而言,有顾客、客服、审单人、财务、打单人、称重人、打包人、发货人等等。
将和状态变更无关的用例剔除。比如订单导出、订单查询等。
将状态收集起来并进行分组
比如对于订单状态而言,从业务上来看可以分为:售前、售中和售后。上面的流程图涉及到售前和售中两个环节,售后环节可以纳入订单状态中,也可以另起一个状态流来管理。
将状态串起来
状态先后顺序
那里会产生分支 一般是涉及到判断选择时会出现分支。
那里会产生并发。 涉及多个参与者同时处理用例时,可能会产生并发。
- 那些状态可以作为子状态机来框起来(其实是方便查看)
简要描述动作和事件
在状态图中,并不需要把用例详细的在这里说明,这里描述动作和事件是为了更容易阅读图型。
动作一般用中括号括起来: [xxx]
调整和美化
个状态图的关键作用是为了沟通,所以画图时,注意各个状态图的大小一致、位置对齐、连接线的对齐等等。
整个图务必看起来整齐美观,赏心悦目,不要觉得这是浪费时间。