某軟件公司欲開發(fā)一個(gè)Windows平臺上的公告板系統(tǒng)。在明確用戶需求后，該公司的架構(gòu)師決定采用Command模式實(shí)現(xiàn)該系統(tǒng)的界面顯示部分，并設(shè)計(jì)UML類圖，如圖8-41所示。圖中與Command模式中的"Invoker"角色相對應(yīng)的類是（1），與"ConcreteCommand"角色相對應(yīng)的類是（2）。
空白（2）處應(yīng)選擇（）
A.Command
B.Menultem
C.Open
D.BulktinBoardScreen
您可能感興趣的試卷
- 2009年計(jì)算機(jī)技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計(jì)師下半年上午試卷
- 2009年計(jì)算機(jī)技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計(jì)師下半年下午試卷
- 2010年計(jì)算機(jī)技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計(jì)師下半年上午試卷
- 2011年計(jì)算機(jī)技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計(jì)師下半年上午試卷
- 2012年計(jì)算機(jī)技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計(jì)師下半年上午試卷
- 2013年計(jì)算機(jī)技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計(jì)師下半年上午試卷
- 2014年計(jì)算機(jī)技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設(shè)計(jì)師下半年上午試卷
你可能感興趣的試題
某軟件公司欲開發(fā)一個(gè)Windows平臺上的公告板系統(tǒng)。在明確用戶需求后，該公司的架構(gòu)師決定采用Command模式實(shí)現(xiàn)該系統(tǒng)的界面顯示部分，并設(shè)計(jì)UML類圖，如圖8-41所示。圖中與Command模式中的"Invoker"角色相對應(yīng)的類是（1），與"ConcreteCommand"角色相對應(yīng)的類是（2）。
A.Command
B.Menultem
C.Open
D.ButktinBoardScreen
A.命令（CommanD）
B.適配器（Adapter）
C.裝飾（DecoratE）
D.享元（Flyweight）
當(dāng)不適合采用生成子類的方法對已有的類進(jìn)行擴(kuò)充時(shí)，可以采用（1）設(shè)計(jì)模式動態(tài)地給一個(gè)對象添加一些額外的職責(zé)；當(dāng)應(yīng)用程序由于使用大量的對象，造成很大的存儲開銷時(shí)，可以采用（2）設(shè)計(jì)模式運(yùn)用共享技術(shù)來有效地支持大量細(xì)粒度的對象；當(dāng)想使用一個(gè)已經(jīng)存在的類，但其接口不符合需求時(shí)，可以采用（3）設(shè)計(jì)模式將該類的接口轉(zhuǎn)換成我們希望的接口。
空白（2）處應(yīng)選擇（）
A.命令（CommanD）
B.適配器（Adapter）
C.裝飾（DecoratE）
D.享元（Flyweight）
當(dāng)不適合采用生成子類的方法對已有的類進(jìn)行擴(kuò)充時(shí)，可以采用（1）設(shè)計(jì)模式動態(tài)地給一個(gè)對象添加一些額外的職責(zé)；當(dāng)應(yīng)用程序由于使用大量的對象，造成很大的存儲開銷時(shí)，可以采用（2）設(shè)計(jì)模式運(yùn)用共享技術(shù)來有效地支持大量細(xì)粒度的對象；當(dāng)想使用一個(gè)已經(jīng)存在的類，但其接口不符合需求時(shí)，可以采用（3）設(shè)計(jì)模式將該類的接口轉(zhuǎn)換成我們希望的接口。
空白（1）處應(yīng)選擇（）
A.命令（CommanD）
B.適配器（Adapter）
C.裝飾（DecoratE）
D.享元（Flyweight）
如圖8-40（a）所示的UML類圖描繪的是設(shè)計(jì)模式中的（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è)計(jì)模式中的（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è)計(jì)語言中常用的一種機(jī)制，而設(shè)計(jì)模式中的（1）模式就是回調(diào)機(jī)制的一個(gè)面向?qū)ο蟮奶娲?。該模式的意圖是（2）。
空白（2）處應(yīng)選擇（）
A.使原本由于接口不兼容而不能一起工作的那些類可以一起工作
B.將一個(gè)請求封裝為一個(gè)對象，從而可用不同的請求對客戶進(jìn)行參數(shù)化，將請求排隊(duì)或記錄請求日志，支持可撤銷的操作
C.定義對象間的一種一對多的依賴關(guān)系，當(dāng)一個(gè)對象的狀態(tài)發(fā)生改變時(shí)，所有依賴于它的對象都得到通知并被自動更新
D.使算法可獨(dú)立于使用它的客戶而變化
回調(diào)（Call Back）函數(shù)是面向過程的程序設(shè)計(jì)語言中常用的一種機(jī)制，而設(shè)計(jì)模式中的（1）模式就是回調(diào)機(jī)制的一個(gè)面向?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）、單個(gè)場景評估、場景交互和總體評估。
空白（2）處應(yīng)選擇（）
A.架構(gòu)需求
B.架構(gòu)描述
C.架構(gòu)設(shè)計(jì)
D.架構(gòu)實(shí)現(xiàn)
基于場景的架構(gòu)分析方法（Scenarios-basedArchitectureAnalysisMethod，SAAM）是卡耐基梅隆大學(xué)軟件工程研究所的Kazman等人于1983年提出的一種非功能質(zhì)量屬性的架構(gòu)分析方法，是最早形成文檔并得到廣泛應(yīng)用的軟件架構(gòu)分析方法。SAAM的主要輸入是問題描述、（1）和架構(gòu)描述文檔，其分析過程主要包括場景開發(fā)、（2）、單個(gè)場景評估、場景交互和總體評估。
空白（1）處應(yīng)選擇（）
A.問題說明
B.問題建模
C.需求說明
D.需求建模
最新試題
易用性關(guān)注的是對用戶來說完成某個(gè)期望任務(wù)的容易程度。
效用樹的作用是使質(zhì)量屬性需求具體化，從而迫使設(shè)計(jì)師和客戶代表準(zhǔn)確地定義出他們將要提供的相關(guān)質(zhì)量需求。
好的構(gòu)架設(shè)計(jì)是一系列相容的原理和技術(shù)的產(chǎn)物，在項(xiàng)目的各個(gè)階段保持一致。
動態(tài)優(yōu)先調(diào)度策略包括（）
CBAM不是使用一個(gè)單獨(dú)的場景，是通過改變響應(yīng)值對某一質(zhì)量屬性生成一組場景，每個(gè)場景又對應(yīng)一個(gè)效用。
推遲綁定時(shí)間是提高系統(tǒng)運(yùn)行時(shí)的可修改性的一種戰(zhàn)術(shù)。
采用恰當(dāng)?shù)捏w系結(jié)構(gòu)是項(xiàng)目成功的第一步，體系結(jié)構(gòu)不當(dāng)，將可能會導(dǎo)致災(zāi)難性的損失。
安全性是衡量系統(tǒng)在向合法用戶提供服務(wù)的同時(shí)，阻止非授權(quán)使用的能力。
軟件體系結(jié)構(gòu)只是表示了軟件的拓?fù)浣Y(jié)構(gòu)，不關(guān)心其動態(tài)結(jié)構(gòu)。
構(gòu)架并不能獨(dú)立實(shí)質(zhì)量屬性，它為質(zhì)量屬性的實(shí)現(xiàn)提供了基礎(chǔ)。