引言
對於系統工程師來說，設計用例圖是一種極為常見的建模活動。用例圖是一種黑盒視圖，通過向讀者傳遞一系列的用例以及相關的參與者，對系統對外提供的服務或系統具備的行為進行建模。在詳細討論SysML的用例圖之前，我們先來了解一個非常關鍵的概念 - 用例。
什么是用例？
用例，英文為 “Use Case”，不同的書籍或論文資料對於 “用例” 有不同的定義，本文引用《Writing Effective Use Case》一書中關於用例的描述：
A use case captures a contract between the stakeholders of a system about its behavior. The use case describes the system’s behavior under various conditions as it responds to a request from one of the stakeholders, called the primary actor. The primary actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and conditions surrounding the requests. The use case collects together those different scenarios.
通俗的說，“用例” 是系統行為的黑盒描述，其闡述的是參與者（可能是用戶，也可能是其他系統）的意圖或對系統行為的期望，從參與者的角度對系統應該具備的行為進行建模。
用例表達方式？
用例可以采用基於模型和基於文本的方式進行表達。文本方式是傳統的但廣泛應用的方式，用戶可以采用特定格式的文本段落或表格對用例進行詳細描述。模型方式是未來的主要趨勢，例如用戶可以通過UML/SysML的模型圖如用例圖、活動圖、時序圖等對用例進行描述和細化。
不管基於哪種方式，用例的名稱典型地會采用動詞短語進行描述，例如 “存錢”、“取錢”、“發布文檔”、“創建用戶”等，這種概要性描述能夠 “大致” 說明參與者的意圖或者參與者希望系統執行的行為，雖然傳遞的信息非常關鍵但是有限，設計者不可能單從這些動詞短語獲取完備的信息。作為一種補充，一般會采用 用例說明書 （對於模型來說，可能是時序圖、活動圖等模型）對用例進行說明。典型地，我們可以采用基於文字的方式表達用例說明書。
《Writing Effective Use Case》一書中提供了示例形式，可以參考下圖：
不同的文字表述形式的樣式可能不太相同，具體選擇哪種樣式取決於用戶。
初識SysML用例圖
我們說，用例圖傳遞了一系列的用例，那么在SysML中用例圖如何表述呢？下面先睹為快。如下圖所示，這是一個 “Security System” 系統的SysML用題圖。圖頭部是SysML通用的頭部結構，其中圖類型為 “uc”，即用題圖。用例圖的內容區域部分展示了四種模型元素：
系統邊界框：矩形框表示，用於定義系統的范圍。
參與者：人形圖標或帶有<<actor>>關鍵字的矩形圖標都可以表示參與者，一般習慣於使用人形圖標。參與者可能是用戶，也可能是其他系統，本用例圖包含四個參與者。
用例：橢圓形圖標，並帶有用例名稱。本用例圖包含 2 個用例。
參與者與用例間的關系：無箭頭實線。
用例間的關系之泛化（generalization）
用例間的泛化關系表示一種繼承，是從抽象到具體的一種演化。子類型的用例繼承父用例的內容，並在此基礎上進行重新定義或添加新的父用例不具備的關系或行為。在SysML中，泛化關系采用帶空三角箭頭的實線表示。如下圖：
用例間的關系之包含（include）
包含（include）關系在SysML中的標識法是帶有箭頭的虛線，並注有<<include>>關鍵字。“被包含” 的用例位於關系的尾端，即箭頭端。
用例間的包含關系表示的是：當某用例被觸發時，其包含的用例也會執行。被包含的用例作為其他用例的一個組成部分存在。
注意： 包含關系雖然表達了用例間的組成關系，但用戶切記不要急於包含關系對系統做功能分解。這是用戶在使用用例建模時經常出現錯誤。用例不是功能，用例使用功能而已。因此基於用例實現功能分解是不合適的。另外，到底什么時候定義包含用例？包含用例的定義不是必然的。創建包含用例的原則是當多個用例具有一些公共的子行為時，一般會將這些公共行為創建為包含用例。而且，這些往往不是在系統設計的初始迭代就做的事情，而是系統建模開始時，僅構建基礎用例，並對用例進行詳細的說明（例如，定義用例說明書），隨着用例的不斷明確，公共子行為自然顯現出來，此時再定義包含用例時合理的。
用例間的關系之擴展（extend）
SysML中用例擴展（extend）關系的標識法是帶箭頭的虛線，並注有<<extend>>關鍵字。擴展用例位於擴展關系的尾端（非箭頭端）。擴展關系表述的是一種可選的公共行為。當用例觸發時，它的擴展用例是可選的執行（與包含用例不同）。
擴展關系表述的是對可選行為的建模。當多個用例具備通用的可選行為時，可以將這些通用行為重構為擴展用例。
參與者間的關系
SysML還支持參與者間的泛化關系，表示方式帶有空三角箭頭的實線，父類型位於箭頭端。同樣，泛化關系所表達的含義同樣適用於參與者間的泛化關系。泛化意味着繼承，泛化意味着抽象，子類型會繼承父類型的上下文。
用例與場景的關系
場景是用例執行的路徑，用例從開始執行到結束可以定義為一個 “場景”。由此，用例和場景間是 “一對多” 的關系。場景有很多，不僅僅局限於用例執行成功的場景，當然也包括用例執行過程中出現的各種異常場景。
當描述用例的場景時，發現某個用例的成功的場景太多，則這要引起注意，可能是用例定義的粒度太大，導致成功場景（執行路徑）太多。因此，要適當拆分，盡量保證單個用例有一個主要的成功場景。
用例圖設計原則
-
首先構建基礎用例，並細化用例說明書；
-
切記禁止使用用例實現功能分解（用例不是功能，用例調用功能）；
-
使用包含用例重構多用例的公共行為（必然執行）；
-
使用擴展用例重構多用例的可選的公共行為（可選的執行）；
-
大型系統的頂層基礎用例典型的為 10 ~ 15 個，單個用例的用例場景數為 5 ~ 25 （來自IBM Harmoney SE）。
-
非成功場景超過 5 個，則重構為 “Exception use case”，並與主用例鏈接（來自IBM Harmoney SE）。
-
用例一般不包含系統性能以及UI；
小結
用例圖是一種黑盒視圖，表征系統對外部參與者的可見行為或服務。用例間具有泛化、擴展、包含三種關系。通過包含和擴展關系可以對系統通用行為進行重構。
更多系統工程知識請關注 “系統工程實驗室” 微信公眾號
