基于服務化理論指導下的合同管理信息系統的需求開發與構建實現

韓瀟影，劉利民

?

基于服務化理論指導下的合同管理信息系統的需求開發與構建實現

韓瀟影，劉利民

（甘肅省氣象局氣象信息與技術裝備保障中心，甘肅 蘭州 730020）

通過服務化理論的引入和實踐，應用自頂向下的設計方法，基于.NET開發構建了覆蓋合同起草、審批、存檔全流程信息化支撐的合同管理信息系統。圍繞用戶和業務兩個主體進行需求的分析與開發，基于原型交互進行業務的梳理與確認；開發構建中以分層設計為基礎，實現了前端UI層、中間層和數據服務層的完全獨立和開放。整體應用建設在需求開發與設計階段投入資源過半，但是整體建設投資比傳統應用開發減少了約1/3；在良好的業務擴展框架基礎上，同時兼顧了良好的投資效益比。

服務化；合同管理；信息系統；需求開發；構建實現

0 引言

合同作為企業生產經營過程的重要法律文書依據，是企業管理過程中的重要資源。為了改變現有的手工管理過程，將數據轉化為可以提供決策的信息，單位決定建立合同管理信息系統，一期建設目標為合同相關文件和數據的信息化，包括合同業務流程的信息化支撐。

在本次合同管理信息系統建設過程中，通過服務化理論的引入和實踐，自頂向下的設計以及項目分包編碼等方法的支撐，較好的實現了初期建設任務，并為以后的業務擴展打下了良好的架構支撐基礎。

1 服務化理論的選擇

合同管理信息系統在建設之初就需要考慮未來其它業務模式[1]的擴展（如車輛管理、耗材管理等）并考慮多終端的應用可能，所以在需求分析階段，就否定了傳統的CS應用開發部署模式。

在綜合分析之后，決定采用基于服務化理論的系統規劃與設計，在實際設計中服務器只會向客戶端發送JSON，主要的設計步驟包括：整體架構設計，業務需求抽象與建模，服務規劃與層次劃分，服務內流程、數據、契約（接口）定義和技術選型。業務服務化意味著后端無法再繼續使用非服務化場景下的技術（如動態頁面技術），雖然傳統框架（如SpringMVC、Mybatis、Hibernate、Structs、Entity-Framework、ASP.NET MVC、ASP.NET Web Form等）同樣也可以實現服務化，但這些框架在最初創建時都會考慮非服務化場景，當服務器僅僅向客戶端發送JSON時，這些框架顯得臃腫和低效，并且此類傳統框架基本上都是利用反射機制創建和運行，反射意味著運行性能的部分損失；所以合同管理信息系統開發過程中選擇直接使用ASP.NET Web API作為底層服務實現的驅動。

2 合同業務管理范圍

合同信息管理系統對合同從起草、審批、存檔的全流程做信息化管理，實現紙質合同的數據信息化存檔，基于信息化數據的快速檢索；對合同相關附件、回款記錄、以及回款發票信息的存檔和檢索。在合同管理信息系統中，將完整覆蓋整個合同管理的業務范圍，對于合同洽談、審批痕跡等，都需要做到數據采集與信息化存檔管理。

圖1 合同業務流程圖

3 需求開發過程概述

在需求調研與開發階段，圍繞用戶和業務兩個主體展開[2]，主要的工作任務是理清業務，充分理解并挖掘用戶界面、用戶交互。在合同信息管理系統中，因為需要考慮未來其它業務模式的擴展，所以對于系統業務相關的組織結構和用戶的管理，是在合同業務管理范圍之上的；按照前述的合同業務流程清單，通過和具體的業務人員做訪談、溝通，按照業務環節、業務操作的結構總結出具體的需求闡述，以及其他必要的非功能性需求定義（如對安全性、性能、使用環境、用戶主題等的描述說明）。

3.1 合同業務管理的“用戶”開發

任何應用系統的設計與開發，最重要的原則就是用戶交互[3]。用戶是應用系統的中心，所有其他一切都圍繞用戶開展。在服務化的應用系統中，一個具體的功能被定義為服務，使用服務的用戶可以是人，還可能是其他內部或外部系統。如在合同到期前通過郵件系統自動告知合同所有人，此時的郵件系統就是合同管理信息系統的一個潛在的用戶。在合同管理信息系統中，最終的用戶定義如下表1。

表1 用戶定義表

Tab.1 User defined tables

3.2 合同業務管理的“業務”梳理與開發

業務的梳理與開發[4]主要分兩類，一是每一類用戶分別參與哪些業務，二是一個業務分別有哪些用戶參與。在需求開發過程中，重點是理清每一個業務中包含哪些環節，每一個環節中包含哪些操作。也就是說，從結構化的角度，一個業務由多個環節構成，一個環節由多個操作構成；環節與操作分別對應了設計及后續階段的模塊和功能。在同一個環節中，業務操作之間應該具有高內聚度。在Web用戶界面上，同一個環節的多個操作通常表現為一兩個完整的頁面，其中包含一個入口頁面，其他業務操作可以通過局部視圖、對話框等方式與用戶進行交互操作。

對于業務環節的需求開發，主要集中在：如何進入業務操作，業務操作需要哪些輸入數據，這些數據如何展示；對數據執行何種操作，業務操作完成后會產生和返回哪些數據，這些數據如何展示。

具體在合同管理信息系統中，合同起草業務包括合同基本信息錄入，同時可能存在合同附件信息上傳；在合同存檔業務中，必須上傳合同附件信息。所以，對這兩個業務做梳理結果如圖2。

其中，【合同起草】作為一個業務模塊，包括合同基本信息錄入，合同附件上傳兩個功能環節；一個功能定義一個請求，一個功能完成一定的業務操作，多個功能共同構成一個模塊。在具體實現中，功能被創建為模塊類的方法（函數），在數據庫中實現時被創建為存儲過程，其包含一組輸入參數、輸出參數或者輸入輸出參數。基于服務化的實現，所有的功能都只向客戶端發送JSON 數據，而不會包含任何動態前端代碼，比如 HTML、CSS 或 JS。

對于【合同附件上傳】分別定義兩個功能，其原則是“每一個環節僅僅只有一個用戶角色執行各種操作”；同時考慮業務環節之間應該具有低耦合關系，當一個環節僅涉及一個用戶角色時，可以避免模塊之間的角色依賴。合同起草和合同存檔，都是通過獨立的角色在權限ACL（訪問控制列表）控制下分別啟動業務功能模塊的，合同起草時，完成合同基本信息的錄入；合同的審批與執行信息由合同審批環節進行確認；合同附件信息可能在起草時已經確認，也可能在存檔時進行最終的確認。

對于【生成合同編號】業務功能，可以考慮以后臺服務的形式提供，但是實際開發中考慮到存在提供靈活的合同編號預檢索功能的潛在要求，以前臺UI的形式進行業務模塊功能的設計支撐，業務體現為一個獨立的“獲取合同編號”環節，對該功能在設計時直接定義具體的輸入參數、輸出參數，供后續開發實現。

圖2“合同起草”與“合同存檔”業務環節定義

圖3 “生成合同編號”業務環節定義

3.3 合同信息管理系統的“原型”開發

在實際的需求調研開發過程中，終端用戶很難清晰的描述他們的實際需求，這給需求調研和分析帶來極大的阻力。實際建設過程中，通過采用原型設計的方式，制作一個相對較友好的交互原型，并且對原型也進行了快速的迭代設計與開發，實現了終端用戶需求的進一步深入挖掘和完善。

合同信息管理系統的第一版原型設計，與第二版原型設計[5]，具體見圖4、圖5；實際開發過程中，第二版開發結果直接被復用為系統前端的成果，減小了重復開發的工作量，實現了系統的快速開發。

圖4 合同信息管理系統的第一版原型設計

圖5 合同信息管理系統的第二版原型設計與系統前端展示基本一致

4 應用構建過程概述

4.1 應用構建原則

動態View：傳統的Web應用動態視圖通常是由服務器生成的。這意味著服務器不僅僅要執行業務和數據操作，還必須負責View的創建，這是一個非常耗時的過程。實際上，在服務器完成響應前，用戶其實是在等待當中。既然如此，就不如盡快向客戶端響應數據，完成請求，降低服務器負擔，由 客戶端自己完成數據呈現；客戶端能自己完成的事，就讓它們自己去完成；在此過程中，客戶端還可以提供更友好的交互體驗。

無狀態：不在服務器端使用Session，不因為Session對服務器資源造成壓力。不使用Session使得整個應用系統構建在無狀態的HTTP協議之上。

數據排序：傳統排序一般要依賴于數據庫的ORDER BY或應用服務器的內存排序，無論如何都會增加服務器的負擔。實際除了數據庫分頁查詢需要的排序，所有其他排序不在服務器端完成，而是發送到客戶端后，由客戶端自己完成排序。開發中選擇通過JS的Array.sort進行排序處理。

異步：目前在Java中沒有實現請求、數據操作以及響應的完善的異步支持，請求接收后將在請求上下文中同步完成請求處理和響應。開發中選擇.NET框架進行開發支撐，通過使用async/await實現異步操作支持，充分利用ADO.NET提供程序自身的異步操作方法，改善了性能。

4.2 應用分層實現

合同信息管理系統整體的應用分為三層設計實現：前端、中間層和數據服務[6]。

前端：考慮到未來的系統擴展性，前端可以是桌面瀏覽器、移動瀏覽器或者移動原生應用；從數據的角度，前端被設計為是可以識別JSON數據的應用。實際開發中基于Material Design Components（谷歌發布的可以同時滿足不同終端需要的Web組件），不使用其他第三方UI和數據框架，僅使用jQuery創建和操作動態DOM，它們是基于H5和CSS3的代碼，可同時滿足在桌面和移動瀏覽器上使用，為后期應用的可移植性打好了基礎。

中間層：中間層選擇了.NET（C#）。客戶端請求由Web API直接轉交給目標服務API，再由服務API提交到數據庫，通過存儲過程執行數據操作。當數據操作完成后，返回結果到服務API，由服務API負責將數據轉換為JSON，最后由Web API將JSON發回客戶端。在整個過程中，參數映射、數據編碼（總是使用UTF-8）、數據結果集到實體類對象的轉換、實體類對象到JSON的轉換等都遵循服務設計的約定。

數據服務：數據庫復用了單位現有的SQL SERVER，簡化部署與維護的成本。在不改變前端和中間層的情況下，數據服務還可以是MySQL或者是其他數據服務。為后續可能的數據庫平臺轉移提供了最大的便利。

圖6 合同信息管理分層實現-前端代碼輸出展示

實際開發中基于分層的快速編碼[7]輸出見圖7、圖8，具體輸出內容包括：

（1）前端代碼，包括所有必要的HTML、CSS和JS：

每一個功能的HTML文件和對話框HTML；

每一個功能的服務器API請求代碼，API請求參數封裝和驗證，API返回JSON的解析和呈現（數據綁定）。

（2）中間代碼：

每一個功能API的參數封裝和映射，每一個實體類，以及每一個實體類的JSON序列化。JSON序列化不是通過反射實現的，而是完全通過TextWriter實現，效率更高；

圖7 合同信息管理分層實現-中間層代碼編碼

圖8 合同信息管理分層實現-數據庫代碼編碼

ADO.NET數據庫操作代碼，ADO.NET數據結果集合到實體對象的轉換代碼；

Web API基礎框架代碼。

（3）數據庫代碼：

每一個功能對應的存儲過程，每一個存儲過程內部的參數驗證代碼，每一個存儲過程內部的INSERT、UPDATE、DELETE和SELECT；

每一個分頁存儲過程內分頁查詢代碼；

每一個存儲過程內結果集或輸出參數的返回代碼；

每一個實體類對應的視圖代碼，每一個視圖的實現。

5 項目實踐結果

服務化的本質，無非就是client發起調用，中間層某個組件攔截調用信息，序列化后將信息傳輸到server端，server端收到調用請求后反序列化，根據請求詳細發起實際調用后返回響應傳輸回給client端。本系統中基于對服務化理論的實際探索，在需求分析與開發階段就貫徹自頂向下的服務化設計理念，功能模塊設計完全根據業務、權限、性能、交互和導航要求進行開發實現；在面向對象設計的基礎上提供更完善的“邏輯單元”復用性的設計與開發，支持服務之間根據業務需求來組合調用。

通過基于快速迭代原型的需求開發與設計，整體的開發周期比傳統應用開發周期縮短了一半，實際人力投入減少約1/3；完全基于服務化理念的功能設計，可以較好的支撐后續業務范圍的擴展，具有良好的投資效益比。

[1] 張昱, 田晉, 楊功廷. 校園黨校結業考試系統的設計與實現[J]. 軟件, 2015, 36(4): 73-75.

[2] 楊春霞, 王曉軍, 何子偉, 基于IRP的建設項目合同管理信息系統規劃[J], 建筑經濟, 2014(08): 5(12): 289-336.

[3] 永明, 蘇斌. 面向服務架構體系的研究[J]. 計算機技術與發展, 2007 , 17(3): 132-134.

[4] 胡智慧, 朱斐. 基于B/S 架構的培訓部課程管理系統的設計與實現[J]. 軟件, 2015, 36(8): 79-83.

[5] 熊宗炬, 周波, 李劍陽. 突發事件應急通信系統原型設計[J]. 軟件, 2016, 37(4): 04-07.

[6] 馬亮, 肖建軍, 劉錦文. 西部形變數據分中心在提升數據服務能力方面的探究[J]. 軟件, 2016, 37(01): 120-121.

[7] 焦華. 基礎編程的思考方法[J]. 軟件, 2018, 39(3): 57-62.

The Development and Construction of the Contract Management Information System Based on the Service Theory

HAN Xiao-ying, LIU Li-ming

(The meteorological information and technical equipment support center of the Gansu Meteorological Bureau, Lanzhou, Gansu, 730020)

Through the introduction and practice of service-oriented theory, the top-down design method is applied, and a contract management information system supporting the whole process of contract drafting, approval and archiving is built based on. NET development. Around the two main bodies of users and businesses, we need to analyze and develop requirements, and sort out and confirm business based on prototype interaction. Based on layering design, we realized the complete independence and openness of the front tier UI layer, the middle tier and the data service layer. The overall application construction has invested more than half of the resources in the demand development and design stage. However, the overall construction investment has been reduced by about 1/3 compared with the traditional application development. On the basis of a good business expansion framework, a good investment benefit ratio has also been taken into account.

Service; Contract management; Information system; Demand development; Construction and implementation.

p315.69

A

10.3969/j.issn.1003-6970.2018.11.025

韓瀟影(1982-)，女，工程師，主要研究方向：計算機科學與技術；劉利民(1972-)，男，高工，主要研究方向：大氣科學。

韓瀟影，劉利民. 基于服務化理論指導下的合同管理信息系統的需求開發與構建實現[J]. 軟件，2018，39（11）：110-115