以下為2013年系統(tǒng)架構(gòu)設(shè)計師考試案例分析真題。

>>>點此進入系統(tǒng)架構(gòu)設(shè)計師歷年真題下載

一、閱讀以下關(guān)于企業(yè)應用系統(tǒng)集成架構(gòu)設(shè)計的說明，在答題紙上回答問題1和問題2。

【說明】

某航空公司希望對構(gòu)建于上世紀七、八十年代的主要業(yè)務系統(tǒng)進行改造與集成，提高企業(yè)的競爭力。由于集成過程非常復雜，公司決定首先以Ramp Coordination系統(tǒng)為例進行集成過程的探索與驗證。

在航空業(yè)中，Ramp Coordination是指飛機從降落到起飛過程中所需要進行的各種業(yè)務活動的協(xié)調(diào)過程。通常每個航班都有一位員工負責Ramp Coordination，稱之為Ramp Coordinator由Ramp Coordinator協(xié)調(diào)的業(yè)務活動包括檢查機位環(huán)境、卸貨和裝貨等。

由于航班類型、機型的不同，Ramp Coordination的流程有很大差異。圖1-1(a)所示的流程主要針對短期中轉(zhuǎn)航班，這類航班在機場稍作停留后就起飛；圖1-1(b)所示的流程主要針對到達航班，通常在機場過夜后第二天起飛；圖1-1(c)所示的流程主要針對離港航班，這類航班是每天的第一班飛機。這三種類型的航班根據(jù)長途/短途、國內(nèi)/國外等因素還可以進一步細分，每種細分航班類型的Ramp Coordination的流程也略有不同。

圖1-1 Ramp Coordination業(yè)務流程

為了完成上述業(yè)務，Ramp Coordination信息系統(tǒng)需要從乘務人員管理系統(tǒng)中提取航班乘務員的信息、從訂票系統(tǒng)中提取乘客信息、從機務人員管理系統(tǒng)中提取機務人員信息、接收來自航班調(diào)度系統(tǒng)的航班到達事件。其中乘務人員管理系統(tǒng)和航班調(diào)度系統(tǒng)運行在大型主機系統(tǒng)中，機務人員管理系統(tǒng)運行在Unix操作系統(tǒng)之上，訂票系統(tǒng)基于Java語言，具有Web界面，運行在Linux操作系統(tǒng)之上。

目前Ramp Coordination信息系統(tǒng)主要由人工完成所有協(xié)調(diào)工作，效率低且容易出錯。

公司領(lǐng)導要求集成后的Ramp Coordination信息系統(tǒng)能夠針對不同需求迅速開展業(yè)務流程，靈活、高效地完成協(xié)調(diào)任務。

針對上述要求，公司IT部門的架構(gòu)師經(jīng)過分析與討論，最終采用面向服務的架構(gòu)，以服務為中心進行Ramp Coordination信息系統(tǒng)的集成工作。

【問題1】(10分)

服務建模是對Ramp Coordination信息系統(tǒng)進行集成的首要工作，公司的架構(gòu)師首先對Ramp Coordination信息系統(tǒng)進行服務建模，識別出系統(tǒng)中的兩個主要業(yè)務服務組件：

（1）Ramp Control：負責Ramp Coordination信息系統(tǒng)中相關(guān)各種業(yè)務活動的組件；

（2）Flight Management：負責航班相關(guān)信息的管理，包括航班日程，乘客信息等。針對上述服務模型，結(jié)合題干描述，請為每個業(yè)務服務組件提供的服務進行分析與整理，完成表1-1中的空白部分。

表1-1業(yè)務組件服務提供的服務

【問題2】(15分)

對Ramp Coordination信息系統(tǒng)的集成涉及到對乘務人員管理系統(tǒng)、航班調(diào)度系統(tǒng)、機務人員管理系統(tǒng)和訂票系統(tǒng)的組織與協(xié)調(diào)，公司架構(gòu)師決定采用企業(yè)服務總線(Enterprise Service Bus，ESB)技術(shù)進行系統(tǒng)集成，請用200字以內(nèi)的文字對ESB的定義進行描述，給出ESB的五個主要功能，并針對題干描述，將恰當?shù)膬?nèi)容填入圖1-2中的（1）~（6）。

圖1-2系統(tǒng)集成框架圖

二、閱讀以下關(guān)于某項目開發(fā)計劃的說明，在答題紙上回答問題1至問題4。

【說明】

某軟件公司擬開發(fā)一套電子商務系統(tǒng)，王工作為項目組負責人負責編制項目計劃。由于該企業(yè)業(yè)務發(fā)展需要，CEO急于啟動電子商務系統(tǒng)，要求王工盡快準備一份擬開發(fā)系統(tǒng)的時間和成本估算報告。

項目組經(jīng)過討論后，確定出與項目相關(guān)的任務如表2-1所示。其中，根據(jù)項目組開發(fā)經(jīng)驗，分別給出了正常工作及加班趕工兩種情況下所需的時間和費用。

表2-1項目開發(fā)任務進度及費用

【問題1】（7分）

請用400字以內(nèi)文字說明王工擬編制的項目計劃中應包括哪些內(nèi)容。

【問題2】（8分）

請根據(jù)表2-1，分別給出正常工作和最短工期兩種情況下完成此項目所需的時間和費用。

【問題3】（4分）

如果項目在系統(tǒng)調(diào)研階段用了7天時間才完成，公司要求盡量控制成本，王工可在后續(xù)任務中采取什么措施來保證項目能按照正常工作進度完成？

【問題4】（6分）

如果企業(yè)CEO想在34天后系統(tǒng)上線，王工應該采取什么措施來滿足這一要求？這種情況下完成項目所需的費用是多少？

三、閱讀以下有關(guān)嵌入式軟件FMEA方法和相關(guān)案例的說明，在答題紙上回答問題1至問題3。

【說明】

故障（失效）模型影響分析FMEA是分析產(chǎn)品所有可能的故障模式及其可能產(chǎn)生的影響，并按每個故障模式產(chǎn)生影響的嚴重程度及其發(fā)生概率予以分類的一種歸納分析方法。近年來，F(xiàn)MEA方法已被廣泛用于安全關(guān)鍵系統(tǒng)的嵌入式軟件可靠性分析工作。

某軟件公司承擔了一項通信軟件的開發(fā)項目。該項目由FC系統(tǒng)、DY系統(tǒng)和GD系統(tǒng)組成，而DY系統(tǒng)(TMS320C25S)軟件負責按系統(tǒng)的通信協(xié)議完成與FC系統(tǒng)的通信，圖3-1給出了該通信軟件的約定層次圖。公司高層將項目交給王工程師，王工認為此項目是安全關(guān)鍵系統(tǒng)，安全等級應為Ⅱ類（致命的），因此應開展軟件的FMEA分析。

圖3-1某設(shè)備通信軟件的約定層次圖

【問題1】（8分）

請閱讀以下有關(guān)FMEA的描述，將恰當?shù)膬?nèi)容填入（1）～（7）。

FMEA是FMA（故障模式分析）和FEA（故障影響分析）的組合，它對系統(tǒng)各種可能的風險進行評價、分析后，在現(xiàn)有技術(shù)的基礎(chǔ)上消除這些風險或?qū)⑦@些風險降低到可接受的水平。為達到最佳效益，F(xiàn)MEA必須在產(chǎn)品研制初期進行。

FMEA實際是一組系列化的活動，其主要活動包括：

（1）__________；

（2）__________；

（3）__________。

由于產(chǎn)品故障可能與設(shè)計、制造過程、使用、承包商/供應商以及服務有關(guān)，因此FMEA又細分為（4）FMEA、（5）FMEA、（6）FMEA和（7）FMEA四類。

【問題2】（10分）

從圖3-1可以看出，CSU01信模塊是該項目的關(guān)鍵模塊，主要功能定義為：總線通信控制器自動完成一幀數(shù)據(jù)的接收，存入數(shù)據(jù)緩沖區(qū)，并產(chǎn)生中斷(INT0)通知CPU從數(shù)據(jù)緩沖區(qū)中讀取數(shù)據(jù)；CPU讀完數(shù)據(jù)后，將準備好的發(fā)送數(shù)據(jù)寫至數(shù)據(jù)緩存區(qū)，寫完后通知總線通信控制器自動完成一幀數(shù)據(jù)的發(fā)送。CRC校驗由外部電路完成判別，其結(jié)果通過數(shù)據(jù)線上的相應位進行標識。針對CSU01通信模塊，簡要描述實施FMEA的具體內(nèi)容，填寫完成表3-1的（1）～（5）。

表3-1 CSU01通信模塊FMEA步驟的主要內(nèi)容

【問題3】（7分）

表3-2給出針對該項目的CSU01通信模塊的軟件故障（失效）模型影響分析FMECA表（局部），請根據(jù)此題描述情況填寫表3-2中的（1）~（7）。

注：表3-2中的SRPN（軟件風險優(yōu)先數(shù)）=SESR（軟件故障模式的嚴酷度等級）×SOPR（軟件故障模式的發(fā)生概率等級）×SDDR（軟件故障模式的被檢測難度等級）。

表3-2通信模塊INT0-ISR的軟件FMECA表（局部）

四、閱讀以下有關(guān)表現(xiàn)層設(shè)計方面的說明，在答題紙上回答問題1至問題3。

【說明】

某商業(yè)銀行欲開發(fā)一套個人銀行系統(tǒng)，為用戶提供常見的金融服務，包括轉(zhuǎn)賬、查詢、存款變更和個人信息管理等功能。該軟件除了業(yè)務需求外，還有一些特殊的表現(xiàn)層需求：

（1）根據(jù)用戶級別的不同，界面和可用功能是不同的；

（2）支持Web、Windows、手機App等多種不同類型的界面；

（3）考慮到將來功能的擴展，需要系統(tǒng)支持界面的定制以及動態(tài)生成等功能，以降低系統(tǒng)維護和新功能發(fā)布的成本。

經(jīng)過對需求的討論，該銀行初步?jīng)Q定采用MVC模式設(shè)計該個人銀行系統(tǒng)的表現(xiàn)層，采用XML作為GUI的描述語言，并應用XML的界面管理技術(shù)來實現(xiàn)靈活的界面配置、界面動態(tài)生成和界面定制。

【問題1】（9分）

MVC模式強制性地將一個應用處理流程按照模型、視圖、控制的方式進行分離，三者的協(xié)作關(guān)系如圖4-1所示。

圖4-1 MVC設(shè)計模式

請?zhí)顚憟D4-1中的（1）～（3），并簡要說明在該個人銀行系統(tǒng)中采用MVC模式對界面設(shè)計的作用。

【問題2】（4分）

請從設(shè)計模式的角度，簡要說明設(shè)計方案采用XML作為GUI描述語言的機制。

【問題3】（12分）

基于XML的界面管理技術(shù)可實現(xiàn)靈活的界面配置、界面動態(tài)生成和界面定制，其思路是用XML生成配置文件及界面所需的元數(shù)據(jù)，按不同需求生成界面元素及軟件界面，其技術(shù)框圖如圖4-2所示。

圖4-2基于XML的界面管理技術(shù)框架

請將恰當?shù)膬?nèi)容填入圖4-2中的（1）～（3），并簡要解釋說明其含義。

五、閱讀以下有關(guān)軟件與信息安全方面的說明，在答題紙上回答問題1至問題3。

【說明】

某軟件公司擬開發(fā)一套信息安全支撐平臺，為客戶的局域網(wǎng)業(yè)務環(huán)境提供信息安全保護。該支撐平臺的主要需求如下：

（1）為局域網(wǎng)業(yè)務環(huán)境提供用戶身份鑒別與資源訪問授權(quán)功能；

（2）為局域網(wǎng)環(huán)境中交換的網(wǎng)絡(luò)數(shù)據(jù)提供加密保護；

（3）為服務器和終端機存儲的敏感持久數(shù)據(jù)提供加密保護；

（4）保護的主要實體對象包括局域網(wǎng)內(nèi)交換的網(wǎng)絡(luò)數(shù)據(jù)包、文件服務器中的敏感數(shù)據(jù)文件、數(shù)據(jù)庫服務器中的敏感關(guān)系數(shù)據(jù)和終端機用戶存儲的敏感數(shù)據(jù)文件：

（5）服務器中存儲的敏感數(shù)據(jù)按安全管理員配置的權(quán)限訪問；

（6）業(yè)務系統(tǒng)生成的單個敏感數(shù)據(jù)文件可能會達到數(shù)百兆的規(guī)模；

（7）終端機用戶存儲的敏感數(shù)據(jù)為用戶私有；

（8）局域網(wǎng)業(yè)務環(huán)境的總用戶數(shù)在100人以內(nèi)。

【問題1】（9分）

在確定該支撐平臺所采用的用戶身份鑒別機制時，王工提出采用基于口令的簡單認證機制，而李工則提出采用基于公鑰體系的認證機制。項目組經(jīng)過討論，確定采用基于公鑰體系的機制，請結(jié)合上述需求具體分析采用李工方案的原因。

【問題2】（7分）

針對需求（7），項目組經(jīng)過討論，確定了基于數(shù)字信封的加密方式，其加密后的文件結(jié)構(gòu)如圖5-1所示。請結(jié)合需求說明對文件數(shù)據(jù)進行加密時，應采用對稱加密的塊加密方式還是流加密方式，為什么？并對該機制中的數(shù)據(jù)加密與解密過程進行描述。

圖5-1加密數(shù)據(jù)文件結(jié)構(gòu)

【問題3】（9分）

對數(shù)據(jù)庫服務器中的敏感關(guān)系數(shù)據(jù)進行加密保護時，客戶業(yè)務系統(tǒng)中的敏感關(guān)系數(shù)據(jù)主要是特定數(shù)據(jù)庫表中的敏感字段值，客戶要求對不同程度的敏感字段采用不同強度的密鑰進行防護，且加密方式應盡可能減少安全管理與應用程序的負擔。目前數(shù)據(jù)庫管理系統(tǒng)提供的基本數(shù)據(jù)加密方式主要包括加解密API和透明加密兩種，請用300字以內(nèi)的文字對這兩種方式進行解釋，并結(jié)合需求說明應采用哪種加密方式。