UML用例圖

   最近團隊在做在一個項目，設計到一些用例圖的繪制。因為以前沒有深入研究，是以這幾天浏覽了一些資料，對這方面的知識總結了一下，與大家一起分享(lxf)。

對于用例圖，首先我們要了解什麼是用例圖？

用例圖(use case diagram)是由軟體需求分析到最終實作的第一步，它描述人們如何使用一個系統。用例視圖顯示誰是相關的使用者、使用者希望系統提供什麼樣的服務，以及使用者需要為系統提供的服務，以便使系統的使用者更容易了解這些元素的用途，也便于軟體開發人員最終實作這些元素。用例圖在各種開發活動中被廣泛的應用，但是它最常用來描述系統及子系統。

當用例視圖在外部使用者出現以前出現時，它捕獲到系統、子系統或類的行為。它将系統功能劃分成對參與者（即系統的理想使用者）有用的需求。而互動部分被稱作用例。用例使用系統與一個或者多個參與者之間的一系列消息來描述系統中的互動。

簡而言之，就是站在使用者的角度，把使用者要做的場景以圖的方式表現出來。

用例圖包含的元素：uml用例圖包含六個元素，分别是：執行者(actor)、用例(usecase)、關聯關系(association)、包含關系(include)、擴充關系(extend)以及泛化關系(generalization)。但是有些uml的繪圖工具多提供了一種直接關聯關系(directedassociation)。

1.執行者(actor)

表示與應用程式或系統進行互動的使用者、組織或外部系統。用一個小人表示。

每個參與者可以參與一個或多個用例。它通過交換資訊與用例發生互動（是以也與用例所在的系統或類發生了互動），而參與者的内部實作與用例是不相關的，可以用一組定義其狀态的屬性充分的描述參與者。

    參與者有三大類：系統使用者、與所建造的系統互動的其它系統和一些可以運作的程序。

    第一類參與者是真實的人，即使用者，是最常見的參與者，幾乎存在于每個系統中。命名這類參與者時，應當按照業務而不是位置命名，因為一個人可能有很多業務。

    第二類參與者是其它的系統。這類位于程式邊界之外的系統也是參與者。

    第三類參與者是一些可以運作的程序，如時間。當經過一定的時間觸發系統中的某個事件時，時間就成了參與者。

    2.用例(use case)

用例就是外部可見的系統功能，對系統提供的服務進行描述。用橢圓表示。

在模型中，每個用例的執行都獨立與其它用例，盡管在執行一個用例時由于用例之間共享對象的原因可能會在用例之間産生隐含的依賴關系。每個用例都表示一個縱向的功能塊，這個功能塊的執行會和其它用例的執行混合在一起。

     用例的動态執行過程可以用uml的互動來說明，可用用狀态圖、時序圖、協作圖或非正式的文字描述來表示。用例功能的執行通過系統中類之間的協作來實作。一個類可以參與多個協作，是以也參與了多個用例。

     在系統層，用例表示整個系統對外部使用者可見的行為。一個用例就像外部使用者可以使用的系統操作。但是，它不又與操作不同，用例可以在執行過程中持續接受參與者的輸入消息。用例也可以被像子系統和獨立類這樣的系統小單元所應用。一個内部用例表示了系統的一部分對其它部分呈現出的行為。

3. 子系統(subsystem)

用來展示系統的一部分功能，這部分功能聯系緊密。

4. 關系

用例圖中涉及的關系有：關聯、泛化、包含、擴充。

a. 關聯(association)

表示參與者與用例之間的通信，任何一方都可發送或接受消息。

關聯關系表示參與者與用例之間的通信。不同的參與者可以通路相同的用例，一般說來它們和該用例的互動是不一樣的，如果一樣的話，說明它們的角色可能是相同的。如果兩中互動的目的也相同，說明它們的角色是相同的，就可以将它們合并。

b. 泛化(inheritance)

就是通常了解的繼承關系，子用例和父用例相似，但表現出更特别的行為；子用例将繼承父用例的所有結構、行為和關系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。

c. 包含(include)

包含關系用來把一個較複雜用例所表示的功能分解成較小的步驟。

包含關系使一個用例的功能可以在另一個用例中使用，如下所述。

  （1）如果兩個以上用例有大量一緻的功能，則可以将這個功能分解到另外一個用例中。其它用例可以和這兩個用例建立包含關系。

  （2）一個用例的功能太多時，可以用包含關系模組化兩個小用例。

要使用包含關系，就必須在客戶用例中說明提供者用例行為别包含的詳細位置。這一點同功能調用有點類似。事實上，它們在某種程度上具有相似的語義。

d. 擴充(extend)

擴充關系是指用例功能的延伸，相當于為基礎用例提供一個附加功能。

擴充關系是把新的行為插入到已有的用例中的方法。同一個基礎用例的幾個擴充用例可以在一起應用。基礎用例的擴充增加了原有的語義，此時基礎用例而不是擴充用例被作為例子使用

e. 依賴(dependency)

　以上4種關系，是uml定義的标準關系。但vs2010的用例模型圖中，添加了依賴關系，用帶箭頭的虛線表示，表示源用例依賴于目标用例。

包含(include)、擴充(extend)、泛化(inheritance) 的差別：

條件性：泛化中的子用例和include中的被包含的用例會無條件發生，而extend中的延伸用例的發生是有條件的；

直接性：泛化中的子用例和extend中的延伸用例為參與者提供直接服務，而include中被包含的用例為參與者提供間接服務。

對extend而言，延伸用例并不包含基礎用例的内容，基礎用例也不包含延伸用例的内容。

對inheritance而言，子用例包含基礎用例的所有内容及其和其他用例或參與者之間的關系；

用例模組化技術：

一．對語境模組化

對于一個系統，會有一些事物存在于其内部，而一些事物存在于其外部。存在于系統内部的事物的任務是完成系統外部事物所期望的系統行為，存在于系統外部并與其進行互動的事物構成了系統的語境，即系統存在的環境。在uml模組化中，用例圖對系統的語境進行模組化，強調的是系統的外部參與者。對系統語境模組化應當遵循以下的方法：

（1） 用以下幾組事物來識别系統外部的參與者：需要從系統中得到幫助以完成其任務的組；執行系統功能時所必須的組；與外部硬體或其它軟體系統進行互動的組；為了管理和維護而執行某些輔助功能的組。

（2）将類似的參與者組織成泛化/特殊化的結構層次。

（3）在需要加深了解的地方，為每個參與者提供一個構造型。

（4）将參與者放入到用例圖中，并說明參與者與用例之間的通信路徑。

二．對需求模組化

需求就是根據使用者對産品功能的期望，提出産品外部功能的描述。需要分析所要做的工作是擷取系統的需求，歸納系統所要實作的功能，使最終的軟體産品最大限度的貼近使用者的要求。對系統需求模組化可以參考以下的方法。

（1）識别系統外部的參與者來建立系統的語境。

（2）考慮每一個參與者期望的行為或需要系統提供的行為。

（3）把公共的行為命名為用例

（4） 解公共行為，放入到新的用例中以供其它的用例使用：分解異常行為，放入新用例中以延伸為主要的控制流。簡而言之，就是确定提供者用例和擴充用例。

（5）         在用例視圖中對用例、參與者和它們之間的關系進行模組化。