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