1、1面向對象分析與設計用例建模葉文來2項目分析過程Operation: enterItem()Post-conditions:- . . .Operation ContractsSaledate. . .SalesLineItemquantity1.*1. . . . .Domain ModelUse-Case ModelDesign Model: RegisterenterItem(itemID, quantity): ProductCatalogspec = getProductSpec( itemID )addLineItem( spec, quantity ): Saleobjects,

2、 attributes, associationsRequire-mentsBusiness ModelingDesignSample UP Artifact Relationships: SystementerItem(id, quantity)Use Case TextSystem Sequence DiagramsmakeNewSale()system eventsCashierProcess Sale: Cashieruse case namessystem operationsUse Case DiagramVisionSupplementarySpecificationGlossa

3、ryscope, goals, actors, featuresterms, attributes, validationnon-functional reqs, quality attributesrequirementsProcess Sale1. Customer arrives .2. Cashier makes new sale.3. .3什么是用例建模 什么是用例建模? 一種描述功能性需求的方法 清晰地定義系統的邊界 詳細描述系統和外部環境的交互4用例模型不僅僅是圖形 用例是文本形式的情節描述 重要的用例文本，次要的用例圖5使用用例的好處 用例是對用戶需求（主要是功能需求）的規范化

4、的描述 為需求提供了應用環境 把系統系統定義在一個使用環境中 幫助解釋為什么需要該系統 有助于保證沒有需求的遺漏 易于理解 站在系統使用者的立場上來定義需求 使用客戶和用戶都能理解的術語和表述 易于客戶對于需求的審核為領域專家、最終用戶和開發者提供一種相互交流的手段。 可以為其他開發環節所重用 項目計劃、設計、測試、用戶手冊強調用戶的目標和觀點強調用戶的目標和觀點6定義：參與者、場景和用例 參與者（actor） 是某些具有行為的事物，可以是人、系統或組織 場景（Scenario） 參與者與系統之間的一系列特定的活動和交互 特定的情節或用例的一條執行路徑 用例（use case ） 一組相關的成

5、功和失敗場景集合，用來描述參與者如何使用系統實現其目標 場景是用例的一個實例7什么是場景? 事件流：完成事件的一系列步驟 用例：描述所有的流 場景：用例的某一個實例，從用例開始直到它的某一個結束點 用場景檢驗用例的事件流是否描述完整8場景是用例的一個實例 P47場景1:成功取款（在驗證客戶身份后） 1.客戶輸入提款金額 2.系統查詢客戶賬戶余額，并記錄客戶提款金額，吐出現金 3.客戶提取現金，完成取款 4.系統顯示取款成功場景2:成功取款，中途取款超限額（在驗證客戶身份后） 1.客戶輸入提款金額（超過2500元） 2.系統提示金額超過當筆取款限額2500元，并提示客戶重新輸入 3.客戶輸入正確

6、金額 4.系統查詢客戶賬戶余額，并記錄客戶提款金額，吐出現金 5.客戶提取現金，完成取款 6.系統顯示取款成功9用例建模中的主要模型元素用例是文本形式的場景描述，用以說明某參用例是文本形式的場景描述，用以說明某參與者使用系統以實現某目標的過程。與者使用系統以實現某目標的過程。10用例描述了系統需求 每一個用例 表述了系統向參與者所提供的某種服務 也表述了參與者是如何使用系統的 描述了系統和參與者之間的一段對話誰使用系統？使用的典型場景是什么？他們使用系統目的是什么？11參與者與用例間的通訊關聯 參與者和用例之間進行對話的一個渠道 用一條帶或不帶箭頭的線來表示 箭頭表示是誰發起了這次對話 沒有箭

7、頭表示任何一方都可以發起對話 箭頭并不表示數據的流向，數據流向總是雙向的12用例建模的步驟 界定系統邊界 尋找主要參與者 尋找用例（參與者達到的目標） 描述用例框架 細化用例描述13系統邊界 系統成分和系統以外事物的分界線 一個系統所包含的所有系統成分與系統以外各種事物的分界線。 確定研究對象。14示例 POS系統 收銀員 支付授權服務 支付授權服務在邊界內還是邊界外？ 界面對象在邊界內與邊界外對構造系統有何影響？POS系統系統15參與者 在系統邊界以外，與系統進行交互的事物。人員、設備、外系統。16找出參與者 為何從參與者入手? 誰來使用系統，他們的目標是什么？ 考慮如下問題： 系統有哪些用

8、戶? 有誰想從系統中獲取信息? 誰負責向系統提供信息? 系統將會在哪些部門使用? 是誰負責管理理和維護系統? 時間是參與者嗎？系統要響應時間事件嗎？ 有沒有其他的系統會和該系統發生交互?17識別參與者（1） 用戶從直接使用系統的人員中發現參與者。這里強調的是直接使用，而不是間接的。 特定的人，在系統中可扮演不同的角色。 例如，添加數據、使用數據及產生報告的那個人就扮演了三種不同的角色，反映為三種不同的參與者。 18識別參與者（2） 外部系統 所有與系統交互的外部應用系統都是參與者。從系統邊界的角度，應該把與軟件系統運行在同一平臺上的應用系統看作是外部的應用。相對于當前在正在開發的系統而言，外部

9、應用系統可以是其他子系統、上級系統或任何與它進行協作的系統，但對它的開發并不是當前系統的開發小組的責任。19識別參與者（3） 設備 識別所有與系統交互的設備。 這樣的設備與系統相連，向系統提供外界信息，或在系統的控制下運行。通常，不包括監視器、鍵盤、鼠標和其它的標準的用戶接口類型設備，但考慮外部傳感器（輸入信息）和受控馬達（輸出信息）。 外部事件 當構造實時和異步交互的系統時，將外部事件識別為潛在的參與者就變得更加重要了。 例如，由時間的流逝而激發系統的活動是常見的情況。可以把時間事件作為一個參與者，也可以把時間事件作為系統的一部分，還可以把二者結合起來使用。20對于參與者的描述21例：設計A

10、TM機器 判斷下列那些是ATM系統的參與者：客戶銀行卡ATM機器面板收據打印機銀行的主系統賬戶信息數據庫 22Pos系統的處理銷售用例Goal: Process salesCashierCustomerPOS SystemCheckout ServiceGoal: Buy itemsEnterprise Selling ThingsSales TaxAgencyGoal: Collect taxes on salesSales ActivitySystemGoal: Analyze sales and performance data23根據邊界識別參與者24尋找用例25考慮 每一個參與者想達

11、到的目標是什么? 為什么該參與者需要使用該系統? 該參與者會在系統中創建、修改、刪除或訪問任何數據嗎? 當外部有事件發生的時候，該參與者需要通知系統嗎? 當系統內部有某些事件發生時，需要通知該參與者嗎? 已定義的系統功能是否足以滿足所有的業務需求?26利用參與者捕獲用例 對所有的參與者（把自己作為參與者），提問下列問題：每個參與者的主要任務是什么？為了達到某種目的，它們參加什么活動？該參與者是否將讀、寫或修改系統的任何信息？參與者是否該把系統外部的變化通知系統？參與者是否希望系統把預料之外的變化通知自己？在交互過程中，它們是怎樣使用系統的服務來完成它們的任務以達到目的？ 它們參加了什么在本質上

12、是不同的過程？ 是什么事件引起了與系統進行交互的序列？ 能完成特定功能的每一項活動明確地是一個用例。這些參與者參與的活動，通常會導致其它用例。27從系統功能角度捕獲用例 一些簡單的指導如下：一個用例描述一項功能，這項功能不能過大。 例如，把一個企業信息管理系統粗略第分為生產管理、供銷管理、財務管理和人事管理等幾大方面的功能，就顯得粒度太大了，應該再進行細化。全面地認識和定義每一個用例，要點是以窮舉的方式考慮每一個參與者與系統的交互情況，看看每個參與者要求系統提供什么功能，以及參與者的每一項輸入信息將要求系統作出什么反映，進行什么處理；另外，要以窮舉的方式，檢查用戶對系統的功能需求，是否能在各個

13、用例中體現出來。 28從系統功能角度捕獲用例(2)以窮舉的方式檢查用戶對系統的功能需求是否能在各個用例中體現出來。一個用例應該是一個完整的任務，通常應該在一個相對短的時間段內完成。如果一個用例的各部分被分配在不同的時間段，尤其被不同的參與者執行，最好還是將各部分作為單獨的用例對待。29捕獲用例的策略1. 首先寫下兩個或三個最常見的簡單場景（用例）。2. 當有兩個或三個場景看上去很相似的時候，就試著產生更“抽象”的場景（用例）。 3. 應謹慎選擇用于不常見事件的附加的用例，并保持在可管理的數量上。 4. 以增量的方式進行分析。 首先開發主要的、高層的用況模型。 然后使用該模型開發主要的、本質的用

14、況模型。 進一步地，使用所得到的模型指導開發次要的、本質的用況。 最后，使用該模型開發次要的、具體的用況。 30POS系統用例圖31應避免的誤解 應該避免這樣一種誤解認為由參與者和用例構成的用例圖就是用例模型， 用例圖只是在總體上大致描述了系統所能提供的各種服務，對于系統的功能有一個總體的認識。 除此之外，還需要描述每一個有例的詳細信息，這些信息包含在用例規約中。 用例模型是由用例圖和每一個用例的詳細描述用例規約所組成的 32描述用例描述用例 對用例的功能描述，可采用自然語言，也可以采用用戶定義的語言。 大多數用例是簡單的；只是一個操作的邏輯序列，該序列具有一個來自外界的出發操作。 有一些用例

15、要復雜一些，具有多個例外的情況（例如出錯）或不同的交互路徑（可進行分支）。33細化用例描述 為什么細化用例描述? 描述軟件需求 為后續的開發準備一個系統功能描述 在事件流中描述更為詳細的信息 參與者做了什么動作 系統是如何響應的 系統和參與者之間交換了哪些信息 描述用例場景 成功場景 失敗場景 描述額外的用例信息 前置條件 后置條件34用例文本表示法 用例編寫沒有固定格式，根據個人需要編寫，關鍵是詳細編寫主流程及備選流程 單欄分格 雙欄格式（分離參與者與系統的處理步驟） 不需要描述界面信息 編寫黑盒用例，不對系統內部工作、構件或設計進行描述35Pos系統處理銷售用例 用例命名，一般是動詞+名詞

16、結構 各小節含義 范圍 用例描述的是對一個系統的使用，為系統用例 說明所要設計的系統 級別 用例的級別，依據用例服務的對象分為用戶目標級別和子功能級別 主要參與者 調用此用例提供的服務完成目標的主要參與者36 涉眾及其關注點 此用例參與的對象關注點所在，建議了系統必須要做的事情 前置條件和成功保證 前置條件：假設條件，滿足假設后用例才可能執行，應編寫引起分析員警惕，值得注意的前提條件。 后置條件（成功保證）：用例成功后必須滿足的事情。保證滿足所有涉眾的需求 主流程 滿足涉眾關注點的典型成功路徑。不包含任何條件和分支37 備選流程 描述除其他場景和分支，包括成功和失敗路徑。 替代流是主流程的分支

17、，需要對對應步驟進行標識 默認情況下，替代流程執行完后重新匯入主流程 執行其他用例 用例產生分支執行其他用例 特殊需求 與用例相關的非功能性需求、質量屬性和約束 技術和數據變化可能 以后可能會發生的技術或數據上的變化可能 如：輸入或輸出技術的約束38描述用例的另一種框架39事件流 流：是指一系列的步驟 一個基本流 最順利的場景 從開始到結束一切都順利的場景 很多個備選流 除基本流之外的另外一些正常場景 偶爾發生的場景 異常或錯誤處理40描述用例框架 基本流 是什么事件啟動了用例? 用例是如何結束的? 用例中最常用到的行為是什么? 備選流 在用例中有無可選執行的情況? 那些行為是偶爾才發生的?

18、是否有沒有包含在基本流中的正常情況? 發生錯誤的情況下該如何處理?41表示基本流和備選流編寫用例準則 以無用戶界面約束的風格編寫用例 摒除界面細節描述 編寫簡潔的用例 編寫黑盒用例 不對系統內部工作、構件或設計進行描述 采用參與者和參與者目標的視點 強調提供可觀察的用戶價值并關注用戶的典型目標42示例：Monopoly游戲 以軟件模擬方式運行，展示游戲。4344示例：ATM自動取款機用例圖45例：ATM驗證客戶身份驗證客戶身份用例規約：驗證客戶身份用例規約：驗證客戶身份簡要說明簡要說明該用例描述ATM機是如何驗證客戶身份的。事件流事件流客戶使用ATM機提供的各項服務之前，必須先通過該用例來進行

19、用戶身份驗證。基本流（主成功場景）基本流（主成功場景）1.客戶將信用卡插入系統2.系統讀取信用卡上的客戶帳號信息，并向后臺服務器系統確認該信用卡的有效性3.系統提示客戶輸入信用卡密碼4.客戶輸入6位密碼，系統向后臺服務器檢查用戶密碼是否正確5.客戶通過身份驗證后，系統顯示操作主菜單供客戶選擇查詢、提款、轉帳服務6.客戶選擇他所需要的服務。46備選流備選流2a. 無效信用卡：無效信用卡：在基本流步驟1中，客戶插入的信用卡在后臺服務器中沒有對應的帳號 系統顯示錯誤信息并退出信用卡，用例結束。4a. 密碼不正確：密碼不正確：客戶輸入錯誤的信用卡密碼1.系統提示客戶重新輸入密碼2.客戶重新輸入密碼后繼

20、續基本流中的下一個步驟；如客戶輸入密碼錯誤超過次，系統沒收客戶插入的信用卡，用例結束。*a. 退出退出:在基本流的任何一個步驟中，客戶都可以選擇“取消(Cancel)”退出，系統退出信用卡，用例結束。47 用例場景用例場景 成功場景成功場景 通過客戶身份驗證通過客戶身份驗證：基本流 取消客戶身分驗證取消客戶身分驗證：基本流，退出 失敗場景失敗場景 無效信用卡無效信用卡：基本流，無效信用卡 重新輸入客戶密碼重新輸入客戶密碼：基本流，客戶密碼不正確 沒收客戶信用卡沒收客戶信用卡：基本流，客戶密碼不正確（密碼輸錯3次以上） 特殊需求特殊需求 驗證信用卡和客戶密碼操作必須在秒鐘內完成。 前置條件前置條

21、件 ATM機系統必須已經啟動，并且跟后臺服務器建立連接。 后置條件后置條件 無 擴展點擴展點 無48練習：描述轉賬用例文本 請參照上“驗證客戶身份”用例文本，試著描述轉賬用例文本。49偽代碼描述方式用例名用例名： “收銀”（收銀員）用例實現過程用例實現過程：收銀員輸入開始本次收款的命令；*作好收款準備，就收款總數置為0，輸出提示信息；For 顧客選購的每種商品 do收銀員輸入商品編號；If 此種商品多于一件 then 輸入商品數量End if；*檢索商品名稱及單價*并把貨架商品數減去集出數；If 貨架商品數低于下限 then *通知供貨員請求上貨 End if；*計算本種商品總價并打印編號、名稱、數量、單價、總價*總價累加到應收款總數End for；*打印應收款總額；輸入顧客交來的款數；*計算應找回的款數；*打印以上兩個數目*收款數計入賬冊50簡易圖書館要求陳述 學院圖書館需要一個新的圖書管理系統管理圖書資源。主要是圖書資源的管理。圖書由圖書館顧客借出、還入和預定。圖書也可能處于特殊的狀態，如被預留或僅作為參考書。在這種情況下，圖書不能被借出