一文读懂 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。码字不易，欢迎点赞。