什么是用例和用例描述

1、我發(fā)現(xiàn)，在OO和UML幾乎一統(tǒng)天下的今天，仍有很多系統(tǒng)分析員對OO和UML一知半解，甚至包括很多已經(jīng)使用了很久UML的系統(tǒng)分析員。于是打算寫一個系列文章，將多年來的工作經(jīng)驗做一個總結(jié)。對初學(xué)者起個啟蒙作用，也希望拋磚引喻，與各路大蝦共同探討，共同提高。這個系列文章將以我對OO和系統(tǒng)分析的理解為主，從UML基礎(chǔ)開始，闡述面向?qū)ο蟮男枨蠓治龇椒?，過程，并以RUP為例，闡述如何將OO過程與軟件過程有機結(jié)合在一起，做一個真正OO應(yīng)用。好了，今天是第一篇。想得很遠，不知能否堅持下去，呵呵:lol:用例是什么？其原始英文是usecase，直譯過來就成了用例。這也是一個比較貼切的叫法了，從字面的直接理解就是

2、使用的例子。另一種比較流行的定義是用例就是與使用者(actor)交互的，并且給使用者提供可觀測的有意義的結(jié)果的一系列活動的集合。這個定義還是比較費解的，筆者在眾多應(yīng)聘者中發(fā)現(xiàn)很多使用用例來做需求的系統(tǒng)分析員，有的已經(jīng)使用了兩年以上，但仍不能把握用例的本質(zhì)，雖然他們號稱精通UML。最具普遍意義的理解錯誤是認(rèn)為用例就是功能的劃分和描述，認(rèn)為一個用例就是一個功能點。在這種理解下，用例變成了僅僅是較早前需求中功能框圖的翻版，很多人用用例來劃分子系統(tǒng)，功能模塊和功能點。如果這樣，用例根本沒有存在的必要。有意思的是，造成這種理解錯誤的相當(dāng)一部分原因卻是因為對OO思想的理解不夠深入，本質(zhì)上說，把用例當(dāng)成功能

3、點的系統(tǒng)分析員腦子里還是面向過程的那一套思想，雖然他們在使用OO的工具，OO的語言，號稱在做面向?qū)ο蟮拈_發(fā)，但過程的影子還沒有從他們腦子里徹底抹去。如果用例不是功能的話，它是什么呢？從定義上說，能給使用者提供一個執(zhí)行結(jié)果的活動，不就是功能嗎？我的回答是：錯！功能是計算機術(shù)語，它是用來描述計算機的，而非定義需求的術(shù)語。功能實際描述的是輸入->計算->輸出。這讓你想到了什么？DFD圖？這可是典型的面向過程分析模式。因此我說把用例當(dāng)做功能點的分析員實際在做面向過程的分析。推薦精選而用例則不是計算機術(shù)語，UML除了在計算機行業(yè)中應(yīng)用，它也經(jīng)常被應(yīng)用在其它行業(yè)中。用例是一種需求方法學(xué)，雖然軟

4、件危機和OO的發(fā)展促成了它的誕生并被完美的融合進了OO體系，形成了UML，但它實際上并不是軟件行業(yè)的專用品。如果非要從功能的角度解釋，那么用例可以解釋為一系列完成一個特定目標(biāo)的“功能”的組合，針對不同的應(yīng)用場景，這些“功能”體現(xiàn)不同的組合方式。實際上，把用例解釋為某個參與者(actor)要做的一件事可能更為合適。這樣的一件事有以下幾個特征：一、這件事是相對獨立的。這意味著它不需要與其它用例交互而獨自完成參與者的目的。也就是說這件事從“功能”上說是完備的。讀者可能會想到，用例之間不是也有關(guān)聯(lián)關(guān)系嗎？比如擴展，比如實現(xiàn)，比如繼承，它看上去并不是獨立的嘛。關(guān)于這個問題，筆者會在后續(xù)的文章里詳細(xì)說明。

5、這里稍微解釋一下，用例之間的關(guān)系是分析過程的產(chǎn)物，而且這種關(guān)系一般的產(chǎn)生在概念層用例階段和系統(tǒng)層用例階段。對于業(yè)務(wù)用例，這個特征是很明顯的。 二、這件事的執(zhí)行結(jié)果對參與者來說是可觀測的和有意義的。例如，系統(tǒng)會監(jiān)控參與者在系統(tǒng)里的操作，并在參與者刪除數(shù)據(jù)之前備份。雖然它是系統(tǒng)的一個必需組成部分，但它在需求階段卻不應(yīng)該作為用例出現(xiàn)。因為這是一個后臺進程，對參與者來說是不可觀測的，它應(yīng)該在系統(tǒng)用例分析階段定義。又比如說，登錄系統(tǒng)是一個有效的用例，但輸入密碼卻不是。這是因為登錄系統(tǒng)對參與者是有意義的，這樣他可以獲得身份認(rèn)證和授權(quán)，但輸入密碼卻是沒有意義的，輸入完了呢？有什么結(jié)果嗎？ 三、這件事必須由一

6、個參與者發(fā)起。不存在沒有參與者的用例，用例不應(yīng)該自動啟動，也不應(yīng)該主動啟動另一個用例。用例總是由一個參與者發(fā)起，并且滿足特征二。例如從ATM取錢是一個有效的用例，ATM吐鈔卻不是。因為ATM是不會無緣無故吐鈔的，否則，我從此天天守在ATM旁，生活無憂矣。 四、這件事必然是以動賓短語形式出現(xiàn)的。即，這件事必須有一個動作和動作的受體。例如，喝水是一個有效的用例，而“喝”和“水”卻不是。雖然生活常識告訴我們，在沒有水的情況下人是不會做出喝這個動作的，水也必然是喝進去的，而不是滑進去的，但是筆者所見的很多用例中類似“計算”，“統(tǒng)計”，“報表”，“輸出”，“錄入”之類的并不在少數(shù)。推薦精選除去以上的特征

7、，筆者覺得用例的含義還要更深些。首先，用例的背后是一種需求方法論。其核心是以參與者為中心（區(qū)別于以計算機系統(tǒng)為中心），從參與者的角度來描述他要做的日常工作（區(qū)別于以業(yè)務(wù)流程描述的方式），并分析這些日常工作之間是如何交互的（區(qū)別于數(shù)據(jù)流的描述方式）。換句話說，用例分析的首要目標(biāo)不是要弄清楚某項業(yè)務(wù)是如何一步一步完成的，而是要弄清楚有多少參與者？每個參與者都做什么？業(yè)務(wù)流程分析則是后續(xù)的工作了。其次，用例簡直就是為OO而生的，其思想完美的符合OO。用例分析方法試圖找到問題領(lǐng)域內(nèi)所有相對獨立的參與者和事件，并把業(yè)務(wù)流程當(dāng)成是這些參與者和事件之間的交互結(jié)果（在UML用活動圖或序列圖來描述）。因此，用例

8、方法被吸納到OO之后，UML得以以完備的形式出現(xiàn)，用例成為了真正的OO核心。在RUP里，這種核心作用被發(fā)揮到極致，產(chǎn)生了用例驅(qū)動（usecase driven）的軟件過程方法，在RUP里，軟件生產(chǎn)的所有過程和產(chǎn)物都是圍繞著用例形成的?？梢哉f，用例分析是OO的第一步。如果用例分析本身出了問題，對業(yè)務(wù)架構(gòu)，軟件架構(gòu)的影響是很大的，將大大削弱OO的優(yōu)勢-復(fù)用、擴展。筆者認(rèn)為軟件復(fù)用可以分為三個層次，最低層次的復(fù)用是代碼級復(fù)用，這是由OO語言特性提供支持的，例如繼承，聚合，多態(tài)；較高層次的復(fù)用是組件級復(fù)用，這是由設(shè)計模式提供支持的，例如Factory模式,Builder模式；最高層次的復(fù)用則是服務(wù)級復(fù)

9、用，這在很大程度上是由應(yīng)用服務(wù)器和通訊協(xié)議來提供支持的，例如最近炒得火熱的SOA（面向服務(wù)的應(yīng)用）架構(gòu)。用例分析的好壞也許對代碼級和組件級的復(fù)用影響不太大，但對服務(wù)級的復(fù)用影響卻是巨大的。筆者認(rèn)為服務(wù)級復(fù)用是OO的最高境界，而結(jié)構(gòu)良好的用例分析則是達到這一境界的基礎(chǔ)。閑話： 今天你OO了嗎？ 如果你的分析習(xí)慣是在調(diào)研需求時最先弄清楚有多少業(yè)務(wù)流程，先畫出業(yè)務(wù)流程圖，然后順藤摸瓜，找出業(yè)務(wù)流程中每一步驟的參與部門或崗位，弄清楚在這一步參與者所做的事情和填寫表單的結(jié)果，并關(guān)心用戶是如何把這份表單傳給到下一個環(huán)節(jié)的。那么很不幸，你還在做面向過程的事情。推薦精選如果你的分析習(xí)慣是在調(diào)研需求時最先弄清楚

10、有多少部門，多少崗位，然后找到每一個崗位的業(yè)務(wù)代表，問他們類似的問題：你平時都做什么？這件事是誰交辦的？做完了你需要通知或傳達給誰嗎？做這件事情你都需要填寫些什么表格嗎？.那么恭喜你，你已經(jīng)OO啦！用例組成當(dāng)記錄基于組件的系統(tǒng)的行為需求時，用例是最常用的技術(shù)之一。開發(fā)人員常問的一個問題是，“用例文檔應(yīng)該包括哪些信息？”盡管我在此提到的一些部分是可選的，但在我看來，將這些部分包括在用例文檔中不失為一個好主意。當(dāng)編寫基本用例的文檔時（另請參閱前一篇技巧 Modelling essential use cases），我傾向于略去可選部分（因為基本用例關(guān)注的是是什么，而不是 為什么，因此不必像系統(tǒng)用例

11、那樣復(fù)雜）。當(dāng)編寫系統(tǒng)用例時，我通常將所有部分都包括在內(nèi)?；仡櫼幌拢居美拖到y(tǒng)用例之間的主要區(qū)別是，系統(tǒng)用例包括了高級實現(xiàn)決策，而基本用例是要以與技術(shù)和實現(xiàn)無關(guān)的方式捕捉用戶的意圖。參與者 (actor) 和被包含的用例這兩個部分實際上只看用例圖即可確定。但是，按我的經(jīng)驗，各個用例最好相互獨立 換句話說，用例應(yīng)該包含理解它們所需的全部關(guān)鍵信息以及它們所在的上下文。這使您的主題問題專家 (SME) 能夠分別充實各個用例。（他們可能上午以小組為單位協(xié)同工作，下午則各自獨立地以最快的速度充實所分配的用例，從而提高了整個小組的生產(chǎn)效率。）用例的各個組成部分名稱。名稱無疑應(yīng)該表明用戶的意圖或用例的用

12、途，如“研究班招生”。 標(biāo)識符 可選。唯一標(biāo)識符，如 "UC1701"，在項目的其他元素（如類模型）中可用它來引用這個用例。 說明。概述用例的幾句話。 參與者 可選。與此用例相關(guān)的參與者列表。盡管這則信息包含在用例本身中，但在沒有用例圖時，它有助于增加對該用例的理解。 狀態(tài) 可選。指示用例的狀態(tài)，通常為以下幾種之一：進行中、等待審查、通過審查或未通過審查。 頻率。參與者訪問此用例的頻率。這是一個自由式問題，如用戶每次錄訪問一次或每月一次。 前置條件。一個條件列表，如果其中包含條件，則這些條件必須在訪問用例之前得到滿足。 后置條件。一個條件列表，如果其中包含條件，則這些條件將

13、在用例成功完成以后得到滿足。 被擴展的用例 可選。此用例所擴展的用例（如果存在）。擴展關(guān)聯(lián)是一種廣義關(guān)系，其中擴展用例接續(xù)基用例的行為。這是通過擴展用例向基用例的操作序列中插入附加的操作序列來實現(xiàn)的。這總是使用帶有 <<extend>> 的用例關(guān)聯(lián)來建模的。 推薦精選被包含的用例 可選。此用例所包含用例的列表。包含關(guān)聯(lián)是一種廣義關(guān)系，它表明對處于另一個用例之中的用例所描述的行為的包含關(guān)系。這總是使用帶有 <<include>> 的用例關(guān)聯(lián)來建模的。也稱為使用或具有 (has-a) 關(guān)系。 假設(shè) 可選。對編寫此用例時所創(chuàng)建的域的任何重要假設(shè)。您應(yīng)該在一定的時候檢驗這些假設(shè)，或者將它們變?yōu)闆Q策的一部分（請參閱下文），或者將它們添加到操作的基本流程或可選流程中。 基本操作流程。參與者在用例中所遵循的主邏輯路徑。因為它描述了當(dāng)各項工作都正常進行時用例的工作方式，所以通常稱其為 適當(dāng)路徑 (happy path) 或主路徑 (main path) 。 可選操作流程。用例中很少使用的