第二部分 項目分析設計

第2章 項目開發流程與分析設計概述

作者希望通過這本書推廣一種最有效的學習與培訓方法：Project-driven training，也就是用項目實戰來帶動理論的學習。這里先介紹一些項目開發的背景知識。

2.1 項目開發流程RUP

RUP（Rational Unified Process）是目前最流行的一套項目開發流程模式，其基本特征是通過多次迭代完成一個項目的開發，每次迭代會帶來項目整體的遞增。如圖2-1所示。

縱向來看，項目的生命周期或工作流程包括：項目需求分析、系統分析和設計、實現、測試和維護。橫向來看，項目開發分為4個階段：起始（Inception）、細化（Elaboration）、建造（Construction）和移交（Transition），每個階段都包括一次或多次迭代。在每次迭代中，可以根據不同的要求或工作流（如需求、分析和設計等）投入不同的工作量，也就是說，在不同階段的每次迭代中，生命周期的每個步驟是同步進行的，但權重不同。這是與傳統瀑布式開發流程最大的區別。

項目生命周期具體如下。

1.項目需求分析

需求分析階段包括定義潛在的角色（角色指使用系統的人和與系統互相作用的軟、硬件環境）、識別問題域中的對象和關系、基于需求規范說明、角色的需要發現用例（use case）和詳細描述用例。

2.系統分析和設計

系統分析階段是基于問題和用戶需求的描述，建立現實世界的計算機實現模型。系統設計是結合問題域的知識和目標系統的體系結構（求解域），將目標系統分解為子系統，之后基于分析模型，添加細節，完成系統設計。

3.實現

又稱編碼或開發階段，也就是將設計轉換為特定的編程語言或硬件，同時保持先進性、靈活性和可擴展性。在這個階段，設計階段的類被轉換為使用面向對象編程語言編制（不推薦使用過程語言）的實際代碼。這一任務可能比較困難，也可能比較容易，主要取決于所使用的編程語言本身的能力。

4.測試和維護

測試是檢驗系統是否滿足用戶功能需求以便增加用戶對系統的信心。系統經過測試后整個開發流程便進入運行維護或新的功能擴展時期。

項目開發的4個階段具體如下。

1.起始階段（The Inception Phase）

對于新的開發項目來說，起始階段是很重要的，在項目繼續進行前，我們必須處理重要的業務與需求風險。對于那些增強現有系統的項目，起始階段是比較短暫的，但是其目的仍是確定該項目的實施價值及可行性。

起始階段有4個重要活動，分別為：

制定項目的范圍

計劃并準備業務案例

綜合得出備選構架

準備項目環境

2.細化階段（The Elaboration Phase）

細化階段的目標是為系統構架設立基線（baseline），為在構建階段開展的大量設計與實施工作打下堅實的基礎。構架是通過考慮最重要的需求與評估風險演進而來的。構架的穩定性是通過一個或多個構架原型（prototype）進行評估的。

3.構建階段（The Construction Phase）

構建的目標是完成系統開發。構建階段從某種意義上來說，可以看作是一個制造過程，其重點工作就是管理資源、控制操作以優化成本、日程和質量。從這個意義上來講，管理理念應該進行一個轉換，從起始階段和細化階段的知識產品開發轉換到構建和交付階段的部署產品的開發。

構建階段的每次迭代都具有三個關鍵活動：

管理資源與控制過程

開發與測試組件

對迭代進行評估

4.交付階段（Transition Phase）

交付階段的焦點是確保軟件對于最終用戶是可用的。交付階段包括為發布應用而進行產品的測試、在用戶反饋的基礎上做微小的調整等幾方面內容。在生命周期的這個時刻，用戶反饋主要集中在精確調整產品、配置、安裝，以及可用性等問題上。

交付階段的關鍵活動如下：

確定最終用戶支持資料

在用戶的環境中測試可交付的產品

基于用戶反饋精確調整產品

向最終用戶交付最終產品

2.2 UML概述

UML（Unified Modeling Language）是實現項目開發流程的一個重要工具，它是一套可視化建模語言，由各種圖來表達。圖就是用來顯示各種模型元素符號的實際圖形，這些元素經過特定的排列組合來闡明系統的某個特定部分或方面。一般來說，一個系統模型擁有多個不同類型的圖，一個圖是某個特定視圖的一部分。通常，圖是被分配給視圖來繪制的。另外，根據圖中顯示的內容，某些圖可以是多個不同視圖的組成部分。

圖具體分為靜態模型和動態模型兩大類。其中，靜態模型包括：

用例圖（Use-case Diagram）

類圖（Class Diagram）

對象圖（Object Diagram）

組件圖（Component Diagram）

部署圖Deployment diagrams

動態模型包括：

序列圖（Sequence Diagram）

協作圖（Collaboration Diagram）

狀態圖（State chart Diagram）

行為圖（Activity Diagram）

其中三種最常用的圖為：用例圖，類圖和序列圖。

2.2.1 用例圖

用例圖（Use-case Diagram）顯示多個外部參與者及他們與系統之間的交互和連接，如圖2-2所示。一個用例是對系統提供的某個功能（該系統的一個特定用法）的描述。雖然實際的用例通常用普通文本來描述，但是也可以利用一個活動圖來描述用例。用例僅僅描述系統參與者從外部觀察系統得到的那些功能，并不描述這些功能在系統內部是如何實現的，也就是說，用例定義系統的功能需求。

2.2.2 類圖

類圖（Class Diagram）用來顯示系統中各個類的靜態結構，如圖2-3所示。類代表系統內處理的事物，這些類可以以多種方式相互連接在一起，包括：關聯（類互相連接）、依賴（一個類依賴/使用另一個類）、特殊化（一個類是另一個類的特化）或者打包（多個類組合為一個單元）。所有的這些關系連同每個類的內部結構都在類圖中顯示。其中，一個類的內部結構是用該類的屬性和操作表示的。由于類圖所描述的結構在系統生命周期的任何一處都是有效的，所以通常認為類圖是靜態的。

我們常常會使用特殊化（Specialize）、一般化（Generalize）、特化（Specialization）和泛化（Generalization）這幾個術語來描述兩個類之間的關系。例如，對于一個類A（即父類）派生出另一個類B（即子類）這樣一個過程，也常常這樣描述：類A可以特殊化為類B，而類B可以一般化為類A；或者類A是類B的泛化，而類B是類A的特化。

一個系統一般都有多個類圖，（并不是所有的類都放在一個類圖中），并且一個類可以參與到多個類圖中。

2.2.3 對象圖

對象圖（Object Diagram）是類圖的一個變體，它使用的符號與類圖幾乎一樣。對象圖和類圖之間的區別是：對象圖用于顯示類的多個對象實例，而不是實際的類。所以，對象圖就是類圖的一個實例，顯示系統執行時的一個可能的快照——在某一時間點上系統可能呈現的樣子。雖然對象圖使用與類圖相同的符號，但是有兩處例外：用帶下畫線的對象名稱來表示對象和顯示一個關系中的所有實例，如圖2-4所示。

雖然對象圖沒有類圖那么重要，但是它們可以用于為一個復雜類圖提供示例，以顯示實際和關系可能的樣子。另外，對象圖也作為協作圖的一部分被使用，其作用是顯示一群對象之間的動態協作關系。

2.2.4 狀態圖

一般來說，狀態圖（State Diagram）是對類的描述的補充。它用于顯示類的對象可能具備的所有狀態，以及那些引起狀態改變的事件，如圖2-5所示。對象的一個事件可以是另一個對象向其發送的消息，例如到了某個指定的時刻，或者已經滿足了某條件。狀態的變化稱之為轉換（Transition）。一個轉換也可以有一個與之相連的動作，后者用以指定完成該狀態轉換應該執行的操作。

在實際建模時，并不需要為所有的類都繪制狀態圖，僅對那些具有多個明確狀態的類，并且類的這些不同狀態會影響和改變類的行為時才繪制類的狀態圖。另外，也可以為系統繪制整體狀態圖。

2.2.5 順序圖

順序圖（Sequence Diagram）顯示多個對象之間的動態協作，如圖2-6所示。順序圖重點是顯示對象之間發送的消息的時間順序，也顯示對象之間的交互，也就是在系統執行時，某個指定時間點將發生的事情。順序圖由多個用垂直線顯示的對象組成，圖中時間從上到下推移，并且順序圖顯示對象之間隨著時間的推移而交換的消息或函數。消息是用帶消息箭頭的直線表示的，并且位于垂直對象線之間。時間說明及其他注釋放到一個腳本中，并將其放置在順序圖的頁邊空白處。

2.2.6 協作圖

協作圖（Collaboration Diagram）像順序圖一樣顯示動態協作。為了顯示一個協作，通常需要在順序圖和協作圖之間作出選擇。除了顯示消息的交換（稱之為交互）外，協作圖也顯示對象及它們之間的關系（上下文）。通常，選擇順序圖還是協作圖的決定條件是：如果時間或順序是需要重點強調的方面，那么選擇順序圖；如果上下文是需要重點強調的方面，那么選擇協作圖。順序圖和協作圖都用于顯示對象之間的交互。

協作圖當做一個對象圖來繪制，它顯示多個對象及它們之間的關系（利用類/對象圖中的符號來繪制）。協作圖中對象之間繪制的箭頭顯示對象之間的消息流向。圖中的消息上放置標簽，用于顯示消息發送的順序。協作圖也可以顯示條件、迭代和返回值等信息。當開發人員熟悉消息標簽語法之后，就可以讀懂對象之間的協作及跟蹤執行流程和消息交換順序。除此之外，協作圖也可以包括活動對象，這些活動對象可以與其他活動對象并發執行，如圖2-7所示。

2.2.7 活動圖

活動圖（Activity Diagram）用于顯示一系列順序的活動，如圖2-8所示。盡管活動圖也可以用于描述像用例或交互這類的活動流程，但是一般來說，它主要還是用于描述在一個操作內執行的那些活動?；顒訄D由多個動作狀態組成，后者包含將被執行的活動（即一個動作）的規格說明。當動作完成后，動作狀態將會改變，轉換為一個新的狀態（在狀態圖內，狀態在進行轉換之前需要標明顯式的事件）。于是，控制就在這些互相連接的動作狀態之間流動。同時，在活動圖中也可以顯示決策和條件，以及動作狀態的并發執行。另外，活動圖也可以包含那些被發送或接收的消息的規格說明，這些消息是被執行動作的一部分。

2.2.8 組件圖

組件圖（Component Diagram）是用代碼組件來顯示代碼物理結構的。其中，組件可以是源代碼組件、二進制組件或一個可執行的組件。由于一個組件包含它所實現的一個或多個邏輯類的相關信息，于是就創建了一個從邏輯視圖到組件視圖的映射。根據組件圖中顯示的組件之間的依賴關系，可以很容易地分析出其中某個組件的變化將會對其他組件產生的影響。另外，組件也可以用它們輸出的任意接口來表示，并且可以被聚集在包內。一般來說，組件圖用于實際的編程工作中，如圖2-9所示。

2.2.9 部署圖

部署圖（Deployment Diagram）用于顯示系統中的硬件和軟件的物理結構。它可以顯示實際的計算機和設備（節點），同時還有它們之間的必要連接，也可以顯示這些連接的類型。在圖中顯示的節點內，已經分配了可執行的組件和對象，以顯示這些軟件單元分別在哪個節點上運行。另外，部署圖也可以顯示組件之間的依賴關系。

正如前面所說的那樣，顯示部署視圖的部署圖描述系統的實際物理結構，這與用例視圖的功能描述完全不同。但是，對一個明確定義的模型來說，可以實現從頭到尾的完整導航：從物理結構中的一個節點導航到分配給該節點的組件，再到該組件實現的類，接著到該類的對象參與的交互，最終到達用例。系統的不同視圖在總體上給系統一個一致的描述，如圖2-10所示。

2.3 小結

圖2-10 系統物理結構的部署圖

本章講解了項目開發的背景知識。首先介紹了項目開發流程RUP（Rational Unified Process），使讀者對RUP有了基本的了解，然后討論了UML（Unified Modeling Language），它是實現項目開發流程的一個重要工具，是一套可視化建模語言，由各種圖來表達。