高級軟件工程課程設計基于web的通用權限管理系統的設計與實現1 研究現狀權限管理技術的理論研究開始于20世紀60年代末70年代初，所權限管理，就是通過某種途徑顯示地準許或限制訪問能力及范圍，從而限制對關鍵資源的訪問，防止非法用戶的侵入或者合法用戶的不慎操作造成破壞。隨著計算機技術和應用的發展，特別是互聯網的發展，應用系統對于權限管理的需求開始迅速增加。在隨后40年的發展歷程中，人們在權限管理技術的研究方面取得了很大的成果，先后出現過多種權限管理訪問控制技術。20世紀80年代到90年代初，自主權限管理自主訪問控制技術、強制訪問控制技術得到了美國國防部制定的橘皮書-可信計算機評估準則的認證。但是，近幾年來，人們普遍感到DAC和MAC的權限管理技術無法滿足現今日趨復雜的應用系統的安全需求。因此，基于角色的權限管理(RBAC)，便成為人們研究訪問控制技術的重點和熱點。2 可行性研究可行性研究是對項目進行可行性調研和論證，確定項目開發的價值和意義以及是否可以付諸實施。其目的是在對比投入和產出的基礎上考慮利用目前的資源、成本等因素能否實現一個系統以及是否會創造價值或帶來實際的意義。可行性分析可行性分析一般可定義為web系統權限管理 標準翻譯，可行性分析是在建設的前期對工程項目的一種考察和鑒定，對擬議中的項目進行全面與綜合的技術、經濟能力的調查，判斷它是否可行。
2.1社會可行性分析通用權限管理系統的開發 符合國家法律 ，能夠與社會大系統實現良好的對接。2.2 技術可行性分析開發通用權限管理系統具備所需要的條件。開發通用權限管理系統使用的MS 2008系統開發工具。系列操作系統已經是普遍使用的系統，所以在技術上是成熟的。2.3經濟可行性分析開發通用權限管理系統只需普通配置的計算機，在開發經費上沒有問題。開發通用權限管理系統所投入的資金與系統投入使用后所帶來的經濟效益相比較，通用權限管理會給信息管理系統帶來一定的經濟效益。2.4管理可行性分析通用權限管理系統現行的管理體制具有現代化的管理意識和管理水平。在系統中，每個人都有自己的用戶名和密碼，因此在管理上可行。綜上所述，開發通用權限管理系統在目標上 、技術上 、經濟上 、管理上都是可行的。3 需求分析需求分析是軟件開發的重要階段。在需求分析階段我們可以理清思路、澄清概念，最終形成一個完整的、清晰的、一致的系統需求，來幫助我們更好的進行系統開發，實現系統功能，滿足用戶需求。3.1 面向對象的需求分析方法面向對象分析獲得系統功能需求的方法與傳統軟件工程過程中需求分析的不同。
其核心內容包括：劃分子系統、確定參與者（角色，可以是人也可以使其他子系統）并明確其關系、獲得參與者用例并明確用例之間的關系、繪制用例圖。用例圖即最終獲得的系統用例模型，該圖應當能夠將系統中所有的功能需求或者其中某一方面的功能需求表達出來，所有這些用例圖所表達的功能之和應該同用戶提出的功能相吻合。(1)劃分子系統一個復雜的系統往往通過功能劃分為若干小的模塊，稱為子系統。劃分子系統的目的是使復雜的問題簡單化。每個子系統還可以再劃分子系統，所有這些子系統都被看作是對象進行數據（字段和屬性）和操作（方法）的封裝。(2)確定參與者參與者是指與系統交互的人或其他程序，是所有用例的執行者。在UML中使用一個人形的圖標表示。需要注意的是參與者不是指人或其他程序本身，而是指它在系統中扮演的角色，比如小明是以系統管理員的身份登錄系統，參與者就是系統管理員。(3)獲取用例 從用戶的角度來看，一個用例（USE CASE）就是參與者完成的一項不可再分割功能，比如注冊到一個網站。UML對用例的標準定義如下：用例是對包括變量在內的一組動作序列的描述，系統執行這些動作，并產生傳遞特定參與者的價值的可觀察結果。用例之間的關系主要包括泛化、包含、擴展三種。
(4)繪制用例圖用例圖（USE CASE ）由參與者（Actor）、用例（USE CASE）、關系（）和系統邊界等元素組成。其中關系包括用例之間的關系、參與者之間的關系、參與者和用例之間的關系。參與者之間的關系主要是泛化，因為參與者也是參與到系統中的類。參與者和用例的關系就是簡單的關聯。3.2權限管理系統描述權限管理是一個軟件非常重要的組成部分。一個完善的信息管理系統，關系到很多部門。他們各盡其責，互相配合，互相制約。所以，我們的電腦軟件權限要細分，才能滿足用戶的需求。我們的系統采用兩級權限管理，先分用戶角色，每個角色分派一定權限，權限的功能可以大部門是控制到窗口級，部門窗口限制還達到按鈕級。然后每一個用戶可以扮演某一個角色或多個角色，從而構成了我們嚴密的權限分級系統。權限管理嚴密，安全性高，支持加密。安全權限可以細化到字段，真正實現了不同級別的人看不同的文件，實現一次登陸全網通行。下面就來介紹一下權限管理系統操作的具體情況。3.2.1 用戶操作(1) 根據自己的喜好，對用戶密碼進行改動，并存入數據庫。(2) 根據用戶需要，在自己的權限內對系統的數據庫進行查詢，獲得所需的數據。
(3) 根據用戶的角色代碼web系統權限管理 標準翻譯，使用戶在進入主界面的時候進入相應的部門操作。3.2.2 管理員操作(1) 根據企業的用人要求，給員工分配權限，把用戶的資料輸入數據庫中存儲起來。(2) 當用戶的職位發生改變的時候，及時更新用戶資料，再把新資料存檔。(3) 根據企業發展情況，對企業的權限、角色進行細分，可以進行相應的增。加、刪除與修改。3.3用例建模在確定了系統中的角色以后，進一步分析系統需求，按照角色不同得到系統用例。3.3.1系統參與者(1) 管理員：管理日志，增加、刪除、修改角色，增加、修改、刪除部門為用戶分配權限等等管理用戶操作。(2) 用戶：在管理員分配的權限內進行操作。3.3.2用例圖系統管理員的角色用例如下：(1)應用列表管理：添加應用列表。(2)應用模塊管理：新增應用模塊，并且給應用模塊分類。(3)用戶資料管理：新增用戶、用戶資料查詢和修改用戶資料。(4)部門資料管理：新增部門、排序子部門、修改部門資料和移除本門資料。(5)角色資料管理：新增角色、修改角色、給角色新增應用和給角色設置限。(6)應用字段設定：設置字段。(7)事件日志管理：日志查詢。(1)系統管理員的總用例圖如下：圖3.1系統管理員的總用例圖（2）管理員對角色管理用例圖圖3.2管理員對角色管理的用例圖(3) 管理員對部門管理用例圖圖3.3管理員對部門操作的用例圖(4) 管理員對用戶管理用例圖圖3.4管理員對用戶管理模塊操作用例圖用戶在權限管理系統中擁有管理員賦予的權限，能在自己權限內進行操作，因此用例圖與管理員的用例圖大同小異，在此就不用再畫出來了。
3.3.3 用例規約用例規約的內容如下所示。用例名稱：用來指定用例名稱。用例描述：用來簡單說明用例的作用。前置條件：在執行用例之前系統必須處于的狀態。事件流：系統完成用例執行所需要的所有操作。后置條件：在用例執行結束以后系統必須處于另一狀態。(1)修改密碼用例規約用例名稱：修改密碼。用例描述：用來修改管理員或者用戶登錄時的密碼。前置條件：管理員或者用戶在系統中。事件流:a管理員或者用戶進入個人設定。b輸入原始密碼驗證密碼是否正確，正確進入下一步否者修改密碼失敗。c輸入新密碼。d再次輸入新密碼。e驗證兩次密碼輸入一致否則修改密碼失敗。f提交到數據庫提示密碼修改完成。后置條件：密碼修改成功。(2) 用例名稱：設定權限用例規約。用例描述：管理員給用戶設定一定的權限使用戶在權限內能進行部分操作 前置條件：在系統內。 事件流： a管理員登錄系統進入角色管理頁。b打開一個角色，點擊修改角色權限。c修改角色權限然后點確定。d提交數據庫權限設定完成。后置條件：權限設置成功。(3) 用例名稱：新增用戶用例規約 。用例描述：新增加一個用戶。前置條件：在系統內。事件流：a管理員進登錄系統進入部門資料管理。
b打開新增用戶按鈕。c輸入用戶名和用戶密碼， 設定用戶類型。d 提交數據庫，新增用戶完成。后置條件： 新增用戶完成。 (4) 用例名稱：新增部門用例規約用例描述： 管理員新增一個部門。前置條件： 在系統內。 事件流： a管理員登錄系統進入部門資料管理。b點擊新增用戶按鈕。c輸入新增部門名稱。d提交數據庫新增不猛成功。后置條件：新增部門完成。 4總體設計完成系統的對象模型，包括系統的類圖（CLASS ）和對象圖的繪制。類圖表示不同實體如何彼此相關，它主要是顯示了系統的靜態結構。對象圖顯示一組對象和他們之間的關系。4.1概要設計類圖由許多靜態的說明性元素組成，它顯示出類、接口以及他們之間的靜態結構和關系。其最基本結構是類和接口，此外還有他們之間的關系，此外類圖還顯示其內部結構。4.1.1對象類型描述和類圖(1) 日志消息類該類主要是記錄用戶的登錄信息如 ID、用戶名、客服端IP、事件類型、應用名稱、模塊名稱和登錄時間。也可以查詢用戶的登錄信息。其中查詢的時候可也根據用戶ID、用戶名和登錄時間查詢；其中查詢時間可也是一個時間段。其類設計圖如下:圖4.1日志消息類圖(2) 邏輯類 該類的主要作用是執行增加、修改、刪除等操作，以及操作后的返回功能。
其中包括角色、權限、用戶的增加、修改和刪除。其設計圖如下、圖4.2邏輯類圖(3) 用戶在線類該類的主要作用是記錄用戶的登錄時間從而獲取在線用戶的列表，在用戶列表中插入新登錄用戶，并且更新用戶列表。檢查用戶是否在線。其類設計圖如下：圖4.3邏輯類圖(4) 檢查更新類 檢測是否有最新版本并返回最新版本。設計圖如下：圖4.4檢查更新類圖(5) 文本日志文件操作類 該類主要作用是記錄寫操作文件日志，以及判斷寫操作文件日志是成功還是失敗。記錄日志文件內容，獲取日志文件目錄。設計圖如下：圖4.5文本日志文件操作類圖(6) 系統信息操作類 對系統各種信息進行操作，設計圖如下：圖4.6系統信息操作類圖(7) 登陸類 該類主要作用是檢測用戶名和密碼是否正確，判斷正確用戶進入界面，錯誤提示用戶登錄失敗。設計圖如下：圖4.7登錄類圖(8) 權限檢測類該類的主要作用是檢測在線用戶緩存、應用啟動時間、版本等等。權限檢測成功后，用戶能在相應的權限內進行操作，設計圖如下：圖4.8權限檢測類圖4.1.2 類圖圖4.9類之間的關系圖4.2 詳細設計系統設計是信息系統開發過程中的另一個重要階段。
我們要根據之前進行分析的結果，在系統需求分析的基礎上，來進行對系統的設計4.2.1權限系統定義在一個系統中包含了企業正常運轉所需要的重要數據。一個企業中由于每個員工的不同，所允許接觸到的數據是不同的。如何使每個員工都能方便的訪問他在工作中所需要的數據，同時屏蔽不允許他們訪問的數據，這就需要對用戶進行訪問控制。訪問控制是根據需要批準或者禁止用戶訪問企業數據的過程。訪問控制的關鍵概念是權限。權限定義了授予或者禁止用戶對某部分數據的訪問類型。權限可以應用到任何受到保護的數據對象。設置權限，就是為用戶指定相應數據的訪問權限。4.2.2權限系統目標權限管理的方式有很多種，但是對于本系統而言，我們采用了如下描述的權限系統。首先，把權限系統分為角色、功能組、基本權限三層。其次，根據企業的需要，對所有可能的操作進行詳細劃分，確定所有的基本權限。最后，把相關的權限可以組成功能組，把幾個功能組組成一個角色。一個用戶可以充當幾個角色。通過這樣一個分層之后，整個權限管理系統可以靈活、有效的對用戶訪問系統數據進行控制，對用戶操作進行管理。權限管理系統的目標是實現以上所描述的權限管理。首先，根據對系統的分析，確定系統的所有基本權限。
然后在這個基礎上，給系統的權限系統管理員提供靈活的組織、安排功能組和角色以及給用戶分配相應的角色的功能。4.2.3權限系統子系統設計根據權限系統的定義和項目目標，權限管理系統的子系統有：功能組管理、角色管理以及用戶角色分配功能三大塊，同時還應該提供根據權限分配檢查特定用戶是否具有某項基本權限的接口，以及所有用戶都適用的密碼修改以及查詢功在線用戶管理和日志管理等等。系統管理模塊如圖4.10所示。圖4.10系統功能模塊通過上面的分析，我們在對權限管理系統的研究和開發中可以清楚的了解到在角色獲得的權限是功能權限則能實現系統功能；如果是實體權限，則選擇實體對象。同時某個用戶獲得了該角色，可以對實體對象進行具體權限操作，然后修改權限，刷新權限記錄，直至權限管理完成。具體權限實施流程如圖4.11所示。圖4.11 權限實施流程圖4.2.4登錄子系統登錄子系統是每個系統都應該具備的模塊，登錄界面是進入系統的前提。在本系統設置的登錄界面中，需要用戶輸入正確的用戶名和密碼。在系統中我使用了一個下拉框，里面載入了所有的用戶名。這樣的話在登錄的時候用戶可以在其中找出自己的用戶名或者是自己進行輸入。而當用戶名和輸入的密碼不符時，將出現對話框來提示用戶“密碼錯誤，請重新輸入”。
4.2.5用戶操作子系統在用戶操作子系統中，我主要設計了對系統信息的查詢功能和對系統信息的維護功能。在系統信息查詢方面，主要特點是支持對整體系統的查詢和具體的查詢。用戶可以根據自己的需要來對系統進行查詢。比如說，用戶可能會想要知道什么樣的角色會有怎么樣的權限，某個同事具體擁有什么樣的權限之類的，這樣的話就可以通過查詢操作來了解。在查詢模塊中，用戶根據自己想要了解的內容來對具體操作進行選擇。在對系統信息維護方面，主要是對用戶密碼的修改。由于用戶最初在使用系統的時候是由系統操作員統一的分配權限以及對用戶的信息進行初始化，即對密碼和權限的賦予。權限是不可以照著用戶的意念改變，但是密碼可以。用戶可以根據自己的喜好與習慣來對密碼進行設置，并替換原來的密碼存儲到用戶信息中。4.2.6操作員操作這個子系統是整個權限管理系統的核心模塊。權限管理系統的核心就是對用戶的權限進行管理，而具體實行權限管理的就是系統操作員。所以為了簡化對權限管理，我們把對權限系統的管理具體分為三個小模塊，分別是對用戶管理的模塊、對角色管理的模塊以及對權限組管理的模塊。由于企業是動態的，總是有人在內部不停的流動。他們可能是新進人員、可能是離職人員、可能升遷、可能降級，這些情況都是隨時可能發生的。
但是只要有人員的位置發生變動，那么他的相應資料就會隨之改變。這個時候系統操作員就可以根據人員位置的具體改變來選擇相應的模塊來對企業員工信息進行管理，并把員工的新資料存儲到數據庫中。4.3用例建模系統的類模型主要是反映了系統中各個類或接口之間的調用關系和類的內部結構。不同于靜態模型，系統的動態模型反映的是系統中各個對象之間的交互信息。系統的動態模型主要包括：時序圖、狀態圖、活動圖和協作圖四種圖形。4.3.1時序圖和協作圖簡介(1)時序圖（ ）可以用來顯示一個具體的用例或用例的一部分的詳細流程。其詳盡的顯示了不同對象之間的消息傳遞順序和調用關系。時序圖有兩個維度：水平維度是互相通信的對象，垂直維度代表時間。(2)協作圖（ ）與時序圖類似，用來表達對象之間的合作和交互，但與時序圖重點強調消息發送順序不同，協作圖重點突出的是上下文關系，其由Rose根據時序圖自動生成。4.3.2時序圖的繪制時序圖由角色、對象、生命線、激活期和消息五種元素組成。(1) 角色角色可以是外部參與者系統中其他程序。(2) 對象對象在時序圖中用矩形表示，在命名時可以使用對象名：類名的形式，也可以不帶類名。
如圖19中站點管理員就是一個對象(3) 生命線生命線是指對象的存在時期，在時序圖中表示為代表對象的方框下面的一條虛線，對象之間的消息在兩條生命線之間。如圖19中站點管理員和登錄頁面下的虛線就分別是這兩個對象的生命線。(4) 激活期激活期表示系統中對象執行某個操作的一段時間，在時序圖中以窄矩形表示。如圖下圖中的矩形框就是兩個對象的激活期。(5) 消息消息是各個對象之間進行通信的媒介，消息在時序圖中位于兩個對象的生命線之間，使用有向箭頭表示。如圖19中有向將頭就是一條消息。4.3.3 繪制時序圖和協作圖(1) 登錄功能時序圖 圖4.12登錄功能時序圖（2）登錄功能協作圖圖4.13登錄功能協作圖（3）部門資料管理時序圖圖4.14部門資料管理時序圖（4）部門資料管理協作圖圖4.15部門資料管理協作圖（5）角色管理時序圖圖4.16角色管理時序圖（6）角色管理協作圖圖4.17角色管理協作圖（7）權限設定時序圖圖4.18權限設定時序圖(8)權限設定協作圖圖4.19權限設定協作圖其他功能時序圖與角色管理時序圖大同小異，這里就不一一列舉了4.3.4 繪制活動圖(1)角色管理活動圖如下圖4.20角色管理活動圖（2）用戶資料管理活動圖圖4.21用戶資料管理活動圖4.4 數據庫邏輯結構設計概念結構設計是獨立于實際數據模型的信息結構,必須將其轉化為邏輯結構后才能進行數據庫應用的設計。
設計數據表的主要原則是符合3NF，3NF即所有的非鍵字段依賴而且僅僅依賴于主鍵，而與主鍵之外的字段無關。第一種轉化是將實體轉化為關系表。這種轉化比較簡單，只需要將實體的屬性定義為表的屬性即可。第二種轉化是聯系的轉化，即將各個實體之間的聯系轉化為表格之間的關系，如外鍵的定義。在上面工作的基礎上歸納出通用權限管理數據庫表格的組成、列的屬性、屬性之間的聯系等。該數據庫系統要求具有以下方面的特點：(1) 結構合理：對一個職員可以建立多條記錄。(2) 所建立的數據冗余度小，獨立性強。(3) 建檔、修改、查詢、統計快而準確。(4) 保密性、可靠性好。4.4.1系統權限表系統權限表描述了所有系統的基本功能。它其中的數據在實施階段就已經導入，并且系統中不給所有的用戶提供修改這個表中數據的功能。為了生成權限組表中的功能字符串，權限ID必須進行順序編號，具體設計結構如表4.22所示。字段名類型長度是否為空說明 null權限權限名稱表4.22系統權限表4.4.2權限組表權限組表保存了系統所有權限組。用戶定義的每個權限組在這個表中只有一條記錄，具體結構設計如表4.23所示字段名類型長度是否為空說明 null權限組權限組名稱表4.23權權限組表4.4.3角色表角色表保存了系統所有角色的信息，每一個角色在表中有且僅有一條記錄，并且具體的角色都是在一個相應的權限組中，具體結構設計如表4.24所示。
字段名類型長度是否為空說明 null角色角色名稱權限組ID表4.24角色表4.4.4角色權限表角色權限表保存了角色和權限之間的對應關系。每個角色包含的每一個權限在這個表中都存在一條相應的記錄，具體結構設計如表4.25所示。字段名類型長度是否為空說明 null表角色權限ID表4.25角色權限表4.4.5員工表員工表保存了企業所有員工的信息。員工表的主要維護工作應該是屬于人力資源管理系統。在權限管理系統中，對于員工表的維護主要就是對登錄名字和登錄密碼進行維護。對于每個企業人員來說，要使用ERP系統，必須首先在系統中注冊一個登錄名字以及設置登錄密碼，然后由系統操作員分配相應的權限，這些工作是在權限管理系統中實現的，具體結構設計如表4.26所示。字段名類型長度是否為空說明 null員工員工姓名登錄密碼所在角色ID表4.265 權限管理系統實現出于對系統安全的重視，現在人們將眼光更多的投向了權限管理系統，但是由于實現系統安全的方式是多樣的。
在實現權限管理系統的過程中，出于對系統信息安全的考慮，我們在權限管理系統的開發中還要對權限字符串進行加密設置。5.1權限管理系統實現的關鍵技術在當今我們都越來越注重在獲取對自己有用的信息的同時保護自己的信息不受損害，那么在一個大型的信息管理系統中這樣的要求是尤為重要的。一個大型的信息管理系統不僅要面臨著自己內部員工對它的操作，還面臨著其他用戶對它訪問。如何保證自己系統本身的信息不受損害是一個十分重要的問題。在這樣的環境下應用加密技術可以在一定程度上增大系統的安全性，它可以為我們進行一般的電子商務活動提供了安全保障。數據加密的基本過程，就是對原來為明文的文件或數據按某種算法進行處理，使其成為不可讀的一段代碼，通常稱為“密文”，使其只能在輸入相應的密鑰之后才能顯示出本來內容，通過這樣的途徑來達到保護數據不被非法人竊取、閱讀的目的。該過程的逆過程為解密，即將該編碼信息轉化為其原來數據的過程5.2權限管理系統實現過程在我們這個系統中主要是對權限字符串進行判斷。判斷權限字符串是否包含了某一權限以及完成對幾個權限字符串進行合并的操作，并在程序中提供這些函數供其他系統調用。同時為了系統的安全性，用戶密碼是以密文存儲在數據庫中的，其他系統也需要進行對用戶密碼是否正確進行判斷，所以也要有字符串加密和解密函數。
5.2.1判斷權限字符串是否包含某權限ID的方法判斷權限字符串的主要步驟是首先定位權限字符所對應的字符，然后判斷對應位置的取值。如下圖所示圖5.15.2.2將兩個權限字符串合并為一個的方法權限字符串合并的基本算法為：(1) 循環對兩個權限字符串的前n位進行合并，合并的方法是求得兩個字符的ASCII碼的或運算，直到一個字符串的結束。(2) 將長度較長的字符串的末尾部分附加到結果字符串末尾。5.2.3對字符串進行加密和解密的方法在本例中，對字符串進行加密和解密的算法改編自公司。加密算法的基本思想是利用預先給定的key與第一個字符進行異或運算，獲得第一個字符的密文；再利用得到的密文字符與預先給定的常量對key進行變換，然后再利用新得到的key對第二個字符進行加密，如此進行，直到所有明文加密結束，得到與明文長度相同的密文。由于在加密過程中，可能產生一些不可見字符，在將這些字符存入數據庫中容易導致異常，因此需要對算法得到的密文再次進行交換，即求得每個字符的ASCII編號的十六進制值轉換為字符串，這樣就得到了一個由0～9和A～F組成的長度為原來字符串的兩倍的密文。如下圖所示圖5.2解密算法是加密算法的逆運算。首先將由0～9和A～F組成的密文轉換為對應的ASCII碼的字符串；然后利用預先給定的key與第一個字符進行異或運算，獲得字符的明文；再利用密文、預先給定的常量對key進行變換，然后再利用新得到的key對第二個字符進行解密，如此進行，直到獲得所有的明文。如下圖所示