摘要：时序图是表示统一模型语言UML(unifiedmodellanguage )实体间的相互关系的图。 首先，在定义系统间接口和模块间接口时，时序图非常好用，涉及与第三方系统协商定义接口，定义系统内的多模块间接口有的时序画很漂亮，可以帮助读者准确理解业务和实现方法，而有的时序画读着云山雾罩，痛苦不堪。 本文不打算再说一遍时序图的结构和步骤，而是说明了时序图中经常遇到的主要问题，希望在今后的工作中不要遇到难以阅读的时序图。
时序图是用统一模型语言UML(unifiedmodellanguage )表示实体间的相互关系的图。 英语Sequence Diagram，也有人称为序列图、序列图，但个人习惯称为时序图，以下用这个名字称呼。
绘制时间图的工具非常多，从早期的Rational Rose、Sybase Power Designer、Visio开始，到企业架构、StarUML、甚至Typora中Markdown风格的
值得推荐的是，公司的CloudDesign在线设计工具提供的CloudModeling绘图工具也相当好用，团队共享和Word插件部署方便，修改时序图后只需在Word文档中更新即可自动更新URL:https://cloud dragon.Huawei.com/uadp/home
让我们进入正题吧。
两点1 :上下文掌握了这一点就成功了一大半，没有做到这一点就基本画不清楚了。
为什么这句话这么冷酷？ 画一张时序图吧。 关于上下文是什么？ 因为我看过太多悔恨的时序图种在这个问题上。
我们知道在时序图中参与相互作用的实体只有两种：角色(Actor )和对象。 如果连相互作用的实体都不能明确定义和匹配，那么突然、忽大忽小，具体的相互作用流程如何清晰，所有读者和写作者又能匹配呢？
为了说明这个问题，我们以远程控制特性的交互式时序图等远程通信的场景为例。
车辆许可证的相互作用时序图
远程开窗的交互式时序图
远程驾驶门的交互式时序图
如图所示，交互实体包括“所有者”、“许可用户”、“共享用户”、“移动电话APP”、“所有者APP”、“TSP平台”、“TSP系统”、“车云”等在车辆方面，请参照“
这里只举了三个交互式时序图作为例子，但是复杂的系统往往会出现几十几百个。 如果各个时序图的作者随心所欲地给互动实体命名的话，会很混乱。 结果，各个时序图似乎都很有道理，但即使一起看也不能正确理解，会让读者烦躁。
解决办法：很简单，画出一个上下文图，把所有时序图中涉及的交互实体都放进去，规定它们的名字，要求所有时序图中的实体必须与上下文图中保持一致，不得自己定义新的。如果确实需要增加新的实体，那么首先更新上下文，在上下文图中把实体定义进去才能使用。
例如，如果针对上述电信系统场景添加这样的上下文，就会变得更清晰。
在实际项目中，可以利用工具实现这种一致性。 例如，CloudModeling绘图工具定义了系统上下文和系统逻辑结构的完整视图。 所有交互时序图都必须通过此处的角色和链接进行参考，而不是自行创建。
3要点2 )决定是否应将某个实体列入时间图上的例子。 在车辆相关实体中，有时粒度被称为“车辆”，有时细分为“TBox”、“车身控制模块”、“PEPS”。 实际上，“TBox”、“车身控制模块”和“PEPS”都是车辆内部模块的一部分。 那么，究竟在什么情况下应该在时序图中加入“车辆”这样大的粒度，在什么情况下应该展示“TBox”、“车身控制模块”、“PEPS”这样的内部模块呢？
个人理解是这样的：实体是否展示与业务场景和所设计的对象密切关联，只有在业务场景中与所设计对象有直接交互的实体才有必要放入时序图中，间接交互实体则应当去掉。
在上面的例子中，在以TSP以及智能手机APP为对象进行设计的情况下，不需要展开车辆内部的物理部分，如下所示，展示与车的云直接交换的TBox模块即可
远程驾驶门的交互式时序图
但是，如果我们设计的对象变成了车身控制模块，则交互实体必须省略有关TSP和车主手机App的实体
，把关注点调整到与车身控制模块直接交互的实体上来，例如：远程开车门交互时序图
4 关键点3：响应消息要与请求消息分开时序图中交互实体间水平的线条用来表示消息，最常见的有三种：
4.1 同步消息（Synchronous Message）与返回消息（Return Message）同步消息（也称为调用消息）一定要与返回消息成对使用，特别要强调的是：返回消息样式不得使用同步消息的样式，这是两个完全不同的事情。同步消息表示一个实体对另一个实体的一个接口调用，被调用方要按流程实现提供接口的编码，并按返回消息内容要求进行返回；调用方需要按流程实现调用接口的编码，并对返回消息内容进行处理。为了更清楚的说明问题，往往会在消息中注明关键的参数。
经常看到的错误是不区分同步消息和返回消息，乱画一气，非常让人恼火。有时会看到像这样的时序图，特别注意其中红色的消息线条，看起来似乎“TBox”实体对“TSP”实体的一个接口调用，但实际问一问作者，发现并不是这样，而是上面消息的返回消息。这样的画法就给人造成一种错觉，以为交互实体双方需要实现一个新的接口。
4.2 异步消息（Asynchronous Message）消息发送者通过消息把信息发给消息接收者，然后继续自己的活动，不等待接收者返回消息。
4.3 自关联消息（Self-Message）表示实体自身需要实现一个处理过程，也可以调用一个外部实体的消息。
同样以上面车联网场景为例，假定设计的对象是TSP及车主手机App，那么我们只能对这两个实体分解开发任务，如图，我们要求“车主手机App”实现“提供开车门功能”，具体包含向TSP的请求开车门消息调用及返回结果的处理；“TSP”要实现“提供开车门接口”，具体包含向TBox的下发开车门指令及返回结果的处理，还包含一个发送短信通知的异步消息，TSP提供的开车门接口请求参数中应包含关键的用户token、车辆ID信息，返回结果中应包含关键的成功/失败、错误信息。
注意：这里引入了一个新的实体“短信中心”，也应当在上下文图中先加进去才能使用。
远程开车门交互时序图
5 总结三个关键点：所有交互实体放进上下文，不直接交互的实体去掉，响应消息要与请求消息分开。如果你画的时序图确保以上三个关键点都做到了，我想至少拿出去给大家看的时候会少挨一点抱怨。
点击关注，第一时间了解华为云新鲜技术~