1、 模擬 系統架構設計師下午 （ ） 模擬 3案例分析題 試題一 閱讀以下關于設計模式應用的敘述，根據要求回答問題。 說明 PH 軟件公司承接了某企業二期信息化軟件開發項目， 工程項目的研發任 務之一是建設采購分級審批系統。 該企業采購審批是根據采購金額的不同由不同 層次的主管人員來審批， 主任可以審批 8萬元以下 （不包含 8萬元）的采購單，副 董事長可以審批 815 萬元（不包含 15 萬元）的采購單，董事長可以審批 15-45 萬元（不包含 45 萬元）的采購單， 45萬元及以上的采購單就需要企業高層開會討 論決定。 PH公司架構師采用某種設計模式設計的類圖如圖 49 所示。第 1 題：

2、問題 1請用 350 字以內的文字指出該公司架構師所采用的設計模式的具體名稱、 設計意圖及其優缺點。參考答案：Chain of Responsibility（ 職責鏈 ） 模式可以在系統中建立一個鏈，這樣消 息可以在首先接收到它的級別處被處理， 或者可以定位到可以處理它的對象。 依 題意， 該企業的采購審批是分級 進行的 ，可以采用職 責鏈（Chain of Responsibility） 設計模式對該采購審批過程進行設計，設計后得到的類圖如圖 49 所示。Chain of Responsibility（職責鏈 ） 模式的設計意圖是，使多個對象都有機會處理請求， 從而避免請求的發送者和接收者之

3、間的耦合關系； 將這 些對象連成一條鏈， 并沿著這條鏈傳遞該請求， 直到有一個對象處理它為止。 換 而言之，其目的是為了將一個請求發送給一個對象集合，對象被組織成一條鏈， 而負責處理該請求的對象將獲取請求消息并加以處理， 其余對象則僅僅負責將該 請求消息按照責任鏈的順序傳遞到下一個對象。 因此責任鏈模式的關鍵在于組織 不同的對象成為一條鏈并傳遞消息。 根據題干給出的不同層次主管人員的審批額 度“主任： 5萬元以下，副董事長： 5萬元 10萬元，董事長： 10萬元50萬 元，開會討論： 50 萬元及以上”，對象在職責鏈中的順序應該為： Director Vicepresident Preside

4、n CongressMeeting 。由于主任的審批額度最小， 因此 審批的請求應該從主任 （Director） 開始。 Chain of Responsibility 模式有 以下一些優點和缺點。 （1） 降低了耦合度。該模式使得一個對象無須知道是 其他哪一個對象處理其請求。對象僅需知道該請求會被“正確”地處理。接收者 和發送者都沒有對方的明確的信息， 且鏈中的對象不需要知道鏈的結構。 結果是， 職責鏈可簡化對象的相互連接。 它們僅需要保持一個指向其后繼者的引用， 而不 需要保持它所有的 候 選接受者 的 引用。 (2) 增加了給 對象指定責 任 (Responsibility) 的靈活性。

5、當在對象中分派職責時， 職責鏈給出更多的靈活性。 可以通過在運行時刻對該鏈進行動態的增加或修改來增加或改變處理一個請求 的那些職責。可以將這種機制與靜態的特例化處理對象的繼承機制結合起來使用。(3) 由于在一個類中產生的事件可以被發送到組成中的其他類處理器上，因此類 的集合可以作為一個整體。 (4) 不保證被接受。既然一個請求沒有明確的接 收者，那么就不能保證它一定會被處理該請求可能一直到鏈的末端都得不到 處理。一個請求也可能因為該鏈沒有被正確配置而得不到處理。詳細解答： 第 2 題： 問題 2請用 300 字以內的文字指出該公司架構師所采用的設計模式的適用性，以 及圖 65 中需要考慮哪些實

6、現問題 ?參考答案：在以下情況中，應該使用 Chain of Responsibility模式。 (1) 多個對象可以處理一個請求，而其處理器卻是未知的。 (2) 想要在不指定確切的請 求接收對象的情況下，向幾個對象中的一個發送請求。 (3) 可以動態地指定 能夠處理請求的對象集等。 依題意，在圖 49 中，需要考慮以下一些職責 鏈模式實現問題。 (1) 實現后繼者。鏈有兩種方法可以實現后繼者鏈：定 義新的鏈接 ( 通常在類 Approver 中定義，但也可由類 Director 、類 Vicepresident 類 Presiden 和類 Congress 來定義 ) ；使用已有的鏈接。通常

7、，可使用已有的對象引用來形成后繼者鏈。 例如，在一個部分一整體層次結構中， 父構件引 用可定義一個部件的后繼者， 窗口組件 (Widget) 結構可能早已有這樣的鏈接。 在 Composite 模式中更詳細地討論了父構件引用。 當已有的鏈接能夠支持所需的鏈 時，完全可以使用它們。這樣就不需要明確定義鏈接，而且可以節省空間。但如 果該結構不能反映應用所需的職責鏈，那么就必須定義額外的鏈接。 (2) 連 接后繼者。 如果沒有已有的引用可定義一個鏈， 那么就必須自己引入它們。 這種 情況下類 Approver 不僅定義該請求的接口，通常也維護后繼鏈接。這樣類 Approver 就提供了 Approv

8、erRequest 的缺省實現， ApproverRequest 向后繼者 ( 如果有的話 ) 轉發請求。如果類 Director 的子類對該請求不感興趣，它不需要 重定義轉發操作，因為它的缺省實現進行無條件的轉發。 (3) 表示請求。可 以用不同的方法表示請求。 最簡單的形式， 請求是一個硬編碼的 (hard-coded) 操 作調用。這種形式方便而且安全，但只能轉發 Approver 類定義的固定的一組請 求。 另一選擇是使用一個處理函數，這個函數以一個請求碼 ( 如一個整型常 數或一個字符串 ) 為參數。這種方法支持請求數目不限。唯一的要求是發送方和 接受方在請求如何編碼問題上應達成一致

9、。 該方法更為靈活， 但它需要用條件語 句來區分請求代碼以分派請求。另外，無法用類型安全的方法來傳遞請求參數， 因此它們必須被手工打包和解包。 顯然，相對于直接調用一個操作而言它不太安 全。 為解決參數傳遞問題，可以使用獨立的請求對象來封裝請求參數。 Request 類可明確地描述請求，而新類型的請求可用它的子類來定義。這些子類可定義不同的請求參數。處理者必須知道請求的類型 ( 即它們正使用哪一個 Request 子類 ) 以訪問這些參數。為標識請求， Request 可定義一個訪問器 (accessor) 函數以返回該類的標識符。 或者， 如果實現語言支持的話， 接受者可 使用運行時的類型信

10、息。 (4) 在 Smalltalk 中自動轉發。你可以使用 Smalltalk 中的 doseNotUnderstand 機制轉發請求。沒有相應方法的消息被 doseNotUnderstand 的實現捕捉 (trap in) ，此實現可被重定義，從而可向一個 對象的后繼者轉發該消息。 這樣就不需要手工實現轉發； 類僅處理它感興趣的請 求，而依賴 doesNotUnderstand 轉發所有其他的請求。詳細解答：第 3 題： 問題 3 結合你的系統架構經驗，請用 300 字以內的文字指出 Command模式、Observer 模式、 Chain ofResponsibility 模式和 Med

11、iator 模式在發送者和接 收者解耦方面的區別。參考答案： 詳細解答：試題二閱讀以下關于某平安城市工程視頻監控系統架構的敘述， 根據要求回答問題。 說明 某城市為滿足治安管理、城市管理、交通管理和應急指揮等需求，決定 在城市的所有進出路口、客貨運場所、主要道路路口、重要公共場所、商業密集 區域，以及治安案件高發區等地進行視頻監控， 并通過網絡建立完善的社會治安 視頻監控系統，即實施“平安城市工程” ，實現視頻監控信息資源的整合與共享。平安城市工程的網絡接入如圖 4-10 所示。所有監控點的攝像機通過運 營商提供的線路接入平安城市網絡， 公安局的監控體系有三級結構， 分別為市局、 分局和派出所

12、監控中心。 運營商傳輸網絡負責所有視頻監控信號的傳輸、 存儲和 轉發，由傳輸設備、網絡設備和存儲設備等構成。平安城市工程規范中規定， 實時調閱視頻流從采集至播放的時間延遲不 得大于 1s。第 4 題： 問題 1圖 4-11 為某派出所與其管轄的一個監控點之間的設備連接圖， 表4-12 為圖中各設備產生的延遲情況。其中，核心交換機 3 號插槽上安裝 8 端口 GBIC千兆以太網模塊 WS-X6408A(8p ort GIGABITETHERNE，T)用于與各行政區匯 聚交換機互連；核心交換機 4 號插槽上安裝 16 端口 GBIC 千兆以太網模塊 WS- 6516-GBIC（16 port GI

13、GABIT ETHERNET），負責連接平安城市工程中所有的流媒 體服務器、存儲服務器等設備，端口 1 和端口 2 連接兩臺流媒體服務器，端口 3 和端口 4 連接兩臺存儲服務器。 請計算該派出所與其管轄的一個監控點的 實時視頻調閱延遲， 并指出是否符合平安城市工程規范。 若符合規范， 請簡要說 明理由；若不符合規范， 在不改變編解碼器和流媒體服務器產品的情況下， 請給出可能的優化方案。參考答案：依題意，基于圖 4-11 所示的視頻監控設備連接圖和表 412 所示的各種設 備產生的延遲參數可以做出如下分析， 當某派出所的控制計算機發出調閱其管轄 的某個監控點實時視頻的指令后， 該調閱指令將被流

14、媒體服務器接收并進行相關 處理，流媒體服務器將向所指定監控點的攝像機發出采集視頻流的操作命令； 攝 像機所采集的模擬視頻流信號經編碼器進行模 / 數（A/D） 轉換并封裝成相應的以 太數據幀送入視頻監控網絡的接入層交換機 （ 約延遲 350ms），之后該視頻流數據 幀將經過接入層交換機和匯聚層交換機的轉發 （分別延遲了 30ms和 30ms），將到 達核心交換機 3 號插槽光纖接口模塊； 由于流媒體服務器是連接在核心交換機 4 號插槽的端口 1 和端口 2，因此該視頻流數據幀從 3 號插槽光纖接口模塊轉發到 4 號插槽千兆以太接口模塊時，將有 10ms 延遲時間；該視頻流數據幀經流媒體 服務器

15、進行相關處理后 （約延遲80ms），將由4號插槽的端口 1（或端口 2）轉發給 連接在端口 3（ 或端口 4） 的存儲服務器進行數據存儲操作，這一過程存在有數據 幀模塊內端口間 5ms轉發延時和 250ms視頻存儲延遲時間； 當從存儲服務器調閱 相應的視頻流數據時 （ 約延遲 100ms），該視頻流數據幀將從 4 號插槽的端口 3（或 端口 4）轉發到 3 號插槽光纖接口模塊 （約延遲 10ms），然后分別經匯聚層交換機 和接入層交換機轉發后 （分別延遲了 30ms和 30ms），送至解碼器進行數據幀的拆 封并通過數 / 模（D/A） 轉換形成監視器可接收的模擬視頻流信號 （ 約延遲 350m

16、s）。 以上分析過程中，各設備延遲情況的示意圖如圖 4-20 所示。因此某派出所與其 管轄的一個監控點的實時視頻調閱延遲 t=350+30+30+10+80+5+250+100+10+30+30+350=1275ms=1.275。s由于平安城市工程規范中規定， 實時調閱視頻流從采集至播放的時間延遲不 得大于 1s，由于1.275s 1.0s ，因此圖 4-11 所產生的實時視頻調閱延遲不符合 平安城市工程規范。若不能改變編 / 解碼器和流媒體服務器產品，即保留實時視 頻調閱延遲 t 中 350ms、80ms和 350ms 3 個參數的情況下， 則可以從優化其他轉 發延時參數入手進行分析，在不考

17、慮經費限制的情況下，可能的優化方案如下。（1）改進流媒體服務器視頻流處理軟件的工作模式，即當視頻流數據幀經流媒體 服務器進行相關處理后， 采取并發 （或并行）或組播的工作模式將處理后的數據幀 一路送至存儲服務器進行數據存儲操作， 同時另一路數據幀直接送至核心交換機 的相應輸出端口。 采取這一優化措施， 可能節省約 350ms轉發延時 （ 即節省 250ms 視頻存儲延遲時間和 100ms視頻調閱轉發延時 ）。（2） 將核心交換機 4 號插槽的 GBIC干兆以太網模塊升級 （或更換）成至少擁有 4 個千兆光纖接口和 16個 千兆以太端口的模塊，由這 4 個干兆光纖接口分別連接圖 4-11 中的兩

18、臺匯聚交 換機。若 4 號插槽中有空余的千兆光纖接口， 則可將兩臺匯聚交換機上連光纖由 原來插接在 3 號插槽變更為插接在 4 號插槽。采取這一優化措施，將節省 10ms 轉發延時，即節省圖 4 11中兩次的核心交換機數據幀模塊間的 10ms轉發延時， 但同時也引入了兩次的數據幀模塊內端口間的 5ms轉發延時。（3） 在光纖傳輸距離允許且匯聚交換機有多余光纖接口的情況下， 可將編碼器和解碼器直接連 接至各自的匯聚交換機。采取這一優化措施，若編 / 解碼器均直接上連至匯聚交 換機，則將節省 60ms轉發延時；若只將一側的編碼器 （或解碼器 ）直接上連至匯 聚交換機， 則將節省 30ms轉發延時。

19、（4） 優化存儲服務器對視頻流存儲和調閱轉發的處理機制 （例如，采用 RAID10或 RAID0技術，把連續的數據分散到多個 磁盤上存取） ，或者升級存儲服務器的相關硬件 （如CPU、內存和硬盤等 ），再或者 更換成具有更高數據存取性能的存儲服務器產品， 從而減少視頻流存儲延時和調 閱轉發延時。詳細解答： 第 5 題： 問題 2該平安城市工程視頻監控系統可以提供實時監控、存儲和隨時調看 CIF 格 式（352288）和 D1格式 （720 576）分辨率的圖像，支持： MPEG-、2 MPEG-4和 H.264 等編碼格式。（1） 該城市某行政區內預計共有監控點 600 個，如果保存的是 CI

20、F 格式的圖 像，碼流為 512kbps，請計算每小時保存該行政區內全部監控點視頻流需要多 大的存儲空間 （B 或 GB）。 （請將計算結果保留小數點之后 3 位數）。如果保存的是 D1 格式的圖像，碼流為 2048kbps，請計算每小時保存該行 政區內全部監控點視頻流需要多大的存儲空間 （B或 GB）。（2）全部監控視頻流信息保存在 IP SAN設備 S2600中， S2600控制框（ 雙 控， 220V交流， 4GB內存， 8xGE iSCSI 主機接口，磁盤數量 12個/ 框，最大支 持附加 7 個磁盤擴展框 ） 。假設在本項目中采用 SATA1.5TB 7.2KRPM硬盤，在 IP S

21、AN 配置的 RAID組級別為 RAID10。若該視頻監控系統實施時，圖像格式采用了 CIF，碼流為 512 kbps ，請計 算保存該行政區內全部監控點 30天視頻流需要的存儲空間 （B、GB或 TB），并計 算出保存 30 天視頻流至少需要的硬盤數，以及至少需要配置的 $2600 控制框數 量。參考答案：詳細解答： 第 6 題： 問題 3 該平安城市工程視頻監控系統的一些關鍵的應用系統，采用雙機冗余熱備 的方式進行保護。請用 200 字以內的文字，說明雙機冗余熱備方式主要解決的是系統運行中 的哪些問題，以及在選擇雙機冗余熱備產品時通常需要考慮哪些問題 ?參考答案：容錯技術是指在一定程度上容

22、忍故障的技術，也稱為故障掩蓋技術 (Fault Masking) 。容錯主要依靠冗余設計來實現， 以增加資源換取可靠性。 由于資源的 不同，冗余技術分為硬件冗余、軟件冗余、時間冗余和信息冗余。也可以是元器 件級、部件級和系統級的冗余設計。 采用雙機冗余熱備方式， 當本地某個系 統發生故障時， 系統能夠自動快速地切換到正常的系統， 通過本地故障恢復確保 系統持續提供服務。 在這種方案中， 需采用雙機熱備份軟件， 用于提高服務器的 可靠性。可選用離線數據備份及災難恢復軟件， 保證數據的可靠性。 還需要用到 磁帶機、磁帶庫和磁盤陣列等硬件設備。 雙機熱備份方式的兩臺服務器都處 于熱機狀態，如果一臺服

23、務器壞了，另一臺服務器可以將所有的業務接管過來。 它有兩種工作方式： Online 方式兩臺服務器都在工作，分別擔負不同的任 務，均衡負載。缺點是成本大，管理難； Standby 方式備份機不工作，只是 監測作業機的工作狀況。 缺點是服務器之間的切換時間較長。 目前有許多不 同廠家提供雙機冗余熱備的產品。 在選擇雙機冗余熱備產品時， 通常需要考慮的 因素有：雙機熱備產品適用的規模； 支持的操作系統； 支持的數據庫系統； 對正常業務系統的性能影響；提供的圖形用戶界面 (GUI) 管理工具功能易用 性；能夠完全實現多應用多級切換 (應用級切換 ) ，適用于多種應用并存的系統， 某一應用的切換可以不

24、對其他應用產生影響； 集中管理配置能力； 遠程監控 和管理能力；切換速度；磁盤管理方面的功能等。詳細解答：試題三閱讀以下關于 UML建模技術在某前臺銷售子系統的應用說明， 根據要求回答 問題。 說明 某超市管理系統的前臺銷售子系統以最基本的方式處理銷售業務。 系統 的功能需求如下。(1) 記錄每種商品的編號、單價和現有數量。(2) 為顧客選購的商品計價、收費，并打印清單。(3) 幫助商家找出哪種商品將脫銷，從而及時補充貨源。(4) 隨時按上級系統的要求報告當前的款貨數量、增減商品的種類或修改商品定價。(5) 交接班時結算貨款數目和商品數目。每臺收款機可以處理任何數目的銷售事件， 但一個銷售事件

25、只能由一臺 收款機處理。 每個銷售事件從收款機響應收款人員的指令開始， 先向商品發送檢 索請求消息來查找將被出售的商品。 如果該商品的數量少于下限， 則向供貨員發 送缺貨登記消息。 每名供貨員可以提供一種或多種商品， 同一品牌的商品只能由 一位供貨員來提供。 接著收款機發送計價和入賬消息請求售出操作， 再由銷售事 件發送記賬消息給相應的賬冊， 并控制流程返回收款機等待下一次銷售操作。 每 本銷售賬冊可以記錄任何數目的銷售事件， 但一個銷售事件只能由一本銷售賬冊 記錄。該銷售子系統采用面向對象方法開發，系統中的類及類之間的關系用 UML類圖表示，圖 4-12 是該系統類圖中的一部分；系統的動態行

26、為采用 UML序 列圖表示，圖 4 13 是銷售事件部分的序列圖。第 7 題： 問題 1請將圖 412 中的類商品、類特價商品和類計量商品三者之間的聯系補充參考答案：在 UML類圖中，“”表示其相連的兩個類之間存在泛化 (generalization) 關 系。這種關系描述了一般事物與該事物中特殊種類之間的關系， 子用例是父用例 的一種特殊形式， 子用例繼承了父用例所有的結構、 行為和關系， 還可以增加或 者覆蓋父用例的行為。子用例可以出現在父用例出現的任何位置。 在圖 412 所示的類圖中，類特價商品和類計量商品是類商品的子類，它們將繼承類商 品的所有屬性和操作， 并且又有自己特殊的屬性和操

27、作。 因此這三者之間的聯系 是泛化關系，如圖 4-21 所示。詳細解答：第 8 題： 問題 2 識別關聯的多重度是面向對象建模過程中的一個重要步驟。請根據說明中 給出的描述，將圖 4-12 中(1) (8) 空缺處的內容填寫完整。參考答案： 由題干描述中給出的關鍵信息“每臺收款機可以處理任何數目的銷售事 件” 和常識可知， 每個超市有多臺收款機， 每個銷售事件可能與一種或多種 商品發生聯系， 商品可以到任何一臺收款機付款， 因此收款機與商品之間存在多 對多(m:n)的關系，即(1) 、(2) 空缺處所填寫的內容均是“ 1*”。由題干中關鍵信息 “每名供貨員可以提供一種或多種商品， 同一品牌的商

28、品只能由一位 供貨員來提供” 可知，商品與供貨員之間存在多對一 (m:1) 的關系， 因此(3) 空缺 處所填寫的內容是“ 1* ”，(4) 空缺處所填寫的內容是“ 1”。由題干中關鍵信息“每臺收款機可以處理任何數目的銷售事件， 但一個銷售事件只能由一臺 收款機處理” 可知，收款機與銷售事件之間存在一對多 (1:n) 的關系， 因此(5) 空 缺處所填寫的內容是“ 1”，(6) 空缺處所填寫的內容是“ 1 *”。由題干中關鍵信息“每本銷售賬冊可以記錄任何數目的銷售事件， 但一個銷售事件只能由 一本銷售賬冊記錄”可知，銷售事件與賬冊之間存在多對一 (n:1) 的關系，因此 (7) 空缺處所填寫的

29、內容是“ 1*”， (8) 空缺處所填寫的內容是“ 1”。較完整的前臺銷售子系統類圖如圖 4-22 所示。詳細解答：第 9 題： 問題 3請使用 說明 中給出的詞語，將銷售事件序列圖中的 (A) (D)空缺處的內 容填寫完整。參考答案： 由題干給出的關鍵信息“記錄每種商品的編號、單價和現有數量”和“如 果該商品的數量少于下限， 則向供貨員發送缺貨登記消息” 可知，類商品有 5 個 屬性，即編號、名稱、單價、數量和下限。 由題干中關鍵信息“幫助商家 找出哪種商品將脫銷，從而及時補充貨源”、 “接著收款機發送計價和入賬消息 請求售出操作”和“先向商品發送檢索請求消息來查找將被出售的商 品”可知，類

30、商品有 3 個操作，即檢索、補充和售出。 由題干中關鍵信 息“隨時按上級系統的要求報告當前的款貨數量、 增減商品的種類或修改商品 定價”可知，類商品還具有兩個操作，即種類增刪和價格更新。 由題干中給 出的關鍵信息 “每個銷售事件從收款機響應收款人員的指令開始， 先向商品發送 檢索請求消息來查找將被出售的商品” 可知， 收款機將向商品對象發送 “檢 索”這一觸發消息，因此 (A) 空缺處所填寫的內容是“檢索”。由題干中關鍵信息“接著收款機發送計價和入賬消息請求售出操作， 再由銷售事件發送記賬 消息給相應的賬冊”可知，收款機將向銷售事件發送“計價”、“入賬”觸 發消息，其中，“入賬”消息將被銷售事

31、件轉變為“記賬”消息送給賬冊對象， 因此(B) 空缺處所填寫的內容是“計價”， (c) 空缺處所填寫的內容是“記賬”。由題干中關鍵信息 “再由銷售事件發送記賬消息給相應的賬冊， 并控制流程返回 收款機等待下一次銷售操作” 可知，記賬操作完成時即可表示本次銷售事件入賬 操作結束，賬冊對象將發送“入賬”結束消息給收款機，以觸發收款機等待下一 次銷售操作，因此 (D) 空缺處所填寫的內容是“入賬”。詳細解答： 第 10 題： 問題 4頂層架構是 UML分析與設計的階段成果的承載體。 UML包圖是表示頂層架 構的適當機制。結合你的系統架構設計經驗，請列舉 3 種常見的頂層架構模 式，并簡要說明每種架構

32、模式的特點。參考答案： 頂層架構的主要目的是為后續的分析和設計活動建立一種結構和分劃， 以便 開發人員在不同的開發階段， 以及同一開發階段的不同開發人員， 能夠聚焦于系 統的不同部分。 頂層架構是分析和設計的階段成果的承載體。 隨著開發過程的推 進，框架中的內容不斷豐富和翔實，最終演進為完整的面向對象軟件結構。 UML 包圖是表示頂層架構的適當機制。 建立軟件系統頂層架構的基本方法是， 結 合實際需求，從既往的架構設計經驗模型中選取適當者， 再進行微調或局部改造。 目前有如下幾種主要的架構模式。 (1) 流程處理模式。流程處理系統以算法 和數據引進中心， 其系統功能由一系列的處理步驟構成， 相

33、鄰的處理步驟之間以 數據流通管道相互連接。 該模式僅適合于采用批處理方式的軟件系統， 不適合于 交互式系統。 (2) 客戶/ 服務器模式。客戶端負責用戶輸入和處理結果的呈 現，服務器端則負責后臺的業務邏輯處理。 (3) 模型視圖控制器 (MVC)模 式。該模式將整個軟件系統劃分為模型、 視圖和控制器 3 個部分。模型負責維護 并保存具有持久性的業務數據， 實現業務處理功能， 并將業務數據的變化情況及 時通知視圖；視圖負責呈現模型的業務數據， 響應模型變化通知， 更新呈現形式， 并向控制器傳遞用戶的界面動作； 控制器負責將用戶的界面動作映射為模型中業 務處理功能并實際調用之， 然后根據模型返回的

34、業務處理結果選擇新的視圖。 MVC 模式特別適合于分布應用軟件，尤其是 Web應用系統。(4) 分層模式。該模式將整個軟件系統分為若干層次， 最頂層直接面向用戶提供軟件系統的操作界面， 其余各層為緊鄰其上的層次提供服務。 層次劃時分的主要原則是： 較易變化的軟 件部分(例如用戶界面、 與業務邏輯緊密相關的部件 )置于較高層次， 較穩定的軟 件部分 (例如公共的技術服務部件 )則位于較低層次；每一層次盡量只訪問其緊鄰 下層提供的服務，避免越級訪問，尤其要避免逆向訪問 ( 上層模塊為下層模塊提 供服務 ) ；在許多情況下，可以將目標軟件系統的外部接口置入較低層次，目標 軟件系統其余部分對外部系統的

35、訪問或操作均通過這些外部接口所提供的公共 服務來完成。分層模式可以有效地降低軟件系統的耦合度， 因此其應用十分普遍。詳細解答：試題四閱讀以下關于體系結構設計的敘述，根據要求回答問題。 說明 某大中型電子商務公司的主要業務是在線購物，包括書籍、服裝、家電 和日用品等。 隨著公司業務規模不斷增大， 公司決策層決定重新設計并實現其網 上交易系統。 PH 軟件公司承擔了該項目軟件開發任務，負責系統開發的杜工和 趙工分別給出了兩種不同的設計方案，分別如圖 414和圖 415所示。公司的架構師和開發者針對這兩種設計方案，從服務器負載情況、業務邏輯 的分離性、系統可靠性， 以及實現簡單性等方面進行討論與評估

36、， 綜合考慮最終 采用了趙工給出的方案。第 11 題： 問題 1結合你的系統架構設計經驗，請分析比較杜工、趙工兩種方案的優點和不 足，將表 4-13 中(1) (6) 空缺處的內容填寫完整。參考答案：本問題主要考查體系結構設計需要注意的問題。 根據圖 414和圖 415給 出的拓撲結構可知，圖 4-14 給出的體系結構代表了一種典型的基于數據庫服務 器的動態內容發布結構， 這種結構在服務器端設置了一臺 Web服務器和一臺數據 庫服務器。在這種體系架構下， 用戶工作界面是通過 WWW瀏覽器來實現， 極少部 分事務邏輯在前端 (Browser) 實現，但是主要事務邏輯在Web 應用服務器端(Ser

37、ver) 實現。Web服務器通過應用程序的支持 ( 通常采用 ASP、JSP等腳本語言， 比較簡單 ) ，就可以給用戶提供動態的信息服務，通過定制頁面模板，添加到后 臺數據庫中的信息可以及時發布給客戶。 這種將瀏覽器與 Web服務器、應用服務 器三者分開的架構風格， 可跨平臺操作， 具有良好的開放性和可擴充性， 便于系 統升級、擴展和維護。但是，在這種架構下， Web服務器需要同時負責業務邏輯 的處理和數據庫訪問， 負載很較重； 業務邏輯代碼和其他程序代碼全部在 Web服 務器中，不能做到業務邏輯代碼與其他代碼分離， 且其中任何一個環節出錯， 都 會導致 Web服務器宕機，系統可靠性較差。圖

38、4-15 給出的是一種分布式的Web應用架構。與圖 414 的架構風格相比，在 Web服務器和后臺數據庫服務器 之間增加了一層應用服務器。 這是一種比較先進的架構模式， 通過 Web服務器處 理用戶請求，應用服務器處理業務邏輯與數據庫訪問， 負載較為均衡。 但是這種 架構模式需要將腳本語言與面向對象編程語言相結合， 相對復雜。 由于增加了中 間層應用服務器， 因此可以將業務邏輯和數據庫連接等放置到中間層上， 不但減 輕了 Web應用服務器的負擔， 而且還可以做到業務邏輯代碼與其他程序代碼之間 的分離。多個應用服務器的存在也可以提高訪問性能，并增加系統的可靠性。10整理以上分析內容，可得到如表

39、414 所示的兩種架構方案各自的優點和不足詳細解答：第 12 題： 問題 2如何架構高性能 Web應用系統是 PH公司項目組面臨的另一個問題。結合你 的系統架構設計經驗，請用 200 字以內的文字列舉兩個主要影響著 Web應用系 統服務端執行效率的技術因素，并針對每個因素提出相應的解決方案以提高系 統性能。參考答案：本問題主要考查 Web應用系統的性能優化問題。 性能是 Web應用系統的一個 重要質量屬性。主要有如下一些重要的技術因素影響著 Web應用系統服務端的執 行效率。 (1) 數據庫的連接與銷毀。 可以采用數據池的方式緩存數據庫鏈接， 實現數據庫鏈接復用，提高系統的數據訪問效率。 (2

40、) 構件或中間件的加載 與卸載。可以采用分布式對象池的方式緩存創建開銷大的對象，實現對象復用， 提高效率。 (3) 線程的創建與銷毀。可以采用線程池的方式緩存已經創建的 線程，提高系統的反應速度。詳細解答： 第 13 題： 問題 3REST(REpresentational State Transfer) 是從幾種基于網絡的架構風格衍 生出來的一種混合架構風格。采用這種方法設計的 Web應用系統能夠結合 REST 風格和面向服務思想的優點。結合你的系統架構設計經驗，請用300 字以內的文字簡要說明與傳統的 Web服務相比，采用 REST服務構建的 Web應用具有哪些 優勢和不足。參考答案：RE

41、ST(REpresentational State Transfer) 是從幾種基于網絡的架構風格衍 生出來的一種混合架構風格，它是目前因特網的核心架構風格。REST風格中的特點是客戶端 / 服務器、無狀態、緩存、統一接口、分層系統和按需代碼。 REST 組件通過以一種數據格式轉移資源的表述進行通信， 可以基于接收者的能力和期 待的內容，以及資源的性質動態地選擇不同的表述。基于 REST服務 (RESTfulService) 的 Web應用系統設計任務主要包括識別并設計 REST風格的服務和采用 面向服務的思想進行 REST服務集成。采用這種方法設計的 Web應用系統能夠結11合 REST風格

42、和面向服務思想的優點，近年來受到了廣泛的關注。與傳統的Web服務相比，REST服務主要有以下幾點優勢。(1)REST 服務基于 W3C/IETF的標準與規范 (包括 HTTP、XML、URI 和 MIME等) ，其實現技術簡單且成熟。 (2)REST 服務基于 URI 和超鏈接技術， 不需要通過集中式的服務信息倉庫即可發 現服務資源。(3)REST服務支持緩存， 具有無狀態的特性， 這些使得 REST服務能夠支持大量客戶端，構建的應用系統具有較強的伸縮性。(4)REST 服務基于輕量級的 Web框架，僅僅需要基本的開發工具支持， 構建過程簡單且成本較 低。 (5)REST 服務的測試相對簡單，

43、采用瀏覽器即可完成服務功能測試。 與傳統的 Web服務相比， REST服務主要存在如下不足。(1)REST服務倡導的REST風格與實際實現尚存在一定差距。例如高層 REST服務倡導使用 GET、PUT、 POST和 DELETE所有 4 個統一接口，在 REST實現部分通常只能采用 GET和 POST 接口，因為大多數的代理和防火墻會屏蔽其他接口； 并且 XHTML表單中只能使用 GET和 POST接口。(2)REST 服務要求所有的輸入參數都必須在 URI中傳遞，這樣會產生對參數容量大小的限制 ( 目前的大小是 4KB)。如果超出該數量，會導 致 HTTP協議錯誤(錯誤代碼 414：Requ

44、estURI too long) 。 (3) 在 URI中 表達復雜類型的參數比較困難，且目前對 uRj 中的參數不存在一種公認的編組 (marshalling) 和解編 (un-marshalling) 方法。詳細解答：試題五 閱讀下列關于軟件產品線方面的敘述，回答問題。 說明 A 公司是一家中等規模的計算機企業，專門從事網絡安全防護軟件系統 的開發。從最初僅開發基于 Windows的個人防火墻產品開始， 現在已經延伸到基 Linux 、Windows系列、Mac操作系統的個人防火墻、 企業防火墻、入侵檢測系統、 病毒掃描系統， 以及安全掃描系統等多種產品。 公司原來的產品都是一個一個地 開

45、發，為每個軟件對應地組織一個項目組。為了適應快速變化的市場，降低開發成本，公司想引入產品線方法。然 而，軟件產品線方法涉及了一個軟件開發企業的多個產品， 所以，公司的王總決 定在弄清楚以下 3 個問題之后再做決定： 首先是本公司的業務范圍是否適合使用 產品線方法， 其次是如何在原有產品的基礎上建立產品線， 最后是成功實施產品 線的主要因素。第 14 題： 問題 1 結合你的系統架構設計經驗，請用 200 字以內的文字簡要說明 A公司是否 適合采用產品線方法，并說明你的理由。參考答案：這是一道要求讀者根據具體應用環境，分析軟件產品線 (Software Product Line) 的適用性的綜合

46、理解題。 本試題的解答思路如下。 (1) 軟件產品線代表 了一種強勁的軟件開發范例， 它可使軟件生產在時間、 成本和質量方面獲得顯著 改善。它是一個十分適合專業的軟件開發組織的軟件開發方法， 能夠有效地提高12 軟件生產率和質量， 縮短開發時間，降低總開發成本。同時，它也是一個新興的、 多學科交叉的研究領域，研究內容和范圍都相當廣泛。 (2) 卡耐基梅隆大學 軟件工程研究所 (CMU/SEI)對產品線和軟件產品線的定義是，產品線是一個產品 集合，這些產品共享一個公共的、 可管理的特征集， 這個特征集能滿足選定的市 場或任務領域的特定需求。 這些系統遵循一個預描述的方式， 在公共的核心資源 (Core Assets) 基礎上開發的。 這一定義體現了軟件產品線的特征。 (3) 軟件 產品線開發有：過程驅動；特定領域；技術支持