用例圖。
組成：系統邊界。參與者。用例。關系。
參與者：Actor不是人，而是指參與用例時擔當的角色。
如果一個角色的操作是由另一個角色代理完成的，請建立該角色到另外角色之間的依賴。
怎樣識別參與者呢？
-
是誰向系統提供的信息呢.
-
誰向系統獲取信息。
-
誰操作系統。
-
系統使用哪些外部資源
-
系統是否和已經存在的系統交互
系統、子系統或類與外部的參與者（actor）交互的動作序列的說明，包括各種序列及出錯序列。
用例分析可以認為是對系統功能的分解。
怎樣確定用例的粒度呢？
用例的粒度（用例的大小）可大可小，一般一個系統易控制在20個左右。用例是系統級的抽象的描述，不是細化的（是做什么，非怎樣做）。對復雜系統可以划分為若干個子系統處理。
怎樣獲取用例呢？
參與者希望系統執行什么任務？
參與者在系統中訪問哪些信息（創建、存儲、修改、刪除等）？
需要將外界的哪些信息提供給系統？
需要將系統的那個事件告訴參與者？
如何維護系統？
UML中的四種關系。
關聯（association）
包含（include） 
擴展（extend）
泛化（generalization）
關聯關系
描述參與者和用例之間的關系。
用單向箭頭，表示誰啟動用例。
每個用例都有角色啟動，除了包含和擴展用例。
包含。
是指兩個用例之間的關系。其中一個用例（基本用例，base use case）的行為包含了另一個用例（包含用例，inclusion use case）的行為。
如果兩個以上用例有大量一致的功能，則可以將這個功能分解到另一個用例中，其他用力拉可以和這個用例建立包含關系。
上面的例子就是說查詢、提款和轉賬三個用例都有一個一致的功能，所以將這個功能提取出來為一個用例。且這三個用例和提取出的這個用例之間是包含的關系。
執行基本用例的時候也可以執行被包含的用例，被包含的用例也可以單獨執行。
如果一個用例的功能太多時，可以用包含關系建模成兩個或多個小用例
擴展。
也是指兩個用例之間的關系。一個用例可以被定義為基礎用例的增量的擴展，稱作為擴展關系。擴展關系是把新的行為插入到已有的用例中方法。基礎用例即使沒有擴展用例的執行不會涉及擴展用例，只有在特定的條件發生，擴展用例才被執行。
泛化（繼承）。
一個用例和其幾種情形的用例間構成泛化關系。往往父用例表示為抽象用例。
任何父用例出現的地方子用例也可出現。
1 對用例的描述。
-
用例圖：只能描述系統的大概功能，是一種視圖。
-
用例描述：更詳細地描述用例的功能。
2 用例描述的組成
用例名稱，簡要說明/描述，優先級，參與者，前置條件，基本事件流，其他事件流，擴展點，后置條件。
事件流：就是用例執行時，由一序列活動組成的控制流。
基本事件流：對用例中常規、預期路徑的描述。
擴展事件流：主要是對一些異常情況、選擇分支進行描述。
前置條件：在用例啟動時參與者（actor）與系統應置於什么狀態。
后置條件：用例結束時系統應置於什么狀態。
以上述的"新增書籍信息"為例，說明如何細化用例描述。
-
用例的概要描述
用例名稱：新增書籍（UCO1）
簡要說明：錄入新購書籍信息，並自動存儲建檔。
事件流：基本事件流和擴展事件流。
非功能需求
前置條件：用戶進入圖書管理系統。
后置條件：完成新書信息的存儲建檔。
擴展點：無
優先級：高（滿意度 5 ，不滿意度5 ）
-
詳細描述
基本事件流
-
圖書管理員向系統發出"新增書籍信息"請求。
-
系統要求圖書管理員選擇要增加的書籍是計算機類還是飛信計算接類
-
圖書管理員做出選擇后，顯示相應界面，讓圖書管理員輸入信息，並自動根據書號規則生成書號。
-
圖書管理員輸入書籍的相關信息，包括：書名、作者、出版社、ISBN號、開本。頁數、定價。是否有CD-ROM。
-
系統確認輸入的信息中書名沒有重名。
-
系統將所輸入的信息存檔建檔。
擴展事件流。
-
A 如果輸入的書名有重名現象，則顯示出重名的書籍，並要求圖書管理員選擇修改書名或取消輸入。
-
A（1）圖書管理員選擇取消輸入，則結束用例，不做存儲建檔工作。
-
A（2）圖書管理員選擇修改書名后，轉到A。
如下例所示建立用例模型。
有一個業務需求如下，要求我們為其構件一個用例圖。
1）系統可以供教師使用來為學生記錄成績。
2）系統根據需要創建報告卡。
-
系統允許用戶瀏覽記錄的成績。
首先這里面要問到的是：11）中教師可以記錄學生信息，這就是說教師可以錄入、修改和刪除學生信息了。22）中系統要創建報告卡，是誰來創建報告卡呢？這里就應該有權限的問題了，系統需要管理人員來來執行這項工作，另一個方面做系統的維護工作。報告卡創建后干什么？管理人員檢查其准確性之后，由教師來分發報告卡。33） 系統允許用戶瀏覽成績，是誰可以瀏覽成績呢？是學生和老師。
-
從中得到這個系統的參與者是：教師，學生，管理員。
主要用例：錄入成績。更新成績。生成報告卡。報告卡准確性。分發報告卡。瀏覽成績。
要區分用例的優先級。
首先是 ：記錄成績，瀏覽成績，更新成績，生成報告，檢查報告卡的准確性，分發報告卡。
細化每一個用例。
對"記錄成績"進行細化，下面是對該用例的主事件流。
-
首先是教師要確定錄入哪些學的成績。
-
系統中要確保學生在數據庫中。
-
教師說明記錄哪像作業的成績。
-
系統開始數據庫的一些事物。
-
系統為學生把作業加入到數據庫中。
-
教師輸入學生作業的成績。
-
系統核對輸入的成績是否符合正確的范圍和格式。
-
系統記錄作業的成績。
-
系統結束事物的處理。
-
系統提示教師成績已經記錄好。
從細分的用例中發現新的用例，並根據優先級重新排列。
機房收費系統的用例圖。
1、首先是分析系統中的角色（Actor）。
誰向系統提供信息？-----學生
誰從系統獲取信息？----學生、管理員、操作員、一般用戶
誰操作這個系統呢？--一般用戶、操作員、管理員。
誰維護這個系統呢？---管理員。
系統要使用的外部資源？---數據庫。
系統是否和已經存在的系統交互？---好像沒有。
從中找出這個系統的Actor---（學生、一般用戶、管理員、數據庫）
-
基本Use case。
找出的參與者希望系統執行什么任務？
學生---去注冊卡號，后充值，上機，下機，付錢，查看信息（查看自己的個人信息，上機信息，卡內的余額信息），不想用了就注銷卡號。（學生的需求是要通過系統用戶對系統的操作來完成的。所以學生和系統用戶這兩個角色之間是關聯關系。）
一般用戶—主要是用這個系統來管理學生上下機。可以登錄到系統中去，后學生刷卡上機，顯示上機的學生的記錄，顯示登錄時間，查看學生上機狀態，學生下機，顯示下機時間和消費金額，可以修改自己的密碼，查詢余額。
操作員---主要是用這個系統為學生進行注冊充值以及查詢一些信息。登錄到系統中去，可修改密碼，根據學生的要求使用系統來，注冊，充值，退卡，注冊后充值可以查看收取金額，學生基本信息維護，學生上機統計信息，最后退卡時，查看金額退還信息來退還相應的錢數。最后可以查看老師和自己的工作記錄。
管理員---登錄到系統中去，可以修改密碼以確保安全性。利用這個系統可以對學生的上下機情況查看。可以對一般用戶和操作員的工作記錄查看。
參與者在系統中訪問哪些信息（創建、存儲、修改、刪除等）？
參與者在系統中需要訪問
需要將外界哪些信息供給系統？
外界提供給本系統的信息是---學生信息、系統時間信息、系統用戶信息。
需要將系統的哪個事件告訴參與者？
……無……
如何維護系統？
管理員負責對系統的維護-----基本數據的設定。
用例圖如下所示：
學生和一般用戶的用例圖。
學生和操作員的用例圖。
學生和管理員用例圖所示：
