最近我看到一张图表显示多年来对UML的兴趣几乎降至零。该图是从Quora中获取的，Quora是一个有意见者的论坛，而不是真相的来源。
毫无疑问，早期的敏捷方法放弃了架构（至少是前期架构），因此对UML的兴趣大大降低。我理解为什么早期的敏捷方法不支持UML。我相信动机是两个：
UML本身太复杂了。
毫无疑问，在讨论软件架构时，UML包含许多非常有用的图表。例如用例，类和序列图。然后使用UML设计时，各种必要元素和非必需元素混合在一起，2010年，我写了一篇论文“UML的前进之路” 其中提出了重组规范的问题。标准。它不会改变语言，但会改变它的呈现方式。
该文建议我们应该确定一个必要元素的小内核，然后应该在内核之上添加更高级的元素作为单独的关注点。因此，我们将使用与我们已经应用于软件开发方法相同的想法，并且已经产生了用于软件工程的不必要元素。必要元素是OMG采用的新标准。
UML在大多数组织中都被严重滥用。
UML用于描述所有内容，而不仅仅是必需品 - 架构。开发人员首先使用UML设计他们的用例，然后使用他们生成的类图数据表作为编码的输入。工具供应商提供了从这些图中生成代码的工具，但由于图表是由不了解实现的人组成的，因此它们可能是无用的。那些不得不编码的人感到沮丧，只好扔掉了设计并重新编写了所需的代码。嗯，说实话，很多组织都做得比这更好，但是公平地说，UML使用得太多而且太多了。毕竟UML是一种建模语言，而不是像C ++，Java或任何更现代的语言，如Python，Haskell，Erlang这样的实现语言。(banq注：使用UML构建DDD的战略模式是很好的)
但是，如果以智能方式使用UML，则它非常实用并且会产生具有更高价值的产品。UML是一种创建架构的好语言。它对敏捷团队非常有效。在早期的冲刺中，您可以创建体系结构路线图。该路线图使用了非常简单的UML版本，它可以识别最关键的子系统，它们的交互，用户故事或类似内容，以及您认为至关重要的任何其他内容。在以后的冲刺中，您可以随时改进路线图。关键在于您通过架构思维引领的每个冲刺。
UML被滥用是在软件开发领域变得时尚的一切。但是，如果以智能方式使用UML，它确实有助于团队了解他们前进的方向。
很明显，UML的兴趣在敏捷的早期大幅下降，但我认为在向大型组织扩展敏捷时使用量会增加。从我的视野看，UML甚至没有接近死亡，但我认为它需要更好地反映它的使用方式。如果它能够生存下去，它就像其他一切一样需要跟上它的环境。UML是20年前开发的，当时大多数人都遵循一种令人窒息的开发方法，而忽略了软件开发的人性方面。我想看一个更好地反映我们今天所处位置的UML n.0。如果这种情况没有发生，恐怕我们会看到新一代的建模语言，UML至少会成为灵感的源泉。