三、我们的权限模型
先大概解释下我们的业务，我们做的是教育行业高校云平台，每个学校都可以在我们平台进行注册，注册完成后可以享受一些基础的服务，当然了不同级别的用户享受的基础服务是不同的，这些基础的服务包括新生注册管理、基础系统管理、考试系统管理、评教系统管理等模块，每个模块都相当于一个子系统，每个子系统都有各自的功能，每个功能也都有各自的相关的页面，而所有的子系统、页面以及页面上的功能按钮都是需要我们权限进行管理，所以我们的权限管理相对来说任务也是比较繁重的。
我们先来看下我们权限管理模块的类图：
核心还是基于用户、角色和许可的RBAC模型，只不过我们将这三者分别进行了相应的扩展：
用户
无论哪个用户首先它必须是属于某个部门的，部门是行政单位，而某个部门也可以包含多个用户，所以部门和用户的关系为1对多的关系；
先说一下为什么要有用户组的概念，如果有一类的用户都要属于某个角色，我们一个个给用户授予角色，重复工作特别多，所以我们把这么一些用户进行分类，也就是用户组，这样的话，我们直接对用户组赋予角色，减少重复的工作量，这样达到的目的是这，用户拥有的所有许可，就是用户个人所属角色拥有的许可与该用户所在用户组所属角色拥有的许可之和。一个用户可以属于多个用户组，一个用户组也可以包括多个用户，所以用户与用户组是多对多的关系；
角色
角色是一定数量的许可的集合，许可的载体，一个角色可以包含多个用户，一个用户同样的也可以属于多个角色，所以角色与用户的关系为多对多的关系。同样的一个角色可以包含多个用户组，一个用户组也可以属于多个角色，所以角色和用户组也是多对多的关系；
许可
许可我一般称它为权限，它包括控制对象和操作，控制对象一般为资源，包括菜单、页面、文件等资源，而操作一般包括增删改查等，图中“系统操作”就是操作，“菜单信息”就是控制对象；
菜单信息中的每个菜单都会有增删改查等操作，所以菜单信息与系统操作是一对多的关系；
我们给角色授予权限时，授予就是颗粒最小的权限，所以我们将系统操作权限授予某些角色。一个角色可以拥有多个系统操作，一个系统操作同样也可以属于多个角色，所以系统操作和角色为多对多的关系。
到这里我们就将我们的权限模型之间的关系基本上介绍完毕了，在类图中的两个类之间的多对多的关系在数据库中会出现第三张表，所以下面我们来看下我们的数据库中表的关系图：
四、改进
现在这个权限模型已经开发出来投入使用了，当然了现在的模型也不一定是最好的，只能说针对于现在的系统的规模是比较合适的，对于现在的权限模型还是有可以扩展的地方，其实就是类图中的菜单信息，在系统中我们只是粗犷的将子系统名称、子系统菜单、子系统菜单页面元素、文件等这些资源全部放到了一个表中即菜单信息表，在表中我们利用类型进行具体区分，同时利用上下级关系来管理他们之间的层次关系，但是在这个表中冗余的数据会特别多，我觉得如果可以更进一步改善的话，可以考虑将菜单表按照菜单类型进行拆分，然后再来一张表资源关系表来管理这些类型资源之间的关系。
