级别： 初级 Mandy Chessell, IBM 杰出工程师、杰出发明家, IBM
Larry Yusuf, 解决方案架构师, IBM
2008 年 7 月 03 日 通过本系列了解如何构建用户模型，以描述相关人员及其如何使用 IT 解决方案。本文是本系列的开篇，将对统一建模语言（Unified Modeling Language，UML）建模进行介绍，并将讨论如何从用户的角度创建系统的规范（系统规格说明书）。
引言
没有人会专门构建难于使用的产品。不过，我们经常会遇到让人迷惑、烦躁而且不便于使用的工具、设备和 IT 解决方案。为什么会这样呢？
在很多情况下，IT 解决方案之所以不好用，是因为设计者是根据技术或 Gadget 能够提供的功能构建的，而没有以用户的需求为基础。这不是某个个人的失职。相反，这主要是因为软件开发方法经常太过于关注系统功能的正确设计和视觉方面的有限外部设计（如颜色、术语、交互性和屏幕布局）所致。
正确功能和视觉设计非常重要，但为使用者设计 IT 解决方案不仅仅需要对用户界面的外观加以关注。用户建模在这方面更深入了一步，会影响系统行为的基础层面。如果用户模型一开始就不正确，即使功能完全符合其规范，也不会“正确”。
 | | 后续文章将提供构建用户模型的具体说明，并将提供在用户建模中使用的 UML 建模元素的目录。 |
|
在本文中，我们将了解如何从用户 的角度创建系统规格说明书。用户建模对系统建模和组件的其他体系结构建模进行补充，这方面从界面设计阶段一开始就非常有用。另外，还可以通过其提供用例的重要信息。通过此方法，每个迭代都可以交付有用而且易用的功能。有用，因为它可帮助人们实现其目标；易用，因为它与概念模型匹配。
定义概念模型
概念 模型定义我们预期事物将如何工作。它是根据我们以前的经验动态构建的。人们使用可见的线索和控制器（如手柄和开关）来操作看到的物体，以实现其目标。概念模型可帮助我们了解各种新情况。
想想通过不熟悉的门进入建筑物的情况。您不需要借助操作手册或培训课程来通过这扇门。您将首先找到可以旋转的房门把手，或推动门板。这些部件的位置告诉您折叶的位置以及门是向里开还是向外开。如果没有这些，您可以试试门会不会检测到有人靠近就自动打开。在这个过程中，您在使用来自概念模型的知识进行一系列试验。您收到的反馈和结果将确定您后面的步骤。
通过我们的概念模型，我们可以容易地处理很多新情况。不过，当某个东西不按照我们预期的方式工作时（由于缺少可见线索，或被线索误导），我们会发现一片混乱。如果折叶位于门的顶部，其工作方式有些像门上的猫洞，或者如果门把手位于折叶旁边，您会有什么样的感觉呢？
当事物不按照我们预期的方式工作时，我们经常会由于失败而感到有些不好意思，或者感到非常气恼。即使了解了其工作方式，将来使用时仍然需要特别注意，否则就可能继续犯错。我们认为它“很难使用”，因此会采取措施来避免使用。
将概念模型应用于 IT 解决方案
概念模型也适用于 IT 解决方案。IT 解决方案在屏幕上显示对象，如文档或文件夹，并为人们提供操作对象实现其目标的方法。
IT 对象经常与现实世界中的物体非常相似。就像实际物体一样，解决方案中的 IT 对象必须按照与我们认为其应该的行为方式的概念模型一致的方式工作。当 IT 对象模拟现实世界的物体，必须准确。IT 解决方案必须具有与概念模型预期相符的可见操作，并对每项操作提供清楚、明确的反馈。
例如，以在线文档库为例。用户可以创建在线文档并将其放入电子文件夹中。文档和文件夹的电子版本需要按照与现实世界的对等项相同的方式工作。可以对电子版本添加或扩展在现实世界中无法完成的功能（例如，将文档同时放入多个文件夹的能力）。不过，进行扩展时必须格外小心，以避免给使用系统的人员造成混淆。
将解决方案的外部设计元素与使用它的人员的概念模型匹配，这是成功的关键。对解决方案满意的用户是此解决方案最强大的销售推广力量。用户如果不满意，可能甚至会劝阻其他人试用此解决方案。
了解用户是用户建模的第一步
为了构建有用而且易用的解决方案，您必须从以下方面了解其使用者的特征：
- 他们的目标是什么
- 他们如何将目标转换为行动
- 他们的概念模型的相关部分如何操作
此信息捕获在用户模型中。
用户模型 是由简单类关系图组成的专用 UML 模型，描述用户的目标和技能、您要求他们执行的任务以及在 IT 解决方案中将使用的对象。其中的每个概念都作为自己的造型化 UML 类表示，并具备描述其间关系的 UML 关联。
从确定解决方案的使用者开始构建用户模型。
用户角色
由于概念模型是以我们的经验为基础构建的，因此每个人的概念模型都是唯一的。不过，这并不意味着我们需要针对每个个人用户进行建模。幸运的是，我们与具有类似背景和教育的其他人有相似的经验。在解决方案操作的领域，可以将可能具有类似概念模型的用户分组到一起。这些用户组称为用户角色。
用户角色代表具有类似职责和技能的用户组。可以将用户角色视为组织内的工作角色，如采购员、营销经理、系统管理员和办事员。
务必为解决方案的所有方面定义用户角色，包括业务使用、自定义、管理及操作等。如果忽略了某个使用领域，此领域可能在部署解决方案时带来意外成本和造成用户不满意。
用户目标
对于每个用户角色，为其定义目标及您预期其将具有的技能。每个用户角色至少具有一个用户目标。用户目标 描述结束状态，或用户角色希望达到的目的。此目标应该是可度量的，而且应该为用户角色可以实现的。从用户角色到用户目标的关系称为主要目标，以强调您建模的仅是用户角色最为重要的方面。
图 1. 具有主要目标的用户角色
您可以通过创建使用子目标关系链接的用户目标层次结构来将用户目标划分为子目标，如图 2 中所示。
图 2. 将主要目标划分为子目标
在典型的组织中，一个用户角色可能依赖于其他用户角色来完成其目标。例如，除非开发人员编写了代码，否则测试人员无法完成与测试软件相关的目标。如果代码提交晚了，测试人员出色完成工作的能力将受到影响。
可以通过虚线箭头表示依赖关系。确定依赖关系是在帮助了解组织内的压力所在（这在系统设计期间通常是重点关注对象）。
图 3. 不同用户角色的用户目标之间的依赖关系
通过对用户角色的目标的详细分析，可以了解使用系统的人员的动机——还可以了解可能出现协作和冲突的地方。此分析将帮助您将解决方案的功能定为更直接地支持用户需求。
向关系图添加技能集
用户角色预计应该具有的技能归入多个组，可通过培训课程或技术鉴定获得的这些技能。这些技能组称为技能集。
如果某个用户角色拥有某技能集，就表示该角色中的人员了解与该技能集关联的术语和概念。这种了解使用从用户角色到技能集的“已获得技能”关系在用户模型中显示。
图 4. “已获得技能”关系
用户角色必须具有一个以上技能集。某些技能集可能代表现有知识，而其他技能集可能代表用户角色为了使用此解决方案而必须获得的知识。
图 5. 具有主要目标和已获得技能集的用户角色
您可以使用“嵌套技能集”关系表示技能集之间的关系，指示嵌套技能集是先决技能集。在图6 中，假定已获得技能集 A 的用户角色还将具有技能集 C。
图6. “嵌套技能集”关系
还可以将技能集分组为规程，如图 7 中所示。您可以使用“嵌套规程”关系以层次结构方式建模规程。规程仅用于提供在模型中组织技能集的方法。
图 7. 层次结构中定义的规程和技能集
通过建模技能集关系，可以对不同用户角色的技能进行比较，或许可以帮助了解职业发展途径。通过建模这些关系，可以确定某个用户角色是否可以替代另一个用户角色。在图 8 的示例中，用户角色 A，具有用户角色 B 具有的所有技能。适合担任用户角色 A 的人可以代替用户角色 B。类似地，具有用户角色 B 的技能的人可以通过技能集 A 和技能集 B 的培训执行用户角色 A 的工作。
图 8. 用户角色间共享的技能集
通过分析与用户角色关联的技能集，可以帮助确定哪些是高技术用户角色以及为了某个人执行某个用户角色而需要进行哪些培训。技能集分析可以帮助项目经理对特定项目所需的资源进行预算。
每个技能集还具有与其关联的术语或概念词汇表。这些术语代表了用户角色在拥有此技能集的情况下所熟悉的词汇。您可以使用用户对象和用户构件来建模此词汇表。
建模用户对象和构件
用户对象 是用户使用的逻辑概念，而不是编程接口中的对象。用户构件 是物理对象，如磁盘或文件。
您可以将“用户-属性”关系用于建模用户对象和用户构件间的关系。此关系表明目标是源的特性或属性。例如，在图 9 中，用户对象 A 具有用户对象 B 的属性或特性。
图 9. 用户对象间的“用户-属性”关系
类似地，可以将“用户-属性”关系用于用户构件和用户对象之间。可以将这种“用户-属性”关系视为用户构件内容的定义。如果图 10 中的用户构件是日志文件，用户角色 C 则可以为日志文件中的日志记录。
图 10. 建模用户构件内容的“用户-属性”关系
用户对象和用户构件定义技能集的概念和术语。在用户模型中，我们使用双向关系对此加以表示。从技能集到用户对象或用户构件的方向上，此关系称为“词汇表”关系。而在另一个方向上，此关系称为“教授”关系。
图 11. 技能集和用户对象间及技能集与用户构件间的双向关系
通过这些关系，您可以定义每个角色所理解的术语。用户角色将使用的任何用户界面都应该仅仅使用相应技能集中的这些术语。如果需要其他术语，可以将其添加到用户角色的技能集之一，或将其添加到属于用户角色的新技能集。
图 12. 与技能集关联的用户对象和用户构件
通过用户任务实现目标
用户目标是通过执行用户任务实现的，这些任务可以是手动任务或由一个或多个 IT 解决方案支持的任务。用户任务显示在用户模型中，以帮助通过从用户目标到用户任务的“支持任务”关系实现用户目标。
图 13. “支持任务”关系
通常，用户的目标由一系列用户任务加以支持，如图 14 中所示。
图 14. 用户目标和实现此目标所需的用户任务之间的关系
为了实现用户目标，可以按照任意顺序多次执行用户任务。用户任务还可以与多个用户目标关联。因此，特定的用户任务可能会由多个用户角色执行。可以将用户任务细分为子任务层次结构，以显示用户任务复杂的情况，或显示两个或更多用户任务之间存在相同子任务的情况。
您可以使用“子任务”关系来将复杂用户任务组织为包含若干简单用户任务的层次结构。
图 15. “子任务”关系
在这种模型中，定义“支持任务”或“子任务”关系的顺序并不指示用户任务执行顺序。使用解决方案的人员可以使用自己的技能来决定何时适合执行某个任务（如发送电子邮件）。或者，如果存在逻辑顺序，您可以使用“后续任务”关系来记录此顺序，“后续任务”关系表明用户任务可能的完成顺序。
图 16. “后续任务”关系
需要自动定序时，可以将用户任务处理为业务流程模型中的步骤。
通过其他关系，可以显示支持用户目标的用户任务的结构，如图 17 中所示。
图 17. 支持用户目标的用户任务结构
有很多用户的模型可能包含很多用户任务。您可以将相关的用户任务分组为用户域，就像技能集可以分组为规程一样。用户域可以使用嵌套域关系链接为层次结构，如图 18 中所示。
图 18. 由嵌套用户域和用户任务形成的层次结构
执行用户任务需要特定的技能。每个用户任务都与执行此任务所需的技能集之间存在联系。
图 19. “所需技能”关系
“所需技能”关系允许进行简单的检查，以确保执行特定任务所需的每个用户角色都具有相应的技能。
图 20. 用户角色、用户目标、技能集和用户任务之间的关系
“所需技能”关系可以指向直接与用户角色关联的技能集或其中的嵌套技能集。嵌套技能集可以提供用户角色的支持任务所需的技能。
图 21. 嵌套技能集
在图 22 中，用户角色 B 具有执行用户任务 4 的技能。不过，此用户角色只有在用户任务 4 支持此角色的一个或多个主要目标时才会执行该任务。
图 22. 用户角色和技能
通过用户模型中的关系，您可以：
- 方便地验证用户角色的用户目标可以实现。
- 验证解决方案需要支持的用户任务。
- 确定哪些用户角色需要执行每个用户任务。
- 确认执行用户任务所需的技能与将执行这些任务的用户角色的技能匹配。
建模用于完成任务的用户操作
对于每个任务，您还要建模用户完成任务时使用的用户对象和用户构件。您可以使用从用户任务到用户对象的“操作-目标” 关系对此进行建模，如图23 中所示。您可以通过在此关系上使用操作关键字建模所执行的操作。
图 23. “操作-目标”关系
图 24 显示了具有三个“操作-目标”关系的用户任务。运行此任务的人员首先选择用户对象 A 的一个或多个实例，然后对其（包括用户对象 B 的嵌套实例）进行更新。最后，用户任务创建用户对象 C 的一个或多个实例。
图 24. 用户对象和用户任务间的关系
“操作-目标”关系出现在用户任务中的顺序定义其应有的执行顺序。
由于用户任务也与技能集关联，因此可以验证该技能集了解这些用户对象，而且二者保持了一致。
图 25. 验证用户对象一致性
创建用户模型的好处
完成了用户模型后，可以提供 IT 解决方案外部化的对象的详细清单，还能了解根据用户角色执行的任务的特征向每个用户公开的对象子集的详细情况。
只需要很少的 UML 知识就能构建用户模型（创建类关系图）。通过分析解决方案将如何工作获得的宝贵知识的价值将远远超过构建模型所花的成本或时间。此模型可创建用户交互的准确定义，可以方便地用于检查逻辑一致性。模型的抽象级别（详细程度）与用户将面临的抽象级别相同。如果模型变得难于使用或“太过复杂”而不便创建时，则明显地表明所得到的解决方案也会同样过于复杂。
创建用户模型的流程揭示了开发团队对用户需求不了解的领域。而且，此过程还突出了项目定义中存在风险和不足的领域。完成用户模型之后，可以对用例定义起到促进作用（以用户任务为基础开发），并提供了确定开发和测试规模方面有用的标准，如要支持的用户任务数量等。
无论用户模型是完全事先构建的，还是稍早于每个开发迭代开始前构建的，它都为项目的每个迭代提供了坚实的基础。
请关注本系列的 第 2 部分，其中将说明如何为支持对 Web 资源进行安全访问的简单组件创建用户模型。
致谢
特别感谢我们的同事审阅了本文并提供了极好的评论和反馈，尤其是 Rebecca Schaller 和 Dan Wolfson。
参考资料 学习
获得产品和技术
- 下载 IBM 产品评估版，获得来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。
讨论
作者简介 | | | Mandy Chessell，系英国皇家工程学会会员（FREng）、特许工程师资格（CEng），及英国计算机协会成员（FBCS）。她从 1987 年开始在 IBM 任职。她是 IBM 杰出工程师（IBM Distinguished Engineer）、IBM 杰出发明人（IBM Master Inventor）以及 IBM 技术研究院（IBM Academy of Technology）的成员。目前，她正担任 IBM 软件部信息解决方案部门（Information Management division）的首席架构师（Lead Architect）。在先前担任的职位上，她为 CICS、Encina、TxSeries、Component Broker 以及 WebSphere 等产品开发了许多新功能。她还提交了 40 项专利、当中的 15 项已经获得批准。在她的技术职责之外，Mandy 还参与了在于增强 IBM 技术人员技术活力的倡议活动。这些活动包括了辅导、为员工技术职业发展以及晋升委员会服务，领导创新项目以及组织 Women in Technology 活动等等。在 IBM 之外，Mandy 还是英国皇家工程学会（Royal Academy of Engineering）的会员，以及英国谢菲尔德大学（University of Sheffield）的客座教授。在 2001 年，她成为了第一位获得英国皇家工程学会银质奖章的女性。她还曾在 2000 入选由美国 MIT 的 Technology Review 杂志评选的 “TR100” 青年发明家。目前，由于她为创新人群的推动工作，她还获得了英国女性发明家（British Female Innovators）称号、Inventors Network (BFIIN) 的“Building Capability”奖，以及 BlackBerry “2006 Best Woman in Technology - Corporate Sector” 奖。 |
| | | Larry Yusuf 是 Software Group Strategy and Technology 的一名解决方案架构师，并开发了将组织上下文和用户透视图引入复杂软件解决方案体系结构和设计的全面设计技术。他领导了填补软件组合空缺的集成外接程序的开发。在早期工作中，他曾致力于新兴技术、解决方案开发和测试。他拥有业务集成解决方案、模型驱动的开发、面向模式的软件开发和事件管理方面的经验。他广泛从事关于这些主题的写作和演讲，并申请了七项专利。 |
对本文的评价
| 
