一、前言

在日常工作中，無論是產品經理寫PRD或是開發、測試同學寫技術方案、整理業務文檔等場景都會用到諸如流程圖、時序圖、用例圖、泳道圖等形式的圖來輔助閱讀者理解。相信平時工作中有畫圖需要的讀者都有這樣的感受：有些圖制作過程非常簡單但邏輯清晰又不失美觀，而有些圖費時費力制作繁瑣，但效果卻不是特別驚艷，這其中的底層邏輯尤為關鍵，畢竟作圖也是一門藝術。本文將會以直播商品講解業務場景出發，給大家分享一些畫圖小知識。

上面我們提到了很多種的圖，歸根結底是兩類：流程圖和UML圖。細分的話有活動圖、狀態圖、用例圖、順序圖、類圖、對象圖、協作圖等13種。不同的圖適用于不同的情形。

本文主要討論流程圖和時序圖。

二、兩者區別

• 時序圖強調對象之間的交互與時序關系，流程圖則是針對一個過程或者活動進行全面而細致的展開。
• 時序圖主要描繪多個對象之間的復雜關系，流程圖通常描述單一對象的各種操作和轉換過程。
• 時序圖更加注重時間順序，可以清晰地表示交互的先后順序與時序關系，而流程圖注重過程的控制流程，可以描述每個步驟的執行方式以及處理邏輯。

三、流程圖

流程圖基本組成

如上圖所示，飛書文檔里提供的流程圖的元素。下面我簡述一下常用的圖形：

圖片

繪制流程圖中的注意事項

1. 畫流程圖的時候，需要遵守從上至下、從左至右的順序的原則進行排列，這樣做的目的是流程圖的邏輯性更高。

2. 一個流程需以開始符開始，以結束符來結束。開始符號只能出現1次，但是結束符號是可出現N次的。其實流程邏輯清晰的話，可以省略掉開始符號和結束符號，但還是建議保留二者。

3. 用菱形作為判別符號，且一定要有"是和否，建議使用Y或者N表示"兩個處理結果，且判別框中一定要有二個箭頭；而且判斷符號的上下處的流入流出一般用“是(Y)”，左右處流入流出用“否(N)”。

4. 在一個流程圖中，字符的大小必須一致，同時連線不得交叉，連線也不得無故扭曲。

5. 流程處理關系如果是并行關系的，那么就需要將流程畫的時候放在同一個高度。

6. 描述流程需要清晰明了，所以必要的時候需采用標注，標注需要要用專門的標注符號來表示。

7. 畫處理流程，必須是單一的入口、單一的出口。

BadCase：

圖片

對照上文7點注意事項看看上圖存在哪些問題？直觀感受是不是看著不是很舒服？

• 元素大小不一致。
• 布局未按從左到右。
• 部分需要判斷的流程沒有畫出來。
• 處理流程的入口和出口非單一。

還有其他問題期盼大家在評論區里留言。

GoodCase：

主播或者管理員對商品進行錄制講解功能：

圖片

四、時序圖

時序圖基本組成

時序圖形，也被叫做序列圖,是UML圖形的一部分。它通過描述對象間傳遞message的時間序列，來表示各個object間的動態協作關系。飛書文檔里提供了豐富的元素來支持我們繪制UML圖。

圖片

其中比較常用的有以下7種。

圖片

畫好時序圖的注意事項

1. 必須明確上下文

掌握了這一點就成功了一大半，沒有做到這一點基本就畫不清楚了。

為什么說的這么篤定呢？

眾所周知，時序圖中參與交互的實體只有兩類，即角色（Actor）和對象（Object）。如果連交互的實體都沒有明確的定義以及達成一致，具體交互的流程就很難說清楚，也就很難使所有讀者和作者達成一致。

2. 決定該不該把某個實體放進時序圖

實體是否展示與業務場景和所設計的對象密切關聯，只有在業務場景中與所設計對象有直接交互的實體才有必要放入時序圖中，間接交互實體則應當去掉。

3. 響應消息要與請求消息分開

    a. 同步消息與返回消息

同步消息（也稱為調用消息）一定要與返回消息成對使用，特別要強調的是：返回消息樣式不得使用同步消息的樣式，這是兩個完全不同的事情。同步消息表示一個實體對另一個實體的一個接口調用，被調用方要按流程實現提供接口的編碼，并按返回消息內容要求進行返回；調用方需要按流程實現調用接口的編碼，并對返回消息內容進行處理。為了更清楚的說明問題，往往會在消息中注明關鍵的參數。

經常看到的錯誤是不區分兩種消息，讀者看后會產生理解偏差。

    b. 異步消息

message的發件者通過把信息發給接收對象，然后繼續它自己的執行邏輯，不需要等待接收者響應。

    c. 自關聯消息

表示實體自身需要實現一個處理過程，也可以調用一個外部實體的消息。

示例場景：直播短視頻切片生產并送審

業務簡要說明：主播把錄制好的商品解說進行視頻上傳，視頻需要同步上傳至點播中心，然后需要對視頻進行轉碼。另外視頻需要進行風險檢查。視頻內容重復度檢查。最后投遞到直播審核后臺進行人工審核。

• 明確上下文：

本場景只需要一個時序圖就可以畫完，所以不涉及上下文。明確好角色和對象即可。如果是多個時序圖描述的，所有的實體的命名需要統一定義好，且顆粒度需要保持一致。

• 確定實體：

只需要把我們直接交互的實體進行羅列。舉例：在本示例中，視頻送審至風控后，風控側審核人員領取任務進行審核這個步驟與本示例就屬于間接交互。就需要剔除。因為我們只需要關心送審成功，以及審核結果同步即可。

• 消息交互梳理：

主播上傳視頻至直播服務是同步消息。

直播服務同步返回主播操作成功or失敗消息。

直播服務把視頻注冊到外部云廠商視頻點播服務是一個異步操作需要異步消息。

點播注冊成功后通知直播服務，所以是一個回調操作。

直播服務通知外部云廠商視頻點播服務進行轉碼操作，是一個異步操作需要異步消息。

直播服務把視頻送審至風控是一個異步操作需要異步消息。

上述兩步可以并行操作，所以需要標記并行。

外部云廠商視頻點播服務轉碼成功通知直播服務，所以是一個回調操作。

直播服務把轉碼后的視頻通知算法進行去重檢查是異步操作，需要異步消息。

風控結果同步直播服務，是一個回調操作。

直播服務進行送入人審是一個異步操作。

算法視頻重復度檢查結果通知直播服務是一個回調操作。

直播服務接收到視頻重復檢查結果后，只需內部處理。所以是自關聯消息。

綜上梳理，時序圖繪制如下：

圖片

五、結語

上述主要分享了流程圖和時序圖繪制的一些小Tips，因篇幅有限其他UML圖在后續的文章中再做補充。我們倡導規范且有邏輯地畫圖，這對讀者是非常友好的，便于其快速熟悉業務流程，并理解實現思路。對照你之前畫的流程圖和時序圖，看看是否還有調整優化的空間，有沒有辦法表述更清楚？期待大家的評論互動，共同指出畫圖過程中可以繼續完善的地方。