原文链接：http://littletutorials.com/2008/05/15/13-reasons-for-umls-descent-into-darkness/
中文版本：http://news.csdn.net/a/20091231/216194.html
>> 今天头一次在CSDN上看到这篇文章的中文版本，原文是英文写的，作者不详。看到标题就够震惊的，本来都准备睡觉了，
>> 然震惊之余，觉得有必要发表一下自己的看法。我基本上不赞同文章中的诸多观点，但我深知，个人的观点也未必正确，
>> 因此，欢迎大家拍砖:)
编者按：UML开发社区最近流失了一批开发者和拥趸，对一种软件设计技术来说，这意味着它正趋于下滑。而且它的发展趋于一个不利的方向：UML已经开始变得官僚化。本文作者罗列13个理由，以此来分析为何UML正日薄西山。
由委员会设计
从长远来看这是导致语言或技术失败的一个主要和常见的原因，CORBA就是最好的例子。
>> CORBA失败了吗？它是ITU推荐的中间件标准，其高性能是IBM的CICS以及Weblogic的Tuxedo无法比拟的，而且CICS
>> 和Tuxedo基本上都算是这两个公司内部的标准，而非任何开放的标准，从这点而言，CORBA应该更有生命力。CORBA
>> 规范设计有很多公司参与的，几乎囊括业界领先的软件公司。
>> 不可否认，CORBA技术很复杂，使用门槛比较高，这的确有些影响其推广。
过分注重商业化
试图为一门不够成熟的技术出售工具而且只对工程的管理部门承诺什么，这只能是一种短期有效的方法。有时候人们会认识到这样的成本远大于收益，这也让程序员在本能上非常厌恶。另一些人因为工程管理部门的要求或好奇心而尝试这些工具，但大都使用不超过一个工程就弃用了。
>> UML的学习过程应该没有CORBA那么难。在还不熟练的时候，使用起来的确会感到很麻烦，但当熟练以后，就得心应手
>> 了。就像CMM认证，开始推行的时候会非常困难，也会让工程人员厌恶，但是一旦成功，那么对一个企业还是有很大的
>> 帮助的(不过很多国内CMM认证的企业，对待CMM的态度是不正确的，即使通过了，也还和原来差不多)。因此，对待一
>> 个经过比较长时间检验过的工具，不仅仅是为了满足谁的好奇心去尝试而已(这样的尝试往往是浅尝辄止，然后知难而退)，
>> 而是要以虚心态度来认真对待。
太过激进地想把几乎一切都涵盖起来（UML规范超过800页）
当你试图为一个领域内的每个问题都提供一个解决方案的时候，最终你会发现其实你没有提供任何有效的解决方法。UML试图解决所有与软件开发相关的问题。试图涵盖一切是一个不可能的任务，即使规范有800页，UML也只是覆盖了复杂的软件工程领域的一部分。
>> 800页的规范不算太多吧：）
>> UML并没有试图去解决软件工程中的所有问题，它的确只是解决了其中的一部分问题。软件工程涵盖的内容很广，UML是
>> 相对静态的东西，与之对应的RUP(当然还有其他的方法论)则是相对动态的东西。
背离了开发者的最初目的
作为一名程序员，我喜欢UML为设计通讯等内容而提供的标准化，能够使用一套通用的符号来与其他的程序员或者设计师交流我的想法真的很棒。我想大多数程序员仍然只是使用类图表，或者在他们写一份文件的序列图时偶尔用一下。然而，UML开始使用那些即便是商务人士都不懂的面向商业的类图表。
>> 谁能代表“开发者”？
>> UML的宗旨是主要为开发人员之间提供一个交流的工具。
概念膨胀
在过去的10-15年里，UML一直试图概括所有流行语言的概念。现实么？
>> 不是这样的。UML并没有一直试图概括所有流行语言的概念，它专注于OO类的语言。过去的10-15年里面，VB也算是
>> 流行的编程语言了吧(不是VB.net)，在UML绝大多数相关文章中，几乎看不多VB影子。所以，UML是有所取舍的。
>> 但是在面向OO类语言方面，UML做得的确不错，至少目前没有第二种方式比它更好吧？
总在追赶新的语言和概念
承接上一点，既然UML承诺全语言的代码生成，就意味着它必须包含每一种特殊的语言架构。
>> 与时俱进没有什么不好的：）
>> 我不相信有“全语言的代码生成”这样的承诺。请提供这种说法的出处。
>> 在正向工程方面，理论上UML的确可以做到代码生成，而且某些部分(比如由UML类图生成类)还应该不算特别难实现，
>> 这样的工具已经存在。但是我们对待生成的代码的态度必须端正，因为它也许不是最优的代码，甚至是有缺陷的代码，但
>> 这并未必是UML的错，而有可能是提供这方面工具的生产商的错误，就像因为VC6.0对STL支持不是很好，你就说STL
>> 是个烂东西吧？
试图成为一门编程语言
由于能够生成全代码，所以实际上UML试图成为一门编程语言，而一种通用的图形编程语言存在很大的问题。在人类历史上，所有语言的手写形式都是从图形到文本，在捕捉和传递思想方面，字母表证明比图像更具表达力。如果试图用图形描述每个流程，那必须还得使用语言来注释这些图形。图形在形象化人们的思维和概念方面确实有效，但是在描述细节方面语言更有效。
>> 前面曾经提到，UML的宗旨是提供软件工程师之间的一个沟通交流的工具。其他目的都是从属的、辅助性的，其代码生成
>> 也是如此，但在一定程度上可以减少程序员的工作量(如果工具合适，并且该程序员可以熟练使用)。它和语言并不是同一个
>> 层面的东西，因此没有可比性。
>> “在捕捉和传递思想方面，字母表证明比图像更具表达力”这种说法，难以让很多人认同。
需要昂贵的工具还是只需要一个文本编辑器
要想真正地UML入门，要求很高，他们需要训练，因为他们不是时时刻刻都在使用最直观的工具。咨询公司会喜欢UML的这一特性，因为这意味着昂贵的培训课程。
>> UML开源的、免费的工具比比皆是，CSDN就有一个网友开发出了一个很好的UML工具，所以UML工具并不总是昂贵的。
>> 至于UML培训课程的昂贵，那完全是另外一个问题，你完全可以自己学习而不去参加培训，也可以达到熟练掌握的程度。
>> 顺便说说：现在各种各样的培训，那样很便宜？
>> 我们需要UML工具，也需要文本编辑器:)
缺乏模型清晰度（model clarity）
图形读不懂我听到很多开发者在理解UML图解的设计时发出这样的抱怨，最终不得不通过读代码来理解。
>> 这个纯属误会。谁说过仅UML图就能完全代替设计，而无需任何文字说明？
>> 事实上，UML图 + 文字说明 + 代码/伪代码(但不限于此)，才能说明问题。
缺乏真正软件设计的问题解决方法
UML规范很多，却没有软件系统常见问题的好的解决方法。随便举个例子：
没有多任务和任务间通信的解决方案；
没有用例（use cases）之间的依赖
>> 解决方案是具体的东西，UML不可能提供现成的此类解决方案，它只是一个高层次的描述语言而已。但是有一点是肯定的：
>> 可以用UML来描述所谓的解决方案。有点过于求全责备了吧:)
假设你在写第一行代码前就知道一切
编写使用手册，然后在此基础上顺利成章地生成代码但这可能无法实现。由于在实践中一切都是动态的，所以UML图表如果要与代码保持一致，它的维护就变得非常麻烦，开发者对此很反感。
>> 这个问题我觉得是习惯问题，并非所有的开发者对此都很反感，这是一个有经验的、有责任心的程序员必须做的。
>> 我也认同“在写第一行代码前就知道一切”这样的天才肯定不存在，因此所有的东西都有可能需要修改。现在，请问如果
>> 你不用UML，那你用什么做设计？Word + Visio + 任何非UML工具…组成的设计文档？很好，但这样你能确保你的代码
>> 一定是按照文档写的吗？如果在写代码的时候，发现文档有问题，你或者你的同事不打算update原来的设计文档吗？要知
>> 道，这个文档里，可是没有任何UML的影子！
>> 或许你会说，我们用XP或者Scrum之类的Agile方法，渐进、迭代式地来开发项目，可以少写文档(可以负责任地告知，
>> 一点文档都不写是不可能的)，如果是这样的话，那么请看看这方面Robert C. Martin写的权威著作《Agile Software
>> Development》，很有意思的是，他这本书里面充实了大量的UML图，而且在书的后面还有专门介绍UML Notation的章节。
>> 实在不明白，这样的问题为什么可以归结到UML的错。
对待软件开发就像对待制造业
软件设计不是制造业，软件创作是一种创造性的活动，更加是工艺或者艺术。UML试图标准化和形式化开发者的想象力和才智。
>> 软件设计的确不是制造业。但不能因为借口所谓的“创造性的活动”，而忽视一些基本要素的存在。UML提供了“创造性
>> 的活动”的词汇，你可以用这些词汇去推理，去设计，去创造。试想在数学里面，如果你什么概念和定理(词汇)都没有理解，
>> 你怎么能够去证明或者解决一些问题？
>> 说到这里，Design Patterns肯定也是被你否定了，因为它限制了你所谓的“创造性的活动”，但是事实真的是这样吗？
>> 而且Design Patterns比UML更抽象难懂:) 但它是众多软件界高人集体智慧的结晶，由GoF表达了出来，被无数的软件开
>> 发人员证明是行之有效的，顺便再提及一下，里面的各种模式都有UML图:)。学海无涯，我们不可能什么事情都直接参与
>> 从头做起，应该认真吸取别人的间接经验，在充分理解的基础上，加以扬弃。
>> 不受任何约束的创造，那是凭空创造，但这样的牛人应该不存在吧。
UML工具的目标错误
大部分的UML工具承诺代码生成，然而大多数时候它们都是没用的，因为只是生成了没有逻辑的空的类别本体。而且这很笨重和繁琐，因为开发者必须保持代码和图表的同步。有开发者不得不使用丑陋格式的评论来进行标记。
>> 任何时候，请不要忘记UML的宗旨：为系统设计人员、程序员提供有效的交流工具。代码生成是辅助性的。
这些工具的另一个问题是屏幕上呈现的有效图表元素的数量。很多次我查看一个UML图表或者一个复杂的系统，但只能看到一角，根本无法帮助全局的理解。
>> 任何代码和文档，你的view也只能有电脑屏幕那么大，这与UML何干？
>> 我以前用ERWin和同事设计一个大型系统的data model，的确也存在你提到类似的情形，我们后来把那些图用A4纸打印
>> 出来，做成了一副很大的图(应该有16张A4纸)，订在墙上，这样就很有全局观了。很多朋友都是这么干的。
而且，很多使用UML完成的工程，其最终的代码与最初的UML图表并不一致。
>> 如果你们觉得UML图表已经完成了它的使命，不一致也没有关系。否则，一定要保持一致。
我也不认为代码生成是个好主意，一般来说生成的都是复杂的代码，而大部分工程可能使用库中的公用代码更好。
>> 从目前的UML工具来看，对于这点，我和你基本持相同的看法。
你怎么看待UML呢？（文/王玉磊）