用例的需求分析-讀書筆記

一.系統邊界和參與者

參與者Actor定義:在系統之外,透過系統邊界和系統進行有意義的互動的任何事物

透露出參與者的特征:

1.不屬于系統

2.通過系統邊界直接和系統互動->參與者的确定決定了系統邊界的确定

3.進行有意義的互動

4.任何事物

其中第二點的"直接"要注意:如果一個顧客通過售票員買機票,那麼對于售票系統來說,售票員是參與者而顧客不是.

由此又産生了業務模組化和系統模組化的差別:對于售票系統來說,當業務模組化的時候,我們描述的是顧客來訂票,可能還有票務中心的主任來詢問售票情況等等事件.但是系統模組化的時候,他們都不是我們的對象,我們描述為售票員要售票和提供售票情況的事件的描述,是以這兩者在模組化的不同階段是不一樣的.

在有些自動系統中,時間往往是觸發系統工作的外部事物,是以參與者是時間,不可忽略.

識别參與者方法:面對一個系統時,你應該問這些問題:

誰使用系統?

誰改變系統資料?

誰從系統擷取資訊?

誰需要系統的支援來完成日常工作?

誰負責管理并維護系統正常運作?

系統要應付那些硬裝置?

系統要和其他的系統互動嗎?

誰對系統産生的結果感興趣?

時間,氣候等外部條件呢?

當你回答完這些問題之後,你的答案基本上就涵蓋了參與者的候選人.

識别參與者的重要性:

1.根據參與者識别系統用例:是以為了完整系統的功能,你識别的系統參與者甯多勿少.

2.測試部署階段你可能會通過識别者的角度去了解系統的完整性.

3.用例文檔編寫階段,參與者不是很重要,但是你應該考慮參與者的泛化關系,避免出現用例的重複功能.

二.識别事件

羅列清楚系統事件,是正确建立系統用例的必要條件.

系統事件分為兩類:系統外部事件和系統内部事件

外部事件就是外部參與者對系統互動的具體工作,内部事件就是系統内部觸發的工作,通常由時間觸發.

識别事件的方法:頭腦風暴法-主語+謂語+賓語,描述系統可能發生的事情,盡可能全面,同樣是甯多勿少的原則,不過你可以根據事件的重要程度進行一個排序,這能加深你對系統的認識.

通常把識别出來的事件列成一個表格:稱為3A表

Actor  Action Aim

參與者  作甚麼  業務目的

...  ...  ...

三.識别用例

用例定義:用例是一組用例執行個體

用例執行個體定義:系統執行的一系列動作,用以産生參與者可觀測到的結果值

用例要點:

1.位于系統  --必須由系統運作

2.目标導向  --用例運作必須有所目的

3.止于邊界  --可以觀測到結果,并且是在邊界和外部有所互動的

4.使用者觀點  --參與者觀測

5.粒度   --是一組有共同目标或者可以類聚的目标的執行個體們組成

識别用例是從業務模組化開始的,也就是說我們描述用例是從使用者的角度即使用者觀點出發的識别行為,描述用例是用純粹的業務語言,而不是技術語言.比如描述為清繳稅款,而不是J2ee架構.是以,使用者的命名也是從使用者的角度出發,描述使用者要做的一件通過系統完成有目的,有結果的行為.

用例的粒度不宜過細,過細的分解會導緻用例描述的錯誤:

1.把互動的步驟成為一個用例,而不是把一類一系列步驟作為一個用例.例如,使用者登陸是一個用例,錯誤的做法是把請求輸入使用者名也作為一個用例.

2.把必要的處理過程中的一些系統内部活動稱作用例:驗證使用者,連接配接資料庫,發送SQL請求等稱作一個用例,其實都是使用者登陸這一次互動的步驟而已.

3.把識别用例的工作當成是關系資料庫分析的工作:稱作四輪馬車的錯誤,即CRUD(Create Read Update Delete).例如管理使用者是一個用例,但是可能變成了增加使用者,查詢使用者,修改使用者,删除使用者的"系統就是資料的增删改查"的認識論錯誤.

識别用例的一個關鍵性原則就是:站在使用者的角度分析使用者的目的,而不是站在系統的角度,更不是站在資料的角度.

通過建立的系統事件可以很順利的畫出用例圖,但是應該記住"用例的本質是文字",是以我們最終要将用例圖轉化成用例文檔.可以用下面的例子格式書寫用例文檔:

用例編号:

用例名:

用例描述:

參與者:

前置條件:開始該用例時的所必需的系統和環境狀态

後置條件:結束該用例時的所具備的系統和環境狀态

基本路徑:

1…..××××

2……××××

3…..××××

擴充點:

2a.××××

2a1….×××××

補充說明:

前置條件和後置條件可以反應用例間的互相依賴關系.還可以防止漏掉某些用例

用例之間的關系:擴充extends,包含include,泛化