1 前言
UML[1]是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。
UML是一门通用的语言，在对于人与人之间的交流上，能提供跨编程语言的作用。在设计阶段，功能落地阶段，测试阶段，维护阶段，能起到提高效率的作用。
使用UML能为我解决什么问题？这里我罗列一下我遇到的场景：
- 在一个较大的功能（可能要1个月才能完成）来到的时候，在没有使用UML的时候，我可能会开发过程中，会发现我可能一开始做设计的时候没有考虑的点。或者我曾经想到过的点，到我真正编程的时候，就忘记了这个小点。在此过程，我需要不断反复修复不同地方的小点。
- 当我开发这个功能的时候，可能我是要跟不同的同事合作（比如合作的同事是做 与我不同平台的 开发语言），此时我需要面对面通过一些画图来讲解我的功能设计。因为大家的开发语言不一致，对方要看我的源码是不太现实的
- 当测试需要介入时，他们需要了解我们的内部逻辑，才能做好白盒测试[2]的测试用例设计。此时也不能直接让对方看代码，只能靠口口相传
- 可能过了很久很久以后，有同事帮忙去定位模块的功能 Bugs，或者迭代优化。对于那位接手的同事，只能面对一片没有注释的源码，估计他只能在地下画圈圈了
应对上面4个场景，使用了UML之后，会怎样：
- 可以通过UML的元模型建立
功能模型，对象模型，动态模型，反思自己在设计这个代码的时候，是否具备完备性。人的记忆是有限的，当设计完一个子模块，跳到另一个子模块设计的时候，可能就对上一个模块的记忆会出现模糊。而拥有已经写好的UML，可以让人快速建立对上一个子模块的记忆（UML每一个记录的细节点，都可以成为那位开发的记忆触发点）。当真正进行开发的时候，开发可以按照UML来进行相关的开发，尽可能保证所有的细节都被保留。 - 当进行
技术评审时，可以拿出UML，进行整个流程的讲解。让对方知道自己是怎么跑流程/功能。由于UML是统一性语言，对方能很快get到设计者的思路想法。Reviewer可以根据自己的经验给出一些建议，能让大家的沟通成本，思想的传递做得更好（PS：相对文字和图形，人脑对图形的接受能力显然更强） - 跟第二点一样，对于测试同事，也可以很快传达自己的思路
- 从维护角度，通过UML和必要的文字描述，可以辅助接手的同事快速知道代码不同地方的作用。如果有了相关的UML，在代码的类头部也可以加入注释，把文档的link带上。
这里引用一段有意思的话:
来自《Thinking in UML》[3]:
从微观角度说，这些独立的对象有着一系列奇妙而古怪的特性。例如，对象有着坚硬的外壳，从外部看来，除了它用来与外界交互的消息通道之外，对象内部就是一个黑匣子，什么也看不到，这称为封装；再例如对象可以结合在一起形成新的对象，结合后的对象具有前两者特性的总和，这称为聚合；对象可以繁育，产下的孩子将拥有父辈全部的本领，这称为继承；每个对象都有多个外貌，在不同情况下可以展现不同的外貌，但本质只有一个，这就是接口；而多个对象却可能长着相同的脸，但同样的这张脸背后却是不同的对象，它们有着不同的行为，这就是多态。
从宏观角度说，对象是“短视”的，它不知道也无法理解它所处的宏观环境，也不知道它的行为会对整个宏观环境造成怎样的影响。它只知道与它有着联系的身边的一小群伙伴，这称为依赖，并与小伙伴间保持着信息交流的关系，这称为耦合。同时对象也是“自私”的，即便在伙伴之间，每个对象也仍然顽固地保护着自己的领地，这称为类属性，只允许其他人通过它打开的小小窗口，这称为方法，进行交流，从不允许对方进入它的领地。
然而对象也喜欢群居，并且总是“物以类聚，人以群分”。这些群居的对象有着一些相似的性质，它们依靠这些相似的性质来组成一个部落。对象们寻找相似性质并组成部落的过程称为抽象，它们组成的部落称为类；部落里的每个成员既有共同的性质又有自己的个性，我们只有把特有的个性赋给部落成员才能区分它们并使它们活动起来，这称为实例化。
1.1 它能为我带来什么好处
从我目前几个月的使用情况来讲：
- 前期设计上：对我在做功能设计的时候，可以
低成本画出功能上是怎么运作，每一步是怎么做的，是否有遗漏没有考虑到的地方 - 合作上：可以使用它跟合作的开发介绍这个功能是怎样，让对端理解我的设计，提出意见
- 测试上：可以让测试知道其内部的运作模式是怎样的（可用于技术评审上讲解功能展示，这里注意要补充一些必要的文字，如果单纯丢文档，可能信息不足，对于测试同事会懵逼），能做出相关的白盒测试用例。
- 维护上：人员的流动，业务的交接，这是无法避免。对于接手业务的同事来讲，必要的文档，能让他们更快去理解原来功能的设计
- 跨部门支援：当别的部门想直接使用本部门已经完备的功能，这是可以通过这部分的文档，快速让对方知道要怎么接入
2 目前我对UML的理解
在了解有什么UML之前，可以先思考一下，在哪里用到UML，怎么使用UML。这里有一个概念要介绍一下。
- 建模：指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达
以我目前使用到的场景，有以下三个场景：
- 了解需求后，根据经验与了解到的事情，把关键的要素罗列出来，通过
活动图描述整体走下来的过程。让参与者达成一致，避免大家理解的差异 - 对具体的一个功能，其内部逻辑的交互过程通过时序图描述出来。有什么作用，请看下面两点
- 自我回述查看是否哪里的一个拐点我理解不足，是否我需要去了解更多
- 可以跟他人沟通，让双方达成一致的观点，或者对方可以补充我思考不足的地方
- 跨部门合作的适合，明确双方的一个交互
活动图，明确双方的职责在什么地方。与第一点相似，但是这里偏向双方的技术栈是不同，可以通过统一语言，让双方明白交互物，输入/输出是什么。
3 我常用的UML类型
我比较常用的UML有以下几种：
- 时序图
- 类图
- 活动图
- 组件图
- 状态图
不常用的UML图有以下：
- 对象图
- 部署图
以下将展示一下上面讲到的图的例子
3.1 时序图
时序图[4]：通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。
以下是一个例子
3.2 类图
类图[5]：显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。
以下是一个例子
3.3 活动图
活动图[6]: 阐明了业务用例实现的工作流程。
以下是一个例子
3.4 组件图
组件图[7]：表示组件是如何互相组织以构建更大的组件或是软件系统的。
以下是一个例子
3.5 状态图
状态图[8]：描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。
以下是一个例子
3.6 对象图
对象图[9]: 显示了一组对象(类的实例)和他们之间的关系。
以下是一个例子
3.7 部署图
部署图[10]：用来显示系统中软件和硬件的物理架构。
以下是一个例子
4 总结
以上是我为什么会投入去了解和使用UML的原因，基本的例子给大家看看各种图的样式。后面会讲解我针对不同的UML的日常使用理解与结合PlantUML[11]是如何使用的介绍。工具能让我在一些不必要的消耗上减少，focus更多的精力在工具无法解决的领域