我们不需要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精神以离架构逐渐远去。 59 楼 mingjian01 2010-08-05 个人认为： UML用来说明想法是好的，比如你设计了一个框架，想要表达你的设计思想，用图总比说的好，但是用UML来生成代码，逆工程之类的就有点不太必要。而且有时用UML来表达一些细节的时候往往要结合几种图一起图，不是一种图搞掂的事，变通也是很重要的 60 楼 KimShen 2010-08-06 "所谓的"架构们很喜欢用UML,能忽悠客户阿.
有时候客户需要知道自己的系统大体的结构是什么,这时候这东西就派上用处了.刷的一下,硕大的图纸.客户一看很复杂自然钱也就多了.
其他用处好像就不多了,而且UML还要配套RUP什么的.对于不是异构的大项目来说...负担阿。 61 楼 habzyhs 2010-09-15 真正好的代码，代码本身就是最好的设计说明，没必要再写成文当，而且维护文档的工作比维护代码的工作更难。
还是这句话。。。 就应该是这样说的。
我都不怎么会看uml。。。但是。。 只能说这个是一个业内需要的技能。。
就像电影一样。不会演。。。但要会看。。 62 楼 softrain 2010-10-25 目前的工作就是用Borland Together画图，然后交给开放组写代码，基本上是图画成什么样，代码就要写成什么样。
有几个问题比较严重：
1. 缺少重构的工具，就算是重命名一个类，也能把人累死
2. 缺少质量测量的工具，设计的质量如何没法保证
3. 画图太慢，没有语法提示，还不如写代码速度快
也有好处，主要是可以自动把所有图打包到一个PDF文档里面，方便传阅。 63 楼 pushboy 2010-10-25 自顶而下，层层分解
从uml图入手了解一个系统就是这样，先有大的概念和模型，然后一层层的去了解
给个大系统，一大堆的代码，很容易开始就陷入细节 64 楼 hyj1254 2010-12-11 最起码看一段代码之前如果有UML图的话速度会快很多。 65 楼 wwty 2011-01-18 unsid 写道rainytooo 写道其它的开发不敢说,java肯定还是得用uml,所以人对项目会有个直观的认知
我觉得如果把代码分为两种情况：技术性代码（比如HashMap和Entity），业务性代码（比如OrderList和OrderItem）
那么业务性代码用uml表述还可以，技术性代码用uml已经很难准确描述
很赞同，我也感觉用uml来反映业务是很好的
66 楼 wolfbrood 2011-01-18 <div class="quote_title">habzyhs 写道</div>
<div class="quote_div">真正好的代码，代码本身就是最好的设计说明，没必要再写成文当，而且维护文档的工作比维护代码的工作更难。<br><br>还是这句话。。。 就应该是这样说的。<br>我都不怎么会看uml。。。但是。。 只能说这个是一个业内需要的技能。。<br>就像电影一样。不会演。。。但要会看。。</div>
<p>?</p>
<p>有UML图还是非常非常不错的，一目了然。如果没有UML，看它的概念介绍也是非常不错。</p>
<p>一个劲的看代码太累。</p>
<p>文档维护在前期是一个很大的工作，如果稳定下来了，改动也很少。</p>
<p>?</p>
<p>文档不要求很多，但一定要能说明一个大体。</p> 67 楼 TheNegRo 2011-01-18 我认为啊，想要学习一个开源项目的设计思想的话，就该从它的代码去理解，理解之后，自己根据代码而反画出UML图来。 68 楼 z276356445t 2011-01-18 我认为在做业务逻辑的时候一定要先用UML画个草图,这样会更直观些,而且也能在你敲写业务逻辑代码的时候能够更清晰的来完善你的代码,至少不会感觉到自己在迷宫里. 69 楼 cdn_mn_mm 2011-01-18 Anddy 写道一直在学习UML ,却一直使用不上。
UML应该是每个软件工程师必须的。
together UML 这个软件不错的。
这个很好用，一致都有用到UML 70 楼 coolbamboo2008 2011-02-02 大家为什么开始用注解而不使用UML了？
我觉得国内的项目工期紧压力大，如果客户没有特别的要求一般能省就省了
很大程度上，注解能直接对代码起作用，UML不行
唉，国内做项目真纠结 71 楼 unsid 2011-02-03 coolbamboo2008 写道大家为什么开始用注解而不使用UML了？
我觉得国内的项目工期紧压力大，如果客户没有特别的要求一般能省就省了
很大程度上，注解能直接对代码起作用，UML不行
唉，国内做项目真纠结
我觉得不是这么说，现在即便在国外，UML也被排挤，因为提出UML是外国人，说UML不好用的也是外国人，现在国外推崇敏捷开发的越来越多，敏捷开发本身就崇尚简单设计，比较反对前期做过大的设计，只为现有需求做刚刚好满足的设计就足够，未来遇到变化再重构，他们推崇“代码即设计”，所以可见UML被排挤，这不仅仅是国内的事。 72 楼 464410531 2011-02-03 看帖加粉吗？？？？？？？？？？？？？？？？？ 73 楼 Willam2004 2011-02-05 cdn_mn_mm 写道Anddy 写道一直在学习UML ,却一直使用不上。
UML应该是每个软件工程师必须的。
together UML 这个软件不错的。
这个很好用，一致都有用到UML
jude uml这个软件画uml也不错，目前我们公司的用例图和类图都是用它来画。 74 楼 chengkun 2011-03-02 uml很少用的飘过。 我们做项目重来不用uml 75 楼 lewisw 2011-03-02 ilove2009 写道UML不是万能的
纠结，这句话，是肯定还是否定啊，怎么马上让我想起“但是没有XXX是万万不能的”. 76 楼 proud686 2011-03-03 很多东西，很多业务，用图来表达的话会更加清晰。而且画图的话也可以提前规避一些设计上的风险。如果光用文字去表达，中间失真会比较大，而且也不清晰。 77 楼 Durian 2011-03-04 池中物 写道UML用来描述业务的。
用uml来直接描述实现或者直接生成代码之类的我觉的没啥需要了
---
你说的这个靠谱。我也这么认为。
敏捷开发上面十分肯定的说，uml是作为沟通交流业务的描述工具，大家坐在会议室，在白板上画出来各种uml的关系图，然后讨论，修改，明确需求，传达设计师的意图。开发再反馈理解情况。
但是，最后的uml图不作为实现的依据，也就是说，不用图形指导编码和设计，只是帮助理解，达成共识。
设计需要另外一套文档，或者工具，也许仅仅是代码。
我觉得面向接口本身就是一种详细设计。 78 楼 moqinan 2011-03-08 早就不用了，不好用
