原文地址：http://www.ibm.com/developerworks/cn/architecture/ar-usermod2/?S_TACT=105AGX52&S_CMP=tec-csdn
2008 年 7 月 10 日
用户模型是对一组人员和这些人员如何使用某个 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 类来定义的用户角色的示例。
在 Rational Software Architect 中，还为每个属性显示了 图标，意味着该属性是私有的，并且在用户模型中不重要。
每个用户角色应该至少定义一个用户目标。用户目标 定义用户角色尝试达到的最终状态或目的。图 2 显示了“资源所有者”(Resource Owner) 用户角色的用户目标示例。
该用户目标的名称是“资源所有者”希望达到的状态。存在一个提供简短描述的 <<definition>> 属性、一个或多个 <<measure>> 属性 () ，并可选地存在一个或多个 <<target>> 属性 (
)。
<<measure>> 属性描述用户角色将如何测量该用户目标是否成功实现。在适当的情况下，还可以对表示成功的测量成果级别进行建模。这是在 <<target>> 属性中提供的。
通常，您定义的初始用户目标与您认为用户可能执行的任务紧密相关。例如，您最初可能定义了一个名为“定义所有有效用户”的用户目标。这实际上是一组操作，可将其作为一个用户任务进行建模（将在稍后描述）。
用户目标应该以声明方式定义用户角色希望实现的事务状态。用户目标不描述该最终状态是如何实现的。这样存在两个优点：
- 您可以客观地检查指定的解决方案是否真正满足用户的目标。
- 使您不会在这个早期阶段就局限于特定的实现模型。
因此，让我们将该用户目标修改为“资源访问受到正确控制”。此目标捕获了为什么 资源所有者要使用该 IT 解决方案，但是没有描述如何使用。
定义了用户目标以后，就可以使用与 <<primary_goal>> 构造型的聚合关系来将该目标与适当的用户角色联系起来。将其称为主要目标是为了强调我们仅在对驱使用户角色使用该解决方案的原因进行建模。
图 3 显示了该用户角色与该用户目标之间的聚合关联。
资源所有者的 Project Explorer 视图显示了资源所有者与该用户目标的 <<definition>> 和 <<primary_goal>> 关联，如图 4 所示。
图 4. Project Explorer 中用于关联的构造型
通过选择角色名称（在此例中为“资源访问受到正确控制”）将构造型应用于关联，以在相应的窗格中显示该角色的属性。Apply Stereotypes 按钮在 Stereotypes 选项卡下，如图 5 所示。
属性和关联按字母顺序出现在 Project Explorer 中。它们在图上的出现顺序是在 Resource Owner 属性视图中的 Attributes 选项卡下定义的。
本部分讨论每个用户角色预期应该具备的技能。技能是在技能集中定义的。技能集 是与某个主题相关的技能的集合。每项技能通常仅在单个技能集中出现。技能集使用具有 <<skill_set>> 构造型的 UML 类进行定义。技能集具有一个提供简短描述的 <<definition>> 属性，以及对构成该技能集的关键技能做显式文档记录的一个或多个 <<skill>> 属性。图 6 显示了一个示例。
用户角色通过与 <<assumed_skill>> 构造型的聚合（空心菱形）关系与技能集联系起来。可以在用户角色之间共享技能集。一个用户角色可以具有多个技能集。
在图 7 所示的示例中，存在一个资源所有者预期将具备的针对资源安全技能的技能集。此定义规定拥有某个资源的个人需要具备这些技能。
当添加了从 Resource Owner 用户角色到 Resource Security Policies 技能集的关联时，该关联将出现在 Resource Owner 的 Project Explorer 视图中。可以看到 <<assumed_skill>> 构造型已应用于该关联。
对技能集建模涉及到指明哪些技能是某个用户角色特有的，以及哪些技能是某些或所有用户角色共有的。为此，您还要指明技能集之间的关系（使用聚合）。通常，表示高级技能的技能集具有与更基本的必备技能之间的聚合关系。
在图 9 所示的示例中，存在三个联系在一起的技能集：基本计算机技能 (Basic Computer Skills)、个人用户安全性 (Personal User Security) 和资源安全策略 (Resource Security Policies)。“资源安全策略”具有与“个人用户安全性”之间的聚合关系。Project Explorer 视图表明该聚合已应用了 <<nested_skill_set>> 构造型，意味着了解“资源安全策略”的任何用户角色还了解“个人用户安全性”。“个人用户安全性”和“基本计算机技能”之间的关系也类似如此。
在对技能集建模以后，将不同用户角色所需要的技能做一下对比是非常有趣的。例如，图 10 表明“资源所有者”与“业务用户”具有围绕资源安全性的相同基本技能。因此，资源所有者具有操作业务用户的资源安全性用户界面的技能。
在建模过程中的此部分，您将定义用户的预期技能级别。如果预期履行这些用户角色的人员不具备您指定的技能，则项目需要为这些用户包括培训资料，或者您可能需要尝试某种不同的方法。此分析在设计信息组织方式时也是非常有用的，因为它有助于揭示人员在何处可以履行多个用户角色。
在为用户角色定义用户目标和技能集时，您会发现在名称和 <<definition>> 属性中使用的单词选择方面，您在开始为用户角色定义一个词汇表。
用户模型以用户对象和用户构件的形式，包含了该词汇表的正式定义。用户对象表示出现在用户界面上的虚拟概念。用户构件是物理的事物，例如文件和文档。
将要经历几次迭代才能完成该词汇表。在完成用户角色、用户目标和技能集的基本定义以后，就是在用户模型中构建该用户对象和用户构件词汇表的恰当时机了。
请考虑如图 11 所示的技能集。
该技能集暗示存在以下类型的用户对象：
- Resource
- Access Level
- Access Control List
- User Group
- User Account
以及以下用户构件：
- Audit Log
对于其中每个用户对象和用户构件，创建一个带有 <<user object>> 或 <<user_artifact>> 构造型的 UML 类，并添加一个 <<definition>> 属性以提供简短描述。
如果不确定要使用 <<user object>> 还是 <<user artifact>> 构造型，只需做出您的最佳猜测。当以后有了更多信息时，可以容易地更改构造型。
每个用户对象和用户构件可以定义用户属性，以表明用户角色了解有关这些用户对象和用户构件的什么信息。在图 13 所示的示例中，Resource 具有六个属性：Name、Type、Owner、Creation Time、Last Update Time 和 Description。
每个用户属性具有类型，此类型可以是以下类型之一：
- 基本 UML 基元类型（String、Integer、Boolean 或 UnlimitedNatural）。
- 导入的模型库中的某种类型。在此示例中，DateTime 和 Text 来自于一个导入的模型库。
- UML 枚举（如果可以将用户属性设置为某个固定的值集）。
- 某种用户数据类型。
- 与另一个用户对象、用户构件或用户数据类型的关联。
用户数据类型是一种自定义数据类型，表示用户属性的相关集合。用户类型被建模为应用了 <<user_datatype>> 构造型的类。该数据类型应该对用户有意义。
用户属性始终应用了 <<user_attribute>> 构造型，即使其类型是与另一个用户对象、用户构件或用户数据类型的关联。<<user_attribute>> 构造型的图标为 。
用户属性还可以具有 <<identifier>> 构造型，其图标为 ，指示该用户属性在确定、定位或选择用户对象或用户构件的实例时非常有用。最后，还存在 <<dynamic_enum>> 构造型 (
)，指示该用户属性的有效值被定义为服务器上的一个列表（而不是通过 UML 枚举在模型中定义为固定列表）。
图 14 显示了 Resource 用户对象的树形视图，并具有如下用户属性列表：Access Control List、Creation Time、Description、Last Update Time、Name、Owner 和 Type。Name 和 Type 还具有 <<identifier>> 构造型，并且 Type 也具有 <<dynamic_enum>>。
图 14. Resource 用户对象在 Project Explorer 中的树形视图
在使用该树形视图时，务必记住：
- 该列表显示了所有的用户属性，包括其类型为与另一个用户对象、用户构件或用户类型的关联的用户属性。Access Control List 就是这样一个关联，如图 15 所示。下一部分将对这些关联进行更详细的描述。
- 当某个用户属性应用了多个构造型时，您将使用最先应用于该用户属性的构造型的图标。例如，Name 同时应用了 <<user_attribute>> 和 <<identifier>>，但是由于最先应用 <<identifier>>，因此使用了其钥匙形图标。类似地，Type 应用了 <<user_attribute>>、<<identifier>> 和 <<dynamic_enum>>，但是使用了 <<dynamic_enum>> 图标，因为该构造型是最先应用的。
通过从属性中删除所有的构造型，然后以所需的顺序重新应用这些构造型，从而可以更改构造型的顺序以更改所使用的图标。
- 可以通过属性窗格将用户属性标记为只读。
用户对象之间的关系使用 UML 关联进行定义。使用了所有四种类型：双向、定向（单向）、聚合和组合。
在图 6 所示的示例中，用户构件 Audit Log 和用户对象 Audit Log Entry 之间存在一个组合（黑色菱形）。
组合 意味着一个用户对象是另一个用户对象的一部分。在该示例中，Audit Log Entry 是 Audit Log 的一部分。基数设置为 *，这意味着每个 Audit Log 中有零到多个 Audit Log Entry。该关系的另一端的基数为 1，这意味着每个 Audit Log Entry 仅出现在一个 Audit Log 中。
在图 17 所示的示例中，存在两个来自于 User Group 的聚合关联。聚合暗示两个用户对象之间的临时关系。来自 User Group 的第一个聚合关系环回到自身。这表示一个 User Group 可以列出其他 User Group。两端的基数均为 *，因此一个 User Group 中可以包括零到多个其他 User Group，并且一个 User Group 可以包括在零到多个其他 User Group 中。
第二个聚合关联指向 User Account，表示一个 User Group 可以具有零个或多个与之关联的 User Account。此外，一个 User Account 可以包括在零个或多个 User Group 中。
这是用于描述用户对象树的常见建模模式。您可以将 User Group 看作是树中的中间节点，将 User Account 看作是树叶。
图 18 显示了如何对 Access Control List 建模。该关系具有一个来自于 Resource 的关联，表示 Access Control List 是 Resource 的一部分。 每个 Resource 有一个 Access Control List，并且一个 Access Control List 只能属于一个 Resource。
图 18. Access Control List 是 Resource 的一部分
Access Control List 由多个条目构成，因此我们创建了一个名为 Access Control List Entry 的新用户对象，如图 19 所示。
图 19. 具有多个条目的 Access Control List
起初，Access Level 被定义为一个用户对象。经过深思熟虑之后，可以明显看出它实际上是 Access Control List Entry 的一个用户属性。它可以具有的值是一个固定的值列表。如果希望在模型中硬编码这些值，可以使用一个 UML 枚举来对其进行建模，如下所示。
使用一个 <<dynamic_enum>> 构造型，从而可以在以后定义访问值，并且这些值可以随 Resource 的每种类型而不同。
当使用动态枚举时，Access Level 被指定给某个 User Group 或 User Object。可以使用继承来对此选择进行建模。定义一个名为 Access List 的新用户对象，并通过其属性视图将其设置为抽象的。
由于 Access List 是抽象的，其名称以斜体显示。
User Group 和 User Account 都继承 Access List，这意味着它们都是某种 Access List。
Access Control List Entry 通过另一个聚合关联与 Access List 联系在一起。由于 Access List 是抽象的，Access Control List Entry 只可能指向某个继承 Access List 的具体（非抽象）用户对象——在此例中为 User Group 或 User Account。图 23 显示了一个示例。
与词汇表相关的最后一个概念是用户对象筛选器，当您开始对用户任务建模时，此概念将变得更加重要。用户对象筛选器是应用了 <<user_object_filter>> 构造型的类。可以使用用户对象筛选器来对用户对象的有限视图建模，并且其中包含该用户对象的属性一个子集。用户对象筛选器具有与它所筛选的用户对象的定向关联。此定向关联上的构造型为 <<filtered_object>>。
图 24 显示了 Resource 用户对象的两个筛选器的定义，这两个筛选器分别名为 Resource Selection Filter 和 Resource ACL Filter。
Resource Selection Filter 定义了在从列表中选择一个或多个 Resource 时非常有用的 Resource 属性。例如，当某个资源所有者希望选择要使用的资源时，该筛选器包含 Name、Type、Creation Time 和 Last Update Time 用户属性。当使用此用户对象筛选器来代替用户对象时，用户将不会看到 Owner、Description 和 Access Control List 用户属性。
Resource ACL Filter 仅包括 Name 和 Access Control List。诸如 Access Control List Entry 等 Access Control List 中的所有用户属性都将可见。
此时，您应该考虑如何完成每个用户目标。用户目标是通过执行用户任务来完成的。每个用户任务描述一个操作，用户执行该操作以实现全部或部分用户目标。用户任务的范围从粗粒度到细粒度不等。有些用户任务可以通过其他用户任务组合而成。然而，用户任务始终以对用户有意义的术语来表示。
用户任务使用具有 <<user task>> 构造型的 UML 类进行定义。与其他用户建模元素一样，用户任务具有一个 <<definition>> 属性以提供简短描述。图 25 显示了一个名为 Maintain Access to Resource 的用户任务。
图 25. 用户任务 Maintain Access to Resource 的定义
用户目标通过一个单向关联与相应的用户任务联系起来。该关联应用了 <<supporting_task>> 构造型。一个用户目标通常与多个用户任务联系在一起。例如，资源所有者确保“资源访问受到正确控制”的目标是通过多次执行以下用户任务来实现的：
- 查看资源
- 维护资源访问
- 将资源移交给新的所有者
图 26 中的类关系图显示了从该用户目标到这些用户任务的三个关系。
该 Project Explorer 视图显示了这些带有 <<supporting_task>> 构造型的关系。
此模型仅表明该用户目标与这些用户任务之间存在一个关系。它没有描述何时执行这些用户任务。我们依赖用户的技能和理解来确定何时执行这些任务才适当。例如，资源所有者将使用他们的判断（或其他来源的信息）来了解应该为哪些用户提供访问权限，以及何时需要删除访问权限。
如果您觉得可以描述一个明确的过程，该过程阐述某个用户目标如何转换为用户任务，那么该用户目标很可能是一个复杂的用户任务。在这样的情况下，您应该将其构造型更改为 <<user_task>>，并为该用户角色创建一个新的用户目标。
用户任务的行为是使用从该用户任务到某个用户对象、用户对象筛选器或用户构件的定向关联来进行建模的，如下所示。该关联上的构造型为 <<action_target>>。
每个 action_target 关联定义该用户任务中的一个步骤。关系上的 <<select>>、<<view>>、<<create>>、<<update>> 或 <<delete>> 关键字表示在该步骤中执行什么类型的操作。各个关联在属性窗格的特性选项卡中的出现顺序就是预期要执行那些步骤的顺序。
需要验证用户任务与用户角色的技能匹配。在定义用户任务以后，我们将这些用户任务与执行它们所需要的技能集关联起来。要使用的关系是从用户任务到技能集的定向关联，如图 29 所示。该关联上的构造型为 <<required_skill>>。
如果截止目前已定义的所有技能集似乎都不适合，则定义一个新的技能集并将其与用户任务关联起来。
在将每个技能集与用户任务相关联时，检查预期要执行该任务的用户角色具备相关的技能集。这需要追溯到用户目标。例如，对于图 30 中的“Maintain Access to Resource”，存在一个将用户角色、用户目标、用户任务和技能集联系在一起的关系环。
图 30. 一致的关系环——用户角色具备执行某个用户任务的技能
下一阶段是定义哪些用户对象（和用户构件）与每个技能集相关联。此阶段可以定义需要包括在教育课程、帮助信息和手册中的信息类型。完成此任务的最简单方法是将与该技能集相关联的用户任务所操作的每个用户对象或构件联系在一起。
在该场景中，用户任务处理 Access Control List 和相关的用户对象。两个用户任务都与 Resource Security Policies 技能集相关联，因此 Resource Security Policies 技能集也具有这些用户对象。图 31 显示了这些关系。
技能集与用户对象或构件之间的关联是双向的，并在技能集端具有 <<glossary>> 构造型，在用户对象或构件端具有 <<taught_by>> 构造型。
最后，可以定义用户域以将相关用户任务分组在一起。在图 32 所示的示例中，用户域是一个应用了 <<user_domain>> 构造型的 UML 类。用户域可以连同用户任务一起嵌套在另一个用户域中。在较大的用户模型中，当您希望将用户任务组织到逻辑组中时，嵌套用户域是非常有用的。
本文说明了学习用于构建用户模型的符号和过程是多么简单。您只需基本了解 UML 类关系图和了解用于在用户角色之间进行区分的 UML 构造型。
有些开发团队曾经遇到过回答用户建模所引发的问题的困难。但是，这不是因为用户建模非常困难；而是由于对解决方案的用户了解得不够全面。用户建模的最大价值在于确定需求定义方面的差距，如果忽略这些差距，可能会导致非常糟糕的可用性（以及蒙受的所有成本和失败风险）。
用户建模可以揭示出何时需要通过联系参与者和用户以获取所需信息，从而执行更多的分析。一旦解决了不确定性，用户模型即可按照将对开发团队有用的形式捕获丢失的细节。其结果是获得该解决方案所支持的用户类型、那些用户需要的技能以及用户在使用该解决方案时所做的工作的有条理的定义。这实际上是构建解决方案用例的坚实基础。
请继续关注本系列的第 3 部分，其中将讨论可用于扩展用户模型的 UML 的构造型和关系。