我的工程實踐是印章檢測專案，屬於計算機視覺中的目標檢測方向，在對用例建模之前，我先對用例建模進行一些相關的介紹：
我們首先來看一下傳統的需求表述方式-"軟體需求規約"(software requirement specification)。傳統的軟體需求規約基本上採用的是功能分解的方式來描述系統功能，在這種表述方式中，系統功能被分解到各個系統功能模組中，我們通過描述細分的系統模組的功能來達到描述整個系統功能的目的。乙個典型的軟體需求規約可能具有以下形式：
這樣的表述實際上已經包含了部分的設計在內。由此常常導致這樣的迷惑：系統需求應該詳細到何種程度？乙個極端就是需求可以詳細到概要設計，因為這樣的需求表述既包含了外部需求也包含了內部設計。在有些公司的開發流程中，這種需求被稱為"內部需求"，而對應於使用者的原始要求則被稱之為"外部需求"。
參與者(actor)
參與者是指存在於被定義系統外部並與該系統發生互動的人或其他系統，他們代表的是系統的使用者或使用環境。
用例(use case)
用例用於表示系統所提供的服務，它定義了系統是如何被參與者所使用的，它描述的是參與者為了使用系統所提供的某一完整功能而與系統之間發生的一段對話。
通訊關聯(communication association)
通訊關聯用於表示參與者和用例之間的對應關係，它表示參與者使用了系統中的哪些服務（用例），或者說系統所提供的服務（用例）是被哪些參與者所使用的。
這大三種模型元素在uml中的表述如下圖所示。
用例圖使我們對系統的功能有了乙個整體的認知，我們可以知道有哪些參與者會與系統發生互動，每乙個參與者需要系統為它提供什麼樣的服務。用例描述的是參與者與系統之間的對話，但是這個對話的細節並沒有在用例圖中表述出來，針對每乙個用例我們可以用事件流來描述這一對話的細節內容。
使用用例的方法來描述系統的功能需求的過程就是用例建模，用例模型主要包括以下兩部分內容：
用例圖(use case diagram)
確定系統中所包含的參與者、用例和兩者之間的對應關係，用例圖描述的是關於系統功能的乙個概述。
用例規約(use case specification)
針對每乙個用例都應該有乙個用例規約文件與之相對應，該文件描述用例的細節內容。
在用例建模的過程中，我們建議的步聚是先找出參與者，再根據參與者確定每個參與者相關的用例，最後再細化每乙個用例的用例規約。
參與者是由系統的邊界所決定的，如果我們所要定義的系統邊界僅限於atm機本身，那麼後台伺服器就是乙個外部的系統，可以抽象為乙個參與者。
值得注意的是，用例建模時不要將一些系統的組成結構作為參與者來進行抽象，
找到參與者之後，我們就可以根據參與者來確定系統的用例，主要是看各參與者需要系統提供什麼樣的服務，或者說參與者是如何使用系統的。尋找用例可以從以下問題入手（針對每乙個參與者）：
綜合以上所述，目標檢測系統的用例圖可表示如下，
在用例的抽取過程中，必須注意：用例必須是由某乙個主角觸發而產生的活動，即每個用例至少應該涉及乙個主角。如果存在與主角不進行互動的用例，就可以考慮將其併入其他用例；或者是檢查該用例相對應的參與者是否被遺漏，如果是，則補上該參與者。反之，每個參與者也必須至少涉及到乙個用例，如果發現有不與任何用例相關聯的參與者存在，就應該考慮該參與者是如何與系統發生對話的，或者由參與者確定乙個新的用例，或者該參與者是乙個多餘的模型元素，應該將其刪除。
視覺化建模的主要目的之一就是要增強團隊的溝通，用例模型必須是易於理解的。用例建模往往是乙個團隊開發的過程，系統分析員在建模過程中必須注意參與者和用例的名稱應該符合一定的命名約定，這樣整個用例模型才能夠符合一定的風格。如參與者的名稱一般都是名詞，用例名稱一般都是動賓片語等。
用例方法完全是站在使用者的角度上（從系統的外部）來描述系統的功能的。在用例方法中，我們把被定義系統看作是乙個黑箱，我們並不關心系統內部是如何完成它所提供的功能的。用例方法首先描述了被定義系統有哪些外部使用者（抽象成為actor），這些使用者與被定義系統發生互動；針對每一參與者，用例方法又描述了系統為這些參與者提供了什麼樣的服務（抽象成為use case），或者說系統是如何被這些參與者使用的。所以從用例圖中，我們可以得到對於被定義系統的乙個總體印象。
與傳統的功能分解方式相比，用例方法完全是從外部來定義系統的功能，它把需求與設計完全分離開來。在物件導向的分析設計方法中，用例模型主要用於表述系統的功能性需求，系統的設計主要由物件模型來記錄表述。另外，用例定義了系統功能的使用環境與上下文，每乙個用例描述的是乙個完整的系統服務。用例方法比傳統的srs更易於被使用者所理解，它可以作為開發人員和使用者之間針對系統需求進行溝通的乙個有效手段。
在rup中，用例被作為整個軟體開發流程的基礎，很多態別的開發活動都把用例作為乙個主要的輸入工件(artifact)，如專案管理、分析設計、測試等。根據用例來對目標系統進行測試，可以根據用例中所描述的環境和上下文來完整地測試乙個系統服務，可以根據用例的各個場景(scenario)來設計測試用例，完全地測試用例的各種場景可以保證測試的完備性。
用例建模技巧
本文介紹了一些提高系統用例模型質量的技巧和技術。本文改編自 object primer 2nd edition 的第 6 章。從參與者的角度並以主動語態編寫用例。應該以主動語態 學生表明參加研習班意向 而不是被動語態 研習班意向被學生表明 來編寫用例。而且，應該從參與者的角度來編寫用例。畢竟，用例的...
用例建模（設計）
1 用例圖 定義 展示系統中參與者與用例之間的關係 用例圖是根據需求分析得到的，也是軟體設計中的第一張圖紙。描述了軟體系統的全部使用者 角色 和全部功能點 業務需求 以及他們之間的關係。也是軟體開發中最重要的一張圖紙。用例準則 用例描述了為參與者提供可測量的價值的乙個動作順序，如 提取資金，登記檔案...
用例建模Use Case Modeling
參與者是指存在於被定義系統外部並與該系統發生互動的人或其他系統，他們代表的是系統的使用者或使用環境。通訊關聯用於表示參與者和用例之間的對應關係，它表示參與者使用了系統中的哪些服務 用例 或者說系統所提供的服務 用例 是被哪些參與者所使用的。用例模型的四種關係 通訊關聯 1.關聯 建立參與者與用例通訊...