產品經理必看:常用的UML建模詳解
關于UML,我相信在做B端的產品經理一定知道它的重要性。那么UML常用的圖都包含哪些呢?它們都在什么場景什么階段使用?如何使用?這篇文章主要幫助小伙伴們解答這些問題。
一、UML的分類及用途
首先簡單給大家介紹一下什么是UML,UML的全稱是Unified Modeling Language。翻譯過來就是統一建模語言。它對產品經理最主要的作用是用于需求分析中更好的梳理邏輯,同時能夠提升溝通效率。
UML主要包括圖表中的十一種,那在本次的介紹中,只講解類圖、構件圖、部署圖、活動圖、狀態機圖、順序圖、用例圖。
通常對業務概念等靜態結構進行系統化的梳理和提煉,我們叫它結構建模。而于對業務流程等動態內容進行系統化的梳理和提煉,我們叫它行為建模。
而需求分析的核心目的是解決軟件有沒有用的問題,軟件設計是解決軟件用多大的成本做出來的問題,所以需求分析首要任務是保證軟件的價值。
那么如何學好UML呢?其實UML的語法很簡單,但是想要學好UML關鍵在于要改變思維習慣。要在平時多培養自己的書面表達能力、歸納總結能力、思維能力和抽象能力。
二、類圖
裝逼的講,類圖(Class diagram)是顯示了模型的靜態結構,特別是模型中存在的類、類的內部結構以及它們與其他類的關系等。那它其實就是用來幫助我們識別出人、事、物和業務的概念,并理清它們的關系的一種方法。
2.1 類圖的基礎知識
在聊類圖之前先讓我們理清幾個概念。
首先,什么是類?將某類東西歸納在一起就可以成為一個類。
例如,本文的讀者,我們就可以分為初級產品經理,高級產品經理;或者分為產品經理和非產品經理;這些都可以叫做類。
然后,什么是類圖?類圖就是一個矩形的方框,上面是類的名字,中間是屬性,下面是操作。
比如這篇文章的讀者是產品經理,那產品經理的屬性就有性別,年齡,級別等;如果要列舉當然會有很多屬性,但是我們只找出相關且對我們有用的屬性。
那一般如何用類圖獲取需求呢?首先要識別出類。其次識別出類的主要屬性。然后描述出類之間的關系,最后在對各類進行分析、抽象、整理。
2.2 類之間的關系
(1)直線關系
直線關系其實就是我們常說的關聯關系,A關聯B,如下圖:
那如果在直線兩端加上數字1,那就是1對1的關系,如下圖:
同樣,如果將B旁邊的1改成*,那就是1對多的關系,如下圖:
那如果將*改成0..3,那就是0到3的意思。如果是1..4那就是1到4的意思。下入就是1對0..3的意思:
如果把數字換成了上司和下屬,那么他們就是角色關系了,就代表a是b的上級,b是a的下屬。如下圖:
如果把數字換成箭頭,那就變成了導航關系,即由A可找到B,如下圖:
(2)包含關系
包含關系有兩種表示方法,一種是空心菱形,一種是實心菱形;空心菱形可以表示為弱包含的關系,實心菱形可以表示為強包含的關系。
弱包含關系即部門沒有了,員工可以繼續存在。強包含關系是部門沒有了,員工也就不存在了。
以下圖中表示的為,一個部門可以包含多個員工:
(3)繼承關系
繼承關系是誰繼承了誰的屬性。例如香蕉,蘋果,葡萄他們繼承了水果的屬性,同時又擁有自己的屬性。
我們用一個三角來表示,如下圖:
(4)依賴關系
所謂的依賴關系,依賴程度是相對而言的,不一定是A沒有B就不能生存了。
在實際的業務邏輯當中,對于某個事情,A需要B來協助完成,也是一種依賴關系,依賴關系使用虛線箭頭表示。
2.3 類圖的進階
(1)遞歸關系
我們常用的電腦系統中,如果用類圖表示出文件夾與文件的關系,那么該如何表達呢?是文件夾包含文件嗎?那文件夾和文件夾的關系呢?
使用遞歸關系,我們就可以更好的表達出來。
遞歸關系分為自包含和自關聯,和字面的解釋一樣,就是自己包含自己,自己關聯自己。
下圖分別是自包含和自關聯:
(2)三角關系
當某些屬性值并不是由該類本身就可以確定的時候,我們可以使用三角關系;
例如員工的薪資,職位等,并不是由公司可以確定的,而是由勞動合同來確定的,那么我們的表達方式如下:
三、活動圖
活動圖是用來表達流程最常用的一種UML圖,它和流程圖很類似。
3.1 基本語法
(1)基礎流程圖
流程中一般只有一個開始,會有一個或多個結束。箭頭表示流程的走向,一個圓角矩形表示一個活動,活動可以理解為流程中的一個步驟,需要用主動賓的形式來表達。
例如員工填寫工時,項目經理審批工時。菱形代表判斷,會有兩個或兩個以上的分支。
判斷一般有三種表達方式:在判斷菱形旁寫下判斷的句子;直接通過監護來表示這個判斷;在菱形判斷之前加一個活動來表明判斷動作。
分支流程匯合時,也會使用菱形,然后會合并成一條路線。如下圖:
(2)泳道圖
上面的流程圖當中,如果流程簡單,那么就可以很好的表達,如果流程很長,涉及到的角色很多,且很復雜時,看到就會非常亂,不止畫的人覺著亂,看的人也會感覺很亂。
那么,這個時候我們就可以用泳道圖。
泳道圖一般是會按照角色進行分區,那么在畫和瀏覽時都非常清晰。如下圖:
3.2 活動圖的進階
(1)并行的活動
當遇到需要并行的活動或分支時,我們可以使用粗短棒。
短粗棒會有兩個同時出現:第一個是有一個箭頭指入,多條箭頭指出,這個叫做分叉;第二個是多條箭頭指入,一條箭頭指出,這個叫匯合。如下圖:
(2)對象流
當我們用矩形框來表示某個節點,并將矩形框的文字標注下劃線,那它就代表對象。
每個活動都有可能有一個或多個輸入或輸出,與輸入輸出直接相連的箭頭叫對象流,而活動和活動之間相連的叫控制流。
如圖:
(3)連接件
有的時候活動圖很大,一張紙畫不下,我們可以使用另一張紙繼續畫,這個時候,我們可以使用連接件(其實現在的畫圖軟件大多都不會出現這種情況)。
如下圖,左邊的圖是箭頭指向A,則是活動圖到這里轉向另一張圖;右邊的圖是A指出一個箭頭,表示從A開始繼續這個活動圖:
3.3 關于活動圖的其他問題
對于活動圖的粒度是如何控制的呢?其實這個是沒有標準答案的,下面只是一些實踐建議。
- 首先要清楚活動圖要表達什么內容,表達的重點是什么,以此來確定合適的粒度;
- 其次,可以先用粒度比較大的活動圖,大致搞清楚流程的總體情況;
- 最后在逐步細化,需要重點說明的部分,活動的粒度應該足夠細,足夠說明問題。
那如何畫好活動圖呢?
- 建議你一個活動圖只表達一個事情,同時在畫之前要明確該流程要達到怎樣的業務目的、有什么角色參與、哪些是主要角色;
- 先畫出主流程,明確主流程中涉及到的角色,然后在逐步增加分支流程,這里主要表達出關鍵的分支即可;
- 同時異常流程也不用全部表達出來,必要的時候,可以用文字來說明;控制好粒度,然后分別畫出當前的流程和優化后的流程。
- 對照差異,整理出需要調整的地方。
四、狀態機圖
狀態機圖其實和大家常說的狀態圖是一個東西,只是它的專業名稱叫做狀態機圖。
4.1 基本語法
狀態機圖的開始狀態和結束狀態與活動圖的一致,活動機圖用一個圓角矩形來代表一個狀態。
與活動圖不同,活動圖是用圓角矩形代表一個活動,而且狀態機圖一般使用名詞或形容詞來表示某種狀態。
如下圖:
4.2 其他問題
關于狀態數量的問題:在使用狀態機圖時,若流程不合理,可以考慮通過增加、減少、修改狀態來完善。
增加一個新的狀態會解決很多問題,但是也會增加流程的復雜度,可能會出現其他問題。
關于狀態圖的實踐會有一些建議可供大家參考:
- 流程圍繞某一事物開展時,可以考慮使用狀態機圖來分析;同樣也需要弄清楚它的目的,參與的角色,以及這些角色是如何推動流程的發展;并且列出流程中存在的問題;
- 同時要考慮事物在流程不同階段有什么變化,然后列出當前的流程,再根據流程的目的和存在的問題進行調整。
五、順序圖
當流程設計到多種角色,并且通過多個角色交互展開時,順序圖是不二選擇。
5.1 基本語法
角色可以用一個小人的圖標來表示,下面寫明角色。也可以用一個矩形來表示,但是需要在矩形里面說明角色。
生命線是角色下面的那條虛線,激活框也叫會話,是生命線中細長的矩形。
消息用箭頭表示,并在上面說明做了什么事情;箭頭可以從A指向B,也可以指向自己。
返回值用虛線箭頭表示,并在上面說明返回的內容,一般是反饋某個東西給相應的對象。
如下圖:
5.2 順序圖的進階
循環分支屬于業務流程中比較常見的特殊結構。
- loop,也叫循環,是滿足循環條件的前提下,不斷地重復做某些事情;
- alt,條件分支,是根據不同的條件選擇不同的分支;
- opt,可選分支,是滿足一定條件則執行該分支,否則就跳過。
如下圖:
上圖的流程中,loop,中括號內是循環條件的內容,表示如果滿足循環條件,則重復執行本框的內容;alt,如果滿足條件1則執行上半部分,如果滿足條件2則執行下半部分;opt,如果滿足條件,則執行框中的內容,否則跳過。
5.3 其他問題
關于順序圖使用的一些建議:
- 先從復雜的業務中整理出一條一條的流程,然后分析參與的角色,角色擔任的職責和專業特色。
- 然后在將流程分解成角色與角色的交互,想清楚各個角色之間是如何交互的,用順序圖把它組織起來,在這個過程中要不斷的進行優化。
活動圖,狀態機圖和順序圖,被稱為流程分析的三大利器,那么每種圖都有不同的特點和應用場景。
- 順序圖,強調角色之間的交互,強調按時間順序分別發生了什么事情,不太適合表達復雜的特殊流程;
- 活動圖,強調每個角色做了什么事情,這些事情的先后關系,適合表達各種特殊流程,如分支,并發等;
- 狀態圖,主要是事情圍繞某東西開展,并且有不同的狀態。
那么在實際工作中如何選擇呢?
通過上面說明的特點我們可以很清楚的知道。如果事情圍繞某個東西開展,就可以考慮使用狀態機圖。
如果不是,則可以考慮順序圖或活動圖;如果沒有復雜的特殊流程,可以考慮順序圖。如果有負責的特殊流程,則可以考慮活動圖。
當然,在實際工作中,不要被上面的條條框框所限制,有的時候可以有兩種甚至三種圖來表示,可以從多個角度來分析問題,再做適當取舍。
六、用例圖
用例圖對于很多人來說只是給一些角色配置一些權限。其實用例圖是可以幫我們搞清楚這個產品是誰在用,通過這個系統能做什么事情。
6.1 基本語法
小人(actor,執行者),執行者可能是人也可能是系統。如果是人的話,可稱之為角色。如果是系統的話,可以將另外一個系統畫成執行者就可以了。
圈圈(用例,use case)圈圈里面的文字是動詞加名詞,這個就代表了系統能做什么事情。
大框框(系統邊界,system boundary)這個框只框住了用例,沒有框住執行者,這個就叫系統邊界。
線條(關聯,association)線條指用例和角色之間的線條,一般有三種,無箭頭的,指向用例的箭頭,指向執行者的箭頭。同時,一般情況下也會有兩種解釋,一種是數據流向,還有一種是誰啟動誰。
如下圖:
6.2 進階語法
用例的進階語法主要包括繼承、include(包含)、extend(擴展)
(1)include(包含)
包含一般有兩種用法,一種是以樹的方式組織各種用例,用包含來組織好父子用例,子用例可以再次包含自己的子用例,這樣層次分明。
還有一種是某些用例的一部分可以抽離出來成為子用例,該子用例同時也被其他用例包含。
如下圖:
(2)extend(擴展)
擴展的意思就是在某用例的基礎上,還能做什么事情。例如用戶在查看報表的時候,還可以導出報表,打印報表。如下圖:
(3)繼承
繼承與類圖中的繼承性質是一樣的,但是一般在畫用例圖的時候很少用,都會用其他的方式替代,因為不太好理解,而且還會降低溝通效率。如下圖:
6.3 用例圖的其他問題
那么我們日常工作中,如何畫好用例圖呢?
下面是一些在實踐中的建議:
- 首先,在客戶能全面理解的基礎上,越精簡越好;
- 同時用例應該使用客戶的語言,讓客戶能夠看得懂,要全面的表達用例,對于重點的地方要詳細描述,非重點的地方不要過多描述;
- 通過使用擴展和包含來細化用例圖,但要靈活把握,用例圖只是一種表達方式,必要時可以結合其他方式來表達。
七、部署圖、構件圖
部署圖和構件圖一般用來獲取和描述非功能需求。非功能性需求,一般包括兩個方面,一方面的軟件技術的架構要求。另一方面是安全性、易用性、性能等方面的要求。
7.1 部署圖
在實際環境中的電腦、服務器或硬件設備,在部署圖中用節點(Node)來表示,就是圖中一個個立體矩形。
每個節點都有一個名字,如圖中的財務的pc等。
門店的pc中有標記,標記(Tags)用來詳細說明節點的配置情況,如Number=50-70,說明有50到70臺門店的pc。
節點與節點直接有物理聯系,則直接拉條直線,在直線上寫上連接的方式。
如下圖所示。
7.2 構件圖
構件圖也叫組件圖,構件指的是物理上獨立的一個東西,它可以單獨維護、升級、替換。
下圖展示了構件和構件的接口:
下圖中的A和B表示依賴關系,表示A依賴于B,A需要調用B提供的一些服務。而C和D則是接口對接,D提供的服務是C所需要的,也可以畫成C依賴D。
如圖:
7.3 部署圖和構件圖結合使用
通常部署圖和構件圖需要綜合使用,才能表達清楚在架構設計上的要求。
如下圖:
7.4 關于部署圖和構件圖的實踐建議
- 首先不要寫放在任何地方都可用的東西,要根據項目的業務需求,IT架構環境寫出針對性的要求;
- 其次,抓住主要問題,列出具體要求。主要考慮正常使用情況下系統應達到的要求,出現幾率低的情況可不考慮;
- 最后,要文字表達準確,內容應該是可被驗證的。
八、一些實踐
本章主要為前面所講的內容,通過一個案例,將部分串聯起來。
我們的需求是做一個考勤系統。主要目標是規范員工的上下班、請假、外出工作等行為,同時方便計算員工薪資,方便管理各種帶薪假期。
在整個過程中,需要遵循戰略分析、相關方與目標分析、業務分析、需求細化這樣的流程。那在業務分析階段可以通過使用類圖來分析業務概念,使用活動圖、順序圖、狀態機圖來分析業務流程。
在需求細化階段可以使用用例圖來整理用例。同時也可以使用部署圖和構件圖來分析整理非功能性需求。
那在這里直接省略戰略分析、相關方與目標分析階段,直接進入到業務概念分析。假設已經目標清晰,且明確了相關方。那么下一步進入到業務概念分析。
8.1 業務概念圖
這個考勤系統主要涉及到考勤,請假,外出??记诤驼埣俸芎美斫?,外出是指外出工作,性質仍然是工作。
這三類事情全都涉及到流程,流程的問題咱們后面在分析,通常我們管理一個事情,除了管理流程,還要對一條或多條記錄進行管理。
打卡不是會留下打卡記錄嗎?請假不是會有請假申請嗎?外出不是會有外出申請嗎?管理這些記錄,就是管理這些事情了。
如下圖,列出了關鍵的業務概念、業務概念的重要屬性、業務概念之間的關系、相關業務信息通過注解來補充。
每個人所在的公司情況不一樣,理解的角度不一樣,業務概念圖自然就會不一樣。
8.2 外出申請審批流程分析
這里只對外出申請做舉例,分別畫出它的活動圖和狀態機圖。
當然,也可以用順序圖來表達,但是此處用活動圖和狀態機圖更合適,所有省略了順序圖。
活動圖
狀態機圖
8.3 普通員工的用例分析
這里只對普通員工做舉例,進行了用例分析。這里考慮到用戶需要擁有管理自己外出的權限,管理自己請假,包含可休年假的權限。
同時為了方便安排工作,所以增加了可以查看所有員工請假的權限,以及查看自己打卡記錄的權限。
如下圖:
8.4 其他
關于部署圖和構件圖,一般情況下是由架構師來完成。所以在這里就不進行舉例了。
九、總結
關于UML,是我們日常工作中,最常見的一種手段。它很簡單,也很復雜。
簡單的原因在于一學就會,容易上手,便于理解;復雜的原因是要畫好uml建模需要不斷的思考,反復驗證,重復修改,才能達到最終的目的。
所以以上只是基于前者,來簡單的說明常用的UML。若要提高建模能力,需要在日常的工作,生活中,不斷的練習思考,終有所成。
本文由 @侯學峰 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
學習了
除了流程圖和狀態機圖,其他的感覺沒啥用
文件夾和文件為啥不是 強包含呢?
文中有提到強包含和若包含的含義。同理,如果文件夾不存在了,那么這個文件夾里面的文件夾和文件依然存在,所以說弱包含。
文件夾和文件只有包含關系嗎,怎么識別到有關聯關系的
第一個狀態機圖,大于三天的審批的時候沒有拒絕呢?
別人端盤好菜給你吃,你問盤子上花紋啥意思,干這行的不需要每件事都做成這樣規范,但是每個環節都要像作者寫的這樣思考
有拒絕呀~從部門經理到拒絕的那條線就是高層經理的拒絕。
可以這樣理解,在狀態為部門經理批準,且大于三天時,高層經理進行了拒絕操作,所以狀態變為拒絕。
我說的是 4.1章節的那個圖,我還是覺得 大于三天時還是少了一根到 拒絕的線呀
這是狀態機圖,框內的【部門經理批準】和【拒絕】都指的是狀態,其中【部門經理批準】->【拒絕】這條線表達的就是大于3天時,高層拒絕的情況