一、前言
UML分析、建模与设计 来自现实世界中的概念的抽象描述方法（摘取自《UML面向对象分析、建模与设计（第2版）》）
就我对UML分析与建模技术的认知，最早可追溯至2019年时的学习。也是在正式开发项目前，最后学习的一门设计类知识，我认为这是软件开发者描述业务逻辑的最佳方式。
写这篇博客，我是希望在未来，我的同事、合作者或者是交流人员，能够拥有一定的建模习惯。或者在互相关注之后，能够知道我的编程习惯是怎样的，能够拥有更好的默契和愉快的合作。
二、代码注释与UML语言
（代码注释）
在项目编码过程中，是必不可缺的一个环节，也是工作组中合作交流的关键。在中大型项目中，如果个人的代码、算法、业务处理能力一般，但是注释完善易懂的话，去请教大佬，还是会得到善意的帮助。就算在开发的过程中，遇到了bug，也能快速定位问题出现的位置。
但是大篇大论的语言表达总是苍白无力，一个复杂的算法或者业务逻辑，是很难使用语言（汉语、英语等）去表达的。就算表达出来了，理解这个逻辑也需要花费一定时间。
我举两个例子。
（第一个）甲和乙是室友，甲回到寝室，突然告诉乙：我丢，今天在路上遇到了一个腿长、漂亮（帅气）的女孩（男孩）。这么说乙能够理解，无非就是表达一个身材好、吸人眼球的女孩（男孩）。可以自动将思维带入短视频里的某一个up主或者正能量。
/ * * 实现数据按某个要求排列，并自动将用户爱好优先排列在最上层。（优先级：用户爱好>某个要求) * @参数a （什么意思，什么作用，有没有关键作用）...* @developer [开发者]* @see [相关类/方法]* @since [产品/模块版本]* @deprecated*/public ...（第二个）甲、乙、丙是室友，甲和乙回到寝室，甲对丙说：今天我们两在商业街看到一个小姐姐，身材目测无限接近于黄金比例（0.618）、微胖、事业线惊人。可惜穿搭上有所欠妥，没有完全展示出她的优点，但气质弥补了这一问题（然后又描写气质）。这样表达也确实详细，但是关注点太多，脑海生成出一个这样的人，就比较缓慢。这时乙拿出手机将拍到的照片给丙看，这一切就明朗了（现实生活中可不能这么来，乙的行为是错误的，应该大胆上去加微信，大胆访问空间），而个照片可以看做是UML分析、建模与设计。
/ * * 调用了（方法1）（方法2）能够实现对摄像机内头像的实时捕获，并同步生成什么样的人脸数据，这个数据要进行什么样的操作和导出，才能完成对比* @参数a （什么意思，什么作用，有没有关键作用）* @文件b 数据是什么类型 识别转换的数据排列方式 ....* @developer [开发者]* @see [相关类/方法] [class1.java、class2.java、class.java]* @since [产品/模块版本]* @deprecated*/public ...（UML分析、建模与设计）
一般执行于项目编码之前，是对一个模块（功能）的具体（图像流程）分析与描述。开发过程能否顺利，测试结果能否过关，凭借于UML的设计严谨程度。当然也有一些厉害的、业务逻辑熟练的开发工作者，对于建模只是一张草图而已，甚至建模软件都不用打开，就能完整的开发出一个功能来的，也是非常常见。
就我22年2月份找的那份工作，一个负责金融交接功能模块的小组，全小组就一个人。非常厉害的一位大佬，听说是上海回来，之后回不去了，只好在本地老家就业。在一次聚餐时，因为两个人都吃不了辣（我是因为打了疫苗，大佬是因为习惯了上海的饮食），有幸结识了这位大佬，进行了技术交流。听他说，他处理这套逻辑已经7,8年，兼容不同的开发框架也有五、六种，反正对业务逻辑非常熟悉，全公司就他一个人熟悉金融交接，注释随便写，建模就算了。
如果在我的组里，组长告诉我哪个功能模块出现了bug，需要我去修改一下。注释和建模描述不清，我可能会出于行内礼貌，重新定义一个方法、接口去取代他那个有问题的模块。但如果全是黑黢黢的代码，不好意思，请这位靓仔（靓女）和我进行工作衔接时，注意头上那所剩不多的几根毛的存在意义。当然替换了新方法，有可能回出现连锁反应，导致其他方法出现故障，这个时候还是要尽量去重新定位和观察被取代的代码。贸然将自己的方法交上去，导致了这个问题，一般公司会完完整整的将问题全算你的头上。如果只是重构，问题没有得到解决，可以拖着这位同事来分担火力，一切的一切都是他不写注释、不建模而导致我对这个问题不清楚。
三、开发工作中的UML
根据软件三大生存周期：软件定义时期、软件开发时期和软件维护时期。
UML分析、建模与设计的工作处于软件定义后期和开发前期，分布于项目说明书的需求分析、总体设计、概要设计三个标题中。主要作用是为了用户（领导）能够浅显看懂内部逻辑（拿了工资，帮他实现了这个功能没，一般都是看头看尾看大概）、开发期同事兼容其他功能、维护期维护人员能够快速理解内部逻辑。