主要UML模型圖繪製技巧
— 筆記整理自 北京理工大學 計算機學院
用例圖與用例分析
- 用例分析技術是Ivar Jacobson於1986年總結髮布的一項源於實踐的需求分析技術
- 用例圖對系統、子系統或類與外部參與者的交互行爲進行了可視化
- 爲軟件需求規格化提供了一個可驗證可度量的基本元素
- 是項目計劃、進度控制、測試等環節的基礎
- 用例圖可以使開發團隊與客戶之間的交流更加順暢
- 用例分析技術的核心是用例描述而不是用例
用例圖元素
- 參與者(actor):代表系統用戶，驅動系統運轉
- 系統邊界(system scope):確定系統的範圍
- 用例(use case):代表系統提供的服務
- 關係(association):關聯、包含，擴展與泛化
備註：圖片託管於github，請確保網絡的可訪問性
用例描述
- 前置條件:指在用例啓動時，參與者與系統應置於什麼狀態，這個狀態應該是系統能夠檢測到的、可觀測的
- 後置條件:用例結束時，系統應置於什麼狀態，這個狀態也應該是系統能夠檢測得到的、可觀測的
- 基本事件流:基本事件流是對用例中常規、預期路徑的描述，也被稱爲Happy day場景，即大部分時間所遇到的場景;它將體現系統的核心價值
- 擴展事件流:主要是對一些 異常情況和選擇分支的描述
UML用例
- 用例是用戶與計算機之間爲達到某個目的的典型交互
- 用例的執行結果對參與者來說是可觀測的和有意義的
- 用例必須由一個參與者發起
- 用例應以動賓短語形式命名
- 用例是指對系統提供的功能的描述
- 用例對應一個層次性用戶目標
- 概要級
- 目標級
- 子功能級
如何獲取參與者
- 誰使用系統的主要功能(主要使用者)?
- 誰需要系統支持他們的日常工作?
- 誰來維護、管理系統使其能正常工作(輔助使用者)?
- 系統需要控制哪些硬件?
- 系統需要與其他哪些系統交互?
- 對系統產生的結果感興趣的是哪些人?
如何獲取用例
- 參與者要求系統提供哪些功能?
- 參與者需要讀、產生、刪除、修改或存儲系統中的信息有哪些類型?
- 必須提醒參與者的系統事件有哪些?
- 參與者必須提醒系統事件有哪些?
- 怎樣把這些事件表示成用例中的功能?
編寫用例時的建議
- 使用簡單的語法，主語明確，語義易於理解
- 明確寫出"誰控制球":在事件流描述中，讓讀者直觀地瞭解是參與者在控制還是系統在控制
- 從俯視角度編寫，即從第三者的角度:指出參與者的動作，以及系統的響應，顯示過程
- 向前推移:每一步都有前進的感覺
- 顯示參與者的意圖而非動作
學習用例分析技術
- 學習用例分析技術的"守、破、離"的三個階段:
- 守:練習基本功夫，遵循規則，照章行事
- 破:能突破傳統，因地制宜地靈活應用
- 離:超脫任何招式與規則，達到無招勝有招的境界
- 把捕獲的需求整理爲易理解的用例圖(圖形化)
- 識別參與者
- 識別用例
- 構建用例圖
- 補充用例描述(詳細完整的描述需求)
- 重構用例(識別用例間關係，組織用例)
擴展
設計模式作爲一種傳承下來的面向對象設計經驗，一直得到程序員們的喜愛。是否掌握Gof23種設計模式甚至一度作爲衡量程序員水平的標誌之一。
然而，To A Man with a Hammer, Everything Looks Like a Nail.
於是，有人在"Hello world”程序中使用了4種設計模式。還有人想在一個程序中用盡 23 個 GoF 設計模式，據說失敗了，因爲他們只能使用 20 個。所以他們希望客戶能讓他們接着寫程序，也許能再擠進去另外 3 個。
他們是怎麼了？中毒了麼？跟着下面的鏈接去看看到底是怎麼回事。但是，請不要失去對提高自己面向對象分析設計能力的信心。