1、面向對象分析與設計Object-Oriented Analysis & Design-2-學習路線圖OOUML : : 核心過程-3-業務建模Business Modeling-5-開發過程解析 業務建模：用軟件建模方法描述業務流程；其目標是認識業務本質，該業務本質是后續用例建模的基礎 用例建模：采用UML用例建模技術描述軟件需求，該需求模型將為后續用例分析提供輸入 用例分析：采用UML用例分析技術分析軟件需求，建立軟件系統的分析模型 架構設計：在系統的全局范圍內，以分析模型為基礎，設計系統的架構 構件設計：根據架構設計的成果，將分析模型細化，設計系統構件的實現細節 代碼實現：將系統構

2、件映射到目標語言上-6-業務 業務是指某個組織或者組織單元 業務可以看作一種包含了人、機器、資源的“系統” 利用軟件思想(用例思想、對象思想)描述業務的過程，就是業務建模 業務建模只是輔助環節 不是所有項目都需要 也不一定和軟件開發相關-7-業務建模 業務建模的目的 理解將要實施的系統的組織結構和動態特性 理解當前在目標組織中的問題，并明確改進的潛力 確保客戶、最終用戶和開發人員對目標組織有統一的理解 獲取用于支持目標組織的系統需求 業務建模關注 機構的核心價值 機構的邊界 機構的參與者 機構中的工作流及如何優化-8-業務建模方法 研究對象 軟件要改進的 研究目標 定義業務本質 研究方法：把業

3、務看成對外提供價值的價值流-9-業務建模工件 業務用例模型(Business Use-Case Model) 業務用戶表示為 業務過程表示為和 業務對象模型(Business Object Model) 人們在組織中扮演的角色表示為 組織管理或制造的“東西”表示為-10-業務建模流程 0. 建立 1. 識別業務參與者 2. 識別業務用例 3. 詳述業務用例 4. 建立-11-業務建模流程 0. 建立 1. 識別業務參與者 2. 識別業務用例 3. 詳述業務用例 1. 建立-12-1.業務參與者(Business Actor) 識別業務參與者 在，與業務進行的人或組織-13-區分業務工人(Bus

4、iness Worker) 業務參與者在業務外面 業務工人在業務里面儲戶儲戶營業員營業員-14-區分業務實體(Business Entity)營業員營業員經理經理帳戶帳戶取款機取款機點鈔機點鈔機儲戶儲戶-15-識別業務參與者思路 客戶 供應商 合作伙伴 潛在客戶 政府 組織中未建模部分 -16-2.業務用例(Business Use Case) 識別業務用例 業務為業務參與者提供的 體現企業業務本質，是的目標看清楚了，我就是業務用例看清楚了，我就是業務用例-17-業務用例與業務參與者取款取款存款存款儲戶儲戶轉帳轉帳企業企業貸款貸款食客食客吃飯吃飯-18-識別業務用例的方法 直接獲得：從業務參與

5、者的角度，從外部推導出來 拼裝：從里面往外面看，內部業務流程的目標是什么業務工人業務工人業務工人業務工人活動活動活動活動直接獲得-19-從業務流程拼裝業務用例 業務流程 1. 收款人在支票背后簽名，寫上身份證件號碼，把支票和身份證件交給營業員 2. 營業員核對印章正確且證件有效 3. 營業員操作營業受理系統，辦理支票兌現手續 4. 營業員把現金和證件交給交款人收款人收款人兌現支票兌現支票-20-識別業務用例-支持性事件 不要遺漏支撐性業務流程背后的業務用例 支持性事件 人員的發展與維護 業務內部IT的開發與維護 辦公室的設立與維護 安全性 法律活動 例：公司為什么要舉行足球比賽？董事會董事會提

6、高員工士氣提高員工士氣-21-3.詳述業務用例 業務用例是對業務流程的封裝，在業務建模過程中需要逐一描述其內部細節，即詳述業務用例 目的 詳細說明業務用例的工作流程 說明業務用例的工作流程，以便于客戶、用戶和涉眾理解 -22-三種可選技術-23-選擇合適的技術 只有文字 不生動，不便于和客戶交流 只有活動圖 難以表達所有細節 業務用例文檔中插入活動圖 活動圖中插入文字(+注釋+基本路徑) 順序圖(需要涉及到業務對象模型)-24-細說活動圖-25-細說活動圖(1) 起點、終點 活動的一種特殊形式，各自只有一個 起點：只有離開的轉移 終點：只有進入的轉移 存在從起點出發，到達終點的路徑 活動和動作

7、 有進有出 動賓結構 可以簡單，可以復雜 分區 定義活動的負責者-26-細說活動圖(2) 控制流 向外轉移的條件之和必須是完備集 向外轉移的條件之間不能重疊 決策點 注意和流程圖的區別 誤把活動當決策 圖中判斷“技術可行性”需要單獨的活動來完成 無空位 有空位 -27-細說活動圖(3) 并發(concurrent) 同步條(synchronization bar)的分叉(fork)與合并(join) 有分必有合 有分必有進 有合必有出 并發同時-28-活動圖中的對象流 指定活動操作的數據(對象)以及數據的流向(對象流) 業務對象(business objects)、對象流(object flo

8、ws) 指出對某些業務實體的操作，類似結構化中的數據流圖 UML2中對象流由原來的虛線改為實線-29-活動圖的分層 活動可以簡單可以復雜，復雜的活動可以進一步細化：分層 頂層有起點終點，下層可以沒有 出入平衡-30-4.業務對象模型 業務對象模型(Business Object Model) 勾勒出實現業務關系中的人、事物、設備、資源以及它們之間的關系；即業務工人和業務實體之間的靜態關系 從另一個視角描述現實 使用UML類圖描述 不要和待開發系統中的分析設計類相混淆-31-餐館的業務對象模型廚師廚師菜肴菜肴1.*1.*1 1 1 11.*1.*負責負責服務員服務員領位員領位員雇員雇員-32-業

9、務建模實踐：建模指南 業務模型不是UML標準直接支持的，但是通過UML的擴展機制可以很方便的建立業務模型 主要構造型(stereotype) 業務用例模型 參與者的構造型：業務參與者(Business Actor) 用例的構造型：業務用例(Business Use Case) 業務對象模型 類的構造型：業務工人(Business Worker)、業務實體(Business Entity)-33-建模指南：模型的組織 利用“包”組織模型 用例視圖中 “業務用例模型” 每個業務用例的”狀態/活動模型” 邏輯視圖中 “業務對象模型”-34-建模指南：使用構造型 業務用例模型是在UML的用例模型(用例

10、圖)基礎上添加構造型來實現的 業務對象模型是在UML的對象模型(類圖)基礎上添加構造型來實現的 利用已有元素添加構造型 Rose直接支持這些構造型-35-業務建模實踐：實例分析 研究對象：某旅店 業務現狀： 某旅店可對外開放50個雙人間和20個單人間，房間費用視情況按季節調整，但周一到周五提供半價（周末全價）折扣 旅客可以直接入住房間(如果有空房)，也可提前預訂；入住和預訂都需要登記個人信息 旅客提前預訂房間時，需提交一定的訂金；入住時間24小時之外的旅客可以取消預訂，并退回所有訂金，24小時以內則不退還訂金 退房時繳納全部的住宿費用 服務員每月為經理提供房間的預訂情況和入住情況的詳細信息-3

11、6-實例分析：業務用例模型-37-實例分析：旅客住宿業務流程-38-實例分析：檢查業務用例模型 該業務用例模型體現了整個旅店的業務需求嗎？ 如何考慮這項業務：服務員每月為經理提供房間的預訂情況和入住情況的詳細信息？ 經理是什么，如何體現在業務建模過程中？ 是業務參與者還是業務工人？體現怎樣的業務本質的差異？-39-實例分析：業務對象模型-40-從業務模型到系統模型 對于軟件開發而言，業務建模只是輔助環節，并不是最終目標 軟件工程師最終目標是要構造軟件系統 業務建模則是一種定義系統模型的輔助手段 從業務模型到系統模型 業務模型描述了目前的業務現狀 系統模型才是軟件開發的最終工件-41-業務模型為

12、系統模型提供素材 為用例視圖和邏輯視圖提供輸入 對于每個將被系統實現的業務用例，在用例視圖中確定一個系統用例或用例包（或單獨的子系統）來實現該業務 為需要支持自動化業務確定相應的用例 對于業務對象模型中的業務實體，可以在系統模型中定義對應的實體類 為系統構架提供一些重要的構架機制 在軟件構架中定義專用層來實現復雜的業務邏輯-42-業務模型映射到系統模型 從入手，結合系統，可以幫助獲取系統模型 可能的對應關系(并非一一對應) 業務用例 系統(子系統) 業務參與者 系統參與者 業務工人 系統參與者 業務工人的操作(活動) 系統用例 業務實體 實體類用例建模Use Case Modeling-44-

13、內容安排 理解需求 從業務模型獲取需求 建立用例模型 編寫用例文檔 重構用例模型 其它問題-45-內容安排 從業務模型獲取需求 建立用例模型 編寫用例文檔 重構用例模型 其它問題-46-需求建造“正確”的系統 需求：客戶可接受的、系統必須滿足的條件或具備的能力 RUP中的FURPS+軟件質量準則 功能性（Functionality） 使用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） +需求工程的主要活動 定義需求 理解用戶的需要，建立用戶可理解的系統需求模型分析需求 根據需求模型，建立開發者無二義性解釋的分

14、析模型 需求管理-47-48-需求難在何處：石頭問題 我要一塊石頭 差不多，但我要小一點的 很好，不過我要藍色的 啊，沒有那么小 咳，還是原來那個好了 -49-需求：也需要開發客戶客戶/用戶的要用戶的要求求/想法想法/期望期望軟件設計軟件設計軟件產品軟件產品開發開發編碼和測試編碼和測試驗收驗收有價值的有價值的軟件需求軟件需求分析和設計分析和設計-50-需求問題：對策-51-內容安排 理解需求 用例建模流程 獲取原始需求 構建初始用例模型 編寫用例文檔 重構用例模型-52-從業務模型獲取需求 有業務模型 從業務用例模型中尋找系統改進點 結合系統，獲取系統用例來表達需求 采用需求啟發技術，從涉眾獲

15、得-53-從業務模型獲取需求 從業務用例模型中獲取系統需求，來構建系統用例模型 1. 尋找業務改進點 2. 定義項目遠景 3. 導出系統需求-54-1. 業務改進點 業務模型描述業務現狀，這些現狀： 有些可能一直運轉的很好，不需要改進，也就沒有必要作為軟件需求來由系統實現 而另外可能更多的業務在運轉過程中存在這樣或那樣的問題，這些問題就成為業務待改進的改進點，也就很可能作為軟件需求而存在-55-尋找業務改進點 從業務流程中獲取改進點的思路： 信息的自動流轉 演繹復雜業務邏輯 訪問和操作業務對象 自動工作 -56-2. 遠景(Vision) 系統改進點不等同于軟件需求 用戶根據自身的工作特點和支

16、付能力決定哪些應該改進，哪些不需要改進 這就是用戶的遠景，它表明用戶改進的目標，這也將成為項目的目標 業務模型描述了“現實是什么”，遠景則描述“希望的改進” 遠景表達了“為什么要開發這個系統” 在業務現狀(業務模型)下，開發系統是為了達到什么目標？-57-定義項目遠景 遠景包含了對待開發系統的目標和約束 代表了項目涉及的所有人之間達成的第一個共識 是項目核心需求的概覽 為更詳細的技術需求提供了契約性的依據 指導團隊實現具體的業務目標 遠景的作用 最初，根據項目的遠景目標來決定項目是否值得繼續 在項目批準后，團隊根據項目遠景來指導后續的需求和設計-58-遠景說明 遠景可以作為一個單獨的文檔存在，

17、而這其中最重要的部分就是關于遠景目標的說明，它建立了一個項目涉及的所有人的共同目標 遠景說明應該是精確、清晰和激勵性的描述，以便激勵所有的團隊成員為達成該遠景而努力。一個好的遠景應該具有以下五個特點(SMART)： 具體的（Specific） 可測量的（Measurable） 可實現的（Achievable） 相關的（Relevant） 基于時間的（Time-based）-59-3. 導出系統需求 從業務改進點入手，結合項目遠景，導出系統需求： 對于每一個業務改進點，明確是否是為了達到遠景目標的需要 如果是則作為軟件需求而存在，并把相應地模型作為系統模型 如果不是則不作為需求而存在，可能作為一

18、項潛在的需求考慮，也可能直接拋棄 -60-實例分析：旅店系統開發背景 隨著旅店聲譽日益提高，住宿人員越來越多，旅客為了能夠獲得好的房間，均提前預訂房間 然而，隨著預訂的增多、預訂周期的拉長，前臺服務員工作壓力也日益增大，還經常出現工作的失誤，使得已經預訂好房間的旅客也不能按期入住，這給酒店的聲譽帶來不好的影響 為此，旅店老板想到了計算機，希望能夠通過計算機來自動管理這些預訂業務，不過由于目前資金的問題，目前只開發一個單機版的系統，不提供網上業務；并且旅店方面的其它業務暫不考慮信息化問題 旅店老板委托某計算機公司開發該系統，并承諾如果系統運轉良好的話，將會考慮進一步合作事宜-61-遠景：旅店預訂

19、系統 A很榮幸地成為項目經理，并被要求在兩個月之內發布該系統的第一個版本，同時還被要求要為后續的開發提供必備的接口 結合現狀和老板的要求，考慮到的項目可擴展的要求，A首先進行了簡單的業務建模 之后，A初步定義了項目的遠景 方便、快捷、準確地為旅客預訂房間 旅客可以方便的取消預訂的房間 旅店經理能夠定期的獲取預訂的信息，根據這些信息可以及時調整房間的價格 及時、快速地計算房間費用、預訂費用、取消預訂后退款金額等信息 ?預留接口：可以為以后的網絡版，以及其它業務系統的開發提供支持-62-結合遠景，獲取系統需求-63-業務模型映射到系統模型思路 從入手，結合系統，可以幫助獲取系統模型 可能的對應關系

20、(并非一一對應) 業務用例 系統(子系統) 業務參與者 系統參與者 業務工人 系統參與者 業務工人的操作(活動) 系統用例 業務實體 實體類-64-內容安排 理解需求 從業務模型獲取需求 編寫用例文檔 重構用例模型 其它問題-65-1.需求從何而來 需求只能來自涉眾(stakeholders) 最終用戶、客戶 政府、法律、文化 開發人員、管理人員 競爭對手 但并不是直接從涉眾中來 你們的需求是什么？-66-涉眾無法直接提供需求 涉眾無法陳述自己的需要 涉眾說的是解決方案而不是需求 涉眾難以構想新的工作方法 涉眾的利益矛盾 涉眾抵制變更 “最好也要有”過度的要求 需求引發需求-67-需求啟發技術

21、 需求工程師利用需求啟發技術，從涉眾中發掘需求 收集資料 現場觀察 訪談 開會 原型 問卷調查 -68-2 識別參與者(Actor) 識別參與者 關鍵詞：邊界 參與者：在系統之外，透過系統邊界與系統進行有意義交互的任何事物-69-參與者要點分析 系統外 參與者不是系統的一部分，處于系統的外部 系統邊界 參與者透過系統邊界直接與系統交互，參與者的確定代表系統邊界的確定 系統角色 參與者與使用系統的物理人和職務沒有關系 需要從參與系統的角色(作用)來尋找參與者 與系統進行信息交互 系統需要關注其交互過程，即系統職責 任何事物 人、外系統、外部因素、時間-70-要點：與系統進行信息交互-71-要點：

22、任何事物-72-任何事物：小人與圣小豬-1-73-小人與圣小豬-2 眾所周知，用例圖中的參與者用一個小人表示。但是這個小人具有一定的誤導性，往往讓初學者(包括客戶)理解為一個真實的人。大多數UML 學習者都要花好長一段時間來搞明白小人其實不一定代表的是人，而是很抽象的系統不可控的外部因素，比如說另一個系統。那么為什么不干脆用其它的符號來表示參與者呢？ 如果我開發一個豬圈自動供食供水系統，豬的前蹄觸發一個開關系統就供食或供水。顯然，這里的參與者 是小豬。那么在用例圖里用小豬代替原來的小人不是更易于交流嗎？-74-思考：參與者與系統邊界？ 某企業要求開發一個企業信息管理系統，并與原來已有的庫存系統

23、相連接 某企業要求開發一個企業信息管理系統，并把原來已有的庫存管理系統加以改造，成為企業信息管理系統的一部分-75-識別參與者的思路 可以從以下要點來識別參與者 系統在哪些部門使用 誰向系統提供信息、使用和刪除信息。 誰與系統的需求有關聯 誰使用系統的功能（用例） 誰對系統進行維護 與外部系統是否有關聯 時間參與者：一種習慣用法，用于激活那些系統定期的、自動執行的用例-76-參與者的命名 對參與者賦予能更好地表達其角色(作用)的名稱 不好的參與者命名的例子：用職務名稱和個人姓名來命名 例如，張三、老李、校長、科長 若使用系統的人（職務名稱）變化的話，就不是參與者了 好的參與者命名的例子：用能知

24、道其角色的名稱來命名 例如，學生、訂單管理員、維護部門 即使使用系統的人改變，從系統來看，使用者的角色（作用）是相同的。-77-參與者之間的關系：泛化 參與者可以通過來定義，在這種泛化關系中，一個參與者的抽象描述可以被一個或多個具體的參與者所共享 如系統中經理可以參加雇員的所有用例用例A雇員用例B經理用例C-78-參與者地位 識別用例之前重要 有助于識別用例，寧多勿少 開始書寫用例文檔以后不重要 涉及的參與者太多 測試和部署階段重要 需要從參與者的角度考慮-79-3 識別用例 關鍵詞：價值 定義 用例實例是系統執行的一系列動作，這些動作將生成特定參與者可觀測的結果值 一個用例定義一組用例實例（

25、場景） 簡潔：參與者使用系統達到某個目標記住了，我是(系統)記住了，我是(系統)用例用例-80-用例要點 可觀測用例止于系統邊界 結果值用例是有意義的目標 系統執行結果值由系統生成 由參與者觀測業務語言、用戶觀點 一組用例實例用例的粒度-81-要點：有意義的目標 設定查詢條件 會員 選擇零件 會員 檢索零件-82-要點：結果值由系統生成出納員吃飯-83-要點：用戶觀點而非系統觀點-84-用例的命名 參與者視角： （狀語）動詞+（定語+ ）賓語-85-要點：用例粒度-1 用例是一組用例實例的抽象；其內部要有路徑，路徑要有步驟 最常犯錯誤：粒度過細，陷入功能分解 通過執行用例，參與者完成想做的事情

26、(最終的目的)，并為參與者產生價值 過細的粒度，一般都會導致技術語言的描述，而不再是業務語言-86-用例粒度-2 把步驟當用例 把系統活動當用例 會員 輸入用戶名 驗證用戶名和密碼 會員 登錄 查詢訂單建立數據庫連接執行SQL語句-87-用例粒度-3 “四輪馬車” C(Create)R(Read)U(Update)D(Delete) 所有業務最終對會成為CRUD？ CRUD能為Actor提供價值？ CRUD掩蓋業務，銳變成關系數據庫的建模： “系統就是數據的增刪改查” 關心數據的存儲和維護，反而忽略了用戶的目的 刪除用戶 修改用戶 增加用戶 管理員 查詢用戶-88-用例粒度-4 如果確實是CR

27、UD？ 如果CRUD不涉及復雜的交互，一個用例“管理”即可 不管是C、R、U、D，都是為了完成“管理”目標 甚至很多種的基本數據管理都可以用一個用例表示 管理員 管理用戶-89-用例粒度-5 靈活處理CRUD 管理員 管理用戶 增加用戶 -90-找出用例的思路 用例要考慮如下要點來尋找。 參與者的工作是什么 參與者的角色(作用)是什么 參與者是否生成、參照、刪除系統信息 參與者是否需要把外部變更通知給系統 系統是否需要把內部事情通知給參與者 是否存在進行系統維護的用例 用例數量的參考基準 1個系統中存在十幾個用例(或更少) 1個用例中有多個用例實例(場景)-91-UML2.4中的常見的14種圖

28、UML2.4-圖Diagrams類圖Class Diagrams對象圖Object Diagrams構件圖Component Diagrams部署圖Deployment Diagrams用例圖Use Case Diagrams順序圖Sequence Diagrams通信圖Communication Diagrams狀態機圖State Machine Diagrams活動圖Activity Diagrams包圖Package Diagrams組合結構圖Composite Structure Diagrams時間圖Timing Diagrams交互縱覽圖Interaction Overview D

29、iagrams外廓圖Profile Diagrams畫用例圖的基本元素附錄2-1. UML元語-94-用例圖元語返回用例圖-95-活動圖元語返回活動圖-96-類圖、對象圖、包圖元語返回靜態結構圖組合結構圖元語-97-返回組合結構圖-98-順序圖元語返回順序圖-99-通信圖元語返回通信圖-100-交互縱覽圖元語返回交互縱覽圖時間圖元語-101-返回時間圖-102-狀態機圖元語返回狀態機圖-103-構件圖元語返回構件圖-104-部署圖元語返回部署圖-105-外廓圖返回外廓圖-106-4 構建用例圖 用例圖：表達參與者與用例關系圖形-107-內容安排 從業務模型獲取需求 建立用例模型 重構用例模型

30、其它問題-108-撰寫用例文檔 用例文檔：更進一步的精度 需求規格說明書的核心，而用例圖作為用例文檔的索引圖 進一步的精度：文檔 文檔中每一句話都有其價值-109-用例文檔的組成 用例標識(UC)、名稱、描述 涉及的參與者、涉及的用例 涉眾利益 前置條件、后置條件 事件流 基本路徑 備選路徑 補充約束 字段列表、業務規則 非功能需求、設計約束 待解決問題 相關圖(用例圖、活動圖、類圖)用例文檔參考模板用例名用例名稱，與用例圖中的名稱保持一致簡要描述用簡單的幾句話說明用例本身以及使用它的原因參與者與該用例相關的參與者，應與用例圖保持一致涉眾與該用例相關的其他用戶或部門，該用例的執行會對這些用戶產

31、生影響相關用例與該用例存在關系的用例，對于不同的關系可采用不同的表示方式前置條件執行該用例之前必須滿足的條件后置條件在該用例執行之后，系統所達到的狀態基本事件流描述用例在最通常情況下所發生的事件流的執行步驟，采用編號的方式表示發生的先后順序；對于復雜的事件流還可以采用子流的方式分解為多個事件流進行表述備選事件流描述用例基本流程可能出現的分支事件或異常事件補充約束描述與該用例相關的約束，包括數據需求、業務規則、非功能需求、設計約束等待解決問題說明該用例日前還未明確的相關問題相關圖與該用例相關的其他圖形，可以是標準的UML圖，如活動圖、類圖等，也可以是其他格式的圖形。-111-尋找涉眾的思路 區分

32、涉眾與參與者 涉眾是與當前用例存在利益關系的人或組織 參與者是啟動或參與用例執行過程的人或外部事物 可能的涉眾有： 當事人 上游下游 操作對象的主人 -112-前置、后置條件 前置條件約束在用例開始前系統的狀態 作為用例的入口限制，它阻止參與者觸發該用例直到滿足所有條件 說明在用例觸發之前什么必須為真 后置條件約束用例執行后系統的狀態 用例執行后什么必須為真 對于存在各種分支事件流的用例，則可以指定多個后置條件 把用例看作是參與者與系統交互的流程，前置條件和后置條件則是這個流程的入口和出口狀態。如圖 直線箭頭表示基本事件流，曲線箭頭代表各種備選事件流，注意前置條件和后置條件所處位置-113-定

33、義前置、后置條件 前置、后置條件必須是系統能檢測到的 前置條件必須是系統在用例開始前就能檢測到的-114-應用前置、后置條件 某些用例依賴于其他用例 一個用例在離開系統時，可能是另一個用例的前置條件（例如：“登錄”和“管理系統”） 有助于識別漏掉的用例 如果一個用例的前置條件不能有執行其他用例滿足，可能意味著丟失了用例（例如：“管理訂單”卻沒有“登錄”用例）-115-事件流描述-用例交互四部曲1. 動動 作作4. 響響 應應2.驗證驗證3.處理處理系系 統統 用例的核心內容就是參與者和系統交互的過程，這個交互過程在用例文檔中采用事件流的方式進行完整的表示。如圖-116-事件流描述要點 事件流描

34、述要使用戶和開發人員互相理解用例的功能，要注意以下幾點： 使用業務語言：使用用戶平時所使用的語言進行描述 要明確參與者與系統所交互的信息 不使用例如、等這樣的不清晰的表達 不要過多地考慮界面細節 不要描述計算機內部的處理，要描述從系統外部所看到的活動 除了基本流程，還要描述替代流程 要明確描述用例的開始和結束-117-例1：使用業務語言 技術語言：無法與用戶溝通 系統通過JDBC建立數據庫連接，傳送SQL查詢語句，從“商品表”查詢商品的詳細信息 業務語言(用戶語言) 系統按照查詢條件搜索商品的詳細信息-118-例2：描述參與者與系統交互過程 以參與者或系統作為主語描述 參與者 系統 示例 出納

35、員接收顧客的付款顧客的付款數可能高于商品總額 出納員錄入顧客所付的現金總額 系統顯示出應找還給顧客的余額，打印付款收據-119-例3：不細化界面細節 過細的界面細節描述 會員從下拉框中選擇類別 會員在相應文本框中輸入查詢條件 會員點擊“確定”按鈕-120-例4：分支和循環的描述 分支：放到備選路徑中 參與者的選擇 另一條成功線路 系統進行驗證 循環：直接描述-121-用例文檔中的補充約束 用例重點在于描述功能需求，而其它方面的補充約束采用兩種處理策略： 與特定用例相關的補充約束，作為該用例文檔中一部分來描述 一些全局性的補充約束，單獨形成一份獨立的文檔，如“補充需求規約”文檔 補充約束 字段列

36、表 業務規則 非功能需求 設計約束-122-實例分析：撰寫用例文檔 用例文檔參考模板 旅店預訂系統用例文檔 “ UC01-預訂房間”用例文檔-123-內容安排 從業務模型獲取需求 建立用例模型 編寫用例文檔 其它問題重構用例模型 對于一些復雜的系統，用例可能很多，所以可以利用用例建模高級技術重構用例模型 用例關系 通過用例關系將復雜的用例進行適當的分解，以便于提高需求的復用性和可擴展性等，從而使用例模型的結構更合理 用例分級 可以根據用例的重要程度進行分級，以便后續迭代計劃的制定，高級別的用例優先考慮 用例分包 將相關的用例打包，通過分包的方式可以將用例圖分層表示，以用于大規模系統的用例建模-124-125-用例關系擴展擴展包含包含泛化泛化-126-通過關系整理文檔 Extend(擴展) 通過擴展用例對基用例增加附加的行為 Include(包含) 基用例中復用被包含用例的行為 提取公共步驟，便于復用 Generalization(泛化) 派生用例繼承泛化用例的行為并添加新行為-127-用例關系：擴展 擴展：某個用例在特定情況下，包含其他用例(擴展用例)的行為，表示功能被擴展 擴展使用帶有的虛線表示。此時，箭頭由擴展的用例指向原用例，通過擴展點指明在原用例中的擴展位置-128-用例關系：包含 包含：表示某個用例中包含了