二 分析设计
1 静态模型
安全对象
由于安全对象在程序设计期确定，所以设计的目标是确保一个需要控制的地方有且仅有一个安全对象(一一对应)，至于维护性之类的运行期相关因素均可忽略。
一个安全对象基本上最少要有一个区分其它安全对象的身份(ID)和便于人理解的名字(这里的人指程序员，如果在定义编号时使用了有效的编码规则可以省去这个无关紧要的属性)。由于可能有子安全对象，它还必须让使用者知道其有关子安全对象的信息。我们可以使用Composite的模式来完成上述功能。如图2所示：
在前面讲到安全对象有结构安全对象和行为安全对象之分，在这里是否也要建立两个不同的类确定这种区分呢？我的建议是在设计的开始要抑制子类化的冲动。因为此时我们定义的对象并不清晰，到用代码来实现还有很大的距离。在动态建模时，我们还会进一步充实类的方法和属性。
由于子对象的存在，所以在实现时要避免循环包含的情况。这里的循环包含指A包含B，而B又包含A的情况。要避免这种情况，需要在Add()方法中增加一个约束：Add()的对象不能是当前对象自己或在其父对象链上。
一一对应要求一个安全对象只有一个父对象，所以也不允许Add()一个已有父对象的安全对
(题外话：现在有些信息有这样的安全需求，对于同一模块授于用户A和用户B相同的权限，但是A只能访问A生成的数据而B可以访问全部数据。这样的安全对象该如何定义呢？)
图2：安全对象模型
访问者、用户和角色
根据领域模型，我们会发现有些角色也会有类似安全对象的“整体—部分”的关系，是否也使用Composite模式呢？让我们来分析角色的来源：企业在定义一个信息系统的角色时一般会根据企业的行政架构或企业的生产流程来定义。行政架构上是有清晰的层次的，但是根据生产(业务)流程来定义的角色之间并没有明显的“整体—部分”的关系。我个人的经验是可以引入Composite模式来表示行政架构相关的角色之间的关系，由于这些角色在管理上启到了与用户组相类似的功能，所以为了简化模型我们可以将用户组取消而直接用角色来替代。虽然这里的模型并没有严格区分行政架构的角色(用户组)和流程相关的角色，但是在实际中他们还是有细微差别的。
在理解上用“父—子”关系而非“整体—部分”来分析行政架构相关的角色可能更清晰一些。在划分这些角色时要注意将每个组织的“领导”、“部门经理”等与“官”有关的角色作为相关组织角色的子角色来定义(我们往往会犯领导更大的错误J)。整理后访问者模型如图3所示：
图3：访问者模型
授权和验证规则
前面在领域建模时已经讨论了授权的继承问题。使用继承将会大大增加权限验证的复杂性，在大型系统中可能会影响验证的效率。这是要仔细考虑的问题，建议在实际采用前最好测试一下。否则每个验证都要几秒的时间，就是再好再安全的软件也不会有用户来使用的。
如果使用了继承，自然又会引入验证冲突的问题。举个简单的例子：如果用户A有对安全对象a的授权①，在可继承的情况下安全对象a的子安全对象b也自动有相同的授权给用户A，但是如果用户又另外定义了用户A对安全对象b的授权②。在一般情况下来讲，这两个授权肯定是相互有冲突的，否则就是管理员吃饱了没事干J。这个时候还采用“拒绝优先”的规则是不合时宜的，根据人们先一般后特殊的习惯，我们可以定义这样的规则：子授权(对应于授权②)优先于父授权(对应于授权①)。也就是说如果授权②明确了用户A对安全对象b的访问是被允许的或被拒绝的，那么授权①就不起作用的；只有在授权②的验证规则不能确定用户A对安全对象b的访问权限的情况下授权①才会起作用。
稍微细心的读者会发现在上面的安全体系中存在三种授权：安全对象授权给用户，安全对象授权给角色，角色授权给用户，见图4。可见在安全对象到用户的授权流程中又有两条“路线”可以到达，这里也是一个潜在的冲突源。根据“从一般到特殊”，我们让“安全对象授权给用户”优先来解决冲突的问题。
图4权限流向图
验证规则表现企业的逻辑，而企业的逻辑又是出了名的“没逻辑”（许多程序员报怨的所谓‘变态的需求’、‘没完没了的变更需求’讲得都是这个）。要求企业的逻辑不‘变态’就象要求软件可以适应企业将来的需求一样不现实，我们能做的就是将这种变化控制在一定的范围之内。我们在设计验证规则时要考虑为将来的发展留下足够的余地，尽可能避免陷入一旦客户真的提出修改就导致全部重来的地狱。在这里定义了只包含一个验证方法的抽象类ValidateRule，然后让其它有意义的验证规则来继承这个类（如PeriodRule）。好处是很明显的：如果客户提出新的验证需求时只要新增一个验证类就可以了，不用改变其它的验证类。这里简单介绍一下PeriodRule，它包含一个开始时间和一个结束时间表示验证起作用的时间段，frequence属性表示时间段重复发生的频率（每天、每月、每年等等），而validate属性表示时间段内的授权是否有效。
图5授权与验证
小结
在对领域模型进一步分析，我们得到了一个更加丰满的模型——静态模型。静态模型中我们添加了各个类的属性和部分抽象方法(这里各类的属性并不是完整的，由于它们对我们 关注的安全主题没有什么关系所以对它们没有过多介绍，有兴趣的读者可以自行根据适当的情况添加)。我们将在下一步的动态建模中来进一步完善各类的方法。
