本质用例（Essential Use Cases）是一种轻量级的方法，它简单明了，不受技术约束，用于沟通用户意图和系统职责，能够有效地捕捉用户界面的设计需求。在设计过程中，使用本质用例从系统职责中提取的关键词汇可以直接作为对象来使用，具有显著的优点。本文描述如何使用本质用例直接驱动面向对象开发过程，并实现与用户界面进行并行开发的方法。

在面向对象软件开发的过程中，用例在捕获需求过程中得到了广泛应用，并受到业界标准建模语言UML和建模过程RUP的广泛支持。Constantine和Lockwood在《以使用为中心的设计》（Usage-Centered Design）中写道：“本质用例为支持用户界面设计而编写，简单明了，不受技术约束”。在一般过程中，本质用例用来产生用户界面设计，设计完成以后，又分解成几个更具体的一般用例，其中包括更详尽的细节和进一步的界面设计。但是，采用这种方法在用户界面设计完成以后才能进行实质的面向对象开发工作，费时费力，难以取得良好的效果。

在本文中，我们讨论在面向对象的软件开发过程中尝试直接使用本质用例的方法。与一般用例类似，本质用例可以作为面向对象设计的起点，但是，使用本质用例的方法进行沟通更加简洁，且无需指定太多的设计细节，便于需求搜集。

在过去两年中，我们使用本质用例方法作为主要需求搜集工具做了好几个系统的开发。我们发现，本质用例方法非常适用于面向对象软件开发，并且比一般用例具有更加显著的优点。

有三个结果需要介绍：第一，与我们推测的一样，本质用例可以直接驱动面向对象设计；其它的两个是意料之外的结果：一是本质用例提供了从需求转换到面向对象设计的指导，再有，就是保证了本质用例和对象之间的可追溯性。进一步研究发现，因为本质用例反映了用例的基本需求，从而可以由此确定用例的模式，更有效地进行需求搜集。在后文中，我们将详细描述该方法。

本文组织如下：首先介绍本质用例提出的过程，并与一般用例方法进行比较；在第三章中，介绍本质用例的提取方法，以及使用角色扮演的方法检验其正确性和一致性；第四章通过一小段例子介绍如何在设计面向对象系统时使用本质用例；第五章以应用为中心讨论在无人参与的系统中使用本质用例的方法、开发过程以及业务过程设计等主题；最后，在第六章，进行相关工作的讨论，并得出结论。

背景

1.用例

Jacobson在他1992年的著作中写道：“用例是与系统进行对话时行为相关的事务系列的描述。”在最近的RUP中，对用例的描述没有实质性的改变，它认为用例是“一系列带变量的动作描述，系统由此对特定用户产生有价值的可见结果”。

从某种程度上说，利用用例思想描述系统与外界的交互过程是行之有效的。

在软件开发的早期，用例着眼于系统交互，有助于提取系统行为，从而捕捉系统需求，确定系统规范。用格式化的语言和图形对系统的交互过程进行描述比较容易，而且易于理解，所以，由此产生的用例技术非常有效，特别适用于在大范围内进行需求搜集和分析工作。

在后续的开发阶段中，用例描述系统的交互过程。而交互过程是系统规约的具体化。在设计和实现过程中，系统规约通过结构来体现。在复审和测试过程中，用例描述测试等系统行为。在设计、实现和复审过程中，它们由同一角色引出，因此，整个开发过程具有可追溯性。

用例建立在一系列交互的基础上，一般来说，一个期望的交互过程总伴随与其目标（或子目标）一致的结构，因此，采用用例可以对需求进行有效的划分，通过组合、过滤、设定优先次序等方式进行组织，协助管理整个开发过程。

关于用例的优点以及用例到底是什么的讨论一直没有停止过。其基本概念已经有所发展和变化，尤其对软件开发方面的支持，例如职责描述和本质用例。我们选择本质用例作为工作的重点。

2.本质用例

本质用例是以使用为中心设计的一部分，由Larry Constantine和 Lucy Lockwood 提出。用例具有显著的优点，但也有其局限性：“特别是一般的测试用例，它包括太多难以说明的，甚至是隐含的内建假设，而且用户界面设计的内容也包括在内”，这导致很早就必须进行设计决策，因为其内容成为需求的一部分，难于变更来适应以后的变化。

本质用例克服了上述问题。术语“本质”来源于：本质模型是“通过与技术无关的、理想化的、简单明了的描述来捕捉问题的实质”。Constantine 和Lockwood对“本质用例”的定义如下：

“本质用例是使用应用领域或用户语言描述的结构化叙述，由职责的描述或交互过程组成。是一种轻量级的方法，对职责的描述简明扼要、技术无关、可独立实现，从反映系统交互的根本意图和目的角色的用户视角出发来描述交互过程，具有完整、针对性强、定义明确的特点。

本质用例用一种格式化的文本来记录用户和系统的交流过程。这个文本与Wirfs-Brock使用的两列表的格式类似。虽然在Wirfs-Brock的格式中用“动作”和“响应”两列来讨论用例抽象的级别框架，但它也适用于用户和系统的交互。

在本质用例中相应地采用“用户意图”和“系统职责”作为两列的标识。这样，即便使用用户界面细节描述也能抽象地描述交互的过程。需要注意的是，这个抽象过程并非作为一个整体与用例相关，而是与用例的各个阶段相关。用这种方法得到的本质用例是一系列交互过程，而不是抽象的步骤。

Constantine和Lockwood的例子如图1和图2所示。图1采用一般用例，用“用户动作”和“系统响应”进行描述，图2采用本质用例，用“用户意图”和“系统职责”进行描述。可以看到，采用本质用例的描述更抽象，更易于适应具体实现的变化，它更简短而且易于理解。

Jacobson使用用例支持面向对象的软件设计； Constantine 和Lockwood提出了本质用例和更广泛的基本模型框架，以支持界面设计和开发。我们注意到除了面向对象的软件开发外，本质用例实际上是毫无用处的。换句话说，本质用例的优点只有在面向对象的软件开发领域才能得到体现。

自动取款系统的一般用例描述（Constantine 和Lockwood）

用户动作 系统响应

插入卡 读取磁卡

提示输入PIN

输入PIN 校验PIN

显示交易菜单

按键 显示总额菜单

按键 提示总额

输入总额 显示总额

按键 退卡

取卡 吐钞

取钞

自动取款系统本质用例描述（Constantine 和Lockwood）

用户意图 系统职责

身份识别 验证身份

提供选择

选择 吐钞

取钞

本质用例和需求

在设计过程中，CRC技术可以在团队活动中提高对设计的理解和设计的有效性，而在用例分析和评估过程中却缺乏这样的技术。我们希望开发这样一种技术。本质用例有许多适应这种技术的特性，因此，我们开始在面向对象软件开发过程中使用本质用例。

与CRC技术类似，该技术包括索引卡和角色扮演。经过大家讨论确定用例以后，给每个用例分配一张卡片，在顶部写上用例的名称。将卡片纵向分成两部分，左侧描述用户，右侧描述系统，如图3所示。然后，团队中每两人一组来研究人机对话过程，一个扮演用户，一个扮演系统，并记录对话的经过，把结果提交给用例的审查小组进行复审。

本质用例描述系统的人机对话过程，是角色扮演的脚本，可以通过一部分人扮演系统，一部分人扮演用户的方式来模拟系统的人机对话过程。与纯文本的描述不同，这个过程是可视化的，不易引起歧义。Wirfs-Brock指出，用例可以看做用户和系统的“交谈”过程，有助于系统建模。另外，用例和角色扮演还可以帮助确定系统边界，划清系统内部和外部的界限。

我们在应用领域和学校的开发小组中展开进一步的工作，获得了使用的实际经验。我们发现，抽象的本质用例有很多好处，简短的卡片式描述可以加速分析过程，更多地考虑交互细节，无需早期就在系统交互的具体问题上纠缠不清，被系统的具体实现所困扰而花费大量时间，从而可以集中精力确定系统的本质用例。

本质用例的抽象过程实际上是指导角色扮演的过程，并不是一个真正可实现的对话过程。但是，开发早期的角色扮演实际上是轻量级的，不能判断能否实现。如果需要对抽象元素的具体例子加以明确，那么，把它作为一个可操作的本质用例，可以由此讨论产生一个具体的脚本，描述可能的实现细节。

1.用例

本质用例的对话并不是指简单的用户动作，而是用户意图。

在角色扮演中，要从角色的视角考虑问题，深入理解其动机和类型，考虑其所处的环境，了解其背景。这样才能准确表现其意图。

从这个意义上说，角色扮演对团队其它成员和听众变得更加重要。对用户意图的充分考虑赋予角色扮演更丰富的内容。更重要的是，复审人员需要更深入详细地考虑用例，评估其一致性，验证是否提取对话中的所有元素。

除此之外，用例着眼于系统与外部世界的交互过程和使用细节。而在大多数系统的开发过程中，系统使用的不确定导致用例实现完全依靠理解能力和创造能力的发挥。本质用例通过对用户意图的理解来确认系统用途，但并不否认用途也可以基于对用户本身的理解进行提取。在这种方式下，用户意图成为用例设计的原动力。

在RUP等软件开发过程中，用户界面原型包括对用户本身和用户需求的理解，因此很早就需要进行开发。采用本质用例方法，在理解用户意图的前提下，为用户建立一个清晰的流程设想，同样可以作为系统后期设计的输入。但是，这种方法是轻量级的，不需要产生具体的用户界面，可以支持更快速的开发过程。

2.系统职责

在本质用例中，采用系统职责代替系统响应进行描述是因为系统职责包括了更多与用户意图相关的内容，并在系统后期设计中产生其它影响。

在角色扮演中，用户角色扮演特定的人，意图可以通过多种方式表达，而系统扮演的未知实体则很难进行发挥。但是必须达到验证、确认人机交互过程的目的。

要深入理解人机对话中的任何一个元素，都需要在目标基础上加以引申。因此，本质用例对用户的描述采纳用户意图而不是用户目的。用户意图中除了可以理解的内容外，有一部分我们可以适当地加以引申。

对系统的描述应增加一些针对内部的说明，用以指导下一步的设计。系统职责是描述系统需要做什么，而不是系统实现的细节。这与用户意图的产生动机略有不同，但有助于确定用例和角色扮演。引入用户意图是为了描述系统实现的目标，而引入系统职责是为了描述系统实现的责任。

在本质用例中，某些用户界面与大系统的开发有千丝万缕的联系。在使用本质用例开发用户界面的例子中，系统职责作为人机对话的参与者，主要关心提供给用户的信息内容。但是，在大系统中，系统职责必须包括更广泛的内容。例如，在图2所示的银行系统取款的本质用例中，清楚地描述了与用户界面相关的内容，却缺乏与银行财会业务相关内容的描述。

当然，一般用例也有这样的缺点。如果用例只用于描述系统和用户之间的对话，必然难以准确地体现各系统（子系统）之间的联系，比如图1的用例也有这样的缺点。

从这个意义上说，着眼于系统职责的本质用例更加实用，因为它并不直接、简单地描述系统与用户的交流过程。在图4的本质用例中，我们补充了对系统职责的描述，虽然这些描述不会在具体的对话过程中体现，但是交流过程的完整性和场景的一致性能够指导系统的开发。

补充后的自动取款系统的本质用例描述

用户意图 系统职责

身份识别 验证身份

启动交易服务

提供选择

选择 吐钞

结余

取钞; 终止交易服务