上一篇：面向对象开发中的本质用例及其职责（2） >>

面向对象开发中的本质用例及其职责（1）

本质用例（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的格式中用“动作”和“响应”两列来讨论用例抽象的级别框架，但它也适用于用户和系统的交互。

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

返回顶部

下一篇：面向对象技术应用：可重用软件组件 >>