由上一篇文章可知在程序設計中最基礎的就是用例圖(use
case diagram), 因爲他描述了系統的功能,也就是對應於系統需求, 整個程序也就是爲了滿足這些需求而實現的. 如果用例圖描述錯誤, 將直接導致整個系統不滿足需求, 也就是說整個系統是無用的.
用例圖也就是對需求的抽象, 描述, 將需求從文字轉變成圖形, 在整個轉變過程中使不明確的需求變的明確. 用例圖只關心需求, 也就是系統需要具有哪些功能, 而不關心如何實現這些功能, 更不關心繫統非功能部分,比如性能, 使用的開發語言, 技術等.
如何來畫用例圖呢? 由於用例對應於需求, 因此也就是說如何來用圖形的方式描述一個需求呢.
首先應該是搞清楚參與者(actor), 也就是與你的系統進行交互的東西(人或物), 嚴格來說, 參與者需要滿足兩個要求:
(1) 與系統進行交互; (2)不是系統的一部分. 參與者並不一定都是人, 也可能是第三方系統等, 可以將其想象成一個黑盒子, 首先我們不能改變他, 而且也不關心參與者本身是如何實現的, 其次他需要與我們的系統進行相互.
比如我們在設計開發一個博客內容管理系統(weblog content management system, 以下簡稱CMS), 他有如下需求:
Requirement A.1
CMS系統允許管理員去創建新的博客賬號, 該賬號對應的個人詳細信息作者認證數據庫來確認.
針對上面的A.1需求, 最容易發現的參與者就是管理員, 他與系統進行交互(創建新的賬號), 並且他不屬於系統的一部分.在用例圖中, 參與者可以有兩種表示方式: (1)火柴人(stick
man); (2)元數據框(stereotyped box), 如下所示:
也可以通過以下的問題來找出參與者:
用例圖的另一個組成部分就是用例(use case), 或者說任務(job),
也就是該需求到底要做什麼事, 可能只是簡單的登錄, 也可能是複雜的多個全球數據庫之間的分佈式事務. 比如上面的需求A.1, 就是創建新的博客賬號. 在用例圖中, 用例用一個橢圓形框來表示, 如下所示:
最後就是將參與者與用例聯繫起來, 因爲參與者就是要與系統發生交互的, 然後完成用例所示的功能或任務, 在用例圖中使用通信線(communication
lines)來連接參與者與用例, 如下所示:
另外, 爲了表明參與者不屬於系統的一部分,可以使用系統邊界(system boundary)來表示, 如下所示:
到這裏, 一個簡單完整的用例圖就畫好了, 總結下來, 用例圖主要包括2個組成部分:參與者和用例, 然後使用通信線將參與者(一個或多個)分別與用例連接起來, 最後可以使用系統邊界來顯式的指明系統內的部分(用例)和系統外的部分(參與者).
圖形的一個好處就是簡潔明瞭, 但這也恰恰是他的不足, 也就是不夠詳細充分, 比如如果有多個參與者, 那麼哪個參與者是最重要的? 用例包含哪些步驟等等? 所以我們可以使用用例描述(use case description)來對用例圖加以補充描述.
在UML中用例描述一般包含以下內容, 但並沒有嚴格的要求, 可以自行增刪:
| 用例描述內容 | 解釋和用途 | 解釋和用途原文 |
| 相關需求(Related Requirements) | 該用例圖所描述的需求 | Some indication as to which requirements this use case partially or completely fulfills. |
| 目標背景(Goal in Context) | 該用例在系統中的位置和重要性 | The use case's place within the system and why this use case is important. |
| 先決條件(Preconditions) | 用例實現(發生)的前提 | What needs to happen before the use case can be executed. |
| 成功末端條件(Successful End Condition) | 成功後系統的狀態 | What the system's condition should be if the use case executes successfully. |
| 失敗末端條件(Failed End Condition) | 失敗後系統的狀態 | What the system's condition should be if the use case fails to execute successfully. |
| 主要參與者(Primary Actors) | 用例的主要參與者 | The main actors that participate in the use case. Often includes the actors that trigger or directly receive information from a use case's execution. |
| 次要參與者(Secondary Actors) | 用例的其他參與者 | Actors that participate but are not the main players in a use case's execution. |
| 觸發條件(Trigger) | 觸發用例發生的事件 | The event triggered by an actor that causes the use case to execute. |
| 主要流程(Main Flow) | 描述用例主要的正常流程 | The place to describe each of the important steps in a use case's normal execution. |
| 擴展流程(Extensions) | 除主流程之外的其他情況 | A description of any alternative steps from the ones described in the Main Flow. |
下面就是針對需求A.1的用例描述: