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