UML正日薄西山的13个理由

    由委员会设计

    从长远来看这是导致语言或技术失败的一个主要和常见的原因，CORBA就是最好的例子。

   过分注重商业化

   试图为一门不够成熟的技术出售工具而且只对工程的管理部门承诺什么，这只能是一种短期有效的方法。有时候人们会认识到这样的成本远大于收益，这也让程序员在本能上非常厌恶。另一些人因为工程管理部门的要求或好奇心而尝试这些工具，但大都使用不超过一个工程就弃用了。

   太过激进地想把几乎一切都涵盖起来（UML规范超过800页）

   当你试图为一个领域内的每个问题都提供一个解决方案的时候，最终你会发现其实你没有提供任何有效的解决方法。UML试图解决所有与软件开发相关的问题。试图涵盖一切是一个不可能的任务，即使规范有800页，UML也只是覆盖了复杂的软件工程领域的一部分。

   背离了开发者的最初目的

   作为一名程序员，我喜欢UML为设计通讯等内容而提供的标准化，能够使用一套通用的符号来与其他的程序员或者设计师交流我的想法真的很棒。我想大多数程序员仍然只是使用类图表，或者在他们写一份文件的序列图时偶尔用一下。然而，UML开始使用那些即便是商务人士都不懂的面向商业的类图表。

   概念膨胀

   在过去的10-15年里，UML一直试图概括所有流行语言的概念。现实么？

   总在追赶新的语言和概念

   承接上一点，既然UML承诺全语言的代码生成，就意味着它必须包含每一种特殊的语言架构。

    试图成为一门编程语言

    由于能够生成全代码，所以实际上UML试图成为一门编程语言，而一种通用的图形编程语言存在很大的问题。在人类历史上，所有语言的手写形式都是从图形到文本，在捕捉和传递思想方面，字母表证明比图像更具表达力。如果试图用图形描述每个流程，那必须还得使用语言来注释这些图形。图形在形象化人们的思维和概念方面确实有效，但是在描述细节方面语言更有效。

    需要昂贵的工具还是只需要一个文本编辑器

    要想真正地UML入门，要求很高，他们需要训练，因为他们不是时时刻刻都在使用最直观的工具。咨询公司会喜欢UML的这一特性，因为这意味着昂贵的培训课程。

   缺乏模型清晰度（model clarity）

   图形读不懂我听到很多开发者在理解UML图解的设计时发出这样的抱怨，最终不得不通过读代码来理解。

    缺乏真正软件设计的问题解决方法

   UML规范很多，却没有软件系统常见问题的好的解决方法。随便举个例子：

   没有多任务和任务间通信的解决方案；

   没有用例（use cases）之间的依赖

   假设你在写第一行代码前就知道一切

 

编写使用手册，然后在此基础上顺利成章地生成代码但这可能无法实现。由于在实践中一切都是动态的，所以UML图表如果要与代码保持一致，它的维护就变得非常麻烦，开发者对此很反感。

    对待软件开发就像对待制造业

    软件设计不是制造业，软件创作是一种创造性的活动，更加是工艺或者艺术。UML试图标准化和形式化开发者的想象力和才智。

    UML工具的目标错误

    大部分的UML工具承诺代码生成，然而大多数时候它们都是没用的，因为只是生成了没有逻辑的空的类别本体。而且这很笨重和繁琐，因为开发者必须保持代码和图表的同步。有开发者不得不使用丑陋格式的评论来进行标记。

    这些工具的另一个问题是屏幕上呈现的有效图表元素的数量。很多次我查看一个UML图表或者一个复杂的系统，但只能看到一角，根本无法帮助全局的理解。而且，很多使用UML完成的工程，其最终的代码与最初的UML图表并不一致。

    我也不认为代码生成是个好主意，一般来说生成的都是复杂的代码，而大部分工程可能使用库中的公用代码更好。