共计 2833 个字符，预计需要花费 8 分钟才能阅读完成。
摘要： 时序图是对立模型语言 UML（Unified Model Language）中一种用来示意实体间交互关系的图。
1 前言
在定义零碎间接口或模块间接口时，时序图应用起来十分不便，工作中常常波及要与第三方零碎协商定义接口，或者定义零碎内多模块间接口的状况，常常会看到很多时序图。有的时序图画的很漂亮，很好的帮忙读者精确了解业务和实现办法，而有的时序图则读起来人云山雾罩，苦楚不已。本文不打算再说一遍时序图的构造和步骤，只想阐明时序图中常常遇到次要问题，并许下一个美妙的欲望：心愿当前的工作中再也不要遇到难读的时序图。
时序图是对立模型语言 UML（Unified Model Language）中一种用来示意实体间交互关系的图，英文 Sequence Diagram，有的人把它称为序列图、程序图、循序图，集体习惯于称为时序图，下文都以这个名字来称说。
画时序图的工具十分多，从晚期的 Rational Rose、Sybase Power Designer、Visio，到 Enterprise Architect、StarUML，甚至用 Typora 来画 Markdown 格调时序图也不错，再到当初按公司的要求换用亿图图示 Edraw，这些工具都不错，略微适应下就能画出丑陋的时序图了。
值得举荐的是，公司 CloudDesign 在线设计工具提供的 CloudModeling 绘图工具用起来也相当难受，既便于在团队分享，又提供了 Word 插件便于导入设计文档，如果批改了时序图也只须要在 word 文档中更新一下就主动刷新了，十分不便，强烈推荐应用。网址：https://clouddragon.huawei.co…
上面进入正题。
2 关键点 1：必须明确上下文
把握了这一点就胜利了一大半，没有做到这一点就根本画不分明了。
为什么这句话说这么狠？不就画个时序图嘛，关上下文什么事？因为看过太多让人痛恨的时序图都栽在这个问题上。
咱们晓得时序图中参加交互的实体只有两类，即角色（Actor）和对象（Object），如果连交互的实体都不能明确的定义和达成统一，忽东忽西，忽大忽小，具体交互的流程怎么可能说分明，使所有读者和写作者达成统一呢。
为阐明这个问题，以车联网的场景举个例子，比方近程管制个性的交互时序图。
车辆受权交互时序图
近程开车窗交互时序图
近程开车门交互时序图
如图所示，咱们看到交互实体中呈现了多个相似但又不同的表述，例如“车主”、“被受权用户”、“被分享用户”这一组，“手机 App”和“车主 App”这一组，“TSP 平台”、“TSP 零碎”和“车云”这一组，而在车辆方面，有时称为“车辆”这么大的粒度，有时又称细分为“TBox”、“车身管制模块”、“PEPS”。
这里仅仅举例了 3 个交互时序图，而一个简单零碎往往会呈现几十上百个，当每个时序图的作者都得心应手的对交互实体进行命名时就会呈现极其凌乱的场面，最终貌似每个时序图都看起来很有情理，放在一起看却难以精确了解，使读者抓狂。
解决办法：很简略，画出一个上下文图，把所有时序图中波及的交互实体都放进去，规定它们的名字，要求所有时序图中的实体必须与上下文图中保持一致，不得本人定义新的。如果的确须要减少新的实体，那么首先更新上下文，在上下文图中把实体定义进去能力应用。
例如针对上述车联网的场景，减少一个这样的上下文就能够更加清晰：
在理论我的项目中，能够利用工具来实现这个一致性。例如 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 总结
三个关键点：所有交互实体放进上下文，不间接交互的实体去掉，响应音讯要与申请音讯离开。如果你画的时序图确保以上三个关键点都做到了，我想至多拿出去给大家看的时候会少挨一点埋怨。
点击关注，第一工夫理解华为云陈腐技术~
