最近對就有系統人員許可權升級計劃――也談人員許可權的設計。

dunel發表於2004-04-16
前言：
人員、機構、角色、許可權物件間組織關係的重新抽象；

人員、機構、角色、許可權；
這四個經過抽象的物件原型經過事實證明還是比較成功的；

這幾個物件不會有大的變動；
但是實際中也碰到了問題，就是這些物件之間關係的不確定性；
下面描述以下四個物件新的關係結構；

1 核心思想：

1。人員在系統中總是扮演某種角色的；
例如：小張在屬於辦公廳這個部門，以前我們都傾向於認為辦公廳聚合了小張。
其實考察一下實際情況，辦公廳下面有個辦公廳人員這個角色，而小張只是扮演了這個角色而已；
考慮一下如果當小長被調動另外一個部門時候那種抽象更容易處理。

2。業務邏輯希望面對的是系統中的角色，而非扮演角色的具體的人。
例如：以工作流示例，一個公文的下一步流轉的物件是組織部部長，他不關心誰扮演這個部長，人員許可權模組知道就行了。

2 抽象關係描述：


.人員和機構之間的松耦合（透過角色耦合）

目的：改變糟糕地人員和機構之間的強聚合關係。




人員和部門透過角色進行耦合；

人員和部門的關係可以容易的變化，不會產生大的影響。

.人員和角色間變成強聚合關係；

目的：強調人員在系統中必須扮演角色，起碼扮演某個機構的人員這個角色；




人員的角色又可以同時扮演的，也有互相排斥的。

排斥的角色就是不能同時扮演的，登入以後可以選擇的角色；

由管理員規定人員的那些角色是相互排斥的；


.機構和許可權點之間沒有直接關係；

目的：讓機構的抽象更清晰化，機構和許可權的關係透過角色體現；


.機構和角色之間強聚合關係；

目的：明確部門的作用是行使某種特定職能的。



說明：

部門和部門之間還有從屬關係；

部門可以專門設定部門管理員用於管理下級的機構和人員，使分級管理在模型上成為可能；

部門擁有的角色有寫是系統規定的，如：部門人員，部門管理員；

部門可以自定義自己的角色，並由部門管理員管理；

.角色之間的繼承關係；
目的：更好的處理角色和許可權點之間的關係；



說明：

角色之間擁有繼承關係如上圖所示。

可以被繼承的角色是由系統管理員制定的，部門管理員不能制定；

3 總結：

經過考慮，我認為 人員、機構、角色、許可權 的關係應該做成可以改變的外掛，系統初始時候進行選擇不同組織方式；

也就是說，上文描述的 人員、機構、角色、許可權 的關係還有原有關係都做成的外掛，並不拋棄原有的人員許可權關係。

相關文章