1、用例建模的概念

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

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

一、用例的組成

參與者

1）參與者是系統(tǒng)之外直接與系統(tǒng)進(jìn)行有意義交互的任何事物。

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

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

4）參與者不僅可以由人承擔(dān)，還可以是其他系統(tǒng)、硬件設(shè)備，甚至是時鐘。

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

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

• 定時器：當(dāng)你的系統(tǒng)需要通過時鐘確定某個時間來觸發(fā)時，時鐘就是一個參與者，例如系統(tǒng)在用戶生日的零點(diǎn)準(zhǔn)時推送祝福，就需要引入時鐘作為參與者。

盡可能將角色細(xì)化，再合并和抽象，但要避免過度泛化。例如滴滴的專車司機(jī)、社會車輛司機(jī)經(jīng)過細(xì)化再合并之后都是司機(jī)角色，但不能將司機(jī)和乘客都泛化為“用戶”，這樣不能恰當(dāng)?shù)谋硎龈鹘巧枨蟆?/p>

用例

1）用例是參與者在系統(tǒng)中進(jìn)行的一系列有價值的操作。

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

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

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

系統(tǒng)用例建模包含多個用例，需要通過完整文檔組織整個業(yè)務(wù)的用例，通常放在PRD內(nèi)。

二、用例的不足與誤解

1）AI、算法、策略產(chǎn)品引擎及接口描述不適用。用例多用于描述需要大量交互產(chǎn)品，因為它本身就是強(qiáng)調(diào)參與者與系統(tǒng)交互的視角。

2）用例缺乏約束性，需要非功能需求補(bǔ)充。用例僅組織、描述功能需求，強(qiáng)調(diào)發(fā)起什么請求得到什么反饋，但在系統(tǒng)安全性、穩(wěn)定性等方面需要通過非功能性需求描述作為補(bǔ)充。

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

三、用例的表述方式

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

?

?

1）用例圖

用例圖中通常包含參與者、用例與系統(tǒng)邊界。

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

?

用例的定義與切分粒度需根據(jù)應(yīng)用場景決定，通常方法是：

• 強(qiáng)調(diào)系統(tǒng)為參與者提供的完整價值，需要明確是從價值維度而非功能維度的描述，需要讓看文檔的使用人能便捷理解，即使是業(yè)務(wù)人員。

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

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

系統(tǒng)邊界用于清楚分割和定義系統(tǒng)提供的價值范圍。邊界內(nèi)的由系統(tǒng)提供，邊界外則不提供。

2）用例文檔

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

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

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

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

• 事件流：基本流程/擴(kuò)展流程/異常流程，描述如何通過交互傳遞用例承諾的價值，是嚴(yán)格流程化、規(guī)范化的“詞牌名”，大致結(jié)構(gòu)為：?例開始（??） → {?戶發(fā)起請求 → 系統(tǒng)校驗請求 → 系統(tǒng)處理 → 系統(tǒng)反饋} → ?例結(jié)束

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

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

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

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

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

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

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

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

• 策略：通常描述時機(jī)和受，如廣告消息推送，單獨(dú)進(jìn)行描述。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。