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

本文轉自 trufun 51CTO部落格，原文連結：http://blog.51cto.com/trufun/295534，如需轉載請自行聯系原作者