韓瀟影，劉利民

?

基于服務(wù)化理論指導(dǎo)下的合同管理信息系統(tǒng)的需求開發(fā)與構(gòu)建實(shí)現(xiàn)

韓瀟影，劉利民

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

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

服務(wù)化；合同管理；信息系統(tǒng)；需求開發(fā)；構(gòu)建實(shí)現(xiàn)

0 引言

合同作為企業(yè)生產(chǎn)經(jīng)營過程的重要法律文書依據(jù)，是企業(yè)管理過程中的重要資源。為了改變現(xiàn)有的手工管理過程，將數(shù)據(jù)轉(zhuǎn)化為可以提供決策的信息，單位決定建立合同管理信息系統(tǒng)，一期建設(shè)目標(biāo)為合同相關(guān)文件和數(shù)據(jù)的信息化，包括合同業(yè)務(wù)流程的信息化支撐。

在本次合同管理信息系統(tǒng)建設(shè)過程中，通過服務(wù)化理論的引入和實(shí)踐，自頂向下的設(shè)計(jì)以及項(xiàng)目分包編碼等方法的支撐，較好的實(shí)現(xiàn)了初期建設(shè)任務(wù)，并為以后的業(yè)務(wù)擴(kuò)展打下了良好的架構(gòu)支撐基礎(chǔ)。

1 服務(wù)化理論的選擇

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

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

2 合同業(yè)務(wù)管理范圍

合同信息管理系統(tǒng)對合同從起草、審批、存檔的全流程做信息化管理，實(shí)現(xiàn)紙質(zhì)合同的數(shù)據(jù)信息化存檔，基于信息化數(shù)據(jù)的快速檢索；對合同相關(guān)附件、回款記錄、以及回款發(fā)票信息的存檔和檢索。在合同管理信息系統(tǒng)中，將完整覆蓋整個合同管理的業(yè)務(wù)范圍，對于合同洽談、審批痕跡等，都需要做到數(shù)據(jù)采集與信息化存檔管理。

圖1 合同業(yè)務(wù)流程圖

3 需求開發(fā)過程概述

在需求調(diào)研與開發(fā)階段，圍繞用戶和業(yè)務(wù)兩個主體展開[2]，主要的工作任務(wù)是理清業(yè)務(wù)，充分理解并挖掘用戶界面、用戶交互。在合同信息管理系統(tǒng)中，因?yàn)樾枰紤]未來其它業(yè)務(wù)模式的擴(kuò)展，所以對于系統(tǒng)業(yè)務(wù)相關(guān)的組織結(jié)構(gòu)和用戶的管理，是在合同業(yè)務(wù)管理范圍之上的；按照前述的合同業(yè)務(wù)流程清單，通過和具體的業(yè)務(wù)人員做訪談、溝通，按照業(yè)務(wù)環(huán)節(jié)、業(yè)務(wù)操作的結(jié)構(gòu)總結(jié)出具體的需求闡述，以及其他必要的非功能性需求定義（如對安全性、性能、使用環(huán)境、用戶主題等的描述說明）。

3.1 合同業(yè)務(wù)管理的“用戶”開發(fā)

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

表1 用戶定義表

Tab.1 User defined tables

3.2 合同業(yè)務(wù)管理的“業(yè)務(wù)”梳理與開發(fā)

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

對于業(yè)務(wù)環(huán)節(jié)的需求開發(fā)，主要集中在：如何進(jìn)入業(yè)務(wù)操作，業(yè)務(wù)操作需要哪些輸入數(shù)據(jù)，這些數(shù)據(jù)如何展示；對數(shù)據(jù)執(zhí)行何種操作，業(yè)務(wù)操作完成后會產(chǎn)生和返回哪些數(shù)據(jù)，這些數(shù)據(jù)如何展示。

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

其中，【合同起草】作為一個業(yè)務(wù)模塊，包括合同基本信息錄入，合同附件上傳兩個功能環(huán)節(jié)；一個功能定義一個請求，一個功能完成一定的業(yè)務(wù)操作，多個功能共同構(gòu)成一個模塊。在具體實(shí)現(xiàn)中，功能被創(chuàng)建為模塊類的方法（函數(shù)），在數(shù)據(jù)庫中實(shí)現(xiàn)時被創(chuàng)建為存儲過程，其包含一組輸入?yún)?shù)、輸出參數(shù)或者輸入輸出參數(shù)。基于服務(wù)化的實(shí)現(xiàn)，所有的功能都只向客戶端發(fā)送JSON 數(shù)據(jù)，而不會包含任何動態(tài)前端代碼，比如 HTML、CSS 或 JS。

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

對于【生成合同編號】業(yè)務(wù)功能，可以考慮以后臺服務(wù)的形式提供，但是實(shí)際開發(fā)中考慮到存在提供靈活的合同編號預(yù)檢索功能的潛在要求，以前臺UI的形式進(jìn)行業(yè)務(wù)模塊功能的設(shè)計(jì)支撐，業(yè)務(wù)體現(xiàn)為一個獨(dú)立的“獲取合同編號”環(huán)節(jié)，對該功能在設(shè)計(jì)時直接定義具體的輸入?yún)?shù)、輸出參數(shù)，供后續(xù)開發(fā)實(shí)現(xiàn)。

圖2“合同起草”與“合同存檔”業(yè)務(wù)環(huán)節(jié)定義

圖3 “生成合同編號”業(yè)務(wù)環(huán)節(jié)定義

3.3 合同信息管理系統(tǒng)的“原型”開發(fā)

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

合同信息管理系統(tǒng)的第一版原型設(shè)計(jì)，與第二版原型設(shè)計(jì)[5]，具體見圖4、圖5；實(shí)際開發(fā)過程中，第二版開發(fā)結(jié)果直接被復(fù)用為系統(tǒng)前端的成果，減小了重復(fù)開發(fā)的工作量，實(shí)現(xiàn)了系統(tǒng)的快速開發(fā)。

圖4 合同信息管理系統(tǒng)的第一版原型設(shè)計(jì)

圖5 合同信息管理系統(tǒng)的第二版原型設(shè)計(jì)與系統(tǒng)前端展示基本一致

4 應(yīng)用構(gòu)建過程概述

4.1 應(yīng)用構(gòu)建原則

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

無狀態(tài)：不在服務(wù)器端使用Session，不因?yàn)镾ession對服務(wù)器資源造成壓力。不使用Session使得整個應(yīng)用系統(tǒng)構(gòu)建在無狀態(tài)的HTTP協(xié)議之上。

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

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

4.2 應(yīng)用分層實(shí)現(xiàn)

合同信息管理系統(tǒng)整體的應(yīng)用分為三層設(shè)計(jì)實(shí)現(xiàn)：前端、中間層和數(shù)據(jù)服務(wù)[6]。

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

中間層：中間層選擇了.NET（C#）?？蛻舳苏埱笥蒞eb API直接轉(zhuǎn)交給目標(biāo)服務(wù)API，再由服務(wù)API提交到數(shù)據(jù)庫，通過存儲過程執(zhí)行數(shù)據(jù)操作。當(dāng)數(shù)據(jù)操作完成后，返回結(jié)果到服務(wù)API，由服務(wù)API負(fù)責(zé)將數(shù)據(jù)轉(zhuǎn)換為JSON，最后由Web API將JSON發(fā)回客戶端。在整個過程中，參數(shù)映射、數(shù)據(jù)編碼（總是使用UTF-8）、數(shù)據(jù)結(jié)果集到實(shí)體類對象的轉(zhuǎn)換、實(shí)體類對象到JSON的轉(zhuǎn)換等都遵循服務(wù)設(shè)計(jì)的約定。

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

圖6 合同信息管理分層實(shí)現(xiàn)-前端代碼輸出展示

實(shí)際開發(fā)中基于分層的快速編碼[7]輸出見圖7、圖8，具體輸出內(nèi)容包括：

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

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

每一個功能的服務(wù)器API請求代碼，API請求參數(shù)封裝和驗(yàn)證，API返回JSON的解析和呈現(xiàn)（數(shù)據(jù)綁定）。

（2）中間代碼：

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

圖7 合同信息管理分層實(shí)現(xiàn)-中間層代碼編碼

圖8 合同信息管理分層實(shí)現(xiàn)-數(shù)據(jù)庫代碼編碼

ADO.NET數(shù)據(jù)庫操作代碼，ADO.NET數(shù)據(jù)結(jié)果集合到實(shí)體對象的轉(zhuǎn)換代碼；

Web API基礎(chǔ)框架代碼。

（3）數(shù)據(jù)庫代碼：

每一個功能對應(yīng)的存儲過程，每一個存儲過程內(nèi)部的參數(shù)驗(yàn)證代碼，每一個存儲過程內(nèi)部的INSERT、UPDATE、DELETE和SELECT；

每一個分頁存儲過程內(nèi)分頁查詢代碼；

每一個存儲過程內(nèi)結(jié)果集或輸出參數(shù)的返回代碼；

每一個實(shí)體類對應(yīng)的視圖代碼，每一個視圖的實(shí)現(xiàn)。

5 項(xiàng)目實(shí)踐結(jié)果

服務(wù)化的本質(zhì)，無非就是client發(fā)起調(diào)用，中間層某個組件攔截調(diào)用信息，序列化后將信息傳輸?shù)絪erver端，server端收到調(diào)用請求后反序列化，根據(jù)請求詳細(xì)發(fā)起實(shí)際調(diào)用后返回響應(yīng)傳輸回給client端。本系統(tǒng)中基于對服務(wù)化理論的實(shí)際探索，在需求分析與開發(fā)階段就貫徹自頂向下的服務(wù)化設(shè)計(jì)理念，功能模塊設(shè)計(jì)完全根據(jù)業(yè)務(wù)、權(quán)限、性能、交互和導(dǎo)航要求進(jìn)行開發(fā)實(shí)現(xiàn)；在面向?qū)ο笤O(shè)計(jì)的基礎(chǔ)上提供更完善的“邏輯單元”復(fù)用性的設(shè)計(jì)與開發(fā)，支持服務(wù)之間根據(jù)業(yè)務(wù)需求來組合調(diào)用。

通過基于快速迭代原型的需求開發(fā)與設(shè)計(jì)，整體的開發(fā)周期比傳統(tǒng)應(yīng)用開發(fā)周期縮短了一半，實(shí)際人力投入減少約1/3；完全基于服務(wù)化理念的功能設(shè)計(jì)，可以較好的支撐后續(xù)業(yè)務(wù)范圍的擴(kuò)展，具有良好的投資效益比。

[1] 張昱, 田晉, 楊功廷. 校園黨校結(jié)業(yè)考試系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J]. 軟件, 2015, 36(4): 73-75.

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

[3] 永明, 蘇斌. 面向服務(wù)架構(gòu)體系的研究[J]. 計(jì)算機(jī)技術(shù)與發(fā)展, 2007 , 17(3): 132-134.

[4] 胡智慧, 朱斐. 基于B/S 架構(gòu)的培訓(xùn)部課程管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J]. 軟件, 2015, 36(8): 79-83.

[5] 熊宗炬, 周波, 李劍陽. 突發(fā)事件應(yīng)急通信系統(tǒng)原型設(shè)計(jì)[J]. 軟件, 2016, 37(4): 04-07.

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

[7] 焦華. 基礎(chǔ)編程的思考方法[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-)，女，工程師，主要研究方向：計(jì)算機(jī)科學(xué)與技術(shù)；劉利民(1972-)，男，高工，主要研究方向：大氣科學(xué)。

韓瀟影，劉利民. 基于服務(wù)化理論指導(dǎo)下的合同管理信息系統(tǒng)的需求開發(fā)與構(gòu)建實(shí)現(xiàn)[J]. 軟件，2018，39（11）：110-115