檢港查驗系統“廢物原料”子系統的設計與實現

張禹+仲吉偉+李政良

摘要：該子系統包含了從申報、審批和放行全部的檢驗檢疫流程，用戶角色涵蓋了整個廢物原料檢驗檢疫流程中每一個參與者，全程實現了工作無紙化和電子化，為企業節約成本，縮短檢驗檢疫周期。致力于打造一個業務規范邏輯清晰功能完善的系統，提供良好的用戶使用體驗。

關鍵詞：廢物原料子系統；JavaEE；SSH框架；數據庫

1開發部分

主要儀器及工作條件：

本項目需要在營口港信息公司進行，要求隨時接入營口港后臺服務器數據庫等。此外，本項目為JavaEE項目，其中使用的SSH框架、SVN等關鍵技術都是開源免費的。

系統開發軟、硬件環境最低要求具體如下：

JavaEE 1.6 Apache Tomcat 6.0 Eclipse 3.4 ApacheAnt 1.7 SVN 1.6.6操作系統Windows7 8G內存酷睿i7CPU ITG以上硬盤以太網卡

1.1系統模塊功能需求（以審批功能為例）

監管科收到企業申報的信息，首先根據海運提單等相關數據判定企業申報的信息是否準確，如不準確將數據退回，企業重新修改：如準確，將等待衛檢科和鑒定科分別對該批次廢物檢驗檢疫的結果上報，并判定上報的信息是否準確規范，如不準確將數據退回，相應科室進行修改；如準確，將數據填寫完整的“廢物原料工作聯系單”確認保存，并將“廢物原料工作聯系單”傳至保稅科，保稅科根據海運提單等相關數據核查無誤后，將該批次廢物原料進行放行。

1.2技術路線需求

系統設計應當遵循國際標準，采用B/S多層的體系結構，對外查詢利用模塊必須采用B/S結構：B/S結構應采用先進的WEB應用開發技術，支持多并發進程、多用戶：保證系統具有開放性，能支持跨平臺運行，采用JavaEE體系結構，保證系統可以運行在各種操作系統平臺上：系統開發必須采用通用開發工具，不得使用任何封閉的專用開發工具，避免由此引起的系統不兼容等問題。

1.3系統設計

1.3.1系統結構

根據需求分析，“廢物原料”子系統可分為廢物原料申報、廢物原料審批和廢物原料放行子功能模塊。

1.3.2數據庫設計

數據庫是存儲在物理設備上的，邏輯數據庫設計工作完成后，需要為邏輯數據模型選擇適合應用環境的物理結構，即存儲結構與存取方法。

該項目的ER圖（以單據數據為例）如圖1所示。

數據庫表的設計，如表1所示。

1.4系統實現

1.4.1功能模塊實現描述（以審批功能為例）

“監管科查驗員”類型的用戶選擇任意申報單，進入申報單詳情頁面，將查看到申報單詳細信息。該類型的用戶還將看到衛檢科查驗員和鑒定科查驗員的檢驗檢疫結論及結果。如對結論存在質疑，可點擊對應的重新審批按鈕，改變單據的審批狀態：如果用戶點擊“單據確認”按鈕，則該單據的審批結果將改為“待放行”，審批類型將改為“已審批”。該用戶將無法變更當前單據所有數據，當前單據將進入放行流程。

1.4.2功能模塊代碼實現（以審批功能為例）

2測試部分

2.1系統測試

系統測試是驗證系統是否滿足了需求規格的定義，找出與需求規格不符的地方，提出更加完善的方案。系統測試發現問題之后要經過調試找出錯誤原因和位置，然后進行改正。最后，還要進行有針對性的壓力測試。

2.1.1系統測試目標

各項具體測試目標如下（以審批功能為例）：

廢物原料審批模塊測試。測試本子模塊能否正常運行，能否實現新申報單的詳情列表，能否顯示具體一條申報單的數據，能否完成申報單的修改等功能。

2.1.2測試用例的設計與結果

功能測試以審批功能為例，如表2所示。

測試結果表明，功能已經符合預期要求。

2.2壓力測試

根據需求分析中關于并發性的要求，系統能夠承受300個用戶的并發訪問。啟動300個用戶（線程），對待以下頁面進行持續5分鐘的并發訪問，測試結果如圖2所示。

測試結果表明，系統可以輕松應對實際工作中對于壓力和并發性的需求。

3成果總結

隨著系統設計的完善和軟件的測試，整個系統逐步的成功實施了。子系統（整個系統）致力于實現每個港口企業、部門業務員的業務獨立，對自己權限內的工作任務及時有效的完成：同時對港口業務數據的統計提供了更加準確快捷的方法，避免了人工統計中可能出現的錯誤；而且對于港口查驗的機關單位實時監督管理口岸業務并和港口業務部門的工作聯動起到了重要作用。

當然，個別功能目前還有一些有待改進之處，在系統安全性和操作界面的的友好程度上仍有待提升。后期再系統使用中將不斷完善此類瑕疵，爭取早日將系統打造成功能完善、界面獨特的檢驗檢疫輔助系統，為檢驗檢疫工作創新提供助力！endprint