【UML分析、建模与设计】我在工作时遇到UML

一、前言

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
【UML分析、建模与设计】我在工作时遇到UML

三、开发工作中的UML

根据软件三大生存周期:软件定义时期、软件开发时期和软件维护时期。

UML分析、建模与设计的工作处于软件定义后期和开发前期,分布于项目说明书的需求分析、总体设计、概要设计三个标题中。主要作用是为了用户(领导)能够浅显看懂内部逻辑(拿了工资,帮他实现了这个功能没,一般都是看头看尾看大概)、开发期同事兼容其他功能、维护期维护人员能够快速理解内部逻辑。

Original: https://www.cnblogs.com/Xu-pq/p/16658575.html
Author: Create丶言午
Title: 【UML分析、建模与设计】我在工作时遇到UML

原创文章受到原创版权保护。转载请注明出处:https://www.johngo689.com/803330/

转载文章受原作者版权保护。转载请注明原作者出处!

(0)

大家都在看

亲爱的 Coder【最近整理,可免费获取】👉 最新必读书单  | 👏 面试题下载  | 🌎 免费的AI知识星球