一文讀懂 UML 時序圖

書接上文，咱們在《一文讀懂 UML 用例圖》裏說到：需求設計的第一圖一般是用例圖，後來有人問我，那第二圖、第三圖呢？本文開始前，我先列一下設計階段經常使用到的 UML 視圖：java

你們能夠看到，時序圖和活動圖是各個設計階段，從產品經理、架構師，到底層開發人員都會使用到的視圖，今天就藉機講講如何畫時序圖。git

概述

時序圖（Sequence Diagram）是 UML 中最多見的交互圖，經過描述對象間發送消息的時間順序顯示多個對象之間的動態協做狀態。github

數序圖的元素稍多於用例圖，有角色（Actors）、對象（Object）、生命線（Lifetime）、消息（Message）、激活（Focus of Control）等等。markdown

咱們仍是老樣子，不列一堆名詞解釋，只用一個簡單的例子，分步驟講解這些功能模塊的示意以及使用方式。例子的話，仍是沿用咱們的乞丐版銀行 APP——見《一文讀懂 UML 用例圖》；因爲篇幅所限，本文只涉登錄和查詢餘額相關的操做。架構

Actor（角色）& Object（對象）

時序圖的第一步是列出交互中出現的全部角色和對象。框架

角色：一般指「人」，也能夠是組織、機器、系統等等「抽象的人」，和用例圖同樣，用小人圖表示
對象：就是與上述「人」對應的「物」了，包括全部產品、服務、設備等等抽象的物體

時序圖的交互，一般由最左側的 Actor 發出；在咱們的銀行 APP 案例中，Actor 是客戶；咱們就按出場順序，把這些「人」和「物」從左至右列出來：oop

Lifeline（生命線）

時序圖的第二步很是機械：給每一個角色和對象加上一條生命線。所謂的生命線就是從角色（或對象）引出向下延伸的虛線，表示時序圖存在的時間軸。post

Message（消息）

有了角色和生命線，時序圖的基本框架就搭建起來了。咱們就可讓客戶向 APP 發出第一個消息了——登錄：spa

消息天然是有來有往的，發送出去的消息叫 Request（請求），反饋的消息成爲 Response（響應）設計

請求用實心箭頭示意，並在箭頭上方加註說明
響應用虛線箭頭表示，也會加上簡單的返回內容

咱們登錄的操做，如上圖所示就是這麼幾小步：

客戶輸入用戶名、密碼後點擊登錄
APP 將用戶名、密碼送往 Auth 服務驗證
Auth 服務經過驗證後返回 JWT
APP 向客戶顯示登錄成功

Combined Fragment（組合片斷）

可是，登錄也可能失敗！也就是說在時序圖上還要添加登錄失敗時的消息反饋。這時候就得用到組合片斷了；組合片斷用來解決交互執行中的條件反饋。組合片斷長得比較複雜，以下圖所示：

組合片斷有十幾種，最經常使用的就是 Alt 片斷——抉擇片斷，通俗來講就是 if-else 的條件判斷組合。如上圖所示：

左上角黃色區域會標明片斷的類型
片斷中用虛線區分不一樣的條件子域
再在子域左上角——綠色陰影區——註釋條件判斷
最後在各自的條件子域上返回特定響應

Focus of Control（控制焦點）

控制焦點又稱激活，是覆蓋在生命線上一段細長的矩形，表示在這個時間段內，對象或角色正處於活動狀態；這有點相似於 java 語言裏的大括號{}——做用域。畫激活相對來講比較機械，我通常都留到最後加上。

由上圖可知，APP 的活動態要長於 Auth 服務；若是再加上 Bank 服務相關的時序活動，你們能更直觀地感覺到服務運行時長對比。這有什麼用呢？先賣個關子，我會在以後的文章裏給出解答。

小結

好了，基本元素都講完了，咱們再小結一下。時序圖是咱們開發人員使用最頻繁的一種設計視圖。你們在動手實現新 feature 前，都應該畫一張設計視圖。爲何呢？其根本緣由就是：畫設計圖的成本要遠低於碼代碼，經過設計圖理清思路後，開發更便捷；換句話說，就是咱們應該以更經濟地形式完成工做。此外，還有一些腹黑的緣由：代碼很長的，老闆根本沒時間看的；你要本身找存在感，得讓他/她看簡單明瞭的東西，圖就是最好的信息介質！好了，你們快去畫圖吧。

文章同步發佈於an-Onion 的 Github。碼字不易，歡迎點贊。