1、,CH5 用例模型 用例規(guī)約,統(tǒng)一建模語言,11軟件工程,回顧,用例的概念 用例的關系 參與者的定義與關系,本節(jié)教學內(nèi)容,詳細、完整地描述需求 用例描述 事件流描述要點 實例 POS銷售 記錄時間 小結(jié),用例規(guī)約,用例規(guī)約 黑盒用例與白盒用例 用例規(guī)約組成 用例規(guī)約類型與書寫風格 簡單型 非正式型 正式型（詳細型）,用例規(guī)約-進行用例闡述,用例規(guī)約：更進一步的精度 用例文檔的核心，而用例圖作為用例文檔的總圖 進一步的精度：有層次的文檔 文檔中每一句話都有其價值,用例圖是骨架 而用例規(guī)約則是其內(nèi)在的肉,誰來寫用例文檔,最完美：業(yè)務人員接受訓練，寫出優(yōu)美的用例文檔 最現(xiàn)實：業(yè)務人員提供素材，開發(fā)人

2、員寫用例文檔 最糟糕：業(yè)務人員不管，完全由開發(fā)人員杜撰,黑盒用例 建模人員常用，不描述系統(tǒng)的內(nèi)部工作流程，也不描述其組成成分或設計。 白盒用例 借助責任描述系統(tǒng)，指出系統(tǒng)應該具有什么職責，具有各種職責的軟件元素之間是如何合作的,黑盒用例與白盒用例,用例規(guī)約組成,用例名稱 用例標識 涉及的參與者 涉及的用例 描述,用例規(guī)約組成,用例的規(guī)格說明 （1）前置條件 與 后置條件 （2）正常事件流 （3）備選事件流 其它 非功能需求、設計約束、尚存在的問題,前置條件約束在用例開始前系統(tǒng)的狀態(tài) 把它們看做是看門人，它阻止參與者觸發(fā)該用例直到滿足所有條件 說明在用例觸發(fā)之前什么必須為真,前置條件,后置條件約

3、束用例執(zhí)行后系統(tǒng)的狀態(tài) 用例執(zhí)行后什么必須為真 對于有多個事件流的用例，則應該有多個后置條件,后置條件,前置、后置條件注意,某些用例依賴于其他用例 一個用例在離開系統(tǒng)時，可能是另一個用例的前置條件（例如：“登錄”和“管理系統(tǒng)”） 有助于識別漏掉的用例 如果一個用例的前置條件不執(zhí)行，就不能執(zhí)行其他用例，可能意味著丟失了用例（例如：“管理訂單”卻沒有“登錄”用例）,事件流-用例交互四部曲,1. 動 作,4. 回 應,2.改變,3.驗證,系 統(tǒng),寫：可觀測的、 體現(xiàn)客戶利益的文字,簡單型,用簡潔的一段話來描述用例，通常只給出主要成功場景 處理銷售 一個顧客帶著商品在收款處準備交費購買。 出納員使用P

4、OS終端記錄所購買的每一件商品 POS系統(tǒng)給出所應收的總款數(shù)以及每件商品的價格細節(jié)。 顧客鍵入支付信息，系統(tǒng)進行確認并記錄。 然后，系統(tǒng)更新商品的存貨清單 顧客拿著系統(tǒng)打印的收條并帶著商品離開。,非正式型,用若干非正式段落來描述用例，通常給出多個不同場景 處理退貨 主要成功場景：顧客帶著商品到收款處退貨，出納員使用POS終端記錄每一件被退回的商品。 可選場景：如果系統(tǒng)中找不到商品標識，那么就通知出納員并建議他手工輸入商品標識碼（或許商品的標識已經(jīng)破損）；如果系統(tǒng)檢測到和外部稅金計算系統(tǒng)之間的通信失敗，那么就。,描述更多細節(jié)并以結(jié)構化方法組織這些細節(jié)，對理解系統(tǒng)非常有意義 參考：http:/ww

5、,正式型（詳細型）,正式型（詳細型）-處理銷售1,1. 用例 UC1：處理銷售 2. 主要參與者：出納員 3. 受益人及其利益： （1）出納員：需要精確、快速的輸入，并且不出現(xiàn)支付錯誤 （2）銷售人員：需要銷售款得到更新 （3）顧客：需要購買并花費最小的精力得到快速的服務，并需要支持退貨功能 （4）公司：需要精確地記錄交易并滿足客戶的利益。需要支付授權服務記錄可接受的支付。需要一些容錯功能。需要賬目和存貨清單得到自動的快速更新 （5）政府稅務機構：需要從每一次銷售中收稅。 （6）支付授權服務：需要用正確的格式和協(xié)議傳來的數(shù)字授權請求。需要精確計算它們可支付給商店的款

6、額,正式型（詳細型）-處理銷售4,4. 前置條件： 出納員需要身份識別并授權 5. 后置條件： 存儲了銷售情況， 正確地計算了稅金， 更新了賬目和存貨清單， 記錄了銷售額， 打印了收據(jù),正式型（詳細型）-處理銷售5,6.主要成功場景： （1）顧客帶著商品到POS終端處準備購買 （2）出納員開始一次新的銷售 （3）出納員輸入商品標識碼 （4）系統(tǒng)記錄銷售的商品并給出商品的描述、單價和折扣，并根據(jù)某些價格規(guī)則計算所應付的款額。出納員重復步驟3和步驟4，一直到處理完所有商品為止。 （5）系統(tǒng)給出所應支付的總款額并計算稅金 （6）出納員告訴顧客總價并請求付款 （7）顧客付款，系統(tǒng)處理支付 （8）系統(tǒng)記

7、錄下已完成的銷售，并將銷售和支付信息發(fā)送給外部的賬目系統(tǒng)以及存貨清單系統(tǒng) （9）系統(tǒng)打印收據(jù) （10）顧客帶著收據(jù)和商品離開,正式型（詳細型）-擴展1,1a 在系統(tǒng)失敗時，要恢復和校正賬目，確保所有的交易敏感狀態(tài)以及事件能夠從場景的任何步驟中恢復 (1)出納員重啟系統(tǒng)和登錄，并請求恢復先前的狀態(tài) (2)系統(tǒng)重建先前的狀態(tài),2a 系統(tǒng)檢測阻止恢復的異常狀態(tài) (1)系統(tǒng)給出納員發(fā)出一個出錯信號，記錄該錯誤并進入一個干凈的狀態(tài) (2)出納員開始一次新的銷售,正式型（詳細型）-擴展3,3a 無效標識碼： 系統(tǒng)發(fā)出一個出錯信號并拒絕輸入 出納員可以手工輸入商品標識碼 2a 輸入無效標識碼，系統(tǒng)拒絕輸入

8、4a 顧客可能購買多件相同類別的商品，因此記不記錄每件商品的標識碼并不重要 出納員可以輸入商品類別號以及數(shù)量,正式型（詳細型）-擴展4,3-6a 顧客請求出納員從購買的貨物中去掉一件商品 3-6b 顧客告訴出納員取消銷售 3-6c 出納員中止銷售 4a 系統(tǒng)所輸出的商品單價不是顧客所想要的,正式型（詳細型）-擴展5,5a 系統(tǒng)檢測到和外部稅金計算系統(tǒng)之間的通信失敗 5b顧客說他們符合打折條件 5c 顧客說他們帳上的存款為此次銷售付款 6a 顧客說他們想付錢但沒有帶足夠的現(xiàn)金,正式型（詳細型）-擴展6,7a 用現(xiàn)金付賬 出納員輸入顧客所付總款數(shù) 系統(tǒng)計算出應找的余款，并彈出現(xiàn)金抽屜 出納員存放現(xiàn)

9、金并找零給顧客 系統(tǒng)記錄此次現(xiàn)金支付情況,正式型（詳細型）-擴展7,7b 用信用卡付賬 顧客輸入他們的信用卡帳戶信息 系統(tǒng)向外部支付授權服務系統(tǒng)發(fā)出支付請求授權，并請求支付批準 2a系統(tǒng)檢測到和外部系統(tǒng)之間協(xié)作上的失敗： 系統(tǒng)給出納員發(fā)出一個出錯信號 出納員請顧客用其他方式付款,正式型（詳細型）-擴展8,7b 用信用卡付賬 系統(tǒng)收到批準支付回應并向出納員發(fā)出一個批準支付信號 3a 系統(tǒng)受到拒絕該支付信號 系統(tǒng)發(fā)拒絕支付信號給出納員 出納員請顧客用其他方式付款 系統(tǒng)記錄信用卡支付情況，其中包括批準支付情況,正式型（詳細型）-擴展9,7b 用信用卡付賬 系統(tǒng)給出信用卡支付簽名輸入機制 出納員請客戶

10、進行信用卡支付簽名，客戶輸入簽名,正式型（詳細型）-其他擴展,7c 用帳單付款 7d 賒賬 7e 顧客拿出優(yōu)惠券 9a 商品打折 9b 顧客請求贈品收據(jù),正式型（詳細型）-特殊需求,應具有一個大的扁平面板監(jiān)視器上的觸摸屏界面，并可在1m之外看清屏幕上的字 信用卡授權90%的情況下能在30s內(nèi)作出響應 當訪問諸如庫存清單等這類遠程服務時，應具有健壯的恢復功能,正式型（詳細型）-特殊需求,文本顯示應語言國際化 可在步驟3和步驟7插入業(yè)務規(guī)則 。,正式型（詳細型）-其它1,技術和數(shù)據(jù)約束列表 3a 商品標識碼由條形碼激光掃描器或鍵盤輸入 3b 商品標識符可以使UPC、EAN、JAN、SKU編碼格式

11、7a 信用卡賬目信息由信用卡閱讀器或鍵盤輸入 7b 信用卡支付簽名可以在紙上進行。但未來兩年內(nèi)，顧客可能更愿使用數(shù)字簽名,正式型（詳細型）-其它2,發(fā)生頻率：幾乎可以連續(xù)發(fā)生 尚未解決的問題 稅法變化怎么辦 遠程服務恢復問題 不同的業(yè)務需要什么樣的自定義功能 出納員退出系統(tǒng)時必須帶走現(xiàn)金抽屜嗎 顧客使用信用卡閱讀器還是出納員使用,事件流描述要點,一個正常的業(yè)務事件流描述 只書寫“可觀測”的 使用主動語句 句子必須以參與者或系統(tǒng)作為主語 不要涉及界面細節(jié) 分支和循環(huán),要點1-只寫“可觀測”的,系統(tǒng)通過ADO建立數(shù)據(jù)庫連接，傳送SQL查詢語句，從“商品表”查詢商品的詳細信息 系統(tǒng)按照查詢條件搜索商

12、品的詳細信息,要點2-主動語句,歐文從貝克漢姆處得到傳球，守門員 貝克漢姆傳球給歐文，歐文射門，守門員撲救,要點3-以參與者或系統(tǒng)作主語,參與者 出納員接收顧客的付款顧客的付款數(shù)可能高于商品總額 出納員錄入顧客所付的現(xiàn)金總額 系統(tǒng) 系統(tǒng)顯示出應找還給顧客的余額，打印付款收據(jù),要點4-不涉及界面細節(jié),會員從下拉框中選擇類別,會員在相應文本框中輸入查詢條件,會員點擊“確定”按鈕,要點5-分支和循環(huán),分支：放到擴展路徑 參與者的選擇 另一條成功線路 系統(tǒng)進行驗證 循環(huán)：直接描述,用例規(guī)約：記錄時間,UC01：“Record Time”用例文檔 用例名稱：Record Time（記錄時間） 用例標識：

13、UC01 涉及的參與者：雇員、系統(tǒng)管理員 涉及的用例：無 描述：雇員利用“Record Time”用例來登記他們的工時，系統(tǒng)用這個用例為任何雇員登記時間,用例規(guī)約：記錄時間(續(xù)),前置條件： 用戶必須已經(jīng)登錄到這個系統(tǒng) 后置條件： 系統(tǒng)將雇員的工時正確的記錄到數(shù)據(jù)庫中,用例規(guī)約：記錄時間(續(xù)),正常事件流： 雇員查看當前時間之前輸入的數(shù)據(jù)； 雇員從已有的支付號碼中選擇一個，這些收費代碼是按客戶和項目組織的； 雇員從當前的時間段選擇一個日期； 雇員輸入以正整數(shù)表示的工時； 系統(tǒng)在視圖中顯示這個數(shù)據(jù)，并在以后的視圖中看到這個數(shù)據(jù)。,用例規(guī)約：記錄時間(續(xù)),備選事件流1：雇員更改他的時間 雇員查看當前時間之前輸入的數(shù)據(jù)； 雇員選擇一個已有的條目； 雇員改變工時； 在視圖中更新這個信息，并在以后的視圖中都可以看到。,用例規(guī)約：記錄時間(續(xù)),非功能需求：無 設計約束：無 部署約束： 用戶可以從客戶端或雇員的家中訪問到“Record