66056學習目標-資料下載頁
2024-09-30 09:46本頁面
【導讀】使用用例模型捕獲系統(tǒng)需求。詳細地描述系統(tǒng)和客戶以及系統(tǒng)和外部系統(tǒng)之間的交互。重構這個詳細描述以保證它是可讀且易懂的。用例模型用于需求分析階段。它將系統(tǒng)看作黑盒，從參與執(zhí)行者的角度來理解系統(tǒng)。它驅動了需求分析之后各階段的開發(fā)工作，不僅在開發(fā)過。一個用例是由一名普通用戶的目標聯系在。用例必須是集中的，并有一個明確的目標。用例代表系統(tǒng)的一種外觀，和系統(tǒng)內部的。用例由參與者激活，并提供確切的值給參與。用例可大可小，但它必須是對一個具體的用。硬件設備或某段時間的流逝。其圖形化的表示是一個小人。主要或協(xié)助參與者。因為系統(tǒng)要響應時間事件而完成某些活動。例如，管理用戶用例可以同時滿足”編輯用戶“、”子參與者繼承父參與者的角色，及父參與者與用例
【正文】 P即基本業(yè)務過程（ Elementary Business Process），是源于業(yè)務過程工程領域的術語。 定義：一個人于某個時刻在一個地點所執(zhí)行的任務，以響應業(yè)務事件。該任務能夠增加可量化的業(yè)務價值，并且以持久狀態(tài)留下數據，例如，批準信用卡的信用額度或者確定訂購的價格。 用例不是單獨的一小步，例如”刪除一條商品項目“或者”打印文檔“。相反，主成功場景應該是 510個步驟。用例不能持續(xù)數日或多個會話過程，例如”就供應者合同進行談判“。用例是在一個會話過程中完成的任務。用例可能只需幾分鐘或一個小時就能完成。 如何發(fā)現有效用例 ? 規(guī)模測試 用例很少由單獨的活動或步驟組成，相反，用例通常包含多個步驟。用例建模中的一個常見錯誤就是僅講一系列相關步驟中的一個步驟定義為用例。 例如將輸入商品 ID定義為用例。如果你以詳述形式想象一下，你會發(fā)現該用例出奇的短。 如何發(fā)現有效用例 ? 測試的合理違例 盡管應用中主要用例的定義和分析可以滿足上述測試，但是常常會出現例外。 有時，需要為子任務或常規(guī) EBP級別用例中的步驟編寫單獨的子功能級別用例。例如，諸如”信用卡支付“等子任務或擴展可能在多個基本用例中出現。 認證用戶這一用例可能無法通過老板測試，但是其步驟極為復雜，需要引起重視進行細致的分析，例如需要考慮”單點登錄“特性。 編寫用例準則 ? 以無用戶界面約束的本質風格編寫用例 ? 編寫簡潔的用例 ? 編寫黑盒用例 ? 采用參與者和參與者目標的觀點 以無用戶界面約束的本質風格編寫用例 ? 新式和改良！適于指紋的情形 在需求獲取時，收銀員可能會說其目標之一表述為”登錄“。此時收銀員大概會想象有圖形界面，對話框，用戶 ID和口令。這是實現目標的一種機制，但不是目標本身。通過分析，可以反響與實現機制無關的目標：“表示自己的身份并得到認證”，或是更高層的目標：“防盜 ……”。 這種對根源目標的發(fā)現過程能夠拓展視野，以促成新的和改進的解決方案。但可能還要進行一些可用性分析工作。 準則：編寫黑盒用例 黑盒用例（ blackbox use case）是最常用和推薦使用的類型，它不對系統(tǒng)內部工作，構作或設計進行描述。反之，它以通過 職責 來描述系統(tǒng)，這是面向對象思想中普遍統(tǒng)一的隱喻主題 軟件元素具有職責，并且與其他具有職責的元素進行協(xié)作。 通過使用黑盒用例定義系統(tǒng)職責，人們可以規(guī)定系統(tǒng)必須做什么，而不必決定系統(tǒng)如何去做（設計）。實際上，“分析”與“設計”的區(qū)別就在于“ 什么 ”和“ 如何 ”的差異。 黑盒風格 非黑盒風格 系統(tǒng)記錄銷售 系統(tǒng)將銷售信息寫入數據庫。 …… 或者（更糟的描述）：系統(tǒng)對銷售信息生成 SQL INSERT語句 …… 準則：采用參與者和參與者目標的視點 以下是 RUP的用例定義： 一組用例實例，每個實例是系統(tǒng)所執(zhí)行的一系列活動，以此產生對特定參與者具有價值的可觀察結果。 短語”對特定參與者具有價值的可觀察結果“是細微而又重要的概念，它強調了需求分析的兩個態(tài)度： 1. 關注系統(tǒng)的用戶或參與者來編寫需求，詢問其目標和典型情況。 2. 關注理解參與者所考慮的有價值結果。 用例和需求模型的關系 用例 條形褲 用例 條形褲（子用例）
教學課件相關推薦
鄂ICP備17016276號-1