當(dāng)不適合采用生成子類的方法對已有的類進行擴充時，可以采用（1）設(shè)計模式動態(tài)地給一個對象添加一些額外的職責(zé)；當(dāng)應(yīng)用程序由于使用大量的對象，造成很大的存儲開銷時，可以采用（2）設(shè)計模式運用共享技術(shù)來有效地支持大量細(xì)粒度的對象；當(dāng)想使用一個已經(jīng)存在的類，但其接口不符合需求時，可以采用（3）設(shè)計模式將該類的接口轉(zhuǎn)換成我們希望的接口。
空白（1）處應(yīng)選擇（）
A.命令（CommanD）
B.適配器（Adapter）
C.裝飾（DecoratE）
D.享元（Flyweight）
您可能感興趣的試卷
- 2009年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計師下半年上午試卷
- 2009年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計師下半年下午試卷
- 2010年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計師下半年上午試卷
- 2011年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計師下半年上午試卷
- 2012年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計師下半年上午試卷
- 2013年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計師下半年上午試卷
- 2014年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計師下半年上午試卷
你可能感興趣的試題
如圖8-40（a）所示的UML類圖描繪的是設(shè)計模式中的（1）模式。如圖8-40（b）所示的UML類圖描述了該模式的一種應(yīng)用，其中與圖8-40（a）中的"Creator"對應(yīng)的類是（2）。
A.Bank
B.Account
C.Checking
D.Savings
如圖8-40（a）所示的UML類圖描繪的是設(shè)計模式中的（1）模式。如圖8-40（b）所示的UML類圖描述了該模式的一種應(yīng)用，其中與圖8-40（a）中的"Creator"對應(yīng)的類是（2）。
A.Command
B.Factory Method
C.Composite
D.Class Adapter
回調(diào)（Call Back）函數(shù)是面向過程的程序設(shè)計語言中常用的一種機制，而設(shè)計模式中的（1）模式就是回調(diào)機制的一個面向?qū)ο蟮奶娲?。該模式的意圖是（2）。
空白（2）處應(yīng)選擇（）
A.使原本由于接口不兼容而不能一起工作的那些類可以一起工作
B.將一個請求封裝為一個對象，從而可用不同的請求對客戶進行參數(shù)化，將請求排隊或記錄請求日志，支持可撤銷的操作
C.定義對象間的一種一對多的依賴關(guān)系，當(dāng)一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知并被自動更新
D.使算法可獨立于使用它的客戶而變化
回調(diào)（Call Back）函數(shù)是面向過程的程序設(shè)計語言中常用的一種機制，而設(shè)計模式中的（1）模式就是回調(diào)機制的一個面向?qū)ο蟮奶娲?。該模式的意圖是（2）。
空白（1）處應(yīng)選擇（）
A.Strategy（策略）
B.Adapter（適配器）
C.Command（命令）
D.Observer（觀察者）
基于場景的架構(gòu)分析方法（Scenarios-basedArchitectureAnalysisMethod，SAAM）是卡耐基梅隆大學(xué)軟件工程研究所的Kazman等人于1983年提出的一種非功能質(zhì)量屬性的架構(gòu)分析方法，是最早形成文檔并得到廣泛應(yīng)用的軟件架構(gòu)分析方法。SAAM的主要輸入是問題描述、（1）和架構(gòu)描述文檔，其分析過程主要包括場景開發(fā)、（2）、單個場景評估、場景交互和總體評估。
空白（2）處應(yīng)選擇（）
A.架構(gòu)需求
B.架構(gòu)描述
C.架構(gòu)設(shè)計
D.架構(gòu)實現(xiàn)
基于場景的架構(gòu)分析方法（Scenarios-basedArchitectureAnalysisMethod，SAAM）是卡耐基梅隆大學(xué)軟件工程研究所的Kazman等人于1983年提出的一種非功能質(zhì)量屬性的架構(gòu)分析方法，是最早形成文檔并得到廣泛應(yīng)用的軟件架構(gòu)分析方法。SAAM的主要輸入是問題描述、（1）和架構(gòu)描述文檔，其分析過程主要包括場景開發(fā)、（2）、單個場景評估、場景交互和總體評估。
空白（1）處應(yīng)選擇（）
A.問題說明
B.問題建模
C.需求說明
D.需求建模
A.架構(gòu)需求
B.架構(gòu)屬性
C.架構(gòu)優(yōu)先級
D.架構(gòu)約束
采用以架構(gòu)為核心的軟件開發(fā)方法，在建立軟件架構(gòu)的初期，首要任務(wù)是選擇一個合適的（1），在此基礎(chǔ)上，開發(fā)人員通過架構(gòu)模型，可以獲得關(guān)于（2）的理解，為將來的架構(gòu)實現(xiàn)與演化過程建立了目標(biāo)。
空白（1）處應(yīng)選擇（）
A.分析模式
B.設(shè)計模式
C.架構(gòu)風(fēng)格
D.架構(gòu)標(biāo)準(zhǔn)
A.敏感點
B.風(fēng)險點
C.非風(fēng)險點
D.權(quán)衡點
識別風(fēng)險點、非風(fēng)險點、敏感點和權(quán)衡點是軟件架構(gòu)評估過程中的關(guān)鍵步驟。針對某系統(tǒng)所作的架構(gòu)設(shè)計中，“系統(tǒng)需要支持的最大并發(fā)用戶數(shù)量直接影響傳輸協(xié)議和數(shù)據(jù)格式”描述了系統(tǒng)架構(gòu)設(shè)計中的一個（1）：“由于系統(tǒng)的業(yè)務(wù)邏輯目前尚不清楚，因此現(xiàn)有系統(tǒng)三層架構(gòu)中的第2層可能會出現(xiàn)功能重復(fù)，這會影響系統(tǒng)的可修改性”描述了系統(tǒng)架構(gòu)設(shè)計中的一個（2）。
空白（1）處應(yīng)選擇（）
A.敏感點
B.風(fēng)險點
C.非風(fēng)險點
D.權(quán)衡點
最新試題
如果兩個模塊之間是語義依賴，則可以插入一個仲裁者來降低它們之間的依賴程度。
軟件構(gòu)架評估的主要目的是控制風(fēng)險，ATAM是一個結(jié)構(gòu)化的軟件構(gòu)架評估方法。
構(gòu)架并不能獨立實質(zhì)量屬性，它為質(zhì)量屬性的實現(xiàn)提供了基礎(chǔ)。
采用恰當(dāng)?shù)捏w系結(jié)構(gòu)是項目成功的第一步，體系結(jié)構(gòu)不當(dāng)，將可能會導(dǎo)致災(zāi)難性的損失。
David Garlan對軟件體系結(jié)構(gòu)的定義可以精簡為體系結(jié)構(gòu)=組件+連接件+約束。
數(shù)據(jù)流風(fēng)格的構(gòu)架不但關(guān)心數(shù)據(jù)怎樣在運算單元之間流動，同時也關(guān)心控制點怎樣在程序或系統(tǒng)之間移動。
和Pipe-and-Filter構(gòu)架相比，解釋器構(gòu)架提供更好的重用支持，并使得整個系統(tǒng)易于維護和增強。
使用質(zhì)量屬性場景的概念主要是為了使質(zhì)量屬性更清楚、能操作度量。
通過對軟件構(gòu)架的評估，可以預(yù)測軟件系統(tǒng)的質(zhì)量。
軟件體系結(jié)構(gòu)只是表示了軟件的拓?fù)浣Y(jié)構(gòu)，不關(guān)心其動態(tài)結(jié)構(gòu)。