互联网上有一篇名为“UML就这么悄悄死掉了吗？”帖子，文章中Ernesto Garbarino说，UML被降低标准的程序员所杀死：“敏捷是刺客，而用户故事是她致命的、有毒的箭头。” 如果本新闻稿有一个主题，那就是我们不应该相信简单的答案。现实世界很复杂。
碰巧的是，几年前，我正计划编写UML的历史：它来自何处，为何如此流行如此之快，为什么它死了等等。作为其中的一部分，我采访了许多UML的知名人士。早期包括Grady Booch，Bertrand Meyer和Ed Seidewitz。现在我仍然记得一点一滴，足以自信地说，这个故事比“敏捷做到这一点”要复杂得多。免责声明，我的记忆力和四年前我放弃的一个项目的字迹模糊不清，所以我可能弄错了一些细节。
史前史
UML产生了两个重要的趋势。首先是“方法大战”。在Smalltalk和C ++成为主流的OOP之后，人们真正大量宣传并最终创建用于设计软件系统的正式统一的流程。这引发了不同设计方法的爆炸式增长。Bertrand Meyer在他的《 Business Object Notation》一书中列出了26种竞争方法。我记得阅读过列出50多个文档，但似乎无法再次找到它们，因此可能是错误的记忆。
大约在同一时间，人们还制作了第一个计算机辅助软件工程（CASE）工具。现在，CASE只是一个脚注，但在当时是一个巨大的行业，预计将比CAD或IDE大得多。CASE工具与方法集成在一起，不仅为开发人员，而且为测试人员，项目经理和客户提供了一种整体的软件创建方法。但是，制作CASE工具非常昂贵，并且必须针对特定的设计方法进行定制。随着时间的流逝，CASE供应商选择了以下三个：
- Grady Booch的面向对象的分析和设计
- Ivar Jacobson的面向对象软件工程
- 詹姆斯·朗博（James Rumbaugh）的对象建模技术
格雷迪·布奇（Grady Booch）为Rational效力，后者也有大量的CASE产品，且他们大部分的收入都来自Ada工具。Booch还和Rumbaugh是私人朋友，随着时间的流逝，他们的想法趋于一致。在此之后，一致的想法给他们施加了很大的驱动力，要求他们进行明确的协作，以便CASE供应商仅支持两种方法，而不是三种。然后，由于一种方法优于两种方法，他们购买了Jacobson的咨询公司，并逐步淘汰了OOSE。
OOSE，OOAD和OMT是整体方法，涵盖了表示法和过程。消除符号差异要比处理差异更容易，因此Rational将统一分为两部分。统一建模语言于1996年问世，并移交给对象管理小组（OMG），而Rational Unified Process则于1997年问世。UML在大约十年中被证明非常受欢迎，并且大约在2004年开始引起人们的广泛关注，直到今天，也就是我们发布“ UML死了吗？”之类的文章时，那么为什么UML死了？
这意味着什么？
这个问题有两个歧义。首先是我们所说的“死”。程序员通常使用“死亡”来表示“相对市场份额的下降”，而不是绝对市场份额。许多意见领袖Thought Leaderz抱怨几乎没有开发人员会真正了解底层系统，但是与30年前相比，内核黑客总数有所增加，但这些黑客数量只是占用所有程序员数量中较低的一部分。
这意味着UML可以同时增长和“消亡”，具体取决于您使用的度量标准。现在，我假设UML无疑是“垂死中”。
另一个歧义是我们所说的UML。首先，UML包含十几种不同的图类型。我仍然看到人们经常使用顺序图。其次，人们使用UML图的方式有很多。UML和敏捷领域的杰出人物Martin Fowler ，确定三种用途：草绘，蓝图和编程。
以UML编程的方式在婴儿期就死了，因为即使UML的大多数支持者也认为这是一个可怕的想法。以UML进行需求快速捕捉（速写）却没有死，只是类似一种水上漂流状态而已。
人们使用非正式草图符号与UML标准保持同步，因此随着时间的流逝，它逐渐演变为多种相互难以理解的方言。所以我们不会看到在不同公司中的两个团队，一个在加利福尼亚，另一个在纽约，使用相同的符号，除非有人故意使它们保持同步。
这使UML蓝图成为最复杂的情况。据我了解，它也是Rational最想要的一种。作为蓝图的UML和作为草图的UML之间有两个相关的区别。
首先，他们目的是让设计人员编写蓝图，并由程序员实施蓝图。这意味着不同的技能和不同的工具。其次，UML-as-blueprint集成了不同的图类型。您不仅要编写一个类图和一个需求图，还要为实现了需求图的类编写一个类图。这意味着使用CASE工具进行蓝图。
因此，UML的下降通常与CASE工具的下降联系在一起。 这意味着“为什么CASE工具会失败”与为什么UML蓝图“会死”一样有趣。
UML将死的原因
在方法战和CASE工具兴起之后，UML出现了。市场上已经有大量用于OOAD，OOSA和OMT的CASE工具，而UML必须与这三个工具都向后兼容。从一开始就增加了很多摩擦。如果UML不必与传统供应商打交道，它本来可以更简单并且在概念上更加统一。
- 缺乏形式化
UML留下了许多未指定的内容，例如图表交互的方式以及许多关键字的实际含义。UML 1.3在类图中给出了“generalization”箭头的示例:
其中Sailboat(帆船)是WindPoweredVehicle（风能驱动运输工具）和WaterVehicle（水驱动运输工具）的specializations ，它们都是Vehicle（运输工具）的specializations 。从设计角度来看，这实际上意味着什么？我们是否应该使用继承以特定方式实现它？这与细化关系（efinement relation）有何不同？在实践中，用户可以决定这些关系的含义，而CASE供应商可以决定要实现的功能。
这可能使您想起C语言：C89具有如此多的未定义和用户定义的行为的原因是，它需要容纳所有冲突的编译器。OMG（1.0版后UML的维护者）也有同样的问题。他们无法对UML标准进行任何更新，以免破坏现有的供应商决策，从而进一步减慢了UML的开发速度，并增加了每个修订的复杂性。
- IBM公司
这是我从一位外围人那里得到的八卦。当时，虽然OMG受现有供应商差异的约束，但他们仍有一定的余地来为“更大的利益”做出重大改变。我怀疑Rational作为UML的原始开发者和最大的CASE工具供应商之一，Rational特别愿意更新其旧版软件。但是后来IBM在2003年收购了Rational，他们很快就停产了Rational的UML工具，并开始销售专有的CASE工具Rational Software Architect。因为他们不想继续发展传统的Rational项目，他们封锁了甚至任何UML变化轻微不相容的，UML作为一个整体停滞不前。
当UML的市场占有率开始下降时，2003年也差不多。我不认为这两件事是巧合。
- 太复杂
现在，我们要探讨UML的特定问题。UML包含许多不同的图和规则，导致最终产品非常复杂。每个人都为此感到难过，这使学习UML变得多么困难。这也使开发工具变得困难。您只需要了解几张图就可以逃脱，但是在整个规范中，任何工具都必须是全面的。如果您想构建比“生成图”更复杂的内容，则需要一个庞大的团队和大量资金，这限制了您可以实际增长生态系统的数量。开源世界并没有大量的CASE工具，而您获得的工具却很薄弱。
这并不是说商用CASE工具可以创造奇迹。您的表示法越复杂，为其开发任何工具的难度就越大。 如果CASE工具能够完成令人兴奋的创新工作，那么UML的使用时间可能会显着延长，但是事实并非如此。
- 无文字格式
这是对工具的又一拖累。这意味着您无法在自己喜欢的文本编辑器中编辑UML图表，也无法对其进行grep编写，也无法编写自己的定制解析器等等。
已经尝试过为UML创建文本表示形式，例如PlantUML或Mermaid，但是这些遇到了两个问题。首先，它们只是单向的：您不能将现有图转换为文本形式。第二个问题是我所说的Graphviz问题：文本格式在表示视觉布局方面很糟糕。在最好的你已经有了一个繁琐的系统，该系统比使用一个图形编辑器显著恶化。
- 完全没有数据格式
这使得导入和导出UML基本上是不可能的。一旦开始使用工具，就会被该工具所困扰。在明显的问题中，这又是生态系统的杀手。您无法制作独立的UML工具，验证器或必须作为CASE工具扩展运行的任何东西。OMG试图通过XMI（一种UML的XML格式）来纠正这一问题，但是据信它从来没有那么好过。而且它在XMI和UML版本上都向后不兼容，这使其异常脆弱。
- 无法正向逆向
一些工具可能会从UML规范中生成代码，但是可能会对某些修改后的代码进行逆向工程图处理。没有人能做的很好。就像所有蓝图一样，UML和代码将不可避免地不同步。
- 文化转变
最后一个高度投机的理由。Garbarino在原始文章中说，UML之所以死是因为敏捷接管了文化。我确实认为文化转变在UML的下滑中发挥了作用，但这并不是出于他的想法。
CASE工具仅对大型软件项目有意义，因为在大型软件项目中，很多人长时间从事相同的工作。它也是高度“官僚”的。虽然我们今天认为敏捷取代了占主导地位的瀑布，但在那时，大多数开发人员都是临时性地和渐进式地工作的。由于这些原因，CASE工具最初是由强制内部使用的企业采用的，这似乎是合理的。正如Garbarino自己所说的那样，UML受到了业务人员而不是程序员的喜爱。
传统企业在1990年代是软件的主要雇主，这意味着技术趋势可能反映了他们的兴趣。这将是UML最初兴起的一个很好的解释。但是，在过去的二十年中，软件文化逐渐向大型技术优先的公司和初创公司转移。从历史上看，两者都不是CASE供应商的目标受众。随着时间的流逝，传统企业开始从技术和初创企业那里借鉴学习，反之则相反，这导致CASE在现有领域中的地位逐渐下降。