做業(yè)務系統(tǒng)很喜歡用uml來做分析和設計模型，很喜歡在rose中作以下事情：
1.以用戶需求作為輸入，做用例分析和領域模型設計，得到一個系統(tǒng)用例模型和領域模型
2.接下來就做模型遷移（轉換），將用例模型和領域模型轉換為特定語言環(huán)境的設計模型和數(shù)據(jù)庫模型，比如java和oracle，其中還可以在java組件上直接應用23種設計模式。
3.接下來將設計模型和數(shù)據(jù)庫模型正向工程為java代碼框架和數(shù)據(jù)庫建庫腳本（或者直接在數(shù)據(jù)庫中建表）
4.如果想將代碼或者數(shù)據(jù)庫表和設計模型或者數(shù)據(jù)庫模型保持同步，可以進行逆向工程（這些uml工具真的很強大）
4.接下來就是實現(xiàn)所有的代碼框架和編寫dao組件
5.最后可能的話還可以畫一個部署模型

整個路線圖看起來很好很強大很清晰，也很和諧。但是做到后來總是很困惑，可能是自己對uml把我不好或者是濫用了uml，那就是：分析模型和設計模型畫好后，代碼也寫了一部分了，結果客戶說他的需求要做大的變更。我傻眼了，需求的變化導致分析模型要調整，設計模型也要調整（你不要罵我做的模型不具備可擴展性），代碼也要做一部分的調整(記住只是一部分)，我該如何下手：
a.修改分析模型,然后將分析模型再轉換為設計模型，然后將設計模型再轉換為代碼模型（框架）和數(shù)據(jù)庫模型
b.直接修改分析模型,直接修改設計模型，直接修改代碼和數(shù)據(jù)庫模型
c.直接修改代碼和數(shù)據(jù)庫表，然后采用逆向工程方法同步先前的設計模型，數(shù)據(jù)庫模型，然后再逆向工程到分析模型（呵呵，這些uml工具確實很強大）

采用上述a,b，c三種方法都是一件很痛苦的事情，而且會導致分析模型，設計模型和代碼模型的不同步，另外，采用方法a很可能導致你已經編寫好的代碼和數(shù)據(jù)庫腳本被模型轉換出來的新代碼框架和數(shù)據(jù)庫腳本給覆蓋掉。這時你就徹底傻眼了，所有的代碼和腳本都得重新來過（誰知到以前的代碼是怎么寫的，有些人會說你不是有配置庫嗎，有版本管理嗎，把原來的代碼考回來不就是了，事情要是有這么簡單就好了，關鍵是你有這么多的時間去反反復復做這些事情嗎，項目的進度怎么保證，如果是在單純地玩玩uml也沒什么，關鍵咱們是在做項目）。
如果項目的規(guī)模比較大，大面積出現(xiàn)上述的情況，那么這個項目就很危險了，一般情況下項目都會以失敗而終結，當然這是我碰到的一般情況，可能您或者是大家碰到的情況要好些。

 

后來再也不去做那種傻事了，在項目中頂多用uml畫畫靜態(tài)的用例圖、類圖、實體關系圖（也叫分析模型，領域模型）以及動態(tài)的時序圖什么的，作為交流和溝通使用，或者作為文檔備案，這樣就夠了，不再去搞什么正向工程和逆向工程了，更多的時候只是用office word來畫幾個草圖，然后放到需求或者設計文檔中就可以了。

 

曾經聽一位uml培訓老師講到：只要架構師或者設計師將系統(tǒng)的體系架構和代碼框架設計好，剩下的事情只要程序員去填空就可以了。呵呵，我個人覺得這個老師很天真，也很單純，一個系統(tǒng)不可能就這么簡簡單單就出來了的，要不還要那么多迭代開發(fā)方法干什么。

最后說一下Hashmap與Entity的問題該怎么處理，之前我也不知道怎么處理，后來上面的那位uml培訓老師告訴我可以用uml 2.x中的組合結構圖(Compostion Construction diagram)來表示復雜的類結構，例如java中的內部類和匿名類。