軟件體系結構與設計模式課件

1、第8章 軟件體系結構與設計模式8.1軟件體系結構的概念 8.1.1什么是軟件體系結構 軟件體系結構是系統(tǒng)的一個或多個結構，它包括：1) 軟件的組成元素（組件）；2) 這些（組件）元素的外部可見特性；3) 這些元素（組件）之間的相互關系。 軟件體系結構不僅指定了系統(tǒng)的組織結構和拓撲結構，也顯示了系統(tǒng)需求和構成系統(tǒng)的元素之間的對應關系，提供了一些設計決策的基本原理。8.1軟件體系結構的概念 軟件體系結構描述的對象是直接構成系統(tǒng)的抽象組件。它由功能各異、相互作用的部件按照層次構成，包含了系統(tǒng)的基礎構成單元、單元之間的相互作用關系、在構成系統(tǒng)時它們的合成方法以及對合成約束的描述。具體來說，部件包括客戶

2、端、服務器、數(shù)據(jù)庫、程序包、過程、子程序等一切軟件的組成部分。相互作用的關系可以是過程調(diào)用、消息傳遞、共享內(nèi)存變量、客戶端/服務器的訪問協(xié)議、數(shù)據(jù)庫的訪問協(xié)議等。8.1軟件體系結構的概念 8.1.2軟件體系結構建模根據(jù)建模的側重點的不同，可以將軟件體系結構的模型分為結構模型、框架模型、動態(tài)模型、過程模型和功能模型5種。1）結構模型這是一個最直觀、最普遍的建模方法。這種方法以體系結構的構件、連接件和其他概念來刻畫結構，并力圖通過結構來反映系統(tǒng)的重要語義內(nèi)容，包括系統(tǒng)的配置、約束、隱含的假設條件、風格、性質。研究結構模型的核心是體系結構描述語言。2）框架模型框架模型與結構模型類似，但它不太側重描述

3、結構的細節(jié)而更側重于整體的結構?？蚣苣Ｐ椭饕砸恍┨厥獾膯栴}為目標建立只針對和適應該問題的結構。8.1軟件體系結構的概念 3）動態(tài)模型動態(tài)模型是對結構模型或框架模型的補充，研究系統(tǒng)的大顆粒的行為性質。例如，描述系統(tǒng)的重新配置或演化。動態(tài)可能指系統(tǒng)總體結構的配置、建立或拆除通信通道或計算的過程。這類系統(tǒng)常是激勵型的。4）過程模型過程模型研究構造系統(tǒng)的步驟和過程，因此結構是遵循某些過程腳本的結果。5）功能模型該模型認為體系結構是由一組功能構件按層次組成，下層向上層提供服務。它可以看作是一種特殊的框架模型。5.1 生產(chǎn)函數(shù)與軟件生產(chǎn)函數(shù)生產(chǎn)是指廠商對各種生產(chǎn)要素加以組合制成產(chǎn)品的行為。生產(chǎn)要素就是生

4、產(chǎn)過程中所使用的各種資源，主要包括勞動、資本、土地和企業(yè)家才能。5.1 生產(chǎn)函數(shù)與軟件生產(chǎn)函數(shù)勞動是指勞動者所提供的各種服務資本是指生產(chǎn)過程中使用的資金土地是指在生產(chǎn)過程中所使用的自然資源企業(yè)家才能是指企業(yè)家對整個生產(chǎn)過程的管理和組織工作 企業(yè)家主要根據(jù)市場預測，合理地配置各生產(chǎn)要素來從事生產(chǎn)經(jīng)營活動，以追求企業(yè)的利潤最大化。5.1.1 生產(chǎn)函數(shù) 生產(chǎn)函數(shù)是指一定時期內(nèi)生產(chǎn)要素的數(shù)量與某種組合與其所能產(chǎn)出的最大產(chǎn)量之間存在的函數(shù)關系。生產(chǎn)函數(shù)的表達式如式5.1所示。式5.1中的y表示總產(chǎn)出量，L，K，N，E分別表示投入到生產(chǎn)中的勞動、資本、土地、企業(yè)家才能的數(shù)量。1. 生產(chǎn)函數(shù)的定義5.1.1

5、 生產(chǎn)函數(shù) 考慮到土地的固定性，變化較小，企業(yè)家才能難以估算故生產(chǎn)函數(shù)通常被簡化為式5.2。式5.2表明，在已知勞動和資本數(shù)量的組合情況時，可以推算出產(chǎn)品的最大產(chǎn)量。1. 生產(chǎn)函數(shù)的定義5.1.1 生產(chǎn)函數(shù)2. 生產(chǎn)函數(shù)的特征特征資本與勞動力的邊際產(chǎn)出總是為正值，勞動力（或者資本）投入量不變的情況下，資本（或者勞動力）的增加將引起產(chǎn)出的增加邊際產(chǎn)量遞減特性。當其他生產(chǎn)要素固定不變時，隨著某一要素投入量的增加，其邊際產(chǎn)量將逐漸減少生產(chǎn)函數(shù)具有非負性，總產(chǎn)出必須是正值，且總產(chǎn)量是生產(chǎn)要素組合的結果，單一要素的投入是不能獲得產(chǎn)出的5.1.1 生產(chǎn)函數(shù)3. 規(guī)模報酬規(guī)模報酬又稱為規(guī)模經(jīng)濟，主要研究所有

6、要素都同比例增加時，產(chǎn)量時如何發(fā)生變化的。 通常在規(guī)模較小時，增加投入可以促進規(guī)模報酬遞增，而當規(guī)模達到一定程度時，則會出現(xiàn)規(guī)模報酬遞減的情況。5.1.1 生產(chǎn)函數(shù)3. 規(guī)模報酬5.1.1 生產(chǎn)函數(shù)分別對公示5.3中的L與K求偏導數(shù)則有：式5.4中， 表示勞動力對產(chǎn)出的彈性系數(shù)，表示在其他條件不變的情況下，勞動力增加1%會使產(chǎn)出發(fā)生變化的百分比； 表示資本對產(chǎn)出的彈性系數(shù)，表示在其他條件不變的情況下，資本增加1%會使產(chǎn)出發(fā)生變化的百分比。3. 規(guī)模報酬5.1.1 生產(chǎn)函數(shù)5.1.2 軟件生產(chǎn)函數(shù)5.1.2 軟件生產(chǎn)函數(shù)5.1.2 軟件生產(chǎn)函數(shù) 軟件生產(chǎn)率是指軟件開發(fā)的效率，是衡量軟件開發(fā)水平的

7、一個重要因素。影響軟件生產(chǎn)率的因素眾多，主要有技術因素、管理因素以及文化因素。5.1.2 軟件生產(chǎn)函數(shù)強調(diào)對企業(yè)研發(fā)人員個人職業(yè)能力的綜合評估。為了提升個人對軟件企業(yè)的貢獻，有必要從專業(yè)、技能、經(jīng)驗、學歷以及年齡等多方面進行考量。軟件技術領域最好根據(jù)研發(fā)人員所擅長的技術能力來劃分不同的專業(yè)技術組。培養(yǎng)研發(fā)人員對新技術的學習掌握，并創(chuàng)新應用。提高軟件生產(chǎn)率的主要舉措有：技術方面5.1.2 軟件生產(chǎn)函數(shù)建立良好的人才激勵機制，通過物質、精神獎勵以及職務晉升制度提高研發(fā)人員的工作熱情。建立科學、合理的研發(fā)人員梯隊制度，明確劃分管理與技術領域人才。依據(jù)軟件企業(yè)所處的市場環(huán)境及企業(yè)自身發(fā)展的要求適時變革

8、管理。用以應對不斷變化的IT市場，進而增強軟件企業(yè)的核心競爭力。提高軟件生產(chǎn)率的主要舉措有：管理方面5.1.2 軟件生產(chǎn)函數(shù)建立良好的企業(yè)學習氛圍。通過研發(fā)人員個人知識的學習、交流及其共享來形成群體效應，提升整個企業(yè)的知識資源。注重軟件工程項目團隊建設，加強團隊合作精神，提高團隊溝通能力。提高軟件生產(chǎn)率的主要舉措有：文化方面8.1軟件體系結構的概念 軟件體系結構建?？煞譃?個層次。1）軟件體系結構核心元模型：軟件體系結構模型由哪些元素組成，這些組成元素之間按照何種原則組織；2）軟件體系結構模型的多視圖表示：從不同的視角描述特定系統(tǒng)的體系結構，從而得到多個視圖，并將這些視圖組織起來以描述整體的軟

9、件體系結構模型；3）軟件體系結構描述語言：在軟件體系結構基本概念的基礎上，選取適當?shù)男问交虬胄问交姆椒▉砻枋鲆粋€特定的體系結構；4）軟件體系結構文檔化：記錄和整理上述3個層次的描述內(nèi)容。8.1軟件體系結構的概念 8.1.3軟件體系結構的分層模型計算機硬件層是軟件實現(xiàn)的物質基礎，比如存儲器、時鐘、高速緩存等。軟件硬件層實現(xiàn)了軟件與硬件的分離，既是對軟件實現(xiàn)的最底層的描述，也是對硬件實現(xiàn)的操作和控制的描述?；A控制描述層、資源和管理調(diào)度層是體系結構構件和連接的內(nèi)在構成模型。系統(tǒng)結構模式層是軟件的上層體系結構，它是最高層次的軟件結構概念，其涉及的概念通常有客戶端/服務器、解釋器、編譯器、框架等。

10、應用層是建立在軟件概念之上的領域問題描述，它是基于純粹的應用領域的。8.1軟件體系結構的概念 8.1.4軟件體系結構的作用 設計軟件的體系結構在設計階段非常重要。軟件體系結構就好比軟件系統(tǒng)的骨骼，如果骨骼確定了，那么軟件系統(tǒng)的框架就確定了。軟件體系結構在軟件開發(fā)過程中的作用如下。1）規(guī)范軟件開發(fā)的基本架構2）便于開發(fā)人員與用戶的溝通3）模塊化、層次化設計，有利于減少返工，提高效率4）便于系統(tǒng)開發(fā)前、后期的籌備與服務8.1軟件體系結構的概念 兩種常用的軟件體系結構如圖所示。樹形結構網(wǎng)狀結構8.2 典型的軟件體系結構風格 所謂軟件體系結構風格，是描述某一特定應用領域中系統(tǒng)組織方式的慣用模式。 軟件

11、體系結構風格包含4個關鍵要素：1) 提供一個詞匯表；2) 定義一套配置規(guī)則；3) 定義一套語義解釋規(guī)則；4) 定義對基于這種風格的系統(tǒng)進行的分析。 根據(jù)以上4要素框架，Garlan和Shaw對通用軟件體系結構風格的進行分類，每種體系結構風格有各自的應用領域和優(yōu)缺點。8.2 典型的軟件體系結構風格 8.2.1數(shù)據(jù)流風格數(shù)據(jù)到達即被激活處理工作，無數(shù)據(jù)時不工作。一般來說，數(shù)據(jù)的流向是有序的。在純數(shù)據(jù)流系統(tǒng)中，處理之間除了數(shù)據(jù)交換，沒有任何其他的交互。主要研究近似線性的數(shù)據(jù)流，或在限度內(nèi)的循環(huán)數(shù)據(jù)流。其中包括批處理序列、管道/過濾器。8.2 典型的軟件體系結構風格 8.2.2調(diào)用返回風格 各個構件通

12、過調(diào)用其他構件和獲得返回參數(shù)來進行交互，配合完成功能。包括主程序/子程序、面向對象風格、層次結構。8.2 典型的軟件體系結構風格 8.2.3 獨立構件風格這種風格的主要特點是：事件的觸發(fā)者并不知道哪些構件會被這些事件影響，相互保持獨立，這樣不能假定構件的處理順序，甚至不知道哪些過程會被調(diào)用；各個構件之間彼此無連接關系，各自獨立存在，通過對事件的發(fā)布和注冊實現(xiàn)關聯(lián)，其中包括進程通訊、事件系統(tǒng)。8.2 典型的軟件體系結構風格 8.2.4 虛擬機風格它創(chuàng)建了一種虛擬的環(huán)境，將用戶與底層平臺隔離開來，或者將高層抽象和底層實現(xiàn)隔離開來。其中包括解釋器、基于規(guī)則的系統(tǒng)。8.2 典型的軟件體系結構風格 8.

13、2.5倉庫風格倉庫是存儲和維護數(shù)據(jù)的中心場所。在倉庫風格中存在兩類構件，表示當前數(shù)據(jù)的狀態(tài)的中心數(shù)據(jù)結構和一組對中心數(shù)據(jù)進行操作的獨立構件。其中包括數(shù)據(jù)庫系統(tǒng)、超文本系統(tǒng)、黑板系統(tǒng)。8.3 軟件質量屬性 軟件質量屬性是指軟件系統(tǒng)在其生存周期過程中所表現(xiàn)出的各種特征。質量屬性既和軟件體系結構有關，也和具體實現(xiàn)有關。但軟件設計是保證軟件質量的重要階段，而軟件體系結構是獲取許多質量屬性的基礎，因此在軟件體系結構設計時就應考慮到這些質量屬性， 并在軟件體系結構層次上進行評估。質量屬性可以分為3類：系統(tǒng)屬性、商業(yè)屬性和構架屬性。8.3 軟件質量屬性 系統(tǒng)屬性按運行時是否可見又分為：運行時可觀察到的：包括

14、性能、安全性、可用性、易用性；運行時不可觀察的：包括可修改性、可移植性、可測試性、可集成性、可重用性。 商業(yè)屬性包括投放市場時間、成本和預計的系統(tǒng)生命周期長短。 構架屬性包括軟件體系結構本身的概念完整性、正確性和可構建性。 我們在軟件體系結構設計時除了考慮到系統(tǒng)要實現(xiàn)的功能外，還應充分考慮到系統(tǒng)所要求的各類質量屬性。8.4分布式系統(tǒng)結構 8.4.1多處理器體系結構多處理器系統(tǒng)是分布式系統(tǒng)的最簡單模型，系統(tǒng)同時運行許多進程，這些進程分布在不同的處理器上，可以極大地提高系統(tǒng)的性能。由于大型實時系統(tǒng)對響應時間要求很高，多采用這種模型。大型實時系統(tǒng)需要實時采集信息，并利用采集到的信息進行決策，然后發(fā)送

15、信號給執(zhí)行機構。雖然，信息采集、決策和執(zhí)行可以在一個處理器上統(tǒng)一調(diào)度完成，但多處理器的并行計算比單處理器的分時片計算能夠極大地提高系統(tǒng)的性能，而且可靠度也相對較高。8.4分布式系統(tǒng)結構 8.4.2客戶機/服務器體系結構客戶機/服務器（Client/Server，簡稱C/S）體系結構是為了共享不對等的資源而提出來的，是20世紀90年代成熟起來的技術，C/S體系結構定義了客戶機如何與服務器連接，以將數(shù)據(jù)和應用系統(tǒng)分部到多個處理機上。C/S體系結構有3個主要的組成部分。服務器。負責給其子系統(tǒng)提供服務，如數(shù)據(jù)庫服務器提供數(shù)據(jù)存儲和管理服務，文件服務器提供文件管理服務，搜索服務器提供數(shù)據(jù)檢索等?？蛻魴C。

16、通常是獨立的子系統(tǒng)，通過向服務器請求約定的資源獲取數(shù)據(jù)。一臺服務器可以同時為許多客戶機提供服務。網(wǎng)絡。連接服務器和客戶機。有時客戶機和服務器位于同一臺物理主機上，但多數(shù)情況下它們分布在不同主機上。網(wǎng)絡可以有各種形式，包括有線和無線等。8.4分布式系統(tǒng)結構 C/S系統(tǒng)的設計必須考慮應用系統(tǒng)的邏輯結構。在邏輯上，我們通常將應用系統(tǒng)劃分為3層，即數(shù)據(jù)管理層、應用邏輯層和表示層。數(shù)據(jù)管理層主要處理數(shù)據(jù)存儲和管理操作。應用邏輯層處理與業(yè)務相關的邏輯。表示層處理用戶界面以及用戶的交互。在集中式系統(tǒng)中，不需要將這些清楚地分離，但在分布式系統(tǒng)中，不同層常常被部署在不同的主機上，因此必須嚴格地分離不同層。C/S

17、體系結構通常有兩層或三層，也可根據(jù)需要劃分為更多層。兩層C/S結構一般有兩種形態(tài)。瘦客戶機模型。在瘦客戶機模型中，數(shù)據(jù)管理和應用邏輯都在服務器端執(zhí)行，客戶機只負責表示部分。胖客戶機模型。在這種模型中，服務器只負責對數(shù)據(jù)的管理?？蛻魴C上的軟件實現(xiàn)應用邏輯以及與系統(tǒng)的交互。8.4分布式系統(tǒng)結構 三層C/S結構就避免了這個問題，將數(shù)據(jù)管理層和應用邏輯層分別放在兩個物理層或物理主機上，客戶端仍然保留在客戶機上。對于三層C/S結構，各層的功能或指責如下：表示層。表示層是應用系統(tǒng)的用戶界面部分，擔負著用戶與應用程序之間的對話功能。通常采用圖形界面的方式呈現(xiàn)。應用邏輯層。應用邏輯層為應用系統(tǒng)的主體，包含全部

18、的業(yè)務邏輯。比如數(shù)據(jù)處理，用戶管理，與其他系統(tǒng)交互，以及記錄系統(tǒng)日志等。通常是應用服務器。數(shù)據(jù)層。數(shù)據(jù)層一般只負責數(shù)據(jù)的存取、管理和維護（如備份等），通常是關系型數(shù)據(jù)庫服務器。瀏覽器/服務器（Browser/Server，簡稱B/S）結構是三層應用結構的一種實現(xiàn)，其具體結構為瀏覽器/Web服務器/數(shù)據(jù)庫服務器。8.4分布式系統(tǒng)結構 8.4.3分布式對象體系結構分布式系統(tǒng)設計的更一般方法是去掉客戶機與服務器之間的差異，用分布式對象體系結構來設計系統(tǒng)。分布式對象的實質是在分布式異構環(huán)境下建立應用程序系統(tǒng)框架和對象構件，將應用服務分割成功能獨立的構件，各個構件可以放在同一臺或不同的多臺服務器上運行。

19、構件之間的通信最通常的設計方法是通過一個中間件通信，類似計算機中主板上的數(shù)據(jù)總線。中間件一般稱為軟件總線或對象請求代理，它的作用是在對象之間提供一個無縫接口。分布式對象技術的應用目的主要是為了降低服務器負荷、共享網(wǎng)絡的資源、平衡分配計算任務到不同的主機，提高系統(tǒng)的協(xié)同處理能力。8.4分布式系統(tǒng)結構 8.4.4對等端體系結構對等端體系結構可以視為客戶端/服務器體系結構和分布式對象體系結構的融合。它沒有嚴格的客戶機、服務器劃分，所有的分布的對等端根據(jù)需要既能充當服務器，又能充當客戶端。但有些情況下，對等端體系結構仍然需要設計一個端節(jié)點服務器，用于存儲端節(jié)點信息。在通信之時，對等端首先連接到端節(jié)點服

20、務器上，下載可用的對等端節(jié)點信息。之后的通信就是根據(jù)這些端節(jié)點信息連接到其他對等端請求信息，這時，該節(jié)點常常充當客戶端，其它被請求的端充當服務器。對等端體系結構常常用于數(shù)據(jù)共享類系統(tǒng)的設計。8.4分布式系統(tǒng)結構 8.4.5代理 代理可以用于構件包含隔離組件的軟件系統(tǒng)，軟件通過遠程服務調(diào)用進行交互。代理者負責協(xié)調(diào)通信，諸如轉發(fā)請求和傳遞結果、異常等。 在ORB上有4個對象接口。對象服務。定義加入ORB的系統(tǒng)級服務，如安全性、命名、事務處理，這類與應用領域無關。公共設施。定義應用程序級服務。領域接口。面向特定領域接口。應用接口。面向指定的外界應用，一般是供應商或用戶借助ORB、公共對象服務以及公共

21、設施而開發(fā)的特定產(chǎn)品。8.5體系結構框架 8.5.1模型-視圖-控制器MVC（Model-View-Controller）模型由Trygve Reenskaug博士在20世紀70年代提出，并最早在面向對象編程語言Smalltalk-80中實現(xiàn)。MVC強調(diào)將用戶的輸入、數(shù)據(jù)模型和數(shù)據(jù)表示方式分開設計，一個交互式應用系統(tǒng)由模型、視圖、控制器3部分組成，分別對應內(nèi)部數(shù)據(jù)、數(shù)據(jù)表示和輸入/輸出控制部分。8.5體系結構框架 模型。模型對象代表應用領域中的業(yè)務實體和業(yè)務邏輯規(guī)則，是整個模型的核心，獨立于外在的顯示內(nèi)容和顯示形式。模型對象的變化通過事件通知視圖和控制器對象。采用了發(fā)布者/訂閱者方式，模型是發(fā)

22、布者，視圖和控制器是訂閱者。對于模型來說，并不知道自己對應的視圖控制器；但控制器可以通過模型提供的接口改變模型對象，接口內(nèi)封裝了業(yè)務數(shù)據(jù)和行為。視圖。視圖對象代表GUI對象，以用戶熟悉和需要的格式表現(xiàn)模型信息，是系統(tǒng)與外界的交互接口。視圖訂閱模型可以感知模型的數(shù)據(jù)變化，并更新自己的顯示。視圖對象也可以包含子視圖，用于顯示模型的不同部分。在多數(shù)的MVC實現(xiàn)技術中，視圖和控制器常常是一一對應的?？刂破??？刂破鲗ο筇幚碛脩舻妮斎耄⒔o模型發(fā)送業(yè)務事件，再將業(yè)務事件解析為模型應執(zhí)行的動作；同時，模型的更新與修改也將通過控制器來通知視圖，保持視圖與模型的一致。 8.5體系結構框架 MVC的整個處理流程為

23、：系統(tǒng)攔截到用戶請求，根據(jù)相應規(guī)則（多數(shù)采用路由技術），將用戶請求交給控制器，控制器決定哪個模型來處理用戶的請求；模型根據(jù)業(yè)務邏輯處理完畢后將結果返回給控制器；然后控制器將數(shù)據(jù)提交給視圖；視圖把數(shù)據(jù)組裝之后，呈現(xiàn)給用戶。其中，模型處理所有的業(yè)務邏輯和規(guī)則，視圖只負責顯示數(shù)據(jù)，控制器負責用戶的請求，這樣將業(yè)務和表現(xiàn)層分離，以便業(yè)務代碼可以被用于任何相似的業(yè)務中，視圖代碼也可以根據(jù)需要隨意替換。8.5體系結構框架 8.5.2模型-視圖-表示器模型-視圖-表示器（Model-View-Presenter，簡稱MVP）是近年來流行起來的一種體系結構。從名字上就可以看出，MVP與MVC十分類似，事實也確

24、實如此。甚至有程序員開玩笑說MVP不過是將MVC中的C換成了字母P，這種說法一定程度上確實有其道理。MVP與MVC的的主要差異體現(xiàn)在“請求在何處訪問系統(tǒng)”以及“各部分如何聯(lián)系在一起”。MVP中的視圖比MVC中的視圖更加“被動”，視圖引發(fā)事件，但是由表示器讀取并設置UI的值。事實上，MVP模式設計的目的就是為了增強MVC模式，以嘗試使視圖更加被動，以便更換視圖更加容易。8.5體系結構框架 MVP的處理流程如圖所示。 用戶直接與視圖進行交互（圖中步驟1）。視圖通過引發(fā)一個事件，通知表示器有事件發(fā)生（步驟2），然后表示器訪問視圖通過其IView接口公開的屬性（步驟3）。這些屬性是視圖實際UI元素的包

25、裝器。此后表示器調(diào)用模型（步驟4），再返回結果（步驟5）。表示器轉換數(shù)據(jù)，然后設置UI的值，該操作通過IView接口完成（步驟6）。視圖將最終頁面顯示給用戶。8.5體系結構框架 8.5.3J2EE體系結構框架MVC是很多現(xiàn)代體系結構框架的基礎，主要應用于企業(yè)和電子商務系統(tǒng)中。J2EE的核心體系結構就是在MVC框架的基礎上進行擴展得到的，如圖所示。J2EE模型是分層結構，中間是3層（表示層、業(yè)務層和集成層）包含應用構件，客戶層和資源層處于應用的外圍。8.5體系結構框架 8.5.4PCMEF框架表示-控制-中介-實體-基礎（Presentation-Control-Mediator-Entity-Foundation，簡稱PCMEF）是一個垂直層次的分層體系結構框架。每一層是可以包含子包的包。PCMEF框架包含4層：表示層、控制層、領域層和基礎層。領域層包含兩個預定義的包：實體（Entity）和中介（Mediator）。參考MVC框架，表