传送门
UML设计系列(1)：状态机图
UML设计系列(2)：类图
UML设计系列(3)：时序图
UML设计系列(4)：用例图
UML设计系列(5)：系统依赖图
UML设计系列(6)：活动图
UML设计系列(7)：UML设计阶段性总结
UML设计系列(8)：数据库关联关系图
我眼中的软件开发流程
对于软件的开发流程，我们一直没怎么触碰，探讨不多。业界的标准开发模式也很成熟，比如你可能听过传统的瀑布、迭代开发模式，随着微服务风靡的敏捷开发模式，以及时下比较为的DevOps等。
这些名词程序员或多或少都听过，甚至项目上都应用过，不过标准的开发模式其实分为4种：瀑布模型、迭代式开发、螺旋开发、敏捷开发，其中螺旋开发可能接触的比较少，而敏捷又比较繁杂。由于今天不是讨论的重点，可自行参考相关资料。
但是从我个人经验来说，不管是哪种开发模式，我觉得在开发过程中应用UML设计都是很有必要的，这里可以提供一些个人的经历供参考。
常用的软件开发流程
早期阶段
在刚工作的那些年，我是在杭州的软件公司做开发，主要是为一些金融机构做系统，既有驻场开发、也有公司saas化的产品。这类项目有一个共通点：属于偏"交付"性质项目，所以对需求管理比较严格（尤其是银行类钱多又强势的甲方），但是对代码设计几乎是没有的。而且这类项目一般有一个权力比较大的项目经理，不仅把控项目进度，还拥有考核权，属于项目经理矩阵的强势一方。他的主要任务是保证系统交付不延期，所以通常都鼓励加班来达成目标。在这种情况下，当时不要说利用UML做系统分析设计，甚至可以说设计也几乎没有，每天几乎就是按照需求不停的写代码，然后产品经理修改需求再改代码，偏向于传统的瀑布模式！
不过当时没有什么经验，加上技术也不熟练觉得可以锻炼技术，这样情况下倒对此也没有多想，顺便收获了一波经验。现在回想起来，如果当年能有这样一个机制要求做好系统设计+评审（或者有这样一个资深的程序员来整体负责），或许当年加的班会不会少一些（至少不会每个资金指令都要重新撸一遍代码）
中期阶段
事情突然有了改变，当从杭州离开回到成都，进入了一家互联网企业（公司总部竟然还是在杭州），UML于我而言，突然变成了不可或缺！这里的开发流程不再是需求来了，埋头苦干就行了，必须要做称为"系分"的设计：
- 不论是项目规模大小，功能简单或复杂都要求写一个系分文档设计
- 要求本系统内尽可能详细，关联系统尽可能全，从全局视角梳理涉及的功能点
- 参与开发人员都要参与，最终汇总评审
在第2点中，编写设计文档的过程中，主要会使用到UML相关的以下几点：
- 使用ER图表示数据库的关联关系
- 使用类图表示对象之间的关联关系；以及模块化的包图
- 使用状态机表示单个对象的生命周期，或某一个操作的业务状态流转
- 使用时序图表示某一个操作的整体流程
- 使用活动图表示某一个操作的详细流程
- 使用依赖图表示系统/组件之间的依赖关系
除此以外，还有从用户角度的用例图来表示系统的功能点与角色的关系，还有系统运维角度的部署图（这里就不贴链接了，现在它还躺在我的草稿箱里面），以及项目管理角度的功能点大图（一般是xmind编写）。
这个过程从入职那一天开始，一直持续到离职。不夸张的说花在UML设计这上面的时间不会比写代码时候少，对于UML的熟悉程度也算比较熟悉了。刚开始肯定是有个适应的过程，工具不熟悉、流程不熟悉，可能画一个流程图所费的时间可能代码都写完了，甚至会在某个时刻感到痛苦。后来类似于自我心里调节，公司相当于发钱让自己学习了，这样还整体学习了一下UML知识体系，收获颇多！其中看过的几本书列举在后面附录了。
现阶段
有一种说法叫"近朱者赤"。虽然离开了老东家，但是对于"系分"和UML设计，还是形成了潜移默化的影响。现在的公司虽然也有自己的研发流程和各种要求，但还是和早期阶段一样，对于系统设计要求并不高。所以难就难在没有外部要求下，如何坚持下去这种研发高标准！好在公司还算有点自由，在后面几年中我始终都沿续了这种步骤，写代码之前做需求、设计分析， 并有幸影响了周围的同事都开始了这种习惯（当有个同事第一次看到这种文档时，直感叹"专业"二字！！！）
假装是一个附录-UML书籍列表
前后七七八八看过几本UML的书，也都是粗略翻翻：
- UML精粹第三版
https://baike.baidu.com/item/UML%E7%B2%BE%E7%B2%B9%EF%BC%9A%E6%A0%87%E5%87%86%E5%AF%B9%E8%B1%A1%E5%BB%BA%E6%A8%A1%E8%AF%AD%E8%A8%80%E7%AE%80%E6%98%8E%E6%8C%87%E5%8D%97%EF%BC%88%E7%AC%AC3%E7%89%88%EF%BC%89/62687193这本书厚，可以做为很好的入门。但是它是大名鼎鼎的Martin Fowler写的，这就值得入手一观了 - [大象-Thinking.in.UML（第二版）].谭云杰https://baike.baidu.com/item/%E5%A4%A7%E8%B1%A1%EF%BC%9AThinking%20in%20UML%EF%BC%88%E7%AC%AC2%E7%89%88%EF%BC%89/12067378这是一本国人写的优秀的UML书籍，里面除了介绍UML之外，还有系统设计方法与思路。不过比较"大部头"，有啰嗦之嫌，说实话我没有看完，建议有兴趣的看看
- UML用户指南(第2版)https://baike.baidu.com/item/UML%E7%94%A8%E6%88%B7%E6%8C%87%E5%8D%97%EF%BC%88%E7%AC%AC2%E7%89%88%C2%B7%E4%BF%AE%E8%AE%A2%E7%89%88%EF%BC%89/62641927这本同UML精粹大同小异，可以互为补充，如果看了前面2本，这本选读
看一个简单的案例
俗话说，"纸上得来终觉浅，绝知此事要躬行"。下面就以一个例子来看看，在一个开发过程中到底如何使用UML。在最开始介绍状态机的时候举了一个用户登录的例子，现在就以继续以这个场景为背景，来看看开发的视角该做哪些工作。
用时序图体现整体流程
可以用时序图表现出整体的登录流程，这里直接复用原来的那张图，不再重复画了：
时序虽然说是表现整体流程的，但是要画到什么程度，画多少个并没有具体的规定，可以按照项目大小、功能维度自行斟酌或团队约定。只要能真实的表达它对应的业务操作即可！
用状态机体现状态流转
这里的状态机也直接复用以前的，不过要说明的是这里状态节点比时序图中体现出来的操作更多，因为考虑了新用户注册及注销的情况。此处仅仅是做个示例就不再调整了：
用例图表现用户的操作
这里有2个角色：普通用户、管理员。理论上来说，注册时确认邮件的发送、账户的冻结可能都是自动化的（论证/风控系统识别出高危操作）不需要管理员这个角色手动操作，但这里为了突出用例图的作用，都设计出了对应的手动操作功能！
用ER图体现数据库的关联关系
对于一般的业务来说，关系型数据库是必不可少的，这里这里就假设有几个表（RDS类型不限）：t_user用户表、t_send_mail_history邮件发送表，现在用ER图来表示一下这2个表的信息
用类图表示对象之间的关系
系统的设计最终效果还是要通过代码来体现，在UML设计的过程中与代码最息息相关也是最直接的就是类图。这里采用传统的SpringMVC结构来进行分层：
写在最后
没什么多说的，学习一项技术（工具）最好的时候就是当你开始使用的时候，找到一款合适的工具，从一个最简单的场景用UML设计起来吧！
