用例建模簡介
用例建模是uml建模的一部分，它也是uml裡最基礎的部分。用例建模的最主要功能就是用來表達系統的功能性需求或行為。用例圖重點描述使用者需求。 它描述需求、使用者和主要元件之間的關係。 它不會詳細描述使用者需求；在可鏈結到每個用例的其他關係圖或文件中可詳細描述這些需求。用例圖是uml的九個圖中較為重要和常用的一種圖。常常用於軟體開發的需求分析階段，也能用於軟體的系統測試階段。簡單的來說，用例圖是描述系統的外部檢視，為了搞清某個專案的大概需求，我們往往要問兩個問題，
1． 這個系統有什麼用？有哪些人參與?
2． 這些人通過這個系統能做些什麼事？
通過這兩個問題，一般就能比較清楚地表達系統的需求了，用例圖就是用來回答這兩個問題的，它能從比較清晰的角度來表達系統的需求，而且不涉及到技術用語。
用例建模可分為用例圖和用例描述。
用例圖由參與者（actor）、用例（use case）、系統邊界、箭頭組成，用畫圖的方法來完成。
用例描述用來詳細描述用例圖中每個用例，用文字文件來完成。
1． 參與者(actor)
在乙個系統開發前，我們必定首先要確定系統的使用者，系統的使用者就是系統的參與者。除此以外，我們還會想想我們開發的系統與其他的系統有什麼關聯？因此，系統的參與者可分為兩類，一類是人，包括系統的使用者、維護者等，另外一類是其他系統。
參與者不是特指人，是指系統以外的，在使用系統或與系統互動中所扮演的角色。因此參與者可以是人，可以是事物，也可以是時間或其他系統等等。還有一點要注意的是，參與者不是指人或事物本身，而是表示人或事物當時所扮演的角色。比如小明是圖書館的管理員，他參與圖書館管理系統的互動，這時他既可以作為管理員這個角色參與管理，也可以作為借書者向圖書館借書，在這裡小明扮演了兩個角色，是兩個不同的參與者。參與者在畫圖中用簡筆人物畫來表示，人物下面附上參與者的名稱。
2． 用例是對包括變數在內的一組動作序列的描述，系統執行這些動作，並產生傳遞特定參與者的價值的可觀察結果。我們可以這樣去理解，用例是參與者想要系統做的事情。對於對用例的命名，我們可以給用例取乙個簡單、描述性的名稱，一般為帶有動作性的詞。用例在畫圖中用橢圓來表示，橢圓下面附上用例的名稱。
3．系統邊界是用來表示正在建模系統的邊界。邊界內表示系統的組成部分，邊界外表示系統外部。系統邊界在畫圖中方框來表示，同時附上系統的名稱，參與者畫在邊界的外面，用例畫在邊界裡面。因為系統邊界的作用有時候不是很明顯，所以我個人理解，在畫圖時可省略。
4．箭頭用來表示參與者和系統通過相互傳送訊號或訊息進行互動的關聯關係。箭頭尾部用來表示啟動互動的一方，箭頭頭部用來表示被啟動的一方，其中用例總是要由參與者來啟動。
一：用例之間的關係
1角色的繼承
2： 用例的包含(include) 包含關係指用例可以簡單地包含其他用例具有的行為，並把它所包含的用例行為作為自身行為的一部分。在uml中，包含關係是通過帶箭頭的虛線段加<>字樣來表示，箭頭由基礎用例(base) 指向被包含用例(inclusion)
在處理包含關係時，具體的做法就是把幾個用例的公共部分單獨的抽象出來成為乙個新的用例。主要有兩種情況需要用到包含關係：
a） 第一，多個用例用到同一段的行為，則可以把這段共同的行為單獨抽象成為乙個用例，然後讓其他用例來包含這一用例。
b） 第二，某乙個用例的功能過多、事件流過於複雜時，我們也可以把某一段事件流抽象成為乙個被包含的用例，以達到簡化描述的目的。
3: 擴充套件關係 在一定條件下，把新的行為加入到已有的用例中，獲得的新用例叫做擴充套件用例(extension) ，原有的用例叫做基礎用例(base) ，從擴充套件用例到基礎用例的關係就是擴充套件關係。乙個基礎用例可以擁有乙個或者多個擴充套件用例，這些擴充套件用例可以一起使用。
二．用例描述
用例圖只是簡單地用圖描述了一下系統，但對於每個用例，我們還需要有詳細的說明，這樣就可以讓別人對這個系統有乙個更加詳細的了解，這時我們就需要寫用例描述。
下面是乙個用例描述模板：
編號[用例編號,如 uc-01]
名稱[用例名稱,即用例圖中用例的描述]
執行者[使用者，角色等]
描述[簡單的描述本用例，重點說明執行者的目標]
前置條件
[列出執行本用例前必須存在的系統狀態，如：必須錄入什麼資料，須選實現其他什麼用例等。注意除非情況特殊，不要寫類似」登入系統」等每個用例幾乎都需要具備的前置條件。]
基本流程
[說明在「正常」的情況下，最常用的流程，通常是執行者和系統之間互動的文字描述]
結束狀態
[列出在「正常」結束的情況下的用例的結果]
可選流程1
[說明 和基本流程不同的其他可能的流程]
可選流程n
[說明 和基本流程不同的其他可能的流程]
異常流程
[說明出現錯誤或其他異常情況時和基本流程的不同之處]
說明[對本用例的補充說明，如：業務概念，業務規則等]
三．用例圖和用例描述設計例項
這裡以之前的那個考勤系統為例來簡單分析乙個用例圖的畫法。
經分析系統中涉及的角色有如下： 普通員工、行政部員工、財務部員工、部門經理、總經理。
角色的繼承關係如下：
普通員工的用例：
下面是關於普通員工的」提出請假申請」的用例描述
編號1.1
名稱提出請假申請
執行者普通員工
描述普通員工錄入請假的資訊，能成功提出請假申請
前置條件
無基本流程
1: j顯示請假申請表單。
2：填寫請申請單，選擇請假型別
3：提交申請
4:顯示成功提交的申請資訊並返回列表。
結束狀態
系統儲存請假申請資料，並提示成功提交申請的資訊
可選流程1
3：取消請假申請
4：返回列表
異常流程
2：填寫請申請單，選擇請假型別為」年假」
3：提交申請
4：提示可休年假不足，顯示相應資訊。
5： 修改請假申請單，或取消請假申請.
說明請假申請單有以下內容：申請者，開始時間，結束時間，請假事由，請假類別。
申請假預設為當前的使用者，不可修改。
請假的類別為：事假，病假，婚 嫁，產假，年假，只能而且必須選其一
其它的用述描述不再贅述。
以上內容來自於 【火球uml大戰需求分析】中，作為學習筆記記錄一下
建模學習 用例篇
所謂用例，即是參與者與應用系統的一系列使用場景 其中參與者是系統的直接互動物件，它可以是人物 組織 計算機系統等等。其次，每個用例中都包含乙個互動列表，它相當於完成此用例的步驟 即希望完整的實現此用例，列表中的每乙個元素都必須要成功完成 如果有乙個元素的狀態是 失敗 的，那麼最好也補充相應的替代方案...
UML學習 用例的分包
uml學習 用例的分包 2005年8月25日 前言繼續昨天的用例分析，在昨天的工作裡，我基本了解了需求，並且根據使用者需求機型用例分析，得到了若干用例，並且提取出了一組actor。但是在設計用例的問題中，我遇到了若干問題 1 怎麼用應用泛化的方法構建用例？許多用例都是很相似，比如說 新增 修改 檢視...
學習建模 UML
學習位址 安裝成功之後，重啟才能在 搜尋 中查詢到staruml一 用例圖user case diagram1 在model exploer 區域中清空所有的model，右鍵add diagram user case diagram 2 使用 actor 和 directed association...