初學UML 之用例圖

初學UML之用例圖——陳雨章節(jié)UML基礎(chǔ)知識用例圖

概述參與者（Actor）用例（Uesrcase）4種關(guān)系用例描述示例2011年2月28日星期一UML基礎(chǔ)知識什么是UMLUML（統(tǒng)一建模語言，UnifiedModelingLanguage）是一種定義良好、易于表達、功能強大且普遍適用的可視化建模語言。它融入了軟件工程領(lǐng)域的新思想、新方法和新技術(shù)。它的作用域不限于支持面向?qū)ο蟮姆治雠c設(shè)計，還支持從需求分析開始的軟件開發(fā)的全過程。

在系統(tǒng)分析階段，我們一般用UML來畫很多圖，主要包括用例圖、狀態(tài)圖、類圖、活動圖、序列圖、協(xié)作圖、構(gòu)建圖、配置圖等等，要畫哪些圖要根據(jù)具體情況而定。其實簡單的理解，UML的作用就是用很多圖從靜態(tài)和動態(tài)方面來全面描述我們將要開發(fā)的系統(tǒng)。2011年2月28日星期一2011年2月28日星期一UML基礎(chǔ)知識UML的構(gòu)成

2011年2月28日星期一UML基礎(chǔ)知識UML中視圖的關(guān)系

用例視圖邏輯視圖組件視圖配置視圖并發(fā)視圖用例視圖是其他視圖的核心，它的內(nèi)容直接驅(qū)動其他視圖的開發(fā)。系統(tǒng)要提供的功能都是在用例視圖中描述的，用例視圖的修改會對其他視圖產(chǎn)生影響。2011年2月28日星期一UML基礎(chǔ)知識UML中的9種圖

用例圖（UesrcaseDiagram）：需求捕獲，測試依據(jù)類圖（ClassDiagram）：類以及類之間的相互關(guān)系對象圖（ObjiectDiagram）：對象以及對象之間的相互關(guān)系狀態(tài)圖（StateDiagram）：對類描述的補充，類所經(jīng)歷的各種狀態(tài)時序圖（SequenceDiagram）：對象之間發(fā)送的消息的時間順序協(xié)作圖（CollaborationDiagram）：強調(diào)對象寫作的交互圖活動圖（ActivityDiagram）：對工作流程建模組件圖（ComponentDiagram）：組件及其之間的相互依賴關(guān)系配置圖（DeploymentDiagram）：系統(tǒng)中硬件的軟件的物理結(jié)構(gòu)2011年2月28日星期一UML基礎(chǔ)知識UML建模工具IBM的RationalRoseMS的VisioSparxSystems的EnterpriseArchitect（EA）PowerDesigner、trunfunplato…2011年2月28日星期一用例圖概述——定義由參與者（Actor）、用例（usercase）以及它們之間的關(guān)系構(gòu)成的用于描述系統(tǒng)功能的動態(tài)視圖稱為用例圖。2011年2月28日星期一用例圖概述——作用用例圖是需求分析中的產(chǎn)物，主要作用是描述參與者（Actor）和用例（UserCase）之間的關(guān)系，幫助開發(fā)人員可視化得了解系統(tǒng)的功能。借助于用例圖、系統(tǒng)用戶、系統(tǒng)分析人員、系統(tǒng)設(shè)計人員、領(lǐng)域?qū)＜夷軌蛞钥梢暬姆绞綄栴}進行探討，減少了大量交流上的障礙，便于對問題達成共識。用例圖可視化地表達了系統(tǒng)的需求，具有直觀、規(guī)范等優(yōu)點，克服了純文字性說明的不足。

用例方法是完全從外部來定義系統(tǒng)功能，它把需求和設(shè)計完全的分離開來。我們不用關(guān)心系統(tǒng)內(nèi)部是如何完成各種功能的，系統(tǒng)對于我們來說就是一個黑箱子。2011年2月28日星期一用例圖概述——構(gòu)成要素參與者（Actor）用例（UserCase）關(guān)系（箭頭）注釋約束系統(tǒng)邊界（也可以是一個“包”）用例描述2011年2月28日星期一用例圖參與者（Actor）——概念要在用例上繪制一個參與者，可繪制一個人形符號，參與者的角色名稱寫在人形符號正下方。要注意的是，參與者不是指人或事物本身，而是表示人或事物當時所扮演的角色。比如小明是圖書館的管理員，他參與圖書館管理系統(tǒng)的交互，這時他既可以作為管理員這個角色參與管理，也可以作為借書者向圖書館借書，在這里小明扮演了兩個角色，是兩個不同的參與者。參與者有三大類：系統(tǒng)用戶、與所建造的系統(tǒng)交互的其他系統(tǒng)、一些可以運行的進程。

每個參與者可以參與一個或多個用例，每個用例也可以有一個或多個參與者。2011年2月28日星期一用例圖參與者（Actor）——確定參與者

在獲取用例前首先要確定系統(tǒng)的參與者，建模人員可以通過回答以下的問題來尋找系統(tǒng)的參與者。誰將使用該系統(tǒng)的主要功能。誰將需要該系統(tǒng)的支持以完成其工作。誰將需要維護、管理該系統(tǒng)，以及保持該系統(tǒng)處于工作狀態(tài)。系統(tǒng)需要處理哪些硬件設(shè)備。與該系統(tǒng)那個交互的是什么系統(tǒng)。

誰或什么系統(tǒng)對本系統(tǒng)產(chǎn)生的結(jié)果感興趣。2011年2月28日星期一用例圖參與者（Actor）——確定參與者在對參與者建模的過程中，建模人員必須要牢記以下幾點：參與者對于系統(tǒng)而言總是外部的，因此它們可以處于人的控制之外。參與者可以直接或間接的與系統(tǒng)交互，或使用系統(tǒng)提供的服務以完成某件事務。

參與者表示人和事物與系統(tǒng)發(fā)生交戶時所扮演的角色，而不是特定的人或者特定的事物。每個參與者需要一個具有業(yè)務一樣的名字，在建模中不推薦使用類似“新參與者”的名字。每一個參與者要必須有簡短的描述，從業(yè)務角度描述參與者是什么。

一個人或事物在與系統(tǒng)發(fā)生交互時，可以同時或不同時扮演多個角色。和類一樣，參與者可以具有表示參與者的屬性和可以接受的事件，但使用的不頻繁。2011年2月28日星期一用例圖參與者（Actor）——參與者之間的關(guān)系

因為參與者是類，所以多個參與者之間可以具有與類相同的關(guān)系。在用例視圖中，使用了泛化關(guān)系（也稱作繼承關(guān)系）來描述多個參與者之間的公共行為。如果系統(tǒng)中存在幾個參與者，它們既扮演自身的角色，同時也扮演更具一般化的角色，那么就用泛化關(guān)系來描述它們。這種情況往往發(fā)生在一般角色的行為在參與者超類中描述的場合。特殊化的參與者繼承了該超類的行為，然后在某些方面擴展了此行為。參與者之間的泛化關(guān)系用一個三角箭頭來表示，指向扮演一般角色的超類。2011年2月28日星期一用例圖用例（UserCase）——概念

用例是對包括變量在內(nèi)的一組動作序列的描述，系統(tǒng)執(zhí)行這些動作，并產(chǎn)生傳遞特定參與者的價值的可觀察結(jié)果。這是UML對用例的正式定義，對我們初學者可能有點難懂。我們可以這樣去理解，用例是參與者想要系統(tǒng)做的事情。對于對用例的命名，我們可以給用例取一個簡單、描述性的名稱，一般為帶有動作性的詞。用例在畫圖中用橢圓來表示，橢圓下面附上用例的名稱。2011年2月28日星期一用例圖用例（UserCase）——識別用例

任何用例都不能在缺少參與者的情況下獨立存在。同樣，任何參與者也必須要有與之關(guān)聯(lián)的用例。所以識別用例的最好方法就是從分析系統(tǒng)參與者開始，在這個過程中往往會發(fā)現(xiàn)新的參與者。

可以通過以下問題來尋找用例：參與者希望系統(tǒng)能提供什么功能？參與者是否會讀取、創(chuàng)建、修改、刪除、存儲系統(tǒng)的某些信息？如果是的話，參與者又是如何完成這些操作的？參與者是否會將外部的某些時間通知給系統(tǒng)？是否存在影響系統(tǒng)的外部事件？2011年2月28日星期一用例圖用例（UserCase）——用例的粒度

用例的粒度指的是用例所包含的系統(tǒng)服務或功能單元的多少。用例的粒度越大，用例包含的功能越多，反之則包含的功能越少。

如果用例的粒度很小，得到的用例數(shù)就會太多。反之，如果用例的粒度很大，那么得到的用例數(shù)就會很少。

如果用例的數(shù)目過多會造成用例模型過大和引入設(shè)計困難大大提高。如果用例數(shù)目過少會造成用例的粒度太大，不便于進一步的充分分析。2011年2月28日星期一用例圖用例（UserCase）——用例的粒度

比如：網(wǎng)站后臺管理系統(tǒng)中的會員信息維護用例，管理員需要進行添加會員信息、修改會員信息、刪除會員信息等操作。

我們還可以根據(jù)具體的操作把它抽象成3個用例，它展示的系統(tǒng)需求和單個用例是完全一樣的。2011年2月28日星期一用例圖4種關(guān)系

用例除了與其參與者發(fā)生關(guān)聯(lián)外，還可以具有系統(tǒng)中的多個關(guān)系，這些關(guān)系包括：包含關(guān)系（Include）擴展關(guān)系（Extend）泛化關(guān)系（Generalization）關(guān)聯(lián)關(guān)系（Association）2011年2月28日星期一用例圖4種關(guān)系——關(guān)聯(lián)關(guān)系（Association）

關(guān)聯(lián)關(guān)系描述參與者與用例之間的關(guān)系，表示參與者和用例之間的通信。不同的參與者可以訪問相同的用例，一般來說它們和該用例的交互是不一樣的，如果一樣的話，說明它們的角色可能是相同的。如果兩種交互的目的也相同，說明它們的角色是相同的，就可以將它們合并（參與者之間的泛化關(guān)系）。在Rose中關(guān)聯(lián)關(guān)系用箭頭表示，在EA中用直線表示。2011年2月28日星期一用例圖4種關(guān)系——包含關(guān)系（Include）

包含關(guān)系指用例可以簡單地包含其他用例具有的行為，并把它所包含的用例行為做為自身行為的一部分。在UML中，包含關(guān)系是通過帶箭頭的虛線線段加<<include>>字樣來表示，箭頭由基礎(chǔ)用例(Base)指向被包含用例(Inclusion)。2011年2月28日星期一用例圖4種關(guān)系——包含關(guān)系（Include）包含關(guān)系代表著基礎(chǔ)用例會用到被包含用例，具體的講就是被包含用例的事件流插入到基礎(chǔ)用例的事件流中。例如：登錄輸入驗證碼如果兩個以上用例有大量一致的功能，則可以將這個功能分解到另一個用例中。其他用例可以和這個用例建立包含關(guān)系。一個用例的功能太多時，可以用包含關(guān)系建模兩個小用例。包含關(guān)系是UML1.3中的表述，在UML1.1中，同等語義的關(guān)系被表述為使用（Uses）。2011年2月28日星期一用例圖4種關(guān)系——擴展關(guān)系（Extend）在一定條件下，把新的行為加入到已有的用例中，獲得的新用例叫做擴展用例（Extension），原有的用例叫做基礎(chǔ)用例（Base），從擴展用例到基礎(chǔ)用例的關(guān)系就是擴展關(guān)系。

一個基礎(chǔ)用例可以擁有一個或者多個擴展用例，這些擴展用例可以一起使用。

在UML中，擴展關(guān)系表示為虛線箭頭加<<extend>>字樣，箭頭指向被擴展的用例（即基礎(chǔ)用例）。2011年2月28日星期一用例圖4種關(guān)系——擴展關(guān)系（Extend）基礎(chǔ)用例不必知道擴展用例的任何細節(jié)，它僅為其提供擴展點。事實上，基礎(chǔ)用例即使沒有擴展用例也是完整的，這點與包含關(guān)系有所不同。

一般情況下，基礎(chǔ)用例的執(zhí)行不會涉及到擴展用例，只有特定的條件發(fā)生，擴展用例才被執(zhí)行。例如：拼途網(wǎng)人人登錄2011年2月28日星期一用例圖4種關(guān)系——泛化關(guān)系（Generalization）用例的泛化指的是一個父用例可以被特化形成多個子用例，而父用例和子用例之間的關(guān)系就是泛化關(guān)系。

在用例的泛化關(guān)系中，子用例繼承了父用例所有的結(jié)構(gòu)、行為和關(guān)系，子用例是父用例的一種特殊形式。

在UML中，用例的泛化關(guān)系通過一個三角箭頭從子用例指向父用例來表示。2011年2月28日星期一用例圖4種關(guān)系——泛化關(guān)系（Generalization）例如：2011年2月28日星期一用例圖用例描述

用例圖只是簡單地用圖描述了一下系統(tǒng)，但對于每個用例，我們還需要有詳細的說明，這樣就可以讓別人對這個系統(tǒng)有一個更加詳細的了解，這時我們就需要寫用例描述。

對于用例描述的內(nèi)容，一般沒有硬性規(guī)定的格式，但一些必須或者重要的內(nèi)容還是必須要寫進用例描述里面的。用例描述一般包括：簡要描述（說明）、前置（前提）條件、基本事件流、其他事件流、異常事件流、后置（事后）條件等等。2011年2月28日星期一用例圖用例描述簡要描述對用例的角