posts - 286,&
comments - 1539,&
trackbacks - 0
&&& 在前两篇文章中，不少朋友对我的设计提出了异议，认为过于复杂，当然在实际的各种系统的权限管理模块中，并不像这里设计得那么复杂，我以前所做的系统中，由只有用户和权限的，有只有用户、权限和角色的，还有一个系统用到了用户、权限、角色、组概念，这个系统是我在思考以前所做系统的权限管理部分中找到的一些共性而想到的一个设计方案，当然还会有不少设计不到位的地方，在设计开发过程中会慢慢改进，这个系统权当学习只用，各位朋友的好的建议我都会考虑到设计中，感谢各位朋友的支持。
&&& 今天抽时间整了一份概念设计出来，还有一些地方尚未考虑清楚，贴出1.0版，希望各位朋友提出宝贵建议。
&&& 大家也可以点击此处自行下载，这是1.0版本，有些地方可能还会进行部分修改，有兴趣的朋友请关注我的blog。
1.1 编写目的
本文档对通用权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统安全数据进行了说明。
a、&软件系统的名称：通用权限管理系统；
b、&任务提出者、开发者：谢星星；
c、&在J2EE的web系统中需要使用权限管理的系统。
本系统：通用权限管理系统；
SSH：英文全称是Secure Shell。
1.4 预期读者与阅读建议
总体设计、接口设计、数据结构设计、界面总体设计、系统出错处理设计
总体设计、接口设计、数据结构设计、系统安全设计
1.5 参考资料
《通用权限管理系统需求规格说明书》
《通用权限管理系统数据库设计说明书》
2.总体设计
2.1 设计目标
权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。
本系统的设计目标是对应用系统的所有资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。
2.2 运行环境
操作系统：Windows系统操作系统和Linux系列操作系统。
2.3 网络结构
&通用权限管理系统可采用Java Swing实现，可以在桌面应用和Web应用系统中进行调用。如果需要要适应所有开发语言，可以将其API发布到WEB Service上。暂时用Java Swing实现。
2.4 总体设计思路和处理流程
在说明总体设计思路前，我们先说明本系统的相关概念：
1. 权限资源
系统的所有权限信息。权限具有上下级关系，是一个树状的结构。下面来看一个例子
&&&&&&& 用户管理
&&&&&&& &&&&&& 查看用户
&&&&&&&&&&&&&&&新增用户
&&&&&&&&&&&&&&&修改用户
&&&&&&&&&&&&&&&删除用户
对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例如对于“查看用户”这个权限，如果用户只被授予“可访问”，那么他就不能将他所具有的这个权限分配给其他人。
应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。
为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系，可以形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。
为了更好地管理用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际情况中，我们知道，组也可以具有自己的角色信息、权限信息。这让我想到我们的QQ用户群，一个群可以有多个用户，一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ群也可以具有自己的角色信息，例如普通群、高级群等。
针对如上提出的四种对象，我们可以整理得出它们之间的关系图，如下所示：
总体设计思路是将系统分为组权限管理、角色权限管理、用户权限管理、组织管理和操作日志管理五部分。
其中组权限管理包括包含用户、所属角色、组权限资源和组总权限资源四部分，某个组的权限信息可用公式表示：组权限 = 所属角色的权限合集 + 组自身的权限。
角色权限管理包括包含用户、包含组和角色权限三部分，某个角色的权限的计算公式为：角色权限 = 角色自身权限。
用户权限管理包括所属角色、所属组、用户权限、用户总权限资源和组织管理五部分。某个用户总的权限信息存在如下计算公式：用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。
组织管理即对用户所属的组织进行管理，组织以树形结构展示，组织管理具有组织的增、删、改、查功能。
操作日志管理用于管理本系统的操作日志。
注意：因为组和角色都具有上下级关系，所以下级的组或角色的权限只能在自己的直属上级的权限中选择，下级的组或者角色的总的权限都不能大于直属上级的总权限。
2.5 模块结构设计
本系统的具有的功能模块结构如下图所示：
2.6 尚未解决的问题
3.接口设计（暂略）
3.1 用户接口（暂略）
3.2 外部接口（暂略）
3.3 内部接口（暂略）
4.界面总体设计
本节将阐述用户界面的实现，在此之前对页面元素做如下约定：
未选中时：[按钮名称]
选中时：[按钮名称]
&[选项,…,] ▽
&|________|
&|…………|
未选中时：选项名称
&选中时：选项名称
未选中链接
4.1 组权限管理
4.1.1包含用户
&&&&&& 组11
&&&&&& 组12
&&&&&& 组…
&&&&&& 组21
&&&&&& 组22
&&&&&& 组…
所选择组：组1
[包含用户] [所属角色] [组权限] [总权限]
用户名&& 姓名&&&& 手机号&& 最近登录时间&登录次数
阿蜜果&谢星星&&&&& 66
sterning xxx&&& &&&& 10&
……
当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该组所包含的用户。
4.1.2所属角色
&&&&&& 组11
&&&&&& 组12
&&&&&& 组…
&&&&&& 组21
&&&&&& 组22
&&&&&& 组…
所选择组：组1
[包含用户] [所属角色] [组权限] [总权限]
角色ID&& 角色名称&& 角色描述
1&&&&&&&&& 访客&&&&&& --
&& 2&&&&&&&& 初级用户&&& --
当用户选择“修改”按钮时，弹出角色树形结构，操作人可以通过勾选或取消勾选来修改该组所属的角色。
4.1.3组权限
&&&&&& 组11
&&&&&& 组12
&&&&&& 组…
&&&&&& 组21
&&&&&& 组22
&&&&&& 组…
所选择组：组1
[包含用户] [所属角色] [组权限] [总权限]
&&&&&&&&&&&&&&& [保存] [取消]
4.1.4总权限
&&&&&& 组11
&&&&&& 组12
&&&&&& 组…
&&&&&& 组21
&&&&&& 组22
&&&&&& 组…
所选择组：组1
[包含用户] [所属角色] [组权限] [总权限]
&&&&&&&&&&&&&&& [保存] [取消]
通过对已具有的权限取消勾选，或为某权限添加勾选，来修改组的权限信息，点击“保存”按钮保存修改信息。
4.1.5组管理
&&&&&& 在下图中，选中组1的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成在该组下添加子组，删除该组以及修改该组的功能。
&&&&&& 组11
&&&&&& 组12
&&&&&& 组…
&&&&&& 组21
&&&&&& 组22
&&&&&& 组…
所选择组：组1
[包含用户] [所属角色] [组权限] [总权限]
用户名&& 姓名&&&& 手机号&& 最近登录时间&登录次数
阿蜜果&谢星星&&&&& 66
sterning xxx&&& &&&& 10&
……
4.2 角色权限管理
4.2.1包含用户
&&&&&& 角色11
&&&&&& 角色12
&&&&&& 角色…
&&&&&& 角色21
&&&&&& 角色22
&&&&&& 角色…
所选择角色：角色1
[包含用户] [包含组] [角色权限]
用户名&& 姓名&&&& 手机号&& 最近登录时间&登录次数
阿蜜果&谢星星&&&&& 66
sterning xxx&&& &&&& 10&
……
当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该角色所包含的用户。
4.2.2包含组
&&&&&& 角色11
&&&&&& 角色12
&&&&&& 角色…
&&&&&& 角色21
&&&&&& 角色22
&&&&&& 角色…
所选择角色：角色1
[包含用户] [包含组] [角色权限]
组ID&& 组名称&&&& 组描述
1&&&&&&xxx1&&&&&&&--
2 &&&&&&xxx2&&& &&&&--&
……
当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该角色所包含的组。
4.2.3角色权限
&&&&&& 角色11
&&&&&& 角色12
&&&&&& 角色…
&&&&&& 角色21
&&&&&& 角色22
&&&&&& 角色…
所选择角色：角色1
[包含用户] [包含组] [角色权限]
&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&[保存] [取消]
通过对已具有的权限取消勾选，或为某权限添加勾选，来修改角色的权限信息，点击“保存”按钮保存修改信息。
4.2.4管理角色
&&&&&& 在下图中，选中组1的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成在该组下添加子组，删除该组以及修改该组的功能。
&&&&&& 角色11
&&&&&& 角色12
&&&&&& 角色…
&&&&&& 角色21
&&&&&& 角色22
&&&&&& 角色…
所选择角色：角色1
[包含用户] [包含组] [角色权限]
用户名&& 姓名&&&& 手机号&& 最近登录时间&登录次数
阿蜜果&谢星星&&&&& 66
sterning xxx&&& &&&& 10&
……
4.3 用户权限管理
4.3.1所属角色
用户权限信息
&& 广州分公司
&&&&&& 阿蜜果
&&&&&& 肖xx
&&&&&& yy…
&& 北京分公司
&&&&&& zz1
&&&&&& zz2
&&&&&& zz3…
所选择用户：阿蜜果
[所属角色] [所属组] [用户权限] [总权限]
角色ID&& 角色名称&& 角色描述
1&&&&&&&&& 访客&&&&&& --
&& 2&&&&&&&& 初级用户&&& --
当用户选择“修改”按钮时，弹出角色树形结构，操作人可以通过勾选或取消勾选来修改该用户所属的角色。
4.3.2所属组
&& 广州分公司
&&&&&& 阿蜜果
&&&&&& 肖xx
&&&&&& yy…
&& 北京分公司
&&&&&& zz1
&&&&&& zz2
&&&&&& zz3…
所选择用户：阿蜜果
[所属角色] [所属组] [用户权限] [总权限]
组ID&& 组名称&&&& 组描述
1&&&&&& 组1&&&&&&&& --
&& 2&&&&&& 组2&&&&&&&& --
当用户选择“修改”按钮时，弹出组的树形结构，操作人可以通过勾选或取消勾选来修改该用户所属的组。
4.3.3用户权限
&& 广州分公司
&&&&&& 阿蜜果
&&&&&& 肖xx
&&&&&& yy…
&& 北京分公司
&&&&&& zz1
&&&&&& zz2
&&&&&& zz3…
所选择用户：阿蜜果
[所属角色] [所属组] [用户权限] [总权限]
&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&[保存] [取消]
通过对已具有的权限取消勾选，或为某权限添加勾选，来修改用户的权限信息，点击“保存”按钮保存修改信息。
4.3.4总权限
&& 广州分公司
&&&&&& 阿蜜果
&&&&&& 肖xx
&&&&&& yy…
&& 北京分公司
&&&&&& zz1
&&&&&& zz2
&&&&&& zz3…
所选择用户：阿蜜果
[所属角色] [所属组] [用户权限] [总权限]
&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&[保存] [取消]
通过对已具有的权限取消勾选，或为某权限添加勾选，来修改用户的权限信息，点击“保存”按钮保存修改信息。
4.3.5用户管理
&&&&&& 当选择了某用户时，点击右键，弹出菜单列表：修改、删除、取消，点击修改和删除按钮可以实现用户的删除和修改功能。
&&&&&& 选择某个组织，例如下表中的“广州分公司”，弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消，点击添加用户按钮可以实现用户的添加功能。
用户权限信息
&& 广州分公司
&&&&&& 阿蜜果
&&&&&& 肖xx
&&&&& &yy…
&& 北京分公司
&&&&&& zz1
&&&&&& zz2
&&&&&& zz3…
所选择用户：阿蜜果
[所属角色] [所属组] [用户权限] [总权限]
角色ID&& 角色名称&& 角色描述
1&&&&&&&&& 访客&&&&&& --
&& 2&&&&&&&& 初级用户&&& --
4.3.6组织管理
&&&&&& 选择某个组织，例如下表中的“广州分公司”，弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消，点击添加子组织、删除组织、修改组织按钮可以实现组织的添加、删除和修改功能。
用户权限信息
&& 广州分公司
&&&&&& 阿蜜果
&&&&&& 肖xx
&&&&&& yy…
&& 北京分公司
&&&&&& zz1
&&&&&& zz2
&&&&&& zz3…
所选择用户：阿蜜果
[所属角色] [所属组] [用户权限] [总权限]
角色ID&& 角色名称&& 角色描述
1&&&&&&&&& 访客&&&&&& --
&& 2&&&&&&&& 初级用户&&& --
4.4 操作日志管理
4.4.1查询操作日志
操作名称：|________| &操作人：|________|
操作时间从&|________| 到 |________|&[查询] [重置] [删除]
编号&& &操作名称&& &操作内容&& &操作人&& &操作时间
1&&&&&&& xx1&&&&&& &&--&&&&&&& Amigo&& &
2&&&&&&& xx2&&& &&&&&--&&&&&&& xxyy&& &&
输入上图表单中的查询信息后，点击“查询”按钮，可查询出符合条件的信息。
4.4.2删除操作日志
操作名称：|________|&操作人：|________|
操作时间从&|________| 到 |________|&[查询] [重置] [删除]
编号&& &操作名称&&& 操作内容&&& 操作人&&& 操作时间
1&&&&&&& xx1&&&&&& --&&&&&&&&&& Amigo&&&&&
2&&&&&&& xx2&&&&&& --&&&&&&&&&& xxyy&&&&&&
输入上图表单中的查询信息后，点击“查询”按钮，可查询出符合条件的信息。而后点击“删除”按钮，可删除符合查询条件的操作日志。
5.数据结构设计
数据库设计的模型请参见《通用权限管理系统_数据库模型.pdm》。表的说明请参见《通用权限管理系统数据库设计说明书》。
5.1 设计原则
5.1.1命名的规范
数据库中表、主键、外键、索引的命名都以统一的规则，采用大小写敏感的形式，各种对象命名长度不要超过30个字符，这样便于应用系统适应不同的数据库平台。
5.1.2数据的一致性和完整性
为了保证数据库的一致性和完整性，往往通过表间关联的方式来尽可能的降低数据的冗余。表间关联是一种强制性措施，建立后，对父表（Parent Table）和子表(Child Table)的插入、更新、删除操作均要占用系统的开销。如果数据冗余低，数据的完整性容易得到保证，但增加了表间连接查询的操作，为了提高系统的响应时间，合理的数据冗余也是必要的。使用规则（Rule）和约束（Check）来防止系统操作人员误输入造成数据的错误是设计人员的另一种常用手段，但是，不必要的规则和约束也会占用系统的不必要开销，需要注意的是，约束对数据的有效性验证要比规则快。所有这些，需要在设计阶段应根据系统操作的类型、频度加以均衡考虑。
5.2 数据库环境说明
数据库：MySql5.0
设计库建模工具：PowerDesigner12.0
5.3 数据库命名规则
表名以T开头，外键以FK开头，索引以INDEX开头。
5.4 逻辑结构
pdm文件的名称为：《通用权限管理系统_数据库模型》。
5.5 物理存储
通过数据库建模工具PowerDesigner12可以将pdm导出为文本文件，将数据库脚本放入文本文件中保存。
5.6 数据备份和恢复
数据库需定期备份（每天备份一次），备份文件格式为backup_yyyyMMdd，数据库被破坏时，利用最新的备份文件进行恢复。
6.系统出错处理设计
6.1 出错信息
子项及其编码
6.2 补救措施
为了当某些故障发生时，对系统进行及时的补救，提供如下补救措施：
a．后备技术&& 定期对数据库信息进行备份（每天一次），当数据库因某种原因被破坏时，以最新的数据库脚本进行恢复；。
7.系统安全设计
7.1 数据传输安全性设计
SSH可以通过将联机的封包加密的技术进行资料的传递; 使用SSH可以把传输的所有数据进行加密，即使有人截获到数据也无法得到有用的信息。同时数据经过压缩，大大地加快了传输的速度。通过SSH的使用，可以确保资料传输比较安全并且传输效率较高。
7.2 应用系统安全性设计
操作人的操作信息需要提供操作记录。对系统的异常信息需进行记录，已备以后查看。只有授权用户才能登录系统，对于某个操作，需要具有相应权限才能进行操作。
7.3 数据存储安全性设计&&&&&&&&&&&
对于用户的密码等敏感信息采用MD5进行加密。
阅读(42709)
&re: 通用权限管理系统设计篇（三）——概要设计说明书
lzmm快25岁了，我也快25岁了，并且属于同一行业，但成就远不如lzmm，就拿你做为学习的榜样吧！&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
你太厉害了啊! 真是可惜了这么好的一个MM啊!&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
真是太厉害了，佩服佩服啊&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
文档还是挺不错的
收藏做模版，谢谢lz了&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
学习了，支持！&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
非常的清晰，佩服，正在朝这个方面努力！&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
虽然还有很多地方需要改进，但思路非常清晰，表达得很清楚。好妹妹!&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
实在是太有才了。。。。佩服佩服。。。惭愧惭愧。。。&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
楼主是不是好象少考滤了一样东西：资源&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
支持！！&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
标准的设计文档模板，希望能够继续深化下去。我将关注中&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
真是一位才女,最近也在为权限设计,关注中....&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
难道博主是在中航信工作？&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
@ quietywind
没有啊&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
哦 看文档里面截图的例子都是航班订座或售票相关的东西，还以为是中航信的呢 :)&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
@ quietywind
是在网上弄的一个图片来冒充的，哈哈&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
设计的很多不合理,虽然体现了RABC的设计精神,但太过于死板,很明显的可以看出,组和角色是重复的,应该再进行细划,区别出组和角色,比如组只能包含角色,而不涉及具体的权限分配,从这点上可以说组就是角色权限组.还有实际的管理系统中人员是属于哪个部门的,并没有在权限系统中体现,可能可以说部门可以用角色来模拟,显然,角色是个抽象的东西,他适用于系统所有的文件,把他归结为某个部门显然是违背设计的初衷的,就说这么多了。&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
补充一点:既然是基于角色的权限管理系统,那么用户实际上是归于某个具有某个权限的角色后才具有某个权限,所以,用户没有自己的权限.故 &应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n个组。&叙述的不合理,&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
@恺撒之吻
针对“还有实际的管理系统中人员是属于哪个部门的,并没有在权限系统中体现”这个问题，请看下我上篇的数据库设计，是由组织这个表的，在这篇文章中也有提及，请仔细看看。
对于组和角色的问题，我觉得可以参考QQ，它的普通群、高级群可以与这里的角色相对应，每一个群可以对应于我们这里的组的概念，在此处看来，组当然会有他们自己的权限。&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
@恺撒之吻
我并没有说这是基于角色的权限管理系统,如果是的话，设计大可以简化。&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
@阿蜜果
对于QQ群,我想他是一种部门,具体的群是个具体部门，具体部门也有部门的组和角色,比如管理员和普通用户而并不是你说的那个角色的概念.&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
@阿蜜果
所以通用的权限系统是依附于部门,通过角色来访问.&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
你那個總權限又是做什麼用的&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
MM,你好棒哦&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
你的设计很不错，我想提一个问题，你的组与角色有没有什么隶属关系．看了你的设计后我没有感到他们有什么联系，只存在简单的Ｎ～Ｎ的关系，对于你的这种设计我只能理解出是互包含，不知你在设计时是如何考虑他们的业务联系的？看到你的数据库设计时，我理解你最终要做的是用户与功能点的对应关系．不知这么理解对不对，你所引入的角色和组都是用来管理功能点的一种附助手段&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
我现在的设计时组可以包含多个角色，而一个角色可以属于多个组，所以这两者之间是N~N的关系。
引用：看到你的数据库设计时，我理解你最终要做的是用户与功能点的对应关系．不知这么理解对不对，你所引入的角色和组都是用来管理功能点的一种附助手段
恩，你所理解的就是我所想的。其实到最后还是用户与功能点的对应关系&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
to 阿蜜果
还没完成coding吗？我每天来看的哦～ 期待你开放code～&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
@jimmy lin
我都没开始coding啊
晕
给个设计思路就差不多了啊
最近需要忙的私事太多了&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
@阿蜜果
UI控制上我不清楚怎么控制好呢？
比如一个user他能编辑页面上的一部份form项，但是其它的不能由他来填写。这个一般要怎么控制呢？不能在view上看到这些硬code吧。&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
@jimmy lin
恩，这个是不太好处理的，你可以将它做成一个自定义标签，我现在是这样做的，不过还是觉得不够好&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
@阿蜜果
然后在这个自定义标签上接受权限规约来定义这个标签的状态？
这样的话，感觉上这个标签就不通用了。对吗？&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
怎么会不通用呢，你只是传入一个登录名进去的，还好吧，不过总觉得不是很好的方法，不知道其他人有无好办法&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
对应权限的判断逻辑是怎么样的呢？会不会很复杂？另外对于一个组信息里面的总权限不明白是干嘛用的？&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
很佩服您，您的通用权限管理系统的设计思想也让我学到了很多，在这里我也想和您提一下我的一点不成熟的想法，我觉得还可以做的更抽象些，在一个实际的系统管理中，组可以看成是对资源的纵向拆分，而角色可以看成是对资源的横向拆分，举个例子，一个公司由很多个部门组成，这里的部门就可以看成是“组”的概念，是纵向的拆分，而这个公司又是由管理员和普通员工组成，是“角色”的概念，是横向的拆分。这样是不是可以把“角色”和“组”这两个概念和在一起，再抽象一下，就是让用户自己去设计他想在系统中对资源怎样拆分，用户可以给他想要添加的拆分方法起一个名字叫“角色”，也可以叫”组“，也可以叫”部门“，或者别的什么，这样在数据库里需要用的一个总的方法表来记录用户添加的拆分方法，然后还要一个记录详细信息的表（就是把您设计的角色表和组表和起来），根据不同的分法，可以到这个详细信息表里取出相对于这种分法的记录集合，然后再像您介绍的那样继续设计下去。这样如何拆分，按”角色“，”部门“，”组“，”职位“，或者别的，完全由用户自己设计。当然，这只是我个人的一点想法，仅供参考。我现在也在权管理这块的开发，看了你的文章，确实学到很多，再次感谢您&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
我现在在做一个系统，一个类似信息发布的东东，本来也无所谓，可没想到用户提出了许多BT的要求，尤其是权限方面，本来照我的常规思维，这种东东一般也就是划分几个角色，划分几个信息的发布模块等等也就行了，甚至公司都有现成的东西直接用。
可没想到客户的要求比较刁钻。我先说说系统的大概模样。
信息发布吗，首先当然要划分信息的类别和层次，而这层次是不定的，可能是两三层，也可能是十层、八层（没这么变态吧^_^），其实就类似与windows的资源管理器的样式，目录里面含着文件，而文件又有可能和目录平级的说，这是显示方面大概要显示的东东。现在说说他们在权限控制方面的要求，某个用户登录系统之后，这些目录文件（使用的是资源管理器类似的样式，左边一颗树，右边基本信息列表）将需要根据用户权限的不同而不同（有的目录文件显示，有的不显示的说），当然对于不同的记录用户也需要有不同的增删改权限，列表虽然都能看见，不过有的记录他可以修改却不可以删除，有的却连修改都不许了，当然还有其他的一下操作方式的控制。更为变态的是，要求点击某条记录（或目录、或文件）时弹出的信息查看页面对于不同权限的用户也需不同，即某些字段可以显示，某些字段不能显示（my god，还是把我回收了得了），这就要求在后台的管理方面有着灵活的操作，当然用户也要求了，本着易用性的原则，管理员可以适当选择是对一条条记录赋权还是对一批记录赋权。
说了这么多，不知道你能否看明白？
我开始的想法是定义组，将某些权限相同的用户赋为一组，然后对记录赋权时根据组进行选择而不用对每个人进行选择，这样就不需对个人进行操作（即使一个人也给他搞个组），这样对组配置改组可以对记录有那些权限，可以显示记录的那些字段，然后针对记录选择组（一个用户可能属于多个组，如有重复，则以用户能获得的最大权限为主）。
不过后来一想，加入某些记录只是针对个人的，如果也这么做的话，会死人的啊，组的数量就太多了。
&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
如果用单位来对应权限，然后让用户、角色、组来对应单位中的权限，这种实现会不会更简单一些&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
看着这个头痛，我干了好几个月的这个东西，Amigo你可以试着兼容LDAP。那就跟我差不多一样痛苦了。唉&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
基于用户、用户组、角色都可以进行资源授权这一事实，是否可以考虑抽象出一个授权单位的虚拟对象，而用户、用户组、角色，都是这个虚拟对象的具体实现。这样，楼主的授权模型就得以简化，变成：虚拟授权对象--权限
虚拟授权对象之间的包含关系
。
当然，由于用户、用户组、角色本来还具有自己的特殊属性，这三个实体数据表时不能省略的，但是，对象之间的关系表变得简单了，代码也相应简化。同时，由于“一切都等同于角色”这样的概念，系统将具有更好的可扩展性，比如，将来增加一个用户级别或职务之类的概念，就可以同用户组之类的概念等同处理，因为用户级别或职务也可以看作角色（授权对象）。&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
感觉比较不错，伸缩性很强，灵活性很好
可以随时抽调一个主表，比如：组
就可以用来实现基于角色的权限
确实可通用&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
楼主，接下来还有继续吗？！！&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
本人菜鸟一个,有个很菜的问题请教.做这个权限管理模块,用户界面用JAVA实现,数据存储那些必须放在数据库里面吗?如果用户没有安装任何数据库怎么办呢?&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
学习呀,真是高!!
希望有时间多向你学习!!!&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
图上的访问与管理如果遇到细致化分如何处理？&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
俺虽然不是做JAVA的，现在正在头痛做这个问题。
谢谢，你这个给了我一定的启发。你这个权限管理的思路很好，可是不够细，不一定能满足客户的要求。
比如我现在这个项目的权限要求要做到单元格一级的控制。&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
@jimmy lin
可以将要显示的项存储在数据库啊，在库中规定具有特定权限的用户才可以对其进行相应的操作&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
妹妹 你有男朋友了吗？我想追你&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
用户权限管理还真是一大头疼问题，几乎每个系统都或多或少改一些，有没有更妙的处理方式？&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
不错
借鉴下
不过偶用.net来实现。。。&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
@AI3
my god&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
不错，不错，确实在菜单管理这样的权限设计比较通用了，但是似乎妹妹只贴出了菜单管理的权限，没有资源管理的权限，呵呵&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
天下掉下来你这个MM!
还让人活吗？同样是同行阿.......&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
不错好多！&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
看了你的东东，我都不想学java了，啥子能达到你的境界呢？？&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
我想你真是个好人,写得很好,对我很有有帮助.还提供文档下载,非常感谢.&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
楼主真厉害，我正在搞人事权限管理系统，毕业设计！可无从下手！楼主加我QQ指教指教&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
lzmm，你好，请问说明书里面的带多个复选框的目录树怎么实现的？&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
一直在找权限设计的资料，非常感谢博主的分享 ^^&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
楼主大才，但怎么没写第四篇？呜呜&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
不对啊，下载下来是三星手机使用说明啊&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
@恺撒之吻
部门就是组，组就是部门。这样理解可以吧。otherpart给对于外来访客使用。
&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
如果我是公司的老板后者高管，我可能会提出给一个人增加一个权限，如果照很多朋友的看法，那就得新建一个角色了，完全没必要。设计时要从使用人的视角来看问题，规范的设计固然好，但会给操作带来麻烦；灵活的东西固然负责，可以把它当成基础设计，至于组是否应该直接具备权限，可以看成业务逻辑。所以在最基础之上的东西可以智者见智，不必拘泥于一种形式，但最基础的东西就应该简单灵活，它的使用时有一定门槛的，否则就会用的一塌糊涂。楼主的设计不错。&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
其实不用这么纠结，这是一个通用的东西，在具体业务实现是，用户可以直接对权限，角色也可以直接对权限，用不用可以由实现业务的人自己选择。就是说，这里提供了多种方法，具体业务逻辑采用哪种或哪几种，是实现具体业务逻辑的人需要决定的。&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书[未登录]
要是粘贴的 就艹尼玛 各种一样的&&&&&&
&re: 通用权限管理系统设计篇（三）——概要设计说明书
2007年10月
3012345710111314151618192021222526272829303112345678910
&&&&&&生活将我们磨圆，是为了让我们滚得更远——“圆”来如此。&&&&& 我的作品：&&&&&&&&&&&&&&&（2012年1月出版）&&&&&&&&&&（2010年5月出版）&&&&&
留言簿(233)
积分与排名
阅读排行榜
评论排行榜