由Rational Software开发并于1997年被Object Management Group（OMG）用作标准的统一建模语言（UML）旨在标准化软件工程领域中的几种不同的图形符号。
我与UML的恋情始于近十年后，当时我开始宣传UML作为一种弥合IT与业务社区之间鸿沟的语言。我从来没有完全相信过UML作为建模具体软件工件的一种符号的价值。我的目标是使用UML来描述设计中的给定系统所期望的所需结构和行为特性。
对我来说，我无法忍受非正式的Visio流程图，因为会受到含糊不清的困扰。例如，从方框中出现的两个箭头是否表示对流的选择或将流分成两个平行的轨道？同样，指向单个框的两个箭头是否意味着活动在第一个流程到达框后立即开始？是OR，XOR还是AND？你明白我的意思。UML通过引入清晰明确的语义来解决此问题。
我投入UML经历：
- 我主要在2004年至2015年之间使用UML为七个不同的雇主和客户绘制了自己的解决方案的大多数图表。
- 我为两个大客户运行了UML新手训练营（面向业务分析师）。
- 作为硕士论文，我确定了离散数学的关键集合，这些集合是大多数结构和行为UML模型的基础。我什至用Haskell和GraphViz编写了一个工具，将所说的数学可视化回到图形UML。
几年后，大概在2015年左右，我意识到我已经停止使用UML，其余的同行以及我最近咨询过的几乎所有《财富》 500强客户也是如此。发生了什么？
UML并没有因为其复杂性或严谨性而被商业界所杀。与此相反， 商务人士喜欢使用少数几个新的约定符号来进行清晰而明确的沟通的能力。是IT人员将UML带到商务人士桌面上的（就像我以前所做的那样），并在一夜之间把它撤走了。
但并不是UML本身就被杀死了。公平地说，UML只是附带被损害的。真正变革涉及整个需求工程领域，包括业务分析和设计。敏捷是变革者，用户故事是敏捷射出的致命有毒的箭头（双关语意）。
在将用户故事倒入香肠机并在其末尾获得演示的模型（或在DevOps商店中发布功能性产品！），不再需要针对性地进行结构化问题分析了。
在当今勇敢的新世界中，理解直接形成为可用于生产的代码。甚至整个业务实体建模都被敏捷的姊妹学科：领域驱动设计（DDD）所杀死。有界上下文封装了（复杂的）复杂性，因此企业可以通过添加两个披萨团队来进行扩展。雇用BDD并要求其业务团队直接编写Cucumber规范的测试在这里占据上风，但是很少有企业这样做。
今天的范例是，我们无论如何都无法理解这个问题。数字化转型专家告诉我们，我们应该将其部署到生产中，并让用户告诉我们业务需求是什么，而不是自己先提出需求。我们可以多次进行shot直到正确为止。是的，失败很快，而且经常失败。
所以现在您明白了。它与UML的缺点无关。我们只是放弃了业务分析和正式规范，而将其带到下一个问题：如果不用UML，我们将使用什么？
尽管有些人采用了诸如C4之类的轻量级建模技术，但我现在所使用的大多数图（有时是贬义的）都是masala（马萨拉）图。别难过，我这样称呼自己的图表。为什么要马萨拉？因为他们是非正式的；它们一次覆盖多个维度，可能既是结构上的又是行为上的，逻辑上的和物理上的。它们通常是4 + 1建筑模型视图的杂乱无章。
数以百万计的系统是您生活和财务赖以生存的系统，完全是在上述masala图的背面设计、资助和执行的，通常也不会比一堆史诗和用户故事带来更多附加值。
可能你会说：我的银行抵押系统尚未使用您描述的这些可怕的masala模型之一进行设计。
如果您的银行没有运行CICS，并且该解决方案是在去年出售的，则很有可能完全是使用我在谈论的那种masala图完全构思了该解决方案。
Masala图虽然起作用。如果您以它们的本质来接受它们，那么它们可以是美丽的东西。瞧，它们不是规格。他们的目的是唤起情感。根据Marie Kondo的原则，Masala图在每个图的目标利益相关者的心中激发欢乐时，就很有价值。
尽管我不同意敏捷阵营中的朋友，但我对人类的幸福视而不见。我的客户和同行不仅不断要求提供更多的masala图，而且还坚持要求我使它们变得更加masala（我将它们合并到更多的建筑尺寸中！）那么，为什么要这么固执？
UML仍然存在于我的心中，我仍然使用多个维度来构造解决方案，但是今天，我以纯数据/表格方式进行操作。当需要图片展示的时候，我就为可爱的顾客制作了令人愉快的masala图。
黑客新闻网友讨论
我们停止使用UML和其他前期繁重的计划方法的原因是，我们计划的总是错误的。过去，软件项目通常会大大超出预算，交付时间很晚，而且通常还是不能满足客户的需求。事实证明，客户不知道他们想要什么，或者至少不能正确地向业务分析员明确说明。通过尽早交付，我们不仅可以尽早为客户释放价值，而且还可以得到反馈，使我们和客户能够了解他们的需求。而且，事实证明，工程团队比架构师更了解如何开发软件。我们通过将项目分解为（如他所说的）“比萨饼团队”大小的组件来解决复杂性问题，并着重于定义这些组件之间的接口，而不是深入了解信息在代码中如何流动。当然，这会导致其他复杂性，但是它们不会带来大型，整体式设计所具有的同类交付问题。
总而言之，从设计繁琐的方法转向改变了交付方式，为我们的客户创造了价值，并使员工的工作效率更高。
您永远不会像您想象的那样了解自己的问题领域。我总是尝试启动一个新项目，假设一切都会改变。奇怪的是，这种做法往往会产生相同的最终结果是假设什么会改变。如果您不知道需求将如何随着时间变化，那么就没有任何猜测。只需编写第一批需求所需的代码，别无其他。当有新的需求时，将一个抽象层添加到一个简单的系统要容易得多，而当您最终意识到不需要它时，则在以后删除一个抽象层要容易得多。
我认为UML及其类似物在开发人员和团队之间仍然具有巨大的价值，以一种易于理解的方式传达复杂的流程，并促进了共同的理解。
UML的精度过于精细。没人关心语言的大多数特定规则和语法，因为输出被设计为通常由外行听众阅读。与其把时间花费UML制作上，不如重建良好的通用图上的时间更好。
我一直将UML视为进入域的窗口，而不是将其视为代码的先驱。仅使用几个用例图，一些类图，甚至可能是一些序列图，您就可以传达最终系统应该做什么以及人们将如何与之交互。如何实现的细节将从所使用的体系结构中得出。我总是发现即使是很少细节的基本图表（没有字段的类）也非常有用，但是人们不想“浪费时间”而错过了它们。
我曾经在一个软件工程课程中将建模/规范技术分为三类：非形式，伪形式和形式。非形式规范只是发布着一些图表。它们非常有用，生产起来也不耗费大量劳动，因此它们的用途显而易见，但缺乏精确性。形式规范使用某种形式主义来精确定义程序的行为（通常以某些数学启发的符号，例如Z）来定义程序的行为。如果有的话，它非常有用，但是需要大量劳动来生产，没有太多的人可以舒适地阅读或编写这些内容，并且很难满足不断变化的需求。
我认为像UML这样的伪形式表示法的卖点是，它将是“两全其美”的地方，您将从中获得形式规范的大部分好处，而工作量则与非正式规范更相似。相反，我的理想是两全其美。额外的工作不如形式规范那么高，但是您从额外工作中获得一点收益：规范的精确性仍然比非形式规范更接近形式规范。
UML的词汇表提供了有用的共同基础（例如，将元模型和类图与对象图区分开），但是超出最基本的图的花哨的UML功能不仅会很耗时，也不是白板上讨论的重点，且过于繁琐和繁琐。对于详细设计和模型驱动的代码生成的预期用途，从根本上讲是非形式的，而标准化则提供严格的负面价值。
我认为是肯特·贝克（Kent Beck）提出了舌头的银河标记语言（GML）作为他的首选。它具有非常清晰的语义：一个盒子是一个盒子，一个箭头是一个箭头。我个人总是发现，形式主义较少的图表可以更好地进行沟通，因为您可以专注于为思想提供基本框架，而不是淹没仅在某些情况下才有意义的细节。
我会使用从真实代码，数据库模型等生成的图表作为UML替代。
UML的一个问题是，它是为UML工具供应商（IBM狂想曲，Enterprise Architect等）开发的，而在UML 2中更为严重。就像我们有一个编译器供应商设计并推广一种通用编程语言一样，将其声明为一种行业标准，它取代了所有替代方法，并且出于他们的利益而锁定所有程序员。
几年前，我学习了UML，但发现PowerPoint可以很好地解释需要完成的工作。使用PPT绘制草图甚至比Visio都容易得多。
UML之所以死是因为现代软件开发不像设计飞机那样，而是设计一种新型飞机的研究计划。对于程序员而言，他们将要建立的平原是如此之大和复杂，以至于程序员的行为还不完全清楚。因此，要设计一个特定的应用程序，程序员必须在平台上执行一系列实验，以确定将其用于支持应用程序目标的方式。当这些实验完成后，程序员可以花一些时间进行设计，但是在大多数情况下，编程类似于进行研究，然后进行一些设计。对于大型系统，必须有人设计，但是进行这种设计的最佳方法是通过白皮书，以及大规模实验以及可能的模拟和分析。除了为图表建立通用词汇表之外，UML并不是特别有用，该任务可以更简单，更非形式地完成。
我曾经开发过下一代高端OO CASE工具，并且非常擅长于系统分析/设计/等，视觉思维和交流等，我仍将使用专用的UML工具进行最熟悉的静态对象建模。而且，如果该工具很好地支持它们，那么我还将用于状态建模，事件跟踪，Jacobson用例建模以及其他一些UML（例如，活动图，尤其是对象流，而不仅仅是流程图控制）。
我最喜欢的UML：
-序列图：非常适合理解分布式工作流程
-状态图：状态机是很棒的工具。
序列图可能是最有用的UML图。我不知道一种更简单的方法来指定和记录工作流程，无论规模如何（从功能到整个系统）
21亿美元-这是IBM在2003年收购Rational软件的价格。“三个朋友”（Grady Booch，James Rumbaugh和Ivar Jacobson）使用了不同的建模方法，因此决定“统一”。UML的大肆宣传是为了获得采用和进入市场。其他人也陷入了炒作之中，也赚了一些钱，例如马丁·福勒（Martin Fowler），他撰写了UML提要，然后从事敏捷和Thoughtworks的开发。特别要提到现在不知名的Alistair Cockburn，他写了一本书，并围绕用例的混乱做了很多咨询。用今天的语言，Rational Rose将成为“企业建模的Uber”，而UML和RUP将成为护城河。为什么我们不再使用UML？答案是：这三个朋友退出了市场；但是为什么没有什么东西可以代替UML？答案是：不需要。
我认为，随着PlantUML的普及，UML在2010年代重生。PlantUML比大多数早期的UML相关软件更适合用于网络建模。虽然原始UML标准不是专门为表示网络而设计的，但是PlantUML具有内置的网络图类型。而且，PlantUML的可扩展性还可以覆盖许多用例。我以为只要应用一定的强度，就可以为“ masala图”创建PlantUML库。另外，“敏捷”阵营通常会喜欢这种工具。
UML与面向对象的编程紧密相关。在2000年代，OO编程风靡一时，拥有“设计模式”的精巧笔记本被认为是真正的软件工程师的标志。从那时起，OO失去了很多光彩，与之最相关的语言（如Java和C ++）被认为有些笨拙和不酷。即使在实践中，大多数流行的编程语言借用了命令性，OO和功能性特征的组合，函数式编程也成为了讨论的“智能”范式。在您可以创建SQL数据库并使用它的时代，UML也很流行。更多数据库品种的引入使事情变得复杂。除了OO，UML还与非程序员进行的“可视”编程紧密相关。这种范式注定要每三年更新一次，并将其作为下一个大事件推向永恒，直到永恒，我们目前是以最新的无代码趋势看到这一点，但在2000年代与UML相关联。最终，与语言无关的数据格式（如JSON，Thrift和protobufs）开始流行。当我可以制作实际的数据结构然后立即将其作为二进制格式时，为什么还要制作UML图呢？在一定程度上，UML意味着“数据建模”。
在我看来，UML的最大问题之一是它丑陋且不是很直观。有一阵子，我跳上了UML潮流，并开发了许多各种类型的图。事实证明，即使是非常有经验的开发人员也不了解他们，更不用说技术含量较低的人员了。现在，我只用箭头画几个盒子，通常就能传达出信息。UML作为代码生成器也可以用于真正的演示，但实际上，复杂系统的图表比代码更难阅读。
UML只是另一个糟糕的主意，它想降低业务逻辑部分的复杂性，但实际上它是：
- -在业务逻辑上增加了UML的复杂性
- -在“乐高乐园”（UML规范需要执行的代码块）上增加了过多的过度设计和复杂性
- -在编码部分增加了巨大的复杂性（开发人员突然不再看到整个流程，不仅犯了愚蠢的错误，而且无法优化可以优化的东西。）
没有银弹。没有银弹。没有银弹。正如艾伦·凯（Alan Kay）所说，编程是一种“流行文化”，对最新的流行技术更感兴趣。我们拥有如此众多的编程语言（其中许多是相对较新的语言）这一事实证明了我们并不真正了解我们在做什么。
UML很烂，因为它要花很长时间，如果您的软件发生更改，则必须更改UML。在计划阶段，我只使用Draw.io，但是一旦系统实际存在，它总是会过时且无关紧要。
UML之所以死亡，是因为大多数代码是由不在乎官僚机构或只关心编写代码的人编写的。UML承担了一种语言来指定设计，以便其他人可以实现它，或者至少这就是我所看到的用法。但这在大多数情况下是没有意义的。我们已经知道，编写软件的更有效方法是由一个人同时设计和实施该设计。这意味着UML已被降级为仅用作文档。
我用Archimate代替了UML，我讨厌UML的发展方向，以及讨厌从源代码中删除代码/逆向工程的概念-这个想法足够新颖，但绝对是花架子。架构很重要，这可以通过Archimate imo很好地实现。对我有效的方法可能对您不起作用。我仍然使用UML中的某些元素，但通常在白板上用作用例，简单的序列图或状态图。该代码是自我记录。
在某种程度上，UML确实取得了成功：这是描述类图，状态机等的事实上的方法。这不能被低估。
UML与J2EE的思路相同，这是我25年以上职业中遇到的最糟糕的事情。J2EE承担了软件的复杂性，使其不仅更加复杂，而且还带来了灾难性的乏味。然后，“专家”不再是软件开发人员，而是官僚。这是销毁Java和企业软件的完美方法。UML是零基础的企业软件中最糟糕的部分的遗物，我很高兴它完全死了。
我认为UML的最大希望是代码生成，所以UML-> code，但是问题是，当需要对生成的代码进行手动微调时，没有code-> uml的运行过程。
OOP之所以在软件业务中如此受欢迎的部分原因是因为它消除了业务功能与其生产的软件之间的阻抗不匹配。从这种观点来看，UML是业务计划和软件计划之间的一种中间字节码。
说到uml，在我的大学里有一个通用的“软件工程”课程，并且有一个关于UML图表的部分。我记得创建这些看起来像蜘蛛网的绝对野兽UML图。这很有趣，但是在现实世界中绝对没有用。
多年前，我尝试了UML，但收效甚微。我最近开始使用BPMN 2并取得了一些成功-泳道对于大多数人来说很容易解释并且很有意义。ERD仍然是我最喜欢的符号，并且确实经受了时间的考验！
我从来没有遇到过UML，但是可以为SysML说几句好话，它是建立在UML之上的。在嵌入式软件/硬件项目上工作，我发现SysML对于系统设计和文档编制非常有用。主要是BDD，IBD，序列和状态机图。在某些时候，参数图也可能会派上用场。SysML用户倾向于不太活跃的行业，尤其是那些使用许多前期设计来制造昂贵昂贵的硬件的行业。国防，航空，医疗等。我希望我们会继续使用它，直到出现更好的情况为止。
UML发生了三件事：
- 1图驱动的代码并没有像倡导者所希望的那样成功（并且在一定程度上有用，UML并不是一门伟大的语言； BPMN却不错。）
- 建模和分析贬值，对建模语言产生不利影响
- OMG也最终成为BPMN的所有者（这也受到前两个因素的影响），而BPMN在功能上与UML有很大的重叠。因此，通过减少可视化建模语言的作用，您可以在同一组织中获得该领域中两个相互竞争的标准，而这两个标准都不能真正适应当前的使用模式。
在大学时代，我的教授告诉了我很多东西。ORM会杀死RDB，UML是最烂的东西，敏捷是所有软件工程的未来等等。但是现在我几乎看不到这些事情发生。
我亲自采用了序列图，向非编程领域的专家解释了过程，并取得了巨大的成功。但是，无法想象在日常编码实践中使用UML。
UML的问题在于它是框线式的。线框的麻烦之处在于，它们可以很好地解决小问题，而对于复杂的情况却毫无用处地重叠在一起。
敏捷杀死了UML。极限编程引入了以周为单位的Sprint概念，以及在每个Sprint末尾都有工作代码的概念。后来，scrum，看板和其他敏捷方法学至少复制了该过程的那些部分。无论您采用哪种敏捷风格，两个星期都不会留出很多空间来维护不会随代码一起发展的就像UML图一样的工件。您绘制了一个不错的图，然后编码了一个星期左右，然后您的图就过时了。您可以通过花一些时间来解决它。但是您需要每两周这样做一次。极限编程之所以极端，是因为它有意地跳过了需求规范和设计文档，因为它们意识到需求是错误的和过时的结合，这是由于您在项目中学到的东西所致。因此，设计也是错误的。您需要做一些需求，并设计每个sprint。这就是所谓的计划和评估会议。需求现在称为用户故事。而且，由于两周之内对软件系统能做的事情很多，因此不需要太多的UML文档来描述要进行的更改。除了极限编程外，还提供了诸如白板，照相手机和Wiki之类的工具。您通常使用它们用一些简单的图表来进行白板会议，将白板的照片拍下来，然后将其放在Wiki上，没人再看。如果您要进行两个星期的冲刺，那就足够好了。这种会议目的是：共享和交流想法并达成共识。这就是UML死亡的原因：不再需要。创建成本太高，更新成本更高，一旦拥有它就价值有限，一旦停止维护它，保质期就非常有限。
banq注：DDD设计使用UML类图和序列图的实现在线视频：https://www.bilibili.com/video/BV1Yo4y1f7rz/