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