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建模結合的問題。

UML建模與軟體開發過程模型

軟體開發過程模型

軟體開發過程及其模型

軟體開發過程

相關推薦