第5章需求建模15.1用例模型概述5.2用例圖組成5.3識別和描述用例5.4用例間的關系2本章將向讀者詳細介紹應用用例模型進行軟件系統(tǒng)需求建模的基本內(nèi)容。需求建模主要包括：用例模型概述、用例圖的組成、識別和描述用例、識別用例之間的關系、繪制用例圖等。本章的學習要點包括：用例圖的組成（參與者和用例）；識別和描述用例；用例間的關系（泛化、關聯(lián)和依賴）；繪制用例圖。35.1用例模型概述45.1用例模型概述5任務1了解用例模型的基本功能和基本組成。任務描述

65.1用例模型概述

1.用例模型的功能用例模型是把應滿足用戶需求的基本功能（集）聚合起來表示的強大工具。對于正在構造的新系統(tǒng)，用例描述該系統(tǒng)應該做什么；對于已構造完畢的系統(tǒng)，用例則反映了系統(tǒng)能夠完成什么樣的功能。構建用例模型是通過系統(tǒng)開發(fā)者與系統(tǒng)的客戶（或最終使用者）共同協(xié)商完成的，他們要反復討論需求的規(guī)格說明，達成共識，明確系統(tǒng)的基本功能，為后階段的工作打下基礎。75.1用例模型概述

2.用例模型的基本組成用例模型的基本組成部件是用例、參與者和系統(tǒng)。

用例用于描述系統(tǒng)的功能，也就是從外部用戶的角度觀察系統(tǒng)應具備哪些功能，幫助分析人員理解系統(tǒng)的行為，它是對系統(tǒng)功能的宏觀描述。一個完整的系統(tǒng)中通常包含若干個用例，每個用例具體說明應完成的功能，代表系統(tǒng)的所有基本功能（集）。

參與者是與系統(tǒng)進行交互的外部實體，它可以是系統(tǒng)用戶，也可以是其他系統(tǒng)或硬件設備，總之，凡是需要與系統(tǒng)交互的任何東西都可以稱做參與者。

系統(tǒng)仿佛是實現(xiàn)各種用例的“黑盒子”，我們只關心該系統(tǒng)實現(xiàn)了哪些功能，并不關心內(nèi)部的具體實現(xiàn)細節(jié)（如系統(tǒng)是如何做的，用例是如何實現(xiàn)的）。85.1用例模型概述

3.引入用例的目的引入用例的主要目的包括以下幾點：（1）確定系統(tǒng)應具備哪些功能，這些功能是否滿足系統(tǒng)的需求（開發(fā)者與用戶協(xié)商達成共識的東西）。（2）為系統(tǒng)的功能提供清晰一致的描述，以便為后續(xù)的開發(fā)工作打下良好的交流基礎，方便開發(fā)人員傳遞需求的功能。（3）為系統(tǒng)驗證工作打下基礎。通過驗證最終實現(xiàn)的系統(tǒng)能夠執(zhí)行的功能是否與最初需求的功能相一致，保證系統(tǒng)的實用性。5.2用例圖組成95.2用例圖組成10任務2確定WebShop電子商城系統(tǒng)中的參與者、系統(tǒng)邊界。任務描述

11在UML中，用例模型（也就是用例視圖）是用例圖描述的。用例模型可以由若干個用例圖組成。用例圖中包含系統(tǒng)、參與者和用例等三種模型元素。繪制用例圖時，既要畫出這三種模型元素，同時還要畫出元素之間的各種關系（泛化、關聯(lián)、依賴）。5.2用例圖組成WebShop用戶管理用例圖12

5.2.1參與者參與者（Actor）是與系統(tǒng)交互的人或事。所謂“與系統(tǒng)交互”指的是參與者向系統(tǒng)發(fā)送消息，從系統(tǒng)中接收消息，或是在系統(tǒng)中交換信息。

UML中用一個小人形圖形表示角色類，小人的下方書寫角色名字。5.2用例圖組成購物用戶參與者13

5.2.1參與者——參與者的類型5.2用例圖組成從參與者的具體表現(xiàn)形式來看，參與者有三種類型：（1）系統(tǒng)用戶，即系統(tǒng)的用戶（真實的人），是最常見的參與者。（2）其他系統(tǒng)。（3）一些可以運行的進程。14

5.2.1參與者——參與者的確定5.2用例圖組成怎樣確定系統(tǒng)的參與者呢？開發(fā)人員可以通過回答以下的問題來確定系統(tǒng)的參與者：（1）使用系統(tǒng)主要功能的人是誰（主要角色）？（2）需要借助于系統(tǒng)完成日常工作的人是誰？（3）誰來維護和管理系統(tǒng)（次要角色），保證系統(tǒng)正常工作？（4）系統(tǒng)控制的硬件設備有哪些？（5）系統(tǒng)需要與哪些其他系統(tǒng)交互？（6）對系統(tǒng)產(chǎn)生的結果感興趣的人或事是哪些？WebShop電子商城參與者15參與者對于系統(tǒng)而言總是外部的，它們可以處于人的控制之外；參與者可以直接或間接地同系統(tǒng)交互，或使用系統(tǒng)提供的服務以完成某件事務；參與者表示人或事物與系統(tǒng)發(fā)生交互時所扮演的角色，而不是特定的人或者特定的事物；一個人或事物在與系統(tǒng)發(fā)生交互時，可以扮演多個角色；每一個參與者需要一個具有業(yè)務一樣的名字，并且必須有簡短的描述（從業(yè)務角度描述參與者是什么）；參與者可以具有屬性和事件，但使用不能太頻繁。16

5.2.2系統(tǒng)5.2用例圖組成系統(tǒng)是用例模型的一個組成部分，代表的是一部機器或一個商務活動等，而并不是真正實現(xiàn)的軟件系統(tǒng)。

系統(tǒng)的邊界用來說明構建的用例模型的應用范圍。

用例圖中的系統(tǒng)用一個長方框表示，系統(tǒng)的名字寫在方框上方或方框里面，方框內(nèi)部還可以包含該系統(tǒng)中的用符號表示的用例。系統(tǒng)17

5.2.3用例——什么是用例5.2用例圖組成用例代表一個系統(tǒng)或系統(tǒng)的一部分行為，是對一組動作序列的描述，系統(tǒng)執(zhí)行該動作序列來為參與者產(chǎn)生一個可觀察的結果值。用例代表的是一個完整的功能。UML中的用例是動作步驟的集合。動作是系統(tǒng)的一次執(zhí)行（能夠給某個參與者輸出結果值）。用例應支持多種可能發(fā)生的動作。

UML中的用例用橢圓形表示，用例的名字寫在橢圓的內(nèi)部或下方。用例示例18

5.2.3用例——用例的特征5.2用例圖組成用例具有以下的特征：（1）用例總是由參與者初始化。用例所代表的功能必須由參與者激活，而后才能執(zhí)行。（2）用例為參與者提供值。用例必須為參與者提供實在的值，雖然這個值并不總是重要的，但是應能被參與者識別。（3）用例具有完全性。用例是一個完整的描述。不管用例內(nèi)部的小用例是如何通信工作的，只有最終產(chǎn)生了返回給參與者的結果值，才能說明用例執(zhí)行完畢。19用例表示的也是一個類（如搜索圖書），而不是某個具體的實例（搜索名稱為“Java程序設計”的圖書）。用例描述了它代表的功能的各個方面，也就是包含了用例執(zhí)行期間可能發(fā)生的種種情況。20（1）小組討論用例模型的主要功能有哪些。（2）根據(jù)已往的軟件開發(fā)經(jīng)驗，討論使用用例模型來描述需求與使用純文字的方式來描述需求有什么不同。（3）結合實例說明用例模型由哪幾部分組成。

（4）根據(jù)典型圖書管理系統(tǒng)的需求，確定該系統(tǒng)中的參與者，并說明確定參與者的根據(jù)。（5）確定圖書管理系統(tǒng)的系統(tǒng)邊界。

1.操作要求

2.操作提示

（1）通過學習小組討論和上網(wǎng)查詢資料形式完成。（2）使用手繪形式繪制出圖書管理系統(tǒng)的參與者和系統(tǒng)邊界。5.3識別和描述用例21225.3識別和描述用例任務3確定WebShop電子商城中的用例，繪制WebShop電子商城的用例圖，并對用例進行描述。任務描述

235.3識別和描述用例

5.3.1識別用例——針對參與者（1）某個參與者要求系統(tǒng)為其提供什么功能？該參與者需要做哪些工作？（2）參與者需要閱讀、創(chuàng)建、銷毀、更新或存儲系統(tǒng)中的某些信息嗎？（3）系統(tǒng)中的事件一定要告知參與者嗎？參與者需要告訴系統(tǒng)一些什么嗎？（4）系統(tǒng)新功能的識別，參與者的日常工作被簡化或效率提高了嗎？245.3識別和描述用例

5.3.1識別用例——針對系統(tǒng)（1）系統(tǒng)需要什么樣的輸入和輸出？輸入來自哪里？輸出到哪里去？（2）該系統(tǒng)的當前狀況還存在哪些問題？（3）系統(tǒng)的改進方向？255.3識別和描述用例

5.3.1識別用例【任務3-1】確定WebShop電子商城中的用例。265.3識別和描述用例

5.3.2繪制WebShop電子商城用例圖【任務3-2】繪制WebShop電子商城中的用例圖。詳見教學視頻《繪制圖書管理系統(tǒng)用例圖》275.3識別和描述用例

5.3.2繪制WebShop電子商城用例圖按鈕按鈕名稱功能Selection選擇工具Note添加注釋Anchor將圖中的元素與注釋相連Label添加文本標簽Box繪制盒子，將某些元素框在一起Actor繪制參與者UseCase繪制用例Association添加雙向關聯(lián)關系DirectionalAssociation添加單向關聯(lián)關系Dependency添加依賴關系Generalization添加泛化關系用例圖繪圖工具欄按鈕285.3識別和描述用例

5.3.3通過文件夾對用例進行合理規(guī)劃Umbrello的用例視圖可以通過文件夾“Folder”來管理，把各種各樣的模型元素通過內(nèi)在的語義連在一起成為一個整體。Umbrello中的文件夾通常用于對模型進行組織管理，它是一個邏輯元素，并不會出現(xiàn)在用例圖中?！救蝿?-3】通過文件夾對WebShop電子商城中的用例進行規(guī)劃。295.3識別和描述用例

5.3.4WebShop電子商城用例圖（不含關系）系統(tǒng)的參與者購物用戶管理相關的用例圖305.3識別和描述用例

5.3.4WebShop電子商城用例圖（不含關系）前臺購物相關的用例圖后臺管理相關的用例圖315.3識別和描述用例

5.3.4WebShop電子商城用例圖（不含關系）管理購物用戶相關的用例圖325.3識別和描述用例

5.3.5用例描述用例的描述應包括以下幾個方面：（1）用例的目標。（2）用例是怎樣被啟動的。（3）參與者和用例之間的消息流。（4）用例的多種執(zhí)行方案。（5）用例怎樣才算完成并把值傳給了參與者。用例編號用例名稱用例描述參與者前置條件后置條件基本路徑1．….XXXX2．….XXXX擴展點 2a.….XXXX 2a1.….XXXX變異點補充說明用例描述的模板335.3識別和描述用例

5.3.5用例描述用例編號：001用例名：購物用戶登錄用例描述：購物用戶根據(jù)所注冊的用戶名和密碼，登錄到WebShop電子商城系統(tǒng)。參與者：購物用戶前置條件：電子商城正常運行時間。后置條件：如果購物用戶登錄成功，則該購物用戶可搜索商品并購買商品；如果購物用戶登錄未成功，則該用戶不能進行商品的購買?；韭窂?．購物用戶進入WebShop電子商城系統(tǒng)；2．購物用戶輸入用戶名和密碼；

3．購物用戶提交輸入的信息；4．系統(tǒng)對購物用戶的賬號和密碼進行有效性檢查；5．系統(tǒng)記錄并顯示當前登錄用戶；6．購物用戶搜索商品并購買商品；7．系統(tǒng)允許購物用戶的購買操作。擴展點 4a．購物用戶的賬號錯誤 4a1．系統(tǒng)彈出賬號錯誤或賬號已關閉警告信息； 4a2．購物用戶離開或重新輸入賬號。 4b．購物用戶的密碼錯誤 4b1．系統(tǒng)彈出密碼錯誤警告信息； 4b2．購物用戶離開或重新輸入密碼。變異點

無補充說明34在用例描述中不要包含GUI設計，因為用例是針對需求的，而界面設計是“設計”，不要把設計的東西放進需求中；用例描述的目的是對用例的具體完成情況進行詳細說明；用例通常描述參與者與系統(tǒng)的交互，如購物用戶怎樣，系統(tǒng)怎樣等。35（1）確定圖書管理系統(tǒng)的用例。（2）繪制圖書管理系統(tǒng)的用例圖。（3）對圖書管理系統(tǒng)的用例進行描述。

1.操作要求

2.操作提示

（1）通過學習小組討論和上網(wǎng)查詢資料形式完成。（2）使用Umbrello2.32進行圖形的繪制。（3）建議通過包圖對圖書管理系統(tǒng)中的用例進行邏輯分類。5.4用例間的關系365.4用例間的關系37任務4識別WebShop電子商城中用例間的關系，并繪制其關系圖。任務描述

38用例圖主要用來圖示化系統(tǒng)的主事件流程，它主要用來描述客戶的需求，即客戶希望系統(tǒng)具備的完成一定功能的動作。通俗地理解，用例就是軟件的功能模塊，所以用例圖是系統(tǒng)分析階段的起點，設計人員根據(jù)客戶的需求來創(chuàng)建和解釋用例圖，用來描述軟件應具備哪些功能模塊以及這些模塊之間的調(diào)用關系。用例圖中的用例之間和參與者之間也是具有一定的聯(lián)系的。用例是從系統(tǒng)外部可見的行為，是系統(tǒng)為某一個或幾個參與者提供的一段完整的服務。從原則上來講，用例之間都是獨立、并列的，它們之間并不存在著包含從屬關系。但是為了體現(xiàn)一些用例之間的業(yè)務關系，提高可維護性和一致性，用例之間可以抽象出泛化（Generalization）、關聯(lián)（Asscociation）和依賴（Dependency）幾種關系。用例間關系的共性就是從現(xiàn)有的用例中抽取出公共的那部分信息，作為一個單獨的用例，然后通后過不同的方法來重用這個公共的用例，以減少模型維護的工作量。5.4用例間的關系395.4用例間的關系

5.4.1泛化關系——用例泛化關系用例泛化關系（Generalization）是指一種從子用例到父用例的關系，它指定了子用例如何特化父用例的所有行為和特征。

Umbrello使用“”表示泛化關系。箭尾方向為子用例（子參與者），箭頭方向為父用例（父參與者）。用例間的泛化關系詳見教學視頻《繪制泛化關系》405.4用例間的關系

5.4.1泛化關系——參與者泛化關系跟用例一樣，參與者和參與者之間也存在著泛化關系

右圖所示的參與者的包中包含了五個參與者。其中用戶被購物用戶和后臺管理員所特化，后臺管理員進一步由普通管理員和系統(tǒng)管理員所特化。參與者間的泛化關系415.4用例間的關系

5.4.2關聯(lián)關系

關聯(lián)關系（Association）是指表示參與者與用例之間的通信，任何一方都可發(fā)送或接受消息。關聯(lián)關系包括普通關聯(lián)關系（Association）和定向關聯(lián)關系（DirectionalAssociation）。前者表示參與者與用例之間的通信，任何一方都可發(fā)送或接受消息，后者表示只有一方表示可以發(fā)送消息，另一方則接受消息。Umbrello使用“”表示普通關聯(lián)關系，使用“”表示定向關聯(lián)關系，箭尾方向為發(fā)送消息方，箭頭方向為接受消息方，如圖5-29所示。參與者與用例之間的關聯(lián)關系詳見教學視頻《繪制關聯(lián)關系》425.4用例間的關系

5.4.3依賴關系依賴關系（Dependency）是指一個用例會使用到另一個用例的關系。Umbrello使用“”表示依賴關系，箭尾方向為使用者用例，箭頭方向為提供者用例。相比RationalRose等UML建模工具，Umbrello簡化了用例圖中的關系，不再區(qū)分擴展（extend）和包含（include）關系，統(tǒng)一使用依賴關系表示。依賴關系詳見教學視頻《繪制依賴關系》435.4用例間的關系

5.4.4WebShop電子商城用例圖（含關系）參與者關系購物用戶管理用例之間的關系詳見教學視頻《繪制圖書管理系統(tǒng)用例間的關系》445.4用例間的關系

5.4.4WebShop電子商城用例圖（含關系）前臺購物用例之間的關系后