軟考之用例模型

用例概念理解

用例模型主要由以下模型元素構成：

參與者(Actor)

• 參與者是指存在於被定義系統外部並與該系統發生交互的人或其他系統，他們代表的是系統的使用者或使用環境。

用例(Use Case)

• 用例用於表示系統所提供的服務，它定義了系統是如何被參與者所使用的，它描述的是參與者爲了使用系統所提供的某一完整功能而與系統之間發生的一段對話。

通訊關聯(Communication Association)

• 通訊關聯用於表示參與者和用例之間的對應關係，它表示參與者使用了系統中的哪些服務（用例），或者說系統所提供的服務（用例）是被哪些參與者所使用的。

這大三種模型元素在UML中的表述如下圖所示

通訊關聯表示的是參與者和用例之間的關係，箭頭表示在這一關係中哪一方是對話的主動發起者，箭頭所指方是對話的被動接受者；如果你不想強調對話中的主動與被動關係，可以使用不帶箭頭的關聯實線。在參與者和用例之間的信息流不是由通訊關聯來表示的，該信息流是缺省存在的（用例本身描述的就是參與者和系統之間的對話），並且信息流向是雙向的，它與通訊關聯箭頭所指的方向亳無關係。

事件流

• 用例描述的是參與者與系統之間的對話，對話的細節
  用事件流進行描述。

事件流分類

基本事件流

• 描述正常流程
  備選事件流
• 描述異常終止流程

小結

優點：

• 用例方法站在用戶的角度（從系統外部）來描述系統的功能，將需求與設計分離，在面向對象的分析設計方法中，用例模型主要用於表述系統的功能性需求，系統的設計主要由對象模型來記錄表述。

• 用例方法比傳統的SRS更易於被用戶所理解，它可以作爲開發人員和用戶之間針對系統需求進行溝通的一個有效手段。

用例建模

用例模型主要包括以下兩部分內容：

用例圖(Use Case Diagram)

• 確定系統中所包含的參與者、用例和兩者之間的對應關係，用例圖描述的是關於系統功能的一個概述。

用例規約(Use Case Specification)

• 針對每一個用例都應該有一個用例規約文檔與之相對應，該文檔描述用例的細節內容。

尋找參與者

所謂的參與者是指所有存在於系統外部並與系統進行交互的人或其他系統。通俗地講，參與者就是我們所要定義系統的使用者。尋找參與者可以從以下問題入手：

• 系統開發完成之後，有哪些人會使用這個系統？
• 系統需要從哪些人或其他系統中獲得數據？
• 系統會爲哪些人或其他系統提供數據？
• 系統會與哪些其他系統相關聯？
• 系統是由誰來維護和管理的？

這些問題有助於我們抽象出系統的參與者。對於ATM機的例子，回答這些問題可以使我們找到更多的參與者：操作員負責維護和管理ATM機系統、ATM機也需要與後臺服務器進行通訊以獲得有關用戶帳號的相關信息。

系統邊界決定了參與者

參與者是由系統的邊界所決定的，如果我們所要定義的系統邊界僅限於ATM機本身，那麼後臺服務器就是一個外部的系統，可以抽象爲一個參與者。

如果我們所要定義的系統邊界擴大至整個銀行系統，ATM機和後臺服務器都是整個銀行系統的一部分，這時候後臺服務器就不再被抽象成爲一個參與者。

用例規約

用例規約用以描述每一個用例的詳情，用例模型是由用例圖和每一個用例的詳細描述――用例規約所組成的，RUP-統一軟件過程中提供了用例規約的模板，每一個用例的用例規約都應該包含以下內容：

簡要說明 (Brief Description)

• 簡要介紹該用例的作用和目的。

事件流 (Flow of Event)

• 包括基本流和備選流，事件流應該表示出所有的場景。

用例場景 (Use-Case Scenario)

• 包括成功場景和失敗場景，場景主要是由基本流和備
  選流組合而成的。

特殊需求 (Special Requirement)

• 描述與該用例相關的非功能性需求（包括性能、可靠性、可用性和可擴展性等）和設計約束（所使用的操作系統、開發工具等）。

前置條件 (Pre-Condition)

• 執行用例之前系統必須所處的狀態。

後置條件 (Post-Condition)

• 用例執行完畢後系統可能處於的一組狀態。

注：用例規約基本上是用文本方式來表述的，爲了更加清晰地描述事件流，也可以選擇使用狀態圖、活動圖或序列圖來輔助說明。只要有助於表達的簡潔明瞭，就可以在用例中任意粘貼用戶界面和流程的圖形化顯示方式，或是其他圖形。如活動圖有助於描述複雜的決策流程，狀態轉移圖有助於描述與狀態相關的系統行爲，序列圖適合於描述基於時間順序的消息傳遞。

基本流

基本流描述的是該用例最正常的一種場景，在基本流中系統執行一系列活動步驟來響應參與者提出的服務請求。我們建議用以下格式來描述基本流：

• 每一個步驟都需要用數字編號以清楚地標明步驟的先後順序。

• 用一句簡短的標題來概括每一步驟的主要內容。

• 當整個用例模型基本穩定之後，我們再針對每一步驟詳細描述參與者和系統之間所發生的交互。建議採用雙向(roundtrip)描述法來保證描述的完整性，即每一步驟都需要從正反兩個方面來描述:(1)參與者向系統提交了什麼信息；(2)對此係統有什麼樣的響應。

在描述參與者和系統之間的信息交換時，需指出來回傳遞的具體信息。例如，只表述參與者輸入了客戶信息就不夠明確，最好明確地說參與者輸入了客戶姓名和地址。通常可以利用詞彙表讓用例的複雜性保持在可控範圍內，可以在詞彙表中定義客戶信息等內容，使用例不至於陷入過多的細節。

備選流

備選流負責描述用例執行過程中異常的或偶爾發生的一些情況，備選流和基本流的組合應該能夠覆蓋該用例所有可能發生的場景。在描述備選流時，應該包括以下幾個要素：

• 起點：該備選流從事件流的哪一步開始；

• 條件：在什麼條件下會觸發該備選流；

• 動作：系統在該備選流下會採取哪些動作；

• 恢復：該備選流結束之後，該用例應如何繼續執行。

備選流的描述格式可以與基本流的格式一致，也需要編號並以標題概述其內容，編號前可以加以字母前綴A(Alternative)以示與基本流步驟相區別。

用例場景

用例在實際執行的時候會有很多的不同情況發生，稱之爲用例場景；在用例規約中，場景的描述可以由基本流和備選流的組合來表示。場景既可以幫助我們防止需求的遺漏，同時也可以對後續的開發工作起到很大的幫助：開發人員必須實現所有的場景、測試人員可以根據用例場景來設計測試用例。

特殊需求

特殊需求通常是非功能性需求，它爲一個用例所專有，但不適合在用例的事件流文本中進行說明。特殊需求的例子包括法律或法規方面的需求、應用程序標準和所構建系統的質量屬性（包括可用性、可靠性、性能或支持性需求等）。此外，其他一些設計約束，如操作系統及環境、兼容性需求等，也可以在此節中記錄。

需要注意的是，這裏記錄的是專屬於該用例的特殊需求；對於一些全局的非功能性需求和設計約束，它們並不是該用例所專有的，應把它們記錄在《補充規約》中。

前置和後置條件

前置條件是執行用例之前必須存在的系統狀態，後置條件是用例一執行完畢後系統可能處於的一組狀態。

檢查用例模型

用例模型完成之後，可以對用例模型進行檢查，看看是否有遺漏或錯誤之處。主要可以從以下幾個方面來進行檢查：

功能需求的完備性

• 現有的用例模型是否完整地描述了系統功能，這也是我們判斷用例建模工作是否結束的標誌。

模型是否易於理解

• 用例模型最大的優點就在於它應該易於被不同的涉衆所理解，因而用例建模最主要的指導原則就是它的可理解性。用例的粒度、個數以及模型元素之間的關係複雜程度都應該由該指導原則決定。

是否存在不一致性

• 系統的用例模型是由多個系統分析員協同完成的，模型本身也是由多個工件所組成的，所以要特別注意不同工件之前是否存在前後矛盾或衝突的地方，避免在模型內部產生不一致性。不一致性會直接影響到需求定義的準確性。

避免二義性語義

• 好的需求定義應該是無二義性的，即不同的人對於同一需求的理解應該是一致的。在用例規約的描述中，應該避免定義含義模糊的需求，即無二義性。

系統需求

RUP中根據FURPS+模型將系統需求分爲以下幾類：

• 功能(Functionality)
• 可用性(Usability)
• 可靠性(Reliability)
• 性能(Performance)
• 可支持性(Supportability)
• 設計約束等

除了第一項功能性需求之外的其他需求都歸之爲非功能性需求。

需求工件集

用例模型主要用於描述系統的功能性需求，對於其他的非功能性需要用其他文檔來記錄。RUP中定義瞭如下的需求工件集合。

• 用例模型：記錄功能性需求
• 用例圖：描述參與者和用例之間的關係
• 用例規約：描述每一個用例的細節信息
• 補充規約：記錄一些全局性的功能需求、非功能性需求和設計約束等
• 詞彙表：記錄一些系統需求相關的術語

在實際應用中，除了這些工件之外，我們還可以根據實際需求靈活選用其他形式的文檔來補充說明需求。並不是所有的系統需求都適保合用用例模型來描述的，如編譯器，我們很難用用例方法來表述它所處理的語言的方法規則，在這種情況下，採用傳統的BNF範式來表述更加合適一些。在電信軟件行業中，很多電信標準都是採用SDL語言來描述的，我們也不必用UML來改寫這些標準（UML對SDL存在着這樣的兼容性），只需將SDL形式的電信標準作爲需求工件之一，在其他工件中對其加以引用就可以了。總之，萬萬不可拘泥於用例建模的形式，應靈活運用各種方式的長處

補充規約

補充規約記錄那些在用例模型中不易表述的系統需求，主要包括以下內容。

功能性

• 功能性需求主要在用例模型中刻畫，但是也有部分需求不適合在用例中表述。有些功能性需求是全局性的，適用於所有的用例，如出錯處理、I18N支持等，我們不需要在所有的用例中描述這些功能性需求，只需要在補充規約中統一描述就可以了。

可用性

• 記錄所有可用性相關的需求，如系統的使用者所需要的培訓時間、是否應附合一些常見的可用性標準如Windows界面風格等。

可靠性

• 定義系統可靠性相關的各種指標，包括：
  • 可用性：指出可用時間百分比(xx.xx%)，系統處於使用、維護、降級模式等操作的小時數；
  • 平均故障間隔時間(MTBF)：通常表示爲小時數，但也可表示爲天數、月數或年數；
  • 平均修復時間(MTTR)：系統在發生故障後可以暫停運行的時間；
  • 精確度：指出系統輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標準）；
  • 最高錯誤或缺陷率：通常表示爲bugs/KLOC（每千行代碼的錯誤數目）或bugs/function-point（每個功能點的錯誤數目）。

性能

• 記錄系統性能相關的各種指標，包括：
  • 對事務的響應時間（平均、最長）；
  • 吞吐量（例如每秒處理的事務數）；
  • 容量（例如系統可以容納的客戶或事務數）；
  • 降級模式（當系統以某種形式降級時可接受的運行模式）；
  • 資源利用情況：內存、磁盤、通信等。

可支持性

• 定義所有與系統的可支持性或可維護性相關的需求，其中包括編碼標準、命名約定、類庫、如何來對系統進行維護操作和相應的維護實用工具等。

設計約束

• 設計約束代表已經批准並必須遵循的設計決定，其中包括軟件開發流程、開發工具、系統構架、編程語言、第三方構件類庫、運行平臺和數據庫系統等等。

詞彙表

詞彙表主要用於定義項目特定的術語，它有助於開發人員對項目中所用的術語有統一的理解和使用，它也是後續階段中進行對象抽象的基礎。

調整用例模型

關係描述

參與者與用例

參與者與參與者

• 泛化
• 繼承

用例與用例

• 包含(include)
• 擴展(extend)
• 泛化(generalization)

包含

• 包含關係是通過在關聯關係上應用<< include>>構造型來表示的，如下圖所示。它所表示的語義是指基礎用例(Base)會用到被包含用例(Inclusion)，具體地講，就是將被包含用例的事件流插入到基礎用例的事件流中。

graph LRA(基礎用例) -->|include| B(被包含用例)

在ATM機中，如果查詢、取現、轉帳這三個用例都需要打印一個回執給客戶，我們就可以把打印回執這一部分內容提取出來，抽象成爲一個單獨的用例"打印回執"，而原有的查詢、取現、轉帳三個例都會包含這個用例。每當以後要對打印回執部分的需求進行修改時，就只需要改動一個用例，而不用在每一個用例都作相應修改，這樣就提高了用例模型的可維護性。

graph LRA(銀行客戶) --> B(查詢)A --> C(提款)A --> D(轉賬)B -->|include|E(打印回執)C -->|include|ED -->|include| E

擴展

• 擴展關係是指將擴展用例(Extension)的事件流在一定的條件下按照相應的擴展點插入到基礎用例(Base)中。

• 對於包含關係而言，子用例中的事件流是一定插入到基礎用例中去的，並且插入點只有一個。而擴展關係可以根據一定的條件來決定是否將擴展用例的事件流插入基礎用例事件流，並且插入點可以有多個。

graph TBA(擴展用例) --> B(打電話) C(呼叫等待) --> |extend|BD(呼叫轉移) --> |extend|B

例如對於電話業務，可以在基本通話(Call)業務上擴展出一些增值業務如：呼叫等待(Call Waiting)和呼叫轉移(Call Transfer)。我們可以用擴展關係將這些業務的用例模型描述如下。

graph LRA(電話用戶) -->|extend| B(基礎用例)

泛化

• 當多個用例共同擁有一種類似的結構和行爲的時候，我們可以將它們的共性抽象成爲父用例，其他的用例作爲泛化關係中的子用例。

graph BTA(子用例1) --> B(父用例)C(子用例2) --> B

• 在用例的泛化關係中，子用例是父用例的一種特殊形式，子用例繼承了父用例所有的結構、行爲和關係。在實際應用中很少使用泛化關係，子用例中的特殊行爲都可以作爲父用例中的備選流存在。