1、 <文檔名稱> <版本信息> 研發(fā)類課題管理系統(tǒng)架構設計說明書文件版本：文件編號：發(fā)布日期：編 制：審 核： 批 準：國家開發(fā)銀行版權所有內部資料 注意保密修訂記錄：版本號修訂人修訂日期修訂描述目 錄1 簡介31.1 目的31.2 文檔范圍31.3 預期的讀者和閱讀建議31.4 參考文檔31.4.1 包含文檔31.4.2 相關文檔31.5 縮略語和術語32 總體架構32.1 系統(tǒng)范圍32.2 設計方法32.3 設計可選方案32.4 整體架構33 總體約束33.1 遵循標準33.2 文件約定33.3 目錄約定33.4 對后續(xù)設計的約束33.5 其它34 系統(tǒng)邏輯結構34.

2、1 總體結構34.2 子系統(tǒng)定義34.2.1 子系統(tǒng)一34.2.2 子系統(tǒng)二34.3 接口設計34.3.1 產(chǎn)品外部接口34.3.2 子系統(tǒng)間接口34.4 主要數(shù)據(jù)模型35 系統(tǒng)物理結構35.1 總體結構35.2 組件定義35.2.1 組件一35.3 組件接口設計35.4 組件與子系統(tǒng)對應關系36 系統(tǒng)部署36.1 網(wǎng)絡結構圖36.2 部署模式37 關鍵技術及公用機制37.1 關鍵技術設計37.2 公用機制說明38 系統(tǒng)重用設計38.1 以往設計的重用38.2 可重用性考慮39 系統(tǒng)功能實現(xiàn)310 開發(fā)平臺與技術架構說明310.1 開發(fā)平臺310.2 技術架構310.2.1 硬件設備說明310

3、.2.2 軟件說明311 系統(tǒng)非功能特性設計311.1 可擴展性311.2 可靠性311.3 性能311.4 可維護性311.5 安全311.6 審計311.7 容錯性311.8 可移植性311.9 可部署性311.10 312 風險313 附錄31 簡介1.1 目的本設計文檔的目的是根據(jù)研發(fā)類課題管理系統(tǒng)用戶需求規(guī)格說明書對需求的描述，對研發(fā)類課題管理系統(tǒng)的業(yè)務實現(xiàn)進行了架構設計。本文檔將指導后續(xù)的設計和開發(fā)工作，并對功能測試和性能測試工作起到輔助、參考作用。1.2 文檔范圍本文檔主要描述研發(fā)類課題管理系統(tǒng)的架構設計，覆蓋研發(fā)類課題管理系統(tǒng)的需求。研發(fā)類課題管理系統(tǒng)基于USE平臺的UAAP框

4、架進行構建，UAAP中已經(jīng)實現(xiàn)的權限管理、菜單管理、人員及組織機構管理、統(tǒng)一授權接口等已經(jīng)完成的功能不在本文檔范圍之內，以后系統(tǒng)實現(xiàn)的各種業(yè)務流程將會受到研發(fā)類課題管理系統(tǒng)設計的影響。本文檔遵循自頂向下、逐層分解的原則，對研發(fā)類課題管理系統(tǒng)進行架構設計：首先，根據(jù)對開行的系統(tǒng)范圍的理解，提出總體設計方法，結合行內的平臺及架構要求，給出了系統(tǒng)架構，從與外圍系統(tǒng)關系、主要子系統(tǒng)、技術實現(xiàn)框架角度分別闡述研發(fā)類課題管理系統(tǒng)的構成。其次，在系統(tǒng)邏輯結構章節(jié)，結合以上各個角度的剖析，從平臺實現(xiàn)、業(yè)務處理模式方面存在的差異，將研發(fā)類課題管理系統(tǒng)進行邏輯架構分解，劃分為不同的子系統(tǒng)并分別闡述功能及設計思路。

5、再次，在系統(tǒng)物理結構章節(jié)，對系統(tǒng)功能進行構件化的劃分。此外，該文檔對系統(tǒng)的部署、關鍵技術、系統(tǒng)重用設計、系統(tǒng)功能實現(xiàn)、開發(fā)平臺與技術架構、系統(tǒng)非功能性設計及風險進行了說明。1.3 預期的讀者和閱讀建議本文檔的讀者必須對USE平臺的體系結構或者設計方法有所了解本文檔的閱讀者為研發(fā)類課題管理系統(tǒng)開發(fā)過程的各角色：產(chǎn)品角色、系統(tǒng)分析架構角色、項目管理角色、代碼角色、測試角色、文檔角色，信息科技事務跟蹤系統(tǒng)系統(tǒng)系統(tǒng)的部署角色、培訓角色、維護角色；本文檔組織方式：第一章 簡介，描述文檔的目的；第二章 描述總體設計思路，包括設計方法及備選設計方案和方案的選擇；第三章 描述系統(tǒng)的邏輯結構。從最高層次上描述系

6、統(tǒng)的邏輯組成；第四章 描述系統(tǒng)的物理結構。從最高層次上描述系統(tǒng)的物理組成；第五章 描述系統(tǒng)的部署情況；第六章 對系統(tǒng)架構中的關鍵技術及公用設計機制進行描述；第七章 如何重用以往設計產(chǎn)物及現(xiàn)有設計如何對將來重用產(chǎn)生影響進行描述；第八章 對系統(tǒng)中重要的用例或者有技術難度的部分進行功能實現(xiàn)的描述，以方便設計人員在進行設計、開發(fā)時進行參考；第九章 對系統(tǒng)依賴的第三方軟硬件進行描述；第十章 對系統(tǒng)的非功能特性設計進行描述；產(chǎn)品經(jīng)理應當關注該部分的描述是否與產(chǎn)品需求中產(chǎn)品的非功能性需求一致；開發(fā)人員應當在后續(xù)設計過程中對這部分設計進行關注，避免遺漏；測試人員應當根據(jù)這部分的描述制定測試案例，驗證是否可以達

7、到產(chǎn)品需求的要求。第十一章 描述架構設計中識別的風險，產(chǎn)品經(jīng)理、設計人員、開發(fā)人員和測試人員 都應當隨時關注這些風險，避免風險發(fā)生并及時采取規(guī)避、減輕措施。第十二章 附錄1.4 參考文檔1.4.1 包含文檔無1.4.2 相關文檔作者文檔名稱文檔版本出版日期出版單位或歸屬單位研發(fā)類課題管理系統(tǒng)項目組研發(fā)類課題管理系統(tǒng)用戶需求說明書V1.0二一二年四月國家開發(fā)銀行信息科技局1.5 縮略語和術語縮略語/術語全 稱說 明CDB國家開發(fā)銀行USE國家開發(fā)銀行統(tǒng)一軟件環(huán)境基于EOS Studio實現(xiàn)UAAPFRAMEUnified Authorization and Auth authentication

8、 Platform FrameUSE平臺對統(tǒng)一授權平臺框架BPM國家開發(fā)銀行工作流平臺基于FileNet Process EngineECM國家開發(fā)銀行內容管理平臺基于FileNet Content EngineEII國家開發(fā)銀行信息交換平臺ESB國家開發(fā)銀行企業(yè)服務總線基于TIBCO實現(xiàn)SOA面向服務架構EP國家開發(fā)銀行企業(yè)門戶系統(tǒng)基于TAM實現(xiàn)RDPM國家開發(fā)銀行研發(fā)類課題管理系統(tǒng)接口接口研發(fā)類課題管理系統(tǒng)對外系統(tǒng)的訪問，統(tǒng)稱接口服務服務研發(fā)類課題管理系統(tǒng)內部調用，統(tǒng)稱服務2 總體架構2.1 系統(tǒng)范圍研發(fā)類課題管理系統(tǒng)面向全行研發(fā)類課題申報、管理和查看等部門，系統(tǒng)覆蓋研發(fā)類課題管理全流程，

9、包括：立項受理、付款受理、信息發(fā)布、成果共享等模塊。研發(fā)類課題管理系統(tǒng)在開行2011版整體IT規(guī)劃中，屬于支持平臺域，其所處的位置如下所示（紅色方框部分）。主要用戶包括：1研發(fā)類課題主管部門目前是國家開發(fā)銀行研究院，作為研發(fā)類課題管理系統(tǒng)的管理歸口部門，通過系統(tǒng)對全行研發(fā)類課題全流程電子化管理。2研發(fā)類課題主辦部門總行各業(yè)務廳局均可申請課題，通過研發(fā)類課題管理系統(tǒng)進行課題申請、付款申請等操作。3普通員工全行所有員工，通過研發(fā)類課題管理系統(tǒng)查看權限內的共享課題成果。2.2 設計方案研發(fā)類課題管理系統(tǒng)的設計方法是在國家開發(fā)銀行USE平臺架構的基礎上，采用符合SOA體系結構和對其進行SCA和SDO的

10、落地規(guī)范進行設計。同時對系統(tǒng)內的公共功能進行參數(shù)化及靈活化的設計，來提高系統(tǒng)的重用性和擴展性。在業(yè)務方面，采用以課題從立項到成果發(fā)布的流程為主線，支持管理功能相對獨立的設計方法，模塊內部構件化和接口化來降低系統(tǒng)的耦合度，便于系統(tǒng)的實施及升級維護。1. 采用基于SOA體系結構設計方法采用基于SOA體系結構的“高內聚，低耦合”的基本原則。遵照國家開發(fā)銀行USE平臺架構系統(tǒng)將采用面向服務的設計方法，把整個系統(tǒng)的不同功能單元（稱為服務）劃分出來，通過這些服務之間定義的接口和契約聯(lián)系起來，接口是采用中立的方式進行定義的，它獨立于實現(xiàn)服務的硬件平臺、操作系統(tǒng)和編程語言。這使得構建在各種系統(tǒng)中的服務可以以一

11、種統(tǒng)一和通用的方式進行交互。2. 采用SCA和SDO的落地規(guī)范進行設計SOA只是一種框架性的體系結構， 研發(fā)類課題管理系統(tǒng)采用USE平臺進行建設，USE平臺整合了SCA和SDO的標準和規(guī)范。SCA是SOA的落地架構框架規(guī)范，SDO是數(shù)據(jù)結構規(guī)范和數(shù)據(jù)存取原理規(guī)范。而這些規(guī)范，用現(xiàn)有的開發(fā)語言和技術框架都可以實現(xiàn)。服務構件架構（SCA）的基本思想是將業(yè)務功能作為一系列服務來提供，這些服務組合到一起，以創(chuàng)建滿足特定業(yè)務需要的解決方案。服務數(shù)據(jù)對象（SDO）的設計是為了簡化和統(tǒng)一應用程序處理數(shù)據(jù)的方式。利用SDO，應用程序編程人員可以一致地訪問和操縱來自異構數(shù)據(jù)源的數(shù)據(jù)，包括關系數(shù)據(jù)庫、XML數(shù)據(jù)源

12、、Web服務和其他信息系統(tǒng)。SCA和SDO獲得更高的靈活性和更高的開發(fā)效率?？梢栽诓桓淖儜贸绦蚯闆r下,使用不同的技術作為構件的實現(xiàn),或者改變通信協(xié)議等，同時模塊也可以容易的被重用和組裝，易于修改和變更。3. 參數(shù)化和靈活性設計：考慮到國家開發(fā)銀行研發(fā)類課題管理系統(tǒng)業(yè)務不斷增長和變化帶來的種種影響?；谟美募毩６仍O計使得業(yè)務流程自身是可被組裝的。流程可被拆分為多個單元。比如，針對不同的種類的課題在申報時需要提交的材料是不一樣的，而且在最終評審和結題的流程中也是不一樣的，同時不同種類的課題劃分依據(jù)也會隨著業(yè)務的變化而變化。這樣在系統(tǒng)設計時就需要采用參數(shù)化的設計思想，定義和管理系統(tǒng)的參數(shù)及配置，

13、調整參數(shù)以適應外部變化。 系統(tǒng)的具體設計如下：l 建立研發(fā)類課題業(yè)務辦理的主體流程，建立以業(yè)務流程為主線的系統(tǒng)，體現(xiàn)信貸業(yè)務全生命周期的特點，即一條主線：課題立項備案、費用預算執(zhí)行、合同簽訂支付、研發(fā)成果評審、研發(fā)成果發(fā)布。l 建立相對獨立的業(yè)務支持管理功能，如：立項管理、合同管理、成果管理、機構管理、專家管理等。l 系統(tǒng)內部模塊化、構件化的設計原則，采用統(tǒng)一接口規(guī)范，降低各個功能單元之間的耦合度。2.3 整體架構針對研發(fā)類課題管理系統(tǒng)的系統(tǒng)功能范圍，按照2.3章節(jié)描述的設計方案，進行系統(tǒng)架構的設計，包括研發(fā)類課題管理系統(tǒng)與外圍系統(tǒng)的關系，研發(fā)類課題管理系統(tǒng)主要功能模塊和用戶訪問方式。研發(fā)類課

14、題管理系統(tǒng)其與各其他系統(tǒng)關系描述如下：1. 通過企業(yè)信息交換平臺（EII）平臺獲取全行用戶、機構信息等基礎數(shù)據(jù)。2. 通過統(tǒng)一授權系統(tǒng)拿到用戶授權信息，與統(tǒng)一授權系統(tǒng)同步角色資源等授權信息。3. 與企業(yè)門戶進行單點集成，用戶可以通過直接訪問和企業(yè)門戶單點分別訪問系統(tǒng)。4. 系統(tǒng)根據(jù)內部業(yè)務流程的需要，封裝內部業(yè)務流程構件，使用BPM平臺實現(xiàn)流程的調度、監(jiān)控和管理。5. 通過與ECM集成對文檔管理，進行文檔的上傳、下載、檢索等功能。6. 通過AD進行用戶登錄認證管理。3 總體約束3.1 軟硬件環(huán)境約束1、軟件約束：l 本系統(tǒng)的開發(fā)基于國家開發(fā)銀行USE開發(fā)平臺；l 本系統(tǒng)的數(shù)據(jù)庫基于Oracle

15、 10g；2、平臺約束：l 本系統(tǒng)工作流調度實現(xiàn)基于國家開發(fā)銀行BPM平臺；l 本系統(tǒng)授權實現(xiàn)基于國家開發(fā)銀行UAAP系統(tǒng)；l 本系統(tǒng)內容存儲實現(xiàn)基于國家開發(fā)銀行ECM平臺；l 本系統(tǒng)單點登錄實現(xiàn)基于國家開發(fā)銀行企業(yè)門戶；l 本系統(tǒng)登錄認證實現(xiàn)基于國家開發(fā)銀行AD系統(tǒng)。3、環(huán)境約束：l 開發(fā)環(huán)境應用服務器、數(shù)據(jù)庫服務器操作系統(tǒng)基于Windows Server 2008；l UAT測試環(huán)境應用服務器、數(shù)據(jù)庫服務器操作系統(tǒng)基于Windows Server 2008；l 生產(chǎn)環(huán)境應用服務器、數(shù)據(jù)庫服務器操作系統(tǒng)基于 Windows Server 2008；4、規(guī)范約束：l BPM平臺業(yè)務系統(tǒng)集成命名

16、規(guī)范l USE平臺-應用項目開發(fā)規(guī)范l CDB-SOA_系統(tǒng)集成指導說明書l BPM平臺USE構件接口說明l USE平臺-軟件開發(fā)編碼規(guī)范3.2 遵循標準l 本系統(tǒng)遵循JavaEE標準，主要包括：WebService、JMS、Servlet、JSP、JDBC、XML等。l 本系統(tǒng)遵循SOA架構下 SCA 1.0和SDO 2.1標準。l 本系統(tǒng)Java部分遵循面向對象設計并在設計中遵循UML工業(yè)標準。l 本系統(tǒng)遵循JavaSE 5.0 的技術規(guī)范及注解標準。l 本系統(tǒng) Java 依賴注入標準規(guī)范遵循JSR-330。.l 本系統(tǒng)遵循ISMS-03-08-01-國家開發(fā)銀行軟件開發(fā)安全管理

17、規(guī)范3.3 文件和目錄約定1、設計文檔l 研發(fā)類課題管理系統(tǒng)數(shù)據(jù)庫設計說明書2、開發(fā)文檔：l USE開發(fā)平臺下構件包配置信息采用properties、xml、eosinf、aegis 文件擴展名。l 日志文件為文本文件格式，文件命名：u 標準模塊信息輸出，系統(tǒng)名稱_模塊名稱_yyyymmdd.log；u 標準模塊錯誤信息輸出，系統(tǒng)名稱_模塊名稱_Error_yyyymmdd.log。3、目錄約定u RDPM /src：源文件目錄。u RDPM/conf：放置應用系統(tǒng)配置文件。u RDPM/build：放置編譯代碼。u RDPM/WEB：放置頁面、樣式、腳本。u RDPM/lib：放置所需第三方

18、Jar包。3.4 對后續(xù)設計的約束國家開發(fā)銀行研發(fā)類課題管理系統(tǒng)的后續(xù)建設及維護開發(fā)，應遵循本文檔中列出的遵循標準、文件約定、目錄約定中的要求。4 系統(tǒng)邏輯結構 根據(jù)系統(tǒng)功能實現(xiàn)的技術方式、數(shù)據(jù)處理模式及平臺實現(xiàn)的異同，對研發(fā)類課題管理系統(tǒng)進行邏輯結構的分解。本系統(tǒng)由于功能模塊關系較為緊密且系統(tǒng)業(yè)務邏輯相對簡單清晰，因此不劃分子系統(tǒng)，以下僅從總體結構進行闡述。4.1 總體結構結合對業(yè)務需求的理解和以業(yè)務流程為主線的基礎上，對系統(tǒng)功能根據(jù)業(yè)務關聯(lián)性進行劃分，研發(fā)類課題管理系統(tǒng)的邏輯架構如下圖所示。研發(fā)類課題管理系統(tǒng)的邏輯架構設計，遵循系統(tǒng)內各個模塊相對獨立的松耦合原則。根據(jù)系統(tǒng)內實現(xiàn)功能的主體對

19、象及業(yè)務關聯(lián)度，將系統(tǒng)劃分為四大單元11個功能模塊，分別是1、立項管理；2、合同管理；3、付款管理；4、成果管理；5、檢索統(tǒng)計；6、業(yè)務參數(shù)管理；7、機構管理；8、專家管理；9、信息發(fā)布；10、系統(tǒng)管理；11、系統(tǒng)維護。4.2 功能模塊定義4.2.1 功能模塊概述模塊名稱主要功能立項管理完成課題立項、課題備案相關業(yè)務流程的發(fā)起、流轉。合同管理完成合同備案業(yè)務流程的發(fā)起、流轉。付款管理完成付款申請業(yè)務流程的發(fā)起、流轉。成果管理完成成果發(fā)布業(yè)務流程的發(fā)起、流轉；實現(xiàn)研究成果根據(jù)查看范圍展示。檢索統(tǒng)計根據(jù)用戶需要對系統(tǒng)中數(shù)據(jù)進行分類匯總，并打印輸出報表。業(yè)務參數(shù)管理將業(yè)務參數(shù)及業(yè)務規(guī)則作為系統(tǒng)參數(shù)進

20、行管理，以使系統(tǒng)靈活響應業(yè)務規(guī)則調整。合作機構注冊完成合作機構注冊業(yè)務流程的發(fā)起、流轉。專家管理完成專家注冊業(yè)務流程的發(fā)起、流轉。信息發(fā)布完成信息發(fā)布業(yè)務流程的發(fā)起、流轉。系統(tǒng)管理完成用戶相關的權限、所屬機構管理，菜單項管理，角色管理等功能。系統(tǒng)維護通過系統(tǒng)界面完成系統(tǒng)相關維護功能，目前主要是數(shù)據(jù)庫導入、導出。4.2.2 設計思路根據(jù)用戶需求進行分析，并進行功能點的適當歸納總結后，可對系統(tǒng)功能進行以下分解設計：a、 業(yè)務流程功能單元包含立項管理、合同管理、付款管理3個邏輯功能模塊，此功能組涵蓋了課題從立項、商務直至驗收后付款的主要業(yè)務環(huán)節(jié)，是課題管理的主要業(yè)務功能。b、 業(yè)務管理功能單元包含成

21、果管理、檢索統(tǒng)計、信息發(fā)布3個邏輯功能模塊，主要是課題主管部門對課題管理業(yè)務過程進行歸納總結，并發(fā)布各項管理信息。c、 業(yè)務支持功能單元包含業(yè)務參數(shù)管理、機構管理、專家管理3個邏輯功能模塊，此功能組為完成課題管理主要業(yè)務功能運行的基礎。d、 系統(tǒng)管理功能單元由于機構管理、權限管理、用戶管理、菜單管理、角色管理等功能從定位上具有同一性，因此考慮在此功能組內使用一個系統(tǒng)管理模塊統(tǒng)一完成以上功能。此外，根據(jù)非功能需求，需要通過系統(tǒng)界面實現(xiàn)系統(tǒng)主要維護功能，因此在此功能單元內使用系統(tǒng)維護模塊完成系統(tǒng)維護功能。4.3 接口設計 系統(tǒng)僅有外部接口。外部接口遵循開行各平臺、系統(tǒng)接口規(guī)范。4.3.1 產(chǎn)品外部

22、接口外部接口主要包括：EII、統(tǒng)一授權、AD、BPM、ECM接口。具體接口說明和交互方式如下：序號外圍系統(tǒng)說明接口交互方式1業(yè)務流程管理(BPM)平臺實現(xiàn)流程設計、步驟定義、節(jié)點設定并提供接口支持實時2企業(yè)內容管理（ECM）平臺統(tǒng)一存儲系統(tǒng)需管理的附件文檔，并通過接口進行文檔的上傳、下載和查詢。實時3企業(yè)信息交換（EII）平臺在用戶、機構信息發(fā)生變化時，EII將變化信息主動實時推送至本系統(tǒng)。實時4統(tǒng)一用戶認證系統(tǒng)（AD）對用戶進行身份認證檢查實時5統(tǒng)一授權管理系統(tǒng)（UAAP）本系統(tǒng)與UAAP間雙向同步用戶、角色、權限的對應關系。實時6企業(yè)門戶（EP）通過EP實現(xiàn)單點登錄實時5 系統(tǒng)物理結構5.

23、1 總體結構本系統(tǒng)物理架構設計采用縱向分層、層內模塊之間松耦合的原則，保證各組件的物理獨立性，增強系統(tǒng)可擴展性，有利于系統(tǒng)分模塊開發(fā)部署。研發(fā)類課題管理系統(tǒng)自身的物理組件主要分為五類：1、業(yè)務流程類；2、業(yè)務支持類；3、業(yè)務管理類；4、基礎支持類；5、UAAPFRAME類。共10個組件包。1、 業(yè)務流程類組件是課題管理業(yè)務的主線，完成從課題立項、合同備案到付款申請的課題管理主體業(yè)務流程；包括課題過程管理組件包。2、 業(yè)務支持類組件對業(yè)務流程類構件提供業(yè)務的支持，保證業(yè)務的順利開展；包括業(yè)務支持組件包、合作資源組件包。3、 業(yè)務管理類組件實現(xiàn)對業(yè)務的管理統(tǒng)計，包括對成果的發(fā)布和查詢統(tǒng)計；包括業(yè)務

24、管理組件包。4、 基礎支撐類組件是業(yè)務實現(xiàn)的根基，在此基礎上對業(yè)務流程類、業(yè)務支持類和業(yè)務管理類構件提供技術的支撐；包括通用工具組件包和流程管理組件包。5、 UAAPFRAME類組件提供了通用的和統(tǒng)一授權平臺和企業(yè)門戶集成，以及角色權限管理的功能；包括認證管理組件包，機構管理組件包，權限管理組件包及集成管理組件包。系統(tǒng)縱向分為四層，分別是展現(xiàn)層、業(yè)務邏輯處理層、數(shù)據(jù)持久層以及數(shù)據(jù)存儲層。展現(xiàn)層主要負責向用戶展示系統(tǒng)界面，響應用戶在界面上的操作，并轉化為系統(tǒng)請求傳輸至業(yè)務邏輯處理層調用對應的業(yè)務功能組件。業(yè)務邏輯處理層在實現(xiàn)業(yè)務功能時使用數(shù)據(jù)持久層中的持久化數(shù)據(jù)對象，由數(shù)據(jù)持久層將對持久化數(shù)據(jù)對

25、象轉化為對數(shù)據(jù)存儲層物理數(shù)據(jù)實體的訪問。5.2 組件定義5.2.1 課題管理課題管理組件包內部的4個組件屬于業(yè)務功能組件，實現(xiàn)與課題申報、備案以及付款這一生命周期的業(yè)務流程相關的功能。這些業(yè)務功能屬于業(yè)務需求方最關心的主體業(yè)務功能，是本系統(tǒng)的核心功能組件。課題管理組件包從展現(xiàn)層接收用戶請求，經(jīng)過處理后調用基礎支持類組件，完成業(yè)務流程流轉及流程附件管理；調用數(shù)據(jù)映射組件完成流程及業(yè)務實體數(shù)據(jù)增刪改查；調用UAAPFRAME組件獲取操作用戶的所屬機構、角色及權限。5.2.2 業(yè)務管理業(yè)務管理組件包內部的3個組件屬于業(yè)務功能組件，實現(xiàn)主管部門對課題管理業(yè)務進行高階管理統(tǒng)計分析的業(yè)務功能。這些業(yè)務功能

26、能夠幫助主管部門更好地對課題管理業(yè)務進行總結、分析，屬于本系統(tǒng)的額外增值功能，并不影響主體業(yè)務功能。業(yè)務管理組件包從展現(xiàn)層接收用戶請求，經(jīng)過處理后調用基礎支持類組件，完成業(yè)務流程流轉及流程附件管理；調用數(shù)據(jù)映射組件完成流程及業(yè)務實體數(shù)據(jù)增刪改查；調用UAAPFRAME組件獲取操作用戶的所屬機構、角色及權限。5.2.3 業(yè)務支持業(yè)務支持組件包內部的1個組件屬于業(yè)務功能組件，是課題管理類組件正常運行的前提，為課題管理類組件運行提供前置條件。主要實現(xiàn)業(yè)務參數(shù)配置。業(yè)務支持組件包從展現(xiàn)層接收用戶請求，調用數(shù)據(jù)映射組件完成系統(tǒng)業(yè)務參數(shù)增刪改查；調用UAAPFRAME組件獲取操作用戶的所屬機構、角色及權限

27、。5.2.4 合作資源合作資源組件包內部的2個組件屬于業(yè)務功能組件，是課題管理類組件正常運行的前提，為課題管理類組件運行提供前置條件。主要實現(xiàn)課題管理組件包中課題相關的合作機構、專家資源的管理。合作資源組件包從展現(xiàn)層接收用戶請求，經(jīng)過處理后調用基礎支持類組件，完成業(yè)務流程流轉及流程附件管理；調用數(shù)據(jù)映射組件完成流程及業(yè)務實體數(shù)據(jù)增刪改查；調用UAAPFRAME組件獲取操作用戶的所屬機構、角色及權限。5.2.5 通用工具通用工具組件包內部的2個組件屬于系統(tǒng)管理組件，是確保系統(tǒng)正常平穩(wěn)運行的工具組件。系統(tǒng)各業(yè)務功能組件均需調用通用工具組件包的組件實現(xiàn)日志記錄查詢分析、異常捕獲及處理。5.2.6 集

28、成平臺調用集成平臺調用組件包內部的2個組件屬于接口類組件，調用應用集成平臺業(yè)務流程管理平臺（BPM）、內容管理平臺（ECM）提供的流程管理、文件管理服務。系統(tǒng)各業(yè)務功能組件均需調用集成平臺調用組件包的組件實現(xiàn)業(yè)務流程發(fā)起、流轉及終止，文件上傳下載刪除等功能。5.2.7 UAAPFRAMEUAAPFRAME組件包內部的4個組件屬于系統(tǒng)管理組件及接口組件，實現(xiàn)系統(tǒng)登錄認證、用戶管理、組織機構管理、權限管理、業(yè)務數(shù)據(jù)字典項管理、集成管理等功能。UAAPFRAME組件從EII接收用戶機構同步信息，與統(tǒng)一授權系統(tǒng)雙向同步用戶角色權限信息，與AD集成進行用戶登錄認證。5.2.8 系統(tǒng)維護組件包系統(tǒng)維護組件

29、包內部的數(shù)據(jù)庫維護組件屬于系統(tǒng)管理組件，實現(xiàn)數(shù)據(jù)庫備份、恢復功能。數(shù)據(jù)庫維護組件主要調用數(shù)據(jù)庫備份、恢復的。5.3 組件接口設計設計編號接口名稱接口描述接口提供組件目標組件接口調用方式1文件管理接口文件上傳、下載、查詢文檔管理組件課題過程管理組件包、業(yè)務管理組件包、合作資源組件包方法調用2、流程管理接口流程創(chuàng)建、流轉、終止、查詢流程、查詢工作項等工作流組件課題過程管理組件包、成果管理、信息發(fā)布組件方法調用3異常處理接口捕獲程序運行過程中出現(xiàn)的系統(tǒng)異常、業(yè)務異常，并記錄系統(tǒng)異常時間、描述、所屬模塊、線程等信息。對于業(yè)務異常則統(tǒng)一處理用戶反饋頁面。異常處理組件所有組件方法調用4日志管理接口將程序運

30、行過程中的信息按照DEBUG, INFO, WARN, ERROR, FATAL五個級別記錄到日志文件中日志管理組件所有組件方法調用5合作機構查詢接口使用統(tǒng)一的方法對合作機構數(shù)據(jù)實體進行查詢，并返回查詢結果。機構組件課題過程管理組件包方法調用6專家查詢接口使用統(tǒng)一的方法對合作專家數(shù)據(jù)實體進行查詢，并返回查詢結果。專家組件立項課題組件、備案課題組件。方法調用6 系統(tǒng)部署6.1 網(wǎng)絡結構圖研發(fā)類課題管理系統(tǒng)部署于開發(fā)銀行內部生產(chǎn)網(wǎng)段，與外聯(lián)網(wǎng)之間使用防火墻邏輯隔離，內外網(wǎng)之間沒有數(shù)據(jù)訪問需求。系統(tǒng)用戶（包括總分行用戶）均需要使用內網(wǎng)終端訪問本系統(tǒng)。與研發(fā)類課題管理系統(tǒng)需要進行集成的外部系統(tǒng)，如BP

31、M、ECM、ESB、AD系統(tǒng)也均部署于開發(fā)銀行內部生產(chǎn)網(wǎng)段，從網(wǎng)絡策略上確保可以互相訪問。6.2 部署模式依據(jù)現(xiàn)有服務器資源，設計了2套部署模式，其中模式一為單機運行，只使用1個服務器分區(qū)，部署數(shù)據(jù)庫服務器、web應用服務器（WAS）、USE運行環(huán)境以及研發(fā)類課題管理系統(tǒng)應用軟件包；模式二為雙機運行，設計思路為服務器1和服務器2互備運行，2臺服務器均部署數(shù)據(jù)庫服務器、web應用服務器（WAS）、USE運行環(huán)境以及研發(fā)類課題管理系統(tǒng)應用軟件包，其中服務器1上的web應用服務器（WAS）、USE運行環(huán)境以及研發(fā)類課題管理系統(tǒng)應用軟件包為運行狀態(tài)，數(shù)據(jù)庫服務器為待機狀態(tài)，服務器2上的web應用服務器

32、（WAS）、USE運行環(huán)境以及研發(fā)類課題管理系統(tǒng)應用軟件包為待機狀態(tài)，數(shù)據(jù)庫服務器為運行狀態(tài)。具體如下圖所示。模式一的優(yōu)點為節(jié)省服務器資源，缺點為系統(tǒng)可用性較低，一旦發(fā)生服務器故障，系統(tǒng)將無法對外提供服務。模式二的優(yōu)點為系統(tǒng)可用性較高，一旦發(fā)生服務器故障，可利用事先準備的腳本，快速完成服務器切換，確保系統(tǒng)服務正常?？紤]到本系統(tǒng)應用場景、重要性以及服務器資源情況，目前采用模式一進行部署。在服務器資源能夠滿足的情況下，優(yōu)先考慮采用方案2進行部署。7 關鍵技術及公用機制7.1 關鍵技術設計7.1.1 SCA服務面向服務架構（SOA）要求我們將業(yè)務需求分解為若干個功能相對獨立、可被復用的服務單元，通過

33、服務之間的相互調用完成一定的業(yè)務功能。這種架構有利于業(yè)務重組，它通過服務的復用加速企業(yè)的信息系統(tǒng)開發(fā)，達到快速響應企業(yè)業(yè)務變化的要求。OASIS組織發(fā)布的服務組件架構（SCA）是一組SOA編程模型規(guī)范，它描述了利用面向服務架構（SOA）來構建應用程序和系統(tǒng)的模型；SCA裝配模型定義了構成一個SCA系統(tǒng)的各種構件和他們之間的關系，包括：組合構件（Composite）、構件（Component）、服務（Service）、引用（Reference）、實現(xiàn)（Implementation）等。系統(tǒng)構件裝配是SCA裝配模型的實現(xiàn)。通過可視化的方式定義組合構件（Composite）中的構件（Componen

34、t）組成，定義構件中包含的服務（Service）、引用（Reference），構件引用所指向的構件服務等。下圖是構件裝配的概念結構圖，從圖中可以看出，一個構件由服務（Service）、引用（Reference）、實現(xiàn)（Implementation）和屬性（Property）四部分組成。一個構件可以有一個或多個服務、引用和屬性，但只能有一個實現(xiàn)。服務和引用的接口（Interface）描述了其操作的范圍；通過服務綁定（Service Binding）來對外暴露服務的訪問；通過引用綁定（Reference Binding）來消費服務。組合構件（Composite）作為構件的容器對構件進行包裝和組織，

35、并作為可發(fā)布的單元進行部署。圖7.1 SCA服務構件裝配圖對上圖術語的詳細解釋如下表所示：術語 解釋 服務（Service） Service是一系列業(yè)務功能的集合，將某一個業(yè)務功能通過服務的方式暴露出來，供外部應用訪問。服務可以用多種形式的訪問協(xié)議進行訪問，比如Web Service，JMS，Stateless SessionBean等。 引用（Reference） 構件的功能由其它構件的服務提供，在構件環(huán)境中通過引用來進行指定。在運行時，根據(jù)配置找到引用對應的服務，并注入到構件實現(xiàn)當中，類似依賴注入。 屬性（Property） 對構件實現(xiàn)的字段設置默認值，在構件環(huán)境運行時，會把值注入到相應的

36、字段中。 接口（Interface） 接口定義了服務對外提供的功能范圍，描述了服務所包含的操作以及操作的參數(shù)。USE中支持兩種接口的描述形式：Java Interfaces和WSDL PortType。 綁定（Binding） 綁定定義了服務的生產(chǎn)和消費的方式，以及訪問服務所采用的協(xié)議。綁定可以分為服務綁定和引用綁定。服務綁定，描述了客戶端可以使用什么樣的機制來調用服務。引用綁定描述了采用什么機制來調用外部的服務。 實現(xiàn)（Implementation） 構件的實現(xiàn)是構件服務功能的具體實現(xiàn)，SCA規(guī)范支持各種各樣的構件實現(xiàn)方式，如：Java實現(xiàn)，C#實現(xiàn)，Python實現(xiàn)等等。USE目前只支持J

37、ava實現(xiàn)，以及USE特有的邏輯構件實現(xiàn)。 構件（Component） 對外提供服務功能的單元，定義了構件的實現(xiàn)方式，以及構件提供了哪些服務，引用和屬性。 組合構件（Composite） 由一組具有業(yè)務上相互聯(lián)系的構件組成，本身也可以定義對外的服務和引用，其實質是一種更大粒度的構件。 裝配（Assembly） 將一組具有業(yè)務上相互聯(lián)系的構件組織到一個組合構件（Composite）中，在這個組合構件中定義構件的服務，引用關系，構件的實現(xiàn)等，這個過程稱為裝配。 構件包（Contribution） 在USE中構件包（Contribution）作為一個部署單元，在其中包含了構件，構件實現(xiàn)以及一些額外需

38、要的資源，比如：頁面流、邏輯流、運算邏輯、數(shù)據(jù)集、jsp文件等。 提升（Promote） 組合構件中可以把構件中的服務通過promote的方式對服務進行重新包裝，添加外部用戶的訪問方式。同時組合構件引用是對一個或多個構件的一個或多個引用的提升，所有的構件引用共享相同的配置。 連線（wire） 定義源構件引用連接到目標構件的服務上，給引用進行賦值。7.1.2 構件裝配下圖是構件裝配的概念圖：圖7.2 SCA服務構件裝配概念圖由上圖可知：· 一個組合構件可以包含多個構件。 · 每個構件可以定義多個服務和引用；服務和引用通過"接口描述"來描述其業(yè)務功能。USE

39、中包含了兩種類型的接口描述：Java接口和WSDL PortType。 · 可以為每個構件指定至多一個構件實現(xiàn)。· 構件實現(xiàn)是構件服務功能的具體實現(xiàn)。 · 可以為一個構件定義多個構件屬性。 · 可以為服務和引用定義一個或多個綁定信息。· 服務和引用的默認綁定是SCA綁定。 7.1.3 SDO數(shù)據(jù)對象Service Data Object，服務數(shù)據(jù)對象。為服務和應用提供一個簡單統(tǒng)一的數(shù)據(jù)模型。USE支持SDO2.0規(guī)范，在數(shù)據(jù)傳輸過程缺省的對象類型是SDO對象。SDO對象可以根據(jù)實際的數(shù)據(jù)源決定它的實際表現(xiàn)，在使用過程中可以不必考慮其后端的實際數(shù)

40、據(jù)類型和構建方法。7.2 公用機制說明7.2.1 USE平臺應用技術架構模型的三個維度軟件技術架構用來處理軟件高層次結構的設計和實施。它以精心選擇的形式將若干結構元素進行裝配，從而滿足系統(tǒng)主要功能需求，并滿足其他非功能性需求，如可靠性、可伸縮性、可移植性和可用性。我們用多個視圖或視角組成的模型來描述它，該模型包括下列視角：l 邏輯結構視圖邏輯結構主要支持功能性需求，即在為用戶提供功能方面系統(tǒng)所應該提供的能力。一般基于流程的方式進行系統(tǒng)功能的分解，將系統(tǒng)分解為一系列的關鍵抽象，這些抽象大多數(shù)來自于面向功能的問題域，可以劃分為業(yè)務流程問題域、業(yè)務問題域、技術問題域，采用組件的方式表現(xiàn)為業(yè)務流程、領

41、域框架、應用基礎框架、技術組件。l 技術實現(xiàn)視圖技術實現(xiàn)視圖從具體實現(xiàn)技術視角描述了系統(tǒng)的分層結構，每層均具有良好定義的職責，某層子系統(tǒng)依賴同一層或低一層的子系統(tǒng)，從而最大程度地減少了具有復雜模塊依賴關系，得到層次式的簡單策略，提高系統(tǒng)的穩(wěn)定度，減少開發(fā)量?；赨SE平臺的JavaEE系統(tǒng)的技術分層結構自底向上包括資源層、邏輯層、服務層、流程層和協(xié)同層。l 非功能需求視圖非功能需求包括系統(tǒng)的安全性、可管理性、可靠性、可用性和擴展性，定義了系統(tǒng)如何滿足功能需求之外的其他隱式需求。這些需求可以通過一個監(jiān)控管理框架來提供，該框架包含系統(tǒng)共性能監(jiān)控、應用與平臺配置、管理儀表盤、服務水平與質量、仿真與虛

42、擬化等。圖 71 USE平臺的應用技術架構模型在面向服務的體系架構中，針對上述的架構模型，規(guī)劃了支撐上述3個視角的技術框架和規(guī)范：l 組件模型系統(tǒng)的邏輯結構由一系列組件組成，每個組件分別負責一組功能，提供本地調用接口、對外服務、用戶操作界面等。組件規(guī)范定義了組件自身的特性，設計系統(tǒng)邏輯結構的過程，實際上就是將系統(tǒng)拆分為組件的過程（系統(tǒng)分解過程參看USE平臺項目實施方法論）。在一個基于組件的應用系統(tǒng)中，組件包是可部署的單元，因此系統(tǒng)的物理結構是以組件包為基本單位的。l 基于組件的技術架構基于組件包的技術架構是針對JavaEE系統(tǒng)技術分層結構的具體規(guī)劃，系統(tǒng)將根據(jù)業(yè)務和技術的需要分解為多個組件包，

43、在組件包內根據(jù)邏輯功能特性劃分為協(xié)同層、流程層、服務層、邏輯層和資源層。在實現(xiàn)組件包的過程中，允許對上述層次進行裁減，例如很多組件包就只有服務層和邏輯層代碼即可。l 管理監(jiān)控架構為了滿足對應用系統(tǒng)的非功能性需求，在JavaEE應用系統(tǒng)中需要一個面向管理監(jiān)控的框架，這個框架采用微內核結合擴展點的架構模式，能夠靈活的擴展管理監(jiān)控內容，以便于非功能需求的實現(xiàn)與具體業(yè)務的實現(xiàn)相分離。7.2.2 USE ServerUSE Server（USE運行環(huán)境）是支撐SOA應用和服務的運行環(huán)境，USE Server 由SCA（Service Component Architecture）容器、構件運行環(huán)境、頁面

44、流引擎、邏輯流引擎、系統(tǒng)服務、基礎服務等核心模塊組成。USE Server是一個面向SOA的基礎設施，實現(xiàn)了SOA的核心編程模型SCA 1.0、SDO 2.1的標準規(guī)范。根據(jù)USE平臺的建設目標，USE Server保障了SOA應用或服務穩(wěn)定、安全、可靠、高效、可擴展地運行。USE Server運行在標準的J2EE應用服務器之上，支持主流的應用服務器（如：WebSphere、WebLogic、JBoss、Tomcat等）和主流的數(shù)據(jù)庫（Oracle、DB2、MS SQL Server、Informix、Sybase等）。7.2.3 USE數(shù)據(jù)處理USE采用的編程模型是：流程+數(shù)據(jù)+人機交互。其

45、中流程包括：頁面流和邏輯流；數(shù)據(jù)包括持久化實體和非持久化實體，并采用SDO標準來描述這些數(shù)據(jù)的格式；人機交互采用富客戶端控件來實現(xiàn)。以下內容闡述在USE的技術架構下，數(shù)據(jù)是如何存儲，如何被獲取以及如何在流程和客戶端之間傳遞。 數(shù)據(jù)上下文USE中所有的數(shù)據(jù)都是通過數(shù)據(jù)上下文來存儲的。數(shù)據(jù)上下文是一個有固定分區(qū)的數(shù)據(jù)容器，它采用統(tǒng)一的Xpath語法對對象樹進行取值和設值操作。在使用數(shù)據(jù)上下文時，只需要使用Xpath定位數(shù)據(jù)即可，不需要知道內部的具體數(shù)據(jù)類型。數(shù)據(jù)上下文分為多種數(shù)據(jù)區(qū)，其中包括請求上下文數(shù)據(jù)區(qū)、會話上下文數(shù)據(jù)區(qū)、頁面流上下文數(shù)據(jù)區(qū)、邏輯流上下文數(shù)據(jù)區(qū)、MUO上下文數(shù)據(jù)區(qū)

46、、流程上下文數(shù)據(jù)區(qū)。如下圖所示。圖7.3 USE數(shù)據(jù)上下文每一種數(shù)據(jù)區(qū)的生命周期是不同的，由USE Server統(tǒng)一管理。詳細描述參下表所示。數(shù)據(jù)區(qū)名稱使用模塊描述請求上下文頁面流請求上下文數(shù)據(jù)區(qū)中放置的是一個完整的Http Request/Response過程中頁面流產(chǎn)生的數(shù)據(jù)。當一個頁面流實例接受到一個HTTP請求后，引擎創(chuàng)建一個請求上下文數(shù)據(jù)區(qū)，當引擎響應這個HTTP Request后，引擎銷毀這個請求上下文數(shù)據(jù)區(qū)。頁面流上下文頁面流上下文數(shù)據(jù)區(qū)和一個頁面流實例的生命周期是一致的。會話上下文會話上下文的生命周期與HTTP Session的生命周期是一致的，會話上下文數(shù)據(jù)區(qū)的數(shù)據(jù)來自與HT

47、TP Session中的數(shù)據(jù)。邏輯流上下文邏輯流邏輯流上下文數(shù)據(jù)區(qū)的生命周期與邏輯流的生命周期是一致的。當一個邏輯流實例結束時，引擎會銷毀這個邏輯流對應的邏輯流上下文數(shù)據(jù)區(qū)。MUO上下文MUO上下文是受管用戶對象上下文，是為了在邏輯流、運算邏輯中防止用戶隨意使用Http會話中的數(shù)據(jù)，而構造的一個受管數(shù)據(jù)上下文區(qū)。用戶需要在USE Governor中配置MUO中需要存放的數(shù)據(jù)對象，這些對象才能在邏輯流和運算邏輯中使用。 數(shù)據(jù)流轉過程圖7.4 USE數(shù)據(jù)流轉過程示例如上圖所示，USE的核心數(shù)據(jù)流程是：1. 客戶端瀏覽器發(fā)起HTTP請求，通過Key/Value對的形式將數(shù)據(jù)傳輸?shù)椒掌?/p>

48、端；2. 頁面流引擎接到HTTP請求后將Key/Value對象轉換為SDO對象，傳遞給頁面流實例；3. 頁面流調用邏輯流時，將SDO對象傳遞給邏輯流引擎；4. 邏輯流引擎又會將SDO對象傳遞給邏輯流實例；5. 邏輯流調用運算構件時，傳入SDO對象。運算構件訪問數(shù)據(jù)服務完成業(yè)務操作后產(chǎn)生SDO類型的返回結果；6. 邏輯流引擎將返回結果傳遞給頁面流引擎；7. 頁面流引擎又將返回結果轉發(fā)給JSP頁面；8. JSP頁面響應這個HTTP請求，返回到客戶端瀏覽器，顯示返回結果。完成一次數(shù)據(jù)流轉。USE數(shù)據(jù)傳輸過程，缺省的對象類型是SDO對象，但是用戶也可以采用自定義類型，比如POJO、W3C DOM等等。

49、 數(shù)據(jù)處理過程在介紹了數(shù)據(jù)上下文的分類和數(shù)據(jù)流轉的原理后，再分析一下頁面流、邏輯流各自的數(shù)據(jù)處理過程。1. 頁面流數(shù)據(jù)處理頁面流使用到的數(shù)據(jù)上下文分為三個數(shù)據(jù)區(qū)，包括會話上下文數(shù)據(jù)區(qū)，請求上下文數(shù)據(jù)區(qū)，頁面流上下文數(shù)據(jù)區(qū)。如下圖所示。圖7.5 頁面流數(shù)據(jù)處理示意圖(1) 會話上下文數(shù)據(jù)區(qū)會話上下文數(shù)據(jù)區(qū)存儲的數(shù)據(jù)是當前用戶所在的HTTP會話數(shù)據(jù)的一個映射。開發(fā)頁面流的時候可以使用s:XPATH_EXPRESSION來訪問會話數(shù)據(jù)區(qū)中的數(shù)據(jù)，訪問會話數(shù)據(jù)區(qū)中表達式的前綴為s:。(2) 請求上下文數(shù)據(jù)區(qū)請求上下文數(shù)據(jù)區(qū)中放置的是一個完整的Http Request/Response過程

50、中產(chǎn)生的數(shù)據(jù)，當USE的頁面引擎接受到一個HTTP Request的請求后，它會將這個請求的Key/Value參數(shù)按照規(guī)則，轉換成一個或者多個Java對象放入到請求上下文數(shù)據(jù)區(qū)中；也可以使用復制圖元訪問或創(chuàng)建請求上下文數(shù)據(jù)區(qū)中的數(shù)據(jù)；調用業(yè)務邏輯或者服務的返回值也可以設置到請求上下文的數(shù)據(jù)區(qū)中。訪問請求上下文數(shù)據(jù)區(qū)中的數(shù)據(jù)可以采用r:XPATH_EXPRESSION或者不帶前綴，直接使用XPATH_EXPRESSION訪問請求上下文數(shù)據(jù)區(qū)中的數(shù)據(jù)。(3) 頁面流上下文數(shù)據(jù)區(qū)頁面流上下文數(shù)據(jù)區(qū)存儲的是在頁面流里定義的變量或者對象，訪問頁面流上下文的表達式為f:XPATH_EXPRESSION。頁

51、面流上下文數(shù)據(jù)區(qū)的數(shù)據(jù)生命周期相當于頁面流流程級別的變量，在一個頁面流實例中的不同的頁面，業(yè)務邏輯，賦值操作都可以使用頁面流上下文中的數(shù)據(jù)。2. 邏輯流數(shù)據(jù)處理邏輯流使用到的數(shù)據(jù)上下文為兩個數(shù)據(jù)區(qū)，包括MUO上下文數(shù)據(jù)區(qū)和邏輯流上下文數(shù)據(jù)區(qū)。(1) MUO上下文數(shù)據(jù)區(qū)MUO上下文數(shù)據(jù)區(qū)中存放的是受管用戶數(shù)據(jù)對象，訪問的方式采用m:XPATH_EXPRESSION樣式的表達式來訪問和更新數(shù)據(jù)。在邏輯流中涉及用戶數(shù)據(jù)（HttpSession）傳遞的過程時，因只允許對用戶的部分數(shù)據(jù)有存取權限，這時就需要根據(jù)session中的部分數(shù)據(jù)構造一個受控的用戶數(shù)據(jù)對象，用戶只能對該受管用戶數(shù)據(jù)對象做操作。(2

52、) 邏輯流上下文數(shù)據(jù)區(qū)邏輯流上下文數(shù)據(jù)區(qū)和頁面流的請求上下文數(shù)據(jù)區(qū)比較類似，如果把一個邏輯流比作是一個Java方法，那么邏輯流上下文數(shù)據(jù)區(qū)中的數(shù)據(jù)包含的是這個Java方法傳入的參數(shù)，以及這個方法中定義的成員變量。訪問邏輯流請求上下文的數(shù)據(jù)直接采用XPATH_EXPRESSION訪問，不需要加任何前綴。7.2.4 事務控制中小系統(tǒng)使用USE平臺提供的事務控制機制，在邏輯構件對應的邏輯流作為事務控制的邊界。設計中事務控制的邊界限制在邏輯流內部，即不存在跨多個邏輯流的事物控制。如果初始設計時存在事物邊界跨越多個邏輯流的情況，則多個邏輯流需要合并成單個邏輯流。7.2.5 操作日志USE平臺下對日志的邏輯劃分為三類：服務器日志、應用日志和構件包日志。其中應用日志供開發(fā)人員定位調試系統(tǒng)使用，包含跟蹤日志、引擎日志和系統(tǒng)日志，通過平臺提供的USE Governor配置實現(xiàn)；構件包日志記錄用戶登錄和訪問系統(tǒng)功能模塊的業(yè)務日志，由系統(tǒng)開發(fā)人員根據(jù)用戶需求實現(xiàn)具體功能?！安僮魅罩尽笔怯脩羰褂弥行∠到y(tǒng)過程中，對各構件包級功能操作的記錄。中小系統(tǒng)可以通過操作日志模塊對用戶登錄和功能操作記錄進行展現(xiàn)。系統(tǒng)提供統(tǒng)一的操作日志記錄方法，SCMSLogUtil類統(tǒng)一處理日志信息。在各個功能模塊中，只需要將用戶的操作信息放入HttpServletRequest中即可。8 系統(tǒng)重用設計8.1