1. 為什么建立UML模型范例

作為統一建模語言，UML可以幫助我們對很多業務、技術的知識進行梳理，從多個視角描述清楚，幫助讀者理解。另外因為UML的建模首先來自于軟件建模的需求，所以UML的模型很容易轉換為軟件的設計，這對于軟件開發者來說是一個天生的福利。

現在UML對于IT技術有關的建模已經比較成功，例如：

• 用類圖建模 數據模型、程序結構。
• 用活動圖建模業務流程、程序流程和運算過程等等。
• 用順序圖建模人員交互、程序模塊交互等等。
• 用狀態圖建模控制對象的狀態邏輯。

但是一個完整的應用，最重要的往往是專業性強的領域知識的建模。而這方面，可以公開看到的UML范例卻不多，這也就造成了UML建模的價值還沒有被充分的挖掘出來。

所以我們嘗試采用UML對各個領域的專業知識建模，期望能夠讓大家看到邏輯建模的重要性，以及在邏輯建模方面以面向對象思想為核心的UML建模的強大表達力。進而更多的采用UML提高描述、分析和設計能力。

雖然UML對邏輯建模具有很大的表達能力，但是各個專業領域自身、以及人們自發的描述方式也是非常重要的，而且一般是各種專業知識的首要表達方式。所以UML的建模不應該成為已有描述形式的顛覆者，而更應該是對已有描述的梳理，以更簡潔、更加精確、更加抽象的方式進行邏輯化描述。這樣可以對知識進行多個維度、多個層次的更加充分的挖掘和展示。因為我們這里主要關注UML的建模，但是也不想損失已有的知識描述，所以在UML之前的各種已有的知識的描述和建模方式，我們這里稱之為 “原生圖”。

所以我們對專業知識的建模采用2種方式：

• 原生圖：采用被建模領域的常見圖示，可以是專業圖，也可以是一些形象的示意圖。
• UML圖：采用UML建模，重點是邏輯的描述，更強調建模的簡潔性和清晰度。

為了更加充分的描述被建模對象，這里采用4個視角進行建模：

• 結構視角：描述事物的構成和關系，是一種靜態視圖。
• 過程視角：描述一個事物的行為過程，是一種動態視圖。
• 數據視角：描述行為過程中傳遞的數據，數據結構是靜態視圖， 數據的傳遞是一個動態視圖。
• 狀態視角：描述各種對象和行為的狀態變化，狀態的數據結構定義，屬于靜態視圖，狀態的轉換過程，是一種動態視圖。
  

本文采用UML模型對TCP協議進行建模。主要涉及4個視圖：

1. 結構視圖：描述該協議的網絡通信相關的節點和鏈接。
2. 過程視圖：描述基于該協議的網絡通信的過程。
3. 數據視圖：描述通信相關的數據結構和關系。
4. 狀態視圖：描述通信過程中的對象狀態。
5. TCP/IP協議簡介

TCP 協議是通信網絡傳輸層的網絡通信協議。為了充分的理解TCP按照TCP/IP的5層協議結構，我們看看各層通信協議的職責，如下圖所示：

TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協議/網際協議）是指能夠在多個不同網絡間實現信息傳輸的協議簇。TCP/IP協議不僅僅指的是TCP 和IP兩個協議，而是指一個由FTP、SMTP、TCP、UDP、IP等協議構成的協議簇， 只是因為在TCP/IP協議中TCP協議和IP協議最具代表性，所以被稱為TCP/IP協議。

TCP/IP五層模型說明：

通信過程中最重要的數據就是在各個通信協議層次傳遞的數據。如下是一個要發送的消息通過各個網絡協議層的過程中被逐步添加相應協議信息的示意圖：

較高的層將信息傳遞給較低的層。每一層都將被稱為header的信息添加到傳遞給它的數據中。此header包含圖層執行其工作所需的信息。我們將從應用程序層開始。

我們更關注各個層次數據的逐步累加過程，為了讓表達累加過程中數據結構的變化，采用UML的類圖，對各個層次的數據結構進行建模如下：

各個網絡通信層次對消息的處理過程采用UML的活動圖描述其中的數據流如下：

活動圖描述：

3. UML建模圖例

下面采用UML的4個視圖建模TCP通信協議。

3.1 結構視圖

主要描述TCP協議的網絡通信相關的網絡節點和連接，采用UML的復合結構圖建模如下：

3.2 過程視圖

過程視圖主要描述2各層次：

• 整個網絡通信的過程
• TCP傳輸的過程

TCP通信過程

建立連接

通過三次握手（3個消息）建立客戶端和服務端的連接：

1. 客戶端發出建立連接請求，
2. 服務端響應
3. 客戶端確認收到響應

順序圖描述：

傳輸數據

如下是傳輸數據的圖示：

關閉連接

通過四次握手（4個消息）關閉客戶端和服務端的連接：

1. 客戶端發出關閉請求
2. 服務端確認
3. 服務端發出關閉請求
4. 客戶端確認

順序圖描述：

如下是來自于一篇網絡文章的關閉連接的過程描述：

• 第一次揮手：主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的數據傳送，也就是主動關閉方告訴被動關閉方：我已經不會再給你發數據了(當然，在fin包之前發送出去的數據，如果沒有收到對應的ack確認報文，主動關閉方依然會重發這些數據)，但此時主動關閉方還可以接受數據。
• 第二次揮手：被動關閉方收到FIN包后，發送一個ACK給對方，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號）。
• 第三次揮手：被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的數據傳送，也就是告訴主動關閉方，我的數據也發送完了，不會再給你發數據了。
• 第四次揮手：主動關閉方收到FIN后，發送一個ACK給被動關閉方，確認序號為收到序號+1，至此，完成四次揮手。

3.3 數據視圖

一個具體的TCP報文結構如下圖所示：

可以用UML的類圖對報文結構進行建模，圖示如下：

這個類圖對結構的關系描述的更加清晰，也符合開發工程師的結構化需要。當然也比較抽象，應該結合原生圖進行理解才好。

3.4 狀態視圖

通信協議因為存在狀態變遷，所以一般采用狀態圖建模協議的狀態機。下圖來自于一篇網絡是常見的TCP協議狀態機(來自于一篇網絡文章)：

TCP狀態及其描述如下表。

這個狀態圖涉及到了客戶端、服務端、網絡連接多個對象，所以看起來一頭霧水，很難理解。這樣的圖示對于用戶是不友好的，所以有必要用UML的狀態圖改進一下。

狀態圖的建模首先應該識別持有狀態的對象，然后再建立它的狀態圖，TCP網絡通信過程實際上涉及到了3個對象：

• 客戶端Client，
• 服務端Host，
• 網絡連接Connection 。

他們分別有各自的狀態圖，下面基于TCP的通信過程，對三個對象的狀態分別進行建模。

Connection的狀態如下

這樣看起來和通信過程完全映射，好理解多了。