今天起再開個專題，談談我們開發中常用到的壹些圖形建模手段。前言結束，我們從 UML 視圖啟航。
UML——Unified Modeling Language——統壹建模語言，是業務建模階段最常用和最重要的壹種視圖。由於它簡單易懂，常常用於跨組織的文檔或演示的說明中；這裏所謂的跨組織指的不僅僅是開發部門間，而是指跨產品、設計、測試、運維等等部門的業務交流中。UML 設計中，第壹張圖壹般都是用例圖：是的，就是那個有“小人”的圖。
用例圖主要有三個部分組成：用例（Use Case）、參與者（Actor），以及它們互相間的關系（Relationship）；形式上就是用橢圓、小人，以及箭頭的連線組合。
我們先不細說橢圓或是箭頭的具體含義。我覺得講用例圖最好還是從具體的 Use case 入手為好。我們試著設計壹款簡單的銀行 APP，它包含註冊、登陸、交易等等操作。我們壹步步拆解揮著用例圖的過程。
畫用例圖的第壹步通常是拖出壹個巨大的矩形塊，並將其命名為我們的目標系統——Banking App。壹個用例圖壹般只會有壹個 System，之後我們會把所有該系統相關的是功能（“用例”）放置在系統內部，系統的相關方（“參與者”）放置在系統的左右兩側。
第二個繪制元素就是參與者，即系統相關方，可以是人、組織、外部設備，或是其他系統。在我們這個銀行案例裏，該 App 的相關方有兩個：就是客戶（Customer）和銀行（Bank）。
通常來說，壹個用例圖中會有兩三個參與者，我們會把主要參與者放在系統左側，次要參與者（主要參與者的回應方）放在右側；顯然我們的 App 主要是面向客戶的，所以把客戶放在了左邊。
第三步就是在系統內添加具體的用例，也就是該系統所提供的功能或是業務塊。我們的銀行 APP 比較簡單，只提供如下業務：
第四步，我們再把參與者與用例串聯起來，就是我們所說的關系（Relationships）。用例圖中，關系還可以繼續細分：
最後，所有 UML 視圖事實上都可以加註釋，專業術語叫延伸（Extension points）和批註（Note）；這兩種註釋性質形同，都是起說明作用：
好了，UML 用例圖大體就講完了。我們再回顧壹下用例圖的使用場景，在產品設計階段，我們可以使用用例圖為用戶、系統和功能服務建立起抽象關系，以便描述產品所呈現的外部動態特征。在壹些大廠中，通常由產品經理或是設計師來首先繪制 UML 用例圖，再交於開發團隊實現。
我們舉了壹個銀行 App 的例子，事實上有點大了；現實開發中，壹個 Use Case 圖通常只對應的壹個簡單的業務流而已。我們自己在寫用例圖時，也要註意在宏觀層面將聯系緊密的功能模塊抽象為壹個簡單的 Case，然後逐步地為這些較大的功能模塊畫出細分 Case 的用例圖。