李鵬飛pengfei0302@UML系統分析與設計UML-SystemAnalysis&Design1第6章用例建模作業

Use-CaseModeling2旅店管理系統某公司要開發一個旅店管理系統，該旅店可對外開放10個雙人間和10個單人間，房間費用視情況按季節調整，但周一到周五半價（周末全價）折扣不變。對于外界請求，該系統應能根據請求入住時間預定指定檔次的房間，記錄旅客姓名、地址、聯系電話、有效證件號、房間類型和預定天數，并計算出總費用。預定的同時旅客按規定須提交10%定金。六個小時之內旅店允許旅客取消預定，并退回所有定金，超過六個小時定金不退還。每周一系統自動打印一周預定情況清單。采用哪種費用支付方式和何種類型操作界面尚不確定。3問題用例圖1領導的角色沒有價值；旅店房間預訂系統用例沒有意義4問題用例圖2用例圖不描述業務流程圖中箭頭不代表前后順序5問題用例圖3用例圖不描述程序流程不描述控制邏輯6基于用例的需求分析過程1.獲取原始需求2.開發一個可以理解的需求識別參與者識別用例構建用例圖3詳細、完整地描述需求進行用例闡述4重構用例模型識別用例間的關系對用例進行組織和分包71識別參與者參與者，Actor關鍵詞：邊界參與者：在系統之外，透過系統邊界與系統進行有意義交互的任何事物81識別參與者參與者要點系統外參與者代表在系統邊界之外的真實事物，并不是系統的成分系統邊界參與者透過系統邊界直接與系統交互，參與者的確定代表系統邊界的確定有意義的交互考慮責任邊界，非物理邊界任何事物人、外系統、外部因素、時間9識別參與者思路誰使用系統的主要功能誰改變系統的數據誰從系統獲取信息誰需要系統的支持以完成日常工作任務誰負責日常維護、管理并保證系統正常運行系統需要應付（處理）那些硬設備系統需要和那些外部系統交互誰（或什么）對系統運行產生的結果（值）感興趣時間、氣溫等內部外部條件……服務員顧客時間10“時間”參與者的使用時間：參與者，一種習慣用法，用于激活那些系統定期的、自動執行的用例“計算總費用”的時候，時間僅僅是一個條件，而不是參與者，因為此時它是作為系統的一部分11不恰當的“時間”參與者時間：參與者，一種習慣用法，用于激活那些系統定期的、自動執行的用例“檢查是否可以退定金”的時候，時間僅僅是一個系統內部的判斷條件，而不是參與者12無效的參與者泛化參與者泛化：特殊參與者會繼承泛化參與者所有的要素！參與者的重要性在一識別用例，如果泛化沒有帶來任何用例，則這樣的方法沒有任何意義在系統中如果兩個參與者涉及相同的用例，則合并132識別用例關鍵詞：價值定義用例實例是系統執行的一系列動作，這些動作將生成特定參與者可觀測的結果值一個用例定義一組用例實例簡潔：參與者使用系統達到目標142識別用例用例要點可觀測→用例止于系統邊界結果值→用例是有意義的目標系統執行→結果值由系統生成由參與者觀測→業務語言、用戶觀點一組用例實例→用例的粒度152識別用例某公司要開發一個旅店管理系統，該旅店可對外開放10個雙人間和10個單人間，房間費用視情況按季節調整，但周一到周五半價（周末全價）折扣不變。對于外界請求，該系統應能根據請求入住時間預定指定檔次的房間，記錄旅客姓名、地址、聯系電話、有效證件號、房間類型和預定天數，并計算出總費用。預定的同時旅客按規定須提交10%定金。六個小時之內旅店允許旅客取消預定，并退回所有定金，超過六個小時定金不退還。每周一系統自動打印一周預定情況清單。采用哪種費用支付方式和何種類型操作界面尚不確定。16用例干什么？“其他”、“打印清單”用例和外圍沒有任何有意義交互，和其他用例也沒有任何關系，這樣的用例有意義嗎？“其他”用例又代表什么呢？想說明什么樣的功能需求？17用例粒度注意“管理用例”的使用！18用例粒度太小19看看這個用例圖參與者與用例的定義！203構建用例圖(一)顧客21用例關系<<include>><<extend>>ExtendIncludeGeneralization224.用例關系-1：明顯的錯誤依賴關系：include,extend都是依賴關系(dependency)的構造型(stereotype)，帶箭頭的虛線表示“extend”關系的方向，子用例對主用例的擴展234.用例關系-2：什么關系？用例是一個完整的交互，用例之間沒有順序的關系244.用例關系-325擴展關系的使用使用擴展的一個潛在問題是創建過深的擴展依賴層次Jacobson博士建議永遠不要擴展一個擴展對于在描述用例的時候，什么時候用擴展，什么時候用可選路徑，Jacobson建議：只有當擴展用例與被擴展用例完全分離（即它本身是一個獨立的具體用例或者是其他用例需要的一個小片段）時，才使用擴展關系基用例自身必須是完整的，它的正確執行不需要擴展。否則，就應該用可選路徑來描述附加行為26包含關系的使用包含關系使用不當容易誘使人們進行功能分解，從而導致對用例的誤用Jacobson說，“事實上，今天一些人誤用了用例，把它們用來描述功能（注：指功能分解式的分析）而不是對象，反過來又指責用例概念存在問題”27泛化的危害一個售貨員可以終止任何交易，除了那些需要特殊的售貨員（高級代理）終止的超過了一定限制的交易28再看一個29用例規約用例規約用來描述用例的，不是用例圖用例規約該寫什么？用例規約需要與用例圖相對應用例的名稱用例描述：一句完整的話用例間的關系用例與參與者的關系事件流的詳細程度事件流之間的流轉30用例規格描述常見錯誤用例描述中沒有主參與者。用例描述中只有參與者動作，沒有系統動作。事件流中的動作沒有主語。描述中有過多的用戶操作細節，如按鈕等界面元素的具體實現。描述過低的目標級別。31較為合理的用例圖(二)爭論：使用包含還是擴展？32較為合理的用例規格說明1用例名稱：預定房間涉及的參與者：酒店前臺描述：酒店前臺人員根據旅客的入住請求，預定某個時間指定檔次的房間，預定的同時旅客按規定須提交10%定金。

前置條件：前臺工作人員必須已經登錄到這個系統后置條件：預定信息正確的記錄到系統中主事件流：1)前臺人員向系統提供需要預定房間的類型、時間和預定天數。2)系統確認有相應檔次的空閑房間，并計算出總費用和定金。3)前臺人員向系統提供旅客信息（姓名、地址、聯系電話、證件號等）。4)系統記錄旅客信息。5)前臺人員確認已經交納定金。6)系統記錄房間已經預定，工作完成。備選事件流：2a.沒有指定類型的空閑房間,可以轉到第一步或者取消預定，用例結束5a.顧客沒有交納定金，前臺工作人員取消預定，用例結束。33較為合理的用例規格說明2n用例名稱：取消預訂n主要參與者：酒店前臺n描述：酒店前臺利用該用例來取消顧客的預定，如果在指定時間內，則取消時需要返還顧客定金n前置條件：用戶必須已經預訂了某個房間n后置條件：系統將取消預定的房間恢復為空閑，并且定金已返還給顧客n正常事件流：前臺人員提供給系統顧客信息，比如顧客姓名或證件號碼；系統進行檢查并返回該顧客的預訂信息，包括顧客姓名、證件號碼、聯系電話、房間類型、預訂時間、預訂天數和總費用；前臺人員確認取消該預定；系統取消該房間預訂n備選事件流：2a.系統提示沒有該顧客的預定信息。4a.當取消預訂在六小時之內，系統提示需要退還顧客定金。

4a1.系統提示返回金額；

4a2.前臺人員確認已退還定金；

4a3.系統記錄定金已退