前面 我們講了如何建立用例模型，那么建立用例模型應當注意什么呢？

建立用例模型應當注意的問題

給大家幾個建立用例模型中常出現的問題和應對遵循的原則：

一．如何發現用例

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

當我們開始一個項目的需求分析時，肯定是去聽客戶談他們的需求，或者看客戶提交的業務需求文檔。這其中，客戶一定會提出一個又一個的功能或要求，他們中的每一個就成為了我們最初的用例。分析這些用例，關注它們每一個的參與者，以及它們相互之間的關系，這就形成了最初的用例模型。這里特別應當提醒大家的是，我們采用用例分析的方式與客戶溝通需求的時候，我們應當著重關注的是參與者及其目標，即每個功能的參與者是誰，完成這個功能的目標是什么，以及如何完成這個目標。這時的用例說明采用概述的方式，即只進行主成功場景（基本流程）的描述。

此后，我們繼續與客戶溝通，一方面，繼續細化以后的用例，各個用例的替代場景（分支流程）逐漸被整理出來，用例在一步步細化。同時，我們對一些需求的認識一開始可能存在著偏差，因此我們還不斷在更正我們的用例描述。另一方面，一些新的功能被用戶提出來，形成一些新的用例。

如此反復數輪之后，項目需求的整體框架逐漸清晰，這時候我們開始討論系統邊界。這是，我們需要對我們的用例模型進行一次調整。我們開始考慮哪些系統以外的系統與我們的系統相關，而另一些用例則由于不在系統邊界之內而被剔除。

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

二．什么才是有效用例

在你與客戶溝通的過程中，客戶會提出許多的需求，也就是提出許多對你要實現的這個系統的期望。但是，并不是所有這是都能有效地形成用例。哪些是有效用例，依然有一個評判的標準，我們通常采用三種測試的方法進行評判：老板測試、 EBP 測試、規模測試。

1 ．老板測試。如果老板問你“整天都在做什么”，而你的回答是：“登陸系統”，這顯然不能讓老板高興，因為你的回答不具有可量化的價值。不具有可量化的價值就是不具有提高工作效率、產生有價值結果的操作，即該操作對老板來說沒有價值。如果你寫的用例不具有可量化的價值，則不能通過老板測試，也就不是一個有效用例。老板測試是最低級別的用例有效性測試。

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

一個人于某個時間某個地點，為響應業務事件所執行的任務，如果能增加可量化的業務價值，并且以持久狀態保留下數據，則可以通過 EBP 測試。

EBP 測試用一種更加精確的方式量化了用例的有效性。它除了要求進行有價值的業務操作以外，還必須產生有價值的、持續保留的數據。同時，它還要求了完成這個任務的時效性，即必須在一個會話中完成。持續數日或跨越多個會話的用例都不能通過這個測試。

3 ．規模測試，即一個用例必須達到一定的規模才能算有效。必須達到什么樣的規模呢？通常必須包含多個步驟，在詳述形式的用例說明通常會持續數頁。不能通過規模測試的一個典型錯誤，就是將一系統步驟中的一個作為用例。

一般來說，必須通過以上三個測試才能算是有效用例，但是也存在著例外。譬如，有些為了提高復用性而從用例中提取出來的子用例或擴展用例，可能不能通過 EBP 測試或規模測試，但它們依然是有效用例。另一個特例就是“認證用戶”用例，它可能不能通過老板測試，卻依然是有效的。

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

如題，用例模型的重點是用例說明而不是用例圖。建立用例模型的時候，繪制用例圖可能只花費幾十分鐘，而編寫用例說明卻得花費你數小時甚至數天。用例圖只是給人最直觀的展示，而用例說明才是對業務需求最詳盡的說明。

四．以黑盒的方式編寫用例

黑盒用例（ black-box use case ），是指以職責來描述用例，而不對系統內部的工作、構建或設計進行描述。它體現了 OOD/A 的一個重要思想——封裝性，隱喻了 OOD/A 的一個主題——軟件元素具有職責。因此，黑盒用例是最值得推薦的一種用例編寫方式。

五．以參與者和參與者目標的視點編寫用例

用例的創立者 Ivar Jacobson 是這樣定義用例的：用例的執行應當產生“對特定參與者具有價值的可觀察結果”。在 Jacobson 的定義中傳達的一個重要信息就是，什么是對這個參與者有價值的。因此，用例分析的兩個重要視點就是：關注參與者期望達到的目標，關注參與者認為有價值的結果。我們在編寫用例說明的時候，就應當以這兩個視點來進行編寫。

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

這是一些人（包括我）常犯的錯?！包c擊××按鈕”、“顯示××列表”都是不應當出現在用例描述的文字中的。界面設計應當交給原型設計或界面設計階段完成，而不是用例設計階段。用例分析應當摒除用戶界面的思考，而將全部精力關注于參與者的意圖。

七．再談談采用迭代的方式構建用例

在本文中，我已經反復強調了采用迭代的方式構建用例。迭代是 RUP 以及后來的敏捷開發所大力提倡的一種開發方式，它從理論上徹底打破了過去的瀑布式開發理論。迭代開發包含了以下幾個思想：

1 ．從整體逐漸細化的過程。人類認識事物總是從整體到局部逐漸細化的一個過程，而迭代開發也體現了這一客觀規律。在需求分析的初期，我們總是將系統分為幾個大的用例，為每個大的用例，繪制幾個最主要的用例出來。而對于每個用例的說明，采用概述的方式，僅僅寫出主成功場景。然后，隨著一次一次的迭代，我們在不斷豐富我們的用例，而用例說明的方式也漸漸變為非正式的方式，最終改為詳盡的方式，寫出完整的用例圖和用例說明。

2 ．將大段的開發進程劃分成了無數小的階段。一次軟件開發項目往往持續數月，甚至超過一年。而需求分析，也常常持續數月。許多項目開發團隊不能按時完成開發任務，或者不能從容地完成開發任務，一個非常重要的原因就是，在項目執行過程中，并沒有隨時評估自己的進度是否走在正常軌道上，也就沒有及時將偏離的進度拉回到正常的軌道上來。人造衛星和宇航飛機能夠隨時矯正自己的軌道，是因為它們在定期檢測自己是否偏離軌道，項目管理也同樣需要。如何定期檢測項目進度是否在正常軌道呢？答案是迭代。迭代將持續數月的需求分析劃分成了為期 1 ～ 2 周的一個個迭代期。每個迭代期在項目計劃時都有一個目標，即該迭代期完成是項目應當進展到什么程度。在項目執行過程中，每個迭代期都要進行計劃、執行、總結三個階段的工作（如果迭代期為 1 周，通常是周一做計劃，然后開始執行，直到周五開始總結）。在進行總結時，對比該迭代期應當完成的目標，就可以判斷項目進度是否在正常軌道，從而進行必要的調整。

3 ．它強調的是與客戶的反復溝通。按照敏捷開發的思想，業務變更是無所不在，正如那句經典的話： I changed when I saw it （當我看到軟件時，需求就開始變更了）。瀑布式開發理論之所以失敗，正是因為拒絕了這種與客戶的溝通，武斷地認為，需求確認以后就不能再變更，也就不再需要與客戶繼續進行溝通。 按照敏捷開發的思想，每次與客戶溝通，都應當將客戶的意見體現到設計開發中。然而，在將客戶的意見體現到設計開發以后，需要尋找一個合適的時候與客戶進行反饋，讓客戶確認這樣的設計是否符合他的要求。沒有及時地與客戶進行反饋，就不能保證項目的進展是否偏離了客戶的需求?；氐接美治鲞@個主題上，用例分析應當分成無數個迭代期，每個迭代期都應當包含與客戶確認需求、進行用例分析、與客戶進行反饋三個階段。同時，用例分析還將持續到需求分析以后的整個項目開發過程中。

用例分析的總結

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

后記

我從小到大讀書有一個特點，就是不求甚解。一本書，特別是技術書籍，從來沒有興趣從頭到尾把它讀完過。即使感興趣的章節，也從來不愿一字一句地去讀。翻看目錄是我主要干的事情。因為這樣的讀書方式，我小時候的成績一定好不了，我卻總是能去粗取精，把許多知識的精華握在胸中，跳出書本去思考許多更重要的東西。我看的書總是越看越薄，然后跳出來評判作者思想的得與失。正可謂：當局者迷，旁觀者清。

我寫這些文章的目的，就是幫你把書讀薄，去粗取精，最后留下真正重要的問題與你討論。在寫作過程中，我會將整個文章分成了數個大章，數個小節。每個章節，我都通過簡短的語言，說明我下面要說的內容。你不必一章一節地挨著看，只看你感興趣的部分，不求甚解，這就是柳宗元先生給我們的最大啟示。

參考文獻

中文名：《 UML 和模式應用》

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

作者：（美） Craig Larman

?

? 相關文章：

?《 談談用例模型那些事兒 之 用例圖 》

?《 談談用例模型那些事兒 之 用例說明 》

談談用例模型的那些事兒 之 注意什么