1. 為什么建立UML模型范例
作為統(tǒng)一建模語言,UML可以幫助我們對(duì)很多業(yè)務(wù)、技術(shù)的知識(shí)進(jìn)行梳理,從多個(gè)視角描述清楚,幫助讀者理解。另外因?yàn)閁ML的建模首先來自于軟件建模的需求,所以UML的模型很容易轉(zhuǎn)換為軟件的設(shè)計(jì),這對(duì)于軟件開發(fā)者來說是一個(gè)天生的福利。
現(xiàn)在UML對(duì)于IT技術(shù)有關(guān)的建模已經(jīng)比較成功,例如:
- 用類圖建模 數(shù)據(jù)模型、程序結(jié)構(gòu)。
- 用活動(dòng)圖建模業(yè)務(wù)流程、程序流程和運(yùn)算過程等等。
- 用順序圖建模人員交互、程序模塊交互等等。
- 用狀態(tài)圖建??刂茖?duì)象的狀態(tài)邏輯。
但是一個(gè)完整的應(yīng)用,最重要的往往是專業(yè)性強(qiáng)的領(lǐng)域知識(shí)的建模。而這方面,可以公開看到的UML范例卻不多,這也就造成了UML建模的價(jià)值還沒有被充分的挖掘出來。
所以我們嘗試采用UML對(duì)各個(gè)領(lǐng)域的專業(yè)知識(shí)建模,期望能夠讓大家看到邏輯建模的重要性,以及在邏輯建模方面以面向?qū)ο笏枷霝楹诵牡腢ML建模的強(qiáng)大表達(dá)力。進(jìn)而更多的采用UML提高描述、分析和設(shè)計(jì)能力。
雖然UML對(duì)邏輯建模具有很大的表達(dá)能力,但是各個(gè)專業(yè)領(lǐng)域自身、以及人們自發(fā)的描述方式也是非常重要的,而且一般是各種專業(yè)知識(shí)的首要表達(dá)方式。所以UML的建模不應(yīng)該成為已有描述形式的顛覆者,而更應(yīng)該是對(duì)已有描述的梳理,以更簡(jiǎn)潔、更加精確、更加抽象的方式進(jìn)行邏輯化描述。這樣可以對(duì)知識(shí)進(jìn)行多個(gè)維度、多個(gè)層次的更加充分的挖掘和展示。因?yàn)槲覀冞@里主要關(guān)注UML的建模,但是也不想損失已有的知識(shí)描述,所以在UML之前的各種已有的知識(shí)的描述和建模方式,我們這里稱之為 “原生圖”。
所以我們對(duì)專業(yè)知識(shí)的建模采用2種方式:
- 原生圖:采用被建模領(lǐng)域的常見圖示,可以是專業(yè)圖,也可以是一些形象的示意圖。
- UML圖:采用UML建模,重點(diǎn)是邏輯的描述,更強(qiáng)調(diào)建模的簡(jiǎn)潔性和清晰度。
為了更加充分的描述被建模對(duì)象,這里采用4個(gè)視角進(jìn)行建模:
- 結(jié)構(gòu)視角:描述事物的構(gòu)成和關(guān)系,是一種靜態(tài)視圖。
- 過程視角:描述一個(gè)事物的行為過程,是一種動(dòng)態(tài)視圖。
- 數(shù)據(jù)視角:描述行為過程中傳遞的數(shù)據(jù),數(shù)據(jù)結(jié)構(gòu)是靜態(tài)視圖, 數(shù)據(jù)的傳遞是一個(gè)動(dòng)態(tài)視圖。
- 狀態(tài)視角:描述各種對(duì)象和行為的狀態(tài)變化,狀態(tài)的數(shù)據(jù)結(jié)構(gòu)定義,屬于靜態(tài)視圖,狀態(tài)的轉(zhuǎn)換過程,是一種動(dòng)態(tài)視圖。
本文采用UML模型對(duì)TCP協(xié)議進(jìn)行建模。主要涉及4個(gè)視圖:
- 結(jié)構(gòu)視圖:描述該協(xié)議的網(wǎng)絡(luò)通信相關(guān)的節(jié)點(diǎn)和鏈接。
- 過程視圖:描述基于該協(xié)議的網(wǎng)絡(luò)通信的過程。
- 數(shù)據(jù)視圖:描述通信相關(guān)的數(shù)據(jù)結(jié)構(gòu)和關(guān)系。
- 狀態(tài)視圖:描述通信過程中的對(duì)象狀態(tài)。
- TCP/IP協(xié)議簡(jiǎn)介
TCP 協(xié)議是通信網(wǎng)絡(luò)傳輸層的網(wǎng)絡(luò)通信協(xié)議。為了充分的理解TCP按照TCP/IP的5層協(xié)議結(jié)構(gòu),我們看看各層通信協(xié)議的職責(zé),如下圖所示:
TCP/IP(Transmission Control Protocol/Internet Protocol,傳輸控制協(xié)議/網(wǎng)際協(xié)議)是指能夠在多個(gè)不同網(wǎng)絡(luò)間實(shí)現(xiàn)信息傳輸?shù)膮f(xié)議簇。TCP/IP協(xié)議不僅僅指的是TCP 和IP兩個(gè)協(xié)議,而是指一個(gè)由FTP、SMTP、TCP、UDP、IP等協(xié)議構(gòu)成的協(xié)議簇, 只是因?yàn)樵赥CP/IP協(xié)議中TCP協(xié)議和IP協(xié)議最具代表性,所以被稱為TCP/IP協(xié)議。
TCP/IP五層模型說明:
層 | 職責(zé) |
---|---|
應(yīng)用層 | 應(yīng)用程序?qū)邮切枰W(wǎng)絡(luò)通信的應(yīng)用程序所在的位置。這些應(yīng)用程序的示例包括電子郵件客戶端和Web瀏覽器。這些應(yīng)用程序使用傳輸層發(fā)送請(qǐng)求以連接到遠(yuǎn)程主機(jī)。 |
傳輸層 | 在傳輸層建立在不同主機(jī)上運(yùn)行的應(yīng)用程序之間的連接。它使用TCP進(jìn)行可靠連接,使用UDP進(jìn)行快速連接。它通過為其分配port號(hào)來跟蹤在其上方的應(yīng)用程序中運(yùn)行的進(jìn)程,并使用網(wǎng)絡(luò)層訪問TCP / IP網(wǎng)絡(luò)。 |
網(wǎng)絡(luò)層 | 該網(wǎng)絡(luò)層負(fù)責(zé)創(chuàng)建在整個(gè)網(wǎng)絡(luò)中的數(shù)據(jù)包。它使用IP地址來識(shí)別數(shù)據(jù)包的源和目的地。 |
數(shù)據(jù)鏈路層 | 該數(shù)據(jù)鏈路層負(fù)責(zé)創(chuàng)建跨網(wǎng)絡(luò)傳輸?shù)膸?。這些幀封裝了數(shù)據(jù)包,并使用MAC地址來標(biāo)識(shí)源和目的地。 |
物理層 | 所述物理層編碼和解碼數(shù)據(jù)鏈路層的一幀中的bit,它包括收發(fā)器,可以在網(wǎng)絡(luò)上發(fā)生和接收信號(hào)。 |
通信過程中最重要的數(shù)據(jù)就是在各個(gè)通信協(xié)議層次傳遞的數(shù)據(jù)。如下是一個(gè)要發(fā)送的消息通過各個(gè)網(wǎng)絡(luò)協(xié)議層的過程中被逐步添加相應(yīng)協(xié)議信息的示意圖:
較高的層將信息傳遞給較低的層。每一層都將被稱為header的信息添加到傳遞給它的數(shù)據(jù)中。此header包含圖層執(zhí)行其工作所需的信息。我們將從應(yīng)用程序?qū)娱_始。
我們更關(guān)注各個(gè)層次數(shù)據(jù)的逐步累加過程,為了讓表達(dá)累加過程中數(shù)據(jù)結(jié)構(gòu)的變化,采用UML的類圖,對(duì)各個(gè)層次的數(shù)據(jù)結(jié)構(gòu)進(jìn)行建模如下:
各個(gè)網(wǎng)絡(luò)通信層次對(duì)消息的處理過程采用UML的活動(dòng)圖描述其中的數(shù)據(jù)流如下:
過程的文本描述 |
---|
應(yīng)用程序?qū)由梢粭l消息。在這種情況下,特定的應(yīng)用程序是請(qǐng)求網(wǎng)頁下載的Web瀏覽器。然后,此消息將發(fā)送到傳輸層。傳輸層添加了TCP 或者UDP 的header,其中包括源port和目標(biāo)port地址。其他信息(如用于TCP的數(shù)據(jù)包序列號(hào))也將添加到header中。如果使用TCP,則由傳輸層生成的數(shù)據(jù)稱為段(segment),如果使用UDP,則稱為數(shù)據(jù)報(bào)(Datagram)。然后將該段發(fā)送到網(wǎng)絡(luò)層。網(wǎng)絡(luò)層添加了包含源IP地址和目標(biāo)IP地址的header以生成數(shù)據(jù)包(Packet)。然后將此數(shù)據(jù)包發(fā)送到數(shù)據(jù)鏈路層。數(shù)據(jù)鏈路層添加包含MAC地址信息的header以創(chuàng)建幀(Frame)。然后,將該幀發(fā)送到物理層以傳輸比特碼。 |
活動(dòng)圖描述:
- UML建模圖例
下面采用UML的4個(gè)視圖建模TCP通信協(xié)議。
3.1 結(jié)構(gòu)視圖
主要描述TCP協(xié)議的網(wǎng)絡(luò)通信相關(guān)的網(wǎng)絡(luò)節(jié)點(diǎn)和連接,采用UML的復(fù)合結(jié)構(gòu)圖建模如下:
3.2 過程視圖
過程視圖主要描述2各層次:
- 整個(gè)網(wǎng)絡(luò)通信的過程
- TCP傳輸?shù)倪^程
TCP通信過程
建立連接
通過三次握手(3個(gè)消息)建立客戶端和服務(wù)端的連接:
- 客戶端發(fā)出建立連接請(qǐng)求,
- 服務(wù)端響應(yīng)
- 客戶端確認(rèn)收到響應(yīng)
過程的文本描述 |
---|
段1 :客戶端發(fā)送一個(gè)連接請(qǐng)求消息SYN報(bào)文說明:在TCP頭部的SYN位字段置位的TCP/IP數(shù)據(jù)包,并指明自己想要連接的port號(hào)和它的客戶端初始序列號(hào)(記為ISN,圖中ISN=x)。段2:服務(wù)端響應(yīng)連接請(qǐng)求消息服務(wù)端收到請(qǐng)求后,也發(fā)送自己的SYN報(bào)文段作為響應(yīng),并包含了它的初始序列號(hào)(ISN(s)=y)。此外,為了確認(rèn)客戶端的SYN,SYN數(shù)據(jù)加1后作為返回的ACK數(shù)值。因此,每發(fā)送一個(gè)SYN,序列號(hào)就會(huì)自動(dòng)加1。、段3:客戶端發(fā)送確認(rèn)收到響應(yīng)的消息為了確認(rèn)服務(wù)器端的SYN,客戶端將ISN(s)的數(shù)值加1后作為返回的ACK數(shù)值。這稱為段3。 |
順序圖描述:
傳輸數(shù)據(jù)
如下是傳輸數(shù)據(jù)的圖示:
關(guān)閉連接
通過四次握手(4個(gè)消息)關(guān)閉客戶端和服務(wù)端的連接:
- 客戶端發(fā)出關(guān)閉請(qǐng)求
- 服務(wù)端確認(rèn)
- 服務(wù)端發(fā)出關(guān)閉請(qǐng)求
- 客戶端確認(rèn)
過程的文本描述 |
---|
1. 主動(dòng)關(guān)閉者發(fā)送一個(gè)FIN,指明接收者希望看到的自己當(dāng)前的序列號(hào)。目的是告訴被動(dòng)關(guān)閉方,我要關(guān)閉連接了。2. 被動(dòng)關(guān)閉方收到 FIN包后,發(fā)送一個(gè)ACK給對(duì)方,將K的數(shù)值加1作為響應(yīng)的ACK值,以標(biāo)識(shí)該ACK對(duì)應(yīng)的FIN 。3. 被動(dòng)關(guān)閉方發(fā)送一個(gè)FIN,用來告訴對(duì)方,我也可以關(guān)閉連接了。為了標(biāo)識(shí)這是自己發(fā)起的,有一個(gè)表示位seq =q,為了標(biāo)識(shí)該FIN對(duì)應(yīng)的主動(dòng)關(guān)閉方發(fā)起的FIN,會(huì)有標(biāo)識(shí)符ack = p+1;4. 主動(dòng)關(guān)閉方收到 FIN后,發(fā)送和一個(gè)ACK給對(duì)方,告知確認(rèn)關(guān)閉,用一個(gè)標(biāo)識(shí)位ack =q+1標(biāo)識(shí)對(duì)應(yīng)的請(qǐng)求。 |
順序圖描述:
如下是來自于一篇網(wǎng)絡(luò)文章的關(guān)閉連接的過程描述:
- 第一次揮手:主動(dòng)關(guān)閉方發(fā)送一個(gè)FIN,用來關(guān)閉主動(dòng)方到被動(dòng)關(guān)閉方的數(shù)據(jù)傳送,也就是主動(dòng)關(guān)閉方告訴被動(dòng)關(guān)閉方:我已經(jīng)不會(huì)再給你發(fā)數(shù)據(jù)了(當(dāng)然,在fin包之前發(fā)送出去的數(shù)據(jù),如果沒有收到對(duì)應(yīng)的ack確認(rèn)報(bào)文,主動(dòng)關(guān)閉方依然會(huì)重發(fā)這些數(shù)據(jù)),但此時(shí)主動(dòng)關(guān)閉方還可以接受數(shù)據(jù)。
- 第二次揮手:被動(dòng)關(guān)閉方收到FIN包后,發(fā)送一個(gè)ACK給對(duì)方,確認(rèn)序號(hào)為收到序號(hào)+1(與SYN相同,一個(gè)FIN占用一個(gè)序號(hào))。
- 第三次揮手:被動(dòng)關(guān)閉方發(fā)送一個(gè)FIN,用來關(guān)閉被動(dòng)關(guān)閉方到主動(dòng)關(guān)閉方的數(shù)據(jù)傳送,也就是告訴主動(dòng)關(guān)閉方,我的數(shù)據(jù)也發(fā)送完了,不會(huì)再給你發(fā)數(shù)據(jù)了。
- 第四次揮手:主動(dòng)關(guān)閉方收到FIN后,發(fā)送一個(gè)ACK給被動(dòng)關(guān)閉方,確認(rèn)序號(hào)為收到序號(hào)+1,至此,完成四次揮手。
3.3 數(shù)據(jù)視圖
一個(gè)具體的TCP報(bào)文結(jié)構(gòu)如下圖所示:
可以用UML的類圖對(duì)報(bào)文結(jié)構(gòu)進(jìn)行建模,圖示如下:
這個(gè)類圖對(duì)結(jié)構(gòu)的關(guān)系描述的更加清晰,也符合開發(fā)工程師的結(jié)構(gòu)化需要。當(dāng)然也比較抽象,應(yīng)該結(jié)合原生圖進(jìn)行理解才好。
3.4 狀態(tài)視圖
通信協(xié)議因?yàn)榇嬖跔顟B(tài)變遷,所以一般采用狀態(tài)圖建模協(xié)議的狀態(tài)機(jī)。下圖來自于一篇網(wǎng)絡(luò)是常見的TCP協(xié)議狀態(tài)機(jī)(來自于一篇網(wǎng)絡(luò)文章):
TCP狀態(tài)及其描述如下表。
狀態(tài) | 描述 |
---|---|
LISTEN | 等待來自遠(yuǎn)程TCP應(yīng)用程序的請(qǐng)求 |
SYN_SENT | 發(fā)送連接請(qǐng)求后等待來自遠(yuǎn)程端點(diǎn)的確認(rèn)。TCP第一次握手后客戶端所處的狀態(tài) |
SYN-RECEIVED | 該端點(diǎn)已經(jīng)接收到連接請(qǐng)求并發(fā)送確認(rèn)。該端點(diǎn)正在等待最終確認(rèn)。TCP第二次握手后服務(wù)端所處的狀態(tài) |
ESTABLISHED | 代表連接已經(jīng)建立起來了。這是連接數(shù)據(jù)傳輸階段的正常狀態(tài) |
FIN_WAIT_1 | 等待來自遠(yuǎn)程TCP的終止連接請(qǐng)求或終止請(qǐng)求的確認(rèn) |
FIN_WAIT_2 | 在此端點(diǎn)發(fā)送終止連接請(qǐng)求后,等待來自遠(yuǎn)程TCP的連接終止請(qǐng)求 |
CLOSE_WAIT | 該端點(diǎn)已經(jīng)收到來自遠(yuǎn)程端點(diǎn)的關(guān)閉請(qǐng)求,此TCP正在等待本地應(yīng)用程序的連接終止請(qǐng)求 |
CLOSING | 等待來自遠(yuǎn)程TCP的連接終止請(qǐng)求確認(rèn) |
LAST_ACK | 等待先前發(fā)送到遠(yuǎn)程TCP的連接終止請(qǐng)求的確認(rèn) |
TIME_WAIT | 等待足夠的時(shí)間來確保遠(yuǎn)程TCP接收到其連接終止請(qǐng)求的確認(rèn) |
這個(gè)狀態(tài)圖涉及到了客戶端、服務(wù)端、網(wǎng)絡(luò)連接多個(gè)對(duì)象,所以看起來一頭霧水,很難理解。這樣的圖示對(duì)于用戶是不友好的,所以有必要用UML的狀態(tài)圖改進(jìn)一下。
狀態(tài)圖的建模首先應(yīng)該識(shí)別持有狀態(tài)的對(duì)象,然后再建立它的狀態(tài)圖,TCP網(wǎng)絡(luò)通信過程實(shí)際上涉及到了3個(gè)對(duì)象:
- 客戶端Client,
- 服務(wù)端Host,
- 網(wǎng)絡(luò)連接Connection 。
他們分別有各自的狀態(tài)圖,下面基于TCP的通信過程,對(duì)三個(gè)對(duì)象的狀態(tài)分別進(jìn)行建模。
Connection的狀態(tài)如下
這樣看起來和通信過程完全映射,好理解多了。
-
IT
+關(guān)注
關(guān)注
2文章
864瀏覽量
63518 -
建模
+關(guān)注
關(guān)注
1文章
305瀏覽量
60774 -
UML
+關(guān)注
關(guān)注
0文章
122瀏覽量
30860 -
開發(fā)者
+關(guān)注
關(guān)注
1文章
575瀏覽量
17011
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論