軟件體系結構原理、方法與實踐總結

第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體系結構風格：能夠歸納爲經過鏈接件綁定在一塊兒的按照一組規則動做的並行構件網絡。組織規則有：一、系統中的構件和鏈接件都有一個頂部一個底部。二、構件的頂部應鏈接到某鏈接件的底部，構件的底部應鏈接到鏈接件的頂部，構件之間不能直接鏈接。三、一個鏈接件能夠和任意數目的其餘構件和鏈接件相連。四、當兩個鏈接件直接相連時，必須由其中一個底部到另外一個的頂部。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上。特徵：一、使用標準協議規範二、使用協議的規範性三、高度集成能力四、無缺的封裝性五、鬆散耦合

說明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）是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。對通用設計問題的重複解決方案。
軟件體系結構風格是描述某一特定應用領域中系統組織方式的慣用模式。軟件框架是整個或部分系統的可重用設計；模式比框架更加抽象；框架是模式的特例化；設計模式被實現成爲框架後，能夠極大的減輕從設計到實現的鴻溝；利用了模式的框架比沒有利用模式的框架更容易理解、更能被設計與實現重用；一般成熟的框架包含了多種設計模式；一個框架不只能夠具體實現一個模式，還能夠具體的實現多個模式；設計模式與風格二者爲近義詞，一般狀況下能夠互相通用；風格主要是指大的，宏觀的設計。模式既可宏觀，又可微觀。
做用：
一、複用解決方案——經過複用已經公認的設計，我可以在解決問題時取得先發優點，並且避免重蹈前人覆轍。我能夠從學習他人的經驗中獲益，用不着爲那些老是會重複出現的問題再次設計解決方案了。
二、確立通用術語——開發中的交流和協做都須要共同的詞彙基礎和對問題的共識。設計模式在項目的分析和設計階段提供了共同的基準點。
三、提升觀察高度－－模式還爲咱們提供了觀察問題、設計過程和麪向對象的更高層次的視角，這將使咱們從「過早處理細節」的桎梏中解放出來。
四、大多數設計模式還能使軟件更容易修改和維護。其緣由在於，它們都是久經考驗的解決方案。因此，它們的結構都是通過長期發展造成的，比新構思的解決方案更善於應對變化。並且，這些模式所用代碼每每更易於理解——從而使代碼更易維護。
美麗的架構的原則和特性
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.關於軟件開發，有哪些新趨勢？
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.體系結構的生命週期模型分爲哪幾個階段？  答：一、需求分析階段  二、創建軟件體系結構階段  三、設計階段  四、實現階段 16.請簡述軟件體系結構的生命週期。 答：以天然語言進行軟件結構的非形式化描述，接着運用合適的形式化數學理論模型對上一階段的非形式化描述進行規範定義，從而獲得軟件形式結構的形式化規範描述。對設計好的軟件體系結構進行驗證和求精，直到不須要進行求精驗證時，轉入軟件體系結構的實施。在此階段將軟件結構實施於系統設計中，並將其結構的構件和鏈接件有機組織在一塊兒。判斷軟件體系結構是否須要擴展，演化。須要從則重複以上步驟，不然對該體系結構進行評價、度量，轉入終結階段。 17.動態體系結構特徵有哪些？ 答：一、可構造性動態特徵二、適應性動態特徵三、智能型動態特徵 18.請簡述基於構件的動態體系結構模型是如何支持運行系統更新的？  答：一、檢測更新的範圍  二、更新準備工做  三、執行更新  四、存儲更新 19.軟件體系結構評估的主要方式有哪些？ 答：1.基於調查問卷或檢查表的評估方式：調查問卷是一系列能夠應用到各類體系結構評估的相關問題，這些問題可能涉及體系結構對設計決策，有些問題涉及體系結構的文檔，有的問題針對體系結構描述自己細節問題等。檢查表中也包含一系列比調查問卷更細節和具體的問題，它們更趨向於考察某些關心的質量屬性。這一評估方法比較靈活自由，可評估多種質量屬性，也能夠在軟件體系結構設計的多個階段進行。2.基於場景的評估方式：場景是一系列有序使用或修改系統的步驟。基於場景的方式由SEI首先提出並應用在體系結構權衡分析方法和軟件體系結構分析方法中，這種軟件體系評估方式分析軟件體系結構對場景也就是對系統對使用或修改活動的支持程度，從而判斷該體系結構對這一場景所表明對質量需求對知足程度。3.基於度量的評估方式：度量是指爲軟件產品對某一屬性所賦予對數值。此評估技術涉及3個基本活動：首先須要創建屬性和質量之間的映射關係，而後從軟件體系結構文檔中獲取度量信息，最後根據映射原則分析推導出系統對某些質量屬性。 20.簡述雙生命週期中的領域工程階段的主要任務及內容。 答：（1）領域分析。利用現有的系統設計、體系結構和需求創建領域模型。（2）領域設計。用領域模型肯定領域/產品線的共性和可變性，爲產品線設計體系結構。（3）領域實現。基於領域體系結構開發領域可重用資源（構件、文檔、代碼生成器）。 21.軟件產品線的過程模型有哪些？ 答：一、雙週期模型 二、SEI模型  三、三生命週期模型 22.請簡述並畫出「4+1」視圖模型 答：「4+1」視圖模型即從5個不一樣的視角（邏輯視圖，進程視圖，物理視圖，開發視圖和場景視圖）來描述軟件體系結構。每一個視圖之關心繫統的一個側面，5個視圖結合在一塊兒才能反映系統的軟件體系結構的所有內容。 邏輯視圖主要支持系統的功能需求，即系統提供給最終用戶的服務；開發視圖也稱模塊視圖，主要側重於軟件模塊的組織和管理；進程視圖側重於系統的運行特性，主要關注一些非功能性的需求，例如系統的性能和可用性；物理視圖主要考慮如何把軟件映射到硬件上，它一般要考慮到系統性能、規模、可靠性等；場景能夠看作是那些重要系統活動的抽象，它使4個視圖有機聯繫起來，從某種意義上說場景是最重要的需求抽象。