提到uml中的用例，很多人可能都會覺得很熟悉經常聽說。如果問一句什麼是用例，很多的回答就是用例圖中的乙個橢圓。用例僅僅是用例圖中的乙個橢圓嗎？當然不是，那麼用例的本質是什麼呢？
1、用例發展史
為了搞清用例的本質我們首先了解一下用例技術的發展史。uml中的用例概念是由有uml之父ivar jacobson在60年代提出。後來alistair cockburn從ivar jacobson那裡學習了用例，並且結合自己的實踐對用例進行了繼承和發展，提出了「基於目標的用例」。在uml形成的時候，用例uml作為乙個重要的部分被納入了uml。用例被認為是第二代物件導向技術的標誌。
2、用例的本質
用例的本質並不是uml中的乙個橢圓符號，而是描述系統中各個相關人員之間就系統的行為所達成的契約，它應用功能分解的方法，站在系統之外，使用文字表達系統的功能性需求。在uml中為了視覺化使用乙個橢圓來表示，用例的具體內容通過使用用例模板來表達。用例技術是迄今為止最為深刻、準確和有效的系統功能需求描述方法。
用例技術有如下的一些特點：用例是一種半角化的方式，它不是使用一種形式化的語言，而是使用自然語言來描述需求。但是它卻明確的提出了角色和用例的概念，以及角色和用例進行通訊的規則，以及用例模板的主要內容。嚴格的結構和形式會使需求變得生硬、無用，沒有結構和形式的需求又不易交流。這種半形式結構使得人們的創造性得以發揮，也使得系統的終端使用者能夠輕鬆的閱讀；在每個用例和所有的描述層次中，都描述了錯誤時的系統處理。系統複雜性大部分都是處理錯誤情況，這樣能夠在需求分析階段檢測出相關的問題進行分析，而不是在以後的階段中發現。這是我在使用用例過程中最為深刻的一點，我們在寫需求的時候僅僅描述正確的使用者需求，很少提及錯誤情況；用例提供了可以在其上處理其他專案資訊的骨架，從而實現用例驅動。
3、用例與需求
很多人使用用例描述需求後，就會產生疑問用例和需求到底是什麼關係。用例是需求，但並不是系統的全部需求，用例描述的只是功能性方面的需求。不要試圖把所有的需求都以用例的方式表示出來。有些人認為用例可以表示所有的系統需求，因此用uml來表示那些事實上很難用用例表示的需求，這樣做是不對的。用用例分析需求有如下的特點：
1. 用例從使用系統的角度描述系統中的資訊，即站在系統外部**系統的功能，而不考慮系統內部對該功能的具體實現方式。
2. 用例描述了使用者提出的一些可能需求，對應乙個具體的使用者目標，用例可以促進與使用者溝通、理解正確的需求，同時也可以用來劃分系統與外部實體的界限，是物件導向系統設計的起點，是類、物件、操作的**。
3. 用例是對系統行為的動態描述。
4、用例驅動
可能很多人都聽說過資料驅動、用例驅動這樣的字眼。為什麼說使用uml進行軟體開發是用例驅動的？因為用例代表系統中各個相關人員之間就系統的行為所達成的契約，乙個軟體的開發就是從分析這些工作開始的。軟體的開發過程分為需求分析、設計、實現、測試等階段，用例把所有這些都**再一起，用例分析的結果也為**系統的開發時間和預算提供依據，保證專案的順利進行，從各個方面綜合起來講軟體開發是用例驅動的。
5、用例模板
用例圖只是簡單地視覺化描述系統，我們還需要對用例進行詳細的說明。為了明確的描述用例我們需要乙個用例模板，但是至今並沒有統一的用例模板。用例模板的內容一般包括：簡要描述、前置條件、後置條件、基本事件流、備選事件流等等。
簡要描述：對用例的角色、目的的簡要描述。
前置條件：執行用例之前系統必須要處於的狀態，或者要滿足的條件。
後置條件：用例一旦執行後系統所處的狀態。
基本事件流：描述該用例的基本流程，指每個流程都「正常」運作時所發生的事情，沒有任何備選流而只有最有可能發生的事件流。
備選事件流：表示這個行為或流程是可選的或備選的，並不是總要總要執行它們。
下面是乙個用例模板的示例：
用例：《編號》《名稱》
特徵資訊：
用例在系統中的目標（用例目標描述）
範圍（當前考慮的是哪個系統）
級別（概要任務/首要任務/子功能）
前提條件（用例執行前系統用具有的狀態）
成功後繼條件（用例成功執行後應具有的狀態）
失效後繼條件（用例沒有完成目標的狀態）
首要角色（與該用例關聯的首要角色）
觸發（啟動該用例執行的系統動作）
主要步驟：
《步驟編號》《動作描述》
擴充套件：《有變化情況的步驟編號》《條件》:《動作或另外乙個用例》
變異：《步驟或變化編號》《變異列表》
優先順序（該用例對於系統組織的關鍵程度）
效能目標（該用例的執行時間耗費）
頻度（該用例被執行的頻度）
從屬用例：（可選）
下屬用例：
與首要角色的聯絡渠道（包括互動式、靜態檔案、資料庫等）
公開問題：（可選）
列出關於該用例的未解決的問題
用例的本質
提到uml中的用例，很多人可能都會覺得很熟悉經常聽說。如果問一句什麼是用例，很多的回答就是用例圖中的乙個橢圓。用例僅僅是用例圖中的乙個橢圓嗎？當然不是，那麼用例的本質是什麼呢？1 用例發展史 為了搞清用例的本質我們首先了解一下用例技術的發展史。uml中的用例概念是由有uml之父ivar jacobs...
業務用例與系統用例的區別
1 業務用例就是要完成的業務，系統用例是系統要做的事情，兩者的域不同。2 業務建模主要描述了該專案涉及的所有業務，需求模型主要是描述為了滿足業務需求系統要做什麼，因此，需求模型與業務模型相比，它描述的只是業務模型的乙個子集。3 比方說我們設計乙個自動提款機系統，它可以滿足使用者的取款 改密 查詢等需...
業務用例和系統用例
拋開前一篇文章談的總體思路，我們今天來談一下需求分析工作實質性的做些什麼。在這裡，我們，將主要關注於分析層面，也即 uml中的用例模型和邏輯模型。在這裡要申明的是邏輯模型並不能完全算需求分析階段的工作，因為它包含了設計模型的概念，但是我又把它歸納了一塊到需求分析階段，原因在於邏輯模型中存在了業務物件...