我们不需要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精神以离架构逐渐远去。

评论

18 楼 ilove2009 2010-04-09  

UML的类图还可以，基本上23个设计模式都能刻画出来。其他的好像一般，其他图，如时序图发现很多人理解都不一样，有的人粒度大，有的粒度小。

17 楼 yin_bp 2010-04-09  

hatedance 写道

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

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

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

uml是一种建模语言，也是一种规范，你遵循它或者用他来画图无可非议，你不遵循它或者弃用他也无可非议，萝卜白菜各有所爱，有些人喜欢用uml来表达自己的设计思想（尤其是比较自己觉得做的比较得意的地方）、表达自己的架构思想，有些人喜欢直接拿支笔（管他规范不规范）在墙上、在地上、在纸上（总之可以画可以写的地方）涂鸦式的表述自己的设计和架构思想，呵呵

16 楼 Anddy 2010-04-09  

一直在学习UML ,却一直使用不上。
UML应该是每个软件工程师必须的。

together UML 这个软件不错的。

15 楼 wei495715356 2010-04-09  

我觉uml 在设计中 设计框架图 给人比较直接。

14 楼 cleanerje 2010-04-09  

个人私下认为：UML适合业务逻辑特别复杂的情况，尤其是存在非单一系统：（例如业务系统、短信平台、银行刷卡等等），这时候使用UML时，提高生产力的作用是非常巨大的。
但如果是单一的系统，如果分层正确，注释也到位，使用UML本身就是一种负担。这时候详细设计说明书本身就已经满足开发需要了。
使用UML还有一个问题，它需要设计团队本身有足够强大的能力才能驽驾UML这个怪物。
最后一个问题，因为人员流动性的存在，你确定接手的人员能够搞得定UML？
综上所述，从成本考虑，如非必要，最好不要沾UML，呵呵。

13 楼 nighthawk 2010-04-09  

那交流的时候总得画个什么吧，不能你画个馒头大饼表示，我画个阿猫阿狗的

12 楼 gdpglc 2010-04-09  

1.UML做为一种设计辅助手段，的确有它的用处。当然可以不选择UML表达架构设计，但是一样要选一种其它的表达方式。我喜欢用它，因为现在uml工具很多，容易上手，图表含意相同。但我并不局限于它，只要能清楚表达设计意图的方式，都是可以尝试的。拿uml当教条当然会有问题。
2.开源项目也有用uml的。
3.你举的例子，是一个设计细节，一方面的确可以用uml表达，uml有 构造型 有注释 可以进行扩展。不知大家所在的公司会不会作这么细的设计。我想这个应该是成熟的程序员的习惯用法，并不象是架构的内容，有必要画到图里吗？

11 楼 ilove2009 2010-04-09  

UML不是万能的

10 楼 andyu2008 2010-04-09  

真正好的代码，代码本身就是最好的设计说明，没必要再写成文当，而且维护文档的工作比维护代码的工作更难。

---------
没错，好的代码本身就是最好的设计，为什么要用UML? 就是因为无法保证整个项目都是好的代码，假如一个项目是200个人协作完成的，谁成保证这200个人都能写出高质量的代码？

9 楼 vampire423 2010-04-09  

池中物 写道

UML用来描述业务的。


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

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

8 楼 tryto21 2010-04-09  

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

7 楼 池中物 2010-04-09  

UML用来描述业务的。


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

6 楼 unsid 2010-04-09  

hatedance 写道

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

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

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

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

5 楼 hatedance 2010-04-09  

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

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

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

4 楼 jiafu0773 2010-04-09  

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

3 楼 抛出异常的爱 2010-04-08  

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

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

2 楼 unsid 2010-04-08  

rainytooo 写道

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

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

1 楼 rainytooo 2010-04-08  

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