整個路線圖看起來很好很強大很清晰，也很和諧。但是做到后來總是很困惑，可能是自己對uml把我不好或者是濫用了uml，那就是：分析模型和設(shè)計模型畫好后，代碼也寫了一部分了，結(jié)果客戶說他的需求要做大的變更。我傻眼了，需求的變化導(dǎo)致分析模型要調(diào)整，設(shè)計模型也要調(diào)整（你不要罵我做的模型不具備可擴展性），代碼也要做一部分的調(diào)整(記住只是一部分)，我該如何下手：
a.修改分析模型,然后將分析模型再轉(zhuǎn)換為設(shè)計模型，然后將設(shè)計模型再轉(zhuǎn)換為代碼模型（框架）和數(shù)據(jù)庫模型
b.直接修改分析模型,直接修改設(shè)計模型，直接修改代碼和數(shù)據(jù)庫模型
c.直接修改代碼和數(shù)據(jù)庫表，然后采用逆向工程方法同步先前的設(shè)計模型，數(shù)據(jù)庫模型，然后再逆向工程到分析模型（呵呵，這些uml工具確實很強大）
采用上述a,b，c三種方法都是一件很痛苦的事情，而且會導(dǎo)致分析模型，設(shè)計模型和代碼模型的不同步，另外，采用方法a很可能導(dǎo)致你已經(jīng)編寫好的代碼和數(shù)據(jù)庫腳本被模型轉(zhuǎn)換出來的新代碼框架和數(shù)據(jù)庫腳本給覆蓋掉。這時你就徹底傻眼了，所有的代碼和腳本都得重新來過（誰知到以前的代碼是怎么寫的，有些人會說你不是有配置庫嗎，有版本管理嗎，把原來的代碼考回來不就是了，事情要是有這么簡單就好了，關(guān)鍵是你有這么多的時間去反反復(fù)復(fù)做這些事情嗎，項目的進度怎么保證，如果是在單純地玩玩uml也沒什么，關(guān)鍵咱們是在做項目）。
如果項目的規(guī)模比較大，大面積出現(xiàn)上述的情況，那么這個項目就很危險了，一般情況下項目都會以失敗而終結(jié)，當然這是我碰到的一般情況，可能您或者是大家碰到的情況要好些。
后來再也不去做那種傻事了，在項目中頂多用uml畫畫靜態(tài)的用例圖、類圖、實體關(guān)系圖（也叫分析模型，領(lǐng)域模型）以及動態(tài)的時序圖什么的，作為交流和溝通使用，或者作為文檔備案，這樣就夠了，不再去搞什么正向工程和逆向工程了，更多的時候只是用office word來畫幾個草圖，然后放到需求或者設(shè)計文檔中就可以了。
曾經(jīng)聽一位uml培訓(xùn)老師講到：只要架構(gòu)師或者設(shè)計師將系統(tǒng)的體系架構(gòu)和代碼框架設(shè)計好，剩下的事情只要程序員去填空就可以了。呵呵，我個人覺得這個老師很天真，也很單純，一個系統(tǒng)不可能就這么簡簡單單就出來了的，要不還要那么多迭代開發(fā)方法干什么。
最后說一下Hashmap與Entity的問題該怎么處理，之前我也不知道怎么處理，后來上面的那位uml培訓(xùn)老師告訴我可以用uml 2.x中的組合結(jié)構(gòu)圖(Compostion Construction diagram)來表示復(fù)雜的類結(jié)構(gòu)，例如java中的內(nèi)部類和匿名類。
