摘要：時序圖是統一模型語言UML（Unified Model Language）中一種用來表示實體間交互關系的圖。
1 前言
在定義系統間接口或模塊間接口時，時序圖使用起來非常方便，工作中經常涉及要與第三方系統協商定義接口，或者定義系統內多模塊間接口的情況，經常會看到很多時序圖。有的時序圖畫的很漂亮，很好的幫助讀者准確理解業務和實現方法，而有的時序圖則讀起來人雲山霧罩，痛苦不已。本文不打算再說一遍時序圖的結構和步驟，只想說明時序圖中經常遇到主要問題，並許下一個美好的願望：希望以后的工作中再也不要遇到難讀的時序圖。
時序圖是統一模型語言UML（Unified Model Language）中一種用來表示實體間交互關系的圖，英文Sequence Diagram，有的人把它稱為序列圖、順序圖、循序圖，個人習慣於稱為時序圖，下文都以這個名字來稱呼。
畫時序圖的工具非常多，從早期的Rational Rose、Sybase Power Designer、Visio，到Enterprise Architect、StarUML，甚至用Typora來畫Markdown風格時序圖也不錯，再到現在按公司的要求換用億圖圖示Edraw，這些工具都不錯，稍微適應下就能畫出漂亮的時序圖了。
值得推薦的是，公司CloudDesign在線設計工具提供的CloudModeling繪圖工具用起來也相當舒服，既便於在團隊分享，又提供了Word插件便於導入設計文檔，如果修改了時序圖也只需要在word文檔中更新一下就自動刷新了，非常方便，強烈推薦使用。網址：https://clouddragon.huawei.com/uadp/home
下面進入正題。
2 關鍵點1：必須明確上下文
掌握了這一點就成功了一大半，沒有做到這一點就基本畫不清楚了。
為什么這句話說這么狠？不就畫個時序圖嘛，關上下文什么事？因為看過太多讓人痛恨的時序圖都栽在這個問題上。
我們知道時序圖中參與交互的實體只有兩類，即角色（Actor）和對象（Object），如果連交互的實體都不能明確的定義和達成一致，忽東忽西，忽大忽小，具體交互的流程怎樣可能說清楚，使所有讀者和寫作者達成一致呢。
為說明這個問題，以車聯網的場景舉個例子，比如遠程控制特性的交互時序圖。
車輛授權交互時序圖
遠程開車窗交互時序圖
遠程開車門交互時序圖
如圖所示，我們看到交互實體中出現了多個類似但又不同的表述，例如“車主”、“被授權用戶”、“被分享用戶”這一組，“手機App”和“車主App”這一組，“TSP平台”、“TSP系統”和“車雲”這一組，而在車輛方面，有時稱為“車輛”這么大的粒度，有時又稱細分為“TBox”、“車身控制模塊”、“PEPS”。
這里僅僅舉例了3個交互時序圖，而一個復雜系統往往會出現幾十上百個，當每個時序圖的作者都隨心所欲的對交互實體進行命名時就會出現極其混亂的局面，最終貌似每個時序圖都看起來很有道理，放在一起看卻難以准確理解，使讀者抓狂。
解決辦法：很簡單，畫出一個上下文圖，把所有時序圖中涉及的交互實體都放進去，規定它們的名字，要求所有時序圖中的實體必須與上下文圖中保持一致，不得自己定義新的。如果確實需要增加新的實體，那么首先更新上下文，在上下文圖中把實體定義進去才能使用。
例如針對上述車聯網的場景，增加一個這樣的上下文就可以更加清晰：
在實際項目中，可以利用工具來實現這個一致性。例如CloudModeling繪圖工具中，我們會定義完整的系統上下文和系統邏輯架構視圖，要求所有的交互時序圖必須從這里面鏈接引用角色和，而不是自己新建一個。
3 關鍵點2：決定該不該把某個實體放進時序圖
在上面的例子中，在車輛相關實體中，有時稱為“車輛”這么大的粒度，有時又稱細分為“TBox”、“車身控制模塊”、“PEPS”。事實上，“TBox”、“車身控制模塊”、“PEPS”都是車輛內部模塊的一部分，那么究竟什么情況下該把“車輛”這么大的粒度放入時序圖，什么情況下該把“TBox”、“車身控制模塊”、“PEPS”這樣的內部模塊展示出來呢？
個人理解是這樣的：實體是否展示與業務場景和所設計的對象密切關聯，只有在業務場景中與所設計對象有直接交互的實體才有必要放入時序圖中，間接交互實體則應當去掉。
在上面的例子中，如果我們設計的對象是TSP及車主手機App，那么車輛內部的實體部分就不需要展開，只需要展示與車雲直接交互的TBox模塊即可，如下：
遠程開車門交互時序圖
但是，如果我們設計的對象換成了車身控制模塊，那么交互的實體就應當省略TSP及車主手機App相關的實體，把關注點調整到與車身控制模塊直接交互的實體上來，例如：
遠程開車門交互時序圖
4 關鍵點3：響應消息要與請求消息分開
時序圖中交互實體間水平的線條用來表示消息，最常見的有三種：
4.1 同步消息（Synchronous Message）與返回消息（Return Message）
同步消息（也稱為調用消息）一定要與返回消息成對使用，特別要強調的是：返回消息樣式不得使用同步消息的樣式，這是兩個完全不同的事情。同步消息表示一個實體對另一個實體的一個接口調用，被調用方要按流程實現提供接口的編碼，並按返回消息內容要求進行返回；調用方需要按流程實現調用接口的編碼，並對返回消息內容進行處理。為了更清楚的說明問題，往往會在消息中注明關鍵的參數。
經常看到的錯誤是不區分同步消息和返回消息，亂畫一氣，非常讓人惱火。有時會看到像這樣的時序圖，特別注意其中紅色的消息線條，看起來似乎“TBox”實體對“TSP”實體的一個接口調用，但實際問一問作者，發現並不是這樣，而是上面消息的返回消息。這樣的畫法就給人造成一種錯覺，以為交互實體雙方需要實現一個新的接口。
4.2 異步消息（Asynchronous Message）
消息發送者通過消息把信息發給消息接收者，然后繼續自己的活動，不等待接收者返回消息。
4.3 自關聯消息（Self-Message）
表示實體自身需要實現一個處理過程，也可以調用一個外部實體的消息。
同樣以上面車聯網場景為例，假定設計的對象是TSP及車主手機App，那么我們只能對這兩個實體分解開發任務，如圖，我們要求“車主手機App”實現“提供開車門功能”，具體包含向TSP的請求開車門消息調用及返回結果的處理；“TSP”要實現“提供開車門接口”，具體包含向TBox的下發開車門指令及返回結果的處理，還包含一個發送短信通知的異步消息，TSP提供的開車門接口請求參數中應包含關鍵的用戶token、車輛ID信息，返回結果中應包含關鍵的成功/失敗、錯誤信息。
注意：這里引入了一個新的實體“短信中心”，也應當在上下文圖中先加進去才能使用。
遠程開車門交互時序圖
5 總結
三個關鍵點：所有交互實體放進上下文，不直接交互的實體去掉，響應消息要與請求消息分開。如果你畫的時序圖確保以上三個關鍵點都做到了，我想至少拿出去給大家看的時候會少挨一點抱怨。