上一篇主要是从权限管理的目标和总体构架上作了EOM的阐述。在我看来，很多程序员并不关心“要做什么？”，而是只关心“怎么做！”。对权限管理而言，他们并不关心权限管理在企业经营中的作用，只关心权限管理的程序是如何编制的，这是令人感到非常遗憾的事。如果权限管理不能满足企业经营管理的需要，不能促进企业经营向前发展，权限管理编好了那还有什么意义呢？就我而言，如果没有了目标，做任何事都会时没有意义的。
中国社会存在的一个普遍的现象： “不关心目的，只关心手段”。举《我要做全国最最好的标准权限组件和通用权限管理软件》作者为例，据他所言，在他大学期间，几乎没有学到有用的计算机知识，反而在毕业后工作中才感觉到软件的乐趣，学到了编程的技术。上大学本身是获取知识的手段，获取知识才是上大学的目的，但是，当前社会只关心大学毕业没有毕业，只关心考试得了多少分，但不关心知识获取了没有。我的经历正好和作者相反，我学到的东西基本是在上学的时候，毕业后，虽然开发程序很多，但学到的东西比较少，尤其是理论的东西更少，我基本上是依靠理论来推导出各种解决思路的。
回到权限管理问题的本身，从平常的角度来看，权限管理的编程有两个部分，一个是权限设置，一个是权限比对。这两个部分本身都相对比较简单，没有太多复杂。权限设置主要是向系统管理者提供一个用户权限的设置的功能。权限比对主要是在程序中提供一个函数，用于检查用户是否有权限进入下一个功能。除了这个两个部分，还有就是相关的参数设置等。
其实权限管理的亮点不在于编程，而是在于权限管理的设计，有了好的设计，编程应该没有什么问题的。我准备从需求设计、功能设计、数据库设计、软件构架设计四个方面来谈谈这个话题。
一、 需求设计
1、 权限管理的定位
1） 一般人编写权限管理，主要是在一个系统内建立用户和权限关系。其特点是用户和权限范围仅限于一个系统。
2） 也有能力比较强的人，在探索做的是一个企业内多系统的权限管理。其特点是用户和权限范围仅限于这个企业或这个企业的多个系统。
3） EOM的权限管理一定是定位于所有企业的，它是真正意义上的通用。通用几个含义，一个企业多系统使用或调用，多个企业多系统使用或调用。这样就可以避免大量的权限管理程序的重复开发了。
2、 需求分析
有了定位之后，那我们就要进行需求分析，明晰权限管理的内容和边界。
1） 一般程序员对权限管理的需求来自于具体系统开发需求，他们关心的是这个系统的菜单是什么？功能是什么，有哪些操作？有哪些特殊的权限控制？用户是如何被设置权限的？是否有角色？角色是如何设计的。根据这些需求，明晰数据库设计和程序的流程处理。他们所有的需求分析都是建立在具体的系统之上的。他们并不关心什么是权限？什么是用户？什么是功能？什么是操作？什么是角色！他们只要把他们认为的具体的内容与其做了对应就行了。例如，某个菜单查询，他们就把它做为一个功能。
2） 水平稍高的程序员由于想建立企业内多系统的权限管理，往往会对企业内的各种权限管理进行需求分析，力图找到一些共性的东西，然后通过共性的东西对各系统进行权限管理的整合。他们的重点是考虑到如何把系统的因素考虑进去，并能实现权限的集中管理。他们的需求本质上还是来自具体需求，只是其中增加了需求共性的分析，朝着通用的方向迈了一步。
3） EOM对权限管理的需求分析，并不是针对某个企业、某个系统。而是根据EOM，来分析员工和客户（用户）在企业经营中的职责和权利以及限制，以及建立与企业经营管理模式相适应权限管理模式。因此，EOM要从理论上解决的是，什么是权限？什么是用户？什么是功能？什么是操作？什么是角色！什么是权限管理的要素，要素之间的关系是什么？什么是权限管理模式，这种管理模式与什么样的企业经营模式相适应等等。当我们把这些问题考虑清楚之后，我们才能说对权限管理的有一个初步的认识。在此之外，我们还要跳开权限管理的本身的框框，站在更高的层次去看待，权限管理与其他功能之间的关系，例如，用户管理，参数管理等等。
有了这些理论和抽象的需求之后，我们就可以找一些具体企业和具体的系统去验证这些需求的正确性。
当然很多程序员还不习惯这种从理论到实际的思维方式，还是满足于从实践中来到实践中去，往往会说你怎么会知道别的系统权限管理需求呢？你怎么知道你的权限管理能适应所有企业权限管理需求呢？因为他不能穷尽所有的企业，不能知道所有企业权限管理的需求，所以他们认为通用的权限管理是不可能的。究其根本原因，是他们不能将实践的问题抽象到理论高度，然后用理论来解决实际问题。
3、 需求设计
我们可以根据需求分析，进行需求设计，通过一系列的定义，重新规范需求的内容和边界。这样我们就可以依据这个设计，展开功能设计、数据库设计、软件构架设计了。（以下的定义并不严谨，只是做个示例而已，如果严格起来，每个定义都可以成为一篇论文）
1） 权限的定义：
权限是指系统用户的职能与系统的功能和操作之间的关系。
这表明权限主体是系统的用户，权限的根据是用户职能，权限所涉及的是系统的功能和系统的操作。
注意：用户的概念和职能的概念都是EOM中员工、客户、管理三大要素的概念以及其内容的延伸。
2） 系统的定义：
系统是指企业为企业信息化而建立的各种应用系统。应用系统具有相对独立的、相对完整的功能、有相应的用户群。一个企业往往会建立几十个甚至成百上千个应用系统来满足企业经营管理的需要。
3） 系统用户的定义：
系统用户是指使用系统的员工和客户。其中狭义上的员工是指企业的员工，广义上的员工可能包含上级或下级企业的员工。
狭义的客户是指购买企业产品或服务的用户等，广义上的客户可能包含企业的管理部门、行业协会以及潜在的用户人群等。
无论是员工还是客户都可能是系统的用户。上级员工和外部客户都可能访问企业的系统而成为系统用户。
4） 用户职能的定义
用户职能是指使用系统的用户（员工）按照其岗位职能要求，以及企业管理的要求，从事的业务或管理活动。同时也指系统用户（客户）按照企业经营管理的要求，享受企业提供的各种产品、服务。
要注意无论是员工职能还是客户所享受的产品和服务都是有条件的、有限制的。
5） 系统功能的定义：
系统功能是指系统中相对独立的功能模块，这个模块常常具有用户界面，并完成界面中的各种操作。在后台处理中，功能模块可能并没有用户界面。
通常菜单、子菜单、具有菜单属性的命令按钮都是系统功能控件。权限管理是指用户触发这个控件后，程序对用户是否有权限运行其后的功能进行的检查和比对，若允许，则程序继续，若不允许，则程序提示返回。
6） 系统操作的定义：
系统操作是指在系统功能中为完成某一特定功能而编制的程序。系统操作涉及面很广，例如在一个信息录入功能模块之中，会出现新增、保存、删除、退出等操作控件，一个用户进入功能模块后，很可能只有增加权限，没有删除权限。又例如，在一个查询功能模块之中，用户只能查询到本单位数据，但不能查到其他单位的数据。
用户是否可以操作或操作程度如何也是权限管理的重要内容。
7） 角色的定义：
角色是指具体若干功能或操作的权限用户的别称。用户通过拥有角色，拥有角色所定义的若干功能或操作的权限。设计角色主要是方便用户权限的设置。
要特别指出的是，角色并不单指一个系统内若干功能和操作的集合。角色也可以指多系统的若干功能和操作的集合。
8） 权限设置的定义：
权限设置是指建立用户与系统的功能和操作之间的关系。权限设置可以提供用户与功能和操作的直接的关系，也可以提供建立用户与角色之间对应关系，以获取角色中的各种功能和操作的权限。
9） 权限比对的定义：
权限比对是指当前用户在当前功能或操作状态下，与预先定义的用户功能和操作权限的比对，返回值，有或无权限。若有权限，则程序继续，无则提示返回。
10） 参数的定义：
参数定义是指为实现权限管理的功能，而适应权限管理变化的参数、以及相关库表（字典）的维护功能。
例如：系统代码表、功能代码表、操作代码表、数据库用户名、密码、权限管理模式参数等等都属于参数定义范畴。而为了实现权限管理的软件构架的有关参数也是归属于其中。
11） 权限管理模式定义：
权限管理模式是指企业或系统采用权限管理的方式或方法。一般有系统管理模式、授权管理模式、集中管理模式。
1. 系统管理模式
所有的用户权限由这个系统的系统管理员来设置。
2. 授权管理模式
系统管理员可以设置用户权限，但是得到授权的用户，可以为其它用户设置权限。
3. 集中管理模式
企业对所属各种应用系统的用户权限采取集中管理，各个系统的用户权限设置由一个部门集中统一来完成。集中管理是系统管理或授权管理的高级阶段，它可以有效地规范企业用户的各种角色，方便用户权限的设置，实现单一用户和实名用户的管理，方便用户操作，降低和防范操作风险。
例如，一个用户要在系统A、系统B、系统C中增加相应的权限。
在系统管理模式下，系统A、系统B、系统C的系统管理员要分别为用户设置功能权限。
在集中管理模式下，只要进入一次权限管理功能，就能为用户设置系统A、系统B、系统C的权限了。如果，用户这些权限正好是一个多系统的角色，那只要将此用户赋予这个角色就行了。操作非常方便。
通过以上我们可以看到，我们对权限管理的需求分析和设计是按照EOM理论，采用抽象的方式进行的。大家可以拿具体的系统，具体的用户权限来验证这个需求是否完整，如果这个需求不完整，不全面，我们可以完善上述的定义使之更加科学更加合理。这样我们不但可以开发出一个通用的权限管理软件，而且建立了与之相适应的理论，这些理论将成为EOM一个部分。而EOM提倡的正是理论和实践的结合。光有理论不行，光有实践也不行，只有理论和实践的结合，才能发挥理论的价值和实践的价值。
