UML輕松入門--UML靜態(tài)建模：用例
本節(jié)和大家學(xué)習(xí)一下UML靜態(tài)建模中的用例，主要包括用例與用例圖，建立用例模型等內(nèi)容，相信通過本節(jié)的學(xué)習(xí)你對(duì)UML靜態(tài)建模一定會(huì)有深刻的認(rèn)識(shí)。下面請(qǐng)看詳細(xì)介紹。
UML輕松入門--UML靜態(tài)建模：用例
目前，在熱播的內(nèi)地版《神雕俠侶》中，楊過和小龍女有一份不為人知的默契與浪漫，那就是他們所繪制的并肩小人圖。這樣的小人圖，是UML用例圖的一部分，被稱為參與者。
2.1用例與用例圖
UML靜態(tài)建模中用例是需求分析中最重要的概念，需求表征了一個(gè)系統(tǒng)的設(shè)計(jì)特性、特征和行為，描述一個(gè)系統(tǒng)的需求意味著描述了建立在該系統(tǒng)外部的事物與系統(tǒng)之間的契約，契約上聲明了期望系統(tǒng)做什么。
需求獲取(RequirementElicitation)是需求工程的主體，其主要工作是建立待開發(fā)系統(tǒng)的模型，而用例就是用于建立這種模型的良好方法。用例最初由IvarJackboson博士提出，后被綜合到UML規(guī)范之中，成為需求表述的標(biāo)準(zhǔn)化體系。前文已經(jīng)提到，整個(gè)RUP流程都是“用例驅(qū)動(dòng)”的，各種類型的開發(fā)活動(dòng)包括項(xiàng)目管理、分析、設(shè)計(jì)、測(cè)試、實(shí)現(xiàn)等以用例為主要輸入工件，用例模型奠定了整個(gè)系統(tǒng)軟件開發(fā)的基礎(chǔ)，用例被認(rèn)作第二代面向?qū)ο蠹夹g(shù)的標(biāo)志，可見其重要性非同一般。
我們先來給出一個(gè)具體而簡(jiǎn)單的用例圖，即“圖書管理系統(tǒng)”用例圖，如圖2.1。在用例圖中主要涉及到參與者（又稱角色、執(zhí)行者）、用例以及二者之間的通訊關(guān)聯(lián)。
圖2.1圖書管理系統(tǒng)用例圖
參與者
UML靜態(tài)建模中參與者是與系統(tǒng)、子系統(tǒng)或類發(fā)生交互的外部用戶、進(jìn)程或其他系統(tǒng)。參與者可以是人、另一個(gè)計(jì)算機(jī)系統(tǒng)或一些可運(yùn)行的進(jìn)程。在圖2.1中，“讀者”和“管理員”即為參與者。
參與者之間可以存在泛化關(guān)系，例如，在圖2.1所示圖書館管理系統(tǒng)用例圖中，可以認(rèn)為“讀者”是“學(xué)生讀者”和“教師讀者”的泛化，而“學(xué)生讀者”還可以具體化為“本科生讀者”和“研究生讀者”；同樣，“圖書管理人員”也是“采購(gòu)員”、“編目員”及“借閱人員”的泛化。圖2.2表示出了參與者之間的泛化關(guān)系。
圖2.2參與者泛化關(guān)系
用例
UML靜態(tài)建模中用例是外部可見的一個(gè)系統(tǒng)功能，這些功能由系統(tǒng)所提供，并通過與參與者之間消息的交換來表達(dá)。用例的用途是在不揭示系統(tǒng)內(nèi)部構(gòu)造的情況下定義行為序列，它把系統(tǒng)當(dāng)作一個(gè)黑箱，表達(dá)整個(gè)系統(tǒng)對(duì)外部用戶可見的行為。
鑒于用例的特點(diǎn)，用例一般被命名為一個(gè)能夠說明目標(biāo)的動(dòng)名詞組。如圖2.1中的“借書”、“還書”和“管理圖書”皆為動(dòng)名詞組。
用例之間也可以存在包含、擴(kuò)展和泛化等關(guān)系：
（1）包含關(guān)系：用例可以簡(jiǎn)單地包含其他用例具有的行為，并把它所包含的用例行為做為自身行為的一部分，這被稱作包含關(guān)系。
（2）擴(kuò)展關(guān)系：擴(kuò)展關(guān)系是從擴(kuò)展用例到基本用例的關(guān)系，它說明為擴(kuò)展用例定義的行為如何插入到為基本用例定義的行為中。它是以隱含形式插入的，也就是說，擴(kuò)展用例并不在基本用例中顯示。在
以下幾種情況下，可使用擴(kuò)展用例：
a.表明用例的某一部分是可選的系統(tǒng)行為（這樣，您就可以將模型中的可選行為和必選行為分開）；
b.表明只在特定條件（如例外條件）下才執(zhí)行的分支流；
c.表明可能有一組行為段，其中的一個(gè)或多個(gè)段可以在基本用例中的擴(kuò)展點(diǎn)處插入。所插入的行為段和插入的順序取決于在執(zhí)行基本用例時(shí)與主角進(jìn)行的交互。
圖2.3給出了一個(gè)擴(kuò)展關(guān)系的例子，在還書的過程中，只有在例外條件（讀者遺失書籍）的情況下，才會(huì)執(zhí)行賠償遺失書籍的分支流。
圖2.3用例擴(kuò)展關(guān)系
（3）泛化關(guān)系：用例可以被特別列舉為一個(gè)或多個(gè)子用例，這被稱做用例泛化。當(dāng)父用例能夠被使用時(shí)，任何子用例也可以被使用。如在圖2.4中，訂票是電話訂票和網(wǎng)上訂票的抽象。
圖2.4用例泛化關(guān)系
通訊關(guān)聯(lián)
UML靜態(tài)建模中通訊關(guān)聯(lián)用于表示參與者和用例之間的對(duì)應(yīng)關(guān)系，它表示參與者使用了系統(tǒng)中的哪些用例（或者說系統(tǒng)所提供的用例被哪些參與者使用）。
通訊關(guān)聯(lián)以箭頭或?qū)嵕€表示。若使用箭頭，箭頭所指方將是對(duì)話的被動(dòng)接受者；如果不強(qiáng)調(diào)對(duì)話中的主動(dòng)與被動(dòng)關(guān)系，則可以使用不帶箭頭的關(guān)聯(lián)實(shí)線。#p#
2.2建立用例模型
知道了用例與用例圖的概念，我們還需要懂得怎樣建立用例模型，即怎樣找出參與者、用例以及定義用例的過程。一般來說，建立用例模型的步驟為：
（1）確定誰(shuí)會(huì)直接使用該系統(tǒng)，即參與者（Actor），為了發(fā)現(xiàn)參與者，我們可以嘗試問如下問題：
a.誰(shuí)/什么使用系統(tǒng)？
b.誰(shuí)/什么從系統(tǒng)獲得信息？
c.誰(shuí)/什么向系統(tǒng)提供信息？
d.誰(shuí)/什么支持、維護(hù)系統(tǒng)？
e.哪些其它系統(tǒng)使用此系統(tǒng)？
f.公司的哪個(gè)部門使用系統(tǒng)？
…
（2）選取其中一個(gè)參與者；
（3）定義該參與者希望系統(tǒng)做什么，參與者希望系統(tǒng)做的每件事成為一個(gè)用例，為了發(fā)現(xiàn)用例，我們可以嘗試問如下問題：
a.為什么該參與者想要使用此系統(tǒng)？
b.該參與者是否要?jiǎng)?chuàng)建、保存、更改、移動(dòng)或讀取系統(tǒng)的數(shù)據(jù)？如果是，為什么？
c.該參與者是否要通知系統(tǒng)外部事件或變化？
d.該參與者是否需要知道系統(tǒng)內(nèi)部的特定事件？
…
（4）對(duì)每件事來說，何時(shí)參與者會(huì)使用系統(tǒng)，通常會(huì)發(fā)生什么，這就是用例的基本過程；
（5）描述該用例的基本過程；
（6）考慮一些可變情況，把他們創(chuàng)建為擴(kuò)展用例；
（7）復(fù)審不同用例的描述，找出其中的相同點(diǎn)，抽出相同點(diǎn)作為共同的用例；
（8）重復(fù)步驟2-7找出每一個(gè)用例。
UML靜態(tài)建模中參與者檢查的參考標(biāo)準(zhǔn)如下：
（1）是否您已找到所有的參與者？也就是說，是否您已經(jīng)對(duì)系統(tǒng)環(huán)境中的所有參與者都進(jìn)行了說明和建模？
（2）每個(gè)參與者是否至少涉及到一個(gè)用例？
（3）您能否列出至少兩名可以作為特定參與者的人員？
（4）是否有參與者擔(dān)任與系統(tǒng)相關(guān)的相似參與者？如果有，您應(yīng)該將他們合并到一個(gè)參與者中。
UML靜態(tài)建模中用例檢查的參考標(biāo)準(zhǔn)如下：
（1）用例模型的簡(jiǎn)介部分簡(jiǎn)明清晰地概述此系統(tǒng)的目的和功能；
（2）所有的用例已確定，這些用例共同說明所有的必要行為；
（3）所有的功能性需求都至少映射到一個(gè)用例；
（4）該用例模型不包含多余的行為，所有的用例都可回溯到某個(gè)功能性需求來證明其合理性。
例圖從總體上大致描述了系統(tǒng)所能提供的各種服務(wù)，讓我們對(duì)于系統(tǒng)的功能有一個(gè)總體的認(rèn)識(shí)，僅此還是不夠的，我們還需要描述每一個(gè)用例的詳細(xì)信息，即用例規(guī)約。用例模型正是由用例圖和每一個(gè)用例的詳細(xì)描述――用例規(guī)約所組成的。RUP中提供了用例規(guī)約的模板，包含以下內(nèi)容：
（1）簡(jiǎn)要說明(BriefDescription)：簡(jiǎn)要介紹該用例的作用和目的；
（2）事件流(FlowofEvent)：包括基本流和備選流，事件流應(yīng)該表示出所有的場(chǎng)景；
（3）用例場(chǎng)景(Use-CaseScenario)：包括成功場(chǎng)景和失敗場(chǎng)景，場(chǎng)景主要是由基本流和備選流組合而成的；
（4）特殊需求(SpecialRequirement)：描述與該用例相關(guān)的非功能性需求（包括性能、可靠性、可用性和可擴(kuò)展性等）和設(shè)計(jì)約束（所使用的操作系統(tǒng)、開發(fā)工具等）；
（5）前置條件(Pre-Condition)：執(zhí)行用例之前系統(tǒng)必須所處的狀態(tài)；
（6）后置條件(Post-Condition)：用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。
用例規(guī)約基本上是用文本方式來表述的，為了更加清晰地描述事件流，也可以選擇使用狀態(tài)圖、活動(dòng)圖或序列圖來輔助說明（狀態(tài)圖有助于描述與狀態(tài)相關(guān)的系統(tǒng)行為，活動(dòng)圖有助于描述復(fù)雜的決策流程，序列圖適合于描述基于時(shí)間順序的消息傳遞）。另外，只要對(duì)簡(jiǎn)潔明了地表達(dá)用例有幫助，我們就可以在用例中任意粘貼用戶界面、流程的圖形化顯示方式及其他圖形。
【編輯推薦】
- 學(xué)習(xí)筆記 解析UML動(dòng)態(tài)建模機(jī)制
- UML實(shí)例教程 圖書管理系統(tǒng)中UML建模分析與設(shè)計(jì)
- 名師講解UML動(dòng)態(tài)建模機(jī)制中消息，狀態(tài)圖和順序圖用法
- UML建模時(shí)需要注意的四大問題
- 深入剖析UML動(dòng)態(tài)建模機(jī)制中的四種動(dòng)態(tài)模型
