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是个好东西，但是大多公司由于需求变动而造成uml只是个摆设而以

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

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

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

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

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

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

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

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