2.1.1 系統邊界決定了參與者
參與者是由系統的邊界所決定的，如果我們所要定義的系統邊界僅限于ATM機本身，那么后臺服務器就是一個外部的系統，可以抽象為一個參與者。
如果我們所要定義的系統邊界擴大至整個銀行系統，ATM機和后臺服務器都是整個銀行系統的一部分，這時候后臺服務器就不再被抽象成為一個參與者。
值得注意的是，用例建模時不要將一些系統的組成結構作為參與者來進行抽象，如在ATM機系統中，打印機只是系統的一個組成部分，不應將它抽象成一個獨立的參與者；在一個MIS管理系統中，數據庫系統往往只作為系統的一個組成部分，一般不將其單獨抽象成一個參與者。
2.1.2 特殊的參與者――系統時鐘
有時候我們需要在系統內部定時地執行一些操作，如檢測系統資源使用情況、定期地生成統計報表等等。從表面上看，這些操作并不是由外部的人或系統觸發的，應該怎樣用用例方法來表述這一類功能需求呢？對于這種情況，我們可以抽象出一個系統時鐘或定時器參與者，利用該參與者來觸發這一類定時操作。從邏輯上，這一參與者應該被理解成是系統外部的，由它來觸發系統所提供的用例對話。
2.2 確定用例
找到參與者之后，我們就可以根據參與者來確定系統的用例，主要是看各參與者需要系統提供什么樣的服務，或者說參與者是如何使用系統的。尋找用例可以從以下問題入手（針對每一個參與者）：
綜合以上所述，ATM系統的用例圖可表示如下，
在用例的抽取過程中，必須注意：用例必須是由某一個主角觸發而產生的活動，即每個用例至少應該涉及一個主角。如果存在與主角不進行交互的用例，就可以考慮將其并入其他用例；或者是檢查該用例相對應的參與者是否被遺漏，如果是，則補上該參與者。反之，每個參與者也必須至少涉及到一個用例，如果發現有不與任何用例相關聯的參與者存在，就應該考慮該參與者是如何與系統發生對話的，或者由參與者確定一個新的用例，或者該參與者是一個多余的模型元素，應該將其刪除。
可視化建模的主要目的之一就是要增強團隊的溝通，用例模型必須是易于理解的。用例建模往往是一個團隊開發的過程，系統分析員在建模過程中必須注意參與者和用例的名稱應該符合一定的命名約定，這樣整個用例模型才能夠符合一定的風格。如參與者的名稱一般都是名詞，用例名稱一般都是動賓詞組等。
對于同一個系統，不同的人對于 參與者和用例都可能有不同的抽象結果，因而得到不同的用例模型。我們需要在多個用例模型方案中選擇一種"最佳"（或"較佳"）的結果，一個好的用例模型應該能夠容易被不同的涉眾所理解，并且不同的涉眾對于同一用例模型的理解應該是一致的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
