本節要講述用況的含義、用況與參與者之間的關系、用況間的關系以及如何使用它們描述系統功能。
一個用況(use case)是描述系統的一項功能的一組動作序列，這樣的動作序清單示參與者與系統間的互動，系統執行該動作序列要為參與者産生結果。
把用況表示成一個包含用況名字的橢圓，見圖34。
除了用圖符表示用況外，對用況還要描述其活動序列。對用況的描述，可使用自然語言、活動圖（見53節）和僞碼，也可以使用使用者自己定義的語言。無論用什麼形式，所描述的動作序列都應該足夠清晰，使得其他人員易于了解。書寫動作序列時，應該反映出用況何時開始和結束，參與者何時與用況互動，交換什麼内容，以及用況中的基本動作序列和可選動作序列等。
以超市銷售管理系統為例，圖35給出了實作系統收款功能的用況“收款”的描述。
上面的示例描述的是通常的收款情況，對于用信用卡付款和給予優惠等的描述可使用333節中講述的用況之間的關系。
圖35中，采用縮進文字的方式描述系統的行為，使得參與者與系統的行為容易區分。
還有一種常見的描述用況的方式，即區分用況的互動序列的基本流和可選流。例如，在一個圖書館借書系統中，有一個用況為“确認圖書證”。其基本動作序列（基本流）為：從業人員可以用掃描器識别借書證，也可以用鍵盤輸入借書證資訊；随後系統檢查輸入的資料是否合法；如果合法，系統顯示該客戶的借書情況。可選的動作序列（可選流）有多個：例如，1）如果輸入的資料不合法，系統就要求重新輸入；2）如果該使用者借書過多，則停止他再借書。
有的做法是把基本動作序列和可選的動作序列分開來寫。下面以atm 系統為例，采用基本流和可選流的方式，給出實作驗證使用者功能的用況“驗證使用者”的描述,見圖36。
驗證使用者
基本流：系統提示顧客輸入密碼，顧客按鍵輸入密碼。顧客按“确認”按鈕進行登入。系統确認是否有效。如果有效，系統承認這次登入，該用況結束。
可選流：顧客可以在按“确認”按鈕之前的任何時刻清除密碼，重新輸入新密碼。
可選流：如果顧客輸入了一個無效的密碼，用況重新開始。如果連續3 次無效，系統将取消整個登入事務，并在60 秒内阻止該顧客與atm 進行交易。
在運用用況時要注意以下幾點：
1）用況是一種類型，它是要被執行個體化執行的。當參與者執行個體使用由一個用況描述的一項系統功能時，該用況所描述的功能的全部或部分才發揮作用，其中經曆的動作序列是該用況的一個執行個體，即一個場景（scenario）。
2）用況描述中的一個動作應該描述參與者或系統要完成的一個互動步驟。
3）執行用況的一個動作序列要為參與者産生可觀察的結果，是指系統對參與者的動作要做出響應。例如，參與者向系統發一個指令，要求它做某件事；系統經過判斷，要求參與者提供進一步的資訊；參與者輸入資訊；系統進行處理，把結果報告給參與者。
4）用況描述的是參與者所使用的一項系統功能，該項功能應該相對完整，即應該保證用況是某一項功能的完整說明，而不能隻是其中的一個片段。這就要求一個用況描述的功能，既不能過大以至于包含過多的内容，也不能過小以至于僅包含完成一項功能的幾個小步驟。特别是，不能因為用況的功能過大，就像結構化分析方法把大的加工細分成下層的若幹較小的加工那樣，把用況也細分成下層的若幹較小的用況，因為用況是不分層的，不能說上層的用況是由下層的較小用況組成的。
5）對用況的描述隻強調用用況描述參與者和系統彼此為對方直接地做了些什麼事，不描述怎麼做，也不描述間接地做了些什麼。例如，對于一個成績管理系統的“成績統計”功能，可以在某個用況中做這樣的描述：“指定專業和年級，計算每個學生的各科成績，并以成績的高低為序列印成績表。”該功能包含很多計算細節，如要進行資料檢索、計算和排序等，但是這些細節并不在用況中描述。實際上，定義用況是在捕獲需求，此時分析員還沒有完全了解系統，還不能确定應該設立哪些成分以及成分之間的行為依賴關系，他們隻能從系統的最高層次（即最接近參與者的層次）來觀察和描述系統功能。對于參與者也隻描述它對系統的直接動作（例如“輸入某某資料”），不描述為了完成這個動作所進行的準備工作（例如為獲得輸入資料進行的調查、統計和計算）。
6）使用用況來可視化、詳述、構造和文檔化所希望的系統行為。盡管用況中描述的行為是系統級的，但在用況内所描述的互動中的動作應該是詳細的，準則是對用況的了解不産生歧義即可。若描述得過于綜合，則不易認識清楚系統的功能。
7）在用況描述中，由參與者首先發起互動的可能性較大，但有些互動也可能是由系統首先發起的。例如，系統在發現某些異常情況時主動要求操作員幹預，或者系統主動地向裝置發出操作指令。對于這樣的情況，參與者和系統之間的互動就是由系統首先發起的。
8）在描述一個用況時，要求用況應該描述出可能出現的各種情況，并進行概括，不要顧此失彼；描述應力求準确、清晰，但不要把雙方的行為混在一起。
一個參與者可以使用系統的多項功能，系統的一項功能也可以供多個參與者使用。在用況圖中，展現為一個參與者可以同多個用況互動，一個用況也可以同多個參與者互動。對于前一種情況，參與者根據與其互動的各用況分别扮演了不同的角色。
在uml中，把參與者與用況間的這種互動關系稱為關聯。若沒做具體的規定，互動是雙向的，即參與者能夠對系統進行請求，系統也能夠要求參與者采取某些動作。
把參與者和用況之間的關聯表示成參與者和用況之間的一條實線。若要明确地指出參與者和用況之間的通信是單向的，就在接收通信的那端的關聯線上加一個箭頭，用以訓示方向。圖37給出了一個參與者和用況之間的關聯示例。
圖37中的參與者“收款員”分别與用況“收款”和“檢查商品”間存在着關聯，參與者“統計員”與用況“收款”間存在着關聯。這意味着“收款員”的執行個體與“收款”和“檢查商品”的執行個體進行互動，“統計員”的執行個體與“收款”的執行個體進行互動。
不但在參與者和用況之間存在着關聯關系，在用況之間也可存在一定的關系。例如，在下述情況下，就需要考慮産生新的用況，并在用況間建立關系：
在一個用況中存在着幾處重複使用的動作序列。
在幾個用況中存在着重複使用的動作序列。
一個用況中的主要動作序列或分支動作序列過于冗長或複雜，而且分離它們有助于對需求進行管理和了解。
uml把用況之間存在的關系分為三種：包含、擴充和繼承。
1包含
在一個或幾個用況中經常存在着重複的互動行為。為了避免重複，可把重複的互動行為放在一個用況中，原有的用況（基用況）再引入該用況（供應者用況），這樣就在用況間建立了包含關系(include relationship)。原來用況中剩下的部分通常是不完整的，依賴于被包含部分才有意義，即供應者用況是包含它的基用況的功能的一部分。進一步地講，從基用況到供應者用況的包含關系表明：基用況在它内部說明的某一（些）位置上顯式地使用供應者用況的行為的結果。
可以把包含關系想象為基用況調用供應者用況（類似于子程式調用），基用況僅僅依賴供應者用況執行的結果，而不依賴供應者用況内部的結構。
建立包含關系的方法很簡單，即從具有共同活動序列的幾個用況中抽取出公共動作序列，或者在一個用況中抽取重複出現的公共動作序列，形成一個在幾處都要使用的附加用況。這樣，可以避免多次描述同一動作序列；當這個共同的序列發生變化時，這樣做就顯現出優勢，即隻需要在一個地方改動即可。
用一個敞開的帶箭頭的虛線（簡稱為虛箭線）表示用況之間的包含關系，該虛箭線從基用況指向被包含的用況（供應者用況），并在虛箭線上用include标記，見圖38。
具有包含關系的用況間并不一定是一對一的。實際上，一個用況可以包含多個用況，一個用況也可以被多個用況包含，甚至一個供應者用況還可以包含其他用況。
2擴充
在一個或幾個用況的描述中，有時存在着可選的描述互動行為的片段。在這種情況下，可以從用況中把可選的互動行為描述部分抽取出來，放在另一個用況（擴充用況）中，原來的用況（基用況）再用其進行擴充，以此來解決候選路徑的複雜性。這樣在描述基本動作序列的基用況和描述可選動作序列的擴充用況之間就建立了擴充關系(extend relationship)。進一步地講，從基用況到擴充用況的擴充關系表明：按基用況中指定的擴充條件，把擴充用況的動作序列插入到由基用況中的擴充點定義的位置。
基用況是可單獨存在的，但是在一定的條件下，它的行為可以被另一個用況的行為擴充。擴充用況定義一組行為增量，擴充用況定義的行為離開基用況可能是無意義的。注意，擴充用況中定義的各行為增量是可以單獨插入到基用況中的，這與包括關系中的供應者用況要作為一個整體被包含是不同的。
用虛箭線表示用況之間的擴充關系。該箭頭從擴充用況指向基用況（方向與包含關系相反），并用《extend》标記虛箭線，還可在《extend》附近寫上擴充條件，見圖39。
一個擴充點是用況中的一個位置，在這樣的位置上，如果擴充條件為真，就要插入擴充用況中描述的全部動作序列或其中的一部分，并予以執行。執行完後，基用況繼續執行擴充點下面的行為。如果擴充條件為假，擴充不會發生。
在一個用況中，各擴充點的名字是唯一的。可以把擴充點列在用況中的一個題頭為“擴充點”的分欄中，并以一種适當的方式（通常采用普通的文本）給出擴充點的描述（作為基用況中的标号）。圖310給出了一個示例。
在圖310中，用況“使用atm”有一個擴充點“選擇”。當用況“使用atm”的執行個體執行到達擴充點“選擇”所辨別的位置，且使用者選擇了幫助（即擴充條件{使用者選擇了幫助}為真）時，該用況就借助這個擴充點用用況“聯機幫助”來擴充自己。圖中的帶虛線的折角矩形用于表示注釋。
一個擴充用況可以擴充多個基用況，一個基用況也可以被多個用況擴充，甚至一個擴充用況自身也可以被其他擴充用況來擴充。
若要在基用況中表述可選的互動行為，就可以使用擴充關系。用這種方式把可選行為分離出來，通過擴充關系在擴充點使用它們。在對例外行為處理模組化時或對系統的可配置的功能模組化時，也可使用擴充關系。
3繼承
用況之間的繼承關系的含義如同類之間或參與者之間的繼承關系一樣。特殊用況不但繼承一般用況的行為，還可以增加行為或覆寫一般用況的行為。一般用況和特殊用況均有具體的執行個體，特殊用況的執行個體可以出現在一般用況的執行個體出現的任何位置。
用一個指向一般用況的帶有封閉的空心箭頭的實線來表示用況之間的繼承關系，見圖311。
在本小節的最後要強調的是，盡管用況間的三種關系都有助于複用，但從上面的講述中可以看出，它們之間是有差別的。
可以從如下幾個方面來捕獲用況。
1從參與者的角度捕獲用況
用況用于描述參與者和系統之間的一系列互動。參與者用況通常是由參與者啟動的，有時也需要在系統内部啟動的用況。 通常作為互動的發起者，使用系統來完成某種任務。識别參與者的責任是尋找參與者與系統互動理由的良好基礎。對所有的參與者，提出下列問題：
每個參與者的主要任務是什麼？
是什麼事件引發了任務，進而開始了參與者與系統進行互動？
在互動過程中，參與者是怎樣使用系統的服務來完成它們的任務的？例如，參與者是否将讀、寫或删除系統的什麼資訊？參與者是否該把系統外部的變化通知給系統？參與者是否希望系統把内部的變化通知給自己？參與者是否希望系統把預料之外的變化通知自己？
參與者參加了什麼本質上不同的互動過程？有些互動過程實際上是相同的或相似的，如果出現這些情況，需要合并用況或在用況間建立前述關系。
能完成特定功能的每一項活動明确地是一個用況。這些參與者參與的活動，通常會導緻其他活動，進而可識别出其他用況。
2從系統功能的角度捕獲用況
欲達到某種目的的一組動作序列要完成一項功能，這樣的動作序列要描述在一個用況中。通常，以用況中的互動動作為線索能發現其他用況。如下是一些指導：
全面地認識和定義每一個用況，要點是以窮舉的方式考慮每一個參與者與系統的互動情況，看看每個參與者要求系統提供什麼功能，以及參與者的每一項輸入資訊将要求系統做出什麼反應，進行什麼處理。
以窮舉的方式檢查系統的功能需求是否能在各個用況中展現出來。
一個用況描述一項功能，但這項功能不能過大。例如，把一個企業管理資訊系統粗略分為生産管理、供銷管理、财務管理和人事管理等幾大方面的功能，并分别把它們各作為一個用況，粒度就太大了。對于這種情況，應該把系統先劃分成子系統（見141節），再針對子系統建立用況模型。
一個用況應該完成一項完整的任務，通常應該在一個相對短的時間段内完成。如果一個用況的各部分被配置設定在不同的時間段，尤其還被不同的參與者執行，最好還是将各部分作為單獨的用況對待。
針對用況描述的基本流，要詳盡地考慮各種其他的情況。
考慮對例外情況的處理。
3利用場景捕獲用況
如果不能順利地确定一個用況的描述，可盡早使用人們熟知的“角色扮演”技術。該技術要求模組化人員深入到現場，通過觀察業務人員的現場工作(就好像自己是業務人員一樣)，深入地了解業務人員的工作，将具體的工作流程記錄下來，形成一個用來說明完成特定功能的動作序列，即一個場景。一個場景應該僅關注一次具體的業務活動，盡量要詳細。要确定出誰是扮演者，他們做了什麼事，他們做這些事的用意是什麼，或者是什麼原因要求他們做這些事。在描述一個場景時，還要指出其前驅和後繼場景，并要考慮可能發生的錯誤以及對錯誤的處理措施。通過模組化人員的角色扮演活動，找出各具體的場景；然後再把本質上相同的場景抽象為一個用況，如圖312所示。
從另一個方面看，用況的一次執行也形成了一個場景。用況的一次執行所經曆的動作序列可能為用況描述中的一部分。例如，在圖35所示的例子中，若某顧客在一次購物中購買的商品隻是一件，就不執行“輸入商品數量”這個動作，也不需要多次執行for循環的循環體。
通過從上述三個方面捕獲到的用況，有些是簡單的，隻有一個動作序列，有些要複雜一些，具有一些可選擇的互動路徑和多種例外的情況。一般而言，用況中含有一個在通常的情況下發生的基本動作序列，其餘的為可選的動作序列。
對于所捕獲的用況，需要按一定的格式對其進行描述，形成用況規約。按照國家電子資訊行業标準《面向對象的軟體系統模組化規範第三部分：文檔編制》[14]的要求，圖313給出了用于描述用況的模闆。
在描述用況時，并不要求把用況模闆中的每一項都寫出來，而是可以根據需要進行相應的取舍。根據用況圖，功能良好的模組化工具能夠把參與者以及包含、擴充和繼承關系中的用況提取到用況規約中。