指南： 用例示意板
详细信息：概念： 以用户为中心的设计
主题
- 解释
- 描述事件流 - 示意板
- 所需的指导说明
- 对象的平均属性值和平均容量
- 平均操作使用率
- 总结：事件流 - 示意板
- 创建边界类图
- 创建边界对象交互图
- 补充用例示意板图
- 获得对用例示意板的可用性需求
- 参考用例示意板中的用户界面原型
- 使用
解释 
用例示意板用于理解和分析包括可用性需求在内的用户界面需求。它们是对用户界面的高层理解，并且开发它们比开发实际用户界面速度更快。因而，在设计和实施用户界面原型之前，可以使用用例示意板来创建和分析推导几个不同版本的用户界面。
用例示意板按照边界类以及它们的静态与动态关系（如聚合关系、关联关系和链接）来进行描述。 每个边界类则是用户界面上的窗口或类似结构的一个高层表示。以下是这种方法的优点：
- 它提供了静态窗口关系的一个高层视图，如用户界面中的窗口包含分层结构以及对象间的其他关联关系。
- 它提供了动态窗口关系的一个高层视图，如用户界面中的窗口导航路径和对象间的其他导航路径。
- 它通过说明相应的边界类，提供了在用户界面中获取各个窗口或类似结构的需求的一种方法。这是因为每个边界类都定义了职责、属性、关系等等，从而存在直接映射到用户界面中相应结构的一个映射。
- 它可以追踪特定用例，从而提供软件工程用例驱动方法的无缝集成。因此，用户界面将由系统要求提供的用例、在这些用例中的主角（用户）的角色以及用例的期望来驱动。
分析模型中的用例示意板可以追踪（一对一）到用例模型中的用例。
描述事件流 - 示意板
以下是关于如何描述事件流 - 示意板的指南：
- 首先要阐明用例本身，而不是用户界面。首先要使用例说明不受用户界面影响，对未经研究的用例更应如此。这将有助您抓住用例的本质，类似于概念：以用户为中心的设计中说明的“核心用例”。随着对用例有深入的理解，事件流 - 示意板可在用户界面和可用性等方面逐步进行补充。
- 保持操作语句简短。因为除了用户界面设计人员以外，不要求所有的人都能够理解，所以描述不必面面俱到。由于用简短步骤组成的操作语句可以使用例说明更简练，因此这种操作语句能够提供更佳的概述。例如，当描述用例如何与一个主角交换数据时，应保证描述简洁而全面；您可以在行末的圆括号内列出交换数据：“create person (name, address, telephone)”。
- 避免使用序列和模式。人员主角通常能够以不同的顺序执行用例的各项操作，对于由用户控制且用户界面所占比重较大的系统尤其如此。序列通常包含用户界面的模式，因而应该尽可能避免使用模式。这样以来，应该只指定在用例中必须使用的序列。例如，在用户可以从 ATM 机上提款之前，他必须证明自己的身份；或者在用户可以接受或拒绝之前，系统必须先将发票出示给该用户。
- 与用例保持一致。既然用例示意板或多或少可以和相关用例并行描述，那么这两个工件应该保持一致，并且相互提供反馈。特别地，用例示意板的事件流 - 示意板应该和相应用例的事件流保持一致。注：在这种情况下，负责用例的用例作者和负责示意板的用户界面设计人员之间通常需要进行大量的交流和反馈循环。
示例：
以下是关于在补充可用性方面的信息之前，“管理进入邮件消息”用例的示意板的一个初始事件流 - 示意板示例。
a) 邮件用户请求管理邮件消息时，该用例启动，然后系统显示消息。
b) 邮件用户接着可以执行以下一个或多个步骤：
c) 根据发送人或主题排列邮件消息。
d) 读取邮件消息的正文。
e) 将邮件消息另存为文件。
f) 将邮件消息附件另存为文件。
g) 当邮件用户请求退出管理进入邮件消息时，用例终止。
注：该初始事件流 - 示意板与活动： 查找主角和用例中已经描述的相应用例的分步说明相类似。因此，在创建初始事件流 - 示意板说明时，请将相应用例的分步说明用作输入。
然后，对该初始事件流 - 示意板说明增加不同的可用性方面的信息，例如所需的指导说明、对象的平均属性值和平均容量以及平均操作使用率（参见下文内容）。
所需的指导说明
一个确实可用的系统不仅帮助用户自动完成简单的重复性任务，还可以提供相关指导，通常是通过（隐含方式）提供无法实现自动化的任务的信息。例如，这些指南可以通过“气球式帮助”或环境生成的屏幕帮助来获得。
这是用户界面设计的一个重要输入，应通过在用例事件流的特定点确定对这些所需指导说明的需求来表述。
用户界面设计人员应该走查事件流，并在每个步骤上考虑以下问题：
- 用户可能需要什么样的指南？
- 系统可以提供什么样的指南？
- 什么应该表示为所需的指导说明而什么不应该？
根据事件流，可以确定系统的基本功能。根据所需的指导说明，应该可以确定“可选”功能，这对于用户是否能够开展他的工作并不是至关重要的，但是该指导说明可以通过（隐含方式）提供用户所需的信息来帮助用户开展工作。因此，任何可以帮助查找到这些可选功能的东西都应该看做是所需的指导说明。不过，不应对只能找到无论如何都可以找到的某些功能的所需指导说明进行描述，因为我们通过较好的用户界面设计方法就能查找到这些功能（例如，无须描述以下内容：系统应该向用户提供有关用户操作的反馈，或应该向用户显示用户可以使用的所有选项等等）。
所需的指导说明还可以用来告诉您什么内容不应该显示出来，从而帮助您制作避免用户陷入不相关信息包围的用户界面。
所需的指导说明与事件流一样，不是“需求”，而更象“想要有”或“有最好”。当确定和描述所需的指导说明时，不应该仅仅考虑系统最终应该提供的内容，而且还要考虑用户可能需要的内容；否则，您的考虑范围将受到限制。因此，请记住，所需的指导说明不是绝对需要的，它仅仅是增加可用性的一种手段。
示例：
以下是关于管理进入邮件消息用例的示意板的一个事件流 - 示意板示例，其中补充了所需的指导说明（在[]内）。
a) 邮件用户请求管理邮件消息时，该用例启动，然后系统显示消息。[用户应该可以区分新的、已读的和未读的消息；用户还应该看到每个消息的发送人、主题和优先级。]
b) 邮件用户接着可以执行以下一个或多个步骤：
c) 根据发送人或主题排列邮件消息。
d) 读取邮件消息的正文。
e) 将邮件消息另存为文件。
f) 将邮件消息附件另存为文件。[用户应该可以看到附件的文件类型。]
g) 当邮件用户请求退出管理进入邮件消息时，用例终止。
在用户需要作出决策的动作过程中常常要求得到所需的指导说明。以下各点通常适用于这类决策：
- 它们对用户而言不是微不足道的。
- 它们影响系统周围的人们生活或业务（系统周围的人或业务通常指业务、用户以及用户企图执行的任务。）
- 一旦用例终止，它们就变得关系重大。
示例：
在管理进入邮件消息用例的事件流 - 示意板中，步骤 f)（即保存附件）显而易见是用户做出的决策。因此，它需要一些操作指导。
对象的平均属性值和平均容量
获取对象的平均属性值和平均容量通常是很重要的事情，这些属性值和容量需要用户进行管理或者提交给用户。用户界面然后利用这些平均值和容量来进行优化。
示例：
以下是关于管理进入邮件消息用例的示意板的一个事件流 - 示意板示例，其中补充了平均属性值和容量（在{ }内）。
a) 邮件用户请求管理邮件消息时，该用例启动，然后系统显示消息。{平均有 100 个未读邮件消息同时显示；在 90% 的情况下，消息的主题行少于 40 个字符。}
b) 邮件用户接着可以执行以下一个或多个步骤：
c) 根据发送人或主题排列邮件消息。
d) 读取邮件消息的正文。{消息正文平均包含 100 个字符。}
e) 将邮件消息另存为文件。
f) 将邮件消息附件另存为文件。{在 95% 的情况下，附件少于两个。}
g) 当邮件用户请求退出管理进入邮件消息时，用例终止。
平均操作使用率
获取平均操作使用率以查找频繁使用的动作，其频繁使用程度是相对于很少使用的动作而言的。因此，我们将通过用例查找常用的和不常用的序列（流）。这是一个重要的信息，可以用于确定用户界面及其导航分层结构的频繁使用部分的优先次序并集中解决这些部分的问题（例如，通过在用户界面中提供快捷方式或增加工具栏来执行常用的操作）。
示例：
以下是关于管理进入邮件消息用例的示意板的一个事件流 - 示意板示例，其中补充了平均操作使用率（在()内）。
a) 邮件用户请求管理邮件消息时，该用例启动，然后系统显示消息。
b) 邮件用户接着可以执行以下一个或多个步骤：
c) 根据发送人或主题排列邮件消息。（在超过 60% 的情况下都完成此步骤。）
d) 读取邮件消息的正文。（在超过 75% 的情况下都完成此步骤。）
e) 将邮件消息另存为文件。（在不足 5% 的情况下完成此步骤。）
f) 将邮件消息附件另存为文件。
g) 当邮件用户请求退出管理进入邮件消息时，用例终止。
本描述的结论是步骤 c) 和 d) 是需要彻底的用户界面支持。
总结：
事件流 - 示意板
示例：
以下是关于管理进入邮件消息用例的示意板的最终事件流 - 示意板示例，其中补充了不同的可用性方面的信息。
a) 邮件用户请求管理邮件消息时，该用例启动，然后系统显示消息。[用户应该可以区分新的、已读的和未读的消息；用户还应该看到每个消息的发送人、主题和优先级。] {平均有 100 个未读邮件消息同时显示；在 90% 的情况下，消息的主题行少于 40 个字符。}
b) 邮件用户接着可以执行以下一个或多个步骤：
c) 根据发送人或主题排列邮件消息。（在超过 60% 的情况下都完成此步骤。）
d) 读取邮件消息的正文。{消息正文平均包含 100 个字符。} （在超过 75% 的情况下都完成此步骤。）
e) 将邮件消息另存为文件。（在不足 5% 的情况下完成此步骤。）
f) 将邮件消息附件另存为文件。[用户应该可以看到附件的文件类型。] {在 95% 的情况下，附件数量少于两个。}
g) 当邮件用户请求退出管理进入邮件消息时，用例终止。
因此，事件流 - 示意板的基本思想是用不同的可用性方面的信息来增强事件流的说明；该信息将用于进一步的可用用户界面设计的工作。另请注意：以上示例所示的可用性方面信息可以进行修改或对其他方面进行补充，而这一切都依赖于对特定应用类型的需要或使用中的用户界面技术。
创建边界类图
用例示意板是通过边界类以及它们的交互对象来实现的。为了阐明参与用例示意板的边界类以及它们的关系，我们创建了类图并将它们作为用例示意板的一部分。
示例：
以下是“管理进入邮件消息”用例的用例示意板包含的一个类图：
类图包括邮件用户 (Mail User) 主角、邮箱 (Mail Box) 边界类、邮件消息 (Mail Message) 以及附件 (Attachment)，这些对象都参与了管理进入邮件消息用例的用例示意板。 我们可以通过邮件用户与邮箱聚合关系分层结构中所有包含的对象交互环境来理解类图。
有关边界类及其关系的详细信息，请参阅指南：边界类（用户界面建模）。
创建边界对象交互图
为阐明参与用例示意板的边界对象以及它们与用户的交互，我们使用协作图或序列图。 这对于具有复杂序列或事件流的用例是非常有用的。
示例：
以下是关于管理进入邮件消息用例的用例示意板拥有的一个协作图。
协作图包括邮件用户 (Mail User) 主角、邮箱 (Mail Box) 边界对象、邮件消息 (Mail Message) 以及附件 (Attachment)，这些对象都参与了实现管理进入邮件消息用例的用例示意板。
补充用例示意板图
根据需要，可以通过将事件流 - 示意板用作补充文本说明来对用例示意板图做进一步阐述。 这可以通过为事件流 - 示意板补充有关的边界类来完成。
示例：
以下是关于管理进入邮件消息用例的示意板的一个事件流 - 示意板示例，其中补充了边界类（在""内）。
a) 邮件用户请求管理邮件消息时，该用例启动，然后系统显示消息。[用户应该可以区分新的、已读的和未读的消息；用户还应该看到每个消息的发送人、主题和优先级。]{平均有 100 个未读邮件消息同时显示；在 90% 的情况下，消息的主题行少于 40 个字符。}“邮箱”
b) 邮件用户接着可以执行以下一个或多个步骤：
c) 根据发送人或主题排列邮件消息。（在超过 60% 的情况下都完成此步骤。）“邮箱”
d) 读取邮件消息的正文。{消息正文平均包含 100 个字符。}（在超过 75% 的情况下都完成此步骤。）“邮件消息”
e) 将邮件消息另存为文件。（在不足 5% 的情况下完成此步骤。）“邮件消息”
f) 将邮件消息附件另存为文件。[用户应该可以看到附件的文件类型。] {在 95% 的情况下，附件数量少于两个。}“邮件消息” “附件”
g) 当邮件用户请求退出管理进入邮件消息时，用例终止。"邮箱"
获得对用例示意板的可用性需求
可用性需求可以定义用户界面的可用性必须达到的水平高度。例如，这类需求可以在工件： 补充规约内找到。这意味着为达到使用目的，可用性需求不应设置为您所认为系统能够达到的高度，而应该设置为系统必须达到的最低级别的可用性。
出于使用目的，系统必须达到的高度主要取决于备选的使用系统的办法。因此要求该系统比备选方法具有更大有用性是合理的。备选方法可以利用：
- 现有的手工步骤。
- 遗留系统。
- 竞争产品。
- 系统的早期版本。
可用性需求还可以说明新系统在资金节约方面的合理性需要。如果客户必须耗资 3 百万美元购买新系统，则最好使用相应的可用性需求，说明由于减少了人力资源的工作负荷，每年大概会节约 1 百万美元。
关于用例示意板的可用性需求通常指定：
- 最大执行时间 - 用户经培训后执行用例的某个常见场景需要多长时间。
- 最高错误率 - 经过培训的用户执行用例的某个常见场景时平均出现多少错误。
与评测有关的唯一错误是那些无法恢复且对组织存在消极影响的错误，例如业务丢失或者监控的硬件遭到破坏。如果某个错误的仅有序列需要费时修理，这将影响到评测的执行时间。
用户经过学习后执行某个场景的时间会少于指定的最大执行时间，在此之前用户花费的时间就是学习时间。
注：可用性需求不能作为目标，如上限等。可用性需求应该规定绝对最低的、可接受的系统可用性。因此，在实现可用性需求之后，不应该停止提高可用性。
示例：
以下是关于管理进入邮件消息的可用性需求的示例，它们都记录在相应的用例示意板上。
-
邮件用户应该可以通过一次鼠标单击完成对邮件消息的整理。
-
邮件用户应该可以通过按住单个键盘键来滚动邮件消息正文。
-
当阅读现有的邮件消息时，邮件用户不应该受到进入邮件消息的干扰。
参考用例示意板中的用户界面原型
为进一步阐明用例示意板，可参考与它的参与边界类对应的用户界面原型部分（如窗口）。在说明示意板时，如果已经存在用户界面原型部分，这将对说明很有帮助。
使用
在用户设计用户界面原型之前，用例示意板主要用于开发的初始阶段，作为获取关于用户界面需求的“推理”工具。
用例示意板通常被看作暂时性工件，一旦项目加快设计原型或实施用户界面的工作，则可能不再保留该用例示意板。然而在某些情况下，在一定数量的迭代过程中保留用例示意板可能有一定的使用价值。例如，如果存在对用户界面的复杂需求，了解该要求需要耗费一定的时间（经过几个迭代）。
由于用例示意板是高度概念性的说明，有些读者对其理解不明确，因此用例示意板不必以任何其他读者的观点来说明，而需要以用例设计人员的观点来说明。相反，它们的具体表现形式（如用户界面本身或它的某个原型）将由包括最终用户在内的其他涉众进行讨论、复审和测试。尽管如此，用户界面设计人员在使用测试期间可以将用例示意板作为一个参考对象来使用，重点解决要测试的相关问题（如，复杂的交互序列）。
可以对上述建议采取一个折衷方案；如果开发示意板的成本大大低于开发实际用户界面原型的成本，则在实施原型之前，让用户直接复审示意板可能是很有价值的。这样就要求示意板的说明必须清楚完整，以便让用户理解；创建这些说明需要大量的开发资源。
如果用例示意板已在需求工作流程内进行概述，并且用户界面原型已经创建，那么相应的边界类都是分析活动的良好输入。然而，有时还需要在分析过程中创建用例示意板以触发相应的用户界面设计和实施活动，原因有以下：
- 有些项目不需要创建用户界面原型；相反，它们只需要直接设计和实施用户界面，无需将任何原型作为输入内容。
- 有些项目确实需要创建用户原型，但是只是针对很少数量的用例。其余的用例不需要为它们的用户界面设计原型。
