1.閱讀以下關於軟件系統設計的敘述，在答題紙上回答問題1至問題3。
【題目】
某文化產業集團委託軟件公司開發一套文化用品商城系統，業務涉及文化用品銷售、定製、競拍和點評等板塊，以提升商城的信息化建設水平。該軟件公司組織項目組完成了需求調研，現已進入到系統架構設計階段。考慮到系統需求對架構設計決策的影響，項目組先列出了可能影響系統架構設計的部分需求如下：
(a)用戶界面支持用戶的個性化定製；
(b)系統需要支持當前主流的標準和服務，特別是通信協議和平臺接口；
( c)用戶操作的響應時間應不大於3秒，競拍板塊不大於1秒；
(d)系統具有故障診斷和快速恢復能力；
(e)用戶密碼需要加密傳輸；
(f)系統需要支持不低於2G的數據緩存；
(g)用戶操作停滯時間超過一定時限需要重新登錄驗證；
(h)系統支持用戶選擇漢語、英語或法語三種語言之一進行操作。
項目組提出了兩種系統架構設計方案：瘦客戶端C/S架構和胖客戶端C/S架構，經過對上述需求逐條分析和討論，最終決定採用瘦客戶端C/S架構進行設計。
【問題1】(8分)
在系統架構設計中，決定系統架構設計的非功能性需求主要有四類：操作性需求、性能需求、安全性需求和文化需求。請簡要說明四類需求的含義。
【問題1解析】
統性能需求(Performance Requirements)：指響應時間、吞吐量、準確性、有效性、資源利用率等與系統完成任務效率相關的指標。可靠性、可用性等指標可歸爲此類。
安全性需求(Security Requirements)：系統向合法用戶提供服務並阻止非授權用戶使用服務方面的系統需求。
操作性需求(Operational Requirements)：與用戶操作使用系統相關的一些需求。
文化需求(Cultural Requirements)：帶有文化背景因素的系統需求。
【問題2】(8分)
根據表1-1的分類，將題幹所給出的系統需求(a)-(h)分別填入(1)~(4)。
| 需求類別 | 系統需求 |
|---|---|
| 操作性需求 | (1) |
| 性能需求 | (2) |
| 安全性需求 | (3) |
| 文化需求 | (4) |
【問題2解析】
(1): (a)、(b)
(2): ©、(d)、(f)
(3): (e)、(g)
(4): (h)
【問題3】(8分)
請說明瘦客戶端C/S架構能夠滿足題幹中給出的哪些系統需求(只需要回答出三個系統需求)。
【問題3解析】
1、問題問的是哪些需求瘦客戶端C/S能滿足。
這似乎是個僞命題，如果要做，這些需求都應該能滿足啊。
2、那麼退而求其次，只能理解爲哪些需求使用瘦客戶端比胖客戶端更合適(因爲題目是在胖與瘦之間做的選擇)。此時，好像也很難做出準確的判斷。
(a)無論胖還是瘦，要做到用戶界面的個性化應該都沒有問題，而且難說哪種更強。畢竟瘦的只是把業務邏輯從客戶端放到了服務器上。
(b)胖和瘦無明顯差異。
( c)胖客戶端，在客戶端的運算能力強一些。瘦客戶端可以在服務端面用集羣做支持。誰更強一點?
(d)瘦客戶端將業務邏輯遷移到應用服務器上，所以有故障只要修復服務器上的內容，而胖客戶端要更新所有客戶端，工作量大，所以此情況下瘦客戶端有優勢。
(e)胖客戶端的後端是數據庫，沒有業務邏輯，此時要做加密傳輸沒有基礎，但瘦客戶端可以做到。
(f) 胖客戶端做到2G數據緩存很容易，而瘦客戶端不現實。
(g) 瘦客戶端與胖客戶端均可做到。
(h) 瘦客戶端與胖客戶端均可做到。
2.閱讀以下關於軟件系統建模的敘述，在答題紙上回答問題1至問題3。
【題目】
某公司欲建設一個房屋租賃服務系統，統一管理房主和租賃者的信息，提供快捷的租賃服務。本系統的主要功能描述如下：
1. 登記房主信息。記錄房主的姓名、住址、身份證號和聯繫電話等信息，並寫入房主信息文件。
2. 登記房屋信息。記錄房屋的地址、房屋類型(如平房、帶陽臺的樓房、獨立式住宅等)、樓層、租金及房屋狀態(待租賃、已出租)等信息，並寫入房屋信息文件。一名房主可以在系統中登記多套待租賃的房屋。
3. 登記租賃者信息。記錄租賃者的個人信息，包括：姓名、性別、住址、身份證號和電話號碼等，並寫入租賃者信息文件。
4. 安排看房。已經登記在系統中的租賃者，可以從待租賃房屋列表中查詢待租賃房屋信息。租賃者可以提出看房請求，系統安排租賃者看房。對於每次看房，系統會生成一條看房記錄並將其寫入看房記錄文件中。
5. 收取手續費。房主登記完房屋後，系統會生成一份費用單，房主根據費用單交納相應的費用。
6. 變更房屋狀態。當租賃者與房主達成租房或退房協議後，房主向系統提交變更房屋狀態的請求。系統將根據房主的請求，修改房屋信息文件。
【問題1】(12分)
若採用結構化方法對房屋租賃服務系統進行分析，得到如圖2-1所示的頂層DFD。使用題幹中給出的詞語，給出圖2-1中外部實體E1-E2、加工P1-P6以及數據存儲D1~D4的名稱。
【問題1解析】
E1：房主 E2：租賃者
P1：登記房主信息 P2：登記房屋信息 P3：登記租賃者信息
P4：查詢待租賃房屋信息 P5：安排看房 P6：變更房屋狀態
D1：房主信息文件 D2：租賃者信息文件 D3：房屋信息文件
D4：看房記錄文件
【問題2】(5分)
若採用信息工程(Information Engineering)方法對房屋租賃服務系統進行分析，得到如圖2-2所示的ERD。請給出圖2-2中實體(1)~(5)的名稱。
【問題2解析】
(1)：房主 (2)：房屋 (3)：房屋信息文件
(4)：租賃者 (5)：看房記錄文件
【問題3】(8分)
(1)信息工程方法中的“實體(entity)” 與面向對象方法中的“類(class)”之間有哪些不同之處？
(2)在面向對象方法中通常採用用例(Use Case)來捕獲系統的功能需求。用例可以按照不同的層次來進行劃分，其中的Essential Use Cases和Real Use Cases有哪些區別?
【問題3解析】
(1)：實體用於數據建模，而類用於面向對象建模。實體只有屬性，而類有屬性和操作。
(2)：Essential Use Cases(抽象用例)，Real Use Cases(基礎用例)，這兩者的區別爲：基礎用例是實實在在在與用戶需求有對應關係的用例，是從用戶需求獲取的渠道得到的，而抽象用例是從基礎用例中抽取的用例的公共部分，是爲了避免重複工作，優化結構而提出的用例。
3.閱讀以下關於嵌入式實時系統相關技術的敘述，在答題紙上回答問題1和問題2。
【題目】
某公司長期從事宇航領域嵌入式實時系統的軟件研製任務。公司爲了適應未來嵌入式系統網絡化、智能化和綜合化的技術發展需要，決定重新考慮新產品的架構問題，經理將論證工作交給王工負責。王工經調研和分析，完成了新產品架構設計方案，提交公司高層討論。
【問題1】(14分)
王工提交的設計方案中指出：由於公司目前研製的嵌入式實時產品屬於簡單型系統，其嵌入式子系統相互獨立，功能單一，時序簡單。而未來滿足網絡化、智能化和綜合化的嵌入式實時系統將是一種複雜系統，其核心特徵體現爲實時任務的機理、狀態和行爲的複雜性。簡單任務和複雜任務的特徵區分主要表現在十個方面。請參考表3-1給出的實時任務特徵分類，用題幹中給出的(a)-(t) 20個實時任務特徵描述，補充完善表3-1給出的空(1)-(14)。
(a)任務屬性不會隨時間變化而改變；
(b)任務的屬性與時間相關；
( c)任務僅可以從非連續集中獲取特徵變量；
(d)任務變量域是連續的；
(e)功能原理不依賴於上下文；
(f)功能原理依賴於上下文；
(g)任務行爲可以用step-by-step順序分析方法來理解；
(h)許多任務在產生訪問活動時相互間是併發處理的，很難用step-by-step方法分析；
(i)因果關係相互影響；
(j)行爲特徵依賴於大量的反饋機制；
(k)系統內構成、策略和描述是相似的；
(l)系統內存在許多不同的構成、策略和描述；
(m)功能關係是非線性的；
(n)功能關係是線性的；
(o)不同的子任務是相互獨立的，任務內部僅存在少量的交互操作；
( p)不同的子任務有很高的交互操作，要把一個單任務的行爲隔離開是困難的；
(q)域特徵有非常整齊的原則和規則；
( r)許多不同的上下文依賴於規則；
(s)原理和規則在表面屬性上很容易被識別；
(t)原理被覆蓋、抽象，而不會在表面屬性上被識別。
| 特徵分類 | 簡單任務(sample task) | 複雜任務(complex task) |
|---|---|---|
| 靜態/動態 | (a) | (b) |
| 連續/非連續 | (1) | (2) |
| 子系統的獨立性 | (3) | (4) |
| 順序/並行執行 | (5) | (6) |
| 單一性/混合性 | (7) | (8) |
| 工作原理 | (9) | (10) |
| 線性/非線性 | (11) | (12) |
| 上下文相關性 | (13) | (14) |
| 規律/不規律 | (q) | ( r) |
| 表面屬性 | (s) | (t) |
【問題1解析】
| 特徵分類 | 簡單任務(sample task) | 複雜任務(complex task) |
|---|---|---|
| 靜態/動態 | (a) | (b) |
| 連續/非連續 | (d) | ( c) |
| 子系統的獨立性 | (e) | (f) |
| 順序/並行執行 | (g) | (h) |
| 單一性/混合性 | (i) | (j) |
| 工作原理 | (k) | (l) |
| 線性/非線性 | (n) | (m) |
| 上下文相關性 | (o) | ( p) |
| 規律/不規律 | (q) | ( r) |
| 表面屬性 | (s) | (t) |
【問題2】(11分)
王工設計方案中指出：要滿足未來網絡化、智能化和綜合化的需求，應該設計一種能夠充分表達嵌入式系統行爲的、且具有一定通用性的通信架構， 以避免複雜任務的某些特徵帶來的通信複雜性。通常爲了實現嵌入式系統中計算組件間的通信，在架構上需要一種簡單的架構風格，用於屏蔽不同協議、不同硬件和不同結構組成所帶來的複雜性。圖3-1給出了一種“腰(Waistline)" 型通信模式的架構風格。腰型架構的關鍵是基本消息通信(BMTS)，通常BMTS的消息與時間屬性相關，支持事件觸發消息、速率約束消息和時間觸發消息。
請說明基於BMTS的消息通信網絡的主要特徵和上述三種消息的基本含義，並舉例給出兩種具有時間觸發消息能力的網絡總線。
【問題2解析】
BMTS的消息通信網絡主要特徵：能適配不同的傳輸介質，以及適配不同的協議，屏蔽不同協議之間的差異，簡化通信過程降低系統複雜度。
事件觸發消息：以事件作爲觸發方式，事件發生便觸發相應消息。
速率約束消息：傳輸速率固定的消息。
時間觸發消息：以時間作爲觸發方式，到達時間點便觸發相應消息。
具有時間觸發消息能力的網絡總線：航空電子全雙工交換式以太網(AFDX)，時間觸發以太網(TTE)。
4.閱讀以下關於分佈式數據庫緩存設計的敘述，在答題紙上回答問題1至問題3。
【題目】
某企業是爲城市高端用戶提供高品質蔬菜生鮮服務的初創企業，創業初期爲快速開展業務，該企業採用輕量型的開發架構(腳本語言+關係型數據庫)研製了一套業務系統。業務開展後受到用戶普遍歡迎，用戶數和業務數量迅速增長，原有的數據庫服務器已不能滿足高度併發的業務要求。爲此，該企業成立了專門的研發團隊來解決該問題。
張工建議重新開發整個系統， 採用新的服務器和數據架構，解決當前問題的同時爲日後的擴展提供支持。但是，李工認爲張工的方案開發週期過長，投入過大，當前應該在改動儘量小的前提下解決該問題。李工認爲訪問量很大的只是部分數據，建議採用緩存工具MemCache來減輕數據庫服務器的壓力，這樣開發量小，開發週期短，比較適合初創公司，同時將來也可以通過集羣進行擴展。然而，劉工又認爲李工的方案中存在數據可靠性和一致性問題，在宕機時容易丟失交易數據，建議採用Redis來解決問題。在經過充分討論，該公司最終決定採用劉工的方案。
【問題1】(9分)
在李工和劉工的方案中，均採用分佈式數據庫緩存技術來解決問題。請說明分佈式數據庫緩存的基本概念。表4-1中對MemCache和Redis兩種工具的優缺點進行了比較，請補充完善表4-1中的空(1)~(6)。
| Memcache | Redis | |
|---|---|---|
| 數據類型 | 簡答key/value結構 | (1) |
| 持久性 | (2) | 支持 |
| 分佈式存儲 | (3) | 多種方式，主從、Sentinel、Cluster等 |
| 多線程支持 | 支持 | (4) |
| 內存管理 | (5) | 無 |
| 事物支持 | (6) | 有限支持 |
【問題1解析】
| Memcache | Redis | |
|---|---|---|
| 數據類型 | 簡答key/value結構 | key/value，list，set，hash，sorted |
| 持久性 | 不支持 | 支持 |
| 分佈式存儲 | 不支持 | 多種方式，主從、Sentinel、Cluster等 |
| 多線程支持 | 支持 | 不支持 |
| 內存管理 | 有 | 無 |
| 事物支持 | 不支持 | 有限支持 |
【問題2】(8分)
劉工認爲李工的方案存在數據可靠性和一致性的問題，請說明原因。爲避免數據可靠性和一致性的問題，劉工的方案採用Redis作爲數據庫緩存，請說明基本的Redis與原有關係數據庫的數據同步方案。
【問題2解析】
Memcache不支持數據持久化操作，所以掉電數據會全部丟失，而且無法直接恢復，這存在 可靠性間題
Memcache不支持事務，所以操作過程中可能產生數據的不一致性。
同步方案：讀取數據時，先讀取Redis中的數據，如果Redis沒有，則從原數據庫中讀取，並同步更新Redis中的數據。寫回時，寫入到原數據庫中，並同步更新到Redis中。
【問題3】(8分)
請給出Redis分佈式存儲的2種常見方案和Redis集羣切片的幾種常見方式。
【問題3解析】
Redis分佈式存儲的2種常見方案：主從方案、Cluster方案。
Redis集羣切片的幾種常見方式：
① 客戶端分片：在客戶端通過key的hash值對應到不同服務器。
② 對數據根據key散列到不同的slot上，不同slot對應不同的服務器。
5.閱讀以下關於Web系統設計的敘述，在答題紙上回答問題1至問題3。
【題目】
某銀行擬將以分行爲主體的銀行信息系統，全面整合爲由總行統一管理維護的銀行信息系統，實現統一的用戶賬戶管理、轉賬匯款、自助繳費、理財投資、貸款管理、網上支付、財務報表分析等業務功能。但是，由於原有以分行爲主體的銀行信息系統中，多個業務系統採用異構平臺、數據庫和中間件，使用的報文交換標準和通信協議也不盡相同，使用傳統的EAI解決方案根本無法實現新的業務模式下異構系統間靈活的交互和集成。因此，爲了以最小的系統改進整合現有的基於不同技術實現的銀行業務系統，該銀行擬採用基於ESB的面向服務架構(SOA)集成方案實現業務整合。
【問題1】(7分)
請說明什麼是面向服務架構(SOA)以及ESB在SOA中的作用與特點。
【問題1解析】
面向服務的架構（SOA)是一個組件模型，它將應用程序的不同功能單元（稱爲服務）通過 這些服務之間定義良好的接口和契約聯繫起來。接口是釆用中立的方式進行定義的，它應該 獨立於實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。
① 支撐SOA的關鍵是其消息傳遞架構-企業服務總線（ESB)。ESB用於實現企業應用不同消息和信息的準確、高效和安全傳遞。
② 面向服務的元數據管理：他必須瞭解被他中介的兩端，即服務的請求以及請求者對服務的要求，以及服務的提供者和他所握供的服務的描述；
③ 通信：服務的發佈/訂鬩、響應/請求、同步/異步消息、路由和尋址等；
④ 服務交互：服務接口定義，服務實現的置換，服務消息模型，服務目錄和發現等；
⑤ 服務安全：認證和授權、不可否認和機密性、安全標準的支持等。
【問題2】(12分)
基於該信息系統整合的實際需求，項目組完成了基於SOA的銀行信息系統架構設計方案。該系統架構圖如圖5-1所示：
請從(a)~ (j)中選擇相應內容填入圖5-1的(1)~ (6)，補充完善架構設計圖。
(a)數據層
(b)界面層
(c )業務層
(d) bind
(e)企業服務總線ESB
(f) XML
(g)安全驗證和質量管理
(h) publish
(i) UDDI
(j)組件層
(k) BPEL
【問題2解析】
(1)： c (2)： i (3) ：h (4)： e (5)： g (6)： j
【問題3】(6分)
針對銀行信息系統的數據交互安全性需求，列舉3種可實現信息系統安全保障的措施。
【問題3解析】
① 釆用挑戰/應答的認證機制，防止重放攻擊。
② 釆用加密技術保證信息在網絡傳輸過程的安全。
③ 釆用數字簽名技術保證信息傳輸過程的完整性和不可否認。