本節(jié)向大家描述一下UML用例模型，主要包括UML用例模型與需求分析，如何建立UML用例模型，用例圖等內(nèi)容，希望本節(jié)的介紹對(duì)你的學(xué)習(xí)有所幫助。下面就是具體介紹。

對(duì)UML用例模型及其應(yīng)用的一次有益的探討

前言：這是一次對(duì)用例模型的探討。怎樣建立用例模型，怎樣編寫用例說明，它與需求規(guī)格說明書有什么區(qū)別，它能替代需求規(guī)格說明書嗎？也許在這里可以找到你要的答案。
進(jìn)入軟件業(yè)稍微久一點(diǎn)兒的人恐怕都不會(huì)陌生，軟件開發(fā)的最初階段都是談需求、寫需求規(guī)格說明書。需求規(guī)格說明書是與客戶最終確認(rèn)到紙上的，非常正式的公文。軟件開發(fā)應(yīng)當(dāng)做什么，做成什么樣子，什么東西不做，項(xiàng)目范圍有多寬，需求規(guī)格說明書都是白紙黑字寫得清清楚楚，誰都無法抵賴。所以，需求規(guī)格說明書一直都是軟件項(xiàng)目開發(fā)合同的重要附件，地位相當(dāng)重要。

但是，隨著RUP的引入，人們開始困惑了。在RUP中沒有需求規(guī)格說明書，而是為用例模型所替代。現(xiàn)在，一些信息化走在比較前列的公司，都紛紛要求按照RUP統(tǒng)一過程進(jìn)行開發(fā)，我們也開始嘗試使用用例模型來替代需求規(guī)格說明書。然而，相信一些關(guān)于用例模型的幾個(gè)重要問題一直困惑著不少人（當(dāng)然也包括我）：用例模型與需求規(guī)格說明書的區(qū)別在哪里？用例模型的優(yōu)勢(shì)在哪里？用例模型能替代需求規(guī)格說明書嗎？圍繞著這幾個(gè)問題我們進(jìn)行一次用例模型的探討之旅吧。
在開始我的探討之旅之前，我們***能帶上一個(gè)問題去探討：

UML用例模型與需求規(guī)格說明書的區(qū)別在哪里？

看到這個(gè)問題，你也許會(huì)非常不屑一顧，認(rèn)為這個(gè)問題不值一提。確實(shí)，在編寫格式上，用例模型與需求規(guī)格說明書的差別顯而易見。但是，從更深層次來討論，你會(huì)發(fā)現(xiàn)，這個(gè)問題并不是那么簡(jiǎn)單。有些人由于對(duì)用例模型的膚淺認(rèn)識(shí)，將用例模型當(dāng)成需求規(guī)格說明書來寫，格式雖說是用例模型的格式，內(nèi)容卻不是用例模型的內(nèi)容，換湯不換藥，反倒弄巧成拙，讓人困惑。需求規(guī)格說明書是面向過程時(shí)代的產(chǎn)物，因此它的核心就是按照面向過程的設(shè)計(jì)思想編寫需求；用例模型是面向?qū)ο蠓治?設(shè)計(jì)的產(chǎn)物，因此它的核心思想就是OOA/D（面向?qū)ο蠓治?設(shè)計(jì)）。我認(rèn)為，把握這一點(diǎn)實(shí)在太重要了。明白了它，才能明白用例模型應(yīng)當(dāng)怎樣設(shè)計(jì)，才能明白它與需求規(guī)格說明書的區(qū)別，才能明白其作用和優(yōu)勢(shì)在何處。下面，我們看看用例模型應(yīng)當(dāng)怎么設(shè)計(jì)。

如何建立UML用例模型

一些初學(xué)者認(rèn)為，用例模型就是畫張用例圖。其實(shí)這是錯(cuò)誤的，用例模型包括用例圖、用例說明，有時(shí)還要輔之一些簡(jiǎn)單的行動(dòng)圖、狀態(tài)圖和序列圖。用例圖采用圖形的方式，形象生動(dòng)地展現(xiàn)了用例、參與者和系統(tǒng)邊界之間的關(guān)系。而用例說明，是對(duì)用例、參與者和系統(tǒng)邊界進(jìn)行的詳細(xì)描述。在描述過程中，還可以對(duì)一些關(guān)鍵的流程，以及這些流程中關(guān)鍵類的狀態(tài)變化，使用行動(dòng)圖、狀態(tài)圖和序列圖進(jìn)行圖形化地展現(xiàn)。

UML用例圖

用例圖是建立UML用例模型的開始。用例模型的建立過程通常都是：先畫用例圖，然后對(duì)用例圖編寫用例說明。在編寫用例說明的時(shí)候，對(duì)一些復(fù)雜的、認(rèn)為有必要的地方，繪制行動(dòng)圖、狀態(tài)圖和序列圖，方便閱讀者理解。用例圖關(guān)注的是三部分內(nèi)容：用例、參與者和系統(tǒng)邊界。

1.用例

用例就是一個(gè)用來描述參與者如何使用系統(tǒng)來實(shí)現(xiàn)其目標(biāo)的一組場(chǎng)景的集合。這句話聽起來比較抽象，但我通常都把它暫時(shí)理解為功能中的模塊（雖然這并不嚴(yán)密，但更加實(shí)用）。用例強(qiáng)調(diào)的是一組場(chǎng)景，在這組場(chǎng)景不多但相互之間存在功能上的共性，就像一個(gè)大功能模塊下的多個(gè)子模塊。這組場(chǎng)景中的每一個(gè)，又分別形成一個(gè)個(gè)子用例。子用例再細(xì)分，又可以再形成各自的子用例。用例分析就是這樣由粗到細(xì)的逐步細(xì)分，從而形成一系統(tǒng)的用例圖。用例圖分析到多細(xì)，應(yīng)當(dāng)由業(yè)務(wù)需求的情況決定。分得過粗，就不足以說清楚業(yè)務(wù)的相關(guān)細(xì)節(jié)，或者使一張用例圖信息過多，影響人們的理解；分得過細(xì)，不僅會(huì)增加工作量，還會(huì)丟失許多用例間的相互關(guān)系，得不償失。總之，較為復(fù)雜的部分細(xì)一些，簡(jiǎn)單的部分粗一些，保證每個(gè)用例圖都保持強(qiáng)烈的相關(guān)性，指導(dǎo)日后的功能劃分。
同時(shí)，用例強(qiáng)調(diào)的是參與者與系統(tǒng)功能的交互，用例就是系統(tǒng)的功能，而參與者可以暫時(shí)理解為使用系統(tǒng)的人。因此，大多數(shù)用例都對(duì)應(yīng)著一個(gè)或數(shù)個(gè)參與者（但部分從用例中包含著的子用例，或擴(kuò)展出來的擴(kuò)展用例沒有參與者）。

用例與用例之間通常有兩種關(guān)系：包含與擴(kuò)展。包含關(guān)系表示一種從屬關(guān)系，即子用例是主用例中相對(duì)獨(dú)立的、必須調(diào)用的一部分功能。在用例分析中，我們應(yīng)當(dāng)將多個(gè)用例都共有的、相對(duì)獨(dú)立的功能提取出來形成一個(gè)子用例，為日后代碼復(fù)用提供有力保障。擴(kuò)展關(guān)系表示一個(gè)功能是對(duì)另一個(gè)功能的擴(kuò)展，即被擴(kuò)展功能不一定調(diào)用擴(kuò)展功能，但擴(kuò)展功能是對(duì)被擴(kuò)展功能的加強(qiáng)與延伸。在繪制用例關(guān)系時(shí)，包含關(guān)系應(yīng)繪制成從主用例指向子用例的虛線箭頭，并標(biāo)注為“include”，表示主用例包含子用例；擴(kuò)展關(guān)系應(yīng)繪制成從擴(kuò)展用例指向被擴(kuò)展用例的虛線箭頭，并標(biāo)注為“extend”，表示擴(kuò)展用例是對(duì)被擴(kuò)展用例的擴(kuò)展。虛線箭頭在UML中代表的是一種依賴關(guān)系，即客戶元素了解供應(yīng)者，并且供應(yīng)者的變化會(huì)影響到客戶元素（依賴是從客戶元素指向供應(yīng)者的）。

封裝性是面向?qū)ο笤O(shè)計(jì)的重要思想之一。而實(shí)現(xiàn)封裝的前提之一，就是要對(duì)需求進(jìn)行整理的基礎(chǔ)上加以功能劃分，使具有強(qiáng)烈相關(guān)性的功能劃分在一起，只有少量接口與外界交互。用例分析，從一開始就對(duì)原始需求進(jìn)行了功能劃分，將相關(guān)功能劃分到一起，將共有功能提取出來，標(biāo)志出功能間的依賴與非依賴關(guān)系（包含表示的是一種依賴關(guān)系，而擴(kuò)展表示的是一種非依賴關(guān)系）。這是一種OOA/D，它為日后的OO設(shè)計(jì)提供了強(qiáng)有力地支持。而這些都是需求規(guī)格說明書所不具有，或者不完全具體的功能。

2.參與者

現(xiàn)在再來說說UML用例模型中的參與者。參與者給大家最直觀的認(rèn)識(shí)就是操作系統(tǒng)的那些人，但更準(zhǔn)確的說應(yīng)當(dāng)是操作系統(tǒng)的那些角色。用例模型要求我們描述清楚系統(tǒng)中的每一個(gè)場(chǎng)景的每一步操作，操作者是誰。同時(shí)，我們關(guān)注的這個(gè)操作者并不是某個(gè)具體的人，而是一群有著相同職責(zé)的人，即角色。用例模型中對(duì)參與者的分析，為我們之后在開發(fā)過程中，進(jìn)行功能、角色、用戶的劃分提供了依據(jù)。
用例模型中的參與者，除了表示操作系統(tǒng)的人，還表示處于系統(tǒng)邊界之外，與系統(tǒng)邊界內(nèi)的用例有關(guān)聯(lián)的其它系統(tǒng)。因此，只有定義好一個(gè)系統(tǒng)的邊界，才能定義哪些是這個(gè)系統(tǒng)內(nèi)的用例，哪些是這個(gè)系統(tǒng)內(nèi)外的參與者。用例模型對(duì)本系統(tǒng)與其它系統(tǒng)相互關(guān)聯(lián)的分析，為我們?nèi)蘸箝_發(fā)過程中，為其它系統(tǒng)提供接口，或與其它系統(tǒng)進(jìn)行接口，提供了依據(jù)。

參與者之間的關(guān)系只有一種——繼承關(guān)系，表示功能職責(zé)上的繼承。譬如，通常軟件系統(tǒng)中都有“普通操作者”，代表的是進(jìn)入系統(tǒng)的所有用戶都應(yīng)當(dāng)具有的功能。而軟件系統(tǒng)又有很多“特殊職能者”，他們除了具有普通操作者的功能外，還有自己獨(dú)特的功能。在這里，“特殊職能者”是對(duì)“普通操作者”的繼承，繼承了“普通操作者”的所有功能。然而，“特殊職能者”又有“普通操作者”不具備的，自己獨(dú)特的功能。

參與者與用例之間是一種關(guān)聯(lián)關(guān)系，即實(shí)線表示。通常，參與者與用例之間的關(guān)系不用定義導(dǎo)航關(guān)系（即畫出箭頭），但部分UML的書籍也定義了這種導(dǎo)航關(guān)系。如果參與者要使用用例，則箭頭從參與者指向用例；如果參與者要接受用例提供的數(shù)據(jù)或查詢結(jié)果，則箭頭從用例指向參與者。

用例分析將參與者放到了一個(gè)十分顯著的位置，同時(shí)還關(guān)注的參與者的期望（即“涉眾利益”，在后面詳細(xì)描述），這也是需求規(guī)格說明書所不具有的。

3.系統(tǒng)邊界

UML用例模型中系統(tǒng)邊界是一個(gè)軟件系統(tǒng)需要處理的整個(gè)問題空間的范圍。一個(gè)軟件系統(tǒng)不可能處理所有問題，我們必須得給它定義這個(gè)問題空間的范圍。哪些是我們這個(gè)軟件可以處理的，哪些則是我們這個(gè)軟件不能處理的，也就是項(xiàng)目管理中所說的項(xiàng)目范圍。與需求規(guī)格說明書相比，用例分析通過圖形的方式，更加明確地定義出了項(xiàng)目范圍，以及與其它系統(tǒng)之間的關(guān)系，使其更加清楚明了。

【編輯推薦】

1. UML用例建模的慨念和應(yīng)用
2. 解析UML面向?qū)ο蠓治雠c建模中交互圖
3. UML基礎(chǔ)與應(yīng)用--UML用例圖
4. UML建模過程中需要注意要點(diǎn)專家提醒
5. 體驗(yàn)免費(fèi)UML建模工具