《软件方法》2023版第1章（08）使用UML的理由，挑破乱七八糟图的脓包

news2025/1/11 16:46:06

DDD领域驱动设计批评文集

做强化自测题获得“软件方法建模师”称号

《软件方法》各章合集

1.3 UML

1.3.2 使用UML的理由

在开发团队中，不乏刻意排斥UML的人。这些人如果只是不使用UML，改为使用其他标准的图形表示法（如BPMN），那倒没有什么好说的——但仔细观察可以发现，绝大多数情况下并非如此，这些人要么使用自编的“图形表示法”，要么使用文本，甚至有的人只强调“口头交流”。

当然，通过UML、自编图形、文本、语音等形式都可以交流软件开发中的各种逻辑，但背后的效率是不一样的。

1.3.2.1 听觉 vs. 视觉

回忆一下我们在学生时代做听力题和阅读理解题的过程，就可以体会到，相对于听觉，视觉传递信息的效率更高，而且可以传递更复杂的信息。正常情况下，把模型表达成视觉信息，不管是文本还是图形，比起语音信息来说是更好的选择。非正常情况，视觉无法使用的时候，例如开车或者累得眼睛睁不开，这时用语音来见缝插针，通过听觉利（zhà）用（gān）建模人员的生产力，也不是不可以。

如果有人以“敏捷”为理由，特别推崇“口头交流”，排斥文档或图形，很可能是遮羞布，背后的脓包是此人没有能力剖析复杂逻辑，试图通过这种方式来遮掩。

有的开发团队动不动就开会，你一嘴我一嘴，场面看起来热热闹闹，其实沟通的效果不好，更谈不上思考的深度和知识的沉淀。对比一下街坊老大爷下象棋的热闹和职业棋手比赛时的沉静就知道了。

1.3.2.2 文本 vs. 图形

相对于只有自上而下顺序的文本（包括自然语言文本和编程语言文本），能够朝四个方向扩展的平面图形（如果有三维模型就更好了）更容易让建模人员看出领域概念之间的联系。例如，图1-8和图1-9的内容，如果没有图形的帮助，通过文本一行一行地构造和阅读模型，人脑的负担非常重。

图1-8 餐饮领域的类图

图1-9 计算器的状态机图，摘自Practical UML Statecharts in C/C++[Samek 2008]

说到这里，又不可避免地要提醒，故意选择文本的形式来表达领域知识，有可能也是一种遮羞布。图1-8和1-9的内容如果用文本表达，可能会得到很多页文本——这就有了理由：因为工作量太大了，所以很多地方无法做深入的思考，可以原谅！

1.3.2.3 自编图形 vs. 标准图形

事实上，纯口头交流甚至纯文本交流是很少见的。除非要交流的问题极其简单或者其他同事对这样的人极其容忍，否则他至少也得随意画几张“草图”来传达自己的意思——自编的图形才是比例最大的存在。

这样的人之所以用自编的图形，往往并不是因为他看出了UML有哪些不足，然后用自己的表示法弥补了这些不足，而是要遮掩背后的一些脓包。

脓包一：利益绑架

项目中，有人画了张自编的图形，然后往往会伴随这样的招呼，“来，我给大家讲讲！”。这意味着项目要依赖于“我”头脑中的隐式知识——要是“我”不给大家“讲讲”，大家就不理解“我”画的图的意思，项目就玩不转了。于是，“我”在团队里的地位就提高了，大家得哄着“我”捧着“我”，领导不敢轻易开掉“我”，“我”离职领导还要挽留。这在有一定资历、但又不对项目的成败承担首要责任的“高手”身上表现得更明显。

★Tips：开发人员让我看他的模型时，如果开口说“我先来给你讲讲”，我都会拦住，“如果还需要你先讲讲，说明你所想的没有体现在模型中”。

脓包二：遮羞

因为符号是“我”自创的，所以这个图的解释权归“我”所有。如果有其他同事质疑图上什么地方画得不对，“我”就有了充分的躲闪空间——“你理解错了，这个图形不是你以为的那个意思。你以为我画的是鹿，其实这是马，在我的规范里面，马就是鹿的意思，鹿就是马的意思”。

如果使用了标准的表示法，例如用UML画了一个状态机图，其他人就有得说了，“好像手册上不是这样说的”，“我看那个书上不是这样说的”，这不就尴尬了嘛。

自编图形未必是看起来十分简陋的白板草图，也有看起来比较精致的，例如，来自某项目的图1-10。