基于.NET的協同監理平臺的設計與實現

蔣 怡，蔡 瓊*,2，易雪蓉

1.武漢工程大學計算機科學與工程學院，湖北 武漢 430205；2.智能機器人湖北省重點實驗室（武漢工程大學），湖北 武漢 430205

在互聯網發達的現今，企業廣泛地采用信息管理系統來進行日常辦公，信息平臺要滿足企業需求且擁有良好的安全性。安全可靠的管理系統是合理使用信息，防止他人非法獲取信息或者損壞信息的保障。此外，信息系統的訪問控制和權限管理至關重要，已有不少文檔對影響系統安全的訪問控制［1-2］問題進行研究。

在信息管理系統中，存在多種實現權限動態分配［3-4］的方法，僅操作對象而言，就有基于用戶的和基于角色［5-6］的兩種。基于用戶［7］的分配方法是直接給用戶分配權限，而基于角色的權限分配方法是一種間接的分配方法［8］，即將用戶分成很多不同的組，同一組的用戶獲得同樣的權限，這種方法具有很好的靈活性、安全性和通用性［9］。Ferraiol［10-12］對基于角色的訪問控制（Role Based Access Control，RBAC）的相關術語進行了統一，建立了RBAC技術的參考模型，此模型在信息系統中的使用極大地簡化了安全管理的難度。

在監理［13-14］企業中，項目工作需要監理人員與第三方人員協同完成。而多方人員的參與使得系統的權限控制變得復雜。為解決該問題，本文改進了基于角色的訪問控制技術，將角色劃分層次后再賦予用戶，從而使整個系統層次分明［15］，權限管理也變得更加簡單。

本平臺協助監理企業完成施工組織設計、監理規劃編制和旁站監理三項重點工作，實現了監理企業與第三方人員的協同辦公，使信息在多方之間的流轉更加準確迅速。在監理規劃編制模塊調用Web Office插件實現了文檔在線批注功能，加快了員工的日常工作進程，給企業帶來了巨大的益處。在旁站監理模塊，實現了手機端與Web端的交互，監理人員在施工現場使用手機端采集信息并上傳數據庫，以供Web端獲取并展示，實現了數據的高效傳遞。

1 協同監理平臺的設計

監理的一系列工作都在項目的基礎上進行，由項目經理創建項目并分配人員，項目中的人員是動態的，所分配的項目權限也是動態的，可以隨時回收或改變。

根據監理企業的辦公需求，平臺重點實現了施工組織設計模塊、監理規劃編制模塊和旁站監理模塊。具體如下：

1）施工組織設計：工程開工前，總監理工程師（總監）組織專業監理工程師（專監）審查施工單位報審的施工組織設計材料。專監需要根據編審程序合規性；編制內容完整性；施工進度、方案及質量保證措施合同符合性；勞動力、材料、設備等資源供應計劃；安全技術措施強制性條文符合性；“四新”和施工總平面布置這7個方面進行審查，若審核不通過，審批凍結，若通過則提交總監進行審查，總監審查不通過則退回專監重查，若符合要求則由總監簽認，項目監理機構報送建設單位審核，若合格則審批完成，若不通過則退回總監重審。施工單位上傳的文件由平臺調用Html.Beginform方法提交給后端進行保存，審批流程中專監上傳、總監退回等操作狀態的改變，是運用ASP.NET MVC的Url.Action方法提交后端處理而實現的。施工組織設計審批流程如圖1（a）所示。

2）監理規劃編制：專監按照模板文件進行特定項目的監理規劃編制，具體包括工程概況；監理工作的范圍、內容、目標；監理工作依據；監理組織形式、人員配備及進、退場計劃和監理人員崗位職責；監理工作制度；工作質量控制；工程造價控制；工程進度控制；安全生產管理的監理工作；合同與信息管理；組織與協調；監理工作設施和ISO9001：2015國際質量管理體系標準在工程中的應用。總監對專監編寫的文件進行在線審批，審批全部通過后，上交建設單位審批，若合格則編制完成，若不通過，需要專監重新編寫。在該模塊的審批流程中，平臺運用Web Office控件實現了在線審批功能。審批狀態分為專監保存、總監保存、總監待審核、總監駁回和總監審核合格五項，狀態的更改通過使用Ajax異步刷新技術提交后端處理從而實現。監理規劃編制流程如圖1（b）所示。

圖1 審批流程圖：（a）施工組織設計，（b）監理規劃編制，（c）旁站監理Fig.1 Flowchart of approvals：（a）construction organization design，（b）supervision plan，（c）side station supervision

3）旁站監理：旁站監理模塊中，Web端負責旁站監理方案的編制與現場旁站記錄的展示，移動端負責施工現場的信息采集工作。旁站監理方案編制的模塊設計與監理規劃編制相同，只在內容上有所改變，旁站編制的內容為：旁站范圍與內容；旁站程序和方式；旁站監理人員主要職責和旁站監理依據四項。Web端還進行旁站記錄的展示，監理人員在施工現場使用手機端采集信息填寫旁站記錄，并上傳至服務器數據庫，Web端從數據庫中獲取信息并按列表的形式在頁面中展示，形成旁站列表。旁站監理編制流程如圖1（c）所示。

為了實現模塊功能，達到協同辦公的目的，用戶權限的分配至關重要。只有擁有對應權限的用戶才可以實現某個特定的操作，否則無法對項目進行任何操作。針對這一情況，本文改進了基于角色的訪問控制技術，引入角色層級這一概念，將角色分層后再賦予用戶。所有角色的分層如表1所示。

表1 角色層級表Tab.1 Hierarchy of roles

在實際的平臺中，數據庫是采用Microsoft SQL Server2012實現的。具體到數據庫結構方面，與權限相關的數據庫表主要包含Roles表、Uesr?roles表、Rolelevel表、Employee表、Users表、Epspre表以及Eproject表。數據庫關系圖如圖2所示。其中Roles表是角色表，定義了所有的角色。Uesr?roles表是用戶權限表，連接用戶和角色。Rolelevel表是角色層級表，即上述的5個層級。Users表是用戶表，即存放用戶。Employee表是員工表，存放企業中所有員工信息。Epspre表是項目人員表，用來記錄某個項目動態分配的員工的信息。Epro?ject表是項目表，用于存放項目信息。

圖2 數據庫表結構圖Fig.2 Table structure of database

根據企業的實際情況，對角色進行分析歸類，從而使平臺層次更加清晰，項目創建時人員的動態選擇也變得簡單，滿足了企業在監理工作中的需求。

2 協同平臺的實現

平臺是基于.NET框架，使用Visual Studio 2017進行開發，數據庫選擇的是Microsoft SQL Server2012。

2.1 角色賦予和項目角色分配

在新建員工時，平臺通過下拉菜單選取不同層級下的角色賦予用戶，如圖3所示。平臺使用input標簽將value=“@item.name”即角色名提交給后端，后端新建ApplicationUser對象，并使用Cre?ateAsync方法異步創建用戶實現了人員到用戶的添加過程，然后使用 AddToRoleAsync（user.Id，ro?leName）方法將用戶與角色綁定到一起，最后調用db.SaveChangesAsync方法異步更新數據庫，實現了角色的賦予。

圖3 角色分配圖Fig.3 Assignment of roles

用戶登錄后，平臺就會判斷用戶的角色，根據用戶所在的角色層級，跳轉到特定的頁面。如果用戶未被包含在某個項目內，則該用戶無法訪問平臺各模塊。此處是運用IsAuthority（id，“Office Staff”，db）方法判斷用戶是否擁有訪問模塊的權限，如果沒有即返回Redirect方法重定位到提醒無法查閱的頁面。

當該用戶參與某個項目后，項目列表就會顯示用戶參與的項目，此處需要在數據庫中進行條件搜索，滿足 e.EmployeeID.Equals（User.Identity.Name）條件即異步輸出，并在頁面中獲取并展示。

在創建項目時，需要動態分配人員。在人員分配頁面，平臺根據角色層級獲取人員。以獲取角色級別為1的公司管理層人員為例，后端查找數據庫中滿足e.RoleLevelID==1與e=＞e.IsEPS==true這兩項條件的數據形成列表輸出，再調用SelectList（ComManager，“Id”，“RoleCNName”）方法，并將其賦給ViewBag.ComManagerList參數，以供前端獲取并展示。

2.2 施工組織設計

在施工組織設計模塊，施工方上傳的文件由前端調用Html.Beginform方法提交給后端，后端采用try catch語句進行文件的保存，主要包括審批ID、文件名、文件路徑、文件上傳人等參數。專監需要對材料進行審核，并在對應文本域內填寫意見，文本意見由HtmlTextArea控件提交給模型。若材料不合格則點擊駁回，審批凍結。若合格則點擊提交按鈕提交給總監，總監會綜合專監意見進行審核，若不合格則駁回給專監重審，若通過則點擊提交按鈕，上交建設單位審查。若建設單位審查通過，即審批完成，若不通過，則駁回給總監重審。登錄用戶的角色都會被實時獲取，以總監駁回給專監重審一步為例，前端使用Url.Action函數提交審批ID給后端，后端獲取審批ID進行處理，首先根據獲取的審批ID號查找到審批項，當滿足審批狀態為總監審查狀態且總監是項目內成員時，審批狀態改變為專監審查，并調用db.SaveChangesAsync函數保存更改至數據庫，最后再將審批ID返回給施工組織設計審批頁面，頁面設計如圖4所示。

圖4 施工組織設計審批頁面Fig.4 Interface of approving construction organization design

2.3 監理規劃編制

在監理規劃編制模塊，專監上傳文件的路徑都根據編制ID進行保存，路徑為“～/UploadFiles/EPS/BZFile”+bZ.BZID。在辦公中，所有用戶的操作均會被記錄，例如這句代碼就記錄了某位總監接受了提交的監理規劃編制文件：

bZLog.BZDetail=“總監”+TempBZFile.File?UpPerson+“接受提交的監理規劃編制文件：”+TemplateNames［k-1］。

監理規劃編制頁面如圖5所示。

圖5 監理規劃編制頁面Fig.5 Interface of compiling supervision plan

在監理規劃審批中，平臺調用Web Office控件實現了文檔的在線審批，以總監點擊待審文件進行文檔在線批注為例，調用Web Office控件首先需要觸發Web Office初始化方法：

＜SCRIPT language=javascript event=NotifyCtrlReady for=WebOffice1＞

WebOffice1_NotifyCtrlReady（）

＜/SCRIPT＞

平臺會先執行＜object＞標簽內的方法，填充監理規劃文件，最后調用WebOffice1_NotifyCtrlReady方法進行文檔初始化。總監完成對文檔的編輯后，申請上傳文件，平臺模擬表單提交，將文件虛擬路徑和編制ID提交給控制器處理，實現總監在線審批文件的功能。文件狀態會因不同用戶的操作而發生改變，例如當專監提交文件后，文件就會變成總監待審核狀態，后端首先需要判斷用戶的操作是否為提交，然后改變文件狀態，步驟流程向后跳轉一步，并向前端傳遞有文件待審的信號。

2.4 旁站監理

旁站監理方案編制的具體實現與監理規劃編制大致相同，僅在文件內容上有所改變。只有旁站監理方案審批通過后，才允許進行施工現場的旁站工作。在施工現場，監理人員使用手機端創建普通旁站監理記錄以進行信息的錄入工作，現場照片的獲取由平臺調用cordova-plugin-camera插件實現。當監理人員錄入信息完畢，即可點擊提交按鈕將數據發送給后端處理，后端創建旁站記錄保存前端提交的數據，然后獲取該用戶的所有旁站記錄并加入該條記錄，再調用db.SaveChanges方法更新到數據庫。此時，Web端即可訪問數據庫獲取該條最新上傳的新記錄。手機端的普通旁站監理頁面如圖6所示。

圖6 普通旁站監理頁面Fig.6 Interface of normal side station supervision

手機端采集到的旁站信息都會顯示在Web端的旁站列表中，可以點擊旁站記錄列表查看詳細信息。旁站列表頁面設計如圖7所示。

圖7 旁站列表界面Fig.7 Interface of side station supervision list

在該頁面，實現了根據旁站類型和旁站名稱進行檢索的功能，前端提交項目ID、旁站類型ID和搜索關鍵字參數給后端處理，后端運用Contains方法尋找包含搜索關鍵字的旁站記錄，再運用Equals方法尋找前端指定旁站類型的旁站記錄，最后返回篩選結果以供前端展示。

3 結 語

本文設計了基于.NET的協同監理平臺，實現了施工組織設計、監理規劃編制與旁站監理三項模塊且運行正常。采用Cordova技術實現了跨平臺旁站監理APP，實現了手機端和Web端的互動，使信息的傳遞更加準確迅速。改進了基于角色的訪問控制技術，使平臺的層次更加清晰，充分保證了平臺的安全性、高效性和靈活性，也有利于今后的平臺功能拓展。本平臺在項目人員選擇部分還可以進一步改善，例如運用機器學習等相關知識，對所有員工操作記錄進行分析，實現人員的自動推薦功能。