秋式开源团队:权限管理系统需求与分析

秋式开源团队Winform组简介:

秋式开源团队winform组,主要负责非Web内容的开源项目,主要为Winfrom项目,但不止于winfom。

目前第一期项目为秋式开源团队VS插件与权限系统,本文为权限系统的需求与分析,由winform组提供。

原文发表于:http://www.cyqdata.com/qswinform/article-detail-36354

撰写人:秋式开源团队-winform小组-何庆攀

如果网友对权限系统有兴趣,欢迎关注:秋式开源团队-Winform组http://www.cyqdata.com/qswinform

 

以下为正文内容:

项目的目标

提供一个调用简单、可复用性高、满足一般需求的权限管理模块。为需要对权限管理的系统节省开发本。

产品的用户

开发基于.net且权限管理较为复杂的系统的开发者。

限制条件

权限管理项目要能够和以后开发系统对接,做到权限系统和以后的应用系统完全分离。

短语解释


短语


解释


产品


权限管理系统


系统


权限管理系统


外部系统


使用权限管理系统的系统


用户


外部系统的用户


管理员


权限管理系统的管理员


资源


外部系统的某项数据


资源操作


外部系统对资源的处理(需要授权)


资源权限


外部系统对资源操作的一个度量值(参数)


资源操作参数


代表资源权限


权限


产品内部定义的一个实体类


前置条件


成功执行用例的前置条件


后置状态


成功执行用例的的后置状态


主流程


成功执行用例的主要流程

 

事实与假设

假设

a:基于RBAC模型实现用户与资源权限的关联。

权限管理RBAC域模型图:

附加说明:

1.       角色与组都实现继承,在多级继承中如果多继承则向上查询时消耗的时间、空间比较大,所以只选择单继承。

工作范围

系统业务数流图:

附加说明:

2.       与权限管理系统交互的外部系统可按交互方式分为三类:用户管理系统资源权限管理系统、资源权限消费者。

3.       需要管理员给用户分配资源权限。

 

产品范围

运行环境

权限系统运行环境上下文(图):

附加说明:

1.       权限管理系统在.net平台上,供同处一主机上的其它系统调用(包括产品自带的管理系统的UI)。

2.       产品可实现对不在同一主机上的系统交互接口。(注:此产品接口可以是扩展功能,因为此接口的功能同样可以由同一主机的其它系统提供,即可以留给产品的使用者开发。)


业务用例

权限管理业务用例图:

附加说明:

1.       图中外部系统中的三个子系统是按照外部系统访问本系统的方式而区分,是从本系统的角度区分,和外部系统的子系统划分没有必然的关系,在外部系统中未必会区分这三个实体。

根据假设a(见事实与假设)可把“使用户与资源操作关联”用例细分为以下多个用例:

附加说明:

1.       图中权限系统的管理员划分是按照系统的工作流程来划分,是系统真实存在的实体。


用例叙述

注:在本文档的上下文中的用例叙述中,前置条件、主流程、后置状态没有特殊说明则都是指基于成功执行用例的情况。如前置条件是指:能成功执行用例的前置条件。

Ø  用例:添加资源操作参数

前置条件:外部系统拥有新的(还未存入系统中的)资源操作。

主流程:

1.       外部系统触发添加资源操作参数操作,用例开始。

2.       外部系统获得执行此用例的操作权限。

3.       外部系统传入将要添加的资源操作参数。

4.       系统判断传入的数据的合法性。

5.       系统将接收到的资源操作参数保存到系统的存储系统中。

6.       把执行操作的果返回给外部系统。

7.       结束。

后置状态:系统的存储系统加入了新的资源操作参数。

附加相关用例:查询、修改、删除资源操作参数,用例叙述略。

 

Ø  用例:添加用户

前置条件:外部系统拥有新的(还未存入权限系统中的)用户。

主流程:

1.       外部系统触发添加用户操作,用例开始。

2.       外部系统获得执行此用例的操作权限。

3.       外部系统传入想要添加的用户信息。

4.       系统判断传入的数据的合法性。

5.       系统将接收到的资源操作保存到系统的存储系统中。

6.       把执行操作的果返回给外部系统。

7.       结束。

后置状态:系统的存储系统加入了新的用户信息。

附加相关用例:查询、修改、删除用户,用例叙述略。

 

Ø  用例:查询用户对应的资源操作参数

前置条件:用户、资源操作参数已经分别被添加入系统的存储系统中,且两者已经按照系统的方式建立起关联。

主流程:

1.       某用户在外部系统中将要执行某些资源操作时,此用例开始。

2.       外部系统输入用户的必要信息和要执行的资源操作(参数的标识符)的范围。

3.       判断用户的合法性。

4.       系统返回在指定查询范围中,用户所拥有的资源操作(参数)集。

5.       结束。

后置状态:用户获得其对应的资源操作参数。

 

注:以下用例是根据假设a(见事实与假设)而得到的用例(非必需的用例)的叙述。

Ø  用例:关联资源权限到权限

前置条件:要关联的资源权限已经被添加入的系统的存储系统。

主流程:

1.       权限管理员获得其权限,并触发关联资源到权限的操作,用例开始。

2.       指定一些(已有的)资源操作参数。

3.       指定一些(原有的或者新建的)权限(实体)。

4.       将指定的资源操作参数关联到指定的权限上。

5.       结束。

后置状态:指定的权限(实体)拥有指定的资源操作参数。

 

Ø  用例:权限管理

前置条件:无

主流程:

1.       权限管理员获得其权限。

2.       对权限的增、删、查、改。

3.       结束。

后置状态:权限集有所改变。

 

Ø  用例:关联权限到角色

前置条件:要关联的权限已经被权限管理员添加入库。

主流程:

1.       角色管理员获得其权限,并触发关联权限到角色的操作,用例开始。

2.       指定一些(已有的)权限。

3.       指定一些(原有的或者新建的)角色。

4.       将指定的权限关联到指定的角色上。

5.       结束。

后置状态:指定的角色拥有指定的权限。

 

Ø  用例:关联角色到角色(角色间的继承)

前置条件:无

主流程:

1.       角色管理员获得其权限,并触发关联角色到角色的操作,用例开始。

2.       指定一个(原有的)父角色。

3.       指定一些(原有的)子角色。

4.       判断子角色是否有父角色。

5.       判断父角色是否有继承所选的子角色。

6.       关联所选子角色到父角色。

7.       结束

后置状态: 子角色继承父角色,子角色拥有父角色的权限。

异常流程1:

1.       在主流程中的第4步判断中,如果子角色有父节点(角色),则启动该异常流程。

2.       提示不允许多继承的非法操作信息。

3.       结束。

 

异常流程2:

1.       在主流程中的第5步判断中,如果父角色是某选定子节点的的子孙节点,则启动该异常流程。

2.       提示不允许直接或接的父节点继承于它们的子节点的非法操作信息。

3.       结束。

附:*异常流程1是为了保证角色间不存在多继承的关系。如果能解决多继承中查询父节点集的效率问题,则可以考虑实现角色间的多继承关系。

*异常流程2是为了保证角色间不存在继承环,如:a继承b,b继承c,c继承a。

 

Ø  用例:角色管理

前置条件:无

主流程:

1.       角色管理员获得其权限。

2.       对角色的增、删、查、改。

3.       结束。

后置状态:角色集有所改变。

附:在实现删、改时要注意角色树的处理。

 

Ø  用例:关联角色到组

前置条件:要关联的角色已经被父组的管理员添加到当前组中。

主流程:

1.       当前组管理员获得其权限,并触发关联角色到组的操作,用例开始。

2.       指定一些(当前组拥有的)角色。

3.       指定一些(当前组拥有的)子组。

4.       将指定的角色关联到指定的组上。

5.       结束。

后置状态:指定的子组拥有指定的角色。

附:因为该用例的前置条件中知每个组节点都存在“父组”,父组又存在父组,所以至少有一组没有存在父组,而没有父组则不满足前置条件。为了解决这个问题,我们可以在系统中默认的创建一个超级组,并为这个超级组指定一个组管理员(系统内部用户)。这个超级组拥有系统中所有非系统默认的角色(把这特权设成系统默认创建的一个角色,这样可以再分配给其子组),系统中的所有组都是超级组的子孙组(子组或间接子组)。

 

Ø  用例:管理组

前置条件:无

主流程:

1.       组管理员获得其权限。

2.       对子组的增、删、查、改。

3.       结束。

后置状态:子组集有所改变。

附:增加子组时组管理员会成为子组管理员之一。

 

Ø  用例:管理组成员

前置条件:无

主流程:

1.       组管理员获得其权限。

2.       *移动组中的非管理员或子孙组中的成员到指定的子组或本组。*指定、移除子组成员为其所在组的管理员。

3.       结束。

后置状态:组员的相应角色得到了重新分配。

附:管理员不能把组成员移除到组外,因为组成员和组管理员都属于父组成员,从父组的角度来看,组员之间是不能相互删除,这样也避免的恶意的错误的操作,也可以实现职者分块化。如果要彻底删除某用户则需要用户管理员或外部用户管理系统权限,如果想要减少或不给其角色,则可以新建一个子组分配给其合适的角色,把组成员移入新建的组。

 

Ø  用例:关联用户到组

前置条件:要关联的用户已经被添加入的系统的存储系统。

主流程:

1.       用户管理员获得其权限,并触发关联用户到组的操作,用例开始。

2.       指定一些(已有的)用户。

3.       指定一个(已有的)组。

4.       将指定的用户关联到指定的组上。

5.       结束。

后置状态:指定的权限(实体)拥有指定的资源操作参数。

 

Ø  用例:管理系统用户

前置条件:无

主流程:

1.       用户管理员获得其权限。

2.       增、删、查、改系统内部的用户(一般是系统管理员)。

3.       线束。

后置状态:系统的管理员(数量与职权)有所改变。

版权声明:本文原创发表于博客园,作者为路过秋天,原文链接:

http://www.cnblogs.com/cyq1162/archive/2011/04/17/2019069.html

时间: 2024-10-02 14:31:10

秋式开源团队:权限管理系统需求与分析的相关文章

秋式开源团队:第一期项目论坛数据库设计文档

秋式开源团队自成立以来,已近快一月时间...... 如需了解团队近一月的工作近况,可看:秋式开源团队:第一期项目论坛进展情况汇报(一) 关注秋式开源团队,留意:http://www.cyqdata.com/qiushi 团队需要激情,更需要坚持,欢迎有激情,能坚持者加入,三分热度者请慎重.   下面为本期论坛数据库设计文档,发布共享,同时也欢迎各界人士多提意见. 论坛:数据库设计文档 数据库名:CYQBBS 序号 表名 说明 1 BBS_Attachment 论坛附件表 2 BBS_Attach

秋式开源团队-Web1组-论坛-第一阶段源码发布并提供下载

秋式开源团队Web1组简介: 秋式开源团队web1组,主要负责传统webform方式的开源项目开发. 目前第一期项目为秋式开源团队:论坛,本文为web1组截至上周的源码整理,由web1组提供. 原文发表于:http://www.cyqdata.com/qsweba/article-detail-38075 撰写人:秋式开源团队-web1小组-房垚华   如果网友对本系统有兴趣,欢迎关注:秋式开源团队-Web1组(http://www.cyqdata.com/qsweba)   以下为正文内容:

权限管理设计、分析、实现参考资料

AspNetForums中基于角色的权限控制 http://blog.joycode.com/dotey/archive/2005/02/24/44791.aspx asp.net页面如何控制页面依据不同用户权限有不可见.可见.编辑 三种操作权限 http://community.csdn.net/Expert/topic/3436/3436974.xml?temp=.0139429 做过权限管理和想做权限管理的人进来(附我的思路) http://community.csdn.net/Exper

浅谈权限管理的对象模型和实现

对象 浅谈权限管理的对象模型和实现    beegee(原作) 关键字    权限管理 对象模型 ACL 电子政务 浅谈权限管理的对象模型和实现 beegee (2003-7-16) 目录: 1.权限管理问题的分析 1.1权限管理简要分析 1.2电子政务系统的权限管理 1.3商业化应用系统的权限管理 1.4他山之石 2.权限管理子系统设计 2.1权限管理子系统的总体目标 2.2权限管理子系统的对象模型 2.3注意与不足 3.权限管理子系统的实现 3.1面向对象的实现 3.2组件层与功能层对对象的

开源:秋式广告杀手源码

前言: 在一个精神上容易空虚寂寞冷的岁月里,我静静地看了两个月的书,还报了健身房,请了私教,做为一名有思想的少年人,一个健康的生活态度还是要有的,至于工作,偶尔有猎头约就去面聊体验各种奇葩(待满3个月,再来一篇专门的回忆录满足大家的口味). 虽然人生有很多新的领悟,不过这都不是重点,而是,当看书看到感觉无书适看时,就转一下念,故我又回来写写文章了. 刚刚在CTO俱乐部的群聊,然后聊到写书的事,说出书虽然赚不到钱,但可以得瑟,我说我写了400多篇文章,他们说我整理一下,就可以出书了,我想了一想,算

springboot(十四):springboot整合shiro-登录认证和权限管理

这篇文章我们来学习如何使用Spring Boot集成Apache Shiro.安全应该是互联网公司的一道生命线,几乎任何的公司都会涉及到这方面的需求.在Java领域一般有Spring Security.Apache Shiro等安全框架,但是由于Spring Security过于庞大和复杂,大多数公司会选择Apache Shiro来使用,这篇文章会先介绍一下Apache Shiro,在结合Spring Boot给出使用案例. Apache Shiro What is Apache Shiro?

新的RBAC:基于资源的权限管理(Resource-Based Access Control)

本文讨论以角色概念进行的权限管理策略及主要以基于角色的机制进行权限管理是远远不够的.同时将讨论一种更好的权限管理方式. What is a Role? 什么是角色 当说到程序的权限管理时,人们往往想到角色这一概念.角色是代表一系列行为或责任的实体,用于限定你在软件系统中能做什么.不能做什么.用户帐号往往与角色相关联,因此,一个用户在软件系统中能"做"什么取决于与之关联的各个角色. 例如,一个用户以关联了"项目管理员"角色的帐号登录系统,那这个用户就可以做项目管理员能

如何从零设计结构清晰、操作友好的权限管理模块

本文讲的是如何从零设计结构清晰.操作友好的权限管理模块, 前言 在开讲之前,先列举几个场景: 场景一 Hi,今天那个销售总监说要设立几个销售经理的职位,然后每个经理管理自己小组的销售员,我们把用户的销售数据按组分开来吧. 场景二 Mario,今天那个市场部的说要分立几个板块,公众号的管理所有文章投稿评论,推广管各平台宣传策略方案与实施,对,竞品的相关资料数据也要分立出来,我们要把这些分开来.之前讨论的销售部的事情和这个没关系哦. 场景三 那个,xx店的店主说,他管理的两家门店,想同时处理两家店的

不使用三方包时,如何在ThinkSNS中建立优雅的用户权限管理

本文主要全面讲解在不适用第三方包的情况下,如何在基于Laravel框架上,研发社交系统ThinkSNS+时,简历一套优雅而不失性价比的用户权限管理体系功能,[内含ThinkSNS真实代码]. 需求场景 就是用户组+权限节点,这个需求 laravel 有很多很好的第三方包实现.下面描述代码不参与缓存机制纯数据库查询,给大家提供一个思路. 下面的代码都是来自于ThinkSNS+,是基于 Laravel 全新开发的 ThinkSNS 社交开源项目,遵循 Apache-2.0 开源协议.欢迎 Star