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

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

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

【說明】

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

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

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

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

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

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

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

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

【問題1】(10分)

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

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

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

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

【問題2】(15分)

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

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

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

【說明】

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

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

表2-1項(xiàng)目開發(fā)任務(wù)進(jìn)度及費(fèi)用

【問題1】（7分）

請(qǐng)用400字以內(nèi)文字說明王工擬編制的項(xiàng)目計(jì)劃中應(yīng)包括哪些內(nèi)容。

【問題2】（8分）

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

【問題3】（4分）

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

【問題4】（6分）

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

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

【說明】

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

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

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

【問題1】（8分）

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

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

FMEA實(shí)際是一組系列化的活動(dòng)，其主要活動(dòng)包括：

（1）__________；

（2）__________；

（3）__________。

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

【問題2】（10分）

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

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

【問題3】（7分）

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

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

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

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

【說明】

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

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

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

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

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

【問題1】（9分）

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

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

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

【問題2】（4分）

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

【問題3】（12分）

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

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

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

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

【說明】

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

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

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

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

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

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

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

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

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

【問題1】（9分）

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

【問題2】（7分）

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

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

【問題3】（9分）

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