A.架構(gòu)文檔應該從架構(gòu)設計者的角度進行編寫
B.應該保持架構(gòu)文檔的即時更新，但更新不要過于頻繁
C.架構(gòu)文檔中的描述應該盡量避免不必要的重復
D.每次架構(gòu)文檔修改，都應該記錄修改的原則
您可能感興趣的試卷
- 2009年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設計師下半年上午試卷
- 2009年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設計師下半年下午試卷
- 2010年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設計師下半年上午試卷
- 2011年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設計師下半年上午試卷
- 2012年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設計師下半年上午試卷
- 2013年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設計師下半年上午試卷
- 2014年計算機技術(shù)與軟件專業(yè)技術(shù)資格高級系統(tǒng)架構(gòu)設計師下半年上午試卷
你可能感興趣的試題
A.使用ABSD方法，設計活動可以從項目總體功能框架明確就開始
B.ABSD方法是一個自頂向下，遞歸細化的過程
C.ABSD方法有3個基礎：功能分解、選擇架構(gòu)風格實現(xiàn)質(zhì)量和商業(yè)需求及軟件模板的使用
D.使用ABSD方法，設計活動的開始意味著需求抽取和分析活動可以終止
A.設計構(gòu)件
B.需求獲取
C.標識構(gòu)件
D.架構(gòu)需求評審
A.架構(gòu)設計能夠滿足系統(tǒng)的性能、可維護性等品質(zhì)
B.良好的架構(gòu)設計能夠更好地捕獲并了解用戶需求
C.架構(gòu)設計能夠使得不同的利益相關(guān)人（Stakeholders）達成一致的目標
D.架構(gòu)設計能夠支持項目計劃和項目管理等活動
A.需求分析與設計
B.設計與實現(xiàn)
C.實現(xiàn)與測試
D.部署與變更
A.服務器、客戶端及其物理位置
B.處理器說明信息
C.單位時間的數(shù)據(jù)流大小
D.傳輸協(xié)議
A.靜態(tài)IDLSkeletons
B.POA
C.靜態(tài)IDL Stubs
D.動態(tài)Skeletons
A.JavaEE定義了分布式環(huán)境中多層應用系統(tǒng)的架構(gòu)，是多種Java技術(shù)的混合體
B.具有典型的3層結(jié)構(gòu)：表現(xiàn)層、業(yè)務邏輯層和基礎設施層
C.不同的應用系統(tǒng)對底層支持系統(tǒng)的要求可能不同，因此每次開發(fā)時應該針對不同的應用需求對底層系統(tǒng)進行二次開發(fā)，提供支持接口
D.要嚴格區(qū)分業(yè)務邏輯層和表現(xiàn)層，尤其應該注意不要在表現(xiàn)層中混雜業(yè)務代碼
在企業(yè)應用系統(tǒng)開發(fā)中，方法調(diào)用（Method Invocation）和消息（Messaging）機制是兩種常用的數(shù)據(jù)處理與交換方式，下面關(guān)于這兩種機制的描述，不正確的是（）
A.方法調(diào)用一般具有同步特性，而消息機制具有異步的特點
B.從可靠性方面考慮，消息機制比方法調(diào)用更有優(yōu)勢
C.從效率方面考慮，一般情況下消息機制比方法調(diào)用更有優(yōu)勢
D.消息調(diào)用機制可以支持多個數(shù)據(jù)的發(fā)送者和接收者，更加靈活
設計模式（Design Pattem）是一套被反復使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設計經(jīng)驗的總結(jié)。下面關(guān)于設計模式所倡導的基本原則的描述，錯誤的是（）
A.模塊應對擴展開放，而對修改關(guān)閉
B.優(yōu)先使用繼承，而不是組合
C.要針對接口編程，而不是針對實現(xiàn)編程
D.抽象不應該依賴于細節(jié)，細節(jié)應當依賴于抽象
A.遠程過程調(diào)用
B.層次化
C.管道/過濾器
D.共享數(shù)據(jù)
最新試題
黑板構(gòu)架用于解決無確定性求解策略問題，它由黑板、知識源和仲裁者構(gòu)成。
效用樹的作用是使質(zhì)量屬性需求具體化，從而迫使設計師和客戶代表準確地定義出他們將要提供的相關(guān)質(zhì)量需求。
CBAM是對軟件系統(tǒng)進行經(jīng)濟建模的方法，它提供了對技術(shù)與經(jīng)濟問題以及構(gòu)架決策的評估。
Pipe-and-Filter構(gòu)架天然地支持并行，并具有良好的性能。
在軟件體系結(jié)構(gòu)模式中，解決方案包括一個特定的結(jié)構(gòu)，即元素的一個空間配置，還規(guī)定了運行期間的行為。
一個界面美觀、容易學習的系統(tǒng)是用戶評估易用性重要方面，因此構(gòu)架設計對此質(zhì)量屬性幫助不大。
接口展示了軟件構(gòu)件之間的交互關(guān)系，對于軟件構(gòu)架而言非常重要，需要單獨編檔。
和Pipe-and-Filter構(gòu)架相比，解釋器構(gòu)架提供更好的重用支持，并使得整個系統(tǒng)易于維護和增強。
體系結(jié)構(gòu)設計在軟件設計階段的后期，和前期的需求過程沒有關(guān)系。
好的構(gòu)架設計是一系列相容的原理和技術(shù)的產(chǎn)物，在項目的各個階段保持一致。