一.系統邊界和參與者
參與者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,泛化