共计 5094 个字符，预计需要花费 13 分钟才能阅读完成。
前言
正如任何生物一样，软件也有孕育，诞生，成长，成熟以及兴起的生命过程，常称为“软件生命周期”。软件生命周期个别分为几个阶段：既制订打算、需要剖析、设计、编码、测试、运行和保护。而UML 则反对从需要剖析到设计再到编码的过程。
需要剖析和设计占了整个软件生命周期的两个局部，可见其重要性，而很多时候，开发同学经常会跳过这两步，间接进入编码阶段。本文次要应用 PlantUML 开源我的项目，联合一些理论我的项目中的需要进行剖析和设计。
PlantUML 是一种简略易懂的 UML 图形绘制语言，几行代码就能够绘制出各种 UML 图。在纯熟之后，能够比个别的绘图工具高效许多。更重要的一点是便于版本治理，在一直迭代的性能需要中，能够继续保护。
需要剖析 - 前奏
前奏，是一个首歌的基调，肯定水平上决定了整首歌的格调变动。需要剖析是整个软件设计的根底。
有很多开发同学会有疑难：需要剖析是产品经理要干的事件啊？关咱们开发什么事件？其实不然，需要剖析对于开发来说，首要也是重要的目标，就是精确并且简洁的答复“谁用什么零碎做什么事”。咱们通常能够应用「用例图」来搞清楚这一问题。
用例图
例如在「晒单有礼」这个我的项目中，有如下用例图：
- “客户端用户应用晒单有礼零碎匹配晒单策略”
- “经营人员应用该零碎设置晒单策略”
PlantUML 代码
@startuml
left to right direction
actor 经营人员 as D
actor 客户端用户 as user
rectangle 晒单有礼（精简版）{
D –> (晒单策略): 设置
user –> (晒单)
(晒单) –> (晒单策略): 匹配
}
@enduml
解析
1、@staruml 和 @enduml plantuml 预发的起始和完结标识
2、left to right direction // 标识图形由左向右绘制
3、actor 用户（君子图形）
4、rectangle 矩形框，外部代码图形都在这个框内
5、–> 实线箭头
上图简略的表白了，“客户端用户应用晒单有礼零碎匹配晒单策略”和“经营人员应用该零碎设置晒单策略”，曾经能能大略答复“谁用什么零碎做什么事”了。然而还不够精密，咱们还能够做如下扩大：
上图将“晒单”和“晒单策略”进行了补充和解释。
- “晒单”入口来源于订单列表
- “晒单策略”分为“设置”和“匹配”两个动作
- “晒单”包含“发动静”和“匹配晒单策略”
- “设置晒单策略”包含“设置激励类型”和“设置画像”
PlantUML 代码
@startuml
left to right direction
actor 经营人员 as D
actor 客户端用户 as user
rectangle 晒单有礼（扩大版）{
D –> (设置晒单策略)
(设置晒单策略) .> (设置画像):《include》
(设置晒单策略) .> (设置激励类型):《include》
user –> (查看订单列表)
(查看订单列表) –> (晒单)
(晒单) .> (发动静):《include》
(晒单) .> (匹配晒单策略):《include》
}
@enduml
解析
1、用例图除了罕用的关联和泛化还有上面两种：
include – 一个性能能够拆分较小的局部）
extend – 一个性能的附加性能
2、(晒单) .> (发动静):《include》
示意“晒单”蕴含“发动静”这个动作，冒号前面其实能够是随便文本。
实际上，咱们还能够将用例图持续细化，然而并没有必要这么做，用例图往往只有做到可能比较清楚的形容两个 W，Who- 谁来用这零碎；What- 用这个零碎做什么。
概要设计 - 主歌
主歌，是一首歌的中心思想，外围主题，它贯通于整首歌当中。在概要设计中，咱们须要梳理并把握整个我的项目的脉络。
有了需要剖析的铺垫，咱们能力更好地进行概要设计。在上文中咱们曾经提到，需要剖析时，须要答复好 Who&What，而 概要设计则是须要概要的答复 How- 如何解决问题。在概要设计时，我通常会应用 UML 中的流动图，状态图，时序图来形容我的设计。
流动图
在 UML 中，流动图会比拟宽泛，例如咱们常说的流程图，泳道图等都能够算是一种流动图。流程图的次要侧重点在于突出有哪些流程节点，以及节点的走向管制；泳道图则是在流程图的根底上，突出不同角色在整个流程中的地位和作用。通常咱们会联合起来绘制。
上面咱们看一个自建圈子我的项目的实例：
就绘制泳道图而言，还是举荐应用其余工具绘制。
比照一下应用其余工具绘制的图（齐全一样的流程）：
PlantUML 代码
@startuml
| 客户端 |
|H5 前端 |
|ServerAPI|
|CRM 后盾 |
| 客户端 |
start
|ServerAPI|
if(不合乎建圈要求) then
| 客户端 |
: 不展现建圈入口;
stop
else
| 客户端 |
: 展现建圈入口;
|H5 前端 |
: 填写建圈表单;
|ServerAPI|
: 提交表单期待审核;
|CRM 后盾 |
if(审核不通过) then
|ServerAPI|
: 私信告诉不通过;
stop
else
|ServerAPI|
: 私信告诉通过;
| 客户端 |
: 展现建圈工作入口;
: 点击工作入口;
|H5 前端 |
: 展现工作列表;
|ServerAPI|
if(未实现工作) then
: 私信告诉工作失败;
stop
else
: 私信告诉工作胜利;
| 客户端 |
: 保留自建圈子;
stop
@enduml
解析
1、| 客户端 |
双竖线示意泳道。
2、start、stop
开始完结节点，是泳道流程图中必须的元素。
3、if … then … else
条件判断，个别用菱形示意。
4、一般来说泳道中的流程只能始终往下“游”，而不能往回“游”。
状态图
状态图用来形容一个实体的各种状态，以及状态之间的转化关系。例如电商平台最常见的“订单状态”，状态繁冗多样，用状态图来表白，能够让我的项目更加清晰。
在晒单有礼中，就有波及到订单列表按钮状态的变换。在上面的例子中，有几个关键点：
– 必须要有起始状态和终止状态
– 状态是绝对静止的
– 状态间的转化肯定随同着动作
– 状态是能够蕴含状态的
PlantUML 代码
@startuml
[*] –> 其余订单状态变换
state 其余订单状态变换 {
[*] –> 期待付款
期待付款 –> [*] : 勾销领取
期待付款 –> 期待发货 : 领取
期待发货 –> [*] : 勾销订单
}
其余订单状态变换 –> 无礼确认收货 : 未命中有礼策略
其余订单状态变换 –> 有礼确认收货 : 命中有礼策略
有礼确认收货 –> 晒单 : 14 天后点击确认收货
无礼确认收货 –> 晒单 : 点击确认收货
晒单 –> 查看晒单 : 公布动静
有礼确认收货 –> 晒单有礼 : 点击确认收货
晒单有礼 –> 查看晒单 : 公布动静
查看晒单 –> 有礼查看晒单 : 审核通过发送优惠券
有礼查看晒单 –> 查看晒单 : 领完优惠券
查看晒单 –> [*]
@enduml
解析
1、[] –> 与 –>[]
分表示意起始状态与终止状态。
2、state … {}
状态是能够蕴含子状态的。在本例中，晒单有礼不关怀订单的其余状态，能够应用此语法做简略形容。
时序图
时序图是自己最喜爱的 UML 图，在多团队合作时，能够让沟通变得十分高效，所有相干人员都能很快的理解到本人须要负责的中央。
例如下图是品牌列表需要的一个时序图：
PlantUML 代码
@startuml
hide footbox
autonumber
actor “ 用户 ” as user
participant “APP” as app
participant “ 服务端 ” as tag
participant “ 数仓 ” as sc
participant “ 算法 ” as alg
== 点击品牌入口 ==
user -> app: 点击品牌入口卡片
activate user
activate app
app -> tag: 调用自选品牌数据接口
activate tag
tag –> app: 返回「无自选品牌数据」
deactivate tag
app -> app: 弹出自选品牌窗口
app -> tag: 拜访品牌数据接口
activate tag
tag -> sc: 拜访数仓排序数据
activate tag
activate sc #orange
sc –> tag: 返回品牌排序后果
deactivate tag
deactivate sc
tag -> alg: 查问用户社区偏好品牌
activate tag
activate alg
alg –> tag
deactivate tag
deactivate alg
tag –> app: 品牌数据(包含默认选项 2 个)
deactivate tag
app –> user
deactivate app
deactivate user
@enduml
解析
1、autonumber
指定显示序号，不便沟通交流，举荐应用。
2、actor，participant
示意用户和对象。
3、activate user，deactivate user
激活一个对象，终止一个对象。
4、activate sc #orange
这里是个小技巧，能够给一个对象的激活态标注不同色彩，用于强调。
5、左侧小图中，序号 6，7 步骤，是在一个激活态上再次激活了一次。这里能够强调是开启线程，进行并发调用。
具体设计 - 副歌
副歌，所谓重要的局部再多细唱两遍，是一首歌的低潮局部，能够升华中心思想。在具体设计中，咱们从概要设计中选取一些细节和外围局部做进一步的设计。
具体设计就像一首歌的副歌局部（也经常被咱们称为低潮局部），尽管在主歌里有波及，然而须要重点强调。一般而言，具体设计也是用来答复 How- 如何解决问题，然而须要抓到整个零碎的难点进行重点设计。在 UML 中我通常会应用时序图、类图和组件图来形容。
时序图
看到这个小标题，有同学会问了，“诶，怎么又是时序图？”。其实，时序图能够上到零碎级别的调用过程，也能够下到办法级别的调用过程，甚至能够十分靠近代码逻辑。在具体设计中也经常应用，来个示例，大家感受一下：
PlantUML 代码
…// 省略
loop 循环订单 ids
server -> extend: 查问 trend_extend 是否存在订单
activate server
activate extend
extend -> server: 返回是否曾经绑定订单
deactivate extend
…// 省略
alt 命中晒单有礼
server->cserver: 查问优惠券信息
activate cserver
cserver -> server: 返回优惠券信息
deactivate cserver
server->result:「晒单有礼(最高 XX 元)」
else 未命中晒单有礼
server->result:「晒单」
end
end
…// 省略
代码解析
左侧代码只保留了外围逻辑，如下：
1、loop … end 示意循环，相似各开发语言中的 while 语句。
2、alt … else … end 示意逻辑判断，相似各开发语言中的 if else。
类图
类图是罕用的 UML 图，显示出类、接口以及它们之间的动态构造和关系；它用于形容零碎的结构化设计。
PlantUML 代码
@startuml
interface DuDataFlow {
InfoPosts()
InfoAd()
}
class duDataFlow {
grpc.ClientConn
phpservice.Service
context.Context
InfoPosts()
InfoAd()
}
class grpc.ClientConn{}
class phpservice.Service{}
class context.Context{}
DuDataFlow <|-down- duDataFlow
duDataFlow .> grpc.ClientConn
duDataFlow .> phpservice.Service
duDataFlow .> context.Context
@enduml
代码解析
左侧代码曾经十分靠近开发语言的类定义和接口定义了。
1、<|-down- 继承关系
2、.> 依赖关系
其余局部
具体设计不仅仅只有时序图、类图，还能够包含 DDL、接口文档、工作分工等模块，这里就不再开展细说了。
至此设计文档至此离编写代码仅剩一步之遥了！！
结语
如果将编写软件设计文档比作写一首歌。那么需要剖析就是一首歌的前奏，前奏是一首歌的基调，肯定水平上决定了整首歌的格调；概要设计则是主歌，是一首歌的中心思想，外围主题；具体设计则是一首歌的低潮局部，好听的，重要的局部，当然就得再多唱两遍，加深一下记忆点。
最初，再用几句话详情一下几个 UML 图的特点：
– 用例图 - 答复“谁用这个零碎做什么事件”
– 流动图 - 突出流程中的事务扭转，以及每个泳道的地位与作用
– 状态图 - 形容一个实体的各种状态，以及状态之间的转化关系
– 时序图 - 在多团队合作时，让沟通十分高效，也能够是代码逻辑的具体构造
– 类图 - 代码如何组织，各个类之间的关系
文|BeeOML
关注得物技术，携手走向技术的云端 粗体