UML怎么就真“挂”了？_语言 & 开发_buttondown.email



 写点什么

“CASE 工具为什么会失败”与“UML 为什么会挂”在很大程度上是一回事。

不久前，Ernesto Garbarino 发表了一篇《UML 是否就这样悄悄地消亡了？》的文章。Garbarino 在使用了 9 年的 UML 后发现，不只自己，同行及其咨询过的《财富》500 强公司都不再使用 UML 了。他认为敏捷化给了 UML 致命地打击，是导致 UML“死亡”的真正元凶。

我知道很多软件项目都在市场竞争中被淘汰，但 UML 不是。它没有因太复杂、严谨而被公司高层所嫌弃，相反，他们很喜欢用少数几种新的约定符号完成高效清晰的沟通。IT 人士将 UML 摆上台面，商务人士则欣然接受。

所以问题的答案是，死掉的并不是 UML 本身——它只是连带受害者。这场“大屠杀”波及到整个需求工程领域，包括业务分析与设计等等。下杀手的是“敏捷化”，正是它抹杀掉了 UML 以及关于它的一切。

Garbarino 认为，错不在 UML，人们只是放弃了业务分析与正式规范的僵化束缚：

数字化转型专家建议我们直接将方案部署在生产环境中，由客户用行动向我们展示实际需求，而非预先做出假设。在这样一套流程下，我们通过反复试错来找到正确答案。这就是所谓快速失败、快速迭代的新方法。

但现实世界很复杂，答案往往没那么简单粗暴。我在几年前曾想写篇关于 UML 诞生、快速发展到退出公众视野的文章。为此，我采访了不少 UML 知名人士，包括 Grady Booch、Bertrand Meyer 和 Ed Seidewitz 等等。但遗憾的是，UML 项目最终走向了消亡，所有的准备都打了水漂。但我仍记得种种细节，所以我可以负责任地说：事情绝不只是“死于敏捷化”那么简单。当然，这已经过去四年了，有些细节我可能确实记错了，欢迎大家边看边监督。

史前阶段

UML 的诞生，源于两大重要趋势。

首先是“方法大战”。在 Smalltalk 与 C++ 成为主流面向对象程序设计（OOP）后，人们开始大肆宣传一种用于设计软件系统的终极流程。但语言统一的过程无疑是混乱且“血腥”，一直有不同的设计方法涌现。Eiffel 语言和按契约设计（Design by Contract）思想发明者 Bertrand Meyer 在他写的《Business Object Notation》一书中列出了 26 种竞争方法，我忘了是在哪里甚至还看到过“50 多种”竞争方法的结论。

几乎在同一时期，人们还开发出第一款计算机辅助软件工程（CASE）工具。如今，CASE 只是个“小角色”，但当初它是有潜力拓展出巨大产业的，甚至有人认为其规模将远超 CAD 或者 IDE。

CASE 工具与方法论结合，不仅为开发者，也为测试人员、项目经理乃至客户提供了一种整体性的软件创建方法。然而，CASE 工具的制作成本极高，而且必须针对特定设计方案进行定制，因此随着时间的推移，CASE 供应商只能从以下三种方式中选择其中一个：

Grady Booch 的 Object-Oriented Analysis and Design（碸对象分析与设计，OOAD）
Ivar Jacobson 的 Object-Oriented Software Engineering（面向对象软件工程，OOSE）
James Rumbaugh 的 Object Modeling Technique（对象建模技术，OMT）

Rational 公司有不少的 CASE 产品组合，而且大部分收入来自 Ada 相关工具。Grady Booch 是 Rational 公司的员工，Booch 与 Rumbaugh 是好朋友，所以两个人的思路在充分交流之后逐渐趋于一致。所以，两人也开始尝试明确协作，将 CASE 供应商需要支持的方法从三种缩减成两种。之后，随着其中一种方法优于另外两种，他们买下了 Jacobson 的咨询公司，逐步放弃了面向对象软件工程（OOSE）。

OOSE、OOAD 与 OMT 都是代表了整体方法，涵盖到符号表示和过程。由于消除符号差异要比处理差异更容易，所以 Rational 将联合体拆分成了两个部分。

统一建模语言（UML）于 1996 年问世，并被移交给对象管理小组（OMG），Rational Unified Process 则在一年之后诞生。UML 在接下来的十年中大受欢迎，并从 2004 年开始受到人们的普遍关注。但时间飞逝，转眼就来到“UML 已死”的时代——这中间到底发生了什么？

理解问题本身

必须承认的是，UML 怎么“挂掉”这个问题是有歧义的。

首先，我们说的“挂掉”究竟指什么。程序员们常用这个词来代表某种事物的“相对市场份额下降”，而非“绝对市场份额下降”。如今，仍有不少意见领袖抱怨开发者不够了解底层系统，但与 30 年前相比，参与内核开发的开发者数量已经大幅增加。接触内核开发的群体在全体开发者中确实比例很低。同理可知，UML 也许正经历类似的“既增长、又消亡”过程，具体要看大家选择衡量的标准。所以，我们不妨假设 UML 处于“快挂了”的状态，再进一步展开讨论。

另一个分歧是，我们说的 UML 究竟是什么。首先，UML 包含十几种不同的图类型，目前仍有不少人在使用顺序图。其次，人们使用 UML 图的方式也是多种多样。UML 与敏捷世界中的杰出人物 Martin Fowler 同样确定出三种基本用例：草图、蓝图与编程。

这两点很容易解释。UML 的编程用例在早期发展阶段就已经消亡，大多数 UML 支持者自己也认为这东西没什么用。UML 草图的命运也不容乐观，而且人们发现草图符号与 UML 标准很难保持同步，逐渐演变出多种相互间难以理解的“方言”。所以，除非有人刻意保持统一，否则两者基本毫不相干。

剩下的 UML 蓝图则是最复杂的用例。据我的了解，它应该也是 Rational 公司最重视的成果。

UML 蓝图与 UML 草图之间有两个差异。首先，UML 的本意是先让设计人员写蓝图，再由程序员实现蓝图，但二者对应了不同的技能与工具。其次，UML 蓝图集成有多种不同的图类型，我们不仅需要编写类图与需求图，还需要用实现需求图编写的工具，即需要在蓝图设计当中使用 CASE 工具。因此，UML 的人气往往与 CASE 工具的流行度密切相关。也正因为如此，我觉得“CASE 工具为什么会失败”与“UML 为什么会‘挂’”在很大程度上是一回事。

下面咱们开始探究 UML 悲惨命运的根源。我得强调，我只能根据自己仅有的记忆做出还原和推测，所以给出的理由也许不那么准确，仅供大家参考。

消亡原因

传统的约束

在方法大战爆发、CASE 工具兴起之后，UML 可以说是应运而生。市场上已经出现大量基于 OOAD、OOSA 以及 OMT 的 CASE 工具，而 UML 必须与这三类工具保持向后兼容，这也在起步阶段就埋下了隐患。如果能够果断放弃这些，UML 也许可以更简单地实现概念统一。

规范化缺失

UML 的规范太过松散，在图的交互方式及关键字实际含义等方面都模糊不清。比如，UML 1.3 在类图中给出了“泛化”箭头示例，其中 Sailboat 是 WindPoweredVehicle 与 WaterVehicle 的专业化表达，而后两者又是 Vehicle 的专业化表达。但从设计角度来看这些的意义是什么呢？我们有必要用专门的方式来实现吗？这种细化关系有什么特别？总之，在具体操作中，一直存在着用户决定关系含义、CASE 供应商决定实现功能，但两者长期存在倒错的问题。

看到这里，很多朋友可能想到了 C 语言。没错，当初的 C89 之所以要包含大量未定义及用户定义行为，完全是为了容纳大量彼此冲突的编译器。OMG（UML 1.0 后版本的维护者）也面临着类似的困境。他们无法对 UML 标准做出任何更新，否则很可能破坏现有供应商的决策，这自然拖慢了 UML 的发展速度，也大大增加了各个版本的修订复杂性。

我有一个从朋友那里听来的“八卦”。当时，虽然 OMG 被束缚住了手脚，但还有一定为“更大利益”做出改变的空间。我个人怀疑作为 UML 的原始开发商以及规模最大的 CASE 工具供应商之一，Rational 其实很想对旧版软件做出更新。但是，IBM 随后在 2003 年收购了 Rational，并很快停用了 Rational 的 UML 工具，转而销售专有 CASE 工具 Rational Software Architect。由于不打算继续在 Rational 遗留项目上投入精力，IBM 开始阻止一切可能对 UML 兼容性造成影响的更新，最终导致项目彻底停滞。

而 2003 年也正是 UML 市场战胜率开始下降的开端，我觉得这应该不是纯粹的巧合。现在，我们要探讨 UML 的具体问题了。

UML 中包含了非常多种不同的图和规则，导致产品太过复杂。这对任何人都没有好处，因为 UML 变得越来越难学，配套开发工具的设计也陷入困境。

虽然看似会画几张图就能上手，但背后的规范体系并不简单，所有工具都必须全面完整。所以，除了“泛化图”外，其他稍稍复杂一点的内容都需要庞大的团队和充裕的资金才有可能实现，这就限制了生态系统的增长速度。最终，开源社区也拿不出丰富的 CASE 工具，用户实际使用的工具就更少了。

更关键的是，就连商业 CASE 工具也啃不下这块硬骨头。表示方法越复杂，开发工具的难度就越大，没有了令人振奋的强大 CASE 工具支撑，UML 自然陷入孤掌难鸣的境地。

没有文本格式

这是工具体系方面的另一重大缺失。没有文本格式导致我们无法在自己熟悉的文本编辑器中编辑 UML 图、无法执行 grep 编写、也无法编写自己的定制化解析器。

也有人曾尝试为 UML 提供文本表示形式，例如 PlantUML 或者 Mermaid 等，但它们全都面临着两大难题。首先，这种表示是单向的，我们无法将现有图转换为文本形式；第二个就是所谓的图形化问题，文本格式在表现视觉布局方面效果极差。这个问题可以具体分为三个方面：1）系统非常笨拙，不如直接使用图形编辑器；2）必须调整设置才能让布局引擎更为流畅；3）需要编写 TikZ。

根本没有数据格式

这个问题看似与“没有文本格式”类似，但本质上截然不同：UML 只有视觉表示这唯一的格式，令 UML 的导入与导出几乎无法实现。一旦开始使用具体工具，结果就会被限制在此种工具之内，这明显又制约了生态系统的发展：无法制作独立的 UML 工具、验证品节，也无法开发出任何 CASE 工具扩展。

OMG 方面也曾尝试通过 XMI（一种用于 UML 的 XML 格式）纠正这个问题，但据说效果一直不好，而且各个 XMI 与 UML 版本都不具备向后兼容能力，工作根本推进不下去。

无法逆向

一部分工具可能会采用某些 UML 规范并生成代码，也有一些工具可以根据某些代码对图进行逆向操作，但这两种用例的效果都不太好。因此，与蓝图类似，UML 与代码终将不可避免地陷入无法同步的状况。

在采访 UML 用户时，我最常听到的抱怨就是“UML 太烂了，根本没法用。”

文化变革

最后的这一点，我开始跟开头文章作者的观念趋于相同。文化变革确实给了 UML 沉重一击，但我认为其中的原因不是那么简单。

CASE 工具的作用仅限于大型软件项目，这是因为只有大型软件项目才有很多人长时间从事相同的工作。这类项目的“官僚化”程度也更高。虽然我们如今都认同敏捷化正全面取代以往占主导地位的瀑布式开发方式，但那个时候大多数开发者都在遵循“事来忙一阵、亡羊再补牢”的工作思路。因此，CASE 工具最初是由企业在内部强制要求使用的。文章作者也提到，真正喜欢 UML 的其实是企业高管、而非程序员自己。

上世纪九十年代，程序员们主要在传统企业工作，因此当时的技术趋势也主要反映传统企业管理层的喜好。虽然也正是他们的决策让 UML 有了一时的辉煌，但近二十年过去了，软件文化逐渐向大型科技企业与初创公司倾斜，从历史上看这两者都不属于 CASE 供应商的预设目标受众。这样的变化，也让 CASE 在市场上的地位一降再降。