在使用用例以及用例建模的方法之前，我簡要介紹一下我的工程實踐專案：
首先，我所選的是乙個企業專案，題目為「物聯網組網智慧型分析引擎」；
其次，專案描述為：通過爬取現有物聯網裝置組網的資料或採用現場調研的方式，運用資料探勘方法對這些資料進行分析，為開發新型物聯網裝置提供參考與依據。資料分析結果可以包括成本、典型組網方式、開發周期、測試標準、交付週期、功能。
下面的內容主要分為兩個部分，一是敘述用例一些基本知識，二是針對於我的工程實踐專案，展示用例的分析以及建模的過程。
首先來看一下傳統的需求表述方式——"軟體需求規約"(software requirement specification)。
傳統的軟體需求規約基本上採用的是功能分解的方式來描述系統功能，在這種表述方式中，系統功能被分解到各個系統功能模組中，我們通過描述細分的系統模組的功能來達到描述整個系統功能的目的。
採用這種方法來描述系統需求，非常容易混淆需求和設計的界限，這樣的表述實際上已經包含了部分的設計在內。由此常常導致這樣的迷惑：系統需求應該詳細到何種程度？乙個極端就是需求可以詳細到概要設計，因為這樣的需求表述既包含了外部需求也包含了內部設計。在有些公司的開發流程中，這種需求被稱為"內部需求"，而對應於使用者的原始要求則被稱之為"外部需求"。
功能分解方法的另乙個缺點是這種方法分割了各項系統功能的應用環境，從各項功能項入手，你很難了解到這些功能項是如何相互關聯來實現乙個完成的系統服務的。
可以發現，按照傳統的需求表述方法來進行編碼，最終的成品往往與使用者的期望有很大偏差。
有沒有一種方法，是以使用者的視角來進行系統分析，又能夠極大程度提公升系統成品與使用者需求契合度呢？
有，這就是用例分析的方法：
用例方法完全是站在使用者的角度上（從系統的外部）來描述系統的功能的。在用例方法中，我們把被定義系統看作是乙個黑箱，我們並不關心系統內部是如何完成它所提供的功能的。用例方法首先描述了被定義系統有哪些外部使用者（抽象成為actor），這些使用者與被定義系統發生互動；針對每一參與者，用例方法又描述了系統為這些參與者提供了什麼樣的服務（抽象成為use case），或者說系統是如何被這些參與者使用的。所以從用例圖中，我們可以得到對於被定義系統的乙個總體印象。
與傳統的功能分解方式相比，用例方法完全是從外部來定義系統的功能，它把需求與設計完全分離開來。在物件導向的分析設計方法中，用例模型主要用於表述系統的功能性需求，系統的設計主要由物件模型來記錄表述。另外，用例定義了系統功能的使用環境與上下文，每乙個用例描述的是乙個完整的系統服務。用例方法比傳統的srs更易於被使用者所理解，它可以作為開發人員和使用者之間針對系統需求進行溝通的乙個有效手段。
那麼，明確了用例方法的好處，該如何建立乙個可靠的用例模型呢？
使用用例的方法來描述系統的功能需求的過程就是用例建模，用例模型主要包括以下兩部分內容：
一、用例圖(use case diagram)
確定系統中所包含的參與者、用例和兩者之間的對應關係，用例圖描述的是關於系統功能的乙個概述。
二、用例規約(use case specification)
針對每乙個用例都應該有乙個用例規約文件與之相對應，該文件描述用例的細節內容。
所謂的參與者是指所有存在於系統外部並與系統進行互動的人或其他系統。通俗地講，參與者就是我們所要定義系統的使用者。尋找參與者可以從以下問題入手：
這些問題有助於我們抽象出系統的參與者。
而對於本專案而言，回答這些問題也能夠幫助我更快更好地找到系統的參與者：
普通使用者使用系統所提供的功能與服務；
管理員使用者使用後台系統進行系統資訊的更新和維護。
找到參與者之後，我們就可以根據參與者來確定系統的用例，主要是看各參與者需要系統提供什麼樣的服務，或者說參與者是如何使用系統的。尋找用例可以從以下問題入手（針對每乙個參與者）：
在用例的抽取過程中，必須注意：用例必須是由某乙個主角觸發而產生的活動，即每個用例至少應該涉及乙個主角。如果存在與主角不進行互動的用例，就可以考慮將其併入其他用例；或者是檢查該用例相對應的參與者是否被遺漏，如果是，則補上該參與者。反之，每個參與者也必須至少涉及到乙個用例，如果發現有不與任何用例相關聯的參與者存在，就應該考慮該參與者是如何與系統發生對話的，或者由參與者確定乙個新的用例，或者該參與者是乙個多餘的模型元素，應該將其刪除。
視覺化建模的主要目的之一就是要增強團隊的溝通，用例模型必須是易於理解的。用例建模往往是乙個團隊開發的過程，系統分析員在建模過程中必須注意參與者和用例的名稱應該符合一定的命名約定，這樣整個用例模型才能夠符合一定的風格。如參與者的名稱一般都是名詞，用例名稱一般都是動賓片語等。
對於同乙個系統，不同的人對於參與者和用例都可能有不同的抽象結果，因而得到不同的用例模型。我們需要在多個用例模型方案中選擇一種"最佳"（或"較佳"）的結果，乙個好的用例模型應該能夠容易被不同的涉眾所理解，並且不同的涉眾對於同一用例模型的理解應該是一致的。
應該避免這樣一種誤解――認為由參與者和用例構成的用例圖就是用例模型，用例圖只是在總體上大致描述了系統所能提供的各種服務，讓我們對於系統的功能有乙個總體的認識。除此之外，我們還需要描述每乙個有例的詳細資訊，這些資訊包含在用例規約中，用例模型是由用例圖和每乙個用例的詳細描述――用例規約所組成的。rup中提供了用例規約的模板，每乙個用例的用例規約都應該包含以下內容：
用例規約基本上是用文字方式來表述的，為了更加清晰地描述事件流，也可以選擇使用狀態圖、活**或序列圖來輔助說明。只要有助於表達的簡潔明瞭，就可以在用例中任意貼上使用者介面和流程的圖形化顯示方式，或是其他圖形。如活**有助於描述複雜的決策流程，狀態轉移圖有助於描述與狀態相關的系統行為，序列圖適合於描述基於時間順序的訊息傳遞。
前面說完用例建模的種種好處，以及用例模型如何建立，但是不放在乙個具體的案例中，仍然比較枯燥。
那麼下面根據我的工程實踐專案，具體分析一下用例模型建立的過程，並給出最終用例圖。
前文已經分析過，本系統中的參與者主要分為兩類：即普通使用者與系統管理員。
按照參與者的角色不同，可以從中分析出不同的用例。
首先，對於普通使用者而言，能夠抽取出的用例有：
一、提供組網方案：使用者可以通過上傳新的方案，對於系統的初始資料進行完善；
二、篩選資料：按照使用者自身的要求，從系統已有的方案中選出所有的符合項；
三、視覺化展示：對於篩選出來的資料，使用者選擇按照圖和表的形式更好地呈現出來；
四、調整組網方案：當系統提供的解決方案不符合使用者預期，可以修改某些引數反饋給後台管理員；
五、比對組網方案：使用者可以自行選擇將兩種以上的組網方案進行比較，系統給出比對結果。
其次，對於系統管理員而言，所抽取出的用例有：
一、上傳組網方案：從可靠渠道得出組網解決方案，管理員將其同步至系統資料庫；
三、使用者管理：通過後台管理系統，對於系統註冊的使用者資訊進行處理；
用例的擴充套件主要包含兩個種類：包含關係（include）以及擴充套件關係（extend）。
普通使用者角色的用例所包含、擴充套件出的子用例有：
三、視覺化展示。包含：可以選擇柱狀圖、折線圖方式、餅狀圖等方式展示。
五、比對組網方案。包含：篩選符合要求的資料；分欄列出不同的方案；擴充套件：以演算法進行資料比對，並給出總體的結論。
管理員使用者角色的使用者所包含、擴充套件出的子用例有：
三、使用者管理。包含：使用者資訊的增加、刪除、修改、查詢。
首先是普通使用者的用例圖：
其次，系統管理員的用例圖：
本文主要**的是用例分析和建模的方法，重點在於明確建立使用者模型的步驟，能夠在之後的專案開發中形成乙個開發正規化。
所以本文最後給出的用例圖，也僅是在當前階段我對於本專案的需求某乙個切面的理解，日後可能還需要反覆分析、做諸多修改。
用例建模技巧
本文介紹了一些提高系統用例模型質量的技巧和技術。本文改編自 object primer 2nd edition 的第 6 章。從參與者的角度並以主動語態編寫用例。應該以主動語態 學生表明參加研習班意向 而不是被動語態 研習班意向被學生表明 來編寫用例。而且，應該從參與者的角度來編寫用例。畢竟，用例的...
用例建模（設計）
1 用例圖 定義 展示系統中參與者與用例之間的關係 用例圖是根據需求分析得到的，也是軟體設計中的第一張圖紙。描述了軟體系統的全部使用者 角色 和全部功能點 業務需求 以及他們之間的關係。也是軟體開發中最重要的一張圖紙。用例準則 用例描述了為參與者提供可測量的價值的乙個動作順序，如 提取資金，登記檔案...
用例建模Use Case Modeling
參與者是指存在於被定義系統外部並與該系統發生互動的人或其他系統，他們代表的是系統的使用者或使用環境。通訊關聯用於表示參與者和用例之間的對應關係，它表示參與者使用了系統中的哪些服務 用例 或者說系統所提供的服務 用例 是被哪些參與者所使用的。用例模型的四種關係 通訊關聯 1.關聯 建立參與者與用例通訊...