UML基礎與Rose建模實訓教程

目  錄

 

第1章  初識UML. 1

1.1 初識UML用例圖... 1

1.2 初識UML類圖... 3

第2章  Rational Rose工具... 6

2.1 安裝與配置Rational Rose. 6

2.2 使用Rational Rose建模... 15

第3章  用例模型... 20

3.1 參與者... 20

3.2 用例... 28

3.3用例模型中的關係... 37

第4章  靜態模型... 49

4.1 類圖中的事物... 49

4.2 類圖中的關係... 66

第5章  時序圖... 80

第6章  協做圖... 95

第7章  狀態圖... 108

第8章  活動圖... 122

第9章  物理模型... 139

9.1 組件圖（Component Diagram）... 139

9.2 部署圖（Deployment Diagram）... 160

第10章  雙向工程... 167

10.1 正向工程... 167

10.2 逆向工程... 177

第11章  綜合案例實訓... 182

11.1 BBS論壇系統... 182

11.2 基於Web的求職招聘系統... 205

附錄  Rational Rose 2003菜單... 220

 

 

第1章  初識UML 

UML（Unified Modeling Language，統一建模語言）是描述、構造和文檔化系統（尤爲是面向對象軟件）製品的可視化語言，是用於面向對象建模圖形化表示法的事實標準和法律標準。UML用來描述模型內容的基本構造塊有三種：事物（Things）、關係（Relationships）和圖（Diagrams）。事物是實體抽象化的結果，關係是事物鏈接的方式，圖是事物和關係的組合，在後續的各章節中會逐步介紹其詳細內容，本章主要經過兩個實驗，來初步瞭解UML中的用例圖和類圖。本章在全書知識體系中的位置如圖1.1所示。

 

1.1 初識UML用例圖

1.1.1 相關知識點

1. 什麼是用例圖

用例圖用於展現系統的參與者（也稱角色）、用例（也稱用況）及其相互關係。其中參與者指的是系統用戶，用例指的是系統功能。用例圖僅從參與者使用系統的角度描述系統信息，即處在系統外部分析系統功能，並不涉及系統內部對該功能的具體操做。用例圖在定義系統功能需求時最爲有用。

2. 如何繪製用例圖

藉助用例圖來描述系統需求通常可分三個步驟：首先，肯定系統角色即參與者；其次，肯定系統功能即用例；最後，肯定系統中涉及到的關係（包括參與者之間的關係、參與者和用例之間的關係、用例之間的關係）。

在具體應用時，可輔以建模工具（如Microsoft Office Visio、Sybase PowerDesigner、IBM Rational Rose等）將其描繪出來。

1.1.2 知識點的能力目標

可以初步識別UML用例圖中的參與者、用例及其關係，可以根據用例圖對系統需求進行簡單描述。

1.1.3 實現能力目標的具體要求

1. 識別「CD銷售系統」用例圖。

2. 根據用例圖，對「CD銷售系統」的功能需求進行簡單描述。

1.1.4 須要完成的實驗

1. 識別「CD銷售系統」用例圖

如圖1.2所示爲「CD銷售系統」的用例圖。其中參與者表示爲小人圖形，如Band Manager（樂隊經理）、Disc Manager（唱片經理）、Rank Service（排行榜報告服務）；用例表示爲橢圓圖形，如Browse CD Sale（查看樂隊CD的銷售統計）、Browse Rank（查看排行榜報告）、Search CD Sale（查看特定CD的銷售統計）、Search New Rank（檢索最新的排行榜報告）；其中關聯關係表示爲實型直線，如Band Manager和Browse CD Sale之間、Rank Service和Search New Rank之間的連線。

 

2. 根據用例圖，對「CD銷售系統」的功能需求進行簡單描述

在圖1.2中能夠很容易地看出「CD銷售系統」所提供的功能。該系統容許樂隊經理查看樂隊CD的銷售統計報告及排行榜報告；它也容許唱片經理查看特定CD的銷售統計報告和這些CD在排行榜的報告。經過此圖還能夠看出，系統將經過一個名爲「排行榜報告服務」的外部系統來提供排行榜報告。

1.1.5 測試能力目標

1. 如下對於UML的描述，錯誤的是（     ）。

A. UML是一種面向對象的設計工具

B. UML不是一種程序設計語言，而是一種建模語言

C. UML不是一種建模語言規格說明，而是一種表示的標準

D. UML不是過程，也不是方法，但容許任何過程和方法使用它

2. 從系統外部用戶角度着眼，用於描述系統功能集合的UML圖是___________。

3. 識別如圖1.3所示的用例圖，並對其功能需求進行簡單描述。

 

1.1.6 知識擴展

使用用例圖時應注意以下事項：將系統視爲黑盒，從用戶的角度看待系統，以肯定系統必須實現的功能；參與者描述的是系統中涉及的用戶，現實生活中不一樣的人可能擁有多個角色；全部的交互都發生在參與者和用例之間，再沒有其餘可能發生的交互。

1.2 初識UML類圖

1.2.1 相關知識點

1. 什麼是類圖

類圖用於展現系統中的類、接口及其相互關係，類和接口體現系統須要處理的事物，關係體現系統內部的結構。一個典型的系統一般包含多個類圖，其中單個類圖只表達了系統的某一方面。類圖在系統靜態建模時最爲有用。

2. 如何繪製類圖

使用類圖進行系統靜態建模通常可分兩個步驟：首先，肯定系統中的類、接口等事物；其次，肯定事物之間的邏輯關係。在具體應用時，可藉助建模工具將其描繪出來。

1.2.2 知識點的能力目標

可以初步識別UML類圖中的類、接口等事物，可以初步識別事物之間關係。

1.2.3 實現能力目標的具體要求

1. 識別「教學管理系統」類圖中的類、接口等事物。

2. 識別「教學管理系統」類圖中事物之間的關係。

1.2.4 須要完成的實驗

1. 識別「教學管理系統」類圖中的類、接口等事物

如圖1.4所示爲「教學管理系統」的部分類圖。其中類表示爲一個矩形，該矩形被分隔成上、中、下三部分。上部描述類的名字，如Person（人）、Stu（學生）、Teacher（教師）、Course（課程）；中部描述類的屬性，此處略去；下部描述類的操做，此處略去。

 

2. 識別「教學管理系統」類圖中事物之間的關係

以上「教學管理系統」類圖中涉及到了兩種關係：泛化關係和關聯關係。其中泛化關係表示爲一條帶有空心箭頭的實線，其方向指向父類，如Person和Stu之間、Person和Teacher之間的連線，標明學生類和教師類是人類的子類。其中關聯關係表示爲實型直線，如Stu和Course之間、Teacher和Course之間的連線，標明學生學習課程、教師講授課程。

1.2.5 測試能力目標

1. 在UML的關係中，用來描述父類與子類之間關係的是__________關係。

2. 「交通工具」類與「汽車」類之間的關係屬於（     ）。

A. 關聯關係            B. 彙集關係

C. 依賴關係            D. 泛化關係

3. 請用UML圖示描述「狗」和「小黃狗」之間的關係。

4. 根據如圖1.5所示的類圖，回答問題。

（1）在該圖中，涉及到的類有___________________________­­­­­­­­­­______。

（2）在該圖中，涉及到的關係有_______________________________。

 

1.2.6 知識擴展

UML建模過程一般被分爲如下四個連續迭代的階段：分析階段、設計階段、實現階段和部署階段。在系統開發的每一個階段都需創建相應的模型，創建這些模型的目的也不盡相同。分析階段的模型用來捕獲系統的需求，多以用例圖體現；設計階段的模型用來擴充分析階段的系統需求，同時爲實現段提供解決方案，多以類圖體現；實現階段的模型用於將設計階段的系統方案轉化成實際事物（如可執行文件等），多以組件圖體現；部署階段的模型用來展現系統的物理架構，多以部署圖（也稱配置圖）體現。

 

第2章  Rational Rose工具

「工欲善其事，必先利其器」。爲了更好地利用UML進行軟件系統建模，咱們首先須要得到支持UML的建模工具。自從UML正式發佈之後，出現了大量的UML建模工具，如在第1章中說起的Microsoft Office Visio、Sybase PowerDesigner、IBM Rational Rose等，其中以Rational Rose使用較爲普遍。

Rational Rose工具由Rational公司（現已被IBM公司收購）提供，它具備建模功能強大、操做界面友好、可視化的特色，可以支持UML用例建模、靜態建模、動態建模、物理建模等。本章將初步介紹Rational Rose的安裝、配置及使用，本章在全書知識體系中的位置如圖2.1所示。

 

2.1 安裝與配置Rational Rose

2.1.1 相關知識點

1. Rational Rose的安裝

安裝Rational Rose首先須要得到軟件安裝包，能夠從官方網站http://www.ibm.com下載試用版本，而後根據安裝嚮導提示逐步安裝。

2. Rational Rose的啓動

成功安裝後，能夠經過開始菜單啓動該軟件；也能夠找到Rational Rose的安裝路徑，默認狀況下爲C:\Program Files\Rational\Rose\，雙擊該目錄下的Rose.exe文件啓動該軟件。

3. Rational Rose的配置

Rational Rose成功安裝、正常啓動後，爲了有效的完成建模工做，能夠根據實際須要對環境進行配置。

2.1.2 知識點的能力目標

可以熟練安裝Rational Rose，可以正確啓動Rational Rose，可以進行Rational Rose環境配置。

2.1.3 實現能力目標的具體要求

1. 安裝Rational Rose 2003。

2. 啓動Rational Rose 2003。

3. 配置Rational Rose 2003。

2.1.4 須要完成的實驗

1. 安裝Rational Rose 2003

（1）運行Rational Rose 2003的安裝程序，若是安裝程序爲壓縮文件，將會打開「指定文件保存路徑」對話框，如圖2.2所示。此處默認的保存路徑爲「C:\Program Files\Rose Enterprise Edition for Windows」，單擊【Change】按鈕能夠更改文件保存路徑，單擊【Cancel】按鈕能夠取消本次安裝。

 

（2）單擊【Next】按鈕，打開「解壓文件」對話框，如圖2.3所示。

（3）文件解壓完畢後，打開「Rational產品安裝嚮導」對話框，如圖2.4所示。

（4）單擊【下一步】按鈕，打開「選擇安裝產品」對話框，如圖2.5所示。在此選擇「Rational Rose Enterprise Edition」準備安裝企業版。

 

 

 

（5）單擊【下一步】按鈕，打開「發佈方法」對話框，如圖2.6所示。在此選擇默認的「Desktop installation from CD image」便可。

 

（6）單擊【下一步】按鈕，打開「Rational Rose 企業版安裝嚮導」對話框，如圖2.7所示。

 

（7）單擊【Next】按鈕，打開「產品警告」對話框，如圖2.8所示。

 

（8）單擊【Next】按鈕，打開「版權聲明」對話框，如圖2.9所示。在此選擇「I Accept the terms in the license agreement」接受版權許可協議。

 

（9）單擊【Next】按鈕，打開「目標文件夾」對話框，如圖2.10所示。單擊【Change】按鈕能夠更改程序安裝路徑。

 

（10）單擊【Next】按鈕，打開「自定義安裝」對話框，如圖2.11所示。在此處能夠自行選擇要安裝的項目，單擊【Space】按鈕可查看磁盤空間，單擊【Help】按鈕可查看幫助信息。

 

（11）單擊【Next】按鈕，打開「準備安裝」對話框，如圖2.12所示。

 

（12）單擊【Install】按鈕，打開「安裝Rose企業版」對話框，如圖2.13所示。

 

（13）軟件安裝完畢，打開「安裝完成」對話框，如圖2.14所示。

 

（14）單擊【Finish】按鈕，打開「註冊嚮導」對話框，在此用戶能夠對軟件進行註冊，如圖2.15所示。

 

2. 啓動Rational Rose 2003

Rational Rose 2003安裝成功後，依次單擊【開始】->【程序】->【Rational Software】->【Rational Rose Enterprise Edition】啓動該程序，如圖2.16所示；或找到Rational Rose 2003的安裝路徑，如C:\Program Files\Rational\Rose\，雙擊Rose.exe文件啓動該程序。

 

啓動Rational Rose 2003後，首先出現啓動界面，如圖2.17所示。啓動界面消失後，進入到Rational Rose 2003的主界面，而且會彈出「建立新模型」的對話框，此對話框用來設置本次啓動的初始動做，分爲New（新建模型）、Existing（打開現有模型）、Recent（最近打開模型）三個選項卡。第一個選項卡New，用來選擇新建模型時採用的模板，如圖2.18所示。第二個選項卡Existing，用來打開一個已經存在的模型，如圖2.19所示；第三個選項卡Recent，用來打開一個最近使用過的模型文件，如圖2.20所示。

在此暫時不須要任何模板，只需新建一個空白模型，即單擊【Cancel】按鈕，直接進入Rational Rose 2003的主界面，如圖2.21所示。

       

 

3. 配置Rational Rose 2003

實際應用中能夠根據我的喜愛和具體狀況，對Rational Rose進行相應的配置。主要經過菜單【Tools】->【Options】->【General】進行常規操做，如圖2.22所示。在此對話框中單擊【Font…】（根據不一樣對象選擇不一樣的【Font…】）按鈕，彈出如圖2.23所示的對話框，能夠設置字體；單擊【Line Color…】按鈕進行顏色選擇，如圖2.24所示。

 

       

2.1.5 測試能力目標

1. Rational Rose 2003的自定義安裝

在本身計算機上安裝Rational Rose 2003，並將安裝路徑選擇在非啓動盤符下，如D:\。

2. Rational Rose 2003的配置

在Rational Rose 2003中進行除常規設置外的其餘設置，如使用菜單【Tools】->【Options】->【Toolbars】對標準工具欄和編輯區工具欄進行配置。

2.1.6 知識擴展

1. Rational Rose 2003軟件的卸載

在控制面板的添加刪除程序中對其進行卸載，而不只僅只刪除安裝後的文件目錄。

2. 其餘UML建模工具安裝

在本身計算機上下載、安裝一款其餘UML建模工具，並與Rational Rose進行比較。

2.2 使用Rational Rose建模

2.2.1 相關知識點

使用Rational Rose工具進行UML建模，一般包括建立模型、保存模型、發佈模型、導入/導出模型等幾個步驟。

2.2.2 知識點的能力目標

可以使用Rational Rose建模。

2.2.3 實現能力目標的具體要求

1. 建立一個UML模型，命名爲myFirst.mdl。

2. 將該模型保存在D:\UML目錄下，如無此目錄可自行創建。

3. 發佈該模型。

2.2.4 須要完成的實驗

1. 建立模型

在Rational Rose主界面中，單擊菜單【File】->【New】，或直接單擊標準工具欄的【Create New Model of File】按鈕，打開如圖2.18所示的對話框，選擇建立模型所需的模板，單擊【OK】按鈕確認，或直接單擊【Cancel】按鈕取消。

2. 保存模型

在Rational Rose主界面中，單擊菜單【File】->【Save】，或直接單擊標準工具欄的【Save Model，File，Script】按鈕保存模型，其文件擴展名爲.mdl。若是該模型還未指定名稱，將會打開如圖2.25所示的另存爲對話框。

 

3. 發佈模型

使用Rational Rose創建的模型能夠直接發佈到Web上，以方便他人共享。在Rational Rose主界面中，單擊菜單【Tools】->【Web Publisher】，打開如圖2.26所示的對話框，該對話框中能夠選擇發佈到Web頁面上的內容和HTML文件保存的位置，而後單擊【Publish】按鈕發佈模型。若是打開所保存的HTML文件，則能夠看到發佈的Rational Rose模型，如圖2.27所示。

2.2.5 測試能力目標

1. 使用Rational Rose創建的模型文件其擴展名爲：_______。

2. 經過Rational Rose的【Tools】->【Web Publisher】菜單能夠進行模型的_________操做。

3. 建立一個空白的模型，命名爲simpleTest.mdl；在simpleTest.mdl模型中添加一個簡單的類圖，保存該模型；將其發佈到D:\UML\simpleTest.html文件，選擇發佈的圖形文件類型爲JPEG；查看發佈的模型。

 

2.2.6 知識擴展

1. 導出模型

在Rational Rose主界面中，單擊菜單【File】->【Export Model】，打開如圖2.28所示的對話框，可進行模型的導出。

2. 導入模型

在Rational Rose主界面中，單擊菜單【File】->【Import】，打開如圖2.29所示的對話框，可進行模型的導入。

 

3. Rational Rose的主菜單

Rational Rose的主菜單如圖2.30所示，主菜單中各菜單的含義說明詳見表2.1所示，主菜單的各級子菜單含義及功能可參閱本書附錄。

 

表2.1 Rational Rose主菜單說明

序號	菜單	含義
1	File	文件
2	Edit	編輯
3	View	視圖
4	Format	格式
5	Browse	瀏覽
6	Report	報告
7	Query	查詢
8	Tools	工具
9	Add-Ins	插件
10	Window	窗口
11	Help	幫助

 

4. Rational Rose的工具欄

Rational Rose的工具欄如圖2.31所示，其中各按鈕的含義詳見表2.2所示。

 

表2.2 Rational Rose工具欄

按鈕	英文含義	中文含義
	Create New Model or File	新建模型或文件
	Open Existing Model or File	打開已有的模型或文件
	Save Model, File or Script	保存模型，文件或腳本
	Cut	剪切
	Copy Diagram	複製圖形
	Paste	粘貼
	Print	打印
	Context Sensitive Help	動態幫助
	View Documentation	瀏覽文檔
	Browse Class Diagram	瀏覽類圖
	Browse Interaction Diagram	瀏覽交互圖
	Browse Component Diagram	瀏覽組件圖
	Browse State Machine Diagram	瀏覽狀態圖
	Browse Deployment Diagram	瀏覽部署圖
	Browse Parent	瀏覽父圖
	Browse Previous Diagram	瀏覽上一圖形
	Zoom In	放大
	Zoom Out	縮小
	Fit in Window	設置顯示比例，使圖形放進窗口
	Undo Fit in Window	撤銷【Fit in Windows】設置

 

第3章  用例模型

在系統開發的分析階段，用戶對系統的使用方式直接決定了系統的設計方式與構建方式。因此從用戶觀點出發，對幫助分析人員理解用戶需求，創建可用、有用的系統是十分關鍵的。從用戶的觀點出發對系統創建模型是用例模型要完成的任務，所以用例建模一般也稱爲需求建模。本章在全書知識體系中位置如圖3.1所示。

 

在UML中，一個用例模型由若干個用例圖（Use Case Diagram）描述。用例圖是顯示一組參與者、用例以及它們之間關係的圖。

3.1 參與者

3.1.1 相關知識點

1. 系統邊界（System Boundary）

系統邊界指一個軟件系統可以處理的整個問題空間的範圍。一個軟件系統不可能處理全部問題，開發人員必須得給系統定義問題空間的範圍。哪些是這個軟件能夠處理的，哪些則是這個軟件不能處理的，也就是項目管理中所說的項目範圍。

在UML中，系統邊界用方框表示，或者省略不作表示。

2. 參與者（Actor）

參與者指的是存在於系統以外，透過系統邊界與系統進行有意義交互的任何事物。參與者能夠是一我的，一個其餘的系統或一部機器，甚至能夠是時間，如圖3.2所示。舉例來講，好比在「自動售貨系統」中，系統有售貨、供貨、提取銷售款等功能，其中啓動售貨功能的是人，那麼人就是參與者；又如「圖書管理系統」可能須要和其餘應用系統發生聯繫，比方說可能經過「學生管理系統」驗證讀者是否爲在校學生，那麼這裏的「學生管理系統」就是一個參與者，只不過該參與者不是具體的一我的，而是另外的一個系統；與一個系統進行交互的人或其餘的系統能夠是參與者，與系統進行通訊的硬件設備也能夠是參與者，例如在「自動售貨系統」中，顧客購買貨品時，最終是貨品分配器將貨品傳送至出貨口以便用戶提取，此時貨品分配器做爲硬件設備也就成爲了該系統的參與者之一；再如「圖書管理系統」中若是讀者到期沒有歸還圖書，則讀者進入系統時會有「未還書提示」功能，此處時間也就成爲參與者，也就是說當通過必定時間後系統中的「未還書提示」事件就會發生。

從參與者在系統中的地位來看，能夠將其分紅兩類，即主要參與者（Primary Actor）和次要參與者（Secondary Actor）。主要參與者指的是執行系統主要功能的參與者，例如在「圖書管理系統」中主要參與者是進行借閱管理的圖書管理員；次要參與者指的是使用系統次要功能的參與者，次要功能通常指系統維護功能（如管理數據庫、備份和通訊等），例如在「圖書管理系統」中，可以檢索該系統中一些基本統計數據的系統管理員屬於次要參與者。將參與者分類的主要目的是，保證把系統全部功能表示出來，而主要功能是系統最關心的部分。

從參與者對用例的做用來看，能夠將其分爲主動參與者和被動參與者。主動參與者能夠初始化用例、啓動用例；而被動參與者則不能，它須要使用用例結果或爲用例執行提供數據，被動參與者僅僅參與一個或多個用例，在某個時刻與用例通訊。

在UML中，參與者表示爲一個小人的圖形（Stick Man符號），在小人圖形的下方書寫參與者的名字，如圖3.3所示；也能夠用類符號（類的具體內容詳見第4章）來表示參與者，如圖3.4所示。

         

3. 識別參與者

怎樣肯定系統的參與者呢？開發人員能夠從以下幾個方面來考慮。

從交互識別：

（1）誰使用系統的主要功能？

（2）誰改變系統的數據？

（3）誰從系統得到信息?

（4）誰須要系統的支持以完成平常工做任務？

（5）誰（或什麼）對系統運行產生的結果感興趣？

從維護、管理識別：

（6）誰負責維護、管理並保持系統正常運行？

從設備或外部條件識別：

（7）系統須要應付（處理）哪些硬件設備？

（8）系統須要和哪些外部系統交互？

（9）時間、氣溫等條件是否對系統產生影響？

例如，在「基於Web的零件銷售系統」中，顧客能夠經過Internet進行購買。要求顧客先預付必定金額存入內部帳戶中成爲會員，而後才能購買零件。顧客能夠根據本身所知道的零件的形狀、大小、零件編號等指標，搜索出所須要的零件。結帳使用內部帳戶支付。系統根據會員提供的送貨地址和訂購數量，從庫存中搜索出離送貨地址最近的供應商，通知供應商發貨。另外，內部工做人員不按期地根據供應商方面的價格變更，對某些零件的銷售價格進行更新。每一個星期，各個供應商會把記錄本身最新庫存狀況的Excel文件寄來，系統根據這些文件更新庫存信息。因簡化的須要，如下因素略去不考慮：折扣，延遲交貨……

以該系統爲例，針對前述問題進行回答即可以肯定系統的參與者。

（1）潛在會員，會員使用系統的主要功能。

（2）會員，貨管員，經理改變系統的數據。

（3）潛在會員，會員，經理，貨管員從系統得到信息。

（4）經理，貨管員須要系統的支持以完成平常工做任務。

（5）會員，經理對系統運行產生的結果感興趣。

（6）系統管理員負責維護、管理並保持系統正常運行。

（7）系統無需應付（處理）特殊硬件設備。

（8）系統可能與供應商的系統交互。

（9）忽略時間、氣溫等條件對系統產生的影響。

綜上回答，肯定出「基於Web的零件銷售系統」的參與者有：潛在會員、會員、經理、貨管員、系統管理員、供應商系統。

須要注意的是，在識別參與者時，不能將參與者的名字表示成參與者的某個實例，好比「張三」是「基於Web的零件銷售系統」中的會員，但「張三」做爲參與者的實例不能做爲參與者的名字；也不能將參與者表示成參與者所需完成的功能，好比「售貨」就是所需完成的功能，一樣不能做爲參與者的名字。

3.1.2 知識點的能力目標

可以識別「圖書管理系統」中的參與者，而且在Rational Rose中繪製圖示。

3.1.3 實現能力目標的具體要求

1. 識別「圖書管理系統」中的參與者。

2. 在Rational Rose中繪製「圖書管理系統」的參與者。

3.1.4 須要完成的實驗

1. 識別「圖書管理系統」中的參與者

遵循前面敘述的識別參與者的方法，暫時能夠分析出「圖書管理系統」中的參與者有：Administrator（系統管理員），Librarian（圖書管理員），Reader（讀者）。

Administrator（系統管理員）：經過使用系統進行用戶管理。

Librarian（圖書管理員）：經過使用系統進行讀者管理、圖書管理、借閱管理等。

Reader（讀者）：經過使用系統進行讀者信息查詢、預訂圖書、取消預訂等。

2. 在Rational Rose中繪製「圖書管理系統」的參與者

（1）建立和保存工程

啓動Rational Rose後，在菜單欄中選擇【File】->【New】菜單項，能夠建立一個模型，選擇【File】->【Save】或【Save As】能夠保存工程爲「Library」，如圖3.5所示。

              

（2）建立用例圖

在Rational Rose左側視圖區域樹型列表中選擇【Use Case View】，點擊鼠標右鍵在彈出的快捷菜單中選擇【New】->【Use Case Diagram】，新建一個用例圖，如圖3.6所示。

 

新建用例圖默認名稱爲「NewDiagram」，能夠更改其名稱，更改方法是選擇「NewDiagram」點擊鼠標右鍵選擇【Rename】，而後輸入用例圖的新名稱便可，如圖3.7所示，在此可將用例圖名稱改成「Library UseCase」。雙擊該用例圖，在Rational Rose窗口內右側空白處出現相應的編輯區，在編輯區中可進行後續操做。

 

（3）新建參與者

在編輯區工具欄中單擊「Stick Man」符號，也就是「Actor」，如圖3.8所示，而後將鼠標停放在編輯區任意位置，鼠標會變成十字形狀，在須要的位置再次單擊鼠標便可在編輯區中繪製出參與者的圖示。新建的參與者默認名稱爲「NewClass」，可將其名稱根據具體狀況進行修改。簡便的修改方法是直接在「NewClass」處鍵入參與者的新名稱；稍複雜的修改方法是雙擊該參與者打開「參與者屬性」對話框，或者右鍵單擊該參與者，在彈出的快捷菜單中選擇【Open Specification】也能夠打開「參與者屬性」對話框，如圖3.9所示，在此進行參與者名稱的修改，同時還能夠進行其餘方面更爲詳細的設置。

 

 

按照以上方法，能夠繪製出「圖書管理系統」中的所有參與者：Administrator（系統管理員），Librarian（圖書管理員），Reader（讀者），如圖3.10所示。

 

3.1.5 測試能力目標

1. 什麼是系統邊界？

2. 什麼是參與者？如何用圖示描述參與者？

3. 識別參與者應遵循怎樣的步驟？

4. 在UML中，參與者能夠是（    ）。

A. 人員         B. 外部系統         C. 硬件設備         D. 時間

5. 參考以上「圖書管理系統」，捕獲「短信平臺系統」中的參與者，並使用Rational Rose工具實現。需求描述以下：

用戶若是預約了天氣預報，系統天天定時給用戶發送天氣信息；若是當天氣溫高於34攝氏度，系統還要提醒用戶注意防暑。在這段敘述中，誰是「短信平臺系統」的參與者？

3.1.6 知識擴展

1. 自定義繪圖工具欄

繪圖工具欄中給出了經常使用的繪圖工具，若是用戶有更豐富的需求，可根據實際狀況自定義該工具欄。方法是右鍵單擊繪圖工具欄的任意位置，在彈出的快捷菜單中選擇【Customize】，如圖3.11所示。

而後在彈出的「自定義工具欄」對話框中「可用工具欄按鈕」欄，選取須要添加的工具，單擊「添加」按鈕，確認無誤後關閉該對話框便可，如圖3.12所示。

 

2. 繪製多個參與者的快捷方法

若是系統用例圖中有多個參與者，按照前面介紹的方法繪製相關圖示就須要作不少重複勞動，顯得至關麻煩。其實能夠選擇更快捷的方法來完成多個參與者的繪製，首先選擇繪圖工具欄中【】 「鎖定選擇」按鈕 ，而後選擇「參與者」按鈕，此時鼠標會變成十字形狀，接着在編輯區中任意位置屢次單擊鼠標，便可繪製出多個參與者圖示，再次單擊「鎖定選擇按鈕」便可取消鎖定，如圖3.13所示。此方法一樣適用於其餘圖示。

 

3. 刪除用例模型中的參與者

使用Rational Rose繪製系統用例模型的參與者時，因爲操做不當或需求發生變化可能須要刪除已繪製出的參與者圖示，刪除方法有以下幾種。

（1）在編輯區中選擇待刪除的參與者，而後選擇菜單【Edit】->【Delete from Model】便可刪除指定參與者，如圖3.14所示。另外，在編輯區中選擇待刪除的參與者後，直接按「Ctrl+D」組合鍵也可直接刪除指定參與者。

 

（2）在左側瀏覽器窗口的樹型結構中選擇待刪除對象，單擊鼠標右鍵，在彈出的快捷菜單中選擇【Delete】，便可刪除指定參與者，如圖3.15所示。另外，在瀏覽器窗口的樹型結構中選擇待刪除對象後，直接按「Delete」鍵也可直接刪除指定參與者。

 

（3）在編輯區中選擇待刪除的參與者，單擊鼠標右鍵，在彈出的快捷菜單中選擇【Edit】->【Delete】，能夠將指定參與者從編輯區中刪除，但該參與者在用例模型中仍然存在，即在瀏覽器窗口樹型結構中該參與者仍然顯示，如圖3.16所示。另外，在編輯區中選擇待刪除的參與者後，直接按「Delete」鍵也可達到相同效果。

 

3.2 用例

3.2.1 相關知識點

1. 用例（Use Case）

用例是系統執行的一系列動做，這些動做生成特定參與者可觀測的、有價值的結果值。一個用例定義一組用例實例。

用例是參與者要求系統提供的服務，是參與者使用系統指望達到的目標.，是從用戶角度描述的系統行爲。通俗地說，用例側重於目標，而不是內部處理。用例沒有表示任何關於系統內部的東西，只是表示系統將達到什麼樣的目標及由哪些參與者操做、負責。

用例具備如下特徵：

（1）每一個用例都有相應的信息輸入，而輸入信息通常由參與者提供；

（2）每一個用例都有相應的信息輸出，而輸出信息通常被參與者接收；

（3）每一個用例都是對一項系統功能的完整表述 ，對應具體的用戶目標。

在UML中，用例被表示爲一個橢圓圖形，該橢圓的底部或內部書寫用例名稱，如圖3.17所示。

 

2. 識別用例

對於用戶來說，用例能夠幫助他們明確將來怎樣使用系統；而對於開發者來說，就須要在不關注細節的狀況下，快速蒐集系統需求，識別出系統用例。識別用例是系統開發中的重要組成部分，一個新的系統在研發前首先要進行系統的功能分析，弄清楚業務流程，這樣才能更好地爲系統服務，藉助用例進行描述即可以解決上述問題。

怎樣肯定系統的用例呢？識別用例最好的方法是從參與者着手，考慮每一個參與者是怎樣使用系統的。應用這種策略可能還會找出一些新的參與者，這對完善整個系統用例模型大有益處。用例建模的過程就是反覆迭代和逐步精化的過程。在此過程當中，經過回答以下幾個問題能夠幫助識別用例。

（1）參與者要爲系統提供哪些功能和信息？

（2）參與者須要系統提供哪些功能和信息？

（3）系統在哪些方面存在問題，在哪些方面亟待完善？

進而，肯定用例的通常步驟爲：

（1）肯定哪些參與者爲系統提供輸入信息；

（2）肯定哪些參與者須要從系統獲取輸出信息；

（3）肯定輸入信息與輸出信息之間的映射關係，即用例。

例如，在「倉庫管理系統」中，經過與系統用戶溝通，分析人員能夠識別出系統主要參與者有：操做員、管理員、供應商、商品領料人、商品退料人。針對以上參與者，識別出系統用例有：倉庫進貨、倉庫退貨、倉庫領料、倉庫退料、商品調撥、倉庫盤點、庫存查詢、業務分析、倉庫歷史記錄查詢、供應商信息維護、倉庫信息維護、用戶管理等。

3. 用例闡述文檔

用例闡述文檔是針對每一個用例，描述該用例各個場景（Scenario）的文檔。所謂場景是指參與者和系統之間的一系列特定的活動和交互。每一個用例是一組場景的集合，而每一個場景又是一組步驟序列的集合。具體應用時，可採用以下用例闡述的模板。

------------------------------------------------------------------------------------------------------------

用例編號：

用例名稱：

涉及的參與者：

用例概述：

前置條件：

後置條件：

基本事件流：

1.……XXXXX

2.……XXXXX

備選流：

1a.……XXXXX

1a1.……XXXXX

1a2.……XXXXX

2a.……XXXXX

2a1.……XXXXX

2a2.……XXXXX

補充說明：

------------------------------------------------------------------------------------------------------------

其中前置條件約束在用例開始前系統的狀態，後置條件約束用例執行後系統的狀態。

例如，在「圖書管理系統」的Borrow Book（借書）這個用例中，包含着以下幾個相關的場景。

Scenario-1：順利地借到書

Scenario-2：該種書刊不存在

Scenario-3：物理書刊都已借出

Scenario-4：沒有該讀者信息

爲描述該用例的各個場景，可採用以下用例闡述文檔加以說明。

------------------------------------------------------------------------------------------------------------

用例編號：001

用例名稱：Borrow Book

涉及的參與者：Librarian（圖書管理員）

用例概述：讀者憑讀者證借閱圖書

前置條件（Preconditions）：圖書館正常開放時間

後置條件（Postconditions）：若是讀者借閱成功，則該讀者可借閱書刊數量減小，館藏減小；若是讀者借閱失敗，該讀者可借閱書刊數量不變。

基本事件流（Flow of Events）：

1. 讀者進入圖書館

2. 讀者查找圖書

3. 讀者將讀者證提交給圖書管理員，並提交借閱圖書請求

4. 圖書管理員檢查讀者可借閱書刊數量和館藏數量，若是知足條件則借出圖書

5. 圖書借給讀者，讀者可借閱書刊數量減小，館藏減小

6. 系統顯示讀者當前的借閱信息

備選流：

1a. 沒有該借閱者信息：

1a1.系統提示借閱者信息不存在

2a. 查詢圖書信息不存在：

2a1系統提示該圖書不存在

3a. 物理書刊均已借出

3a1. 系統提示無館藏

補充說明：

無

------------------------------------------------------------------------------------------------------------

3.2.2 知識點的能力目標

可以識別「圖書管理系統」中的用例，並在Rational Rose中繪製圖示。

3.2.3 實現能力目標的具體要求

1. 識別「圖書管理系統」的用例。

2. 在Rational Rose中繪製「圖書管理系統」的用例。

3.2.4 須要完成的實驗

1. 識別「圖書管理系統」的用例

針對3.1.4中分析出的系統主要參與者（系統管理員、圖書管理員、讀者），能夠分析出「圖書管理系統」中主要用例包括：Manage User（用戶管理）、Manage Book（圖書管理）、Manage Reader（讀者管理）、Borrow-Lend（借閱管理）等，詳細說明以下。

Manage User（用戶管理）：完成系統用戶的增長、刪除、修改、查詢等功能。

Manage Book（圖書管理）：完成基本信息設置（圖書類型設置、借閱種類設置）和圖書信息管理（圖書信息設置、圖書信息查詢）功能。

Manage Reader（讀者管理）：完成讀者辦證、讀者信息查詢、讀者證掛失功能。

Borrow-Lend（借閱管理）：完成借書、還書、續借、超期罰款、圖書預訂、取消預訂、圖書掛失等功能。

綜合對「圖書管理系統」中參與者和相關係統功能的分析，獲得該系統的所有用例如表3.1所示。

2. 在Rational Rose中繪製「圖書管理系統」的用例

（1）打開工程和用例圖

啓動Rational Rose後，在菜單欄中選擇【File】->【Open】菜單項，能夠打開已有工程「Library」，而後在左側瀏覽器窗口中單擊【Use Case View】前面的【】符號，展開樹型結構，此時已經建立過的「Library UseCase」用例圖即可顯示出來，雙擊「Library UseCase」打開該用例圖的編輯區便可建立用例。

（2）建立用例

在編輯區工具欄中單擊用例符號【】即「Use Case」，而後將鼠標停放在編輯區任意位置，鼠標會變成十字形狀，在須要的位置再次單擊鼠標便可在編輯區中繪製出用例的圖示。新建的用例默認名稱爲「NewUseCase」，可將其名稱根據具體狀況進行修改。

表3.1 「圖書管理系統」中的用例

編號	參與者	用例名稱	用例說明
1	Administrator （系統管理員）	Add User	增長系統用戶
2		Delete User	刪除系統用戶
3		Update User	修改系統用戶
4		Query User	查詢系統用戶
5	Librarian （圖書管理員）	Set BookType	進行圖書類型設置
6		Set BorrowType	進行借閱種類設置
7		Set BookInfo	進行圖書信息設置
8		Set ReaderCard	爲讀者辦證
9		Query BookInfo	根據須要進行圖書信息查詢
10		Query ReaderInfo	進行讀者信息查詢
11		Borrow Book	處理讀者的借書請求
12		Return Book	處理讀者的還書請求
13		Renew Book	處理讀者的續借圖書請求
14		Fine	收取讀者的超期罰款
15		Reserve Book	處理讀者的圖書預約請求
16		Cancel Reservation	處理讀者的取消預訂請求
17		Lose Book	處理圖書掛失
18		Lose ReaderCard	處理讀者證掛失
19	Reader （讀者）	Login	登陸系統
20		Reserve Book	申請預訂圖書
21		Cancel Reservation	取消圖書預訂
22		Query BookInfo	根據須要進行圖書信息查詢
		Query ReaderInfo	進行讀者信息查詢
23		Renew Book	申請續借圖書

 

簡便的修改方法是直接在「NewUseCase」處鍵入用例的新名稱；稍複雜的修改方法是雙擊該用例打開「用例屬性」對話框，或者右鍵單擊該用例，在彈出的快捷菜單中選擇【Open Specification】也能夠打開「用例屬性」對話框，在此進行用例名稱的修改，同時還能夠進行其餘方面更爲詳細的設置。

按以上方法，能夠建立「圖書管理系統」中的主要用例，與系統管理員相關的用例如圖3.18所示，與圖書管理員相關的用例如圖3.19所示，與讀者相關的用例如圖3.20所示。

 

 

 

 

 

 

 

 

3.2.5 測試能力目標

1. 什麼是用例圖？用例圖的構成要素有哪些？

2. 創建用例圖應遵循怎樣的步驟？

3. 如圖3.21所示爲「超市系統」設計的用例圖，該系統的參與者有：(     )。

A. Clerk, Manager

B. Clerk, Manager, Customer

C. Clerk, Manager, Bank network

D. Clerk, Manager, Bank network, Customer

 

4. 下列關於使用用例的目的，不正確的說法是：(     )。

A. 肯定系統應該具有哪些功能

B. 爲系統的功能提供清晰一致的描述，方便開發人員傳遞系統的需求

C. 爲系統驗證工做奠基基礎

D. 可以減小程序員的編碼工做量，從而提升開發效率

5. 根據表3.2列舉的信息，藉助Rational Rose工具繪製「手機系統」的參與者和相關用例。

表3.2 「手機系統」相關信息

參與者	用例
手機用戶	呼叫某人 接聽電話 發送短消息 記錄電話號碼

 

6. 識別「Email客戶端」（如：outlook express）軟件系統中的參與者和用例，需求描述以下：A在北京發送郵件給上海的B，系統提醒B 「您有新郵件」，B接收郵件。藉助Rational Rose工具，設計並繪製出相關參與者和用例圖示。

7. 藉助Rational Rose工具，繪製「航班售票系統」的參與者和用例。參與者爲旅客（ Passenger ），用例爲訂票（ Order ）和查看今日航班（ Search TodayFlight ）。

3.2.6 知識擴展

1. 誰來寫用例闡述文檔

最完美的狀況：業務人員接受訓練，寫出優美的用例文檔。

最現實的狀況：業務人員提供素材，開發人員寫用例文檔。

最糟糕的狀況：業務人員無論，徹底由開發人員杜撰。

2. 用例的粒度

簡單地說，用例的粒度就是用例規模的大小；嚴格地說，用例的粒度表示一個用例能夠描述一項完整的業務流程或一項完整的系統功能。怎樣肯定一個用例的粒度是否合適，是以這個用例是否完成了參與者的某個目的爲依據的。

在一次技術研討會上，有人問起Ivar Jacoboson博士，一個系統須要多少個用例？Ivar Jacoboson博士的回答是20個，固然他的意思是最好將用例模型的規模控制在幾十個用例左右，這樣比較容易來管理用例模型的複雜度。在用例個數大體肯定的條件下，咱們就很容易來肯定用例粒度的大小。

對於較複雜的系統，咱們須要控制用例模型這一級別的複雜度。因此能夠將複雜度適當地移往每個用例的內部，也就是讓一個用例包含比較多的需求信息量，從而減小用例個數增大用例的粒度，下降用例模型的複雜度。

對於比較簡單的系統，咱們則能夠將複雜度適當地曝露在模型這一級別，也就是咱們能夠將較複雜的用例分解成爲多個簡單的用例，從而增大用例的個數減少用例的粒度，增強用力模型的飽滿度。

用例的粒度不但決定了用例模型級的複雜度，並且也決定了每個用例內部的複雜度。咱們應該根據每一個系統的具體狀況，來把握各個層次的複雜度，在儘量保證整個用例模型易理解的前提下來決定用例的大小和數目。

例如，在「圖書管理系統」讀者借閱書刊的場景中， 讀者首先出示了讀者證，圖書管理員查詢了該讀者之前的借閱記錄，確保沒有到期未歸還的書刊，而後又查詢了讀者欲借閱的書刊確保有館藏，最後讀者借閱成功。 從這個例子中能分析出多少用例呢？ 注意， 用例分析是以參與者爲中心的， 所以用例的粒度是以能完成參與者目的爲依據。 所以，實際上合適的用例是：借書。 只有這一個用例便可，其它描述都只是完成這個目的過程。

3. 識別用例的注意事項

（1）用例應該終止於系統邊界，超出系統問題空間的功能沒必要放入該系統用例模型中。

例如，在「零件銷售管理系統」中，出納員做爲其中的參與者可能爲系統提供相應功能或者但願系統爲其提供相應功能，但吃飯和睡覺這兩項功能與銷售管理自己並無密切聯繫，也就是說圖3.22中「Eat」和「Sleep」脫離了系統問題空間，超出了系統邊界，因此這兩項功能不該做爲系統用例出現。在具體分析時，應避免此種狀況發生。

 

 

（2）用例的結果值應該由系統生成，從而使得用例是有意義的目標。

例如，在「零件銷售管理系統」中，與客戶相關的檢索零件功能具體操做步驟是：首先客戶設置檢索條件，而後選擇合適的零件，接着再進行後續操做。經過分析可知，其中有意義的目標就是檢索零件，而並不是是設置檢索條件和選擇合適零件。因此正確的用例應如圖3.23所示，而非圖3.24所示。在具體分析時，也應避免此種狀況發生。

 

 

（3）用例分析應從用戶角度出發，使用業務語言描述；而非從開發人員角度出發，使用技術語言描述。

例如，在「航班售票系統」中，從用戶角度描述的功能爲「訂票」和「查看今日航班」，而從開發人員角度描述的系統功能爲「處理訂票」和「顯示今日航班」。

又如，在「手機系統」中，分別從用戶角度和開發人員角度描述的系統功能如表3.3所示，在具體識別用例時應着重考慮用戶角度。

表3.3 用戶角度與開發人員角度的不一樣描述

用戶角度	開發人員角度
呼叫某人	傳輸/接收
接聽電話	電源/基站
發送短消息	輸入輸出（顯示器，鍵盤）
記錄電話號碼	電話簿管理
……	……

3.3用例模型中的關係

3.3.1 相關知識點

1. 泛化（Generalization）關係

在面向對象程序設計中存在繼承的概念，繼承是指一種由已有類建立新類的機制。利用繼承，能夠先建立彙集共有屬性和行爲的通常類，根據該通常類再建立具備特殊屬性和行爲的新類，新類繼承通常類的屬性和行爲，並根據須要增長本身新的屬性和行爲。由繼承而獲得的類稱爲子類，被繼承的類稱爲父類。與此類似的是，用例模型中參與者和參與者之間、用例和用例之間也有可能存在這種通常和特殊的關係；與此不一樣的是，在分析領域而非設計、實現領域，咱們一般用泛化來表示此種關係。也就是說，若是一個參與者是另外一個參與者的特例，一個用例是另外一個用例的特例，它們之間就能夠表示爲泛化關係。實際上，泛化是一種抽象化，繼承則是一種具體化。

在UML用例模型中，泛化關係被表示爲一條帶有空心箭頭的實線，其方向指向父參與者或父用例。如圖3.25所示爲參與者之間的泛化關係，如圖3.26所示爲用例之間的泛化關係。

 

2. 關聯（Association）關係

在用例模型中關聯關係一般用來反應參與者和用例之間的相互做用，表示參與者使用用例的功能或參與者接受用例提供的數據。

在UML中，關聯關係用實型直線表示，該實型直線能夠有導航方向（即畫出箭頭），也能夠忽略導航方向（即不畫出箭頭）。一般，參與者與用例之間的關聯關係無需特別強調導航，但部分UML書籍中也定義了這種導航，其大體內容是：若是參與者要使用用例，則箭頭從參與者指向用例；若是參與者要接受用例提供的數據或查詢結果，則箭頭從用例指向參與者。

如圖3.27所示爲定義了導航方向的關聯關係，而圖3.28所示爲忽略導航方向的關聯關係，兩個圖示均可以表示「自動提款機系統」中Bank Customer（銀行客戶）、Server（後臺服務器）兩個參與者和Query（查詢）、Get Cash（提款）、Transefer（轉帳）三個用例之間的關聯關係。本章後續內容中沒有過多考慮導航方向的問題。

 

 

3. 包含（Inclusion）關係

雖然每一個用例大都是獨立的，可是一個用例也能夠包含其餘用例具備的行爲，並把它所包含的用例行爲做爲自身行爲的一部分。若是一個用例包含另外一個用例的行爲，則稱這兩個用例之間存在包含關係，被包含的用例能夠是事先定義好的，也能夠是在各類環境下使用的公共行爲。

在UML中包含關係使用虛線箭頭表示，其上添加<<include>>字樣，箭頭指向被包含用例。例如，在「學生成績管理系統」中，學生登陸系統以後方可查詢我的的成績信息，教師也需登陸系統後方可輸入學生成績、查詢學生成績，那麼該系統用例模型中登陸用例和查詢成績、輸入成績用例之間就能夠表示爲包含關係，如圖3.29所示。

 

值得注意的是，不要亂用包含關係，錯把用例步驟（即用例闡述文檔中的事件流）看成被包含的用例。如圖3.30就是一個誤用包含關係的實例，該例中錯將會員註冊的步驟（填寫註冊信息、生成會員ID和密碼、保存註冊信息）看成註冊用例的包含用例來使用，實際問題中應儘可能避免。

 

4. 擴展關係（Extension）

用例模型中容許爲已有用例建立新用例，新用例做爲已有用例的增量擴展，以此強化已有用例的行爲，等於在不改變已有用例的狀況下，給系統添加新的行爲。其中已有用例一般稱爲基本用例（Base Use Case），新用例一般稱爲擴展用例（Extension Use Case）。基本用例與擴展用例之間的關係稱做擴展關係。

擴展的目的在於：

（1）代表用例的某一部分是可選的系統行爲。這樣，就能夠將模型中的可選行爲和必選行爲分開；

（2）代表只有在特定條件下（一般是在異常狀況下）才執行的行爲，如觸發警報等。也就是說，基本用例自身應該是完整的，即基本用例應該是可理解而且是有意義的，而沒必要引用任何擴展用例；擴展用例是否執行取決於在執行基本用例時所發生的事件。

如前所述，擴展用例的執行是有條件的，這個條件稱做擴展點（Extension Point），該擴展點能夠用註釋在用例中進行標註，也能夠在用例描述中加以說明。經過在基本用例中引用擴展點，能夠定義在基本用例的哪些位置插入擴展用例。

在UML中，擴展關係使用虛線箭頭表示，其上添加<<extend>>字樣，箭頭指向基本用例。例如，在「圖書管理系統」中，若是定期還書不會出現異常狀況即不會有其餘用例產生，而超期還書就會出現異常狀況即產生用例——罰款，如圖3.31所示。其中Return Book爲基本用例，Fine爲擴展用例，OverdueBook爲擴展點。因爲在此圖中加入了擴展關係，因此Librarian和Fine之間的關聯關係也能夠省略。

有些時候，人們對擴展關係和包含關係會產生混淆，其實擴展關係和包含關係的主要區別在於：擴展關係中，基本用例沒必要知道擴展用例的任何細節，事實上基本用例沒有擴展用例也是完整的，只有特定的條件發生了，擴展用例的行爲才被執行；而在包含關係中，被包含用例倒是必不可少的，如在圖3.29中沒有Login System用例做爲前提，Input Score用例和Query Score用例的功能則根本不能完成。

 

3.3.2 知識點的能力目標

可以識別「圖書管理系統」用例模型中的關係，並在Rational Rose中繪製圖示。

3.3.3 實現能力目標的具體要求

1. 識別「圖書管理系統」用例模型中的關係。

2. 在Rational Rose中繪製「圖書管理系統」用例模型中的關係。

3.3.4 須要完成的實驗

1. 識別「圖書管理系統」用例模型中的關係

三個參與者Administrator（系統管理員），Librarian（圖書管理員），Reader（讀者）和與其相關的用例之間存在關聯關係。

此外，Reader（讀者）相關的Reserve Book（預訂圖書）用例、Cancel Reservation（取消預訂）用例、Query BookInfo（查詢圖書）用例、Query ReaderInfo（查詢讀者）用例、Renew Book（續借圖書）用例包含一個公共的用例，就是Login（註冊）用例，它們與Login（註冊）用例存在包含關係。

Librarian（圖書管理員）相關的Return Book（還書）用例和Fine（罰款）用例之間存在擴展關係。

2. 在Rational Rose中繪製「圖書管理系統」用例模型中的關係

（1）打開工程和用例圖

按照3.2.4中的方法，打開「Library」工程和「Library UseCase」用例圖。

（2）建立用例模型中的關係

在編輯區工具欄中單擊關聯關係符號【】即「Association」，而後將鼠標停放在編輯區任意位置，鼠標會變成箭頭形狀，箭頭方向向上，此時採用按住鼠標左鍵拖拽的方式將參與者和用例鏈接起來即可。

繼續在編輯區工具欄中單擊依賴關係符號【】即「Dependency or instantiates」，採用按住鼠標左鍵拖拽的方式，分別將Reserve Book（預訂圖書）用例、Cancel Reservation（取消預訂）用例、Query BookInfo（查詢圖書）用例、Query ReaderInfo（查詢讀者）用例、Renew Book（續借圖書）用例和Login（註冊）用例鏈接起來，注意箭頭應該指向被包含的用例Login（註冊）。而後雙擊在圖中出現的依賴關係，打開如圖3.32所示的對話框，在該對話框中「Stereotype」對應的下拉列表裏選擇「include」，即可完成包含關係的繪製。

 

最後在編輯區工具欄中單擊依賴關係符號【】即「Dependency or instantiates」，採用按住鼠標左鍵拖拽的方式，將Return Book（還書）用例和Fine（罰款）用例鏈接起來，注意箭頭應指向基本用例Return Book（還書）。接下來雙擊兩個用例之間的依賴關係，在圖3.32所示的對話框中「Stereotype」對應的下拉列表裏選擇「extend」，即可完成擴展關係的繪製。

按照以上方法，繪製出「圖書管理系統」用例模型中的關係，如圖3.33所示，此圖也就是本系統的用例圖。

3.3.5 測試能力目標

1. 用例之間有不一樣的關係，下列哪一個不是它們之間可能的關係（    ）。

A. 泛化（Generalization）                B. 擴展（Extension）

C. 包含（Inclusion）                        D. 聚合（Aggregation）

 

2. 用例用來描述系統在對事件作出響應時所採起的行爲。用例之間是具備相關性的。在一個「訂單輸入子系統」中，建立新訂單和更新訂單都須要覈查用戶帳號是否正確。那麼，用例「建立新訂單」、「更新訂單」與用例「檢查客戶帳號」之間是（    ）關係。

A. 包含                                     B. 擴展   

C. 分類（Classification）           D. 泛化

3. 用例從用戶角度描述系統的行爲。用例之間能夠存在必定的關係。假設在「圖書管理系統」用例模型中，全部用戶使用系統以前必須經過「身份驗證」，「身份驗證」能夠有「密碼驗證」和「智能卡驗證」兩種方式，則「身份驗證」與「密碼驗證」和「智能卡驗證」之間是（    ）關係。

A. 關聯   B. 包含    C. 擴展     D. 泛化

4. 在「成績管理系統」中，「查詢成績」和「網上查詢成績」用例之間爲（　　　　）關係；「輸入成績」和「登陸系統」用例之間爲（　　　　）關係；「修改爲績」和「輸入成績」用例之間爲（　　　　）關係。

A. 關聯   B. 包含    C. 擴展     D. 泛化

5. 某電話公司決定開發一個管理全部客戶信息的交互式的網絡系統，系統功能需求描述以下。

（1）瀏覽客戶信息：任何使用Internet的網絡用戶均可以瀏覽電話公司全部的客戶信息（包括姓名、住址、電話號碼等）。

（2）登陸：電話公司授予每一個客戶一個帳號。擁有受權帳號的客戶，能夠使用系統提供的頁面設置我的密碼，並使用該帳號和密碼向系統註冊。

（3）修改我的信息：客戶向系統註冊後，能夠發送電子郵件或者使用系統提供的頁面，對我的信息進行修改。

（4）刪除客戶信息：只有公司管理人員纔可以刪除再也不接受公司服務的客戶的信息。

在需求分析階段，採用用例圖描述系統功能需求，以下圖3.34所示，請指出圖中的A，B，C和D分別是哪一個用例？

 

6. 根據如下「汽車租賃系統」的需求描述，藉助Rational Rose工具繪製系統用例圖。

用戶能夠經過不一樣的方式（包括電話、前臺、網上）提出預訂車輛申請；基層工做人員能夠處理客戶預約、客戶取車、客戶還車等業務，並保存客戶相應歷史記錄；技術人員能夠填寫檢修服務記錄、保存檢修結果。

7. 在線售票訂位系統中，客戶（通常客戶/企業客戶）能夠創建在線訂位銷售事件、事件確認、執行在線信用卡付費、我的或團體帳戶修改和管理；系統操做者能夠創建在線銷售定位事件、查詢目前銷售訂位情況；系統設計維護者能夠創建在線售票定位事件、查詢目前銷售定位狀況、在線系統維護功能和系統環境設置。

根據以上描述，請分析出該系統的參與者和用例，並利用Rational Rose工具繪製出需求用例模型。

8. 根據下面的陳述，分析出系統參與者和用例，並利用Rational Rose繪製用例圖。

在醫生的辦公室裏接待員、護士和醫生使用病人記錄和計劃安排系統。當病人第一次來這裏看病時，接待員使用該系統來輸入病人信息，而且安排全部的預定。護士使用系統來跟蹤病人每次看病的結果並輸入護理病人的信息，如醫療和診斷。護士也能夠訪問這些信息以打印病人診斷結果或病人看病歷史。醫生主要用這個系統來查看病人的病史，偶爾也輸入病人的醫療信息，但一般醫生讓護士輸入這些信息。

9. 經過回答下列提示問題，獲取ATM自動取款系統中的參與者、用例、關係，並利用Rational Rose工具繪製ATM系統的用例圖。

（1）誰使用ATM系統的取款功能？

（2）誰使用ATM系統的支持以完成平常工做任務？

（3）誰對ATM系統的運行結果感興趣？

（4）誰來維護、管理並保持ATM系統的正常運行？

（5）ATM系統須要和哪些系統進行交互？

（6）ATM系統須要處理哪些設備？

10. 根據下面圖3.35所示的結帳系統用例圖，描述出其中涉及到的參與者、用例以及相互關係。

 

3.3.6 知識擴展

1. 用例圖的層次

因爲人類處理復瑣事物的能力有限，因此在系統需求相對較多的狀況下，就須要採用分層處理的方法。層次中的「頂層」用例是重中之重，由於它決定了一個系統的內在實質。同時，做爲系統的實施者，要常常性地關注頂層用例圖，這樣纔可以保證在系統實施過程當中緊緊把握系統目標。在接下來的次高層，用例的數量也應當進行適當地控制，但就總體而言用例圖的總層次不宜超過三層。

以「圖書管理系統」爲例，爲了讓層次更加清晰，能夠先繪製頂層用例圖，如圖3.36所示。

 

而後在頂層用例圖的基礎上繪製子用例圖，好比在圖3.36中雙擊「Borrow-Lend」用例，或右鍵單擊該用例並在彈出的快捷菜單中選擇【Open Specification】，打開「用例屬性」對話框，繼而選擇其中的【Diagrams】選項卡，右鍵單擊中間的空白區域並在彈出的快捷菜單中選擇【Insert Use Case Diagram】，即可插入「Borrow-Lend」用例的子圖，同時可將子用例圖的默認名稱「New Diagram」修改成「Borrow-Lend SubDiagram」，如圖3.37所示。

 

雙擊「Borrow-Lend SubDiagram」子用例圖，進入用例圖的繪製界面，參照前面用例圖的繪製步驟，完成Administrator（圖書管理員）「Borrow-Lend SubDiagram」子用例圖，如圖3.38所示。

 

相似地，完成Librarian（圖書管理員）「Manage Reader」子用例圖，如圖3.39所示；完成Administrator（圖書管理員）「Manage User」子用例圖，如圖3.40所示；完成Reader（讀者）「Borrow-Lend」子用例圖，如圖3.41所示。

 

 

 

2 用例圖工具欄

用例圖工具欄上的按鈕名稱及功能，詳見表3.4。

表3.4 用例圖工具欄按鈕

按鈕	按鈕名稱	說明
	Selection Tool	選擇工具
	Text Box	文本框
	Note	註釋
	Anchor Note to Item	將圖中的元素與註釋鏈接
	Package	包
	Actor	參與者
	Use Case	用例
	Unidirectional Association	單向關聯關係
	Dependency or instantiates	依賴關係或實例化（包含和擴展關係）
	Generalization	泛化關係
	Association	關聯關係

 

3. 繪圖中的錯誤提示

以繪製關聯關係即便用【】爲例，若是在操做過程當中出現如圖3.42所示的錯誤提示對話框，則說明操做有誤。該錯誤提示的含義爲：爲非法關聯，關聯關係只能用來鏈接類（用例圖中的參與者能夠看做類）或用例。出現這個錯誤是由於，在繪製參與者和用例間的關聯關係時，關係的起始端和終止端不是參與者和用例，或者是由於在繪製關係時起始點和終止點位置選擇則不夠準確。

 

以添加註釋即便用【】爲例，若是在操做過程當中出現如圖3.43所示的錯誤提示對話框，則一樣說明操做有誤。該錯誤提示的含義爲：爲非法註釋，必須與註釋鏈接。出現這個錯誤是由於，在添加註釋時，連線的的起始端或終止端不是註釋，或者是由於註釋的起始點和終止點位置選擇則不夠準確。

 

以添加依賴關係即便用【】爲例，若是在操做過程當中出現如圖3.44所示的錯誤提示對話框，則一樣說明操做有誤。該錯誤提示的含義爲：非法的依賴關係，對象流或實例化。出現這個錯誤是由於，在繪製用例間的擴展關係或包含關係時，關係的起始端和終止端不是用例，或者是由於在繪製關係時起始點和終止點位置選擇不夠準確。

 

 

第4章  靜態模型

靜態模型是UML的基礎，它用於顯示系統的靜態結構，特別是系統中事物（例如類、對象、包等）的內部結構以及相互關係。類圖、對象圖和包圖都屬於靜態模型。類圖主要描述系統中類的內部結構（屬性和操做）及類之間的關係。對象圖是類圖的實例，主要描述類圖的多個對象實例及相互關係。包圖用於顯示系統的分層結構，主要描述包的構成及包之間的相互關係。靜態模型中以類圖的使用最爲普遍，因此本章主要介紹類圖，稍加說明對象圖和包圖的部份內容。本章在全書知識體系中的位置如圖4.1所示。

 

 

4.1 類圖中的事物

4.1.1 相關知識點

1. 類（Class）

類是面向對象系統中最爲重要的概念。在UML中，類是描述事物結構特性和行爲特性的模型元素。類是對衆多UML元素的泛化，這些元素包括常規的類、接口、用例和參與者；反過來講，能夠認爲這些元素是類的特例。在類圖中，最經常使用的兩個元素是常規的類和接口。

類在UML中被表示爲一個矩形，該矩形被分隔成上、中、下三部分，如圖4.2所示和圖4.3所示。其中上部描述類的名字，中部描述類的屬性，下部描述類的操做（也稱類的方法），具體說明以下。

   

 

（1）名稱（Name）

類映射爲真實世界中的對象或結構，類的名稱就是根據它們所表明的真實世界中的對象和結構來定義的。類的名稱是一個字符串，是每一個類必有的構成元素，用於和其它類相互區分。類的名稱應該來自系統的問題空間，而且儘量的明確。通常狀況下，類的名字是一個名詞，如「圖書」、「Animal」、「Dog」等。

類的名稱可分爲簡單名稱（Single Name）和路徑名稱（Path Name）。單獨的名稱叫作簡單名稱，如圖4.4所示。用類所在的包名做爲前綴的類名叫作路徑名稱，如圖4.5所示，其中Package爲NewClass所在的包的名稱，NewClass爲類名。

  

（2）屬性（Attribute）

屬性用於描述同類對象的內部特徵。同類對象的內部特徵可能須要多個屬性進行描述，構成屬性集合。例如對「學生」來建模，每一個學生都有學號、姓名、專業、籍貫、出生日期等，這些均可以做爲學生類的屬性。

在UML中類屬性的通常語法格式爲：

[可見性] 屬性名稱 [：屬性的類型] [=初始值] [{屬性字符串}]

須要注意的是，在描述屬性時屬性名是必定要有的，其餘部分可根據須要進行選擇。

其中可見性用於控制外部事物對類中屬性的操做方式，經常使用的可見性有三種，即公有的（public）、受保護的（protected）、私有的（private）。一般使用加號（+）表示公有的（public），井號（#）表示受保護的（protected），減號（-）表示私有的（private）。而在Rational Rose中，採用圖形符號表示可見性，具體含義見表4.1所示。若是沒有標識可見性修飾符，則表示該屬性的可見性還沒有定義。

表4.1 Rational Rose的屬性可見性

說明	可見範圍	UML符號	Rose符號	說明
公有的（public）	類內部和外部	+
受保護的（protected）	類內部	#		能被其子類使用
私有的（private）	類內部	-		不能被其子類使用

 

其中屬性名稱用於區別類中其餘屬性，一般狀況下，屬性名稱由描述類特徵的名詞或名詞短語組成。按照UML的約定，若是屬性名稱爲單個英文單詞，宜採用小寫形式，如「name」；若是屬性名稱包含多個英文單詞，這些單詞要合併，而且除第一個單詞外其他單詞的首字母要大寫，如「bookName」。

其中屬性的類型用來講明該屬性是什麼數據類型，它能夠是基本數據類型（如整型、單精度浮點型、布爾型等），也能夠是其餘數據類型（如類的類型）。

其中初始值是指屬性最初得到的賦值。設置初始值有兩個做用：一是保護系統的完整性，防止屬性未被賦值而破壞系統完整性的狀況出現；二是爲用戶操做提供方便，一旦指定了屬性的初始值，當建立該類對象時，該對象的屬性值便自動被賦予了設定的初始值，從而簡化了用戶操做。

其中屬性字符串用來指定屬性的其餘相關信息。一般狀況下，屬性字符串列出該屬性全部可能的取值。

（3）操做（Operation）

操做是對象與其外部進行信息交換的惟一途徑，同類對象的外部特徵可能須要多個事件進行描述，構成事件集合。操做定義的基本原則是：操做集合必須定義在屬性集合之上，操做集合中各個操做至少用於屬性集合中的一個屬性；也就是說，操做的定義至少要涉及一個屬性，不然就不是這個類的操做。

在UML中類操做的通常語法格式爲：

[可見性] 方法名 [（參數表）] [：返回類型] [{屬性字符串}]

其中可見性與類屬性的可見性類似。

其中方法名是用來描述類行爲的動詞或動詞短語。命名方法與類屬性命名方法類似。

其中參數表是一些按順序排列的屬性，這些屬性定義了方法的輸入。參數表是可選的，即方法不必定必須有參數。若是要定義參數，則能夠採用「名稱：類型」的方式。存在多個參數時，可將各個參數用逗號隔開，參數也能夠有默認值。

其中屬性字符串能夠爲方法加入一些預約義元素以外的信息。

如圖4.6所示Shape類的全部方法可見性均爲公有的（public），其中move方法有兩個參數argname和argname2，argname參數類型爲Boolean布爾型，argname2參數類型爲Date日期型，該方法返回值類型爲int型。

 

在面向對象軟件工程中，將類劃分爲如下三種類型。

（1）實體類（Entity Class）

實體類（Entity Class）表示系統問題空間內的實體。在軟件系統中，實體具備永久性的特色，而且能夠持久地存儲在數據庫中。這裏的實體類與數據庫中的表對應；類的實例對應於表中的一條記錄；類的屬性對應記錄的字段。在UML建模時，一般使用實體類保存那些要永久存儲的信息，如「教務管理系統」中的學生類、課程類等。

具體應用時，實體類一般被表示爲如圖4.7所示的形式。

（2）邊界類（Boundary Class）

邊界類（Boundary Class）用於處理系統內部與外部之間的通訊，爲系統的參與者或其餘系統提供接口。邊界類位於系統邊界處，即系統內部與外部的交接處。邊界類包括窗體、報表以及其餘系統的接口。每一個參與者和用例交互至少要有一個邊界類。如「教務管理系統」中選課時使用的學生選課窗體等。

具體應用時，邊界類一般被表示爲如圖4.8所示的形式。

（3）控制類（Control Class）

控制類（Control Class）用於控制系統中對象間的交互。它負責協調其餘類之間的工做，實現對其餘對象的控制。一般狀況下，每一個用例都相應的有一個控制類，控制用例中的事件流。如：「教務管理系統」中學生選課時的課程判斷等。

具體應用時，控制類一般被表示爲如圖4.9所示的形式。

         

在以往傳統的C/S（Customer/Server）客戶機/服務器模式中，實體類、邊界類、控制類沒有嚴格的一一對應關係。在當前流行的設計模式如MVC（Model-View-Controller，模型—視圖—控制器）模式中，MVC分別對應實體類、邊界類、控制類。

2. 接口（Interface）

根據以往所學咱們知道，經過操做系統的接口能夠實現良好的人機交互和信息交流。在UML中也能夠定義接口，利用接口來講明類可以支持的行爲。在面向對象建模時，接口起着很是重要的做用，由於模型元素之間的相互協做都是經過接口實現的。一個結構良好的軟件系統，其接口的定義也必然很是規範。

接口一般被描述爲一組抽象操做，也就是這些操做只有標識（返回值、方法名、參數表）說明它的行爲，而真正實現部分放在使用該接口的類中。這樣，應用該接口的各個類就能夠對接口採用不一樣的實現方法。

在UML中，接口被表示爲一個圓形，在圓形的下方書寫接口名稱和抽象操做；接口還有其擴展形式，擴展形式中接口被表示爲一個構造型類，如圖4.10所示爲接口的通常表示形式，圖4.11所示爲接口的擴展表示形式。在Rational Rose中能夠經過右鍵單擊該接口，在彈出的快捷菜單中選擇【Options】->【Stereotype Display】中各子菜單項，來完成接口各類表示形式的轉換，如圖4.12所示。

      

 

 

3. 包（Package）

包是對模型元素進行分組的機制，它把模型元素劃分紅若個個子集。包能夠擁有UML中的其餘元素，如類、接口、用例等等，包甚至還能夠包含其餘包。包和類同樣也具備可見性，利用可見性控制外部包對包中內容的存取方式，包的可見性分爲三種。

（1）公有的（public）：表示此包內的模型元素能夠被任何引入此包的其餘包中的模型元素訪問。公有訪問的表示形式爲：在該包的模型元素名字前添加加號（+）修飾符。

（2）受保護的（protected）：表示此包內的模型元素可以被該包在繼承關係上的後代包中的模型元素訪問。受保護訪問的表示形式爲：在該包的模型元素名字前添加井號（#）修飾符。

（3）私有的（private）：表示此包內的模型元素能夠被屬於同一包的其餘模型元素訪問。私有訪問的表示形式爲：在該包的模型元素名字前添加減號（-）修飾符。

在UML中，包被表示爲相似文件夾的形狀，內部書寫包的名稱，如圖4.13所示爲NewPackage包中包含了NewPackage2包。

4. 協做（Collaboration）

協做是一組類、接口和其餘模型元素構成的羣體，它們共同工做，提供比各組成部分功能總和更強的合做行爲，如圖4.14所示內容即爲協做。

 

4.1.2 知識點的能力目標

可以識別「圖書管理系統」中的類，而且在Rational Rose中繪製圖示。

4.1.3 實現能力目標的具體要求

1. 識別「圖書管理系統」中的類。

2. 在Rational Rose中繪製「圖書管理系統」中的各個類。

4.1.4 須要完成的實驗

1. 識別「圖書管理系統」中的類

怎樣肯定軟件系統中的類呢？開發人員能夠從以下幾方面考慮。

（1）尋找名詞

閱讀系統文檔和用例（尤爲是用例事件流），找出名詞或名詞短語，分析這些名詞的含義，由於這些名詞並不都是類，可能有些只是屬性。因此須要通過篩選，去除冗餘的、與系統無關的、非獨立的類。

（2）類—職責—協做方法

類—職責—協做方法 ，也稱CRC（Class-Responsibility-Collaboration）方法。這是模擬開發人員「處理卡片」的一個過程。開發人員在執行一個處理實例（即一個用例）的同時，將類名賦予的職責和合做者填入卡片，以此來肯定類。

（3）根據MVC模式尋找

根據用例圖找出邊界類；在用例中找出控制類；若是此時數據庫已經設計完畢，則能夠根據數據庫中的表得到實體類。

須要注意的是，有些類沒法經過以上方法找到，可能還須要從後面的動態模型（如時序圖和協做圖）中經過分析對象來肯定。

接下來就以「圖書管理系統」爲例來進行類的識別。在「圖書管理系統」的用例模型中已經知道，系統須要爲每一個讀者創建一個帳戶，並給讀者發放讀者證（讀者證能夠提供讀者證號、讀者姓名），帳戶中存儲讀者的我的信息、借閱信息以及預訂信息等，持有讀者證的讀者能夠借閱書刊、返還書刊、查詢書刊信息、預訂書刊並取消預訂。

在借閱書刊時，須要輸入所借閱的書刊名、書刊的ISBN號，而後輸入讀者的讀者證號和讀者姓名，完成後提交所填表格，系統驗證讀者是否有效。若讀者有效，借閱請求被接受，系統查詢讀者所借閱的書刊是否存在，若存在，則讀者可借出書刊，系統記錄借閱記錄；若是讀者所借書刊已被借出，讀者還可預訂該書刊。讀者如期還書後，系統清除借閱記錄，不然需繳納罰金。

同時，以上部分操做還須要系統管理員和圖書管理員進行參與。

結合以上分析，遵循前面敘述的識別類的方法，暫時能夠識別出「圖書管理系統」中的類有：Admin，Administrator，Librarian，Reader，ReaderType，Book，BookType，Borrow，BorrowType，Store，Reserve，Fine。詳見表4.2所示。

表4.2 「圖書管理系統」中的類

序號	類名稱	類說明
1	Admin	抽象出來的管理員
2	Administrator	進行系統管理的管理員
3	Librarian	進行讀者管理、圖書管理、借閱管理的圖書管理員
4	Reader	讀者基本信息
5	ReaderType	讀者類別信息
6	Book	圖書基本信息
7	BookType	圖書類別信息
8	Borrow	讀者借閱圖書信息
9	BorrowType	讀者借閱類型信息
10	Store	圖書在圖書館中的存放位置信息
11	Reserve	讀者預訂圖書信息
12	Fine	讀者罰款信息

 

另外，系統的用戶接口，如Login（登陸）、Main（主界面）、SystemManage（系統管理）、ReaderManage（讀者管理）、BookManage（圖書管理）、BorrowManage（借閱管理）、FineManage（罰款管理）等窗體，也可做爲該系統的邊界類出現。

爲方便管理，能夠將上述各種納入兩個包中：Business Package（業務包）和GUI Package（圖形用戶接口包）。Business Package包含表4.2中列舉出來的類，GUI Package包含用戶接口類。

固然，若是採用頁面形式表示用戶接口，也能夠把頁面當作邊界類。

2. 在Rational Rose中繪製「圖書管理系統」中的各個類

（1）打開工程建立類圖

啓動Rational Rose，在菜單欄中選擇【File】->【Open】菜單項，打開在第3章中創建過的「Library」工程，而後在左側瀏覽器窗口中單擊「Logical View」，點擊鼠標右鍵【New】->【Class Diagram】，新建一個類圖，如圖4.15所示。

 

新建類圖默認名稱爲「NewDiagram」，能夠更改其名稱，更改方法是選擇「NewDiagram」點擊鼠標右鍵選擇【Rename】，而後輸入類圖的新名稱便可，在此可將類圖名稱改成「Library Class」。雙擊該類圖，在Rational Rose窗口內右側空白處出現相應的編輯區，在編輯區中可進行後續操做。

（2）建立包

由於前面已經分析過，爲方便管理，能夠將各個類納入Business Package和GUI Package兩個包中。因此，接下來就須要在Rational Rose中建立這兩個包。

在編輯區工具欄中單擊【】符號，也就是「Package」，如圖4.16所示，而後將鼠標停放在編輯區任意位置，鼠標會變成十字形狀，在須要的位置再次單擊鼠標便可在編輯區中繪製出包的圖示。新建包的默認名稱爲「NewPackage」，可將其名稱根據具體狀況進行修改。簡便的修改方法是直接在「NewPackage」處鍵入包的新名稱；稍複雜的修改方法是雙擊該包打開「包屬性」對話框，或者右鍵單擊該包，在彈出的快捷菜單中選擇【Open Specification】也能夠打開「包屬性」對話框，如圖4.17所示，在此進行包名稱的修改，同時還能夠進行其餘方面更爲詳細的設置。

 

按照以上方法，能夠繪製出「圖書管理系統」中的包：Business Package（業務包）和GUI Package（圖形用戶接口包），如圖4.18所示。

 

（3）建立類

包被建立完之後，能夠繼續建立包中的各個類。具體方法是：首先雙擊包（如Business Package包），進入該包的編輯區；而後在編輯區工具欄中單擊【】符號，也就是「Class」，如圖4.19所示，將鼠標停放在該包編輯區任意位置，鼠標會變成十字形狀，在須要的位置再次單擊鼠標便可在包編輯區中繪製出類的圖示。新建類的默認名稱爲「NewClass」，可將其名稱根據具體狀況進行修改。簡便的修改方法是直接在「NewClass」處鍵入類的新名稱「Book」；稍複雜的修改方法是雙擊該參與者打開「類設置」對話框，或者右鍵單擊該類，在彈出的快捷菜單中選擇【Open Specification】也能夠打開「類設置」對話框，如圖4.20所示，在此修改類名稱爲「Book」，同時還能夠進行其餘方面更爲詳細的設置。

 

（4）編輯類

類名被肯定之後，還能夠爲類添加相應的屬性和操做。添加屬性的方法和添加操做的方法相似，大體都有兩種。

添加屬性的方法之一是經過菜單直接添加。即右鍵單擊要添加屬性的類（如「Book」類）打開快捷菜單，選擇【New Attribute】菜單項，如圖4.21所示；而後鍵入新的屬性名稱「bookID」替換掉默認屬性名稱「name」，如圖4.22所示。若是想同時設置屬性的類型、初始值，能夠直接採用「屬性名：類型 = 初始值」的鍵入方式。若是想進一步設置屬性的可見性，則能夠直接用鼠標單擊屬性名前面的可見性符號，在彈出的可見性選擇項中從新設定以替換默認選項「private」。如圖4.23所示將Book類的「bookID」屬性設置爲整型int，初始值設置爲「0」，可見性設置爲「public」。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

添加屬性的方法之二是經過「類設置」對話框間接添加。即首先在圖4.20所示對話框中選擇【Attributes】選項卡，如圖4.24所示；而後右鍵單擊中間空白區域，在彈出的快捷菜單中選擇【Insert】菜單項，最後鍵入新的屬性名稱「bookName」替換默認屬性名稱「name」。同時，在此還能夠雙擊屬性，打開「類屬性設置」對話框，進行更爲詳細的其餘設置，例如設置屬性的類型、初始值、可見性等等，詳見圖4.25所示。

 

 

添加操做的方法與添加屬性的方法基本相同，只須要在圖4.21所示的快捷菜單中選擇【New Operation】菜單項；或者在圖4.24 所示的「類設置」對話框中選擇【Operations】選項卡而非【Attributes】選項卡，便可完成類操做的添加。類操做的詳細設置能夠在如圖4.26所示的對話框中雙擊指定的操做如querybyAuthor，打開「類操做設置」對話框，如圖4.27所示，在此能夠進行操做名稱、返回值、可見性等設置；繼續單擊該對話框的【Detail】選項卡，能夠進行參數列表設置，如圖4.28所示，在「Arguments」空白區域任意位置右鍵單擊，在彈出的快捷菜單中選擇【Insert】菜單項，此處設置querybyAuthor操做有一個參數名爲authorName，參數類型爲String字符串。

 

 

 

遵循以上步驟，繪製出Business Package包中的全部類，如圖4.29和圖4.30所示。

 

 

以上Business Package包中的各個類默認狀況下都屬於實體類，能夠參照繪製實體類的方法繪製系統的邊界類和控制類。接下來就以GUI Package包中的邊界類爲例，說明其操做步驟：首先在「Library Class」類圖中，雙擊GUI Package包，進入該包的編輯區，在編輯區中添加「Login」類；而後打開如圖4.20所示的「類設置」對話框，在對話框中選擇【Stereotype】下拉列表框內的「boundary」選項，便可將「Login」類設置爲邊界類。如圖4.31所示。

 

依次添加Main，SystemManage，ReaderManage，BookManage，BorrowManage，FineManage等邊界類，如圖4.32所示。

 

至此，「圖書管理系統」兩個包中的類就所有分析、繪製完成，具體層次結構如圖4.33目錄樹所示。

 

4.1.5 測試能力目標

1. 下圖4.34中類的名稱是______________，類中的屬性有______________，類中的操做有______________。

 

2. 若是一個類的屬性不能被其子類使用，則該屬性的可見性爲（    ）。

A. 公有的（public）            B. 受保護的（protected）

C. 私有的（private）            D. 默認的（default）

3. UML中的類被劃分爲三類，下面那個不是其中之一（    ）。

A. 邊界類                     B. 實體類

C. 控制類                     D. 主類

4. 在「類設置」對話框中，能夠經過（    ）設置類屬性的可見性。

A. Type                       B. Stereotype

C. Initial                      D. Export Control

5. 在「類設置」對話框中，能夠經過（    ）構造型（Stereotype）設置類爲邊界類。

A. abstract                     B. control

C. boundary                    D. subclass

6. 簡述靜態模型中類和用例模型中參與者之間的區別與聯繫。

7. 請根據如下描述，給出系統的UML類設計方案。

系統名稱：農夫果園遊戲系統

人物角色：農夫（Farmer）、市場調查員（Inquirer）、農場主（Boss）

系統實物：各類果樹（Fruit）、果園（Garden）

功能需求：

（1）農夫能夠根據市場行情種植各類水果；

（2）市場調查員能夠了解市場行情；

（3）農場主能夠向農夫、市場調查員發佈命令；

（4）各類果樹都具備種植（plant）、成長（grow）、收穫（harvest）行爲；

（5）果園是人物和實物進行交易的經營場所。

4.1.6 知識擴展

在軟件開發的不一樣階段，類能夠具備不一樣的抽象層次。通常地，類的抽象可分爲三個層次，即概念層（Conceptual），說明層（Specification）和實現層（Implementation），如圖4.35所示。

 

類的概念層、說明層和實現層的劃分最早是由 Steve Cook和John Daniels引入的。

概念層（Conceptual）描述應用領域中的概念，通常地，這些概念和類有很天然的聯繫，但二者並無直接的映射關係。

說明層（Specification）描述軟件的接口部分，而不是軟件的實現部分。

實現層（Implementation）才真正考慮類的實現問題，揭示實現細節。

4.2 類圖中的關係

4.2.1 相關知識點

UML類圖中經常包含多個類，這些類並非孤立存在的，它們之間存在着必定的邏輯關係，這些邏輯關係能夠分爲四種：泛化（Generalization）、依賴（Dependency）、實現（Realize）、關聯（Association），其中關聯又能夠細化爲彙集（Aggregation）和組合（Composition）。

1. 泛化（Generalization）關係

在第3章用例模型中已經提到過泛化關係，經過前面的介紹可知，泛化表示通常元素和特殊元素之間的關係。在類圖中，通常元素被稱爲超類或父類，特殊元素被稱爲子類。子類能夠繼承父類的屬性和操做，並根據須要增長本身新的屬性和操做。更簡單地說，泛化關係描述了類之間的「is a kind of」（是……的一種）關係。在Java語言中，extends關鍵字表示了這種關係的精髓。具體應用中，抽象類（沒有具體對象的類）一般用做父類，具體類（擁有具體對象的類）一般用做子類。這樣的例子不少，如「交通工具」爲抽象類能夠用做父類，「汽車」和「輪船」爲具體類能夠用做「交通工具」的子類。又如「圖形」類是抽象類能夠用做父類，「矩形」類、「圓形」類和「多邊形」類是具體類能夠用做「圖形」類的子類。

在UML類圖中，泛化關係被表示爲一條帶有空心箭頭的實型直線，其方向指向父類，如圖4.36所示。

 

2. 依賴（Dependency） 關係

若是一個元素A的變化影響到另外一個元素B，但反之卻不成立，那麼這兩個元素B和A之間的關係是依賴關係，即元素B依賴元素A。好比，工人（Worker）要完成擰螺絲（screw）的工做，須要依賴螺絲刀（Screwdriver）的幫助，在這種狀況下就能夠理解爲，工人和螺絲刀之間存在依賴關係。前面介紹的泛化關係和後面即將介紹的實現關係在語義上講也是依賴關係，但因爲其有更特殊的用途，因此被單獨描述。

在UML中，依賴關係被表示爲帶箭頭的虛線，箭頭指向被依賴元素。具體建模時，依賴關係一般體現爲某個類的方法使用另外一個類的對象做爲參數，如圖4.37所示，依賴關係體現爲Worker類的screw方法使用Screwdriver對象做爲參數。

 

3. 實現（Realize）關係

若是一個元素A定義了一個標準，而另外一個元素B保證執行該標準，那麼元素B和元素A之間的關係是實現關係，即元素B實現元素A。在Java語言中，直接使用implements關鍵字表示實現關係。

這個關係最常應用於類和接口之間，接口能夠定義標準，一般是定義類須要完成的功能的標準，但接口並不關心功能的具體實現，具體實現交由相應的類去完成。好比，「收費」是一個接口，它定義了「收取費用」這個功能的標準，若是「客車」類和「火車」類要執行該標準完成各自「收取費用」的功能，就必須給出「收取費用」的具體實現方法。在這種狀況下能夠理解爲，「客車」類和「收費」接口之間是實現關係，「火車」類和「收費」接口之間也是實現關係。

在UML中，實現關係被被表示爲帶有空心箭頭的虛線，箭頭指向定義標準的元素（如接口），詳見圖4.38所示。

 

4. 關聯（Association）關係

關聯是類（更確切地說，是類的實例即對象）之間的關係，表示有意義的和值得關注的鏈接。換言之，在類圖中若是兩個對象之間存在須要保持一段時間的關係，那麼它們之間就能夠表示爲關聯關係。舉例來講，學生（Student）在學校（School）裏學習課程（Classes），那麼在學生（Student）、學校（School）和課程（Classes）之間就存在着某種鏈接。設計類圖時，也就能夠在「Student」、「School」和「Classes」之間創建關聯關係。

關聯一般是雙向的（固然也有單向的），即關聯的雙方彼此可以互相通訊，彼此都能感知到另外一方的存在。在UML中，關聯關係被表示爲一條實型直線。若是該實型直線實線帶有箭頭，則代表是單向關聯，箭頭方向表示關聯方向，圖4.39所示；若是該實型直線實線沒有箭頭，則代表是雙向關聯，如圖4.40所示。

 

關聯能夠使用關聯名稱、關聯角色、導航性和多重性等來進行修飾。

（1）關聯名稱

關聯關係能夠添加名稱，用於描述該關係的性質。此關聯名稱應該是動詞或動詞短語，由於它表明源對象正在目標對象上執行的動做。在雙向關聯中，能夠在關聯的一個方向上爲關聯起一個名字，而在另外一個方向上起另一個名字（也能夠不起），名字一般緊挨着實線書寫。爲避免產生混淆，在名字的前面或後面能夠附加一個表示關聯方向的實心黑三角，黑三角的尖角指明這個關聯名稱只能用於尖角所指的對象上。如圖4.41所示，「Person」和「Company」之間存在關聯關係，其關聯名稱爲「works for」，該名稱用於「Company」上。

 

值得說明的是，關聯名稱並不是是必須的，只有在須要明確給關聯提供角色名稱時，或一個模型中存在不少關聯且應該加以區分時，才須要給出關聯名稱。

（2）關聯角色

當一個對象處於關聯的一端時，也就意味着該對象在這個關係中扮演了一個特定的角色。具體來講，關聯角色就是關聯關係中一個對象針對於另外一個對象所表現的職責。角色的名稱應該是名詞或名詞短語，用來解釋對象是如何參與關聯的。在類圖中，關聯角色放置在相應的關聯（實線）的末端。如圖4.42所示，「Company」扮演的是「employer」僱主的角色，而「Person」扮演的是「employee」僱員的角色。關聯角色是關聯的一個組成部分，可根據須要選用。

 

（3）關聯的導航性

導航性描述的是一個對象可否訪問另外一個對象。也就是說，關聯的一端設置導航性代表本端的對象能夠被另外一端的對象訪問。在圖示上，導航方向用箭頭方向標註，前面已經介紹過，只在一個方向上能夠導航的關係稱爲單向關聯，用一條帶箭頭的實線來表示；在兩個方向上均可以導航的關係稱爲雙向關聯，用一條沒有箭頭的實線表示。具體建模時，關聯關係的導航性通常是經過類的成員變量來體現的，如圖4.43所示。

 

（4）關聯的多重性

關聯的多重性是一種約束，用來表示關聯中的數量關係。在圖示上，多重性被表示爲用圓點分隔的區間，每一個區間的通常格式爲：minimum..maximum。其中minimum表明最小值，maximum表明最大值，取值均是非負整數。具體多重性指標如表4.3所示。

表4.3 關聯的多重性指標

多重性指標	含義
1	恰爲1
*   等同於n	0或更多
0..1	0或1
0..*   等同於0..n	0或更多
1..*   等同於1..n	1或更多
2..6	2~6
2,4..6	2,4~6

 

「Company」和「Person」之間的多重性關係如圖4.44所示。經過圖示可知，一個「Company」（公司）能夠擁有1個或多個「Person」（人員），一個「Person」（人員）屬於一個「Company」（公司）。

 

5. 彙集（Aggregation）關係

彙集也稱聚合，是一種特殊的較強的關聯，表示類（確切地說，是類的實例即對象）之間是總體與部分的關係。

在UML中，彙集關係被表示帶有空心菱形頭的實線。如圖4.45所示，「Car」（汽車）是表明總體事物的對象（也稱彙集對象），「Wheel」（輪子）是表明部分事物的對象。

 

6. 組合（Composition）關係

組合是一種特殊形式的彙集，組合關係中的總體與部分具備相同的生存期。

在UML中，組合關係被表示爲帶有實心菱形頭的實現。如圖4.46所示，「Company」（公司）是表明總體事物的對象（也稱組合對象），「Department」（部門）是表明部分事物的對象。

 

UML類圖中的彙集關係和組合關係主要區別在於：彙集關係表示總體與部分的關係比較弱，而組合比較強。彙集關係是「has a」的關係，組合關係是「contains a」的關係。彙集關係中彙集對象與表明總體事物的對象並沒有生存期上的聯繫，一旦刪除了表明總體對象的事物不必定就刪除了彙集對象。組合中一旦刪除了組合對象，同時也就刪除了表明部分事物的對象。例如圖4.45汽車和輪子之間的彙集關係代表，若是汽車沒有了，輪子還能夠獨立存在，還能夠被安裝到其餘汽車上，它們之間的關係相對鬆散。而在圖4.46公司和部門之間的組合關係代表，若是公司沒有了，公司的部門天然也就消失了，它們具備相同的生存期，它們之間的關係相對彙集而言更加密切。

以前介紹的關聯關係和彙集關係的主要區別是語義上的：關聯的兩個對象之間通常是平等的，例如你是個人朋友；彙集則通常不是平等的，例如一個球隊包含多個球員。但它們在實現上都是類似的。

4.2.2 知識點的能力目標

可以識別「圖書管理系統」中各個類之間的關係，並在Rational Rose中繪製圖示。

4.2.3 實現能力目標的具體要求

1. 識別「圖書管理系統」中包之間的關係。

2. 識別「圖書管理系統」中各個類之間的關係。

3. 在Rational Rose中繪製「圖書管理系統」的類圖。

4.2.4 須要完成的實驗

1. 識別「圖書管理系統」中包之間的關係

顯而易見，GUI Package和Business Package之間存在依賴關係，前者依賴後者而存在。

2. 識別「圖書管理系統」中各個類之間的關係

結合前面的知識，能夠分析出「圖書管理系統」中Business Package包中各個實體類的關係如表4.4所示。

表4.4 Business Package包中各個實體類的關係

序號	類A	類B	類A和類B之間的關係
1	Admin	Administrator	泛化
2	Admin	Librarian	泛化
3	Book	BookType	組合
4	Book	Store	普通關聯
5	Reader	ReaderType	組合
6	Reader	Reserve	普通關聯
7	Reader	Book	普通關聯
8	Reader	Borrow	普通關聯
9	Borrow	Book	普通關聯
10	Borrow	BorrowType	組合
11	Reserve	Book	普通關聯
12	Fine	Borrow	普通關聯

 

一樣，能夠分析出GUI Package包中各個邊界類的關係如表4.5所示。

表4.5 GUI Package包中各邊界類的關係

序號	類A	類B	類A和類B之間的關係
1	Login	Main	單向關聯
2	SystemManage	Main	普通關聯
3	ReaderManage	Main	普通關聯
4	BookManage	Main	普通關聯
5	BorrowManage	Main	普通關聯
6	FineManage	BorrowManage	普通關聯

 

3. 在Rational Rose中繪製「圖書管理系統」的類圖

（1）打開類圖

啓動Rational Rose後，在菜單欄中選擇【File】->【Open】菜單項，能夠打開已有工程「Library」，而後在左側瀏覽器窗口中單擊【Logical View】前面的【】符號，展開樹型結構，此時已經建立過的「Library Class」類圖即可顯示出來，雙擊「Library Class」打開該類圖的編輯區。

（2）創建包之間的關係

在編輯區工具欄中單擊依賴關係符號【】即「Dependency or instantiates」，採用按住鼠標左鍵拖拽的方式，將GUI Package和Business Package鏈接起來。注意箭頭應該指向Business Package，如圖4.47所示。

 

（3）創建類之間的關係

接下來能夠雙擊Business Package，爲該包中的各個類創建關係。

參照表4.4的分析，Admin類和Administrator類之間存在泛化關係，爲刻畫這種關係，須要在編輯區工具欄中單擊依賴關係符號【】即「Generalization」，採用按住鼠標左鍵拖拽的方式，將Admin類和Administrator類鏈接起來，注意箭頭應該指向父類Admin。按照一樣的方法，能夠創建Admin類和Librarian類之間的泛化關係。

參照表4.4的分析，Book類和BookType類之間存在組合關係，爲刻畫這種關係，須要在編輯區工具欄中單擊依賴關係符號【】即「Association」，而後將鼠標停放在編輯區任意位置，鼠標會變成箭頭形狀，箭頭方向向上，此時採用按住鼠標左鍵拖拽的方式，首先將Book類和BookType類之間創建關聯關係。而後，雙擊該關聯關係（即實線），打開「關聯設置」對話框，在該對話框的【General】選項卡中能夠設置關聯名稱、關聯角色等內容，如圖4.48所示。在該對話框的【Role A Detail】和【Role B Detail】選項卡中能夠設置關聯的導航型、多重性等內容，同時還能夠將該關聯關係細化爲彙集關係或組合關係，如圖4.49所示。

 

 

根據實際須要，進行完相應的設置後，Book類和BookType類之間就能夠創建起如圖4.50所示的組合關係。

 

遵循以上方法，很容易創建「圖書管理系統」GUI Package包中各邊界類之間的關係，如圖4.51所示。

 

相似地，能夠再創建「圖書管理系統」Business Package包中各實體類之間的關係，如圖4.52所示和圖4.53所示。

 

 

4.2.5 測試能力目標

1. 在UML的靜態建模中，能夠藉助___________表示在某一時刻這些類的具體實例和這些實例之間的鏈接關係。

2. 若是一個類與另外一個類之間的關係具備「總體與部分」的特色，描述的是「has a」的關係，那麼這兩個類之間的關係是（     ）關係。

A. 實現（Realize）                B. 彙集（Aggregation）

C. 組合（Composition）            D. 泛化（Generalization）

3. 「交通工具」類與「汽車」類之間的關係屬於（     ）關係。

A. 關聯（Association）             B. 彙集（Aggregation）

C. 組合（Composition）            D. 泛化（Generalization）

4. 每一個HouseKeeper都有一個Manager負責，有的Manager可能負責多個HouseKeeper，有的Manger可能一個HouseKeeper都沒有，下面哪幅圖適合描述類HouseKeeper和類Manger的關係？（      ）

A.

B.

C.

D.

5. 根據圖4.54所示類之間的關係，回答問題。

 

 

class RegularReceiptVisitor

{

public void printRoomCharges( XXX& aVar)

{

       aVar.getDescription();

       aVar.getQualtity();

       aVar.getPrice();

}

……

}

上面代碼中的XXX處最適合填什麼？（       ）

A. ReceiptVisitor                  B. PromotionalReceiptVisitor

C. Describable                     D. Entertainment

6. 已知三個類A、B和C，其中類A由類B的一個實例和類C的1個或多個實例構成。可以正確表示類A、B和C之間關係的UML類圖是 （     ）。

A.   B.

C.          D.

7. 下面哪一個類圖的關係表示只有SportVehicle才能使用SportEngine? (      )

A. B.

C. D.

8. 請創建一個樹型結構的類圖，要求任意一個節點可以導航到父親節點，也能導航到其孩子節點。

9. 請爲下面這段Java代碼補充類圖。

public class Student{

       private String name;

       public void setName(String name){

              this.name=name;

       }

       public String getName(){

              return this.name;

       }

}

10. 根據下面的陳述繪製類圖。

（1）學生包括本科生、研究生兩種。

（2）研究生能夠利用課餘時間擔任助教。

（3）教師包括講師和教授兩種。

（4）一名助教能夠爲一位講師或一位教授助課，一位講師只能有一名助教，一位教授能夠有5名助教。

11. 按以下描述繪製出「飛船系統」的類圖。

神州六號飛船是神州飛船系列的一種，它由軌道艙、返回艙、推動艙和逃逸救生塔等組成；航天員能夠在返回艙內駕駛飛船，軌道艙則是航天員工做和休息的場所。在緊急狀況下，能夠利用逃逸救生塔逃生。在飛船兩側有多個太陽能電池翼，能夠爲飛船提供電能。

12. 按以下描述繪製出「自治機器人系統」的類圖。

這張圖的焦點是彙集在那些讓機器人在路上行走的機制所對應的類上。經過分析，能夠發現一個虛類Motor和兩個從它派生出來的類：SteeringMotor和MainMotor。這兩個類都從父親Motor繼承了五個方法：move()、stop()、resetCounter()、status（）、distance()。這兩個類又是另外一個類Driver的一部分。類PathAgent和Driver有一個1對1的關係，類PathAgent和CollisionSensor有1對n的關係。

4.2.6 知識擴展

1. 類圖工具欄

類圖工具欄上的按鈕名稱及功能，詳見表4.6。

表4.6 類圖工具欄

按鈕	按鈕名稱	說明
	Selection Tool	選擇工具
	Text Box	文本框
	Note	註釋
	Anchor Note to Item	將圖中的元素與註釋鏈接
	Class	類
	Interface	接口
	Unidirectional Association	單向關聯關係
	Association Class	關聯類
	Package	包
	Dependency or instantiates	依賴關係或實例化（包含和擴展關係）
	Generalization	泛化關係
	Realize	實現關係
	Association	關聯關係

 

2. 對象圖與類圖

類圖表示類及類間的關係，對象圖則表示在某一時間段這些類的具體實例及這些實例間的關係。因爲對象是類的實例，因此對象圖能夠看做是類圖的實例（對象圖中的概念也與類圖中的概念基本一致），用於幫助人們理解比較複雜的類圖。對象有生存期，因此對象圖只能在系統的某一時間段存在。

對象圖主要用來增強對類圖的理解，在實際建模中並不經常使用。使用Rational Rose工具並不能繪製對象圖，如需繪製對象圖能夠藉助於其餘建模工具。

 

第5章  時序圖

除了靜態模型外，UML還有很是重要的動態模型。本章主要介紹動態模型中的時序圖。時序圖（Sequence Diagram）也稱順序圖，描述了隨時間變化，對象間傳遞消息的前後順序。在具體應用中，時序圖一般用來展現用例行爲中各個對象的交互順序。例如「圖書管理系統」中的「借閱圖書」用例，若是咱們想刻畫該用例是如何完成借閱功能的，就要分析該用例所涉及到的對象間是經過怎樣的消息進行交互的，這些消息又是經過怎樣的順序進行傳遞的，那麼就須要爲「借閱圖書」這一用例創建相應的時序圖。時序圖可供用戶、分析人員、設計人員、編碼人員、測試人員使用，以幫助他們深刻理解系統的功能和結構。本章在全書知識體系中的位置如圖5.1所示。

 

在UML中，時序圖被描繪成一個二維關係圖。其中，橫軸表明各個參與交互的對象，縱軸表明時間，垂直向下延伸。通常來說，時序圖包括以下四種構成元素：對象（Object）、生命線（Lifeline）、消息（Message）、激活期（Activation）。

5.1 相關知識點

5.1.1 對象（Object）

在第4章靜態模型的類圖和對象圖中，咱們已經知道對象是類的實例，是系統中用來描述客觀事物的實體，是構成系統的基本單位。在本章動態模型的時序圖中，對象表明參與交互的角色，該角色能夠是類的實例，也能夠是系統參與者、人機界面、功能模塊等。

在UML 1.x中，時序圖的對象符號被表示爲矩形，該矩形包含對象名稱，而且在該對象名稱下方需加下劃線。常見格式有下列三種，實際應用中如何選擇應視具體狀況而定。

第一種見圖5.2所示，即對象名在前，類名在後，其間用冒號鏈接，代表前者是後者的對象，如「Tom」是「Student」類的一個對象。

 

第二種見圖5.3所示，此種格式用於還沒有給出對象名的狀況，如只給出「Student」類而沒有給出該類對象的具體名稱。

 

第三種格式見圖5.4所示，只給出對象名而省略類名，如只給出對象名「Tom」，卻沒有指出該對象具體屬於哪一個類。

 

5.1.2 生命線（Lifeline）

生命線表明對象在一段時期內的存在。在UML 1.x中，生命線表示爲一條垂直的虛線，存在於對象底部中心位置，如圖5.5所示。可是在UML 2.0中，生命線改爲了矩形加虛線的總體表示，而取消了原來關於對象的稱呼。另外，因爲在UML 2.0的時序圖中矩形已經不表明對象，因此先前矩形對象名稱下方的下劃線也被取消，如圖5.6所示。

在某些狀況下，須要明顯地表示出對象被銷燬。例如，當使用沒有自動垃圾回收機制的C++做爲開發語言時，或者須要特別指明對象再也不被使用時（如關閉數據庫鏈接等），都須要銷燬對象。在UML生命線中提供了表示對象銷燬的方式，如圖5.7所示。

 

 

5.1.3 消息（Message）

消息是對象間通訊的表現形式，對象間的交互是經過消息的傳遞來完成的。消息能夠激發操做、喚起信號、建立對象或撤銷對象。在時序圖和後續的協做圖中均用到了這一律念，消息在具體應用中能夠是確切的信號，也能夠是某種調用機制。

在UML中，消息表示爲箭頭，箭頭起始的一方是發送方，箭頭指向的一方是接收方，如圖5.8中所示。箭頭的類型體現了消息的類型，詳見表5.1。

 

序號	消息類型	符號表示	含義說明
1	Simple		對象間的簡單消息
2	Synchronous		對象間的同步消息
3	Balking		反身消息
4	Timeout		超時消息
5	Procedure call		對象間的過程調用
6	Asynchronous		對象間的異步消息
7	Return		返回消息

 

注：同步消息，就是須要等待消息的處理完成，才能夠接着執行下去。異步消息，就是發送之後沒必要等待完成。

5.1.4 激活期（Activation）

激活期，也稱活動期或控制期（Focus of Control），表明對象直接或間接執行某項操做的時期；換言之，在該時期內對象被佔用以完成特定的任務，而在該時期之外對象則處於空閒狀態。在UML中，激活期表示爲對象生命線上的細長矩形，該矩形也被稱爲激活條。對象在激活條的頂部被激活，完成特定的任務後進入空閒狀態，詳見圖5.8所示。

 

5.2 知識點的能力目標

可以識別「圖書管理系統」中既定場景的對象、消息等要素，而且使用Rational Rose工具繪製出相關的時序圖。

5.3 實現能力目標的具體要求

1. 識別「圖書管理系統」中「用戶登陸」場景的對象、消息等要素，並使用Rational Rose工具繪製出其登陸場景的時序圖。

2. 識別「圖書管理系統」中「圖書信息錄入」場景的對象、消息等要素，並使用Rational Rose工具繪製出其登陸場景的時序圖。

3. 識別「圖書管理系統」中管理員「查詢熱門圖書」場景的對象、消息等要素，並使用Rational Rose工具繪製出其登陸場景的時序圖。

4. 識別「圖書管理系統」中「借書」場景的對象、消息等要素，並使用Rational Rose工具繪製出其登陸場景的時序圖。

5. 識別「圖書管理系統」中「查詢罰金」場景的對象、消息等要素，並使用Rational Rose工具繪製出其登陸場景的時序圖。

5.4 須要完成的實驗

1. 創建「用戶登陸」的時序圖，並使用Rational Rose工具實現。

（1）新建模型或打開模型

 Rational Rose正常啓動後，選擇【File】->【New】菜單，新建一個模型命名爲「Library」，如圖5.9所示。若是在此以前已經創建了「Library」模型，那麼就能夠選擇【File】->【Open】菜單，打開這個原有的模型。

 

（2）新建時序圖

在視圖區域樹型列表中，右鍵單擊【Logical View】結點，而後在彈出的快捷菜單中選擇【New】->【Sequence Diagram】，如圖5.10所示。在此默認的時序圖名稱爲「New Diagram」，能夠輸入新的時序圖名稱爲「User Login」。

 

（3） 建立對象

在時序圖工具欄中選擇對象按鈕【】即「Object」，而後在繪圖區域中單擊鼠標左鍵，即可以將指定的對象添加到時序圖中，被添加的對象自動帶有生命線。若是要修改對象的名稱，能夠雙擊對象打開「對象屬性」對話框，或者右鍵單擊該對象，在彈出的快捷菜單中選擇【Open Specification】也能夠打開「對象屬性」對話框，如圖5.11所示。以建立Librarian對象爲例，在圖5.11所示對話框的【Class】下拉列表中，若是選擇「Librarian(Use Case View)」，Librarian對象將顯示爲相似參與者的圖示，若是選擇「Lirarian(Logical View:Business Package)」，Librarian對象對象將顯示爲類似於類的圖示。

 

本例時序圖中涉及到兩個對象，其一爲Librarian建立的一個對象，其二爲Reader類建立的一個對象，如圖5.12所示。

 

（4）識別對象間的消息

在時序圖工具欄中選擇消息按鈕【】即「Object Message」，而後在繪圖區域中兩個對象生命線之間拖拽鼠標左鍵，即可以在指定的對象間添加相應的消息，被添加消息後對象的激活期會自動出現。對象間的消息默認狀況下只有一個消息編號，若是要輸入消息的具體內容或設置消息的類型，能夠雙擊該消息打開「消息屬性」對話框，或者右鍵單擊該消息打開「消息屬性」對話框。在「消息屬性」對話框中選擇【General】選項卡能夠輸入消息的名字和相關說明信息，如圖5.13所示；在「消息屬性」對話框中選擇【Detail】選項卡能夠設置消息的類型等，如圖5.14所示。

 

若是要取消消息編號或取消激活期的顯示，能夠選擇主菜單欄中的【Tools】->【Options】，在彈出的對話框中選擇【Diagram】選項卡，經過複選框來完成相應的設置，如圖5.15所示。

  

 

本例時序圖中， 對象間涉及到的消息有兩個：其一爲 Librarian對象發送給Reader對象的getReaderInfo消息，用於獲取用戶信息如用戶名和密碼等；其二爲Lirarian對象發送給自身的 login消息，用於顯示是否成功登陸到「圖書管理系統」，如圖5.16所示。

 

至此，「用戶登陸」場景的時序圖已基本完成。

2. 創建「圖書信息錄入」的時序圖，並使用Rational Rose工具實現。

實際操做步驟與創建「用戶登陸」時序圖類似，使用Rational Rose工具實現的 「InputBook」時序圖如圖5.17所示。

該時序圖中涉及到的對象說明以下：

（1）Librarian對象：Librarian類即圖書管理員類建立的一個對象。

（2）BookType對象：BookType類即圖書類型建立的對象。

（3）Book對象：Book類即圖書類建立的對象。

該時序圖中涉及到的消息說明以下：

（1）bookType消息：獲取全部圖書類型編號及類型名稱。

（2）operationType消息：選擇操做方式。

（3）getBookInfo消息：獲取圖書基本信息。

（4）returnBookInfo消息：返回獲取到的圖書基本信息。

（5）editPage消息：界面編輯。

（6）inputBookInfo：根據操做方式錄入圖書基本信息。

（7）returnInputMess：返回錄入信息。

 

 

3. 識別「圖書管理系統」中管理員「查詢熱門圖書」場景的對象、消息等要素，並使用Rational Rose工具繪製出其登陸場景的時序圖。

實際操做步驟與創建「用戶登陸」時序圖類似，使用Rational Rose工具實現的 「SearchHotBook」時序圖如圖5.18所示。

該時序圖中涉及到的對象說明以下：

（1）Librarian對象：Librarian類即圖書管理員類建立的一個對象。

（2）BorrowManage對象：借閱管理對象。

（3）BookType對象：圖書類型對象。

（4）Book對象：圖書對象。

該時序圖中涉及到的消息說明以下：

（1）getBorrowInfo消息：獲取借閱信息。

（2）getBookType消息：獲取圖書類型信息。

（3）getBookInfo消息：獲取圖書基本信息。

（4）showResult消息：顯示查詢結果。

4. 識別「圖書管理系統」中「借書」場景的對象、消息等要素，並使用Rational Rose工具繪製出其登陸場景的時序圖。

實際操做步驟與創建「用戶登陸」時序圖類似，使用Rational Rose工具實現的 「BorrowBook」時序圖如圖5.19所示。

 

 

 

 

 

該時序圖中涉及到的對象說明以下：

（1）Librarian對象：Librarian類即圖書管理員類建立的一個對象。

（2）Reader對象：讀者對象。

（3）Book對象：圖書對象。

（4）ReaderType對象：讀者類型對象。

（5）BorrowManage對象：借閱管理對象。

該時序圖中涉及到的消息說明以下：

（1）getReaderInfo消息：獲取讀者基本信息，如辦證日期、借閱數量、掛失標誌，用處理圖書證過時、借閱數量已滿等問題

（2）getReaderType消息：獲取讀者類型信息。

（3）getBookFlag消息：獲取圖書借閱標誌，用於判斷圖書是否可借閱。

（4）InputBorrowInfo消息：輸入借閱信息，如讀者編號，圖書編號，借還日期等。

（5）modifyBookFlag消息：修改圖書借閱標誌。

（6）addBorrowBook消息：增長讀者已借閱圖書數量。

5. 識別「圖書管理系統」中「查詢罰金」場景的對象、消息等要素，並使用Rational Rose工具繪製出其登陸場景的時序圖。

實際操做步驟與創建「用戶登陸」時序圖類似，使用Rational Rose工具實現的 「SearchPayment」時序圖如圖5.20所示。

 

 

 

該時序圖中涉及到的對象說明以下：

（1）Librarian對象：Librarian類即圖書管理員類建立的一個對象。

（2）Reader對象：讀者對象。

（3）Book對象：圖書對象。

（4）BorrowManage對象：借閱管理對象。

該時序圖中涉及到的消息說明以下：

（1）inputOption消息：輸入查詢條件信息。

（2）getPaymentInfo消息：獲取罰金信息。

（3）getReaderInfo消息：獲取讀者基本信息。

（4）getBookInfo消息：獲取圖書基本信息。

（5）showResult消息：顯示出讀者、圖書及罰金信息。

5.5 測試能力目標

1. 什麼是時序圖？時序圖的構成要素有哪些？

2. 創建時序圖應遵循怎樣的步驟？

3 閱讀如圖5.21所示「購買飲料」主要場景的時序圖，試描述不一樣對象間消息的傳遞。

 

4 閱讀如圖5.22所示「飲料已售完」場景的時序圖，試描述不一樣對象間消息的傳遞。

 

5 參考「圖書管理系統」的「借書」時序圖，建立「還書」時序圖，並使用Rational Rose工具實現。

6 參考「圖書管理系統」的「圖書信息錄入」時序圖，建立「讀者信息錄入」時序圖，並使用Rational Rose工具實現。

7 參考「圖書管理系統」的「查詢熱門圖書」時序圖，建立「查詢讀者信息」時序圖，並使用Rational Rose工具實現。

8. 根據以下文字描述，繪製出「ATM取款」最理想場景（無需考慮特殊狀況）的時序圖，並用Rational Rose工具實現。

（1）開始用戶「Jack」將銀行卡插入到讀卡器，讀卡器讀取卡號，打開「Jack」的帳目對象，並初始化屏幕，屏幕提示輸入PIN密碼，「Jack」輸入密碼，而後系統驗證密碼與帳戶對象，發出相符的信息。

（2）ATM屏幕向「Jack」提供操做選項，「Jack」選擇取款，而後屏幕提示「Jack」輸入取款金額，他選擇了2000元RMB，系統啓動帳目對象進行覈實，以後從帳戶中取錢。

（3）系統啓動帳目對象進行覈實的過程以下：首先，驗證「Jack」的帳目至少有2000元RMB ；而後從中扣除2000元RMB，再讓吐鈔機提供2000元RMB現金；另外還須要讓票據打印機提供取款憑據；最後讓讀卡器退卡。

5.6 知識擴展

1. 監護條件

爲了詳細說明對象間的消息傳遞，能夠在時序圖中使用監護條件（或稱約束條件），加以輔助說明，如圖5.23「購買飲料零錢找不開」場景時序圖所示，其中括號內部標註信息即爲監護條件。例如消息3的監護條件是[cash>price]即顧客現金大於飲料售價，此條件知足時Recorder（記錄儀）對象才傳遞找零信息給Distributor（分配器）對象；又如消息5的監護條件是[no Change]即沒有零錢，此條件知足時Recorder（記錄儀）對象纔會傳遞相關提示信息給Panel（面板）對象。

 

在大部分狀況下，時序圖中發送消息的時間是能夠忽略的。若是有某些特殊狀況須要表示消息間的時間差，也能夠在圖中使用監護條件，用於指示時間間隔。

2. 時序圖工具欄

時序圖工具欄上的按鈕名稱及功能，詳見表5.2。

表5.2 時序圖工具欄按鈕

按鈕	按鈕名稱	說明
	Selection Tool	選擇工具
	Text Box	文本框
	Note	註釋
	Anchor Note to Item	將圖中的元素與註釋鏈接
	Object	對象
	Object Message	對象間的消息
	Message to Self	反身消息
	Return Message	返回消息
	Destruction Marker	銷燬對象

 

第6章  協做圖

協做圖（Collaboration Diagram）和時序圖同樣，都是用於描述系統動態特性的交互圖；只不過期序圖側重強調消息的前後順序，而協做圖側重強調參與交互的各個對象是如何組織的。本章在全書知識體系中的位置如圖6.1所示。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

通常來說，協做圖包括以下三種構成元素：對象（Object）、鏈（Link）和消息（Message）。

6.1 相關知識點

6.1.1 對象（Object）

對象表明協做圖中參與交互的角色，和時序圖中對象的概念基本類似。只不過在協做圖中，沒法表示出對象的建立與對象的撤銷，正由於如此在協做圖中對象的位置沒有特殊限制。如圖6.2所示，矩形框中的內容表明對象。

6.1.2 鏈（Link）

鏈是鏈接兩個對象的路徑，它指明瞭對象間的關聯。在UML中，鏈被表示爲一條實線。如圖6.2所示，從Student類的一個對象到Teacher類的一個對象之間存在鏈（或路徑），消息會沿着此鏈流轉，如message1，message2和message3。

6.1.3 消息（Message）

協做圖中的消息與時序圖中的消息類似，可是爲了可以在協做圖中顯示交互過程當中消息的時間順序，一般也爲交互的消息添加順序號。順序號是一個數字前綴，由數字1開始依次遞增，每一個消息有一個惟一的順序號，能夠經過點表示法表明消息的嵌套關係。例如在圖6.2消息2中，消息2.1是嵌套在消息2中的第一個消息，它在2.2以前，以此類推。因爲在消息中使用了嵌套表示，與時序圖相比，協做圖能夠顯示更爲複雜的內容。

 

 

 

 

 

 

 

6.2 知識點的能力目標

可以捕獲「圖書管理系統」中既定場景的對象、消息等要素，而且使用Rational Rose工具繪製出協做圖；可以將指定的時序圖轉化成協做圖，而且使用Rational Rose工具繪製出其圖示。

6.3 實現能力目標的具體要求

1. 識別「圖書管理系統」中「讀者預訂」場景的對象、消息等要素，並使用Rational Rose工具繪製出其讀者預訂的協做圖。

2. 識別「圖書管理系統」中「讀者確認預訂」場景的對象、消息等要素，並使用Rational Rose工具繪製出其讀者確認預訂的協做圖。

3. 將「圖書管理系統」中「用戶登陸」場景的時序圖轉化成協做圖，並使用Rational Rose工具繪製出該協做圖。

4. 將「圖書管理系統」中「圖書信息錄入」場景的時序圖轉化成協做圖，並使用Rational Rose工具繪製出該協做圖。

5. 將「圖書管理系統」中「查詢熱門圖書」場景的時序圖轉化成協做圖，並使用Rational Rose工具繪製出該協做圖。

6. 將「圖書管理系統」中「借書」場景的時序圖轉化成協做圖，並使用Rational Rose工具繪製出該協做圖。

7. 將「圖書管理系統」中「查詢罰金」場景的時序圖轉化成協做圖，並使用Rational Rose工具繪製出該協做圖。

6.4 須要完成的實驗

1. 創建「讀者預訂」協做圖，並使用Rational Rose工具實現。

（1）打開模型

 Rational Rose正常啓動後，選擇【File】->【Open】菜單，打開此前已有的「Library」模型。

（2）新建協做圖

在視圖區域樹型列表中，右鍵單擊【Logical View】結點，而後在彈出的快捷菜單中選擇【New】->【Collaboration Diagram】，如圖6.3所示。在此默認的協做圖名稱爲「New Diagram」，能夠輸入新的協做圖名稱爲「Reader Reserve」。雙擊該協做圖，在Rational Rose窗口內右側空白處出現相應的編輯區，在編輯區中可進行後續操做。

 

圖6.3 新建協做圖

（3）建立對象

在協做圖工具欄中選擇對象按鈕【】即「Object」，而後在編輯區中單擊鼠標左鍵，即可以將指定的對象添加到協做圖中。若是要修改對象的名稱，能夠雙擊對象打開「對象屬性」對話框，或者右鍵單擊該對象，在彈出的快捷菜單中選擇【Open Specification】也能夠打開「對象屬性」對話框，具體參見第5章中圖5.11所示。

本例協做圖中涉及到四個對象，其一爲Reader類建立的對象，其二爲Main類建立的對象，其三爲Book類建立的對象，其四爲Reserve類建立的對象，如圖6.4所示。

 

圖6.4 建立對象

（4）在對象間添加鏈和消息

在協做圖工具欄中選擇鏈的按鈕【】即「Object Link」，而後在編輯區中兩個對象之間拖拽鼠標左鍵，即可以在指定的對象間添加鏈。若是須要對鏈進行詳細設置，能夠雙擊鏈，或者右鍵單擊鏈，在彈出的快捷菜單中選擇【Open Specification】，打開「鏈屬性」對話框，如圖6.5所示。

 

圖6.5 「鏈屬性」對話框

對象間添加鏈之後，能夠在鏈上添加相應的消息。以Reader對象發送給Main對象的readerID（讀者證號）消息爲例，將具體添加方法說明以下。

方法之一是：在協做圖工具欄中選擇消息按鈕【】即「Object Message」，此時將鼠標停放在該編輯區任意位置，鼠標會變成十字形狀，在須要添加消息的鏈上再次單擊鼠標便可在該鏈上添加消息。對象間的消息默認狀況下只有一個消息編號，若是要輸入消息的具體內容或設置消息的類型，能夠雙擊該消息打開「消息屬性」對話框，或者右鍵單擊該消息打開 「消息屬性」對話框。在「消息屬性」對話框中選擇【General】選項卡能夠輸入消息的名字和相關說明信息，具體參見第5章中圖5.13所示；在「消息屬性」對話框中選擇【Detail】選項卡能夠設置消息的類型，具體參見第5章圖5.14所示。

方法之二是：在圖6.5所示的「鏈屬性」對話框中，選擇【Messages】選項卡，而後右鍵單擊中間空白區域，在彈出的快捷菜單中選擇【Insert To :Main】菜單項，最後鍵入新的消息名稱「readerID」替換默認屬性名稱「opname」。如圖6.6所示。

 

圖6.6 添加消息

本例協做圖中， 對象間涉及到的消息有四個：其一爲 Reader對象發送給Main對象的readerID（讀者證號）消息；其二爲Main對象發送給Book對象的queryRequirement（查詢條件）消息；其三爲Book對象發送給Main對象的返回消息queryResult（查詢結果），其四是Main對象發送給Reserve對象的reserveSuccess（預訂成功）消息。如圖6.7所示。

 

圖6.7 「Reader Reserve」協做圖

至此，「讀者預訂」協做圖已基本完成。

2. 創建「讀者確認預訂」協做圖，並使用Rational Rose工具實現。

實際操做步驟與創建「讀者預訂」協做圖類似，使用Rational Rose工具實現的 「Reader Confirm」協做圖如圖6.8所示。

該協做圖中涉及到的對象說明以下：

（1）Librarian對象：Librarian類即圖書管理員類建立的一個對象。

（2）Reserve對象：Reserve類即預訂類建立的對象。

（3）Book對象：Book即圖書類建立的對象。

（4）Reader對象：Reader類即讀者類建立的對象。

（5）Borrow對象：Borrow類即借閱類建立的對象。

該協做圖中涉及到的消息說明以下：

（1）readerInfo消息：讀者信息。

（2）reserveInfo消息：預訂信息。

（3）confirmRequirement消息：請求確認預訂。

（4）successInfo消息：覈對成功。

（5）borrowInfo消息：借閱信息。

（6）bookInfo：圖書信息。

（7）bookRequirement：請求獲取圖書。

 

圖6.8「Reader Confirm」協做圖

3. 創建「用戶登陸」協做圖，並使用Rational Rose工具實現。

使用Rational Rose工具，創建「用戶登陸」協做圖的方法有兩種。

方法之一是按照創建「讀者預訂」協做圖的步驟操做。

方法之二是採用時序圖和協做圖自動相互轉換的方式。具體步驟以下：

（1）首先打開要轉換的時序圖，如「User Login」時序圖。

（2）而後選擇Rational Rose主菜單中的【Browse】->【Go To Collaboration Diagram】菜單項，如圖6.9所示，便可將當前時序圖轉換成協做圖。在圖6.9所示的菜單中，選擇【Previous Diagram】菜單項還能夠查看轉換前的UML圖示。固然也能夠在Rational Rose中按「F5」快捷鍵，直接將「User Login」時序圖轉化成協做圖。

相似地，也能夠將協做圖轉換成時序圖。具體步驟同上：首先打開要轉換的協做圖，如「User Login」協做圖；而後選擇Rational Rose主菜單中的【Browse】->【Go To Sequence Diagram】菜單項，如圖6.10所示，便可將當前協做圖轉換成時序圖。一樣，在圖6.10所示的菜單中，選擇【Previous Diagram】菜單項也能夠查看轉換前的UML圖示。

不管採用哪一種方式，最終完成的協做圖如圖6.11所示。

 

圖6.9 轉化成協做圖                       圖6.10轉化成時序圖

 

 

圖6.11「User Login」協做圖

該協做圖中涉及到的對象說明以下：

（1）Librarian對象：Librarian類即圖書管理員類建立的一個對象。

（2）UserInfo對象：用戶信息表對象。

該協做圖中涉及到的消息說明以下：

（1）getUserInfo消息：用於獲取用戶信息如用戶名和密碼等。

（2）login消息：用於顯示是否成功登陸到「圖書管理系統」。

4. 創建「圖書信息錄入」協做圖，並使用Rational Rose工具實現。

實際操做步驟與創建「用戶登陸」協做圖類似，使用Rational Rose工具實現的 「InputBook」協做圖如圖6.12所示。

該協做圖中涉及到的對象說明以下：

（1）Librarian對象：Librarian類即圖書管理員類建立的一個對象。

（2）BookType對象：BookType類即圖書類型建立的對象。

（3）Book對象：Book類即圖書類建立的對象。

該協做圖中涉及到的消息說明以下：

（1）bookType消息：獲取全部圖書類型編號及類型名稱。

（2）operationType消息：選擇操做方式。

 

圖6.12 「InputBook」協做圖

（3）getBookInfo消息：獲取圖書基本信息。

（4）returnBookInfo消息：返回獲取到的圖書基本信息。

（5）editPage消息：界面編輯。

（6）inputBookInfo：根據操做方式錄入圖書基本信息。

（7）returnInputMess：返回錄入信息。

5. 創建「查詢熱門圖書」協做圖，並使用Rational Rose工具實現。

實際操做步驟與創建「用戶登陸」協做圖類似，使用Rational Rose工具實現的 「SearchHotBook」協做圖如圖6.13所示。

 

圖6.13「SearchHotBook」協做圖

該協做圖中涉及到的對象說明以下：

（1）Librarian對象：Librarian類即圖書管理員類建立的一個對象。

（2）BorrowManage對象：借閱管理對象。

（3）BookType對象：圖書類型對象。

（4）Book對象：圖書對象。

該協做圖中涉及到的消息說明以下：

（1）getBorrowInfo消息：獲取借閱信息。

（2）getBookType消息：獲取圖書類型信息。

（3）getBookInfo消息：獲取圖書基本信息。

（4）showResult消息：顯示查詢結果。

6. 創建「借書」協做圖，並使用Rational Rose工具實現。

實際操做步驟與創建「用戶登陸」協做圖類似，使用Rational Rose工具實現的 「BorrowBook」協做圖如圖6.14所示。

 

圖6.14 「BorrowBook」協做圖

該協做圖中涉及到的對象說明以下：

（1）Librarian對象：Librarian類即圖書管理員類建立的一個對象。

（2）BorrowManage對象：借閱管理對象。

（3）Reader對象：讀者對象。

（4）Book對象：圖書對象。

（5）ReaderType對象：讀者類型對象。

該協做圖中涉及到的消息說明以下：

（1）getReaderInfo消息：獲取讀者基本信息，如辦證日期、借閱數量、掛失標誌，用處理圖書證過時、借閱數量已滿等問題

（2）getReaderType消息：獲取讀者類型信息。

（3）getBookFlag消息：獲取圖書借閱標誌，用於判斷圖書是否可借閱。

（4）InputBorrowInfo消息：輸入借閱信息，如讀者編號，圖書編號，借還日期等。

（5）modifyBookFlag消息：修改圖書借閱標誌。

（6）addBorrowBook消息：增長讀者已借閱圖書數量。

7. 創建「查詢罰金」協做圖，並使用Rational Rose工具實現。

實際操做步驟與創建「用戶登陸」協做圖類似，使用Rational Rose工具實現的 「SearchPayment」協做圖如圖6.15所示。

該協做圖中涉及到的對象說明以下：

（1）Librarian對象：Librarian類即圖書管理員類建立的一個對象。

（2）Reader對象：讀者對象。

（3）Book對象：圖書對象。

（4）BorrowManage對象：借閱管理對象。

該協做圖中涉及到的消息說明以下：

（1）inputOption消息：輸入查詢條件信息。

（2）getPaymentInfo消息：獲取罰金信息。

（3）getReaderInfo消息：獲取讀者基本信息。

（4）getBookInfo消息：獲取圖書基本信息。

（5）showResult消息：顯示出讀者、圖書及罰金信息。

 

圖6.15「SearchPayment」協做圖

6.5 測試能力目標

1. 關於協做圖的敘述，不正確的是（     ）。

A. 協做圖做爲一種交互圖，強調參加交互的對象的組織

B. 在Rational Rose工具中，協做圖可在時序圖的基礎上按「F5」鍵自動生成

C. 協做圖中有消息的順序號

D. 協做圖是時序圖的一種

2. 下面哪一種圖最合適用來描述場景：（     ）。

A. 包圖                         B. 交互圖

C. 類圖                         D. 用例圖

3. 什麼是協做圖，協做圖由哪些部分組成？

4. 將下圖6.16所示的時序圖轉換成協做圖。

5. 根據下圖6.17所示的協做圖，描述參與交互的對象及對象間的消息。

6. 根據某連鎖企業對其分店管理的協做圖，以下圖6.18所示，描述其管理過程。

7. 根據下圖6.19所示的協做圖，描述對象之間的消息傳遞，並將其轉換爲時序圖。

8 創建「教務管理系統」中「學位評審」的協做圖，其中學生學位評審流程描述以下。

（1）教務人員將需評審的學生的學號輸入學位初評模塊。

（2）學位初評模塊會查詢相應學生的成績和獎懲記錄，來做爲學位評定的依據。

（3）學位初評模塊將初評結果打印。

（4）學位初評打印稿被提交給教務人員。

 

圖6.16 「發送消息」時序圖

 

圖6.17 「ATM驗證用戶」協做圖

 

圖6.18 分店管理協做圖

 

圖6.19 維護課程信息協做圖

6.6 知識擴展

1. 時序圖與協做圖的比較

時序圖與協做圖都是交互圖，兩者既有聯繫又有區別。

聯繫體現爲：順序圖和協做圖都是用於描述系統動態特性的交互圖；時序圖和協做圖從語義上講是相同的，它們只是從不一樣的方面來描述一次交互。

區別體現爲：時序圖強調消息的時間順序，協做圖強調參加交互的對象的組織。一般狀況下，兩者能夠相互轉換。

2. 交互圖與類圖的關係

前面已經介紹過，協做圖和時序圖，都是用於描述系統動態特性的交互圖。值得注意的是，當繪製交互圖時，也就是在動態建模的過程當中可能會發現一些新的類及方法。所以，類圖的定義可以從交互圖中產生。

在具體實踐中，動態建模和靜態建模每每是並行的。例如，10分鐘繪製靜態模型，10分鐘繪製動態模型，如此交替進行。

3. 協做圖工具欄

協做圖工具欄上的按鈕名稱及功能，詳見表6.1。

表6.1 協做圖工具欄按鈕

按鈕	按鈕名稱	說明
	Selection Tool	選擇工具
	Text Box	文本框
	Note	註釋
	Anchor Note to Item	將圖中的元素與註釋鏈接
	Object	對象
	Class Instance	類實例
	Object Link	對象間的鏈
	Link To Self	連接自身的鏈
	Link Message	消息
	Reverse Link Message	返回消息
	Data Token	數據流
	Reverse Data Token	返回數據流

 

第7章  狀態圖

狀態圖（Statechart Diagram）是描述系統動態行爲的一種經常使用工具，它強調從狀態到狀態的控制流，規定了對象在其生命週期內響應事件所經歷的狀態序列以及對象針對這些事件的響應。換言之，狀態圖主要用於創建類的一個對象在其生存期間的動態行爲，表現一個對象所經歷的狀態序列，引發狀態轉移的事件（Event），以及因狀態轉移而伴隨的動做（Action）。但值得說明的是，並不須要爲系統中涉及的全部對象都建立狀態圖，只有當行爲的改變和狀態有關時才須要建立狀態圖。

與交互圖適合於描述單個用例中多個對象的行爲不一樣，狀態圖適合於描述跨越多個用例的單個對象的行爲，而不適合於描述多個對象之間的行爲協做，所以，在實際應用中經常將狀態圖與其它技術組合使用。狀態圖在檢查、調試和描述類的動態行爲時很是有用。本章在全書知識體系中的位置如圖7.1所示。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

通常來說，協做圖包括以下幾種構成元素：起點（Start）和終點（End）、狀態（State）、事件（Event）、轉換（Transition）。

7.1 相關知識點

7.1.1起點（Start）和終點（End）

起點是狀態圖的初始狀態，也是狀態圖的起始位置，表示一個工做流程的開始。起點只能做爲轉換（Transition）的源，而不能做爲轉換（Transition）的目標。起點在狀態圖中只容許有一個。在UML中，起點被表示爲實心圓，如圖7.2所示。

終點是狀態圖的最後狀態，也是狀態圖的終止位置。與起點相反，終點只能做爲轉換（Transition）的目標，而不能做爲轉換（Transition）的源。終點在一個狀態圖中能夠有一個或有多個，也能夠沒有。在UML中，終點被表示爲環形，環形內圓爲實心圓，如圖7.2所示。

 

圖7.2 狀態圖的起點和終點

7.1.2狀態（State）

狀態是指對象在其生命週期內某時刻所處的的情形，在此期間對象將知足某些條件、執行某些活動或等待某些事件。下面就以「圖書管理系統」中的對象爲例，說明其狀態。

例如，《C語言程序設計教程》在圖書館中，那麼此時該圖書對象就處於在館狀態。又如，「張三」已經畢業，那麼此時該讀者對象就處於離校狀態。再如，「李四」的讀者證已經掛失且不曾補辦，那麼此時該讀者證對象就處於無效狀態。

一個狀態能夠包括如下幾個組成部分：狀態名稱（State Name）、入口/出口動做（Entry/Exit Action）、動做（Action）、子狀態（Substate）。在實際應用中，狀態名稱通常須要表示出來，而入口/出口動做（Entry/Exit Action）、動做（Action）、子狀態（Substate）部分能夠視具體狀況而定。在UML中，狀態被表示爲圓角矩形框，如圖7.3所示。

（1）狀態名稱（State Name）

狀態名稱用於識別不一樣的狀態，一般被表示爲一個字符串，放置於狀態的頂部，如圖7.4所示，狀態名稱爲Faxing。

（2）入口/出口動做（Entry/Exit Action）

入口動做表示進入某個狀態所執行的操做，入口動做的語法是：entry/執行的動做。出口動做表示退出某個狀態所執行的操做，出口動做的語法是：exit/執行的動做。這裏所說的動做能夠是原子動做，也能夠是一個動做序列。如圖7.4中所示，進入Faxing狀態所執行的操做，即該狀態的入口動做表示爲entry/key in remote fax number，退出Faxing狀態所執行的操做，即該狀態的出口動做表示爲exit/complete transmission。

（3）動做（Action）

動做表示在某個狀態下，須要執行的操做。這裏所說的動做一樣能夠是原子動做，也能夠是一個動做序列。如圖7.4中所示，在Faxing狀態下須要執行的操做，即該狀態的動做表示爲do/add datestamp和do/timestamp。

（4）子狀態（Substate）

一個狀態容許嵌套，以包含子狀態，子狀態繼承其父狀態的全部轉換（Transition）。這使得即使在複雜的應用中，也能夠繪製出結構清晰的狀態圖。以電話機對象的狀態爲例，

其簡潔的描繪方式如圖7.5所示。接線員掛機（on hook）以後再次拿起話筒以前電話機處於空閒（Idle）狀態，當摘機（off hook）事件發生時，電話從空閒（Idle）狀態轉換爲活動（Active）狀態。而對於活動（Active）狀態來講相對比較複雜，因此能夠採用其子狀態加以詳細描繪，如圖7.6所示，其中PlayingDialTone狀態、 Dialing狀態、Connecting狀態、Talking狀態都是Active狀態的子狀態。當發生某個到活動（Active）狀態的轉換時，播放撥號音（PlayingDialTone）狀態被建立，並自動轉換到該狀態。不管電話機對象處於活動（Active）狀態的哪個子狀態，當掛機（on hook）事件發生時，都發生向空閒（Idle）狀態的轉換。

 

圖7.4 狀態的組成部分

 

圖7.5 電話機對象狀態圖1

 

圖7.6 電話機對象狀態圖2

7.1.3事件（Event）

事件是指一件值得注意的事情的發生，事件可以引發某些動做執行。例如，電話接線員拿起話筒，此處「拿起話筒」就是事件，而事件引發的動做就是「開始通話」。又如，當按下CD機上的Play按鈕時，CD機開始播放音樂，此處「按下Play按鈕」就是事件，而事件引起的動做就是「開始播放」。

事件產生的緣由包括：調用、知足條件的狀態的出現、到達時間點或經歷某一時間段、發送信號等等。事件的圖形表示方式，可參見圖7.5和圖7.8中的標註。

7.1.4轉換（Transition）

轉換用於描述兩個狀態之間的關係，表示對象將在第一個狀態中執行必定的動做，並在某個特定事件發生時進入第二個狀態。也就是說，轉換每每由事件引起。

在UML中，轉換被表示爲箭頭，箭頭起始的一端爲源狀態，箭頭指向的一端爲目標狀態，如圖7.7所示。

 

圖7.7 轉換

對於一個給定的狀態，最終只能產生一個轉換。所以從相同的狀態出發、事件相同的幾個轉換之間的條件應該是互斥的。如圖7.8所示，從源狀態「A」出發，事件均爲「event」的三個轉換條件分別爲[x<0]、[ x=0]、[ x>0]，這三個條件自己是互斥的，使得對於給定的狀態「A」，最終只能產生一個轉換。

 

圖7.8 轉換中的互斥條件

7.2 知識點的能力目標

可以捕獲「圖書管理系統」中指定對象的狀態，而且使用Rational Rose工具繪製出相應的狀態圖。

7.3 實現能力目標的具體要求

1. 創建讀者證對象的狀態圖，並使用Rational Rose工具實現。

2. 創建圖書對象的狀態圖，並使用Rational Rose工具實現。

3. 創建整個系統的狀態圖，並使用Rational Rose工具實現。

7.4 須要完成的實驗

1. 創建讀者證對象的狀態圖，並使用Rational Rose工具實現。

（1）打開模型

Rational Rose啓動後，選擇【File】->【Open】菜單，打開已有的「Library」模型。

（2）新建狀態圖

在視圖區域樹型列表中，右鍵單擊【Logical View】結點，而後在彈出的快捷菜單中選擇【New】->【Statechart Diagram】，如圖7.9所示。在此默認的狀態圖名稱爲「New Diagram」，能夠輸入新的狀態圖名稱爲「ReaderCard State」。雙擊該狀態圖，在Rational Rose窗口內右側空白處出現相應的編輯區，在編輯區中可進行後續操做。

 

圖7.9 新建狀態圖

（3）添加狀態及轉換

在狀態圖工具欄中選擇起點按鈕【】即「Start State」，而後在編輯區中單擊鼠標左鍵，即可以將初始狀態添加到狀態圖中。

繼續在狀態圖工具欄中選擇狀態按鈕【】即「State」，而後在編輯區中單擊鼠標左鍵，即可以將狀態添加到狀態圖中。新添加的狀態默認名稱爲「NewState」，可將其名稱根據具體狀況進行修改。簡便的修改方法是直接在「NewState」處鍵入狀態的新名稱；稍複雜的修改方法是雙擊該狀態打開「狀態屬性」對話框，或者右鍵單擊該狀態，在彈出的快捷菜單中選擇【Open Specification】也能夠打開「狀態屬性」對話框，如圖7.10所示，在此將狀態命名爲「Valid」。若是還須要爲狀態設置入口/出口動做、動做等內容，能夠雙擊「狀態屬性」對話框中的【Actions】選項卡，而後在中間空白區域任意位置右鍵單擊，會彈出如圖7.11所示的快捷菜單。在彈出的快捷菜單中選擇【Insert】菜單項，能夠添加動做，新添加的動做默認類型爲「Entry」，默認名稱爲空。若是想修改動做的類型和名稱，能夠在圖7.11所示的快捷菜單中選擇【Specification】菜單項，打開如圖7.12所示的「動做屬性」對話框，在該對話框中進行詳細的設置。

 

圖7.10 「狀態屬性」對話框

 

依照如上方法，分別建立出讀者證的三個狀態：Valid（有效）、Losing（掛失）、Invalid（無效）。

在不一樣狀態之間能夠添加轉換，完成從一種狀態到另外一種狀態的過渡。具體方法是：在狀態圖工具欄中單擊轉換符號【】即「State Transition」，而後將鼠標停放在編輯區任意位置，鼠標會變成箭頭形狀，箭頭方向向上，此時採用按住鼠標左鍵拖拽的方式，首先將Valid狀態和Losing狀態之間添加轉換。而後，雙擊該轉換，打開「狀態轉換屬性」對話框，在該對話框的【General】選項卡中能夠設置轉換名稱、參數等內容，如圖7.13所示。在「狀態轉換屬性」對話框中單擊【Detail】選項卡，能夠打開如圖7.14所示的界面，在該界面中能夠設置監護條件等內容。

 

圖7.11 設置狀態包含的動做

 

 

圖7.12 「動做屬性」對話框

 

 

圖7.13 「狀態轉換」對話框

 

 

圖7.14 設置監護條件

 

若是狀態圖還有終止狀態，則能夠在狀態圖工具欄中選擇終點按鈕【】即「End State」，繼而在編輯區中單擊鼠標左鍵，即可以將終止狀態添加到狀態圖中。

（4）調整圖形

按照美觀實用的原則，調整狀態圖中各元素的大小和位置。其中對線性的調整能夠參照圖7.15所示的菜單進行操做，以保證線性的平滑。

 

圖7.15 調整線性

 

通過以上各步驟，最終獲得「圖書管理系統」中讀者證狀態圖如圖7.16所示。

 

圖7.16 「ReaderCard State」狀態圖

經過讀者證對象的狀態圖可知：

（1）讀者證對象首先進入初始狀態，讀者辦理讀者證（get card）後，該讀者證轉換到有效（Valid）狀態，入口動做是得到新證（get new card）；

（2）發生讀者證丟失（lose card）事件後，該讀者證從有效狀態轉換到掛失（losing）狀態，此時動做爲丟失讀者證（lost card）；

（3）發生補辦讀者證（retrieve card）事件後，該讀者證從掛失狀態轉換到有效狀態；

（4）讀者證丟失但讀者放棄讀者證（give up card）事件發生後，該讀者證從掛失狀態轉換到無效（Invalid）狀態；

（5）發生讀者畢業（reader graduate）事件後，該讀者證從有效狀態轉換到無效狀態，出口動做是歸還讀者證（return card）。

2. 創建圖書對象的狀態圖，並使用Rational Rose工具實現。

實際操做步驟與創建讀者證對象狀態圖類似，使用Rational Rose工具實現的 「Book State」狀態圖如圖7.17所示。

 

圖7.17 「Book State」狀態圖

經過圖書對象狀態圖可知：

（1）圖書對象首先進入初始狀態，購入新書（buy new book）後，該圖書轉換到入庫（Enter To Store）狀態；

（2）發生登記圖書（book in）事件後，該圖書會由入庫狀態轉換到在館（In Store）狀態；

（3）圖書處於在庫狀態時，若是發生讀者預訂（reader reserve）事件，那麼該圖書將從在館狀態轉換到預訂（Reserved）狀態；

（4）圖書處於在館狀態時，若是發生讀者借閱（reader borrow）事件，那麼該圖書將從在館狀態轉換到在借（Borrowed）狀態；

（5）圖書處於預訂狀態時，若是發生取消預訂（cancel reservation）事件，那麼該圖書將從預訂狀態轉換回在館狀態；

（6）圖書處於預訂狀態時，若是發生了確認預訂（confirm reservation）事件，那麼該圖書將從預訂狀態轉換到在借狀態；

（7）圖書處於在借狀態時，若是發生了歸還圖書（return book）事件，那麼該圖書將從在借狀態轉回到在館狀態；

（8）圖書處於在借狀態時，若是發生了丟失圖書（lose book）事件，那麼該圖書將從在借狀態轉換到註銷（Logout）狀態；

（9）圖書處於在館狀態時，若是發生了圖書下架（remove book）事件後，那麼該圖書將從在館狀態轉換到下架（Off Bookshelf）狀態。

3. 創建整個系統的狀態圖，並使用Rational Rose工具實現。

實際操做步驟與創建讀者證對象狀態圖類似，使用Rational Rose工具實現的 「System State」狀態圖如圖7.18所示。

 

圖7.18 「System State」狀態圖

經過整個系統的狀態圖可知：

（1）系統首先進入初始狀態，用戶輸入登陸（input login information）信息後，系統進入登陸（Login）狀態；

（2）系統進入登陸狀態後，根據用戶的操做產生相應的事件，系統能夠進入讀書管理（Book Management）狀態、讀者管理（Reader Management）狀態、借閱管理（Borrow Management）狀態、罰金管理（Fine Management）狀態、關閉（Closing）狀態；

（3）系統進入讀書管理（Book Management）狀態、讀者管理（Reader Management）狀態、借閱管理（Borrow Management）狀態、罰金管理（Fine Management）狀態之一後，發生退出（quit）事件時，系統將進入關閉（Closing）狀態。

7.5 測試能力目標

1. 要描述控制機制，好比描述一個系統中的控制對象，（     ）最合適。

A. 時序圖（Sequence Diagram）    B. 狀態圖（Statechart Diagram）

C . 類圖（Class Diagram）         D. 協做圖（Collaboration Diagram）

2. 下面關於狀態圖的說法錯誤的是（      ）。

A. 狀態圖適合用來描述跨多個用例的對象的行爲

B. 狀態圖只適用於那些有多個狀態的對象，而不是系統中絕大多數或全部的對象

C. 狀態圖適合用來描述多個對象的交互

D. 狀態圖能夠用於圖形用戶界面或控制對象

3. 如圖7.19所示爲一個MortgageApplication的狀態圖。假設要加入一個新的需求：除了「Closed」狀態，其餘任何狀態都能遷移到「Cancelled」狀態。如下（         ）方法最好。

A. 只從其中一個狀態遷移到「Cancelled」狀態

B. 在圖中增長「Cancelled」父狀態

C. 增長一個「Active」父狀態來處理到「Cancelled」狀態的遷移

D. 從「Submitted」和「Qualified」到新的「Cancelled」狀態都增長一個遷移

 

圖7.19 MortgageApplication的狀態圖

 

4. 根據圖7.20所示的狀態圖，回答問題。

 

圖7.20 線程的狀態圖

（1）該圖中有幾種狀態，分別爲_____________________________。

（2）請描述線程的基本運行過程_____________________________。

5. 根據圖7.21所示的手機狀態圖，描述手機的工做過程。

 

圖7.21 手機狀態圖

6. 根據以下描述，繪製電梯狀態圖。

（1）電梯開始處於空閒（Idle）狀態，當有人按下按鈕要求使用電梯時（is required事件發生），電梯進入運行（Run）狀態；

（2）若是電梯的當前樓層比想要的樓層高時（[currentFloor>desiredFloor]監護條件成立），電梯進入降低（Moving Down）狀態；

（3）反之，若是電梯的當前樓層比想要的樓層低時（[currentFloor<desiredFloor] 監護條件成立），電梯進入上升（Moving Up）狀態；

（4）若是電梯的當前樓層與想要的樓層相同時（[else]監護條件成立），電梯門打開（Door Open）；

（5）在電梯上升或降低期間，每通過一個樓層就判斷[currentFloor=desiredFloor]監護條件是否成立，若不成立，繼續移動，若成立，就進入中止（Stop）狀態，15秒後，電梯門自動打開（Door Open），2分鐘後，電梯門自動關上（Door Close），若是有更多的電梯使用請求，進入運行（Run）狀態，反之，則進入空閒（Idle）狀態。

7. 繪製辦公系統中打印機（printer）的狀態圖

8. 繪製網上書店系統中訂單（order）的狀態圖

7.6 知識擴展

1. 繪製狀態圖時的錯誤提示

以繪製起點即便用【】爲例，若是在操做過程當中出現如圖7.22所示的錯誤提示對話框，則說明操做有誤。該錯誤提示的含義爲：在上下文中已經定義了一個初始狀態。出現這個錯誤是由於，起點在狀態圖中只容許有一個。

 

圖7.22 關於起點的錯誤提示

 

若是在同一個模型中繪製多個狀態圖，同時爲了保證圖形的完整性又想在每一個狀態圖中都顯示起點，該如何操做呢？具體步驟以下：首先，須要添加一個起點，該起點被添加後能夠在Rational Rose視圖區域樹型列表中顯示出來，如圖7.23所示；而後採用按住鼠標左鍵拖拽的方式，將起點從樹型列表拖拽到編輯區便可。

 

圖7.23 視圖區域樹型列表

再以繪製轉換即便用【】爲例，若是在操做過程當中出現如圖7.24所示的錯誤提示對話框，則一樣說明操做有誤。圖7.24中錯誤提示的含義爲：狀態轉換必須用於狀態之間的鏈接，不然非法。出現這個錯誤是由於，轉換的起始端和終止端不是狀態，或者是由於在繪製轉換時起始點和終止點位置不夠準確。

 

圖7.24 關於轉換的錯誤提示

2. 狀態圖工具欄

將狀態圖工具欄上的按鈕名稱及功能說明以下，詳見表7.1。

表7.1 狀態圖繪圖工具欄

按鈕	按鈕名稱	說明
	Selection Tool	選擇工具
	Text Box	文本框
	Note	註釋
	Anchor Note to Item	將圖中的元素與註釋鏈接
	Selection Tool	選擇工具
	Text Box	文本框
	Note	註釋
	Anchor Note to Item	將圖中的元素與註釋鏈接
	State	狀態
	Start State	起點
	End State	終點
	State Transition	狀態轉換
	Transition to Self	轉換到自身狀態

 

 

第8章  活動圖

活動圖（Activity Diagram）是描述系統動態行爲的經常使用工具之一，它強調從活動到活動的控制流。活動圖與程序設計中的流程圖很是類似，能夠顯示出一個過程的各個步驟。但與流程圖不一樣的是，活動圖在表示併發過程時顯得尤其有用，而流程圖則通常經常使用於表示串行過程。

活動圖的應用很是普遍，能夠用於對系統的工做流(Workflow)建模，即對系統的業務過程建模，好比進行用例分析等；也能夠用於對具體的操做建模，好比進行計算過程的細節描述等。本章在全書知識體系中的位置如圖8.1所示。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

通常來說，協做圖包括以下幾種構成元素：起點（Start）和終點（End），活動（Activity），轉換（Transition），泳道（Swimlane），分支（Branch），分叉與匯合（Fork and Join），對象流（Object Flow）。

8.1 相關知識點

8.1.1起點（Start）和終點（End）

起點是活動圖的初始狀態，也是活動圖的起始位置，表示一個工做流的開始。起點只能做爲轉換（Transition）的源，而不能做爲轉換（Transition）的目標。起點在活動圖中只容許有一個。活動圖中起點的表示方法與狀態圖中起點的表示方法相同。

終點是活動圖的最後狀態，也是活動圖的終止位置。與起點相反，終點只能做爲轉換（Transition）的目標，而不能做爲轉換（Transition）的源。終點在一個活動圖中能夠有一個或有多個，也能夠沒有。活動圖中終點的表示方法與狀態圖中終點的表示方法相同。

8.1.2活動（Activity）

活動表示一個工做流或一個過程當中任務的執行，包括動做狀態和活動狀態。

動做狀態是指執行原子的、不可中斷的動做，並在此動做完成後經過轉換轉向另外一個狀態。在UML中，動做狀態使用帶圓端的矩形表示，動做狀態的名稱寫在該矩形內部，如圖8.2所示。

動做狀態有以下特色：

（1）動做狀態是原子的，沒法分解；

（2）動做狀態是不可中斷的，一旦開始運行就一直運行到結束；

（3）動做狀態是瞬時的，所佔用的處理時間極短，有時甚至能夠忽略。

活動狀態用於表示非原子的運行，可被進一步分解。

在UML中，活動狀態的表示方法與動做狀態類似，只是活動狀態能夠添加入口動做、出口動做、動做狀態等，如圖8.3所示。

活動狀態有以下特色：

（1）活動狀態能夠分解成其餘子活動或動做狀態，因爲它是一組不可中斷的動做或操做的組合，因此能夠被中斷；

（2）活動狀態的內部活動能夠用另外一個活動圖來表示，如圖8.4所示就是將「Deliver Order」活動狀態用另外一個子活動圖來表示。其中的「Deliver Rush」和「Deliver Regular」能夠認爲是「Deliver Order」的子活動。

 

圖8.4 活動的擴展

8.1.3轉換（Transition）

活動圖中的轉換用於描述兩個活動之間的關係，表示一個活動執行完相應的操做後會自動轉換到另外一個活動。與狀態圖中不一樣的是，這種轉換通常不須要特定事件的觸發。

活動圖中轉換的表示方法與狀態圖中轉換的表示方法相同，見圖8.5中所示。

8.1.4泳道（Swimlane）

顧名思義，泳道本來是用來分隔游泳池的，以保證不一樣選手能夠在指定區域中進行比賽，而彼此互不干擾。活動圖中泳道的含義與此相似，每一個泳道表明一個責任區，它將活動分爲若干個組，併爲每一組指定負責人或所屬組織。藉助泳道，能夠在活動圖中清晰描述負責活動的對象，明確表示出哪些活動是由哪些對象展開的。在加入泳道的活動圖中，每一個活動只能屬於一個泳道。從語義上理解，泳道能夠被認爲是一個模型包。

在UML中，泳道被表示爲縱向矩形，屬於同一個泳道的活動均放在該矩形中。每一個泳道必須有惟一的名字（實際上就是對象名）以區別於其餘泳道，泳道的名字放在縱向矩形的頂部。泳道沒有順序號，不一樣泳道的活動能夠是順序執行的也能夠是併發執行的。如圖8.5所示的活動圖中有兩個泳道，分別是Student和System，其中「Complete Application」活動屬於Student泳道，「Check Course Availability」活動和「Check Applicaion Qualification」活動屬於Systems泳道。

 

圖8.5 轉換和泳道

8.1.5分支（Branch）

分支也稱斷定，是軟件系統流程中十分常見的一種結構。在活動圖中，分支描述了對象在不一樣的斷定結果下所執行的不一樣動做。一般，分支包括一個進入轉換和兩個（或多個）輸出轉換，即有一個入口和兩個（或多個）出口。每一個出口都應帶有監護條件，當且僅當該監護條件成立時，相應的出口路徑纔有效。在全部的出口中，其監護條件必須互斥，並且應該儘可能覆蓋全部的可能性，這樣才能夠保證有且僅有一條輸出轉換可以被觸發。

在UML中，分支被表示爲菱形框。如圖8.6所示，Release Work Order（分配工做指令）活動執行完之後遇到分支，該分支有兩個出口路徑：其中一條輸出轉換到Assign Tasks（執行任務）活動，監護條件是[materials ready]（材料準備齊全）；另外一條輸出轉換到Reschedule（從新規劃）活動，監護條件是[materials not ready]（材料沒有準備齊全）。

 

圖8.6 分支

8.1.6分叉與匯合（Fork and Join）

在活動圖建模的過程當中，可能會遇到這樣的狀況：存在兩個或多個併發執行的控制流。爲了描述這種併發執行，在活動圖中能夠使用分叉和匯合。分叉用於將路徑分解成多個併發執行的分支控制流，每一個分叉包括一個進入轉換和多個輸出轉換；匯合則用於將不一樣的分支聚集在一塊兒，當全部分支控制流都達到聚集點後，控制流才能繼續往下進行，每一個匯合包括多個進入轉換和一個輸出轉換。從概念上說，分叉的每個控制流都是併發的，但實際應用中，這些控制流能夠是真正的併發，也能夠是時序交替的。

在UML中，分叉和匯合都被表示爲比較粗的實線，該實線也稱爲同步條，分水平和垂直兩種，如圖8.7所示。

8.1.7對象流（Object Flow）

在活動圖中能夠出現對象做爲活動的輸入或輸出，並用對象流表達對象與活動之間的依賴關係。

同前幾章介紹的同樣，在活動圖中對象也用矩形符號表示，矩形內部是對象的名稱或對象所屬類的名稱，在名稱的下方還能夠設置對象的狀態。對象和活動之間的依賴關係即對象流使用帶箭頭的虛線表示，如圖8.8所示。

 

圖8.7 分支與匯合

 

 

圖8.8 對象流

8.2 知識點的能力目標

可以捕獲「圖書管理系統」中指定對象或指定用例的活動，而且使用Rational Rose工具繪製出相應的活動圖。

8.3 實現能力目標的具體要求

1. 創建圖書管理員對象的活動圖，並使用Rational Rose工具實現。

2. 創建讀者對象的活動圖，並使用Rational Rose工具實現。

3. 創建登陸系統用例的活動圖，並使用Rational Rose工具實現。

4. 創建借閱圖書用例的活動圖，並使用Rational Rose工具實現。

8.4 須要完成的實驗

1. 創建圖書管理員對象的活動圖，並使用Rational Rose工具實現。

（1）打開「Library」模型

（2）新建活動圖

在視圖區域樹型列表中，右鍵單擊【Logical View】結點，而後在彈出的快捷菜單中選擇【New】->【Activity Diagram】，如圖8.9所示。在此默認的活動圖名稱爲「New Diagram」，能夠輸入新的活動圖名稱爲「Librarian Activity」。雙擊該活動圖，在Rational Rose窗口內右側空白處出現相應的編輯區，在編輯區中可進行後續操做。

 

圖8.8 新建活動圖

（3）添加活動

在活動圖工具欄中選擇起點按鈕【】即「Start State」，而後在編輯區中單擊鼠標左鍵，即可以將初始活動添加到活動圖中。若是在操做過程當中出現如圖8.9所示的錯誤提示對話框，則說明操做有誤。該錯誤提示的含義爲：在上下文中已經定義了一個初始狀態。此時能夠採用按住鼠標左鍵拖拽的方式，將已經存在的起點從左側視圖區域樹型列表中拖拽到編輯區。

 

圖8.9 關於起點的錯誤提示

繼續在活動圖工具欄中選擇起點按鈕【】即「Activity」，而後在編輯區中單擊鼠標左鍵，即可以將活動添加到活動圖中。新添加的活動默認名稱爲「NewActivity」，可將其名稱根據具體狀況進行修改。簡便的修改方法是直接在「NewActivity」處鍵入活動的新名稱；稍複雜的修改方法是雙擊該活動打開「活動屬性」對話框，或者右鍵單擊該活動，在彈出的快捷菜單中選擇【Open Specification】也能夠打開「活動屬性」對話框，如圖8.10所示，在此將活動命名爲「Process Return」。若是還須要爲活動設置入口/出口動做、動做等內容，能夠雙擊「活動屬性」對話框中的【Actions】選項卡，而後在中間空白區域任意位置右鍵單擊，會彈出如圖8.11所示的快捷菜單。在彈出的快捷菜單中選擇【Insert】菜單項，能夠添加動做，新添加的動做默認類型爲「Entry」，默認名稱爲空。若是想修改動做的類型和名稱，能夠在圖8.11所示的快捷菜單中選擇【Specification】菜單項，打開如圖8.12所示的「動做屬性」對話框，在該對話框中進行詳細的設置。

 

圖8.10 「活動屬性」對話框

 

圖8.11 設置活動包含的動做

 

 

圖8.12 「動做屬性」對話框

依照如上方法，分別建立出圖書管理員對象活動：Query（查詢）、Process Return（處理還書）、Process Borrow（處理借閱）、Set（設置）、Get Fine（收取罰金）、Return Book（收回圖書）、Give Book（借出圖書）、Quit（退出）。

若是活動圖還有終止活動，則能夠在活動圖工具欄中選擇終點按鈕【】即「End State」，繼而在編輯區中單擊鼠標左鍵，即可以將終止活動添加到活動圖中。

（4）添加分叉與匯合

因爲Query（查詢）、Process Return（處理還書）、Process Borrow（處理借閱）、Set（設置）活動能夠認爲是併發執行的，因此還須要爲這些活動添加分叉與匯合，具體操做方法描述以下。

在活動圖工具欄中選擇水平同步按鈕【】即「Horizontal Synchronization」，而後在編輯區中單擊鼠標左鍵，即可以將分叉與匯合添加到活動圖中。若是想對分叉與匯合進行詳細設置，還能夠打開如圖8.13所示的「同步屬性」對話框，在此進行設置。

 

圖8.13 「同步屬性」對話框

（5）添加分支

圖書管理員在處理還書時，可能會出現這樣的狀況：若是讀者超期還書，那麼圖書管理員要收取必定的罰金；若是讀者定期還書，那麼圖書管理員直接收回圖書便可。也就是說，對於「Process Return」活動而言，可能出現分支。分支的一條路徑會轉換到「Get Fine」活動，條件是「out of date」；分支的另外一條路徑會轉換到「Return Book」活動，條件是「no」。描述這種分支結構的操做方法很簡單，只需在活動圖工具欄中選擇分支按鈕【】即「Decision」，而後在編輯區中單擊鼠標左鍵，即可以將分支添加到活動圖中。關於分支的條件描述，則要藉助添加轉換來完成。

（6）添加轉換

在活動之間、分叉與活動之間、活動與匯合之間、活動與分支之間均可以添加轉換，來完成相應的過渡。以處理還書出現的具體狀況爲例，將操做方法描述以下。

在活動圖工具欄中單擊轉換符號【】即「State Transition」，而後採用按住鼠標左鍵拖拽的方式，首先將「Process Return」活動和分支之間添加轉換。而後，將分支與「Get Fine」活動之間也添加轉換，雙擊該轉換，打開「狀態轉換屬性」對話框，在該對話框中單擊【Detail】選項卡，能夠打開如圖8.14所示的界面，在該界面中能夠設置監護條件等內容。按照一樣的方法，也能夠在分支與「Return Book」活動之間添加相應的轉換。

 

圖8.14 設置監護條件

通過以上各步驟，最終獲得圖書管理員對象活動圖，如圖8.15所示。

 

圖8.15 「Librarian Activity」活動圖

2. 創建讀者對象的活動圖，並使用Rational Rose工具實現。

實際操做步驟與創建圖書管理員對象活動圖類似，使用Rational Rose工具實現的 「Reader Activity」活動圖，如圖8.16所示。

 

圖8.16 「Reader Activity」活動圖

3. 創建登陸系統用例的活動圖，並使用Rational Rose工具實現。

實際操做步驟與創建圖書管理員對象活動圖類似，使用Rational Rose工具實現的 「Login Activity」活動圖，如圖8.17所示。

 

圖8.17 「Login Activity」活動圖

須要說明的是，該圖中添加了泳道。具體方法是：在活動圖工具欄中選擇泳道符號【】即「Swimlane」，此時鼠標會變成十字形狀，而後在編輯區相應位置單擊便可。新添加的泳道默認名稱爲「NewSwimlane」，能夠根據實際須要將名稱修改，如修改成「Reader」。右鍵單擊該泳道能夠打開如圖8.18所示的快捷菜單，在該快捷菜單中能夠選擇相應的菜單項以知足更多的操做需求，好比剪切、複製、刪除泳道等。

 

圖8.18 關於泳道的快捷菜單

4. 創建借閱圖書用例的活動圖，並使用Rational Rose工具實現。

實際操做步驟與創建登陸系統用例活動圖類似，使用Rational Rose工具實現的 「Borrow Book Activity」活動圖，如圖8.19所示。

 

 

圖8.19 「Borrow Book Activity」活動圖

以上各圖中沒有涉及對象流的內容，若是在活動圖中須要添加對象流，能夠首先在活動圖工具欄中選擇對象符號【】即「Object」，而後在編輯區中單擊鼠標即可。新添加的對象默認名稱爲空，能夠打開如圖8.20所示的「對象屬性」對話框進行名稱修改，在此還能夠爲對象設置所屬類以及狀態等。在圖8.20的【State】下拉類表中選擇「New」能夠打開如圖8.21所示的「對象狀態屬性」對話框，在該對話框中能夠定義對象的新狀態。

 

圖8.20 「對象屬性」對話框

 

圖8.21 「對象狀態屬性」對話框

添加完對象之後，能夠使用對象流將對象與指定的活動相鏈接，使該對象做爲活動的輸入或輸出。在活動圖工具欄中選擇對象流符號【】即「ObjectFlow」，而後採用按住鼠標左鍵拖拽的方式將對象與活動鏈接起來便可。

8.5 測試能力目標

1. 在UML中，用例能夠進一步使用（    ）來詳細描述。

A. 類圖（Class Diagram）            B. 狀態圖（State Diagram）

C. 活動圖（Activity Diagram）        D. 對象圖（Object Diagram）

2. 在活動圖中，（    ）能夠把活動劃分紅若干個組，並將劃分的組指定給相應的對象，進而可以明確地表示出哪些活動是哪些對象負責的。

A. 分叉與匯合（Fork and Join）         B. 泳道（Swimlane）

C. 活動（Activity）                    D. 對象流（ObjectFlow）

3. 如圖8.22所示爲「網上求職招聘系統」中「搜索工做」用例的活動圖，請根據圖示回答如下問題。

 

圖8.22 「搜索工做」活動圖

（1）在上圖中，有幾種不一樣的角色___________________________。

（2）清找出系統在該流程中相關的活動內容___________________________________。

4. 如圖8.23所示爲「汽車租賃系統」的總體活動圖，請根據該圖完成如下要求。

（1）結合系統活動圖描述汽車租賃過程的各個步驟。

（2）使用Rational Rose工具繪製該圖。

 

圖8.23 「汽車租賃系統」活動圖

4. 根據以下描述，繪製出「乘坐電梯」的活動圖。

（1）用戶（user）想乘電梯，按下電梯外的按鈕（press button）；

（2）若是電梯在當前樓層，則電梯門打開（open the door）；不然，電梯移到當前樓層（lift move to the current floor），而後電梯門打開；

（3）電梯門打開後，用戶進入（enter），電梯門關閉（close the door）；

（4）用戶按下想去的樓層按鈕（press desired floor button）；

（5）電梯移到那個樓層（go to the floor）；

（6）電梯門打開（the door open），用戶離開（leave）；

（7）電梯門關閉（close）。

5. 根據以下描述，繪製出「建立文檔」的活動圖。

（1）打開Word字處理軟件包；

（2）新建一個文件；

（3）命名該文檔併爲該文檔指定一個存放目錄；

（4）鍵入文檔的內容；

（5）若是文檔中須要圖形，則打開圖形軟件包，建立圖形，將圖粘貼到文檔中；

（6）若是文檔中須要電子表格，再打開電子表格軟件包，創建電子表格，將電子表格粘貼到文檔中；

（7）保存該文件；

（8）打印一份該文檔的硬拷貝；

（9）退出Office軟件包。

8.6 知識擴展

1. 活動圖工具欄

活動圖工具欄上的按鈕名稱及功能，詳見表8.1。

表8.1 活動圖工具欄按鈕

按鈕	按鈕名稱	說明
	Selection Tool	選擇工具
	Text Box	文本框
	Note	註釋
	Anchor Note to Item	將圖中的元素與註釋鏈接
	State	狀態
	Activity	活動
	Start State	起點
	End State	終點
	State Transition	狀態轉換
	Transition to Self	轉換到自身狀態
	Horizontal Synchronization	水平同步條
	Vertical Synchronization	垂直同步條
	Decision	分支
	Swimlane	泳道
	ObjuectFlow	對象流
	Object	對象

 

2. 活動圖與狀態圖的區別

（1）活動圖和狀態圖描述的側重點不一樣

活動圖能夠被認爲是狀態圖的一個變種，但與狀態圖不一樣的是，活動圖的主要目的是描述對象的活動以及執行完活動的結果。也就是說，活動圖強調從活動到活動的控制流，當一個活動中的動做被執行完時，直接轉換到下一個活動；而狀態圖強調的是對象的狀態及狀態之間的轉換。

（2）活動圖和狀態圖使用的場合不一樣

對於如下狀況，如分析用例、理解涉及多個用例的工做流、處理多線程應用，適合使用活動圖。

對於下面的狀況，如顯示一個對象在其生命週期內的行爲，適合使用狀態圖。

換言之，活動圖適合於描述多個對象和多個用例活動的總次序，狀態圖適合於描述跨越多個用例的單個對象的行爲。

另外須要重申的是，若是要顯示多個對象之間的交互狀況，能夠使用時序圖或協做圖。

3. 活動圖與流程圖的區別

活動圖描述的是對象活動的順序關係以及所遵循的規則，它着重表現的是系統的行爲，並不是是系統的處理過程；而流程圖則着重描述處理過程，它的主要控制結構是順序、選擇（分支）和循環，各個處理過程之間有嚴格的順序和時間關係。

活動圖可以表示併發活動的情形，而流程圖不能。

活動圖是面向對象的，流程圖是面向過程的。

4. 繪圖活動圖時的錯誤提示

以繪製活動即便用【】爲例，若是在操做過程當中出現如圖8.24和圖8.25所示的錯誤提示對話框，則說明操做有誤。圖8.24中錯誤提示的含義爲：「Login」名稱不合法，由於在上下文中已經存在了「Login」活動。圖8.25中錯誤提示的含義爲：將活動名稱修改成「Quit」時產生衝突，由於已經存在了「Quit」。之因此產生上述錯誤，是由於給活動命名和修更名稱時，出現了與已有名稱衝突的狀況，只需另換一個名稱即可解決。若是非要使用這個名稱，那麼能夠採用按住鼠標左鍵拖拽的方式，把在模型中已經存在（顯示在左側視圖區域樹型列表中）的活動拖拽到編輯區便可。

 

圖8.24 錯誤提示1

 

圖8.25 錯誤提示2

 

第9章  物理模型

在軟件系統的建模過程當中，能夠藉助用例模型描述系統指望達到的功能，能夠藉助靜態模型來描述系統中存在的事物及關係，能夠藉助動態模型描述事物的行爲活動及相互協做。在這些工做都完成之後，開發人員須要把以上的邏輯結構轉化爲物理結構（如設計執行文件、庫和文檔等），也就是創建物理模型。在進行物理建模時，須要用到組件圖（Component Diagram）和部署圖（Deployment Diagram）兩種工具，組件圖和部署圖也統稱爲實現圖。

Rational Rose工具除支持前述的用例建模、靜態建模、動態建模、物理建模以外，還支持持久層數據庫建模即創建數據模型。它容許將UML靜態模型用做邏輯模型，將數據模型用做物理模型，並幫助用戶保持兩者之間的同步。因此本章在實驗環節中相應地加入了數據建模的內容。本章在全書知識體系的位置如圖9.1所示。

 

 

 

 

 

 

 

 

 

 

9.1 組件圖（Component Diagram）

組件圖也稱構件圖，用於顯示一組軟件組件及它們之間的關係。也就是說，藉助組件圖能夠顯示組件的結構，能夠顯示編譯、連接或執行時組件之間的依賴關係。一般，組件圖包含三種構成元素：組件（Component）、接口（Interface）和關係（Relationship）。

9.1.1 相關知識點

1. 組件（Component）

組件也稱構件，是系統中可替換的物理部件，是定義了良好接口的物理實現模塊。換言之，組件是聽從一組接口且提供其實現的、物理的、可替換的部分。如程序源代碼、子系統、動態連接庫、ActiveX控件、JSP頁面等均可以被認爲是組件。這些組件通常都包含不少類且實現許多接口。對於組件能夠作一個形象的類比，那就是家庭娛樂系統，在該系統中人們能夠輕易更新DVD播放機或揚聲器，由於它們是系統中模塊化的、可替換的部分，而且能夠經過標準接口相互鏈接。

一般存在三種類型的組件：配置組件（Deployment Component）、工做產品組件（Work Product Component）、執行組件（Execution Component）。

（1）配置組件：也稱二進制組件，這些組件構成了一個可執行的系統，如DLL文件、EXE文件、COM+對象、CORBA對象、EJB、動態Web頁、數據庫表等。

（2）工做產品組件：也稱源組件，這些組件屬於開發過程產物，這些組件不直接參與可執行系統，而是開發中的工做產品，如源代碼文件（.java，.cpp），數據文件等。

（3）執行組件：這類組件是做爲一個正在執行的系統的結果而被建立的，例如由DLL實例化造成的.NET對象。

以人們玩電腦遊戲的整個過程爲例，能夠簡單理解上述三種類型的組件。當單擊遊戲圖標開始遊戲時，該圖標所對應的EXE文件就是配置組件；在遊戲結束時會打開存儲用戶信息的數據文件，用於保持當前的最好成績，這些都是工做產品組件；遊戲結束後，系統會把相應的成績更新到用戶數據文件，這時又能夠算是執行組件。

在UML中，組件被表示爲左側帶有兩個突出小矩形的大矩形，大矩形內部書寫組件名稱，如圖9.2所示。

 

圖9.2 組件

2. 接口（Interface）

接口用於描述類或組件提供的服務。在組件圖中，組件能夠經過其餘組件的接口使用其餘組件中定義的操做。經過使用接口，能夠避免系統中各個組件之間直接發生依賴關係，有利於組件的替換。與前面章節介紹過的同樣，在UML中，接口被表示爲一個圓；其擴展形式是被表示爲一個構造型類。

組件的接口能夠分爲兩類：導入接口（Import Interface）和導出接口（Export Interface）。導入接口供訪問操做的組件使用，導出接口由提供操做的組件提供，如圖9.3所示，NewInterface接口對於NewComponent1組件來講是導出接口，對於NewComponent2組件來講是導入接口。

 

 圖9.3 接口

3. 關係（Relationship）

在組件圖中，組件和接口之間能夠存在兩種關係：依賴（Dependency）關係和實現（Realization）關係。若是組件使用接口，那麼組件和接口之間存在依賴關係即組件依賴接口；若是組件實現接口，那麼組件和接口之間存在實現關係即組件實現接口。每一個組件可能使用一些接口，並實現另外一些接口。如上圖9.3所示代表NewComponent1組件實現NenInterface接口，NewComponent2組件依賴NenInterface接口。

另外，組件和組件之間能夠存在依賴關係。如圖9.4所示代表NewComponent1組件依賴NewComponent2組件。

 

圖9.4 組件之間的依賴關係

9.1.2 知識點的能力目標

可以抽象出「圖書管理系統」中的組件、接口及關係，而且使用Rational Rose工具繪製系統組件圖。可以結合「圖書管理系統」靜態模型，藉助Rational Rose工具進行持久層數據庫建模，即繪製系統數據模型圖。

9.1.3 實現能力目標的具體要求

1. 抽象出「圖書管理系統」中的組件、接口及關係。

2. 使用Rational Rose工具繪製「圖書管理系統」組件圖。

3. 結合第4章的靜態模型，藉助Rational Rose繪製「圖書管理系統」數據模型圖。

9.1.4 須要完成的實驗

1. 抽象出「圖書管理系統」中的組件、接口及關係。

經過分析，肯定「圖書管理系統」中的組件有：Main Program（主程序），SystemManage，Login，ReaderManage，BookManage，BorrowManage，FineManage，User.java，Login.java，Reader.java，Book.java，Reaserve.java，Borrow.java，Fine.java，Conn.java（用於數據庫鏈接的java源文件）。 以上各組件中有部分組件存在依賴關係，詳見表9.1所示。

表9.1 「圖書管理系統」中組件間的關係

序號	組件A	組件B	組件A和組件B之間的關係
1	Main Program	SystemManage	依賴關係
2	Main Program	Login	依賴關係
3	Main Program	ReaderManage	依賴關係
4	Main Program	BookManage	依賴關係
5	Main Program	BorrowManage	依賴關係
6	Main Program	FineManage	依賴關係
7	SystemManage	User.java	依賴關係
8	Login	Login.java	依賴關係
9	ReaderManage	Reader.java	依賴關係
10	BookManage	Book.java	依賴關係
11	BorrowManage	Borrow.java	依賴關係
12	BorrowManage	Reserve.java	依賴關係
13	FineManage	Fine.java	依賴關係
14	User.java	Conn.java	依賴關係
15	Login.java	Conn.java	依賴關係
16	Reader.java	Conn.java	依賴關係
17	Book.java	Conn.java	依賴關係
18	Borrow.java	Conn.java	依賴關係
19	Reserve.java	Conn.java	依賴關係
20	Fine.java	Conn.java	依賴關係

 

2. 使用Rational Rose工具繪製「圖書管理系統」組件圖。

（1）打開「Library」模型

（2）新建組件圖

在視圖區域樹型列表中，右鍵單擊【Component View】結點，而後在彈出的快捷菜單中選擇【New】->【Component Diagram】，如圖9.5所示。在此默認的組件圖名稱爲「New Diagram」，能夠輸入新的組件圖名稱爲「Library Component」。雙擊該組件圖，在Rational Rose窗口內右側空白處出現相應的編輯區，在編輯區中可進行後續操做。

 

圖9.5 新建組件圖

（3）添加組件

在組件圖工具欄中選擇按鈕【】即「Main Program」，而後在編輯區中單擊鼠標左鍵，即可以將主程序添加到組件圖中。相似地，在組件圖工具欄中選擇按鈕【】即「Component」，能夠將組件添加到組件圖中。新添加的組件默認名稱爲「NewComponent」，可在如圖9.6所示的「組件屬性」對話框中對其進行修改，同時還能夠進行其餘詳細設置。

 

圖9.6 「組件屬性」對話框

（4）添加關係

對於在模型中已經存在的接口（或類），能夠創建其與組件之間的關係，具體操做方法有兩種。

方法之一是：在「組件屬性」對話框中選擇【Realizes】選項卡，右鍵單擊要創建關係的接口（或類），在彈出的快捷菜單中選擇【Assign】，即可以創建組件和接口（或類）之間的關係，如圖9.7所示；若是要取消組件和接口（或類）之間的關係，則能夠右鍵單擊要取消關係的類或接口，在彈出的快捷菜單中選擇【Remove Assign】。

方法之二是：建立了相應的組件後，採用按住鼠標左鍵拖拽的方式，從左側視圖區域中將相應的接口（或類）拖放到組件上，創建組件和接口（或類）之間的關係，經過【Realizes】選項卡能夠查看到創建了關係的接口（或類）前面標記了一個紅色的勾，同時在左側視圖區域中的接口（或類）也顯示了與組件的關聯性，如圖9.8所示。

在具體的組件圖中，還能夠指定實現組件功能的文件，也就是創建組件和功能文件之間的關係，具體方法描述以下。在「組件屬性」對話框中選擇【Files】選項卡，而後在中間空白區域任意位置右鍵單擊，會彈出如圖9.9所示的快捷菜單，在彈出的快捷菜單中選擇【Insert File】菜單項，能夠添加實現該組件功能的文件。若指定的文件存在，如D:\ch9temp\Login.java，雙擊該文件名能夠查看文件的詳細內容，如圖9.10所示爲Login.java文件的源代碼。若指定的文件不存在，如D:\ch9temp\Conn.java，雙擊該文件名會彈出如圖9.11所示的對話框，該對話框提示的含義爲：Rose不能定位D:\ch9temp\Conn.java文件，您是否想要本身建立指定的文件？單擊【是】按鈕便可自行建立文件。

 

圖9.7 設置組件和接口（或類）的關係

 

圖9.8 組件和接口（或類）的關聯

 

圖9.9 設置組件和功能文件之間的關係

 

圖9.10 查看Login.java文件內容

 

圖9.11 建立文件提示框

如前所述，組件和組件之間能夠存在依賴關係，例如「圖書管理系統」中的Main Program組件依賴SystemManage組件。爲描述這種關係，能夠在編輯區工具欄中單擊依賴關係符號【】即「Dependency」，採用按住鼠標左鍵拖拽的方式，將Main Program組件和SystemManage組件鏈接起來。注意箭頭應該指向SystemManage組件。

綜合以上操做，完成「圖書管理系統」組件圖，如圖9.12所示。

 

圖9.12 圖書管理系統組件圖

 

3. 結合第4章靜態模型，藉助Rational Rose工具繪製「圖書管理系統」數據模型圖。

Rational Rose支持持久層的數據庫建模，便可以藉助該工具創建「數據模型」。在Rational Rose中，數據模型不只存在於邏輯視圖（Logical View）中，並且也存在於組件視圖（Component View）中。在邏輯視圖中，開發人員能夠建立一個計劃（Schema），而後在計劃中建立表（table）、域（domain）。在組件視圖中，開發人員能夠進行數據庫建模，數據庫在組件視圖中扮演<<Database>>組件角色。

接下來就以「圖書管理系統」爲例，說明創建數據模型的操做步驟。

（1）建立數據庫

正常啓動Rational Rose，在視圖區域樹型列表中，右鍵單擊【Component View】結點，而後在彈出的快捷菜單中選擇【Data Modeler】->【New】->【Database】，如圖9.13所示。

 

圖9.13 建立數據庫

新建的數據庫默認名稱爲「DB_0」，如圖9.14所示；右鍵單擊該數據庫，在彈出的快捷菜單中選擇【Open Specification...】菜單項，能夠打開「數據庫屬性」對話框，如圖9.15所示，在該對話框中，能夠修改數據庫名稱（如修改成「Library Database」）、設置數據庫查詢語言名稱、設置創建的數據庫類型（如ANSI SQL92，IBM DB2，SQL Server2000，Oracle等）。

 

圖9.14 新建數據庫的默認名稱

（2）建立表空間

表空間（Tablespaces）是存儲表的邏輯單元。不一樣類型的數據庫，表空間充當的角色有所不一樣。建立表空間的具體步驟以下：選定已經建立好的「Library Database」數據庫，右鍵單擊該數據庫，在彈出的快捷菜單中選擇【Data Modeler】->【New】->【Tablespaces】便可，如圖9.16所示。

 

圖9.15 「數據庫屬性」對話框

 

圖9.16 建立表空間

（3）建立計劃

計劃（Schema）是數據模型的容器，全部的表、觸發器、約束等數據模型元素都包含在這個容器中。在【Component View】組件視圖中建立數據庫後，【Logical View】邏輯視圖中會自動生成兩個包，即Global Data Types（全局數據模型包）和Schemas（計劃包）。建立計劃的具體步驟以下：

展開視圖區域樹型列表中的【Logical View】結點，選擇其下的Schemas（計劃包），右鍵單擊該包，在彈出的快捷菜單中選擇【Data Modeler】->【New】->【Schema】便可建立一個計劃，如圖9.17所示。新建立的計劃默認名稱爲「S_0」，若要對計劃進行詳細設置，能夠打開如圖9.18所示的「計劃屬性」對話框完成相應操做。

 

圖9.17 建立計劃

 

圖9.18 「計劃屬性」對話框

（4）建立數據模型圖

計劃建立完之後，就能夠在計劃內建立數據模型圖（Data Model Diagram）了，進而能夠在數據模型圖中添加表和其餘一些數據模型元素，這相似於靜態模型中的類圖。建立數據模型圖的具體步驟以下：

展開視圖區域樹型列表中的【Logical View】結點，選擇Schemas包下的「S_0」計劃，右鍵單擊該計劃，在彈出的快捷菜單中選擇【Data Modeler】->【New】->【Data Model Diagram】即可建立數據模型圖，如圖9.19所示。新建立的數據模型圖默認名稱爲「NewDiagram」，在此根據實際狀況將名稱修改成「Libraray DataModel」。雙擊「Libraray DataModel」數據模型圖，打開如圖9.20所示的編輯窗口。在數據模型圖編輯窗口中能夠添加表及表之間的關係等相關內容。

 

圖9.19 建立數據模型圖

 

 

圖9.20 數據模型圖編輯窗口

（5）添加表及表之間的關係

打開「Libraray DataModel」數據模型圖，在編輯區工具欄中單擊【】按鈕即「Table」，而後在編輯區任意位置單擊鼠標左鍵便可建立表。雙擊該表，能夠打開「表屬性」對話框，如圖9.21所示。

 

圖9.21 「表屬性」對話框

 

單擊「表屬性」對話框中的【Columns】選項卡，在中間空白處任意位置單擊鼠標右鍵，在彈出的快捷菜單中選擇【Insert】，能夠添加表的一個列，如圖9.22所示。對於列屬性的詳細設置能夠在如圖9.23所示的「列屬性」對話框中定義。同時，表的索引、約束、觸發器等均可以在「表屬性」對話框中進行設置。

添加完表之後，能夠進一步添加表之間的關係。在編輯區工具欄中單擊【】按鈕即「Non_identifying Relationship」，而後將鼠標停放在編輯區任意位置，鼠標會變成箭頭形狀，箭頭方向向上，此時採用按住鼠標左鍵拖拽的方式，將兩個表之間鏈接起來便可創建關係。雙擊該關係，打開如圖9.24所示的「關係屬性」對話框，在該對話框中能夠進行關係的詳細設置，好比設置對應關係等。

結合「圖書管理系統」的靜態模型，能夠獲得該系統的數據模型圖，截取其中部份內容見圖9.25所示。

 

圖9.22 添加表的列

 

圖9.23 「列屬性」對話框

 

圖9.24 「關係屬性」對話框

 

圖9.25 「圖書管理系統」部分數據模型圖

（6）數據模型和對象模型的轉換

如前所述，藉助Rational Rose能夠由一個數據模型自動生成一個對象模型，同時也能夠由一個對象模型自動生成數據模型，以保證數據的一致性。由數據模型生成對象模型的具體步驟以下：

首先，展開視圖區域樹型列表中的【Logical View】結點，選擇Schemas包下的「S_0」計劃，右鍵單擊該計劃，在彈出的快捷菜單中選擇【Data Modeler】->【Transform to Object Model】，如圖9.26所示。

 

圖9.26 生成對象模型

而後，能夠在打開的「數據模型生成對象模型」對話框中，詳細設置目標對象的包名及前綴，如圖9.27所示，單擊【OK】按鈕便可生成對象模型。

 

圖9.27 「數據模型生成對象模型」對話框

通過上述操做，自動生成的「圖書管理系統」部分對象模型如圖9.28所示。相似地，也能夠由對象模型生成數據模型。

 

圖9.28 「圖書管理系統」部分對象模型圖

（7）由數據模型導出數據庫

最後，能夠從數據模型中導出數據庫或DDL（數據庫定義語言）腳本，具體步驟以下：

展開視圖區域樹型列表中的【Logical View】結點，選擇Schemas包下的「S_0」計劃，右鍵單擊該計劃，在彈出的快捷菜單中選擇【Data Modeler】->【Forward Engineer...】，如圖9.29所示。

 

圖9.29 導出數據庫

選擇以上菜單後，會彈出如圖9.30所示的「導出數據庫嚮導」對話框。

 

圖9.30 「導出數據庫嚮導」對話框

單擊【Next】按鈕，進入如圖9.31所示的對話框，在該對話框中能夠選擇所須要的數據庫模型元素。

 

圖9.31 選擇數據庫模型元素

繼續單擊【Next】按鈕，進入如圖9.32所示的對話框，在該對話框中能夠單擊【Browse】按鈕，選擇保存DDL腳本的位置，此處將保存位置選定爲「F:\圖書管理系統數據模型」。

 

圖9.32 選擇保存和執行DDL

繼續單擊【Next】按鈕，進入如圖9.33所示的對話框，在該對話框中單擊【Finish】按鈕完成操做。

 

圖9.33 操做完成

 

通過上述步驟後，能夠獲得「圖書管理系統」的DDL腳本文件，如圖9.34所示。

 

圖9.34 「圖書管理系統」DDL腳本文件

 

導出的「LibraryDB.ddl」腳本文件具體內容以下：

CREATE TABLE Book (

       bookID SMALLINT NOT NULL,

       bookName VARCHAR ( 30 ) NOT NULL,

       pubID SMALLINT NOT NULL,

       author SMALLINT NOT NULL,

       price SMALLINT NOT NULL,

       quantity SMALLINT NOT NULL,

       CONSTRAINT PK_Book2 PRIMARY KEY (bookID)

       );

CREATE TABLE Fine (

       fineID SMALLINT NOT NULL,

       borrowID SMALLINT NOT NULL,

       CONSTRAINT TC_Fine16 UNIQUE (borrowID),

       CONSTRAINT PK_Fine4 PRIMARY KEY (fineID)

       );

CREATE TABLE Borrow (

       borrowID SMALLINT NOT NULL,

       borrowTypeName VARCHAR ( 3 ) NOT NULL,

       CONSTRAINT PK_Borrow1 PRIMARY KEY (borrowID)

       );

CREATE TABLE Reader (

       ID VARCHAR ( 10 ) NOT NULL,

       bookID SMALLINT NOT NULL,

       borrowID SMALLINT,

       CONSTRAINT PK_Reader0 PRIMARY KEY (ID)

       );

CREATE TABLE BookType (

       bookTypeID SMALLINT NOT NULL,

       bookTypeName VARCHAR ( 10 ) NOT NULL,

       bookID SMALLINT NOT NULL,

       CONSTRAINT PK_BookType3 PRIMARY KEY (bookTypeID)

       );

 

ALTER TABLE BookType ADD CONSTRAINT FK_BookType3 FOREIGN KEY (bookID) REFERENCES Book (bookID)  ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE Fine ADD CONSTRAINT FK_Fine7 FOREIGN KEY (borrowID) REFERENCES Borrow (borrowID)  ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE Reader ADD CONSTRAINT FK_Reader5 FOREIGN KEY (bookID) REFERENCES Book (bookID)  ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE Reader ADD CONSTRAINT FK_Reader6 FOREIGN KEY (borrowID) REFERENCES Borrow (borrowID)  ON DELETE NO ACTION ON UPDATE NO ACTION;

9.1.5 測試能力目標

1. ____________和___________是用於對面向對象系統進行物理方面建模的兩種圖形。

2. 下列不屬於組件類型的是（     ）。

A. 調用時的組件                     B. 編譯時的源組件

C. 連接時的二進制組件                D. 運行時的可執行組件

3. 如圖9.35所示爲「商品導覽系統」組件圖，根據圖示說明其中的組件、接口及關係。

 

圖9.35 「商品導覽系統」組件圖

9.1.6 知識擴展

1. 組件圖工具欄

組件圖工具欄上的按鈕名稱及功能，詳見表9.2。

表9.2 組件圖工具欄按鈕

按鈕	按鈕名稱	說明
	Component	組件
	Package	包
	Dependency	依賴關係
	Subprogram Specification	子程序規範
	Subprogram Body	子程序體
	Main Program	主程序
	Package Specification	包規範
	Package Body	包體
	Task Specification	任務規範
	Task Body	任務體
	Database	數據庫

 

2. 組件和類之間的區別

類是邏輯抽象，組件是物理抽象。

組件是對其餘邏輯元素，如類、協做(Collaboration)的物理實現。即組件是軟件系統的一個物理單元。

類能夠有屬性和操做；而組件一般只有操做，並且這些操做只能經過組件的接口才能使用。

3. 數據模型圖工具欄

數據模型圖工具欄上的按鈕名稱及功能，詳見表9.3。

表9.3 數據模型圖工具欄按鈕

按鈕	按鈕名稱	說明
	Selection Tool	選擇工具
	Text Box	文本框
	Note	註釋
	Anchor Note to Item	將圖中的元素與註釋鏈接
	Table	表
	Non_identifying Relationship	關係
	Identifying Relationship	單向關係
	View	視圖
	Dependancy	依賴關係

9.2 部署圖（Deployment Diagram）

部署圖是爲面向對象系統進行物理方面建模的兩個工具之一，也稱配置圖或實施圖，主要用於描述系統硬件的物理拓撲結構以及在此結構上執行的軟組件。也就是說，藉助部署圖能夠顯示出計算節點的拓撲結構、通訊路徑、節點上運行的軟組件等內容。

須要注意的是，一個系統模型只能有一個部署圖。一般狀況下，這個部署圖由體系結構設計師、網絡工程師、系統工程師來進行描述。

9.2.1 相關知識點

1. 節點（Node）

節點是存在於運行時並擁有某些計算資源的物理元素，通常至少擁有一些內存，並且一般具備處理能力。節點包括兩種類型：處理器（Processor）和設備（Device）。

處理器是具備處理能力的節點，即它能夠執行組件，如服務器（Server）、客戶機（Customer）等。

設備是無計算能力的外部設備，如調制解調器（Modem）、打印機（Printer）、掃描儀（Scanner）等。

在UML中，處理器和設備都被表示爲一個附有名稱的三維立方體，但表明處理器的三維立方體中有兩個側面帶有陰影，如圖9.36所示。

2. 鏈接（Connection）

鏈接表明一種交流機制，經常使用於對節點間的物理通訊路徑或軟件通訊協議進行建模。

在UML中，鏈接被表示爲一條實線，如圖9.37所示。

 

圖9.36 處理器和設備

 

 

圖9.37 鏈接

9.2.2 知識點的能力目標

可以抽象出「圖書管理系統」中節點及鏈接，而且使用Rational Rose工具繪製部署圖。

9.2.3 實現能力目標的具體要求

1. 抽象出「圖書管理系統」中的節點及鏈接。

2. 使用Rational Rose工具繪製部署圖。

9.2.4 須要完成的實驗

1. 抽象出「圖書管理系統」中的節點及鏈接。

經過分析，肯定「圖書管理系統」中的節點有：ApplicationServer（應用服務器）、Printer（打印機）、AdministratorPC（系統管理員PC機）、LibrarianPC（圖書管理員PC機）、LibraryPC（圖書館內的自助PC機）、ReaderPC（讀者PC機）、DatabaseSever（數據庫服務器）。

顯而易見，ApplicationServer（應用服務器）節點與其餘各節點之間都存在鏈接。

2. 使用Rational Rose工具繪製部署圖。

（1）打開「Library」模型

（2）打開部署圖

部署圖並不須要建立，由於模型裏面已經創建好了部署圖，如圖9.38所示，在視圖區域樹型列表中雙擊【Deployment View】打開部署圖便可，被打開的部署名稱爲「Deployment Diagram」。

（3）添加節點

在部署圖工具欄中選擇按鈕【】即「Processor」，而後在編輯區中單擊鼠標左鍵，即可將處理器添加到部署圖中。添加的處理器默認名稱爲「NewProcessor」，可在圖9.39所示的「處理器屬性」對話框中對其進行修改，同時還能夠進行其餘詳細設置。在此處將處理器名稱設置爲「ApplicationServer」，節點類型設置爲「Processor」。

 

圖9.38 打開部署圖

 

圖9.39 「處理器屬性」對話框

因爲處理器具備必定的處理能力，因此在繪圖時能夠爲其指明處理性能、處理進程、處理計劃等內容。具體操做方法是：在「處理器屬性」對話框中選擇【Detail】選項卡，而後在其「Characteristic」欄中書寫性能指標；繼而在其「Processes:」欄中的空白區域右鍵單擊，在彈出的快捷菜單中選擇【Insert】菜單項添加進程，如圖9.40所示。

默認狀況下，爲處理器添加的進程不顯示，若要顯示則需右鍵單擊該處理器，在彈出的快捷菜單中選擇【Show Processes】菜單項，如圖9.41所示。

相似地，在部署圖工具欄中選擇按鈕【】即「Device」，即可以將設備節點添加到部署圖中。

 

圖9.40 爲處理器添加處理內容

 

 

圖9.41 顯示處理器的處理內容

（4）添加鏈接

參照前面的分析，ApplicationServer節點和AdministratorPC節點之間存在鏈接，爲刻畫這種關係，須要在編輯區工具欄中單擊鏈接符號【】即「Connection」，採用按住鼠標左鍵拖拽的方式，將ApplicationServer節點和AdministratorPC節點鏈接起來。

若要爲鏈接指定更詳細的內容，如鏈接名稱和鏈接類型等，則能夠在如圖9.42所示的「鏈接屬性」對話框中進行設置。

 

圖9.42 「鏈接屬性」對話框

 

此處將鏈接類型設置爲「10/100/1000M Ethernet」（10/100/1000M自適應以太網），設置完的效果如圖9.43所示。

 

圖9.43 顯示鏈接類型

按照一樣的方法，能夠創建ApplicationServer節點與Printer（打印機）、ApplicationServer節點與LibrarianPC（圖書管理員PC機）、ApplicationServer節點與LibraryPC（圖書館內的自助PC機）、ApplicationServer節點與ReaderPC（讀者PC機）、ApplicationServer節點與DatabaseSever（數據庫服務器）各節點間的鏈接。

綜合以上操做，最終完成「圖書管理系統」部署圖，如圖9.44所示。

 

圖9.44 「圖書管理系統」部署圖

9.2.5 測試能力目標

1. 在UML部署圖中，具備計算能力的節點、可以執行軟組件的節點，一般被稱爲_____________。

2. 如下各項不屬於設備節點的是（     ）。

A. 掃描儀（Scanner）                      B. 計算機（Computer）

C. 打印機（Printer）                       D. 調制解調器（Modem）

3. 如圖9.45所示爲家用計算機系統部署圖，請根據圖示說明該系統中的處理器節點、設備節點、鏈接。

 

圖9.45 家用計算機系統部署圖

9.2.6 知識擴展

1. 處理計劃（Scheduling）中各選項的含義

如前所述，在爲處理器指定處理性能、處理進程的同時，還能夠指定處理計劃。現將處理計劃各選項（即在圖9.40所示的對話框中「Scheduling」欄各選項）的含義說明以下，詳見表9.4所示。

表9.4 處理計劃中選項的含義

選項	含義
Preemptive	高優先級的進程能夠搶佔低優先級的進程
Non Preemptive	進程沒有優先級，按順序執行進程
Cyclic	按時間片輪轉的方式執行進程
Executive	經過算法控制進程的執行
Manual	進程的執行由用戶手工控制

 

2. 部署圖工具欄

部署圖工具欄上的按鈕名稱及功能，詳見表9.5。

表9.5 部署圖工具欄按鈕

按鈕	按鈕名稱	說明
	Selection Tool	選擇工具
	Text Box	文本框
	Note	註釋
	Anchor Note to Item	將圖中的元素與註釋鏈接
	Processor	處理器
	Connection	鏈接
	Device	設備

 

3. 繪製部署圖時的錯誤提示

以繪製鏈接即便用【】爲例，若是在操做過程當中出現如圖9.46所示的錯誤提示對話框，則說明操做有誤。該錯誤提示的含義爲：非法的鏈接關係，鏈接只能用於節點之間。出現這個錯誤是由於鏈接的起始端和終止端不是節點，或者是由於在繪製鏈接時起始點和終止點位置不夠準確。

 

圖9.46 關於鏈接的錯誤提示

 

第10章  雙向工程

雙向工程包括正向工程和逆向工程。正向工程指的是從UML模型生成具體語言代碼的過程；而逆向工程則與此相反，指的是從具體語言代碼生成UML模型的過程。不管是從代碼到模型，仍是從模型到代碼，都是一項複雜的工做。Rational Rose建模工具將兩者有機地整合在了一塊兒，提供了模型框架與代碼框架進行雙向交換的機制。本章在全書知識體系中的位置如圖10.1所示。

 

 

 

 

 

 

 

 

 

 

10.1 正向工程

10.1.1 相關知識點

正向工程可以從UML模型（主要是靜態模型中的類圖）直接生成代碼框架，這爲程序員節省了大量用於編寫類、定義屬性和方法等瑣碎代碼的時間。正向工程的指導思想就在於框架，一個成熟的框架可讓開發人員思路更清晰。

以Java做爲模型語言爲例，正向工程就是從Rational Rose模型中的一個或多個類圖生成Java源代碼的過程。Rational Rose的正向工程是以組件爲中心的，也就是說Java源代碼的生成是基於組件的而不是基於類的，因此在建立一個類後須要將它分配給一個組件（具體內容參見第9章物理模型中組件圖的相關介紹）。若是模型的缺省語言是Java，Rational Rose會自動爲這個類建立一個組件。

對一個Java模型元素進行正向工程時，模型的特徵會映射爲對應的Java語言的特徵。好比Rational Rose類圖中的一個類會經過組件生成一個.java文件；Rational Rose中的包會生成Java中的一個包。

10.1.2 知識點的能力目標

利用Rational Rose工具的正向工程，以「圖書管理系統」爲例，將其類模型中的Admin類、Librarian類等，生成Java源代碼。

10.1.3 實現能力目標的具體要求

1. 設置模型的缺省語言爲Java。

2. 設置類路徑和代碼生成屬性。

3. 對「圖書管理系統」模型進行語法檢查。

4. 將「圖書管理系統」類圖生成Java源代碼。

5. 瀏覽代碼。

10.1.4 須要完成的實驗

1. 設置模型的缺省語言爲Java。

在主菜單欄中選擇【Tools】->【Options...】菜單，而後在彈出的窗口中選擇【Notation】選項卡，在該選項卡的「Default」欄下拉列表中選擇「Java」做爲模型的缺省語言，肯定便可，如圖10.2所示。

 

圖10.2 設置缺省語言

2. 設置類路徑和代碼生成屬性。

在主菜單欄中選擇【Tools】->【Java/J2EE】->【Project Specification】菜單，而後在彈出的「工程屬性」對話框中選擇【Classpath】選項卡能夠爲模型指定一個Java類路徑，如圖10.3所示。

 

圖10.3 設置Classpath

繼續在「工程屬性」對話框中選擇【Code Generation】選項卡，能夠對正向工程的代碼生成屬性進行相關設置，如圖10.4所示。其中各選項的含義詳見表10.1。

3. 對「圖書管理系統」模型進行語法檢查。

在生成代碼以前，能夠採用手動方式對模型組件進行語法檢查。在生成代碼時，Rational Rose會自動進行語法檢查。此步驟爲可選步驟，具體方法描述以下。

 

圖10.4 設置Code Generation

 

表10.1 代碼生成屬性中各選項的含義

選項	含義
IDE	指定與Rose相關聯的開發環境，默認爲Sun的JDK
Default Data Types	設置缺省數據類型
Prefixes	設置實例和類變量是否使用缺省前綴
Generate Rose ID	設置是否添加惟一的Rose ID標識符
Generate Default Return Line	設置是否在類聲明後面生成一個返回行
Stop on Error	設置是否遇到錯誤時中止生成代碼
Create Missing Directories	指定是否生成沒有定義的目錄
Automatic Synchronization Mode	自動保持代碼與模型同步
Show Progress Indicator	指定在遇到複雜同步時顯示進度欄
Source Code Control	指定對哪些文件進行源代碼控制
Input Checkin/Checkout comment	指定用戶是否須要對檢入/檢出代碼的活動進行說明
Select Source Root Path for Source Control	選擇代碼的存放路徑

 

（1）打開包含用於生成代碼的模型圖。

啓動Rational Rose後，首先打開「Library」模型，而後在左側視圖區域樹型列表中展開【Logical View】邏輯視圖，進一步打開該視圖下的「Library Class」類圖。在該類圖中存在兩個包，即Business Package和GUI Package，雙擊每一個包打開其中的類模型圖便可。

（2）檢查模型

在主菜單中選擇【Tools】->【Check Model】，從日誌窗口中觀察錯誤提示。若是有錯誤，信息將顯示在日誌窗口中，如圖10.5所示。

 

圖10.5 檢查模型

（3）檢查訪問問題

若是要發現訪問（如尋找不一樣包中兩個類之間是否存在關係）問題，能夠在主菜單中選擇【Report】->【Show Access Violations】來進行檢查，訪問窗口將提示是否存在問題，如圖10.6所示。

（4）檢查語法

在主菜單中選擇【Tools】->【Java/J2EE】->【Syntax Check】，能夠進行語法檢查，如圖10.7所示。

 

圖10.6 檢查訪問問題

 

 

圖10.7 檢查語法

對於模型語法檢查中存在的問題，能夠進行更正，以保證語法正確。

4. 將「圖書管理系統」類圖生成Java源代碼。

在打開的類圖中，選定要生成Java源代碼的類（如Admin類及其子類Librarian），而後在主菜單中選擇【Tools】->【Java/J2EE】->【Generate Code】，如圖10.8所示。

 

圖10.8 生成代碼

接下來在彈出的「指定類路徑入口」對話框中指定保存Java源代碼的路徑以及包名等內容，最後肯定便可。如圖10.9所示，此處指定保存源代碼路徑爲「D:\Rose&Java」，包名爲「BusinessPackage」。

 

圖10.9 指定類路徑入口

5. 瀏覽代碼。

代碼生成之後，能夠在保存路徑中找到對應的Java源文件，如圖10.10所示爲生成的Admin.java文件和Librarian.java文件。

 

圖10.10 定位Java源文件

與此同時，能夠瀏覽Admin.java文件的詳細代碼：

//Source file: D:\\Rose&Java\\BusinessPackage\\Admin.java

 

package BusinessPackage;

 

public class Admin

{  

   /**

    * @roseuid 4D523D380242

    */

   public Admin()

   {

   

   }

}

另外，還能夠經過瀏覽Librarian.java文件的詳細代碼，肯定Rational Rose是否在生成的代碼中保持了模型中原有的繼承關係，子類Librarian源代碼以下：

//Source file: D:\\Rose&Java\\BusinessPackage\\Librarian.java

package BusinessPackage;

public class Librarian extends Admin

{

   private int libID;

   private int libName;

   private int libPassword;

  

   /**

    * @roseuid 4D523D3801D4

    */

   public Librarian()

   {

   

   }

  

   /**

    * @roseuid 4D33EE8D037A

    */

   public void manageBook()

   {

   

   }

  

   /**

    * @roseuid 4D33EE95034B

    */

   public void manageReader()

   {

   

   }

  

   /**

    * @roseuid 4D33EE9D036B

    */

   public void manageFine()

   {

   

   }

  

   /**

    * @roseuid 4D33EEF101D4

    */

   public void manageBorrow()

   {

   

   }

  

   /**

    * @roseuid 4D33EF250119

    */

   public void query()

   {

   

   }

}

經過瀏覽以上代碼，能夠明確Admin類和Librarian類無缺地保持了模型中的繼承關係。遵循以上的操做步驟，可以將「圖書管理系統」類圖中的全部類生成相應的Java源代碼。開發人員即可以在此代碼框架的基礎上給出具體的方法實現，從而節省開發時間、提升開發效率。

10.1.5 測試能力目標

1. 從UML模型生成代碼框架的過程稱爲___________工程。

2. 在Rational Rose選擇【Tools】->【Java/J2EE】菜單實現正向工程時，選擇下列哪一項，能夠實現代碼生成功能。

A. Edit Code                                     B. Syntax Check

C. Project Specification                      D. Generate Code

3. 利用Rational Rose正向工程，將第4章4.2.5測試能力目標中十、十一、12題的類圖生成Java源代碼。

10.1.6 知識擴展

利用Rational Rose正向工程，將UML模型生成語言代碼時，並非全部語言都被支持。通常狀況下，在【Tools】的子菜單中能夠查看Rational Rose所支持的模型語言，若是在其子菜單中沒有列舉出所有的語言種類，還能夠選擇主菜單中【Add-Ins】->【Add-In Manage】，在彈出的「插件管理器」對話框中，設置顯示或隱藏各類語言的生成菜單，如圖10.11所示。

 

圖10.11 語言選擇界面

經過觀察發現，插件管理器中並未列舉出C#語言，若是要實施C#語言的正向工程，須要選擇其餘建模工具。

10.2 逆向工程

10.2.1 相關知識點

逆向工程可以從現有的語言代碼生成UML模型（如類圖、組件圖、數據模型圖等），這對達到設計模型和實現模型的同步大有益處；尤爲是在爲大型軟件系統作二次開發時，開發人員能夠利用逆向工程生成的模型，來更好地瞭解系統原來的組織結構，以方便團隊內部討論以及制定改進方案。

Rational Rose建模工具所支持的逆向工程擁有很是強大的功能，它不只支持多種編程語言（如C++、VB、VC、Java、CORBA等）；並且還支持多種數據庫（如SQL Server、Oracle、DB二、Sybase等）。

10.2.2 知識點的能力目標

利用Rational Rose工具的逆向工程，以「圖書管理系統」爲例，將已有的Java源代碼（即正向工程中獲得的源代碼）生成類模型。

10.2.3 實現能力目標的具體要求

1. 檢查類路徑。

2. 加載「圖書管理系統」源代碼。

3. 生成「圖書管理系統」類圖。

10.2.4 須要完成的實驗

1. 檢查類路徑。

進行逆向工程時，必需要有JDK（Java Development Kit）類庫的支持。Classpath類路徑能夠指向不一樣類型的類庫文件，如.zip，.jar等。有關Classpath的配置，能夠從「環境變量」中進行設置（具體參見Java相關教程）。

2. 加載「圖書管理系統」源代碼。

（1）選擇Java逆向工程。

啓動Rational Rose後，在主菜單中選擇【Tools】->【Java/J2EE】->【Reverse Engineer】，如圖10.12所示，繼而能夠打開「Java逆向工程」對話框，如圖10.13所示。

 

圖10.12 選擇Java逆向工程

 

圖10.13 「Java逆向工程」對話框

（2）加載指定的Java源代碼

在「Java逆向工程」對話框中，選擇Java源代碼所存放的路徑及待加載的文件。此處首先選擇「D:\Rose&Java\BusinessPackage」中的Admin.java，Administrator.java，Librarian.java三個文件，而後單擊【Reverse】按鈕，執行從代碼到模型的逆向轉換，如圖10.14所示。

 

圖10.14 生成的類

3. 生成「圖書管理系統」類圖。

採用按住鼠標左鍵拖拽的方式，將生成的類從左側視圖區域拖放到右側繪圖區域，即可以獲得相應的類圖，如圖10.15所示爲Admin類、Administrator類和Librarian.java類構成的類圖。遵循一樣的方法，可以獲得「圖書管理系統」的完整類圖。

10.2.5 測試能力目標

1. 在軟件的迭代開發週期中，一般採用___________達到設計模型與實現模型的同步。

2. 下列關於正向工程和逆向工程的描述，錯誤的是（     ）。

A. 正向工程是把模型轉換爲代碼的過程。

B. 逆向工程是把代碼轉換爲模型的過程。

C. 正向工程是把代碼轉換爲模型的過程。

D. 逆向工程是把模型轉換爲代碼的過程。

E. 正向工程和逆向工程均可以經過Rational Rose工具來實現。

3. 應用Java語言編寫一個簡單的學籍管理系統，並藉助Rational Rose工具實施逆向工程，將其中的Java源代碼轉換成UML模型。

 

圖10.15 生成的類圖

10.2.6 知識擴展

1. 逆向工程中類屬性的表現形式

利用Rational Rose實施逆向工程時，類的屬性可能表現爲如圖10.16左圖的形式，即在「String」類型前附加了「Logical View::java::lang::」前綴，該前綴指明瞭視圖名稱和包名稱，實際應用時可根據具體狀況選擇是否刪除該前綴。刪除後的表現形式更爲簡潔，如圖10.16右圖所示。

 

圖10.16 屬性的表現形式

2. 逆向工程中的錯誤提示

在進行逆向工程時，若是Rational Rose彈出如圖10.17所示的錯誤提示框，則說明操做有誤，該錯誤提示的含義爲：在實施逆向工程時發生錯誤，詳情見Rose日誌窗口。單擊【肯定】按鈕後，在日誌窗口中能夠查看錯誤詳情提示，如圖10.18所示。通常狀況下，該問題能夠經過檢查類路徑、包路徑及Java源文件的正確性來解決。

 

圖10.17 關於逆向工程的錯誤提示

 

圖10.18 日誌窗口中的錯誤詳情提示

 

 

第11章  綜合案例實訓

前面已經介紹了關於建模基礎和建模技術的相關內容，本章主要經過兩個綜合實例（「BBS論壇系統」和「基於Web的求職招聘系統」），加深讀者對UML基礎與Rose建模的理解和掌握。本章在全書知識體系中位置如圖11.1所示。

 

 

 

 

 

 

 

 

 

 

11.1 BBS論壇系統

11.1.1 相關知識點

 BBS（Bulletin Board System，電子公告牌系統）俗稱論壇系統，是互聯網上一種交互性極強、網友喜聞樂見的信息服務形式。根據相應的權限，論壇用戶能夠進行瀏覽信息、發佈信息、回覆信息、管理信息等操做，從而增強不一樣用戶間的文化交流和思想溝通。

通過調查分析，最終肯定「BBS論壇系統」的基本模塊有：用戶管理、版塊管理、帖子管理、友情連接管理、廣告管理。

其中各基本模塊的功能大致說明以下：

（1）用戶管理主要包括用戶註冊、用戶登陸、用戶資料修改等功能。

（2）版塊管理主要包括增長版塊、編輯版塊、刪除版塊等功能。

（3）帖子管理主要包括髮布帖子、回覆帖子、瀏覽帖子、轉移帖子、編輯帖子、刪除帖子、帖子加精、帖子置頂等功能。

（4）友情連接管理主要包括增長連接、修改連接、刪除連接等功能。

（5）廣告管理主要包括放置廣告、刪除廣告等功能。

另外，須要說明的是，以上各項功能中有些功能只須要普通用戶權限就可以完成，而有些功能則須要版主或管理員權限才能完成。

結合前述需求分析，能夠得出論壇系統的整體結構圖，如圖11.2所示。

 

圖11.2 「BBS論壇系統」整體結構圖

11.1.2 知識點的能力目標

根據11.1.1相關知識點介紹，藉助Rational Rose工具，按照「用例建模」、「靜態建模」、「動態建模」、「物理建模」、「雙向工程」的順序對「BBS論壇系統」進行UML建模。

11.1.3 實現能力目標的具體要求

1. 用例建模

（1）分析系統參與者。

（2）分析系統用例，並使用天然語言對主要用例進行文檔闡述。

（3）分析系統用例模型中的關係。

（4）藉助Rational Rose工具繪製出「BBS論壇系統」用例圖。

2. 靜態建模

（1）識別系統中的類，並根據實際狀況肯定類的屬性和操做。

（2）識別系統中各種之間的關係。

（3）藉助Rational Rose工具繪製出「BBS論壇系統」類圖。

3. 動態建模

（1）識別系統中既定場景的對象、消息等要素，並藉助Rational Rose工具繪製出相應的時序圖。

（2）識別系統中既定場景的對象、消息等要素，並藉助Rational Rose工具繪製出相應的協做圖，或將現有的時序圖轉換成協做圖。

（3）捕獲系統中指定對象的狀態，並藉助Rational Rose工具繪製出相應的狀態圖。

（4）捕獲系統中指定對象或指定用例的活動，並藉助Rational Rose工具繪製出相應的活動圖。

4. 物理建模

（1）分析系統中的組件及組件間的關係，並藉助Rational Rose工具繪製出「BBS論壇系統」組件圖。

（2）結合靜態模型，藉助Rational Rose工具繪製「BBS論壇系統」數據模型圖。

（3）分析系統中的節點及節點間的鏈接，並藉助Rational Rose工具繪製出「BBS論壇系統」部署圖。

5. 雙向工程

（1）利用Rational Rose工具的正向工程，將「BBS論壇系統」的類模型生成相應的Java源代碼。

（2）利用Rational Rose工具的逆向工程，將「BBS論壇系統」已有的Java源代碼（即正向工程中獲得的源代碼）生成類模型。

11.1.4 須要完成的實驗

1. 用例建模

（1）分析系統參與者。

遵循識別參與者的方法，能夠初步分析出「BBS論壇系統」中的主要參與者有：Anonymous User（匿名用戶）、Member（註冊用戶）、Editor（版主）、Administrator（管理員），如圖11.2所示。

 

圖11.2 「BBS論壇系統」的參與者

Anonymous User（匿名用戶）：經過使用系統進行帖子搜索、帖子瀏覽等。

Member（註冊用戶）：經過使用系統進行帖子搜索、帖子瀏覽、帖子發佈、帖子回覆、帖子編輯以及我的信息修改等。

Editor（版主）：除擁有普通用戶的職責外，還能夠經過使用系統進行版塊管理、公告發布等。

Administrator（管理員）：除擁有普通用戶的職責外，還能夠經過使用系統進行用戶管理、帖子管理、版塊管理、公告管理等。

（2）分析系統用例，並使用天然語言對主要用例進行文檔闡述。

針對分析出的系統主要參與者（匿名用戶、註冊用戶、版主、管理員）的功能需求，能夠初步肯定「BBS論壇系統」中主要用例包括：Search Article（搜索帖子）、Browse Article（瀏覽帖子）、Register（註冊）、Login（登陸）、Issue Article（發佈帖子）、Reply Article（回覆帖子）、Modify Article（修改帖子）、Modify Info（修改資料），Displace Article（轉移帖子）、Delete Article（刪除帖子）、Place Peak（帖子置頂）、Extract Article（帖子加精）、Add Edition（增長版塊）、Modify Edition（修改版塊）、Delete Edition（刪除版塊）、Add Link（增長連接）、Modify Link（修改連接）、Delete Link（刪除連接）、Add Advertise（增長廣告）、Delete Advertise（刪除廣告）。

綜合對「BBS論壇系統」中參與者和相關係統功能的分析，將該系統的所有用例說明以下，詳見表11.1所示。

表11.1 「BBS論壇系統」用例說明

用例名稱	功能描述	輸入內容	輸出內容
Search Article	根據須要搜索帖子	搜索條件	符合搜索條件的帖子
Browse Article	瀏覽任意版塊帖子	選擇任意話題帖子	該話題帖子及其回覆
Register	檢測註冊信息	用戶名等註冊信息	註冊結果（是否成功）
Login	合法用戶經過驗證進入系統	用戶名、密碼	登陸狀態（是否成功）
Issue Article	根據須要發佈帖子	用戶的言論	用戶的言論
Reply Article	回覆已存在的話題帖子	用戶的回覆	用戶的回覆
Modify Article	修改曾經發過的帖子	修改的內容	修改後的內容
Modify Info	根據當前情況修改我的信息	修改的信息	修改信息（是否成功）
Displace Article	根據實際狀況移動帖子位置	「移動」命令	移動結果（是否成功）
Delete Article	刪除違規帖子	「刪除」命令	刪除結果（是否成功）
Place Peak	將重要話題帖子放置於最上方	「置頂」命令	添加置頂圖標的帖子
Extract Article	將重要話題帖子列爲精華帖子	「加精」命令	添加加精圖標的帖子
Add Edition	添加版塊、設置版主	版塊的相關信息	版塊列表
Modify Edition	修改版塊信息	版塊的修改信息	修改結果（是否成功）
Delete Edition	刪除版塊	「刪除」命令	刪除結果（是否成功）
Add Link	接受友情連接申請，等待驗證	友情網站的信息	友情網站的連接
Modify Link	驗證並修改友情連接信息	友情連接信息	修改後的友情連接
Delete Link	清理不合格的友情連接	「刪除」命令	刪除結果（是否成功）
Add Advertise	選擇已有位置發佈廣告	廣告語、URL地址	前臺廣告
Delete Advertise	清理已發佈的廣告	「刪除」命令	原有的廣告消失

 

（3）分析系統用例模型中的關係。

顯然，四個參與者即Anonymous User（匿名用戶）、Member（註冊用戶）、Editor（版主）、Administrator（管理員）之間依次存在泛化關係。

另外，還能夠肯定Anonymous User（匿名用戶）、Member（註冊用戶）、Editor（版主）、Administrator（管理員）和與其相關的用例之間存在關聯關係。

Member（註冊用戶）相關的Issue Article（發佈帖子）用例、Reply Article（回覆帖子）用例、Modify Article（修改帖子）用例、Modify Info（修改資料）用例包含一個公共的用例，就是Login（登陸）用例，它們與Login（登陸）用例存在包含關係；一樣Login（登陸）用例與Register（註冊）用例之間也存在包含關係。

（4）藉助Rational Rose工具繪製出「BBS論壇系統」用例圖

根據以上分析，藉助Rational Rose工具繪製系統參與者之間的關係，如圖11.3所示；繪製Anonymous User（匿名用戶）與其關聯的用例之間的關係，如圖11.4所示；繪製Member（註冊用戶）與其關聯的用例之間的關係，如圖11.5所示；繪製Editor（版主）與其關聯的用例之間的關係，如圖11.6所示；繪製Administrator（管理員）與其關聯的用例之間的關係，如圖11.7所示；最後，獲得「BBS論壇系統」整體用例圖，如圖11.8所示。

 

圖11.3系統參與者之間的關係

 

 

圖11.4 匿名用戶與其關聯的用例

 

 

圖11.5 註冊用戶與其關聯的用例

 

 

圖11.6 版主與其關聯的用例

 

圖11.7 管理員與其關聯的用例

 

 

圖11.8 「BBS論壇系統」用例圖

2. 靜態建模

（1）識別系統中的類，並根據實際狀況肯定類的屬性和操做。

基於MVC三層架構的思想，將系統中的類按照實體類、邊界類、控制類來劃分。

其中實體類有：User（用戶）、Administrator（管理員）、Article（帖子）、Edition（版塊）、Link（連接）、Advertise（廣告）、UserData（用戶信息）、ArticleData（帖子信息）、EditionData（版塊信息）、LinkData（連接信息）、AdvertiseData（廣告信息）、Conn（數據庫鏈接），如圖11.9所示。須要說明的是，識別類時將Anonymous User（匿名用戶）、Member（註冊用戶）、Editor（版主）統一抽象爲User（用戶）類，並依據userGrade屬性值標識其具體身份。

 

圖11.9 系統中的實體類

其中邊界類有：index.jsp，user.jsp，article.jsp，edition.jsp，link.jsp，advertise.jsp，如圖11.10所示。

 

圖11.10 系統中的邊界類

 

其中控制類有：UserServelet，ArticleServlet，EditionServlet，LinkServlet，AdvertiseServlet，如圖11.11所示。

 

圖11.11 系統中的控制類

 

（2）識別系統中各種之間的關係。

分析得出「BBS論壇系統」中各個類之間關係如表11.2所示。

表11.2 系統中各種之間的關係

序號	類A	類B	類A和類B之間的關係
1	User	Administrator	泛化關係
2	user.jsp	UserServlet	依賴關係
3	UserServlet	UserData	依賴關係
4	UserServlet	User	依賴關係
5	UserData	User	依賴關係
6	UserData	Conn	依賴關係
7	article.jsp	ArticleServlet	依賴關係
8	ArticleServlet	ArticleData	依賴關係
9	ArticleServlet	Article	依賴關係
10	ArticleData	Article	依賴關係
11	ArticleData	Conn	依賴關係
12	Article	Edition	依賴關係
13	edition.jsp	EditionServlet	依賴關係
14	EditionServlet	EditionData	依賴關係
15	EditionServlet	Edition	依賴關係
16	EditionData	Edition	依賴關係
17	EditionData	Conn	依賴關係
18	link.jsp	LinkServelet	依賴關係
19	LinkServelet	LinkData	依賴關係
20	LinkServelet	Link	依賴關係
21	LinkData	Link	依賴關係
22	LinkData	Conn	依賴關係
23	advertise.jsp	AdvertiseServlet	依賴關係
24	AdvertiseServlet	AdvertiseData	依賴關係
25	AdvertiseServlet	Advertise	依賴關係
26	AdvertiseData	Advertise	依賴關係
27	AdvertiseData	Conn	依賴關係
28	index.jsp	user.jsp	關聯關係
29	index.jsp	article.jsp	關聯關係
30	index.jsp	edition.jsp	關聯關係
31	index.jsp	link.jsp	關聯關係
32	index.jsp	advertise.jsp	關聯關係

 

（3）藉助Rational Rose工具繪製出「BBS論壇系統」類圖。

因爲該系統整體類圖較複雜，因此將其劃分爲以下六個子圖：Mange User（用戶管理）子圖，如圖11.12所示；Manage Article（帖子管理）子圖，如圖11.13所示；Manage Edition（版塊管理）子圖，如圖11.14所示；Manage Link（友情連接管理）子圖，如圖11.15所示；Manage Advertise（廣告管理）子圖，如圖11.16所示；Manage Module（模塊管理）子圖，如圖11.17所示。

 

圖11.12  Manage User子圖

3. 動態建模

（1）識別系統中既定場景的對象、消息等要素，並藉助Rational Rose工具繪製出相應的時序圖。

此處以「Login」（用戶登陸）場景和「Add Edition」（增長版塊）爲例進行分析和建模。

 

圖11.13 Manage Article子圖

 

 

圖11.14 Manage Edition子圖

 

「Login」（用戶登陸）的具體處理流程爲：User（用戶）經過user.jsp輸入登陸信息，而後其登陸信息交由UserServlet處理，繼而UserServlet將登陸信息傳遞給User進行封裝，接着再由UserData查詢判斷用戶輸入的登陸信息是否與數據庫中的信息一致，最後由UserServlet根據判斷結果給出是否成功登陸的提示信息。詳見圖11.18所示。

 

圖11.15 Manage Link子圖

 

圖11.16 Manage Advertise子圖

 

 

圖11.17 Manage Module子圖

 

 

圖11.18 「Login」的處理流程

根據以上處理流程，得出「Login」（用戶登陸）場景時序圖，如圖11.19所示。

 

圖11.19 「Login」時序圖

 

「Add Edition」（增長版塊）的具體處理流程爲：Administrator（管理員）經過edition.jsp輸入版塊相關信息，而後交由EditionServlet處理，繼而EditionServlet將版塊信息傳遞給Edition進行封裝，接着EditionServlet調用EditionData中相應的方法對數據庫進行操做。詳見圖11.20所示。

 

圖11.20 「Add Edition」的處理流程

 

根據以上處理流程，得出「Add Edition」（增長版塊）場景時序圖，如圖11.21所示。

 

圖11.21 「Add Edition」時序圖

 

（2）識別系統中既定場景的對象、消息等要素，並藉助Rational Rose工具繪製出相應的協做圖，或將現有的時序圖轉換成協做圖。

此處仍以「Login」（用戶登陸）場景和「Add Edition」（增長版塊）爲例，利用Rational Rose工具將其時序圖直接轉化成協做圖。

最終生成的「Login」（用戶登陸）場景協做圖，如圖11.22所示，生成的「Add Edition」（增長版塊）場景協做圖，如圖11.23所示，

（3）捕獲系統中指定對象的狀態，並藉助Rational Rose工具繪製出相應的狀態圖。

此處以Member（註冊用戶）對象、Article（帖子）對象、Edition（版塊）對象爲例，繪製其狀態圖。

最終獲得註冊用戶的狀態圖如圖11.24所示，帖子的狀態圖如圖11.25所示，版塊的狀態圖如圖11.26所示。

 

圖11.22 「Login」協做圖

 

圖11.23 「Add Edition」協做圖

 

圖11.24 註冊用戶的狀態圖

 

圖11.25 帖子的狀態圖

 

圖11.26 版塊的狀態圖

（4）捕獲系統中指定對象或指定用例的活動，並藉助Rational Rose工具繪製出相應的活動圖。

以捕獲「Search Article」（搜索帖子）用例的活動爲例，繪製「Search Article」活動圖如圖11.27所示。

 

圖11.27 「Search Article」活動圖

再以捕獲「Delete Edition」（刪除版塊）用例的活動爲例，繪製「Delete Edition」活動圖如圖11.28所示。

 

圖11.28 「Delete Edition」活動圖

 

4. 物理建模

（1）分析系統中的組件及組件間的關係，並藉助Rational Rose工具繪製出「BBS論壇系統」組件圖。

經過分析，肯定「BBS論壇系統」中的組件有：BBS System（BBS論壇系統Web應用程序）、Manager User（用戶管理）、Manage Article（帖子管理）、Manage Edition（版塊管理）、Manage Link（友情連接管理）、Manage Advertise（廣告管理）。

以上各組件中有部分組件存在依賴關係，詳見表11.3所示。

表11.3 「BBS論壇系統」中組件間的關係

序號	組件A	組件B	組件A和組件B之間的關係
1	BBS System	Manager User	依賴關係
2	BBS System	Manage Article	依賴關係
3	BBS System	Manage Edition	依賴關係
4	BBS System	Manage Link	依賴關係
5	BBS System	Manage Advertise	依賴關係

 

最終完成「BBS論壇系統」組件圖，如圖11.29所示。

 

圖11.29 「BBS論壇系統」組件圖

（2）結合靜態模型，藉助Rational Rose工具繪製「BBS論壇系統」數據模型圖。

藉助Rational Rose工具繪製「BBS論壇系統」數據模型圖，如圖11.30所示。

 

圖11.30 「BBS論壇系統」數據模型圖

另外，還能夠從以上數據模型中導出數據庫或DDL（數據庫定義語言）腳本，導出的「BBS_DB.ddl」腳本文件具體內容以下：

CREATE TABLE Link (

       linkID SMALLINT NOT NULL,

       linkName VARCHAR ( 20 ) NOT NULL,

       linkURL VARCHAR ( 80 ) NOT NULL,

       CONSTRAINT PK_Link5 PRIMARY KEY (linkID)

       );

CREATE TABLE Administrator (

       adminID SMALLINT NOT NULL,

       adminName VARCHAR ( 20 ) NOT NULL,

       adminPassword VARCHAR ( 20 ) NOT NULL,

       CONSTRAINT PK_Administrator1 PRIMARY KEY (adminID)

       );

CREATE TABLE Article (

       articleID SMALLINT NOT NULL,

       articleName VARCHAR ( 16 ) NOT NULL,

       articleContent VARCHAR ( 500 ) NOT NULL,

       editionID SMALLINT NOT NULL,

       CONSTRAINT PK_Article3 PRIMARY KEY (articleID)

       );

CREATE TABLE Edition (

       editionID SMALLINT NOT NULL,

       editionInfo VARCHAR ( 500 ) NOT NULL,

       editionName VARCHAR ( 116 ) NOT NULL,

       CONSTRAINT PK_Edition4 PRIMARY KEY (editionID)

       );

CREATE TABLE Advertise (

       advertiseID SMALLINT NOT NULL,

       advertiseName VARCHAR ( 20 ) NOT NULL,

       advertiseWord VARCHAR ( 100 ) NOT NULL,

       CONSTRAINT PK_Advertise6 PRIMARY KEY (advertiseID)

       );

CREATE TABLE User (

       userID VARCHAR ( 20 ) NOT NULL,

       userName VARCHAR ( 20 ) NOT NULL,

       userPassword VARCHAR ( 20 ) NOT NULL,

       userGrade VARCHAR ( 1 ) NOT NULL,

       CONSTRAINT PK_User0 PRIMARY KEY (userID)

       );

 

ALTER TABLE Article ADD CONSTRAINT FK_Article6 FOREIGN KEY (editionID) REFERENCES Edition (editionID)  ON DELETE NO ACTION ON UPDATE NO ACTION;

 

（3）分析系統中的節點及節點間的鏈接，並藉助Rational Rose工具繪製出「BBS論壇系統」部署圖。

經過分析，肯定「BBS論壇系統」中的節點有：ApplicationServer（應用服務器）、DatabaseSever（數據庫服務器）及若干個Customer（客戶機）。

顯而易見，ApplicationServer（應用服務器）節點與其餘各節點之間都存在鏈接。

藉助Rational Rose工具繪製「BBS論壇系統」部署圖，如圖11.31所示。

 

圖11.31 「BBS論壇系統」部署圖

5. 雙向工程

（1）利用Rational Rose工具的正向工程，將「BBS論壇系統」的類模型生成相應的Java源代碼。

藉助Rational Rose的正向工程將類模型生成代碼之後，能夠在保存路徑中找到對應的Java源文件，如圖11.32所示。

瀏覽Administrator.java文件的詳細代碼：

//Source file: D:\\Rose&Java\\Administrator.java

public class Administrator extends User

{

   private int adminID;

   private int adminName;

   private int adminPassword;

  

   /**

    * @roseuid 4D622F1902EE

    */

   public Administrator()

   {

   

   }

 

圖11.32 生成Java源文件

 

/**

    * @roseuid 4D5C9989036B   

*/

   public void setAdminID()

   {

   

   }

  

   /**

    * @roseuid 4D5C98D6032C

    */

   public void getAdminID()

   {

   

   }

  

   /**

    * @roseuid 4D5C99B701B5

    */

   public void setAdminName()

   {

   

   }

  

   /**

    * @roseuid 4D5C98DF0203

    */

   public void getAdminName()

   {

   

   }

  

   /**

    * @roseuid 4D5C99BD02FD

    */

   public void setAdminPass()

   {

   

   }

  

   /**

    * @roseuid 4D5C99C90290

    */

   public void getAdminPass()

   {

   

   }

}

（2）利用Rational Rose工具的逆向工程，將「BBS論壇系統」已有的Java源代碼（即正向工程中獲得的源代碼）生成類模型。

讀者可參照第10章雙向工程的介紹自行練習，將「BBS論壇系統」已有的Java源代碼生成類模型。

11.1.5 測試能力目標

選擇一個熟悉的軟件系統（如「學生管理系統」、「教務管理系統」等），藉助Rational　Rose工具，按照「用例建模」、「靜態建模」、「動態建模」、「物理建模」、「雙向工程」的順序對其進行UML建模。

11.1.6 知識擴展

1. 傳統的瀑布開發模型

最先的軟件開發模型是1970年提出的瀑布模型，然後隨着軟件工程學科的發展和軟件開發實踐的推動，又相繼出現了原型模型、演化模型、增量模型、噴泉模型等。瀑布模型將軟件生命週期劃分爲八個階段：問題定義、可行性研究、需求分析、整體設計、詳細設計、編碼實現、測試運行、使用維護，如圖11.33所示。其中各個階段的工做按順序開展，上一個階段的工做成果是下一個階段的工做前提。

不難看出，瀑布模型規定了一個標準流程，整個軟件開發過程嚴格按照這個流程來實施，有效避免了盲目、混亂局面的出現。可是也必須看到，瀑布模型仍有其與生俱來的侷限性。由於它要求在軟件開發的初始階段就捕獲用戶的所有需求，這顯然是十分困難的，甚至是不切實際的。另外，在需求肯定之後，若是用戶臨時提出變動需求，那麼瀑布模型因爲其不可回溯性也將不能靈活應對。

 

圖11.33 瀑布模型

2. RUP的迭代開發模型

RUP（Rational Unified Process，統一軟件過程）是由Rational公司推出的軟件開發模型框架，它吸取了多種開發模型的優勢，具備良好的操做性和實用性。

RUP能夠用二維座標來描述，如圖11.34所示。其中橫軸以時間來組織，是過程展開的生命週期特徵，體現開發過程的動態結構；用來描述它的術語主要包括週期、階段、迭代和里程碑。縱軸之內容來組織，爲天然的邏輯活動，體現開發過程的靜態結構；用來描述它的術語主要包括活動、產物、工做者和工做流。

 

圖11.34 RUP開發模型

從上圖能夠看出，RUP將軟件生命週期劃分爲四個階段：Inception（初始）階段、Elaboration（細化）階段、Construction（構造）階段、Transition（交付）階段。

（1）Inception（初始）階段

初始階段是項目的基礎階段，該階段的主要參與人員是項目經理和系統設計師。初始階段的目標是對系統進行可行性分析、建立基本需求、識別軟件系統的關鍵任務。

（2）Elaboration（細化）階段

細化階段的目標是建立可執行的構件基準、精化風險評估、定義質量屬性、捕獲大部分的系統功能需求用例，爲構造階段建立詳細的計劃。細化階段是開發過程當中最重要的階段。細化的焦點是需求、分析和設計工做流。

（3）Construction（構造）階段

構造階段的目標是完成全部的需求、分析和設計。細化階段的成果將演化爲最終系統，構造的主要問題是維護系統框架的完整性。構造的焦點是實現工做流。

（4）Transition（交付）階段

交付階段的目標是將完整的系統部署到用戶所處的環境。交付的內容包括修復系統缺陷、爲用戶環境準備新軟件、建立用戶使用手冊和系統文檔、提供用戶諮詢。

RUP的每一個階段能夠進一步分解爲迭代。一個迭代是一個完整的開發循環，產生一個可執行的產品版本，即最終產品的子集，它增量式地發展（從一個迭代過程到另外一個迭代過程），直到成爲最終的軟件系統。

與傳統的瀑布模型相比，RUP的迭代模型下降了開發風險，由於開發人員重複某個迭代承擔的只是本次迭代的開發風險。另外，與傳統的瀑布模型相比，RUP的迭代模型加快了開發進程，由於開發人員清楚問題的焦點所在，這樣使得工做更有效率。

11.2 基於Web的求職招聘系統

11.2.1 相關知識點

極速發展的時代，企業對於人才的需求日新月異。「基於Web的求職招聘系統」正是在這樣的背景下應運而生的，它爲求職者和招聘者提供了一個虛擬化、智能化的人才市場，其主要目的是爲了拉近求職者和應聘者之間的距離，以便於求職者可以找到合適的工做，招聘者可以找到合適的人才。當用戶進入該系統時，能夠根據各自的需求和權限註冊爲求職者、招聘者以及管理員，而後行使系統爲其提供的相應功能。

通過調查分析，最終肯定「基於Web的求職招聘系統」的基本模塊有：求職模塊、招聘模塊、管理模塊。其中各基本模塊的功能大致說明以下：

（1）求職模塊主要包括更新求職者資料、搜索招聘信息、發佈求職意向、投遞簡歷、查看求職郵箱等功能。

（2）招聘模塊主要包括更新招聘者資料、搜索應聘信息、發佈招聘信息、查看招聘郵箱、瀏覽應聘簡歷、回覆求職者等功能。

（3）管理模塊主要包括更新管理員資料、管理求職者、管理招聘者、管理新聞等功能。

結合前述需求分析，能夠得出論壇系統的整體結構圖，如圖11.35所示。

 

圖11.35 「基於Web的求職招聘系統」整體結構圖

11.2.2 知識點的能力目標

根據11.2.1相關知識點的介紹，藉助Rational　Rose工具，按照「用例建模」、「靜態建模」、「動態建模」、「物理建模」、「雙向工程」的順序，對「基於Web的求職招聘系統」進行UML建模。

11.2.3 實現能力目標的具體要求

1. 用例建模

（1）分析系統參與者。

（2）分析系統用例。

（3）分析系統用例模型中的關係。

（4）藉助Rational Rose工具繪製出「基於Web的求職招聘系統」用例圖。

2. 靜態建模

（1）識別系統中的類，並根據實際狀況肯定類的屬性和操做。

（2）識別系統中各種之間的關係。

（3）藉助Rational Rose工具繪製出「基於Web的求職招聘系統」類圖。

3. 動態建模

（1）識別系統中既定場景的對象、消息等要素，並藉助Rational Rose工具繪製出相應的時序圖。

（2）識別系統中既定場景的對象、消息等要素，並藉助Rational Rose工具繪製出相應的協做圖，或將現有的時序圖轉換成協做圖。

（3）捕獲系統中指定對象的狀態，並藉助Rational Rose工具繪製出相應的狀態圖。

（4）捕獲系統中指定對象或指定用例的活動，並藉助Rational Rose工具繪製出相應的活動圖。

4. 物理建模

（1）分析系統中的組件及組件間的關係，並藉助Rational Rose工具繪製出「基於Web的求職招聘系統」組件圖。

（2）結合靜態模型，藉助Rational Rose工具繪製「基於Web的求職招聘系統」數據模型圖。

（3）分析系統中的節點及節點間的鏈接，並藉助Rational Rose工具繪製出「基於Web的求職招聘系統」部署圖。

5. 雙向工程

（1）利用Rational Rose工具的正向工程，將「基於Web的求職招聘系統」的類模型生成相應的Java源代碼。

（2）利用Rational Rose工具的逆向工程，將「基於Web的求職招聘系統」已有的Java源代碼（即正向工程中獲得的源代碼）生成類模型。

11.2.4 須要完成的實驗

1. 用例建模

（1）分析系統參與者。

遵循識別參與者的方法，能夠初步分析出「基於Web的求職招聘系統」中的主要參與者有：User（用戶）、Seeker（求職者）、Inviter（招聘者）、Administrator（管理員），如圖11.36所示。其中User（用戶）是爲了實際須要，抽象出來的參與者。

 

圖11.36 「基於Web的求職招聘系統」的參與者

（2）分析系統用例。

針對分析出的系統主要參與者（用戶、求職者、應聘者、管理員），能夠初步肯定「圖書管理系統」中主要用例包括：Register（註冊）、Login（登陸）、Modify Info（更新資料）、Seek Job（搜索招聘信息）、Issue Application（發佈求職意向）、Post Resume（投遞簡歷）、Browse SeekMail（查看求職郵箱），Search SeekInfo（搜索應聘信息）、Issue Invitation（發佈招聘信息）、Browse Resume（瀏覽應聘簡歷）、Browse InviteMail（查看招聘郵箱）、Reply Seeker（回覆求職者）、Manage Seeker（管理求職者）、Manage Inviter（管理招聘者）、Manage News（管理新聞）。

下面給出Modify Info（更新資料）用例的闡述文檔，其他用例闡述文檔讀者能夠經過自行練習來完成。

---------------------------------------------------------------------------------------------------------------------

用例編號：003

用例名稱：Modify Info

涉及的參與者：User（用戶）

用例概述：用戶針對當前的實際狀況，修改了我的資料

前置條件：用戶已經成功登陸到求職招聘系統

後置條件：用戶資料更新成功，新的我的資料生效

基本事件流：

1. 用戶登陸到求職招聘系統

2. 用戶發出更新資料請求

3. 系統接受請求，並提示用戶輸入新的資料

4. 用戶輸入新的我的資料並確認

5. 系統顯示更新後的用戶資料

備選流：

1a. 資料格式輸入有誤

1a1.系統提示用戶輸入信息有誤，提供正確的格式範例

補充說明：

無

---------------------------------------------------------------------------------------------------------------------

（3）分析系統用例模型中的關係。

顯然，User（用戶）、Seeker（求職者）、Inviter（招聘者）、Administrator（管理員）和與其相關的用例之間存在關聯關係。User（用戶）相關的用例Login（登陸）與Register（註冊）之間、Modify Info（更新資料）與Login（登陸）之間存在包含關係。

另外，還能夠肯定參與者User（用戶）和Seeker（求職者）、Inviter（招聘者）、Administrator（管理員）之間依次存在泛化關係。

（4）藉助Rational Rose工具繪製出「基於Web的求職招聘系統」用例圖。

根據以上分析，藉助Rational Rose工具繪製User（用戶）與其關聯的用例之間的關係，如圖11.37所示；繪製Seeker（求職者）與其關聯的用例之間的關係，如圖11.38所示；繪製Inviter（招聘者）與其關聯的用例之間的關係，如圖11.39所示；繪製Administrator（管理員）與其關聯的用例之間的關係，如圖11.40所示；繪製系統參與者之間的關係，如圖11.41所示；最後，獲得「基於Web的求職招聘系統」整體用例圖，如圖11.42所示。

 

 

圖11.37 用戶與其關聯的用例

 

 

圖11.38 求職者與其關聯的用例

 

 

圖11.39 招聘者與其關聯的用例

 

圖11.40 管理員與其關聯的用例

 

 

圖11.41 系統參與者之間的關係

 

圖11.42 「基於Web的求職招聘系統」用例圖

2. 靜態建模

（1）識別系統中的類，並根據實際狀況肯定類的屬性和操做。

此處只對系統中部分實體類進行分析，識別出的實體類有：User（用戶）、Seeker（求職者）、Inviter（招聘者）、Administrator（管理員）、Application（求職信息）、Invitation（招聘信息）、Resume（簡歷）、News（新聞），如圖11.43所示。

 

圖11.43 系統中的實體類

 

（2）識別系統中各種之間的關係

分析得出「基於Web的求職招聘系統」中各實體類之間關係如表11.4所示。

表11.4 系統中各實體類之間的關係

序號	類A	類B	類A和類B之間的關係
1	User	Seeker	泛化關係
2	User	Inviter	泛化關係
3	User	Administrator	泛化關係
4	Administrator	News	關聯關係
5	Seeker	Resume	關聯關係
6	Seeker	Invitation	關聯關係
7	Seeker	Application	關聯關係
8	Seeker	News	關聯關係
9	Inviter	Resume	關聯關係
10	Inviter	Invitation	關聯關係
11	Inviter	Application	關聯關係
12	Inviter	News	關聯關係

 

（3）藉助Rational Rose工具繪製出「基於Web的求職招聘系統」類圖

因爲該系統整體類圖較複雜，因此將其劃分爲以下三個子圖：Manage（管理模塊）子圖，如圖11.44所示；Seek（求職模塊）子圖，如圖11.45所示；Invite（招聘模塊）子圖，如圖11.46所示；。

 

圖11.44 Manage子圖

 

圖11.45 Seek子圖

 

 

圖11.46 Invite子圖

 

3. 動態建模

（1）識別系統中既定場景的對象、消息等要素，並藉助Rational Rose工具繪製出相應的時序圖。

此處以「Register」場景爲例進行分析和建模，獲得的時序圖如圖11.47所示。

 

圖11.47 「Register」時序圖

（2）識別系統中既定場景的對象、消息等要素，並藉助Rational Rose工具繪製出相應的協做圖，或將現有的時序圖轉換成協做圖。

此處仍以「Register」場景爲例，利用Rational Rose工具將其時序圖直接轉化成協做圖。生成的「Register」場景協做圖，如圖11.48所示。

 

圖11.48 「Register」協做圖

（3）捕獲系統中指定對象的狀態，並藉助Rational Rose工具繪製出相應的狀態圖

此處以Seeker（求職者）對象爲例，繪製其狀態圖，如圖11.49所示。

 

圖11.49 Seeker的狀態圖

（4）捕獲系統中指定對象或指定用例的活動，並藉助Rational Rose工具繪製出相應的活動圖

以捕獲「Modify Info」（更新信息）用例的活動爲例，繪製「Modify Info」活動圖如圖11.50所示。

 

圖11.50 「Modify Info」活動圖

4. 物理建模

（1）分析系統中的組件及組件間的關係，並藉助Rational Rose工具繪製出「基於Web的求職招聘系統」組件圖

經過分析，肯定「基於Web的求職招聘系統」中的組件有：Application System（求職招聘系統的Web應用程序）、Seek（求職）、Invite（招聘）、Manage（管理）。以上各組件中有部分組件存在依賴關係，詳見表11.5所示。

表11.5 「基於Web的求職招聘系統」中組件間的關係

序號	組件A	組件B	組件A和組件B之間的關係
1	Application System	Seek	依賴關係
2	Application System	Invite	依賴關係
3	Application System	Manage	依賴關係

 

最終完成「BBS論壇系統」組件圖，如圖11.51所示。

 

圖11.51 「基於Web的求職招聘系統」組件圖

（2）結合靜態模型，藉助Rational Rose工具繪製「基於Web的求職招聘系統」數據模型圖

藉助Rational Rose繪製「基於Web的求職招聘系統」部分數據模型圖如圖11.52所示。

 

圖11.52 「基於Web的求職招聘系統」部分數據模型圖

另外，還能夠從以上數據模型中導出數據庫或DDL（數據庫定義語言）腳本，導出的「S&I.ddl」腳本文件具體內容以下：

CREATE TABLE Seeker (

       seekerID SMALLINT NOT NULL,

       seekerName VARCHAR ( 16 ) NOT NULL,

       seekerSex VARCHAR ( 2 ) NOT NULL,

       seekerPassword SMALLINT NOT NULL,

       userID SMALLINT NOT NULL,

       CONSTRAINT PK_Seeker0 PRIMARY KEY (seekerID)

       );

CREATE TABLE Inviter (

       inviterID SMALLINT NOT NULL,

       inviterName VARCHAR ( 50 ) NOT NULL,

       InviterPassword SMALLINT NOT NULL,

       userID SMALLINT NOT NULL,

       CONSTRAINT PK_Inviter1 PRIMARY KEY (inviterID)

       );

CREATE TABLE User (

       userID SMALLINT NOT NULL,

       userName VARCHAR ( 50 ) NOT NULL,

       userPassword SMALLINT NOT NULL,

       CONSTRAINT PK_User2 PRIMARY KEY (userID)

       );

CREATE TABLE Administrator (

       adminID SMALLINT NOT NULL,

       adminName VARCHAR ( 16 ) NOT NULL,

       adminPassword SMALLINT NOT NULL,

       userID SMALLINT NOT NULL,

       CONSTRAINT PK_Administrator3 PRIMARY KEY (adminID)

       );

 

ALTER TABLE Administrator ADD CONSTRAINT FK_Administrator2 FOREIGN KEY (userID) REFERENCES User (userID)  ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE Seeker ADD CONSTRAINT FK_Seeker0 FOREIGN KEY (userID) REFERENCES User (userID)  ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE Inviter ADD CONSTRAINT FK_Inviter1 FOREIGN KEY (userID) REFERENCES User (userID)  ON DELETE NO ACTION ON UPDATE NO ACTION;

 

（3）分析系統中的節點及節點間的鏈接，並藉助Rational Rose工具繪製出「基於Web的求職招聘系統」部署圖。

經過分析，肯定「基於Web的求職招聘系統」中的節點有：ApplicationServer（應用服務器）、DatabaseSever（數據庫服務器）、SeekerPC、（求職者客戶機）、InviterPC（招聘者PC客戶機）、AdminPC（管理員PC機）。

顯而易見，ApplicationServer（應用服務器）節點與其餘各節點之間都存在鏈接。

藉助Rational Rose工具繪製「基於Web的求職招聘系統」部署圖，如圖11.53示。

 

圖11.53「基於Web的求職招聘系統」部署圖

5. 雙向工程

（1）利用Rational Rose工具的正向工程，將「基於Web的求職招聘系統」的類模型生成相應的Java源代碼。

藉助Rational Rose的正向工程將類模型生成代碼之後，能夠在保存路徑中找到對應的Java源文件。

以瀏覽Inviter.java文件爲例，其詳細代碼以下：

//Source file: D:\\Rose&Java\\Inviter.java

 

public class Inviter extends User

{

   private int inviterID;

   private int inviterName;

   private int inviterPassword;

   private int inviterPhone;

   private int inviterEmail;

   private int inviterRID;

   public Resume theResume;

   public Application theApplication;

   public Invitation theInvitation;

   public News theNews;

  

   /**

    * @roseuid 4D65D2990157

    */

   public Inviter()

   {

   

   }

  

   /**

    * @roseuid 4D64BEC001E4

    */

   public void setInviterPhone()

   {

   

   }

  

   /**

    * @roseuid 4D64BEC70177

    */

   public void getInviterPhone()

   {

   

   }

  

   /**

    * @roseuid 4D64BECC0232

    */

   public void setInviterEmail()

   {

   

   }

  

   /**

    * @roseuid 4D64BED20280

    */

   public void getInviterEmail()

   {

   

   }

  

   /**

    * @roseuid 4D64BEDA007D

    */

   public void setInviterRID()

   {

   

   }

  

   /**

    * @roseuid 4D64BEE00196

    */

   public void getInviterRID()

   {

   

   }

}

（2）利用Rational Rose工具的逆向工程，將「基於Web的求職招聘系統」已有的Java源代碼（即正向工程中獲得的源代碼）生成類模型。

讀者可參照第10章雙向工程的介紹自行練習，將「BBS論壇系統」已有的Java源代碼生成類模型。

11.2.5 測試能力目標

選擇一個基於Web的軟件系統（如「網上書店系統」、「網上花店系統」等），藉助Rational　Rose工具，按照「用例建模」、「靜態建模」、「動態建模」、「物理建模」、「雙向工程」的順序，對其進行UML建模。

11.2.6 知識擴展

1. RUP的核心工做流

從圖11.34能夠看出，RUP包括九個核心工做流：Business Modeling（業務建模）、Requirements（需求分析）、Analysis & Design（分析與設計）、Implementation（實現）、Test（測試）、Deployment（部署）、Configuration & Change Mgmt（配置和變動管理）、Project Management（項目管理）、Environment（環境）。其詳細內容讀者可自行參考相關資料介紹。

2. RUP的核心技術特色

（1）用例驅動

經過前面的實例能夠看出，需求分析階段用戶需求是藉助用例來表達的，設計初期的類是根據用例來發現的，構造階段開發管理和任務分配是按照用例來組織的，測試階段的實例是根據用例來生成的。

（2）以構架爲中心

架構爲用戶和研發人員提供系統的管理視圖，架構是系統實現的基礎，架構爲項目管理提供基本指導，架構描述是軟件系統的主要製品。

（3）迭代和增量的開發方式

迭代是同一過程當中最小的開發時間單位，但它卻包括了軟件開發的全部工做流，所以能夠看做是「袖珍瀑布模型」。增量是每次迭代所產生的、可增長系統功能的構造塊。迭代是RUP的開發方式，增量是RUP的開發結果。

 

附錄  Rational Rose 2003菜單

因爲Rational Rose 2003是英文菜單，因此爲方便讀者使用，對照每一項菜單，將其中文含義說明以下，供讀者自行查閱。

1. 【File】菜單

（1）【File】菜單的下級菜單如表附1所示。

表附1 【File】的下級菜單

二級菜單	三級菜單	快捷鍵	含義
New		Ctrl+N	建立新的模型文件
Open		Ctrl+O	打開模型文件
Save		Ctrl+S	保存模型文件
Save As			將當前的模型保存到其餘的模型文件中
Save Log As			保存日誌文件
AutoSave Log			自動保存日誌
Clear Log			清空日誌記錄區
Load Model Workspace			加載模型工做區
Save Model Workspace			保存模型工做區
Save Model Workspace As			將當前模型工做區保存爲其餘模型工做區
Units	Load…		加載
	Save		保存
	Save As…		另存爲
	Unload		卸載
	Control		控制
	Uncontrol		放棄控制
	Write Protected		寫保護
	CM		存在四級菜單（見表附2）
Import			導入模型
Export Activation			導出模型
Update			更新模型
Print		Ctrl+P	打印模型中的圖和說明書
Page Setup			打印時的頁面設置
Edit Path Map			設置虛擬映射
Exit			退出

須要說明的是，二級菜單選項【Units】下的三級菜單（【CM】除外）因模型元素的不一樣而不一樣。

（2）【CM】的下級菜單詳見表附2所示。

表附2 【CM】的下級菜單

四級菜單	含義
Add to Version Control	將模型元素加入版本控制
Remove From Version Control	將模型元素從版本中刪除
Start Version Control Explore	啓動Rose裏的版本控制系統
Get Latest	獲取模型元素的最新版本
Check Out	放棄當前版本
Check In	登記當前版本
Undo Check Out	撤銷上一級的【Check Out】
File Properties	顯示加入版本控制的模型元素的信息
File History	顯示加入版本控制的模型元素的歷史信息
Version Control Option	版本控制選項
About Rational Rose Version Control Integration	顯示Rose版本控制的版本信息

2. 【Edit】菜單

不一樣種類的模型圖，其【Edit】菜單的下級菜單有所不一樣，但有一些選項是共有的，詳見表附3所示，不一樣的選項詳見表附4所示。

表附3 共有的【Edit】的下級菜單

二級菜單	快捷鍵	含義
Undo Move	Ctrl+Z	撤銷前一次的操做
Redo Move	Ctrl+Y	重複前一次的操做
Cut	Ctrl+X	剪切
Copy	Ctrl+C	複製
Paste	Ctrl+V	粘貼
Delete	DEL	刪除
Select All	Ctrl+A	全選
Delete from Model	Ctrl+D	刪除模型中的元素
Find	Ctrl+F	查找
Reassign		從新指定模型元素

 

 

 

 

表附4 不一樣種類模型圖的【Edit】下級菜單

模型圖	二級菜單	三級菜單	含義
Use Case Diagram Class Diagram	Reloacate		更新部署模型元素
	Compartemnet		編輯模塊
	Change Info	Class	更改類
		Parameterized Class	更改參數化的類
		Instantiated Class	更改示例化的類
		Class Utility	更改類的效用
		Parameterized Class Utility	更改參數化的類的效用
		Instantiated Class Utility	更改示例化的類的效用
		Uses Dependency	更改依賴關係
		Generalization	更改泛化關係
		Instantiates	更改實例
		Association	更改關聯關係
		Realize	更改實現關係
Component Diagram	Relocate		從新部署模型元素
	Compartment		編輯模塊
	Change Info	Subprogram specification	更改子系統規範
		Subprogram body	更改子系統體
		Generic subprogram	更改通用子系統
		Main program	更改主程序
		Package specification	更改包規範
		Package body	更改包體
		Task specification	更改工做規範
		Task body	更改工做體
Deployment Diagram	Relocate		從新部署模型元素
	Compartment		編輯模塊
Sequence Diagram	Attach Script		添加腳本
	Detach Script		刪除腳本
Collaboration Diagram	Compartment		編輯模塊
Statechart Diagram	Compartment		編輯模塊
	Change Info	State	將活動變爲狀態
		Activate	將狀態變爲活動
Activate Diagram	Relocate		從新部署模型元素
	Compartment		編輯模塊
	Change Info	State	將活動變爲狀態
		Activate	將狀態變爲活動

 

3. 【View】菜單

【View】菜單的下級菜單如表附5所示。

表附5 【View】下級菜單

二級菜單	三級菜單	快捷鍵	含義
Toolbars	Standard		顯示或隱藏標準工具欄
	Toolbars		顯示或隱藏編輯區工具欄
	Configure		定製工具欄
Status Bar			顯示或隱藏狀態欄
Documentation			顯示或隱藏文檔區
Browser			顯示或隱藏瀏覽區
Log			顯示或隱藏日誌區
Editor			顯示或隱藏內部編輯器
Time Stamp			顯示或隱藏時間戳
Zoom to Selection		Ctrl+M	居中顯示
Zoom In		Ctrl+I	放大
Zoom Out		Ctrl+U	縮小
Fit in Window		Ctrl+W	設置顯示比例使圖形放進窗口
Undo Fit in Window			撤銷【Fit in Window】
Page Breaks			顯示或隱藏頁的操做
Refresh		F2	刷新
As Booch		Ctrl+Alt+B	用Booch符號表示模型
As OMT		Ctrl+Alt+O	用OMT符號表示模型
As Unified		Ctrl+Alt+U	用UML符號表示模型

4. 【Format】菜單

【Format】菜單的下級菜單如表附6所示。

表附6 【Format】下級菜單

二級菜單	三級菜單	含義	備註
Font Size	8	設置爲8號字
	10	設置爲10號字
	12	設置爲12號字
	14	設置爲14號字
	16	設置爲16號字
	18	設置爲18號字
二級菜單	三級菜單	含義	備註
Font		設置字體
Line Color		設置線段顏色
Fill Color		設置圖標顏色
Use Fill Color		使用設置的圖標顏色
Automatic Resize		自動調節圖標大小
Stereotype Display	None	選擇空的構造型
	Label	選擇帶標籤的模板
	Decoration	選擇帶註釋的模板
	Icon	選擇帶圖標的模板
Stereotype Label		顯示構造型標籤
Show Visibility		顯示可見性
Show Compartment Stereotype		顯示構造型屬性或操做
Show Operation signature		顯示操做的署名 （即參數和返回值）
Show All Attributes		顯示全部的屬性
Show All Operations		顯示全部的操做
Show All Columns		顯示全部列	用例圖和類圖中沒有
Show All Triggers		顯示全部觸發器	用例圖和類圖中沒有
Suppress Attributes		禁止顯示全部屬性
Supress Operations		禁止顯示全部操做
Supress Columns		禁止顯示全部列	用例圖和類圖中沒有
Supress Triggers		禁止顯示全部觸發器	用例圖和類圖中沒有
Line Style	Rectilinear	選擇垂線樣式	協做圖中沒有
	Oblique	選擇斜線樣式	協做圖中沒有
	Toggle	選擇折線樣式	協做圖中沒有
Layout Diagram		從新排列全部圖形	組件圖和協做圖中沒有
Autosize All		自動調節圖標大小	組件圖和部署圖中沒有
Layout Selected Shapes		從新排列選中的圖形	時序圖和協做圖中沒有

 

表附6中備註欄沒有特別說明的，表示該菜單選項在全部的模型圖中都存在。

5. 【Browse】菜單

不一樣種類的模型圖，其【Browse】菜單的下級菜單有所不一樣，但有一些選項是共有的，詳見表附7所示，不一樣的選項詳見表附8所示。

 

表附7 共有的【Browse】的下級菜單

二級菜單	快捷鍵	含義
Use Case Diagram		瀏覽用例圖
Class Diagram		瀏覽類圖
Component Diagram		瀏覽組件圖
Deployment Diagram		瀏覽配置圖
Interaction Diagram		瀏覽交互圖
State Machine Diagram	Ctrl+T	瀏覽狀態圖
Expand	Ctrl+E	瀏覽選中的邏輯包或組件包的主圖
Parent		瀏覽父圖
Specification	Ctrl+B	瀏覽模型元素的規範
Top Level		瀏覽上層圖
Previous Diagram	F3	瀏覽前一個圖

 

表附8 不一樣種類模型圖的【Browse】下級菜單

模型圖	二級菜單	快捷鍵	含義
Use Case Diagram Class Diagram	Referenced Item	Ctrl+R	瀏覽選中項目相關的圖或說明書
	Create Message Trace Diagram	F5	建立消息追蹤圖
Sequence Diagram	Referenced Item	Ctrl+R	瀏覽選中項目相關的圖或說明書
	Create Collaboration Diagram	F5	根據時序圖建立協做圖
Collaboration Diagram	Referenced Item	Ctrl+R	瀏覽選中項目相關的圖或說明書
	Create Sequence Diagram	F5	根據協做圖建立時序圖
Component Diagram Deployment Diagram	Referenced Item	Ctrl+R	瀏覽選中項目相關的圖或說明書

6. 【Report】菜單

【Report】菜單的下級菜單如表附9所示。

表附9 【Report】下級菜單

二級菜單	含義	備註
Show Usage	顯示所選項目在哪裏被使用	所有圖中都有
Show Participants in UC	得到用例中全部參與者列表	所有圖中都有
Show Instances	得到全部包含所選類的協做圖列表	用例圖和類圖中有
Show Access Violations	得到類圖中包之間全部拒絕訪問的列表	用例圖和類圖中有
Show Unresolved Objects	得到全部所選項目中未解決的對象列表	時序圖和協做圖中有
Show Unresolved Message	得到所選項目中未解決的消息列表	時序圖和協做圖中有

 

7. 【Query】菜單

在時序圖、協做圖和配置圖中沒有【Query】菜單，在其餘的模型圖中【Query】的下級也是不一樣的，如表附10所示。

表附10 【Query】下級菜單

模型圖	二級菜單	含義
Use Case Diagram, Class Diagram	Add Class	添加類
	Add Use Case	添加用例
	Expand Selected Elements	擴展所選的元素
	Hide Selected Elements	隱藏所選的元素
	Filter Relationships	過濾關係
Statechart Diagram Activate Diagram	Add Elements	添加元素
	Expand Selected Elements	擴展所選的元素
	Hide Selected Elements	隱藏所選的關係
	Filter Transitions	過濾轉換
Component Diagram	Add Components	添加組件
	Add Interfaces	添加接口
	Expand Selected Elements	擴展所選的元素
	Hide Selected Elements	隱藏所選的元素
	Filter Relationships	過濾關係

8. 【Tools】菜單

【Tools】菜單的下級菜單如表附11所示。

表附11 【Tools】下級菜單

二級菜單	三級菜單	四級菜單	含義
Create	不一樣模型圖的三級菜單不一樣 在此附表中再也不逐一贅述
Check Model			搜尋模型中未解決的引用， 並在日誌區中輸出結果
Model Properties	Edit		編輯模型道具
	View		顯示模型道具
	Replace		加載模型道具集合
	Export		導出模型道具集合
	Add		添加新的模型道具
	Update		更新模型道具集合
二級菜單	三級菜單	四級菜單	含義
Options			定製Rose選項
Open Script			打開現有的腳本
New Script			建立新的腳本
ANSI C++	Open ANSI C++ Specification		編輯ANSI C++規範
	Browse Header		瀏覽ANSI C++標題
	Browser Body		瀏覽ANSI C++主題
	Reverse Engineer		由ANSI C++代碼生成模型
	Generate Code		生成ANSI C++代碼
	Class Customization		定製生成ANSI C++中的類
	Preferences		定製ANSI C++中的參數
	Convert From Classic C++		從經典的C++轉變爲ANSI C++
Ada 83	Code Generation		生成Ada 83代碼
	Browse Spec		瀏覽Ada 83說明書
	Browse Body		瀏覽Ada 83主體
Ada 95	Code Generation		生成Ada 95代碼
	Browse Spec		瀏覽Ada 95說明書
	Browse Body		瀏覽Ada 95主體
CORBA	Project Specification		編輯CORBA工程規範
	Syntax Check		CORBA語言檢測
	Browse CORBA Source		瀏覽CORBA來源
	Reverse Engineer CORBA		由CORBA代碼生成模型
	Generate Code		生成CORBA代碼
J2EE Deploy	Deploy		配置J2EE
Java/J2EE	Project Specification		編輯Java/J2EE工程規範
	Syntax Check		Java/J2EE語法檢測
	Edit Code		編輯Java/J2EE代碼
	Generate Code		生成Java/J2EE代碼
	Reverse Engineer		由Java/J2EE代碼生成模型
	Check In		登記當前的Java/J2EE代碼
	Check Out		放棄當前的Java/J2EE代碼
	Undo Check Out		撤銷【Check Out】
	Use Source Code Control Explorer		使用源代碼控制探測器
	New EJB		建立新的EJB
	New Servlet		建立新的Servlet
	Generate EJG-JAR File		生成EJB-JAR文件
	Generate WAR File		生成WAR文件

 

二級菜單	三級菜單	四級菜單	含義
Oracle 8	Data Type Creation Wizard		建立數據模型
	Ordering Wizard		屬性和隊列順序嚮導
	Edit Foreign Keys		編輯外鍵
	Analyze Schema		分析圖表
	Schema Generation		生成圖表
	Syntax Checker		語法檢測
	Reports		生成數據模型報告
	Import Oracle8 Data Types		導入數據類型
Quality Architect	Console		打開質量結構控制檯
	Unit Test	Generate Unit Test	生成單元測試
		Select Unit Test Template	選擇單元測試模板
		Create/Edit Datapool	建立或編輯數據池
	Stubs	Generate Stub	生成存根
		Creat/Edit Look-up Table	建立或編輯查詢表
	Scenario Test	Generate Scenario Test	生成情景測試
		Select Scenario Template	選擇情景測試
	Online Manual		打開在線手冊
Model Integrator			打開模型集成器
Web Publisher			發佈模型
TOPLink			進行TOPLink轉換
COM	Properties		定製COM選項
	Import Type Library		導入COM組件類型庫
Visual C++	Model Assistant		打開建模助手
	Component Assignment Tool		打開組件分配工具
	Update Code		打開代碼更新工具
	Update Model from Code		打開模型更新工具
	Class Wizard		建立新的類
	Undo Last Code Updata		撤銷【Code Update】
	COM	New ATL Object	新的ATL對象
		Implement Interface	實現接口
		Module Dependency Properties	模塊依賴關係選項
		How Do I	如何實現接口對應的類
	Quick Import ATL 3.0		導入ATL3.0類型庫
	Quick Import MFC 6.0		導入MFC6.0類型庫
	Model Converter		Visual C++模型轉換器
	Frequently Asked Questions		Visual C++幫助
	Properties		Visual C++選項設置

 

二級菜單	三級菜單	四級菜單	含義
Version Control	Add to Version Control		將模型元素加入版本控制
	Remove From Version Control		將模型元素從版本控制中刪除
	Start Version Control Explorer		啓動Rose中的版本控制系統
	Check In		登記爲當前版本
	Check Out		放棄當前版本
	Undo Check Out		撤【Check Out】
	Get Latest		獲取模型元素的最新版本
	File Properties		顯示加入版本控制的模型元素的信息
	File History		顯示加入版本控制的模型元素的歷史信息
	Version Control Options		版本控制選項
	About Rational Rose Version Control Integration		顯示Rational Rose版本控制的版本信息
Visual Basic	Model Assistant		打開Visual Basic建模助手
	Component Assignment Tool		打開Visual Basic組件分配工具
	Update Code		打開Visual Basic代碼更新工具
	Update Model from Code		打開Visual Basic模型更新工具
	Class Wizard		建立新的Visual Basic類
	Add Reference		將COM組件的類型庫導入模型
	Browse Source Code		瀏覽Visual Basic源碼
	Properties		設置Visual Basic選項
Web Modeler	User Preference		設置網絡建模器中的用戶參數
	Reverse Engineer a New Web Application		由網絡應用生成模型
XML_DTD	Project Specification		編輯XML_DTD工程規範
	Syntax Check		XML_DTD語法檢測
	Browse XML_DTD Source		瀏覽XML_DTD來源
	Reverse Engineer XML_DTD		由XML_DTD代碼生成模型
	Generate Code		生成XML_DTD代碼
Class Wizard			建立新類

9. 【Add-Ins】菜單

【Add-Ins】菜單下只有一個【Add-In Manager】選項，其用途是設置附加選項的狀態，即設置爲活動或無效。

 

10.【Windows】菜單

【Windows】菜單的下級菜單如表附12所示。

表附12 【Windows】下級菜單

二級菜單	含義
Cascade	層疊編輯區窗口
Tile	平均分配編輯區窗口
Arrange Icons	排列編輯區最小化窗口的圖標

11.【Help】菜單

【Help】菜單的下級菜單如表附13所示。

表附13 【Help】下級菜單

二級菜單	三級菜單	含義
Contents and Index		顯示文檔主題的列表
Search for Help On		搜尋一個指定的幫助主題
Using Help		在線查看幫助
Extend Help		查看擴展幫助
Contracting Technical Support		客戶支持
Rational on the Web	Rational Home Page	打開Rational的主頁
	Rose Home Page	打開Rose的主頁
	Technical Support	打開技術支持的主頁
Rational Developer Network		打開Rational開發者網站
About Rational Rose		顯示Rational Rose的產品信息