当前位置:文档之家› 庞飞-基于web的通用权限管理系统

庞飞-基于web的通用权限管理系统

高级软件工程课程设计基于web的通用权限管理系统的设计与实现1 研究现状权限管理技术的理论研究开始于20世纪60年代末70年代初,所权限管理,就是通过某种途径显示地准许或限制访问能力及范围,从而限制对关键资源的访问,防止非法用户的侵入或者合法用户的不慎操作造成破坏。

随着计算机技术和应用的发展,特别是互联网的发展,应用系统对于权限管理的需求开始迅速增加。

在随后40年的发展历程中,人们在权限管理技术的研究方面取得了很大的成果,先后出现过多种权限管理访问控制技术。

20世纪80年代到90年代初,自主权限管理自主访问控制技术、强制访问控制技术得到了美国国防部制定的橘皮书-可信计算机评估准则的认证。

但是,近几年来,人们普遍感到DAC和MAC的权限管理技术无法满足现今日趋复杂的应用系统的安全需求。

因此,基于角色的权限管理(RBAC),便成为人们研究访问控制技术的重点和热点。

2 可行性研究可行性研究是对项目进行可行性调研和论证,确定项目开发的价值和意义以及是否可以付诸实施。

其目的是在对比投入和产出的基础上考虑利用目前的资源、成本等因素能否实现一个系统以及是否会创造价值或带来实际的意义。

可行性分析可行性分析一般可定义为,可行性分析是在建设的前期对工程项目的一种考察和鉴定,对拟议中的项目进行全面与综合的技术、经济能力的调查,判断它是否可行。

2.1社会可行性分析通用权限管理系统的开发符合国家法律,能够与社会大系统实现良好的对接。

2.2 技术可行性分析开发通用权限管理系统具备所需要的条件。

开发通用权限管理系统使用的MS Visual Studio 2008系统开发工具。

Windows系列操作系统已经是普遍使用的系统,所以在技术上是成熟的。

2.3经济可行性分析开发通用权限管理系统只需普通配置的计算机,在开发经费上没有问题。

开发通用权限管理系统所投入的资金与系统投入使用后所带来的经济效益相比较,通用权限管理会给信息管理系统带来一定的经济效益。

2.4管理可行性分析通用权限管理系统现行的管理体制具有现代化的管理意识和管理水平。

在系统中,每个人都有自己的用户名和密码,因此在管理上可行。

综上所述,开发通用权限管理系统在目标上、技术上、经济上、管理上都是可行的。

3 需求分析需求分析是软件开发的重要阶段。

在需求分析阶段我们可以理清思路、澄清概念,最终形成一个完整的、清晰的、一致的系统需求,来帮助我们更好的进行系统开发,实现系统功能,满足用户需求。

3.1 面向对象的需求分析方法面向对象分析获得系统功能需求的方法与传统软件工程过程中需求分析的不同。

其核心内容包括:划分子系统、确定参与者(角色,可以是人也可以使其他子系统)并明确其关系、获得参与者用例并明确用例之间的关系、绘制用例图。

用例图即最终获得的系统用例模型,该图应当能够将系统中所有的功能需求或者其中某一方面的功能需求表达出来,所有这些用例图所表达的功能之和应该同用户提出的功能相吻合。

(1)划分子系统一个复杂的系统往往通过功能划分为若干小的模块,称为子系统。

划分子系统的目的是使复杂的问题简单化。

每个子系统还可以再划分子系统,所有这些子系统都被看作是对象进行数据(字段和属性)和操作(方法)的封装。

(2)确定参与者参与者是指与系统交互的人或其他程序,是所有用例的执行者。

在UML中使用一个人形的图标表示。

需要注意的是参与者不是指人或其他程序本身,而是指它在系统中扮演的角色,比如小明是以系统管理员的身份登录系统,参与者就是系统管理员。

(3)获取用例从用户的角度来看,一个用例(USE CASE)就是参与者完成的一项不可再分割功能,比如注册到一个网站。

UML对用例的标准定义如下:用例是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果。

用例之间的关系主要包括泛化、包含、扩展三种。

(4)绘制用例图用例图(USE CASE DIAGRAM)由参与者(Actor)、用例(USE CASE)、关系(RELATIONS)和系统边界等元素组成。

其中关系包括用例之间的关系、参与者之间的关系、参与者和用例之间的关系。

参与者之间的关系主要是泛化,因为参与者也是参与到系统中的类。

参与者和用例的关系就是简单的关联。

3.2权限管理系统描述权限管理是一个软件非常重要的组成部分。

一个完善的信息管理系统,关系到很多部门。

他们各尽其责,互相配合,互相制约。

所以,我们的电脑软件权限要细分,才能满足用户的需求。

我们的系统采用两级权限管理,先分用户角色,每个角色分派一定权限,权限的功能可以大部门是控制到窗口级,部门窗口限制还达到按钮级。

然后每一个用户可以扮演某一个角色或多个角色,从而构成了我们严密的权限分级系统。

权限管理严密,安全性高,支持加密。

安全权限可以细化到字段,真正实现了不同级别的人看不同的文件,实现一次登陆全网通行。

下面就来介绍一下权限管理系统操作的具体情况。

3.2.1 用户操作(1) 根据自己的喜好,对用户密码进行改动,并存入数据库。

(2) 根据用户需要,在自己的权限内对系统的数据库进行查询,获得所需的数据。

(3) 根据用户的角色代码,使用户在进入主界面的时候进入相应的部门操作。

3.2.2 管理员操作(1) 根据企业的用人要求,给员工分配权限,把用户的资料输入数据库中存储起来。

(2) 当用户的职位发生改变的时候,及时更新用户资料,再把新资料存档。

(3) 根据企业发展情况,对企业的权限、角色进行细分,可以进行相应的增。

加、删除与修改。

3.3用例建模在确定了系统中的角色以后,进一步分析系统需求,按照角色不同得到系统用例。

3.3.1系统参与者(1) 管理员:管理日志,增加、删除、修改角色,增加、修改、删除部门为用户分配权限等等管理用户操作。

(2) 用户:在管理员分配的权限内进行操作。

3.3.2用例图系统管理员的角色用例如下:(1)应用列表管理:添加应用列表。

(2)应用模块管理:新增应用模块,并且给应用模块分类。

(3)用户资料管理:新增用户、用户资料查询和修改用户资料。

(4)部门资料管理:新增部门、排序子部门、修改部门资料和移除本门资料。

(5)角色资料管理:新增角色、修改角色、给角色新增应用和给角色设置限。

(6)应用字段设定:设置字段。

(7)事件日志管理:日志查询。

(1)系统管理员的总用例图如下:图3.1系统管理员的总用例图(2)管理员对角色管理用例图图3.2管理员对角色管理的用例图(3) 管理员对部门管理用例图图3.3管理员对部门操作的用例图(4) 管理员对用户管理用例图图3.4管理员对用户管理模块操作用例图用户在权限管理系统中拥有管理员赋予的权限,能在自己权限内进行操作,因此用例图与管理员的用例图大同小异,在此就不用再画出来了。

3.3.3 用例规约用例规约的内容如下所示。

用例名称:用来指定用例名称。

用例描述:用来简单说明用例的作用。

前置条件:在执行用例之前系统必须处于的状态。

事件流:系统完成用例执行所需要的所有操作。

后置条件:在用例执行结束以后系统必须处于另一状态。

(1)修改密码用例规约用例名称:修改密码。

用例描述:用来修改管理员或者用户登录时的密码。

前置条件:管理员或者用户在系统中。

事件流:a管理员或者用户进入个人设定。

b输入原始密码验证密码是否正确,正确进入下一步否者修改密码失败。

c输入新密码。

d再次输入新密码。

e验证两次密码输入一致否则修改密码失败。

f提交到数据库提示密码修改完成。

后置条件:密码修改成功。

(2)用例名称:设定权限用例规约。

用例描述:管理员给用户设定一定的权限使用户在权限内能进行部分操作前置条件:在系统内。

事件流:a管理员登录系统进入角色管理页。

b打开一个角色,点击修改角色权限。

c修改角色权限然后点确定。

d提交数据库权限设定完成。

后置条件:权限设置成功。

(3)用例名称:新增用户用例规约。

用例描述:新增加一个用户。

前置条件:在系统内。

事件流:a管理员进登录系统进入部门资料管理。

b打开新增用户按钮。

c输入用户名和用户密码,设定用户类型。

d 提交数据库,新增用户完成。

后置条件:新增用户完成。

(4)用例名称:新增部门用例规约用例描述:管理员新增一个部门。

前置条件:在系统内。

事件流:a管理员登录系统进入部门资料管理。

b点击新增用户按钮。

c输入新增部门名称。

d提交数据库新增不猛成功。

后置条件:新增部门完成。

4总体设计完成系统的对象模型,包括系统的类图(CLASS DIAGRAM)和对象图的绘制。

类图表示不同实体如何彼此相关,它主要是显示了系统的静态结构。

对象图显示一组对象和他们之间的关系。

4.1概要设计类图由许多静态的说明性元素组成,它显示出类、接口以及他们之间的静态结构和关系。

其最基本结构是类和接口,此外还有他们之间的关系,此外类图还显示其内部结构。

4.1.1对象类型描述和类图(1) EventMessage 日志消息类该类主要是记录用户的登录信息如 ID、用户名、客服端IP、事件类型、应用名称、模块名称和登录时间。

也可以查询用户的登录信息。

其中查询的时候可也根据用户ID、用户名和登录时间查询;其中查询时间可也是一个时间段。

其类设计图如下:图4.1日志消息类图(2) BusinessFacade 逻辑类该类的主要作用是执行增加、修改、删除等操作,以及操作后的返回功能。

其中包括角色、权限、用户的增加、修改和删除。

其设计图如下、图4.2逻辑类图(3) CacheOnline 用户在线类该类的主要作用是记录用户的登录时间从而获取在线用户的列表,在用户列表中插入新登录用户,并且更新用户列表。

检查用户是否在线。

其类设计图如下:图4.3逻辑类图(4) CheckUpdate 检查更新类检测是否有最新版本并返回最新版本。

设计图如下:图4.4检查更新类图(5) FileTxtLogs 文本日志文件操作类该类主要作用是记录写操作文件日志,以及判断写操作文件日志是成功还是失败。

记录日志文件内容,获取日志文件目录。

设计图如下:图4.5文本日志文件操作类图(6) FrameSystemInfo系统信息操作类对系统各种信息进行操作,设计图如下:图4.6系统信息操作类图(7) FrameWorkLogin 登陆类该类主要作用是检测用户名和密码是否正确,判断正确用户进入界面,错误提示用户登录失败。

设计图如下:图4.7登录类图(8) FrameWorkPermission 权限检测类该类的主要作用是检测在线用户缓存、应用启动时间、版本等等。

权限检测成功后,用户能在相应的权限内进行操作,设计图如下:图4.8权限检测类图4.1.2 类图图4.9类之间的关系图4.2 详细设计系统设计是信息系统开发过程中的另一个重要阶段。

我们要根据之前进行分析的结果,在系统需求分析的基础上,来进行对系统的设计4.2.1权限系统定义在一个系统中包含了企业正常运转所需要的重要数据。

相关主题