|
|
從任何一個環(huán)節(jié)我們都會看到用例，但是僅僅依靠用例本身的圖來描述用例是不夠的，為什么呢？因為用例它所要描述的是一個場景，換句話說，就是用例是描述了某件詳細(xì)的事情。如果作為一個場景的話必然要考慮這么幾個問題：
- 誰在這個場景中做事？
- 什么時候進(jìn)入這個場景？
- 這個場景在做什么？
- 這個場景有沒有特殊規(guī)則？
- 這個場景結(jié)束后會有什么情況？
- 這個場景和別的場景會有什么聯(lián)系？
考慮這幾個問題的話，那我們就可以開始描述我們的用例了，這步工作我們就稱為用例描述。
好了，我們針對這幾個問題一個個來給出它們的標(biāo)準(zhǔn)定名：
- 誰在這個場景中做事？
我們稱之為參與者
- 怎么會進(jìn)入這個場景？
我們稱之為前置條件
- 這個場景在做什么？
我們稱之為基本操作流程、可選操作流程
- 這個場景有沒有特殊規(guī)則？
我們稱之為業(yè)務(wù)規(guī)則
- 這個場景結(jié)束后會有什么情況？
我們稱之為后置條件
- 這個場景和別的場景會有什么聯(lián)系？
我們稱之為相關(guān)用例
讀過我之前一篇的朋友一定會記得用例分為業(yè)務(wù)用例 和系統(tǒng)用例 兩種。針對這兩種用例，相對來說都會根據(jù)這些標(biāo)準(zhǔn)定名來描述用例。
只是，有許多人習(xí)慣在業(yè)務(wù)用例 中不作描述，或者只是簡單的描述一下，這點我認(rèn)為無所謂，因為業(yè)務(wù)用例是描述企業(yè)的組織機(jī)構(gòu)中各部門的業(yè)務(wù)，它的用例實在是很粗的，它本身的目標(biāo)只在于可以及時得在談需求時記錄下企業(yè)的業(yè)務(wù)。不過我認(rèn)為最好的做法是在業(yè)務(wù)用例的階段，我們需要將業(yè)務(wù)用例劃分出來，然后根據(jù)調(diào)研的結(jié)果將業(yè)務(wù)流程清晰的描述出來，表達(dá)的方式就不用太過拘泥，最簡單的就可以是“我做 1-> 我做 2-> 我做 3… ”。
而在系統(tǒng)用例 部分則不得不清晰得來表明每個用例的場景，演示系統(tǒng)的需求，描述系統(tǒng)的功能。那么這里我們就用一個例子來說明一下這些描述吧。
根據(jù)之前曾經(jīng)給出的一組用例來看：
我們來描述“提取商品信息”這個用例（請注意這是系統(tǒng)用例 ）。
參與者：
商品管理員
參與者的意思是，誰在對這個用例進(jìn)行使用
前置條件：
1. 商品管理員登陸 XXX 系統(tǒng)后擁有能夠操作該用例的權(quán)限
2. 商品信息的名稱、生產(chǎn)日期可以被商品管理員獲取作為條件
前置條件的意思是，在怎樣的前提下，該用例才有可能被使用。
基本操作流程：
商品管理員輸入商品名稱和信息-> 系統(tǒng)提取對應(yīng)的商品并顯示所有商品信息
可選操作流程：
商品管理員輸入商品名稱和信息-> 系統(tǒng)無法根據(jù)條件得到對應(yīng)商品信息，系統(tǒng)提示商品管理員重新輸入條件
基本操作流程和可選操作流程的意思是，描述用例中基本的操作步驟和系統(tǒng)的反應(yīng)結(jié)果，以及針對同一操作步驟可能會出現(xiàn)的另一種可能性。
業(yè)務(wù)規(guī)則：
1.在提取商品信息的時候必須滿足不能提取“安全鎖”類型的商品
業(yè)務(wù)規(guī)則的意思是，在整個用例的場景中，無法在前置條件或后置條件以及基本操作流程和可選操作流程中描述的一些特殊業(yè)務(wù)規(guī)則。該業(yè)務(wù)規(guī)則是隱含的卻是必須的。
后置條件：
1. 被提取的商品其狀態(tài)全部變成“已查看”狀態(tài)的商品
后置條件的意思是，在用例結(jié)束后會產(chǎn)生怎樣的一個結(jié)果，而該結(jié)果可能會對今后的其他用例產(chǎn)生一定的影響。
相關(guān)用例：
擴(kuò)展的用例：打印商品信息、更新商品信息
被包含的用例：獲取商品單價
相關(guān)用例的意思是，能夠在用例的描述中查看到當(dāng)前用例與其他用例的關(guān)系，一般只有直接與當(dāng)前用例相關(guān)的用例才會被作為相關(guān)用例，而且需要使用“擴(kuò)展的用例”和“被包含的用例”來清晰的定義。
這樣，我們的系統(tǒng)用例就完成了，雖然很煩瑣，但是能夠清晰的告之你的客戶,你的系統(tǒng)將會做什么，不是一件令人很愉快的事嗎？
完成了這一步后，我們接著的工作就需要進(jìn)入邏輯模型了。邏輯模型對于我們來說，是為了展示這個系統(tǒng)是怎樣做的。因此它牽涉到的內(nèi)容就比較多了。而一般而言，對于邏輯模型，我們通常分為做三步：
Step-1 ：業(yè)務(wù)對象模型
業(yè)務(wù)對象模型描述的是現(xiàn)行的業(yè)務(wù)活動對象之間的關(guān)系，是通過從業(yè)務(wù)用例視圖中調(diào)研描述的結(jié)果以及角色和客戶交付的文檔中的對象演化而來，通過對象合作來實現(xiàn)。
Step-2 ：分析模型
分析模型屬于推進(jìn)用例的實現(xiàn)，它是在系統(tǒng)用例模型和業(yè)務(wù)對象模型基礎(chǔ)上更進(jìn)一步的對一個用例的實現(xiàn)說明。它更多的是告訴了我們，針對某個用例，系統(tǒng)會怎樣實現(xiàn)。而在這里我們就會引出一個新名詞“用例實現(xiàn)”，也會看到“類”。
Step-3 ：設(shè)計模型
設(shè)計模型和分析模型一樣，其實也是告訴了我們針對某個用例系統(tǒng)會怎樣實現(xiàn)，只是設(shè)計模型更抽象，它已經(jīng)要求帶入了實現(xiàn)技術(shù)的概念。
it知識庫：需求分析階段的工作（二）：用例描述和邏輯模型，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
