業(yè)務(wù)建模及用例建模(共139頁).ppt

1、面向?qū)ο蠓治雠c設(shè)計Object-Oriented Analysis & Design-2-學(xué)習(xí)路線圖OOUML : : 核心過程-3-業(yè)務(wù)建模Business Modeling-5-開發(fā)過程解析 業(yè)務(wù)建模：用軟件建模方法描述業(yè)務(wù)流程；其目標(biāo)是認(rèn)識業(yè)務(wù)本質(zhì)，該業(yè)務(wù)本質(zhì)是后續(xù)用例建模的基礎(chǔ) 用例建模：采用UML用例建模技術(shù)描述軟件需求，該需求模型將為后續(xù)用例分析提供輸入 用例分析：采用UML用例分析技術(shù)分析軟件需求，建立軟件系統(tǒng)的分析模型 架構(gòu)設(shè)計：在系統(tǒng)的全局范圍內(nèi)，以分析模型為基礎(chǔ)，設(shè)計系統(tǒng)的架構(gòu) 構(gòu)件設(shè)計：根據(jù)架構(gòu)設(shè)計的成果，將分析模型細(xì)化，設(shè)計系統(tǒng)構(gòu)件的實現(xiàn)細(xì)節(jié) 代碼實現(xiàn)：將系統(tǒng)構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

28、ams類圖Class Diagrams對象圖Object Diagrams構(gòu)件圖Component Diagrams部署圖Deployment Diagrams用例圖Use Case Diagrams順序圖Sequence Diagrams通信圖Communication Diagrams狀態(tài)機圖State Machine Diagrams活動圖Activity Diagrams包圖Package Diagrams組合結(jié)構(gòu)圖Composite Structure Diagrams時間圖Timing Diagrams交互縱覽圖Interaction Overview Diagrams外廓圖Pro

29、file Diagrams畫用例圖的基本元素附錄2-1. UML元語-94-用例圖元語返回用例圖-95-活動圖元語返回活動圖-96-類圖、對象圖、包圖元語返回靜態(tài)結(jié)構(gòu)圖組合結(jié)構(gòu)圖元語-97-返回組合結(jié)構(gòu)圖-98-順序圖元語返回順序圖-99-通信圖元語返回通信圖-100-交互縱覽圖元語返回交互縱覽圖時間圖元語-101-返回時間圖-102-狀態(tài)機圖元語返回狀態(tài)機圖-103-構(gòu)件圖元語返回構(gòu)件圖-104-部署圖元語返回部署圖-105-外廓圖返回外廓圖-106-4 構(gòu)建用例圖 用例圖：表達(dá)參與者與用例關(guān)系圖形-107-內(nèi)容安排 從業(yè)務(wù)模型獲取需求 建立用例模型 重構(gòu)用例模型 其它問題-108-撰寫用例

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

31、關(guān)系的用例，對于不同的關(guān)系可采用不同的表示方式前置條件執(zhí)行該用例之前必須滿足的條件后置條件在該用例執(zhí)行之后，系統(tǒng)所達(dá)到的狀態(tài)基本事件流描述用例在最通常情況下所發(fā)生的事件流的執(zhí)行步驟，采用編號的方式表示發(fā)生的先后順序；對于復(fù)雜的事件流還可以采用子流的方式分解為多個事件流進(jìn)行表述備選事件流描述用例基本流程可能出現(xiàn)的分支事件或異常事件補充約束描述與該用例相關(guān)的約束，包括數(shù)據(jù)需求、業(yè)務(wù)規(guī)則、非功能需求、設(shè)計約束等待解決問題說明該用例日前還未明確的相關(guān)問題相關(guān)圖與該用例相關(guān)的其他圖形，可以是標(biāo)準(zhǔn)的UML圖，如活動圖、類圖等，也可以是其他格式的圖形。-111-尋找涉眾的思路 區(qū)分涉眾與參與者 涉眾是與當(dāng)前

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

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

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

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

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