Robert Biddle 著，zhangxxin 译
本质用例（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的本质用例中，我们补充了对系统职责的描述，虽然这些描述不会在具体的对话过程中体现，但是交流过程的完整性和场景的一致性能够指导系统的开发。
补充后的自动取款系统的本质用例描述
用户意图 系统职责
身份识别 验证身份
启动交易服务
提供选择
选择 吐钞
结余
取钞; 终止交易服务
本质用例及其设计
面向对象的设计中，“职责”扮演了非常重要的角色，确切地说，它不仅是CRC技术的关键概念，同样也是职责驱动设计中的关键概念。
在CRC技术中，职责与对象相关联，标识需要解决的问题。在完成职责的过程中，互相协作的对象之间彼此通信，通过不断的优化、迭代，形成一个满意的结构。这样，将职责分配到类，并进行细化，作为一种工具，指导实际系统的开发。
在职责驱动的设计中，职责的内容更广泛更完整。与职责相关联的对象不仅描述了对象维护的知识，还需要描述对象需要完成的动作。在这个意义上，职责强调的是对行为的抽象，而不是具体可能的执行结构的提取。但是，对象可以通过协作对象之间的消息传递完成职责，也可以由此产生更高层次的抽象类。总的来说，在这种设计方法中，职责是在较高层次上进行抽象的分配，而不考虑对象执行的细节。
在CRC技术和职责驱动的设计中，关于职责的概念和使用方法看起来非常类似。它们都认为每一个对象都有一组明确的职责，都包括了进行职责分配，指导设计决策的概念。其实，两者之间本来就有一定的继承关系。面向对象设计的基本原理就是：对象是行为和数据的统一体。职责观点沿袭了这一说法，“职责”本身就包括了职责的内容和可以使用的资源。职责还允许进行授权和管理，通过对一系列子职责的调度和管理完成职责，包括了抽象和封装的概念，正象Wrifs-Brock等人解释的那样：“职责驱动强调对结构和对象行为的封装，关注类所完成的职责，而到实现阶段再考虑类实现的具体细节。”
本质用例的职责描述系统要做什么，而不是做的具体细节。这与对象封装的观点类似，同样也具有类似的优点。
用例中的职责与设计中的职责一样，都描述行为本身，而不是执行的细节，这就可以将需求和设计连结成一个整体来进行描述。
1.确定系统边界
在实际工作中，需求主要是区分系统做什么不做什么。然而，这个边界非常难以确定，也非常难以与涉及的所有人（包括分析员和投资方等）进行沟通，达成共识。我们发现设计中使用的逼近技术非常适用于这种情况。我们把系统当成一个有明显边界的“黑盒子”，用本质用例的系统职责对系统的行为进行描述。
我们把系统看成由一系列职责组成尚未考虑执行细节的独立系统对象。Jacobson等人在不同的方向上提出过类似的观点。采用本质用例、系统职责有助于确定系统边界。如果系统类似一个独立对象，那么用例就采用类似的方法描述，只能从系统的内部访问系统的行为，而交互的过程就类似于一系列能有序管理的参数和返回值。
在UML和RUP中，通用的用例图可以把这些想法固化下来，如图5所示，在图中，我们增加了一个方框，将用户意图和系统职责分离开来，从而明确了系统边界。
银行取款系统的用例表示样例
Jacobson认可这种用法，UML同样认可这种用法，它指出：“用例可以用一个随意封闭的矩形代表系统的边界或分界”。这种用法与系统对象的提法非常一致，便于讨论和确定系统边界。
2.用例的职责和设计
对任何系统来说，本质用例的职责与系统对象内部的职责联系紧密。本质用例的职责反映了整个系统的行为，对象的职责协同工作也应该反映相同的行为。
这种方法将系统的需求和设计联系起来。本质用例的职责可以作为系统设计的起点，指导系统的行为设计，保证设计和用例的可追溯性。
从一系列本质用例开始设计，引出系统对象，通常通过一系列对象的协作完成职责。另外，在设计中，两者可以通过采用相同语言的方法巩固其一致性。
首先，尽可能采用一致的语言，对一系列描述系统对象职责的本质用例进行设计，然后再确定完成相同职责的协作类。
在严格的设计过程中，将根据上面的结果产生具体的类。这个过程是一个重新分配职责的过程，将直接影响最终设计方案的确定，要求非常细致。这个阶段的工作属于设计的基本流程，不可省略。需要一定的设计技巧和技术进行职责再分解。现在有一些成熟的技术可以直接使用，例如，在设计早期就可以使用类析取（Extract Class）技术。
但是，我们不提倡这种做法，主要有三个原因：其一，没用利用任何领域模型，使领域模型和设计脱节，造成理解和维护的困难；其二，一个完整系统有很多用例和职责，难以严格地分解；其三，难以兼顾其它地方产生的设计结构。
在CRC和职责驱动的设计中，基于基本模型和应用领域模型，产生一组关键对象和类，根据领域知识和设计要求进行初步职责分配，然后着眼于少量的关键用例进行交互和迭代，产生初步设计方案。
在CRC和职责驱动的设计中，本质用例没有引起任何流程的改变，但是，它扮演了使用快速原型法进行开发过程中非常有用的角色，为检验设计与需求的一致性提供了有效的方法。
这种方法要从设计初期抓起，从早期用例的职责分配抓起。换句话说，初始的设计职责应该从领域知识中产生。这样，可以与本质用例进行比较，得到早期的反馈，避免以后产生歧义。这样可以更好地指导关键职责设计者的开发工作。
设计一般都会有结果，有许多设计方案可以在新的设计中作为一部分进行继承和重用，例如组件、组件库、框架、设计模式等等，有的甚至本身已经是可执行的，它们对系统设计影响很大。而本质用例则提供最终设计与需求是否一致的有效检验方法。
与CRC和职责驱动的设计不同，其它设计方法与职责本身可以无关，因此，设计和需求的检验显得更加复杂，更加重要，需要对组件和其它结构进行仔细检查。但是，对可执行重用资源的检查并不是对其执行的正确性进行验证，更多的是对其行为模式的认可，也可以说是对其适用性的认可。这样确实对提高重用度具有深远的意义。
用例和设计的职责划分明确以后，问题就迎刃而解了。无论是无意的还是设计活动中的折衷，设计的不完善性都可能存在。无论采用哪种方式，都需要提升设计。另一方面，设计又可以从某种程度上弥补需求的不足。例如，设计必须基于现有系统的处理活动，哪怕仅是需求中的片言只语，这时就可以重新考察用例，看能否有所改变，能否使用现成的设计资源。
综上所述，引入需求和设计职责的概念提高了两者之间的可追溯性，保证需求和设计的一致性。
3.举例说明
在本节中，我们将通过一个小例子来描述我们的工作。为了说明问题，例子非常简单，但是所用的方法同样适用于更复杂的系统，可以用于顶层设计，也可以用于详细设计，并且也有可用的支撑工具。
这个例子是图书馆系统中的一小部分。领域模型由两个对象类组成：书籍和借阅者。分析的过程如图6所示。在顶层，我们只关注于两个本质用例：借书和还书。
通过对这两个本质用例的进一步分析，我们可以得到迭代1中产生的CRC卡片。在这个步骤中，我们不一定能够分析得到所有的系统对象。例如，要知道可借阅的图书，就必须登记已借阅的图书，必须对作为协作对象的职责进行分配。
系统对象应该明确，能够与用例对应，如果用例太多，产生的对象太大，就会难以执行。从领域模型出发，我们建立了三个类：单独的图书馆系统Library System类、书籍Book类（每本书一个实例）和借阅者Borrower类（每个借阅者一个实例），然后考虑它们的职责分配。
迭代2显示了这个设计过程。在设计中，书籍借阅标志的设定在书籍Book类中完成，但是，依然可以通过图书馆系统Library System类进行初始化、查询和更新操作。
图书馆系统Library System类还有一项职责，就是不但需要“知道有哪些图书”，而且还要能够查询。也就是说，图书馆系统Library System类必须对书籍Book类进行管理，同时对借阅者Borrower类也应有相应的管理功能。
在迭代3中，书籍Book类和借阅者Borrower类没有改变，增加了一个独立的分类Catalogue类，完成“知道有哪些图书”的职责，可以用一个标准的collection对象来实现。
需要说明的是，我们在这里基本上只列举在用例中明确描述的职责，实际上，在领域分析的过程中，还会分析产生一些职责，并且对整个过程发生影响。例如，检查书籍是否被借阅的职责就是通过类似领域分析的过程产生的。
如图所示，从需求中提取职责进行设计并不只是一个单向的过程，它可以进行调整和变化。但是，这个过程的描述非常有利于与投资方进行交流，特别是复审阶段的双方沟通。
讨论
在本章中，将讨论几个与本质用例相关的面向对象设计主题，包括：
· 无界面系统（实时系统）设计；
· 定制界面系统的设计；
· 迭代和增量开发过程；
· 界面和应用的并行开发；
· 基于业务过程的面向对象设计。
1.无界面系统（实时系统）设计
在实时系统和软件引擎中，系统只与系统主角交互，并且没有传统的人机界面，那么，能否采用本质用例呢？答案是肯定的。本质用例同样适用于这类系统。
在这类系统中，有一个重要概念就是“外部世界（outside world）”。在任何系统中，都需要对系统的内部和外部进行明确的划分，从而确定系统的边界；确定系统交互的原则（无论是人还是机器）；设计交互方式。我们发现，在这样的系统中，本质用例同样有许多优点。在适当的抽象层次上，本质用例摆脱了表达和实现的具体细节的束缚，能够更准确的捕捉用户意图和系统职责的本质，它不受具体系统类型限制，简洁明了，易于理解，便于编辑，方便复审，可以实现分析和设计的无缝连接和平滑过渡。
系统常常有一些附加的非功能性约束，例如响应时间、交换速率、信息容量、可靠性等。因为用例着眼于交互的过程，所以不是发现和确定这类需求的理想工具。但是，它可以帮助记录和管理这类需求。在常规用例方法中，通常采用文字描述的方法，并与用例同步管理，且其管理过程与用例结构无关。本质用例也可以采用类似的方法。在以用为中心的设计中，这类指标往往与本质用例相关，因为它们对高性能的用户界面设计至关重要。
本质用例的系统职责、系统对象的职责以及中间对象的职责之间的可追溯性弥补了系统设计的不足，保证系统满足这类非功能性指标的要求。例如，用例级的系统约束可以分解到对象中，对象的性能又直接影响到用例职责。采用公共任务标签的办法可以调整最终设计，确保满足非功能性指标要求。
2.定制界面系统
本质用例同样适用于已经定义好界面的情形。在这种情况下，我们先对界面进行分析，然后描述交互过程的本质用例，并在此基础上进行面向对象的设计。这样，从系统交互和职责的本质着眼进行设计的中间系统更稳定，更能够适应界面细节的变化，同样具有本质用例方法的主要优点。
3.设计业务流程
长期以来，常规用例被认为是业务流程建模的好方法，它主要描述的是业务单元（人）之间的交互，而不是计算机系统和人之间的交互过程。
本质用例与技术无关，它描述用例之中抽象的意图和任务，因此，无论采用何种界面技术，都可以实现用例。例如，采用相同的一个呼叫中心的用例，既可以支持用桌面应用的方法实现，也可以支持用Web的方式实现。还可以支持采用交互的语音提示的方法实现。这就是说，本质用例与采用何种技术途径无关，需要的仅仅是最基本的计算支持。
使用本质用例的成功经验告诉我们：本质用例既适用于软件设计，也适用于业务流程设计，它们在抽象、对话和任务中具有相同的优点。
4.开发过程
本节主要描述我们建立的软件设计模型，并为模型构建的过程提供参考。非常重要的是，从本质用例到系统对象，然后到面向对象的中间设计描述是开发的抽象过程，而不是构建模型的具体步骤，并不是类似于瀑布的过程，先对本质用例进行“分析”，接着确认其“完整性”和“正确性”，然后进行设计等等。
我们希望这个过程是一个增量的、可迭代的过程：先有一个备选用例表和一个初步的领域模型；其中的关键用例首先被细化，按用户意图和系统任务编写到用例卡片中；然后进行初步的设计，划分对象任务，并对用例的措词进一步细化和调整。再细化其它的用例，获得更多的对象模型，这些工作可根据后续工作中情况进行必要的复查和调整。
本质用例有助于软件开发的迭代过程，其抽象层次、用例与模型间的通用词汇决定了迭代开发的过程更易于跟踪，具有更好的一致性，对象和用例之间具有更良好的可追溯性。当设计完成时，所有的用例和对象都使用相同的词汇表，所有的系统任务被设计划分成适当的中间对象，所有的用例都可以被对象模型执行，能够更方便地检验设计和系统任务的一致性。
5.并行开发
在以用为中心的设计中，使用本质用例同样可以产生用户界面。在这种情况下，基于本质用例采用面向对象设计方法进行中间设计具有更加显著的优点。它可以避免重复工作：它设计的用户界面可以直接在软件设计中重用，无须重新捕捉和进一步细化，使软件设计和界面设计可以同步进行，只要二者同时支持本质用例就可以保证良好的一致性。
这和其它的过程方法（特别是RUP过程）略有不同，不需要在早期就完成界面设计，可以在软件设计阶段进行，支持软件设计和界面设计的同步进行，不会因为界面设计没有完成而延宕工期，可以有效地缩短项目周期，特别是在用户界面设计要求高、数量多的项目中，可以为整个项目节约好几个月的时间。
并行设计特别适合于Web系统的开发，前端界面和后台服务软件可以独立设计，并有专门的技术支撑其实现。在这样的并行开发过程中，要求对迭代过程进行有效地管理，协调设计过程中用例的变更和实现，使二者保持良好的一致性和可追溯性。
与其它方法的比较
软件开发技术在不断地向前发展，也提出了许多其它的手段和方法。在此，我们着重介绍它们处理需求和设计之间关系的不同方法。
面向对象的软件工程（OOSE）对建立对象模型中对象和用例之间的关系提出了许多有用的建议。Jacobson等人用系统边界、控制和实体对象实现用例的方法来建立分析模型，但是在分配系统行为和产生类（class）的过程，要求有一个附加的翻译过程。与这种方法相比，我们使用的本质用例方法具有更好的可操作性。
还有一些更简单和直接的方法来组织需求和进行面向对象设计。例如，在第二章中提到，Jacobson等人介绍用例概念，以及Lockwood提出在用例界面设计中使用本质用例方法就是基于这样的思想。还有许多指导用例写作及其在软件开发中具体应用的书籍。例如，Cockburn最近就出版了一本详细介绍用例写作方法的书籍，并对各种风格的用例进行了介绍。Amour和Miller还讨论作了为需求搜集工作的一部分，如何发现和管理用例。但是，这些工作很少提及用例如何在分析和设计阶段的工作中反映，讨论用例和设计关系的工作在领域模型的开发中完成，把领域模型作为设计和开发的第一步。领域模型固然非常重要，但是，从需求到发现领域模型、领域模型满足需求之间还应该有大量的工作需要完成。
大量的文献都提到可追溯性的重要性。Pfleeger指出，可追溯性包括横向和纵向的可追溯性。纵向的可追溯性是指开发过程中模型内部的关系，横向的可追溯性是指模型与模型之间的关系。加强系统的可追溯性可以有效地提高开发过程的质量和降低维护成本。
我们致力于需求与设计横向可追溯性的工作，将二者的关系直接反映到任务的分配中，成为设计工作的一部分。
任何软件开发方法都伴随相应的过程。最近经常提到的过程是Rational（瑞理公司）统一过程，即RUP。RUP是用例驱动的软件开发过程，用例连接开发过程的各个阶段。在我们使用的本质用例方法中，本质用例在开发过程中具有同等重要的地位，只是在用例格式的选择上有所差异。事实上，本质用例方法与RUP方法中用例的描述没有任何矛盾，甚至可以认为本质用例是基于前文中指出的OOSE方法中分析和设计工作流的细化。
还有一种开放式的软件开发过程，准确地说，它是一种软件开发方法的框架，而我们只关注其过程部分。特别值得关注的是它的开放式工具技术，为不同职责的软件开发需求提供完整的技术支持。它提供从原始需求到设计模型的技术，包括：协作分析技术、CRC卡片建模技术、委托分析技术、领域分析技术、泛化和继承技术以及对象模型转换技术等。上述所有技术都可以和我们的研究联系起来，而我们的工作在指导操作和提供可追溯性方面做出了贡献。
最近，轻量级方法XP等大行其道。基于XP方法的设计要求功能需求尽量简化，在真正需要以前，不轻易增加别的功能。XP是带有独立“用户故事”的增量开发过程（与用例类似但完全固化），通过再分解现存的程序实现用例，达到增量的目的。我们的方法与XP的方法也有所类似，所有的设计都可以再生。但在XP的方法中，当需要扩展支持新的用例时就需要重新设计，而在我们的方法中，设计从完整的系统目标出发，以实现整个系统为目的，所有的再分解都维持了对象的任务，都可以在中间组件之间重新进行分配。
结论
用例适用于各种软件的开发，本质用例起源于用户界面设计的细化和描述。我们尝试在面向对象的系统开发中使用本质用例，并在本文中进行了总结。
本质用例能够简单快速地发现需求，支持通过角色扮演进行沟通，有助于发现系统边界。它简明扼要，易于学习，避开了繁琐的实现细节，支持快速开发。使用这种方法易于确定用例模式。它还同时支持界面和系统设计，可以实现二者的并行开发。
本质用例标识系统任务，将需求和面向对象的设计联系起来。在设计中，其职责启发分配协作对象之间的抽象行为。使用本质用例描述需求，采用职责驱动的方法进行设计，可以更好地为设计提供指导，使设计和需求具有良好的可追溯性。
