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中的内部类和匿名类。

评论

17 楼 crane136 2011-01-30  

UML是标准语言，但是具体的项目要具体分析，不一定每个项目都是需要这么标准严格。
项目总结时，将UML包含进来供后续的跟踪和更新也是不错的选择。

16 楼 liyan1709 2011-01-26  

UML，只是一种手段，一种交流的方式；楼主先前的做法太教条化了，自己也体验到了同步模型的痛苦。软件开发的最终目的是软件产品，其他都是为这个目的服务的。所以不管是各种模式、各种模型、各种开发方法，只可借鉴，不可死搬硬套，还是仔细分析自己项目的具体情况，借助这些方法论的东西，最主要是体会其中的思想，才能和项目完美的结合，不至于陷入僵局

15 楼 yangguo 2010-04-30  

这个跟是否该画UML图，画到什么程度，画些什么图半毛钱关系也没有。

大量的翻工原因是软件工程本身没有被有序执行。需求没有搞定就已经开始编码了。上层的改动必然导致下层一层一层的变化。

UML是基于软件工程的，而中国的软件公司只有浮躁两个字，根本就没有严格执行软件工程的，所以你却照搬UML那套来用，翻跟斗是必然的。

14 楼 yin_bp 2010-04-27  

不可否认uml确实是表述我们软件设计和需求分析的最好的预言了，呵呵，因此uml掌握的好的话，那么就能非常好地用他来描述我们软件的体系结构和基本思路，正所谓工欲善其事、必先利其器也就是这个意思吧，凡是把握个度就好。
真的有个时候想用个什么符号来表述一下某个意思，左想右想硬是找不到合适的来表述，但是了解uml的话，可能里面有很多符号可以非常合适地恰当地描述你的思想和意图。真是千里寻他千百度，原来它就在你手里，呵呵。

13 楼 修己安人 2010-04-27  

UML用来描述思路是非常不错的。
但要做到相当的规范，是很困难的，是需要付出很高的代价的。
因此，我们使用UML要做一个权衡。在粗细粒度上做出选择。

12 楼 wmteo77 2010-04-27  

惭愧，都是画些简单的草图，估计连uml都不是，顶多是业务模型

11 楼 yin_bp 2010-04-27  

xiao-qiang163 写道

楼主好像对你的老师很不服气啊呀， 

我觉得人啊，还是应该学会回报，几年前，别人教你！你现在牛了，就说别人天真？？？

其实，框架这个东西，你用 UML 画出来，也可以，直接以代码表现快速搭环境，也可以，

任何事都不是一成不变的，要看项目的紧迫度，我觉得，


一个很小的项目，又是很急，难道你还要用  UML画，一个一个地画，再产生代码？？ 有必要吗 ？  像这种情况，框架师可以把代码大概写一下，让工程师有个整体的概念，有很多事，可以等项目后期再完善，以备将来维护，

呵呵，说实话，我很佩服这位老师，uml的培训课程讲得非常不错，是我听过的培训里面讲得最棒的老师，另外，我是最近一个月才听他讲的课，然后有感而发，才写的这个帖子，写这个帖子的意思不是说我很牛，也并没有真正地说这个老师天真呵呵，只是有感而发，希望大家不要误会我的意思。

10 楼 xiao-qiang163 2010-04-27  

楼主好像对你的老师很不服气啊呀， 

我觉得人啊，还是应该学会回报，几年前，别人教你！你现在牛了，就说别人天真？？？

其实，框架这个东西，你用 UML 画出来，也可以，直接以代码表现快速搭环境，也可以，

任何事都不是一成不变的，要看项目的紧迫度，我觉得，


一个很小的项目，又是很急，难道你还要用  UML画，一个一个地画，再产生代码？？ 有必要吗 ？  像这种情况，框架师可以把代码大概写一下，让工程师有个整体的概念，有很多事，可以等项目后期再完善，以备将来维护，

9 楼 jyslb 2010-04-25  

比较熟悉和经常使用class diagram, activity diagram, state diagram, use case diagram, sequence diagrame，其他不怎么用

8 楼 liwenjie 2010-04-23  

还是按照敏捷的思想不到非常需要这个文档就不写这个文档，UML图也是一样。但是我发现使用UML把设计意图表达出来第一非常清晰。
第二容易发现设计的问题和逻辑的缺漏，比如实体间的关系，反正图上就这些实体，那么我们一一检查两者关系好了。我个人进行设计、交流的时候使用UML，通常是2个或者多人，每个人先有自己的想法然后边讨论，边画图，图也画好了，设计也出来了，做到非常清晰，并且可以作为以后工作交接、备忘的设计文档，如果以后有改动，就把图拿出来，在上面修改，这样也做到了设计与文档同步。我不太建议用UML生成代码，我很推荐headfirst 设计模式中的UML，只要能清晰地说明设计意图最好，哪怕不是特别的正规。比如包图、类图，反映了其之间的关联、依赖关系就好，哪怕在上面加上了数据流向。
我个人用visio画图。

7 楼 zhangdaiping 2010-04-22  

piao_bo_yi 写道

LZ的UML一定用得很熟练。我觉得LZ前期的确是正向工程和逆向工程整过度了。同意LZ后期做法，仅保存对于理解系统所必要的图就可以了。
关于那句“架构师或者设计师将系统的体系架构和代码框架设计好，剩下的事情只要程序员去填空就可以了”，其实不是不可能的。很多对日外包就是这么做的。我觉得很牛。不过这也不等于人家没有迭代。
LZ说的那个ENTITY和HASHMAP的问题是什么意思，能描述下吗？

小日本的这种开发成本很高，所以填空的事都是找成本低的地方来做，比如国内。

6 楼 yin_bp 2010-04-19  

ENTITY和HASHMAP的问题指的是怎么用uml中的图来表述java中的匿名类、内部类和主体类之间的关系，呵呵，ENTITY对应Map中的内部类Map.Entry ，需要用uml图来表述一个复杂关系的例子。

5 楼 piao_bo_yi 2010-04-19  

LZ的UML一定用得很熟练。我觉得LZ前期的确是正向工程和逆向工程整过度了。同意LZ后期做法，仅保存对于理解系统所必要的图就可以了。
关于那句“架构师或者设计师将系统的体系架构和代码框架设计好，剩下的事情只要程序员去填空就可以了”，其实不是不可能的。很多对日外包就是这么做的。我觉得很牛。不过这也不等于人家没有迭代。
LZ说的那个ENTITY和HASHMAP的问题是什么意思，能描述下吗？

4 楼 yin_bp 2010-04-19  

关键看我们对这些uml工具掌握的熟练程度，掌握得好就能够利用其很好地表述我们业务需求和业务流程

3 楼 mouse5s306 2010-04-18  

培训的过程往往让人感觉事情很美好。
但到实际中，情景就颠覆了。
培训灌输的东西只能够做借鉴，该怎么处理还是应该从项目的实际情况出发。

2 楼 chenjianjx 2010-04-13  

Correct!
UML只应该用于沟通，而且必须是粗粒度的。想知道细粒度的设计，去看看代码。

1 楼 huatu122 2010-04-13  

uml是个好东西，但是大多公司由于需求变动而造成uml只是个摆设而以