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的本质用例中，我们补充了对系统职责的描述，虽然这些描述不会在具体的对话过程中体现，但是交流过程的完整性和场景的一致性能够指导系统的开发。

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

用户意图 系统职责
身份识别 验证身份
启动交易服务
提供选择
选择 吐钞
结余
取钞; 终止交易服务