一、前言

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

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

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

(相關(guān)資料圖)

二、兩者區(qū)別時序圖強(qiáng)調(diào)對象之間的交互與時序關(guān)系，流程圖則是針對一個過程或者活動進(jìn)行全面而細(xì)致的展開。時序圖主要描繪多個對象之間的復(fù)雜關(guān)系，流程圖通常描述單一對象的各種操作和轉(zhuǎn)換過程。時序圖更加注重時間順序，可以清晰地表示交互的先后順序與時序關(guān)系，而流程圖注重過程的控制流程，可以描述每個步驟的執(zhí)行方式以及處理邏輯。三、流程圖流程圖基本組成

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

圖片

繪制流程圖中的注意事項

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

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

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

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

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

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

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

BadCase：

圖片

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

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

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

GoodCase：

主播或者管理員對商品進(jìn)行錄制講解功能：

圖片

四、時序圖時序圖基本組成

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

圖片

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

圖片

畫好時序圖的注意事項1. 必須明確上下文

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

為什么說的這么篤定呢？

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

2. 決定該不該把某個實體放進(jìn)時序圖

實體是否展示與業(yè)務(wù)場景和所設(shè)計的對象密切關(guān)聯(lián)，只有在業(yè)務(wù)場景中與所設(shè)計對象有直接交互的實體才有必要放入時序圖中，間接交互實體則應(yīng)當(dāng)去掉。

3. 響應(yīng)消息要與請求消息分開a. 同步消息與返回消息

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

經(jīng)?？吹降腻e誤是不區(qū)分兩種消息，讀者看后會產(chǎn)生理解偏差。

b. 異步消息

message的發(fā)件者通過把信息發(fā)給接收對象，然后繼續(xù)它自己的執(zhí)行邏輯，不需要等待接收者響應(yīng)。

c. 自關(guān)聯(lián)消息

表示實體自身需要實現(xiàn)一個處理過程，也可以調(diào)用一個外部實體的消息。

示例場景：直播短視頻切片生產(chǎn)并送審

業(yè)務(wù)簡要說明：主播把錄制好的商品解說進(jìn)行視頻上傳，視頻需要同步上傳至點播中心，然后需要對視頻進(jìn)行轉(zhuǎn)碼。另外視頻需要進(jìn)行風(fēng)險檢查。視頻內(nèi)容重復(fù)度檢查。最后投遞到直播審核后臺進(jìn)行人工審核。

明確上下文：

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

確定實體：

只需要把我們直接交互的實體進(jìn)行羅列。舉例：在本示例中，視頻送審至風(fēng)控后，風(fēng)控側(cè)審核人員領(lǐng)取任務(wù)進(jìn)行審核這個步驟與本示例就屬于間接交互。就需要剔除。因為我們只需要關(guān)心送審成功，以及審核結(jié)果同步即可。

消息交互梳理：

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

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

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

點播注冊成功后通知直播服務(wù)，所以是一個回調(diào)操作。

直播服務(wù)通知外部云廠商視頻點播服務(wù)進(jìn)行轉(zhuǎn)碼操作，是一個異步操作需要異步消息。

直播服務(wù)把視頻送審至風(fēng)控是一個異步操作需要異步消息。

上述兩步可以并行操作，所以需要標(biāo)記并行。

外部云廠商視頻點播服務(wù)轉(zhuǎn)碼成功通知直播服務(wù)，所以是一個回調(diào)操作。

直播服務(wù)把轉(zhuǎn)碼后的視頻通知算法進(jìn)行去重檢查是異步操作，需要異步消息。

風(fēng)控結(jié)果同步直播服務(wù)，是一個回調(diào)操作。

直播服務(wù)進(jìn)行送入人審是一個異步操作。

算法視頻重復(fù)度檢查結(jié)果通知直播服務(wù)是一個回調(diào)操作。

直播服務(wù)接收到視頻重復(fù)檢查結(jié)果后，只需內(nèi)部處理。所以是自關(guān)聯(lián)消息。

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

圖片

五、結(jié)語

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

關(guān)鍵詞：