灵敏“杀死”同一建模语言？

熊猫鱼

原标题：灵敏“杀死”同一建模语言？

泉源 | buttondown.email

译者 | 核子可乐

筹谋 | Tina

“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 在市场上的职位一降再降。

UML 之后

在开头提到的文章中，作者 Garbarino 提出了一个题目：假如 UML 没有了，我们将利用什么?

固然有些人利用 C4 之类的轻量级建模技能，但现在主流的应该照旧 masala 图。为什么要用 masala？Garbarino 以为是由于它机动多变、可以或许一次性涵盖多个维度、既涉及布局又涉及举动、既表现逻辑层面又贯通物理层面，很像是 4+1 架构模子视图的大杂烩产物。

Masala 图示例，泉源: Red Hat

如今生存和财政所依靠的数百万个体系，完满是在 masala 图表的背后计划、资助和实行的，通常除了一堆史诗和用户故事之外没有更多的附属品。不外在特殊严谨的业务体系，如银行抵押体系并不会利用潦草的马萨拉图。

不外，在 Garbarino 看来，马萨拉图也有作用。masala 图本质上并不是规范，更多的是一种情绪共鸣的载体。根据 Marie Kondo 提出的原则，masala 图的焦点目的，是在长处相干者心中激起认同与积极感情。能做到这一点的，就是好 masala 图。

延伸阅读：

http://buttondown.email/hillelwayne/archive/why-uml-really-died/

http://garba.org/posts/2021/uml/

2021年，薪酬最高的5种编程语言

“行业毒瘤”低代码

没有人真的想摸鱼，对开辟者来说，企业的“致命”吸引力是什么？

闲鱼正在静静放弃Flutter吗？

十年三次庞大架构升级，微博应对“极度热门”的进阶之路

InfoQ 读者交换群上线啦！各位小同伴可以扫描下方二维码，添加 InfoQ 小助手，复兴关键字“进群”申请入群。复兴“资料”，获取资料包传送门，注册 InfoQ 网站后，可以恣意领取一门极客时间课程，免费滴！各人可以和 InfoQ 读者一起各抒己见，和编辑们零间隔打仗，超值的技能礼包等你领取，另有超值运动等你到场，快来参加我们吧！

点个在看少个 bug