軟件架構(gòu)與架構(gòu)建模技術(shù)

軟件架構(gòu)與架構(gòu)建模技術(shù)7.1從設(shè)計(jì)模式到軟件架構(gòu)隨著軟件系統(tǒng)越來(lái)越復(fù)雜和龐大，對(duì)數(shù)據(jù)結(jié)構(gòu)及算法的選擇在許多情況下成為較次要的部分，代碼級(jí)別的軟件復(fù)用已經(jīng)遠(yuǎn)遠(yuǎn)不能滿足大型軟件開(kāi)發(fā)的需求。而對(duì)整個(gè)系統(tǒng)的設(shè)計(jì)和描述變得越來(lái)越重要。由此便產(chǎn)生了軟件架構(gòu)（SoftwareArchitecture）這一概念，軟件架構(gòu)是軟件設(shè)計(jì)抽象的進(jìn)一步發(fā)展，它使得軟件開(kāi)發(fā)人員視野更加開(kāi)闊，滿足了更好地理解軟件系統(tǒng)，更方便地開(kāi)發(fā)更大、更復(fù)雜的軟件系統(tǒng)的需要。第2頁(yè),共51頁(yè)，2024年2月25日，星期天7.1.1軟件架構(gòu)的定義雖然軟件架構(gòu)已經(jīng)在軟件工程領(lǐng)域中有著廣泛的應(yīng)用，但迄今為止還沒(méi)有一個(gè)被大家所公認(rèn)的定義。許多專家學(xué)者從不同角度和不同側(cè)面對(duì)軟件架構(gòu)進(jìn)行了刻畫。第3頁(yè),共51頁(yè)，2024年2月25日，星期天7.1.1軟件架構(gòu)的定義我們將使用軟件架構(gòu)的下列定義：軟件架構(gòu)為軟件系統(tǒng)提供了一個(gè)結(jié)構(gòu)、行為和屬性的高級(jí)抽象，由構(gòu)成系統(tǒng)的元素的描述、這些元素的相互作用、指導(dǎo)元素集成的模式以及這些模式的約束組成。軟件架構(gòu)不僅指定了系統(tǒng)的組織結(jié)構(gòu)和拓?fù)浣Y(jié)構(gòu)，并且顯示了系統(tǒng)需求和構(gòu)成系統(tǒng)的元素之間的對(duì)應(yīng)關(guān)系，提供了一些設(shè)計(jì)決策的基本原理。第4頁(yè),共51頁(yè)，2024年2月25日，星期天7.1.2軟件架構(gòu)的發(fā)展史

20世紀(jì)70年代以前，此階段系統(tǒng)規(guī)模較小，很少明確考慮系統(tǒng)結(jié)構(gòu)，一般不存在系統(tǒng)建模工作。70年代中后期，由于結(jié)構(gòu)化開(kāi)發(fā)方法的出現(xiàn)與廣泛應(yīng)用，軟件開(kāi)發(fā)中出現(xiàn)了概要設(shè)計(jì)與詳細(xì)設(shè)計(jì)，而且主要任務(wù)是數(shù)據(jù)流設(shè)計(jì)與控制流設(shè)計(jì)。因此，此時(shí)軟件結(jié)構(gòu)已作為一個(gè)明確的概念出現(xiàn)在系統(tǒng)的開(kāi)發(fā)中。第5頁(yè),共51頁(yè)，2024年2月25日，星期天7.1.2軟件架構(gòu)的發(fā)展史

20世紀(jì)80年代初到90年代中期，是面向?qū)ο箝_(kāi)發(fā)方法興起與成熟階段。90年代以后則是基于構(gòu)件的軟件開(kāi)發(fā)階段，該階段以過(guò)程為中心，強(qiáng)調(diào)軟件開(kāi)發(fā)采用構(gòu)件化技術(shù)和體系結(jié)構(gòu)技術(shù)，要求開(kāi)發(fā)出的軟件具備很強(qiáng)的自適應(yīng)性、互操作性、可擴(kuò)展性和可重用性。此階段中，軟件架構(gòu)已經(jīng)作為一個(gè)明確的文檔和中間產(chǎn)品存在于軟件開(kāi)發(fā)過(guò)程中，同時(shí)，軟件架構(gòu)作為一門學(xué)科逐漸得到人們的重視，并成為軟件工程領(lǐng)域的研究熱點(diǎn)。第6頁(yè),共51頁(yè)，2024年2月25日，星期天7.1.2軟件架構(gòu)的發(fā)展史

經(jīng)歷了4個(gè)階段：(1)“無(wú)體系結(jié)構(gòu)”設(shè)計(jì)階段：以匯編語(yǔ)言進(jìn)行小規(guī)模應(yīng)用程序開(kāi)發(fā)為特征；(2)萌芽階段：出現(xiàn)了程序結(jié)構(gòu)設(shè)計(jì)主題，以控制流圖和數(shù)據(jù)流圖構(gòu)成軟件結(jié)構(gòu)為特征；(3)初級(jí)階段：出現(xiàn)了從不同側(cè)面描述系統(tǒng)的結(jié)構(gòu)模型，以UML為典型代表；(4)高級(jí)階段：以描述系統(tǒng)的高層抽象結(jié)構(gòu)為中心，不關(guān)心具體的建模細(xì)節(jié)，劃分了體系結(jié)構(gòu)模型與傳統(tǒng)的軟件結(jié)構(gòu)的界限，該階段以Kruchten提出的“4+1”模型為標(biāo)志。第7頁(yè),共51頁(yè)，2024年2月25日，星期天7.2經(jīng)典軟件架構(gòu)模式人們?cè)谲浖_(kāi)發(fā)實(shí)踐中總結(jié)出了許多軟件架構(gòu)模式，這些模式在提出后得到了不斷的修正和完善，逐漸成為人們選擇軟件架構(gòu)時(shí)首先考慮的模式，因此稱為經(jīng)典軟件架構(gòu)模式。第8頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.1管道和過(guò)濾器模式1、管道和過(guò)濾器模式的基本結(jié)構(gòu)

第9頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.1管道和過(guò)濾器模式2、管道和過(guò)濾器模式的優(yōu)點(diǎn)管道和過(guò)濾器模式的軟件架構(gòu)具有許多很好的特點(diǎn)：（1）使得軟構(gòu)件具有良好的隱蔽性和高內(nèi)聚、低耦合的特點(diǎn)；（2）允許設(shè)計(jì)者將整個(gè)系統(tǒng)的輸入/輸出行為看成是多個(gè)過(guò)濾器的行為的簡(jiǎn)單合成；（3）支持軟件重用。只要提供適合在兩個(gè)過(guò)濾器之間傳送的數(shù)據(jù)，任何兩個(gè)過(guò)濾器都可被連接起來(lái)；（4）系統(tǒng)維護(hù)和增強(qiáng)系統(tǒng)性能簡(jiǎn)單。新的過(guò)濾器可以添加到現(xiàn)有系統(tǒng)中來(lái)；舊的可以被改進(jìn)的過(guò)濾器替換掉；（5）允許對(duì)一些屬性如吞吐量、死鎖等的分析；（6）支持并行執(zhí)行。每個(gè)過(guò)濾器是作為一個(gè)單獨(dú)的任務(wù)完成，因此可與其它任務(wù)并行執(zhí)行。

第10頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.1管道和過(guò)濾器模式3、管道和過(guò)濾器模式的不足采用管道和過(guò)濾器模式的系統(tǒng)也存在著若干不利因素。（1）通常導(dǎo)致進(jìn)程成為批處理的結(jié)構(gòu)。這是因?yàn)殡m然過(guò)濾器可增量式地處理數(shù)據(jù)，但它們是獨(dú)立的，所以設(shè)計(jì)者必須將每個(gè)過(guò)濾器看成一個(gè)完整的從輸入到輸出的轉(zhuǎn)換。（2）不適合處理交互的應(yīng)用。當(dāng)需要增量地顯示改變時(shí)，這個(gè)問(wèn)題尤為嚴(yán)重。這樣的系統(tǒng)幾乎無(wú)法顯示系統(tǒng)數(shù)據(jù)流細(xì)微的變換過(guò)程。（3）因?yàn)樵跀?shù)據(jù)傳輸上沒(méi)有通用的標(biāo)準(zhǔn)，每個(gè)過(guò)濾器都增加了解析和合成數(shù)據(jù)的工作，這樣就導(dǎo)致了系統(tǒng)性能下降，并增加了編寫過(guò)濾器的復(fù)雜性。第11頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.1管道和過(guò)濾器模式4、模式實(shí)例一個(gè)特征顯著的實(shí)例是傳統(tǒng)的編譯器。傳統(tǒng)的編譯器一直被認(rèn)為是一種管道系統(tǒng)，在該系統(tǒng)中，一般包含四個(gè)階段即：詞法分析、語(yǔ)法分析、語(yǔ)義分析和代碼生成，每一個(gè)階段的輸出是另一個(gè)階段的輸入。

第12頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.2面向?qū)ο竽Ｊ?、面向?qū)ο竽Ｊ降幕窘Y(jié)構(gòu)第13頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.2面向?qū)ο竽Ｊ?、面向?qū)ο竽Ｊ降膬?yōu)點(diǎn)面向?qū)ο笙到y(tǒng)具有如下4個(gè)基本特征：信息隱藏、數(shù)據(jù)抽象、動(dòng)態(tài)匯集和繼承性，其優(yōu)點(diǎn)大致歸納為以下幾方面：（1）高度模塊化，系統(tǒng)中的每個(gè)對(duì)象都是功能和數(shù)據(jù)獨(dú)立的單元，對(duì)象之間的聯(lián)系是明確的和可預(yù)知的。（2）功能封裝、信息隱藏，用戶不必知道對(duì)象的內(nèi)部狀態(tài)，只需了解其功能描述就可以使用。因?yàn)閷?duì)象對(duì)其它對(duì)象隱藏它的表示，所以可以改變一個(gè)對(duì)象的表示，而不影響其它的對(duì)象。（3）可重用性好，面向?qū)ο蟮睦^承性提供了一種代碼共享的手段，可以避免重復(fù)的代碼設(shè)計(jì)。（4）靈活性

，對(duì)象可以根據(jù)自身的特點(diǎn)進(jìn)行功能實(shí)現(xiàn)，提高了系統(tǒng)的靈活性。（5）系統(tǒng)易維護(hù)，面向?qū)ο蟮姆庋b性決定了類和對(duì)象內(nèi)聚性，從而將可能出現(xiàn)的錯(cuò)誤限制在對(duì)象內(nèi)部，不會(huì)向外傳播，易于檢錯(cuò)和修改，對(duì)某個(gè)對(duì)象中錯(cuò)誤的修改也不會(huì)導(dǎo)致其它對(duì)象代碼失效。（6）可擴(kuò)充性好，面向?qū)ο笙到y(tǒng)可以通過(guò)繼承機(jī)制不斷擴(kuò)充功能，這種增量式的功能擴(kuò)充方式不會(huì)影響原有系統(tǒng)的運(yùn)行。

第14頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.2面向?qū)ο竽Ｊ?、面向?qū)ο竽Ｊ降牟蛔悖?）為了使一個(gè)對(duì)象和另一個(gè)對(duì)象通過(guò)過(guò)程調(diào)用等進(jìn)行交互，必須知道被調(diào)用對(duì)象的標(biāo)識(shí)（對(duì)象名或其他標(biāo)識(shí)符）。這就增加了對(duì)象之間的依賴關(guān)系，只要一個(gè)對(duì)象的標(biāo)識(shí)改變了，就必須修改所有其他明確調(diào)用它的對(duì)象。（2）如果修改一個(gè)對(duì)象，也必須修改所有顯式調(diào)用它的其它對(duì)象，并消除由此帶來(lái)的一些副作用。例如，如果A使用了對(duì)象B，C也使用了對(duì)象B，那么，C對(duì)B的使用所造成的對(duì)A的影響可能是料想不到的。

第15頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.2面向?qū)ο竽Ｊ?、模式實(shí)例以一個(gè)最簡(jiǎn)單的交互式矢量繪圖系統(tǒng)為例。

第16頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.3分層模式1、分層模式的基本結(jié)構(gòu)第17頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.3分層模式2、分層模式的優(yōu)點(diǎn)（1）支持基于抽象程度遞增的系統(tǒng)設(shè)計(jì)，使設(shè)計(jì)者可以把一個(gè)復(fù)雜系統(tǒng)按遞增的步驟進(jìn)行分解。（2）支持功能增強(qiáng)，有較好的擴(kuò)展性。因?yàn)槊恳粚又炼嗪拖噜彽纳舷聦咏换ィ虼斯δ艿母淖冏疃嘤绊懴噜彽纳舷聦?；如果該層次功能的變化僅僅局限于某些功能函數(shù)的具體實(shí)現(xiàn)，而沒(méi)有對(duì)接口進(jìn)行修改，那么對(duì)其相鄰層次幾乎沒(méi)有影響。（3）支持軟件重用。只要提供的服務(wù)接口定義不變，同一層的不同實(shí)現(xiàn)可以交換使用。這樣，就可以定義一組標(biāo)準(zhǔn)的接口，而允許各種不同的實(shí)現(xiàn)方法。

第18頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.3分層模式3、分層模式的不足（1）并不是每個(gè)系統(tǒng)都可以很容易地劃分為分層的模式，甚至即使一個(gè)系統(tǒng)的邏輯結(jié)構(gòu)是層次化的，出于對(duì)系統(tǒng)性能的考慮，系統(tǒng)設(shè)計(jì)師不得不把一些低級(jí)或高級(jí)的功能綜合起來(lái)；（2）很難找到一個(gè)合適的、正確的層次抽象方法。

第19頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.3分層模式4、模式實(shí)例層次系統(tǒng)最廣泛的應(yīng)用是分層通信協(xié)議。在這一應(yīng)用領(lǐng)域中，每一層提供一個(gè)抽象的功能，作為上層通信的基礎(chǔ)。較低的層次定義低層的交互，最低層通常只定義硬件物理連接。以ISO/OSI參考模型為例。該模型采用了7層體系結(jié)構(gòu)，從高到低分別是：應(yīng)用層、表示層、會(huì)話層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層和物理層。

第20頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.4知識(shí)庫(kù)模式

1、知識(shí)庫(kù)模式基本結(jié)構(gòu)第21頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.4知識(shí)庫(kù)模式2、知識(shí)庫(kù)模式的優(yōu)缺點(diǎn)知識(shí)庫(kù)模式常應(yīng)用于專家系統(tǒng)中，是專家系統(tǒng)中不可替代的軟件架構(gòu)模式，但在其他領(lǐng)域應(yīng)用的案例較少見(jiàn)。

第22頁(yè),共51頁(yè)，2024年2月25日，星期天7.2.4知識(shí)庫(kù)模式4、模式實(shí)例知識(shí)庫(kù)模式的軟件體系架構(gòu)常見(jiàn)于專家系統(tǒng)中。專家系統(tǒng)是一類具有專門知識(shí)和經(jīng)驗(yàn)的計(jì)算機(jī)智能程序系統(tǒng)，通過(guò)對(duì)人類專家的問(wèn)題求解能力的建模，采用人工智能中的知識(shí)表示和知識(shí)推理技術(shù)來(lái)模擬通常由專家才能解決的復(fù)雜問(wèn)題，達(dá)到具有與專家同等解決問(wèn)題能力的水平。

第23頁(yè),共51頁(yè)，2024年2月25日，星期天7.3客戶/服務(wù)器模式

當(dāng)一臺(tái)連入網(wǎng)絡(luò)的計(jì)算機(jī)向其他計(jì)算機(jī)提供各種網(wǎng)絡(luò)服務(wù)(如數(shù)據(jù)、文件的共享等)時(shí)，它就被叫做服務(wù)器。而那些用于訪問(wèn)服務(wù)器資料的計(jì)算機(jī)則被叫做客戶機(jī)?？蛻魴C(jī)和服務(wù)器都是獨(dú)立的計(jì)算機(jī)。采用客戶/服務(wù)器（Client/Server，C/S）結(jié)構(gòu)的系統(tǒng)，有一臺(tái)或多臺(tái)服務(wù)器以及大量的客戶機(jī)。服務(wù)器配備大容量存儲(chǔ)器并安裝數(shù)據(jù)庫(kù)系統(tǒng)，用于數(shù)據(jù)的存放和數(shù)據(jù)檢索；客戶端安裝專用的軟件，負(fù)責(zé)數(shù)據(jù)的輸入、運(yùn)算和輸出。嚴(yán)格說(shuō)來(lái)，客戶機(jī)／服務(wù)器模型并不是從物理分布的角度來(lái)定義，它所體現(xiàn)的是一種網(wǎng)絡(luò)數(shù)據(jù)訪問(wèn)的實(shí)現(xiàn)方式。采用這種結(jié)構(gòu)的系統(tǒng)目前應(yīng)用非常廣泛。

第24頁(yè),共51頁(yè)，2024年2月25日，星期天7.3.1協(xié)作計(jì)算模型的發(fā)展在集中式計(jì)算技術(shù)時(shí)代，廣泛使用大型機(jī)/小型機(jī)計(jì)算模型。70年代以后，隨著微型計(jì)算機(jī)和計(jì)算機(jī)網(wǎng)絡(luò)的出現(xiàn)，集中式結(jié)構(gòu)逐漸被以PC為主的微機(jī)網(wǎng)絡(luò)所取代。網(wǎng)絡(luò)/文件服務(wù)器計(jì)算模型的產(chǎn)生用以解決個(gè)人PC和工作站的數(shù)據(jù)和外部設(shè)備共享問(wèn)題。以PC機(jī)為主體的文件服務(wù)器并不能滿足分布式計(jì)算的需求，因此客戶機(jī)/服務(wù)器技術(shù)應(yīng)運(yùn)而生，它集中了大中型系統(tǒng)及文件服務(wù)器的優(yōu)點(diǎn)，并有良好的系統(tǒng)開(kāi)放性和可擴(kuò)展性。隨著信息的全球化，區(qū)域的界限已經(jīng)被打破，電子商務(wù)作為Internet的強(qiáng)大的驅(qū)動(dòng)力，迫使客戶機(jī)/服務(wù)器模式從局域網(wǎng)(LAN)向廣域網(wǎng)(WAN)延伸。

第25頁(yè),共51頁(yè)，2024年2月25日，星期天7.3.2傳統(tǒng)兩層客戶機(jī)/服務(wù)器模式1、兩層客戶機(jī)/服務(wù)器模式的基本結(jié)構(gòu)客戶機(jī)/服務(wù)器系統(tǒng)有三個(gè)主要部件：數(shù)據(jù)庫(kù)服務(wù)器、客戶應(yīng)用程序和網(wǎng)絡(luò)。（1）服務(wù)器負(fù)責(zé)有效地管理系統(tǒng)的資源，其任務(wù)集中于：數(shù)據(jù)庫(kù)安全性的要求數(shù)據(jù)庫(kù)訪問(wèn)并發(fā)性的控制數(shù)據(jù)庫(kù)前端的客戶應(yīng)用程序的全局?jǐn)?shù)據(jù)完整性規(guī)則數(shù)據(jù)庫(kù)的備份與恢復(fù)（2）客戶端應(yīng)用程序的主要任務(wù)是：提供用戶與數(shù)據(jù)庫(kù)交互的界面向數(shù)據(jù)庫(kù)服務(wù)器提交用戶請(qǐng)求并接收來(lái)自數(shù)據(jù)庫(kù)服務(wù)器的信息利用客戶應(yīng)用程序?qū)Υ嬖谟诳蛻舳说臄?shù)據(jù)執(zhí)行應(yīng)用邏輯要求（3）網(wǎng)絡(luò)通信軟件的主要作用是，完成數(shù)據(jù)庫(kù)服務(wù)器和客戶應(yīng)用程序之間的數(shù)據(jù)傳輸。第26頁(yè),共51頁(yè)，2024年2月25日，星期天7.3.2傳統(tǒng)兩層客戶機(jī)/服務(wù)器模式1、兩層客戶機(jī)/服務(wù)器模式的基本結(jié)構(gòu)第27頁(yè),共51頁(yè)，2024年2月25日，星期天7.3.2傳統(tǒng)兩層客戶機(jī)/服務(wù)器模式2、兩層客戶機(jī)/服務(wù)器模式的優(yōu)缺點(diǎn)（1）系統(tǒng)的客戶端應(yīng)用程序和服務(wù)器部件分別運(yùn)行在不同的計(jì)算機(jī)上，系統(tǒng)中每臺(tái)服務(wù)器都可以適合各部件的要求，這對(duì)于硬件和軟件的變化顯示出極大的適應(yīng)性和靈活性，而且易于對(duì)系統(tǒng)進(jìn)行擴(kuò)充和維護(hù)。（2）在客戶機(jī)/服務(wù)器模型中，系統(tǒng)中的功能部件充分隔離，客戶端程序的開(kāi)發(fā)集中于數(shù)據(jù)的顯示和分析，而數(shù)據(jù)庫(kù)服務(wù)器的開(kāi)發(fā)則集中于數(shù)據(jù)的管理，不必在每一個(gè)新的應(yīng)用開(kāi)發(fā)中都要對(duì)一個(gè)數(shù)據(jù)庫(kù)進(jìn)行編碼。（3）將大的應(yīng)用處理任務(wù)分布到許多通過(guò)網(wǎng)絡(luò)連接的低成本計(jì)算機(jī)上使系統(tǒng)部署費(fèi)用極大降低。（4）兩層模式的客戶機(jī)/服務(wù)器模式和多層模式相比，開(kāi)發(fā)、部署和維護(hù)成本較低。第28頁(yè),共51頁(yè)，2024年2月25日，星期天7.3.2傳統(tǒng)兩層客戶機(jī)/服務(wù)器模式2、兩層客戶機(jī)/服務(wù)器模式的優(yōu)缺點(diǎn)（1）系統(tǒng)的可靠性有所降低。一個(gè)客戶機(jī)/服務(wù)器系統(tǒng)是由各自獨(dú)立開(kāi)發(fā)、制造和管理的各種硬件和軟件的組成的混合體

，其內(nèi)在的可靠性不如單一的、中央管理的大型機(jī)或小型機(jī)，出現(xiàn)問(wèn)題時(shí)，很難立即獲得技術(shù)支持和幫助。（2）維護(hù)費(fèi)用較高。盡管這種應(yīng)用模式在某種程度上提高了生產(chǎn)效率，由于客戶端需要安裝龐大而復(fù)雜的應(yīng)用程序，當(dāng)網(wǎng)絡(luò)用戶的規(guī)模達(dá)到一定的數(shù)量之后，系統(tǒng)的維護(hù)量急劇增加，因而維護(hù)應(yīng)用系統(tǒng)變得十分困難。（3）系統(tǒng)資源的浪費(fèi)。隨著客戶端的規(guī)模越來(lái)越大，對(duì)客戶機(jī)資源的要求也越來(lái)越高?？蛻魴C(jī)硬件要適應(yīng)系統(tǒng)要求而不斷更新，每個(gè)客戶機(jī)都要重復(fù)購(gòu)置、安裝大量應(yīng)用軟件，這無(wú)疑是一種巨大的浪費(fèi)。（4）系統(tǒng)缺乏靈活性?？蛻魴C(jī)/服務(wù)器需要對(duì)每一應(yīng)用獨(dú)立地開(kāi)發(fā)應(yīng)用程序，消耗了大量的資源。（5）二層C/S結(jié)構(gòu)是單一服務(wù)器且以局域網(wǎng)為中心的，所以難以擴(kuò)展至大型企業(yè)廣域網(wǎng)或Internet;（6）數(shù)據(jù)安全性不好。因?yàn)榭蛻舳顺绦蚩梢灾苯釉L問(wèn)數(shù)據(jù)庫(kù)服務(wù)器，那么，安裝在客戶端計(jì)算機(jī)上的其他程序也可以訪問(wèn)數(shù)據(jù)庫(kù)服務(wù)器，從而使數(shù)據(jù)庫(kù)的安全性受到威脅。第29頁(yè),共51頁(yè)，2024年2月25日，星期天7.3.2傳統(tǒng)兩層客戶機(jī)/服務(wù)器模式3、應(yīng)用實(shí)例以一個(gè)早期構(gòu)建的學(xué)生信息管理系統(tǒng)為例。系統(tǒng)硬件包括若干臺(tái)客戶機(jī)和一臺(tái)服務(wù)器以及連接它們的網(wǎng)絡(luò)環(huán)境，服務(wù)器上安裝Unix操作系統(tǒng)，使用Oracle數(shù)據(jù)庫(kù)管理系統(tǒng)管理和存儲(chǔ)數(shù)據(jù)；客戶機(jī)上安裝Windows操作系統(tǒng)，使用Delphi語(yǔ)言開(kāi)發(fā)客戶端管理軟件，再部署到每個(gè)管理人員使用的客戶機(jī)上。服務(wù)器和客戶機(jī)軟件要采用一些安全控制策略和加密手段以保證數(shù)據(jù)的安全。

第30頁(yè),共51頁(yè)，2024年2月25日，星期天7.3.3經(jīng)典三層客戶機(jī)/服務(wù)器模式

1、三層客戶機(jī)/服務(wù)器模式基本結(jié)構(gòu)三層C/S結(jié)構(gòu)是將應(yīng)用功能分成表示層、功能層和數(shù)據(jù)層三部分。表示層是應(yīng)用的用戶接口部分,它擔(dān)負(fù)著用戶與應(yīng)用間的對(duì)話功能。它用于檢查用戶從鍵盤等輸入的數(shù)據(jù),顯示應(yīng)用輸出的數(shù)據(jù)。為使用戶能直觀地進(jìn)行操作，一般要使用圖形用戶接口(GUI)，操作簡(jiǎn)單、易學(xué)易用。在變更用戶接口時(shí)，只需改寫顯示控制和數(shù)據(jù)檢查程序，而不影響其他兩層。檢查的內(nèi)容也只限于數(shù)據(jù)的形式和值的范圍，不包括有關(guān)業(yè)務(wù)本身的處理邏輯。功能層相當(dāng)于應(yīng)用的本體，它是將具體的業(yè)務(wù)處理邏輯地編入程序中。表示層和功能層之間的數(shù)據(jù)交互要盡可能簡(jiǎn)潔。數(shù)據(jù)層就是DBMS，負(fù)責(zé)管理對(duì)數(shù)據(jù)庫(kù)數(shù)據(jù)的讀寫。DBMS必須能迅速執(zhí)行大量數(shù)據(jù)的更新和檢索。目前的主流是采用關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)(RDBMS)。因此一般從功能層傳送到數(shù)據(jù)層的要求大都使用SQL語(yǔ)言。

第31頁(yè),共51頁(yè)，2024年2月25日，星期天7.3.3經(jīng)典三層客戶機(jī)/服務(wù)器模式1、三層客戶機(jī)/服務(wù)器模式基本結(jié)構(gòu)第32頁(yè),共51頁(yè)，2024年2月25日，星期天7.3.3經(jīng)典三層客戶機(jī)/服務(wù)器模式2、三層C/S模式的優(yōu)缺點(diǎn)

（1）三層C/S結(jié)構(gòu)具有更靈活的硬件系統(tǒng)構(gòu)成，對(duì)于各個(gè)層可以選擇與其處理負(fù)荷和處理特性相適應(yīng)的硬件。（2）合理地分割三層結(jié)構(gòu)并使其獨(dú)立，可以使系統(tǒng)的結(jié)構(gòu)變得簡(jiǎn)單清晰，這樣就提高了程序的可維護(hù)性。（3）三層C/S結(jié)構(gòu)中，應(yīng)用的各層可以并行開(kāi)發(fā)，各層也可以選擇各自最適合的開(kāi)發(fā)語(yǔ)言，有利于變更和維護(hù)應(yīng)用技術(shù)規(guī)范。按層分割功能使各個(gè)程序的處理邏輯變得十分簡(jiǎn)單。（4）允許充分利用功能層有效地隔離開(kāi)表示層與數(shù)據(jù)層，未授權(quán)的用戶難以繞過(guò)功能層而利用數(shù)據(jù)庫(kù)工具或黑客手段非法地訪問(wèn)數(shù)據(jù)層，這就為嚴(yán)格的安全管理奠定了堅(jiān)實(shí)的基礎(chǔ)；整個(gè)系統(tǒng)的管理層次也更加合理和可控制。（5）系統(tǒng)可用性高，具有良好的開(kāi)放性，可跨平臺(tái)操作，支持異構(gòu)數(shù)據(jù)庫(kù)。三層C/S模式當(dāng)然也存在一些不足，例如相比兩層C/S模式來(lái)講，開(kāi)發(fā)的技術(shù)難度加大，對(duì)于小企業(yè)和小型應(yīng)用項(xiàng)目來(lái)說(shuō)，部署成本過(guò)高等。第33頁(yè),共51頁(yè)，2024年2月25日，星期天7.3.3經(jīng)典三層客戶機(jī)/服務(wù)器模式3、應(yīng)用實(shí)例由于三層C/S模式應(yīng)用較廣泛，各行業(yè)的應(yīng)用實(shí)例也不勝枚舉，仍以學(xué)校學(xué)生信息管理系統(tǒng)為例。出于性能和數(shù)據(jù)安全的考慮，上節(jié)實(shí)例中提到的學(xué)校對(duì)自己的學(xué)生信息管理系統(tǒng)進(jìn)行了升級(jí)改造，增加了兩臺(tái)應(yīng)用服務(wù)器，其中一臺(tái)處理學(xué)生信息查詢業(yè)務(wù)，另一臺(tái)處理學(xué)生信息修改業(yè)務(wù)，這兩臺(tái)應(yīng)用服務(wù)器軟件使用微軟COM+組件開(kāi)發(fā)，對(duì)客戶機(jī)軟件也進(jìn)行了修改。這樣改造的結(jié)果是：業(yè)務(wù)處理邏輯分配到了兩個(gè)服務(wù)器節(jié)點(diǎn)上，系統(tǒng)性能得到提升，支持的終端數(shù)可以成倍增加；查詢和修改兩個(gè)業(yè)務(wù)邏輯分離，更有利于系統(tǒng)安全控制；客戶機(jī)軟件只處理表示邏輯，系統(tǒng)開(kāi)發(fā)工作量大大減少；客戶機(jī)軟件和應(yīng)用服務(wù)器軟件可由兩個(gè)小組分別開(kāi)發(fā)和維護(hù)，提高和效率。第34頁(yè),共51頁(yè)，2024年2月25日，星期天7.3.3經(jīng)典三層客戶機(jī)/服務(wù)器模式4、多層客戶機(jī)/服務(wù)器模式在大型系統(tǒng)中，為了進(jìn)一步提高系統(tǒng)性能，增加系統(tǒng)靈活性，還可以對(duì)三層C/S結(jié)構(gòu)中的功能層繼續(xù)進(jìn)行細(xì)分。例如將數(shù)據(jù)庫(kù)存取的相關(guān)操作獨(dú)立出來(lái)形成數(shù)據(jù)庫(kù)訪問(wèn)層，該層專門負(fù)責(zé)和數(shù)據(jù)庫(kù)交互，存取數(shù)據(jù)。這樣就形成了四層乃至N層客戶機(jī)/服務(wù)器模式。這樣做的優(yōu)點(diǎn)在于，對(duì)于大型系統(tǒng)來(lái)說(shuō)，邏輯結(jié)構(gòu)更加清晰，系統(tǒng)各層的開(kāi)發(fā)和維護(hù)、部署更加靈活，但也帶來(lái)了管理成本加大的問(wèn)題。在實(shí)際應(yīng)用中，系統(tǒng)架構(gòu)師應(yīng)根據(jù)項(xiàng)目的具體情況選擇合適的架構(gòu)模式。第35頁(yè),共51頁(yè)，2024年2月25日，星期天7.4瀏覽器/服務(wù)器模式

瀏覽器/服務(wù)器（Browser/Server，B/S）架構(gòu)模式實(shí)際上是上述三層C/S架構(gòu)的一種實(shí)現(xiàn)方式，其具體結(jié)構(gòu)為：瀏覽器/Web服務(wù)器/數(shù)據(jù)庫(kù)服務(wù)器，第36頁(yè),共51頁(yè)，2024年2月25日，星期天7.4瀏覽器/服務(wù)器模式2、主要優(yōu)缺點(diǎn)B／S結(jié)構(gòu)的主要優(yōu)點(diǎn)是分布性強(qiáng)、維護(hù)方便、開(kāi)發(fā)簡(jiǎn)單且共享性強(qiáng)、總體擁有成本低。提供了異種機(jī)、異種網(wǎng)、異種應(yīng)用服務(wù)的聯(lián)機(jī)、聯(lián)網(wǎng)、統(tǒng)一服務(wù)的最現(xiàn)實(shí)的開(kāi)放性基礎(chǔ)。用戶在使用系統(tǒng)時(shí)，僅僅需要一個(gè)瀏覽器就可運(yùn)行全部的模塊，真正達(dá)到了"零客戶端"的功能，很容易在運(yùn)行時(shí)自動(dòng)升級(jí)。主要缺點(diǎn)在于：一是存在數(shù)據(jù)安全性問(wèn)題、對(duì)服務(wù)器要求過(guò)高、數(shù)據(jù)傳輸速度慢、軟件的個(gè)性化特點(diǎn)明顯降低；二是難以實(shí)現(xiàn)傳統(tǒng)模式下的特殊功能要求。例如通過(guò)瀏覽器進(jìn)行大量的數(shù)據(jù)輸入或進(jìn)行報(bào)表的應(yīng)答、專用性打印輸出都比較困難和不便。三是實(shí)現(xiàn)復(fù)雜的應(yīng)用構(gòu)造有較大的困難。雖然可以用ActiveX、Java等技術(shù)開(kāi)發(fā)較為復(fù)雜的應(yīng)用，但是相對(duì)于已經(jīng)發(fā)展的非常成熟的C／S一系列應(yīng)用工具來(lái)說(shuō)，這些技術(shù)還不夠成熟。第37頁(yè),共51頁(yè)，2024年2月25日，星期天7.4瀏覽器/服務(wù)器模式3、應(yīng)用實(shí)例還以上文學(xué)校學(xué)生信息管理系統(tǒng)為實(shí)例說(shuō)明這種架構(gòu)模式。學(xué)校準(zhǔn)備向全校學(xué)生開(kāi)放部分信息，在校學(xué)生可以在校園網(wǎng)上用自己的計(jì)算機(jī)查詢自己的諸如考試成績(jī)、圖書借閱記錄等信息，學(xué)校難道要讓每個(gè)學(xué)生都下載安裝一個(gè)客戶機(jī)信息軟件嗎。這種情況下，B/S模式就顯示出它的巨大優(yōu)勢(shì)，改用這種模式就是一種必然的選擇。新系統(tǒng)采用B／S架構(gòu)，結(jié)合了ASP技術(shù)，并將組件技術(shù)COM+和ActiveX技術(shù)分別應(yīng)用在服務(wù)器端和客戶端。該系統(tǒng)的實(shí)現(xiàn)主要分為三個(gè)部分：ASP頁(yè)面、COM+組件和數(shù)據(jù)庫(kù)，是一個(gè)三層結(jié)構(gòu)。表示層由ASP頁(yè)面組成，用以實(shí)現(xiàn)WEB頁(yè)面顯示和調(diào)用COM+組件，業(yè)務(wù)邏輯和數(shù)據(jù)訪問(wèn)由一組用VC實(shí)現(xiàn)的COM+組件構(gòu)成。為了便于維護(hù)、升級(jí)和實(shí)現(xiàn)分布式應(yīng)用，在實(shí)現(xiàn)過(guò)程中，又將業(yè)務(wù)邏輯層和數(shù)據(jù)訪問(wèn)層分離開(kāi)，ASP頁(yè)面不直接調(diào)用數(shù)據(jù)訪問(wèn)層，而是通過(guò)業(yè)務(wù)邏輯層調(diào)用數(shù)據(jù)庫(kù)。一些需要用WEB處理的、滿足大多數(shù)訪問(wèn)者請(qǐng)求的功能界面采用B／S結(jié)構(gòu)，例如任課教師可以通過(guò)瀏覽器查詢所教班級(jí)學(xué)生各種相關(guān)信息；學(xué)校管理人員通過(guò)瀏覽器對(duì)學(xué)校的學(xué)生、教師等信息進(jìn)行管理與維護(hù)以及查詢統(tǒng)計(jì)；領(lǐng)導(dǎo)層可通過(guò)瀏覽器進(jìn)行數(shù)據(jù)的查詢和決策。第38頁(yè),共51頁(yè)，2024年2月25日，星期天7.5基于構(gòu)件的模式1、基于構(gòu)件模式的基本結(jié)構(gòu)一般認(rèn)為，構(gòu)件是指語(yǔ)義完整、語(yǔ)法正確和有可重用價(jià)值的單位軟件，是軟件重用過(guò)程中可以明確辯識(shí)的系統(tǒng)；結(jié)構(gòu)上，它是語(yǔ)義描述、通訊接口和實(shí)現(xiàn)代碼的復(fù)合體。簡(jiǎn)單地說(shuō)，構(gòu)件是具有一定的功能，能夠獨(dú)立工作或能同其它構(gòu)件裝配起來(lái)協(xié)調(diào)工作的程序體，構(gòu)件的使用同他的開(kāi)發(fā)、生產(chǎn)無(wú)關(guān)。從抽象程度來(lái)看，面向?qū)ο蠹夹g(shù)已達(dá)到了類級(jí)重用(代碼重用)，它以類為封裝的單位。這樣的重用粒度還太小，不足以解決異構(gòu)互操作和效率更高的重用。構(gòu)件將抽象的程度提到一個(gè)更高的層次，它是對(duì)一組類的組合進(jìn)行封裝，并代表完成一個(gè)或多個(gè)功能的特定服務(wù)，也為用戶提供了多個(gè)接口。整個(gè)構(gòu)件隱藏了具體的實(shí)現(xiàn)，只用接口提供服務(wù)。

第39頁(yè),共51頁(yè)，2024年2月25日，星期天7.5基于構(gòu)件的模式2、基于構(gòu)件模式的優(yōu)缺點(diǎn)基于構(gòu)件的軟件架構(gòu)模式是軟件開(kāi)發(fā)發(fā)展到一定階段的產(chǎn)物，是目前主流的應(yīng)用軟件架構(gòu)模式，其優(yōu)點(diǎn)體現(xiàn)在以下幾個(gè)方面：（1）完全黑盒的軟件復(fù)用，整個(gè)構(gòu)件隱藏了具體的實(shí)現(xiàn)，只用接口提供服務(wù)。不僅能實(shí)現(xiàn)代碼復(fù)用，還實(shí)現(xiàn)了核心功能復(fù)用。（2）總體架構(gòu)的松耦合，構(gòu)件與構(gòu)件之間都是松耦合的，相同接口而不同實(shí)現(xiàn)的構(gòu)件完全可以互換。（3）軟件生產(chǎn)周期縮短，目前，人們更傾向于購(gòu)買使用已開(kāi)發(fā)好的構(gòu)件來(lái)構(gòu)建自己的系統(tǒng)，從而使開(kāi)發(fā)時(shí)間大大縮短。（4）能適應(yīng)遠(yuǎn)程訪問(wèn)的分布式、多層次異構(gòu)系統(tǒng)。（5）具有靈活方便的升級(jí)能力和系統(tǒng)模塊的更新維護(hù)能力。存在的缺點(diǎn)主要有以下幾點(diǎn)：一是大量使用第三方構(gòu)件給軟件的安全帶來(lái)隱患；二是購(gòu)買構(gòu)件可能使軟件成本增加；三是非定制的構(gòu)件中存在的無(wú)用部分可能帶來(lái)性能負(fù)擔(dān)。第40頁(yè),共51頁(yè)，2024年2月25日，星期天7.5基于構(gòu)件的模式3、應(yīng)用實(shí)例在此以企事業(yè)單位的檔案管理系統(tǒng)為例，檔案MIS系統(tǒng)基于C/S(Client/Server)與B/S(Browser/Server)混合結(jié)構(gòu)對(duì)檔案信息進(jìn)行全面收集、加工、存儲(chǔ)、傳輸和利用，并對(duì)管理活動(dòng)進(jìn)行控制。針對(duì)檔案管理的業(yè)務(wù)流程，檔案管理信息系統(tǒng)應(yīng)具有庫(kù)文件管理、著錄標(biāo)引、分類編目、排序、查詢、借閱、打印、統(tǒng)計(jì)、報(bào)表等功能，形成若干子系統(tǒng)。根據(jù)對(duì)檔案工作領(lǐng)域的分析結(jié)果，建立開(kāi)發(fā)模型，明確劃分三類構(gòu)件，即：將系統(tǒng)中不變(或基本不變)部分作為通用類構(gòu)件，如各類型的檔案單位都要進(jìn)行大量的查詢、統(tǒng)計(jì)、報(bào)表等操作；可變部分，則歸入專用類構(gòu)件，如著錄標(biāo)引、分類編目、借閱等；而系統(tǒng)類構(gòu)件，則是在整個(gè)MIS中都要用到的構(gòu)件，如開(kāi)發(fā)工具的菜單、窗口、網(wǎng)絡(luò)安全模塊等。

第41頁(yè),共51頁(yè)，2024年2月25日，星期天7.5基于構(gòu)件的模式3、應(yīng)用實(shí)例第42頁(yè),共51頁(yè)，2024年2月25日，星期天7.6軟件架構(gòu)建模技術(shù)研究軟件架構(gòu)的首要問(wèn)題是如何表示軟件架構(gòu)，即如何對(duì)軟件架構(gòu)建模。根據(jù)建模的側(cè)重點(diǎn)的不同，可以將軟件架構(gòu)的模型分為5種：結(jié)構(gòu)模型、框架模型、動(dòng)態(tài)模型、過(guò)程模型和功能模型。在這5個(gè)模型中，最常用的是結(jié)構(gòu)模型和動(dòng)態(tài)模型。（1）結(jié)構(gòu)模型這是一個(gè)最直觀、最普遍的建模方法。這種方法以架構(gòu)的構(gòu)件、連接件和其他概念來(lái)刻畫結(jié)構(gòu)，并力圖通過(guò)結(jié)構(gòu)來(lái)反映系統(tǒng)的重要語(yǔ)義內(nèi)容，包括系統(tǒng)的配置、約束、隱含的假設(shè)條件、風(fēng)格、性質(zhì)。研究結(jié)構(gòu)模型的核心是架構(gòu)描述語(yǔ)言。（2）框架模型框架模型與結(jié)構(gòu)模型類似，但它不太側(cè)重描述結(jié)構(gòu)的細(xì)節(jié)而更側(cè)重于整體的結(jié)構(gòu)。框架模型主要以一些特殊的問(wèn)題為目標(biāo)建立只針對(duì)和適應(yīng)該問(wèn)題的結(jié)構(gòu)。第43頁(yè),共51頁(yè)，2024年2月25日，星期天7.6軟件架構(gòu)建模技術(shù)（3）動(dòng)態(tài)模型動(dòng)態(tài)模型是對(duì)結(jié)構(gòu)或框架模型的補(bǔ)充，研究系統(tǒng)的"大顆粒"的行為性質(zhì)。例如，描述系統(tǒng)的重新配置或演化。動(dòng)態(tài)可能指系統(tǒng)總體結(jié)構(gòu)的配置、建立或拆除通信通道或計(jì)算的過(guò)程。這類系統(tǒng)常是激勵(lì)型的。（4）過(guò)程模型過(guò)程模型研究構(gòu)造系統(tǒng)的步驟和過(guò)程。因而結(jié)構(gòu)是遵循某些過(guò)程腳本的結(jié)果。（5）功能模型該模型認(rèn)為架構(gòu)是由一組功能構(gòu)件按層次組成，下層向上層提供服務(wù)。它可以看作是一種特殊的框架模型。這5種模型各有所長(zhǎng)，如果將5種模型有機(jī)地統(tǒng)一在一起，形成一個(gè)完整的模型來(lái)刻畫軟件架構(gòu)，將能更加準(zhǔn)確、全面地反映軟件架構(gòu)。第44頁(yè),共51頁(yè)，2024年2月25日，星期天7.6.1軟件架構(gòu)“4+1”視圖模型

PhilippeKruchten在1995年提出了一個(gè)"4+1"的視角模型。"4+1"模型從5個(gè)不同的視角包括邏輯視角、過(guò)程視角、物理視角、開(kāi)發(fā)視角和場(chǎng)景視角來(lái)描述軟件架構(gòu)。每一個(gè)視角只關(guān)心系統(tǒng)的一個(gè)側(cè)面，5個(gè)視角結(jié)合在一起才能夠反映系統(tǒng)的軟件架構(gòu)的全部?jī)?nèi)容。"4+1"視圖模型如圖7.14所示。

第45頁(yè),共51頁(yè)，2024年2月25日，星期天7.6.2“4+1”視圖模型建模方法

1、邏輯視角－邏輯結(jié)構(gòu)邏輯視角主要對(duì)系統(tǒng)的邏輯結(jié)構(gòu)進(jìn)行建模，采用的是面向?qū)ο蟮姆纸獾姆椒?。邏輯架?gòu)主要支持功能性需求――即在為用戶提供服務(wù)方面系統(tǒng)所應(yīng)該提供的功能。系統(tǒng)分解為一系列的關(guān)鍵抽象，（大多數(shù)）來(lái)自于問(wèn)題域，表現(xiàn)為對(duì)象或?qū)ο箢惖男问?。它們采用抽象、封裝和繼承的原理。分解并不僅僅是為了功能分析，而且用來(lái)識(shí)別遍布系統(tǒng)各個(gè)部分的通用機(jī)制和設(shè)計(jì)元素。一般使用Rational/Booch方法來(lái)表示邏輯架構(gòu)，主要借助于類圖和類模板的手段。類圖用來(lái)顯示一個(gè)類的集合和它們的邏輯關(guān)系：關(guān)聯(lián)、使用、組合、繼承等等。相似的類可以劃分成類集合。類模板關(guān)注于單個(gè)類，它們強(qiáng)調(diào)主要的類操作，并且識(shí)別關(guān)鍵的對(duì)象特征。如果需要定義對(duì)象的內(nèi)部行為，則使用狀態(tài)轉(zhuǎn)換圖或狀態(tài)圖來(lái)完成。公共機(jī)制或服務(wù)可以在類功能（classutilities）中定義。對(duì)于數(shù)據(jù)驅(qū)動(dòng)程度高的應(yīng)用程序，可以使用其他形式的邏輯視圖，例如E-R圖，來(lái)代替面向?qū)ο蟮姆椒ā?/p>

第46頁(yè),共51頁(yè)，2024年2月25日，星期天7.6.2“4+1”視圖模型建模方法

2、進(jìn)程視角－進(jìn)程架構(gòu)進(jìn)程視角主要對(duì)系統(tǒng)的進(jìn)程架構(gòu)進(jìn)行建模，采用過(guò)程分解的方法。進(jìn)程架構(gòu)考慮一些非功能性的需求，如性能和可用性。它解決并發(fā)性、分布性、系統(tǒng)完整性、容錯(cuò)性的問(wèn)題，以及邏輯視圖的主要抽象如何與進(jìn)程結(jié)構(gòu)相配合在一起――即在哪個(gè)控制線程上，對(duì)象的操作被實(shí)際執(zhí)行。進(jìn)程架構(gòu)可以在幾種層次的抽象上進(jìn)行描述，每個(gè)層次針對(duì)不同的問(wèn)題。在最高的層次上，進(jìn)程架構(gòu)可以視為一組獨(dú)立執(zhí)行的通信程序的邏輯網(wǎng)絡(luò)，它們分布在整個(gè)一組硬件資源上，這些資源通過(guò)LAN或者WAN連接起來(lái)。多個(gè)邏輯網(wǎng)絡(luò)可能同時(shí)并存，共享相同的物理資源。例如，獨(dú)立的邏輯網(wǎng)絡(luò)可能用