一文读懂 UML 时序图

书接上文，我们在《一文读懂 UML 用例图》里说到：需求设计的第一图通常是用例图，后来有人问我，那第二图、第三图呢？本文开始前，我先列一下设计阶段常用到的 UML 视图：

大家可以看到，时序图和活动图是各个设计阶段，从产品经理、架构师，到底层开发人员都会使用到的视图，今天就借机讲讲如何画时序图。

概述

时序图（Sequence Diagram）是 UML 中最常见的交互图，通过描述对象间发送消息的时间顺序显示多个对象之间的动态协作状态。

数序图的元素稍多于用例图，有角色（Actors）、对象（Object）、生命线（Lifetime）、消息（Message）、激活（Focus of Control）等等。

我们还是老样子，不列一堆名词解释，只用一个简单的例子，分步骤讲解这些功能模块的示意以及使用方式。例子的话，还是沿用我们的乞丐版银行 APP——见《一文读懂 UML 用例图》；由于篇幅所限，本文只涉登陆和查询余额相关的操作。

Actor（角色）& Object（对象）

时序图的第一步是列出交互中出现的所有角色和对象。

• 角色：通常指“人”，也可以是组织、机器、系统等等“抽象的人”，和用例图一样，用小人图表示
• 对象：就是与上述“人”对应的“物”了，包括所有产品、服务、设备等等抽象的物体

时序图的交互，通常由最左侧的 Actor 发出；在我们的银行 APP 案例中，Actor 是客户；我们就按出场顺序，把这些“人”和“物”从左至右列出来：

Lifeline（生命线）

时序图的第二步非常机械：给每个角色和对象加上一条生命线。所谓的生命线就是从角色（或对象）引出向下延伸的虚线，表示时序图存在的时间轴。

Message（消息）

有了角色和生命线，时序图的基本框架就搭建起来了。我们就可以让客户向 APP 发出第一个消息了——登陆：

消息自然是有来有往的，发送出去的消息叫 Request（请求），反馈的消息成为 Response（响应）

• 请求用实心箭头示意，并在箭头上方加注说明
• 响应用虚线箭头表示，也会加上简单的返回内容

我们登陆的操作，如上图所示就是这么几小步：

1. 客户输入用户名、密码后点击登陆
2. APP 将用户名、密码送往 Auth 服务验证
3. Auth 服务通过验证后返回 JWT
4. APP 向客户显示登陆成功

Combined Fragment（组合片段）

但是，登陆也可能失败！也就是说在时序图上还要添加登陆失败时的消息反馈。这时候就得用到组合片段了；组合片段用来解决交互执行中的条件反馈。组合片段长得比较复杂，如下图所示：

组合片段有十几种，最常用的就是 Alt 片段——抉择片段，通俗来说就是 if-else 的条件判断组合。如上图所示：

• 左上角黄色区域会标明片段的类型
• 片段中用虚线区分不同的条件子域
• 再在子域左上角——绿色阴影区——注释条件判断
• 最后在各自的条件子域上返回特定响应

Focus of Control（控制焦点）

控制焦点又称激活，是覆盖在生命线上一段细长的矩形，表示在这个时间段内，对象或角色正处于活动状态；这有点类似于 java 语言里的大括号{}——作用域。画激活相对来说比较机械，我一般都留到最后加上。

由上图可知，APP 的活动态要长于 Auth 服务；如果再加上 Bank 服务相关的时序活动，大家能更直观地感受到服务运行时长对比。这有什么用呢？先卖个关子，我会在之后的文章里给出解答。

小结

好了，基本元素都讲完了，我们再小结一下。时序图是我们开发人员使用最频繁的一种设计视图。大家在动手实现新 feature 前，都应该画一张设计视图。为什么呢？其根本原因就是：画设计图的成本要远低于码代码，通过设计图理清思路后，开发更便捷；换句话说，就是我们应该以更经济地形式完成工作。此外，还有一些腹黑的原因：代码很长的，老板根本没时间看的；你要自己找存在感，得让他/她看简单明了的东西，图就是最好的信息介质！好了，大家快去画图吧。

文章同步发布于an-Onion 的 Github。码字不易，欢迎点赞。