走出用例圖誤區

    uml初學者，大部分都是從認識用例圖開始。記得我剛學uml的時候，導師就再三跟我強調，uml只是一門工具，不是爲了畫圖而畫圖。這句話聽來並不難理解，但真要在實際項目中領悟參透還是需要一段時日的。它反應在各種需求建模的細節中。
    uml用例圖也並未很難畫，各種用例的間的關係也不是很難理解。對於初學者來說，很容易把重點放到uml用例圖上，而忽視了用例文本（用例規格說明）的編寫。高手提取幾個用例會很輕鬆，但要編寫嚴格、乾淨、邏輯性強的用例文本卻非易事。所以，用例文本的編寫很容易看出一個分析/設計人員的水準。
    用例圖可以直觀地展現需求中的所有用例、參與者、系統邊界，以及它們之間的關係，但這還不足以表達需求分析所要求表達的內容。用例圖必須輔之以用例說明，才能完整清楚地表達。用例模型是需求分析階段的主要成果，因此它擔負的職責繁重。用例模型必須做到以下要求：  
1、語言的互通。用例模型採用的語言必須達到，既能讓業務人員看懂，以便給予業務確認，又能讓技術人員看懂，以便進行日後的設計開發。因此，用例模型的描述必須是對業務需求最平實的表述，站在業務人員的角度說事兒，不能參雜過多的技術語言。同時，又要站在技術的角度進行分析，詳細清楚地表述各個功能的操作流程，並不能使用過於專業的業務術語，或者對必要的業務術語進行解釋，讓技術人員看懂。
2、清晰準確。用例模型必須清晰準確地表達每一個業務需求，因此我們在建立用例模型的時候，必須明確每一個術語，每一段表述，不能存在二義性。
3、最全面和詳盡的業務需求。用例模型必須從各個角度，全面地反映客戶對系統的期望。用例模型對業務需求把握得越全面和詳盡，項目出現偏差和風險的機率就越小。這要求我們進行分析時，各個角度都要分析到。
要做到以上幾點其實並不容易，所幸的是，用例說明爲我們提供了一個良好的範例。用例說明在用例模型中的作用，甚至超過了用例圖。寥寥幾頁的用例圖，需要數十頁甚至上百頁的用例說明來描述。用例說明需要按照一定的格式，對所有用例圖中的所有用例進行描述，如果有必要，還要對參與者、系統邊界和部分術語進行描述。下面我們來看看用例說明是怎樣編寫的。
按照用例分析的特點，用例說明也應當從粗到細依次進行編寫。首先是對整個系統進行概述，編寫總用例圖的說明，然後依次編寫各個支用例圖的說明。在編寫每個用例圖時，首先貼上該用例圖，然後爲每個用例編寫說明。
下面就是從主用例圖開始，依次對所有用例圖進行說明。在對每個用例圖進行說明時，先貼出用例圖，然後爲每個用例編寫說明。在這部分，每個用例的說明可以按照如下格式編寫：
用例標識：用例的編號。
用例名稱：根據用例表達的功能而取的簡短明瞭的名稱。用例命名其實是有講究的，即必須是一個動詞短語或句子，而不是一個名詞短語，通常建議爲一個動賓短語（如：提取存款），一個被動句（如：發票填報），或者一個主謂句（如：用戶提款）。用例的命名錶現了用例的特點，即它代表的是參與者的操作，是一個動作。儘量不要取 “××管理”或“維護××”，因爲這個動作應當是一個非常明確的動作，而“××管理”代表的是插入、修改、刪除等一系列動作，操作就變得不明確了。
應用範圍：就是要設計的系統。
用例類型：“用戶目標”還是“子功能”，即是用戶需要操作的目標功能，還是從“用戶目標”中提取出來的“子功能”。“用戶目標”應當至少有一個參與者，來驅動它完成相關操作，而“子功能”通常沒有，因爲它往往是被系統所驅動。
用例描述：對該用例的功能定義、要實現的業務需求，以及誰（參與者）如何進行使用進行描述。同時，這部分還可以整體概述實現業務需求的主要流程，以及與其它用例、其它外部系統的關係。
參與者：列出與該用例相關的參與者，包括進行操作的人（角色）和相關的外部系統。
涉衆利益：關注該用例的人對該用例的要求，它往往是非功能需求，或者是功能需求中的一些常常爲我們所忽視的細節。如客戶要求在填寫一些表單的時候能夠快速進行查找，而另一些系統管理員希望提高可維護性（雖然他們可能不是該用例的參與者）。編寫涉衆利益應當按照如下格式：使用數字編寫序號，而每個涉衆利益應當書寫爲“誰期望怎麼樣”。
前置條件：在觸發該用例相關操作前必須達到的條件。
事件流：是用例說明中最重要的部分，它詳細描述了該用例可能出現的所有流程。
基本流程：又稱爲“主流程”或“主成功場景”，它描述的是該用例以最正常的方式流轉，並且最終獲得成功的流程。基本流程在編寫時，應當通過數字，對流程中的每一步進行編號
擴展流程：又稱爲“替代流程”、“分支流程”或“交替場景”，它描述的是基本流程在流轉過程中可能出現的所有分支。擴展流程在編寫時，通常使用“數字+小寫字母”對擴展流程進行編號。數字代表該擴展流程是在基本流程的哪一步發生分支的。如果是任意位置滿足某條件就會發生分支，則使用“*”代替。小寫字母代表該擴展流程是本用例中的第幾個擴展流程。擴展流程編號的後面應當描述進入該擴展流程的條件。最後，和基本流程一樣，通過數字編號，詳細描述該擴展流程的整個流程。如果在擴展流程中還會出現分支，則如上遞歸地描述該擴展流程的擴展流程
異常流程：故名思意，它是對該用例的所有基本流程和擴展流程可能出現的所有異常情況及其處理流程的描述。與擴展流程一樣，異常流程首先通過“數字+小寫字母”進行編號，描述出現異常的條件。如果是任意位置都可能滿足異常條件，則使用“*”代替數字。隨後，編寫出處理該異常的整個流程。按照以上步驟，羅列出所有可能出現的異常情況。
後置條件：又稱爲“成功保證”，就是執行基本流程獲得成功以後所達到的狀態（條件）。後置條件往往體現的是執行該用例的最終目的。
非功能需求：我們可以把它們簡稱爲“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。
補充規格說明書：該用例對應的補充規格說明書。
除此之外，用例說明還可以包括其它內容。比如，該用例是用於查詢數據或展現一個表格，則應當畫出數據的格式或表格的樣式，並詳細標註數據間的運算關係；如果客戶對該用例有其它硬件或技術要求，可增加“技術與數據變元”項。
在編寫這部分說明的時候，還有一個非常關鍵的地方值得注意。當我們在編寫事件流時，如果發現多個用例都出現相同或相似的流程，並且功能相對獨立時，應當考慮將它提取出來單獨形成一個用例。如果是這樣，在原用例的這個地方只需說明在執行某個步驟時進入哪個用例就可以了，不用再描述這部分流程。如果原用例在基本流程中調用這個用例，則原用例包含這個用例；如果原用例在擴展流程中調用這個用例，則這個用例是對原用例的擴展。
另外，異常流程也是一個非常重要的內容。過去我們在分析階段沒有考慮異常處理的情況，以致在開發階段不知道怎樣處理才能讓客戶滿意。但值得提醒的是，這裏的異常是站在業務層面的異常，如：“用戶不能提供單據號”，或“用戶未領取通知單”。而那些技術層面的異常不應當出現在這裏，如“數據庫連接失敗”等。
編寫用例說明的建議
按照過去RUP的設計思路，填寫用例說明的時候，所有的項目都必須填寫清楚完整，這是一個繁瑣而令人沮喪的工作。然後，敏捷開發的思想出來了，我們都解脫了。敏捷開發的一個重要思想就是：我們只做我們需要做的事情，千萬不要去做不需要做的事情（這也就是它稱之爲的“過度設計”）。用例說明只有幾個項目是必填的：用例名稱、用例描述、參與者（有的用例可能沒有參與者，但必須寫“無”而不能不寫）、基本流程，其它都是可選項。另一個重要的思想就是迭代，需求分析是一個逐漸推進的過程，因此千萬不要想到把用例說明寫得一步到位。在這個問題上，大師給我們了建議。Craig Larman在他的《UML和模式應用》中這樣描述，他說用例的編寫有三種常用形式：摘要、非正式和詳述。
摘要，簡潔的一段式概要，通常用於主成功場景，在早期需求分析中爲快速瞭解主題和範圍而使用，範例：
處理銷售：顧客攜帶所購商品到達收銀臺。收銀員使用POS系統記錄每件商品。系統連續顯示累計金額，並逐行顯示明細。顧客輸入支付信息，系統對支付信息進行驗證和記錄。系統最終顯示交易成功。
非正式的，就是以一種非正式的段落格式，描述各個場景。它用於在需求分析逐漸深入的過程中使用。範例：
處理退貨
主成功場景：
顧客攜帶商品到收銀臺退貨。收銀員使用POS系統記錄每件商品……
交替場景：
如果客戶之前使用信用卡付款，而其信用卡賬戶退還交易被拒，則告知顧客並使用現金退貨
如果在系統中未查找到該商品的標識碼，則提示收銀員並建議手工輸入標識碼。
……
詳述，就是前面詳述的完整格式，它主要用於需求分析後期以及最終需求確認的時候。即使採用詳述的方式，也沒有必要每個用例都寫出每個項目。需要寫的時候才寫，不需要就不要寫。即使需要寫的內容，也是在需求分析逐漸深入過程中逐漸完成的。
用例說明將過去需求規格書面向過程進行需求分析的方式，轉變成面向對象的分析方式，即需求中的所有過程都被封裝在了一個個用例中。同時，用例說明又給我我們一個模板，讓我們照着這個模板進行需求分析，避免了我們在分析過程中可能遺漏用於信息的問題。另外，用例說明從一開始就進入了OOD/A分析，將可複用的、相對獨立的功能進行提取、封裝，避免了過去程序設計纔開始OOD/A分析所造成的許多設計規劃先天不足的問題。總之，用例說明已經不單純是對原需求的簡單描述，而是帶着面向對象的設計思想在進行需求描述。