指南：主角

主角	主角实例是指在系统外部与系统进行交互的人或物。 一个主角类定义一个主角实例集，其中的各个主角实例在系统中都担任同一角色。

主题

• 解释
• 如何查找主角
• 主角帮助定义系统边界
• 简要说明
• 主角特征

解释

要充分了解系统的目的，您就必须知道系统是为谁而设计的，即谁将使用该系统。不同类型的用户用主角来表示。

主角是与系统交换数据的任何事物。主角可以是用户，也可以是外部硬件或者其他系统。

主角与单个系统用户的区别在于，一个主角表示某一特定的用户类，而不是一个实际的用户。多个用户可以担任同一角色，这意味着他们可以是同一个主角。在这种情况下，每个用户都是一个主角实例。

Ivar 和 Mark 是一台回收机的操作员 (Operator)。当他们使用这台机器时，将他们分别表示为操作员这一主角的一个实例。

但是，在某些条件下，只有一个人来担任一个主角所建模的角色。例如，一个较小的系统可能只有一个人担任系统管理员的角色。

同一用户也可以充当多个主角（即，同一个人可以担任多个不同的角色）。

Charlie 主要以库房经理 (Depot Manager) 的身份来使用库房管理系统，但有时他也会以普通库房人员 (Depot Staff) 的身份来使用该系统。

如何查找主角

在系统环境中，什么会成为系统的主角？

首先考虑使用系统的个人。如何对他们进行分类？作为一种好习惯，通常应考虑 2 至 3 个人，并确保您所确定的主角能够满足他们的所有需要。如果在确定主角时能考虑到以下问题，那将非常有用：

• 谁负责提供、使用或删除信息？
• 谁将使用此功能？
• 谁对某个特定功能感兴趣？
• 在组织中的什么地方使用系统？
• 谁负责支持和维护系统？
• 系统有哪些外部资源？
• 其他还有哪些系统将需要与该系统进行交互？

系统环境中有多个不同的方面可用单独的主角来表示：

• 执行系统主要功能的用户。

示例：

对于一个支持库房工作的库房管理系统来说，有以下几类用户：库房人员、订单登记员和库房经理。所有这些用户类别都在系统中担任专门的角色，因此您应该用一个单独的主角来表示每个类别。

• 执行系统辅助功能（例如系统管理）的用户。

示例：

对于回收利用罐子、瓶子、箱子等的回收机来说，客户是主要的主角，因为系统就是为他们建立的。但是，必须有人来管理这台机器。此角色用操作员这一主角来表示。

• 系统所使用的外部硬件。

示例：

控制建筑物中温度的通风系统不断地从建筑物中的传感器处获取温度信息。所以，传感器就是一个主角。

• 与该系统交互的其他系统。

示例：

一个自动柜员机必须和保存银行帐户的中央系统进行通信。中央系统很可能是一个外部系统，因此它应该是一个主角。

如果您在构建一个基于 Internet 的应用程序，那么您的主要主角在某种意义上将是匿名的。您并不真正知道这些主要主角是谁，而且也无法假定他们的技能和背景。但您仍能说明您希望他们在您的系统中担任的角色。

示例：

用来提供信息的系统（例如搜索引擎）的主角全部是匿名的，他们访问应用程序的目的仅在于查找有关某一特定主题的信息。 

示例：

政府信息站点的宗旨是为公民或者“网民”提供有关法律法规、行为规范和表单等方面的信息。例如，美国国内收入署的网站上就有专门的网页告诉公民如何填写纳税申报单。这包括通过电子手段提供所有表单，并使得个人可通过电子手段提交纳税申报单。在这种情况下，主要主角的角色就是对在美国提交纳税申报单感兴趣的所有人。当然，一旦个人试图提交纳税申报单，此人就不再是匿名的。 

主角帮助定义系统边界

查找主角还意味着建立系统边界，这可以帮助您理解系统的目的和范围。只有那些直接与系统通信的人员才需要被当作主角。如果您将系统环境之外的角色也包括进来，那您就是在试图对使用系统的业务建模，而不是对系统本身建模。

示例：

在一个机票预订系统中，什么是主角呢？这取决于您所建立的机票预订系统是供旅行社使用，还是供旅客通过 Internet 直接使用。

如果是第一种情况，那么主角就是旅行社。旅游者不直接与系统进行交互，因此不是主角。

如果是第二种情况，旅游者将直接和系统交互，因此是该系统的主角。

简要说明

对主角的简要说明应该包括以下信息：

• 主角所代表的对象。
• 为什么需要主角。
• 主角在系统中能获得哪些利益。

简要说明的长度最多为几个句子。

示例：

在回收机的用例模型中，三个主角的简要说明如下：

客户：客户收集家中的瓶子、罐子、箱子，然后将它们送回商店换得退款。

操作员：操作员负责对回收机进行维护。

经理：经理负责处理商店在向客户支付钱款和提供服务时出现的问题。

主角特征

主角的特征可能会影响到系统的开发，特别会影响到以可视方式开发出一个最实用的用户界面的过程。注意，如果在业务对象模型中已对与主角通信的业务角色进行了说明，就可能已经获得了以下的某些特征。主角特征包括：

• 主角的职责范围。
• 主角使用系统时所处的物理环境。理想的情况是，用户处于一个安静的环境中，并且全神贯注。但如果有偏差，就可能会影响到到用户对声音、字体选择以及一些输入设备组合（例如键盘、触摸屏、鼠标和热键等）的使用。
• 此主角所表示的用户数量。在确定此主角的重要性及其使用的用户界面中各部分的重要性时，该数字将是一个相关因素。
• 主角使用系统的频率。此频率将决定该主角在各会话之间应该能够记住用户界面中的多少内容。

在多数情况下，对用户数量和使用频率大致估计一下就足够了。30 和 40 之间的差别并不会影响用户界面的形成，但是 3 和 30 之间的差别则可能会。

其他主角特征包括：

• 主角的领域知识水平。这一水平将帮助我们决定用户界面中需要多大领域专用帮助，以及应该使用多少领域专用术语。
• 主角使用计算机的经验水平。这一水平将有助于确定应该在用户界面中使用复杂的交互技术还是简单的交互技术。
• 主角使用的其他应用程序。如果能够从这些应用程序中借用用户界面概念，将缩短主角的学习时间并减小其记忆负担，因为主角已经熟悉了这些概念。
• 主角的一般特征，包括专业知识（教育）水平、社会背景（如语言）和年龄。这些特征能影响用户界面的一些细节，例如字体和语言。

以上特征主要在确定边界类和原型时使用，可确保用户群能最充分地利用用户界面设计。

示例：

以下是“邮件用户”这一主角的特征示例。此主角与“管理输入邮件消息”用例进行交互。

• 邮件用户是一位熟练的 PC 使用者。

• 邮件用户通常在安静的办公室中工作。

• 邮件用户的目标数量为 500,000。