我们不需要UML了么？

还是用来交流吧

给后辈，给同事，都这样

能迅速有个整体概念。

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

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

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

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

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

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

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

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

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

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

我刚出道的时候，做业务系统也很喜欢用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

"最后说一下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上，有点偏激吧！