搜索 | 会员  
通用权限管理系统设计
来源: CIOZJ   作者:春山  日期:2014-10-16  类别:软件项目  主题:建模设计  编辑:春山
本文档对通用权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统安全数据进行了说明。

 

1.      引言

1.1 编写目的

本文档对通用权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统安全数据进行了说明。

1.2 背景

a、 软件系统的名称:通用权限管理系统;

b、 任务提出者、开发者:谢星星;

c、 在J2EE的web系统中需要使用权限管理的系统。

1.3 术语

本系统:通用权限管理系统;

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. 权限资源

系统的所有权限信息。权限具有上下级关系,是一个树状的结构。下面来看一个例子

系统管理

        用户管理

               查看用户

               新增用户

               修改用户

               删除用户

对于上面的每个权限,又存在两种情况,一个是只是可访问,另一种是可授权,例如对于“查看用户”这个权限,如果用户只被授予“可访问”,那么他就不能将他所具有的这个权限分配给其他人。

2. 用户

应用系统的具体操作者,用户可以自己拥有权限信息,可以归属于0~n个角色,可属于0~n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。

3. 角色

为了对许多拥有相似权限的用户进行分类管理,定义了角色的概念,例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系,可以形成树状视图,父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。

4.

为了更好地管理用户,对用户进行分组归类,简称为用户分组。组也具有上下级关系,可以形成树状视图。在实际情况中,我们知道,组也可以具有自己的角色信息、权限信息。这让我想到我们的QQ用户群,一个群可以有多个用户,一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ群也可以具有自己的角色信息,例如普通群、高级群等。

针对如上提出的四种对象,我们可以整理得出它们之间的关系图,如下所示:

 

总体设计思路是将系统分为组权限管理、角色权限管理、用户权限管理、组织管理和操作日志管理五部分。

其中组权限管理包括包含用户、所属角色、组权限资源和组总权限资源四部分,某个组的权限信息可用公式表示:组权限 = 所属角色的权限合集 + 组自身的权限。

角色权限管理包括包含用户、包含组和角色权限三部分,某个角色的权限的计算公式为:角色权限 = 角色自身权限。

用户权限管理包括所属角色、所属组、用户权限、用户总权限资源和组织管理五部分。某个用户总的权限信息存在如下计算公式:用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。

组织管理即对用户所属的组织进行管理,组织以树形结构展示,组织管理具有组织的增、删、改、查功能。

操作日志管理用于管理本系统的操作日志。

注意:因为组和角色都具有上下级关系,所以下级的组或角色的权限只能在自己的直属上级的权限中选择,下级的组或者角色的总的权限都不能大于直属上级的总权限。

2.5 模块结构设计

本系统的具有的功能模块结构如下图所示

 

 

2.6 尚未解决的问题

无。

3.      接口设计(暂略)

3.1 用户接口(暂略)

3.2 外部接口(暂略)

3.3 内部接口(暂略)

4.      界面总体设计

本节将阐述用户界面的实现,在此之前对页面元素做如下约定:

序号

页面元素

约定

1

按钮

未选中时:[按钮名称]

选中时:[按钮名称]

2

单选框

○ 选项

3

复选框

□ 选项

4

下拉框

 [选项,…,] ▽

5

文本框

 |________|

6

TextArea

 |…………|

7

页签

未选中时:选项名称

 选中时:选项名称

8

未选中链接

链接文字

9

选中链接

链接文字

10

说明信息

说明信息

 

4.1 组权限管理

4.1.1包含用户

组信息

   组1

       组11

       组12

       组…

   组2

       组21

       组22

       组…

 

所选择组:组1

[包含用户] [所属角色] [组权限] [总权限]

[修改]

用户名   姓名     手机号   最近登录时间 登录次数

阿蜜果 谢星星 13666666666 2007-10-8    66

sterning xxx    13555555555 2007-10-8    10 

……

当用户选择“修改”按钮时,弹出用户列表,操作人可以通过勾选或取消勾选来修改该组所包含的用户。

4.1.2所属角色

组信息

   组1

       组11

       组12

       组…

   组2

       组21

       组22

       组…

 

所选择组:组1

[包含用户] [所属角色] [组权限] [总权限]

[修改]

角色ID   角色名称   角色描述

1          访客       --

   2         初级用户    --

  

当用户选择“修改”按钮时,弹出角色树形结构,操作人可以通过勾选或取消勾选来修改该组所属的角色。

4.1.3组权限

 

 

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 出错信息

错误分类

子项及其编码

错误名称

错误代码

备注

数据库错误

连接

连接超时

100001001

 

连接断开

100001002

 

数据库本身错误代码

数据库本身错误代码

100002+数据库错误代码

 

TCP连接错误

连接

连接超时

101001001

 

连接断开

101001002

 

其它TCP连接错误(socket自身错误代码)

 

101002+ socket错误代码

 

配置信息错误

未配置输入参数

 

102001

 

未配置输出参数

 

102002

 

组管理部分自定义错误

 

 

103001——103999

 

角色管理部分自定义错误

 

 

104001——104999

 

用户管理部分自定义错误

 

 

105001——105999

 

操作日志管理

 

 

106001——106999

 

6.2 补救措施

为了当某些故障发生时,对系统进行及时的补救,提供如下补救措施:

a.后备技术   定期对数据库信息进行备份(每天一次),当数据库因某种原因被破坏时,以最新的数据库脚本进行恢复;。

7.      系统安全设计

7.1 数据传输安全性设计

SSH可以通过将联机的封包加密的技术进行资料的传递; 使用SSH可以把传输的所有数据进行加密,即使有人截获到数据也无法得到有用的信息。同时数据经过压缩,大大地加快了传输的速度。通过SSH的使用,可以确保资料传输比较安全并且传输效率较高。

7.2 应用系统安全性设计

操作人的操作信息需要提供操作记录。对系统的异常信息需进行记录,已备以后查看。只有授权用户才能登录系统,对于某个操作,需要具有相应权限才能进行操作。

7.3 数据存储安全性设计           

对于用户的密码等敏感信息采用MD5进行加密。

 

另一个文档

理清了对象关系之后,让我们接着来进行数据库的设计。在数据库建模时,对于N对N的 关系,一般需要加入一个关联表来表示关联的两者的关系。初步估计一下,本系统至少需要十张表,分别为:权限表、用户表、角色表、组表、用户权限关联表、用 户角色关联表、角色权限关联表、组权限关联表、组角色关联表、用户属组关联表。当然还可能引出一些相关的表。下面让我们在PowerDesigner中画出各表吧。

   各表及其关系如下:

 

 

  1.    用户表

  用户表(TUser)

  字段名称

  字段

  类型

  备注

  记录标识

  tu_id

  bigint

  pk, not null

  所属组织

  to_id

  bigint

  fk, not null

  登录帐号

  login_name

  varchar(64)

  not null

  用户密码

  password

  varchar(64)

  not null

  用户姓名

  vsername

  varchar(64)

  not null

  手机号

  mobile

  varchar(20)

 

  电子邮箱

  email

  varchar(64)

 

  创建时间

  gen_time

  datetime

  not null

  登录时间

  login_time

  datetime

 

  上次登录时间

  last_login_time

  datetime

 

  登录次数

  count

  bigint

  not null

  2.    角色表

  角色表(TRole)

  字段名称

  字段

  类型

  备注

  角色ID

  tr_id

  bigint

  pk, not null

  父级角色ID

  parent_tr_id

  bigint

  not null

  角色名称

  role_name

  varchar(64)

  not null

  创建时间

  gen_time

  datetime

  not null

  角色描述

  description

  varchar(200)

 

  3.    权限表

  权限表(TRight)

  字段名称

  字段

  类型

  备注

  权限ID

  tr_id

  bigint

  pk, not null

  父权限

  parent_tr_id

  bigint

  not null

  权限名称

  right_name

  varchar(64)

  not null

  权限描述

  description

  varchar(200)

 

  4.    组表

  组表(TGroup)

  字段名称

  字段

  类型

  备注

  组ID

  tg_id

  bigint

  pk, not null

  组名称

  group_name

  varchar(64)

  not null

  父组

  parent_tg_id

  bigint

  not null

  创建时间

  gen_time

  datetime

  not null

  组描述

  description

  varchar(200)

 

  5.    角色权限表

  角色权限表(TRoleRightRelation)

  字段名称

  字段

  类型

  备注

  记录标识

  trr_id

  bigint

  pk, not null

  角色

  Role_id

  bigint

  fk, not null

  权限

  right_id

  bigint

  fk, not null

  权限类型

  right_type

  int

  not null(0:可访问,1:可授权)

  6.    组权限表

  组权限表(TGroupRightRelation)

  字段名称

  字段

  类型

  备注

  记录标识

  tgr_id

  bigint

  pk, not null

  组

  tg_id

  bigint

  fk, not null

  权限

  tr_id

  bigint

  fk, not null

  权限类型

  right_type

  int

  not null(0:可访问,1:可授权)

  7.    组角色表

  组角色表(TGroupRoleRelation)

  字段名称

  字段

  类型

  备注

  记录标识

  tgr_id

  bigint

  pk, not null

  组

  tg_id

  bigint

  fk, not null

  角色

  tr_id

  bigint

  pk, not null

  8.    用户权限表

  用户权限表(TUserRightRelation)

  字段名称

  字段

  类型

  备注

  记录标识

  tur_id

  bigint

  pk, not null

  用户

  tu_id

  bigint

  fk, not null

  权限

  tr_id

  bigint

  fk, not null

  权限类型

  right_type

  int

  not null(0:可访问,1:可授权)

  9.    用户角色表

  用户角色表(TUserRoleRelation)

  字段名称

  字段

  类型

  备注

  记录标识

  tur_id

  bigint

  pk, not null

  用户

  tu_id

  bigint

  fk, not null

  角色

  tr_id

  bigint

  fk, not null

  10.  用户组表

  用户组表(TUserGroupRelation)

  字段名称

  字段

  类型

  备注

  记录标识

  tug_id

  bigint

  pk, not null

  用户

  tu_id

  bigint

  fk, not null

  组

  tg_id

  bigint

  fk, not null

  11.  组织表

  组织表(TOrganization)

  字段名称

  字段

  类型

  备注

  组织id

  to_id

  bigint

  pk, not null

  父组

  parent_to_id

  bigint

  not null

  组织名称

  org_name

  varchar(64)

  not null

  创建时间

  gen_time

  datetime

  not null

  组织描述

  description

  varchar(200)

 

  12.  操作日志表

  操作日志表(TLog)

  字段名称

  字段

  类型

  备注

  日志ID

  log_id

  bigint

  pk, not null

  操作类型

  op_type

  int

  not null

  操作内容

  content

  varchar(200)

  not null

  操作人

  tu_id

  bigint

  fk, not null

  操作时间

  gen_time

  datetime

  not null

 

德仔网尊重行业规范,每篇文章都注明有明确的作者和来源;德仔网的原创文章,请转载时务必注明文章作者和来源:德仔网;
头条那些事
大家在关注
广告那些事
我们的推荐
也许感兴趣的
干货
了解一下吧