軟體體系結構復習

軟體體系結構 原理、方法與實踐（第三版 張）

第一章

軟體危機的表現和產生原因？軟體危機的特征

表現：

1）軟體成本日益增加：開發、部署和應用成本高

2）開發進度難以控制：無法按時完成

3）軟體質量差：錯誤率高，無法滿足用戶需求，沒有生命力

4）軟體維護困難：成本高，維護效果不理想，還有可能有潛在錯誤

產生原因：

1）用戶要求不明確

2）缺乏正確的理論引導

3）軟體規模越來越大

4）軟體復雜度越來越高

軟體危機與體系結構之間關系

20世紀60年代的軟體危機使得人們開始重視軟體工程的研究.起初,人們把軟體設計的重點放在資料結構和演算法的選擇上,隨著軟體系統規模越來越大,越來越復雜,整個系統的結構和規格說明顯得越來越重要.在此背景下,人們認識到對軟體體系結構系統進行深入研究將成為提高軟體生產率和解決軟體維護問題的新的最有希望的途徑，

即軟體危機的出現導致人們開始重視對軟體工程的研究，隨著系統規模的越來越大，人們也開始意識到對軟體體系結構研究的重要性，

P27題4 基于構件的軟體開發的優勢，面臨哪些挑戰和困難

優勢：基于構件的軟體將軟體開發的重點從程式撰寫轉移到了基于已有構件的組裝，更快地構造系統，減輕用來支持和升級大型系統所需要的維護負擔，從而降低了軟體開發的費用困難和挑戰：沒有可依據的參考，可用資源和環境缺乏，開發難度高，而各方面需求增長速度與日劇增，更新和升級的跟進是一個不小的挑戰.此外，在同一系統采用多個開發商提供的構件，它們之間的兼容性可能是開發程序中所要面對的一個嚴峻的問題

挑戰和困難：

（1）在同一系統采用多個開發商提供的構件，它們之間的兼容性可能是開發程序中所要面對的一個嚴峻的問題；

（2）采用隨處可以購買到的構件可能會使開發出來的軟體產品喪失技術上的獨創性和市場上的競爭力；（3）第三方的構件開發商可能歇業，這會使購買的構件失去維護服務，這些都是在購買第三方構件進行軟體開發時無法回避的問題，因此需要對這些風險進行充分的估計，

構件與重用的關系與定義

1、重用定義：重用是指在兩次或多次不同的軟體開發程序中，重復使用相同的或者相近軟體元素的程序；

2、構件定義：具有一定的功能，能夠獨立作業或者能夠同其他構件裝配起來進行協調作業的程式體；

3、兩者關系：要真正解決軟體危機，就要實作軟體的工業化生產，其中構件是核心和基礎，重用是必需的手段，構件開發的目的是重用，重用技術的基礎是構件，只有存在大量的可重用的構件，才能有效使用重用技術，

獲取構件的主要途徑

1、在現有的構件中搜尋，直接使用或修改后使用
2、通過遺留工程，將有重用價值的構件重用后使用
3、從市場上購買現成的商業構件
4、開發新構件

P27 題7 軟體體系結構的定義眾多，你是如何理解軟體體系結構的（意義）？軟體體系結構在軟體系統中有什么作用？

軟體體系結構為軟體系統提供了一個結構、行為和屬性的高級抽象,由構成系統的元素的描述、這些元素的相互作用、指導元素集成的模式以及這些模式的約束組成，軟體體系結構不僅指定了系統的組織結構和拓撲結構,并且顯示了系統需求和構成系統的元素之間的對應關系,提供了一些設計決策的基本原理，

作用:

(1)體系結構是風險承擔者進行交流的手段，軟體體系結構代表了系統的公共的高層次的抽象，這樣,系統的大部分有關人員(即使不是全部)能把它作為建立一個互相理解的基礎,形成統一認識,互相交流， 體系結構提供了一種共同語言來表達各種關注和協商,進而對大型復雜系統能進行理智的管理，這對專案最終的質量和使用有極大的影響，

(2)體系結構是早期設計決策的體現:

1)軟體體系結構明確了對系統實作的約束條件;

2)軟體體系結構決定了開發和維護組織的組織結構;

3)軟體體系結構制約著系統的質量屬性;

4)通過研究軟體體系結構可能預測軟體的質量;

5)軟體體系結構使推理和控制更改更簡單;

6)軟體體系結構有助于循序漸進的原型設計;

7)軟體體系結構可以作為培訓的基礎，

P27題8 程式結構、軟體結構和軟體體系結構的區別和聯系

程式結構指的是軟體中的一個程式的模塊及其相互關系；

軟體結構指的是組成某個或某類軟體的模塊及其相互關系；

軟體體系結構指的是：構成軟體系統的元素的描述、元素之間的相互作用、元素的集成模式及模式約束，是一種結構、行為和屬性的高級抽象，

第二章

4+1模型有些視圖組成，各自的作用的是什么

邏輯視圖：設計的物件模型

行程視圖：捕捉設計的并發和同步特征

物理視圖：描述軟體到硬體的映射，反映了分布性特性

開發視圖：描述了在開發環境中軟體的靜態組織結構

架構的描述（場景視圖）：所作的各種決定圍繞著以上四個視圖來組織，然后用一些場景和用例來說明，

用自己的語言介紹4+1模型

“4+1”的視圖模型是Kruchten于1995年提出的用于描述軟體體系結構的方式，主要用5個不同的視圖：邏輯視圖、行程視圖、物理視圖、開發視圖和場景視圖來描述軟體體系結構， 每一個視圖只關心系統的一個側面，5個視圖結合在一起才能反映系統的軟體體系結構的全部內容，

軟體體系結構在軟體生命周期中的地位

軟體體系結構是必需的，軟體體系結構是貫穿于軟體研發的整個生命周期的系統開發、運行、維護所實施的全部作業和任務的結構框架，給出了軟體開發活動各階段之間的關系，軟體體系結構的生命周期模型為軟體生命周期模型提供了很好的結構依據和參考，也為其構建了很好的開發方式，

軟體體系結構的生命周期模型（說明）

需求分析階段，建立軟體體系結構階段，設計階段，實作階段；

軟體體系結構的生命周期描述了軟體研發的整個程序中的系統開發、運行、維護所實施的全部作業和任務的結構框架，給出了軟體開發活動各階段之間的關系，包括SA的非形式化描述；SA的規范描述和分析；SA的求精與驗證；SA的實施；SA的演化和擴展；SA的提供、SA的評價和度量；SA的終結，

網上：（1）以自然語言進行軟體結構的非形式化描述，（2）接著運用合適的形式化數學理論模型對上一階段的非形式化描述進行規范定義，從而得到軟體形式結構的形式化規范描述，（3）對設計好的軟體體系結構進行驗證和求精，直到不需要進行求精驗證時，（4）轉入軟體體系結構的實施，在此階段將軟體結構實施于系統設計中，并將其結構的構件和連接件有機組織在一起，（5）判斷軟體體系結構是否需要擴展，演化，需要從則重復以上步驟，（6）否則對該體系結構進行評價、度量，（7）轉入終結階段，

第三章

特定領域軟體體系結構DSSA，怎么理解

DSSA描述了領域中各個應用的共同特征和動態行為

DSSA是作用于領域中不同應用的設計藍圖

DSSA的定義：

DSSA是軟體構件的集合，以標準結構組合而成，對于一種特殊型別的任務具有通用性，可以有效地，成功地用于新應用系統的構件

DSSA是一個特定問題領域中支持一組應用的領域模型、參考需求、參考體系結構等組成的開發基礎，其目標就是支持在一個特定領域中多個應用的生成，

特定領域軟體體系結構的必備特征：

1）一個嚴格定義的問題域和/或解決域

2）具有普遍性，使其可以用于領域中某個特定應用的開發

3）對整個領域的合適程度的抽象

4）具備該領域固定的、典型的在開發程序中可重用元素

從功能覆寫的范圍角度有兩種理解DSSA中領域的含義的方式：

垂直域：定義了一個特定的系統族，包含整個系統族內的多個系統，結果是在該領域中可作為系統的可行解決方案的一個通用軟體體系結構

水平域：定義了在多個系統和多個系統族中功能區域的共有部分，在子系統級上涵蓋多個系統族的特定部分功能，無法為系統提供完整的通用體系結構

DSSA的基本活動

領域分析

這個階段的主要目標是獲得領域模型，領域模型描述系統之間的共同的需求

領域設計，

這個階段的目標是獲得DSSA，DSSA描述在領域模型中表示的需求的解決方案，它不是單個系統的表示，而是能夠適應領域中多個系統的需求的一個高層次的設計，

領域實作

這個階段的主要目標是依據領域模型和DSSA開發和組織可重用資訊，這些可重用資訊可能是從現有系統中提取得到，也可能需要通過新的開發得到，

DSSA的建立程序分為五個階段：

1）定義領域范圍：本階段的重點是確定什么在感興趣的領域中及本程序到何時結束，這個階段的一個主要輸出是領域中的應用需要滿足一系列用戶的需求

2）定義領域特定的元素：本階段的目標是編譯領域字典和領域術語的同義詞詞典，在領域工程程序的前一個階段產生的高層塊圖將被增加更多的細節，特別是識別領域中應用間的共同性和差異性

3）定義領域特定的設計和實作需求約束：本階段的目標是描述解決空間中有差別的特定，不僅要識別出約束，并且要記錄約束對設計和實作決定造成的后果，還要記錄對處理這些問題時產生的所有問題的討論

4）定義領域模型和體系結構：本階段的目標是產生一般的體系結構，并說明構成它們的模塊或構件的語法和語意

5）產生、搜集可重用的產品單元：本階段的目標是為DSSA增加構件，使它可以被用來產生問題域中的新應用

DSSA的建立程序是并發的、遞回的和反復進行的，該程序的目的是將用戶的需求映射為基于實作限制集合的軟體需求，這些需求定義了DSSA，

用基本軟體體系結構風格分析問題（給圖分析風格和要點）猜測

1、經典軟體體系結構風格

1.1、管道與過濾器：每個構件有一組輸入輸出，構件讀取輸入流，經內部處理產生輸出流，其中構件被稱為過濾器，連接件被稱為管道；

1.2、資料抽象和面向物件系統：在資料抽象和面向物件的基礎上，將資料的表示方法和相應操作封裝在一個抽象資料型別或物件中，其中構件是物件；

1.3、基于事件的系統：構件不會直接呼叫一個程序，而是觸發或者廣播一個或多個事件，事件包含了系統中其他構件的程序注冊資訊，事件的觸發會導致另一模塊中的程序呼叫，也被稱為隱式呼叫，其中構件是模塊；

1.4、分層系統：將系統組織成一個層次結構，每一層為其上層服務，并作為其下層的客戶，層次系統風格的的體系結構一般包括核心層、基本工具層和用戶系統層，

1.5、倉庫系統：倉庫風格有兩種不同的構件：中央資料結構和獨立構件，前者說明當前狀態，后者在中央資料存盤上執行，其控制原則的不同又分為傳統型資料庫和黑板系統，區別在于觸發行程執行選擇的物件，前者是輸入流中某類時間，后者是中央資料結構的當前狀態，

1.6、黑板系統：一般應用于信號處理領域和松耦合代理資料共享存取，由知識源、黑板資料結構和控制組成，

1.7、C2風格：通過連接件系結在一起，按照一組規則運作的并行構件網路，其中構件和連接件都有一個頂部和底部，構件的頂部和底部與連接件的底部和頂部相連，構件不能與連接件直接相連，一個連接件可以和任意構件、連接件相連，連接件之間連接時，必須頂部和底部相連，

2、C/S風格：由資料庫服務器、客戶應用程式和網路三部分組成，分為表示層和資料層；

3、三層C/S風格：在C/S基礎上加入了應用服務器，增加了應用層；

4、B/S風格：由瀏覽器、web服務器、資料庫服務器組成；

5、CORBA風格：即公共物件請求代理風格；

6、正交軟體體系結構：由組織層和線索的構件構成，其主要特征是由n個完全不同功能的線索和m個不同抽象的層組成，線索之間相互獨立，系統有頂層的公共驅動層和底層的公共資料結構，

7、基于層次訊息總線：即 HMB，基于層次訊息總線、支持構件的分布和并發，構件之間通過訊息總線進行通信；

8、異構結構風格：將不同的體系結構組合起來形成的風格；

9、互聯系統：即SASIS，系統可以分為若干不同的部分，每個部分作為單獨的系統獨立開發，整個系統通過一組互相系統實作，體現整體性能稱為上級系統，代表整體的一部分稱為從屬系統；

10、DSSA:在一個特定應用領域中為一組應用提供組織結構參考的標準構件體系結構，

第四章

軟體體系結構描述方法(p122 題1)（p100頁）

（1）圖形表達工具,采用矩陣和有向線段來代表構件和連接件；

（2）模塊內連接語言（MIL），將一種或幾種傳統程式設計語言的模塊連接起來；

（3）基于軟構件的系統描述語言（PCL），將軟體系統描述成一種是由許多以特定形式相互作用的特殊軟體物體構造組成的組織或系統；

（4）軟體體系結構描述語言（ADL），參照傳統的程式設計語言的設計和開發經驗，重新設計、開發和適用針對軟體體系結構特點的專門的軟體體系解雇描述語言，

第五章

Uml有哪些圖？各類圖的特點（P147 題5）軟體體系結構可以通過UML直接進行描述，請說明UML包括哪些圖，以及各自的作用是什么

用例圖：描述一組用例、參與者及它們之間的關系；

類圖：描述一組類、介面、協作和它們之間的關系；

物件圖：描述一組物件及它們之間的關系；

互動圖：表示各組物件如何依某種行為進行協作的模型，包含順序圖、通信圖、定時圖和互動概覽圖；

順序圖：由一組物件或角色以及它們之間可能發送的訊息構成，用來描述物件之間動態的互動關系，著重體現物件間訊息傳遞的時間順序；

通信圖：強調收發訊息的物件或角色的結構組織；

定時圖：強調訊息跨越不同物件或角色的實際時間；

狀態圖：描述物件狀態和事件之間的關系，通常描述單個物件的行為；

活動圖：將行程或其他計算的結構展示為計算內部一步步的控制流和資料流，用來表示系統中的各種活動的次序；

互動概覽圖：整合活動圖和順序圖的產物；

構件圖：描述一個封裝的類和它的介面、埠，以及由內嵌的構件和連接件構成的內部結構；

部署圖：描述對運行時的處理結點及在其中生存的構件的配置，

四層元模型 p140頁（如何使用）

UML的四層元模型結構包括元-元模型、元模型、模型和用戶物件，元-元模型層定義了元模型層的規格說明語言；元模型層為給定的建模語言定義規格說明；模型層用來定義特定軟體系統的模型；用戶物件層用來構建給定模型的特定實體，

用例圖和其他圖直接的關系 題4

用例圖是對系統行為的動態描述，是從用戶的角度審視軟體體系結構的，它可以促進設計人員、開發人員與用戶的溝通，理解正確的需求，劃分系統與外部物體的界限，對系統的行為進行組織和建模時非常重要，是系統設計的起點，只有清楚了用例圖，才能對后續的其他圖進行描述，

第六章

XML SGML HTML的去別 p169題1

XML與HTML

HTML是一種格式化的語言，一個HTML文本可以看作一個格式化的程式，而一段符合XML語法規范的文本則是一段“純”資料，它的結構由其它的稱為DTD的文本來描述，而它的處理則可能是任何其它支持XML的容器或程式，與XML相比的另一個不同點是，XML是一種元標記語言，XML定義了一套元句法，與特定領域有關的標記語言都必須遵守，

XML與SGML

SGML是一種用標記描述檔案資料的通用語言，包含一系列的檔案型別定義即DTD，但因語法的可擴展性，導致SGML龐大難學，不易使用且實作困難，因此HTML應運而生，HTML簡化了SGML，只使用SGML的少量標記，且標記固定不可擴展，易學易用操作簡單，但簡單的語法導致無法表現復雜的形式，為了克服上述問題，XML應運而生，

XML與資料庫的區別

（1）資料庫可以進行資料的海量儲存，而XML主要處理資料在網上的傳輸標準問題，XML能夠作為橋梁將資料格式輸入到資料庫中，也能將資料庫的資料轉換成其他格式；

（2）XML是檔案形式，利于長期保存，可讀性高，資料庫是關系型資料庫，某些關系表現不出；

（3）XML是存盤資料的標準格式，便于網路資料傳輸和互動；資料庫能夠進行大量資料的存盤和分析；

（4）XML和資料庫都可以定義資料模型并存盤資料，然而，XML更加通用、更加標準化

（5）XML缺少資料庫具備的特性：高效的存盤、索引和資料修改機制、嚴格的資料安全訪問控制；完整的事務和資料一致性控制；多用戶訪問機制；觸發器、完善的并發控制等，用戶量大、資料集成度高以及性能要求高的資料環境中還是需要資料庫來完成任務；

XML的應用范圍是? 152

經常在以下情況使用：

（1）應用于客戶需要與不同的資料源進行互動時；

（2）應用于將大量運算負荷分布在客戶端；

（3）應用于將同一資料以不同的面貌展現給不同的用戶；

（4）應用于網路代理對所取得的資訊進行編輯、增減以適應個人用戶的需要，

XML的編程介面？怎么選擇編程介面 159

XML的介面有DOM（檔案物件模型）,SAX（用于XML的簡單API）,JDOM（基于java的檔案物件模型）,JAXP（用于XML決議的java API）四種；

如何選擇介面？

1、是否使用Java撰寫應用程式？是則使用JAXP；

2、應用程式將如何部署？如果將要作為java applet部署，則使用JDAM；

3、決議了XML檔案后，是否需要多次訪問這些資料？是則考慮DOM；

4、是否只需要XML源檔案的少量內容？是則考慮SAX；

5、是否正在一臺記憶體很少的機器作業？是則考慮SAX；

第七章

軟體體系結構的演化、動態性、擴展的區別

軟體體系結構的動態性：指軟體系統在運行時刻的體系結構變動，

體系結構擴展：體系結構的靜態修改

軟體體系結構演化：由于系統的需求、技術、環境、分布等因素的變化，最終導致軟體體系結構的變動；

什么是動態軟體體系結構體現在哪3個方面?

（1）互動動態性，如允許在復合構件的固定連接中改變資料；

（2）結構化動態性，如允許對系統添加或洗掉構件或連接件；

（3）體系結構動態性，允許構件的整個配置發生改變；

對基于構建的動態結構模型的了解

又被稱為CBDSAM，支持運行系統的動態更新，分為應用層、中間層和體系結構層三層，其中應用層處于最底層，包括構件連接、構件介面和執行；中間層包括連接件配置、構件配置、構建描述和執行；體系結構層位于最頂層，控制和管理整個體系結構，包括體系結構配置、體系結構描述和執行，

動態更新和區域更新和全域更新（重要） 174

CBDSAM的動態更新包括檢測更新范圍、更新準備作業、執行更新和存盤更新，分為區域更新和全域更新，

區域更新只作用于需要更新的構件內部，不影響系統的其他部分；判斷屬于區域更新后，在執行更新前，需要進行區域更新的構件會發送信號以隔離自身的通信，執行更新后將再將斷開的連接重新存盤起來，在整個程序中不會影響其他部分的運行，

全域更新作用于需要更新的構件，僅影響更新所涉及的部分，不影響系統的其他部分，在判斷屬于全域更新后，體系結構配置器會對更新所涉及的連接件和構件發送更新準備資訊，整個更新作業只在這些部分進行，不會影響系統的其他部分運行，

第八章

你是怎樣認識SOA的？有哪些特征（得有自己的理解和認識）

SOA是面向服務的體系結構的意思，對此，W3C，Service-architecture.com和Gartner給出了不同的定義，SOA是一種在計算環境中設計、開發、部署和管理離散邏輯單元（服務）模型的方法，由于SOA考慮到了系統內的物件，所以雖然SOA是基于物件的，但是作為一個整體，它卻不是面向物件的，

SOA的特征：（1）松散耦合；（2）粗粒度服務；（3）標準化介面，

Web服務的核心技術以及作用（三要素）p220題3

（1）：底層傳輸層，主要負責訊息的傳輸機制，

（2）：服務通信協議層，服務通信協議層主要是以一種統一的方式描述并定義服務之間進行通信傳輸所需的技術標準，

（3）：服務描述層，主要以一種統一的方式描述服務的介面和訊息交換方式，

（4）：服務層，主要功能是將遺留系統進行包裝，并通過發布的WSDL介面描述被定位和呼叫，

（5）：業務流程層，主要功能是支持服務發現，服務呼叫和點到點的服務呼叫，并將業務流程從服務的底層呼叫抽象出來，

（6）：服務注冊層，主要功能是使服務提供者能夠通過WSDL發布服務定義，并支持服務請求者查找所需的服務資訊，

三個構成元素為：服務提供者、服務請求者、服務注冊中心

三個核心協議：簡單物件訪問協議SOAP；統一描述、發現和集成協議UDDI；Web服務描述語言WSDL

簡述面向服務體系結構的設計原則 P220題5 （p190頁）

（1）明確定義的介面，服務定義必須長時間穩定；

（2）自包含和模塊化，實作服務的功能物體完全獨立自主；

（3）粗粒度，服務數量不應太多；

（4）松耦合，確保服務請求者可見的是服務的介面；

（5）互操作性、兼容和策略宣告，確保服務規約的全面和明確，

第九章

（結合第九章，技術發展的驅動力是什么？P232題2）

為什么使用RIA技術 p232 題1

RIA利用相對健壯的客戶端描述引擎，這個引擎能夠提供內容密集、回應速度快和圖形豐富的用戶界面，RIA的另一個好處在于，資料能夠被快取在客戶端，從而可以實作一個比基于HTML的回應速度更快且資料往返于服務器的次數更少的用戶界面，

第十章

軟體體系結構的可靠性從哪些方面體現 P247題1后半 （p234頁）

可靠性是軟體系統在應用或系統錯誤面前，在意外或錯誤使用的情況下維持軟體系統的功能特性的基本能力，分為兩個方面：（1）容錯：在規定的條件下，在規定的時間內，軟體不引起系統失效的概率；（2）健壯性：在規定的時間周期內，在所述條件下程式執行所要求的功能的能力； 所以對應從容錯和健壯性進行評估，以判斷軟體體系結構的可靠性，

為什么進行軟體體系結構的分析 P247題2 （p244頁）

因為風險評估是一個基于能夠通過定量的方法對軟體產品屬性進行的度量，它對任何一個軟體風險管理計劃都是一個重要的程序， 風險評估能夠對需要進行詳細檢測的復雜模型進行驗證得到潛在的模型問題和測驗效果，有利于開發階段的后期評估，一般的方法有動態方法、構件依賴圖等，一般的風險分析步驟是：體系結構風險建模、復雜性分析、嚴重性分析、開發可靠性風險因子、建立CDG和通過演算法進行風險評估和分析，

如何理解基于軟體體系結構的軟體測驗

軟體測驗是困難、花銷巨大的作業，但在軟體開發程序中是一項非常重要的作業，怎樣將形式化方法與軟體測驗技術結合起來是軟體測驗研究的重點，基于體系結構的軟體測驗和傳統的軟體測驗一樣，需要研究測驗內容、測驗準則、測驗用例、測驗充分性、測驗方法等，

測驗準則被定義為：測驗應該覆寫所有的構件及各個構件的介面、各個連接件的介面、構件之間的直接連接、構件之間的間接連接，

軟體體系結構的測驗程序可以分為單元測驗、集成測驗和系統測驗

第十一章

三種評估方式的優缺點和特征 p270題2

1.基于調查問卷或檢查表的評估方式：調查問卷是一系列可以應用到各種體系結構評估的相關問題，這些問題可能涉及體系結構對設計決策，有些問題涉及體系結構的檔案，有的問題針對體系結構描述本身細節問題等，檢查表中也包含一系列比調查問卷更細節和具體的問題，它們更趨向于考察某些關心的質量屬性，這一評估方法比較靈活自由，可評估多種質量屬性，也可以在軟體體系結構設計的多個階段進行，

2.基于場景的評估方式：場景是一系列有序使用或修改系統的步驟，基于場景的方式由SEI首先提出并應用在體系結構權衡分析方法和軟體體系結構分析方法中，這種軟體體系評估方式分析軟體體系結構對場景也就是對系統對使用或修改活動的支持程度，從而判斷該體系結構對這一場景所代表對質量需求對滿足程度，

3.基于度量的評估方式：度量是指為軟體產品對某一屬性所賦予對數值，此評估技術涉及3個基本活動：首先需要建立屬性和質量之間的映射關系，然后從軟體體系結構檔案中獲取度量資訊，最后根據映射原則分析推匯出系統對某些質量屬性，

第十二章

什么是設計模式、什么是中間件

設計模式是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結，對通用設計問題的重復解決方案，

中間件是處于系統軟體和應用軟體之間的一類軟體，

如何理解中間件

優點：

它使設計師集中設計與應用有關的部分，大大簡化了設計和維護作業，

功能：

1.負責客戶機與服務器之間的連接和通信，以及客戶機與應用之間的高效率通信機制，

2.提供應用層不同服務之間的互操作機制沒，以及應用層與資料庫之間的連接和控制機制

3.提供一個多層體系結構的應用開發和運行的平臺，以及一個應用開發框架，支持模塊化的應用開發，

4.屏蔽硬體、作業系統、網路和資料庫的差異，

5.提供應用的負載和高可用型、安全機制和管理功能，以及交易管理機制，保證交易的一致性，

6.提供一組通用的服務區執行不同的功能，避免重復的作業和是應用之間可以協作，
分類：

采用自底向上的方式來劃分，可分為底層中間件、通用型中間件和集成性中間件三大層次，

主要的中間件：RPC，ORB，RMI，RMI-IIOP,MOM, 事務處理監控器，

簡要說明 基于體系結構的軟體設計的生命周期模型及設計步驟 P333題4

ABSD方法的生命周期介于需求分析和實際構件設計之間，在該方法中，必須記錄所有做出決策以及這些決策的原理，以利于決策的可跟蹤性和決策評審，其輸入包含抽象功能需求、用例、抽象的質量和業務需求、質量因素、體系結構選項和約束組成，

設計模式于軟體體系結構之間的關系

設計模式的層次

（1）面向物件模式：由最底層的類與物件及其關系區分；

（2）代碼模式：有助于解決某種面向物件程式設計語言的特定問題；

（3）框架應用模式：用一種不很規范的方式描述了如何應用框架來解決特定的問題；

（4）形式合約：是一種描述框架設計的方法，強調組成框架的物件間的互動關系，過于抽象，僅在小規模程式中使用，

第十三章

什么是軟體產品線？你是怎么理解的？

軟體產品線就是在一個公共的軟體資源集合基礎上建立起來的共享同一個特性集合的系統集合，

雙生命周期模型

雙生命周期模型是軟體產品線的一種程序模型，分成領域工程和應用工程這兩個重疊的生命周期，其中領域工程的主要任務是領域分析、領域設計和領域實作，應用工程的主要任務是需求分析、系統設計和系統實作，

應用工程將產品線資源不能滿足的需求回傳給領域工程，以檢驗是否將之合并到產品線的需求中，領域工程從應用工程中獲得反饋或者結合新產品的需求進入有一次周期性發展，此為產品線的演化，