原文鏈接：https://blog.csdn.net/mj_ww/article/details/53020080
1. 如何識別用例
任何用例都不能在缺少參與者的情況下獨立存在。同樣，任何參與者也必須要有與之關聯的用例。所以識別用例的最好方法就是從分析系統參與者開始，在這個過程中往往會發現新的參與者。
可以通過以下問題來尋找用例：
(1)參與者希望系統提供什么功能？
(2)參與者是否會讀取、創建、修改、刪除、存儲系統的某種信息？如果是的話，參與者又是如何完成這些操作的？
(3)參與者是否會將外部的某些事件通知給系統？
(4)系統中發生的事件是否通知參與者？
(5)是否存在影響系統的外部事件。
2.用例的粒度
用例的粒度指的是用例所包含的系統服務或功能單元的多少。用例的粒度越大，用例包含的功能越多，反之則包含的功能越少。
如果用例的粒度很小，得到的用例數就會太多。反之，如果用例的粒度很大，那么得到的用例數就會很少。
如果用例數目過多會造成用例模型過大和引入設計困難大大提高。 如果用例數目過少會造成用例的粒度太大，不便於進一步的充分分析。
3.用例規約
對於每一個用例，我們還需要有詳細的描述信息，以便讓別人對於整個系統有一個更加詳細的了解，這些信息包含在用例規約之中。
每一個用例的用例規約都應該包含以下內容：
(1)簡要說明:對用例作用和目的的簡要描述。
(2)事件流:事件流包括基本流和備選流。基本流描述的是用例的基本流程，是指用例“正常”運行時的場景。
(3)用例場景:同一個用例在實際執行的時候會有很多不同的情況發生，稱之為用例場景，也可以說用例場景就是用例的實例。
(4)特殊需求: 特殊需求指的是一個用例的非功能性需求和設計約束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可擴展性等。例如法律或法規方面的需求、應用程序標准和所構建系統的質量屬性等。
(5)前置條件: 執行用例之前系統必須所處的狀態。例如，前置條件是要求用戶有訪問的權限或是要求某個用例必須已經執行完。
(6)后置條件:用例執行完畢后系統可能處於的一組狀態。例如，要求在某個用例執行完后，必須執行另一個用例。
用例間關系：
1、包含include
包含關系指用例可以簡單地包含其他用例具有的行為，並把它所包含的用例行為作為自身行為的一部分。在UML中，包含關系是通過帶箭頭的虛線段加<>字樣來表示，箭頭由基礎用例(Base)指向被包含用例(Inclusion)。在處理包含關系時，具體的做法就是把幾個用例的公共部分單獨的抽象出來成為一個新的用例。主要有兩種情況需要用到包含關系：
第一，多個用例用到同一段的行為，則可以把這段共同的行為單獨抽 象成為一個用例，然后讓其他用例來包含這一用例。
第二，某一個用例的功能過多、事件流過於復雜時，我們也可以把某一段事件流抽象成為一個被包含的用例，以達到簡化描述的目的。
2、擴展extend
在一定條件下，把新的行為加入到已有的用例中，獲得的新用例叫做擴展用例(Extension)，原有的用例叫做基礎用例(Base)，從擴展用例到基礎用例的關系就是擴展關系。
一個基礎用例可以擁有一個或者多個擴展用例，這些擴展用例可以一起使用。
3、泛化（繼承）
用例的泛化指的是一個父用例可以被特化形成多個子用例，而父用例和子用例之間的關系就是泛化關系。
在用例的泛化關系中，子用例繼承了父用例所有的結構、行為和關系，子用例是父用例的一種特殊形式。
子用例還可以添加、覆蓋、改變繼承的行為。在UML中，用例的泛化關系通過一個三角箭頭從子用例指向父用例來表示。
