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