基于RBAC的智慧管廊信息管理系統的設計與實現

發布時間：2023-07-10 10:10

第一章緒論 1

1.1論文研究背景及意義 1

1.2國內外相關研究現狀 1

1.3論文研究內容 2

1.4論文組織結構 3

第二章智慧管廊信息管理相關知識 4

2.1智慧管廊系統 4

2.2RBAC 模型 5

2.3Spring Boot 6

2.4MyBatis 與 MySQL 6

2.5攔截器與過濾器 7

2.6 IDEA 與 Maven 8

2.7本章小結 8

第三章智慧管廊信息管理支撐系統需求分析與架構設計 10

3.1智慧管廊信息管理支撐系統 10

3.2智慧管廊信息管理支撐系統需求分析 10

3.2.1系統用例分析 10

3.2.2功能需求分析 12

3.2.3性能需求分析 15

3.3智慧管廊信息管理支撐系統架構設計 16

3.3.1系統功能模塊 16

3.3.2系統分層架構 19

3.4本章小結 22

第四章智慧管廊信息管理支撐系統的設計與實現 24

4.1智慧管廊信息管理支撐系統功能 24

4.2智慧管廊信息管理角色樹的設計與實現 24

4.2.1角色樹的設計 24

4.2.2角色樹的實現 25

4.3智慧管廊信息管理登錄模塊的設計與實現 27

4.3.1登錄模塊的設計 27

4.3.2登錄模塊的實現 28

4.4智慧管廊信息管理鑒權模塊的設計與實現 31

4.4.1鑒權功能的分類 31

4.4.2操作權限的設計 31

4.4.3操作權限的實現 32

4.4.4數據權限的設計 34

4.4.5數據權限的實現 36

4.5智慧管廊信息管理審批模塊的設計與實現 39

4.5.1審批模塊的設計 39

4.5.2審批模塊的實現 40

4.6智慧管廊用戶信息管理的設計與實現 43

4.6.1用戶信息管理的設計 43

4.6.2用戶信息管理的實現 44

4.7智慧管廊群組信息管理的設計與實現 50

4.7.1群組信息管理的設計 50

4.7.2群組信息管理的實現 50

4.8智慧管廊信息管理性能需求的設計與實現 52

4.8.1穩定性需求的設計與實現 52

4.8.2安全性需求的設計與實現 53

4.8.3復用性需求的設計與實現 53

4.8.4可擴展性需求的設計與實現 53

4.9本章小結 54

第五章智慧管廊信息管理支撐系統功能測試及性能分析 55

5.1智慧管廊信息管理支撐系統功能測試 55

5.1.1角色樹功能測試 55

5.1.2登錄功能測試 57

5.1.3操作權限功能測試 59

5.1.4數據權限功能測試 61

5.1.5審批功能測試 62

5.1.6用戶信息管理功能測試 64

5.1.7群組信息管理功能測試 67

5.2智慧管廊信息管理支撐系統性能分析 68

5.3本章小結 71

第六章總結與展望 72

6.1總結 72

6.2展望 73

參考文獻 75

致謝 77

攻讀學位期間取得的研究成果 78

第一章緒論

1.1論文研究背景及意義

根據國家“智慧城市”發展戰略，“智慧管廊”理念己經被提出，并且己經有相關人員進行了相應的研究與開發。“智慧管廊”系統聚焦于智慧水務管廊、智慧燃氣管廊、智慧園區管廊、智慧建筑管廊等核心業務的研究開發與應用推廣, 是智慧化城市需要解決的重要工作之一。其中物聯網技術是“智慧管廊”系統的基礎與支撐［1］。

物聯網是指將生活中的物理設備和網關相連，再通過相應的協議將網關與網絡相連，進而達到通過網絡控制物理設備的目的。物理設備之間可以通過傳播媒介進行信息交換和通信，以實現智能化的定位、跟蹤和管理等功能。同時隨著 5G時代的到來，物聯網賴以生存的數據傳輸也得到了強有力的保障⑵。

地下管廊是保證城市運行的基礎設施，方便各種工作可以統一建設和管理。

智慧管廊是指管廊本體、附屬設施及入廊管線（高壓電纜、燃氣、給水、排水、通信等）與人實現互聯互通，從而實現從感知、傳輸、控制、大數據處理、指揮調度一體化的協同解決方案［%智慧管廊平臺為城市地下綜合管廊智慧化監控、智能運維、智能決策做技術支撐，并利用了物聯網、云計算、GIS （地理信息系統）技術、大數據等先進的技術。智慧管廊使得管廊運行與管理更加高效, 從而使得城市管理與運行更加智能。

智慧管廊信息管理系統是智慧管廊的“大腦”，本文主要針對智慧管廊信息管理支撐系統中的不同角色和不同權限的人員的用戶登錄、鑒權、功能交互、用戶信息與群組信息管理進行研究，為智慧管廊系統業務模塊提供功能支撐，實現了智慧管廊的視頻監控、入廊作業、巡檢維護、應急指揮和管理考核等工作全天候和通視野運維監控，達到了管廊設備運行穩定、管理效率高、資源最大化利用的目標。

1.2國內外相關研究現狀

信息管理系統最初的定義是“信息管理系統是一個人機交互系統，它將PC （個人計算機）作為載體，通過分析制定的計劃，利用已有的決策模型以及數據庫來提供信息，實現管理功能，進而完成企業和組織的正常運行”。其中信息管理的定義主要是指系統對需要管理的信息進行收集、傳遞、存儲與處理，不同的用戶根據自己的需求來管理自己需要的信息，從而實現多用戶共享，可以滿足實際需求中不同職業和不同部門的信息管理⑷。

當今主流的一些信息管理系統都是多用戶系統，而國內外對于多用戶系統的權限設計已經相對成熟，國內外也已經有很多著名的0A (辦公自動化)系統設計且已經應用到實際工作中，同時也取得了一定的成果，這些都是智慧管廊信息管理系統設計的重要參考［%智慧管廊信息管理系統既要借鑒通用信息管理系統功能，又要考慮智慧管廊信息管理系統的特色。

隨著人工智能與物聯網技術的發展，越來越多的管理操作可以不用人工完成, 只需要在特定的時間點或者地點使用人工智能技術即可完成自動的管理操作，避免了多余的人力的投入。已有的智慧管廊信息管理系統研究較少，也欠完善，本文針對物聯網云平臺智慧管廊系統業務模塊的功能支撐進行研究，提出了基于 RBAC (基于角色的權限控制)模型的智慧管廊信息管理系統的設計與實現方案，該方案基于RBAC模型將用戶-角色-權限分離來滿足智慧管廊系統不同職位的用戶協同工作的業務需求，為系統業務模塊提供功能支撐，實現智慧管廊信息管理的高效性。

1.3論文研究內容

本文給出了基于RBAC的智慧管廊信息管理系統設計與實現方案。本文的主要工作如下：

(1)基于RBAC模型設計用戶-角色-權限分離的角色樹，并給出了智慧管廊信息管理系統用戶與權限的分離實現方案。用戶通過成為某種角色來獲得相應的權限，實現了系統設計的高效性與低耦合性。

(2)設計實現了智慧管廊信息管理鑒權功能，為智慧管廊系統業務模塊提供鑒權功能支撐。用戶登錄系統時首先要進行登錄鑒權，如果用戶名密碼正確則可以登錄系統進行對應的操作；接著要進行操作鑒權，即判斷登錄的用戶是否有權限進行某些操作；最后要進行數據鑒權，即判斷登錄之后的用戶是否有權限對某些數據進行相應的操作。

(3)設計實現了智慧管廊信息管理審批功能，為巡檢維護模塊提供審批功能支撐。由于智慧管廊系統的巡檢業務需求，擁有不同權限的用戶需要合作完成審批工作，本文將不同權限的用戶對應于審批功能的不同流程來實現審批功能。

(4)設計實現了智慧管廊用戶信息與群組信息管理功能，為智慧管廊業務模塊提供用戶信息與群組信息管理功能支撐。智慧管廊系統包含多個用戶，因此需要對用戶信息進行管理。根據業務需求用戶需要通過加入群組來完成相應的工作，因此也需要對群組信息進行管理。同時用戶與群組之間也有功能聯系，例如用戶加入群組和群組中移除用戶等。

1.4論文組織結構

論文一共分為六個章節，每個章節的具體內容如下：

第一章：緒論。主要闡述論文的研究背景及意義、信息管理系統的國內外發展情況、論文的主要研究內容和整個論文的章節結構。

第二章：智慧管廊信息管理相關技術闡述。歸納總結了在本文中使用到的相關技術，包括使用的RBAC模型，MySQL數據庫，攔截器以及使用到的開發工具和項目管理工具等。此外，還闡述了本文所依托的智慧管廊系統。

第三章：智慧管廊信息管理支撐系統需求分析和架構設計。這一章主要分析了系統的需求，并且根據需求分析和技術選型，進行總體的架構設計。系統層次主要分為四層：（1）數據存儲層，負責存儲數據。（2）數據訪問層（dao層），負責與數據庫進行連接從而獲取和操作數據。（3）業務邏輯層（service層），主要工作是實現dao層的具體功能以及調用一些己有功能模塊的功能。（4）控制層（controller層），主要是通過接口的方式將具體實現的功能暴露給前端調用。

第四章：智慧管廊信息管理支撐系統子模塊的設計與實現。詳細分析了系統各個模塊的設計與實現。針對不同的功能，給出相應的流程設計和具體實現。本文主要包括以下幾個功能：（1）通過角色樹實現用戶-角色-權限分離。（2）登錄功能。主要是對登錄進行鑒權。（3）鑒權功能。對用戶的操作權限與數據權限進行鑒權。（4）審批功能。主要是實現業務模塊的審批功能支撐。（5）用戶信息管理功能。主要是用戶信息與群組信息的管理。

第五章：智慧管廊信息管理支撐系統子模塊功能測試及性能分析。對智慧管廊信息管理支撐系統子模塊的功能進行測試，以及分析系統的性能。

第六章：總結和展望。對課題完成的工作進行總結，并且提出當前智慧管廊信息管理系統的不足之處以及未來可以進一步深入的方向。

第二章智慧管廊借息管理相關知識

2.1智憊管廊系統

智慧管廊系統通過物聯網技術將管廊設備信息采集并存儲在云端數據庫中，以便于對設備采集數據進行展示和分析。智慧管廊系統主要包括以下幾個模塊：地圖模塊、視頻模塊、應急指揮模塊、巡檢維護模塊和信息管理模塊。地圖模塊的作用是直觀地展示智慧管廊設備的分布情況，和設備采集的信息，以便繪制巡檢路線方便巡檢人員進行作業；視頻模塊的作用是實時監控智慧管廊設備的運行情況以及對異常事件進行智能預警;應急指揮模塊的作用是應對突發事件進行實時音視頻交流;巡檢維護模塊的作用是完成巡檢維護、入廊作業等系統日常工作；信息管理模塊的作用是管理用戶信息以及為其余業務模塊提供功能支撐。同時在智慧管廊系統的前端會實時展示設備信息，和報警信息以及日常值守等工作內容, 實現智慧管廊系統的高效率運行。智慧管廊系統架構示意圖如圖2-1所示。

展示層設備信息報警信息日常值守大屏展示

信息管理介地圖模塊日志管理仆

數據存儲層用戶數據日志數據管廊嚴數據

MQTT 協議

傳輸層網關

@方g尿協議? Q

圖2-1智慧管廊系統架構示意圖

2.2RBAC 模型

RBAC是當前實現權限管理的常用技術。在RBAC模型中，權限問題能夠理解為是Who、What、How三者的問題，也就是"Who對What進行How的操作"。其中，Who是指權限的擁用者或主體(如User等)；What是指權限針對的對象或資源 (Resource> Class) ； How指的是具體的權限回。

目前常用的模型族是RBAC96模型族，其中包括RBACO-RBAC3四種模型：仃).RBAC0

RBAC0是基本模型，在此模型中，用戶與角色的對應關系是多對多，即在實際項目中一個用戶可以成為不同角色而不同用戶也可以成為同一個角色；角色和權限的對應關系也是多對多，即在實際項目中一種角色可以擁有多個不同的操作權限，而不同角色也可以執行某個相同的操作。

(2). RBAC1

RBAC1是在RBAC0的基礎上增加了角色的上下級關系，補充了角色的繼承，主要分為一般繼承和受限繼承。一般繼承屬于絕對偏序，支持多繼承；受限繼承屬于樹型結構，只支持單繼承。

(3). RBAC2

RBAC2是基于RBAC0的基礎上增加了責任分離關系，它規定了權限和角色分配的時候需要遵守的一種強制性規則。

(4). RBAC3

RBAC3是結合了 RBAC1和RBAC2的特性，同時支持角色的繼承和責任分離規則。因此在實際的開發過程中，RBAC3是使用最為廣泛的，由于其出色的角色分級和繼承，本項目也是基于RBAC3進行開發。RBAC3模型示意圖如圖 2-2所示。

角色上下級關系

用戶《—用戶分配 ? 角色 4~權限分髭一＞權限

責任分離原則

圖2-2 RBAC3模型示意圖【7】

2.3Spring Boot

Spring Boot是由Pivotal團隊提供的新一代開發框架，相比于之前的Spring 和Spring MVC （模型、視圖、控制器），Spring Boot框架提供了自動配置以及自動化部署。自動配置通過注解@SpringBootApplication來完成，不再需要繁瑣的 XML （可擴展標記語言）配置；自動化部署使得應用不需要再打包成war包部署在tomcat容器運行，方便應用管理，從而減輕了開發人員的重復工作，使得 Spring Boot廣泛應用于快速應用開發領域。同時Spring Boot還可以方便的與其他工具鏈整合（比如redis和elasticsearch）,再加上nginx負載均衡，可以輕松實現橫向擴展【％

2.4MyBatis 與 MySQL

MyBatis是一種數據持久層框架，支持高級映射，通過使用注解@Mapper 可以直接在數據存儲層編寫SQL （結構化查詢語言）語句，其自帶的攔截器功能支持定制化動態SQL的編寫［刃，在本項目中將作為主要技術使用。

在使用MyBatis時，首先通過SqlSessionFactoryBuilder方法從XML配置文件或者Java配置類的實例中獲取SqlSessionFactory；接著將SqlSessionFactory進行實例化，創建一個實體對象；之后會產生一個會話實例SqlSessionTemplate, 用來與數據庫進行交互，根據在數據存儲層定義好的Mapper文件中的SQL語句來進行數據庫操作［⑼。

MySQL作為主流的關系型數據庫支持使用SQL語句操作數據庫；支持多用戶和多線程；支持多種連接方式，在本項目中主要是基于JDBC （Java數據庫連接）實現數據庫連接；支持多種存儲引擎，在本文中選擇的是InnoDB引擎山］。

MySQL主要有以下幾個特性：1 .MySQL支持事務且滿足ACID （原子性、一致性、隔離性與持久性）特性，保證數據庫在操作過程中保持事務執行的準確性；2. MySQL支持通過加鎖操作來保證并發情況下事務仍能夠正確執行且互不影響；3.MySQL支持三種范式的規定，保證數據庫表設計的合理性，避免出現字段冗余，提升査詢效率等。

2.5攔截器與過濾器

Java語言支持面向對象編程（OOP）,而在Spring Boot中還支持面向切面編程（AOP）。AOP基于動態代理模式，主要用于解決框架的一些問題，可以在運行時將代碼動態的加入到指定的方法或者指定的位置上，從而可以降低代碼的復用率，減少代碼耦合度。

攔截器（Interceptor）是AOP的典型應用，通過Java的反射機制來實現功能，在Spring Boot框架中通過依賴注入（DI）來實現功能問。攔截器主要作用于控制層（controller）之前服務端（Servlet）之后，通過攔截控制層的請求來實現功能，但是對于其他層次的請求比如數據訪問層（dao）的請求則無法進行攔截。

過濾器（Filter）是指在web開發中，將前端傳入的請求（request）和響應（response ）等信息根據需求提前過濾掉一些冗余參數,或者提前提取一些參=數，比如過濾掉一些token （令牌）攜帶的冗余參數或者一些可能包含SQL注入的非法URL （統一資源定位符）或者非法字符，然后再傳入Servlet實現功能需求。

過濾器主要作用于Servlet之前，可以對HttpServletRequest （客戶端請求）進行預處理，也可以對HttpServletResponse （服務端響應）進行后處理。過濾器的工作流程分為三步：首先對進入Servlet的請求HttpServletRequest進行過濾，接著將過濾之后的請求傳到Servlet執行并生成響應HttpServletResponse,最后過濾器再對Servlet執彳亍之后生成的響應HttpServletResponse進行后處理〔⑼。過濾器與攔截器作用位置對比如圖2-3所示。

容器

過濾器

服務端

扌二截器

控制器

圖2-3攔截器與過濾器作用位置對比

2.6 IDEA 與 Maven

IDEA全稱是IntelliJ IDEA,是基于Java開發的集成環境。相比于之前的 Java開發工具，IDEA集成了代碼重構和代碼導航功能，同時智能代碼助手、代碼自動提示、重構、各類版本工具（git、svn等）、代碼分析、創新的GUI （圖形用戶界面）設計等方面的功能得到了業內好評，使得開發人員有了更好的開發體驗。：（DEA是JetBrains公司的產品，該公司旗下還包括很多其他的產品，例如 WebStorm和PyCharm,他們共同構成了 JetBrains全家桶。

Maven是一個主要用于Java項目自動化構建的工具，它主要由項目對象模型（POM）、項目生命周期、依賴管理系統和一套運行目標插件的邏輯組成，其中目標插件是定義在生命周期中的-Maven的主要目標是通過提供統一的構建系統使構建過程簡單，而統一的構建系統主要是由POM文件和其他的Maven插件組成。Maven主要解決了項目構建過程中的兩個問題：1 .Maven描述了如何構建項目；2.Maven描述了項目之間的依賴性。Maven通過XML文件來描述項目的構建過程，還包括項目需要的組件和相關插件。

2.7本章小結

本章主要對智慧管廊信息管理用到的相關知識和工具進行歸納總結。

首先闡述了智慧管廊系統的系統架構和功能模塊與本文研究內容之間的關系。分析了 RBAC模型與本文研究的信息管理系統之間的關系，通過RBAC模型來實現信息管理系統用戶-角色-權限的分離，是整個系統實現的前提。闡述了 Spring Boot在本文研究的信息管理系統中的作用，作為整個系統后臺的框架，是系統實現的基礎。介紹了 MyBatis與MySQL,指出了 MyBatis是連接數據庫的工具，同時提供了自定義攔截器的功能，可以實現數據鑒權功能；MySQL作為最主流的關系型數據庫支持并發情況下事務的處理，規定了數據庫表設計時需要遵守的三范式原則，為整個系統提供了優秀的數據支撐。指出了攔截器與過濾器的不同作用，攔截器與過濾器都可以實現鑒權功能，只是實現方式與實現原理不同，通過介紹攔截器與過濾器的工作原理，選擇最優的實現方案，提升系統的性能。簡要的介紹了系統開發所需要的開發工具Intellij IDEA和項目管理工具 Maven o

第三章智慧管廊信息管理支撐系統需求分析與架構設計

3.1智慧管廊信息管理支撐系統

一般信息管理系統的支撐系統主要是為系統提供通用功能的支撐，根據智慧管廊信息管理系統多用戶分工合作的特點，智慧管廊信息管理支撐系統主要是對智慧管廊的用戶進行統一的管理，給用戶分配權限去完成視頻監控、入廊作業、巡檢維護、應急指揮和管理考核等智慧管廊的日常工作，為智慧管廊系統的業務模塊提供功能支撐，實現智慧管廊高效的運維與管理。

在智慧管廊信息管理支撐系統中包含多種角色，每種角色分別承擔不同的工作，對應著不同的權限，角色之間存在上下級關系，他們通過協同工作來實現智慧管廊的業務功能。同時根據智慧管廊的業務需求一個用戶可以成為多種角色，也可以從一種角色變為其他角色；角色也可以根據實際的工作變動擁有新的權限, 而權限也可以從對應的角色去除。

智慧管廊信息管理支撐系統基于RBAC3模型設計了角色樹，通過角色樹將用戶-角色-權限分離，首先讓角色擁有對應的操作權限將角色和權限綁定，然后再根據業務需求讓用戶成為對應的角色來獲取該角色擁有的權限［⑷。這樣的設計方案不但可以為智慧管廊的業務模塊提供功能支撐，還能降低系統的耦合性，使智慧管廊系統各個模塊高效協同運作。

3.2智慧管廊信息管理支撐系統需求分析

3.2.1系統用例分析

系統用例分析主要是將系統用例和系統功能相對應，直觀地展示系統的功能。智慧管廊信息管理支撐系統的主要系統用例就是各種不同角色的用戶，而這些用戶對應的角色都是根據智慧管廊監控中心的工作任務而設定的。

與一般的信息管理系統的核心為人事部門不同，在智慧管廊的日常工作中，監控中心的任務最為重要。首先監控中心需要實時全方位的監控整個智慧管廊系統的運行情況，實時監測設備的運行狀態，對設備故障等問題進行預測并且及時解決；其次還要掌握整個系統的運行流程，將流程對應到個人，如果流程出現問題需要及時的向相關人員反饋；同時還要及時準確的處理突發事件，發揮監控中心的職能，盡量預防發生較大的事故；最后還要負責與其他職能部門保持聯絡以便及時處理發生的報警和事故。

監控中心職能如下：

1）總監控中心職能：承擔公司管理的智慧管廊的監控、宏觀管理、政策設置、指揮、調度、重大事件的處理、重要數據的備份、數據統計、數據分析、行政管理等職能。

2）分監控中心職能：承擔所管轄區域的智慧管廊的監控、管理、預警、聯動、人員調度、數據分析、維修維護、應急指揮等職能。

一般信息管理系統的角色包括四種，即系統管理員、子系統管理員、子系統錄入員和普通用戶［⑴，而智慧管廊信息管理系統根據智慧管廊監控中心的工作任務分配主要包括六種角色，分別是總中心系統管理員，總中心調度員，總中心監控員，分中心調度員，分中心監控員與維修值班員，這六種角色分別擁有不同的權限，用戶通過成為這些角色來獲得對應的權限。其中總中心系統管理員只負責為用戶分配權限而不參與智慧管廊的日常工作，參與日常工作的角色主要是總中心調度員，總中心監控員，分中心調度員，分中心監控員與維修值班員，他們的對應關系圖如圖3-1所示。

圖3-1智慧管廊系統日常工作角色對應關系圖

如圖3-1所示，智慧管廊系統角色的主要工作如下：

總監控中心系統管理員：主要負責智慧管廊系統的如下系統管理事務：管理用戶信息、分配用戶權限；管理統一日志模塊、管理統一配置和統一部署模塊以及系統自身控制等。

總監控中心調度人員：主要負責智慧管廊系統的如下決策管理事務：查看突發事件視頻監控；查看突發事件詳細信息，監督事件快速處置；協調信息發布; 向分監控中心發布調度命令；對總監控中心監控員進行管理。

總監控中心監控員：主要負責智慧管廊系統的如下監控事務：數據傳輸狀態監控；重大事件的處理；通報上級協調控制；統計數據并匯總報表；監控設備數據、設備狀態;協調和管理各分監控中心的工作;查看各分監控中心的巡檢結果；完成系統每日重要數據的備份和重要文檔的存儲；對報警事件進行詳細登記、事件跟蹤；對運維計劃進行登記上報；日常定時巡檢；發生突發事件時與相關部門聯系。

分監控中心調度員：主要負責管理所轄區域智慧管廊系統的如下監控管理事務：定期進行巡查，制定突發事件處置方案；查看突發事件視頻監控；查看突發事件詳細信息，監督事件快速處置；向總監控中心報告處理突發事件的過程；接受總監控中心的控制指令；對分監控中心監控員進行管理。

分監控中心監控員：主要負責管理所轄區域智慧管廊系統的如下監控事務：監控數據傳輸狀態；監控設備數據、設備狀態；對報警事件進行詳細登記并持續跟蹤事件進展；查詢視頻監控；對運維計劃登記上報；日常定時巡檢；統計數據并匯總報表；發生突發事件時與相關部門聯系。

維修值班員：主要負責所在區域智慧管廊系統的如下維修事務：維修智慧管廊的故障設備；完成入廊作業并提交；完成預案設計并提交；完成巡檢任務并提交。

3.2.2功能需求分析

功能需求分析主要是列出智慧管廊信息管理支撐系統需要完成的功能，這些功能為智慧管廊系統的業務模塊提供支撐。智慧管廊信息管理支撐系統主要有以下功能：

（1） •登錄鑒權功能

用戶在操作智慧管廊系統時首先需要輸入用戶名和密碼來進行登錄鑒權。如果輸入的用戶名和密碼是正確的，則表示該用戶登錄成功，可以完成相應的功能。

（2） .操作鑒權功能

用戶登錄成功之后會返回該用戶ID （身份證標識號），會通過角色樹査詢該用戶對應的角色信息，然后在攔截器中對角色信息進行攔截，如果某些操作沒有被攔截則表明該用戶有執行該操作的權限，進而完成操作鑒權功能。

（3） .數據鑒權功能

數據權限主要分為數據庫表權限和字段權限。對于一張數據庫表，其子表也有權限，和數據庫表權限相同，子表中的字段權限與數據庫表字段權限相同；權限分等級，擁有高等級的權限必定擁有低等級的權限。

對于庫表權限主要分為不可見（用戶無法操作該數據庫表）、只讀（用戶能查看數據表下的數據）、增加（用戶能新增這個數據表的數據）、修改（用戶能夠修改這個數據表下的數據）和刪除（用戶能夠刪除這個數據表下的數據），本文中體現為用戶數據庫表操作的鑒權。

對于字段權限主要分為不可見（用戶無法讀取這個字段）、只讀（用戶能查看該字段，但是無法修改，且無法在新建頁面看到）、可新建（相對只讀而言，用戶可以在新建頁面填入字段內容）和可編輯（相對可新建而言，用戶可以在修改頁面修改該字段內容），本文中體現為動態字段的鑒權。

（4）.用戶信息管理功能

一般信息管理系統只有系統管理員才具有用戶信息管理功能，而在智慧管廊信息管理系統中調度員、監控員與系統管理員都具有用戶信息管理功能，其中系統管理員擁有的操作權限最高，可以實現用戶信息、角色信息和權限信息的查看、修改、增加和刪除，為用戶分配和刪除角色，為角色分配和刪除權限等功能；而調度員與監控員只能實現查看用戶信息、角色信息和權限信息，以及為用戶分配和刪除群組的功能。用戶信息管理用例圖如圖3-2所示。

圖3-2用戶信息管理用例圖

(5).群組信息管理功能

一般信息管理系統只有系統管理員才具有群組信息管理功能，而在智慧管廊信息管理系統中調度員、監控員與系統管理員都具有群組信息管理功能，其中系統管理員擁有的操作權限最高，可以實現查看群組信息、修改群組信息、增加群組信息與刪除群組信息等功能，而調度員與監控員只能實現查看群組信息，以及在群組中增加與刪除用戶的功能，其中刪除用戶是指將某個用戶移除群組，而不是在系統中刪除用戶的信息。群組信息管理用例圖如圖3-3所示。

(6).審批功能

一般信息管理系統只有子系統管理員和普通用戶來實現審批功能，而在智慧管廊信息管理系統中調度員、監控員與維修值班員都需要實現審批功能，其中維修值班員可以實現審批信息的新建、刪除、修改與查看，和查看審批結果；監控員可以實現審批信息的新建、刪除、修改與查看，完成審批功能，權限不夠傳給上級審批，和查看、修改審批結果；調度員可以完成審批功能，和查看、修改審批結果。審批功能用例圖如圖3-4所示。

圖3-4審批功能用例圖

3.2.3性能需求分析

性能需求分析主要是指智慧管廊信息管理支撐系統需要達到的性能要求，主要包括穩定性需求、安全性需求、復用性需求和可擴展性需求。

(1).穩定性需求

穩定性需求主要是指系統在訪問時需要保持穩定運行，在并發情況下能夠保證系統的時延較短，主要包括平均響應時間、吞吐量和錯誤率這三個指標。

智慧管廊信息管理支撐系統通過后臺提供接口的方式來實現功能，因此穩定性主要體現在接口的響應速度。當接口訪問次數變多時，數據庫的讀寫壓力也會隨著增大，為了維持系統的穩定性，需要合理設計接口的功能，即每個接口只完成特定的某項功能。同時需要合理設計業務邏輯，避免將業務邏輯處理的壓力集中在數據庫，進而提高系統的穩定性。

(2)•安全性需求

安全性需求主要是指系統在訪問時需要保持系統安全，禁止非法用戶操作系統功能，避免系統數據泄露。

智慧管廊信息管理支撐系統主要通過鑒權模塊來保證系統的安全性。登錄鑒權能夠保證系統用戶的合法性，操作鑒權能夠保證系統操作的安全性，數據鑒權能夠保證數據操作的安全性，避免系統數據泄露。

(3)•復用性需求

復用性需求主要是指系統的某項功能能夠在不同的業務場景下重復使用，避免相同功能的重復開發。

智慧管廊信息管理支撐系統的復用性需求主要包括權限的復用和用戶信息管理功能的復用。權限的復用是指智慧管廊信息管理支撐系統的鑒權模塊能夠為智慧管廊系統的所有業務模塊提供鑒權功能支撐，而無需各個業務模塊單獨實現鑒權功能；用戶信息管理功能的復用是指智慧管廊信息管理支撐系統的用戶信息管理模塊能夠同時給PC端和移動端提供用戶信息管理功能支撐，從而實現用戶信息管理功能的復用。

(4)可擴展性需求

可擴展性需求主要指系統通過良好的架構設計能夠實現新功能的插入，同時避免功能修改導致的代碼重新開發，降低模塊之間的耦合。

智慧管廊信息管理支撐系統的可擴展性需求包括兩方面：一是規范接口的設計標準，在接口調用時能夠體現出良好的適配性；二是系統架構分層設計，通過分層設計可以將功能模塊劃分為不同層次，增加新功能時也不會影響系統的整體架構。

3.3智憊管廊侑息管理支撐系統架構設計

與一般信息管理支撐系統單向架構設計不同，智慧管廊信息管理支撐系統架構設計分為橫向架構設計和縱向架構設計。橫向架構設計主要是將整個系統按照功能分為不同的模塊進行獨立設計與開發，主要分為用戶模塊、鑒權模塊和審批模塊；縱向架構設計主要是按照前端發出的請求在后端的執行順序來劃分，按照前端請求進入后端系統的層次順序在縱向將系統分為控制層、業務邏輯層、數據訪問層和數據存儲層"I。

3.3.1系統功能瞅

智慧管廊信息管理支掉系統包含多個用戶，這些用戶擁有的權限各不相同，因此每個用戶能夠操作的系統功能也是不一樣的，但是這些功能既有重復的也有獨立的［17】，例如查看群組包含的用戶，所有人都可以看到自己所在群組的所有用戶，但是只有群主或者是權限較高的用戶才可以刪除群組用戶或者添加群組用戶=同時智慧管廊信息管理支撐系統是基于項目組已有的通用物聯網云平臺進行開發，需要用到其中的一些PaaS (平臺即服務)層的通用模塊，例如日志模塊，為了符合通用物聯網云平臺整體設計的微服務思想［⑻，降低各個功能的耦合性, 智慧管廊信息管理支撐系統也需要根據功能將系統進行模塊化設計。

智慧管廊信息管理支撐系統根據功能將系統進行模塊化劃分,這樣不僅可以體現微服務的思想，降低系統的耦合性，也可以使得相同功能得以復用，為智慧

管廊系統的業務模塊提供良好的功能支撐。智慧管廊信息管理支撐系統的子模塊劃分圖如圖3-5所示，主要包括三個模塊：用戶模塊、鑒權模塊和審批模塊。

信息管理支撐系統

圖3-5智慧管廊信息管理支撐系統子模塊劃分

如圖3-5所示的智慧管廊信息管理支撐系統的子模塊之間關系如下：

(1)•用戶模塊

用戶模塊主要是完成用戶信息的管理，為智慧管廊業務模塊提供用戶信息管理功能支撐，包含三個功能：角色樹設計、用戶信息管理和群組信息管理。角色樹設計主要是基于RBAC3模型設計用戶-角色-權限相關聯的角色樹，通過先將權限分配給角色，讓角色都擁有對應的權限，然后再為用戶分配角色，使用戶通過成為相應的角色來獲取對應的權限，從而將用戶-角色-權限分離，降低了系統的耦合性；用戶信息管理是指對用戶信息進行管理，包括用戶信息、角色信息和權限信息的查看、修改、增加和刪除，為用戶分配和刪除角色，為角色分配和刪除權限，為用戶分配和刪除群組等功能；群組信息管理是指對群組信息進行管理，包括群組信息的查看、修改、增加和刪除，為群組添加新用戶，刪除群組中的用戶等功能。

(2)•鑒權模塊

鑒權模塊主要是完成用戶鑒權功能，為智慧管廊業務模塊提供鑒權功能支撐，包含三個子模塊：登錄鑒權模塊、操作鑒權模塊與數據鑒權模塊。

(a)•登錄鑒權模塊

登錄鑒權模塊主要實現用戶登錄鑒權、用戶修改登錄密碼和用戶退出登錄功能。用戶登錄鑒權是指當用戶輸入用戶名和密碼之后，登錄鑒權模塊會將輸入的密碼采用和數據庫密碼相同的加密算法進行加密，然后再將輸入的用戶名和加密后的密碼與數據庫中的用戶名和加密后的密碼進行比對，如果符合，則證明該用戶是合法用戶，可以登錄且獲取Token信息，否則提示用戶名或者密碼錯誤，無法登錄系統；用戶修改密碼功能需要用戶首先輸入舊密碼，如果舊密碼是正確的才可以修改新的密碼，否則不能進行密碼修改；用戶退出功能是指用戶已經登錄智慧管廊系統，在執行完相應的操作后退出系統，避免權限不同的人使用自己的權限執行操作，確保系統的安全性。

(b).操作鑒權模塊

操作鑒權模塊主要實現操作的鑒權與操作權限的管理。操作的鑒權是指當前用戶登錄之后進行某些操作，此時鑒權模塊需要對用戶的身份進行鑒權來判斷當前用戶是否有權限來進行該項操作，如果權限匹配則放行，讓其進行操作，如果權限不匹配則進行攔截，阻止其進行操作，確保系統的安全性；操作權限的管理是指對某個操作進行權限的添加、修改與刪除，根據不同的業務需求進行變動，實現權限的復用，保證系統的復用性。

(c).數據鑒權模塊

數據鑒權模塊主要實現動態字段的鑒權與字段權限的管理。動態字段的鑒權是指根據不同用戶的權限需要對數據庫表字段操作進行鑒權，即某些字段對于某些用戶是可見的，而對另一些用戶則是不可見的，體現為字段級的權限，需要根據當前用戶的權限來實現具體字段的權限；同時具有相同權限的用戶在執行同一操作時是對同一張數據庫表進行操作，會存在用戶數據共享問題，此時也需要通過動態字段鑒權來實現，根據當前用戶操作的字段來判斷該用戶在數據庫表中對應的數據；字段權限的管理是指對動態字段權限的增加和刪除，即一個字段要么是動態字段要么是普通字段，如果該字段為動態字段則需要將其加入動態字段統一管理，否則只需按普通字段進行操作即可。

(3)•審批模塊

審批模塊主要實現審批功能，為巡檢維護模塊提供審批功能支撐。用戶在執行審批操作時首先要獲取未審批的信息，在執行審批操作時需要填寫審批人信息與審批意見，審批結果分為通過，不通過與交給上級處理三種，根據不同用戶的權限實現的結果不同，例如最低權限的只能提交審批信息，中級權限的可以審批或者覺得自己無法決定則交給高級權限的人員進行最終審批，高級權限的人員只需審批通過與否即可；用戶也可以査看己經審批過的信息來獲取審批結果；同時

也可以查看審批信息，包括審批人的名稱與審批意見。

3.3.2系統分層架構

與一般信息管理支撐系統根據應用結構進行層次劃分不同，智慧管廊信息管理支撐系統根據前端請求在后端的執行順序在縱向將系統層次分為控制層、業務邏輯層、數據訪問層和數據存儲層。位于上層的功能模塊通過調用下層功能模塊提供的類和方法來實現功能，保證系統功能的實現具有方向性。同時各個層次獨立開發，不但方便問題的排査還降低了整個系統的耦合性。智慧管廊信息管理支撐系統分層結構如圖3-6所示：

控制層

業務邏輯層

MySQL

數據訪問對象

數據持久化類

圖3-6智慧管廊信息管理支撐系統縱向層次劃分

智慧管廊信息管理支撐系統的開發工作主要層次如上圖3-6所示，四個層次之間的關系如下：

(1)•數據存儲層

數據存儲層主要負責存儲數據，在系統中的體現就是在數據庫層面，包括關系型數據庫(MySQL)和非關系型數據庫(NoSQL)。智慧管廊信息管理支撐系統采用MySQL關系型數據庫存儲全部數據，包括用戶的數據、群組數據、角色樹模型與審批信息。在數據庫的設計中按照需求進行建表，有依托關系的表使用外鍵和關聯表來實現。

MySQL主要包含以下幾張表的設計：

user表：用于存放用戶基本信息，包括用戶ID,用戶名，用戶郵箱等基本信息。

user_credentials表：用于存放用戶的加密后的密碼，通過外鍵將字段user_id 與user表主鍵ID綁定。

role表：用于存放角色基本信息，包括角色名和角色描述。

permission表：用于存放權限基本信息，包括權限名和權限描述。

role_user_relation表：用戶角色關聯表，通過外鍵將字段role_id與role表中主鍵ID綁定，將字段user_id與user表中主鍵ID綁定，從而將用戶表與角色表相綁定。

role_permission_relation表：角色權限關聯表，通過外鍵將字段role id與role 表中主鍵ID綁定，將字段permission id與permission表中主鍵ID綁定，從而將角色表與權限表相綁定。

通過以上6張表可以實現用戶-角色-權限角色樹的數據庫表設計。 reservePlan表：審批信息表，包括計劃名、提交計劃的用戶的ID與名稱、添加日期與狀態。

planAduit表：審批結果表，包含審批ID、審批人ID、審批人名稱與審批意見。

plan user表：審批結果與user關聯表，通過外鍵將字段user_id與user表中主鍵ID綁定，可以通過審批結果查詢審批人的信息。

chatGroup表：包括群組ID、群組名稱與群組信息。

group user表：群組與用戶關聯表，通過外鍵將字段group id與chatGroup 表中主鍵chatGroupId綁定，將字段user_id與user表中主鍵ID綁定，可以實現在群組中增加和刪除用戶的操作。

通過以上5張表可以實現審批-群組-用戶的數據庫表設計。

（2） •數據訪問層

數據訪問層主要實現系統連接數據庫并對數據庫進行操作。操作數據庫的 SQL語句在該層進行封裝，通過訪問數據存儲層來實現對數據庫表的CRUD （增刪改查）等操作；并且通過類的方式讓業務邏輯層進行調用。同時該層還完成系統數據的持久化工作，方便前端的展示。

智慧管廊信息管理支撐系統的數據訪問層通過MyBatis來訪問數據存儲層。通過@1^伍戸戸6「注解將SQL語句與Java語言結合，實現傳統的面向對象開發。 MyBatis是一種ORM （對象關系映射）方式的技術，由兩個部分組成，數據訪問對象（DAO）和數據持久化類。

數據訪問對象：該對象可以進行數據庫的基本操作，包括CRUD等基本方法。

DAO的主要作用是將Mapper中實現功能的SQL語句進行封裝，然后通過類的方式讓業務邏輯層進行調用來實現操作數據庫的功能。

數據持久化類：該類為DAO提供數據載體，將數據庫表中的數據以類的方式在Java中展示。數據庫表是一張二維表格，每條數據就是這張二維表格中的一行，但是在Java中，數據是以類的實例存在的，因此數據庫表中的數據想要在系統中展示就必須轉化為實體類才行，而數據持久化類的作用就是將數據庫表中的數據轉化為Java中的實體類。

數據訪問層的實現類也是按照數據訪問對象和數據持久化類分為兩部分放在系統的代碼分層包中：數據訪問對象的接口放在com.buptiot.dao包中，包括 UserRepository,RoleRepository,PermissionRepository,ChatGroupRepository,PlanAud itRepository 與 ReservePlanRepository；持久化類放在 com.buptiot.pojo 包中，主要有 user,role,permission,chatGroup,planAudit 與 reservePlan。

(3).業務邏輯層

業務邏輯層是智慧管廊信息管理支撐系統的核心，負責處理整個系統的業務邏輯。在業務邏輯層，實現了完成功能所需要的調用關系、方法和算法，根據需求來調用數據訪問層的相關類來實現功能。同時作為系統縱向開發層次的中間層, 業務邏輯層還需要接收控制層傳送的請求，根據請求的內容來調用數據訪問層的相關類來處理請求中的業務邏輯。

業務邏輯層是完成系統功能需求最主要的一層，上接控制層接收請求，下連數據訪問層調用方法，操作數據，訪問數據庫，起到承上啟下的作用。不同于數據訪問層的每個類對應一張固定數據庫表的開發方式，業務邏輯層的每個功能需求都不相同，有時不只調用單個數據訪問層的方法，可能會同時調用多個數據訪問層的類以及其他的方法來實現功能。

業務邏輯層的類存放在com.buptiot.service包中，主要包括以下幾個接口： UserService,Ro leService,PermissionService,ChatGroupService,PIanAuditService^n ReservePlanService；同時上述接口對應的實現類也放在該包中，包括以下實現類： UserServiceImpl,RoleServiceImpl,PermissionServiceImpl,ChatGroupServiceImpI,Pla nAuditServicel mpl 禾口 ReserveP lanServicel mpl。

UserServicelmpl 類實現 UserService 接口的功能，通過調用 User Repo sitory 接口的方法，操作持久化類user,實現用戶信息的獲取、修改、增加、刪除、通過角色ID獲取用戶信息與通過用戶ID獲取用戶信息等功能。

RoleServicelmpl 類實現 Role Service 接口的功能，通過調用 RoleRepository 接口的方法，操作持久化類role,實現角色信息的獲取、修改、增加、刪除、通過角色ID獲取角色信息與通過用戶ID獲取角色信息等功能。

PermissionServicelmpl 類實現PermissionService接口的功能，通過調用 PermissionRepository接口的方法，操作持久化類permission,實現權限信息的獲取、修改、增加、刪除、通過角色ID獲取權限信息與通過用戶ID獲取權限信息等功能。

ChatGroupServicelmpl 類實現ChatGroupService接口的功能，通過調用 ChatGroupRepository接口的方法,操作持久化類chatGroup,實現群組信息的獲取、修改、增加、刪除、通過用戶ID獲取群組信息與在群組中增加或者刪除用戶信息等功能。

PlanAuditServicelmpl類實現PlanAuditService接口的功能，通過調用 PlanAuditRepository接口的方法，操作持久化類planAudit,實現審批結果信息的獲取、修改、增加、刪除、通過審批結果ID獲取用戶信息與通過審批結果ID獲取審批結果信息等功能。

ReservePlanServicelmpl類實現ReservePlanService接口的功能，通過調用 ReservePlanRepository接口的方法，操作持久化類reservePlan,實現審批信息的獲取、修改、增加、刪除、通過ID獲取審批信息與對未審批的信息進行審批等功能。

（4）.控制層

智慧管廊信息管理支撐系統基于前后端分離開發，后臺采用Spring Boot框架開發，在控制層基于MVC （模型，視圖，控制器）模式，其中視圖（view）是指前端界面，由前端開發人員進行設計與開發；模型（model）是指后臺的業務邏輯層的各個功能模塊；控制器（controller）是在控制層來實現的。

控制層作為系統后臺縱向開發層次的最上層，負責調用業務邏輯層的功能，將具體功能通過API （應用程序接口）接口的方式暴露給前端調用，其本身不處理任何的業務邏輯；同時負責接收前端傳來的請求，將請求傳到業務邏輯層的具體類來處理，然后將請求處理后的結果再通過控制層傳到前端展示在對應的界面。

控制層的實現類存放在com.buptiot.controller包中，主要包括以下幾個類： UserContro Iler,RoleController,Permissioncontroller,ChatGroupContro Iler,HttpContr oller,PlanAduitController,ReservePlanController,LoginController 與 BaseControIler。 3.4本章小結

本章闡述了智慧管廊信息管理支撐系統的功能需求以及系統的架構設計方案。

第一節說明了智慧管廊信息管理支撐系統的基本信息。

第二節分析了智慧管廊信息管理支撐系統的需求。從系統用例和系統功能兩個方面詳細闡述了系統包含的六種角色以及每種角色對應的工作。同時列出系統需要完成的功能，并且與六種角色相對應。最后還分析了系統整體的性能需求，并且與相應的功能對應。

第三節給出了智慧管廊信息管理支撐系統的架構設計方案。按照功能將系統在橫向劃分為三個模塊，用戶模塊、鑒權模塊與審批模塊，各模塊獨立開發，為智慧管廊系統的業務模塊提供功能支撐；基于系統前后端分離的開發模式，按照前端請求在后臺的執行順序將系統在縱向劃分為控制層、業務邏輯層、數據訪問層和數據存儲層，各層獨立開發、相互調用，這種分層開發的方式極大的降低了系統的耦合性。

第四章智慧管廊信息管理支撐系統的設計與實現

4.1智憊管廊信息管理支撐系統功能

與一般信息管理支撐系統提供通用功能支撐不同，智慧管廊信息管理支撐系統通過角色樹實現用戶-角色-權限分離，將角色與權限相關聯，用戶通過成為適當的角色來獲取相應的權限；用戶登錄時首先進行登錄鑒權，如果鑒權通過則該用戶可以執行其對應的角色的相關操作；接著進行操作鑒權來判斷該用戶是否可以執行某些操作；在用戶執行數據操作時要判斷該用戶執行操作的數據庫表是否包含動態字段，若包含動態字段則需要進行數據鑒權；智慧管廊信息管理支撐系統的功能還包括審批功能和管理用戶信息與群組信息功能，這些子模塊相互調用為智慧管廊系統的業務模塊提供功能支撐。

4.2智憊管廊信息警厘角色樹的設計與實現

4.2.1角色樹的設計

智慧管廊信息管理支撐系統通過為用戶分配權限去完成智慧管廊的日常工作，因此需要通過權限訪問控制技術將用戶與權限分離。與一般信息管理支撐系統采用DAC（自主訪問）和MAC （強制訪問）實現權限訪問控制不同，智慧管廊信息管理支撐系統基于RBAC3模型設計了角色樹，通過角色樹將用戶、角色和權限分離，并且引入了角色間的上下級關系a】。同時通過角色樹可以高效的查詢用戶對應的角色和權限信息，為智慧管廊系統的業務模塊提供良好的功能支撐。

智慧管廊信息管理角色樹通過讓角色擁有相應的操作權限，實現角色和權限多對多的對應關系。在設計時需要建立三張數據庫表，一張為角色表，包含整個系統所有角色的信息；一張為權限表，包含整個系統所有的操作權限信息；一張為角色權限對應表，在該表中將不同的角色和其對應的權限進行多對多記錄，即可實現角色與權限綁定。同理，用戶與角色之間也需要一張用戶角色表來記錄用戶與角色的對應關系來實現用戶與角色的綁定。通過五張表就可以使用戶擁有相應的權限，完成角色樹的設計。智慧管廊信息管理角色樹示意圖如圖4-1所示。

圖4-1智慧管廊信息管理角色樹示意圖

4.2.2角色樹的實現

智慧管廊信息管理角色樹的實現包括系統縱向架構層次的數據存儲層、數據訪問層、業務邏輯層和控制層，由于部分功能和用戶信息管理功能重疊，因此本節主要說明數據存儲層的實現方案，其余層級的實現方案將在后文詳細說明。

數據存儲層需要實現五張數據庫表，其中三張為基本信息表，分別是用戶表, 角色表和權限表；兩張為關聯表，分別是用戶-角色關聯表和角色-權限關聯表，具體的實現如表4-1至表4-5所示：

(1)用戶表(user表)

用戶表用來存儲用戶信息，主鍵為ID,也就是用戶ID,其余的字段包括用戶名和用戶郵箱等，其中用戶郵箱是用戶的登錄名。

表4-1用戶表

字段名稱類型長度是否索引是否主鍵字段說明

id INT 11 Y Y 用戶ID

name VARCHAR 255 用戶名稱

email VARCHAR 255 用戶郵箱

wechat VARCHAR 255 用戶微信

phone VARCHAR 255 用戶電話

department VARCHAR 255 用戶部門

(2)角色表(role表)

角色表用來存儲角色信息，主鍵為ID,也就是角色ID,其余的字段包括角色名稱和角色描述。

表4-2角色表

字段名稱類型長度是否索引是否主鍵字段說明

id INT 11 Y Y 角色ID

name VARCHAR 255 角色名稱

description VARCHAR 255 角色描述

(3) 權卩艮表 (permission 表)

權限表用來存儲權限信息，主鍵為ID,也就是權限ID,其余的字段包括權限名稱和權限描述。

表4-3權限表

字段名稱類型長度是否索引是否主鍵字段說明

id INT 11 Y Y 權限ID

name VARCHAR 255 權限名稱

description VARCHAR 255 權限描述

(4)用戶-角色關聯表(role user relation表)

用戶-角色關聯表用來存儲用戶與角色的關聯信息，主鍵為ID,無具體意義，主要字段為user id與role id,其中user_id通過外鍵與user表中的主鍵ID 關聯,role_id通過主鍵與role表中的主鍵ID關聯，進而實現用戶與角色的關聯。

表4-4用戶-角色關聯表

字段名稱類型長度是否外鍵是否主鍵字段說明

id INT 11 Y ID

userid INT 11 Y 用戶ID

role id INT 11 Y 角色ID

(5) 權限-角色關聯表(role_permission_relation表)

權限-角色關聯表用來存儲權限與角色的關聯信息，主鍵為ID,無具體意義，主要字段為permissionid與roleid,其中permissionid通過外鍵與permission 表中的主鍵ID關聯，rolejd通過主鍵與role表中的主鍵ID關聯，進而實現權限與角色的關聯。

表4-5權F 艮-角色關聯表

字段名稱類型長度是否外鍵是否主鍵字段說明

id INT 11 Y ID

role id INT 11 Y 角色ID

permission id INT 11 Y 權限ID

MySQL數據庫可以直觀地展示角色樹數據庫表對應關系ER （實體聯系）

圖，如圖4-2所示。

Zj role_

id F>JT{11) userjd R4T(11) rt^J d INT(ll)

圖4-2角色樹ER圖

4.3智憊管廊信息管理登錄模塊的設計與實現

4.3.1登錄臧的設計

登錄模塊的作用是驗證用戶身份，為智慧管廊系統做登錄功能支撐。用戶在使用智慧管廊系統的功能之前，需要使用賬戶（此處為郵箱）與密碼進行登錄。登錄成功后，可以執行自己權限范圍內的操作。登錄過程示意圖如圖4-3所示。

圖4-3登錄過程示意圖

與一般信息管理支撐系統前后端聯合開發不同，智慧管廊信息管理支撐系統基于前后端分離進行開發，在前端輸入用戶名和密碼之后需要通過和后臺建立 session （會話控制）連接才能將用戶名和密碼傳到后臺進行認證冋。當后臺獲取到前端傳送的賬戶信息后，登錄模塊會通過用戶的賬戶去數據庫獲取用戶的憑證信息，其中包含了用戶經過Bcrypt（跨平臺的文件加密工具）算法加密后的密碼。如果獲取憑證信息失敗，則表明用戶輸入的賬號不存在。在成功獲取憑證信息后，用戶輸入的密碼同樣會經過Bcrypt算法進行加密，然后與獲取到的數據庫中的憑證信息中的密碼進行比對。如果比對結果相同則表示驗證通過，接著開始創建 Token,執行登錄操作；否則表示驗證失敗。登錄流程圖如圖4-4所示。

圖4-4登錄流程圖

同時登錄模塊還包括修改用戶密碼和退出登錄的功能。用戶修改密碼時首先輸入舊密碼，接著將舊密碼與數據庫中的用戶密碼進行比對，如果相同則輸入新密碼，將新密碼存入數據庫，完成修改密碼功能；退出登錄時首先獲取當前用戶的Token,接著將其中的access_token去除，最后執行退出登錄操作。

4.3.2登錄模塊的實現

由于智慧管廊系統基于前后端分離進行開發，用戶執行登錄操作時需要前后端建立連接且認證之后才能進行登錄鑒權，因此登錄模塊主要基于shiro框架和 OAuth2 Token認證技術來實現，其中shiro框架用于建立前后端seesion會話并完成登錄和退出登錄操作，0Auth2 Token用于登錄鑒權并生成Token。

用戶進行登錄操作時，shiro框架會創建一個session并儲存在智慧管廊信息管理支撐系統后臺，該session會包含Subject (安全視圖)的基本信息,并會在請求結束后返回session的sessionld給智慧管廊系統客戶端。客戶端在瀏覽器沒有關閉的情況下可以使用sessionld進行身份驗證，帶上sessionld來檢索智慧管廊信息管理支撐系統后臺的session,如果session存在則驗證通過,并獲取session 的信息。

登錄模塊通過SessionListener類來實現session會話的管理，包括session的創建與銷毀，以及生成sessionldo當智慧管廊系統客戶端和智慧管廊信息管理支撐系統后臺建立session會話且獲取到sessionld后，客戶端就可以攜帶sessionld 在智慧管廊信息管理支撐系統后臺進行session認證。如果認證成功就可以將用戶在智慧管廊系統客戶端輸入的用戶名和密碼傳到智慧管廊信息管理支撐系統后臺，再進行登錄鑒權。

在session認證成功之后，智慧管廊系統客戶端輸入的username和password 會傳入登錄模塊的Authenticationprovider進行處理，驗證用戶身份是否屬實。首先將username傳入UserService的findUserByName()方法獲取登錄用戶的信息，接著將 userid 傳入 UserCredentialsService 的 findUserCredentialsByUserId()方法獲取當前用戶儲存在數據庫用戶密碼表(user_credentials表)的密碼，用戶密碼表的實現如表4-6所示。

表4-6用戶密碼表

字段名稱類型長度是否外鍵是否主鍵字段說明

id INT 11 Y ID

password VARCHAR 255 用戶密碼

user id INT 11 Y 用戶ID

用戶密碼表用來存儲用戶密碼,主鍵為ID,無具體意義，主要字段為password 與user_id,其中password為用戶密碼，user_id通過外鍵與user表中的主鍵ID 關聯，方便用戶查詢密碼。

在獲取用戶密碼后會調用Authenticationprovider的setAuthenticated()方法比對用戶輸入的密碼與數據庫密碼，如果結果為true則表示用戶登錄認證成功，開始創建 Token；通過 AuthenticationTokenService 向 MySQL 進行讀操作,取出 Token 的過期時間等屬性來創建Token的基本信息access_token ；接著會由 TokenEnhancer方法進行Token的進一步處理，添加其余詳細信息，包括username 和user_id等，此時便完成了登錄認證與Token的創建。創建Token的流程圖如圖4-5所示。

圖4-5創建Token流程圖

在完成登錄認證與Token的創建之后，shiro框架的UsernamePasswordToken 方法會將username和password封裝為UsernamePasswordToken對象，接著通過 shiro框架的SecurityUtils類的getSubject。方法獲取當前Subject,執行 subject.login(usernamePasswordToken)方法，完成登錄功能。

用戶修改密碼時，首先輸入當前密碼，同時SecurityUser類的getCurrentUser() 方法會獲取當前登錄用戶的用戶信息，將用戶ID傳入UserCredentialsService的 findUserCredentialsByUserId()來獲取用戶數據庫密碼；如果當前密碼與數據庫密碼相同則輸入新密碼，通過 UserCredentialsService 的 updateUserCredentials()方法將新密碼更新到數據庫，完成修改密碼的功能。

用戶退出登錄時首先獲取當前的Token信息，接著通過TokenStore類的 readAccessToken 方法獲取 Token 信息中的 access token,再通過 TokenStore 類的 removeAccessToken 方法將 access_token 去除，最后通過 shiro 框架的 SecurityUtils 類的getSubject()方法獲取當前Subject,執行subject.logout()方法，完成退出登錄功能，同時給智慧管廊系統客戶端返回信息"success to logout

4.4智憊管廊信息他鑒權模塊的設計與實現

4.4.1鑒權功能的分類

鑒權模塊分為三部分，登錄鑒權、操作鑒權和數據鑒權。登錄鑒權主要是在用戶登錄智慧管廊系統時進行鑒權,具體的設計與實現方案己在4.3節中說明; 操作權限是指用戶登錄智慧管廊系統之后進行相關操作時的鑒權；數據鑒權是指在執行某些數據操作時的鑒權。

4.4.2操作權限的設計

操作權限是在用戶已經登錄智慧管廊系統之后需要實現的鑒權。當用戶登錄鑒權成功之后登錄模塊會給智慧管廊系統客戶端返回Token等認證信息，用戶會攜帶這些認證信息進行操作鑒權。進行操作鑒權時首先通過角色樹獲取當前登錄用戶的角色信息，接著通過判斷該角色是否有執行智慧管廊系統某些操作的權限，如果有則會讓其執行相應的操作，否則就會提示該用戶沒有權限，阻止其執行操作。操作權限設計示意圖如圖4-6所示。

圖4-6操作權限設計示意圖

智慧管廊信息管理支撐系統的功能是在controUer層以接口的形式暴露給智慧管廊系統客戶端調用，因此操作權限的設計主要是在controller層。通過給 controller層各個功能接口添加注解(annotation)將接口功能對應給相應的角色，通過注解可以知道哪些角色可以實現該接口的功能；用戶登錄之后通過角色樹查詢該用戶對應的角色，如果當前用戶對應的角色是可以實現某些功能接口的角色集合的子集則表明該用戶有權限來執行該接口對應的操作；如果當前用戶的角色并未包含在可以實現某種功能接口的角色集合中則表明該用戶沒有權限來執行該接口對應的操作。通過在接口添加注解這樣的設計即可實現操作權限。操作鑒權流程圖如圖4-7所示。

圖4-7操作權限流程圖

4.4.3操作權限的實現

智慧管廊信息管理支撐系統需要管理多種不同角色的用戶的權限，但是權限的數量相對于角色的數量較為繁多，處理起來較為復雜，而角色樹實現了用戶 -角色-權限分離，因此與一般信息管理支撐系統基于Spring Security對權限判定來實現操作權限不同，智慧管廊信息管理支撐系統的操作權限是基于攔截器對角色判定來實現的，通過使用自定義攔截器類來實現權限攔截，在代碼層面則是通過繼承HandlerlnterceptorAdapter類來實現攔截功能。

首先說明 HandlerlnterceptorAdapter 類，它通過實現 AsyncHandlerlnterceptor 接口的方法來實現功能，主要有三個實現方法，包括preHandle、postHandle和 afterCompIetion,其中preHandle是在執行目標方法之前執行，postHandle是在執行目標方法之后執行，afterCompletion在請求已經返回之后執彳亍。本文通過注解 @Override重寫preHandle方法來實現自定義攔截器類Loginlnterceptor的功能, 進而實現操作鑒權。

在實現攔截器功能之前首先需要對攔截器進行配置，通過使用注解 ©Configuration標注一個普通類使得該類成為配置類，可以在該類中定義Bean

（可重用組件）以及注入一些配置參數，接著在Spring Boot的攔截鏈中注入自定義的攔截器來配置攔截路徑，實現請求傳入時去攔截需要攔截的請求的功能。

在配置攔截器時，首先需要新建一個普通類ConfigAdapter,并且讓該類繼承WebMvcConfigurerAdapter類；然后使用@（30迪£1«^；011注解進行標注使其成為配置類；接著通過@86玄11注解將自定義攔截器類Logininterceptor注入；最后通過注解@Override重寫addinterceptors方法來配置需要攔截的接口的URL。

在完成攔截器的配置之后需要自定義權限注解@Auth,通過注解@丁3^筑、 @Retention、©Documented和@11^1"劃ce來實現，其中@Target注解表明被標注的這個類可以進行標注的位置以及添加常用的元素類型（ElementType）； ©Retention注解表示的是被標注這個類的注解保留時期；@Documented注解是是否生成文檔的標注，表示是否生成注解文檔；@inter短ce表示該類為自定義注解類。在自定義權限注解@Auth中包含一個String類型的角色數組roles,表示注解包含的角色集合。

接著需要在controller方法上配置權限，通過自定義注解@人皿11進行標注，該注解通過roles數組表明可以實現標注的接口功能的角色集合。例如標注為 @Auth（roles = {"GeneralDispatcher"," GeneralMonitor" }）表明可以實現該方法的角色只能是GeneralDispatcher （總中心調度員）和GeneralMonitor （總中心監控員）兩種角色，其余角色沒有權限實現該方法。

最后實現攔截器的功能，實現流程圖如圖4-8所示:

圖4-8攔截器流程圖

首先通過繼承Handlerinterceptor Adapter類來定義一個實現攔截方法的 Logininterceptor類，同時需要引入業務邏輯層中的RoleService類來實現角色樹的查詢。在Spring Boot中，控制層的類通過注解@Controller標注，業務邏輯層的類通過注解@Service標注，經過標注后控制層類的每個方法都能調用業務邏輯層的類，通過注解@Autowired對引入的業務邏輯層的類進行標注，讓Spring Boot完成Bean的自動裝配。

本文在實現操作鑒權時也通過注解@Autowired對自定義攔截器類中引入的業務邏輯層的RoleService類進行標注從而調用其相應方法。當調用RoleService 類的 HndRolesNameByUserld()方法時會出現 java.lang.nullpointerexception (空指針錯誤)，原因是自定義攔截器類并非控制層的類，沒有注解©Controller標注，因此無法直接調用業務邏輯層的方法。

解決方案是通過注解©Component將需要調用的業務邏輯層的類標注為組件，然后通過加載組件來調用相應類的方法。首先通過注解©Component對自定義攔截器類Logininterceptor進行標注，使其成為組件；接著通過注解@Autowired 獲取業務邏輯層的Bean對象，將RoleService方法引入并將其聲明為protected 類型，同時將自定義攔截器類Logininterceptor類引入并聲明一個static類型的靜態變量logininterceptor,用來存儲Bean對象；最后通過注解@PostConstruct對初始化方法init()進行標注，在該方法中包括初始化靜態對象logininterceptor和它的靜態成員變量roleService,其作用是在獲取業務邏輯層Bean對象之后將其靜態存儲，防止被釋放。

通過以上方案即可實現在非控制層的類中調用業務邏輯層的類。由于需要調用的類已被標注為組件，因此在調用時需要通過靜態對象和靜態成員變量加載組件來調用，例如調用RoleService的HndRolesNameByUserld。方法，通過加載組件的方式來調用的示例為 loginInterceptor.roleService.findRolesNameByUserId()o 在自定義攔截器類中引入RoleService類之后需要實現preHandle方法。在實現preHandle方法時首先需要獲取注解，即獲取攔截器配置中需要攔截的方法的注解@Auth中定義的角色數組，若角色配置不為空則取出角色名稱并將其放在一個set集合中；接著通過request.getParameter方法獲取用戶登錄之后返回的 user_id參數且將其轉換為int型變量ID,通過loginlnterceptor.roleSer\7ice的 AndRolesNameByUserldO方法來獲取當前用戶對應的角色集合；最后將當前用戶角色集合與set集合中的角色進行比對，如果set集合中的角色包含該角色則證明當前用戶有權限執行該攔截的方法，否則就是沒有權限，拒絕執行。

4.4.4數據權限的設計

與一般信息管理支撐系統只包括操作權限不同，智慧管廊信息管理支撐系統根據智慧管廊業務模塊的業務需求還包括數據權限。智慧管廊信息管理支撐系統的數據權限和操作權限類似，也是在用戶已經完成登錄功能之后攜帶用戶ID 等認證信息通過角色樹獲取當前登錄用戶的角色信息，接著通過判斷該角色是否對某張數據庫表或者是數據庫表中的某些字段有操作權限。數據權限示意圖如圖 4-9所示。

圖4-9數據權限示意圖

數據權限與操作權限的設計不同，操作權限主要是對功能的鑒權，在系統層次中就是在controUer層來實現；而數據權限主要是對數據的鑒權，在系統層次中則是在dao層來實現。dao層主要是通過SQL語句來實現數據的增刪改查，和操作權限類似，只要給dao層的實現方法添加注解就能表明該方法對應的數據權限。根據不同權限的用戶對應的數據權限不同，通過動態字段動態的拆分SQL 來實現數據權限，主要分為兩種場景，一種是行級數據處理，一種是列級數據處理。行級數據處理主要是根據不同的用戶權限來操作不同行的數據，例如可以根據權限對某幾行執行查詢操作，能夠解決智慧管廊系統用戶數據共享的問題；列級數據處理主要是根據權限來操作不同字段的信息，可以根據權限來指定其可以操作的字段，能夠解決智慧管廊系統字段權限的問題；根據具體的業務需求將兩者結合起來使用則可以實現數據鑒權，為智慧管廊系統業務模塊的數據鑒權提供功能支撐。數據鑒權流程圖如圖4-10所示。

圖4-10數據權限流程圖

4.4.5數據權限的實現

與一般信息管理支撐系統通過規則配置SQL語句實現數據權限不同，智慧管廊信息管理支撐系統通過MyBatis自帶的攔截器來實現數據權限。MyBatis允許已經在數據存儲層中完成映射的SQL語句在執行過程中的某一點通過使用插件來完成攔截調用，動態地對SQL語句進行拆分重組來實現數據權限，這樣的方案可以靈活地應對智慧管廊系統業務模塊的需求變化。

MyBatis常用的方法調用主要有以下四種卩叫

1、 Executor (update, query, flushstatements, commit, rollback, getTransaction, close, isClosed)

2、 ParameterHandler (getParameterObject, setParameters)

3、 StatementHandler (prepare, parameterize, batch, update, query)

4、 ResultSetHandler (handleResultSets, handleOutputParameters)

這四種方法分別是攔截執行器的方法、攔截參數的處理方法、攔截結果集的處理方法和攔截SQL語法構建的處理方法。數據權限的實現用到Executor接口的部分方法，比如 updatequerycommit,rollback 等；同時選擇 StatementHandler 的prepare方法來完成SQL執行前的攔截，然后重新封裝SQL。

MyBatis通過實現自帶的Interceptor接口的方法就可以實現攔截器的功能，該接口一共有三個實現方法，包括intercept、plugin和setProperties。其中plugin 方法用來封裝目標對象，然后將封裝之后的對象返回，返回結果即可以是目標對象本身，也可以是一個目標對象的代理，如果返回的是對象代理，則可以通過調用intercept方法對代理進行攔截處理；setProperties方法可以讀取MyBatis的配置文件，能夠指定其中的某些屬性，一般按照默認方法執行。

實現自定義攔截器主要是實現Interceptor接口的plugin方法和intercept方法。正如上文所述，plugin方法用來決定返回目標是對象本身還是代理以及判斷當前對象是否攔截；而intercept方法的主要功能是如果當前目標要進行攔截，則要調用intercept方法。

MyBatis中的Plugin類可以直接實現plugin方法，該類中有一個靜態方法 wrap(Object target,Interceptor interceptor),它可以決定圭寸裝之后的目標對象會返回對象本身還是對象的代理，在代碼實現時只需要將wrap方法的兩個參數配置為 target和this即可卩刃，因此對于自定義攔截器主要是實現intercept方法。

在實現攔截器功能之前需要對攔截器進行配置。首先新建一個普通類 MybatisConfig,然后使用©Configuration注解進行標注使其成為配置類，最后通 ii@Bean注解將自定義攔截器類Preparelnterceptor注入。

在配置完攔截器之后需要自定義權限注解@PermissionAop,通過注解 @Target、@Retention、@Documented 和@interface 來實現，這些注解的含義已在4.4.3節中說明，故不再贅述。自定義權限注解@PermissionAop中包含一個 String類型的變量value,表明該注解的值。

與操作權限在controller層配置權限類似，數據權限需要在dao層配置權限, 通過自定義注解@PermissionAop進行標注，表示dao層對應方法的數據庫表在操作時需要進行數據鑒權，具體實現是根據用戶角色加上動態字段來進行權限判定。

智慧管廊系統動態字段的數量會根據業務需求發生變化，若將角色判定和動態字段判定都放在攔截器實現類來實現將會增加系統的耦合性，因此對于數據權限的判定條件則統一放在配置文件中利用Java的反射機制來實現。配置文件分為獲取當前用戶角色區域和動態參數區域兩部分，在攔截器中利用Java反射機制獲取用戶角色和動態字段的實現方法的路徑，即可完成相應功能。

智慧管廊信息管理支撐系統通過UserUtils類來獲取這兩個區域的參數。首先UserUtils類需要引入HttpServletRequest方法來獲取當前用戶的user_id參數，接著通過將業務邏輯層的類標注為組件再加載組件的方法引入RoleService來查詢角色樹信息；最后引入動態字段對應的業務邏輯層實現方法。獲取當前用戶角色的方法和操作權限攔截器中獲取用戶角色方法相同，即通過 request.getParameter方法獲取用戶登錄之后返回的user_id參數且將其轉換為int 型變量ID,通過roleService的findRolesNameByUserldQ方法來獲取當前用戶對應的角色集合；接著要獲取動態字段，不同的動態字段獲取方法不同，但是實現原理都是相同的，主要是調用該字段對應的業務邏輯層的實現方法來獲取動態字段，比如對于動態字段description,該字段位于數據庫的role表，故首先需要在 UserUtils中引入RoleService,接著通過request.getParameter方法獲取用戶登錄之后返回的user_id參數且將其轉換為int型變量ID,再通過RoleService中的 findDescriptionByU serld ()方法獲取 description 這個動態字段。

自定義MyBatis攔截器的實現流程圖如圖4-11所示：

圖4-11攔截器流程圖

自定義攔截器Interceptor接口有兩個重要的注解，一個是@Intercepts,另一個是@Signature, @Signature 是一個數組，表示@Intercepts 的值。@Intercepts 注解的作用是表明當前定義的對象是一個攔截器對象，而@Signature則表明攔截器要攔截的接口、方法以及對應的參數類型，在本文中用到的方法為Executor. StatementHandler 和 MappedStatement,可以執行的方法包括 update> prepare 和 query o

如上文所述，對于Interceptor接口的三個方法只需要實現intercept方法即可，攔截器的主要功能都放在該方法中實現。首先通過反射機制獲取delegate父類的 BaseStatementHandler 的 mappedStatement 屬性；接著調用 PermissionAop 注解獲取需要判斷權限的dao層方法對應的數據庫表；然后進行動態字段的獲取, 首先需要通過Java反射機制獲取當前登錄用戶的角色信息，接著定位到該角色需要操作的動態字段，如果該角色需要操作某些動態字段且該字段存在于動態字

第四章韁蕙艷宣昌管理皺系統鯉計與實現

段配置文件中，則需要再通過Java反射機制獲取到該字段;最后進行SQL拼接，即實現數據權限最關鍵的步驟，首先判斷是行級權限還是列級權限，如果是行級權限則需要在對應的dao層SQL語句中加上where與動態字段名稱即可，如果是列級權限則需要對原SQL語句進行拆分，加上動態字段的限制條件之后再進行重組。通過以上方法就可以實現數據鑒權，從而為智慧管廊系統業務模塊提供數據鑒權功能支撐。

4.5智蕙管廊信息管理審批模塊的設計與實現

4.5.1審批模塊的設計

與一般信息管理系統實現特定業務的審批功能不同，智慧管廊信息管理審批模塊能夠實現通用審批功能,可以同時為巡檢維護模塊提供預案審批和作業審批功能支撐。在巡檢維護模塊的預案審批流程中，維修值班員首先需要制定類似管廊泄漏等突發事件的應急預案草稿請求監控員審批;監控員收到預案后提出修改意見，打回修改；維修值班員根據監控員意見修改后提交突發事件的應急預案二稿，請求監控員審批；監控員同意之后，突發事件應急預案生效，存檔可查, 維修值班員可以查看審批結果；如果監控員覺得當前的審批已經超過自己的權限范圍，則將預案信息交給上一級，即調度員進行審批，調度員審批流程和監控員之前的類似，只是不會再往上一級傳。作業審批的流程與預案審批類似，只是將應急預案變為入廊作業，故不在贅述。預案審批示意圖如圖4-12所示。

4.5.2審批模塊的實現

審批模塊的實現包括系統縱向架構層次的數據存儲層、數據訪問層、業務邏輯層和控制層，接著從這四層分別給出審批模塊的實現方案。

（1）•數據存儲層

數據存儲層主要是和審批有關的MySQL數據庫表的實現，包括reservePlan、 planAudit和plan_user三張表，如表4-7至表4-9所示。

reservePlan表主要存放審批信息，ID為表主鍵，無實際意義，planName 為審批計劃名稱，userid和userName為提交審批信息的人的ID和名字，addDate 為提交審批的時間,為String類型，需要填寫時間戳格式,state為審批信息狀態，分為0、1、2和3四種，其中0為未審批，1為審批通過，2為審批未通過，3 為交給上級處理。

表 4-7 reservePlan 表

字段名稱類型長度是否索引是否主鍵字段說明

id INT 11 Y ID

planName VARCHAR 255 審批名稱

userid INT 11 Y 提交審批人員ID

userName VARCHAR 255 提交審批人員名稱

addDate VARCHAR 255 添加日期

state INT 11 Y 審批狀態

planAudit表用來存放審批結果，ID為主鍵，無實際意義，planld為已經審

批的計劃的ID,userid和userName為審批人的ID和名字,auditinfo為審批信息。表 4-8 planAudit 表

字段名稱類型長度是否索引是否主鍵字段說明

id INT 11 Y ID

planld INT 11 Y 審批信息

userid INT 11 Y 審批人ID

userName VARCHAR 255 審批人名稱

auditinfo VARCHAR 255 審批信息

plan user表用來關聯user表和reservePlan表，實現通過審批信息ID查詢提交審批信息人員的信息，ID為主鍵，無實際意義，planld為計劃ID,通過外鍵與reservePlan的主鍵ID關聯，userid為用戶ID,通過外鍵與user的主鍵ID

關聯，進而實現通過審批信息ID獲取提交審批信息人員的信息。

表 4-9 plan user 表

字段名稱類型長度是否外鍵是否主鍵字段說明

id INT 11 Y ID

planid INT 11 Y 審批信息

userid INT 11 Y 用戶ID

(2) •數據訪問層

數據訪問層通過 ReservePlanRepository 和 PlanAuditRepository 來實現數據

的訪問，通過reservePlan和planAudit實體類來實現數據持久化。

ReservePlanRepository主要用到的方法以及功能如下所示:

save()方法：填寫reservePlan表各字段信息，其中state字段默認填寫為0, 表示未審批；

update。方法：更新reservePlan表中各字段的信息；

findNo()方法：獲取state=O的審批信息，即未審批信息；

findAIreadyO方法：獲取state=l和state=2的審批信息，即已審批信息； findCantReservePlan()方法：獲取state=3的審批信息，即交由上級審批的信息；

agree。方法：將state置為1,表示審批通過；

disagree()方法：將state置為2,表示審批未通過；

nextBoss()方法：將state置為3,表示交由上級審批；

findUserByPlanId()方法：通過 plan_user 關聯表利用 planld 獲取 userid,再通過嵌套SQL查詢獲取user表中的用戶信息。

PlanAuditRepository用到的方法以及功能如下所示：

save()方法：填寫planAudit表中各字段的信息；

update。方法：更新planAudit表中各字段的信息； findAll()方法：獲取planAudit表中的所有信息。

findPlanAuditById()方法：通過planld獲查詢planAudit表中的審批結果信 '息、O

deleteById()方法：通過ID刪除planAudit表中的審批結果信息。

reservePlan為審批信息的持久化類，映射審批信息表，其成員變量與上文中數據庫表字段對應，包括審批名稱planName,提交審批信息的用戶的userid, 提交審批信息的用戶的名字userName,提交審批的時間addDate,審批信息狀態 state =該類通過setter和getter方法將數據庫表字段與成員變量對應。

planAudit為審批結果的持久化類，映射審批結果表，其成員變量與上文中數據庫表字段對應，包括已經審批的計劃的planld,審批人的userid和名字 userName,審批信息auditinfo。該類通過setter和getter方法將數據庫表字段與成員變量對應。

(3).業務邏輯層

業務邏輯層通過 ReservePlanServicelmpl 和 PlanAuditServicelmpl 來實現業務邏輯。

ReservePlanServicelmp 1 通過調用 ReservePlanRepository 操作 reservePlan 來實現ReservePlanService的業務邏輯㈤］,主要用到的方法以及功能如下所示： save。方法：新建審批信息；

update。方法：更新審批信息；

findNo()方法：獲取未審批的信息；

findAlready()方法：獲取已審批的信息；

findCantReservePlan()方法：獲取無權限審批需要交由上級審批的信息； agree。方法：表示審批通過；

disagree。方法：表示審批未通過；

nextBoss()方法：表示無權限審批，交由上級審批；

fmdUserByPlanId()方法：通過 plan_user 關聯表利用 planld 獲取 userid,再通過嵌套查詢獲取用戶信息。

PlanAuditServicelmpl 通過調用 PlanAuditRepository 操作 planAudit 來實現 PlanAuditService的業務邏輯，主要用到的方法以及功能如下所示：

save()方法：新建審批結果信息；

update。方法：更新審批結果信息；

findAUO方法：獲取所有的審批結果信息；

findPlanAuditById()方法：通過planld獲查詢審批結果信息。 deleteById()方法：通過ID刪除審批結果信息。

(4).控制層

控制層主要通過 ReservePlanController 和 PlanAuditController 暴露接口給智慧管廊系統客戶端調用,其中ReservePlanController通過調用ReservePlanService, PlanAuditController通過調用PlanAuditService來實現功能，其本身不實現業務邏輯，都是調用service層中的功能，故對controller層的功能不再贅述。

審批功能包括一級審批和二級審批，一級審批的實現流程圖如圖4-13所示，二級審批的實現流程圖如圖4-14所示。

圖4-13 一級審批功能實現流程圖

4.6智JS管廊用戶信息管理的設計與實現

4.6.1用戶信息管理的設計

與一般信息管理系統管理所有用戶信息不同，智慧管廊用戶信息管理主要是為智慧管廊系統的業務模塊提供用戶信息管理功能支撐，包括以下功能：用戶信息、角色信息和權限信息的增刪改查、為用戶分配和刪除角色、為角色分配和刪除權限以及為用戶分配和刪除群組。用戶信息管理設計示意圖如圖4-15所示。

用戶信息管理

O xz O J , O O

MySQL數據庫

圖4-15智慧管廊用戶信息管理設計示意圖

4.6.2用戶信息他的實現

智慧管廊用戶信息管理的實現包括系統縱向架構層次的數據存儲層、數據訪問層、業務邏輯層和控制層，接著從這四層分別給出了用戶信息管理功能的實現方案。

(1) •數據存儲層

數據存儲層主要是和用戶信息管理相關的MySQL數據庫表的設計，主要包括角色樹、chatGroup與group user表。

角色樹涉及的數據庫表的設計與實現已在4.2節中說明，故不再贅述。

chatGroup為群組信息表，主鍵為chatGroupId,為群組的ID, chatGroupName 為群組名稱，chatGroupInfo為群組信息，如表4-10所示。

表 4-10 chatGroup 表

字段名稱類型長度是否索引是否主鍵字段說明

chatGroupId INT 11 Y Y 群組ID

chatGroupName VARCHAR 255 Y 群組名稱

chatGroupInfo VARCHAR 255 群組信息

group_user用來關聯user表和chatGroup表，實現通過群組ID查詢群組內包含的人員的信息，ID為主鍵，無實際意義，chatGroupId為群組ID,通過外鍵與chatGroup的主鍵chatGroupId關聯，userid為用戶ID,通過外鍵與user的主鍵ID關聯，實現通過群組ID獲取群組內包含的人員的信息，如表4-11所示。

4-11 group user 表

字段名稱類型長度是否外鍵是否主鍵字段說明

id INT 11 Y ID

chatGroupId INT 11 Y 群組ID

userid INT 11 Y 用戶ID

(2).數據訪問層

數據訪問層主要是通過 UserRepository , RoleRepository ,

PermissionRepository 和 ChatGroupRepository 來實現數據的訪問,通過 user, role» permission和chatGroup實體類來實現數據持久化。

UserRepository主要用到的方法以及功能如下所示：

save()方法：填寫user表中各字段的信息； update。方法：更新user表中各字段的信息； findUserByldO方法：通過userid作為查詢語句的查詢條件來查詢user表中的用戶信息；

findAll()方法：獲取除了參數為ID的所有user表中的信息； findAllUsersO方法：獲取user表中所有用戶信息； deleteByldO方法：從user表中刪除參數為ID的用戶信息； deleteByGroupIdO方法：通過群組ID刪除群組中的用戶； findIdByName()方法：從user表中查詢參數為name的用戶ID； findUserByChatGroupIdO方法:通過嵌套查詢從groupuser表中查詢參數為 chatGroupId對應的userid,再在user表中查詢該ID對應的用戶信息；

findUserByRoleId():通過嵌套查詢從role_user_relation表中查詢參數為 roleld對應的userid,再在user表中查詢該ID對應的用戶信息；

fmdUserByPermissionId():通過雙層嵌套查詢從 role_permission_relation 表中查詢參數為permissionld對應的roleld,再通過嵌套查詢從role user relation 表中查詢參數為roleld對應的userid,再在user表中查詢該ID對應的用戶信息。

RoleRepository主要用到的方法以及功能如下所示：

save。方法：填寫role表中各字段的信息；

update。方法：更新role表中各字段的信息；

findRoleById()方法：通過roleld作為查詢語句的查詢條件來查詢role表中的角色信息；

findAllRolesQ方法：獲取role表中所有角色的信息；

deleteRoleById()方法：從role表中刪除參數為ID的角色信息； findRoleByName()方法：從role表中查詢參數為name的角色信息；

findRoleByUserld()方法：通過嵌套查詢從role_user_relation表中查詢參數為userid對應的roleld,再在role表中查詢該ID對應的所有角色信息；

findRoleNameByUserId():通過嵌套查詢從 role_user_relation 表中查詢參數為userid對應的roleld,再在role表中查詢該ID對應的角色名稱；

findRoleByPermissionld()方法:通過嵌套查詢從 rolejpermission_relation 表中查詢參數為permissionld對應的roleld,再在role表中查詢該ID對應的角色信息；

findExtraRolesByUserld()方法：通過嵌套查詢從 role_user_relation 表中查詢參數為userid對應的roleld,再在role表中查詢該ID對應的已有的角色信息；

findNotOwnedExtraRolesByU serld ()方法:通過嵌套查詢從 role_user_relation 表中查詢參數為userid對應的roleld,再在role表中查詢該ID對應的未擁有的角色信息；

saveRoleUserRelation()方法：在 role_user_relation 表中插入參數為 role_id 和user_id的數據，使其一一對應；

deleteRoleUserRelationByUserId()方法：通過參數 user_id 將 role_user_relation表中的相關數據刪除。

PermissionRepository主要用到的方法以及功能如下所示:

save()方法：填寫permission表中各字段的信息；

updateQ方法：更新permission表中各字段的信息；

findPermissionById()方法：通過permissionld作為查詢語句的查詢條件來查詢permission表中的權限信息；

findAllPermissions()方法：獲取permission表中所有權限的信息； deletePermissionById()方法:從permission表中刪除參數為ID的權限信息； findPermissionByUserld()方法：通過雙層嵌套查詢從 role_user_relation 表中查詢參數為userid對應的roleld,再通過嵌套查詢從role_permission_relation表中查詢參數為roleld對應的permissionld,再在permission表中查詢該ID對應的權限信息；

findPermissionldByRoleld()方法：通過嵌套查詢從 role_permission_relation 表中查詢參數為roleld對應的permissionld,再在permission表中查詢該ID對應的權限ID；

findPermissionNameByRoleId() 方法：通過嵌套查詢從 role_permission_relation 表中查詢參數為 roleld 對應的 permissionld,再在 permissioii表中查詢該ID對應的權限名稱；

findExtraPermissionByRoleId()方法：通過嵌套查詢從 role_permission_relation 表中查詢參數為 roleld 對應的 permissionld,再在 permission表中查詢該ID對應的已有的權限信息；

findNotOwnedExtraPermissionsByRoleId()方法：通過嵌套查詢從 role_permission_relation 表中查詢參數為 roleld 對應的 permissionld,再在 permission表中查詢該ID對應的未擁有的權限信息；

saveRolePermissionRelationQ方法：在 role_permission_relation 表中插入參數為role_id和pemiission_id的數據，使其對應；

deleteRolePermissionRelationByRoleldO 方法：通過參數 role_id 將 role_pennission_relation表中的相關數據刪除。

ChatGroupRepositoiy主要用到的方法將在群組信息管理部分詳細說明，在用戶信息管理部分用到的方法以及功能如下所示：

saveGroupUserRelation()方法：在 group user 表中插入參數為 userid 和 chatGroupId的數據，使其——對應。

deleteGruopUserRelationByUserId()方法：通過參數 userid 將 group user 表中的相關數據刪除。

user為用戶信息的持久化類，映射用戶表，其成員變量與上文中數據庫表字段對應，包括用戶的ID,用戶郵箱email,用戶微信we_chat,用戶電話phone, 用戶部門departmento該類通過setter和getter方法將數據庫表字段與成員變量對應。

role為角色信息的持久化類，映射角色表，其成員變量與上文中數據庫表字段對應，包括角色ID,角色名稱name,角色描述description。該類通過setter 和getter方法將數據庫表字段與成員變量對應。

permission為權限信息的持久化類，映權限表，其成員變量與上文中數據庫表字段對應，包括權限ID,權限名稱name,權限描述description。該類通過setter和getter方法將數據庫表字段與成員變量對應。

chatGroup為群組信息的持久化類，將在群組信息管理部分詳細說明。

(3).業務邏輯層

業務邏輯層主要是通過 UserServicelmpl , RoleServicelmpl , PermissionServicelmpl 和 chatGroupServicelmpl 來實現數據的訪問。

UserServicelmpl 通過調用 UserRepository 操作 user 來實現 UserService 的業務邏輯，主要用到的方法以及功能如下所示：

save()方法：增加用戶信息；

update。方法：更新用戶信息；

findUserById()方法：通過userid查詢用戶信息；

findAlK)方法：獲取除了參數為ID的所有用戶信息； findAUUsersO方法：獲取所有用戶信息； deleteById()方法：刪除參數為ID的用戶信息； HndldByNameO方法：查詢參數為name的用戶信息； fmdUserByChatGroupIdO方法:通過群組ID獲取該群組中的所有用戶信息; deleteByGroupIdO方法：通過群組ID刪除群組中的用戶； HndUserByRoleldO方法：通過角色ID獲取用戶信息； fmdUserByPermissionId()方法：通過權限ID獲取用戶信息。

RoleServicelmpl 通過調用 RoleRepository 操作 role 來實現 RoleService 的業務邏輯，主要用到的方法以及功能如下所示：

save()方法：增加角色信息； update。方法：更新角色信息； findRoleById()方法：通過roleld查詢角色信息； findAllRoles()方法：獲取所有角色的信息； deleteRoleById()方法：刪除參數為ID的角色信息； findRoleByName()方法：通過角色名稱獲取角色信息； HndRoleByUserldO方法：通過用戶ID獲取所有的角色信息； fmdRoleNameByUserld()方法：通過用戶ID獲取角色名稱； HndRoleByPermissionId()方法：通過權限ID獲取角色信息； findExtraRolesByUserldO方法：通過用戶ID獲取該用戶擁有的角色名稱； findNotOwnedExtraRolesByUserldO方法:通過用戶ID獲取該用戶未擁有得角色名稱；

saveRoleUserRelation()方法：為用戶分配角色； deleteRoleUserRelationByUserId()方法：為用戶刪除分配的角色。 PermissionServicelmpl 通過調用 PermissionRepository 操作 permission 來實現PermissionService的業務邏輯，主要用到的方法以及功能如下所示：

save()方法：增加權限信息；

update。方法：更新權限信息；

findPermissionById()方法：通過ID查詢權限信息； findAHPermissionsO方法：獲取所有權限信息； deletePermissionById()方法：通過ID刪除權限信息； findPermissionByUserId()方法：通過用戶ID獲取權限信息； findPermissionIdByRoleId()方法：通過角色ID獲取所有權限ID； findPermissionNameByRoleId()方法：通過角色ID獲取所有權限名稱；

findExtraPermissionByRoleldO方法：通過角色ID獲取該角色擁有的權限信息；

findNotOwnedExtraPermissionsByRoleld()方法：通過角色 ID 獲取該角色未擁有的權限信息；

saveRolePermissionRelation()方法：為角色分配權限； deleteRolePermissionRelationByRoleId()方法：為角色刪除分配的權限 ° ChatGroupServicelmpl 通過調用 ChatGroupRepository 操作 chatGroup 來實現ChatGroupService的業務邏輯，主要用到的方法將在群組信息管理部分詳細說明，在用戶信息管理部分用到的方法以及功能如下所示：

saveGroupUserRelation()方法：為用戶分配群組； deleteGruopUserRelationByUserldO方法:為用戶刪除分配的群組。

(4) •控制層

控制層主要用到 UserController^ RoleController> PermissionController 和 ChatGroupController來暴露接口給智慧管廊系統客戶端調用，其中UserController 調用 UserService, RoleController 調用 RoleService, PermissionController 調用 PermissionService, ChatGroupController 調用 ChatGroupService 來實現功能，其本身不實現業務邏輯，都是調用service層中的功能，故對controller層的功能不再贅述。

智慧管廊用戶信息管理層級調用圖如圖446所示。

圖4-16智慧管廊用戶信息管理層級調用圖

4.7智慧管廊群組信息管理的設計與實現

4.7.1群組信息WS的設計

與一般信息管理系統管理所有群組信息不同，智慧管廊群組信息管理主要是為智慧管廊系統的業務模塊提供群組信息管理的功能支撐，包括以下功能：群組信息的增刪改查、為群組添加和刪除用戶。智慧管廊群組信息管理設計示意圖如圖4-17所示。

群組信息管理

MySQL數據庫

圖4-17智慧管廊群組信息管理設計示意圖

4.7.2群組信息魄的實現

智慧管廊群組信息管理的實現包括系統縱向架構層次的數據存儲層、數據訪問層、業務邏輯層和控制層，接著從這四層分別給出群組信息管理的實現方案。

(1)•數據存儲層

數據存儲層主要是和用戶信息管理相關的MySQL數據庫表的設計，主要包括 chatGroup 與 group user 表。

chatGroup與group user表都已在4.6節中說明，故不再贅述。

(2)•數據訪問層

數據訪問層主要是通過ChatGroupRepositoiy來實現數據的訪問，通過 chatGroup實體類來實現數據的持久化。

ChatGroupRepository主要用到的方法以及功能如下所示：

save()方法：填寫user表中各字段的信息； update。方法：更新user表中各字段的信息； findGroupById()方法：通過參數ID從chatGroup表中查詢數據； findGroupByName()方法：通過參數name從chatGroup表中查詢數據； findAll ()方法：獲取chatGroup表中的所有數據； deleteById()方法：通過參數ID從chatGroup表中刪除數據； findGroupByUserld()方法：通過嵌套查詢用參數userid從group_user表中查詢chatGroupId,再從chatGroup表中查詢此ID對應的數據；

saveGroupUserRelation()方法：在 group user 表中插入參數為 userid 和 chatGroupId的數據，使其對應；

deleteGroupUserRelationByGroupId()方法:通過參數 groupld 刪除 groupuser 表中相應的數據。

chatGroup為群組信息的持久化類，映射群組信息表，其成員變量與上文中數據庫表字段對應，包括群組ID,群組名稱chatGroupName,群組信息 chatGroupInfo»該類通過setter和getter方法將數據庫表字段與成員變量對應。

(3)•業務邏輯層

業務邏輯層通過 ChatGroupServicelmpl 調用 ChatGroupRepository 操作 chatGroup來實現ChatGroupService的業務邏輯，主要用到的方法以及功能如下所示：

save()方法：新建群組信息；

update。方法：更新群組信息； findGroupById()方法：通過參數ID查詢群組信息； findGroupByName()方法：通過參數name查詢群組信息； findAll。方法：獲取所有群組信息； deleteById()方法：刪除參數為ID的群組信息； findGroupByUserId()方法：通過userid查詢用戶對應的群組信息； saveGroupUserRelation()方法：為群組中添加用戶； deleteGroupUserRelationByGroupId()方法：刪除群組中的用戶。

(4).控制層

控制層通過ChatGroupControUer來暴露接口給智慧管廊系統客戶端調用，通過調用ChatGroupService來實現功能，其本身不實現業務邏輯，都是調用 service層中的功能，故對controller層的功能不再贅述。

智慧管廊群組信息管理層級調用圖如圖4-18所示。

圖4-18智慧管廊群組信息管理層級調用圖

4.8智慧管廊信息他性能需求的設計與實現

4.&1穩定性fflf求的設計與實現

智慧管廊信息管理支撐系統穩定性的實現主要是優化數據庫的讀寫。通過優化數據庫的讀寫提高接口的響應速度，進而實現系統的穩定性需求。

智慧管廊信息管理支撐系統采用HTTP （超文本傳輸協議）協議將后臺接口提供給前端調用，前端調用的請求依次經過系統的控制層、業務邏輯層和數據訪問層，最終在數據存儲層的MySQL數據庫執行SQL語句，實現數據庫的查詢操作。因此對數據庫的查詢操作進行優化可以提升查詢速度，進而提升調用接口的速度。

在4.3.2節登錄模塊的實現中設計了 user credentials表，該表存儲了用戶加密后的密碼，并且與用戶表相對應，這種將對應關系單獨設計一張表的思想即為數據庫設計中的“分表”思想，這樣做的優勢是可以降低用戶表的復雜性，方便用戶信息與加密后密碼的獨立調用；用戶在登錄系統時需要查詢用戶加密后的密

碼但是不需要用戶的其他信息，而查詢用戶信息時則不需要查詢用戶密碼，因此在單獨設計一張表之后，對相應字段設置索引即可滿足實際需求。設置索引之后進行查詢時不會再進行全表查詢，只會查詢對應的數據，因此系統其余數據庫表涉及到查詢操作時都會添加索引。這樣的設計方案可以提升數據庫表查詢速度，進而提升接口的響應速度，實現了系統的穩定性。

4.8.2安全性需求的設計與實現

智慧管廊信息管理支撐系統安全性的實現主要是對登錄用戶進行鑒權，判斷其身份的合法性以及在系統操作時進行鑒權，保證系統操作和系統數據的安全。

在4.3節中可知，用戶登錄系統時需要輸入用戶名和密碼，接著登錄模塊會進行鑒權，只有用戶身份合法才能登錄系統進行操作，從而可以防止非法用戶登錄系統，確保系統的安全性；在4.4節中可知，當用戶登錄系統之后才能進行系統操作，而在系統操作時會進行操作鑒權，如果當前用戶執行其權限范圍外的操作則會被攔截，從而可以保證系統操作的安全性；同時在數據操作時也會進行數據鑒權，當前用戶只能操作其權限范圍內的數據，從而可以避免系統的數據泄露。因此通過智慧管廊信息管理支撐系統鑒權模塊可以很好的實現系統的安全性需求O

4.8.3復用性需求的設計與實現

智慧管廊信息管理支撐系統復用性的實現主要是實現權限的復用和用戶信息管理功能的復用。

在4.4節中可知，鑒權功能主要是通過在控制層和數據訪問層添加注解將功能與指定角色對應，通過判斷當前角色與指定角色是否匹配來進行鑒權，因此智慧管廊系統的業務模塊在實現鑒權功能時只需調用鑒權模塊，通過添加注解將功能與角色對應即可，不需要再單獨實現攔截器的邏輯，從而實現權限的復用；在智慧管廊業務模塊的需求中PC端和移動端都需要進行用戶信息管理，用戶信息管理模塊通過暴露接口可以同時給PC端和移動端提供功能支撐，避免了相同功能的重復開發，從而實現了用戶信息管理功能的復用。

4.8.4可擴展性需求的設計與實現

智慧管廊信息管理支撐系統可擴展性的實現主要是實現接口和系統架構的合理設計。

在3.3節中可知，智慧管廊信息管理支撐系統的架構基于前后端分離、后臺模塊化和分層化的方案進行設計。前后端分離開發的優勢是實現項目解耦，可以使前后端并行開發，同時使得接口的設計擁有統一的規范，形如api/vl/user/..., 在調用時具有較好的適配性；模塊化開發可以將模塊解耦，減少模塊之間的依賴，達到在增加功能時最小化改動現有模塊的效果；分層化設計將功能模塊分為不同層次獨立開發，各層完成不同的功能，層與層之間相互調用，層次之間的耦合性也降到了最低。這樣的架構設計方案很好的實現了系統的可擴展性。

4.9本章小結

本章給出了智慧管廊信息管理支撐系統子模塊的設計與實現方案，說明了子模塊的設計示意圖和流程圖、各模塊實現所用到的技術以及為智慧管廊系統業務模塊提供的功能支撐。

第一節闡述了智慧管廊信息管理支撐系統的功能。

第二節給出了智慧管廊信息管理角色樹的設計與實現方案。角色樹的實現主要是在數據存儲層，通過三張主表和兩張關聯表來實現角色樹。

第三節給出了智慧管廊信息管理登錄模塊的設計與實現方案，包括登錄的流程和用到的shiro框架、OAuth2技術和token機制，以及登錄模塊的具體實現方案。登錄模塊為智慧管廊系統提供了登錄支撐，是系統的基礎功能。

第四節給出了智慧管廊信息管理鑒權模塊的設計與實現方案，該部分是本文的核心。該模塊將權限分為操作權限和數據權限，其中操作權限為智慧管廊系統業務模塊提供操作鑒權功能支撐，使用攔截器來實現，通過判斷當前用戶對應的角色來對角色進行攔截，與Spring Security相比降低了系統的耦合性和復雜性；數據權限為智慧管廊系統業務模塊提供數據鑒權功能支撐,系統中的不同用戶可能成為相同的角色，此時在進行數據操作的時候會出現到用戶數據共享問題，同時還涉及到字段權限，數據權限通過MyBatis的攔截器來動態的攔截和拆分SQL 語句，使SQL執行結果符合系統的業務需求，從而實現數據權限。

第五節給出了智慧管廊信息管理審批模塊的設計與實現方案。審批模塊為巡檢維護模塊提供審批功能支撐，通過改變數據庫字段的狀態來對應審批流程中的各個狀態，配合操作權限和數據權限可以高效的實現巡檢維護模塊的審批需求。

第六節給出了智慧管廊用戶信息管理功能的設計與實現方案，為智慧管廊系統業務模塊提供用戶信息管理功能支撐。用戶信息管理的實現包括數據存儲層、數據訪問層、業務邏輯層和控制層，本文從這四層對該模塊的設計與實現方案進行說明。

第七節給出了智慧管廊群組信息管理功能的設計與實現方案，為智慧管廊系統業務模塊提供群組信息管理功能支撐。群組信息管理的實現包括數據存儲層、數據訪問層、業務邏輯層和控制層，本文從這四層對該模塊的設計與實現方案進行說明。

第八節給出了智慧管廊信息管理性能需求的設計與實現方案，從穩定性、安全性、復用性和可擴展性四個方面說明了系統的性能需求實現方案。

第五章智慧管廊信息管理支撐系統功能測試及性能分析

5.1智慧管廊信息管理支撐系統功能測試

智慧管廊信息管理支撐系統通過給智慧管廊系統客戶端提供接口 URL調用的方式為智慧管廊系統業務模塊提供功能支撐，因此系統的功能測試主要是針對各功能模塊的接口來進行測試，用到的工具是postman,該工具專門用于測試后臺的接口，包括常見的四種類型GET （獲取）、POST （插入）、PUT （更新）和 DELDETE （刪除）的URL測試。同時為了某些流程和數據可以直觀的展示，也會采用前端頁面展示的方式來測試相應模塊的功能。

5.1.1角色樹功能測試

智慧管廊信息管理角色樹主要涉及用戶-角色-權限三者之間的關系，通過單獨實現用戶管理、角色管理和權限管理的接口以及實現角色樹通用的接口來完成角色樹的功能。其中用戶信息管理的相關接口會在后續章節單獨測試，故本節只列出角色管理、權限管理和角色樹通用的接口列表以及測試結果，具體的接口列表如表5-1至表5-3所示：

表5-1角色role接口表

接口類型接口 URL 接口描述傳入參數返回值

GET /api/vl/user/role 獲取所有的角色信息無所有角色信息

GET /api/v 1/user/roleCount 統計有多少角色無角色的數量

GET /api/vl/user/fmdRoleByld 根據角色ID 獲取角色信息 roleld 角色信息

POST /api/vl/user/role 增加角色的信息角色實體類信息新增信息

PUT /api/vl/user/role 更新角色信息角色實體類信息更新信息

DELETE /api/vl/user/ deleteRoleByld 通過ID刪除角色信息 roleld 刪除信息

表5-2權限permission接口表

接口類型接口 URL 接口描述傳入參數返回值

GET /api/vl /user/permissions 獲取所有權限無所有權限信息

GET /api/vl/user/permissionCount 統計有多少權限無權限的數量

（續上表）

接口類型接口 URL 接口描述傳入參數返回值

GET /api/vl/user/permissionByld 根據權限ID 獲取權限信息 permissionld 信艮權息

POST /api/vl /user/permission 增加權限的信息權限實體類信息信增新息

PUT /api/vl /user/permission 更新權限信息權限實體類信息更新信息

DELETE /api/vl/user/permissionByld 通過ID刪除權限信息 permissionld 刪除信息

表5-3角色樹接口表

接口類型接口 URL 接口描述傳入參數返回值

GET / api/vl /user/userByRo leld 根據角色ID 獲取用戶信息 roleld 用戶信息

GET /api/vl/user/userByPermissionl d 根據權限ID 獲取用戶信息 permission

Id 用戶信息

GET /api/vl/user/allRolesByUserld 根據用戶ID 獲取角色信息 userid 角色信息

GET /api/vl/user/findRolesNameBy Userid 根據用戶ID 獲取角色名稱 userid roleNa me

GET /api/vl/user/findRoleByPermis sionld 根據權限ID 獲取角色信息 permission Id 角色信息

GET /api/vl/user/findAllByUserld 根據用戶ID 獲取權限信息 userid 權限信息

GET /api/vl/user/findPermissionlds ByRoleld 根據角色ID 獲取權限ID roleld permissi onld

GET /api/vl/user/findPermissionNa mesByRoleld 根據角色ID 獲取權限名稱 roleld permissi onName

GET /api/vl/user/userRoles 獲取一個用戶分配的角色信息無分角息一戶的宣用配色

GET /api/vl/user/notOwnedRoles 獲取一個用戶未分配的角色信息無用戶未分配的角色信息

GET /api/vl /user/ro lePermission 獲取一個角色分配的權限信息無角色分配的權限信息

GET /api/vl/user/roleNotOwnedPer mission 獲取一個角色未分配的權限信息無角色未分配的權限信息

（續上表）

接口類型接口 URL 接口描述傳入參數返回值

POST /api/vl/user/user/role 為一個用戶分配角色角色實體類信息新增信息

POST /api/vl /user/role/permission 為一個角色分配權限權限實體類信息新增信息

DELETE /api/vl/user/user/role 為一個用戶刪除角色無刪除信息

DELETE /api/vl /user/user/deleteRoleBy Userid 通過用戶ID 刪除角色 userid 刪除信

息

DELETE /api/vl /user/permissionByRo le

Id 通過角色ID 刪除權限 roleld 刪除信息

如表5-1至表5-3所示角色樹用到的功能接口，通過postman測試，所有接口都可以實現其對應的功能，進而完成角色樹的功能。

5.1.2登錄功能測試

登錄功能為智慧管廊系統提供登錄功能支撐，包括PC端和移動端。PC端登錄首頁如圖5-1所示，移動端登陸首頁如圖5-2所示。

圖5-1 PC端登錄界面

應急掲揮

圖5-2移動端登錄界面

登錄功能通過接口的方式來實現，具體的接口列表如表5-4所示:

表5-4登錄信息接口表

接口類型接口 URL 接口描述傳入參數返回值

GET /api/vl/user/logout 退出登錄接口無退出登錄信息

POST /ap i/v 1 /user/lo gin 登錄接口 username, password Token

POST /api/vl/user/refreshToken 刷新token接口無刷新之后的 Token

PUT / api/vl /user/changePassword 修改密碼接口舊密碼與新密碼修改結果信息

其中最主要的是登錄接口。登錄接口是POST方法，在調用時需要輸入用戶名和密碼，在postman中的請求體body如圖5-3所示：

■{■'user-iame*': ,r£u-ncr: .-zuSgraail. co?n"/'psss..'ord" : "123456"}

圖5-3登錄用戶名和密碼

在postman調用登錄接口輸入用戶名和密碼之后，如果用戶名和密碼正確就會返回Token信息，如圖5-4所示；如果用戶名和密碼錯誤，在智慧管廊系統前端則會提示登錄失敗，如圖5-5所示。

亡:jhbGciC

,'token-Typet,: %

Mreccesaken,f:

nexpire5_in**: 899,

Hscape1': 'Tencnt_ivw: 3, ,,user_idB: 4, "lig亡廣 r3,r i ' f

圖5?4 Token信息

圖5-5用戶登錄失敗界面

經過postman測試，登錄功能的所有接口也可以實現對應的功能，進而為智慧管廊系統提供登錄功能支撐。

5.1.3操作權限功能測試

登錄之后就可以進入智慧管廊系統進行操作，而不同的權限的用戶在登錄之

后的頁面也不相同，其中系統管理員不但可以操作展示平臺也可以操作運維平臺, 例如統一日志中心；而普通用戶只可以操作展示平臺不可以操作運維平臺。系統管理員登錄首頁如圖5-6所示，普通用戶登錄首頁如圖5-7所示：

圖5-6系統管理員首頁

圖5-7普通用戶首頁

由圖5-6和圖5-7對比可以看出，只有系統管理員的權限才能操作所有平臺, 普通用戶的權限只能操作展示平臺。進入信息管理平臺之后的頁面如圖5-8所示。

圖5-8信息管理平臺首頁展示圖

當前登錄用戶對應的角色為總中心調度員，擁有最高的操作權限，可以操作系統的所有功能。例如獲取所有審批信息的接口 URL為/api/vl/user/planAudit, 由于操作權限的鑒權是通過攔截器來實現的，故需要在對應操作的URL之后添加對應用戶的 user_id,此時 URL 變為/api/vl/user/planAudit?user_id=4。如果當前的用戶沒有該功能的操作權限則會被攔截，例如user_id=8的用戶為維修員，執行該操作則會被攔截，攔截之后的結果如圖5-9所示。

訪問12700.1的請求遭到拒絕

壇未戀壬.無法査看就盤頁。

HTTP ERROR 403

圖5-9無操作權限攔截結果

操作權限通過攔截器實現，所有用戶執行操作時都需要在對應操作的URL 末尾帶上自己的userjd來進行鑒權。通過上述接口舉例可以實現操作權限功能的測試。

5.1.4數據權限功能測試

同操作權限相同，數據權限也是通過攔截器來實現，因此在訪問需要數據鑒權的接口時也需要在對應的URL末尾帶上當前用戶的user_id；與操作權限不同的是，所有接口都需要進行操作鑒權，而只有業務模塊操作數據的接口才需要進行數據鑒權。

例如在系統中，只有系統管理員才能獲取所有角色信息，此時就涉及到數據鑒權。獲取所有角色信息的URL是/api/vl/user/role,如果當前用戶為系統管理員，其訪問該接口時對應的URL為/api/vl/user/role?user_id=l,由于其數據權限最高, 可以獲取所有的角色信息，如圖5-10所示；如果當前用戶為總中心調度員，其訪問該接口時對應的URL為/api/vl/user/role?user_id=4,盡管其操作權限最高但是不具有該操作的數據權限，因此只能獲取其對應的角色信息，如圖5-11所示。

[{*id*:l「name":”SYS_ADMIN"「description":"系統管理員 {*id":2,"name”:"TENANT_ADMIN","ciesaiption*:•租戶管理員”}, 「id":3,*name*:"CUSToMER_USER",*desaiption":"普通用戶工 {"id*:4,"name*:*GeneralDispatcher*,"description*:* 總中心調度員 {*id*:5,"name":*GeneralMonit0 廣,*description":* 總中心監控員"},

"name*:* BranchDispatcher*, "description":1■分中心調度員"}, {*id*:7rname*:"BranchMonitor"「description*:"分中心監控員"}, {*icT:8,"name*:”RepakMan","description":* 維修值班員”}, {*id*:9,"name*:"PipeRepairMan","description*:* 管線單位維修員 {"id*:10,"name":*Municipal*,"descriptiorT:"市政*}, {*id*:ll,*name":"Police","description":"公安*}, {"id^U/name":" Hospital "/description°醫院"}, {"id*:13,"name":"Gas*,"description*:"天然氣*}]

圖5-10系統管理員數據鑒權結果

[{"id":4,"name":"GeneralDispatcher："desciiptiorT:"總中心調度員"}]

圖5-11總中心調度員數據鑒權結果

數據權限通過MyBatis攔截器實現，為業務模塊提供數據鑒權功能支撐。涉及到用戶數據共享的接口需要進行數據鑒權，在鑒權時需要在對應接口的URL 末尾帶上自己的userjd來進行數據鑒權。通過上述接口舉例可以實現數據權限功能的測試。

5.1.5審批功能測試

審批功能是通過接口來獲取未審批的計劃信息，再通過接口改變計劃信息的狀態來實現審批功能，同時還可以通過接口查詢已審批的計劃信息和審批結果，從而為巡檢維護模塊提供預案審批和作業審批功能支撐。

審批功能接口列表如表5-5和表5-6所示：

表5-5審批計劃信息和審批功能接口表

T E

G T 無計

比量報數審劃

G Ms

e 怡g 無審劃有計翊所批的

G ■tId d 說 h

P 計、比息曲信審劃

T 計

眈息

信

審劃

G d lalll p 用戶信息

T E

G an_ e 一 L 批信審劃未計息

G X 0 批信審劃已計息

T E

G /api/an 所限息取權偉獲無劃無限計權批施無審坡

增傳計實息批息儉審仕劉信增新息

T U

P MZ息劃體一計實息批息< 審信類信新更息

T U

P /api/lan 無信批審息

T U

P X 無信批審息

（續上表）

接口類型接口 URL 接口描述傳入參數返回值

PUT /api/vl/user/nextBoss 交給上級審批無審批信息

DELETE /api/v 1/user/reserveP lanBy

Id 通過ID刪除計劃信息 planld 刪除信息

表5-6審批信息接口表

接口類型接口 URL 接口描述傳入參數返回值

GET /api/vl/user/planAudit 獲取所有的審批信息無所有審批結果信息

GET /api/vl /user/planAuditCount 統計有多少審批信息無審批結果數量

GET /ap i/vl/ user/planAud itPages 獲取所有的審批的頁數無審批結果頁數

GET /api/vl /user/planAuditByld 根據ID獲取審批信息 planld 審批結果信息

POST /api/vl/user/planAudit 增加審批信息審批信息實體類新增信息

PUT /api/vl /user/planAudit 更新審批信息審批信息實體類更新信息

DELETE /api/vl/user/planAuditByld 通過ID刪除

審批信息 planld 刪除信息

實現預案審批功能時，首先要獲取未審批的預案信息，如圖5-12所示，可以對該預案信息進行刪除和審批；當點擊新建審批時會出現如圖5-13所示的界面，需要填寫審批人信息和審批意見，以及審批通過或者不通過，此時就完成了審批功能，可以在已審批列表中看到已經審批完成的信息，如圖5-14所示；同時也可以查看審批結果，如圖5-15所示。作業審批功能與預案審批功能類似，故不再贅述。

信息 jssdssr

圖5-12未審批的預案信息

5)r»Mm ^««bupteduxn igW:—®

u®5t

?丈總牆揮?傾更車址?犬審妣

• 50S4 :

＞京軋人：6

?seii&SJ-

ES1

圖 5-13

審批頁面

德庠匱理系焼 KflttS 遽繪站 ES3SK- 入?作業運営飆

Es^t 示我如

? ＞痰韋率歩＞ BKRt

離星Q itSKS 馬佝£＞

JW^S SESSS

&us* "Srt!-Sl-旳 G9.?& 42

Ztt： W袴■•?】2g祐 47

圖5-14已審4t匕的預案信息

ABfRt 運3S3

ty«Admin9bupL«du tn itijBLt-

ciS«

?寂藝宿揮?僉宰審生?題批疙累

J5S1D 冃TD

spa

圖5-15審批結果信息

通過postman對審批功能的接口進行測試，結果顯示所有接口都可以完成其對應的功能；在智慧管廊前端界面進行審批操作也可以完成審批流程，從而證明審批功能可以正常實現。

5.1.6用戶信息管理功能測試

用戶信息管理功能主要是對用戶信息進行統一的管理，為智慧管廊系統提供用戶管理功能支撐，包括PC端和移動端，使用的是同一套用戶信息，同時還涉及到角色樹的部分功能，這些功能主要是通過接口的方式來實現，接口列表如表 5-7所示：

表5-7用戶信息管理接口表

接口類型接口 URL 接口描述傳入參數返回值

GET /api/vl/user/userByP age 分頁接口配置，有篩選參數返回篩選參數的，沒有則顯示全部 limit 和

name 用戶信息

GET /api/vl /user/userPage s 獲取所有的用戶的頁數無用戶信息頁數

GET /api/vl /user/userByld 根據用戶ID獲取用戶信息 userid 用戶信息

GET /api/vl /user/userByN ame 根據用戶名稱獲取用戶信息 userName 用戶信息

GET /api/vl/user/userByG roupld 根據群組ID獲取用戶信息 groupld 用戶信息

GET /api/vl /user/userCou nt 統計有多少用戶無用戶數量

GET /api/vl /xiser/idByNa me 根據用戶ID獲取用戶名稱 userid userNa me

GET /api/vl/user/user 獲取所有的用戶信息（不包括當前登錄用戶）無用戶信息

GET /api/vl /user/allUsers 獲取所有的用戶信息（包括當前登錄用戶）無用戶信息

POST /api/vl/user/user 增加用戶的信息用戶實體類信息新增信息

POST /api/vl/user/user/gro up 為一個用戶分配群組群組實體類信息新增信息

PUT /api/vl/user/user 更新用戶信息用戶實體類信息更新信息

DELETE /api/vl /user/userByld 通過ID刪除信息 userid 刪除信息

DELETE /api/vl/user/user/gro up 為一個用戶刪除群組無刪除信息

用戶信息管理在PC端主要是在巡檢維護模塊管理員工信息，如圖5-16所示; 同時在PC端展示操作系統的用戶信息，如圖5-17所示；在移動端主要是獲取除當前用戶的其他用戶信息，在應急指揮模塊通訊使用以及給用戶分配群組，完成群聊功能，如圖5-18所示。

AfffTft ^ttS . «&£-«

兔據翻J Sr?^

権購.芻辛無皿一

&ywr«a yrii^JgC：*- "r：fc.<W- 472.t8S3R

親W： ::?4598如

:£S至 06*u d'W好;，彳淬沖20沁；替冰•>

^；;- '■ F"

細潑2 羅歹=、■ 214，，.g：wa v'^'.' ^.x" ? > 燙琴.

JT：»謎鴻

圖5-16 PC端用戶信息管理界面

圖5-17 PC端操作系統的用戶信息界面

O s^mory wu

O総敷

O ^hny

O bryce

O bamzi

O蝕

圖5-18移動端用戶信息管理界面

第五蔓置慧管廊腿萱理支撐垂統功能測試及性能分析

通過postman對用戶信息管理相關的接口進行測試，結果顯示所有接口都可以完成其對應的功能；在前端界面和移動端進行用戶信息的相關操作也可以完成對應的功能，從而證明用戶信息管理模塊可以為智慧管廊系統提供用戶信息管理功能支撐。

5.1.7群組信息管理功能測試

群組信息管理主要是對群組信息進行統一管理，為移動端應急指揮模塊的群聊功能做支撐，可以實現群組信息的增刪改查操作以及在群組中添加和刪除用戶。具體實現也是通過接口的方式來實現，涉及到的接口列表如表5-8所示：

表5-8群組信息管理接口表

接口類型接口 URL 接口描述傳入參數返回值

GET /api/v 1 /user/groupByPa ge 配合分頁設置，獲取所有的群組信息 limit 所有的群組信息

GET /api/vl /user/groupCoxint 統計有多少群組無群組數量

GET /api/vl /user/groupPages 獲取所有的群組的頁數無群組頁數

GET /api/ v 1 /user/groupByl d 根據ID獲取群組

信息 groupld 群組信息

GET /api/ v 1 /user/groupIdBy Name 根據群組名字獲取群組ID groupld groupNam

GET /api/vl /user/group 獲取所有群組信息無所有群組信息

GET / api/vl/user/groupByU s erid 根據用戶ID獲取群組信息 userid 群組信息

POST /api/vl /user/group 增加群組信息群組實體類信息新增信息

POST /api/vl/user/group/user 為一個群組分配用戶用戶實體類信息新增信息

PUT /api/vl/user/group 更新群組信息群組實體類信息更新信息

DELETE /api/vl/user/groupByld 通過ID刪除信息 groupld 刪除信息

DELETE / api/ v 1/user/group/user 為一個群組刪除用戶無刪除信息

群組信息管理主要是在移動端實現，移動端當前登錄用戶可以對群組信息進行操作以及在群組中添加通訊錄中別的用戶，進而完成應急指揮系統的群聊功能, 如圖5-19所示。

O巡檢人員GHC磁陰

廠、：

圖5-19移動端群組信息管理界面圖

通過postman對群組信息管理相關的接口進行測試，結果顯示所有接口都可以完成其對應的功能；在移動端進行群組信息的相關操作也可以完成對應的功能, 從而證明群組信息管理模塊可以為應急指揮模塊提供群組信息管理功能支撐。

5.2智憊管廊信息管理支撐系統性能分析

在分析系統的性能之前首先需要測試系統的性能。智慧管廊信息管理支撐系統主要包括穩定性、安全性、復用性和可擴展性四個性能，其中安全性和復用性與功能模塊相關，可擴展性與架構設計相關，這三種性能己在5.1節中完成測試，故本節主要測試系統的穩定性。

穩定性的測試主要是測試在高并發的情況下的系統性能，主要包括平均響應時間、吞吐量和錯誤率這三個指標。本文采用Jmeter作為測試工具，通過對用戶信息管理模塊的查詢所有用戶信息的接口進行并發測試,逐漸增加并發線程數來獲取平均響應時間、吞吐量和錯誤率這三個指標。Jmeter可以通過文本表格或者圖形展示的方式生成平均響應時間、吞吐量和錯誤率等指標di,方便進行數據統計分析。

本文通過曲線圖的方式直觀地展示平均響應時間、吞吐量和錯誤率這三個指標與并發線程數的對應關系，如圖5-20、圖5-21與圖5-22所示。

圖5-20并發線程數-平均響應時間對應關系圖

(sw)Mrs三=>•£,

并發線程數-吞吐量關系圖

圖5-21并發線程數-吞吐量對應關系圖

并發線程數-錯誤率關系圖

圖5-22并發線程數-錯誤率對應關系圖

由圖5-20可知，隨著并發線程數的增加平均響應時間在不斷增加；由圖5-21 可知，隨著并發線程數的增加吞吐量先增加后減少，在并發線程數為2000的時候達到峰值；由圖5-22可知，隨著并發線程數的增加錯誤率開始為0%,當并發線程數為2000的時候錯誤率開始增加。

通過對穩定性的測試結果進行分析可以發現，隨著請求數的逐漸增大，平均響應時間呈指數增長，表示系統越來越不穩定；當并發線程數低于2000的時候錯誤率一直為0%,且吞吐量在并發線程數為2000時達到峰值，此時的平均響應時間為965ms,表明系統在Is內可以穩定的處理2000個請求同時到達，與一般信息管理系統Is內只能穩定的處理600個請求〔33〕相比，智慧管廊信息管理支撐系統具有更好的穩定性。因此智慧管廊信息管理支撐系統的穩定性性能良好。

安全性的測試主要是在5.1.2、5」.3和5.1.4節中。在5.1.2節中可以看到，只有當用戶輸入正確的用戶名和密碼才能夠進入系統，進而進行其權限范圍內的相應操作，否則無法進入系統；在5.1.3節中可以看到，用戶在操作系統時只能執行其權限范圍內的操作，否則將會被攔截；在5.1.4節中可以看到，用戶執行數據操作時只會獲取其權限范圍內的數據，其余數據則無法獲取，保證系統不會發生數據泄露。通過對安全性的測試結果進行分析可以發現，系統的安全性滿足系統設計的預期設想，因此智慧管廊信息管理支撐系統的安全性性能良好。

復用性的測試主要是在5.1.3、5.1.4和5.1.6節中。在5.1.3節和5.1.4節中可以看到，系統可以根據實際需求給不同的功能和數據添加權限，也可以進行權限的變更，從而實現了權限的復用；在5」.6節中可以看到，用戶信息管理模塊即可以為PC端也可以為移動端提供功能支撐，從而實現了相同功能的復用。通過對復用性的測試結果進行分析可以發現，系統的復用性滿足系統設計的預期設想, 因此智慧管廊信息管理支撐系統的復用性性能良好。

可擴展性的測試主要是在5.1節中接口的設計以及系統整體架構的設計。通過統一的規范設計接口，接口的命名形式形如api/vl/user/...,可以在接口調用時體現岀良好的適配性；在架構設計方面，本文設計的智慧管廊信息管理支撐系統基于Spring Boot作為后臺框架，通過注解@CrossOrigion來解決跨域問題，使得系統的前后端分離開發得以實現。同時本系統架構設計分為橫向設計和縱向設計兩個方面，在橫向按照功能進行模塊化劃分，各個模塊獨立開發、互相調用；在縱向按照前端請求在后端執行順序進行層次化劃分，各層次獨立開發、相互調用，這樣的分層設計方案極大的減少了系統的耦合性。最后在功能上也體現了系統的可擴展性需求，智慧管廊信息管理支撐系統基于RBAC模型設計了角色樹，將用戶-角色-權限分離，降低了系統的耦合性。通過以上分析可以發現，系統的可擴展性滿足系統設計的預期設想，因此智慧管廊信息管理支撐系統的可擴展性性能良好。

5.3本章小結

本章對智慧管廊信息管理支撐系統進行了功能測試、性能測試以及性能分析。功能測試結果表明智慧管廊信息管理支撐系統基本實現了預期的功能效果，能夠為系統業務模塊提供良好的功能支撐;性能測試結果表明智慧管廊信息管理支撐系統在高并發情況下仍然能穩定運行，通過性能分析可以得出系統具有良好的穩定性、安全性、復用性以及可擴展性，能夠達到系統預期的設計目標。

第六章總結與展望

6.1總結

本文通過調研和查閱資料，對當今國內外智慧管廊和信息管理系統的發展現狀進行歸納總結，分析總結了目前信息管理系統的特點和不足，結合智慧管廊的特點，提出了基于RBAC的智慧管廊信息管理系統的設計與實現方案。

本文對基于RBAC的智慧管廊信息管理系統的功能需求進行分析，結合當前主流的微服務思想提出了將整個系統按照功能模塊劃分進行模塊間獨立開發、每個獨立模塊再按照層次化進行開發的系統架構設計方案。其中功能模塊包括用戶模塊、鑒權模塊和審批模塊;每個獨立模塊的開發層次從上至下依次為控制層、業務邏輯層、數據訪問層和數據存儲層。利用Spring Boot框架、MyBatis和MySQL 以及攔截器技術，在IDEA和maven工具下進行開發，利用GitHub進行版本控制，實現了系統的各個功能模塊的需求,為其余業務模塊提供了相應的功能支撐。

微服務的思想使得整個系統不再像以前一樣需要整體開發，而是根據功能需求將整個系統劃分為多個獨立的功能模塊，各個模塊獨立開發，相互調用，為智慧管廊業務模塊提供功能支撐，整體上降低了系統的耦合性，提升了系統性能；而層次化的設計將系統的實現在縱向層次上進行分離，底層提高基礎的數據支撐, 上層可以調用下層的方法來實現功能，最后在頂層通過暴露API接口的方式供前端和移動端調用來實現對應的功能。

本文的主要工作總結如下：

(1)闡述了當今物聯網技術高速發展時代的信息管理系統的發展現狀，對信息管理系統的權限設計和管理功能的不足進行研究。結合智慧管廊與web開發技術，分析出通過攔截器加上數據庫動態字段來實現操作權限和數據權限的設計方案，提出一種基于RBAC的智慧管廊信息管理系統的設計與實現方案。

(2)歸納總結了系統開發中需要用到的技術與工具，主要包括RBAC模型、 Spring Boot框架、MySQL數據庫、MyBatis、攔截器技術，以及主要的開發工具 IDEAo分析了各種技術的優缺點和應用場景，結合智慧管廊系統，闡述了各種技術在系統中的具體應用。

(3)分析了智慧管廊信息管理支撐系統的系統用例、功能需求和性能需求，給出了系統總體架構設計方案。系統架構按功能模塊主要分為用戶模塊、鑒權模塊和審批模塊；按開發層次主要分為控制層、業務邏輯層、數據訪問層和數據控制層。由于鑒權模塊為本文核心模塊且其不同的類別對應不同的層次，故為了設計方便，本文主要按照功能模塊給出其設計與實現方案：

a.用戶模塊：角色樹、用戶信息管理模塊和群組信息管理模塊的實現包括系統的四個層次，為智慧管廊業務模塊提供了良好的用戶管理功能支撐。

b.權限模塊：分為登錄模塊、操作模塊和數據模塊。登錄模塊基于shiro框架和OAuth2進行開發，主要在控制層實現；操作權限基于攔截器實現，主要在控制層實現，通過聲明控制層可操作的角色集合來判斷當前用戶角色是否可以執行該層對應的操作進而實現權限的控制；數據權限主要在數據訪問層實現，通過對dao層進行聲明，去判斷訪問數據庫表是是否涉及動態字段，通過動態的拆分 SQL來實現不同權限用戶對不同數據和字段的訪問，從而實現數據鑒權功能。鑒權模塊為智慧管廊系統業務模塊提供了良好的鑒權功能支撐。

c.審批模塊的實現包括系統的四個層次，通過各層的邏輯調用修改字段state 的值來實現審批操作，再配合操作權限和數據權限，可以為巡檢維護模塊提供良好的審批功能支撐。

基于RBAC的智慧管廊信息管理系統的設計與實現是一個完整的工程項目，從開始制定開發框架與技術、分析系統的需求、分析系統的功能以及功能的實現方案都需要負責不同模塊的開發人員制定統一的開發規范，例如數據庫表的命名以及Spring Boot的版本等問題，然后在實際開發過程要按照規范進行。同時使用GitHub進行版本控制，使得多人協同開發得以實現。正是在這種規范的統一開發規范下才使得本文能夠順利的完成。

6.2展望

基于RBAC的智慧管廊信息管理系統在總體架構上基于微服務的思想進行設計，將系統劃分成不同的功能模塊獨立開發，互相調用來為智慧管廊業務模塊提供功能支撐。由于系統功能模塊依賴于通用物聯網云平臺部分PaaS層的基礎功能模塊和通用功能模塊，因此需要通過配置URL去調用其他模塊來實現相應的功能。同時系統在模塊調用時使用的是HTTP協議，需要將對應模塊的URL 寫死，這樣一旦別的模塊URL發生改變則需要修改配置，在性能上耦合性較高，故后期考慮基于dubbo和zookeeper來實現微服務核心的RPC （遠程過程調用）調用來降低耦合，提升系統性能，這也是日后系統更新迭代的主要工作點之一。

鑒權模塊使用了攔截器和MyBatis技術來實現。攔截器技術可以通過對用戶身份鑒別再進行攔截來實現權限判定，但是只是實現了其簡單的方法，對于更復雜的方法還沒有涉及。數據權限使用MyBatis攔截器來實現，但是主要是在SQL 拆分前進行攔截，雖然可以實現數據鑒權的功能，但是僅僅適用于數據量不大的情況，對于海量數據的情況還需對重組之后的SQL進行攔截過濾，來獲取對系統有效的數據，這些還需要將MyBatis攔截器進行深入的研究，然后在開發中應用起來才能使系統適應這種海量數據的情況。

技術總是在更新迭代，我們始終要抱著探索學習的心態來面對層出不窮的新技術，萬變不離其宗，對于新技術不只是會運用，還要掌握其底層的實現原理，這樣在未來的工作中才能適應不斷更新的技術棧。同時也要多去接觸新的領域，作為開發人員，了解大數據分析和深度學習的相關內容也是有必要的，不但能拓展知識面而且能夠提升自己的學習能力，進而去適應未來技術迭代的浪潮。

口]何遙.物聯網和智慧城市[J].中國公共安全，2018(07): 72-76.

[2]孫其博，劉杰，黎磬,et al.物聯網：概念、架構與關鍵技術研究綜述[J].北京郵電

大學學報，2010, 33(3).

[3]曹茂春，張東霞.智慧管廊信息化建設探討[J].智能建筑與智慧城市，2016(11):

76-80.

[4]孫倩.淺談計算機管理信息系統得發展及其經濟效益[J].科技資訊，2018, 36(012):

1672-3791.

[5]劉彤.基于微服務架構平臺在OA系統中的設計與實現[J].民航管理，201& (07),

73-76.

[6]黃牧.基于RBAC模型的權限管理系統設計[D].長春：吉林大學，2013.

[7]喬艷青.基于RBAC模型的權限管理子系統的設計和實現[D].長春：吉林大學，2013.

[8]Kan Ji. Design and Implementation of Teaching Quality Evaluation System Based on SpringBoot[C].西南石油大學(Southwest Petroleum University).第七屆計算與信息科學國際學術會議論文集.西南石油大學(Southwest Petroleum University):西南石油大學計算機科學學院，2019: 444-452.

[9]榮艷冬.關于Mybatis持久層框架的應用研究[J].信息安全技術，2015,(12):86-88.

[10]江榮波.MyBatis3源碼深度解析[M].北京：清華大學出版社，2019.

[11]Baron Schwartz, Peter Zaitsev, Vadim Tkachenko 著，寧海元，周振興，彭立勛等譯.高性能MySQL (第3版)[M].北京：電子工業出版社，2013.

[12]葉志鵬，何成萬，張崢峰.基于AOP的Web應用程序的安全會話管理[J].武漢工程大學學報，2018, (05): 565-56&

[13]史永樂.基于Java過濾器實現的系統權限控制方法研究[J].信息技術與信息化，2019, (09): 212-214.

[14]周奇才，王奕童，趙炯，熊肖磊.基于RBAC模型的細粒度權限管理系統的設計與實現[J].網絡安全技術與應用，2019,(10):38-41.

[15]何瑞娟.RBAC在企業管理信息系統中的應用[J].中國管理信息化.2017, (17), 72-74.

[16]劉潤澤.圖片管理系統后臺設計與實現[D].北京：北京郵電大學，2017.

[17]龔登偉.基于微服務架構的旅行社門店系統的設計與實現[D].北京：北京郵電大學， 2019.

[18]何修宇.微服務環境下訪問控制技術的研究與應用[D].北京：北京郵電大學，201&

[19]楊陽.基于角色的訪問控制改進模型研究與應用[D].西安：西安科技大學，2014.

[20]施剛.基于RBAC的統一權限管理系統分析與設計[J].產業與科技論壇.2017,(06), 49-50.