3.1 分析設計過程簡介

為了能夠有效地進行軟件系統的分析和設計，需要將各個技術層次合理地、適時地結合在一起，這就需要遵循一定的過程，也就是軟件工程過程所要求的內容。雖然UML提供了有效地表達分析和設計思想的手段，但是如何合理地、適時地利用這些手段去進行分析和設計是UML所不能提供的。因此，從本質上來講，UML僅僅是一種標準的表達形式，它提供了統一的符號體系，使人們擺脫了符號之間的困擾，從而可以專心面對業務問題。而用好UML除了需要掌握面向對象分析和設計的基本原則和方法外，還需要借助一定的軟件開發過程。

與UML配套的軟件工程過程很多，其中應用最廣的還是與UML同出一門的Rational統一過程（Rational Unified Process, RUP）。Rational統一過程是一個龐大的、應用于企業應用開發的工程過程，它提供了如何在開發組織中嚴格分配任務和職責的方法，其目標是按照預先制定的時間計劃和經費預算，開發高質量的軟件產品以滿足用戶的需求，其核心思想是用例驅動、以架構為中心的迭代增量開發。本書并不是一本介紹過程的書，但是為了能夠有效地進行分析和設計，還必須采納一定的過程，而RUP過程本身過于復雜，并不符合本書的學習要求。因此本書在借鑒RUP思想的基礎上，定義了重點關注分析和設計的簡化過程，這樣既保證能夠按照有效的過程進行分析和設計，又不會因為過于復雜的過程而影響到對分析和設計方法的學習。

3.1.1 UML分析設計過程解析

本書所討論的UML分析設計過程起始于業務建模，接下來是需求建模、用例分析、架構設計和構件設計，最后終止于代碼實現。本書的后續內容將按照這個過程展開。當然，這個過程并不是完整的軟件開發過程（如缺少計劃、管理、測試、維護等方面的內容），這里重點關注的是分析和設計。此外，書中對于這些階段的描述是線性的，但在實際應用過程中它應該是一個迭代增量的過程。這個過程如圖3-1所示，框內的圖示是相關階段所要使用的主要的UML圖例。

（1）業務建模：采用軟件建模方法分析和理解待開發的業務，描述業務流程；其目標是認識業務本質，該業務本質是后續用例建模的基礎。此部分內容對應本書第3章。

（2）用例建模：采用UML用例建模技術描述軟件需求，該需求模型將為后續用例分析提供輸入。此部分內容對應本書第4章。

（3）用例分析：采用UML用例分析技術分析軟件需求，建立軟件系統的分析模型。此部分內容對應本書第5章。

（4）架構設計：在系統的全局范圍內，以分析模型為基礎，設計系統的架構。此部分內容對應本書第8章（第6章和第7章是設計的基礎理論）。

（5）構件設計：根據架構設計的成果，將分析模型細化，設計系統構件的實現細節。此部分內容對應本書第9章。

（6）代碼實現：將系統構件映射到目標語言上。此部分內容對應本書第10章。

3.1.2 結合過程應用UML

UML和過程本身并不存在嚴格的對應關系，它們之間是一種多對多的關系；不同的過程、不同的階段對UML使用有不同的要求。如RUP方法中提供了4個階段9個工作流的二維過程模式，但是在某個特定的階段、對于特定的工作流采用何種UML模型進行建模，這些在RUP中并沒有做強制的規定。不過RUP卻提供了很多最佳實踐，這些最佳實踐提醒用戶只有合理地利用UML，才能發揮RUP方法的特點。

關于UML和過程的關系可以采用一個形象的比喻：過程是一種“戰術”，它決定了項目團隊如何去合理地安排資源、進度或人員；而UML則是一種“作戰技能”，是團隊成員的使能技術，再好的戰術缺少合適的人去執行也是空談。這兩者之間是相輔相成的。

本書在定義UML分析設計過程時，給讀者提供了一些可參考的最佳實踐。正如圖3-1所示，每個階段都有不同的UML模型去支撐。在業務階段，采用擴展的業務用例模型進行業務建模，采用活動模型進行業務流程的細化。在用例建模階段，采用用例模型進行需求建模，采用用例文檔來詳述需求。在用例分析階段，采用擴展的類模型表示靜態關系，采用交互模型表示動態交互。在設計階段則采用包、構件、部署等模型表示軟件架構，采用靜態類圖、動態交互圖、狀態模型來進行詳細的類設計。在代碼實現階段，則根據設計類圖、設計交互圖生成代碼。這些模型的細節和使用方式將在本書的后續章節中詳細展開討論。

圖3-1給出的是一個相對完整的在系統開發過程中使用UML的示意圖。在項目實踐過程中，團隊可以根據自身的實際情況逐步引入不同的UML模型。早期，可以只在需求階段采用用例建模技術，后續過程仍沿用以前傳統的方式進行分析和設計。在此基礎上，下一步可以利用UML類圖進行靜態分析和設計。最后，可以更進一步使用UML交互模型進行動態分析和設計，從而使用UML模型覆蓋項目的全生命周期。