1、用例建模的概念

用例建模是一種需求分析方法，側重于從用戶的角度出發，將系統當做一個黑盒子，描述用戶將如何使用系統，以此來梳理系統需求。相較于傳統的結構化分析與設計方法，用例主張通過用戶語言從“人”的視角對有價值的行為進行抽象，能夠更全面的對問題域和系統價值進行分析，在需求描述上也更為收斂，一個上百種特性（計算機實現角度描述）的系統可能只有不到10個用例。

用例模型的組成部分包含參與者與用例，想要做好用例建模必須準確理解他們的含義：

一、用例的組成

參與者

1）參與者是系統之外直接與系統進行有意義交互的任何事物。

2）參與者是獨立于系統的實體，是系統的觸發者，需要直接參與系統的交互。如果我找某代理幫我在某平臺辦理購房手續，即使我是需求方和直接受益人，也不能算作平臺的實際參與角色，僅僅是利益相關者（stakeholder）而已。

3）參與者是角色而非個人。角色與具體個人的區別在于“角色”是業務中的職能單位，而一個人可能承擔多個角色。比如便利店的店員可能充當庫存管理員和收銀員兩種角色參與業務；一個人的角色也可能發生轉換，例如在游戲中的觀戰觀眾，如果加入對戰就變成了玩家角色。

4）參與者不僅可以由人承擔，還可以是其他系統、硬件設備，甚至是時鐘。

• 其他系統：當你的系統需要與其他系統交互時，例如在淘寶購物下單時去請求賣家的上架管理系統的庫存信息，商家管理系統就是一個參與者；

• 硬件設備：當系統需要與硬件設備交互時，硬件設備也可以作為系統參與者，例如高鐵乘車需要在道閘刷身份證，道閘的讀寫器就是一個參與者；

• 定時器：當你的系統需要通過時鐘確定某個時間來觸發時，時鐘就是一個參與者，例如系統在用戶生日的零點準時推送祝福，就需要引入時鐘作為參與者。

盡可能將角色細化，再合并和抽象，但要避免過度泛化。例如滴滴的專車司機、社會車輛司機經過細化再合并之后都是司機角色，但不能將司機和乘客都泛化為“用戶”，這樣不能恰當的表述各角色需求。

用例

1）用例是參與者在系統中進行的一系列有價值的操作。

2）用例是有步驟的，他是由一系列連貫的業務步驟組成的業務活動。

3）用例是有目標的，它能夠為參與者帶來有意義、有價值的結果，能給系統相關人清楚傳達系統能提供的價值，而不是某個具體功能的操作。例如“輸入身份證號”就不是用例，而“在線購票”則是。

4）用例是對一組實例的抽象（即場景），能夠從使用者角度清晰描述與其互動的方式以觀測系統實現全貌，包含基本事件流、擴展流、子事件流，比如購物時正常購物、填錯地址改地址、拍多了取消訂單...但從用例角度都抽象在“下單”用例中。一個場景是一個具體的行為，一個用例是對一類相關行為的抽象。

系統用例建模包含多個用例，需要通過完整文檔組織整個業務的用例，通常放在PRD內。

二、用例的不足與誤解

1）AI、算法、策略產品引擎及接口描述不適用。用例多用于描述需要大量交互產品，因為它本身就是強調參與者與系統交互的視角。

2）用例缺乏約束性，需要非功能需求補充。用例僅組織、描述功能需求，強調發起什么請求得到什么反饋，但在系統安全性、穩定性等方面需要通過非功能性需求描述作為補充。

關于用例的理解，很多人都誤認為用例就是用例圖，需要注意的是，用例是一種需求分析方法，用例圖只是描述用例的一個部分，單從用例的表述層面來看，也還需要通過用例文檔細化描述。

三、用例的表述方式

用例模型的表述包括兩部分：用例圖是目錄，用例文檔是封裝所有需求的形式。

?

?

1）用例圖

用例圖中通常包含參與者、用例與系統邊界。

參與者主要是系統使用角色，需要根據系統范圍的邊界確定是在系統內還是系統外，例如我們設計用戶使用的電商購物軟件時，就不會把供應商的庫管員拉進系統角色中。繪制用例圖時通常左邊放置主要使用角色，右邊是被動維護角色，具體繪制方法還需根據場景確定，能讓讀者清晰理解即可。

?

用例的定義與切分粒度需根據應用場景決定，通常方法是：

• 強調系統為參與者提供的完整價值，需要明確是從價值維度而非功能維度的描述，需要讓看文檔的使用人能便捷理解，即使是業務人員。

• 通過詢問自己：用例是個完整可銷售的服務嗎？老板理解和認可單個用例價值嗎？來判斷對用例的定義是否到位。

• 用例的表述以主動的邏輯命名，動賓結構，體會一下：藥品采購VS采購藥品...

系統邊界用于清楚分割和定義系統提供的價值范圍。邊界內的由系統提供，邊界外則不提供。

2）用例文檔

用例圖目錄繪制完成后，就是通過用例文檔對用例進行更加詳盡的描述，通常包含如下部分：

• 標題/作者/修改歷史：定義文檔、署名作者及記錄變更信息

• 簡要概述：描述基本含義和背景

• 利益相關者/涉眾/參與人及其相關利益：除了用例參與人，為便于對用例價值和系統邊界的理解可加入利益相關者的描述信息

• 事件流：基本流程/擴展流程/異常流程，描述如何通過交互傳遞用例承諾的價值，是嚴格流程化、規范化的“詞牌名”，大致結構為：?例開始（??） → {?戶發起請求 → 系統校驗請求 → 系統處理 → 系統反饋} → ?例結束

• 基本流：無分支，僅順序、完整的描述成功路線。主語是用戶，即使繁瑣也要按步驟寫，幫助自己切換視角，注意僅描述故事，與交互和界面元素無關，也沒有技術實現。

• 擴展流程/異常流程：描述除基本流以外的分支流程。

• 輔助圖例：如若通過文字描述不好理解用例，可增加其他輔助圖例，如狀態機等。

• 前置條件/后置條件：前置條件描述正確的起點，需要具備哪些條件才能開始用例；后置條件描述正確的結束，可能有多種，如取消訂單和完成訂單。

• 術語表：對重要或者難以理解的術語作出解釋。

• 界面圖例：通過界面輔助讀者理解用例。

• 限制條件：用例可能在數量、金額、時間等方面的限制。

• 特殊需求：例如敏感詞審核等其他用例交互外的訴求。

• 策略：通常描述時機和受，如廣告消息推送，單獨進行描述。

用例文檔中具體描述的內容可按需裁剪，并非每項都需要覆蓋，清楚達意即可。

總結

以上是生活随笔為你收集整理的软件工程4 用例建模的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。