UML建模與軟件開發(fā)過程模型
現(xiàn)在談到軟件開發(fā)過程，大家可能也不會(huì)陌生，學(xué)過軟件工程的人都能隨口說上幾個(gè)軟件過程模型，現(xiàn)在要把這兩種不同的模型拿到一起來討論，一方面是軟件開發(fā)的實(shí)際需要，另一方面也是UML建模工具要和其他面向?qū)ο箝_發(fā)模型結(jié)合的一種必然要求。
但是，OMG為了防止UML建模和某種開發(fā)過程模型結(jié)合過緊，導(dǎo)致其適應(yīng)性降低，使統(tǒng)一性大打折扣，從而影響UML建模工具的普及和推廣，只制定了語義規(guī)
則和表示符號(hào)，對于一個(gè)實(shí)際問題怎樣進(jìn)行建模，并未制定象數(shù)據(jù)庫設(shè)計(jì)范式那樣的規(guī)范和原則，對于一個(gè)項(xiàng)目，應(yīng)該先建什么模型，后建什么模型，也沒有做什么
限制。也就是說，沒有規(guī)定UML建模的工作過程和方法，UML建模可以適應(yīng)任何開發(fā)過程模型。
軟件開發(fā)過程模型的理論定義比較簡單，而把這一過程模型在實(shí)踐中應(yīng)用成功，卻有許多制約因素，首先是軟件的范圍，一個(gè)大型分布式軟件系統(tǒng)和一個(gè)單機(jī)版的個(gè)
人軟件系統(tǒng)在開發(fā)管理上肯定不同；其次軟件的開發(fā)目的，一個(gè)為了提高瀏覽量而開發(fā)的網(wǎng)站和一個(gè)為密集計(jì)算而開發(fā)的的一個(gè)處理系統(tǒng)在開發(fā)過程管理上肯定不
同。最后一點(diǎn)是團(tuán)隊(duì)，不同的團(tuán)隊(duì)在磨合度、個(gè)人能力、團(tuán)隊(duì)協(xié)作等方面各不相同，開發(fā)相同的項(xiàng)目使用相同的開發(fā)過程模型，開發(fā)結(jié)果完全不同的實(shí)例多得數(shù)不勝
數(shù)。另外，軟件復(fù)用是面向?qū)ο蟮囊淮筇攸c(diǎn)，它不但與所選擇的開發(fā)過程模型有關(guān)系，而且與企業(yè)文化和企業(yè)的做事方式有關(guān)。
上面這一些都說明，選擇或
設(shè)計(jì)一個(gè)好的，能夠反映軟件開發(fā)過程在什么時(shí)候做什么、如何作的過程模型并不是件容易的事。UML建模工具和統(tǒng)一過程（RUP）結(jié)合，是很多人熟知的理
論，這很大程度上得益于UML三位主要?jiǎng)?chuàng)始人的功勞，因?yàn)樗鼈冊餐鲞^一本關(guān)于UML與統(tǒng)一過程的書，另一方面是UML建模工具和統(tǒng)一過程的發(fā)源地都是
rational公司，也使人們誤認(rèn)為使用UML建模工具就得使用統(tǒng)一過程，事實(shí)上，UML自1.0版本以后，就歸OMG所有，而RUP不是OMG發(fā)布
的，只有OMG發(fā)布的信息，才能作為我們的行業(yè)標(biāo)準(zhǔn)。
一切先進(jìn)的思想，往往是融合了先前其他人的先進(jìn)思想，在介紹trufun的TUP建模過程之前，我們有必要回顧一下和UML建模結(jié)合的幾種軟件開發(fā)過程模型。
統(tǒng)
一過程（UP）模型：統(tǒng)一過程模型在和UML建模結(jié)合時(shí)，采用以用例為驅(qū)動(dòng)的方式，用用例連接所有活動(dòng)，每個(gè)活動(dòng)都建一組模型，如業(yè)務(wù)領(lǐng)域模型、責(zé)任領(lǐng)域
模型、實(shí)現(xiàn)模型、測試模型，每組模型中又由多個(gè)不同的角色共同協(xié)作完成，比如具有專門進(jìn)行用例建模的角色和組件建模的角色等等，采用增量迭代方式建立和完
善用例，并對每一次建模進(jìn)行評估，在項(xiàng)目的計(jì)劃、監(jiān)控等方面并非以建模為中心，而是把建模作為統(tǒng)一過程的一個(gè)小部分。該模型的主要缺點(diǎn)是周期長、人員要求
多、建模工作量大。
迭代模型：它是采用較多的小迭代來實(shí)現(xiàn)最終的模型，也就是說，模型圖是通過一系列步驟一步一步地建起來，每一次迭代都有新信息
添加到模型中來，每一次迭代都要經(jīng)過評估，都是下一次迭代的輸入，迭代會(huì)使系統(tǒng)開發(fā)的活動(dòng)（需求、分析、設(shè)計(jì)和測試）執(zhí)行多次，并且每次都有新的內(nèi)容增加
進(jìn)來。這個(gè)方法有一個(gè)缺點(diǎn)是在迭代的后期，仍然有新的需求增加進(jìn)來。
增量模型：增量模型開發(fā)每次迭代都能產(chǎn)生一個(gè)可執(zhí)行的結(jié)果，這個(gè)結(jié)果是一個(gè)可
“交付的”系統(tǒng)版本，每一次迭代要經(jīng)過評估，并且增加了一些新的功能，增量模型主要包括分析、設(shè)計(jì)、實(shí)現(xiàn)、測試四個(gè)活動(dòng)。該方法有一個(gè)很大缺點(diǎn)是到了項(xiàng)目
迭代后期還要進(jìn)行設(shè)計(jì)，會(huì)給系統(tǒng)帶來很大的風(fēng)險(xiǎn)。
XP模型：又叫極限編程，它是一個(gè)輕量級的、靈巧的軟件開發(fā)方法；同時(shí)它也是一個(gè)非常嚴(yán)謹(jǐn)和周密
的方法。它的基礎(chǔ)和價(jià)值觀是交流、樸素、反饋和勇氣；即，任何一個(gè)軟件項(xiàng)目都可以從四個(gè)方面入手進(jìn)行改善：加強(qiáng)交流；從簡單做起；尋求反饋；勇于實(shí)事求
是，整個(gè)開發(fā)是以測試為驅(qū)動(dòng)的，它屬于小型方法，對于初級軟件開發(fā)企業(yè)有效，無法站在軟件過程的行列談和UML建模結(jié)合的問題。