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

评论

38 楼 unsid 2010-04-11  

"最后说一下Hashmap与Entity的问题该怎么处理，之前我也不知道怎么处理，后来上面的那位uml培训老师告诉我可以用uml 2.x中的组合结构图(Compostion Construction diagram)来表示复杂的类结构，例如java中的内部类和匿名类。
"

这点可能我孤陋寡闻，不过在设计时候，还有很多比Hashmap与Entity更细节的问题，可以通过扩充规范解决Hashmap与Entity的问题，但是UML规范始终是跟不上人们新的设计思路变化的。在实现代码的时候有很多精巧的设计，比如你把一个类设计成不可变类（类似String），你说这些算不算设计范畴？还真不能不算，你是通过充分分析这个类在并发环境下的风险。但是作为设计语言的UML更难触及这些问题，换言之你把UML给了一个实现人员，这个人员很难从中获得你要把这个类设计成不可变的信息。

所以我的观点是Hashmap与Entity，这种类型的问题他们是不可能用在UML中的，一个系统的设计UML仅仅代表了最最基础的一部分，是蓝图，有了UML你仍然什么都做不了。

37 楼 yin_bp 2010-04-11  

unsid 写道

我觉得UML肯定大有其存在的价值，不过大家都在闷头讨论自己遇到的UML多么多么有用，或者自己遇到的UML多么多么没用的例子，我相信这些例子有很大的道理，既然UML这么有用，为啥还没人直面我的2个问题发表意见：
1、为什么开源项目，比如你下载apache很多世界闻名的开源项目，找不到UML图，按说开源项目是全世界各个国家工程师一起在做，那么用通用的UML语言比在同一个办公室里开发显得更重要。难道是他们从来不画？说不过去，因为更难写的用户指南都写的那么清楚，没理由UML图懒得画。难道是不公开？也说不过去，代码都公开了UML有什么可隐藏的（请对认可于UML有很大价值的人来分析一下，我得理论就是既然他们选择不用UML，他们又比我们强那么多，那么UML肯定有很大问题才会这样）
2、我承认UML用作描述业务的价值，但是是否承认UML在作为架构语言的时候表述力不足呢？（请认为不是的人讨论下Hashmap与Entity的问题该怎么处理）

我刚出道的时候，做业务系统也很喜欢用uml来做分析和设计模型，很喜欢在rose中作以下事情：
1.以用户需求作为输入，做用例分析和领域模型设计，得到一个系统用例模型和领域模型
2.接下来就做模型迁移（转换），将用例模型和领域模型转换为特定语言环境的设计模型和数据库模型，比如java和oracle，其中还可以在java组件上直接应用23种设计模式。
3.接下来将设计模型和数据库模型正向工程为java代码框架和数据库建库脚本（或者直接在数据库中建表）
4.如果想将代码或者数据库表和设计模型或者数据库模型保持同步，可以进行逆向工程（这些uml工具真的很强大）
4.接下来就是实现所有的代码框架和编写dao组件
5.最后可能的话还可以画一个部署模型

整个路线图看起来很好很强大很清晰，也很和谐。但是做到后来总是很困惑，可能是自己对uml把我不好或者是滥用了uml，那就是：分析模型和设计模型画好后，代码也写了一部分了，结果客户说他的需求要做大的变更。我傻眼了，需求的变化导致分析模型要调整，设计模型也要调整（你不要骂我做的模型不具备可扩展性），代码也要做一部分的调整(记住只是一部分)，我该如何下手：
a.修改分析模型,然后将分析模型再转换为设计模型，然后将设计模型再转换为代码模型（框架）和数据库模型
b.直接修改分析模型,直接修改设计模型，直接修改代码和数据库模型
c.直接修改代码和数据库表，然后采用逆向工程方法同步先前的设计模型，数据库模型，然后再逆向工程到分析模型（呵呵，这些uml工具确实很强大）

采用上述a,b，c三种方法都是一件很痛苦的事情，而且会导致分析模型，设计模型和代码模型的不同步，另外，采用方法a很可能导致你已经编写好的代码和数据库脚本被模型转换出来的新代码框架和数据库脚本给覆盖掉。这时你就彻底傻眼了，所有的代码和脚本都得重新来过（谁知到以前的代码是怎么写的，有些人会说你不是有配置库吗，有版本管理吗，把原来的代码考回来不就是了，事情要是有这么简单就好了，关键是你有这么多的时间去反反复复做这些事情吗，项目的进度怎么保证，如果是在单纯地玩玩uml也没什么，关键咱们是在做项目）。
如果项目的规模比较大，大面积出现上述的情况，那么这个项目就很危险了，一般情况下项目都会以失败而终结，当然这是我碰到的一般情况，可能您或者是大家碰到的情况要好些。

后来我再也不去做那种傻事了，在项目中顶多用uml画画静态的用例图、类图、实体关系图（也叫分析模型，领域模型）以及动态的时序图什么的，作为交流和沟通使用，或者作为文档备案，这样就够了，不再去搞什么正向工程和逆向工程了，更多的时候只是用office word来画几个草图，然后放到需求或者设计文档中就可以了。



曾经听一位uml培训老师讲到：只要架构师或者设计师将系统的体系架构和代码框架设计好，剩下的事情只要程序员去填空就可以了。呵呵，我个人觉得这个老师很天真，也很单纯，一个系统不可能就这么简简单单就出来了的，要不还要那么多迭代开发方法干什么。

最后说一下Hashmap与Entity的问题该怎么处理，之前我也不知道怎么处理，后来上面的那位uml培训老师告诉我可以用uml 2.x中的组合结构图(Compostion Construction diagram)来表示复杂的类结构，例如java中的内部类和匿名类。


在我的一篇博文《我们还需要uml么》中也阐述了上面的观点：
http://www.iteye.com/topic/641103

36 楼 wandou 2010-04-11  

我刚学编程的时候也以为uml是有用的。

35 楼 yangyiqian 2010-04-10  

unsid 写道

我觉得UML肯定大有其存在的价值，不过大家都在闷头讨论自己遇到的UML多么多么有用，或者自己遇到的UML多么多么没用的例子，我相信这些例子有很大的道理，既然UML这么有用，为啥还没人直面我的2个问题发表意见：
1、为什么开源项目，比如你下载apache很多世界闻名的开源项目，找不到UML图，按说开源项目是全世界各个国家工程师一起在做，那么用通用的UML语言比在同一个办公室里开发显得更重要。难道是他们从来不画？说不过去，因为更难写的用户指南都写的那么清楚，没理由UML图懒得画。难道是不公开？也说不过去，代码都公开了UML有什么可隐藏的（请对认可于UML有很大价值的人来分析一下，我得理论就是既然他们选择不用UML，他们又比我们强那么多，那么UML肯定有很大问题才会这样）
2、我承认UML用作描述业务的价值，但是是否承认UML在作为架构语言的时候表述力不足呢？（请认为不是的人讨论下Hashmap与Entity的问题该怎么处理）

第1点，我觉得肯定不是所有的这些工程师都不懂UML和不用UML，应该是apache项目中规定了只要哪几种类型的文档，其余的文档一律不包括。这也方便项目的管理。
第2点，UML从硬件部署到对象关系及状态都能表述。架构不外乎整体与局部，这些用UML都能够表达清楚，关键是看选择怎样的一个角度去表述。

34 楼 yangyiqian 2010-04-10  

UML图不是说不需要了，而是很需要，只是目前深入理解UML的程序员是不很多，更加上维护这样一张图，需要额外的工作量，所以，很多项目组中不使用UML。

但UML确实是很重要的一个东东，它的不流行根本原因是很多人不会正确的使用。

    首先UML就是一个工具。但它是一种什么样的工具呢？它就是“作战地图”，是对项目演进进行指导性的文档。请注意这里是指导，也就是说相当于轮廓之类的“粗概念”，主要的是要把“关系”，“流程”等东西描述清楚。
    这些清楚了，明白了哪是“有利地形”，明白了“先打哪，后打哪”等这些流程，这样才能布局“一场好的战斗”。
    现在有好多程序员直接就用详细设计文档进行开发，对程序的结构没有精细的布局，需求一变动，要改的地方那真是“牵一发而动全身”，这些都造成项目的后期维护、系统bug等风险增加，究其原因就是没有一个好的规划，没有一个好的设计，最后导致很多项目以失败告终。更可悲的是很多人最终也没弄明白，为什么项目会失败。
    对UML图应该把握好描述的“景深”。景深是摄影方面的一个名词，大体是指根据所要拍摄的效果决定取景远近。UML正是这样一个工具，它不是一成不变的，也不是包罗万象的，它要根据所要描述问题的主题来取舍某些元素，重要的是要让主题突出出来－－让“图像”更清楚。
    UML要突出重点，把骨架、重要枢纽及其关系描述出来，这些是项目进度的指导方向。
    UML是一门语言，要用这门语言写出好的文章，才是我们的最终目的。所以UML要同设计模式、企业架构模式等结合起来才能充分发挥它的威力。

    总之，UML决不是不需要了，而是高质量的项目必备的“作战图”。

33 楼 unsid 2010-04-10  

我觉得UML肯定大有其存在的价值，不过大家都在闷头讨论自己遇到的UML多么多么有用，或者自己遇到的UML多么多么没用的例子，我相信这些例子有很大的道理，既然UML这么有用，为啥还没人直面我的2个问题发表意见：
1、为什么开源项目，比如你下载apache很多世界闻名的开源项目，找不到UML图，按说开源项目是全世界各个国家工程师一起在做，那么用通用的UML语言比在同一个办公室里开发显得更重要。难道是他们从来不画？说不过去，因为更难写的用户指南都写的那么清楚，没理由UML图懒得画。难道是不公开？也说不过去，代码都公开了UML有什么可隐藏的（请对认可于UML有很大价值的人来分析一下，我得理论就是既然他们选择不用UML，他们又比我们强那么多，那么UML肯定有很大问题才会这样）
2、我承认UML用作描述业务的价值，但是是否承认UML在作为架构语言的时候表述力不足呢？（请认为不是的人讨论下Hashmap与Entity的问题该怎么处理）

32 楼 ppgunjack 2010-04-10  

看过的TMF电信网管规范文档里面，基本全是UML图，下层不同设备商按统一接口实现，上层按接口调用
当然这都是老外设计标准，我们只能照着画瓢用，只不过我们目前还属于下里巴人作坊阶段，靠白板水笔搞定交流，要做大做强走上台面还是缺不了UML

31 楼 抛出异常的爱 2010-04-10  

iaimstar 写道

还是用来交流吧
给后辈，给同事，都这样
能迅速有个整体概念。
没用的时候，那是真没啥用

一门大家都会的语言
但大家不说。。。
就会失传。。。。。

30 楼 iaimstar 2010-04-10  

还是用来交流吧

给后辈，给同事，都这样

能迅速有个整体概念。

没用的时候，那是真没啥用

29 楼 yqp_001 2010-04-10  

uml不是做任何事情的；有一天你发现你需要了，他才有用

28 楼 shuiguozheng 2010-04-10  

tryto21 写道

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

   是的！  但是，还是利大于弊啊！

27 楼 myhousepoor 2010-04-10  

确实很少在用，当然在初期阶段还是有一些uml图，但是现在我们的项目基本按照设计文档来做

26 楼 hunterkevin 2010-04-10  

说来都不好意思，项目中从没用过这玩意。

25 楼 抛出异常的爱 2010-04-10  

hong879113 写道

在我看来UML还是有相当的存在必要的，java语言不需要UML？一个java软件的开发至少是要完整的分析一个对象的基本属性和基本需求吧~那么简单的use case可以很好帮你完善软件的开发，软件整体的骨架，那么类图是非常好的开发基础。。还有一堆堆，当然都是很有必要的存在，当然，个人技术原因，我只懂得几个，但是我的个人项目里面UML还是很重要的~~

青铜器的存在很有必要
你没见拍卖会上那么贵么

好用的东西才会有人用。
用的人比例多了才会有意义。
我没见谁给UML图来设计接口的。。。。
也许我见的人都作坊出来的

24 楼 hong879113 2010-04-10  

在我看来UML还是有相当的存在必要的，java语言不需要UML？一个java软件的开发至少是要完整的分析一个对象的基本属性和基本需求吧~那么简单的use case可以很好帮你完善软件的开发，软件整体的骨架，那么类图是非常好的开发基础。。还有一堆堆，当然都是很有必要的存在，当然，个人技术原因，我只懂得几个，但是我的个人项目里面UML还是很重要的~~

23 楼 donkee 2010-04-09  

只用UML来画草图

22 楼 刃之舞 2010-04-09  

系统复杂起来看UML还不如找个了解的人，弄杆笔搞块白板大家一起随便画画，要效率的多

21 楼 JE帐号 2010-04-09  

UML在设计架构的时候真的很有用处,而且也是唯一选择吧.业务流程图之类的无法深入技术架构层面.
一但涉及非常多的具体实现时,UML就混乱了.不管是视觉上还是思想上.

20 楼 squirel 2010-04-09  

抛出异常的爱 写道

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

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

赞同

当业务趋于复杂，设计决定不是显而易见时，可以用UML来帮助分析业务，理清设计思路，但不要把结果作为文档来保留，如上所述，仅是草图;一句话，把UML用作业务分析和系统设计的工具，而不是结果。

当系统比较大，从代码不容易马上理解系统的整体架构的时候，可以使用反向工程来得到想要的UML图，所以也没有必要维护一份与代码一致的UML文档，这是很难做好的，要做到，成本也非常高。

19 楼 workfish 2010-04-09  

UML只是起到一个提高项目或者产品统一的认知度，在你的项目中是否使用UML不是最重要的，重要的是明确你的团队是否需要UML来统一对项目的认知，而且，是否使用UML还和项目本身的复杂程度有关系，如果就是一个简单记账程序，有必要使用UML吗？
个人之见，请指教