前面 我們講了如何建立用例模型，那么建立用例模型應(yīng)當(dāng)注意什么呢？

建立用例模型應(yīng)當(dāng)注意的問(wèn)題

給大家?guī)讉€(gè)建立用例模型中常出現(xiàn)的問(wèn)題和應(yīng)對(duì)遵循的原則：

一．如何發(fā)現(xiàn)用例

經(jīng)過(guò)以上的講解，相信大家對(duì)建立用例模型有了一個(gè)整體的概念，然后開(kāi)始著手練習(xí)繪制用例模型。這時(shí)候，一個(gè)非常嚴(yán)峻的問(wèn)題出現(xiàn)了：如何發(fā)現(xiàn)用例。大師曾經(jīng)給出了答案，大致意思就是：首先選擇系統(tǒng)邊界，然后確定主要參與者，定義滿足用戶目標(biāo)的用例，為其命名。然而，我在實(shí)踐中證明，這套方法過(guò)于理論，并不實(shí)用。也許，我們換一種思路會(huì)更加符合實(shí)際。

當(dāng)我們開(kāi)始一個(gè)項(xiàng)目的需求分析時(shí)，肯定是去聽(tīng)客戶談他們的需求，或者看客戶提交的業(yè)務(wù)需求文檔。這其中，客戶一定會(huì)提出一個(gè)又一個(gè)的功能或要求，他們中的每一個(gè)就成為了我們最初的用例。分析這些用例，關(guān)注它們每一個(gè)的參與者，以及它們相互之間的關(guān)系，這就形成了最初的用例模型。這里特別應(yīng)當(dāng)提醒大家的是，我們采用用例分析的方式與客戶溝通需求的時(shí)候，我們應(yīng)當(dāng)著重關(guān)注的是參與者及其目標(biāo)，即每個(gè)功能的參與者是誰(shuí)，完成這個(gè)功能的目標(biāo)是什么，以及如何完成這個(gè)目標(biāo)。這時(shí)的用例說(shuō)明采用概述的方式，即只進(jìn)行主成功場(chǎng)景（基本流程）的描述。

此后，我們繼續(xù)與客戶溝通，一方面，繼續(xù)細(xì)化以后的用例，各個(gè)用例的替代場(chǎng)景（分支流程）逐漸被整理出來(lái)，用例在一步步細(xì)化。同時(shí)，我們對(duì)一些需求的認(rèn)識(shí)一開(kāi)始可能存在著偏差，因此我們還不斷在更正我們的用例描述。另一方面，一些新的功能被用戶提出來(lái)，形成一些新的用例。

如此反復(fù)數(shù)輪之后，項(xiàng)目需求的整體框架逐漸清晰，這時(shí)候我們開(kāi)始討論系統(tǒng)邊界。這是，我們需要對(duì)我們的用例模型進(jìn)行一次調(diào)整。我們開(kāi)始考慮哪些系統(tǒng)以外的系統(tǒng)與我們的系統(tǒng)相關(guān)，而另一些用例則由于不在系統(tǒng)邊界之內(nèi)而被剔除。

如此迭代數(shù)次，才最終形成我們需要的用例模型。

二．什么才是有效用例

在你與客戶溝通的過(guò)程中，客戶會(huì)提出許多的需求，也就是提出許多對(duì)你要實(shí)現(xiàn)的這個(gè)系統(tǒng)的期望。但是，并不是所有這是都能有效地形成用例。哪些是有效用例，依然有一個(gè)評(píng)判的標(biāo)準(zhǔn)，我們通常采用三種測(cè)試的方法進(jìn)行評(píng)判：老板測(cè)試、 EBP 測(cè)試、規(guī)模測(cè)試。

1 ．老板測(cè)試。如果老板問(wèn)你“整天都在做什么”，而你的回答是：“登陸系統(tǒng)”，這顯然不能讓老板高興，因?yàn)槟愕幕卮鸩痪哂锌闪炕膬r(jià)值。不具有可量化的價(jià)值就是不具有提高工作效率、產(chǎn)生有價(jià)值結(jié)果的操作，即該操作對(duì)老板來(lái)說(shuō)沒(méi)有價(jià)值。如果你寫(xiě)的用例不具有可量化的價(jià)值，則不能通過(guò)老板測(cè)試，也就不是一個(gè)有效用例。老板測(cè)試是最低級(jí)別的用例有效性測(cè)試。

2 ． EBP 測(cè)試（ Elementary Business Process ），它的定義如下：

一個(gè)人于某個(gè)時(shí)間某個(gè)地點(diǎn)，為響應(yīng)業(yè)務(wù)事件所執(zhí)行的任務(wù)，如果能增加可量化的業(yè)務(wù)價(jià)值，并且以持久狀態(tài)保留下數(shù)據(jù)，則可以通過(guò) EBP 測(cè)試。

EBP 測(cè)試用一種更加精確的方式量化了用例的有效性。它除了要求進(jìn)行有價(jià)值的業(yè)務(wù)操作以外，還必須產(chǎn)生有價(jià)值的、持續(xù)保留的數(shù)據(jù)。同時(shí)，它還要求了完成這個(gè)任務(wù)的時(shí)效性，即必須在一個(gè)會(huì)話中完成。持續(xù)數(shù)日或跨越多個(gè)會(huì)話的用例都不能通過(guò)這個(gè)測(cè)試。

3 ．規(guī)模測(cè)試，即一個(gè)用例必須達(dá)到一定的規(guī)模才能算有效。必須達(dá)到什么樣的規(guī)模呢？通常必須包含多個(gè)步驟，在詳述形式的用例說(shuō)明通常會(huì)持續(xù)數(shù)頁(yè)。不能通過(guò)規(guī)模測(cè)試的一個(gè)典型錯(cuò)誤，就是將一系統(tǒng)步驟中的一個(gè)作為用例。

一般來(lái)說(shuō)，必須通過(guò)以上三個(gè)測(cè)試才能算是有效用例，但是也存在著例外。譬如，有些為了提高復(fù)用性而從用例中提取出來(lái)的子用例或擴(kuò)展用例，可能不能通過(guò) EBP 測(cè)試或規(guī)模測(cè)試，但它們依然是有效用例。另一個(gè)特例就是“認(rèn)證用戶”用例，它可能不能通過(guò)老板測(cè)試，卻依然是有效的。

三．用例模型的核心是文字，而不是圖形

如題，用例模型的重點(diǎn)是用例說(shuō)明而不是用例圖。建立用例模型的時(shí)候，繪制用例圖可能只花費(fèi)幾十分鐘，而編寫(xiě)用例說(shuō)明卻得花費(fèi)你數(shù)小時(shí)甚至數(shù)天。用例圖只是給人最直觀的展示，而用例說(shuō)明才是對(duì)業(yè)務(wù)需求最詳盡的說(shuō)明。

四．以黑盒的方式編寫(xiě)用例

黑盒用例（ black-box use case ），是指以職責(zé)來(lái)描述用例，而不對(duì)系統(tǒng)內(nèi)部的工作、構(gòu)建或設(shè)計(jì)進(jìn)行描述。它體現(xiàn)了 OOD/A 的一個(gè)重要思想——封裝性，隱喻了 OOD/A 的一個(gè)主題——軟件元素具有職責(zé)。因此，黑盒用例是最值得推薦的一種用例編寫(xiě)方式。

五．以參與者和參與者目標(biāo)的視點(diǎn)編寫(xiě)用例

用例的創(chuàng)立者 Ivar Jacobson 是這樣定義用例的：用例的執(zhí)行應(yīng)當(dāng)產(chǎn)生“對(duì)特定參與者具有價(jià)值的可觀察結(jié)果”。在 Jacobson 的定義中傳達(dá)的一個(gè)重要信息就是，什么是對(duì)這個(gè)參與者有價(jià)值的。因此，用例分析的兩個(gè)重要視點(diǎn)就是：關(guān)注參與者期望達(dá)到的目標(biāo)，關(guān)注參與者認(rèn)為有價(jià)值的結(jié)果。我們?cè)诰帉?xiě)用例說(shuō)明的時(shí)候，就應(yīng)當(dāng)以這兩個(gè)視點(diǎn)來(lái)進(jìn)行編寫(xiě)。

六．不要描述任何用戶界面

這是一些人（包括我）常犯的錯(cuò)。“點(diǎn)擊××按鈕”、“顯示××列表”都是不應(yīng)當(dāng)出現(xiàn)在用例描述的文字中的。界面設(shè)計(jì)應(yīng)當(dāng)交給原型設(shè)計(jì)或界面設(shè)計(jì)階段完成，而不是用例設(shè)計(jì)階段。用例分析應(yīng)當(dāng)摒除用戶界面的思考，而將全部精力關(guān)注于參與者的意圖。

七．再談?wù)劜捎玫姆绞綐?gòu)建用例

在本文中，我已經(jīng)反復(fù)強(qiáng)調(diào)了采用迭代的方式構(gòu)建用例。迭代是 RUP 以及后來(lái)的敏捷開(kāi)發(fā)所大力提倡的一種開(kāi)發(fā)方式，它從理論上徹底打破了過(guò)去的瀑布式開(kāi)發(fā)理論。迭代開(kāi)發(fā)包含了以下幾個(gè)思想：

1 ．從整體逐漸細(xì)化的過(guò)程。人類(lèi)認(rèn)識(shí)事物總是從整體到局部逐漸細(xì)化的一個(gè)過(guò)程，而迭代開(kāi)發(fā)也體現(xiàn)了這一客觀規(guī)律。在需求分析的初期，我們總是將系統(tǒng)分為幾個(gè)大的用例，為每個(gè)大的用例，繪制幾個(gè)最主要的用例出來(lái)。而對(duì)于每個(gè)用例的說(shuō)明，采用概述的方式，僅僅寫(xiě)出主成功場(chǎng)景。然后，隨著一次一次的迭代，我們?cè)诓粩嘭S富我們的用例，而用例說(shuō)明的方式也漸漸變?yōu)榉钦降姆绞剑罱K改為詳盡的方式，寫(xiě)出完整的用例圖和用例說(shuō)明。

2 ．將大段的開(kāi)發(fā)進(jìn)程劃分成了無(wú)數(shù)小的階段。一次軟件開(kāi)發(fā)項(xiàng)目往往持續(xù)數(shù)月，甚至超過(guò)一年。而需求分析，也常常持續(xù)數(shù)月。許多項(xiàng)目開(kāi)發(fā)團(tuán)隊(duì)不能按時(shí)完成開(kāi)發(fā)任務(wù)，或者不能從容地完成開(kāi)發(fā)任務(wù)，一個(gè)非常重要的原因就是，在項(xiàng)目執(zhí)行過(guò)程中，并沒(méi)有隨時(shí)評(píng)估自己的進(jìn)度是否走在正常軌道上，也就沒(méi)有及時(shí)將偏離的進(jìn)度拉回到正常的軌道上來(lái)。人造衛(wèi)星和宇航飛機(jī)能夠隨時(shí)矯正自己的軌道，是因?yàn)樗鼈冊(cè)诙ㄆ跈z測(cè)自己是否偏離軌道，項(xiàng)目管理也同樣需要。如何定期檢測(cè)項(xiàng)目進(jìn)度是否在正常軌道呢？答案是迭代。迭代將持續(xù)數(shù)月的需求分析劃分成了為期 1 ～ 2 周的一個(gè)個(gè)迭代期。每個(gè)迭代期在項(xiàng)目計(jì)劃時(shí)都有一個(gè)目標(biāo)，即該迭代期完成是項(xiàng)目應(yīng)當(dāng)進(jìn)展到什么程度。在項(xiàng)目執(zhí)行過(guò)程中，每個(gè)迭代期都要進(jìn)行計(jì)劃、執(zhí)行、總結(jié)三個(gè)階段的工作（如果迭代期為 1 周，通常是周一做計(jì)劃，然后開(kāi)始執(zhí)行，直到周五開(kāi)始總結(jié)）。在進(jìn)行總結(jié)時(shí)，對(duì)比該迭代期應(yīng)當(dāng)完成的目標(biāo)，就可以判斷項(xiàng)目進(jìn)度是否在正常軌道，從而進(jìn)行必要的調(diào)整。

3 ．它強(qiáng)調(diào)的是與客戶的反復(fù)溝通。按照敏捷開(kāi)發(fā)的思想，業(yè)務(wù)變更是無(wú)所不在，正如那句經(jīng)典的話： I changed when I saw it （當(dāng)我看到軟件時(shí)，需求就開(kāi)始變更了）。瀑布式開(kāi)發(fā)理論之所以失敗，正是因?yàn)榫芙^了這種與客戶的溝通，武斷地認(rèn)為，需求確認(rèn)以后就不能再變更，也就不再需要與客戶繼續(xù)進(jìn)行溝通。 按照敏捷開(kāi)發(fā)的思想，每次與客戶溝通，都應(yīng)當(dāng)將客戶的意見(jiàn)體現(xiàn)到設(shè)計(jì)開(kāi)發(fā)中。然而，在將客戶的意見(jiàn)體現(xiàn)到設(shè)計(jì)開(kāi)發(fā)以后，需要尋找一個(gè)合適的時(shí)候與客戶進(jìn)行反饋，讓客戶確認(rèn)這樣的設(shè)計(jì)是否符合他的要求。沒(méi)有及時(shí)地與客戶進(jìn)行反饋，就不能保證項(xiàng)目的進(jìn)展是否偏離了客戶的需求。回到用例分析這個(gè)主題上，用例分析應(yīng)當(dāng)分成無(wú)數(shù)個(gè)迭代期，每個(gè)迭代期都應(yīng)當(dāng)包含與客戶確認(rèn)需求、進(jìn)行用例分析、與客戶進(jìn)行反饋三個(gè)階段。同時(shí)，用例分析還將持續(xù)到需求分析以后的整個(gè)項(xiàng)目開(kāi)發(fā)過(guò)程中。

用例分析的總結(jié)

又到總結(jié)時(shí)間了，每到這個(gè)時(shí)刻我總是千言萬(wàn)語(yǔ)不知從何說(shuō)起。我用了如此多的篇幅說(shuō)明了什么是用例模型，它與需求規(guī)格說(shuō)明書(shū)的區(qū)別以及優(yōu)勢(shì)。用例模型代表了先進(jìn)的設(shè)計(jì)思想和方法，他可以完全替代需求規(guī)格說(shuō)明書(shū)，但遺憾的是它至今還為我們所忽視（這也正是我寫(xiě)這篇文章的目的之一）。當(dāng)然，你可能會(huì)說(shuō)，許多客戶依然要求我們編寫(xiě)需求規(guī)格說(shuō)明書(shū)作為需求確認(rèn)的指定文檔。許多單位的質(zhì)量管理手冊(cè)也要求我們必須編寫(xiě)需求規(guī)格說(shuō)明書(shū)，作為質(zhì)量管理的一個(gè)部分。確實(shí)，需求規(guī)格說(shuō)明書(shū)至今依然有大量 fans ，但我不得不替需求規(guī)格說(shuō)明書(shū)說(shuō)：不要迷戀哥，哥只是一個(gè)傳說(shuō)。說(shuō)服客戶和主管改用用例分析也許需要一定的時(shí)間，然而，采用需求分析過(guò)程是用例分析，最終結(jié)果寫(xiě)成需求規(guī)格說(shuō)明書(shū)，不失是另一個(gè)曲線救國(guó)的方式吧。

后記

我從小到大讀書(shū)有一個(gè)特點(diǎn)，就是不求甚解。一本書(shū)，特別是技術(shù)書(shū)籍，從來(lái)沒(méi)有興趣從頭到尾把它讀完過(guò)。即使感興趣的章節(jié)，也從來(lái)不愿一字一句地去讀。翻看目錄是我主要干的事情。因?yàn)檫@樣的讀書(shū)方式，我小時(shí)候的成績(jī)一定好不了，我卻總是能去粗取精，把許多知識(shí)的精華握在胸中，跳出書(shū)本去思考許多更重要的東西。我看的書(shū)總是越看越薄，然后跳出來(lái)評(píng)判作者思想的得與失。正可謂：當(dāng)局者迷，旁觀者清。

我寫(xiě)這些文章的目的，就是幫你把書(shū)讀薄，去粗取精，最后留下真正重要的問(wèn)題與你討論。在寫(xiě)作過(guò)程中，我會(huì)將整個(gè)文章分成了數(shù)個(gè)大章，數(shù)個(gè)小節(jié)。每個(gè)章節(jié)，我都通過(guò)簡(jiǎn)短的語(yǔ)言，說(shuō)明我下面要說(shuō)的內(nèi)容。你不必一章一節(jié)地挨著看，只看你感興趣的部分，不求甚解，這就是柳宗元先生給我們的最大啟示。

參考文獻(xiàn)

中文名：《 UML 和模式應(yīng)用》

英文名： Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development

作者：（美） Craig Larman

?

? 相關(guān)文章：

?《 談?wù)動(dòng)美Ｐ湍切┦聝?之 用例圖 》

?《 談?wù)動(dòng)美Ｐ湍切┦聝?之 用例說(shuō)明 》

談?wù)動(dòng)美Ｐ偷哪切┦聝?之 注意什么