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

评论

58 楼 windforce9811 2010-08-04  

UML更多的应该是沟通的工具，相当于一些约定的术语的集成，省去一些沟通的成本而已。
更多的应该体现在草图和草稿阶段，作为最终的文档，UML表现力还是弱了些，且很不好控制，画多细，画到什么程度都是个问题。

57 楼 xiaoyp 2010-08-04  

其实有次听讲座，有个教授已经说过：建小的东西可以不用图纸，但大多东西呢？
所以UML中这东西一般是给大企业用的，小企业或小东西的话我觉得是一个鸡肋～～

56 楼 GRDJE 2010-07-20  

从来不用那玩意， 脑子拍拍就干了

55 楼 cutesource 2010-07-19  

<p>个人感觉 UML还是非常必要的，特别是可以帮助你自己梳理思路和表现架构，我在分析源码和架构的时候就特别喜欢用UML，具体可以以下例子：</p>
<p><span style="">
<p style="padding: 0px; margin: 0px;">源码分析：<a style="color: #006699; text-decoration: underline;" href="http://blog.csdn.net/cutesource/category/631854.aspx">http://blog.csdn.net/cutesource/category/631854.aspx</a></p>
<p style="padding: 0px; margin: 0px;">架构分析：<a style="color: #006699; text-decoration: underline;" href="http://blog.csdn.net/cutesource/category/695489.aspx">http://blog.csdn.net/cutesource/category/695489.aspx</a></p>
</span></p>
<p> </p>

54 楼 soci 2010-06-26  

不是很大的项目（几个人的）都是直接定义 接口 类 方法签名 URL参数  URL跳转

53 楼 murainwood 2010-06-26  

其实极少能看见谁画好“精确，标准，严格”的UML. 虽然一直在用这个。呵呵，所以么…UML,简单用用，简单用用就好啦，吹毛求疵就没啥意思了

52 楼 huangyuanmu 2010-06-25  

用uml成本太高，一般中小企业用不起也用不好，这是我的看法。

但是uml一定要懂一些，起码那些基本的图要认识，在进行一些培训、讲解、沟通、交流方面，有的时候使用uml图还是蛮方便的。

51 楼 zzitt 2010-06-25  

UML还是有一定作用的~但是好像没那么必不可少的意思~

50 楼 udvs 2010-06-23  

有利有弊把，我们公司作项目现在没用UML，新来的同事，融入团队需要一定时间

49 楼 hatedance 2010-04-12  

ppgunjack 写道

很多开源软件开发参考文档仍然都是收费的，不公开uml，序列图更大可能是这个价值更高
写到大几千行代码，靠脑子已经很难维护代码，多好的代码都一样。越好的代码越颗粒化，以平均40行一个函数，1w行原始代码就会达到近250个函数，撇掉属性，到了十几w行谁还能光拿代码说话，造火箭的难道能牛逼到拿电路说话

赞同。
光看代码我们很难一下子看出类之间的关系，采用的模式。
数据库er图能看出实体关系，1对多，多对多之类，uml里的类图比er图稍微全面一些。
状态图，序列图，对理解设计意图帮助很大的。

48 楼 ppgunjack 2010-04-12  

很多开源软件开发参考文档仍然都是收费的，不公开uml，序列图更大可能是这个价值更高
写到大几千行代码，靠脑子已经很难维护代码，多好的代码都一样。越好的代码越颗粒化，以平均40行一个函数，1w行原始代码就会达到近250个函数，撇掉属性，到了十几w行谁还能光拿代码说话，造火箭的难道能牛逼到拿电路说话

47 楼 gdpglc 2010-04-12  

unsid 写道

gdpglc 写道

其实这个问题换个问法就清楚了。

我们不需要建模了吗？

显然建模是需要的，即然如此，UML就是一个不错的选择。

我明显不是想说的这个，谁都知道需要建模，我是在质疑uml对建模有多大贡献，其实写的好地代码自己就给自己建模。

你可能是想说，用代码进行建模行不行？
你要知道，需求调研、分析、设计、这时都是不会写代码的。代码并不是建模语言。

46 楼 unsid 2010-04-12  

gdpglc 写道

其实这个问题换个问法就清楚了。

我们不需要建模了吗？

显然建模是需要的，即然如此，UML就是一个不错的选择。

我明显不是想说的这个，谁都知道需要建模，我是在质疑uml对建模有多大贡献，其实写的好地代码自己就给自己建模。

45 楼 gdpglc 2010-04-12  

其实这个问题换个问法就清楚了。

我们不需要建模了吗？

显然建模是需要的，即然如此，UML就是一个不错的选择。

44 楼 刃之舞 2010-04-12  

其实从OO来说，数据库表字段跟类中属性基本能对应。
所以维护数据库表结构关系，有个数据库表结构关系图看看就很明晰了。

pd12用的比较多，基本就是看表机构关系

不过还有个borland的architecture together这个用来生成数据库表结构文档，效果更好

43 楼 unsid 2010-04-11  

讨论到这个程度，我觉得不那么纠结了。

关于开源项目为什么找不到UML图的问题我不认为是上面某位朋友说的“apache有选择地发布文档，便于管理”，我觉得他们就是压根不画，他们是哪种喜欢用高质量代码直接说明问题的人。

42 楼 抛出异常的爱 2010-04-11  

if eles if else for while
画结构化的流程图大家应该都见过了。
相信大家也都应该画的不错


面向对象。。。。。
这利器一出。。。。。
再让你画个结构化流程图
根本没有用。。。。。。。

之后就有了UML
但用的人太少了
我学会之后全还大学老师了。。。。

41 楼 zhao3546 2010-04-11  

敏捷的核心理念之一就是： Adapting （适应）。

根据实际需要来决定UML是否对自己的项目有帮助。不过我个人感觉有时UML还是非常有用的。

40 楼 unsid 2010-04-11  

gdpglc 写道

unsid 写道

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

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

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

   个人觉得软件开发是一个复杂的过程，从最初的对用户需求的调研到最终的功能落实为代码，UML要做的是建模，而不是什么都管。在整个软件开发过程中都可以使用UML，它不只限于用来做设计的。
  
   我不认为UML是一个万能的符号语言，用来记录软件设计中的细节，如果这样，做多少它都不够。细节完全可以用自然语言或者代码来表达，而隐藏在代码和细节背后的模型，才需要UML。

你举的例子其实和我下边的问题的实质是一样的：

为什么UML画完之后是不可执行的呢？

对于设计来说：UML是用来表达软件背后的思想的，是用来表达软件的骨架的，画UML图最忌讳的就是大而全的图 。如果UML能用来刻画软件执行的每一个细节，又何需代码人员将它转化为代码？

你说这些，好象你认为开发是：设计人员用uml事先把什么都定好，然后给开发人员开发的。在这一样个开发过程里，首先不是UML对不对的事，我想首先是这样行不行得通的问题？难到设计人员什么都要替开发人员事先把怎么做想好？就算这样行， 这种分工，面对的主要挑战将是交流，而你把交流的责任全部推给UML，把交流的问题怪在UML上，有点偏激吧！

我觉得你的说法很有道理，我也这么想过，我只是很想从别人嘴里也听到这些东西。

我觉得基本可以认定这点“只要设计做的好，过程做的好，最终装配（实现者）的能力不重要”这点在制造业适用在软件行业不适用，按照你的说法，“不可变类”应该属于实现者该思考的问题，如果不做这样设计可能会对系统造成很大损伤，所以实现者能力依然决定项目是否成功,尽管设计的到位依然存在失败的风险，在软件开发团队中每一个人都很重要，这也是为什么软件业的优秀团队比其他行业更难组建的原因。

39 楼 gdpglc 2010-04-11  

unsid 写道

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

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

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

   个人觉得软件开发是一个复杂的过程，从最初的对用户需求的调研到最终的功能落实为代码，UML要做的是建模，而不是什么都管。在整个软件开发过程中都可以使用UML，它不只限于用来做设计的。
  
   我不认为UML是一个万能的符号语言，用来记录软件设计中的细节，如果这样，做多少它都不够。细节完全可以用自然语言或者代码来表达，而隐藏在代码和细节背后的模型，才需要UML。

你举的例子其实和我下边的问题的实质是一样的：

为什么UML画完之后是不可执行的呢？

对于设计来说：UML是用来表达软件背后的思想的，是用来表达软件的骨架的，画UML图最忌讳的就是大而全的图 。如果UML能用来刻画软件执行的每一个细节，又何需代码人员将它转化为代码？

你说这些，好象你认为开发是：设计人员用uml事先把什么都定好，然后给开发人员开发的。在这一样个开发过程里，首先不是UML对不对的事，我想首先是这样行不行得通的问题？难到设计人员什么都要替开发人员事先把怎么做想好？就算这样行， 这种分工，面对的主要挑战将是交流，而你把交流的责任全部推给UML，把交流的问题怪在UML上，有点偏激吧！