UML 需求分析入門

UML，Unified Modeling Language，統一建模語言。

上週五，大管家@fenbox 給咱們講解分析產品需求的一套方法：UML

---

用例圖（Use Case Diagram）：對象角度描述業務

主要用來描述「用戶、需求、系統功能單元」之間的關係。它展現了一個外部用戶可以觀察到的系統功能模型圖。幫助開發團隊以一種可視化的方式理解系統的功能需求。

用例圖所包含的元素以下：
參與者(Actor)：表示與您的應用程序或系統進行交互的用戶、組織或外部系統。用一個小人表示。
用例(Use Case)：用例就是外部可見的系統功能，對系統提供的服務進行描述。用橢圓表示。
關係：包含、擴展、泛化。

一種參與者對應一個用例：


包含關係(Include)：參與者 ---> 執行的動做/功能 - -> 可能繼續細化的動做/功能

包含關係用來把一個較複雜用例所表示的動做/功能分解成較小的步驟（父用例 -> 子用例）。

擴展關係(Extend)：參與者 ---> 執行的動做/ 功能<- - 可能觸發的動做/功能

擴展關係是指用例功能的延伸，至關於爲基礎用例提供一個附加功能。

泛化關係（Inheritance）：就是一般理解的繼承關係，子用例和父用例類似，但表現出更特別的行爲；子用例將繼承父用例的全部結構、行爲和關係。子用例可使用父用例的一段行爲，也能夠重載它。父用例一般是抽象的。

還能夠有的關係：註釋(Comment)、依賴(Dependency)，基本原理類似。

一個用例圖示例：

建模階段：能描述⼀個完整的業務流程便可（如：裝寬帶）；
分析階段：能描述⼀個完整的事件流程便可（如：業務申請、業務受理、現場安裝）；

用例描述表：保證全部⽤例在⼀個層級，當⽤列圖並不能清楚地表達功能需求，一般⽤描述⽂檔來補充某些不易表達的⽤例，下圖的表給你們提供一個參考：

資料參考：UML用例圖總結

---

時序圖（Sequence Diagram）：從計算機角度描述用例

時序圖（Sequence Diagram）是經過描述對象之間發送消息的時間順序顯示多個對象之間的動態協做。它能夠表示用例的行爲順序，當執行一個用例行爲時，時序圖中的每條消息對應了一個類操做或狀態機中引發轉換的觸發事件。

它是顯示對象之間交互的圖，這些對象是按時間順序排列的。順序圖中顯示的是參與交互的對象及其對象之間消息交互的順序。時序圖中包括的建模元素主要有：

1. 對象（Actor）：可選地顯示對象名和類名。
2. 生命線（Lifeline）：生命線在順序圖中表示爲從對象圖標向下延伸的一條虛線，表示對象存在的時間。
3. 控制焦點（Focus of control）：控制焦點是順序圖中表示時間段的符號，在這個時間段內對象將執行相應的操做。用小矩形表示。
4. 消息（Message）：消息通常分爲同步消息（Synchronous Message），異步消息（Asynchronous Message）和返回消息（Return Message）。

• 同步消息=調用消息（Synchronous Message）：消息的發送者把控制傳遞給消息的接收者，而後中止活動，等待消息的接收者放棄或者返回控制。用來表示同步的意義。
• 異步消息（Asynchronous Message）：消息發送者經過消息把信號傳遞給消息的接收者，而後繼續本身的活動，不等待接受者返回消息或者控制。異步消息的接收者和發送者是併發工做的。
• 返回消息（Return Message）：返回消息表示從過程調用返回

資料參考：UML建模之時序圖（Sequence Diagram）

---

大管家還說了兩種圖：狀態圖、活動圖，基本原理和流程圖類似，略過不表；

---

類圖：描述結構化設計

類圖（Class Diagram）: 類圖是面向對象系統建模中最經常使用和最重要的圖，是定義其它圖的基礎。類圖主要是用來顯示系統中的類、接口以及它們之間的靜態結構和關係的一種靜態模型。

在畫類圖的時候，理清類和類之間的關係是重點。

類圖的3個基本組件：類名、屬性、方法。

資料參考：UML類圖與類的關係詳解

---

UML的認識誤區

誤區一：認爲UML主要用於軟件設計。

UML除了用於軟件設計，還能用於需求分析，如何在需求分析工做中活用UML的。

誤區二：客戶沒法理解UML，在需求分析中應用UML實際意義不大。

不熟悉UML時，確實也有這樣的懷疑，而實際工做中發現UML偏偏成爲與客戶溝通的良好橋樑!UML其實不難讀懂，只要稍加解釋客戶立刻就能讀懂
UML能直觀、形象、嚴謹地描述出業務概念、業務流程、客戶的指望和需求，只要稍加引導客戶，客戶將會很容易讀懂UML

誤區三：認爲UML語法繁雜，難以學習和應用。

誤區四：UML用途不大。

有人推崇UML，但也有很多人士不太承認UML。不承認的緣由主要是由於一些人士學習UML後，發如今實際工做中發揮的做用並非很大，有時候不用UML效果更好。UML不能解決全部問題，但對於提高需求分析能力幫助仍是很大的。UML的經常使用語法可能幾天就能學會了，⽽要真正作到「thinking in UML」卻沒有這麼容易，須要長期的鍛鍊。

---

大管家最後推薦了兩個 Mac OS 可用的 UML 建模的軟件：Gliffy Diagrams（一個 Chrome 擴展程序），OmniGraffle。

---

本文基於@fenbox的分享《UML需求分析入門》，圖片大部分來自配套的 slides，少部分來自參考資料。