283.軟件體系結構描述

 

 

　4.6 使用「4+1」模型描述軟件體系結構

　　對於同一座建築，住戶、建築師、內部裝修人員和電氣工程師有各自的視角。這些視角反映了建築物的不一樣方面，但它們彼此都有內在的聯繫，並且合起來造成了建築物的整體結構。
　　軟件體系結構反映了軟件系統的總的結構，它和建築物同樣，存在不一樣的角度來反映系統的體系結構。
　　當面對一個複雜的系統時，必須從多個角度來考慮問題。在處理體系結構時咱們一般只考慮系統功能方面的需求，而實際上除了功能，物理分佈、過程通訊和同步等也必須在體系結構一級加以考慮。這些來自不一樣方面的需求就造成了軟件體系結構的不一樣視角。每種不一樣的視角說明了系統中不一樣角色或參與者(Stakeholder)各自所關注的焦點。每一個視角均可以當作是一幅軟件藍圖，同時具備本身的標記方法，能夠選擇本身的體系結構風格。
　　固然，全部視角並非徹底獨立的，不一樣視角之間的元素在必定的規則下是相關聯的。
　　從1990年開始，Rational公司的Philippe Kruchten對軟件體系結構的不一樣視角進行了專門的研究，並於1995年在IEEE提出了用於體系結構描述的「4+1」視圖模型(The 4+1 View Model of Architecture)。它們是邏輯視圖(Logical View)、過程視圖(Process View)、物理視圖(Physical View)、開發視圖(Development View)，另外加上場景(Scenarios)。「4+1」視圖模型爲理解複雜系統的軟件體系結構提供了一個簡單和易於理解的方式。它從 5個不一樣的角度來描述軟件，每一個角度都顯示了模型系統的一個具體方面。下面對該模型進行較詳細的
介紹。
　　「4+1」模型由5個視圖組成，如圖4-17所示。

圖4-17 「4+1」視圖模型
　　其中：
　　● 邏輯視圖：當採用面向對象的設計方法時，邏輯視圖便是對象模型。
　　● 過程視圖：描述系統的併發和同步方面的設計。
　　● 物理視圖：描述軟件到硬件之間的映射關係，反映系統在分佈方面的設計。
　　● 開發視圖：描述軟件在開發環境下的靜態組織結構。
　　對體系結構進行的描述是圍繞着以上4個視圖展開的。而後，經過選擇出的一些用例對體系結構加以說明。這些用例被稱作場景，它們構成了第5個視圖。實際上，體系結構在某種程度上是由場景演化而來的。
　　體系結構的概念在每一個視圖裏面均可以獨立應用。這就是說，能夠在每一個視圖裏面定義體系結構的各類組成元素，如構件、鏈接件等。對於不一樣的視圖，還能夠選擇不一樣的體系結構風格，所以在同一個系統結構中可使用多種風格。此外，在每一種視圖裏，咱們使用該視圖特定的符號。這避免了符號用法和意義的混亂。「4+1」視圖模型是一個十分通用的模型：可使用其餘的符號表示法，也可使用其餘的設計方法，尤爲是邏輯視圖和過程視圖的分解。
　　「4+1」模型實際上使得有不一樣需求的人員可以獲得他們對於軟件體系結構想要了解的東西。系統工程師先從物理視圖，而後從過程視圖靠近體系結構；最終使用者、客戶、數據專家從邏輯視圖看體系結構；項目經理、軟件配置人員從開發視圖看體系結構。
　　要指出的是，不是全部的軟件體系結構都須要完整的「4+1」視圖。沒有用的視圖在體系結構描述中能夠被省略，例如對於很是小的系統，邏輯視圖和開發視圖有可能很是類似，以致於沒有必要把它們分開描述。場景視圖在各類環境下都是有用的。
　　下面將分別討論這5種視圖，考察每種視圖所涉及的方面，所使用的符號表示，以及在描述和管理該視圖時要用到的工具。下文中，將以簡化了的專用自動交換分機系統和航空交通管制系統爲例進行討論。
4.6.1 邏輯視圖的體系結構：面向對象的分解
　　邏輯視圖主要支持功能需求——系統應當向用戶提供什麼樣的服務。從問題域出發，採用面向對象的方法，按照抽象、封裝、繼承的原則進行分解，獲得表明着系統的關鍵抽象表示的集合。這些抽象表示的具體形式就是對象和對象的類。這種分級不只是爲了功能分析，並且還擔負着在系統的各部分中肯定公共機制和設計元素的做用。
　　使用Rational/Booch方法，經過類圖(Class Diagram)和類模板(Class Template)來表示邏輯體系結構。類圖顯示了類的集合和它們的邏輯關係：關聯(Association)、組合(Composition)、使用(Usage)、繼承(Inheritance)等。類模板則着眼於每一個類的個體，強調類的主要操做，並肯定對象的關鍵特徵。當十分須要定義一個對象的內部行爲時，要使用狀態轉換圖(State Transition Diagram)，或者是狀態表(State Chart)。相關類的集合能夠歸到一塊兒，稱做類的種屬(Class Category)。
　　正如前面介紹的，「4+1」視圖模型是一個十分通用的模型。除了面向對象的方法，還可使用其餘形式的邏輯體系結構。例如，當所面對的應用具備很明顯的數據驅動的特徵時，可使用E-R圖。
　　1．邏輯視圖的符號表示法
　　邏輯體系結構的符號表示法(見圖4-18)是從Booch方法派生而來的。它被極大地簡化了，尤爲大量簡化了在這個設計階段做用不大的各類修飾，只考慮對於體系結構有重要意義的元素。在設計工具上，可使用Rational Rose等UML建模工具。公共的機制和服務在類設施(Class Utilities)中定義。

圖4-18 邏輯視圖的符號表示法
　　2．邏輯視圖的風格
　　邏輯視圖也能夠採用面向對象的風格。邏輯視圖設計的主要準則是，要設法在整個系統中保持一個單一的、連貫的對象模型，避免類和相關機制按照場地或處理器過早地分化。
　　3．邏輯視圖的例子
　　圖4-19(a)顯示了一個專用自動交換分機的例子。
　　專用自動交換分機用於在通訊終端之間創建鏈接。通訊終端多是電話機、中繼線(鏈接到中心室的線路)、專用線(專用自動交換分機和通常的交換分機之間的線路)、數據線、ISDN線等。不一樣的線路須要不一樣的線路接口卡的支持。線路控制器對象負責從線路接口卡接收信號，以及向它發送信號，並完成信號和一系列的事件(如開始、結束、計數等)之間的轉換。控制器還必須受到嚴格的實時要求的約束。

圖4-19 邏輯視圖舉例
(a) 專用自動交換分機的邏輯設計圖； (b) 航空交通管制系統的邏輯設計圖
　　爲了適應不一樣的接口，這個類有許多子類。終端對象負責維護終端的狀態，並表明所在的線路提供通訊服務。會話對象表明在一個對話中涉及的終端的集合。會話對象使用轉換服務(邏輯地址和物理地址之間的映射、路由等)和鏈接服務創建兩個終端之間的語音鏈接。
　　和前一個系統相比，航空交通管制系統是一個規模大得多的系統。圖4-19(b)中顯示的是一個包括8個類種屬(即類的分組)的航空交通管制系統的最頂層的類圖。
4.6.2 過程視圖的體系結構：過程分解
　　過程體系結構考慮的是一些非功能性的需求，諸如性能、可用性等。它所要面對的問題有併發、分佈、系統的完整性、容錯能力等。它還要考慮怎樣把過程體系結構與邏輯視圖體系結構的要點相適應——對某個對象的某個操做其實是在哪一個控制線程上發生的。
　　能夠把過程體系結構分爲幾個抽象層次來描述，每一個層次考慮不一樣的方面。在最高層次上，過程體系結構能夠被視爲一個邏輯網絡的集合。每一個獨立執行的邏輯網絡都是由通訊程序(即「過程」)構成的。這些邏輯網絡分佈在一個經過LAN或WAN鏈接起來的硬件資源集合上。多個邏輯網絡可能同時存在，並共享一樣的物理資源。例如，邏輯網絡的概念可用於區分在線處理系統和離線處理系統。
　　這裏所說的過程，是指構成一個可執行單元的一組任務。過程表明了在何種層次上過程體系結構能夠進行策略控制，如啓動、恢復、從新配置和關閉。
　　軟件被分爲獨立的任務的集合。每一個任務是一個獨立的控制線程，能夠在一個處理節點上獨立單獨調度。所以能夠將任務分爲主任務和輔任務。主任務是須要單獨解決的體系結構元素。輔任務是因爲實現緣由而在本地加入的附加任務(緩衝、超時等)，例如能夠將它們實現爲輕量級的線程。
　　主任務經過一套完善定義的任務間通訊機制進行通訊：同步的或異步的基於消息的通訊服務、遠程過程調用、時間廣播等。不該當假設通訊中的主任務處於同一個過程當中或處在同一個處理節點上。輔任務的通訊能夠採用共享內存的方式或其餘雙方約定的方式。
　　基於過程的體系結構設計圖能夠估計出消息流和過程負荷。
　　1．過程視圖的符號表示法
　　這裏介紹的過程體系結構符號表示法是從Booch爲Ada任務分配提出的符號表示法擴展而來的。與邏輯視圖的符號表示法相似，它也被極大地簡化了，只考慮對於體系結構有重要意義的元素，如圖4-20所示。

圖4-20 過程視圖的符號表示法
　　在輔助工具的選擇上，能夠考慮使用TRW提供的UNAS(Universal Network Achitecture Services)產品。它可用於把各類過程和任務構建並實現爲過程的邏輯網絡。UNAS裏面包含的一個工具SALE(Software Architecture Lifecycle Environment)支持這樣的符號表示法。SALE容許過程體系結構的圖形化描述，包括對可能的任務間通訊路徑的規格說明。而後，從這種規格說明能夠自動生成相應的Ada或C++語言源代碼。
　　2．過程視圖的風格
　　有多種風格適合過程體系結構。例如管道-過濾器、客戶/服務器及其變體(多客戶/單服務器、多客戶/多服務器等)。
　　3．過程視圖的例子
　　在圖4-21所示的例子中，全部的終端是由單一的一個終端過程處理的。這個終端過程由輸入隊列中的消息驅動。控制過程由3個任務組成，控制對象在其中之一上執行。低速循環任務掃描全部的非激活終端(200 ms)，它將全部變爲激活的終端放入高速循環掃描 (10 ms)的掃描列表中；高速循環掃描探測掃描列表裏終端的重要的狀態改變，並將這種改變傳輸給主控任務；主控任務解讀這種狀態改變並經過消息與相關終端通訊。這裏，控制過程內部的消息通訊是經過共享內存的方式實現的。

圖4-21 專用自動交換分機的過程設計圖
4.6.3 開發視圖的體系結構：子系統分解
　　開發視圖關注的是在軟件開發環境中軟件模塊的實際組織。軟件被打包成能夠由單個或少許程序員開發的各類小的部分：程序庫或子系統。子系統被組織成層次化的體系，每層爲上一層提供一個嚴密的、明肯定義的接口。
　　系統的開發體系結構用模塊圖和子系統圖來表示，在圖中能夠顯示出「導入」和「導出」關係。完整的開發體系結構只有在軟件系統的全部元素被識別出來以後才能被描述。控制開發體系結構的原則是：分割、編組、可視。
　　開發體系結構主要考慮的是內部需求，這些需求的目的是要使開發相關的活動更易於進行，如軟件管理、軟件複用、開發工具集所形成的約束、編程語言等。開發體系結構是許多開發活動的基礎，包括需求配置、團隊組織和工做分配、成本估算和成本規劃、項目進度監控、軟件可重用性和可移植性分析、軟件安全分析等。它是創建軟件產品線的基礎。
　　1．開發視圖的符號表示法
　　與前面相似，開發視圖的符號表示法採用Booch表示法的變體，而且只考慮對於體系結構有重要意義的元素，如圖4-22所示。
　　Rational公司的Apex Development Environment 支持對開發視圖的定義和實現，也支持上面描述的分層策略和對設計規則的執行。在Rational Rose中，能夠繪製模塊層和子系統層的開發體系結構圖，還能夠在逆向工程中從已經開發的源代碼(Ada或C++)中得出系統的開發體系結構圖。

圖4-22 開發視圖的符號表示法
　　2．開發視圖的風格
　　對於開發視圖，咱們建議採用分層風格，定義4～6層的子系統。每一層都有明肯定義的責任。設計規則是，某一層的子系統只能依賴於本層或其下層的子系統。這樣作的目的是使模塊間相互依賴而構成的複雜網絡最小化，並使得系統能夠採用逐層的策略完成釋放。
　　3．開發視圖的例子
　　圖4-23用5個層次表示了航空交通管制系統產品線的開發組織。此開發體系結構是與圖4-19(b)中描述的邏輯體系結構相對應的。
　　第一、2層是在軟件產品線中常見的分佈式系統基礎結構。這兩層獨立於應用域，並將上層系統遮蔽起來，防止其受到硬件平臺、操做系統、數據庫等變化的影響。在這兩層的基礎上，第3層增長了一個航空交通管制(ATC)框架，成爲一個用於特定應用領域的軟件系統結構。使用這一框架，第4層構造了一系列的功能模塊。第5層與用戶和產品相關，包括大多數的用戶界面與外部系統的接口。在這5層中，共分佈着72個子系統，每層大約包括10～50個模塊。

圖4-23 航空交通管制系統的5個層次
4.6.4 物理視圖的體系結構：從軟件到硬件的映射
　　物理體系結構主要考慮的是非功能性的系統需求，如系統的可用性、可靠性(容錯性)、性能(信息吞吐量)和可擴展性。軟件系統在計算機網絡的各個處理節點上運行。各類被肯定出的元素——網絡、過程、任務和對象——須要映射到各類節點上去，將用到不一樣的物理配置，有些用於開發和測試，有些用於不一樣場所或不一樣用戶。所以從軟件處處理節點的映射須要高度靈活，而且最小限度地影響其自己的源代碼。
　　1．物理視圖的符號表示法
　　圖4-24所示爲物理視圖的符號表示法。大型系統中的物理視圖可能很是凌亂。
　　TRW公司的UNAS容許使用者採用數據驅動的方式將過程體系結構映射到物理體系結構，並容許在不修改源代碼的狀況下對這種映射作出多種改動。

圖4-24 物理視圖的符號表示法
　　2．物理視圖的例子
　　圖4-25顯示了大型專用自動交換分機的一種可能的硬件配置。

圖4-25 專用自動交換分機的物理體系結構
4.6.5 場景視圖的體系結構：彙總
　　經過使用一些重要場景，4個視圖中的元素能夠協調地共同工做。儘管這些場景是一個小集合，可是它們很重要。場景是更通用的概念——用例的實例。從某種意義上講，場景是最重要的需求的抽象。場景的設計使用對象場景圖(Object Scenario Diagram)和對象交互圖來表示。
　　相對於其餘的4個視圖，場景視圖是多餘出來的(因此稱爲「4+1」)，可是它承擔着兩個任務：
　　(1) 在下面要講到的體系結構設計中，將以此視圖爲驅動來發現體系結構元素。
　　(2) 在體系結構設計結束後，此視圖承擔驗證和描述的角色。它不只用於書面記錄，而且是體系結構原型測試的起始點。
　　1．場景視圖的符號表示法
　　場景視圖的符號表示法中，構件的表示與邏輯視圖很是類似，可是鏈接件的表示使用過程視圖中的方法。注意，對象的實例用細實線表示。在工具的使用方面，和邏輯體系結構相似，可使用Rational Rose繪製和管理對象場景圖。
　　2．場景視圖的例子
　　圖4-26顯示了用於小型專用自動交換分機的場景的片斷。
　　(1) 小王的電話控制器檢測和驗證電話從掛機到摘機狀態的轉變，而且發送一個消息來喚醒相關的終端對象。
　　(2) 終端分配必定的資源，並通知控制器發出撥號音。
　　(3) 控制器收到所撥號碼並將它們發送給終端。
　　(4) 終端使用編號計劃分析號碼。
　　(5) 當一個有效的撥號序列進入時，終端打開一個會話。

圖4-26 場景的雛形——本地呼叫選擇階段
　　從以上分析可知，邏輯視圖和開發視圖描述系統的靜態結構，而進程視圖和物理視圖描述系統的動態結構。對於不一樣的軟件系統來講，側重的角度也有所不一樣。例如，對於管理信息系統來講，比較側重於從邏輯視圖和開發視圖來描述系統，而對於實時控制系統來講，則比較注重於從進程視圖和物理視圖來描述系統。
　　　4.7 使用UML描述軟件體系結構

4.7.1 UML簡介
　　1．UML的概念
　　UML(Unified Modeling Language)是一種統一建模語言，下面對它進行解釋。
　　統一：表示是一種通用的標準，它被OMG(Object Management Group)承認，成爲軟件工業界的一種標準。UML表述的內容能被各種人員所理解，包括客戶、領域專家、分析師、設計師、程序員、測試工程師及培訓人員等。他們能夠經過UML充分理解和表達本身所關注的那部份內容。
　　建模：即創建軟件系統的模型。爲說明建模的價值，Booch給出一個類比：蓋一個寵物窩棚、修一個鄉間別墅和建一座摩天大樓。創建一個簡單的系統，例如蓋一個寵物窩棚，模型無關緊要；創建一個比較複雜的系統，例如修一個鄉間別墅，模型的必要性增大；創建一個高度複雜的系統，例如建一座摩天大樓，模型必不可少。
　　語言：代表它是一套按照特定規則和模式組成的符號系統，它用半形式化方法定義，即用圖形符號、天然語言和形式語言相結合的方法來描述定義的。
2．UML的發展歷史
　　公認的面向對象建模語言出現於20世紀70年代中期，到了80年代末發展極爲迅速。據統計，1989年到1994年，面向對象建模語言的數量從不到10種增長到50多種。各位語言的創造者極力推崇本身的語言，並不斷地發展完善它。但因爲各類建模語言所固有的差別和優缺點，使得使用者不知道該選用哪一種語言。
　　其中比較流行的有Booch、Rumbaugh(OMT)、Jacobsom(OOSE)、Coad-Yourdon等方法。OMT擅長分析，Booch擅長設計，OOSE擅長業務建模。 Rumbaugh於1994年離開GE加入Booch所在的Rational公司，他們一塊兒研究一種統一的方法，一年後，Unified Method 0.8誕生，同年，Rational收購了Jacobson所在的Objectory AB公司。通過三年的共同努力，UML0.9和UML0.91於1996年相繼面世。
　　此後，UML的創始人Booch等邀請計算機軟件工程界的著名人士和著名的企業如IBM、HP、DEC、Microsoft、Oracle等對UML進行評論，提出修改意見。1997年1月，Rational公司向OMG遞交了UML1.0標準文本。1997年11月，OMG宣佈接受UML，認定爲標準的建模語言。UML目前還在不斷髮展和完善。
4.7.2 UML基本圖符
　　UML包含了一些圖形元素，在進行系統分析和設計時須要這些圖。UML經過提供這些圖，使得能夠經過多個視圖從不一樣角度來描述一個系統。
　　1．用例圖(Use Case Diagram)
　　用例(Use Case)是從用戶的觀點對系統行爲的一個描述。它從用戶角度搜集系統需求，這樣既可靠又不易遺漏需求。
這裏先舉一個簡單的例子，假設一我的使用洗衣機來洗衣服，用UML用例圖來描述洗衣過程如圖4-27所示。
　　其中，小人表示參與者(Actor)，它表明擬建系統外部和系統進行交互的某類人或系統；橢圓表明用例。用例定義一組相關的由系統執行的動做序列。

圖4-27 UML用例圖
　　2．類圖(Class Diagram)
　　一個類是一組具備相似屬性和共同行爲的事物。例如，屬於洗衣機類的事物都有諸如品牌(Brand Name)、型號(Model Name)、序列號(Serial Number)和容量(Capacity)等屬性，它們的行爲包括加衣物(Add Clothes)、加洗滌劑(Add Detergent)、取出衣物(Remove Clothes)等操做。
　　圖4-28是一個用UML表示法表示的洗衣機屬性和行爲的例子。矩形方框是UML中表示類的圖標，它被分爲3個區域：最上面是類名，中間是屬性，最下面是操做。類圖由這些類框和代表類之間關聯的連線所組成。

圖4-28 UML類圖標
　　3．對象圖(Object Diagram)
　　對象是一個類的實例，是具備具體屬性和行爲的一個具體事物。如洗衣機品牌爲海爾或小天鵝，一次最多洗滌重量爲5 kg。
　　圖4-29說明了如何用UML來表示對象。使用UML描述對象時和類圖相似，但在對象名下要加下劃線，對象名後加冒號加類名。

圖4-29 UML對象圖標
　　4．順序圖(Sequence Diagram)
　　類圖和對象圖表達的是系統的靜態結構。在一個運行的系統中，對象之間要發生交互，而且這些交互要經歷必定的時間。UML順序圖所表達的正是這種基於時間的動態交互。
　　仍以洗衣機爲例，洗衣機的構件包括一個注水的進水管(Water Pipe)、一個用來裝衣物的洗滌缸(Drum)和一個排水管(Drain)。這些構件也是對象。
　　當「洗衣服」這個用例被執行時，假設已完成了「加衣物」、「加洗滌劑」和「開機」操做，那麼應執行如下步驟：
(1) 經過進水管向洗滌缸中注水。
(2) 洗滌缸保持靜止狀態。
(3) 水注滿，中止注水。
(4) 洗滌缸往返旋轉15分鐘。
(5) 經過排水管排掉洗滌後的髒水。
(6) 從新開始注水。
(7) 洗滌缸繼續往返旋轉洗滌。
(8) 中止向洗衣機中注水。
(9) 經過排水管排掉漂洗衣物的水。
(10) 洗滌缸加快速度單方向旋轉5分鐘。
(11) 洗滌缸中止旋轉，洗衣過程結束。
　　圖4-30用一個順序圖說明了進水管、洗滌缸和排水管(由順序圖頂端的矩形圖標表明)之間隨時間變化所經歷的交互過程。
　　對象符號下方垂直的虛線，稱爲對象生存線。沿對象生存線上展開的細長矩形稱爲激活，表示該對象正在執行某個操做，矩形的長度表示執行操做的持續時間。
　　帶箭頭的水平實線表示發送消息，消息能夠發往其餘對象或自身對象。圖中對象之間發送的消息有6個，發往自身的消息有5個。 消息能夠是簡單的(Simple)、同步的(Synchronous)或異步的(Asynchronous)。消息的圖符能夠用圖4-31來表示。

圖4-30 UML順序圖

圖4-31 順序圖的消息圖符
　　5．協做圖(Collaboration Diagram)
　　系統的工做目標是由系統中各組成元素相互協做完成的，建模語言必須具有這種協做關係的表達方式。UML協做圖就是爲此目的設計的。圖4-32是協做圖的一個例子。該圖仍以洗衣機爲例，在洗衣機構件的類集中又增長了一個內部計時器(Internal Timer)。在通過一段時間後，內部計時器控制進水管中止注水，而後啓動洗滌缸往返旋轉。圖中的序號表明命令消息的發送順序，內部計時器先向進水管對象發送中止注水消息，後向洗滌缸對象發送往返旋轉消息。

圖4-32 UML協做圖
　　6．狀態圖(Statechart Diagram)
　　在任一給定的時刻，一個對象老是處於某一特定的狀態。一我的能夠是新生兒、嬰兒、兒童、少年、青年、中年或老年。一個電梯能夠處於上升、降低或中止狀態。一臺洗衣機可處於浸泡(Soak)、洗滌(Wash)、漂洗(Rinse)、脫水(Spin)或關機(Off)狀態。UML狀態圖如圖4-33所示，說明洗衣機能夠從一個狀態轉移到另外一個狀態。
　　狀態在圖中表述爲圓角矩形，有兩種比較特殊的狀態：初始狀態(實心圓點)和結束狀態(實心圓點外加一個圓圈)。只能有一個初始狀態，可能有多種結束狀態。

圖4-33 UML狀態圖
　　7．活動圖(Activity Diagram)
　　活動圖相似於流程圖，用於描述用例中的事件流結構。圖4-34顯示了順序圖中步驟4到步驟6之間按順序的UML活動圖。

圖4-34 UML活動圖
　　8．構件圖(Component Diagram)
　　構件圖和下一個要介紹的部署圖將再也不使用洗衣機做爲例子來作說明，由於它們和整個計算機系統密切相關。
　　用圖4-35來講明如何用UML表示軟件構件。構件是軟件系統的一個物理單元，例如數據表、可執行文件、動態連接庫、文檔等。

圖4-35 UML構件圖
　　9．部署圖(Deployment Diagram)
　　部署圖顯示了基於計算機系統的物理體系結構。它能夠描述計算機和設備，展現它們之間的鏈接，以及駐留在每臺機器中的軟件。每臺計算機用一個立方體來表示，立方體之間的連線表示這些計算機之間的通訊關係。圖4-36是部署圖的一個例子。

圖4-36 UML部署圖
　　10．其餘特徵圖
　　(1) 包(Package)。當須要將圖中的組織元素分組，或者在圖中說明一些類或構件是某個特定子系統的一部分時，能夠將這些元素組織成包。包的表示法如圖4-37所示。
　　(2) 註釋(Note)。註釋能夠做爲圖中某部分的解釋，其圖標是一個帶折角的矩形，矩形框中是解釋性文字，如圖4-38所示。
　　(3) 構造型(Stereotype)。構造型可讓用戶能使用現有的UML元素來定製新的元素。構造型用雙尖括號(Guillemets)括起來的一個名稱來表示，如圖4-39所示。
　　以上3種圖均可以用來組織和擴展模型圖的特徵。

圖4-37 包圖

圖4-38 註釋

圖4-39 構造型
4.7.3 UML的靜態建模機制
　　UML的靜態建模機制包括用例圖、類圖、對象圖、包、構件圖和部署圖。
　　1．用例圖
　　(1) 用例模型(Use Case Model)描述的是外部角色(Actor)所理解的系統功能。 用例模型適用於需求分析階段，它是通過系統開發者和用戶反覆討論後而創建的，說明了開發者和用戶對系統功能和需求規格達成的共識。
　　用例模型描述了待開發系統的功能需求，它將系統看做黑盒，從系統的外部用戶角度出發，對系統進行抽象表示。用例模型驅動了需求分析以後各階段的開發工做，不只在開發過程當中保證了系統全部功能的實現，並且被用於測試系統是否知足用戶的需求和驗證系統的有效性，從而影響到開發工做的各個階段和UML的各個模型。用例視圖是其餘視圖的核心和基礎，其餘視圖依靠用例視圖中所描述的內容來構造。
　　用例模型基本組成包括：用例、角色和系統。用例用於描述系統的功能，即從外部用戶的角度觀察系統應該支持的功能。用例宏觀描述了系統功能，幫助分析人員理解系統的行爲。每一個系統中的用例都具體說明系統所具備的基本功能。角色是與系統進行交互的外部實體，能夠是系統用戶，也能夠是與系統交互的任何其餘系統或硬件設備。系統邊界線之內的區域(即用例的活動區域)抽象表示系統可以實現的基本功能。
　　用例模型能夠由若干個用例圖組成。用例圖用於顯示若干角色以及這些角色與系統提供的用例之間的鏈接關係。一般一個實際的用例採用普通的文字描述，做爲用例符號的文檔性質。固然，實際的用例圖也能夠用活動圖描述。用例圖僅僅從角色使用系統的角度描述系統中的信息，也就是站在系統外部查看系統功能，它並不描述系統內部對該功能的具體操做方式。
　　(2) 用例(Use Case)。用例的表示法見圖4-27。從本質上講，一個用例是用戶與計算機之間的一次典型交互做用。在UML中，用例被定義成系統執行的一系列動做，動做執行的結果能被指定角色察覺到。
　　用例的特色以下：
　　● 用例捕獲某些用戶可見的需求，實現一個具體的用戶目標。
　　● 用例由角色激活，並提供確切的值給角色。
　　● 用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。
　　(3) 角色(Actor)。角色是與系統交互的人或事。所謂與系統交互，指的是角色向系統發送消息，從系統中接收消息，或是在系統中交換信息。只要使用用例，與系統互相交流的任何人或事都是角色。
　　角色是一個羣體概念，表示一類能使用某個功能的人或事，並非指某個個體。一個具體的個體在系統中能夠具備多種不一樣的角色。角色都有名字，它的名字反映了該角色的身份和行爲，可是不能將角色的名字表示成角色的某個實例，或表示成角色所需完成的功能。
　　角色與系統進行通訊的收、發消息機制，相似於面向對象編程中的消息機制。角色是啓動用例的前提條件。首先，角色發送消息給用例，當初始化用例後，用例再開始執行，在執行過程當中該用例也可能向一個或多個角色發送消息。
　　(4) 用例之間的關係，包括擴展和使用等關係。
　　① 擴展關係。若是一個用例中加入一些新的動做後構成另外一個用例，那麼這兩個用例之間的關係就是擴展關係。後者經過集成前者的一些行爲得來。前者一般稱爲通用化用例，後者常稱爲擴展用例。擴展用例能夠根據須要有選擇地集成通用化用例的部分行爲。
　　② 使用關係。一個用例使用另外一個用例時，這兩個用例之間就構成了使用關係。一般，能夠把用例中相同的行爲提取出來單獨作成一個用例，這個用例稱爲抽象用例。當某個用例使用該抽象用例時，就像這個用例包含了抽象用例的全部行爲。
　　2．類圖、對象圖和包
　　(1) 類圖。在面向對象建模技術中，將客觀世界的實體映射爲對象，並概括成類。類、對象和它們之間的關聯是面向對象技術中最基本的元素。系統的類模型和對象模型描述了系統的結構。在UML中，類和對象模型分別由類圖和對象圖表示。
　　類圖表示類和類之間的靜態關係。不一樣於數據模型，它不只顯示了信息的結構，同時還描述了系統的行爲。類圖是定義其餘圖的基礎，狀態圖、協做圖等在這個基礎上進一步描述了系統其餘方面的特性。
　　類圖是一種用類和它們之間的關係描述系統的圖示。一般，類用長方形表示，分爲上、中、下3個區域，如圖4-28所示。上面的區域內標識類的名字，中間的區域內標識類的屬性，下面的區域內標識類的操做(行爲)，這3部分做爲一個總體描述某個類。若是要描述有關約定規則，就有了額外的分欄。若是類圖中存在多個類時，類與類之間的關係能夠用表示某種關係的連線將它們鏈接起來。類圖的另外一種表示方法是用類的具體對象代替類，這種表示方法稱做對象圖。
　　類圖必須含有公有屬性或私有屬性。公有屬性用加號(+)表示，私有屬性用減號(-)表示，在屬性名稱的左側標識它們。當屬性名稱旁沒有標識任何符號時，則表示該屬性的可見性還沒有定義。類圖能夠指定屬性的默認值，這樣當建立該類的對象時，對象的屬性值便自動被賦以該默認值。
　　UML規定類的屬性的語法格式爲：
　　　可見性 屬性名：類型 = 默認值 {性質串}
其中，屬性名和類型是必需的。性質串列出該屬性全部可能的取值，是用戶對該屬性性質的約束說明，例如「{只讀}」說明該屬性是隻讀屬性。
　　類圖描述了類和類之間的靜態關係。在定義類以後，就能夠定義類之間的各類關係。
　　(2) 關係。類之間的關係一般有關聯、泛化(繼承)、依賴等。
　　關聯關係：關聯用於描述類與類之間的鏈接。由於對象是類的實例，因此類與類之間的關聯也就是其對象之間的關聯。雖然類與類之間有含義各不相同的多種鏈接方式，但外部表示形式類似，統稱爲關聯。關聯關係一般都是雙向的，即關聯的對象雙方彼此都能與對方通訊。也就是，當某兩個類的對象之間存在要互相通訊的關係時，這兩個類之間就存在關聯關係。
　　泛化關係：又稱繼承關係，是指一個類(稱爲通常元素、基類元素或父元素)的全部信息(屬性和操做)能被另外一個類(稱爲特殊元素或子元素)繼承。繼承某個類的類中不只能夠有屬於本身的信息，並且還擁有被繼承類中的信息。泛化的優勢是經過把通常的公共信息放在基類元素中，使得在處理具體狀況時只需定義該狀況的特殊信息便可，公共信息則從通用元素中繼承得來，從而加強了系統的靈活性、易維護性和可擴充性，大大縮短了系統的維護時間。
　　具備泛化關係的兩個類之間，繼承通用類全部信息的具體類稱爲子類，被繼承類稱爲父類。能夠從父類中繼承的信息有屬性、操做和全部的關聯關係。
　　(3) 對象圖。類圖表示類以及類和類之間的關係，對象圖則表示在某一時刻這些類的實例之間的具體關係。因爲對象是類的實例，所以，UML對象圖中的概念與類圖中的概念徹底一致，對象圖能夠幫助理解一個比較複雜的類圖，也能夠用於顯示類圖中的對象在某一點的鏈接關係。
　　對象的圖示方法與類的圖示方法幾乎同樣，主要差異在於對象的名字下面要加下劃線(見圖4-29)。
　　(4) 包。包是一種組合機制，把各類模型元素經過內在的語義連在一塊兒成爲一個總體，造成一個高內聚、低耦合的集合，UML中將這種分組機制稱爲包。構成包的模型元素稱爲包的內容。包一般用於對模型的組織管理，所以有時又將包稱爲子系統。
　　模型元素的分組方法能夠是任意的。在UML中，最有用和強調最多的分組原則是依賴。包圖主要顯示模型元素的包以及這些包之間的依賴關係，有時還顯示包和包之間的繼承關係和組成關係。
　　3．構件圖和部署圖
　　構件圖和部署圖顯示系統實現的一些特性，包括源代碼的靜態結構和運行時刻的實現結構。構件圖顯示代碼自己的結構，部署圖顯示系統運行時刻的結構。
　　(1) 構件圖。構件圖的表示法如圖4-35所示。構件圖顯示系統構件之間的依賴關係，如圖4-40所示。通常來講，系統構件就是一個實際文件，能夠是源代碼文件、二進制代碼和可執行文件等，能夠用來顯示編譯、連接或執行時構件之間的依賴關係。

圖4-40 構件圖
　　(2) 部署圖。部署圖描述系統硬件的物理拓撲結構以及在此結構上執行的系統。部署圖能夠顯示計算節點的拓撲結構和通訊路徑、節點上運行的系統構件、系統構件包含的邏輯單元(對象、類)等。部署圖經常用於幫助理解分佈式系統。
　　① 節點和鏈接。節點表明一個物理設備以及其上運行的系統。節點表示爲一個立方體，節點名放在左上角。與類和對象同樣，節點能夠用於表示類型和實例。當用該符號表示實例時，須要名字下面有一條下劃線。節點之間的連線表示系統之間進行交互的通訊路徑，稱爲鏈接。通訊類型放在鏈接旁邊的<< >>之間，表示所用的通訊協議或網絡類型。
　　② 構件和界面。在部署圖中，構件表明可執行的物理代碼模塊，它在邏輯上與類圖中的包或類對應。所以，部署圖中顯示運行時各個包或類在節點中的分佈狀況。在面向對象方法中，類和構件等元素並非全部的屬性和操做都對外可見。它們對外提供了可見操做和屬性，稱爲類和構件的界面。界面表示爲一頭是小圓圈的直線。
　　③ 對象。一個面向對象系統中能夠運行不少對象。由於構件能夠看作與包或類對應的物理代碼模塊，因此構件中應包含一些運行的對象。如圖4-36所示的部署圖中的對象與對象圖中的對象表示法一致。
4.7.4 UML的動態建模機制
　　在面向對象技術中，對象間的交互是經過在對象間傳遞消息完成的。在UML的全部動態圖(順序圖、協做圖、狀態圖、活動圖)中，消息被看成對象間的一種通訊表示方式。通常狀況下，當一個對象調用另外一個對象中的操做時，即完成了一次消息傳遞。當操做執行後，控制便返回到調用者。對象經過相互間的通訊(消息傳遞)進行合做，並在其生命週期中根據通訊的結果不斷改變自身的狀態。
　　在UML中，消息的圖形表示是用帶有箭頭的線段將消息發送者和接收者聯繫起來，箭頭的類型表示消息的類型，如圖4-30和圖4-31所示。
　　簡單消息(Simple Message)：表示普通的控制流。它描述控制是如何在對象間進行傳遞的，不考慮通訊的具體細節。這種消息類型主要用於通訊細節未知或不須要考慮通訊細節的場合。
　　同步消息(Synchronous Message)：表示嵌套的控制流。操做的調用即是一種典型的同步消息。調用者發出消息後必須等待消息返回，只有當處理消息的操做執行完畢後，調用者纔可繼續執行本身的操做。
　　異步消息(Asynchronous Message)：表示異步控制流。調用者發出消息後不用等待消息的返回便可繼續執行本身的操做。異步消息在實時系統中經常使用來描述其中的併發行爲。
　　1．順序圖
　　順序圖用來描述對象間的動態交互關係，側重體現對象間消息傳遞的時間順序。順序圖用橫座標軸表示對象，用縱座標軸表示時間。順序圖橫座標軸上的對象用一個帶有垂直虛線的矩形框表示，矩形框中寫有對象名和/或類名。垂直虛線是對象的生命線，用於表示在某段時間內對象是否存在。對象間的通訊用對象的生命線之間的水平消息線來表示。消息的箭頭表示消息的類型，如同步消息、異步消息或簡單消息。
　　若是收到消息，那麼對象就當即開始執行活動，即對象被激活了。激活用對象生命線上的細長矩形框表示。消息能夠用消息名稱和參數來表示。消息可帶有條件表達式，用以表示分支或決定是否發送消息。當條件表達式用於表示分支時，分支是互斥的，也就是說一次只能發送分支中的一個消息。
　　順序圖的左邊能夠有註釋，用以說明消息發送的時刻、描述動做的執行狀況以及約束信息等，如圖4-30所示。
　　2．協做圖
　　協做圖用於描述相互合做的對象間的交互和連接關係(連接是關聯的實例化)。儘管順序圖和協做圖都用來描述對象間的交互關係，但側重點並不同。順序圖強調交互的時間順序，而協做圖則強調交互對象間的靜態連接關係。
　　協做圖表示對象與對象間的連接以及連接間如何發送消息。協做圖中對象的外觀與順序圖中的同樣。對象間連接的表示方法相似於類圖中的關聯。經過連接上標以用消息串表示的消息(簡單、異步或同步消息)來表達對象間的消息傳遞。
　　(1) 連接。連接用於表示對象間的各類關係，協做圖中的各類連接關係與類圖中的定義相同，在連接的斷點位置能夠顯示對象的角色名和模板信息。
　　(2) 消息流。在協做圖的連接線上，可經過用消息串表示的消息來描述對象間的交互，如圖4-32所示。消息的箭頭指明消息的流動方向。消息串中包含了發送的消息、消息的參數、消息的返回值以及消息的序列號等信息。
　　(3) 對象的生命週期。若是一個對象在消息的交互中被建立，則可在對象名稱以後標以{new}。相似地，若是一個對象在交互期間被刪除，則可在對象名稱以後標以{destroy}。
　　3．狀態圖
　　狀態圖描述一個特定對象的全部可能狀態以及引發狀態轉移的事件。狀態圖由一系列狀態和狀態之間的轉移構成，經過狀態圖能夠表示單個對象在其生命週期中的行爲。
　　(1) 狀態。每一個對象都具備狀態，狀態是對象執行某個活動的結果。當發生某些事情後，結果將引發對象的狀態的變化。一般將這些引發對象狀態變化的事情稱爲「事件」。狀態圖能夠有一個起點(初態)和多個終點(終態)。狀態圖的起點用一個黑圓點來表示，終點用黑圓點外加一個圓表示，狀態用一個圓角矩形表示。
　　一個狀態能夠進一步細化爲多個子狀態，進一步細化的狀態稱做複合狀態。子狀態又可分爲兩種：「或子狀態」和「與子狀態」。或子狀態指在某一時刻僅可到達一個子狀態，與子狀態指在某一時刻可同時到達多個子狀態(稱爲併發子狀態)。具備併發子狀態的狀態圖稱爲併發狀態圖。
　　(2) 轉移。狀態圖中用狀態間帶箭頭的連線來表示狀態的轉移。狀態的變化一般由事件觸發，此時應在狀態轉移線上標出觸發轉移的事件表達式。若是狀態轉移線上未標明事件，則表示在源狀態的內部活動執行完畢後自動觸發轉移，如圖4-33所示。
　　通常狀況，狀態圖是對類圖的補充。實際上，並不須要爲全部的類畫狀態圖，僅須要爲那些有多個狀態且其行爲受外界環境的影響而發生改變的類畫狀態圖。
　　4．活動圖
　　活動圖能夠描述操做(類的方法)中完成的工做，也能夠描述用例和對象內部的工做過程。活動圖由狀態圖變化而來，但它們的目的有所不一樣。活動圖的主要目的是描述動做(將要執行的工做或活動)以及對象狀態變化的結果。在活動圖中，當一個活動結束後將當即進入下一個活動。但在狀態圖中，狀態的變遷可能須要由事件觸發。
　　(1) 活動和轉移。一項操做能夠用一系列相關的活動來描述。活動只有一個起始點，但結束點能夠有多個。一個活動能夠順序地跟在另外一個活動以後，這是簡單的順序關係。若是在活動圖中使用一個菱形的判斷標誌，則表達條件關係，判斷標誌能夠有多個輸入和輸出轉移，但在活動的運做中只觸發其中的一個輸出轉移。
　　活動圖也能夠表示併發行爲。在活動圖中，使用一個稱爲同步條的水平粗線能夠將一條轉移分爲多個併發執行的分支，或將多個轉移合爲一條轉移。此時，只有當輸入的轉移所有有效，同步條纔會觸發轉移，進而執行後面的活動。
　　(2) 泳道。泳道用縱向矩形框表示，放在該矩形框內均屬於某個泳道的全部活動；將對象和名稱放在矩形框的頂部，表示該對象對泳道中的活動負責。因此，經過泳道能夠將活動圖的邏輯描述與順序圖、協做圖的責任描述結合起來。
　　(3) 對象。在活動圖中能夠出現對象。對象能夠做爲活動的輸入或輸出，也能夠僅表示某一活動對對象的影響。若是對象是一個活動的輸入，那麼用一個從對象指向活動的虛線箭頭表示；若是對象是一個活動的輸出，那麼用一個從活動指向對象的虛線箭頭表示；若是僅表示對象受到某一活動的影響，則可用不帶箭頭的虛線來鏈接對象與活動。
　　(4) 信號。在活動圖中能夠表示信號的發送與接收，分別用發送符號和接收符號表示。發送符號和接收符號也可與消息的發送對象和消息的接收對象相連。
4.7.5 UML在軟件體系結構建模中的應用實例
　　下面以瀏覽器/服務器的軟件體系結構爲例子，用UML的建模機制對簡單的B/S體系結構進行建模，並說明該結構的構件交互及其交互模式的重用技術。
　　1．用UML對構件交互模式進行靜態建模
　　前面已經介紹UML的靜態建模機制包括用例圖、類圖、對象圖、包、構件圖和部署圖。在本節主要經過用例圖和部署圖兩種圖來對B/S體系結構進行靜態建模。
　　通過對B/S風格的軟件體系結構的分析可知，用戶經過瀏覽器與服務器端的交互用UML的部署圖來表示，如圖4-41所示。
　　瀏覽器是運行在客戶端的應用程序，與網絡上的服務器鏈接並請求獲取信息頁。當請求被知足，即瀏覽器獲得所請求的信息頁，鏈接就終止。瀏覽器指導怎樣經過HTTP與Web服務器通訊，以及怎樣顯示由Web服務器返回的格式化的信息(即以網頁的形式返回)。

圖4-41 瀏覽器與服務器交互的部署圖
　　服務器端的Web服務器接收網頁(靜態的HTML或服務器頁)的請求，根據請求，Web服務器可能啓動某個服務器端的處理(例如向數據庫服務器發出SQL查詢，而後將查詢結果返回)，再將獲得的信息以網頁(如HTML格式的網頁)的形式返回，在客戶端的瀏覽器中顯示出來。
　　在B/S體系結構中，有各類構件和鏈接件。構件分爲造成客戶瀏覽器和服務器端的構件，服務器端構件包括Web服務器端和數據庫服務器構件。
　　構件在這裏能夠看作是進行必定運算或其餘操做的體系結構的實體，而鏈接件是用於提供構件間交互的體系結構實體。經過構件和鏈接件加上由構件之間造成的交互，就造成了一個完整的體系結構。其中，構件間的信息交互有同步和異步兩種；而內部構件的通訊分爲同步、異步、代理和組通訊等。鏈接件不但表示一個簡單的交互操做(例如過程調用、共享變量的使用)，並且還表示複雜的交互(例如TCP/IP協議、數據庫使用協議、異步事件列表、網絡安全協議等)。
　　用UML的靜態建模機制與擴展機制的構造型對構件間交互進行靜態建模，如圖4-42所示，其中<<構件>>、<<資源>>和<<鏈接件>>是構造型的。

圖4-42 瀏覽器/服務器類圖
　　構件用來描述終端客戶的瀏覽器類和用於創建數據庫鏈接並負責數據庫存儲和檢索，響應請求數據查詢、處理的服務器類。
　　資源表明支持構件與鏈接件的通訊，而Internet就是一種資源，使得瀏覽器的鏈接件能夠經過網絡與服務器創建鏈接。
　　鏈接件能夠表示簡單的交互，也能夠表示複雜的交互，它隱藏構件間的內部交互細節(例如同步或異步信息的傳遞)。從圖4-42中描述可知，每個服務器構件與瀏覽器端構件間是一對多關係，瀏覽器與瀏覽器鏈接件和服務器與服務器鏈接件都是一對一的關係，而網絡資源與瀏覽器鏈接件、服務器鏈接件都是一對多的關係。
　　在B/S體系結構中，還可對鏈接件進一步細化爲瀏覽器鏈接件和異步客戶鏈接件。瀏覽器鏈接件也就是客戶鏈接件，能夠分爲同步客戶鏈接件和異步客戶鏈接件。異步客戶鏈接件是一個組合類，它由客戶消息輸入緩存類、客戶請求端類和客戶返回端類構成。用UML的類圖表示如圖4-43所示。
　　服務器鏈接件能夠分爲單線程和多線程服務器鏈接件。用UML類圖表示如圖4-44所示。

圖4-43 客戶鏈接件類圖

圖4-44 服務器鏈接件類圖
　　2．用UML對構件交互模式進行動態建模
　　如前面所講，UML中動態圖有順序圖、協做圖、狀態圖、活動圖。在本節中，主要利用協做圖對B/S體系結構的構件之間的交互進行建模。
　　圖4-45中顯示了客戶端瀏覽器與服務器端的構件的動態交互的協做圖。
　　首先，用戶經過瀏覽器向瀏覽器鏈接件發出消息請求，瀏覽器鏈接件將請求進行打包造成消息包(消息包中包含相應的服務參數)，再經過網絡資源(例如傳輸協議軟件)將消息包發給服務器鏈接件，服務器鏈接件接收器將消息包進行檢查，若是無錯，就將它提交給服務器，服務器根據請求包中的請求完成相應的處理或服務，並將服務結果裝配成一個響應包，再沿原路返回到瀏覽器端(中間服務器鏈接與瀏覽器鏈接件都將消息包進行處理)，最後提交給用戶。
　　前面已經提出，瀏覽器鏈接件有同步與異步之分，那麼它們如何請求與接收信息的程序？請參見圖4-46與圖4-47。

圖4-45 瀏覽器與服務器的協做圖

圖4-46 瀏覽器/服務器的單線程的同步消息通訊協做圖

圖4-47 瀏覽器/服務器的多線程服務器鏈接件的通訊協做圖
　　圖4-46描述了簡單的瀏覽器/服務器的同步消息通訊的協做圖。同步客戶構件經過靜態綁定與一個單線程服務器構件通訊。同步客戶構件與一個同步客戶鏈接件相連，單線程服務器構件與一個單線程服務器鏈接，其中客戶鏈接件與單線程服務器裏面都封裝着與服務器交互的細節。同步客戶鏈接件主要是整理打包消息後把消息包送給服務器鏈接件，同時也接收來自服務器的響應消息包，並解包後發給客戶瀏覽器。
　　若是是多線程服務器端則比較複雜些，因爲多線程服務器鏈接件與多線程服務器都是一個複雜的構件。客戶能夠靜態或動態地綁定與它同步或異步的通訊。當服務器鏈接件接收到消息包後就存入消息緩存中，而後由服務器端接收消息包(能夠是單線程也能夠是多線程)。
　　若是服務器是單線程，就將消息送給單線程服務器構件並等待響應；若是服務器端是多線程，就把消息放入分配器緩存中，再繼續處理下一個消息包。當分配器接收到來自緩存的消息後，就逐步地將消息隊列分配給空閒的服務器；服務器處理完畢，再打包造成消息響應包，按原路發送回給客戶，詳細狀況請見圖4-47。
　　在圖4-46中，當同步客戶變成異步客戶時，同步客戶鏈接件也相應地變成異步客戶鏈接件。它的通訊複雜得多，就如同多線程通訊比單線程通訊複雜同樣。主要的不一樣點是：異步客戶鏈接件在接收響應前還能夠處理其餘請求。異步客戶鏈接件採用了並行端，客戶請求端用來處理輸出消息，客戶返回端處理輸入的響應，響應處理完後存入客戶消息輸入緩存，供異步客戶構件讀取。其通訊協做圖如圖4-48所示。

圖4-48 異步客戶鏈接件的通訊協做圖