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