軟件體系結(jié)構(gòu)考試要點-資料下載頁
2025-06-25 00:18本頁面
【正文】 何產(chǎn)生的，消息的發(fā)出者和接收者不必知道彼此的情況。這使得構(gòu)件之間的耦合度低，構(gòu)件重用性好，構(gòu)件的更換更容易。在一般的互聯(lián)接口定義的系統(tǒng)中，構(gòu)件之間的連接是在要求的服務和提供的服務之間進行固定的匹配，而在HMB中，構(gòu)件對外來消息進行響應后，可能會引起狀態(tài)的變遷。因此，一個構(gòu)件在收到同樣的消息后，在不同時刻所處的不同狀態(tài)下，可能會有不同的響應。請根據(jù)P147圖52介紹體系結(jié)構(gòu)設計方法的元模型。答：元模型是對各種體系結(jié)構(gòu)設計模型的抽象。圖中用圓角矩形表示概念，用連線表示概念之間的關(guān)聯(lián)，用菱形符號表示3~4個概念之間的關(guān)聯(lián)。客戶：表示那些關(guān)心體系結(jié)構(gòu)設計的系統(tǒng)相關(guān)人員；需求規(guī)格說明：描述了所要開發(fā)的體系結(jié)構(gòu)的系統(tǒng)需求；制品：表示某一方法的制品描述；解決方案抽象：定義了子結(jié)構(gòu)的概念表示；體系結(jié)構(gòu)描述：定義了體系結(jié)構(gòu)的規(guī)格說明；領(lǐng)域知識：用于表示在解決某一問題中所用的知識范圍；請根據(jù)P167圖61簡要介紹基于體系結(jié)構(gòu)的軟件開發(fā)過程的各個步驟。并說明各個步驟的必要性何在？或者說，它們在軟件生命周期中都起到了什么作用？本過程由以下步驟組成：（1）導出體系結(jié)構(gòu)需求：體系結(jié)構(gòu)需求由開發(fā)組織創(chuàng)建，并受技術(shù)環(huán)境和體系結(jié)構(gòu)設計師個人經(jīng)驗的影響。該步驟的輸出有3個：列舉功能需求；列舉特定體系結(jié)構(gòu)需求；列舉質(zhì)量場景集合，它為體系結(jié)構(gòu)需求提供具體測試；（2）設計體系結(jié)構(gòu)：一個體系結(jié)構(gòu)設計師在開發(fā)體系結(jié)構(gòu)時，先做出一些設計決定，然后通過考慮不同的體系結(jié)構(gòu)構(gòu)造和視圖來對這些設計決定進行分析。體系結(jié)構(gòu)設計是一個迭代的過程，首先做出某些決策并進行分析，然后重新考慮并重新作決定，直到設計達到封閉；（3）文檔化體系結(jié)構(gòu)：體系結(jié)構(gòu)的文檔是為支持程序設計人員和分析人員而設計的。它是加深各種系統(tǒng)相關(guān)人員之間通信交流程度的有效工具，并能從中導出體系結(jié)構(gòu)需求。創(chuàng)建并維護體系結(jié)構(gòu)文檔是長期性的軟件體系結(jié)構(gòu)取得成功的關(guān)鍵因素之一；（4）分析體系結(jié)構(gòu)：確定潛在的風險，驗證所給出的設計能夠處理所提出的質(zhì)量需求，之所以要求外部評估人員的參與，是為了確保能夠毫無偏見地進行檢查，并保證評估結(jié)果的可信性；（5）實現(xiàn)體系結(jié)構(gòu)：當把一個體系結(jié)構(gòu)轉(zhuǎn)變成代碼，要考慮到各種常用的軟件工程和項目管理知識：詳細設計、編碼實現(xiàn)、測試、配置管理等；（6）維護體系結(jié)構(gòu)：對于體系結(jié)構(gòu)來說，良好的文檔、良好的發(fā)布和良好的維護都非常重要。如果缺少任何一方面的活動，那么體系結(jié)構(gòu)將不可避免地偏離其初始原則；請根據(jù)P185圖71對SAAM的各個步驟進行較詳細的介紹。P184步驟：（1）場景開發(fā)：場景生成是各種涉眾參與討論和頭腦風暴的過程。每個參與者都有自己的視角，并提供基于此的場景。此階段可能會迭代進行好幾次。場景開發(fā)與體系結(jié)構(gòu)描述是相互關(guān)聯(lián)、相互驅(qū)動的。（2）描述體系結(jié)構(gòu)：體系結(jié)構(gòu)文檔包括了需要評估的信息，為了更好地進行評估，體系結(jié)構(gòu)描述應該以一種參與者都能接受的形式表達，對構(gòu)件、連接件、模塊、配置、依賴、部署等概念要去分清楚。（3）對場景分類和設置優(yōu)先級：SAAM中的場景分為兩類：直接場景和間接場景。直接場景是指當前體系結(jié)構(gòu)不經(jīng)修改即可支持的場景。間接場景不能直接被當前體系結(jié)構(gòu)支持。由于時間和資源有限，就需要通過設置優(yōu)先級的方法來選擇最關(guān)鍵的場景。CMU SEI建議以涉眾范圍內(nèi)投票的方式?jīng)Q定哪些是“關(guān)鍵”的。（4）間接場景的獨立評估：對于每個候選體系結(jié)構(gòu)，都要評估一下在每個間接場景下的表現(xiàn)。在此，體系結(jié)構(gòu)的元素被映射到具體的質(zhì)量屬性。間接場景都要求改動當前體系結(jié)構(gòu)。（5）識別場景關(guān)聯(lián)：如果不同的場景都要求對同一個體系結(jié)構(gòu)元素進行修改，則稱這些場景關(guān)聯(lián)于此元素。場景關(guān)聯(lián)的程度高意味著功能分解不良。場景關(guān)聯(lián)可能是災難的種子，因為將來系統(tǒng)演化的時候該關(guān)聯(lián)會導致混亂的修改。（6）形成整體評估：SAAM的最后一步是形成總結(jié)報告。如果候選體系結(jié)構(gòu)只有一個，那么總體評估要做的就是審查前面步驟的結(jié)果并總結(jié)成報告。修改計劃將基于此報告。請根據(jù)P207圖81分析服務提供者、服務請求者和服務注冊中心三者的作用，以及它們之間的工作流程。答：作用：（1）服務提供者：發(fā)布自己的服務，并且對服務請求進行響應。（2）服務注冊中心：注冊已發(fā)布的WebServices，對其進行分類，并提供搜索服務。（3）服務請求者：利用服務注冊中心查找所需的服務，然后使用該服務。這些角色之間使用三種操作：（1）發(fā)布操作：使服務提供者可以向服務注冊中心注冊自己的功能及訪問接口。（2）查找操作：使服務請求者可以通過服務注冊中心查找特定種類的服務。（3）綁定操作：使服務請求者能夠真正使用服務提供者提供的服務。請根據(jù)P229圖811介紹UDDI的具體工作步驟。答：（1）軟件公司、標準化組織和程序員定義了企業(yè)如何在UDDI中注冊的規(guī)劃后，開始向UDDI注冊中心發(fā)布這些規(guī)則的描述信息。這些規(guī)則被稱為技術(shù)模型；（2）企業(yè)向UDDI注冊中心注冊關(guān)于該企業(yè)及其提供的WebServices的描述；（3）UDDI注冊中心會給每個實體指定一個在相關(guān)程序中唯一的標識符，從而可以隨時了解所有這些實體的當前情況；（4）電子交易場所和搜索引擎等其他類型的客戶和商務應用程序使用UDDI注冊中心來發(fā)現(xiàn)他們感興趣的WebServices；（5）其他的企業(yè)就可以調(diào)用這些服務，方便、迅速地進行商務應用程序的動態(tài)集成；
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1