解析UML用例圖六大元素
本節和大家學習一下UML用例圖方面的內容，UML用例圖在系統建模過程中是使用最為頻繁的，這里向大家介紹一下UML用例圖的元素，希望通過本節的學習，你對UML用例圖有新的認識。
UML用例圖
UML用例圖(UseCaseDiagram)是由軟件需求分析到最終實現的第一步，它描述人們如何使用一個系統。用例視圖顯示誰是相關的用戶、用戶希望系統提供什么樣的服務，以及用戶需要為系統提供的服務，以便使系統的用戶更容易理解這些元素的用途，也便于軟件開發人員最終實現這些元素。用例圖在各種開發活動中被廣泛的應用，但是它最常用來描述系統及子系統。
當用例視圖在外部用戶出現以前出現時，它捕獲到系統、子系統或類的行為。它將系統功能劃分成對參與者（即系統的理想用戶）有用的需求。而交互部分被稱作用例。用例使用系統與一個或者多個參與者之間的一系列消息來描述系統中的交互。
用例圖包含六個元素，分別是：參與者(Actor)、用例(UseCase)、關聯關系(Association)、包含關系(Include)、擴展關系(Extend)以及泛化關系(Generalization)。
UML用例圖可一個包含注釋和約束，還可一個包含包，用于將模型中的元素組合成更大的模塊。有時，可以將用例的實例引入到圖中。用例圖模型如下所示，參與者用人形圖標來標識，用例用橢圓來表示，連線表示它們之間的關系。
一、參與者（Actor）
1．參與者的概念
參與者是系統外部的一個實體，它以某種方式參與用例的執行過程。參與者通過向系統輸入或請求系統輸入某些事件來觸發系統的執行。參與著由參與用例時所擔當的角色來表示。在UML中，參與者用名字寫在下面的人形圖標表示。
每個參與者可以參與一個或多個用例。它通過交換信息與用例發生交互（因此也與用例所在的系統或類發生了交互），而參與者的內部實現與用例是不相關的，可以用一組定義其狀態的屬性充分的描述參與者。
參與者有三大類：系統用戶、與所建造的系統交互的其它系統和一些可以運行的進程。
第一類參與者是真實的人，即用戶，是最常見的參與者，幾乎存在于每個系統中。命名這類參與者時，應當按照業務而不是位置命名，因為一個人可能有很多業務。
第二類參與者是其它的系統。這類位于程序邊界之外的系統也是參與者。
第三類參與者是一些可以運行的進程，如時間。當經過一定的時間觸發系統中的某個事件時，時間就成了參與者。
2．確定參與者
在獲取用例前首先要確定系統的參與者，開發人員可以通過回答以下的問題來尋找系統的參與者。
（1）誰將使用該系統的主要功能。
（2）誰將需要該系統的支持以完成其工作。
（3）誰將需要維護、管理該系統，以及保持該系統處于工作狀態。
（4）系統需要處理哪些硬件設備。
（5）與該系統那個交互的是什么系統。
（6）誰或什么系統對本系統產生的結果感興趣。
在對參與者建模的過程中，開發人員必須要牢記以下幾點。
（1）參與者對于系統而言總是外部的，因此它們可以處于人的控制之外。
（2）參與者可以直接或間接的與系統交互，或使用系統提供的服務以完成某件事務。
（3）參與者表示人和事物與系統發生交戶時所扮演的角色，而不是特定的人或者特定的事物。
（4）每個參與者需要一個具有業務一樣的名字，在建模中不推薦使用類似“新參與者”的名字。
（5）每一個參與者要必須有簡短的描述，從業務角度描述參與者是什么。
（6）一個人或事物在與系統發生交互時，可以同時或不同時扮演多個角色。
（7）和類一樣，參與者可以具有表示參與者的屬性和可以接受的事件，但使用的不頻繁。
3．參與者之間的關系
因為參與者是類，所以多個參與者之間可以具有與類相同的關系。在UML用例圖中，使用了泛化關系來描述多個參與者之間的公共行為。如果系統中存在幾個參與者，它們既扮演自身的角色，同時也扮演更具一般化的角色，那么就用泛化關系來描述它們。這種情況往往發生在一般角色的行為在參與者超類中描述的場合。特殊化的參與者繼承了該超類的行為，然后在某些方面擴展了此行為。參與者之間的泛化關系用一個三角箭頭來表示，指向扮演一般角色的超類。這與UML中類之間的返還關系符號相同。
二、用例（UseCase）
1．用例的概念
用例是外部可見的系統功能單元，這些系統功能由系統單元所提供，并通過一系列系統單元與一個或多個參與者之間交換的消息所表達。用例的用途是，在不揭示系統內部構造的前提下定義連貫的行為。
用例的定義包含它所必須的所有行為——執行用例的主線次序、標準行為的不同變形、一般行為下的所有異常情況及其預期反應。從用戶的角度來看，上述情況很可能是異常情況；從系統的角度來看，它們是必須被描述和處理的附加情況。更確切地說，用例不是需求或功能的規格說明，但是也展示和體現其所描述的過程中的需求情況。在UML中，用例用一個橢圓表示。
在模型中，每個用例的執行都獨立與其它用例，盡管在執行一個用例時由于用例之間共享對象的原因可能會在用例之間產生隱含的依賴關系。每個用例都表示一個縱向的功能塊，這個功能塊的執行會和其它用例的執行混合在一起。
用例的動態執行過程可以用UML的交互來說明，可用用狀態圖、時序圖、協作圖或非正式的文字描述來表示。用例功能的執行通過系統中類之間的協作來實現。一個類可以參與多個協作，因此也參與了多個用例。
在系統層，用例表示整個系統對外部用戶可見的行為。一個用例就像外部用戶可以使用的系統操作。但是，它不又與操作不同，用例可以在執行過程中持續接受參與者的輸入消息。用例也可以被像子系統和獨立類這樣的系統小單元所應用。一個內部用例表示了系統的一部分對其它部分呈現出的行為。例如，某個類的用例表示了一個連貫的功能塊，這個功能塊是該類提供給系統內其它有特定作用的類的。一個類可以有多個用例。#p#
2．識別用例
UML用例圖對整個系統建模過程非常重要，在繪制系統用例圖前，還有許多工作要做。系統分析者必須分析系統的參與者和用例，他們分別描述了“誰來做”和“做什么”這兩個問題。
識別用例最好的方法就是從分析系統的參與者開始，考慮每一個參與者是如何使用系統的。使用這種策略的過程中可能會發現新的參與者，這對完善整個系統的建模有很大的幫助。用例建模的過程是一個迭代和逐步精華的過程，系統分析者首先從用例的名稱開始，然后添加用例的細節信息。這些信息由簡短的描述組成，它們被精華成完整的規格說明。
在識別用例的過程中，通過回答以下幾個問題，系統分析者可以獲得幫助。
（1）特定參與者希望系統提供什么功能。
（2）系統是否存儲和檢索信息，如果是，由哪個參與者觸發。
（3）當系統改變狀態時，是否通知參與者。
（4）是否存在影響系統的外部事件。
（5）哪個參與者通知系統這些事件。
3．用例與事件流
UML用例圖中用例分析處于系統的需求分析階段，這個階段應該盡量避免考慮系統實現的細節問題。但是要實際建立系統，則需要更加具體的細節，這些細節寫在事件流文件中。事件流的目的是為用例的邏輯流程建立文檔，這個文檔詳細描述系統用戶的工作和系統本身的工作。
雖說事件流很詳細，但其仍然是獨立于實現的方法的。換句話說，事件流描述的是一個系統“做什么”而不是“怎么做”。事件流通常包括：簡要說明、前提條件、主事件流、其它事件流和事后事件流。
（1）簡要說明。每個用例應當有一個相關的說明，描述該用例的作用，說明應當簡明扼要，但應包括執行用例的不同類型的用戶和通過這個用例要達到的結果。
（2）前提條件。用例的前提條件列出用例之間必須滿足的條件。例如，前提條件是另一個用例已經執行或用戶具有運行當前用例的權限。但并不是所有用例都有前提條件。
（3）主事件流和其它事件流。用例的具體細節在主事件流和其它事件流中描述。事件流是從用戶角度描述執行用例的具體步驟，關注系統“做什么”，而不是“怎么做”。主事件流和其它事件流包括：用例如何開始和結束、用例如何與參與者交互、用例的正常流程（主流程）、用例主事件流（其它事件流）的變體和錯誤流。
（4）事后條件。事后條件是用例執行完畢后必須為真的條件。例如，可以在用例完成之后設置一個標識，這種信息就是事后條件。與前提條件一樣，事后條件可以增加用例次序方面的信息，如果要求一個用例執行完后必須執行另一個用，那么就可以在事后條件中說明這一點。當然，并不是每個用例中都有事后條件。
三、用例間的關系
UML用例圖中用例除了與參與者發生關系外，還可以具有系統中的多個關系，這些關系包括包含關系、擴展關系和泛化關系。應用這些關系的目的是為了從系統中抽取出公共行為和其變體。
1．關聯關系（Association）
關聯關系描述參與者與用例之間的關系，它是用于表示類的掛系的關聯元類的實例。在UML中，關聯關系用箭頭來表示。
關聯關系表示參與者與用例之間的通信。不同的參與者可以訪問相同的用例，一般說來它們和該用例的交互是不一樣的，如果一樣的話，說明它們的角色可能是相同的。如果兩中交互的目的也相同，說明它們的角色是相同的，就可以將它們合并。
2．包含關系（Include）
雖然每個用例的實例都是獨立的，但是一個用例可以用其它的更簡單的用例來描述。這有點像通過繼承父類并增加附加描述來定義一個類。一個用例可以簡單地包含其它用例具有的行為，并把它所包含的用例行為作為自身行為的一部分，這被稱作包含關系。在這種情況下，新用例不是初始用例的一個特殊例子，并且不能被初始用例所代替。在UML中，包含關系表示為虛線箭頭交<<include>>字樣，箭頭指向被包含的用例。
包含關系把幾個用例的公共步驟分離成一個單獨的被包含用例。被包含用例稱作提供者用例，包含用例稱作客戶用例，提供者用例提供功能給客戶使用。用例間的包含關系允許包含提供者用例的行為到客戶用例的事件中。
包含關系使一個用例的功能可以在另一個用例中使用，如下所述。
（1）如果兩個以上用例有大量一致的功能，則可以將這個功能分解到另外一個用例中。其它用例可以和這兩個用例建立包含關系。
（2）一個用例的功能太多時，可以用包含關系建模兩個小用例。
要使用包含關系，就必須在客戶用例中說明提供者用例行為別包含的詳細位置。這一點同功能調用有點類似。事實上，它們在某種程度上具有相似的語義。
3．擴展關系（Extend）
一個用例也可以被定義為基礎用例的增量擴展，這被稱作擴展關系，擴展關系是把新的行為插入到已有的用例中的方法。同一個基礎用例的幾個擴展用例可以在一起應用。基礎用例的擴展增加了原有的語義，此時基礎用例而不是擴展用例被作為例子使用。在UML用例圖中，擴展關系表示為虛線箭頭加<<extend>>字樣，箭頭指向被擴展展的用例。
基礎用例提供了一組擴展點，在這些新的擴展點中可以添加新的行為，而擴展用例提供了一組插入片片段，這些片段能夠被插入到基礎用例的擴展點上。基礎用例不必知道擴展用例的任何細節，它僅為其提供擴展點。事實上，基礎用例即使沒有擴展用例也是完整的，這點與包含關系有所不同。一個用例可能有多個擴展點，每個擴展點可以出現多次。但是一般情況下，基礎用例的執行不會涉及到擴展用例，只有特定的條件發生，擴展用例才被執行。擴展關系為處理異常或構建靈活的系統框架提供了一種有效的方法。
4．泛化關系（Generalization）
一個用例可以被特別列舉為一個或多個用例，這被稱為用例泛化。當父用例能夠被使用時，任何子用例也可以被使用。在UML中用例泛化與其它泛化關系的表示法相同，用一個三角箭頭從子用例指向父用例。
在用例泛化中，子用例表示父用例的特殊形式。子用例從父用例處繼承行為和屬性，還可以添加、覆蓋或改變繼承的行為。如果系統中一個或多個用例是某個一般用例的特殊化時，就需要使用用例的泛化關系。
【編輯推薦】
