权限系统组织管理—具体设计说明书

前言:

上次聚哥让写具体设计文档。自己也写了自己模块的,认为写的挺好的。可是后来娥接手权限。我跟她说权限逻辑的时候,才发现非常多东西在具体设计文档中都没有写出来,所下面一个人接手的话,又要跑来问好多逻辑的问题。每一次都要做非常多反复性的工作。还有上次。做PB中期验收的毕业设计的时候,我没有下载到直接带着数据库的,可是材料中有数据库说明书,写的特别具体。所以我就依照别人的数据库说明书,搭建起来了,系统也成功跑起来了。这个时候认为这些文档特别的实用。所以,我想,别人看了我的具体设计说明书,是不是也可以非常清楚的了解这块的业务,高速的入手呢!由于我整理了一下ITOO
4.1 权限系统,组织管理模块。

 具体设计说明书(组织管理)

1引言

1.1编写目的

目的是为了总结本模块的主要功能,然后给再次开发这个模块的人一个好的開始。

预期读者:权限的系统开发者

1.2背景

说明:

a. 待开发软件系统的名称:权限系统——后台组织管理

b. 本项目的任务开发人员:栗振娟

1.3定义

组织:前台用户注冊的学校,我们称之为组织。

资源:高效云平台有五个系统,新生系统、权限系统等,这每一个系统都叫做每一个资源。

称为资源。用户拥有哪些资源,就是用户能够有权利使用哪些功能。

1.4參考资料

(1)、ITOO4.0 权限系统需求说明书

(2)、ITOO4.0 权限系统具体设计说明书

2.模块功能说明

2.1本模块在整个系统中的地位

    组织组织在权限系统的作用:连接前台和后台的交互点,由于仅仅有给组织分配了对应的资源。在前台库,才可以在页面中显示出来这个资源,这个资源才可以使用。所以给组织分配资源,是这个模块的主要作用。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" >

2.2、与其它模块的关系:

(1)、 左側导航栏,显示的是注冊模块注冊的全部学校。(注冊模块)相应表 TA_Organization

(2)、资源树。显示的是后台资源管理模块加入的全部前台资源(后台资源管理)相应表TA_BackResource

2.3、模块重要逻辑

由于高校云平台。面向的对象是全部的学校,所以每一个学校注冊之后。就会给这个学校分配一个新的数据库,包含权限、新生、考评、基础、成绩这个五个子数据库。以后这个学校全部的数据都会放入在这个自己的数据库中。比方:廊坊师范学院注冊了ITOO云平台,我们就会给它建立5个库(新生库、权限库、考评库、成绩库、基础库),华航注冊了ITOO云平台。那么相同我们也会给它建立5个库。这也就是注冊模块说的动态建库。

动态切库,由于不同的学校拥有不同的数据库,所以分配资源的时候,首先须要依据组织ID去找到某个组织所拥有的数据库。然后去找到对应的表,最后才可以对其表进行操作。

了解了以上的知识,再了解“给组织分配资源”这条线就变得很easy了。

第一条线:给组织分配资源:

依据资源ID获取连接师范学院的数据库连接字符串?—连接上师范数据库—找到权限库——找到权限库的TA_Resource表—将分配的新资源写入这个表。

第二条线:查询组织相应资源:

依据资源ID获取连接师范学院的数据库连接字符串—连接上师范数据库—找到权限库——找到权限库的TA_Resource表—就能够读取师范学院所拥有的全部资源

以下一张图能够描写叙述详细过程:

3、数据库使用说明

组织管理这个模块,共使用了4张表,以下是每张表中重点字段的说明。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" >

4、遗留问题:

(1)、 如今组织管理这个模块都是依照切库实现的情况下,写好的方法。可是由于切库还未搭建在ITOO上,所以还不可以动态的将资源加入到相应的某个学校的数据库中,同一时候也不可以依据资源ID动态的读取相应库中的数据。

(2)、 由于如今仅仅有一个前台权限库ITOO_Authority000000,所以全部的资源都是加入到这个库中,同一时候如今全部的组织都是读取的同一个库(ITOO_Authority000000)的资源,所以资源都是一样的。

(3)、 分配资源这条线方法还有点问题,方法类型有待于在考虑一下。后台资源管理负责提供这个接口,能够跟他们协商。

5、对于这个模块,我的想法和建议:

 5.1. 界面优化:

左側导航栏:如今学校少,看着还好。假设学校多了,找一个学校还得一个个找,并且看着好丑(这是重点)。

能够分类做成树的形状,更建议分类汇总。加入搜索框。

5.2、 点击组织,点击“很多其它”。才可以查看对应的学校信息和资源,一个陌生用户是不知道点击这里的是干嘛的,怎样给与用户更好地提醒呢?

5.3、分配权限的树,我已经拥有的资源,我还能够再选?尽管这条线,在详细实现的时候。我已经做了不让其反复加入,可是我认为应该给个默认提示,标注哪些是我已经拥有的。这样我就不用选了。浪费感情啊。

5.4、 假设廊坊师范学院不交钱了,不想使用考评系统了。我应该给它删除这个资源。可是如今的系统。还没有增加这个需求。下一个版本号能够考虑。

小结:

如今越来越认为文档的重要性。人能够走。可是得留下点东西嘛。这才是一个公司宝贵的財富,假设每一个人接手系统,都得重头開始捋,这样每次系统都是在反复性的工作。

希望我们的文档越写越好。真正发挥其作用。

时间: 2024-10-05 04:25:55

权限系统组织管理—具体设计说明书的相关文章

通用权限系统框架功能实现设计

1  开发环境技术:B/S(.NET C# ) 1.Windows 7及以上 (支援最新Win 8) 2.Microsoft Visual Studio 2013 C#.NET 3..NET Framework 4.0及以上 (支援最新4.5版本) 4.SQL Server 2008 R2及以上 (支援2012/2014)框架特点 2  系统简介 1.帮企业快速地实现各种通用功能,结合系统现有的通用权限管理功能. 2.快速地开发出各种项目应用系统.让企业开发一个系统变得非常轻松. 3.符合RBA

教务管理系统软件设计说明书

队名:伐木累 队长:石明浩 026 队员:禹继跃 020 匡永昌 022 徐纪彰 024 王飞 027 陈晓宇 004 1. 编写目的  学生管理是高校管理的重要组成部分,对于学校和政府教育管理单位来说都至关重要,所以学生管理系统应该能够为用户提供充足的信息和快捷的查询手段.但是使用传统人工的方式管理学生学籍.档案.成绩等,效率低.保密性差,不利于查找.更新和维护.使用计算机对学生信息进行管理,能够极大地提高学生管理的效率,节约教育经费,这也是适应学校信息化建设发展趋势的重要因素. 2. 软件系

架构设计分享之权限系统(看图说话)

前面一篇文章<最近架构随想>,我提到架构设计的一些构想,其实也是对之前项目经验的一些归纳及总结.今天我们就以权限系统作为切入点,谈一谈怎么设计权限系统以及怎么做到系统具有以下特性: Organized:如果系统组织比较好,可以起到事半功倍的效果. Encapsulated:对功能,结构,数据进行有效的封装,会使系统维护变得更加容易. Reusable:对常用功能以及组件进行有效的封装,可以使系统变得结构清晰且方便维护. Extensible:在设计系统的时候,如果很好的遵守OO的设计理念(OO

机房收费系统——数据库设计说明书

GB8567--88 数据库设计说明书 1      引言 优质数据库在处理大数据的程序或系统中是有非常重要的作用的,所以对于数据库的设计有很多的要求和规定.首先数据库要有很好的可维护性.灵活性,并且数据库的算法逻辑性也要有一定的优化性,这样可以对资源进行有效利用,并且处理数据的时间也会缩短. 1.1   编写目的 由于上机的人越来越多,产生的上机数据越来越多,原始的保存方式已经不能满足数据存储的需要,所以使用数据库对各种记录进行存储.并且数据库可以节省很多的资源,如人力.时间.空间等. 数据库

面试题:如何设计一个权限系统?

前言 权限管理是所有后台系统的都会涉及的一个重要组成部分,主要目的是对不同的人访问资源进行权限的控制,避免因权限控制缺失或操作不当引发的风险问题,如操作错误,隐私数据泄露等问题. 目前在公司负责权限这块,所以对权限这块的设计比较熟悉,公司采用微服务架构,权限系统自然就独立出来了,其他业务系统包括商品中心,订单中心,用户中心,仓库系统,小程序,多个APP等十几个系统和终端 1.权限模型 迄今为止最为普及的权限设计模型是RBAC模型,基于角色的访问控制(Role-Based Access Contr

转:RBAC如何设计一个权限系统

前言 权限管理是所有后台系统的都会涉及的一个重要组成部分,主要目的是对不同的人访问资源进行权限的控制,避免因权限控制缺失或操作不当引发的风险问题,如操作错误,隐私数据泄露等问题.目前在公司负责权限这块,所以对权限这块的设计比较熟悉,公司采用微服务架构,权限系统自然就独立出来了,其他业务系统包括商品中心,订单中心,用户中心,仓库系统,小程序,多个APP等十几个系统和终端 1.权限模型 迄今为止最为普及的权限设计模型是RBAC模型,基于角色的访问控制(Role-Based Access Contro

途牛原创|途牛无线权限系统的架构设计与实践

序 之前写过一篇大话权限中心的PHP架构之道,主要是从软件工程角度介绍,如何通过编码规范.依赖管理.数据源架构.事务处理.单元测试等技术,来保障权限系统的高可用,并未真正的涉及这套系统的架构. 今天准备从设计细节上分享一二. 望各位看官,心有“空杯”,带着“问题”一探究竟. 0. RBAC3 这里还是尤为的重要,因为他是整套系统设计的根基. 所以残忍的从上一篇中复制了一遍... RBAC认为权限授权实际上是Who.What.How的问题.在RBAC模型中,who.what.how构成了访问权限三

RBAC用户权限管理数据库设计

http://minjiechenjava.iteye.com/blog/1759482 RBAC用户权限管理数据库设计 博客分类: RBAC 权限设计 RBAC RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成"用户-角色-权限"的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数

权限管理系统之组织管理

概述 基于角色的用户权限管理系统(RBAC)是目前公认的解决大型企业的统一资源访问控制的有效方法. 本套权限管理组件不局限于传统的权限,角色,用户三者的关系,在减小授权管理的复杂性基础上,通过独特的允许.禁止资源控制思想,增强了授权的灵活性.既可以按照角色统一授权,也可以对人员独立授权.权限可粗粒度的分为模块权限,亦可细化到具体操作资源和功能(菜单.按钮.数据).能够指根据系统管理员设置的安全规则或者安全策略,能够达到使用户可以访问且只能访问自己被授权的资源,并拒绝访问被禁止的指定资源. 平台配