- 商業分析教程
- 商業分析 - 首頁
- 商業分析 - 簡介
- 軟體開發生命週期
- 商業分析 - 角色
- 工具和技術
- 商業分析 - JAD 會議
- 需求收集技術
- 功能需求文件
- 軟體需求規格說明書
- 商業分析 - 用例
- 用例圖
- 需求管理
- 規劃良好的需求
- 商業分析 - 建模
- 商業分析有用資源
- 商業分析 - 快速指南
- 商業分析 - 有用資源
- 商業分析 - 討論
用例圖
統一建模語言 (UML) 的一個重要部分是繪製用例圖的功能。用例在專案的分析階段用於識別和劃分系統功能。它們將系統劃分為參與者和用例。參與者代表系統使用者可以扮演的角色。
這些使用者可以是人類、其他計算機、硬體部件,甚至是其他軟體系統。唯一的標準是它們必須位於被劃分為用例的系統部分之外。它們必須向系統的那一部分提供刺激,並且必須接收來自它的輸出。
用例代表參與者在追求目標的過程中藉助您的系統執行的活動。我們需要定義這些使用者(參與者)需要系統提供什麼。用例應反映使用者需求和目標,並應由參與者啟動。參與業務用例的業務、參與者、客戶應透過關聯連線到用例。
繪製用例圖
下圖顯示了用例在 UML 圖示形式中的外觀。用例本身看起來像一個橢圓形。參與者被繪製成小小的簡筆人物。參與者用線連線到用例。
用例 1 − 銷售員結賬
- 顧客將商品放在櫃檯上。
- «uses» 掃描 UPC 閱讀器。
- 系統在資料庫中查詢 UPC 程式碼,獲取商品描述和價格
- 系統發出蜂鳴聲。
- 系統透過語音輸出宣佈商品描述和價格。
- 系統將價格和商品型別新增到當前發票。
- 系統將價格新增到正確的稅款小計。
因此,「uses」關係非常類似於函式呼叫或子程式。
以這種方式使用的用例稱為抽象用例,因為它不能獨立存在,而必須由其他用例使用。
示例 ─ 取款用例
客戶與我們的自動取款機 (ATM) 相關的目標是取款。因此,我們添加了取款用例。從自動取款機取款可能涉及銀行進行交易。因此,我們還添加了另一個參與者 – 銀行。參與用例的兩個參與者都應透過關聯連線到用例。
自動取款機為客戶和銀行參與者提供取款用例。
參與者和用例之間的關係
用例可以使用以下關係進行組織:
- 泛化
- 關聯
- 擴充套件
- 包含
用例之間的泛化
在某些情況下,參與者可能與類似的用例相關聯。在這種情況下,子用例繼承父用例的屬性和行為。因此,我們需要泛化參與者以顯示函式的繼承。它們由帶有大型空心三角形箭頭頭的實線表示。
用例之間的關聯
參與者和用例之間的關聯在用例圖中由實線表示。只要參與者參與用例描述的互動,就存在關聯。
擴充套件
有些功能是可選觸發的。在這種情況下,使用擴充套件關係,並將擴充套件規則附加到它。需要注意的是,即使未呼叫擴充套件用例,基本用例也應該能夠自行執行功能。
擴充套件關係顯示為一條虛線,帶有從擴充套件用例指向擴充套件(基本)用例的開放箭頭。箭頭用關鍵字 «extend» 標記。
包含
它用於提取在多個用例中重複的用例片段。它還用於透過將大型用例拆分為多個用例以及提取兩個或多個用例行為的公共部分來簡化大型用例。
用例之間的包含關係,由一條從基本用例指向包含用例的帶有開放箭頭頭的虛線表示。箭頭用關鍵字 «include» 標記。
用例僅處理系統的功能需求。其他需求,例如業務規則、服務質量需求和實現約束,必須單獨表示。
下圖顯示了一個帶有所有標記元素的簡單用例圖示例。
用例成功應用的基本原則
- 透過講述故事來簡化它
- 無需完美即可高效
- 瞭解全域性
- 識別用例的重用機會
- 關注價值
- 分片構建系統
- 增量交付系統
- 適應以滿足團隊的需求
用例模板
在這裡,我們展示了一個用例的示例模板,業務分析師可以填寫該模板,以便技術團隊可以利用這些資訊來確定專案資訊。
| 用例 ID | |||
| 用例名稱 | |||
| 建立者 | 最後更新者 | ||
| 建立日期 | 最後更新日期 | ||
| 參與者 | |||
| 描述 | |||
| 前提條件 | |||
| 後置條件 | |||
| 優先順序 | |||
| 使用頻率 | |||
| 正常流程 | |||
| 備選流程 | |||
| 異常 | |||
| 包含 | |||
| 特殊要求 | |||
| 假設 | |||
| 備註和問題 | |||