目錄：
1．權限管理問題的分析
1.1權限管理簡要分析
1.2電子政務系統的權限管理
1.3商業化應用系統的權限管理
1.4他山之石
2．權限管理子系統設計
2.1權限管理子系統的總體目標
2.2權限管理子系統的對象模型
2.3注意與不足
3．權限管理子系統的實現
3.1面向對象的實現
3.2組件層與功能層對對象的包裝
3.3整合到具體業務系統

1 ．權限管理問題的分析
1.1 權限管理簡要分析
任何多用戶的系統不可避免的涉及到權限問題，系統的使用者越多、使用者本身的社會屬性或分工越復雜，權限問題也就越復雜。無疑，無論是背負復雜辦公室政治關系的辦工系統、包含縱向行政關系的電子政務業務系統還是用于數據業務集成的應用集成系統，都不可避免的要解決這一問題。
我們的團隊正在推動的項目是一個典型的多業務集成系統。簡單的說，在這個系統中，有一個數據中心和若干具體的業務系統，各具體的業務系統在一定邏輯規則的指導下共享數據中心的數據；并且，各具體的業務系統之間也存在相互的數據和業務調用。在我們的系統構架設計中，數據中心和這些業務系統之間是一個中間層，該層容納對數據中心數據操作的功能接口和各業務相互調用的功能接口。
權限管理即要求實現對不同用戶對上述接口不同權限的訪問。

1.2 電子政務系統的權限管理
在與公司相關技術人員的討論中，了解到公司已有的辦公自動化或電子政務產品中的權限管理完全能夠滿足客戶的要求。而且，在這些系統中，設計者將權限分為功能權限和資源權限。分管用戶對系統功能項的訪問和用戶對系統所管理資源（如：公文、通知）的訪問。
在這些系統中的權限設計一般是在了解客戶需求、和分析服務對象的內部行政關系的基礎上，將系統的用戶分為若干等級，每個等級賦予對系統某些功能和資源的不同訪問權限。這種用戶級別往往是對服務對象行政關系的直接映射（如：科長、處長）。

1.3 商業化應用系統的權限管理
在IT世界里，從來都不缺少蘊涵完善權限管理的應用系統，甚至是操作系統。得益于來自Internet的資料，我們了解到這些較成熟的系統中的權限管理是通過ACL這一中間對象來實現的。
ACL，即Access Control List。中文譯名：訪問控制列。ACL發揮作用的原理如下：用戶、或用戶組通過數據庫中的訪問控制表得到其ACL（可以不止一個），該ACL具有一個權限――Privilege（如：只讀、讀寫等），同時該ACL指向某個訪問項，這個訪問項因所處的系統不同而不同。如：在操作系統中可能是某個文件夾，在關系數據庫管理系統中可能是一個數據庫，等等。實現中，用戶通過ACL訪問到某一具體訪問項，并受該ACL所附帶的權限――Privilege的限制。從而可以實現多用戶對多訪問項的多權限訪問。

1.4 他山之石
任何設計均服務于需求，由于團隊所推進的系統中服務于橫向聯系的多業務單位，1.2所述的傳統的方法建立的訪問級別在實現多維權限管理時顯得缺乏靈活性。所有，團隊決定利用成熟的商業化應用系統中的權限管理原理結合項目的需求來實現權限管理。也即，在我們的業務集成系統中，使用ACL管理和功能模塊管理來實現權限管理。下面進入技術主題：

2 ．權限管理子系統設計
2.1 權限管理子系統的總體目標
權限管理子系統實現系統的權限管理部分的功能。以用例（User Case）分析的方法，可以得出，系統的權限管理子系統滿足三種主要的功能。
A．獲取訪問項列表
依據預先為用戶配置好的權限設置，來獲取某用戶所能訪問的訪問項列表。
B．訪問可訪問項
用戶通過訪問項列表來訪問某一可訪問項時，權限管理子系統給予權限控制，如：許可、不許可、只讀等。
C．權限管理
設置用戶、用戶組與訪問項之間的訪問關系，也即我們熟悉的權限指派、配置等。同時，在這個設計中，使用“用戶組”來歸屬相同權限屬性的“用戶”。可見，用戶組是一種與權限管理直接相關的對象，所有，用戶、用戶組關聯管理也是權限管理子用例的一個重要組成部分。

2.2 權限管理子系統的對象模型
參考《權限管理對象模型(簡稿)》和《“XXXX（注：屏蔽商業敏感字符）”平臺權限管理子系統概要設計》，已經可以看出本次權限管理設計的對象模型的產生和實現。這里為了便于交流，作簡要描述。

對象模型解釋：（參考附錄的名詞解釋）
“Function”代表系統中的可訪問項，在實際應用中，可能是前述中間層的功能接口，也可能是某種業務資源，如已經生成的靜態報表。具體實現時可以標簽加以區別。
“ACL”代表訪問控制列，連接用戶、用戶組、Function并擁有Privilege屬性。
“Privilege”代表權限，如：禁止、只讀、讀寫、完全控制。
“User/Group”用戶，和具有相同訪問屬性的用戶容器――用戶組。之間存在多對多的關系。
“UserAccess/GroupAccess”訪問關聯，連接ACL和User/Group，并為其綁定權限――Privilege
實際實現是，還需實現以下邏輯：即當一個User屬性多個Group時，將通過編程的方法比對權限，使得該User獲得最大的權限。
現在我們可以回到1.2小節，看看本設計能否適應已有的電子政務系統的權限關聯需求。
1) 可以使用Function對象來作為電子政務系統的“功能項”和“資源項”的抽象，可以使用標簽來區別“功能項”和“資源項”；
2) 使用Group來模仿原有系統中的角色，使得原先用戶與系統內角色之間的直接映射變為了通過Group的所屬關系，并且可以為每個Group指定具體訪問項的不同權限――Privilege的訪問屬性，便于靈活處置。也可以為簡化系統，將每個Group的對應具體Function的訪問權限固定，以“角色”發布。
由此，團隊認定，現在的設計可以滿足普通電子政務系統的權限關聯要求。
2.3 注意與不足
該設計可以滿足權限管理較復雜時的功能需求，但面對簡單的業務系統顯得很多余。并且，實現時需多表組合，并伴隨大量管理模塊的編寫工作。并且，在系統實施階段，還需要對系統進行軟件配置操作。

3. 權限管理子系統的實現
3.1 面向對象的實現
在團隊推進的多業務集成項目中，我們嘗試使用以上的對象模型，但處于成本的考慮，我們將以上對象模型作了適當簡化，取消了User對ACL的直接關聯，統一使用Group歸組User。
在此基礎上，我們進行了數據建模，用以實現權限管理的具體功能。在完成建模后，團隊還利用面向對象的方法，對該子系統進行概要設計和代碼設計。（請參考《“XXXX（注：屏蔽商業敏感字符）”平臺權限管理子系統概要設計》），實現是，我們引入了ACLManager和GroupManager管理類，將該子系統所有的數據庫操作封裝在這兩個類中，并將權限管理子系統所有功能以這兩個類的方法的形式發布。
該部分具體是實現，如建模細節、代碼設計，可以《“XXXX（注：屏蔽商業敏感字符）”平臺權限管理子系統概要設計》和測試工程DataCS中查閱。

3.2 組件層與功能層對對象的包裝
團隊認定權限管理子系統的探索性設計應該到此為止。這樣的權限管理子系統在物質上只是若干文檔和幾個可以相互配合工作C#類和一個測試演示工程。我們的理由是，我們已經完成對象框架的建設，在未來的具體功能實現時（假設我們的類很完美）將根據具體項目系統的要求或條件，將這些類的方法實現以不同的方式發布。如：可以將ACLManager和GroupManager包裝為傳統程序可用的COM，或是更時髦的.NET程序集，甚至是Web Service。對于使用Java的團隊，我們會樂意他們在我們的文檔的幫助下用Java重新實現我們的類設計，并包裝為EJB，或Web Service。

3.3 整合到具體業務系統
可以看出，團隊在實現系統的權限管理子系統的路上，其實并未走完。本文作者是XP軟件方法（極限編程）的擁躉，相信“計劃不如變化”。故在具體到某個業務系統的權限管理實現時，還需要針對具體的需求、條件對該模型進行優化、改進甚至全部推倒！ <!--v:3.2-->