第一章 軟體體系結構概述

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

軟體危機

1.軟體成本日益增長

2.開發進度難以控制

3.軟體質量差

4.軟體維護困難

產生原因

1.用戶需求不明確

2.缺乏正確的理論指導

3.軟體規模越來越大

4.軟體復雜度越來越高

軟體危機與軟體體系結構的關系

軟體危機引起軟體工程的研究，軟體危機的加劇，人們認識到軟體體系結構的重要性，并對軟體體系結構開始系統地深入地研究，是提高軟體生產率和解決軟體問題最有希望的途徑，

構件與重用的定義及他們之間的關系

構件：語意完整，語法正確，有重用價值的單位軟體，結構上，是語意描述，介面通信和代碼實作的復合體，

重用：兩次或多次軟體開發程序中重復使用或使用相同或相近軟體元素的程序，

關系：實作軟體的工業化生產，構件是核心和基礎，重用是必須的手段，

基于構件的軟體開發的優勢 《個人見解》

1.縮短開發費用

2.縮短開發周期

3.可以實作復用

基于構件的軟體開發會面臨的困難和挑戰《個人見解》

1.在同一系統采用多個開發商提供的構件，它們之間的兼容性可能是一個嚴峻的問題；

2.采用隨處可以購買到的構件可能會使開發出來的軟體產品喪失技術上的獨創性和市場上的競爭力；

3.第三方的構件開發商可能歇業，這會使購買的構件失去維護服務，這些都是在購買第三方構件進行軟體開發時無法回避的問題，因此需要對這些風險進行充分的估計，

獲取構件的途徑

1.從現有構件中獲得復合要求的構件，直接使用或做適應性修改，得到可重用的構件，

2.通過遺留工程將提取潛在重用價值的構件，

3.從市場上購買現成的商業構件

4.開發新構件

軟體體系結構的意義

1.體系結構是風險承擔者進行交流的手段

2.體系結構是早期設計決策的體現

3.軟體體系結構是可傳遞和重用的模型

如何理解軟體體系結構 《個人見解》

軟體體系結構是一個抽象的系統規范，主要包括用其行為來描述的功能構件和構件之間的相互連接、介面和關系，一個工程就像是一座樓，軟體體系結構就是被用來創建一個完整的體系，用來建造這座樓的，

程式結構、軟體結構、軟體體系結構的區別

區別:

程式結構:指的是代碼的結構,一般的程式結構有三種:順序、選擇和回圈，

軟體結構:指的是軟體的組成結構,軟體的組成單位是模塊(泛指),軟體結構其實就是組成軟體的模塊結構，

體系結構:指的是軟體的設計風格、范式等,常見的體系結構如:4+1,SOA,MVC,層次,管道過濾器,主程式子程式等，

**聯系:**這三種結構其實講的是同一種產品——同一個軟體,是在不同層次對軟體構成的抽象，

第二章 軟體體系結構建模

介紹四加一模型

通過五個不同的視角反映系統的軟體體系結構的全部內容，

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

對于軟體專案，一個清晰的軟體體系結構是首要的，p36

四加一模型的視圖組成 和 作用

1.邏輯視圖：系統的功能需求即提供給最終用戶的服務，

2.開發視圖：側重于軟體模塊的組織和管理，考慮軟體內部的需求，軟體開發難度，軟體重用，開發工具帶來的局限，

3.行程視圖：側重于系統的運行特征，主要關注非功能需求，強調并發性、分布性、系統集成性和容錯能力，

4.物理視圖：如何把軟體映射到硬體上，考慮系統性，可靠性，

軟體體系結構的生命周期模型

軟體體系結構生命周期由4個階段組成：

1.需求分析階段

2.建立軟體體系結構階段

3.設計階段

4.實作階段

第三章 軟體體系結構風格

軟體體系結構進行分析

經典軟體體系結構風格

客戶服務器（C/S）風格

三層C/S習題結構風格

瀏覽服務器風格

公共物件請求代理體系結構風格

正交軟體體系結構風格

基于訊息總想的體系結構風格

異構結構風格

互聯系統的構成系統及其體系結構

特定領域軟體體系結構

特定領域軟體體系結構

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

特征

1.一個嚴格定義的問題和問題域

2.具有普遍性，可以用于特定領域軟體的開發

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

4.具備固定的典型的可重用元素

第四章 軟體體系結構描述

軟體體系結構的描述方法？

描述方法可分為文字表達工具，數學表達工具和圖形表達工具，產業偏向圖形表達，學術偏向數學表達，

1.圖形表達工具

2.模塊內連接語言

3.基于軟構件的系統描述語言

4.軟體體系結構描述語言

第五章 統一建模語言

理解圖并清楚這些圖的作用和特點？

p129

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

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

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

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

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

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

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

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

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

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

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

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

請問用例圖和其他圖的關系是什么？《個人見解》

用例圖是從用戶的角度審視SA的

用例是因,狀態圖、類圖是果.根據用例來撲捉這些結果

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

UML的四層元模型結構？

元元模型層：只有一個元素就是“thing”，類似于.Net類別庫層次的根object

元模型層：面向物件和面向組件開發的各種概念，如“類”、“關聯”、“屬性”等，是UML語言的組成部分

模型層：建模者自己創建的具體的模型，比如“汽車類”、“司機”類、“汽車”與“司機”之間的多對多關系

用戶模型層：模型層中模型的實體，比如“小李：司機”、“A001：汽車”

第六章 可擴展標記語言

XML、SGML、HTML等之間的區別？

XML是一個精簡的SGML，他將SGML的豐富功能與HTML的易用性結合到Web應用中，保留了SGML的可拓展功能，

HTML是一種格式化的語言，HTML描述的程式和文本具有“內容和格式”的雙重屬性，XML則是純資料，可以支持其他可以處理XML的容器和程式，XML是一種元標記語言，可以用于定義其他的標記語言，

HTML 是遵循了 DTD 標準的 SGML 的檔案，也可以說是 SGML 的一個實體

XML與資料庫的區別？

xml主要解決的是資料在網上傳輸標準的問題，把原來各種各樣的資料孤島可以通過xml這座橋梁連接起來，所以打個比方，資料庫就好比是盛資料的桶，而xml則是資料傳輸轉換的橋梁

二者也存在非常緊密的聯系，畢竟都是處理資料的工具，就是很多其他的資料格式可以通過xml輸入到資料庫中，資料庫中的關系型資料也可以通過xml轉化成其他的資料格式

XML的應用領域？經常在什么地方使用？

1.應用于客戶需要與不同資料源進行互動時

2.應用于將大量運算負荷分布于客戶端

3.應用于將統一資料以不同的面貌展示給不同用戶

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

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

編程介面：DOM、SAX、 JDOM、 JAXP

如何選擇：

（1）如果使用Java撰寫應用程式則使用JAXP；

（2）如果應用程式將要作為java applet部署則使用JDAM；

（3）決議了XML檔案后要多次訪問這些資料則考慮DOM；

（4）如果只需要XML源檔案的少量內容則考慮SAX；

（5）如果正在一臺記憶體很少的機器作業則考慮SAX；

第七章 動態軟體體系結構

軟體體系結構演化、體系結構的動態性、體系結構擴展這三個概念是什么？

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

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

體系結構擴展：體系結構的靜態性修改稱之為體系結構拓展，

什么是動態軟體體系結構？體系結構的動態性主要體現在那三個方面？

軟體系統在運行時刻的體系結構可以進行變動，而不需要停機維護，

動態性主要體現

1.互動式動態性

2.結構化動態性

3.體系結構動態性

基于構件的動態結構模型？（7.2）

CBDSAM，支持運行系統的動態更新，分為應用層、中間層和體系結構層三層，

應用層處于最底層，包括構件連接、構件介面和執行；

中間層包括連接件配置、構件配置、構建描述和執行；

體系結構層位于最頂層，控制和管理整個體系結構，包括體系結構配置、體系結構描述和執行，

動態？區域？更新與全域更新？

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

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

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

第八章 基于服務的體系結構

什么是 SOA？你對SOA的理解是什么？它有哪些特征？

SOA：面向服務的體系結構

理解：一種在計算環境中設計、開發、部署、和管理離散邏輯單元（服務）模型的方法；它是面向物件模型的替代，基于物件而不面向物件的一種方法；

特征：

1.松散耦合

2.粗粒度服務

3.標準化介面

web的服務有什么樣的核心技術？這些技術的作用是什么？web服務的三要素是什么？

Web服務的核心技術及其作用，

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

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

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

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

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

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

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

面向服務體系結構的設計原則

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

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

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

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

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

第九章 富互聯網應用體系結構

了解RIA技術的前世今生？《個人見解》

（1）連接本地的只有文字界面的大型計算機；

（2）連接本地的具有集成媒體圖形用戶界面的客戶-服務器模式；

（3）連接全球的網路應用程式；

（4）連接全球的富互聯網應用體系（RIA）；

為什么要使用它？

RIA利用相對健壯的客戶端描述引擎，這個引擎能夠提供內容密集、回應速度快和圖形豐富的用戶界面，RIA的另一個好處在于，資料能夠被快取在客戶端，從而可以實作一個比基于HTML的回應速度更快且資料往返于服務器的次數更少的用戶界面，對企業而言，RIA可以繼續使用現有的應用程式模型，可以幫助企業提供多元化的重要業務效益，

第十章 軟體體系結構的分析與測驗

軟體體系結構的可靠性可以從哪幾個方面進行評估？（p234）《個人見解》

可靠性是軟體系統在應用或系統錯誤面前，在意外或錯誤使用的情況下維持軟體系統的功能特性的基本能力，分為兩個方面：

（1）容錯：在規定的條件下，在規定的時間內，軟體不引起系統失效的概率；

（2）健壯性：在規定的時間周期內，在所述條件下程式執行所要求的功能的能力；

所以對應從容錯和健壯性進行評估，以判斷軟體體系結構的可靠性，

為什么要進行軟體體系結構的分析？（p238）《個人見解》

因為風險評估是一個基于能夠通過定量的方法對軟體產品屬性進行的度量，它對任何一個軟體風險管理計劃都是一個重要的程序， 風險評估能夠對需要進行詳細檢測的復雜模型進行驗證得到潛在的模型問題和測驗效果，有利于開發階段的后期評估，

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

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

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

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

第十一章 軟體體系結構評估

軟體體系結構的評估方法？哪三種方法？各有什么樣的優缺點？

1.基于調查問卷或檢查表的評估方式

優點：自由靈活，可評估多種質量屬性，在多階段進行；

缺點：主觀性較強，評估人員的熟悉程度和相關經驗等會對結果產生很大影響；

2.基于場景的評估方式，應用于ATAM和SAAM中；

優點是考慮到了所有人員對質量需求的滿意程度

缺點是評估方式是特定于某個領域的，需要實施者有豐富的領域知識，能夠設計出合理場景，還要求實施者對待評估的軟體體系結構有一定的了解，

3.基于度量的評估方式

優點：提供更為客觀和量化的質量評估；

缺點：有時間限制，需在軟體體系結構設計基本完成以后才能進行，對評估人員要求較高，需要評估人員對評估的體系結構十分了解，

第十二章 基于體系結構的軟體開發

什么是設計模式？

設計模式是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結，其目的是提高代碼的可重用性，使代碼易于理解，保證代碼的可靠性，設計模式廣泛應用于面向物件系統的設計和開發，成為面向物件領域的一個重要組成部分，

什么是中間件？你如何理解中間件？

定義：中間件是一種獨立的系統軟體或服務程式，便于資源共享，中間件位于作業系統之上，能夠管理計算資源和網路通信，實作應用之間的互操作，

基本功能：

（1）負責客戶機和服務器之間的通信，以及客戶機與應用層之間的高效率通信機制；

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

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

（4）屏蔽軟體、作業系統網路和資料庫的差異，

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

（6）提供一組通用的服務去執行不同的功能，避免重復的作業，使應用之間可以協作，

分類：底層中間件、通用型中間件、集成型中間件；

應用：在企業應用集成中扮演重要的角色，可以從不同的層次采用不同種類、不同技術的中間件進行應用集成，為了完成不同層次的繼承，采用不同的技術和產品，

發展趨勢：規范化、構件化、松耦合、平臺化發展；

設計模式的層次？

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

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

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

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

基于體系結構的軟體設計（ABSD）的生命周期？

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

第十三章 軟體產品線體系結構

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

產品線是一個產品集合，這些產品共享一個公共的、可管理的特征集，這個特征集可以滿足選定的市場或任務領域的特定需求，這些系統遵循一個預描述的方式，是在公共的核心資源基礎上開發的，

軟體產品線由核心資源和產品集合組成，核心資源是領域工程的所有結果的集合，是產品線里產品構造的基礎，

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

雙生命周期模型？（p339）

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

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