【正文】 用戶組（ Group）：表示能夠訪問同一批數(shù)據的一組用 戶的集合，例如： A 公司用戶組，表示屬于該組的用戶都能夠訪問 A 公司的所有數(shù)據； A1 小區(qū)用戶組，表示屬于該組的用戶都能訪問 A1 小區(qū)的所有數(shù)據。 角色（ Role）： 是物業(yè)公司中特定的一種工作職責或者是職位，如：公司管理員、會計等。為此，本課題根據實際的我業(yè)務需求，對 RBAC 基本模型進行擴展，設計了符合物業(yè)管理系統(tǒng)需求的權限管理模型 —— RBAC 擴展模型，圖 37 顯示了 RBAC 擴展模型： U s e r R o l e P e r m i s s i o nU A P AG r o u pG AS e s s i o nU s e r _ S e s s i o n S e s s i o n _ R o l eS e s s i o n _ G r o u pM o d u l eM AR e s o u r c eR A 圖 37 RBAC 擴展模型 比較 RBAC 基本模型和 RBAC 擴展模型，我們可以看到 在 RBAC 擴展模型中 增加了三個對象集合和三對關系，他們分別是：用戶 組（ Group）、模塊（ Module）、資源（ Resource）和用戶 用戶組分配（ GA）、角色模塊分配（ MA）、權限資源分配（ RA） 。 RBAC 基本模型優(yōu)勢在于解決 對象（資源）層面上的權限管理，即執(zhí)行者能否操作某個對象，能夠對其進行何種操作。如果 要求 RBAC 基本模型實現(xiàn)上述控制，將會導致權限集合的擴散，使得用戶能夠訪問權限范圍之外的數(shù)據。例如：在物業(yè)管理系統(tǒng)中，公司管理員可以查看該公司管理的所有小區(qū)的業(yè)主信息、繳費信息等，但是小區(qū)管理員只能查看自己小區(qū)的信息。最終，是用戶執(zhí)行權限，角色作為中介使得用戶執(zhí)行權限。一個用戶可以是多個角色的成員，一個角色也可以擁有多個用戶；同樣的，一個角色可以擁有多個權限，同一個權限也可以分配給多個角色。 1996 年， Sandhu 發(fā)布了 RBAC96 的 RBAC 基本 模型 [2]，圖 36 顯示了 RBAC的基本模型。在這種權限模式下，用戶的角色轉換變得很容易實現(xiàn)。浙江工業(yè)大學本科畢業(yè)設計說明書（論文） 10 第 三 章 物業(yè)管理系統(tǒng)安全平臺構建 RBAC 基本模型 1992 年， Ferraiolo 等人提出了基于角色的訪問控制模型 [1]。 公司公司編號公司名稱公司法人公司執(zhí)照公司電話公司地址注冊時間注冊資金公司描述是否啟用...intvarchar(50)varchar(50)varchar(50)varchar(50)varchar(200)datetimeintvarchar(200)bitpk小區(qū)小區(qū)編號小區(qū)名稱公司編號所在地區(qū)所在街道詳細地址交付時間小區(qū)規(guī)模小區(qū)類型小區(qū)描述是否啟用...intvarchar(50)intvarchar(50)varchar(50)varchar(200)datetimeintvarchar(50)varchar(200)bitpkfk樓宇樓宇編號樓號小區(qū)編號樓宇類型層數(shù)跳過層數(shù)單元數(shù)單元標識每層戶數(shù)樓宇描述是否啟用...intintintvarchar(50)intvarchar(50)intvarchar(50)intvarchar(200)bitpkfk房屋房屋編號樓宇編號房號房屋面積是否入住描述...intintvarchar(50)floatbitvarchar(200)pkfk業(yè)主業(yè)主編號房號業(yè)主姓名房屋面積手機號碼性別名族籍貫生日婚否工作單位個人愛好證件類型證件編號家庭電話領房時間裝修時間入住時間車位號車牌號車型號儲藏室使用狀況其他地址緊急聯(lián)系人緊急電話描述...intvarchar(50)intfloatvarchar(50)varchar(50)varchar(50)varchar(50)datetimebitvarchar(100)varchar(100)varchar(50)varchar(50)varchar(50)datetimedatetimedatetimevarchar(50)varchar(50)varchar(50)varchar(50)varchar(50)varchar(200)varchar(50)varchar(50)varchar(200)pk家庭成員成員編號業(yè)主編號成員姓名關系證件編號聯(lián)系電話...intintvarchar(50)varchar(50)varchar(50)varchar(50)pkfk房屋業(yè)主編號房屋編號業(yè)主編號Intintintpkfk1fk2物業(yè)費項目編號小區(qū)編號項目名稱繳費年份繳費月份創(chuàng)建時間創(chuàng)建人員...intintvarchar(100)intintdatetimevarchar(50)pkfk物業(yè)費編號項目編號房屋編號業(yè)主編號繳費年份繳費月份繳費日期應收金額實收金額收費人員錄入人員錄入時間審核時間審核人員狀態(tài)備注...intintintintintintdatetimefloatfloatvarchar(50)varchar(50)datetimedatetimevarchar(50)varchar(50)textpkfk1fk3fk2短信賬號編號賬號名稱上行地址下行地址用戶名密碼擴展碼公司編號...intvarchar(50)varchar(200)varchar(200)varchar(50)varchar(50)intintpkfk歷史短信編號短信賬號接收人狀態(tài)短信類別發(fā)送時間發(fā)送人短信內容...intinttextvarchar(0)intdatetimevarchar(50)varchar(200)pkfk 圖 25 物業(yè)管理系統(tǒng)業(yè)務功能模塊數(shù)據庫關系圖 基于角色的訪問控制系統(tǒng)相關的數(shù)據庫表設計在第四章中詳細描述。 各個實體對象之間的關系均為一對多關系，包括：公司— 小區(qū)、公司 — 短信賬號、小區(qū) — 樓宇、樓宇 — 房產、業(yè)主 — 房產、業(yè)主 — 家庭浙江工業(yè)大學本科畢業(yè)設計說明書（論文） 9 成員、小區(qū) — 物業(yè)費項目、物業(yè)費項目 — 物業(yè)費、業(yè)主 — 物業(yè)費。同時本系統(tǒng)還采用了 Spring的子項目，包括 Spring JMS、 Spring Security 等組件。 Spring 框架是一個分層架構，由 7 個定義良好的模塊組成。 本系統(tǒng)的采用 Hibernate 框架實現(xiàn)數(shù)據的持久化操作，不過在批量數(shù)據處理時考慮到執(zhí)行效率以及內存占用等因素，采用了直接調用 JDBC 接口來實現(xiàn)，同時浙江工業(yè)大學本科畢業(yè)設計說明書（論文） 8 也在數(shù)據系統(tǒng)中創(chuàng)建存儲過程和觸發(fā)器以提高數(shù)據存儲的效率。 (5) 物業(yè)繳費管理模塊：物業(yè)繳費主要是指物業(yè)費的收繳， 本模塊主要實現(xiàn)物業(yè)費繳費的流程， 以及物業(yè)費信息的查看和檢索。 (3) 物業(yè)項目管理模塊：物業(yè)項目是指物業(yè)公司所管理的住宅小區(qū)或寫字樓等，具體又包括了小區(qū)的基本信息管理、樓宇信息管理和房屋信息管理。 舟山市物業(yè)管理系統(tǒng)物 業(yè) 公 司 管 理 模 塊信 息 機 賬 號 管 理 模 塊物 業(yè) 項 目 管 理 模 塊業(yè) 主 信 息 管 理 模 塊物 業(yè) 繳 費 管 理 模 塊小 區(qū) 信 息 管 理樓 宇 信 息 管 理房 屋 信 息 管 理物 業(yè) 費 創(chuàng) 建物 業(yè) 費 錄 入物 業(yè) 費 審 核 圖 23 物業(yè)管理系統(tǒng)業(yè)務功能需求 結構圖 (1) 物業(yè)公司管理模塊：該模塊主要是管理物業(yè)公司的基本信息。為了滿足物業(yè)公司的日常管理工作需求，本系統(tǒng)必須支持以下功能模塊：公司信息管理模塊、物業(yè)項目管理模塊、業(yè)主信息管理模浙江工業(yè)大學本科畢業(yè)設計說明書（論文） 7 塊、物業(yè)繳費管理模塊。 另外通過在業(yè)務流中（如物業(yè)繳 費管理）引入短信提醒功能，及時提醒業(yè)主當前繳費信息，能夠有效提高業(yè)主對公司服務的滿意度。 短信平臺 需求 傳統(tǒng)的物業(yè)管理方式中，物業(yè)公司與業(yè)主之間的溝通只能通過張貼公告或逐戶上門通知，這樣不僅消息傳遞速度慢、耗費人力資源大，而且傳遞的效果也不佳。 系統(tǒng)日志需求 為了保證系統(tǒng)數(shù)據的安全，我們需要跟蹤用戶的一些關鍵操作，如對數(shù)據的增刪改等操作。 同一層次的用戶，擁有的功能模塊又有所不同，如公司管理員可以管理業(yè)主信息，卻不能創(chuàng)建物業(yè)費信息，而公司財務卻可以創(chuàng)建和審核物業(yè)費，但是卻不能編輯業(yè)主信息。 系 統(tǒng) 管 理 員系 統(tǒng) 初 始 化系 統(tǒng) 配 置用 戶 管 理 u s e s u s e s u s e s 移 動 公 司 管 理 員物 業(yè) 公 司 信 息 管 理O p e n M A S 賬 號 管 理 u s e s u s e s 物 業(yè) 公 司 管 理 員物 業(yè) 信 息 管 理 u s e s 業(yè) 主 信 息 管 理短 信 平 臺 管 理物 業(yè) 費 查 看 u s e s u s e s u s e s u s e s 物 業(yè) 小 區(qū) 管 理 員物 業(yè) 信 息 查 看業(yè) 主 信 息 查 看物 業(yè) 費 錄 入 u s e s u s e s u s e s u s e s u s e s 物 業(yè) 公 司 財 務 人 員 u s e s 物 業(yè) 費 創(chuàng) 建物 業(yè) 費 審 核 u s e s u s e s u s e s 圖 22 系統(tǒng)整體用例圖 浙江工業(yè)大學本科畢業(yè)設計說明書（論文） 6 系統(tǒng)安全 需求 通過上述用戶 概述，我們了解到本系統(tǒng)的用戶類型非常多，并且用戶又分為不同的層次， 按權限 從高到低 可以分成 系統(tǒng)級 用戶、 公司級 用戶和 小區(qū)級 用戶 。不用類型的用戶登錄系統(tǒng)后所擁有的功能模塊不同，相同類型的用戶根據所在公司或小區(qū)不同，能夠訪問的數(shù)據也不同。 (5) 系統(tǒng)管理員：負責系統(tǒng)的初始化配置，包括系統(tǒng)的權限設置、功能模塊配置、初始用戶創(chuàng)建等。 (3) 物業(yè)公司財務人員：負責物業(yè)費繳費信息的創(chuàng)建和維護、繳費審核 。 五個基本角色的基本職責描述如下： (1) 移動公司管理員：負責物業(yè)公司信息的創(chuàng)建和維護，信息機賬號的創(chuàng)建和維護。 用戶 概述 本系統(tǒng)的用戶包括以下五個基本類型 （角色） ：移動公司管理員、物業(yè)公司浙江工業(yè)大學本科畢業(yè)設計說明書（論文） 5 管理員、物業(yè)公司財務人員、小區(qū)管理 員 、系統(tǒng)管理員 。小區(qū)信息管理又包括了小區(qū)基本信息管理、樓宇信息管理、房屋信息管理等，物業(yè)費繳費信息管理又包括了物業(yè)費的創(chuàng)建和生成、物業(yè)費的錄入、物業(yè)費的審核等三個流程。 中 國 移 動 舟 山 分 公 司 A 物 業(yè) 公 司 B 物 業(yè) 公 司 A 1 小 區(qū) A 2 小 區(qū) B 1 小 區(qū) B 2 小 區(qū) 圖 21 組織結構圖 物業(yè)管理系統(tǒng)的使用主要是為了實現(xiàn)物業(yè)管理過程的信息化，滿足日益繁雜的業(yè)務需求 ，實現(xiàn)物業(yè)信息的有效存儲和傳遞，簡化日常操作，提高管理效率。 本章小結 本章簡要介紹 課題 的研究背景 與意義 、 以及 該課題的國內外研究現(xiàn)狀和主要研究內容， 最后 ， 給出了 本文的 主要研究內容 及本文的組織結構浙江工業(yè)大學本科畢業(yè)設計說明書（論文） 4 第 二 章 物業(yè)管理系統(tǒng)需求分析 系統(tǒng) 需求分析 需求 概述 本系統(tǒng)是由中國移動舟山分公 司發(fā)起并推廣的面向全市物業(yè)公司共享的一套物業(yè)管理信息系統(tǒng)， 所以本系統(tǒng)首先必須支持多公司、多小區(qū)的共同訪問，而不造成數(shù)據的越權和非法訪問 ，為此本系統(tǒng)需擁有一套完善的訪問控制機制，以確保用戶只能在權限范圍內進行的操作。 第 七 章：總結和展望。 第 六 章：物業(yè)管理系統(tǒng) 業(yè)務 功能實現(xiàn)。 第五 章：物業(yè)管理系統(tǒng)短信平臺構建。 第四 章：物業(yè)管理系統(tǒng)日志系統(tǒng)構建。 第三 章：物業(yè)管理系統(tǒng)安全平臺構建。 第 二 章：物業(yè)管理系統(tǒng)需求分析。 本文的 組織結構 本文共分為 七 個章節(jié) ： 第一章：緒論。 (6) 采用 ActiveMQ 消息服務器，構建物業(yè)管理系統(tǒng)的消息發(fā)送與接收機制，使得短