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

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。

图1-10 自编图形示例

其实，抛弃标准符号和建模工具带来的便利，用绘图工具或幻灯片工具画出这样的图，所花费的时间往往还要更多。但是，有意思的是，有的人画这样的图，还以“敏捷”为理由。

注意，上面说的只是“看起来比较精致”，其实内容还是很粗陋的，仅仅是把一些动词、名词的罗列成一个个形状，各个形状之间的关系基本没有，读者可以把图1-10和图1-8、图1-9对比。

1.3.2.4 挑破乱七八糟图的脓包

我们甚至可以“抛开事实（具体领域知识）不谈”，仅从“一致性”这一点入手，就可以挑破这种自编“乱七八糟图”的脓包。

自编“乱七八糟图”的画图者，很可能并没有归纳过各种形状的定义，只是凭感觉随意使用，或者即使归纳了，也不会像标准语言这么严谨，所以，大概率会产生“不一致”的问题。

我们就以图1-10为例。

图1-10中，同样被称为“平台”的东西，有着不同的形状，如图1-11。

图1-11 图1-10的不一致示例1

我们再来看中间这些方框，如图1-12。

图1-12 图1-10的不一致示例2

先看图1-12的最顶上3个方框，它们形状一样，长度一样，但有的叫“层”，有的叫“模型”，有的叫“队列”，这些概念可不是一个级别的。

（可能的辩解）也许在颜色中暗示？

再来看方框里的命名。最上面4行的命名，基本上都是“名词+动词+名词”结构，例如“消费信贷+统一前置+层”、“额度+管控+模型”，最下面2行的方框，命名是“名词+动词”结构，例如“消费业务+管理”、“流程+控制”。

（可能的辩解）你没脑子吗，自己脑补一个尾巴不行吗，“……模型”、“……层”、“……功能”、“……队列”、“……AI赋能领域驱动设计革命性创新微服务功能模块组件分布式大数据数智化平台”。

还有，名称同样是“模型”，颜色也有多种……

读者可以尝试从“一致性”着手，看看身边的同事画的“乱七八糟图”有没有这方面的问题。

可能有人会问：难道用UML来画就没有这个问题吗？

有的，例如，建模人员故意往用例的圈圈里乱填东西，有的填名词，有的填动词，有的填形容词，但这是违反UML相关的规范或指南的，其他人可以看出问题，批评和纠正。刚才说的情况是没有规范或规范模糊，这两者是不一样的。

用法律类比：精确严谨的法律条文并不能保证没有人违法，但至少大家有共识，什么是违法，什么不是。而另一种情况则可能是，孪生兄弟张三和张四做了同样的事情，张三违法，张四不违法，理由？不知道。