系統架構設計師既然屬於軟考高級，它的含金量肯定也是比較大的。軟考證書是全國認可的，在很多國企、事業單位以及一些其他企業，可以用軟考證書來評職稱。而系統架構設計師屬於軟考高級資格證書，可聘任高級工程師職務，幫助升職加薪。當然也是對過往成績的一次認證，同時也是繼續出發的一個起點，故精調細選往年的系統架構設計師考試的易錯選擇題，和大家一起分享及解讀！
01CRC校驗碼
CRC校驗碼，其根本思想就是先在要發送的幀後面附加一個數（這個數，就是用來做校驗的校驗碼，但要注意，這個數也是二進位序列的，下同），生成一個新幀發送給接收端。
當然，這個附加的數不是隨意的，它要使所生成的新幀能與發送端和接收端共同選定的某個特定數整除（注意，這裡不是直接採用二進位除法，而是採用一種稱之為「模2除法」）。
到達接收端後，再把接收到的新幀除以（同樣採用「模2除法」）這個選定的除數。因為在發送端發送數據幀之前就已通過附加一個數，做了「去餘」處理（也就已經能整除了），所以結果應該是沒有餘數。
如果有餘數，則表明該幀在傳輸過程中出現了差錯。
1.若信息碼字為111000110，生成多項式G(x)=x5+x3+x+1，則計算出的CRC校驗碼為（ ）。A. 01101 B. 11001C. 001101 D. 011001
解析：
（1）生成多項式G(X)對應的二進位數為 101011(有X的幾次方，對應位上就是1）
（2）校驗碼的位數就是生成多項式的最高冥次，即該生成多項式產生的校驗碼為5位
（3）由於校驗碼的位數為5位，因此需要在信息碼後面補5個0，即信息碼為11100011000000
（4）用補位後的信息碼除以生成多項式（用「模2除法」(其實就是亦或^)，得到的餘數即為CRC校驗碼(11001)。
（5）發送端發送的信息：CRC^11 1000 1100 0000 = 0011 1000 1101 1001 。即發送給客戶端的數據為0011 1000 1101 1001
（6）接收端用收到的數據除以生成多項式（模2除法），餘數為0則說明無差錯
02系統架構設計
在架構設計中普遍關注的質量屬性包含性能、可用性、安全性、可修改性、可靠性、易用性、可測試性等，其中前4項是質量屬性效應樹的重要組成部分，通過質量屬性效應樹，又可進一步分析出架構設計中的敏感點、權衡點和問題決策帶來的風險隱患。而條件約束主要來源於用戶的限制包括了預算、機構政策和其它軟硬體交互的外部因素，例如遵守什麼樣的行業標準、使用哪個廠商的產品、採用哪種開發技術等。
軟體架構設計的4條策略：
一、性能設計
性能是指系統響應能力，包括速度、吞吐量和持續高速性三方面的要求。
針對性能方客戶提出性能要求：
第一，系統應具有快速的響應能力，在網絡負載正常情況下打開界面的平均響應時間小於1.5秒，在線查詢和提交操作的處理時間小於2秒；第二，系統應能承受每年11月底帶來的負載壓力。對於性能需求在架構設計中可選的方案有優先級隊列、增加計算資源、減少計算開銷、引入並發機制、採用資源調度等。
在架構設計上，若採用了優先級隊列和增加計算資源兩個方案，首先採用RabbitMQ消息組件使系統以消息為中心進行交互，可保證請求的處理順序，特別是在高並發情況下可解決流量削峰問題。然後在數據層使用了讀寫分離技術，採用Memcache作為查詢資料庫，分擔主庫負載提高查詢速度。
二、可用性設計
可用性是指系統能正常運行的時間比。
針對這個方面客戶提出可用性要求：
第一，必須保證系統7*24小時持續提高服務的能力；第二，在網絡失效或主機斷電的情況下，系統必須保證在3分鐘內啟用備用設備恢復正常服務。對可用性需求在架構設計中可選的方案有心跳、Ping/Echo、冗餘、進程監視器。
在架構設計上，若採用了心跳技術和冗餘技術，使用keepalived組件構件雙機熱備環境，用戶通過虛擬IP訪問，當Master宕機自動切換到Backup繼續運行，防止因為單點故障導致系統癱瘓。
若在與信息中心溝通時受到了硬體資源上的約束，因伺服器資源緊張，部署策略不得不由雙機熱備後改為雙機互備，在性能和可用性上求得了平衡。
三、安全性設計
安全性是指軟體系統可向合法用戶提供服務，以及阻止非授權使用服務的能力。
針對這個方面用戶的安全性要求，提出必須保證企業用戶，通過網際網路訪問系統的安全防止欺詐和篡改。
對安全性需求，在架構設計中可選的方案有用戶認證，用戶授權，追蹤審計，限制訪問。
在架構設計上，可採用了用戶認證技術，使用SSL證書+Ukey雙向認證方式，只須插入Ukey即可登錄系統，每個Ukey在服務端均與用戶身份進行了綁定。
若在方案評審時，受到了用戶方預算上的約束，由於因CA每年會向單個Ukey設備收取200元左右的年費，將是一筆巨款，因此經過折中，確定為僅向大型國有企業發放Ukey，並且費用自理，以節省資金預算。對於普通中小型企業，可採用了服務端SSL證書+客戶端動態驗證方式。
四、可修改性設計
可修改性是指能快速地並以較高性價比對系統進行變更的能力。
針對這個方面用戶提出，系統應該能夠適應不斷變化的業務環境，可快速的實現業務的新增、修改。
對可修改性需求，在架構設計中可選的方案有抽象、信息隱藏、限制通信路徑、運行時註冊。
在架構設計上，若採用Java語言作為主開發語言，保證程序的抽象和信息隱藏，同時使用Spring框架管理JavaBean運行時註冊，最後在架構上採用了服務化設計，將系統拆分成若干獨立服務，相互間通過消息進行通信，降低系統耦合度。
但在設計與異構系統通信時，若受到了來自用戶現行技術標準上的約束，由於已投入使用的部分舊系統僅支持webervice技術，因此一體化平臺在只能採用相同的方式與這些系統進行交互。
2.某公司欲開發一個人員管理系統，在架構設計階段，公司的架構師識別出3個核心質量屬性場景。其中「管理系統遭遇斷電後，能夠在15秒內自動切換至備用系統並恢復正常運行」主要與（58）質量屬性相關，通常可採用（59）架構策略實現該屬性；「系統正常運行時，人員信息查詢請求應該在2秒內返回結果」主要與（60）質量屬性相關，通常可採用（61）架構策略實現該屬性；「系統需要對用戶的操作情況進行記錄，並對所有針對系統的惡意操作行為進行報警和記錄」主要與（62）質量屬性相關，通常可採用（63）架構策略實現該屬性。（58）A. 可用性B. 性能C. 易用性 D. 可修改性（59）A. 抽象接口 B. 信息隱藏 C. 主動冗餘 D. 影子操作（60）A. 可測試性 B. 易用性C. 可用性 D. 性能（61）A. 記錄/回放 B. 操作串行化C. 心跳 D. 資源調度（62）A. 可用性 B. 安全性C. 可測試性 D. 可修改性（63）A. 追蹤審計 B. Ping/EchoC. 選舉 D. 維護現有接口
【解析】
能夠在15秒內自動切換至備用系統並恢復正常運行」主要與可用性（58題）質量屬性相關。通常可採用心跳、Ping/Echo、主動冗餘、被動冗餘、選舉等（59題）架構策略實現該屬性。
「系統正常運行時，人員信息查詢請求應該在2秒內返回結果」主要與性能（60題）質量屬性相關，實現該屬性的常見架構策略包括：增加計算資源、減少計算開銷、引入並發機制、採用資源調度（61題）等。
系統應該能夠抵擋惡意用戶的入侵行為，並進行報警和記錄」主要與安全性（62題）質量屬性相關，通常可採用入侵檢測、用戶認證、用戶授權、追蹤審計（63題）等架構策略實現該屬性。
【答案】A、C、D、D、B、A
03系統架構的評估主要評估方法架構分析方法
1、SAAM
基於場景的架構分析方法（Scenarios-based Architecture Analysis Method， SAAM）是非功能質量屬性的體系結構分析方法，是最早形式成文檔並得到廣泛使用的分析方法。最初它用於比較不同的軟體體系結構，以分析SA的可修改性。
特定目標，目標是對描述應用程式屬性的文檔，驗證假設和原則，有利於評估固有的風險。評估技術，使用場景技術，描述了各種系統 必須支持的活動 和 將要發生的變化。質量屬性，可修改性 是 SAAM分析的主要 質量屬性。風險承擔者，SAAM 協調不同參與者所感興趣的方面，作為後續決策的基礎，提供了對系統結構的 公共理解。體系結構描述，描述形式 應該被所有參與者理解。功能、結構、分配，三個主要方面。方法活動，SAAM 的主要輸入問題是 描述、需求聲明、體系結構描述。SAAM 分析評估 體系結構過程包括 5個 步驟：場景開發、體系結構描述、單個場景評估、場景交互、總體評估。
通過各類 風險承擔者協商討論，開發一些 任務場景，體現系統所支持的 各種活動。
通過對場景交互的分析，得出系統中所有場景對系統中構件所產生影響的列表。總體的 權衡 和 評價。
2、ATAM
體系結構權衡分析方法（Architecture Tradeoff Analysis Method，ATAM），主要針對 性能、實用性、安全性、可修改性。
確定多個質量屬性之間 這種 的必要性。
體系結構空間 受到 歷史遺留系統、互操作性 和 以前失敗的項目約束。
邏輯視圖被分為 功能結構和 代碼結構。這些結構加上他們之間適當的映射可以完整地描述一個體系結構。
用一組 消息順序圖 顯示運行時的 交互 和 場景。
從不同的體系結構角度，有三種不同場景，用例、增長場景、探測場景。
ATAM 使用定性的 啟發式分析方法QAH，構造 精確分析模型時 要進行分析。
4個主要的活動領域（或階段），場景和需求收集、結構視圖和場景實現、屬性模型構造和分析、分析與折中。
屬性分析是互相依賴的。獲得屬性交互的方法有兩種，敏感度分析來發現折中點、通過檢查假設。迭代的改進。除了通常從場景派生而來的需求，還有很多對 行為模式和執行環境的 假設。由於屬性之間存在折中，每一個架設都要被 檢查、驗證、提問，完成所有操作後，把分析的 結果和需求 進行對比。
領馭知識庫通過基於屬性的 體系結構風格ABAS維護，變得更為慣例化、更可預測，得到一個標準問題集合。
3.體系結構權衡分析方法（Architecture Tradeoff Analysis Method，ATAM）包含4個主要的活動領域，分別是場景和需求收集、體系結構視圖和場景實現、（47） 、折中。基於場景的架構分析方法（Scenarios-based Architecture Analysis Method， SAAM）的主要輸入是問題描述、需求聲明和（48）。（47）A. 架構設計B. 問題分析與建模C. 屬性模型構造和分析D. 質量建模（48）A. 問題說明B. 問題建模C. 體系結構描述D. 需求建模
ATAM包含4個主要的活動領域，分別是場景和需求收集、體系結構視圖和場景實現、屬性模型構造和分析 、折中。
SAAM的主要輸入問題是問題描述、需求聲明和體系結構描述。
【答案】CC。
04特定領域軟體架構
特定領域軟體架構（Domain Specific Software Architecture, DSSA），主要目的在一組相關的應用中共享體系結構。
DSSA的必備特徵：
一個嚴格定義的問題域和解域。具有普遍性。對整個領域的構件組織模型其當抽象。具備該領域固定的、典型的可重用元素。DSSA的基本活動
1、領域分析主要目標是獲得領域模型，描述領域中系統之間的共同需求，定義領域的邊界。從而明確分析的對象，識別信息源，確定哪些需求是領域中的系統廣泛共享的，從而建立領域模型。
2、領域設計目標是獲得DSSA，DSSA描述在領域模型中表示的需求的解決方案。不是單個系統的表示，而是能夠適應領域中多個系統的需求的一個高層次設計。
3、領域實現主要目標是依據領域模型和DSSA開發和組織可重用信息，對基礎軟體架構進行實現。領域模型和DSSA定義了這些可重用信息的重用時機。
以上過程是反覆的、逐漸求精的過程。
參與DSSA的人員
4種角色：領域專家、領域分析師、領域設計人員、領域實現人員。
1、領域專家可能包括有經驗的用戶、從事該領域中系統的需求分析、設計、實現以及項目管理的有經驗的軟體工程師等。主要任務提供需求規約和實現的知識，組織規範的、一致的領域字典，選擇樣本系統，覆審領域模型、DSSA。
應該熟悉該領域軟體設計和實現、硬體限制、未來的用戶需求、技術走向等。
2、領域分析人員應由系統分析員來擔任。知識獲取組織到領域模型中，根據現有系統、標準規範等驗證模型的準確性和一致性。
應熟悉軟體重用和領域分析方法，具有一定的該領域經驗，較高的抽象、關聯、類比能力，較高的交互合作能力。
3、領域設計人員控制整個軟體設計過程，根據領域模型和現有系統開發出DSSA，對DSSA的準確性和一致性進行驗證，建立領域模型和DSSA之間的聯繫。應熟悉軟體重用和領域設計方法，熟悉軟體設計方法，有一定的該領域經驗。
4、領域實現人員根據領域模型和DSSA，從頭開發可重用構件，或利用再工程技術從現有系統中提取可重用構件。DSSA的建立過程
一般情況下，需要用開發者習慣使用的工具和方法建立DSSA模型。
DSSA建立過程分為5個階段，過程是並發的、遞歸的、反覆的，可能每個階段經歷幾遍，每次增加更多的細節。
1、定義領域範圍，一系列用戶的需求。2、定義領域特定的元素，編譯領域字典、領馭屬於的同義詞詞典。3、定義特定的設計和實現需求約束，不僅要識別出約束，並且要記錄約束對設計和實現造成的後果，還要記錄對處理這些問題時所產生的所有問題的討論。4、定義領域模型和體系結構，產生一般的體系結構，並說明構成它們的模塊或構件的語法、語義。5、搜集可重用的產品單元，為DSSA增加構件。4.特定領域軟體架構（Domain Specific Software Architecture, DSSA）的基本活動包括領域分析、領域設計和領域實現。其中，領域分析的主要目的是獲得領域模型。領域設計的主要目標是獲得（45）。領域實現是為了（46）。（45）A. 特定領域軟體需求 B. 特定領域軟體架構C. 特定領域軟體設計模型D. 特定領域軟體重用模型（46）A. 評估多種軟體架構B. 驗證領域模型 C. 開發和組織可重用信息，對基礎軟體架構進行實現
【解析】
特定領域軟體架構(DSSA)是一個特定的問題領域中由領域模型、參考需求及參考架構等組成的開發基礎架構，其目標就是支持一個特定領域中多個應用的生成。
DSSA的基本活動包括領域分析、領域設計和領域實現。領域分析的主要目的是獲得領域模型，領域模型描述領域中系統之間共同的需求，即領域需求；領域設計的主要目標是獲得DSSA，DSSA描述領域模型中表示需求的解決方案；領域實現的主要目標是依據領域模型和DSSA開發並組織可重用信息。
【答案】 BC。
05CORBA程序的工作流程
CORBA的底層結構是基於面向對象模型的，由OMG接口描述語言(OMG Interface Definition Language，OMG IDL)、對象請求代理(Objec tRequest Broker，ORB)和IIOP標準協議（Internet Inter ORB Protocol，也稱網絡ORB交換協議）3個關鍵模塊組成。是對象管理組織（OMG）為解決分布式處理環境(DCE)中，硬體和軟體系統的互連而提出的一種解決方案。
工作流程的一些細節
1. Server啟動，等待來自Client的請求
Server啟動後，它首先生成一個POA(potable object adapter)。然後告訴POA他所能提供的服務，即Servant(Server按照IDL定義所實現的每個對象)。Server從POA處得到每個Servant的引用OR(Object Reference，類似於句柄)。Server把自己提供的服務公布出來，這裡有兩個辦法：將OR轉換為一個字符串並輸出；將這個OR綁定到一個簡單易理解的名字上，這通過Naming Service完成。
2. Client調用你定義的對象方法
Client通過象Naming Service查詢獲得要訪問的對象的引用OR(object reference)，或通過一個IOR字符串獲得；Client通過這個引用調用對象的方法，因為OR中有足夠的信息來定位一個對象；這個調用被傳遞給ORB。
3. 調用的完成
Client端的調用請求通過ORB被傳遞給正確的Server端的ORB，定位是根據OR實現的；這個ORB把調用請求交給真正的Server進行處理;Server又根據OR定位產生這個OR的POA，並把請求傳給它；POA又把請求傳給最後真正的Servant，完成調用並返回。
5.CORBA服務端構件模型中，（ ）是CORBA對象的真正實現，負責完成客戶端請求。A. 伺服對象（Servant）B. 對象適配器（Object Adapter）C. 對象請求代理（Object Request Broker）D. 適配器激活器（Adapter Activator）
伺服對象（Servant）：CORBA對象的真正實現，負責完成客戶端請求。
對象適配器（Object Adapter）：用於屏蔽ORB內核的實現細節，為伺服器對象的實現者提供抽象接口，以便他們使用ORB內部的某些功能。
對象請求代理（Object Request Broker）：解釋調用並負責查找實現該請求的對象，將參數傳給找到的對象，並調用方法返回結果。客戶方不需要了解服務對象的位置、通信方式、實現、激活或存儲機制。
【答案】 A。
人生道路上，不止眼前的苟且，不要說什麼詩和遠方，總有一些自己內心追求，為自己定個目標，總是美好的吧。在追求中，可能道路是曲折的，但是不要著急，相信前途是光明的。