某軟件公司欲開發(fā)一個Windows平臺上的公告板系統(tǒng)。在明確用戶需求后，該公司的架構師決定采用Command模式實現(xiàn)該系統(tǒng)的界面顯示部分，并設計UML類圖，如圖8-41所示。圖中與Command模式中的"Invoker"角色相對應的類是（1），與"ConcreteCommand"角色相對應的類是（2）。
A.Command
B.Menultem
C.Open
D.ButktinBoardScreen
您可能感興趣的試卷
- 2009年計算機技術與軟件專業(yè)技術資格高級系統(tǒng)架構設計師下半年上午試卷
- 2009年計算機技術與軟件專業(yè)技術資格高級系統(tǒng)架構設計師下半年下午試卷
- 2010年計算機技術與軟件專業(yè)技術資格高級系統(tǒng)架構設計師下半年上午試卷
- 2011年計算機技術與軟件專業(yè)技術資格高級系統(tǒng)架構設計師下半年上午試卷
- 2012年計算機技術與軟件專業(yè)技術資格高級系統(tǒng)架構設計師下半年上午試卷
- 2013年計算機技術與軟件專業(yè)技術資格高級系統(tǒng)架構設計師下半年上午試卷
- 2014年計算機技術與軟件專業(yè)技術資格高級系統(tǒng)架構設計師下半年上午試卷
你可能感興趣的試題
A.命令（CommanD）
B.適配器（Adapter）
C.裝飾（DecoratE）
D.享元（Flyweight）
當不適合采用生成子類的方法對已有的類進行擴充時，可以采用（1）設計模式動態(tài)地給一個對象添加一些額外的職責；當應用程序由于使用大量的對象，造成很大的存儲開銷時，可以采用（2）設計模式運用共享技術來有效地支持大量細粒度的對象；當想使用一個已經(jīng)存在的類，但其接口不符合需求時，可以采用（3）設計模式將該類的接口轉(zhuǎn)換成我們希望的接口。
空白（2）處應選擇（）
A.命令（CommanD）
B.適配器（Adapter）
C.裝飾（DecoratE）
D.享元（Flyweight）
當不適合采用生成子類的方法對已有的類進行擴充時，可以采用（1）設計模式動態(tài)地給一個對象添加一些額外的職責；當應用程序由于使用大量的對象，造成很大的存儲開銷時，可以采用（2）設計模式運用共享技術來有效地支持大量細粒度的對象；當想使用一個已經(jīng)存在的類，但其接口不符合需求時，可以采用（3）設計模式將該類的接口轉(zhuǎn)換成我們希望的接口。
空白（1）處應選擇（）
A.命令（CommanD）
B.適配器（Adapter）
C.裝飾（DecoratE）
D.享元（Flyweight）
如圖8-40（a）所示的UML類圖描繪的是設計模式中的（1）模式。如圖8-40（b）所示的UML類圖描述了該模式的一種應用，其中與圖8-40（a）中的"Creator"對應的類是（2）。
A.Bank
B.Account
C.Checking
D.Savings
如圖8-40（a）所示的UML類圖描繪的是設計模式中的（1）模式。如圖8-40（b）所示的UML類圖描述了該模式的一種應用，其中與圖8-40（a）中的"Creator"對應的類是（2）。
A.Command
B.Factory Method
C.Composite
D.Class Adapter
回調(diào)（Call Back）函數(shù)是面向過程的程序設計語言中常用的一種機制，而設計模式中的（1）模式就是回調(diào)機制的一個面向?qū)ο蟮奶娲?。該模式的意圖是（2）。
空白（2）處應選擇（）
A.使原本由于接口不兼容而不能一起工作的那些類可以一起工作
B.將一個請求封裝為一個對象，從而可用不同的請求對客戶進行參數(shù)化，將請求排隊或記錄請求日志，支持可撤銷的操作
C.定義對象間的一種一對多的依賴關系，當一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知并被自動更新
D.使算法可獨立于使用它的客戶而變化
回調(diào)（Call Back）函數(shù)是面向過程的程序設計語言中常用的一種機制，而設計模式中的（1）模式就是回調(diào)機制的一個面向?qū)ο蟮奶娲?。該模式的意圖是（2）。
空白（1）處應選擇（）
A.Strategy（策略）
B.Adapter（適配器）
C.Command（命令）
D.Observer（觀察者）
基于場景的架構分析方法（Scenarios-basedArchitectureAnalysisMethod，SAAM）是卡耐基梅隆大學軟件工程研究所的Kazman等人于1983年提出的一種非功能質(zhì)量屬性的架構分析方法，是最早形成文檔并得到廣泛應用的軟件架構分析方法。SAAM的主要輸入是問題描述、（1）和架構描述文檔，其分析過程主要包括場景開發(fā)、（2）、單個場景評估、場景交互和總體評估。
空白（2）處應選擇（）
A.架構需求
B.架構描述
C.架構設計
D.架構實現(xiàn)
基于場景的架構分析方法（Scenarios-basedArchitectureAnalysisMethod，SAAM）是卡耐基梅隆大學軟件工程研究所的Kazman等人于1983年提出的一種非功能質(zhì)量屬性的架構分析方法，是最早形成文檔并得到廣泛應用的軟件架構分析方法。SAAM的主要輸入是問題描述、（1）和架構描述文檔，其分析過程主要包括場景開發(fā)、（2）、單個場景評估、場景交互和總體評估。
空白（1）處應選擇（）
A.問題說明
B.問題建模
C.需求說明
D.需求建模
A.架構需求
B.架構屬性
C.架構優(yōu)先級
D.架構約束
最新試題
通過對軟件構架的評估，可以預測軟件系統(tǒng)的質(zhì)量。
安全性是衡量系統(tǒng)在向合法用戶提供服務的同時，阻止非授權使用的能力。
軟件體系結構只是表示了軟件的拓撲結構，不關心其動態(tài)結構。
安全性質(zhì)量屬性場景的環(huán)境包括在線或離線、直接或通過防火墻入網(wǎng)。
黑板構架用于解決無確定性求解策略問題，它由黑板、知識源和仲裁者構成。
限制隊列大小是一個提高系統(tǒng)性能的戰(zhàn)術。
一個界面美觀、容易學習的系統(tǒng)是用戶評估易用性重要方面，因此構架設計對此質(zhì)量屬性幫助不大。
使用質(zhì)量屬性場景的概念主要是為了使質(zhì)量屬性更清楚、能操作度量。
易用性關注的是對用戶來說完成某個期望任務的容易程度。
軟件體系結構的設計的好壞對于軟件的易用性沒有影響。