什麼是UML用例圖（UCD），何時應該使用它？
UML用例圖可用於以水平方式描述系統的功能。也就是說，UCD不僅僅代表系統各個功能的細節，還可以用來顯示其所有可用功能。但值得注意的是，UCD與序列圖或流程圖根本不同，因爲它們不會嘗試表示系統操作和子操作應執行的次序或次數。本常見問題解答中有許多圖形示例; 你可能想看看它們以熟悉它們的外觀。
UCD只有4個主要元素：您描述的系統與之交互的角色，系統本身，用例或系統知道如何執行的服務，以及表示這些元素之間關係的線。
您應該使用UCD從上到下的角度來表示系統的功能（也就是說，系統的功能很明顯，但所有描述都處於非常高的水平。稍後可以將更多詳細信息添加到圖表中闡明系統行爲中的有趣點。）
示例： UCD非常適合描述可以使用數據庫系統完成的所有事情的任務（所有可能使用它的人員（管理員，開發人員，數據輸入）人員。）
您不應該使用UCD來表示異常行爲（發生錯誤時）或嘗試說明爲完成任務必須執行的步驟序列。使用序列圖顯示這些設計功能。
示例： UCD不太適合描述TCP / IP網絡協議，因爲有許多異常情況，分支行爲和條件功能（當數據包丟失或延遲時會發生什麼，連接何時死亡？）
你怎麼知道演員在UCD中是誰？
在Action / Response表中工作時，對actor進行操作非常簡單：行爲出現在“Actor's Actions”列中的實體是actor，其行爲出現在“System's Response”列中的實體是系統中的組件。
如果您使用非正式敘述，序列圖或場景描述，則actor通常是那些行爲無法控制或更改的實體（即，不是您正在構建或描述的系統的一部分的代理。）最明顯的演員候選人是系統中的人; 除非在極少數情況下，您所描述的系統實際上是一個人爲過程（例如與員工應該遵循的客戶打交道的具體方法），您必須與之互動的人才都是演員。如果您的系統與其他系統（數據庫，由其他人維護的服務器，遺留系統）進行交互，您最好將這些視爲演員，因爲您不想描述他們的行爲。
例： 在添加新的數據庫系統來管理公司的財務時，您的系統可能必須與現有的庫存管理軟件進行交互。由於您沒有編寫此軟件，不打算替換它，只使用它提供的服務，因此該系統成爲一個actor是有意義的。
你怎麼知道在“系統”框中輸入什麼？
系統框僅出現在頂層圖上（請記住，典型的UML用例描述將由許多圖表和子圖組成），並且應包含用例橢圓，一個用於系統提供的每個 頂級服務對其演員。任何一種內部行爲，你的系統可能有一個只能使用該系統的其他部分應該不會出現在系統框。考慮這些頂級服務的一種有用方法如下：如果用例表示頂級服務，那麼與其交互的參與者在單個會話中僅請求您的系統服務是有意義的（無論何種意義上，“會話”在您的系統中都是可理解的。）
示例：在下圖中，我們想要表示相機的用例。假設我們選擇“Open Shutter”，“Flash”和“Close Shutter”作爲頂級用例。當然這些都是相機所具有的行爲，但沒有攝影師會拿起相機，打開快門，然後放下它，對當天的攝影時間感到滿意。要認識到的重要一點是，這些行爲不是孤立進行的，但相當一部份更高層用的情況下，“拍照”的。（請注意，攝影師在使用相機的會話期間只拍攝一次“拍照”確實有意義。） 
我的圖表中的演員有互動。我該如何代表他們？
如果系統中的actor之間存在交互，則無法在與系統相同的圖表中表示這些交互。您可以做的是繪製一個單獨的UCD，將其中一個演員本身視爲系統，將原始系統（以及其他演員）視爲此新圖表上的演員。
例： 假設您想要繪製用戶，Web瀏覽器和它所聯繫的服務器之間的交互圖。由於圖表上只能有一個系統，因此必須選擇一個明顯的“系統”，例如服務器。然後你可能會試圖在演員之間繪製交互線，但這是一個問題，因爲不清楚交互意味着什麼，所以在這裏展示它沒有幫助。更有用的解決方案是繪製兩個圖表，顯示所有交互，如下所示。 
我試圖表示系統執行的一系列操作。我該怎麼做？
使用UML用例圖，你不能。UCD應該是一種自上而下的，橫向的功能描述，而不是一種逐行的行爲解釋。在大多數情況下，嘗試使用用例圖表示操作序列並不是一個好主意。您應該使用序列圖或傳統流程圖。（可以用UCD表示簡單的分支條件，如下所述，但是你應該謹慎使用這種技術，因爲它可以使圖表不可讀。）
UML用例圖與傳統流程圖有何不同？
如上所述，UCD以自上而下的方式表示功能，而流程圖以線性，基於時間的方式表示行爲。而且，你開發它們的方式是完全不同的。
示例:(此文本引用下圖。）構建UCD時，初始步驟是識別所有頂級行爲。一旦你完成了這個（不是一個非常棘手的過程），你已經描述過，至少在高級方面，系統知道如何做的所有事情。然後，您可以繼續你的用例分解成更用例來添加細節 使用由頂級用例組成。但是，在開發的每個階段，您的UCD都是對系統功能的完整描述：它可能缺乏細節，但它不會缺少功能集元素。如果在項目的整個生命週期中添加或刪除功能或行爲，則需要進行的更改範圍與系統本身的更改範圍和模型的成熟度成正比。這很有用，因爲這意味着當你的模型非常年輕（只繪製高級圖表）時，對系統進行徹底的更改並不需要投入大量的工作。但是，在完成繪製之前，流程圖無法正確描述系統，即使這樣，系統中的微小更改也會導致流程圖的重新修改。一般來說， 
我何時使用使用箭頭？
的用途箭頭（或使用邊緣，因爲它會在傳統的圖形理論聯繫被調用）從用例X另一種用途如果Y繪製以指示總是進行X的過程涉及進行Y至少一次（雖然它可能涉及做很多次，“至少一次”是這個符號保證的唯一關係。）這個符號可以稱爲聚合 運算符，因爲它表示給定的用例是一個聚合（由部分組成），其組成部分是它使用的用例。如果某個用例使用其他幾個，這意味着所有組件用例必須在完成聚合用例的過程中完成，儘管UCD中沒有規定完成這些用例的順序。考慮使用箭頭的一種簡短的記憶方式是它可以被讀取X使用Y意味着“X 有一個 Y”作爲其行爲的一部分。
示例：假設您要將詳細信息添加到下面顯示的圖表中，表示航空公司預訂系統。首先，您將爲頂級服務創建單獨的圖表，然後添加構成頂級服務的新用例。從“登記乘客”到“稱行李”，從“登機乘客”到“指定座位”有一個使用邊緣; 這表明了爲了登記乘客，必須對行李進行稱重並且必須分配座位。類似地，該圖表示爲了向系統添加預留，必須檢查可用空間並且必須記錄乘客的信息。您可以想象進一步打破這些用例以顯示更多細節。 
我什麼時候使用延伸箭頭？
該擴展箭頭（或延伸邊緣）從用例X的使用如果Y繪製，以表明進程X是相同類型的特殊情況下的行爲更普遍的過程Y.你會在情況下使用您的系統有許多用例（進程），它們都有一些共同的子任務，但是每個用例都有不同之處，這使得你無法將它們全部集中到同一個用例中。
例：假設您想在下面顯示的圖表中添加細節，代表航空公司預訂系統。具體來說，你想要展示的是，並非飛機上的所有座位都是完全相同的（一些窗戶和一些過道座位），有時乘客會表示偏好這些類型的座位而不是另一個座位。但當然，他們不能馬上給予他們的偏好，因爲他們想要的座位可能無法使用。因此，分配靠窗座位的過程涉及檢查靠窗座位的可用性，而指定過道座位的過程涉及檢查過道座位的可用性。但即使這些過程不同，它們在許多其他方面也非常相似，所以忽略它們的相似之處是沒有意義的。幸好，這兩個過程都擴展了一個共同的，更一般的過程（分配席位。） 
使用和延伸有什麼區別？
考慮這些圖元素的最佳方法可能如下：
- “X 使用 Y”表示任務“X” 具有 子任務“Y”; 也就是說，在完成任務“X”的過程中，任務“Y”將至少完成一次。
- “X extends Y”表示“X” 是與“Y”相同類型的任務，但“X”是執行“Y”的特殊，更具體的情況。也就是說，做X很像做Y，但X有一些額外的進程，超出了爲了完成Y必須完成的事情。
示例：表示爲了成功“辦理登機手續”，您必須按照某種順序“稱重行李”和“分配座位”一些次數。但關鍵是，在用例被認爲完成之前，用例使用的所有UC必須完成。一旦你意識到有幾種類型的座位分配，你可能會試圖使用下面的使用邊緣繪製圖表 ，但這沒有意義：這個圖表說，爲了分配一個座位你必須分配窗戶座位和乘客的過道座位。但是，不要害怕; 這種情況由extends 關係正確處理。使用extends關係（如下圖所示），我們可以表達出來分配座位有兩種方式：分配一個靠窗的座位並指定一個過道座位，但在爲乘客分配一個座位的過程中只需要完成一個。 
我想描述的場景分爲幾種可能的結果，或者有一些錯誤條件。如何用Use Case Diagrams表示？
表示故障和分支條件通常最好使用序列圖或流程圖完成，但是當不清楚用例圖是否合適時，存在一些灰色區域情況。根據經驗：如果在用例圖中表示分支操作，則必須添加更多用例橢圓，並且生成的圖表混亂或混亂，請考慮使用不同的圖表樣式。
話雖如此，有可能用UCD表示簡單的分支行爲，儘管我想再次強調UCD不是流動圖。這是通過認識到如果您嘗試表示的用例或進程可能具有兩個顯着不同的結果（例如，成功和失敗），那麼這意味着您確實有兩個不同的用例：一個用於進程成功，進程失敗。當然，這兩個用例的相關之處在於它們都是 原始用例的擴展，因此您將使用從其擴展的兩個分支繪製原始用例。我認爲這幾乎是濫用延伸的含義邊緣，因爲它實際上並沒有在這裏用來表示用例的分類（這是它的目的），而是利用UCD風格的黑客流程圖行爲的關係的特定抽象定義。再次，謹慎使用這項技術; 它可以快速製作一個無法比擬的圖表。
例：假設我們想要表示普通CD播放器的用例。當一切順利時，CD播放器縮回CD所在的托盤，讀取並開始播放。（此行爲的用例如下所示。頂級圖表已被省略。）不幸的是，即使托盤中沒有CD，某些用戶也會命令系統播放CD。因此，我們有一個失敗的條件，系統必須做除了播放CD之外的其他事情（即，提示用戶提供CD）。爲了表示這一點，我們用一些額外的用例修改了法線圖，其中存在CD已經過 驗證。播放CD 的行爲擴展了驗證CD存在的行爲，因爲它是 特殊情況驗證CD存在CD 的存在。驗證CD存在的另一個特例是這樣做並且CD 不存在，因此提示用戶輸入CD。我將最後一次說這種擴展的使用有點觸及，但是當這種行爲的數量很少時，它是表達單個用例的多個行爲的優雅方式。 