高級系統(tǒng)架構(gòu)設(shè)計師下午試題(Ⅰ)-4-真題(與解析)-交互

高級系統(tǒng)架構(gòu)設(shè)計師下午試題(Ⅰ)-4(總分187.5,做題時間90分鐘)試題一1.企業(yè)應用集成(EnterpriseApplicationIntegration是每個企業(yè)都必須要面對的實際問題。企業(yè)服務總線(EnterpriseServiceBus，ESB)一種體系結(jié)構(gòu)模式，支持通信各方間的服務交互的虛擬化和管理。它充當面向服務架構(gòu)(Service-OrientedArchitecture，SOA)中服務提供者和請求者之間的連接服務的中間層。與傳統(tǒng)的EAI技術(shù)相比，ESB用總線式的體系結(jié)構(gòu)集成多個應用系統(tǒng)，基于開放標準實現(xiàn)其內(nèi)部核心功能，并支持快速加入新的應用到已有的集成環(huán)境中。請圍繞“ESB模式在企業(yè)應用集成中的應用”論題，依次從以下3個方面進行論述。1．要敘述你參與實施的企業(yè)應用集成項目包括業(yè)務背景、組織結(jié)構(gòu)、現(xiàn)有應用系統(tǒng)的分布，以及采用的技術(shù)等)，以及你所擔任的主要工作。2．詳細論述的核心功能和典型結(jié)構(gòu)；列舉目前流行的ESB品；指出你參與的項目所選擇的ESB產(chǎn)品，并從ESB心功能的角度說明選擇該產(chǎn)品的理由。3．闡述在使用技術(shù)進行應用集成過程中所遇到的問題及解決辦法，簡要敘述你進一步應用ESB模式的有關(guān)設(shè)想。SSS_TEXT_QUSTI分值:18.75答案:1．簡要介紹你參與規(guī)劃、設(shè)計、實施和管理的企業(yè)應用集成項目的基本情況(包括業(yè)務背景、組織結(jié)構(gòu)、現(xiàn)有應用系統(tǒng)的分布和采用的技術(shù)等，簡要說明自己在該項目中的角色、所承擔的主要任務及開展的主要工作。論文敘述自己參與管理和實施的企業(yè)應用集成項目應有一定的規(guī)模，自己在該項目中擔任的主要工作應有一定的分量。2．企業(yè)服務總線(EnterpriseServiceBus，ESB)是由中間件技術(shù)實現(xiàn)的支持面向服務架構(gòu)(SOA)的基礎(chǔ)軟件平臺，支持異構(gòu)環(huán)境中的服務以基于消息和事件驅(qū)動模式的交互，并且具有適當?shù)姆召|(zhì)量和可管理性。技術(shù)的基本思想是，提供一種標準的軟件底層架構(gòu)，各種程序組件能夠以服務單元的方式“插入”到該平臺上運行，并且組件之間能夠以標準的消息通信方式來進行交互。換而言之，ESB是傳統(tǒng)中間件技術(shù)與XML服務等技術(shù)結(jié)合的產(chǎn)物。ESB是一個集成平臺，將現(xiàn)有的IT設(shè)施和應用系統(tǒng)暴露為服務。由于ESB基于開放標準，企業(yè)的遺產(chǎn)系統(tǒng)使用的私有技術(shù)能夠基于開放和現(xiàn)代的技術(shù)例如Web服務和消息機制等)暴露為服務。1)其核心功能包括位置透明性、傳輸協(xié)議轉(zhuǎn)換、消息轉(zhuǎn)換、消息路由、消息增強、安全，以及監(jiān)控和管理7項內(nèi)容(1)位置透明性(LocationTransparency)。位置透明性是指當一個服務消費者與一個服務提供者通過ESB進行通信時，服務消費者不需要知道服務提供者的實際位置，這意味著服務消費者與服務提供者之間是解耦合的。

(2)傳輸協(xié)議轉(zhuǎn)換(TransportProtocolConversion)。當服務請求者與服務提供者采用不同的傳輸協(xié)議時，ESB能夠?qū)⒒谳斎雮鬏攨f(xié)議格式的數(shù)據(jù)轉(zhuǎn)換為不同輸出傳輸協(xié)議格式的數(shù)據(jù)。(3)消息轉(zhuǎn)換(MessageTransformation)在服務請求者和服務提供者進行交互時，ESB基于開發(fā)標準(XLST和XPath)提供了將消息從一種格式轉(zhuǎn)換為另外一種格式的能力。(4)消息路由(MessageRouter)在實際的集成環(huán)境中，對于一個特定的輸入請求消息，可能有多個應用程序參與進來作為該消息傳遞的目標。能夠決定一個消息必須發(fā)送到哪些相關(guān)的應用程序中，處理這種邏輯的核心功能稱為消息路由。(5)消息增強(MessageEnhancement)在某些情況下，可能需要為請求數(shù)據(jù)添加額外的數(shù)據(jù)或轉(zhuǎn)換已有的數(shù)據(jù)，在這種情況下，應該提供對外部數(shù)據(jù)的訪問能力，支持用戶編寫客戶端代碼對數(shù)據(jù)進行訪問和處理。(6)安全(Security)必須支持對消息的授權(quán)和認證能力，如果輸入數(shù)據(jù)可能被惡意解析，還要提供加密能力。的安全包括消息的機密性、完整性和可用性等，支持不同的安全策略與方法。(7)監(jiān)控和管理(MonitorandManagement)。關(guān)注ESB的維護和管理能力。監(jiān)控與管理功能包含多個方面，例如對于消息層來說，其管理主要包括管理消息隊列，監(jiān)控消息大小和消息隊列的吞吐率等。對于服務，主要包括監(jiān)控每個服務是否啟動和運行，在每分鐘有多少調(diào)用請求，對于一個服務，有多少服務實例在運行等。(論文中只要給出以上7個核心功能中的5個即可)2)ESB提供了一個基于標準的松散應用耦合模式，在層次化的技術(shù)結(jié)構(gòu)中，ESB至少包含以下3層(1)總線接入層：通過這一層可以使用戶各種應用接入，使用ESB的各種服務。在這一層提供對多種主流應用的接入?yún)f(xié)議支持，如、JCA/J2C、NET和IBM/CICS等。同時考慮到一些客戶自己定制的應用與ESB的連接，在總線接入層提供了適配器服務。(2)核心層：提供多種企業(yè)服務總線所需的必要服務支持，在這一層除了提供總線基本服務(如分發(fā)/訂閱、隊列、安全服務和仲裁服務等)外，還提供了QoS的支持(如高可用性、確保消息傳輸?shù)?(3)微流程組合/拆分或定制路由層：這一層是側(cè)重在業(yè)務支持上。通過通用和標準的對象和服務模型，可以在這一層上定義可重用和基于業(yè)界標準的業(yè)務流程。3)目前流行的產(chǎn)品包括商業(yè)產(chǎn)品和開源產(chǎn)品兩類(1)商業(yè)產(chǎn)品的WebSphereESB、Oracle的OracleServiceBus(身是BEA的AquaLogicServiceBus)和微軟的Server等。(2)開源產(chǎn)品：、ApacheServiceMix、JBossESB、OpenESBWSO2等。(論文中只要給出以上產(chǎn)品中的個即可)4)結(jié)合項目實踐經(jīng)驗，說明你參與管理和實施的工程項目所采用的產(chǎn)品，然后圍繞7個核心功能，并結(jié)合企業(yè)應用集成項目的實際特點，論述選擇該ESB產(chǎn)品的原因，原因的描述要具有一定的廣度和深度，要客觀、適當。3．具體說明你參與管理和開發(fā)的項目中，使用技術(shù)進行應用集成時

所遇到的問題。這些問題包含但不限于以下內(nèi)容。(1)如何根據(jù)企業(yè)應用集成的需求選擇合適的產(chǎn)品?(2)如何根據(jù)企業(yè)的具體組織結(jié)構(gòu)確定集成系統(tǒng)的體系結(jié)構(gòu)，并據(jù)此設(shè)計系統(tǒng)的功能分布與物理拓撲結(jié)構(gòu)?(3)相關(guān)子系統(tǒng)之間的數(shù)據(jù)格式轉(zhuǎn)換問題。(4)針對具體業(yè)務編寫合適的處理邏輯并確定消息路由問題等。論述解決以上問題所采取的策略、具體辦法和步驟，以及它們對該工程項目后期的工作產(chǎn)生了哪些積極(或消極)的影響效果和存在的問題)。論文最后可以進一步討論你在該工程項目中獲得的與應用相關(guān)的幾點體會，以及在今后的工作過程中，如果碰到類似的開發(fā)項目你將如何應用這些經(jīng)驗或教訓。對需要進一步改進的地方，應有具體的著眼點，不能泛泛而談。4．論文寫作過程中值得關(guān)注的一些要點如下全書同)。(1)整篇論文要結(jié)構(gòu)合理、切中要害、陳述完整、言簡意賅、語言流暢、字跡清楚，切忌對知識點的堆積、長篇大論、言之無物。(2)選擇自己參與過的工程項目進行分析論述，所述項目切題真實，介紹清楚。(3)下午試卷Ⅱ是論述題目，問題中提到的中心內(nèi)容在題目的說明中都有所涉及。在答題時首先要冷靜并認真閱讀題目，找出和問題相關(guān)的知識點，確定考題的關(guān)鍵考點，這是答題的前提。(4)摘要是全文概括，千萬不要寫成引言。(5)圍繞論文主題，對所參與的項目進行科學敘述與評價，要有具體的著眼點，不能泛泛而談，盡可能從字里行間讓閱卷者體會到你的實際工作能力、業(yè)務水平和項目實踐經(jīng)驗。(6)在考試過程中應注意技巧，讓答題的思路最大限度地符合出題的思路，避免跑題，這樣容易得到閱卷老師的共鳴。(7)根據(jù)考生對所參與的項目中針對本論文主題的相關(guān)敘述與評價，可確定他(她)有無參與信息系統(tǒng)項目開發(fā)過程的實踐經(jīng)驗。試題二閱讀以下關(guān)于SOA架構(gòu)在網(wǎng)上銀行貸款業(yè)務的應用說明，根據(jù)要求回答問題。[說明]FZ軟件公司承接了某銀行網(wǎng)上銀行業(yè)務軟件系統(tǒng)的開發(fā)任務。該銀行所開通的網(wǎng)上銀行業(yè)務中，網(wǎng)上貸款業(yè)務流程如下。(1)客戶在網(wǎng)上填寫姓名、電子郵件地址、貸款類型、貸款金額、身份證號和通信地址等信息，提交貸款申請。(2)在指定的時間內(nèi)，客戶會收到銀行的電子郵件，通知貸款是否被批準。(3)銀行根據(jù)客戶提交的信息，創(chuàng)建貸款申請任務，創(chuàng)建工作由運行在主機上的CICS(客戶信息控制系統(tǒng))完成，同時需要從第三方獲得客戶的信用審查信息。(4)由信貸員對該項貸款申請業(yè)務進行審批，然后由風險檢查系統(tǒng)評估該項貸款的風險程度，風險大的貸款申請將被拒絕。(5)無論批準或者拒絕，結(jié)果都會通過郵件系統(tǒng)遞交給客戶。對于拒絕的貸款申請，還要通知貸款申請任務進行有關(guān)操作。(6)除了信貸員審批環(huán)節(jié)需要人機交互外，業(yè)務是自動進行的。

SSS_TEXT_QUSTI2.[問題1]上述網(wǎng)上貸款業(yè)務采用架構(gòu)來實現(xiàn)。上述業(yè)務流程中涉及哪些功能單元?本題中的案例采用SOA架構(gòu)具有哪些優(yōu)點請用300字以內(nèi)的文字簡要說明。分值:15答案:面向服務架構(gòu)體系結(jié)構(gòu)(Service-OrientedArchitecture，SOA)作為一種架構(gòu)模型，它將應用程序的不同功能單元(稱為服務通過服務之間的接口(和契約)聯(lián)系起來。接口獨立于實現(xiàn)服務的硬件平臺、操作系統(tǒng)和編程語言。接口是采用中立的方式進行定義的，它獨立于實現(xiàn)服務的硬件平臺、操作系統(tǒng)和編程語言。這使得構(gòu)建的服務可以以一種統(tǒng)一的和通用的方式進行交互。這種具有中立的接口定義(沒有強制綁定到特定的實現(xiàn)上的特征稱為服務之間的松耦合。松耦合系統(tǒng)的好處有兩點：①靈活性；②當組成整個應用程序的每個服務的內(nèi)部結(jié)構(gòu)和實現(xiàn)逐漸地發(fā)生改變時，它能夠繼續(xù)存在。而與此相對，緊耦合意味著應用程序的不同組件之間的接口與其功能和結(jié)構(gòu)是緊密相連的，因而當需要對部分或整個應用程序進行某種形式的更改時，它們就顯得非常脆弱。通過題干中關(guān)于網(wǎng)上銀行貸款業(yè)務的說明不難找出相對獨立的功能單元。這些功能單元為SOA中的“服務”。由題干中給出的關(guān)鍵信息“(1)客戶在網(wǎng)上填寫姓名……等信息，提交貸款申請”可知，該網(wǎng)上貸款業(yè)務流程中需涉及“貸款申請”這一功能單元。由題干中給出的關(guān)鍵信息“(3)銀行根據(jù)客戶提交的信息……同時需要從第三方獲得客戶的信用審查信息”可知，該網(wǎng)上貸款業(yè)務流程中涉及“信用審查”這一第三方功能單元。由題干中給出的關(guān)鍵信息“(4)由信貸員對該項貸款申請業(yè)務進行審批，然后由風險檢查系統(tǒng)評估該項貸款的風險程度”可知，該網(wǎng)上貸款業(yè)務流程中涉及“信貸員審批”和“風險檢查(或風險評估)”這兩個功能單元。其中，功能單元“信貸員審批”也可從題干中給出的關(guān)鍵信息“(6)除了信貸員審批環(huán)節(jié)需要人機交互外，業(yè)務是自動進行的”獲得啟發(fā)。由題干中給出的關(guān)鍵信息“(5)無論批準或者拒絕，結(jié)果都會通過郵件系統(tǒng)遞交給客戶”可知，該網(wǎng)上貸款業(yè)務流程中涉及“電子郵件傳送”這一功能單元。從技術(shù)角度而言，帶來了“松散耦合”的應用程序組件，在此類組件中，代碼不一定綁定到某個特定的數(shù)據(jù)庫(甚至不一定綁定到特定的基礎(chǔ)設(shè)施)。正是得益于這個松散耦合特性，才使得能夠?qū)⒎战M合為各種應用程序。這樣不僅大幅度提高了代碼重用率，而且業(yè)務變更時業(yè)務系統(tǒng)更加靈活和便利，還可以在增加功能的同時減少工作量。還具有管理上的優(yōu)點。例如，現(xiàn)在管理員可直接管理開發(fā)人員所構(gòu)建的服務，這遠勝于以往管理單個應用的方式。通過分析服務間的交互，SOA可以幫助企業(yè)了解何時及什么業(yè)務邏輯被切實執(zhí)行了，這使管理員能夠有針對性地優(yōu)化業(yè)務流程。采用SOA將本項目相關(guān)功能單元有機地集成在一起，可以快速、經(jīng)濟、方便地構(gòu)建出網(wǎng)上銀行貸款業(yè)務系統(tǒng)。具體優(yōu)點表現(xiàn)在：①可以復用銀行的各種

應用資源；②可以增強銀行各個業(yè)務的集成性和靈活性；③業(yè)務流程變更時便于快速構(gòu)建應用系統(tǒng)。SSS_TEXT_QUSTI3.[問題2]服務注冊表(ServiceRegistry)式是SOA的架構(gòu)模式之一。注冊表支持驅(qū)動SOA治理的服務合同、策略和元數(shù)據(jù)的開發(fā)、發(fā)布和管理。結(jié)合你的系統(tǒng)架構(gòu)經(jīng)驗，請用400字以內(nèi)的文字簡要說明大多數(shù)商用服務注冊產(chǎn)品支持哪些SOA治理功能。分值:15答案:雖然服務注冊表(ServiceRegistry)常常具有運行時段的功能，但它主要是在SOA設(shè)計時段使用。注冊表支持驅(qū)動SOA治理的服務合同、策略和元數(shù)據(jù)的開發(fā)、發(fā)布和管理。因此它提供一個主控制點，也稱為策略執(zhí)行點PolicyEnforcementPoint，PEP)。在這個點上，服務可以在中注冊和被發(fā)現(xiàn)。注冊表可以包括有關(guān)服務和相關(guān)軟件組件的配置、遵從性和約束配置文件。任何幫助注冊、發(fā)現(xiàn)和檢索服務合同、元數(shù)據(jù)和策略的信息庫、數(shù)據(jù)庫、目錄或其他節(jié)點都可以被認為是一個注冊表。通用描述、發(fā)現(xiàn)與集成標準定義了SOA的一種主要注冊環(huán)境。大多數(shù)商用服務注冊產(chǎn)品支持以下治理功能。(1)服務注冊：應用開發(fā)者(也稱為服務提供者)向注冊表公布他們的功能。他們公布服務合同，包括服務身份、位置、方法、綁定、配置、方案和策略等描述性屬性。實現(xiàn)SOA治理最有效的方法之一，是限制哪類新服務可以向主注冊表發(fā)布、由誰發(fā)布，以及誰批準和根據(jù)什么條件批準。此外，許多注冊表包含開發(fā)向注冊表發(fā)布服務可能需要的說明性服務模板。(2)服務位置：服務應用開發(fā)者幫助他們查詢注冊服務，尋找符合自身要求的服務。注冊表讓服務的消費者檢索服務合同。對誰可以訪問注冊表，以及什么服務屬性通過注冊表暴露的控制，是另一些有效的治理手段，注冊表產(chǎn)品一般都支持此類功能。(3)服務綁定：服務的消費者利用檢索到的服務合同來開發(fā)代碼，開發(fā)的代碼將與注冊的服務綁定、調(diào)用注冊的服務，以及與它們實現(xiàn)互動。開發(fā)者常常利用集成的開發(fā)環(huán)境自動將新開發(fā)的服務與不同的新協(xié)議、方案和程序間通信所需的其他接口綁在一起。工具驅(qū)動對服務綁定的控制，有效地管理服務在企業(yè)服務總線(ESB)上的互動。SSS_TEXT_QUSTI4.[問題3]上述網(wǎng)上貸款系統(tǒng)能夠?qū)嶋H應用的基本前提之一是滿足金融領(lǐng)域的安全性需求。該系統(tǒng)必須要滿足哪些安全方面的需求請用200字以內(nèi)的文字簡要說明。分值:15

答案:在進行SOA的集成時，用戶身份識別、數(shù)據(jù)完整性等安全問題是需要重點解決的問題。該網(wǎng)上貸款系統(tǒng)必須滿足以下安全方面的需求。(1)利用用戶身份驗證技術(shù)對該網(wǎng)上貸款系統(tǒng)有關(guān)角色進行身份識別。(2)利用公鑰密鑰機制等技術(shù)創(chuàng)建及驗證類似手寫簽名的電子簽名。(3)采用授權(quán)機制審查系統(tǒng)中信貸員是否具有相應的審批權(quán)。(4)利用數(shù)據(jù)完整性機制驗證發(fā)送的數(shù)據(jù)與接收到的數(shù)據(jù)是否一致。(5)采用機密性機制使與業(yè)務無關(guān)的人員不能讀取事務中的數(shù)據(jù)。(6)采用審查機制(例如，日志記錄)把所有事務記錄下來，以便事后驗證。(7)利用防否認機制，由第三方求證事務中發(fā)送及收到的是否是同一數(shù)據(jù)。(8)利用威脅預防機制，防止間諜程序登錄和攻擊系統(tǒng)。試題三5.以圖形的方式觀察和認識事物，是人類最便捷的認知方式之一。實時控制系統(tǒng)的可視化技術(shù)，使得操控人員以更加易于理解的形式掌握被控對象和過程的狀態(tài)，為操作與決策提供方便。但是，可視化的設(shè)計涉及許多相關(guān)技術(shù)，程序設(shè)計復雜，有時甚至比設(shè)計實時控制系統(tǒng)本身的工作量還大。請圍繞“可視化技術(shù)在實時控制系統(tǒng)的應用”論題，依次對以下個方面進行論述。1．概要敘述你參與管理和開發(fā)的實時控制系統(tǒng)項目及你所擔任的主要工作。2．論述你在實時控制系統(tǒng)可視化的設(shè)計中所涉及的基本概念和采用的技術(shù)、方法，詳細敘述實現(xiàn)過程中所遇到的問題及解決辦法。3．分析與評估可視化技術(shù)對改善系統(tǒng)操控性能的效果，簡要展望可視化技術(shù)在未來實時控制系統(tǒng)的應用前景，以及你進一步應用可視化技術(shù)的有關(guān)設(shè)想。SSS_TEXT_QUSTI分值:18.75答案:1．簡要介紹你參與管理和開發(fā)的大中型實時控制系統(tǒng)項目的基本情況，簡要說明自己在該項目中的角色、所承擔的主要任務及開展的主要工作。論文敘述自己參與管理和開發(fā)的實時控制系統(tǒng)項目應有一定的規(guī)模，自己在該項目中擔任的主要工作應有一定的分量。2．討論你在實時控制系統(tǒng)可視化的設(shè)計中所涉及的基本概念和采用的技術(shù)及方法。分析各種可視化系統(tǒng)的共性，討論獨立于實時控制系統(tǒng)的可視化平臺的概念模型和基本要素，分析在實時控制系統(tǒng)與可視化平臺之間傳送的消息的基本形式。結(jié)合項目實踐經(jīng)驗，針對在可視化平臺上開發(fā)實時控制系統(tǒng)可視化部分的具體要求，詳細分析對可視化系統(tǒng)開發(fā)工具的要求。詳細敘述實時控制系統(tǒng)可視化的形式和實際意義，要明確系統(tǒng)設(shè)計的目

標，對于討論可視化系統(tǒng)設(shè)計和實現(xiàn)時所遇到過的主要問題，要有具體的解決方案和對策(解決辦法)。3．說明你的項目中所使用的可視化技術(shù)，對改善系統(tǒng)操控性能進行客觀的分析和適當?shù)脑u價，進一步討論你在實時控制系統(tǒng)的可視化設(shè)計方面的幾點體會，以及在今后的工作過程中，如果碰到類似的開發(fā)項目你將如何應用這些經(jīng)驗或教訓。對需要進一步改進的地方，應有具體的著眼點，不能泛泛而談。論文最后簡要給出實時控制系統(tǒng)可視化技術(shù)的發(fā)展趨勢與前景。在對發(fā)展前景和可能的新技術(shù)討論時，最好能夠討論某一種具體技術(shù)的實際應用。試題四4閱讀以下關(guān)于基于場景驅(qū)動的軟件架構(gòu)設(shè)計的相關(guān)敘述，根據(jù)要求回答問題。[說明]對于大中型軟件開發(fā)項目，通常采用迭代的方法來進行架構(gòu)設(shè)計。架構(gòu)先被原型化、測試和評估分析，然后在一系列的迭代過程中被細化。這種方法能夠使需求細化、成熟化，并能夠被更好地理解。用例場景是通過描述流經(jīng)用例的路徑來確定的過程，這個流經(jīng)過程要從用例開始到結(jié)束遍歷其中所有基本流(基本事件和備選流(分支事件)。表1是對某IC卡加油機應用系統(tǒng)基本流的描述，表是對該IC卡加油機應用系統(tǒng)備選流的描述。表1基本流描述表序號

用例名稱用例描述A1準備加油客戶將加油卡插入加油機A2A3

驗證加油加油機從加油卡的磁條中讀取賬戶代碼，并檢查它是否屬于可卡以接收的加油卡驗證黑名加油機驗證卡賬戶是否存在于黑名單中，如果屬于黑名單，則單加油機吞卡A4

輸入購油量

客戶輸入需要購買的汽油數(shù)量A5加油加油機完成加油操作，從加油卡中扣除相應金額A6

返回加油卡

退還加油卡表2備選流描述表序號

用例名稱用例描述BCD

加油卡無效卡賬戶屬于黑名單加油卡賬面現(xiàn)金不足

在基本流過程中，該卡不能夠識別或是非本機可以使用的卡，加油機退卡，并退出基本流在基本流過程中，判斷該卡賬戶屬于黑名單(例如，已經(jīng)掛失)，加油機吞卡，并退出基本流系統(tǒng)判斷加油卡內(nèi)現(xiàn)金不足，重新加入基本流，或選擇退卡

E

加油機油量系統(tǒng)判斷加油機內(nèi)油量不足，重新加入基本流，或選擇退不足卡SSS_TEXT_QUSTI6.[問題1]結(jié)合你的系統(tǒng)架構(gòu)經(jīng)驗，請用字以內(nèi)的文字，簡述基于場景驅(qū)動的迭代式軟件架構(gòu)設(shè)計過程。分值:15答案:這是一道要求讀者掌握基于場景驅(qū)動的迭代式軟件架構(gòu)設(shè)計的經(jīng)驗總結(jié)題。本題的解答思路如下。軟件架構(gòu)是軟件系統(tǒng)的高層描述，給出了關(guān)于軟件系統(tǒng)組織結(jié)構(gòu)的一系列高級的、重要的抽象，包括：①系統(tǒng)組成的結(jié)構(gòu)性構(gòu)件；②組成構(gòu)件之間的接口；③構(gòu)件相對系統(tǒng)其他部分的可視行為；④構(gòu)件之間所采取的交互和協(xié)作關(guān)系。采用迭代的方法來進行架構(gòu)設(shè)計，除了減少與架構(gòu)相關(guān)的風險之外，在項目管理方面的優(yōu)點有團隊合作和培訓，加深對架構(gòu)的理解，以及深入程序和工具等(此處提及的是演進的原形，逐漸發(fā)展成為系統(tǒng)，而不是一次性的試驗性的原形)。這種迭代方法還能夠使需求被細化和成熟化，并能夠被更好地理解。軟件系統(tǒng)大多數(shù)關(guān)鍵的功能以場景或用例)的形式被捕獲。這里的“關(guān)鍵”是指系統(tǒng)最重要的功能(或系統(tǒng)存在的理由，或使用頻率最高的功能，或其應用減輕了一些重要的技術(shù)風險?；趫鼍膀?qū)動的迭代式設(shè)計過程如下。(1)開始階段?；陲L險和重要性為某次迭代選擇一些場景。場景可能被歸納為對若干用戶需求的抽象；對場景進行“描述”，以識別主要的抽象類、機制、過程和子系統(tǒng))；將所發(fā)現(xiàn)的架構(gòu)元素分布到個視圖中；然后實施、測試和評估該架構(gòu)。這個過程中可能檢測到一些缺點或潛在的增強要求。(2)循環(huán)階段。重新評估風險，選擇能減輕風險或提高結(jié)構(gòu)覆蓋的額外的少量場景，然后試著在原先的架構(gòu)中描述這些場景，發(fā)現(xiàn)額外的架構(gòu)元素，或找出適應這些場景所需的重要架構(gòu)變更，更新個主要視圖；根據(jù)變更修訂現(xiàn)有的場景；升級實現(xiàn)工具(架構(gòu)原型)以支持新的、擴展的場景集合。(3)測試。如果有可能(例如，在已有的可重用的組件下快速實現(xiàn)系統(tǒng))，則在實際的目標環(huán)境和負載下進行測試。(4)評審。評審軟件架構(gòu)的5個視圖，檢測架構(gòu)在簡潔性、可重用性和通用性方面可能存在的潛在問題。(5)更新設(shè)計準則和基本原理。(6)捕獲經(jīng)驗教訓。對于實際的系統(tǒng)，初始的架構(gòu)原型需要不斷進行演化。一般的情況是在經(jīng)過2次或3次迭代，當找到了主要的抽象時，子系統(tǒng)和過程都已經(jīng)完成并且已經(jīng)實現(xiàn)所有的接口，系統(tǒng)架構(gòu)可認為趨向于穩(wěn)定?？赡苓@些迭代過程的持續(xù)時間參差不齊，其原因在于：所實施項目的規(guī)模，參與項目人員的數(shù)量，對本領(lǐng)域和方法的熟悉程度，以及該系統(tǒng)和開發(fā)組

織的熟悉程度等。因而較小的項目迭代過程可能持續(xù)～3周，而大中型的項目可能為6～9個月。SSS_TEXT_QUSTI7.[問題2]下圖是對該IC卡加油機應用系統(tǒng)的基本流路徑和備選流路徑的描述，請用試題描述中的相應字母(見表1和表2)，將圖中1)～(6)空缺處的內(nèi)容填寫完整。分值:15答案:這是一道要求讀者掌握場景法的基本流和備選流路徑描述的應用分析題。本題的解答思路如下。(1)經(jīng)過用例的每條不同路徑都反映了基本流和備選流，都用箭頭來表示?；玖饔么种焙诰€來表示，是經(jīng)過用例的最簡單的路徑。上圖中粗直黑線就是對該IC卡加油機應用系統(tǒng)基本流路徑的描述。(2)再根據(jù)表1中A1～A6各個基本流的描述和描述順序，以及圖中已給出的基本流A1、A2、A3、A6的路徑位置可知，圖中3)空缺處填寫的內(nèi)容應為“A4(輸入購油量)”，(4)空缺處填寫的內(nèi)容應為“A5(加油)”。(3)備選流用不同的彩色曲線表示，一個備選流可能從基本流開始，在某個特定條件下執(zhí)行，然后重新加入基本流中；也可能起源于另一個備選流，或者終止用例而不再重新加入某個流。(4)根據(jù)表2中備選流B的描述“在基本流A2過程中，該卡不能夠識別或是非本機可以使用的IC卡，加油機退卡，并退出基本流”可知，備選流B的路徑起源于基本流A2，終點是基本流A6(退還加油卡。因此圖中(1)空缺處填寫的內(nèi)容應為“B(加油卡無效)”。(5)同理，根據(jù)表2中備選流C的關(guān)鍵描述“在基本流A3過程中，判斷該卡賬戶屬于黑名單，加油機吞卡，并退出基本流”可知，備選流的路徑起源于基本流A3，終點是基本流A6(退還加油卡。因此圖中(2)空缺處填寫的內(nèi)容應為“C(卡賬戶屬于黑名單)”。(6)備選流D(加油卡賬面現(xiàn)金不足)的描述“系統(tǒng)判斷加油卡內(nèi)現(xiàn)金不足，重新加入基本流A4，或選擇退卡”中，“系統(tǒng)判斷加油卡內(nèi)的現(xiàn)金不足”是指當客戶輸入需要購買的汽油數(shù)量時，該卡加油機應用系統(tǒng)將準備購買的汽油數(shù)量乘以單位油價得到需支付的費用，并將此費用與客戶加油卡內(nèi)現(xiàn)金進行比較后的一種可能結(jié)果。因此備選流D的路徑起源于基本流A4(輸入購油量)之后，基本流A5(加油)之前。由備選流D的描述“重新加入基本流A4，或選擇退卡”可知，備選流D的路徑終點可能是基本流，以便重新進行購油量的輸入；也可能是基本流A6(退還加油卡)。因此需將“D(加油卡賬面現(xiàn)金不足)”的內(nèi)容同時填入圖中(5)、(6)空缺處。(7)備選流E(加油機油量不足)的描述“系統(tǒng)判斷加油機內(nèi)油量不足，重新加入基本流A4，或選擇退卡”中，“系統(tǒng)判斷加油機內(nèi)油量不足”是指當客

戶輸入需要購買的汽油數(shù)量時，該IC卡加油機應用系統(tǒng)將準備購買的汽油數(shù)量與系統(tǒng)加油機內(nèi)現(xiàn)存的汽油數(shù)量進行比較后的一種可能結(jié)果。因此備選流的路徑起源于基本流A4(輸入購油量)之后，基本流加油)之前。備選流的路徑終點可能是基本流A4，以便重新進行購油量的輸入，也可能是基本流A6(退還加油卡)。因此需將“E(加油機油量不足)”的內(nèi)容同時填寫入圖中5)、(6)空缺處。SSS_TEXT_QUSTI8.[問題3]場景中的每一個場景都需要確定測試用例，一般采用矩陣或決策表來確定和管理測試用例。表5-19是一種通用格式，表中各行代表各個測試用例，而各列代表測試用例的信息。本例中的測試用例包含測試用例號、場景(或說明/條件)、測試用例中涉及的所有數(shù)據(jù)元素(作為輸入或已經(jīng)存在于數(shù)據(jù)庫中)，以及預期結(jié)果等項目。測試用例的設(shè)計步驟通常是，首先確定執(zhí)行用例場景所需的數(shù)據(jù)元素本例中包括賬號、是否黑名單卡、輸入油量、賬面金額和加油機油量，然后構(gòu)建矩陣，最后確定包含執(zhí)行場景所需的適當條件的測試用例。在表的測試矩陣中，V表示有效數(shù)據(jù)元素，I表示無效數(shù)據(jù)元素，表示不適用，例如表示“成功加油”基本流。請按上述規(guī)定為其他的應用場景設(shè)計測試用例矩陣。表3測試用例表測試用例ID號

場景

賬是否黑名輸入油賬面金加油機油期結(jié)號單卡量額量果CW01

場景1：成功加油

VIVVV

成功加油CW02CW03CW04CW05分值:15答案:這是一道要求讀者掌握在場景法中設(shè)計測試用例的綜合分析題。本題的分析思路如下。(1)根據(jù)題干的描述可知，本案例中存在著以下種場景。場景1：基本流A。場景2：基本流A、備選流B。場景3：基本流A、備選流C。場景4：基本流A、備選流D。場景5：基本流A、備選流E。(2)測試用例表(表3)已給出了場景1的測試用例，對于其他4行所填寫的內(nèi)容可以通過參照場景1的測試用例的解答思路進行。(3)本案例中與場景相關(guān)的描述如下。A2，驗證加油卡：加油機從加油卡的磁條中讀取賬戶代碼，并檢查它是否

屬于可以接收的加油卡。B，加油卡無效：在基本流過程中，該卡不能夠識別，或是非本機可以使用的Ic卡，加油機退卡，并退出基本流。由“備選流B(加油卡無效)”的描述中提取出場景2(AB)的名稱——“卡無效”，輸入值是“賬號無效”，預期結(jié)果是“退卡”。(4)本案例中與場景相關(guān)的描述如下。A2，驗證加油卡：加油機從加油卡的磁條中讀取賬戶代碼，并檢查它是否屬于可以接收的加油卡。A3，驗證黑名單：加油機驗證卡賬戶是否存在于黑名單中，如屬于黑名單，則加油機吞卡。C，卡賬戶屬于黑名單：在基本流過程中，判斷該卡賬戶屬于黑名單，例如，已經(jīng)掛失，加油機吞卡并退出基本流。由“備選流C(卡賬戶屬于黑名單)”的描述提取出場景3(AC)的名稱——“黑名單卡”，輸入值是“賬號有效”和“黑名單卡”，預期結(jié)果是“吞卡”。(5)基本流A1、備選流D的相關(guān)描述與本案例中場景4(AD)關(guān)。由“備選流D(加油卡賬面現(xiàn)金不足)”的描述提取出場景的名稱——“金額不足”，其輸入值為“賬號有效”、“非黑名單卡”、“輸入購油量有效”、“加油機油量有效”和“賬面金額無效”，預期結(jié)果是“提示錯誤，或重新輸入購油量，或退卡”。(6)基本流A1、備選流E的相關(guān)描述與本案例中場景5(AE)關(guān)。由“備選流E(加油機油量不足)”的描述提取出場景的名稱——“油量不足”，其輸入值為“賬號有效”、“非黑名單卡”、“輸入購油量有效”、“賬面金額有效”和“加油機油量無效”，預期結(jié)果是“提示錯誤，或重新輸入購油量，或退卡”。(7)將以上分析結(jié)果按照試題中的規(guī)定——“V示有效數(shù)據(jù)元素，I表示無效數(shù)據(jù)元素，n/a表示不適用”，歸納整理成如表所示的測試用例表。表4完整的測試用例表測試用例ID號

場景

賬號

是否黑名單輸入油賬面金加油機油卡量額量

預期結(jié)果場景CW01

1：成功加

V

IVVV

成功加油油場景CW022：In/an/an/an/a卡無效場景3：CW03VVn/an/an/a黑名單卡

退卡吞卡

CW04

場景4：金額不足

V

IVIV

提示錯誤，或重新輸入購油量，或退卡場景CW05

5：油量不

V

IVVI足試題五閱讀以下關(guān)于辦公自動化(OA)系統(tǒng)的相關(guān)敘述，根據(jù)要求回答問題。[說明]某企業(yè)的辦公自動化(OA)系統(tǒng)采用Browse/Server架構(gòu)，服務器是一臺PCServer(4路2.7GHz處理器，4GB內(nèi)存)，安裝的平臺軟件包括InternetInformationServer5.0、ASRNETSQLServer2000?，F(xiàn)對該系統(tǒng)進行負載壓力測試，采用專業(yè)的負載壓力測試工具來執(zhí)行測試，并使用臺筆記本電腦安裝測試工具模擬客戶端執(zhí)行“登錄”業(yè)務操作。測試目標分別為以下兩個。(1)測試系統(tǒng)分別在2Mbps和4Mbps網(wǎng)絡帶寬下，能夠支持用戶登錄的最大并發(fā)用戶數(shù)。(2)測試服務器的吞吐量(即每秒可以處理的交易數(shù))，主要包括服務器CPU平均使用率達到85%時系統(tǒng)能夠支持的最大吞吐量，以及服務器CPU平均使用率達到100%時系統(tǒng)能夠支持的最大吞吐量。本次測試的性能需求是：指標“響應時間”合理范圍為～5s。在2Mbps和4Mbps網(wǎng)絡帶寬的測試環(huán)境下，客戶端性能及服務器資源使用情況的測試結(jié)果如表1所示。表1性能測試結(jié)果網(wǎng)絡帶測試對象測試指標登錄響應時間

平均值**2Mbps

客戶端性能

虛擬用戶數(shù)N/A**交易/s每秒處理完成登錄的個數(shù)服務器資源使用情CPU使用率78%4Mbps

客戶端性能

**登錄響應時間虛擬用戶數(shù)N/A**交易/s每秒處理完成登錄的個數(shù)

服務器資源使用情CPU使用率98%在2Mbps帶寬的網(wǎng)絡測試環(huán)境下，負載壓力測試工具上客戶端性能的顯示結(jié)果如圖1所示(注：圖中登錄響應時間的縱坐標單位是，服務器資源使用情況如圖2所示。圖1圖2在4Mbps帶寬的網(wǎng)絡測試環(huán)境下，負載壓力測試工具上客戶端性能的顯示結(jié)果如圖3所示(注：圖中登錄響應時間的縱坐標單位是，服務器資源使用情況如圖4所示。圖3SSS_TEXT_QUSTI9.[問題1]在2Mbps帶寬的網(wǎng)絡測試環(huán)境下，分析案例中的測試結(jié)果，指出滿足系統(tǒng)的性能指標需求時，系統(tǒng)能夠承受的并發(fā)用戶登錄的最大數(shù)量，并簡要說明理由。分值:15答案:網(wǎng)絡系統(tǒng)應用的性能測試是為確保網(wǎng)絡在實際運行狀況下，各種基本應用服務能夠達到用戶可以接受的性能和服務質(zhì)量。本題考查系統(tǒng)負載壓力性能測試的重要指標“并發(fā)用戶數(shù)”。判斷系統(tǒng)能夠承受的最大并發(fā)用戶數(shù)的條件可以概括為：①交易操作響應時間在合理范圍內(nèi)；②交易通過率在合理范圍內(nèi)；③系統(tǒng)運行無故障；④系統(tǒng)資源使用在合理范圍內(nèi)等。其中，應用系統(tǒng)交易執(zhí)行響應時間(“RT”，ResponseTime)是指系統(tǒng)完成事務執(zhí)行準備后所采集的時間戳和系統(tǒng)完成待執(zhí)行事務后所采集的時間戳之間的時間間隔。它是衡量特定類型應用事務性能的重要指標，標志了用戶執(zhí)行一項操作大致需要多長時間。在本案例場景中，應該選擇第個條件來判斷系統(tǒng)能夠承受的最大并發(fā)用戶數(shù)。由題干關(guān)鍵信息“本次測試的性能需求是：指標‘響應時間’合理范圍為0～5s”，即在通常情況下，交易操作合理的響應時間為以內(nèi)。由案例1的圖1的顯示結(jié)果可知，登錄響應時間隨虛擬并發(fā)用戶數(shù)增加而增長。在個虛擬并發(fā)用戶的負載下，登錄響應時間達到5s(意：圖1中響應時間指標的比例為10)，當負載超過50個虛擬并發(fā)用戶，響應時間超過5s或者與5s持平。因此案例1中最合理的最大并發(fā)用戶數(shù)為5