以下為2010年系統架構設計師考試案例分析真題，供大家參考學習。

>>>點此進入系統架構設計師歷年真題下載

一、閱讀以下關于軟件系統架構選擇的說明，在答題紙上回答問題1至問題3。

【說明】

某公司欲針對Linux操作系統開發一個KWIC（Key Word in Context）檢索系統。該系統接收用戶輸入的查詢關鍵字，依據字母順序給出相關幫助文檔并根據幫助內容進行循環滾動閱讀。在對KWIC系統進行需求分析時，公司的業務希賽網發現用戶后續還有可能采用其它方式展示幫助內容。根據目前需求，公司的技術人員決定通過重復剪切幫助文檔中的第一個單詞并將其插入到行尾的方式實現幫助文檔內容的循環滾動，后續還將采用其它的方法實現這一功能。

在對KWIC系統的架構進行設計時，公司的架構師王工提出采用共享數據的主程序-子程序的架構風格，而李工則主張采用管道-過濾器的架構風格。在架構評估會議上，大家從系統的算法變更、功能變更、數據表示變更和性能等方面對這兩種方案進行評價，最終采用了李工的方案。

【問題1】（7分）

在實際的軟件項目開發中，采用恰當的架構風格是項目成功的保證。請用200字以內的文字說明什么是軟件架構風格，并對主程序-子程序和管道-過濾器這兩種架構風格的特點進行描述。

【問題2】（12分）

請完成表1-1中的空白部分（用+表示優、－表示差），對王工和李工提出的架構風格進行評價，并指出采用李工方案的原因。

表1-1王工與李工的架構風格評價

【問題3】（6分）

圖1-1是李工給出的架構設計示意圖，請將恰當的功能描述填入圖中的（1）～（4）。

圖1-1李工給出的架構示意圖

二、閱讀以下關于軟件系統數據架構建模的說明，在答題紙上回答問題1至問題3。

【說明】

RMO是一家運動服裝制造銷售公司，計劃在五年時間內將銷售區域從華南地區擴展至全國范圍。為了擴大信息技術對于未來業務發展的價值，公司邀請咨詢顧問幫助他們制訂戰略信息系統規劃。經過評審，咨詢顧問給出的戰略規劃要點之一是建立客戶關系支持系統CRSS。RMO公司決定由其技術部成立專門的項目組負責CRSS的開發和維護工作。

項目組在仔細調研和分析了系統需求的基礎上，確定了基于互聯網的CRSS系統架構。但在確定系統數據架構時，張工認為應該采用集中式的數據架構，給出的理由是結構簡單、易維護且開發及運行成本低；而劉工建議采用分布式的數據架構，并提出在開發中通過“局部數據庫+緩存”的讀寫分離結構實現，具有較好的運行性能和可擴展性。

項目組經過集體討論，考慮到公司的未來發展規劃，最終采用了劉工的建議。

【問題1】（8分）

請用300字以內的文字，說明張工和劉工提出的數據架構的基本思想。

【問題2】（13分）

在劉工建議的基礎上，為了避免CRSS系統的單點故障，請用200字以內文字簡要說明如何建立CRSS的數據庫系統；對于數據的讀取、添加、更改和刪除操作分別如何實現。

【問題3】（4分）

RMO公司銷售區域將在未來五年大面積擴展，其潛在客戶數量也會因此大幅度增加，所以良好的可擴展性是CRSS系統所必需的質量屬性。請分別說明在集中式和分布式數據架構下，可以采用哪些方法提升系統的可擴展性。

三、閱讀以下關于汽車電子基礎軟件架構的說明，在答題紙上回答問題1至問題3。

【說明】

某軟件公司承擔了某項重點項目的研制工作，任務重點是參考國外汽車電子發展趨勢，開發某汽車公司的企業汽車電子基礎軟件的架構，逐步實現汽車企業未來技術發展規劃。

該軟件公司接收此項任務后，調動全體技術人員深入收集國外相關技術資料，經過多方調研和分析，公司提出遵照國際組織最新推出的AUTOSAR規范，按統籌規劃、分步驟實施的原則，實現汽車公司的基礎軟件架構設計。圖3-1給出了AUTOSAR規范所定義的工作包，圖中灰色部分代表本項目工作所包含的內容，即軟件架構和基礎軟件。

圖3-1 AUTOSAR定義的工作包

【問題1】（7分）

AUTOSAR規范中要求，汽車電子軟件開發流程應盡量滿足并發、可多次迭代的特性。為了定義汽車電子的軟件開發過程，公司李工和王工分別提出了兩種軟件開發流程，其開發流程見圖3-2和3-3（圖中ECU是指汽車電子中的電子控制單元）。請說明李工和王工誰定義的流程更符合AUTOSAR的規定，并說明理由。

圖3-2李工設計的流程

圖3-3王工設計的流程

【問題2】（10分）

圖3-1中的II-1.1.1項中定義了軟件架構和操作系統的要求，圖3-4是滿足AUTOSAR定義的操作系統各功能模塊的層次結構，請說明（1）~（5）箭頭所標的具體操作含義。

圖3-4 AUTOSAR定義的操作系統結構

【問題3】（8分）

AUTOSAR是一種開放式架構，用150字以內的文字，說明采用AUTOSAR架構的主要優點，并說明汽車電子ECU覆蓋汽車的哪三個領域。

四、閱讀以下關于系統設計與開發工具集成的說明，在答題紙上回答問題1至問題3。

【說明】

TeleDev是一個大型的電信軟件開發公司，公司內部采用多種商業/開源的工具進行軟件系統設計與開發工作。為了提高系統開發效率，公司管理層決定開發一個分布式的系統設計與開發工具集成框架，將現有的系統設計與開發工具有效集成在一起。集成框架開發小組經過廣泛調研，得到了如下核心需求：

（1）目前使用的系統設計與開發工具的運行平臺和開發語言差異較大，集成框架應無縫集成各個工具的功能；

（2）目前使用的系統設計與開發工具所支持的通信協議和數據格式各不相同，集成框架應實現工具之間的靈活通信和數據格式轉換；

（3）集成框架需要根據實際的開發流程靈活、動態地定義系統工具之間的協作關系；

（4）集成框架應能集成一些常用的第三方實用工具，如即時通信，郵件系統等。

集成框架開發小組經過分析與討論，最終決定采用企業服務總線（ESB）作為集成框架的基礎架構。

【問題1】（8分）

ESB是目前企業級應用集成常用的基礎架構。請列舉出ESB的4個主要功能，并從集成系統的部署方式、待集成系統之間的耦合程度、集成系統的可擴展性3個方面說明為何采用ESB作為集成框架的基礎架構。

【問題2】（12分）

在ESB基礎架構的基礎上，請根據題干描述中的4個需求，說明每個需求應該采用何種具體的集成方式或架構風格最為合適。

【問題3】（5分）

請指出在實現工具之間數據格式的靈活轉換時，通常采用的設計模式是什么，并對實現過程進行簡要描述。

五、閱讀以下信息系統可靠性的問題，在答題紙上回答問題1至問題3。

某軟件公司開發一項基于數據流的軟件，其系統的主要功能是對輸入的數據進行多次分析、處理和加工，生成需要的輸出數據。需求方對該系統的軟件可靠性要求很高，要求系統能夠長時間無故障運行。該公司將該系統設計交給王工負責。王工給出該系統的模塊示意圖如圖5-1所示。王工解釋：只要各個模塊的可靠度足夠高，失效率足夠低，則整個軟件系統的可靠性是有保證的。

圖5-1王工建議的軟件系統模塊示意圖

李工對王工的方案提出了異議。李工認為王工的說法有兩個問題：第一，即使每個模塊的可靠度足夠高，假設各個模塊的可靠度均為0.99，但是整個軟件系統模塊之間全部采用串聯，則整個軟件系統的可靠度為0.994=0.96，即整個軟件系統的可靠度下降明顯；第二，軟件系統模塊全部采用串聯結構，一旦某個模塊失效，則意味著整個軟件系統失效。

李工認為，應該在軟件系統中采用冗余技術中的動態冗余或者軟件容錯的N版本程序設計技術，對容易失效或者非常重要的模塊進行冗余設計，將模塊之間的串聯結構部分變為并聯結構，來提高整個軟件系統的可靠性。同時，李工給出了采用動態冗余技術后的軟件系統模塊示意圖，如圖5-2所示。

圖5-2李工建議的系統模塊示意圖

劉工建議，李工方案中M1和M4模塊沒有采用容錯設計，但M1和M4發生故障有可能導致嚴重后果。因此，可以在M1和M4模塊設計上采用檢錯技術，在軟件出現故障后能及時發現并報警，提醒維護人員進行處理。

注：假設各個模塊的可靠度均為0.99

【問題1】（4分）

在系統可靠性中，可靠度和失效率是兩個非常關鍵的指標，請分別解釋其含義。

【問題2】（13分）

請解釋李工提出的動態冗余和N版本程序設計技術，給出圖5-1中模塊M2采用圖5-2動態冗余技術后的可靠度。

請給出采用李工設計方案后整個系統可靠度的計算方法，并計算結果。

【問題3】（8分）

請給出檢錯技術的優缺點，并說明檢測技術常見的實現方式和處理方式。