系統架構設計師學習之路（31）

6.3 基於UML的軟體開發過程

6.3.1 開發過程概述
UML是獨立於軟體開發過程的，即UML能夠在幾乎任何一種軟體開發過程中使用。
迭代的漸進式軟體開發過程包含4個階段：初啟、細化、構建、部署。
1.初啟
軟體專案的發起人確定專案的主要目標和範圍，並進行初步的可行性分析和經濟效益分析。
2.細化
細化階段的開始標誌著專案的正式確立。
（1）初步的需求分析
採用UML的用例描述目標軟體系統所有比較重要、比較有風險的用例；
採用用例圖表示參與者與用例以及用例與用例之間的關係；
採用類圖表示目標軟體系統所基於的應用領域中的概念與概念之間的關係。
這些相互關聯的概念構成領域模型。
領域模型一方面可以幫助軟體專案組理解業務背景，與業務專家進行有效溝通；
另一方面，隨著軟體開發階段的不斷推進，領域模型也將成為軟體結構的主要基礎。
如果領域中含有明顯的流程處理成分，可以考慮利用UML的活動圖來刻畫領域中的工作流，並標識業務流程中的併發、同步等特徵。
（2）初步的高層設計
如果目標軟體系統的規模比較龐大，那麼經初步需求分析獲得的用例和類將會非常多。此時，根據用例、類在業務領域中的關係，或者根據業務領域中某種有意義的分類方法將整個軟體系統劃分為若干個包，利用UML的包刻畫這些包及其間的關係。
（3）部分的詳細設計
對於系統中某些重要的或者風險比較高的用例，可以採用互動圖進一步探討其內部實現過程。同樣，對於系統的關鍵類，也可以詳細研究其屬性和操作，並在UML類圖中加以表現。
這裡倡導的軟體開發過程是根據軟體元素（用例、類等）的重要性和風險程度確立優先細化原則，建議軟體專案組優先考慮重要的、比較有風險的用例和類，不能將其延遲到細化階段之後。
（4）部分的原型構造
在許多情形下，針對某些複雜的用例構造可實際執行的原型是降低技術風險、讓使用者幫助軟體專案組確認使用者需求的最有效的方法。
為了構造原型，需要針對用例生成詳盡的互動圖，對所有相關類給出明確的屬性和操作定義。
綜上所述，在細化階段可能需要使用的UML語言機制包括描述使用者需求的用例及用例圖、表示領域概念模型的類圖、表示業務流程處理的活動圖、表示系統高層結構的包圖和表示用例內部實現過程的互動圖。
3.構建
開發人員通過一系列的迭代完成對所有用例的軟體實現工作，在每次迭代中實現一部分用例。以迭代方式實現所有用例的好處在於，使用者可以及早參與對已實現用例的世紀評價，並提出改進意見。這樣可有效降低大型軟體系統的開發風險。
在實際開始之前，有必要預先制定迭代計劃。計劃的制定需遵循如下兩項原則：
（1）使用者認為業務價值較大的用例應優先安排
（2）開發人員評估後認為開發風險較高的用例應優先安排。
在迭代計劃中，要確定迭代次數、每次迭代所需時間以及每次迭代中應完成（或部分完成）的用例。
每次迭代過程由針對用例的分析、設計、編碼、測試和整合5個子階段構成。在整合階段之後，使用者可以對用例的實現效果進行評價，並提出修改意見。這些修改意見可以在本次迭代過程中立即實現，也可以在下次迭代過程中再予以考慮。
構建過程中，需要使用UML的互動圖來設計用例的實現方法。為了與設計得出的互動圖協調一致，需要修改或精化在細化階段繪製的作為領域模型的類圖，增加一些為軟體實現所必須的類、類的屬性或方法。
在構建階段的每次迭代過程中，可以對細化階段繪製出的包圖進行修改或精化，以便包圖切實反映目標軟體系統最頂層的結構劃分情況。
綜上所述，在構建階段可能需要使用的UML語言機制包括：
（1）用例及用例圖。它們是開發人員在構造階段進行分析和設計的基礎。
（2）類圖。在領域概念模型的基礎上引進為軟體實現所必需的類、屬性和方法。
（3）互動圖。表示針對用例設計的軟體實現方法。
（4）狀態圖。表示類的物件的狀態-事件-相應行為。
（5）活動圖。表示複雜的演算法過程，尤其是過程中的併發和同步。
（6）包圖。表示目標軟體系統的頂層結構。
（7）構件圖。
（8）部署圖。
4.部署
在部署階段，開發人員將構造階段獲得的軟體系統在使用者實際工作環境（或接近實際的模擬環境）中試執行，根據使用者的修改意見進行少量調整。