软件工程4 用例建模
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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: VBS脚本简明教程
- 下一篇: 信息论与编码_学术动态 | “中大网络信