面向对象的思想和UML的方法.ppt

聚合（AGGREGATION）? 上面图中，有一个菱形（空心）表示聚合（aggregation）（聚合类型为共享），聚合的意义表示has-a关系。聚合是一种相对松散的关系，聚合类B不需要对被聚合的类A负责。 组合（COMPOSITION） 这幅图与上面的唯一区别是菱形为实心的，它代表了一种更为坚固的关系——组合（composition）（聚合类型为复合）。组合表示的关系也是has-a，不过在这里，A的生命期受B控制。即A会随着B的创建而创建，随B的消亡而消亡。 依赖(DEPENDENCY) 这里B与A的关系只是一种依赖(Dependency)关系，这种关系表明，如果类A被修改，那么类B会受到影响。 用户模型包含以下概念： 场景 该场景涉及一个简单的安全组件，此组件支持 Web 登录和受控制的在线资源访问。每个资源的所有者可以定义谁能够访问该资源。从业务的角度看，此组件具有三个主要功能： 设置谁可以访问每个资源 登录和访问所需资源 记录哪些用户在访问每个资源，用于审核目的 用户角色 第一步是确定谁将使用该解决方案，用户角色描述一群具有相似需要和职责的用户。用户角色可以表示用户组织中将大量使用该解决方案的特定工作。或者，用户角色可以具有更细的粒度，仅包括执行不同类型的工作但需要以相似方式使用该解决方案的人员的一个共同工作方面。 用户模型 包含许多用户角色。用户角色应该基于用户群体的实际情况，而不是精心设计以匹配解决方案本身的设计。 在我们的安全组件场景中，存在拥有资源的人员和使用资源的人员。其中每个群体分别称为“资源所有者”和“业务用户”。 用户角色涵盖用户工作的一个方面，而不是代表某项完整的工作。用户角色不是互斥的。有些人可以是一个资源的资源所有者和另一个资源的业务用户。资源所有者甚至可以是他或她自己的资源的业务用户。只要某个个人一次仅扮演单个用户角色，就足以对这些用户角色进行区分了。 另一个用户角色是“审核员”，负责检查审核记录以确定谁正在访问每个资源。 最后，您需要考虑： 谁将设置该解决方案？ 谁将确保该解决方案保持运行？ 谁将调查该解决方案的问题？ 谁将扩展该解决方案？ 安全组件具有以下用户角色： 资源所有者 负责确保正确的用户获得对他们拥有的资源的访问权限 业务用户 负责使用适当的资源来执行业务 审核员 负责安全策略的定义（和对这些策略的遵从性） IT 管理员 IT 系统（包括该安全组件）的可用性 部署人员 负责经过测试的软件版本的初始部署 开发人员 负责向该组件添加新功能并修复代码中的缺陷 测试工程师 负责验证该组件的编码是正确的 解决方案架构师 负责选择应该使用该组件的场合 用户角色 每个用户角色在该用户模型中使用一个将构造型设置为 user_role 的 UML 类来表示。该构造型显示在 UML 类的顶部，并带有一个 图标。还为该 UML 类指定了一个构造型为 definition 的属性。此属性的名称是对该用户角色的简短描述，并标记有 图标。图 1 显示了一个使用 UML 类来定义的用户角色的示例。 图 1. 使用 UML 类定义的用户角色 确定用户目标 每个用户角色应该至少定义一个用户目标。用户目标 定义用户角色尝试达到的最终状态或目的。图 2 显示了“资源所有者”(Resource Owner) 用户角色的用户目标示例。 图 2. 资源所有者的用户目标 该用户目标的名称是“资源所有者”希望达到的状态。存在一个提供简短描述的 definition 属性、一个或多个 measure 属性 ( ) ，并可选地存在一个或多个 target 属性 ( )。 measure 属性描述用户角色将如何测量该用户目标是否成功实现。在适当的情况下，还可以对表示成功的测量成果级别进行建模。这是在 target 属性中提供的。 聚合关联。 定义了用户目标以后，就可以使用与 primary_goal 构造型的聚合关系来将该目标与适当的用户角色联系起来。将其称为主要目标是为了强调我们仅在对驱使用户角色使用该解决方案的原因进行建模。 图 3 显示了该用户角色与该用户目标之间的聚合关联。 类的特性 重载： 重载指类的同名方法在给其传递不同的参数是可以有不同的运动规律。在对象间相互作用时，即使接收消息对象采用相同的接收办法，但消息内容的详细程度不同，接收消息对象内部的运动规律也可能不同。 如 老板指派采购员买东西，当老板没有指明买什么时，采购员可能默认买地瓜；如老板指明要采购员买大米，采购员可能到最近的超市买10斤大米；如老板指明采购员今天晚上到福州东街口买5斤大米，那采购员将不得不按老板指定的时间、地点去购买5斤大米。 函数重载是指在同一作用域内的若