第2章 IT項目開發流程與UML概述

2.1 項目開發流程

項目開發并不是一個簡單的過程，我們需要遵循一些開發流程。一個項目的開發會被分成很多步驟來實現，每一個步驟都有自己的起點和終點。也正如此，使得開發過程中每個步驟的起點和終點在不同的軟件項目中會出現不同難度的“坎”，使其難于達到該步驟開始或終結的條件，開發過程也就不會一帆風順。

不同的開發模式其實就是將步驟的起點和終點重新定義，甚至重新組合排列。雖然任何一個開發模式的最終目的都是完成軟件項目的開發，但期間所經歷的過程不一樣，過程步驟之間的起點和終點的定義不同，所帶來的“坎”也就不一樣，項目周期自然各不相同。因此，根據軟件項目的實際情況，選擇一種適合的開發模式能減少開發周期中“坎”的出現次數與難度，可以很大程度地縮短開發周期。

我們首先了解一下傳統瀑布式（Waterfall）開發流程，如圖2-1所示。

瀑布模型是由W.W.Royce在1970年首先提出的軟件開發模型。在瀑布模型中，開發被認為是按照需求分析、設計、實現、測試（確認）、集成和維護這一順序堅定而順暢地進行的。線性模型太理想化、太單純，以至于很多人認為瀑布模型已不再適合現代的軟件開發模式，幾乎被業界拋棄。

這里向大家推薦的是統一開發流程RUP（Rational Unified Process），它是目前最流行的一種項目開發流程模式，其基本特征是通過多次迭代完成一個項目的開發，每次迭代都會帶來項目整體的遞增，如圖2-2所示。

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

2.1.1 項目生命周期

1.需求分析

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

2.系統分析和設計

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

3.實現

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

4.測試和維護

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

2.1.2 項目開發階段

1.起始階段（Inception Phase）

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

起始階段有以下4個重要活動。

● 制定項目的范圍。

● 計劃并準備業務案例。

● 綜合分析，得出備選構架。

● 準備項目環境。

2.細化階段（Elaboration Phase）

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

3.構建階段（Construction Phase）

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

構建階段的每次迭代都具有以下3個關鍵活動。

● 管理資源與控制過程。

● 開發與測試組件。

● 對迭代進行評估。

4.交付階段（Transition Phase）

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

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

● 確定最終用戶支持資料。

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

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

● 向最終用戶交付最終產品。

最后，作為補充，再簡單介紹一種新的開發流程：敏捷開發和極限編程。

2001年，為了解決許多公司的軟件團隊陷入不斷增長的過程泥潭的問題，一批業界專家一起概括出了一些可以讓軟件開發團隊具有快速工作、響應變化能力的價值觀和原則，他們稱自己為敏捷聯盟。敏捷開發過程的方法有很多，主要有SCRUM、Crystal、特征驅動軟件開發（Feature Driven Development，FDD）、自適應軟件開發（Adaptive Software Development，ASD），以及最重要的極限編程（eXtreme Programming，XP）。

極限編程是一套快速開發高質量軟件所需的價值觀、原則和活動的集合，使軟件能以盡可能快的速度開發出來并向客戶提供最高的效益。XP在很多方面都和傳統意義上的軟件工程不同，同時，它也和傳統的管理和項目計劃的方法不同。這些方法在軟件工程和其他管理活動中都有借鑒意義。

XP具有12個過程，只有完全使用12個過程才是真正使用了XP，只是簡單地使用了其中的一個過程并不代表使用了XP。XP的12個過程如下：

● 現場客戶（On-site Customer）

● 計劃博弈（Planning Game）

● 系統隱喻（System Design）

● 簡化設計（Simple Design）

● 集體擁有代碼（Collective Code Ownership）

● 結對編程（Pair Programming）

● 測試驅動（Test-driver）

● 小型發布（Small Release）

● 重構（Refactoring）

● 持續集成（Continous Integration）

● 每周40小時工作制（40-hour Weeks）

● 代碼規范（Coding Standards）

下面是極限編程的有效實踐。

● 完整團隊XP項目的所有參與者（開發人員、客戶、測試人員等）一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的墻壁上隨意懸掛著大幅的、顯著的圖表，以及其他一些顯示進度的東西。

● 計劃博弈是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。

● 客戶測試作為選擇每個所期望特性的一部分，客戶可以根據腳本語言定義出自動驗收測試以表明該特性可以工作。

● 簡單設計團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重復，表達出了編寫者想表達的所有東西，并且包含盡可能少的代碼。

● 結對編程：所有的產品軟件都是由兩個程序員并排坐在一起在同一臺機器上構建的。

● 測試驅動開發：編寫單元測試是一個驗證行為，更是一個設計行為。同樣，它更是一種編寫文檔的行為。編寫單元測試避免了相當數量的反饋循環，尤其是功能驗證方面的反饋循環。程序員以非常短的循環周期工作，他們先增加一個失敗的測試，然后使之通過。

● 改進設計隨時利用重構方法改進已經腐化的代碼，使代碼盡可能地干凈，具有表達力。

● 持續集成團隊總是使系統完整地被集成。一個人拆入（Check in）后，其他所有人負責代碼集成。

● 集體擁有代碼：任何結對的程序員都可以在任何時候改進任何代碼。沒有程序員對任何一個特定的模塊或技術單獨負責，每個人都可以參與任何其他方面的開發。

● 編碼標準系統中所有的代碼看起來就好像是由一人單獨編寫的。

● 系統隱喻：將整個系統聯系在一起的全局視圖，它是系統的未來影像，使所有單獨模塊的位置和外觀變得明顯、直觀。如果模塊的外觀與整個隱喻不符，那么就會知道該模塊是錯誤的。

● 可持續的速度團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，保存精力，把項目看做是馬拉松長跑，而不是全速短跑。

極限編程是一組簡單、具體的實踐，這些實踐結合在一起形成了一個敏捷開發過程。極限編程是一種優良的、通用的軟件開發方法，項目團隊可以拿來直接采用，也可以增加一些實踐，或者對其中的一些實踐進行修改后再采用。

2.2 UML概述

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

2.2.1 UML圖

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

● 用例圖（Use Case Diagram）

● 類圖（Class Diagram）

● 對象圖（Object Diagram）

● 組件圖（Component Diagram）

● 部署圖（Deployment Diagram）

動態模型包括：

● 序列圖（Sequence Diagram）

● 協作圖（Collaboration Diagram）

● 狀態圖（State Diagram）

● 活動圖（Activity Diagram）

具體見表2-1。

1.用例圖

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

2.類圖

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

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

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

3.對象圖

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

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

4.組件圖

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

5.部署圖

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

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

6.序列圖

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

7.協作圖

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

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

8.狀態圖

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

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

9.活動圖

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

2.2.2 UML建模工具及使用

1.Rational Rose工具簡介

在使用UML進行面向對象分析設計工作中，我們常常使用一些工具。Rational Rose就是這樣一種UML建模工具，它可以提供建立、修改和操作Rose視圖的功能。Rose運行環境為Windows NT、Windows 95、UNIX（Solaris、HP/UX、AIX、DEC Unix），Rose支持Unified、Booch、OMT標記法。

在Rose中有4種視圖，分別是Use Case視圖、邏輯視圖、組件視圖和拓撲視圖。

（1）Use Case視圖

Use Case視圖中包含以下圖形：

① Use Case圖：包、actors、Use Case和關系。

② 交互圖（序列圖或協同圖）：對象和消息。

Use Case圖描述了存在的actors（外部系統）、Use Case（該系統應該執行什么）及它們的關系。Use Case圖可以描述該系統中部分或全部的Use Case。交互圖描述了系統在邏輯設計中存在的對象及其間的關系，它可以代表系統中對象的結構。Rose中包含兩種交互圖，它們對同一交互操作提供了不同的瀏覽視角。

● 序列圖：按時間順序排列對象的交互操作。

● 協作圖：圍繞對象及其間的連接關系組織對象的交互操作。

（2）邏輯視圖

邏輯視圖中的元素可以用一種或多種圖形來表示。邏輯視圖中可以包含以下圖形：

① 類圖：包、類和類的關系。

② 狀態圖：狀態、事件和轉換關系。

類圖是描述系統的靜態視圖，它描述了系統邏輯設計中存在的包、類及它們的關系。類圖可以代表該系統中部分或全部的類結構，在模型中有一些典型的類圖。

狀態圖描述了給定類的狀態轉換空間；導致狀態轉換的事件；導致狀態改變的動作。

（3）組件視圖

組件視圖中的元素可以在一個或多個組件圖中被瀏覽。

組件圖描述了在系統物理設計中組件中類和對象的分配情況，組件圖可以代表系統中部分或全部的組件結構。組件圖描述了包、組件、依賴關系。

（4）拓撲視圖

拓撲視圖中的元素可以在拓撲圖形中被瀏覽，拓撲視圖只能包含一個拓撲圖形。拓撲視圖描述了一個系統在物理設計階段進程處理的分配情況。

2.Rational Rose的使用

（1）用例圖

① 右鍵單擊“Use Case View”，選擇“New→Use Case Diagram”，新建用例圖視窗，如圖2-12所示。

② 單擊工具欄中的“Use Case”工具，在視窗中單擊便可添加用例；也可以右鍵單擊“Use Case View”，選擇“New→Use Case”添加用例，然后按住左鍵將添加的用例拖入視窗中使用（見圖2-13）。

③ 雙擊用例或者右鍵單擊用例，選擇“Open Specification...”（見圖2-14），在彈出的對話框中設置用例屬性，如圖2-15所示。

④ 單擊工具欄上的“Actor”工具，在視窗中單擊便可添加角色；也可以右鍵單擊“Use Case View”，選擇“New→Actor”添加角色，然后按住左鍵將添加的角色拖入視窗中使用（見圖2-16）。

⑤ 雙擊角色或右鍵單擊角色，選擇“Open Specification...”（見圖2-17），在彈出的對話框中設置角色屬性，如圖2-18所示。

⑥ 使用工具欄上的“Unidirectional Association”工具添加角色與用例之間的關聯。單擊“Unidirectional Association”選擇角色，按住左鍵拖向該角色應有的用例。

完整的用例圖實例如圖2-19所示。

（2）類圖

① 右鍵單擊“Use Case View”，選擇“New→Class Diagram”新建類圖視窗，如圖2-20所示。

② 單擊工具欄上的“Class”工具，在視窗中單擊便可添加類；也可以右鍵單擊“Use Case View”，選擇“New→Class”添加類，然后按住左鍵將添加的類拖入視窗中使用，如圖2-21所示。

③ 雙擊類或右鍵單擊類，選擇“Open Specification...”（見圖2-22），在彈出的對話框中為該類添加方法和屬性，如圖2-23所示。

④ 單擊工具欄上的“Interface”工具添加接口。

⑤ 雙擊接口或右鍵單擊接口，選擇“Open Specification...”（見圖2-24），在彈出的對話框中為該接口添加方法，如圖2-25所示。

⑥ 添加類的繼承關系和接口的實現（見圖2-26）。用“Generalization”工具描述類的繼承，用“Realize”工具描述接口的實現，用“Dependency or instantiates”工具描述依賴。

完整的類圖實例如圖2-27所示。

（3）序列圖

① 右鍵單擊“Use Case View”，選擇“New→Sequence Diagram”新建序列圖視窗，如圖2-28所示。

② 單擊工具欄上的“Object”工具添加對象，雙擊選擇對應類或接口；也可以按住左鍵把已經生成的類和接口拖入序列圖視窗中使用，如圖2-29所示。

③ 用工具欄中的“Object Message”工具表示執行順序，用工具欄中的“Return Message”工具表示返回，如圖2-30所示。

④ 雙擊Object Message和Return Message添加說明，如圖2-31和圖2-32所示。

完整的序列圖實例如圖2-33所示。

另外一個常用建模工具是Microsoft Visio，接下來我們介紹Visio的使用方法。

3.Microsoft Visio工具簡介

Microsoft Office Visio提供的模板、形狀和繪圖工具可用于創建有效的業務圖表和技術圖表。使用Visio Standard，可以分析業務流程、安排項目日程、形象地表達思維過程以及繪制組織結構圖。使用Visio Professional，除了可以完成上述任務外，還可以形象地顯示網絡基礎設施、平面布置圖、公共設施設備、電路、軟件系統和數據庫結構。

在熟悉的Microsoft環境中工作時，您還可以通過導入數據來創建圖表、從圖表中導出數據、使用圖表存儲數據、根據存儲的數據生成報告以及將圖表并入Microsoft Office文件。

Microsoft Visio有助于IT和商務專業人員輕松地查看、分析和交流復雜的信息。它能夠將難以理解的復雜文本和表格轉換為一目了然的Visio圖表。該軟件通過創建與數據相關的Visio圖表來顯示數據，這些圖表易于刷新，并能夠顯著提高生產效率。使用Office Visio中的各種圖表可了解、操作和共享企業內組織系統、資源和流程的有關信息。

Office Visio提供了各種模板：業務流程的流程圖、網絡圖、工作流圖、數據庫模型圖和軟件圖，這些模板可用于可視化和簡化業務流程、跟蹤項目和資源、繪制組織結構圖、映射網絡、繪制建筑地圖以及優化系統。

4.Microsoft Visio的使用

（1）用例圖

① 依次單擊“文件→新建→軟件→UML模型圖”，如圖2-34所示。

② 單擊左側工具欄中的“UML用例”工具，將需要添加的用例按住左鍵拖入視窗中使用，如圖2-35所示。

③ 雙擊用例或右鍵單擊用例，在彈出的快捷菜單中選擇“屬性”命令，在接下來彈出的對話框中設置用例屬性，如圖2-36和圖2-37所示。

④ 單擊工具欄中的“UML用例”工具，然后將要添加的角色按住左鍵拖入視窗中使用，如圖2-38所示。

⑤ 雙擊角色或右鍵單擊角色，在彈出的快捷菜單中選擇“屬性”命令，在接下來彈出的對話框中設置角色屬性，如圖2-39和圖2-40所示。

⑥ 用工具欄中的“用”工具添加角色與用例之間的關聯。單擊“用”，接著選擇角色，然后按住左鍵拖向該角色的應用用例，如圖2-41所示。

完整的用例圖實例如圖2-42所示。

（2）類圖

① 依次單擊“文件→新建→軟件→UML模型圖”，如圖2-43所示。

② 單擊工具欄中的“類”工具，然后將添加的類按住左鍵拖入視窗中使用，如圖2-44所示。

③ 雙擊類或右鍵單擊類，在彈出的快捷菜單中選擇“屬性”命令，在接下來彈出的對話框中為該類添加方法和屬性，如圖2-45和圖2-46所示。

④ 單擊工具欄中的“接口”工具，然后將添加的接口按住左鍵拖入視窗中使用，如圖2-47所示。

⑤ 雙擊接口或右鍵單擊接口，在彈出的快捷菜單中選擇“屬性”命令，在接下來彈出的對話框中為該接口添加方法，如圖2-48和圖2-49所示。

⑥ 添加類的繼承關系和接口的實現。用“泛化”工具描述類的繼承；用“泛化”工具描述接口的實現，但需要對其進行更改；用“依賴關系”工具描述依賴。利用“泛化”工具實現接口的時候，要把線的格式改為虛線，如圖2-50 和圖2-51 所示。操作方法：右鍵單擊線條，選擇“格式→線條”，將圖案選項改為虛線格式即可。

完整的類圖實例如圖2-52所示。

（3）序列圖

① 依次單擊“文件→新建→軟件→UML模型圖”，如圖2-53所示。

② 單擊工具欄中的“UML序列→對象生命線”工具添加對象，按住左鍵拖入到序列圖視窗中使用，如圖2-54所示。

③ 雙擊對象生命線，在彈出的對話框中對其屬性進行更改，如圖2-55所示。

④ 用工具欄中的“消息”工具表示執行順序，用工具欄中的“消息（返回）”工具表示返回，用工具欄中的“激活”工具表示對象或方法的激活操作，效果如圖2-56所示。

⑤ 雙擊“消息”和“消息返回”，在彈出的對話框中添加說明，如圖2-57所示。

完整的序列圖實例如圖2-58所示。

在本書后面的內容中，我們會使用UML工具和圖形來進行需求分析和系統分析設計等工作。