軟體開發中描述用例的書寫規約

 描述用例規約

應 該避免這樣一種誤解――認為由參與者和用例構成的使用案例圖就是用例模型，使用案例圖只是在總體上大致描述了系統所能提供的各種服務，讓我們對於系統的功能有一個 總體的認識。除此之外，我們還需要描述每一個有例的詳細資料，這些資訊包含在用例規約中，用例模型是由使用案例圖和每一個用例的詳細描述――用例規約所組成 的。RUP中提供了用例規約的模板，每一個用例的用例規約都應該包含以下內容： 簡要說明 (Brief Description)
簡要介紹該用例的作用和目的。 事件流 (Flow of Event)
包括基本流和備選流，事件流應該表示出所有的情境。 用例情境 (Use-Case Scenario)
包括成功情境和失敗情境，情境主要是由基本流和備選流組合而成的。 特殊需求 (Special Requirement)
描述與該用例相關的非功能性需求（包括效能、可靠性、可用性和可擴充性等）和設計約束（所使用的作業系統、開發工具等）。 前置條件 (Pre-Condition)
執行用例之前系統必須所處的狀態。 後置條件 (Post-Condition)
用例執行完畢後系統可能處於的一組狀態。

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

基本流

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

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

2) 用一句簡短的標題來概括每一步驟的主要內容，這樣閱讀者可以通過瀏覽標題來快速地瞭解用例的主要步驟。在用例建模的早期，我們也只需要描述到事件流步驟標題這一層，以免過早地陷入到用例描述的細節中去。

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

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

備選流

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

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

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

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

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

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

用例情境

用 例在實際執行的時候會有很多的不同情況發生，稱之為用例情境；也可以說情境是用例的執行個體，我們在描述用例的時候要覆蓋所有的用例情境，否則就有可能導致需 求的遺漏。在用例規約中，情境的描述可以由基本流和備選流的組合來表示。情境既可以協助我們防止需求的遺漏，同時也可以對後續的開發工作起到很大的協助： 開發人員必須實現所有的情境、測試人員可以根據用例情境來設計測試案例。

特殊需求

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

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

前置和後置條件

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

檢查用例模型

用例模型完成之後，可以對用例模型進行檢查，看看是否有遺漏或錯誤之處。主要可以從以下幾個方面來進行檢查： 功能需求的完備性
現有的用例模型是否完整地描述了系統功能，這也是我們判斷用例建模工作是否結束的標誌。如果發現還有系統功能沒有被記錄在現有的用例模型中，那麼我們就需要抽象一些新的用例來記錄這些需求，或是將他們歸納在一些現有的用例之中。 模型是否易於理解
用例模型最大的優點就在於它應該易於被不同的涉眾所理解，因而用例建模最主要的指導原則就是它的可理解性。用例的粒度、個數以及模型元素之間的關係複雜程度都應該由該指導原則決定。 是否存在不一致性
系統的用例模型是由多個系統分析員協同完成的，模型本身也是由多個工件所組成的，所以我們要特別注意不同工件之前是否存在前後矛盾或衝突的地方，避免在模型內部產生不一致性。不一致性會直接影響到需求定義的準確性。 避免二義性語義
好的需求定義應該是無二義性的，即不同的人對於同一需求的理解應該是一致的。在用例規約的描述中，應該避免定義含義模糊的需求，即無二義性。

 

                                                                         引自：http://www.ibm.com/developerworks/cn/rational/r-usecase-atm/