目錄：
1．權(quán)限管理問題的分析
1.1權(quán)限管理簡要分析
1.2電子政務(wù)系統(tǒng)的權(quán)限管理
1.3商業(yè)化應(yīng)用系統(tǒng)的權(quán)限管理
1.4他山之石
2．權(quán)限管理子系統(tǒng)設(shè)計
2.1權(quán)限管理子系統(tǒng)的總體目標(biāo)
2.2權(quán)限管理子系統(tǒng)的對象模型
2.3注意與不足
3．權(quán)限管理子系統(tǒng)的實現(xiàn)
3.1面向?qū)ο蟮膶崿F(xiàn)
3.2組件層與功能層對對象的包裝
3.3整合到具體業(yè)務(wù)系統(tǒng)

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

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

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

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

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

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

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

3. 權(quán)限管理子系統(tǒng)的實現(xiàn)
3.1 面向?qū)ο蟮膶崿F(xiàn)
在團隊推進的多業(yè)務(wù)集成項目中，我們嘗試使用以上的對象模型，但處于成本的考慮，我們將以上對象模型作了適當(dāng)簡化，取消了User對ACL的直接關(guān)聯(lián)，統(tǒng)一使用Group歸組User。
在此基礎(chǔ)上，我們進行了數(shù)據(jù)建模，用以實現(xiàn)權(quán)限管理的具體功能。在完成建模后，團隊還利用面向?qū)ο蟮姆椒ǎ瑢υ撟酉到y(tǒng)進行概要設(shè)計和代碼設(shè)計。（請參考《“XXXX（注：屏蔽商業(yè)敏感字符）”平臺權(quán)限管理子系統(tǒng)概要設(shè)計》），實現(xiàn)是，我們引入了ACLManager和GroupManager管理類，將該子系統(tǒng)所有的數(shù)據(jù)庫操作封裝在這兩個類中，并將權(quán)限管理子系統(tǒng)所有功能以這兩個類的方法的形式發(fā)布。
該部分具體是實現(xiàn)，如建模細(xì)節(jié)、代碼設(shè)計，可以《“XXXX（注：屏蔽商業(yè)敏感字符）”平臺權(quán)限管理子系統(tǒng)概要設(shè)計》和測試工程DataCS中查閱。

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

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