一 前言

　　在日常工作中，无论是产品经理写PRD或是开发、测试同学写技术方案、整理业务文档等场景都会用到诸如流程图、时序图、用例图、泳道图等形式的图来辅助阅读者理解。相信平时工作中有画图需要的读者都有这样的感受：有些图制作过程非常简单但逻辑清晰又不失美观，而有些图费时费力制作繁琐，但效果却不是特别惊艳，这其中的底层逻辑尤为关键，毕竟作图也是一门艺术。本文将会以直播商品讲解业务场景出发，给大家分享一些画图小知识。

　　上面我们提到了很多种的图，归根结底是两类：流程图和UML图。细分的话有活动图、状态图、用例图、顺序图、类图、对象图、协作图等13种。不同的图适用于不同的情形。

　　本文主要讨论流程图和时序图。

　　二 两者区别

　　时序图强调对象之间的交互与时序关系，流程图则是针对一个过程或者活动进行全面而细致的展开。

　　时序图主要描绘多个对象之间的复杂关系，流程图通常描述单一对象的各种操作和转换过程。

　　时序图更加注重时间顺序，可以清晰地表示交互的先后顺序与时序关系，而流程图注重过程的控制流程，可以描述每个步骤的执行方式以及处理逻辑。

　　三 流程图

　　流程图基本组成

　　如上图所示，飞书文档里提供的流程图的元素。下面我简述一下常用的图形：

　　2.绘制流程图中的注意事项

　　1. 画流程图的时候，需要遵守从上至下、从左至右的顺序的原则进行排列，这样做的目的是流程图的逻辑性更高。

　　2. 一个流程需以开始符开始，以结束符来结束。开始符号只能出现1次，但是结束符号是可出现N次的。其实流程逻辑清晰的话，可以省略掉开始符号和结束符号，但还是建议保留二者。

　　3. 用菱形作为判别符号，且一定要有"是和否，建议使用Y或者N表示"两个处理结果，且判别框中一定要有二个箭头；而且判断符号的上下处的流入流出一般用“是(Y)”，左右处流入流出用“否(N)”。

　　4. 在一个流程图中，字符的大小必须一致，同时连线不得交叉，连线也不得无故扭曲。

　　5. 流程处理关系如果是并行关系的，那么就需要将流程画的时候放在同一个高度。

　　6. 描述流程需要清晰明了，所以必要的时候需采用标注，标注需要要用专门的标注符号来表示。

　　7. 画处理流程，必须是单一的入口、单一的出口。

　　BadCase：

　　对照上文7点注意事项看看上图存在哪些问题？直观感受是不是看着不是很舒服？

　　元素大小不一致。

　　布局未按从左到右。

　　部分需要判断的流程没有画出来。

　　处理流程的入口和出口非单一。

　　还有其他问题期盼大家在评论区里留言。

　　GoodCase：

　　主播或者管理员对商品进行录制讲解功能：

　　四 时序图

　　时序图基本组成

　　时序图形，也被叫做序列图,是UML图形的一部分。它通过描述对象间传递message的时间序列，来表示各个object间的动态协作关系。飞书文档里提供了丰富的元素来支持我们绘制UML图。

　　其中比较常用的有以下7种。

　　画好时序图的注意事项

　　1. 必须明确上下文

　　掌握了这一点就成功了一大半，没有做到这一点基本就画不清楚了。

　　为什么说的这么笃定呢？

　　众所周知，时序图中参与交互的实体只有两类，即角色（Actor）和对象（Object）。如果连交互的实体都没有明确的定义以及达成一致，具体交互的流程就很难说清楚，也就很难使所有读者和作者达成一致。

　　2. 决定该不该把某个实体放进时序图

　　实体是否展示与业务场景和所设计的对象密切关联，只有在业务场景中与所设计对象有直接交互的实体才有必要放入时序图中，间接交互实体则应当去掉。

　　3. 响应消息要与请求消息分开

　　a. 同步消息与返回消息

　　同步消息（也称为调用消息）一定要与返回消息成对使用，特别要强调的是：返回消息样式不得使用同步消息的样式，这是两个完全不同的事情。同步消息表示一个实体对另一个实体的一个接口调用，被调用方要按流程实现提供接口的编码，并按返回消息内容要求进行返回；调用方需要按流程实现调用接口的编码，并对返回消息内容进行处理。为了更清楚的说明问题，往往会在消息中注明关键的参数。

　　经常看到的错误是不区分两种消息，读者看后会产生理解偏差。

　　b. 异步消息

　　message的发件者通过把信息发给接收对象，然后继续它自己的执行逻辑，不需要等待接收者响应。

　　c. 自关联消息

　　表示实体自身需要实现一个处理过程，也可以调用一个外部实体的消息。

　　示例场景：直播短视频切片生产并送审

　　业务简要说明：主播把录制好的商品解说进行视频上传，视频需要同步上传至点播中心，然后需要对视频进行转码。另外视频需要进行风险检查。视频内容重复度检查。最后投递到直播审核后台进行人工审核。

　　明确上下文：

　　本场景只需要一个时序图就可以画完，所以不涉及上下文。明确好角色和对象即可。如果是多个时序图描述的，所有的实体的命名需要统一定义好，且颗粒度需要保持一致。

　　确定实体：

　　只需要把我们直接交互的实体进行罗列。举例：在本示例中，视频送审至风控后，风控侧审核人员领取任务进行审核这个步骤与本示例就属于间接交互。就需要剔除。因为我们只需要关心送审成功，以及审核结果同步即可。

　　消息交互梳理：

　　主播上传视频至直播服务是同步消息。

　　直播服务同步返回主播操作成功or失败消息。

　　直播服务把视频注册到外部云厂商视频点播服务是一个异步操作需要异步消息。

　　点播注册成功后通知直播服务，所以是一个回调操作。

　　直播服务通知外部云厂商视频点播服务进行转码操作，是一个异步操作需要异步消息。

　　直播服务把视频送审至风控是一个异步操作需要异步消息。

　　上述两步可以并行操作，所以需要标记并行。

　　外部云厂商视频点播服务转码成功通知直播服务，所以是一个回调操作。

　　直播服务把转码后的视频通知算法进行去重检查是异步操作，需要异步消息。

　　风控结果同步直播服务，是一个回调操作。

　　直播服务进行送入人审是一个异步操作。

　　算法视频重复度检查结果通知直播服务是一个回调操作。

　　直播服务接收到视频重复检查结果后，只需内部处理。所以是自关联消息。

　　综上梳理，时序图绘制如下：

　　五 结语

　　上述主要分享了流程图和时序图绘制的一些小Tips，因篇幅有限其他UML图在后续的文章中再做补充。我们倡导规范且有逻辑地画图，这对读者是非常友好的，便于其快速熟悉业务流程，并理解实现思路。对照你之前画的流程图和时序图，看看是否还有调整优化的空间，有没有办法表述更清楚？期待大家的评论互动，共同指出画图过程中可以继续完善的地方。