第11章軟件體系結(jié)構(gòu)

第4部分軟件生存期模型與軟件體系結(jié)構(gòu)第11章軟件體系結(jié)構(gòu)11.1軟件體系結(jié)構(gòu)的基本概念什么是體系結(jié)構(gòu)目前還沒有一個公認的關(guān)于軟件體系結(jié)構(gòu)的定義，許多專家學(xué)者從不同角度對軟件體系結(jié)構(gòu)進行了描述。Bass、Clements和Kazman給出了如下定義：“一個程序或計算機系統(tǒng)的軟件體系結(jié)構(gòu)是指系統(tǒng)的一個或者多個結(jié)構(gòu)。結(jié)構(gòu)中包括軟件的構(gòu)件、構(gòu)件的外部可見屬性以及它們之間的相互關(guān)系。外部可見屬性則是指軟件構(gòu)件提供的服務(wù)、性能、使用特性、錯誤處理、共享資源使用等?！边@一定義強調(diào)在任一體系結(jié)構(gòu)表述中“軟件構(gòu)件”的角色。DewaynePerry和A1exanderWo1f曾這樣定義：“軟件體系結(jié)構(gòu)是具有一定形式的結(jié)構(gòu)化元素，即構(gòu)件的集合，包括處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件。處理構(gòu)件負責(zé)對數(shù)據(jù)進行加工，數(shù)據(jù)構(gòu)件是被加工的信息，連接構(gòu)件把體系結(jié)構(gòu)的不同部分組合連接起來。”這一定義注重區(qū)分處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件。雖然軟件體系結(jié)構(gòu)的定義在變化，但其意圖是清晰的。體系結(jié)構(gòu)設(shè)計是一系列決策和基本原理的集合，這些決策的目標(biāo)在于開發(fā)高效的軟件體系結(jié)構(gòu)。在體系結(jié)構(gòu)設(shè)計中所強調(diào)的基本原理是系統(tǒng)的可理解性、可維護性和可擴展性。11.1軟件體系結(jié)構(gòu)的基本概念1．模式軟件設(shè)計模式是從軟件設(shè)計過程中總結(jié)出來的，是針對特定問題的解決方案。建筑師C.Alexander對模式給出的經(jīng)典定義是：每個模式都描述了一個在我們的環(huán)境中不斷出現(xiàn)的問題及該問題解決方案的核心。在軟件系統(tǒng)中，可以將模式劃分為以下3類。（1）體系結(jié)構(gòu)模式（architecturalpattern）：表達了軟件系統(tǒng)的基本結(jié)構(gòu)組織形式或者結(jié)構(gòu)方案，包含了一組預(yù)定義的子系統(tǒng)，規(guī)定了這些子系統(tǒng)的責(zé)任，同時還提供了用于組織和管理這些子系統(tǒng)的規(guī)則和向?qū)?。典型的體系結(jié)構(gòu)模式如OSI參考模型。11.1軟件體系結(jié)構(gòu)的基本概念體系結(jié)構(gòu)模式、風(fēng)格和框架的概念

（2）設(shè)計模式（designpattern）：為軟件系統(tǒng)的子系統(tǒng)、構(gòu)件或者構(gòu)件之間的關(guān)系提供一個精煉之后的解決方案，描述了在特定環(huán)境下，用于解決通用軟件設(shè)計問題的構(gòu)件以及這些構(gòu)件相互通信時的各種結(jié)構(gòu)。有代表性的設(shè)計模式是ErichGamma及其同事提出的23種設(shè)計模式。（3）慣用法（idiom）：是與編程語言相關(guān)的低級模式，描述如何實現(xiàn)構(gòu)件的某些功能，或者利用編程語言的特性來實現(xiàn)構(gòu)件內(nèi)部要素之間的通信功能。11.1軟件體系結(jié)構(gòu)的基本概念2．風(fēng)格風(fēng)格是帶有一種傾向性的模式。同一個問題可以有不同的解決問題的方案或模式，但我們根據(jù)經(jīng)驗，通常會強烈傾向于采用特定的模式，這就是風(fēng)格。每種風(fēng)格描述一種系統(tǒng)范疇，該范疇包括：（1）一組構(gòu)件（如數(shù)據(jù)庫、計算模塊）完成系統(tǒng)需要的某種功能；（2）一組連接件，它們能使構(gòu)件間實現(xiàn)“通信”、“合作”和“協(xié)調(diào)”；（3）約束，定義構(gòu)件如何集成為一個系統(tǒng)；（4）語義模型，它能使設(shè)計者通過分析系統(tǒng)的構(gòu)成成分的性質(zhì)來理解系統(tǒng)的整體性質(zhì)。11.1軟件體系結(jié)構(gòu)的基本概念體系結(jié)構(gòu)風(fēng)格定義了一個系統(tǒng)家族，即一個體系結(jié)構(gòu)定義一個詞匯表和一組約束。詞匯表中包含一些構(gòu)件和連接件類型，而這組約束指出系統(tǒng)是如何將這些構(gòu)件和連接件組合起來的。體系結(jié)構(gòu)風(fēng)格反映了領(lǐng)域中眾多系統(tǒng)所共有的結(jié)構(gòu)和語義特性，并指導(dǎo)如何將各個模塊和子系統(tǒng)有效地組織成一個完整的系統(tǒng)。對體系結(jié)構(gòu)風(fēng)格的研究和實踐為大粒度的軟件復(fù)用提供了可能。11.1軟件測試的基本概念11.1軟件測試的基本概念3．框架隨著應(yīng)用的發(fā)展和完善，某些帶有整體性的應(yīng)用模式被逐漸固定下來，形成特定的框架，包括基本構(gòu)成元素和關(guān)系?？蚣苁翘囟☉?yīng)用領(lǐng)域問題的體系結(jié)構(gòu)模式，框架定義了基本構(gòu)成單元和關(guān)系后，開發(fā)者就可以集中精力解決業(yè)務(wù)邏輯問題。在組織形式上，框架是一個待實例化的完整系統(tǒng)，定義了軟件系統(tǒng)的元素和關(guān)系，創(chuàng)建了基本的模塊，定義了涉及功能更改和擴充的插件位置。典型的框架例子有MFC框架和Struts框架。體系結(jié)構(gòu)的重要作用體現(xiàn)在以下三個方面：（1）體系結(jié)構(gòu)的表示有助于風(fēng)險承擔(dān)者（項目干系人）進行交流。（2）體系結(jié)構(gòu)突出了早期設(shè)計決策。（3）軟件體系結(jié)構(gòu)是可傳遞和可復(fù)用的模型。

11.1軟件測試的基本概念體系結(jié)構(gòu)的重要作用當(dāng)輸入數(shù)據(jù)經(jīng)過一系列的計算和操作構(gòu)件的變換形成輸出數(shù)據(jù)時，可以應(yīng)用這種體系結(jié)構(gòu)。管道/過濾器、批處理序列都屬于數(shù)據(jù)流風(fēng)格。管道/過濾器結(jié)構(gòu)如下圖所示。11.2典型的體系結(jié)構(gòu)風(fēng)格數(shù)據(jù)流風(fēng)格

管道/過濾器結(jié)構(gòu)

從上圖可看出，管道/過濾器結(jié)構(gòu)擁有一組被稱為過濾器（filter）的構(gòu)件，這些構(gòu)件通過管道（pipe）連接，管道將數(shù)據(jù)從一個構(gòu)件傳送到下一個構(gòu)件。每個過濾器獨立于其上游和下游的構(gòu)件而工作，過濾器的設(shè)計要針對某種形式的數(shù)據(jù)輸入，并且產(chǎn)生某種特定形式的數(shù)據(jù)輸出。如果數(shù)據(jù)流退化成為單線的變換，則稱為批處理序列（batchsequential）。這種結(jié)構(gòu)接收一批數(shù)據(jù)，然后應(yīng)用一系列連續(xù)的構(gòu)件（過濾器）變換它。11.2典型的體系結(jié)構(gòu)風(fēng)格管道/過濾器風(fēng)格具有以下優(yōu)點：（1）使得軟構(gòu)件具有良好的隱蔽性和高內(nèi)聚、低耦合的特點。（2）允許設(shè)計者將整個系統(tǒng)的輸入/輸出行為看成是多個過濾器的行為的簡單合成。（3）支持軟件復(fù)用。只要提供適合在兩個過濾器之間傳送的數(shù)據(jù)，任何兩個過濾器都可被連接起來。（4）系統(tǒng)維護和增強系統(tǒng)性能簡單。新的過濾器可以添加到現(xiàn)有系統(tǒng)中來；舊的可以被改進的過濾器替換掉。（5）允許對一些如吞吐量、死鎖等屬性的分析。（6）支持并行執(zhí)行。每個過濾器是作為一個單獨的任務(wù)完成，因此可與其他任務(wù)并行執(zhí)行。11.2典型的體系結(jié)構(gòu)風(fēng)格管道/過濾器風(fēng)格主要缺點如下：（1）通常導(dǎo)致進程成為批處理的結(jié)構(gòu)。這是因為雖然過濾器可增量式地處理數(shù)據(jù)，但它們是獨立的，所以設(shè)計者必須將每個過濾器看成一個完整的從輸入到輸出的轉(zhuǎn)換。（2）不適合處理交互的應(yīng)用。當(dāng)需要增量地顯示改變時，這個問題尤為嚴重。（3）因為在數(shù)據(jù)傳輸上沒有通用的標(biāo)準，每個過濾器都增加了解析和合成數(shù)據(jù)的工作，這樣就導(dǎo)致了系統(tǒng)性能下降，并增加了編寫過濾器的復(fù)雜性。11.2典型的體系結(jié)構(gòu)風(fēng)格在此類體系結(jié)構(gòu)中，存在以下3種子風(fēng)格。1．主程序/子程序體系結(jié)構(gòu)這種傳統(tǒng)的程序結(jié)構(gòu)將功能分解為一個控制層次，其中“主”程序調(diào)用一組程序構(gòu)件，這些程序構(gòu)件又去調(diào)用別的程序構(gòu)件，如下圖所示。這種結(jié)構(gòu)總體上為樹狀結(jié)構(gòu)，可以在底層存在公共模塊。11.2典型的體系結(jié)構(gòu)風(fēng)格調(diào)用—返回風(fēng)格

主程序/子程序體系結(jié)構(gòu)的優(yōu)點如下:（1）可以使用自頂向下，逐步分解的方法得到體系結(jié)構(gòu)圖，典型的拓撲結(jié)構(gòu)為樹狀結(jié)構(gòu)?；诙x—使用關(guān)系對子程序進行分解，使用過程調(diào)用作為程序之間的交互機制。（2）采用程序設(shè)計語言支持的單線程控制。其主要缺點如下:（3）子程序的正確性難于判斷。需要運用層次推理來判斷子程序的正確性，因為子程序的正確性取決于它調(diào)用的子程序的正確性。（4）子系統(tǒng)的結(jié)構(gòu)不清晰。通?？梢詫⒍鄠€子程序合成為模塊。11.2典型的體系結(jié)構(gòu)風(fēng)格

2．面向?qū)ο箫L(fēng)格

系統(tǒng)的構(gòu)件封裝了數(shù)據(jù)和必須應(yīng)用到該數(shù)據(jù)上的操作，構(gòu)件間通過消息傳遞進行通信與合作。與主程序/子程序的體系結(jié)構(gòu)相比，面向?qū)ο箫L(fēng)格中的對象交互會復(fù)雜一些。面向?qū)ο箫L(fēng)格與網(wǎng)絡(luò)應(yīng)用的需求在分布性、自治性、協(xié)作性、演化性等方面具有內(nèi)在的一致性。

面向?qū)ο箫L(fēng)格具有以下優(yōu)點:（1）因為對象對其他對象隱藏它的表示，所以可以改變一個對象的表示，而不影響其他對象。（2）設(shè)計者可將一些數(shù)據(jù)存取操作的問題分解成一些交互的代理程序的集合。11.2典型的體系結(jié)構(gòu)風(fēng)格其缺點如下:（1）為了使一個對象和另一個對象通過過程調(diào)用等進行交互，必須知道對象的標(biāo)識。只要一個對象的標(biāo)識改變了，就必須修改所有其他明確調(diào)用它的對象。（2）必須修改所有顯式調(diào)用它的其他對象，并消除由此帶來的一些副作用。例如，如果A使用了對象B，C也使用了對象B，那么，C對B的使用所造成的對A的影響可能是料想不到的。11.2典型的體系結(jié)構(gòu)風(fēng)格3．層次結(jié)構(gòu)層次結(jié)構(gòu)的基本結(jié)構(gòu)如下圖所示。在這種體系結(jié)構(gòu)中，整個系統(tǒng)被組織成一個分層結(jié)構(gòu)，每一層為上層提供服務(wù)，并作為下一層的客戶。11.2典型的體系結(jié)構(gòu)風(fēng)格這種風(fēng)格支持基于可增加抽象層的設(shè)計。允許將復(fù)雜問題分解成一個增量步驟序列的實現(xiàn)。由于每一層最多只影響兩層，同時只要給相鄰層提供相同的接口，允許每層用不同的方法實現(xiàn)，同樣為軟件復(fù)用提供了強大的支持。層次結(jié)構(gòu)具有以下優(yōu)點:（1）支持基于抽象程度遞增的系統(tǒng)設(shè)計，使設(shè)計者可以把一個復(fù)雜系統(tǒng)按遞增的步驟進行分解。（2）支持功能增強，因為每一層至多和相鄰的上下層交互，因此，功能的改變最多影響相鄰的內(nèi)外層。11.2典型的體系結(jié)構(gòu)風(fēng)格（3）支持復(fù)用。只要提供的服務(wù)接口定義不變，同一層的不同實現(xiàn)可以交換使用。這樣，就可以定義一組標(biāo)準的接口，從而允許各種不同的實現(xiàn)方法。其缺點如下:（1）并不是每個系統(tǒng)都可以很容易地劃分為分層的模式，甚至即使一個系統(tǒng)的邏輯結(jié)構(gòu)是層次化的，出于對系統(tǒng)性能的考慮，系統(tǒng)設(shè)計師不得不把一些低級或高級的功能綜合起來。（2）很難找到一個合適的、正確的層次抽象方法。11.2典型的體系結(jié)構(gòu)風(fēng)格數(shù)據(jù)庫系統(tǒng)、超文本系統(tǒng)和黑板系統(tǒng)都屬于倉庫風(fēng)格。在這種風(fēng)格中，數(shù)據(jù)倉庫（如文件或數(shù)據(jù)庫）位于這種體系結(jié)構(gòu)的中心，其他構(gòu)件會經(jīng)常訪問該數(shù)據(jù)倉庫，并對倉庫中的數(shù)據(jù)進行增加、修改或刪除操作。右圖為一個典型的倉庫風(fēng)格的體系結(jié)構(gòu)。11.2典型的體系結(jié)構(gòu)風(fēng)格倉庫風(fēng)格

上圖中,可把中心存儲庫變換成“黑板”，黑板構(gòu)件負責(zé)協(xié)調(diào)信息在客戶間的傳遞，當(dāng)用戶感興趣的數(shù)據(jù)發(fā)生變化時，它將通知客戶軟件。黑板系統(tǒng)的組成如下圖所示。黑板系統(tǒng)的傳統(tǒng)應(yīng)用是信號處理領(lǐng)域，如語音和模式識別。另一應(yīng)用是松耦合代理數(shù)據(jù)共享存取。11.2典型的體系結(jié)構(gòu)風(fēng)格以上所講的體系結(jié)構(gòu)模型是通用的模型，除了這些通用的模型以外，對于特定的應(yīng)用還需要特定的體系結(jié)構(gòu)模型。這些體系結(jié)構(gòu)模型稱為領(lǐng)域相關(guān)的體系結(jié)構(gòu)。有兩種領(lǐng)域相關(guān)的體系結(jié)構(gòu)模型：類屬模型（genericmodel）和參考模型（referencemodel）。11.3特定領(lǐng)域的軟件體系結(jié)構(gòu)類屬模型

類屬模型是從許多實際系統(tǒng)中抽象出來的一般模型，它封裝了這些系統(tǒng)的主要特征。例如，許多圖書館開發(fā)了自己的圖書館館藏/流通系統(tǒng)，若把它們的共同功能抽取出來并創(chuàng)建一個讓所有圖書館都認可的系統(tǒng)體系結(jié)構(gòu)模型，這就是類屬模型。類屬模型的一個最著名的例子是編譯器模型，由這個模型已開發(fā)出了數(shù)以千計的編譯器。

參考模型源于對應(yīng)用領(lǐng)域的研究，它描述了一個理想化的包含了系統(tǒng)應(yīng)具有的所有特征的軟件體系結(jié)構(gòu)。它是更抽象且是描述一大類系統(tǒng)的模型，并且也是對設(shè)計者有關(guān)某類系統(tǒng)的一般結(jié)構(gòu)的指導(dǎo)，如Rockwell和Gera所提出的軟件工廠參考模型。以上兩種不同類型的模型之間并不存在嚴格的區(qū)別，也可以將類屬模型視為參考模型。區(qū)別之一是類屬模型可以直接在設(shè)計中復(fù)用，而參考模型一般是用于領(lǐng)域概念間的交流和對可能的體系結(jié)構(gòu)做出比較。另外，類屬模型通常是經(jīng)過“自下而上”地對已有系統(tǒng)的抽象，而參考模型是“由上到下”地產(chǎn)生的。它們都是抽象系統(tǒng)表示法。11.3特定領(lǐng)域的軟件體系結(jié)構(gòu)參考模型

分布式系統(tǒng)的一個最簡單的模型是多處理器系統(tǒng)，系統(tǒng)由許多進程組成，這些進程可以在不同的處理器上并行運行，可以極大地提高系統(tǒng)的性能。由于大型實時系統(tǒng)對響應(yīng)時間要求較高，這種模型在大型實時系統(tǒng)中比較常見。大型實時系統(tǒng)需要實時采集信息，并利用采集到的信息進行決策，然后發(fā)送信號給執(zhí)行機構(gòu)。雖然，信息采集、決策制定和執(zhí)行控制這些進程可以在同一臺處理器上統(tǒng)一調(diào)度執(zhí)行，但使用多處理器能夠提高系統(tǒng)性能。11.4分布式系統(tǒng)結(jié)構(gòu)多處理器體系結(jié)構(gòu)

客戶機/服務(wù)器（client/server，C/S）體系結(jié)構(gòu)是基于資源不對等，且為實現(xiàn)共享而提出來的，由服務(wù)器、客戶機和網(wǎng)絡(luò)三部分組成。在C/S體系結(jié)構(gòu)中，客戶機可以通過遠程調(diào)用來獲取服務(wù)器提供的服務(wù)，因此，客戶機必須知道可用的服務(wù)器的名字及它們所提供的服務(wù)，而服務(wù)器不需要知道客戶機的身份，也不需要知道有多少臺服務(wù)器在運行。傳統(tǒng)的C/S體系結(jié)構(gòu)分為兩層。在這種體系結(jié)構(gòu)中，一個應(yīng)用系統(tǒng)被劃分為客戶機和服務(wù)器兩部分。典型的兩層C/S體系結(jié)構(gòu)如下圖所示。11.4分布式系統(tǒng)結(jié)構(gòu)客戶/服務(wù)器體系結(jié)構(gòu)

兩層C/S體系結(jié)構(gòu)可以有兩種形態(tài)：（1）瘦客戶機模型。在瘦客戶機模型中，數(shù)據(jù)管理部分和應(yīng)用邏輯都在服務(wù)器上執(zhí)行，客戶機只負責(zé)表示部分。11.4分布式系統(tǒng)結(jié)構(gòu)（2）胖客戶機模型。在這種模型中，服務(wù)器只負責(zé)對數(shù)據(jù)的管理?？蛻魴C上的軟件實現(xiàn)應(yīng)用邏輯和與系統(tǒng)用戶的交互。胖客戶機模型能夠利用客戶機的處理能力，比瘦客戶機模型在分布處理上更有效。但另一方面，隨著企業(yè)規(guī)模的日益擴大，軟件的復(fù)雜程度不斷提高，胖客戶機模型逐漸暴露出了以下缺點：開發(fā)成本較高。用戶界面風(fēng)格不一，使用繁雜，不利于推廣使用。軟件移植困難。軟件維護和升級困難。11.4分布式系統(tǒng)結(jié)構(gòu)為了解決以上問題，三層C/S體系結(jié)構(gòu)應(yīng)運而生，其結(jié)構(gòu)圖如下圖所示。與兩層C/S體系結(jié)構(gòu)相比，3層C/S體系結(jié)構(gòu)中增加了應(yīng)用服務(wù)器?？梢詫⒄麄€應(yīng)用邏輯駐留在應(yīng)用服務(wù)器上，而只有表示層存在于客戶機上。11.4分布式系統(tǒng)結(jié)構(gòu)三層C/S體系結(jié)構(gòu)將整個系統(tǒng)分成表示層、應(yīng)用邏輯層和數(shù)據(jù)層三個部分，其數(shù)據(jù)處理流程如下圖所示。11.4分布式系統(tǒng)結(jié)構(gòu)11.4分布式系統(tǒng)結(jié)構(gòu)（1）表示層：表示層是應(yīng)用系統(tǒng)的用戶界面部分，擔(dān)負著用戶與應(yīng)用程序之間的對話功能。它用于檢查用戶從鍵盤等輸入的數(shù)據(jù)，顯示應(yīng)用程序輸出的數(shù)據(jù)，一般采用圖形用戶界面（graphicuserinterface，GUI）。（2）應(yīng)用邏輯層：應(yīng)用邏輯層為應(yīng)用系統(tǒng)的主體部分，包含具體的業(yè)務(wù)處理邏輯。通常在功能層中包含有確認用戶對應(yīng)用和數(shù)據(jù)庫存取權(quán)限的功能以及記錄系統(tǒng)處理日志的功能。（3）數(shù)據(jù)層：數(shù)據(jù)層主要包括數(shù)據(jù)的存儲及對數(shù)據(jù)的存取操作，一般選擇關(guān)系型數(shù)據(jù)庫管理系統(tǒng)（RDBMS）。

瀏覽器/服務(wù)器（browser/server，B/S）風(fēng)格是三層體系結(jié)構(gòu)的一種實現(xiàn)方式，其具體結(jié)構(gòu)為瀏覽器/Web服務(wù)器/數(shù)據(jù)庫服務(wù)器。B/S體系結(jié)構(gòu)如下圖所示。11.4分布式系統(tǒng)結(jié)構(gòu)B/S體系結(jié)構(gòu)主要是利用不斷成熟的WWW瀏覽器技術(shù)，結(jié)合瀏覽器的多種腳本語言，用通用瀏覽器就實現(xiàn)了原來需要復(fù)雜的專用軟件才能實現(xiàn)的強大功能，并節(jié)約了開發(fā)成本。從某種程度上來說，B/S結(jié)構(gòu)是一種全新的軟件體系結(jié)構(gòu)。B/S體系結(jié)構(gòu)具有以下優(yōu)點：（1）基于B/S體系結(jié)構(gòu)的軟件，系統(tǒng)安裝、修改和維護全在服務(wù)器端解決。（2）B/S體系結(jié)構(gòu)還提供了異種機、異種網(wǎng)、異種應(yīng)用服務(wù)的聯(lián)機、聯(lián)網(wǎng)和統(tǒng)一服務(wù)的最現(xiàn)實的開放性基礎(chǔ)。

11.4分布式系統(tǒng)結(jié)構(gòu)與C/S體系結(jié)構(gòu)相比，B/S體系結(jié)構(gòu)也有許多不足之處。（1）B/S體系結(jié)構(gòu)缺乏對動態(tài)頁面的支持能力，沒有集成有效的數(shù)據(jù)庫處理功能。（2）采用B/S體系結(jié)構(gòu)的應(yīng)用系統(tǒng)，在數(shù)據(jù)查詢等響應(yīng)速度上，要遠遠地低于C/S體系結(jié)構(gòu)。（3）B/S體系結(jié)構(gòu)的數(shù)據(jù)提交一般以頁面為單位，數(shù)據(jù)的動態(tài)交互性不強，不利于在線事務(wù)處理（OLTP）應(yīng)用。11.4分布式系統(tǒng)結(jié)構(gòu)在客戶機/服務(wù)器模型中，客戶機和服務(wù)器的地位是不同的。為了消除客戶機與服務(wù)器之間的差別，提高系統(tǒng)的伸縮性以及有效地均衡負載，可采用分布式對象體系結(jié)構(gòu)來設(shè)計系統(tǒng)。

分布式對象的實質(zhì)是在分布式異構(gòu)環(huán)境下建立應(yīng)用系統(tǒng)框架和對象構(gòu)件，它將應(yīng)用服務(wù)分割成具有完整邏輯含義的獨立子模塊（我們稱之為構(gòu)件），各個子模塊可放在同一臺服務(wù)器或分布在多臺服務(wù)器上運行，模塊之間通過中間件互相通信。通常將這個中間件稱為軟件總線或?qū)ο笳?1.4分布式系統(tǒng)結(jié)構(gòu)分布式對象體系結(jié)構(gòu)

求代理，它的作用是在對象之間提供一個無縫接口。分布式對象體系結(jié)構(gòu)如下圖所示。11.4分布式系統(tǒng)結(jié)構(gòu)

分布式對象技術(shù)的應(yīng)用目的是為了降低主服務(wù)器的負荷、共享網(wǎng)絡(luò)資源、平衡網(wǎng)絡(luò)中計算機業(yè)務(wù)處理的分配，提高計算機系統(tǒng)協(xié)同處理的能力，從而使應(yīng)用的實現(xiàn)更為靈活。分布式對象技術(shù)的基礎(chǔ)是構(gòu)件。構(gòu)件是一些獨立的代碼封裝體，在分布計算的環(huán)境下可以是一個簡單的對象，但大多數(shù)情況下是一組相關(guān)的對象組合體，提供一定的服務(wù)。分布式環(huán)境下，構(gòu)件是一些靈活的軟件模塊，它們可以位置透明、語言獨立和平臺獨立地互相發(fā)送消息，實現(xiàn)請求服務(wù)。構(gòu)件之間并不存在客戶機與服務(wù)器的界限，接受服務(wù)者扮演客戶機的角色，提供服務(wù)者就是服務(wù)器。當(dāng)前主流的分布式對象技術(shù)規(guī)范有OMG的CORBA、Microsoft公司的.NET和Sun公司的J2EE。它們都支持服務(wù)端構(gòu)件的開發(fā)，都有其各自的特點。11.4分布式系統(tǒng)結(jié)構(gòu)代理可以用于構(gòu)建帶有隔離組件的分布式軟件系統(tǒng)，該軟件通過遠程服務(wù)調(diào)用進行交互。代理者負責(zé)協(xié)調(diào)通信，諸如轉(zhuǎn)發(fā)請求以及傳遞結(jié)果和異常等。1991年，OMG基于面向?qū)ο蠹夹g(shù)，給出了以對象請求代理（ORB）為中心的分布式應(yīng)用體系結(jié)構(gòu)，如下圖所示。11.4分布式系統(tǒng)結(jié)構(gòu)代理

在OMG的對象管理結(jié)構(gòu)中，ORB是一個關(guān)鍵的通信機制，它以實現(xiàn)互操作性為主要目標(biāo)，處理對象之間的消息分布。在ORB之上有4個對象接口：（1）對象服務(wù)：定義加入ORB的系統(tǒng)級服務(wù)，如安全性、命名和事務(wù)處理，它們是與應(yīng)用領(lǐng)域無關(guān)的。（2）公共設(shè)施：水平級的服務(wù)，定義應(yīng)用程序級服務(wù)。（3）領(lǐng)域接口：面向特定的領(lǐng)域。（4）應(yīng)用接口：面向指定的現(xiàn)實世界應(yīng)用。是指供應(yīng)商或用戶借助于ORB、公共對象服務(wù)及公共設(shè)施而開發(fā)的特定產(chǎn)品。11.4分布式系統(tǒng)結(jié)構(gòu)MVC框架即模型—視圖—控制器（model-view-controller）框架，它強調(diào)將用戶輸入、數(shù)據(jù)模型和數(shù)據(jù)表示的方式分開設(shè)計，一個交互式應(yīng)用系統(tǒng)由模型、視圖和控制器3個部件組成，分別對應(yīng)于內(nèi)部數(shù)據(jù)、數(shù)據(jù)表示和輸入/輸出控制部分，其結(jié)構(gòu)如下圖所示。

11.5體系結(jié)構(gòu)框架MVC框架

11.5體系結(jié)構(gòu)框架MVC框架1.模型對象模型對象獨立于外在顯示內(nèi)容和形式，代表應(yīng)用領(lǐng)域中的業(yè)務(wù)實體和業(yè)務(wù)規(guī)則，是整個模型的核心。模型對象的變化通過事件處理通知視圖和控制器對象。2.視圖對象視圖對象代表GUI對象，并且以用戶需要的格式表示模型狀態(tài)，是交互系統(tǒng)與外界的接口。視圖對象可以包含子視圖，子視圖用于顯示模型的不同部分。通常，每個視圖對象對應(yīng)一個控制器對象。11.5體系結(jié)構(gòu)框架3.控制器對象控制器對象代表鼠標(biāo)和鍵盤事件。它處理用戶的輸入行為并給模型發(fā)送業(yè)務(wù)事件，再將業(yè)務(wù)事件解析為模型應(yīng)執(zhí)行的動作；同時，模型的更新與修改也將通過控制器來通知視圖，從而保持各個視圖與模型的一致性。

MVC的處理過程為：首先控制器接收用戶的請求，并決定應(yīng)該調(diào)用哪個模型來進行處理；然后模型用業(yè)務(wù)邏輯來處理用戶的請求并返回數(shù)據(jù)；最后控制器用相應(yīng)的視圖格式化模型返回的數(shù)據(jù)，并通過表示層呈現(xiàn)給用戶。其中，模型是核心數(shù)據(jù)和功能，視圖只關(guān)心顯示數(shù)據(jù)，控制只關(guān)心用戶輸入，這種結(jié)構(gòu)由于將數(shù)據(jù)和業(yè)務(wù)規(guī)則從表示層分開，因此可以最大化地重用代碼。

11.5體系結(jié)構(gòu)框架J2EE的核心體系結(jié)構(gòu)就是在MVC框架的基礎(chǔ)上進行擴展得到的，如下圖所示。11.5體系結(jié)構(gòu)框架J2EE體系結(jié)構(gòu)框架

J2EE的核心體系結(jié)構(gòu)框架

客戶層：用戶通過客戶層與系統(tǒng)交互。該層可以是各種類型的客戶端。例如，可編程客戶端（如基于JavaSwing的客戶端或applet），純Web瀏覽器客戶端，WML移動客戶端等。資源層：資源層可以是企業(yè)數(shù)據(jù)庫，電子商務(wù)解決方案中的外部企業(yè)系統(tǒng)，或者是外部SOA服務(wù)。數(shù)據(jù)可以分布在多個服務(wù)器上。從上圖可看出，J2EE模型是分層結(jié)構(gòu)，中間的3層（表示層，業(yè)務(wù)層，集成層）包含應(yīng)用程序構(gòu)件，客戶層和資源層處于應(yīng)用程序的外圍。

11.5體系結(jié)構(gòu)框架表示層：也稱為Web層或服務(wù)器端表示層，用戶通過表示層來訪問應(yīng)用程序。在基于Web的應(yīng)用系統(tǒng)中，表示層由用戶界面代碼和運行于Web服務(wù)器或應(yīng)用服務(wù)器上的過程組成。參考MVC框架，表示層包括視圖構(gòu)件和控制器構(gòu)件。業(yè)務(wù)層：業(yè)務(wù)層包含表示層中的控制器構(gòu)件沒有實現(xiàn)的一部分應(yīng)用邏輯。它負責(zé)確認和執(zhí)行企業(yè)范圍內(nèi)的業(yè)務(wù)規(guī)則和事務(wù)，并管理從資源層加載到應(yīng)用程序高速緩存中的業(yè)務(wù)對象。集成層：集成層負責(zé)建立和維護與數(shù)據(jù)源的連接。例如，通過JDBC與數(shù)據(jù)庫進行通信，利用Java消息服務(wù)（JMS）與外部系統(tǒng)聯(lián)合。11.5體系結(jié)構(gòu)框架1．PCMEF框架表示—控制—中介者—實體—基礎(chǔ)（presentation-control-mediator-entity-foundation，PCMEF）是一個垂直層次的分層體系結(jié)構(gòu)框架。每一層是可以包含其他包的包。PCMEF框架包含4層：表示層、控制層、領(lǐng)域?qū)雍突A(chǔ)層。領(lǐng)域?qū)影瑑蓚€預(yù)定義包：實體（entity）包和中介者（mediator）包。

PCMEF框架中包的依賴性主要是向下依賴性。表示層依賴于控制層，控制層依賴于領(lǐng)域?qū)?，中介者包依賴于實體包和基礎(chǔ)層,如下圖所示。

PCMEF與PCBMER框架

11.5體系結(jié)構(gòu)框架表示層:包含定義GUI對象的類?？刂茖?處理表示層的請求，負責(zé)大多數(shù)程序邏輯、算法、主要計算以及為每個用戶維持會話狀態(tài)。

領(lǐng)域?qū)?其實體包處理控制請求,中介者包用于創(chuàng)建一個協(xié)調(diào)實體類和基礎(chǔ)類的通信通道。基礎(chǔ)層:負責(zé)與數(shù)據(jù)庫和Web服務(wù)的所有通信。

11.5體系結(jié)構(gòu)框架PCMEF框架

2.PCBMER框架

PCBMER框架由PCMEF框架擴展而成,代表著表示—控制器—Bean—中介者—實體—資源（presentation-control-bean-mediator-entity-resource，PCBMER）。其核心體系結(jié)構(gòu)框架如右圖所示。

11.5體系結(jié)構(gòu)框架PCBMER的核心框架

在上圖中，把層表示為UML包（子系統(tǒng)，層），帶箭頭的虛線表示依賴關(guān)系。例如，表示層依賴控制器層和bean層，控制器層依賴bean層。PCBMER的層次不是嚴格線性的，上層可以依賴多個相鄰下層。bean層：表示那些預(yù)先確定要呈現(xiàn)在用戶界面上的數(shù)據(jù)類和值對象。除了用戶輸入外，bean數(shù)據(jù)由實體對象（實體層）創(chuàng)建。表示層：表示屏幕以及呈現(xiàn)bean對象的UI對象?？刂破鲗樱罕硎緫?yīng)用邏輯。實體層：響應(yīng)控制器和中介者。中介者層：建立了充當(dāng)實體類和資源類媒介的通信管道。資源層：負責(zé)所有與外部持久數(shù)據(jù)資源（數(shù)據(jù)庫、Web服務(wù)等）的通信。

11.5體系結(jié)構(gòu)框架在UML中，體系結(jié)構(gòu)建模是以結(jié)點、構(gòu)件、包、子系統(tǒng)等概念為中心的。另外，UML還可以通過給類圖增加設(shè)計約束支持體系結(jié)構(gòu)建模。所采用的主要形式是在類及其他模型中增加依賴關(guān)系。依賴是體系結(jié)構(gòu)框架的基礎(chǔ)，它還決定體系結(jié)構(gòu)的復(fù)雜性。體系結(jié)構(gòu)設(shè)計描述了建立計算機系統(tǒng)所需的數(shù)據(jù)結(jié)構(gòu)和程序構(gòu)件。一個好的體系結(jié)構(gòu)設(shè)計要求軟件模塊的分層及編程標(biāo)準的執(zhí)行。在面向?qū)ο筌浖?，常見的軟件模塊有類、接口、包和構(gòu)件。在設(shè)計階段我們往往關(guān)注類、接口和包，而在實現(xiàn)階段則關(guān)注構(gòu)件，而在部署階段則關(guān)注構(gòu)件的部署，也就是將構(gòu)件部署在哪些結(jié)點上。11.6體系結(jié)構(gòu)建模1.類

在面向?qū)ο蟮某绦蛟O(shè)計中，類和接口是程序的基本組成單元。一個典型程序需要界面類專門負責(zé)表示用戶界面信息，需要數(shù)據(jù)庫類負責(zé)與數(shù)據(jù)庫進行交互，需要有業(yè)務(wù)邏輯類負責(zé)算法計算等。在計算機程序中，要設(shè)計和實現(xiàn)的所有類都具有唯一的名字，在不同的階段或從不同的角度可以將它們稱為設(shè)計類、實現(xiàn)類、系統(tǒng)類、應(yīng)用類等。

11.6體系結(jié)構(gòu)建模類及其依賴性

2．繼承依賴性

依賴性管理中最棘手的問題是由于繼承所引起的依賴性。繼承是一種在父類和子類之間共享屬性和行為的方式，所以運行時可以用一個子類對象代替其父類對象。程序中凡是使用父類對象的地方，都可以用子類對象來代替。一個子類對象是一種特殊的父類對象，它繼承父類的所有特征，同時它又可以覆蓋父類的方法，從而改變從父類繼承的一些特征，并可以在子類中增加一些新的功能。這樣，從客戶的角度看，在繼承樹中為請求提供服務(wù)的特定對象不同，系統(tǒng)的運行行為可能會有所不同。11.6體系結(jié)構(gòu)建模（1）多態(tài)繼承根據(jù)為請求提供服務(wù)的對象不同可以得到不同的行為，這種現(xiàn)象稱為多態(tài)。在運行時對類進行實例化，并調(diào)用與實例化對象相應(yīng)的方法，稱為動態(tài)綁定、后期綁定或運行時綁定。相應(yīng)地，如果方法的調(diào)用是在編譯時確定的，則稱為是靜態(tài)綁定、前期綁定或編譯時綁定。多態(tài)并不是伴隨著繼承而出現(xiàn)。如果在子類中不覆蓋父類中的任何方法，就不會產(chǎn)生多態(tài)行為。很明顯，繼承會帶來類和方法之間的依賴性。繼承帶來的依賴性有編譯時繼承依賴性和運行時繼承依賴性。11.6體系結(jié)構(gòu)建模11.6體系結(jié)構(gòu)建模①編譯時繼承依賴性右圖所示的例子說明了一棵樹中類之間的編譯時依賴性。在這個例子中，B繼承A，但沒有覆蓋A中的方法do1()。因此，B和A之間沒有運行時繼承依賴性。也就是說，由于編譯時依賴性的存在，A中do1()方法的任何變化，都會被B在編譯時（靜態(tài)地）繼承。一般來說，所有的繼承都會引入編譯時依賴性。依賴性是可傳遞的，也就是說，如果C依賴B，B依賴A，那么C也依賴A。②運行時繼承依賴性

下圖舉例說明了在一棵繼承樹中涉及客戶對象訪問類服務(wù)的運行時繼承依賴性。圖中類B的do1()方法是從父類A繼承來的，因此Test與B沒有運行時繼承依賴性，只是一個靜態(tài)依賴性，通過從Test到A的關(guān)聯(lián)來表明。如果在doTest方法中調(diào)用的是do2()方法，或者在B中覆蓋了A的do1()方法，則從Test到A和B就會存在運行時依賴性。11.6體系結(jié)構(gòu)建模（2）無多態(tài)繼承使用繼承最簡單的方式是子類不覆蓋從父類繼承來的方法，這樣就不存在多態(tài)性繼承問題。雖然無多態(tài)的繼承有時并不是十分有用，但理解和管理起來是最容易的。（3）擴展繼承和約束繼承

擴展繼承是指子類繼承父類的屬性，并且提供額外屬性來增強類定義。子類是父類的一種，如果子類覆蓋了父類的方法，那么被覆蓋的方法應(yīng)該實現(xiàn)該方法的定義，并且能夠在子類的語境中工作。當(dāng)一個類覆蓋了繼承來的方法，并對一些繼承來的功能進行了限制，這時就產(chǎn)生了約束繼承。這時，子類不再是父類的一種。有時，限制會造成繼承方法的完全禁止。當(dāng)方法的實現(xiàn)是空時，就會發(fā)生這種情況。11.6體系結(jié)構(gòu)建模3．交互依賴性交互依賴性也稱為方法依賴性，是通過消息連接產(chǎn)生的。如下圖所示。11.6體系結(jié)構(gòu)建模圖中，CActioner使用方法do1(

)來發(fā)送一條消息do3(

)給EEmployee，因此，do1()依賴于do3()。依賴性向上傳遞給所屬的類，因此，CActioner依賴于EEmployee。類似地，EOutMessage的do2()調(diào)用EEmployee的方法do3()，因此，EOutMessage依賴于EEmployee。11.6體系結(jié)構(gòu)建模1．接口在UML2.0中，接口是不可直接實例化的特性集合的聲明，即其對象不能直接實例化，需要通過類來實現(xiàn)，實現(xiàn)接口的類需要實現(xiàn)接口中聲明的方法。UML2.0對流行編程語言中的接口概念進行了擴展。接口中不僅可以聲明操作，還可以聲明屬性。由于允許在接口中存在屬性，因此，在接口之間或者接口和類之間可能會產(chǎn)生關(guān)聯(lián)。用另一個接口或類作為屬性的類型可以表示關(guān)聯(lián)。在UML2.0中，可以通過關(guān)聯(lián)實現(xiàn)從接口接口及其依賴性

11.6體系結(jié)構(gòu)建模到類的導(dǎo)航。但在Java中是無法實現(xiàn)的，因為Java規(guī)定接口中的數(shù)據(jù)元素必須是常量。接口與抽象類有相似之處，抽象類是至少包含一個沒有實現(xiàn)的方法的類，如果在一個抽象類中所有的方法都沒有實現(xiàn)，則稱其為純抽象類，從這一點上，接口和純抽象類似乎沒有區(qū)別。但實際上，接口和抽象類還是有著本質(zhì)的區(qū)別。在只支持單繼承的語言中，一個類只能有一個直接父類，但是卻可以實現(xiàn)多個接口。11.6體系結(jié)構(gòu)建模2．實現(xiàn)依賴性一個類可以實現(xiàn)多個接口，由類實現(xiàn)的接口集合稱為該類的供給接口。在UML2.0中，將一個類和該類實現(xiàn)的接口之間的依賴性稱為實現(xiàn)依賴性。右圖所示為實現(xiàn)依賴性的UML符號，在箭頭末端的類實現(xiàn)了箭頭所指向的接口。從圖中可以看到，Class1實現(xiàn)了Interface1接口和Interface2接口，而Class2只實現(xiàn)了Interface2接口。11.6體系結(jié)構(gòu)建模3．使用依賴性一個接口可以為其他類或接口提供服務(wù)，同時也可能需要其他接口的服務(wù)。一個接口所需要的其他接口所提供的服務(wù)稱為這個類的需求接口。需求接口詳細說明一個類或接口需要的服務(wù)，從而可以為其客戶提供服務(wù)。在UML2.0中，通過類（接口）和它所需接口之間的依賴關(guān)系來說明需求接口，這稱為使用依賴性。下圖所示為使用依賴性的UML符號，在箭頭尾部的類或接口使用在箭頭頭部的接口。Class1使用Interface1，Interface1使用Interface2。在Java語言中，不允許接口之間的使用，只允許接口間的擴展繼承。

11.6體系結(jié)構(gòu)建模Class1包含方法do1()，而do1()調(diào)用操作op1()。在靜態(tài)代碼中，并不清楚需求接口的哪個實現(xiàn)提供了所需的服務(wù)，可以是實現(xiàn)Interface1的任何一個類實例。當(dāng)Class1的一個執(zhí)行實例設(shè)置數(shù)據(jù)成員myInterface的值時，具體實例才能確定，從而可以引用具體類的一個具體對象。

11.6體系結(jié)構(gòu)建模1.包

包（package）又可稱為層或子系統(tǒng)，是表示組織類的一種方式，用于劃分應(yīng)用程序的邏輯模型。包是高度相關(guān)的類的聚合，這些類本身是內(nèi)聚的，但相對于其他聚合來說又是松散耦合的。

包可以嵌套。外層包可以直接訪問包括在它的嵌套包中的任何類。包還可以導(dǎo)入其他包，例如，在包A中導(dǎo)入了包B，這意味著包A或者包A的元素可以引用包B或者包B的元素。因此，雖然一個類只屬于一個包，但是它可以被導(dǎo)入其他包。包的導(dǎo)入操作會引入包之間的依賴性以及它們的元素之間的依賴性。11.6體系結(jié)構(gòu)建模包及其依賴性

下圖為UML包的例子。一個包可以不暴露任何成員，也可以明確標(biāo)明它所包含的成員，或者用符號“”來表示。圖中，包B擁有類X，包C擁有包D，包E擁有包F，包F擁有類Y和類Z。11.6體系結(jié)構(gòu)建模如果包A的一些成員在某種程度上引用了包B的某些成員（包A導(dǎo)入了包B的一些成員），這隱含著雙重含義。包B的變化可能會影響包A，通常需要對包A重新進行編譯和測試。包A只能和包B一起使用。2．包依賴性本質(zhì)上，兩個包之間的依賴性來自于兩個包中類之間的依賴性。類之間的循環(huán)依賴性是個特別棘手的問題，好在大多數(shù)情況下可以通過重新設(shè)計避免循環(huán)依賴性。包之間循環(huán)依賴的例子如下圖所示。11.6體系結(jié)構(gòu)建模通過在上圖中增加新包可以消除包之間的循環(huán)依賴性。方法為：在第1個例子中將包B依賴的包A的元素從包A中分離出來，組成包C，使得包B不再依賴包A，而是依賴包C；11.6體系結(jié)構(gòu)建模在第2個例子中，將包F所依賴的包D中的元素從包D中分離出來，組成包G。消除循環(huán)依賴性后如下圖所示。11.6體系結(jié)構(gòu)建模在面向?qū)ο蟮能浖こ汰h(huán)境中，面向?qū)ο蠹夹g(shù)已達到了類級復(fù)用，而構(gòu)件級復(fù)用則是比類級復(fù)用更高一級的復(fù)用，它是對一組類的組合進行封裝（當(dāng)然，在某些情況下，一個構(gòu)件可能只包含一個單獨的類），并代表完成一個或多個功能的特定服務(wù)，也為用戶提供了多個接口。

一個構(gòu)件可以是一個編譯的類，可以是一組編譯的