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

秋式开源团队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. 线束。
后置状态:系统的管理员（数量与职权）有所改变。