第1章：軟件體系結構概論
什么是軟件危機，軟件危機的具體表現有哪些？
軟件危機：落后的軟件生產方式無法滿足迅速增長的計算機軟件需求，從而導致軟件開發與維護過程中出現一系列嚴重問題的現象。
軟件危機的表現：
軟件成本日益增長，開發進度難以控制，軟件質量差，軟件維護困難
產生軟件危機的原因，如何克服軟件危機？
產生軟件危機的原因有用戶需求不明確，缺乏正確的理論指導，軟件規模越來越大，軟件復雜度越來越高。
人們面臨的不光是技術問題，更重要的是管理問題。要提高軟件開發效率，提高軟件產品質量，必須采用工程化的開發方法與生產技術。在技術上，應該采用基於重用的軟件生產技術；
在管理上，應該采用多維的工程管理模式。
構件：（components，也譯為組件，部件）：
是指語義完整、語法正確和有可重用價值的單位軟件，是軟件重用過程中可以明確辨識的系統；結構上，它是語義描述、通訊接口和實現代碼的復合體。是具有某種功能的可重用的軟件模板單元，表示了系統中主要的計算元素和數據存儲。
軟件架構師的關注點：
關注的首先不是功能，而是品質關注點（非功能性需求） 。涉眾關注的是那些品質，如性能，安全，可伸縮性，還是可變性，可維護性，可用性等。理解的涉眾的品質關注點后，考慮折中。分而治之，保持概念完整性
軟件體系結構的定義
軟件體系結構為軟件系統提供了一個結構、行為和屬性的高級抽象，由構成系統的元素的描述，這些元素的相互作用、指導元素集成的模式以及這些模式的約束組成。軟件架構不僅指定了系統的組織結構和拓撲結構，並且顯示了系統需求和構成系統的元素之間的對應關系，提供了一些設計決策的基本原理。
軟件體系結構的意義
體系結構是風險承擔者進行交流的手段，體系結構是早期設計決策的體現，它明確了對系統實現的約束條件，決定了開發和維護組織的組織結構，制約着系統的質量屬性，可以預測軟件的質量，是推理和控制更改更簡單，有助於循序漸進的原型設計。同時，軟件體系結構是可傳遞和可重用的模型。
軟件體系結構的應用現狀
目前，軟件體系結構領域研究非常活躍，歸納現有體系結構的研究活動，主要包括以下幾個方面
1.軟件體系結構描述語言2.體系結構構造與表示 3.體系結構分析、設計與驗證4.體系結構發現、演化與重用5.基於體系結構的軟件開發方法6.特定領域的體系結構框架7.軟件體系結構支持工具8.軟件產品線體系結構9.建立評價軟件體系結構的方法
架構分析、設計與驗證，發現、演化與重用
架構分析的內容可分為結構分析、功能分析和非功能分析。生成一個滿足軟件需求的架構的過程即為架構設計。
架構設計過程的本質在於將系統分解成相應的組成成分，並將這些成分重新組裝成一個系統。 架構設計有兩大類方法：過程驅動方法和問題列表驅動方法。
架構測試着重於仿真系統模型，解決架構層的主要問題。由於測試的抽象層次不同，架構測試策略可以分為單元/子系統/集成/驗收測試等階段的測試策略。
架構發現 從既存系統中提取軟件的架構，屬逆向工程。
架構重用 屬於設計重用，比代碼重用更抽象。由於軟件架構是系統的高層抽象，反映了系統的主要組成元素及其交互關系，因而較算法更穩定，更適合於重用。
軟件架構演化是指由於系統需求、技術、環境、分布等因素的變化而導致軟件架構的變動。軟件系統在運行時的架構變化稱為架構的動態性，而將架構的靜態修改稱為架構擴展。兩者都是架構適應性和演化性的研究范疇。
第2章 軟件體系結構建模。
軟件體系結構建模的種類
結構模型、框架模型、動態模型、過程模型和功能模型
什么是“4+1視圖”，分別給出每個視圖的名稱和主要關注點。
“4+1”的視圖模型是Kruchten於1995年提出的用於描述軟件體系結構的方式，主要用5個不同的視圖：邏輯視圖、進程視圖、物理視圖、開發視圖和場景視圖來描述軟件體系結構。 每一個視圖只關心系統的一個側面，5個視圖結合在一起才能反映系統的軟件體系結構的全部內容
軟件體系結構的生命周期模型
軟件體系結構的非形式化描述，軟件體系結構的規范描述和分析，軟件體系結構的求精及其驗證，軟件體系結構的實施，軟件體系結構的演化和拓展，軟件體系結構的提供、評價和度量，軟件體系結構的終結
容器
容器是指一個在其內部可以執行構件或駐留數據的東西。它可以是從網絡或應用服務器直到富客戶端應用或數據庫的任何東西。容器通常是可執行文件，但未必是各自獨立的流程。
C4模型
在面向對象的系統中，通常系統由多個容器組成，容器由多個構件組成，構件由多個類組成
第3章 軟件體系結構風格。
軟件架構風格的定義
諸風格的特征
◎數據流風格：批處理序列；管道/過濾器。
管道與過濾器風格的軟件體系結構的特點
（1）使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點；（2）允許設計者將整個系統的輸入/輸出行為看成是多個過濾器的行為的簡單合成；（3）支持軟件重用。（4）系統維護和增強系統性能簡單。（5）允許對一些如吞吐量、死鎖等屬性的分析；（6）支持並行執行。但是，這樣的系統也存在着若干不利因素。
（1）通常導致進程成為批處理的結構。這是因為雖然過濾器可增量式地處理數據，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉換。
（2）不適合處理交互的應用。當需要增量地顯示改變時，這個問題尤為嚴重。
（3）因為在數據傳輸上沒有通用的標准，每個過濾器都增加了解析和合成數據的工作，這樣就導致了系統性能下降，並增加了編寫過濾器的復雜性。
◎調用/返回風格：主程序/子程序；面向對象風格；層次結構。
面向對象的優點
能形象地表現現實世界的領域，重用性高，對應變化很強。 即易擴展， 維護性強
數據抽象和面向對象組織缺點
性能損失。 面向對象編程為了：重用性、 靈活性和擴展性等特性而作出的犧牲。測試比較麻煩，對整體系統設計要求高
◎獨立構件風格：進程通訊；事件系統。
基於事件的隱式調用優點：
為軟件重用提供了強大的支持。 當需要將一個構件加入現存系統中時，只需將它注冊到系統的事件中。為改進系統帶來了方便。 當用一個構件代替另一個構件時，不會影響到其它構件的接口。
基於事件的隱式調用缺點：
構件放棄了對系統計算的控制。數據交換的問題。 有時數據可被一個事件傳遞，但
有時系統必須依靠一個共享的倉庫進行交互。 這時全局性能和資源管理便成了問題。
既然過程的語義必須依賴於被觸發事件的上下文約束，關於正確性的推理存在問題。
分層系統優點：
支持基於抽象程度遞增的系統設計，使設計者可以把一個復雜系統按遞增的步驟進行分解；
支持功能增強，因為每一層至多和相鄰的上下層交互，因此功能的改變最多影響相鄰的上下層；支持重用。 只要提供的服務接口定義不變，同一層的不同實現可以交換使用。 這樣，就可以定義一組標准的接口，而允許各種不同的實現方法。
分層系統缺點：
並不是每個系統都可以很容易地划分為分層的模式，甚至即使一個系統的邏輯結構是層次化
的，出於對系統性能的考慮，系統設計師不得不把一些低級或高級的功能綜合起來；很難找到一個合適的、 正確的層次抽象方法。
◎虛擬機風格：解釋器；基於規則的系統。
◎倉庫風格：數據庫系統；超文本系統；黑板系統。
請簡要說明黑板風格的定義。
黑板結構是一個六至八層的層次結構，每一層都抽象了與之相鄰的較低一層的信息。
知識源代表整個問題求解中的獨立的子任務。每個知識源被組織成一個條件部分和一個動作部分，條件部分規定什么時候知識源可用，動作部分負責處理相關的黑板元素並產生新的元素。控制構件作為黑板的監控程序和調度程序；通常將黑板知識源應用到黑板中各種元素具有優先次序，調度程序負責監控黑板和計算的優先次序。
◎C2風格
C2風格的特點
C2體系結構風格：可以概括為通過連接件綁定在一起的按照一組規則動作的並行構件網絡。組織規則有：1、系統中的構件和連接件都有一個頂部一個底部。2、構件的頂部應連接到某連接件的底部，構件的底部應連接到連接件的頂部，構件之間不能直接連接。3、一個連接件可以和任意數目的其他構件和連接件相連。4、當兩個連接件直接相連時，必須由其中一個底部到另一個的頂部。C2風格的特點：系統中的構件可實現應用需求，並能將任意復雜度的功能封裝在一起；所有構件之間的通訊是通過以連接件為中介的異步消息交換機制來實現的；構件相對獨立，構件之間依賴性較少。系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制線程之類的相關性假設。
◎C/S風格
C/S風格優點：
C/S架構具有強大的數據操作和事務處理能力，模型思想簡單，易於理解。系統的客戶應用程序和服務器構件分別運行在不同計算機上，系統中每台服務器都可以適合各構件的要求，這對於硬件和軟件的變化顯示出極大的適應性和靈活性，而且易於對系統進行擴充和縮小。系統中的功能構件充分隔離，客戶應用程序的開發集中於數據的顯示和分析，而數據庫服務器的開發則集中於數據的管理。 將大的應用處理任務分布到許多通過網絡連接的低成本計算機上，以節約費用。
C/S風格缺點：
開發成本較高，客戶端程序設計復雜，信息內容和形式單一，用戶界面風格不一，使用繁雜，不利於推廣使用，軟件移植困難，軟件維護和升級困難，新技術不能輕易應用
◎三層C/S風格
三層C/S風格優點：
允許合理地划分三層結構的功能，使之在邏輯上保持相對獨立性，能提高系統和軟件的可維護性，和可擴展性。允許更靈活選用相應的平台和硬件系統，使之在
處理負荷能力上與處理特性上分別適應於三層；並且這些平台和各個組成部分可以具有良好的可升級性和開放性。應用的各層可以並行開發，可以選擇各自最適合的開發語言。利用功能層有效地隔離開表示層與數據層，未授權的用戶難以繞過功能層而利用數據庫工具或黑
客手段非法訪問數據層，為嚴格的安全管理奠定了堅實的基礎。
要注意的問題：
三層C/S結構各層間的通信效率若不高，即使分配給各層的硬件能力很強，其作為整體來說
也達不到所要求的性能。設計時必須慎重考慮三層間的通信方法、 通信頻度及數據量。 這和提高各層的獨立性一樣是三層C/S結構的關鍵問題。
◎三層B/S風格
B/S風格就是上述三層應用結構的一種實現方式，其具體結構為：瀏覽器/Web服務器/數據庫服務器。優點（1）基於B/S體系結構的軟件，系統安裝，修改和維護全在服務器端解決。（2）提供了異種機，異種網，異種應用服務的聯機，聯網，同意服務的最現實的開放性基礎。缺點（1）缺乏對動態頁面的支持能力，沒有集成有效的數據庫處理能力。（2）在數據查詢等響應速度上，要遠遠低於C/S體系結構。（3）數據提交一般以頁面為單位，數據的動態交互性不強，不利於在線事務處理應用。
◎異構風格
◎領域特定的軟件架構(DSSA)
◎典型的軟件系統的架構類型
◎游戲系統的體系結構實例Darkstar
◎商業系統體系結構實例Explanner/Ai，Explanner/J
第5章 統一建模語言(UML).
復習UML的各種圖的含義，用途和畫法
類圖在UML中有何重要作用？
1.為開發人員提供這種模仿現實世界的表達方式。
2.讓分析員使用客戶所采用的術語和客戶交流，促使客戶說出所要解決的問題的重要細節。
RUP 4+1圖
什么是體系結構描述語言？它與程序語言以及UML有哪些區別與聯系？
ADL是一種形式化語言，在底層語義模型的支持下，為軟件系統的概念體系結構建模提供了具體語法和概念框架。基於底層語義的工具為體系結構的表示、分析、演化、細化、設計過程等提供支持。其三個基本元素是：構件、連接件、體系結構配置。
跟其他語言的比較：構造能力：ADL能夠使用較小的獨立體系結構元素來建造大型軟件系統；抽象能力：ADL使得軟件體系結構中的構件和連接件描述可以只關注它們的抽象特性，而不管其具體的實現細節；重用能力：ADL使得組成軟件系統的構件、連接件甚至是軟件體系結構都成為軟件系統開發和設計的可重用部件；組合能力：ADL使得其描述的每一系統元素都有其自己的局部結構，這種描述局部結構的特點使得ADL支持軟件系統的動態變化組合；異構能力：ADL允許多個不同的體系結構描述關聯存在；分析和推理能力：ADL允許對其描述的體系結構進行多種不同的性能和功能上的多種推理分析。
第6章 可擴展標記語言(XML).
XML的特點，作用，應用
特點：
簡潔有效；易學易用；開放的國際化標准；高效且可擴充
作用：
使得搜索更加有意義；
開發靈活的Web應用軟件；實現不同數據的集成；使用於多種應用環境；客戶端數據處理與計算；數據顯示多樣化；局部數據更新；與現有Web發布機制相兼容；可升級性；壓縮性能高
應用：
應用於客戶需要與不同的數據源進行交互時；應用於將大量運算復合分布在客戶端；應用於將統一數據以不同的面貌展現給不同的用戶；應用於網絡代理對所取得的信息進行編輯、增減以適應個人用戶的需要
XML與HTML的區別
HTML是一種格式化的語言，一個HTML文本可以看作一個格式化的程序，而一段符合XML語法規范的文本則是一段“純”數據，它的結構由其它的稱為DTD的文本來描述，而它的處理則可能是任何其它支持XML的容器或程序。與XML相比的另一個不同點是，XML是一種元標記語言。XML定義了一套元句法，與特定領域有關的標記語言都必須遵守。
XSL與CSS的區別
XML文檔的解析的各種API接口的特征和選擇原則
DOM，SAX，JDOM，JAXP
第8章 基於服務的體系結構。
SOA的定義，特征，用途（目的）
什么是SOA，SOA具有哪些特征？
SOA，是Service-Oriented Architecture的簡寫，是面向服務的體系結構的意思，對此，W3C，Service-architecture.com和Gartner給出了不同的定義，SOA是一種在計算環境中設計、開發、部署和管理離散邏輯單元（服務）模型的方法。由於SOA考慮到了系統內的對象，所以雖然SOA是基於對象的，但是作為一個整體，它卻不是面向對象的。
SOA的特征：（1）松散耦合；（2）粗粒度服務；（3）標准化接口。
用途（目的）：
便於將業務系統能力分解為獨立性高（或松散耦合），粗粒度的和可復用的服務； 便於對服務進行組裝和編排以滿足業務和流程的變化需求。
SOA的目標：
為方便構建數據服務，業務服務，展現層構件，使用戶容易借助界面建模，流程引擎和規則引擎實現靈活的應用組裝。
SOA的設計原則
明確定義的接口；自包含和模塊化；粗粒度；松耦合；互操作性、兼容和策略聲明
SOA的關鍵技術
發現服務層；描述服務層；消息格式層；編碼格式層；傳輸協議層
SOA的實現方法
1.Web Service
什么是Web服務？Web服務具有哪些特點？
答：Web服務是使用標准技術在Internet上運行的商務流程，它可以使用標准的Internet協議，將功能綱領性的體現在Internet和Intranet上。特征：1、使用標准協議規范2、使用協議的規范性3、高度集成能力4、完好的封裝性5、松散耦合
說明Web服務的體系結構模型？它的三個核心協議分別是什么？
Web服務是一種嶄新的分布式計算模型，是Web上數據和信息集成的有效機制。
三個構成元素為：Serverice Broker、Service Provider、Service Requester
三個核心協議：簡單對象訪問協議SOAP；統一描述、發現和集成協議UDDI；Web服務描述語言WSDL
WEB服務作為Web服務體系結構的核心，簡要說明Web服務的核心技術及其作用。
（1）：底層傳輸層，主要負責消息的傳輸機制。
（2）：服務通信協議層，服務通信協議層主要是以一種統一的方式描述並定義服務之間進行通信傳輸所需的技術標准。
（3）：服務描述層，主要以一種統一的方式描述服務的接口和消息交換方式。
（4）：服務層，主要功能是將遺留系統進行包裝，並通過發布的WSDL接口描述被定位和調用。
（5）：業務流程層，主要功能是支持服務發現，服務調用和點到點的服務調用，並將業務流程從服務的底層調用抽象出來。
（6）：服務注冊層，主要功能是使服務提供者能夠通過WSDL發布服務定義，並支持服務請求者查找所需的服務信息。
2.服務注冊表
3.企業服務總線
第9章 富互聯網應用體系結構。
RIA的優點
1.RIA利用相對健壯的客戶端描述引擎，這個引擎能夠提供內容密集、響應速度快和圖形豐富的用戶界面。RIA的另一個好處在於，數據能夠被緩存在客戶端，從而可以實現一個比基於HTML的響應速度更快且數據往返於服務器的次數更少的用戶界面。
RIA客戶端開發技術類別
Macromedia Flash/Flex；AJAX；Laszlo；Avolon；Java SWT；XUL；Bindows；Oracle Forms
Javascript/Html5: 被認為是最有前途的RIA技術
Ajax開發模式
Ajax核心技術
Ajax開發過程
AJAX技術的核心是什么？AJAX是如何將多種已有的技術綁定在一起的？這些技術各自起到什么作用？
AJAX技術的核心是javascript調用XML的異步傳輸。借助於AJAX,可以在用戶單擊按鈕時，使用JavaScript和DHTML立即更新用戶界面，並向服務器發出異步請求，以執行更新或查詢數據庫。當請求返回時，就可以使用JavaScript和css來相應的更新用戶界面，而不是刷新整個頁面。最重要的是，用戶甚至不知道瀏覽器正在與服務器通信，Web站點看起來是即時響應的。
XML的高拓展性、高靈活性，使得其可以描述各種不同類的應用軟件中的不同類型的數據，可以實現不同數據的集成。
XHTML結合了部分XML的強大功能和HTML的簡單特性。
JavaScript主要用來傳遞用戶界面上的數據到服務端並返回結果。
XMLHttpRequest用來響應通過HTTP傳遞的數據，一旦數據返回到客戶端，就可以立刻使用DOM將數據顯示在網頁上。
DOM為XML文檔的已解析版本定義了一組接口。
XSLT能夠減少大量的用JavaScript編寫的應用邏輯。
CSS提供了從內容中分離應用樣式和設計的機制。
第11章 用戶界面設計
OO分析模型 --> 設計模型
接口設計包含用戶接口設計=用戶界面設計
用戶界面設計的黃金規則及其含義
用戶操縱控制
減少用戶的記憶負擔
保持界面一致
用戶操作控制
以不強迫用戶進入不必要的或不希望的動作的方式來定義交互模式。提供靈活的交互。
允許用戶交互被中斷和撤銷。當技能級別增長時可以使交互流線化並允許定制交互。使用戶與內部技術細節隔離開來。設計應允許用戶與出現在屏幕上的對象直接交互。
減輕用戶記憶負擔
減少對短期記憶的要求。建立有意義的缺省。定義直觀的快捷方式。界面的視覺布局應該基於真實世界的象征。以不斷進展的方式揭示信息。
保持界面一致
允許用戶將當前任務放入有意義的環境中。在應用系統家族內保持一致性。如果過去的交互模型已經建立起了用戶期望除非有不得已的理由，否則不要改變它。
界面分析從哪些方面着手
WebApp 界面設計
有效的WebApp 界面
WebApp界面設計原則
第12章 基於體系結構的軟件開發
軟件設計里的模式的層次
設計模式 – 定義，作用，分類
什么是設計模式？它與風格、框架有什么區別與聯系？
設計模式（Design pattern）是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。對通用設計問題的重復解決方案。
軟件體系結構風格是描述某一特定應用領域中系統組織方式的慣用模式。軟件框架是整個或部分系統的可重用設計；模式比框架更加抽象；框架是模式的特例化；設計模式被實現成為框架后，可以極大的減輕從設計到實現的鴻溝；利用了模式的框架比沒有利用模式的框架更容易理解、更能被設計與實現重用；通常成熟的框架包含了多種設計模式；一個框架不僅可以具體實現一個模式，還可以具體的實現多個模式；設計模式與風格兩者為近義詞，通常情況下可以互相通用；風格主要是指大的，宏觀的設計。模式既可宏觀，又可微觀。
作用：
1、復用解決方案——通過復用已經公認的設計，我能夠在解決問題時取得先發優勢，而且避免重蹈前人覆轍。我可以從學習他人的經驗中獲益，用不着為那些總是會重復出現的問題再次設計解決方案了。
2、確立通用術語——開發中的交流和協作都需要共同的詞匯基礎和對問題的共識。設計模式在項目的分析和設計階段提供了共同的基准點。
3、提高觀察高度－－模式還為我們提供了觀察問題、設計過程和面向對象的更高層次的視角，這將使我們從“過早處理細節”的桎梏中解放出來。
4、大多數設計模式還能使軟件更容易修改和維護。其原因在於，它們都是久經考驗的解決方案。所以，它們的結構都是經過長期發展形成的，比新構思的解決方案更善於應對變化。而且，這些模式所用代碼往往更易於理解——從而使代碼更易維護。
美麗的架構的原則和特性
GoF的23種經典設計模式
分類：
1.創建型模式
▪工廠方法模式▪ 抽象工廠模式▪ 建造者模式▪ 原型模式▪ 單例模式
2.結構型模式
▪ 適配器模式▪ 橋接模式▪ 組合模式▪ 裝飾模式▪外觀模式▪ 享元模式▪ 代理模式
3.行為型模式
▪ 職責鏈模式▪ 命令模式▪ 解析器模式▪ 迭代器模式▪ 中介者模式▪ 備忘錄模式▪ 觀察者模式
▪ 狀態模式▪ 策略模式▪ 模版方法模式▪ 訪問者模式
工廠模式，抽象工廠模式的具體代碼實現示例
MVC特點和Java實現示例
MVP
中間件技術
中間件的定義，優點，功能，分類，發展趨勢
定義：
中間件是處於系統軟件和應用軟件之間的一類軟件。
優點：
它使設計師集中設計與應用有關的部分，大大簡化了設計和維護工作。
功能：
1.負責客戶機與服務器之間的連接和通信，以及客戶機與應用之間的高效率通信機制。
2.提供應用層不同服務之間的互操作機制沒，以及應用層與數據庫之間的連接和控制機制。
3.提供一個多層體系結構的應用開發和運行的平台，以及一個應用開發框架，支持模塊化的應用開發。
4.屏蔽硬件、操作系統、網絡和數據庫的差異。
5.提供應用的負載和高可用型、安全機制和管理功能，以及交易管理機制，保證交易的一致性。
6.提供一組通用的服務區執行不同的功能，避免重復的工作和是應用之間可以協作。
分類：
采用自底向上的方式來划分，可分為底層中間件、通用型中間件和集成性中間件三大層次。
主要的中間件：RPC，ORB，RMI，RMI-IIOP,MOM, 事務處理監控器
編程語言Scala有哪些特點？
編程語言Scala的特點：
1）測試容易。函數性語言（Lisp等）的優點。
2）代碼量少。腳本語言（Ruby,Python等）的優點。
3）由編譯器進行型檢查（型宣言不要）。靜的型定義語言（Java,C等）和動的型定義語言（Ruby，Lisp等）的優點。
4）可直觀易懂地記述處理流程。面向過程語言（Cobol,C等）的優點。
5）可實現封裝，繼承，多態，面向對象開發。面向對象語言（Java，C#等）的優點。
1.關於軟件開發，有哪些新趨勢？
一、在全球金融危機布景下，開源軟件將取得更多的商場時機
二：開源軟件將主導移動運用軟件的開展
三：將開源軟件推行到雲核算、SaaS(軟件即效勞)
選擇一個你熟悉的大型軟件系統，分析其體系結構中用到的風格，以及表現出的特點（為什么要采用這種風格？帶來了哪些優勢？具有哪些不足？）。
對社交軟件體系結構中用到的風格分析：采用了C/S風格，並且在一定程度上算為三層C/S風格
采用這種風格的原因：
表示層：社交信息的顯示，並提供了更新和搜索等操作
功能層：具有搜索、在線聊天、離線留言、文件傳輸等等功能
數據層：有數據庫服務器提供留言、相冊、好友信息等數據
優點：使邏輯結構更為清晰，分類明確，給用戶更好的體驗
缺點：需要數據通信的支持，對網絡的依賴很高，沒有網絡，許多功能將沒有意義。
對於一個實際的系統，不能判斷它是A風格、B風格還是C風格，因為沒有足夠的理由把它歸為任何一種獨立的體系結構風格。這種系統類型被稱為異構結構，對應着它是分層系統，所以這個虛擬系統是分層系統。
這個系統包含的體系結構有：管道和過濾器風格、事件驅動風格、分層系統。
管道和過濾器風格
管道和過濾器風格的優點：
管道和過濾器風格的缺點：
事件驅動風格
以體系結構定義作為開發框架,支持基於構件的開發.該語言提供了建模,分析,仿真和代碼生成的能力,但是沒有將連接子顯式地表示為一階實體。
分層系統
分層系統的優點：支持基於抽象程度遞增的系統設計；支持功能增強；支持重用。
分層系統的缺點：並不是每個系統都可以很容易的划分為分層的模式，甚至即使是層次化的，出於性能的考慮，也不得不吧一些低及或高級的功能綜合起來；很難找到一個合適的、正確的層次抽象方法。
C2風格
系統中的構件可實現應用需求，並能將任意復雜度的功能封裝在一起；
所有構件之間的通訊是通過以連接件為中介的異步消息交換機制來實現的；
構件相對獨立，構件之間依賴性較少。系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制線程之類的相關性假設。
基於消息總線的風格
消息總線是系統的連接件、負責消息的分派、傳遞和過濾以及處理結果的返回。消息是構件之間通信的唯一方式。由於構件通過總線進行連接，並不要求各個構件具有相同的地址空間或局限在一台機器上，因此該風格可以很好的刻畫分布式開發系統，以及CORBA.DCOM和EJB規范的系統
traveler.com是一家在線旅游信息服務公司，其主要業務是為自助旅游者提供關於旅游線路及周邊信息的服務。隨着公司業務的不斷發展，公司用戶要求提供基於位置的增值旅游信息服務，即希望能夠在給定位置（利用 GPS 全球定位系統獲取）的情況下得到周邊的地理位置、住宿、餐飲和交通等旅游相關信息。針對該需求，公司技術人員對現有系統的體系結構和運行模式進行了認真分析，決定采用Mashup技術集成來自其合作網站（設為A、B、C、D）的信息，滿足用戶的需求。具體實現方式是：
（1）利用A網站提供的地圖信息，得到用戶位置相關的周邊地理信息。
（2）B網站根據用戶的位置信息向其提供周邊的住宿信息。
（3）C網站根據用戶的位置信息向其提供周邊的餐飲信息。
（4）D網站根據用戶的位置信息向其提供周邊的公交線路等信息。
問題1：
（2）對用戶請求的服務作出相應的處理。（3）Traveler網站向A網站請求返回用戶所處位置周邊的地圖信息。（5）Traveler網站向B網站請求返回用戶所處位置周邊的住宿信息。
（7）對網站提供的信息作出響應的處理。
問題2：
聚合的是服務時，則通過調用API來獲取各個源的功能，Mashup最常用的API類型一般有兩種，分別是REST和SOAP；如果聚合的是數據，則使用RSS來獲取數據。
問題3：
客戶端的用戶界面能表現和應對更多更復雜的數據模式，這樣才能處理客戶端的運算以及異步發送、接收數據。當頁面在服務器上創建完成並交付給HTML后，客戶端的程序為用戶提供比與服務器交互更良好的感受。為了達到高度復雜的數據模式，客戶端允許用戶構建一個高響應、交互式的應用程序。可以實現一個比基於HTML的響應速度更快且數據往返於服務器的次數更少的用戶界面。
一方認為應采用微軟.net平台，一方認為應采用Java企業版平台
給出兩個平台的優勢和共有的特點
(1)、.Net平台：易於部署和設置、多程序設計語言支持、針對特定平台的優化支持
Java企業版平台：良好跨平台可移植性支持、豐富的多廠商外部支持、良好的源代碼以外的可定制性的支持
共同特點：良好的Web多層應用開發支持、良好的O/R(對象/關系）映射支持、良好的Web服務支持
J2EE更適合大型企業，大企業鍾情J2EE
.NET更適合中小型企業，實施速度快，維護容易，中小企業則看好.Net
J2EE平台更穩定
.NET平台更適合與微軟系統的軟件結合
支持J2EE平台的服務器更好也更貴
支持.NET平台的服務器占據低端市場，價格適中
J2EE平台適合大數據量並發處理的系統
.NET平台適合與微軟應用軟件（例如Office、Project、Exchange等）結合緊密的系統
(2)、MVC模式中各組間應采用何種構件實現
在基於EJB的重量級框架中,實現的構件分別為：
模型（Model）：由EJB構件實現
視圖（View）：由JSP構件實現
控制器（Controller）：由Servlet構件實現
在基於Struts等的輕量級框架中,實現的構件分別為：
模型（Model）：由Java Bean構件實現
視圖（View）：由JSP構件實現
控制器（Controller）：由Servlet構件實現
(3)、MVP模式與MVC模式的主要區別為：
① 在組件耦合度方面：在MVP模式中,視圖並不直接使用模型,它們之間的通信通過Presenter進行,從而實現了視圖與模型的分離,而在MVC模式中,視圖直接與模型交互。
② 在組件分工方面：在MVP模式中,視圖需要處理鼠標及鍵盤等觸發的界面事件,而在MVC模式中這通常是由控制器完成的工作；在MVP模式中,系統核心業務邏輯組織集中在Presenter中,而在MVC模式中,相應的控制器通常只完成事件的分發。
③ 在開發工程化支持方面：MVP模式可更好地支持單元測試,而在MVC模式中,由於模型與視圖綁定,因此難以實施相應的單元測試；在MVP模式中,Presenter基於約定接口與視圖和模型交互,可更好地支持組件的重用。
(4)、事務的基本特征包括：
原子性：一個事務中的所有操作,要么全部完成,要么全部不完成,不會結束在中間某個環節。事務在執行過程中發生錯誤,會被回滾到事務開始前的狀態,就像這個事務從來沒有執行過一樣。
一致性：在事務開始之前和事務結束以后,數據的完整性限制沒有被破壞。
隔離性：兩個事務的執行是互不干擾的,兩個事務時間不會互相影響。
持久性：在事務完成以后,該事務對數據所作的更改便持久地保存在數據庫之中,並且是完全的。
EJB規范支持的兩種事務控制方法為：
容器維護的事務（Container Managed Transaction,CMT）：由EJB容器根據部署描述符或EJB構件注釋中指定的事務屬性自動控制事務的邊界,容器維護的事務是方法級的,即默認將一個方法當作一個事務執行,當方法執行的過程中發生系統級異常,容器會自動將事務回滾,從而將方法前面執行的結果恢復。
Bean維護的事務（Bean Managed Transaction,BMT）：由程序員在EJB的源代碼中控制事務執行的邊界,事務的邊界通過Java事務接口（Java Transaction API,JTA）進行控制,Bean維護的事務可以跨越方法的邊界。
1.什么是軟件重用，軟件重用的層次可以分為哪幾個級別？
答：軟件重用是指在兩次或多次不同的軟件開發過程中重復使用相同或相近軟件元素的過程。軟件重用的層次按重用的粒度大小可分為程序代碼重用，測試用例重用，設計文檔重用，設計過程重用，需求分析文檔重用及領域知識重用。
2.軟件體系結構模型可以分為哪幾種，具體是如何划分的？
答：軟件結構的核心模型由5種元素組成：構件、連接件、配置、端口和角色。其中，構件、連接件和配置是最基本的元素。
3.體系結構的設計和演化中實驗原型階段分為2個周期，分別對各周期簡述。
答：第一周期沒有具體的、明確的日期，第一周期結束會形成圖形用戶界面的初始設計和問題域模型兩個版本。第二周期的任務是設計和建立一個下次軟件體系結構，具有以下特征：足夠靈活，能包括現有元素，也有包括新增功能；提供相當穩定的結構，在這個結構中，原型能在實驗原型階段進行演化；開發一個高效的開發的組織，允許開發人員並行地在原型基礎上進行開發。
4.連接件：是用來建立構件間的交互以及支配這些交互規則的體系結構構造模塊。
5.體系結構配置：體系結構配置或拓撲是描述體系結構的構件與連接件的連接圖。體系結構配置提供信息來確定構件是否正確連接、接口是否分配、連接件構成的通信是否正確，並說明實現要求行為的組合含義。
6.軟件體系結構的動態性：指軟件系統在運行時刻的體系結構變動。
7.Web服務棧：Web服務棧是一種全新的體系結構，整個Web服務的技術系列被稱為Web服務棧。
8.SOAP：簡單對象訪問協議，SOAP是一個基於XML的，在松散分布式環境中交換結構化信息的輕量級協議，它為在一個松散的、分布式環境中使用XML交換結構化的和類型化的信息提供了一種簡單的機制。
9.WSDL標准：是一種XML格式，用來實現Web服務棧中的描述層，將網絡服務描述為能夠進行消息交換的通信端點集合。
10.可修改性：是指能夠快速地以較高的性能價格比對系統進行變更的能力。通常以某些具體的變更為基准，通過考察這些變更的代價衡量可修改性。可修改性包括：1可維護性，2可擴展性，3結構重組，4可移植性
11.核心資源：是領域工程所有結果的集合，是產品線中產品構造的基礎。
12.軟件產品線：軟件產品線就是在一個公共的軟件資源集合基礎上建立起來的共享同一個特性集合的系統集合。
13.SEI模型：SEI將產品線的基本活動分為三部分，分別是核心資源開發，產品開發和管理。
14.產品線體系結構：產品線體系結構是一個軟件體系結構和一組在一族產品中可重用的構件，為增加軟件重要、為企業降低軟件開發和維護的成本提供了一個重要的途徑。
15.體系結構的生命周期模型分為哪幾個階段？
答：1、需求分析階段 2、建立軟件體系結構階段 3、設計階段 4、實現階段
16.請簡述軟件體系結構的生命周期。
答：以自然語言進行軟件結構的非形式化描述，接着運用合適的形式化數學理論模型對上一階段的非形式化描述進行規范定義，從而得到軟件形式結構的形式化規范描述。對設計好的軟件體系結構進行驗證和求精，直到不需要進行求精驗證時，轉入軟件體系結構的實施。在此階段將軟件結構實施於系統設計中，並將其結構的構件和連接件有機組織在一起。判斷軟件體系結構是否需要擴展，演化。需要從則重復以上步驟，否則對該體系結構進行評價、度量，轉入終結階段。
17.動態體系結構特征有哪些？
答：1、可構造性動態特征2、適應性動態特征3、智能型動態特征
18.請簡述基於構件的動態體系結構模型是如何支持運行系統更新的？
答：1、檢測更新的范圍 2、更新准備工作 3、執行更新 4、存儲更新
19.軟件體系結構評估的主要方式有哪些？
答：1.基於調查問卷或檢查表的評估方式：調查問卷是一系列可以應用到各種體系結構評估的相關問題，這些問題可能涉及體系結構對設計決策，有些問題涉及體系結構的文檔，有的問題針對體系結構描述本身細節問題等。檢查表中也包含一系列比調查問卷更細節和具體的問題，它們更趨向於考察某些關心的質量屬性。這一評估方法比較靈活自由，可評估多種質量屬性，也可以在軟件體系結構設計的多個階段進行。2.基於場景的評估方式：場景是一系列有序使用或修改系統的步驟。基於場景的方式由SEI首先提出並應用在體系結構權衡分析方法和軟件體系結構分析方法中，這種軟件體系評估方式分析軟件體系結構對場景也就是對系統對使用或修改活動的支持程度，從而判斷該體系結構對這一場景所代表對質量需求對滿足程度。3.基於度量的評估方式：度量是指為軟件產品對某一屬性所賦予對數值。此評估技術涉及3個基本活動：首先需要建立屬性和質量之間的映射關系，然后從軟件體系結構文檔中獲取度量信息，最后根據映射原則分析推導出系統對某些質量屬性。
20.簡述雙生命周期中的領域工程階段的主要任務及內容。
答：（1）領域分析。利用現有的系統設計、體系結構和需求建立領域模型。（2）領域設計。用領域模型確定領域/產品線的共性和可變性，為產品線設計體系結構。（3）領域實現。基於領域體系結構開發領域可重用資源（構件、文檔、代碼生成器）。
21.軟件產品線的過程模型有哪些？
答：1、雙周期模型 2、SEI模型 3、三生命周期模型
22.請簡述並畫出“4+1”視圖模型
答：“4+1”視圖模型即從5個不同的視角（邏輯視圖，進程視圖，物理視圖，開發視圖和場景視圖）來描述軟件體系結構。每個視圖之關心系統的一個側面，5個視圖結合在一起才能反映系統的軟件體系結構的全部內容。
邏輯視圖主要支持系統的功能需求，即系統提供給最終用戶的服務；開發視圖也稱模塊視圖，主要側重於軟件模塊的組織和管理；進程視圖側重於系統的運行特性，主要關注一些非功能性的需求，例如系統的性能和可用性；物理視圖主要考慮如何把軟件映射到硬件上，它通常要考慮到系統性能、規模、可靠性等；場景可以看做是那些重要系統活動的抽象，它使4個視圖有機聯系起來，從某種意義上說場景是最重要的需求抽象。