Java 建模: UML 工作簿，第 3部分

核心提示：需求收集是任何成功的软件开发周期中不可缺少的一步，虽然有众多的需求收集方法，Java 建模: UML 工作簿，第 3部分，但是最普通的方法是用例建模，在 先前的两个专栏中，这个事件流代表一个经过系统的通向成功输出的单一路径，这是用例描述的核心部分，我们已经完成了一部分将序列图同用例建模关联起来的工作，这次我将更多地谈论

需求收集是任何成功的软件开发周期中不可缺少的一步。虽然有众多的需求收集方法，但是最普通的方法是用例建模。在 先前的两个专栏中，我们已经完成了一部分将序列图同用例建模关联起来的工作。这次我将更多地谈论方法之后的理论，并且也增加一些您的建模词汇。

这次讨论中，我更关心的是阐明用户接口、系统接口和用例描述之间的关系。因为所建立的大多数系统将被设计成人机交互式的，所以将用例描述设计成以用户接口开始运行是很诱人的。但是在用例中包括用户接口逻辑通常被认为是不好的形式。这种说法的一个简单解释是，用户接口提供一个系统透视图的系统概貌。用例总是以参与者（或用户）透视图被描述。

为了真正理解为什么我们在用例描述中不包括 UI 逻辑，我想无论如何我们不得不采用亲身实践的方法。我们将使用我的 第一个专栏中的贷款申请的示例，并且您将看到用例是如何随着尺寸的增大而变得复杂的。特别地，我们要注意在用例建模中透视图的角色。随着我们的深入，您将看到透视图是怎样被用来为您工作的，或者，如果被不正确地应用，它是如何阻碍您工作的。

什么是用例模型？

一个用例模型由一张图表和一组阐明该用例的描述组成。一个用例是在一个系统中的一组可能的交互，它的参与者朝着同一个被定义的目标进行。这些描述描述了系统中该用例的功能性；这张图表提供了这些描述的可视化路标。UML 规定了建立用例图表的标准，但并不是为了编写用例描述的。结果产生了许多编写用例描述的方法，这些方法有时是互相竞争的。

最流行的编写用例描述的方法体现着 Ivar Jacobson （用例建模的发明者）的思想。Jacobson 的方法涉及一系列进入和退出的准则，分别被称作 前置条件和 后置条件，和一个称为 事件流的核心准则。这个事件流描述了一系列参与者（用户或外部系统）和被制定的系统之间的交互。这个事件流代表一个经过系统的通向成功输出的单一路径。这是用例描述的核心部分，但不是全部。