【軟件信息架構(gòu)】考試知識(shí)點(diǎn)貫通

軟件信息架構(gòu)考試知識(shí)點(diǎn)貫通什么是架構(gòu)？有哪幾種常見(jiàn)的架構(gòu)？架構(gòu)是體現(xiàn)在它的組件中的一個(gè)系統(tǒng)的基本組織、他們彼此的關(guān)系、與環(huán)境的關(guān)系及指導(dǎo)它的設(shè)計(jì)和發(fā)展的原則。常見(jiàn)的架構(gòu)有邏輯架構(gòu)、開(kāi)發(fā)架構(gòu)、進(jìn)程架構(gòu)、物理架構(gòu)、場(chǎng)景架構(gòu)2.架構(gòu)、框架、模式的區(qū)別？架構(gòu)、框架、模式是一種從大到小的關(guān)系，也是一種組合關(guān)系。從復(fù)用角度講，設(shè)計(jì)模式是代碼級(jí)復(fù)用、框架是模塊級(jí)復(fù)用、架構(gòu)是系統(tǒng)級(jí)復(fù)用、平臺(tái)是應(yīng)用級(jí)復(fù)用。

架構(gòu)一般針對(duì)一個(gè)行業(yè)或一類應(yīng)用，是技術(shù)和應(yīng)用完美的結(jié)合?？蚣鼙燃軜?gòu)更具體，框架不是現(xiàn)成可用的應(yīng)用系統(tǒng)。是一個(gè)半成品，需要后來(lái)的開(kāi)發(fā)人員進(jìn)行二次開(kāi)發(fā)，實(shí)現(xiàn)具體功能的應(yīng)用系統(tǒng)。

框架是為了解決特定問(wèn)題而存在的，其它諸如ORM框架、模板框架、緩存框架，框架不能直接使用，需要二次開(kāi)發(fā)。設(shè)計(jì)模式就是告訴你針對(duì)特定問(wèn)題如何組織類、對(duì)象和接口之間的關(guān)系，是前人總結(jié)的經(jīng)驗(yàn)。

設(shè)計(jì)模式和框架在軟件設(shè)計(jì)中是兩個(gè)不同的研究領(lǐng)域。設(shè)計(jì)模式研究的是一個(gè)設(shè)計(jì)問(wèn)題的解決方法，一個(gè)模式可應(yīng)用于不同的框架和被不同的語(yǔ)言所實(shí)現(xiàn)；而框架則是一個(gè)應(yīng)用的體系結(jié)構(gòu)，是一種或多種設(shè)計(jì)模式和代碼的混合體雖然它們有所不同，但卻共同致力于使人們的設(shè)計(jì)可以被重用，在思想上存在著統(tǒng)一性的特點(diǎn)，因而設(shè)計(jì)模式的思想可以在框架設(shè)計(jì)中進(jìn)行應(yīng)用。模式：是在給定的上下文中針對(duì)一個(gè)常見(jiàn)問(wèn)題的一個(gè)常規(guī)解決方法。平臺(tái)的概念類似框架，但又結(jié)合的架構(gòu)的考慮，它是更高層面上的“框架”，準(zhǔn)確說(shuō)是一種應(yīng)用。它是針對(duì)企業(yè)用戶，為解決企業(yè)業(yè)務(wù)需要而形成的產(chǎn)品。3.架構(gòu)的元件有哪些？4.了解一下流程，特別是迭代、敏捷流程（課本P32~P35）流程：軟件行業(yè)中使用的各種方法之間的許多差異與遵循的流程有關(guān)，而不再是角色、工作產(chǎn)品、活動(dòng)和執(zhí)行的任務(wù)。（此句摘于書中，不準(zhǔn)確的定義）迭代的概念？在每一次迭代的過(guò)程中需要經(jīng)歷每一個(gè)階段，包括需求、架構(gòu)、開(kāi)發(fā)和測(cè)試。迭代是一個(gè)明確的、固定時(shí)間的活動(dòng)序列，它們會(huì)產(chǎn)生一個(gè)可執(zhí)行產(chǎn)品的（內(nèi)部或外部）版本。隨著項(xiàng)目的推進(jìn)，這些版本會(huì)提供性能方面的逐步改善。迭代特征：迭代有明確的評(píng)估標(biāo)準(zhǔn)。迭代要有一個(gè)計(jì)劃的可論證性能。迭代以一個(gè)較小的里程碑結(jié)束。在迭代過(guò)程中，更新工作產(chǎn)品。在迭代過(guò)程中，對(duì)系統(tǒng)進(jìn)行集成和測(cè)試。階段的概念？階段是一個(gè)專門的活動(dòng)類型，它代表項(xiàng)目中以一個(gè)決策點(diǎn)，主要里程碑或一組可交付物借書的一個(gè)很重要時(shí)期。階段和迭代的異同點(diǎn)？階段提供了定義良好的業(yè)務(wù)的里程碑，它確保迭代向前推進(jìn)并匯集在一個(gè)解決方案上而不是不確定地重復(fù)。迭代具有（固定周期的）固定時(shí)間，而階段以目標(biāo)位基礎(chǔ)。階段沒(méi)有固定時(shí)間，因?yàn)橐粋€(gè)階段的完成是基于項(xiàng)目的裝填評(píng)定的。階段和就迭代共同為迭代開(kāi)發(fā)流程提供了基礎(chǔ)。每個(gè)階段的目標(biāo)通過(guò)執(zhí)行這個(gè)階段內(nèi)的一個(gè)或多個(gè)迭代來(lái)達(dá)到。每個(gè)階段最終給都有一個(gè)主要里程碑和去頂這個(gè)階段的目標(biāo)是否達(dá)成的評(píng)估。階段可以分為：起始階段、細(xì)化階段、構(gòu)造階段、移交階段。起始和細(xì)化階段也可以歸納為制造過(guò)程，構(gòu)造和移交階段也可以歸納為生產(chǎn)過(guò)程。具體每一個(gè)階段的詳細(xì)任務(wù)請(qǐng)見(jiàn)書本P36上部分。敏捷流程（課本內(nèi)容太少了），只提煉了敏捷流程的基礎(chǔ)原則：注重個(gè)人及其交互，勝于過(guò)程與工具。注重可用的軟件，勝于詳盡的文檔。注重客戶協(xié)作，勝于七月談判。注重效應(yīng)變化，勝于恪守計(jì)劃。關(guān)于軟件架構(gòu)的4+1視圖模型（要和UML結(jié)合）準(zhǔn)備知識(shí)：視點(diǎn)和視圖的概念？構(gòu)架的視點(diǎn)是用于構(gòu)建和利用一個(gè)視圖的常規(guī)說(shuō)明書。它是一個(gè)模式或模本，可以利用它確定一個(gè)視圖的目標(biāo)和用戶及其創(chuàng)建和分析的技術(shù)，從而來(lái)開(kāi)發(fā)單獨(dú)的視圖。4+1視圖模型邏輯視圖是設(shè)計(jì)的對(duì)象模型過(guò)程視圖獲取設(shè)計(jì)的并發(fā)和同步方面的信息開(kāi)發(fā)視圖描述的是在團(tuán)建開(kāi)發(fā)環(huán)境中的軟件靜態(tài)組織物理視圖描述了軟件與硬件之間的映射，還反應(yīng)了它在分布式方面的信息。一個(gè)架構(gòu)的描述是通過(guò)少許挑選使用的用例或者場(chǎng)景來(lái)說(shuō)明的真正理解三層經(jīng)典架構(gòu)和MVC架構(gòu)（見(jiàn)PPT）準(zhǔn)備知識(shí)：層的概念？下層組件負(fù)責(zé)對(duì)上層組件提供服務(wù)。上層組件可以使用下層組件定義的服務(wù)，但下層組件對(duì)上層組件一無(wú)所知。層與層之間通常是不透明的，每一層都具有獨(dú)立的職責(zé)。不同層的軟件構(gòu)件可以分布在多臺(tái)機(jī)器上，也可以部署在同一臺(tái)機(jī)器上。C/S常被稱為傳統(tǒng)的兩層，B/S稱為三層分層模式：傳統(tǒng)C/S（無(wú)明顯分層）、兩層、三層、四層、多層基本思想：將邏輯功能相似的類封裝到一個(gè)組件中。經(jīng)典的三層結(jié)構(gòu)：表現(xiàn)層：處理用戶和信息系統(tǒng)之間的交互。業(yè)務(wù)邏輯層：也稱為領(lǐng)域?qū)踊驊?yīng)用層，是信息系統(tǒng)所有和領(lǐng)域相關(guān)的工作。數(shù)據(jù)訪問(wèn)層：一般指與數(shù)據(jù)庫(kù)的交互，主要責(zé)任是數(shù)據(jù)庫(kù)記錄的存取。MVC架構(gòu)模型視圖控制器架構(gòu)MVC：Model&&View&&Control模型：即相關(guān)的數(shù)據(jù)，它是對(duì)象的內(nèi)在屬性視圖：是模型的外在表現(xiàn)形式，一個(gè)模型可以對(duì)應(yīng)一個(gè)或者多個(gè)視圖，視圖還具有與外界交互的功能控制器：是模型與視圖的聯(lián)系紐帶，控制器提取通過(guò)視圖傳輸進(jìn)來(lái)的外部信息轉(zhuǎn)化成相應(yīng)事件，然后由對(duì)應(yīng)的控制器對(duì)模型進(jìn)行更新；相應(yīng)的，模型的更新與修改將通過(guò)控制器通知視圖，保持視圖與模型的一致性5、了解SOA：SOA，面向服務(wù)的體系結(jié)構(gòu)（service-orientedarchitecture）是一個(gè)組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）通過(guò)這些服務(wù)之間定義良好的接口和契約聯(lián)系起來(lái)。接口是采用中立的方式進(jìn)行定義的，它應(yīng)該獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺(tái)、操作系統(tǒng)和編程語(yǔ)言。這使得構(gòu)建在各種這樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。6、畫類圖和時(shí)序圖的方法： 畫類圖的一般步驟：識(shí)別并篩選名詞概念識(shí)別類之間的關(guān)系（關(guān)聯(lián)：特殊的關(guān)聯(lián)——聚合：描述部分和整體的關(guān)系，如果一個(gè)部分屬于某個(gè)整體，那么該部分就無(wú)法同時(shí)屬于其他整體，也無(wú)法單獨(dú)存在，則這種聚合關(guān)系叫做組合）：繼承：類圖舉例：（圖書管理系統(tǒng)）時(shí)序圖畫法：餐館中顧客點(diǎn)菜時(shí)序圖：7、邊界類、控制類、實(shí)體類邊界類：邊界類的職責(zé)是完成系統(tǒng)與其參與者之間的交互。接收來(lái)自用戶和外部系統(tǒng)的信息與請(qǐng)求、將信息與請(qǐng)求提交給用戶和外部系統(tǒng)邊界類包括屏幕窗口、通信接口、打印機(jī)接口、傳感器、終端以及專用API（應(yīng)用程序編程接口）等軟件對(duì)象。實(shí)體類： 實(shí)體類是一個(gè)軟件對(duì)象，表示了領(lǐng)域?qū)ο蟮男畔?，以及具有與它所表示的信息有關(guān)的復(fù)雜行為邊界類僅負(fù)責(zé)數(shù)據(jù)的輸入和輸出，不應(yīng)承擔(dān)和數(shù)據(jù)處理有關(guān)的業(yè)務(wù)邏輯邊界類通過(guò)與實(shí)體類的交互，獲得有關(guān)數(shù)據(jù)處理的結(jié)果控制類：控制類代表協(xié)調(diào)、排序、事務(wù)處理以及對(duì)其他對(duì)象的控制，經(jīng)常用于封裝與某個(gè)具體用例有關(guān)的控制流第七章定義需求簡(jiǎn)述：這一章主要介紹了組成定義需求的活動(dòng)1、需求和架構(gòu)之間如何發(fā)生關(guān)系（關(guān)聯(lián)）？需求影響架構(gòu)。最明顯的關(guān)系是需求影響解決方案的架構(gòu)，因?yàn)榻鉀Q方案的元素是按照其是否能夠滿足規(guī)需求來(lái)挑選的。定義良好的需求導(dǎo)致高質(zhì)量的架構(gòu)。由于需求驅(qū)動(dòng)架構(gòu)的定義，因此，一組定義良好的需求比粗劣定義需求更能產(chǎn)生高質(zhì)量的架構(gòu)。讓架構(gòu)師參與某些特定的需求分析和需求定義的工作，憑他們的經(jīng)驗(yàn)，往往會(huì)得到質(zhì)量更高的需求。架構(gòu)的決定影響需求。在定義架構(gòu)時(shí)，架構(gòu)師經(jīng)常必須在不同的需求之間進(jìn)行取舍，如平衡性能和成本。結(jié)果，業(yè)務(wù)分析師會(huì)得到這些反饋，從而對(duì)需求進(jìn)行必要的調(diào)整。架構(gòu)中某些特定因素的選取也會(huì)約束可實(shí)現(xiàn)的需求。第三方商業(yè)系統(tǒng)的選擇，會(huì)對(duì)需求使用的術(shù)語(yǔ)、所提供的功能和獲得的質(zhì)量產(chǎn)生約束。架構(gòu)定義了子系統(tǒng)的需求。當(dāng)架構(gòu)被分解為各個(gè)部分時(shí)，需求和架構(gòu)之間還有另一種不那么明顯的關(guān)系。實(shí)際上，對(duì)架構(gòu)中某一部分的說(shuō)明已經(jīng)構(gòu)成了對(duì)那一部分的需求。2、一個(gè)元素出現(xiàn)什么情況，可以認(rèn)為對(duì)架構(gòu)的意義重大呢？這個(gè)元素與系統(tǒng)的關(guān)鍵功能相關(guān)，沒(méi)有它，你將無(wú)法得到可用的系統(tǒng)。這個(gè)元素與系統(tǒng)的關(guān)鍵質(zhì)量相關(guān)，例如性能，沒(méi)有它，你將無(wú)法得到可用的系統(tǒng)。這個(gè)元素與解決方案的重要約束相關(guān)，例如需要和特定的外部系統(tǒng)集成。這個(gè)元素能影響特定的技術(shù)風(fēng)險(xiǎn)。這個(gè)元素帶來(lái)特定的架構(gòu)挑戰(zhàn)。3、名詞解釋：功能性需求：描述了支持用戶目標(biāo)、任務(wù)和活動(dòng)的系統(tǒng)的行為（功能或者服務(wù)）。非功能性需求：包括性能需求、質(zhì)量屬性、對(duì)外接口和約束，約束是對(duì)再提供解決方案時(shí)所擁有的自由度的一個(gè)限制；質(zhì)量是利益相關(guān)者關(guān)心的系統(tǒng)特性和特點(diǎn)，因而影響系統(tǒng)的滿意度。業(yè)務(wù)規(guī)則：業(yè)務(wù)規(guī)則是定義或約束某一方面的聲明。其目的是維護(hù)業(yè)務(wù)結(jié)構(gòu)或控制及影響業(yè)務(wù)行為。4、質(zhì)量和質(zhì)量屬性的區(qū)別：軟件質(zhì)量是軟件擁有所要求的綜合屬性的程度。因此，要建立成功的軟件系統(tǒng)，系統(tǒng)必須滿足各種顯式及隱式的要求。系統(tǒng)為滿足顯式及隱式的要求而需要具備的要素稱為質(zhì)量。為了度量一個(gè)系統(tǒng)的質(zhì)量，人們通常會(huì)選用系統(tǒng)的某些質(zhì)量要素進(jìn)行量化處理，建立質(zhì)量特征，這些特征稱為質(zhì)量屬性。軟件質(zhì)量屬性包括功能性、可靠性、可用性、效率、可維護(hù)性、可移植性。性能、可擴(kuò)展性和可維護(hù)性都是質(zhì)量屬性的例子。5、在收集需求時(shí)通常會(huì)出現(xiàn)的缺陷有哪些？把要求當(dāng)做需求購(gòu)物車式的思維方式問(wèn)卷調(diào)查過(guò)于技術(shù)性要求過(guò)于籠統(tǒng)要求不可測(cè)量和不適當(dāng)?shù)娜擞懻?、在細(xì)化一個(gè)用例時(shí)，需要說(shuō)明的信息有哪些？名稱簡(jiǎn)要描述主要參與者次要參與者主要事件流可選事件流特殊需求先決條件后置條件7、細(xì)化非功能性需求場(chǎng)景有哪些組成部分？觸發(fā)、觸發(fā)源、觸發(fā)對(duì)象、環(huán)境、響應(yīng)、響應(yīng)度量、8、業(yè)務(wù)規(guī)則分類：為管理業(yè)務(wù)行為提供條件和規(guī)則為判斷一個(gè)行動(dòng)是否成功完成提供標(biāo)準(zhǔn)的規(guī)則規(guī)定一個(gè)行為成功或失敗后可以執(zhí)行什么或不能執(zhí)行什么的規(guī)則指定如何響應(yīng)對(duì)企業(yè)有影響的外部事件的規(guī)則管理各種業(yè)務(wù)實(shí)體之間的關(guān)系的規(guī)則9、本章重點(diǎn)：定義需求這項(xiàng)活動(dòng)的任務(wù)：收集利益相關(guān)者的要求（目的是收集各種利益相關(guān)者對(duì)系統(tǒng)的要求）（注意要求和需求的區(qū)別，要求是對(duì)利益相關(guān)者想要系統(tǒng)中有什么的一個(gè)表述）獲取常用詞匯定義系統(tǒng)上下文（目的是確保理解所要開(kāi)發(fā)系統(tǒng)的邊界范圍，同時(shí)還是別于系統(tǒng)交互的用戶和外部系統(tǒng)）概述功能性需求概述非功能性需求定義需求優(yōu)先級(jí)（目的是排定需求的優(yōu)先級(jí)以根據(jù)需求的優(yōu)先級(jí)來(lái)安排迭代）詳述功能性需求詳述非功能型需求更新軟件架構(gòu)文檔和利益相關(guān)者復(fù)審需求10、每個(gè)事件流的詳細(xì)描述中應(yīng)包括哪些信息？用例何時(shí)和如何發(fā)起用例何時(shí)與參與者交互并交互了哪些信息何時(shí)應(yīng)用了業(yè)務(wù)規(guī)則用例何時(shí)結(jié)束和如何結(jié)束11、需求定義產(chǎn)生的產(chǎn)品：術(shù)語(yǔ)表、利益相關(guān)者要求、系統(tǒng)上下文、功能性需求、非功能性需求和排定優(yōu)先級(jí)的需求列表第八章：創(chuàng)建邏輯架構(gòu)1、邏輯架構(gòu)和物理架構(gòu)的比較：邏輯架構(gòu)代表從需求通往解決方案的第一步——第一次主要從獨(dú)立于技術(shù)的角度考慮架構(gòu)。另一方面，物理架構(gòu)則更為具體——需考慮技術(shù)。2、什么是屬性驅(qū)動(dòng)設(shè)計(jì)：通過(guò)使用滿足質(zhì)量屬性場(chǎng)景的架構(gòu)策略和模式，質(zhì)量屬性用于驅(qū)動(dòng)架構(gòu)和設(shè)計(jì)的演化并用于接下來(lái)的各級(jí)分解中。3、什么是四門子的4重視圖方法：從整體分析影響架構(gòu)的因素開(kāi)始，反復(fù)地應(yīng)用4種視圖（概念、運(yùn)行、模塊、代碼架構(gòu)）來(lái)確認(rèn)架構(gòu)的關(guān)鍵挑戰(zhàn)和解決這些挑戰(zhàn)的策略。4、什么是統(tǒng)一過(guò)程：這個(gè)方法由對(duì)架構(gòu)有影響的用例、非功能性需求和風(fēng)險(xiǎn)來(lái)驅(qū)動(dòng)。在利用解決方案的關(guān)鍵架構(gòu)元素實(shí)現(xiàn)需求之前，每次迭代都考慮這些關(guān)鍵元素。5、策略：策略是決定如何滿足一個(gè)功能性需求或如何達(dá)到一個(gè)質(zhì)量屬性的決策。6、邏輯架構(gòu)的價(jià)值： （1）一種幫助盡可能快的把需求變?yōu)榭捎么a實(shí)現(xiàn)的物理架構(gòu)的簡(jiǎn)單有效方法。 （2）作為戰(zhàn)略性資源，當(dāng)需要更新系統(tǒng)時(shí)，邏輯架構(gòu)可以提供一個(gè)系統(tǒng)極好的抽象。7、可追溯性：可追溯性是用于把一個(gè)工作產(chǎn)品中的元素連接到相同或不同工作產(chǎn)品的元素的一種機(jī)制。8、創(chuàng)建邏輯架構(gòu)活動(dòng)的任務(wù)有哪些？ （1）調(diào)查架構(gòu)資源（2）定義架構(gòu)概覽（3）編寫架構(gòu)決策文檔（4）概述功能性元素 （5）概述部署元素（6）檢驗(yàn)架構(gòu)（7）構(gòu)建架構(gòu)概念證明（8）細(xì)化功能性元素（9）細(xì)化部署元素（10）確認(rèn)架構(gòu)（11）更新軟件架構(gòu)文檔（12）和利益相關(guān)人復(fù)審架構(gòu)組件的確認(rèn)是建立在對(duì)業(yè)務(wù)實(shí)體模型、功能需求、非功能需求、業(yè)務(wù)規(guī)則、現(xiàn)有IT環(huán)境和架構(gòu)決策等工作產(chǎn)品的分析之上的。9、組件質(zhì)量的度量軟件的內(nèi)聚性和耦合性質(zhì)量作為降低軟件維護(hù)和修改的成本的一個(gè)方法。內(nèi)聚性是組件的職責(zé)之間的相關(guān)程度的一個(gè)度量。耦合與內(nèi)聚有關(guān)，它表示組件之間關(guān)聯(lián)的強(qiáng)度。子系統(tǒng)與組件子系統(tǒng)是一組相關(guān)的組件。在業(yè)務(wù)系統(tǒng)中，組件通常被組合在一起，因?yàn)樗鼈冇泄餐С帜骋粯I(yè)務(wù)領(lǐng)域。組件是封裝自身的內(nèi)容并在環(huán)境中可替換的一個(gè)系統(tǒng)模塊化部分。一個(gè)組件根據(jù)提供和要求的接口來(lái)定義自己的行為。第九章創(chuàng)建物理架構(gòu)與物理架構(gòu)相關(guān)的任務(wù)可以開(kāi)始于起始階段的一個(gè)迭代。在細(xì)化階段，當(dāng)你專心于架構(gòu)系統(tǒng)的主要元素時(shí)，你會(huì)把這些任務(wù)作為重點(diǎn)，當(dāng)你進(jìn)入構(gòu)造階段的迭代是，物理架構(gòu)的任務(wù)逐漸減少，焦點(diǎn)轉(zhuǎn)向了根據(jù)目前定義的架構(gòu)完成系統(tǒng)的實(shí)現(xiàn)。影響物理架構(gòu)的主要因素之一是為處理非功能性需求（包括質(zhì)量和約束）2、軟件體系結(jié)構(gòu)的“4+1視圖”是指什么？是否每個(gè)軟件系統(tǒng)這5個(gè)視圖都需要？答：從5個(gè)不同的視角包括邏輯視角、過(guò)程視角、物理視角、開(kāi)發(fā)視角和場(chǎng)景視角來(lái)描述軟件體系結(jié)構(gòu)。每一個(gè)視角只關(guān)心系統(tǒng)的一個(gè)側(cè)面，5個(gè)視角結(jié)合在一起才能夠反映系統(tǒng)的軟件體系結(jié)構(gòu)的全部?jī)?nèi)容。并非每個(gè)系統(tǒng)都必須把5個(gè)視圖都畫出來(lái)，而是各有側(cè)重。1、典型的軟件構(gòu)架樣式（architecturalstyles）有哪些?答：o 以數(shù)據(jù)為中心的構(gòu)架 數(shù)據(jù)集成——一個(gè)集中式的數(shù)據(jù)集與多個(gè)客戶端進(jìn)行通信o 數(shù)據(jù)流構(gòu)架 成批數(shù)據(jù)流；管道和過(guò)濾器o 虛擬組織構(gòu)架 目標(biāo)：可移植性 模擬對(duì)象：模擬硬件不具備的功能或軟件環(huán)境 實(shí)例：java虛擬機(jī)(java的平臺(tái)獨(dú)立性)o 調(diào)用——返回構(gòu)架 目標(biāo)：可更改性和可擴(kuò)展性 主——子程序（傳統(tǒng)）；面向?qū)ο螅惻缮粚哟螛邮給 獨(dú)立組件構(gòu)架由獨(dú)立進(jìn)程或?qū)ο蠼M成，通過(guò)消息進(jìn)行通信例：C/S模式o 異質(zhì)構(gòu)架多種構(gòu)架樣式的綜合局部異質(zhì)/層次異質(zhì)/并行異質(zhì)（同時(shí)符合幾種樣式）3、簡(jiǎn)單區(qū)別軟件構(gòu)架分析方法SAAM與ATAM。答：涉及的質(zhì)量屬性：ATAM不面向任何具體的質(zhì)量屬性，但據(jù)其歷史，它更側(cè)重于可修改性，安全性，可靠性和性能；SAAM只要是可修改性和功能分析的對(duì)象：ATAM架構(gòu)方法或樣式，闡述過(guò)程、數(shù)據(jù)流、使用、物理或模塊試圖的架構(gòu)文檔；SAAM架構(gòu)文檔，特別是闡述邏輯或模塊視圖的部分試用階段：ATAM在架構(gòu)設(shè)計(jì)方法已經(jīng)選定之后；SAAM在架構(gòu)已經(jīng)將功能分配到各個(gè)模塊中以后采用方法：利用效用樹(shù)和對(duì)場(chǎng)景的集體討論來(lái)搞清楚質(zhì)量屬性需求。通過(guò)對(duì)架構(gòu)方法的分析確定出敏感點(diǎn)、權(quán)衡點(diǎn)和風(fēng)險(xiǎn)；SAAM利用對(duì)場(chǎng)景的集體討論搞清楚質(zhì)量屬性需求。通過(guò)來(lái)驗(yàn)證功能或?qū)Ω某杀咀龀龉烙?jì)資源需求：一般用3的時(shí)間，另外還有預(yù)先的準(zhǔn)備時(shí)間和之后的總結(jié)時(shí)間。參評(píng)人員有客戶、架構(gòu)師、風(fēng)險(xiǎn)承擔(dān)者和4人評(píng)估小組；SAAM一般用2天時(shí)間，另外還有之后的總結(jié)時(shí)間，參評(píng)人員有客戶、架構(gòu)師、風(fēng)險(xiǎn)承擔(dān)者和3人評(píng)估小組4.ATAM的一個(gè)方面是架構(gòu)評(píng)價(jià)，它遵循以下步驟：介紹ATAM。介紹業(yè)務(wù)驅(qū)動(dòng)因素。介紹架構(gòu)。確定架構(gòu)方法。生成質(zhì)量屬性效用樹(shù)。分析架構(gòu)方法。進(jìn)行頭腦風(fēng)暴并定義場(chǎng)景的優(yōu)先級(jí)。分析架構(gòu)場(chǎng)景。這個(gè)步驟等同于第6步，但是不考慮任何新場(chǎng)景。介紹結(jié)論5、理解軟件體系結(jié)構(gòu)（Softwarearchitecture）,框架（Framework）和設(shè)計(jì)模式（Designpatterns）3個(gè)概念理解軟件體系結(jié)構(gòu)：軟件體系結(jié)構(gòu)是具有一定形式的結(jié)構(gòu)化元素，即構(gòu)件的集合，包括處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件。處理構(gòu)件負(fù)責(zé)對(duì)數(shù)據(jù)進(jìn)行加工，數(shù)據(jù)構(gòu)件是被加工的信息，連接構(gòu)件把體系結(jié)構(gòu)的不同部分組組合連接起來(lái)。這一定義注重區(qū)分處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件，這一方法在其他的定義和方法中基本上得到保持。框架：框架是一種軟件重用技術(shù)，它是一個(gè)應(yīng)用軟件系統(tǒng)的部分或整體的可重用設(shè)計(jì)。應(yīng)用框架具有領(lǐng)域相關(guān)性，構(gòu)件根據(jù)框架進(jìn)行復(fù)合而生成可運(yùn)行的系統(tǒng)?？蚣芫唧w表現(xiàn)為一組抽象類以及其實(shí)例（對(duì)象）之間的相互作用方式?？蚣苁强杀粦?yīng)用開(kāi)發(fā)者定制的應(yīng)用骨架。框架是實(shí)現(xiàn)了某應(yīng)用領(lǐng)域通用完備功能（除去特殊應(yīng)用的部分）的底層服務(wù)。使用這種框架的編程人員可以在一個(gè)通用功能已經(jīng)實(shí)現(xiàn)的基礎(chǔ)上開(kāi)始具體的系統(tǒng)開(kāi)發(fā)。設(shè)計(jì)模式：設(shè)計(jì)模式(英語(yǔ)designpattern)是對(duì)面向?qū)ο笤O(shè)計(jì)中反復(fù)出現(xiàn)的問(wèn)題的解決方案。這個(gè)術(shù)語(yǔ)是在1990年代由ErichGamma等人從建筑設(shè)計(jì)領(lǐng)域引入到計(jì)算機(jī)科學(xué)中來(lái)的。這個(gè)術(shù)語(yǔ)的含義目前還存有爭(zhēng)議。算法不是設(shè)計(jì)模式，因?yàn)樗惴ㄖ铝τ诮鉀Q問(wèn)題而非設(shè)計(jì)問(wèn)題。設(shè)計(jì)模式通常描述了一組相互緊密作用的類與對(duì)象。設(shè)計(jì)模式提供一種討論軟件設(shè)計(jì)的公共語(yǔ)言，使得熟練設(shè)計(jì)者的設(shè)計(jì)經(jīng)驗(yàn)可以被初學(xué)者和其他設(shè)計(jì)者掌握。設(shè)計(jì)模式還為軟件重構(gòu)提供了目標(biāo)。6、了解C/S與B/S混合軟件架構(gòu)及其優(yōu)缺點(diǎn)o C/S與B/S混合軟件體系結(jié)構(gòu)的優(yōu)點(diǎn)是外部用戶不直接訪問(wèn)數(shù)據(jù)庫(kù)服務(wù)器，能保證企業(yè)數(shù)據(jù)庫(kù)的相對(duì)安全。企業(yè)內(nèi)部用戶的交互性較強(qiáng)，數(shù)據(jù)查詢和修改的響應(yīng)速度較快。o C/S與B/S混合軟件體系結(jié)構(gòu)的缺點(diǎn)是企業(yè)外部用戶修改和維護(hù)數(shù)據(jù)時(shí)，速度較慢，較煩瑣，數(shù)據(jù)的動(dòng)態(tài)交互性不強(qiáng)。7、理解面向?qū)ο笤O(shè)計(jì)的“開(kāi)—閉”原則答：“開(kāi)—閉”原則是指軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展性開(kāi)放，對(duì)修改關(guān)閉。即軟件實(shí)體應(yīng)該在不修改的前提下擴(kuò)展，這個(gè)原則實(shí)際上為軟件設(shè)計(jì)指明了目標(biāo)。我們知道軟件設(shè)計(jì)應(yīng)當(dāng)充分考慮軟件的可維護(hù)性，即需求發(fā)生變化的時(shí)候軟件結(jié)構(gòu)能夠靈活地適應(yīng)這種變化。就評(píng)價(jià)軟件的可維護(hù)性而言，“開(kāi)—閉”原則提供了一個(gè)依據(jù)。實(shí)際上，設(shè)計(jì)模式的應(yīng)用就是使軟件的結(jié)構(gòu)在某種程度上滿足“開(kāi)—閉”原則。8. 需要確定構(gòu)架驅(qū)動(dòng)因素。構(gòu)架驅(qū)動(dòng)因素：功能，質(zhì)量，商業(yè)需求的某個(gè)集合“塑造”了架構(gòu)，我們把這些塑造架構(gòu)的需求稱為架構(gòu)的驅(qū)動(dòng)因素。9、如何確定架構(gòu)驅(qū)動(dòng)因素？1） 需要識(shí)別優(yōu)先級(jí)最高的業(yè)務(wù)目標(biāo)，這樣的業(yè)務(wù)目標(biāo)應(yīng)該很少，用質(zhì)量屬性場(chǎng)景或用例來(lái)表述這些企業(yè)目標(biāo)。2） 在需求中，選擇對(duì)構(gòu)架影響最大的需求，這些就是構(gòu)架的驅(qū)動(dòng)因素，應(yīng)該少于10個(gè)。10、ADD(AttributesDrivenDesign),把一組質(zhì)量屬性場(chǎng)景作為輸入，并使用對(duì)質(zhì)量屬性實(shí)現(xiàn)和構(gòu)架之間的關(guān)系的了解，對(duì)構(gòu)架進(jìn)行設(shè)計(jì)，以滿足質(zhì)量需求和功能需求?！顰DD（屬性驅(qū)動(dòng)設(shè)計(jì)）ADD使用大致過(guò)程：ADD是一種定義軟件架構(gòu)的方法，該方法將分解過(guò)程建立在軟件必須滿足的質(zhì)量屬性之上，