《軟件體系結構ppt課件》由會員分享，可在線閱讀，更多相關《軟件體系結構ppt課件（142頁珍藏版）》請在裝配圖網(wǎng)上搜索。

軟件體系結構,劉興 計算機學院軟件工程系,1,軟件體系結構內(nèi)容,1概述 2軟件體系結構風格 3案例研究 4軟件體系結構的分析與評估（略） 5流行的軟件體系結構 6設計模式與軟件架構 7企業(yè)架構師和設計師、企業(yè)軟件架構簡介,2,1概述,我們要學的這個是什么玩意？ 我們?yōu)槭裁匆獙W這個玩意？ 我們將來會怎么干？ 其他人是怎么玩的？,3,1概述,它是一種簡單的、清楚的、完善的方式形成的 軟件工程師需要一種更好的視角來理解軟件，并試圖找到一種新的方法來構建更復雜的大型軟件系統(tǒng) SA (software architecture) 一個簡單程序到復雜系統(tǒng)軟件的距離是十年,4,1概述－需求開發(fā)的主要困難,5,1概述－軟件危機的原因,軟件規(guī)模越來越大 隨著軟件應用范圍的增廣，軟件規(guī)模愈來愈大。大型軟件項目需要組織一定的人力共同完成，而多數(shù)管理人員缺乏開發(fā)大型軟件系統(tǒng)的經(jīng)驗，而多數(shù)軟件開發(fā)人員又缺乏管理方面的經(jīng)驗。各類人員的信息交流不及時、不準確、有時還會產(chǎn)生誤解。 軟件項目開發(fā)人員不能有效地、獨立自主地處理大型軟件的全部關系和各個分支，因此容易產(chǎn)生疏漏和錯誤。,6,1概述－軟件危機的原因,軟件復雜度越來越高 軟件不僅僅是在規(guī)模上快速地發(fā)展擴大，而且其復雜性也急劇地增加。軟件產(chǎn)品的特殊性和人類智力的局限性，導致人們無力處理“復雜問題”。 所謂“復雜問題”的概念是相對的，一旦人們采用先進的組織形式、開發(fā)方法和工具提高了軟件開發(fā)效率和能力，新的、更大的、更復雜的問題又擺在人們的面前。,7,1.1what is SA ？,這種全局結構的設計和規(guī)劃問題包括 全局組織結構；全局控制結構；通信和同步以及數(shù)據(jù)存取協(xié)議；規(guī)定設計元素的功能；設計元素的組合；物理分布；規(guī)模和性能；演化的維度；設計方案的選擇等。 1隨著軟件系統(tǒng)的規(guī)模和復雜性不斷增加，系統(tǒng)的全局結構的設計和規(guī)劃變得比算法的選擇以及數(shù)據(jù)結構的設計更加重要。 2人們普遍認為，為系統(tǒng)設計一個合適的體系結構是系統(tǒng)取得長遠的成功的關鍵因素。 3非形式化的。,8,1.1what is SA ？,形式化還是非形式化 ： 首先，軟件工程師在長期的實踐中已經(jīng)擁有了一套共享的，語義豐富的詞典，它由軟件系統(tǒng)的習慣用語，模式，軟件系統(tǒng)組織結構風格組成。 通過識別一個管道過濾器體系結構風格的實例，一個軟件工程師傳達了這樣的事實：這個系統(tǒng)的主要功能就是進行數(shù)據(jù)流的轉換，系統(tǒng)的主要功能由各種獨立實體的過濾器分別來實現(xiàn)，系統(tǒng)的響應時間和吞吐量能用一種直接的方式計算出來。,9,1.1what is SA ？,e.g. 每個Filter都有輸入端和輸出端，例如一個MPEG-1解碼Filter它的輸入是MPEG編碼的流數(shù)據(jù)，它的輸出端是一解碼過的流數(shù)據(jù)。DirectShow正是通過將不同的Filter連接在一起完成特定的功能的，我們將這些Filter的連接叫做Filter Graph，如下圖A給出是播放AVI的Filter Graph： 圖A 播放AVI文件的Graph Filter圖 上圖中每個模塊分別代表了不同的Filter，媒體文件Filter從硬盤讀取AVI文件，AVI分離 Filter將文件分離為音頻流和視頻流，AVI解碼Filter對視頻流進行解碼并送往Video表現(xiàn)Filter，由后者將各幀在顯示器上顯示，默認的DirectSound設備用DirectSound將音頻流輸出。。,10,1.1what is SA ？,其次，體系結構的描述的作用好像一個框架，系統(tǒng)屬性在這個框架下進行擴充，并且，它在考察一個系統(tǒng)實現(xiàn)其整體需求的能力中扮演了非常重要的作用。 （軟件體系結構是非常抽象的，可以理解更大范圍的，系統(tǒng)級的關注點，比如吞吐量，通信模式，執(zhí)行控制結構，可伸縮性，以及系統(tǒng)演化的擴展方式，提供一個自然的框架。）,11,1.1what is SA ？,軟件系統(tǒng)的體系結構定義系統(tǒng)由計算構件和構件之間的相互作用組成。構件可以是客戶機和服務器、數(shù)據(jù)庫、過濾器或者是在一個分層系統(tǒng)中的層。構件之間的相互作用在這個設計層次上可以是簡單和相似的，比如過程調(diào)用，共享變量的訪問。但是它們也可以是復雜和語義豐富的。比如客戶機－服務器協(xié)議（client－server protocols）數(shù)據(jù)庫存取協(xié)議（database-accessing protocols）,異步事件多點傳送（asynchronous event multicast）和管道數(shù)據(jù)流（piped streams）,12,1.1what is SA ？,軟件設計層次 體系結構級：系統(tǒng)性能與構件之間的整體聯(lián)系。這個級別的構成元素是模塊，模塊通過各種方式互連，通過操作算子將子系統(tǒng)組裝成一個系統(tǒng)。 代碼級：這個級別的設計問題包括算法和數(shù)據(jù)結構；其構成元素是編程語言原語。 執(zhí)行級：這個級別的設計問題包含存儲器的映射、數(shù)據(jù)格式配置、堆棧和寄存器的分配。,13,軟件各級抽象,高級程序設計語言,數(shù)據(jù)結構與算法,軟件結構研究的開始,抽象數(shù)據(jù)類型,程序族,軟件體系結構,,,,,,匯編語言、宏替換、高級語言編譯器、數(shù)據(jù)類型,程序＝數(shù)據(jù)結構＋算法,軟件劃分與構造、方便系統(tǒng)的開發(fā)與維護,數(shù)據(jù)類型抽象、封裝、信息隱藏、多態(tài)性,程序族在信息隱藏和軟件結構設計上具有相同的模式（設計模式抽象）,軟件體系結構使系統(tǒng)在體系結構級達到重用,14,1.1定義,Dewayne Perry和A1exander Wo1f 軟件體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數(shù)據(jù)構件和連接構件。 處理構件負責對數(shù)據(jù)進行加工，數(shù)據(jù)構件是被加工的信息，連接構件把體系結構的不同部分組合連接起來。 這一定義注重區(qū)分處理構件、數(shù)據(jù)構件和連接構件，這一方法在其他的定義和方法中基本上得到保持。,15,1.1定義,Mary Shaw和David Garlan 軟件體系結構是軟件設計過程中的一個層次，這一層次超越計算過程中的算法設計和數(shù)據(jù)結構設計。 體系結構問題包括總體組織和全局控制、通訊協(xié)議、同步、數(shù)據(jù)存取，給設計元素分配特定功能，設計元素的組織，規(guī)模和性能，在各設計方案間進行選擇等。 軟件體系結構處理算法與數(shù)據(jù)結構之上關于整體系統(tǒng)結構設計和描述方面的一些問題，如全局組織和全局控制結構、關于通訊、同步與數(shù)據(jù)存取的協(xié)議，設計構件功能定義，物理分布與合成，設計方案的選擇、評估與實現(xiàn)等。,16,,Kruchten 軟件體系結構有四個角度，它們從不同方面對系統(tǒng)進行描述：概念角度描述系統(tǒng)的主要構件及它們之間的關系；模塊角度包含功能分解與層次結構；運行角度描述了一個系統(tǒng)的動態(tài)結構；代碼角度描述了各種代碼和庫函數(shù)在開發(fā)環(huán)境中的組織。,17,,Hayes Roth 軟件體系結構是一個抽象的系統(tǒng)規(guī)范，主要包括用其行為來描述的功能構件和構件之間的相互連接、接口和關系。,18,,David Garlan 和 Dewne Perry 軟件體系結構是一個程序／系統(tǒng)各構件的結構、它們之間的相互關系以及進行設計的原則和隨時間演化的指導方針。,19,,Barry Boehm 軟件體系結構包括一個軟件和系統(tǒng)構件，互聯(lián)及約束的集合；一個系統(tǒng)需求說明的集合；一個基本原理用以說明這一構件，互聯(lián)和約束能夠滿足系統(tǒng)需求。,20,,Bass，Ctements 和 Kazman 軟件體系結構包括一個或一組軟件構件、軟件構件的外部的可見特性及其相互關系。其中，“軟件外部的可見特性”是指軟件構件提供的服務、性能、特性、錯誤處理、共享資源使用等。,21,1.2軟件體系結構研究的內(nèi)容和范疇,被解決的：模塊接口語言，特定領域的軟件體系結構，軟件的重用，軟件組織結構模式的規(guī)范化編纂，體系結構描述語言，體系結構設計形式化的支持和體系機構設計環(huán)境。 四個研究領域： 1.新的體系機構描述語言來解決體系機構描述問題。 2.體系結構領域知識的總結性研究。這個領域關心的是工程師通過軟件實踐總結而來的各種體系機構原則和模式的分類和闡釋。 3.針對特定的領域的框架的研究。 4.軟件體系結構形式化支持的研究。,22,1.2軟件體系結構研究的內(nèi)容和范疇,風格、設計模式、框架 1.體系結構風格（architecture styles） 體系結構風格獨立于實際問題，強調(diào)了軟件系統(tǒng)中通用的組織結構。比如管道線，分層系統(tǒng)，客戶機－服務器等等。,23,1.2軟件體系結構研究的內(nèi)容和范疇,風格、設計模式、框架 2.設計模式 設計模式是軟件問題高效和成熟的設計模板，模板包含了固有問題的解決方案。設計模式可以看成規(guī)范了的小粒度的結構成分，并且獨立于編程語言或編程范例。設計模式的應用對軟件系統(tǒng)的基礎結構沒有什么影響，但可能對子系統(tǒng)的組織結構有較大影響。每個模式處理系統(tǒng)設計或?qū)崿F(xiàn)一種特殊的重復出現(xiàn)的問題。它為解決抽象部分和實現(xiàn)部分獨立變化的問題提供了一種通用結構。因此，設計模式更強調(diào)直接復用的程序結構。,24,1.2軟件體系結構研究的內(nèi)容和范疇,風格、設計模式、框架 3.應用框架（application framework） 應用框架是整個或部分系統(tǒng)的可重用設計，表現(xiàn)為一組抽象構件的集合以及構件實例間交互的方法。可以說，一個框架是一個可復用的設計構件，它規(guī)定了應用的體系結構，闡明了整個設計、協(xié)作構件之間的依賴關系、責任分配和控制流程。,25,1.2軟件體系結構研究的內(nèi)容和范疇,體系結構風格、設計模式和應用框架的概念是從不同的目的和出發(fā)點討論軟件體系結構，它們之間的概念經(jīng)?；ハ嘟梃b和引用。,26,1.3體系結構設計原則,抽象 分而治之 封裝和信息隱藏 模塊化 高內(nèi)聚和低耦合 關注點分離 策略和實現(xiàn)的分離 接口和實現(xiàn)的分離,27,1.3體系結構設計原則,體系結構是指軟件系統(tǒng)的基本和主體的形態(tài)，也就是軟件系統(tǒng)中“最本質(zhì)”的東西。一個軟件系統(tǒng)的體系結構設計得好不好，可以用“合適性、結構穩(wěn)定性、可擴展性、可復用性”這些特征量來評估。,28,1.3體系結構設計原則,合適性：即體系結構是否適合于軟件的“功能性需求”和“非功能性需求”。,設計師可以充分發(fā)揮主觀能動性，根據(jù)需求的特征，通過推理和歸納的方法設計出合適的體系結構。經(jīng)驗不豐富的設計師往往把注意力集中在“功能性需求”而疏忽了“非功能性需求”，殊不知后者恰恰是最能體現(xiàn)設計水平的地方。 ??高水平的設計師高就高在“設計出恰好滿足客戶需求的軟件，并且使開發(fā)方和客戶方獲取最大的利益，而不是不惜代價設計出最先進的軟件。（以設計住宅為例）… ??對于軟件系統(tǒng)而言，能夠滿足需求的設計方案可能有很多種，究竟該選哪一種？此時商業(yè)目標是決策依據(jù)，即選擇能夠為開發(fā)方和客戶方帶來最大利益的那個設計方案。大部分軟件開發(fā)人員天生有使用新技術的傾向，而這種傾向?qū)﹂_發(fā)商業(yè)產(chǎn)品而言可能是不利的，切記切記,29,,結構穩(wěn)定性,當前中國有幾句流行的至理名言：“穩(wěn)定壓倒一切”、“發(fā)展是硬道理”。發(fā)展的前提條件是穩(wěn)定，社會如此，開發(fā)軟件產(chǎn)品也是如此。 ?體系結構一旦設計完成，應當在一定的時間內(nèi)保持穩(wěn)定不變，只有這樣才能使后續(xù)工作順利開展。如果體系結構經(jīng)常變動，那么建筑在體系結構之上的用戶界面、數(shù)據(jù)庫、模塊、數(shù)據(jù)結構等等也跟著經(jīng)常變動，用“樹倒猢猻散”來比喻很恰當，這將導致項目發(fā)生混亂。 ?高水平的設計師應當能夠分析需求文檔，判斷出哪些需求是穩(wěn)定不變的，哪些需求是可能變動的。于是根據(jù)那些穩(wěn)定不變的需求設計體系結構，而根據(jù)那些可變的需求設計軟件的“可擴展性”。,30,,可擴展性是指軟件擴展新功能的容易程度?？蓴U展性越好，表示軟件適應“變化”的能力越強?？蓴U展性越來越重要，這是由現(xiàn)代軟件的商業(yè)模式?jīng)Q定的： ?社會的商業(yè)越發(fā)達，需求變化就越快。 ?現(xiàn)代軟件產(chǎn)品通常采用“增量開發(fā)模式”，開發(fā)商不斷地推出軟件產(chǎn)品的新版本，從而不斷地獲取增值利潤。 ?穩(wěn)定性和可擴展性之間存在辨證的關系：如果系統(tǒng)不可擴展的話，那么就沒有發(fā)展前途，所以不能只關心穩(wěn)定性而忽視可擴展性；而軟件系統(tǒng)“可擴展”的前提條件是“保持結構穩(wěn)定”，否則軟件難以按計劃開發(fā)出來，穩(wěn)定性是使系統(tǒng)能夠持續(xù)發(fā)展的基礎。所以穩(wěn)定性和可擴展性都是體系結構設計的要素。 ?如果每次變化都導致體系結構發(fā)生大的變動，那簡直就是“傷筋動骨”，這樣的體系結構無疑是敗筆之作。（例如房屋裝修）,31,,復用就是指“重復利用已經(jīng)存在的東西”。被復用的對象可以是有形的物體，也可以是無形的知識財富。復用不是人類懶惰的表現(xiàn)而是智慧的表現(xiàn)。因為人類總是在繼承了前人的成果，不斷加以利用、改進或創(chuàng)新后才會進步。 ??復用的有利于提高產(chǎn)品的質(zhì)量、提高生產(chǎn)率和降低成本。由經(jīng)驗可知，通常在一個新系統(tǒng)中，大部分的內(nèi)容是成熟的，只有小部分內(nèi)容是創(chuàng)新的。一般地可以相信成熟的東西總是比較可靠的（即具有高質(zhì)量），而大量成熟的工作可以通過復用來快速實現(xiàn)（即具有高生產(chǎn)率）。勤勞并且聰明的人們應該把大部分的時間用在小比例的創(chuàng)新工作上，而把小部分的時間用在大比例的成熟工作中，這樣才能把工作做得又快又好。,32,,復用的意義很容易理解，人們也樂意復用以前的成果，但是前提條件是該成果具有比較好的可復用性。可復用性是指成果被復用的容易程度。 ??可復用性是設計出來的，而不是偶然碰到的。要使體系結構具有良好的可復用性，設計師應當分析應用域的共性問題，然后設計出一種通用的體系結構模式，這樣的體系結構才可以被復用。,33,問題回答,架構師與設計師 企業(yè)軟件架構 作業(yè)1：分組 大作業(yè) 作業(yè)2：準備,http://en.wikipedia.org/wiki/Key_Word_in_Context,34,軟件體系結構內(nèi)容,1概述 2軟件體系結構風格 3案例研究 4共享信息系統(tǒng) 5軟件體系結構描述 6軟件體系結構的分析與評估 7特定領域的軟件體系結構 8流行的軟件體系結構,35,2體系結構風格,慣用模式 我們的目的是展示軟件體系結構豐富的選擇空間，以及在這個基礎上對風格選擇的一些權衡。,36,2.1體系結構風格,數(shù)據(jù)流系統(tǒng) 虛擬機 批處理序列 解釋器 管道和過濾器 基于規(guī)則系統(tǒng) 調(diào)用和返回系統(tǒng) 數(shù)據(jù)中心系統(tǒng)（知識庫） 主程序和子程序 數(shù)據(jù)庫 面向?qū)ο笙到y(tǒng) 超文本系統(tǒng) 多級分層 黑板 獨立構件 通訊進程 事件系統(tǒng),37,2.1體系結構風格,設計符號集即構件和連接件的類型是什么？ 被認可的結構模式是什么？ 根本的計算模型是什么？ 最基本的特點是什么？ 使用這種風格的通用例子有哪些？ 使用這種風格有什么優(yōu)點和缺點 通用的規(guī)格說明是什么？,38,2.1體系結構風格,7種通用的風格 管道和過濾器、對象、隱式調(diào)用、層、知識庫、解釋器和過程調(diào)用。,39,構件對輸入流進行內(nèi)部轉換和增量計算，在輸入數(shù)據(jù)流全部處理之前，輸出就已經(jīng)開始了。 重要特點是每個filter必須是一個獨立實體。特別是filter之間無需共享狀態(tài)。,40,2.2管道過濾器（pipes &filters,典型的例子： Unix的shell中編寫的程序通過提供的符號表示要連接的構件和提供運行時機制實現(xiàn)管道。 傳統(tǒng)的編譯器 ：詞法分析、句法分析、詞義分析、代碼生成階段 信號處理領域 并行計算 功能編程 分布式系統(tǒng),41,2.2管道過濾器（pipes &filters,管道過濾器的優(yōu)點： 設計者可以將整個系統(tǒng)的輸入和輸出特性理解為各個過濾器功能的簡單合成。 支持功能模塊的重用：只要相互傳輸?shù)臄?shù)據(jù)格式達成一致，就可以連接在一起。 系統(tǒng)容易維護和擴展：新的過濾器可以加進來，舊的可以被替換 支持某些特定的分析，如吞吐量和死鎖檢測 具有天然的并發(fā)特性，可以獨立運行，也可以和其他過濾器并發(fā)執(zhí)行。,42,2.2管道過濾器（pipes &filters,管道過濾器模式的缺點： 過濾器獨立性強，處理過程成批處理，不適合交互性強的應用 維持兩個相對獨立但有不存在某種關系的數(shù)據(jù)流之間的通訊可能很困難。 根據(jù)實際應用的要求，設計者也需要在數(shù)據(jù)傳輸時被迫使用底層公共命名。增加過濾器本身的復雜性。,43,2.3數(shù)據(jù)抽象和面向?qū)ο蠼M織結構,對象通過函數(shù)和過程調(diào)用來實現(xiàn)交互。這種模式有兩個重要的方面： 對象維護自身表示的完整性（通常是通過保持其表示上的一些不變式來實現(xiàn)的） 這種表示對其他對象是隱藏的。,44,2.3數(shù)據(jù)抽象和面向?qū)ο蠼M織結構,面向?qū)ο笙到y(tǒng)有很多眾所周知的優(yōu)點。由于對象的對客戶隱藏了實現(xiàn)的細節(jié)，所以可以在不影響其客戶的情況下改變對象實現(xiàn)。另外，由于把操作的數(shù)據(jù)和一組存取例程綁定在一起，使得設計者能夠把問題分解成交互作用的代理集合。,45,2.3數(shù)據(jù)抽象和面向?qū)ο蠼M織結構,最大的缺點：當一個對象和其他對象交互（過程調(diào)用），它必須知道其他對象的標識。而在過濾器系統(tǒng)中，過濾器是不需要知道其他過濾器的存在。每當一個對象的標識改變的時候，必須修改那些顯式調(diào)用它的對象。在模塊化語言中，當一個模塊改變后需要修改每一個引用了這個模塊的“導入”列表。,46,2.4事件驅(qū)動，隱式調(diào)用,隱式調(diào)用，響應集成，選擇性廣播。這種模式起源于基于角色的系統(tǒng)，約束滿足性檢查，后臺程序和包交換網(wǎng)絡。 思想是，不直接調(diào)用一個過程，而是發(fā)布或廣播一個或多個事件。系統(tǒng)中的其他構件通過注冊與一個事件關聯(lián)起來的過程，來表示對某一個事件感興趣。當這個事件發(fā)生時，系統(tǒng)本身會調(diào)用所有注冊了這個事件的過程。這樣一個事件的激發(fā)會導致其他模塊中過程的隱式調(diào)用。,47,2.4事件驅(qū)動，隱式調(diào)用,QT的signal與slot,Object1 Signal1 signal2,Object2 Slot1 slot2,Object4 Slot1 Slot2 Slot3,Object3 Signal1,Connect(object1,singal1,object2,slot1),Connect(object1,singal1,object2,slot2),Connect(object1,singal2,object4,slot1),Connect(object3,singal1,object4,slot3),48,2.4事件驅(qū)動，隱式調(diào)用,主要特點： 事件發(fā)布者不知道哪些構件會受到事件的影響，這樣，構件不能對事件的處理順序，或者事件發(fā)生后的處理結果做任何假設。 許多隱式調(diào)用系統(tǒng)也包含顯示調(diào)用（正常的過程調(diào)用）以此作為構件交互的補充形式。,49,2.4事件驅(qū)動，隱式調(diào)用,例子： 編程環(huán)境中工具集成 數(shù)據(jù)庫管理系統(tǒng)中的一致性約束 用戶界面中數(shù)據(jù)表示與管理數(shù)據(jù)的應用程序的分離 語法導向的增量語義檢查,50,2.4事件驅(qū)動，隱式調(diào)用,優(yōu)點： 它提供了對重用非常好的支持。通過注冊一個系統(tǒng)事件，任何一個構件可以很容易的引入到系統(tǒng)中來。 能簡化系統(tǒng)的演化。在不改變系統(tǒng)中其他構件接口的情況下，構件可以非常容易的被其他構件取代。,51,2.4事件驅(qū)動，隱式調(diào)用,缺點： 構件放棄了自身對系統(tǒng)的計算的控制。當一個構件發(fā)布一個事件，它不能保證保證其他構件會對其作出響應。即使它能夠肯定該事件會被其他構件響應，它也不能依賴事件被處理的先后順序。 在數(shù)據(jù)交換方面，有時數(shù)據(jù)通過事件傳遞，但在某些情況下，事件系統(tǒng)必須依賴一個共享緩沖區(qū)，這樣整體的性能和資源的管理可能成為關鍵性問題。(ip) 正確性驗證也可能是問題，因為發(fā)布事件的過程的具體含義與事件激發(fā)的上下文有關。,52,2.5分層系統(tǒng)（LAYERED SYSTEMS）,一個分層系統(tǒng)是按照層次結構組織的，每一層向它的上層提供服務，同時它又是下層的客戶。在某些分層系統(tǒng)中，內(nèi)層只對其相鄰的層和某些用于輸出的函數(shù)是可見的，對其他外部的層是隱藏的。在這些系統(tǒng)中，構件在某些層中實現(xiàn)虛擬機。,53,2.5分層系統(tǒng)（LAYERED SYSTEMS）,,應用系統(tǒng)層,用戶,,基本功能層,內(nèi)核層,過程調(diào)用,過程調(diào)用,,,54,2.5分層系統(tǒng)（LAYERED SYSTEMS）,例子： 最著名的例子是分層通信協(xié)議 數(shù)據(jù)庫系統(tǒng) 操作系統(tǒng),55,2.5分層系統(tǒng)（LAYERED SYSTEMS）,性質(zhì)特點： 它支持逐級抽象的系統(tǒng)設計 它支持擴展，每層最多和上下兩層交互 它支持重用 。這使得定義標準層接口成為可能，在此接口上可建立不同實現(xiàn)。（OSI的ISO模型和X WINDOW SYSTEM）,56,2.5分層系統(tǒng)（LAYERED SYSTEMS）,缺點： 并不是所有的系統(tǒng)都容易用這種模式來構建。從性能的考慮，也需要將邏輯上高層次的功能與相對低層次的實現(xiàn)結合起來。 很難定義一個合適的抽象層次可能會非常困難。,57,2.6知識庫（REPOSITORIES）,由兩種截然不同的功能構件：一個是中央數(shù)據(jù)結構構件，代表系統(tǒng)當前狀態(tài)，另一個是一些相對獨立的構件的集合，這些構件對中央數(shù)據(jù)存儲進行操作。 控制方式的選擇將知識庫分成了兩種主要的子類。輸入流中事務觸發(fā)系統(tǒng)相應的進程執(zhí)行，是傳統(tǒng)的數(shù)據(jù)庫型知識庫。由中心數(shù)據(jù)結構的當前狀態(tài)觸發(fā)系統(tǒng)相應的進程執(zhí)行，這種稱為黑板知識庫,58,2.6知識庫（REPOSITORIES）－黑板體系結構,黑板（共享數(shù)據(jù)）,KS1,KS8,KS7,KS6,KS5,KS4,KS3,KS2,,,,,,,,,Knowledge source,直接存取,計算,59,2.6知識庫（REPOSITORIES）－黑板體系結構,黑板系統(tǒng)傳統(tǒng)上應用在復雜信號處理解釋上，比如語音和模式識別。 通過松散連接代理共享數(shù)據(jù) 集成編程環(huán)境 編譯器（以共享信息為基礎）,60,2.7解釋器（INTERPRETERS）,通常有一個虛擬機。一個解釋器包括正在被解釋執(zhí)行的偽碼和解釋引擎本身。包含四個部分：完成解釋工作的解釋引擎，一個包含將被解釋的偽碼的存儲區(qū)，一個紀錄解釋引擎當前工作狀態(tài)的數(shù)據(jù)結構，以及一個紀錄源代碼被解釋執(zhí)行的進度的數(shù)據(jù)結構。,61,2.7解釋器（INTERPRETERS）,被解釋的程序 （偽碼）,數(shù)據(jù) （程序狀態(tài)）,解釋引擎,內(nèi)部解釋器狀態(tài),,,,,,,,選擇的指令和數(shù)據(jù),輸入,輸出,62,2.8過程控制,過程控制環(huán)路。這種模式在軟件開發(fā)團隊中并沒有受到廣泛的認可，不象面向?qū)ο蠡蚬δ茉O計那樣以出現(xiàn)的某類構件為特征，控制環(huán)路設計的特點是不僅具有某類構件，還具有在構件間必須保持的特殊關系。,63,2.9異構體系結構,大多數(shù)系統(tǒng)都是由很多風格組合而成的 一種是使用層次結構 一種是允許單一的構件使用復合的連接件。 第三種組合方法是，用完全不同的體系結構風格來闡述體系結構的一個角度。,64,2.10其他常見的體系結構,分布式處理（比如心跳算法） 主程序/子程序組織結構 特定領域的軟件體系結構（參考模型） 狀態(tài)轉換系統(tǒng)（State Transition System）,65,軟件體系結構內(nèi)容,1概述 2軟件體系結構風格 3案例研究 4共享信息系統(tǒng) 5軟件體系結構描述 6軟件體系結構的分析與評估 7特定領域的軟件體系結構 8流行的軟件體系結構,66,3.0案例分析－上下文關鍵字,Key Word in Context From Wikipedia, the free encyclopedia Jump to: navigation, search KWIC is an acronym for Key Word In Context, the most common format for concordance lines. The term KWIC was first coined by Hans Peter Luhn. [1] A KWIC index is formed by sorting and aligning the words within an article title to allow each word (except the stop words) in titles to be searchable alphabetically in the index. It was a useful indexing method for technical manuals before computerized full text search became common. For example, the title statement of this article and the Wikipedia slogan would appear as follows in a KWIC index. A KWIC index usually uses a wide layout to allow the display of maximum 'in context' information (not shown in the following example).,http://en.wikipedia.org/wiki/Key_Word_in_Context,http://www.cs.cmu.edu/~ModProb/KWIC.html,67,3.0案例分析－上下文關鍵字,68,3.0案例分析－上下文關鍵字 需求分析,處理算法的變更 比如輸入設備可以每讀入一行就執(zhí)行一次移動，也可以讀完所有行再執(zhí)行行移動，或者在需要以字母表的順序排列行集合時才執(zhí)行行移動。 數(shù)據(jù)表示的變更 比如，行，單詞和字母可以用各種各樣的方式存儲。類似的，循環(huán)移動情況也可以被顯示的或者隱式存儲（使用索引和偏移量）,69,3.0案例分析－上下文關鍵字 需求分析,系統(tǒng)功能的擴充 比如，修改系統(tǒng)使其能夠排除以某些干擾單詞（a，an）開頭的循環(huán)移動。把系統(tǒng)變成交互式的，允許用戶從初始列表中（或者從循環(huán)移動的列表中）刪除某些行。 性能：空間和時間。 重用：作為可重用的實體，構件重用的程度。,70,3.0案例分析－上下文關鍵字 解決方案1,使用共享數(shù)據(jù)的主程序/子程序 根據(jù)四個基本功能將問題分解為：輸入、移動、按字母表排序、輸出。所有計算構件作為子程序協(xié)同工作，并且由一個主程序順序地調(diào)用這些子程序。構件通過共享存儲區(qū)（核心存儲區(qū)）交換數(shù)據(jù)。 因為是順序訪問，使得計算構件和共享數(shù)據(jù)之間基于一個不受約束的讀寫協(xié)議的通信成為可能。,71,3.0案例分析－上下文關鍵字 解決方案1,輸入,循環(huán)移動,按字母表排序,輸出,字符,索引,按字母表索引,輸入媒介,輸出媒介,主控制,,,,,,,,,,,,,使用共享數(shù)據(jù)的主程序/子程序,72,3.0案例分析－上下文關鍵字 解決方案1,優(yōu)點：不同的計算功能被劃分到不同的模塊中 缺點：數(shù)據(jù)存儲格式的變化會影響到所有模塊。整體處理算法的變更和系統(tǒng)功能擴充的問題也很難調(diào)和。不支持重用。,73,3.0案例分析－上下文關鍵字 解決方案2,抽象數(shù)據(jù)類型 數(shù)據(jù)不在共享，每個模塊提供一個接口，該接口允許其他構件通過調(diào)用接口中的過程來訪問數(shù)據(jù)。,74,3.0案例分析－上下文關鍵字 解決方案2,主控制,輸入,輸出,輸入媒介,輸出媒介,,,,,,,字符,,設置字符,字符,單詞,循環(huán)移動,,設置字符,字符,單詞,設置,,,按字母次序移動,字母,第I個,,,抽象數(shù)據(jù)類型,75,3.0案例分析－上下文關鍵字 解決方案2,優(yōu)點：將系統(tǒng)邏輯上分成了幾個處理模塊。然而，當設計變更時，這種方案比第一種具有一定優(yōu)勢。特別是，在一個獨立的模塊中算法和數(shù)據(jù)表示的改變不會影響其他模塊。另外，為重用提供了更好的支持。 缺點：并不能很好地適合于功能擴展的情況。主要問題是，向系統(tǒng)中加入一個新的功能時，實現(xiàn)者要么平衡其簡介性和完整性而修改現(xiàn)存模塊，要么添加新的模塊而導致性能下降。,76,3.0案例分析－上下文關鍵字 解決方案3,輸入,循環(huán)移動,按字母表排序,輸出,輸入媒介,輸出媒介,主控制,,,,,,,,使用共享數(shù)據(jù)隱式調(diào)用,,,,行,,插入,刪除,第一個,行,,刪除,第一個,插入,,,77,3.0案例分析－上下文關鍵字 解決方案3,采用共享數(shù)據(jù)的構件集成方式。 兩個主要不同。 數(shù)據(jù)訪問接口更加抽象 數(shù)據(jù)被修改時，計算被隱式地調(diào)用。,78,3.0案例分析－上下文關鍵字 解決方案3,優(yōu)點：容易支持系統(tǒng)功能擴展，通過注冊，添加的模塊很容易和系統(tǒng)整合，當發(fā)生數(shù)據(jù)交換事件時，這些添加的模塊就會被調(diào)用。因為數(shù)據(jù)被抽象訪問，所以這種解決方案也將計算和數(shù)據(jù)表示分開。也支持重用。 難以控制隱式調(diào)用模塊的處理順序。數(shù)據(jù)驅(qū)動，會占用更大的空間。,79,3.0案例分析－上下文關鍵字 解決方案４,管道過濾器,輸入媒介,輸入,,,循環(huán)移動,,,,,,按字母表順序排序,,輸出,輸出媒介,,80,3.0案例分析－上下文關鍵字 解決方案４,特性：首先，它能夠維持處理的自然流動。第二，它支持重用，因為每個過濾器可以獨立處理。通過在處理序列中的合適位置插入過濾器，新的功能很容易加入系統(tǒng)中。第三，既然每個過濾器和其他過濾器在邏輯上是獨立的，那么每個過濾器也很容易替換或修改。,81,3.0案例分析－上下文關鍵字 解決方案４,缺點： 首先，不可能通過修改使其支持交互。比如，刪除一行可能需要一些持久性共享存儲區(qū)，但是這樣就違反了這種方案的基本原則。第二，這種方案空間使用的效率非常低。因為每個過濾器必須復制所有的數(shù)據(jù)到它的輸出端口。,82,3.0案例分析－上下文關鍵字 方案比較,共享數(shù)據(jù)方案對整體處理算法、數(shù)據(jù)表示的變更以及重用的支持比較弱。另一方面，由于對數(shù)據(jù)的直接共享，獲得了相對好的性能。另外，相對比較容易加入新的處理構件。 抽象數(shù)據(jù)類型方案在保證性能的情況下，允許數(shù)據(jù)表示變更并且支持重用。但是由于構件的交互依賴于模塊本身，所以改變整體處理算法或者加入新的功能可能要對現(xiàn)有的系統(tǒng)作很大的修改。 隱式調(diào)用方案對于添加新的功能的支持非常好。然而，由于共享數(shù)據(jù)自身的一些問題，該方案對于數(shù)據(jù)表示和重用的支持非常弱。它可能引起額外的執(zhí)行開銷。管道過濾器方案允許在文本處理流中放置新的過濾器。因此它支持處理算法的改變、功能的變化和重用。 管道過濾器允許在文本處理流中放置新的過濾器，因此它支持處理算法的改變，功能的變化和重用。數(shù)據(jù)表示的選擇過分依賴于管道中傳輸?shù)臄?shù)據(jù)類型的假定。而且對管道中的數(shù)據(jù)進行編碼和解碼需要額外的開銷。,83,3.0案例分析－上下文關鍵字 方案比較,共享數(shù)據(jù),抽象數(shù)據(jù)類型,隱式調(diào)用,管道過濾器,算法變更,數(shù)據(jù)表示變更,功能變更,性能,重用,—,—,—,—,—,—,—,—,—,—,＋,＋,＋,＋,＋,＋,＋,＋,＋,＋,84,3.１案例分析－儀器儀表,為Tektronix公司開發(fā)一種可重用的體系結構 需求：對電信號進行取樣，并且在屏幕上顯示電信號的圖像，完成大量的測量，提供兆字節(jié)的內(nèi)存，支持工作站和其他儀器的接口，完善的界面，菜單和觸摸屏、內(nèi)置的HELP……,85,3.１案例分析－儀器儀表,需求： 幾乎沒有在不同的示波器上可重用的軟件組織結構。 性能問題越來越嚴重。不能被快速配置。 （也碰到過：網(wǎng)絡測試儀表、兩個不同的平臺）,86,3.１案例分析－儀器儀表,面向?qū)ο竽Ｐ停▍⒖嘉臋n）,示波器對象,波形,最大最小波形,X-Y波形,疊加波形,,,,,,87,3.１案例分析－儀器儀表,但是沒有一個整體模型解釋怎么結合這些對象類型。這會導致功能劃分的混亂。比如量度是否應該與被測量的或者被外部表示的數(shù)據(jù)類型相關聯(lián)？用戶界面應該和哪些對象交互？,88,3.１案例分析－儀器儀表,分層模型 第二階段嘗試了解決這些問題。,,,,,,硬件,數(shù)字化,可視化,用戶接口,操作,89,3.１案例分析－儀器儀表,在應用領域是錯誤的。 主要問題是層次間強加的抽象邊界和各種功能交互的需要是相互沖突的。 用戶需要跟各層打交道，比如在信號處理層中設置衰減，在采集層中選擇采集模式和參數(shù)，或者在波形處理層中制作導出波形。,90,3.１案例分析－儀器儀表,管道過濾器模型,耦合,采集,To-xy,裁減,,信號,觸發(fā)子系統(tǒng),,,,,,,測量,,測量值,,,,91,3.１案例分析－儀器儀表,沒有在功能劃分中將各個功能孤立起來，模型允許各個構件靈活混合和替換。 問題：沒有清晰說明用戶怎么與其交互。如果用戶僅僅是等待結果，那么比分層還要糟糕。 改進。。。。。？？？？？,92,3.１案例分析－儀器儀表,改進后的FILTER,耦合,采集,To-xy,裁減,,信號,觸發(fā)子系統(tǒng),,,,,,,測量,,測量值,,,,耦合度,種類速率,轉換,大小,,,,,,93,3.１案例分析－儀器儀表,專用化模型 顯著問題：計算模型的性能非常差。特別是波形數(shù)據(jù)占用了很大的內(nèi)存容量。每個過濾器的處理速率是不同的。 解決方法：一些FILTER不用復制數(shù)據(jù)，一些允許慢速過濾器在數(shù)據(jù)還沒有處理完時忽略新來的數(shù)據(jù)。,94,3.１案例分析－儀器儀表,小結： 在工業(yè)設計體系結構中，必須將“純”的體系結構風格改造成專用的風格來滿足特定領域的需要。,95,3.2案例分析－移動機器人,簡介：移動機器人用來操縱有人駕駛或部分地有人駕駛的交通工具。 這類系統(tǒng)在諸如空間探索、有害垃圾處理、深水探索等領域得到了新的應用。,96,3.2案例分析－移動機器人,軟件功能： 采集從傳感器發(fā)送來的輸入信號， 操縱車輪和其他可移動零件的運動， 規(guī)劃未來的移動路線。 －》使任務變復雜： 障礙物可能會阻擋機器人的移動路線； 傳感器的輸入信號可能非常弱； 機器人的電力使用完； 機器的局限性會限制移動的精確性； 機器人可能會處理有毒的材料； 不可預知的事件要求它具有快速響應。,97,3.2案例分析－移動機器人,設計考慮因素：對體系結構的幾個基本需求 需求１：必須能夠協(xié)調(diào)有準備的行為和反應行為。（完成規(guī)定動作） 需求２：必須能夠處理不確定性。機器人能夠應對不完整的或不可靠的信息。 需求３：能應對固有的危險?？紤]容錯度、安全性和性能，這個體系結構必須能夠保持完整性。（電力下降、有毒氣體） 需求４：設計者靈活性。需要經(jīng)常實驗和重新配置。任務的改變要定期的修改。 當然有環(huán)境問題。不同的使用環(huán)境是不同的要求。,98,3.2案例分析－移動機器人,考察四種設計： Lozano的控制環(huán)路 Elfes的分層組織結構 Simmons的任務控制體系結構 Shafer的黑板組織結構應用,99,3.2案例分析－移動機器人,方案１控制環(huán)路 開始是開環(huán)的。（不需要檢查結果）因此需要改進成閉環(huán)的。,機器人的活動組件,傳動裝置,傳感器,控制器,外界環(huán)境,,,,,動作,反饋,100,3.2案例分析－移動機器人,控制環(huán)路對需求的滿足： 需求１：結構簡單，機器人與外界的交互非常清晰。然而在不可預知的環(huán)境中這種簡單性也是它的缺陷。對于復雜的任務，控制環(huán)路并沒有給出將軟件分解成幾個協(xié)作構件的方法。,101,3.2案例分析－移動機器人,需求２：對于不確定性，控制環(huán)路偏愛使用下述方法來解決。通過迭代來降低未知性。試探和錯誤處理程序通過動作和響應來消除每次循環(huán)中的可能性。（沒有使用基本循環(huán)集成這些操作的框架，也沒有提供委托獨立實體進行操作的框架）,102,3.2案例分析－移動機器人,需求３：這種閉環(huán)范例提供對容錯度和安全性的支持。因為它的結構簡單，使得復制操作更加容易，并能減少系統(tǒng)中錯誤發(fā)生的幾率。,103,3.2案例分析－移動機器人,需求４：主要構件（監(jiān)視器、傳感器、發(fā)動機）是彼此分開的，并能夠被獨立地替換。微小的修改必須在模塊中進行。,104,3.2案例分析－移動機器人,方案２分層體系結構,監(jiān)督,全局技術,控制,導航,現(xiàn)實世界建模,傳感器集成分析,傳感器解釋分析,機器人控制,外界環(huán)境,這種定義也影響了Dolphin聲納和導航系統(tǒng)的設計，并在Terregator Neptune移動機器人上,駐留機器人控制程序（發(fā)動機，關節(jié)等）,處理外界的輸入（分析單個，集成分析）,維持機器人的外界模型,負責調(diào)度和安排機器人行動。處理問題和重新安排,用戶界面和全局監(jiān)控,105,3.2案例分析－移動機器人,分層 需求１：通過定義更多的執(zhí)行委托任務的構件,Elfes的模型避開了一些控制環(huán)路方案面臨的問題。因為這個模型專用于自動控制的機器人，所以它揭示了針對這種機器人所必須解決的問題。（如傳感器集成）另外它定義了抽象層來指導設計。,106,3.2案例分析－移動機器人,需求１：雖然這種模型很好的組織了用來協(xié)調(diào)機器人操作的構件，但是這種分層體系結構并不適合現(xiàn)行的數(shù)據(jù)和控制流模式。因為，分層模型要求請求和服務必須在相鄰的兩層進行。 現(xiàn)實中，比如需要快速響應的數(shù)據(jù)應該直接從傳感器送到位于7層的問題處理代理那里。并且相應的命令也應該跳過好幾層及時到達發(fā)動機。,107,3.2案例分析－移動機器人,另一問題：不能區(qū)分實際存在兩個抽象層次。 數(shù)據(jù)層： 原始的傳感器輸入（第1層） 解釋后和集成后的結果（第2層和第3 層）、最終的外界模型（第4層） 控制層： 包括發(fā)動機控制（第1層）、導航（第5層）、調(diào)度（第6層）、安排（第7層）、用戶層控制（第8層）。,108,3.2案例分析－移動機器人,需求２：抽象層的存在滿足了處理不確定性的需要：通過在較高層加入可以用到的知識，使得在最低層中的不確定的事物在較高層中會變得確定。比如外界模型中的上下文能夠提供某些線索來消除相對矛盾的傳感器數(shù)據(jù)中的歧義。,109,3.2案例分析－移動機器人,需求3： 抽象機制滿足了容錯度和被動的安全性（你什么也不做）的要求?？梢詮牟煌嵌确治鰯?shù)據(jù)和命令。將多個檢查和平衡操作合并到系統(tǒng)中是可能的。就象已經(jīng)提到的，性能和主動安全性需要縮短通訊路徑。,110,3.2案例分析－移動機器人,需求4： 層次間的依賴性使得構件的替換和添加更加困難。另外，層次間復雜的關系使得解讀每一次變化都會令人頭疼。,111,3.2案例分析－移動機器人,方案３：隱式調(diào)用 內(nèi)嵌于任務控制體系結構（Task-Control Architecture）,task,task,task,task,task,,,異常,消息,,分支的消息,,,竊聽,,112,3.2案例分析－移動機器人,方案３：隱式調(diào)用 內(nèi)嵌于任務控制體系結構（Task-Control Architecture） 任務樹,采集巖石,到位置,取石子,舉起巖石,左移,前移,,,,,,113,3.2案例分析－移動機器人,TCA的三種功能： 異常（exception） 竊聽（wiretapping） 例如一個安全性檢查的構件能夠根據(jù)這種特點驗證輸出的移動命令。 監(jiān)控器（Monitor） 如果數(shù)據(jù)滿足某一標準，監(jiān)控器就可以讀取信息，然后去執(zhí)行某些操作。比如監(jiān)控器檢測到電量低于一個給定值，就會調(diào)用負責充電的動作。這個特點提供了一個處理容錯度問題的簡便方法。放置一個代理來監(jiān)控系統(tǒng)。,114,3.2案例分析－移動機器人,隱式調(diào)用 需求１：一方面是任務樹，另一方是異常、竊聽、監(jiān)控器，這些為動作和響應提供了清晰的劃分。可以進行并發(fā)處理。多個任務是相互獨立的。,115,3.2案例分析－移動機器人,隱式調(diào)用 需求2：TCA解決不確定性是不夠清晰的。如果存在不可估計的情況，會創(chuàng)建一個試驗性的任務樹，如果任務樹中基本假設被證明是錯誤的，那么異常處理程序會不斷的修改它直到正確為止。,116,3.2案例分析－移動機器人,隱式調(diào)用 需求3 TCA異常、竊聽、監(jiān)控器特點使其考慮了性能、安全性、容錯度這些問題。 當為同一個信號注冊多個處理者時，通過冗余來實現(xiàn)容錯。,117,3.2案例分析－移動機器人,隱式調(diào)用 需求4 使用隱式調(diào)用使得增量開發(fā)和構件的替換更為直接。在不影響現(xiàn)有構件的情況下，很容易在中心服務器注冊新的處理者、異常、竊聽器或監(jiān)控器。,118,3.2案例分析－移動機器人,方案４：黑板體系結構,lookout,caption,Map navigator,pilot,黑板,,,,,,感知子系統(tǒng),,,,,,,,,Caption：：總監(jiān)視器 MN：高層路線規(guī)劃程序 Lookout：為獲取路標而監(jiān)控環(huán)境的模塊 Pilot：底層的路線規(guī)劃程序和發(fā)動機控制器 感知子系統(tǒng)：這個模塊接收來自多個傳感器的原始輸入并將它們整合成一致的解釋,119,3.2案例分析－移動機器人,黑板體系結構 需求１：構件（感知子系統(tǒng)中的模塊）通過黑板系統(tǒng)的共享知識庫來進行通信。每個模塊只對某種信息感興趣。數(shù)據(jù)庫可以立刻向這些模塊發(fā)送它們需要的信息，或者在這些模塊向數(shù)據(jù)庫插入這些信息后，再向這些模塊發(fā)送它們需要的信息。,120,3.2案例分析－移動機器人,黑板 需求2：黑板也是一種解決矛盾和不確定性情況的方式。,121,3.2案例分析－移動機器人,黑板 需求3：通過數(shù)據(jù)庫進行通信和通過TCA中心消息服務器進行通信的方式非常相似。,122,3.2案例分析－移動機器人,黑板： 需求4 和TCA一樣，黑板體系結構風格支持并發(fā)以及發(fā)送者和接受者分離，這樣有利于維護。 總之，基于數(shù)據(jù)庫內(nèi)容的隱式調(diào)用機制、黑板體系結構具有模擬任務協(xié)作的能力，滿足了以靈活的方式處理協(xié)調(diào)和解決不確定性的需求。,123,3.2案例分析－移動機器人,循環(huán)控制,分層,隱式調(diào)用,黑板,任務協(xié)調(diào),處理不確定性,故障容忍,安全,性能,適應性,＋－,＋,++,＋,－,＋—,＋－,＋－,＋—,＋＋,＋,＋－,＋－,＋＋,＋,＋－,＋－,＋＋,＋,＋－,＋,＋,＋,－,124,3.3定速巡航控制,目的：怎么將控制環(huán)路范例應用到一個簡單的問題中，這個問題傳統(tǒng)上使用面向?qū)ο蟮姆椒ㄟM行處理。 控制環(huán)路體系結構的使用，有利于闡明體系結構對于問題解決所起的重要作用。,125,3.3定速巡航控制,巡航控制系統(tǒng),系統(tǒng)開關,引擎開關,車輪脈沖,加速度,剎車,增減速,恢復速度,時鐘,,,,,,,,,,油門,126,3.3定速巡航控制,車輪,當前車速,時鐘,期望速度,油門,司機,剎車,發(fā)動機,加速器,,,,,,,,,,面向?qū)ο蟮姆椒?127,3.3定速巡航控制,控制環(huán)路方法,,引擎,,油門設定,,,,期望速度,活躍閑置肘,,車輪轉動,,,,控制器,128,3.3定速巡航控制,激活狀態(tài)機,非活動加速,活動,非活動減速,非活動零,關閉,,,,,,,,,加速度設定點,加速度設定點,恢復,剎車,系統(tǒng)開,引擎開,所有狀態(tài),除關閉外的所有狀態(tài),系統(tǒng)關閉,引擎關,129,4軟件架構的評估,,130,5流行的軟件體系結構,需求： 提供一種手段，使應用軟件可以預先編好的，功能明確的產(chǎn)品部件定制而成，并可用不同版本的部件實現(xiàn)應用的擴展和更新。 利用模塊化的方法，將復雜的難以維護的系統(tǒng)分解為互相獨立、協(xié)同工作的部件，并努力使這些部件可反復重用。 突破時間、空間及不同硬件設備的限制，利用客戶和軟件之間統(tǒng)一的接口實現(xiàn)跨平臺的互操作。,131,5流行的軟件體系結構,CORBA 規(guī)范 Sun的java平臺 Microsoft的.NET平臺,132,5流行的軟件體系結構,這兩種體系結構提供的技術服務， 例如：事務的完整性、消息傳遞和目錄服務、安全、異常處理、遠程訪問，以及許多其他服務，它們使開發(fā)人員能夠?qū)⒆⒁饬性跇嫾墓δ苌?，而無需關注工作需要的所有底層技術基礎。,133,5.1基于CORBA的分布式構件技術,OMG OMA :三種對象 CORBA服務 CORBA設備 應用對象,134,5.1基于CORBA的分布式構件技術,對象請求代理（Object Request Broker）,CORBA 服務,應用對象,CORBA 服務,CORBA 服務,垂直CORBA設備 facility,水平CORBA設備,,,,,,,OMA對象管理體系結構,135,5.1基于CORBA的分布式構件技術,Corba規(guī)范包括：ORB,IDL(接口定義語言),存根(STUB)和框架（SKELETON)、對象適配器、動態(tài)調(diào)用接口。,136,5.1基于CORBA的分布式構件技術,CORBA 體系結構,接口庫,客戶端程序,對象請求中間件核心（ORB CORE）,實現(xiàn)庫,對象適配器,客戶stub,動態(tài)調(diào)用,ORB接口,,,,,,,對象實現(xiàn)（server）,動態(tài)服務,靜態(tài)服務,,,,137,5.1基于CORBA的分布式構件技術,一個從客戶程序發(fā)送到對象實現(xiàn)的請求,客戶端程序,,請求,Object Request Broker,IDL STUB,IDL STUB,,,,,對象實現(xiàn),138,5.2基于JAVA的分布式構件技術,客戶端應用程序,動態(tài)HTML頁面,動態(tài)HTML頁面,客戶層,JSP頁面,EJB,JSP頁面,EJB,WEB層,業(yè)務層,EIS層,數(shù)據(jù)庫,數(shù)據(jù)庫,數(shù)據(jù)庫,139,5.3基于.NET平臺的分布式構件技術,VB C++ C# PERL,WEB 服務 用戶界面 ,數(shù)據(jù)和XML(ADO.NET),類庫（CLASS LIBRARY）,通用語言運行時（Common Language Runtime）,Visual studio .net,140,5.4面向服務的體系結構,服務注冊,服務消費者,服務提供者,服務注冊,服務,服務描述,,,,綁定與調(diào)用,發(fā)布,發(fā)現(xiàn),141,5.4面向服務的體系結構,實現(xiàn)的核心技術 1)XML 2)SOAP 3)WSDL 4)UDDI(Universal Description Discovery and Integration),142,