1、图形化≠易用性

很好的例子就是UML。

2、自动化≠易用性

显然自动化的目的是为了易用性，但并不是所有的自动化都能够带来正面效益。以Hibernate为例，一旦自动化的设计超出了普通人的心智模型，往往会带来负面影响。我曾写过一篇批评Hibernate的文章，也引起了很大的争议，我承认只要有足够的时间和足够的细心，存在能够把Hibernate学到精通的人，但在现实的环境中，影响到时间和细心程度的因素实在太多了，有时我们不得不为Hibernate的这种复杂的自动化说埋下的隐患买单。

那么什么才是好的易用性，这个话题又可以谈很多，这里只归纳一条：Simple is Best.

附：UML正日薄西山的13个理由

编者按：UML开发社区最近流失了一批开发者和拥趸，对一种软件设计技术来说，这意味着它正趋于下滑。而且它的发展趋于一个不利的方向：UML已经开始变得官僚化。本文作者罗列13个理由，以此来分析为何UML正日薄西山。

由委员会设计

从长远来看这是导致语言或技术失败的一个主要和常见的原因，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图表并不一致。

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

你怎么看待UML呢？