建模揭秘.docVIP

建模揭秘，第 2 部分: 构建用户模型 ? ? 本文内容包括： 引言 场景 用户角色 用户目标 用户角色和技能集 构建词汇表 设计用户任务 关联用户任务与用户对象/构件 验证匹配 将用户对象或构件与技能集关联起来 分组相关用户任务 结束语 致谢 参考资料 用户模型是对一组人员和这些人员如何使用某个 IT 解决方案的描述。这种类型的建模基于主要的可用性理论与实践，并允许解决方案架构师指定 IT 解决方案的外部条件，以便该解决方案对所有类型的用户都有用并可用。在本文中，了解如何为支持安全 Web 资源访问的简单组件构建用户模型。了解用户模型如何确定需求定义方面的可能差距。 引言 在本系列的第 1 部分中，您了解了什么是用户模型，以及为什么它可以帮助改进您构建的系统的可用性。用户模型从人员的角色、目标、技能、要求他们执行的任务和他们将在 IT 解决方案中处理的对象等方面，描述他们将如何使用 IT 解决方案。用户模型包含以下概念： 用户角色 一组职责，刻画使用系统的人群的特征 用户目标 用户角色必须使用该解决方案的目的和动机 技能集 用户角色可能具备的相关技能的集合 用户任务 用户角色采取来帮助实现用户目标的操作 用户对象 用户角色理解并在用户任务期间使用的概念或虚拟对象 用户数据类型 用户对象的复杂属性类型 用户对象筛选器 用户对象属性的有限子集 用户构件 用户角色在用户任务期间必须使用的物理对象或文件 用户域 用户任务的逻辑分组 规程 技能集的逻辑分组 用户团队 用户角色的逻辑分组 用户模型是一种统一建模语言（Unified Modeling Language，UML）类模型。该模型中的每个元素表示为一个应用了适当构造型的 UML 类。构造型化的 UML 特性和关联描述元素的属性和属性之间的关系。 在本文中，了解如何为一个简单场景构建用户模型。（UML 屏幕截图来自 IBM Rational? Software Architect, Version 7.0。） 场景 该场景涉及一个简单的安全组件，此组件支持 Web 登录和受控制的在线资源访问。每个资源的所有者可以定义谁能够访问该资源。从业务的角度看，此组件具有三个主要功能： 设置谁可以访问每个资源 登录和访问所需资源 记录哪些用户在访问每个资源，用于审核目的 用户角色 构建用户模型的第一步是确定谁将使用该解决方案。用户的特征在用户模型中通过用户角色 来刻画。用户角色描述一群具有相似需要和职责的用户。用户角色可以表示用户组织中将大量使用该解决方案的特定工作。或者，用户角色可以具有更细的粒度，仅包括执行不同类型的工作但需要以相似方式使用该解决方案的人员的一个共同工作方面。 用户模型 包含许多用户角色。必须特别小心地确定所有类型的用户，因为忽略某个人员群体会在解决方案中导致脆弱性。用户角色应该基于用户群体的实际情况，而不是精心设计以匹配解决方案本身的设计。 在我们的安全组件场景中，存在拥有资源的人员和使用资源的人员。其中每个群体分别称为“资源所有者”和“业务用户”。 用户角色涵盖用户工作的一个方面，而不是代表某项完整的工作。用户角色不是互斥的。有些人可以是一个资源的资源所有者和另一个资源的业务用户。资源所有者甚至可以是他或她自己的资源的业务用户。只要某个个人一次仅扮演单个用户角色，就足以对这些用户角色进行区分了。 另一个用户角色是“审核员”，负责检查审核记录以确定谁正在访问每个资源。 最后，您需要考虑： 谁将设置该解决方案？ 谁将确保该解决方案保持运行？ 谁将调查该解决方案的问题？ 谁将扩展该解决方案？ 该安全组件具有以下用户角色： 资源所有者 负责确保正确的用户获得对他们拥有的资源的访问权限 业务用户 负责使用适当的资源来执行业务 审核员 负责安全策略的定义（和对这些策略的遵从性） IT 管理员 负责 IT 系统（包括该安全组件）的可用性 部署人员 负责经过测试的软件版本的初始部署 开发人员 负责向该组件添加新功能并修复代码中的缺陷 测试工程师 负责验证该组件的编码是正确的 解决方案架构师 负责选择应该使用该组件的场合 每个用户角色在该用户模型中使用一个将构造型设置为 user_role 的 UML 类来表示。该构造型显示在 UML 类的顶部，并带有一个 图标。还为该 UML 类指定了一个构造型为 definition 的属性。此属性的名称是对该用户角色的简短描述，并标记有 图标。图 1 显示了一个使用 UML 类来定义的用户角色的示例。 图 1. 使用 UML 类定义的用户角色 在 Rational Software Architect 中，还为每个属性显示了 图标，意味着该属性是私有