今天學習了一下UML建模部分的用例圖，做個總結：
用例圖的定義：
由Actor 、 Use Case以及他們之間的關係構成的用於描述系統功能的動態視圖稱爲用例圖。
用例圖是需求分析中的產物，主要作用是描述參與者和用例之間的關係， 幫助開發人員可視化的瞭解系統的功能。
用例圖的組成：
參與者：
參與者（Actor）是指存在於系統外部並直接與系統進行交互的人、系統、子系統或類的外部實體的抽象。通常而言一個參與者可以代表一個人，一個計算機子系統，硬件設備或者時間等。
如何確定參與者呢？
確定參與者可以從以下幾個問題入手：
.系統開發出來後，使用系統主要功能的是誰？
.誰需要藉助系統來完成日常的工作？
.系統需要從哪些人或其他系統中獲得數據？
.系統會爲哪些人或其他系統提供數據？
.系統會與哪些其他系統交互？其他系統可以分爲兩類，一類是該系統要使用的系統，二是啓動該系統的系統，包括計算機系統和計算機中的其他應用軟件。
.系統是由誰來維護和管理的，以保證系統處於工作狀態？
.系統控制的硬件設備有哪些？
.誰對本系統產生的結果感興趣？
參與者之間的關係：
參與者之間也存在一定的關係，例如泛化關係，泛化關係可以理解爲面嚮對象語言中的繼承，用一個空心箭頭符號表示，例如職員是銷售經理的父類，那麼在UML中可以做如下表示：
用例：
用例的概念：
用例其實對於參與者來說就是可以感受到的系統服務或者功能單元。它定義了系統如何被參與者使用的。
比如對於一個教學管理系統來說，用例可以是登錄模塊，可以是成績錄入模塊，可以是修改成績模塊等等。
非常重要的是，用例也是一個類，而不是一個具體實例，他描述的是代表的功能的各個方面，包含了用例執行期間可能發生的各種情況。
用例的識別：
那麼如何確定一個用例呢？同樣也可以從以下問題入手來尋找用例：
參與者希望系統提供什麼功能？
參與者是否會讀取，創建，修改，刪除，存儲系統的某種信息？如果是的話，參與者又是如何完成這些操作的？
參與者是否會將外部的某些事件通知給系統？
系統中發生的時間是否通知參與者？
是否存在影響系統的外部事件？
總而言之，用例圖的主要目的就是幫助人民瞭解系統功能，便於開發人員與用戶之間的交流，所以確定用例的一個很重要的標準就是用例應當易於理解。
3.用例的粒度
用例的粒度是指用例所包含的系統服務或者功能單元的多少。用例的粒度越大，用例包含的功能越多，反之則包含的功能越少。
比如一個維護學生信息可以分解成添加學生信息，修改學生信息，刪除學生信息等子用例。
關聯：
接下來談論一下比較重要的概念是關聯，關聯有以下幾種關係：包含（Include）、擴展(Extend)、和泛化（Generalization）。
1.包含關係：
包含關係是指用例可以簡單地包含其他用例具有的行爲，並把它所包含的用例行爲作爲自身行爲的一部分。
圖形表示是這樣的：
具體的說：
多個用例如果用到同一段的行爲，則可以吧這段共同的行爲單獨抽象成爲一個用例，然後讓其他用例來包含這一用例。
舉個栗子：
比如現在有添加資源和修改資源兩個用例，其中，添加資源和修改資源都具有預覽的功能或者動作，那麼就可以這麼做：
2.擴展關係：
在一定條件下，把新的行爲加入到已有的用例中，獲得的新用例稱爲擴展用例(Extension)，原有的用例就稱爲基礎用例（Base）,從擴展用例到基礎用例的關係就是擴展關係。
如圖所示：
需要注意的是：擴展和包含是有本質區別的，其中擴展關係中基礎用例本身就是完整的，然而對於包含關係來說，基礎用例在沒有被包含的用例的情況下就是不完整的存在。
比如上面的添加資源如果沒有預覽資源，就是不完整的。
3.泛化關係：
泛化關係指的是一個父用例可以被特化成多個自用例，父用例和子用例之間的關係就是泛化關係。在泛化關係中，子用例繼承了父用例所有的結構、行爲和關係，自用例就是父用例的特殊形式，這個和麪向對象中的繼承類似。
例如訂票和電話訂票、網上訂票就是這樣一種泛化關係。子用例繼承父用例的所有特性，再在父用例上加上自己的一些特性，這和包含關係有本質不同，包含關係中是把多個基礎用例中的共性抽象爲一個被包含用例，可以說被包含用例就是基礎用例中的一部分，基礎用例的額執行必然會引起被包含用例的執行。
