第6章 用例

本文為《UML和模式應用(原書第3版)》讀書筆記


用例是文字形式的情節描述,廣泛應用於需求的發現和記錄工作中。

示例

顧客攜帶商品到收銀臺,收銀員使用POS系統記錄每件商品,系統連續顯示累計總額,並逐行顯示細目。顧客輸入支付資訊,系統對支付資訊進行驗證和記錄。系統更新庫存資訊,顧客從系統得到購物小票,然後攜帶商品離開。

參與者、場景和用例

  • 參與者是某些具有行為的事物,可以是人、計算機系統或組織,例如收銀員。
  • 場景是參與者和系統之間的一系列特定的活動和互動,也稱為用例例項。場景是使用系統的一個特定情節或用例的一條執行路徑。例如使用現金成功購買商品的場景,或使用信用卡付款被拒造成購買失敗的場景。
  • 用例就是一組相關的成功和失敗場景的集合,用來描述參與者如何使用系統來實現其目標。
  • 例如處理退貨
    • 成功場景:收銀員使用POS系統記錄並處理每件退貨。
    • 交替場景:客戶之前使用信用卡付款,信用卡拒絕退款;在系統未找到商品標識碼;與外部記賬系統通訊失敗等。
  • 一組用例的例項,其中每一個都是系統執行的一系列活動,這些活動產生了對某個參與者而言可觀察的返回值【RUP】

用例和用例模型

  • 用例模型是所有書面用例的集合,同時也是系統功能性和環境的模型。
  • 用例是文字文件,而不是圖形,用例模型主要是編寫文字的活動,而非製圖。
  • 用例有利於使用者參與專案,比如領域專家或需求提供方可以自己編寫用例,而且用例強調了使用者的目標和觀點。
  • 用例的優越性在於,能夠根據需要對複雜程度和形式化程度進行增減調節。
  • 用例就是需求,主要是說明系統如何工作的功能性或行為性需求。
  • 在統一過程和其他現代方法中,用例被推薦為發現和定義需求的核心機制。
  • 用例的主要思想:為功能性需求編寫用例,從而降低詳細的老式特性列表的重要性或減少這種列表的使用。

參與者的三種型別

  • 參與者是任何具有行為的事物。
  • 主要參與者,具有使用者目標,並通過使用系統的服務完成。例如收銀員。
  • 協助參與者,為系統提供服務,一般是計算機系統。比如說自動付費服務授權。
  • 幕後參與者,在用例行為中具有影響或利益,但不是主要或協助參與者。例如政府稅收機構。

表示法:用例的三種常用形式

  • 摘要,簡潔的一段式概要,通常用於祝成功場景。例如示例中的處理銷售。
  • 非正式,非正式的段落格式,用幾個不同的段落覆蓋不同場景。例如示例中的處理退貨。
  • 詳述,詳細編寫所有步驟及各種變化,同時具有補充部分,比如前置條件和保證成功。

示例:詳述風格的處理銷售

  • 詳述用例是結構化的,它展示了更多的細節,並且更為深入。
  • 在迭代和進化式UP需求分析中,第一次需求討論會應該以這種形式編寫10%的關鍵用例,然後對這10%中最具有重要架構意義的用例或場景進行設計和程式設計。
  • 詳細用例格式的模板採用以下風格,是目前使用最為廣泛的格式:
    • 用例名稱:以動詞開始。
    • 範圍:範圍界定了索要設計的系統。通常用例描述的是對一個軟體系統(或硬體加軟體)的使用,這種情況下稱之為系統用例。在更廣義的範圍上,用例也能夠描述顧客和有關人員如何使用業務。這種企業級的過程描述被稱為業務用例
    • 級別:用例主要分為使用者目標級別或子功能級別。使用者目標級別是通常所使用的級別,描述了實現主要參與者目標的場景,該級別大致相當於業務流程工程中的基本業務流程子功能級別用例支援使用者目標所需要的自步驟,當若干常規用例共享重複的自步驟時,將其分離出來,建立為子功能級別用例(以避免重複公共的文字),比如信用卡支付,該用例可以被許多常規用例所共享。
    • 主要參與者:呼叫系統服務來完成目標的參與者。
    • 涉眾及其關注點列表:該列表建議並界定了系統必須要做的工作。用例應該包含滿足所有涉眾關注點的事物,在編寫用例其餘部分之前就確定涉眾及其關注點,能夠讓我們更加清楚地瞭解詳細的系統職責。從涉眾及其關注點的角度出發,能夠為發現並記錄所有行為需求提供徹底、系統的過程。
    • 前置條件:給出在用例中場景開始之前必須永遠為真的條件。通常前置條件隱含已經成功完成的其他用例場景,例如“登入”。注意有些條件也必須為真,但是不值得編寫出來,例如“系統有電力供應”。前置條件傳達的是編寫者認為應該引起讀者警惕的那些值得注意的假設。
    • 成功保證:給出用例成功結束後必須為真的事物,包括主成功場景及其替代路徑。該保證應該滿足所有涉眾的需求。
    • 主成功場景和步驟(或基本流程):也被稱為“理想路徑”場景,或“基本流程”及“典型流程”。它描述了滿足涉眾關注點的典型成功路徑,要注意的是,它通常不包括任何條件或分支,保持一定的連貫性,並且將所有條件處理都推延至擴充套件部分,這樣的做法更易於理解和擴充套件。場景記錄三種步驟:1.參與者之間的互動;2.確認過程(通常由系統來完成);3.系統完成的狀態變更(例如記錄或更改某事物);
    • 擴充套件:擴充套件是重要的並通常佔據了文字的大部分篇幅。擴充套件部分描述了其他所有場景或分支,包括成功和失敗路徑。在整個用例編寫中,理想路徑與擴充套件路徑相結合應該滿足“幾乎”所有涉眾所關注的問題。但是有些關注問題最好是作為非功能性需求在補充規格說明中描述,比如顧客要求顯示商品描述和價格。擴充套件由兩部分組成:條件和處理。儘可能用系統內給或參與者能夠檢測到的事物作為條件,例如,系統檢測到與外部稅務計算系統服務的通訊故障和外部稅務計算系統工作不正常,前一種比較好,因為那個是系統能夠檢測的條件,而後一種只是推斷。
    • 特殊需求:相關的非功能性需求;將所有非功能性需求集中於補充規範規格說明中,對於內容管理、可理解性和可讀性而言更為有效,因為在架構分析時通常將這些需求作為整體來考慮。
    • 技術和資料變元表:不同的I/O方法和資料格式,在需求分析中發現的一些技術變元,這些變元是關於必須如何實現系統的,而不是實現系統的哪些功能。
    • 發生頻率:影響對實現的調查、測試和時間安排;
    • 雜項:例如未決問題;

以下是基於以上模板的相關示例:

範圍:NextGen POS 應用(銷售時點資訊系統)
級別:使用者目標
主要參與者:收銀員
涉眾及其關注點

  • 收銀員:希望能夠準確、快速地輸入,而且沒有支付錯誤,因為如果少收貸款,將從薪水中扣除。
  • 售貨員:希望自動更新銷售提成。
  • 顧客:希望以最小代價完成購買活動並得到快速服務。希望便捷、清晰地看到所輸入的商品專案和價格。希望得到購買憑證,以便退貨。
  • 公司:希望準確地記錄交易,滿足顧客要求。希望確保記錄了支付授權服務的支付票據。希望有一定的容錯性,即使在某些伺服器構件不可用時(如遠端信用卡驗證),也能夠完成銷售。希望能夠自動、快速地更新賬務和庫存資訊。
  • 經理:希望能夠快速地執行超控操作,並易於更正收銀員的不當操作。
  • 政府稅收代理:希望能從每筆交易中抽取稅金,可能存在多級稅務代理,比如國家級、省級、市級。
  • 支付授權服務:希望接收到格式和協議正確的數字授權請求。希望準確計算對商店的應付款。

前置條件:收銀員必須經過確認和認證。
成功保證(或後置條件):儲存銷售資訊。準確計算稅金。更新賬務和庫存資訊。記錄提成。生成票據。記錄支付授權的批准。
主成功場景(或基本流程)

  1. 顧客攜帶所購商品或服務到收銀臺通過POS機付款。
  2. 收銀員開始一次新的銷售交易。
  3. 收銀員輸入商品條碼。
  4. 系統逐條記錄出售的商品,並顯示該商品的描述、價格和累計額。價格通過一組價格規則來計算。
    收銀員重複3~4步驟,直到輸入結束。
  5. 系統顯示總額。
  6. 收銀員告知顧客總額,並請顧客付款。
  7. 顧客付款,系統處理支付。
  8. 系統記錄完整的銷售資訊,並將銷售和支付資訊傳送到外部的賬務系統(進行賬務處理和提成)和庫存系統(更新庫存)。
  9. 系統列印票據。
  10. 顧客攜帶商品和票據離開。

擴充套件(或替代流程):例如系統在某一步失敗、無效的商品、顧客告知免稅狀況、需要手工輸入類別和價格、顧客要求取消銷售交易等。這些情況和步驟需要結合實際的場景進行詳細的描述,例如:

在主成功場景的第3步,出現無效商品ID,第一個描述條件及響應擴充套件被標記為“3a”,第二個標記為“3b”,以此類推。
  3a.無效商品ID
  1.系統提示錯誤並拒絕輸入該標識。
  3b.多個商品屬於同一類別時,不必記錄每個商品的唯一標識

當一組步驟中都出現相同條件時,可以如下表示:
  3-6a.顧客要求收銀員從所購商品中去掉一項
  1.收銀員輸入商品ID並將其刪除。
  2.系統刪除該專案並顯示更新後的累計額。

在任何或大多數步驟都可能發生的擴充套件條件,可以用“*a”和“*b”這樣的標記,另外在複雜的擴充套件中還可以另外使用單獨的用例來表達該擴充套件,即擴充套件是可以巢狀的。
  *a. 系統在任意時刻失敗
  保證所有交易的敏感狀態和時間能夠從場景的任何一步中完全恢復。
  1.收銀員重啟系統,登入,請求恢復上次狀態。
  2.系統重建上次狀態。
    2a.系統在恢復過程中檢測到異常
    1.系統向收銀員提示錯誤,記錄此錯誤,並進入一個初始狀態。
    2.收銀員開始一次新的銷售交易。

特殊要求:使用大尺寸平面顯示器觸控式螢幕、90%的信用卡授權響應時間小於30秒、支援文字顯示的語言國際化等。
技術與資料變元表:商品ID可以用掃描槍輸入或鍵盤輸入、信用卡賬戶資訊可以用讀卡器或鍵盤輸入等。
發生頻率:可能會不斷地發生。
未決問題:稅法如何變化、研究遠端服務的恢復問題、顧客是否可以直接使用讀卡器,還是必須由收銀員完成等。

準則

  • 以無使用者介面約束的本質風格編寫用例:*以本質風格編寫用例,摒除使用者介面並且關注參與者的意圖。*例如表述為“登入”的這一個目標,收銀員可能會想象有圖形介面、對話方塊、使用者名稱和密碼。這是實現目標的一種機制,但不是目標本身。通過對目標層次的研究,系統分析員會發現與實現機制無關的目標,比如標識自己身份並得到認證、或者更為高層的目標:防盜。這種對根源目標的發現過程能夠擴充套件視野,以促成新的和改進的解決方案,例如如果目標是識別身份和認證,那麼為何不直接使用生物資訊讀取裝置來實現這一功能,而這一問題可能涉及到可用性分析,比如說手指是否粘有油脂,有沒有手指等。與之相對應的是具體風格,在早期需求工作中應該避免這樣的風格,具體用例的風格包括但不限於視窗截圖、視窗導航討論、互動小部件的操作等。
  • 編寫簡潔的用例:儘量減少詞彙。
  • 編寫黑盒用例:黑盒用例不對系統內部工作、構件或設計進行描述,它通過職責來描述系統。分析與設計的區別在於“什麼”和“如何”的差異,在需求分析中應避免進行“如何”的決策,而是規定系統的外部行為。
  • 採用參與者和參與者目標的視點:強調了需求分析的兩個態度,一個是關注系統的使用者或參與者來編寫需求,詢問其目標和典型情況,另一個是關注理解參與者所考慮的有價值結果。
  • 如何發現用例:
    • 選擇系統邊界。系統僅僅是軟體還是軟硬結合,是一個人還是整個組織在使用。對於本案例,POS系統是要被設計的系統,任何該系統之外的事物都在系統邊界之外,包括收銀員、支付授權服務等。
    • 確定主要參與者。在本案例的處理銷售用例中,主要參與者是收銀員而不是顧客,因為在POS系統的邊界出發,系統所服務的目標是受過訓練的收銀員,以實現“專業使用者”的目標。
    • 確定每個主要參與者的目標。通過使用系統的服務實現其目標的那些人或事物。誰來啟動和停止系統?誰來完成使用者管理和安全管理?誰來完成系統管理?你在做什麼(比較像是在反映當前的解決方案與過程,以及期間的複雜因素),你的目標是什麼(能夠開闊思路以形成新的和改進的結局方案,能夠集中於增加業務價值並且能夠觸及涉眾想從系統中得到的核心價值)。
    • 定義滿足使用者目標的用例,根據其目標對用例命名,用例名稱應使用動詞開頭。

用例圖

  • 用例圖用於描述用例名稱和參與者及其之間的關係。
  • 簡單的用例圖能夠為系統提供簡潔可視的語境圖,能夠闡述外部參與者及其對系統的使用。
  • 用例圖能夠展示系統邊界、位於邊界之外的事物以及系統如何被使用。
  • 應注重編寫文字,而不是用例圖和用例關係。

這裡寫圖片描述

這裡寫圖片描述

由於該書認為用例圖只是輔佐理解用例,因此在用例圖上並沒有講的很詳細,以下是目前詳細的用例圖畫法:
 用例圖所包含的元素如下:
1. 參與者(Actor)
  表示與您的應用程式或系統進行互動的使用者、組織或外部系統。用一個小人表示。
2. 用例(Use Case)
  用例就是外部可見的系統功能,對系統提供的服務進行描述。用橢圓表示。
3. 子系統(Subsystem)
  用來展示系統的一部分功能,這部分功能聯絡緊密。
  這裡寫圖片描述
4. 關係
  用例圖中涉及的關係有:關聯、泛化、包含、擴充套件。
這裡寫圖片描述
a. 關聯(Association)
  表示參與者與用例之間的通訊,任何一方都可傳送或接受訊息。
  【箭頭指向】:指向訊息接收方
  這裡寫圖片描述
b. 泛化(Inheritance)
  就是通常理解的繼承關係,子用例和父用例相似,但表現出更特別的行為;子用例將繼承父用例的所有結構、行為和關係。子用例可以使用父用例的一段行為,也可以過載它。父用例通常是抽象的。
  【箭頭指向】:指向父用例
這裡寫圖片描述
c. 包含(Include)
  包含關係用來把一個較複雜用例所表示的功能分解成較小的步驟。
  【箭頭指向】:指向分解出來的功能用例
  這裡寫圖片描述
d. 擴充套件(Extend)
  擴充套件關係是指用例功能的延伸,相當於為基礎用例提供一個附加功能。
  【箭頭指向】:指向基礎用例
  這裡寫圖片描述
e. 依賴(Dependency)
  以上4種關係,是UML定義的標準關係。但VS2010的用例模型圖中,新增了依賴關係,用帶箭頭的虛線表示,表示源用例依賴於目標用例。
  【箭頭指向】:指向被依賴項
  這裡寫圖片描述
  
包含(include)、擴充套件(extend)、泛化(Inheritance) 的區別:
  條件性:泛化中的子用例和include中的被包含的用例會無條件發生,而extend中的延伸用例的發生是有條件的;
  直接性:泛化中的子用例和extend中的延伸用例為參與者提供直接服務,而include中被包含的用例為參與者提供間接服務。
  對extend而言,延伸用例並不包含基礎用例的內容,基礎用例也不包含延伸用例的內容。
  對Inheritance而言,子用例包含基礎用例的所有內容及其和其他用例或參與者之間的關係;
  

活動圖

用例涵蓋過程和工作流分析,所以活動圖能夠成為編寫用例文字的有用的輔助措施。

容許高階系統特性列表

  • 在設想文件中加入簡介的高階特性列表有助於概括系統的功能性,該列表也稱為系統特性列表。系統特性列表獨立於用例檢視,簡要地概括了功能性。
  • 有時某些應用迫切需要特性驅動的觀點,例如對於應用伺服器、資料庫產品和其他中介軟體或後臺系統而言,首要考慮的是特性(“比如需要在下一版本中支援web Services”)。

總結

  • 在初始階段如何編寫用例:不以詳述形式編寫所有用例,假設有為期兩天的需求討論會,在開始的時候主要工作是確定目標和涉眾,並且推測專案的範圍,使用工具編寫、顯示 參與者-目標-用例列表,繪製用例語境圖。幾個小時之後,大概確定20個用例的名稱,以摘要形式編寫大部分需要關注的、複雜的、具有風險的用例,每個用例平均話費兩分鐘時間編寫,小組開始對系統的功能性達成共識。然後以詳述形式重新編寫其中10%~20%的用例,這些用例代表複雜的核心功能、需要構建核心架構或者在某些方面極具風險,通過對具有影響力的用例所完成的小範圍深入調查,小組能夠進行略為深入的研究,以獲取對專案規模、複雜度、隱藏風險的理解。
  • 在細化階段如何編寫用例:該階段含有多次時間定量的迭代,在這些迭代中,逐步地構建具有風險、高價值或具有重要架構意義的部分系統,同時確定需求的主題。由於具體程式設計步驟的反饋會影響和干預小組對需求的理解,對需求的迭代是可適應的。每次迭代都可以有一個為期兩天的需求討論會,但是並不是要在每個討論會上調查所有用例,而是討論具有優先順序、最重要的用例。在隨後精化使用者目標和用例列表,以詳述形式編寫和重新編寫更多的用例,在細化階段結束時,將詳細編寫80%~90%的用例。注意該階段所涉及對部分系統的程式設計,因此在該階段結束時,除了有更詳細的用例定義外,還應該有一些可執行的軟體。
  • 在構造階段如何編寫用例:在細化階段,一旦解決了那些具有風險的和不穩定的核心問題,那麼在由時間定量的迭代組成的構造階段中,則側重於完成系統。在這一階段中,可能還要編寫一些次要的用例,還會舉行需求討論會,但是次數會大大少於細化階段。