我们不需要UML了么？

   故事还要从去年说起，去年无聊的时候，开始下载Apache的开源项目看，说实话Apache的项目代码对于刚开始接触开源的人来说难度还是太大，但是我一直认为想看懂开源项目的所有细节是不可能的，应该把握整体的骨架，不久我惊奇的发现所有开源项目的指南，安装手册，用户手册一应俱全但是几乎找不到包含任何类图，时序图，协作图等设计细节的设计文档，我在想代码开源了设计图纸没必要保密吧。所以就个费解问题请教了很多人，包括作过开源项目的人，从他们口中得出一个结论：真正好的代码，代码本身就是最好的设计说明，没必要再写成文当，而且维护文档的工作比维护代码的工作更难。 说实话，当时给我的困惑真是不小，难道好的软件已经推翻或者不再需要大学时候老师像圣经一样传授的UML?

   不久别人推荐文章：http://www.sigplan.org/oopsla/oopsla99/2_ap/tech/2d1a_uml.html 质疑UML是否真的适合作为架构设计的语言，显然作者是否定态度的。

    在一次讨论上，我们又针对一个非常关键的问题进行了讨论：到底UML的粒度到什么位置最合适。首先基本上所有人都可以肯定地是不需要把所有东西都画在UML上，一个巨大的图纸带来的灾难远大于帮助。到底如何用UML来指导设计真是一个很困难的问题。我曾经举了这样一个例子：

比如java中的HashMap，在HashMap中定义了静态内部类Entry,这样做的好处是
1、根据数据亲密性原则，将HashMap中关联的数据key和value封装起来
2、这个结构只对HashMap本身有用，所以定义成私有的内部类，以免其他类与Entry产生不必要的耦合
但是如果站在你是设计HashMap设计者角度上考虑，将怎么记录设计决定呢？
一、如果企图将HashMap与Entity的关系记录在UML里，那么：
1、UML中很难找到方法表演一个类是另一个类的静态内部类，更难找到方法体现这两种类之间的关系。
2、如果把这些画上了，那么意味着很多其他同等细节的东西也需要在UML上面体现，将会产生一个硕大的难以短时间读懂的图纸。
二、如果不做这样的记录那么：
1、HashMap与Entry关系确确实实是你精心设计的结果，是很设计的重要组成部分，不是实现架构时候的随便决定的。
2、你可能确确实实需要在设计而不是开发阶段能够记录下这个决定，并且很有可能实现架构的人不是设计者你，你也需要保证实现者准确的接收到你的意图。
基于这两点，这种设计决定处于一种相当尴尬和纠结的局面，许多事实证明这么细节的东西是不会被记录到UML中的，UML作为架构设计语言的表述不完整性也可见非常。

无论大家怎么看待UML，有一点可以肯定地是，越来越多的人（包括软件大师）在设计和实现架构的时候不会预先绘制UML图，UML终究不可能像建筑图纸那样精确的描述建筑物的设计决定，UML精神以离架构逐渐远去。

其它的开发不敢说,java肯定还是得用uml,所以人对项目会有个直观的认知

我觉得如果把代码分为两种情况：技术性代码（比如HashMap和Entity），业务性代码（比如OrderList和OrderItem）
那么业务性代码用uml表述还可以，技术性代码用uml已经很难准确描述

好吧我见过乱用UML图的占大多数。

用的好的只有草图。。。。但他们又不是标准UML

我们现在做的项目，没有用到uml，项目做得太烂了，都没法说。

我觉得UML的问题在于其不可执行性。（虽然有正向工程和反向工程的概念，但还不管用）
类图是能用来生成代码了，但其他的图却不好办。

如果你能像建筑工程图纸一样，先画粗稿，然后慢慢完善细节，最后得到的图纸就能被执行了，或者完美的生成了代码。

现在的实际情况是你代码归代码，图归图，谁愿意费力同步这2玩意啊？

不光是我们做的不好的项目阿，就算国外优秀实践项目也在逐渐摒弃uml，尤其是技术框架型代码里的uml不常见了
当然uml用作一种传播设计思想的伪语言还是不错的，但是指导开发还是很难

UML用来描述业务的。


用uml来直接描述实现或者直接生成代码之类的我觉的没啥需要了

做个一个项目，开始的时候用uml，直接生成数据库和java代码，但是随着项目进展，维护uml的成本越来越高，就逐渐放弃了。

同意，感觉UML一般都是用来很high level的描述下业务，或让人对系统整体有个初步的认识。