1、用例高天迎 用例n1 用例的概念n2 用例建模技術n3 實例圖書館管理系統中的用例需求分析n需求分析的任務是確定所開發的軟件的功能、性能、數據等各個方面的要求。主要解決系統“做什么”的問題。n需求分析是軟件整個開發過程中的一個關鍵過程。n需求分析中的“溝通鴻溝”： 需求分析需要各方面人員（如分析人員、開發人員、客戶等）的參與，而這些人員有著不同的知識背景，對目標系統的認知程度也各不相同，這種差異導致各方面人員之間溝通困難，人為的給需求分析的實施增加了難度。需求規格說明書的目錄框架參考需求n需求定義：需求定義：需求（requirement）就是系統（更廣義的說法是項目）必須提供的能力和必須遵從的

2、條件。n需求分類：需求分類： n功能性功能性（行為的），有具體的完成內容的需求。n客戶登錄、郵箱網站的收發收發郵件、論壇網站的發帖留言等。n用戶能夠搜索所有的數據集合n每一個訂單需要分配一個唯一標識符，用戶可以永久保存起來需求n非功能性非功能性（其它所有的行為） ，軟件產品為滿足用戶業務需求而必須具有且除功能需求以外的特性，包括系統的性能、可靠性、可維護性、可擴充性和對技術和對業務的適應性等。 n性能要求：要求系統能滿足100個人同時使用，頁面反應時間不能超過6秒；n可靠性： 系統能724小時連續運行，年非計劃宕機時間不能高于8小時。要求能快速的部署，特別是在系統出現故障時，能夠快速的切換到備

3、用機。n領域規則，法律，知識產權需求n在統一過程（UP）中，需求按照“FURPS+”模型進行分類。 n功能性（Functional）：特性、功能、安全性； n可用性（Usability）：人性化因素、幫助、文檔； n可靠性（Reliability）：故障頻率、可恢復性、可預測性； n性能（Performance）：響應時間、吞吐量、準確性、有效性、資源利用率； n可支持性（Supportability）：適應性、可維護性、國際化、可配置性。 需求n“FURPS+”中的“+”是指一些輔助性的和次要的因素，比如：n實現（Implementation）：資源限制、語言和工具、硬件等； n接口（Int

4、erface）；強加于外部系統接口之上的約束； n操作（Operation）：對其操作設置的系統管理； n包裝（Packaging）例如物理的包裝盒； n授權（Legal）：許可證或其他方式。需求問題的代價想改進就能改進嗎？需求石頭問題需求問題對策1. 概念n1.1 概述n1.2 參與者n1.3 用例n1.4 用例之間的關系1.1 概述 n用例圖顯示誰將是相關的用戶、用戶希望系統提供什么服務以及用戶需要為系統提供的服務。n用例圖最常用來描述系統以及子系統。 1.1 概述 n用例圖包含6個元素：n參與者（Actor）n用例（Use Case）n關聯關系（Association）n包含關系（Inc

5、lude）n擴展關系（Extend）n泛化關系（Generalization） 1.2 參與者 n定義：Actor是指系統以外的，需要使用系統或與系統交互的東西，包括人，設備和其它系統。Actor有不同的譯名，如：參與者, 活動者, 執行者, 行動者等。n系統外部的一個實體。n參與用例的執行過程。n通過向系統輸入或請求系統輸入某些事件來觸發系統的執行。n由參與用例時所擔當的角色來表示。n每個參與者可以參與一個或多個用例。 1.2 參與者n參與者的種類：n系統用戶n與所建造的系統交互的其他系統n一些可以運行的進程 確定參與者n如何尋找系統的參與者 n誰使用系統的主要功能？n誰改變系統的數據n誰從

6、系統獲取信息n誰需要系統的支持以完成日常工作任務？n誰負責維護、管理并保持系統正常運行？n系統需要應付（處理）哪些硬設備？n系統需要和哪些外部系統交互？n誰（或什么）對系統運行產生的結果感興趣？n有沒有自動發生的事件確定參與者n對參與者建模的過程中需要注意的問題n參與者對于系統而言總是外部的n參與者可以直接或間接的同系統交互n一個人或事物在與系統交互時，可以扮演多個角色n每一個參與者必須有簡短的描述參與者間的關系n參與者(actor)之間可以存在泛化泛化關系，表示一個一般性的參與者與另一個更為特殊的參與者之間的聯系。n參與者間的泛化關系示例：說明n例：在線銀行系統的一些可能的參與者參與者n客戶

7、：從系統獲取信息并執行金融交易。n管理人員：開辦系統的用戶。獲取并更新信息。n廠商：接受作為轉帳支付結果的資金nmail系統說明n責任類似或重疊泛化出一個抽象執行者1.3 用例 nUse Case概念是Jacobson于60年代和70年代在愛立信公司開發AKE，AXE系列系統時發明的，并在其博士論文(85年)和92年出版的論著中做了詳細論述。n在軟件開發中采用Use Case驅動是Jacobson對軟件界最重要的貢獻之一。 n自Jacobson的著作出版后，面向對象領域已廣泛接納了用例這一概念，并認為它是第二代面向對象技術的標志。UseCase驅動use case對軟件開發的意義實現實現測試測

8、試需求需求分析和設計分析和設計Use Cases 把所有這些過程綁到一起把所有這些過程綁到一起Use Case的定義n在一個workshop(專題討論會)上，14位主要的OO專家對Use Case有14個定義。n定義1：use case是對一個活動者活動者(actor)使用系統的一項功能時所進行的交互過程的一個文字描述序列。n定義2：The specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can p

9、erform by interacting with outside actors.用例的三種常用形式n摘要簡潔的一段概要，通常用于主成功場景n一般用于早期需求分析中n非正式非正式的幾個段落，覆蓋不同場景n一般用于早期需求分析中n詳述詳細編寫所有步驟及各種變化n以摘要的形式編寫了大量用例之后，詳細編寫其中少量重要的、高價值的用例摘要形式的用例n處理銷售n顧客攜帶所購商品到達收銀臺，收銀員使用POS系統記錄每件商品。系統連續顯示累計總額，并逐行顯示細目。顧客輸入支付信息，系統對支付信息進行驗證和記錄。系統更新庫存信息。顧客從系統獲得購物小票，然后攜帶商品離開。例：在線銀行系統的一些可能的用例：瀏

10、覽帳戶余額列出交易內容劃撥資金支付帳款登錄退出系統編輯配置文件買進證券賣出證券use case說明： Use case從用戶的角度獲取操作性需求，可以促進與用戶溝通，并不考慮系統內部對該功能的具體實現方式。 用例是對系統的功能進行清晰而一致的描述，代表系統中各個項目相關人員之間就系統的行為所達成的契約。 使用use case可以用來劃分系統與外部實體的界限，是OO系統設計的起點，是類、對象、操作的來源。 用例的一些特點：（1）用例描述了用戶提出的一些可見的需求；（2）用例可大可?。唬?）用例對應一個具體的用戶目標。爭論： 本質上，Use Case分析是一種功能分解功能分解(functional

11、 decomposition)(functional decomposition)的技術，沒有以對象觀點為中心，因而有人認為Use Case 分析只是OOA/OOD的先導性工作，并非OOA/OOD過程的一部分；但也有人視其為OOA/OOD的一環。 不管怎樣，Use Case是UML的一部份，Use Case是OO開發過程中的第一步。用例n為用例的邏輯流程建立文檔，詳細描述系統用戶的工作和系統本身的工作n用例的描述是獨立于實現方法的，描述系統“做什么”，而不是“怎么做”n1. 簡要說明n2. 前提條件n3. 事件流（主事件流、其他事件流、錯誤流 ）n4. 事后條件用例n用例的組成n簡要說明n與用

12、例相關的說明，描述該用例的作用n應包括執行用例的不同類型用戶和通過這個用例要達到的結果n前提條件n列出用例執行之前必須滿足的條件，例如另一個用例必須要先執行n后置條件n用例執行完畢后必須滿足的條件，例如必須執行另一個用例n事件流程（主事件流、其他事件流、錯誤流 ）n從用戶角度描述執行用例的具體步驟n包括用例的開始和結束、用例如何與參與者交互、用例的正常流程、主事件流的變體以及錯誤流用例n學生提交實驗結果的用例描述 student提交實驗結果用例用例名稱用例名稱提交實驗結果提交實驗結果參與者參與者學生學生假設假設學生完成了實驗學生完成了實驗前置條件前置條件學生已預約了實驗，并且完成實驗學生已預約

13、了實驗，并且完成實驗后置條件后置條件學生提交實驗結果后，系統數據庫存儲實驗結果學生提交實驗結果后，系統數據庫存儲實驗結果主事件流主事件流1.1.學生登錄系統；學生登錄系統；2.2.學生完成實驗結果；學生完成實驗結果；3.3.學生選擇該門實驗課程點擊學生選擇該門實驗課程點擊“上傳上傳”按鈕；按鈕；4.4.系統彈出上傳實驗結果菜單；系統彈出上傳實驗結果菜單；5.5.學生選擇自己的實驗結果文件夾進行上傳；學生選擇自己的實驗結果文件夾進行上傳；6.6.上傳成功之后系統提示提交成功；上傳成功之后系統提示提交成功；7.7.系統修改存儲學生是否提交實驗結果的字段。系統修改存儲學生是否提交實驗結果的字段。備選

14、事件流備選事件流1a.1a.非法用戶：提示用戶名或密碼錯誤；非法用戶：提示用戶名或密碼錯誤；5a.5a.學生的實驗結果文件夾未按要求命名，不是以學期和學號兩部分組成學生的實驗結果文件夾未按要求命名，不是以學期和學號兩部分組成：系統提示文件夾命名錯誤；：系統提示文件夾命名錯誤；5b.5b.學生所提交的實驗結果文件夾是空：系統提示文件夾為空；學生所提交的實驗結果文件夾是空：系統提示文件夾為空；6a.6a.在上傳實驗結果的過程中突然中斷：系統要求學生重新上傳實驗結果在上傳實驗結果的過程中突然中斷：系統要求學生重新上傳實驗結果；6b.6b.學生誤傳了實驗結果，把其他課程的實驗提交到該實驗課，可以進行學

15、生誤傳了實驗結果，把其他課程的實驗提交到該實驗課，可以進行刪除操作，重新上傳，重復刪除操作，重新上傳，重復3 37 7的操作；的操作；6c.6c.學生未按時提交實驗結果：系統提示已過期；學生未按時提交實驗結果：系統提示已過期；用例n只書寫“可觀測的”的n使用主動語句n句子必須以執行者或系統作為主語n每一句都要朝目標邁進n分支和循環n不要涉及界面細節用例用例用例用例用例用例用例Use Case的描述nuse case采用自然語言描述參與者與系統進行交互時雙方的行為，不追求形式化的語言表達。n描述用例時的原則：盡可能寫得“充分”，而不是追求寫得形式化，完整，漂亮。n作為OOA文檔的一個組成部分，U

16、se Case的描述應該有一定的規范格式。n在統一的標準出現之前，人們可以創造發明use case的不同表示形式，但至少在一個開發組織內部應該采用統一的格式。Use Case的描述用例的一個描述格式：用例的一個描述格式： ( (用例模板用例模板) )n用例名稱用例名稱。表明用戶的意圖或use case的用途，如“劃撥資金”。 n標識符標識符 可選可選 。唯一標識符，如 “UC1701”，在文檔的別處用標識符來引用這個用例。 n用例描述用例描述。概述用例的幾句話。n參與者參與者。與此用例相關的參與者列表。n優先級優先級。一個有序的排列，1代表優先級最高。n狀態狀態 可選可選 。用例的狀態，通常為

17、以下幾種之一：進行中、等待審查、通過審查或未通過審查。n前置條件前置條件。一個條件列表，如果其中包含條件，則這些條件必須在訪問用例之前得到滿足。 n后置條件后置條件。一個條件列表，如果其中包含條件，則這些條件將在用例完成以后得到滿足。n基本操作流程基本操作流程。描述用例中各項工作都正常進行時用例的工作方式 。 n可選操作流程可選操作流程。描述變更工作方式、出現異常或發生錯誤的情況下所遵循的路徑。n被泛化的用例被泛化的用例 可選可選 。此用例所泛化的用例列表。n被包含的用例被包含的用例 可選可選 。此用例所包含的用例列表。n被擴展的用例被擴展的用例 可選可選 。此用例所擴展的用例列表。 n修改歷

18、史記錄修改歷史記錄 可選可選 。關于用例的修改時間、修改原因和修改人的詳細信息。 n問題問題 可選可選 。與此用例的開發相關的問題的列表。 n決策決策 可選可選 。關鍵決策的列表，將這些決策記錄下來以便維護時使用。n頻率頻率 可選可選 。參與者訪問此use case的頻率。如用戶每日訪問一次或每月一次。例：用例模板n用例名稱用例名稱：處理訂單n標識符標識符：UC1701n用例描述用例描述：當一個訂單初始化或者被查詢的時候這個用例開始。它處理有關訂單的初始化定義和授權等問題。當訂單業務員完成了同一個顧客的對話的時候，它就結束了。n參與者參與者：訂單業務員n優先級優先級：1n狀態狀態：通過審查n前

19、置條件前置條件：訂單業務員登錄進系統n后置條件后置條件：下訂單；庫存數目減少 n基本操作流程基本操作流程：n1. 顧客來訂購一個吉他，并且提供信用卡作為支付手段。n2. .n可選操作流程可選操作流程：n顧客來訂購一個吉他，并且使用匯票的方式。n顧客來訂購一個風琴，并且提供信用卡作為支付手段。n顧客使用信用卡下訂單，但那張信用卡是無效的。n顧客來下訂單，但他想要的商品沒有存貨。n被泛化的用例被泛化的用例：無n被包含的用例被包含的用例：登錄 (UC1706)。n被擴展的用例被擴展的用例：無n修改歷史記錄修改歷史記錄：nRene Becnel, 定義基本操作流程, 2002/10/3 nRene B

20、ecnel, 定義可選操作流程, 2002/10/6用例描述的一些常見錯誤分析n在描述用例時易犯的錯誤包括：n只描述系統的行為，沒有描述actor的行為。n只描述actor的行為，沒有描述系統的行為。n設定對用戶界面的設計的要求。n過于冗長。n例1：下面是一個用例描述的片斷：Use Case: Withdraw Cash（提取現金）參與者：Customer主事件流：1. 儲戶插入ATM卡，并鍵入密碼。2. 儲戶按 “Withdrawal” 按鈕，并鍵入取款數目。3. 儲戶取走現金、ATM卡并拿走收據。4. 儲戶離開。上述描述中存在的問題：n只描述了參與者的動作序列，沒有描述系統的行為。n改進的

21、描述如下：Use Case: Withdraw Cash （提取現金）參與者: Account Holder主事件流：1. 通過讀卡機，儲戶插入ATM卡。2. ATM系統從卡上讀取銀行ID、帳號、加密密碼、并用主銀行系統驗證銀行ID和帳號。3. 儲戶鍵入密碼，ATM系統根據上面讀出的卡上加密密碼，對密碼進行驗證。4. 儲戶按“FASTCASH”按鈕，并鍵入取款數量，取款數量應該是5美元的倍數。5. ATM系統通知主銀行系統，傳遞儲戶帳號和取款數量，并接收返回的確認信息和儲戶帳戶余額。6. ATM系統輸出現金，ATM卡和顯示帳戶余額的收據。7. ATM系統記錄事務到日志文件。n例2：下面是一個用

22、例描述的片斷：Use Case: Withdraw Cash參與者: Customer主事件流：1. ATM系統獲得ATM卡和密碼。2. 設置事務類型為 Withdrawal3. ATM系統獲取要提取的現金數目。4. 驗證帳戶上是否有足夠儲蓄金額。5. 輸出現金，數據和ATM卡。6. 系統復位。上述描述中存在的問題：n只描述了ATM系統的行為，而沒有描述參與者的行為。這樣的描述很難理解，驗證和修改。n改進的描述同例1。n例3：下面是一個用例描述的片斷：Use Case: Buy Something參與者: Customer主事件流：1. 系統顯示“ID and Password”屏幕。2. 顧

23、客鍵入ID和密碼，然后按OK按鈕。3. 系統驗證顧客ID和密碼，并顯示“Personal Information”屏幕4. 顧客鍵入姓名、街道地址、城市、州、郵政編碼、電話號碼，然后按OK按鈕。5. 系統驗證用戶是否為老顧客。6. 系統顯示可以賣的商品列表。7. 顧客在準備購買的商品圖片上點擊，并在圖片旁邊輸入要購買的數量。選購商品完畢后按“Done”按鈕。8. 系統通過庫存輔助系統驗證要購買的商品是否有足夠庫存。.etc.上述描述中存在的問題：n對用戶界面的描述過于詳細，對于需求文檔來說，詳細的UI描述對獲取需求獲取需求并無幫助。n改進的描述可以如下所示：Use Case: Buy Some

24、thing參與者: Customer主事件流：1. 顧客使用ID和密碼進入系統。2. 系統驗證顧客身份。3. 顧客提供姓名、地址、電話號碼。4. 系統驗證顧客是否為老顧客。5. 顧客選擇要購買的商品和數量。6. 系統通過庫存輔助系統驗證要購買的商品是否有足夠庫存。. etc.n例4：下面是一個用例描述的片斷：Use Case: Buy Something參與者: user(或Customer)主事件流：1. 顧客使用ID和密碼進入系統。2. 系統驗證顧客身份。3. 顧客提供姓名。4. 顧客提供地址。5. 顧客提供電話號碼。6. 顧客選取商品。7. 顧客確定商品的數量。8. 系統驗證顧客是否為老

25、顧客。9. 系統打開到庫存系統的連接。10. 系統通過庫存系統請求當前庫存量。11. 庫存系統返回當前庫存量12. 系統驗證購買商品的數量是否小于庫存量。. etc.上述描述中存在的問題：n對用例的描述過于冗長，可以采用更為簡潔的描述方式，如合并類似的數據項（步驟3至步驟5），提供抽象的高層描述（步驟9至12）等。n改進的描述可以如下所示：Use Case: Buy Something參與者: user(或Customer)主事件流：1. 顧客使用ID和密碼進入系統。2. 系統驗證顧客身份。3. 顧客提供個人信息(包括姓名、地址、電話號碼), 選擇要購買的商品及數量。4. 系統驗證顧客是否為老

26、顧客。5. 系統使用庫存系統驗證要購買的商品數量是否少于庫存量。. etc.如何發現用例n選擇系統邊界n在許多情形下，系統邊界是顯而易見的n尋找主要參與者n參與者可以使用戶，外部的硬件或者另外一個系統n為每個參與者確定他們的目標n參與者-活動列表如何發現用例n定義用例n一般而言，為每一個用戶目標定義用例n定義用例需要交流和參與n領域專家的參與非常重要n迭代開發識別用例n業務語言而非技術語言識別用例n用戶觀點而非系統觀點識別用例n識別用例最好的方法就是從分析系統的參與者開始，考慮每個參與者是如何使用系統的。 n特定參與者希望系統提供什么功能n系統是否存儲、檢索信息，如果是，由哪個參與者觸發n當系

27、統狀態改變時，是否通知參與者n是否存在影響系統的外部事件n那個參與者通知系統這些事件識別用例n用例的“粒度”n最常犯錯誤把步驟當作用例n把執行者動作當作用例n把系統活動當作用例識別用例n用例的“粒度”： CRUDn警惕CRUD泛濫！n所有業務最終都會成為CRUD光CRUD能為actor提供價值嗎？識別用例n用例的“粒度”n一個用例背后可能隱藏著許多數據操作識別用例n用例的“粒度”：如果確實是純CRUDn如果CRUD不涉及復雜的交互，一個用例“管理”即可n不管是C、R、U、D，都是為了完成“管理”的目標n甚至很多種基本數據的管理都可以用一個用例表示識別用例n用例的“粒度”n也可以把包含復雜交互的

28、路徑獨立出去形成用例討論n登錄？討論n幾個登錄？5.1.4 用例間的關系 nUse Case除了和參與者有關聯(association)外，Use Case之間也存在著一定的關系(relationship)。包括：泛化(generalization)關系、包含(include)關系、擴展(extend)關系等。n也可以利用UML的擴充機制自定義Use Case間的關系。關聯關系n表示參與者用例之間進行通信。 n不同的參與者可以訪問相同的用例。 泛化關系n泛化泛化(generalization)(generalization)代表一般與特殊的關系。use case間的泛化關系與類之間的泛化關系（

29、繼承關系）類似。n子用例表示父用例的特殊形式。 n子用例從父用例處繼承行為和屬性，還可以添加行為或覆蓋、改變繼承的行為。泛化關系n泛化關系（Generalization）n如果系統中一個或多個用例是某一個一般用例的特殊化用例時，就應該使用用例的泛化關系，例如：包含關系n包含包含(Include)(Include)n一個用例可以簡單地包含其他用例具有的行為，并把它所包含的行為作為自身行為的一部分，這稱作用例間的包含關系n客戶用例可以簡單地包含提供者用例具有的行為，并把它所包含的用例行為作為自身行為的一部分 包含關系的例子：inclusion use casebase use case包含關系n包

30、含關系的特點n包含用例（客戶用例）執行，則被包含用例（提供者用例）必須執行n什么時候使用包含關系？n如果兩個以上的用例有大量一致的功能，則可以將這個功能分解到另一個用例中，其他用例可以和這個用例建立包含關系n一個用例的功能太多時，可以用包含關系建模成兩個以上的用例，降低用例的復雜度擴展關系n擴展擴展(extend)(extend)關系關系的基本含義與泛化關系類似，但是對于擴展Use Case有更多的規則限制，即基本的Use Case必須聲明若干“擴展點” (extension point)(extension point)，而擴展Use Case只能在這些擴展點上增加新的行為。n基礎用例提供擴

31、展點以添加新的行為。n擴展用例提供插入片段以插入到基礎用例的擴展點上。擴展關系n擴展關系的特點n基礎用例沒有擴展用例也是完整的用例n基礎用例被執行時，一般不會涉及擴展用例，只有特定的條件發生，擴展用例才可能被執行，這是與包含關系的差別UseCase的泛化、擴展、包含關系的比較 當處理正常行為的變型時，而且只是偶爾描述時，可以考慮只用泛化關系泛化關系。 如果需要重復處理兩個或多個Use Case時，可以考慮使用包含關系包含關系，實現一個基本Use Case對另一個Use Case的引用。 當描述正常行為的變型，而且希望采用更多的控制方式時，可以在基本Use Case中設置擴展點，使用擴展關系擴展

32、關系。小結：actor，usecase的關系(relationship)類型說明：可在usecase間建立關聯，但意義不是很明確。association關聯:actor和usecase之間的關系包含:usecase之間的關系includeextend擴展:usecase之間的關系generalization泛化:actor之間或usecase之間的關系關系類型說明表示符號5.2 用例圖建模技術n5.2.1 對語境建模n5.2.2 對需求建模5.2.1 對語境建模識別系統外部的參與者。將類似參與者組織成泛化的結構層次。在需要加深理解的地方，為每個參與者提供一個構造型。將參與者放入到用例圖中，并說

33、明參與者與用例之間的通信路徑。5.2.2 對需求建模 識別系統的外部參與者來建立系統的語境。考慮每一個參與者期望的行為或需要系統提供的行為。把這些公共的行為命名為用例。確定提供者用例和擴展用例。對這些用例、參與者和它們之間的關系建模。用注釋修飾用例。選修課管理系統用例圖用例圖n在UML中，一個用例模型由若干個用例圖用例圖(use case diagram)(use case diagram)描述。用例圖是顯示一組用例、參與者以及它們之間關系的圖。 例：金融貿易系統的用例圖。一個use case圖的例子financial trading system用例圖中的一些主要圖標AssociationG

34、eneralizationDependency說明：UML中不使用顏色來作為圖形語義的區分標記。注釋連接Realizeuse-case realizationextend use case注釋include use casen用例圖是表達用例和活動者及其之間關系的載體n用例圖是模型圖，用例圖可包含用例，活動者以及它們之間的關系n用例圖的用途是為軟件系統、軟件子系統、類的動態行為建模。它從兩個方面對其建模對象的內容進行描述，即：n描述它們的邊界n對它們進行需求分析用例的組織和用例圖用例的組織和用例圖n用例圖和用例關系在編寫用例工作中是次要的。用例是文本文檔。編寫用例意味著編寫文本。n繪制簡單的用

35、例圖，并與參與者-目標列表關聯。Use Case圖的建立步驟(1) 找出系統外部的參與者和外部系統，確定系統的邊界和范圍；(2) 確定每一個參與者所期望的系統行為；(3) 把這些系統行為命名為Use Case；(4) 使用泛化、包含、擴展等關系處理系統行為的公共或變更部分；(5) 編制每一個Use Case的腳本；(6) 繪制Use Case圖；(7) 區分主事件流和異常情況的事件流，可以把表達異常情況的事件流的Use Case畫成一個單獨的子Use Case；(8) 細化Use Case圖，解決Use Case間的重復與沖突問題。3 實例圖書館管理系統n3.1 確定系統涉及的總體信息n3.2

36、 確定系統的參與者n3.3 確定系統的用例n3.4 使用Rational Rose繪制用例圖的步驟n3.5 圖書館管理系統的用例圖3.1 確定系統涉及的總體信息n讀者：n借書n還書n書籍預定n查詢 3.1 確定系統涉及的總體信息n圖書館管理員：n書籍借出處理n書籍歸還處理n預定信息處理 3.1 確定系統涉及的總體信息n系統管理員：n增加書目n刪除或更新書目n增加書籍n減少書籍n增加讀者帳戶信息n刪除或更新讀者帳戶信息n書籍信息查詢n讀者信息查詢 3.2 確定系統的參與者n首先分析系統所涉及的問題領域和系統運行的主要任務：n分析使用該系統主要功能部分的是哪些人。n誰將需要該系統的支持以完成其工作。n系統的管理者與維護者。 3.2 確