别把洋垃圾当宝贝-评InfoQ中国“敏捷……”文章（一）

InfoQ中国发了一篇《敏捷“杀死”统一建模语言？》（https://mp.weixin.qq.com/s/qKcnQ_1IKrEn6tiIO6D9nw），不少同学发给我链接，问我怎么看？

类似的驳斥文章我已经写过很多（见文中给出的各个参考链接），但考虑到InfoQ中国的阅读量，只好再写一篇了。

一、InfoQ中国不应该发这类质量低下的文章

首先要说的是，《敏捷“杀死”统一建模语言？》这篇文章和国外的InfoQ并没有关系。虽然文章是翻译的，但来源并非InfoQ，在infoq.com上搜索UML，并无此文。

这篇文章是InfoQ中国自己找的资源。

InfoQ中国是国内的公司借用了InfoQ的品牌，上面的很多内容和InfoQ没有关系。

这篇文章怎么来的呢？我猜测可能是这样：

隔一段时间发一个“***已死”，割一波反智流量，是某些媒体人士的习惯。

觉得又到了收割流量的时间了，刚发了“低代码是行业毒瘤”，网络上再搜一搜“UML dead”、“UML death”、“UML die”（或者换个丧气的词），找找网上近期的言论，哎，buttondown.email这个网站有一篇帖子，太好了，马上翻译发出来。

内容有没有道理不管，翻译质量怎样不管，先收割流量再说。

只要是老外写的就一定有道理吗？洋垃圾也不少的。InfoQ中国以后发文章还是要谨慎一点。

接下来，我先普及一些基本知识，然后再评点文章内容，最后再说一下我认为的建模（以及UML）起起落落的原因。

二、基本知识：很多人说UML的时候并不知道自己在说什么

软件开发的一个迭代周期中需要思考四个问题：

A-业务建模——定位需要改进的目标组织（人群或机构）以及该组织接下来最需要改进的问题。

B-需求——描述为了改进组织的问题，所引入的信息系统必须具有的表现。

C-分析——提炼为了满足功能需求，所引入的信息系统需要封装的核心域机制。

D-设计——考虑质量需求和设计约束，将核心域机制映射到选定非核心域上实现。

针对这些工作流的思考，就是建模。任何一个软件项目，这些思考都是逃不掉的，也就是说，我们一直在建模，只不过很多人习惯于无意识地做，运气时好时坏，速度时快时慢，有的人能够有意识地做，让汗水不白流。

思考的结果，可以用口头表达，也可以用文本、其他表示法或自造符号来表达。用UML来表达，目前是一种不坏的做法。

如果用UML来表达，推荐的表达方式是：

可以看到，设计模型（叫实现模型也可以）的表达方式目前是文本形式的“源代码”。

当一个人发表言论“UML怎样怎样……”时，

*如果这个人对工作流A、B、C有认识，也掌握了相关的技能，只不过认为其他表示法（ArchiMate、BPMN或者自己造了一个表示法）比UML表示法要好，那么他的言论里的“UML”可能确实是UML，值得一听。

*如果这个人对工作流A、B、C根本没有基本概念的情况下胡乱评点，那么他的言论里的“UML”就可能什么含义都有，这些言论多半荒谬，不值得一听。

************

有一些人只有D的知识，在没有学习和掌握A、B、C的情况下，先高喊“敏捷”之类的口号砸烂一切，后来发现客观规律绕不过去，又想偷偷捡起自己砸烂的A、B、C，但又不好好学习其中的知识，只是从D来臆想A、B、C，就会得到各种伪创新，然后用“敏捷”包装起来到处宣传。很多“敏捷实践”实际上就是只掌握D的人怎么爽怎么来的实践。

现在“敏捷”没有那么时髦了，“领域驱动设计”又成了伪创新的重灾区。

************

如果您不认可我的观点，那么不妨做一做下面的题目，做到至少80%的正确率后，再回头看看您的观点是否有变化？如果全做对了，即使您依然不认可我的观点，那么您的观点也非常值得倾听。

https://mp.weixin.qq.com/s/Xj9YoZzuR-4loMXwBubEag

https://mp.weixin.qq.com/s/GDfIMgdZ8VWWmrNF-axmsw

我相信，一旦付出努力，咬咬牙掌握了更严谨和更高效的方法，是羞于再回头去使用那些打着“敏捷”或“领域驱动设计”旗号的伪创新的。

三、对文章内容的评点

【原文】

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

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

【评点】

（1）

文中居然说UML被公司高层、商务人士欣然接受，这是不是想得太美了？而且这里刚说完：UML复杂、严谨、高效清晰的沟通，下面的段落怎么又说UML规范化缺失？

倒是这种场景更常见：软件开发人员有时候会拿“涉众不喜欢看我的UML图”当成遮羞布——不是我不想建模，是因为客户不想看，所以我就懒得画了——其实是没有相应的思考能力，画不出来。

UML模型是严谨的，用于在软件开发人员之间沟通，不是用来和涉众沟通的。

和涉众沟通的介质是各种涉众能接受的、比较随意的“视图”。

面对大领导，我们可以给他放幻灯片交流愿景；一线操作工只关心他那一小块工作，我们可以制作界面原型和他交流；有的涉众根本不喜欢看任何东西，我们还可以通过“谈话”这种视图和他交流。涉众连谈话都不乐意，我们也可以通过观察涉众来获取素材。

就像医院里，给病人拍CT主要目的不是给病人看，而是医疗团队内部使用。当然，病人乐意拿CT让医生教他一点影像知识，医生拿着CT和他多交流几句也无妨。但是不能这样：病人懒得看或者看不懂自己的CT，医生就不给拍了，病人喜欢看或者看得懂CT，医生就多拍几张。

（2）

也许作者说的高层指的是软件开发组织的高层（例如研发总监、CTO……）？

这个有可能欣然接受，但形势也不会太乐观。

即使是在“软件开发组织”里，愿意并胜任建模工作的总是少数人。

大多数软件开发人员，并不愿意主动去做建模的思考，这是人的本性使然——想那么多干什么，浑水摸鱼就好了。要训练出严谨的建模思维，也有一定的门槛，很多软件开发人员并不乐意付出精力去跨过门槛。

如果针对软件开发人员发起调查“在公司里推行建模好不好”，预计大多数人会投反对票。

有的时候，连这样的描述我都认为是贴切的：

建模的一切反对者团结起来反对一切建模。

以我传授建模技能20年的经历总结：只有少数有“冠军的心”的软件开发人员，希望自己交付的系统成为所在领域的冠军，才会有质量的诉求，从而带来提升建模技能的渴望，最终能掌握并应用建模技能。

啰嗦了这么多，我要表达的意思是，会建模的人少是正常现象。

但是，我更要表达的意思是，会建模的人少不代表学习建模没有价值，答案可能刚好相反。

就拿编码类比。会编码的多吗？可能您觉得会编码的人挺多的，周围的人大多都会。其实从全民来看，会编码的人数占的比例极少，但不能由此推导出“学习编码没用”。相反，正是因为编码有门槛，所以大多数程序员买房可能不容易，衣食无忧还是做得到的。

*********

针对本段落，可以参见我下面的文章：

https://mp.weixin.qq.com/s/7ZlZKWr-98fIXfPEZOGaMA

https://mp.weixin.qq.com/s/khwKP3XokOXzA9HgazHUTg

https://mp.weixin.qq.com/s/DVpw6_uqEX4Bhlz5s6yUiw

https://mp.weixin.qq.com/s/d_XbTGo5Ipo5dMUMMzb26A

https://mp.weixin.qq.com/s/3DP79_J7nNZtAiwcXhs2Zg

https://mp.weixin.qq.com/s/ivZ7ldeJGllGRqmoF3TVAQ

https://mp.weixin.qq.com/s/v39RvOTPa6pnSBJX0OTAIQ

https://mp.weixin.qq.com/s/KrPzuwnUcU-kygvwy4t4SQ

【原文】

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

【评点】

作者在这里说“波及到整个需求工程领域，包括业务分析与设计等等”，但后面段落说的内容和需求工程又没关系，反而大谈面向对象、编程，给出个UML图还是一个类图。

显然，作者并不了解什么叫需求工程，什么叫业务分析与设计（这个是模糊术语，估计作者就是随口拼凑）。

【原文】

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

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

【评点】

遮羞布：迭代、试错。

“迭代”只是底线，不是上限。

再高明的医生，有时也没有把握一个疗程就治好患者，所以要按疗程试试看，但是每一个疗程中，依然要尽力检查、诊断、拟治疗方案。检查、诊断等技能越精湛，所需要的疗程就越少。

如果一名护士被提拔成医生，却没有掌握医生所需的技能，只会打针，不会检查、诊断、拟治疗方案等技能，也不愿意学习，那怎么办呢？索性说：“唉，反正再高明的医生，也不能一个疗程把患者治好，干脆我也别花那么多心思了，拍脑袋开药，先随便给患者打一针看看吧，不好再来！“

甚至，为了自己的地位，护士会有意无意贬低医生所需的技能，发布类似于“医生没啥用，最终打针还是得靠护士来打”的言论，把周围的人的知识限制在自己懂的范围之内。

反复试错来找到正确答案？这傻子都会啊，这就能在竞争中胜出？莫非你爸是李刚，或者普天之下都是你妈？

真是自大成狂的幼稚思维。我见过的一句最自大的宣传敏捷的口号是：如果允许新手一次走两步,他甚至可以击败象棋大师。

你咋不上天呢？

古罗马的奴隶主一边吃瓜，一边欣赏角斗士以命相搏，偶尔有大热门"试错"失败被黑马击杀，那更是赏心悦目。而每一个角斗士却要如履薄冰，每个环节都要考虑周到，担心踏错一步就无法挽回。可悲的是，很多人是角斗士，却偏偏有"我是奴隶主"的错觉。

打麻将，如果只是一两块钱，出牌可能会大大咧咧，如果输了要剁手指，那么，每次出牌前怕是书到有时方恨少，后悔之前没好好练习算牌的技能了。

*********

口号：我们只做最重要的需求，尽快把系统推向市场。

问题来了：怎么知道哪个需求最重要？拍脑袋？

口号：设计要分离变和不变，这样可以减少变更的成本。

问题来了：怎么知道哪些变哪些不变？抓阄？

建模则提供了方法：

业务建模和需求：寻找最值得攻占的大脑、最值得改善的指标、流程中最值得改进的片段、最值得系统提供的用例。

分析和设计：建立反映核心域内涵的模型，分离核心域和非核心域，让系统以最小的代价随着领域规律的变化而变化。

*********

关于更多遮羞布，参见：

https://mp.weixin.qq.com/s/DuD1dUNuM12S6ByR0dkEAw

https://mp.weixin.qq.com/s/fbtP_9ZUfQSYAm9hfvyluQ

 【原文】

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

史前阶段

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

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

【评点】

（1）

Bertrand Meyer没有写过《Business Object Notation》这本书。

此处有误译，原文是说：在他关于Business Object Notation的书中，Bertrand Meyer列出了……”

可惜，原文依然是错的。文章作者说的书，应该是1994年出版的这本书：

这本书不是Bertrand Meyer写的，他只是做了个序。关于BON，书中说：

 顺便说一下，这本书即使是今天也还是可以一看，比许多打着“领域驱动设计”旗号的伪创新要有价值。

（2）

“我忘了是在哪里甚至还看到过“50 多种”竞争方法的结论。”

忘了不会去查一查？这种文章InfoQCn也好意思登出来？

【原文】

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

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

【评点】

CASE 工具的制作成本极高？

据PC Magazine的1990年1月30刊统计，当时已经有超过100家公司提供了将近200款CASE工具，下面图中，被红框圈住的内容说明了工具的数量。 

 【原文】

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

【评点】

没看懂。

OOSE是Jacobson的方法学。上面文字的意思是：OOSE比Booch和Rumbaugh的方法学要好，所以买下来，然后把它放弃（并非译错，原文如此）？这是什么脑洞？

用例、序列图以及RUP就是基于Jacobson的工作，怎么是被“放弃”了呢，也许作者说的放弃就是“统一到UML”的意思吧。

【原文】

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

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

【评点】

关于软件开发方法学、UML和CASE工具，更严谨的历史可以看我写的

https://mp.weixin.qq.com/s/k6rCCCFYb0zCNPCtW23o4A

https://mp.weixin.qq.com/s/fbtP_9ZUfQSYAm9hfvyluQ

https://mp.weixin.qq.com/s/K3QmlgfNxYMS9T08cFp4aw

【原文】

理解问题本身

必须承认的是，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 为什么会‘挂’”在很大程度上是一回事。

【评点】

Martin Fowler也有自己的知识局限，他的说法并不正确。参见：

https://mp.weixin.qq.com/s/F0xKgcrSmbMXlAsJey2ncg

【原文】

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

消亡原因

传统的约束

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

【评点】

（1）

“UML 必须与这三类工具保持向后兼容，这也在起步阶段就埋下了隐患” 纯属胡说。

UML是语言，“语言和工具兼容”说不通，可以说“UML和***表示法兼容”。

UML最初版本就不只是取材于Rational三友方法学的表示法，而是十几种。例如，状态图来自Harel。

UML也没有要“向后兼容”的意思。事实上，UML规范发布之后，之前的工具厂商就纷纷拥抱UML标准，把自己的工具变成UML工具。Rose是Rational的就不用说了，PowerDesigner、Together甚至StarUML（在UML之前就已存在，当时叫Plastic）都有这个转变过程。

（2）就算真的有“UML起步阶段要向后兼容埋下隐患”，这个“隐患”到现在也有20多年了。

信息时代居然有这么给力的隐患，给我来一打！

【原文】

规范化缺失

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

【评点】

（1）作者拿出UML 1.3的图来挑毛病。

UML 1.3是2000年3月发布的，如果这篇文章是2000年写的，那还好说。

写于2021年的文章拿一个2000年的图来挑毛病，结合上面的“隐患”文字，我猜测作者会不会在哪个地方复制了2000年的某段文字。

（2）作者关于该类图的观点是错误的。

这段文字不但翻译得乱七八糟，看了原文也没弄清楚作者到底在说什么。只能猜个大概：

作者可能是说，这个图没有针对后面的设计（或实现）提供指导，大概意思类似于“你这个是多继承，我用Java怎么做嘛，我用数据库怎么保存嘛”。

这是一种常见的误解——认为分析模型要对设计作出指导。同理，有这样误解的人，往往也会认为需求需要对分析作出指导。这也是只有D知识的人臆想ABC的时候常犯的思维颠倒错误。

独立于实现的概念建模（或者时髦一点，叫领域建模）是很重要的。评价这个图的质量如何，标准是它是否准确地描述了领域的内涵，而不是其他。从这一点来看，这个类图还是合格的。

分析描述了一份任何设计都必须履行的契约。图中所讲述的领域知识不依赖于任何实现方式，你可以用任何编程语言、任何存储系统、任何的部署方式来实现，但是，图中描述的领域知识必须得到体现。

不同的实现方式，影响的只是分析到设计的映射套路。

如果不理解以上说法，可以看以下内容：

https://mp.weixin.qq.com/s/fbtP_9ZUfQSYAm9hfvyluQ

【原文】

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

【评点】

UML从1.1到现在的2.5.1，经历了10次更新。

另外，这是建模语言，更新没有编程语言频繁是正常的。

作者用C语言类比，说C89这个那个，我研究不多，就不评价了。

不过既然提到C语言，手边Leon Starr的书“Models to Code”（Apress 2017）里刚好有个类比，可以帮助理解我上面所说的分析和设计关系。

int linearValue (int x, int m, int b)

{

return (m * x) + b ;

}

int y = linearValue(5, 10, -2)

y的值是多少？48，对吧？你怎么敢这样说，你用VC还是GCC什么的编译了吗，在各个平台上都运行过了吗？

不需要，按照C的语法，大脑里一过（也算是人肉编译器吧），结果就是48，至于具体某个编译器怎么做的，不关它的事。

【原文】

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

【评点】

呵呵，“我有一个朋友”。

收购并很快停用？这是吃饱了撑的？

更贴近事实的应该是：Rational高层觉得像Rational Rose这样的独立建模工具的运行形态，不如走另一条路线的、和IDE集成的Rational XDE有发展前途，决定接下来的建模工具新版本朝这个方向走，于是重新做了一款基于Eclipse的UML建模工具，叫Rational Software Architect，不再沿用Rational Rose的名称，原来的Rational Rose也不再更新。

Rational Software Architect目前版本是9.7.0。

我的看法是：Rational的这个决定是错误的，RSA界面风格大变，使得原有的Rose用户（包括我）纷纷转向用起来更像Rose的另一款UML建模工具，Enterprise Architect（EA）。

【原文】

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

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

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

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

【评点】

参见以下链接：

https://mp.weixin.qq.com/s/PhOATGSauzjlu7UC1v234w

 *UMLChina整理的UML工具一览，可以按各种条件搜索。

http://www.umlchina.com/tools/search.aspx

---

---

---

---

---

---

---

---

---

---